1 Metodologia : to kompleksowe podejście wykorzystujące procedury, techniki, narzędzia oraz metody tworzenie dokumentacji służące realizacji i uproszczeniu.

Prezentacja na temat: "1 Metodologia : to kompleksowe podejście wykorzystujące procedury, techniki, narzędzia oraz metody tworzenie dokumentacji służące realizacji i uproszczeniu."— Zapis prezentacji:

1 1 Metodologia : to kompleksowe podejście wykorzystujące procedury, techniki, narzędzia oraz metody tworzenie dokumentacji służące realizacji i uproszczeniu procesu projektowania. Konceptualne projektowanie bazy danych – to proces tworzenia modelu dla informacji wykorzystywanych w przedsiębiorstwie, niezależny od wszelkich szczegółów reprezentacji fizycznej.

2 2 Logiczne projektowanie bazy danych – to proces tworzenia modelu dla informacji wykorzystywanych w przedsiębiorstwie, przystosowanego do konkretnego modelu danych (np. model relacyjny), lecz niezależnego od konkretnego SZBD i innych szczegółów implementacji fizycznej. Fizyczne projektowanie bazy danych – proces tworzenia opisu implementacji bazy danych w pamięci zewnętrznej, który zawiera relacje bazowe, organizację plików, indeksy stosowane dla uzyskania efektywnego dostępu do danych, a także wszystkie więzy integralności i zagadnienia bezpieczeństwa.

3 3 Główne zasady efektywnego projektowania baz danych: jak najwięcej kontaktuj się z użytkownikami bazy danych; w trakcie całego procesu modelowania danych postępuj zgodnie z przyjętą metodologią; stosuj podejście uwzględniające przepływ danych; uwzględniaj w modelu kwestie struktury i integralności danych;

4 4 stosuj w trakcie projektowania techniki konceptualizacji, normalizacji i oceny możliwości realizacji wymaganych transakcji; wszędzie, gdzie tylko to możliwe, wyrażaj model danych za pomocą diagramów; stosuj język projektowania bazy danych (DBDL od ang. Database Design Language) do opisu tych własności, których nie można w prosty sposób wyrazić za pomocą diagramów; utwórz słownik danych uzupełniający diagramy i DBDL; zawsze, gdy zachodzi taka potrzeba, powtarzaj odpowiednie kroki modelowania.

5 5 Konceptualne projektowanie bazy danych: Krok 1. Tworzenie lokalnego konceptualnego modelu danych dla każdej perspektywy Krok 1.1. Określ występujące zbiory encji Krok 1.2. Ustal typy występujących związków Krok 1.3. Określ atrybuty odpowiadające poszczególnym zbiorom encji i związkom Krok 1.4. Określ dziedziny poszczególnych atrybutów Krok 1.5. Ustal klucze kandydujące i klucze główne Krok 1.6. Rozważ możliwość zastosowania zaawansowanych metod modelowania (krok opcjonalny) Krok 1.7. Zweryfikuj utworzony model pod kątem występowania redundancji Krok 1.8. Zweryfikuj możliwość realizacji transakcji w lokalnym modelu konceptualnym Krok 1.9. Omów lokalny konceptualny model danych z użytkownikiem

6 6 Logiczne projektowanie bazy danych w modelu relacyjnym: Krok 2. Tworzenie i weryfikacja lokalnego modelu logicznego dla każdej perspektywy: Krok 2.1. Usuń własności niekompatybilne z modelem relacyjnym (krok opcjonalny); Krok 2.2. Wyznacz relacje dla lokalnego logicznego modelu danych; Krok 2.3. Wykonaj normalizację relacji; Krok 2.4. Sprawdź, czy relacje umożliwiają realizację transakcji; Krok 2.5. Wyznacz więzy integralności; Krok 2.6. Omów lokalny logiczny model danych z użytkownikiem. Krok 3. Tworzenie i weryfikacja globalnego logicznego modelu danych: Krok 3.1. Scal lokalne logiczne modele danych w model globalny; Krok 3.2. Sprawdź poprawność globalnego logicznego modelu danych; Krok 3.3. Sprawdź możliwości przystosowania modelu do przewidywanych zmian; Krok 3.4. Omów globalny logiczny model danych z użytkownikami.

