66852 ullman041 (2)
88 2. MODELOWANIE BAZ DANYCH
gramowaniu konwencjonalnym swój odpowiednik w postaci zakazu istnienia wskaźnika wiszącego.
4. Więzy domenowe (domain constraints) stanowią wymaganie, aby wartość atrybutu należała do określonego zbioru wartości specyficznych lub znajdowała się w określonym zakresie. W podrozdziale 6.3 opiszemy ograniczenia domenowe w języku $QL.
5. Więzy zasadnicze {generał constraints) są arbitralnie narzuconymi warunkami, których spełnienie musi być bezwzględnie przestrzegane wr definiowanej bazie danych. Na przykład można by zażądać, aby dany film był związany nie więcej niż z dziesięcioma gwiazdami. W podrozdziałach 4.5 i 4.6 przedstawimy język wyrażeń dedykowany więzom zasadniczym.
Więzy są ważne z kilku powodów. Po pierwsze określają one ważne właściwości struktuiy tych fragmentów świata rzeczywistego, które są modelowane. Na przykład klucze umożliwiają uniknąć kłopotów przy identyfikowaniu poszczególnych obiektów lub encji. Jeśli na przykład wiadomo, że atrybut nazwa jest kluczem obiektów klasy Stiudio. to odwołując się do studia poprzez jego nazwę, wiemy, że mamy do czynienia z pojedynczym obiektem. Poza tym, jeśli wiadomo, że dana wartość występuje jednokrotnie, to można zaoszczędzić zarówno czas, jak i przestrzeń, ponieważ przechowywanie pojedynczych wartości jest prostsze niż przechowywanie ich zbioru, nawet jeśli jest to zbiór jedno-elcmcntowy1. Integralność referencyjna i klucze pozwalają także na stosowanie takich struktur, które przyspieszają dostęp do poszczególnych obiektów.
2.5.1. Klucze
Kluczem klasy w języku ODL nazywamy zbiór K atrybutów taki. że dla danych dwóch różnych obiektów 0\ i O2, które należą do tej samej klasy, 0\ i 02 nie mogą mieć takich samych wartości wszystkich atrybutów ze zbioru K. W modelu E/R klucz definiuje się analogicznie, zastępując słowo „klasa" słowem „zbiór encji", a słowo „obiekt” przez „encja”.
PRZYKŁAD 2.23
Rozważmy klasę Film z przykładu 2.1. Na pierwszy rzut oka można by pomyśleć, że atrybut określający tytuł filmu jest dobrym kluczem. Jednakże są takie tytuły, które nadano wielokrotnie różnym filmom, na przykład King Kong. Nic byłoby zatem zbyt roztropnie, jeżeli sam tytuł stanowiłby klucz w klasie Film. Gdybyśmy bowiem tak zrobili, to nie można by było w naszej bazie przechowywać danych o dwóch różnych filmach King Kong.
Lepiej jest utworzyć klucz ze zbioru dwóch atrybutów: tytuł i rok. Nadal występuje ryzyko, ze nakręcono w jednym roku dwa filmy o tym samym tytule (i wówczas tylko jeden z nich da się wprowadzić do naszej bazy danych), ale taka sytuacja jest bardzo mało prawdopodobna.
Jeśli chodzi o pozostałe dwie klasy z podrozdziału 2.1 Gwiazdę i Studio, to także trzeba uważnie przemyśleć, eo może posłużyć jako klucz. W przypadku studia może to być jego nazwa, bo rozsądnie myśląc, można wykluczyć taką sytuację, że istnieją dwa studia filmowe o takiej samej nazwie. Tak też zrobimy - określimy atrybut nazwa jako klucz klasy Studio. Jednak w przypadku gwiazd ekranu nic jest już oczywiste, że mogą być jednoznacznie identyfikowane za pomocą nazwiska. Z pewnością nazwiska wcale nic są cechą identy fikującą ludzi. Jednak gwiazdy przyjmują przecież sceniczne pseudonimy, więc można mieć nadzieję, że atrybut nazwisko będzie dla klasy Gwiazda dobrymi kluczem. Jeśli nie, to możemy utworzyć klucz z pary atrybutów nazwisko i adres, chyba że dwie gwiazdy filmowe o takich samych nazwiskach mieszkają pod tym samym adresem.
□
Więzy są częścią schematu bazy danych
Może się zdarzyć, że obserwacja danych przez pewien okres doprowadzi do określenia pewnych atrybutów jako kluczy, ponieważ żadne dwie wartości tych atrybutów nie powtarzały się. W naszym filmowym przykładzie przez pewien czas mogą występować wyłącznie filmy o różnych tytułach. To mogłoby sugerować, że tytuł jest dobry m kluczem w klasie Fi ln. Jeśli jednak na podstawie tych obserwacji zdecydowalibyśmy przyjąć, że atrybut tytuł będzie kluczem, to w przypadku wyprodukowania nowego filmu o nazwie King Kong jego danych nie dałoby się umieścić w naszej bazie.
Dlatego klucz, a w zasadzie wszystkie więzy, muszą stanowić część schematu bazy danych. Są one określane przez projektanta bazy równolegle z jej strukturą (tzn. encjami i związkami). Po określeniu więzów wszystkie tc operacje wstawiania i modyfikacji danych, które nie spełniają warunków narzuconych w więzach, są niedopuszczalne.
A zatem, nawet jeśli jakiś stan bazy danych wskazuje istnienie pewnych więzów, to tc „prawdziwe”, spełnione dla wszystkich potencjalnych wartości danych, określa projektant podczas analizy świata rzeczywistego. Tkwią one w strukturze bazy i użytkownik nie musi znać wartości danych w bazie, aby wiedzieć, że muszą one być spełnione.
PRZYKŁAD 2.24
Doświadczenie uzyskane w trakcie wykonywania ćwiczenia 2.23 mogłoby nasunąć wnioski, że znalezienie klucza lub uzyskanie pewności, żc zbiór atrybutów może być kluczem stanowi problem. W praktyce jednak okazuje się to być zupełnie łatwe. W sytuacjach rzeczywistych, kiedy zazwyczaj modeluje
Wiadomo, zc chociażby na przykład w języku C jest dużo łatwiej reprezentować wartość całkowitą niż. listę takich wartości, nawet jeśli na danej liście występuje tylko jeden element.
Wyszukiwarka
Podobne podstrony:
42593 ullman031 (2) 68 2. MODELOWANIE BAZ DANYCH RYSUNEK 2.12 /.wiązek czteroargumentowy może być zw
46418 ullman030 (2) 66 2. MODELOWANIE BAZ DANYCH rysunek 2.10 Związek trzyargumentowy mcncie z pozos
47796 ullman034 (2) 74 2. MODELOWANIE BAZ DANYCH2.3.1. Dokładność Przede wszystkim projekt powinien
82892 ullman040 (2) 86 2 MODELOWANIE BAZ DANYCH mie z rys. 2.23. A nasza przykładowa cncja Królik Ro
więcej podobnych podstron