plik

Baza danych - zbiór informacji opisujący wybrany fragment rzeczywistości.
Cechy baz danych: trwałość, duże wolumeny (duża ilość danych wymaga innych metod dostępu),
zgodność z rzeczywistością.
Właściwości baz danych: spójność danych, współdzielenie danych, integracja danych, integralność
danych, bezpieczeństwo danych, niezależność danych, standaryzacja danych, metadane (dane o danych)

System zarządzania bazami danych - (SZBD, DBMS - Database Management System) - określa jaka
powinna być struktura danych oraz w jaki sposób dane są powiązywane.
Do podstawowych funkcji realizowanych przez SZBD należą:

●

Definiowanie i obróbka danych - wsparcie dla języka bazy danych, tworzenie, aktualizacja,
usuwani danych

●

Struktury danych - wsparcie dla struktur danych zapewniających składowanie i przetwarzanie
dużych wolumenów danych.

●

Bezpieczeństwo i integralność danych

●

Odzyskiwanie danych i współbieżność

●

Wydajność

●

Różnorodność interfejsów.

Komercyjne: Oracle. IBM, Access. Niekomercyjne: MySQL, Firebird

Transakcje - jedno lub więcej zapytań stanowiące grupę zadań do wykonania w jednym ciągu.
Własności transakcji: niepodzielność (cała transakcja musi być wykonana), izolacja (wykonywanie

dwóch transakcji jednocześnie jest blokowane), trwałość (jeśli transakcja się zakończy to jej wynik nie
może być utracony z powodu awarii)

Współdzielenie bazy danych - wielu użytkowników tej samej bazy

Użytkownicy bazy danych

●

Grupy zasadnicze: Użytkownicy (z prawem odczytu, z prawem odczytu i modyfikacji),
Programiści aplikacji, Projektanci baz danych, Analitycy systemowi, Administratorzy bazy
danych.

●

Grupy dodatkowe: Administratorzy serwerów, sieci komputerowych, Projektanci i programiści
ZBD, Inżynierowie wiedzy, Projektanci narzędzi developerskich.

Integralność bazy danych - dokładne odzwierciedlenie obszaru analizy. Baza powinna zapewniać
aktualizację danych po obu stronach związków będących odzwierciedleniem rzeczywistości, zapobiegnie
to sprzeczności pomiędzy dwoma pozycjami reprezentującymi ten sam fakt, powinna istnieć możliwość
nakładania ograniczeń integralnościowych
Reguły integralności - Integralność to ograniczenie nakładane na bazę danych przez model relacyjny.
Dwie podstawowe reguły integralności to integralność encji (wartość klucza głównego nie może być
wartością NULL) oraz integralność odwołań (nie mogą istnieć niedopasowane wartości klucza obcego).

2. Architektura bazy danych wg ANSI SPARC

Trzypoziomowa architektura dla systemu baz danych. Architektura ta wyróżnia trzy poziomy
abstrakcji (nazywane schematami lub widokami):

● Poziom zewnętrzny

○ opisuje jak użytkownicy widzą bazę danych i w jaki sposób uzyskują do niej

dostęp

○ składa się z wielu zewnętrznych sposobów widzenia bazy danych - tzw.

perspektyw.

○ perspektywa zawiera tylko te dane z bazy danych, którymi dany użytkownik jest

zainteresowany. pozostałe dane są dla niego niewidoczne.

○ perspektywy zwiększają poziom bezpieczeństwa danych oraz umożliwiają

dostosowanie sposobu prezentacji danych do przyzwyczajeń użytkownika.

● Poziom konceptualny (pojęciowy)

○ stanowi zbiorowy sposób widzenia bazy danych.
○ opisuje, jakie dane są przechowywane w bazie i jakie są ich wzajemne związki
○ zawiera logiczną strukturę bazy danych

● Poziom wewnętrzny

poprzez wystąpienie. Przykładowo, wystąpieniami encji KLIENT są: Nowak, Dobrowolski,
Kwiatkowski itd.

Atrybut - element informacji służący do klasyfikowania (np. typ towaru), identyfikowania (np.
nr zamówienia), opisywania (np. opis towaru), określania ilości (np. ilość towaru w magazynie)
lub wyrażania stanu encji (np. status płatności za zamówienie).
Klucz encji - zwany identyfikatorem; pełni szczególną rolę w zakresie atrybutow - Pozwala on
na jednoznaczne określenie wystąpienia encji. Jeśli używa się jednego atrybutu dla określenia
encji, to mamy do czynienia z kluczem pojedynczym, a jeśli w tym celu używa się więcej niż
jednego atrybutu, to z kluczem złożonym

Związek - znaczący sposób, w jaki mogą być ze sobą powiązane dwie rzeczy tego samego typu
lub różnych typów. W identyfikowaniu i modelowaniu związków encji bierze się pod uwagę
następujące cechy: stopień związku (lub liczebność związku) i opcjonalność (lub uczestnictwo
encji).
Stopień związku – oznacza stosunek ilościowy między liczebnością wystąpień poszczególnych
encji, uczestniczących w danym związku. Stopień związku mówi o tym, ile wystąpień encji
jednego rodzaju jest powiązanych z iloma wystąpieniami encji innego rodzaju

Stopień związku

Przykład

Znaczenie

1:1

Dziekan-

Wydział

Każde wystąpienie encji Dziekan jest powiązane tylko z jednym
wystąpieniem encji Wydział. Zatem jeden Dziekan kieruje jednym
Wydziałem

1:M

1: wiele

Wydział-Student

Wydział posiada wielu Studentów, natomiast Student studiuje
wyłącznie na jednym Wydziale

M:N

Wiele: wiele

Książka-Autor

Jest to sytuacja, gdzie Książka może być napisana przez jednego
lub wielu Autorów i jeden Autor jest podpisany pod jednym lub
wieloma tytułami Książek.

Przykład prostego diagramu związków encji:

Typy encji ERD (notacja Martina)

● Encja regularna – oznacza dowolny znaczący element, o którym informacja powinna

być znana albo utrzymywana (częściowe uczestnictwo w związku).

● Encja słaba – jest to encja, która może istnieć tylko wtedy, gdy jest związana z innymi

encjami lub też nie posiada własnych atrybutów kluczowych (całkowite uczestnictwo w
związku)

● Encja – obiekt asocjacyjny – przechowuje informacje o związku pomiędzy dwiema

encjami.

4. Relacyjny model danych

Konceptualny model danych, którego odzwierciedleniem są diagramy ERD, przekształcany jest
w jeden z modeli baz danych: relacyjny, sieciowy, hierarchiczny. Nazywa się to projektowaniem
logicznym danych.
Relacja - jest to podzbiór iloczynu kartezjańskiego repezentowany przez zbiór krotek.
Reprezentacją relacji jest tablica.
Krotka - oznacza wiersz tablicy. Reprezentacją krotki w tablicy jest rekord.
Atrybut - oznacza kolumnę tablicy ( a dokładnie są to różne wystąpienia tego samego atrybutu).
Reprezentacją atrybutu w tablicy jest pole.
Stopień relacji - liczba atrybutów w relacji
Liczebność relacji - liczba krotek w relacji
Klucz główny - kolumna lub kombinacja kolumn, których wartości jednoznacznie identyfikują
wiersze w tablicy.
Klucz obcy - kolumna lub kombinacja kolumn, których wartości określają klucz główny innej

tablicy.
Dziedzina (atrybutu) - lista dostępnych wartości atrybutu, wszystkie tego samego typu.

Relacyjna baza danych

● Schemat relacyjnej bazy danych jest zbiorem schematów relacji
● Relacyjna baza danych jest zbiorem relacji spełniających warunki integralności dla

każdej relacji i między relacjami

Baza danych pozwalająca na sprawne przechowywanie, zarządzanie oraz operowanie danymi
zorganizowanym w struktury zwane relacjami.

Stworzenie relacyjnego modelu danych polega na wykonaniu następujących kroków:

● każda encja staje się tablicą, której nazwa jest nazwą encji w liczbie mnogiej;
● każdy atrybut staje się komuną, a jego nazwa odpowiednio nazwą tej kolumny.

Natomiast właściwości atrybutu stają się odpowiadającymi im właściwościami w
projekcie danych. Atrybuty obowiązkowe stają się kolumnami NOT NULL (co oznacza,
że nie jest możliwe by wartość kolumny przyjmowała wartość NULL);

● unikalny identyfikator encji staje się kluczem głównym tabeli;
● każdy związek jest przekształcany w dwa obiekty. Kolumnę klucz obcego, zgodną z

kluczem głównym (lub unikalnym) tabeli, której dotyczy. Dziedziczy ona typ i rozmiar
danego klucz głównego. Opcjonalność kolumny zależy od tego, czy związek jest
obowiązkowy czy opcjonalny. Więzy klucza obcego związane są z kolumną klucza
obcego.

2. Statyczny kod SQL (Static SQL) nie ulega zmianom i pisany jest wraz z całą aplikacją,

podczas której pracy jest wykorzystywany. Nie ulega zmianom w sensie zachowania
niezmiennej treści instrukcji, które jednak zawierać mogą odwołania do zmiennych lub
parametrów przekazujących wartości z lub do aplikacji. Statyczny SQL występuje w
dwóch odmianach.

