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

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

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

Projektowanie Systemów Informacyjnych

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

Transformacja modelu ER do modelu relacyjnego

Cel normalizacji. Tadeusz Pankowski

Bazy danych i usługi sieciowe

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

WYKŁAD 1. Wprowadzenie do problematyki baz danych

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

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

Normalizacja. Pojęcie klucza. Cel normalizacji

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

1 Projektowanie systemu informatycznego

Wykład 2. Relacyjny model danych

Modelowanie danych, projektowanie systemu informatycznego

Projektowanie baz danych

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

Bazy Danych. Modele danych. Krzysztof Regulski WIMiIP, KISiM,

Bazy Danych i Usługi Sieciowe

Technologie baz danych

Przykłady normalizacji

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

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

PLAN WYKŁADU BAZY DANYCH MODEL DANYCH. Relacyjny model danych Struktury danych Operacje Integralność danych Algebra relacyjna HISTORIA

1 Wstęp do modelu relacyjnego

TRANSFORMACJA MODELU ER DO MODELU RELACYJNEGO

Zasady transformacji modelu DOZ do projektu tabel bazy danych

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

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

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

Projektowanie bazy danych

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

Technologia informacyjna

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

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

Pojęcie zależności funkcyjnej

Systemy informatyczne. Modelowanie danych systemów informatycznych

Związki pomiędzy tabelami

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

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

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

Transformacja modelu ER do modelu relacyjnego

Modelowanie konceptualne model EER

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

Normalizacja baz danych

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

Autor: Joanna Karwowska

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA Relacyjny model danych. Relacyjny model danych Struktury danych Operacje Oganiczenia integralnościowe

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

Bazy Danych 2008 Część 1 Egzamin Pisemny

Normalizacja relacyjnych baz danych. Sebastian Ernst

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

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

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

Diagramy związków encji ERD Ćwiczenia w modelowaniu danych

Baza danych. Modele danych

Model relacyjny bazy danych

Informatyka Ćwiczenie 10. Bazy danych. Strukturę bazy danych można określić w formie jak na rysunku 1. atrybuty

Bazy danych i usługi sieciowe

Bazy danych. Zasady konstrukcji baz danych

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

Model relacyjny. Wykład II

Pierwsza postać normalna

Bazy danych. Andrzej Łachwa, UJ, /15

Temat: Modelowanie schematu bazy danych za pomocą diagramów związków encji (Entity Relationship Diagrams ERD)

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

Normalizacja relacji

1. Mapowanie diagramu klas na model relacyjny.

Pierwsza postać normalna

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

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

KSS: Modelowanie konceptualne przykład

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

FUNKCJE SZBD. ZSE - Systemy baz danych 1

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

WPROWADZENIE DO BAZ DANYCH

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

Normalizacja schematów logicznych relacji

WPROWADZENIE DO BAZ DANYCH

Baza danych. Baza danych to:

ZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH

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

Autor: Joanna Karwowska

Bazy danych TERMINOLOGIA

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

Krzysztof Kadowski. PL-E3579, PL-EA0312,

Uniwersytet Zielonogórski Instytut Sterowania i Systemów Informatycznych Bazy Danych - Projekt. Zasady przygotowania i oceny projektów

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

Modelowanie związków encji. Etapy budowy systemu informatycznego przedsiębiorstwa (1/4) Etapy budowy systemu informatycznego przedsiębiorstwa (2/4)

Przykładowa baza danych BIBLIOTEKA

Relacyjny model danych

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

Bazy danych. Algebra relacji

Modelowanie konceptualne. Modelowanie konceptualne przykład. Modelowanie konceptualne model ER. Model ER Entity-Relationship

Normalizacja baz danych

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

Autor: Joanna Karwowska

Bazy danych 3. Normalizacja baz danych

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

Transkrypt:

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

Elementy procesu projektowania bazy danych Badanie zależności funkcyjnych Normalizacja Projektowanie bazy danych Model ER, diagramy ERD Encje, atrybuty, związki Więzy integralności

Zagrożenia - Anomalie Anomalia dołączania (wstawiania) nie można dołączyć krotki, nie znamy wszystkich danych, które krotka musi zawierać. Anomalia aktualizacji (modyfikacji) te same dane muszą być zmieniane w wielu miejscach. Anomalia usuwania usunięcie krotki powoduje niepożądane usunięcie innych, istotnych danych.

Normalizacja relacji Normalizacja to jeden z etapów projektowania relacyjnej bazy danych. Celem normalizacji jest usunięcie redundancji (powtarzania się tych samych danych, nadmiaru danych) i wyeliminowanie anomalii.

Pierwsza postać normalna 1NF Relacja jest w pierwszej postaci normalnej (1NF), jeżeli wartości atrybutów są atomowe (niepodzielne).

