1. Mapowanie diagramu klas na model relacyjny.

Podobne dokumenty
Projektowanie baz danych

Projektowanie baz danych

Technologie baz danych

Bazy danych - wykład wstępny

030 PROJEKTOWANIE BAZ DANYCH. Prof. dr hab. Marek Wisła

Transformacja modelu ER do modelu relacyjnego

Wprowadzenie do baz danych

Rysunek 1: Przykłady graficznej prezentacji klas.

Instytut Mechaniki i Inżynierii Obliczeniowej fb.com/groups/bazydanychmt/

Bazy danych 1. Wykład 5 Metodologia projektowania baz danych. (projektowanie logiczne)

PLAN WYKŁADU BAZY DANYCH GŁÓWNE ETAPY PROJEKTOWANIA BAZY MODELOWANIE LOGICZNE

Model relacyjny bazy danych

Baza danych. Baza danych to:

MSI dr. Inż. Mariusz Trzaska. obiektowych językach programowania

Projektowanie aplikacji z bazami danych

Bazy danych. Plan wykładu. Diagramy ER. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych

Laboratorium Technologii Informacyjnych. Projektowanie Baz Danych

Baza danych. Modele danych

77. Modelowanie bazy danych rodzaje połączeń relacyjnych, pojęcie klucza obcego.

TRANSFORMACJA MODELU ER DO MODELU RELACYJNEGO

Transformacja modelu EER do postaci relacyjnego modelu danych. Zbyszko Królikowski

Bazy danych. Andrzej Grzybowski. Instytut Fizyki, Uniwersytet Śląski

MAS dr. Inż. Mariusz Trzaska

SIECI KOMPUTEROWE I BAZY DANYCH

Modelowanie konceptualne model EER

Podstawowe pojęcia dotyczące relacyjnych baz danych. mgr inż. Krzysztof Szałajko

Dane wejściowe. Oracle Designer Generowanie bazy danych. Wynik. Przebieg procesu

Podstawowe pakiety komputerowe wykorzystywane w zarządzaniu przedsiębiorstwem. dr Jakub Boratyński. pok. A38

Utwórz klucz podstawowy relacji na podstawie unikalnego identyfikatora encji. podstawie kluczy podstawowych wiązanych relacji.

Informacje wstępne Autor Zofia Kruczkiewicz Wzorce oprogramowania 4

Bazy Danych i Systemy informacyjne Wykład 7. Piotr Syga

Bazy danych wykład trzeci. trzeci Modelowanie schematu bazy danych 1 / 40

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych

Plan wykładu: Relacyjny model danych: opis modelu, podstawowe pojęcia, ograniczenia, więzy.

Technologia informacyjna

Bazy danych wykład trzeci. trzeci Przekształcenie modelu ER na model relacyjny 1 / 19

Krzysztof Kadowski. PL-E3579, PL-EA0312,

Programowanie obiektowe - 1.

Diagramy związków encji. Laboratorium. Akademia Morska w Gdyni

Programowanie obiektowe

Agnieszka Ptaszek Michał Chojecki

Księgarnia PWN: Michael J. Hernandez Bazy danych dla zwykłych śmiertelników

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

Bazy danych 2. Wykład 2 czyli Kilka słów o tworzeniu aplikacji bazodanowej

Definicja bazy danych TECHNOLOGIE BAZ DANYCH. System zarządzania bazą danych (SZBD) Oczekiwania wobec SZBD. Oczekiwania wobec SZBD c.d.

Wdrożenie do projektu

Transformacja modelu ER do modelu relacyjnego

Projektowanie bazy danych przykład

MAS dr. Inż. Mariusz Trzaska

WPROWADZENIE DO BAZ DANYCH

Normalizacja Projektowanie Diagramy encji. Bazy Danych i Systemy informacyjne Wykład 7. Piotr Syga

ZAGADNIENIA DO EGZAMINU DYPLOMOWEGO NA STUDIACH INŻYNIERSKICH. Matematyka dyskretna, algorytmy i struktury danych, sztuczna inteligencja

Bazy danych. Zenon Gniazdowski WWSI, ITE Andrzej Ptasznik WWSI

Dariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki

Projektowanie relacyjnych baz danych model związków encji (Entity-Relationship, ER)

OPRACOWANIE: SŁAWOMIR APANOWICZ

Bazy danych TERMINOLOGIA

SIECI KOMPUTEROWE I BAZY DANYCH

Wprowadzenie do systemów informacyjnych

Systemy baz danych. mgr inż. Sylwia Glińska

Wykład 2. Relacyjny model danych

Zasady transformacji modelu DOZ do projektu tabel bazy danych

Program wykładu. zastosowanie w aplikacjach i PL/SQL;

