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

Transkrypt

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

2 Wstęp Projektowanie baz bazodanowy komponent aplikacji projektujemy w sposób analogiczny do całej aplikacji ustalamy główne wymagania klienta, a przede wszystkim najczęstsze zastosowanie bazy danych OLTP vs. OLAP pomaga podjąć decyzję dot. normalizacji nadanie priorytetów komponentom i funkcjonalnościom, identyfikujemy encje, relacje między nimi, uwzględniamy ograniczenia projektu

3 Koncepcja Koncepcyjny model danych Etap mapowania pojęć dziedzinowych na komponenty (encje) baz danych. Rozpoznanie wymagań biznesowych. Lokalizowanie głównego komponentu i rozbudowywanie zależnie od powiązań. modelowanie abstrakcyjnych pojęć brak wchodzenia w strukturę baz danych, model musi być zrozumiały dla eksperta dziedzinowego i projektanta bazy danych określenie komponentów, które będą podlegać uszczegółowieniu

4 Modelowanie logiczne Etap modelu logicznego utechniczniamy model koncepcyjny podstawa pod implementację eliminacja redundantnych encji, ponowne wykorzystanie encji i określenie relacje między encjami Diagram struktur danych Identyfikujemy podstawowe encje, własności (atrybuty) encji oraz powiązania między encjami. Informacje te można przedstawić w postaci graficznej: diagram Chena IDEF1X diagram Bachmana diagram Martina UML

5 Modelowanie fizyczne Fizyczny model danych określamy wchodzące w skład bazy danych: tabele, ich kolumny, typy danych, klucze (w tym klucze obce), ograniczenia na wartości kolumn, kontrolę spójności za pomocą triggerów, poziomy dostępu i procedury składowane normalizujemy bazę danych rozważając każdą tabelę z osobna uwzględniamy ograniczenia systemowe (np. dialekt, system operacyjny, API frontendu) oraz organizacyjne (np. liczba ról użytkowników, wymagania odnośnie logowania, nazewnictwo)

6 Modelowanie fizyczne Transformacja z modelu logicznego do fizycznego Zależnie od typu bazy danych (relacyjna, relacyjno-obiektowa, obiektowa) mogą pojawić się trudności: implementacja zależności jeden do wielu i wiele do wielu brak dziedziczenia ograniczony zbiór typów danych typy atomowe, dla wielu wartości jednego atrybutu potrzebne jest powielanie rekordu dobór klucza wymagania użytkownika, np. czas działania, wymagania pamięciowe (przydatna denormalizacja)

7 Modelowanie fizyczne Podsumowanie 1 Określamy cel bazy 2 Określamy podstawowe komponenty, identyfikujemy nośniki informacji 3 Organizujemy informacje w encje, określamy ich atrybuty i powiązania między encjami 4 Transformujemy encje w tabele, określamy klucze 5 Uwzględniamy ograniczenia systemowe, normalizujemy

8 Diagramy Chena Podstawowe elementy Historia Notacja usystematyzowana przez P. Chena w 1976 r. Pozwala określić encje (transformowane do tabel), ich atrybuty (kolumny) i związki między nimi (klucze obce lub tabele). Podstawowa notacja będąca bazą dla kolejnych. Encja Atrybut Związek

9 Diagramy Chena Encje Wyszczególniony koncept podczas modelowania logicznego, cechuje się regularną strukturą własności i powiązań. Między encjami może zachodzić specjalny rodzaj powiązania uszczegółowienie isa

10 Diagramy Chena Atrybuty określają cechy encji określają cechy związków określają cechy złożonego atrybutu wyróżniamy podzbiór atrybutów identyfikujący encję (klucz)

11 Diagramy Chena Związki Określają powiązania między encjami powiązanie jednoznaczne (1-1) powiązania funkcyjne: jeden do wielu (1-n) powiązania wieloznaczne: wiele do wielu (n-m) Uwaga: mogą występować samopowiązania (związki rekurencyjne) a także związki między więcej niż dwoma encjami

12 Diagramy Martina Podstawowe elementy rozszerzenie notacji Chena (np. dodanie aktywności) umożliwienie modelowania zdarzeń (diagram przepływów) rozszerzenie modelowania krotności (encje opcjonalne) Określenie krotności:

