Bazy danych 1. Wykład 6 Metodologia projektowania baz danych. (projektowanie logiczne - Normalizacja)



Podobne dokumenty
Chemoinformatyczne bazy danych - Wprowadzenie do technologii baz danych. Andrzej Bąk

Projektowanie bazy danych

System Zarządzania Relacyjną Bazą Danych (SZRBD) Microsoft Access 2010

SIECI KOMPUTEROWE I BAZY DANYCH

INSTRUKCJA DLA INSPEKTORÓW DS. REJESTRACJI

System zarządzania bazą danych (SZBD) Proces przechodzenia od świata rzeczywistego do jego informacyjnej reprezentacji w komputerze nazywać będziemy

Temat: Funkcje. Własności ogólne. A n n a R a j f u r a, M a t e m a t y k a s e m e s t r 1, W S Z i M w S o c h a c z e w i e 1

KLAUZULE ARBITRAŻOWE

Rudniki, dnia r. Zamawiający: PPHU Drewnostyl Zenon Błaszak Rudniki Opalenica NIP ZAPYTANIE OFERTOWE

Warszawska Giełda Towarowa S.A.

Umowa o pracę zawarta na czas nieokreślony

Harmonogramowanie projektów Zarządzanie czasem

Trwałość projektu co zrobić, żeby nie stracić dotacji?

Uchwała nr O III Krajowej Rady Izby Architektów RP z dnia 20 marca 2012 r. w sprawie wprowadzenia wzoru kontraktu menedżerskiego

2.Prawo zachowania masy

Nadzwyczajne Walne Zgromadzenie Art New media S.A. uchwala, co następuje:

Motywuj świadomie. Przez kompetencje.

Wiedza niepewna i wnioskowanie (c.d.)

Odpowiedzi na pytania zadane do zapytania ofertowego nr EFS/2012/05/01

Instrukcja zarządzania systemem informatycznym służącym do przetwarzania danych osobowych

Regulamin organizacji przetwarzania i ochrony danych osobowych w Powiatowym Centrum Kształcenia Zawodowego im. Komisji Edukacji Narodowej w Jaworze

JĘZYK ROSYJSKI POZIOM ROZSZERZONY

Jakie są te obowiązki wg MSR 41 i MSR 1, a jakie są w tym względzie wymagania ustawy o rachunkowości?

System obsługi pacjenta w ośrodku zdrowia

Wniosek o ustalenie warunków zabudowy

Zarządzenie Nr 12 /SK/2010 Wójta Gminy Dębica z dnia 06 kwietnia 2010 r.

Program szkoleniowy Efektywni50+ Moduł III Standardy wymiany danych

Turniej Piłkarski. Copa Manufaktura 2006

KOMISJA WSPÓLNOT EUROPEJSKICH. Wniosek DECYZJA RADY

RAPORT NA TEMAT STANU STOSOWANIA PRZEZ SPÓŁKĘ ZALECEŃ I REKOMENDACJI ZAWARTYCH W ZBIORZE DOBRE PRAKTYKI SPÓŁEK NOTOWANYCH NA GPW 2016

Warunki Oferty PrOmOcyjnej usługi z ulgą

Ogłoszenie o zwołaniu Nadzwyczajnego Walnego Zgromadzenia Spółki ELKOP S.A.

Warszawa, dnia 11 marca 2016 r. Poz. 327 ROZPORZĄDZENIE. z dnia 7 marca 2016 r.

REGULAMIN PRAKTYK DLA STUDENTÓW UCZELNI JANA WYŻYKOWSKIEGO

ARKUSZ OCENY OKRESOWEJ DLA STANOWISK PRACOWNICZYCH

Postanowienia ogólne. Usługodawcy oraz prawa do Witryn internetowych lub Aplikacji internetowych

RAPORT Z EWALUACJI WEWNĘTRZNEJ. Młodzieżowego Domu Kultury w Puławach W ROKU SZKOLNYM 2014/2015. Zarządzanie placówką służy jej rozwojowi.

Umowa w sprawie przyznania grantu Marie Curie 7PR Wykaz klauzul specjalnych

REGULAMIN ZAWIERANIA I WYKONYWANIA TERMINOWYCH TRANSAKCJI WALUTOWYCH

ZAMAWIAJĄCY. Regionalna Organizacja Turystyczna Województwa Świętokrzyskiego SPECYFIKACJA ISTOTNYCH WARUNKÓW ZAMÓWIENIA (DALEJ SIWZ )

