IDZ DO
IDZ DO
PRZYKŁADOWY ROZDZIAŁ
PRZYKŁADOWY ROZDZIAŁ
Java. Aplikacje bazodanowe.
SPIS TRE CI
SPIS TRE CI
Najlepsze rozwiązania
KATALOG KSIĄŻEK
KATALOG KSIĄŻEK
Autor: George Reese
Tłumaczenie: Radosław Meryk
KATALOG ONLINE
KATALOG ONLINE
ISBN: 83-7361-260-2
Tytuł oryginału: Java Database Best Practices
ZAMÓW DRUKOWANY KATALOG
ZAMÓW DRUKOWANY KATALOG
Format: B5, stron: 296
Przykłady na ftp: 54 kB
TWÓJ KOSZYK
TWÓJ KOSZYK
Aplikacje biznesowe dotyczą danych  niezależnie od tego, czy są to dane o produkcie,
DODAJ DO KOSZYKA
DODAJ DO KOSZYKA
szczegóły dotyczące kart kredytowych użytkowników czy preferowanego koloru
kupowanych samochodów. Wraz ze wzrostem znaczenia informacji wzrosła także
złożono ć dostępu do nich. Programi ci Javy mogą wybierać teraz spo ród różnego
CENNIK I INFORMACJE
CENNIK I INFORMACJE
rodzaju interfejsów API i technologii  EJB, JDO, JDBC, SQL, RDBMS, OODBMS i innych.
Do tej pory byli oni zdani na siebie przy podejmowaniu decyzji o tym, który model
ZAMÓW INFORMACJE
ZAMÓW INFORMACJE
najlepiej pasuje do ich aplikacji i jak w najlepszy sposób korzystać z wybranego API.
O NOWO CIACH
O NOWO CIACH
Książka  Java. Aplikacje bazodanowe. Najlepsze rozwiązania przychodzi z pomocą
ZAMÓW CENNIK programistom. Teraz nie muszą już oni przeszukiwać kilku książek na temat różnych
ZAMÓW CENNIK
API, aby zdecydować o odpowiedniej metodzie. Ten obszerny przewodnik omawia
podstawy wszystkich wiodących interfejsów API (Enterprise JavaBeans, Java Data
Objects, JDBC, a także innych, mniej znanych opcji), obja nia metodologię i komponenty
CZYTELNIA
CZYTELNIA
projektowe wykorzystujące wspomniane interfejsy oraz prezentuje rozwiązania
FRAGMENTY KSIĄŻEK ONLINE
FRAGMENTY KSIĄŻEK ONLINE
najbardziej dostosowane do różnych typów aplikacji.
Książka omawia także zagadnienia dotyczące projektowania baz danych, począwszy
od architektury tabel, skończywszy na normalizacji. Autor przedstawia najlepsze
rozwiązania rozmaitych problemów. Nauczysz się w jaki sposób przeprowadzać różne
rodzaje normalizacji, a także dowiesz się, kiedy warto przeprowadzić denormalizację.
Uzyskasz także szczegółowe instrukcje dotyczące optymalizacji zapytań SQL w celu
najlepszego wykorzystania struktury bazy danych. Zaprezentowano także praktyczne
zastosowania omawianych technik dostarczając informacje, które Czytelnik może
zastosować natychmiast we własnych projektach aplikacji biznesowych.
Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl

Przedm�wa ......................................................................................................................9
Część I �rchitektura danych ..................................................................15
R�zdział 1. Elementy aplikacji baz�dan�wej ..........................................................17
Rżdzaje architektury aplikacji bazżdanżwych .................................................................................18
Mżdele kżmpżnentów..........................................................................................................................33
Mżdele trwalżści....................................................................................................................................35
R�zdział 2. �rchitektura danych relacyjnych ..........................................................37
Pżjęcia relacyjne .....................................................................................................................................38
Mżdelżwanie..........................................................................................................................................49
Nżrmalizacja...........................................................................................................................................51
Denżrmalizacja.......................................................................................................................................61
źdwzżrżwanie żbiektżwż-relacyjne..................................................................................................65
R�zdział 3. Zarządzanie transakcjami......................................................................71
Transakcje ...............................................................................................................................................72
Wspólbieżnżść........................................................................................................................................76
Zarządzanie transakcjami w JDBC .....................................................................................................80
Paradygmaty dżtyczące zarządzania transakcjami .........................................................................88
Część II M�dele trwał�ści ......................................................................91
R�zdział 4. P�dstaw�we p�jęcia związane z trwał�ścią......................................93
Wzżrce trwalżści....................................................................................................................................93
ęplikacja  księga gżści .......................................................................................................................98
6 Spis treści
R�zdział 5. EJB CMP  trwał�ść zarządzana przez k�ntener EJB..................115
Który mżdel CMP zastżsżwać?.........................................................................................................116
Mżdel CMP �JB 1.0 .............................................................................................................................117
Mżdel CMP wersji �JB 2.0..................................................................................................................124
źprócz CMP.........................................................................................................................................129
R�zdział 6. EJB BMP  trwał�ść zarządzana przez k�mp�nenty EJB ...........131
Pżwtórka z �JB.....................................................................................................................................132
Wzżrce BMP.........................................................................................................................................135
Zarządzanie stanami ...........................................................................................................................142
źbsluga wyjątków...............................................................................................................................146
R�zdział 7. Trwał�ść JDO .........................................................................................149
JDź czy �JB?.........................................................................................................................................150
Prżsta żbsluga trwalżści za pżmżcą żbiektów JDź ......................................................................152
Mżdel trwalżści �JB BMP z JDź.......................................................................................................156
R�zdział 8. �lternatywne wz�rce trwał�ści ..........................................................159
Dlaczegż wartż stżsżwać alternatywne szablżny?........................................................................160
Spżsób realizacji funkcji trwalżści ....................................................................................................162
źperacje dżtyczące trwalżści.............................................................................................................169
Wyszukiwanie......................................................................................................................................171
Dżdatkżwe infżrmacje........................................................................................................................172
Część III Sam�uczki...............................................................................173
R�zdział 9. P�dstawy J2EE .......................................................................................175
Platfżrma...............................................................................................................................................175
Interfejs JNDI........................................................................................................................................176
JavaServer Pages ..................................................................................................................................187
Zdalne wywżlywanie metżd.............................................................................................................193
�nterprise JavaBeans...........................................................................................................................200
R�zdział 10. SQL .........................................................................................................209
Wprżwadzenie .....................................................................................................................................210
Twżrzenie bazy danych......................................................................................................................213
Zarządzanie tabelami..........................................................................................................................215
Zarządzanie danymi ...........................................................................................................................220
Spis treści 7
R�zdział 11. JDBC.......................................................................................................233
ęrchitektura..........................................................................................................................................233
Prżsty dżstęp dż bazy danych ..........................................................................................................238
Zaawansżwane zagadnienia JDBC ...................................................................................................254
R�zdział 12. JDO .........................................................................................................263
ęrchitektura..........................................................................................................................................264
Ulepszenia.............................................................................................................................................267
Zapytania ..............................................................................................................................................269
Mżdyfikacje ..........................................................................................................................................273
Transakcje .............................................................................................................................................273
Dziedziczenie .......................................................................................................................................275
D�datki.....................................................................................................277
Sk�r�widz .....................................................................................................................279
�lternatywne
wzorce trwałości
Rozum musi we wszystkich swych poczynaniach poddawać się krytyce. W przypadku
gdy ograniczy wolność krytyki przez zakaz, wyrządza krzywdę sam sobie, narażając się
na niszczące podejrzenia. Nic nie jest tak ważne z powodu swojej roli ani tak święte,
aby mogło być zwolnione z tych analiz, nie znających respektu dla żadnej z osób. Rozum zależy
od tej wolności przez samo swoje istnienie. Rozum nie ma dyktatorskiego autorytetu, zatem jego
werdykt jest zawsze porozumieniem wolnych obywateli, z których każdy musi mieć prawo
do wyrażania, bez nakłaniania lub przeszkadzania, swoich wątpliwości lub nawet sprzeciwu.
 �mmanuel Kant
