dr Łukasz Murowaniecki T-109

Prezentacja na temat: "dr Łukasz Murowaniecki T-109"— Zapis prezentacji:

1 dr Łukasz Murowaniecki lukaszm@uni.lodz.pl T-109
Banki danych WYKŁAD 4 dr Łukasz Murowaniecki T-109 Łódź 2008

2 Język SQL - DDL Polecenia DDL Przykłady obiektów
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

3 Język SQL - DDL Polecenia DDL na przykładzie obiektu TABLE
CREATE 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

4 Język SQL - DCL Polecenia DCL Ogólna składnia Uprawnienia
GRANT – nadanie praw użytkownikowi lub grupie użytkowników REVOKE – odebranie praw Ogólna składnia GRANT uprawnienie ON obiekt TO podmiot; REVOKE uprawnienie ON obiekt FROM podmiot; Uprawnienia SELECT INSERT UPDATE DELETE DROP CREATE ... Łódź 2008

5 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

6 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

7 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

8 Normalizacja danych Imię Nazwisko Adresy Jan Kowalski
Główny: Łódź, Włókniarzy 10 m. 9 Korespondencyjny: Łódź, Wyszyńskiego 23 m. 14 Anna Malinowska Główny: Warszawa, Jerozolimskie 102 Stefan Kwiatkowski Główny: Kraków, Stary Rynek 8 m. 5 Korespondencyjny: 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 Wyszyńskiego 23 14 Anna Malinowska 01-010 Warszawa Al. Jerozolimskie 102 Stefan Kwiatkowski 34-567 Kraków Start Rynek 8 5 33-333 Dworcowa 12/13 Łódź 2008

9 Normalizacja danych 1FN 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 Wyszyńskiego 23 14 Anna Malinowska 01-010 Warszawa Al. Jerozolimskie 102 Stefan Kwiatkowski 34-567 Kraków Start Rynek 8 5 33-333 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 Wyszyńskiego 23 14 Anna Malinowska 01-010 Warszawa Al. Jerozolimskie 102 Stefan Kwiatkowski 34-567 Kraków Start Rynek 8 5 33-333 Dworcowa 12/13 1FN Łódź 2008

10 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

11 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 Fiat EL9123E Stefan Kwiatkowski 27 DD123456 Opel KR34212 Łódź 2008

12 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

13 Normalizacja danych 1FN 2FN 1 Jan Kowalski G 99-999 Łódź
Id osoby Imię Nazwisko Id adresu Rodzaj adresu Kod Miejsco- wość Ulica Nr domu Nr lokalu 1 Jan Kowalski G 99-999 Łódź Al. Włókniarzy 10 9 2 K 98-088 Wyszyńskiego 23 14 Anna Malinowska 3 01-010 Warszawa Al. Jerozolimskie 102 Stefan Kwiatkowski 4 34-567 Kraków Start Rynek 8 5 33-333 Dworcowa 12/13 1FN Id adresu Id osoby Kod Miejsco- wość Ulica Nr domu Nr lokalu 1 99-999 Łódź Al. Włókniarzy 10 9 2 98-088 Wyszyńskiego 23 14 3 01-010 Warszawa Al. Jerozolimskie 102 4 34-567 Kraków Start Rynek 8 5 33-333 Dworcowa 12/13 2FN Id osoby Imię Nazwisko 1 Jan Kowalski 2 Anna Malinowska 3 Stefan Kwiatkowski Łódź 2008

14 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

15 Normalizacja danych 2FN 3FN 1 99-999 Łódź Al. Włókniarzy 10 9 2 98-088
Id adresu Id osoby Kod Miejsco- wość Ulica Nr domu Nr lokalu 1 99-999 Łódź Al. Włókniarzy 10 9 2 98-088 Wyszyńskiego 23 14 3 01-010 Warszawa Al. Jerozolimskie 102 4 34-567 Kraków Start Rynek 8 5 33-333 Dworcowa 12/13 Id osoby Imię Nazwisko 1 Jan Kowalski 2 Anna Malinowska 3 Stefan Kwiatkowski 2FN 3FN Id adresu Id osoby 1 2 3 4 5 Id adresu Kod Miejsco- wość Ulica Nr domu Nr lokalu 1 99-999 Łódź Al. Włókniarzy 10 9 2 98-088 Wyszyńskiego 23 14 3 01-010 Warszawa Al. Jerozolimskie 102 4 34-567 Kraków Start Rynek 8 5 33-333 Dworcowa 12/13 Id osoby Imię Nazwisko 1 Jan Kowalski 2 Anna Malinowska 3 Stefan Kwiatkowski Łódź 2008

16 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.” Obsada (tytuł, rok, długość, studio, aktor) Klucz kandydujący: tytuł, rok, aktor Film (tytuł, rok, długość, studio) Obsada (tytuł, rok, aktor) BCNF Łódź 2008

17 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

18 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

19 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

20 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

21 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). Łódź 2008