Instrukcja kasowa. Spółdzielni Mieszkaniowej Lokatorsko Własnościowej PRZYMORZE w Świnoujściu. tekst jednolity na dzień 14 maja 2015 r.

Szczegółowe wyjaśnienia dotyczące definicji MŚP i związanych z nią dylematów

REGULAMIN KONKURSU Organizacja Przyjazna Wolontariuszom

Zintegrowane Systemy Zarządzania Biblioteką SOWA1 i SOWA2 SKONTRUM

WYKŁAD 8. Postacie obrazów na różnych etapach procesu przetwarzania

INFORMACJE O INSTRUMENTACH FINANSOWYCH WCHODZĄCYCH W SKŁAD ZARZADZANYCH PRZEZ BIURO MAKLERSKIE PORTFELI Z UWZGLĘDNIENIEM ZWIĄZANYCH Z NIMI RYZYK

Ogłoszenie o zwołaniu Nadzwyczajnego Walnego Zgromadzenia Akcjonariuszy TELL Spółka Akcyjna z siedzibą w Poznaniu na dzień 11 sierpnia 2014 r.

ZP Obsługa bankowa budżetu Miasta Rzeszowa i jednostek organizacyjnych

art. 488 i n. ustawy z dnia 23 kwietnia 1964 r. Kodeks cywilny (Dz. U. Nr 16, poz. 93 ze zm.),

Procedura nadawania uprawnień do potwierdzania, przedłuŝania waŝności i uniewaŝniania profili zaufanych epuap. Załącznik nr 1

Regulamin realizacji projektu edukacyjnego w Gimnazjum w Niechobrzu.

2) Drugim Roku Programu rozumie się przez to okres od 1 stycznia 2017 roku do 31 grudnia 2017 roku.

Procedura nadawania uprawnień do potwierdzania Profili Zaufanych w Urzędzie Gminy w Ryjewie

Edycja geometrii w Solid Edge ST

Elementy cyfrowe i układy logiczne

GENERALNY INSPEKTOR OCHRONY DANYCH OSOBOWYCH

Formularz oferty. (Wypełniają jedynie Wykonawcy składający wspólną ofertę)

Wykład 8 Ochrona danych wprowadzenie Sterowanie dostępem do danych Sterowanie przepływem danych Ograniczanie możliwości wnioskowania Szyfrowanie

WZÓR UMOWY DLA PRZETARGU NIEOGRANICZONEGO na realizację szkoleń w ramach projektu Patrz przed siebie, mierz wysoko UMOWA NR.

Miejski System Zarządzania - Katowicka Infrastruktura Informacji Przestrzennej

OFERTA. Oświadczamy, że:

tel/fax lub NIP Regon

Plan wykładu. Rozmyte zapytania do Baz Danych. Wstęp. Wstęp informacja rozmyta. Logika rozmyta w Bazach Danych nieprecyzyjne wartości atrybutów

PFR Wstępnie wypełnione zeznanie podatkowe. PIT-37 i PIT-38 za rok 2015

Postanowienie z dnia 9 kwietnia 2003 r., I CKN 281/01

POLITYKA BEZPIECZEŃSTWA OCHRONY DANYCH OSOBOWYCH W PRAKTYCE LEKARSKIEJ/DENTYSTYCZNEJ.... (nazwa praktyki) wydana w dniu... przez...

Zarządzanie Zasobami by CTI. Instrukcja

UCHWAŁA NR./06 RADY DZIELNICY PRAGA PÓŁNOC M. ST. WARSZAWY

PLAN POŁĄCZENIA RADPOL SPÓŁKA AKCYJNA I WIRBET SPÓŁKA AKCYJNA

INSTRUKCJA Panel administracyjny

Procedura działania Punktu Potwierdzającego Profile Zaufane epuap Urzędzie Gminy w Ułężu

JĘZYK UML JAKO NARZĘDZIE MODELOWANIA PROCESU PROJEKTOWO-KONSTRUKCYJNEGO

1. Korzyści z zakupu nowej wersji Poprawiono Zmiany w słowniku Stawki VAT Zmiana stawki VAT w kartotece Towary...

Podstawy programowania

Gdynia: Księgowość od podstaw Numer ogłoszenia: ; data zamieszczenia: OGŁOSZENIE O ZAMÓWIENIU - usługi

