Lekcje >> Podstawy MySQL
Polimax

Drukarnia w Warszawie realizująca druk wizytówek, plakatów jak również fotoksiążki, fotoobrazy i fotokalendarze - z wysyłką na terenie całego kraju.

Zasady projektowania

Podsumowując zdobyte do tej pory wiadomości, możemy powiedzieć, że w relacyjnej bazie danych każda tabela powinna być w relacji przynajmniej z jedną tabelą. Mówiąc o relacjach między tabelami, zawsze analizujemy i definiujemy relację wyłącznie między dwiema tabelami.

Typy integralności w relacyjnych bazach danych

Zanim zaczniemy projektować prawdziwą bazę danych, musimy jeszcze poznać pojęcie integralności. Przez integralność relacyjnej bazy danych, rozumiemy poprawność, spójność, a także dokładność przechowywanych w niej danych. Zapewnienie integralności danych jest jednym z najważniejszych zadań, przed którymi stoją projektanci baz danych.

Integralność na poziomie pól

Zapewnienie integralności na poziomie pól gwarantuje, że struktura każdego pola jest poprawna, zawarte w nich wartości są logiczne, wszystkie pola są tego samego typu i są zdefiniowane w identyczny sposób. Tabela nie może zawierać pól posiadających różne typy danych, czy pól kalkulowanych, których wartości możemy wyliczyć na podstawie innych pól.

Weźmy dla przykładu tabelę Uczniowie(UczenID, Nazwisko, Imię, Adres). W polu Adres możemy wpisać np. ul. Sobieskiego, 5, Krasnystaw, 22-300. Wymóg zachowania integralności pól, zabrania nam traktowania tych danych jako tekstu i liczb. W tym wypadku cały adres musi być tekstem.

Jeżeli mamy tabelę Towary(TowarID, Nazwa, Cena, Ilosc, Koszt), to wartość w polu Koszt można wyliczyć na podstawie wartości pól Cena i Ilosc, ponieważ Koszt=Cena* Ilosc. Tak więc pole Koszt jest polem kalkulowanym i nie możemy go zastosować w tabeli.

Integralność na poziomie relacji

Integralność na poziomie relacji oznacza poprawnie zdefiniowane relacje pomiędzy tabelami. Dane w powiązanych tabelach powinny ze sobą zsynchronizowane - w tabeli zawierającej klucz obcy wartości tego klucza muszą odpowiadać wartościom klucza podstawowego w tabeli nadrzędnej. Mówiąc inaczej, nie można dodać do tabeli rekordu z wartościami klucza obcego różnego niż wartości klucza podstawowego tabeli nadrzędnej.

Reguły integralności

Regułami integralności nazywamy pewne sformułowania, które ograniczają dopuszczalne wartości pól tabeli, lub niektóre cechy i właściwości samych tabel. Przykłady reguł:

  • płeć może przyjmować tylko dwie wartości: K lub M,
  • liczba uczniów w klasie nie może być mniejsza jak 25 i większa od 35.

Ćwiczenie 2_3_0_1. Typy integralności baz danych

Opisz w zeszycie własnymi słowami reguły integralności baz danych.

Definiowanie obiektów i zależności świata rzeczywistego

Projektując schemat bazy danych musimy przemyśleć rzeczywiste wymagania które należy postawić projektowanej bazie. Załóżmy, że mamy opracować projekt bazy danych DziennikElektroniczny, której fragment już pokazywaliśmy. Wstępne założenia mogą wyglądać następująco:

  • użytkownikami bazy danych, będą nauczyciele, rodzice i uczniowie;
  • można wykonać następujące operacje: dodawanie, usuwanie, modyfikacja oraz pobieranie danych o uczniach, nauczycielach, klasach, zajęciach, rodzicach i salach lekcyjnych;
  • celem tworzonego projektu jest wspomaganie zarządzania szkołą;

Po takiej wstępnej analizie powinien nastąpić etap szczegółowego definiowania encji i tabel, zakończony diagramem tabel i relacji. Poniżej pokazany jest taki diagram dla fragmentu bazy DziennikElektroniczny.

Diagram tabel i relacji
Rysunek 2_3_0_1. Przykład diagramu tabel i relacji

Widzimy, że jest to tylko fragment większego projektu. Również tabele nie są kompletne, brak np. w tabeli Uczniowie relacji z tabelą rodziców, brak w tabeli Oceny relacji z tabelą klas, itp. Pokazany schemat należy potraktować poglądowo, to nie jest kompletny schemat bazy, która mogłaby służyć za dziennik elektroniczny.

