2. Obiekt

Obiekt jest abstrakcyjnym bytem reprezentującym lub opisującym pewną rzecz lub pojęcie obserwowane w świecie rzeczywistym. Obiekt jest odróżnialny od innych obiektów, ma nazwę i dobrze określone granice. Przykładami obiektów są: pracownik Jan Kowalski, miasto Warszawa, dokument zakupu, pozycja tego dokumentu specyfikująca zakupiony towar, model samochodu, samochód Toyota o numerze rejestracyjnym WAP 9369, pogoda w dniu 13 kwietnia 1998 r. itd.

Wielu autorów nie rozróżnia pojęcia obiektu jako pewnej abstrakcji pojęciowej lub informacyjnej, konkretnego obiektu (materialnego) istniejącego w świecie rzeczywistym oraz struktury danych określanej jako "obiekt" przechowywanej wewnątrz komputera. Z metodologicznego punktu widzenia takie rozróżnienie jest konieczne. Dla języków zapytań tylko ostatni punkt widzenia jest relewantny. Dla naszych celów obiektem będzie więc pewna struktura danych przechowywana w przestrzeni pamięciowej komputera. Nie wymagamy, aby ta struktura danych miała swój odpowiednik wśród obiektów świata rzeczywistego. Niektóre obiekty mogą mieć taką własność, ale projektant bazy danych lub programista powołuje obiekt w zależności od swoich potrzeb i upodobań, często z przyczyn czysto technicznych. Nie wymagamy również, aby ta struktura była elementem bazy danych. Obiektem może być także dowolna abstrakcja programistyczna, np. moduł, procedura, zmienna, stała środowiskowa, okienko wyświetlane na ekranie, plik tekstowy itd. Istotą obiektu jest to, że programista może nim manipulować tak jak pojedynczą zwartą bryłą, np. wyszukiwać, kopiować, tworzyć, usuwać lub przenosić.

2.1. Tożsamość obiektu, identyfikator obiektu

W odróżnieniu od modelu relacyjnego obiektowość nie zakłada konieczności określenia takiego atrybutu obiektu (lub kombinacji atrybutów), który identyfikuje go w sposób unikalny, czyli tzw. "klucza głównego" (primary key). Mówi się, że obiekt posiada swoją tożsamość (identity), tj. istnieje niezależnie od innych obiektów i od swojego aktualnego stanu. Jakkolwiek tożsamości obiektów przypisuje się niekiedy głębszy sens filozoficzny, w praktyce implementacyjnej oznacza ona, że obiekt posiada unikalny wewnętrzny identyfikator (object identifier, OID), który odróżnia go od innych obiektów. Nie mogą istnieć dwa obiekty posiadające ten sam identyfikator. Taki identyfikator jest nadawany przez system automatycznie, niezależnie od woli projektanta lub programisty. Wewnętrzny identyfikator umożliwia budowanie referencji do obiektu, w szczególności tworzenie powiązań pointerowych. Identyfikator obiektu jest również istotnym elementem semantyki języków dostępu i manipulacji obiektami, m.in. może reprezentować wartość określaną jako l-value (od słowa left) w operacjach podstawienia, może być argumentem operacji usuń (delete) lub parametrem procedury przekazywanym przez referencję (call-by-reference). Identyfikator obiektu nie posiada znaczenia w dziedzinie przedmiotu systemu informatycznego. Programista lub użytkownik nigdy bezpośrednio nie posługuje się wartością identyfikatora obiektu, lecz wykorzystuje wyłącznie pewne oznaczenie symboliczne, np. nazwę obiektu, która w procesie wiązania jest zamieniana na jego identyfikator. Identyfikator może być zwrócony jako wynik wyrażenia, zapytania lub może być zapamiętany jako wartość zmiennej lub obiektu.

W idealnym przypadku identyfikator obiektu jest niezależny od lokacji obiektu w świecie rzeczywistym lub w przestrzeni adresowej komputera. Czasami to założenie kłóci się z innymi własnościami, np. z koniecznością jednoczesnego pamiętania wielu wersji czasowych tego samego obiektu lub z wymaganiami dotyczącymi wydajności. Dla celów definicji języków zapytań zasady budowy identyfikatorów obiektów będziemy uważać za nieistotne.

