Co to są relacyjne bazy danych?
Co to są relacyjne bazy danych? O Są to zbiory danych pogrupowane w tabele o strukturze: kolejne kolumny określają kolejne porcje informacji potrzebne dla każdego wystąpienia, kolejne wiersze to właśnie te wystąpienia. wiersze nazywamy rekordami, przecięcie kolumny i wiersza to pole. przykład: tabela student, kolumny: imię, nazwisko, rok studiów, data urodzenia, wzrost, czyjestczlonkemskni (tak/nie)
Różne kolumny mogą przechowywać różne typy O liczbowe, O tekstowe, O daty, danych: O flagi mające tylko wartość 0 lub 1(bolean, bit)
Założenia modelu relacyjnego: O Relacyjne bazy danych oparte są na matematycznym modelu relacji, jednak w pewnych kwestiach od tego modelu odchodzą. O relacją nazywamy tabelę przechowującą dane O relacje te są zbiorami w matematycznym sensie, a więc: -nie mają ustalonego porządku -można na nich przeprowadzać operacje na zbiorach
Obsługa baz relacyjnych O Do obsługi baz relacyjnych służy nam SQL -Structured Query Language. W zasadzie każda implementacja relacyjnych baz danych używa SQL, ale poszczególne dialekty trochę się od siebie różnią. Dlatego zapytanie, które zadziała np. na MS SQL SERVER, może być nierozpoznawane przez Oracle
Popularne systemy relacyjnych baz danych: O Oracle O Microsoft SQL Server O Sybase O Mysql bezpłatny O PostgreSQL - bezpłatny
Typy baz danych: Bazy proste: Bazy kartotekowe Hierarchiczne bazy danych Bazy złożone: Bazy relacyjne Bazy obiektowe Bazy relacyjno-obiektowe Strumieniowe bazy danych Temporalne bazy danych
Dlaczego przydają się bazy danych? O możemy przechowywać i manipulować taką ilością informacji, której obróbka ręczna zajęłaby stulecia O np. całkiem normalną sytuacją jest, że tabela klient jakiegoś przedsiębiorstwa zawiera milion wierszy. wyobraźmy sobie, że ktoś trzyma kartotekę klientów w wielkim pokoju i w pewnym momencie próbuje odszukać wszystkich klientów, którzy dziś mają urodziny. Praca nie do wykonania. A baza danych poradzi sobie w tym w przeciągu kilku minut. O Bazy danych ułatwiają przenoszenie danych i ich kopiowanie
Normalizacja baz danych O Wyobraźmy sobie,że mamy przedsiębiorstwo biblioteka, które swoje dane trzyma w jednej wielkiej tabeli
Dlaczego ten sposób jest nieefektywny? O W jednej tabeli trzymamy dane o zupełnie różnych podmiotach - książce, autorze, osobie wypożyczającej, wydawnictwie - sprawia to, że dane są mało czytelne O Jeśli dane wydawnictwo ma wiele książek - informacje o nazwie i adresie wydawnictwa będzie powtórzona wielokrotnie nie dając niczego nowego - tracimy wiec miejsce na dysku (redundancja) O Przypuśćmy, że wydawnictwo zmieniło adres - w obecnej sytuacji trzeba zmienić jego dane we wszystkich wierszach zawierających książki tego wydawnictwa. Jeśli w którymś miejscu tego nie zrobimy, okaże się że mamy w naszej tabeli sprzeczne informacje na temat wydawnictwa (nie konsystencja danych) O Ponadto poszczególne pola w naszej tabeli zawierają nieatomowe dane- np. jednocześnie cały adres - co bardzo utrudnia operacje na danych np. ciężko byłoby wyszukać wszystkich wypożyczających z ulicy Błotnistej
Jak to naprawić? O Należy przeprowadzić proces, zwany normalizacją bazy w wyniku którego zadbamy by: 1. każda tabela zawierała jedynie dane na temat jednego podmiotu np. książki 2. każde pole zawierało jedynie atomowe dane (np. nazwa ulicy, numer mieszkania, kod pocztowy) 3. tabele pozostawały w powiązaniu ze sobą za pomocą klucza głównego i klucza obcego
W efekcie otrzymujemy następujące tabele:
Czym jest klucz główny? O id... w każdej tabeli stanowi klucz główny tej tabeli - oznacza to pole, lub zbiór pól, które jednoznacznie identyfikują dany wiersz - są w skali tej tabeli unikatowe. poprzez wpisanie tej wartości klucza np. wydawnictwa, do tabeli KSIAZKI zyskujemy odnośnik, ze informacje o wydawnictwie tej książki możemy znaleźć w tabeli WYDAWNICTWA, w wierszu o tej wartości klucza. Taki wpis klucza z innej tabeli nazywamy kluczem obcym. To jest właśnie sposób na powiązanie danych z różnych tabel ze sobą. O relacje przedstawione są typu 1 do wielu: to znaczy 1 wydawnictwo może mieć wiele książek (ale 1 książka nie może mieć wielu wydawnictw).
Relacja wiele-do-wielu O Np jeden czytelnik może mieć wypożyczone wiele książek. Ale jedna książka może (w czasie) być wypożyczana przez wielu czytelników. Jak to przedstawić?
Tabela Pośrednia
Relacje
Wartość NULL O Model relacyjny przewiduje, że część wartości może pozostać nieznana, pusta. Dlatego istnieje wartość null - która oznacza wartość nieznaną, nieokreśloną. nie jest to to samo co brak wartości. O w praktyce dość często się nią posługujemy. I tak w ostatniej tabeli: CZYTELNIK_KSIAZKA zwróćmy uwagę na pole data_oddania. Jeśli książka została już zwrócona - wiadomo, co będzie tam wpisane. Ale co, jeśli książka jest ciągle wypożyczona? Wpisać tam wartość z przeszłości? przyszłości? najlepiej chyba zostawic null...
Poszczególne kolumny mają różne typy danych: O tekstowe O numeryczne, O bitowe O i inne O np. imię będzie typu tekstowego O data_wypozyczenia - typ daty O id - typ numeryczny
O O O Co nam daje odpowiednie dopasowanie? Oszczędność miejsca - na dysku oraz w pamięci RAM podczas obróbki danych - różne typy różnią się pojemnością, a więc i wielkością. Odpowiedni typ danych umożliwia różne operacje typowe dla niego. np. jeśli datę zapiszemy jako typ tekstowy- nie będziemy mogli w prosty sposób obliczyć różnicy między tą data, a jakąś inną, czy odjąć od tej daty np. 30 dni. odpowiedni dobór typów zapewni nam takie możliwości. Czasami może okazać się, że typ danych nas ogranicza. Np. na stan konta bankowego ustawiliśmy typ smallint,który przyjmuje wartość do 32767. A potem dostajemy przelew na jeszcze 20 tysięcy. I co? i mamy problem ;). podobnie może być np. ze zbyt długim nazwiskiem w polu tekstowym, ale o ułamkiem o zbyt dużej precyzji w polu numerycznym.
Zadanie Jesteś świeżo zatrudnionym informatykiem w firmie wypożyczającej melexy na polu golfowym. Firma nazywa się Głęboki dołek i w takim stanie się znajduje, bo ma problem z kartoteką. Zaproponuj sensowny układ tabel dla firmy. W zamian prezes pozwoli Ci przez rok za darmo jeździć melexem do domu. myślę, że warto ;)