Projektowanie baz danych

Podobne dokumenty
PLAN WYKŁADU BAZY DANYCH ZALEŻNOŚCI FUNKCYJNE

Jak wiernie odzwierciedlić świat i zachować występujące w nim zależności? Jak implementacja fizyczna zmienia model logiczny?

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

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

Projektowanie hurtowni danych i modelowanie wielowymiarowe

Systemy baz danych. Notatki z wykładu

Projektowanie Systemów Informacyjnych

Normalizacja relacyjnych baz danych. Sebastian Ernst

Wykład II Encja, atrybuty, klucze Związki encji. Opracowano na podstawie: Podstawowy Wykład z Systemów Baz Danych, J.D.Ullman, J.

Projektowanie hurtowni danych i modelowanie wielowymiarowe

Bazy danych Teoria projektowania relacyjnych baz danych. Wykła. Wykład dla studentów matematyki

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

WYKŁAD 1. Wprowadzenie do problematyki baz danych

Pojęcie zależności funkcyjnej

Bazy danych. Andrzej Łachwa, UJ, /15

Bazy Danych i Usługi Sieciowe

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

Normalizacja baz danych

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

BAZY DANYCH NORMALIZACJA BAZ DANYCH. Microsoft Access. Adrian Horzyk. Akademia Górniczo-Hutnicza

Bazy danych. Andrzej Łachwa, UJ, /15

Bazy danych 3. Normalizacja baz danych

Technologie baz danych

BAZY DANYCH model relacyjny. Opracował: dr inż. Piotr Suchomski

Bazy danych i usługi sieciowe

Cel normalizacji. Tadeusz Pankowski

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

Bazy danych. Plan wykładu. Zależności funkcyjne. Wykład 2: Relacyjny model danych - zależności funkcyjne. Podstawy SQL.

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

Normalizacja. Pojęcie klucza. Cel normalizacji

Modelowanie danych, projektowanie systemu informatycznego

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

1 Wstęp do modelu relacyjnego

Transformacja modelu ER do modelu relacyjnego

Bazy danych 3. Normalizacja baz danych (c.d.)

Bazy danych 2. Zależności funkcyjne Normalizacja baz danych

Pierwsza postać normalna

Zależności funkcyjne pierwotne i wtórne

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

1 Projektowanie systemu informatycznego

Projektowanie hurtowni danych

Normalizacja schematów logicznych relacji

Postać normalna Boyce-Codd (BCNF)

BAZY DANYCH. Anomalie. Rozkład relacji i normalizacja. Wady redundancji

Projektowanie relacyjnych baz danych

Wykład 2. Relacyjny model danych

1 Przygotował: mgr inż. Maciej Lasota

Zależności funkcyjne

Technologia informacyjna

Normalizacja baz danych

Projektowanie baz danych

Pierwsza postać normalna

Relacyjne Bazy Danych Andrzej M. Borzyszkowski. Projekt bazy danych normalizacja. PJATK/ Gdańsk. Dwie metodologie. Formalne zasady projektowe

Tadeusz Pankowski Definicja. Definicja

Projektowanie hurtowni danych i modelowanie wielowymiarowe

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

Systemy baz danych i hurtowni danych

Przykłady normalizacji

BAZY DANYCH model związków encji. Opracował: dr inż. Piotr Suchomski

BAZY DANYCH NORMALIZACJA BAZ DANYCH. Microsoft Access. Adrian Horzyk. Akademia Górniczo-Hutnicza

KaŜdemu atrybutowi A przyporządkowana jest dziedzina Dom(A), czyli zbiór dopuszczalnych wartości.

TRANSFORMACJA MODELU ER DO MODELU RELACYJNEGO

Relacyjne bazy danych. Normalizacja i problem nadmierności danych.

Związki pomiędzy tabelami

Bazy danych. Zachodniopomorski Uniwersytet Technologiczny w Szczecinie. Wykład 3: Model związków encji.

Relacyjne systemy baz danych i język SQL

Baza danych to zbiór wzajemnie powiązanych ze sobą i zintegrowanych danych z pewnej dziedziny.

Bazy Danych i Usługi Sieciowe

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

Bazy danych Algebra relacji Wykład dla studentów matematyki

