Typy danych. Obiektowe bazy danych: osiągnięcia i wyzwania 28 Obiektowo zorientowany model danych
PostrelacjaModel
Klasyczny model relacyjny zakłada niepodzielność danych przechowywanych w polach rekordów tabeli. Model postrelacyjny to rozszerzony model relacyjny, który usuwa ograniczenie niepodzielności danych. Model dopuszcza pola wielowartościowe - pola, których wartości składają się z podwartości. Zbiór wartości dla pól wielowartościowych jest uważany za samodzielną tabelę osadzoną w tabeli głównej.
Na ryc. 2.6 na przykładzie informacji o fakturach i towarach do porównania pokazano prezentację tych samych danych za pomocą modeli relacyjnych (a) i postrelacyjnych (b). Z rysunku widać, że w porównaniu z modelem relacyjnym model postrelacyjny przechowuje dane wydajniej, a podczas przetwarzania nie będzie konieczne wykonywanie operacji łączenia danych z dwóch tabel.
Faktury
N faktura |
Kupujący |
N faktura |
Ilość |
||
Nad głową
N faktura |
Kupujący |
Ilość |
|
Ryż. 2.6. Struktury danych modeli relacyjnych i postrelacyjnych
Ponieważ model postrelacyjny umożliwia przechowywanie nieznormalizowanych danych w tabelach, pojawia się problem zapewnienia integralności i spójności danych. Problem ten rozwiązuje uwzględnienie odpowiednich mechanizmów w DBMS.
Godność Model postrelacyjny to zdolność do reprezentowania zestawu powiązanych tabel relacyjnych przez jedną tabelę postrelacyjną. Zapewnia to wysoką widoczność prezentacji informacji oraz wzrost efektywności ich przetwarzania.
niekorzyść Model postrelacyjny to złożoność rozwiązania problemu zapewnienia integralności i spójności przechowywanych danych.
Rozważany postrelacyjny model danych jest obsługiwany przez uniVers DBMS. Inne DBMS oparte na postrelacyjnym modelu danych obejmują również systemy Bubba i Dasdb.
Model wielowymiarowy
Wielowymiarowe podejście do reprezentacji danych pojawiło się niemal równocześnie z podejściem relacyjnym, ale zainteresowanie wielowymiarowymi systemami DBMS zaczęło się upowszechniać od połowy lat dziewięćdziesiątych. Impulsem był w 1993 roku artykuł E. Codda. Sformułowano 12 podstawowych wymagań dla systemów OLAP (OnLine Analytical Processing), z których najważniejsze dotyczą możliwości koncepcyjnej reprezentacji i przetwarzania danych wielowymiarowych.
W rozwoju koncepcji systemów informatycznych można wyróżnić dwa kierunki:
Operacyjne (transakcyjne) systemy przetwarzania;
Systemy przetwarzania analitycznego (systemy wspomagania decyzji).
Relacyjne DBMS były przeznaczone dla informatycznych systemów przetwarzania informacji operacyjnej i są w tym zakresie bardzo efektywne. W analitycznych systemach przetwarzania okazały się one nieco niezgrabne i niewystarczająco elastyczne. Wielowymiarowe DBMS są tutaj bardziej wydajne.
Wielowymiarowe SZBD to wysoce wyspecjalizowane SZBD przeznaczone do interaktywnego analitycznego przetwarzania informacji. Główne pojęcia używane w tych DBMS to agregacja, historyczność i przewidywalność.
Agregowalność dane to uwzględnianie informacji na różnych poziomach jej uogólnienia. W systemach informatycznych stopień szczegółowości prezentacji informacji dla użytkownika zależy od jego poziomu: analityk, użytkownik, menedżer, menedżer.
Historyczność dane wiążą się z zapewnieniem wysokiego stopnia statyki samych danych i ich relacji, a także obowiązkowego wiązania danych w czasie.
Przewidywalność przetwarzanie danych polega na ustawianiu funkcji predykcyjnych i stosowaniu ich do różnych przedziałów czasowych.
Wielowymiarowość modelu danych nie oznacza wielowymiarowości cyfrowej wizualizacji danych, ale wielowymiarową logiczną reprezentację struktury informacji w opisie i operacjach manipulacji danymi.
W porównaniu z modelem relacyjnym wielowymiarowa organizacja danych ma większą widoczność i zawartość informacyjną. Dla ilustracji na ryc. Rysunek 2.7 przedstawia relacyjne (a) i wielowymiarowe (b) reprezentacje tych samych danych o wielkości sprzedaży samochodów.
Podstawowe pojęcia wielowymiarowych modeli danych: wymiar i komórka.
Pomiar to zbiór danych tego samego typu, które tworzą jedną ze ścian hipersześcianu. W modelu wielowymiarowym wymiary pełnią rolę wskaźników, które służą do identyfikacji określonych wartości w komórkach hipersześcianu.
Komórka to pole, którego wartość jest jednoznacznie określona przez ustalony zestaw pomiarów. Typ pola jest najczęściej definiowany jako numeryczny. W zależności od tego, w jaki sposób są tworzone wartości danej komórki, może to być zmienna (wartości zmieniają się i mogą być ładowane z zewnętrznego źródła danych lub generowane programowo) lub formuła (wartości, takie jak komórki formuły arkusza kalkulacyjnego, są obliczane według predefiniowanych wzorów).
Ryż. 2.7. Relacyjna i wielowymiarowa reprezentacja danych
W przykładzie na ryc. 2,7 b każda wartość komórki Wielkość sprzedaży jednoznacznie określony przez kombinację wymiaru czasu Miesiąc sprzedaży i modele samochodów. W praktyce często wymagane są więcej pomiarów. Przykład trójwymiarowego modelu danych pokazano na ryc. 2.8.
Ryż. 2.8. Przykład modelu 3D
Istniejące wielowymiarowe DBMS wykorzystują dwa główne schematy organizacji danych: hipersześcienny i wielosześcienny.
W wielosześcienny Schemat zakłada, że kilka hipersześcianów o różnych wymiarach io różnych wymiarach można zdefiniować w bazie danych jako twarze. Przykładem systemu obsługującego wielosześcienny wariant bazy danych jest Oracle Express Server.
Kiedy hipersześcienny Schemat zakłada, że wszystkie komórki są zdefiniowane przez ten sam zestaw pomiarów. Oznacza to, że jeśli w bazie danych jest kilka hipersześcianów, wszystkie mają ten sam wymiar i te same wymiary.
Główny godność wielowymiarowy model danych to wygoda i wydajność analitycznego przetwarzania dużych ilości danych czasowych.
niekorzyść wielowymiarowy model danych jest jego uciążliwością dla najprostszych zadań konwencjonalnego przetwarzania informacji online.
Przykładami systemów obsługujących wielowymiarowe modele danych są Essbase, Media Multi-matrix, Oracle Express Server, Cache. Istnieją produkty programowe, takie jak Media/MR, które pozwalają na jednoczesną pracę z wielowymiarowymi i relacyjnymi bazami danych.
Model zorientowany obiektowo
W modelu obiektowym podczas prezentacji danych można zidentyfikować poszczególne rekordy bazy danych. Relacje między rekordami i ich funkcjami przetwarzania są ustanawiane przy użyciu mechanizmów podobnych do odpowiednich funkcji w obiektowych językach programowania.
Standaryzowany model obiektowy jest opisany w zaleceniach standardu ODMG-93 (Object Database Management Group – obiektowa grupa zarządzania bazą danych).
Rozważmy uproszczony model obiektowej bazy danych. Struktura obiektowej bazy danych jest graficznie reprezentowana jako drzewo, którego węzły są obiektami. Właściwości obiektów są opisane przez jakiś standardowy lub skonstruowany przez użytkownika typ (zdefiniowany jako klasa). Wartością właściwości typu class jest obiekt będący instancją odpowiedniej klasy. Każdy obiekt instancji klasy jest uważany za element podrzędny obiektu, w którym jest zdefiniowany jako właściwość. Obiekt instancji klasy należy do jej klasy i ma jednego rodzica. Ogólne relacje w bazie danych tworzą połączoną hierarchię obiektów. Przykładową strukturę logiczną bazy danych bibliotekoznawstwa zorientowanego obiektowo przedstawiono na rys.1. 2.9. Tutaj obiekt typu Biblioteka jest rodzicem obiektów instancji klasy Abonent, Katalog oraz ekstradycja. Różne typy obiektów Książki i mogą mieć tych samych lub różnych rodziców. Obiekty typu Książka które mają tego samego rodzica, muszą różnić się co najmniej numerem dostępu (niepowtarzalnym dla każdego egzemplarza książki), ale mają te same wartości nieruchomości jest b n udko, nazwy e i autor.
Logiczna struktura obiektowej bazy danych jest zewnętrznie podobna do struktury hierarchicznej bazy danych. Główna różnica między nimi dotyczy metod manipulacji danymi.
Do wykonywania działań na danych w rozważanym modelu bazy danych wykorzystywane są operacje logiczne, wzbogacone o obiektowe mechanizmy enkapsulacji, dziedziczenia i polimorfizmu.
Kapsułkowanie ogranicza zakres nazwy właściwości do obiektu, w którym jest zdefiniowana. Tak więc, jeśli w obiekcie typu Katalog dodać właściwość, która określa numer telefonu autora książki i posiada tytuł telefon, otrzymamy właściwości o tej samej nazwie dla obiektów Abonent oraz Katalog. Znaczenie takiej właściwości będzie określane przez przedmiot, w którym jest ona zawarta.
Dziedzictwo, przeciwnie, rozszerza zakres własności na wszystkich potomków przedmiotu. Tak więc dla wszystkich obiektów typu Książka, które są potomkami obiektu typu Katalog, możesz przypisać właściwości obiektu nadrzędnego: isbn, udko, tytuł oraz autor. Jeśli konieczne jest rozszerzenie działania mechanizmu dziedziczenia na obiekty, które nie są bezpośrednimi krewnymi (na przykład między dwoma potomkami tego samego rodzica), to abstrakcyjna właściwość typu abs. Zatem definicja własności abstrakcyjnych bilet oraz Pokój w obiekcie Biblioteka powoduje, że te właściwości są dziedziczone przez wszystkie obiekty podrzędne Abonent, Książka oraz Zagadnienia a. To nie przypadek, że w związku z tym wartości nieruchomości bilet zajęcia Abonent oraz ekstradycja pokazano na ryc. 2.9 są takie same - 00015.
Wielopostaciowość w obiektowych językach programowania oznacza zdolność tego samego kodu programu do pracy z heterogenicznymi danymi. Innymi słowy oznacza to dopuszczalność w przedmiotach różne rodzaje mają metody (procedury lub funkcje) o tej samej nazwie. Podczas wykonywania programu obiektowego te same metody działają na różnych obiektach w zależności od typu argumentu. W odniesieniu do rozważanego przykładu polimorfizm oznacza, że obiekty klasy Książka posiadanie różnych rodziców z klasy Katalog, może mieć inny zestaw właściwości. Dlatego programy do pracy z obiektami klas Książka może zawierać kod polimorficzny.
Wyszukiwanie w obiektowej bazie danych polega na znalezieniu podobieństw między obiektem wskazanym przez użytkownika a obiektami przechowywanymi w bazie.
Ryż. 2.9. Logiczna struktura bazy bibliotekarskiej
Główny godność obiektowy model danych w porównaniu z relacyjnym to możliwość wyświetlania informacji o złożonych relacjach obiektów. Obiektowy model danych pozwala zidentyfikować pojedynczy rekord bazy danych i zdefiniować funkcje do ich przetwarzania.
niedogodności Modele obiektowe charakteryzują się dużą złożonością koncepcyjną, niewygodą przetwarzania danych i niską szybkością wykonywania zapytań.
DBMS zorientowane obiektowo obejmują POET, Jasmine, Versant, O2, ODB-Jupiter, Iris, Orion, Postgres.
04.06.2004 Siha Bagi
Rozwój obiektowych systemów bazodanowych rozpoczął się w połowie lat 80-tych ze względu na potrzebę spełnienia wymagań aplikacji innych niż obsługiwane i obsługiwane przez relacyjne systemy bazodanowe. Przyjrzyjmy się postępom w technologii baz danych zorientowanych obiektowo oraz wyzwaniom, z którymi społeczność programistów musi jeszcze pokonać, aby technologia baz danych zorientowanych obiektowo stała się tak popularna, jak technologia relacyjnych baz danych.
Rozwój obiektowych systemów bazodanowych (tzw. technologii bazodanowych piątej generacji) rozpoczął się w połowie lat 80-tych w związku z potrzebą spełnienia wymagań aplikacji innych niż aplikacje przetwarzania danych charakterystyczne dla relacyjnych systemów bazodanowych (czwarta technologii baz danych generacji). Próby wykorzystania technologii relacyjnych baz danych w złożonych aplikacjach, takich jak projektowanie wspomagane komputerowo (CAD); produkcja zautomatyzowana (wytwarzanie wspomagane komputerowo, CAM); technologia programowania; systemy oparte na wiedzy i systemy multimedialne obnażyły ograniczenia systemów relacyjne bazy danych (RDB). Wraz z pojawieniem się nowej generacji aplikacji bazodanowych pojawiły się potrzeby, które najlepiej spełniało użycie bazy danych obiektowych (OODB).
Zaproponowano wiele definicji obiektowej orientacji i obiektowych baz danych, ale zdefiniujemy obiektowe bazy danych jako bazy danych, które łączą orientację obiektową z możliwościami bazy danych. Orientacja obiektu umożliwia bardziej bezpośrednie reprezentowanie i modelowanie rzeczywistych problemów oraz funkcjonalność bazy danych wymagane do zapewnienia stabilności danych i jednoczesnego dostępu wielu użytkowników do informacji o aplikacji.
Obecnie na rynku dostępnych jest ponad 25 systemów OODB. Wśród nich jest system GemStone firmy Servio, ONTOS firmy Ontos, ObjectStore firmy Object Design i wiele innych. Ponadto systemy zarządzania relacyjnymi bazami danych opracowane przez Oracle, Microsoft, Borland, Informix zawierały narzędzia obiektowe. Wiele z tych produktów pojawiło się w drugiej połowie lat 80., a dziś, po prawie półtorej dekadzie rozwoju, wciąż nie weszły w okres dojrzałości; jest to jeden z powodów, dla których do dziś światowy rynek rzeczywistych aplikacji nie spieszy się z przyjmowaniem systemów OODB. Wśród nowoczesnych OODB prawie nie ma pełnoprawnych systemów porównywalnych z nowoczesnymi relacyjnymi systemami baz danych. Omówmy główne osiągnięcia i problemy związane z obecnym stanem OODB.
Model OOBD
Powodem pojawienia się obiektowych systemów bazodanowych była potrzeba bardziej adekwatnej reprezentacji i modelowania encji świata rzeczywistego, ponieważ OODB zapewniają znacznie bardziej zaawansowany model danych niż tradycyjne relacyjne bazy danych. Paradygmat OODB opiera się na kilku podstawowe koncepcje, takich jak obiekt, identyfikowalność, klasa, dziedziczenie, przeciążanie i leniwe wiązanie.
W zorientowanym obiektowo modelu danych każda jednostka świata rzeczywistego jest reprezentowana przez tylko jedną koncepcję - obiekt. Obiekt ma skojarzony stan i zachowanie. Stan obiektu określają wartości jego właściwości - atrybuty. Wartości właściwości mogą być wartościami pierwotnymi (takimi jak ciągi lub liczby całkowite) oraz obiektami nieprymitywnymi. Z kolei obiekt nieprymitywny składa się ze zbioru właściwości. W związku z tym obiekty mogą być rekurencyjnie definiowane w kategoriach innych obiektów. Zachowanie obiektu definiuje się za pomocą metody, które operują na stanie obiektu.
Każdy obiekt ma zdefiniowany przez system unikalny identyfikator. Obiekty, które mają te same właściwości i zachowanie są pogrupowane w zajęcia. Obiekt może być instancją tylko jednej klasy lub wielu klas.
Klasy są zorganizowane w hierarchię klas. Podklasa dziedziczy właściwości i metody nadklasy; ponadto podklasy mogą mieć indywidualne właściwości i metody. W niektórych systemach, takich jak ORION , klasa może mieć więcej niż jedną superklasę (wielokrotne dziedziczenie), podczas gdy w innych systemach liczba nadklas jest ograniczona do jednej (pojedyncze dziedziczenie).
Większość modeli pozwala przeciążać odziedziczone właściwości i metody. Przeciążanie polega na zastąpieniu domeny właściwości nową domeną lub zastąpieniu jednej implementacji metody inną implementacją.
Zalety modelu OODB
Bazy danych zorientowane obiektowo umożliwiają bardziej bezpośrednią reprezentację złożonych obiektów niż systemy relacyjne. Zastanówmy się nad niektórymi osiągnięciami w dziedzinie OODB. Systemy OODB pozwalają użytkownikom definiować abstrakcje; ułatwić projektowanie niektórych linków; wyeliminować potrzebę kluczy zdefiniowanych przez użytkownika; obsługuje nowy zestaw predykatów porównania; w niektórych przypadkach eliminuj potrzebę połączeń; w niektórych sytuacjach zapewniają wyższą wydajność niż systemy oparte na modelu relacyjnym; zapewniają wsparcie dla wersji i długotrwałych transakcji. Wreszcie opracowano algebrę obiektów - choć być może jeszcze nie tak szczegółowo, jak algebra relacyjna.
Definiowanie własnych abstrakcji
Bazy danych zorientowane obiektowo dają możliwość definiowania nowych abstrakcji i kontrolowania implementacji takich abstrakcji. Te nowe abstrakcje mogą odpowiadać strukturom danych wymaganym w złożonych zadaniach, nowym abstrakcyjnym typom danych. Innymi słowy, nowoczesne pakiety OODB pozwalają użytkownikowi stworzyć nową klasę z atrybutami i metodami, posiadać klasy dziedziczące atrybuty i metody z nadklas, tworzyć instancje klasy, z których każda ma unikalny identyfikator obiektu, pobierać te instancje po kolei jeden lub w grupach, a także ładować i wykonywać metody. Ponadto OODB umożliwiają definiowanie obiektów jako kolekcji innych obiektów, a w przypadku kolekcji dozwolonych jest kilka poziomów zagnieżdżania. Właściwości mogą również mieć złożoną strukturę i być definiowane za pomocą konstruktora kolekcji. Ponadto mogą mieć jako wartości obiekty nieprymitywne, co umożliwia tworzenie głęboko zagnieżdżonych struktur obiektów.
Właściwości wielowartościowe są używane w obiektowych modelach danych do wyrażania złożonych struktur danych. W modelu relacyjnym osiąga się to za pomocą dodatkowe relacje i połączenia.
Przykładem pakietu OODB, który posiada wszystkie wymienione funkcje, jest ENCORE. Model danych w ENCORE opiera się głównie na abstrakcji danych. ENCORE pozwala na podtypowanie (dziedziczenie), enkapsulację, złożone struktury, identyfikację obiektów i leniwe wiązanie metod. Ponadto ENCORE zapewnia możliwość wiązania obiektów za pomocą właściwości. W systemie ENCORE właściwość p łączy obiekt x ze zbiorem obiektów S bez wskazania sposobu obliczania tego połączenia. Można go obliczyć bezpośrednio określając identyfikator zestawu S (lub identyfikatory jego członków) lub mapując wartości innych właściwości, jak w złączeniu.
Lekka konstrukcja niektórych linków
Bazy danych zorientowane obiektowo obsługują funkcję odwrotnych linków do wyrażania wzajemnych odniesień między dwoma obiektami (link binarny). Taki system wymusza integralność referencyjną poprzez ustanowienie odpowiedniego łącza zwrotnego zaraz po utworzeniu łącza nadawczego. Istnieje nawet opcja automatycznego propagowania usunięć za pośrednictwem tych linków. Przykładem pakietu OODB, który zapewnia automatyczną obsługę łączy odwrotnych, jest ObjectStore.
Nie ma potrzeby używania kluczy zdefiniowanych przez użytkownika
Model OOBD opiera się na koncepcji identyfikatorów obiektów, generowanych automatycznie przez system i gwarantujących, że są one unikalne dla każdego obiektu. To, w połączeniu z faktem, że model OODB eliminuje potrzebę stosowania kluczy zdefiniowanych przez użytkownika, zapewnia zorientowane obiektowo bazy danych o innych zaletach. Po pierwsze, identyfikator obiektu nie może być modyfikowany przez aplikację. Po drugie, pojęcie identyfikowalności obiektu pociąga za sobą odrębne i spójne pojęcie tożsamości, niezależne od tego, w jaki sposób obiekt jest dostępny lub jak obiekt jest modelowany przez dane opisowe. Dlatego dwa obiekty nie są identyczne, jeśli mają różne identyfikatory obiektów; w tym przypadku obiekty mogą mieć te same struktury, a wszystkie ich właściwości mogą mieć te same wartości. W modelu RDB, w którym obiekty są identyfikowane za pomocą kluczy zdefiniowanych przez użytkownika, takie obiekty byłyby uważane za ten sam obiekt.
Obecność predykatów porównania
W RDB porównanie jest zawsze oparte tylko na wartościach. W tym modelu dwie krotki są jedną jednostką, jeśli wszystkie ich kluczowe atrybuty mają tę samą wartość. Jednak w modelu OODB opracowano i zdefiniowano inne rodzaje porównań.
- Równość przedmiotów na podstawie ich tożsamości. Dwa obiekty, S1 i S2 są równe, jeśli są tym samym obiektem (tj. mają ten sam identyfikator obiektu).
- Równość obiektów na podstawie wartości. Można to określić w dwóch przejściach - (a) dwa prymitywne obiekty są równe, jeśli mają tę samą wartość; (b) dwa obiekty niepierwotne są równe, jeśli mają taką samą liczbę właściwości, a dla każdej właściwości pi obiektu S1 istnieje właściwość pj obiektu S2 o równej jej wartości.
- Równość właściwości na podstawie wartości.
- Równość właściwości na podstawie ich tożsamości.
Mniejsza potrzeba połączeń
Możliwość poruszania się po strukturach obiektów i wynikających z nich wyrażeń ścieżek pod względem atrybutów obiektów daje nam nowy sposób spojrzenia na problem złączeń w OODB. Sprzężenie relacyjne to mechanizm, który dopasowuje dwie relacje na podstawie wartości odpowiednich par atrybutów w tych relacjach. Ponieważ dwie klasy mogą mieć odpowiadające sobie pary atrybutów w OODB, nadal może istnieć potrzeba łączenia relacyjnego (lub jawnego) w tym modelu. Załóżmy na przykład, że mamy klasy Uczeń i Szkoła, a każda z tych klas ma atrybuty Imię i Wiek. Chociaż domeny atrybutów Imię i Wiek klasy Szkoła mogą nie być takie same jak domeny atrybutów Imię i Wiek klasy Uczeń, możemy chcieć skojarzyć te klasy na podstawie wartości tych atrybutów (powiedzmy , znajdź wszystkich uczniów, których wiek jest niższy niż wiek szkoły, do której uczęszcza ten uczeń).
Ale, jak już wspomniano, obsługa wyrażeń ścieżek może znacznie zmniejszyć potrzebę łączenia klas w porównaniu z sytuacją w bazach danych RDB. Zdarzają się nawet sytuacje, w których można całkowicie wyeliminować potrzebę relacyjnego sprzężenia. Na przykład, gdy domeną atrybutu klasy A jest klasa B, pobranie identyfikatorów obiektów pewnej klasy, które są przechowywane jako wartości atrybutów innej klasy, eliminuje potrzebę niejawnych łączeń obiektów.
Dlatego w bazach danych zorientowanych obiektowo niejawne sprzężenia generowane przez hierarchiczne zagnieżdżanie obiektów różnią się od sprzężeń jawnych. Te ostatnie przypominają sprzężenia relacyjne: dwa obiekty są porównywane jawnie według wartości atrybutów lub identyfikatorów obiektów. Co więcej, wszystkie jawne złączenia (oparte na porównaniu wartości lub identyfikatorów) nie mogą być wyrażone w relacyjnym języku zapytań, ponieważ w RDB każdy predykat może zawierać tylko atrybuty atomowe.
Wzrost wydajności
Nowoczesne OODB nie są w pełni rozwiniętymi systemami baz danych w porównaniu z nowoczesnymi RDB, OODB mają kilka cech, które zapewniają im przewagę wydajności.
- W OODB wartość atrybutu obiektu X, którego domeną jest inny obiekt Y, jest identyfikatorem obiektu Y. Dlatego jeśli aplikacja pobrała już obiekt X, a teraz chciałaby pobrać obiekt Y, to SZBD może pobrać obiekt Y, sprawdzając jego identyfikator. Jeśli ten identyfikator jest adresem fizycznym obiektu, obiekt można pobrać bezpośrednio; jeśli identyfikator jest adresem logicznym, obiekt znajduje odpowiedni element tablicy mieszającej (zakładając, że system utrzymuje tablicę mieszającą, która odwzorowuje identyfikator obiektu na adres fizyczny). Może to nie być takie proste w RDB, ponieważ RDB nie obsługują identyfikatorów obiektów.
- Drugą cechą OODB, która zapewnia wzrost wydajności, jest to, że w większości OODB, gdy obiekt jest ładowany do pamięci, identyfikatory obiektów przechowywane w tym obiekcie są konwertowane na wskaźniki pamięci. Ponieważ bazy danych RDB nie przechowują identyfikatorów obiektów, nie mogą przechowywać wskaźników pamięci do innych krotek. Niemożność poruszania się po obiektach zawartych w pamięci jest podstawową właściwością bazy danych RDB, a wynikającego z tego spadku wydajności nie można zrekompensować. prosty wzrost rozmiar pamięci bufora. Tak więc podczas wykonywania aplikacji, które wymagają wielokrotnej nawigacji przez powiązane obiekty załadowane do pamięci, OODB mogą znacznie przewyższyć wydajność RDB.
- Ponadto, nawet jeśli OODB nie są indeksowane, wygodnie może być wykonanie dowolnych zapytań odpowiadających strukturze obiektów poprzez skanowanie sekwencyjne, tj. użyj ścieżek odniesienia między obiektami. Gdy zapytanie jest sformułowane w kierunku nieobsługiwanym przez łącza, zostanie ono przetworzone przez skanowanie sekwencyjne. Jednak zapytania formułowane na podstawie takich relacji obiektowych, które nie są bezpośrednio modelowane za pomocą łączy, są wykonywane nieefektywnie.
Wsparcie dla wersji i długotrwałych transakcji
Biblioteki RDB nie obsługują wersjonowania ani długotrwałych transakcji. Takie wsparcie jest dostępne w niektórych OODB, aczkolwiek z ograniczonymi funkcjami.
Algebra obiektów
Algebra obiektów nie jest tak dobrze rozwinięta i nie tak dojrzała jak algebra relacyjna. Ale tak czy inaczej, taka algebra istnieje i definiuje pięć podstawowych operacji, które zachowują obiekty: sumę, różnicę, wybieranie, generowanie i mapowanie . Na podstawie tych podstawowych operacji można zdefiniować inne operacje, takie jak przecięcie. Reguły transformacji dla logicznej optymalizacji wyrażeń algebry obiektów z zachowaniem równoważności są wyprowadzone w i . Podczas gdy operacje sumowania, różnicowania i mapowania tworzą głównie mapowanie jeden do jednego, operacje zaznaczania i generowania generują mapowanie jeden do wielu. Trwałość obiektów oznacza, że operacje algebraiczne zwracają obiekty należące do wcześniej zdefiniowanych klas bazy danych i nie tworzą nowych obiektów. Operator union zwraca obiekty zawarte w zbiorze P, zbiorze Q lub obu. Operator różnicy zwraca zbiór obiektów należących do zbioru P, ale nie do zbioru Q. select zwraca podzbiór danego zbioru. generate generuje obiekty z tych, które należą do zestawu wejściowego. map zwraca zestaw obiektów powstałych w wyniku każdego zastosowania sekwencji metod.
Wady modelu OODB
Spodziewano się, że metody obiektowe pozwolą technologii baz danych na dokonanie pewnego rodzaju skoku kwantowego. Jednak pomimo powyższych osiągnięć OODB nie były w stanie wywrzeć znaczącego wpływu na stan rzeczy w tym obszarze. Zarówno model, jak i technologia OODB nadal mają słabe punkty.
Bazom danych zorientowanych obiektowo brakuje podstawowych funkcji, do których użytkownicy systemów bazodanowych są przyzwyczajeni i dlatego spodziewają się ich zobaczyć. Między innymi można zauważyć: brak interoperacyjności między RDB i OODB; minimalna optymalizacja zapytań; brak standardowej algebry zapytań; brak środków na zapewnienie wniosków; brak poparcia dla poglądów; problemy bezpieczeństwa; brak wsparcia dla dynamicznych zmian w definicjach klas; ograniczone wsparcie dla ograniczeń integralności; ograniczone opcje dostrajania wydajności; niewystarczające wsparcie dla złożonych obiektów; ograniczona integracja z istniejącymi systemami programowania obiektowego; ograniczony przyrost wydajności.
Brak interoperacyjności między RDB i OODB
Aby OODB miały znaczący wpływ na rynek baz danych, należy spełnić szereg warunków.
- Przekształć bazy danych OODB w pełnoprawne systemy baz danych o wystarczającej kompatybilności z bazami danych RDB. Konieczna jest pewna ścieżka migracji, aby zapewnić współistnienie istniejących i nowych produktów, a także płynne przejście od pierwszego do drugiego.
- Oferuj narzędzia do tworzenia aplikacji i narzędzia do uzyskiwania dostępu do obiektowych baz danych.
- Ujednolicenie architektur RDB i OODB.
- Ujednolicenie modeli danych RDB i OODB.
Niewystarczające środki na optymalizację zapytań
Jednym z najważniejszych problemów w OODB jest optymalizacja zapytań deklaratywnych. Optymalizacja zapytań OODB jest utrudniona przez dodatkową złożoność samego obiektu zorientowanego na model danych. Ta dodatkowa złożoność wynika z wielu czynników.
- Możliwość definiowania przez użytkowników nowych typów i klas poprzez dziedziczenie zarówno ułatwia, jak i utrudnia optymalizację zapytań. Przykładem, w którym ta funkcja pomaga w optymalizacji, jest zapytanie, które zawiera przecięcie zbiorów pracowników („pracownicy”) i nadzorców („inspektorów”). Jeśli pracownik jest nadklasą klasy Supervisor, optymalizator może założyć, że Supervisors jest własnym podzbiorem pracowników i uprościć procedurę przecięcia zbiorów. Przykładem, w którym dodatkowe typy danych ograniczają opcje optymalizacji, jest połączenie zestawów Uczniów i Pracowników; nadklasą dla obu klas jest klasa Person. Gdybyśmy chcieli znaleźć wszystkich przełożonych uczniów i pracowników, najpierw zrobilibyśmy unię, a następnie użylibyśmy superwizora() .
- Zapytania mogą być oparte na operacjach na kolekcjach, ale optymalizacje obejmujące zestawy (lub multizestawy, listy itp.) muszą być połączone z optymalizacjami typów obiektów zawartych w tych zestawach. Optymalizator zapytań zorientowany obiektowo musi być w stanie zastosować procedury optymalizacji, które są specyficzne dla danych typów, a także procedury optymalizacji, które uwzględniają relacje między obiektami różnych typów.
- Złożoność przetwarzania zapytań w OODB jest spotęgowana przez obecność złożonych obiektów, metod i enkapsulacji. Obiekty złożone generują wyrażenia ścieżek, które komplikują przetwarzanie zapytań. Tworzenie indeksów dla wyrażeń ścieżek, zwłaszcza gdy w wyrażeniach występują dowolne metody, komplikuje przetwarzanie zapytań. Problem komplikuje się jeszcze bardziej, jeśli metody mają skutki uboczne. Innym problemem związanym z wyrażeniami ścieżki jest to, że narzucają kolejność wywoływania metod wyrażeń ścieżki, a ta kolejność może być dość nieefektywna. Na przykład wyrażenie ścieżki Orders.part.name najlepiej oceniać od prawej do lewej, jeśli istnieje wiele zamówień (Orders) i niewiele części (Parts), ale jeśli istnieje wiele części i niewiele zamówień, wyrażenie najlepiej oceniać od lewej w prawo. Ponadto czasami wyrażenia ścieżki są bardziej wydajnie przetwarzane przy użyciu opcji Join. Rozważmy na przykład zapytanie z wyrażeniem ścieżki s.comp.name, gdzie s należy do zestawu Students. Bardziej wydajne może być (jeśli liczba firm, komp, jest mała), aby najpierw obliczyć nazwę (Nazwa) dla każdej firmy (Firma) i zapisać wynik w krotce. Następnie ocena wyrażenia od ucznia do nazwy firmy wymagałaby połączenia zestawu uczniów z zestawem krotek przez dopasowanie właściwości comp klasy ucznia z wartością atrybutu Firma pewnej krotki.
- Języki zapytań OODB wspierają wykorzystanie struktur zagnieżdżonych, co ponownie może znacząco skomplikować proces optymalizacji, ponieważ odwracają go od lokalny problem w problem globalny, ponieważ wymagana jest globalna znajomość całego wyrażenia zapytania.
- Kiedy przedmioty są identyfikowalne, pojawia się pytanie, co oznacza równość dwóch przedmiotów. To pytanie przenosi się do języka, w którym porównania równości są używane w predykatach i gdzie należy podjąć decyzję o utworzeniu nowych obiektów podczas wykonywania zapytania. Optymalizator modelu zorientowanego obiektowo powinien być w stanie poradzić sobie z tworzeniem nowych obiektów i alternatywnymi definicjami równości.
Problemy te wskazują, że optymalizacja zapytań obiektowych jest niezwykle trudnym zadaniem, a obszar ten jest wciąż badany. Dzisiejsze zorientowane obiektowo systemy baz danych oferują dość proste strategie optymalizacji. Bliższej uwagi wymaga również problem optymalizacji połączeń.
Brak standardowej algebry zapytań
Inną poważną wadą OODB jest brak standardów algebry zapytań. Ta okoliczność również komplikuje optymalizację zapytań. Dla OODB zaproponowano kilka różnych formalnych języków zapytań opartych na algebrze i rachunku różniczkowym. Te algebry i rachunki różnią się pod kilkoma względami, zarówno pod względem wyrazistości, jak i wspomagania optymalizacji reguł przepisywania. Prawie wszystkie te algebry są oparte na zmiennych, tj. użyj zmiennych do przechowywania wyników pośrednich. KOLA, jedno z pakietów OOBD, to produkt czysto funkcjonalny; zmienne nie są w nim używane. Autor twierdzi, że to właśnie z powodu braku zmiennych algebra KOLA umożliwia budowanie potężniejszych systemów reguł.
W bazach danych RDB istnieje ścisły związek między operacjami algebraicznymi a prymitywami niskiego poziomu systemu fizycznego. Ta silna korespondencja jest osiągana dzięki mapowaniu między relacjami i plikami oraz między krotkami i rekordami. Jednak w OODB nie ma podobnej intuicyjnej zgodności między operacjami algebry obiektów a prymitywami systemów fizycznych. W każdej dyskusji na temat generowania planu wykonania konieczne jest również zdefiniowanie w pierwszej kolejności prymitywów manipulacji obiektami niskiego poziomu.
Brak obsługi zapytań
Większość OODB nie obsługuje zapytań. W nielicznych systemach, w których istnieje wystarczająca ilość odpowiednich narzędzi, język zapytań nie jest zgodny z ANSI SQL. Wśród tych narzędzi zapytań nie ma zagnieżdżonych podzapytań, zapytań ze zbiorami (suma, przecięcie, różnica), funkcji agregujących i GROUP BY, łączących kilka klas - cechy, które są w pełni obsługiwane w RDB.
Nie ma również standardu dla zapytań obiektowych, choć trzeba powiedzieć, że podjęto próby opracowania języka obiektowego SQL. SQL3 jest prawdopodobnie opóźniony o kilka lat.
Brak widoku wsparcia
Widoki nie są obsługiwane w OODB. Chociaż na ten temat pojawiło się kilka propozycji, nie osiągnięto konsensusu co do tego, jak powinien funkcjonować silnik widoku w OODB. Rozwój mechanizmu reprezentacji obiektowej komplikują takie właściwości modelu, jak identyfikowalność obiektów. Jaki jest identyfikator obiektu w widoku? Z drugiej strony istnieje pogląd, zgodnie z którym możliwość enkapsulacji i dziedziczenia danych pozwala obejść się bez jednoznacznych definicji poglądów.
Problemy bezpieczeństwa
Autoryzacja jest obsługiwana w RDB, podczas gdy większość OODB nie. Bazy danych RDB umożliwiają użytkownikom przenoszenie i odwoływanie praw do czytania lub modyfikowania definicji i krotek w relacjach i widokach. OODB będą mogły stać się bardziej rozpowszechnione w biznesie tylko wtedy, gdy ta funkcja zostanie w nich ulepszona.
W niektórych systemach OODB użytkownicy muszą jawnie nabyć i zwolnić blokady. Systemy RDB automatycznie ustawiają i zwalniają blokady podczas przetwarzania żądań użytkowników i instrukcji aktualizacji.
Brak wsparcia dla dynamicznych zmian definicji klas
Oprócz tego, że nie opracowano jeszcze jednego standardowego modelu danych dla OODB, większość OODB nie pozwala na dynamiczne zmiany w schemacie bazy danych, takie jak dodanie nowego atrybutu lub metody do klasy, dodanie nowej nadklasy do klasy , usunięcie nadklasy klasy, dodanie nowej klasy i usunięcie klasy. RDB umożliwiają użytkownikowi dynamiczną zmianę schematu bazy danych za pomocą polecenia ALTER; można dodać nową kolumnę do relacji, relację usunąć, a w niektórych przypadkach możliwe jest usunięcie kolumny z relacji.
W większości OODB brakuje również automatycznego zarządzania rozszerzeniami klas. Jeśli wymagane jest rozszerzenie klasy, użytkownik musi zdefiniować dla niego kolekcję i upewnić się, że wszystkie wstawienia i usunięcia będą rejestrowane w odpowiednim czasie.
Ograniczona obsługa ograniczeń integralności
Nie ma mechanizmów deklarowania kluczowych właściwości atrybutów (na przykład atrybut klasy nie może być zadeklarowany jako klucz podstawowy klasy) lub ograniczeń unikatowości, jawnych ograniczeń integralności oraz warunków wstępnych i końcowych metody. Chociaż wszystko to można zrobić za pomocą metod, wyraźne ograniczenia byłyby bardziej przyjazne dla użytkownika, generowałyby mniej błędów i byłyby bardziej weryfikowalne i modyfikowalne.
Ograniczone opcje dostrajania wydajności
Większość OODB zapewnia tylko ograniczone opcje parametryzowanego dostrajania wydajności. W RDB instalatorzy mają możliwość dostrojenia wydajności systemu poprzez ustawienie dużej liczby parametrów, które są ustawiane przez Administrator systemu. Parametry te obejmują liczbę buforów pamięci, ilość wolnego miejsca zarezerwowanego na stronie danych na przyszłe wstawianie danych i tak dalej. .
Niewystarczające wsparcie dla złożonych obiektów
Pełna funkcjonalność złożonych obiektów nadal nie jest obsługiwana. Możesz poruszać się po linkach i operacjach kodu za pomocą tych linków, ale nie ma predefiniowanych ogólnych operacji, które używają Różne rodzaje semantyka łącza. Uważa się, że wszystkie łącza wskazują na niezależne obiekty, a semantyka specjalnych łączy w złożonych obiektach jest ukryta w operacjach wprowadzonych przez użytkownika.
Ograniczona integracja z systemami programowania obiektowego
Trudno jest przepisać programy obiektowe do zarządzania stabilnymi danymi. Pojawia się tu szereg problemów: konflikty nazw; potrzeba przeprojektowania hierarchii klas; Tendencja OODB do przeciążania operacji systemowych.
Ograniczony wzrost wydajności
Gdyby wszystkie aplikacje bazodanowe musiały tylko wyszukiwać obiekty bazy danych za pomocą identyfikatorów obiektów i szybko pracować z obiektami w pamięci głównej za pomocą wskaźników, to OODB rzeczywiście przewyższałyby RDB o dwa do trzech rzędów wielkości. Jednak większość aplikacji, które muszą uzyskiwać dostęp do obiektów za pomocą identyfikatorów, wymaga również dostępu do bazy danych i możliwości aktualizacji zapewnianych przez RDB. Funkcje te obejmują masowe ładowanie bazy danych; tworzenie, aktualizowanie i usuwanie pojedynczych obiektów (pojedynczo); wyodrębnienie z klasy jednego lub więcej obiektów spełniających określone warunki wyszukiwania; połączenie kilku klas; dokonywanie transakcji itp. Podczas uruchamiania takich aplikacji OODB nie mają przewagi wydajności nad RDB.
Funkcje, które nie są jeszcze obsługiwane w OODB, obejmują wyzwalacze, kontrolki metadanych i ograniczenia integralności, takie jak UNIQUE i NULL .
***
Z powodu tych słabości OODB nie były w stanie sprostać ich oczekiwaniom: zapewnić wszystkie ważne funkcje pożądane przez docelowe aplikacje. W stosunku do większości nowoczesnych systemów termin „OODB” jest używany niepoprawnie. Prawie wszystkie nowoczesne OODB to nie tyle systemy bazodanowe, co stabilne systemy przechowywania danych dla jakiegoś zorientowanego obiektowo języka programowania. Tak więc, chociaż model danych obiektowych jest pod wieloma względami bogatszy niż relacyjny model danych, model obiektowy nie jest jeszcze w pełni dojrzały. Do tej pory w systemach OODB jest wyraźnie więcej wad niż zalet.
Literatura
- S. Abiteboul, A. Bonner, „Przedmioty i widoki”. ACM SIGMOD Int. Konf. O zarządzaniu danymi, 1991.
- M. Atkinson i in., „Manifest systemu baz danych zorientowanych obiektowo”. Budowanie zorientowanego obiektowo systemu baz danych: historia O2. Morgan Kaufman, 1992.
- F. Bancilhon, „Systemy baz danych zorientowane obiektowo”. VII Konferencja ACM SIGART/SIGMOD, 1988.
- J. Banerjee i in., „Problemy z modelem danych dla aplikacji zorientowanych obiektowo”. ACM Trans. O systemach informatycznych biurowych, styczeń 1987 r.
- J. Banerjee, W. Kim, K.C. Kim, "Zapytania w obiektowych bazach danych". Konferencja Inżynierii Danych IEEE, luty 1988.
- D. Beech, Podstawy ewolucji i relacyjne z obiektowymi bazami danych. Proc. Technologia rozszerzonej bazy danych, marzec. 1988.
- E. Bertino, M. Negri, G. Pelagatti, L. Sbattella, "Języki zapytań zorientowane obiektowo: pojęcie i problemy". IEEE Transactions on Knowledge and Data Engineering, Mar. 1992.
- A.W. Brown, obiektowe bazy danych, zastosowania w inżynierii oprogramowania. Nowy Jork: McGraw-Hill, 1991.
- R.G.G. Cattell, zarządzanie danymi obiektowymi, systemy zorientowane obiektowo i rozszerzone relacyjne bazy danych. Addison-Wesley, 1991.
- M. Cherniack, „Form(y) nad funkcją(ami): Kola Query Algebra”. Raport techniczny, Brown University, grudzień. 1995.
- S. Cluet i in., „Reloop, język zapytań oparty na algebrze dla zorientowanego obiektowo systemu baz danych”. 1 miedzynarodowy Konf. O dedukcyjnych i obiektowych bazach danych, grudzień 1989.
- JEŚLI. Cruz, DOODLE: Język wizualny dla baz danych zorientowanych obiektowo. ACM SIGMOD Int. Konf. O zarządzaniu danymi, 1992.
- U. Dayal, „Zapytania i widoki w obiektowym modelu danych”. 2-gi Międzyn. praca. O językach programowania baz danych, czerwiec 1989.
- K.A. Dittrich, KR Dittrich, „Gdzie DBMS zorientowane obiektowo powinny działać lepiej: krytyka oparta na wczesnych doświadczeniach”. Nowoczesne systemy baz danych: model obiektowy, interoperacyjność i nie tylko, ACM Press, Addison Wesley, 1995.
- U. Erlingsson, „Optymalizacja kwerend opartych na obiektach”, niepublikowany rękopis.
- L. Fegaras, D. Maier, „W kierunku efektywnego rachunku różniczkowego dla języków zapytań obiektowych”. ACM SIGMOD Int. Konf. w sprawie zarządzania danymi, San Jose, Kalifornia, maj 1995.
- L. Fegaras, D. Maier, T. Sheard, „Określanie optymalizatorów zapytań opartych na regułach w strukturze refleksyjnej”. 3rd Międzyn. Konf. w sprawie dedukcyjnych i obiektowych baz danych, Phoenix, Arizona, grudzień 1993.
- S. Heiler, S. Zdonik, „Widoki na obiekt: Rozszerzanie wizji”. 6. Międzyn. Konf. O inżynierii danych, 1990.
- J.G. Hughes, Bazy danych zorientowanych obiektowo. Nowy Jork: Prentice-Hall, 1991.
- S. Khoshafian, „Wgląd w zorientowane obiektowo bazy danych”. Technologia informacyjna i programistyczna, kwiecień 1990.
- S. Khoshafian, Object-Oriented Databases, New York: John Wiley & Sons, 1993.
- S. Khoshafian, G. Copeland, „Tożsamość obiektu”. 1 miedzynarodowy Konf. O systemach programowania obiektowego, językach i aplikacjach, październik. 1986.
- W. Kim, Fundacja dla obiektowych baz danych. MCK Tech. Rep., N. ACA-ST-248-88, sierpień. 1988.
- W. Kim, Wprowadzenie do baz danych obiektowych. MIT Press, 1991.
- W. Kim, „Systemy baz danych zorientowane obiektowo: obietnice, rzeczywistość i przyszłość”. Nowoczesne systemy baz danych: model obiektowy, interoperacyjność i nie tylko, ACM Press, Addison Wesley, 1995.
- T.W. Leung i in., Aqua Data Model i Algebra. Raport techniczny CS-93-09, Uniwersytet Browna, marzec. 1993.
- G. Mitchell, S.B. Zdonik, U. Dayal, "Optymalizacja zapytań zorientowanych obiektowo - na czym polega problem?" Raport techniczny CS-91-41, Brown University, czerwiec 1991.
- EA Rudensteiner, „Multiview: Metodologia obsługi wielu widoków w obiektowych bazach danych”. 18. Międzyn. Konf. O bardzo dużych bazach danych, 1992.
- M. Scholl, H. Schek, "Relacyjny model obiektu". 3rd Międzyn. Konf. O teorii baz danych, LNCS, tom. 470, Springer Verlag, 1990.
- P.G. Selinger i inni, „Wybór ścieżki dostępu w systemie zarządzania relacyjnymi bazami danych”. ACM SIGMOD Int. Konf. O zarządzaniu danymi, 1979.
- M. Stefik, DG Bobrow, „Programowanie obiektowe: tematy i wariacje”. Mag. AI, sty. 1986.
- M. Stonebraker i in., „Manifest systemu baz danych trzeciej generacji”. Komitet ds. Zaawansowanych Funkcji DBMS, Uniwersytet Kalifornijski, Berkeley, 1990.
- D.D. Straube, M.T. Ozsu, „Zapytania i przetwarzanie zapytań w obiektowych systemach baz danych”. Transakcje ACM w systemach informatycznych, październik 1990.
- D.D. Straube, M.T. Ozsu, „Generowanie planu wykonania dla zorientowanego obiektowo modelu danych”. 2-gi Międzyn. Konf. w sprawie dedukcyjnych i obiektowych baz danych, Monachium, Niemcy, grudzień 1991.
- S.Y.W. Su, M. Guo, H. Lam, „Algebra asocjacji: podstawa matematyczna baz danych zorientowanych obiektowo”. IEEE Transactions on Knowledge and Data Engineering, październik. 1993.
- S.B. Zdonik, D. Maier, eds., Odczyty w obiektowych systemach baz danych, Morgan Kauffman, 1989.
- S.B. Zdonik, P. Wegner, „Język i metodologia dla obiektowych środowisk baz danych”. Hawaje Int. Konf. na Naukach Systemowych, Jan. 1986.
Siha Bagi([e-mail chroniony]) jest wykładowcą na Wydziale Informatyki Uniwersytetu Zachodniej Florydy. Współautor trzech książek o bazach danych: Learning SQL: A Step-by-Step Guide Using Oracle, Learning SQL: A Step-by-Step Guide Using Access (Addison Wesley) oraz Database Design Using Entity Relationship Diagrams (CRC Press).
Tłumaczenie z „Achievements and Weakness of Object-Oriented Databases” Sikha Bagi w Journal of Object Technology (JOT), t. 2, nie. 4, lipiec-sierpień 2003, strony 29-41. Przetłumaczone na język rosyjski dla Otkrytye Systemy za specjalnym zezwoleniem pierwotnego wydawcy. Prawa autorskie JOT, 2003. http://www.jot.fm/issues/issue_2003_07/column2.
Z edytora tłumaczeń
OOBD - zapadalność czy spadek?
Siergiej Kuzniecow
W ciągu ostatnich kilku lat nastąpił znaczący zastój w dziedzinie baz danych zorientowanych obiektowo, który niektórzy postrzegają jako upadek technologii, a inni jako przejście do dojrzałego i stabilnego stanu technologii. Z moich obserwacji taki zastój czasami prowadzi do nieporozumień, a nawet mitów wśród osób, które są blisko IT, ale nie są ekspertami w dziedzinie baz danych. Jednym z tych błędnych przekonań jest to, że dana osoba przyjmuje zestaw terminów, który rozwinął się w jej głowie (obiekt, atrybut, metoda, klasa, dziedziczenie itp.) jako ogólnie uznany model danych zorientowanych obiektowo.
To wyjaśnia naszą decyzję o opublikowaniu tłumaczenia dość zwyczajnego artykułu Siha Bagi. Taka publikacja jest uzasadniona choćby tym, że przerywa tę ciszę i pokazuje przede wszystkim, że obszar OODB nie tylko nie wszedł w okres dojrzałości, ale nadal jest konglomeratem niejednorodnych i pogmatwanych idei, które są bardziej zjednoczone. na poziomie haseł, a nie technologii.
Artykuł oparty jest na analizie 36 publikacji poświęconych obiektowym bazom danych i opublikowanych w latach 1986-1995. Dlatego często stosowana charakterystyka „nowoczesnych” OODB nie jest całkowicie sprawiedliwa. Cytaty, czasami podawane w czasie teraźniejszym, czasami wyglądają dość podejrzanie.
Oczywiście w wielu źródłach stosowano inną terminologię i pod tym względem ich recenzja jest wyjątkowo różnorodna. Ponadto wiele artykułów jest skomplikowanych technicznie, a cytowanie ich bez podania kontekstu tylko utrudnia zrozumienie. Najbardziej uderzającym przykładem jest podrozdział dotyczący rozwoju algebry obiektów. Pierwsze trzy „podstawowe” operacje – suma, różnica, wybór – są intuicyjne (choć w rzeczywistości autorzy oryginalnego artykułu dopuszczają mało oczywisty wariant wyboru w postaci sprzężenia częściowego), ale dwie ostatnie – generują i mapa - są trudnymi do zdefiniowania i nieoczywistymi operacjami.
Chciałbym zwrócić uwagę na jeszcze jedną dziwną cechę artykułu Bagui. Przed 2001 r. istniało międzynarodowe konsorcjum Object Data Management Group, które opublikowało trzy wersje propozycji standaryzacji zorientowanego obiektowo modelu danych; Ostatnia wersja- ODMG 3.0 został opublikowany w 2000 roku. to jedyny dokument, który proponuje stosunkowo spójną terminologię i do pewnego stopnia obiektowy model danych. Szkoda, że Bagi nie używa tego materiału.
Należy zauważyć, że magazyn DBMS opublikował artykuł na temat pierwszej wersji standardu ODMG-93. Krótki przegląd standardu ODMG 3.0 można znaleźć w . Możesz również polecić tłumaczenie Manifestu Obiektowych Systemów Baz Danych oraz bardzo fajny przegląd technologii OODB.
Literatura
- Standard danych obiektowych: ODMG 3.0. R.G.G. Cattel, Dania Barry, red., Morgan Kauffmann, 2000.
- LA. Kaliniczenko, . // DBMS, nr 1, 1996.
- SD Kuzniecow. „Trzy Manifesty bazy danych: retrospektywa i perspektywa”. Relacja z konferencji „Bazy danych i technologie informacyjne XXI wieku”, Moskwa, wrzesień 2003, http://www.citforum.ru/database/articles/manifests.
- M. Atkinson i in., // DBMS, nr 4, 1995.
- Ark Andreev, Dmitrij Berezkin, Roman Samarev. // systemy otwarte, № 3, 2001.
Bazy danych obiektowych: osiągnięcia i wyzwania
Przy dużej liczbie projektów eksperymentalnych (a nawet systemów komercyjnych) nie ma ogólnie akceptowanego, obiektowego modelu danych i to nie dlatego, że nie opracowano jednego kompletnego modelu, ale dlatego, że nie ma ogólnej zgody co do przyjęcia jakiegokolwiek modelu. W rzeczywistości istnieją bardziej szczegółowe kwestie związane z projektowaniem deklaratywnych języków zapytań, wykonywaniem i optymalizacją zapytań, formułowaniem i utrzymywaniem ograniczeń integralności, synchronizacją dostępu i zarządzaniem transakcjami i tak dalej.
Model obiektowy (rys. 3) umożliwia tworzenie, przechowywanie i wykorzystywanie informacji w postaci obiektów. Każdy obiekt po jego utworzeniu otrzymuje unikalny identyfikator generowany przez system, który jest powiązany z obiektem przez cały okres jego istnienia i nie zmienia się wraz ze zmianą stanu obiektu.
Rys.3. Obiektowo zorientowany model danych
Każdy obiekt ma swój stan i zachowanie. Stan obiektu to zbiór wartości jego atrybutów. Zachowanie obiektu to zestaw metod (kod programu), które operują na stanie obiektu. Wartością atrybutu obiektu jest również jakiś obiekt lub zbiór obiektów. Stan i zachowanie obiektu są zawarte w obiekcie; interakcja obiektów opiera się na przekazywaniu wiadomości i wykonywaniu odpowiednich metod.
Zbiór obiektów z tym samym zestawem atrybutów i metod tworzy klasę obiektów. Obiekt musi należeć tylko do jednej klasy (jeśli nie bierze się pod uwagę możliwości dziedziczenia). Dozwolone są prymitywne klasy predefiniowane, których obiekty instancji nie posiadają atrybutów: liczb całkowitych, łańcuchów itp. Klasa, której obiekty mogą służyć jako wartości atrybutu obiektów innej klasy, nazywana jest domeną tego atrybutu.
Dozwolone jest generowanie nowej klasy na podstawie klasy już istniejącej - dziedziczenie. W tym przypadku nowa klasa, zwana podklasą istniejącej klasy (superklasa), dziedziczy wszystkie atrybuty i metody nadklasy. Ponadto w podklasie można zdefiniować dodatkowe atrybuty i metody. Zdarzają się przypadki prostego i wielokrotnego dziedziczenia. W pierwszym przypadku podklasę można zdefiniować tylko na podstawie jednej nadklasy, w drugim przypadku nadklas może być kilka. Jeśli język lub system obsługuje dziedziczenie pojedynczych klas, zestaw klas tworzy hierarchię drzewa. Podczas obsługi dziedziczenia wielokrotnego klasy są połączone w grafie skierowanym z korzeniem, zwanym kratą klas. Obiekt podklasy uważany jest za należący do dowolnej nadklasy tej klasy.
Bazy danych obiektowych są najczęściej wykorzystywane w obszarach takich jak komputerowe wspomaganie projektowania/wytwarzania (CAD/CAM), komputerowe systemy wspomagania rozwoju oprogramowanie(CASE), złożone systemy zarządzania dokumentami, tj. w obszarach nie tradycyjnych dla baz danych. Przykładami DBMS zorientowanych obiektowo są - POET, Jasmine, Versant, Iris, Orion.
2.2.4 Relacyjny model danych
W 1970 roku amerykański matematyk Codd E.F. opublikował w swojej treści rewolucyjny artykuł, sugerujący wykorzystanie teorii mnogości do przetwarzania danych. Twierdził, że dane powinny być połączone zgodnie z ich logicznymi relacjami (np. sumą, przecięciem), a nie fizycznymi wskaźnikami. Zaproponował prosty model danych, w którym wszystkie dane są podsumowywane w tabelach składających się z wierszy i kolumn o unikalnych nazwach. Tabele te nazywane są relacjami (relacja - relacja), a model nazywany jest relacyjnym modelem danych zbudowanym na koncepcji relacji matematycznych, a czasami nazywany jest również modelem Codda. Propozycje Codda okazały się na tyle skuteczne dla systemów bazodanowych, że za ten model otrzymał prestiżową nagrodę Turing Award in Computing Theory.
W relacyjnych bazach danych wszystkie dane są przechowywane w proste stoły, podzielone na wiersze (nazywane są rekordami) i kolumny (nazywane są polami), na przecięciu których znajdują się informacje o danych. Ogólnie można to przedstawić jak na ryc. cztery.
Rys.4. Tabela relacyjnej bazy danych.
Każda kolumna ma swoją nazwę. Na przykład w tabeli „Towary na stanie” (ryc. 5.) nazwy pól są następujące: Identyfikator, Produkt, Nazwa grupy, Grupa, jednostka miary, Cena zakupu, Cena sprzedaży, Dostępność: W magazynie.
Ryż. 5. Tabela „Towary w magazynie »
Wszystkie wartości w jednej kolumnie są tego samego typu. Zatem pola są różnymi cechami (czasami nazywanymi atrybutami) obiektu. Wartości pól w tej samej linii odnoszą się do tego samego obiektu, a różne pola mają różne nazwy.
Każdy rekord jest wyróżniany unikalnym kluczem rekordu, który można podzielić na dwa typy: podstawowy i pomocniczy.
główny klucz to jedno lub więcej pól, które jednoznacznie identyfikują rekord. Jeśli klucz podstawowy składa się z jednego pola, nazywamy go kluczem prostym, jeśli składa się z kilku pól, nazywamy go kluczem złożonym.
klucz wtórny jest polem, którego wartość może się powtarzać w kilku rekordach pliku, czyli nie jest unikatowa.
Klucz zewnętrzny kluczem drugorzędnym tej relacji jest tabela podrzędna, która jednocześnie pełni funkcje klucza głównego w tabeli głównej. Jeśli według wartości klucza podstawowego można znaleźć jedną instancję rekordu, to według wartości klucza obcego jest ich kilka (rys. 6).
Rys.6. Przykład użycia klucza obcego
Z reguły relacyjna baza danych składa się z kilku tabel, ponieważ nie jest możliwe zebranie w jednej tabeli wszystkich informacji niezbędnych pracownikom (użytkownikom baz danych) jakiejkolwiek organizacji do rozwiązywania problemów.
Sposobem efektywnego dostępu za pomocą klucza do rekordu pliku jest indeksowanie. Indeksowanie tworzy dodatkowy plik, który zawiera wszystkie kluczowe wartości pliku danych w kolejności. Dla każdego klucza plik indeksu zawiera wskaźnik do odpowiedniego wpisu w pliku danych. Wskaźnik do wpisu w pliku danych zapewnia bezpośredni dostęp do tego wpisu.
Do pracy z relacyjnymi bazami danych powszechnie używany jest obecnie strukturalny język zapytań (SQL). Jest to język używany do tworzenia, modyfikowania i manipulowania danymi. SQL nie jest język algorytmiczny programowanie. Jest to język informacyjno-logiczny, oparty na algebrze relacyjnej i podzielony na trzy części:
operatory definicji danych;
operatory manipulacji danymi (Insert, Select, Update, Delete);
· operatorzy definicji dostępu do danych.
W 1986 r. SQL został przyjęty jako standard ANSI (American National Standards Institute) dla języków relacyjnych baz danych. Dziś dana podstawa uznawane za standard nowoczesnych systemów informatycznych.
Tabela jest więc głównym typem struktury danych modelu relacyjnego. Strukturę tabeli definiuje zestaw kolumn. Każdy wiersz tabeli zawiera jedną wartość w odpowiedniej kolumnie. Tabela nie może mieć dwóch identycznych wierszy, łączna liczba wierszy nie jest ograniczona. Kolumna to element danych, każda kolumna ma nazwę. Kluczem tabeli jest jeden lub więcej atrybutów, których wartości jednoznacznie identyfikują wiersz tabeli.
Zaletami modelu relacyjnego są:
Prostota i przystępność zrozumienia przez użytkownika końcowego - jedyną konstrukcją informacyjną jest tabela;
Projektując relacyjną bazę danych, stosuje się ścisłe reguły oparte na aparacie matematycznym;
Pełna niezależność danych. Przy zmianie struktury zmiany, które wymagają wprowadzenia w programy użytkowe ach, minimalna;
Aby budować zapytania i pisać programy użytkowe, nie trzeba znać konkretnej organizacji bazy danych w pamięci zewnętrznej.
Wady modelu relacyjnego to:
Stosunkowo niska prędkość dostępu i duża ilość pamięci zewnętrznej;
Trudność w zrozumieniu struktury danych ze względu na pojawienie się dużej liczby tabel w wyniku logicznego projektowania;
Nie zawsze temat można przedstawić jako zestaw tabel.
Obecnie najszerzej wykorzystywane są relacyjne bazy danych. Modele sieciowe i hierarchiczne są uważane za przestarzałe, modele obiektowe nie są jeszcze ustandaryzowane i nie są szeroko stosowane.
Opisane powyżej technologie bazodanowe oparte na MD opierają się na statycznej koncepcji przechowywania informacji, skoncentrowanej na modelowaniu danych. Jednak nowe obszary zastosowań technologii ze złożonymi, wzajemnie powiązanymi obiektami bazodanowymi, takie jak:
Projektowanie wspomagane komputerowo;
Produkcja zautomatyzowana;
Zautomatyzowany rozwój oprogramowanie;
Biurowe systemy informacyjne;
Systemy multimedialne;
Systemy geoinformacyjne;
Systemy publikowania i inne wykazały ograniczenia koncepcji statycznej w zakresie modelowania obiektów świata rzeczywistego.
W przypadku nowych typów złożonych specjalistycznych aplikacji bazodanowych, dynamiczna koncepcja przechowywania informacji jest skuteczna, umożliwiając równoległe modelowanie danych i procesów działających na tych danych. Pozwala to na uwzględnienie semantyki obszaru tematycznego, a zatem jak najbardziej adekwatne opisanie tych zastosowań. Koncepcja ta opiera się na podejściu obiektowym szeroko stosowanym w tworzeniu oprogramowania. MD, który wdraża ta koncepcja i oparty na paradygmacie zorientowanym obiektowo (OOP), nazwano modelem danych zorientowanym obiektowo (OODM).
Konstrukcja OOMD opiera się na założeniu, że przedmiotowy obszar można opisać zbiorem obiektów. Każdy obiekt jest unikalnie identyfikowalną jednostką, która zawiera atrybuty opisujące stan obiektów „rzeczywistego świata” i powiązanych z nimi działań. Bieżący stan obiektu jest opisany przez jeden lub więcej atrybutów, które mogą być proste lub złożone. Atrybut prosty może mieć typ pierwotny (na przykład liczba całkowita, łańcuch itp.) i przyjmować wartość dosłowną. Atrybut złożony może zawierać kolekcje i/lub linki. Atrybut łącza reprezentuje relację między obiektami.
Kluczową właściwością obiektu jest niepowtarzalność jego Identyfikacji. Dlatego każdy obiekt w systemie obiektowym musi mieć swój własny identyfikator.
Identyfikator obiektu (OID) to wewnętrzny sposób oznaczania poszczególnych obiektów w bazie danych. Użytkownicy pracujący z zadaniem zapytania lub wyświetlania okna dialogowego zazwyczaj nie widzą tych identyfikatorów. Są one przypisywane i używane przez sam DBMS. Semantyka identyfikatora w każdym DBMS jest inna. Może być wartością losową lub zawierać informacje potrzebne do znalezienia obiektu w pliku bazy danych, takie jak numer strony w pliku i przesunięcie obiektu od jego początku. Jest to identyfikator, który powinien być używany do organizowania odwołań do obiektu.
Wszystkie obiekty są hermetyzowane, co oznacza, że reprezentacja lub wewnętrzna struktura obiektu pozostaje ukryta przed użytkownikiem. Zamiast tego użytkownik wie tylko, że obiekt może pełnić jakąś funkcję. Na przykład dla obiektu WAREHOUSE można zastosować metody takie jak ACCEPT_ITEM, ISSUE_TOBAP itp. Zaletą enkapsulacji jest to, że umożliwia zmianę wewnętrznej reprezentacji obiektów bez przeprojektowywania aplikacji korzystających z tych obiektów. Innymi słowy, enkapsulacja oznacza niezależność danych.
Obiekt hermetyzuje dane i funkcje (metody zgodne z OOP). Metody definiują zachowanie obiektu. Mogą być używane do zmiany stanu obiektu poprzez zmianę wartości jego atrybutów lub do zapytania o wartości wybranych atrybutów. Na przykład mogą istnieć metody dodawania informacji o nowej wynajmowanej nieruchomości, aktualizowania informacji o wynagrodzeniu pracownika lub drukowania informacji o konkretnym produkcie.
Obiekty, które mają ten sam zestaw atrybutów i odpowiadają na te same komunikaty, można pogrupować w Klasa(w literaturze terminy „klasa” i „typ” są często używane zamiennie). Każda taka klasa ma swojego przedstawiciela - obiekt, którym jest element danych. Obiekty określonej klasy nazywają się kopie.
W niektórych systemach obiektowych klasa jest również obiektem i posiada własne atrybuty i metody zwane atrybuty klasy i metody klas.
Ważnymi koncepcjami OOP są: hierarchia klas i hierarchia kontenerów.
hierarchia klas implikuje możliwość, że każda klasa, nazywana w tym przypadku nadklasą, ma swoją własną podklasę. Jako przykład można przytoczyć następujący łańcuch: wszyscy programiści przedsiębiorstwa są jego pracownikami, zatem każdy programista, który w ramach OODM jest obiektem klasy PROGRAMMER, jest również pracownikiem, który z kolei , jest obiektem klasy PRACOWNICY. W ten sposób programiści byliby podklasą, a PERSONEL nadklasą. Ale programistów można również podzielić na programistów systemowych i aplikacyjnych. Dlatego PROGRAMMERS będzie nadklasą dla podklas SIS_PROGRAMMERS i APPLIC_PROGRAMMERS. Kontynuując ten łańcuch dalej, otrzymujemy hierarchię klas, w której każdy obiekt podklasy dziedziczy instancje zmiennych i metod odpowiedniej nadklasy.
Istnieje kilka rodzajów dziedziczenia - pojedyncze, wielokrotne i selektywne. Dziedziczenie pojedyncze ma miejsce wtedy, gdy podklasy dziedziczą z co najwyżej jednej nadklasy. Dziedziczenie wielokrotne - dziedziczenie z więcej niż jednej nadklasy. Dziedziczenie selektywne pozwala podklasie dziedziczyć ograniczoną liczbę właściwości z nadklasy.
Dziedziczenie instancji zmiennych nazywa się dziedziczenie strukturalne, dziedziczenie metody - dziedziczenie behawioralne, a możliwość używania tej samej metody dla różnych klas, a raczej używania różnych metod o tej samej nazwie dla różnych klas, nazywa się wielopostaciowość.
Architektura zorientowana obiektowo ma również inny rodzaj hierarchii - hierarchia kontenerów. Polega na tym, że niektóre przedmioty mogą być pojęciowo zawarte w innych. Zatem obiekt klasy DEPARTMENT musi zawierać publiczną zmienną HEAD, która jest referencją do obiektu klasy PRACOWNIK odpowiadającego kierownikowi działu, a także musi zawierać referencję do zbioru referencji do obiektów odpowiadających pracownikom pracującym w ten dział.
W niektórych systemach zorientowanych obiektowo klasa jest również obiektem i ma swoje własne atrybuty i metody. Ogólna charakterystyka Klasa jest opisana przez jej atrybuty. Metody klasy obiektów są rodzajem analogii właściwości obiektów w świecie rzeczywistym. Każdy obiekt należący do określonej klasy posiada te właściwości. Dlatego podczas tworzenia obiektu konieczne jest zadeklarowanie klasy, do której należy, aby zdefiniować jego nieodłączne właściwości.
Użytkownik i obiekt wchodzą w interakcję poprzez komunikaty. W odpowiedzi na każdą wiadomość system wykonuje odpowiednią metodę.
Wszystkie relacje w modelu obiektowym są tworzone przy użyciu atrybutów referencyjnych, które są zwykle implementowane jako OID.
Relacje w relacyjnej bazie danych są reprezentowane przez pasujące klucze podstawowe i obce. W samej bazie danych nie ma struktur służących do tworzenia asocjacji między tabelami; łącza są używane w razie potrzeby podczas łączenia tabel. W przeciwieństwie do tego, relacje są podstawą zorientowanej obiektowo bazy danych, ponieważ każdy obiekt zawiera identyfikatory obiektów, z którymi jest powiązany.
W OOMD można zaimplementować nie tylko tradycyjne linki, ale także linki z powodu dziedziczenia.
Relacja jeden do jednego (1:1) między obiektami A i B jest implementowana przez dodanie atrybutu referencyjnego obiektu B do obiektu A oraz (w celu zachowania integralności referencyjnej) atrybutu referencyjnego obiektu A do obiektu B.
Związek jeden-do-wielu (1:M) między obiektami A i B jest implementowana poprzez dodanie atrybutu referencji do obiektu B do obiektu A oraz atrybutu zawierającego zestaw linków do obiektu A do obiektu B (na przykład atrybut referencji B (OID2, OID3 ...) jest dodawany do obiektu A, a instancje obiektu B z OID2, OID3, ... dodawany jest atrybut referencyjny A: OID1.
Relacja wiele do wielu (M:N) pomiędzy obiektami A i B jest zaimplementowana poprzez dodanie atrybutu zawierającego zestaw linków do każdego obiektu.
W OODM można użyć relacji „cała-część”, która opisuje, że obiekt jednej klasy zawiera jako części obiekty innych klas. W przypadku produkcyjnej bazy danych istniałaby relacja „cała część” między klasą PRODUCT a klasami PART i ASSEMBLY. Ta relacja jest odmianą relacji wiele-do-wielu, która ma specjalną semantykę. Relacja całej części jest implementowana jak każda inna relacja wiele-do-wielu, z zestawem skojarzonych identyfikatorów obiektów. Jednak w przeciwieństwie do zwykłej relacji wiele do wielu ma inne znaczenie semantyczne.
Ponieważ paradygmat obiektowy obsługuje dziedziczenie, możliwe jest użycie relacji „jest” i relacji „rozszerza” w OODM. Relacja „jest”, znana również jako relacja uogólnienie-specjalizacja, tworzy hierarchię dziedziczenia, w której podklasy są szczególnymi przypadkami nadklas. Pozwala to nie opisywać cech ponownie dziedziczonych. Używając relacji „extends”, podklasa rozszerza funkcjonalność nadklasy, a nie ogranicza się do jej szczególnego przypadku.
Zastanówmy się, jak w OOMD implementowane są takie komponenty, jak ograniczenia integralności i operacje na danych.
Cechy tych elementów zależą od specyfiki modelu. Ta specyfika w OOMD jest podyktowana przede wszystkim takimi wewnętrznymi pojęciami jak enkapsulacja obiektów, czyli tajność wewnętrznej struktury, dostęp do danych tylko poprzez z góry zdefiniowane metody, hierarchia klas i hierarchia kontenerów.
Specyfika OOMD jest również podyktowana specyfiką obiektu. Przejawia się w potrzebie grupowania obiektów w klasy. Każdy obiekt jest zaliczany do jednej lub innej klasy w zależności od zadania, a jeden obiekt może należeć do kilku klas jednocześnie (na przykład rodziny PROGRAMATORZY i WYSOKO PŁATNE). Inną specyficzną cechą obiektu jest to, że może „przebiegać” z jednej klasy (podklasy) do drugiej. W ten sposób PROGRAMATOR SYSTEMOWY może ostatecznie stać się PROGRAMATOREM STOSOWANYM. W związku z tym hierarchia klas nie jest analogiczna do modelu hierarchicznego, jak mogłoby się wydawać wcześniej, ale wymaga, aby system był w stanie zmienić położenie każdego obiektu w hierarchii klas, na przykład przesuwać się „w górę” lub „w dół” w obrębie danej hierarchii. Możliwy jest jednak również bardziej złożony proces – system musi zapewniać możliwość dołączenia (odłączenia) obiektu do dowolnego szczytu hierarchii w dowolnym momencie.
Ograniczenia integralności łącza odgrywają ważną rolę w OODM. Aby łącza w zorientowanej obiektowo DM działały, identyfikatory obiektów po obu stronach łącza muszą być zgodne. Na przykład, jeśli istnieje związek między PRACOWNIKAMI a ich DZIEĆMI, to musi istnieć jakaś gwarancja, że po wstawieniu obiektu opisującego dziecko do obiektu reprezentującego pracownika, identyfikator pracownika zostanie dodany do odpowiedniego obiektu. Ten rodzaj integralności łącza, nieco analogiczny do integralności referencyjnej w relacyjnym modelu danych, jest ustalany za pomocą informacja zwrotna. Aby zapewnić integralność łączy, projektant otrzymuje specjalną składnię potrzebną do określenia położenia odwrotnego identyfikatora obiektu. Obowiązkiem projektanta jest nałożenie ograniczeń na integralność relacji (jak również na integralność referencyjną w relacyjnej bazie danych).
W OOMD zarówno opis danych, jak i manipulacja nimi odbywa się przy użyciu tego samego, zorientowanego obiektowo języka proceduralnego.
ODMG (Object Database Management Group) zajmuje się problematyką standaryzacji technologii baz danych obiektowych. Opracowała model obiektowy (ODMG 2.0 został przyjęty we wrześniu 1997), który definiuje standardowy model semantyki obiektów bazy danych. Ten model jest ważny, ponieważ definiuje wbudowaną semantykę, którą obiektowy DBMS (OODBMS) rozumie i może zaimplementować. Struktura bibliotek i aplikacji korzystających z tej semantyki musi być przenośna między różnymi OODBMS obsługującymi dany model danych obiektowych. Głównymi składnikami architektury ODMG są: Object Model (OM), Object Definition Language (ODL), Object Query Language (OQL) oraz możliwość łączenia się z C++, Java i Smalltalk.
Obiektowy model danych zgodny ze standardem ODMG 2.0 charakteryzuje się następującymi właściwościami:
Podstawowymi elementami budulcowymi są obiekty i literały. Każdy obiekt posiada unikalny identyfikator. Literał nie ma własnego identyfikatora i nie może istnieć oddzielnie jako obiekt. Literały są zawsze osadzone w obiektach i nie można się do nich odwoływać;
Obiekty i literały różnią się typem. Każdy typ ma własną domenę współdzieloną przez wszystkie obiekty i literały tego typu. Typy mogą również mieć zachowanie. Jeśli typ ma jakieś zachowanie, to wszystkie obiekty tego typu zachowują się tak samo. W praktyce typem może być klasa, z której tworzony jest obiekt, interfejs lub prosty typ danych (np. liczba całkowita). Obiekt można traktować jako instancję typu;
Stan obiektu jest określony przez zestaw aktualnych wartości realizowanych przez zestaw właściwości. Te właściwości mogą być atrybutami obiektu lub relacjami między obiektem a jednym lub większą liczbą innych obiektów;
Zachowanie obiektu jest definiowane przez zestaw operacji, które można wykonać na obiekcie lub na samym obiekcie. Operacje mogą mieć listę parametrów wejściowych i wyjściowych, z których każdy ma ściśle określony typ. Każda operacja może również zwrócić wpisany wynik;
Definicja bazy danych jest przechowywana w schemacie napisanym w języku definicji obiektów (ODL). Baza danych przechowuje obiekty, dzięki czemu można je udostępniać różnym użytkownikom i aplikacjom.
DBMS oparte na OODM nazywane są obiektowo zorientowanymi DBMS (OODBMS). Te DBMS są określane jako DBMS trzeciej generacji* (* Historia rozwoju modeli przechowywania danych często dzieli się na trzy etapy (generacje): pierwsza generacja (koniec lat 60. - początek lat 70.) - hierarchiczna i model sieci; druga generacja (ok. 1970-1980) - model relacyjny; trzecia generacja (lata 80. - początek XXI wieku) - modele obiektowe.).
Obecnie bazy danych obiektowych są wykorzystywane w różnych organizacjach do rozwiązywania szerokiego zakresu problemów. Analiza i uogólnienie zgromadzonych doświadczeń w zakresie danych informatycznych pozwoliły zidentyfikować aplikacje, w których wykorzystanie obiektowych baz danych jest uzasadnione:
Aplikacja składa się z dużej liczby wzajemnie oddziałujących części. Każdy z nich ma swoje własne zachowanie, które zależy od zachowania innych;
System musi przetwarzać duże ilości nieustrukturyzowanej lub złożonej struktury danych;
Aplikacja będzie realizowała przewidywalny dostęp do danych, dzięki czemu nawigacyjny charakter baz danych obiektowych nie będzie istotnym minusem;
Potrzeba nieplanowanych wniosków jest ograniczona;
Struktura przechowywanych danych ma charakter hierarchiczny lub podobny.
W chwili obecnej na rynku oprogramowania istnieje wiele zorientowanych obiektowo systemów DBMS. W tabeli. 10.6 przedstawia niektóre komercyjne systemy tej klasy.
Tabela 10.6
Nowoczesne komercyjne OODBMS,
ich firmy produkcyjne i obszary zastosowań
Jedną z podstawowych różnic między bazami obiektowymi a relacyjnymi jest możliwość tworzenia i używania nowych typów danych. Ważną cechą OODBMS jest to, że tworzenie nowego typu nie wymaga modyfikacji rdzenia bazy danych i opiera się na zasadach programowania obiektowego.
Jądro OODBMS jest zoptymalizowane pod kątem operacji na obiektach. Jego naturalnymi operacjami są buforowanie obiektów, wersjonowanie obiektów i rozdzielanie praw dostępu do określonych obiektów. OODBMS charakteryzują się wyższą wydajnością na operacjach wymagających dostępu i pobierania danych spakowanych w obiekty, w porównaniu do relacyjnych DBMS, dla których konieczność pobrania powiązanych danych prowadzi do dodatkowych operacji wewnętrznych.
Duże znaczenie dla OODBMS ma możliwość przenoszenia obiektów z jednej bazy danych do drugiej.
Przy tworzeniu różnych aplikacji opartych na OODBMS ważna jest wbudowana struktura klas danego DBMS. Biblioteka klas z reguły obsługuje nie tylko wszystkie standardowe typy danych, ale także rozszerzony zestaw multimediów i innych złożonych typów danych, takich jak wideo, dźwięk, sekwencja klatek animacji. W niektórych OODBMS utworzono biblioteki klas, które umożliwiają przechowywanie i wyszukiwanie pełnotekstowe informacji dokumentacyjnych (na przykład Jasmine, ODB-Jupiter). Przykład podstawowej struktury klas pokazano na ryc. 10.17.
Główną pozycję w nim zajmuje klasa TOdbObject, która zawiera wszystkie niezbędne właściwości i metody kontroli dostępu do bazy danych oraz wykonywania indeksowania. Wszystkie inne klasy zastępują jego metody, dodając weryfikację typu, który implementują, i określonego indeksatora.
Jak widać na ryc. 10.17, w strukturze znajdują się różne klasy skoncentrowane na przetwarzaniu informacji dokumentacyjnych - TOdbText, TOdbDocument, TODBTextDocument itp. Każdy dokument jest reprezentowany przez osobny obiekt. Dzięki temu zapewniona jest naturalność przechowywania dokumentów. Jedną z najważniejszych operacji jest wyszukiwanie dokumentów na żądanie. W przypadku większości klas zaimplementowana jest możliwość wyszukiwania obiektów po wartości określonego klucza. Dla klasy TOdbText zaimplementowana jest możliwość generowania zapytania wyszukiwania na podstawie frazy napisanej w języku naturalnym.
Klasa TOdbDocument jest wyjątkowa, może zawierać obiekty różnych typów. Składa się z pól, z których każde ma nazwę i jest powiązane z obiektem określonego typu. Obecność tej klasy daje użytkownikowi możliwość rozszerzenia zestawu typów. Modyfikując obiekt kontenera (dokument), można ustawić określony zestaw pól i uzyskać nowy typ Dokument.
Na podstawie ODB-Jupiter twórcy OODBMS stworzyli w pełni funkcjonalny system wyszukiwania informacji ODB-Text, który posiada uniwersalną strukturę przechowywanych danych oraz potężny mechanizm wyszukiwania. System ODB-Text to narzędzie do zbiorowego przetwarzania dokumentów i prowadzenia archiwum firmowego. Wśród możliwych zastosowań wymienimy automatyzację księgowości obiegu dokumentów nowoczesnego urzędu, budowę systemów referencyjnych i informacyjnych (na wzór znanych prawniczych baz danych), obsługę sieciowych baz danych, ewidencji kadrowej, bibliografii, itp.
41. Cechy konstrukcyjne stosowanego IS. Fazy rozwoju SI. (Temat 11, s. 100-103).
11.1.3. Cechy konstrukcji systemu zastosowanego układu scalonego
Budując (wybierając, adaptując) System informacyjny można zastosować dwie główne koncepcje, dwa główne podejścia (trzecia koncepcja jest ich kombinacją):
1. Orientacja na problemy, które należy rozwiązać za pomocą tego systemu informacyjnego, tj. podejście zorientowane na problem (lub podejście indukcyjne);
2. skupić się na technologii, która jest dostępna (aktualizowana) w danym systemie, środowisku tj. podejście zorientowane na technologię (lub podejście dedukcyjne).
Wybór koncepcji zależy od strategicznych (taktycznych) i (lub) długoterminowych (krótkoterminowych) kryteriów, problemów, zasobów.
Jeśli najpierw zbada się możliwości istniejącej technologii, a następnie określi rzeczywiste problemy, które można rozwiązać za ich pomocą, konieczne jest poleganie na podejściu zorientowanym na technologię.
Jeżeli najpierw identyfikowane są rzeczywiste problemy, a następnie wprowadzana jest technologia wystarczająca do rozwiązania tych problemów, to należy oprzeć się na podejściu problemowym.
Jednocześnie obie koncepcje budowy systemu informacyjnego są od siebie zależne: wprowadzanie nowych technologii zmienia rozwiązywane problemy, a zmiana rozwiązywanych problemów prowadzi do konieczności wprowadzenia nowych technologii; Oba te czynniki wpływają na podejmowane decyzje.
Projekt systemu (opracowanie) i wykorzystanie dowolnego zastosowanego (korporacyjnego) systemu informacyjnego musi przejść przez następujący cykl życia systemu informacyjnego:
- analiza przedprojektowa (doświadczenie w tworzeniu innych podobnych systemów, prototypów, różnice i cechy tworzonego systemu itp.), analiza zewnętrznych przejawów systemu;
– analiza wewnątrzsystemowa, analiza wewnętrzna (analiza podsystemów systemowych);
- systemowy (morfologiczny) opis (reprezentacja) systemu (opis celu systemu, relacji i powiązań systemu z otoczeniem, innymi systemami i zasobami systemowymi - materialnymi, energetycznymi, informacyjnymi, organizacyjnymi, ludzkimi, przestrzennymi i czasowymi);
– określenie kryteriów adekwatności, wydajności i trwałości (niezawodności);
– opis funkcjonalny podsystemów systemu (opis modeli, algorytmy funkcjonowania podsystemów);
- prototypowanie (opis fikcyjny) systemu, ocena interakcji podsystemów systemu (opracowanie modelu - implementacja podsystemów z uproszczonymi opisami funkcjonalnymi, procedurami oraz testowanie interakcji tych modeli w celu osiągnięcia celu systemu ), natomiast możliwe jest zastosowanie „modeli” kryteriów adekwatności, stabilności, efektywności;
- "montaż" i testowanie systemu - implementacja pełnoprawnych podsystemów funkcjonalnych i kryteriów, ocena modelu według sformułowanych kryteriów;
- operacja systemowa;
– określenie celów dalszego rozwoju systemu i jego zastosowań;
- utrzymanie systemu - doprecyzowanie, modyfikacja, rozbudowa możliwości systemu w trybie jego pracy (w celu jego ewolucji).
Te etapy są głównymi etapami przebudowy systemów informatycznych.
Rozwój korporacyjnego systemu informacyjnego jest z reguły realizowany dla dobrze zdefiniowanego przedsiębiorstwa. Oczywiście cechy przedmiotowej działalności przedsiębiorstwa będą miały wpływ na strukturę systemu informacyjnego. Ale jednocześnie struktury różne przedsiębiorstwa są na ogół do siebie podobne. Każda organizacja, niezależnie od rodzaju prowadzonej działalności, składa się z szeregu pionów, które bezpośrednio realizują taki lub inny rodzaj działalności firmy. I ta sytuacja dotyczy prawie wszystkich organizacji, bez względu na rodzaj prowadzonej działalności.
Tak więc każdą organizację można uznać za zbiór oddziałujących na siebie elementów (podpodziałów), z których każdy może mieć własną, dość złożoną strukturę. Relacje między działami są również dość złożone. W ogólnym przypadku istnieją trzy rodzaje powiązań między jednostkami biznesowymi:
Powiązania funkcjonalne - każdy dział wykonuje określone rodzaje pracy w ramach jednego procesu biznesowego;
Komunikacja informacyjna - jednostki wymieniają informacje (dokumenty, faksy, zamówienia pisemne i ustne itp.);
Komunikacja zewnętrzna - niektóre jednostki wchodzą w interakcję z systemami zewnętrznymi, a ich interakcja może mieć również charakter informacyjny i funkcjonalny.
Wspólność struktury różnych przedsiębiorstw pozwala na sformułowanie pewnych wspólnych zasad budowy korporacyjnych systemów informatycznych.
Ogólnie rzecz biorąc, proces tworzenia systemu informacyjnego można rozpatrywać z dwóch punktów widzenia:
Według czasu lub etapami koło życia opracowywany system. W tym przypadku rozważamy dynamiczną organizację procesu rozwoju, opisaną w kategoriach cykli, etapów, iteracji i etapów.
System informacyjny przedsiębiorstwa jest opracowywany jako projekt. Wiele cech zarządzania projektem i faz rozwoju projektu (faz cyklu życia) jest wspólnych i nie zależy tylko od tematyki, ale także od charakteru projektu (nie ma znaczenia, czy jest to projekt inżynierski czy ekonomiczny ). Dlatego warto najpierw rozważyć kilka ogólnych kwestii związanych z zarządzaniem projektami.
Projekt to ograniczona w czasie, celowa zmiana w odrębnym systemie z wstępnie jasno określonymi celami, których osiągnięcie warunkuje zakończenie projektu, a także z ustalonymi wymaganiami dotyczącymi terminów, rezultatów, ryzyka, wydatkowania środków i zasobów, i struktury organizacyjnej.
Zwykle w przypadku koncepcji złożonej (którą w szczególności jest koncepcja projektu) trudno jest podać jednoznaczne sformułowanie, które w pełni obejmuje wszystkie cechy wprowadzonej koncepcji. Dlatego powyższa definicja nie twierdzi, że jest unikalna i kompletna.
Można wyróżnić następujące główne cechy wyróżniające projekt jako obiekt zarządzania:
Zmienność - celowe przeniesienie systemu z istniejącego do jakiegoś
stan pożądany, opisany pod kątem celów projektu;
Ograniczenie ostatecznego celu;
ograniczony czas trwania;
Ograniczony budżet;
Wymagane ograniczone zasoby;
Nowość dla przedsiębiorstwa, dla którego realizowany jest projekt;
Złożoność - obecność dużej liczby czynników, które bezpośrednio lub pośrednio wpływają na postęp i wyniki projektu;
Wsparcie prawno-organizacyjne – stworzenie określonej struktury organizacyjnej na czas trwania projektu.
Efektywność pracy osiąga się poprzez zarządzanie procesem realizacji projektu, co zapewnia alokację zasobów, koordynację kolejności wykonywanych prac oraz kompensację zakłóceń wewnętrznych i zewnętrznych.
Z punktu widzenia teorii systemów sterowania projekt jako obiekt sterowania musi być obserwowalny i zarządzalny, czyli wyróżnia się pewne cechy, dzięki którym możliwe jest stałe monitorowanie postępu projektu (właściwość obserwowalności). Dodatkowo potrzebne są mechanizmy terminowego wpływu na przebieg realizacji projektu (właściwość sterowalności).
Własność sterowalności jest szczególnie istotna w warunkach niepewności i zmienności przedmiotowego obszaru, które często towarzyszą projektom rozwoju systemów informatycznych.
Każdy projekt, niezależnie od złożoności i nakładu pracy potrzebnej do jego realizacji, przechodzi przez pewne etapy swojego rozwoju: od stanu, gdy „jeszcze nie ma projektu” do stanu, w którym „projektu już nie ma”. Zestaw etapów rozwoju od powstania pomysłu do całkowitego zakończenia projektu dzieli się zwykle na fazy (etapy, etapy).
Istnieją pewne różnice w określaniu liczby faz i ich treści, ponieważ cechy te w dużej mierze zależą od warunków realizacji konkretnego projektu i doświadczenia głównych uczestników. Jednak logika i główna treść procesu tworzenia systemu informacyjnego w prawie wszystkich przypadkach są wspólne.
Można wyróżnić następujące fazy rozwoju systemu informatycznego:
Formowanie koncepcji;
Opracowanie specyfikacji technicznych;
Projekt;
Produkcja;
Uruchomienie systemu.
Rozważmy każdy z nich bardziej szczegółowo. Faza druga i częściowo trzecia są zwykle nazywane fazami projektowania systemu, a dwie ostatnie (czasem obejmują fazę projektowania) są fazami wdrażania.
Faza koncepcji
Formowanie pomysłów, wyznaczanie celów;
Utworzenie kluczowego zespołu projektowego;
Badanie motywacji i wymagań klienta i innych uczestników;
Zbieranie danych wyjściowych i analiza stanu istniejącego;
Określenie podstawowych wymagań i ograniczeń, wymaganych zasobów materialnych, finansowych i pracy;
Ocena porównawcza rozwiązań alternatywnych;
Składanie propozycji, ich rozpatrzenie i zatwierdzenie.
Opracowanie propozycji technicznej
Opracowanie głównej treści projektu, podstawowa struktura projektu;
Opracowanie i zatwierdzenie specyfikacji istotnych warunków zamówienia;
Planowanie, dekompozycja podstawowego modelu konstrukcyjnego projektu;
Sporządzanie kosztorysów i budżetów projektu, określanie zapotrzebowania na zasoby;
Opracowywanie planów kalendarzowych i rozszerzonych harmonogramów pracy;
Podpisanie umowy z klientem;
Uruchomienie środków komunikacji uczestników projektu i kontrola postępu prac.
Projekt
Na tym etapie najczęściej określane są podsystemy, ich wzajemne połączenia skuteczne sposoby wykonanie projektu i wykorzystanie zasobów. Charakterystyczne prace tego etapu:
Wykonanie podstawowych prac projektowych;
Opracowanie prywatnych specyfikacji technicznych;
Wykonanie projektu koncepcyjnego;
Sporządzanie specyfikacji technicznych i instrukcji;
Wydajność rozwój projektu, badanie i zatwierdzenie.
Rozwój
Na tym etapie prowadzona jest koordynacja i kontrola operacyjna prac nad projektem, podsystemy są produkowane, łączone i testowane. Główna zawartość:
Wykonywanie prac nad rozwojem oprogramowania;
Wykonywanie przygotowań do wdrożenia systemu;
Kontrola i regulacja głównych wskaźników projektu.
Uruchomienie systemu
Na tym etapie przeprowadzane są testy, próbna eksploatacja systemu w warunkach rzeczywistych, trwają negocjacje dotyczące wyników projektu oraz ewentualnych nowych kontraktów. Główne rodzaje pracy:
Złożone testy;
42. Pojęcie cyklu życia IP. (Temat 11, s. 103-105).
Baza danych zorientowana obiektowo(OOBD) – baza danych, w której modelowane są dane w postaci obiektów, ich atrybutów, metod i klas.
Bazy danych zorientowane obiektowo są zwykle zalecane w przypadkach, w których wymagane jest wydajne przetwarzanie danych o złożonej strukturze.
Manifest OODB proponuje obowiązkowe cechy, które musi spełniać każdy OODB. Ich wybór opiera się na 2 kryteriach: system musi być zorientowany obiektowo i być bazą danych.
Obowiązkowe cechy
1. Obsługa złożonych obiektów. System musi przewidywać możliwość tworzenia obiektów złożonych za pomocą konstruktorów obiektów złożonych. Konieczne jest, aby konstruktory obiektów były ortogonalne, to znaczy, że każdy konstruktor może być zastosowany do dowolnego obiektu.
2. Wsparcie indywidualności obiektów. Wszystkie obiekty muszą mieć unikalny identyfikator, który jest niezależny od wartości ich atrybutów.
3. Wsparcie enkapsulacji. Prawidłowa enkapsulacja jest osiągnięta dzięki temu, że programiści mają prawo dostępu jedynie do specyfikacji interfejsu metod, a dane i implementacja metod są ukryte wewnątrz obiektów.
4. Wsparcie dla typów i klas. Wymagane jest, aby OODB wspierała co najmniej jedną koncepcję rozróżnienia między typami i klasami. (Termin „typ” jest bardziej odpowiedni dla abstrakcyjnego typu danych. W językach programowania zmienna jest deklarowana z jej typem. Kompilator może wykorzystać te informacje do sprawdzenia, czy operacje wykonywane na zmiennej są zgodne z jej typem, co pomaga zapewnić czy oprogramowanie jest poprawne.Z drugiej strony, klasa jest szablonem do tworzenia obiektów i zapewnia metody, które można zastosować do tych obiektów, więc „klasa” dotyczy bardziej czasu wykonywania niż czasu kompilacji).
5. Wsparcie dziedziczenia typów i klas po przodkach. Podtyp lub podklasa musi dziedziczyć atrybuty i metody odpowiednio ze swojego nadtypu lub nadklasy.
6. Przeciążenie połączone z pełnym wiązaniem. Metody muszą być stosowane do obiektów różnego typu. Implementacja metody musi zależeć od typu obiektów, do których metoda jest stosowana. Aby zapewnić tę funkcjonalność, wiązanie nazw metod w systemie nie może nastąpić do czasu uruchomienia programu.
7. Kompletność obliczeniowa. Język manipulacji danymi powinien być językiem programowania ogólnego przeznaczenia.
8. Zbiór typów danych musi być rozszerzalny. Użytkownik musi mieć możliwość tworzenia nowych typów danych w oparciu o zestaw predefiniowanych typów systemów. Co więcej, nie powinno być żadnej różnicy między sposobem korzystania z danych systemowych i typów danych zdefiniowanych przez użytkownika.
OO DBMS
Bazy danych zorientowanych obiektowo- bazy danych, w których informacje są reprezentowane w postaci obiektów, jak w obiektowych językach programowania.
Używać czy nie używać obiektowych systemów zarządzania bazami danych (OODBMS) w rzeczywistych projektach dzisiaj? Kiedy należy ich używać, a kiedy nie?
Tutaj Korzyści za pomocą OODBMS:
· Nie ma problemu niezgodności pomiędzy modelem danych w aplikacji a bazą danych (niezgodność impedancji). Wszystkie dane są przechowywane w bazie danych w takiej samej formie jak w modelu aplikacji.
· Nie jest wymagane oddzielne utrzymywanie modelu danych po stronie DBMS.
· Wszystkie obiekty na poziomie źródła danych są silnie typowane. Nigdy więcej nazw kolumn ciągów! Refaktoryzacja obiektowej bazy danych i działającego z nią kodu jest teraz zautomatyzowana, a nie monotonnym i nudnym procesem.
standard ODMG
Pierwszy manifest formalnie był tylko artykułem przedstawionym na Konferencja na temat baz danych obiektowych i dedukcyjnych grupa osób. Jak widzieliście w poprzednim podrozdziale, wymagania Manifestu były raczej emocjonalne niż wyraźnie sprecyzowane. W 1991 roku powstało konsorcjum ODMG (wtedy skrót ten został ujawniony jako Grupa zarządzania obiektową bazą danych, ale później uzyskała szerszą interpretację - Grupa Zarządzania Danymi Obiektowymi). Konsorcjum ODMG jest blisko spokrewnione ze znacznie większym konsorcjum OMG ( Grupa Zarządzania Obiektem), która powstała dwa lata wcześniej. Głównym pierwotnym celem ODMG było opracowanie standardu branżowego dla baz danych zorientowanych obiektowo (model wspólny). Jako podstawę przyjęto podstawowy model obiektowy OMG COM ( Podstawowy model obiektowy). W ciągu ponad dziesięciu lat istnienia ODMG opublikowało trzy podstawowe wersje standardu, z których najnowsza nazywa się ODMG 3.0. 16
To zabawne, że chociaż ODMG (według autora) wyewoluowało z OMG, w ostatnich latach niektóre standardy OMG opierają się na modelu obiektowym ODMG. W szczególności specyfikacja OCL oparta jest na modelu ODMG ( Język ograniczenia obiektu), która jest częścią ogólnej specyfikacji języka UML 1.4 (i UML 2.0). W tym artykule nie zamierzamy przeprowadzać szczegółowego porównania podejść OMG i ODMG i kierować zainteresowanych czytelników do Encyklopedia Kogalowski oraz materiały ze stron internetowych tych konsorcjów. Ograniczymy się do krótkiego podsumowania głównych idei zawartych w standardzie ODMG-3.
Architektura ODMG
Proponowaną architekturę ODMG pokazano na rys. 2.1. Architektura ta określa sposób przechowywania danych i różne rodzaje dostępu użytkownika do tego „magazynu danych” 17 . Ujednolicona składnica danych jest dostępna z języka definicji danych, języka zapytań i wielu języków manipulacji danymi. 18 Na ryc. 2.1 ODL oznacza Język definicji obiektów (język definicji obiektów), OQL - Język zapytań obiektowych (język zapytań obiektowych) i OML- Język manipulacji obiektami (język manipulacji obiektami).
Ryż. 2.1. Architektura ODMG
Kluczem do architektury jest model danych reprezentujący struktura organizacyjna, który przechowuje wszystkie dane zarządzane przez OODBMS. Język definicji obiektów, język zapytań i języki manipulacji są zaprojektowane w taki sposób, aby wszystkie ich możliwości opierały się na modelu danych. Architektura pozwala na przechowywanie modelowanych danych w różnych strukturach implementacyjnych, ale ważnym wymogiem jest, aby wszystkie biblioteki oprogramowania i wszystkie narzędzia pomocnicze były dostarczane w ramach zorientowanej obiektowo i muszą być utrzymywane w spójności z danymi.
Główne elementy architektury są następujące.
- Obiektowy model danych. Wszystkie dane przechowywane przez OODBMS są ustrukturyzowane pod względem konstrukcji modelu danych. Dokładna semantyka wszystkich pojęć jest zdefiniowana w modelu danych (więcej szczegółów poniżej).
- Język definicji danych (ODL). Schematy baz danych są opisane w języku ODL, w którym konstrukcje modeli danych są tworzone w postaci języka definicji. ODL umożliwia opisanie schematu jako zestawu interfejsów typu obiektowego, który zawiera opis właściwości typu i relacji między nimi, a także nazwy operacji i ich parametrów. ODL nie jest kompletnym językiem programowania; implementacja typów musi odbywać się w jednym z języków kategorii OML. Ponadto ODL jest wirtualny język w tym sensie, że standard ODMG nie wymaga jego implementacji w produktach oprogramowania OODBMS, które są uznawane za zgodne ze standardem. Dopuszczalne jest, aby te produkty wspierały równoważne języki definicji, które zawierają wszystkie cechy ODL, ale są dostosowane do specyfiki konkretnego systemu. Jednak obecność specyfikacji języka ODL w standardzie ODMG jest ważna, ponieważ język określa właściwości modelu danych.
- Język zapytań obiektowych (ODL). Język ma składnię podobną do Język SQL, ale opiera się na semantyce modelu obiektowego ODMG. Standard umożliwia bezpośrednie korzystanie z OQL i jego osadzenie w jednym z języków kategorii OML.
Relacyjny model danych
Prawie wszystko nowoczesne systemy oparte na relacyjny(relacyjne) modele zarządzania bazami danych. Nazwa relacyjny ze względu na to, że każdy rekord w takiej bazie zawiera informacje dotyczące tylko jednego konkretnego obiektu.
W relacyjny DBMS wszystkie przetwarzane dane prezentowane są w postaci płaskich tabel. Informacje o obiektach określonego typu prezentowane są w formie tabelarycznej: kolumny tabeli zawierają różne atrybuty obiektów, a wiersze mają na celu sprowadzenie opisów wszystkich atrybutów do pojedynczych instancji obiektów.
Model stworzony na etapie modelowania infologicznego w największym stopniu spełnia zasady relacyjności. Aby jednak sprowadzić ten model do relacyjnego, konieczne jest wykonanie procedury zwanej normalizacja.
Teoria normalizacji działa z pięcioma normalne formy. Formularze te mają na celu zmniejszenie nadmiarowości informacji, dlatego każda kolejna normalna forma musi spełniać wymagania poprzedniej oraz pewne dodatkowe warunki. W praktycznym projektowaniu baz danych zwykle nie stosuje się czwartej i piątej formy. Ograniczyliśmy się do pierwszych czterech normalnych form.
Wprowadźmy pojęcia niezbędne do zrozumienia procesu doprowadzenia modelu do schematu relacyjnego.
Nastawienie- abstrakcja opisywanego obiektu jako zbioru jego właściwości. Na infologicznym etapie projektowania rozmawialiśmy o abstrahowaniu obiektów i przypisywaliśmy im pewne właściwości. Teraz, dzięki projektowi koncepcyjnemu, przechodzimy na wyższy poziom abstrakcji. Na tym etapie obiekty jako takie już nie istnieją. Pracujemy z zestawem właściwości, które definiują obiekt.
Instancja związku- zestaw wartości właściwości konkretnego obiektu.
główny klucz- identyfikujący zestaw atrybutów, tj. wartość tych atrybutów jest pod tym względem wyjątkowa. Żadne dwa wystąpienia relacji nie zawierają tych samych wartości w kluczu podstawowym.
prosty atrybut- atrybut, którego wartości są niepodzielne.
Atrybut złożony- atrybut, którego wartością jest zbiór wartości kilku różnych właściwości obiektu lub kilka wartości jednej właściwości.
Koncepcje esencji.
Domena
Pojęcie domeny jest bardziej specyficzne dla baz danych, chociaż ma pewne analogie z podtypami w niektórych językach programowania. W swojej najbardziej ogólnej postaci domena jest definiowana przez określenie podstawowego typu danych, do którego należą elementy domeny, oraz arbitralnego wyrażenia logicznego zastosowanego do elementu typu danych. Jeśli to wyrażenie logiczne ma wartość true, element danych jest elementem domeny.
Najbardziej poprawną intuicyjną interpretacją pojęcia domeny jest rozumienie domeny jako ważnego potencjalnego zestawu wartości danego typu. Na przykład domena „Nazwy” w naszym przykładzie jest zdefiniowana na typie podstawowego ciągu znaków, ale jej wartości mogą zawierać tylko ciągi, które mogą reprezentować nazwę (w szczególności takie ciągi nie mogą zaczynać się od znaku miękkiego).
Należy również zwrócić uwagę na semantyczne znaczenie pojęcia domeny: dane uważa się za porównywalne tylko wtedy, gdy należą do tej samej dziedziny. W naszym przykładzie wartości domen „Pass Numbers” i „Group Numbers” są typu całkowitego, ale nie są porównywalne. Zauważ, że większość relacyjnych DBMS nie używa pojęcia domeny, chociaż jest już obsługiwane w Oracle V.7.