Nowości w module: BI, w wersji 9.0

Wdrożenie modułu płatności eservice dla systemu Virtuemart 2.0.x

UMOWA (wzór) zawarta w dniu... w Płaskiej, pomiędzy: Gminą Płaska, Płaska 53, Płaska, NIP , REGON ,

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

K P K P R K P R D K P R D W

PROCEDURY UDZIELANIA ZAMÓWIEŃ PUBLICZNYCH w Powiatowym Urzędzie Pracy w Pile

UCHWAŁA NR RADY MIEJSKIEJ W ŁODZI z dnia

Komentarz do prac egzaminacyjnych w zawodzie technik administracji 343[01] ETAP PRAKTYCZNY EGZAMINU POTWIERDZAJĄCEGO KWALIFIKACJE ZAWODOWE

Przypomnienie najważniejszych pojęć z baz danych. Co to jest baza danych?

Zalecenia dotyczące prawidłowego wypełniania weksla in blanco oraz deklaracji wekslowej

UMOWA POWIERZENIA PRZETWARZANIA DANYCH OSOBOWYCH (zwana dalej Umową )

Aplikacje bazodanowe. Laboratorium 1. Dawid Poªap Aplikacje bazodanowe - laboratorium 1 Luty, 22, / 37

KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH

Procedura działania Punktu Potwierdzającego Profile Zaufane epuap w Urzędzie Miejskim w Gdańsku

Kontrola na zakończenie realizacji projektu. Trwałość projektu

Zamieszczanie ogłoszenia: obowiązkowe. Ogłoszenie dotyczy: zamówienia publicznego. SEKCJA I: ZAMAWIAJĄCY

Regulamin Drużyny Harcerek ZHR

Komentarz technik ochrony fizycznej osób i mienia 515[01]-01 Czerwiec 2009

OSZACOWANIE WARTOŚCI ZAMÓWIENIA z dnia roku Dz. U. z dnia 12 marca 2004 r. Nr 40 poz.356

PROGRAM ZAPEWNIENIA I POPRAWY JAKOŚCI AUDYTU WEWNĘTRZNEGO

Regulamin Projektów Ogólnopolskich i Komitetów Stowarzyszenia ESN Polska

ZAPYTANIE OFERTOWE. Katowice, dnia dla potrzeb realizacji projektu: ZAMAWIAJĄCY:

Politechnika Warszawska Wydział Matematyki i Nauk Informacyjnych ul. Koszykowa 75, Warszawa

Jak usprawnić procesy controllingowe w Firmie? Jak nadać im szerszy kontekst? Nowe zastosowania naszych rozwiązań na przykładach.

Umowa nr.. /. Klient. *Niepotrzebne skreślić

Transkrypt:

Bazy danych 1 Wykład 6 Metodologia projektowania baz danych (projektowanie logiczne - Normalizacja)

Projektowanie logiczne przegląd krok po kroku 1. Usuń własności niekompatybilne z modelem relacyjnym 2. Wyznacz relacje dla logicznego modelu danych 3. Wykonaj normalizację relacji 4. Sprawdź, czy relacje umoŝliwiają realizacje transakcji. 5. Wyznacz więzy integralności. 6. Omów logiczny model danych z uŝytkownikiem.

Projektowanie logiczne (krok 2 - przypomnienie) 2. Wyznacz relacje dla logicznego modelu danych Relacje będziemy opisywać za pomocą języka definiowania bazy danych DDL (DataBase Definition Language) Definicja (uproszczona) relacji w DDL zawiera: nazwę relacji (w liczbie mnogiej), ujętą w nawiasy listę prostych atrybutów relacji, klucz główny, wszystkie klucze alternatywne i obce, nazwę relacji zawierającą wskazany klucz obcy jako klucz główny listę atrybutów pochodnych wraz z wyraŝeniami definiującymi sposób wyliczenia ich wartości.

Projektowanie logiczne (krok 2 - przypomnienie) 1. Dla kaŝdej encji tworzymy schemat relacji (reprezentacją relacji jest tabela). Najczęściej nazwa relacji jest taka sama jak nazwa encji, tylko w liczbie mnogiej ze względu na to, ze relacja zawiera wiele wystąpień obiektu. 2. Atrybuty encji stają się atrybutami w schemacie relacji. Atrybuty odpowiadające kluczom głównym stają się kluczami głównymi relacji. Atrybuty opcjonalne stają się kolumnami o dopuszczalnych wartościach NULL, atrybuty obligatoryjne stają się kolumnami NOT NULL. 3. Sposób tworzenia kluczy obcych zaleŝy od liczności (krotności) oraz uczestnictwa encji w związku.

