Struktura danych w modelu relacyjnym to. Relacyjny model danych

MODELE DANYCH

Dane przechowywane w bazie danych mają określoną strukturę logiczną i są opisane przez pewien model reprezentacji danych (model danych) obsługiwany przez DBMS. Następujące modele danych są klasykami:

· Hierarchiczne;

· Sieć;

· Relacyjne.

Ponadto w ostatnich latach pojawiły się i zostały aktywniej wdrażane w praktyce następujące modele danych:

Postrelacyjny,

Wielowymiarowy,

· Zorientowany obiektowo.

Opracowywane są również różne systemy w oparciu o inne modele danych, które rozszerzają znane modele. Są to modele obiektowo-relacyjne, dedukcyjno-obiektowe, semantyczne, konceptualne i zorientowane. Niektóre z tych modeli służą do integracji baz danych, baz wiedzy i języków programowania. Niektóre systemy DBMS obsługują jednocześnie wiele modeli danych.

2.1. Hierarchiczny model danych

W modelu hierarchicznym dane można opisać za pomocą uporządkowanego wykresu (lub drzewa). Uproszczoną reprezentację zależności między danymi w modelu hierarchicznym przedstawiono na rys. 2.1.

Postać: 2.1. Reprezentacja relacji w modelu hierarchicznym

Typ danych drzewo służy do opisu struktury (schematu) hierarchicznej bazy danych w określonym języku programowania.

Typ drzewa jest podobny do typu danych rekordu Pascal. Dozwolone jest zagnieżdżanie typów, z których każdy jest na pewnym poziomie.

Drzewo jest złożone. Obejmuje podtypy („poddrzewa”), z których każdy z kolei jest rodzajem „drzewa”. Każdy z typów drzew składa się z jednego typu głównego i uporządkowanego zestawu (prawdopodobnie pustych) typów podrzędnych. Każdy z typów pierwotnych zawartych w typie drzewa jest prostym lub złożonym typem rekordu. Prosty „rekord” składa się z jednego typu, na przykład liczbowego. Złożony „rekord” łączy zbiór typów, takich jak liczba całkowita, ciąg znaków i wskaźnik (odwołanie). Przykład typu „drzewo” jako zbioru typów pokazano na rys. 2.2.

Kornevnazywany typem, który ma podtypy i sam nie jest podtypem. Typ niewolnika (podtyp) jest potomkiem typu, który działa jako przodek (rodzic) dla niego. Potomkowie tego samego typu są bliźniakami w stosunku do siebie.

Ogólnie rzecz biorąc, typ drzewa to hierarchicznie zorganizowany zbiór typów rekordów.

Postać: 2.2. Przykład typu „drzewo”

Hierarchiczna baza danych to uporządkowany zbiór instancji danych typu drzewiastego (drzew) zawierający instancje typu rekordu (rekordy). Często związek między typami jest przenoszony na związek między samymi rekordami. Pola rekordów przechowują rzeczywiste wartości liczbowe lub symboliczne, które tworzą główną zawartość bazy danych. Przeglądanie wszystkich elementów hierarchicznej bazy danych jest zwykle wykonywane od góry do dołu i od lewej do prawej.

W hierarchicznym DBMS można używać terminologii innej niż podana. Na przykład rekord można nazwać segmentem, a rekord bazy danych można rozumieć jako cały zestaw rekordów związanych z jedną instancją typu „drzewo”.

Dane w bazie danych z podanym schematem (ryc.2.2.) Mogą wyglądać np. Tak, jak pokazano na ryc.2.3.

Postać: 2.3. Dane w hierarchicznej bazie danych

Do organizacji fizycznego rozmieszczenia danych hierarchicznych w pamięci komputera można zastosować następujące grupy metod:

· Reprezentacja przez listę liniową z sekwencyjną alokacją pamięci (arytmetyka adresów, struktury lewej listy);

· Reprezentacja przez połączone listy liniowe (metody wykorzystujące wskaźniki i odniesienia).

Główne operacje manipulacji hierarchicznie zorganizowanymi danymi obejmują:

· Wyszukaj określoną instancję bazy danych (na przykład drzewo o wartości 912 w polu Group_Code);

· Przejście z jednego drzewa do drugiego;

· Przejście z jednego rekordu do innego w drzewie (na przykład do następnego rekordu typu Studenci);

· Wstawianie nowego rekordu na określonej pozycji;

· Usuwanie aktualnego rekordu itp.

Zgodnie z definicją typu „drzewo” można stwierdzić, że kontrola integralności powiązań jest zachowana automatycznie między przodkami i potomkami. Główna zasada kontroli integralności jest sformułowana następująco: dziecko nie może istnieć bez rodzica, a niektórzy rodzice mogą nie mieć dzieci. Nie ma mechanizmów utrzymywania integralności powiązań między rekordami różnych drzew.

Do zalet hierarchicznego modelu danych należy efektywne wykorzystanie pamięci komputera i dobre wskaźniki wydajności dla podstawowych operacji na danych. Hierarchiczny model danych jest przydatny do pracy z informacjami uporządkowanymi hierarchicznie.

Wadą modelu hierarchicznego jest jego nieporęczność w przetwarzaniu informacji z dość złożonymi powiązaniami logicznymi, a także złożoność zrozumienia dla zwykłego użytkownika.

Stosunkowo ograniczona liczba DBMS jest oparta na hierarchicznym modelu danych, w tym systemy zagraniczne IMS, PS / Focus, Team-Up, Data Edge, a także systemy krajowe Oka, INES, MIRIS.

2.2. Model sieci

Sieciowy model danych umożliwia wyświetlanie różnych relacji elementów danych w postaci dowolnego wykresu, uogólniając tym samym hierarchiczny model danych (rys. 2.4). Najpełniejsza koncepcja sieciowych baz danych została po raz pierwszy przedstawiona w Propozycjach grupy KODASYL.

Do opisu schematu sieciowej bazy danych używa się grup typów: „record” i „link”. Typ łącza jest zdefiniowany dla dwóch typów rekordów: nadrzędnego i podrzędnego. Zmienne typu „Link” to instancje linków.

Składa się ze studentów

Prowadzony przez naczelnika

Postać: 2.5. Przykład schematu sieciowej bazy danych

W różnych DBMS typ sieci Do oznaczenia zasadniczo identycznych pojęć można użyć różnych terminów. Na przykład, takie jak elementy danych i agregaty, rekordy, zbiory, obszary itp.

Fizyczne rozmieszczenie danych w bazach danych typu sieciowego można zorganizować przy użyciu prawie takich samych metod, jak w hierarchicznych bazach danych.

Do najważniejszych operacji związanych z manipulowaniem danymi w bazach danych typu sieciowego należą:

Wyszukaj rekord w bazie danych,

Przejście od przodka do pierwszego potomka,

Przejście od potomka do przodka,

Tworzenie nowego rekordu,

Usunięcie aktualnego rekordu,

Aktualizacja aktualnego rekordu,

Włączanie nagrywania do komunikacji,

Wyłączenie zapisu z komunikacji,

· Zmiana połączeń itp.

Godność model sieci dane to możliwość efektywnej realizacji pod względem czasu i wydajności. W porównaniu z modelem hierarchicznym model sieciowy daje duże możliwości w sensie dopuszczalności tworzenia dowolnych powiązań.

Niekorzyśćsieciowy model danych to duża złożoność i sztywność schematu bazy danych, zbudowanego na jego podstawie, a także złożoność zrozumienia i wykonywania operacji przetwarzania danych w bazie danych dla zwykłych użytkowników. Ponadto w sieciowym modelu danych kontrola integralności łączy jest osłabiona ze względu na dopuszczalność tworzenia dowolnych powiązań między rekordami.

Systemy oparte na modelu sieciowym nie są szeroko stosowane w praktyce. Najbardziej znane sieciowe DBMS to: IDMS, db_VistaIII, NETWORK, CETOR i KOMPAS.

2.3. Model relacyjny

Relacyjny model danych został zaproponowany przez pracownika iBM Edgara Codda i opiera się na koncepcji relacji (relacji).

Nastawienie to zbiór elementów zwanych krotkami. Szczegółowe podstawy teoretyczne model relacyjny omówione w następnej sekcji. Wizualną formą reprezentacji relacji jest dwuwymiarowy stół znany ludzkiej percepcji.

Tabela zawiera wiersze (rekordy) i kolumny (kolumny). Każdy wiersz tabeli ma taką samą strukturę i składa się z pól. Wiersze tabeli odpowiadają krotkom, a kolumny atrybutom relacji.

Korzystając z jednej tabeli, wygodnie jest opisywać informacje o grupach jednorodnych (o tych samych właściwościach) obiektów, zjawisk lub procesów w świecie rzeczywistym. Każdy wiersz tabeli zawiera informacje o konkretnym obiekcie, zjawisku lub procesie. Łańcuch (rekord) ma taką samą strukturę i opisuje właściwości obiektów za pomocą pól. Na przykład tabela może zawierać informacje o grupie stażystów, o każdej z nich znane są następujące cechy: nazwisko, imię i nazwisko rodowe, płeć, data urodzenia, adres zamieszkania. Ponieważ nie jest możliwe opisanie wszystkich danych z obszaru tematycznego w jednej tabeli, tworzonych jest kilka tabel, pomiędzy którymi tworzone są łącza.

Fizyczne rozmieszczenie danych w relacyjnych bazach danych na nośniki zewnętrzne łatwo zrobić za pomocą zwykłych plików.

Korzyści relacyjny model danych polega na prostocie, jasności i wygodzie fizycznej implementacji na komputerze. To właśnie prostota i przejrzystość dla użytkownika są głównym powodem ich powszechnego stosowania.

Główny niedogodności modele relacyjne są następujące: standardowe narzędzia identyfikacja poszczególnych rekordów i złożoność opisu relacji hierarchicznych i sieciowych.

Przykłady relacyjnych DBMS to: dBaseIIIPlus dBaseIV (Ashton-Tate), DB2 (IBM), R: BASE (Microrim), FoxPro wczesne wersje oraz FoxBase (Fox Software), Paradox i dBASE dla Windows (Borland), później FoxPro, Visual FoxPro i Access (Microsoft), Clarion (Clarion Software), Ingres (ASK Computer System) i Oracle (Oracle).

Najnowsze wersje relacyjnych systemów DBMS mają pewne właściwości systemów zorientowanych obiektowo. Takie DBMS są często nazywane obiektowo-relacyjnymi. Przykładem takiego systemu jest Oracle 8.x.

2.4. Model postrelacyjny

Klasyczny model relacyjny zakłada niepodzielność danych przechowywanych w polach rekordów tabeli. Oznacza to, że informacje w tabeli są przedstawione w pierwszej normalnej formie. Istnieje wiele przypadków, w których to ograniczenie przeszkadza w skutecznej implementacji aplikacji.

Postrelacyjny model danych to rozszerzony model relacyjny, który usuwa ograniczenie niepodzielności danych przechowywanych w rekordach tabel. Postrelacyjny model danych dopuszcza zmienne wielowartościowe - zmienne, których wartości składają się z wartości podrzędnych. Zestaw wartości dla pól wielowartościowych jest uważany za niezależną tabelę, osadzoną w tabeli głównej.

Na rys. 2.6 na przykładzie informacji o fakturach i towarach do porównania pokazano prezentację tych samych danych za pomocą modeli relacyjnych (a) i postrelacyjnych (b). Tabela Faktury zawiera informacje o numerach faktur i numerach klientów. Tabela Invoice_Goods zawiera informacje o każdej z faktur: numer faktury, nazwę towaru oraz ilość towaru. Tabela Faktury jest połączona z tabelą Faktury_Produkty za pomocą pola Numer faktury.

Jak widać na rysunku, w porównaniu z modelem relacyjnym, model postrelacyjny efektywniej przechowuje dane, a podczas przetwarzania nie jest wymagana operacja łączenia danych z dwóch tabel.

Oprócz pól zagnieżdżonych model postrelacyjny obsługuje powiązane zmienne wielowartościowe (wiele grup). Zbiór powiązanych pól nazywany jest asocjacją. W tym przypadku w wierszu pierwsza wartość jednej kolumny asocjacji odpowiada pierwszym wartościom wszystkich pozostałych kolumn asocjacji. Wszystkie wartości drugiej kolumny są powiązane w podobny sposób i tak dalej.

Wymóg stałości nie dotyczy długości pól ani liczby pól w rekordach tabeli. Oznacza to, że struktura danych i tabel jest bardzo elastyczna.

Nad głową

Koszty ogólne_Produkty

Nad głową

Postać: 2.6. Relacyjne i postrelacyjne struktury danych modeli

Ponieważ model postrelacyjny pozwala na przechowywanie nieznormalizowanych danych w tabelach, istnieje problem z zapewnieniem integralności i spójności danych. Ten problem został rozwiązany poprzez włączenie mechanizmów w DBMS, które są podobne do procedur składowanych w systemach klient-serwer.

Aby opisać funkcje kontrolne dla wartości w polach, można stworzyć procedury (kody konwersji i kody korelacji), które są automatycznie wywoływane przed i po uzyskaniu dostępu do danych. Kody korelacji są wykonywane natychmiast po odczytaniu danych, przed ich przetworzeniem. I odwrotnie, kody konwersji są wykonywane po przetworzeniu danych.

Zaletą modelu postrelacyjnego jest możliwość reprezentacji zestawu powiązanych tabel relacyjnych za pomocą jednej tabeli postrelacyjnej. Zapewnia to wysoką przejrzystość prezentacji informacji i wzrost wydajności jej przetwarzania.

Wadą modelu postrelacyjnego jest złożoność rozwiązania problemu zapewnienia integralności i spójności przechowywanych danych.

Rozważany postrelacyjny model danych jest obsługiwany przez uniVers, Bubba, Dasdb DBMS.

2.5. Model wielowymiarowy

Wielowymiarowe podejście do prezentacji danych w bazie danych pojawiło się prawie jednocześnie z relacyjnym, ale do tej pory działało bardzo niewiele wielowymiarowych DBMS (MSUBMS). Od połowy lat 90. zainteresowanie nimi zaczęło nabierać masowego charakteru.

Impulsem w 1993 r. Był artykuł programowy jednego z twórców podejścia relacyjnego, E. Codda. Formułuje 12 podstawowych wymagań dla systemów klasy OLAP (OnLine Analytical Processing), z których najważniejsze związane są z możliwościami reprezentacji koncepcyjnej i przetwarzania danych wielowymiarowych. Systemy wielowymiarowe pozwalają na szybkie przetwarzanie informacji w celu analizy i podejmowania decyzji.

Przy opracowywaniu koncepcji własności intelektualnej można wyróżnić dwa kierunki:

· Systemy przetwarzania operacyjnego (transakcyjnego);

· Analityczne systemy przetwarzania (systemy decyzyjne).

Relacyjne DBMS były przeznaczone dla systemów informatycznych do przetwarzania informacji on-line i były bardzo skuteczne w tym obszarze. W analitycznych systemach przetwarzania okazały się nieco niezdarne i niewystarczająco elastyczne. Wielowymiarowe systemy DBMS są tutaj bardziej wydajne.

Wielowymiarowy system DBMSto wysoce wyspecjalizowane DBMS przeznaczone do interaktywnego analitycznego przetwarzania informacji. Pokażmy podstawowe pojęcia używane w tych DBMS: agregowalność, historyczność, przewidywalność danych.

Agregowalność dane oznaczają rozpatrywanie informacji na różnych poziomach ich uogólnienia. W systemy informacyjne stopień szczegółowości prezentacji informacji dla użytkownika zależy od jego poziomu: analityk, użytkownik-operator, menedżer, menedżer.

Historyczność dane oznacza zapewnienie wysokiego poziomu statyczności (niezmienności) samych danych i ich wzajemnych relacji, a także obowiązek powiązania danych z czasem.

Statyczny charakter danych pozwala na stosowanie wyspecjalizowanych metod ładowania, przechowywania, indeksowania i pobierania podczas ich przetwarzania.

Czasowe wiązanie danych jest niezbędne do częstego wykonywania zapytań, które mają wartości godziny i daty w próbce. Konieczność uporządkowania danych w czasie w procesie przetwarzania i prezentacji danych użytkownikowi nakłada wymagania na mechanizmy przechowywania i dostępu do informacji. Dlatego w celu skrócenia czasu przetwarzania wniosków pożądane jest, aby dane były zawsze sortowane w kolejności, w jakiej są najczęściej żądane.

Przewidywalność dane wymagają ustawiania funkcji prognozowania i stosowania ich w różnych przedziałach czasowych.

Wielowymiarowość modelu danych nie oznacza wielowymiarowości wizualizacji danych cyfrowych, ale wielowymiarową, logiczną reprezentację struktury informacji w opisie i operacjach manipulacji danymi.

W porównaniu z modelem relacyjnym, wielowymiarowa organizacja danych ma wyższą widoczność i zawartość informacyjną.

Jeśli nadchodzi o modelu wielowymiarowym o wymiarze większym niż dwa, wówczas informacje niekoniecznie są prezentowane wizualnie w postaci obiektów wielowymiarowych (trój-, cztero- i wielowymiarowych hipersześcianów). Nawet w takich przypadkach wygodniej jest posługiwać się dwuwymiarowymi tabelami lub wykresami. Jednocześnie dane są „wycinkami” (a dokładniej „wycinkami”) z wielowymiarowej hurtowni danych, wykonanymi z różnym stopniem szczegółowości.

Rozważmy podstawowe pojęcia wielowymiarowych modeli danych, które obejmują wymiar i komórkę.

Wymiar (Dimensiom) to zbiór danych tego samego typu, który tworzy jedną z płaszczyzn hipersześcianu. Przykłady najczęściej używanych pomiarów czasu to dni, miesiące, kwartały i lata. Miasta, regiony, regiony i kraje są szeroko stosowane jako wymiary geograficzne. W wielowymiarowym modelu danych wymiary działają jak indeksy identyfikujące określone wartości w komórkach hipersześcianu.

Komórka lub miara to pole, którego wartość jest jednoznacznie określona przez stały zestaw wymiarów. Typ pola jest najczęściej definiowany jako numeryczny. W zależności od tego, jak tworzone są wartości danej komórki, zwykle może to być zmienna (wartości zmieniają się i mogą być ładowane z zewnętrznego źródła danych lub generowane programowo) lub formuła (wartości, takie jak komórki formuły w arkuszu kalkulacyjnym, są obliczane przy użyciu predefiniowanych formuł).

W przykładzie na rys. 2,8 wartości każdej komórki Wielkość sprzedażyjest jednoznacznie określany przez połączenie wymiaru czasu (miesiąc sprzedaży) i modelu pojazdu. Przykład modelu danych 3D pokazano na rys. 2.9.

1999

Petrov 9999999varoyoro

Wielkość sprzedaży

„Zhiguli” „Moskvich”

Pomiary:

Czas (rok) - 1994, 1995, 1996

Menedżer - Petrov, Smirnov, Yakovlev

Model - „Wołga”, „Żiguli”, „Moskwicz”

Wskaźnik: wielkość sprzedaży

Postać: 2.9. Przykład modelu 3D

Istnieją dwie główne opcje (schematy) organizowania danych w istniejącym ISDBMS: hipersześciana i wielopierścieniowa.

Schemat pół-sześcianu zakłada, że \u200b\u200bDBMS może zdefiniować kilka hipersześcianów o różnych wymiarach i różnych wymiarach jako ściany. Przykładem systemu obsługującego polycubicową wersję bazy danych jest Oracle Express Server.

W przypadku projektu hipersześcianu zakłada się, że wszystkie miary są zdefiniowane przez ten sam zestaw wymiarów. Oznacza to, że jeśli istnieje kilka hipersześcianek DB, wszystkie mają ten sam wymiar i pokrywają się wymiarami. Oczywiście w niektórych przypadkach informacje w bazie danych mogą być zbędne (jeśli wymagane jest obowiązkowe wypełnienie komórek).

W przypadku wielowymiarowego modelu danych stosuje się szereg operacji specjalnych, do których należą: „wycinek”, „obrót”, agregacja i uszczegółowienie.

Wycinek to podzbiór hipersześcianu będący wynikiem co najmniej jednego pomiaru. Cięcie na plasterki ma na celu ograniczenie wartości używanych przez użytkownika, ponieważ wszystkie wartości hipersześcianu prawie nigdy nie są używane jednocześnie. Na przykład, jeśli ograniczysz wartości pomiarów Model samochodu w hipersześcianie (rys. 2.9) do marki „Zhiguli”, otrzymasz dwuwymiarową tabelę sprzedaży tej marki samochodu przez różnych menedżerów według roku.

Operacja Obróć służy do reprezentacji danych 2D. Jej istotą jest zmiana kolejności pomiarów w wizualnej prezentacji danych. Zatem „obrót” dwuwymiarowej tabeli pokazanej na rysunku 2.8b doprowadzi do zmiany jej wyglądu w taki sposób, że marka samochodu znajdzie się na osi X, a czas na osi Y.

Operację „rotacji” można uogólnić na przypadek wielowymiarowy, jeśli rozumie się ją jako procedurę zmiany kolejności pomiarów. W najprostszym przypadku może to być wzajemna permutacja dwóch dowolnych wymiarów.

Operacje „agregacja” (drążenie w górę) i „uszczegółowienie” (drążenie w dół) oznaczają odpowiednio przejście do bardziej ogólnej lub bardziej szczegółowej prezentacji informacji dla użytkownika z hipersześcianu.

Aby zilustrować znaczenie operacji „agregacji” załóżmy, że mamy hipersześcian, w którym oprócz wymiarów hipersześcianu pokazanego na ryc. 2.9, są też wymiary: Dział, Region, Firma, Kraj. Zauważ, że w tym przypadku w hipersześcianie istnieje hierarchia (od dołu do góry) relacji pomiędzy wymiarami: Kierownik, Dział, Region, Firma, Kraj.

Niech opisywany hipersześcian określi, jak skutecznie w 2000 roku menedżer Pietrow sprzedawał samochody Żiguli i Wołgi. Następnie przechodząc o jeden poziom w hierarchii w górę za pomocą operacji „agregacja” można dowiedzieć się, jak wygląda stosunek sprzedaży tych samych modeli na poziomie działu, w którym pracuje Pietrow.

Główną zaletą wielowymiarowego modelu danych jest wygoda i efektywność analitycznego przetwarzania dużych ilości danych czasowych. Organizując przetwarzanie podobnych danych w oparciu o model relacyjny, następuje nieliniowy wzrost złożoności operacji w zależności od rozmiaru bazy danych oraz znaczny wzrost kosztu pamięci RAM do indeksowania.

Wadą wielowymiarowego modelu danych jest jego uciążliwość w rozwiązywaniu najprostszych problemów przetwarzania informacji operacyjnych.

Przykładami systemów obsługujących wielowymiarowe modele danych są Essbase (oprogramowanie Arbor), Media Multi-matrix (Speedware), Oracle Express Server (Oracle), Cache (InterSystem). Niektóre programy, na przykład Media / MR (Speedware), pozwalają na jednoczesną pracę z wielowymiarowymi i relacyjnymi bazami danych. W Oracle DBMS, w którym wewnętrzny model danych jest modelem wielowymiarowym, zaimplementowano trzy sposoby dostępu do danych: bezpośredni (na poziomie wielowymiarowych węzłów macierzowych), obiektowy oraz relacyjny.

2.6. Model zorientowany obiektowo

W modelu zorientowanym obiektowo, prezentując dane, można zidentyfikować poszczególne rekordy bazy danych. Relacje między rekordami bazy danych i ich funkcjami przetwarzania są ustanawiane przy użyciu mechanizmów podobnych do tych, które są stosowane w obiektowych językach programowania.

Zestandaryzowany model obiektowy jest opisany w zaleceniach standardu ODMG-93 (Object Database Management Group - obiektowa grupa zarządzania bazami danych). Zalecenia ODMG-93 nie zostały jeszcze w pełni wdrożone. Aby zilustrować kluczowe idee, rozważ nieco uproszczony model obiektowej bazy danych.

Zorientowana obiektowo struktura bazy danych można przedstawić graficznie w postaci drzewa, którego węzłami są obiekty. Właściwości obiektu są opisane przez niektórych typ standardowy (na przykład string) lub typ utworzony przez użytkownika (zdefiniowany jako klasa).

Wartością właściwości typu string jest ciąg znaków. Wartością właściwości typu class jest obiekt będący instancją odpowiedniej klasy. Każda instancja klasy jest traktowana jako potomek obiektu, w którym jest zdefiniowana jako właściwość. Obiekt instancji klasy należy do swojej klasy i ma jednego rodzica. Relacje ogólne w bazie danych tworzą hierarchię obiektów.

Przykład struktury logicznej zorientowanej obiektowo bazy danych bibliotekarstwa przedstawiono na rys. 2.10.

W tym przypadku obiekt typu LIBRARY jest obiektem nadrzędnym dla instancji klas SUBSCRIBER, DIRECTORY i REFERENCE. Różne obiekty typu KSIĄŻKA mogą mieć tych samych lub różnych rodziców. Obiekty typu BOOK, które mają tego samego rodzica, muszą różnić się co najmniej numerem inwentarzowym (unikalnym dla każdej kopii książki), ale mają te same wartości dla szyfru książki właściwości, KDPU, tytułu i autora.

Logiczna struktura obiektowej bazy danych jest zewnętrznie podobna do struktury hierarchicznej bazy danych. Główna różnica między nimi polega na metodach manipulacji danymi.

Do wykonywania działań na danych w rozważanym modelu bazy danych wykorzystuje się operacje logiczne, wzmocnione obiektowymi mechanizmami enkapsulacji, dziedziczenia i polimorfizmu. Operacje podobne do poleceń SQL mogą być używane w ograniczonym zakresie (na przykład do tworzenia bazy danych).

Tworzeniu i modyfikowaniu bazy danych towarzyszy automatyczne tworzenie i późniejsze dostosowywanie indeksów (tabel indeksowych) zawierających informacje do szybkiego wyszukiwania danych.Rozważmy pokrótce koncepcje enkapsulacji, dziedziczenia i polimorfizmu w odniesieniu do obiektowego modelu bazy danych.

Kapsułkowanie ogranicza zakres nazwy właściwości do granic obiektu, w którym jest zdefiniowana. Jeśli więc dodamy właściwość, która ustawia numer telefonu autora książki i ma nazwę numer telefonu do obiektu typu DIRECTORY, otrzymamy właściwości o tej samej nazwie dla obiektów SUBSCRIBER i DIRECTORY. Znaczenie takiej właściwości zostanie określone przez obiekt, w którym jest zamknięta.

Dziedzictwoodwrotnie, rozszerza zakres własności na wszystkich potomków obiektu. Zatem wszystkim obiektom typu BOOK, które są potomkami obiektu typu DIRECTORY, można przypisać właściwości obiektu nadrzędnego: kod książki, KDPU, tytuł, autor. Jeśli konieczne jest rozszerzenie działania mechanizmu dziedziczenia na obiekty, które nie są bezpośrednio powiązane (na przykład między dwoma potomkami tego samego rodzica), to w ich wspólnym przodku definiowana jest abstrakcyjna właściwość typu abs. Zatem definicja abstrakcyjnych właściwości bilet i numer w obiekcie LIBRARY prowadzi do dziedziczenia tych właściwości przez wszystkie obiekty potomne SUBSCRIBER, BOOK i REFERENCE. To nie przypadek, że wartości biletu własności klas SUBSCRIBER i RETURN pokazane na rysunku będą takie same - 00015.

Polimorfizm w obiektowych językach programowania oznacza zdolność tego samego kodu programu do pracy z różnymi typami danych. Innymi słowy, oznacza to, że można mieć metody (procedury lub funkcje) o tych samych nazwach w obiektach różnych typów. Podczas wykonywania programu obiektowego te same metody działają na różnych obiektach w zależności od typu argumentu. W przypadku naszej zorientowanej obiektowo bazy danych polimorfizm oznacza, że \u200b\u200bobiekty klasy BOOK mające różnych rodziców z klasy DIRECTORY mogą mieć inny zestaw właściwości. W konsekwencji programy do pracy z obiektami klasy BOOK mogą zawierać kod polimorficzny Wyszukiwanie w bazie zorientowanej obiektowo polega na znalezieniu podobieństwa między obiektem określonym przez użytkownika a obiektami przechowywanymi w bazie danych. Obiekt zdefiniowany przez użytkownika, nazywany obiektem celu (właściwość obiektu jest typu goal), w ogólnym przypadku może być podzbiorem całej hierarchii obiektów przechowywanych w bazie danych. Obiekt docelowy, jak również wynik wykonania zapytania, mogą być przechowywane w samej bazie danych. Przykład zapytania do czytelników, którzy otrzymali przynajmniej jedną książkę z biblioteki, pokazano na ryc. 2.11.

Postać: 2.11. Fragment bazy danych z obiektem docelowym

Główna zaleta obiektowy model danych w porównaniu z relacyjnym to możliwość wyświetlania informacji o złożonych relacjach obiektów. Zorientowany obiektowo model danych umożliwia identyfikację osobny wpis baz danych i zdefiniować funkcje ich przetwarzania.

Wadami modelu zorientowanego obiektowo są duża złożoność koncepcyjna, niedogodności w przetwarzaniu danych i niska prędkość zapytań.

W latach 90. istniały eksperymentalne prototypy zorientowanych obiektowo systemów zarządzania bazami danych. Obecnie takie systemy są szeroko rozpowszechnione, w szczególności następujące DBMS to: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), Q2 (Ardent Software), ODB-Jupiter (centrum badawczo-produkcyjne) Inteltek Plus), a także Iris, Orion, Postgres.

MODEL DANYCH RELACYJNYCH

3.1. Podstawowe definicje

Relacyjny model danych został zaproponowany przez E.Codda w 1970 roku. Relacyjny model danych oparty jest na koncepcji relacji.

Matematycznie stosunek ten definiuje się następująco. Niech n zbiorów D1, D2,…, Dn będą dane. Wtedy R jest relacją nad tymi zbiorami, jeśli R jest zbiorem uporządkowanych krotek o długości n postaci (d1, d2,…, dn), gdzie d1 jest elementem z D1, d2 jest elementem z D2, dn jest elementem z Dn. D1, D2,…, Dn nazywane są domenami relacji R. Zauważ, że ta definicja jest równoważna definicji iloczynu kartezjańskiego zbiorów D1, D2,…, Dn.

Zdefiniujmy tę zależność z punktu widzenia teorii przetwarzania danych. Nastawienie - podzbiór iloczynu kartezjańskiego jednej lub kilku dziedzin. Domena - zbiór możliwych wartości dla określonego atrybutu. Atrybut - własność przedmiotu, zjawiska lub procesu. Przykłady atrybutów: nazwisko, imię, patronimia, data urodzenia. Tuple- element relacji to odwzorowanie nazw atrybutów na wartości pobrane z odpowiednich domen. Skończony zbiór krotek tworzy relację. Jeśli relacja jest tworzona z n domen, to każda krotka ma n składników.

Wyjaśnijmy te definicje przykładami.

Przykład 1. Miejmy dwie domeny:

D1 \u003d (0,1); D2 \u003d (a, b, c).

Skonstruuj iloczyn kartezjański domen D1, D2:

D1 x D2 \u003d ((0, a), (0, b), (0, c), (1, a), (1, b), (1, c)).

Jako relację zbudowaną na domenach D1, D2 możesz wybrać na przykład:

R \u003d ((0, a), (0, c), (1, b), (1, c)).

Relacja R składa się z czterech krotek, każda krotka ma dwa elementy, pierwszy jest wybierany z domeny D1, drugi z domeny D2.

Przykład 2. Miejmy cztery domeny:

D1 to zbiór liczb całkowitych, na przykład zbiór numerów części (101, 34, 23, 109, 147).

D2 - wiele ciągów znaków, na przykład wiele nazw części (tuleja, wspornik, wspornik, sprzęgło, śruba).

D3 - wiele ciągów znaków, na przykład wiele nazw obróbki (tłoczenie na zimno, odlewanie metali, odlewanie tworzyw sztucznych, obróbka skrawaniem).

D4 to zbiór liczb rzeczywistych, na przykład zbiór wag części (45,8, 6,9, 123, 69,3, 5,2, 2,34).

Jako relację zbudowaną na domenach D1, D2, D3, D4 możesz wybrać na przykład:

R \u003d ((34, tuleja, formowana z tworzywa sztucznego, 69.3), (23, wspornik, formowana na zimno, 45.8), (101, śruba, obrabiana, 5.2)).

Relacja R składa się z trzech krotek, każda krotka zawiera cztery elementy.

Relację wygodnie jest przedstawić jako tabelę, w której każdy wiersz jest krotką zawierającą dane o określonym obiekcie, zjawisku lub procesie. Każda kolumna tabeli jest domeną zawierającą możliwe wartości jednej z właściwości obiektu, procesu lub zjawiska.

Na przykład: Szczegóły

Następujące zestawy terminów są równoważne:

relacja, tabela, plik;

krotka, ciąg, rekord:

atrybut, element kolumny, pole.

Nazwana jest nazwana lista nazw atrybutów relacji schemat relacji... Przykładowy schemat:

Detale ( Numer szczegółu, Nazwa części, rodzaj obróbki, waga).

Podkreślono kluczowy atrybut w schemacie relacji.

Nazywa się zbiór schematów relacji używanych do reprezentowania informacji schemat relacyjnej bazy danych.

Wywoływana jest liczba kolumn w relacji stopień... Bieżąca liczba krotek w relacji jest nazywana moc... Stopień relacji zwykle nie zmienia się po utworzeniu relacji, ale liczność będzie się zmieniać w miarę dodawania nowych krotek i usuwania starych.

Relacyjna baza danychTo zbiór relacji zawierający wszystkie informacje, które muszą być przechowywane w bazie danych.

Przykładowy fragment bazy danych:

Postawa 1. Radioelementy (tranzystory)

Attitude 2. Magazyn

Każdy związek ma klucz. Klucz (klucz podstawowy, klucz relacji, atrybut klucza) Jest atrybutem lub grupą atrybutów, które jednoznacznie identyfikują krotkę w relacji. Jeśli klucz złożony (składa się z dwóch lub więcej atrybutów), to musi być minimalny... Oznacza to, że jeśli jeden dowolny atrybut zostanie wykluczony z klucza złożonego, pozostałe atrybuty nie będą wystarczające do jednoznacznego zidentyfikowania poszczególnych krotek. Kluczowe wartości w relacji (tabeli) muszą być unikalne, to znaczy nie mogą istnieć dwie lub więcej krotek (rekordów) o tej samej wartości klucza. Jeśli w relacji nie ma pól, których wartości są unikalne, zwykle wprowadza się dodatkowe pole liczbowe w celu utworzenia klucza zawierającego liczby porządkowe rekordów.

