Page 1


Modelowanie danych w SQL Server 2005 i 2008. Przewodnik Autor: Eric Johnson, Joshua Jones T³umaczenie: Wojciech Moch ISBN: 978-83-246-2090-6 Tytu³ orygina³u: A Developer's Guide to Data Modelling for SQL Server. Covering SQL Server 2005 and 2008 Format: 168x237, stron: 280 Twórz wydajne modele danych! • Jakie techniki modelowania danych warto stosowaæ? • Jakie jest znaczenie procesu normalizacji? • Jak rozwi¹zaæ typowe problemy w trakcie modelowania?

Model danych jest niezwykle istotnym etapem tworzenia systemu informatycznego, poniewa¿ rzutuje on bezpoœrednio na wydajnoœæ rozwi¹zania oraz komfort pracy programisty. Warto zatem poznaæ najlepsze techniki modelowania danych i wszystkie zwi¹zane z nimi procesy. Dziêki tej ksi¹¿ce zrozumiesz podstawowe techniki modelowania danych oraz dowiesz siê, jak gromadziæ wymagania dotycz¹ce modelu. Ponadto zapoznasz siê z elementami wykorzystywanymi w logicznych i fizycznych modelach danych. Czwarty — niezwykle istotny — rozdzia³ wprowadzi Ciê w tematykê normalizacji modelu, dziêki czemu zrozumiesz, jak istotny to proces! W trakcie lektury kolejnych rozdzia³ów nauczysz siê rozwi¹zywaæ typowe problemy, wystêpuj¹ce w trakcie modelowania, oraz uœwiadomisz sobie, jak istotn¹ rolê pe³ni¹ w nim indeksy. Pojawiaj¹ce siê tu przyk³ady dotycz¹ bazy danych SQL Server firmy Microsoft, niew¹tpliwie jednak ksi¹¿ka ta przyda siê równie¿ osobom zwi¹zanym z innymi platformami bazodanowymi. • Techniki modelowania danych • Elementy wykorzystywane w logicznych modelach danych • Elementy wykorzystywane w fizycznych modelach danych • Proces normalizacji modelu danych • Sposoby efektywnego gromadzenia wymagañ • Interpretacja oraz dokumentacja wymagañ • Proces tworzenia modelu logicznego • Sposób wykorzystania SQL Server w celu stworzenia modelu fizycznego • Zastosowanie i znaczenie indeksów • Przygotowanie warstwy abstrakcji w SQL Server • Rozwi¹zywanie typowych problemów w trakcie procesu modelowania

Dowiedz siê wszystkiego o modelowaniu danych i Twórz wydajne rozwi¹zania!


SPIS TRECI

Wstp ................................................................................................. 13 O autorach ........................................................................................... 15

Cz I

Teoria modelowania danych ...................................... 17

Rozdzia 1. Przegld technik modelowania danych ..................................... 19 Bazy danych ...................................................................................................... 20 Systemy zarzdzania relacyjnymi bazami danych .............................................21 Dlaczego dobrze zaprojektowany model danych jest tak wany ..................... 22 Sp贸jno danych .............................................................................................22 Skalowalno ..................................................................................................23 Spenianie wymaga biznesowych ...................................................................25 atwe odczytywanie danych ............................................................................26 Poprawianie wydajnoci ..................................................................................28 Proces modelowania danych ............................................................................. 29 Teoria modelowania danych ............................................................................29 Wymagania biznesowe ...................................................................................31 Budowanie modelu logicznego .........................................................................33 Budowanie modelu fizycznego .........................................................................34 Podsumowanie .................................................................................................. 35

Rozdzia 2. Elementy wykorzystane w logicznych modelach danych ............... 37 Encje .................................................................................................................. 37 Atrybuty ............................................................................................................ 38 Typy danych ...................................................................................................39 Klucze g贸wne i obce ......................................................................................43 Domeny .........................................................................................................44 Atrybuty z pojedyncz wartoci i z wieloma wartociami ................................45 Sp贸jno referencji ............................................................................................ 46 Relacje ............................................................................................................... 47 Typy relacji .....................................................................................................48 Opcje relacji ...................................................................................................52 Liczno .........................................................................................................53


8

SPIS TRECI Uywanie podtypów i typów nadrzdnych ....................................................... 54 Definicje podtypów i typów nadrzdnych .........................................................54 Kiedy u ywa klastrów podtypów ....................................................................56 Podsumowanie .................................................................................................. 56

Rozdzia 3. Fizyczne elementy modeli danych ............................................ 57 Fizyczne przechowywanie danych .................................................................... 57 Tabele ...........................................................................................................57 Widoki ...........................................................................................................59 Typy danych ...................................................................................................61 Spójno referencji ............................................................................................ 70 Klucze gówne ................................................................................................70 Klucze obce ....................................................................................................74 Ograniczenia ..................................................................................................76 Implementowanie spójnoci referencji .............................................................78 Programowanie ................................................................................................. 81 Procedury skadowane ....................................................................................81 Funkcje u ytkownika ......................................................................................82 Wyzwalacze ...................................................................................................83 Integracja z CLR .............................................................................................85 Implementowanie typów nadrzdnych i podtypów ......................................... 85 Tabela typu nadrzdnego ................................................................................86 Tabele podtypów ............................................................................................87 Tabele typu nadrzdnego i podtypów ..............................................................87 Typy nadrzdne i podtypy — podsumowanie ...................................................88 Podsumowanie .................................................................................................. 88

Rozdzia 4. Normalizowanie modelu danych .............................................. 91 Czym jest normalizacja? .................................................................................... 91 Postaci normalne ............................................................................................91 Okrelanie postaci normalnych ......................................................................... 99 Denormalizacja ............................................................................................... 100 Podsumowanie ................................................................................................ 102

Cz II

Wymagania biznesowe ........................................... 105

Rozdzia 5. Gromadzenie wymaga ........................................................ 107 Przegld zagadnie zwizanych ze zbieraniem wymaga ............................... 108 Zbieranie wymaga krok po kroku ................................................................. 108 Prowadzenie wywiadów ................................................................................108 Obserwacje ..................................................................................................111 Istniejce procesy i systemy ..........................................................................112 Przypadki u ycia ...........................................................................................114


SPIS TRECI

9

Potrzeby biznesowe ........................................................................................ 120 Szukanie zotego rodka midzy ograniczeniami technicznymi i potrzebami biznesowymi ................................................................................................... 121 Zbieranie danych uytkowych ........................................................................ 121 Odczyty a zapisy ..........................................................................................121 Wymagania dotyczce przechowywania danych ............................................122 Wymagania transakcyjne .............................................................................123 Podsumowanie ................................................................................................ 124

Rozdzia 6. Interpretowanie wymaga .................................................... 125 Mountain View Music ...................................................................................... 125 Analiza danych na temat wymaga .................................................................. 127 Identyfikowanie u ytecznych informacji .........................................................127 Identyfikowanie informacji nadmiarowych .....................................................128 Definiowanie wymaga modelu ...................................................................... 129 Interpretowanie wyników wywiadów .............................................................129 Interpretacja diagramów przepywu ..............................................................134 Interpretowanie istniejcych systemów .........................................................137 Interpretowanie przypadków u ycia ..............................................................139 Okrelanie atrybutów ...................................................................................141 Okrelanie regu biznesowych ........................................................................ 143 Definiowanie regu biznesowych ....................................................................145 Liczno .......................................................................................................146 Wymagania wobec danych ...........................................................................146 Dokumentowanie wymaga ........................................................................... 147 Lista encji ....................................................................................................147 Lista atrybutów ............................................................................................147 Lista relacji ..................................................................................................148 Lista regu biznesowych ................................................................................148 Spojrzenie w przyszo — recenzja ............................................................... 148 Dokumentacja projektowa ............................................................................148 Podsumowanie ................................................................................................ 150

Cz III Tworzenie modelu logicznego ................................... 151 Rozdzia 7. Tworzenie modelu logicznego .................................................153 Tworzenie diagramów modelu danych ........................................................... 153 Sugestie dotyczce nazewnictwa ...................................................................153 Standardy notacji .........................................................................................156 Narzdzia do modelowania ...........................................................................159 Wykorzystywanie wymaga do budowania modelu ....................................... 160 Lista encji ....................................................................................................160 Lista atrybutów ............................................................................................164 Dokumentacja relacji ...................................................................................165 Reguy biznesowe .........................................................................................166


10

SPIS TRECI Budowanie modelu ......................................................................................... 167 Klucze gówne ..............................................................................................168 Relacje .........................................................................................................169 Domeny .......................................................................................................170 Atrybuty .......................................................................................................170 Podsumowanie ................................................................................................ 172

Rozdzia 8. Typowe problemy przy modelowaniu danych .............................173 Problemy z encjami ......................................................................................... 173 Zbyt mao encji ............................................................................................173 Zbyt wiele encji ............................................................................................176 Problemy z atrybutami .................................................................................... 177 Jeden atrybut zawierajcy ró ne dane ...........................................................177 Niewaciwe typy danych ..............................................................................179 Problemy z relacjami ....................................................................................... 183 Relacje typu jeden-do-jednego ......................................................................183 Relacje typu wiele-do-wielu ..........................................................................184 Podsumowanie ................................................................................................ 185