7 7 Proces konceptualnego i logicznego projektowania bazy danych składa się z trzech głównych kroków. Celem kroku 1 jest podział problemu na zadania łatwiejsze do analizy poprzez rozważenie różnych perspektyw użytkowników. W wyniku kroku 1 powstaje wiele (lub jeden) lokalnych konceptualnych modeli danych. Każdy z tych modeli powinien stanowić kompletną i dokładną reprezentacje zagadnienia z punktu widzenia innego użytkownika lub grupy użytkowników. Krok 2 odwzorowuje każdy lokalny model konceptualny na lokalny logiczny model danych dla modelu relacyjnego, składający się z diagramów związków encji, schematów relacji oraz dokumentacji pomocniczej. W kroku 3 następuje integracja lokalnych logicznych modeli danych (reprezentujących różne perspektywy) w jeden globalny logiczny model danych całego przedsiębiorstwa (reprezentujący wszystkie perspektywy użytkowników).

8 8 Krok 1 : Tworzenie lokalnego konceptualnego modelu danych dla każdej perspektywy (każdego obszaru zainteresowań) W trakcie analizy zagadnienia zazwyczaj zidentyfikowanych zostaje wiele różnych perspektyw. W przypadku dużego stopnia wzajemnego ich pokrywania się, niektóre z nich można połączyć w perspektywy „grupowe” z nadanymi im własnymi nazwami. Krok 1.1. Określ występujące zbiory encji (dokumentuj informacje o zbiorach encji) Częstą metodą określenia zbiorów encji jest wyróżnienie obiektów, których istnienie wynika z samej natury modelowego zagadnienia. Czasami wyróżnienie zbiorów encji może być trudne, co spowodowane jest sposobem ich reprezentacji w specyfikacjach wymagań użytkowników, którzy posługują się zazwyczaj przykładami lub analogiami, czy też synonimami i homonimami.

9 9 Fragment słownika danych przedstawiający opis zbiorów encji : Uzupełnieniem konceptualnego modelu danych jest dokumentacja, w tym słownik danych utworzony w trakcie tworzenia modelu Nazwa zbioru encji OpisAliasyWłasności Personel Pojęcie ogólne opisujące wszystkich pracowników zatrudnionych przez biuro obrotu nieruchomościami. PracownicyKażdy pracownik personelu pracuje w jednym biurze. Nieruchomość Pojęcie ogólne opisujące wszystkie nieruchomości do wynajęcia. Nieruchomość -- DoWynajęcia Każda nieruchomość ma jednego właściciela i jest oferowana do wynajęcia w jednym biurze, gdzie zarządza nią jeden pracownik. Informacje o nieruchomości dostępne są wielu klientom, ale w danym momencie może być wynajęta tylko przez jednego klienta....

10 10 Krok 1.2. Dużą uwagę należy poświęcić temu, aby wykryć wszystkie związki zawarte wprost lub wynikające pośrednio ze specyfikacji wymagań użytkownika. W tym celu: używaj diagramów związków encji (ER); ustal krotności w poszczególnych związkach encji (do weryfikowania i utrzymywania określonych własności danych); sprawdź czy występują pułapki wachlarzowe lub szczelinowe; sprawdź, czy każdy zbiór encji występuje w przynajmniej jednym związku (należy jeszcze raz sprawdzić wymagania użytkownika i ustalić, czy nie doszło do pominięcia jakichś związków lub czy encja nie występuje w innej części modelu); udokumentuj typy związków. Ustal typy występujących związków (między wyróżnionymi wcześniej zbiorami encji):

11 11 Pierwsze przybliżenie diagramu: Właściciel prywatny WłaścicielNr Wynajęcie WynajęcieNr Nieruchomość NieruchomośćNr Klient KlientNr Personel PersonelNr Biuro BiuroNr Ma Oferuje Posiada Wynajęty Przez Nadzoruje Ogląda Wynajmuje

12 12 Fragment słownika danych prezentujący opis związków : Nazwa encjiKrotnośćZwiązekNazwa encjiKrotność Personel0..1 Zarządza Kieruje Nieruchomość Personel 0..100 0..10 Nieruchomość1..1SkojarzonaZWynajęcie0..*...

13 13 Krok 1.3. Poprzez zidentyfikowanie rodzajów informacji o encjach i związkach, które chcemy reprezentować w bazie danych. Określamy: Określ atrybuty odpowiadające poszczególnym zbiorom encji i związkom atrybuty proste i złożone; atrybuty jednowartościowe i wielowartościowe; atrybuty pochodne – umieszczamy je aby uniknąć utraty informacji w przypadku usunięcia bądź zmodyfikowania atrybutów od których zależy atrybut pochodny; potencjalne problemy; dokumentowanie informacji o atrybutach (po zidentyfikowaniu atrybutów należy przyporządkować im adekwatne i czytelne dla użytkownika nazwy).

