Zeszyty Naukowe nr 798 Uniwersytetu Ekonomicznego w Krakowie 2009 Katedra Systemów Obliczeniowych Implementacja reguł integralności w XML-owych bazach danych Streszczenie. Technologia XML jest wykorzystywana do opisu i wymiany danych i dokumentów tekstowych. Jej istota polega na połączeniu danych z ich semantyką oraz oddzieleniu formy od treści. Przyjęcie takiego rozwiązania daje możliwość zdefiniowana podstaw modelu bazodanowego opartego na tej technologii. Wiąże się to jednak z koniecznością uwzględnienia szeregu zagadnień znanych z teorii baz danych. Należy tu wymienić przede wszystkim operowanie na danych w warunkach współbieżności dostępu oraz zapewnienie poprawności i spójności danych. To ostatnie zagadnienie, obejmujące szereg szczegółowych rozwiązań, znane jest w teorii baz danych pod nazwą reguł integralności. W artykule omówiona została możliwość wykorzystania technologii XML do implementacji reguł integralności. Na podstawie zaprezentowanych mechanizmów popartych przykładami praktycznymi dokonano porównania języka XML i relacyjnych baz danych w tym zakresie. Słowa kluczowe: XML, XSD, XML Schema, bazy danych, reguły integralności. 1. Wprowadzenie W zasobach internetowych można znaleźć informacje niemal na każdy temat. Użytkownicy Internetu, zarówno osoby fizyczne, jak i instytucje, publikują różnorodne treści, mające najczęściej formę opartą na składni języka HTML, który został stworzony głównie w tym celu, aby możliwe było nadanie prezentowanym zasobom odpowiedniego wyglądu. Dokument HTML zawiera więc informacje, zwykle tekstowe, oraz znaczniki formatujące. Jedynym narzędziem wspomagającym proces poszukiwania infor ma cji w Internecie są wyszu kiwarki. Programy te w odpowiedzi na parametry wskazane przez użytkownika zwracają odnośniki do stron internetowych, czasem już nieist niejących, a w większości przypadków zawie rających treści anonimowe, niespraw dzone, o wątpliwej wiarygodności.
44 Poszukiwanie żądanych informacji w dalszym ciągu wymaga od użytkownika dodatkowego, często znacznego nakładu pracy. Wybierając odnośniki, programy te korzystają m.in. z atrybutu name= keywords elementu <META>, zawierającego listę słów kluczo wych. Aby przyciągnąć jak największą rzeszę użytkowników, autorzy stron niejednokrotnie umieszczają w tym elemencie słowa kluczowe luźno związane z tematyką strony lub niemające z nią w ogóle nic wspólnego, co dodatkowo komplikuje proces wyszukiwania. Aby treści zamieszczane w zasobach internetowych mogły być wiarygodne oraz aby odpowiednie oprogramowanie (tzw. agenty) było w stanie efektywnie je przeszukiwać w celu znalezienia konkretnej informacji, trzeba oddzielić treść dokumentu od jego formy oraz uzupełnić treść o elementy semantyczne opisujące znaczenie informacji za war tych w dokumencie. Efektem podjętych w tym zakresie prac było powstanie technologii XML oraz opartego na niej języka RDF, pozwalającego na definiowanie znaczników seman tycz nych dla poszczególnych dziedzin. Dzięki temu możliwa stała się wymiana do kumentów tekstowych między ludźmi zajmującymi się daną dziedziną. Doku menty takie, zawierające treści wraz z opisującymi je powszechnie znanymi znacznikami, mogą być analizowane przez ludzi, gdyż mają formę tekstu, a także oprogramowanie, które w tak uporządkowanym pliku jest w stanie wyszukać odpo wiednie informacje. Dokumenty tekstowe zamieszczane na stronach internetowych lub przesyłane po mię dzy użytkownikami w takiej formie mogą być traktowane jako zbiory danych, a nawet swego rodzaju bazy danych. Relacyjne bazy danych, mimo zauważanych wad, nadal obej mują swym zasięgiem większość praktycznych zastosowań. Ich popularność wynika z faktu, że oparte są na solidnych podstawach teoretycznych: dobrze rozwiązane są zagadnienia modelowania rze czywistości, ustalania reguł integralności, optymalizacji zapytań czy bezpieczeństwa danych. Zanim XML-owe bazy danych będą powszechnie wykorzystywane lub nawet będą stanowić konkurencję dla modeli relacyjnych, istnieje potrzeba znalezienia rozwiązań dla szeregu za gadnień. Jednym z nich jest konieczność opracowania odpowiednich mecha nizmów umożli wiających imple mentację reguł integralności. Pod tym pojęciem rozumie się ogół działań przyczyniających się do tego, aby dane przechowywane w bazie danych były poprawne, spój ne i aktualne. W procesie projektowania należy rozpoznać własności i ogra niczenia do ty czące danych zapisywanych w bazach danych, ustalić charakter powiązań mię dzy nimi oraz podjąć wszelkie działania zmierzające do tego, aby podczas eksploatacji nie poja wiały się błędy. W teorii relacyjnych baz danych wyróżnia się dwa typy reguł integralności: bazodanowe, które można wpisać w fizyczny projekt bazy danych, dzięki czemu ich przestrzeganie kontrolowane jest przez systemy zarządzania bazami danych (SZBD);
Implementacja reguł integralności 45 aplikacyjne, które wpisane są w logiczny projekt bazy danych, lecz nie mogą być ele mentem projektu fizycznego. Wymagają napisania procedur, które podczas eksploatacji bazy danych będą sprawdzać ich przestrzeganie. Ze względu na segment bazy danych, którego dotyczą, reguły integralności można podzielić na: 1. Reguły dotyczące pól: typ pola każde pole musi być typu zgodnego z typem przechowywa nych w nim wartości oraz wszystkie pola zawierające ten sam rodzaj wartości (np. nazwisko_klienta, nazwisko_pracownika) muszą być tego samego (lub zgodnego) typu oraz tego samego rozmiaru (postulat ten dotyczy przede wszystkim pól tekstowych i liczbowych); maska wprowadzania ułatwia wprowadzanie danych do pola i zapewnia zgodność wpisanej wartości z ustalonym formatem; wartość domyślna ustalana jest dla pól, które dla większości rekordów mają takie same wartości; reguły poprawności dla pól określają dodatkowe ograniczenia dla wartości wpisywanych do pola (np. rabat <= 10%), przy czym w tego rodzaju regułach nie można odwo ływać się do wartości zapisanych w innych polach tabeli; wymagalność ustalana jest dla tych pól tabeli, które muszą być wypełnione, aby rekordy za wierały sensowne wartości; niepodzielność danych pierwsza postać normalna mówi, że w bazie danych mogą znaj do wać się wyłącznie wartości atomowe; ułatwia to operowanie na danych i kontrolę ich poprawności. 2. Reguły dotyczące tabel: reguły poprawności dla tabel określają relacje między wartościami umieszcza nymi w różnych polach tej samej tabeli (np. data_zamówienia <= data_realizacji); klucze podstawowe zapewniają niepowtarzalność i jednoznaczną identyfikację obiektów i zdarzeń zarejestrowanych w tabelach bazy danych. 3. Reguły dotyczące relacji: typ relacji określający liczebność powiązań między rekordami znajdującymi się w po łą czonych tabelach; typ uczestnictwa tabel w relacji, który oznacza konieczność lub opcjonalność połączenia rekordu jednej tabeli z rekordem drugiej tabeli; stopień uczestnictwa tabel w relacji wskazujący minimalną i maksymalną liczbę rekor dów jednej tabeli, które mogą być powiązane z pojedynczym rekordem drugiej tabeli; reguły usuwania informujące, w jaki sposób ma zareagować system w razie próby usu nię cia rekordu z tabeli podstawowej, gdy w tabeli związanej istnieją powiązane rekordy;
46 reguły modyfikacji opisujące, co ma się zdarzyć przy próbie zmiany wartości w polu będącym kluczem podstawowym, gdy w tabeli związanej występują powiązane rekordy. 4. Reguły dotyczące bazy danych: tabele walidacji zawierają wszystkie dopuszczalne wartości, które można wpisać do po la innej tabeli; mechanizm ten jest przydatny do zachowania jednoznaczności danych; transakcje traktujące szereg modyfikacji bazy danych tak, jakby to była jedna mody fikacja. Możliwość zastosowania technologii XML w charakterze SZBD jest uzależniona od istnienia mechanizmu pozwalającego, jak w przypadku rela cyjnych lub obiektowych baz danych, na utworzenie fizycznego projektu bazy danych. Istnieją dwie podstawowe techno logie, które umożliwiają zdefiniowanie schematu dokumentu, a tym samym określenie włas ności danych oraz powiązań między nimi: definicja typu dokumentu (DTD Document Type Definition), XML Schema (XSD Extensible Stylesheet Definition). DTD została zdefiniowana jako pierwsza. Ponieważ standard ten obejmuje rozwią zania umożliwiające określenie tylko niektórych własności dokumentu XML, możliwości zastosowania tej technologii w charakterze opisu XML owych baz danych są ograniczone. Bardziej adekwatnym narzędziem jest XSD. Korzystając z tej technologii, można stworzyć definicję dokumentu, w której będą opisane istotne własności danych, dzięki czemu dokument XML, o ile zostanie stworzony na podstawie zdefiniowanego schematu, będzie zawierał odpowiednio powiązane dane, wolne od błędów oraz zgodne z ustalonymi regułami integralności. Dokument XML jest plikiem tekstowym o strukturze hierarchicznej. Zawiera jeden element główny oraz podelementy, które również mogą zawierać podelementy itd. Taka składnia pozwala na organizację danych podobną do tej stosowanej w tradycyjnych modelach relacyjnych. 2. Reguły integralności w technologii XML 2.1. Konstrukcja odpowiednika rekordu w XML-owej bazie danych W standardzie XSD opisany jest mechanizm pozwalający grupować elementy. Jeśli w grupie zostaną umieszczone wyłącznie elementy proste, może ona być odpowiednikiem rekordu relacyjnej bazy danych 1. W XSD występują trzy rodzaje 1 Pierwsza postać normalna mówi, że atrybuty przechowywane w polach bazy danych muszą być niepodzielne (atomowe).
Implementacja reguł integralności 47 grup: choice, sequence oraz all. Zastosowanie grupy choice wymaga, aby w dokumencie XML wystąpił dokładnie jeden element spośród wymienionych na liście. Z kolei elementy umieszczone w grupie sequence muszą wystąpić we wskazanej kolejności. Użycie grupy all wydaje się rozwią za niem umożliwiającym utwo rzenie odpowiednika rekordu w postaci najbardziej zbliżonej do jego definicji stosowanej w relacyjnym modelu danych. Każdy element grupy może wystą pić maksymalnie jeden raz, a ich kolejność jest dowolna 2 : <xsd:all> <xsd:element name= a type= xsd:string /> <xsd:element name= b type= xsd:integer minoccurs= 0 /> <xsd:element name= c type= xsd:date /> <xsd:element name= d type= xsd:string minoccurs= 0 /> </xsd:all> W dokumencie XML zgodnym z powyższym schematem muszą wystąpić elementy a i c, a mogą elementy b i d, dla których wyłączono atrybut wymagalności (minoccurs= 0 ). Wszystkie elementy mogą wystąpić najwyżej jeden raz, w dowolnej kolejności. Zgodnie z teorią relacyjnych baz danych pola rekordu nie muszą być uporządkowane taki efekt można osiągnąć w XML, stosując grupę all. Ponieważ jednak z punktu widzenia opisu danego obiektu bądź zdarzenia zwykle nie jest istotne, czy zbiór cha rak teryzujących je atrybutów jest uporządkowany, czy nie, a nieuporząd ko wany zbiór elementów może być trudniejszy do przetwarzania, w praktyce często wykorzy sty wana bywa grupa sequence. 2.2. Typy pól W tradycyjnych SZBD zdefiniowanych jest kilka typów prostych. Wartości wpisy wane w polach bazy danych są sprawdzane przez system pod kątem zgodności z typem pola. W tym zakresie w technologii XSD istnieją rozwiązania spełniające identyczną funkcję. Jednym z atry butów nadawanych elementom podczas ich definicji jest typ. Technologia XSD umożliwia zdefiniowanie m.in. elementów typu: łańcuch znakowy (m.in. string), liczba całkowita (np.: byte, unsignedinteger, integer, short, long), liczba rzeczywista (decimal, float, double), wartość logiczna (boolean), czas i data (time, date, datetime), 2 Wszystkie przykłady zamieszczone w niniejszym artykule zostały sprawdzone za pomocą walidatora rekomendowanego przez W3C, dostępnego na stronie internetowej http://apps.gotdotnet. com/xmltools/xsdvalidator/default.aspx.
48 adres URI (anyuri), definiującego język narodowy (language). Typ nadawany jest w definicji elementu, jak w poniższym przykładzie, w którym ele ment o nazwie a jest typu decimal, więc w dokumencie XML element <a> musi zawierać liczbę rzeczywistą: <xsd:element name= a type= xsd:decimal /> 2.3. Wartość domyślna W elementach XSD wartość domyślna wskazywana jest poprzez atrybut default. Element otrzymuje wartość, jaką nadano mu w dokumencie. Aby otrzymał wartość domyślną, w dokumencie należy mu przypisać wartość pustą. Gdy element nie występuje w dokumencie, definicja wartości domyślnej nie ma znaczenia. Zgodnie z poniższym sche matem: <xsd:element name= a... /> <xsd:element name= e type= xsd:integer default= 22 /> <xsd:element name= b... /> element <e> może otrzymać wartość nadaną w dokumencie XML, wtedy ustawienia doty czące wartości domyślnej nie mają zastosowania: <a>książka</a> <e>562</e> <b>66</b> lub wartość domyślną (równą 22 zgodnie z definicją w pliku XSD), jeśli dokument XML będzie miał postać: <a>książka</a> <e></e> <b>66</b> 2.4. Wymagalność W XML element może wystąpić dowolną liczbę razy. Parametr ten jest ustalany za pomocą atrybutów minoccurs (określa minimalną liczbę wystąpień) i maxoccurs (wskazuje maksymalną liczbę wystąpień). Standardowo obydwa parametry przyjmują wartość 1. Oznacza to, odmiennie niż w relacyjnych bazach danych, gdzie wymagalność należy ustawić w sposób jawny, że element zdefiniowany w XSD musi wystąpić dokładnie raz, czyli atrybut wymagalności jest ustawiony, jeśli nie podejmie się dodatkowej akcji. Aby go usunąć, trzeba użyć atrybutu minoccurs z wartością 0: <xsd:element name= a type= xsd:integer > <xsd:element name= b type= xsd:integer minoccurs= 0 >
Implementacja reguł integralności 49 Występowanie w dokumencie elementu <a> jest obowiązkowe (minoccurs i maxoccurs są równe 1), a elementu <b> opcjonalne (minoccurs jest równe 0, a maxoccurs 1). Schemat XSD pozwala na tworzenie modeli zawartości. Dzięki temu istnieje możli wość zdefiniowania grupy elementów i nadania całej grupie atrybutu wymagalności lub wskaza nia, że elementy muszą wystąpić w określonej kolejności: <xsd:complextype name= Adres /> <xsd:sequence> <xsd:element name= Ulica type= xsd:string /> <xsd:element name= KodPocztowy type= xsd:string /> <xsd:element name= Miejscowosc type= xsd:string /> </xsd:sequence> W skład zdefiniowanego typu złożonego wchodzą trzy elementy stanowiące sekwencję. W do ku mencie XML element typu Adres zawiera dokładnie trzy podelementy (Ulica, KodPocztowy i Miejscowosc), występujące w podanej kolejności. 2.5. Tabele walidacji Tabele walidacji (słownikowe) są tworzone w celu ograniczenia zakresu dopusz czalnych wartości wpisywanych w polu. Są zwykle związane z tymi polami tekstowymi, w których istotne jest, aby nie dopuścić do niejednoznaczności zapisu tej samej informacji, oraz z polami typu numerycznego, w których wartości mają charakter dyskretny. W XML zdefiniowano kilkanaście faz, wśród nich enumeration, używaną do ogra niczenia wybieranych wartości, mającą zastosowanie niemal do wszystkich typów (oprócz logicznego). Ograniczenie jest definiowane wewnątrz typu prostego: używając fazy enumeration, definiuje się wszystkie dopuszczalne wartości, które można przypisać elemen towi tego typu: <xsd:element name= Jednostka type= JednostkiMiary /> <xsd:simpletype name= JednostkiMiary > <xsd:restriction base: xsd:string > <xsd:enumeration value= sztuka /> <xsd:enumeration value= litr /> <xsd:enumeration value= kilogram /> </xsd:restriction> </xsd:simpletype> W powyższym przykładzie zdefiniowano element o nazwie Jednostka typu JednostkiMiary. Zgodnie z definicją typu element ten musi być łańcuchem zna-
50 kowym (string) i można mu przypisać wyłącznie jedną z trzech wartości: sztuka, litr lub kilogram. 2.6. Reguły poprawności Do definiowania reguł poprawności w XML-owych bazach danych można wyko rzy stać para metry mininclusive i maxinclusive ograniczające zakres wpi sywanych war tości. Ozna czają one odpowiednio minimalną i maksymalną war tość, jaką można przypisać elemen towi. Standard definiuje także parametry minexclusive i maxexclusive, które wykluczają wartości skrajne. W poniższym przykładzie: <xsd:simpletype name= dzien > <xsd:restriction base= xsd:integer > <xsd:mininclusive value= 1 /> <xsd:maxinclusive value= 31 /> </xsd:restriction> <xsd:simpletype> elementowi typu dzien można przypisać wyłącznie liczbę całkowitą z przedziału <1; 31>. 2.7. Klucz podstawowy Klucz podstawowy wskazuje się za pomocą znacznika key. W definicji elementu zło żonego zawierającego zbiór atrybutów charakteryzujących jednorodne obiekty lub zda rzenia (np. pracowników, książki, zamówienia) umieszcza się znacznik key zawierający dwa elementy: selektor wskazujący ścieżkę prowadzącą do pola będącego kluczem podstawowym (element selector) oraz nazwę tego elementu (field). W poniższym przykładzie zdefiniowano konstrukcję key o nazwie kp. Element zawierający atrybuty obiektów (klientów) nosi nazwę Klienci, a pole idklienta jest kluczem podstawowym: <xsd:key name= kp > <xsd:selector xpath= Klienci /> <xsd:field xpath= idklienta /> </xsd:key> Zgodnie z powyższą definicją idklienta będący podelementem elementu Klienci ma wszyst kie cechy klucza pod stawowego występującego w tradycyjnych systemach bazodanowych: wartości w tym elemencie dla wszystkich obiektów muszą być unikalne oraz nie mogą być równe Null.
Implementacja reguł integralności 51 2.8. Maska wprowadzania W XSD zdefiniowano szeroką gamę rozwiązań ułatwiających ustalenie formatu wartości przy pi sy wanych elementom. Można w tym celu wykorzystać wyrażenia regularne. W tym zakre sie technologia ta umożliwia m.in.: stosowanie znaków globalnych (gwiazdka, pytajnik), wybór jednego lub kilku spośród wskazanych znaków, wybór znaku oprócz znaków zabronionych, użycie znaku (lub znaków) wskazaną liczbę razy, zdefiniowanie formatu dla liczb. Przykład zawiera definicję typu prostego o nazwie cena: <xsd:simpletype name= cena > <xsd:restriction base= xsd:float > <xsd:totaldigits value= 8 /> <xsd:fractiondigits value= 2 /> </xsd:restriction> <xsd:simpletype> Element typu cena musi być liczbą rzeczywistą (float) o całkowitej długości ośmiu znaków, w tym dwa znaki po kropce dziesiętnej. Kolejny przykład zawiera definicję formatu wprowadzania dla kodu pocztowego. Ele ment typu kodpocztowy jest łańcuchem znakowym składającym się zawsze z dwóch cyfr, następnie kreski i trzech cyfr. <xsd:simpletype name= kodpocztowy > <xsd:restriction base= xsd:string > <xsd:pattern value= [0-9]{2}-[0-9]{3} /> </xsd:restriction> <xsd:simpletype> 2.9. Typ relacji W teorii baz danych zdefiniowano trzy typy relacji. Ze względu na to, że relacja wiele do wielu składa się z dwóch relacji jeden do wielu, w projekcie fizycznym występują tylko dwa typy. W XSD typ relacji można zdefiniować, wskazując minimalną i maksymalną liczbę elementów występujących w encji podrzędnej powiązanych z pojedynczym elementem encji nadrzędnej. W poniższym przykładzie zdefiniowano typ złożony o nazwie tklient, który będzie wyko rzy stywany do przechowywania danych o klientach: <xsd:complextype name= tklient > <xsd:all> <xsd:element name= idklienta type= xsd:positiveinteger />
52 <xsd:element name= nazwaklienta type= xsd:string /> </xsd:all>. Typ tzamowienie zawiera dane charakteryzujące zamówienia składane przez klientów: <xsd:complextype name= tzamowienie > <xsd:all> <xsd:element name= idzamowienia type= xsd:positiveinteger /> <xsd:element name= datazamowienia type= xsd:string /> </xsd:all> Klient może złożyć wiele zamówień, z których każde dotyczy dokładnie jednego klienta. Omawiany związek jest więc typu jeden do wielu, w którym elementy zawie rające dane o klientach odgrywają rolę nadrzędną. W technologii XSD relację można zdefiniować w postaci sekwencji elementów złożonych. W omawianym przypadku każdy taki element składa się z występujących jednokrotnie danych opisujących klienta oraz z dowolnej liczby elementów charakteryzujących zamówienia złożone przez tego klienta: <xsd:complextype name= tdane > <xsd:sequence> <xsd:element name= klient type= tklient /> <xsd:element name= zamowienie type= tzamowienie minoccurs= 0 maxoccurs= unbounded /> </xsd:sequence> Typ złożony tdane umożliwia przechowywanie danych o klientach oraz złożonych przez nich zamówieniach. Element klient musi wystąpić dokładnie jeden raz. Każdy element zamowienie jest związany z konkretnym klientem i może wystąpić dowolną liczbę razy. Nie występuje tu potrzeba definiowania kluczy obcych poszczególne elementy zamowienie, poprzez element główny typu tdane, są związane z konkretnym klientem, wiadomo więc, który klient złożył dane zamówienie. Należy jednakże zauważyć, że taka konstrukcja nie będzie mogła być wykorzystana w każdej sytuacji. W szczególności jeśli w bazie danych wystąpi wielokrotne zagnieżdżenie relacji lub trzy bądź większa liczba tabel będzie stanowić strukturę, w której każda tabela będzie pełniła funkcję podrzędnej, trzeba zastosować rozwiązanie oparte na jawnym wskazaniu klucza obcego (element keyref). Jeśli w definicji typu tdane usunięty zostanie parametr maxoccurs elementu zamowienie, związek klientów z zamówieniami będzie miał charakter relacji
Implementacja reguł integralności 53 jeden do jednego. W pliku XML w każdym elemencie typu tdane będzie musiał wystąpić element klient, a dane charakteryzujące zamówienie wystąpią najwyżej raz. Należy zauważyć, że relacja jeden do jednego może być zdefiniowana poprzez utworzenie jednego typu zawierającego wszystkie atrybuty obydwu encji: nadrzędnej i podrzędnej oraz usunięcie wymagalności dla elementów wchodzących w skład encji podrzędnej. Takie roz wiązanie jest także dopuszczalne w relacyjnych bazach danych. 2.10. Stopień uczestnictwa W tradycyjnych bazach danych stopień uczestnictwa jest aplikacyjną regułą inte gralności. W technologii XSD parametr ten można wpisać w schemat bazy danych poprzez okre ślenie wartości atrybutu maxoccurs dla elementu podrzędnego. W powyższym przy kładzie zawierającym definicję typu tdane wskazano, że z pojedynczym klientem może być związana dowolna liczba zamówień (maxoccurs= unbounded ). Jeśli w miejsce unbounded wpisana zostanie liczba całkowita n > 1, relacja będzie nadal typu jeden do wielu, ale maksy malna liczba powiązań klientów z zamówieniami będzie równa n. 2.11. Związek dwóch tabel-podzbiorów z tabelą główną W relacyjnych bazach danych tabele-podzbiory opisują temat innej tabeli w bardziej szczegółowy sposób. Zawierają atrybuty charakteryzujące tylko niektóre obiekty lub zda rzenia zarejestrowane w tabeli macierzystej. Niekiedy występuje sytuacja, że fakty zapisane w tej tabeli mogą być dodatkowo charakteryzowane przez dwa wykluczające się zbiory atry butów. Mówi się wtedy o związku wykluczającym się. Załóżmy, że organizacja zatrudnia pracowników etatowych i sezonowych. Dane o wszystkich pracownikach zapisywane są w tabeli pracownicy, dodatkowe dane określające charakter zatrudnienia znajdują się albo w tabeli pracownicy_etatowi albo pracownicy_sezonowi, nigdy w obydwu. Taka organizacja danych w dokumencie XML jest możliwa dzięki wykorzystaniu grupy choice. W definicji grupy podaje się zbiór elementów, spośród których w dokumencie może wystąpić dokładnie jeden: <xsd:complextype name= pracowniksezonowy > <xsd:element name= dataostatniegozatrudnienia type= xsd:date /> <xsd:element name= RodzajZatrudnienia type= xsd:string /> <xsd:complextype name= pracowniketatowy > <xsd:element name= placabrutto type= xsd:decimal /> <xsd:element name= stanowisko type= xsd:string />
54 <xsd:element name= pracownik > <xsd:complextype> <xsd:element name= idpracownika type= long />... <xsd:choice> <xsd:element name= sezonowy type= pracowniksezonowy /> <xsd:element name= etatowy type= pracowniketatowy /> </xsd:choice> </xsd:element> W powyższym przykładzie zdefiniowano dwa typy złożone (pracowniksezonowy i pracowniketatowy) zawierające po dwa przykładowe elementy proste. Pracownik jest opisywany przez idpracownika, inne atrybuty charakteryzujące wszystkich pracowników oraz atrybuty wska zujące, czy jest to pracownik etatowy, czy sezonowy. Ponieważ te dwa elementy wchodzą w skład grupy choice, w dokumencie XML może wystąpić dokładnie jeden z nich, co oznacza, że z każdym pracownikiem jest związana grupa atrybutów, które informują, czy pracownik jest zatrudniony na etacie, czy sezonowo. W tym rozwiązaniu nie ma możliwości zareje stro wania pracownika bez wskazania charakteru zatrudnienia, nie można też przypisać pra cow nikowi danych charakteryzujących zarówno pracow ników etatowych, jak i sezonowych. 3. Przykład praktycznego zastosowania Do zobrazowania zaprezentowanych zagadnień wybrano fragment bazy danych skła dający się z dwóch encji: czytelnik i wypożyczenie, połączonych relacją jeden do wielu. Schemat logiczny tego związku zamieszczono na rys. 1. Zgodnie z tym schematem encja czytelnik pełni funkcję nadrzędną. Stopień uczestnictwa pojedynczego czytelnika w relacji z wypożyczeniami wynosi (0; 10), co oznacza, że z każdym czytelnikiem może być związanych od 0 do 10 wypożyczeń. Stopień uczestnictwa encji wypożyczenie wynosi (1; 1), co jest najczęściej spotykanym rozwiązaniem dla tego typu relacji. Dla obydwu encji zdefi niowano klucze podstawowe (odpowiednio idczytelnika, idwypozyczenia). Wykorzystano różne typy danych zgodne z typem przechowywanych wartości. Elementy za wie ra jące datę (dataurodzenia, datawypozy czenia, datazwrotu) są typu tdata, w którym zdefinio wano maskę wprowadzania postaci rrrr mm dd, dzięki czemu wszystkie daty w do ku mencie XML muszą mieć ten format. Zdefiniowano także maskę wprowadzania dla kodu poczto wego w postaci cc-ccc (gdzie c oznacza dowolną cyfrę), uzyskując w ten sposób zapewnienie, że wszystkie kody pocztowe będą miały poprawną składnię. Pole miejscowosc ma wartość domyślną Krakow. Ele-
Implementacja reguł integralności 55 menty kodpocztowy oraz datazwrotu są opcjonalne (minoccurs= 0 ), pozostałe mają ustawiony atrybut wymagal ności. Dla pola typczytelnika utworzono zbiór do puszczalnych wartości w dokumencie XML elementowi temu można przypisać wyłącznie jed ną z trzech wartości: pracownik, student lub uczen. Nazwisko Id czytelnika (KP) Id Wypożyczenia (KP) Id książki Data urodzenia Czytelnik (1, 1) (0, 10) Wypożyczenie Adres: ulica, kod pocztowy, miejscowość Typ czytelnika: (pracownik, student, uczeń) Data zwrotu Data wypożyczenia Rys. 1. Projekt logiczny związku 1 pomiędzy czytelnikami i wypożyczeniami Źródło: opracowanie własne. Schemat XSD dla projektu logicznego bazy danych zobrazowanego na rys. 1 przedstawia się następująco: <xsd:schema xmlns:xsd= http://www.w3.org/2001/xmlschema > <xsd:element name= eg > <xsd:complextype> <xsd:sequence> <xsd:element name= dane type= tdane minoccurs= 0 axoccurs= unbounded /> </xsd:sequence> <xsd:key name= x1 > <xsd:selector xpath= dane/czytelnik /> <xsd:field xpath= idczytelnika /> </xsd:key> <xsd:key name= x2 > <xsd:selector xpath= dane/wypozyczenie /> <xsd:field xpath= idwypozyczenia /> </xsd:key> </xsd:element>
56 <xsd:complextype name= tczytelnik > <xsd:all> <xsd:element name= idczytelnika type= xsd:positiveinteger /> <xsd:element name= nazwiskoczytelnika type= xsd:string /> <xsd:element name= dataurodzenia type= tdata /> <xsd:element name= ulica type= xsd:string /> <xsd:element name= miejscowosc type= xsd:string default= Krakow /> <xsd:element name= kodpocztowy type= tkodpocztowy minoccurs= 0 /> <xsd:element name= typczytelnika type= ttypczytelnika /> </xsd:all> <xsd:complextype name= twypozyczenie > <xsd:all> <xsd:element name= idwypozyczenia type= xsd:positiveinteger /> <xsd:element name= idksiazki type= xsd:positiveinteger /> <xsd:element name= datawypozyczenia type= tdata /> <xsd:element name= datazwrotu type= tdata minoccurs= 0 /> </xsd:all> <xsd:complextype name= tdane > <xsd:sequence> <xsd:element name= czytelnik type= tczytelnik /> <xsd:element name= wypozyczenie type= twypozyczenie minoccurs= 0 maxoccurs= 10 /> </xsd:sequence> <xsd:simpletype name= tdata > <xsd:restriction base= xsd:date > <xsd:pattern value= [0-9]{4}-[0-9]{2}-[0-9]{2} /> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name= tkodpocztowy > <xsd:restriction base= xsd:string > <xsd:pattern value= [0-9]{2}-[0-9]{3} /> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name= ttypczytelnika > <xsd:restriction base= xsd:string >
Implementacja reguł integralności 57 <xsd:enumeration value= pracownik /> <xsd:enumeration value= student /> <xsd:enumeration value= uczen /> </xsd:restriction> </xsd:simpletype> </xsd:schema> 4. Wnioski Jednym z najistotniejszych zagadnień, które należy rozwiązać w procesie projekto wania bazy danych, jest zapewnienie integralności danych, czyli podjęcie działań przyczyniających się do poprawności przechowywanych danych. Pozwoli to uniknąć nieprawi dło wości i różnych anomalii podczas eksploatacji bazy danych oraz ułatwi zachowanie spójności i poprawności danych. Coraz większą popularnością cieszy się technologia XML, która jest powszechnie wyko rzystywana m.in. do opisu znaczenia danych umieszczanych w dokumentach tekstowych wymienianych między organi zacjami i ludźmi. Popularność zdobywa także koncepcja XML owych baz danych. Zanim jednak takie bazy danych staną się powszechne, trzeba rozwiązać w praktyce wiele zagadnień, choćby tych dobrze znanych w teorii modeli: relacyjnego i obiektowego. Jednym z nich są reguły integralności. W XML Schema, technologii służącej do opisu struktury dokumentu XML, stworzono możliwość deklarowania elementów oraz określania szeregu ich atrybutów, dzięki czemu, tworząc schemat XML-owej bazy danych, ustala się postać dokumentu opartego na definiowanym schemacie. Stanowi to podstawę do tworzenia rozwiązań, które wymuszą na twórcy dokumentu XML, lub osobie zarządzającej XML-ową bazą danych, przestrzeganie zdefiniowanych reguł integralności, a to z kolei będzie miało wpływ na poprawność i spójność danych. Na podstawie przeprowadzonych rozważań popartych praktycznymi przykładami można wyciągnąć wniosek, że zagadnienia integralności są dobrze rozwiązane w technologii XML. Zdefiniowane własności pozwalają na ustalenie reguł integralności, podobnie jak w modelu relacyjnym. W technologii XML istnieją różnorodne typy danych, których zakres jest przynajmniej porównywalny z tymi występującymi w bazach relacyjnych, a także możliwość definiowania wartości domyślnych, ustawiania atrybutu wymagalności czy reguł poprawności dla wartości występujących w poszczególnych ele mentach, zdefiniowano również me chanizm będący odpowiednikiem tabel walidacji, które zapewniają jednoznaczność
58 da nych. Można także ustawić atrybut unikalności 3 oraz wskazać element odgrywający rolę klucza pod stawowego. Maska wprowadzania oraz stopień uczestnictwa tabel w relacji to aplikacyjne reguły integralności, których nie można zaimplementować w większości tradycyjnych systemów bazodanowych. Do kontroli danych pod tym względem w trakcie eksploatacji bazy danych niezbędne jest na pisanie procedury. W XML obydwie te reguły można wpisać w schemat bazy danych. Także typ relacji jest ustalany w prosty sposób, poprzez określenie wartości jednego parametru. W opracowaniu zwrócono uwagę na jedno z rozwiązań nieklasycznych związek dwóch wykluczających się encji podrzędnych z encją nadrzędną. W XSD imple mentacja tego zagadnienia jest możliwa dzięki grupie choice. W tradycyjnych bazach danych zagadnienie tego typu musi być rozwiązane na poziomie aplikacyjnym. Mimo że technologia XML dobrze nadaje się do opisu reguł integralności, zanim XML-owe bazy danych będą powszechnie wykorzystywane, należy znaleźć rozwiązania szeregu innych problemów. Najistotniejsza wydaje się konieczność opracowania kom pletnego języka zapytań oraz mechanizmów optymalizacji zapytań uwzględniających ko niecz ność współbieżnego przetwarzania danych oraz dostosowanych do tekstowego cha rakteru dokumentów XML. Istotne są także zagadnienia transakcji oraz bezpieczeństwa danych przechowywanych w plikach tekstowych. Implementation of Integrality Rules in XML Data Bases The XML technology is applied to description and exchange of data and text documents. Its key features concern the connection between data and their semantics, and the separation between form and content. Such a solution delivers the possibility of defining a database model that is based on this technology. It is however necessary to take into consideration a number of issues that are known in databases theory. Main problems concern the operation on data in multi-access conditions and the matter of data correctness and consistency. The latter issue includes a number of detailed solutions and is known as integrality rules in the database theory. The article describes the possibility of utilisation of XML technology in integrality rules implementation. On the basis of presented tools and with support of practical examples, the comparison between XML language and relation databases in this area has been performed. 3 Zagadnienie to nie zostało omówione w opracowaniu. Unikalność w XML Schema jest ustawiana za pomocą elementu unique, którego składnia jest podobna do składni elementu key.