a. Embedded SQL (Osadzony SQL) oznacza włączenie kodu SQL do kodu

źródłowego innego języka. Większość aplikacji pisana jest w takich językach
jak C++ czy Java, jedynie odwołania do bazy danych realizowane są w SQL. W
tej odmianie statycznego SQL-a do przenoszenia wartości wykorzystywane są
zmienne.

b. Język modułów. W tym podejściu moduły SQL łączone są z modułami kodu

w innym języku. Moduły kodu SQL przenoszą wartości do i z parametrów,
podobnie jak to się dzieje przy wywoływaniu podprogramów w większości
języków proceduralnych. Jest to pierwotne podejście, zaproponowane w
standardzie SQL. Embedded SQL został do oficjalnej specyfikacji włączony
nieco później.

3. Dynamiczny kod SQL (Dynamic SQL) generowany jest w trakcie pracy aplikacji.

Wykorzystuje się go w miejsce podejścia statycznego, jeżeli w chwili pisania aplikacji
nie jest możliwe określenie treści potrzebnych zapytań – powstaje ona w oparciu o
decyzje użytkownika. Tę formę SQL generują przede wszystkim takie narzędzia jak
graficzne języki zapytań. Utworzenie odpowiedniego zapytania jest tu odpowiedzią na
działania użytkownika.

Wymagania tych trzech form różnią się i znajduje to odbicie w wykorzystywanych przez nie
konstrukcjach językowych. Zarówno statyczny, jak i dynamiczny SQL uzupełniają formę
autonomiczną cechami odpowiednimi tylko w określonych sytuacjach. Zasadnicza część języka
pozostaje jednak dla wszystkich form identyczna.

Składnia SQL

Użycie SQL, zgodnie z jego nazwą, polega na zadawaniu zapytań do bazy danych. Zapytania
można zaliczyć do jednego z trzech głównych podzbiorów:

● SQL DML (ang. Data Manipulation Language – „język manipulacji danymi”),
● SQL DDL (ang. Data Definition Language – „język definicji danych”),
● SQL DCL (ang. Data Control Language – „język kontroli nad danymi”).

Instrukcje SQL w obrębie zapytań tradycyjnie zapisywane są wielkimi literami, jednak nie jest to
wymóg. Każde zapytanie w SQL-u musi kończyć się znakiem średnika (;).

Dodatkowo, niektóre programy do łączenia się z silnikiem bazy danych (np. psql w przypadku
PostgreSQL), używają swoich własnych instrukcji, spoza standardu SQL, które służą np. do

połączenia się z bazą, wyświetlenia dokumentacji itp.

DML
DML (Data Manipulation Language) służy do wykonywania operacji na danych – do ich
umieszczania w bazie, kasowania, przeglądania oraz dokonywania zmian. Najważniejsze
polecenia z tego zbioru to:

● SELECT – pobranie danych z bazy,
● INSERT – umieszczenie danych w bazie,
● UPDATE – zmiana danych,
● DELETE – usunięcie danych z bazy.

Dane tekstowe muszą być zawsze ujęte w znaki pojedynczego cudzysłowu (').

DDL
Dzięki DDL (Data Definition Language) można operować na strukturach, w których dane
są przechowywane – czyli np. dodawać, zmieniać i kasować tabele lub bazy. Najważniejsze
polecenia tej grupy to:

● CREATE (np. CREATE TABLE, CREATE DATABASE, ...) – utworzenie struktury

(bazy, tabeli, indeksu itp.),

● DROP (np. DROP TABLE, DROP DATABASE, ...) – usunięcie struktury,
● ALTER (np. ALTER TABLE ADD COLUMN ...) – zmiana struktury (dodanie kolumny

do tabeli, zmiana typu danych w kolumnie tabeli).

DCL
DCL (Data Control Language) ma zastosowanie do nadawania uprawnień do obiektów
bazodanowych. Najważniejsze polecenia w tej grupie to:

● GRANT (np. GRANT ALL PRIVILEGES ON EMPLOYEE TO PIOTR WITH GRANT

OPTION) – przyznanie wszystkich praw do tabeli EMPLOYEE użytkownikowi PIOTR z
opcją pozwalającą mu nadawać prawa do tej tabeli.

● REVOKE – odebranie użytkownikowi wszystkich praw do tabeli, które zostały

przyznane poleceniem GRANT.

● DENY.

Główne zapytania spisane przez Gadoma :)

MYSQL -U użytkownik –P - logowanie

SHOW DATABASES; - wyświetlanie baz

CREATE database nasza_baza; - tworzenie bazy

DROP database nasza_baza; - usuwanie bazy

USE nasza_baza – wybieranie bazy

