40421 ullman052 (2)

3_

Relacyjny model danych

Mimo że omawiane w rozdziale drugim podejście do projektowania baz danych, oparte na związkach encji i zorientowane obiektowo, są użyteczne i właściwe do opisu struktur danych, to obecnie implementacje bazy danych prawie zawsze opierają się na innym sposobie podejścia, nazywanym modelem relacyjnym. Ten relacyjny model jest najbardziej użyteczny, co wynika z faktu, że bazuje on na jednym pojęciu modelowania danych: na relacji, czyli dwuwymiarowej tabeli, do której wpisuje się dane. W rozdziale 5 przekonamy się, że właśnie model relacyjny jest odpowiedni do współdziałania z języ kiem zapytań bardzo wysokiego poziomu SQL (siruciured ąuery language - strukturalny język zapytań). W języku SQL można zapisywać proste programy, które generują złożone wyniki, operując na danych zapamiętanych w postaci relacji.

Często jednak jest łatw iej zaprojektow ać bazę danych w jednym z modeli opisanych w rozdziale 2. Dlatego naszym podstawowym celem jest poznanie sposobu przekształcenia projektu zapisanego w jednej z tamtych notacji do postaci modelu relacyjnego. Potem okaże się, że model relacyjny obejmuje również, właściwą sobie teorię projektowania. Teoria ta bywa często nazywana normalizacją relacji i operuje pojęciem „zależności funkcyjnych”, które z kolei rozszerza pojęcie klucza; klucze w sposób nieformalny już opisano w p. 2.5.1. Korzystając z teorii normalizacji, często udaje się poprawić relacje opisujące pewien projekt bazy danych.

3.1. Podstawy modeli relacyjnych

Model relacyjny dostarcza tylko jednego sposobu reprezentowania danych: jest nim dwuwymiarowa tabela, nazywana relacją. Przykład relacji przedstawiono na rys. 3.1. Nazwą relacji jest Film i zamierzamy w niej przechowywać takie same dane, jak w prostej klasie modelu GDI. o nazwie - iim, która była zdefiniowana w przykładzie 2.1 na rys. 2.4 oraz powtórzona

na rys. 3.2. Warto przypomnieć sobie, że nie była to ostateczna wersja definicji klasy Film i obejmowała tylko atrybuty' tytuł, rok, długość i typFilmu.

tytuł	rok	długość	typFilmu
Gwiezdne Wojny	1977	124	kolor
Potężne Kaczory	1991	104	kolor
Świat Wayne'a	1992	95	kolor

RYSUNEK 3.1 Relacja Film

1)    interface Fiim{

2)    attribute    strir.g tytuł;

3)    attribute    integer rok;

•1)    attribute    integer dłuqość;

5}    attribute    enumeration (kolor, czarno-biały)

typFilmu;

1 ;

RYSUNEK 3.2

Opis klasy Fi ln w języku ODL

3.1.1. Atrybuty

W nagłówku relacji są podane atrybuty. Na rysunku 3.1 atrybutami są: tytuł, rok, długość i typFilmu. Atrybuty relacji służą do nazywania kolumn relacji. Na ogół atrybuty oddają znaczenie danych umieszczanych w kolumnach pod nimi. Na przykład w kolumnie z atrybutem długość umieszcza się czas trwania (czyli długość) poszczególnych filmów.

Zauważmy, że atrybuty relacji Film z rys. 3.1 odpowiadają elementom struktury danych definicji ODL z rys. 2.4, nazywanym tam również atrybutami. Taki sposób dobierania atrybutów relacji jest dość powszechny. Jednak to, żc atrybuty relacji mają jakieś odpowiedniki w składnikach modelu encji lub obiektowym modelu opisu danych, nie musi być obowiązująca regułą.

3.1.2. Schematy

Nazwa relacji oraz jej zbiór atrybutów nazywają się schematem relacji. Schemat relacji zapisujemy za pomocą jej nazwy, po której występuje lista atrybutów' ujęta w nawiasy okrągłe. Schemat relacji Film z rys. 3.1 jest następujący:

Film(tytuł, rok, długość, typFilmu)