Postulaty Codd'a dotyczące relacyjnych baz danych. Rodzaje kluczy, zasady dobierania kluczy. Powiązania pomiędzy relacjami

1. Postulaty Codd'a dotyczące relacyjnych baz danych

  1. postulat informacyjny - dane są reprezentowane jedynie przez wartości atrybutów w wierszach tabel (w krotkach)
  2. postulat dostępu - każda wartość w bazie danych jest dostępna poprzez podanie nazwy tabeli, atrybutu i wartości klucza podstawowego (głównego)
  3. postulat dotyczący wartości NULL - dostępna jest specjalna wartość NULL dla reprezentacji zarówno wartości nieokreślonej, jak i nieadekwatnej, inna od wszystkich i podlegająca przetwarzaniu
  4. postulat dotyczący katalogu - wymaga się, aby system obsługiwał wbudowany katalog relacyjny z bieżącym dostępem dla uprawnionych użytkowników używających języka zapytań
  5. postulat języka danych - system musi dostarczać pełny język przetwarzania danych, który może być używany zarówno w trybie interaktywnym, jak i w obrębie programów, obsługuje operacje definiowania danych, operacje manipulowania danymi, ograniczenia związane z bezpieczeństwem i integralnością oraz operacje zarządzania transakcji
  6. postulat modyfikowalności perspektyw - system musi umożliwiać modyfikowanie perspektyw, o ile jest ono semantycznie realizowalne.

Semantykę bazy danych określa się, opisując zbiór legalnych stanów, czyli ograniczając dozwoloną zawartość tabel. Operacje modeluje się jako funkcje: operacja: stan->stan. Operacje powinny przeprowadzać legalne stany w legalne stany. Jednak w czasie wykonywania powiązanego ciągu operacji przejściowo baza danych może przyjmować nielegalne stany. Takie ciągi obudowujemy transakcjami i traktujemy transakcje jako niepodzielne operacje.

  1. postulat modyfikowalności danych - system musi umożliwiać operacje modyfikacji danych, musi obsługiwać operacje INSERT, UPDATE oraz DELETE
  2. postulat fizycznej niezależności danych - zmiany fizycznej reprezentacji danych i organizacji dostępu nie wpływają na aplikacje
  3. postulat logicznej niezależności danych - zmiany wartości w tabelach nie wpływają na aplikacje
  4. postulat niezależności więzów spójności - więzy spójności są definiowane w bazie i nie zależą od aplikacji
  5. postulat niezależności dystrybucyjnej - działanie aplikacji nie zależy od modyfikacji  i dystrybucji bazy
  6. postulat bezpieczeństwa względem operacji niskiego poziomu - operacje niskiego poziomu nie mogą naruszać modelu relacyjnego i więzów spójności

2. Terminologia wykorzystywana w modelu relacyjnym baz danych - podsumowanie

Relacja w ujęciu formalnym to tabela posiadająca kolumny i wiersze, w ujęciu matematycznym, każdy podzbiór iloczynu kartezjańskiego zbiorów, w ujęciu intuicyjnym - powiązanie pomiędzy tabelami.

Atrybut (pole) - kolumna relacji opatrzona nazwą. Atrybuty mogą się pojawić w relacji w dowolnej kolejności bez wpływu na znaczenie relacji. Z każdym atrybutem związana jest para (nazwa atrybutu, typ danych).

Dziedzina - zbiór dopuszczalnych wartości dla jednego lub większej liczby atrybutów.

Krotka - wiersz relacji (rekord).

Stopień (krotność) relacji - liczba atrybutów relacji.

Moc relacji  - ilość (liczba) krotek, które znajdują się w relacji.

Relacyjna baza danych - zbiór znormalizowanych relacji o różnych nazwach (relacyjny system zarządzania bazą danych określa jedynie, że taka baza jest dla użytkownika zbiorem relacji (tabel), czyli odnosi się do warstwy konceptualnej i zewnętrznej modelu ANSI).