Cz IV Tworzenie modelu fizycznego .................................. 187 Rozdzia 9. Tworzenie modelu fizycznego za pomoc serwera SQL Server ........ 189 Nazewnictwo obiektów .................................................................................. 189 Ogólne reguy nazewnictwa ..........................................................................191 Nazywanie tabel ..........................................................................................194 Nazywanie kolumn .......................................................................................195 Nazwy widoków ...........................................................................................195 Nazywanie procedur skadowanych ...............................................................195 Nazywanie funkcji u ytkownika ....................................................................196 Nazywanie wyzwalaczy ................................................................................196 Nazywanie indeksów ....................................................................................196 Nazywanie typów danych u ytkownika .........................................................197 Nazywanie kluczy gównych i kluczy obcych ..................................................197 Nazywanie ogranicze ..................................................................................197 Tworzenie modelu fizycznego ........................................................................ 198 Modelowanie tabel na podstawie encji ..........................................................198 U ywanie relacji do modelowania kluczy .......................................................208 Modelowanie kolumn za pomoc atrybutów ..................................................209 Implementowanie regu biznesowych w modelu fizycznym ........................... 209 Implementowanie regu biznesowych za pomoc ogranicze ..........................210 Implementowanie regu biznesowych za pomoc wyzwalaczy ........................212 Implementowanie zaawansowanej licznoci ..................................................214 Podsumowanie ................................................................................................ 216


SPIS TRECI

11

Rozdzia 10. Kilka sów na temat indeksów ............................................... 217 Przegld indeksów .......................................................................................... 217 Czym s indeksy? ..........................................................................................218 Rodzaje ........................................................................................................220 Wymagania dotyczce korzystania z bazy danych .......................................... 226 Odczyty i zapisy ...........................................................................................226 Dane transakcji ............................................................................................228 Okrelanie waciwych indeksów ................................................................... 228 Przegldanie wzorów dostpu do danych .......................................................228 Równowa enie indeksów ..............................................................................229 Indeksy pokrywajce .....................................................................................230 Statystyki indeksów ......................................................................................230 Rozwa ania na temat obsugi indeksów ........................................................231 Implementowanie indeksów w serwerze SQL Server .................................... 231 Konwencje nazewnictwa ...............................................................................231 Tworzenie indeksów .....................................................................................232 Grupy plików ................................................................................................233 Konfigurowanie konserwacji indeksów ...........................................................233 Podsumowanie ................................................................................................ 235

Rozdzia 11. Tworzenie warstwy abstrakcji w serwerze SQL Server ................ 237 Czym jest warstwa abstrakcji? ........................................................................ 237 Po co uywa warstwy abstrakcji? .................................................................. 238 Bezpieczestwo ............................................................................................238 Elastyczno i mo liwo rozbudowy .............................................................240 Zwizek warstwy abstrakcji z logicznym modelem danych ............................ 241 Zwizek warstwy abstrakcji z programowaniem zorientowanym obiektowo ......241 Implementowanie warstwy abstrakcji ............................................................. 243 Widoki .........................................................................................................243 Procedury skadowane ..................................................................................245 Inne skadniki warstwy abstrakcji ..................................................................248 Podsumowanie ................................................................................................ 248

Cz V

Dodatki ................................................................251

Dodatek A Przykadowy model logiczny .................................................. 253 Dodatek B Przykadowy model fizyczny .................................................. 257 Dodatek C Zarezerwowane sowa serwera SQL Server 2008 ....................... 261 Dodatek D Zalecane standardy nazewnictwa ............................................263 Skorowidz .........................................................................265


R O Z D Z I A  2.

ELEMENTY WYKORZYSTANE W LOGICZNYCH MODELACH DANYCH

Prosz sobie wyobrazi, e kto poprosi nas o wybudowanie domu. Jednym z pierwszych pyta, jakie w takiej sytuacji naleaoby sobie postawi, jest: „Czy mam wszystkie potrzebne narzdzia i materiay?” Aby na takie pytanie odpowiedzie, potrzebujemy projektu tego domu. To wanie z projektu bdziemy w stanie wywnioskowa, jakie narzdzia i materiay bd niezbdne. Oznacza to, e na pocztek musimy sobie przygotowa projekt. Jeeli wczeniej tego nie robilimy, to najprawdopodobniej bdziemy musieli dowiedzie si, jak naley go wykona. Przygotowany przez nas logiczny model danych, podobnie jak projekt domu, stanie si podstaw wszystkich prac nad fizyczn baz danych. Oprócz tego logiczny model danych jest swego rodzaju wysokopoziomowym widokiem na baz danych, który mona zaprezentowa wszystkim stronom biorcym udzia w projekcie. Z tych wanie powodów logiczny model danych moe by cakowicie oderwany od technicznych szczegóów zwizanych z konkretnym systemem zarzdzania bazami danych. Informacje zawarte w modelu logicznym definiuj jedynie sposób, w jaki baza danych zbudowana na podstawie tego modelu bdzie speniaa biznesowe wymagania klienta. Zanim jednak przystpimy do konstruowania modelu logicznego, koniecznie musimy pozna wszystkie narzdzia, jakich bdziemy potrzebowali. W tym rozdziale omówimy obiekty i koncepcje powizane z procesem tworzenia logicznego modelu danych. Obiekty te wykorzystamy ponownie w rozdziale 7., w którym zaczniemy tworzy model danych dla firmy Mountain View Music. Na razie opiszemy temat encji oraz atrybutów i zobaczymy, jak mona tworzy relacje midzy nimi.

Encje Encje reprezentuj logiczne grupy danych, dlatego w modelu logicznym s najwaniejszym elementem, który definiuje sposób zapisu danych w bazie. Typowymi przykadami encji s klienci, zamówienia lub produkty. Kada encja, która powinna reprezentowa pojedynczy typ informacji, skada si z caej kolekcji egzemplarzy tej encji. Egzemplarz (ang. instance) encji jest bardzo podobny do rekordu bazy danych. W teorii modelowania danych pojcia egzemplarza, rekordu lub wiersza


38

ROZDZIA 2. ELEMENTY WYKORZYSTANE W

LOGICZNYCH MODELACH DANYCH

s uywane zamiennie. W tej ksice egzemplarz bdzie pojawia si wycznie w encjach, natomiast rekordy lub wiersze bd elementami fizycznych tabel lub widoków. Czsto moemy ulega pokusie traktowania poszczególnych encji jako tabel (w kocu midzy tabelami a encjami istniej zwykle zwizki typu jeden do jednego), trzeba jednak pamita, e logiczna encja moe by reprezentowana przez wiele tabel, a wiele encji moe zosta zgromadzonych w ramach jednej tabeli. Zadaniem encji jest identyfikacja wszystkich informacji, które bd zapisywane w bazie danych. Jednym ze sposobów na okrelenie, co mona zakwalifikowa jako encj, jest mylenie o encjach jak o rzeczownikach. Encje zwykle s obiektami, które mona opisa za pomoc rzeczownika: zamówieniami, samochodami, trbkami albo telefonami, czyli przedmiotami znanymi nam na co dzie. Waciwe zdefiniowanie encji na potrzeby modelu jest niezwykle istotne, dlatego to zadanie stanowi zawsze jedn z wikszych czci procesu projektowania. Definiujc encje, powinnimy przede wszystkim zajmowa si ich przeznaczeniem, a dopiero w dalszej kolejnoci zastanawia si nad ich atrybutami i innymi szczegóami (atrybuty zostan opisane w nastpnym podrozdziale). Wywiady prowadzone z pracownikami firmy i innymi osobami odpowiedzialnymi za jej funkcjonowanie w ramach procesu gromadzenia wymaga biznesowych (bdzie o tym mowa w rozdziale 5.) pozwol nam okreli najczciej uywane w firmie rzeczowniki, a co za tym idzie, najistotniejsze encje. Po rozpoczciu projektowania modelu to wanie z tych notatek bdziemy korzysta do okrelania wszystkich niezbdnych encji. Musimy przy tym bardzo ostronie przeglda i filtrowa sporzdzone wczeniej notatki, tak eby wykorzysta tylko te informacje, które s rzeczywicie istotne w aktualnym projekcie.

Atrybuty Kada encja jest opisywana przez pewne szczegóowe informacje, które s wanie jej atrybutami. Zaómy, e musimy utworzy encj przechowujc wszystkie informacje opisujce kapelusze. Otrzyma ona nazw Kapelusze, a nastpnie bdziemy mogli okreli, jakie informacje, czyli atrybuty, musimy w niej zachowa: kolor, nazw producenta, styl, materia itp. W czasie konstruowania modelu definiujemy kolejk atrybutów, które bd przechowyway te dane w ramach encji. Definicja atrybutu skada si z jego nazwy, opisu, celu i typu danych (typy danych zostan omówione w nastpnym podrozdziale). Naley si przy tym wystrzega dodawania do encji atrybutów, które tak naprawd powinny by czci innej encji. Typowy bd polega na bezporednim przeksztacaniu danych z fizycznej dokumentacji, takiej jak wydrukowane arkusze kalkulacyjne lub podrczniki, w encje i atrybuty modelu logicznego. Na przykad informacje na temat klienta s czsto fizycznie czone z informacjami na temat zamówienia. Mona z tego wysnu bdne zaoenie, e informacje dotyczce klienta, takie jak adres lub numer telefonu, s atrybutami zamówienia. W rzeczywistoci klient i zamówienie s cakowicie niezalenymi encjami. Zapisanie atrybutów klienta w ramach