Projektowanie logiczne (krok 2 - przypomnienie) 1. W przypadku związków jeden do jeden najczęściej tworzymy jedną relację zawierająca atrybuty obu encji 2. W przypadku związków jeden do wiele najczęściej do schematu do schematu po stronie wiele wstawiamy jako dodatkowy atrybut klucz główny z relacji po stronie jeden. 3. W przypadku związków wiele do wiele związek ten reprezentujemy dodatkową relacją, który zawiera dwa klucze obce związek reprezentujemy dodatkową relacją, który zawiera dwa klucze obce klucze główne z relacji po obu stronach związku (oraz atrybuty związku).

Normalizacja (krok 3) Aby uniknąć w bazie redundancji (powtórzeń) i związanych z nią anomalii róŝnego typu, przeprowadza się normalizacje relacji wchodzących w skład bazy. 6

ZaleŜność funkcyjna Niech R będzie schematem relacji i X,Y R Definicja Zbiór Y jest w zaleŝności funkcyjnej względem zbioru X (X Y) wtw, gdy dla kaŝdej relacji o schemacie R wartości atrybutów ze zbioru X jednoznacznie wyznaczają wartości atrybutów ze zbioru Y. 7

ZaleŜność funkcyjna - przykład Niech schemat relacji R określa rozkład zajęć w szkole. Ma on następujące atrybuty: N (nauczyciel),g (godzina),s (sala),k (klasa),p (przedmiot). KaŜda z krotek relacji r oznacza, Ŝe: Nauczyciel N wykładający przedmiot P prowadzi zajęcia o godzinie G w sali S z klasą K Dla tego schematu określamy następujące zaleŝności funkcyjne: dany nauczyciel o danej godzinie prowadzi zajęcia tylko z jedną klasą - NG K o danej godzinie w danej sali znajduje się tylko jeden nauczyciel - GS N 8

ZaleŜność funkcyjna Sformułowanie zaleŝności funkcyjnych oznacza ustalenie pewnych związków między atrybutami odzwierciedlających związki między odpowiednimi obiektami w świecie rzeczywistym. Wybór zaleŝności funkcyjnych nie pozostaje bez wpływu na organizację danych. Np.. ustalenie zaleŝności N P oznacza, Ŝe Ŝaden nauczyciel nie będzie mógł wykładać kilku przedmiotów. 9

Klucz relacji Definicja Zbiór atrybutów X tworzy klucz, gdy: wszystkie pozostałe atrybuty są funkcyjnie zaleŝne od atrybutów X; jest to minimalny taki zbiór, tzn. nie istnieje podzbiór właściwy zbioru X wyznaczający funkcyjnie pozostałe atrybuty relacji. 10

Klucz relacji Niech F będzie zbiorem zaleŝności funkcyjnych dla schematu relacji R. Definicja ZaleŜność funkcyjna X Y wynika logicznie ze zbioru zaleŝności F (F = X Y), jeśli kaŝda relacja o schemacie R spełniająca wszystkie zaleŝności funkcyjne z F spełnia równieŝ zaleŝność X Y. 11

Domknięcie zbioru zaleŝności Definicja Domknięciem F + zbioru F zaleŝności funkcyjnych dla schematu relacji R nazywamy zbiór wszystkich zaleŝności funkcyjnych wynikających logicznie ze zbioru F. 12

ZaleŜności trywialne Definicja ZaleŜność funkcyjna X Y jest trywialna, gdy Y X, nietrywialna, gdy Y X i Y X, 13

Rozkład schematu relacji ZaleŜność od klucza jest jedyną zdrową zaleŝnością funkcyjną i najlepiej by było, Ŝeby kaŝda relacja reprezentowała tylko jedną taką zaleŝność funkcyjną. ZaleŜność nie od klucza wprowadza wewnętrzną zaleŝność między atrybutami, moŝliwość przewidywania wartości jednych atrybutów przez inne, co oznacza redundancję. Usunięcie z relacji anomalii i redundancji odbywa się poprzez podział (rozkład) relacji na kilka nowych. 14

