Modelowanie związków encji
Identyfikacja i zdefiniowanie
podstawowych obiektów danych
Diagramy E-R
Przetłumaczenie obiektów E-R na
konstrukcje relacyjne
Ustalenie modelu logicznego
Normalizacja logicznego modelu
danych
1
Właściwości encji
Jest istotna.
- Wypisujemy tylko encje ważne
Jest rodzajowa.
- Wypisujemy tylko typy rzeczy, a nie
indywidualne elementy.
Jest fundamentalna.
- Wypisujemy encje które egzystują niezależnie.
Jest jednolita.
- Upewnić się, że każda encja którą się nazywa
reprezentuje pojedynczą klasę.
2
Identyfikacja encji
osoba adres stacjonarny fax komórka
" Prywatna książka adresowa:
 osoby
 adresy
 telefony
3
Wybieranie atrybutów encji
Są istotne.
Są bezpośrednie, nie pochodne.
Są atomowe
Zawierają dane tego samego typu.
4
Identyfikacja atrybutów
osoba adres stacjonarny fax komórka
imię ulica st_numer fax_num k_num
nazwisko miasto st_typ od Era
data_ur województwo do Simplus
rocznice nr_kodu Orange
email
dziecko1
dziecko2
5
Definiowanie relacji
Typ relacji
Zależność egzystencjalna
Zależność egzystencjalna opisuje czy
encja będąca w relacji jest opcjonalna
czy obowiązkowa.
Kardynalność
Kardynalność określa ilość krotek w
relacji.
6
Ustalenie relacji
osoba adres numer numer numer
(stacjonarny)
(fax) (komórka)
osoba żaden
adres żaden
numer żaden
(stacjonarny)
numer żaden
(fax)
numer żaden
(komórka)
7
Ustalenie relacji
osoba adres
osoba brak
0-1
Jak wiele osób może być związanych z jednym adresem?
8
Ustalenie relacji
osoba adres
0-n
osoba brak
0-1
Jak wiele adresów może być skojarzonych z jedną osobą?
9
Ustalenie relacji
numer
osoba adres
(stacjonarny)
0-n
osoba brak
0-n
0-1
Jak wiele numerów stacjonarnych może być
skojarzonych z osobą?
10
Ustalenie relacji
Numer
osoba adres
(stacjonarny)
1
0-n
osoba brak
0-n
0-1
Jak wiele osób może być skojarzonych z numerem
stacjonarnym?
11
Ustalenie relacji
osoba adres numer numer numer
(stacjonarny)
(fax) (komórka)
osoba żaden 0-n 1 1-n 1
0-1 0-n 0-n 0-n
adres żaden żaden żaden żaden
numer żaden żaden żaden
(stacjonarny)
numer żaden żaden
(fax)
numer żaden
(komórka)
12
Reguły definiowania tabel,
wierszy i kolumn
Wiersze muszą być niezależne
Wiersze muszą być unikalne
Kolumny muszą być niezależne
Wartości w kolumnach muszą być
atomowe
Każda kolumna musi mieć unikalną
nazwę
Każda kolumna musi zawierać dane
pojedynczego typu
13
Nakładanie ograniczeń na
kolumny
Typ danych (Integer, Char, Date itp)
Format ( np. yy/mm/dd)
Zakres (np. od 1,000 do 5,400)
Znaczenie ( np. PESEL)
Dopuszczalne wartości (np. tylko S lub U)
Unikalność
Wartość Null
Wartość domyślna
Ograniczenia referencyjne
14
Diagramy E-R
osoba adres
relacja
encja encja
15
Symbole graficzne
opcjonalny opcjonalny
wiele
dokładnie jeden
16
Czytanie diagramów E-R
może mieć 0 lub dokładnie 1
osoba adres
może mieć 0 lub wiele
17
Diagram E-R
książki telefonicznej
osoba
nazwisko
imię
data_ur
adres
rocznice
ulica
email
miasto
dziecko1
województwo
dziecko2
dziecko3 nr_kodu
komórka
k_num
stacjonarny
fax
Era
Simplus
fax_num
st_numer
Orange
od
st_typ
do
18
Dodanie kluczy
osoba
PK=Primary Key
Nr_osoby PK
FK=Foreign Key
nazwisko
adres
imie
data_ur
Id_adr PK
rocznice
Nr_osoby FK
email
ulica
dziecko1
miasto
dziecko2
województwo
dziecko3
nr_kodu
komórka
k_num PK
stacjonarny
fax
nr_osoby FK
Era
fax_num PK
st_numer PK
Simplus
nr_osoby FK
nr_osoby FK
Orange
od
st_typ
do
19
Anomalie
Redundancja danych (redudancy)
dane niepotrzebnie powtarzają się w
kilku krotkach
Anomalia istnienia
jedna encja nie może istnieć bez drugiej
encji
Anomalia aktualizacji
wartość danej zostanie zmodyfikowana w
jednej krotce, a w drugiej nie
20
Normalizacja
Normalizacja to proces usuwania
anomalii (dekompozycja relacji)
Pierwsza postać normalna (1NF)
Druga postać normalna (2NF)
Trzecia postać normalna (3NF)
Czwarta postać normalna (4NF)
Piąta postać normalna (5NF)
21
1NF
ID Faktu Data_sp Odbiorca NIP Miejscow Adres Towar Ilość Cena_j VAT
01/10/05 05-10-13 Hurtown 345-456- Sopot Kolorowa papier, 100,2000
ołówek, ,100, 500
pióro,
gumka
" Postać ta wymaga, aby każdy element informacji,
zapisywany w wierszach i kolumnach był atomowy, tzn
niepodzielny (wartość była jednym z prostych typów
danych np. liczbą całkowitą, a nie kolekcją wartości typu
lista danych).
" Tabela w 1NF nie zawiera powtarzających się danych
(kolumn).
22
1NF
ID Faktu Data_sp Odbiorca NIP Miejscow Adres Towar Ilość Cena_j VAT
01/10/05 05-10-13 Hurtown 345-456- Sopot Kolorow papier, 100
01/10/05 05-10-13 Hurtown 345-456- Sopot Kolorow ołówek 2000
01/10/05 05-10-13 Hurtown 345-456- Sopot Kolorow pióro 100
01/10/05 05-10-13 Hurtown 345-456- Sopot Kolorow gumka 500
" Ponieważ dane o odbiorcy, numer faktury i data jej
wystawienia powtarzają się (redundancja danych), traci się
dużo pamięci.
" W przypadku zmiany adresu Odbiorcy, należałoby dokonać
zmian we wszystkich rekordach dotyczących tego klienta.
Zjawisko to nosi nazwę anomali aktualizacji.
" Taki sposób zapisu sugerowałby, że nie istnieje klient bez
faktury ( dwie encje mogą istnieć tylko razem).
Jest to tzw. anomalia istnienia.
23
2NF
Tabela jest w 2NF gdy jest w 1NF
Tabela jest w 2NF gdy każde z pól
nie wchodzących w skład klucza
zależy funkcjonalnie od całego
klucza, a nie od jego części.
Zależność funkcjonalna wskazuje, że
istnieją związki pomiędzy wartościami
pochodzącymi z dwóch różnych
kolumn.
24
Zależności funkcjonalne
Mówimy że kolumna A jest funkcjonalnie
zależna od B, jeśli dla każdej wartości w
kolumnie B istnieje dokładnie jedna
związana z nią wartość kolumny A.
Jeżeli kolumna nie jest zależna funkcyjnie
od klucza, to nie jest związana z encją.
25
Druga postać normalna (2NF)
Jeżeli tabela posiada klucz główny prosty,
to atrybut musi zależeć od klucza.
Jeżeli tabela posiada klucz główny złożony,
to atrybut musi zależeć od wartości
wszystkich kolumn klucza razem wziętych,
nie od jednej czy którejś z nich.
Jeżeli atrybut zależy również od innych
kolumn, to muszą być one kluczem
kandydującym.
26
2NF
ID Faktu Data_sp Odbiorca NIP Miejscow Adres Towar Ilość Cena_j VAT
01/10/05 05-10-13 Hurtown 345-456- Sopot Kolorow papier, 100
01/10/05 05-10-13 Hurtown 345-456- Sopot Kolorow ołówek 2000
01/10/05 05-10-13 Hurtown 345-456- Sopot Kolorow pióro 100
01/10/05 05-10-13 Hurtown 345-456- Sopot Kolorow gumka 500
Określenie klucza głównego tabeli
Faktura
tworzą go ID Faktury i Towar, bo tylko
ich kombinacja powoduje
rozróżnialność każdego wiersza w
tabeli.
27
2NF
ID Faktu Data_sp Odbiorca NIP Miejscow Adres Towar Ilość Cena_j VAT
01/10/05 05-10-13 Hurtown 345-456- Sopot Kolorow papier, 100
ID Faktu Data_sp Towar Ilość Cena_n VAT
01/10/05 05-10-13 Hurtown 345-456- Sopot Kolorow ołówek 2000
01/10/05 05-10-13 Hurtown 345-456- Sopot Kolorow pióro 100
01/10/05 05-10-13 papier, 100
01/10/05 05-10-13 Hurtown 345-456- Sopot Kolorow gumka 500
01/10/05 05-10-13 ołówek 2000
01/10/05 05-10-13 pióro 100
01/10/05 05-10-13 gumka 500
ID Faktury Odbiorca NIP Miejscow Adres
01/10/05 Hurtown 345-456- Sopot Kolorow
" Dane o odbiorcy zależą jedynie od ID Faktury (fakturę wystawia się
na danego klienta), a nie zależą od Towaru.
" Dwie encje Faktura i Odbiorca zostały mylnie połączone w jedną.
28
2NF
ID Faktu Data_sp Towar Ilość Cena_n VAT
01/10/05 05-10-13 papier, 100
01/10/05 05-10-13 ołówek 2000
01/10/05 05-10-13 pióro 100
01/10/05 05-10-13 gumka 500
ID Faktury Odbiorca NIP Miejscow Adres Data_sp
01/10/05 Hurtown 345-456- Sopot Kolorow 05-10-13
Data sprzedaży zależy od ID Faktury, ale
nie zależy od Towaru ( Każdy towar można
sprzedać dowolnego dnia).
29
2NF
ID Faktu Towar Ilość Cena_n VAT
01/10/05 papier, 100
01/10/05 ołówek 2000
01/10/05 pióro 100
01/10/05 gumka 500
ID Faktury Odbiorca NIP Miejscow Adres Data_sp
01/10/05 Hurtown 345-456- Sopot Kolorow 05-10-13
30
2NF
ID Faktu Towar Ilość Cena_n VAT
01/10/05 papier, 100
01/10/05 ołówek 2000
01/10/05 pióro 100
01/10/05 gumka 500
Ilość zależy od Towaru, ale zależy również
od
ID Faktury (na konkretnej fakturze jest
konkretna ilość), dlatego pozostaje w
tabeli.
31
2NF
ID Faktu Towar Ilość
01/10/05 papier, 100
01/10/05 ołówek 2000
01/10/05 pióro 100
01/10/05 gumka 500
ID Faktury Odbiorca NIP Miejscow Adres Data_sp
01/10/05 Hurtown 345-456- Sopot Kolorow 05-10-13
ID_Towaru Towar Cena_n VAT
papier 100 22
Cena i VAT są związane z towarem, nie
zależą od numeru faktury.
32
3NF
Tabela jest w 3NF jeżeli jest w 2NF.
Wszystkie atrybuty nie zależą tranzytywnie
od klucza głównego.
Zależność tranzytywna oznacza, że atrybut
opisujący klucz zależy nie tylko od klucza
głównego jako całości, ale również od innego
atrybutu opisującego klucz.
Aby przekształcić tabelę do 3NF należy
usunąć z tabeli atrybuty, które są zależne
od innych atrybutów opisujących klucz.
33
3NF
ID Faktury Odbiorca NIP Miejscow Adres Data_sp
01/10/05 Hurtown 345-456- Sopot Kolorow 05-10-13
Odbiorca NIP Miejscow Adres
ID Faktury NIP Data_sp
Hurtown 345-456- Sopot Kolorow
01/10/05 345-456- 05-10-13
" NIP, Miejscow., Adres są polami, które zależą od kolumny
Odbiorca.
" Kolumna Odbiorca nie jest polem kluczowym.
34
1 1
Id_faktury
Id_towaru
n
NIP
Towar
Cena Data_sp
Vat
NIP
Id_towaru
1
n
Odbiorca
Id_faktury
n
ilość Miejscow
Adres
35
ID_Faktury ID_Faktury
Data_sp ID_Towar
Ilość
Odbiorca
NIP ID_Faktury
ID_Faktury
Data_sp
Miejscow Data_sp
NIP
Odbiorca
Adres
NIP
NIP
ID_Towar
Miejscow
Odbiorca
Nazwa_towaru
Adres
Miejscow
Ilość
Adres
ID_Towaru
Cena_n
Nazwa_towaru
Vat
Cena_n
Vat
36
Normalizacja modelu danych
Uzyskanie większej elastyczność projektu
Zapewnienie, że atrybuty będą
umieszczone w odpowiednich tabelach
Redukcja redundancji danych
Poprawienie efektywności programowania
Niższe koszty zarządzania aplikacją
Maksymalizacja stabilności struktury
danych
37
Diagram przed normalizacją
osoba
PK=Primary Key
Nr_osoby PK
FK=Foreign Key
nazwisko
adres
imie
data_ur
Id_adr PK
rocznice
Nr_osoby FK
email
ulica
dziecko1
miasto
dziecko2
województwo
dziecko3
nr_kodu
komórka
k_num PK
stacjonarny
fax
nr_osoby FK
Era
fax_num PK
st_numer PK
Simplus
nr_osoby FK
nr_osoby FK
Orange
od
st_typ
do
38
Normalizacja tabeli Osoba
Nr_osoby Nazwisko Imię Data_ur Rocznice e-mail Dziecko1 Dziecko2 Dziecko3
Powtarzające się kolumny
Nr_osoby Nazwisko Imię Data_ur Rocznice e-mail
Nr_osoby Dziecko
39
Diagram po normalizacji
dziecko
osoba
PK=PrimaryKey
Nr_osoby FK
Nr_osoby PK
FK=ForeignKey
dziecko
nazwisko
adres
imie
data_ur
Id_adr PK
rocznice
Nr_osoby FK
email
ulica
miasto
województwo
nr_kodu
komórka
stacjonarny
Nazwa_fax
k_num PK
Fax_num PK FK
st_numer PK nr_osoby FK
Nr_osoby PK FK
nr_osoby FK
operator
st_typ
fax
fax_num PK
od
do
40
Modelowanie danych metodą
E-R, podsumowanie
Identyfikacja i zdefiniowanie podstawowych obiektów:
Encje
Relacje
Atrybuty
Przedstawienie graficzne obiektów przy użyciu diagramów
E-R.
Przetłumaczenie diagramów E-R na konstrukcje relacyjne:
Ustalenie dla każdej encji klucza głównego i obcego.
Ustalenie typu relacji
1:1
m:n
inny specjalny typ
Normalizacja modelu danych:
Pierwsza postać normalna
Druga postać normalna
41
Trzecia postać normalna.
Implementacja modelu danych
Zdefiniowanie domeny
Typy danych
Wartości domyślne
Ograniczenia (constraints)
Utworzenie bazy danych
Instrukcja CREATE DATE BASE
Instrukcja CREATE TABLE
Fragmentowanie tabel i indeksów
Dostęp do danych w tabelach
pofragmentowanych
42
Reguły Codda
1. Baza danych gromadzi wszystkie dane wewnątrz
krotek
2. Każda wartość może być dostępna przez kombinację
nazwy relacji, nazwy atrybutu i wartości klucza
podstawowego krotki
3. Wartości NULL wprowadzane są systematycznie
4. Katalog bazy danych jest przechowywany wewnątrz
jednej lub wielu relacji, które mogą być czytane przez
autoryzowanych użytkowników
5. System musi być zdolny do uaktualniania przez
perspektywę
43
Reguły Codda
6. System wdraża język zapytań, dzięki któremu
użytkownik może wykonywać następujące zadania:
- definiowanie relacji
- definiowanie perspektyw (ang. views)
- manipulowanie danymi
- ustawianie ograniczeń, aby narzucić integralność
danych
- przyznawanie i cofanie pozwoleń na przeglądanie lub
manipulowanie relacjami
- wiązanie manipulacji elementami bazy danych jako
transakcji
44
Reguły Codda
7. System musi być zdolny do wstawiania, aktualizowania
i usuwania grup krotek, nie tylko jednej krotki naraz
8. Programy, za pomocą których manipuluje się bazą
danych, są niezależne od tego, jak baza danych jest
fizycznie zorganizowana
9. Programy, za pomocą których baza danych jest
przetwarzana, są niezależne od tego, jak baza danych
jest logicznie zorganizowana wewnętrznie
45
Reguły Codda
10. Zasady, które artykułują semantyczny stopień
integralności, powinny być możliwe do opisania
wewnątrz języka zapytań systemu zarządzania bazą
danych. Możliwe powinno być również
zmagazynowanie ich wewnątrz katalogu systemu bazy
danych i narzucanie przez sam system zarządzania
bazą danych
11. Relacyjna baza danych powinna działać tak samo,
niezależnie od tego, czy pracuje na pojedynczej
maszynie, czy jest rozpowszechniana przez sieć
12. Nie można użyć języka niższego rzędu do obalenia
jedności zasad bazy danych
46