ATRYBUTY

39

encji zamรณwienia spowoduje niepotrzebne skomplikowanie procesu odczytywania danych i moe doprowadzi do powstania projektu, ktรณry nie bdzie poddawa si skalowaniu. Chcc prawidowo modelowa atrybuty encji, musimy pozna kilka najwaniejszych poj: typy danych, klucze, domeny i wartoci. W kolejnych podrozdziaach nieco dokadniej je omรณwimy.

Typy danych Oprรณcz informacji opisowych w definicji atrybutu trzeba poda jeszcze typ danych (ang. data type). Jak sama nazwa wskazuje, definiuje on typ informacji, jaka bdzie zapisywana w atrybucie. Na przykad atrybut moe by cigiem znakรณw, liczb albo wartoci logiczn typu prawda-fasz. W modelach logicznych okrelenie typรณw danych atrybutรณw nie jest absolutnie wymagane. Ze wzgldu na to, e typ danych jest okreleniem fizycznego sposobu zapisu danych, okrelenie typu danych atrybutu nastpuje w czasie tworzenia modelu fizycznego. Trzeba jednak pamita, e okrelajc typ danych ju w trakcie przygotowywania modelu logicznego, moemy uzyska kilka wanych korzyci: ย„ Zespรณ tworzcy model fizyczny bdzie dysponowa ju pewnym przewodni-

kiem i nie bdzie musia wyszukiwa informacji w zbiorze wymaga (czasami moe si to okaza dziaaniem wielokrotnym). ย„ Bdziemy mogli wykry niecisoci powstajce pomidzy encjami przechowujcymi ten sam typ danych (na przykad numer telefonu), i to jeszcze przed powstaniem modelu fizycznego. ย„ W ramach uatwienia procesu budowania fizycznej bazy danych moemy zdefiniowa typy danych cile zwizane z uywanym systemem relacyjnych baz danych. Mona to zrobi tylko wtedy, gdy docelowy system zarzdzania baz danych bdzie znany jeszcze przed rozpoczciem prac nad modelem. Wikszo dostpnych programรณw do modelowania danych pozwala na wybranie sporรณd typรณw danych stosowanego systemu zarzdzania baz danych. Skoro mamy pracowa z serwerem Microsoft SQL Server, moemy od razu korzysta z typรณw danych obsugiwanych przez ten serwer. Przyjrzyjmy si teraz rรณnym typom danych stosowanym w modelach logicznych.

Alfanumeryczne Wszystkie modele danych zawieraj dane alfanumeryczne, czyli dowolne dane w postaci cigu znakรณw, niezalenie od tego, czy zawieraj one znaki alfabetu, czy te cyfry (pod warunkiem e te nie bior udziau w obliczeniach matematycznych). Przykadami tego typu danych mog by nazwy, adresy albo numery telefonรณw. Konkretne typy danych uywane do przechowywania informacji alfanumerycznych to char, nchar, varchar i nvarchar. Jak mona wywnioskowa z nazw tych typรณw, s one przeznaczone do przechowywania znakรณw, takich jak litery, cyfry i znaki specjalne.


40

ROZDZIA 2. ELEMENTY WYKORZYSTANE W

LOGICZNYCH MODELACH DANYCH

Wszystkie te typy danych wymagaj okrelenia ich dugoci. Mówic ogólnie, dugo definiuje cakowit liczb znaków, jaka moe znale  si w danym atrybucie. Jeeli mamy pewno, e dany atrybut bdzie przechowywa tylko dwuliterowe skróty nazw pastw, to moemy zdefiniowa go jako char(2). W ten sposób definiujemy atrybut jako alfanumeryczne pole mieszczce w sobie dokadnie dwa znaki. Atrybuty typu char przechowuj dokadnie tyle znaków, ile okrela ich definicja — nie mniej i nie wicej, niezalenie od tego, ile znaków faktycznie do nich wprowadzono. Kady zapewne zauway ju, e istniej a cztery rodzaje znakowego typu danych: dwa z przedrostkiem var i dwa z przedrostkiem n (jeden z tych typów zawiera oba te przedrostki). Pola o zmiennej dugoci s definiowane jako zawierajce nie wicej znaków, ni zostao to podane w definicji pola. Aby zobrazowa rónic midzy typami char i varchar, mona poda, e definicja char(10) tworzy pole o dugoci dziesiciu znaków, nawet jeeli konkretny egzemplarz tego pola bdzie mia dugo szeciu znaków. W takim przypadku pozostae cztery znaki zostan automatycznie dopisane. Jeeli ten atrybut zostanie zdefiniowany jako varchar(10), to w podobnej sytuacji zapisanych zostanie tylko sze znaków. Przedrostek n oznacza, e znaki bd zapisywane w formacie Unicode. Jest to midzynarodowa, niezalena od platformy specyfikacja przeznaczona do zapisywania znaków. Uywanie Unicode’u pozwala na budowanie systemów pracujcych ze znakami rónych jzyków. Systemy takie mog bez adnych problemów wymienia midzy sob dane tekstowe, wanie dziki zastosowaniu wspólnej metody zapisu znaków. Jeeli tylko musimy zapisa znaki wykraczajce poza standardowy zestaw ASCII konieczne jest zastosowanie Unicode’u. Podstawow rónic midzy systemami korzystajcymi z Unicode’u a systemami uywajcymi tylko znaków ASCII jest to, e kady znak Unicode zajmuje dwa bajty, podczas gdy znaki ASCII zajmuj tylko jeden znak (jeeli s zapisywane dane o zmiennej dugoci, moe si okaza, e jest potrzebny wicej ni jeden bajt). Problem z systemami zapisujcymi znaki w jednym bajcie polega na tym, e nie s one w stanie skutecznie zapisa pewnych znaków, takich jak japoskie znaki Kanji albo koreaskie znaki Hangul. W tym przypadku trzeba rozway, czy waniejsza jest wygoda zapisywania danych, czy moe wydajno pracy. Zagadnienie to bdziemy omawia dokadniej w rozdziale 3. Na razie prosz pamita, e jeeli chcemy przechowywa w bazie pewne typy tekstów, niezbdne moe okaza si uycie znaków w formacie Unicode.

Numeryczne Dane numeryczne to dowolne dane, które musz zosta zapisane w postaci liczbowej. Na wszystkich typach danych numerycznych moemy wykonywa obliczenia matematyczne. Wród najogólniejszych typów danych numerycznych znajdziemy typy cakowite (integer), dziesitne (decimal), walutowe (money), zmiennoprzecinkowe (float) i rzeczywiste (real). Typy cakowite zawsze s zapisywane w postaci liczby cakowitej. Ten typ danych pozwala na zapisywanie liczb dodatnich i ujemnych, a dodatkowo istnieje on w kilku wielkociach, z których kada pozwala na przechowywanie okrelonego


ATRYBUTY

41

zakresu wartoci. Typy dziesitne s liczbami o z góry zdefiniowanej wielkoci i dokadnoci. Wielko typu oznacza w tym przypadku ogóln liczb cyfr, jakie mona zapisa w danym polu, natomiast dokadno okrela, ile z tych cyfr zostanie zapisanych po przecinku. Typ walutowy jest przeznaczony do zapisywania wartoci kwot, a jego dokadno jest uzaleniona od stosowanego wanie systemu zarzdzania bazami danych. Typ zmiennoprzecinkowy opisuje liczby zmiennoprzecinkowe, a zatem liczby zapisywane z pewnym przyblieniem. Wartoci tego typu s najczciej zapisywane w notacji naukowej. Dodatkowo moliwe jest zdefiniowanie liczby bitów, w której maj by przechowywane liczby. Typy rzeczywiste s waciwie identyczne z typami zmiennoprzecinkowymi, ale typy zmiennoprzecinkowe umoliwiaj przechowywanie znacznie wikszych liczb. Podobnie jak w przypadku typów danych alfanumerycznych szczegóowe informacje na temat fizycznego zapisywania danych tych typów zostay przedstawione w rozdziale 3.

Logiczne Typy logiczne (boolean) umoliwiaj przechowywanie tylko trzech wartoci: prawdy (TRUE), faszu (FALSE) lub zera (NULL). Dane przechowywane w polach tego typu s logiczne, fizycznym typem danych jest jednak jeden bit. Moe on przechowywa warto 1, 0 lub NULL, które mona przetumaczy jako prawd, fasz i nic. Logiczne typy danych s uywane do przechowywania wyników rónych wyrae logicznych. Czsto stosowane s te jako przeczniki lub flagi, na przykad wskazujce, e dany pojazd jest aktualnie niesprawny.