Funkcyjna zależność atrybutów Zbiór atrybutów Y jest funkcyjnie zależny od zbioru atrybutów X, co zapisujemy X Y, wtedy i tylko wtedy, gdy dla dwóch dowolnych krotek r, s takich, że r[x] = s[x], zachodzi zawsze r Y = s[y]. Przykład: Atrybut Y=Płaca jest funkcyjnie zależny od X=Stanowisko.

Funkcyjna zależność od klucza Każdy atrybut jest funkcyjnie zależny od klucza relacji, który jest unikalny. Rzeczywiście, jeśli K jest kluczem relacji, to dla każdych krotek r, s równość r K = s[k] implikuje, że r = s, a stąd r[a] = s[a] dla każdego atrybutu A.

Pełna funkcyjna zależność Zbiór atrybutów Y jest w pełni funkcyjnie zależny od zbioru atrybutów X, jeżeli X Y i nie istnieje podzbiór Z X taki, że Z Y..

Druga postać normalna 2NF Relacja jest w drugiej postaci normalnej (2NF), jeżeli każdy jej atrybut wtórny (tzn. nie należący do klucza relacji) jest w pełni funkcyjnie zależny od klucza głównego tej relacji. W szczególności klucz główny relacji w 2NF jest optymalny (nie można zmniejszyć liczby jego atrybutów). Każda relacja, która ma klucz główny jednoelementowy, jest zawsze w 2NF.

Przechodnia funkcyjna zależność Zbiór atrybutów Y jest przechodnio funkcyjnie zależny od zbioru atrybutów X, jeżeli X Y i istnieje zbiór atrybutów Z, nie będący podzbiorem żadnego klucza relacji taki, że zachodzi X Z i Z Y.

Przykład przechodniej funkcyjnej zależności ID pracownika Stanowisko Płaca

Trzecia postać normalna 3NF Relacja jest w trzeciej postaci normalnej (3NF), jeżeli jest w drugiej postaci normalnej i żaden atrybut wtórny nie jest przechodnio funkcyjnie zależny od klucza głównego tej relacji.

Projektowanie bazy danych Projektowanie relacyjnej bazy danych ma na celu: określenie, jakie tabele, a w nich jakie wiersze i kolumny będą występowały w bazie danych oraz jakie będą powiązania pomiędzy tabelami; określenie, jakie operacje będą wykonywane na danych i jakie będą skutki tych operacji tak, aby zachować integralność danych;

Projektowanie baz danych

Model ER (Entity-Relationship) Model ER opisuje dziedzinę przedmiotową za pomocą pojęć: encja (entity) (jednostka, obiekt) - reprezentuje byt (a w zasadzie typ takiego bytu ) ze świata rzeczywistego (obiekty materialne i niematerialne, zdarzenia i fakty); atrybut (attribute) określa szczegółowe właściwości (cechy) encji; związek (relationship) - reprezentuje powiązania między encjami.

Notacja Chena Do nieformalnego przedstawienia projektu bazy danych możemy wykorzystać model ER zaproponowany przez Petera P. Chena w 1976 r. http://en.wikipedia.org/wiki/entity%e2%80%93relationship_model

Inne notacje http://en.wikipedia.org/wiki/entity%e2%80%93relationship_model

Model ER Projekt ma postać graficzną zwaną diagramem związków encji lub ERD (Entity Relationship Diagram). Atrybuty tworzące klucz główny encji wyróżnia się przez podkreślenie. Istnieje procedura (pół)automatycznej transformacji diagramu ER do konkretnej implementacji, np. do relacyjnej bazy danych.

Przykład ERD

Przykład diagramu ERD

Przykład diagramu ERD

Związki Związek obrazuje powiązania między dwoma encjami (związek binarny) lub większą liczbą encji (związki wieloczłonowe). Związek może posiadać atrybuty. związki mogą być rekurencyjne (cykliczne).

Związki Opisując związek należy określić: role uczestniczących w nim encji charakter uczestnictwa encji: obowiązkowy (obligatoryjny), opcjonalny liczebność, tj. wartość mówiącą, ilu reprezentantów danej encji może jednocześnie uczestniczyć w związku: zero lub 1 0..1 (opcjonalny) dokładnie jeden 1(obligatoryjny) zero lub wiele 0..N, 0.. (opcjonalny) jeden lub wiele N, 1..N, 1.. (obligatoryjny) liczebność określamy dla każdej encji uczestniczącej w związku

Związki jedno-jednoznaczne 1-1 Ten typ związku występuje rzadko i nie jest pożądany Pary encji pozostające w takim związku należy połączyć w jedną encję dodając atrybuty jednej z nich do drugiej.

Związki jednoznaczne 1-N lub N-1 Najczęściej spotykany i pożądany typ związku. Związek jest reprezentowany za pomocą klucza głównego encji po stronie jeden, umieszczanego jako atrybut encji po stronie wiele. Tak utworzony atrybut encji po stronie wiele tworzący referencję, nosi nazwę klucza obcego (foreign key) Jeżeli związek posiada atrybuty, to dołączamy je do encji po stronie wiele.

