Wykład 3 Tabele
Posługiwanie się tabelami Przykładowa tabela gromadząca informacje o osobach (Imię, Nazwisko, Data urodzenia) Osoby Imię Nazwisko Data urodzenia Jan Kowalski 1995-01-01 Piotr Nowak 1994-05-22 Michał Wróblewski 1997-08-15 Czy powyższa tabela nadaje się do gromadzenia informacji w Bazie Danych? Co stanie się, gdy chcemy w niej umieścić dane dwóch osób o tych samych danych (Jan Kowalski, 1995-01-01)?
Posługiwanie się tabelami - klucz We wcześniejszej tabeli brak klucza głównego, który jednoznacznie identyfikowałby wiersze Osoby OsobaId Imię Nazwisko Data urodzenia 1 Jan Kowalski 1995-01-01 2 Jan Kowalski 1995-01-01 3 Piotr Nowak 1994-05-22 4 Michał Wróblewski 1997-08-15 Klucz główny (podstawowy) jednoznacznie identyfikuje każdy wiersz Kombinacja kolumn również może być kluczem głównym byle jednoznacznie identyfikowała każdy wiersz O kluczu głównym decyduje projektant Bazy Danych
Posługiwanie się tabelami - relacje Tabele przechowujące dane muszą być w jakiś sposób powiązane ze sobą Powiązania (relacje) między tabelami uzyskuje się za pomocą klucza obcego Przykładowa struktura bazy danych o Klientach i ich Zamówieniach w ramach sklepu internetowego Klienci KlientId Imię Nazwisko klucz główny Zamówienia ZamówienieId KlientId Towar Data zamówienia klucz główny klucz obcy
Posługiwanie się tabelami - relacje Jednoznaczne zidentyfikowanie wiersza dzięki kluczom glównym: KlientId w tabeli Klienci i ZamówienieId w tabeli Zamówienia Jednoznaczne powiązanie wierszy w tabelach Klienci i Zamówienia dzięki kluczowi głównemu (kluczowi obcemu) KlientId Przykładowa baza danych o Klientach i ich Zamówieniach Klienci Zamówienia KlientId Imię Nazwisko 1 Jan Kowalski 2 Piotr Nowak 3 Ewa Jabłońska ZamówienieId KlientId Towar Data zamówienia 1 1 Towar1 2010-11-05 2 1 Towar2 2010-12-06 3 2 Towar3 2010-12-15 4 3 Towar1 2010-12-20
Posługiwanie się tabelami - relacje Trzy podstawowe typy relacji między tabelami: Jeden do jednego. Jednemu wierszowi tabeli X odpowiada dokladnie jeden wiersz z tabeli Y. Przykładowa baza danych z tabelami Osoba i Pesele ( każdej osobie odpowiada jeden Pesel i dla każdego nr Pesel jest przyporzadkowana jedna osoba ) OsobaId Imię Nazwisko 1 Jan Kowalski 2 Piotr Nowak 3 Ewa Jabłońska OsobaId Pesel 3 01234567890 1 01234567891 2 01234567892 klucz główny klucz obcy klucz główny
Posługiwanie się tabelami - relacje Jeden do wielu Jednemu wierszowi tabeli X odpowiada jeden lub wiecej wierszy z tabeli Y. Przypomnijmy przykładową bazę danych o Klientach i ich Zamówieniach (jeden Klient może złożyć wiele zamówień, ale Zamówienie jest przpisane tylko do jednego Klienta) KlientId Imię Nazwisko Klienci 1 Jan Kowalski 2 Piotr Nowak 3 Ewa Jabłońska Zamówienia ZamówienieId KlientId Towar Data zamówienia 1 1 Towar1 2010-11-05 2 1 Towar2 2010-12-06 3 2 Towar3 2010-12-15 4 3 Towar1 2010-12-20
Posługiwanie się tabelami - relacje Wiele do wielu Jednemu wierszowi z tabeli X może odpowiadać wiele wierszy z tabeli Y oraz jednemu wierszowi z tabeli Y może odpowiadać wiele wierszy z tabeli X Przykładowa struktura bazy danych o Autorach i Książkach powinna zawierać tabelę Ksiązki/Autorzy łącząca dane z tabel Ksiązki i Autorzy [ Autor mógł napisać jedną lub więcej książek, Książka może mieć jednego lub więcej autorów] Autorzy AutorId Imię Nazwisko Książki /Autorzy KsiążkaId AutorId Książki KsiążkaId Tytuł
Projektowanie tabel Określenie celu i struktury bazy - strukturę bazy należy dobrać do konkretnego projektu - te same dane można zapisać w różny sposób zależnie od tego, do czego maja służyć np. - baza do celów administracyjno-meldunkowych wymaga tabel Osoby i Adresy z relacją jeden do wielu (jeden adres wielu zameldowanych, jedna osoba jeden adres meldunkowy) - baza opisująca stosunki własnościowe wymaga tabel Osoby i Mieszkania z relacja wiele do wielu (jedna osoba jest wlaścielem wielu mieszkań, jedno mieszkanie ma wielu właścicieli) - baza dla celów obsługi małego sklepu internetowego wymaga danych dotyczących osób i adresów wysyłki (może być jedna tabela lub dwie tabele, relacja jeden do jeden lub jeden do wielu)
Projektowanie tabel Duplikowanie danych - należy unikać sytuacji, w której w kolejnych wierszach są duplikaty tych samych danych. Liczne duplikaty danych są oznaką źle zaprojektowanej bazy np. - baza do prowadzenia małej księgarni powinna zawierać dane o książkach i wydawnictwach przykładowo z tabelą o strukturze Książki KsiążkaId Tytuł Nazwa Wydawnictwa Adres Wydawnictwa KsiążkaId Tytuł Nazwa Wydawnictwa Adres Wydawnictwa 1 Pierwsze kroki z SQL Helion S.A. Kościuszki 1c, 44-100 Gliwice 2 C++ przewodnik Helion S.A. Kościuszki 1c, 44-100 Gliwice 3 Sieci komputerowe Helion S.A. Kościuszki 1c, 44-100 Gliwice
Projektowanie tabel Duplikowanie danych Dlaczego organizacja powyższej tabeli jest nienajlepsza? - marnujemy miejsce w bazie, bo dopisanie kolejnej książki oznacza powtórzenie tej samej nazwy wydawnictwa i adresu - jeśli przy wprowadzeniu nowych książek do bazy pomylimy się o choć jeden znak (o co łatwo przy tak dużej ilości wpisów) to baza będzie niespójna - jeśli wydawnictwo zmieni nazwę lub adres trzeba będzie zmienić to w wielu wierszach -. Lepsze rozwiązanie: Książki KsiążkaId Tytuł WydawnictwoId Wydawnictwa WydawnictwoId Nazwa Wydawnictwa Adres Wydawnictwa 1 Helion S.A. Kościuszki 1c, 44-100 Gliwice
Projektowanie tabel Informacje atomowe - w każdym polu bazy należałoby zapisywać pojedyncze, atomowe informacje Czy adres wydawnictwa zapisany w polu bazy jest informacją atomową? - zależy czego będziemy szukać w bazie, bo trudno wówczas znaleźć wydawnictwa z jednego miasta lub przy jednej ulicy. Lepiej rozbić adres na informacje bardziej elementarne (atomowe) - błędem jest umieszczanie w jednym polu wielu odwołań do innej tabeli Przykładowa tabela Wypożyczenia w bibliotecznej bazie danych KlientId KsiązkaId Data wypożyczenia 1 1, 18, 24 2017-05-05 2 2 2017-05-05 3 2, 14 2017-06-07
Projektowanie tabel Informacje atomowe Dlaczego organizacja powyższej tabeli jest niedobra? Nie można sprawdzić: Ile razy w danym okresie wypożyczono książkę? Jakie książki wypożycza klient o KlientId =1? Kiedy została wypożyczona książka o KsiążkaId=24? Prawidłowy (atomowy) zapis w tabeli Wypożyczenia KlientId KsiązkaId Data wypożyczenia 1 1 2017-05-05 1 18 2017-05-05 1 24 2017-05-05 2 2 2017-05-05 3 2 2017-06-07 3 14 2017-06-07
Projektowanie tabel Puste pola - należy unikać pozostawiania w tabelach pustych pól, czyli takich, które nie zawierają danych - jeśli pustych pól jest dużo to należy przemyśleć i ewentualnie zmodyfikować strukturę bazy Przykładowa struktura bazy meldunkowej: Osoby OsobaId Imię Nazwisko Data urodzenia Adresy Pesel AdresId AdresZameldowaniaId AdresId Ulica Nr domu Nr lokalu Miejscowość Kod Poczta Nie każda osoba ma adres zameldowania więc pojawią się pola puste.
Projektowanie tabel Puste pola Przykładowa tabela Zamówienia z dużą liczbą pustych pól. Zamówienia ZamówienieId KlientId TowarId Data zamówienia Uwagi 1 1 24 2017-01-01 2 1 12 2017-02-02 3 3 76 2017-03-03 Wysłać do 20.03 Można rozbić na dwie tabele: Zamówienia ZamówienieId KlientId TowarId Data zamówienia 1 1 24 2017-01-01 2 1 12 2017-02-02 3 3 76 2017-03-03 Uwagi ZamówienieId Uwagi 3 Wysłać do 20.03
Projektowanie tabel Jednoznaczna identyfikacja rekordów Wiersze w tabeli muszą być jednoznacznie identyfikowane, bo w przeciwnym wypadku nie będziemy w stanie rozróżnić rekordów. Niezbędny jest zatem dobrze określony klucz podstawowy (główny), najczęściej jako dodatkowy identyfikator: KlientId, OsobaId, TowarId. Można też używać identyfikatora rzeczywistego jak numer ISBN (wydawnictw), PESEL (osób) etc.