SHOW tables; - wyświetlanie tabel

CREATE table nazwa_tabeli (lista pol); - tworzenie tabeli

DROP TABLE do_usuniecia; - usuwanie tabeli

DESCRIBE nazwa_tabeli; - wyświetlanie zawartości tabeli

ALTER TABLE nazwa_tabeli RENAME nowa_nazwa_tabeli; - zmiana nazwy tabeli

ALTER TABLE nazwa_tabeli ADD nazwa_pola VARCHAR(60); - dodawanie nowego pola

do tabeli

ALTER TABLE nazwa_tabeli CHANGE nazwa_pola nowa_nazwa_pola VARCHAR(60); -

zmiana nazwy pola

ALTER TABLE nazwa_tabeli MODIFY nazwa_pola VARCHAR(80); - zmiana typu pola

ALTER TABLE nazwa_tabeli DROP COLUMN nazwa_pola; - usuniecie pola

INSERT INTO nazwa_tabeli VALUES(wartosci pol oddzielone „,”); - dodawanie

rekordów

DELETE FROM nazwa_tabeli WHERE warunek

UPDATE nazwa_tabeli SET nazwa_pola = 'wartosc' WHERE warunek

SELECT ... FROM nazwa_bazy.nazwa_tabeli;

SELECT ... FROM nazwa_tabeli;

* - wybierz wszystko

nazwa_pola – wybrana kolumna lub kolumny

MAX(nazwa_pola) – maksymalna wartość w danej kolumnie

MIN() – minimalna

COUNT(*) – liczba rekordów

SUM() – suma podanej kolumny

AVG() – srednia

CONCAT(nazwa_pola1,nazwa_pola2) – łaczenie wyświetlanych wynikow

SELECT * FROM nazwa_tabeli WHERE ...;

operatory warunkowe jak =, <>, !=, >, <,>=,<=

operatory logiczne jak AND, OR, BETWEEN, IN, NOT

SELECT * FROM nazwa_tabeli ORDER BY nazwa_pola; - sortowanie wedlug nazwy

pola

SELECT * FROM nazwa_tabeli LIMIT x,y; - ograniczenie wyswetlanych pozycji

x – pozycja startowa, y – ilość rekordow

SELECT DISTINCT nazwa_pola FROM nazwa_tabeli; - wysw.niepowtarzalnych sie

wartosci danego pola

SELECT nazwa_tabeli1.nazwa_pola, nazwa_tabeli2.nazwa_pola FROM nazwa_tabeli1

INNER JOIN nazwa_tabeli2 ON nazwa_tabeli1.nazwa_pola = nazwa

tabeli2.nazwa_pola; - nie wiem jak to opisac :D

SELECT nazwa_pola AS nowa_etykieta, pole2 AS etykieta2 FROM nazwa_tabeli; -

ustawienie jak ma nazywac się etykieta kolumny

6. Funkcje agregujące i grupowanie wierszy

Funkcje agregujące
Agregacje to funkcje działające na grupach danych. Można powiedzieć (niezbyt ściśle), że
zwracają one pewną wypadkową pojedynczą wartość z kilku rekordów, np. liczbę rekordów,

średnią obliczoną z wartości w jakiejś kolumnie itp.
W skrócie: Funkcje agregujące dostarczają podsumowaną (“zagregowaną”) informację z wielu
krotek (wierszy).
Przykładowo:
SELECT COUNT(*) FROM Zwierzeta; -- zwraca liczbę wszystkich rekordów w tabeli
Zwierzeta
SELECT AVG(wiek) FROM Zwierzeta; -- zwraca średnią wieku wszystkich zwierząt
Korzystając z agregacji możemy oczywiście stosować w zapytaniach warunek WHERE.

Najważniejsze funkcje agregujące:
COUNT(.) - zlicza wiersze
COUNT(DISTINCT .) - zlicza różne wystąpienia w wierszach
SUM(.) - podaje sumę wartości liczbowych
AVG(.) - podaje średnią arytmetyczną z wartości liczbowych
STD(.), STDDEV(.) - podaje odchylenie standardowe wartości liczbowych
VARIANCE(.) - podaje wariancję wartości liczbowych
MIN(.), MAX(.) - podaje najmniejszą i największą wartość

Grupowanie danych

Słowa kluczowe:
GROUP BY, HAVING

Funkcje agregujące zwracają jedną wartość dla wszystkich rekordów. Klauzula GROUP BY
pozwala pogrupować rekordy w rozdzielne grupy, dzięki czemu możliwe będzie zastosowanie
funkcji agregujących dla każdej z tych grup oddzielnie. Przykładowo, możemy sprawdzić liczbę
zwierząt, którymi opiekuje się każdy z opiekunów:
SELECT id_opiekuna, COUNT(*) FROM Zwierzeta GROUP BY id_opiekuna;

W powyższym zapytaniu grupujemy po kolumnie id_opiekuna. Powoduje to, że wszystkie zwierzaki
zostaną podzielone na rozdzielne grupy według opiekunów, którzy nimi się opiekuj

Klauzula HAVING jest warunkiem dla grup, występuje tylko w połączeniu z GROUP BY.
Stosujemy ją tylko wtedy, gdy chcemy nałożyć warunek na całą grupę, np. chcemy wyświetlić
tylko tych opiekunów, którzy opiekują się więcej niż trzema zwierzakami:
SELECT id_opiekuna, COUNT(*) FROM Zwierzeta GROUP BY id_opiekuna HAVING
COUNT(*)>3;
WHERE nakłada warunek na pojedyncze rekordy, zanim wejdą do grupy. HAVING nakłada
warunek na całe grupy:
SELECT id_opiekuna, COUNT(*) FROM Zwierzeta WHERE wiek>=10
GROUP BY id_opiekuna HAVING COUNT(*)>2;
Zapytanie wyświetli tylko liczbę zwierzaków opiekunów, którzy mają pod swoją pieczą więcej

niż
2 zwierzaki starsze niż 10 lat

7. Podzapytania

Podzapytania pozwalają na tworzenie strukturalnych podzapytań, co umożliwia izolowanie
poszczególnych części instrukcji. Zapewniają one alternatywny sposób wykonywania zadań,
które w inny sposób można realizować tylko poprzez skomplikowane złączenia. Podzapytania
zwiększają czytelność kodu.

Podzapytania — operatory ANY, IN, ALL

SELECT * FROM baza
WHERE Liczba > ANY(SELECT liczba FROM tablica);

Operator porównania ANY oznacza, iż “coś” musi spełniać odpowiednią relację z jakimiś
wynikami
podzapytania.
Słowo kluczowe ALL oznacza, ze warunek musi być spełniony dla wszystkich wierszy
zwracanych przez podzapytanie
Słowo kluczowe IN jest równoważne z warunkiem = ANY.

Podzapytania — operator EXISTS

SELECT * FROM baza

WHERE EXISTS(SELECT * FROM tablica WHERE InnaLiczba > 100);

EXISTS - warunek jest prawdziwy jeśli podzapytanie zwraca niepusty zbiór wiersz

Podzapytania skorelowane

SELECT * FROM baza

WHERE EXISTS(SELECT * FROM tablica WHERE InnaLiczba/3=baza.liczba);

Występujące tutaj podzapytanie zawiera odwołanie do kolumny występującej w zapytaniu
zewnętrznym.. Podzapytania tego typu nazywamy skorelowanymi.

W powyższym przykładzie podzapytanie wykonywane jest dla każdego wiersza tabeli tablica, a
więc przy ustalonej wartości wielkości tablica.liczba.

I tu zaczyna się cała zabawa. Kolejne rozdziały służą do przegrzania mózgownicy.
Rozdział 4. tego manuala to był przedsmak. ;) Polecam wrócić do niego i przypomnieć sobie
pojęcia.
Przede wszystkim polecam poczytać wikipedię. Jeżeli macie ochotę na coś bardziej
hardcorowego to klik: http://www.ia.pw.edu.pl/~ttraczyk/bd2/bd2_2.pdf
Jak komuś się nie chce czytać, to może to małe podsumowanie będzie wystarczające. Dzięki
Bogu niektórzy nie mają życia towarzyskiego i takie kompendium zostało już nie raz spisane.
Zebrałam to, co najważniejsze.
Oczywiście istnieje jeszcze opcja z lat szkolnych - to jest takie trudne, nieludzkie i głupie, że
tego na pewno nie będzie :P

8. Normalizacja relacji

Normalizacja relacji ma na celu takie jej przekształcenie, aby nie posiadała ona cech
nieporządanych. Cechy te, to przede wszystkim redundancja (powtarzanie) danych i trudności w
zapewnieniu integralności danych.

Rozważmy przykład bazy danych zawierających dane dotyczące dostaw towarów w pewnej
firmie. Baza taka mogłaby mieć następującą postać

dostawca

adres

towar

miara

data

ilość

Drewbud

Zielona 4, Szczecin

belki świerkowe

szt.

2004-10-23

Drewbud

Zielona 4, Szczecin

belki bukowe

szt.

2004-09-11

Drwal SA

Dębowa 12A, Poznań

belki bukowe

2004-10-03

1200

na tej tabeli będziemy się opierać przy dalszych rozważaniach

Z postacią taką wiąże się szereg problemów związanych z wygodą dostępu do danych,
utrzymaniem integralności i uniknięciem redundancji:

●

Wyszukiwanie dostawców na podstawie miejscowości gdzie znajduje się jego siedziba
jest utrudnione, bo wymaga przetwarzania tekstu opisującego adres i wyszukiwania w
nim ciągu znaków opisującego miejscowość

●

Jeden dostawca może dostarczać wielu różnych towarów, w związku z tym występuje
redundancja zapisów opisujących dostawcę

●

Zmiana jednej z informacji o dostawcy lub towarze powoduje konieczność zmiany
wszystkich krotek zawierających te dane w celu zapewnienia integralności

●

Nie ma możliwości wprowadzenia danych o dostawcach, z którzy aktualnie nie
dostarczają żadnych towarów

●

Usunięcie dostawcy może spowodować usunięcie wszystkich danych dotyczących
dostarczanych przez nich towarów

Proces normalizacji ma za zadanie usunięcie tych niedogodności.

9. Pierwsza postać normalna

Tabela jest w pierwszej postaci normalnej (1NF), jeśli wartości atrybutów są elementarne, tzn.
są to pojedyncze wartości określonego typu, a nie zbiory wartości. Jest to warunek konieczny,
aby tabelę można było nazwać relacją. Większość systemów baz danych nie ma możliwości
zbudowania tabel nie będących w pierwszej postaci normalnej.

Nasza tabela po przekształceniu do pierwszej postaci normalnej wygląda następująco:

dostawca

ulica

numer

miasto

towar

miara

data

ilość

Drewbud

Zielona

Szczecin

belki

świerkowe

szt.

2004-10-23

Drewbud

Zielona

Szczecin

belki bukowe

szt.

2004-09-11

Drwal SA

Dębowa

12A

Poznań

belki bukowe

2004-10-03

1200

W pierwszej postaci normalnej adres dostawcy został podzielony na elementy atomowe, tj. w
miejsce atrybutu adres wprowadzono atrybuty ulica, numer, miasto.

10. Klucz relacji

Kluczem relacji nazywa się minimalny zbiór atrybutów relacji przy pomocy którego można w
sposób jednoznaczny zidentyfikować każdą krotkę wchodzącą w jej skład. Klucze składające
się z jednego atrybutu (kolumny) nazywane są kluczami prostymi; klucze składające się z wielu
atrybutów nazywane są kluczami złożonymi.

W zależności od natury klucza można go zaklasyfikować jako klucz naturalny (atrybut istniejący
w rzeczywistości pozwalający na jednoznaczną identyfikację rekordów) lub jako klucz sztuczny
(atrybut identyfikujący wprowadzony do schematu relacji ściśle na jej potrzeby).

Klucze wprowadza się aby wyeliminować redundancję danych w ten sposób, że każdemu
obiektowi co do którego ustalimy, że potencjalnie może się wielokrotnie pojawić w bazie danych
przypisujemy klucz. Pod pojęciem „obiekt” rozumie się tutaj zespół atrybutów opisujących
pewien modelowany byt. W naszej przykładowej relacji można wyróżnić następujące obiekty:

● Dostawca (opisany przy pomocy atrybutów dostawca, ulica, numer, miasto)
● Towar (opisany przy pomocy atrybutów towar, miara)
● Dostawa (opisana przy pomocy atrybutów dostawcy, atrybutów towaru oraz atrybutów

data oraz ilość)

● Miasto (opisana przy pomocy atrybutu miasto)
● Miara (opisana przy pomocy atrybutu miara)

Podstawowym wskaźnikiem potrzeby wyróżnienia obiektu w tabeli jest zminimalizowanie
redundancji. W procesie tym często również bierze się pod uwagę wygodę i powszechnie
stosowane praktyki. Właśnie rezultatem tychże jest nieuwzględnienie obiektu Ulica (opisanego
przez atrybut ulica).

Po wyróżnieniu obiektów można przystąpić do przypisania im atrybutów identyfikujących, czyli
kluczy. Powinny być one w miarę możliwości kluczami naturalnymi, czyli np. PESEL dla opisu
obywatela Polski.

Oto klucze, jakie zostały przydzielone poszczególnym obiektom:

● REGON dla obiektu Dostawcy (klucz naturalny)
● Liczba całkowita dla obiektu Towaru (klucz sztuczny)
● Liczba całkowita dla obiektu Miasto (klucz sztuczny)
● Liczba całkowita dla obiektu Miara (klucz sztuczny)

Należy zwrócić uwagę na to, że obiektowi Dostawy nie przypisano klucza. Jest to rezultatem
tego, że jest on opisany częściowo przez obiekty Dostawcy i Towaru, które wraz z atrybutem
data pozwalają na jednoznaczne zidentyfikowanie każdego rekordu opisującego dostawę.

Po dodaniu kluczy schemat przykładowej relacji będzie wyglądać następująco (gwiazdką zostały
oznaczone klucze):

Dostawa (

*REGON
dostawca
ulica
numer
id_miasta
miasto
*id_towaru
towar
id_miary
miara
*data
ilość

)

Należy zwrócić uwagę, że nie wszystkie nowo dodane atrybuty zostały oznaczone jako klucze.
Dzieje się tak dlatego, bo w kontekście opisu dostawy atrybuty id_miasta i id_miary nie są
konieczne do jednoznacznej identyfikacji rekordu dostawy.

Wyróżnienie kluczy w relacji jest istotnym elementem koniecznym do przeprowadzenia procesu
normalizacji.

Znając i rozumiejąc (?) pojęcie klucza relacji, możemy zająć się kolejnymi postaciami. Najpierw
jednak musimy dowiedzieć się o zależności funkcjonalnej.

11. Zależność funkcjonalna, domknięcie tranzytywne

Atrybut B jest funkcjonalnie zależny od atrybutu A (inaczej: atrybut A identyfikuje atrybut
B) jeśli dowolnej wartości atrybutu A odpowiada nie więcej niż jedna wartość atrybutu B.
Zależność funkcjonalną zapisuje się następująco: A -> B.

Atrybut B jest w pełni funkcjonalnie zależny od zbioru atrybutów X jeśli jest funkcjonalnie
zależny tylko i wyłącznie od elementów zbioru atrybutów X.

Zależności w naszym przykładzie prezentują się następująco:

Dostawa (

*REGON -------------+ --+
                    |   |
dostawca <----------+   |

| |

ulica <-------------+ |

| |

miasto <-------+

*id_towaru ---------+ --+

| |

miara <--------+

*data ------------------+

ilość <-----------------+

)

Zapis ten należy rozumieć następująco:

● Klucz REGON jednoznacznie identyfikuje nazwę dostawcy (atrybut dostawca), adres

dostawcy (atrybuty ulica, numer i id_miasta)

● Klucz id_miasta jednoznacznie identyfikuje nazwę miasta (atrybut miasto)

● Klucz id_towaru jednoznacznie identyfikuje nazwę towaru (atrybut towar) i zastosowaną

do niego miarę (atrybut id_miary)

● Klucz id_miary jednoznacznie identyfikuje nazwę miary (atrybut miara)
● Klucze REGON, id_towaru i data jednoznacznie identyfikują szczegóły dostawy (atrybut

ilość)

Jeżeli chcemy stwierdzić, które atrybuty są funkcjonalnie zależne od zbioru X to wyznaczamy
domknięcie tranzytywne tego zbioru.
Domknięciem tranzytywnym zbioru X R względem zbioru zależności funkcyjnych F jest zbiór
atrybutów X+ = {A R: X → A F+}. Oznacza to, że domknięcie tranzytywne jest zbiorem
wszystkich tych atrybutów, których wartości są zdeterminowane przez wartości atrybutów
należących do zbioru X.

12. Druga postać normalna

Tabela jest w drugiej postaci normalnej (2NF) jeśli jest w pierwszej postaci normalnej i
każdy atrybut niekluczowy relacji jest w pełni funkcjonalnie zależny od wszystkich kluczy
niezależnych.

Nawiązując do powyższej definicji w kontekście naszego przykładu widać, że nie jest on w
drugiej postaci normalnej, bo istnieją atrybuty, które nie są w pełni funkcjonalnie zależne od
wszystkich kluczy relacji. Aby doprowadzić naszą relację do drugiej postaci normalnej trzeba ją
podzielić na mniejsze tabele. Wynikiem tego podziału są trzy tabele:

Dostawca (

*REGON -------------+

--------+

dostawca <----------+

ulica <-------------+

numer <-------------+

id_miasta -----+ <--+

miasto <-------+

)

Towar (

*id_towaru ---------+

---+

towar <-------------+

id_miary ------+ <--+

miara <--------+

)

Dostawa (

*id_towaru ---------+

---+

1 |

*REGON -------------+

--------+

*data --------------+
|
ilość <-------------+

)

Na czerwono zaznaczone zostały zależności jakie istnieją pomiędzy atrybutami z różnych tabel.
Należy zwrócić uwagę, że zależności między kluczami są zawsze postaci 1-do-1, a zależności
między kluczem a atrybutem niekluczowym są postaci 1-do-n.

13. Przechodnia zależność funkcjonalna