Rozkład schematu relacji Definicja Rozkładem schematu relacji R nazywamy rodzinę {R i } i {1,...,k} podzbiorów R taką, Ŝe R=R 1... R k. Krotki relacji o schemacie R i otrzymujemy poprzez rzutowanie relacji o schemacie R na zbiór atrybutów R i : r i = Π Ri (r) Rozkład schematu nie moŝe być byle jaki, powinien on być poprawny, tzn. zachowywać informację i zaleŝności funkcyjne wyjściowego schematu.

Rozkład odwracalny (bezstratny) Definicja Rozkład R=Q S jest odwracalny względem F wtw gdy kaŝda relacja o schemacie R i spełniająca zaleŝności z F jest złączeniem naturalnym swoich rzutów na Q i S 16

Rozkład zachowujący zaleŝności funkcyjne Definicja Rozkład R=Q S zachowuje zbiór zaleŝności F, jeśli wszystkie zaleŝności naleŝące do F wynikają logicznie z sumy wszystkich zaleŝności naleŝących do rzutów zbioru F na Q i S. 17

Postacie normalne Pojęcie postaci normalnej wprowadził Codd. Zaproponował on trzy postacie normalne: pierwszą (1NF), drugą (2NF) i trzecią (3NF). Kolejnymi postaciami normalnymi są postać normalna Boyce a-codda (BCNF), czwarta postać normalne (4NF) i złączeniowa postać normalna (5NF). Najczęściej najbardziej poŝądaną jest postać normalna Boyce a-codda. 18

Postać Boyce a-codda Definicja Schemat relacji jest w BCNF wtw, gdy dla kaŝdej zaleŝności X A F + zachodzi jeden z przypadków: A X (czyli jest to zaleŝność trywialna) X jest nadkluczem Jeśli schemat jest w BCNF, nie ma redundancji, tzn. nie moŝna przewidzieć jednych wartości w oparciu o inne. 19

Postać Boyce a-codda Przykład. Niech R = {M (miasto), U (ulica), K (kod)} i F = {MU K, K M}. Schemat nie jest w BCNF, gdyŝ są dwa klucze: {M, U} i {K, U} i nie są spełnione warunki definicji dla zaleŝności K M (K nie jest nadkluczem). Twierdzenie KaŜdy schemat albo jest w BCNF albo daje się rozłoŝyć na sumę schematów relacji w BCNF z zachowaniem informacji (ale niekoniecznie z zachowaniem zaleŝności). 20

Trzecia postać normalna Definicja Schemat relacji jest w 3NF wtw, gdy dla kaŝdej zaleŝności X A F + zachodzi jeden z przypadków: A X (zaleŝność trywialna), X jest nadkluczem, A jest atrybutem kluczowym (naleŝy do co najmniej jednego klucza). 21

Trzecia postać normalna Uwaga: Schemat relacji w BCNF jest w 3NF, ale nie odwrotnie Przykład. Niech R = {M (miasto), U (ulica), K (kod)} i F = {MU K, K M}. Są dwa klucze: {M,U} i {K,U}. Schemat jest w 3NF ({M, U} jest nadkluczem a M jest atrybutem kluczowym). Twierdzenie KaŜdy schemat relacji daje się rozłoŝyć na sumę schematów relacji w 3NF z zachowaniem informacji i zaleŝności funkcyjnych. 22

Druga postać normalna Definicja ZaleŜność funkcyjna X A jest zaleŝnością częściową, gdy X jest właściwym podzbiorem pewnego klucza. Definicja ZaleŜność funkcyjna X A jest zaleŝnością przechodnią, gdy X nie jest właściwym podzbiorem Ŝadnego klucza. Definicja Schemat relacji jest w 2NF wtw, gdy nie zawiera zaleŝności częściowych. 23

Druga postać normalna Przykład. Schemat relacji w BCNF i 3NF jest w 2NF. Przykład. Niech R={A, B, C, D} i F={AB C, AC D}. Jedynym kluczem jest {A, B}. Schemat nie jest w 3NF (D nie jest atrybutem kluczowym). W schemacie nie ma zaleŝności częściowych. Schemat jest w 2NF. W schemacie istnieje zaleŝność przechodnia: AC D. Przykład. Niech R={A, B, C, D} i F={AB C, B D, BC A}. Jedynymi kluczami są {A, B} i {B, C}. D jest atrybutem niekluczowym i {B} jest podzbiorem właściwym klucza, więc zaleŝność B D jest zaleŝnością częściową. Schemat nie jest w 2NF. Twierdzenie Schemat relacji jest w 3NF wtw, gdy jest w 2NF i nie zawiera zaleŝności przechodnich. 24

