Wykład 1
Systemy baz
danych
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