podstawy relacyjnych baz danych wyklad cz3 projektowanie

background image

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

background image

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ę

.

background image

3

Identyfikacja encji

osoba

adres

stacjonarny

fax

komórka

•Prywatna książka adresowa:

– osoby

– adresy

– telefony

background image

4

Wybieranie atrybutów encji

Są istotne.

Są bezpośrednie, nie pochodne.

Są atomowe

Zawierają dane tego samego typu.

background image

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

background image

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.

background image

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

background image

8

Ustalenie relacji

0-1

brak

adres

osoba

osoba

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

background image

9

Ustalenie relacji

0-n

0-1

brak

adres

osoba

osoba

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

background image

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

background image

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?

background image

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

background image

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

background image

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

background image

15

Diagramy E-R

encja

encja

relacja

adres

osoba

background image

16

Symbole graficzne

opcjonalny

opcjonalny

dokładnie jeden

wiele

background image

17

Czytanie diagramów E-R

adres

osoba

może mieć 0 lub wiele

może mieć 0 lub dokładnie 1

background image

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

background image

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

background image

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

background image

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)

background image

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

background image

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.

background image

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.

background image

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

background image

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.

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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.

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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.

background image

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

background image

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ę

background image

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

background image

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

background image

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


Wyszukiwarka

Podobne podstrony:
podstawy relacyjnych baz danych wyklad cz3 projektowanie
podstawy relacyjnych baz danych wyklad cz1 architektura
Projektowanie baz danych Wykłady Sem 5, pbd 2006.01.07 wykład03, Podstawy projektowania
WPROWADZENIE DO RELACYJNYCH BAZ DANYCH POJECIA PODSTAWOWE
Projektowanie baz danych Wykłady Sem 5, pbd 2005.10.02 wykład01, Każda dyscyplina naukowa posiada sw
Obiektowe rozszerzenia relacyjnych baz danych
Zestaw 1, Wprowadzenie do relacyjnych baz danych
Zestaw 1 Wprowadzenie do relacyjnych baz danych
Podstawowe silniki baz danych
Systemy baz danych wykład
Bazy danych - podstawowe kroki w projektowaniu cz 2 - wyklady, Zajęcia z Baz Danych - MS Access, cz
Bazy danych - podstawowe kroki w projektowaniu cz 2 - wyklady, Zajęcia z Baz Danych - MS Access, cz
Demografia (wykład), demografia alicja szuman, Podstawowe pojęcia z zakresu baz danych

więcej podobnych podstron