Projektowanie relacyjnych baz danych – diagramy związków encji Powtórzenie wykładu 1 Projektowanie relacyjnych baz danych – diagramy związków encji

Projektowanie schematu bazy danych Celem procesu projektowania schematu bazy danych jest: wyspecyfikowanie wymagań użytkowników przyszłej bazy danych, dokonanie analizy tych wymagań; 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.

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.

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) lub w postaci graficznej:

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.

Reprezentowanie związku nie-jednoznacznego Związek >2 argumentowy. 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.

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.

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.

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ą).

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.

Reverse Engineering Jest też możliwość wprowadzania zmian dokonywanych w systemie bazy danych z powrotem do diagramu w ErWinie: Tasks  Reverse Engineer