BLOB i CLOB Nie wszystkie dane przechowywane w bazie danych musz mie posta czyteln dla uytkownika. Na przykad baza danych zbierajca informacje sklepu internetowego oprócz danych opisujcych poszczególne produkty moe równie zawiera ich obrazy. Binarne dane skadajce si na informacje o obrazie nie nadaj si do czytania w postaci cigu znaków, ale mog zosta zapisane w bazie danych, tak eby moga z nich skorzysta aplikacja. Tego rodzaju dane s zwykle nazywane wielkimi obiektami binarnymi (ang. binary large object — BLOB). Takie informacje w serwerze SQL Server najczciej s zapisywane za pomoc nastpujcych typów danych: binary, varbinary i image. Podobnie jak w przypadku typów znakowych przedrostek var oznacza, e dany atrybut moe przechowywa wartoci o zmiennej dugoci. W zwizku z tym typ binary definiuje atrybut o staej wielkoci, przechowujcy dane binarne, a typ varbinary okrela tylko maksymaln wielko atrybutu przechowujcego dane binarne. Z kolei typ image okrela, e atrybut zawiera dane binarne o zmiennej wielkoci, podobne do typu varbinary. Typ ten daje jednak znacznie wiksze moliwoci przechowywania danych. Dane znakowe równie mog si pojawia w formach o wiele duszych, ni przewiduj to typowe typy danych alfanumerycznych, o których mówilimy wczeniej. Co zrobi, jeeli w danym atrybucie musimy zapisa tekst dowolnej wielkoci,


42

ROZDZIA 2. ELEMENTY WYKORZYSTANE W

LOGICZNYCH MODELACH DANYCH

na przykad cay yciorys? W tej sytuacji z pomoc przychodz nam dwa typy wielkich obiektów znakowych (ang. character large object — CLOB), czyli text i ntext. Te dwa typy danych s przeznaczone do przechowywania duych iloci tekstu w postaci jednego pola. Podobnie jak byo to w przypadku pozostaych typów znakowych, przedrostek n oznacza, e tekst w danym atrybucie jest zapisywany w formacie Unicode. Z tych typów danych naley korzysta wtedy, gdy w ramach jednego atrybutu encji musimy zapisa naprawd due iloci danych alfanumerycznych.

Data i czas Niemal kady istniejcy model danych wymaga zastosowania encji zawierajcych atrybuty opisujce daty lub czas. Pozwalaj one na okrelenie momentu, w którym wprowadzono zmiany do zamówienia, daty zatrudnienia nowego pracownika albo zdefiniowanie czasu dostawy towarów. Kady system zarzdzania relacyjnymi bazami danych ma swoj wasn implementacj typów danych pozwalajcych na zapisywanie daty i czasu. W przypadku serwera SQL Server 2008 mamy do dyspozycji a sze typów danych tego rodzaju. Jest to duy postp w stosunku do poprzednich wersji tego serwera, które oferoway jedynie dwa typy: datetime i smalldatetime. Kady z tych typów danych przechowuje informacje na temat daty lub czasu. Rónice wynikaj jedynie z dokadnoci zapisanej daty i zakresu dostpnych wartoci. Przyjrzyjmy si starszym typom. Typ datetime przechowuje dane dotyczce daty i czasu z dokadnoci do jednej milisekundy. Zaómy, e do tabeli zawierajcej kolumn typu datetime wpisujemy dat 12.01.2008 oraz godzin 18.00. W bazie danych zostanie zapisana warto: 12/01/2008 18:00:00.000

Typ smalldatetime zapisaby t sam warto w postaci: 12/01/2008 18:00

Typ datetime moe przechowywa dowoln dat z zakresu od 1 stycznia 1753 roku do 31 grudnia 9999 roku, a typ smalldatetime pozwala na zapisanie daty z zakresu od 1 stycznia 1900 roku do 6 czerwca 2079 roku. Powodem wybrania tych wanie dat, trzeba przyzna, e do dziwnych, s wymagania zwizane z metodami zapisu na poziomie dysku twardego oraz z metodami manipulacji na datach w serwerze SQL Server. Jak ju wczeniej wspominalimy, SQL Server 2008 wprowadza cztery nowe typy danych zwizanych z dat i czasem: date, time, datetime2 i datetimeoffset. Nowe typy danych przechowuj informacje o dacie i czasie w sposób duo elastyczniejszy ni poprzednie. Najprostsze s oczywicie typy date i time, poniewa pozwalaj na zapisanie jedynie daty lub jedynie czasu. Typ datetime2 otrzyma niezbyt dobr nazw, ale poza tym jest bardzo podobny do typu datetime. Jedyna rónica polega na tym, e nowy typ danych pozwala na zdefiniowanie dokadnoci zapisywania uamków sekund od zera do siedmiu miejsc po przecinku. Z kolei typ danych datetimeoffset róni si od typu datetime moliwoci zapisania oprócz daty i czasu


ATRYBUTY

43

pewnej wartoci przesunicia. Nie musi by ono zwizane z adn stref czasow ani nawet z czasem Greenwich. Musimy zatem pamita, wzgldem której strefy czasowej naley je liczy. Omówilimy ju sporo szczegóów, ale ponownie przypomnimy, e jeszcze duszy wywód na temat metod przechowywania informacji w ramach poszczególnych typów danych znajduje si w rozdziale 3. W czasie projektowania modelu logicznego moemy ulec pokusie nadawania atrybutom rónych typów danych. Takie praktyki mog jednak powodowa wiele problemów podczas dalszych prac. Wikszo programów do modelowania danych jest w stanie wygenerowa model fizyczny na podstawie modelu logicznego, a zatem wybranie niewaciwych typów danych w modelu logicznym moe doprowadzi do nieprawidowoci w modelu fizycznym, szczególnie gdy pracuje nad nim kilka osób. Naley czsto zaglda do zebranych wymaga biznesowych, tak eby uzyska pewno, e faktycznie definiujemy atrybuty zgodne z danymi uywanymi w firmie. Uatwi nam to równie rozmowy na temat modelu danych prowadzone z pracownikami, którzy nie zajmuj si techniczn stron projektu.

Klucze g ówne i obce Klucz gówny (ang. Primary Key — PK) jest atrybutem lub grup atrybutów, która jednoznacznie identyfikuje kady egzemplarz danej encji. Zawsze musi zawiera dane i nigdy nie moe by pusty. Jako przykady kluczy gównych mona poda numery identyfikacyjne pracowników albo numery ISBN ksiek. W czasie tworzenia modelu musimy pamita o tym, e niemal kada zawarta w nim encja musi mie klucz gówny, nawet jeeli musimy go utworzy sztucznie za pomoc jakiej liczby. Jeeli dane nie maj przypisanego klucza gównego, to czsto niezbdne jest dodanie do tabeli kolumny, która bdzie suya jako taki wanie klucz. Tego rodzaju klucze nazywane s kluczami zastpczymi. Co prawda, taka praktyka jest ju bardziej zbliona do fizycznego projektowania bazy danych, ale modelowanie klucza zastpczego pozwala na tworzenie relacji na podstawie kluczy gównych. Takie klucze s zwykle liczbami, których warto jest zwikszana dla kadego wiersza dodawanego do tabeli. W przypadku serwera SQL Server liczby te nazywane s tosamociami (ang. Identity). Inna regua dobrego modelowania mówi, e nie naley uywa opisowych atrybutów jako kluczy gównych. Na przykad w tabelach opisujcych pracowników czsto jako klucz gówny jest uywany numer PESEL. Nie jest to dobre rozwizanie z co najmniej kilku powodów. Po pierwsze, chodzi o wzgldy bezpieczestwa i zachowanie prywatnoci. Wiele kradziey tosamoci dochodzi do skutku wanie dlatego, e zodziej ma dostp do numeru PESEL ofiary. Po drugie, numery PESEL powinny by unikatowe, ale nie mona wykluczy sytuacji, w której zostan zmienione. Po trzecie, moe si okaza, e przyjdzie nam zarejestrowa pracowników zagranicznych, którzy nie maj numeru PESEL. W takiej sytuacji kuszce moe by wygenerowanie po prostu sztucznego numeru, ale co bdzie, jeeli zagraniczny pracownik otrzyma obywatelstwo, a razem z nim wasnym numer PESEL? W takiej


44

ROZDZIA 2. ELEMENTY WYKORZYSTANE W

LOGICZNYCH MODELACH DANYCH

sytuacji wiersze encji zalenych mog by poczone z prawdziwym lub nieprawdziwym numerem PESEL, przez co odczytywanie danych bardzo si skomplikuje, a co gorsza, w bazie mog pojawi si osierocone wiersze. Mรณwic ogรณlnie, klucz gรณwny powinien: ย„ by cakowicie unikatowy i absolutnie niezmienny, ย„ skada si z atrybutรณw, ktรณre nigdy nie bd puste, ย„ korzysta z nieznaczcych danych, jeeli tylko jest to moliwe.

