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). Rysunek pokazuje, że w porównaniu z modelem relacyjnym w post model relacyjny dane są przechowywane wydajniej, a przetwarzanie nie wymaga operacji łączenia danych między dwiema tabelami.

Faktury

Nad głową

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ą bardzo efektywne w tym zakresie. W analitycznych systemach przetwarzania okazały się one nieco niezdarne 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 systemy informacyjne stopień szczegółowości prezentacji informacji dla użytkownika zależy od jego poziomu: analityk, użytkownik, manager, manager.

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 ustawieniu funkcji predykcyjnych i zastosowaniu 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, jak kształtują się 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, np. komórki formuły arkusze kalkulacyjne, są obliczane zgodnie z ustalonymi wzorami).

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 znajduje się 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ład struktury logicznej bazy danych bibliotekoznawstwa zorientowanego obiektowo przedstawiono na ryc. 2.9. Tutaj obiekt typu Biblioteka jest rodzicem obiektów instancji klasy Abonent, Katalog I 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 (unikatowym dla każdego wystąpienia księgi), ale mają te same wartości właściwoś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 polega na metodach 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ść określającą numer telefonu autora książki i posiada tytuł telefon, otrzymamy właściwości o tej samej nazwie dla obiektów Abonent I 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 zstępnych 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ł I 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 I Pokój w obiekcie Biblioteka powoduje, że te właściwości są dziedziczone przez wszystkie obiekty podrzędne Abonent, Książka I Zagadnienia ale. To nie przypadek, że w związku z tym wartości nieruchomości bilet zajęcia Abonent I ekstradycja pokazano na ryc. 2.9 są takie same - 00015.

Wielopostaciowość w obiektowych językach programowania oznacza możliwość tego samego kod programu pracować z różnymi typami danych. 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 bibliotecznej bazy danych

Główny godność obiektowy model danych w porównaniu z relacyjnym to możliwość wyświetlania informacji o złożonych relacjach obiektów. Obiektowo zorientowany 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.

Obiektowo zorientowany model danych jest rozszerzeniem przepisów programowania obiektowego (podczas gdy model relacyjny powstał na gruncie teorii mnogości, czyli jako model danych). Object DataBase Management Group opracowała standard ODMG-93 (Object DataBase Management Group). Ten standard nie został jeszcze w pełni wdrożony.

Struktura obiektowej bazy danych jest graficznie reprezentowana jako drzewo, którego węzły są obiektami. Widoczna struktura obiektu jest określana przez właściwości jego klasy. Klasa obejmuje obiekty, podczas gdy struktura i zachowanie obiektów tej samej klasy są takie same. Każdy obiekt, a mianowicie instancja klasy, jest uważany za potomka obiektu, w którym jest zdefiniowany jako właściwość. Właściwości obiektu- lub typ standardowy, na przykład ciąg lub typ klasy skonstruowany przez użytkownika. Zachowanie obiektów jest ustawiane za pomocą metod. metoda to operacja, którą można zastosować do obiektu.

Jako przykład rozważmy bazę danych „BIBLIOTEKA” (rys. 4.4). Właściwości, ich rodzaje i wartości są zdefiniowane dla każdego obiektu. W DB:

"BIBLIOTEKA" - rodzic (przodek) dla "SUBSKRYPCJI", "KATALOGU", "WYDANIA";

„KATALOG” jest nadrzędnym elementem „KSIĄŻKI”.

"KSIĄŻKA" - różne przedmioty mogą mieć tych samych lub różnych rodziców. Jeśli ten sam rodzic (jeden autor), to numery inwentarzowe są różne, ale isbn, UDC, tytuł i autor są takie same.

Logiczna struktura obiektowej bazy danych jest podobna do hierarchicznej, główna różnica polega na sposobach manipulacji danymi. Na bazie danych można wykonywać takie czynności jak operacje logiczne, wzbogacone o obiektowe metody 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łaściwość zostanie dodana do „KATALOGU” telefon autora książki, to podobnie uzyskuje się je w „SUBSKRYPCJI” i „KATALOGU”. Znaczenie właściwości będzie określane przez przedmiot, w którym jest zawarta.

Dziedzictwo, odwrotnie, rozszerza zakres własności na wszystkich potomków obiektu. Tak więc wszystkim obiektom typu „KSIĄŻKA”, które są potomkami „KATALOG”, można przypisać właściwości rodzica isbn, UDC, tytułu i autora.

