TRANSFORMACJA DO SCHEMATU RELACYJNEGO - pojęcia podstawowe

Repetytorium - pojęcia podstawowe relacyjnego modelu danych

• Schemat implementacyjny (logiczny) bazy danych: schemat, na którym działają aplikacje.

• Relacja (tablica): dwuwymiarowa tablica będąca implementacją encji. Kolumny tablicy są atrybutami. Wiersze tablicy to krotki - reprezentują wystąpienia encji.

• Atrybut: cecha lub własność encji, kolumna relacji lub pole rekordu.

• Klucz potencjalny: atrybut lub zbiór atrybutów, które mogą w sposób unikalny identyfikować krotki relacji.

• Klucz podstawowy (główny) (identyfikator): atrybut lub zbiór atrybutów wybrany spośród kluczy potencjalnych do identyfikacji krotek relacji.

• Klucz obcy: atrybut lub zbiór atrybutów relacji, który jest kluczem podstawowym w innej relacji. Klucz obcy służy do logicznego powiązania krotek dwóch relacji.

Transformacja do schematu relacyjnego - scenariusz

1. Transformacja encji

• Dla każdej encji, która nie tworzy hierarchii encji, utwórz relację odwzorowując atrybuty encji na nazwy kolumn relacji.

• Utwórz klucz podstawowy relacji na podstawie unikalnego identyfikatora encji

• Hierarchie encji transformuj zgodnie z odpowiednimi regułami.

2. Transformacja związków 1:1

• Dla związków jednostronnie obligatoryjnych, dodaj klucz obcy do relacji powstałej z encji wiązanej obligatoryjnie, na podstawie klucza podstawowego drugiej relacji.

• Dla związków dwustronnie opcjonalnych, dodaj klucz obcy do relacji o przewidywanej mniejszej liczbie krotek.

3. Transformacja związków 1:N

• Dodaj klucz obcy do relacji po stronie N, na podstawie klucza podstawowego relacji po stronie 1.

4. Transformacja związków M:N i ternarnych

• Dla każdego związku utwórz nową relację, zawierającą klucze obce zbudowane na podstawie kluczy podstawowych wiązanych relacji.

Transformacja encji

PRACOWNICY (

id_pracownika PRIMARY KEY,

imię NOT NULL,

nazwisko NOT NULL,

adres_ulica NULL,

adres_miasto NULL )

Zasady transformacji:

• Nazwę encji wyrażoną w liczbie mnogiej przenosimy jako nazwę relacji.

• Atrybuty encji przenosimy jako nazwy kolumn (atrybuty) relacji.

• Unikalny identyfikator encji przenosimy jako klucz podstawowy relacji.

• Obligatoryjność atrybutu encji przenosimy jako ograniczenie NOT NULL atrybutu relacji.

• Opcjonalność atrybutu encji przenosimy jako własność NULL atrybutu relacji.

• Inne ograniczenia integralnościowe nałożone na atrybuty encji przenosimy w niezmienionej formie na atrybuty relacji.

Transformacja związków 1:1

Związek 1:1 jednostronnie obligatoryjny

SPRZEDAŻE (

id_sprzedaży PRIMARY KEY,

data_sprzedaży NOT NULL,

wartość NOT NULL )

ZWROTY (

id_zwrotu PRIMARY KEY,

data_zwrotu NOT NULL,

przyczyna NULL

id_sprzedaży NOT NULL

REFERENCES sprzedaże(id_sprzedaży) )

Zasady transformacji:

• Tworzymy klucz obcy w relacji wiązanej obligatoryjnie na podstawie klucza podstawowego drugiej relacji.

• Na atrybuty klucza obcego nakładamy ograniczenie referencyjne.

Transformacja związków 1:1

Związek 1:1 dwustronnie opcjonalny

Zasady transformacji:

Tworzymy klucz obcy w relacji o mniejszej liczbie krotek, na podstawie klucza podstawowego drugiej relacji.

Na klucz obcy nakładamy ograniczenie referencyjne.

Transformacja związków 1:N

STANOWISKA (

nazwa PRIMARY KEY,

płaca_min NOT NULL,

płaca_max NULL )

PRACOWNICY (

id_pracownika PRIMARY_KEY,

imię NOT NULL,

nazwisko NOT NULL,

stanowisko NOT NULL

REFERENCES stanowiska(nazwa) )

Transformacja związków 1:N - cd.

Zasady transformacji:

• Tworzymy klucz obcy w relacji po stronie "wiele" na podstawie klucza podstawowego relacji po stronie "jeden".

• Na atrybuty klucza obcego nakładamy ograniczenie referencyjne.

• Obligatoryjność związku po stronie "wiele" przenosimy jako ograniczenie NOT NULL atrybutów klucza obcego.

• Opcjonalność związku po stronie "wiele" przenosimy jako własność NULL atrybutów klucza obcego.

• Obligatoryjność i opcjonalność po stronie "jeden" nie jest wyrażona w modelu relacyjnym - ograniczenie implementowane w aplikacji.

Transformacja związków M:N

PRACOWNICY (

id_pracownika PRIMARY_KEY,

imię NOT NULL, nazwisko NOT NULL )

PROJEKTY (

nazwa_proj PRIMARY KEY,

data_rozpocz NOT NULL, data_zakoncz NULL )

