slajd 1

© J.Rumiński

Jacek Rumiński

Bazy danych

Kontakt:

Katedra Inżynierii Biomedycznej, pk.

106,

tel.: [phone], fax: [phone],
e-mail: [e-mail]

slajd 2

© J.Rumiński

Projektowanie relacyjnych baz danych

-Specyfikacja – język naturalny,

-Diagramy związków encji (ERD – Entity-Relationship Diagrams) ,

-Diagramy relacyjne (odwzorowanie ERD-DR),

-Diagramy relacyjne a SQL.

slajd 3

© J.Rumiński

(na podstawie James Larson, Carol Larson, EVALUATION OF FOUR LANGUAGES FOR SPECIFYING
CONCEPTUAL DATABASE DESIGNS, Data Management Handbook, CRC Press, 1999).

Grupa encji

Atrybut

slajd 4

© J.Rumiński

ERD - Peter Chen w 1976 roku, inna notacja IDEF1X standaryzowana
przez wojsko.

Encja – byt, konkretny i jednostkowy egzemplarz, to co istnieje (np.
Kowalski).

Atrybut – cecha charakterystyczna encji (np. kolor oczu). Atrybut
reprezentowany jest na diagramach ZE poprzez owal.

Grupa/zbiór encji – zgrupowane encje o tej samej charakterystyce-
atrybutach (np. studenci).
Zbiór encji reprezentowany jest na diagramach ZE przez prostokąt.

Klucz – zbiór atrybutów, których wartości zapewniają unikalność encji –
ograniczenie
wartości atrybutów (key constraint). Klucz reprezentowany jest na
diagramach ZE poprzez podkreślenie nazwy atrybutu/atrybutów.

Zbiór związków – związki pomiędzy encjami, jeden-do-wielu; wiele-do-
jednego; wiele-do-wielu.

slajd 5

© J.Rumiński

slajd 6

© J.Rumiński

Związki – związek jeden do wielu i wiele do jednego

slajd 7

© J.Rumiński

slajd 8

© J.Rumiński

Związki –wiele do wielu

slajd 9

© J.Rumiński

Hierarchia

slajd 10

© J.Rumiński

Reguły składni diagramów ZE. Często weryfikowane przez

narzędzia wspomagające projektowanie baz danych.

1. Każdy atrybut jest powiązany z dokładnie jednym

zbiorem encji lub zbiorem związków.
(Nie mogą istnieć odseparowane atrybuty, lub
powiązane z wieloma zbiorami encji lub relacji).

2. Każdy zbiór związków jest powiązany z co najmniej

dwoma zbiorami encji.

3. Każdy zbiór encji jest pośrednio powiązany z każdym

zbiorm encji diagramu. (Jeżeli diagram można podzielić
na dwa rozłączne to modelują one dwa schematy a nie
jeden schemat bazy danych.)

slajd 11

© J.Rumiński

Reguły znaczeniowe (semantyczne) diagramów ZE.

Konieczna znajomość specyfikacji bazy danych i jej
przeznaczenia.

1. Każdy atrybut powinien mieć unikalną nazwę.

(Nazwa powinna jednoznacznie wskazywać atrybut.
Jeżeli dwa zbiory encji mają atrybuty o tej samej nazwie
to należy je przekształcić dodając przedrostek w nazwie,
np. nazwy zbioru encji).

slajd 12

© J.Rumiński

2. Każdy zbiór encji powinien mieć unikalną nazwę. (Zbiór
encji jest odwzorowywany w kolekcję danych np. tabele,
których nazwy muszą być unikalne).

slajd 13

© J.Rumiński

2. Każdy zbiór encji powinien mieć unikalną nazwę. (Zbiór
encji jest odwzorowywany w kolekcję danych np. tabele,
których nazwy muszą być unikalne).

slajd 14

© J.Rumiński

3. Każdy zbiór związków łączący parę tych samych
zbiorów encji powinien mieć unikalną nazwę.

slajd 15

© J.Rumiński

4. Żaden atrybut nie może mieć wielu wartości. (Model
relacyjny wyklucza wiele wartości jednego atrybutu).

slajd 16

© J.Rumiński

Pierwsza postać normalna (1NF – First
Normal Form):

Każdy atrybut tabeli jest niepodzielny (atomowy).
Przecięcie krotki i atrybutu zawiera pojedynczą wartość.
W tabeli nie mogą znajdować się zatem powtarzające
grupy.

Przykład złamania reguły: imię i nazwisko jako jedna
wartość atrybutu.

slajd 17

© J.Rumiński

5. Żaden zbiór encji czy związków nie może posiadać
powtarzających się grup. (Problem wielokrotnych zbiorów
atrybutów – np. wiele adresów jednego studenta).

slajd 18

© J.Rumiński

6. Atrybuty klucza zbioru encji funkcyjnie określają
wszystkie wartości atrybutów powiązanych z danym
zbiorem encji. (Atrybut Y relacji R jest funkcyjne zależny od
atrybutu X, jeżeli zawsze każdej wartości x atrybutu X odpowiada
nie więcej niż jedna wartość y atrybutu Y. Jeżeli Y zależy
funkcyjnie od X to X wyznacza Y)