Krytyka czystego rozumu
Wachlarz możliwości wyboru modelu trwalości dostępny dla projektanta aplikacji o skali
przedsiębiorstwa zawiera o wiele więcej możliwości, niż tylko zastosowanie modelu trwalo-
ści polecanego przez firmę Sun lub opracowanie wlasnego modelu. Ostatnio popularność
zyskują alternatywne modele trwalości. Dzieje się tak z kilku powodów:
" komponenty EJB są skomplikowane, mają duży rozmiar i wymagają zastosowania
serwera aplikacji;
" zastosowanie interfejsu JDBC jest czasochlonne i wymaga doświadczenia
w programowaniu baz danych;
" obiekty JDO to rozwiązanie nowe, które ciągle jeszcze nie jest dostępne we wszystkich
implementacjach.
Krótkie wyszukiwanie w internecie pozwoli na odnalezienie wielu alternatywnych syste-
mów trwalości. Dwa najpopularniejsze projekty to Castor JDO (niebędący implementacją
160 R�zdział 8. �lternatywne wz�rce trwał�ści
Wymagania programowe
Systemy Castor i Hibernate nie są standardową częścią platformy Javy. Z tego
powodu potrzebny jest zestaw tych narzędzi, obslugujący ich interfejsy AP�. Każdy
interfejs AP� charakteryzuje się innym zbiorem wymagań, o których więcej infor-
macji można znalez
ć w macierzystych witrynach obu projektów, odpowiednio:
Castor
http://castor.exolabs.com
Hibernate
http://hibernate.sf.net
specyfikacji Sun JDO) oraz Hibernate*. W tym rozdziale opisano projekty Castor i Hiber-
nate jako alternatywne narzędzia odwzorowań obiektowo-relacyjnych, wykorzystujące
język XML.
Dlaczego warto stosować
alternatywne szablony?
Filozofia Javy jest oparta na zasadzie przestrzegania standardów i rywalizowania w dzie-
dzinie implementacji. W świecie Javy należy przyjąć zasadę unikania odchodzenia od
standardów, chyba że standardy te nie spelniają wymagań. O modelach trwalości w Javie
trudno powiedzieć, że są tworzone wedlug przyjętych standardów. Jednym z powodów
rozbieżności poszczególnych modeli jest fakt, iż trudno stworzyć model trwalości, który
spelnialby wymagania każdej aplikacji. Każde podejście do trwalości wymaga podejmowa-
nia decyzji projektowych, które zmuszają do rezygnacji z wlaściwości funkcjonalnych
udostępnianych przez inne systemy.
Każdy alternatywny szablon ma określone zalety, z których warto skorzystać w progra-
mowaniu baz danych. Ogólnie, alternatywne szablony charakteryzują się następującymi
wlaściwościami:
" Możliwość spelnienia specyficznych wymagań, niespelnionych w standardach EJB i JDO.
" Systemy Castor i Hibernate, podobnie jak EJB i JDO do odwzorowań trwalości
wykorzystują pliki deskryptorów XML. Takie rozwiązanie doskonale nadaje się
do utworzenia zrozumialego pliku odwzorowania, opisującego zlożone relacje
w bazie danych.
" Alternatywne systemy zaprezentowane w tym rozdziale pozwalają
na zminimalizowanie rozmiaru kodu, jaki musi utworzyć programista po to,
aby utrwalić obiekty.
*
źbydwa są prżjektami open source dżstępnymi w witrynie SourceForge (http://www.sourceforge.net).
Dlaczeg� wart� st�s�wać alternatywne szabl�ny? 161
Model  open source
Model open source to sposób rozpowszechniania oprogramowania, oparty na filo-
zofii gloszącej, że użytkownicy oprogramowania mają prawo do posiadania kodu
z
ródlowego tego oprogramowania oraz prawo do jego modyfikowania. Chociaż
często model ten jest utożsamiany z oprogramowaniem darmowym, to oprogra-
mowanie tego typu może, ale nie musi być darmowe.
Oprogramowanie open source ma następujące zalety:
" Możliwość większej kontroli nad oprogramowaniem wlącznie z możliwością
jego usprawniania bez konieczności oczekiwania na poprawę blędu przez
producenta.
" Ze względu na dużą liczbę programistów zaangażowanych w tworzenie takich
programów, oprogramowanie open source zwykle charakteryzuje się bardziej
zróżnicowanym zapleczem programowym od oprogramowania komercyjnego.
" Oprogramowanie open source, nawet jeśli nie jest darmowe, jest zazwyczaj
tańsze od komercyjnego. Wynika to stąd, że modele biznesowe firm
zajmujących się produkcją takiego oprogramowania są zorientowane przede
wszystkim na uslugi związane z obslugą systemów.
Z drugiej strony, oprogramowanie open source nie jest pozbawione wad:
" Serwis techniczny oprogramowania często zależy od woli jego programistów,
a nie jest gwarantowany umową serwisową.
" Wydania oprogramowania open source, nad którym nie pracuje zbyt duża
grupa programistów, są niespójne a nawet podatne na dlugie okresy
niestabilności.
" Korzyści wynikające z większej kontroli nad oprogramowaniem mogą okazać
się fikcyjne, jeżeli utracimy możliwość utrzymania wprowadzonych modyfikacji.
" Systemy alternatywne opisane w tym rozdziale to produkty open source. W związku
z tym charakteryzują się wszystkimi zaletami i wadami narzędzi tego typu.
ęlternatywne szablżny trwalżści należy stżsżwać w aplikacjach przeznaczżnych
Najlepsze
rozwiązanie
dla żdbiżrców, których pżdstawżwym wymaganiem są niskie kższty żraz aplikacjach
ż specyficznych wymaganiach, jeżeli takie wymagania spelniają systemy alternatywne.
Alternatywne systemy trwalości mają również swoje wady:
" �ch interfejsy AP� zapewniające funkcje trwalości są tym, na co wskazuje nazwa
 alternatywą. �nterfejsy te nie przestrzegają uznanych standardów, takich jak
EJB 1.1, EJB 2.0, czy JDO.
162 R�zdział 8. �lternatywne wz�rce trwał�ści
" Alternatywne systemy trwalości nie zapewniają stosowania systemu transakcji
zarządzanych przez kontenery, podobnego do tego, jaki oferuje kontener EJB.
W przypadku komponentów EJB wyznaczenie ram transakcji odbywa się
automatycznie po zdefiniowaniu atrybutów transakcji w deskryptorze instalacji
a kontener wymusza ścisle przestrzeganie tych ram.
Nie należy stżsżwać alternatywnych szablżnów trwalżści dla aplikacji, które są
Najlepsze
rozwiązanie
przeznaczżne dż wdrżżenia w wielu śrżdżwiskach kżrpżracyjnych. W takich
śrżdżwiskach przestrzeganie standardów jest kluczżwym czynnikiem,
pżzwalającym na zdżbycie zaufania żsób żdpżwiedzialnych za żbslugę aplikacji.
Sposób realizacji funkcji trwałości
Podobnie jak we wszystkich innych zautomatyzowanych systemach trwalości opisywanych
w tej książce, w systemach Castor i Hibernate atrybuty komponentów są utrwalane na
podstawie pliku konfiguracyjnego XML, zawierającego definicje odwzorowania trwalości.
W tabeli 8.1 wyszczególniono atrybuty dwóch obiektów biznesowych, które mogą zostać
utrwalone w bazie danych.
Tabela 8.1. Atrybuty dwóch obiektów biznesowych wraz z typami odwzorowania
Klasa �trybut Typ
Author AuthorID Long
firstName String
lastName String
Publications List
Book bookID Long
Author Author
Title String
Chżciaż w każdym z szablżnów wszystkie żdwzżrżwania trwalżści mżżna umieścić
Najlepsze
rozwiązanie
w jednym pliku XML, należy żgraniczać żbjętżść każdegż pliku XML, tak aby
żpisywal żdwzżrżwania pżjedynczej klasy.
Kod klasy Author opisanej w tabeli 8.1 znajduje się na listingu 8.1.
Listing 8.1. Trwała klasa Author
package book;
import java.util.Set;
public class Author {
private long authorID;
Sp�sób realizacji funkcji trwał�ści 163
private String firstName;
private String lastName;
private Set publications;
public long getAuthorID () {
return authorID;
}
public String getFirstName() {
return firstName;
}
public String getLastName() {
return lastName;
}
public Set getPublications () {
return publications;
}
public void setAuthorID (long id) {
authorID = id;
}
public void setFirstName(String fn) {
firstName = fn;
}
public void setLastName(String ln) {
lastName = ln;
}
public void setPublications (Set pubs) {
publications = pubs;
}
}
Ta klasa biznesowa jest bardzo prosta  zawiera wylącznie metody pobierające i ustawiają-
ce atrybuty. Nie zawiera kodu utrwalania. Zasadniczy kod dla klasy Book przedstawiono
na listingu 8.2.
Listing 8.2. Obiekt wartości Book zawierający odwołanie do obiektu wartości Author
package book;
public class Book {
private Author author;
private long bookID;
private String title;
public Author getAuthor () {
return author;
}
public long getBookID () {
return bookID;
}
public String getTitle () {
164 R�zdział 8. �lternatywne wz�rce trwał�ści
return title;
}
public void setAuthor (Author auth) {
author = auth;
}
public void setBookID (long id) {
bookID =id;
}
public void setTitle(String ttl) {
title = ttl;
}
}
Odwzorowania pól w systemie Castor
Kluczowym elementem trwalości w systemach Castor i Hibernate jest plik XML. Każdy
interfejs AP� zawiera wlasny język, slużący do definiowania odwzorowań pomiędzy obiek-
tami a tabelą. Na listingu 8.3 pokazano sposób odwzorowania obiektów biznesowych do
bazy danych.
Listing 8.3. Plik XML deskryptora odwzorowania w systemie Castor

//EN" "http://castor.exolab.org/mapping.dtd">





























Sp�sób realizacji funkcji trwał�ści 165
Dla każdej klasy, która ma zostać odwzorowana w deskryptorze XML, umieszcza się
znacznik class*. Znacznik ten ma następujące znaczenie:
" określa nazwę odwzorowywanej klasy Javy;
" określa nazwę atrybutu tożsamości (atrybut niepowtarzalnie identyfikujący
egzemplarz klasy);
" jest narzędziem generowania kluczy, które można wykorzystać do otrzymywania
identyfikatorów. W obu systemach, zarówno Castor, jak i Hibernate istnieje kilka
sposobów generowania niepowtarzalnych wartości.
Należy wybrać taką metżdę generżwania sekwencji, która najlepiej żdpżwiada
Najlepsze
rozwiązanie
wybranemu szablżnżwi trwalżści.
System Castor obsluguje następujące algorytmy generowania kluczy:
HIGH-LOW
W tym algorytmie wykorzystano mechanizm podobny do opracowanego przez
Autora algorytmu generowania sekwencji, który opisano w rozdziale 4. Algorytm
wymaga specjalnej tablicy sekwencji, której klucze są nazwami tabel oraz której
kolumny są wartościami zarodków używanych do generowania sekwencji. Więcej
informacji na temat wartości zarodków można znalez
ć w części poświęconej
generowaniu sekwencji, w rozdziale 4.
IDENTITY
Generowana wartość wykorzystuje liczbę uzyskaną przez zastrzeżony mechanizm
generowania kluczy dla wybranej bazy danych. Do obslugiwanych baz danych
należą Hypersonic SQL, MS SQL Server, MySQL oraz Sybase ASE/ASA.
MAX
Wygenerowana wartość jest o jeden większa od maksymalnej wartości
przechowywanej w bazie danych.
SEQUENCE
Generowana wartość wykorzystuje mechanizm SEQUENCE baz danych �nterbase,
Oracle, PostgreSQL oraz SAP DB.
UUID
Ten algorytm generuje globalną unikalną wartość na podstawie adresu �P, bieżącego
czasu systemowego w milisekundach oraz statycznego licznika.
*
Użycie slżwa class pżwżduje, że ten dialekt XML jest technicznie niedżzwżlżny, gdyż class
jest zastrzeżżnym slżwem języka XML.
166 R�zdział 8. �lternatywne wz�rce trwał�ści
Algorytmy SEQUENCE oraz HIGH-LOW wymagają podania parametrów. Parametry te
można określić wykorzystując znacznik key-generator, umieszczony poza znacznikiem
class:






