Wykład 1

Systemy baz

danych

Program wykładów



Projektowanie schematów baz danych - diagramy
związków encji, zależności funkcyjne, postacie
normalne.



Język relacyjnych i obiektowo-relacyjnych baz danych
SQL.



Rozszerzenia proceduralne SQL: język PL/SQL w
Oracle, opcja obiektowa w Oracle, interfejsy
programistyczne, aplikacje internetowe.



Budowa i działanie systemu baz danych.
Administrowanie i dostrajanie systemu baz danych.



Rozproszone bazy danych. Hurtownie danych.

Program ćwiczeń



1-2 Projektowanie schematów baz danych w Visio
oraz zależności funkcyjne, postacie normalne.



3 Kartkówka 30min.



3-8 SQL.



9 Kolokwium nr 1 (SQL).



10-13 PL/SQL.



14 Kolokwium nr 2 (PL/SQL, procedury,
wyzwalacze).



15 Zaliczanie projektów i ćwiczeń.

Kryteria zaliczeń



Zaliczenie ćwiczeń w oparciu o wyniki
wejściówek, pracy na ćwiczeniach, kartkówki,
dwóch kolokwiów oraz ewentualnego projektu.



Warunkiem pisania egzaminu jest zaliczenie
ćwiczeń.



Egzamin będzie miał charakter testowy.
Końcowa ocena będzie średnią zaliczenia
ćwiczeń i wyniku testu.

Bibliografia



Lech Banachowski, Krzysztof Stencel, Bazy danych Projektowanie

aplikacji na serwerze, Akademicka Oficyna Wydawnicza EXIT, 2001.



Lech Banachowski, Bazy danych Tworzenie aplikacji, Akademicka

Oficyna Wydawnicza PLJ, 1998.



Lech Banachowski, Elżbieta Mrówka Matejewska, Krzysztof Stencel

Systemy baz danych. Wykłady i ćwiczenia. Wydawnictwo PJWSTK, 2004.



Raghu Ramakrishnan and Johannes Gehrke, Database Management

Systems, 3nd edition, McGraw-Hill, 2000.



Jeffrey D. Ullamn, Jennifer Widom, Podstawowy wykład z baz danych,

WNT 1999.



Hector Garcia-Molina, Jeffrey D. Ullman, Jennifer Widom, Implementacja

systemów baz danych, WNT, 2003



Paul Beynon-Davies, Systemy baz danych, WNT 1998.



Dokumentacja Oracle oraz książki na temat baz danych, w szczególności
na temat Oracle.

Projektowanie

schematów baz danych

Przypomnienie

Obiekty modelu danych

Encja

Coś co istnieje, jest odróżnialne od innych, o

czym informację trzeba znać lub
przechowywać. (najlepszym polskim
odpowiednikiem jest słowo byt). Miejsce, w
którym będziemy gromadzić informację
jednego typu (np. o pracownikach w jednej
encji, a o samochodach – w drugiej)

Obiekty modelu danych

Atrybut

Własność encji, to co ją opisuje,

charakteryzuje. Czyli to, jakiego
rodzaju informacje nas interesują (np.
dla pracownika chcemy przykładowo

znać imię, nazwisko, adres i telefon).

Obiekty modelu danych

Związek

Uporządkowana lista encji, poszczególne

encje mogą wystąpić wielokrotnie.
Innymi słowy zależność miedzy dwoma
(lub więcej) encjami, to co je łączy
(Związek między encjami Pracownik i
Samochod: Pracownik ma samochod).

Obiekty modelu danych i

odpowiadające im obiekty bazy

danych

Obiekty

modelu

danych

Obiekty

bazy

danych

Przykłady

Encja

Tabela

Pracownik,

Samochod

Atrybut

Pole

Nazwisko, Imie,
Marka, Model, itd

Związek

Relacja

Pracownik ma

samochod

Ilustracja graficzna

Związek

Encje

Przykładowy

atrybut

Klucze

Klucz główny

(jednoznaczny identyfikator)

Jest to atrybut lub zbiór atrybutów encji, dla których

wartości jednoznacznie identyfikują każdy wiersz. Np.
dla encji Osoba może to być Pesel. Klucz główny ma dwie
podstawowe własności: unikatowość (w każdym wierszu
wartość klucza jest inna, klucza nie można powtórzyć) i
minimalność (nie potrzeba więcej atrybutów, aby
zapewnić unikatowość). Ponadto w kluczu nie może być
NULL. Jeśli klucz jest złożony z kilku atrybutów, to w
żadnym z nich nie może być wartości NULL.