13 UML Diagram klas każda encja reprezentowana jest przez klasę różne poziomy szczegółowości (uwzględnienie atrybutów, funkcji,... ) możemy tworzyć drzewa klas (dziedziczenie) umożliwiając różne stopnie uszczegóławiania encji Nazwa_Klasy Atrybuty Funkcje, Procedury, Triggery

14 UML Asocjacje wskazują na powiązania klas etykieta asocjacji wskazuje krotności oraz kierunek asocjacji asocjacja może mieć oznaczone krotności (cf. notacja Martina) w przypadku autoasocjacji konieczne jest określenie ról wraz z krotnością na końcach asocjacji asocjacja może mieć własne atrybuty (klasy asocjacyjne, łączone przerywaną linią do asocjacji)

15 UML Agregacja i kompozycja związki silniejsze niż asocjacja (część całości) w przeciwieństwie do asocjacji, istnienie jednej encji może być warunkowane istnieniem innej atrybuty, krotności jak w asocjacji na diagramie oznaczane odpowiednio pustym i wypełnionym diamentem

16 UML Modelowanie asocjacji połączenie 1-1: poszerzamy tabelę lub stosujemy rozwiązanie dla innych połączeń połączenie 1 do wielu: implementujemy tabelę dla każdej encji i używamy kluczy obcych lub stosujemy rozwiązanie dla wiele do wielu połączenie wiele do wielu (lub inne z atrybutami asocjacji): tworzymy osobną tabelę połączenia, zawierającą klucze obce do tabel reprezentujących łączone encje

17 UML Uszczegóławianie i dziedziczenie W relacyjnych bazach danych typowe dla baz i języków obiektowych dziedziczenie trzeba obejść: Jedna tabela dla całego drzewa klas wraz z atrybutem uszczegóławiającym obowiązkowe komentarze Zsumowanie atrybutów klasy głównej i dziedziczącej, utworzenie osobnych tabel dla wszystkich klas pochodnych Rozdzielenie każdej z klas, modelowanie zależności dziedziczenia przez agregację/kompozycję z ustalonymi krotnościami

18 Przykład Przykład Opis: Zaprojektuj bazę danych dla ligi piłkarskiej.

19 Przykład Przykład Opis: Zaprojektuj bazę danych dla ligi piłkarskiej. Uwzględnij piłkarzy, drużyny oraz rozgrywane mecze.

20 Przykład Przykład Opis: Zaprojektuj bazę danych ułatwiającą zarządzanie ligą piłkarską. W lidze zawsze jest przynajmniej jedna drużyna, składająca się z wielu piłkarzy oraz przynajmniej jednego trenera. Drużyny identyfikowane są przez ich nazwę oraz siedzibę, natomiast osoby przez imię, nazwisko i datę urodzenia. Dodatkowo przechowywane są informacje o bramkach, asystach i kartkach dla każdego z zawodników. (Natomiast dla każdej z drużyn znamy... ) Każdy mecz odbywa się na konkretnym stadionie, w ramach ustalonych rozgrywek. Grają w nim drużyna gospodarzy oraz gości, uporządkowana para drużyn wraz z sezonem rozgrywek jednoznacznie identyfikuje dany mecz. Żadna drużyna nie może rozgrywać meczy dwa dni pod rząd. Dla każdego meczu przechowujemy jego wynik, strzelców bramek, informację o asystach, kartkach, prowadzącym mecz sędzi oraz dodatkowe statystyki jak procent posiadania piłki (suma posiadania piłki przez obie drużyny nie może przekraczać 100). Baza danych powinna automatycznie uaktualniać statystyki piłkarzy na podstawie dodanego meczu. Możliwe powinno być wygenerowanie aktualnej tabeli drużyn. Po rozegraniu wszystkich meczy (mecz i rewanż pomiędzy każdą parą zespołów) sezon powinien być automatycznie kończony.

21 Narzędzia Przykładowe narzędzia dla ER i UML Dia NetBeans UML Oracle J/SQL Developer Eclipse UML StarUML UMLet Papyrus UML Modeler Vertabelo TikZ przykład, pakiet TikZ-UML