KosciaKowy blog

Obecnie najczęściej stosowanymi bazami danych są relacyjne bazy danych. Mimo wielu niewątpliwych zalet posiadają sporo ograniczeń. Jednym z nich jest problem mapowania obiektowo-relacyjnego, czyli odwzorowania danych opisanych za pomocą języka obiektowego do postaci tabel i relacji.
Jedną z podstawowych koncepcji OOP jest dziedziczenie. Na potrzeby tego wpisu zajmijmy się prostym przykładem (zapisane w notacji UML):



Istnieją trzy podstawowe sposoby odwzorowania:

Jedna tablica dla całej hierarchii
Tworzymy jedną tablicę dla całej hierarchii obiektów zawierającą atrybuty wszystkich obiektów. Tablica taka będzie miała postać:

Osoba
OsobaID <<PK>>
TypOsoby
Nazwisko
NrIndeksu
Tytuł

OsobaID jest kluczem podstawowym, TypOsoby określa czy dana Osoba jest Studentem czy Wykładowcą.

Zalety i wady:

• rozwiązanie jest bardzo proste
• wszystkie Osoby posiadają unikalne ID, bez względu na podtyp
  
• łatwo zmienić podtyp osoby
• szybki dostęp do danych (zarówno wyszukiwanie jak i dodawanie)
  
• łatwo dodać nową podklasę - wystarczy dodać nowy atrybut w tabeli, jednak zwiększa to ilość marnowanego miejsca
  
• atrybuty nieistniejące w danej podklasie zostają wypełnione wartością NULL - marnowanie miejsca. Kłóci się z zasadami normalizacji.
  
• silne powiązanie obiektów w obrębie hierarchii
  

Osobne tabele dla każdej z klas
Tworzymy osobne tablice dla każdej z klas. Klasy podtypów posiadają jedynie te atrybuty, które różnią je od nadklasy. Dla naszego przykładu otrzymamy:

Osoba
OsobaID <<PK>>
Nazwisko

Student
OsobaID <<PK>> <<FK>>
NrIndeksu

Wykładowca
OsobaID <<PK>> <<FK>>
Tytuł

W tabelach Student i Wykładowca atrybut OsobaID jest zarazem kluczem podstawowym jak i kluczem obcym odnoszącym się do tabeli Osoba.

Zalety i wady:

• najlepiej odwzorowuje obiektowość danych i jest bardzo łatwo zrozumiałe
• małe powiązanie obiektów w obrębie hierarchii - bardzo łatwo dodawać nowe atrybuty zarówno w nadklasie jak i podklasach (zmieniasz tylko jedną tabelę)
  
• bardzo łatwo można tworzyć nowe podtypy
• wszystkie Osoby posiadają unikalny identyfikator
  
• powstaje duża ilość tabel w bazie
• utrudniony odczyt (trzeba w zapytaniu połączyć dwie tabele, lub utworzyć widok/kwerendę)
• bardzo utrudnione dodawanie i usuwanie obiektów - musimy oddawać (lub usuwać) dane do wielu tabel jednocześnie
• trudne w implementacji
  

Osobne tabele dla klas konkretnych
Tworzymy osobne tabele jedynie dla klas konkretnych, pomijając klasy abstrakcyjne. Tabele podklas zawierają zarówno atrybuty nadklasy jak i własne. Dla naszego przykładu otrzymamy tabele:

Student
StudentID <<PK>>
Nazwisko
NrIndeksu

Wykładowca
WykładowcaID <<PK>>
Nazwisko
Tytuł

Zalety i wady:

• łatwa implementacja
• łatwy odczyt danych
• łatwe dodawanie  i zmiana danych - wystarczy dopisać dane tylko w jednej tablicy
  
• zmiana atrybutu w nadklasie wymaga zmian we wszystkich podklasach
• jeśli jakiś obiekt będzie zarówno Studentem jak i Wykładowcą dane muszą zostać powielone pomiędzy dwoma tabelami
• łatwo dodać nową podklasę - wystarczy dodać nową tabelę. Jednak problemy mogą się pojawić przy poprawianiu wszystkich relacji z pozostałymi tabelami w bazie
• zarówno Studentem jak i Wykładowca posiadają osobne klucze podstawowe, trudno jest odnosić się do unikalnej Osoby. Musimy wtedy pilnować tworzenia unikalnych kluczy poza bazą
  

Podsumowanie
Jak widać każde z powyżej zaprezentowanych rozwiązań ma swoje wady i zalety. Każde z nich sprawdzi się w innych sytuacjach, dla innych baz danych i aplikacji.

Alternatywnym rozwiązaniem jest zastosowanie obiektowo-relacyjnej bazy danych, wspierającej dziedziczenie tabel. Przykładem takiej bazy może być PostgreSQL. Nie zawsze jednak możemy skorzystać z takiego rozwiązania.

Literatura:
1. Object-Relational Mapping Basics & Strategies
2. Mapping objects to relational databases
3. Mapping Objects to Relational Databases: O/R Mapping in details