Założenia relacyjnego modelu baz danych
W 1970 roku doktor E.F. Codd opublikował pracę zatytułowaną "A Relational Model of Data for Large Shared Data Banks", w której proponował prezentowanie danych w postaci zestawu tabel. Zamiast wskaźników używanych do poruszania się między powiązanymi encjami, nadmiarowe dane mają być używane do łączenia rekordów w różnych tabelach.
W modelu relacyjnym dane są prezentowane przez zbiory krotek (pól tabel), do których dostęp zapewniają operatory algebry relacji, takie jak selekcja, projekcja czy suma.
Każda tabela w relacyjnej bazie danych zawiera informacje unikatowo identyfikujące rekord w danej tabeli (tzw. klucz podstawowy) oraz informacje dodatkowe niezbędne do pełnego opisania encji.
Każdy serwer bazy danych dostarcza mechanizm pozwalający na generowanie unikatowych zbiorów liczb używanych jako wartości klucza podstawowego. Dlatego nie trzeba zajmować się sprawdzaniem, jaki liczby zostały przypisane jako klucze podstawowe.
E.F. Codd określił 12 podstawowych zasad, które musiał spełniać system, by mógł zarządzać relacyjnym modelem danych.
Postulaty dotyczące struktury danych
Spełnienie postulatów dotyczących struktur danych pozwala w ten sam sposób, niezależnie od wykorzystywanego serwera bazodanowego, zarządzać przechowywanymi w bazie informacjami. Do tych postulatów należą:
- Postulat informacyjny - Informacje są reprezentowane w postaci logicznych tabel. Oznacza to, że fizyczny sposób organizacji i przechowywania danych przez serwer bazodanowy nie może mieć wpływu na działanie programów klienckich.
- Postulat dostępu - Każda informacja musi być dostępna za pomocą nazwy tabeli, kolumny i wartości klucza podstawowego. Innymi słowy, znajomość struktury tabeli i wartości identyfikatorów musi wystarczyć do odczytania dowolnej informacji z bazy.
- Postulat fizycznej niezależności danych - Sposób przechowywania danych i wewnętrzne mechanizmy dostępu do nich przez serwer nie mogą mieć wpływu na aplikacje klienckie. Na przykład to, czy dane są przechowywane w jednym pliku, czy w wielu plikach, dla programów klienckich musi być całkowicie niewidoczne.
- Postulat logicznej niezależności danych - Zmiany w strukturze bazy danych, np. zmiana definicji tabeli, o ile tylko nie powodują utraty informacji i są poprawne semantycznie, nie mogą mieć wpływu na aplikację kliencką.
- Postulat niezależności dystrybucyjnej - Odwołania do danych za pomocą języka SQL muszą być niezależne od fizycznej lokalizacji danych. Innymi słowy, aplikacje klienckie powinny mieć taki sam dostęp do danych znajdujących się na lokalnym dysku twardym jak do danych rozproszonych pomiędzy różne lokalizacje.
- Postulat zabezpieczenia przed modyfikacjami przeprowadzanymi za pomocą języków proceduralnych - Jeśli serwer bazodanowy umożliwia bezpośrednie modyfikowanie poszczególnych rekordów za pomocą języków niższego poziomu, zmiany te nie mogą naruszać spójności danych, w szczególności nie mogą być sprzeczne z nałożonymi na tabele ograniczeniami.
- Postulat pełnego języka danych - Serwer baz danych musi implementować jeden język pozwalający definiować tabele, widoki i ograniczenia (więzy spójności), zarządzać dostępem użytkowników i transakcjami oraz odczytywać i modyfikować dane.
- Postulat modyfikowania bazy danych przez widoki - Zmiany danych przeprowadzane poprzez widoki muszą być odzwierciedlane w odpowiednich tabelach, a bezpośrednie zmiany danych w tabelach muszą być automatycznie widoczne poprzez widoki.
- Postulat modyfikowania danych na wysokim poziomie abstrakcji - Odczytanie, zmodyfikowanie, wstawienie lub usunięcie danych musi być możliwe za pomocą pojedynczej operacji.
- Postulat wartości NULL - Serwer bazodanowy w spójny sposób przetwarza specjalną wartość NULL, jak brakującą informację. a nie jak zero czy pusty ciąg znaków ("").
- Postulat słownika danych - Metadane (informacje o strukturze bazy danych) są przechowywane i udostępniane tak samo (w postaci tabel) jak zapisane w bazie informacje.
- Postulat niezależności ograniczeń - Ograniczenia (więzy spójności) muszą być definiowane w tym samym języku SQL i przechowywane po stronie bazy danych, a więc nie jest obowiązkowe implementowanie ich po stronie aplikacji klienckiej. Serwer baz danych musi umożliwić zdefiniowanie przynajmniej dwóch typów ograniczeń:
- ograniczenia klucza podstawowego, które gwarantują spójność w ramach tabel.
- ograniczenia klucza obcego, które gwarantują spójność danych zapisanych w powiązanych tabelach.
Brak komentarzy:
Prześlij komentarz