PRZYKŁAD. Prosta uczelnia. Autor: Jan Kowalski nr indeksu: (przykładowy projekt)

UML. zastosowanie i projektowanie w języku UML

SIECI KOMPUTEROWE I BAZY DANYCH

BAZY DANYCH LABORATORIUM. Studia niestacjonarne I stopnia

Bazy Danych. Model Relacyjny. Krzysztof Regulski WIMiIP, KISiM, B5, pok. 408

Tworzenie projektu bazy danych z kreatorem odnośników - Filmoteka. Projekt tabel dla bazy Filmoteka

Definicja obiektowego modelu danych: struktura i zachowanie

Jarosław Kuchta Projektowanie Aplikacji Internetowych. Projektowanie warstwy danych

Inżynieria oprogramowania. Część 5: UML Diagramy klas

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD

Microsoft Access materiały pomocnicze do ćwiczeń cz. 1

Teoretyczne podstawy informatyki

Teoretyczne podstawy informatyki

Zachodniopomorski Uniwersytet Technologiczny w Szczecinie. Bazy danych. Wykład 4: Model SERM. dr inż. Magdalena Krakowiak

MAS dr. Inż. Mariusz Trzaska. Realizacja różnych modeli dziedziczenia w obiektowych językach programowania

Bazy danych. Plan wykładu. Proces modelowania i implementacji bazy danych. Elementy ERD. Wykład 2: Diagramy zwizków encji (ERD)

Projektowanie internetowej bazy danych część 1

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Bazy danych. Plan wykładu. Proces modelowania i implementacji bazy danych. Elementy ERD. Wykład 2: Diagramy zwizków encji (ERD)

Projektowanie systemów informacyjnych

Budowa aplikacji ASP.NET współpracującej z bazą dany do przeprowadzania ankiet internetowych

Projektowanie struktury danych


Bazy Danych egzamin poprawkowy, 2012 rozwiazania

Paweł Kurzawa, Delfina Kongo

Diagramy klas. dr Jarosław Skaruz

Plan. Formularz i jego typy. Tworzenie formularza. Co to jest formularz? Typy formularzy Tworzenie prostego formularza Budowa prostego formularza

Projektowanie bazy danych. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Zajęcia 1. W następnej tabeli zebrane są dane używane w bibliotece, które są przetwarzane przez bibliotekarza w różnych fazach obsługi czytelnika.

Integralność danych Wersje języka SQL Klauzula SELECT i JOIN

Paweł Rajba

Modelowanie zarządzania danymi w bazach danych

Bazy danych 1. Wykład 4 Metodologia projektowania baz danych

Instytut Mechaniki i Inżynierii Obliczeniowej Wydział Mechaniczny technologiczny Politechnika Śląska

Relacyjny model baz danych, model związków encji, normalizacje

Bazy danych Wykład zerowy. P. F. Góra

Projektowanie obiektowe oprogramowania Wykład 9 Wzorce architektury aplikacji (1) Wiktor Zychla 2013

Transkrypt:

Rafał Drozd 1. Mapowanie diagramu klas na model relacyjny. 1.1 Asocjacje Wpływ na sposób przedstawienia asocjacji w podejściu relacyjnym ma przede wszystkim jej liczność (jeden-do-jednego, jeden-do-wielu, wiele-do-wiele). W przypadku asocjacji o liczności jeden-dojednego można wykorzystać jedną tabelę, grupując w niej wszystkie atrybuty. Na przykład, na Rys. 1 wszystkie atrybuty klas Państwo i Stolica umieszczono w tabeli Państwo. Rys. 1. Implementacja asocjacji o liczności jeden-do-jednego Dla asocjacji o liczności jeden-do-wielu zazwyczaj tworzy się dwie tabele (odpowiadające dwóm klasom) połączone kluczem obcym, który umieszczany jest w tej z tabel, z punktu widzenia której asocjacja ma liczność jeden. Dla przykładu z Rys. 2, do tabeli odpowiadającej klasie Pracownik wprowadzany jest klucz obcy idfirmy. Rys. 2. Implementacja asocjacji o liczności jeden-do-wielu Jeżeli asocjacja jeden-do-wielu posiada atrybuty, wówczas możliwe są dwa rozwiązania: (1) umieszczenie atrybutów asocjacji w tabeli odpowiadającej klasie, przy której liczność asocjacji wynosi wiele; (2) zastosowanie metody opisanej poniżej, która zasadniczo przeznaczona jest dla asocjacji o liczności wiele-do-wielu. W przypadku asocjacji wiele-do-wielu konieczne jest wprowadzenie dodatkowej tabeli, tzw. tabeli pośredniczącej, która zawiera klucze obce prowadzące do dwóch pozostałych tabel. Dla przykładu z Rys. 3 należy utworzyć tabelę pośredniczącą (nazwaną tutaj PracFirma), której

