Alternatywna notacja modelowanie danych IDEF1X
Database -> Options ->Document :: Symbol set = IDEF1X (zamiast domyślnego Relational)
Związek identyfikujący – linia ciągła
Związek nieidentyfikujący – linia przerywana
Strona wiele związku – czarne kółko
Związek opcjonalny – romb przy encji po stronie jeden
Indeks - IE
Notacja IDEF1X jest używana w Erwinie - narzędziu CASE dostępnym w PJWSTK. Erwin modeluje też związki wieloznaczne:
Notacja modelowania danych Chena
Encja – prostokąt
Atrybut – koło
Rozszerzenia zasadniczego modelu w Visio
Definiowanie perspektyw (view)
Po wygenerowaniu do MS Access - kwerenda w widoku Projekt:
i w widoku SQL:
Hierarchia encji, związek kategorii
Osoba może być projektantem, analitykiem lub sekretarką. Cechy wspólne osób grupuje się w encji Osoba; cechy charakterystyczne dla odpowiedniej grupy osób w jednej z podencji Projektant, Analityk lub Sekretarka.
Atrybut Stanowisko, nazywany wyróżnikiem kategorii, decyduje o zaliczeniu osoby do jednej z podencji. Kategoria została określona jako pełna (complete) tzn. każda osoba trafia do jednej z trzech podencji.
Związek kategorii można zastąpić zbiorem związków jedno-jednoznacznych między nadencją kategorii i podencjami kategorii.
Oto zestaw narzędzi opcji Entity Relationship do tworzenia elementów diagramu związków encji:
W bazie danych generowane są tabele dla każdej z podencji.
Jakość schematu bazy danych
Pożądane cechy modelu danych
Poprawność modelu.
Istotność każdego elementu modelu dla funkcjonowania firmy (organizacji).
Pełność modelu - gwarancja, że żaden element modelu danych - istotny dla funkcjonowania firmy (organizacji), nie został pominięty.
Na koniec
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 traktuje uzgodniony z użytkownikami model danych jako wierne odzwierciedlenie rzeczywistości i dla tego modelu buduje bazę danych i aplikację bazy danych.
Każdy fakt przechowywany w bazie danych powinien być wyrażalny w niej tylko na jeden sposób.
Przypomnienie: Klucz - atrubut lub grupa atrybutów, których wartości jednoznacznie określają instancję encji (wiersz w tabeli). Jeden - główny, pozostałe alternatywne. Jedna encja może mieć wiele kluczy.
Dlaczego niektóre schematy tabel są złe?
Dostawcy = {Nazwa_dostawcy, Adres_dostawcy, Nazwa_towaru, Cena}
Nazwa_dostawcy | Adres_dostawcy | Nazwa_towaru | Cena |
Kowalski | Wiolinowa 7 | Telewizor | 1500 |
Kowalski | Wiolinowa 7 | Radio | 500 |
Jaworski | Mozarta 5 | Telewizor | 1800 |
Jaworski | Mozarta 5 | Komputer | 5000 |
Kowalski | Wiolinowa 7 | Baterie | 5 |
Marciniak | Warszawska 140 | Magnetowid | 1000 |
Redundancja: adres dostawcy powtarza się dla każdego dostarczanego towaru.
Anomalie przy modyfikacji: uaktualniony adres w jednym wierszu pozostaje niezmieniony w innych.
Anomalie przy wstawianiu: trudno wstawić dostawcę bez towarów; towar wchodzi w skład klucza - nie może być NULL.
Anomalie przy usuwaniu: usuwając informacje o wszystkich towarach dostarczanych przez dostawcę (który może zmienić profil produkcji) usuwamy informację o samym dostawcy.
Przyczyna: złączenie w jednej encji dwóch różnych rodzajów obiektów (encji):
Dostawcy = {Nazwa_dostawcy, Adres_dostawcy}
Towary = {Nazwa_dostawcy, Nazwa_towaru, Cena}
Pracownicy = {Id_prac, Nazwisko, Uczelnia, Adres}
Id_prac | Nazwisko | Uczelnia | Adres |
101 | Kowalski | PJWSTK | Koszykowa 86 |
123 | Kalinowski | WSI | Zamiany 15 |
109 | Jaworski | WSI | Zamiany 15 |
102 | Makowski | PJWSTK | Koszykowa 86 |
105 | Rudziak | WSI | Zamiany 15 |
Redundancja: adres uczelni powtarza się dla każdego zatrudnionego w niej pracownika.
Anomalie przy modyfikacji: uaktualniony adres uczelni w jednym wierszu pozostaje niezmieniony w innych.
Anomalie przy wstawianiu: trudno wstawić uczelnię bez pracownika; Id_prac stanowi klucz i nie może być NULL.
Anomalie przy usuwaniu: usuwając wszystkich pracowników usuwamy uczelnię.
Przyczyna: złączenie w jednej encji dwóch różnych rodzajów obiektów
(encji):
Pracownicy = {Id_prac, Nazwisko, Uczelnia}
Uczelnie = {Uczelnia, Adres}
Zależności funkcyjne
Atrybuty mogą być powiązane zależnościami funkcyjnymi: wartość jednego lub więcej atrybutów determinuje jednoznacznie wartość innego atrybutu np. Nazwa_dostawcy implikuje Adres_dostawcy co zapisujemy:
Nazwa_dostawcy -> Adres_dostawcy
Zawsze klucz determinuje jednoznacznie każdy atrybut.
Wyjaśnienie złych schematów za pomocą pojęcia zależności funkcyjnej między atrybutami tabeli
(1) Dla schematu tabeli
Dostawcy = {Nazwa_dostawcy,Adres_dostawcy,Nazwa_towaru,Cena}
kluczem jest para atrybutów: Nazwa_dostawcy i Nazwa_towaru,
Adres_dostawcy zależy od części klucza: od Nazwa_dostawcy.
Mówimy, że wartość atrybutu Adres_dostawcy zależy częściowo od klucza:
Nazwa_dostawcy ® Adres_dostawcy
a samą zależność nazywamy zależnością częściową.
(2) Dla schematu tabeli:
Pracownicy = {Id_prac,Nazwisko,Uczelnia,Adres}
kluczem jest atrybut Id_prac,
Adres zależy od innego atrybutu - Uczelnia, który nie jest kluczem.
Mówimy w takim przypadku, że wartość atrybutu Adres zależy przechodnio od klucza:
Uczelnia ® Adres
a samą zależność nazywamy zależnością przechodnią.
Zależność od czegokolwiek innego niż klucz wprowadza wewnętrzną zależność między atrybutami tabeli. Powoduje możliwość determinowania wartości jednych atrybutów przez inne (redundancję).
W schematach Dostawcy i Pracownicy występują zależności od czegoś innego niż klucz, odpowiednio:
Nazwa_dostawcy ® Adres_dostawcy
(zależność częściowa)
Uczelnia ® Adres
(zależność przechodnia)
Metoda eliminowania „złych” zależności polega na wprowadzeniu dla zależności (częściowej lub przechodniej) osobnej tabeli i usunięciu atrybutu stojącego po prawej stronie tej zależności z oryginalnego schematu.
(1) Dla schematu dostawców dodajemy schemat tabeli {Nazwa_dostawcy, Adres_dostawcy} i usuwamy z oryginalnego schematu atrybut Adres_dostawcy: {Nazwa_dostawcy, Nazwa_towaru, Cena}.
(2) Dla schematu pracowników dodajemy schemat tabeli {Uczelnia, Adres} i usuwamy z oryginalnego schematu atrybut Adres: {Id_prac, Nazwisko, Uczelnia}.
W ten sposób zależności funkcyjne dyktują, jakie powinny być tabele w schemacie bazy danych. Najlepiej, aby każda zależność funkcyjna określała pojedynczy schemat tabeli.
Postać normalna Boyce’a-Codda - schemat tabeli zawierający wyłącznie zależności od klucza.
Jeśli schemat tabeli jest w postaci Boyce'a-Codda, nie ma redundancji. Nie można wówczas przewidzieć jednych wartości atrybutów w tabeli w oparciu o inne.
Schemat nie dający się sprowadzić do postaci Boyce’a-Codda
Nie każdy schemat tabeli da się sprowadzić do zbioru schematów tabel w postaci Boyce’a-Codda, np:
{Miasto, Ulica, Kod}.
z zależnościami:
{Miasto, Ulica} ® Kod
oraz
Kod ® Miasto
Są dwa klucze:
{Miasto, Ulica}
{Kod, Ulica}
Ze względu na zależność Kod ® Miasto schemat nie jest w postaci normalnej Boyce'a-Codda.
Tego schematu nie daje się rozłożyć z zachowaniem zależności funkcyjnych (bo jedna z zależności funkcyjnych obejmuje wszystkie atrybuty).
Atrybut kluczowy - atrybut wchodzący w skład jednego z kluczy encji (schematu tabeli).
Trzecia postać normalna - zezwala na zależności nie od klucza ale tylko między atrybutami kluczowymi, np:
Kod ® Miasto.