background image

 

 

 slajd 1

©  J.Rumiński

Jacek Rumiński

Bazy danych 

Kontakt: 

Katedra Inżynierii Biomedycznej, pk. 

106,

tel.: 3472678, fax: 3461757, 
e-mail: jwr@eti.pg.gda.pl

background image

 

 

 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.

background image

 

 

 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

background image

 

 

 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.

background image

 

 

 slajd 5

©  J.Rumiński

background image

 

 

 slajd 6

©  J.Rumiński

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

background image

 

 

 slajd 7

©  J.Rumiński

background image

 

 

 slajd 8

©  J.Rumiński

Związki –wiele do wielu

background image

 

 

 slajd 9

©  J.Rumiński

Hierarchia

background image

 

 

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

background image

 

 

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

background image

 

 

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

background image

 

 

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

background image

 

 

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

background image

 

 

 slajd 15

©  J.Rumiński

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

background image

 

 

 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.

background image

 

 

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

background image

 

 

 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)

background image

 

 

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

background image

 

 

 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 jest przechodnio funkcyjnie zależny od 
zbioru atrybutów w schemacie relacji R, jeżeli X i istnieje 

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

→Y.

background image

 

 

 slajd 21

©  J.Rumiński

Reguły pragmatyczne (upraszczające model).

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

background image

 

 

 slajd 22

©  J.Rumiński

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

background image

 

 

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

background image

 

 

 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.

background image

 

 

 slajd 25

©  J.Rumiński

Odwzorowanie diagramu ZE na model relacyjny

Klucze kandydujące,

Klucze główne,

Tabele,

Klucze obce,

Typy danych

Relacje

background image

 

 

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

background image

 

 

 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.

background image

 

 

 slajd 28

©  J.Rumiński

Przykład – normal_forms.html


Document Outline