atrybutyidprac i idfirmy są kluczami obcymi (zwróćmy uwagę, że razem tworzą klucz główny tej tabeli). Rys. 3. Implementacja asocjacji o liczności wiele-do-wielu 1.2 Atrybuty powtarzalne Jednym z ograniczeń podejścia relacyjnego jest to, że tabele relacyjne nie mogą przechowywać wielokrotnych wartości atrybutów. Zazwyczaj tego rodzaju atrybuty należy odwzorować jako odrębne tabele. W takiej sytuacji mogą pojawić się nowe atrybuty. Poniżej przedstawiamy dwa przykłady. W pierwszym z przykładów (Rys. 4) zakładamy, że wartości atrybutu powtarzalnego zawód klasy Pracownik są różne. Aby ten atrybut zaimplementować w podejściu relacyjnym, należy utworzyć nową tabelę (tutaj o nazwie Wyszkolenie), której krotki będą przechowywać jego pojedyncze wartości. W celu powiązania pracownika z jego zawodami (czyli w celu implementacji klucza obcego) wprowadzamy do każdej z tabel atrybut idprac. Zwróćmy uwagę, że ponieważ pracownik może posiadać wiele zawodów, klucz główny w tabeli Wyszkolenie składa się zarówno z atrybutu idprac jak i zawód. Rys. 4. Przykład atrybutu powtarzalnego, którego wartości są różne Przykład przedstawiony na Rys. 5 różni się od przykładu z Rys. 4 tym, że wartości atrybutu powtarzalnego (tutaj o nazwie wypłata) mogą nie być różne, przy czym ważny jest ich porządek. Rozwiązanie jest podobne do poprzedniego z tą różnicą, że wprowadzony został dodatkowy atrybutnrwypłaty, który umożliwia numerowanie kolejnych wypłat danego pracownika (atrybut ten wchodzi w skład klucza głównego tabeli Zarobek).

Rys. 5. Przykład atrybutu powtarzalnego, którego wartości mogą nie być różne 1.3 Odwzorowanie metod/operacji Model relacyjny nie oferuje specjalnych środków przeznaczonych dla metod, dlatego najczęściej są one odwzorowywane na poziomie programów aplikacyjnych jako procedury. Procedury te są napisane w proceduralnych lub obiektowych językach programowania i dedykowane są do obsługi pewnej tabeli (tabel) w relacyjnej bazie danych. Niektóre systemy relacyjne umożliwiają odwzorowywanie metod w postaci procedur baz danych (w SQL) lub w postaci aktywnych reguł. Odwzorowanie polimorfizmu, przesłaniania, dynamicznego wiązania i hermetyzacji jest w zasadzie niemożliwe. Programista może tylko napisać procedurę, w której ciele określa explicite sposób przełączania na różne przypadki specjalizacji klas. 1.4 Trzy metody obejścia braku dziedziczenia Niektóre odmiany modelu relacyjnego umożliwiają definiowanie dziedziczenia atrybutów pomiędzy tabelami - nie jest to jednak regułą, dlatego poniżej omawiamy trzy metody postępowania w sytuacji, gdy takiej możliwości nie ma. Jedną z metod jest użycie jednej tabeli dla całego drzewa klas poprzez umieszczenie w niej wszystkich występujących atrybutów i powiązań w tym drzewie oraz dodanie dodatkowego atrybutu, tzw. dyskryminatora wariantu, który pozwala określić zakres znaczeniowy każdej z krotek tabeli. Przykład przedstawiony jest na Rys. 6: tabela ABC zawiera atrybuty z klas A, B i C oraz dyskryminator. Rys. 6. Użycie jednej tabeli dla całego drzewa klas Druga z metod polega na użyciu oddzielnej tabeli dla każdej z podklas, przy czym zawartość nadklasy jest powielana w każdej z tych tabel. Zgodnie z tą metodą tabela AB z Rys. 7 zawiera atrybuty z klas A i B, zaś tabela AC zawiera atrybuty z klas A i C.

Rys. 7. Użycie oddzielnej tabeli dla każdej podklasy Ostatnia omawiana metoda to użycie tabeli dla każdej klasy z osobna oraz zamiana dziedziczenia na powiązania łączące tabelę odpowiadającą nadklasie z tabelami odpowiadającymi podklasom. Schemat tej metody przedstawia Rys. 8. Jeżeli klasa A nie jest abstrakcyjna, to klucze obce w tabeli A powinny mieć możliwość przyjęcia wartości zerowych (zaznaczyliśmy to umieszczając liczności 0..1 dla powiązań po stronie tabel B i C). Rys. 8. Użycie tabeli dla każdej klasy Przykładowe obejścia braku dziedziczenia dla diagramu klas: