1.1.

Geneza OBD

Czemu szukano nowego modelu danych ?

Słabości modelu relacyjnego:

Prostota vs obiektów złożonych

Brak abstrakcyjnych typów danych

Brak agregacji i generalizacji

Języki baz danych różnią się od języków programowania

Brak transakcji długotrwałych

Dominacja obiektowych metod analizy i projektowania

Problemy z danymi multimedialnymi

Czemu trafiono na model obiektowy ?

Trendy w oprogramowaniu

Oczekiwania:

oddzielenie specyfikacji od implementacji

mechanizmy kompozycji i dekompozycji

ponowne użycie

Efekty:

niezawodność

testowalność

rozszerzalność

łatwa pielęgnacja

szybkie prototypowanie

współdziałanie

przenaszalność

Jak trafiono na model obiektowy:

Jak doszło do obiektowych baz danych:

1.2.

Cechy OBD

Obligatoryjne cechy (mandatory)	Obiekty złożone Identyfikacja obiektów Hermetyzacja Typy i klasy Dziedziczenie Polimorfizm Kompletność obliczeniowa	Rozszerzalność Trwałość Obsługa BDBD Współbieżny dostęp Odtwarzanie Zapytania Ad-Hoc
Opcjonalne (optional)	Dziedziczenie wielokrotne Wersje	Długie transakcje Rozproszoność
Otwarte (open)	Wielojęzykowość Ortogonalność typów	Unifikacja postaci obiektu Reprezentacja obiektów

1.3.

Zawodnicy

Obiektowo relacyjne:

Nazwa	Język	Platforma	Dziedziny	Orientacja obiektowa
IRIS	C, LISP, OSQL	HP68000, Workstations	OIS, CAD/CAM, Knowledge Bases	strukturalna
Illustra	C,.C++,Visual C++, Visual Basic, ODBC	Sun OS, Solaris, Dec Alpha PSF1, SGI Irix, HP-UX, Windows NT/3.1	CAD/CAM, OIS,GIS	strukturalna
Orion	C, LISP, C++	SUN3, Apollo, HP, SGI, DEC	CAD/CAM, OIS, AI, multimedia	behawioralna
Starburst	C, C++	RISC 6000, IBM PC / UNIX	CAD/CAM, AI, systemy ekspertowe	operacyjna
Statice	Common LISP	LISP-Machines	-	operacyjna
UniSQL	C++, Smalltalk, C, ODBC, SAG CLI, ANSI SQL, Object SQL, PowerBuilder Access	Sun PARCstation, SGI, HP 9000, IBM RS/6000, DEC Alpha AXP, Windows NT	-	strukturalna

Obiektowo zorientowane:

Nazwa	Język	Platforma	Dziedziny	Orientacja obiektowa
ENCORE	C	SUN3, SUN4/Unix SUN,DEC / VMS	CAD	-
KIWI	OOPS+	SUNVIEW	Systemy z bazami wiedzy	behawioralna
O2	C, C++, CO2, SQL, O2Query	SUNWorkstation/ OS4.0	CAD/CAM, GIS, OIS	behawioralna
ObjectStore	MVC++,Java, SmallTalk	SUN, DEC, HP, Apollo; Win 3.1/95/NT, Unix, OS2, VMS	CAD/CAM, CAP, CASE, OIS, CAE, GIS	behawioralna
Ontos	C++	SUN3, SUN4, Apollo, OS/2, DEC, VAX, VMS	CAD/CAM	behawioralna
Poet	C, C++, ODBC OQL	Windows 3.1, Novell, NT Macintosh, OS/2, NextStep, Sun OS, SCO Solaris, SGI,HP, AIX	CAD, Informacja multimedialna	behawioralna
Versant	C/C++	SUN3, SUN4 /OS4.0	CAD/CAM	behawioralna

Obiektowe:

Nazwa	Język	Platforma	Dziedziny	Orientacja obiektowa
AVANCE	PAL (podobny do SmallTalk)	-	VLSI,CAD, CASE, OIS	behawioralna
EXODUS	E (rozszerzenie C++)	-	-	behawioralna
GemStone	OPAL, C, C++, Topaz, SmallTalk	SUN3,SUN4,DEC Apple, IBM, PC Tektronix / VAX, VMS	CAD, OIS, bazy wiedzy, CAM	behawioralna

Dziedziny wykorzystania

• CASE - Computer Aided Software Engineering

• MCAD - Mechanical computer aided design

• ECAD - Electronics computer aided design

• CAM - Computer aided manufacturing

• CAP - Computer aided publishing

• OIS - Office information systems

• Multimedia - Multimedia systems

• Bazy wiedzy - Knowledge bases

• Systemy czasu rzeczywistego

• Aplikacje w nauce i medycynie

2.Obiektowy model danych

Klasa:

Wszystkie obiekty, które mają ten sam zbiór atrybutów i metod, mogą być zgrupowane w jednej klasie. Obiekt należy tylko do jednej klasy, jako instancja tej klasy. Klasa jest również obiektem; w szczegolności klasa jest instancją metaklasy.

Klasa służy jako wzorzec do tworzenia nowych obiektów.

Obiekt:

Każda encja pochodząca z rzeczywistego świata jest obiektem z którym jest skojarzony systemowy, jednoznaczny identyfikator. Przykłady: osoba, konto bankowe, wiatr, kolor czerwony.

Tożsamość:

Obiekt jest wyróżniany w otaczającym nas świecie poprzez swoje istnienie, nie poprzez jakąkolwiek wartość, która go odróżnia od innych obiektów.

Atrybuty + Metody:

Obiekt charakteryzuje się jednym lub więcej atrybutami i jedną lub więcej metodami, które operują na wartościach tych atrybutów. Wartość atrybutu obiektu jest również obiektem. Atrybut obiektu może przyjmować pojedynczą wartość lub zbiór wartości. Wartości atrybutów obiektu tworzą stan obiektu, a metody związane z obiektem działają na stanie obiektu.

Atrybuty klasowe wyrażają wspólne cechy obiektów danej klasy. (średnia ocen grupy)

Atrybuty obiektów charakteryzują cechy obiektu, stanowiące jego stan statyczny. (nazwisko, wiek, kolor)

Dziedziczenie:

Dziedziczenie pozwala na zdefiniowanie nowej wyspecjalizowanej klasy na podstawie klasy nuż istniejącej.

Dziedziczenie pozwala na utworzenie bardziej ogólnej klasy z klas bardziej wyspecjalizowanych poprzez wyciągnięcie wspólnych dla nich cech.

Dziedziczenie jednokrotne - gdy klasa dziedziczy atrybuty i metody od tylko jednej klasy.

Dziedziczenie wielokrotne - gdy klasa dziedziczy atrybuty i metody od więcej niż jednej nadklasy.

Hermetyzacja:

Nie ma innej drogi dostępu do obiektu (jego atrybutów i metod) oprócz ogólnie dostępnego interfejsu który jest dla niego określony.

Polimorfizm (przesłanianie):

Właściwość pozwalająca aby ta sama nazwa była używana do różnych zmiennych czy funkcji.

3.Modelowanie OBD z użyciem jezyka uml

Diagram klas :

Diagram klas pokazuje klasyczne struktury modelu w szczególności, rzeczy które istnieją (klasy, typy) ich wewnętrzne struktury, ich relacje z innymi rzeczami.

Diagram klas nie pokazujeczasowych informacji jednakże może zawierać .....wystąpienia rzeczy które, mają lub opisują czasowe zachowania.

Diagram klas jest grafem elementów klasyfikatora połaczonych rożnymi statycznymi relacjami.

Diagram klas może zawierać również interfejsy pakiety relacje, czy nawet instancje takie jak obiekty i linki.

Diagram przypadków użycia:

Pokazuje elementy z modelu przypadków użycia. Model przypadków użycia reprezentuje funkcjonalność systemu lub klasy jako ..... do zewnętrznych interaktorów z systemem.

Diagram przypadków użycia jest grafem aktorów, zestawem przypadków użycia otoczonym przez granice systemu, komunikacja skojarzona pomiędzy aktorami i przypadkami użycia, i uogólnienia pomiędzy przypadkami użycia.

4.1. Zmiany podstawowe:

Rodzaje zmian schematu:

• zmiany zawartości klasy

• zmiany atrybutu

• dodanie nowego atrybutu do klasy

• usunięcie istniejącego atrybutu z klasy

• zmiana nazwy atrybutu w klasie

• zmiana dziedziny atrybutu w klasie

• zmiana wartości domyślnej atrybutu

• zmiany metody

• dodanie nowej metody do klasy

• usunięcie istniejącej metody z klasy

• zmiana nazwy metody w klasie

• zmiana kodu realizacji metody w klasie.

• zmiana nazwy klasy

• zmiany powiązania nadklasa/podklasa

• uczynienie klasy S nadklasą klasy C

• usunięcie klasy S z listy nadklas klasy C

• zmiana kolejności nadklas dla klasy C

• dodanie nowej klasy

• usunięcie istniejącej klasy

• utworzenie nowej klasy C jako uogólnionej nadklasy istniejących n klas

• podział klasy C na n nowych klas

• połączenie n klas w jedną nową klasę.

4.2. Niezmienniki:

• zbiór niezmienników stanowi podstawę do określenia semantyki zmian schematu (każda zmiana w schemacie musi zachować wszystkie niezmienniki)

• w modelu modyfikowania schematu w systemie ORION występują następujące niezmienniki:

1.Niezmiennik hierarchii klas:

• cały schemat bazy danych składa się z prostej hierarchii klas, tzn. każda klasa ma swoją pozycję i jest osiągalna z klasy CLASS

• hierarchia klas jest przedstawiona w postaci grafu (DAG), mającego korzeń,graf ten jest spójny, skierowany, acykliczny

• korzeniem grafu DAG jest klasa zdefiniowana jako CLASS;

2.Niezmiennik nazwy:

• wszystkie klasy mają jednoznaczne nazwy,

• wszystkie atrybuty i metody w danej klasie mają jednoznaczne nazwy,

• różne klasy mogą mieć atrybuty i metody o tych samych nazwach;

3.Niezmiennik pochodzenia:

• wszystkie atrybuty i metody klasy mają jednoznacznie określone źródło,

• jeśli klasa ma więcej niż jedną nadklasę z atrybutami lub metodami o tych samych nazwach, to klasa może odziedziczyć tylko jeden taki atrybut lub metodę;

4.Niezmiennik pełnego dziedziczenia:

• klasa dziedziczy wszystkie atrybuty i metody od każdej ze swoich nadklas, chyba że pełne dziedziczenie narusza niezmienniki nazwy i pochodzenia,

• jest to zasadniczo rozszerzenie niezmiennika pochodzenia przez określenie warunku, że jeśli dwa atrybuty lub metody mają różne źródła, lecz tę samą nazwę w dwóch różnych nadklasach , to jeden lub oba mogą być odziedziczone;

• w przypadku dziedziczenia obu jeden z nich musi mieć zmienioną nazwę, aby nie naruszać niezmiennika nazwy;

• niezmiennik ten wymaga dziedziczenia co najmniej jednego atrybutu, ale nie określa którego - to określają reguły;

Reguły modyfikacji:

• reguły umożliwiają systemowi wybranie sposobu zachowania niezmienników

• w modelu ORION reguły klasyfikuje się według czterech kategorii:

• reguły rozwiązywania konfliktów - używane w razie wystąpienia konfliktu nazwy lub źródła (gwarantują spełnienie niezmienników nazwy i pochodzenia),

• reguły dziedziczenia - własności odziedziczonego atrybutu/metody mogą być przedefiniowane w podklasie (gwarantują niezmiennik pełnego dziedziczenia)

• reguła dziedziny (gwarantuje niezmiennik pełnego dziedziczenia);

• reguły hierarchii klas - stosowane w sytuacjach gdy zostanie naruszony niezmiennik hierarchii klas przez spowodowanie niespójności hierarchii klas (zapewniają zachowanie spójności hierarchii klas);

Reguły rozwiązywania konfliktów:

REGUŁA 1:

• jeśli nazwa atrybutu lub metody zdefiniowanej lokalnie dla klasy pozostaje w konflikcie z nazwą dziedziczonego atrybutu bądź metody to wybiera się atrybut/metodę zdefiniowaną lokalnie

jeśli nowy atrybut/metoda zdefiniowana lokalnie dla klasy pozostaje w konflikcie z atrybutem/metodą zdefiniowaną wcześniej, to nowy atrybut/metoda zostaje odrzucony/a

REGUŁA 2:

• jeśli dwie lub więcej nadklas danej klasy ma atrybut/metodę o identycznych nazwach, lecz innych źródłach, to należy wybrać atrybut/metodę pierwszej nadklasy wśród nadklas pozostających w konflikcie (każda klasa ma związaną ze sobą listę nadklas,pierwsza nadklasa to pierwsza występująca na tej liście)

REGUŁA 3:

• jeśli dwie lub więcej nadklasy danej klasy mają atrybuty o tym samym źródle pochodzenia, to jest dziedziczony atrybut o najbardziej wyspecjalizowanej dziedzinie

• jeśli dziedziny są takie same lub jedna dziedzina nie stanowi nadklasy dla drugiej to następuje dziedziczenie atrybutu od pierwszej nadklasy wśród nadklas które są w konflikcie;