Mamy bardzo prosty układ tabel: po lewej pokazane są tzw. tabele słownikowe opisujące obiekty występujące wielokrotnie w tabeli ocen, każda z tabel słownikowych jest połączona z tabelą Oceny relacją typu jeden do wielu. Dlaczego?

  • Uczeń otrzymuje w pewnym przedziale czasu wiele ocen, a więc w tabeli Oceny, ID danego ucznia pojawi się nieraz.
  • Z danego przedmiotu, wystawiane jest wiele ocen.
  • Nauczyciel stawia wiele ocen, więc ID danego nauczyciela wielokrotnie będzie wymienione w tabeli tabeli Oceny.
  • Takie same oceny powtarzają się.

Poniżej pokazany jest inny przykład diagramu tabel i relacji prostej bazy danych MojeFilmy przechowującej informacje o Twoich ulubionych filmach.

Diagram tabel i relacji
Rysunek 2_3_0_2. Przykład diagramu tabel i relacji bazy MojeFilmy

Kategoria to np. dramat, komedia, science-fiction, itp. przy założeniu że każdy film zakwalifikujemy tylko do jednej kategorii. W filmie gra wielu aktorów, podobnie aktor może występować w wielu filmach - stąd relacje wiele do wielu między tablami Filmy i Aktorzy, a więc konieczność zastowania tabeli łącznikowej FilmyAktorzy.

Ćwiczenie 2_3_0_2. Diagram tabel i relacji

Sporządź w zeszycie diagram tabel i relacji dla uproszczonej bazy danych samochodów osobowych.

Dane redundantne

Zacznijmy od definicji podanej w Wikipedii: Redundancja (łac. redundantia – powódź, nadmiar, zbytek) – nadmiarowość w stosunku do tego, co konieczne lub zwykłe. Określenie może odnosić się zarówno do nadmiaru zbędnego lub szkodliwego, niecelowo zużywającego zasoby, jak i do pożądanego zabezpieczenia na wypadek uszkodzenia części systemu. W naszym przypadku naszym systemem jest relacyjna baza danych.

Zastanówmy się co by było, gdybyśmy np. w tabeli Oceny zamiast pola UczenID, wstawili kompletne dane ucznia. Tak więc dane ucznia wystąpiłyby wtedy w dwóch tabelach. A co będzie, jeżeli rozbudujemy naszą bazę popełniając konsekwentnie ten sam błąd - umieszczając kompletne dane ucznia w wielu tabelach? Taką sytuację już opisywaliśmy, ale ze względu na wagę problemu podsumujmy jeszcze raz:

  • Marnotrawstwo pamięci, po co te same dane zapisywać kilkakrotnie?
  • Jeżeli zmienimy dane ucznia w kilku tabelach ale nie wzystkich, gdzie one występują, to może powstać tak zwana anomalia uaktualnienia(modyfikacji lub usunięć). Może to prowadzić do naruszenia spójności i integralności danych - nie mamy pewności, które z nich są poprawne. Sytuacje takie skutkują najczęściej utratą części danych.

Wniosek jest oczywisty: projektując bazę danych, unikamy przechowywania danych redundantnych.

Ćwiczenie 2_3_0_3. Dane redundantne

Opisz w zeszycie własnymi słowami problem danych redundantnych.

Pytania, które będą zadawane bazie danych

Pamiętajmy, że tworzona przez nas baza danych musi być funkcjonalna. Podczas projektowania, należy zadbać o to, aby tabele oraz relacje umożliwiały uzyskiwanie potrzebnych dla użytkownika danych. W naszym przykładzie, będziemy na pewno pytać o oceny konkretnego ucznia, możemy się również zapytać o oceny uzyskiwane z poszczególnych przedmiotów, albo oceny wystawione przez danego nauczyciela, itp.

Tabele w wieloma pustymi polami

Puste pola prowadzą do marnotrawienia pamięci i mogą prowadzić do błędnych wyników zwracanych przez różne funkcje obliczeniowe. Użytkownik, widząc puste pole nie jest pewien, czy jest to spowodowane brakiem danych, czy błędami działania bazy. Oto typowa sytuacja błędnego projektowania zakładającego istnienie pól pustych:

Puste pola w tabeli
Rysunek 2_3_0_3. Puste pola w tabeli

Załóżmy że projektując bazę danych Filmoteka, twórca zaprojektował tabelę Filmy w której jedno z pól to Recenzja. Problem polega na tym, że tylko część filmów posiada recenzję. W tabeli wystąpią więc puste pola. Jak temu zaradzić? W prosty sposób. Zamiast pola Recezja w tabeli Filmy, wystarczy utworzyć tabelę Recenzje, w której umieścimy tylko istniejące recenzje.

Stosowanie zasad projektowania omówionych podczas tych zajęć nazywane jest procesem normalizacji. Normalizacja prowadzi do tworzania prostych tabel i wyklucza powstawanie anomalii podczas dodawania, usuwania i zmiany danych.

Ćwiczenie 2_3_0_4. Puste pola w tabelach

Opisz w zeszycie własnymi słowami problem pustych pól. Podaj swój przykład.