14 14 Fragment słownika danych przedstawiający opis atrybutów: Nazwa zbioru encji AtrybutyOpisTyp danych i długośćWartości puste Wielowar- tościowy... PersonelpersonelNr imięNazwisko imię nazwisko stanowisko płeć dataUr Jednoznacznie identyfikuje pracownika Imię pracownika Nazwisko pracownika Nazwa zajmowanego stanowiska Płeć pracownika Data urodzenia pracownika łańcuch, długość maks. 5 łańcuch, długość maks. 15 łańcuch, długość maks. 10 łańcuch, długość 1 (M lub K) data Nie Nie Tak Nie Nie... NieruchomośćnieruchomośćNrJednoznacznie identyfikuje nieruchomość do wynajęcia łańcuch, długość maks. 5Nie...

15 15 Krok 1.4. Określ dziedziny poszczególnych atrybutów W kompletnym modelu danych określona jest dziedzina każdego atrybutu, a także: dopuszczalny zbiór wartości atrybutu; dopuszczalny zakres długości i format atrybutu. Mogą być też podane dodatkowe informacje o dziedzinach, takie jak zbiór dopuszczalnych operacji na atrybutach oraz wykaz atrybutów, które mogą być ze sobą porównywane lub używane łącznie. Możemy zdefiniować np.: dziedzinę dopuszczalnych numerów pracowników (pracownikNr) jako zbiór łańcuchów o długości nie większej niż 5 znaków, w których pierwsze dwa znaki są literałami, a następne (od jednego do trzech) tworzą liczbę z zakresu 1-999; dopuszczalne wartości dla atrybutu płeć jako np. zbiór łańcuchów jednoznakowych: „M” lub „K”.

16 16 Krok 1.5. Ustal klucze kandydujące i klucze główne: Kluczem kandydującym jest minimalny zbiór atrybutów, który jednoznacznie identyfikuje każde wystąpienie encji w zbiorze encji. Przy wyborze klucza głównego spośród kluczy kandydujących warto rozważyć: klucz o najmniejszej liczbie atrybutów; klucz, którego wartości najrzadziej ulegają zmianom; klucz kandydujący o najmniejszej liczbie znaków (dotyczy kluczy składających się z atrybutów tekstowych); klucz o najmniejszej wartości maksymalnej (dotyczy kluczy o wartościach numerycznych); klucz, z którego najłatwiej będzie korzystać użytkownikowi. Jeśli wybór klucza głównego jest możliwy, wtedy zbiór encji nazywamy silnym, zaś gdy nie możemy wybrać żadnego klucz głównego, zbiór encji nazywany jest słabym.

17 17 Diagram związków encji z informacjami o kluczach głównych: Klient KlientNr DataRejestracji Biuro BiuroNr Ma Kieruje 0..1 Personel PersonelNr 1..1 0..1 1..* 1..1 dataPoczątkowa premia dataOgłoszenia koszt 1..1 Rejestruje Zarządza 0..* Preferencje Wynajęcie UmowaNr Nieruchomość NieruchomośćNr Właściciel Instytucjonalny I Nazwa Wynajmuje Określa PPosiada Wynajęty Przez Ogłasza I Posiada Gazeta NazwaGazety Właściciel prywatny WłaścicielNr Oferuje 0..* 1..1 0..100 0..* 1..1 1..* 0..* 0..1 Nadzoruje

18 18 Krok 1.6. Rozważ możliwość zastosowania zaawansowanych metod modelowania (krok opcjonalny) : Rozważenie potrzeby użycia zaawansowanych metod modelowania, takich jak specjalizacja/generalizacja, agregacja i kompozycja. Użycie (bądź nie) zaawansowanych metod modelowania powinno służyć czytelności diagramu związków encji i jasności modelu dla istotnych zbiorów encji i związków między nimi. Np. możemy dokonać generalizacji encji WłaścicielPrywatny i WłaścicielInstytucjonalny, tworząc nadklasę Właściciel zawierającą wspólne dla obu zbiorów encji atrybuty: włascicielNr, adres i telNr.

19 19 Krok 1.7. Zweryfikuj utworzony model pod kątem występowania redundancji: Proces ten składa się z następujących czynności: ponowne sprawdzenie związków wzajemnie jednoznacznych (1:1) – ponieważ w trakcie ustalania występujących zbiorów encji może dojść do utworzenia dwóch różnych zbiorów reprezentujących te same obiekty ze świata rzeczywistego np. Klient i Najemca; usunięcie związków redundantnych (nadmiarowych) – ponieważ naszym celem jest stworzenie minimalnego modelu danych. Wykrycie istnienia więcej niż jednej ścieżki między dwoma zbiorami encji jest stosunkowo łatwe, jednak nie muszą one oznaczać, że jeden ze związków jest redundantny, ponieważ mogą one reprezentować inne powiązania między zbiorami encji. Przy poszukiwaniu redundancji istotne jest zatem zrozumienie i analiza znaczenia poszczególnych związków.