Bazy danych 3. Zależności funkcyjne Normalizacja relacyjnych baz danych

Zasady transformacji modelu DOZ do projektu tabel bazy danych

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

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji

Baza danych. Baza danych to:

Pożyczkobiorcy. Anomalia modyfikacji: Anomalia usuwania: Konta_pożyczkowe. Anomalia wstawiania: Przykłady anomalii. Pożyczki.

Systemy OLAP I. Krzysztof Dembczyński. Instytut Informatyki Zakład Inteligentnych Systemów Wspomagania Decyzji Politechnika Poznańska

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

PODSTAWY BAZ DANYCH. 5. Modelowanie danych. 2009/ Notatki do wykładu "Podstawy baz danych"

Program nauczania. Systemy baz danych. technik informatyk

Modele danych i ich ewolucja

Sylabus do programu kształcenia obowiązującego od roku akademickiego 2014/15

Plan wykładu. Problemy w bazie danych. Problemy w bazie danych BAZY DANYCH. Problemy w bazie danych Przykład sprowadzenia nieznormalizowanej SQL

ZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH

Systemy OLAP I. Krzysztof Dembczyński. Instytut Informatyki Zakład Inteligentnych Systemów Wspomagania Decyzji Politechnika Poznańska

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

Transformacja modelu ER do modelu relacyjnego

Granica funkcji. 27 grudnia Granica funkcji

WPROWADZENIE DO BAZ DANYCH

Transformacja modelu pojęciowego. do logicznego

Bazy danych w sterowaniu

Bazy danych. Algebra relacji

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

Relacyjny model danych

Bazy danych. Zasady konstrukcji baz danych

Bazy danych 2. Algebra relacji Zależności funkcyjne

SZKOLENIE: Administrator baz danych. Cel szkolenia

Zależności funkcyjne c.d.

Literatura. Bazy danych s.1-1

S y s t e m y. B a z D a n y c h

Transkrypt:

Krzysztof Dembczyński Instytut Informatyki Zakład Inteligentnych Systemów Wspomagania Decyzji Politechnika Poznańska Technologie Wytwarzania Oprogramowania Semestr zimowy 2005/06

Plan wykładu Ewolucja systemów baz danych Relacyjne systemy baz danych i język SQL i ochrona danych Optymalizacja i struktury danych Systemy OLAP I Systemy OLAP II Modelowanie wielowymiarowe Proces ekstrakcji, transformacji i ładowania danych (Proces ETL)

Plan wykładu 1 Zależności funkcyjne 2 Normalizacja 3 Model zwiazków encji

Plan wykładu 1 Zależności funkcyjne 2 Normalizacja 3 Model zwiazków encji

Plan wykładu 1 Zależności funkcyjne 2 Normalizacja 3 Model zwiazków encji

Plan wykładu 1 Zależności funkcyjne 2 Normalizacja 3 Model zwiazków encji

Zależności funkcyjne Zależności funkcyjne sa ważnym pojęciem pozwalajacym na lepsze projetkowanie baz danych. Projektowanie bazy danych: Zamodelowanie procesów biznesowych przedsiębiorstwa Rozpoznanie danych Model przedsiębiorstwa Zdefiniowanie informacji potrzebnej użytkownikom końcowym Specyfikacja wymagań Opis potrzeb użytkowników Model abstrakcyjny systemu bazy danych Projekt koncepcyjny Modele danych Przeniesienie modelu abstrakcyjnego do SZBD Projekt logiczny Modele logiczne (obiektowe, relacyjne, itp.) Zdefiniowanie stuktur przechowywania danych i metod dostępu Projekt fizyczny Postać fizyczna systemu bazy danych

Zależności funkcyjne Definicja dla konkretnej chwili czasu Niech R będzie relacja, X i Y zaś dowolnymi podzbiorami zbioru atrybutów R. Mówimy, że Y jest funkcyjnie zależny od X: X Y (czytaj X funkcyjnie określa Y ) wtedy i tylko wtedy, gdy każda wartość X z R jest stowarzyszona z dokładnie jedna wartościa Y z relacji R Innymi słowy, ilekroć dwie krotki z R maja taka sama wartość X, maja również sama wartość Y.

