Relacyjne bazy danych. Koncepcja relacyjnej bazy danych
Relacyjna baza danych to baza danych oparta na relacyjnym modelu danych (RDM).
RMD opiera się na pojęciu relacji, czyli relacji (relacja - relacja, j. ang., stąd określenie relacyjne bazy danych). Do pracy z relacyjnymi bazami danych używane są relacyjne systemy DBMS. Stosowanie relacyjne bazy danych dane zostały zaproponowane przez dr Codda z IBM w 1970 roku. Modele te charakteryzują się prostotą struktury danych, przyjazną dla użytkownika reprezentacją tabelaryczną oraz możliwością wykorzystania aparatu formalnego algebry relacyjnej i rachunku relacyjnego do przetwarzania danych.
W RMBD główną jednostką strukturalną jest tabela (relacja). Model relacyjny koncentruje się na organizowaniu danych w postaci dwuwymiarowej stoły. Każda tabela relacyjna jest tablica dwuwymiarowa i ma następujące nieruchomości:
Każdy element tabeli to jeden element danych;
Wszystkie kolumny w tabeli są jednorodne, tj. wszystkie elementy w kolumnie mają ten sam typ (liczbowy, znakowy itp.) i długość;
Każda kolumna ma unikalną nazwę;
W tabeli nie ma identycznych wierszy;
Kolejność wierszy i kolumn może być dowolna.
Zależności przedstawiono w formie tabel, których wiersze odpowiadają dokumentacja, a kolumny są atrybuty relacje, domeny, pola. Każda linia przechowuje dane o jednym obiekcie, a każde pole charakteryzuje jeden z parametrów obiektu. Każda tabela musi mieć unikalną nazwę bazy danych.
Wywoływane jest pole, którego każda wartość jednoznacznie identyfikuje odpowiedni rekord prosty klucz (pole kluczowe). Jeśli rekordy są jednoznacznie identyfikowane przez wartości kilku pól, wówczas taka tabela bazy danych ma klucz złożony. Jeśli takiego pola nie ma, to trzeba je wprowadzić sztucznie. Aby połączyć dwie tabele relacyjne, należy dołączyć klucz pierwszej tabeli jako część klucza drugiej tabeli (klucze mogą się pokrywać); w przeciwnym razie należy wprowadzić klucz obcy do struktury pierwszej tabeli - klucz drugiej tabeli.
32 Podstawowe modele baz danych (DB)
DB– ustrukturyzowany zbiór informacji związanych z jednym Tematyka lub kilka powiązanych obszarów. Można na nim budować wszystkie istniejące bazy danych różne zasady, które charakteryzują się koncepcją modelu bazy danych.
Model bazy danych określa sposób komunikacji pomiędzy obiektami w bazie danych, sposób przechowywania informacji na nośniku (w pamięci komputera) oraz sposób wyszukiwania i prezentacji danych. Modele bazy danych: 1) hierarchiczny, 2) sieciowy, 3) relacyjny.
1) Hierarchiczny ( Pierwszy podłoga. 60.) przeznaczony był do przechowywania baz danych na papierze i taśmach magnetycznych. Struktura komunikacji pomiędzy danymi opiera się na teorii grafów i jest prezentowana w formie drzewa (odwróconego). Różnica tworzone są obiekty węzły drzewa, tj. są na różnych poziomy hierarchii. Znajomości opisywanych w kategoriach ojciec-syn lub przodek-potomek. Każdy węzeł i-tego poziomu hierarchii odnosi się do węzła poziomu i-1 (i>1), tak jak syn odnosi się do ojca, albo ojciec do syna, czyli syn może mieć jednego ojca , a ojciec może mieć jednego lub więcej synów, tj. . obiekt danego i-tego poziomu odnosi się do obiektów poziomu i+1 tak, jak 1 odnosi się do wielu (1:N, 1:∞). Wady: 1) użytkownik musi znać strukturę drzewa, w przeciwnym razie wyszukiwanie danych będzie utrudnione; 2) wymagane wyszukiwanie. Dane zawsze zaczynają się od korzenia, a następnie nawigacja odbywa się wzdłuż gałęzi drzewa.
2) Sieć(druga połowa lat 60-tych) w celu zmniejszenia wpływu niedociągnięć poprzedniego modelu. Podstawowy różnica z hierarchicznego: może istnieć połączenie pomiędzy obiektami znajdującymi się zarówno na tym samym poziomie hierarchii, jak i na różnych. Doprowadziło to do wzrostu szybkości wyszukiwania danych. Jednak istota wada: Użytkownik musi znać strukturę takiego drzewa.
Podstawowy brak dwóch modeli: bardzo słaba podstawa matematyczna.
3) Relacyjny, która opiera się na rozwiniętym aparacie dwóch działów matematyki: teorii relacji (zbiorów) i teorii predykatów. Teoria mnogości wiąże się z formalizacją procedur analizy warunków logicznych. Istnieje w nim dwuwymiarowy zbiór, który nazywa się relacją (relacją). W tym modelu podstawowa jednostka strukturalna jest tabelą (relacją). Każda tabela musi mieć unikalną dla tej bazy danych nazwę w języku rosyjskim lub łac. listy
Relacyjny baza komputerowa, jak każda inna baza, jest IS, schematycznie przedstawionym:
DBMS(system zarządzania DB) – specjalistyczny narzędzie programowe(shell) lub platforma, za pomocą której użytkownik realizuje na danych wszystkie udostępnione mu funkcje (operacje). Funkcje: wprowadzanie (wstawianie), modyfikacja (zmiana), ekstrakcja (wybór), usuwanie danych.
ISDB posiada ważny element – administratora bazy danych, który odpowiada za bezpieczeństwo i wartość danych, ustanawiając różne. prawa dostępu użytkowników itp.
Każda tabela składa się z pól i wierszy. Każda linia przechowuje dane o jednym obiekcie i każde pole znak jest jednym z parametrów (atrybutów) tego obiektu. W osobnym polu m.b. dane są tylko jednym typem. Jeden z atrybutów lub pól musi zidentyfikować każdy obiekt w tabeli. Oznacza to, że pole to nie powinno zawierać zduplikowanych wartości (każda wartość jest unikalna). Jeżeli warunek ten zostanie spełniony, pole to nazywa się kluczem(klucz danych tabeli). Każda tabela musi mieć pole kluczowe. Klucz ten nazywany jest kluczem głównym. Jeśli klucz składa się z wartości więcej niż jednego pola, nazywa się go kluczem złożonym. Preferowany jest prosty klucz. Jeżeli go nie ma, to wprowadza się go sztucznie (na przykład liczbę).
Model relacyjny
Model relacyjnej bazy danych został zaproponowany w 1969 roku przez matematyka i badacza IBM E.F. Codd (EF Codd). Podstawowe informacje na temat relacyjnych baz danych można znaleźć w artykule przeglądowym „ DB i DBMS" 2. Ponieważ obecnie dominują relacyjne bazy danych, w tym artykule (jak również w artykułach " opis danych”, “Przetwarzanie danych" I " Projekt bazy danych” 2) szczegółowo omówiono najważniejsze pojęcia modelu relacyjnego.
Od razu zauważmy, że teoria relacyjnych baz danych była początkowo sformułowana w sposób ścisły język matematyczny, a dokładnie ścisłe, formalnie zdefiniowane pojęcia matematyczne Najlepszym sposobem opisać istotę rzeczy. Jednocześnie w większości przypadków da się, bez większych szkód, poświęcić rygor terminologii na rzecz przejrzystości prezentacji, co postaramy się zrobić.
Główna idea modelu relacyjnego jest następująca. Baza danych składa się z szeregu nieuporządkowanych stoły(w najprostszym przypadku - z jednej tabeli). Tabele można manipulować za pomocą operacji nieproceduralnych (deklaratywnych) - upraszanie, których wyniki są również tabelami.
Często słowo „relacyjny” ( relacyjny) w pojęciu „model relacyjny” interpretuje się w oparciu o fakt, że w relacyjnej bazie danych nawiązywane są połączenia ( odnieść się) między stołami. To wyjaśnienie jest wygodne, ale nie jest dokładne. W oryginalny system Warunki połączenia Codd ( relacje), atrybuty ( atrybuty) i krotki ( krotki) były używane tam, gdzie większość z nas używa bardziej znanych terminów: tabele, kolumny (pola) i wiersze (rekordy).
Budując model informacyjny obszaru tematycznego (patrz „ DB i DBMS”, “Projekt bazy danych” 2) wyróżniać się istota(obiekty), opisz je nieruchomości a (cechy, atrybuty) niezbędne do celów modelowania i ustanawiane są powiązania pomiędzy jednostkami. Na etapie przejścia od modelu relacyjnego infologicznego do danychlogicznego pojawiają się tabele. Zazwyczaj każda jednostka jest reprezentowana przez jedną tabelę. Każdy wiersz tabeli (jeden rekord) odpowiada jednej instancji encji, a każde pole opisuje pewną właściwość (atrybut).
Na przykład, jeśli musimy przechowywać informacje o osobach, w tym nazwisko każdej osoby, imię, nazwisko rodowe, NIP, kraj zamieszkania i datę urodzenia, wówczas podmiotem jest osoba, a określone dane są atrybutami. Sama jednostka w naturalny sposób staje się nazwą tabeli.
Stół „Człowiek”
Model relacyjny wymaga, aby każdy wiersz w tabeli był unikalny, tj. tak, aby dowolne dwa wiersze różniły się wartością przynajmniej jednego atrybutu.
Tradycyjna forma tabelaryczna przydaje się, gdy trzeba przedstawić same dane. Jeśli tak jak w powyższym przykładzie interesuje Cię tylko Struktura- nazwy pól, to z punktu widzenia przejrzystości, łatwości użycia na diagramach i oszczędności miejsca wygodniej jest przedstawić to w następujący sposób:
Klucze
Klucz stołyto pole lub grupa pól zawierająca unikalne wartości w obrębie danej tabeli. Klucz jednoznacznie identyfikuje odpowiedni wiersz tabeli. Jeśli klucz składa się z pojedynczego pola, często jest on wywoływany prosty, jeśli z kilku - złożony. W powyższym przykładzie kluczem jest pole NIP (zakładamy, że wiadomo, że NIP jest unikalny w obrębie kraju).
Spójrzmy na przykład tabeli z kluczem złożonym. Serwisy z prognozami pogody często prezentują informacje w następujący sposób: dla każdej daty podana jest przewidywana temperatura w nocy, rano, po południu i wieczorem. Aby zapisać te informacje, możesz użyć takiej tabeli:
W tej tabeli ani pola Data, Godzina, ani Temperatura nie są kluczami - wartości mogą się powtarzać w każdym z tych pól. Jednak kombinacja pól Data i godzina jest unikalna i jednoznacznie identyfikuje wiersz tabeli. To jest klucz złożony.
Często zdarzają się sytuacje, w których wybór klucza nie jest jednoznaczny. Wróćmy do pierwszego przykładu. Załóżmy, że oprócz nazwiska, imienia, patronimiki, NIP, daty urodzenia wymagane jest przechowywanie serii i numeru paszportu ogólnego oraz serii i numeru paszportu zagranicznego. Tabela będzie wyglądać następująco:
W tej tabeli możesz wybrać aż trzy klucze. Jeden z nich jest prosty (NIP), pozostałe dwa są złożone (Seria + numer paszportu ogólnego i Seria + numer paszportu zagranicznego). W takiej sytuacji programista wybiera klucz, który jest najwygodniejszy z punktu widzenia organizacji bazy danych (ogólnie taki klucz, którego znalezienie wartości zajmuje najmniej czasu). Wybrany klucz w tym przypadku często nazywany jest kluczem głównym lub podstawowy, klucz i inne kombinacje kolumn, z których można utworzyć klucz, to możliwy lub alternatywne klucze. Należy pamiętać, że w tabeli zawsze znajduje się co najmniej jeden możliwy klucz, ponieważ wiersze nie mogą się powtarzać, a zatem kombinacja wszystkich kolumn jest gwarantowana możliwy klucz.
Podczas przedstawiania tabel zwyczajowo podkreśla się klucze podstawowe tabel. Na przykład odpowiednie pola są często podkreślane. A Dostęp Microsoftu Wyróżnia kluczowe pola pogrubioną czcionką.
Jeszcze częściej niż w przypadku niejednoznaczności w wyborze klucza programiści stają w obliczu braku klucza wśród danych, które należy przechowywać. Podobny fakt można stwierdzić w procesie analizy obszaru tematycznego. Na przykład, jeśli chcesz przechowywać prostą listę osób - imiona, nazwiska, patronimiki i daty urodzenia, to w tym zestawie atrybutów w ogóle nie ma klucza - możliwa jest sytuacja, gdy dwie różni ludzie Podane dane pokrywają się całkowicie. W takim przypadku trzeba sztucznie wprowadzić dodatkowe pole, np. unikalny numer osoby. Taki klucz jest czasami nazywany w literaturze surogat. Często klucz zastępczy wprowadza się ze względu na wydajność. Jeśli na przykład tabela ma długi klucz złożony, programiści często wprowadzają dodatkowy krótki numeryczny klucz zastępczy i czynią go kluczem podstawowym. Często się to robi, nawet jeśli tak jest prosty klucz, posiadający „niewygodny” (nieskuteczny przy wyszukiwaniu) typ danych, na przykład string. Takie operacje nie mają już znaczenia w teorii, ale często spotyka się je w praktyce.
Uważny czytelnik może zauważyć, że klucz prawie zawsze można rozszerzyć (chyba, że obejmuje wszystkie pola tabeli) poprzez dodanie pól zbędnych. Formalnie taki klucz pozostanie kluczem, ale z praktycznego punktu widzenia jest to tylko gra pojęć. Takie klucze nie są nawet uważane za możliwe, ponieważ zawsze należy dążyć do zminimalizowania długości (złożoności) klucza.
Formy normalne, normalizacja
Nie każda tabela, którą możemy narysować na papierze lub w programie Word, może być tabelą relacyjnej bazy danych. I nie każda tabela, którą można zastosować w relacyjnej bazie danych, jest poprawna z punktu widzenia wymagań modelu relacyjnego.
Po pierwsze, wymaga, aby wszystkie dane w tej samej kolumnie były tego samego typu(o typach zobacz“opis danych” 2). Z tego punktu widzenia poniższy przykład nie ma nawet sensu omawiać:
Po drugie, wymaga, aby tabela miała przypisany klucz podstawowy.
Wymagania te są konieczne, ale niewystarczające. Teoria relacyjnych baz danych wprowadza pojęcia tzw. „form normalnych” – wymagań dotyczących organizacji danych w tabelach. Formularze normalne są numerowane sekwencyjnie, w miarę jak wymagania stają się bardziej rygorystyczne. W odpowiednio zaprojektowanej bazie danych tabele znajdują się co najmniej w trzeciej normalna forma. W związku z tym rozważymy pierwsze trzy formy normalne. Przypomnijmy, że mamy do czynienia ze stołami spełniającymi dwa podstawowe wymagania sformułowane powyżej.
Pierwsza postać normalna (1NF)
Pierwsza postać normalna mówi, że wszystkie dane zawarte w tabeli muszą być niepodzielne(niepodzielny). Listę odpowiednich atomowych typów danych określa system DBMS. Wymóg 1NF jest całkowicie naturalny. Oznacza to, że każde pole każdego rekordu powinno zawierać tylko jedną wartość, a nie tablicę lub inną strukturę danych. Podajmy znaczący przykład tabeli, której nie ma w 1NF. Stwórzmy listę ocen uczniów z danego przedmiotu.
Ponieważ wartość pola Oceny nie jest atomowa, tabela nie spełnia wymagań 1NF.
O możliwy sposób wpisana jest prezentacja listy rankingowej zalecenia metodologiczne do art „Projekt DB” 2.
Druga postać normalna (2NF)
Mówi się, że tabela jest w drugiej postaci normalnej, jeśli jest w 1NF i każda kolumna niekluczowa jest całkowicie zależna od główny klucz. Innymi słowy, wartość każdego pola musi być całkowicie określona przez wartość klucza podstawowego. Warto zaznaczyć, że zależność od klucza podstawowego rozumiana jest właśnie jako zależność od klucza jako całości, a nie od jego pojedynczego składnika (w przypadku klucza złożonego). Podajmy przykład tabeli, której nie ma w 2NF. Aby to zrobić, wróćmy do przykładu prognozy pogody i dodajmy do tabeli kolejną kolumnę - godzinę wschodu słońca (jest to przykład całkowicie prawdopodobny; tego rodzaju informacje często pojawiają się na stronach z prognozami pogody).
Jak pamiętamy, ten stół ma klucz złożony Data+Godzina. Pole Temperatura jest całkowicie zależne od klucza podstawowego - nie ma z nim żadnych problemów. Jednak pole Wschód słońca zależy tylko od pola Data.Pora dnia w naturalny sposób nie wpływa na godzinę wschodu słońca.
W tym miejscu wypada zadać pytanie: jakie jest praktyczne znaczenie 2NF? Jaka jest korzyść z tych ograniczeń? Okazuje się, że jest duży. Załóżmy, że w powyższym przykładzie programista ignoruje wymagania 2NF. Po pierwsze, tzw nadmierność- przechowywanie niepotrzebnych danych. Przecież jeśli dla jednego rekordu z daną datą zapisany jest już czas wschodu słońca, to dla wszystkich innych rekordów z daną datą powinien on być taki sam i w zasadzie nie ma potrzeby go zapamiętywać.
Zwróćmy uwagę na słowa „powinno być”. A co jeśli nie? Przecież na poziomie bazy danych nie jest to w żaden sposób kontrolowane - klucz w tabeli jest złożony, mogą być identyczne daty (i pod względem znaczenia najprawdopodobniej będą). I żadne formalne ograniczenia (a nasze zrozumienie, że „tak być nie może” nie jest jednym z nich) nie zabraniają uszczegóławiania inny czas wschód słońca w tym samym dniu.
Trzecia postać normalna (3NF)
Mówi się, że tabela jest w 3NF, jeśli jest w 2NF i wszystkie kolumny niekluczowe są wzajemnie niezależne.
Wzajemną zależność kolumn wygodnie rozumieć w następujący sposób: Kolumny są wzajemnie zależne, jeśli nie można zmienić jednej z nich bez zmiany drugiej.
Podajmy przykład tabeli, której nie ma w 3NF. Spójrzmy na prosty przykład zeszyt do przechowywania numerów telefonów domowych osób mieszkających być może w różnych regionach kraju.
Ta tabela ma zależność pomiędzy niekluczowymi kolumnami Miasto i Kod miasta, dlatego tabela nie jest w 3NF.
Należy pamiętać, że deweloper stwierdza obecność powyższej zależności analizując obszar tematyczny - takiej kolizji nie widać żadnymi metodami formalnymi. Przy zmianie właściwości obszaru tematycznego zależności między kolumnami mogą zniknąć. Na przykład, jeśli w obrębie tego samego miasta zostaną wprowadzone różne kody (np. 495 i 499 w Moskwie), odpowiednie kolumny nie będą już powiązane pod względem naruszenia wymagań 3NF.
W teorii relacyjnych baz danych uwzględniane są także formy wyższego rzędu – postać normalna Boyce’a-Codda, 4NF, 5NF i jeszcze wyższe. Formy te nie mają większego znaczenia praktycznego, a programiści z reguły zawsze zatrzymują się na 3NF.
Normalizacja bazy danych
Normalizacja to proces sprowadzania tabel bazy danych do wybranej postaci normalnej. Normalizacja do 2NF z reguły sprowadza się do dekompozycji - podziału jednej tabeli na kilka. Normalizację do 3NF można zwykle osiągnąć poprzez usunięcie zależnych (obliczonych) kolumn. W niektórych przypadkach podczas normalizacji do 3NF należy również przeprowadzić dekompozycję.
Wielotabelowe bazy danych, relacje między tabelami, klucze obce
W praktyce bazy jednotabelowe są dość rzadkie, gdyż z punktu widzenia modelowania bazy domenowej obecność jednej tabeli oznacza obecność jednego podmiotu. Z kolei obecność kilku podmiotów zwykle oznacza obecność powiązań między nimi.
Nie wyznaczając celu, jakim jest kompletny projekt bazy danych, rozważmy przykład, który pozwala nam zademonstrować relacje w wielotabelowych bazach danych.
Załóżmy, że mamy do czynienia ze szkołą, w której są uczniowie podzieleni na klasy i nauczyciele uczący określonych przedmiotów. Od razu wyróżniamy cztery podmioty: uczniów, nauczycieli, klasy i obiekty. Podmioty te dają nam już cztery tabele.
Następnie musimy rozwiązać kwestię atrybutów encji – jakie informacje będziemy przechowywać. Ponieważ nasz przykład służy wyłącznie celom demonstracyjnym, postaramy się zminimalizować ilość przechowywanych informacji. Wyrażamy zgodę na przechowywanie nazwiska i imienia każdego ucznia, dla klasy - numeru równoległego i litery identyfikującej klasę w obrębie równoległego, dla nauczyciela - nazwiska, imienia i patronimiki, dla przedmiotu - tylko jego nazwy .
Teraz musimy rozwiązać problem z kluczami podstawowymi. Tabele uczniów i nauczycieli w zasadzie nie mają klucza, dlatego wprowadzimy do nich zastępczy klucz numeryczny - liczbę. Tabele klas i przedmiotów, ogólnie rzecz biorąc, mają klucze. W tabeli klas klucz jest złożony, tworzą go atrybuty Parallel Number + Letter, natomiast w tabeli obiektów prosty klucz składa się z pojedynczego pola - nazwy obiektu. Przypomnijmy, że mówiąc o kluczach, wspomnieliśmy, że klucze zastępcze są często dodawane ze względu na wydajność, próbując pozbyć się kluczy złożonych lub pól kluczowych niewygodnych typów, takich jak ciągi znaków. To właśnie zrobimy. Dodajmy zastępczy klucz numeryczny do każdej z tabel.
W rezultacie otrzymamy następujący zestaw tabel odpowiadający opisanym podmiotom.
Rozumiejąc, z jakim obszarem tematycznym mamy do czynienia, wiemy, że nasze podmioty nie istnieją same w sobie – łączą je pewne relacje, które zarysowaliśmy powyżej. Ale jak je technicznie połączyć? Tutaj nie można obejść się bez wprowadzenia dodatkowych pól, a nawet dodatkowych tabel. Przyjrzyjmy się powiązaniom pomiędzy bytami w kolejności.
Aby przypisać ucznia do konkretnej klasy, w tabeli „Uczeń” dodajemy dodatkowe pole Numer klasy. (Jest oczywiste, że jego typ musi całkowicie pokrywać się z typem pola Numer klasy w tabeli „Klasa”). Teraz możemy połączyć tabele „Uczeń” i „Klasa”, używając pasujących wartości pól Numer klasy (nieprzypadkowo nazwaliśmy te pola tak samo, w praktyce często robi się to, aby ułatwić nawigację pomiędzy łączącymi się polami). Należy pamiętać, że jeden rekord w tabeli „Klasa” może odpowiadać wielu rekordom w tabeli „Uczeń” (a w praktyce najprawdopodobniej odpowiada - trudno sobie wyobrazić klasę jednego ucznia). Mówi się, że takie tabele są powiązane zależnością „ jeden za dużo" Nazywa się pole Numer klasy w tabeli „Uczeń”. klucz obcy. Jak widać, celem kluczy obcych jest łączenie tabel. Należy pamiętać, że klucz obcy zawsze odnosi się do klucza podstawowego połączona tabela(tj. klucz obcy znajduje się po stronie „wiele”). Klucz podstawowy powiązany z obcym nazywa się rodzicielski choć termin ten jest używany rzadziej.
Zilustrujmy to za pomocą diagramu w Styl Microsoftu Access (więcej informacji na temat „Schematu danych” Accessa znajduje się w artykule "Opis danych" 2).
Pomyślmy teraz o nauczycielach i przedmiotach. Analizując obszar tematyczny (to jedyny sposób – przecież z samego modelu formalnego nie da się wydobyć prawdziwego stanu rzeczy) zauważamy, że rodzaj powiązania pomiędzy podmiotami „nauczyciel” i „przedmiot” jest odmienny od tego omówionego powyżej. Przecież nie tylko wielu nauczycieli może uczyć jednego przedmiotu, ale jeden nauczyciel może uczyć wielu przedmiotów. Zatem istnieje powiązanie pomiędzy tymi podmiotami” wiele do wielu" Tutaj nie można obejść się bez wprowadzenia dodatkowych pól (spróbuj!). Relacje wiele do wielu rozwiązuje się zawsze poprzez wprowadzenie dodatkowej tabeli. Mianowicie organizujemy tabelę „Nauczyciel-Przedmiot”, która ma następującą strukturę:
Tabela „Nauczyciel-przedmiot”
Ta tabela ma klucz złożony utworzony z dwóch pól. Zarówno tabela „Nauczyciel”, jak i tabela „Przedmiot” są powiązane z tą tabelą w relacji jeden do wielu (oczywiście w obu przypadkach „wiele” znajduje się po stronie „Nauczyciel-Przedmiot”). Odpowiednio w tabeli „Nauczyciel-przedmiot” znajdują się dwa klucze obce (oba są częściami złożonego klucza podstawowego, co nie jest zabronione), które służą do połączenia z odpowiednimi tabelami.
W praktyce oprócz rozważanych relacji „jeden do wielu” i „wiele do wielu” istnieje także relacja „ Jeden na jednego" Z teoretycznego punktu widzenia taka relacja nie jest interesująca, ponieważ dwie tabele połączone relacją jeden do jednego zawsze można po prostu połączyć w jedną. Jednak w prawdziwych bazach danych w celu optymalizacji przetwarzania danych stosowana jest relacja jeden do jednego. Zilustrujmy to przykładem.
Załóżmy, że przechowujemy wiele różnych informacji o osobach - dane z wszelkiego rodzaju dokumentów, numerów telefonów, adresów itp. Najprawdopodobniej większość tych danych będzie używana bardzo rzadko. Często potrzebujemy tylko nazwiska, imienia, nazwiska i numeru telefonu. Wtedy sensowne jest zorganizowanie dwóch tabel i powiązanie ich w relacji jeden do jednego. Często używane informacje przechowuj w jednej (małej) tabeli, a resztę w drugiej. Naturalnie tabele powiązane relacją jeden do jednego mają ten sam klucz podstawowy.
Zasady uczciwości
Model relacyjny definiuje dwa Główne zasady Integralność bazy danych: integralność obiektu i integralność referencyjna.
Zasada uczciwości obiekty bardzo prosta. To wymaga, aby klucze podstawowe tabeli nie zawierały wartości null (null)..
Reguła integralności referencyjnej wymaga, aby klucze obce nie zawierały wartości niezgodnych z kluczami nadrzędnymi. Wracając do omówionego powyżej przykładu, musimy np. wymagać, aby uczniowie należeli tylko do klasy, której numer jest wskazany w tabeli „Oddziały”.
Większość SZBD jest w stanie monitorować integralność danych (oczywiście wymaga to odpowiedniego wysiłku ze strony programisty na etapie opisywania struktur danych). W szczególności wykorzystywane są mechanizmy mające na celu utrzymanie integralności referencyjnej kaskadowe operacje. Kaskadowanie oznacza w szczególności, że podczas usuwania rekordu z tabeli „nadrzędnej”, która jest połączona z inną tabelą relacją „jeden do wielu”, wszystkie powiązane rekordy są automatycznie usuwane z tabeli „wiele” (przez sam system DBMS, bez interwencji użytkownika). I to jest naturalne, bo takie nagrania „wiszą w powietrzu”, nie są już z niczym powiązane.
Indeksowanie
Indeksacja jest z punktu widzenia niezwykle istotna praktyczne zastosowanie, ale jest to rzecz opcjonalna z punktu widzenia czystej teorii. Głównym celem indeksowania jest optymalizacja (przyspieszenie) wyszukiwania (i co za tym idzie niektórych innych operacji na bazie danych). Indeksowanie w każdym przypadku wymaga dodatkowych zasobów (specjalne pliki indeksowe tworzone są najczęściej na poziomie fizycznym). Indeksowanie może nawet spowolnić operacje związane z modyfikacją danych, dlatego indeksowane są zwykle tabele, które są rzadko modyfikowane i często przeszukiwane.
Plik indeksu jest bardzo podobny do zwykłego indeksu książek. Dla każdej wartości indeksu przechowywana jest lista wierszy tabeli zawierających tę wartość. W związku z tym, aby wyszukiwać, nie trzeba przeglądać całej tabeli - wystarczy zajrzeć do indeksu. Jednak podczas modyfikowania rekordów może zaistnieć potrzeba odbudowania indeksu. A to wymaga dodatkowego czasu.
Nie ma oczywiście mowy o przedstawianiu w ich ramach teorii relacyjnych baz danych kurs podstawowy Informatyka! Niemniej jednak ten artykuł jest bardzo ważny dla naszej encyklopedii, ponieważ w tym przypadku Mamy do czynienia z materiałem, którego nie da się w pełni przekazać na lekcjach, ale nauczyciel musi go opanować. Dlaczego?
Po pierwsze dlatego, że w ramach kursu podstawowego uczy się wielu pojęć. To i widok stołu dane i klucze tabeli. A wszyscy wiemy, że bardzo trudno jest poprawnie i trafnie przedstawić tylko niektóre koncepcje, nie przedstawiając całościowego obrazu.
Po drugie, występy z dziećmi proste zapytania do baz danych (materiał na ten temat przedstawiono w artykule "Przetwarzanie danych" 2), należy zająć się tabelami poprawnymi z punktu widzenia teorii relacji. Nie ma potrzeby wyjaśniać uczniom, że te tabele są poprawne, ale „gdyby tylko..., to tabela byłaby błędna”, ale niedopuszczalne jest posługiwanie się złymi przykładami.
W kurs profilowy W informatyce sytuacja może być zasadniczo inna. Najważniejszą i niezwykle produktywną formą pracy na zajęciach specjalistycznych jest praca projektowa. W projekty edukacyjne Tworzenie prostych baz danych jest możliwe i konieczne, a tutaj nie można obejść się bez podstaw prezentowanej teorii. Należy jednak wziąć pod uwagę następujące kwestie:
Modelowane obszary tematyczne nie powinny być zbyt duże;
Powinny być dobrze znane uczniom (w tym sensie projekt „Szkoła”, którego wszyscy mieli dość, nie jest najgorszym wyborem!);
Naiwnością jest oczekiwać, że po wysłuchaniu podstaw teorii studenci będą w stanie sami coś zaprojektować. Musisz przejść z nimi każdy krok, szczegółowo uzasadniając swoje działania.
Poziom 1: Poziom modeli zewnętrznych jest największy Najwyższy poziom gdzie każdy model ma swój własny widok danych. Warstwa ta definiuje punkt widzenia bazy danych poszczególnych aplikacji.
Poziom koncepcyjny: Centralne łącze sterujące, w którym baza danych prezentowana jest najczęściej ogólna perspektywa, który łączy dane wykorzystywane przez wszystkie aplikacje. W rzeczywistości poziom koncepcyjny odzwierciedla uogólniony model obszaru tematycznego.
Warstwa fizyczna (baza danych): Są to same dane znajdujące się w plikach lub strukturach stron znajdujących się na zewnętrznych nośnikach danych.
Modele danych
Wyróżnia się następujące modele danych:
1. Infologiczne
2. Data logiczna
3. Fizyczne
Proces projektowania bazy danych rozpoczyna się od zaprojektowania modelu informacyjnego. Infologiczny model danych to uogólniony, nieformalny opis tworzonej bazy danych, sporządzony przy użyciu języka naturalnego, wzory matematyczne, tabele, wykresy i inne narzędzia zrozumiałe dla wszystkich osób pracujących nad projektowaniem baz danych.
Krotka domeny
Model informacyjny odzwierciedla świat rzeczywisty w jakiejś zrozumiałej dla człowieka koncepcji, całkowicie niezależnej od środowiska przechowywania danych. Dlatego Model Infologii nie powinien się zmieniać, dopóki jakaś zmiana w świecie rzeczywistym nie będzie wymagała zmiany poza definicją, tak aby model nadal reprezentował dziedzinę.
Istnieje wiele podejść do budowy tego modelu: modele grafowe, sieci semantyczne, istota – połączenie i inne.
Model danych
Model infologiczny musi być przedstawiony w modelu datalogicznym zrozumiałym dla SZBD. Model danych jest formalnym opisem modelu informacyjnego w języku DBMS.
Model hierarchiczny
Model ten jest zbiorem powiązanych ze sobą elementów, które tworzą struktura hierarchiczna. Podstawowe pojęcia hierarchii obejmują poziom, węzeł i relację.
poziom komunikacji
Węzeł to zbiór atrybutów danych opisujących obiekt. Każdy węzeł jest połączony z jednym węzłem przez więcej niż wysoki poziom oraz z dowolną liczbą węzłów niższego poziomu. Wyjątkiem jest węzeł najwyższego poziomu. O liczbie drzew w bazie danych decyduje liczba korzeni drzew. Każdy rekord bazy danych ma jedną ścieżkę od rekordu głównego. Prosty przykład może służyć jako adres systemu nazw domen internetowych. Na pierwszym poziomie (korzeń drzewa) leży nasza planeta Ziemia, na drugim Kraj, na trzecim Region, na czwartym – miejscowość, Ulica, dom, mieszkanie. Typowym przedstawicielem jest system DBMS firmy IBM – IMS.
Wszystkie kopie tego typu potomkowie ze wspólnym wystąpieniem typu przodka nazywani są bliźniakami. Zdefiniowane dla bazy danych pełne zamówienie objazd. Od góry do dołu i od prawej do lewej.
Model fizyczny
Model fizyczny budowany jest w oparciu o model datalogiczny. Fizyczna organizacja danych ma ogromny wpływ na Charakterystyka wydajności Baza danych. Programiści DBMS starają się stworzyć najbardziej produktywne modele danych fizycznych, oferując użytkownikom to czy inne narzędzie do dostosowania modelu dla konkretnej bazy danych.
Przykład: W szczególności w przypadku relacyjnej bazy danych uwzględnia ona już:
1. Fizyczne aspekty przechowywania tabel w określonych plikach.
2. Tworzenie indeksów optymalizujących szybkość operacji na danych za pomocą aplikacji.
3. Wykonanie różne działania nad danymi o godz pewne wydarzenia definiowane przez użytkowników za pomocą wyzwalaczy i procedur składowanych.
Modele infologiczne XNa wszystkich poziomach i dla każdej metody przedstawiania obszaru tematycznego istnieje kodowanie pojęć lub relacji między pojęciami. Kluczowy krok w rozwoju każdego System informacyjny jest przeprowadzenie analizy systemowej:
Formalizacja obszaru tematycznego i reprezentacja systemu jako zbioru komponentów.
Kompozycja jako podstawa analizy systemu może mieć charakter funkcjonalny (budowanie hierarchii).
Jednak w większości systemów, jeśli chodzi o bazy danych, typy danych są elementem bardziej statycznym niż sposób ich przetwarzania. Dlatego takie metody analizy systemu, jak diagram przepływu danych, uległy intensywnemu rozwojowi. Rozwój relacyjnych baz danych. Stymulował rozwój metodologii opracowywania danych, w szczególności diagramów ER ER. Relacyjny model danych bezpośrednio wykorzystuje koncepcję relacji jako odwzorowanie. Ona jest najbliżej model koncepcyjny Prezentacja danych. I często leży w jego sercu.
W odróżnieniu od teoretyka modelu grafowego, w modelu relacyjnym powiązania pomiędzy relacjami realizowane są w sposób niejawny, do czego wykorzystywane są klucze relacji. Przykładowo relacje typu hierarchicznego realizowane są poprzez mechanizm kluczy podstawowych i obcych, gdy fakt atrybutów musi występować w relacji podrzędnej.
Taki atrybut relacji w relacji głównej będziemy nazywać kluczem podstawowym, a w relacji podrzędnej kluczem wtórnym.
Postęp w rozwoju języków programowania związanych przede wszystkim z typowaniem danych oraz pojawienie się języków obiektowych umożliwiło podejście do analizy złożonych systemów z punktu widzenia reprezentacji hierarchicznych, czyli z wykorzystaniem klas obiekty posiadające właściwości polimorfizmu, dziedziczenia i enkapsulacji.
RELACJA TO STOŁ.
Usuwanie tego, co utworzyłeś i
Redagowanie.
Relacyjny model bazy danych
Relacyjne modele danych zyskały obecnie największą popularność właśnie dla tej reprezentacji danych.
Model relacyjny można przedstawić jako specjalna metoda reprezentacja danych zawierająca własne dane (w postaci tabel) oraz sposoby ich pracy i manipulowania (w postaci relacji). Model relacyjny zakłada trzy elementy koncepcyjne: Strukturę, Integralność i Przetwarzanie Danych. Elementy te mają swoje własne obowiązkowe pojęcia, które należy wyjaśnić w celu dalszej prezentacji.
Tabela jest uważana za bezpośredni magazyn danych. Tradycyjnie w systemach relacyjnych tabela nazywa się postawa. Nazywa się wiersz tabeli kolumna pojazdów i kolumna atrybut. W tym przypadku atrybuty mają unikalne nazwy(w związku).
Liczba krotek w tabeli nazywa się liczba kardynalna. Liczba atrybutów stopień. Dla zestawu relacji unikalny identyfikator, czyli jeden lub więcej atrybutów, których wartości nie są jednocześnie takie same – wywoływany jest identyfikator klucz podstawowy.Domena jest to zbiór prawidłowych jednorodnych wartości dla określonego atrybutu. Zatem domenę można uznać za nazwany zbiór danych, a składniki tego zbioru są logicznie niepodzielnymi jednostkami (przykładowo lista nazwisk pracowników instytucji może pełnić rolę domeny, ale nie wszystkie nazwiska mogą występować na stole).
SUMAPostawa
atrybuty
Pola KOD, NAME, SUMM są atrybutami tabeli zawartymi w nagłówku.
Pary KOD 5216, NAZWISKO Kireeva, SUMM 25,50 są elementami ciała związku.
W relacyjnych bazach danych, w przeciwieństwie do innych modeli, użytkownik określa, jakie dane mu są potrzebne, a nie jak to zrobić. Z tego powodu proces przenoszenia i nawigacji po bazie danych w systemach relacyjnych jest automatyczny, a zadanie to realizowane jest w systemie DBMS optymalizator. Jego zadaniem jest wyciągnąć jak najwięcej efektywny sposób pobierać dane z bazy danych na żądanie. Zatem optymalizator musi przynajmniej być w stanie określić, z jakich tabel wybrano dane, ile informacji znajduje się w tych tabelach oraz jaka jest fizyczna kolejność rekordów w tabelach i sposób ich pogrupowania.
Ponadto relacyjna baza danych pełni również funkcje katalogowe. W katalogu przechowywany jest opis wszystkich obiektów tworzących bazę danych: tabele, indeksy, wyzwalacze itp. Wiadomo, że jest to istotne prawidłowe działanie cały system, taki element jak optymalizator. Optymalizator wykorzystuje informacje zapisane w katalogu. Ciekawostką jest to, że sam katalog jest zbiorem tabel, więc DBMS może nim manipulować tradycyjne sposoby bez uciekania się do specjalnych technik i metod.
Domeny i relacje
Podstawowe definicje: Dziedziny, rodzaje relacji, predykaty.
Relacje mają kilka podstawowych właściwości:
1. W najbardziej ogólnym przypadku w relacjach nie ma wspólnych krotek - wynika to z samej definicji relacji. Jednakże w przypadku niektórych systemów DBMS odchylenia od tej właściwości są w niektórych przypadkach dopuszczalne. Dopóki w relacji występuje klucz podstawowy, identyczne krotki są wykluczane.
2. Krotki nie są uporządkowane od góry do dołu – po prostu nie ma pojęcia liczby pozycyjnej w relacji. W relacjach, nie tracąc informacji, możesz z powodzeniem układać krotki w dowolnej kolejności.
3. Atrybuty nie są uporządkowane od lewej do prawej. Atrybuty w nagłówku relacji można ułożyć w dowolnej kolejności bez naruszania integralności danych. Dlatego też nie istnieje koncepcja liczby pozycyjnej w odniesieniu do atrybutu.
4. Wartości atrybutów składają się z jednostek logicznie niepodzielnych - wynika to z faktu, że wartości są pobierane z dziedzin, w przeciwnym razie można powiedzieć, że relacje nie zawierają grup powtórzeń. Oznacza to, że są znormalizowane.
Systemy relacyjne obsługują kilka typów relacji:
1. Zmienne nazwane to zmienne relacyjne definiowane w SZBD przez operatory kreacji i z reguły niezbędne dla wygodniejszej prezentacji informacji dla użytkownika.
2. Bezpośrednio ważną częścią bazy danych są podstawowe relacje, dlatego podczas projektowania nadawane są im własne nazwy.
3. Relacja pochodna to taka, która została zdefiniowana poprzez inne, zwykle podstawowe relacje, przy użyciu narzędzi DBMS.
4. Ta reprezentacja jest w rzeczywistości nazwaną relacją pochodną i reprezentacja jest wyrażana wyłącznie za pomocą operatorów DBMS zastosowanych do nazwanych relacji, więc nie istnieją one fizycznie w bazie danych.
5. Wynikiem zapytań jest nienazwana relacja pochodna zawierająca dane (result konkretne żądanie). Wynik nie jest przechowywany w bazie danych, ale istnieje tak długo, jak długo tego potrzebuje użytkownik.
6. Relacja przechowywana to taka, która jest fizycznie utrzymywana w pamięci relacji, przechowywane relacje najczęściej zawierają bazę relacji. Na podstawie powyższego możemy zdefiniować relacyjną bazę danych jako zbiór wzajemnie powiązanych relacji.
Połączenie w tym przypadku to połączenie dwóch lub więcej relacji.
| KOD | ADRESY |
∞ Połączenie binarne
| Studenci |
| Nauczyciele |
| Harmonogram zajęć |
| ∞ |
| ∞ |
| ∞ |
| Studenci |
Połączenia trójskładnikowe
Integralność danych
W modelach relacyjnych szczególne miejsce zajmuje kwestia integralności danych. Przypomnijmy, że klucz lub potencjalny klucz to minimalny zbiór atrybutów, których wartości można wykorzystać do jednoznacznego znalezienia wymaganej krotki; minimalność oznacza, że wykluczenie jakiegokolwiek atrybutu ze zbioru nie pozwala na identyfikację krotki na podstawie pozostałych atrybutów.
Każda relacja ma przynajmniej jeden możliwy klucz. Jeden z nich jest traktowany jako klucz podstawowy.
Wybierając klucz podstawowy, należy preferować klucze niezłożone lub złożone z minimalny zestaw atrybuty. Niepożądane jest również używanie kluczy z długimi wartościami tekstowymi (najlepiej jako kluczy używać atrybutów całkowitych). Tak więc, aby zidentyfikować pracownika, możesz użyć unikalnego numeru personalnego, numeru paszportu lub zestawu nazwisk, drugich imion i numerów działów. Niedozwolone jest, aby klucz podstawowy relacji, czyli jakikolwiek atrybut uczestniczący w kluczu podstawowym, przyjmował niezdefiniowane wartości. W takim przypadku powstanie sytuacja sprzeczna ( kolizja): Pojawia się nieunikalny element klucza podstawowego. Dlatego należy to dokładnie monitorować podczas projektowania bazy danych.
O kluczach obcych. Warto zauważyć, że skoro relacja C łączy relacje B i A, to musi zawierać klucze obce odpowiadające kluczom podstawowym relacji A i B.
Klucz obcy tabeli jest tworzony przy użyciu kilku kluczy podstawowych innych tabel.
Zatem rozważając problem wyboru sposobu łączenia relacji w bazie danych pojawia się pytanie, jakie powinny być klucze obce. Jednocześnie dla każdego klucza obcego konieczne jest rozwiązanie problemu związanego z możliwością (lub niemożnością) niezdefiniowanych wartości (NULL - wartości - wartość atrybut brakujących informacji). Innymi słowy, czy w relacji może istnieć krotka, dla której krotka w powiązanych z nią relacjach nie jest znana?
Z drugiej strony należy z wyprzedzeniem pomyśleć o tym, co się stanie podczas usuwania krotek z relacji, do której odwołuje się klucz obcy. Istnieją następujące możliwe możliwości:
· Operacja kaskady– czyli usunięcie krotek w relacjach powoduje usunięcie krotek powiązanych z relacją. Na przykład usunięcie informacji o nazwisku, imieniu itp. pracownik w jednym zakresie prowadzi do skreślenia jego wynagrodzenia w innym zakresie;
· Operacja ograniczony - oznacza to, że usuwane są tylko te krotki, z którymi nie są powiązane żadne inne informacje. Nie wszystkie informacje są usuwane (nie we wszystkich aspektach), ponieważ można je wykorzystać w innym celu, przy czym usunięcie informacji prowadzi do naruszenia integralności danych. Jeżeli takie informacje są dostępne, nie można dokonać ich usunięcia, np. usunięcia informacji o imieniu, nazwisku itp. pracownika jest możliwe tylko w przypadku braku powiązanych informacji na temat jego wynagrodzenia.
Konieczne jest zapewnienie technologii umożliwiającej obserwację tego, co się stanie, gdy spróbujesz zaktualizować klucz podstawowy relacji, do której odwołuje się klucz obcy. Tutaj masz te same opcje, co przy usuwaniu:
· Operacja jest kaskadowa, co oznacza, że aktualizacja klucza podstawowego powoduje aktualizację klucza obcego w powiązanej relacji. Przykładowo aktualizacja klucza podstawowego w relacji, w której przechowywane są informacje o pracownikach, prowadzi do aktualizacji klucza obcego w relacji zawierającej informacje o wynagrodzeniu.
· Operacja ogranicza się do aktualizacji tylko tych kluczy podstawowych, z którymi w inny sposób nie są powiązane żadne informacje. Jeżeli takie informacje są dostępne, aktualizacja nie będzie możliwa. Przykładowo aktualizacja klucza podstawowego w relacji, w której przechowywane są informacje o pracowniku, jest możliwa tylko w przypadku, gdy w powiązanej relacji brakuje informacji o jego wynagrodzeniu.1
Algebra relacyjna
Podstawą formalną modelu relacyjnej bazy danych jest algebra relacyjna oparta na teorii mnogości i uwzględniająca operator specjalny nad relacjami oraz rachunek relacyjny oparty na logice matematycznej.
| Praca |
| A A B B C | Y Y D |
| G D |
| A |
| A B C | Y Y D | FF W |
Należy zauważyć, że algebra relacyjna ma duża moc- złożone zapytania do bazy danych można wyrazić za pomocą pojedynczego wyrażenia. Dlatego właśnie wprowadzono te mechanizmy model relacyjny dane. Każde zapytanie wyrażone za pomocą jednego wyrażenia algebry relacyjnej lub jednej formuły rachunku relacyjnego można wyrazić za pomocą jednego operatora w tym języku.
Algebra relacyjna ma ważną właściwość - jest zamknięta w odniesieniu do pojęcia relacji. Oznacza to, że wyrażenie algebry relacyjnej wykonywane jest na relacjach relacyjnych baz danych, a wyniki ich obliczeń również reprezentują relacje.
Główną ideą algebry relacyjnej jest to, że sposoby manipulowania relacjami rozpatrywanymi jako zbiór opierają się na tradycyjnych operacjach wielokrotnych uzupełnionych pewnymi operacjami specyficznymi dla bazy danych.
Opiszmy wersję algebry zaproponowaną przez CODD. Operacja składa się z 8 głównych operatorów:
Pobieranie relacji (operacja jednoargumentowa)
Projekcja relacji (operacja jednoargumentowa)
· Łączenie relacji
· Przecięcie relacji (operacja binarna)
· Odejmowanie wskaźników
Produkt relacji
· Łączenie relacji
· Podział relacji
Operacje te można wyjaśnić w następujący sposób:
· Wynikiem wybrania relacji na podstawie jakiegoś warunku jest relacja zawierająca tylko te krotki pierwotnej relacji, które spełniają ten warunek.
· Projektując relację na zadany zbiór jej atrybutów, otrzymamy relację, której krotki zostaną pobrane z odpowiednich krotek pierwszej relacji.
· Wykonując operację łączenia dwóch relacji, otrzymana zostanie relacja obejmująca wszystkie krotki zawarte w co najmniej jednej z relacji biorących udział w operacji.
· Wykonując operację przecięcia dwóch relacji, otrzymana zostanie relacja obejmująca wszystkie krotki zawarte w obu relacjach początkowych.
· Wykonując operację odejmowania dwóch relacji, otrzymana zostanie relacja obejmująca wszystkie krotki zawarte w pierwszej relacji, z wyjątkiem tych, które wchodzą także w drugą relację.
· Wykonując iloczyn bezpośredni dwóch relacji, otrzymujemy relację, której krotki są kombinacją krotek pierwszej i drugiej relacji.
· Kiedy dwie relacje są połączone według jakiegoś warunku, powstaje wynikowa relacja krotek, których krotki są kombinacją krotek pierwszej i drugiej relacji spełniających ten warunek.
· Relacyjna operacja dzielenia ma dwa operandy – relację binarną (składającą się z dwóch atrybutów) i relację jednoargumentową (składającą się z jednego atrybutu). Wynikiem operacji jest relacja złożona z krotek zawierająca relację pierwszego atrybutu krotek pierwszej relacji i taka, że zbiór wartości drugiego atrybutu pokrywa się ze zbiorem wartości drugiej relacji .
Oprócz powyższego istnieje szereg specjalnych operacji charakterystycznych dla pracy z bazami danych:
· W wyniku operacji zmiany nazwy relacja jest zbiorem krotek, który pokrywa się z treścią oryginalnej relacji, ale nazwy atrybutów zostały zmienione.
Wynika z tego, że wynikiem operacji relacyjnej jest pewna relacja, można tworzyć wyrażenia relacyjne, w których zamiast pierwotnej relacji (operandu) zostanie użyte wbudowane wyrażenie relacyjne. Wynika to z faktu, że działania algebry relacyjnej są rzeczywiście zamknięte dla pojęcia relacji. Zacznijmy od operacji ujednolicenie stosunków, jednakże dotyczy to również operacji przecięcia i kombinacji, to znaczy w algebrze relacyjnej wynikiem operacji sumowania jest relacja. Jeśli wpuszczono algebra relacyjna możliwość wspomnienia dowolne dwie relacje o różnych zbiorach atrybutów, wówczas wynikiem takiej operacji będzie zbiór, ale zbiór krotek różnych typów, czyli ogólnie rzecz biorąc, nie relacja. Jeśli wyjdziemy z wymagania, że algebra relacyjna jest domknięta ze względu na pojęcie relacji, to taka operacja wspomnienia jest bez znaczenia. Prowadzi to do pojawienia się koncepcji zgodność relacji Przez zjednoczenie: dwie relacje są kompatybilne tylko wtedy, gdy tak jest z tymi samymi nagłówkami, to znaczy ma ten sam zestaw nazw atrybutów, a atrybuty o tej samej nazwie są zdefiniowane w tej samej domenie.
Pod warunkiem, że dwie relacje są kompatybilne przez sumę, gdy zwykle wykonywana jest na nich operacja sumy-przecięcia-odejmowania, wynikiem tej operacji jest relacja z poprawnie zdefiniowanym nagłówkiem, który pasuje do nagłówka każdej relacji operandu. Jeśli dwie relacje nie są w pełni kompatybilne z łączeniem, to znaczy kompatybilne we wszystkim z wyjątkiem nazw atrybutów, to przed wykonaniem operacji typu łączenia można zapewnić, że te relacje będą w pełni zgodne z łączeniem, stosując operację zmiany nazwy.
Nowe problemy stwarza działanie iloczynu bezpośredniego dwóch relacji. W teorii mnogości iloczyn bezpośredni można otrzymać dla dowolnych zbiorów. Elementy powstałego zbioru będą parami złożonymi z elementów pierwszego i drugiego zbioru. Ponieważ relacje są zbiorami, dla dowolnych dwóch relacji można otrzymać iloczyn bezpośredni. Jednak wynikiem nie będzie relacja. Elementami wyniku nie będą krotki, ale pary krotek. Dlatego w algebrze relacyjnej używamy specjalna forma bezpośrednie operacje produktowe - rozszerzony bezpośredni produkt relacji. Biorąc rozszerzony iloczyn bezpośredni dwóch relacji, elementem wynikowej relacji jest krotka utworzona przez połączenie jednej krotki pierwszej relacji i jednej krotki drugiej relacji. Od razu pojawia się drugi problem związany z otrzymaniem poprawnie utworzonego nagłówka powstałej relacji, co prowadzi do konieczności wprowadzenia koncepcji zgodności relacji poprzez przyjęcie rozszerzonego iloczynu bezpośredniego.
Dwie relacje są zgodne, przyjmując iloczyn bezpośredni tylko wtedy, gdy zbiór nazw atrybutów tych relacji nie przecina się. Dowolne dwie relacje można przekształcić w kompatybilną formę produktu bezpośredniego, stosując operację zmiany nazwy jednej z relacji.
Operacja pobierania wymaga dwóch relacji: relacji początkowej, operandu i prostego warunku ograniczającego. W wyniku operacji selekcji powstaje relacja, której głowa pokrywa się z nagłówkiem relacji operandu, a treść zawiera te krotki relacji operandu, które spełniają wartości warunku ograniczenia.
Przedstawmy kilka operatorów.
Niech suma oznacza operację sumowania, przecięcie – operację przecięcia, minus – operację odejmowania. Aby oznaczyć operację próbkowania, użyjemy konstrukcji A, gdzie B, gdzie A jest relacją operandu, a B jest prostym warunkiem porównania. Niech C1 i C2 będą dwoma prostymi warunkami próbkowania
A, gdzie C1 I C2 są identyczne (A, gdzie C1) przecinają się (A, gdzie C2)
A, gdzie C1 LUB C2 jest identyczne z (A, gdzie C1) złączem (A, gdzie C2)
A, gdzie C1, a nie C2 jest identyczne z (A, gdzie C1) minus (A, gdzie C2)
Korzystając z tych definicji, można zaimplementować operacje próbkowania, w których warunek próbkowania jest dowolny wyrażenie logiczne składa się z proste warunki przy użyciu połączeń logicznych (i, lub, nie). Operacja wciągnięcia rzutów relacji A na listę atrybutów a1, a2,…,an będzie relacją, której głową jest zbiór atrybutów a1,a2,…,an. Ciało wyniku będzie składać się z krotek, dla których w relacji A znajduje się krotka, atrybut a1 ma wartość b1, atrybut a2 ma wartość b2< и так далее атрибут an – bn. По сути при выполнении операции проекции определяется «Вертикальная» вырезка отношения - операнда с удалением возникающих кортежей –дубликатов.
Operacja łączenia, czasami nazywana łączeniem warunkowym, wymaga dwóch operandów, złączenia relacji i trzeciego operandu, czyli prostego warunku. Niech będzie połączona relacja A i B. Podobnie jak w przypadku operacji selekcji, warunek złączenia C ma postać (a comp –op b) lub (a comp –op const), gdzie A i B są nazwami atrybutów relacji A i B, const jest dosłownie określoną stałą. Comp-op – ważny w w tym kontekście operacja porównania. Wówczas z definicji wynikiem operacji łączenia jest relacja uzyskana w wyniku wykonania operacji ograniczenia, zgodnie z warunkiem C, będący iloczynem bezpośrednim relacji A i B.
Jest coś ważnego szczególny przypadek połączenia, naturalne połączenie. Operację łączenia nazywa się operacją łączenia naturalnego, jeśli warunki łączenia mają postać (a=b), gdzie a i b są atrybutami różnych operandów łączenia. Przypadek ten jest o tyle istotny, że jest szczególnie powszechny w praktyce i istnieją dla niego skuteczne algorytmy implementacji w SZBD. Operację łączenia naturalnego stosuje się do pary relacji A i B, które mają wspólny atrybut P, to znaczy atrybut o tej samej nazwie i zdefiniowany w tej samej domenie. Niech ab oznacza sumę nagłówków relacji A i B. Wtedy złączenie naturalne jest wynikiem złączenia A i B rzutowanego na ab. Operacje złączenia naturalnego nie wchodzą bezpośrednio w zbiór operacji algebry relacyjnej, ale mają one bardzo ważne znaczenie praktyczne.
Operacja podziału relacji wymaga czegoś więcej szczegółowe wyjaśnienie bo trudno to zrozumieć. Niech dane będą dwie relacje A (a1,a2,..,an,b1,b2,…,bm)
B (b1,b2,…,bn) Zakładamy, że atrybut b1 relacji A i atrybut b1 relacji B są zdefiniowane w tej samej dziedzinie. Nazwijmy zbiór atrybutów (aj) atrybutem złożonym a, a zbiór (bj) c atrybutem złożonym b. Następnie porozmawiamy o relacyjnym podziale relacji binarnej A (a, b) na relację jednoargumentową B (b).
Wynikiem dzielenia A przez B jest relacja jednoargumentowa C (a), składająca się z krotek v takich, że w relacji A występują krotki
Ponieważ dzielenie jest najtrudniejszą operacją, wyjaśnijmy to na przykładzie. Niech w bazie studentów będą dwie relacje: STUDENCI (IMIĘ, IMIĘ, LICZBA) i NAZWISKO (IMIĘ I NAZWISKO), a jednoargumentowa relacja NAZWISKO zawiera wszystkie nazwiska, jakie noszą studenci instytutu. Następnie po wykonaniu operacji relacyjnego podziału relacji STUDENCI na relację NAZWISKO otrzymamy relację jednoargumentową zawierającą numery legitymacji studenckich należących do studentów o wszystkich możliwych nazwiskach w tej uczelni.
Notacja relacyjna
Załóżmy, że istnieje baza danych o strukturze STUDENCI (liczba, imię i nazwisko, stypendium, kod grupy) i relacji GRUPY (gr_nom, gr_kol, gr old). Załóżmy, że musisz znaleźć nazwiska i numery studentów. bilety dla uczniów będących prefektami grup liczących powyżej 25 osób.W algebrze relacyjnej należy wziąć następujące działania na takie żądanie:
1. Połącz relacje STUDENCI i GRUPY, zgodnie z warunkiem „numer_studenta = gr_gwiazda”;
2. Ogranicz uzyskany współczynnik poprzez warunek gr_col>25.
3. Rzutuj wynik poprzedniej operacji na atrybuty nazwa_ucznia, numer_ucznia.
Oto sformułowanie krok po kroku kolejności wykonywania zapytań w bazie danych, z których każde odpowiada jednej operacji relacyjnej. jeśli sformułujemy to samo zapytanie za pomocą rachunku relacyjnego, to otrzymamy formułę, którą można odczytać: Wydaj STUDY_NAME i STUDY_NUMBER dla takich uczniów, aby taka grupa GR_STAR i wartość GR_NUM>25 współistniały. W drugim sformułowaniu wskazaliśmy jedynie charakterystykę powstałej zależności, nie powiedzieliśmy nic o sposobie jej powstania. W tym przypadku sam DBMS musi zdecydować, jakie operacje i w jakiej kolejności należy wykonać na relacjach STUDENCI i GRUPY. Obie metody omówione w przykładzie są właściwie równoważne i nie ma zbyt skomplikowanych konwersji między nimi.
Podstawowymi pojęciami rachunku relacyjnego są pojęcia zmiennej o określonym obszarze jej wartości oraz pojęcia poprawnie skonstruowanej formuły opartej na zmiennych i funkcjach specjalnych. Funkcje. Czym jest dziedzina definicji zmiennej, różni się w przypadku rachunku krotek i rachunku dziedzinowego, czyli wzdłuż lub w poprzek. W rachunku krotek dziedziną definicji zmiennej jest relacja z bazą danych, tj. ważna wartość Każda zmienna jest krotką jakiejś relacji. W rachunku dziedzin dziedziny definicji zmiennych to domeny, w których zdefiniowane są atrybuty relacji w bazie danych, to znaczy prawidłową wartością każdej zmiennej jest wartość każdej zmiennej.
| Bajt | Liczba całkowita | Strunowy | Zwęglać | |
| M | ||||
| | N | |||
| K | ||||
Do definiowania krotek służy polecenie RANGE. Przykładowo, aby zdefiniować zmienną STUDENT o zakresie STUDENTS, należy zastosować konstrukcję RANGE STUDENT IS STUDENTS. Z tej definicji wynika, że w dowolnym momencie zmienna student reprezentuje pewną krotkę relacji STUDENCI. Jeśli w formułach używasz zmiennych krotek, możesz odwoływać się do wartości atrybutów zmiennych. Przykładowo, aby odwołać się do wartości atrybutu STUDENT_NAME zmiennej STUDENT, należy zastosować konstrukcję STUDENT.STUDENT_NAME.
Poprawnie skonstruowane formuły służą do wyrażania warunków nałożonych na zmienne krotki. Formuły takie opierają się na prostych porównaniach, czyli operacjach porównujących wartości atrybutów zmiennych i stałych literałowych. Przykładowo konstrukcja STUDENT.STUD_NOM=123456. Jest proste porównanie. Bardziej złożona wersja formuł złożonych wykorzystuje połączenia logiczne ORAZ, LUB, NIE, JEŚLI... TO. Wreszcie możliwe jest konstruowanie dobrze sformułowanych formuł za pomocą kwantyfikatorów. Jeśli F jest dobrze sformułowaną formułą zawierającą zmienną var, to konstrukcja ISTNIEJE (kwantyfikator istnienia) var (F) i FORALL (dla wszystkich krotek) var (F) jest poprawna.
Zmienne zawarte w prawidłowo skonstruowanych formułach mogą być dowolne lub powiązane. Wszystkie zmienne wchodzące w ich skład, przy konstrukcji których nie zastosowano kwantyfikatorów, są dowolne. Oznacza to, że jeśli dla jakiegoś zbioru wartości zmiennych krotki swobodnej przy obliczaniu formuł zostanie uzyskana wartość „prawda”, to wartości te można uwzględnić w wynikowej relacji. Jeśli przy konstruowaniu formuł używany jest kwantyfikator, wówczas zmienne są powiązane. Przy obliczaniu wartości tak poprawnie skonstruowanego wzoru uwzględnia się nie pojedynczą wartość powiązanej zmiennej, ale całą jej dziedzinę definicyjną.
1)ISTNIEJE STUD2 (STUD.1STUD_STIP> STUD2.STUD_STIP)
2)DLA WSZYSTKICH STUD2 (STUD.1STUD_STIP> STUD2.STUD_STIP)
Niech STUD1 i STUD2 będą dwiema krotkami zdefiniowanymi dla relacji studenci, wówczas wzór na aktualną krotkę zmiennej STUD1 przyjmuje wartość true tylko wtedy, gdy w całej relacji studenci istnieje taka krotka powiązana ze zmienną STUD2 taka, że wartość jego atrybutu STUD_STIP spełnia warunek porównania wewnętrznego. Poprawnie skonstruowana formuła nr 2 dla skonstruowanej krotki STUDENT 1 przyjmuje wartość true jeżeli dla wszystkich krotek relacji STUDENTS powiązanej ze zmienną STUDENT 2 wartość atrybutu STUDENT.STIP spełnia warunek wewnętrzny.
Zatem dobrze sformułowane formuły umożliwiają wyrażenie warunków próbkowania na podstawie relacji w bazie danych. Aby móc używać rachunku relacyjnego dla prawdziwa praca z bazą danych wymagany jest kolejny komponent, który określa zbiór i nazwy kolumn wynikowej relacji. Ten składnik nazywa się lista docelowa.
Lista docelowa ma postać:
· Var.attr – nazwa zmiennej wolnej, attr to nazwa atrybutu relacji, na którym zdefiniowana jest zmienna var.
· Var, który jest odpowiednikiem relacji z listy, Var.attr1, Var.attr1... Var.attr№ zawiera nazwy wszystkich atrybutów relacji definiującej.
· Nowa_nazwa = var.attr; nowa nazwa odpowiedniego atrybutu wynikowej relacji.
Ostatnia opcja wymagane w przypadkach, gdy kod w formule wykorzystuje kilka wolnych zmiennych o tym samym zakresie. W rachunku dziedzin dziedziną definicji domen nie są relacje, ale domeny. W odniesieniu do bazy STUDENTS GROUP możemy mówić o domenie zmienne NAZWA(Wartości domeny to prawidłowe nazwy lub NOM STUD). (Wartości domeny są prawidłowymi numerami studentów).
Główną różnicą między rachunkiem dziedzinowym a rachunkiem krotek jest obecność dodatkowego zestawu predykatów, które umożliwiają wyrażenie tzw. warunków członkostwa. Jeśli R jest n-argumentową relacją z atrybutami (a1, a2, … an), to warunek przynależności ma postać R(ai1:Vi1,ai2:Vi2,…cel:Vim) gdzie (m<=n). Где в Vij это либо литерально заданная константа либо имя кортежной переменной. Условие членства принимает значение истина, только в том случае если в отношении R существует кортеж, содержащий следующие значения указанных атрибутов. Если от Vij константа то на атрибут aij накладывается жёсткое условие независящее от текущих доменных переменных. Если же Vij имя доменной переменной то условие членства может принимать различные значения при разных значениях этой переменной.
Predykat to funkcja logiczna, która dla jakiegoś argumentu zwraca wartość prawda lub fałsz. Relację można traktować jako predykat, którego argumenty są atrybutami danej relacji. Jeśli w relacji występuje określony zbiór krotek, to predykat da wynik prawdziwy, w przeciwnym razie da wynik fałszywy.
Pod wszystkimi innymi względami wzory i wyrażenia rachunku dziedzinowego wyglądają podobnie do wzorów i wyrażeń rachunku krotek. Relacyjne obliczanie domeny jest podstawą większości zapytań w języku opartym na formularzach.
Powiązana informacja.
Model danych to zbiór struktur danych i operacji służących do ich przetwarzania. Za pomocą modelu danych można wizualnie przedstawić strukturę obiektów i relacje między nimi. Terminologię dotyczącą modeli danych charakteryzują pojęcia „element danych” i „obowiązujące reguły”. Element danych opisuje dowolny zestaw danych, a reguły asocjacji definiują algorytmy łączenia elementów danych. Do chwili obecnej opracowano wiele różnych modeli danych, jednak w praktyce stosowane są trzy główne. Istnieją hierarchiczne, sieciowe i relacyjne modele danych. W związku z tym mówią o hierarchicznych, sieciowych i relacyjnych systemach DBMS.
O Hierarchiczny model danych. Hierarchicznie zorganizowane dane są bardzo powszechne w życiu codziennym. Przykładowo struktura uczelni to wielopoziomowa struktura hierarchiczna. Hierarchiczna (drzewiasta) baza danych składa się z uporządkowanego zbioru elementów. W tym modelu elementy początkowe dają początek innym elementom, a te z kolei dają początek kolejnym. Każdy element podrzędny ma tylko jeden element nadrzędny.
Struktury organizacyjne, spisy materiałów, spisy treści w książkach, plany projektów i wiele innych zbiorów danych można przedstawić w formie hierarchicznej. Integralność powiązań między przodkami i potomkami zostaje automatycznie zachowana. Podstawowa zasada: żadne dziecko nie może istnieć bez rodzica.
Główną wadą tego modelu jest konieczność wykorzystania hierarchii, która była podstawą bazy danych podczas projektowania. Konieczność ciągłej reorganizacji danych (a często też niemożność tej reorganizacji) doprowadziła do powstania modelu bardziej ogólnego – modelu sieciowego.
O Model danych sieciowych. Podejście sieciowe do organizacji danych jest rozwinięciem podejścia hierarchicznego. Model ten różni się od modelu hierarchicznego tym, że każdy wygenerowany element może mieć więcej niż jeden element generujący. ■
Ponieważ sieciowa baza danych może bezpośrednio reprezentować wszelkiego rodzaju relacje właściwe danym odpowiedniej organizacji, po danych można nawigować, eksplorować i odpytywać na różne sposoby, co oznacza, że model sieci nie jest ograniczony tylko jedną hierarchią. Aby jednak skierować zapytanie do sieciowej bazy danych, należy zagłębić się w jej strukturę (posiadać pod ręką schemat tej bazy) i opracować mechanizm nawigacji po bazie danych, co jest istotną wadą tego modelu bazy danych .
Relacyjny model danych. Podstawową ideą relacyjnego modelu danych jest reprezentowanie dowolnego zestawu danych w postaci dwuwymiarowej tabeli. W najprostszej formie model relacyjny opisuje pojedynczą dwuwymiarową tabelę, ale najczęściej model opisuje strukturę i relacje między kilkoma różnymi tabelami.
Relacyjny model danych
Zatem celem systemu informacyjnego jest przetwarzanie dane o obiekty realny świat, biorąc pod uwagę znajomości pomiędzy obiektami. W teorii baz danych dane są często nazywane danymi atrybuty i obiekty - podmioty. Obiekt, atrybut i połączenie to podstawowe pojęcia I.S.
Obiekt(lub esencja) jest czymś, co istnieje i rozpoznawalny, to znaczy przedmiot można nazwać tym „czymś”, dla czego istnieje nazwa i sposób na odróżnienie jednego podobnego przedmiotu od drugiego. Obiektem jest na przykład każda szkoła. Przedmiotami są także osoba, klasa w szkole, firma, stop, związek chemiczny itp. Obiektami mogą być nie tylko przedmioty materialne, ale także bardziej abstrakcyjne pojęcia, odzwierciedlające świat rzeczywisty. Na przykład wydarzenia, regiony, dzieła sztuki; książki (nie jako produkty drukowane, ale jako dzieła), spektakle teatralne, filmy; normy prawne, teorie filozoficzne itp.
Atrybut(Lub dany)- jest to pewien wskaźnik charakteryzujący dany obiekt i przyjmujący określoną wartość liczbową, tekstową lub inną dla konkretnej instancji obiektu. System informacyjny operuje zbiorami obiektów zaprojektowanymi w odniesieniu do danej dziedziny tematycznej, wykorzystując specyfikę wartości atrybutów(dane) niektórych obiektów. Na przykład potraktujmy zajęcia w szkole jako zbiór obiektów. Liczba uczniów w klasie to wielkość, która przyjmuje wartość liczbową (w jednej klasie jest 28 uczniów, w drugiej 32). Nazwa klasy to podana wartość, która przyjmuje wartość tekstową (jedna ma 10A, druga 9B, itd.).
Rozwój relacyjnych baz danych rozpoczął się pod koniec lat 60., kiedy pojawiły się pierwsze prace omawiające; możliwość wykorzystania przy projektowaniu baz danych znanych i naturalnych sposobów prezentacji danych – tzw. tabelarycznych modeli datalogicznych.
Za twórcę teorii relacyjnych baz danych uważa się pracownika IBM, dr E. Codda, który opublikował artykuł 6 czerwca 1970 r. Relacyjny model danych dla dużych współdzielonych banków danych(Relacyjny model danych dla dużych zbiorczych banków danych). W tym artykule jako pierwszy użyto terminu „relacyjny model danych”. Teoria relacyjnych baz danych, opracowana w latach 70. w USA przez dr E. Codda, ma potężną podstawę matematyczną opisującą zasady efektywnej organizacji danych. Ramy teoretyczne opracowane przez E. Codda stały się podstawą rozwoju teorii projektowania baz danych.
E. Codd, z wykształcenia matematyk, zaproponował wykorzystanie aparatu teorii mnogości (suma, przecięcie, różnica, iloczyn kartezjański) do przetwarzania danych. Udowodnił, że dowolny zbiór danych można przedstawić w postaci dwuwymiarowych tablic specjalnego rodzaju, zwanych w matematyce „relacjami”.
Relacyjny Za bazę danych uważa się taką, w której wszystkie dane prezentowane są użytkownikowi w postaci prostokątnych tabel wartości danych, a wszelkie operacje na bazie danych sprowadzają się do manipulacji tabelami.
Stół składa się z kolumny (pola) I linie (rekordy); ma unikalną nazwę w bazie danych. Tabela odzwierciedla Rodzaj obiektu prawdziwy świat (podmiot), i każda z niej string jest konkretnym obiektem. Każda kolumna tabeli jest zbiorem wartości dla konkretnego atrybutu obiektu. Wartości wybierane są ze zbioru wszystkich możliwych wartości atrybutu obiektu, który jest tzw domena.
W najbardziej ogólnej formie domenę definiuje się poprzez określenie podstawowego typu danych, do którego należą elementy domeny, oraz dowolnego wyrażenia logicznego zastosowanego do elementów danych. Jeśli ocenisz warunek logiczny dla elementu danych i wynik będzie prawdziwy, wówczas element ten należy do domeny. W najprostszym przypadku domenę definiuje się jako ważny potencjalny zbiór wartości tego samego typu. Na przykład zbiór dat urodzenia wszystkich pracowników stanowi „domenę dat urodzenia”, a nazwiska wszystkich pracowników stanowią „domenę nazwisk pracowników”. Domena daty urodzenia musi mieć typ danych dotyczący punktu w czasie, a domena nazwisk pracowników musi mieć typ danych znakowy.
Jeśli dwie wartości pochodzą z tej samej domeny, można dokonać porównania między nimi. Na przykład, jeśli z dziedziny dat urodzenia zostaną pobrane dwie wartości, można je porównać i określić, który pracownik jest starszy. Jeśli wartości pochodzą z różnych dziedzin, ich porównanie jest niedozwolone, ponieważ najprawdopodobniej nie ma to sensu. Na przykład nic konkretnego nie wyniknie z porównania imienia i nazwiska pracownika oraz daty jego urodzenia.
Każda kolumna (pole) ma nazwę, która jest zwykle wpisana na górze tabeli. Projektując tabele w obrębie konkretnego SZBD, możliwe jest wybranie dla każdego pola jego typ, czyli zdefiniować zbiór reguł jego wyświetlania, a także określić operacje, które można wykonać na danych przechowywanych w tym polu. Zestawy typów mogą się różnić w zależności od różnych systemów DBMS.
Nazwa pola musi być unikalna w tabeli, ale różne tabele mogą zawierać pola o tej samej nazwie. Każda tabela musi mieć co najmniej jedno pole; Pola ułożone są w tabeli zgodnie z kolejnością występowania ich nazw w momencie jej tworzenia. W przeciwieństwie do pól, ciągi znaków nie mają nazw; ich kolejność w tabeli nie jest określona, a ich liczba jest logicznie nieograniczona.
Ponieważ wiersze w tabeli nie są uporządkowane, nie można wybrać wiersza według jego pozycji - nie ma wśród nich „pierwszego”, „drugiego” ani „ostatniego”. Każda tabela ma jedną lub więcej kolumn, których wartości jednoznacznie identyfikują każdy z jej wierszy. Taka kolumna (lub kombinacja kolumn) nazywa się główny klucz. Do numerowania rekordów w tabeli często wprowadza się sztuczne pole. Takim polem może być np. jego pole porządkowe, które może zapewnić niepowtarzalność każdego rekordu w tabeli. Klucz musi mieć następujące właściwości.
Wyjątkowość. W dowolnym momencie żadne dwie różne krotki relacji nie mają tej samej wartości dla kombinacji atrybutów zawartych w kluczu. Oznacza to, że w tabeli nie mogą znajdować się dwa wiersze o tym samym numerze identyfikacyjnym lub numerze paszportu.
Minimalizm.Żadnego z atrybutów zawartych w kluczu nie można wykluczyć z klucza bez naruszenia unikalności. Oznacza to, że nie należy tworzyć klucza, który zawiera zarówno numer paszportu, jak i numer identyfikacyjny. Wystarczy użyć dowolnego z tych atrybutów, aby jednoznacznie zidentyfikować krotkę. Nie należy także umieszczać w kluczu atrybutu, który nie jest unikalny, tzn. używanie kombinacji numeru identyfikacyjnego i nazwiska pracownika jako klucza jest zabronione. Wykluczając nazwisko pracownika z klucza, każdy wiersz można nadal jednoznacznie zidentyfikować.
Każda relacja ma przynajmniej jeden możliwy klucz, gdyż suma wszystkich jej atrybutów spełnia warunek niepowtarzalności – wynika to z samej definicji relacji.
Jeden z możliwych kluczy jest wybierany losowo jako klucz podstawowy. Pozostałe możliwe klucze, jeśli istnieją, są brane pod uwagę klucze alternatywne. Na przykład, jeśli jako klucz podstawowy wybierzesz numer identyfikacyjny, kluczem alternatywnym będzie numer paszportu.
Relacja tabel jest najważniejszym elementem relacyjnego modelu danych. Jest obsługiwany klucz obcy.
Opisując model relacyjnej bazy danych, często używa się różnych terminów dla tego samego pojęcia, w zależności od poziomu opisu (teoria lub praktyka) i systemu (Access, SQL Server, dBase). W tabeli 2.3 zawiera podsumowanie używanych terminów.
Tabela 2.3. Terminologia baz danych
Teoria baz danych____________ Relacyjne bazy danych_________ SQL Server __________
Tabela relacji Tabela Tabela
Wiersz rekordu krotki
Pole atrybutu_______________Kolumna
Relacyjne bazy danych
Relacyjna baza danych to zbiór relacji zawierających wszystkie informacje, które muszą być przechowywane w bazie danych. Oznacza to, że baza danych reprezentuje zestaw tabel niezbędnych do przechowywania wszystkich danych. Tabele relacyjnej bazy danych są ze sobą logicznie powiązane.Wymagania dotyczące projektowania relacyjnej bazy danych w ogóle można sprowadzić do kilku zasad.
О Każda tabela ma w bazie danych unikalną nazwę i składa się z wierszy tego samego typu.
O Każda tabela składa się z określonej liczby kolumn i wartości. W kolumnie z jednym wierszem nie można zapisać więcej niż jednej wartości. Przykładowo, jeśli istnieje tabela z informacjami o autorze, dacie publikacji, nakładzie itp., to w kolumnie z nazwiskiem autora nie można przechowywać więcej niż jednego nazwiska. Jeśli książka jest napisana przez dwóch lub więcej autorów, konieczne będzie skorzystanie z dodatkowych tabel.
O W żadnym momencie w tabeli nie będą dwa wiersze, które się powielają. Wiersze muszą różnić się co najmniej jedną wartością, aby móc jednoznacznie zidentyfikować dowolny wiersz w tabeli.
О Każda kolumna ma przypisaną unikalną nazwę w tabeli; ustawiony jest dla niego określony typ danych, aby w tej kolumnie umieszczane były jednorodne wartości (daty, nazwiska, numery telefonów, kwoty pieniężne itp.).
O Pełna zawartość informacyjna bazy danych jest reprezentowana jako jawne wartości samych danych i jest to jedyna metoda reprezentacji. Na przykład relacje między tabelami opierają się na danych przechowywanych w odpowiednich kolumnach, a nie na podstawie jakichkolwiek wskaźników sztucznie definiujących relacje.
О Podczas przetwarzania danych masz swobodny dostęp do dowolnego wiersza lub dowolnej kolumny tabeli. Wartości zapisane w tabeli nie nakładają żadnych ograniczeń na kolejność dostępu do danych. Opis kolumn,