Reguły dziedziczenia:

REGUŁA 4:

• każda zmiana własności atrybutu lub metody w klasie C jest przenoszona rekurencyjnie do wszystkich podklas S klasy C, w których te własności nie były przedefiniowane;

REGUŁA 5:

• zmiana nazwy atrybutu/metody lub dodanie nowego atrybutu/metody w klasie C jest propagowane rekurencyjnie do podklasy S klasy C jedynie wtedy, kiedy zmiana ta nie spowoduje konfliktu nazwy w S;

REGUŁA 6:

• dziedzinę dziedziczonego atrybutu można uszczegóławiać w momencie dziedziczenia;

• jednakże niezależnie od sposobu pojawienia się atrybutu (przez dziedziczenie, czy lokalną definicję), jeżeli dla klasy powstały już instancje, to dziedzinę atrybutu można jedynie uogólniać;

• dziedzina odziedziczonego atrybutu w klasie nie może być ogólniejsza niż dziedzina atrybutu w nadklasie klasy, w której zdefiniowano atrybut;

Reguły hierarchii klas:

REGUŁA 7:

jeśli nowa, dodana klasa nie ma zdefiniowanych nadklas, to jej domyślną nadklasą będzie klasa CLASS;

REGUŁA 8:

• jeśli klasa A jest jedyną nadklasą klasy B i klasa A zostanie usunięta z listy nadklas B, to klasa B staje się bezpośrednią podklasą wszystkich bezpośrednich nadklas klasy A. Porządek występowania nowych nadklas klasy B jest taki sam, jak kolejność nadklas klasy A.

REGUŁA 9:

• klasa A uczyniona nadklasą klasy B musi być dopisana na koniec listy nadklas klasy B;

• reguła ta chroni przed wystąpieniem konfliktu nazw, jaki mógłby powstać po dodaniu tej nadklasy;

• jeśli mimo wszystko odziedziczony atrybut wywoła konflikt to należy go usunąć za pomocą reguły 3;

REGUŁA 10:

• usunięcie klasy A następuje w trzech etapach:

• najpierw w grafie hierarchii klas zostają usunięte wszystkie krawędzie wychodzące z klasy A do jej podklas

• następnie wszystkie krawędzie skierowane do A z jej nadklas

wreszcie sam węzeł A.

Reguły & pojedyncze/wielokrotne dziedziczenie:

5. Fizyczna realizacja OBD

5.1.

5.2. Zasady grupowania obiektów

Definicja ogólna

Grupowanie - wyznaczenie podobnych obiektów

na podstawie ściśle sformułowanych kryteriów

Definicja z analizy skupień

Grupowanie - porządkowanie oraz dzielenie na

klasy danego zbioru obiektów na podstawie

matematycznie sformułowanych kryteriów

Definicja z baz danych

Grupowanie - rozmieszczenie obok siebie w

pamięci zewnętrznej tych obiektów bazy danych,

które są logicznie powiązane, co wyraża się w

ich wspólnym wykorzystaniu w operacjach

Kryteria grupowania

• Typ obiektu

• Wartość atrybutu

• Kompozycje obiektów

• Relacje międzyobiektowe

• Wskazówki użytkownika

• Rozmiar obiektów

• Wzorcy dostępu

Wady grupowania statycznego

• Nieokreśloność dla obiektów współdzielonych

• Nieodpowroność na częste modyfikacje

• Nieodpowroność na ewolucje schematu

• Nie uwzględnia logicznych związków użytkownika

• Nie uwzględnia indywidualnego zachowania obiektów

• Nie uwzględnia atrybutów stabilnych i zmiennych

Algorytmy grupowania

Metody aglomeracyjne

Efektywność grupowania

• Częstotliwość transakcji

• Liczba obiektów w transakcji

• Liczba i częst. modyfikacji

• Liczba obiektów kompozytowych

• Rozmiar i strategia bufora

• Indeksowanie

• Rozmiar grup

• Rozmiar obiektów

5.3.

Indeksowanie w OBD

• Indeksy wielokrotne (multi-index)

• Indeksy zagnieżdżone (nested index)

• Indeksy ścieżek (path index)

• Indeksy złączeń (join index)

• Relacje dostępu (access relations)

• Indeksy hierarchiczne

Niekombinatoryczne

Kombinatoryczne

Podziału

Aglomeracyjne

Algorytmy niehierarchiczne

Algorytmy hierarchiczne

Analiza skupień

cluster analysis

---