Entity (Entity) - rzeczywisty lub abstrakcyjny obiekt, który jest niezbędny dla obszaru tematycznego. Jednostka musi mieć rzeczownik w liczbie pojedynczej

Nieformalnym sposobem identyfikacji jednostek jest poszukiwanie abstrakcji opisujących obiekty, procesy, role i inne pojęcia. Formalnym sposobem identyfikacji bytów jest analiza opisów tekstowych obszaru tematycznego, wyróżnianie rzeczowników i wybieranie ich jako abstrakcji.

Instancja encji to określony reprezentant danej encji. Na przykład instancją podmiotu Pracownik może być pracownik Iwanow.

Każda jednostka musi mieć następujące właściwości:

mieć unikalną nazwę;

mieć jeden lub więcej atrybutów, które należą do jednostki lub są dziedziczone przez relację;

mieć jeden lub więcej atrybutów, które jednoznacznie identyfikują każde wystąpienie encji.

Atrybut jest cechą podmiotu, która jest istotna dla rozważanego obszaru tematycznego i ma na celu identyfikację, klasyfikację, charakterystykę ilościową lub wyrażenie stanu podmiotu.

Istnieją następujące typy atrybutów:

prosty - składa się z jednego elementu danych;

złożony - składa się z kilku elementów danych;

jednoznaczny - zawiera jedną wartość dla jednego podmiotu;

wielowartościowy - zawiera kilka wartości dla jednego podmiotu;

opcjonalny - może mieć pustą (niezdefiniowaną) wartość;

pochodna - wartość pochodna wartości innego atrybutu.

Unikalny identyfikator to zestaw atrybutów, których wartości są kolektywnie unikalne dla każdej instancji podmiotu. Usunięcie dowolnego atrybutu z identyfikatora narusza jego unikalność. Unikalne identyfikatory są podkreślone na diagramie.

Każda jednostka może mieć dowolną liczbę relacji z innymi jednostkami.

Relacje między podmiotami

Relacja — nazwane powiązanie między jednostkami, które ma znaczenie dla danej domeny.

Stopień relacji to liczba podmiotów uczestniczących w relacji.

Liczność relacji to liczba wystąpień encji uczestniczących w relacji.

W zależności od wartości mocy komunikacja może być jednego z trzech typów:

jeden do jednego (oznaczony 1:1).

jeden do wielu (oznaczony 1: N).

wiele do wielu (oznaczone przez M: N).

Jeden na jednego. Oznacza to, że w takiej relacji podmiot z jedną rolą zawsze odpowiada nie więcej niż jednemu podmiotowi z inną rolą. Ponieważ stopień połączenia dla każdej jednostki wynosi 1, są one połączone jedną linią.

Jeden za dużo. Encje z jedną rolą mogą odpowiadać dowolnej liczbie encji o innej roli.

Wiele do wielu. W takim przypadku każda ze skojarzonych encji może być reprezentowana przez dowolną liczbę wystąpień.

Podejście dokumentalne, oparte na klasycznym rozważeniu tematu, obejmuje tworzenie typów encji w oparciu o atrybuty każdego dokumentu, tworząc wspólny zestaw takich typów encji (jednostek atrybutów), których ich połączenie reprezentuje relację w pierwszym normalnym formularz (ryc. 4.2).

W tym przykładzie wstępna analiza dokumentów ujawniła zestaw atrybutów, które należy przedstawić podczas budowania modelu bazy danych. Załóżmy, że musimy zbudować model bazy danych do utworzenia dokumentu D1 „Zamówienie”. Dokument zawiera 10 atrybutów, z których każdy jest reprezentowany przez oddzielny typ jednostki zawierający odpowiedni atrybut typu prostego. Jednak ta reprezentacja nie może być uznana za całkowicie poprawną, ponieważ w dokumencie jest jeden atrybut, który jest niepraktyczny do rozważenia, ponieważ ma sens tylko w obrębie dokumentu i charakteryzuje pewne wystąpienie relacji w jego prezentacji w dokumencie. Ten atrybut to „Numer pozycji”. W rzeczywistości jego prezentacja w dokumencie, jak wykazała analiza dokumentu, jest realizowana w procesie odzwierciedlenia zamówionego towaru, a numeracja powstaje w odniesieniu do dokumentu jako przedmiotu obszaru przedmiotowego, a nie miejsce do przechowywania informacji o zamówionych towarach. Tym samym, ponieważ przykład nie ma za zadanie przechowywania informacji o obiekcie „Dokument” i jego prezentacji użytkownikowi, atrybut „Numer pozycji” jest również bez znaczenia z punktu widzenia relacji do zamówienia i towaru. Tym niemniej teraz nie usuniemy go z listy rozważanych atrybutów i typów podmiotów, uznając go za atrybut charakteryzujący kolejność towarów w zamówieniu.