Poliformizm oznacza zdolność tego samego kodu programu do pracy z danymi heterogenicznymi. Innymi słowy, oznacza to dopuszczalność w obiektach różnego typu posiadania metod - procedur i funkcji - o tych samych nazwach. Podczas wykonywania programu obiektowego te same metody działają na różnych obiektach w zależności od typu argumentu. Dla bazy „LIBRARY” oznacza to, że obiekty klasy „BOOK”, które mają innych rodziców niż klasa „CATALOG”, mogą mieć inny zestaw właściwości, tj. programy do pracy z obiektem klasy „BOOK” mogą zawierać kod polimorficzny. W klasie metoda nie ma treści, to znaczy nie jest zdefiniowane, jakie konkretnie akcje ma wykonać. Każda podklasa wykonuje niezbędne operacje. Enkapsulacja ukrywa szczegóły implementacji przed wszystkimi obiektami poza daną hierarchią.

Zaletami modelu obiektowego w porównaniu z relacyjnym jest możliwość wyświetlania informacji o złożonych relacjach obiektów, brak ograniczeń w strukturach przechowywania danych. Obiektowa baza danych może przechowywać nie tylko strukturę, ale także behawioralne aspekty danych. Korzystając z podejścia obiektowego, można również tworzyć bazy danych o dużych ilościach. informacje semantyczne, takich jak multimedia i specjalistyczne dla określonych obszarów tematycznych (geograficznych, projektowych itp.).

Wady tego podejścia obejmują dużą złożoność koncepcyjną, niedogodności przetwarzania danych i niska prędkość realizacja wniosków.

W latach 90. powstały prototypy istniejących baz danych obiektowych. Są to POET (POET Software), JAŚMIN (COMPUTER ASSOCIATES), IRIS, ORION, POSTGRES.

Motyw 5

Podejście relacyjne w budowaniu modelu informacyjno-logicznego: podstawowe pojęcia

Relacyjny model danych. Podstawowe koncepcje

Jak zauważono w części poprzedniego wykładu, model relacyjny jest obecnie jednym z najpopularniejszych modeli na rynku baz danych. Podstawą tego modelu jest zbiór powiązanych ze sobą tabel (relacji).

Główne idee teoretyczne modelu relacyjnego zarysowali w pracach nad teorią relacji amerykański logik Charles Souders Peirce (1839-1914) i niemiecki logik Ernst Schroeder (1841-1902) oraz amerykański matematyk Edgar Codd.

W pracach Pierce'a i Schroedera udowodniono, że zbiór relacji zamyka się pod działaniem specjalnych operacji, które razem tworzą abstrakcyjną algebrę. Ta podstawowa właściwość relacji została wykorzystana w modelu relacyjnym do opracowania języka manipulacji danymi.

W 1970 roku ukazał się artykuł E. Codda o prezentacji danych uporządkowanych w postaci dwuwymiarowych tabel, zwanych relacjami. Codd najpierw przedstawił podstawowe pojęcia i ograniczenia modelu relacyjnego jako podstawy przechowywania danych, a także pokazał możliwości przetwarzania danych za pomocą tradycyjnych operacji na zbiorach oraz specjalnie wprowadzonych operacji relacyjnych.

Podstawowe koncepcje modelu relacyjnego podano w tabeli. 3.1.

Obiektami modelu relacyjnego są głównie tabele (relacje). Integralność danych jest zapewniona przez klucze obcy i podstawowy (patrz Sekcja „Relacyjna Integralność Danych”).

Operatory w modelu relacyjnym to zestaw instrukcji umożliwiających pobieranie i manipulowanie danymi.

Tabela 5.1. Elementy modelu relacyjnego

Struktura danych modelu relacyjnego zakłada reprezentację obszaru przedmiotowego rozważanego problemu jako zbiór powiązanych ze sobą relacji.

W każdej relacji jedna relacja może działać jako główna (baza, rodzic), a druga jako podrzędna (pochodna, dziecko). Aby utrzymać te powiązania, obie relacje muszą zawierać zestaw atrybutów, którymi są powiązane: w relacji głównej jest to klucz podstawowy relacji (jednoznacznie identyfikuje krotkę relacji głównej); podrelacja musi mieć zestaw atrybutów odpowiadający główny klucz główny związek. Tutaj ten zestaw atrybutów jest już kluczem wtórnym lub kluczem obcym, tj. definiuje zestaw pochodnych krotek relacji skojarzonych z pojedynczą krotką relacji bazowej.

Zestaw połączonych ze sobą stołów schemat bazy danych.