Klucze

Klucz jednoznaczny

(nazywany też

kluczem alternatywnym lub w

skrócie kluczem)

Ma tę samą własność co klucz główny

przy czym klucz główny jest tylko
jeden, kluczy jednoznacznych w tabeli
może być więcej niż jeden.

Klucze

Klucz obcy

Jest to zbiór złożony z jednej lub więcej

kolumn, których wartości występują jako
wartości ustalonego klucza głównego lub
jednoznacznego w tej samej lub innej
tabeli i są interpretowane jako wskaźniki
do wierszy w tej drugiej tabeli.

Typy związków



Związek jednojednoznaczny – jeden do

jeden.



Związek jednoznaczny – jeden do wiele.



Związek wieloznaczny – wiele do wiele.

Związek jednoznaczny – jeden do

wiele



Jeden pracownik ma wiele samochodów, jeden

samochód należy tylko do jednego pracownika. Mamy tu

klasyczną sytuację jeden do wiele (jeden pracownik –

wiele samochodów).

IDPracownika jest takim
samym atrybutem
samochodu jak np.
Marka, ponieważ ten
samochód ma jednego
właściciela, tak samo jak
jedną markę.

Kropka po stronie wiele.
IDPracownika
występuje w tabeli
Samochód wiele razy. W
tabeli pracownik – raz.

Związek wieloznaczny – wiele do

wiele



Jeden pracownik może mieć wiele samochodów,
a jeden samochód należy do wielu pracowników.
Widzimy związek wiele do wiele.



Związków takich nie możemy bezpośrednio
reprezentować w relacyjnej bazie danych.
Musimy zatem rozłożyć ten związek na dwa
związki jeden do wiele, czyli stworzyć tabelę
pośrednią (asocjacyjną) pomiędzy naszymi
tabelami.

Związek wieloznaczny –

reprezentacja

Sposób 1

Kluczem tej tabeli są klucze tabel
Pracownik i Samochod. Jest to klucz
obcy. Relacje były identyfikujące, a ta
encja jest encją zależną

Związek wieloznaczny –

reprezentacja

Sposób 2

Ta encja ma własny klucz główny. Jest
więc niezależna. Relacje są
nieidentyfikujące.

Postacie Normalne



Celem normalizacji jest uniknięcie redundancji, czyli zbędnego powtarzania informacji.



Dzięki normalizacji unikamy anomalii przy:

–

Wstawianiu

–

Usuwaniu

–

Aktualizacji

Pierwsza postać normalna:

Każdy atrybut zawiera informację

jednostkową.

Brak 1NF

Przez to pole brak pierwszej postaci
normalnej

Pierwsza postać normalna:

Każdy atrybut zawiera informację

jednostkową.

Jak poprawić?

Druga postać normalna:

Każdy atrybut nie wchodzący w skład klucza

zależy od całego klucza, a nie od jego części.

Brak 2NF

To pole zależy tylko od
pola KodTowaru, a więc
od części klucza.

To pole zależy od całego
klucza, a więc klucz nie
jest za duży

Druga postać normalna:

Każdy atrybut nie wchodzący w skład klucza

zależy od całego klucza, a nie od jego części.

Jak poprawić?

Trzecia postać normalna:

Nie ma atrybutów zależących od części klucza

ani nawet przechodnio od klucza.

Brak 3NF

To pole zależy od pola ZakladPracy,
a dopiero pole ZakladPracy zależy od
klucza tabeli. Jest to przechodnia
zależność od klucza.

Trzecia postać normalna:

Nie ma atrybutów zależących od części klucza

ani nawet przechodnio od klucza.

Jak poprawić?

Projektujemy schemat bazy

danych



Opracuj schemat bazy danych Geografia. Uwzględnij
wiadomości o państwach, miastach, morzach,
językach urzędowych i kontynentach, wiedząc, że:

–

Jedno państwo leży na jednym lub wielu kontynentach.
Każde miasto znajduje się w jednym państwie.

–

Każdy język może być językiem urzędowym dla
jednego lub wielu państw, a każde państwo może mieć
jeden lub wiele języków urzędowych.

–

Każde morze oblewa jedno lub kilka państw, natomiast
państwo może graniczyć z jednym, z kilkoma lub z
żadnym z mórz (uwzględnij długość granicy morskiej).

Diagram związków encji