W bazie danych beda to xs:INT ale tutaj beda dane do evaluacji W bazie danych beda to xs:INT ale tutaj beda dane do evaluacji W bazie danych beda to xs:INT ale tutaj beda dane do evaluacji Oznaczenie numeru ID instancji glownej - sluzy do cacheowania obiektow W bazie danych beda to xs:INT ale tutaj beda dane do evaluacji Oznaczenie numeru ID instancji glownej - sluzy do cacheowania obiektow For values of elements and also attributes. W bazie danych beda to xs:INT ale tutaj beda dane do evaluacji Numer ID danego typu instancji, zapisanej w tabeli z @ID danej instancji Przykładowy obiekt instance np. REWIR, do którego w relacji jest BUDYNEK (INSTANCE2). Instancje powinny być zgodne z numerami #ID (primary_key) FLAT_TABLE, w związku z czym powinna istniec procedura importu rekordow z tabeli plaskiej do danych obiektowych powinna wyglądać następująco WHEN INSERT into FLAT_TABLE (ID,SOME_COLUMN,SOME_COLUMN2) then insert into INSTANCE ($ID) insert into INSTANCE_SOME_COLUMN(@OBJECT_ID,@value) values ($ID,$SOME_COLUMN); insert into INSTANCE_SOME_COLUMN2(@OBJECT_ID,@value) values ($ID,$SOME_COLUMN2); - liczniki @counter_value powinny sie dodac same na bazie triggerow) procedura importu z weryfikacja powinna dzialac tak samo PROCEDURE_IMPORT_UPDATE_FLAT_TABLE foreach FLAT_TABLE { j.w. } Skojarzona z dana instancja tabela plaska, ktora powinna miec zgodny numer OBJECT_ID z kluczem tej tabeli, czyli w wiekszosci przypadków ta sama wartosc pola ID. W zasadzie te dane powinny przechodzic 1:1 w przypadku, kiedy dany obiekt plaski zotsał ustawiony, że jest w relacji do jakiegoś innego obiektu, czyli np. REWIR moze zawierac BUDYNEK, oraz relacja zostala nazwana @id=REWIR_do_BUDUNEK, to powinna sie utworzyc kolumna w tabeli BUDYNEK o nazwie @id(REWIR_do_BUDYNEK), która będize zawierać @OBJECT_ID z tabeli BUDYNEK, która to kolumna powinna być wytriggerowana tak, że po zmianie relacji w element_refs będzie ona zaktualizowana. Założenia dla triggera: when update element_refs then update NIEAKTUALNE @2015-11-20 - odtwarzamy całą mapę ułożenia obiektu zgodnie z dziecziczeniami tabela zawierajaca jakie instanncje reprezentuje dany obiekt - czyli w przypadku obiektu AAAA powinny byc wpisy , ze jest obiektem A, AA, AAA oraz AAAA . zalozenia dla triggerowania: PROCEDURE INSTANCES_DEREVIATIONS_UPDATE { delete from INSTANCES where $OBJECT_ID for each dereviations as $OBJECT_ID,$TYPE { insert into INSTANCES (OBJECT_ID,TYPE) values ($OBJECT_ID,$TYPE) } } when NEW INSTANCE then call_procedure INSTANCES_DEREVIATIONS_UPDATE when UPDATE INSTANCE TYPE on $OBJECT_ID then call_procedure INSTANCES_DEREVIATIONS_UPDATE Tabela z licznikami dla każdej instancji- aby był osobny licznik kolejności dla każdego z instancji. Zasada triggerowania WHEN NEW_RECORD on INSTANCE_SOME_COLUMN then update COUNTER @counter_value +1; return @counter_value + 1; WHEN UPDATE INSTANCE REALOCATE(INSTANCE) { nalezy zrealokowac obiekty ustawiajac ich kolejnosc wlasciwa na podstawie danych wejsciowych, czyli jak doszedl jakis element, to musi byc ustawiony jego counter na @counter_value+1 i wszystkie dane mają zwiększony @counter_value Kazda kolumna z plaskiego wystepuje pod nazwa tabeli np. DEVICES__a123asdad_ID. Przy triggerowaniu regula taka: when NEW_RECORD on FLAT_TABLE then ..... when field SOME_COLUMN then insert into INSTANCE_SOME_COLUMN(@OBJECT_ID,@counter_value,@value) values (`wartosc klucza obiektu np. ID`,`nextval(@counter_value)`,`@SOME_COLUMN_VALUE`) Informacje o relacjach do obcych obiektów z danego obiektu, tabela zawierajaca nr obiektu, licznik oraz @REMOTE_OBJECT_ID odnoszący się do @OBJECT_ID obcego obiektu, gdzie wiemy o jaki typ chodzi na podstawie schematu oraz nazwy tabeli, w której się znajduje dany rekord - bo do każdej relacji jest osobna tabela. dane mogą być cacheowane/triggerowane w z tabelami płaskimi, po stronie obiektu docelowego, z zawartością @OBJECT_ID oraz nazwą kolumny=$nazwa_tabeli_relacji(@id ze schematu). w związku z czym założenia do triggerowania są takie: when UPDATE on element_refs (@OBJECT_ID,@REMOTE_OBJECT_ID) then update FLAT_TABLE2 set element_refs2=@OBJECT_ID where #ID=@REMOTE_OBJECT_ID w przypadku triggerowania od strony tabeli płaskiej, to wyglądało by to tak: when UPDATE FLAT_TABLE2 where #ID=@OBJECT2_ID and element_refs2=@OBJECT_ID delete from element_ref where @ID_OBJECT=OLD.@OBJECT_ID insert into element_ref where @ID_OBJECT=NEW.@OBJECT_ID Aktualny typ dla którego dany obiekt został zainstancjonowany. Jeżeli obiekt jest typu A i został tylko jako A użyty, to jest tutaj wartość A oraz do INSTANCES tez wchodzi, jako typ A. Natomiast, jeżeli został on użyty jako AAAA, który jest typem dziedziczonym z A/AA/AAA/AAAA, to powinna tam byc wartosc 'AAAA'. Jezeli element byl uzyty dla zainstancjonowania obiektu - np. w wyniku zadzialania relacji, to nalezy to pole uzupelnic nazwa tego elementu. W zwiazku z czym dany obiekt nie bedzie mogl wystepowa jako dwa typy elementów? TODO czy jest to wlasciwe? TODO Moze to powinno przejsc na tabele INSTANCES? Przykładowy inny obiekt - np podrzędny do INSTANCE np. BUDYNEK w przypadku, kiedy dany obiekt plaski zotsał ustawiony, że jest w relacji do jakiegoś innego obiektu, czyli np. REWIR moze zawierac BUDYNEK, oraz relacja zostala nazwana @id=REWIR_do_BUDUNEK, to powinna sie utworzyc kolumna w tabeli BUDYNEK o nazwie @id(REWIR_do_BUDYNEK), która będize zawierać @OBJECT_ID z tabeli BUDYNEK, która to kolumna powinna być wytriggerowana tak, że po zmianie relacji w element_refs będzie ona zaktualizowana. Założenia dla triggera: when update element_refs then update