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