35341 ullman055 (2)

116 > RELACYJNY MODEL DANYCII

3.1.7. Ćwiczenia do podrozdziału 3.1

Ćwiczenie 3.1.1. Na rysunku 3.4 $a_ przedstawione instancje dwóch relacji, które mogą stanowić część bazy danych banku. Należy określić:

a)    Atrybuty poszczególnych relacji.

b)    Krotki każdej relacji.

c)    Składowe jednej krotki w każdej relacji.

d)    Schemat każdej relacji.

e)    Schemat bazy danych.

0 Właściwą dziedzinę dla każdego atrybutu.

g) Inny* równoważny sposób przedstawienia każdej z relacji.

nr Konta	typ	saldo
12345	oszczędnościowy	12000
23456	rozliczeniowy	1000
34567	oszczędnościowy	25

Relacja Kenta

Imię	Nazwisko	Nr ID	konto
Robbie	Banks	901-222	12345
Lenn	Hand	805-333	12345
Lena	Hanri	805-333	23456

Relacja Klienci RYSUNEK 3.4

Dwie relacjo w bazie danych banku

!! Ćwiczenie 3.1.2. Ile istnieje różnych sposobów (biorąc pod uwagę różną kolejność atrybutów i krotek) reprezentowania instancji relacji, jeśli składa się ona z:

*a) Trzech atrybutów i trzech krotek, podobnie jak relacja Konta z rys. 3.4?

b)    Czterech atrybutów i pięciu krotek?

c)    n atrybutów i m krotek?

3.2. Od proj ektów ODL do proj ektów relacyjnych

Rozważmy proces tworzenia nowej bazy danych, podobnej do naszej bazy danych filmów. Zaczyna się on od fazy' projektowania, kiedy to trzeba określić zakres i rodzaj przechowywanych danych* powiązania między różnymi rodzajami danych, założenia dotyczące więzów zarówno klucza, jak i integralności referencyjnej. Ta faza może rozciągnąć się w czasie, ponieważ ocenia się rozmaite warianty oraz podsumowuje różne opinie.

Po fazie projektowania następuje faza implementacji w rzeczywistym systemie baz danych. Ponieważ znakomita większość komercyjnych systemów baz danych stosuje model relacyjny, więc preferuje się tworzenie projektu również w modelu relacyjnym, a nie w modelu obiektowym, jak ODL czy związków cnej i, które były omówione w rozdziale 2.

Mimo to w praktyce dość często jest łatwiej rozpocząć od postaci opisanych w rozdziale 2, utworzyć projekt w tym modelu, a potem przekształcić go do postaci relacyjnej. Jedna z przyczyn takiego postępowania leży w braku elastyczności modelu relacyjnego, który zawiera tylko jeden rodzaj elementów - relacje i nie operuje innymi wygodnymi pojęciami (np. zbiorami cncji i związków z modelu związków cncji), a jest to znacznie łatwiej obsługiwać już po określeniu struktury projektu.

W bieżącym rozdziale zastanowimy się, w jaki sposób przekształcać modele zapisane w języku ODL do postaci projektów relacyjnych. Z kolei konwersje między modelem związków encji a modelem relacyjnym omówimy w podrozdziale 3.3. Następnie poświęcimy trochę uwagi podklasom w podrozdziale 3.4. Ponieważ ujęcie podklas (związków isa) jest różne w języku ODL i w związkach encji, to również ich przekształcanie do modelu relacyjnego będzie się różniło.

Często do schematu bazy danych dołącza się więzy. Więzy z modelu ODL i modelu związków encji, takie jak klucze i więzy integralności, można także wyrazić w modelu relacyjnym. Ważna kategoria więzów, nazywana zależnościami funkcyjnymi, w modelu relacyjnym będzie przedstawiona w podrozdziale 3.5. Omówienie innych rodzajów więzów modelu relacyjnego rozpocznie się od podrozdziału 4.5.

3.2.1. Od atrybutów w języku ODL do atrybutów relacji

Na początek załóżmy, że każda klasa będzie miała swój odpowiednik w postaci jednej relacji, a w tej relacji dla każdej właściwości będzie określony jeden atrybut. Zobaczymy później wiele sposobów modyfikacji tych założeń, lecz na chwilę przyjmijmy najprostszy przypadek, kiedy możemy bezpośrednio przekształcić klasy na relacje, a właściwości na atrybuty. A oto nasze założenia:

1.    Wszystkie właściwości klas zapisuje się jako atrybuty (nie ma ani związków, ani metod).

2.    Typy atrybutów są tylko atomowe (nic ma ani struktur, ani zbiorów). PRZYKŁAD 3.2

Na rysunku 3.2 został pokazany przykład klasy, odpowiadający przyjętym założeniom. Występują tam cztery atrybuty i nie określono żadnych innych