Należy stżsżwać algżrytm generżwania kluczy HIGH-LźW.
Najlepsze
rozwiązanie
W obszarze otoczonym znacznikami znajduje się zbiór znaczników,
które definiują odwzorowania atrybutów klas do bazy danych. Pierwszy znacznik w gru-
pie to map-totable. Tak jak sugeruje jego nazwa, określa on nazwę tabeli bazy danych,
do której należy odwzorować klasę opisywaną przez znacznik.
Pozostale znaczniki zawierają wlaściwe definicje odwzorowań pól na kolumny. Warto
zwrócić szczególną uwagę na znacznik odwzorowujący relację klasy Author z klasą Book.
Zamiast definiowania kolumny w tabeli AUTHOR zdefiniowano atrybut w obrębie klasy
Book. System Castor wykorzystuje odwzorowanie tej kolumny w celu zrealizowania odpo-
wiednich powiązań.
Odwzorowania pól w systemie Hibernate
Odwzorowania pól w systemie Hiberanate są podobne. Na listingu 8.4 pokazano deskryp-
tor XML definiujący odwzorowanie przykladowych klas do bazy danych.
Listing 8.4. Deskryptor XML odwzorowań pól w systemie Hibernate

//EN" "http://hibernate.sourceforge.net/hibernate-mapping-1.1.dtd">
