Identyfikator obiektu może być trwały (persistent), tj. niezmienny podczas całego życia danego obiektu. Jest to założenie rozsądne dla obiektów przechowywanych w bazie danych, gdzie zmiana identyfikatora obiektu może pociągać za sobą kłopotliwą zmianę wszystkich referencji/pointerów prowadzących do tego obiektu. Dla innych kategorii obiektów takie założenie może być jednak trudne do spełnienia, gdyż może oznaczać konieczność zwiększenia długości identyfikatora, implikować dodatkowe zapotrzebowanie na pamięć lub powodować zwiększenie czasów dostępu. Dla celów definicji i implementacji języków zapytań założenie o trwałości identyfikatora obiektu jest istotne tylko w pewnym zakresie, mianowicie, identyfikator obiektu tak długo powinien być trwały, jak długo istnieją rezultaty zapytań, w ramach których występuje ten identyfikator.

2.2. Nazwa obiektu

Będziemy przyjmować założenie, że każdy obiekt posiada nazwę, poprzez którą programista lub użytkownik może identyfikować obiekt w tekście programu lub zapytania. Nazwa obiektu z reguły posiada dodatkowe konotacje, np. nazwy takie jak Student, Osoba, Faktura, Wykład przenoszą pewną informację o znaczeniu odpowiedniej struktury danych w świecie rzeczywistym.

Obiekt może posiadać więcej niż jedną nazwę. Z reguły różne nazwy obiektu implikują różne spojrzenie na semantykę obiektów w świecie rzeczywistym. Fakt ten ma szczególne znaczenie dla modelu obiektów wprowadzających dynamiczne role obiektów. Aspekt ten omówimy w dalszej części tego rozdziału.

Nazwa obiektu nie musi być unikalna - może być wiele obiektów posiadających tę samą nazwę. Np. można utworzyć dowolnie dużo obiektów o nazwie Student. Klasyczne modele obiektowości, np. model ODMG, mówią w takich sytuacja o kolekcjach (zbiorach) obiektów, przy czym często zakłada się implicite, że w takich sytuacjach nazwa dotyczy całej kolekcji, a nie poszczególnych jej elementów. W naszym modelu będziemy konsekwentnie zakładać, że każdy pojedynczy obiekt posiada nazwę (np. Student), natomiast będzie także istniała możliwość potraktowania całej kolekcji jako pojedynczego obiektu i w związku z tym nadanie jej nazwy (np. Studenci).

Obiekt może być identyfikowany przez nazwy inne niż jego własna nazwa. Np. obiekt Student może być także identyfikowany przez nazwę Osoba. Jest to konsekwencja zasady zamienialności (substitutability), którą omówimy w dalszej części tego rozdziału.

2.3. Stan obiektu , atrybuty obiektu

Każdy obiekt posiada stan, określany jako kombinacja wartości wszystkich składowych obiektu, przede wszystkim wartości wszystkich jego atrybutów oraz powiązań z innymi obiektami. Stan obiektu może zmieniać się w czasie.

Niżej omówimy niektóre rodzaje atrybutów, z jakimi możemy mieć do czynienia przy rozpatrywaniu różnorodnych obiektów. Mogą istnieć atrybuty należące do kilku wymienionych niżej rodzajów, jak również mogą istnieć atrybuty będące kombinacją podanych niżej rodzajów.

• Atrybut prosty lub atomowy, taki jak np. NAZWISKO dla obiektu PRACOWNIK. Przechowuje dokładnie jedną wartość, która z punktu widzenia użytkownika jest niepodzielna (atomowa); np. "Kowalski".

• Atrybut złożony, taki jak np. ADRES. Przechowuje wiele wartości atomowych. Atrybut złożony ma strukturę hierarchiczną, przy czym każda gałąź hierarchii posiada nazwę. Np. wartością atrybutu ADRES może być struktura:
  
  { Miejscowość: "Warszawa"; Ulica: "Ordona": NrDomu: 21 }
  
  W takiej sytuacji mówi się, że atrybut ADRES posiada podatrybuty: Miejscowość, Ulica i NrDomu. Liczba stopni hierarchii atrybutu złożonego nie jest ograniczana.
  
  