20 20 Krok 1.8. Zweryfikuj możliwość realizacji transakcji w lokalnym modelu konceptualnym : Teraz należy sprawdzić czy utworzony model rzeczywiście umożliwia wykonanie wszystkich transakcji wymaganych w danej perspektywie. Możemy to osiągnąć poprzez: sporządzenie opisu wymagań poszczególnych transakcji i sprawdzeniu, czy wszystkie informacje wymagane do realizacji transakcji zostały umieszczone w modelu; wykorzystanie ścieżek transakcji – poprzez graficzną reprezentację ścieżki, przez którą przechodzi transakcja na diagramie związków encji, możemy też w ten sposób ustalić, które elementy modelu nie są wykorzystywane, a które są krytyczne dla realizacji transakcji. Przeprowadzenie tych czynności sprawdzających na tym etapie projektu (a nie później) jest bardzo istotne, ponieważ naprawianie błędów w modelu na dalszym etapie pracy jest i dużo trudniejsze i droższe. Krok 1.9. Omów lokalny konceptualny model danych z użytkownikiem (w celu weryfikacji, czy model jest „prawdziwą” reprezentacją modelowanej perspektywy).

21 21 Logiczne projektowanie bazy danych w modelu relacyjnym: Krok 2. Tworzenie i weryfikacja lokalnego modelu logicznego dla każdej perspektywy Krok 2.1. Usuń własności niekompatybilne z modelem relacyjnym (krok opcjonalny jeżeli wybieramy relacyjny SZBD do realizacji bazy danych); Cele tego kroku to: usunięcie binarnych związków typu „wiele do wielu” (*:*) – dekomponowanie poprzez utworzenie pośredniego zbioru encji, a następnie zamianę związku „wiele do wielu” (*:*) na dwa związki typu „jeden do wielu” (1:*), w których występuje nowy zbiór encji; usunięcie rekurencyjnych związków typu „wiele do wielu” (*:*) – poprzez ich rozłożenie i ustalenie nowego „pośredniczącego” zbioru encji; usunięcie związków złożonych – też poprzez rozłożenie i utworzenie pośredniczącego zbioru encji; usunięcie atrybutów wielowartościowych (poprzez zastąpienie ich nowym zbiorem encji).

22 22 Krok 2.2. Wyznacz relacje dla lokalnego logicznego modelu danych : Związki pomiędzy encjami są reprezentowane za pomocą „wiązania” poprzez klucze główne i obce. W każdym binarnym związku typu 1:* encja występująca po stronie „jeden” jest encją nadrzędną, a encja po stronie „wiele” podrzędną. Związek taki jest reprezentowany poprzez umieszczenie atrybutów klucza głównego encji nadrzędnej w relacji reprezentującej encję podrzędną. Atrybuty te stanowią klucz obcy relacji podrzędnej. Np.:

23 23 Elementy procesu przekształcania encji i związków na relacje: Encje/ZwiązkiSposób odwzorowania Silna encjaUtworzenie relacji zawierającej wszystkie atrybuty proste. Słaba encjaUtworzenie relacji zawierającej wszystkie atrybuty proste (klucz główny zostanie ustalony dopiero po odwzorowaniu na relacje wszystkich związków z encjami nadrzędnymi). Binarny związek 1:* Klucz główny encji występującej po stronie Jeden" należy skopiować do zbioru encji po stronie „wiele", gdzie będzie kluczem obcym. Atrybuty związku należy umieścić po stronie „wiele".

24 24 Encje/ZwiązkiSposób odwzorowania Binarny związek 1:1: (a) uczestnictwo obowiązkowe po obu stronach (b) uczestnictwo obowiązkowe po jednej stronie (c) uczestnictwo opcjonalne po obu stronach związku Połączenie zbiorów encji w jedną relacje. Klucz główny encji po stronie „opcjonalnej" należy skopiować do zbioru encji po stronie „obowiązkowej" jako klucz obcy. Dowolny, o ile wybór reprezentacji nie wynika z innych informacji. Binarny związek *:*, związek złożony Utworzenie relacji reprezentującej związek i umieszczenie w niej wszystkich atrybutów związku. Klucze główne encji nadrzędnych należy skopiować do nowej relacji (w której pełnią rolę kluczy obcych). Atrybuty wielowartościoweUtworzenie osobnej relacji reprezentującej atrybut wielowartościowy, skopiowanie do niej klucza głównego encji zawierającej dany atrybut (w nowej relacji skopiowany klucz jest kluczem obcym)