Z kluczem gรณwnym jest cile powizany klucz obcy (ang. Foreign Key โ€” FK). Skadaj si na niego atrybuty dane encji, ktรณre bazuj na kluczu (najczciej na kluczu gรณwnym) innej encji. Przyjrzyjmy si przykadowej encji Pracownik oraz cakowicie nowej encji Pojazd. Jeeli chcielibymy wiedzie, ktรณremu pracownikowi przypisano dany samochรณd, to musielibymy poczy te dwie encje relacj. W takiej sytuacji w encji Pojazd musi istnie klucz obcy wskazujcy na klucz gรณwny w tabeli Pracownik. Najprociej mona to zrealizowa, dodajc do encji Pojazd atrybut przechowujcy numer pracownika, ktรณremu przypisano dany samochรณd. Atrybuty w encji referujcej mog by atrybutami kluczowymi, ale rรณwnie niekluczowymi. Oznacza to, e klucz obcy w encji referujcej moe skada si z tych samych atrybutรณw co jej klucz gรณwny, ale moe zosta zbudowany z cakowicie innego zestawu atrybutรณw. Taka kombinacja klucza gรณwnego i klucza obcego pozwala na zachowanie spรณjnoci w logicznych relacjach midzy encjami.

Domeny Zaczynajc budowa model danych, z pewnoci zauwaymy, e w kontekcie danych, nad ktรณrymi pracujemy, pewne encje zawieraj podobne atrybuty. Bardzo czsto ze wzgldu na spรณjno informacji cz danych zwizana z funkcjonowaniem aplikacji lub firmy musi mie tak sam posta we wszystkich encjach. Status, adres, numer telefonu i adres e-mail s przykadami atrybutรณw, ktรณre najprawdopodobniej bd musiay mie identyczn posta w wielu encjach. Zamiast mudnie tworzy i ewentualnie modyfikowa te atrybuty w poszczegรณlnych encjach, moemy skorzysta z domen. Domena jest definicj atrybutu, ktรณra jest przechowywana w ramach modelu logicznego, ale poza jakkolwiek encj. Jeeli w encji zostanie wykorzystany atrybut bdcy czci domeny, to domena ta zostanie doczona do encji. Trzeba jednak pamita, e model danych nie przedstawia widocznej informacji o tym, e dany atrybut jest czci pewnej domeny. Wikszo narzdzi do modelowania udostpnia jednak specjaln sekcj lub dokument, taki jak sownik danych, w ktรณrym s przechowywane informacje o domenach. Jeeli jakiekolwiek zmiany zostan wprowadzone do domeny, to wszystkie zwizane z ni atrybuty we wszystkich encjach oraz dokumentacja zawierajca dane o domenach zostan odpowiednio dopasowane. Przyjrzyjmy si na przykad atrybutowi numeru telefonu. Bardzo czsto w modelach logicznych numery telefonรณw s projektowane jako numery lokalizowane. W Polsce taki numer jest zwykle zapisywany w postaci trzech cyfr numeru kierunkowego, za ktรณrymi znajduje si lokalny numer telefonu (XXX-XXXXXXX). Jeeli


ATRYBUTY

45

w dalszych pracach nad modelem zdecydujemy si zapisywa równie numery midzynarodowe, a atrybut numeru telefonu znalaz si ju w wielu encjach, to bdziemy zmuszeni do edytowania wszystkich wystpie tego atrybutu. Jeeli jednak przygotujemy sobie domen numeru telefonu i dodamy j do wszystkich encji przechowujcych taki numer, to wszelkie zmiany wprowadzane pó niej do domeny bd od razu przenoszone do wszystkich encji w tym modelu. Czste stosowanie domen pozwala na uniknicie niedogodnoci zwizanych z maymi rónicami midzy atrybutami przechowujcymi te same dane w rónych encjach. Praktyka ta pozwala na wymuszenie spójnoci danych i skrócenie czasu projektowania, nie tylko w okresie pocztkowych prac nad modelem, ale równie w czasie funkcjonowania bazy danych.

Atrybuty z pojedyncz wartoci i z wieloma wartociami Wszystkie omawiane do tej pory atrybuty byy atrybutami z pojedyncz wartoci (ang. single-valued attributes). Oznacza to, e dla kadego unikatowego elementu w encji istnieje tylko po jednej wartoci zapisanej w poszczególnych atrybutach. Niektóre atrybuty mog jednak w sposób naturalny przyjmowa wicej ni jedn warto. S one nazywane atrybutami z wieloma wartociami (ang. multivalued attributes). Zidentyfikowanie ich moe by kopotliwe, ale obsuga jest bardzo prosta. Bardzo typowym przykadem atrybutu z wieloma wartociami jest numer telefonu. W czasie zapisywania informacji o kliencie najczciej zapisujemy przynajmniej jeden numer telefonu, ale klienci posiadajcy kilka telefonów z pewnoci nie s wyjtkami. Moemy zatem doda do encji Klient wiele pól opisujcych numer telefonu i odpowiednio je ponumerowa (na przykad Telefon1, Telefon2 itd.) albo nazwa zgodnie z rodzajem telefonu (na przykad Dom, Komorka, Biuro). Jest to cakiem nieze wyjcie, dopóki nie zechcemy zapisa kilku firmowych numerów naszego klienta. Jest to typowy atrybut z wieloma wartociami, czyli jeden atrybut moe przechowywa wiele rónych wartoci. Z pewnoci nie chcemy przechowywa wielu rekordów opisujcych jednego klienta tylko po to, eby zapisa dodatkowy numer telefonu. Byoby to cakowicie sprzeczne z ide relacyjnej bazy danych i wprowadzaoby problemy z odczytywaniem z niej danych. W zwizku z tym moemy wprowadzi do modelu now encj, która bdzie przechowywaa numery telefonów i bdzie zwizana relacj z encj klientów (bazujc na kluczu gównym tej tabeli). Dziki temu zyskamy moliwo zapisania dowolnej liczby numerów telefonów dla kadego z klientów. Powstaa encja moe przechowywa wiele rónych wartoci dla kadego klienta, czyli zawiera tylko dwa atrybuty: unikatowy identyfikator klienta i numer telefonu. Zastosowanie takiej encji jest jedyn metod na skuteczne rozwizanie problemów z atrybutami o wielu wartociach. Co wicej, z takiej konstrukcji skorzysta równie fizyczna implementacja, poniewa bdzie moga wykorzysta techniki wyszukiwania oferowane przez system zarzdzania baz danych, które pozwalaj na przeszukiwanie encji zalenej w oderwaniu od encji nadrzdnej.


46

ROZDZIA 2. ELEMENTY WYKORZYSTANE W

LOGICZNYCH MODELACH DANYCH

Spójno referencji Jedn z najwaniejszych cech relacyjnej bazy danych jest to, e dane w jednej encji mog wskazywa na dane w innej encji. Jeeli taka sytuacja ma miejsce, to niemal zawsze powstaje te wymóg zarzdzania tak relacj. Dane w obu encjach musz by przecie cakowicie spójne. Koncepcja ta nazywana jest spójnoci referencji (ang. referential integrity), a w fizycznej implementacji danych jest najczciej realizowana za pomoc obiektów takich jak klucze i ograniczenia. Nie mona jednak zapomnie, e spójno referencji musi zosta odpowiednio udokumentowana w modelu logicznym, co gwarantuje przestrzeganie w bazie regu biznesowych (jak równie spójno zapisanych w niej danych). Zaómy, e projektujemy baz danych przechowujc informacje na temat inwentarza biblioteki. W modelu logicznym z pewnoci znajd si encje Autor, Wydawca i Tytu. Kady autor moe napisa wiele ksiek, ale dana ksika moe zosta opublikowana tylko przez jednego wydawc. Wydawca moe publikowa wiele ksiek. Jeeli uytkownik bdzie chcia usun dane autora z bazy, to z pewnoci zostanie w niej przynajmniej jedna osierocona ksika. Po usuniciu danych wydawcy równie co najmniej jedna ksika w bazie zostanie osierocona. W zwizku z tym musimy zdefiniowa te akcje, których wykonanie bdzie wymuszane za kadym razem, gdy dane bd aktualizowane w ten sposób. Takie definicje nazywane s wanie spójnoci referencji. Mog one na przykad nakaza usunicie wszystkich ksiek zwizanych z usuwanym wanie autorem. Moliwe jest te zdefiniowanie reguy zakazujcej dodania do bazy ksiki, jeeli nie istnieje w niej jeszcze zapis dotyczcy autora tej ksiki. Nie s to moe najdoskonalsze przykady, ale dobrze ilustruj konieczno zarzdzania relacjami czcymi poszczególne encje. W modelu logicznym spójno referencji jest dokumentowana za pomoc zwizków tworzonych przez klucze gówne i obce. Kada encja powinna mie atrybut kluczowy, jednoznacznie identyfikujcy wszystkie zapisane w niej rekordy. Moemy wykorzysta te klucze do zdefiniowania relacji czcej encj nadrzdn z encj zalen. Prosz spojrze na rysunek 2.1.

Rysunek 2.1. Klucz gówny i klucz obcy

