Obiektowe modelowanie systemów informatycznych



Pobieranie 8,01 Mb.
Strona11/113
Data23.10.2017
Rozmiar8,01 Mb.
1   ...   7   8   9   10   11   12   13   14   ...   113

Architektura Oracle Network Computing Architekture (NCA)


Jako przykład narzędzia do realizacji rozproszonych systemów baz danych w standardzie CORBA posłuży decyzję firmy ORACLE. Network Computing Architekture (NCA) jest przeznaczona dla tworzenia rozproszonych środowisk oraz realizuje trzywarstwowy model „Klient – Serwer” (rys.25 a). ORACLE NCA jest uzasadniona na następnych standardach:

  • Technologii CORBA (Common Request Broker Architekture), która jest przeznaczona dla sterowania rozproszonymi obiektami

  • Protokołu HTTP i języka HTML dla WEB środowiska

  • Protokołu IIOP (Internet Inter–Object Protocol), który jest wykorzystywany przez technologię CORBA dla współdziałania obiektów pomiędzy sobą. W środowisku Internet ten protokół jest transportowy, specyfikuje sposób wymiany komunikatów pomiędzy obiektami poprzez protokół TCP/IP. Na odmianę od protokołu HTTP, IIOP może pamiętać dane pro wywołania obiektów oraz ich połączenia.

  • Języka definicji interfejsu – IDL (Interface Definition Language), który jest opracowany przez OMG (Object Management Group) dla opisu interfejsów, które są niezależnymi od języka oprogramowania.

Architektura NCA zawiera obiektowy mechanizm CORBA z takimi komponentami:

  • Cartridges (nabój z ang.) - to jest biblioteka klas obiektów, która pozwoli projektantom dodawać nowe funkcji do aplikacji. To oprogramowanie może połączy się do jakikolwiek warstwy „Klient – Serwer”. Specyfikacji NCA pozwala tworzyć cartridges w dowolnym środowisku oprogramowania, np. Java, C++, itp. Wszystkie cartridges będzie pracować niezależne od systemu operacyjnego.

  • Protokóły oraz standardowe interfejsy, które pozwalają współdziałać pomiędzy sobą przez szyna (lub magistral) programowy ICX (Inter-Cartridge eXchange). Szyna (lub magistral) programowy to jest zbiór interfejsów oraz obiektów, które udostępniają przezroczyste różne cartridges jeden do drugiego. Każdy cartridge może odwołać do innego cartridge.

  • Klienci, serwery aplikacji, serwery baz danych, które są bazowymi komponentami trzywarstwowej architektury

  • CASE - środowisko dla opracowania oraz sterowania cartridges oraz aplikacjami.

Rys.25 a.

O
biektowo – relacyjne bazy danych


Wady modelu relacyjnego powodowały rozwój obiektowych baz danych. Obiektowe technologie modelowania danych nie wykorzystają w żaden sposób relacyjne modele danych. Główną jednostką modelu relacyjnego jest tabela, która przechowuje wszystkie dani. Głównym elementem modelu obiektowego jest obiekt z wyznaczonymi wartościami atrybutów(stanem obiektu) oraz operacjami. Klasyczny model relacyjny oraz model obiektowy są niekompatybilne.

Razem z tym relacyjne modeli danych posiadają na rynku systemów baz danych mocne pozycji oraz mają dużą ilość stałych klientów. Dlatego otrzymała rozwój inna gałąź systemów baz danych zwaną systemami obiektowo – relacyjnymi. W tych systemach położono nacisk na spojrzenie relacyjne, uzupełniając je pojęciami obiektowymi. Producenci oraz projektanci komercyjnych produktów relacyjnych SZBD odrzucają pretensje konkurentów - zwolenników obiektowych baz danych oraz proponują ewolucyjną zmianę istniejących systemów relacyjnych. Argumentami zwolenników relacyjnych baz danych zostały zły rezultaty efektywności poszukiwania komplikowanych zapytań w obiektowych bazach danych. Zgodnie z opinią zwolenników obiektowo relacyjnych SZBD (ORSZBD) tradycyjny mechanizm stworzenia relacji trzeba wykorzystywać oraz dopełnić go operacjami z obiektami. Główne doróbki w dziedzinie obiektowo relacyjnych baz danych zostali realizowane w opracowaniu standardu SQL3 oraz w szeregu produktów ORSZBD: Informix, DB2 (firmy IBM), Oracle-8, Sybase Adaptive Server, PostgreSQL i innych.

Amerykański informatyk, profesor Stonebraker ( kierownik projektu PostgreSQL w Uniwersytecie Berkeley) zaproponował klasyfikację SZBD w zależności od złożoności schematów i rozszerzalności danych aplikacji oraz od wymóg do złożoności realizacji zapytań k tym danym. Schemat tej klasyfikacji jest pokazany na rys. 26

W dolnym lewym kwadrancie są aplikacje dla obrabiania prostych danych, które nie potrzebują komplikowanych wymóg dla stworzenia zapytań. Te aplikacje wykorzystają dla przechowywania danych system plików komputera. Przykładami takich aplikacji mogą być Word, Framemaker i inne.



Rys. 26


W dolnym prawym kwadrancie są aplikacje, które obrabiają komplikowane dani, ale nie mają dużych wymóg do stworzenia złożonych zapytań do tych danych. Te aplikacji potrzebują wykorzystania OSZBD. W górnym lewym kwadrancie są aplikacje, które realizują proste konstrukcji danych, ale potrzebują złożonych zapytań do tych danych. Do tej kategorii można odnieść aplikacje, które wykorzystają relacyjne SZBD. W górnym prawym kwadrancie są aplikacje, które potrzebują obrabiania złożonych danych oraz realizacji złożonych zapytań do tych danych. Do tej kategorii można odnieść aplikacje, które wykorzystają ORSZBD.


1   ...   7   8   9   10   11   12   13   14   ...   113


©operacji.org 2017
wyślij wiadomość

    Strona główna