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.
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
PrzewodniczacyKlasmoże być przewodniczącem tylko jednej klasy z tabeliKlasyi 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.
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ę.
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.
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.
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.
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
Górny przykład pokazuje sposób najczęściej stosowany, dolny jest stosowany np. w MS Access.
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.