UDZIAŁY_W_PROJ (

id_pracownika REFERENCES pracownicy(id_pracownika),

nazwa_proj REFERENCES projekty(nazwa_proj),

PRIMARY KEY(id_pracownika, nazwa_proj) )

Transformacja związków M:N

Zasady transformacji:

• Związek M:N przenosimy jako nową relację.

• Tworzymy klucze obce na podstawie kluczy podstawowych dwóch pozostałych relacji.

• Na atrybuty jednego i drugiego klucza obcego nakładamy dwa ograniczenia referencyjne.

• Wszystkie atrybuty relacji tworzą klucz podstawowy.

Transformacja hierarchii encji - do trzech relacji

Hierarchia encji:

Schematy relacji:

PRACOWNICY (id_prac PRIMARY KEY,

atrybuty_wspólne,

typ_prac NOT NULL )

PRACOWNICY_KRAJ ( id_prac PRIMARY KEY, atr_specyf_kraj )

PRACOWNICY_ZAGR ( id_prac PRIMARY KEY, atr_specyf_zagr )

Transformacja hierarchii encji - do trzech relacji

Zasady transformacji:

• Tworzymy jedną relację zawierającą atrybuty wspólne i atrybut określający typ specjalizacji.

• Dla każdej specjalizacji tworzymy relację zawierającą jej atrybuty specyficzne i klucz podstawowy dziedziczony z generalizacji.

Perspektywy dla specjalizacji:

PRACOWNICY_KRAJOWI

(id_prac, atrybuty_wspólne, atr_specyf_kraj) AS

select id_prac, atrybuty_wspólne, atr_specyf_kraj

from PRACOWNICY p, PRACOWNICY_KRAJ pk

where p.id_prac = pk.id_prac;

PRACOWNICY_ZAGRANICZNI

(id_prac, atrybuty_wspólne, atr_specyf_zagr) AS

select id_prac, atrybuty_wspólne, atr_specyf_zagr

from PRACOWNICY p, PRACOWNICY_ZAGR pz

where p.id_prac = pz.id_prac;

Transformacja hierarchii encji - do dwóch relacji

Hierarchia encji:

Schematy relacji:

PRACOWNICY_KRAJ ( id_prac PRIMARY KEY, atrybuty_wspólne, atr_specyf_kraj )

PRACOWNICY_ZAGR ( id_prac PRIMARY KEY, atrybuty_wspólne, atr_specyf_zagr )

Transformacja hierarchii encji - do dwóch relacji

Zasady transformacji:

• Dla każdej specjalizacji tworzymy relację zawierającą atrybuty wspólne, atrybuty specyficzne danej specjalizacji i klucz podstawowy dziedziczony z generalizacji.

Perspektywa dla generalizacji:

PRACOWNICY

(id_prac, atrybuty_wspólne, typ_prac) AS

select id_prac, atrybuty_wspólne, 'KRAJ'

from PRACOWNICY_KRAJ

union

select id_prac, atrybuty_wspólne, 'ZAGR'

from PRACOWNICY_ZAGR;

Transformacja hierarchii encji - do jednej relacji

Hierarchia encji:

Schematy relacji:

PRACOWNICY (

id_prac PRIMARY KEY,

atrybuty_wspólne,

atr_specyf_kraj NULL,

atr_specyf_zagr NULL,

typ_prac NOT NULL )

Transformacja hierarchii encji - do jednej relacji

Zasady transformacji:

• Tworzymy relację zawierającą atrybuty wspólne, atrybuty specyficzne wszystkich specjalizacji i atrybut określający typ specjalizacji.

• Wszystkim atrybutom specyficznym poszczególnych specjalizacji nadajemy własność NULL.

Perspektywy dla specjalizacji:

PRACOWNICY_KRAJOWI

(id_prac, atrybuty_wspólne, atr_specyf_kraj) AS

select id_prac, atrybuty_wspólne, atr_specyf_kraj

from PRACOWNICY

where typ_prac = 'KRAJ';

PRACOWNICY_ZAGRANICZNI

(id_prac, atrybuty_wspólne, atr_specyf_zagr) AS

select id_prac, atrybuty_wspólne, atr_specyf_zagr

from PRACOWNICY

where typ_prac = 'ZAGR';

Transformacja łuków - związków wykluczających się

Metoda 1: Współdzielony klucz obcy

• gdy importowane klucze mają tą samą dziedzinę wartości

NAPRAWA (

numer_naprawy INTEGER(6) PRIMARY KEY,

... ,

rodzaj_naprawy CHAR(2) NOT NULL

CHECK(rodzaj_naprawy in ('ŚT', 'EW')),

id_elementu INTEGER(8) )

Transformacja łuków - związków wykluczających się

Metoda 2: Jawne klucze obce

• gdy importowane klucze mają różne dziedziny wartości

NAPRAWA (

numer_naprawy INTEGER(6) PRIMARY KEY,

... ,

kod_środka_trw CHAR(5)

REFERENCES środki_trwałe(kod_śr),

id_wyposażenia INTEGER(8)

REFERENCES wyposażenie(id_wyp) )

89

85

_____________________________________________________________________________

Systemy baz danych Transformacja EER - Model relacyjny, Normalizacja Zbyszko Królikowski

95

___________________________________________________

Systemy baz danych Zbyszko Królikowski

---