BAZY DANYCH - EGZAMIN
sobota, 25.02.2012
1. Podstawowe pojęcia
2. Architektura bazy danych wg ANSI SPARC.
3. Diagram związków encji
4. Relacyjny model danych
5. Język baz danych SQL
6. Funkcje agregujÄ…ce i grupowanie wierszy
7. Podzapytania
8. Normalizacja relacji
9. Pierwsza postać normalna
10. Klucz relacji
11. Zależność funkcjonalna, domknięcie tranzytywne
12. Druga postać normalna
13. Przechodnia zależność funkcjonalna
14. Trzecia postać normalna
15. Postać normalna Boyce'a-Codda (BCNF)
1. Podstawowe pojęcia:
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
1
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

2
dotyczy fizycznej reprezentacji bazy danych w komputerze.
Ë%
opisuje sposób przechowywania danych w bazie - strukturę danych, organizację
Ë%
plików używanych do przechowywania danych
3. Diagram związków encji
Diagram związków encji - (ang. Entity Relationship Diagram  ERD) - technika organizacji
przechowywania danych.
Komponenty diagramu zwiÄ…zku encji:
Encja - rzecz mająca znaczenie, rzeczywista lub wymyślona, o której informacje należy znać lub
przechowywać. Przykładami encji są: PRACOWNIK, KLIENT, DOSTAWCA, ZAMÓWIENIE,
MAGAZYN, FAKTURA, POZYCJA, PRZECENA, KONTO. Encja jest urzeczywistniona
3
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
Każde wystąpienie encji Dziekan jest powiązane tylko z jednym
1:1 Dziekan-
wystąpieniem encji Wydział. Zatem jeden Dziekan kieruje jednym
Wydział
Wydziałem
Wydział posiada wielu Studentów, natomiast Student studiuje
1:M Wydział-Student
wyłącznie na jednym Wydziale
1: wiele
Jest to sytuacja, gdzie Książka może być napisana przez jednego
M:N Książka-Autor
lub wielu Autorów i jeden Autor jest podpisany pod jednym lub
Wiele: wiele
wieloma tytułami Książek.
Przykład prostego diagramu związków encji:
4
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
5
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.
6
5. Język baz danych SQL
z
ródło: wikipedia.org
Formy SQL
Z technicznego punktu widzenia, SQL jest podjęzykiem danych. Oznacza to, że jest on
wykorzystywany wyłącznie do komunikacji z bazą danych. Nie posiada on cech pozwalających
na tworzenie kompletnych programów. Jego wykorzystanie może być trojakie i z tego względu
wyróżnia się trzy formy SQL-a:
SQL interakcyjny (autonomiczny) wykorzystywany jest przez użytkowników w celu
1.
bezpośredniego pobierania lub wprowadzania informacji do bazy. Przykładem może być
zapytanie prowadzące do uzyskania zestawienia aktywności kont w miesiącu. Wynik jest
7
wówczas przekazywany na ekran, z ewentualną opcją przekierowania go do pliku lub
drukarki.
8
Statyczny kod SQL (Static SQL) nie ulega zmianom i pisany jest wraz z całą aplikacją,
2.
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.
Embedded SQL (Osadzony SQL) oznacza włączenie kodu SQL do kodu
a.
z
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.
Język modułów. W tym podejściu moduły SQL łączone są z modułami kodu
b.
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óz
niej.
Dynamiczny kod SQL (Dynamic SQL) generowany jest w trakcie pracy aplikacji.
3.
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
9
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
10
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,
11
ś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
12
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.
13
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 17
Drewbud Zielona 4, Szczecin belki bukowe szt. 2004-09-11 10
Drwal SA Dębowa 12A, Poznań belki bukowe kg 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
14
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 4 Szczecin belki szt. 2004-10-23 17
świerkowe
Drewbud Zielona 4 Szczecin belki bukowe szt. 2004-09-11 10
Drwal SA Dębowa 12A Poznań belki bukowe kg 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ść)
15
Miasto (opisana przy pomocy atrybutu miasto)

Miara (opisana przy pomocy atrybutu miara)

Podstawowym wskaz
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.
16
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 <-------------+ |
| |
numer <-------------+ |
| |
id_miasta -----+ <--+ |
| |
miasto <-------+ |
|
*id_towaru ---------+ --+
| |
towar <-------------+ |
| |
id_miary ------+ <--+ |
| |
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)

17
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 ( 1
*REGON -------------+ --------+
| |
dostawca <----------+ |
| |
ulica <-------------+ |
| |
numer <-------------+ |
| |
id_miasta -----+ <--+ |
| |
miasto <-------+ |
) |
|
Towar ( 1 |
*id_towaru ---------+ ---+ |
| | |
towar <-------------+ | |
| | |
id_miary ------+ <--+ | |
| | |
miara <--------+ | |
) | |
| |
18
Dostawa ( | |
*id_towaru ---------+ ---+ |
| 1 |
*REGON -------------+ --------+
| 1
*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 ( 1
*REGON -------------+ -----------+
19
 | |
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 -------------+ -----------+
| 1
*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
20
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 y
RÓDA
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
21