202 3. RELACYJNY MODEL DANYCH
jest numerem identyfikacyjnym w jakimś zewnętrznym rejestrze albo jest nadawany przez „związek”.
• Do identyfikacji dyrektorów można używać numerów certyfikatów, ale gwiazdy filmowe nie zawsze maja certyfikaty i dlatego w dalszym ciągu kluczem dla gwiazd jest ich nazwisko. Być może to założenie nie sprawdziłoby się w praktyce, bo w rzeczywistości dwie gwiazdy filmowe mogą się nazywać tak samo, ale zdecydujemy tak po to, aby przedstawić różne sytuacje.
• Producent stanowi nową właściwość filmów. Określa ją now\' atrybut relacji film o nazwie producentem. Wartością tego atrybutu ma być numer certyfikatu producenta danego filmu. Producenci należą przypuszczalnie również do dyrektorów produkcji filmów', podobnie jak prezesi studia. Mogą również wystąpić inni zarządzający w relacji FilmDyr.
• Zmianie uległ atrybut typFilmu z relacji Film, poprzednio miał on typ wyliczeniowy, a obecnie jest to atrybut typu logicznego o nazwie czyKolor i przyjmuje on wartość prawda, jeśli film jest kolorowy, a fałsz, gdy jest on czarno-biały. Zmiana ta zaszła w wyniku tego, że nic wszystkie bazy danych obsługują typ wyliczeniowy.
• Do relacji zapisu gwiazd filmowych dołączono atrybut płeć gwiazdy. Jest on typu znakowego i przyjmuje wartość M dla mężczyzn oraz K dla kobiet. Dołączono także atrybut dataurodzenia, który' ma typ data (jest to specjalny typ, który' występuje prawie we wszystkich komercyjnych systemach baz danych, ale można tu także zastosować typ znakowy).
• Wszystkie adresy są napisami, a nie parą złożoną z ulicy oraz miasta. W ten sposób ułatwia się porównanie adresów z różnych relacji oraz wykonywanie operacji na adresach.
Na koniec spróbujemy wyciągnąć wnioski na temat tych pięciu relacji, ich atrybutów' oraz ich powiązań z wcześniejszym schematami w ODI. lub diagramach związków encji. 1 2
—* adres jest również zależnością funkcyjną. A zatem trzeba było przeprowadzić dekompozycję, w wyniku której powstały schematy: (nazwisko, adres} (który rozszerzono do relacji GwiazaaFilmo-wa)oraz {nazwisko, tytuł, rok} (który jest dokładnie schematem naszej relacji GwiazdyW). Ta relacja GwiazdyW jest także dokładnym odpowiednikiem związku Gwiazdy-w z diagramu związków encji, przedstawionego na rys. 2.8.
♦ Model relacyjny: Relacje są tabelami reprezentującymi dane. W nagłówkach kolumn znajduje się opis atrybutów', dla każdego atrybutu określa się jego dziedzinę lub typ danych. Wiersze w tabelach nazywa się krotkami, z kolei w krotkach występują składowe odpowiadające wartościom atrybutów relacji.
♦ Schematy: Nazwa relacji oraz jej atrybuty stanowią schemat relacji. Zbiór schematów relacji nazywa się schematem bazy danych. Konkretne dane występujące w' schemacie nazywa się instancją tego schematu relacji lub bazy danych.
♦ Przekształcanie zbiorów encji do postaci relacji: Relacja odpowiadając* zbiorowi encji ma po jednym atrybucie dla każdego atrybutu ze zbion encji. W wyjątkowy sposób traktuje się tylko słaby zbiór encji E, po nieważ odpowiadająca mu relacja musi zawierać wszystkie atrybuty klucza tych zbiorów' encji, które pomagają w identyfikacji encji w E.
♦ Przekształcalne związków do postaci relacji: Relacja, wyznaczona do re prezentowania w schemacie związku z diagramu związków encji. zawie ra klucze wszystkich zbiorów encji, które uczestniczą w tym związku.
♦ Przekształcanie klas z jązyka ODL do postaci relacji: Dla każdego atrybutu klasy C w języku ODL w odpowiadającej relacji pow staje je den atrybut. Mogą tam także pojawić się atrybuty' klucza innej klas D, powiązanej z C pewnym związkiem. Ze względu na to, że związ^ w języku ODL mają wyznaczone odwrotności, zaleca się przechowy wanie związków typu wicie do jeden z C do D w relacji C, a nie D.
♦ Przekształcanie związków typu wiele do wiele do postaci relacji: Ni ma znaczenia, w której relacji zapisze się związek wiele do wieli trzeba się jednak liczyć z tym, że nastąpi lawinowe zwiększenie liczb krotek w relacji. Ta wada projektu relacyjnego jest usuwana w proci sie normalizacji. Można również związek wiele do wiele z modę1 ODL przedstawiać jako osobną relację, podobnie jak to występu w' przypadku modelu związków encji.
♦ Przekształcanie podklas do postaci relacji: Jeden ze sposobów polej na podziale encji lub obiektów między różne podklasy, a następnie i
Relacja Film powstaje w wyniku dekompozycji relacji Film z przykładu 3.36, do której dołączono atrybut producentC# identyfikujący numer certyfikatu producenta filmu.
Jako druga z dekompozycji w przykładzie 3.36 powstała relacja GwiazdyW. Przy tworzeniu relacji Gwiazda, na podstawie opisu klasy Gwiazda w ODL, również jest potrzebna taka sama relacja, którą potem przekształcamy do postaci BCNF. Przypomnijmy: zaczynając od definicji klasy w ODL, przedstawionej na rys. 2.5, otrzymujemy relację Gwiazda z atrybutami nazwisko, adres, tytuł oraz rok. Dwa ostatnie atrybuty reprezentują zapis związku Występuj ew. Okazało się, że zbiór (nazwisko, tytuł, rok} jest kluczem, ale nazwisko