Pierwsza postać normalna Definicja Schemat relacji jest w 1NF wtw, gdy jego atrybuty przyjmują wartości atomowe (wartości atrybutów nie są zbiorami). 25

Postacie normalne - przykład Hodowca zaproponował następujący schemat bazy danych: Hodowle (Nr_strusiarni, Liczba_strusi, Imię_strusia, Płeć_strusia, Wiek_strusia,Opiekun_strusiarni, Nazwisko_opiekuna, Imię_opiekuna) 1. Nr_strusiarni Liczba_strusi 2. Nr_strusiarni Opiekun_strusiarni 3. Imię_strusia, Nr_strusiarni Płeć_Strusia 4. Imię_strusia, Nr_strusiarni Wiek_Strusia 5. Opiekun_strusiarni Nazwisko_opiekuna, Imię_opiekuna

Normalizacja (krok 3) Projekt logiczny (po wykonaniu normalizacji) nie musi być projektem ostatecznym. Jeśli wymagają tego kryteria dotyczące wydajności, projekt fizyczny moŝe się róŝnić od logicznego jedną z moŝliwości jest denormalizacja niektórych relacji. Normalizacja słuŝy udoskonaleniu modelu danych tak, aby spełniał szereg warunków pozwalających uniknąć duplikowania danych, dzięki normalizacji model lepiej odwzorowuje informacje modelowanego przedsiębiorstwa, staje się spójny, zapewnia minimum redundancji i maksimum stabilności.

Realizacja transakcji (krok 4) Sprawdź, czy relacje umoŝliwiają realizacje transakcji Celem tego kroku jest sprawdzenie, czy logiczny model danych umoŝliwia wykonanie transakcji opisanych w specyfikacji wymagań uŝytkownika. W kroku tym próbujemy wykonać manualnie poszczególne operacje zawarte w transakcjach, korzystając z relacji, powiązań między kluczami głównymi i obcymi relacji.

Więzy integralności (krok 5) Wyznacz więzy integralności Więzy integralności to dodatkowe warunki, których spełnienie zapobiega niespójności bazy danych. Na tym etapie koncentrujemy się na wysokopoziomowym opisie specyfikującym, jakie więzy integralności powinny być spełnione, niezaleŝnie od tego, w jaki sposób zapewniona będzie ich realizacja. Po ustaleniu więzów integralności logiczny model danych moŝna uznać za kompletna reprezentacje rzeczywistości.

Więzy integralności RozwaŜamy pięć typów więzów integralności: wymagana obecność danych niektóre atrybuty nie powinny zawierać wartości pustych; więzy tego typu powinny być ustalone na etapie dokumentowania informacji o atrybutach w słowniku danych. więzy dziedzin atrybutów z kaŝdym atrybutem związana jest dziedzina, czyli zbiór dopuszczalnych wartości; wiązy tego typu naleŝy ustalić wraz z wyborem dziedzin atrybutów. integralność encji klucz główny encji nie moŝe przyjmować wartości pustych; ograniczenie to naleŝy uwzględnić przy wyborze klucza głównego dla danego zbioru encji.

Więzy integralności więzy ogólne są nazywane regułami biznesowymi (lub zasadami działania); reguły te wynikają z zasad obowiązujących w opisywanym przez nie fragmencie świata rzeczywistego, np. Promotor moŝe prowadzić 10 prac dyplomowych studentów integralność referencyjna klucz obcy wiąŝe krotkę relacji podrzędnej z krotką relacji nadrzędnej o pasującej wartości klucza kandydującego; integralność referencyjna oznacza, Ŝe jeśli wartość klucza obcego jest określona, to wartość ta musi odpowiadać istniejącej krotce w relacji nadrzędnej.

Więzy integralności Integralność referencyjna Przykład: Personel Nr_Pracownika <pk> Zarządza Nieruchomość Nr_Nieruchomosci Nr_Pracownika <pk> <fk> Atrybut Nr_Pracownika w relacji Nieruchomość wiąŝe nieruchomość do wynajęcia z krotką w relacji Personel zawierającą dane pracownika zarządzającego daną nieruchomością. Jeśli wartość Nr_Pracownika (w relacji Nieruchomość) jest określona, to powinna ona zawierać poprawny numer pracownika, występujący jako wartość Nr_Pracownika w relacji Personel.

