Podstawy teorii baz danych

Transkrypt

Wykłady z przedmiotu Podstawy baz danych – Podstawy teorii baz danych. Model relacyjny – dr hab. prof. UŁ. Tadeusz Antczak
Podstawy teorii baz danych
Literatura dotycząca (teorii) baz danych
•
•
•
•
•
•
•
•
•
•
P.Benyon-Davies, Systemy baz danych, Wydawnictwo Naukowo-Techniczne, Warszawa 1998.
T.Connolly, C.Begg, Systemy baz danych. Praktyczne metody projektowania, implementacji i zarządzania, t.1, RM, 2004.
T.Connolly, C.Begg, Systemy baz danych. Praktyczne metody projektowania, implementacji i zarządzania, t.2, RM, 2004.
C.J.Date, Wprowadzenie do baz danych, (seria: Klasyka informatyki) WNT Warszawa 2000
R.Elmasri, S.B.Navathe, Wprowadzenie do baz danych, Helion 2005
M.J.Hernandez, Bazy danych dla zwykłych śmiertelników, Wyd. EDU-MIKOM, Warszawa 1998.
J.D.Ullman i J.Widom, Podstawowy wykład z systemów baz danych, WNT Warszawa 2000
J.D.Ullman, Systemy baz danych (tłum. z jęz. ang.), Wydawnictwa Naukowo-Techniczne, Warszawa 1988.
M. J. Hernandez, Projektowanie baz danych dla każdego. Przewodnik krok po kroku. Helion 2014
B.Jankowski, A.Regmunt, Bazy danych uczymy się na przykładach, MIKOM, cena 38,60 zł
Literatura dotycząca Microsoft Access
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Danuta Mendrala, Marcin Szeliga, Access 2013 PL. Kurs. Helion 2013
Lambert Joan, Cox Joyce, Microsoft Access 2013. Krok po kroku, Microsoft 2013
Danuta Mendrala, Marcin Szeliga, Access 2010 PL. Kurs. Helion 2010
Danuta Mendrala, Marcin Szeliga, Access 2010 PL. Ćwiczenia praktyczne. Helion 2010
Michael R. Groh, Access 2010. Biblia. Helion 2013
Curtis D. Frye, Microsoft Access 2010 PL. Praktyczne podejście, Helion
Danuta Mendrala, Paweł Szeliga, Access 2007PL. Ćwiczenia praktyczne,
Michale Groh, Joseph C.Stockman, Gavin Povell, Access 2007. Biblia, grudzień 2007,
Danuta Mendrala, Paweł Szeliga, Access 2007PL. Kurs, luty 2007,
Matthew McDonald, Nieoficjalny podręcznik Access 2007 PL, lipiec 2007,
Andrew Unsworth, Access 2007. Seria praktyk, kwiecień 2009,
Paul McFedries, Access 2007 PL. Formuły, raporty, kwerendy. Rozwiązania w biznesie, lipiec 2009,
Ken Bluttman, Wayne Freeze, Access. Analiza danych. Receptury, maj 2008,
Maciej Groszek, ABC Access 2007, kwiecień 2007,
Helen Feddeman, Microsoft Access. Podręcznik administratora, czerwiec 2006,
Tomasz Nabiałek, ABC 2007 Accessa, Wydawnictwo Edition, grudzień 2006,
Bogdan Krzymowski, Access 2007 PL poradnik dla nieinformatyków, Wyd. HELP, czerwiec 2007,
Steve Lambert, M. Dow Lambert III, Joan Preppernau,, Microsoft Office Access 2007 wersja polska Krok po kroku,
Wydawnictwo READ ME / EREMIS październik 2007,
Mirosław Sławik, Microsoft Access 2007 dla każdego, Wydawnictwo Videograf 2007,
Zarys historii baz danych
 Pierwsze próby użycia komputerów do przechowywania i przetwarzania dużych zasobów informacyjnych – od
razu zaznaczyły się dwa kierunki:

pierwszy, bardzo pragmatyczny, sprowadzał się do budowania konkretnych, zamówionych przez
użytkownika systemów, np. do obsługi rachunków banku czy do automatyzacji katalogów w bibliotece

drugi kierunek wyznaczały prace o charakterze narzędziowym. Celem tworzonych środków było
dostarczenie projektantom systemów informacyjnych narzędzi ułatwiających budowanie takich systemów
(język programowania COBOL).
 Najwcześniejsze znane użycie terminu „data base” miało miejsce w listopadzie 1963 r. – pojawiło się w ramach
sympozjum naukowego o nazwie ”Development and Management of a Computer-centered Data Base”
 Termin „Database” jako pojedyncze słowo pojawiło się w Europie we wczesnych latach 70-tych poprzedniego
stulecia i przy końcu tej dekady zostało użyte w większości amerykańskich czasopism ( DB jest oczywiście skrótem).
 Lata sześćdziesiąte przyniosły ogromny wzrost zainteresowania skomputeryzowanymi systemami baz danych, co
wynikało m.in. z wprowadzenia na rynek komputerów rodziny IBM 360, znacznie lepiej przystosowanych do
przetwarzania informacji nienumerycznych niż wcześniejsze maszyny.

potrzeba posiadania przez projektantów systemów baz danych uniwersalnych narzędzi do możliwie szybkiego
tworzenia różnorakich baz danych, bez potrzeby budowania oprogramowania dla każdej nowozakładanej baz,
1
Opracowanie: dr hab. prof. nadzw. Tadeusz Antczak

oddzielenie sposobu postrzegania bazy danych przez użytkownika od jej realizacji na poziomie struktur i
operacji wewnętrznych komputera
-
poziom logiczny – poziom, z którego na bazę patrzy użytkownik,
-
poziom fizyczny – poziom związany z samym komputerem,
-
niezależność bazy danych – jakiekolwiek zmiany na poziomie fizycznym nie powinny wpływać na
logiczny obraz bazy danych,
 Pierwszy system zarządzania bazą danych (SZBD) został utworzony na początku lat 60-tych. Był nim utworzony
w General Electric w 1961 r. Integrated Data Store IDS – początki sieciowego modelu baz danych.
 Druga poł. lat 60-tych – wprowadzenie modelu hierarchicznego - Information Management System IMS (IBM).
 1970 r. – wprowadzenie przez Edgara Coda (IBM) podstaw modelu relacyjnego – dr Edgar F.Codd – artykuł w
czerwcowym numerze pisma „Communications of the ACM” o tytule „Relacyjny model danych dla dużych banków
danych współużytkowanych”, w którym zostały nakreślone główne idee stworzonego przez niego relacyjnego
modelu baz danych

