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.

Relacje

Podczas poprzednich zajęć pokazaliśmy klucze główne i obce w kilku tabelach przykładowej bazy danych, o nazwie DziennikElektroniczny. Dało to nam pogląd na istotę relacji oraz rolę kluczy w definiowaniu relacji. Podczas dzisiejszych zajęć poznamy różne typy relacji.

Schemat bazy danych

Projektując bazę danych, projektujemy jej tabele. Jeżeli mamy już zaprojektowane wszystkie tabele, to możemy wtedy powiedzieć, że utworzyliśmy schemat bazy danych. Podkreślam, że schemat zawiera opis tabel, na tym etapie nie wprowadzamy jeszcze żadnych danych.

Zanim zaczniemy projektować, musimy zdać sobie sprawę, że tabela powinna być modelem określonej klasy obiektów świata rzeczywistego - tak zwanych encji. Encje, są łącznikami pomiędzy realem a wirtualnym światem danych, można powiedzieć, że są prototypami tabel. Encja może reprezentować:

  • obiekt fizyczny np. Osoba(imię, nazwisko, PESEL, itp.)
  • pojęcie np. Konto(numer konta, nazwa banku, dopuszczalny debet, itp.)
  • wydarzenie np. Wypłata z konta(wypłacający, konto, data wypłaty, itp.)

Tak więc pierwszym etapem projektowania bazy danych powinno być utworzenie listy encji wraz z ich atrybutami. Atrybuty, to właściwości pisane w powyższych przykładach w nawiasach. Tabela jest odpowiednikiem encji, tak więc dla naszych przykładów, moglibyśmy utworzyć tabele:

  • Osoby(OsobaID, Imie, Nazwisko, Pesel)
  • Konta(KontoID, NumerKonta, NazwaBanku, DopuszczalnyDebet, itp)
  • Wyplaty(WyplataID, OsobaID, KontoID, DataWyplaty)

Zwróć uwagę, że postać tabelaryczna zawiera klucz główny oraz klucze obce definiujące relacje - nie może być inaczej, ponieważ w relacyjnej bazie danych nie ma tabel bez relacji. Bardziej przejrzystą prezentacją schematu bazy danych jest diagram encji i relacji E-R(Entity-Relationship-Diagramm) (diagram - uproszczona reprezentacja graficzna pewnych pomysłów, idei, konstrukcji, zależności). Jest on podobny do rysunku pokazanego w poprzednim temacie, przy czym musi dodatkowo uwzględniać typy określonych relacji. W dalszym toku nauki, będziemy stosować diagramy tabel i relacji.

Typy relacji

Musimy bardziej doprecyzować relacje między tabelami które poznaliśmy do tej pory. Zaznaczam, że nie jest to wymysł mający na celu dołożenie Ci kolejnej porcji abstrakcji, ale konieczność aby baza danych działała poprawnie. Pokazane dalej przykłady, nie mają związku z przykładem z poprzednich zajęć.

Relacja jeden do jednego 1:1

Relacja jeden do jednego pomiędzy tabelami A i B występuje wtedy, gdy każdemu rekordowi z tabeli A jest przyporządkowany dokładnie jeden rekord z tabeli B i na odwrót – każdemu rekordowi z tabeli B jest przyporządkowany dokładnie jeden rekord z tabeli A.

Relacja jeden do jednego
Rysunek 2_2_3_1. Relacja jeden do jednego

Zwróćmy uwagę, że w pokazanym przykładzie:

  • Nagłówki są pokazane jeden pod drugim, a nie tak jak w tabeli - jeden obok drugiego. Na etapie projektowania, kiedy nie ma jeszcze danych, taki układ jest najczęściej stosowany.
  • Każdy uczeń z tabeli PrzewodniczacyKlas może być przewodniczącem tylko jednej klasy z tabeli Klasy i odwrotnie - każda klasa może mieć tylko jednego przewodniczącego.
  • Tabele powiązane są poprzez pola o tej samej nazwie, co jest powszechnym sposobem nazywania kluczy obcych.

Podsumowując, aby zdefiniować relację jeden do jednego należy kopię klucza podstawowego jednej tabeli umieścić w drugiej tabeli.

W poniższym przykładzie pokazano pełne tabele zgodnie z pokazanymi wyżej nagłówkami. Aby nie zaciemniać rysunku, połączono tylko jednego przewodniczącego z rekordem odpowiadającej mu klasy.

Przykład relacji jeden do jednego
Rysunek 2_2_3_1a. Przykład relacji jeden do jednego

Relacja jeden do wielu 1:W