Związki rekurencyjne (cykliczne) Związek ma miejsce dla różnych obiektów tej samej encji Związek jest reprezentowany za pomocą klucza głównego encji po stronie jeden, umieszczanego jako dodatkowy atrybut tej samej encji po stronie wiele. Przykład: tabela Pracownicy (ID_Prac,, Szef)

Związki wieloznaczne N-N Związek wieloznaczny nie jest pożądany - może być łatwo usunięty przez utworzenie nowej encji i zastąpienie związku wieloznacznego dwoma związkami jednoznacznymi Nowo utworzona encja działa jako łącznik dla związku wieloznacznego i znajduje się po stronie wiele dla obu nowych związków Para atrybutów tworzących referencje do encji po stronach jeden tworzy klucz główny nowo utworzonej encji, a każdy z tych atrybutów osobno jest jednocześnie kluczem obcym w tej encji Jeżeli związek posiadał atrybuty, to dołączamy je do nowo utworzonej encji.

Związki wieloznaczne N-N Przykład

Związki wieloczłonowe (n-arne) Przykład:

Przekształcenie w związki 1-N Egzaminy (IdEgz, Przedmiot, IdWykł, NrIndeksu, Data, Ocena) IdEgz jest kluczem własnym w tabeli Egzaminy Przedmiot, IdWykł, NrIndeksu są kluczami obcymi w tabeli Egzaminy

Encje słabe Encją słabą nazywamy encję, dla której istnienie jej obiektów jest uzależnione od istnienia obiektów innej encji. Np. istnienie obiektu encji Dziecko w bazie danych o pracownikach ma sens, gdy istnieje obiekt encji Pracownik, będący rodzicem dziecka. Encje słabe nie mają własnego atrybutu kluczowego. Ich obiekty są identyfikowane za pomocą kombinacji wartości wyróżnionego atrybutu (tzw. klucza częściowego) i wartości klucza encji właściciela, np. (IdPrac, Imię).

Specjalizacja - generalizacja Specjalizacja: definiowanie zbioru encji podklas na podstawie encji nadklasy. Generalizacja: definiowanie ogólnej encji nadklasy na podstawie istniejącego zbioru encji, które automatycznie stają się encjami podklas. Specjalizacja może być rozłączna lub nakładająca się. Specjalizacja może być pełna lub częściowa.

Specjalizacja Samochody (NrRej, Marka, Model, Typ) Osobowe (NrRej, LiczMiejsc) Ciężarowe (NrRej, Ładown) Generalizacja Samochody (NrRej, Marka, Model, Typ, LiczMiejsc, Ładown)

Więzy integralności Więzy integralności to wymagania, które winny być spełnione przez określony podzbiór danych z bazy. Określają one warunki spójności powiązań, np.: unikalność klucza encji (klucz nie może zawierać wartości NULL), zawężenie dziedziny atrybutu do wartości dopuszczalnych (np. NOT NULL) zależności między wartościami atrybutów (w danym wierszu), odpowiedni format wartości atrybutu (np. nr telefonu, kod, ISBN) zależności pomiędzy wartościami danego atrybutu, a wartościami tego atrybutu w innych wierszach ograniczenie zbioru wartości, które może przyjmować pewien atrybut encji E1 do wartości określonego atrybutu encji E2 (np. klucz obcy encji E1 może przyjmować wartości tylko z dziedziny klucza głównego encji E2)

Więzy integralności Więzy mogą być statyczne (zawsze zachodzą) lub dynamiczne (związane z przejściem bazy z jednego stanu w drugi). Przykłady konieczności zastosowania dynamicznych więzów integralności: Dodanie lub zmiana wierszy w tabeli powiązanej, jeśli nie istnieje odpowiedni wiersz w tabeli podstawowej. Zmiana wierszy w tabeli podstawowej, która powoduje powstanie osieroconych wierszy w tabeli powiązanej. Usuwanie wiersza z tabeli podstawowej, gdy istnieją do niego odwołania w tabeli powiązanej.

Jak utworzyć ERD? 1. Ustalić encje i określić ich nazwy (rzeczowniki). 2. Dla każdej encji ustalić jej atrybuty i dziedziny tych atrybutów (przymiotniki, cechy). 3. Dla każdej encji określić, jakie atrybuty pełnią funkcję klucza głównego. 4. Ustalić związki, jakie zachodzą między encjami, określić ich liczebność (czasowniki). 5. Wyeliminować jako niepożądane związki jednojednoznaczne (1-1) i związki wieloznaczne (N-N). 6. Uzupełnić encje o klucze obce pozwalające zrealizować w praktyce związki jednoznaczne. 7. Określić więzy integralności nałożone na dane w bazie danych.