Kohana Framework: ORM – relacje

Po długiej przerwie, wracam do kontynuacji serii wpisów dotyczących własnej aplikacji w Kohana Framework. Ostatnim razem zapoznaliśmy się z relacyjnym mapowaniem obiektów (ORM), narzędziem, które bardzo ułatwia szybkie (niekoniecznie dobre) pisanie aplikacji. Dzisiaj zajmiemy się relacjami modeli ORM.

Relacje ORM

Współcześnie pisane aplikacje wymagają odpowiednio przygotowanej bazy danych aby przetwarzać i gromadzić zapisane w niej informacje. Według założenia 1 model – 1 tabela, programiści umieszczają dane w osobnych tabelach. Kluczowe w tym zagadnieniu są relacje jakie zachodzą między tabelami. Aby zrozumieć działanie relacji, weźmy na przykład relację one-to-many ucznia szkoły podstawowej oraz jego ocen. Uczeń jako model model: student, table: students może mieć wiele ocen model: mark, table: marks. Jak powiązać oceny z uczniem będącym w tabeli student? Za pomocą kluczy obcych.

Schemat struktury bazy danych MySQL

Aktualny przykład nie odnosi się do aplikacji wspólnie pisanej w tej serii, jest przykładem dotyczącym relacji ORM i nie należy utożsamiać go z aplikacją CMS.

Warto w tym przykładzie zastosować klucz obcy kaskadowy, który po usunięciu ucznia z bazy danych, usunie również oceny przypisane do niego za pomocą klucza obcego założonego na kolumnę student_id tabeli marks.

Struktura tabeli: students modelu student:

Struktura tabeli marks modelu mark

Od tej chwili wraz z usunięciem elementu studenta z tabeli students kaskadowo zostaną skasowane również oceny przypisane do niego za pomocą klucza obcego student_id.

Definiowanie relacji w modelu ORM

Mechanizm relacji bazy danych został zapisany, więc teraz zajmiemy się utworzeniem odpowiednich wpisów w każdym z modelu. Tworzymy model Student.php w katalogu application/classes/Model (pamiętaj, że ten wpis nie ma powiązania z aplikacją CMS omawianą na łamach tej serii.)

Następnie tworzymy model Mark.php w tym samym katalogu.

Klasy reprezentujące nasze tabele mamy gotowe. Nadszedł czas na przedstawienie Wam rodzaje relacji występujące w modelach. Jest to bardzo ważne, bez tej wiedzy nie zrozumiecie kiedy używać danego typu.

  • Relacja jeden-do-jednego one-to-one
    Używany w przypadku, gdy dany obiekt posiada wyłącznie jedną referencję powiązaną kluczem obcym z inną tabelą. Przykład: Uczeń posiada swój profil/wizytówkę z danymi osobowymi itp.
  • Relacja jeden-do-wielu one-to-many
    Używany w przypadku, gdy dany obiekt nadrzędny posiada kolekcję referencji do obiektów podrzędnych. Przykład: Uczeń wypożyczył kilka książek z biblioteki. Odwrotnością tej relacji będzie many-to-one
  • Relacja wiele-do-wielu many-to-many
    Używany w przypadku, gdy dany rekord jednej tabeli posiada kolekcję referencji do obiektów innej tabeli, a rekord drugiej tabeli posiada wiele referencji z obiektami pierwszej tabeli. To rozwiązanie wymaga użycia trzeciej tabeli skrzyżowań zawierającej klucze podstawowe z pozostałych dwóch tabel, które są kluczami obcymi tej tabeli. Przykład: Jedno zamówienie może zawierać wiele produktów, a każdy produkt może występować w wielu zamówieniach.

Po krótkim zastanowieniu w naszym przypadku potrzebujemy rodzaju relacji one-to-many „jeden uczeń posiada wiele ocen”. Modyfikujemy nasze modele, dodając definicję relacji między modelami Student oraz Mark.

Musimy dodać również referencję modelu Mark do modelu Student tak aby można było się odwołać do obiektu studenta z poziomu oceny.

Użycie relacji w kodzie

Biorąc pod uwagę, że nasza baza danych zawiera informacje (przykładowych studentów oraz ich oceny) możemy w łatwy sposób wydobyć oceny użytkowników poprzez odwołanie się do relacji z poziomu modelu nadrzędnego. Poniższy kod wyświetli wszystkich studentów wraz z ich ocenami.

Relacja działa również odwrotnie za sprawą referencji modelu Mark. Jeśli mamy załadowany model oceny, przykładowo:

Musi istnieć rekord o numerze ID 5 w tabeli marks.

Wówczas możemy odnieść się z poziomu modelu oceny do modelu nadrzędnego, w tym wypadku studenta i wyświetlić np, jego adres e-mail.

W przypadku relacji one-to-one różnica polega wyłącznie na zmianie nazwy parametru.

Konkluzja

Podsumowując należy mieć na uwadze, że odpowiednio zaprojektowana baza danych to podstawa dobrej aplikacji. Zachowując konwencję nazewnictwa tabel, projektując poprawną strukturę i budując relacje zapewniamy sobie na początku istnienia projektu mniej problemów w trakcie jego rozwoju. Z własnego doświadczenia wiem, że źle zaprojektowana baza danych potrafi bardzo ograniczyć późniejsze prace, powodując ciągłe konflikty i kolizje. O ile indeksy możemy nałożyć w każdej chwili poprawiając optymalizację bazy danych, to z relacjami niekoniecznie może być tak kolorowo.

Ciekawskich i bardziej ambitnych zapraszam do dokumentacji, gdzie szerzej wyjaśnione jest zagadnienie relacji w modelach ORM.

Programista, administrator - miłośnik nowych technologii. Jak każdy fachowiec w branży nie oprę się porannej kawie w towarzystwie świeżej prasy. Hobbystycznie fotografuję, psuję, naprawiam, lutuję. Czego nie lubię? Nieskromnych ludzi i brzydkiego kodu.

Send this to a friend

webmastah.weekly
Cotygodniowa porcja linków ze świata WEBDEV BEZ spamu, TYLKO samo mięcho!
Zobacz poprzednie wydania. Dołącz do 2 tysięcy webdeveloperów!
HTML5, CSS3, JS (React, Angular, Ember, Vue), PHP, SQL