1

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

2

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ę

.

3

Identyfikacja encji

osoba

adres

stacjonarny

fax

komórka

•Prywatna książka adresowa:

– osoby

– adresy

– telefony

4

Wybieranie atrybutów encji

Są istotne.

Są bezpośrednie, nie pochodne.

Są atomowe

Zawierają dane tego samego typu.

5

Identyfikacja atrybutów

osoba

adres

stacjonarny

fax

komórka

imię
nazwisko
data_ur
rocznice
email
dziecko1
dziecko2

ulica
miasto
województwo
nr_kodu

st_numer
st_typ

fax_num
od
do

k_num
Era
Simplus
Orange

6

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.

7

Ustalenie relacji

osoba

adres

numer

(stacjonarny)

numer

(fax)

numer

(komórka)

osoba

ż

aden

adres

ż

aden

numer

(stacjonarny)

ż

aden

numer

(fax)

ż

aden

numer

(komórka)

ż

aden

8

Ustalenie relacji

0-1

brak

adres

osoba

osoba

Jak wiele osób może być związanych z jednym adresem?

9

Ustalenie relacji

0-n

0-1

brak

adres

osoba

osoba

Jak wiele adresów może być skojarzonych z jedną osobą?

10

Ustalenie relacji

0-n

0-n

0-1

brak

adres

numer
(stacjonarny)

osoba

osoba

Jak wiele numerów stacjonarnych może być
skojarzonych z osobą?

11

Ustalenie relacji

0-n

1

0-n

0-1

brak

adres

Numer
(stacjonarny)

osoba

osoba

Jak wiele osób może być skojarzonych z numerem
stacjonarnym?

12

Ustalenie relacji

osoba

adres

numer

(stacjonarny)

numer

(fax)

numer

(komórka)

osoba

ż

aden

0-n

0-1

1

0-n

1-n

0-n

1

0-n

adres

ż

aden

ż

aden

ż

aden

ż

aden

numer

(stacjonarny)

ż

aden

ż

aden

ż

aden

numer

(fax)

ż

aden

ż

aden

numer

(komórka)

ż

aden

13

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

14

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

15

Diagramy E-R

encja

encja

relacja

adres

osoba

16

Symbole graficzne

opcjonalny

opcjonalny

dokładnie jeden

wiele

17

Czytanie diagramów E-R

adres

osoba

może mieć 0 lub wiele

może mieć 0 lub dokładnie 1

18

Diagram E-R
książki telefonicznej

osoba

adres

komórka

fax

stacjonarny

nazwisko
imię
data_ur
rocznice
email
dziecko1
dziecko2
dziecko3

st_numer
st_typ

fax_num
od
do

k_num
Era
Simplus
Orange

ulica
miasto
województwo

nr_kodu

19

Dodanie kluczy

osoba

adres

komórka

fax

stacjonarny

Nr_osoby PK
nazwisko
imie
data_ur
rocznice
email
dziecko1
dziecko2
dziecko3

st_numer PK
nr_osoby FK
st_typ

fax_num PK
nr_osoby FK
od
do

k_num PK
nr_osoby FK
Era
Simplus
Orange

Id_adr PK
Nr_osoby FK
ulica
miasto
województwo

nr_kodu

PK=Primary Key
FK=Foreign Key

20

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

21

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)

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

Kolorowa

papier,
ołówek,
pióro,
gumka

100,2000
,100, 500

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

23

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.

24

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.

25

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

26

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.

27

2NF

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.

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

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

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ą

.

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

29

2NF

Data sprzedaży zależy od ID Faktury, ale
nie zależy od Towaru ( Każdy towar można
sprzedać dowolnego dnia).

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

30

2NF

ID Faktury

Odbiorca

NIP

Miejscow

Adres

Data_sp

01/10/05

Hurtown

345-456-

Sopot

Kolorow

05-10-13

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

31

2NF

Ilość zależy od Towaru, ale zależy również
od
ID Faktury (na konkretnej fakturze jest
konkretna ilość), dlatego pozostaje w
tabeli.

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

32

2NF

Cena i VAT są związane z towarem, nie
zależą od numeru faktury.

ID Faktury

Odbiorca

NIP

Miejscow

Adres

Data_sp

01/10/05

Hurtown

345-456-

Sopot

Kolorow

05-10-13

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_Towaru

Towar

Cena_n

VAT

papier

100

22

33

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.

34

3NF

•NIP, Miejscow., Adres są polami, które zależą od kolumny
Odbiorca

.

•Kolumna Odbiorca nie jest polem kluczowym.

ID Faktury

Odbiorca

NIP

Miejscow

Adres

Data_sp

01/10/05

Hurtown

345-456-

Sopot

Kolorow

05-10-13

Odbiorca

NIP

Miejscow

Adres

Hurtown

345-456-

Sopot

Kolorow

ID Faktury

NIP

Data_sp

01/10/05

345-456-

05-10-13

35

Towar

Id_towaru

Cena

Vat

Id_faktury

Id_towaru

ilość

Id_faktury

Data_sp

NIP

NIP

Miejscow

Odbiorca

Adres

1

1

1

n

n

n

36

ID_Faktury

Data_sp

Odbiorca

NIP

Miejscow

Adres

ID_Towar

Nazwa_towaru

Ilość

Cena_n

Vat

ID_Faktury

ID_Towar

Ilość

ID_Towaru

Nazwa_towaru

Cena_n

Vat

ID_Faktury

Data_sp

NIP

NIP

Odbiorca

Miejscow

Adres

ID_Faktury

Data_sp

Odbiorca

NIP

Miejscow

Adres

37

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

38

Diagram przed normalizacją

osoba

adres

komórka

fax

stacjonarny

Nr_osoby PK
nazwisko
imie
data_ur
rocznice
email
dziecko1
dziecko2
dziecko3

st_numer PK
nr_osoby FK
st_typ

fax_num PK
nr_osoby FK
od
do

k_num PK
nr_osoby FK
Era
Simplus
Orange

Id_adr PK
Nr_osoby FK
ulica
miasto
województwo

nr_kodu

PK=Primary Key
FK=Foreign Key

39

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

40

Diagram po normalizacji

osoba

adres

komórka

fax

stacjonarny

Nr_osoby PK
nazwisko
imie
data_ur
rocznice
email

st_numer PK
nr_osoby FK
st_typ

fax_num PK
od
do

k_num PK
nr_osoby FK
operator

Id_adr PK
Nr_osoby FK

ulica

miasto

województwo
nr_kodu

PK=PrimaryKey
FK=Foreign Key

Fax_num PK FK
Nr_osoby PK FK

Nr_osoby FK
dziecko

dziecko

Nazwa_fax

41

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

Trzecia postać normalna.

42

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

43

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ę

44

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

45

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

46

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