Oddzielając typy encji od atrybutów dokumentu, deweloper dodaje jeszcze jedną cechę do tych już obecnych w dokumencie, a opis typów encji stanie się nieco pełniejszy (tabela 4.5), biorąc pod uwagę ich późniejszą reprezentację w modelu.

Tabela 4.5

Poniższy opis przedstawia cechy istotne dla modelu bazy danych:

• typ danych – opis pod względem modelu bazy danych rodzajów przechowywanych informacji, określający na poziomie fizycznej realizacji zasady prezentacji i przetwarzania w bazie danych;
• wymiar jest cechą używaną dla niektórych typów danych w celu określenia liczby znaków (bajtów), które muszą być użyte podczas przechowywania odpowiedniej wartości.

W prezentowanej tabeli opisującej typy encji kolumna „Wymiar” dla niektórych typów danych zawiera wartość liczbową ujętą w nawiasy klamrowe. Dzieje się tak dlatego, że dane całkowite, logiczne oraz data i czas w bazach danych są reprezentowane przez standardowe mechanizmy prezentacji, a rozmiar w bajtach jest zawsze znany do przechowywania danych tego typu.

Numeryczne typy danych i odpowiadające im typy danych logicznych zawsze mają stały wymiar:

• Boolean, Logical, Tinylnt, Bit - Boolean, Logiczny typ danych zawierający wartości „True” i „False”, identyczne z typem małej liczby całkowitej (Tinylnt) lub bitem (Bit) o ​​minimalnej długości 1 bajt (1 bit jeśli jest identyczny z typem Bit) i wartościami „O” lub „1”;
• Bit to 1-bitowy typ danych całkowitych reprezentujący wartości „O” lub „1”;
• Tinylnt to 1-bajtowy typ danych całkowitych;
• Smalllnt to 2-bajtowy typ danych całkowitych;
• Integer - 4-bajtowy typ danych typu integer;
• Biglnt, Long - typ liczby całkowitej o dużym rozmiarze (8 bajtów);
• Date - typ danych typu data, reprezentowany w wersji znakowej, o wymiarze 8 znaków (bajtów);
• Czas to czasowy typ danych, reprezentowany w wersji znakowej, o długości 8 znaków (bajtów).

W przypadku typów danych o stałych wymiarach kolumna „Wymiar” jest zwykle pusta, co oznacza, że ​​wskazanie samego typu danych już go definiuje i nie jest wymagane żadne dodatkowe wskazanie. Dla wszystkich innych typów danych ważne jest, aby wskazać maksymalny wymiar, biorąc pod uwagę specyfikę wartości, które mogą występować w dokumencie. W przypadku liczbowych typów danych określa się liczbę bajtów, które musi zajmować liczba oraz liczbę cyfr po przecinku, określającą dokładność liczby rzeczywistej. W przypadku typów danych znakowych wskazana jest liczba znaków, które powinny być przechowywane dla odpowiedniego atrybutu. Rodzaj znaku można przedstawić na trzy różne sposoby:

Text, CLOB - typ danych tekstowych, który reprezentuje duże informacje tekstowe przechowywane w specjalny sposób, a w tabeli bazy danych są pokazywane przez zestaw pierwszych znaków, których liczba jest wymiarem atrybutu tego typu;

• - Character to typ danych ciągu, który przechowuje dokładnie liczbę znaków określoną jako wymiar, wypełniając brakujące znaki na końcu ciągu spacjami;
• — Varchar to typ danych ciągu o zmiennej długości, dla którego wymiar określa maksymalną liczbę znaków, jakie może mieć przechowywany ciąg.

