POWT1

Powtórzenie
wykładu 1
Projektowanie relacyjnych baz
danych – diagramy związków
encji
SBD, L.Banachowski
1
Projektowanie schematu bazy danych
Celem procesu projektowania schematu bazy danych jest:
1. wyspecyfikowanie wymagań użytkowników przyszłej bazy
danych, dokonanie analizy tych wymagań;
2. utworzenie schematu bazy danych spełniającego wymagania
użytkowników i jednocześnie gwarantującego poprawne
funkcjonowanie bazy danych w ramach całego systemu
informacyjnego, zaprojektowanie schematu bazy danych.
SBD, L.Banachowski
2
Pośredni model - diagram związków
encji ERD (notacja Erwin firmy LogicWorks)
• Ten pośredni model powinien w sposób jednoznaczny określać
wymagania użytkowników - umożliwiając im sprawdzenie czy
analityk systemu rzeczywiście dobrze zrozumiał ich intencje i
specyfikę działania firmy.
• Ten pośredni model powinien być istotnie prostszy od schematu
bazy danych, abstrahując od szczegółów implementacyjnych, które
muszą być później opracowane przez projektanta bazy danych aby
baza danych mogła powstać i spełniać postawione przed nią zadania.
SBD, L.Banachowski
3
Związek (nazywany przez niektórych relacją)
• Uporządkowana lista
encji, poszczególne encje mogą
występować wielokrotnie (w Erwinie związki są tylko binarne).
• Każdy związek określa pewną relację między zbiorami
egzemplarzy encji wchodzącymi w skład związku. Relację tę
nazywamy instancją związku.
•
Związek można formalnie zapisać przy użyciu notacji relacyjnej:
Z(E1,...,En)
SBD, L.Banachowski
lub w postaci graficznej:
4
Reprezentacja związku jednoznacznego
W relacyjnej bazie danych dwie encje połączone związkiem
jednoznacznym są reprezentowane przez dwie tabele, a sam związek
jednoznaczny jest reprezentowany powiązaniem przez wartość
klucza obcego w tabeli odpowiadającej encji po stronie wiele
związku i klucza głównego w tabeli odpowiadającej encji po stronie
jeden.
SBD, L.Banachowski
5
Reprezentowanie związku nie-jednoznacznego
1. Związek >2 argumentowy.
2. Związek binarny wieloznaczny.
Metoda:
Do reprezentowania takiego związku Z(E1,E2,…,En) używamy
dodatkowej encji nazywanej asocjacyjną, którą łączymy związkami
jednoznacznymi (encja asocjacyjna po stronie wiele tych związków)
z encjami E1, E2,….,En.
SBD, L.Banachowski
6
Normalizacja bazy danych
Każdy fakt przechowywany w bazie danych powinien
być wyrażalny w niej tylko na jeden sposób.
• Informacja o przedmiocie powinna być zapisana tylko w jednym
miejscu, a nie przy każdym studencie, który uczęszcza na zajęcia z
tego przedmiotu.
• Jeśli w bazie danych zapisujemy informację o rodzicach każdej
osoby, nie ma już potrzeby zapisywać informacji o dziadkach, gdyż ta
informacja daje się wyprowadzić z informacji o rodzicach.
• W modelu firmy lotniczej (przykład rozważany w następnym
punkcie) Pasażerowie i Personel to dwie odrębne encje. Jeśli
jedna osoba będzie figurować w bazie danych - raz jako pasażer, a raz
jako pracownik firmy lotniczej, wówczas dane dotyczące takiej osoby
(np. adres zamieszkania) będą zapisane w dwóch różnych miejscach.
SBD, L.Banachowski
7
Pożądane cechy modelu danych
•
poprawność modelu;
• istotność każdego elementu modelu dla funkcjonowania firmy
(organizacji);
•
pełność modelu – to znaczy, gwarancja, że żaden element modelu
danych - istotny dla funkcjonowania firmy (organizacji), nie został
pominięty.
Użytkownicy muszą:
•
rozumieć tworzony model danych i
• po dokładnym przeanalizowaniu wszystkich szczegółów, biorąc za
to odpowiedzialność, zaakceptować go.
Projektant bazy danych dla tego modelu buduje bazę danych i
aplikację bazy danych.
SBD, L.Banachowski
8
Akcje referencyjne dla
zachowania więzów
referencyjnych
• CASCADE - gdy usuwa się dane pasażera, system bazy danych usunie wszystkie
rezerwacje dokonane przez tego pasażera.
• RESTRICT - dopóki są rezerwacje dokonane przez pasażera nie można go usunąć z
bazy danych.
• SET-TO-NULL - przy usuwaniu pasażera wstawia się NULL do klucza obcego
wskazującego w rezerwacji na pasażera, którego dotyczy ta rezerwacja. (możliwe dla
związków nieidentyfikujących z opcją NULL).
• SET-TO-DEFAULT - przy usuwaniu pasażera zmieniamy rezerwację na ustalonego
z góry użytkownika np. system.
• NONE – usuwamy pasażera bez zmiany rezerwacji (niemożliwe ze względu na
spójność referencyjną).
SBD, L.Banachowski
9
Forward Engineering
• Erwin może wygenerować gotowy schemat bazy danych w
jednym z wielu systemów zarządzania bazą danych. Po wybraniu z
menu
Server  Target Server
ustalamy docelowy system, a z kolei po wybraniu z menu
Tasks  Forward Engineer
mamy możliwość bezpośredniego połączenia z systemem bazy danych
(np. Oracle, Access lub SQL Server) i utworzenia w nim bazy danych.
SBD, L.Banachowski
10
Reverse Engineering
• Jest też możliwość wprowadzania zmian dokonywanych w
systemie bazy danych z powrotem do diagramu w ErWinie:
Tasks 
SBD, L.Banachowski
Reverse Engineer
11