Model relacyjny dane
Model relacyjny oparty jest na teoretycznej koncepcji relacji. W dyscyplinach matematycznych istnieje pojęcie ʼʼ nastawienie ʼʼ (relacja), której fizyczna reprezentacja to stół ... Stąd nazwa modelu - relacyjny .
W odniesieniu do bazy danych pojęcia „relacyjna baza danych” i „tabelaryczna baza danych” są synonimami. Relacyjne bazy danych są najbardziej rozpowszechnione na świecie. Prawie wszystkie produkty bazodanowe utworzone od późnych lat siedemdziesiątych są relacyjne.
W 1970 roku pojawiły się artykuły omawiające możliwości wykorzystania różnych tabelarycznych modeli danych. Najważniejszym z nich był artykuł pracownika firmy IBM dr E.F. Codd (Relational Model of Data for Large Shared Data Banks. CACM 13: 6, czerwiec 1970), gdzie po raz pierwszy zastosował semestr „relacyjny model danych” ... Projekt System R powstał w laboratorium badawczym IBM Corporation. Ten projekt został stworzony z cel udowodnić praktyczność modelu relacyjnego. Relacyjny DBMS odnosi się do DBMS drugie pokolenie.
Cele tworzenie relacyjnego modelu danych:
1. Zapewnienie wyższego stopnia niezależności od danych.
2. Stworzenie mocne podstawy rozwiązywanie problemów spójności i nadmiarowości danych.
3. Rozszerzenie języków zarządzania danymi poprzez włączenie operacji na zbiorach.
Systemy komercyjne oparte na relacyjnym modelu danych zaczęły pojawiać się na przełomie lat 70. i 80. Obecnie istnieje kilkaset typów różnych relacyjnych DBMS.
Model relacyjny to wygodna i najczęściej stosowana forma reprezentacji danych w formie stoły (związek ). Każdy związek ma nazwa i składa się z nazwanych atrybuty (kolumny) danych. Jedną z podstawowych zalet modelu relacyjnego jest jego jednolitość... Wszystkie dane są przechowywane w tabelach, w których każdy wiersz ma ten sam format. Każdy wiersz w tabeli przedstawia jakiś obiekt ze świata rzeczywistego lub relację między obiektami.
Podstawowe pojęcia, według których definiowany jest model relacyjny, są następujące:
1. relacyjna baza danych - zbiór znormalizowanych relacji;
2. nastawienie - plik, tabela płaska, składająca się z kolumn i wierszy; tabela, w której każde pole jest atomowe;
3. domena - kruszywo dopuszczalne wartości, z którego pobierana jest wartość odpowiedniego atrybutu pewnej relacji. Z programistycznego punktu widzenia domena - ϶ᴛᴏ typ danych;
4. wszechświat - zbiór wartości dla wszystkich pól lub zbioru domen;
5. orszak - rekord, wiersz tabeli;
6. liczność - liczba wierszy w tabeli;
7. atrybuty – nazwane pola, kolumny tabeli;
8. stopień nastawienia - liczba pól (kolumn);
9. diagram relacji - uporządkowana lista nazw atrybutów;
10. schemat relacyjnej bazy danych - zestaw schematów relacji;
11. klucz podstawowy - unikalny identyfikator z niepowtarzalnymi rekordami - kolumna lub podzbiór kolumn, które jednoznacznie identyfikują wiersze.
Zwykle nazywany jest klucz podstawowy, który zawiera więcej niż jedną kolumnę liczba mnoga lub łączny lub złożony lub super klucz .
Reguła integralności obiektu stwierdza, że \u200b\u200bklucz podstawowy nie powinien być całkowicie ani częściowo pusty.
Związek między tymi pojęciami ilustruje rys. 4.5.
| № | Pełne imię i nazwisko | Rok urodzenia | Pozycja | Departament |
| 1. | Iwanow I. I. | Głowa departament | 22 | |
| 2. | S. S. Sidorov | Prof. | 22 | |
| 3. | Andreeva G.G. | Prof. | 22 | |
| 4. | Tsvetkova S. S. | Docent | ||
| 5. | Kozlov K.K. | Docent | 22 | |
| 6. | Petrov P. P. | Sztuka. Obrót silnika. | 22 |
|
|||
figa. 4.5. Podstawowe pojęcia relacyjnego modelu danych.
Czasami różne kolumny są wybierane jako klucz podstawowy w tabeli. Dedykowany klucz to klucz, który jest jawnie wymieniony w schemacie relacyjnym. W przeciwnym razie mówi się o kluczu niejawnym, możliwym kluczu lub kluczu kandydującym.
12. klucz zewnętrzny - ϶ᴛᴏ kolumna lub podzbiór kolumn z jednej tabeli, które mogą służyć jako klucz podstawowy dla innej tabeli. Klucz obcy tabeli jest odniesieniem do klucza podstawowego innej tabeli. Ponieważ celem budowania bazy danych jest przechowywanie wszystkich danych, jeśli to możliwe, w jednym przypadku, to jeśli dany atrybut występuje w kilku relacjach, to jego obecność zwykle odzwierciedla pewien związek między wierszami tych relacji.
Klucze obce implementują relacje między tabelami bazy danych.
Klucz obcy, podobnie jak klucz podstawowy, może być kombinacją kolumn. W praktyce klucz obcy zawsze będzie złożony, jeśli odnosi się do złożonego klucza podstawowego innej tabeli. Liczba kolumn i ich typy danych w kluczu podstawowym i obcym muszą być zgodne.
Jeśli tabela jest powiązana z kilkoma innymi tabelami, może mieć kilka kluczy obcych.
Każdy tabela relacyjna ma następujące nieruchomości:
Ma nazwę ĸᴏᴛᴏᴩᴏᴇ różni się od nazw wszystkich innych tabel;
Dane w komórkach tabeli muszą być strukturalnie niepodzielne. Niedopuszczalne jest, aby komórka tabeli zawierała więcej niż jedną informację. Na przykładnumer i seria paszportu powinny znajdować się w różnych kolumnach tabeli;
Wszystkie kolumny w tabeli są jednorodne, ᴛ.ᴇ. wszystkie elementy w kolumnie mają ten sam typ (numeryczny, znakowy itp.) i długość;
Każda kolumna ma unikalną nazwę;
W tabeli nie ma identycznych wierszy;
Kolejność wierszy i kolumn musi być dowolna, niezależnie od ich zmiany kolejności, relacja pozostanie taka sama, a zatem będzie miała to samo znaczenie.
Podstawowe pojęcia relacyjnego modelu danych to pojęcia i typy. Klasyfikacja i cechy kategorii „Podstawowe pojęcia relacyjnego modelu danych” 2017, 2018.
Model danych sieci
W MDS podstawowe dane i relacje między nimi są reprezentowane jako zorientowana sieć (wierzchołki to dane, łuki to relacje).
Sieciowe bazy danych miały kilka zalet:
· Elastyczność.Wiele relacji rodzic / potomek umożliwiło sieciowej bazie danych przechowywanie danych, które były bardziej złożone niż prosta hierarchia.
· Normalizacja. Pojawienie się standardu CODASYL spopularyzowało model sieciowy, a dostawcy minikomputerów, tacy jak Digital Equipment Corporation i Data General, wdrożyli sieciowe systemy DBMS.
· Szybkie działanie. Pomimo swojej wielkiej złożoności sieciowe bazy danych osiągnęły wydajność porównywalną z wydajnością hierarchicznych baz danych. Zbiory były reprezentowane przez wskaźniki do fizycznych rekordów danych, aw niektórych systemach administrator mógł określić grupowanie danych na podstawie wielu relacji.
Pewnie, sieciowe bazy danych miały wady. Podobnie jak hierarchiczne bazy danych, sieciowe bazy danych były bardzo sztywne. Zestawy relacji i struktury rekordów musiały zostać określone z wyprzedzeniem. Zmiana struktury bazy danych oznaczała zwykle przebudowę całej bazy danych.
Zarówno hierarchiczna, jak i sieciowa baza danych były narzędziami programistów. Realizacja żądań użytkowników była często opóźniona o tygodnie lub miesiące, a do czasu pojawienia się programu informacje, które dostarczał, były często bezużyteczne.
W przypadku danych modelu sieci możesz następujące czynności:
· dokonać zapisu w bazie danych (w zależności od rodzaju włączenia rekord można dodać do relacji grupowej lub nie);
· dołączyć rekord do relacji grupowej (połączyć rekord z właścicielem);
· przełącznik (powiąż rekord podrzędny z rekordem właściciela w tej samej relacji grupowej);
· zmienić wartość elementów wcześniej pobranego rekordu;
· pobrać rekord według wartości klucza lub sekwencyjnie w ramach relacji grupowej;
· usuń - przy usuwaniu rekordu należy wziąć pod uwagę klasy członkostwa;
· wykluczyć z relacji grupowej (przerwać połączenie między rekordem właściciela a rekordem podrzędnym).
Relacyjny model danych.
Model relacyjnynazywana jest bazą danych, w której wszystkie dane dostępne dla użytkownika są zorganizowane w postaci tabel, a wszystkie operacje na danych sprowadzają się do operacji na tych tabelach... Dwuwymiarowy stół to wizualna forma reprezentacji relacji. Tabela zawiera wiersze (rekordy) i kolumny (kolumny). Każda linia ma taką samą strukturę i składa się z pól. Wiersze tabeli odpowiadają krotkom, a kolumny atrybutom relacji. Zaletą modelu relacyjnego jest prostota, jasność i wygoda wykonanie fizyczne na komputerze. To właśnie prostota i przejrzystość dla użytkownika były głównym powodem korzystania z niego przez użytkownika. Problem wydajności przetwarzania tego typu danych okazał się technicznie całkiem rozwiązalny. Główne wady to: brak standardowe narzędzia identyfikacja indywidualne zapisy oraz złożoność opisywania hierarchicznych i sieć... Przykłady zagranicznych relacyjnych DBMS to: Visual FoxPro i Access (Microsoft).
Główne elementy modelu relacyjnego: Relacja jest najważniejszą koncepcją i jest dwuwymiarową tabelą zawierającą pewne dane. Podmiot to obiekt o dowolnym charakterze, o którym dane są przechowywane w bazie danych. Dane podmiotu są przechowywane w związku z. Atrybuty - właściwości, które charakteryzują jednostkę. Jest nazwany w tabeli i odpowiada nagłówkowi kolumny tabeli. Domena to zbiór wszystkich możliwych wartości określonego atrybutu relacji. Schemat relacji (nagłówek relacji) to lista nazw atrybutów. Klucz podstawowy (klucz relacji) jest atrybutem relacji, który jednoznacznie identyfikuje każdy z jej dywanów. Jeśli krotki są identyfikowane tylko przez konkatenację wartości kilku atrybutów, wówczas relacja ma klucz złożony. Relacja może zawierać wiele kluczy. Jeden z kluczy jest zawsze deklarowany jako podstawowy, jego wartości nie mogą być aktualizowane. Wszystkie inne klucze relacji nazywane są kluczami kandydującymi.
Zalety modelu relacyjnego:
Prostota i łatwość zrozumienia dla użytkownika. Jedyną używaną konstrukcją informacyjną jest „tabela”;
Surowe zasady projektowania oparte na aparacie matematycznym;
Pełna niezależność od danych. Zmiany w aplikacji, gdy zmiany relacyjnej bazy danych są minimalne;
Aby organizować zapytania i pisać oprogramowanie aplikacyjne, nie ma potrzeby znajomości konkretnej organizacji bazy danych w trakcie pamięć zewnętrzna.
Wady modelu relacyjnego:
Tematyka nie zawsze daje się przedstawić w formie „tabel”;
W wyniku logicznego projektu pojawia się wiele „tabel”. Utrudnia to zrozumienie struktury danych;
DB zajmuje stosunkowo dużą ilość pamięci zewnętrznej;
Stosunkowo niska prędkość dostępu do danych.
Trzy elementy składowe relacyjnego modelu danych to:
§ strukturalny
§ manipulacyjny
§ holistyczne
Część konstrukcyjna Model określa, że \u200b\u200bjedyną strukturą danych jest znormalizowany stosunek par. Relacje są wygodnie przedstawiane w postaci tabel, w których każdy wiersz jest krotką, a każda kolumna jest atrybutem zdefiniowanym w jakiejś domenie. To nieformalne podejście do pojęcia relacji daje programistom i użytkownikom bardziej znaną formę prezentacji, w której relacyjna baza danych jest skończonym zestawem tabel.
Część manipulacji Model definiuje dwa fundamentalne mechanizmy manipulowania danymi - algebrę relacyjną i rachunek relacyjny. Główną funkcją manipulacyjnej części modelu relacyjnego jest zapewnienie miary względności dowolnego konkretnego języka relacyjnych baz danych: język nazywany jest relacyjnym, jeśli ma nie mniej wyrazistości i mocy niż algebra relacyjna lub rachunek relacyjny.
Część integralna Model definiuje wymagania dotyczące integralności encji i integralności odniesienia. Pierwszym wymaganiem jest to, że każda relacja musi mieć klucz podstawowy. Wymaganie referencyjnej integralności lub wymaganie dotyczące klucza obcego polega na tym, że dla każdej wartości klucza obcego, która pojawia się w relacji odwołującej się, relacja, do której istnieje odwołanie, musi mieć krotkę z tą samą wartością klucza podstawowego lub wartość klucza obcego musi być niezdefiniowana (tj. nie wskazuj na nic).
10. Model "relacji między podmiotami" Model ER, normalizacja danych.
Model ER (model Entity-Relationship) jest na wysokim poziomie model koncepcyjny data, która została opracowana w 1976 roku w celu uproszczenia zadania projektowania bazy danych. Podstawowe pojęcia modelu relacji jednostka obejmują typy jednostek, relacje i atrybuty.
Podstawową koncepcją modelowania ER jest typ jednostki reprezentujący wiele obiektów świata rzeczywistego o tych samych właściwościach. Typ bytu charakteryzuje się niezależnym istnieniem i może być przedmiotem o istnieniu fizycznym (rzeczywistym) lub przedmiotem o istnieniu pojęciowym (abstrakcyjnym).
Każde jednoznacznie identyfikowalne wystąpienie typu jednostki jest po prostu określane jako jednostka. Każdy typ jednostki jest identyfikowany za pomocą nazwy i listy właściwości i jest podzielony na dwa typy: silny słaby. Istnienie słabego typu zależy od innego, silnego - nie.
W użyciu odmianyNa podstawie modelu ER większośćnowoczesne podejście do projektowania baz danych (głównie relacyjnych). Model został zaproponowany przez Chen w 1976 roku. Modelowanie dziedzinowe opiera się na wykorzystaniu diagramów graficznych zawierających niewielką liczbę różnych elementów. W związku z przejrzystością prezentacji schematów koncepcyjnych baz danych Modele ER są szeroko stosowane w CASE-narzędzia przeznaczone do komputerowego wspomagania projektowania relacyjnych baz danych.
Do modelowania struktury danych wykorzystywane są diagramy ER (diagramy relacji encji), które w formie wizualnej przedstawiają relacje między encjami. W związku z tym diagramy ER stały się szeroko rozpowszechnione w systemach CASE, które obsługują wspomagane komputerowo projektowanie relacyjnych baz danych. Najczęściej spotykane są diagramy wykonane zgodnie ze standardem 1DEF1X, z którego korzystają najpopularniejsze systemy CASE (w szczególności ERwin, Design / IDEF, Power Designer). Podstawowe pojęcia diagramu ER to esencja, połączeniei atrybut.
Esencja
Esencja -jest to rzeczywisty lub wirtualny obiekt, który jest istotny dla rozważanego obszaru tematycznego, o którym informacje mają być przechowywane. Nie wchodząc w szczegóły, możemy założyć, że encje odpowiadają tabelom modelu relacyjnego. Każda jednostka musi mieć następujące właściwości:
1. są wyjątkowe identyfikator;
Każdy podmiot może mieć dowolną liczbę relacji z innymi podmiotami.
Na diagramach modeli ER jednostka jest reprezentowana jako prostokąt zawierający nazwę jednostki.
Część 2. Relacyjny model danych
Model relacyjny to wygodna i najczęściej stosowana forma prezentacji danych w postaci tabeli.
W przeciwieństwie do hierarchicznych i modele sieciowe, ten sposób prezentacji:
1. zrozumiały dla użytkownika nie będącego programistą;
2. umożliwia łatwą zmianę schematu - dołączanie nowych elementów danych i rekordów bez zmiany odpowiednich podukładów;
3. Zapewnia elastyczność potrzebną do obsługi nieoczekiwanych żądań. Ponadto każdą sieć lub schemat hierarchiczny można przedstawić za pomocą relacji dwuwymiarowych.
Jedną z głównych zalet modelu relacyjnego jest jego jednolitość. Wszystkie dane są traktowane jako przechowywane w tabelach, w których każdy wiersz ma ten sam format. Każdy wiersz w tabeli przedstawia jakiś obiekt ze świata rzeczywistego lub relację między obiektami.
Użytkownik modelu musi sam zdecydować, czy odpowiadające mu byty realnego świata są jednorodne. Rozwiązuje to problem przydatności modelu do zamierzonego zastosowania.
Podstawowe pojęcia, według których definiowany jest model relacyjny, są następujące:
1. domena,
2. postawa,
3. podwójne,
4. liczność,
5. atrybuty,
6 stopni,
7. klucz podstawowy.
Związek między tymi pojęciami przedstawiono na rysunku 7.
Postać: 7. Podstawowe pojęcia modelu relacyjnego
Tablica 7.
Pojęcia te reprezentują specjalną terminologię wprowadzoną przez autorów podstaw teoretycznych, ale mają również bardziej znane analogi (ale nie wszystkie odpowiedniki), których zgodność przedstawiono w poniższej tabeli 1.
Domena jest zbiorem wartości, z których pobierane są wartości odpowiednich atrybutów określonej relacji. Z programistycznego punktu widzenia domena to typ danych zdefiniowany przez system (standard) lub przez użytkownika oraz zestaw dodatkowych ograniczeń nałożonych na te dane.
W dyscyplinach matematycznych pojęcie „tabeli” odpowiada pojęciu „relacji” (relacji). Stąd nazwa modelu - relacyjny. Oznacza to, że w odniesieniu do baz danych pojęcia „relacyjna baza danych” i „tabelaryczna baza danych” są zasadniczo synonimami.
Klucz podstawowy jest kolumną lub pewnym podzbiorem kolumn, które są unikalne, to znaczy jednoznacznie definiują wiersze. Klucz podstawowy, który zawiera więcej niż jedną kolumnę, nazywany jest wieloma, połączonymi lub złożonymi. Reguła integralności obiektu stwierdza, że \u200b\u200bklucz podstawowy nie może być całkowicie ani częściowo pusty, to znaczy nie może mieć wartości zero.
Pozostałe klucze, które mogą być również używane jako klucze podstawowe, nazywane są potencjalnymi lub alternatywny Klucze.
Klucz zewnętrzny to kolumna lub podzbiór jednej tabeli, który może służyć jako klucz podstawowy dla innej tabeli. Klucz obcy tabeli jest odniesieniem do klucza podstawowego innej tabeli. Reguła więzów integralności stwierdza, że \u200b\u200bklucz obcy może być pusty lub odpowiadać wartości klucza podstawowego, do którego się odnosi. Klucze obce są integralną częścią modelu relacyjnego, ponieważ implementują relacje między tabelami bazy danych.
Klucz obcy, podobnie jak klucz podstawowy, może być również kombinacją kolumn. W praktyce klucz obcy zawsze będzie złożony (wielokolumnowy), jeśli odnosi się do złożonego klucza podstawowego w innej tabeli. Oczywiście liczba kolumn i ich typy danych w kluczu podstawowym i obcym są takie same.
Jeśli tabela jest powiązana z wieloma innymi tabelami, może mieć wiele kluczy obcych.
Model ma następujące wymagania dotyczące tabel:
1. dane w komórkach tabeli muszą być strukturalnie niepodzielne 1;
2. dane w jednej kolumnie muszą być tego samego typu;
3. każda kolumna musi być niepowtarzalna (podwójne kolumny nie są dozwolone);
4. Kolumny są ułożone w kolejności losowej;
5. wiersze są również umieszczane w tabeli w dowolnej kolejności;
6. Kolumny mają unikalne nazwy.
Ogólnie pojęcie modelu relacyjnego jest definiowane przez dwanaście poniższych reguł Codda (na wykładzie zasady podaje).
1. Zasada informacji. Wszystkie informacje w bazie danych należy podawać wyłącznie na poziomie logicznym i tylko w jeden sposób - w postaci wartości zawartych w tabelach.
2. Zasada gwarantowanego dostępu. Dostęp logiczny do każdego elementu danych (wartości atomowej) w relacyjnej bazie danych musi być zapewniony przy użyciu kombinacji nazwy tabeli, klucza podstawowego i nazwy kolumny.
3. Zasada obsługi nieprawidłowych wartości. Relacyjna baza danych musi obsługiwać nieprawidłowe wartości, które różnią się od ciągu znaków o zerowej długości, ciągu znaków białych znaków, zera lub dowolnej innej liczby i są używane do reprezentowania brakujących danych niezależnie od typu danych.
4. Reguła katalogu dynamicznego opartego na modelu relacyjnym. Opis bazy danych na poziomie logicznym musi mieć taką samą formę jak dane podstawowe, aby użytkownicy z odpowiednimi uprawnieniami mogli z nią pracować przy użyciu tego samego języka relacyjnego, którego używają do pracy z danymi podstawowymi.
5. Zasada pełnego języka danych. System relacyjny może wspierać inne języki oraz tryby interakcji z użytkownikiem (np. tryb pytań i odpowiedzi). Jednak musi istnieć co najmniej jeden język, którego operatory można przedstawić jako ciągi znaków zgodnie z dobrze zdefiniowaną składnią i który w pełni obsługuje następujące elementy:
Definicja danych;
Definicja widoków;
Przetwarzanie danych (interaktywne i oprogramowanie);
Warunki integralności;
Identyfikacja praw dostępu;
Granice transakcji (rozpoczęcie, zakończenie i anulowanie).
6. Zasada aktualizowania widoków. Wszelkie widoki, które teoretycznie można zaktualizować, powinny być dostępne do aktualizacji.
7. Zasada dodawania, aktualizacji i usuwania. Możliwość pracy z relacją jako pojedynczym operandem powinna istnieć nie tylko podczas odczytu danych, ale także podczas dodawania, aktualizowania i usuwania danych.
8. Zasada niezależności danych fizycznych. Programy użytkowe i narzędzia do pracy z danymi powinny na poziomie logicznym pozostać nienaruszone w przypadku jakichkolwiek zmian w sposobie przechowywania danych lub metodach dostępu do nich.
9. Zasada niezależności danych logicznych. Aplikacje danych i narzędzia powinny logicznie pozostać nienaruszone po wprowadzeniu jakichkolwiek zmian w bazowych tabelach, które teoretycznie pozwalają, aby dane zawarte w tych tabelach pozostały nienaruszone.
10. Zasada niezależności warunków integralności. Musi istnieć możliwość zdefiniowania warunków integralności specyficznych dla konkretnej relacyjnej bazy danych w podjęzyku relacyjnej bazy danych i przechowywania ich raczej w katalogu niż w aplikacji.
11. Zasada niezależności dystrybucji. Relacyjny DBMS nie powinien zależeć od potrzeb konkretnego klienta.
12. Zasada niepowtarzalności. Jeśli system relacyjny ma język niskiego poziomu (przetwarzający jeden rekord na raz), to nie powinno być możliwe użycie go do ominięcia reguł i warunków integralności wyrażonych w języku relacyjnym wysokiego poziomu (przetwarzanie kilku rekordów jednocześnie).
Reguła 2 określa rolę kluczy podstawowych w wyszukiwaniu informacji w bazie danych. Nazwa tabeli umożliwia znalezienie wymaganej tabeli, nazwa kolumny pozwala znaleźć wymaganą kolumnę, a klucz podstawowy pozwala znaleźć wiersz zawierający poszukiwany element danych.
Reguła 3 wymaga, aby brakujące dane można było przedstawić za pomocą nieprawidłowych wartości ( ZERO).
Zasada 4 mówi, że relacyjna baza danych musi się opisywać. Innymi słowy, baza danych musi zawierać zestaw tabele systemowe, opis struktury samej bazy danych.
Reguła 5 wymaga, aby DBMS używał języka relacyjnej bazy danych, takiego jak SQL. Taki język powinien wspierać wszystkie podstawowe funkcje DBMS - tworzenie bazy danych, odczytywanie i wprowadzanie danych, wdrażanie zabezpieczeń bazy danych itp.
Reguła 6 dotyczy wyświetlenia, które są tabelami wirtualnymi, które umożliwiają różnym użytkownikom wyświetlanie różnych części struktury bazy danych. To jedna z najtrudniejszych zasad do wdrożenia w praktyce.
Zasada 7 podkreśla, że \u200b\u200bbazy danych mają charakter zorientowany na zbiory. Wymaga, aby operacje dodawania, usuwania i aktualizowania mogły być wykonywane na wielu wierszach. Ta reguła ma na celu zablokowanie implementacji, które obsługują tylko operacje jednowierszowe.
Reguły 8 i 9 oznaczają oddzielenie użytkownika i program aplikacyjny z niskopoziomowej implementacji bazy danych. Twierdzą, że konkretna implementacja przechowywania lub dostępu stosowana w DBMS, a nawet zmiany w strukturze tabel bazy danych, nie powinny wpływać na zdolność użytkownika do pracy z danymi.
Zasada 10 stanowi, że język bazy danych musi obsługiwać ograniczenia nałożone na dane wejściowe i działania, które można wykonać na danych.
Zasada 11 stanowi, że język bazy danych musi zapewniać możliwość pracy z rozproszonymi danymi znajdującymi się w innych systemach komputerowych.
Wreszcie reguła 12 zapobiega wykorzystaniu innych możliwości bazy danych niż język bazy danych, ponieważ mogłoby to naruszyć integralność bazy danych.
Literatura
1. Data K . Wprowadzenie do systemów baz danych: na. z angielskiego. - M.: Nauka, 1980. - 463 str.
2. Groff J., Wainberg P. SQL: kompletny przewodnik / Per. z angielskiego. 2nd ed. К.: BHV, 2001.
baz danych, jeśli są oparte na tym modelu. Posiadanie modelu danych umożliwia porównanie konkretnych implementacji przy użyciu jednego wspólnego języka.Chociaż koncepcja modelu danych jest ogólna i można mówić o modelach hierarchicznych, sieciowych, semantycznych i innych, należy zauważyć, że w dziedzinie baz danych pojęcie to zostało wprowadzone przez Edgara Codda w odniesieniu do systemów relacyjnych i jest najbardziej efektywnie wykorzystywane w tym kontekście. Dowodzą tego próby bezpośredniego zastosowania podobnych modeli do organizacji przedrelacyjnych model relacyjny jest zbyt „duża”, ale dla organizacji postrelacyjnych okazuje się „mała”.
ogólna charakterystyka
Chociaż koncepcja relacyjny model danych pierwszy wprowadzony przez założyciela podejście relacyjne Edgar Codd, najczęstsza interpretacja relacyjny model danychnajwyraźniej należy do słynnego popularyzatora idei Codda Christophera Date'a, który powtarza je (z różnymi doprecyzowaniami) w prawie wszystkich swoich książkach (patrz np. K. Date. Wprowadzenie do Database Systems. 6th ed., M. ; SPb .: Williams - 2000). Zgodnie z interpretacją Data, model relacyjny składa się z trzech części opisujących różne aspekty podejście relacyjne: część konstrukcyjna, część manipulacyjna i część integralna.
W części strukturalnej modelu ustalono, że jedyna struktura ogólna 7 Po raz drugi w tym wykładzie argumentowano, że znormalizowana relacja n -arna jest jedyną ogólną strukturą danych używaną w relacyjnych bazach danych. Czas wyjaśnić, co rozumiemy przez ten termin struktura ogólna... Języki programowania z rozwiniętymi systemami typów zwykle mają konstrukcje o nazwie typy ogólne, parametryzowalne typy, konstruktory typów, generatory typów i tak dalej, umożliwiając wygenerowanie konkretnego typu danych na podstawie jego abstrakcyjnej (zwykle predefiniowanej) specyfikacji. Osobliwością takich typów jest to, że podstawowe operacje konkretnego typu są definiowane na poziomie tej abstrakcyjnej specyfikacji. Jednym z bardziej znanych przykładów jest składać czcionki do drukuna przykład w pascal... Gdy relacyjny model danych nie mówimy wprost, że relacja jest typem rodzajowym, ale w istocie jest. Operacje algebry relacyjnej są definiowane na poziomie abstrakcyjnej relacji i mają zastosowanie do wszelkich relacji wartości z określonymi nagłówkami. dane używane w relacyjnych bazach danych to znormalizowana relacja n -arna. Pojęcia dotyczące domen, atrybutów, krotek, nagłówka, treści i zmienny stosunek... W rzeczywistości w dwóch poprzednich częściach tego wykładu dokładnie zbadaliśmy pojęcia i właściwości elementu konstrukcyjnego model relacyjny.
Część manipulacyjna modelu definiuje dwa fundamentalne mechanizmy manipulowania relacyjnymi bazami danych - algebrę relacyjną i rachunek relacyjny... Pierwszy mechanizm oparty jest głównie na klasycznej teorii mnogości (z pewnymi wyjaśnieniami i uzupełnieniami), a drugi - na klasycznym aparacie logicznym rachunku predykatów pierwszego rzędu. Omówimy te mechanizmy bardziej szczegółowo w następnych wykładach, ale na razie zauważymy tylko, że główna funkcja części manipulacji model relacyjny polega na dostarczeniu miary względności dowolnego konkretnego języka relacyjnych baz danych: język nazywany jest relacyjnym, jeśli ma nie mniej wyrazistości i mocy niż algebra relacyjna, lub rachunek relacyjny.
Integralność jednostki i odniesienia
Wreszcie w części integralnej relacyjny model danych naprawiono dwa podstawowe wymagania dotyczące integralności, które powinny być obsługiwane w każdym relacyjnym systemie DBMS. Pierwsze wymaganie to tzw wymóg dotyczący integralności jednostki... Obiekt lub jednostka świata rzeczywistego w relacyjnych bazach danych odpowiada krotkom relacji. W szczególności wymaganiem jest, aby każda krotka o dowolnej wartości była relacją dowolnego zmienny stosunek musi być odróżnialna od jakiejkolwiek innej krotki tego wartości współczynnika przez złożone wartości predefiniowanego zestawu atrybutów zmienny stosunekczyli innymi słowy any zmienna relacji muszę mieć klucz podstawowy... Jak widzieliśmy w poprzedniej sekcji, to wymaganie jest automatycznie spełnione, jeśli podstawowe właściwości relacji nie są naruszone w systemie.
W rzeczywistości wymóg integralność jednostki całkowicie brzmi tak: dowolny zmienny stosunek klucz podstawowy musi istnieć i nie mieć wartości klucz podstawowy w krotkach wartościami są relacje zmienny stosunek nie powinien zawierać niezdefiniowane wartości ... Aby to sformułowanie było w pełni zrozumiałe, musimy przynajmniej pokrótce omówić to pojęcie nieokreślona wartość (ZERO).
Oczywiście teoretycznie każda krotka, która jest wprowadzana do trwałej relacji, powinna zawierać wszystkie cechy rzeczywistego bytu, który modeluje, a które chcemy przechowywać w bazie danych. Jednak w praktyce nie wszystkie te cechy mogą być znane do czasu, gdy jednostka musi zostać zatwierdzona w bazie danych. Prostym przykładem może być procedura zatrudniania osoby, której wynagrodzenie nie zostało jeszcze ustalone. W takim przypadku pracownik HR, który wpisze krotkę opisującą nowego pracownika w relacji PRACOWNICY po prostu nie może podać wartości atrybutu SLU_ZARP (dowolna wartość domeny PAYMENT_SIMES będzie błędnie scharakteryzować wynagrodzenie nowego pracownika).
Edgar Codd zasugerował użycie w takich przypadkach niezdefiniowane wartości. Nieokreślona wartość nie należy do żadnego typu danych i może znajdować się wśród wartości dowolnego atrybutu zdefiniowanego w dowolnym typie danych (chyba że jest to wyraźnie zabronione, gdy atrybut jest zdefiniowany). Jeśli a jest wartością jakiegoś typu danych lub NULL, op jest dowolną operacją arytmetyczną w dwóch miejscach tego typu danych (na przykład +), a poobcinać - operacja porównywania wartości tego typu (np. \u003d), to z definicji:
a op NULL \u003d NULL NULL op a \u003d NULL a lop NULL \u003d nieznany NULL lop a \u003d nieznany
Tutaj nieznana jest trzecia wartość logiczna lub typ logicznyo następujących właściwościach:
NIE nieznane \u003d nieznane prawdziwe AND nieznane \u003d nieznane prawdziwe LUB nieznane \u003d prawdziwe fałszywe AND nieznane \u003d fałszywe fałszywe LUB nieznane \u003d nieznane
(pamiętaj, że operacje AND i OR są przemienne) 8 Jak pokazuje doświadczenie autora, nie zawsze i nie wszyscy uczniowie pamiętają podstawowe operacje logiczne. Aby zagwarantować, przedstawiamy tabele prawdziwości operacji AND (& - spójnik), OR (- disjunction) i NOT (- negacja): I
prawdziwe
fałszywy
LUB
prawdziwe
fałszywy
NIE
prawdziwe
fałszywy
prawdziwe
prawdziwe
fałszywy
prawdziwe
prawdziwe
prawdziwe
fałszywy
prawdziwe
fałszywy
fałszywy
fałszywy
fałszywy
prawdziwe
fałszywy
Tak więc pierwszym z wymagań jest wymaganie integralność jednostki - oznacza, że \u200b\u200bklucz podstawowy musi w pełni identyfikować każdą jednostkę, a zatem jako część dowolnej wartości klucz podstawowy nie dozwolony niezdefiniowane wartości ... (W klasycznym model relacyjny wymóg ten dotyczy również możliwych kluczy; jak zostanie pokazane na kolejnych wykładach, w DBMS zorientowanych na SQL taki wymóg możliwe klucze niewspierany.)
Drugie wymaganie to tzw wymóg integralności referencyjnej, jest bardziej złożony. Oczywiście, jeśli relacje są znormalizowane, złożone byty świata rzeczywistego są reprezentowane w relacyjnej bazie danych jako kilka krotek kilku relacji. Na przykład wyobraź sobie, w czym chcesz reprezentować relacyjna baza danych jednostka DEPARTMENT z atrybutami DET_NUMBER (numer działu), DEPARTMENT_RASM (liczba pracowników) i DTD_SLU (zbiór pracowników działu). Dla każdego pracownika musisz zapisać SLU_NUMBER (numer pracownika), SLU_NAME (imię i nazwisko pracownika) i SLU_ZARP ( gaża pracownik). Jak zobaczymy na wykładzie 7, przy prawidłowym zaprojektowaniu odpowiedniej bazy danych pojawią się w niej dwie relacje: DEPARTMENTS (DEPARTMENT_NUMBER, DEPARTMENT_SIZM) (klucz podstawowy - (DT_NUMBER)) i PRACOWNICY (SERVICE_NUMBER, SERVICE_NAME, SLU_ZARP, SLU_OUT_NOM) (klucz podstawowy - (SLU_NUMBER)).
Jak widać, atrybut SLU_DEPARTMENT_NOM jest wprowadzany do relacji EMPLOYEES nie dlatego, że numer działu jest własnością własną pracownika, ale tylko po to, aby w razie potrzeby móc przywrócić pełną encję DEPARTMENT. Wartość atrybutu SLU_DEPARTMENT_NOM w dowolnej krotce relacji PRACOWNIK musi być zgodna z wartością atrybutu RELATED_NOM w jakiejś krotce relacji DEPARTMENT. Atrybut tego rodzaju (prawdopodobnie złożony) jest nazywany klucz obcy, ponieważ jego wartości wyjątkowo charakteryzują byty reprezentowane przez krotki jakiejś innej relacji (to znaczy ustalają swoje wartości klucz podstawowy). Oczywiście klucz obcy może być złożony, to znaczy może składać się z kilku atrybutów. Mówi się, że relacja, w której zdefiniowany jest klucz obcy, odnosi się do odpowiedniej relacji, w której znajduje się ten sam atrybut klucz podstawowy.
Żądanie integralność przez odniesienielub wymaganiem integralności klucza obcego jest to, że dla każdej wartości klucza obcego pojawiającej się w krotce relacji wartości odniesienia zmienny stosuneklub w relacji znaczeniowej zmienny stosunekłącze wskazuje na, powinna istnieć krotka o tej samej wartości klucz podstawowylub wartość klucza obcego musi być całkowicie niezdefiniowana (tj. nie wskazywać na nic) 9 W język SQL dopuszcza się kilka wariantów definicji klucza obcego, z których tylko jeden w pełni odpowiada podejściu klasycznemu. Bardziej szczegółowo omówimy to w następnych wykładach. ... W naszym przykładzie oznacza to, że jeśli dla pracownika określono numer działu, to ten dział musi istnieć.
Zauważ, że podobnie jak klucz podstawowy,
Jest to aplikacja do rozwiązywania problemów przetwarzania danych w takich gałęziach matematyki, jak teoria mnogości i logika pierwszego rzędu.
Relacyjne bazy danych są zbudowane na relacyjnym modelu danych.
Relacyjny model danych zawiera następujące komponenty:
- Aspekt strukturalny (komponent) - dane w bazie danych to zbiór relacji.
- Aspekt (składnik) integralności - relacje (tabele) spełniają określone warunki integralności. RMD obsługuje deklaratywne ograniczenia integralności na poziomie domeny (typu danych), poziomie relacji i na poziomie bazy danych.
- Aspekt (komponent) przetwarzania (manipulacji) - RMD obsługuje operatory manipulowania relacjami (algebra relacyjna, rachunek relacyjny).
Podstawowe pojęcia relacyjnych baz danych to typ danych, relacja, jednostka, atrybut, domena, krotka, klucz podstawowy.
Pojęcie typ danych w relacyjnym modelu danych jest całkowicie podobny do pojęcia typu danych w językach programowania. Zazwyczaj nowoczesne relacyjne bazy danych umożliwiają przechowywanie znaków, danych liczbowych, ciągów bitów, specjalistycznych danych liczbowych (takich jak pieniądze) i danych specjalnych (data, czas, przedział czasu).
Nastawienie jest najważniejszym pojęciem i jest dwuwymiarową tabelą zawierającą pewne dane.
Esencja– jakiś izolowany obiekt lub zdarzenie, o którym informacje muszą być przechowywane w bazie danych i które mają określony zestaw właściwości - atrybutów. Podmiotami mogą być zarówno obiekty fizyczne (faktycznie istniejące), na przykład STUDENT (atrybuty - numer dziennika ocen, nazwisko, imię, patronimik, specjalność, numer grupy itp.), Jak i abstrakcyjne, na przykład EGZAMIN (atrybuty - dyscyplina, data, Wykładowca, Audytorium itp.). W przypadku jednostek rozróżnia się typ i instancję. Typ charakteryzuje się nazwą i listą właściwości, a instancję charakteryzują określone wartości właściwości.
Atrybuty to właściwości charakteryzujące jednostkę. W strukturze tabeli każdy atrybut jest nazwany i odpowiada tytułowi określonej kolumny w tabeli. Atrybuty jednostki to:
1) identyfikujące i opisowe.Identyfikujące atrybuty mają unikalna wartość dla podmiotów tego typu i są potencjalnymi kluczami. Pozwalają na unikalne rozpoznawanie wystąpień bytu. Wybrano jeden z potencjalnych kluczy klucz podstawowy.Potencjalny klucz jest zwykle wybierany jako klucz podstawowy, który jest używany częściej w celu uzyskania dostępu do instancji rekordów. Klucz podstawowy musi zawierać minimalną liczbę atrybutów wymaganych do identyfikacji. Pozostałe atrybuty nazywane są opisowymi;
2) proste i złożone.Prosty atrybut składa się z jednego składnika, jego wartość jest niepodzielna. Atrybut złożony to połączenie kilku składników, które mogą należeć do różnych typów danych (na przykład adres). Decyzja o zastosowaniu atrybutu złożonego lub rozbiciu go na komponenty zależy od specyfiki procesów do jego zastosowania i może wiązać się z zapewnieniem dużej szybkości pracy duże podstawy dane;
3) jednoznaczne i niejednoznaczne.Atrybuty mogą mieć odpowiednio jedną lub wiele wartości dla każdej instancji jednostki;
4) podstawowe i pochodne.Wartość głównego atrybutu jest niezależna od innych atrybutów. Wartość atrybutu pochodnego jest obliczana na podstawie wartości innych atrybutów (na przykład wiek osoby jest obliczany na podstawie jej daty urodzenia i dzisiejszej daty).
Specyfikacja atrybutu składa się z jego nazwy, wskazania typu danych oraz opisu ograniczeń integralności - zbioru wartości (lub dziedziny), które może przyjąć dany atrybut.
Domenajest zbiorem wszystkich możliwych wartości określonego atrybutu relacji.
Schemat relacji (nagłówek relacji)to lista nazw atrybutów z nazwami domen.
Krotka, odpowiadający danemu schematowi relacji to zbiór par (nazwa atrybutu, wartość), który zawiera jedno wystąpienie każdej nazwy atrybutu. Wartość jest prawidłową wartością domeny dla tego atrybutu.
Klucz podstawowy(klucz relacji, atrybut klucza)jest atrybutem lub zestawem atrybutów relacji, który jednoznacznie identyfikuje każdą z jej krotek. Klucz podstawowy jest z definicji unikalny: relacja nie może mieć dwóch różnych krotek z tymi samymi wartościami klucza podstawowego. Atrybuty tworzące klucz podstawowy nie mogą mieć wartości ZERO.Pojęcie ZEROw teorii relacyjnych baz danych ma oznaczać brak wartości atrybutu. Dla każdej relacji może istnieć tylko jeden klucz podstawowy.
Każda relacja z konieczności ma kombinację atrybutów, które mogą służyć jako klucz. Mogą wystąpić przypadki, w których relacja ma kilka kombinacji atrybutów, z których każda jednoznacznie identyfikuje wszystkie krotki relacji. Wszystkie te kombinacje atrybutów są możliwe kluczezwiązek. Każdy z możliwych kluczy można wybrać jako główny.
Klucze obce są głównym mechanizmem organizowania relacji między tabelami i utrzymywania integralności i spójności informacji w bazie danych.
Klucz zewnętrznyJest to zestaw atrybutów jednej relacji, który jest możliwym kluczem dla innej relacji.
Dzięki obecności powiązań między możliwymi i obcymi kluczami zapewniona jest relacja krotek pewnych relacji, co pomaga w utrzymaniu bazy danych w takim stanie, aby można ją było rozpatrywać jako całość. Relacja zawierająca klucz obcy nazywana jest dzieckiem, a relacja zawierająca możliwy klucz skojarzony z kluczem obcym nazywana jest rodzicem. Typy danych (aw niektórych systemach DBMS wymiary) odpowiednich atrybutów klucza obcego i nadrzędnego muszą być zgodne.
Elementy relacyjnego modelu danych i forma ich prezentacji
|
Element modelu relacyjnego |
Formularz prezentacji |
|
|
Nastawienie |
||
|
Diagram relacji |
Wiersz nagłówków kolumn tabeli (nagłówek tabeli) |
|
|
Rząd tabeli |
||
|
Esencja |
Opis właściwości obiektu |
|
|
Nagłówek kolumny tabeli |
||
|
Wiele prawidłowych wartości atrybutów |
||
|
Wartość atrybutu |
Wartość pola w rekordzie |
|
|
Klucz podstawowy |
Jeden lub więcej atrybutów |
|
|
Typ danych |
Typ wartości elementów tabeli |
|