Typy Character i Varchar mają bardzo podobny charakter, ponieważ definiują typ danych łańcuchowych, ale specyfika reprezentacji danych określa warunki, w których dany typ jest używany. Tak więc, aby przechowywać dane o stałym rozmiarze (na przykład TIN (numer identyfikacyjny podatnika), BNK (kod identyfikacyjny banku) banku, numer zamówienia, numer artykułu itp.), zwykle stosuje się typ znaku, ponieważ dla takich dane nie mogą być opcje, gdy liczba znaków może różnić się od podanej w wymiarze atrybutu. Typ Varchar jest używany we wszystkich innych przypadkach, gdy nie ma potrzeby przechowywania dokładnej liczby znaków.

Termin „relacyjny” oznacza „oparty na relacji”. Relacyjna baza danych składa się z encji (tabel), które są ze sobą powiązane. Nazwa pochodzi od angielskiego słowa relacja-relacja.
Projektowanie bazy danych składa się z dwóch głównych faz: modelowania logicznego i fizycznego.
Podczas modelowania logicznego zbierasz wymagania i tworzysz model bazy danych, który jest niezależny od konkretnego DBMS (relacyjnego systemu zarządzania bazami danych). Jest to podobne do tego, jak tworzysz plany swojego domu. Można wszystko przemyśleć i narysować: gdzie będzie kuchnia, sypialnie, salon. Ale to wszystko na papierze iw układach.
Podczas modelowania fizycznego tworzysz model, który jest zoptymalizowany pod kątem konkretnej aplikacji i DBMS. To właśnie ten model jest wdrażany w praktyce. Jeśli wrócisz do domu z poprzedniego akapitu, na tym etapie będziesz musiał gdzieś zbudować dom - nosić kłody, cegły ...

Proces projektowania bazy danych składa się z następujących kroków:

• kolekcja informacji;
• definicja podmiotów;
• definiowanie atrybutów dla każdej jednostki;
• definiowanie relacji między podmiotami;
• normalizacja;
• transformacja do modelu fizycznego;
• tworzenie bazy danych.

Pierwsze 5 etapów tworzy fazę projektowania logicznego, a pozostałe dwa tworzą fazę modelowania fizycznego.

Faza logiczna

Faza logiczna składa się z kilku etapów. Wszystkie są omówione poniżej.

Zbieranie wymagań

Na tym etapie musisz dokładnie określić, w jaki sposób baza danych będzie używana i jakie informacje będą w niej przechowywane. Zbierz jak najwięcej informacji o tym, co system powinien, a czego nie powinien robić.

Definiowanie jednostek

Na tym etapie musisz zdefiniować encje, które będą tworzyć bazę danych.

Encja to obiekt w bazie danych, który przechowuje dane. Podmiotem może być coś namacalnego (dom, osoba, obiekt, miejsce) lub abstrakcyjne (bankowość, dział firmy, trasa autobusu). W modelu fizycznym jednostka nazywana jest tabelą.

Encje składają się z atrybutów (kolumn tabeli) i rekordów (wierszy w tabeli).

Zazwyczaj bazy danych składają się z kilku encji głównych, powiązanych z dużą liczbą encji podrzędnych. Podstawowe byty nazywane są niezależnymi: nie zależą od żadnego innego bytu. Jednostki podrzędne nazywane są zależnymi: aby jeden z nich istniał, musi być z nim powiązana tabela nadrzędna.
Encje są zwykle przedstawiane na wykresach jako prostokąty. Nazwa jednostki jest wskazana w prostokącie:

Każda tabela ma następujące cechy:

• nie ma w nim identycznych linii;
• wszystkie kolumny (atrybuty) w tabeli muszą mieć różne nazwy;
• elementy w obrębie jednej kolumny mają ten sam typ (string, number, date);
• kolejność wierszy w tabeli może być dowolna.

Na tym etapie należy zidentyfikować wszystkie kategorie informacji (podmiotów), które będą przechowywane w bazie danych.

Definiowanie atrybutów

Atrybut reprezentuje właściwość, która opisuje jednostkę. Atrybuty to często liczba, data lub tekst. Wszystkie dane przechowywane w atrybucie muszą być tego samego typu i mieć te same właściwości.
W modelu fizycznym atrybuty nazywane są kolumnami.
Po zdefiniowaniu encji musisz zdefiniować wszystkie atrybuty tych encji.
Na wykresach atrybuty są zwykle wymienione w prostokącie encji. Na rysunku znajdziesz przykład bazy „Home”, dopiero teraz zdefiniowano niektóre atrybuty dla podmiotów z tej bazy.