Zależności funkcyjne Przykład relacji SCP S# CITY P# QTY S1 London P1 100 S1 London P2 100 S2 Paris P1 200 S2 Paris P2 200 S3 Paris P2 300 S4 London P2 400 S4 London P4 400 S4 London P5 400

Zależności funkcyjne Dla powyższej tablicy mamy następujace zależności funkcyjne: (S#) (CITY) (S#, P#) (QTY) (S#, P#) (CITY) (S#, P#) (CITY, QTY) (S#, P#) (S#) (S#, P#) (S#, P#, CITY, QTY) (S#) (QTY) (QTY) (S#) Niektóre z tych zależności zachodza przez cały czas

Zależność funkcyjna, która zachodzi przez cały czas jest warunkiem integralności relacji R, bowiem nakłada ograniczenia na wartości jakie w R moga wystapić. Definicja dla wszystkich możliwych wartości relacji Niech R będzie zmienna relacja, X i Y zaś dowolnymi podzbiorami zbioru atrybutów R. Mówimy, że Y jest funkcyjnie zależny od X: X Y (czytaj X funkcyjnie określa Y ) wtedy i tylko wtedy, gdy dla każdej dopuszczalnej wartości R każda wartość X z R jest stowarzyszona z dokładnie jedna wartościa Y. Innymi słowy, dla każdej dopuszczalnej wartości R ilekroć dwie krotki z R maja taka sama wartość X, maja również sama wartość Y.

Zależności funkcyjne Dla powyższej tablicy mamy następujace zależności funkcyjne występujace przez cały czas : (S#) (CITY) (S#, P#) (QTY) (S#, P#) (CITY) (S#, P#) (CITY, QTY) (S#, P#) (S#) (S#, P#) (S#, P#, CITY, QTY) Poniższe takie nie sa: (S#) (QTY) (QTY) (S#)

Klucz kandydujacy a zależność funkcyjna Definicja Jeżeli X jest kluczem kandydujacym relacji R to wszystkie atrybuty Y relacji R musza koniecznie zależeć funkcyjnie od X.

Zależności trywialne i nietrywialne Zależność jest trywialna wtedy i tylko wtedy, gdy prawa strona jest podzbiorem lewej strony, np: (S#, P#) (S#) Każda relacja musi spełniać zależność trywialna. Jak łatwo się domyśleć nietrywialne zależności, to wszystkie pozostałe. Lewostronnie nieredukowalne zależności, to takie dla których nie można odjać żadnego atrybutu występujacego po lewej strony, bez straty opisu zależności występujacych w relacji W teorii wyznacza się zbiory zależności, ich domknięcia, oraz tzw. nieredukowalne zbiory zelażności.

Reguły Amstronga Reguły wnioskowania Amstronga Niech A, B i C będa dowolnymi podzbiorami zbioru atrybutów danej relacji R i niech zapis AB oznacza sumę A i B. Wówczas zachodza zwiazki: Zwrotność Jeżeli B A, to A B, Dołaczanie Jeżeli A B, to AC BC, Przechodność Jeżeli A B i B C, to A C.

Plan wykładu 1 Zależności funkcyjne 2 Normalizacja 3 Model zwiazków encji

Normalizacja Przykład rozszerzonej relacji SCP S# CITY P# QTY S1 London P1 300 S1 London P2 200 S1 London P3 400 S1 London P4 200 S1 London P5 100 S1 London P6 100 S2 Paris P1 300 S2 Paris P2 400 S3 Paris P2 200 S4 London P2 200 S4 London P4 300 S4 London P5 400

Postacie normale Pierwsza postać normalna (1NF) Druga postać normalna (2NF) Trzecia postać normalna (3NF) Postać normalna Boyce a-codd a (BCNF) Czwarta postać normalna (4NF) Piata postać normalna (5NF)

Normalizacja Projektant powinien dażyć do stworzenia projektu zawierajacego relacje w 3NF (lub lepiej BNCF) Procedura normalizacji pozwala na przeprowadzenie operacji przejście z jednej postaci do drugiej (przy czym ta druga jest ta bardziej oczekiwana) Procedura ta jest odwracalna.

Rozkład bezstratny(odwracalny) S S# STATUS CITY S3 30 Paris S5 30 Athens (a) SST S# STATUS S3 30 S5 30 SC S# CITY S3 Paris S5 Athens (b) SST S# STATUS S3 30 S5 30 STC STATUS CITY 30 Paris 30 Athens

Rozkład bezstratny(odwracalny) W przypadku (a) nie ma utraty informacji; po połaczeniu relacji SST i SC z powtorem otrzymay relację S w przypadku (b) informacja jest tracona, uzyskujemy wszystkie krotki wyjściowej relacji wraz z pewnymi zbędnymi krotkami Zauważmy, że w relacji S sa spełnione zależności funkcyjne z S# STATUS nieredukowalnego zbioru: S# CITY

Rozkład bezstratny(odwracalny) Twierdzenia Heatha Niech R{A, B, C} będzie relacja, zaś A, B i C zbiorami atrybutów. Jeżeli R spełnia zależność funkcyjna A B, wówczas relacja R jest równa złaczeniu swoich rzutów na {A, B} i {A, C}.

Pierwsza postać normalna Definicja Relacja występuje w pierwszej postaci normalnej 1NF wtedy i tylko wtedy, gdy wszystkie wyjściowe dziedziny zawieraja wyłacznie wartości skalarne.

Przykład rozszerzonej relacji ESCP S# STATUS CITY P# QTY S1 20 London P1 300 S1 20 London P2 200 S1 20 London P3 400 S1 20 London P4 200 S1 20 London P5 100 S1 20 London P6 100 S2 10 Paris P1 300 S2 10 Paris P2 400 S3 10 Paris P2 200 S4 20 London P2 200 S4 20 London P4 300 S4 20 London P5 400 Występujace zależności: (S#, P#) QTY S# CITY S# STATUS CITY STATUS

Normalizacja Występowanie nadmiarowych zależności prowadzi do wielu anomalii aktualizacji (czyli operacji INSERT, DELETE i UPDATE). Warto więc postarać zastapić relację ESCP dwoma innymi stosujac rozkład bezstratny.

(a) ESCT2 S# STATUS CITY S1 20 London S2 10 Paris S3 10 Paris S4 20 London S5 30 Athens (b) SP S# P# QTY S1 P1 300 S1 P2 200 S1 P3 400 S1 P4 200 S1 P5 100 S1 P6 100 S2 P1 300 S2 P2 400 S3 P2 200 S4 P2 200 S4 P4 300 S4 P5 400

Normalizacja Występujace zależności: S# CITY S# STATUS CITY STATUS (S#, P#) QTY

Druga postać normalna Definicja Relacja występuje w drugiej postaci normalnej 2NF wtedy i tylko wtedy, gdy juz jest w 1NF oraz każdy niekluczony atrybut jest nieredukowalnie zależny od klucza głównego. Relacja ESCP nie jest w 2NF. W drugiej postaci sa relacje ESCP2 oraz SP. Niestety cały czas nie jest to całkowicie poprawny projekt (relacja ESCP2)

(a) SC S# CITY S1 London S2 Paris S3 Paris S4 London S5 Athens Występujace zależności: (b) CS CITY STATUS Athens 30 London 20 Paris 10 Roma 50 S# CITY CITY STATUS W końcu poprawny projekt!!!

Trzecia postać normalna Definicja uproszczona Relacja jest w trzeciej postaci normalnej 3NF wtedy i tylko wtedy, gdy juz jest w 2NF oraz każdy niekluczony atrybut jest w sposób nieprzechodni zależny od klucza głównego.

Postać normalna Boyce a-codd a Definicja Relacja znajduje sie w BCNF wtedy i tylko wtedy, gdy jedynymi elementami determinujacymi (występujacymy po lewej stronie zależności) sa klucze kandydujace. Redukcja do postaci BCNF jest zawsze możliwa czyli dowolna relację można zastapić równoważnym zbiorem relacjiw BCNF. Celem takiej redukcji jest unikanie redundancji (nadmiarowości), co wiaże się z anomaliami aktualizacji.

Formalna definicja 3NF i BCNF Definicja Niech R będzie relacja, X dowolnym zbiorem atrybutów R, a A dowolnym jednym atrybutem z relacji R. Wówczas R jest w 3NF wtedy i tylko wtedy, gdy dla każdej zależności funkcyjnej X A z R jest spełniony przynajmniej jeden z warunków: X zawiera A (zależność jest trywialna), X zawiera klucz kandydujacy z R (czyli X jest kluczem nadrzędnym), A zawiera się w kluczu kandydujacym. Definicję BCNF otrzymujemy z powyższej definicji przez usunięcie ostatniego warunku.

Plan wykładu 1 Zależności funkcyjne 2 Normalizacja 3 Model zwiazków encji

Podstawowe definicje modelu zwiazków encji Encja rozróznialny obiekt (np. dostawca, część, dostawa, pracownik), Własność informacja opisujaca encję (np. numer dostawcy, nazwa części, wielkość dostawy, wzrost pracownika), Zwiazek Encja służaca do połaczenia dwóch lub więcej encji (np. dostawa: dostawca-części, zatrudnienie: pracownik-dział), Podtyp Encja typy Y jest podtypem encji typu X wtedy i tylko wtedy, gdy każdy Y jest też X (np. pracownik jest podtypem osoby).

Modelowanie Podstawowe kroki: Określenie zbioru pojęć: encji, zwiazków, typów, itd., Zdefiniowanie obiektów formalnych do reprezentacji powyższych pojęć, Określenie reguł integralności.

Encje Encje, czyli coś co można jednoznacznie zidentyfikować. Rozróżniamy encje regularne oraz słabe. Encja słaba to taka encja, której istnienie zależy od innej encji w tym sensie, że nie może ona istnieć, jeżeli ta inna encja też nie istnieje (np. krewni i pracownik).

Własności Encje posiadaja własności (czasami nazywane polami lub atrybutami). Własności moga być: proste i złożone, kluczowe, jedno- lub wielowartościowe, podstawowe lub pochodne.

Zwiazki Zwiazek to połaczenie między encjami, np. połaczenie między działem a pracownikiem. Zwiazek ten może zostać nazwany: zatrudnia, zatrudnienie, itd.. Zwiazki moga być: obowiazkowe oraz opcjonalne, jeden do jeden, jeden do wielu lub wiele do wiele, zwiazki moga być unarne, binarne, terarne itd..

Podtypy Każda encja ma przynajmniej jeden typ encji, jednak encja może należeć do kilku typów jednocześnie. Np. programista, może być też pracownikiem. Powstaje hierarchia typów.

Diagram zwiazków encji

Diagram zwiazków encji

Model zwiazków encji i projektowanie baz danych Encje regularne odwzorowywane sa na relacje podstawowe, czasem zapisuje się to następujaco: Pracownik(id_prac, imię, nazwisko,..., oddział). Zwiazki wiele do jeden sa reprezentowane przez klucze obce, tak jak powyżej, Zwiazki wiele do wiele zastępowane sa relacja: Dostawa(..., id_prac, id_cześć), Słabe encje sa zwiazane z silna encja zwiazkiem jeden do wiele, należy odpowiednio dobrać reguły klucza obcego: DELETE CASCADES, UPDATE CASCADES, Własności sa zamieniane na atrybuty o określonych atrybutach. Wyjatek stanowia własności złożone, Podtypy i nadtypy, np. Pracownik i Programista: Programista(id_prac,..., język programowania,... ).

Przykład Mały zakład produkcyjny Pracownicy sa zatrudnieni w różnych działach, przy czym jeden pracownik jest zatrudniony w jednym dziale. W bazie danych przechowujemy również informacje o najbliższych krewnych pracownika. Pracownicy uczestnicza w projektach, każdy projekt ma jednego szefa. Projekty wykorzystuja części dostarczane przez dostawców. Część może składać się z innych części.

Ogólna zasada projektowania Wykorzystaj podejście zwiazków encji badź inna metodykę z góry na dół do utworzenia poczatkowego projektu, Wykorzystaj zasady normalizacji do polepszanie otrzymanego projektu.

Plan wykładu Ewolucja systemów baz danych Relacyjne systemy baz danych i język SQL i ochrona danych Optymalizacja i struktury danych Systemy OLAP I Systemy OLAP II Modelowanie wielowymiarowe Proces ekstrakcji, transformacji i ładowania danych (Proces ETL)