25 25 Krok 2.3. Wykonaj normalizację relacji : Przeprowadzamy proces normalizacji: 1NF – usuwa powtarzające się grupy atrybutów; 2NF – usuwa częściowe zależności od klucza głównego; 3NF – usuwa przechodnie zależności od klucza głównego; BCNF – usuwa pozostałe anomalie z zależności funkcyjnych Normalizacja daje bardzo elastyczny projekt, który łatwo daje się dalej rozwijać i rozszerzać. Krok 2.4. Sprawdź, czy relacje umożliwiają realizację transakcji

26 26 Normalizacja: Głównym celem projektowania bazy przeznaczonej dla systemu relacyjnego jest właściwa reprezentacja danych, związków i więzów. W identyfikowaniu właściwych relacji pomaga technika nazywana normalizacją, która można powiedzieć jest techniką wstępującą projektowania bazy danych. Normalizacja – to technika służąca do wyznaczania zbioru relacji o pożądanych na podstawie wymagań względem danych przedsiębiorstwa cechach.

27 27 1972 – po raz pierwszy przedstawiony proces normalizacji przez E.F.Codda; wówczas zproponował trzy postacie normalne: 1NF, 2NF, 3NF (normal form). 1974 – R.Boyce i E.F.Codd wprowadzili silniejszą definicję trzeciej postaci normalnej (postać normalna Boyce’a-Codda BCNF) Powyższe postacie normalne są oparte na zależnościach funkcyjnych pomiędzy atrybutami. Wprowadzone kilka lat później wyższe postacie normalne, wychodzące poza BCNF, czwarta i piąta postać normalna (Fagin 1977, 1979) dotyczą sytuacji występujących bardzo rzadko.

28 28 Redundancja danych i anomalie aktualizacji: Główne zadanie w projektowaniu relacyjnej bazy danych to pogrupowanie atrybutów w relacje w sposób, który minimalizuje redundancję danych – efektem jest zmniejszenie wymagań pamięciowych dla plików implementujących bazowe relacje. Np. porównanie relacji: PersonelBiuro z relacjami: Personel Biuro

29 29 Personel: Biuro: pracownikNrimięNazwiskostanowiskopensjabiuroNr Sl21Jan Wiśniewskidyrektor3000B005 SG37Anna Białyasystent1200B003 SG14Daniel Frankowskikierownik1800B003 SA9Maria Hojnaasystent900B007 SG5Sabina Boberdyrektor2400B003 SL41Julia Lisickaasystent900B005 biuroNradres B003Mała 63, Grajewo, 19-200 B005Dobra 22, Łomża, 18-400 B007Miodowa 32, Białystok, 15-900 pracownikNrimięNazwiskostanowiskopensjabiuroNradres Sl21Jan Wiśniewskidyrektor3000B005Dobra 22, Łomża, 18-400 SG37Anna Białyasystent1200B003Akacjowa 16, Augustów, 16-300 SG14Daniel Frankowskikierownik1800B003Mała 63, Grajewo, 19-200 SA9Maria Hojnaasystent900B007Miodowa 32, Białystok, 15-900 SG5Sabina Boberdyrektor2400B003Cicha 56, Łomża, 18-400 SL41Julia Lisickaasystent900B005 PersonelBiuro:

30 30 Takie relacje zawierające redundantne dane mogą być przyczyną anomalii aktualizacji, które dzielą się na: anomalie wstawienia (przy nowym pracowniku informacje o biurze mogą być błędnie wpisane – niespójność bazy); anomalie usuwania (po usunięciu informacji o pracowniku znikają informacje o biurze); anomalie modyfikacji (gdy zmiana adresu biura trzeba zmienić we wszystkich rekordach pracowników tego biura). Poprzez dekompozycję relacji PersonelBiuro na relacje Personel i Biuro pozbywamy się problemu anomalii aktualizacji.

31 31 Proces normalizacji: Normalizacja jest to formalna technika oparta na kluczach głównych oraz na zależnościach funkcyjnych. Często realizowana w serii kroków, z których każdy odpowiada specyficznej postaci normalnej o ustalonych własnościach. Relacje otrzymują wówczas coraz bardziej ograniczony format, stając się tym samym coraz mniej podatne na anomalie aktualizacji.