Dla każdego atrybutu zdefiniowany jest typ danych, ich rozmiar, dozwolone wartości oraz wszelkie inne reguły. Należą do nich zasady obowiązkowego wypełniania, zmienności i niepowtarzalności.
Obowiązkowa reguła określa, czy atrybut jest wymaganą częścią encji. Jeśli atrybut jest opcjonalną częścią encji, może przyjąć wartość NULL, w przeciwnym razie nie może.
Ponadto musisz określić, czy atrybut jest zmienny. Niektóre wartości atrybutów nie mogą się zmienić po utworzeniu rekordu.
Na koniec musisz określić, czy atrybut jest unikalny. Jeśli tak, to wartości atrybutów nie mogą się powtarzać.

Klucze

Klucz to zestaw atrybutów, które jednoznacznie identyfikują rekord. Klucze dzielą się na dwie klasy: proste i złożone.
Prosty klucz składa się tylko z jednego atrybutu. Na przykład w bazie danych „Paszporty obywateli kraju” numer paszportu będzie prostym kluczem: nie ma dwóch paszportów o tym samym numerze.
Klucz złożony składa się z kilku atrybutów. W tej samej bazie „Paszporty obywateli kraju” może znajdować się klucz złożony o następujących atrybutach:
nazwisko, imię, nazwisko patronimiczne, data urodzenia. To przykład, ponieważ ten klucz złożony teoretycznie nie gwarantuje unikalności zapisu.
Istnieje również kilka rodzajów kluczy, które zostały opisane poniżej.

Możliwy klucz

Możliwy klucz to dowolny zestaw atrybutów, które jednoznacznie identyfikują wpis w tabeli. Możliwy klucz może być prosty lub złożony.
Każda jednostka musi mieć co najmniej jeden możliwy klucz, chociaż może być kilka takich kluczy. Żaden z atrybutów klucza podstawowego nie może mieć wartości NULL.
Możliwy klucz jest również nazywany kluczem zastępczym.

Klucze podstawowe

Klucz podstawowy to zestaw atrybutów, które jednoznacznie identyfikują rekord w tabeli (jednostkę). Jeden z możliwych kluczy staje się kluczem podstawowym. Na diagramach klucze podstawowe są często przedstawiane nad główną listą atrybutów lub wyróżnione znakami specjalnymi. Jednostka na rysunku ma zarówno kluczowe, jak i wspólne atrybuty.

Klawisze alternatywne

Każdy możliwy klucz inny niż podstawowy jest nazywany kluczem alternatywnym. Jednostka może mieć wiele kluczy alternatywnych.

Klucz obcy

Klucz obcy to zbiór atrybutów, które odwołują się do klucza podstawowego lub alternatywnego innej jednostki. Jeśli klucz obcy nie jest skojarzony z jednostką podstawową, może zawierać tylko wartości null. Jeśli klucz jest złożony, wszystkie atrybuty klucza obcego muszą być niezdefiniowane.
Na wykresach atrybuty połączone w klucze obce są oznaczone znakami specjalnymi. Rysunek przedstawia dwa powiązane podmioty (Domy i ich Nadrzędnych) oraz utworzone przez nie klucze obce (w końcu jedna osoba może posiadać więcej niż jeden dom).

Klucze to konstrukcje logiczne, a nie obiekty fizyczne. Relacyjne bazy danych zapewniają mechanizmy przechowywania kluczy.

Definiowanie relacji między podmiotami

Relacyjne bazy danych pozwalają na łączenie informacji należących do różnych podmiotów.
Relacja to sytuacja, w której jedna encja odwołuje się do klucza podstawowego drugiej encji. Jak na przykład encje House i Master na poprzednim rysunku.
Relacje są definiowane podczas procesu projektowania bazowego. Aby to zrobić, powinieneś przeanalizować jednostki i zidentyfikować logiczne powiązania, które istnieją między nimi.
Typ relacji określa liczbę rekordów encji powiązanych z innym rekordem encji. Relacje dzielą się na trzy główne typy, które opisano poniżej.