Więzy integralności Integralność referencyjna Pierwszym problemem jest kwestia, czy dozwolone są wartości puste klucza obcego. W przypadku opcjonalnego uczestnictwa relacji podrzędnej wartości puste są dozwolone, np. dopuszczamy moŝliwość przechowywania informacji o nieruchomości do wynajęcia bez podania pracownika zarządzającego tą nieruchomością W przypadku obowiązkowego uczestnictwa relacji podrzędnej wartości puste nie są dozwolone, np. nie dopuszczamy moŝliwości przechowywania informacji o nieruchomości do wynajęcia bez podania pracownika zarządzającego tą nieruchomością

Więzy integralności Integralność referencyjna Kolejnym problemem jest sposób zapewnienia integralności referencyjnej. Operacje na bazie danych mogą naruszyć więzy referencyjne. Przypadek 1. Wstawienie krotki do relacji podrzędnej dla zachowania integralności referencyjnej konieczne jest sprawdzenie, czy klucz obcy w relacji podrzędnej ma wartość pusta lub jest równy wartości występującej w jednej z krotek relacji nadrzędnej Przypadek 2. Usunięcie krotki z relacji podrzędnej nie narusza integralności referencyjnej Przypadek 3. Modyfikacja klucza obcego krotki w relacji podrzędnej sytuacja podobna do przypadku 1

Więzy integralności Integralność referencyjna Przypadek 4. Wstawienie krotki do relacji nadrzędnej nie narusza integralności referencyjnej Przypadek 5. Usunięcie krotki z relacji nadrzędnej moŝe naruszyć integralność referencyjną w przypadku, gdy w relacji podrzędnej występuje krotka wskazującą na usuniętą krotkę nadrzędną (patrz dalej) Przypadek 6. Modyfikacja klucza głównego krotki nadrzędnej - moŝe naruszyć integralność referencyjną w przypadku, gdy w relacji podrzędnej występuje krotka wskazującą na wartość klucza głównego sprzed modyfikacji (patrz dalej)

Więzy integralności Integralność referencyjna W przypadku 5 i 6 moŝna wybrać kilka moŝliwości: NO ACTION lub RESTRICT - uniemoŝliwia usunięcie (modyfikację) krotki z relacji nadrzędnej jeśli występują jakiekolwiek krotki od niej zaleŝne. CASCADE usunięcie (modyfikacja) krotki nadrzędnej pociąga za sobą usunięcie (modyfikację) wszystkich związanych z nią krotek podrzędnych; jeśli krotka podrzędna pełni rolę nadrzędną w innym związku, analogiczna operacja usuwania (modyfikacji) powinna być wykonana dla krotek podrzędnych tego związku. SET NULL usunięcie krotki nadrzędnej pociąga za soną automatyczne nadanie wartości pustych odpowiednim kluczom obcym wszystkich krotek SET DEFAULT usunięcie krotki nadrzędnej pociąga za soną automatyczne nadanie wartości domyślnych odpowiednim kluczom obcym wszystkich krotek podrzędnych.

Nieruchomość( nieruchomośćnr NumerNieruchomości NOT NULL ulica Ulica NOT NULL miasto Miasto NOT NULL typ TypNieruchomości NOT NULL DEFAULT F pokoje NieruchomośćPokoje NOT NULL DEFAULT 4 czynsz NieruchomośćCzynsz NOT NULL DEFAULT 600 właścicielnr NumerWłaściciela NOT NULL pracowniknr NumerPracownika NOT NULL biuronr NumerBiura NOT NULL kaucja NieruchomośćCzynsz NOT NULL PRIMARY KEY (nieruchomośćnr) ALTERNATE KEY (ulica, miasto) FOREIGN KEY (pracowniknr) REFERENCES Personel(pracownikNr) ON UPDATE CASCADE ON DELETE SET NULL FOREIGN KEY (właścicielnr) REFERENCES WłaścicielPrywatny(właścicielNr) and WłaścicielInstytucjonalny(właścicielNr) ON UPDATE CASCADE ON DELETE NO ACTION DERIVED kaucja (czynsz*0,1)

Dziękuj kuję za uwagę!!!