Przykad przedstawia prost relacj midzy dwoma encjami. Po utworzeniu relacji moemy w jej definicji poda dowolne ograniczenia akcji zwizanych z manipulacjami na danych w encji nadrzdnej i zalenej. Na przykad mona zdefiniowa, e dowolna próba dopisania danych (INSERT) do encji zalenej nie moe si powie, jeeli w encji nadrzdnej nie istnieje egzemplarz o pasujcym kluczu gównym.


RELACJE

47

Mona te okreli, e dowolna operacja usuwania danych (DELETE) wykonana na encji nadrzdnej nie moe si uda, jeeli w encji zalenej istniej jeszcze egzemplarze zwizane z usuwanym wierszem w encji nadrzdnej. W tabeli 2.1. zostay opisane róne opcje, z jakich moemy skorzysta podczas wykonywania akcji na encji nadrzdnej lub zalenej. Tabela 2.1. Opcje spójnoci referencji dla relacji Encja

Akcja

Dostpne akcje

Encja nadrzdna

INSERT

Brak: wstawienie nowego egzemplarza nie ma wpywu na encj zalen

UPDATE

Brak: nie ma adnego wpywu na encj zalen i nie powoduje zablokowania zmian, w wyniku których powstaj niecisoci midzy encj nadrzdn i zalen Ograniczenie: porównuje dane w kluczu gównym encji nadrzdnej z danymi w kluczu obcym encji zalenej. Jeeli wartoci te nie s identyczne, to zmiany s blokowane Kaskada: kopiuje wszystkie zmiany z klucza gównego encji nadrzdnej do klucza obcego encji zalenej Null: podobne do opcji Ograniczenie. Jeeli wartoci nie s identyczne, to klucz obcy encji zalenej otrzymuje warto NULL, a zmiany w encji nadrzdnej s wykonywane

DELETE

Brak: nie ma adnego wpywu na encj zalen i nie powoduje zablokowania zmian, w wyniku których powstaj w encji zalenej wiersze osierocone Ograniczenie: porównuje dane w kluczu gównym encji nadrzdnej z danymi w kluczu obcym encji zalenej. Jeeli wartoci te nie s identyczne, to zmiany s blokowane Kaskada: usuwa wszystkie wiersze encji zalenej, których klucze obce pasuj do klucza gównego wiersza usuwanego w encji nadrzdnej Null: podobne do opcji Ograniczenie. Jeeli wartoci nie s identyczne, to klucz obcy encji zalenej otrzymuje warto NULL, a zmiany w encji nadrzdnej s wykonywane. Ta opcja powoduje powstanie osieroconych wierszy w encji zalenej

Encja zalena

INSERT

Brak: brak ogranicze Ograniczenie: porównuje dane w kluczu gównym encji nadrzdnej z kluczem obcym wartoci wstawianej do encji zalenej. Jeeli wartoci te nie s zgodne, to próba wstawienia danych jest blokowana

UPDATE

Brak: brak ogranicze Ograniczenie: porównuje dane w kluczu gównym encji nadrzdnej z kluczem obcym wartoci wstawianej do encji zalenej. Jeeli wartoci te nie s zgodne, to próba usunicia danych jest blokowana

DELETE

Brak: brak ogranicze. Pozwala na usunicie dowolnego wiersza z encji zalenej

Relacje Pojcie relacyjnej bazy danych implikuje wykorzystanie w bazie relacji. Jeeli nie wiemy, w jaki sposób dane s z sob powizane, to zastosowanie do ich przechowywania relacyjnej bazy danych nie bdzie si w niczym rónio od przechowywania wszystkich dokumentów finansowych w jednym worku. Wypenianie rocznego


48

ROZDZIA 2. ELEMENTY WYKORZYSTANE W

LOGICZNYCH MODELACH DANYCH

zeznania podatkowego moe si w takiej sytuacji okaza prawdziwym koszmarem. Wszystkie niezbdne informacje mamy pod rk, ale ile czasu zajmie nam wyszukanie ich w tym worku i ostateczne wypenienie dokumentów? Zalet relacyjnych baz danych jest to, e pozwalaj na wydajne przechowywanie i odczytywanie danych. Identyfikacja i implementacja waciwych relacji w modelu logicznym to dwa najwaniejsze kroki w procesie projektowania. Chcc prawidowo zidentyfikowa wszystkie relacje, musimy zna wszystkie dostpne moliwoci, wiedzie, jak je prawidowo rozpoznawa, i podj decyzj o tym, której relacji naley uy.

Typy relacji Pod wzgldem logicznym istniej trzy róne relacje czce encje: jeden-do-jednego, jeden-do-wielu i wiele-do-wielu. Kada z nich opisuje sposób, w jaki dwie encje zcz si z sob. Naley pamita o tym, e te relacje s tylko relacjami logicznymi. Ich fizyczna implementacja jest kolejnym krokiem, o którym bdziemy mówi w rozdziale 9.

Relacje jeden-do-jednego Relacja jeden-do-jednego czca dwie encje jest ich bezporednim poczeniem, na co wskazuje jej nazwa. Kady rekord w jednej encji ma dokadnie jeden pasujcy do niego rekord w drugiej encji. Nie mniej i nie wicej. Prosz sobie wyobrazi dwoje ludzi rzucajcych pik. W tej sytuacji jest dokadnie jeden rzucajcy i jeden apicy. Moe by tylko jeden rzucajcy i tylko jeden apicy (kto, kto faktycznie zapa pik). Po co w takim razie wybiera relacj typu jeden-do-jednego? Skoro jeden rekord w jednej encji jest zwizany z dokadnie jednym rekordem w drugiej encji, to czy nie lepiej byoby poczy te encje? Prosz spojrze na rysunek 2.2.

Rysunek 2.2. Encja Szkoly

Kada szkoa moe mie tylko jednego dyrektora, a kady dyrektor moe zarzdza tylko jedn szko. W tym przykadzie wszystkie atrybuty encji dyrektora s przechowywane w encji szkoy. To rozwizanie skupia wszystkie informacje w ramach jednej encji, ale jest bardzo mao elastyczne. Przy kadej zmianie danych szkoy lub dyrektora konieczne jest odczytanie caego rekordu, a nastpnie jego uaktualnienie. Oprócz tego szkoa bez dyrektora lub dyrektor bez szkoy bd tworzy rekord


RELACJE

49

wypeniony tylko w poowie. Co gorsza, taka konstrukcja powoduje problemy przy odczytywaniu danych. Jeeli chcielibymy napisa raport zawierajcy informacje o dyrektorach, to bylibymy zmuszeni do odczytywania równie danych szkó. A co bdzie, jeeli chcielibymy gromadzi informacje o pracownikach dyrektorów? W takim przypadku musielibymy powiza pracowników z poczon encj szkó i dyrektorów, a nie tylko z encj dyrektorów. Prosz si teraz przyjrze rysunkowi 2.3.

Rysunek 2.3. Encje Szkoly i Dyrektorzy

W tym przykadzie mamy ju dwie encje: Szkoly i Dyrektorzy. Kada z nich ma atrybuty opisujce dany rodzaj obiektu. Oprócz tego w encji Dyrektorzy jest zapisana referencja na szko, któr dany dyrektor prowadzi, a w encji Szkoly znajdziemy referencj dyrektora opiekujcego si dan szko. Takie rozwizanie jest duo bardziej elastyczne, poniewa listy szkó i dyrektorów s zarzdzane cakowicie niezalenie. Prosz jednak zauway, e encje te czy relacja jeden-do-jednego, która pozwala na naoenie ogranicze umoliwiajcych utrzymanie spójnoci danych.

Relacje jeden-do-wielu W najczciej wystpujcych relacjach typu jeden-do-wielu jeden rekord w pierwszej encji moe mie zero lub wicej pasujcych rekordów w drugiej encji. Istniej setki przykadów takich relacji, stosowanych najczciej w ramach czenia danych nagówkowych z informacjami szczegóowymi. Na przykad zamówienia s czsto przechowywane jako lista rekordów nagówkowych w jednej encji, druga encja gromadzi natomiast szczegóowe informacje na temat poszczególnych zamówie. Takie rozwizanie pozwala na umieszczenie w kadym zamówieniu wielu pozycji bez koniecznoci tworzenia wielu rekordów zawierajcych te same informacje wysokiego poziomu, takie jak data zamówienia, dane klienta itp.


50

ROZDZIA 2. ELEMENTY WYKORZYSTANE W

LOGICZNYCH MODELACH DANYCH

Wrรณmy do przykadu ze szkoami i dyrektorami. Co si stanie, jeeli pojawi si zarzdzenie pozwalajce pracowa kilku dyrektorom w jednej szkole? Taka sytuacja natychmiast tworzy relacj jeden-do-wielu czc encje Dyrektorzy i Szkoly, tak jak pokazano na rysunku 2.4.

Rysunek 2.4. Encje Szkoly i Dyrektorzy โ€” relacja jeden-do-wielu

Jak wida, taka relacja czca te dwie encje stwarza moliwo powizania kilku dyrektorรณw z jedn szko. Jest ona skalowalna, poniewa obie encje mog by aktualizowane i zarzdzane cakowicie niezalenie od siebie.