Jeden na jednego

Każdy rekord pierwszej encji odpowiada tylko jednemu rekordowi z drugiej encji. A każdy rekord drugiej encji odpowiada tylko jednemu rekordowi z pierwszej encji. Na przykład istnieją dwie jednostki: ludzie i akty urodzenia. A jedna osoba może mieć tylko jeden akt urodzenia.

Jeden za dużo

Każdy rekord pierwszej encji może odpowiadać kilku rekordom z drugiej encji. Jednak każdy rekord drugiej jednostki odpowiada tylko jednemu rekordowi z pierwszej jednostki. Na przykład istnieją dwie encje: Zamówienie i Pozycja zamówienia. A w jednym zamówieniu może być wiele pozycji.

Wiele do wielu

Każdy rekord pierwszej encji może odpowiadać kilku rekordom z drugiej encji. Jednak każdy rekord drugiej encji może odpowiadać kilku rekordom z pierwszej encji. Na przykład istnieją dwie jednostki: Autor i Książka. Jeden autor może napisać wiele książek. Ale książka może mieć wielu autorów.
Zgodnie z kryterium obowiązku relacje dzielą się na obligatoryjne i fakultatywne.

• Relacja obowiązkowa oznacza, że ​​dla każdego rekordu z pierwszej encji muszą istnieć skojarzone rekordy w drugiej encji.
• Relacja opcjonalna oznacza, że ​​dla rekordu z pierwszej encji może nie być rekordu w drugiej encji.

Normalizacja

Normalizacja to proces usuwania nadmiarowych danych z bazy danych. Każda pozycja danych powinna być przechowywana w bazie danych w jednym i tylko jednym egzemplarzu. Istnieje pięć powszechnych form normalizacji. Zazwyczaj baza danych jest redukowana do trzeciej postaci normalnej.
Podczas procesu normalizacji podejmowane są pewne działania w celu usunięcia zbędnych danych. Normalizacja poprawia wydajność, przyspiesza sortowanie i budowanie indeksów, zmniejsza liczbę indeksów na jednostkę oraz przyspiesza wstawianie i aktualizowanie.
Znormalizowana baza danych jest zwykle bardziej elastyczna. Kiedy modyfikujesz zapytania lub dane przechowywane w znormalizowanej bazie danych, zwykle musisz wprowadzać mniej zmian i wprowadzać zmiany, które mają mniejsze konsekwencje.

Pierwsza postać normalna

Aby przekonwertować jednostkę do pierwszej normalnej postaci, należy wyeliminować zduplikowane grupy wartości i upewnić się, że każdy atrybut zawiera tylko jedną wartość; listy wartości są niedozwolone.
Innymi słowy, każdy atrybut w encji powinien być przechowywany tylko w jednej instancji.
Na przykład na rysunku encja Dom nie jest znormalizowana. Zawiera kilka atrybutów do przechowywania danych o właścicielach domu (obiekt Dom nie odpowiada pierwszej normalnej formie).

Aby doprowadzić encję House do jej pierwszej normalnej postaci, konieczne jest usunięcie zduplikowanych grup wartości, czyli usunięcie atrybutów Owner 1-3, umieszczając je w osobnej encji. Wynik (dom jednostki zredukowany do pierwszej normalnej formy):

Druga postać normalna

Tabela w drugiej postaci normalnej zawiera tylko dane, które są dla niej istotne. Wartości niekluczowych atrybutów encji zależą od klucza podstawowego. Mówiąc dokładniej, atrybuty zależą od klucza podstawowego, całego klucza podstawowego i tylko od klucza podstawowego.
Encje muszą mieć pierwszą postać normalną, aby mieć drugą postać normalną.
Na przykład encja Dom na obrazku ma atrybut Cena litra benzyny, który nie ma nic wspólnego z domami. Ten atrybut został usunięty (lub możesz go przenieść do innej jednostki). A także przenosimy atrybut Burmistrz do oddzielnej jednostki - ten atrybut zależy od miasta, w którym znajduje się dom, a nie od domu.
Rysunek przedstawia obiekt House w drugiej postaci normalnej (obiekt House zredukowany do drugiej postaci normalnej).

Trzecia postać normalna

