Banki danych
advertisement
Banki danych WYKŁAD 4 dr Łukasz Murowaniecki [email protected] 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 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 Język SQL - DCL Polecenia DCL 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 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. 9 Korespondencyjny: 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. 5 Korespondencyjny: 33-333 Kraków, Dworcowa 12/13 Imię Nazwisko Rodzaj adresu Kod Miejscowość 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 K 33-333 Kraków Dworcowa 12/13 Łódź 2008 5 Normalizacja danych 1FN Imię Nazwisko Rodzaj adresu Kod Miejscowość 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 K 33-333 Kraków Dworcowa 12/13 5 Imię Nazwisko Rodzaj adresu Kod Miejscowość 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 Stefan Kwiatkowski K 33-333 Kraków Dworcowa 12/13 Łódź 2008 5 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. 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 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). Łó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 1FN Id oso by Imię Nazwisko Id adr esu Rodzaj adresu Kod Miejscowość Ulica Nr domu Nr lokal u 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 3 Stefan Kwiatkowski 5 K 33-333 Kraków Dworcowa 12/13 Id adresu Id osoby Kod Miejscowość Ulica Nr domu Nr lokalu 1 1 99-999 Łódź Al. Włókniarzy 10 9 2 1 98-088 Łódź Wyszyńskiego 23 14 2FN Id osoby Imię Nazwisko 1 Jan Kowalski 3 2 01-010 Warszawa Al. Jerozolimskie 102 2 Anna Malinowska 4 3 34-567 Kraków Start Rynek 8 3 Stefan Kwiatkowski 5 3 33-333 Kraków Dworcowa 12/13 Łódź 2008 5 5 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 Nazwisko Id adresu Id osoby Kod Miejscowość Ulica Nr domu Nr lokalu 1 1 99-999 Łódź Al. Włókniarzy 10 9 14 Id osoby Imię 1 Jan Kowalski 2 1 98-088 Łódź Wyszyńskiego 23 2 Anna Malinowska 3 2 01-010 Warszawa Al. Jerozolimskie 102 3 Stefan Kwiatkowski 4 3 34-567 Kraków Start Rynek 8 5 3 33-333 Kraków Dworcowa 12/13 2FN 3FN Nazwisko 5 Id adr esu Id oso by Id adr esu Kod Miejscowość Ulica Nr domu Nr lok alu 1 1 1 99-999 Łódź Al. Włókniarzy 10 9 14 Id osoby Imię 1 Jan Kowalski 2 1 2 98-088 Łódź Wyszyńskiego 23 2 Anna Malinowska 3 2 3 01-010 Warszawa Al. Jerozolimskie 102 3 Stefan Kwiatkowski 4 3 4 34-567 Kraków Start Rynek 8 5 3 5 33-333 Kraków Dworcowa 12/13 Łódź 2008 5 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 BCNF Film (tytuł, rok, długość, studio) Obsada (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). Łódź 2008
