Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00157 003011 22421665 na godz. na dobę w sumie
wyszukaj dokładnie | pobierz wtyczkę
Modelowanie danych w SQL Server 2005 i 2008. Przewodnik - książka
Modelowanie danych w SQL Server 2005 i 2008. Przewodnik - książka
Autor: , Liczba stron: 280
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-2090-6 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> bazy danych >> sql server
Porównaj ceny (książka, ebook, audiobook).
Czytaj online.
Komentuj
Twórz wydajne modele danych!

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.

Dowiedz się wszystkiego o modelowaniu danych i Twórz wydajne rozwiązania!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

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 TRE¥CI WstÚp .................................................................................................13 O autorach ...........................................................................................15 Teoria modelowania danych ...................................... 17 CzÚĂÊ I Rozdziaï 1. PrzeglÈd technik modelowania danych ..................................... 19 Bazy danych ...................................................................................................... 20 Systemy zarzÈdzania relacyjnymi bazami danych .............................................21 Dlaczego dobrze zaprojektowany model danych jest tak waĝny ..................... 22 SpójnoĂÊ danych .............................................................................................22 SkalowalnoĂÊ ..................................................................................................23 Speïnianie wymagañ biznesowych ...................................................................25 ’atwe odczytywanie danych ............................................................................26 Poprawianie wydajnoĂci ..................................................................................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È wartoĂciÈ i z wieloma wartoĂciami ................................45 SpójnoĂÊ referencji ............................................................................................ 46 Relacje ............................................................................................................... 47 Typy relacji .....................................................................................................48 Opcje relacji ...................................................................................................52 LicznoĂÊ .........................................................................................................53 8 SPIS TRE¥CI Uĝywanie podtypów i typów nadrzÚdnych ....................................................... 54 Definicje podtypów i typów nadrzÚdnych .........................................................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ójnoĂci referencji .............................................................78 Programowanie ................................................................................................. 81 Procedury skïadowane ....................................................................................81 Funkcje uĝytkownika ......................................................................................82 Wyzwalacze ...................................................................................................83 Integracja z CLR .............................................................................................85 Implementowanie typów nadrzÚdnych i podtypów ......................................... 85 Tabela typu nadrzÚdnego ................................................................................86 Tabele podtypów ............................................................................................87 Tabele typu nadrzÚdnego i podtypów ..............................................................87 Typy nadrzÚdne i podtypy — podsumowanie ...................................................88 Podsumowanie .................................................................................................. 88 Rozdziaï 4. Normalizowanie modelu danych .............................................. 91 Czym jest normalizacja? .................................................................................... 91 Postaci normalne ............................................................................................91 OkreĂlanie postaci normalnych ......................................................................... 99 Denormalizacja ............................................................................................... 100 Podsumowanie ................................................................................................ 102 CzÚĂÊ II Wymagania biznesowe ........................................... 105 Rozdziaï 5. Gromadzenie wymagañ ........................................................ 107 PrzeglÈd zagadnieñ zwiÈzanych ze zbieraniem wymagañ ............................... 108 Zbieranie wymagañ krok po kroku ................................................................. 108 Prowadzenie wywiadów ................................................................................108 Obserwacje ..................................................................................................111 IstniejÈce procesy i systemy ..........................................................................112 Przypadki uĝycia ...........................................................................................114 SPIS TRE¥CI 9 Potrzeby biznesowe ........................................................................................ 120 Szukanie zïotego Ărodka miÚdzy ograniczeniami technicznymi i potrzebami biznesowymi ................................................................................................... 121 Zbieranie danych uĝytkowych ........................................................................ 121 Odczyty a zapisy ..........................................................................................121 Wymagania dotyczÈce 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 przepïywu ..............................................................134 Interpretowanie istniejÈcych systemów .........................................................137 Interpretowanie przypadków uĝycia ..............................................................139 OkreĂlanie atrybutów ...................................................................................141 OkreĂlanie 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 przyszïoĂÊ — 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 dotyczÈce nazewnictwa ...................................................................153 Standardy notacji .........................................................................................156 NarzÚdzia do modelowania ...........................................................................159 Wykorzystywanie wymagañ do budowania modelu ....................................... 160 Lista encji ....................................................................................................160 Lista atrybutów ............................................................................................164 Dokumentacja relacji ...................................................................................165 Reguïy biznesowe .........................................................................................166 10 SPIS TRE¥CI 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 maïo encji ............................................................................................173 Zbyt wiele encji ............................................................................................176 Problemy z atrybutami .................................................................................... 177 Jeden atrybut zawierajÈcy róĝne dane ...........................................................177 NiewïaĂciwe 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 reguïy nazewnictwa ..........................................................................191 Nazywanie tabel ..........................................................................................194 Nazywanie kolumn .......................................................................................195 Nazwy widoków ...........................................................................................195 Nazywanie procedur skïadowanych ...............................................................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 licznoĂci ..................................................214 Podsumowanie ................................................................................................ 216 SPIS TRE¥CI 11 Rozdziaï 10. Kilka sïów na temat indeksów ............................................... 217 PrzeglÈd indeksów .......................................................................................... 217 Czym sÈ indeksy? ..........................................................................................218 Rodzaje ........................................................................................................220 Wymagania dotyczÈce korzystania z bazy danych .......................................... 226 Odczyty i zapisy ...........................................................................................226 Dane transakcji ............................................................................................228 OkreĂlanie wïaĂciwych indeksów ................................................................... 228 PrzeglÈdanie wzorów dostÚpu do danych .......................................................228 Równowaĝenie indeksów ..............................................................................229 Indeksy pokrywajÈce .....................................................................................230 Statystyki indeksów ......................................................................................230 Rozwaĝania na temat obsïugi 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 uĝywaÊ warstwy abstrakcji? .................................................................. 238 Bezpieczeñstwo ............................................................................................238 ElastycznoĂÊ i moĝliwoĂÊ rozbudowy .............................................................240 ZwiÈzek warstwy abstrakcji z logicznym modelem danych ............................ 241 ZwiÈzek warstwy abstrakcji z programowaniem zorientowanym obiektowo ......241 Implementowanie warstwy abstrakcji ............................................................. 243 Widoki .........................................................................................................243 Procedury skïadowane ..................................................................................245 Inne skïadniki warstwy abstrakcji ..................................................................248 Podsumowanie ................................................................................................ 248 CzÚĂÊ V Dodatki ................................................................251 Dodatek A Przykïadowy model logiczny .................................................. 253 Dodatek B Przykïadowy model fizyczny .................................................. 257 Dodatek C Zarezerwowane sïowa 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 pierw- szych pytañ, jakie w takiej sytuacji naleĝaïoby sobie postawiÊ, jest: „Czy mam wszyst- kie potrzebne narzÚdzia i materiaïy?” Aby na takie pytanie odpowiedzieÊ, potrzebuje- my projektu tego domu. To wïaĂnie z projektu bÚdziemy w stanie wywnioskowaÊ, jakie narzÚdzia i materiaïy bÚdÈ niezbÚdne. Oznacza to, ĝe na poczÈtek musimy sobie przygotowaÊ projekt. Jeĝeli wczeĂniej tego nie robiliĂmy, to najprawdopodobniej bÚdziemy musieli dowiedzieÊ siÚ, jak naleĝy 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 moĝna zaprezentowaÊ wszystkim stronom biorÈcym udziaï w projekcie. Z tych wïaĂnie powodów logiczny model danych moĝe byÊ caïkowicie oderwany od technicz- nych szczegóïów zwiÈzanych z konkretnym systemem zarzÈdzania bazami danych. Informacje zawarte w modelu logicznym definiujÈ jedynie sposób, w jaki baza danych zbudowana na podstawie tego modelu bÚdzie speïniaïa biznesowe wymagania klienta. Zanim jednak przystÈpimy do konstruowania modelu logicznego, koniecz- nie musimy poznaÊ wszystkie narzÚdzia, jakich bÚdziemy potrzebowali. W tym rozdziale omówimy obiekty i koncepcje powiÈzane z procesem tworze- nia 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 moĝna tworzyÊ relacje miÚdzy nimi. Encje Encje reprezentujÈ logiczne grupy danych, dlatego w modelu logicznym sÈ najwaĝ- niejszym elementem, który definiuje sposób zapisu danych w bazie. Typowymi przykïadami encji sÈ klienci, zamówienia lub produkty. Kaĝda encja, która powinna reprezentowaÊ pojedynczy typ informacji, skïada siÚ z caïej kolekcji egzemplarzy tej encji. Egzemplarz (ang. instance) encji jest bardzo podobny do rekordu bazy danych. W teorii modelowania danych pojÚcia egzemplarza, rekordu lub wiersza 38 ROZDZIA’ 2. ELEMENTY WYKORZYSTANE W LOGICZNYCH MODELACH DANYCH sÈ uĝywane zamiennie. W tej ksiÈĝce egzemplarz bÚdzie pojawiaï siÚ wyïÈcznie w encjach, natomiast rekordy lub wiersze bÚdÈ elementami fizycznych tabel lub widoków. CzÚsto moĝemy ulegaÊ pokusie traktowania poszczególnych encji jako tabel (w koñcu miÚdzy tabelami a encjami istniejÈ zwykle zwiÈzki typu jeden do jednego), trzeba jednak pamiÚtaÊ, ĝe logiczna encja moĝe byÊ reprezentowana przez wiele tabel, a wiele encji moĝe zostaÊ zgromadzonych w ramach jednej tabeli. Zadaniem encji jest identyfikacja wszystkich informacji, które bÚdÈ zapisywane w bazie danych. Jednym ze sposobów na okreĂlenie, co moĝna zakwalifikowaÊ jako encjÚ, jest myĂlenie o encjach jak o rzeczownikach. Encje zwykle sÈ obiektami, które moĝna opisaÊ za pomocÈ rzeczownika: zamówieniami, samochodami, trÈbkami albo telefo- nami, czyli przedmiotami znanymi nam na co dzieñ. WïaĂciwe zdefiniowanie encji na potrzeby modelu jest niezwykle istotne, dlatego to zadanie stanowi zawsze jednÈ z wiÚkszych czÚĂci procesu projektowania. DefiniujÈc encje, powinniĂmy przede wszystkim zajmowaÊ siÚ ich przeznacze- niem, a dopiero w dalszej kolejnoĂci zastanawiaÊ siÚ nad ich atrybutami i innymi szczegóïami (atrybuty zostanÈ opisane w nastÚpnym podrozdziale). Wywiady prowa- dzone z pracownikami firmy i innymi osobami odpowiedzialnymi za jej funkcjonowa- nie w ramach procesu gromadzenia wymagañ biznesowych (bÚdzie o tym mowa w rozdziale 5.) pozwolÈ nam okreĂliÊ najczÚĂciej uĝywane w firmie rzeczowniki, a co za tym idzie, najistotniejsze encje. Po rozpoczÚciu projektowania modelu to wïaĂnie z tych notatek bÚdziemy korzystaÊ do okreĂlania wszystkich niezbÚdnych encji. Musimy przy tym bardzo ostroĝnie przeglÈdaÊ i filtrowaÊ sporzÈdzone wcze- Ăniej notatki, tak ĝeby wykorzystaÊ tylko te informacje, które sÈ rzeczywiĂcie istotne w aktualnym projekcie. Atrybuty Kaĝda encja jest opisywana przez pewne szczegóïowe informacje, które sÈ wïaĂnie jej atrybutami. Zaïóĝmy, ĝe musimy utworzyÊ encjÚ przechowujÈcÈ wszystkie infor- macje opisujÈce kapelusze. Otrzyma ona nazwÚ Kapelusze, a nastÚpnie bÚdziemy mogli okreĂliÊ, jakie informacje, czyli atrybuty, musimy w niej zachowaÊ: kolor, nazwÚ producenta, styl, materiaï itp. W czasie konstruowania modelu definiujemy kolejkÚ atrybutów, które bÚdÈ przechowywaïy te dane w ramach encji. Definicja atrybutu skïada siÚ z jego nazwy, opisu, celu i typu danych (typy danych zostanÈ omówione w nastÚpnym podrozdziale). Naleĝy siÚ przy tym wystrzegaÊ dodawania do encji atrybutów, które tak naprawdÚ powinny byÊ czÚĂciÈ innej encji. Typowy bïÈd polega na bezpoĂrednim przeksztaï- caniu danych z fizycznej dokumentacji, takiej jak wydrukowane arkusze kalkula- cyjne lub podrÚczniki, w encje i atrybuty modelu logicznego. Na przykïad informacje na temat klienta sÈ czÚsto fizycznie ïÈczone z informacjami na temat zamówienia. Moĝna z tego wysnuÊ bïÚdne zaïoĝenie, ĝe informacje dotyczÈce klienta, takie jak adres lub numer telefonu, sÈ atrybutami zamówienia. W rzeczywistoĂci klient i zamó- wienie sÈ caïkowicie niezaleĝnymi encjami. Zapisanie atrybutów klienta w ramach ATRYBUTY 39 encji zamówienia spowoduje niepotrzebne skomplikowanie procesu odczytywania danych i moĝe doprowadziÊ do powstania projektu, który nie bÚdzie poddawaï siÚ skalowaniu. ChcÈc prawidïowo modelowaÊ atrybuty encji, musimy poznaÊ kilka najwaĝniej- szych pojÚÊ: typy danych, klucze, domeny i wartoĂci. W kolejnych podrozdziaïach nieco dokïadniej 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 bÚdzie zapisywana w atrybucie. Na przykïad atrybut moĝe byÊ ciÈgiem znaków, liczbÈ albo wartoĂciÈ logicznÈ typu prawda-faïsz. W modelach logicznych okreĂlenie typów danych atrybutów nie jest absolutnie wymagane. Ze wzglÚdu na to, ĝe typ danych jest okreĂleniem fizycznego sposobu zapisu danych, okreĂlenie typu danych atrybutu nastÚpuje w czasie tworzenia modelu fizycznego. Trzeba jednak pamiÚtaÊ, ĝe okreĂlajÈc typ danych juĝ w trakcie przy- gotowywania modelu logicznego, moĝemy uzyskaÊ kilka waĝnych korzyĂci: „ Zespóï tworzÈcy model fizyczny bÚdzie dysponowaï juĝ pewnym przewodni- kiem i nie bÚdzie musiaï wyszukiwaÊ informacji w zbiorze wymagañ (czasami moĝe siÚ to okazaÊ dziaïaniem wielokrotnym). „ BÚdziemy mogli wykryÊ nieĂcisïoĂci powstajÈce pomiÚdzy encjami przecho- wujÈcymi ten sam typ danych (na przykïad numer telefonu), i to jeszcze przed powstaniem modelu fizycznego. „ W ramach uïatwienia procesu budowania fizycznej bazy danych moĝemy zdefiniowaÊ typy danych ĂciĂle zwiÈzane z uĝywanym systemem relacyjnych baz danych. Moĝna to zrobiÊ tylko wtedy, gdy docelowy system zarzÈdzania bazÈ danych bÚdzie znany jeszcze przed rozpoczÚciem prac nad modelem. WiÚkszoĂÊ dostÚpnych programów do modelowania danych pozwala na wybranie spoĂród typów danych stosowanego systemu zarzÈdzania bazÈ danych. Skoro mamy pracowaÊ z serwerem Microsoft SQL Server, moĝemy od razu korzystaÊ z typów danych obsïugiwanych 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 ciÈgu znaków, niezaleĝnie od tego, czy zawierajÈ one znaki alfabetu, czy teĝ cyfry (pod warunkiem ĝe te nie biorÈ udziaïu w obliczeniach matematycznych). Przykïadami tego typu danych mogÈ byÊ nazwy, adresy albo numery telefonów. Konkretne typy danych uĝywane do przechowywania informacji alfanumerycznych to char, nchar, varchar i nvarchar. Jak moĝna 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È okreĂlenia ich dïugoĂci. MówiÈc ogólnie, dïugoĂÊ definiuje caïkowitÈ liczbÚ znaków, jaka moĝe znaleěÊ siÚ w danym atrybucie. Jeĝeli mamy pewnoĂÊ, ĝe dany atrybut bÚdzie przechowywaÊ tylko dwuliterowe skróty nazw pañstw, to moĝemy zdefiniowaÊ go jako char(2). W ten sposób definiuje- my atrybut jako alfanumeryczne pole mieszczÈce w sobie dokïadnie dwa znaki. Atry- buty typu char przechowujÈ dokïadnie tyle znaków, ile okreĂla ich definicja — nie mniej i nie wiÚcej, niezaleĝnie od tego, ile znaków faktycznie do nich wprowadzono. Kaĝdy zapewne zauwaĝyï juĝ, ĝe istniejÈ aĝ cztery rodzaje znakowego typu da- nych: dwa z przedrostkiem var i dwa z przedrostkiem n (jeden z tych typów zawiera oba te przedrostki). Pola o zmiennej dïugoĂci sÈ definiowane jako zawierajÈce nie wiÚcej znaków, niĝ zostaïo to podane w definicji pola. Aby zobrazowaÊ róĝnicÚ miÚdzy typami char i varchar, moĝna podaÊ, ĝe definicja char(10) tworzy pole o dïugoĂci dziesiÚciu znaków, nawet jeĝeli konkretny egzemplarz tego pola bÚdzie miaï dïugoĂÊ szeĂciu znaków. W takim przypadku pozostaïe cztery znaki zostanÈ automatycznie dopisane. Jeĝeli ten atrybut zostanie zdefiniowany jako varchar(10), to w podobnej sytuacji zapisanych zostanie tylko szeĂÊ znaków. Przedrostek n oznacza, ĝe znaki bÚdÈ zapisywane w formacie Unicode. Jest to miÚdzynarodowa, niezaleĝna od platformy specyfikacja przeznaczona do zapisywania znaków. Uĝywanie Unicode’u pozwala na budowanie systemów pracujÈcych ze znakami róĝnych jÚzyków. Systemy takie mogÈ bez ĝadnych problemów wymieniaÊ miÚdzy sobÈ dane tekstowe, wïaĂnie dziÚki zastosowaniu wspólnej metody zapisu znaków. Jeĝeli tylko musimy zapisaÊ znaki wykraczajÈce poza standardowy zestaw ASCII konieczne jest zastosowanie Unicode’u. PodstawowÈ róĝnicÈ miÚdzy systemami korzystajÈcymi z Unicode’u a systemami uĝywajÈcymi tylko znaków ASCII jest to, ĝe kaĝdy znak Unicode zajmuje dwa bajty, podczas gdy znaki ASCII zajmujÈ tylko jeden znak (jeĝeli sÈ zapisywane dane o zmiennej dïugoĂci, moĝe siÚ okazaÊ, ĝe jest potrzebny wiÚcej niĝ jeden bajt). Problem z systemami zapisujÈcymi znaki w jednym bajcie polega na tym, ĝe nie sÈ one w stanie skutecznie zapisaÊ pewnych znaków, takich jak japoñskie znaki Kanji albo koreañskie znaki Hangul. W tym przypadku trzeba rozwaĝyÊ, czy waĝniejsza jest wygoda zapisywania danych, czy moĝe wydajnoĂÊ pracy. Zagadnienie to bÚdziemy omawiaÊ dokïadniej w rozdziale 3. Na razie proszÚ pamiÚtaÊ, ĝe jeĝeli chcemy prze- chowywaÊ w bazie pewne typy tekstów, niezbÚdne moĝe okazaÊ siÚ uĝycie znaków w formacie Unicode. Numeryczne Dane numeryczne to dowolne dane, które muszÈ zostaÊ zapisane w postaci licz- bowej. Na wszystkich typach danych numerycznych moĝemy wykonywaÊ obliczenia matematyczne. WĂród najogólniejszych typów danych numerycznych znajdziemy typy caïkowite (integer), dziesiÚtne (decimal), walutowe (money), zmiennoprzecin- kowe (float) i rzeczywiste (real). Typy caïkowite zawsze sÈ zapisywane w postaci liczby caïkowitej. Ten typ da- nych pozwala na zapisywanie liczb dodatnich i ujemnych, a dodatkowo istnieje on w kilku wielkoĂciach, z których kaĝda pozwala na przechowywanie okreĂlonego ATRYBUTY 41 zakresu wartoĂci. Typy dziesiÚtne sÈ liczbami o z góry zdefiniowanej wielkoĂci i dokïadnoĂci. WielkoĂÊ typu oznacza w tym przypadku ogólnÈ liczbÚ cyfr, jakie moĝna zapisaÊ w danym polu, natomiast dokïadnoĂÊ okreĂla, ile z tych cyfr zostanie zapisanych po przecinku. Typ walutowy jest przeznaczony do zapisywania wartoĂci kwot, a jego dokïadnoĂÊ jest uzaleĝniona od stosowanego wïaĂnie systemu zarzÈ- dzania bazami danych. Typ zmiennoprzecinkowy opisuje liczby zmiennoprzecin- kowe, a zatem liczby zapisywane z pewnym przybliĝeniem. WartoĂci tego typu sÈ najczÚĂciej zapisywane w notacji naukowej. Dodatkowo moĝliwe jest zdefiniowanie liczby bitów, w której majÈ byÊ przechowywane liczby. Typy rzeczywiste sÈ wïa- Ăciwie identyczne z typami zmiennoprzecinkowymi, ale typy zmiennoprzecinkowe umoĝliwiajÈ przechowywanie znacznie wiÚkszych liczb. Podobnie jak w przypadku typów danych alfanumerycznych szczegóïowe infor- macje na temat fizycznego zapisywania danych tych typów zostaïy przedstawione w rozdziale 3. Logiczne Typy logiczne (boolean) umoĝliwiajÈ przechowywanie tylko trzech wartoĂci: prawdy (TRUE), faïszu (FALSE) lub zera (NULL). Dane przechowywane w polach tego typu sÈ logiczne, fizycznym typem danych jest jednak jeden bit. Moĝe on przechowywaÊ wartoĂÊ 1, 0 lub NULL, które moĝna przetïumaczyÊ jako prawdÚ, faïsz i nic. Logiczne typy danych sÈ uĝywane do przechowywania wyników róĝnych wyraĝeñ logicznych. CzÚsto stosowane sÈ teĝ jako przeïÈczniki lub flagi, na przykïad wskazujÈce, ĝe dany pojazd jest aktualnie niesprawny. BLOB i CLOB Nie wszystkie dane przechowywane w bazie danych muszÈ mieÊ postaÊ czytelnÈ dla uĝytkownika. Na przykïad baza danych zbierajÈca informacje sklepu interne- towego oprócz danych opisujÈcych poszczególne produkty moĝe równieĝ zawieraÊ ich obrazy. Binarne dane skïadajÈce siÚ na informacje o obrazie nie nadajÈ siÚ do czytania w postaci ciÈgu znaków, ale mogÈ zostaÊ zapisane w bazie danych, tak ĝeby mogïa z nich skorzystaÊ aplikacja. Tego rodzaju dane sÈ zwykle nazywane wielkimi obiektami binarnymi (ang. binary large object — BLOB). Takie informacje w serwerze SQL Server najczÚĂciej sÈ zapisywane za pomocÈ nastÚpujÈcych typów danych: binary, varbinary i image. Podobnie jak w przypadku typów znakowych przedrostek var oznacza, ĝe dany atrybut moĝe przechowywaÊ wartoĂci o zmiennej dïugoĂci. W zwiÈzku z tym typ binary definiuje atrybut o staïej wielkoĂci, przechowujÈcy dane binarne, a typ varbinary okreĂla tylko maksymalnÈ wielkoĂÊ atrybutu przechowujÈcego dane binarne. Z kolei typ image okreĂla, ĝe atrybut zawiera dane binarne o zmiennej wielkoĂci, podobne do typu varbinary. Typ ten daje jednak znacznie wiÚksze moĝliwoĂci przechowywania danych. Dane znakowe równieĝ mogÈ siÚ pojawiaÊ w formach o wiele dïuĝszych, niĝ przewidujÈ to typowe typy danych alfanumerycznych, o których mówiliĂmy wcze- Ăniej. Co zrobiÊ, jeĝeli w danym atrybucie musimy zapisaÊ tekst dowolnej wielkoĂci, 42 ROZDZIA’ 2. ELEMENTY WYKORZYSTANE W LOGICZNYCH MODELACH DANYCH na przykïad caïy ĝyciorys? W tej sytuacji z pomocÈ przychodzÈ nam dwa typy wiel- kich obiektów znakowych (ang. character large object — CLOB), czyli text i ntext. Te dwa typy danych sÈ przeznaczone do przechowywania duĝych iloĂci tekstu w postaci jednego pola. Podobnie jak byïo to w przypadku pozostaïych typów znakowych, przedrostek n oznacza, ĝe tekst w danym atrybucie jest zapisywany w formacie Unicode. Z tych typów danych naleĝy korzystaÊ wtedy, gdy w ramach jednego atry- butu encji musimy zapisaÊ naprawdÚ duĝe iloĂci danych alfanumerycznych. Data i czas Niemal kaĝdy istniejÈcy model danych wymaga zastosowania encji zawierajÈcych atrybuty opisujÈce daty lub czas. PozwalajÈ one na okreĂlenie momentu, w którym wprowadzono zmiany do zamówienia, daty zatrudnienia nowego pracownika albo zdefiniowanie czasu dostawy towarów. Kaĝdy system zarzÈdzania relacyjnymi ba- zami danych ma swojÈ wïasnÈ implementacjÚ typów danych pozwalajÈcych na zapi- sywanie daty i czasu. W przypadku serwera SQL Server 2008 mamy do dyspozycji aĝ szeĂÊ typów danych tego rodzaju. Jest to duĝy postÚp w stosunku do poprzednich wersji tego serwera, które oferowaïy jedynie dwa typy: datetime i smalldatetime. Kaĝdy z tych typów danych przechowuje informacje na temat daty lub czasu. Róĝ- nice wynikajÈ jedynie z dokïadnoĂci zapisanej daty i zakresu dostÚpnych wartoĂci. Przyjrzyjmy siÚ starszym typom. Typ datetime przechowuje dane dotyczÈce daty i czasu z dokïadnoĂciÈ do jednej milisekundy. Zaïóĝmy, ĝe do tabeli zawierajÈcej 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 zapisaïby tÚ samÈ wartoĂÊ w postaci: 12/01/2008 18:00 Typ datetime moĝe przechowywaÊ dowolnÈ datÚ z zakresu od 1 stycznia 1753 roku do 31 grudnia 9999 roku, a typ smalldatetime pozwala na zapisanie daty z za- kresu od 1 stycznia 1900 roku do 6 czerwca 2079 roku. Powodem wybrania tych wïaĂnie dat, trzeba przyznaÊ, ĝe doĂÊ dziwnych, sÈ wymagania zwiÈzane z metodami zapisu na poziomie dysku twardego oraz z metodami manipulacji na datach w ser- werze SQL Server. Jak juĝ wczeĂniej wspominaliĂmy, SQL Server 2008 wprowadza cztery nowe typy danych zwiÈzanych z datÈ i czasem: date, time, datetime2 i datetimeoffset. Nowe typy danych przechowujÈ informacje o dacie i czasie w sposób duĝo elastyczniejszy niĝ poprzednie. Najprostsze sÈ oczywiĂcie 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 dokïadnoĂci zapisywania uïamków sekund od zera do siedmiu miejsc po przecinku. Z kolei typ danych da- tetimeoffset róĝni siÚ od typu datetime moĝliwoĂciÈ zapisania oprócz daty i czasu ATRYBUTY 43 pewnej wartoĂci przesuniÚcia. Nie musi byÊ ono zwiÈzane z ĝadnÈ strefÈ czasowÈ ani nawet z czasem Greenwich. Musimy zatem pamiÚtaÊ, wzglÚdem której strefy czasowej naleĝy je liczyÊ. OmówiliĂmy juĝ sporo szczegóïów, ale ponownie przypomnimy, ĝe jeszcze dïuĝ- szy wywód na temat metod przechowywania informacji w ramach poszczególnych typów danych znajduje siÚ w rozdziale 3. W czasie projektowania modelu logicznego moĝemy ulec pokusie nadawania atrybutom róĝnych typów danych. Takie praktyki mogÈ jednak powodowaÊ wiele problemów podczas dalszych prac. WiÚkszoĂÊ programów do modelowania danych jest w stanie wygenerowaÊ model fizyczny na podstawie modelu logicznego, a zatem wybranie niewïaĂciwych typów danych w modelu logicznym moĝe doprowadziÊ do nieprawidïowoĂci w modelu fizycznym, szczególnie gdy pracuje nad nim kilka osób. Naleĝy czÚsto zaglÈdaÊ do zebranych wymagañ biznesowych, tak ĝeby uzyskaÊ pewnoĂÊ, ĝe faktycznie definiujemy atrybuty zgodne z danymi uĝywanymi w firmie. Uïatwi nam to równieĝ rozmowy na temat modelu danych prowadzone z pracow- nikami, 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 kaĝdy egzemplarz danej encji. Zawsze musi zawieraÊ dane i nigdy nie moĝe byÊ pusty. Jako przykïady kluczy gïównych moĝna podaÊ numery identyfikacyjne pracowników albo numery ISBN ksiÈĝek. W czasie tworzenia modelu musimy pamiÚtaÊ o tym, ĝe niemal kaĝda zawarta w nim encja musi mieÊ klucz gïówny, nawet jeĝeli musimy go utworzyÊ sztucznie za pomocÈ jakiejĂ liczby. Jeĝeli dane nie majÈ przypisanego klucza gïównego, to czÚsto niezbÚdne jest dodanie do tabeli kolumny, która bÚdzie sïuĝyïa jako taki wïaĂnie klucz. Tego rodzaju klucze nazywane sÈ kluczami zastÚpczymi. Co prawda, taka praktyka jest juĝ bardziej zbliĝona do fizycznego projektowania bazy danych, ale modelowanie klucza zastÚp- czego pozwala na tworzenie relacji na podstawie kluczy gïównych. Takie klucze sÈ zwykle liczbami, których wartoĂÊ jest zwiÚkszana dla kaĝdego wiersza dodawanego do tabeli. W przypadku serwera SQL Server liczby te nazywane sÈ toĝsamoĂciami (ang. Identity). Inna reguïa dobrego modelowania mówi, ĝe nie naleĝy uĝywaÊ opisowych atry- butów jako kluczy gïównych. Na przykïad w tabelach opisujÈcych pracowników czÚsto jako klucz gïówny jest uĝywany numer PESEL. Nie jest to dobre rozwiÈzanie z co najmniej kilku powodów. Po pierwsze, chodzi o wzglÚdy bezpieczeñstwa i zacho- wanie prywatnoĂci. Wiele kradzieĝy toĝsamoĂci dochodzi do skutku wïaĂnie dlatego, ĝe zïodziej ma dostÚp do numeru PESEL ofiary. Po drugie, numery PESEL powinny byÊ unikatowe, ale nie moĝna wykluczyÊ sytuacji, w której zostanÈ zmienione. Po trzecie, moĝe siÚ okazaÊ, ĝe przyjdzie nam zarejestrowaÊ pracowników za- granicznych, którzy nie majÈ numeru PESEL. W takiej sytuacji kuszÈce moĝe byÊ wygenerowanie po prostu sztucznego numeru, ale co bÚdzie, jeĝeli zagraniczny pracownik otrzyma obywatelstwo, a razem z nim wïasnym numer PESEL? W takiej 44 ROZDZIA’ 2. ELEMENTY WYKORZYSTANE W LOGICZNYCH MODELACH DANYCH sytuacji wiersze encji zaleĝnych mogÈ byÊ poïÈczone z prawdziwym lub niepraw- dziwym numerem PESEL, przez co odczytywanie danych bardzo siÚ skomplikuje, a co gorsza, w bazie mogÈ pojawiÊ siÚ osierocone wiersze. MówiÈc ogólnie, klucz gïówny powinien: „ byÊ caïkowicie unikatowy i absolutnie niezmienny, „ skïadaÊ siÚ z atrybutów, które nigdy nie bÚdÈ puste, „ korzystaÊ z nieznaczÈcych danych, jeĝeli tylko jest to moĝliwe. Z kluczem gïównym jest ĂciĂle powiÈzany klucz obcy (ang. Foreign Key — FK). SkïadajÈ siÚ na niego atrybuty dane encji, które bazujÈ na kluczu (najczÚĂciej na kluczu gïównym) innej encji. Przyjrzyjmy siÚ przykïadowej encji Pracownik oraz caïkowicie nowej encji Pojazd. Jeĝeli chcielibyĂmy wiedzieÊ, któremu pracownikowi przypisano dany samochód, to musielibyĂmy poïÈczyÊ te dwie encje relacjÈ. W takiej sytuacji w encji Pojazd musi istnieÊ klucz obcy wskazujÈcy na klucz gïówny w tabeli Pracownik. NajproĂciej moĝna to zrealizowaÊ, dodajÈc do encji Pojazd atrybut przechowujÈcy numer pracownika, któremu przypisano dany samochód. Atrybuty w encji referujÈcej mogÈ byÊ atrybutami kluczowymi, ale równieĝ niekluczowymi. Oznacza to, ĝe klucz obcy w encji referujÈcej moĝe skïadaÊ siÚ z tych samych atry- butów co jej klucz gïówny, ale moĝe zostaÊ zbudowany z caïkowicie innego zestawu atrybutów. Taka kombinacja klucza gïównego i klucza obcego pozwala na zachowanie spójnoĂci w logicznych relacjach miÚdzy encjami. Domeny ZaczynajÈc budowaÊ model danych, z pewnoĂciÈ zauwaĝymy, ĝe w kontekĂcie danych, nad którymi pracujemy, pewne encje zawierajÈ podobne atrybuty. Bardzo czÚsto ze wzglÚdu na spójnoĂÊ informacji czÚĂÊ danych zwiÈzana z funkcjonowaniem aplikacji lub firmy musi mieÊ takÈ samÈ postaÊ we wszystkich encjach. Status, adres, numer telefonu i adres e-mail sÈ przykïadami atrybutów, które najprawdopodobniej bÚdÈ musiaïy mieÊ identycznÈ postaÊ w wielu encjach. Zamiast ĝmudnie tworzyÊ i ewen- tualnie modyfikowaÊ te atrybuty w poszczególnych encjach, moĝemy skorzystaÊ z domen. Domena jest definicjÈ atrybutu, która jest przechowywana w ramach modelu logicznego, ale poza jakÈkolwiek encjÈ. Jeĝeli w encji zostanie wykorzystany atrybut bÚdÈcy czÚĂciÈ domeny, to domena ta zostanie doïÈczona do encji. Trzeba jednak pamiÚtaÊ, ĝe model danych nie przedstawia widocznej informacji o tym, ĝe dany atrybut jest czÚĂciÈ pewnej domeny. WiÚkszoĂÊ narzÚdzi do modelowania udostÚpnia jednak specjalnÈ sekcjÚ lub dokument, taki jak sïownik danych, w którym sÈ prze- chowywane informacje o domenach. Jeĝeli jakiekolwiek zmiany zostanÈ wprowadzone do domeny, to wszystkie zwiÈzane z niÈ atrybuty we wszystkich encjach oraz doku- mentacja zawierajÈca dane o domenach zostanÈ odpowiednio dopasowane. Przyjrzyjmy siÚ na przykïad atrybutowi numeru telefonu. Bardzo czÚsto w mo- delach logicznych numery telefonów sÈ projektowane jako numery lokalizowane. W Polsce taki numer jest zwykle zapisywany w postaci trzech cyfr numeru kierun- kowego, za którymi znajduje siÚ lokalny numer telefonu (XXX-XXXXXXX). Jeĝeli ATRYBUTY 45 w dalszych pracach nad modelem zdecydujemy siÚ zapisywaÊ równieĝ numery miÚdzynarodowe, a atrybut numeru telefonu znalazï siÚ juĝ w wielu encjach, to bÚdziemy zmuszeni do edytowania wszystkich wystÈpieñ tego atrybutu. Jeĝeli jednak przygotujemy sobie domenÚ numeru telefonu i dodamy jÈ do wszystkich encji prze- chowujÈcych taki numer, to wszelkie zmiany wprowadzane póěniej do domeny bÚdÈ od razu przenoszone do wszystkich encji w tym modelu. CzÚste stosowanie domen pozwala na unikniÚcie niedogodnoĂci zwiÈzanych z maïymi róĝnicami miÚdzy atrybutami przechowujÈcymi te same dane w róĝnych encjach. Praktyka ta pozwala na wymuszenie spójnoĂci danych i skrócenie czasu projektowania, nie tylko w okresie poczÈtkowych prac nad modelem, ale równieĝ w czasie funkcjonowania bazy danych. Atrybuty z pojedynczÈ wartoĂciÈ i z wieloma wartoĂciami Wszystkie omawiane do tej pory atrybuty byïy atrybutami z pojedynczÈ wartoĂciÈ (ang. single-valued attributes). Oznacza to, ĝe dla kaĝdego unikatowego elementu w encji istnieje tylko po jednej wartoĂci zapisanej w poszczególnych atrybutach. Niektóre atrybuty mogÈ jednak w sposób naturalny przyjmowaÊ wiÚcej niĝ jednÈ wartoĂÊ. SÈ one nazywane atrybutami z wieloma wartoĂciami (ang. multivalued attributes). Zidentyfikowanie ich moĝe byÊ kïopotliwe, ale obsïuga jest bardzo prosta. Bardzo typowym przykïadem atrybutu z wieloma wartoĂciami jest numer telefonu. W czasie zapisywania informacji o kliencie najczÚĂciej zapisujemy przynajmniej jeden numer telefonu, ale klienci posiadajÈcy kilka telefonów z pewnoĂciÈ nie sÈ wyjÈtkami. Moĝemy zatem dodaÊ do encji Klient wiele pól opisujÈcych numer telefo- nu i odpowiednio je ponumerowaÊ (na przykïad Telefon1, Telefon2 itd.) albo nazwaÊ zgodnie z rodzajem telefonu (na przykïad Dom, Komorka, Biuro). Jest to caïkiem niezïe wyjĂcie, dopóki nie zechcemy zapisaÊ kilku firmowych numerów naszego klienta. Jest to typowy atrybut z wieloma wartoĂciami, czyli jeden atrybut moĝe przechowywaÊ wiele róĝnych wartoĂci. Z pewnoĂciÈ nie chcemy przechowywaÊ wielu rekordów opisujÈcych jednego klienta tylko po to, ĝeby zapisaÊ dodatkowy numer telefonu. Byïoby to caïkowicie sprzeczne z ideÈ relacyjnej bazy danych i wprowadzaïoby problemy z odczytywa- niem z niej danych. W zwiÈzku z tym moĝemy wprowadziÊ do modelu nowÈ encjÚ, która bÚdzie przechowywaïa numery telefonów i bÚdzie zwiÈzana relacjÈ z encjÈ klientów (bazujÈcÈ na kluczu gïównym tej tabeli). DziÚki temu zyskamy moĝliwoĂÊ zapisania dowolnej liczby numerów telefonów dla kaĝdego z klientów. Powstaïa encja moĝe przechowywaÊ wiele róĝnych wartoĂci dla kaĝdego klienta, czyli zawieraÊ tylko dwa atrybuty: unikatowy identyfikator klienta i numer telefonu. Zastosowanie takiej encji jest jedynÈ metodÈ na skuteczne rozwiÈzanie problemów z atrybutami o wielu wartoĂciach. Co wiÚcej, z takiej konstrukcji skorzysta równieĝ fizyczna implementacja, poniewaĝ bÚdzie mogïa wykorzystaÊ techniki wyszukiwania oferowane przez system zarzÈdzania bazÈ danych, które pozwalajÈ na przeszukiwanie encji zaleĝnej w oderwaniu od encji nadrzÚdnej. 46 ROZDZIA’ 2. ELEMENTY WYKORZYSTANE W LOGICZNYCH MODELACH DANYCH SpójnoĂÊ referencji JednÈ z najwaĝniejszych cech relacyjnej bazy danych jest to, ĝe dane w jednej encji mogÈ wskazywaÊ na dane w innej encji. Jeĝeli taka sytuacja ma miejsce, to niemal zawsze powstaje teĝ wymóg zarzÈdzania takÈ relacjÈ. Dane w obu encjach muszÈ byÊ przecieĝ caïkowicie spójne. Koncepcja ta nazywana jest spójnoĂciÈ referencji (ang. referential integrity), a w fizycznej implementacji danych jest najczÚĂciej re- alizowana za pomocÈ obiektów takich jak klucze i ograniczenia. Nie moĝna 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 przechowujÈcÈ informacje na temat inwentarza biblioteki. W modelu logicznym z pewnoĂciÈ znajdÈ siÚ encje Autor, Wydawca i Tytuï. Kaĝdy autor moĝe napisaÊ wiele ksiÈĝek, ale dana ksiÈĝka moĝe zostaÊ opublikowana tylko przez jednego wydawcÚ. Wydawca moĝe publikowaÊ wiele ksiÈĝek. Jeĝeli uĝytkownik bÚdzie chciaï usunÈÊ dane autora z bazy, to z pewnoĂciÈ zostanie w niej przynajmniej jedna osierocona ksiÈĝka. Po usuniÚciu danych wydawcy równieĝ co najmniej jedna ksiÈĝka w bazie zostanie osierocona. W zwiÈzku z tym musimy zdefiniowaÊ teĝ akcje, których wykonanie bÚdzie wymuszane za kaĝdym razem, gdy dane bÚdÈ aktualizowane w ten sposób. Takie definicje nazywane sÈ wïaĂnie spójnoĂciÈ referencji. MogÈ one na przykïad nakazaÊ usuniÚcie wszystkich ksiÈĝek zwiÈzanych z usuwanym wïaĂnie autorem. Moĝliwe jest teĝ zdefiniowanie reguïy zakazujÈcej dodania do bazy ksiÈĝki, jeĝeli nie istnieje w niej jeszcze zapis dotyczÈcy autora tej ksiÈĝki. Nie sÈ to moĝe najdoskonalsze przykïady, ale dobrze ilustrujÈ koniecznoĂÊ zarzÈdzania relacjami ïÈczÈcymi poszcze- gólne encje. W modelu logicznym spójnoĂÊ referencji jest dokumentowana za pomocÈ zwiÈz- ków tworzonych przez klucze gïówne i obce. Kaĝda encja powinna mieÊ atrybut kluczowy, jednoznacznie identyfikujÈcy wszystkie zapisane w niej rekordy. Moĝemy wykorzystaÊ te klucze do zdefiniowania relacji ïÈczÈcej encjÚ nadrzÚdnÈ z encjÈ zaleĝnÈ. ProszÚ spojrzeÊ na rysunek 2.1. Rysunek 2.1. Klucz gïówny i klucz obcy Przykïad przedstawia prostÈ relacjÚ miÚdzy dwoma encjami. Po utworzeniu relacji moĝemy w jej definicji podaÊ dowolne ograniczenia akcji zwiÈzanych z manipula- cjami na danych w encji nadrzÚdnej i zaleĝnej. Na przykïad moĝna zdefiniowaÊ, ĝe dowolna próba dopisania danych (INSERT) do encji zaleĝnej nie moĝe siÚ powieĂÊ, jeĝeli w encji nadrzÚdnej nie istnieje egzemplarz o pasujÈcym kluczu gïównym. RELACJE 47 Moĝna teĝ okreĂliÊ, ĝe dowolna operacja usuwania danych (DELETE) wykonana na encji nadrzÚdnej nie moĝe siÚ udaÊ, jeĝeli w encji zaleĝnej istniejÈ jeszcze egzem- plarze zwiÈzane z usuwanym wierszem w encji nadrzÚdnej. W tabeli 2.1. zostaïy opisane róĝne opcje, z jakich moĝemy skorzystaÊ podczas wykonywania akcji na encji nadrzÚdnej lub zaleĝnej. Tabela 2.1. Opcje spójnoĂci referencji dla relacji DostÚpne akcje Brak: wstawienie nowego egzemplarza nie ma wpïywu na encjÚ zaleĝnÈ Brak: nie ma ĝadnego wpïywu na encjÚ zaleĝnÈ i nie powoduje zablokowania zmian, w wyniku których powstajÈ nieĂcisïoĂci miÚdzy encjÈ nadrzÚdnÈ i zaleĝnÈ Ograniczenie: porównuje dane w kluczu gïównym encji nadrzÚdnej z danymi w kluczu obcym encji zaleĝnej. Jeĝeli wartoĂci te nie sÈ identyczne, to zmiany sÈ blokowane Kaskada: kopiuje wszystkie zmiany z klucza gïównego encji nadrzÚdnej do klucza obcego encji zaleĝnej Null: podobne do opcji Ograniczenie. Jeĝeli wartoĂci nie sÈ identyczne, to klucz obcy encji zaleĝnej otrzymuje wartoĂÊ NULL, a zmiany w encji nadrzÚdnej sÈ wykonywane Brak: nie ma ĝadnego wpïywu na encjÚ zaleĝnÈ i nie powoduje zablokowania zmian, w wyniku których powstajÈ w encji zaleĝnej wiersze osierocone Ograniczenie: porównuje dane w kluczu gïównym encji nadrzÚdnej z danymi w kluczu obcym encji zaleĝnej. Jeĝeli wartoĂci te nie sÈ identyczne, to zmiany sÈ blokowane Kaskada: usuwa wszystkie wiersze encji zaleĝnej, których klucze obce pasujÈ do klucza gïównego wiersza usuwanego w encji nadrzÚdnej Null: podobne do opcji Ograniczenie. Jeĝeli wartoĂci nie sÈ identyczne, to klucz obcy encji zaleĝnej otrzymuje wartoĂÊ NULL, a zmiany w encji nadrzÚdnej sÈ wykonywane. Ta opcja powoduje powstanie osieroconych wierszy w encji zaleĝnej Brak: brak ograniczeñ Ograniczenie: porównuje dane w kluczu gïównym encji nadrzÚdnej z kluczem obcym wartoĂci wstawianej do encji zaleĝnej. Jeĝeli wartoĂci te nie sÈ zgodne, to próba wstawienia danych jest blokowana Brak: brak ograniczeñ Ograniczenie: porównuje dane w kluczu gïównym encji nadrzÚdnej z kluczem obcym wartoĂci wstawianej do encji zaleĝnej. Jeĝeli wartoĂci te nie sÈ zgodne, to próba usuniÚcia danych jest blokowana Brak: brak ograniczeñ. Pozwala na usuniÚcie dowolnego wiersza z encji zaleĝnej Encja Encja nadrzÚdna Akcja INSERT UPDATE DELETE Encja zaleĝna INSERT UPDATE DELETE Relacje PojÚcie relacyjnej bazy danych implikuje wykorzystanie w bazie relacji. Jeĝeli nie wiemy, w jaki sposób dane sÈ z sobÈ powiÈzane, to zastosowanie do ich przechowy- wania relacyjnej bazy danych nie bÚdzie siÚ w niczym róĝniïo od przechowywania wszystkich dokumentów finansowych w jednym worku. Wypeïnianie rocznego 48 ROZDZIA’ 2. ELEMENTY WYKORZYSTANE W LOGICZNYCH MODELACH DANYCH zeznania podatkowego moĝe siÚ w takiej sytuacji okazaÊ prawdziwym koszmarem. Wszystkie niezbÚdne informacje mamy pod rÚkÈ, ale ile czasu zajmie nam wyszu- kanie ich w tym worku i ostateczne wypeïnienie dokumentów? ZaletÈ relacyjnych baz danych jest to, ĝe pozwalajÈ na wydajne przechowywanie i odczytywanie danych. Identyfikacja i implementacja wïaĂciwych relacji w modelu logicznym to dwa najwaĝniejsze kroki w procesie projektowania. ChcÈc prawidïo- wo zidentyfikowaÊ wszystkie relacje, musimy znaÊ wszystkie dostÚpne moĝliwoĂci, wiedzieÊ, jak je prawidïowo rozpoznawaÊ, i podjÈÊ decyzjÚ o tym, której relacji naleĝy uĝyÊ. Typy relacji Pod wzglÚdem logicznym istniejÈ trzy róĝne relacje ïÈczÈce encje: jeden-do-jednego, jeden-do-wielu i wiele-do-wielu. Kaĝda z nich opisuje sposób, w jaki dwie encje zïÈczÈ siÚ z sobÈ. Naleĝy pamiÚtaÊ o tym, ĝe te relacje sÈ tylko relacjami logicznymi. Ich fizyczna implementacja jest kolejnym krokiem, o którym bÚdziemy mówiÊ w rozdziale 9. Relacje jeden-do-jednego Relacja jeden-do-jednego ïÈczÈca dwie encje jest ich bezpoĂrednim poïÈczeniem, na co wskazuje jej nazwa. Kaĝdy rekord w jednej encji ma dokïadnie jeden pasujÈ- cy do niego rekord w drugiej encji. Nie mniej i nie wiÚcej. ProszÚ sobie wyobraziÊ dwoje ludzi rzucajÈcych piïkÈ. W tej sytuacji jest dokïadnie jeden rzucajÈcy i jeden ïapiÈcy. Moĝe byÊ tylko jeden rzucajÈcy i tylko jeden ïapiÈcy (ktoĂ, kto faktycznie zïapaï piïkÚ). Po co w takim razie wybieraÊ relacjÚ typu jeden-do-jednego? Skoro jeden rekord w jednej encji jest zwiÈzany z dokïadnie jednym rekordem w drugiej encji, to czy nie lepiej byïoby poïÈczyÊ te encje? ProszÚ spojrzeÊ na rysunek 2.2. Rysunek 2.2. Encja Szkoly Kaĝda szkoïa moĝe mieÊ tylko jednego dyrektora, a kaĝdy dyrektor moĝe zarzÈ- dzaÊ tylko jednÈ szkoïÈ. W tym przykïadzie wszystkie atrybuty encji dyrektora sÈ przechowywane w encji szkoïy. To rozwiÈzanie skupia wszystkie informacje w ramach jednej encji, ale jest bardzo maïo elastyczne. Przy kaĝdej zmianie danych szkoïy lub dyrektora konieczne jest odczytanie caïego rekordu, a nastÚpnie jego uaktualnienie. Oprócz tego szkoïa bez dyrektora lub dyrektor bez szkoïy bÚdÈ tworzyÊ rekord RELACJE 49 wypeïniony tylko w poïowie. Co gorsza, taka konstrukcja powoduje problemy przy odczytywaniu danych. Jeĝeli chcielibyĂmy napisaÊ raport zawierajÈcy informacje o dyrektorach, to bylibyĂmy zmuszeni do odczytywania równieĝ danych szkóï. A co bÚdzie, jeĝeli chcielibyĂmy gromadziÊ informacje o pracownikach dyrektorów? W takim przypadku musielibyĂmy powiÈzaÊ pracowników z poïÈczonÈ 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 przykïadzie mamy juĝ dwie encje: Szkoly i Dyrektorzy. Kaĝda z nich ma atrybuty opisujÈce 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 opiekujÈcego siÚ danÈ szkoïÈ. Takie rozwiÈzanie jest duĝo bardziej elastyczne, poniewaĝ listy szkóï i dyrektorów sÈ zarzÈdzane caïkowicie niezaleĝnie. ProszÚ jednak zauwaĝyÊ, ĝe encje te ïÈczy relacja jeden-do-jednego, która pozwala na naïoĝenie ograniczeñ umoĝliwiajÈcych utrzymanie spójnoĂci danych. Relacje jeden-do-wielu W najczÚĂciej wystÚpujÈcych relacjach typu jeden-do-wielu jeden rekord w pierw- szej encji moĝe mieÊ zero lub wiÚcej pasujÈcych rekordów w drugiej encji. IstniejÈ setki przykïadów takich relacji, stosowanych najczÚĂciej w ramach ïÈczenia danych nagïówkowych z informacjami szczegóïowymi. Na przykïad zamówienia sÈ czÚsto przechowywane jako lista rekordów nagïówkowych w jednej encji, druga encja gromadzi natomiast szczegóïowe informacje na temat poszczególnych zamówieñ. Takie rozwiÈzanie pozwala na umieszczenie w kaĝdym zamówieniu wielu pozycji bez koniecznoĂci tworzenia wielu rekordów zawierajÈcych 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 przykïadu ze szkoïami i dyrektorami. Co siÚ stanie, jeĝeli pojawi siÚ zarzÈdzenie pozwalajÈce pracowaÊ kilku dyrektorom w jednej szkole? Taka sytuacja natychmiast tworzy relacjÚ jeden-do-wielu ïÈczÈcÈ 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 ïÈczÈca te dwie encje stwarza moĝliwoĂÊ powiÈzania kilku dyrektorów z jednÈ szkoïÈ. Jest ona skalowalna, poniewaĝ obie encje mogÈ byÊ aktualizowane i zarzÈdzane caïkowicie niezaleĝnie od siebie. Relacje wiele-do-wielu SpoĂród wszystkich rodzajów relacji relacje wiele-do-wielu (nazywane równieĝ relacjami nieokreĂlonymi) naleĝÈ do najbardziej skomplikowanych do zidentyfiko- wania i zaprojektowania. W relacjach wiele-do-wielu rekordy z jednej encji mogÈ ïÈczyÊ siÚ z wieloma rekordami w drugiej encji, a jednoczeĂnie rekordy z drugiej encji mogÈ wiÈzaÊ siÚ z wieloma rekordami z pierwszej encji. ProszÚ sobie wyobraziÊ czÚĂci samochodowe, a w szczególnoĂci siedzenia montowane w kaĝdym aucie. W dowolnym samochodzie znajdziemy przynajmniej dwa rodzaje siedzeñ: fotele dla kierowcy i pasaĝera oraz duĝÈ kanapÚ dla pasaĝerów siedzÈcych z tyïu. Producenci samochodów niemal zawsze wykorzystujÈ istniejÈce siedzenia w kilku modelach samochodów. JeĂli przeïoĝymy te rozwaĝania na encje, to okaĝe siÚ, ĝe Siedzenie moĝe znaleěÊ siÚ w wielu Samochodach, a kaĝdy Samochód moĝe zawieraÊ wiele Siedzeñ. WróÊmy jednak do naszego przykïadu ze szkoïami. Co bÚdzie, jeĝeli zostanie podjÚta decyzja, ĝe jeden dyrektor moĝe zarzÈdzaÊ kilkoma szkoïami, a jedna szkoïa moĝe znajdowaÊ siÚ pod opiekÈ kilku dyrektorów? Na rysunku 2.5. przedstawiliĂmy encje Szkoly i Dyrektorzy zwiÈzane relacjami pozwalajÈcymi na tworzenie wielu poïÈczeñ miÚdzy obiema encjami. RELACJE 51 Rysunek 2.5. Encje Szkoly i Dyrektorzy — relacja wiele-do-wielu RozpatrujÈc tÚ sprawÚ czysto teoretycznie, trzeba powiedzieÊ, ĝe wszystkie relacje mogÈ istnieÊ tylko miÚdzy dwoma encjami. Pod wzglÚdem logicznym mamy wiÚc relacjÚ miÚdzy encjami Szkoly i Dyrektorzy. Pod wzglÚdem technicznym moĝemy zastosowaÊ notacjÚ z dwoma relacjami typu jeden-do-wielu ïÈczÈcymi te encje, ale skierowanymi przeciwnie. Innym rozwiÈzaniem jest zastosowanie relacji z symbolem „wiele” umieszczonym po obu jej koñcach. Z praktycznego punktu widzenia najwy- godniej jednak bÚdzie utworzyÊ trzeciÈ encjÚ obrazujÈcÈ takÈ relacjÚ, podobnie jak zostaïo 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 pogwaïcenie ideaïu modelu logicznego, który nie powinien zawieraÊ ĝadnych elementów fizycznej implementacji. Zastosowanie trzeciej encji ïÈczÈcej encje Szkoly i Dyrektorzy za pomocÈ ich identyfikatorów jest odwzo- rowaniem fizycznej implementacji stosowanej wobec wielu relacji typu wiele-do- wielu. Fizycznie nie jest moĝliwe 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 ĂciĂle zgodne ze wskazówka- mi modelowania logicznego. Umieszczenie dodatkowej encji w modelu logicznym moĝe jednak uïatwiaÊ zapamiÚtanie, dlaczego zostaïa uĝyta taka relacja. BÚdzie teĝ pomocÈ dla przyszïych wspóïpracowników poznajÈcych dopiero wszystkie relacje w tym modelu. Zastosowanie trzeciej encji pozwala ponadto na wprowadzenie dodatkowych atrybutów opisujÈcych kaĝdy egzemplarz takiej relacji. Na przykïad w encji Dyrekto- rzy_Szkoly moĝna dodaÊ informacjÚ, od kiedy dany dyrektor zajmuje siÚ okreĂlonÈ szkoïÈ. Jeĝeli istnieje wiele takich kombinacji, to informacja o czasie zajmowania stanowiska przez danÈ osobÚ w danej szkole moĝe byÊ bardzo przydatna. Relacje typu wiele-do-wielu sÈ stosowane zadziwiajÈco czÚsto, ale zawsze naleĝy podchodziÊ do nich bardzo ostroĝnie i dokïadnie je dokumentowaÊ, tak ĝeby nie byïo ĝadnych nieporozumieñ w trakcie tworzenia fizycznej implementacji modelu. Opcje relacji Skoro znasz juĝ róĝne rodzaje relacji, musimy omówiÊ jeszcze opcje, które moĝemy definiowaÊ w relacjach poszczególnych typów. Opcje te pozwalajÈ na dokïadniejsze sterowanie zachowaniem kaĝdej relacji z osobna. Relacje identyfikujÈce i nieidentyfikujÈce Jeĝeli klucz gïówny encji zaleĝnej wymaga doïÈczenia klucza gïównego encji nad- rzÚdnej, to znaczy, ĝe relacja ïÈczÈca te encje jest relacjÈ identyfikujÈcÈ (ang. identi- fying relation). Wynika to z tego, ĝe unikatowy atrybut encji zaleĝnej wymaga zastoso- wania wyjÈtkowego atrybutu encji nadrzÚdnej, aby jednoznacznie zidentyfikowaÊ odpowiedni egzemplarz encji. Jeĝeli takie wymaganie nie istnieje, to relacja jest definiowana jako nieidentyfikujÈca (ang. non-identifying relation). W przypadku relacji identyfikujÈcej klucz gïówny encji nadrzÚdnej jest faktycznie jednym z atrybutów skïadajÈcych siÚ na klucz gïówny encji zaleĝnej. Oznacza to, ĝe klucz obcy encji zaleĝnej jest czÚĂciÈ lub nawet caïoĂciÈ jej klucza gïównego. W przypadku relacji nieidentyfikujÈcej klucz gïówny encji nadrzÚdnej jest tylko niekluczowym atrybutem encji zaleĝnej. Zaledwie niewielka czÚĂÊ relacji to relacje identyfikujÈce, poniewaĝ wiÚkszoĂÊ encji zaleĝnych moĝe byÊ referowanych caïkowicie niezaleĝnie od e
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Modelowanie danych w SQL Server 2005 i 2008. Przewodnik
Autor: ,
Sklep
Format
Cena
Helion.pl Helion.pl
książka
39,00 zł
Idź do sklepu »

Opinie na temat publikacji:

Inne popularne pozycje z tej kategorii:

Czytaj również:

Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: