Implementacja reguł integralności w XML-owych bazach danych

Pełen tekst

(1)Zeszyty Naukowe nr. 798. Uniwersytetu Ekonomicznego w Krakowie. 2009. Dariusz Put 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 informacji w Internecie są wyszukiwarki. Programy te w odpowiedzi na parametry wskazane przez użytkownika zwracają odnośniki do stron internetowych, czasem już nieistniejących, a w większości przypadków zawierających treści anonimowe, niesprawd zone, o wątpliwej wiarygodności..

(2) 44. Dariusz Put. 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 kluczowych. 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 zawartych 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 semantycznych dla poszczególnych dziedzin. Dzięki temu możliwa stała się wymiana dokumentów tekstowych między ludźmi zajmującymi się daną dziedziną. Dokumenty 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ć odpowiednie informacje. Dokumenty tekstowe zamieszczane na stronach internetowych lub przesyłane pom ięd zy 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 obejmują 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 rzeczywistości, ustalania reguł integralności, optymalizacji zapytań czy bezpieczeństwa danych. Zanim XML-owe bazy danych będą powszechnie wykorzystywane lub nawet będą sta nowić konkurencję dla modeli relacyjnych, istnieje potrzeba znalezienia rozwiązań dla szeregu zagadnień. Jednym z nich jest konieczność opracowania odpowiednich mechanizmów umożliwiających implementację 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ójne i aktualne. W procesie projektowania należy rozpoznać własności i ograniczenia dotyczą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 pojawiał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);.

(3) Implementacja reguł integralności…. 45. – aplikacyjne, które wpisane są w logiczny projekt bazy danych, lecz nie mogą być elementem 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 przechowywanych 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 zawierały sensowne wartości; – niepodzielność danych – pierwsza postać normalna mówi, że w bazie danych mogą znajdować 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 umiesz czanymi 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ę rekordó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 usun ięcia rekordu z tabeli podstawowej, gdy w tabeli związanej istnieją powiązane rekordy;.

(4) Dariusz Put. 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 pola innej tabeli; mechanizm ten jest przydatny do zachowania jednoznaczności danych; – transakcje traktujące szereg modyfikacji bazy danych tak, jakby to była jedna modyfikacja. Możliwość zastosowania technologii XML w charakterze SZBD jest uzależniona od istnienia mechanizmu pozwalającego, jak w przypadku relacyjnych lub obiektowych baz danych, na utworzenie fizycznego projektu bazy danych. Istnieją dwie podstawowe technologie, które umożliwiają zdefiniowanie schematu dokumentu, a tym samym określenie własnoś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 danych1. W XSD występują trzy rodzaje Pierwsza postać normalna mówi, że atrybuty przechowywane w polach bazy danych muszą być niepodzielne (atomowe). 1.

(5) 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ązaniem umożliwiającym utworzenie 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 dowolna2: <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 charakteryzujących je atrybutów jest uporządkowany, czy nie, a nieupo rządkowany zbiór elementów może być trudniejszy do przetwarzania, w praktyce często wykorzystywana bywa grupa sequence. 2.2. Typy pól. W tradycyjnych SZBD zdefiniowanych jest kilka typów prostych. Wartości wpisywane 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 atrybutó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..

(6) 48. Dariusz Put. – adres URI (anyURI), – definiującego język narodowy (language). Typ nadawany jest w definicji elementu, jak w poniższym przykładzie, w którym element 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 schematem: <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 dotyczące wartości domyślnej nie mają zastosowania: <a>Książka</a> <e>562</e> 66 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> 66 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”>.

(7) Implementacja reguł integralności…. 49. Występowanie w dokumencie elementu <a> jest obowiązkowe (minOccurs i maxOccurs są równe 1), a elementu opcjonalne (minOccurs jest równe 0, a maxOccurs 1). Schemat XSD pozwala na tworzenie modeli zawartości. Dzięki temu istnieje możliwość zdefiniowania grupy elementów i nadania całej grupie atrybutu wymagalności lub wskazania, ż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> </xsd:complexType> W skład zdefiniowanego typu złożonego wchodzą trzy elementy stanowiące sekwencję. W dokumencie 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 dopuszczalnych 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 ograniczenia 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ć elementowi 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-.

