Relacyjne bazy danych, algebra relacji. Projektowanie i normalizacja baz danych.


Bazy relacyjne - prawie najpopularniejsze bazy danych.

W relacyjnych bazach danych wykorzystano teorię algebry relacji.
Tabele składają się z rekordów, zaś rekordy z pól ale różnica w stosunku do baz kartotekowych polega na tym, że baza może zawierać kilka tabel (lub plików)
które to  różnią się strukturą rekordów.
Pomiędzy rekordami jest określona pewna relacja porządkująca.
Możliwe jest łączenie rekordów z różnych tabel, jeśli rekordy takie mają przynajmniej jedno pole wspólne.

Relacja  - podstawowowa forma organizacji danych w bazie - zbiór rekordów (krotek)
Relacja
skończony zbiór krotek (rekordów)
r(A1,...,An) = {<a1,..,an>: a1 (- dom(A1), .. an (- dom(An)}
gdzie r(A1,..,An) jest relacją określoną na schemacie relacji R(A1,...,An)

Przykładową relacją jest
{<Kowalski, Jan, 35, 1200>, <Nowak, Piotr, 36, 2000>, <Zielińska, Anna, 25, 1400>}

Krotki relacji nie są uporządkowane, można zmieniać ich kolejność.

Relacyjną bazą danych nazywamy bazę danych w postaci tabel połączonych relacjami.

Dane przechowywane w wielu tabelach, pomiędzy tabelami tworzone są specjalne powiązania zwane relacjami..
Relacje - powiązania  tworzone są pomiędzy odpowiednimi polami rekordów róznych tabel.
Relacje tworzy się pomiędzy tabelami baz danych za pomocą klucza podstawowego jednej tabeli i odpowiedniego klucza obcego drugiej tabeli.

Relacja - powiązanie miedzy tabelami BD za pomocą klucza podstawowego jednej tabeli i  klucza obcego drugiej tabeli

Tabelą w bazie danych nazywamy zbiór rekordów opisujących obiekty np. pracownicy zawierających informacje o tych obiektach w sposób ujednolicony.
Rekord – pojedynczy wiersz w tabeli.
Polem nazywamy najmniejszą część rekordu, która przechowuje jedną daną.

Baza danych składa się z tabel, tabele składają się z rekordów, rekordy składają się z pól.
Pola mogą przechowywać elementarne dane, które są niepodzielne, czyli zakładamy, że mniejszych jednostek danych nie ma.

Typ danej (ang. data type) - rodzaj danej, czyli forma zapisu informacji:

Klucz relacji
taki zbiór identyfikujący relacji, którego żaden podzbiór nie jest zbiorem identyfikujacym relacji
Wyróżnia się klucze proste i złożone.
Klucz jest kluczem prostym, jeśli zbiór identyfikujący relacji jest zbiorem jednoelementowym, w przeciwnym razie klucz jest złożony.
W ogólności, w relacji można wyróżnić wiele kluczy, które nazywamy kluczami potencjalnymi.
Wybrany klucz spośród kluczy potencjalnych nazywamy kluczem głównym.

Aby w bazie mozliwe było szybkie wyszukiwanie i łaczenie danych z tabel, każdy rekord tabeli powinien zawierać pole za pomocą którego byłby jednoznacznie identyfikowany w bazie.
Pole tego typu nazywamy kluczem podstawowym.
Rekord może być też identyfikowany na podstawie kombinacji kilku pól - klucz podstawowy wielopolowy

Klucz podstawowy (ang. primary key field)

Klucz podstawowy (ang. primary key) zwany też kluczem głównym to jedno lub więcej pól, których wartość jednoznacznie identyfikuje każdy rekord w tabeli.
Taka cecha klucza nazywana jest unikatowością.
Klucz podstawowy służy do powiązania rekordów w jednej tabeli z rekordami z innej tabeli.
Klucz podstawowy jest nazywany kluczem obcym, jeśli odwołuje się do innej tabeli.
Na przykład, w bazie pracowników kluczem podstawowym może być numer ewidencyjny pracownika.

Klucz podstawowy jednopolowy (ang. single primary key)

Jeśli istnieje pole zawierające dane unikatowe, jak na przykład numer katalogowy czy numer identyfikacyjny, można je zadeklarować jako klucz podstawowy.
Jeśli jednak w polu tym powtarzają się wartości, klucz podstawowy nie zostanie ustawiony.
Aby znaleźć rekordy zawierające te same dane, należy usunąć rekordy o powtarzających się wartościach bądź zdefiniować wielopolowy klucz. podstawowy.
Klucz podstawowy wielopolowy zwany też kluczem złożonym (ang.composed key)
W sytuacji, gdy żadne z pól nie gwarantuje unikatowości wartości w nim zawartych, należy rozważyć możliwość utworzenia klucza podstawowego złożonego z kilku pól.

Klucz obcy to nazwa pola, które w jednej tabeli jest kluczem podstawowym a w drugiej jest polem łączącym te tabele.
Np. NRUcznia jest kluczem podstawowym w tabeli Uczniowie a w tabeli Oceny jest kluczem obcym


Relacja (ang.relation), typy relacji

Po podzieleniu danych na tabele i zdefiniowaniu pól kluczy podstawowych trzeba wprowadzić do systemu bazy danych informacje na temat sposobu poprawnego
łączenia powiązanych danych w logiczną całość.
W tym celu definiuje się relacje między tabelami.
Relacja - powiązanie miedzy para tabel za pomocą klucza podstawowego jednej tabeli i odpowiadającego mu klucza obcego drugiej tabeli.

Typy relacji (ang.relation types)

Relacje w BD moga być typu:

1. relacja jeden-do-jednego

W relacji jeden-do-jednego każdy rekord w tabeli A może mieć tylko jeden dopasowany rekord z tabeli B, i tak samo każdy rekord w tabeli B może mieć tylko jeden dopasowany rekord z tabeli A. Ten typ relacji spotyka się rzadko, ponieważ większość informacji powiązanych w ten sposób byłoby zawartych w jednej tabeli.
Relacji jeden-do-jednego można używać do podziału tabeli z wieloma polami, do odizolowania części tabeli ze względów bezpieczeństwa,
albo do przechowania informacji odnoszącej się tylko do podzbioru tabeli głównej.

2. Relacja jeden-do-wielu

Relacja jeden-do-wielu jest najbardziej powszechnym typem relacji.
W relacji jeden-do-wielu rekord w tabeli A może mieć wiele dopasowanych do niego rekordów z tabeli B, ale rekord w tabeli B ma tylko jeden dopasowany rekord w tabeli A.

3. Relacja wiele-do-wielu

W relacji wiele-do-wielu, rekord w tabeli A może mieć wiele dopasowanych do niego rekordów z tabeli B i tak samo rekord w tabeli B może mieć wiele dopasowanych do niego rekordów z tabeli A. Jest to możliwe tylko przez zdefiniowanie trzeciej tabeli (nazywanej tabelą łącza), której klucz podstawowy składa się z dwóch pól z  kluczy obcych z tabel A i B.
Relacja wiele-do-wielu jest w istocie dwiema relacjami jeden-do-wielu z trzecią tabelą.
Na przykład, tabele "Zamówienia" i "Produkty" są powiązane relacją wiele-do-wielu zdefiniowaną przez utworzenie dwóch relacji jeden-do-wielu z tabelą "Opisy zamówień".


ALGEBRA RELACJI

Model baz danych relacyjnych charakteryzuje się 3 podstawowymi składowymi:

Podstawową strukturą danych modelu relacyjnego jest relacja -
podzbiór iloczynu kartezjańskiego wybranych dziedzin (tj. zbiorów dopuszczalnych danych), przedstawiona w postaci 2-wymiarowej tablicy.

Relacja - skończony zbiór krotek  (typles) posiadających taką samą strukturę danych i różne wartości, przedstawionych w postaci wierszy tablicy.

Każda krotka zawiera wartosć co najmniej jednego atrybutu o określonej dziedzinie, przedstawionego w postaci kolumny tablicy.


Własności relacji:
Do operowania na danych relacyjnej bazy używa się zwykle języka deklaratywnego (nieproceduralnego), który składa się z 2 komponentów:

Strukturą pochodną do relacji jest perspektywa (view) - okno przez które odczytujemy lub modyfikujemy dane w relacji lub zbiorze relacji.
Perspektywy stosujemy w celu:
ograniczenia dostępu do relacji bazy danych
uproszczenia zapytania
zapewnienia niezalezności danych w stosunku do aplikacji i zapytań ad hoc.

Operacje na realacjach

Operatory relacyjne:

Operacje relacyjne

Na 3 pierwszych operacjach: selekcji, projekcji i połączeniu opiera się tzw. język manipulowania danymi,
umożliwiający użytkownikom baz danych dokonywanie przekształceń relacji, wynikających z potrzeb.

Zazwyczaj użytkownicy żądają dostępu do innych relacji niż te, które są przechowywane.
Zrealizowanie takiego żądania wymaga przekształcenia relacji przechowywanych w bazie danych w relacje określone w żądaniu. 

Tak utworzone relacje mogą być "pionowymi" lub "poziomymi" podzbiorami innych relacji, tzn. relacjami powstałymi przez usunięcie niektórych atrybutów lub krotek,
bądź mogą być wynikiem połączenia różnych relacji w jedną.

Operacja projekcji   - podzbiór pionowy

Operacją projekcji relacji r(A1,...,An) na zbiorze atrybutów X=(Ai,..,Aj), co zapisujemy Px r(A1,...,An), nazywamy przekształcenie relacji r(A1,...,An) w relację wynikową postaci:
Px r(A1,...,An) = {t[X] : t(- r(A1,...,An)}

Operacja projekcji umożliwia utworzenie "pionowego" podzbioru relacji przez wybór określonych atrybutów (pól).

Relacja KIEROWNICY_DZIALOW
Id_Kierownika Nazwisko Id_Dzialu Zarobki Adres_Dzialu
1 Wałecki 1 2500 Poznań, ul. Strzelecka 5
2 Kościański 2 1800 Pniewy, ul. Prosta 3
6 Pietras 3 2300 Poznań, ul. Kórnicka 30

Wynik operacji projekcji PId_Kierownika, Nazwisko, Zarobki KIEROWNICY_DZIALOW:

Wynik projekcji relacji KIEROWNICY_DZIALOW
Id_Kierownika Nazwisko Zarobki
1 Wałecki 2500
2 Kościański 1800
6 Pietras 2300

W systemach zarządzania danymi operacja ta jest formułowana za pomocą poleceń manipulowania danymi.
Np. w dBasee służą do tego polecenia LIST i DISPLAY.

Operacja selekcji  - wybór krotek spełniających określone warunki - podzbiór poziomy

Operacją selekcji relacji r(A1,...,An) względem kryterium selekcji E, co zapisujemy sEr(A1,...,An), nazywamy przekształcenie relacji r(A1,...,An) w relację wynikową postaci
sEr(A1,...,An) = {t : t(- r(A1,...,An) i E(t) = prawda}

Operacja selekcji umożliwia utworzenie "poziomego" podzbioru relacji przez wybór krotek (rekordów) spełniających określony warunek.

Wynik operacji selekcji sId_Dzialu <= 3 .AND. Zarobki >= 2000 KIEROWNICY_DZIALOW

Id_Kierownika Nazwisko Id_Dzialu Zarobki Adres_Dzialu
1 Wałecki 1 2500 Poznań, ul. Strzelecka 5
6 Pietras 3 2300 Poznań, ul. Kórnicka 30

W języku naturalnym można tę operację sformułować następująco:
"Z relacji KIEROWNICY_DZIALOW wybierz informacje o kierownikach tych działów, których identyfikatory są mniejsze lub równe 3 i zaronbki są większe równe 2000".

Operacja połączenia

Operacja połączenia polega na scaleniu odpowiednich krotek (rekordów) 2 różnych relacji pod warunkiem spełnienia warunku logicznego q nałożonego na atrybuty połączeniowe.
Warunkiem - równość atrybutów w obu relacjach

Np. może byc operacja połączenia PRACOWNICY qWYDZIALY, gdzie q ma postać:
Id_Wydzialu = Id_Wydzialu

Iloczyn kartezjański
Umozliwia konkatenację krotek 2 relacji lub wiecej, w taki sposób, że każda krotka pierwszej relacji jest łaczona z każdą krotka drugiej relacji

Projektowanie bazy danych

Dobry projekt jest podstawą utworzenia bazy danych.
  1. Określenie celu, któremu ma słuzyć BD - na tej podstawie jakie zagadnienia będa w bazie - tabele i jakie informacje - pola
  2. Określenie tabel - najtrudniejsze w procesie projektowania BD
    Podstawowe zasady projektowania:
  3. Określenie pól w tabelach
  4. Przypisanie polom jednoznacznych wartosci
  5. Określenie relacji między tabelami
  6. Wprowadzenie danych i utworzenie iinnych obiektów bazy danych

Punktem wyjścia są relacje wymagane przez użytkowników a właściwie informacje zebrane przez projektanta o wymaganych atrybutach bazy danych,
celem jest natomiast zdefiniowanie schematów relacji, które mają być przechowywane w bazie danych.
Trzeba tak zaprojektować rozdział zbioru atrybutów na schematy relacji, aby uzyskać pewne pożądane właściwości bazy danych.
Niewłaściwe zaprojektowanie schematów relacji może byc przyczyną dublowania się danych, ich niespójności i anomalii podczas ich aktualizowania.

W ramach projektowania schematów baz danych, najistotniejszą czynnością jest normalizacja relacji, czyli doprowadzenie relacji do odpowiedniej postaci normalnej.

Pierwsza postać normalna jest immanentną cechą relacji, gdyż wymagania tej postaci są zawarte w definicji relacji.
Postać normalizacji polega w tym przypadku na doprowadzeniu określonego zbioru danych do postaci relacji. 

Mając bazę danych złożoną z relacji w pierwszej postaci normalnej, jest się narażonym na wszystkie niekorzystne zjawiska wymienione wyżej,
dlatego należy doprowadzić relacje do kolejnych postaci normalnych.

Proces normalizacji polega na odpowiednim podziale relacji na mniejsze, w wyższej postaci normalnej.

Pierwsza postać normalna relacji

Relacja jest w pierwszej postaci normalnej, jeżeli każda wartość atrybutu w każdej krotce tej relacji jest wartością elementarną, czyli nierozkładalną.
Z definicji pierwszej postaci normalnej relacji wynika, że każdemu elementowi relacji znajdującemu się na przecięciu dowolnej krotki i dowolnego atrybutu odpowiada pojedyncza wartość,
a nie zbiór wartości.

Przykład:
                                                       Relacja nieznormalizowana
Nr_Zamow Id_Dostawcy Nazwa_Dostawcy Adres_Dostawcy Id_Czesci Nazwa_Czesci Ilosc
001 300 FSO Warszawa 53
57
59
gażnik
wał
błotnik
100
50
500
002 400 FSM Tychy 54 gaźnik 200
Relacja znormalizowana
Nr_Zamow Id_Dostawcy Nazwa_Dostawcy Adres_Dostawcy Id_Czesci Nazwa_Czesci Ilosc
001 300 FSO Warszawa 53 gażnik 100
001 300 FSO Warszawa 57 wał 50
001 300 FSO Warszawa 59 błotnik 500
002 400 FSM Tychy 54 gażnik 200

 

Druga postać normalna

Aby przedstawić 2-gą postać normalną należy wprowadzić kilka pojęć

Zbiór identyfikujący relacji
taki zbiór atrybutów tej relacji, których kombinacje wartości jednoznacznie identyfikują każdą krotkę relacji
Klucz relacji
taki zbiór identyfikujący relacji, którego żaden podzbiór nie jest zbiorem identyfikujacym relacji

Wyróżnia się klucze proste i złożone. Klucz jest kluczem prostym, jeśli zbiór identyfikujący relacji jest zbiorem jednoelemantowym, w przeciwnym razie klucz jest złożony.
W ogólności, w relacji można wyróżnić wiele kluczy, które nazywamy kluczami potencjalnymi. Wybrany klucz spośród kluczy potencjalnych nazywamy kluczem głównym.

Zależność funkcjonalna

Atrybut B relacji r jest funkconalnie zależny od atrybutu A tej relacji, jeśli zawsze każdej wartości a atrybutu A odpowiada nie więcej niż jedna wartość atrybutu B. Inaczej A identyfikuje B.
Np. Id_Dostawcy jest funkcjonalnie zależny od atrybutu Nr_Zamowienia, gdyż jedno zamówienie jest kierowane tylko do jednego dostawcy, a zatem numer zamówienia jednoznacznie określa identyfikator dostawcy. Odwrotna zależność nie jest prawdziwa.

Pełna zależność funkcjonalna

Atrybut B relacji r jest w pełni funkcjonalnie zależny od zbioru atrybutów X, jeśli jest funkcjonalnie zależny od niego, ale nie jest funkcjonalnie zależny od żadnego podzbioru zbioru X.

Druga postać normalna:
Dana relacja jest w drugiej postaci normalnej, jeśli każdy atrybut tej relacji nie wchodzący w skład żadnego klucza potencjalnego jest w pełni funkcjonalnie zależny od wszystkich kluczy potencjalnych.

W celu uzyskania drugiej postaci normalnej należy podzielić relację na zbiór takich relacji, których wszystkie atrybuty będą w pełni funkcjonalnie zależne od kluczy.

Przechodnia zależność funkcjonalna

Niech X, Y i Z będą 3 roz łącznymi podzbiorami atrybutów danej relacji. Podzbiór atrybutów Z jest przechodnio funkcjonalnie zależny od podzbioru atrybutów X, jeśli podzbiór atrybutów Z jest funkcjonalnie zależny od podzbioru atrybutów Y, podzbiór atrybutów Y jest funkcjonalnie zależny od podzbioru atrybutów X, natomiast podzbiór atrybutów X nie jest funkcjonalnie zależny od Y lub podzbiór atrybutów Y nie jest funkcjonalnie zależny od Z.

Trzecia postać normalna relacji

Dana relacja jest w trzeciej postaci normalnej, jeśli jest ona w drugiej postaci normalnej i każdy jej atrybut nie wchodzący w skład żadnego klucza potencjalnego nie jest przechodnio funkcjonalnie zależny od żadnego klucza potencjalnego tej relacji.

Aby uzyskać trzecią postać normalną relacji, której atrybuty pozostają w przechodniej zależności funkcjonalnej, należy podzielić ją na 2 relacje.

Wyróżnia się jeszcze czwartą i piątą postać normalną relacji