bazy danych i in ynieria oprogramowania n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Bazy danych i inżynieria oprogramowania PowerPoint Presentation
Download Presentation
Bazy danych i inżynieria oprogramowania

Loading in 2 Seconds...

play fullscreen
1 / 16

Bazy danych i inżynieria oprogramowania - PowerPoint PPT Presentation


  • 109 Views
  • Uploaded on

Bazy danych i inżynieria oprogramowania. Wykład 7: Wprowadzenie do standardu ODMG, część 1: Motywacje, Model obiektowy. Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa. Plan wykładu (część 1).

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Bazy danych i inżynieria oprogramowania' - tanek-pena


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
bazy danych i in ynieria oprogramowania
Bazy danych i inżynieria oprogramowania

Wykład 7:

Wprowadzenie do

standardu ODMG, część 1:

Motywacje, Model obiektowy

Kazimierz Subieta

Instytut Podstaw Informatyki PAN,

Warszawa

Polsko-Japońska Wyższa Szkoła

Technik Komputerowych, Warszawa

plan wyk adu cz 1
Plan wykładu (część 1)

Co to jest ODMG?

Krytyczne cechy obiektowych baz danych; kryteria wyboru

Cele i uwarunkowania standardu

Zawartość standardu ODMG 2.0; ramowa architektura

Model obiektowy ODMG

  • Typy i klasy; interfejsy i implementacje
  • Podtypy i dziedziczenie
co to jest odmg
Co to jest ODMG?

Object Database Management Group

Jest to konsorcjum powstałe w wyniku porozumienia kilkunastu firm oferujacych

swoje produkty określane jako “obiektowe systemy zarządzania bazami danych”:

Objectivity, ObjectDesign, Ontos, O2, Poet, Servio, Versant,, ...

Pomysł, forma działania, początkowy impuls oraz obiektowy model danych pochodzi od

konsorcjum OMG, która opracowała i rozwija standard CORBA. ODMG nie ma związku

z oficjalnymi instytucjami normalizacyjnymi takimi jak ANSI lub ISO. Zdaniem twórców

ODMG, instytucje te działają wolno, nieefektywnie i są obciążone własnymi preferencjami.

Standard ODMG budzi kontrowersje, zaś jego ogólny poziom techniczny jest przedmiotem krytyki. Wady są systematycznie usuwane w kolejnych wersjach standardu, ale nadal jest ich sporo (bedą omówione).

  • ODMG-93 wersja 1.1 (grudzień 1993)
  • ODMG-93 wersja 1.2 (styczeń 1996)
  • ODMG wersja 2.0 (sierpień 1997)

Wersje:

(Morgan Kaufman Publishers)

kluczowi zawodnicy obiektowych bd
Kluczowi zawodnicy obiektowych BD

Źródło: Barry & Associates, Inc., styczeń 1997, http://www.odbmsfacts.com

System

ODB-II (Jasmine)

GemStone

Odapter (Java/Depot)

ITASCA (Orion)

Illustra/Informix

MATISSE

O2

ObjectStore

Objectivity/DB

Omniscience

ONTOS DB

Persistence

IDB Object Database

POET

UniSQL

OSMOS

ODBMS

VERSANT

Wersja

2.0

5.0

B.05.xx

2.3.5

3.0

3.0

5.0

4.0.2

4.1

3.0

3.2

3.210

2.5

4.0

3.5

R10.0

3.1

4.2

Firma

Fujitsu Software Corporation + Computer Associates

Gemstone Systems, Inc.

Hewlett-Packard Company

IBEX Corporation S.A.

Illustra Information Technologies, Inc.

MATISSE Software, Inc.

O2 Technology

Object Design, Inc.

Objectivity, Inc

Omniscience Object Technology, Inc.

ONTOS, Inc.

Persistence Software, Inc.

Persistent Data Systems, Inc.

POET Software, Inc.

UniSQL, Inc.

Unisys Corporation

VC Software, Inc.

Versant Object Technology

krytyczne cechy obiektowych baz danych 1
Krytyczne cechy obiektowych baz danych: (1)
  • Jasny, naturalny, uniwersalny, powszechnie akceptowany model danych i
  • odpowiadający temu modelowi język opisu danych (język schematu)
  • Języki zapytań: zapytania interakcyjne ad hoc, zagnieżdżanie zapytań (embedding)
  • Programowanie poprzez języki zapytań; bezszwowa integracja języka zapytań z
  • językiem programowani; perspektywy, zapamiętane procedury, reguły
  • Optymalizacja zapytań (query optimization)
  • Obiektowe programowanie wizyjne (visual programming)
  • Interfejsy (wiązania) do programowania aplikacji (API) dla
  • popularnych języków programowania
  • Wygodne środowisko do tworzenia i uruchamiania aplikacji
  • Dynamiczna autoryzacja dostępu
krytyczne cechy obiektowych baz danych 2
Krytyczne cechy obiektowych baz danych (2)
  • Sprawne zarządzanie pamięcią zewnętrzną, indeksowanie, buforowanie, odśmiecanie
  • Konsekwentna organizacja i dostęp do meta-informacji (katalogów, pomocy)
  • Rozszerzalność, skalowalność, dynamiczna ewolucja schematu
  • Wspomaganie dla więzów integralności (integrity constraints)
  • i aktywnych reguł (active rules)
  • Dobrze udokumentowane, uniwersalne, elastyczne i minimalne biblioteki klas
  • oraz inne środki ponownego użycia
  • Wspomaganie dla materializowanych i niematerializowanych obiektowych
  • perspektyw (object views), aktualizacja perspektyw (view updating)
  • Bezszwowa integracja multimediów (tekst, grafika, wideo, audio)
krytyczne cechy obiektowych baz danych 3
Krytyczne cechy obiektowych baz danych (3)
  • Zintegrowanie systemu z bogatym zestawem narzędzi i udogodnień (data mining, CASE,
  • data warehouses, pakiety statytystyczne, ...)
  • Zarządzanie transakcjami (własności ACID, długie transakcje)
  • Składowanie (backup), odwracanie (rollback) i odtwarzanie (recovery)
  • Wersjonowanie, własności temporalne, obiekty archiwalne
  • Integracja z serwisami Internetu (przystosowanie do dostępu poprzez Web)
  • Współdziałanie systemów heterogenicznych, przystosowanie do współpracy z
  • z oprogramowaniem komponentowym (CORBA, OpenDoc, JavaBeans, ActiveX)
  • Architektura klient-serwer
  • Zarządzanie rozproszonymi obiektami, rozproszone przetwarzanie,
  • optymalizacja zapytań w systemach rozproszonych
  • Zarządzanie metodami dostępu, parametryczne dostrajanie
kryteria oceny obiektowych szbd
Kryteria oceny (obiektowych) SZBD

Wydajność (performance) - jak szybki jest produkt?

Skalowalność (scalability) - jak produkt będzie działał gdy wzrośnie

liczba użytkowników i objętość danych?

Funkcjonalność (functionality) - jakie możliwości i cechy produkt oferuje?

Zgodność ze standardami - czy produkt uzależnia od jednego dostawcy?

Łatwość użycia (usability) - ile wysiłku kosztuje nauczenie się produktu i

jak łatwo będzie się go używać?

Niezawodność (reliability) - jak często produkt zawodzi?

Wspomaganie (support) - czy dostawca produktu zapewnia pomoc i jest odpowiedzialny?

Środowisko (environment) - na jakim sprzęcie/systemie operacyjnym pracuje produkt?

Żywotność (viability) - czy można oczekiwać, że dostawca

będzie podtrzymywał produkt w przyszłości?

Cena (price) - ile kosztuje produkt, w krótkim czasie i

w oczekiwanym horyzoncie czasowym?

po co standard
Po co standard?

Przenaszalność (portability):

Aplikacja może działać na różnych obiektowych SZBD.

Współdziałanie (interoperability):

Aplikacja może działać jednocześnie z wieloma obiektowymi SZBD

Wartość dodana, synergia:

Wytwórcy oprogramowania mogą skupić się na wartościach dodanych,

nie na podstawowych interfejsach

Narzędzia i biblioteki wspólne dla wielu systemów (nowy rynek)

Uwolnienie użytkowników od niebezpieczeństwa zależności od jednego

dostawcy