(8) 50. Dariusz Put. 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 wykorzystać parametry minInclusive i maxInclusive ograniczające zakres wpisy wanych wartości. Oznaczają one odpowiednio minimalną i maksymalną wartość, jaką można przypisać elementowi. 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 zdarzenia (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 wszystkie cechy klucza podstawowego 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..

(9) Implementacja reguł integralności…. 51. 2.8. Maska wprowadzania. W XSD zdefiniowano szeroką gamę rozwiązań ułatwiających ustalenie formatu wartości przypisywanych elementom. Można w tym celu wykorzystać wyrażenia regularne. W tym zakresie 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. Element 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 wykorzystywany do przechowywania danych o klientach: <xsd:complexType name=”tklient”>. <xsd:all>. <xsd:element name=”idKlienta” type=”xsd:positiveInteger”/>.

(10) 52. Dariusz Put. <xsd:element name=”nazwaKlienta” type=”xsd:string”/>. …. </xsd:all> </xsd:complexType>. 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> </xsd:complexType> 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 zawierają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> </xsd:complexType> 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.

(11) 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 rozwiązanie jest także dopuszczalne w relacyjnych bazach danych. 2.10. Stopień uczestnictwa. W tradycyjnych bazach danych stopień uczestnictwa jest aplikacyjną regułą integralnoś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 przyk ł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 maksymalna 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 zdarzenia zarejestrowane w tabeli macierzystej. Niekiedy występuje sytuacja, że fakty zapisane w tej tabeli mogą być dodatkowo charakteryzowane przez dwa wykluczające się zbiory atrybutó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> <xsd:complexType name=”pracownikEtatowy”>. <xsd:element name=”placaBrutto” type=”xsd:decimal”/>. <xsd:element name=”stanowisko” type=”xsd:string”/> </xsd:complexType>.

(12) 54. Dariusz Put. <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:complexType> </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 wskazują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 zarejestrowania pracownika bez wskazania charakteru zatrudnienia, nie można też przypisać pracownikowi danych charakteryzujących zarówno pracowników etatowych, jak i sezonowych. 3. Przykład praktycznego zastosowania Do zobrazowania zaprezentowanych zagadnień wybrano fragment bazy danych składają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 zdefiniowano klucze podstawowe (odpowiednio idCzytelnika, idWypozyczenia). Wykorzystano różne typy danych zgodne z typem przechowywanych wartości. Elementy zawierające datę (dataUrodzenia, dataWypozyczenia, dataZwrotu) są typu tdata, w którym zdefiniowano maskę wprowadzania postaci rrrr‑mm‑dd, dzięki czemu wszystkie daty w dok umencie XML muszą mieć ten format. Zdefiniowano także maskę wprowadzania dla kodu pocztowego 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-.

(13) Implementacja reguł integralności…. 55. menty kodPocztowy oraz dataZwrotu są opcjonalne (minOccurs=”0”), pozostałe mają ustawiony atrybut wymagalności. Dla pola typCzytelnika utworzono zbiór dopuszczalnych wartości – w dokumencie XML elementowi temu można przypisać wyłącznie jedną z trzech wartości: pracownik, student lub uczen.. Nazwisko Data urodzenia Adres: ulica, kod pocztowy, miejscowość. Id czytelnika (KP). Czytelnik. (1, 1). Id Wypożyczenia (KP) (0, 10). Id książki. Wypożyczenie Data wypożyczenia. Typ czytelnika: (pracownik, student, uczeń). Data zwrotu. 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:complexType> <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>.

(14) 56. Dariusz Put. <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> <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> <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:complexType> <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”>.

(15) 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 projektowania bazy danych, jest zapewnienie integralności danych, czyli podjęcie działań przyczyniających się do poprawności przechowywanych danych. Pozwoli to uniknąć nieprawidłowoś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 wykorzystywana m.in. do opisu znaczenia danych umieszczanych w dokumentach tekstowych wymienianych między organizacjami 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 elementach, zdefiniowano również mecha nizm będący odpowiednikiem tabel walidacji, które zapewniają jednoznaczność.

(16) Dariusz Put. 58. danych. Można także ustawić atrybut unikalności3 oraz wskazać element odgrywający rolę klucza podstawowego. 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 napisanie 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 implementacja 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 kompletnego języka zapytań oraz mechanizmów optymalizacji zapytań uwzględniających konieczność współbieżnego przetwarzania danych oraz dostosowanych do tekstowego charakteru 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.. 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. 3.

(17)