ullman038 (2)

ullman038 (2)



2. MODELOWANIE BAZ DANYCH

itórych każda dziedziczy właściwości wszystkich swoich poprzedników, siadanie wielu nadklas jest także dla każdej klasy możliwe. Poniższy przy-id obrazuje zarówno potęgę, jak i kłopoty wynikające zc zdefiniowania elu nadklas.

ZYKł.AD 2.19

ifiniujemy inną podklasę klasy Film, która ma opisać specyfikę filmowych gadek kryminalnych:

1)    Interface Kryminały: Film {

2)    attribute string broń;

};

'ynika z tego, że kryminały mają atrybut określający narzędzie zbrodni, także cztery' atrybuty i dwa związki zdefiniowane dla wszystkich filmów.

Zastanówmy się teraz nad atrybutami filmu ,,Kto zabił królika Rogera?”, óry jest zarówno kreskówką, jak i kryminałem, l ego typu obiekt powinien ,ieć określoną wartość atrybutu broń, a także wartości związku głosy oraz szystkie standardowe cechy filmów. Taką sytuację możemy zapisać dekla-ljąc nowa podklasę Kreskówka-Kryminał, która będzie podklasą i Kre-kówek i Kryminałów. Deklaracja przyjmie następującą postać:

interface Kreskówka-Kryminał: Kreskówka, Kryminał {};

Obiekt, mający zarówno cechy kryminałów, jak i kreskówek będzie /ówczas dziedziczył je z obu podklas Kreskówka i Kryminał. Obiekty aszej nowej podklasy Kreskówka-Kryminał nie mają żadnych własnych pecyficznych właściwości. Atrybut broń dziedziczą z klasy Kryminał, związek głosy z klasy Kreskówka. A ponadto ponieważ obie klasy, Kre-kówka i Kryminał, dziedziczą cztery atrybuty i dwa związki klasy Film, vięc klasa Kreskówka-Kryminał dziedziczy także tych sześć cech. Oczywiście klasa Kreskówka-Kryminał nie będzie mieć dwóch kopii tych sześciu vłaściwości, dziedziczy je bowiem z klasy Film tylko za pośrednictwem jednej :e swoich bezpośrednich nadklas. Na rysunku 2.22 zilustrowano zależności ladklasa-podklasa między- omówionymi czterema klasami.

Zasadniczo można określić pewną klasę Cjako podklasę dowolnej liczby das, wymieniając ich nazwy po dwukropku kończącym deklarację nazwy klasy T. Przykład 2.19 z deklaracją Kreskówka-Kryminał dobrze obrazuje taką 'ormułę. Jednak taki przypadek, gdy klasa C dziedziczy różne cechy z różnych tadklas, jest potencjalnym źródłem konfliktów wynikających z podobieństwa nazw. Może się bowiem zdarzyć, że w dwóch (lub więcej) nadklasach występują atrybuty lub związki o tej samej nazwie, ale różniące się typami.

2.4. PODKLASY

RYSUNEK 2.22

Diagram dziedziczenia wielokrotnego


PRZYKŁAD 2.20

Załóżmy, że w klasie Film zdefiniowano podklasy Romans i Sąd. Ponadto załóżmy, że w każdej z tych klas występuje atrybut o nazwie koniec. W klasie Romans wartość tego atrybutu pochodzi ze zbioru {szczęśliwy, smutny}, a w klasie Sąd ze zbioru {winny, niewinny}. Jeśli potem zdefiniujemy podklasę obu klas: Romans i Sad o nazwie Romans-Sad, to nie będzie jasne, jakiego typu mają być wartości dziedziczonego przez nią atrybutu koniec.

Syntaktyka (składnia) języka ODL nie obejmuje takich przypadków, jednak implementacje muszą zapewniać dostęp do co najmniej jednego z opisanych poniżej mechanizmów po to, by użytkownik mógł rozstrzygać, jak obsłużyć sytuacje konfliktowe w przypadku dziedziczenia wielokrotnego.

1.    Wskazanie, która z definicji przysługuje podklasie. W przykładzie 2.20 prawdopodobnie bylibyśmy bardziej zainteresowani czy romans sądowy kończy się dobrze, czy smutno, niż czy wydano wyrok skazujący, czy uniewinniający. W takim razie trzeba by móc wyspecyfikować, że klasa Romans-Sad dziedziczy atrybut koniec z nadklasy Romans, a nie z nadklasy Sad.

2.    Zdefiniowanie w klasie C nowej nazwy dla atrybutu, który nic jest dziedziczony. W naszym przykładzie 2.20, gdzie atrybut koniec dziedziczy się z nadklasy Romans, trzeba wówczas w klasie Romans-Sad mieć dodatkowy atrybut o nazwie wyrok, która jest synonimem nazwy atrybutu koniec z nadklasy Sąd.

3.    Przedefilowanie w klasie C pewnych atrybutów dziedziczonych z nadklas. W naszym przykładzie 2.20 moglibyśmy na przykład zdecydować, że atrybut koniec nie będzie dziedziczony z żadnej nadklasy. Bowiem w przypadku romansu sądowego atrybut koniec będzie miał wartość całkowitą zależną od oceny wydanej przez publiczność sposobowi zakończenia filmu.


Wyszukiwarka

Podobne podstrony:
ullman020 (2) Modelowanie baz danych Proces projektowania baz danych rozpoczyna się od analizy danyc
ullman033 (2) 2 2. MODELOWANIE BAZ DANYCH IZYKLAD 2.13 ałóżmy, że zdefiniowano klasy: Gwiazda, Film
81317 ullman043 (2) 2. MODELOWANIE BAZ DANYCH się przez podkreślanie ich nazw. Na rysunku 2.24 przed
ullman033 (2) 2 2. MODELOWANIE BAZ DANYCH IZYKLAD 2.13 ałóżmy, że zdefiniowano klasy: Gwiazda, Film
67184 ullman020 (2) Modelowanie baz danych Proces projektowania baz danych rozpoczyna się od analizy
ullman035 (2) 76 2. MODELOWANIE BAZ DANYCH2.3.4. Dobór właściwych elementów Czasami sytuacja pozwala
84009 ullman037 (2) su 2. MODELOWANIIi BAZ DANYCH b)    Każda kombinacja dziecko, lek
66852 ullman041 (2) 88 2. MODELOWANIE BAZ DANYCH gramowaniu konwencjonalnym swój odpowiednik w posta
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

więcej podobnych podstron