Łódź 2008

Banki danychWYKŁAD 4

dr Łukasz Murowanieckilukaszm@uni.lodz.pl

T-109

Łódź 2008

Język SQL - DDL

Polecenia DDL CREATE – utworzenie obiektu ALTER – zmiana własności obiektu DROP – usunięcie obiektu

Przykłady obiektów DATABASE TABLE VIEW INDEX USER PROCEDURE

Łódź 2008

Język SQL - DDL

Polecenia DDL na przykładzie obiektu TABLECREATE TABLE zespol2

(ze_kod varchar(2) NOT NULL,

ze_nazwa varchar(2) NOT NULL,

ze_pensja_min number NOT NULL);

ALTER TABLE zespol2

ADD COLUMN ze_opis varchar(100) NULL;

DROP TABLE zespol2;

Łódź 2008

Język SQL - DCL

Polecenia DCL GRANT – nadanie praw użytkownikowi lub grupie

użytkowników REVOKE – odebranie praw

Ogólna składniaGRANT uprawnienie ON obiekt TO podmiot;REVOKE uprawnienie ON obiekt FROM podmiot;

Uprawnienia SELECT INSERT UPDATE DELETE DROP CREATE ...

Łódź 2008

Normalizacja danych

Celem normalizacji jest usunięcie niepożądanych cech struktury bazy danych.

Przykłady cech niepożądanych to: redundancja (nadmiarowość) danych, anomalia modyfikacji, anomalia usunięć.

W wyniku normalizacji zmienia się struktura bazy danych, natomiast dane nie są tracone.

Normalizacja jest dokonywana poprzez przekształcanie struktury bazy danych do kolejnych postaci normalnych (Normal Form)

Łódź 2008

Normalizacja danych

Pierwsza postać normalna = 1 PN = 1 NF Druga postać normalna = 2 PN = 2 NF Trzecia postać normalna = 3 PN = 3 NF Postać normalna Boyce’a - Codd’a = BCNF Czwarta postać normalna Piąta postać normalna

Łódź 2008

Normalizacja danych

Pierwsza postać normalna oznacza, że tabela nie zawiera powtarzających się grup informacji. To znaczy, że każda kolumna jest wartością skalarną (atomową), a nie macierzą lub listą czy też czymkolwiek, co posiada własną strukturę.

1 PN jest konieczna, aby tabelę można było nazwać relacją.

Łódź 2008

Normalizacja danych

Imię Nazwisko Adresy

Jan Kowalski Główny: 99-999 Łódź, Włókniarzy 10 m. 9Korespondencyjny: 98-088 Łódź, Wyszyńskiego 23 m. 14

Anna Malinowska

Główny: 01-010 Warszawa, Jerozolimskie 102

Stefan

Kwiatkowski

Główny: 34-567 Kraków, Stary Rynek 8 m. 5Korespondencyjny: 33-333 Kraków, Dworcowa 12/13

Imię Nazwisko Rodzaj adresu

Kod Miejsco-wość

Ulica Nr domu

Nr lokalu

Jan Kowalski G 99-999

Łódź Al. Włókniarzy 10 9

K 98-088

Łódź Wyszyńskiego 23 14

Anna Malinowska

G 01-010

Warszawa

Al. Jerozolimskie 102

Stefan

Kwiatkowski

G 34-567

Kraków Start Rynek 8 5

K 33-333

Kraków Dworcowa 12/13

Łódź 2008

Normalizacja danych

Imię Nazwisko Rodzaj adresu

Kod Miejsco-wość

Ulica Nr domu

Nr lokalu

Jan Kowalski G 99-999

Łódź Al. Włókniarzy 10 9

K 98-088

Łódź Wyszyńskiego 23 14

Anna Malinowska

G 01-010

Warszawa

Al. Jerozolimskie 102

Stefan

Kwiatkowski

G 34-567

Kraków Start Rynek 8 5

K 33-333

Kraków Dworcowa 12/13

Imię Nazwisko Rodzaj adresu

Kod Miejsco-wość

Ulica Nr domu

Nr lokalu

Jan Kowalski G 99-999

Łódź Al. Włókniarzy 10 9

Jan Kowalski K 98-088

Łódź Wyszyńskiego 23 14

Anna Malinowska

G 01-010

Warszawa

Al. Jerozolimskie 102

Stefan

Kwiatkowski

G 34-567

Kraków Start Rynek 8 5

Stefan

Kwiatkowski

K 33-333

Kraków Dworcowa 12/13

1FN

Łódź 2008

Normalizacja danych

Zależność funkcjonalna: Oznacza, że znając wartość jednego atrybutu, zawsze

możemy określić wartość innego. Symbolem stosowanym w teorii relacji jest strzałka

umieszczona pomiędzy dwoma atrybutami, na przykład A->B, co czyta się następująco: "A określa B".