ważny jest sposób organizacji struktur danych i dostępu do nich, programy zaś są tylko środkami
prowadzącymi do realizacji tego celu
 1971r. – utworzenie standardu sieciowego modelu baz danych (CODASYL).
 1973 r. - pierwszy system zarządzania relacyjną bazą danych (System R w firmie IBM).
 1974 r. - IBM, San Jose – Structured English Query Language SEQUEL (prototyp SQL)
 1977 r. - firma Relational Software (później Oracle) wprowadziła na rynek pierwszą komercyjną wersję systemu
zarządzania relacyjną bazą danych, tj. pierwszy komercyjny serwer baz danych oparty na SQL.
 1987 r. - pierwszy standard języka SQL (ISO 9075).
 lata 80-te – prace dotyczące modelu obiektowego i dedukcyjnego baz danych
 lata 90- te - rozszerzenie baz danych o nowe aspekty: architektury wielowarstwowe, bazy z wykorzystaniem
Internetu, rozproszenie, równoległość, hurtownie danych, OLAP, multimedia, GIS (Geographical Information
Systems), bazy dokumentów (w tym XML).
Aktualne kwestie związane z rozwojem baz danych

problemy modelowania i reprezentacji danych,

zapewnienie wiarygodności i spójności danych, zwłaszcza w kontekście ich aktualizowania,

języki wyszukiwania dla różnych typów danych (tekstowych, graficznych, przestrzennych, itd.),

ochrona danych,

komunikacja człowieka z bazą danych,

poszukiwanie nowych organizacji komputerów zorganizowanych na bazy danych.
Baza danych (ang. databases)
 pojęcie sięgające wieków w dziejach ludzkości
 informacja, dane – są to pojęcia określające pewien zasób wiedzy
 w swej historii ludzie od zawsze próbowali i ciągle próbują gromadzić informację i wnioskować na jej podstawie
 komputery są jedynie narzędziami, które ułatwiają współcześnie przetwarzanie ogromnych ilości informacji
2
Określenia pojęcia bazy danych
Bazy danych to:
 zbiory danych, często dodaje się, iż odpowiednio uporządkowane.
 komputerowe reprezentacje fragmentów istniejącego (niekoniecznie fizycznie) świata rzeczywistego, który jest
przedmiotem zainteresowania użytkowników baz danych. Fragmenty te niekiedy bywają nazywane wycinkami,
światem modelowanym, światem rzeczywistym, itp.
 metoda strukturalizacji zarządzania informacją.
 zbiory danych o określonej strukturze, zapisane na zewnętrznym nośniku pamięciowym komputera, mogące
zaspokoić potrzeby wielu użytkowników korzystających z nich w sposób selektywny, w dogodnym dla siebie
czasie.
 część systemu informacyjnego – obsługuje zapotrzebowania informacyjne pewnego fragmentu rzeczywistości:
- aplikacja bazy danych (oprogramowanie) – gdy chcemy zwrócić uwagę na charakter programistyczny i
szczególne miejsce bazy danych w całej aplikacji.
- system informatyczny (sprzęt) – gdy chcemy zwrócić uwagę na ogólne środki informatyczne, a więc także
na używany sprzęt.
 „serce” Systemu Zarządzania Bazą Danych (SZDB).
Proces modelowania świata rzeczywistego
Proces przechodzenia od świata rzeczywistego do informacyjnej reprezentacji w komputerze nazywamy
modelowaniem świata rzeczywistego.
Z punktu widzenia projektanta bazy danych, w procesie modelowania świata rzeczywistego można wyróżnić
następujące etapy:
i.
wyselekcjonowanie typu informacji, jakie będą potrzebne przyszłym użytkownikom
bazy – konceptualizacja bazy danych,
ii.
zapisania ich w ustrukturalizowanej formie akceptowanej przez komputer –
utworzenie schematu danych, tj. zapisanie „skonceptualizowanego” wycinka w pewnym języku narzuconym przez
komputer (bardziej dokładnie można powiedzieć schemat danych musi być zgodny z tzw. modelem danych),
iii.
wprowadzenia do komputera konkretnych danych odzwierciedlających stan świata rzeczywistego (założenie bazy
danych).
Model danych
Model danych jest to:

spójny zestaw pojęć, który służy do opisywania danych i związków pomiędzy nimi oraz manipulowania danymi
i ich związkami, a także do wyrażania więzów nałożonych na dane w pewnym świecie modelowanym.

pewna reprezentacja wziętych ze świata rzeczywistego obiektów, zdarzeń i powiązań między nimi,

abstrakcja, która koncentruje się na istotnych, swoistych aspektach pewnego fragmentu rzeczywistości, a pomija
cechy przypadkowe.
Z tych powodów model danych musi dostarczać takiego podstawowego zbioru pojęć i oznaczeń, które pozwolą
projektantom baz danych i późniejszym ich użytkownikom na jednoznaczne i precyzyjne przekazywanie własnego
sposobu widzenia danych danego fragmentu rzeczywistości.
3
Składniki modelu danych
1.
część strukturalna – zawierająca zbiór zasad, zgodnie z którymi powinny być konstruowane bazy danych,
2.
część wykonawcza – opisująca typy dopuszczalnych operacji na danych (w tym operacji wykorzystywanych do
modyfikacji i wyszukiwania danych w bazie oraz do zmiany jej struktury),
3.
zbiór zasad integralności (część opcjonalna), które zagwarantują spójność danych.
Model danych – to pewien ustrukturalizowany, dobrze zdefiniowany sposób opisu świata rzeczywistego.
Modele baz danych

hierarchiczny – świat rzeczywisty jest opisywany za pomocą drzew,

sieciowy – świat modelowany jest opisywany za pomocą grafów,

relacyjny – wykorzystanie tabel dwuwymiarowych (relacji) do opisu fragmentów świata rzeczywistego,

obiektowy – składniki programowania obiektowego (obiekty) wykorzystane w celu opisania rzeczywistości,

logiczny (dedukcyjny) - wykorzystanie logiki, inaczej można też powiedzieć o posłużeniu się językiem
naturalnym w celu opisu rzeczywistości,

aktualnie mówi się także o modelu relacyjno-obiektowym baz danych.
Cechy baz danych
Z pojęciem bazy danych są nierozerwalnie związane przede wszystkim dwie cechy:

trwałość – dane mają być przechowywane przez pewien okres czasu, na ogół nieokreślony z góry, w odróżnieniu
od danych chwilowych – istniejących tylko w momencie działania programu,

zgodność z rzeczywistością – dane w bazie danych muszą stanowić wierne odzwierciedlenie modelowanego
fragmentu rzeczywistości, baza danych musi się też odpowiednio zmieniać. Zapewnienie zgodności z rzeczy wistością jest podstawowym procesem we współczesnych systemach informacyjnych korzystających z baz danych.
Ponadto przy budowie baz danych zwraca się też uwagę na:

kontrolowanie replikacji (powtarzania się) danych – w idealnej sytuacji jeden fakt dotyczący modelowanego
fragmentu rzeczywistości powinien być w bazie danych reprezentowany tylko na jeden sposób, jednak z
uzasadnionych powodów, np. w celu dodatkowego zabezpieczenia danych przed utratą czy w celu szybszego
dostępu do potrzebnych danych, dane mogą być, przy zastosowaniu ścisłej kontroli, zapisywane jednocześnie w
kilku miejscach,

oparcie się na jednym spójnym systemie reprezentacji danych fragmentu rzeczywistości – system ten jest
nazywany modelem danych (np. relacyjny model danych)

współbieżny dostęp do bazy przez wielu użytkowników,

zapewnienie ochrony danych,

niezależność danych – dane i procesy działające na bazie danych powinny być niezależne względem siebie, tzn.
zmiana danych (np. dodanie nowego rodzaju danych) nie powinna wymagać zmiany istniejących procesów ani
też zmiana procesów (np. dodanie nowego raportu) nie powinna pociągać za sobą zmiany istniejących danych.
Scenariusze powstawania bazy danych
1.
przyrostowy (kawałek po kawałku) – dla każdego działu lub odcinka działalności firmy (organizacji) tworzy się
osobną bazę danych i osobny system informacyjny. W sytuacji początkowego braku doświadczenia daje to
możliwość powstania w miarę szybko cząstkowych baz danych i zdobycia początkowych doświadczeń. Wadami
tego rozwiązania jest powtarzanie się informacji (stąd redundancja i niespójności), niemożliwość realizowania
4
zadań globalnych, brak pełnego obrazu stanu firmy. Cząstkowe rozwiązania mają znacznie więcej prototypów,
przed uzyskaniem pełnego, w pełni zadowalającego rozwiązania.
2.
zintegrowanego systemu – jest trudniejszy do pełnego zrealizowania, ale za to eliminuje wady poprzedniego
rozwiązania.
Pojęcie informacji i jej podstawowa cecha
Informacja ma wartość, gdy jest:
•
dokładna,
•
dostępna.
Jeśli mamy „zły” sposób poszukiwania informacji, to możemy jej nie odnaleźć i komputer nic nam nie pomoże w tym
zakresie.
Termin informacja będziemy traktować aksjomatycznie.
Podstawowa cecha informacji jest związana z ich strukturą – wyróżniamy:

informacje proste (atomowe) – czyli takie, których w danym kontekście nie można lub nie należy rozkładać na
informacje prostsze,

informacje zagregowane (złożone), które są złożeniem informacji atomowych wedle pewnych zasad.
Przykład: temperatura powietrza i ciśnienie atmosferyczne, mierzone w konkretnym miejscu oraz data ich pomiaru, są
przykładami danych atomowych. Informacje te wspólnie tworzą informację zagregowaną. Informacją zagregowaną w
jeszcze większym stopniu jest zbiór informacji o temperaturze powietrza i ciśnieniu atmosferycznym za miesiąc.
Własności informacji
 Informacje, takie jak temperatura, ciśnienie, data czy relacja kieruje w dotyczą faktów.

Pomiędzy informacjami mogą występować relacje, np. relacja kieruje pomiędzy kierowcą i jego autem.