Szybszy wzrost przemysłu, poprzez wzrost konkurencji

w zakresie wartości dodanych

Komunikacja pomiędzy użytkownikami i projektantami

Ujednolicone uczenie

W tej chwili jest dość trudno ocenić, czy standard spełni te oczekiwania. Jak uczy doświadczenie standardów SQL i C++, prawdopodobnie nie spełni. Jest to jednak nieodzowny początek drogi.

co podlega standardyzacji
Co podlega standardyzacji?

Interfejsy

Ale nie wnętrze OSZBD lub jego architekturę

Kandydaci do standardyzacji:

+

+

+/-

+/-

-

+

-

-

-

-

-

-

  • Model obiektowy (pojęcia, ograniczenia, terminologia)
  • Język definicji obiektów
  • Format wymiany informacji (przekazywania obiektów)
  • Obiektowy język zapytań
  • Abstrakcje wspomagające język zapytań (perspektywy,
  • zapamiętane procedury, aktywne reguły,...)
  • Wiązania do języków programowania: C++, Smalltalk, Java,...
  • Zintegrowany język programowania aplikacji oparty o
  • język zapytań (do pisania metod)
  • Pomosty (gateways) do innych systemów (np. relacyjnych)
  • Administrację systemem, katalogi BD, dostęp do katalogów
  • Prawa dostępu, bezpieczeństwo
  • Narzędzia i usługi (klasy systemowe, biblioteki klas)
  • Protokóły wymiany informacji w sieci (np. IIOP)

Jest jeszcze wiele do zrobienia...

odmg 2 0 zawarto
ODMG 2.0: zawartość
  • Ramowa architektura OSZBD
  • Model obiektowy
  • Języki specyfikacji obiektów
  • - Język definicji obiektówODL (nadzbiór OMG IDL)
  • - Format wymiany obiektów
  • Obiektowy język zapytań OQL (składnia wzorowana na SQL)
  • Wiązanie do C++
  • Wiązanie do Smalltalk’a
  • Wiązanie do Java
  • Dodatki
  • - Porównanie z modelem obiektowym OMG
  • - Obiektowe bazy danych w środowisku OMG CORBA

“Standard leży na przecięciu trzech istniejących dziedzin technologicznych: baz danych (SQL), technologii obiektowych (OMG) oraz obiektowych języków programowania (C++, Smalltalk, Java).”

odmg 2 0 podej cie umiarkowanie rewolucyjne
ODMG 2.0: podejście umiarkowanie rewolucyjne

Podejście ewolucyjne: Rozbudowa relacyjnych SZBD (DB2, Oracle, Sybase, Informix, Ingres) o nowe własności, w tym obiektowe np. BLOBy, abstrakcyjne typy danych, zapamiętane procedury. Niweczą standard SQL-92 poprzez niekompatybilne rozszerzenia

Podejście eklektyczne, odmiana podejścia ewolucyjnego: Budowa systemów obiektowo-relacyjnych, umożliwiających przechowywanie tradycyjnych tablic i obiektów. Brak kompatybilności, koncepcyjna redundancja, przypadkowość, niesystematyczność rozwiązań. SQL3 jest tu nadzieją, ale dość iluzoryczną.

Podejście “wolna amerykanka”: Spontaniczna rozbudowa “od dołu do góry” niektórych narzędzi wspomagających “małą informatykę”: arkuszy kalkulacyjnych, systemów przetwarzania dokumentów (LotusNotes, MS Repository). Standardyzacja - wątpliwa.

Podejście umiarkowanie rewolucyjne: Jednorodny model obiektowy, ale z licznymi odniesieniami do istniejących technologii. Takie właśnie podejście reprezentuje ODMG 2.0.

Podejście rewolucyjne: Jednorodny model obiektowy, jednorodna architektura i język programowania baz danych, język zapytań zintegrowany z językiem programowania. Całkowite odrzucenie półśrodków takich jak C++, Java, SQL. Mocny polimorficzny system kontroli typów, ortogonalna trwałość, ortogonalność języków zapytań i trwałości.

odmg 2 0 ramowa architektura
ODMG 2.0: Ramowa architektura

Baza danych

Deklaracje w ODL

lub jęz.progr./ODL

Źródłowe aplikacje