• Atrybut pointerowy zawiera jako wartość identyfikator obiektu.
  
  
• Atrybut binarny posiada wartość atomową o dużych rozmiarach, reprezentującą najczęściej pewną daną multimedialną, np. tekst, grafikę, audio, wideo itd.
  
  
• Atrybut powtarzalny przechowuje pewien zestaw wartości o nieokreślonej i zmiennej w czasie liczbie elementów. Elementy składowe wartości atrybutu powtarzalnego mogą być proste, złożone oraz pointerowe. Przykładem powtarzalnego atrybutu prostego może być lista wyuczonych specjalności dla pracownika, np. {"tokarz", "ślusarz", "frezer", "spawacz"}. Przykładem powtarzalnego atrybutu złożonego dla pracownika może być lista zwolnień chorobowych, np.:
  
  

  { {Od: 95.02.11; Do: 95.02.18; Przyczyna: "Grypa"}, {Od: 95.05.17; Do: 95.06.10; Przyczyna: "Uraz" } }

  
  Przykładem powtarzalnego atrybutu pointerowego może być atrybut Zatrudnia obiektu DZIAŁ.
  
  
• Atrybut opcyjny (optional), czyli taki atrybut, który w konkretnym wystąpieniu obiektu może posiadać wartość lub nie. Przykładem takiego atrybutu może być NazwiskoPanieńskie dla obiektu OSOBA. W relacyjnych bazach danych takie atrybuty mogły przyjmować wyróżnioną wartość, oznaczaną jako NULL (NIL). Atrybut opcyjny można uważać za szczególny przypadek atrybutu powtarzalnego, gdzie liczba elementów zestawu wartości jest zero lub jeden.
  
  
• Atrybut domyślny (default) wiąże się pojęciowo z atrybutem opcyjnym i oznacza wartość, która jest przyjmowana domyślnie, o ile żadna wartość nie została wstawiona. Przykładowo, dla atrybutu NazwiskoPanieńskie obiektu OSOBA wartością domyślną może być ciąg 30-tu spacji, zaś dla atrybutu Zarobek obiektu PRACOWNIK wartością domyślną może być 0.
  
  
• Atrybut pochodny lub wyliczalny oznacza wartość, która jest wyliczana z innych atrybutów oraz niekiedy z innych danych. Przykładowo, jeżeli obiekt OSOBA zawiera atrybut RokUrodzenia, to atrybut Wiek jest atrybutem pochodnym, ponieważ jego wartość jest obliczana poprzez odjęcie wartości atrybutu RokUrodzenia od aktualnego roku. Pojęcie atrybutu pochodnego jest równoważne pojęciu metody funkcyjnej. Atrybut pochodny określa się też mianem wirtualny.
  
  
• Atrybut klasy (klasowy) oznacza wartość, która jest wspólna dla zestawu obiektów należących do tej samej klasy. Przykładem atrybutu klasy dla obiektów SSAK jest LiczbaOczu z wartością 2.
  
  
• Atrybut proceduralny oznacza wartość, która jest źródłowym lub skompilowanym kodem pewnej abstrakcji proceduralnej, np. metody.

Podana lista nie wyczerpuje wszystkich możliwości. Konieczne staje się wprowadzenie modelu, który zredukowałby liczbę wprowadzanych pojęć i pozwoliłby na zuniformizowanie reguł budowy obiektów. Zasada relatywizmu obiektów, którą omówimy nieco dalej, ustala, że każdy obiekt składa się z dowolnie złożonych podobiektów. W ten sposób każdy atrybut jest także obiektem. Dzięki tej zasadzie pojęcie atrybutu może być istotne dla modeli pojęciowych lub przy nieformalnych objaśnieniach, lecz staje się drugorzędne z punktu widzenia semantyki języka zapytań.

W wielu modelach obiektowych przyjmuje się, że każdemu atrybutowi musi być przypisany typ. Przykładowo, typem atrybutu NAZWISKO jest string, zaś typem atrybutu ZAROBEK jest integer. Kombinacja typów atrybutów wyznacza typ obiektu. Przyjmując wspomnianą zasadę relatywizmu obiektów, nie istnieje potrzeba wprowadzania różnic w środkach określania typów odnoszących się do obiektów i do typów odnoszących się do ich atrybutów.