Relacja też jest informacją i w gruncie rzeczy możemy ją traktować tak samo, jak inne typy informacji.
Proces agregowania (składania informacji w jedną całość) informacji jest zatem określaniem pewnych relacji na
informacjach.
Ważną kategorię wyznaczają takie informacje, które mają charakter reguł lub zasad, gdzie występuje element
uwarunkowania i/lub wynikania. Np. zasada:
jeśli ojciec twojego brata nazywa się X, to twój ojciec nazywa się X
jest w naszym rozumieniu informacją.
Uwaga. Będziemy przyjmować, że w większości rozważanych przypadków, iż informacje w postaci faktów mogą być
albo prawdziwe, albo nieprawdziwe, zaś relacje między informacjami zachodzić lub nie zachodzić, chociaż w życiu
codziennym spotykamy się również z sytuacjami, że nie wiemy czy informacja jest prawdziwa, czy też nie.
Termin „dane”
Przez dane rozumiemy informacje przedstawione w konkretny sposób, za pomocą takiej, a nie innej metody
reprezentacji.
Metoda reprezentacji – to pewien zbiór reguł syntaktycznych, które pozwalają tworzyć napisy (literowe, graficzne,
akustyczne, itp.) oraz zasady interpretowania tych napisów, czyli reguły semantyczne.
Modele danych, o których mówiliśmy powyżej, można traktować jako metody reprezentacji.
Dane, podobnie jak informacje, mogą być proste (atomowe) i zagregowane (złożone).
Dane a informacje
5
Informacja jest reprezentowana przez różne dane – ta sama informacja ( prosta lub zagregowana) może być
przedstawiona na różne sposoby za pomocą różnych metod reprezentacji. Tym niemniej, może się naturalnie zdarzyć,
że (syntaktycznie) różne dane mają tę samą semantykę, czyli opisują tę samą informację.
Przykład. Tę samą informację o temperaturze powietrza w określonym dniu dla danej miejscowości można
przedstawić dwojako: za pomocą pary (a,b), gdzie a oznacza datę, zaś b – liczbę w stopniach Celsjusza, lub za pomocą
punktu na wykresie w układzie współrzędnych OXY, gdzie na osiach są odpowiednio daty i liczby w stopniach
Celsjusza. Zbiór takich par z ostatniego miesiąca prowadzi do utworzenia tabelki, zaś zbiór punktów pozwala
wykreślić wykres temperatury za ten okres. Choć obie dane są dla meteorologa semantycznie równoważne, trzeba
jednak traktować jako różne obiekty, zwłaszcza wtedy, gdy chcemy dokonywać na nich jakiś manipulacji, np. nanieść
poprawki lub wykonać obliczenia. Dalsza agregacja danych może polegać na dodawaniu kolejnych miesięcy (lub
miejscowości), co prowadzi do dołączenia nowych wierszy w tabelce lub nowych wykresów na płaszczyźnie OXY.
Zauważmy, że mimo dołączania nowych informacji metoda reprezentacji się już nie zmienia.
Należy podkreślić, iż sprawą niezmiernie ważną, jest translacja danych z jednej metody reprezentacji na inną z
zachowaniem semantyki reprezentowanych informacji.
Schemat danych i jego wystąpienia
Agregowanie informacji, ujawnianie relacji, wskazywanie reguł ma na celu ustrukturalizowanie informacji lub inaczej
mówiąc utworzenie schematu danych.
W nieco dokładniejszym ujęciu za bazę danych możemy uważać kolekcję danych zorganizowanych według wzoru
określonego przez schemat danych. W konkretnej chwili czasu baza danych jest wystąpieniem (ang. instance)
schematu danych, tzn. zbiorem danych ustrukturalizowanych zgodnie z przyjętym modelem i schematem danych.
Każdy schemat może mieć wiele wystąpień, co wynika choćby z tego faktu, że do bazy można dopisywać nowe dane,
aktualizować lub usuwać dane już istniejące.
Bazę danych można również określić jako zbiór wszystkich dopuszczalnych wystąpień schematu danych.
Manipulacje na bazie danych mogą powodować, że przechodzi ona z jednego stanu do drugiego, co odpowiada
przejściu od jednego wystąpienia schematu do innego wystąpienia tego samego schematu danych. W powyższej
definicji bazy danych zostało wykorzystane określenie „dopuszczalnych”. Chodzi o to, aby dane zawarte w bazie
odzwierciedlały świat rzeczywisty, a nie wyimaginowane sytuacje.
Systemy oparte na przetwarzaniu plików
Systemy komputerowe oparte na przetwarzaniu plików były pierwszą próbą skomputeryzowania ręcznego
przetwarzania danych, które są wykorzystywane niemal przez wszystkich, nawet w domowych zastosowaniach.
W systemach opartych na tradycyjnym przetwarzaniu plików każdy użytkownik definiuje i implementuje pliki, które
są mu potrzebne do konkretnego zastosowania danego programu, i czynność ta stanowi jeden z elementów
programowania tego zastosowania.
Plik to po prostu zbiór rekordów, które zawierają logicznie ze sobą powiązane dane.
Każdy rekord zawiera zbiór logicznie ze sobą powiązanych pól, z których każde dotyczy pewnej charakterystycznej
cechy opisywanego przez rekord obiektu.
Systemy oparte na przetwarzaniu plików powstały i rozwijały się ze względu na zapotrzebowania ze strony
gospodarki na efektywny dostęp do danych.
6
Tym niemniej, zamiast założyć centralną bazę danych operacyjnych przedsiębiorstwa, zostało wybrane rozwiązanie
zdecentralizowane, w którym każdy dział firmy gromadził i nadzorował własne dane, przy wykorzystaniu do tego celu
własnych plików i własnego oprogramowania.
Przykład. Powiedzmy, iż jeden użytkownik – niech to będą kadry w pewnej firmie – jest zobowiązany do
utrzymywania pliku zawierającego informacje o pracownikach wraz z ich przebiegiem pracy zawodowej. Programy
drukujące listy pracowników i umożliwiające wpisywanie do pliku nowych informacji o przebiegu pracy zawodowej
są implementowane w postaci jednego z elementów tego zastosowania. Drugi użytkownik – dział księgowości – może
zarządzać wielkością pensji i przyznawaniem premii. Chociaż każdy z tych użytkowników jest zainteresowany
danymi na temat pracowników, to każdy z nich utrzymuje własne pliki (wraz z programami operującymi na tych
plikach), ponieważ każdy z tych użytkowników wymaga pewnych danych, które nie są definiowane w plikach innych
użytkowników. Każdy dział ma dostęp do swoich plików poprzez aplikacje napisane specjalnie dla niego. Pakiet
aplikacji każdego z działów obsługuje wprowadzanie danych, nadzoruje pliki danych oraz umożliwia generowanie
raportów spośród tych, które są dostępne w systemie.
Należy również podkreślić fakt, iż fizyczna struktura plików z danymi oraz zapisanych w nich rekordów danych jest
zdefiniowana w kodzie każdej aplikacji, a zatem dla każdego działu może być inna.
Wady systemów opartych na przetwarzaniu plików
 powielanie danych – efektem zdecentralizowanego gromadzenia danych w systemach opartych na
przetwarzaniu plików była nadmiarowość w ich definiowaniu i przechowywaniu,
 zależność danych od programu – wynika z faktu, iż fizyczna struktura i organizacja plików danych i rekordów
jest zdefiniowana w kodzie aplikacji. Fakt ten rzutuje również na to, iż zmiany w istniejącej strukturze były
zazwyczaj trudne do przeprowadzenia,
 rozproszenie i odseparowanie danych – ponieważ dane są gromadzone w odrębnych plikach, to fakt ten
implikuje, iż znacznie trudniej jest uzyskać potrzebną informację,
 niekompatybilne formaty plików – jest to konsekwencją faktu, iż struktura plików jest zapisana w kodzie
aplikacji, a zatem zależy od języka, w którym napisano aplikację. Jest oczywistym, iż brak kompatybilności
plików sprawia, iż ich jednoczesne przetwarzanie jest bardzo utrudnione,
 ograniczona liczba możliwych zapytań i aplikacji – każdy dział mógł dostosowywać zapytania i raporty do
własnych potrzeb, to mogło stwarzać sytuację, w której jeden z działów nie nadążał z pracą za innym działem.
Model relacyjny baz danych
Krótka historia modelu relacyjnego
Model relacyjny został zaproponowany przez pracownika firmy IBM pracującego wówczas dziale badań tej firmy
E.F.Codda w 1970 r. w jego pracy „A relational model of data for large shared data banks”.
Cechy relacyjnego modelu Codda:
•
opiera się na pojęciu matematycznej relacji, która nieco przypomina tabelę wartości,
•
relacje pełnią rolę podstawowych elementów składających się na konstruowane struktury,
•
jest oparty na teorii zbiorów, logice pierwszego rzędu i rachunku predykatów,
•
niezależność danych,
•
wykorzystuje języki przetwarzania danych oparte na przetwarzaniu zbiorów,
7
•
wprowadzenie narzędzi pozwalających rozwiązywać problemy semantyki, spójności i redundancji danych.
Trzy najważniejsze projekty dotyczące rozwoju modelu relacyjnego
 Pierwszym z projektów był prototypowy relacyjny SZBD o nazwie System R z IBM San José Research Laboratory
w Kalifornii, który powstał pod koniec lat siedemdziesiątych ubiegłego wieku. Jego głównym celem było
wykazanie praktycznej przydatności modelu relacyjnego poprzez zaimplementowanie jego struktur i operacji.
Przyczynił się do:
•
rozwoju strukturalnego języka zapytań SQL relacyjnych baz danych
•
stworzenia w latach siedemdziesiątych i osiemdziesiątych różnych komercyjnych, relacyjnych SZBD,
np. DB2 i SQL/DS. w firmie IBM oraz Oracle w firmie Oracle Corporation.
 Drugim takim projektem był INGRES (ang. Interactive Graphics Retrieval System) z University of California w
