1 Technologie informacyjne WYKŁAD IV WPROWADZENIE DO BAZ DANYCH MAIL: WWW: a.dudek@pwr.edu.pl http://wgrit.ae.jgora.pl/ad
Bazy danych 2 Baza danych to zbiór danych o określonej strukturze. zapisany na zewnętrznym (trwałym) nośniku pamięci komputera. Zgodnie z tą definicją bazami danych są również systemy plików na dyskach komputera, jednak nowoczesne bazy danych są powiązane z wyspecjalizowanymi programami zarządzającymi określanymi często jako SZBD (system zarządzania bazą danych) takimi jak: ORACLE, MS SQL. POSTGRESQL, MYSQL, FIREBIRD, SAP DB, DB2, MS ACCESS. (i inne)
Bazy danych 3 Programy tego typu powinny: - Zapewniać odpowiednią organizację danych na poziomie fizycznym (w pamięci komputera); - Dbać o zachowanie integralności danych oraz umożliwiać definiowanie reguł integralności; - Dbać o poufność danych i umożliwiać dostęp do nich tylko autoryzowanym użytkownikom; - Zapewniać możliwość pracy współbieżnej wielu użytkownikom równocześnie i unikać tzn. zderzeń poprzez zaawansowane mechanizmy takie jak transakcje, blokowanie pesymistyczne czy blokowanie optymistyczne; - Zapewniać niezawodność danych i eliminować w miarę możliwości błędy związane z zapisem / odczytem danych z nośników pamięci poprzez mechanizm tzn. mirroringu oraz możliwość tworzenia kopii zapasowych; - Definiować język dostępu do danych. W przypadku zdecydowanej większości baz danych tym językiem jest strukturalny język zapytań SQL Structural Query Language
Bazy danych 4 Można wyróżnić cztery najważniejsze modele baz danych (choć należy nadmienić, iż praktycznie wszystkie programy typu SZBD funkcjonują w modelu relacyjnym): Model hierarchiczny Baza danych w tym modelu reprezentuję strukturę drzewiastą z jednym wydzielonym obiektem głównym i powiązaniami jednokierunkowymi z pozostałymi obiektami. Zgodnie z nazwą w tym modelu zakłada się, iż pomiędzy modelowanymi obiektami opisującymi fragmenty rzeczywistości zawsze zachodzi związek typu obiekt nadrzędny obiekt podrzędny Szybko okazało się, iż to założenie zbyt mocno ogranicza proces modelowania i aktualnie ten model jest tylko modelem historycznym. Model sieciowy Model sieciowy usuwał ograniczenia modelu hierarchicznego umożliwiając definiowanie dowolnych powiązań pomiędzy modelowanymi obiektami. Został zastąpiony przez model relacyjny, gdyż ten ostatni okazał się bardziej efektywny i łatwiejszy do implementacji.
Bazy danych 5 Model obiektowy Model, w którym do opisu danych wykorzystywane są pojęcia z zakresu programowania obiektowego takie jak dziedziczenie, enkapsulacja, polimorfizm itp. Model ten powstał mniej więcej na początku lat osiemdziesiątych i nie doczekał się żadnych istotnych realizacji praktycznych. Zamiast tego w ostatnich kilku standardem latach stało się podejście mieszane, mapujące relacyjne bazy danych na obiekty języka Java czy C#, wykorzystujące technologie typu ORM/ORB (Object Relational Mapping/ Object Relational Broker) takie jak Hibernate czy Java Persistence API Model relacyjny Model ten jest rozszerzeniem matematycznego pojęcia relacji (czyli podzbioru iloczynu Kartezjańskiego). Został on opracowany przez E. F. Codda, i mniej więcej od lat osiemdziesiątych poprzedniego stulecia zdecydowana większość SZBD jest oparta właśnie o ten model. Relacja jest pewnym uogólnieniem pojęcia tabeli, przy czym w przeciwieństwie do tabel znanych z MS Excel czy MS Word tabela ta jest zapisywana bezpośrednio w pamięci trwałej komputera a ponadto musi spełniać warunki:
Bazy danych relacja w modelu relacyjnym baz danych musi spełniać warunki: Tabela musi mieć określoną jednoznaczną nazwę; Każda kolumna tabeli (pole, atrybut) musi posiadać jednoznaczną nazwę; 6 Każda kolumna tabeli musi zawierać dane określonego typu (np. tekst, liczbę, wartość logiczną, datę, format waluty, itp.); Nie jest istotna kolejność kolumn; Nie jest (nie powinna być) istotna kolejność wierszy (rekordów); Dane w poszczególnych polach (na przecięciu kolumn i wierszy) na są niepodzielne (atomowe); Każda tabela powinna mieć zdefiniowany klucz główny (pole/a niepuste, niepowtarzalne, jednoznacznie identyfikujące rekord). Poprawnie zaprojektowane relacyjne bazy danych powinny spełniać postulaty tzw. III postaci normalnej, co zazwyczaj jest osiągane poprzez proces normalizacji bazy.
Normalizacja Model logiczny Encja, krotka, atrybut Model fizyczny Tabela, rekord, pole 7 Bazy danych składają się z dużej ilości tabel połączonych ze sobą i spełniających warunki trzeciej postaci normalnej Pierwsza postać normalna Dane w poszczególnych polach są niepodzielne (np. nie powinno być pola Imię_i_nazwisko tylko dwa osobne pola) oraz nie występuje wielowymiarowość (np. w tabeli faktura pola pozycja1, pozycja2, pozycja3 itp). Jedynym wyjątkiem od reguły w niektórych sytuacjach jest umieszczenie w tabeli dwóch pól opisujących podobne dane (imię, drugie_imię). Unikanie wielowymiarowości jest związane z rozdzieleniem tabel. W przykładzie z fakturą powinno się zaprojektować dwie osobne tabele: faktura i pozycje faktury połączone sprzężone ze sobą. Każda tabela ma w I postaci normalnej zdefiniowany klucz główny (pole/a niepuste, niepowtarzalne, jednoznacznie identyfikujące rekord)
Normalizacja 8 Druga postać normalna Żaden podzbiór klucza głównego składającego się z wielu pól nie może sam stanowić klucza (+ pierwsza postać normalna). Najprostszym sposobem spełnienia tego postulatu jest zdefiniowanie wszędzie kluczy składających się z jednego pola. Trzecia postać normalna Brak zależności przechodnich pomiędzy polami tabeli innymi niż klucz (+ druga postać normalna). Zależności przechodnie powodują powtarzanie się danych (redundancję) oraz są zagrożeniem dla integralności bazy, bo to samo pole w jednym rekordzie może mieć inną wartość a w drugim omyłkowo wpisaną inną. Sposobem uniknięcia zależności przechodnich jest rozdzielenie tabel i utworzenie nowej tabeli z polami zależnymi przechodnio.
Normalizacja 9 Aby postulaty trzeciej postaci normalnej były spełnione należy w większości przypadków rozdzielić projektowaną tabele na szereg tabel połączonych. Możliwe jest to dzięki mechanizmowi sprzężeń błędnie nazywanych czasami relacjami. Sprzężenie to para pól w dwóch tabelach z których jedno pełni rolę klucza głównego w pierwszej tabeli. Pole w drugiej tabeli nosi nazwę klucza obcego. Przykładowo, jeśli tworzymy bazę danych dotyczącą kolekcji płyt CD, to poprawnie zaprojektowana baza powinna rozdzielać informacje o samej płycie od informacji o utworach. Tabela Płyty mogłaby mieć następujące pola
Normalizacja 10 Id_płyty Wykonawca Tytuł Gatunek... 1 U2 Joshua Tree Rock 2 U2 Achtung Baby Rock 3 Kaliber 44 3:44 Hip-Hop 4 Cypress Hill Black Sunday Hip-Hop 5 Vavamuffin Vabang Reggae............ Natomiast tabela Utwory może zawierać: Id_Utworu Id_Płyty Tytuł Czas_odtw... 1 1 With or without you 2 1 I still haven t found 3 2 One 4 3 Wena 5 3 Konfrontacje 6 3 Masz albo myślisz o nich 7 3 Litery 8 4 I wanna get high 9 4 Insane In The Brain 10 5 Smokin in Jamaica
Wprowadzenie do budowy systemów analitycznych Normalizacja 11 Tabele te są sprzężone polem Id_płyty, które w tabeli Płyty jest kluczem głównym a w tabeli Utwory kluczem obcym. Zwróćmy uwagę, że o ile wartości klucza głównego są unikalne, to wartości odpowiadającego mu w tabeli Utwory klucza obcego mogą się powtarzać. Interpretacja sprzężenia tabel w tym wypadku jest dość prosta. Utwór One pochodzi z płyty o id=2 czyli z płyty U2 Achtung Baby, utwór Wena z płyty o id=3 czyli z płyty Kalibra 44 3:44 a utwór Insane in the Brain z płyty Cypress Hill Black Sunday itd.
12 DZIĘKUJĘ ZA UWAGĘ!