Projektowanie baz danych







Projektowanie baz danych

Podstawowe
zasady modelu relacyjnego
Charakterystyka
dobrej i zlej bazy danych
Etapy
projektowania bazy danych
Relacje

Normalizacja




PODSTAWOWE ZASADY MODELU
RELACYJNEGO
 
Podstawowe zasady modelu relacyjnego to:

Dane prezentowane sa uzytkownikom w postaci tabel;
Komórki zawieraja wartosci niepodzielne na mniejsze porcje informacji
Kazdy wiersz posiada wartosc (lub grupe wartosci), która go jednoznacznie
identyfikuje (klucz glówny)
W
przypadku okreslenia relacji miedzy tabelami dane z kolumny polaczonej relacja
musza miec swoje odpowiedniki w drugiej tabeli.
 
Back to
Top


CHARAKTERYSTYKA DOBREJ I ZLEJ
BAZY DANYCH
 
Dobrze zaprojektowana baza danych charakteryzuje sie tym, ze
dziala szybko i niezawodnie, znajdowanie w niej informacji jest logicznie proste
a ciagla aktualizacja nie wplywa na obnizenie jej stopnia niezawodnosci i
spójnosci. Oczywiscie w rzeczywistosci nie ma zlotego srodka i podniesienie
wydajnosci bazy danych w jednym miejscu najczesciej wiaze sie z jakims
negatywnym efektem ubocznym (zwiekszenie zawiklania, spadek szybkosci). Mozna
uznac, ze nie istnieje dobra baza danych, trzeba natomiast dazyc do efektu
wystarczajaco dobrej / zadowalajacej bazy danych. Pomóc w tym moze kilka zasad
mówiacych o zagrozeniach, których nalezy sie wystrzegac a stanowia „podstawy”
zle skonstruowanej bazy danych:

Tabele i kolumny maja niejasne nazwy (po n - czasie na pewno zapomnimy o
co chodzilo)
Ta sama informacja musi byc wprowadzona kilkakrotnie a jej zmiana musi byc
dokonywana w kilku róznych miejscach
Dzialanie bazy danych jest nieproporcjonalnie wolne do ilosci obrabianych
danych
Trudno okreslic relacje miedzy danymi
W tabelach wystepuja duplikujace sie wiersze
Jest
prawdziwa tragedia, kiedy to samo pytanie do tych samych danych zwraca rózne
wyniki
 
Back to
Top


ETAPY PROJEKTOWANIA BAZ
DANYCH
 
Etapy projektowania bazy danych to:

Okreslenie wymagan, zadan i celu przeznaczenia projektowanej bazy danych;
Okreslenie rodzaju danych (typów) przechowywanych w konkretnych kolumnach
tabel;
Przeprowadzenie normalizacji;
Napisanie kodu tworzacego baze i tabele bazy;
Zdefiniowanie uzytkowników i praw dostepu;
Wypelnienie
bazy informacjami – ew. przeprowadzenie testów;
 
Back to
Top


RELACJE
 
Wyrózniamy trzy rodzaje relacji:
Jeden do Jeden
Relacja zachodzi, gdy jeden element wykazuje zaleznosc
funkcyjna do drugiego. W przypadku wystapienia tej relacji miedzy danymi zwykle
umieszcza sie je w jednej tabeli.
 
Jeden do Wiele
Relacja zachodzi, gdy jeden element jest powiazany z kilkoma
innymi. Np. My w trójke napisalismy 30 róznych programów – kazdy po 10. Tworzymy
tabele osób (3 rekordy) i programów (30 rekordów). Kazdy rekord z tabeli osób
jest zwiazany (posiada relacje) do 10 rekordów z tablicy programów, ale kazdy
program jest tylko raz powiazany z jedna osoba z tabeli osób.
 
Wiele do Wiele
Utworzenie takiej relacji jest bardziej skomplikowane, poniewaz nie wystarczy
juz zdefiniowanie klucza obcego. Nalezy wówczas utworzyc oddzielna tabele
laczaca. Np. mamy tabele aktorów i filmów, przy czym wiadomo, ze w jednym filmie
gra wielu aktorów, ale jeden aktor moze grac w wielu filmach. Oznacza to, ze nie
da sie stworzyc polaczenia ról aktora z filmami w jednym rekordzie. Trzeba
bedzie dolozyc trzecia tabele, gdzie kluczem glównym bedzie kombinacja numeru
aktora i filmu.
 
Back to
Top


NORMALIZACJA
 
Normalizacja polega na wykryciu w obiektach bazy nadmiarowych
danych.
Istnieje kilka postaci normalnych opisujacych dane, przy czym
kazda wyzsza postac musi spelniac warunki poprzedniej. Normalizacji poddaje sie
tabele bazy danych w celu unikniecia problemów z edycja danych w bazie i bardzo
czesto wystarcza uzyskanie trzeciej postaci normalnej.
 
Dekompozycja
Dekompozycja polega na podzieleniu tabeli w taki sposób, by
zadne dane zgromadzone w tabeli zródlowej nie zostaly stracone a wszystkie
wykonane zmiany byly odwracalne.
 
Pierwsza postac normalna 1PN
Tabela spelnia zalozenia pierwszej postaci normalnej, jezeli
posiada tylko pola niepodzielne.
Oznacza to, ze gdyby wszystkie tabele spelnialy 1PN, to
relacje typu jeden do wiele bylyby zawsze okreslone miedzy kilkoma tabelami
(nigdy w obrebie jednej), a relacja typu jeden do jeden moglaby zawierac sie w
jednej tabeli.
 
Druga postac normalna 2PN
Tabela odpowiada drugiej postaci normalnej jezeli:

Tabela jest 1PN;
Kolumny nie wchodzace w sklad klucza sa zalezne od calego klucza (nie
tylko od jego czesci).
 
Trzecia postac normalna 3PN
Trzecia postac normalna wymaga, aby wszystkie kolumny nie
nalezace do klucza, zalezaly funkcyjnie od klucza kandydujacego.
Klucz kandydujacy spelnia te same warunki co klucz glówny i
charakteryzuje sie tym, ze:

Zadne dwa rekordy w tabeli nie moga miec tej samej kombinacji wartosci;
Z klucza kandydujacego nie mozna wyodrebnic podgrupy kolumn równiez
zapewniajacych unikatowosc danego rekordu.
W tej postaci normalnej nie sa wymagane zaleznosci pomiedzy
kolumnami poza kluczem.
 
Postac normalna Boyce-Codd’a BCPN
Ta postac normalna jest udoskonaleniem 3PN.
Róznica polega na tym, ze w 3PN kolumny nie nalezace do
klucza musza byc funkcyjnie zwiazane z kluczem kandydujacym, natomiast w BCPN,
gdzie wystepuje kilka kluczy kandydujacych zaleznosc ta dotyczy takze kolumn,
które naleza do innego klucza. Oznacza to, ze 3PN i BCPN rózni sie dla tabeli,
która:

Posiada kilka kluczy kandydujacych;
Przynajmniej dwa klucze kandydujace skladaja sie z wiecej niz jednej
kolumny;
Zlozone klucze kandydujace maja wspólna kolumne.
 
Back to
Top


Copyright � 2002 by JRSRevised: maj 21, 2002 .
Powrót do
poprzedniej strony