Relacje wiele-do-wielu Sporรณd wszystkich rodzajรณw relacji relacje wiele-do-wielu (nazywane rรณwnie relacjami nieokrelonymi) nale do najbardziej skomplikowanych do zidentyfikowania i zaprojektowania. W relacjach wiele-do-wielu rekordy z jednej encji mog czy si z wieloma rekordami w drugiej encji, a jednoczenie rekordy z drugiej encji mog wiza si z wieloma rekordami z pierwszej encji. Prosz sobie wyobrazi czci samochodowe, a w szczegรณlnoci siedzenia montowane w kadym aucie. W dowolnym samochodzie znajdziemy przynajmniej dwa rodzaje siedze: fotele dla kierowcy i pasaera oraz du kanap dla pasaerรณw siedzcych z tyu. Producenci samochodรณw niemal zawsze wykorzystuj istniejce siedzenia w kilku modelach samochodรณw. Jeli przeoymy te rozwaania na encje, to okae si, e Siedzenie moe znale  si w wielu Samochodach, a kady Samochรณd moe zawiera wiele Siedze. Wrรณmy jednak do naszego przykadu ze szkoami. Co bdzie, jeeli zostanie podjta decyzja, e jeden dyrektor moe zarzdza kilkoma szkoami, a jedna szkoa moe znajdowa si pod opiek kilku dyrektorรณw? Na rysunku 2.5. przedstawilimy encje Szkoly i Dyrektorzy zwizane relacjami pozwalajcymi na tworzenie wielu pocze midzy obiema encjami.


RELACJE

51

Rysunek 2.5. Encje Szkoly i Dyrektorzy — relacja wiele-do-wielu

Rozpatrujc t spraw czysto teoretycznie, trzeba powiedzie, e wszystkie relacje mog istnie tylko midzy dwoma encjami. Pod wzgldem logicznym mamy wic relacj midzy encjami Szkoly i Dyrektorzy. Pod wzgldem technicznym moemy zastosowa notacj z dwoma relacjami typu jeden-do-wielu czcymi te encje, ale skierowanymi przeciwnie. Innym rozwizaniem jest zastosowanie relacji z symbolem „wiele” umieszczonym po obu jej kocach. Z praktycznego punktu widzenia najwygodniej jednak bdzie utworzy trzeci encj obrazujc tak relacj, podobnie jak zostao to przedstawione na rysunku 2.6.

Rysunek 2.6. Encja Szkoly i Dyrektorzy — relacja wiele-do-wielu z trzeci encj


52

ROZDZIA 2. ELEMENTY WYKORZYSTANE W

LOGICZNYCH MODELACH DANYCH

Niektórzy stwierdz, e jest to pogwacenie ideau modelu logicznego, który nie powinien zawiera adnych elementów fizycznej implementacji. Zastosowanie trzeciej encji czcej encje Szkoly i Dyrektorzy za pomoc ich identyfikatorów jest odwzorowaniem fizycznej implementacji stosowanej wobec wielu relacji typu wiele-dowielu. Fizycznie nie jest moliwe odwzorowanie relacji tego typu bez wykorzystania trzeciej tabeli, nazywanej czasami tabel cznikow (ang. join table). Oznacza to, e wykorzystanie tej tabeli w modelu logicznym nie jest cile zgodne ze wskazówkami modelowania logicznego. Umieszczenie dodatkowej encji w modelu logicznym moe jednak uatwia zapamitanie, dlaczego zostaa uyta taka relacja. Bdzie te pomoc dla przyszych wspópracowników poznajcych dopiero wszystkie relacje w tym modelu. Zastosowanie trzeciej encji pozwala ponadto na wprowadzenie dodatkowych atrybutów opisujcych kady egzemplarz takiej relacji. Na przykad w encji Dyrektorzy_Szkoly mona doda informacj, od kiedy dany dyrektor zajmuje si okrelon szko. Jeeli istnieje wiele takich kombinacji, to informacja o czasie zajmowania stanowiska przez dan osob w danej szkole moe by bardzo przydatna. Relacje typu wiele-do-wielu s stosowane zadziwiajco czsto, ale zawsze naley podchodzi do nich bardzo ostronie i dokadnie je dokumentowa, tak eby nie byo adnych nieporozumie w trakcie tworzenia fizycznej implementacji modelu.

Opcje relacji Skoro znasz ju róne rodzaje relacji, musimy omówi jeszcze opcje, które moemy definiowa w relacjach poszczególnych typów. Opcje te pozwalaj na dokadniejsze sterowanie zachowaniem kadej relacji z osobna.

Relacje identyfikujce i nieidentyfikujce Jeeli klucz gówny encji zalenej wymaga doczenia klucza gównego encji nadrzdnej, to znaczy, e relacja czca te encje jest relacj identyfikujc (ang. identifying relation). Wynika to z tego, e unikatowy atrybut encji zalenej wymaga zastosowania wyjtkowego atrybutu encji nadrzdnej, aby jednoznacznie zidentyfikowa odpowiedni egzemplarz encji. Jeeli takie wymaganie nie istnieje, to relacja jest definiowana jako nieidentyfikujca (ang. non-identifying relation). W przypadku relacji identyfikujcej klucz gówny encji nadrzdnej jest faktycznie jednym z atrybutów skadajcych si na klucz gówny encji zalenej. Oznacza to, e klucz obcy encji zalenej jest czci lub nawet caoci jej klucza gównego. W przypadku relacji nieidentyfikujcej klucz gówny encji nadrzdnej jest tylko niekluczowym atrybutem encji zalenej. Zaledwie niewielka cz relacji to relacje identyfikujce, poniewa wikszo encji zalenych moe by referowanych cakowicie niezalenie od encji nadrzdnej. W relacjach typu wiele-do-wielu s jednak czsto stosowane relacje identyfikujce, jako e dodatkowa encja wie z sob klucze gówne encji nadrzdnej i zalenej. Na przykad encja Szkoly_Dyrektorzy z prezentowanego wczeniej rysunku 2.6. zawiera w caoci klucze gówne encji Szkoly (SzkolyID) i Dyrektorzy (DyrektorzyID).


RELACJE

53

Prosz zauway, e jest to typowe w przypadku relacji typu wiele-do-wielu. Klucz gówny tabeli cznikowej zawsze skada si z kluczy gównych dwóch pozostaych tabel. Dziki temu, e klucze gówne tabeli nadrzdnej i zalenej s od razu widoczne w tabeli cznikowej, moemy bez wahania powiedzie, e jest to relacja identyfikujca. Relacje nieidentyfikujce s zdecydowanie bardziej rozpowszechnione. Mona je rozpozna po tym, e atrybuty klucza gównego encji nadrzdnej s w encji zalenej atrybutami niekluczowymi. Jeeli nie istnieje jaki wany powód do tworzenia relacji identyfikujcej, to wikszo tworzonych w modelu relacji bdzie relacjami nieidentyfikujcymi.

Relacje opcjonalne i obowizkowe Kada relacja w bazie danych musi zosta okrelona jako opcjonalna lub obowizkowa. O relacjach obowizkowych mona myle jak o relacjach typu „musi mie”, podczas gdy relacje opcjonalne mona okrela jako relacje „moe mie”. Na przykad jeeli mamy encj Pracownik oraz encj Biuro, to kady pracownik „musi mie” swoje biuro. Relacja czca te dwie encje opisuje biuro danego pracownika. W takiej sytuacji jest tworzona relacja nieidentyfikujca, a poniewa w encji Pracownik nie moemy wpisa wartoci NULL do klucza obcego identyfikujcego biuro, okazuje si, e jest to równie relacja obowizkowa. Wskazuje ona, e kady pracownik ma przynajmniej jedno biuro, a nawet jeeli musi pracowa w innych biurach, to jedno z nich traktowane jest jako przypisane do niego. Teraz zajmijmy si sytuacj, w której samochody s przypisywane do pracowników firmy. Mona j odzwierciedli w modelu danych, czc z sob encje Pracownik i Samochód. Jak mona si domyli, pracownik „moe mie” samochód, cho wcale nie musi, co odpowiada definicji relacji opcjonalnej.

Liczno W przypadku kadej z opisywanych relacji podawalimy jedynie jej ogólny rodzaj: jeden-do-jednego, jeden-do-wielu lub wiele-do-wielu. Opis takiej relacji zawiera liczb rekordów w encji nadrzdnej, wizanych z pewn liczb rekordów w encji zalenej. Chcc dokadniej wymodelowa faktyczn relacj czc te dane, musimy poda nieco wicej informacji opisujcych te zalenoci — niezbdne jest okrelenie licznoci (ang. cardinality) danej relacji. W przypadku relacji jeden-do-jednego jej liczno jest ju z góry narzucona. Jednoznacznie stwierdzamy, e na kady rekord w encji nadrzdnej moe przypada dokadnie jeden rekord w encji zalenej. W sposób bardziej opisowy mona powiedzie, e na kady rekord w encji nadrzdnej przypada zero lub jeden rekord w encji zalenej. Jeeli jednak chcemy zaznaczy, e w obu encjach zawsze musi by dokadnie jeden rekord, to opis licznoci relacji powinien brzmie: na kady rekord w encji nadrzdnej przypada dokadnie jeden rekord w encji zalenej. Liczno relacji typu jeden-do-jednego jest zazwyczaj zapisywana jako [1:1].