Atrybut Y relacji R jest zależny funkcjonalnie od atrybutu X wtedy i tylko wtedy, gdy każdej wartości atrybutu X odpowiada dokładnie jedna wartość atrybutu Y.

Łódź 2008

Normalizacja danych

Zależność funkcjonalna Jeśli dana wartość atrybutu Y występuje w wielu krotkach relacji R to

jeśli atrybut X jest zależny od Y to w tych krotkach musi wystąpić ta sama wartość X.

Atrybut Y jest w pełni funkcjonalnie zależny od atrybutu X, jeśli jest funkcjonalnie zależny od niego ale nie jest funkcjonalnie zależny od żadnego podzbioru atrybutu X (atrybut X jest atrybutem złożonym).

Imię Nazwisko Lat Nr dowodu

Marka Nr rej.

Jan Kowalski 50 ADE23212 Ford EL12345

Jan Kowalski 50 ADE23212 Fiat EL9123E

Stefan

Kwiatkowski

27 DD123456 Opel KR34212

Łódź 2008

Normalizacja danych

Relacja jest w drugiej postaci normalnej jeśli jest w pierwszej postaci normalnej oraz atrybuty nie wchodzące w skład klucza głównego są w pełni

funkcjonalnie zależne od całego klucza głównego, czyli nie są zależne od innego podzbioru atrybutów.

Jeżeli występują atrybuty zależne od części klucza głównego, to atrybuty te oraz część klucza stanowią podstawę od nowej relacji.

Łódź 2008

Normalizacja danych

Id osoby

Imię Nazwisko Id adresu

Rodzaj adresu

Kod Miejsco-wość

Ulica Nr domu

Nr lokalu

1 Jan Kowalski 1 G 99-999

Łódź Al. Włókniarzy 10 9

1 Jan Kowalski 2 K 98-088

Łódź Wyszyńskiego 23 14

2 Anna Malinowska

3 G 01-010

Warszawa

Al. Jerozolimskie

102

3 Stefan Kwiatkowski

4 G 34-567

Kraków Start Rynek 8 5

3 Stefan Kwiatkowski

5 K 33-333

Kraków Dworcowa 12/13

Id osoby

Imię Nazwisko

1 Jan Kowalski

2 Anna Malinowska

3 Stefan

Kwiatkowski

Id adresu

Id osoby

Kod Miejsco-wość

Ulica Nr domu

Nr lokalu

1 1 99-999

Łódź Al. Włókniarzy 10 9

2 1 98-088

Łódź Wyszyńskiego 23 14

3 2 01-010

Warszawa

Al. Jerozolimskie

102

4 3 34-567

Kraków Start Rynek 8 5

5 3 33-333

Kraków Dworcowa 12/13

1FN

2FN

Łódź 2008

Normalizacja danych

Relacja jest w trzeciej postaci normalnej jeżeli jest w drugiej postaci normalnej oraz żaden z jej atrybutów nie wchodzący w skład klucza

kandydującego nie jest przechodnio funkcjonalnie zależny od żadnego klucza kandydującego tej relacji.

Jeżeli w relacji występują atrybuty zależne od innego atrybutu, nie będącego częścią klucza kandydującego, to atrybuty te stanowią podstawę do nowej relacji.

Łódź 2008

Normalizacja danych

Id osoby

Imię Nazwisko

1 Jan Kowalski

2 Anna Malinowska

3 Stefan

Kwiatkowski

Id adresu

Id osoby

Kod Miejsco-wość

Ulica Nr domu

Nr lokalu

1 1 99-999

Łódź Al. Włókniarzy 10 9

2 1 98-088

Łódź Wyszyńskiego 23 14

3 2 01-010

Warszawa

Al. Jerozolimskie

102

4 3 34-567

Kraków Start Rynek 8 5

5 3 33-333

Kraków Dworcowa 12/13Id osoby

Imię Nazwisko

1 Jan Kowalski

2 Anna Malinowska

3 Stefan

Kwiatkowski

Id adresu

Id osoby

1 1

2 1

3 2

4 3

5 3

Id adresu

Kod Miejsco-wość

Ulica Nr domu

Nr lokalu

1 99-999

Łódź Al. Włókniarzy 10 9

2 98-088

Łódź Wyszyńskiego 23 14

3 01-010

Warszawa Al. Jerozolimskie

102

4 34-567

Kraków Start Rynek 8 5

5 33-333

Kraków Dworcowa 12/13

2FN

3FN

Łódź 2008

Normalizacja danych

Relacja jest postaci normalnej Boyce’a - Codd’a wtedy i tylko wtedy, gdy elementem determinującym każdej nietrywialnej, lewostronnie nieredukowalnej zależności funkcyjnej jest klucz kandydujący.

wg Wiki: „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.”

BCNF

