6. Zasada wewnętrznej identyfikacji

Relatywizm obiektów jest powiązany z inną zasadą, którą określimy mianem zasady wewnętrznej identyfikacji. Jeżeli komponent obiektu jest też obiektem, to musi posiadać swój (unikalny) wewnętrzny identyfikator.

Będziemy uważać, że tej zasadzie będą podlegać nie tylko byty zgromadzone w bazie danych, lecz także dowolne inne identyfikowalne byty zasobów komputera lub danej aplikacji, m.in. procedury zgromadzone w bibliotekach, klasy, metody, perspektywy, ograniczenia, wyzwalacze, moduły itd.

Nie będziemy zajmować się tym, w jaki sposób identyfikator ma być konstruowany i czy ma coś oznaczać. Np. może być fizycznym adresem w pamięci, identyfikatorem obiektu skojarzonym z nazwą atrybutu, identyfikatorem obiektu skojarzonym z przesunięciem (offset) względem początku obiektu itp. Konstruowanie identyfikatorów atrybutów jako par (identyfikator obiektu, nazwa atrybutu) jest niewystarczające dla atrybutów powtarzalnych, np. wartości atrybutu DZIECI obiektów PRACOWNIK, ponieważ zgodnie z tą zasadą każda wartość tego atrybutu musi mieć unikalny identyfikator.

Identyfikator bytu programistycznego nie może być w jakikolwiek sposób związany ze stanem tego bytu, o ile ten stan może podlegać zmianom. Np. identyfikator wartości atrybutu powtarzalnego DZIECI obiektów PRACOWNIK nie może włączać imienia dziecka, jeżeli liczymy się z tym, że to imię może być zmieniane. Generalnie, nie zaleca się, aby identyfikator obiektu przenosił jakąkolwiek informację dotyczącą zewnętrza systemu komputerowego (informację biznesową). W najprostszym przypadku powinna to być automatycznie generowana unikalna liczba naturalna. Ze względu na niebezpieczeństwo powstawania niespójności nie zaleca się także ponownego użycia identyfikatorów obiektów: identyfikator usuniętego obiektu jest stracony na zawsze.

Istnienie unikalnego wewnętrznego identyfikatora obiektu i jego dowolnych podobiektów umożliwia posługiwanie się w dowolnym kontekście jednoznaczną referencją (reference) do obiektu. Brak możliwości uzyskania referencji do obiektów powoduje trudności z definicją semantyki wielu funkcjonalności, takich jak np. operatora podstawienia, operatora usuwania wartości atrybutu powtarzalnego, zapewnienie prywatności dostępu do atrybutu, blokowanie wartości atrybutu dla celów przetwarzania transakcji itd.

Zasadzie wewnętrznej identyfikacji muszą także podlegać powiązania pomiędzy obiektami, niezależnie od sposobu implementacji takiego powiązania. Powiązanie może także podlegać aktualizacji, blokowaniu lub ochronie, wobec czego konieczna jest jego jednoznaczna wewnętrzna identyfikacja, by umożliwić spójną i jasną implementację tych cech. Np. jeżeli powiązanie jest implementowane jako pointer, konieczne jest przypisanie temu pointerowi identyfikatora, który umożliwiłby jednoznaczne zlokalizowanie tego pointera w przestrzeni adresowej komputera. Jest to konieczne w sytuacji, gdy np. ktoś chciałby taki pointer zmienić lub usunąć.

Zasadzie wewnętrznej identyfikacji powinny podlegać również elementy proceduralne, takie jak procedury, funkcje i metody. W większości przypadków jako identyfikator może służyć ich nazwa, ewentualnie skojarzona z nazwą lub identyfikatorem bytu, który je przechowuje (np. nazwą klasy lub modułu).

Zasada wewnętrznej identyfikacji jest ignorowana w modelach zorientowanych na wartości (value-oriented), w szczególności w modelu relacyjnym. Wynikają stąd liczne anomalie i niejasna semantyka wielu cech systemów i języków. Dotyczy to m.in. semantyki aktualizacji w SQL (klauzuli update), semantyki kursorów w zagnieżdżonym SQL i wielu innych cech. W istocie, niektóre cechy SQL, np. operatory update lub delete, nie dadzą się poprawnie wyjaśnić od strony semantycznej bez wprowadzenia pojęcia identyfikatora krotki (tuple identifier), co jest wbrew podstawowemu założeniu twórców modelu relacyjnego, które mówi, że identyfikatory krotek są wyłącznie cechą implementacyjną i nie muszą być uwzględniane w koncepcji i teorii modelu relacyjnego. Próby budowy spójnego modelu semantycznego SQL, jak i praktyka pokazały, że takie założenie jest zbytnim uproszczeniem. Wbrew poglądom głoszonym przez zwolenników modelu relacyjnego, wartość klucza głównego relacji nie jest dobrą referencją do krotki tej relacji, jeżeli tylko dopuścimy możliwość jego aktualizacji (a tego SQL nie zabrania), gdyż w tym przypadku nikt nie miałby pewności (w dowolnym momencie sterowania programu, np. przy operacji podstawienia), że odwołania z zewnątrz do tej krotki są jeszcze ważne.

Relatywizm obiektów w powiązaniu z zasadą wewnętrznej identyfikacji oznacza, że nie może istnieć obiekt, którego wartość jest złożona z wielu podwartości (bez własnych identyfikatorów). Taka wartość musi zostać rozbita na zestaw podobiektów, z których każdy powinien mieć własny unikalny identyfikator