🚀 go-pugleaf

Dyskusja o zwiazku relacyjnych baz danych i programowania obiektowego jest bardzo interesujaca. Jesli
moge wtracic swoje trzy grosze, to warto byc moze zauwazyc iz nowoczesne bazy danych ( SQL Serwer, SQL
Base, Oracle ... ) dysponuja mechanizmami pytan prekompilowanych ( stored commands ) oraz tkz.
trigerow. Mechanizmy te mozna w uproszczeniu traktowac jako "metody" - zadeklarowane w bazie danych
akcje, ktore w obpowiednim momencie zostana podjete na przechowywanych danych. Akcje te wykona
samodzielnie serwer - odciazajac siec komputerowa oraz stacje robocze ( co jest bardzo efektywne i
zgodnie z modelem przetwarzania klient-serwer )
 
Oczywiscie takie podejscie jest bardzo ogolne - zgadzam sie z Robertem iz nie istnieje mozliwosc
bezposredniego przelozenia schematu obiektowego na diagram zwiazkow encji ( oczywiscie rowniez w
kierunku odwrotnym - diagramu ER na schemat klas). Problem pojawia sie szczegolnie na styku: obiekty w
aplikacji - baza danych. Trudno bowiem rozstrzygnac jakie skladowe ( obiekty ) modelowanej
rzeczywistosci przechowywac w pamieci systemu komputerowego i jak dlugo.

W literaturze dotyczacej DMBS Gupta znalazlem informacje iz bardzo niewiele projektow zwiazanych z DBMS
zostalo zrealizowanych w calosci ( a nawet w czesci ) obiektowo.

Warto takze zastanowic sie na poziomem mechanizmow OOP, jakie wbudowane sa w jezyki 4GL otaczajace
serwery DBMS. Moje doswiadczenia z wskazuja iz mozliwosci tworzenia obiektowych aplikacji w tych
jezykach sa mocno ograniczone ( np. w jakim 4GL da sie rozwiazac problem rombu dziedziczenia ? ).
Twierdzenia iz duze aplikacje bazodanowe pisze sie glownie w C++ ( tak slyszalem ) sa moim zdaniem
mocno przesadzone.

Jezeli chodzi o przyklad Czlowiek <- Kobieta <- Matka to rozwiazaniem problemu moze byc np. nastepujacy
schemat relacji  

Czlowiek:

	id_czlowieka - primary key
	atrbuty specyficzne czlowieka
	...

Kobieta
	id_kobieta - primary key
	atrybuty specyficzne kobiety
	...		
	id_czlowieka - foreign key referrences Czlowiek(id_czlowieka)

Matka
	id_matka - primary key
	atrybuty specyficzne matki
	...
	id_kobieta - foreign key referrences Kobieta(id_kobieta)	
	

Rozwiazaniem dostepow ( akcesorow ) do obiektow moga byc tutaj perspektywy ( view ). Przykladowo dostep
do klasy Kobieta mozna by zapewnic poprzez stworzenie nastepujacej perspektywy.

create view as 
   select C.atrybuty specyficzne czlowieka, K.atrybuty specyficzne kobiety 
   from czlowiek C, kobieta K
   where K.id_czlowieka=C.id_czlwieka 

Ten sposob pociaga za wymog aby DBMS potrafil wykonywac polecenia insert, update, delete skierowane do
perspektywy - albo przynajmniej udostepnic mechanim, ktory w tej materii pozostawi otwarta furtke
uzytkownikowi. 

Duzo wiekszym problemem sa jednak metody - zaden ze znanych mi systemow nie zapewnia dziedziczenia (
nie mowiac o polimorfizmie ) metod ( np. dziedziczenia prekompilowanych komend lub trigerow na
perspektywy ) . 

Czytalem ze gdzies w swiecie sprzdaje sie juz komercyjne systemy baz danych obiektowych. Moze ktos zna
temat i chcialby sie podzielic swoimi doswiadczeniami?

Michal Kolano
Politechnika Slaska, Instytu Informatyki