32 32 Postać nieznormalizowana – to tabela zawierająca co najmniej jedną powtarzającą się grupę. Pierwsza postać normalna (1NF – first normal form) – to relacja, w której każde przecięcie wiersza i kolumny zawiera tylko jedną wartość. Druga postać normalna (2NF) – oznacza relację w pierwszej postaci normalnej, w której każdy atrybut spoza klucza głównego jest od niego w pełni funkcyjnie zależny. Trzecia postać normalna (3NF) – oznacza relację w pierwszej i w drugiej postaci normalnej, w której żaden atrybut spoza klucza głównego nie jest od niego przechodnio zależny.

33 33 Zależności funkcyjne: Zależność funkcyjna opisuje związek pomiędzy atrybutami w relacji (tabeli): Np. z relacji Personel czyli dla każdego pracownika występuje tylko jedno stanowisko; czyli istnieje wielu pracowników powiązanych z danym typem stanowiska.

34 34 Np.: Rozważmy wartości atrybutów pracownikNr i imięNazwisko w relacji Personel. Dla sytuacji przedstawionej w tabeli Personel mogą zachodzić następujące zależności funkcyjne: pracownikNr → imięNazwisko imięNazwisko → pracownikNr Jednak po rozważeniu wszystkich możliwych wartości atrybutów pracownikNr i imięNazwisko w relacji Personel jedynym związkiem, który pozostaje prawdziwy jest: pracownikNr → imięNazwisko

35 35 Postać nieznormalizowana – to tabela zawierająca co najmniej jedną powtarzającą się grupę. Nieznormalizowana tabela KlientWynajęcie : klient Nr kImię Nazwisko nierucho- mośćNr nAdreswynajęte Od wynajęte Do czynszwłaściciel Nr wImię Nazwisko CR76Janusz Kalinowski B4 B16 Leśna 6, Białystok 15-900 Nowa 5, Białystok 15-900 01.07. 2006 01.09. 2006 31.08. 2007 01.09. 2007 350 450 CO40 CO93 Tatiana Marcinkowska Tomasz Szymański CO56Alicja Stefańska B4 B36 B16 Leśna 6, Białystok 15-900 Mała 2, Białystok 15-900 Nowa 5, Białystok 15-900 01.09. 2007 01.10. 2006 01.11. 2007 01.06. 2008 01.12. 2007 01.08. 2008 350 375 450 CO40 CO93 CO93 Tatiana Marcinkowska Tomasz Szymański

36 36 Pierwsza postać normalna (1NF – first normal form) – to relacja, w której każde przecięcie wiersza i kolumny zawiera tylko jedną wartość. Pierwszy sposób usuwania powtarzających się grup: KlientWynajęcie klient Nr nierucho- mośćNr kImię Nazwisko nAdreswynajęte Od wynajęte Do czynszwłaścicie lNr wImię Nazwisko CR76B4Janusz Kalinowski Leśna 6, Białystok 15-900 01.07.200631.08.2007350CO40Tatiana Marcinkowska CR76B16Janusz Kalinowski Nowa 5, Białystok 15-900 01.09.200601.09.2007450CO93Tomasz Szymański CO56B4Alicja Stefańska Leśna 6, Białystok 15-900 01.09.200701.06.2008350CO40Tatiana Marcinkowska CO56B36Alicja Stefańska Mała 2, Białystok 15-900 01.10.200601.12.2007375CO93Tomasz Szymański CO56B16Alicja Stefańska Nowa 5, Białystok 15-900 01.11.200701.08.2008450CO93Tomasz Szymański

37 37 Drugi sposób usuwania powtarzających się grup: Klient NieruchomośćWynajęcieWłaściciel klientNrnierucho- mośćNr nAdreswynajęteOdwynajęteDoczynszwłaściciel Nr wImięNazwisko CR76B4Leśna 6, Białystok 15-900 01.07.200631.08.2007350CO40Tatiana Marcinkowska CR76B16Nowa 5, Białystok 15-900 01.09.200601.09.2007450CO93Tomasz Szymański CO56B4Leśna 6, Białystok 15-900 01.09.200701.06.2008350CO40Tatiana Marcinkowska CO56B36Mała 2, Białystok 15-900 01.10.200601.12.2007375CO93Tomasz Szymański CO56B16Nowa 5, Białystok 15-900 01.11.200701.08.2008450CO93Tomasz Szymański klientNrkImięNazwisko CR76Janusz Kalinowski CO56Alicja Stefańska

38 38 Druga postać normalna (2NF) Normalizacja z pierwszej do drugiej postaci normalnej polega na usunięciu zależności częściowych: Wynajęcie nieruchomośćNrnAdresczynszwłaścicielNrwImięNazwisko B4Leśna 6, Białystok 15-900350CO40Tatiana Marcinkowska B16Nowa 5, Białystok 15-900450CO93Tomasz Szymański B36Mała 2, Białystok 15-900375CO93Tomasz Szymański klientNrnieruchomośćNrwynajęteOdwynajęteDo CR76B401.07.200631.08.2007 CR76B1601.09.200601.09.2007 CO56B401.09.200701.06.2008 CO56B3601.10.200601.12.2007 CO56B1601.11.200701.08.2008 WłaścicielNieruchomość