54

ROZDZIA 2. ELEMENTY WYKORZYSTANE W

LOGICZNYCH MODELACH DANYCH

Relacje jeden-do-wielu s definiowane skrótem [1:M], a ich liczno mona opisa sowami: na kady rekord w encji nadrzdnej przypada jeden lub wicej rekordów w encji zalenej. Jeeli jednak chcemy dopuci sytuacj, w której w encji zalenej nie ma rekordów pasujcych do rekordów encji nadrzdnej, to mona zastosowa inny opis licznoci takiej relacji: na kady rekord w encji nadrzdnej przypada zero lub wicej rekordów w encji zalenej. W wikszoci relacji waciwsz interpretacj jest wersja „zero lub wicej”, dlatego w czasie tworzenia modelu naley dokadnie okreli wariant licznoci. Relacje typu wiele-do-wielu mona definiowa jako zero lub wicej do zera lub wicej rekordów. Jak si okazuje, ten rodzaj licznoci jest niemal zawsze odgórnie przyjmowany za domylny dla tych relacji, cho oczywicie moe zdefiniowa wymóg istnienia przynajmniej jednego rekordu w kadej z encji. W takim przypadku relacj typu wiele-do-wielu mona zapisa jako [M:M]. W niektórych programach do modelowania danych moliwe jest bardzo dokadne definiowanie licznoci relacji. Mona na przykad zdefiniowa liczno typu „na kady rekord w encji nadrzdnej przypada osiem rekordów w encji zalenej”. W ten sposób mona zdefiniowa osoby bezporednio podporzdkowane kierownikom (osoby podlegajce danemu menederowi). Firma moe przecie wymaga, aby pracujcy w niej meneder mia nie mniej ni cztery, ale nie wicej ni dwadziecia podporzdkowanych sobie bezporednio osób. W takiej sytuacji liczno relacji mona by opisa jako: przynajmniej cztery, ale nie wicej ni dwadziecia do jednego. Tego rodzaju licznoci wymagaj dokadnego udokumentowania, poniewa wikszo ludzi przyjmie po prostu ich domyln posta.

Uywanie podtypów i typów nadrzdnych Definiujc encje, które maj by wykorzystane w modelu danych, od czasu do czasu moemy wygenerowa tak, która bdzie si skada w caoci z kilku innych. W takiej sytuacji moemy mie problemy z okreleniem, które atrybuty nale do danej encji i jakie cz je relacje. Rozwizaniem moe si okaza zastosowanie typów nadrzdnych.

Definicje podtypów i typów nadrzdnych Typ nadrzdny (ang. supertype) jest encj majc wiele encji zalenych, nazywanych podtypami (ang. subtypes), które opisuj róne warianty tego samego typu nadrzdnego. Kolekcja typu nadrzdnego i wszystkich jego podtypów jest czasami nazywana klastrem podtypów (ang. subtype cluster). Takie klastry pojawiaj si najczciej przy okazji prac nad pewnymi kategoriami niektórych rzeczy, podobnie jak zostao to przedstawione na rysunku 2.7.


UYWANIE PODTYPร“W I TYPร“W NADRZDNYCH

55

Rysunek 2.7. Prosty klaster podtypรณw

Zaรณmy, e ledzimy informacje na temat produktรณw zwizanych z dostpem szerokopasmowym. W tym przykadzie Lacze jest encj z kilkoma atrybutami i kluczem gรณwnym. Chcemy jednak, eby rรณne rodzaje czy byy zapisywane w osobnych encjach, poniewa cza kablowe s oferowane klientom prywatnym i komercyjnym, a cza DSL โ€” wycznie klientom prywatnym. Oba rodzaje czy mogyby by zapisywane w cakowicie niezalenych encjach, ale w ten sposรณb stracilibymy cay obraz relacji. W encji Lacze znajduj si atrybuty, ktรณrych nie znajdziemy w pozostaych dwรณch encjach. Te dwie encje zawieraj natomiast atrybuty, ktรณrych prรณno szuka w encji Lacze. Poza tym przygotowany projekt musi by otwarty, na wypadek gdybymy w przyszoci chcieli doda kolejne rodzaje czy szerokopasmowych bez koniecznoci modyfikowania ju istniejcych. Chcc rozwiza ten problem, powinnimy przeksztaci encj Lacze w typ nadrzdny, a encje Kabel i DSL w podtypy. W tym celu najpierw musimy utworzy encje podtypรณw i nada im wszystkie niezbdne atrybuty, z wyjtkiem klucza gรณwnego. Nastpnie trzeba przygotowa obowizkow relacj identyfikujc, czc encj typu nadrzdnego z encjami podtypรณw. Taka relacja oznacza, e klucz gรณwny encji Lacze jest jednoczenie kluczem gรณwnym pozostaych dwรณch encji. Na zakoczenie niezbdne jest jeszcze wybranie dyskryminatora (ang. discriminator), czyli atrybutu w encji nadrzdnej, ktรณrego warto okrela podtyp danego rekordu. Dyskryminatorem moe by zarรณwno atrybut kluczowy, jak i niekluczowy. W tym przykadzie funkcj t peni atrybut Typ, ktรณry moe otrzyma warto DSL lub Kabel. Jeeli klaster podtypรณw zawiera ju wszystkie moliwe podtypy danego typu nadrzdnego, to mรณwi si o nim, e jest klastrem kompletnym. Jeeli jednak zawiera tylko cz moliwych podtypรณw, to o takim klastrze mรณwi si, e jest klastrem


56

ROZDZIA 2. ELEMENTY WYKORZYSTANE W

LOGICZNYCH MODELACH DANYCH

niekompletnym. Opisy klastra to sprawa zwizana wycznie z dokumentacj, ale podobnie jak ze wszystkimi innymi elementami tworzenia modelu, prawidowe dokumentowanie szczegóów moe bardzo uatwi nam prac w przyszoci. Fizyczna implementacja klastra podtypów jest zawsze zalena od konkretnego przypadku. Klastry podtypów mog by implementowane w postaci relacji typu jeden-do-jednego czcych encje i tabele albo w postaci rónych innych kombinacji tabel i czcych je relacji. Najistotniejszym zagadnieniem, o którym warto pamita, jest umieszczanie tego samego klucza gównego we wszystkich encjach skadajcych si na klaster, a take zastosowanie prawidowych ogranicze dyskryminatora, tak eby wszystkie rekordy znalazy si we waciwych tabelach.

Kiedy uywa klastrów podtypów Niemal kady model danych bdzie zawiera encje, które maj atrybuty, a te z kolei przechowuj informacje na temat maego podzbioru rekordów znajdujcych si w encji. Jeeli natkniemy si na tak sytuacj w swoim modelu danych, powinnimy dokadniej przyjrze si tym atrybutom i sprawdzi, czy nie mona z nich zbudowa klastra podtypów. Nie naley jednak za wszelk cen tworzy relacji budujcych klaster podtypów. W ten sposób skonstruujemy tylko zagmatwany model danych, zawierajcy wicej encji, ni faktycznie potrzeba. Co wicej, istnienie nadmiarowych klastrów podtypów bdzie bardzo utrudniao fizyczn implementacj modelu, prowadzc do powstawania niepotrzebnych tabel i ogranicze. To z kolei moe przekada si na pogorszenie wydajnoci caej bazy danych i w konsekwencji uniemoliwia jej prawidow obsug. Klastry podtypów mog by bardzo przydatnym narzdziem, wprowadzajcym do modelu danych wysoki poziom elastycznoci. Modelowanie danych za pomoc tego rodzaju uogólnionej hierarchii umoliwia wprowadzanie w przyszoci rónych modyfikacji bez koniecznoci poprawiania istniejcych encji, dlatego z pewnoci warto powici nieco czasu na poszukiwanie zwizków logicznych pozwalajcych na zastosowanie klastrów podtypów.

Podsumowanie W niniejszym rozdziale omówilimy narzdzia stosowane podczas tworzenia logicznego modelu danych. Kady model danych skada si z obiektów niezbdnych do prawidowego opisania przechowywanych danych, definicji wszystkich zwizków czcych poszczególne fragmenty danych oraz istniejcych ogranicze. Skoro znasz ju wszystkie elementy skadajce si na logiczne modele danych, moesz zajrze do rozdziau 3., w którym postaramy si agodnie przej od zagadnie zwizanych z obiektami logicznymi do tych dotyczcych ich fizycznej implementacji. Pó niej wykorzystamy te wszystkie informacje do zbudowania modelu danych dla firmy Mountain View Music.

Modelowanie danych w SQL Server 2005 i 2008. Przewodnik  

Dzięki tej książce zrozumiesz podstawowe techniki modelowania danych oraz dowiesz się, jak gromadzić wymagania dotyczące modelu. Ponadto zap...

Read more
Read more
Similar to
Popular now
Just for you