Spis treści 2. Przypomnienie najważniejszych pojęć z baz danych....1 3. Model relacyjny baz danych....8 4. Model związków encji.... 13 5.Projektowanie bazy danych za pomocą narzędzi CASE.... 15 6. Zasady projektowania baz danych. Normalizacja.... 21 2. Przypomnienie najważniejszych pojęć z baz danych. Baza danych jest zbiorem danych z określonej dziedziny tematycznej zorganizowany w sposób ułatwiający do nich dostęp oraz narzędzi systemu DBMS (System zarządzania bazą danych, SZBD (ang. Database Management System, DBMS) przeznaczonego do zarządzania bazą danych oraz gromadzenia, przekształcania i wyszukiwania danych. Baza danych to zbiór danych, który dotyczy rzeczywistości a konkretnie określonego jej fragmentu, który reprezentuje. Fragment ten określamy mianem obszaru analizy. Zalety korzystania z komputerowych baz danych to: szybkie wyszukiwanie informacji łatwe wykonywanie obliczeń możliwość przechowywania dużej ilości danych na małej powierzchni szybkie porządkowanie danych. Baza danych ma takie cechy charakterystyczne, jak: Trwałość danych oznacza możliwość przechowywania danych w pamięci masowej (trwałej) komputera. Dane tymczasowe mogą być przechowywane w pamięci komputera i tracone po jego wyłączeniu. Niezależność danych pozwala osiągnąć większą elastyczność, ponieważ programy wymieniające informacje z bazą danych są niezależne od przechowywania danych na dysku i szczegółów reprezentacji danych na dysku. Niezależność dotyczy również posługiwania się danymi. Użytkownicy są zabezpieczeni przed logicznymi zmianami (program obsługujący bazę danych jest zabezpieczony przed modyfikacją struktury tabel bazy danych). DBMS gwarantujący niezależność fizyczną przejmuje na siebie zadanie określenia, w jakim formacie i jak dane będą przechowywane na dysku. Ochrona danych baza danych oferuje mechanizmy kontroli dostępu do danych w sposób umożliwiający użytkowanie danych wyłącznie przez uprawnionych do tego użytkowników. Integralność danych zgodność z rzeczywistością. Dane w bazie danych są odwzorowaniem rzeczywistości. Jeśli modelowany fragment rzeczywistości ulegnie zmianie, baza danych również musi się zmienić. Część intensjonalna inaczej schemat bazy danych to zbiór definicji powstających w trakcie projektowania bazy danych określający strukturę danych. Schemat tworzy encje (klasy) oraz właściwości klas atrybuty. Część ekstensjonalna - to łączny zbiór danych w bazie danych. 1
SZBD Systemy Zarządzania Bazą Danych System zarządzania bazą danych SZBD (DBMS Database Management System) to program zarządzający danymi w bazie i ułatwiający ich przetwarzanie. SZBD obsługuje użytkowników bazy danych, umożliwiając im eksploatację oraz tworzenie baz danych. System bazy danych to baza danych i system zarządzania bazą danych. By stworzyć i zaprojektować bazę danych, należy ją zdefiniować, a do tego konieczne jest określenie (zdefiniowanie) typów przechowywanych w niej danych. Istotną rolę odgrywa również wyznaczenie użytkowników oraz ich praw dostępu. SZBD pełni funkcje, które określane są mianem właściwości baz danych. Zaliczamy do nich: tworzenie struktur baz danych, wykonywanie operacji CRUD (Create, Read, Update, Delete), obsługa zapytań (selekcjonowanie danych), generowanie raportów i zestawień, administracja bazą danych. Tworzenie struktur baz danych Aby utworzyć strukturę bazy danych, należy posłużyć się wcześniej sporządzonym projektem. Struktura to szkielet bazy danych, przeniesienie koncepcji tabel, powiązań na obszar systemu zarządzania bazą danych. Strukturę bazy danych możemy utworzyć po podłączeniu do serwera bazy danych. Na taką strukturę składają się: tabele, widoki, powiązania pomiędzy tabelami, domeny, funkcje. Wykonywanie operacji CRUD ( operacje zapisu, odczytu, aktualizacji i usuwania). Może zajść potrzeba modyfikowania tabel, widoków oraz aktualizacji danych przechowywanych w tabelach. Baza danych powinna być tak zaprojektowana, by wykonywanie aktualizacji na danych, usuwanie danych czy wprowadzanie nowych informacji nie spowodowało utraty spójności. Spójność bazy danych to poprawność umieszczonych w niej informacji. Baza danych powinna mieć mechanizmy umożliwiające uzyskanie szybkiego dostępu do danych i selekcjonowanie. W relacyjnych bazach danych do uzyskiwania dostępu do danych służą zapytania. Zapytania to instrukcje napisane przeważnie w języku SQL. Oprócz uzyskiwania dostępu do informacji i danych, ich sortowania, selekcjonowania i przeszukiwania baza danych powinna oferować mechanizmy umożliwiające drukowanie wykazów czy zapisywanie ich poza bazą danych. Funkcje takie stanowią raporty i zestawienia, które mogą być generowane z baz danych. Baza danych powinna umożliwić administrację swoimi zasobami. Administracja może mieć charakter nie tylko projektowania i implementowania, lecz także optymalizacji i dostosowywania do potrzeb użytkowników. Wady SZBD: 1. konieczność zapoznania się z bardzo obszerną dokumentacją (oferują bardzo wiele nowoczesnych funkcji, wzrasta ich złożoność) 2. wymagają zapewnienia dużych przestrzeni dyskowych i zasobów pamięci operacyjnej 3. wysokie koszty (opłaty za szkolenia pracowników, koszty przeniesienia systemu, koszty generowane przez audyt i bezpieczeństwo) 2
4. utrzymywanie scentralizowanego DBMS w przypadku awarii systemu uniemożliwia pracę wszystkich powiązanych z nim aplikacji Charakterystyka elementów baz danych. Zagadnienia: encja, atrybut, krotka, dziedzina, klucz (główny, kandydujący, obcy, prosty, złożony). Znajomość budowy bazy danych wymaga zwykle fachowego określenia jej elementów. Twórca relacyjnego modelu danych E.F. Codd w pracy Relacyjny model danych dla dużych banków nie używa terminów tabela, kolumna, wiersz, lecz zamiast nich stosuje pojęcia: relacja (zamiast tabela), atrybu (zamiast kolumna), krotka (zamiast wiersz). ENCJA jest rzeczą lub obiektem mającym dla nas znaczenie, rzeczywistym bądź wyobrażonym, o którym informacje muszą być znane lub przechowywane. Graficzną reprezentacją ENCJI jest prostokąt z nazwą ENCJI zapisaną w liczbie pojedynczej ATRYBUT jest dowolnym szczegółem służącym do kwalifikowania, identyfikowania, klasyfikowania, określania ilości lub wyrażania stanu ENCJI. Lub ATRYBUT jest dowolnym opisem mającym znaczenie dla ENCJI. ATRYBUT może być tekstem, liczbą, wartością logiczną lub obrazem. Przykład atrybutów ENCJI klient. 3
Dziedzina jest zbiorem wartości, jakie może przyjąć atrybut krotki. Jeśli kolumna tabeli przechowywać będzie numery kuli używanych do losowania Lotto, dziedzina atrybutu będą numery od 1 do 49. Klucz prosty to taki, który jest jednoelementowy (składa się z jednej kolumny) Klucz złożony to taki, który jest kilkuelementowy (składa się z więcej niż jednej kolumny) Do łączenia dwóch tabel (np. A i B) za pomocą związków używa się klucza. Klucz pochodzący z obcej tabeli B (w której jest on kluczem głównym), używany do łączenia tej tabeli z tabelą A, będzie dla tabeli A kluczem obcym. Klucz główny (primary key) to klucz, który został wybrany, aby unikatowo identyfikować krotki tabeli. Właściwości klucza głównego: trwałość-not null, unikatowość -id, stabilność-atrybut niezmienny w czasie. Cechy klucza głównego: 1. Id 2. NOT NULL 3. Krótki 4. Jest takim atrybutem, który jest niezmienny w czasie. Projektowanie relacyjnej bazy danych wymaga stosowania fachowych określeń, których używać powinno się nie tylko w odniesieniu do budowy tabel, lecz także w stosunku do relacji związków tworzonych pomiędzy tabelami. Związki pomiędzy tabelami bazy danych. Stosowanie relacji jako nazwy połączenia miedzy tabelami jest tylko grą słów, którą można znaleźć w wielu podręcznikach ( fachowo powinno się używać związku). Związki pomiędzy tabelami Rozróżnia się trzy typy związków, jakie mogą zachodzić pomiędzy dwoma encjami: 4
1. Związek jeden-do-jeden oznacza, iż jeden rekord w pierwszej tabeli odpowiada dokładnie jednemu rekordowi w tabeli drugiej. W praktyce relację jeden-do-jeden stosuje się w przypadku tzw. tabel słownikowych (rysunek 4). Rysunek 4. Związek jeden-do-jeden. Związek ta ułatwia późniejszą modyfikację np. nazwy oceny tylko w jednym miejscu, zamiast przeglądania i zamieniania całości rekordów w encji Oceny_z_egzaminu. W klasycznej notacji ERD relację tę zapisuje się za pomocą symbolu przedstawionego na rysunku 5. Rysunek 5. Symbol związku jeden-do-jeden. A B Tabela A- tabela mocna (atrybuty często wykorzystywane) Tabela B- tabela słaba (jest całkowicie zależna od innej tabeli atrybuty rzadko wykorzystywane) Odwoływanie się do całej tabeli trwa dłużej. Jeśli rzadko korzystamy ze wszystkich atrybutów to dzielimy je na mniejsze. Tworzenie tabel słownikowych: Kiedy wartości pewnego atrybutu należą do pewnego skończonego zbioru, wartości tych nie należy wpisywać ręcznie, ale wybierać z listy wartości zapisanych w tabeli zwanej tabelą słownikową Tabele słownikowe eliminują możliwość popełnienia błędu i usprawniają działanie aplikacji 2. Związek jeden-do-wielu oznacza, iż jeden rekord w pierwszej tabeli odpowiada wielu rekordom w tabeli drugiej i jest to relacja najczęściej stosowana. Jako przykład można użyć strukturę Wydziału składającą się z wielu kierunków (rysunek 6). przedstawionego na rysunku 7. Rysunek 6. Związek jeden-dowielu. Na diagramach ERD związek jeden-do-wielu prezentowana jest za pomocą symbolu Rysunek 7. Symbol związku jeden-do-wielu. 5
3. Związek wiele-do-wielu oznacza, że kilka rekordów z pierwszej tabeli odpowiada wielu rekordom z tabeli drugiej. W praktyce stosowanie tejże relacji jest wielce niewskazane ze względu na redundancję danych, zatem rozwiązaniem tego problemu będzie utworzenie tzw. tabeli łącznikowej, scalającej obie tabele relacją jeden-do-wielu. Przykładowy związek wiele-do-wielu został zaprezentowany na rysunku 8, natomiast prawidłowa prezentacja za pomocą tabeli łącznikowej na rysunku 9. Rysunek 8. Związek wiele-do-wielu. Rysunek 9. Związek wiele-do-wielu zrealizowana za pomocą tabeli łącznikowej. Związek wiele-do-wielu prezentowany jest za pomocą symbolu przedstawionego na rysunku 10. Rysunek 10. Symbol związku wiele-do-wielu. Do opisu powyższych relacji można dodatkowo wprowadzić parametry charakteryzujące opcjonalne bądź obligatoryjne wykorzystanie danego atrybutu. Opcjonalność zapisuje się, dodając puste koło obok symbolu relacji (rysunek 11). Rysunek 11. Symbol związku jeden do wielu z związkiem opcjonalności rekordów. 1 1 https://msdn.microsoft.com/pl-pl/library/projektowanie-baz-danych--diagramy-erd-relacje-miedzy-tabelami-zwiazkirekordy.aspx 6
Indeksowanie (ang. indexing) proces tworzenia i utrzymywania indeksu umożliwiającego skrócenie czasu dostępu do danych. Indeksowanie oznacza przyśpieszenie wyszukiwania na poziomie fizycznym, na nasze żądanie po atrybucie. Szybkie wyszukiwanie po wielu atrybutach spowoduje spowolnienie aktualizacji, modyfikowania i usuwania danych. Zadanie: a) na podstawie poniższych relacji wymień, wszystkie klucze główne, klucze obce, klucze proste i złożone. b) na podstawie poniższych relacji wymień encje i atrybuty encji c) podaj dla jednej wybranej encji wymyślony przez Ciebie przykład krotki (rekordu). Sprawdź swoją wiedzę. 1. Co to jest encja? 2. Wyjaśnij termin atrybuty encji. 3. Wyjaśnij na przykładzie co to jest krotka. 4. Jakie cechy powinien posiadać klucz główny? 5. Co to jest klucz obcy? Tabele baz danych iloczyn kartezjański Relacja tabela Zbiór A przechowujący cyfry Zbiór B przechowujący imiona Iloczynem kartezjańskim tych dwóch zbiorów będzie następujący zbiór C, w którym każdemu elementowi zbioru A, będzie odpowiadał element zbioru B: 7
Teraz spróbujemy zdefiniować relację. Relacją nazywamy podzbiory iloczynu kartezjańskiego. Niech podzbiorem dla naszego przykładu będą (1-Jacek, 2 Ewa). Jeśli umieścimy te elementy w tabeli, otrzymamy: Numery Imiona 1 Jacek 2 Ewa 1 Ewa 3 Ewa 2 Jacek 3 Jacek Dlatego w relacyjnych bazach danych relacją nazywać będziemy tabele bazy danych, ponieważ zawartość tabeli ulega ciągłym zmianom. Kolumny atrybuty mogą przechowywać wartości określonych typów, jednak wartości te mogą być modyfikowane. Istnieją podręczniki, gdzie używane są synonimy pojęcia relacja i tabela, a stosunki pomiędzy tabelami nazywane będą związkami, np. związkiem jeden do wielu, związkiem jeden do jednego. 3. Model relacyjny baz danych. MODELE BAZ DANYCH Bazy danych mogą różnić się sposobem, w jaki dane są zorganizowane i powiązane ze sobą. Przez model danych rozumiemy zbiór pojęć stosowanych do opisu struktury bazy danych. Model danych (ang. Data base model) to zestaw pojęć do opisu świata rzeczywistego. Jest to swojego rodzaju maetajęzyk, w którym analityk systemu formuje soją wizję systemu informatycznego). Struktura BD obejmuje: typy danych, związki miedzy nimi i ograniczenia nałożone na dane zbiór operacji do definiowania, wyszukiwania i uaktualniania BD 8
Rysunek 1. Modele danych Wśród modeli danych można wyróżnić następujące kategorie: Koncepcyjne modele danych. Są to modele najbardziej zbliżone poziomem abstrakcji do wymagań projektantów BD, stosowane w pierwszych etapach projektów, w celu weryfikacji wyróżnionych w nim obiektów i związków miedzy nimi Implementacyjne modele danych, stosowane do transformacji wcześniej przygotowanego modelu koncepcyjnego do konkretnego modelu BD, a więc do postaci, która jest z godna z wymaganiami określonego SZBD. Wśród modeli implementacyjnych wyróżniamy modele: o o o o hierarchiczny sieciowy relacyjny obiektowy Fizyczne modele danych, określające sposoby organizacji danych w pamięci zewnętrznej komputerów. Operuje się tu pojęciami takimi jak np. rekord, plik, adres. Z modeli implementacyjnych modele hierarchiczne i sieciowe są już prawie nie stosowane w praktyce. Model relacyjny dominuje w komercyjnych bazach danych. 9
Model hierarchiczny: Hierarchiczny model danych (do końca lat 70.) opierał się na strukturze drzewa (jeden wyróżniony wierzchołek), np. Baza danych pośredników Używany był, gdy bazy danych były tworzone w językach wysokiego poziomu jak C, C++, itd., kiedy nie było języków baz danych. Aby uzyskać dostęp do danych użytkownik zaczyna od korzenia i przedziera się przez całe drzewo danych, aż do interesującego miejsca. Oznacza to zarazem, że użytkownik musi dobrze znać strukturę b.d. Struktura ta jest podobna do znanych wszystkim stron WWW. Nie można dopisać żadnego z muzyków dopóki nie powiążemy go z którymś z pośredników Nie istnieje tu relacja wiele-do-wielu ponieważ jeden muzyk gra dla wielu klientów, a jeden klient może zamówić wielu muzyków. Dane o klientach muszą być zawarte w tabeli terminarz (obok danych o muzykach), a w tabeli klienci będą dane o muzykach (naturalnie obok danych o klientach). Mamy więc do czynienia z Nadmiarowością danych!!! Sieciowy model: Pewna modyfikacja modelu hierarchicznego - dane można przedstawić w postaci grafu. Ten model wyszedł z obiegu. Opierał się na systemie plików. 10
Sieciowy model bazy danych (SMBD) został stworzony głównie w celu rozwiązania problemów związanych z modelem hierarchicznym. Podobnie, jak w modelu hierarchicznym SMBD można sobie wyobrazić jako odwrócone drzewo. Różnica polega jednak na tym, że w przypadku SMBD, wiele drzew może dzielić ze sobą gałęzie, a każde z nich stanowi cześć ogólnej struktury bazy danych. Diagram modelu sieciowego. 3. Relacyjny model: W latach 60. dr E F Codd pracując w IBM stworzył relacyjny model b.d. opierając się dwóch gałęziach matematyki - teorii mnogości i rachunku predykatów I-rzędu!? W relacyjnych b.d. dane przechowujemy w tabelach. Każda z tabel składa się z rekordów oraz pól. Fizyczna kolejność pól i rekordów jest tutaj bez znaczenia. Każdy rekord jest wyróżniony przez unikatową wartość - klucz. W konsekwencji użytkownik nie musi znać fizycznego położenia rekordu, który chce odczytać. Odróżnia to model relacyjny od hierarchicznego czy sieciowego, gdzie b. duży nacisk kładziono na struktury, które użytkownik musiał opanować, aby mógł odczytać interesujące dane. Czym jest relacyjny model danych Baza danych w terminologii matematycznej jest zbiorem relacji, relacja reprezentowana jest jako dwuwymiarowa tabela złożona z atrybutów (kolumn) oraz krotek (wierszy). Każda relacja ma stałą liczbę atrybutów oraz dowolną liczbę wierszy. Połączenia między relacjami nazywamy związkami (często mylnie związki między tabelami nazywane są relacjami). Relacje zgrupowane są w schematy bazy danych. 11
Rysunek 2. Relacyjny model baz danych Model jednorodny. Baza kartotekowa Nazywana również bazą 2-wymiarową. Bazy takie składają się tylko z jednej tabeli, w której zgromadzone są wszystkie dane. Każdy rekord takiej bazy można przedstawić w postaci pojedynczej karty. Przykład: zestaw kart katalogowych książek w bibliotece lub kart pacjentów. Kartotekowa baza danych oparta jest o 1 plik danych. Baza obiektowa- Bazy opierające się na modelu obiektowym łączą cechy programów komputerowych tworzonych za pomocą nowoczesnych języków programowania obiektowego z cechami aplikacji bazodanowych. Aplikacje bazodanowe bazują na obiektach (zbiorach połączonych danych i procedur umożliwiających manipulowanie tymi danymi) i tzw. klasach obiektów. 12
4. Model związków encji. Diagramy związków encji lub inaczej diagram ERD (Entity-Relationship Diagam) jest używany do graficznego przedstawienia związków pomiędzy encjami podczas projektowania relacyjnych baz danych. Za pomocą diagramu ERD obrazujemy graficznie związki pomiędzy encjami posiadające następujące cechy: Krotność(Liczebność) określająca ile encji wchodzi w skład związku. Możliwe są następujące typy: Opcjonalność, która definiuje czy każda encja musi czy tylko może być powiązana z inną (np.: każdy pacjent przyjęty do szpitala musi mieć przyporządkowany numer PESEL, a z kolei w bibliotece mogą znajdować się książki, które nie były jeszcze przez nikogo wypożyczone. Do wizualizacji związków stosowane jest kilka notacji: 13
Diagramy ERD składają się z trzech rodzajów elementów: Zbiorów encji Atrybutów encji Związków zachodzących między encjami. Narzędzia CASE (ang. Computer Aided Software Engineering) są wykorzystywane podczas projektowania różnego rodzaju oprogramowania, najczęściej wspomagają proces jego wytwarzania. Narzędzie te pozwalają tworzyć modele graficzne odpowiadające konstrukcjom programistycznym. Przykładem narzędzia typu CASE jest program DBDesigner4. Przykład ERD: 14
5.Projektowanie bazy danych za pomocą narzędzi CASE. Istnieje oprogramowanie specjalistyczne, narzędzie CASE (ang. Computer Aided System Engineering), które ułatwia graficzne projektowanie i rysowanie diagramów związków encji na ekranie komputera. Niektóre z tych narzędzi umożliwiają też automatyczne generowanie schematu bazy danych w konkretnych systemach bazodanowych na podstawie opracowanych w nich diagramów. Przykładem takiego narzędzia jest komercyjny program MS Visio, który korzystając z diagramów w nim utworzonych, automatycznie generuje tabele bazy danych w MS Access. Innym narzędziem z rodziny CASE jest program DBDesigner dostępny na otwartej licencji GNU GPL. Za pomocą prostych narzędzi tworzymy w nim diagramy związków encji, a wynikiem jest model projektowy zapisany w formacie XML. 15
Celem zapoznania się z programem DBDesigner wykonamy w nim serię ćwiczeń, które umożliwią wizualne zaprojektowanie bazy danych. Na początek utworzymy nowy projekt. 16
Zadanie 2. 17
18
19
Rozwiązanie: 20
Zadanie Proszę przygotować projekt struktury bazy danych w postaci diagramu ERD dla następujących założeń: 1. Baza zawiera 3 tabele a. Tabela Ksiazki i. Pole Ksiazka_id autonumerowany klucz główny tabeli ii. Pole Autor_id klucz obcy tabeli Autorzy (tworzony automatycznie podczas definiowania relacji) iii. Pole Tytuł typu varchar iv. Pole ISBN b. Tabela Autorzy i. Pole Autor_id autonumerowany klucz główny tabeli ii. Imie varchar iii. Nazwisko varchar c. Tabela Czytelnicy i. Pole czytelnik_id autonumerowany klucz główny tabeli ii. Imie varchar iii. Nazwisko varchar iv. Aktywny boolean 2. Relacje między tabelami a. Relacja 1:N między tabelami Ksiazki i Autorzy ustalamy możliwość zdefiniowania tylko 1 autora dla każdej książki. b. Relacja N:M między tabelami Ksiazki oraz Czytelnicy tabela zostanie stworzona automatycznie podczas definiowania relacji. c. Dodatkowo w tabeli pośredniczącej dla relacji N:M dodefiniowujemy następujęce pola: i. Pole data_wypozyczenia pole typu timestamp ii. Pole data-zwrotu pole typu timestamp 6. Zasady projektowania baz danych. Normalizacja. Projektowanie baz danych. Zasady projektowania Cały proces projektowania bazy danych możemy podzielić na kilka etapów: 21
1. Planowanie bazy danych. 2. Tworzenie modelu konceptualnego (diagramu ERD). 3. Transformacja modelu konceptualnego na model relacyjny. 4. Proces normalizacji bazy danych. 5. Wybór struktur i określenie zasad dostępu do bazy danych. Projektowanie modelu bazy danych powinno składać się z następujących działań: 1. Określenie występujących zbiorów encji. 2. Określenie atrybutów przypisanych do poszczególnych encji. 3. Określenie dziedziny poszczególnych atrybutów. 4. Ustalenie kluczy podstawowych. 5. Określenie typów występujących związków. 6. Zweryfikowanie utworzonego modelu. Przekształcenie diagramu w schemat relacyjnej bazy danych: Dla każdej encji tworzona jest tabela Identyfikatory encji stają się kluczami głównymi tabel Atrybuty stają się atrybutami relacji (nagłówkami kolumn tabeli) Związki jeden do wiele realizowane są za pomocą klucza obcego w tabeli po stronie wiele Związek jeden do jeden można zrealizować za pomocą klucza obcego plus ograniczenie UNIQUE po stronie wiele Opcjonalność po stronie wiele można kontrolować dodając lub nie ograniczenie NOT NULL Związek rekurencyjny jeden do wiele przekształca się do tabeli z kluczem obcym odwołującym się do klucza głównego tej samej tabeli Projektowanie konceptualne, logiczne i fizyczne. Konceptualne projektowanie bazy danych to konstruowanie schematu danych niezależnego od wybranego modelu danych, docelowego systemu zarządzania bazą danych, programów użytkowych czy języka programowania. Do tworzenia modelu graficznego schematu bazy danych wykorzystywane są diagramy związków encji, z których najpopularniejsze są diagramy ERD (ang. Entity Relationship Diagram). Pozwalają one na modelowanie struktur danych oraz związków zachodzących między tymi strukturami. Nadają się szczególnie do modelowania relacyjnych baz danych, ponieważ umożliwiają prawie bezpośrednie przekształcenie diagramu w schemat relacyjny. Projektowanie logiczne to proces konstrukcji modelu danych oparty na specyficznym modelu, ale niezależnym od DBMS. Model fizyczny to proces produkcji i opisu implementacji bazy danych opisujący relacje bazy danych, organizację plików, indeksy, dostęp do danych, ograniczenia, wyznaczenie reguł integralności i stosowanie środków bezpieczeństwa. Normalizacja bazy danych Tabele w bazie danych powinny być logicznie uporządkowane i funkcjonalne. W każdym polu i rekordzie powinna być jak najmniejsza porcja informacji tak, aby dane nie były powielane i można było je łatwo znaleźć. Normalizacja to proces sprowadzania bazy danych do odpowiedniej postaci. Polega on przede wszystkim na dzieleniu tabeli na kilka połączonych kluczem tabel. Głównym powodem, dla którego normalizuje się bazę danych jest uniknięcie anomalii, które mogą wystąpić przy nieprawidłowo skonstruowanej strukturze bazy. Możliwe anomalie są przedstawione w tabeli poniżej. 22
Załóżmy, że mamy następującą strukturę bazy książek w bibliotece: Tytuł książki Autor Wypożyczający Adres wypożyczającego Data wypożyczenia W tej bazie wystąpią następujące anomalie: Anomalia Opis przy aktualizacji Jeżeli wypożyczający zmienił adres, trzeba przeszukać całą bazę i we wszystkich komórkach, w których występuje, zmienić ten adres przy usuwaniu Jeżeli wypożyczający zwróci ostatnią książkę, zostanie utracona informacja na jego temat (adres i inne dane osobowe) przy wstawianiu Nowa osoba nie może zapisać się do biblioteki, jeżeli nie wypożyczy książki (a nie musi od razu wypożyczać) Redundacja, czyli powtarzanie tej samej informacji w kilku miejscach redundacja w bazie, powoduje niepotrzebne zajmowanie pamięci (wypożyczenie dwóch książek powoduje, że niepotrzebnie adres jest powtarzany dwa razy) Aby osiągnąć właściwe uporządkowanie danych i zminimalizować ich powtarzalność należy każdą tabelę poddać co najmniej trzem etapom normalizacji (w sumie jest ich sześć). Każda z następnych postaci normalnych jest bardziej wymagająca od poprzedniej i jest zgodna z poprzednimi postaciami normalizacji. Anomalie powstają gdy próbujemy w jednej tabeli (w żargonie matematycznym - relacji) umieścić zbyt wiele danych. Rozwiązaniem tych problemów są postacie normalne, które gwarantują, że takie anomalie nie będą miały miejsca. Normalizowanie baz danych. Normalizacja bazy danych jest to proces mający na celu eliminację powtarzających się danych w relacyjnej bazie danych. Główna idea polega na trzymaniu danych w jednym miejscu, a w razie potrzeby linkowania do danych. Taki sposób tworzenia bazy danych zwiększa bezpieczeństwo danych i zmniejsza ryzyko powstania niespójności (w szczególności problemów anomalii). Istnieją sposoby ustalenia czy dany schemat bazy danych jest znormalizowany, a jeżeli jest to jak bardzo. Jednym ze sposobów jest przyrównanie danej bazy do schematów zwanych postaciami normalnymi (ang. normal forms lub NF). Normalizacja bazy danych do konkretnej postaci może wymagać rozbicia dużych tabel na mniejsze i przy każdym wykonywaniu zapytania do bazy danych ponownego ich łączenia. Zmniejsza to wydajność, więc w niektórych przypadkach świadoma denormalizacja (stan bez normalizacji) jest lepsza zwłaszcza w systemach niekorzystających z modelu relacyjnego (np. OLAP- OnLine Analytical Processing). Edgar Frank Codd (twórca normalizacji) początkowo wymyślił 3 postacie normalne: 1NF, 2NF i 3NF. Obecnie istnieją jeszcze inne postacie, ale 3NF jest powszechnie uznawana za wystarczającą do większości projektów. Większość tabel spełniając postać 3NF, spełnia także BCNF (ang. Boyce-Codd normal form). 4NF i 5NF są następnymi rozszerzeniami, a 6NF jest używana do baz uwzględniających w modelu relacyjnym wymiar czasowy. 23
Pierwsza postać normalna (1NF) Mówimy, że tabela (encja) jest w pierwszej postaci normalnej, kiedy wiersz przechowuje informacje o pojedynczym obiekcie, nie zawiera kolekcji, posiada klucz główny (kolumnę lub grupę kolumn jednoznacznie identyfikujących go w zbiorze) a dane są atomowe. Pierwsza postać normalna Wyeliminuj powtarzające się grupy w poszczególnych tabelach. Utwórz osobną tabelę dla każdego zestawu powiązanych danych. Zidentyfikuj każdy zestaw powiązanych danych za pomocą klucza podstawowego. Druga postać normalna (2NF) 2 NF - tabela powinna przechowywać dane dotyczące tylko konkretnej klasy obiektów. Druga postać normalna Utwórz osobne tabele dla zestawów wartości dotyczących wielu rekordów. Powiąż te tabele za pomocą klucza obcego. Trzecia postać normalna (3NF) Trzecia postać normalna głosi, że kolumna informacyjna nie należąca do klucza nie zależy też od innej kolumny informacyjnej, nie należącej do klucza. Czyli każdy niekluczowy argument jest bezpośrednio zależny tylko od klucza głównego a nie od innej kolumny. Trzecia postać normalna Wyeliminuj pola, które nie zależą od klucza. Postać Boyce a-codda (BCNF): Treść: Baza danych znajduje się w postaci normalnej BCNF, kiedy spełnia warunki trzeciej postaci normalnej oraz gdy zachodzi zależność: X A i atrybut A nie zawiera się w X, to X jest kluczem bądź zawiera klucz. Ogólnie rzecz ujmując, postać BCNF jest sumą pierwszej, drugiej i trzeciej postaci normalnej. W praktyce oznacza to, iż wartością klucza obcego może być NULL albo klucz główny z innej tabeli. Należy mieć na uwadze, iż postać BCNF nie daje gwarancji, że redundacje poza zależnościami funkcyjnymi nie wystąpią. Piąta postać normalna Treść: Baza danych znajduje się w piątej postaci normalnej, kiedy spełnia warunki postaci BCNF oraz usunięto z niej zależności funkcjonalne, które nie wynikają z zależności od atrybutów klucza. Zasada ta mówi o fakcie nie istnienia rozkładu odwracalnego na zbiór mniejszych tabel, czyli tabela została podzielona na najmniejsze możliwe kawałki w celu eliminacji redundacji. 24