Niech A, B, C będą rozłącznymi zbiorami atrybutów pewnej relacji. Zbiór atrybutów C
jest przechodnio funkcjonalnie zależny od zbioru atrybutów A jeśli zbiór atrybutów B jest
funkcjonalnie zależny od zbioru atrybutów A oraz zbiór atrybutów C jest funkcjonalnie zależny
od zbioru atrybutów B.

W naszym przykładzie przechodnie zależności funkcjonalne istnieją w relacji Dostawca
(REGON -> id_miasta -> miasto) oraz w relacji Towar (id_towaru -> id_miary -> miara).

14. Trzecia postać normalna

Dana relacja jest w trzeciej postaci normalnej (3NF) jeśli jest ona w drugiej postaci normalnej
oraz brak jest w niej przechodnich zależności funkcjonalnych.

Jak już wspomniano w poprzednim podrozdziale w naszym przykładzie istnieją przechodnie
zależności funkcjonalne. Należy je wyeliminować aby uzyskać schemat relacji w trzeciej
postaci normalnej. Dokonuje się tego poprzez podział tabeli z przechodnimi zależnościami
funkcjonalnymi według następującego schematu:

● Wejście: A -> B -> C (przechodnia zależność funkcjonalna C od A)
● Wyjście: A -> B oraz B -> C

W naszym przykładzie w wyniku podziału tabel Dostawca oraz Towar uzyskujemy finalnie
schemat bazy danych w trzeciej postaci normalnej:

Dostawca (

*REGON -------------+

-----------+

dostawca <----------+

ulica <-------------+

numer <-------------+

n |

id_miasta <---------+

<--+ |

)

| |

Miasto (

| |

*id_miasta ---------+

---+ |

1 |

miasto <------------+

)

Towar (

1 |

*id_towaru ---------+

-------+ |

| |

towar <-------------+

| |

n | |

id_miary <----------+

<--+ | |

)

| | |

Miara (

| | |

*id_miary ----------+

---+ | |

1 | |

miara <-------------+

| |

)

| |

Dostawa (

| |

*id_towaru ---------+

-------+ |

1 |

*REGON -------------+

-----------+

*data --------------+

ilość <-------------+

)

15. Postać normalna Boyce’a-Codda

W tej postaci zależności funkcyjne muszą mieć następującą postać: jeżeli X → A i atrybut A nie
jest zawarty w X, to X jest kluczem lub zawiera klucz.

Jeśli schemat relacji znajduje się w postaci normalnej Boyce'a-Codda, nie można w tabeli
przewidzieć jednych wartości w oparciu o inne, chociaż jak to będzie pokazane dalej nie mamy

gwarancji, że nie będzie innego rodzaju redundancji niż zależność funkcyjna.

Nie każdy schemat tabeli da się sprowadzić do zbioru schematów tabel w postaci normalnej
Boyce’a-Codda bez utraty zawartych w tabelach informacji i z zachowaniem zależności
funcyjnych. Na przykład schematem takim jest MUK = {Miasto, Ulica, Kod} z zależnościami:

Miasto Ulica -> Kod

Kod -> Miasto

Są dwa klucze:

● {Miasto, Ulica}
● {Kod, Ulica}

Ze względu na zależność Kod -> Miasto schemat MUK nie jest w postaci normalnej Boyce'a-
Codda. Tego schematu nie daje się rozłożyć z zachowaniem zależności funkcyjnych (bo jedna z
zależności funkcyjnych obejmuje wszystkie atrybuty).
Atrybut kluczowy jest to atrybut wchodzący w skład jednego z kluczy tabeli.

Koniec.
The End.
Fin.
Powodzenia na egzaminie i oby obyło się bez dopytki! ☺

Popełnił Asiek (czasami metodą ctrl+c/ctrl+v)

RÓŻNE ŹRÓDŁA:
http://ii.uwb.edu.pl/~aboltuc/images/stories/wykad_1.pdf
http://tomasz.kubik.staff.iiar.pwr.wroc.pl/dydaktyka/RelacyjneBazyDanych/BD-Wyk06-TK.pdf
http://www.slidefinder.net/w/wyk1/wyk1/22644276
http://www.math.uni.opole.pl/~ajasi/info/1infzaoczne/wyklad_1_2.pdf
http://dydaktyka.polsl.pl/roz6/bd/Materiay%20dydaktyczne/
Bazy%20danych%20(MU)%20-%20Katowice/bd2.pdf

gdr.geekhood.net/gdrwpl/heavy/studia/sbd-podstawy.doc
http://tomasz.kubik.staff.iiar.pwr.wroc.pl/dydaktyka/RelacyjneBazyDanych/BD-Wyk03-TK.pdf
http://www.ujk.edu.pl/~opoka/plikibd/cw1bd/help/3/postacie.htm