Relacja jeden do wielu jest najczęściej używanym typem połączenia. Pomiędzy tabelami A i B występuje wtedy, gdy pojedynczemu rekordowi z tabeli A jest przyporządkowany jeden lub wiele rekordów z tabeli B, natomiast pojedynczemu rekordowi z tabeli B jest przyporządkowany dokładnie jeden rekord z tabeli A. Zmodyfikujmny wcześniejszy przykład, zmieniając tabelę przewodniczących klas na tabelę wychowawców. Może niektórzy nie znają takich sytuacji, więc wyjaśniam, że w mojej szkole funkcjonują klasy łączone. Dwie klasy mają oddzielną domunentację (np. dzienniki lekcyjne), ale jednego wychowawcę.

Relacja jeden do wielu
Rysunek 2_2_3_2. Relacja jeden do wielu

Zwróćmy uwagę, że w pokazanym przykładzie jeden wychowawca może mieć dwie klasy (dwie, to już jest wiele), natomiast każda klasa, może posiadać tylko jednego nauczyciela - wychowawcę.

Relację jeden do wielu tworzymy w podobny sposób jak relację jeden do jednego. W tabeli, leżącej po stronie wiele należy umieścić kopię klucza podstawowego tabeli, leżącej po stronie jeden. Klucz ten staje się kluczem obcym w tabeli, leżącej po stronie wiele. W relacji jeden do wielu tabela po stronie jeden zawsze jest tabelą nadrzędną, zaś po stronie wiele – podrzędną.

W poniższym przykładzie pokazano pełne tabele zgodnie z pokazanymi wyżej nagłówkami. Klasy "I LO" oraz "III TI" są łączone i mają tego samego wychowawcę Jana Mądrego.

Przykład relacji jeden do wielu
Rysunek 2_2_3_2a. Przykład relacji jeden do wielu

Relacja wiele do wielu W:W

Relacja wiele do wielu pomiędzy tabelami A i B występuje wtedy, gdy pojedynczemu rekordowi z tabeli A jest przyporządkowany jeden lub wielu rekordów z tabeli B, i na odwrót - pojedynczemu rekordowi z tabeli B jest przyporządkowany jeden lub wielu rekordów A. Taką sytuację będziemy mieli w realcji nauczycieli do uczniów. Każdy nauczyciel uczy wielu uczniów, natomiast każdego ucznia uczą różni nauczyciele.

Relacja wiele do wielu
Rysunek 2_2_3_3. Relacja wiele do wielu

Aby zdefiniować relację W:W, należy stworzyć tabelę pomocniczą (łączącą, łącznikową). W naszym przykładzie tabelą pomocniczą jest tabela NauczycieleUczniowie. Zawiera ona tylko pary kluczy obcych pochodzących z tabel łączonych. Tym sposobem zamiast relacji wiele do wielu, otrzymujemy releacje jeden do wielu. Tak właśnie będziemy postępować projektując nasze bazy danych.

Rysunek poniżej pokazuje prosty przykład, w którym każdy nauczyciel uczy wszystkich uczniów, jak również każdy z uczniów jest uczony przez wszystkich nauczycieli. Zastosowanie tabeli pośredniej pozwala na zdefiniowanie wszystkich relacji jako jeden do wielu, dla przykładu pokazano jednego nauczyciela i jednego ucznia.

Zastosowanie tabeli łącznikowej
Rysunek 2_2_3_3a. Zastosowanie tabeli łącznikowej

Podsumowując, należy podkreślić, że poprawnie zaprojektowana baza danych, to poprawnie zaprojektowane tabele, w których poprawnie wyznaczono klucze oraz zdefiniowano typy relacji.

Inne sposoby graficznej prezentacji typów relacji

Powiązanie tabel związkiem jeden do jednego
Rysunek 2_2_3_4. Powiązanie tabel związkiem jeden do jednego

Górny przykład pokazuje sposób najczęściej stosowany, dolny jest stosowany np. w MS Access.

Powiązanie tabel związkiem jeden do wielu
Rysunek 2_2_3_5. Powiązanie tabel związkiem jeden do wielu

Górny przykład, to tzw. kurza stopka (Crow's feet), notacja pokazana na rysunku dolnym jest stosowana np. w MS Access.

Ćwiczenie 2_2_3_1

Załóżmy, iż mamy do czynienia z tworzeniem projektu BD SklepSpozywczy. Zaprojektowano między innymi następujące tabele: Artykuly, Producenci, Hurtownie, Zakup, Sprzedaz. Zaprojektuj te tabele. Określ relacje między tabelami, na przykład:

  • Producenci - Artykuly - wiele do wielu, ponieważ w sklepie znajdują się te same artykuły różnych producentów oraz różne artykuły tych samych producentów.
  • Hurtownie - Artykuly - jeden do wielu, ponieważ właściciel zaopatruje się w co prawda w kilku hurtowniach, ale w każdej w określony rodzaj artykułów.