w rozszerzonym jęz.progr.

Preprocesor deklaracji

Kompilator jęz. progr.

OSZBD,

procedury czasu

wykonania (runtime)

Aplikacje w kodzie

do konsolidacji

metadane

Konsolidator (linker)

Dostęp do danych

Działający program

model obiektowy odmg
Model obiektowy ODMG

Ustala konstrukcje, które muszą być wspomagane przez OSZBD

Podstawowymi prymitywami modelu są obiekty i literale. Każdy obiekt posiada unikalny identyfikator. Literal nie posiada identyfikatora, jest to stała.

Obiekty i literale są charakteryzowane poprzez typy. Każdy element danego typu posiada wspólną dziedzinę stanów (ten sam zestaw własności) oraz wspólne zachowanie (ten sam zestaw operacji). Obiekt jest niekiedy określany jako wystąpienie typu.

Stan obiektu jest zdefiniowany jako wartości przechowywane dla własności. Własnościami mogą być atrybuty obiektu oraz związki obiektu z innymi obiektami. Zwykle własności obiektu mogą zmieniać się w czasie.

Zachowaniesię obiektu jest zdefiniowane poprzez zbiór operacji, które mogą być wykonane na obiekcie lub przez obiekt. Operacje mogą mieć parametry wejściowe i wyjściowe, każdy z wyspecyfikowanym typem. Operacja może zwrócić rezultat określonego typu.

Baza danych przechowuje obiekty, umożliwiając jednoczesny dostęp do nich przez wielu użytkowników. Opiera się na schemacie zdefiniowanym w ODL i zawiera wystąpienia typów zdefiniowane w jej schemacie.

typy i klasy interfejsy i implementacje
Typy i klasy; interfejsy i implementacje

Typ posiada dwa aspekty:

- specyfikację interfejsu (jedną)

- jedną lub więcej specyfikacji implementacji

Interfejs (interface): zewnętrzna charakterystyka obiektów danego typu widoczna dla użytkowników obiektu. Interfejs włącza operacje, które można wykonać na obiekcie oraz zmienne stanu (atrybuty), których wartości są dostępne z zewnątrz.

Implementacja: określa wewnętrzne aspekty obiektu danego typu. Składa się z reprezentacji oraz zbioru metod. Metody są ciałami procedur. Dla każdej operacji zdefiniowanej w interfejsie istnieje odpowiednia metoda, która ustala czynności niezbędne dla wykonania tej operacji. Implementacja może zawieraćstruktury danych i metody wewnętrzne, niewidoczne dla użytkowników obiektu i nie wyspecyfikowane w interfejsie.

Typ może mieć wiele implementacji, np. jedną w C++, inną w Smalltalk’u; tylko jedna z nich występuje w danej aplikacji.

Oddzielenie interfejsu (specyfikacji klasy) od implementacji jest bardzo istotne i określa sposób, w jaki ODMG podchodzi do problemu hermetyzacji (encapsulation).

Interfejs = typ

Implementacja = klasa

Mniej formalnie:

podtypy i dziedziczenie
Podtypy i dziedziczenie

subtypes, inheritance

Związek typ-podtyp (typ-nadtyp), określany także jako związek is-a.

interface Pracownik{...};

interface Profesor : Pracownik{...};

interface ProfesorNadzw : Profesor{...};

Obiekt typu Profesor posiada cały interfejs Pracownik plus swój własny.

Obiekt typu ProfesorNadzw posiada cały interfejs Profesor plus swój własny

(czyli cały interfejs Pracownik, plus to, co dodał Profesor, plus własny).

Dowolne wystąpienie podtypu jest jednocześnie wystąpieniem nadtypu, np. obiekt typu ProfesorNadzw jest jednocześnie obiektem typu Pracownik.

Relacje “być podtypem”, “być nadtypem” są przechodnie.

Stąd wynika, że wszędzie tam, gdzie może być użyty obiekt o danym typie T, może być także użyty obiekt typu T1, gdzie T1 jest podtypem T. Np. Wszędzie tam gdzie mozę być użyty obiekt Pracownik może być także użyty obiekt Profesor lub typu ProfesorNadzw. Jest to zasada zamienialności (substitutability).