• Często zachodzi potrzeba dłuższego przechowania niektórych obiektów (np. między sesjami)

• Takie obiekty nazywamy trwałymi (ang. persistent)

• Obiekty trwałe można zachować na dysku w repozytorium obiektów

• Program korzysta z repozytorium za pośrednictwem pamięci buforowej (cache, obiekty ładuje się na żądanie.

• Jeśli dany obiekt ma być trwały, to wszystkie obiekty do których się odwołuje też muszą być trwałe.

• Jako nazwy takiego obiektu (niekoniecznie jedynej) używa się PID (persistent object identifier)

• Repozytoria obiektów trwałych nie są dzielone, jeśli dodamy współbieżny dostęp otrzymamy prawdziwą obiektową bazę danych.

• Brak optymalizacji zapytań. Główny problem to wyrażenia ścieżkowe, trudno dla nich budować indeksy.

• Brak dobrej formalizacji, ale są już algebry podobne do algebry relacji.

• Pięć typowych operacji: suma (union, różnica (difference), selekcja (select), generowanie (generate), odwzorowanie (map).

• Jednak brak powiązania tych operacji z niskopoziomowymi operacjami fizycznymi (takiego jak w algebrze relacji RBD), stąd ich arbitralność.

• Brak uniwersalnych języków zapytań. Zwykle brak zagnieżdżonych podzapytań, funkcji agregujących, grupowania. Brak automatycznego wsparcia dla obsługi ekstensji klasy — zbioru jej egzemplarzy; użytkownik musi sam zdefiniować kolekcję (collection) i pilnować jej aktualizacji przy dodawaniu i usuwaniu obiektów.

• Kompozycyjność

  • W modelu relacyjnym wynik zapytania jest (anonimową) relacją.

  • Można go więc obrobić kolejnym zapytaniem, co umożliwia składanie zapytań.

  • W modelu obiektowym jest gorzej, obiekty ze zbioru wynikowego mogą nie należeć do żadnej klasy.

• Brak wsparcia dla redefiniowania klas (odpowiednik ALTER z SQL), np. dodawania lub usuwania atrybutów.

• Brak perspektyw (ale może są zbędne).

• Brak sensownego mechanizmu definiowania uprawnień, nie wiadomo jaka ziarnistość: obiekt, zbiór, klasa, fragment hierarchii?

• Bardzo ograniczone więzy spójności, konieczność realizacji metodami.

• Kłopoty z współbieżnością, ręczne operowanie blokadami.

  • Problem długich transakcji (unika się ich w systemach OLTP dla relacyjnych baz danych).

  • Propozycja: wspólna publiczna baza danych + prywatne bazy danych użytkowników.

Definiowanie klasy wygląda w O następująco:

class Instytut
  type tuple : (obszar-badań : string,
                nazwa-instytutu : string,
                adres : Adres,
                grupa-badawcza : set(Zespół))
  public read nazwa-instytutu, write obszar-badań
  method init(string, string, Adres, set(Zespół)) :
    Instytut is public;

Zamiast tuple można użyć list lub set, a nawet zagnieżdżać je w sobie.

Deklaracja metody występująca powyżej podaje jedynie jej sygnaturę.

Kolekcje muszą być tworzone ręcznie, mamy dwie możliwości. Możemy utworzyć kolekcję jako klasę class Instytuty type set(Instytut); albo też jako nazwaną wartość złożoną

make-class 'Instytut'
  superclasses: nil
  attributes: '((obszar-badań: domain string)
                (nazwa-instytutu: domain string)
                (adres: domain Adres)
                (grupa-badawcza:
                  domain (set-of Zespół)))

Uwagi:

• Można określać wartości domyślne dla atrybutów

• Wielodziedziczenie

Rodzaje OID:

• logiczne: bez związku z adresem w pamięci zewnętrznej

• fizyczne: na podstawie położenia

Dziedziczenie to jedno z podstawowych pojęć obiektowych baz danych. PostgreSQL umożliwia nakładanie dziedziczenia na tabele.

Zobaczmy to na przykładzie. Utworzymy dwie tabele: tabelę miast i tabelę stolic. Ponieważ stolice także są miastami, chcemy uniknąc dublowania informacji. Jeden ze sposobów to

CREATE TABLE Stolice (
  nazwa       text,
  populacja   real,
  temperatura real
  kraj        char(3)
);
CREATE TABLE Inne_miasta (
  nazwa       text,
  populacja   real,
  temperatura real
);

CREATE VIEW miasta AS
  SELECT nazwa, populacja, temperatura FROM Stolice
    UNION
  SELECT nazwa, populacja, temperatura FROM Inne_miasta;

W PostgreSQL lepszym rozwiązaniem jest:

CREATE TABLE Miasta (
  nazwa       text,
  populacja   real,
  temperatura real
);
CREATE TABLE Stolice (
  kraj char(3)
) INHERITS (Miasta);

Tabela Stolice dziedziczy wszystkie kolumny (nazwa, populacja, temperatura) z macierzystej tabeli Miasta. W tabeli tej występuje jednak dodatkowa kolumna kraj.

Poniższe zapytanie podaje nazwy wszystkich miast (także stolic), w których średnia temperatura roczna jest wyższa niż 10C:

SELECT nazwa, temperatura
  FROM Miasta
  WHERE temperatura > 500;

SELECT nazwa, temperatura
  FROM ONLY Miasta
  WHERE temperatura > 500;

W PostgreSQL tabela może dziedziczyć również z kilku tabel. Struktura dziedziczenia nie może jednak zawierać cykli.

W PostgreSQL można definiować typy w sposób zbliżony do SQL3. Definicja ma postać:

  CREATE TYPE typ AS OBJECT (
  lista atrybutów i metod
  );

Używając jej możemy zdefiniować typ dla punktów:

CREATE TYPE punkt_t AS OBJECT (
  x NUMERIC,
  y NUMERIC
);

Po zdefiniowaniu typu obiektowego używa się podobnie jak typów standardowych, np. możemy teraz zdefiniować typ dla odcinków:

CREATE TYPE odcinek_t AS OBJECT (
  początek punkt_t,
  koniec   punkt_t
);

Możemy teraz utworzyć tabelę zawierającą odcinki wraz z ich identyfikatorami (ID):

CREATE TABLE Odcinki (
  ID      INT,
  odcinek odcinek_t
);

Typy usuwamy poleceniem DROP:

  DROP TYPE odcinek_t;

Typów zdefiniowanych można również używać bezpośrednio de definiowania tabel (odpowiednik ,,rowtype” z SQL3). W poleceniu CREATE TABLE można zastąpić listę kolumn słowem kluczowym OF i nazwą typu, np.

  CREATE TABLE Odcinki OF odcinek_t;

Dostęp do składowych obiektu uzyskuje się używając notacji kropkowej. Jeśli O jest pewnym obiektem typu T, którego jedną ze składowych (atrybutów lub metod) jest A, to O.A odnosi się do tej składowej w obiekcie O.

Możemy wyszukać współrzędne początków owszystkich odcinków

  SELECT o.odcinek.początek.x, o.odcinek.początek.y
  FROM Odcinki o;

  SELECT o.odcinek.koniec
  FROM Odcinki o;

Dla typu t wyrażenie REF t oznacza jego typ referencyjny (,,ID obiektu”). Można go używać w definicjach kolumn:

  CREATE TABLE Odcinki (
    początek REF punkt_t,
    koniec   REF punkt_t
  );

Używając takiego typu trzeba pamiętać o pewnych ograniczeniach. Konkretne referencje muszą odnosić się do wierszy tabeli podanego typu. Na przykład dla tabeli

  CREATE TABLE Punkty OF punkt_t;

  INSERT INTO Odcinki
  SELECT REF(pp), REF(qq)
  FROM Points pp, Points qq
  WHERE pp.x < qq.x;

Referencje nie mogą natomiast odnosić się do obiektów występujących w kolumnach innych tabel, ani nie mogą być tworzone ad hoc (np. umieszczając w poleceniu INSERT klauzulę VALUES(REF(punkt_t(1,2)), REF(punkt_t(3,4)))).

Przechodzenie po referencji zapisuje się używając notacji kropkowej, np. poniższe zapytanie podaje współrzędne x początków i końców wszystkich odcinków w tabeli Odcinki.

  SELECT ll.początek.x, ll.koniec.x
  FROM Lines2 ll;

W Postgresie jako typów kolumn można używać typów tablicowych. Wartością atrybutu może być wtedy cała tablica, tak jak dla kolumny b poniżej.

Aby było to możliwe, należy najpierw zdefiniować relację jako typ, używając frazy AS TABLE OF, np.

  CREATE TYPE wielobok_t AS TABLE OF punkt_t;

Teraz można zdefiniować relację, w której jedna z kolumn będzie reprezentowała wieloboki, tzn. zbiory punktów, np.

  CREATE TABLE Wieloboki (
    nazwa VARCHAR2(20),
    punkty wielobok_t)
  NESTED TABLE punkty STORE AS TabPunkty;

Relacje odpowiadające poszczególnym wielobokom nie są zapisywane bezpośrednio jako wartości atrybutu punkty, lecz trzyma się je w pojedynczej tabeli, której nazwę należy zadeklarować. Do tabeli tej nie można się odwoływać bezpośrednio.

Przy wstawianiu wierszy do relacji Wieloboki używa się konstruktora typu dla zagnieżdżonej relacji (wielobok_t). Wartość zagnieżdżonej relacji podaje się w nim jako rozdzielaną przecinkami listę wartości odpowiedniego typu (punkt_t), najczęściej także używając konstruktora.

  INSERT INTO Wieloboki
  VALUES('kwadrat',
         wielobok_t(punkt_t(0.0, 0.0), punkt_t(0.0, 1.0),
                    punkt_t(1.0, 0.0), punkt_t(1.0, 1.0)));

Wierzchołki tego kwadratu podaje poniższe zapytanie:

  SELECT punkty
  FROM Wieloboki
  WHERE nazwa = 'kwadrat';