Obiekt zorientowany
Model postrelacyjny
Zalety i wady relacyjnego modelu danych
Główny godność relacyjny model danych – jest łatwy do zrozumienia, wizualny i ma ścisłe uzasadnienie matematyczne.
niedogodności następujące:
Relacyjny model danych nie pozwala na reprezentację obiektów o złożonej strukturze, ponieważ w jego ramach możliwe jest modelowanie tylko przy użyciu tabel dwuwymiarowych;
· dane o obiektach zawarte są z reguły w wielu tabelach. W związku z tym wyodrębnienie informacji o każdym takim obiekcie wymaga wykonania wielu operacji łączenia przy użyciu kluczy podstawowych i obcych, co znacznie spowalnia przetwarzanie danych.
Ostatnio takie modele jak postrelacyjne, obiektowe, obiektowo-relacyjne i wielowymiarowe modele.
Postrelacja model danych w ogólnym przypadku jest rozszerzonym modelem relacyjnym, który usuwa ograniczenie niepodzielności wartości pól.
Oznacza to, że dozwolone są pola wielowartościowe, których wartości składają się z podwartości. Przykładem modelu postrelacyjnego jest tabela będąca zbiorem danych z powiązanych tabel relacyjnych KLIENCI i ZAMÓWIENIA.
Zalety postrelacyjny model danych:
· możliwość reprezentowania powiązanych tabel relacyjnych przez jedną tabelę postrelacyjną. Zapewnia to wysoką widoczność prezentacji danych oraz zwiększa efektywność ich przetwarzania;
· brak ograniczeń co do długości pól i ich ilości w rekordach tabeli.
Wada model postrelacyjny – trudność w zapewnieniu integralności danych.
Do pokonania wykorzystywane są modele obiektowe i obiektowo-relacyjne niepełnosprawność relacyjny model przechowywania i przetwarzania złożone obiekty jak np. dokument, dźwięk, wideo, obraz graficzny itd.
Model zorientowany obiektowo reprezentuje strukturę, którą można przedstawić graficznie jako drzewo, którego węzły są obiektami.
Każdy przedmiot jest wyjątkowy identyfikator, stan i zachowanie. Stan obiekt jest określony przez zbiór wartości jego atrybutów. Zachowanie opis obiektu metody zwane procedurami. Oznacza to, że integralną częścią opisu obiektu są procedury, które mogą wykonywać działania na atrybutach obiektu w przypadku wystąpienia określonych zdarzeń. .
Obiekty można łączyć w zajęcia . Instancje tej samej klasy różnią się jedynie wartościami swoich właściwości, a nie metodami. Metody są ustawiane, gdy klasa jest zdefiniowana.
Do wykonywania działań na obiektach wykorzystywane są mechanizmy obiektowe - dziedziczenie, hermetyzacja, polimorfizm.
istota dziedzictwo polega na tym, że na podstawie istniejącej klasy można utworzyć nową klasę obiektów, które odziedziczą właściwości klasy nadrzędnej.
Dostęp do danych odbywa się wyłącznie zgodnie z zasadami zachowania obiektu, opisanymi metodami ( kapsułkowanie ).
Wielopostaciowość – zdolność obiektów do różnych reakcji na to samo wydarzenie w otaczającym świecie. Polimorfizm służy do ujednolicenia przetwarzania różnych obiektów. Na przykład metodę Print Result można zdefiniować dla wielu klas obiektów, ale działa ona różnie w zależności od klasy, do której jest stosowana.
Główny godność OOMD to możliwość wyświetlania informacji o złożone obiekty wraz z wyczerpującym opisem relacji między nimi i ich dynamicznym zachowaniem.Model ten jest zwykle używany do złożonych obszarów tematycznych, których modelowanie jest pozbawione funkcjonalności modelu relacyjnego (np. systemy automatyzacji projektowania, systemy wydawnicze itp.).
Wada OOMD to złożoność aparatu pojęciowego, co komplikuje jego zastosowanie i negatywnie wpływa na gromadzenie doświadczeń w tworzeniu i obsłudze baz danych obiektowych.
Obiektowy relacyjny model danych to model hybrydowy, który łączy możliwości modelu relacyjnego z właściwościami obiektu danych.
1. Obiekty widoczne na interfejs zewnętrzny, są mapowane na tabele w bazowej relacyjnej bazie danych. I odwrotnie, obiekty są pobierane z ich reprezentacji w środowisku tabelarycznej pamięci masowej, gdy żądają ich użytkownicy lub aplikacje. (podejście hybrydowe)).
To podejście było popularne pod koniec lat 80. XX wieku. i ucieleśnione w produkty oprogramowania do automatyzacji programowania (CASE), do automatyzacji projektowania (CAD), w repozytoriach (bazy danych przeznaczone do przechowywania danych nie użytkownika, ale systemu).
2. Wewnętrzne mechanizmy relacyjne SZBD zarządzania danymi są rozszerzone o możliwości obiektowe ( rozszerzone podejście relacyjne).
To podejście jest bardziej zaawansowane technologicznie i jest obecnie preferowane przez większość programistów RDBMS. Wcielił się w latach 1996-1997. w wielu obiektowo-relacyjnych serwerach baz danych.
Cechą wyróżniającą model obiektowo-relacyjny od OOMD jest to, że opiera się on na strategii modelu relacyjnego. Włączenie obiektów do modelu relacyjnego można na tym etapie omówić jedynie jako ogólny kierunek rozwoju baz danych.
DBMS o znacznie wyższym poziomie złożoności. Próbuje uchronić programistę przed wykonywaniem rutynowych operacji zarządzania danymi, które są tak charakterystyczne dla modeli hierarchicznych i sieciowych.W modelu relacyjnym baza danych jest scentralizowanym repozytorium tabel, które zapewnia bezpieczny, jednoczesny dostęp do informacji wielu użytkownikom. W wierszach tabel niektóre pola zawierają dane związane bezpośrednio z rekordem, a niektóre zawierają łącza do rekordów w innych tabelach. Zatem relacje między rekordami są podstawową właściwością modelu relacyjnego.
Każdy wpis w tabeli ma taką samą strukturę. Na przykład w tabeli zawierającej opisy pojazdów wszystkie rekordy będą miały ten sam zestaw pól: producent, model, rok, przebieg itd. Takie tabele są łatwe do przedstawienia graficznego.
Model relacyjny osiąga niezależność informacyjną i strukturalną. Rekordy nie są na tyle powiązane, że zmiana jednego z nich wpłynie na resztę, a zmiana struktury bazy danych niekoniecznie prowadzi do ponownej kompilacji pracujących z nią aplikacji.
W relacyjnym DBMS wykorzystywany jest język SQL, który umożliwia formułowanie dowolnych zapytań ad hoc. Jest to język czwartej generacji, więc każdy użytkownik może szybko nauczyć się pisać zapytania. Ponadto istnieje wiele aplikacji pozwalających na budowanie logicznych schematów zapytań w formie graficznej. Wszystko to dzieje się z powodu zaostrzenia wymagań dotyczących wydajności komputerów. Na szczęście nowoczesny moc obliczeniowa więcej niż wystarczające.
Relacyjne bazy danych cierpią na różnice w implementacji języka SQL, choć nie jest to problem modelu relacyjnego. Każdy relacyjny DBMS implementuje pewien podzbiór standardu SQL oraz zestaw unikalnych poleceń, co utrudnia programistom migrację z jednego DBMS do drugiego. Musisz dokonać trudnego wyboru między maksymalną przenośnością a maksymalną wydajnością. W pierwszym przypadku musisz przestrzegać minimalnego wspólnego zestawu poleceń obsługiwanych w każdym DBMS. W drugim przypadku programista po prostu skupia się na pracy w tym konkretnym DBMS, korzystając z jego unikalnych poleceń i funkcji.
MySQL to relacyjny system DBMS, a ten samouczek dotyczy modelu relacyjnego. Ale teoria baz danych nie stoi w miejscu. Pojawiają się nowe technologie, które rozszerzają model relacyjny.
Bazy danych zorientowanych obiektowo
Baza danych zorientowana obiektowo (OODB) pozwala programistom pracującym z językami trzeciej generacji interpretować wszystkie ich encje informacyjne jako obiekty przechowywane w pamięć o dostępie swobodnym. Dodatkowa warstwa abstrakcji interfejsu umożliwia przechwytywanie żądań, które uzyskują dostęp do tych części bazy danych, które znajdują się na stałe na dysku. Zmiany w obiektach są optymalnie przenoszone z pamięci na dysk.
Zaletą OODB jest uproszczony kod. Aplikacje potrafią interpretować dane w kontekście języka programowania, w którym są napisane. Relacyjna baza danych zwraca wartości wszystkich pól jako tekst, a następnie są one rzutowane na lokalne typy danych. W OOBD ten etap jest wyeliminowany. Metody manipulowania danymi są zawsze takie same, niezależnie od tego, czy dane znajdują się na dysku, czy w pamięci.
Dane w OODB mogą mieć postać dowolnej struktury, którą można wyrazić w używanym języku programowania. Relacje między podmiotami również mogą być dowolnie złożone. OODB zarządza buforem pamięci podręcznej obiektów, przenosząc obiekty między buforem a pamięcią dyskową w razie potrzeby.
OODB rozwiązuje dwa problemy. Po pierwsze, złożone struktury informacji wyrażane są w nich lepiej niż w relacyjnych bazach danych, a po drugie, eliminowana jest konieczność tłumaczenia danych z formatu obsługiwanego przez SZBD. Na przykład, w relacyjnym DBMS, wymiar liczb całkowitych może wynosić 11 cyfr, a w używanym języku programowania może to być 16. Programista będzie musiał wziąć tę sytuację pod uwagę.
DBMS zorientowany obiektowo pełni wiele dodatkowych funkcji. To się opłaca, jeśli relacje między danymi są bardzo złożone. W tym przypadku wydajność OODB jest wyższa niż relacyjnego DBMS. Jeśli dane są mniej złożone, dodatkowe funkcje okazują się zbędne. Kwerendy ad hoc są obsługiwane w modelu obiektów danych, ale ich językiem niekoniecznie jest SQL. Logiczna reprezentacja danych może nie odpowiadać modelowi relacyjnemu, więc użycie języka SQL stanie się bezsensowne. Często wygodniej jest przetwarzać obiekty w pamięci, przeprowadzając odpowiednie wyszukiwania.
Dużą wadą baz obiektowych jest ich ścisły związek z używanym językiem programowania. Dostęp do danych przechowywanych w relacyjnym DBMS może mieć dowolna aplikacja, podczas gdy np. obiekt Java umieszczony w OODB będzie interesujący tylko dla aplikacji napisanych w Javie.
Obiektowe relacyjne bazy danych
Obiektowo-relacyjny DBMS łączy cechy modeli relacyjnych i obiektowych. Ich występowanie tłumaczy się tym, że relacyjne bazy danych dobrze współpracują z wbudowanymi typami danych i znacznie gorzej - z niestandardowymi zdefiniowanymi przez użytkownika. Gdy pojawi się nowy ważny typ danych, musisz albo uwzględnić jego obsługę w DBMS, albo zmusić programistę do samodzielnego zarządzania danymi w aplikacji.
Nie wszystkie informacje mają sens interpretować jako ciągi znaków lub cyfr. Wyobraź sobie muzyczną bazę danych. Piosenkę zakodowaną jako plik audio można umieścić w polu tekstowym duży rozmiar, ale jak w tym przypadku zostanie przeprowadzone wyszukiwanie tekstowe?
Przebudowa DBMS w celu włączenia obsługi nowego typu danych nie jest najlepszym wyjściem. Zamiast tego obiektowo-relacyjny system DBMS umożliwia ładowanie kodu zaprojektowanego do przetwarzania „nietypowych” danych. Baza danych zachowuje więc swoją tabelaryczną strukturę, ale sposób obsługi niektórych pól tabel jest określany zewnętrznie, tj. programista.
Obecnie wśród systemów zarządzania danymi dominują relacyjne DBMS. Z jednej strony zalety podejścia obiektowego do tworzenia złożonych specjalistycznych aplikacji, a z drugiej chęć twórców systemów zarządzania bazami danych, aby poszerzyć granice zastosowania odpowiedniego DBMS, doprowadziły do włączenie komponentów obiektowych (system typów rozszerzalny przez użytkownika, enkapsulacja, dziedziczenie, polimorfizm itp.) w modelu danych relacyjnego DBMS. Odpowiadający DBMS, zwany obiektowo-relacyjny , łączcie się najlepsze cechy relacyjne i obiektowe bazy danych. Zauważ, że różne DBMS implementują inny zestaw wymienionych komponentów obiektowych. Tak więc nie ma ogólnie akceptowanego modelu obiektowo-relacyjnego, ale istnieje kilka takich modeli, które obsługują pewien zestaw komponentów zorientowanych obiektowo. Jednak podstawą wszystkich takich modeli są tabele relacyjne, używany jest język zapytań, zawarta jest koncepcja obiektu, a niektóre dodatkowo implementują możliwość zapisywania metod w bazie danych.
Odpowiednie zmiany w modelu relacyjnym wymusiły rozszerzenie standardu językowego Zapytania SQL. Pierwsza wersja tego standardu nosiła nazwę SQL3. Prace nad standardem wciąż trwają.
Przykładem DBMS zorientowanego obiektowo w maksymalnym stopniu jest badanie DBMS Postgres(3).
Zwróćmy uwagę na elementy systemu Microsoft Server 2008 DBMS, które są uważane za rozszerzenia obiektów.
· Rozszerzenia niestandardowe. Użytkownicy mają możliwość ingerowania w zestaw narzędzi pierwotnie dostarczony przez DBMS, tworząc w szczególności nowe typy danych zdefiniowane przez użytkownika.
· Przechowywanie dużych ilości danych. Wraz z danymi, które tradycyjnie były przechowywane w bazie danych, Microsoft SQL Server 2008 umożliwia przechowywanie dużych danych w kolumnach tabeli (obsługiwane są odpowiednie typy danych).
· Nowe typy danych specyficzne dla obiektu. System definiuje nowe typy danych (geometria, geografia), które są typowe dla tych obszarów, w których podejście obiektowe jest bardzo efektywne i często stosowane (kartografia i związane z nią aplikacje, geometryczna reprezentacja obiektów o bardzo różnym charakterze).
· Przechowywane procedury . W pewnym sensie procedury składowane są również rozszerzeniem obiektu, realizującym na danych czynności niezbędne dla użytkownika (podejście proceduralne, które jest standardem dla OOP).
2. Rozproszone bazy danych
Baza danych to zintegrowany zbiór danych, z którym pracuje wielu użytkowników. Przedstawienie wszystkich poprzednich rozdziałów zakładało pojedynczą bazę danych hostowaną na jednym komputerze. Przypomnij sobie podstawowe zasady leżące u podstaw teorii baz danych:
scentralizowane przechowywanie danych;
· scentralizowana obsługa danych (wprowadzanie, korekta, odczyt, kontrola integralności).
Zauważ, że bazy danych pojawiły się w okresie dominacji mainframe'ów. Baza danych utrzymywana była na jednym komputerze, wszyscy użytkownicy pracowali na komputerze (możliwe tryby pracy zostały opisane w wykładzie 3). Inne możliwości korzystania z technologii komputerowej w tym czasie po prostu nie istniały. Jeśli przeanalizujemy pracę użytkowników z danymi w firmach, organizacjach, przedsiębiorstwach w czasach „przedkomputerowych”, łatwo zauważyć, że w niektórych obszarach użytkownicy pracowali z „swoimi” danymi (zebrali określone dane, zachowywali, przetwarzali, przesyłali przetworzonych danych do innych obszarów) lub poziomów zarządzania).
Technologia ta miała istotne wady, które zostały już zauważone w poprzednich rozdziałach: powielanie niektórych danych, brak możliwości analizy porównawczej danych ze wszystkich stron. Technologia ta miała jednak również istotne zalety: dane były wprowadzane i przechowywane w miejscach ich generowania; użytkownik będący specjalistą w zakresie tych danych pracował z tymi danymi, co pozwoliło mu skutecznie kontrolować prawidłowość danych na wszystkich etapach przetwarzania; dane znajdowały się bezpośrednio u użytkownika, co umożliwiało ich szybkie przetwarzanie. Centralizacja danych na jednym komputerze, która niewątpliwie daje efektywne możliwości przechowywania i przetwarzania danych, nie pozwoliła na realizację powyższych zalet.
Rozwój informatyki sieć komputerowa doprowadził do nowych możliwości w organizacji i utrzymaniu baz danych, pozwalając każdemu użytkownikowi na posiadanie własnych danych na swoim komputerze i pracę z nimi, a jednocześnie pozwalając wszystkim użytkownikom na pracę z całym zbiorem danych jako jedną scentralizowaną bazą danych. Odpowiedni zbiór danych nazywany jest rozproszoną bazą danych.
Termin " rozproszona baza danych” jest dość powszechny w literaturze. Jednak w różne źródła Ten termin oznacza zupełnie inne rzeczy. Niektórzy autorzy rozumieją przez rozproszoną bazę danych, że istnieje zdalny serwer, na którym znajdują się dane, a także komputery klienckie zlokalizowane geograficznie w innym miejscu. Ta interpretacja wydaje się nam błędna. prawdziwy rozproszona baza danych znajduje się na wielu komputerach. W takim przypadku niektóre pliki znajdują się na jednym komputerze, inne na innym i tak dalej. Co więcej, jest to możliwe i często dochodzi do sytuacji, gdy informacje na tych komputerach pokrywają się i są powielane.
Rozproszona baza danych to zbiór logicznie połączonych współdzielonych danych (i opisów ich struktur) fizycznie rozproszonych w sieci komputerowej.
Model danych zorientowanych obiektowo
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 działania 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 kod programu pracować z różnymi typami danych. Innymi słowy oznacza to dopuszczalność w przedmiotach różne rodzaje mają metody - procedury i 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. 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. Stosując podejście obiektowe, można również tworzyć bazy danych zawierające duże ilości informacji semantycznych, takie jak bazy danych multimedialnych oraz bazy danych wyspecjalizowane w określonych obszarach tematycznych (geograficznych, projektowych itp.).
Wady tego podejścia to duża złożoność koncepcyjna, niedogodność przetwarzania danych oraz niska szybkość wykonywania zapytań.
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
| Pojęcie modelu relacyjnego | Opis |
| Baza danych (DB) | Zestaw tabel i innych obiektów niezbędnych do abstrakcyjnej reprezentacji wybranego Tematyka |
| Schemat DB | Zestaw powiązanych ze sobą nagłówków tabeli |
| Postawa | Tabela - zestaw obiektów świata rzeczywistego, które charakteryzują się wspólnymi właściwościami i cechami (pola tabeli) |
| Nagłówek relacji | Nagłówek tabeli - nazwy pól (kolumn) tabeli |
| Ciało związku | Ciało tabeli to zbiór wartości dla wszystkich obiektów świata rzeczywistego, który jest reprezentowany jako wpisy tabeli (wiersze tabeli) |
| schemat relacji | Wiersz nagłówka kolumny tabeli (nagłówek tabeli) |
| atrybut relacji | Nazwa kolumny tabeli (pole tabeli) |
| krotka relacji | Wiersz tabeli (rekord) – reprezentacja jeden do jednego obiektu świata rzeczywistego stworzona przy użyciu wartości pól tabeli |
| Domena | Zestaw prawidłowych wartości atrybutów |
| Wartość atrybutu | Wartość pola w rekordzie (krotka) |
| główny klucz | Jeden lub więcej (w przypadku klucza złożonego) atrybutów, które jednoznacznie definiują wartość krotki (wartość wiersza tabeli) |
| Klucz zewnętrzny | Atrybut tabeli, którego wartości odpowiadają wartościom klucza podstawowego w innej powiązanej tabeli (nadrzędnej, podstawowej). Klucz obcy może składać się z jednego lub więcej atrybutów (złożony klucz obcy). Jeśli liczba atrybutów klucza obcego jest mniejsza niż liczba atrybutów odpowiedniego klucza podstawowego, nazywa się to obciętym (częściowym) kluczem obcym. |
| Stopień (arność) związku | Liczba kolumn tabeli |
| Władza w związku | Liczba wierszy (krotek) tabeli |
| Instancja związku | Zbiór rekordów (krotek) dla danej tabeli (relacja). Instancja może z czasem ulec zmianie. Ponieważ zwykła baza danych w danym momencie działa tylko z jedną wersją relacji, taka instancja relacji nazywana jest bieżącą. |
| Typ danych | Typ wartości elementu tabeli |
| Stosunek bazowy | Relacja zawierająca jedną lub więcej kolumn charakteryzujących właściwości obiektu, a także klucz podstawowy |
| Relacja pochodna | Nie jest relacją bazową, tj. nie charakteryzuje właściwości obiektu i służy do udostępniania powiązań między innymi tabelami, nie może zawierać klucza podstawowego. Jeśli określony jest klucz podstawowy, to składa się on z kluczy obcych powiązanych z kluczami podstawowymi relacji bazowej |
| Połączenie | Ustanawia związek między pasującymi wartościami w polach kluczy – kluczem podstawowym jednej tabeli i kluczem obcym innej |
| Komunikacja jeden do jednego (1:1) | Używając tego typu relacji, wpis w jednej tabeli może mieć co najwyżej jeden skojarzony wpis w innej tabeli. W obu tabelach pola kluczowe muszą być podstawowe. Służy do oddzielania tabel z wieloma polami lub do wymagań dotyczących ochrony danych |
| Związek jeden-do-wielu (1:M) | W przypadku tego typu relacji każdy rekord jednej tabeli może odpowiadać kilku rekordom drugiej tabeli, ale każdy rekord drugiej tabeli odpowiada tylko jednemu rekordowi pierwszej tabeli. Pierwsza tabela musi mieć klucz podstawowy, druga musi mieć klucz obcy. |
| Relacja wiele do wielu (N:M) | W przypadku tego typu relacji jeden rekord w pierwszej tabeli może odpowiadać kilku rekordom drugiej tabeli, ale jeden rekord drugiej tabeli może odpowiadać kilku rekordom pierwszej. Unikalność kluczy dla takich tabel nie jest wymagana. W procesie projektowania schematu bazy danych takie linki są przekształcane. Aby to zrobić, musisz wprowadzić relację pomocniczą, która pozwala zastąpić relację wiele-do-wielu dwiema relacjami jeden-do-wielu |
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); relacja potomna musi mieć zestaw atrybutów odpowiadający kluczowi głównemu relacji głównej. 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 niektórych prosty typ dane 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 ma 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.
12 maja 2010 o 14:04Relacyjne bazy danych a bazy danych obiektowych
- Tworzenie stron internetowych
Niestety, na Habré nie znalazłem wystarczającej liczby interesujących stad o obiektowych bazach danych (OODB). Chciałbym poruszyć ten temat, ponieważ. Ostatnio coraz więcej mówi się o OODB. Jednak nie będzie możliwe umieszczenie wszystkich informacji w jednym artykule, więc na początek przedstawię mały przegląd i moje przemyślenia na ten temat. W tym artykule nie będę rozważał konkretnych rozwiązań opartych na każdej z technologii, a jedynie postaram się porównać same technologie.
tło
Zajmuję się projektowaniem i tworzeniem baz danych od około 6 lat. W tym czasie wypracowałem własną wizję jak najlepiej podejść do projektowania, jak dobrać architekturę systemu, jakie są funkcje w normalizacji i denormalizacji relacyjnych baz danych, jak optymalizować określone struktury i zapytania. W pierwszym roku pracy doszedłem do wniosku, że nie chcę zajmować się rutyną pisania tych samych zapytań. W rezultacie napisałem własny generator procedur składowanych, który zgodnie ze strukturą bazy danych generował większość rutynowych zapytań (jeśli to ciekawe, mogę napisać artykuł na ten temat). Potem ten generator ewoluował z roku na rok iw efekcie doszedłem do potrzeby przechowywania obiektów takimi, jakimi są, aby nie zawracać sobie głowy tłumaczeniem modelu obiektu na strukturę relacyjną. Tych. w rzeczywistości doszedłem do generowania jakiegoś dodatku do ORM. Oczywiście można powiedzieć, że powstała już wystarczająca ilość wysokiej jakości dodatków do ORM i baz obiektowo-relacyjnych, które można z powodzeniem wykorzystywać (zgadzam się z Państwem, ale z pewnymi zastrzeżeniami). Ale to też mi nie odpowiadało. I postanowiłem pójść dalej.Wpływ ORM
Moim skromnym zdaniem korzystanie z dodatków do ORM tylko spowalnia rozwój OODB. Postaram się wyjaśnić to dość kontrowersyjne stwierdzenie. Nie uważam, że ORM jest złem, ale też nie jest absolutnym dobrem. Technologia ORM bez wątpienia odegrała (i nadal odgrywa) ważną rolę w rozwoju narzędzi programistycznych, pokazała, że programista tak naprawdę nie musi dbać o logikę przechowywania danych. Jednak tutaj, podobnie jak wszędzie, jest „ALE”.Zastosowanie ORM niewątpliwie przyspiesza rozwój produktu, obniża koszty pracy i bla bla bla. Jednak każdy ORM jest rodzajem warstwy, która zawsze będzie działać wolniej niż praca bezpośrednia (wcale nie wzywam do przenoszenia wszystkich wywołań zapytań SQL do aplikacji - wszędzie powinien być złoty środek). Obecność ORM pozwala programistom nie myśleć zbyt wiele o działaniu DBMS (i w większości nie myślą), co pociąga za sobą, delikatnie mówiąc, nie do końca optymalne działanie aplikacji pod obciążeniem. Aby zoptymalizować, trzeba rękami wejść do warstwy i skonfigurować zapytania tak, aby zaczęły działać szybciej, trzeba wejść do bazy danych i przekonfigurować indeksy i tabele. Zatem dla optymalnego działania aplikacji należy włożyć więcej wysiłku niż w przypadku braku ORM. Dzięki temu obniżamy koszty rozwoju i przyspieszamy wydanie pierwszej wersji produktu, ale komplikujemy proces optymalizacji.
Jednak nikt nie myśli o optymalizacji w momencie pisania pierwszej (a często drugiej i trzeciej) wersji produktu. Dla większości firm głównym czynnikiem jest teraz nie jakość, ale szybkość rozwoju. To zrozumiałe: początkowo klient chce otrzymać produkt jak najwcześniej, wydając minimum pieniędzy. I dopiero po pewnym czasie, gdy baza danych jest wypełniona prawdziwymi danymi, mija kilka miesięcy, klient (a także programista) ze zdziwieniem stwierdza, że czas próbkowania prawie się podwoił, gdy w firmie pracuje 10-20 użytkowników. w tym samym czasie DBMS próbuje popełnić samobójstwo itp. . itp. Deweloper często kieruje się mądrością Wschodu: I tam albo osioł umrze, albo sułtan, albo sam Khoja. Ale jeśli nikt nie umarł, to tutaj programista zaczyna szukać wąskich gardeł, wyrzuca automatycznie generowane zapytania z ORM, przepisuje je ręcznie, przebudowuje indeksy w tabelach bazy danych i poświęca dużo czasu i wysiłku na to i podobne optymalizacja.
Coś odciągnęło mnie na bok. Mam nadzieję, że wystarczająco jasno przedstawiłem swoje stanowisko w sprawie ORM. Wróćmy do porównania (lub, jak kto woli, opozycji) relacyjnych i obiektowych baz danych.
Relacyjne bazy danych a OODB
Pomimo ogromnej popularności paradygmatu OOP w programowaniu, paradygmat ten nie jest jeszcze zbyt popularny w technologii tworzenia baz danych. Istnieją ku temu zarówno obiektywne, jak i subiektywne powody.- Popularność. Stworzono wiele wspaniałych produktów dla relacyjnych baz danych, które należy utrzymywać i rozwijać. W te produkty zainwestowano już dużo pieniędzy, a klienci są gotowi zainwestować więcej pieniędzy w ich rozwój. Wręcz przeciwnie, stosunkowo niewiele poważnych produktów komercyjnych zostało opracowanych przy użyciu OODB, istnieje niewiele potężnych OODBMS.
- Język zapytań i jego standaryzacja. Już w 1986 roku przyjęto pierwszy standard SQL-86, który zdeterminował losy relacyjnych baz danych. Po przyjęciu standardu wszyscy twórcy relacyjnych DBMS byli zobowiązani do jego przestrzegania. W przypadku baz danych zorientowanych obiektowo nie ma jeszcze standardowego języka zapytań. Obecnie nie ma nawet konsensusu wśród programistów co do tego, co powinien robić ten język zapytań, nie mówiąc już o tym, jak powinien to robić.
- Aparat matematyczny. Kiedyś w przypadku relacyjnych baz danych Edgar Codd położył podwaliny pod matematyczny aparat algebry relacyjnej. Ta mata. aparat wyjaśnia, jak należy wykonać podstawowe operacje na relacjach w bazie danych, dowodzi ich optymalności (lub pokazuje, gdzie należy optymalizować). Z drugiej strony nie ma takiego aparatu dla OODB, mimo że prace w tym obszarze trwają od lat 80-tych. W związku z tym w OODB nie ma jeszcze ścisłych terminów, takich jak produkt kartezjański, relacja itp.
- Problem przechowywania danych i metod. Relacyjne bazy danych przechowują tylko same dane. To, co aplikacja z nimi zrobi, zależy od aplikacji. W OODB wręcz przeciwnie, obiekty powinny być przechowywane, a obiekt jest zbiorem jego właściwości (parametry obiektu) i metod (interfejs obiektu). Nie ma również zgody co do tego, w jaki sposób OODB powinno przechowywać obiekty oraz jak programista powinien opracowywać i projektować te obiekty. Tutaj również pojawia się problem przechowywania hierarchii obiektów, przechowywania klas abstrakcyjnych itp.
Wnioski i perspektywy
W świetle obecnej sytuacji w świecie deweloperskim perspektywa poważnych i popularnych rozwiązań wykorzystujących OODB wydaje się bardzo wątpliwa (ale nie mniej pożądana), dopóki nie zostaną rozwiązane podstawowe kwestie (aparat mat i standard języka zapytań). Jako programista trochę mnie to zasmuca, ponieważ doszedłem do wniosku, że obecność potężnego i wygodnego OODB jest po prostu niezbędna do dalszego jakościowego rozwoju narzędzi do tworzenia baz danych.Jeśli chodzi o perspektywy relacyjnych baz danych, to wierzę, że będą one żyły dość długo. OODB nadal nie będzie w stanie w pełni zastąpić relacyjnych baz danych. W niektórych rzeczywistych zadaniach nadal wygodniejsze i poprawne jest przechowywanie danych nie w obiektach, ale w tabelach.
Dlatego wierzę, że z biegiem czasu OODB odzyska część rynku systemów komercyjnych z relacyjnych baz danych, ale nie może osiągnąć tak całkowitej przewagi, jaką obecnie mają relacyjne bazy danych.