39 39 Trzecia postać normalna (3NF) Wszystkie atrybuty spoza klucza głównego w relacji WłąścicielNieruchomość są funkcyjnie zależne od klucza głównego, z wyjątkiem atrybutu wImięNazwisko, który jest także zależny od właścicielNr. Usuwamy, zatem powyższą zależność: nieruchomośćNrnAdresczynszwłaścicielNr B4Leśna 6, Białystok 15-900350CO40 B16Nowa 5, Białystok 15-900450CO93 B36Mała 2, Białystok 15-900375CO93 Właściciel właścicielNrwImięNazwisko CO40Tatiana Marcinkowska CO93Tomasz Szymański Nieruchomość

40 40 Rozkład relacji KlientWynajęcie w 1NF do relacji w 3NF: KlientWynajęcie 1NF WłaścicielNieruchomość2NF 3NFWłaścicielNieruchomośćKlient Wynajęcie

41 41 Zestawienie relacji w 3NF: Klient klientNrkImięNazwisko CR76Janusz Kalinowski CO56Alicja Stefańska Nierucho mość nieruchomośćNrnAdresczynszwłaścicielNr B4Leśna 6, Białystok 15-900350CO40 B16Nowa 5, Białystok 15-900450CO93 B36Mała 2, Białystok 15-900375CO93 Właściciel właścicielNrwImięNazwisko CO40Tatiana Marcinkowska CO93Tomasz Szymański Wynajęcie klientNrnieruchomośćNrwynajęteOdwynajęteDo CR76B401.07.200631.08.2007 CR76B1601.09.200601.09.2007 CO56B401.09.200701.06.2008 CO56B3601.10.200601.12.2007 CO56B1601.11.200701.08.2008

42 42 Postać normalna Boyce’a-Codda (BCNF): oznacza relację, w której każdy wyznacznik zależności jest kluczem kandydującym. Potencjalne naruszenie BCNF może wystąpić w relacji o następujących własnościach: - relacja zawiera dwa (lub więcej) złożone klucze kandydujące; - klucze kandydujące relacji pokrywają się (tzn. mają co najmniej jeden wspólny atrybut).

43 43 Relacja WywiadZKlientem zawiera trzy złożone klucze kandydujące: (klientNr, dataWywiadu) (pracownikNr, dataWywiadu, czasWywiadu) (pokójNr, dataWywiadu, czasWywiadu) które pokrywają się wzajemnie, dzieląc między sobą wspólny atrybut dataWywiadu. Np. dla sytuacji: WywiadZKlientem klientNrdataWywiaduczasWywiadupracownikNrpokójNr CR7613.05.200410.30SG5G101 CR5613.05.200412.00SG5G101 CR7413.05.200412.00SG37G102 CR5601.07.200410.30SG5G102

44 44 Natomiast mamy następujące zależności funkcyjne: zf1 klientNr, dataWywiadu → czasWywiadu, pracownikNr, pokójNr (klucz główny) zf2 pracownikNr, dataWywiadu, czasWywiadu → klientNr (klucz kandydujący) zf3 pokójNr, dataWywiadu, czasWywiadu → pracownikNr, klientNr (klucz kandydujący) zf4 pracownikNr, dataWywiadu → pokójNr Relację WywiadZKlientem przekształcamy do relacji Wywiad i PokójPersonel : Wywiad (klientNr, dataWywiadu, czasWywiadu, pracownikNr) PokójPersonel (pracownikNr, dataWywiadu, pokójNr) wówczas gdy pracownicy przeprowadzają wiele wywiadów dziennie.

45 45 klientNrdataWywiaduczasWywiadupracownikNr CR7613.05.200410.30SG5 CR5613.05.200412.00SG5 CR7413.05.200412.00SG37 CR5601.07.200410.30SG5 Wywiad pracownikNrdataWywiadupokójNr SG513.05.2004G101 SG3713.05.2004G102 SG501.07.2004G102 PokójPersonel

46 46 Krok 2.5. Wyznacz więzy integralności : Trzeba rozważyć pięć typów więzów integralności: 1. wymagana obecność danych; 2. więzy dziedzin atrybutów (ustalane z wyborem dziedzin atrybutów – krok 1.4); 3. integralność encji (ograniczenie, że klucz główny zbioru encji nie może przyjmować wartości pustych należy uwzględnić po wyborze klucza głównego – 1.5); 4. integralność referencyjna (wymuszanie więzów integralności); 5. więzy ogólne (reguły biznesowe, zasady działania). Krok 2.6. Omów lokalny logiczny model danych z użytkownikiem