Trzecia postać normalna wyklucza atrybuty, które są niezależne od całego klucza. Każdy byt, który jest w trzeciej formie normalnej, jest również w drugiej. Jest to najczęstsza forma bazy danych.
W trzeciej normalnej postaci każdy atrybut zależy od klucza, od całego klucza i tylko od klucza.
Na przykład encja Gospodarz na rysunku posiada atrybut Znak zodiaku, który zależy od daty urodzenia właściciela domu, a nie od jego imienia (które jest kluczem).
Aby rzucić encję Gospodarz, musisz stworzyć encję Znaki Zodiaku i przenieść tam atrybut Znak Zodiaku (encja Gospodarz domu, zredukowana do trzeciej normalnej postaci):

Ograniczenia

Ograniczenia to reguły, które wymusza system zarządzania bazą danych. Ograniczenia definiują zestaw wartości, które można wprowadzić do kolumny lub kolumn.
Na przykład nie chcesz, aby kwota zamówienia w Twoim bardzo fajnym sklepie była mniejsza niż 500 rubli. Po prostu ustawiasz limit w kolumnie Kwota zamówienia.

Procedury składowane

Procedury składowane to prekompilowane procedury, które są przechowywane w bazie danych. Procedury składowane mogą służyć do definiowania reguł biznesowych i mogą wykonywać bardziej złożone obliczenia niż same ograniczenia.
Procedury składowane mogą zawierać logikę wykonywania programu, a także zapytania do bazy danych. Mogą przyjmować parametry i zwracać wyniki w postaci tabel lub pojedynczych wartości.
Procedury składowane są jak zwykłe procedury lub funkcje w dowolnym programie.

NOTATKA
Procedury składowane znajdują się w bazie danych i są wykonywane na serwerze bazy danych. Są one na ogół szybsze niż instrukcje SQL, ponieważ są przechowywane w postaci skompilowanej.

Integralność danych

Organizując dane w tabele i definiując relacje między nimi, możesz założyć, że stworzyłeś model, który poprawnie odzwierciedla środowisko biznesowe. Teraz musimy zadbać o to, aby dane wprowadzone do bazy dawały poprawny obraz stanu rzeczy. Innymi słowy, musisz wymusić reguły biznesowe i zachować integralność bazy danych.
Na przykład Twoja firma dostarcza książki. Jest mało prawdopodobne, że przyjmiesz zamówienie od nieznanego klienta, ponieważ wtedy nawet nie będziesz w stanie dostarczyć zamówienia. Stąd zasada biznesowa: zamówienia przyjmowane są tylko od klientów, których informacje znajdują się w bazie danych.
Poprawność danych w relacyjnych bazach danych zapewnia zbiór reguł. Reguły integralności danych dzielą się na cztery kategorie.

• Integralność podmiotów- każdy rekord podmiotu musi posiadać unikalny identyfikator i zawierać dane. W końcu musisz jakoś rozróżnić wszystkie te rekordy w bazie danych.
• Integralność atrybutów- każdy atrybut akceptuje tylko prawidłowe wartości. Na przykład kwota zakupu zdecydowanie nie może być mniejsza niż zero.
• Więzy integralności- zestaw reguł, które zapewniają logiczną spójność kluczy podstawowych i obcych podczas wstawiania, aktualizowania i usuwania rekordów. Integralność referencyjna zapewnia, że ​​dla każdego klucza obcego istnieje odpowiedni klucz podstawowy. Weźmy poprzedni przykład z encjami Właściciel domu i Dom. Powiedzmy, że jesteś Vasyą Ivanov i jesteś właścicielem domu. Zmieniłeś swoje nazwisko na Sidorov i dokonałeś odpowiednich zmian w podmiocie właściciela domu. Zdecydowanie chciałbyś, aby twój dom był nadal wymieniony pod twoim nowym nazwiskiem, a nie należał do niejakiego Wasi Iwanowa, którego już nie ma.
• Niestandardowe zasady integralności- wszelkie zasady integralności, które nie należą do żadnej z wymienionych kategorii.

Wyzwalacze

Cyngiel jest odpowiednikiem procedury składowanej, która jest wywoływana automatycznie po zmianie danych w tabeli.
Wyzwalacze to potężny mechanizm utrzymywania integralności bazy danych. Wyzwalacze są wywoływane przed lub po zmianach danych w tabeli.
Za pomocą wyzwalaczy możesz nie tylko cofnąć te zmiany, ale także zmienić dane w dowolnej innej tabeli.
Na przykład tworzysz forum internetowe i musisz upewnić się, że ostatni post na forum pojawia się na liście forum. Oczywiście możesz wziąć post z encji Forum Post, ale zwiększy to złożoność Twojej prośby i czas potrzebny na jej ukończenie. Łatwiej jest dodać wyzwalacz do encji Forum Messages, który zapisze ostatnio dodaną wiadomość do encji Forum w atrybucie Last Message. To znacznie uprości zapytanie.

Zasady biznesowe

Reguły biznesowe definiują ograniczenia danych w celu spełnienia wymagań biznesowych (tych, dla których tworzysz bazę danych). Reguły biznesowe mogą składać się z zestawu kroków wymaganych do wykonania określonego zadania lub mogą być po prostu sprawdzeniami, które zapewniają poprawność wprowadzonych danych. Reguły biznesowe mogą obejmować reguły integralności danych. W przeciwieństwie do innych zasad, ich głównym celem jest zapewnienie prawidłowego prowadzenia biznesu.
Np. w firmie „Very Tough Guys” może być tak przyjęte, że na oficjalne potrzeby kupuje się tylko białe, niebieskie i czarne auta.
Następnie reguła biznesowa dla atrybutu Kolor samochodu jednostki Entity Service Vehicles będzie stwierdzać, że samochód może być tylko biały, niebieski lub czarny.
Większość DBMS zapewnia środki:

• określić wartości domyślne;
• sprawdzenie danych przed wprowadzeniem ich do bazy danych;
• utrzymywać relacje między tabelami;
• zapewnić niepowtarzalność wartości;
• do przechowywania procedur składowanych bezpośrednio w bazie danych.

Wszystkie te możliwości można wykorzystać do wymuszenia reguł biznesowych w bazie danych.

Model fizyczny

Kolejnym krokiem, po stworzeniu modelu logicznego, jest zbudowanie modelu fizycznego. Model fizyczny to praktyczna implementacja bazy danych. Model fizyczny definiuje wszystkie obiekty, które musisz zaimplementować.
Podczas przechodzenia z modelu logicznego do fizycznego jednostki są konwertowane na tabele, a atrybuty na kolumny.
Relacje między jednostkami można przekonwertować na tabele lub pozostawić jako klucze obce.
Klucze podstawowe są konwertowane na ograniczenia klucza podstawowego. Możliwe klucze mają unikalne ograniczenia.

Denormalizacja

Denormalizacja- jest to celowa zmiana struktury bazy, która narusza zasady normalnych form. Zwykle ma to na celu poprawę wydajności bazy danych.
Teoretycznie należy zawsze dążyć do w pełni znormalizowanej linii bazowej, ale w praktyce całkowita normalizacja linii bazowej prawie zawsze oznacza spadek wydajności. Nadmierna normalizacja bazy danych może skutkować dostępem do wielu tabel za każdym razem, gdy dane są pobierane. Zazwyczaj w zapytaniu muszą być zaangażowane cztery lub mniej tabele.
Typowe techniki denormalizacji obejmują łączenie wielu tabel w jedną, przechowywanie tych samych atrybutów w wielu tabelach oraz przechowywanie podsumowań lub danych obliczeniowych w tabeli.

3. Komponenty modelu danych

Podmiot, definicja podmiotu, źródła informacji podmiotu

Model danych to pojęciowy opis dziedziny - najbardziej abstrakcyjny poziom projektowania bazy danych. Model danych składa się z jednostek, atrybutów, domen i relacji. Dalej - o każdym z elementów szczegółowo.

3.1 Podmioty

Encja to coś, o czym informacje muszą być przechowywane w bazie danych.

Projektując bazy danych wystarczy opisać obecną sytuację – a większość rzeczowników i niektóre czasowniki będą kandydatami na byty. Na przykład: „Klienci kupują produkty. Pracownicy sprzedają produkty klientom. Dostawcy dostarczają produkty” — klienci, produkty, pracownicy i dostawcy to podmioty. Czasowniki „kupować” i „sprzedawać” również są bytami (choć mogą to być ten sam byt, różny z punktu widzenia kupującego i sprzedającego).

Podczas projektowania bazy danych głównym źródłem informacji o podmiotach jest rozmowa z klientem w celu zrozumienia jego procesów biznesowych. Dodatkowo analizowane są standardowe dokumenty wykorzystywane w procesach biznesowych: formularze, raporty, instrukcje itp. Po otrzymaniu takiej listy należy ją sprawdzić pod kątem kompletności i spójności, a także zidentyfikować duplikaty – te same byty, które nazywamy różnymi słowami, oraz byty faktycznie różne, ale opisywane tym samym terminem.

Podmioty mogą modelować koncepcje konkretne (klienci, towary, rozmowy) i abstrakcyjne (za klienta odpowiada agent, student jest zapisywany na kurs).

Podstawowe pojęcia modelu bazy danych "podmiot - relacja" (model ER): encje, relacje między nimi i ich atrybuty (właściwości).

Esencja- dowolny konkretny lub abstrakcyjny przedmiot w rozważanym obszarze tematycznym. Encje to podstawowe typy informacji, które są przechowywane w bazie danych (tabela jest przypisana do każdej jednostki w relacyjnej bazie danych). Podmioty mogą obejmować: studentów, klientów, działy itp. Wystąpienie jednostki i typ jednostki to różne koncepcje. Typ Entity odnosi się do zbioru jednorodnych osób, obiektów lub zdarzeń, które działają jako całość (np. uczeń, klient itp.). Instancja encji odnosi się na przykład do konkretnej osoby w zestawie. Typ jednostki może być studentem, a instancją może być Petrov, Sidorov itp.

Atrybut Jest własnością podmiotu w przedmiotowym obszarze. Jego nazwa musi być unikalna dla określonego typu jednostki. Na przykład następujące atrybuty mogą być użyte dla jednostki studenta: nazwisko, imię, patronimik, data i miejsce urodzenia, dane paszportowe itp. W relacyjnej bazie danych atrybuty są przechowywane w polach tabeli.

Połączenie- relacje między podmiotami w przedmiotowym obszarze. Relacje to połączenia pomiędzy częściami bazy danych (w relacyjnej bazie danych jest to połączenie pomiędzy rekordami tabeli).

Podmioty Czy dane są klasyfikowane według typu, a relacje pokazują, w jaki sposób te typy danych są ze sobą powiązane. Jeśli określimy pewien obszar tematyczny w kategoriach encji – relacji, to otrzymamy encję – model relacji dla tej bazy danych.

strzałka jest skrótem relacji jeden-do-wielu.

Główne zalety modeli ER: * przejrzystość; * modele pozwalają na projektowanie baz danych z dużą liczbą obiektów i atrybutów;

Główne elementy modeli ER: * obiekty (byty); * atrybuty obiektów; * połączenia między obiektami.

Relację między podmiotami charakteryzuje: * rodzaj relacji (1:1, 1:N, N:M); * klasa przynależności. Klasa może być wymagana lub opcjonalna. Jeśli każde wystąpienie jednostki uczestniczy w relacji, klasa członkostwa jest wymagana, w przeciwnym razie jest opcjonalna.

Koncepcja normalizacji danych. Zależność funkcjonalna.

Normalizacja to formalna metoda analizy relacji na podstawie ich klucza podstawowego i istniejących relacji. Jego zadaniem jest zastąpienie jednego schematu (lub zestawu relacji) bazy danych innym schematem, w którym relacje mają prostszą i bardziej regularną strukturę.

Zależność funkcjonalna. Niech X i Y będą dwoma atrybutami jakiejś relacji. Mówi się, że Y funkcjonalnie zależy od X, jeśli w danym momencie każda wartość X odpowiada co najwyżej jednej wartości atrybutu Y.

Zależność funkcjonalną oznaczono jako X -> Y.

Postawa studencka S (Ns, Fio, Ngr, Addr, Tel). Każdy z atrybutów Fio, Ngr, Addr, Tel jest funkcjonalnie zależny od atrybutu Ns.

Tak więc w znormalizowanej relacji wszystkie atrybuty niekluczowe funkcjonalnie zależą od klucza relacji. Kluczem relacji S jest atrybut Ns.