Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Łódź 2008 Banki danych WYKŁAD 4 dr Łukasz Murowaniecki T-109.

Podobne prezentacje


Prezentacja na temat: "Łódź 2008 Banki danych WYKŁAD 4 dr Łukasz Murowaniecki T-109."— Zapis prezentacji:

1 Łódź 2008 Banki danych WYKŁAD 4 dr Łukasz Murowaniecki T-109

2 Łó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

3 Łó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;

4 Łó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...

5 Łó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)

6 Łó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 Boycea - Codda = BCNF Czwarta postać normalna Piąta postać normalna

7 Łó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ą.

8 Łódź 2008 Normalizacja danych ImięNazwiskoAdresy JanKowalskiGłówny: Łódź, Włókniarzy 10 m. 9 Korespondencyjny: Łódź, Wyszyńskiego 23 m. 14 AnnaMalinowskaGłówny: Warszawa, Jerozolimskie 102 StefanKwiatkowskiGłówny: Kraków, Stary Rynek 8 m. 5 Korespondencyjny: Kraków, Dworcowa 12/13 ImięNazwiskoRodzaj adresu KodMiejsco- wość UlicaNr domu Nr lokalu JanKowalskiG99-999ŁódźAl. Włókniarzy109 K98-088ŁódźWyszyńskiego2314 AnnaMalinowskaG01-010WarszawaAl. Jerozolimskie102 StefanKwiatkowskiG34-567KrakówStart Rynek85 K33-333KrakówDworcowa12/13

9 Łódź 2008 Normalizacja danych ImięNazwiskoRodzaj adresu KodMiejsco- wość UlicaNr domu Nr lokalu JanKowalskiG99-999ŁódźAl. Włókniarzy109 K98-088ŁódźWyszyńskiego2314 AnnaMalinowskaG01-010WarszawaAl. Jerozolimskie102 StefanKwiatkowskiG34-567KrakówStart Rynek85 K33-333KrakówDworcowa12/13 ImięNazwiskoRodzaj adresu KodMiejsco- wość UlicaNr domu Nr lokalu JanKowalskiG99-999ŁódźAl. Włókniarzy109 JanKowalskiK98-088ŁódźWyszyńskiego2314 AnnaMalinowskaG01-010WarszawaAl. Jerozolimskie102 StefanKwiatkowskiG34-567KrakówStart Rynek85 StefanKwiatkowskiK33-333KrakówDworcowa12/13 1FN

10 Łó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.

11 Łó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ęNazwiskoLatNr dowoduMarkaNr rej. JanKowalski50ADE23212FordEL12345 JanKowalski50ADE23212FiatEL9123E StefanKwiatkowski27DD123456OpelKR34212

12 Łó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.

13 Łódź 2008 Normalizacja danych Id oso by ImięNazwiskoId adr esu Rodzaj adresu KodMiejsco- wość UlicaNr domu Nr lokal u 1JanKowalski1G99-999ŁódźAl. Włókniarzy109 1JanKowalski2K98-088ŁódźWyszyńskiego2314 2AnnaMalinowska3G01-010WarszawaAl. Jerozolimskie102 3StefanKwiatkowski4G34-567KrakówStart Rynek85 3StefanKwiatkowski5K33-333KrakówDworcowa12/13 Id osoby ImięNazwisko 1JanKowalski 2AnnaMalinowska 3StefanKwiatkowski Id adresu Id osoby KodMiejsco- wość UlicaNr domu Nr lokalu ŁódźAl. Włókniarzy ŁódźWyszyńskiego WarszawaAl. Jerozolimskie KrakówStart Rynek KrakówDworcowa12/13 1FN 2FN

14 Łó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.

15 Łódź 2008 Normalizacja danych Id osoby ImięNazwisko 1JanKowalski 2AnnaMalinowska 3StefanKwiatkowski Id adresu Id osoby KodMiejsco- wość UlicaNr domu Nr lokalu ŁódźAl. Włókniarzy ŁódźWyszyńskiego WarszawaAl. Jerozolimskie KrakówStart Rynek KrakówDworcowa12/13 Id osoby ImięNazwisko 1JanKowalski 2AnnaMalinowska 3StefanKwiatkowski Id adr esu Id oso by Id adr esu KodMiejsco- wość UlicaNr domu Nr lok alu ŁódźAl. Włókniarzy ŁódźWyszyńskiego WarszawaAl. Jerozolimskie KrakówStart Rynek KrakówDworcowa12/13 2FN 3FN

16 Łódź 2008 Normalizacja danych Relacja jest postaci normalnej Boycea - Codda 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

17 Łódź 2008 Normalizacja danych 12 reguł Codda 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.

18 Łó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.

19 Łó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).

20 Łó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.

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


Pobierz ppt "Łódź 2008 Banki danych WYKŁAD 4 dr Łukasz Murowaniecki T-109."

Podobne prezentacje


Reklamy Google