47 47 Krok 3. Tworzenie i weryfikacja globalnego logicznego modelu danych : Krok 3.1. Scal lokalne logiczne modele danych w model globalny Spis typowych czynności wykonywanych w metodzie scalania: 1.Porównanie nazw i zawartości encji/relacji i ich kluczy kandydujących. 2.Porównanie nazw i zawartości związków/kluczy obcych. 3.Scalenie encji/relacji z lokalnych modeli danych. 4.Włączenie (bez scalania) encji/relacji unikalnych dla poszczególnych lokalnych modeli danych. 5.Scalenie związków/kluczy obcych występujących w lokalnych modelach danych. 6.Włączenie (bez scalania) związków/kluczy obcych unikalnych dla poszczególnych lokalnych modeli danych. 7.Sprawdzenie kompletności zbiorów encji/relacji i związków/kluczy obcych. 8.Sprawdzenie kluczy obcych. 9.Sprawdzenie więzów integralności.

48 48 Relacje reprezentujące globalny logiczny model danych projektu WymarzonyDom : Biuro (biuroNr, ulica, miasto, kodPocztowy, dyrPracownikNr) Primary Key biuroNr Alternate Key kodPocztowy Foreign Key dyrPracownikNr references Dyrektor(pracownikNr) Telefon (telNr, biuroNr) Primary Key telNr Foreign Key biuroNr references Biuro(biuroNr) Personel (pracownikNr, imię, nazwisko, stanowisko, płeć, dataUr, pensja, przetożonyNr, biuroNr) Primary Key pracownikNr Foreign Key przełOŻonyNr references Personel (pracownikNr) Foreign Key biuroNr references Biuro (biuro Nr) Dyrektor (pracownikNr, dataPoczątkowa, premia) Primary Key pracownikNr Foreign Key pracownikNr referenees Personel(pracownikNr)

49 49 Właściciel_Prywatny (właścicielNr, imię, nazwisko, adres, telNr) Primary Key właścicielNr Właściciel Instytucjonalny (właścicielNr, iNazwa, iTyp, nazwiskoReprezentanta, adres, telNr) Primary Key właścicielNr Primary Key iNazwa Alternate Key telNr Nieruchomość (nieruchomośćNr, ulica, miasto, kodPocztowy, typ, pokoje, czynsz, właścicielNr, pracownikNr, biuroNr) Primary Key nieruchomośćNr Foreign Key właścicieiNr references Właściciel Prywatny (właściciel Nr) and Właściciel Instytucjonalny (właścicielNr) Foreign Key pracownikNr references Personel (pracownikNr) Foreign Key biuroNr references Biuro(biuroNr) Wizyta (klientNr, wizytaNr, dataWizyty, uwagi) Primary Key WientNr, nieruchomośćNr Foreign Key klientNr references Kiient(klientNr) Foreign Key nieruchomośćNr references Nieruchomość(nieruchomośćNr)

50 50 Klient (klientNr, imię, nazwisko, telNr, typPreferencji, maksCzynsz) Primary Key klientNr Rejestracja (kiientNr, biuroNr, pracownikNr, dataRejestracji) Primary Key klientNr Foreign Key klientNr references Klient(klientNr) Foreign Key biuroNr references Biuro (biuroNr) Foreign Key pracownikNr references Personel(pracownikNr) Ogłoszenie (nieruchomośćNr, nazwaGazety, dataOgłoszenia, koszt) Primary Key nieruchomośćNr, nazwaGazety, dataOgłoszenia Foreign Key nieruchomośćNr references Nieruchomość(nieruchomośćNr) Foreign Key nazwaGazety references G azeta (nazwaGazety) Gazeta (nazwaGazety, adres, telNr, nazwiskoReprezentanta) Primary Key nazwaGazety Alternate Key telNr

51 51 Wynajęcie (wynajęcieNr, formaPtatności, kaucjaZapłacona, wynajęteOd, wynajęteDo, klientNr, nieruchomośćNr) Primary Key wynajęcieNr Alternate Key nieruchomośćNr, wynajęteOd Alternate Key klientNr, wynajęteOd Foreign Key klientNr references Klient(klientNr) Foreign Key nieruchomośćNr references Nieruchomość(nieruchomośćNr) Derived kaucja (Nieruchomość.czynsz*2) Derived okresNajmu (wynajęteDo - wynajęteOd)