Berkeley. Projekt ten obejmował utworzenie prototypowego relacyjnego SZBD i dotyczył tych samych ogólnych
zagadnień modelu relacyjnego, co poprzednio omówiony projekt firmy IBM. Doprowadził do stworzenia
akademickiej wersji systemu INGRES, który przyczynił się do upowszechnienia koncepcji systemów relacyjnych.
 Trzecim projektem był system Peterlee Relational Test Vehicle, który był rozwijany w IBM UK Centre w Peterlee.
Projekt ten był bardziej o teoretyczny niż poprzednio dwa wspomniane i miał istotne znaczenie z punktu widzenia
badań nad takimi zagadnieniami, jak przetwarzanie i optymalizacja zapytań oraz rozszerzenia funkcjonalne.
Obecnie istnieje kilkaset relacyjnych SZBD, dostosowanych zarówno do dużych, wielodostępnych komputerów, jak i
do komputerów osobistych (niektóre z nich nie do końca są zgodne z definicją modelu relacyjnego.
Przykładami relacyjnych SZDB są:
 Access i FoxPro firmy Microsoft,
 Oracle firmy Oracle Coropration,
 DB2 firmy IBM,
 InterBase i Delphi firmy Borland,
 Paradox firmy Corel Corporation.
Model relacyjny
Model relacyjny definiuje:
 sposób reprezentowania danych (strukturę),
 metodę ich zabezpieczania (integralność danych),
 operacje, które mogą być na nich wykonywane (manipulowanie danymi).
Relacyjna baza danych
Relacyjną bazę danych można określić jako parę złożoną z następujących składników:
 zbioru tabel, których wiersze opisują obiekty lub związki występujące w modelowanym świecie,
 zbioru zależności semantycznych, które opisują ogólne prawidłowości (zasady, reguły) występujące w
modelowanym wycinku rzeczywistości.
Pierwszy składnik tej pary ujmuje aspekt ilościowy modelowanego świata – tabele zawierają bowiem konkretne dane
faktograficzne, np. :
nazwisko: Kowalski,
adres: 35-247 Łódź, ul. Tatrzańska 7 m.12,
telefon: 621-63-09, itd.
Drugi składnik dostarcza informacji ogólniejszych, np. :
8
numer telefonu musi być siedmiocyfrowy;
jeśli osoba jest mężczyzną, to nie może być matką, itd.
Systemy relacyjnych baz danych charakteryzują się następującymi własnościami:

wszystkie dane są reprezentowane koncepcyjnie jako zbiór wartości uporządkowanych w formie wierszy i
kolumn zwanych relacją,

wszystkie wartości są skalarne – oznacza to, że dowolna pozycja relacji na przecięciu kolumny i wiersza zawiera
zawsze jedną i tylko jedną wartość,

wszystkie operacje są wykonywane na całej relacji, a ich wynikiem jest również relacja. Taka właściwość
operacji nazywa się domknięciem.
Model relacyjny:
 wymaga jedynie, aby dane były koncepcyjnie reprezentowane przez relację.
 nie określa on wcale fizycznej reprezentacji danych - w rzeczywistości relacje nie muszą być wcale
reprezentowane fizycznie,
 jest tak zdefiniowany, iż istnienie relacji jest całkowicie niezależne od fizycznej reprezentacji danych.
Definicja relacyjnej bazy danych w terminologii matematycznej
W terminologii matematycznej – relacyjna baza danych jest zbiorem relacji.
Definicja relacji (w matematyce).
Niech dane będą zbiory Z1, Z2,…, Zn. Relacją matematyczną R nad tymi zbiorami nazywamy dowolny podzbiór
iloczynu (produktu) kartezjańskiego nad tymi zbiorami, tj.
R  Z1  Z2  …  Zn = { (z1, z2,…, zn) : zi  Zi , i = 1, 2, …, n }.
Jak wynika z powyższej definicji, relacja (n-członowa) R jest zbiorem n – elementowych ciągów, przy czym i-ty
element ciągu jest elementem zbioru Zi, i=1,2,…,n.
Nieco inną konwencję przyjmuje się w relacyjnym modelu danych. Wynika to z faktu, iż relacja powinna być
uniezależniona od uporządkowania zbiorów, nad którymi jest ona rozważana. Zamiast zatem traktować elementy
n-członowej relacji jako n-elementowe ciągi (a zatem jako funkcje f ze zbioru {1,2,…,n} w zbiór Z1  Z2  …  Zn ,
gdzie f(i)  Zi), traktuje je się jako funkcje nad pewnym n-elementowym zbiorem symboli, zwanych atrybutami. W
zbiorze tym nie musi być określona żadna relacja porządkująca.
Matematyczny opis relacji
Niech dany będzie skończony zbiór U = { A1, A2,…An}, którego elementy nazywamy atrybutami. Niech każdemu
atrybutowi A  U przyporządkowany będzie zbiór wartości DOM(A), zwany dziedziną (domeną) atrybutu A (a
zatem domena atrybutu to zbiór wszystkich możliwych wartości, jakie może przyjmować ten atrybut).
Definicja. Krotką typu U nazywamy dowolną funkcję
f: U 
{ DOM(A) : A  U }
taką, że dla dowolnego A  U, f(A)  DOM(A). Zbiór wszystkich krotek typu U oznaczamy symbolem
KROTKA(U).
Zauważmy, że w ogólnym przypadku zbiór KROTKA(A) może zawierać nieskończenie wiele elementów (krotek),
wtedy mianowicie, gdy któryś ze zbiorów DOM(A) jest zbiorem nieskończonym.
9
Definicja. Relacją (ang. relation) typu U nazywamy dowolny skończony podzbiór zbioru KROTKA(U). Zbiór
wszystkich relacji typu U oznaczamy REL(U). Relacje typu U oznaczamy symbolami R(U), S(U), T(U), … lub w
skrócie R, S, T, …, gdy wiadomo, o jaki zbiór atrybutów chodzi.
1. Relacje typu U oznaczać będziemy symbolami R(U), S(U), T(U), …. Jeśli z kontekstu wynikać będzie
jednoznacznie o jaki zbiór atrybutów chodzi, pisać będziemy w skrócie R, S, T, …
2. Krotki typu U oznaczać będziemy małymi literami alfabetu, niekiedy z indeksami, primami, itp. Np.. R(U), r1(u),
r’(U), s(U), … Jeśli z kontekstu wynikać będzie jednoznacznie typ krotki, w zapisie będziemy go opuszczać.
3. Podzbiory zbioru atrybutów U oznaczać będziemy dużymi literami z końca alfabetu, X, Y, Z, …
4. Dla zbioru atrybutów {A , B}, zamiast pisać R({A , B}), stosować będziemy zapis R(A , B).
Matematyczny opis relacji
Krotka r typu U często bywa utożsamiana z ciągiem jej wartości. Ponieważ krotka ta jest funkcją, więc ścisłe jej
przedstawienie wymaga zatem zapisu
r = {(A1,a1), (A2,a2), …,(An,an) }
gdzie ai = r(Ai), i = 1, 2, …., n. Zamiast tego często pisze się po prostu ciąg wartości {a1,a2, …,an }
Niech U = { A1, A2,…An}. Zauważmy, że krotkę r(U), ponieważ jest ona funkcją, można przedstawić ją w postaci
tabeli
r
A1
A2
 An
r (A1 ) r (A1 )  r (A n )
Każdą z takich krotek możemy przedstawić za pomocą tabeli. Ponieważ zbiory argumentów wszystkich tych krotek są
identyczne, a zatem możemy je napisać w nagłówku tabeli, a wartości poszczególnych krotek (funkcji) umieścić w
kolejnych wierszach. Uzyskujemy w ten sposób tabelaryczne przedstawienie relacji R:
R:
.
A2
 An
r1 (A 2 )  r1 (A n )
A1
r1 (A1 )
r2 (A1 ) r2 (A 2 )  r2 (A n )




rk (A1 ) rk (A 2 )  rk (A n )
Własności relacji R(U)
1.
Nazwa tabeli jest nazwą relacji, tj. R.
2.
Jeśli U jest zbiorem n-elementowym, to tabela ma n-kolumn, z których każda ma przyporządkowany jeden z
atrybutów ze zbioru U jako swoją nazwę (nie ma dwóch różnych kolumn o tej samej nazwie).
3.
Uporządkowanie kolumn tabeli nie jest istotne.
Przykład ilustrujący pojęcia krotki i relacji
Przykład. Relacja postaci U = { NA, S, NP, E }
U = { NrAlbumu, Student, NrPrzedmiotu, Egzamin}
NrAlbumu
Student
NrPrzedmiotu
Egzamin
A003
Adamiak Marta
BD003
4+
K001
Kowalski Marek
AM001
5
S004
Słowik Elżbieta
AL001
4
Struktura i własności relacji R(U)
10
 Przyjmuje się powszechnie reprezentację, przy której pojedyncza relacja jest dwuwymiarową tabelą złożoną z
kolumn i wierszy.
 Nazwa tabeli jest nazwą relacji, tj. R.
 Liczba kolumn jest z góry ustalona.
 Z każdą kolumną jest związana jej nazwa oraz dziedzina, określająca zbiór wartości, jakie mogą wystąpić w
kolumnie. W kolumnie o nazwie A  U mogą występować wartości wyłącznie ze zbioru DOM(A).
 Jeśli U jest zbiorem n-elementowym, to tabela ma n-kolumn, z których każda ma przyporządkowany jeden z
atrybutów ze zbioru U jako swoją nazwę - nazwa kolumny nie może powtórzyć się w obrębie relacji.
 Na przecięciu wiersza i kolumny znajduje się pojedyncza (atomowa) wartość należąca do dziedziny kolumny.
 Wiersze nie powtarzają się.
 Kolejność kolumn jest nieistotna.
 Kolejność wierszy jest nieistotna (są rozpatrywane jako elementy zbioru).
Przykład relacyjnej bazy danych
BIBLIOTEKA
Opis analityczny: książka jest pisana przez (jednego) autora, czytelnicy wypożyczają książki – ich dowolną liczbę.
Struktura przykładowej relacji
Dane przechowywane w tabeli (relacji). Relacja typu U: = {NK, N, I}
Czytelnicy = { NrKarty, Nazwisko, Imie }.
CZYTELNICY
NrKarty
Nazwisko
Imie
A003
Adamczyk
Marta
K001
Kowalski
Jerzy
B004
Balcerzak
Monika
M006
Modlińska
Elżbieta
…
…
…
pola
11
Rodzaje połączeń
 połączenie jeden-do-jednego – mówimy, iż relacja A jest połączona z relacją B połączeniem 1 – 1, gdy każdemu
rekordowi tabeli A odpowiada co najwyżej jeden rekord w tabeli B i każdemu rekordowi
z tabeli B odpowiada co najwyżej jeden rekord w tabeli A .
 połączenie jeden-do-wielu – mówimy, że relacja A jest połączona z relacją B połączeniem 1 – , gdy każdemu
rekordowi z tabeli A może odpowiadać dowolnie wiele rekordów w tabeli B i każdemu rekordowi
z tabeli B odpowiada co najwyżej jeden rekord w tabeli A.
 połączenie wiele-do-wielu – mówimy, że relacja A jest połączona z relacją B połączeniem  – , gdy każdemu
rekordowi z tabeli A może odpowiadać dowolnie wiele rekordów w tabeli B i każdemu rekordowi
z tabeli B może odpowiadać dowolnie wiele rekordów w tabeli A.
Zależności funkcyjne
Definicja. Zależnością funkcyjną nazywamy każdy zapis postaci
XY
gdzie X, Y  U są zbiorami krotek. Mówimy wówczas, że Y zależy funkcyjnie od X lub, że X determinuje
funkcyjnie Y. Ogólnie można powiedzieć, że zależność funkcyjna między zbiorami atrybutów X i Y istnieje wtedy,
gdy w każdym stanie istnieje pewna funkcja ze zbioru krotek typu X w zbiór krotek typu Y. W różnych stanach
funkcje te mogą być różne.
Definicja. Niech dana będzie krotka r typu U i niech X  U. Krotkę t typu X nazywamy ograniczeniem krotki r do
zbioru U, co oznaczamy t = r[X], wtedy i tylko wtedy, gdy dla każdego A  X, r(A) = t(A), czyli wtedy, gdy krotki r i
t są identyczne na zbiorze X; na zbiorze U – X mogą być różne.
Definicja. Niech dana będzie relacja R(U) i niech X, Y  U. Mówimy, że w R spełniona jest zależność funkcyjna
X  Y, co zapisujemy R |= X  Y, jeśli dla każdych dwóch krotek r1, r2  R zachodzi:
r1[X] = r2[X]  r1[Y] = r2[Y]
(*).
Schemat relacyjny a relacja
Definicja. Niech dany będzie zbiór atrybutów U i niech F będzie zbiorem zależności funkcyjnych nad U. Parę
uporządkowaną
R = (U, F)
nazywamy schematem relacyjnym o zbiorze atrybutów U i ze zbiorem F zależności funkcyjnych.
Definicja. Relacja R jest przypadkiem (ang. instance) schematu relacyjnego R = (U, F) lub, że jej schematem jest R,
co zapisujemy R| = R lub R| = (U, F), jeśli R jest typu U i spełniona jest w niej każda zależność funkcyjna X  Y  F.
Przykład. Rozważmy relację R(NK, CZ, KK, DW), która odwzorowuje informację o wypożyczeniach, przy czym
(nk, cz, kk, dw)  R oznacza, że czytelnik cz o numerze karty nk wypożyczył książkę o kodzie książki kk w dniu dw.
Niech rozważana relacja R(NK, CZ, KK, DW) ma postać:
R:
NK
CZ
KK
DW
A003 Adamczyk K1054 19 / 01/ 09
.
A003 Adamczyk K1054 22 / 03 / 09
K 001
Kowalski
A0093 04 / 04 / 09
B004
Balcerzak
12
C1077 25 / 05 / 09
Mamy bowiem, iż równość dwóch różnych krotek dla atrybutu NK pociąga za sobą równość dla atrybutu CZ.
Mogłoby się wydawać, że także dla atrybutów CZ i KK spełniony jest warunek (*) z definicji określającej
zachodzenie zależności funkcyjnej. Nie jest jednak prawdą, że KK zależy funkcyjnie od CZ (ani odwrotnie). Nie jest
to bowiem właściwość niezmiennicza tych atrybutów – dołączenie bowiem np. wiersza (A003, Adamczyk, P1098,
15/05/09) spowoduje, że warunek ten nie będzie już spełniony.
Zależności funkcyjne w zbiorze atrybutów
Przykład. Niech U = {KK, T, G, NA}, gdzie znaczenie poszczególnych atrybutów jest następujące: KK – kod książki,
która jest w bibliotece, T – tytuł książki, G – gatunek książki, NA – nazwisko autora książki.
Zbiór F zależności funkcyjnych na tym zbiorze atrybutów może być następujący:
F = { KK  {T, G}, {T, NA}  KK, KK  {T, NA} ,{KK, T}  NA }
Okazuje się, iż zamiast jednej zależności funkcyjnej KK  {T, NA} można zapisać dwie: KK  T, KK  NA, które
razem są równoważne tej pierwszej. Zauważmy ponadto, że jeśli {T, NA}  KK jest zależnością funkcyjną, to
zależnością funkcyjną jest również np. {T, G, NA}  KK.
Struktura i zawartość informacyjna tabeli KSIAZKI
KodKsiazki
KodAutor
Tytul
Gatunek
K1054
HS234
Potop
powieść historyczna
K2857
SW987
Wesele
dramat
K1059
HS234
Qvo vadis
K7651
EO1134
Nad Niemnem
K8721
BP2222
Faraon
K2233
JS7775
Kordian
dramat
...
...
...
...
Znaczenie pola KodAutor w tabeli KSIAZKI
 Jego wartości nie opisują cech książki.
 Reprezentują związek danej książki z jej autorem, o którym informacja znajduje się w innej tabeli i tylko
korzystając z tego identyfikatora możemy rozpoznać w tej innej tabeli wiersz właściwego autora oraz odczytać o
nim informacje.
 Istotne jest więc, aby ten identyfikator jednoznacznie określał danego autora – w modelu relacyjnym nie ma innej
możliwości identyfikacji wiersza, jak tylko poprzez wartości kolumn, które jednoznacznie identyfikują wiersz.
Klucz kandydujący
Polem klucza nazywamy pole lub pewną liczbę pól, które spełniają następujące własności:

nie zawierają powtarzającej się wartości (unikatowość),

nie zawierają wartości NULL,

żaden podzbiór (właściwy) pól tworzących pole klucza nie jest kluczem (nieredukowalność).
Tabela może zawierać więcej niż jeden klucz.
Atrybuty, które należą do któregoś z kluczy nazywać będziemy atrybutami kluczowymi, a te które nie należą do
żadnego z kluczy – atrybutami niekluczowymi.
13
Definicja klucza głównego
Dla każdej tabeli musi być określony jednoznaczny identyfikator nazywany kluczem głównym (podstawowym) –
ma tę samą własność, co klucz kandydujący, przy czym klucz główny jest tylko jeden, kluczy kandydujących w tabeli
może być więcej niż jeden.
Klucz główny jest wybierany arbitralnie (przez projektanta bazy danych) z kluczy kandydujących. Pozostałe klucze
zwane są kluczami alternatywnymi.
•
•
W tabeli Czytelnicy kluczem głównym jest NrKarty.
•
W tabeli Autorzy kluczem głównym jest KodAutor. Nazwisko nie może być kluczem!
•
W tabeli Ksiazki kluczem głównym jest KodKsiazki, Tytul nie może być kluczem.
W tabeli Wypozyczenia kluczem jest zbiór pól {KodKsiazki, DataWypozyczenia}
Każda tabela musi mieć dokładnie jeden klucz główny.
Kryteria wyboru klucza podstawowego
Kryteriami wyboru klucza głównego mogą być:
 minimalna liczba atrybutów,
 możliwość przewidzenia zakresu wartości klucza – ważne jest, aby klucz główny identyfikował zawsze
jednoznacznie każdą możliwą krotkę, a nie tylko te, które występują w jakimś konkretnym, skończonym zbiorze,
 niewystępowanie wśród wartości klucza wartości nieokreślonych (zerowych)
UWAGA: Jeśli jedyny możliwy klucz kandydujący ma bardzo niewygodną postać – np. składa się ze zbyt wielu pól
lub ma bardzo długie wartości – można skorzystać ze specjalnego typu danych, oferowanego przez poszczególne
systemy zarządzania bazami danych. Przykładowo, aparat bazy danych Microsoft Jet oferuje specjalnie do tworzenia
sztucznych kluczy o wartościach generowanych przez system specjalny typ danych pola tzw. Autonumerowanie, zaś
SQL Server – typ danych Identity. Pola tego typu stanowią ogromnie użyteczne narzędzie, o ile tylko nie będą
używane do jakiegoś innego celu. Są to po prostu tylko jednoznaczne etykiety (rekordów).
Natomiast w bazach Oracle mamy do tego celu specjalne obiekty tzw. sekwencje.
Matematyczny opis definicji klucza
Definicja. Niech dany będzie zbiór atrybutów U i niech F będzie zbiorem zależności funkcyjnych nad U. Parę
uporządkowaną R = (U , F) nazywamy schematem relacyjnym o zbiorze atrybutów U i ze zbiorem F zależności
funkcyjnych.
Definicja. Niech dany będzie schemat relacyjny R = (U , F). Zbiór atrybutów K  U nazywamy kluczem (ang. key)
schematu R wtedy i tylko wtedy, gdy zbiór ten spełnia następujące warunki:
a) K  U  F+ (jednoznaczna identyfikowalność)
b) X  U  F+  ~ ( X  K ) (minimalność)
gdzie symbol F+ oznacza taki najmniejszy zbiór zależności funkcyjnych, który zawiera zbiór F i jest zamknięty ze
względu na reguły wyprowadzeń, tzw. aksjomaty Amstronga.
Przykład. Niech dany będzie schemat relacyjny R = (U, F) postaci
R = ({KK, KA, T, G}, {KK{T, G}, {KK, T}  KA, {KK, T, G}  KA).
Cechę jednoznacznej identyfikowalności mają zbiory: KK, {KK, T}, {KK, T, G},
{KK, KA, T, G}. Najmniejszym z nich jest KK i to właśnie ten atrybut jest kluczem schematu R.
14
Klucz obcy
Klucz obcy jest to jedna lub więcej kolumn, których wartości występują jako wartości ustalonego klucza głównego lub
jednoznacznego w tej lub innej tabeli i są interpretowane jako wskaźniki do wierszy w tej drugiej tabeli.
W tabeli Ksiazki kluczem obcym jest KodAutor, którego wartości pochodzą z kolumny KodAutor w tabeli Autorzy.
W tabeli Wypozyczenia kluczem obcym jest NrKarty, którego wartości pochodzą z kolumny NrKarty w tabeli
Czytelnicy oraz KodKsiazki, którego wartości pochodzą z kolumny KodKsiazki w tabeli Ksiazki.
Na przykład, wartości K1054 i A003 występujące w wierszu tabeli Wypozyczenia stanowią odwołanie do wierszy w
tabeli Ksiazki i Czytelnicy, w którym są zapisane informacje o książce „Potop” i czytelniku o nazwisku „Adamczyk":
„Książka o tytule Potop jest wypożyczana przez Martę Adamczyk"
Każda tabela może mieć więcej niż jeden klucz obcy.
Więzy integralności encji, więzy integralności odwołań, więzy ogólne.
Pojęcie integralności bazy danych dotyczy poprawności i niesprzeczności przechowywanych danych. Integralność jest
zazwyczaj wyrażana w postaci więzów, czyli reguł spójności, które w bazie danych nie mogą zostać naruszone. Więzy
mogą dotyczyć pojedynczego rekordu danych lub mogą odnosić się do związku pomiędzy rekordami.
Administrator bazy danych definiuje więzy integralności, które System Zarządzania Bazą Danych (SZBD) wymusza
przestrzeganie więzów integralności.
Stan bazy danych, który nie spełnia więzów integralności, jest nazywany stanem nieprawidłowym; natomiast stan,
który spełnia wszystkie więzy integralności zdefiniowane w projekcie schematu relacyjnej bazy danych, jest
nazywany stanem prawidłowym.
Wszystkie więzy integralności powinny być definiowane na poziomie schematu relacyjnej bazy danych, jeśli
zgodność z nimi ma być wymuszana we wszystkich stanach tej bazy danych. Oznacza to, że język definiowania
danych (DDL) powinien oferować środki niezbędne do określania różnego rodzaju więzów, które będą następnie
wymuszane przez system zarządzania bazą danych.
Więzy integralności encji, więzy integralności odwołań, więzy ogólne.
Integralność (ang. integrity) łączy w sobie formalną poprawność bazy danych i procesów przetwarzania, poprawność
fizycznej organizacji danych, zgodność ze schematem bazy danych, zgodność z ograniczeniami integralności oraz z
regułami dostępu. Tak rozumiana integralność nie oznacza bynajmniej, iż baza danych prawidłowo odwzorowuje
sytuację i procesy opisanego przez nią świata zewnętrznego. Właściwszym terminem jest tu spójność (ang.
consistency), którą możemy podzielić:
• spójność fizyczna: operacje bazodanowe kończą się sukcesem,
• spójność logiczna: baza danych jest spójna fizycznie, a jej zawartość odpowiada,
schematowi bazy danych i dodatkowym ograniczeniom.
Więzy integralności są warunkami, które powinny być spełnione przez określony podzbiór danych z bazy. Spełnienie
tych warunków świadczy, iż baza danych jest w stanie spójnym. A zatem dzięki więzom integralności nie można
zmodyfikować tak bazy danych, aby znalazła się ona w stanie niespójnym.
Więzy integralności encji określają, że żadna wartość atrybutu (atrybutów) pełniącego rolę klucza głównego nie może
być pusta.
Ograniczenia klucza oraz więzy integralności encji są określane osobno dla poszczególnych relacji.
15
Więzy integralności odwołań są definiowane pomiędzy parami relacji – wykorzystuje się je do utrzymania spójności
powiązanych ze sobą krotek, które należą do tych dwóch relacji.
Można powiedzieć, że więzy integralności odwołań oznaczają, iż krotka w jednej relacji, która odwołuje się do innej
relacji, zawsze (w każdym stanie bazy danych) musi wskazywać na istniejącą krotkę tamtej relacji.
Inaczej można powiedzieć, iż jeżeli w relacji istnieje klucz obcy, to jego wartość albo musi być równa wartości klucza
głównego pewnej krotki relacji wskazywanej, albo klucz obcy musi mieć wartości puste dla wszystkich atrybutów.
Więzy ogólne – są to dodatkowe warunki poprawności danych określane przez użytkowników lub administratorów
bazy danych.
Wady relacyjnego modelu danych
 w procesie modelowania tracimy informację o tym, że w świecie rzeczywistym istnieją dwa identyczne obiekty.
Jest to konsekwencją jednej z głównych zasad relacyjnego modelu baz danych, która mówi, iż w relacji nie mogą
wystąpić dwie takie same krotki. A zatem przy ustalonym zestawie atrybutów nie jest możliwe wpisanie dwóch
rekordów o tej samej wartości. Rozwiązaniem tego problemu jest konieczność zwiększenia liczby atrybutów.
 „sztuczny” język opisu rzeczywistości – są nim dwuwymiarowe tabelki
 trudności w przechowywaniu informacji zmiennych w czasie,
 trudności w przechowywaniu informacji niepełnej,
 problemy z przechowywaniem „dużych” obiektów
16

Podstawy teorii baz danych

Transkrypt

Podobne dokumenty

Projekty z Baz Danych (wytyczne)

Bazy danych i systemy baz danych

znajomość baz danych i podstaw projektowania stron internetowych

Nowoczesnym systemom aplikacji biznesowych (ERP, CRM, E

Do ośmiu baz Internetu

Hasło strona-internetowa

technik informatyk

Plik źródłowy

Spis treści E14 - do pobrania

wiersze Tdeusza Antczaka