Modele architektury baz danych: modele hierarchiczne, sieciowe i relacyjne

Niektóre modele architektury bazy danych są następujące:

Proces definiowania projektu koncepcyjnego elementów danych i ich wzajemnych zależności nazywany jest modelowaniem danych. Tradycyjne podejście do organizacji danych stworzyło różne modele dla każdego pliku danych.

Zdjęcie dzięki uprzejmości: ysma.gr/static/images/6_4_DBinput.jpg

Taka różnorodność sposobów łączenia i przechowywania różnych elementów danych w plikach danych sprawia, że ​​pliki te są odpowiednie tylko dla aplikacji, dla których zostały pierwotnie stworzone. W rzeczywistości szczegóły dotyczące dokładnego umieszczania różnych elementów danych w pliku muszą być bardzo starannie dokumentowane.

Każda zmiana w kolejności wprowadzania różnych elementów danych powoduje zmiany w aplikacjach przy użyciu pliku danych. Podejście bazodanowe wykorzystuje wspólny model danych dla całej bazy danych, a program użytkownika nie zajmuje się umieszczeniem określonego elementu danych. System zarządzania bazami danych (DBMS) działa jako interfejs między bazą danych a programami użytkownika.

DBMS pobiera dane z bazy danych i udostępnia je programowi użytkownika. Ta funkcja oferuje zaletę niezależności danych w podejściu do bazy danych.

Koncepcyjnie istnieją trzy szerokie opcje w odniesieniu do modeli baz danych. To są:

za. Hierarchiczny model

b. Model sieciowy

do. Model relacyjny

(a) Hierarchiczny model:

Model ten przedstawia dane użytkownikom w hierarchii elementów danych, które można przedstawić w postaci odwróconego drzewa. W systemie przetwarzania zleceń klienta klient może otrzymać wiele faktur, a każda faktura może mieć inne elementy danych. Tak więc głównym poziomem danych jest klient, drugim poziomem jest faktura, a ostatnim poziomem są elementy zamówienia, takie jak numer faktury, data, produkt, ilość itp.

Ta struktura jest dość naturalna, gdy widzi się ją z punktu widzenia zdarzenia. Jednak niższe poziomy są własnością elementów danych wyższego poziomu, a elementy na tym samym poziomie nie mają żadnego powiązania. W rezultacie kwerenda taka jak produkty zakupione przez klienta, w powyższym przykładzie, będzie trudna do przeprowadzenia w strukturze hierarchicznej.

Zapytanie, który klient zakupił dany produkt, byłoby wygodne. Zatem tam, gdzie istnieje wiele do wielu relacji między dwoma jednostkami, model ten nie byłby odpowiedni. Rysunek 9.4 przedstawia hierarchiczny model danych dla aplikacji przetwarzania zamówień sprzedaży.

(b) Model sieciowy:

W modelu sieciowym bazy danych nie ma poziomów, a rekord może mieć dowolną liczbę właścicieli, a także może być właścicielem kilku rekordów. Dlatego problem podniesiony powyżej w przetwarzaniu zlecenia klienta nie powstaje w modelu sieciowym.

Ponieważ nie ma określonej ścieżki zdefiniowanej dla pobierania danych, liczba łączy jest bardzo duża, a zatem sieciowe bazy danych są złożone, powolne i trudne do wdrożenia. Ze względu na trudności w implementacji model sieciowy jest używany tylko wtedy, gdy wszystkie inne opcje są zamknięte.

Typowym przykładem sieciowej bazy danych może być pracownik i dział, z którym pracował lub może pracować w przyszłości. Rysunek 9.5 pokazuje model sieci danych dla systemu informacji o pracownikach.

(c) Model relacyjny:

Najnowszym i popularnym modelem projektowania baz danych jest relacyjny model bazy danych. Model ten został opracowany w celu przezwyciężenia problemów złożoności i braku elastyczności wcześniejszych dwóch modeli w obsłudze baz danych zawierających wiele do wielu relacji między podmiotami.

Te modele są nie tylko proste, ale i potężne. W relacyjnej bazie danych każdy plik jest postrzegany jako plik płaski (tabela dwuwymiarowa) składający się z wielu linii (rekordów), przy czym każdy rekord ma klucz i element danych inny niż klucz. Kluczowymi elementami są elementy danych identyfikujące rekord. Rysunek 9.6 pokazuje pliki i pola każdego rekordu w systemie fakturowania klienta.

W tych plikach kluczowe elementy danych to identyfikator klienta, nr faktury i kod produktu. Każdy z plików może być używany osobno do generowania raportów. Jednak dane można również uzyskać z dowolnej kombinacji plików, ponieważ wszystkie te pliki są ze sobą powiązane za pomocą kluczowych elementów danych określonych powyżej.

Jest to podstawowa zaleta relacyjnego modelu bazy danych wraz z jej prostotą i solidnością.

Model relacyjny w dużej mierze opiera się na pracy EF Codda, który identyfikuje cechy dobrej relacyjnej bazy danych w następujący sposób:

a) Wszystkie informacje są logicznie reprezentowane jako tabele, a dostęp do danych jest możliwy dzięki nazwom pól. Zatem kolejność, pozycja lub powiązanie plików nie budzą zaniepokojenia użytkowników.

b) Słownik danych zawiera informacje dotyczące struktury bazy danych, w tym typu danych; rozmiar itp., definicje, relacje i uprawnienia dostępu. Uprawnieni użytkownicy mogą dowiedzieć się o środowisku bazy danych i zmienić środowisko przy użyciu języka opisu danych (DDL).

c) Język manipulacji danymi (DML) jest dostępny dla użytkowników, w tym dla programistów do tworzenia, wstawiania, modyfikowania, wyszukiwania, organizowania i usuwania dowolnej części bazy danych. Te manipulacje są możliwe zarówno na poziomie rekordowym, jak i dla całego pliku, dając elastyczność w definiowaniu uprawnień dostępu dla różnych kategorii użytkowników.

d) Jakakolwiek modyfikacja struktury bazy danych pod względem podziału tabeli w poziomie lub w pionie nie powinna mieć żadnego wpływu na logikę programu przy użyciu bazy danych. Ta niezależność danych jest podstawową zaletą relacyjnego modelu bazy danych.

e) Rozpowszechniana niezależność danych to kolejna cecha dobrej relacyjnej bazy danych. Programy użytkownika nie wymagają żadnych zmian, gdy dane są najpierw dystrybuowane lub redystrybuowane. Faktyczna fizyczna lokalizacja danych nie ma znaczenia dla użytkownika, o ile to pole jest wyświetlane w słowniku danych jako lokalne.

Jak można zauważyć na ryc. 9.6, żadne z pól nie jest powszechne w żadnym z dwóch plików poza kluczem. Tak więc w tym modelu można uniknąć redundancji danych. W tym celu podczas projektowania struktury bazy danych podejmowany jest proces normalizacji danych.