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

Transkrypt

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

2 Wprowadzenie Idea Cel usuwanie redundancji usuwanie anomalii (przy wstawianiu, usuwaniu, modyfikowaniu wierszy)

3 Wprowadzenie Przykład idwyk imię nazwisko gabinet idkatedry wydział nazwakatedry idkursu nazwakursu 1 Jan Kowalski 107 W11K2 11 informatyki I04 Bazy danych 2 Adam Kowalski 107 W13K1 13 matematyki T06 Matematyka dyskretna 3 Jan Nowak 387 W8K3 8 informatyki Z17 Techn.programowania 4 Adam Nowak 41 W11K4 11 fizyki teoretycznej T07 Fizyka co stanie się jeśli usuniemy wiersze dla idwyk=3? co jeśli zmienimy nazwisko prowadzącego Bazy danych na Nowak? jak wstawić nowy kurs (np. nazwę)?

4 Definicje 1NF Pierwsza postać normalna Relacja R jest w pierwszej postaci normalnej iff każdy atrybut ma wartość atomową oraz nie istnieją powtarzające się krotki (tzn. istnieje klucz).

5 Definicje 2NF Druga postać normalna Relacja R jest w drugiej postaci normalnej iff R jest w 1NF oraz żaden atrybut niekluczowy nie jest zależny funkcyjnie od właściwego podzbioru klucza minimalnego. Oznacza to, że jeśli A jest atrybutem niekluczowym oraz X jest kluczem minimalnym relacji (niekoniecznie kluczem głównym) R, to każda zależność funkcyjna Y A, dla Y X narusza 2NF. Normalizacja 1 Szukamy zależności funkcyjnej X Y naruszającej 2NF 2 Rozkładamy R względem tej relacji U 1 = {X } +, U 2 = (U \ {X } + ) X. 3 Kończymy, gdy nie ma zależności naruszających 2NF.

6 Definicje 3NF Trzecia postać normalna Relacja R jest w trzeciej postaci normalnej iff R jest w 2NF oraz wszystkie niekluczowe atrybuty zależą tylko od pełnego klucza minimalnego. Oznacza to, że dla dowolnych atrybutów niekluczowych X, Y dowolna zależność funkcyjna X Y narusza 3NF.

7 Definicje 3NF Trzecia postać normalna Relacja R jest w trzeciej postaci normalnej iff R jest w 2NF oraz wszystkie niekluczowe atrybuty zależą tylko od pełnego klucza minimalnego. Oznacza to, że dla dowolnych atrybutów niekluczowych X, Y dowolna zależność funkcyjna X Y narusza 3NF. Alternatywnie Relacja R jest w trzeciej postaci normalnej iff R dla każdej zależności funkcyjnej (X Y ) F zachodzi przynajmniej jeden z warunków: Y X X jest nadkluczem każdy atrybut A Y \ X jest atrybutem kluczowym.

8 Definicje Podział przykładowej relacji idwyk imię nazwisko gabinet idkatedry 1 Jan Kowalski 107 W11K2 2 Adam Kowalski 107 W13K1 3 Jan Nowak 387 W8K3 4 Adam Nowak 41 W11K4 idkatedry wydział nazwakatedry W11K2 11 informatyki W13K1 13 matematyki W8K3 8 informatyki W11K4 11 fizyki teoretycznej idkursu nazwakursu prowadzący I04 Bazy danych 1 T06 Matematyka dyskretna 2 Z17 Techn.programowania 3 T07 Fizyka 4

9 Definicje A Simple Guide to 5 Normal Forms in Relational DB Theory. W. Kent Every non-key attribute must provide a fact about the key (1NF), the whole key (2NF), and nothing but the key (3NF). (So help me Codd.)

10 Definicje BCNF Postać normalna Boyce a Codda Relacja R jest w postaci normalnej Boyce a Codda iff R dla każdej zależności funkcyjnej (X Y ) F zachodzi przynajmniej jeden z warunków: Y X X jest nadkluczem Uwaga: Nie każdą relację można bezstratnie znormalizować do BCNF. Przykładem schematu nie spełniającego BCNF jest {AB C, C A}.

11 Definicje Przykład R = ABCDEFG, F min = {A C, A D, B D, A F, B C, CG B, FG D, DE C, DE G} klucz minimalny: AE, at. kluczowe: A, E, at. niekluczowe: B, C, D, F, G 1NF: 2NF:? 3NF:? BCNF:?

12 Definicje Przykład R = ABCDEFG, F min = {A C, A D, B D, A F, B C, CG B, FG D, DE C, DE G} klucz minimalny: AE, at. kluczowe: A, E, at. niekluczowe: B, C, D, F, G 1NF: 2NF: Szukamy z.f. właściwy podzbiór klucza atrybut niekluczowy, np. A C 3NF:? BCNF:?

13 Definicje Przykład R = ABCDEFG, F min = {A C, A D, B D, A F, B C, CG B, FG D, DE C, DE G} klucz minimalny: AE, at. kluczowe: A, E, at. niekluczowe: B, C, D, F, G 1NF: 2NF: R 1 = ACDF, F 1 = {A C, A D, A F }, R 2,1 = BCDEG, R 2,2 = DFG, F 2,1 = {DE C, DE G, CG B, B C, B D}, F 2,1 = {FG D} 3NF: BCNF:

14 Wstęp Projektowanie baz bazodanowy komponent 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

15 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

16 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

17 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, triggery(kontrola spójności), poziomy dostępu, widoki 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. przewidywana liczba użytkowników, liczba ról użytkowników, wymagania odnośnie logowania zdarzeń, nazewnictwo)

18 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)

19 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

20 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

21 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

22 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)

23 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

24 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:

25 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

26 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)

27 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

28 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

29 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

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

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

32 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.

33 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