W odniesieniu do „Radioelementów (tranzystorów)” kluczem jest typ urządzenia, aw przypadku „magazyn” - numer regału, typ urządzenia.

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 klucze relacje. Każdy z możliwych kluczy można wybrać jako główny.

Klucze są powszechnie używane do następujących celów:

eliminacja zduplikowanych wartości w kluczowych atrybutach;

zamawianie krotek;

przyspieszenie pracy z krotkami relacji;

organizacja tabel łączących.

Załóżmy, że relacja R1 ma atrybut A niebędący kluczem, którego wartościami są wartości atrybutu kluczowego B innej relacji R2. Wtedy mówi się, że atrybut A relacji R1 (atrybut B relacji R2) jest klucz zewnętrzny... Połączenia między relacjami są ustanawiane za pomocą kluczy obcych.

Klasy relacji... Relacje w relacyjnej bazie danych są podzielone na dwie klasy na podstawie treści: relacje między obiektami i powiązane relacje.

Relacje między obiektami przechowują dane o grupach jednorodnych obiektów, zjawisk lub procesów, które mają te same cechy. W relacji z obiektem klucz nazywany jest podstawowym lub po prostu kluczem relacji.

Połączona postawa przechowuje dane o relacjach między relacjami między obiektami. Powiązana relacja zawiera klucze powiązanych relacji między obiektami i dane, które ilościowo lub jakościowo charakteryzują relację. Klucze powiązanej relacji nazywane są kluczami obcymi, ponieważ są kluczami podstawowymi innych relacji. Model relacyjny nakłada na klucze obce ograniczenie zwane integralnością referencyjną. Oznacza to, że każda wartość klucza obcego musi mieć odpowiednią krotkę relacji obiektu. Bez tego możliwe jest, że klucz obcy odnosi się do obiektu, o którym nic nie wiadomo.

Spójrzmy na przykład obiektu i powiązanych relacji.

Szczegóły relacji między obiektami

Relacja między materiałami a obiektem

Połączona relacja „Proces technologiczny”

W przypadku opcji „Szczegóły” kluczem głównym jest numer części. W relacji Materiał kluczem podstawowym jest kod materiału. W odniesieniu do „procesu technologicznego” kluczem obcym jest numer części, kod materiału. Atrybut „Wskaźnik zużycia materiału dla części” jest ilościową charakterystyką relacji między częścią a materiałem.

Ponieważ nie każda tabela może być skojarzona z relacją, przedstawiamy warunki, których spełnienie pozwala uznać tabelę za relację.

1. Wszystkie wiersze tabeli muszą być unikalne, tj. nie może być wierszy z tymi samymi kluczami podstawowymi.

2. Nazwy kolumn w tabeli muszą być różne, a ich wartości proste, tj. grupa wartości w jednej kolumnie jednego wiersza jest nieprawidłowa.

3. Wszystkie wiersze jednej tabeli muszą mieć taką samą strukturę, z odpowiednimi nazwami i typami kolumn.

4. Kolejność wierszy w tabeli może być dowolna.

Indeksowanie... Zdefiniowanie klucza dla tabeli oznacza automatyczne sortowanie rekordów, kontrolowanie, czy nie ma zduplikowanych wartości w kluczowych polach w rekordach, oraz zwiększenie szybkości wyszukiwania w tabeli. Aby zaimplementować te funkcje, DBMS używa indeksowania. Indeks Jest sposobem na przyspieszenie operacji wyszukiwania rekordów w tabeli, a co za tym idzie innych operacji z wykorzystaniem wyszukiwania: ekstrakcji, modyfikacji, sortowania itp. Tabela, dla której używany jest indeks, nosi nazwę indeksowana. Kluczowe pola tabeli w wielu DBMS są zwykle indeksowane automatycznie. Nazywa się indeksy utworzone dla kluczy indeksy podstawowe.

Czasami nazywane są indeksy utworzone przez użytkownika dla pól niebędących kluczami indeksy pomocnicze (niestandardowe)... Wprowadzenie takich indeksów nie zmienia fizycznego rozmieszczenia rekordów tabeli, ale wpływa na kolejność skanowania rekordów.

Głównym powodem przyspieszenia różnych operacji na indeksowanych tabelach jest to, że większość pracy jest wykonywana na małych plikach indeksowych, a nie na samych tabelach. Największy efekt poprawy wydajności pracy z tabelami indeksowanymi uzyskuje się dla tabel o dużych rozmiarach. Indeksowanie wymaga niewielkiej dodatkowej przestrzeni dyskowej i niewielkiego obciążenia procesora w celu zmiany indeksów w locie.

Powiązania między relacjami (tabele).Zazwyczaj baza danych to zbiór powiązanych tabel. Łączenie tabel zapewnia następujące korzyści:

wiele DBMS podczas łączenia tabel automatycznie kontroluje integralność danych wprowadzanych do bazy zgodnie z ustanowionymi łączami, co zwiększa wiarygodność informacji przechowywanych w bazie;

łatwiejszy dostęp do danych. Łączenie tabel w celu wykonywania operacji, takich jak wyszukiwanie, przeglądanie, edycja, pobieranie i przygotowywanie raportów przy użyciu informacji z różnych tabel, zmniejsza liczbę jawnych wywołań tabel danych i liczbę operacji w każdej z nich.

Istnieje kilka typów połączeń między relacjami. Powiązane relacje często wchodzą w interakcje w formie tabeli głównej i tabeli podrzędnej. Stół główny można również nazwać rodzicem, a podwładnym - dzieckiem. Ta sama tabela może być podstawową dla jednej tabeli bazy danych i podrzędną dla innej.

Relacja jeden do wieluoznacza, że \u200b\u200bjeden rekord w tabeli nadrzędnej może odpowiadać kilku rekordom (w tym jednemu) w tabeli podrzędnej. W tabeli nadrzędnej mogą znajdować się rekordy, dla których obecnie nie ma pasujących rekordów w tabeli podrzędnej. Istnieje również sztywna relacja jeden do wielu, gdy każdy rekord w tabeli nadrzędnej musi odpowiadać rekordowi w tabeli podrzędnej.

Relacja jeden do wielu jest najczęściej stosowaną relacją w relacyjnych bazach danych. Przykład linku: tabele „Studenci” i „Egzaminy” mogą być połączone relacją „jeden do wielu” w polu „Liczba ocen”. To połączenie oznaczałoby, że jeden rekord o uczniu z tabeli „Studenci” może być powiązany z kilkoma rekordami egzaminów zdanych przez danego ucznia w tabeli „Egzaminy”.

Komunikacja jeden do jednego występuje, gdy tylko jeden rekord w tabeli podrzędnej odpowiada jednemu rekordowi w tabeli nadrzędnej. Ta relacja jest rzadka i oznacza, że \u200b\u200binformacje z dwóch tabel można połączyć w jedną. Obecność dwóch tabel wskazuje na chęć podzielenia informacji głównej i drugorzędnej na dwie relacje. Na przykład informacje o uczniach można podzielić na dwie tabele „Uczniowie” i „Informacje dodatkowe”, które zostaną połączone relacją jeden do jednego w polu Numer oceny. Relacja jeden do jednego powoduje wielokrotne odczyty w celu odczytania powiązanych informacji z wielu tabel, co spowalnia pobieranie potrzebnych informacji. Relacja jeden do jednego może być sztywna lub niesztywna.

Trzeci rodzaj połączenia to relacja wiele do wielu... Ten typ relacji oznacza, że \u200b\u200bkilka rekordów z jednej tabeli jest powiązanych z kilkoma rekordami z innej tabeli i odwrotnie. Na przykład: Może istnieć relacja wiele do wielu między grupami uczenia się a tabelami kursów i nauczycieli. Oznacza to, że każdy nauczyciel może uczyć kilku przedmiotów, a jednocześnie kilku nauczycieli może uczyć tego samego przedmiotu.

Niektóre systemy DBMS nie obsługują relacji wiele-do-wielu na poziomie integralności referencyjnej, chociaż pozwalają na niejawną implementację w tabelach. Uważa się, że bazę danych można zawsze przebudować, tak aby każda relacja wiele do wielu została zastąpiona jedną lub większą liczbą relacji jeden do wielu.

Zapewnienie integralności danych... Jedną z podstawowych koncepcji technologii baz danych jest koncepcja integralności. Ogólnie rzecz biorąc, ta koncepcja jest głównie związana z faktem, że baza danych odzwierciedla formularz informacyjny jakiś obiekt ze świata rzeczywistego lub zbiór wzajemnie połączonych obiektów ze świata rzeczywistego. W modelu relacyjnym obiekty świata rzeczywistego są reprezentowane jako zbiór wzajemnie powiązanych relacji. Przez integralność rozumiemy zgodność modelu informacyjnego domeny, przechowywanego w bazie danych, z obiektami świata rzeczywistego i ich wzajemnymi powiązaniami w każdym momencie. Każda zmiana w domenie, która jest istotna dla budowanego modelu, musi znaleźć odzwierciedlenie w bazie danych, a jednocześnie musi zostać zachowana jednoznaczna interpretacja modelu informacyjnego w zakresie dziedzinowym.

Wsparcie integralności w relacyjnym modelu danych w klasycznym rozumieniu obejmuje 3 aspekty.

Pierwsza to wsparcie integralność strukturalna, co jest interpretowane jako fakt, że relacyjny DBMS powinien pozwalać na pracę tylko z jednorodnymi strukturami danych typu „relacja relacyjna”. W tym przypadku pojęcie „relacji relacyjnej” musi spełniać wszystkie ograniczenia nałożone na nią w klasycznej teorii relacyjnej bazy danych (brak duplikatów, obowiązkowa obecność klucza pierwotnego, brak koncepcji uporządkowania krotek).

Oprócz integralności strukturalnej należy wziąć pod uwagę problem niezdefiniowanych wartości zerowych. Niezdefiniowana wartość jest interpretowana w modelu relacyjnym jako wartość, która jest obecnie nieznana. Ta wartość, gdy dodatkowe informacje w dowolnym momencie można zastąpić określoną wartością. Podczas porównywania wartości null nie mają zastosowania standardowe reguły porównania: jedna wartość null nigdy nie jest uważana za równą innej wartości null. Aby zidentyfikować równość wartości jakiegoś atrybutu z wartością niezdefiniowaną, stosuje się specjalne predykaty standardowe:

<имя атрибута> IS NULL i<имя атрибута> NIE JEST NULL.

Jeśli w danej krotce (w danym wierszu) określony atrybut ma nieokreśloną wartość, to predykat IS NULL ma wartość TRUE, a predykat IS NOT NULL ma wartość FALSE, w przeciwnym razie predykat IS NULL ma wartość FALSE, a NIE NULL jest PRAWDA.

Wprowadzenie wartości zerowych spowodowało konieczność zmodyfikowania klasycznej logiki dwuwartościowej i przekształcenia jej w trójwartościową.

Drugi to wsparcie integralność językowa, która polega na tym, że relacyjny DBMS musi zapewniać języki opisu i manipulacji danymi nie niższe niż standard SQL. Inne narzędzia do manipulacji danymi niskiego poziomu, które nie są zgodne ze standardem, nie powinny być dostępne.

Po trzecie, to wsparcie więzy integralności (Deklaratywna integralność referencyjna, DRI).

Więzy integralnościTo zbiór relacji między pojedynczymi tabelami w całej bazie danych. Naruszenie przynajmniej jednego takiego połączenia powoduje, że informacje w bazie danych są niewiarygodne. DBMS zazwyczaj blokuje działania, które naruszają integralność relacji między tabelami, tj. naruszają więzy integralności. Zapewnienie spójności referencyjnej oznacza, że \u200b\u200bDBMS podczas aktualizacji bazy danych zapewnia przestrzeganie następujących reguł dla powiązanych tabel:

pozycja z wartością klucza odsyłacza, której nie ma w tabeli głównej, nie może zostać dodana do tabeli podrzędnej;

rekord nie może zostać usunięty z tabeli głównej, chyba że zostaną usunięte powiązane rekordy w tabeli podrzędnej;

zmiana wartości klucza odsyłacza w rekordzie tabeli nadrzędnej jest niemożliwa, jeśli w tabeli podrzędnej są powiązane z nią rekordy.

Gdy użytkownik próbuje naruszyć te warunki w operacjach dodawania i usuwania rekordów lub aktualizacji kluczowych danych w powiązanych tabelach, DBMS powinien wyświetlać komunikaty o błędach i nie zezwalać na wykonywanie tych operacji.

Aby zapobiec utracie integralności referencyjnej, stosowany jest mechanizm kaskadowy. Polega na zapewnieniu następujących działań:

zmieniając pole odsyłacza w rekordzie tabeli nadrzędnej, należy synchronicznie zmieniać wartości pól odsyłaczy w odpowiednich rekordach tabeli podrzędnej;

podczas usuwania rekordu w tabeli nadrzędnej należy usunąć odpowiednie rekordy w tabeli podrzędnej.

Integralność strukturalna, językowa i referencyjna nie determinują semantyki bazy danych, nie mają związku z zawartością bazy danych, dlatego wprowadzono pojęcie wsparcie integralności semantycznej.

Wsparcie semantyczne można zapewnić na dwa sposoby: deklaratywne i proceduralne.... Sposób deklaratywny wiąże się z obecnością w DBMS mechanizmów, które zapewniają walidację i implementację szeregu deklaratywnie określonych reguł-ograniczeń, które są najczęściej nazywane „Regułami biznesowymi” lub deklaratywnymi ograniczeniami integralności.

Wyróżnia się następujące typy deklaratywnych ograniczeń integralności:

· Ograniczenia integralności atrybutu: wartość domyślna, ustawianie wartości obowiązkowych lub opcjonalnych (Null), ustawianie warunków wartości atrybutów.

Określenie wartości domyślnej oznacza, że \u200b\u200bza każdym razem, gdy do relacji zostanie wprowadzony nowy wiersz, jeśli w określonej kolumnie nie ma danych, temu atrybutowi zostanie przypisana wartość domyślna. Na przykład, wprowadzając nowe wpisy w polu roku publikacji, należy podać wartość bieżącego roku. W przypadku MS Access to wyrażenie będzie wyglądać następująco:

Tutaj NOW () to funkcja zwracająca wartość bieżącej daty, YEAR (dane) to funkcja zwracająca wartość roku dla daty określonej jako parametr.

Inny przykład, jako warunek dla wartości roku publikacji, należy podać wyrażenie, które sprawdzi, czy rok publikacji mieści się w przedziale od 1960 do roku bieżącego. W przypadku MS Access to wyrażenie będzie wyglądać następująco:

Od 1960 do ROKU (TERAZ ())

W MS DBMS SQL Server wartość domyślna jest rejestrowana jako „reguła biznesowa”. W takim przypadku zostanie użyte wyrażenie, w którym nazwa odpowiedniej kolumny musi zostać wyraźnie określona, \u200b\u200bna przykład:

YEAR_PUBL\u003e \u003d 1960 AND YEAR_PUB<= YEAR(GETDATE())

Tutaj GETDATE () jest funkcją MS SQL Server, która zwraca bieżącą datę, YEAR_PUB to nazwa kolumny odpowiadającej rokowi publikacji.

· Ograniczenia integralności określone w domenie... Te ograniczenia są przydatne, jeśli baza danych zawiera kilka kolumn różnych relacji, które pobierają wartości z tego samego zestawu prawidłowych wartości. Niektóre systemy DBMS umożliwiają definiowanie oddzielnych domen, ustawianie typu danych dla każdej domeny i odpowiednie ustawianie ograniczeń w postaci reguł biznesowych dla domen. W tym przypadku atrybuty są przypisywane do określonej domeny. Czasami struktura domeny jest niejawna. Na przykład w MS SQL Server zamiast pojęcia domeny wprowadza się pojęcie typu danych zdefiniowanego przez użytkownika, ale znaczenie tego typu danych jest w rzeczywistości równoważne znaczeniu domeny. Dogodnie jest ustawić ograniczenie wartości na poziomie domeny, wtedy zostanie ono automatycznie wykonane dla wszystkich atrybutów, które pobierają wartości z tej domeny. Jeśli ograniczenie ulegnie zmianie, to jego zamiana jest przeprowadzana raz na poziomie domeny, a wszystkie atrybuty pobierające wartości z tej domeny będą automatycznie działały zgodnie z nową regułą.

· Więzy integralności określone na poziomie relacji. Niektórych reguł semantycznych nie można przetłumaczyć na wyrażenia, które dotyczą tylko jednej kolumny. Na przykład, tworząc relację, Czytelnicy potrzebują co najmniej jednego numeru telefonu (domowego lub służbowego), aby szybko dotrzeć do czytelnika. W przypadku MS Access lub MS SQL Server odpowiednie wyrażenie będzie następujące:

HOME_PHON NIE JEST NULL LUB WORK_PHON NIE JEST NULL

· Ograniczenia integralności określone na poziomie połączenia między relacjami: ustawianie obowiązku komunikacji, zasady kaskadowego kasowania i kaskadowej aktualizacji danych, ustawianie obsługi ograniczeń mocy łączności. Tego rodzaju ograniczenia można wyrazić, określając obowiązkowe lub opcjonalne wartości kluczy obcych w powiązanych relacjach.

Deklaratywne ograniczenia integralności odnoszą się do ograniczeń, które są natychmiast weryfikowalne. Istnieją odroczone ograniczenia integralności. Te ograniczenia integralności są obsługiwane przez mechanizm transakcji i wyzwalacza.

Błędem byłoby zakładanie, że w systemach informatycznych wykorzystywane są tylko relacyjne bazy danych. Często można znaleźć implementacje baz danych oparte na modelach hierarchicznych, sieciowych, relacyjnych i innych. Niemniej jednak większość systemów informatycznych oparta jest na relacyjnych bazach danych, których fundamenty położył pod koniec lat 60. XX wieku E. Codd, określając podstawowe zasady i operacje, jakie należy zastosować przy wdrażaniu takich baz danych. Wiele modeli baz danych, które można znaleźć w systemach informatycznych, w taki czy inny sposób opiera się na zasadach relacyjnych baz danych i wykorzystuje różne dodatkowe narzędzia do usprawnienia pracy z określonymi typami danych, na przykład z danymi geograficznymi, danymi w czasie rzeczywistym (dane strumieniowe), dane wielowymiarowe itp.

Relacyjne bazy danych opierają się na relacyjnym modelu danych zbudowanym w oparciu o algebrę relacyjną, która stanowi podstawowe zasady pracy z danymi w odpowiednich bazach danych.

Relacyjny model danych

Budowa relacyjnego modelu danych opiera się na zrozumieniu, że każdy zbiór danych można przedstawić w postaci relacji, sformatowanej, ale w postaci tabeli (ryc. 1.12), w której dane są prezentowane

atrybuty i wartości na przecięciu odpowiedniego atrybutu z rekordem (krotką).

Termin „Relacja” oznacza zbiór danych połączonych w zbiór rekordów (krotki) i opisanych przez nagłówek zawierający zestaw atrybutów.

W powyższym przykładzie cały zestaw wartości zadania i część nagłówka z nazwanymi atrybutami, na których są umieszczane wartości, nazywa się relacją. Pod względem logiki formalnej relację w ujęciu ogólnym można przedstawić następująco:

R (A, T), i \u003d (1..n) (11)

W tej reprezentacji A jest rozumiane jako atrybut opisujący jedną cechę danych i przez T- typ danych, z którym muszą być zgodne dane, które mają być reprezentowane w relacji. Powyższy przykład jest nieformalnym stwierdzeniem związku. Jej tytuł nie określa typów danych, które opisują informacje prezentowane w treści relacji.

Zwykle nagłówek relacji, w którym wskazane są nazwy atrybutów i ich typy, nazywany jest schematem relacji, a zestaw wzajemnie powiązanych schematów relacji nazywany jest schematem danych. Nagłówek relacji zawiera standardowe typy danych lub typy wywodzące się z typów standardowych, a zestaw wartości skojarzonych z określonym atrybutem standardowego lub pochodnego typu danych nazywany jest domeną.

Termin „domena” w teorii baz danych oznacza dopuszczalny zbiór nazwanych wartości jednego typu, które mają określone znaczenie

Z tej definicji wynika, że \u200b\u200bdomena charakteryzuje się następującymi właściwościami:

• domena przenosi pewien ładunek semantyczny, który wyraża się w zrozumieniu znaczenia opisywanych danych, co zwykle zbiega się ze zrozumieniem danych z obszaru tematycznego;
• domena jest zdefiniowana za pomocą prostego lub pochodzącego z prostego typu danych, co pozwala na stosowanie prostych operacji logicznych na danych;
• domena może zawierać warunek logiczny, który identyfikuje określony podzbiór danych ważnych dla tej domeny.

Ciało relacji jest budowane ze zbioru rekordów, które w kategoriach algebry relacyjnej nazywane są krotkami i reprezentują informacje istniejące w domenie w ramach rozważanego obiektu lub grupy powiązanych ze sobą obiektów.

Zatem zgodnie z definicją krotki zawiera wszystkie możliwe dane, które są zgodne z regułami określonymi przez poszczególne domeny. Co więcej, każdy element danych krotek odpowiada tylko jednej domenie i jest zgodny ze wszystkimi właściwościami zdefiniowanymi przez tę domenę.

Opis krotki korzysta z wielu ważnych właściwości, z których niektóre przedstawiono poniżej:

każda krotka zawiera tylko jedną wartość dla każdego z atrybutów charakteryzujących relację;

nie zakłada się porządku dla składników krotki, podobnie jak elementy domeny;

każdy podzbiór krotek jest reprezentowany przez podobną krotkę.

Łącząc domeny i krotki, można utworzyć relację, która jest ogólnie zdefiniowana w następujący sposób;

R [<Заголовок>]{<Список кортежей >}. (1.2)

Nagłówek relacji jest reprezentowany przez listę atrybutów oddzielonych przecinkami. Istotny jest również fakt, że drugi parametr relacji, jeśli jest poprawnie przedstawiony, oznaczony jest terminem „Ciało”, które zawiera wiele krotek. Ale aby uprościć nieformalną komunikację i uprościć prezentację, termin „ciało” zostaje zastąpiony terminem „krotka”, co oznacza, że \u200b\u200bwszystkie krotki tworzą korpus relacji. Oprócz zrozumienia terminów „krotka”, „domena” i „ciało” w teorii relacyjnych baz danych istnieje ograniczenie, że wszystkie krotki tej samej relacji należą do tego samego typu krotki, a ten typ krotki musi być dokładnie taki sam zgodnie z definicją zawartą w tytule związku. Zatem wszystkie reguły prezentacji danych zdefiniowane w nagłówku mają zastosowanie do wszystkich krotek relacji.

Biorąc pod uwagę definicje relacji, krotki i domeny opisane powyżej, można sformułować podstawowe właściwości relacji. Jako przykład właściwości relacji, rozważ związek informacji o pracownikach organizacji, który obejmuje atrybuty krotek, ale imię i nazwisko pracownika, jego stanowisko i oficjalne wynagrodzenie. Te atrybuty będą stanowić tytuł relacji, tworząc domeny dla relacji. Każdy atrybut nagłówka zawiera nie tylko nazwę atrybutu, ale także jego typ (rys. 1.13), który określa możliwe typy przechowywanych danych w zakresie ich prezentacji, przetwarzania i ograniczeń.

Postać: 1.13. Przykład relacji pracowniczej

Każda relacja w relacyjnej bazie danych ma następujące właściwości.

1. Każda krotka zawiera tylko jedną wartość odpowiedniego typu dla każdego atrybutu (relacja jest znormalizowana).

Każdemu atrybutowi w przedstawionym przykładzie, w ramach każdej krotki, przypisana jest tylko jedna wartość, którą można zobaczyć na przecięciu wybranej domeny „imię i nazwisko pracownika” oraz krotki z pełnym imieniem i nazwiskiem „Pietrow Piotr Pietrowicz”. Stosunek odpowiadający tej właściwości jest znormalizowany, tj. jest w tym przypadku w pierwszej postaci normalnej, 1NF.

2. Atrybuty nie są porządkowane według żadnej reguły.

Wcześniej zdefiniowano, że składniki krotki nie są uporządkowane, a ponieważ krotka musi jednoznacznie pasować do atrybutów nagłówka, atrybuty te również nie są uporządkowane. Musisz zrozumieć, że osoba reprezentująca struktury danych zawsze stosuje pewne reguły dotyczące kolejności atrybutów i krotek, ale należy pamiętać, że taka kolejność nie jest ważna i nie jest brana pod uwagę podczas pracy z relacyjnymi bazami danych. Dlatego pojęcia „pierwszy atrybut” lub „drugi atrybut” nie mają zastosowania do obiektów modelu relacyjnego, a także nie można omawiać terminu „następny atrybut” lub „poprzedni atrybut”.

Taka sytuacja daje pewną sztywność w pracy z bazami danych, poprawiając jakość kodu programu przetwarzającego dane, co często nie zawsze jest oczywiste przy programowaniu z mniejszą sztywnością.

3. Krotki nie są porządkowane według żadnej reguły.

Właściwość ta wynika z faktu, że reprezentowana jest treść relacji

zbiór, który nie jest uporządkowany według reguł matematycznych. Ponieważ relacje relacyjne podlegają regułom pracy ze zbiorami matematycznymi, używany jest aparat matematyczny do pracy ze zbiorami.

Oczywiście, przedstawiając relację na papierze, osoba będzie starała się ją w jakiś sposób usprawnić, aby była łatwiejsza do przetworzenia. Jednak to odzwierciedlenie związku nie jest regułą i jest tylko reprezentacją związku. Sama relacja pozostaje nieuporządkowana, a prezentując ją w innej kolejności krotek, sama relacja nie może zostać zmieniona i można do niej zastosować te same operatory przetwarzania, jak w przypadku relacji z inną uporządkowaną reprezentacją. Oznacza to, że w przypadku implementacji w bazach danych uporządkowana reprezentacja relacji nie ma sensu, co oznacza, że \u200b\u200bkażda relacja w bazie danych jest nieuporządkowana.

4. W relacji nie ma zduplikowanych krotek.

Ta właściwość relacji wynika ze zrozumienia, że \u200b\u200bciało relacji jest reprezentowane przez zbiór, a żaden zbiór, biorąc pod uwagę jego matematyczną reprezentację, nie zawiera duplikatów. Wynika z tego, że biorąc dowolną krotkę reprezentowaną przez wszystkie atrybuty użyte w relacji, niemożliwe będzie znalezienie pojedynczej krotki z dokładnie takimi samymi wartościami atrybutów.

Jednocześnie właściwość ta ilustruje różnice między relacją a tabelą. Rozumiejąc, że tabela danych jest fizyczną implementacją relacji w bazie danych, można w niej umieszczać rekordy o takich samych wartościach, chyba że oczywiście taka możliwość jest zapewniona na poziomie logiki programu do budowy bazy danych, a relacja z definicji nigdy nie zawiera zduplikowanych krotek.

Często, gdy nie ma potrzeby odzwierciedlenia wartości opisywanych w relacji (ciele relacji), model relacyjny ogranicza się jedynie do określenia tytułu relacji z przepisem nazwy samej relacji lub tylko nazwy relacji. Te widoki relacyjnego modelu danych to filtrowane odwzorowania używane w specjalistycznych narzędziach do projektowania baz danych, takich jak IBM InfoSphere Data Architect (rysunek 1.14).

Głównymi informacjami zawartymi w relacyjnym modelu danych są nazwy relacji (encje), atrybuty i typy atrybutów opisujących związek. Dodatkowo model relacyjny odzwierciedla relacje między relacjami (bytami), co umożliwia wyświetlenie interakcji elementów ciał powiązanych relacji. Każdy z tych elementów modelu relacyjnego ma szereg pomocniczych cech, które udoskonalają.

do reprezentacji i przetwarzania elementów treści relacji. Chociaż te cechy nie są wyraźnie wizualizowane w modelu danych, są one brane pod uwagę podczas pełnego przedstawiania relacji, biorąc pod uwagę wyświetlanie treści relacji.

W modelu danych przedstawionym w przykładzie zastosowano filtr wyświetlania, który uwzględnia potrzebę wyświetlenia nazwy relacji (encji), składu atrybutywnego każdej relacji oraz relacji między relacjami. Brak typów atrybutów i innych charakterystyk w wizualizacji modelu nie oznacza, że \u200b\u200bnie są one zdefiniowane lub nie. Oznacza to po prostu, że model danych jest prezentowany na potrzeby uwzględnienia tylko określonych parametrów, a wszystkie inne cechy są ustalone w ukrytych komponentach modelu. Na przykład inną prezentacją może być przypadek pokazany na rys. 1.15.

W tym widoku oprócz nazw relacji (encji) i atrybutów wyświetlane są typy danych, które charakteryzują treść relacji, chociaż sama treść nie jest reprezentowana w tych modelach. Należy pamiętać, że model danych (model bazy danych) w wyspecjalizowanych narzędziach modelowania nastawiony jest na dalszą reprezentację w postaci struktury bazy danych, a wskazanie ciał relacji jest niepraktyczne. Z tego powodu treści relacji zazwyczaj nie są wyświetlane w modelach baz danych. Jeśli model jest zbudowany specjalnie w celu odzwierciedlenia operacji na relacjach, w pełnym tego słowa znaczeniu, wszystkie relacje powinny być reprezentowane za pomocą obiektów, które ilustrują możliwe wartości, które będą później przechowywane w tabelach bazy danych.

Podział ten często wprowadza pewne zamieszanie w poprawności wykorzystania określonego modelu danych (modelu bazy danych), co wymaga dokładniejszego opisu ich wykorzystania. Stąd model danych w postaci relacji jest wykorzystywany, gdy konieczne jest zilustrowanie możliwych operacji na danych relacji oraz zrozumienie prawidłowej interpretacji w modelu dziedzinowym, reprezentowanym przez obiekty wraz z ich możliwymi instancjami. Model danych w postaci encji i relacji (model EL) służy do tworzenia logicznego (infologicznego) modelu bazy danych bez określania konkretnych wartości danych i ma na celu dalszą reprezentację w postaci struktury bazy danych. Model w postaci tabel i linków budowany jest na poziomie fizycznym, odzwierciedlając specyfikę prezentacji i przetwarzania danych na poziomie DBMS. Wynikiem jest reprezentacja relacyjnego modelu danych w trzech głównych wersjach (Tabela 1.3).

Tablica 13

Opcje reprezentacji dla relacyjnych modeli danych

Rodzaj prezentacji	Używany terminologia	Spotkanie
Model z odzwierciedleniem nazwy związku, składu atrybutywnego, powiązań	Esencja Typ danych	Służy do modelowania logicznej struktury danych dla późniejszego przejścia do warstwy fizycznej
Model z odbiciem nagłówka i treści z możliwymi danymi	Nastawienie Nagłówek Atrybut / domena Typ danych	Służy do prezentacji ze wskazaniem możliwych wartości danych oraz zastosowania w razie potrzeby analizy możliwych operacji na relacjach i danych w relacjach
Model wyświetlający struktury fizycznej reprezentacji danych w DBMS	Atrybut / 11ole / Kolumna Typ danych	Służy do wyświetlania wariantu reprezentacji struktury, który zostanie zaimplementowany na poziomie fizycznym w DBMS

Uwaga. W tej sekcji omówiono formy prezentacji modelu bazy danych, co znajduje odzwierciedlenie w trzech opcjach. Należy pamiętać, że modelowanie baz danych opiera się na implementacji poziomów modelowania, w związku z czym istnieje interpretacja modeli danych zgodnie z tymi poziomami, które są reprezentowane przez inne typy modeli relacyjnych, co zostanie omówione później. W związku z tym nie jest konieczne traktowanie opisanej powyżej listy reprezentacji modeli jako wyczerpującej, rozumiejąc, że mogą istnieć inne reprezentacje i inne typy modeli.

• Boyko V.V. Savinkov V.M. Projektowanie baz danych systemów informatycznych.
• Typy danych zostaną omówione w kolejnych rozdziałach.
• Pojęcie „normalizacja” i formy normalne zostaną omówione w rozdz. 2.

Relacyjny model danych

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 stworzone od późnych lat siedemdziesiątych są relacyjne.

W 1970 roku pojawiły się artykuły omawiające zastosowanie różnych tabelarycznych modeli danych. Najważniejszym z nich był artykuł badacza IBM, dr E. Codda (Codd EF, A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, czerwiec 1970), gdzie został zastosowany po raz pierwszy 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. Zbuduj solidne podstawy do rozwiązywania problemów związanych ze 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 różnych typów relacyjnych DBMS.

Model relacyjny to wygodna i najczęściej stosowana forma reprezentacji danych w formie stoły (relacje ). Każdy związek ma imię 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 relacje 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, płaska tabela składająca się z kolumn i wierszy; tabela, w której każde pole jest atomowe;

3. domena - zbiór dopuszczalnych wartości, z których 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

		Atrybuty

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 powinny 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.

Podstawy relacyjnego modelu danych zostały po raz pierwszy nakreślone w artykule E. Codda w 1970 roku. Praca ta stała się bodźcem do powstania wielu artykułów i książek, w których model relacyjny był dalej rozwijany. Najpowszechniejsza interpretacja relacyjnego modelu danych należy do K. Date. Według Date model relacyjny składa się z trzech części:

Część konstrukcyjna.

Część integralna.

Część manipulacji.

Część konstrukcyjna opisuje, które obiekty są rozpatrywane przez model relacyjny. Postuluje się, że jedyną strukturą danych wykorzystywaną w modelu relacyjnym są znormalizowane relacje n-arowe.

Część integralna opisuje ograniczenia szczególnego rodzaju, które muszą być spełnione dla każdej relacji w dowolnej relacyjnej bazie danych. to integralność jednostki i integralność klucza obcego .

Część manipulacji opisuje dwa równoważne sposoby manipulowania danymi relacyjnymi - algebra relacyjna i rachunek relacyjny .

W tym rozdziale omówiono strukturalną część modelu relacyjnego.

Typy danych

Wszelkie dane używane w programowaniu mają swoje własne typy danych.

Ważny! Model relacyjny wymaga typów danych prosty.

Aby wyjaśnić to stwierdzenie, zastanów się, jakie typy danych są generalnie uwzględniane w programowaniu. Zazwyczaj typy danych są podzielone na trzy grupy:

Proste typy danych.

Strukturyzowane typy danych.

Referencyjne typy danych.

Proste typy danych

Proste lub niepodzielne typy danych nie mają struktury wewnętrznej. Ten typ danych nazywa się skalary ... Proste typy danych obejmują następujące typy:

Logiczny.

Strunowy.

Liczbowy.

Różne języki programowania mogą rozszerzyć i zawęzić tę listę, dodając typy, takie jak:

• Real.

• Monetarny.

  Niezliczone.

  Interwał.

Oczywiście pojęcie atomowości jest raczej względne. W ten sposób łańcuchowy typ danych można postrzegać jako jednowymiarową tablicę znaków, a cały typ danych jako zestaw bitów. Jedyną ważną rzeczą jest to, że wchodząc na tak niski poziom, przegrywasz semantyka (znaczenie) danych ... Jeżeli ciąg znaków wyrażający np. Nazwisko pracownika zostanie rozłożony na tablicę znaków, wówczas znaczenie takiego ciągu jako całości zostaje utracone.

Strukturyzowane typy danych

Strukturyzowane typy danych są przeznaczone do definiowania złożonych struktur danych. Strukturyzowane typy danych są zbudowane z elementów składowych zwanych komponentami, które z kolei mogą mieć strukturę. Następujące typy danych można cytować jako uporządkowane typy danych:

• Rekordy (struktury)

Matematycznie tablica jest funkcją o ograniczonym zakresie. Rozważmy na przykład skończony zbiór liczb naturalnych

nazywany zbiorem indeksów. Pokaz

od zbioru do zbioru liczb rzeczywistych definiuje jednowymiarową tablicę rzeczywistą. Wartość tej funkcji dla jakiejś wartości indeksu nazywana jest elementem tablicy odpowiadającym. Tablice wielowymiarowe można definiować podobnie.

Rekord (lub struktura) jest krotką jakiegoś kartezjańskiego iloczynu zbiorów. W rzeczywistości rekord jest nazwaną uporządkowaną kolekcją elementów, z których każdy należy do typu. Stąd wpis jest elementem zestawu ... Deklarując nowe typy rekordów w oparciu o istniejące typy, użytkownik może konstruować dowolnie złożone typy danych.

Wspólną cechą uporządkowanych danych jest to, że mają strukturę wewnętrznąużywany przez na tym samym poziomie abstrakcjijako same typy danych.

Wyjaśnijmy to w następujący sposób. Podczas pracy z tablicami lub rekordami możesz manipulować tablicą lub rejestrować zarówno za pomocą jednej całości (tworzenie, usuwanie, kopiowanie całych tablic lub rekordów), jak i element po elemencie. W przypadku strukturalnych typów danych istnieją specjalne funkcje - konstruktory typów, które pozwalają na tworzenie tablic lub rekordów z elementów prostszych typów.

Podczas pracy z prostymi typami danych, takimi jak liczbowe, manipulujemy nimi jako niepodzielnymi obiektami całkowitymi. Aby „zobaczyć”, że numeryczny typ danych jest w rzeczywistości złożony (jest to zbiór bitów), należy przejść na niższy poziom abstrakcji. Na poziomie kodu programu będzie to wyglądać jak wstawianie asemblera do kodu języka wysokiego poziomu lub użycie specjalnych operacji bitowych.

Referencyjne typy danych

Typ danych odniesienia (wskaźniki ) ma na celu zapewnienie możliwości wskazania innych danych. Wskaźniki są charakterystyczne dla języków proceduralnych, które mają koncepcję obszaru pamięci do przechowywania danych. Typ danych referencyjnych jest przeznaczony do obsługi złożonych struktur zmieniających się, takich jak drzewa, wykresy, struktury rekurencyjne.

Typy danych używane w modelu relacyjnym

W rzeczywistości dla relacyjnego modelu danych rodzaj użytych danych nie jest ważny. Wymaganie typu danych prosty, musisz to zrozumieć operacje relacyjne nie powinny uwzględniać wewnętrznej struktury danych... Oczywiście należy opisać akcje, które można wykonać z danymi jako całością, np. Można dodać dane typu numerycznego, w przypadku stringów możliwa jest operacja konkatenacji itp.

Z tego punktu widzenia, jeśli rozważymy na przykład tablicę jako całość i nie stosujemy operacji elementarnych, to tablicę można uznać za prosty typ danych. Ponadto możesz stworzyć własny, dowolnie złożony typ danych, opisać możliwe akcje z tym typem danych, a jeśli operacje nie wymagają znajomości wewnętrznej struktury danych, to ten typ danych będzie również prosty z punktu widzenia teorii relacyjnej. Na przykład możesz utworzyć nowy typ - liczby zespolone jako rekord formularza gdzie. Możesz opisać funkcje dodawania, mnożenia, odejmowania i dzielenia oraz wszystkie działania z komponentami i wykonuj tylko wewnątrzte operacje. Następnie, jeśli w akcjach tego typu używasz tylkoopisane operacje, struktura wewnętrzna nie ma znaczenia, a typ danych z zewnątrz wygląda jak atomowy.

Dokładnie tak działa niektóre post-relacyjne systemy DBMS z dowolnie złożonymi typami danych tworzonymi przez użytkowników.

Domeny

W relacyjnym modelu danych pojęcie typu danych jest ściśle związane z pojęciem domeny, którą można uznać za specyfikację typu danych.

Domena jest pojęciem semantycznym. Domenę można postrzegać jako podzbiór wartości pewnego typu danych, które mają określone znaczenie. Domena charakteryzuje się następującymi właściwościami:

Domena ma unikalna nazwa(w bazie danych).

Domena jest zdefiniowana na niektórych prostytyp danych lub w innej domenie.

Domena może mieć kilka plików warunek logicznyktóry pozwala opisać podzbiór danych, które są ważne dla danej domeny.

Domena niesie pewną domenę obciążenie semantyczne.

Na przykład domenę, która ma znaczenie „wiek pracownika”, można opisać jako następujący podzbiór zbioru liczb naturalnych:

Różnica między dziedziną a pojęciem podzbioru polega właśnie na tym domena odzwierciedla semantykęokreślone przez obszar tematyczny. Może istnieć kilka domen, które pokrywają się jako podzbiory, ale mają różne znaczenia. Na przykład domeny „Waga części” i „Dostępna ilość” można podobnie opisać jako zbiór nieujemnych liczb całkowitych, ale znaczenie tych domen będzie inne i będą one różnorodnydomeny.

Główne znaczenie domen jest takie domeny ograniczają porównania... Z logicznego punktu widzenia niewłaściwe jest porównywanie wartości z różnych dziedzin, nawet jeśli są one tego samego typu. Jest to przejaw semantycznego ograniczenia domen. Poprawne składniowo zapytanie „podaj listę wszystkich części o masie większej niż dostępna ilość” nie odpowiada znaczeniu pojęć „ilość” i „waga”.

Komentarz... Koncepcja domeny pomaga poprawnie symulowaćtematyka. Podczas pracy z prawdziwym systemem w zasadzie możliwa jest sytuacja, w której trzeba odpowiedzieć na powyższe zapytanie. System da odpowiedź, ale prawdopodobnie będzie to bez znaczenia.

Komentarz... Nie wszystkie domeny mają warunek logiczny, który ogranicza możliwe wartości domeny. W tym przypadku zestaw możliwych wartości domeny jest zgodny z zestawem możliwych wartości typu danych.

Komentarz... Nie zawsze jest oczywiste, jak ustawić warunek logiczny, który ogranicza możliwe wartości domeny. Będę wdzięczny komuś, kto poda mi warunek dla typu string, który ustawia domenę „Nazwisko pracownika”. Oczywiste jest, że wiersze będące nazwiskami nie powinny zaczynać się cyframi, znakami usługowymi, miękkim znakiem itp. Ale czy nazwisko „Гггггыыыыыый” (s) jest dopuszczalne? Dlaczego nie? Oczywiście, że nie! A może ktoś na złość tak siebie nazwie. Trudności tego rodzaju powstają, ponieważ nie zawsze można formalnie opisać znaczenie zjawisk rzeczywistych. Po prostu, jak wszyscy ludzie, intuicyjnie rozumiemy, czym jest nazwisko, ale nikt nie może podać takiej formalnej definicji, która odróżniałaby nazwiska od ciągów znaków, które nie są nazwiskami. Wyjście z tej sytuacji jest proste - polegać na inteligencji pracownika wprowadzającej nazwiska do komputera.

Relacje, atrybuty, krotki relacji

Definicje i przykłady

Podstawową koncepcją relacyjnego modelu danych jest koncepcja relacje ... Przy definiowaniu pojęcia relacji będziemy kierować się książką K. Date.

Definicja 1. Atrybut relacji istnieje kilka typów<Имя_атрибута: Имя_домена>.

Nazwy atrybutów muszą być unikalne w ramach relacji. Często nazwy atrybutów relacji są takie same, jak odpowiadające im nazwy domen.

Definicja 2. Nastawienie zdefiniowany w wielu domenach (niekoniecznie różnych) zawiera dwie części: nagłówek i treść.

Nagłówek relacji zawiera stałą liczbę atrybutów relacji:

Relacja cielesna zawiera wiele krotek relacji. Każdy krotka relacji jest zbiorem par postaci<Имя_атрибута: Значение_атрибута>:

tak, że wartość atrybutu należy do domeny

Związek jest zwykle zapisywany jako:

lub krócej

,

lub po prostu

Nazywa się liczbę atrybutów w relacji stopień (lub -arność ) relacje.

Kardynalność zbioru krotek relacji jest nazywana moc relacje.

Wracając do matematycznej koncepcji relacji przedstawionej w poprzednim rozdziale, można wyciągnąć następujące wnioski:

Wniosek 1... Nagłówek relacji opisuje iloczyn kartezjański dziedzin, w których relacja jest zdefiniowana. Nagłówek jest statyczny, nie zmienia się podczas pracy z bazą danych. Jeśli relacja zmieniła, dodała lub usunęła atrybuty, to wynik jest już innypostawa (nawet o tej samej nazwie).

Wniosek 2... Ciało relacji to zbiór krotek, tj. podzbiór iloczynu kartezjańskiego dziedzin. Zatem treść relacji jest sama w sobie relacją w matematycznym sensie tego słowa. Treść relacji może się zmieniać podczas pracy z bazą danych - można zmieniać, dodawać i usuwać krotki.

Przykład 1 ... Rozważ relację „Pracownicy” zdefiniowaną w domenach „Numer_pracownika”, „Nazwisko”, „Wynagrodzenie”, „Numer_wydziału”. Ponieważ Ponieważ wszystkie domeny są różne, wygodnie jest nadawać nazwy atrybutom relacji w taki sam sposób, jak odpowiadające im domeny. Wygląda jak nagłówek relacji.

Model danych to zbiór struktur danych i operacji do ich przetwarzania. Korzystając z modelu danych, można wizualizować strukturę obiektów i nawiązane między nimi relacje. Terminologia modeli danych charakteryzuje się pojęciami „elementu danych” i „wiążących reguł”. Element danych opisuje dowolny zestaw danych, a wiążące reguły definiują algorytmy relacji między elementami danych. Do tej pory opracowano wiele różnych modeli danych, ale w praktyce stosuje się trzy główne. Przydziel hierarchiczne, sieciowe i relacyjne modele danych. W związku z tym mówią o hierarchicznym, sieciowym i relacyjnym DBMS.

О Hierarchiczny model danych. Hierarchicznie uporządkowane dane są bardzo powszechne w życiu codziennym. Na przykład struktura instytucji szkolnictwa wyższego to wielopoziomowa struktura hierarchiczna. Hierarchiczna (drzewiasta) baza danych składa się z uporządkowanego zestawu elementów. W tym modelu oryginalne elementy generują inne elementy, a te elementy z kolei generują następujące elementy. Każde dziecko ma tylko jednego rodzica.

Schematy organizacyjne, listy materiałów, spis treści w książkach, plany projektów i wiele innych zbiorów danych można prezentować w sposób hierarchiczny. Integralność powiązań między przodkami i potomkami jest zachowywana automatycznie. Z zasady żaden potomek nie może istnieć bez swojego rodzica.

Główną wadą tego modelu jest konieczność korzystania z hierarchii, jaka została założona w bazie danych podczas projektowania. Potrzeba ciągłej reorganizacji danych (a często niemożność takiej reorganizacji) doprowadziła do powstania bardziej ogólnego modelu - sieci.

Informacje o modelu danych sieci. Sieciowe podejście do organizowania danych jest rozszerzeniem podejścia hierarchicznego. Ten model różni się od modelu hierachicznego tym, że każdy wygenerowany element może mieć więcej niż jeden element nadrzędny. ■

Ponieważ baza danych sieci może bezpośrednio reprezentować wszystkie typy relacji nieodłącznie związane z danymi odpowiedniej organizacji, dane te można przeglądać, eksplorować i wyszukiwać na różne sposoby, to znaczy model sieci nie jest połączony tylko jedną hierarchią. Aby jednak skomponować zapytanie do sieciowej bazy danych, konieczne jest wnikliwe zagłębienie się w jej strukturę (posiadanie pod ręką diagramu tej bazy) i opracowanie mechanizmu nawigacji po bazie, co jest istotną wadą tego modelu bazy danych.

O relacyjnym modelu danych. Podstawową ideą relacyjnego modelu danych jest przedstawienie dowolnego zbioru danych jako dwuwymiarowej tabeli. W najprostszym przypadku model relacyjny opisuje pojedynczą dwuwymiarową tabelę, ale najczęściej model ten opisuje strukturę i relacje między kilkoma różnymi tabelami.

Relacyjny model danych

Tak więc celem systemu informacyjnego jest przetwarzanie daneo obiektybiorąc pod uwagę rzeczywisty świat znajomościmiędzy obiektami. W teorii DB dane są często nazywane atrybuty iobiekty - podmioty.Przedmiot, atrybut i połączenie to podstawowe pojęcia I.S.

Obiekt(lub jednostka) jest czymś, co istnieje i dostrzegalny,to znaczy, obiekt można nazwać tym „czymś”, dla którego istnieje nazwa i sposób na odróżnienie jednego podobnego obiektu od drugiego. Na przykład każda szkoła jest przedmiotem. Przedmioty to także osoba, klasa w szkole, firma, stop, związek chemiczny itp. Przedmioty mogą być nie tylko przedmiotami materialnymi, ale także bardziej abstrakcyjnymi koncepcjami, odzwierciedlającymi rzeczywisty świat. Na przykład wydarzenia, regiony, dzieła sztuki; książki (nie jako produkty drukowane, ale jako dzieła), przedstawienia teatralne, filmy; normy prawne, teorie filozoficzne itp.

Atrybut(lub dany)- jest to wskaźnik charakteryzujący określony obiekt i przyjmujący dla określonego wystąpienia obiektu jakąś wartość liczbową, tekstową lub inną. System informacyjny operuje zbiorem obiektów zaprojektowanych w odniesieniu do danego obszaru tematycznego, z wykorzystaniem określonego wartości atrybutów(dane) niektórych obiektów. Na przykład weźmy zajęcia w szkole jako zbiór obiektów. Liczba uczniów w klasie jest zadana i przyjmuje wartość liczbową (jedna klasa liczy 28, inna 32). Nazwa klasy to taka, która ma znaczenie tekstowe (jedna ma 10 A, druga 9B itd.).

Rozwój relacyjnych baz danych rozpoczął się pod koniec lat sześćdziesiątych XX wieku, kiedy pojawiły się pierwsze artykuły omawiające; możliwość wykorzystania znanych i naturalnych sposobów prezentacji danych w projektowaniu baz danych - tzw. tabelaryczne modele datalogiczne.

Za twórcę teorii relacyjnych baz danych uważa się pracownika IBM, dr E. Codda, który opublikował 6 (artykuł z czerwca 1970 Relacyjny model danych dla dużych banków danych współdzielonych(Relacyjny model danych dla dużych zbiorczych banków danych). W tym artykule po raz pierwszy użyto terminu „relacyjny model danych”. Teoria relacyjnych baz danych, opracowana w latach 70. w Stanach Zjednoczonych przez dr E. Codda, ma potężne podstawy matematyczne, które opisują zasady skutecznego organizowania danych. Podstawy teoretyczne opracowane przez E. Codda stały się podstawą do rozwoju teorii projektowania baz danych.

E. Codd, będąc z wykształcenia matematykiem, zasugerował wykorzystanie do przetwarzania danych aparatu teorii mnogości (suma, przecięcie, różnica, iloczyn kartezjański). Udowodnił, że każdy zbiór danych można przedstawić w postaci dwuwymiarowych tabel specjalnego rodzaju, zwanych w matematyce „relacjami”.

Relacyjnyrozważana jest taka baza danych, w której wszystkie dane są prezentowane użytkownikowi w postaci prostokątnych tabel wartości danych, a wszystkie operacje na bazie sprowadzają się do manipulowania tabelami.

Tabela składa się z kolumny (pola)i linie (rekordy);ma nazwę, która jest unikalna w bazie danych. Stółodzwierciedla rodzaj obiekturealny świat (istota),i każdą z niej ciąg to określony obiekt.Każda kolumna w tabeli jest zbiorem wartości dla określonego atrybutu obiektu. Wartości są wybierane ze zbioru wszystkich możliwych wartości atrybutu obiektu, który jest nazywany domena.

W swojej najbardziej ogólnej formie, dziedzinę definiuje się przez określenie podstawowego typu danych, do którego należą elementy domeny, oraz dowolnego wyrażenia logicznego zastosowanego do elementów danych. Jeśli podczas oceny warunku logicznego elementu danych wynikiem jest „prawda”, wówczas element ten należy do domeny. W najprostszym przypadku dziedzinę definiuje się jako prawidłowy potencjalny zbiór wartości tego samego typu. Na przykład zbiór dat urodzenia wszystkich pracowników stanowi „domenę daty urodzenia”, a nazwiska wszystkich pracowników stanowią „domenę nazwisk pracowników”. Domena daty urodzenia ma typ danych, który może przechowywać informacje o punktach w czasie, a domena nazwisk pracowników musi być typem znakowym.

Jeśli dwie wartości pochodzą z tej samej domeny, możesz porównać te dwie wartości. Na przykład, jeśli dwie wartości pochodzą z domeny dat urodzenia, możesz je porównać, aby określić, który pracownik jest starszy. Jeśli wartości są pobierane z różnych dziedzin, to ich porównanie nie jest dozwolone, ponieważ najprawdopodobniej nie ma to sensu. Na przykład nic konkretnego nie wyjdzie z porównania imienia i nazwiska oraz daty urodzenia pracownika.

Każda kolumna (pole) ma nazwę, która jest zwykle zapisywana na górze tabeli. Projektując tabele w ramach określonego DBMS, można wybrać dla każdego pola jego typ,czyli zdefiniowanie zestawu reguł jego wyświetlania, a także określenie, jakie operacje można wykonać na danych przechowywanych w tym polu. Zestawy typów mogą się różnić dla różnych DBMS.

Nazwa pola musi być unikalna w tabeli, jednak różne tabele mogą mieć pola o tej samej nazwie. Każda tabela musi mieć co najmniej jedno pole; pola są ułożone w tabeli zgodnie z kolejnością ich nazw w momencie ich utworzenia. W przeciwieństwie do pól, łańcuchy nie mają nazw; ich kolejność w tabeli nie jest określona, \u200b\u200ba liczba nie jest logicznie ograniczona.

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”, „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) jest nazywana klucz podstawowy... Często do numeracji rekordów w tabeli wprowadza się sztuczne pole. Takim polem może być na przykład jego liczba porządkowa, co zapewnia niepowtarzalność każdego rekordu w tabeli. Klucz musi mieć następujące właściwości.

Wyjątkowość.W żadnym momencie żadne dwie różne krotki relacji nie mają tej samej wartości dla kombinacji atrybutów zawartych w kluczu. Oznacza to, że tabela nie może zawierać dwóch wierszy z tym samym numerem identyfikacyjnym lub numerem paszportu.

Minimalizm.Żaden z atrybutów zawartych w kluczu nie może zostać wykluczony z klucza bez naruszenia unikalności. Oznacza to, że nie jest konieczne tworzenie klucza zawierającego zarówno numer paszportu, jak i numer identyfikacyjny. Wystarczy użyć dowolnego z tych atrybutów, aby jednoznacznie zidentyfikować krotkę. Nie należy również umieszczać w kluczu nieunikalnego atrybutu, to znaczy nie wolno używać jako klucza kombinacji numeru identyfikacyjnego i nazwiska pracownika. Wykluczając nazwisko pracownika z klucza, nadal możesz jednoznacznie zidentyfikować każdy wiersz.

Każda relacja ma co najmniej jeden możliwy klucz, gdyż całość wszystkich jej atrybutów spełnia warunek niepowtarzalności - wynika to z samej definicji relacji.

Jeden z możliwych kluczy jest wybierany losowo w jako klucz podstawowy.Inne możliwe klucze, jeśli istnieją, są traktowane jako alternatywne klucze.Na przykład, jeśli wybierzesz numer identyfikacyjny jako klucz podstawowy, numer paszportu będzie kluczem alternatywnym.

Relacja tabel jest istotnym elementem relacyjnego modelu danych. Jest wspierana 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). Stół 2.3 podsumowuje użyte terminy.

Tabela 2.3.Terminologia dotycząca baz danych

Teoria baz danych ____________ Relacyjne bazy danych _________ SQL Server __________

Tabela relacji

Tuple Record Row

Atrybut (pole) _______________ Kolumna lub kolumna

Relacyjne bazy danych

Relacyjna baza danychto zestaw relacji zawierający wszystkie informacje, które muszą być przechowywane w bazie danych. Oznacza to, że baza danych reprezentuje zestaw tabel wymaganych do przechowywania wszystkich danych. Tabele relacyjnej bazy danych są ze sobą logicznie powiązane.Wymagania dotyczące projektowania relacyjnej bazy danych można ogólnie zredukować do kilku reguł.

О Każda tabela ma w bazie danych unikalną nazwę i składa się z wierszy tego samego typu.

О Każda tabela składa się z ustalonej liczby kolumn i wartości. W jednej kolumnie wiersza nie można przechowywać więcej niż jednej wartości. Np. Jeśli istnieje tabela z informacjami o autorze, dacie publikacji, nakładzie itp., To kolumna z nazwiskiem autora nie może zawierać więcej niż jednego nazwiska. Jeśli książka jest napisana przez dwóch lub więcej autorów, będziesz musiał użyć dodatkowych tabel.

О W żadnym momencie w tabeli nie będzie dwóch wierszy, które się powielały. Wiersze muszą różnić się o co najmniej jedną wartość, aby można było jednoznacznie zidentyfikować dowolny wiersz w tabeli.

О Każda kolumna ma przypisaną nazwę, która jest unikalna w obrębie tabeli; jest dla niego ustawiony określony typ danych, dzięki czemu w tej kolumnie umieszczane są jednorodne wartości (daty, nazwiska, numery telefonów, kwoty pieniężne itp.).

О Cała zawartość informacyjna bazy danych jest prezentowana w postaci jawnych wartości samych danych, a ta metoda prezentacji jest jedyna. Na przykład relacja między tabelami opiera się na danych przechowywanych w odpowiednich kolumnach, a nie na jakichkolwiek wskaźnikach sztucznie definiujących relacje.

О Podczas przetwarzania danych można dowolnie odwoływać się do dowolnego wiersza lub kolumny tabeli. Wartości przechowywane w tabeli nie nakładają żadnych ograniczeń na kolejność dostępu do danych. Opis kolumny,