Obsada (tytuł, rok, długość, studio, aktor)

Film (tytuł, rok, długość, studio)

Obsada (tytuł, rok, aktor)

Klucz kandydujący: tytuł, rok, aktor

Łódź 2008

Normalizacja danych

12 reguł Codd’a dotyczących przedstawiania relacji jako tabeli: Reguła 0: Aby można było uznać dany system za system

zarządzania relacyjnych baz danych, musi on wykorzystywać (wyłącznie) relacyjne mechanizmy do zarządzania bazą danych.

Reguła 1 - Reguła informacyjna: jest to po prostu wymaganie, aby wszystkie informacje zawarte w bazie danych były przedstawiane w jeden i tylko jeden sposób, mianowicie za pomocą wartości umieszczanych w kolumnach w obrębie wierszy tabel.

Reguła 2 - Reguła gwarantowanego dostępu: stanowi ona, że każda poszczególna wartość skalarna w bazie danych musi mieć zapewnioną możliwość logicznego adresowania, wykorzystując nazwę zawierającej ją tabeli, nazwę zawierającej ją kolumny oraz wartość klucza podstawowego zawierającego ją wiersza. SQL spełnia tę regułę w przypadku tabel posiadających klucz podstawowy, ale w ogóle nie wymaga, aby tabele posiadały ten klucz.

Łódź 2008

Normalizacja danych

Reguła 3 - Uporządkowana obsługa wartości NULL: wymaga się, aby DBMS obsługiwał reprezentację brakujących informacji oraz informacji nieadekwatnych, to znaczy uporządkowanych, odmiennych od wszystkich wartości prawidłowych oraz niezależnych od typu danych. Przyjmuje się również, że DBMS musi obsługiwać taką reprezentację w uporządkowany sposób. W SQL-u występuje wartość NULL, która jest wykorzystywana zarówno dla wartości brakujących, jak i dla wartości nieadekwatnych zamiast dwóch oddzielnych symboli.

Łódź 2008

Normalizacja danych

Reguła 4 - Aktywny katalog dostępny na bieżąco, oparty na modelu relacyjnym: wymaga się, aby system obsługiwał wbudowany katalog relacyjny z bieżącym dostępem dla uprawnionych użytkowników używających ich zwykłego języka zapytań. SQL spełnia ten wymóg.

Reguła 5 - Reguła dotycząca podjęzyka obsługi danych o pełnych możliwościach: System musi obsługiwać przynajmniej jeden język relacyjny, który:

charakteryzuje się liniową składnią, może być używany zarówno w trybie interaktywnym, jak i w

obrębie programów aplikacyjnych obsługuje operacje definiowania danych (łącznie z definiowaniem

perspektyw), operacje manipulowania danymi (aktualizację, także wyszukiwanie), ograniczenia związane z bezpieczeństwem i integralnością oraz operacje zarządzania transakcjami (rozpoczynanie, zapis zmian i ponowny przebieg).

Łódź 2008

Normalizacja danych

Reguła 6 - Reguła aktualizacji perspektyw: wszystkie perspektywy, które teoretycznie dają się aktualizować, muszą być aktualizowane przez system.

Reguła 7 - Polecenia wstawiania, aktualizacji oraz usuwania w języku wysokiego poziomu: wymaga się, aby system obsługiwał operatory INSERT, UPDATE oraz DELETE dotyczące całych zbiorów.

Reguła 8 - Fizyczna niezależność danych: Zmiana mechanizmy przechowywania danych nie wpływa na aplikacje korzystające z bazy danych. Każdy istniejący produkt wykazuje pewną fizyczną zależność, ale SQL jest pod tym względem lepszy od większości innych języków programowania.

Reguła 9 - Logiczna niezależność danych: Zmiana w tabelach podstawowych (która nie powoduje utraty danych) nie wpływa na aplikacje korzystające z bazy danych.

Łódź 2008

Normalizacja danych

Reguła 10 - Niezależność integralnościowa: ograniczenia integralnościowe muszą być specyfikowane pojedynczo z programu aplikacyjnego i przechowywane w katalogu. Musi istnieć możliwość dokonywania stosownej zmiany takiego ograniczenia bez zbędnego oddziaływania na istniejące aplikacje.

Reguła 11 - Niezależność dystrybucyjna: istniejące aplikacje powinny działać bez zakłóceń:

kiedy następuje wprowadzenie rozproszonej wersji DBMS oraz kiedy istniejące dane rozproszone są ponownie dystrybuowane w

obrębie systemu. Reguła 12 - Reguła nieprowadzenia "działalności

wywrotowej": jeśli system jest wyposażony w interfejs niskiego poziomu (operacje na pojedynczych rekordach), nie może być użyty do prowadzenia działalności wywrotowej (np. omijania zabezpieczeń relacyjnych lub ograniczeń integralnościowych).