Encja (ang. entity) jest rzeczą lub obiektem mającym dla nas znaczenie rzeczywiste bądź wyobrażone, o którym informacje muszą być znane lub przechowywane. Nazwa encji powinna być podana w liczbie pojedynczej i zapisana WIELKIMI LITERAMI. Encją może być:

  • obiekt fizyczny (np. samochód, bilet lotniczy)
  • obiekt niematerialny (np. konto bankowe, zamówienie)
  • zdarzenie (np. urlop pracownika, sprzedaż samochodu)
  • istniejący fakt (np. znajomość języków obcych)

3. Własności relacji

Relacyjna baza danych jest zbiorem relacji o następujących własnościach:

  • każda relacja (tabela) w bazie danych jest jednoznacznie określona przez swoją nazwę.
  • każda kolumna w relacji (atrybut) ma jednoznaczną nazwę w ramach tej relacji.
  • kolumny relacji tworzą zbiór nieuporządkowany, mogą być wpisywane w dowolny sposób.
  • wszystkie wartości w danej kolumnie muszą być tego samego typu (pochodzić z tej samej dziedziny).
  • każdy wiersz (krotka) jest inny - nie ma duplikatów krotek.
  • teoretycznie, kolejność wierszy nie ma znaczenia ( w praktyce może mieć to wpływ na efektywność wyszukiwania odpowiednich grup krotek).
  • każde pole (przecięcie kolumny z wierszem) zawiera wartość elementarną (atomową) z dziedziny określonej przez kolumnę. Brakowi wartości odpowiada wartość specjalna NULL, zgodna z każdym typem kolumny (chyba że została jawnie wykluczona przez definicję typu kolumny).
  • każda relacja zawiera klucz główny (podstawowy) - kolumnę (lub kolumny), której wartości jednoznacznie identyfikują wiersz (a więc w szczególności nie powtarzają się). Wartością klucza głównego nie może być NULL. Każda tabela musi mieć dokładnie jeden klucz główny.

4. Rodzaje kluczy

  1. superklucz (ang. superkey) - kolumna lub zestaw kolumn jednoznacznie identyfikujących każdą krotkę w tabeli
  2. klucz podstawowy (główny) (PRIMARY KEY) - klucz wybrany przez projektanta bazy danych, aby unikatowo identyfikować krotki tabeli
  3. klucz kandydujący (potencjalny), zwany w skrócie kluczem
  4. klucz obcy - klucz w podrzędnej tabeli powiązany z kluczem głównym w nadrzędnej tabeli celem zapewnienia integralności referencyjnej bazy danych
  5. klucz prosty - klucz oparty na jednej kolumnie
  6. klucz złożony - klucz oparty na wielu kolumnach
  7. klucz sztuczny - pole sztucznie wprowadzone do relacji, aby stał się kluczem podstawowym

5. Właściwości klucza głównego

  1. trwałość - pole kluczowe nie może być puste i nie może zawierać wartości NULL
  2. unikatowość - dane w polu kluczowym nie mogą się powtarzać (indeksowanie bez powtórzeń)
  3. stabilność - dane w polu kluczowym nie mogą się zmienić; nie powinno się jako klucz głównych używać kolumn przechowujących dane nietrwałe (np. numer telefonu - może się zmienić lub zostać przypisany innej osobie)
  4. nieredukowalność - żaden podzbiór właściwy pól tworzących pole klucza nie jest kluczem

Tabela może zawierać więcej niż 1 klucz, ale jeden klucz podstawowy. Atrybuty, które należą do któregoś z kluczy, nazywać będziemy atrybutami kluczowymi, a te, które nie należą do żadnego z kluczy - atrybutami niekluczowymi.

Jedna myśl nt. „Postulaty Codd'a dotyczące relacyjnych baz danych. Rodzaje kluczy, zasady dobierania kluczy. Powiązania pomiędzy relacjami

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.