Więc relacja r to dwuwymiarowa tabela zawierająca pewne dane.

Matematycznie n-ary relacja r jest zbiorem produktu kartezjańskiego D 1×D 2×…×Dn zestawy (domeny) D 1 , D 2 ,…,D n(n≥1), opcjonalnie różne:

R D 1×D 2×…×Dn,

gdzie D 1×D 2×…×Dn jest kompletnym produktem kartezjańskim, tj. zbiór możliwych kombinacji n elementów każdy, gdzie każdy element jest pobierany ze swojej domeny.

Domena to pojęcie semantyczne, które można traktować jako podzbiór wartości pewnego typu danych, które mają określone znaczenie.

Właściwości domeny:

Domena posiada unikalną nazwę (w ramach bazy danych),

Zdefiniowane na jakimś prostym typie danych lub w innej domenie,

Może zawierać warunek logiczny do opisania podzbioru danych dozwolonych dla tej domeny,

Niesie pewien ładunek semantyczny.

Główną wartością domen jest to, że ograniczają porównania: nie można porównywać wartości z różnych domen, nawet jeśli mają ten sam typ danych.

Atrybut związek jest parą form

<Имя_атрибута: Имя_домена>(lub<OGŁOSZENIE>).

Nazwy atrybutów w relacji są unikalne. Często nazwy atrybutów są takie same jak odpowiadające im nazwy domen.

Relacja R zdefiniowana na zbiorze domen zawiera dwie części: nagłówek i treść.

Nagłówek relacji– stała liczba atrybutów relacji opisujących iloczyn kartezjański dziedzin, na których relacja jest określona:

(<A1: D1>, <A2: D2 >, …, <Oraz n>).

Nagłówek jest statyczny: nie zmienia się podczas pracy z bazą danych, jeśli atrybuty są zmieniane, dodawane lub usuwane w relacji, to uzyskiwana jest inna relacja. Nawet z zapisaną nazwą.

Ciało relacja zawiera zestaw krotek relacji.

Każdy krotka to zestaw par postaci:

<Имя_атрибута: Значение атрибута>:

r(<A1:Val1>, <A2:Val2 >, …, <A n: Val n>).

Tak, że wartość Val i atrybut Ai należy do domeny D i.

Ciało relacji jest zbiorem krotek, tj. podzbiorem iloczynu kartezjańskiego domen. Zatem ciało relacji jest w rzeczywistości relacją w matematycznym znaczeniu tego słowa. Treść relacji może się zmieniać podczas pracy z bazą danych, ponieważ krotki mogą się zmieniać, dodawać i usuwać w czasie.

Relacja jest zwykle pisana jako:

r(<A1: D1>, <A2: D2 >, …, <Oraz n>),

lub w skrócie: r(1, A2, …, Jakiś) lub r.

schemat relacji to zbiór nagłówków relacji zawartych w bazie danych, czyli lista nazw atrybutów danej relacji, wskazująca domenę, do której się odnoszą:

SR =(1, A2, …, Jakiś), A i D i, i = 1,...,n.

Jeśli atrybuty przyjmują wartości z tej samej domeny, nazywane są θ-porównywalnymi, gdzie θ jest zbiorem poprawnych porównań określonych dla tej domeny.

Na przykład, jeśli domena zawiera dane liczbowe, to dozwolone są dla niej wszystkie operacje porównania: θ == (=,<>,>=,<=,<,>). Jednak dla domen zawierających dane znakowe można określić nie tylko operacje porównania dla równości i nierówności wartości. Jeśli dana dziedzina ma nadany porządek leksykograficzny, to ma też pełny zestaw operacji porównawczych.

Schematy dwóch relacji są nazywane równowartość, jeśli mają ten sam stopień i możliwe jest ułożenie nazw atrybutów w schematach w taki sposób, aby atrybuty porównywalne, czyli takie, które przyjmują wartości z tej samej domeny, znajdowały się w tych samych miejscach.

Zatem dla relacji równoważnych spełnione są następujące warunki:

Posiadanie tej samej liczby atrybutów;

Obecność atrybutów o tych samych nazwach;

Obecność identycznych ciągów w relacjach, biorąc pod uwagę fakt, że kolejność atrybutów może być różna;

Relacje tego rodzaju są różnymi reprezentacjami tej samej relacji.

Właściwości związku wynikają bezpośrednio z powyższej definicji relacji. Te właściwości to główne różnice między relacjami relacyjnego modelu danych a prostymi tabelami:

Unikalność nazwy relacji. Nazwa jednej relacji musi różnić się od nazw innych relacji.

Wyjątkowość krotek. W relacji nie ma identycznych krotek. Rzeczywiście, ciało relacji jest zbiorem krotek i, jak każdy zbiór, nie może zawierać elementów nie do odróżnienia. Tabele, w przeciwieństwie do relacji, mogą zawierać identyczne wiersze. Każda komórka relacji zawiera tylko atomową (niepodzielną) wartość.

Zaburzenie krotki. Krotki nie są uporządkowane (od góry do dołu), ponieważ ciało relacji jest zbiorem, a zbiór nie jest uporządkowany (dla porównania wiersze w tabelach są uporządkowane). Ta sama relacja może być reprezentowana przez różne tabele z wierszami w różnej kolejności.

Zaburzenie atrybutów. Atrybuty nie są uporządkowane (od lewej do prawej).

Unikalność nazwy atrybutu w relacji. Każdy atrybut posiada unikalną nazwę w ramach relacji, co oznacza, że ​​kolejność atrybutów nie ma znaczenia (dla porównania kolumny w tabeli są uporządkowane). Ta właściwość nieco odróżnia relację od matematycznej definicji relacji. Ta sama relacja może być reprezentowana przez różne tabele, w których kolumny są w innej kolejności.

Niepodzielność wartości atrybutów. Wszystkie wartości atrybutów są niepodzielne. Wynika to z faktu, że atrybuty bazowe mają wartości atomowe, tj. z każdym atrybutem związana jest jakaś domena wartości (oddzielny typ elementarny), wartości atrybutów są pobierane z tej samej domeny. Schemat i krotki relacji są zbiorami, a nie listami, więc kolejność ich prezentacji nie ma znaczenia. Dla porównania - w komórkach tabeli można umieszczać różne informacje: tablice, struktury, inne tabele itp.

Komentarz:

Z właściwości relacji wynika, że nie każdy tabela może być relacją. Aby dana tabela definiowała relację, konieczne jest, aby tabela miała prostą strukturę (zawiera tylko wiersze i kolumny, a każdy wiersz musi mieć taką samą liczbę pól), tabela nie może mieć tych samych wierszy, żadnych kolumna tabeli musi zawierać dane tylko jednego typu , wszystkie użyte typy danych muszą być proste.

