| Relacyjno-Obiektowe bazy danych |
|---|
| Napisane przez Mon 04 Dec 2006 przez Artur (2454 cztane) |
|
Relacyjno-Obiektowe bazy danych Wybór, pomiędzy relacyjnymi a obiektowymi bazami danych, stwarzał i w dalszym ciągu stwarza wielki problem. Z jednej strony mamy stabilną technologię wspieraną przez wielu producentów a z drugiej stosunkowo nowatorskie rozwiązanie o znacznie mniejszym zapleczu. Jednak coraz to większe wymagania od systemów informatycznych oraz brak ich wspomagania przez relacyjny model danych, przemawia na korzyść obiektowego modelu danych. Ale jak w jednej chwili odejść od tak powszechnej technologii? Tym bardziej, że ta druga, w przeciwieństwie do pierwszej, nie zyskała sobie akceptacji w całym obszarze. W odpowiedzi na te fakty wielu producentów podjęło próby uzupełnienia swoich produktów - relacyjnych baz danych, o cechy które mogłyby sprostać stawianym wymaganiom. I tym sposobem obecnie wyróżnia się wiele relacyjnych systemów zarządzania bazą danych z rozszerzeniem o zdolność przechowywania obiektów. Konsekwencją tego jest różna interpretacja pojęć obiektowości w rozszerzeniu funkcji modelu relacyjnego. Jedną z największych zalet tego rozwiązania jest oczywiście zachowanie czynnika, który przyczynił się do sukcesu relacyjnych baz danych - relacyjnego modelu danych. Odbiorcy systemów baz danych akceptują to rozwiązanie nie tylko z racji rozszerzenia funkcjonalności bazy danych, doceniają tu również, łagodniejszy sposób ewolucji, który obrazuje się mniejszymi kosztami wprowadzanych zmian oraz większą pewnością rozwiązania. Następstwem różnej interpretacji są konkurencyjne produkty obiektowo-relacyjne, co nie przyczynia się do spójnego obrazu. Mimo tego, że obiektowo-relacyjne bazy danych są jedynie rozszerzeniem relacyjnych baz danych, występuje tu pewna sytuacja, która zmusza mnie do innego podejścia w opisie tego modelu danych. Przypadek opisania relacyjnych baz danych sprowadzał się do omówienia jego matematycznych podstaw. Tu sytuacja jest o tyle inna, że nie można jednolicie oprzeć działanie tych obiektowych relacji o podobne fundamenty, które miały miejsce w relacyjnym modelu danych. Występuje tu szereg sprzecznych kwestii, różnie opisywanych przez poszczególnych dostawców oprogramowania. Dlatego też, zresztą jak w każdym modelu danych, pożądane jest zatwierdzenie przez ogólno światową instytucję, typu ISO. O sukcesie obiektowo-relacyjnych baz danych zadecydowało opracowanie przez ANSI oraz ISO, SQL 3. Dlatego napisałem o „innym podejściu”, że tu z kolei oprę interpretację obiektowo-relacyjnego modelu danych właśnie o obszerny standard SQL 3, któremu zawdzięcza się jednolity obraz . Struktura danych W dalszym ciągu i ten model opiera się o relacje i reprezentacja danych jest tu podobna jak w modelu relacyjnym. Tylko podobna, gdyż właściwości przechowywanych obiektów wyznaczają tu dodatkowe cechy. O możliwości, zagnieżdżenia jednej tabeli w drugiej, decyduje typ wiersza. Można tu wykorzystać właściwość i zaznaczyć, że kolumna zawiera cały wiersz. Zmienne mogą przechowywać całe wiersze, które można przekazywać jako argumenty procedur czy też zwracać jako wyniki wywołań funkcji. Abstrakcyjne typy tu nazywa się typami definiowanymi przez użytkownika i są niczym innym jak nazwa na to wskazuje. Występuje podział na typy rozróżnione i typy strukturalne. Typ rozróżniony pozwala rozróżnić dwa identyczne typy bazowe. W przeciwieństwie do dziedzin - znanych z SQL, gdzie istniały jedynie więzy, które zapobiegały wprowadzaniu niepoprawnych wartości, tu rozróżnia się wystąpienie typów pomimo takich samych deklaracji. Na szczególną uwagę zasługują typy strukturalne, które składają się z definicji atrybutów i definicji procedur. Określenie metod przetwarzania danych jest realizowane przez tzw. podprogramy użytkownika. Ich rolą jest przede wszystkim definiowanie funkcji zwracających złożone wartości. Definicja podprogramu może następować w dwojaki sposób: jako element typu użytkownika lub odrębny element schematu. Istnieje szereg możliwości, gdyż można zdefiniować podprogram z wykorzystaniem rozszerzenia SQL - co w efekcie daje język obliczeniowo zupełny oraz za pośrednictwem języka typu C++, jako program zewnętrzny względem SQL. Jednym z podstawowych pojęć w technologii obiektowej, o którym wcześniej pisałem jest polimorfizm. Oczywiście tu również następuje odzwierciedlenie tego pojęcia, tyle że z pewnymi ograniczeniami. I tak, funkcje w danym schemacie nie mogą się cechować tą samą nazwą, taką samą liczbą argumentów, takimi samymi typami danych poszczególnych argumentów oraz takim samym typem wyniku. Dwie procedury z tego samego schematu nie mogą mieć takich samych nazw i liczb parametrów. Pojęcia takie jak podtypy i nadtypy są czymś zwyczajowym w obiektowości i tu również mają miejsce. Ograniczeniem jest zakaz stosowania dziedziczenia wielokrotnego. Innymi słowy typ może mieć więcej niż jeden podtyp, ale w danej sytuacji nie może istnieć dla niego więcej niż jeden nadtyp. Rozwiązaniem, dla przechowywania wielu wartości danych w jednej kolumnie tabeli są tzw. kolekcje. Zaletą jest możliwość tworzenie tabel zagnieżdżonych, gdzie jedna kolumna zawiera w rzeczywistości całą inną tabelę. Najczęstsze wykorzystanie to odzwierciedlenie wielu poziomów szczegółowości danych co w rezultacie zwiększa niesamowicie możliwości projektowania struktury danych. Chociaż w zamyśle miałem, poprzez opisanie pewnych cech SQL 3 wskazać na obiektowo-relacyjny model danych, w tym akapicie zbliżę się do jednej z zalet systemu zarządzania bazą danych. W wielu SZBD istnieje możliwość przechowywania dużych obiektów w polu opisywanym przez skrót BLOB. SQL 3 natomiast poszerza tą możliwość o przetwarzanie tych pól. Innymi słowy poprzednicy jedynie przetrzymywali tą binarną wartość bez znajomości jej wewnętrznej struktury. Omawiane duże obiekty SQL 3 dzieli na trzy kategorie: BLOB - zwyczajne, nie powiązane z żadnym zbiorem znaków czy alfabetem ciągi binarne, CLOB - obiekty znakowe, NCLOB - obiekty znakowe w językach narodowych. Godne uwagi jest również opracowanie a zarazem uzupełnienie niedostatku modelu relacyjnego o obsługę zapytań rekurencyjnych. Nazwa rekursja liniowa w SQL 3 wskazuje właśnie na tą operację. Integralność danych Definiowałem wcześniej czym jest tzw. tożsamość obiektu. SQL 3 określa tzw. typy referencji, dzięki którym możemy uzyskać podobny efekt jaki uzyskać można poprzez identyfikatory obiektu OID. Dzięki typom referencyjnym można zdefiniować związek pomiędzy typami wierszy i jednoznacznie identyfikować wiersz w tabeli. W jednej tabeli można składować wartość typu referencyjnego, który wykorzystuje się do bezpośredniego dostępu do określonego wiersza w tabeli bazowej. Inną zaletą referencji jest możliwość umieszczenia jednocześnie wiersza w wielu tabelach co przyczynia się do zastąpienia skomplikowanych złączeń w zapytaniach. Operowanie danymi Ogólnie przyjęte cechy obiektowo-relacyjnego model danych wynikają właśnie z języka do operowania na danych, jakim jest SQL 3. Język ten jest na tyle obszerny, że nie sposób go opisać w pracy o innym temacie. Mogę natomiast w kilku słowach wspomnieć o że SQL 3 jest na tyle rozbudowany że zyskał sobie miano jeżyka obliczeniowo zupełnego, co przyczynia się między innymi do tego że bezpośrednio w bazie danych możemy zapisywać zachowanie obiektów. Obiektowo-relacyjny model danych jest tak naprawdę rozszerzeniem możliwości modelu relacyjnego o realizacje pojęć obiektowości. Nie istnieje jeden rozszerzony relacyjny model danych, natomiast wyróżnia się różne sposoby jego realizacji. SQL 3 jest tu pewną wytyczną, która przyczyniła się do jednolitego spojrzenia. Można śmiało powiedzieć, że ten model danych jako nowe rozwiązanie jest obecnie najszerzej akceptowany co przyczynia się do szerokiego wsparcia przez producentów oprogramowania. Rozszerzenia wprowadzone przez SQL 3, są ogólnie akceptowane, co w połączeniu z konstrukcjami języka czyniącymi go obliczeniowo zupełnymi, decydują o szerokim spektrum możliwości. |
| Indeks :: Drukuj :: E-mail |
Komentarze są własnością ich autorów. Nie ponosimy odpowiedzialności za ich treść.