slajd 19

© J.Rumiński

Zbiór atrybutów Y jest w pełni zależny funkcyjnie od zbioru atrybutów X relacji
R, jeżeli X->Y i nie istnieje podzbiór X’ zawarty w X, taki że X’ ->Y.

Zbiór atrybutów Y jest w częściowo zależny funkcyjnie od zbioru atrybutów X relacji
R, jeżeli X->Y i istnieje podzbiór X’ zawarty w X, taki że X’ ->Y.

Druga postać normalna:

Relacja R jest w drugiej postaci normalnej (2NF) jeżeli
żaden atrybut wtórny tej relacji nie jest częściowo
funkcyjnie zależny od żadnego z kluczy relacji R.
Inaczej – w krotce (wierszu) nie może być atrybutów
(danych) zależnych od fragmentu klucza głównego (np.
gdy jest zdefiniowany z więcej niż jednego atrybutu).

slajd 20

© J.Rumiński

Trzecia postać normalna:

Relacja R o danym schemacie jest w trzeciej postaci
normalnej (3NF), jeżeli jest w drugiej postaci normalnej i
żaden atrybut wtórny tej relacji nie jest przechodnio
zależny od klucza głównego tej relacji.
Inaczej – atrybuty nie wchodzące w skład klucza
głównego zależą jedynie od klucza głównego.

Zbiór atrybutów Y jest przechodnio funkcyjnie zależny od
zbioru atrybutów X w schemacie relacji R, jeżeli X Y i istnieje

zbiór atrybutów Z, nie będący podzbiorem żadnego klucza
schematu relacji R, taki że zachodzi X Z i Z->Y.

→Y.

slajd 21

© J.Rumiński

Reguły pragmatyczne (upraszczające model).

1. Usuwać nadmiarowe zbiory związków.

slajd 22

© J.Rumiński

2. Rozdziel zbiór encji jeśli jego atrybuty są
wykorzystywane w różnych kontekstach (np.
optymalizacja czasowa).

slajd 23

© J.Rumiński

3. Zamień każdy zbiór związków wiele-do-wielu na dwa
jeden-do-wielu i dodatkowy zbiór encji. (Dopasowanie do
modelu relacyjnego).

slajd 24

© J.Rumiński

Dodatkowe wskazówki projektowe.

Reguły biznesowe: reguły określające ważne wartości
(domenę) atrybutów (liczebność, przynależność,
zależności funkcyjne).

Opisuj stosowane kody (np. 1 mężczyzna, 2 kobieta)

Opisuj elementy danych – jakie wartości atrybutu są
dopuszczalne, do kiedy ważne, w jakich jednostkach, itp.

slajd 25

© J.Rumiński

Odwzorowanie diagramu ZE na model relacyjny

Klucze kandydujące,

Klucze główne,

Tabele,

Klucze obce,

Typy danych

Relacje

slajd 26

© J.Rumiński

Klucze

Każdy podzbiór SK (superkey, superklucz) atrybutów
relacji R, taki że dla każdych dwóch krotek k relacji R:
k1(SK)<>k2(SK) jest nazywany superkluczem
(nadkluczem) relacji R.

Kluczem K schematu relacji R nazywamy taki klucz, że nie
istnieje żaden inny klucz K’ zawarty w K.

Jeżeli relacja R zawiera więcej niż jeden klucz, wówczas
nazywane są one kluczami kandydującymi (candidate key).

W procesie odwzorowania modelu koncepcyjnego na
model relacyjny ustalamy klucze kandydujące, oraz
wybieramy z nich klucz główny.
Jeżeli żaden z kluczy kandydujących nie spełnia naszych
oczekiwań (ze względu na efektywność działania – liczby
zamiast łańcuchów znaków) można utworzyć nowy atrybut,
spełniający wymagania klucza głównego. Klucz powinien
być ograniczony co najmniej zapewnieniem iż jego wartość
będzie: NIE PUSTA (NOT NULL) i UNIKALNA (UNIQUE).

slajd 27

© J.Rumiński

Zbiory encji -> Relacje (tabele)

Kolejnym krokiem odwzorowania jest utworzenie
relacji/tabel na podstawie zbiorów encji. Spełniwszy
wymagania co do diagramów ZE (np. wymagania
normalizacji) pozostaje głównie określenie dozwolonych
nazw atrybutów oraz określenie typów danych ich zakresu
(dziedziny).

Klucze obce

Następny krok to określenie kluczy obcych (relacji).
Konieczna jest weryfikacja czy wybrane środowisko RDBMS
obsługuje klucze obce, jakie warunki i ograniczenia, itp. Na
tej podstawie można dopiero przygotować odwzorowanie
związków modelu ZE na relacje modelu relacyjnego.

slajd 28

© J.Rumiński

Przykład – normal_forms.html