Należy zauważyć, że model relacyjny jest bazą danych w postaci zbioru powiązanych ze sobą relacji, które nazywane są schemat relacyjnej bazy danych.

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. Model danych zorientowanych obiektowo

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 predefiniowane klasy, 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 (superklasy), 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 znalazły najszersze zastosowanie w takich obszarach jak komputerowe wspomaganie projektowania/wytwarzania (CAD/CAM), komputerowe wspomaganie tworzenia oprogramowania (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 jest relacyjnym modelem danych zbudowanym na koncepcji relacji matematycznych i jest czasami nazywany 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 prostych tabelach, podzielonych 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. 4.

Rys.4. Tabela relacyjnej bazy danych.

Każda kolumna ma swoją nazwę. Na przykład w tabeli „Towary na stanie” (rys. 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 wyróżnia się unikalnym kluczem rekordu, który można podzielić na dwa typy: podstawowy i wtórny.

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żeli 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. Język SQL nie jest algorytmicznym językiem programowania. 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ś ta baza danych jest uważana 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 dla 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. Podczas zmiany struktury zmiany, które należy wprowadzić w programach użytkowych, są minimalne;

Do budowania zapytań i pisania programów użytkowych 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.

Podstawowe koncepcje

Definicja 1

Model zorientowany obiektowo reprezentacja danych umożliwia identyfikację poszczególnych rekordów bazy danych.

Rekordy bazy danych i funkcje ich przetwarzania połączone są mechanizmami podobnymi do odpowiednich narzędzi zaimplementowanych w obiektowych językach programowania.

Definicja 2

Reprezentacja graficzna Struktura obiektowej bazy danych to drzewo, którego węzły reprezentują obiekty.

Typ standardowy (na przykład ciąg - strunowy) lub typ utworzony przez użytkownika ( klasa), opisuje właściwości obiektu.

Na rysunku 1 obiekt LIBRARY jest obiektem nadrzędnym obiektów instancji klas CATALOG, SUBSCRIBER i ISSUES. Różne obiekty typu BOOK mogą mieć jednego lub różnych rodziców. Obiekty typu BOOK, które mają tego samego rodzica, muszą mieć co najmniej różne numery dostępu (unikalne dla każdego wystąpienia książki), ale te same wartości właściwości autor, tytuł, udko I isbn.

Struktury logiczne obiektowej i hierarchicznej bazy danych są zewnętrznie podobne. Różnią się głównie metodami manipulacji danymi.

Podczas wykonywania działań na danych w modelu zorientowanym obiektowo używane są operacje logiczne, które są wzbogacone o hermetyzację, dziedziczenie i polimorfizm. Z pewnymi ograniczeniami można używać operacji podobnych do poleceń SQL (na przykład podczas tworzenia bazy danych).

Podczas tworzenia i modyfikowania bazy danych automatycznie tworzone są, a następnie korygowane indeksy (tabele indeksów), które zawierają informacje do szybkiego wyszukiwania danych.

Definicja 3

Cel kapsułkowanie– ograniczenie zakresu nazwy właściwości do granic obiektu, w którym jest zdefiniowana.

Na przykład, jeśli do obiektu CATALOG zostanie dodana właściwość, która określa numer telefonu autora i ma imię i nazwisko telefon, wówczas właściwości o tej samej nazwie zostaną uzyskane dla obiektów CATALOG i SUBSCRIBER. Znaczenie właściwości jest określone przez przedmiot, w którym jest zawarta.

Definicja 4

Dziedzictwo, odwrotność enkapsulacji, odpowiada za rozszerzenie zakresu własności na wszystkich potomków przedmiotu.

Na przykład wszystkim obiektom BOOK, które są dziećmi obiektu CATALOG, można przypisać właściwości obiektu nadrzędnego: autor, tytuł, udko I isbn.

Jeśli konieczne jest rozszerzenie działania mechanizmu dziedziczenia na obiekty, które nie są bezpośrednimi krewnymi (na przykład na dwóch potomków tego samego rodzica), definiuje się abstrakcyjną właściwość typu we wspólnym przodku abs.

Więc właściwości Pokój I bilet w obiekcie LIBRARY są dziedziczone przez wszystkie obiekty podrzędne LENDING, BOOK i SUBSCRIBER. Dlatego wartości tej właściwości klas SUBSCRIBER i ISSUANCE są takie same - 00015 (rysunek 1).

Definicja 5

Wielopostaciowość umożliwia pracę tego samego kodu programu z danymi heterogenicznymi.

Innymi słowy, pozwala obiektom różnych typów mieć metody (funkcje lub procedury) o tych samych nazwach.

Szukaj w obiektowej bazie danych jest określenie podobieństwa między obiektem określonym przez użytkownika a obiektami, które są przechowywane w bazie danych.

Zalety i wady modelu obiektowego

Główny korzyść obiektowy model danych w przeciwieństwie do modelu relacyjnego to możliwość wyświetlania informacji o złożonych relacjach obiektów. Rozważany model danych pozwala na zdefiniowanie osobnego rekordu bazy danych i jego funkcji przetwarzania.

DO niedociągnięcia Model zorientowany obiektowo obejmuje wysoką złożoność koncepcyjną, niewygodne przetwarzanie danych i niską szybkość wykonywania zapytań.

Do tej pory takie systemy są dość rozpowszechnione. Należą do nich DBMS:

• postgres,
• orion,
• irys,
• ODBJupiter,
• Wszechstronny,
• Obiektywność/DB,
• magazyn obiektów,
• statyczny,
• kamień szlachetny
• g podstawa.

Model zorientowany obiektowo

W modelu obiektowym podczas prezentacji danych można zidentyfikować poszczególne rekordy bazy danych. Relacje między rekordami bazy danych a 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). Nie udało się jeszcze w pełni wdrożyć zaleceń ODMG-93. Aby zilustrować kluczowe idee, rozważ nieco uproszczony model bazy danych zorientowanej obiektowo.

Struktura obiektowej bazy danych (na przykład Versant Object Database, Object Store itp.) jest graficznie reprezentowana jako drzewo, którego węzły są obiektami. Właściwości obiektu są opisywane przez jakiś standardowy typ (na przykład string - string) lub typ skonstruowany przez użytkownika (definiowany jako klasa).

Wartość właściwości typu string jest ciągiem znaków. Wartością właściwości typu class jest obiekt będący instancją odpowiedniej klasy. Każdy obiekt - instancja klasy jest uważana za potomka obiektu, w którym jest zdefiniowana jako właściwość. Obiekt jest instancją klasy, która należy do jego klasy i ma jednego rodzica. Ogólne relacje w bazie danych tworzą spójną hierarchię obiektów.

Logiczna struktura obiektowej bazy danych jest zewnętrznie podobna do struktury hierarchicznej bazy danych. Główna różnica między nimi polega na metodach 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.

Operacje podobne do poleceń SQL mogą być wykorzystywane w ograniczonym zakresie (na przykład do tworzenia bazy danych).

Tworzeniu i modyfikacji bazy danych towarzyszy automatyczne tworzenie i późniejsze korygowanie indeksów (tablic indeksowych) zawierających informacje do szybkiego wyszukiwania danych.

Rozważmy pokrótce pojęcia enkapsulacji, dziedziczenia i polimorfizmu w odniesieniu do obiektowego modelu bazy danych.

Hermetyzacja ogranicza zakres nazwy właściwości do obiektu, w którym jest zdefiniowana.

Dziedziczenie natomiast rozszerza zakres majątku na wszystkich potomków przedmiotu.

Polimorfizm w obiektowych językach programowania oznacza zdolność tego samego kodu programu do pracy z heterogenicznymi danymi. Innymi słowy, oznacza to, że obiekty różnych typów mogą mieć metody (procedury lub funkcje) o tych samych nazwach. Podczas wykonywania programu obiektowego te same metody działają na różnych obiektach w zależności od typu argumentu. Wyszukiwanie w obiektowej bazie danych polega na szukaniu podobieństw między obiektem określonym przez użytkownika a obiektami przechowywanymi w bazie danych. Obiekt zdefiniowany przez użytkownika nazywany obiektem celu (właściwość obiektu typu gol) może być ogólnie podzbiorem całej hierarchii obiektów przechowywanej w bazie danych. Obiekt docelowy, jak również wynik wykonania zapytania, mogą być przechowywane w samej bazie danych.

Główną zaletą obiektowego modelu danych w porównaniu z relacyjnym jest możliwość wyświetlania informacji o złożonych relacjach obiektów. Obiektowo zorientowany model danych pozwala zidentyfikować pojedynczy rekord bazy danych i zdefiniować funkcje do ich przetwarzania.

Wadami modelu obiektowego są duża złożoność koncepcyjna, niedogodność przetwarzania danych oraz niska szybkość wykonywania zapytań.

Typy danych

Początkowo DBMS służyły przede wszystkim do rozwiązywania problemów finansowych i ekonomicznych. Jednocześnie, niezależnie od modelu prezentacji, w bazach danych zastosowano następujące główne typy danych:

• numeryczne. Przykładowe wartości danych: 0,43; 328; 2E+5;
• znak (alfanumeryczny). Przykłady wartości danych: "piątek", "string", "programista";
• daty określone przy użyciu specjalnego typu „Data” lub jako zwykłe dane znakowe. Przykłady wartości danych: 1.12.97, 23.02.1999.

W różnych DBMS typy te mogą nieznacznie różnić się od siebie nazwą, zakresem wartości i rodzajem reprezentacji. Następnie wyspecjalizowane systemy przetwarzania danych zaczęły pojawiać się w nowych obszarach zastosowań, np. geoinformacji, przetwarzaniu obrazu wideo itp. W związku z tym programiści zaczęli wprowadzać nowe typy danych do tradycyjnego systemu DBMS. Stosunkowo nowe typy danych obejmują:

• tymczasowe i data-godzina, przeznaczone do przechowywania informacji o czasie i (lub) dacie. Przykładowe wartości danych: 31.01.2085 (data), 9:10:03 (godzina), 06.03.1960 12:00 (data i czas);
• zmienne znakowe o zmiennej długości, przeznaczone do przechowywania informacji tekstowych o dużej długości, takich jak dokument;
• binarny, przeznaczony do przechowywania obiektów graficznych, informacji audio i wideo, informacji przestrzennych, chronologicznych i innych informacji specjalnych. Na przykład w MS Access jest to typ danych „OLE Object Field”, który umożliwia przechowywanie danych graficznych w bazie danych w formacie BMP (Bitmap) i automatyczne wyświetlanie ich podczas pracy z bazą danych;
• hiperłącza, przeznaczone do przechowywania linków do różnych zasobów (stron, plików, dokumentów itp.) znajdujących się poza bazą danych, na przykład w Internecie, intranecie korporacyjnym lub na dysku twardym komputera.

W nowoczesnym DBMS z różnymi modelami danych można używać wszystkich wymienionych typów danych.