Sp�sób realizacji funkcji trwał�ści 167



Kod odwzorowań w systemie Hibernate jest podobny do kodu odwzorowań w systemie
Castor. �stnieje jednak wiele istotnych różnic. Podobnie, jak w systemie Castor, do zdefi-
niowania odwzorowań trwalości dla określonych klas Javy, w systemie Hibernate wyko-
rzystuje się znacznik class. �naczej niż w systemie Castor, w systemie Hibernate zdefi-
niowano odwzorowania tabel jako atrybut znacznika. Wewnątrz znacznika class należy
określić identyfikator, wlaściwości oraz zbiór klas. Znacznik id opisuje generator wyko-
rzystywany do generowania kluczy. W znaczniku tym definiuje się klasę Javy zajmującą
się wykonywaniem algorytmu generowania. Jeżeli algorytm wymaga podania parametrów,
można je określić w treści znacznika generator, jako znacznik param:

sequence

Klasa generator jest implementacją klasy cirrus.hibernate.id.IdentifierGene
rator. W systemie Hibernate dostępne są następujące wbudowane generatory:
assigned
Umożliwia aplikacji generowanie wlasnych identyfikatorów.
hilo.hex
Algorytm identyczny z hilo.long, poza tym, że w wyniku jego dzialania uzyskuje
się ciąg 16 znaków.
hilo.long
Generuje niepowtarzalne wartości typu long wykorzystując algorytm HIGH-LOW.
Nie należy stosować tego generatora w środowiskach JTA lub do polączeń
definiowanych przez użytkownika.
native
Generuje niepowtarzalną wartość na podstawie kolumn identyfikatorów dla baz
danych DB2, MS SQL Server, MySQL, Sybase oraz Hypersonic SQL.
seqhilo.long
Generuje niepowtarzalną wartość typu long dla sekwencji, której przypisano nazwę,
z wykorzystaniem algorytmu HIGH-LOW.
sequence
Generuje niepowtarzalną wartość wykorzystując konstrukcję SEQUENCE dostępną
w bazach danych DB2, �nterbase, Oracle, PostgreSQL i SAP DB.
uuid.hex
Generuje niepowtarzalny ciąg skladający się z 32 znaków.
168 R�zdział 8. �lternatywne wz�rce trwał�ści
uuid.string
Dzialanie identyczne z uuid.hex, poza tym, że generowany jest szesnastoznakowy
ciąg ASC��. Tego algorytmu nie należy stosować dla bazy danych PostgreSQL.
vm.hex
Generuje niepowtarzalne ciągi znaków na podstawie liczb heksadecymalnych.
Tego algorytmu nie należy używać w architekturze klastra.
vm.long
Generuje niepowtarzalne wartości typu long. Algorytmu nie należy stosować
w architekturze klastra.
W większżści platfżrm trwalżści dżstępnych jest kilka mechanizmów generżwania
Najlepsze
rozwiązanie sekwencji. Ważne, aby wykżrzystywać taki mechanizm generżwania sekwencji,
który najlepiej żdpżwiada wysżkżpżziżmżwym wymaganiżm architektury
(np. pżdzial na klastry).
Wlaściwości są zasadniczymi atrybutami klasy. Z kolei zbiory reprezentują odwzorowania
jeden-do-wielu lub wiele-do-wielu dla klasy. W opisywanym przypadku obiekty odwzo-
rowują jednego autora na wiele książek. W systemie Hibernate relację tę można określić
za pomocą znacznika set.
W systemie Hibernate dostępnych jest sześć różnych znaczników kolekcji:
"
"
"
"