Wywoływana jest liczba jednostek po każdej stronie połączenia. Model danych związek-jednostka. Lista kontrolna atrybutów pytań

Jednym z najpopularniejszych sposobów sformalizowanej reprezentacji obszaru tematycznego systemów zorientowanych na przetwarzanie informacji faktycznych jest model „jednostka - komunikacja”, który leży u podstaw znacznej liczby komercyjnych produktów CASE, które wspierają pełny cykl rozwoju systemów baz danych lub jego poszczególnych etapów. Jednocześnie wiele z nich obsługuje nie tylko etap projektowania koncepcyjnego obszaru tematycznego opracowanego systemu, ale także pozwala na przeprowadzenie logicznego etapu projektowania na podstawie modelu zbudowanego za ich pomocą poprzez automatyczne generowanie schematu koncepcyjnej bazy danych dla wybranego DBMS, na przykład schematu bazy danych dla dowolnego SQL -server lub obiekt DBMS.

Modelowanie obszaru tematycznego w tym przypadku opiera się na wykorzystaniu graficznych wykresów, które zawierają stosunkowo niewielką liczbę składników, a co najważniejsze - technologia budowlanatakie diagramy.

Podstawą semantyczną modelu ER są następujące założenia:

ta część świata rzeczywistego (zestaw połączonych ze sobą obiektów), informacje, które powinny być umieszczone w bazie danych, mogą być przedstawiony jakocałość podmioty;

każdy byt ma charakterystyczne właściwości (atrybuty), które odróżniają go od innych bytów i pozwalają na to do identyfikacji;

jednostki można klasyfikować według typu jednostki: do każdej instancji jednostki (reprezentującej obiekt) można przypisać doklasa - rodzaj podmiotówkażde wystąpienie ma wspólne dla nich właściwości i odróżnia je od esencji innych klas;

systematyzacja reprezentacji oparta na klasach zasadniczo zakłada hierarchiczną zależność typów: byt typu I jest podtyppodmioty W,jeśli każde wystąpienie typu I jest instancją typu typu W;

relacje między obiektami można przedstawić jako jednostki komunikacyjnektóre służą do naprawy (reprezentowania) współzależności dwóch lub więcej podmiotów.

W tym miejscu powinniśmy jeszcze raz podkreślić informacyjny charakter koncepcji istotai jego związek z materialnymi lub urojonymi przedmiotami z obszaru tematycznego. Każdy obiekt w domenie ma właściwości, z których niektóre wyróżniają się jako charakterystyczne - istotne z punktu widzenia zastosowanego problemu. W tym przypadku na przykład w procesie analizy i systematyzacji obszaru tematycznego zwykle wyróżnia się zajęcia -kolekcje obiektów, które mają ten sam zestaw właściwości zdefiniowanych w formularzu zestawy atrybutów(wartości atrybutów dla obiektów tej samej klasy mogą się oczywiście różnić). Odpowiednio, na poziomie reprezentacji obszaru tematycznego (tj. Jego modelu infologicznego), przedmiot uważany za pojęcie (obiekt w ludzkim umyśle) odpowiada pojęciu istota;przedmiot, jako część świata materialnego (i istniejący niezależnie od ludzkiej świadomości), odpowiada koncepcji instancja encji;klasa obiektów odpowiada koncepcji typ encji.

W przyszłości, ponieważ model infologiczny nie uwzględnia oddzielnych instancji obiektów, ale klasy, nie będziemy rozróżniać odpowiadających sobie pojęć tych dwóch poziomów, tj. Przyjmiemy tożsamość pojęć obiekti jednostka, właściwość obiektui własność podmiotu.

Model ERjako opis obszaru tematycznego musi określać obiekty i relacje między nimi, to znaczy ustanawiać połączenia dwóch następujących typów.

1. Zależność między obiektami a zbiorami charakterystycznych właściwości, a tym samym określają same obiekty.

2. Połączenia między obiektami, które określają naturę i funkcjonalny charakter ich współzależności.

Jak wspomniano wcześniej, modelowanie ER w domenie domenowej opiera się na wykorzystaniu diagramów graficznych jako prostego (znanego), wizualnego, a jednocześnie informacyjnego i wieloaspektowego sposobu wyświetlania komponentów projektu. Dlatego też stwierdzenie głównych przepisów modelu ER zostanie zilustrowane materiałem przykładu schematu ER pokazanego na ryc. 5.4

Istota.Obiekt, z którym modelowana jest klasa obiektów tego samego typu, jest definiowany jako „obiekt, który można jednoznacznie zidentyfikować”. Tak jak każdy obiekt jest jednoznacznie charakteryzowany przez zestaw wartości właściwości, tak byt musi być zdeterminowanymwięc zestaw atrybutówktóre pozwoliłyby na rozróżnienie poszczególnych wystąpień bytu. Każda instancja encji musi być odróżnialna od każdej innej instancji tej samej encji (wymaganie to jest podobne do wymogu, aby w tabelach relacyjnych nie było duplikatów krotek). Na przykład, aby jednoznacznie zidentyfikować każde wystąpienie jednostki „Pracownik”, wprowadzono atrybut „Numer personelu”, który ze względu na swój charakter zawsze będzie miał unikalne znaczenie w ramach przedsiębiorstwa. Oznacza to, że unikalny identyfikator jednostki może być atrybutem, kombinacją atrybutów, kombinacją relacji lub kombinacją relacji i atrybutów, która jednoznacznie odróżnia dowolne wystąpienie bytu od innych wystąpień bytu tego samego typu.

Esencja ma imię,unikalny w modelu. W którym nazwa jednostki -to wpisz imięnie konkretna instancja.

Podmioty są podzielone na silnyi słaby.Istota jest słaba, jeśli jej istnienie zależy od innej istoty silnej w stosunku do węzłów. Na przykład jednostka podrzędna jest słaba w stosunku do dopodmioty „Pracownik”: jeżeli rekord odpowiadający niektórym pracownikom mającym podwładnych zostanie usunięty, informacje o podporządkowaniu również muszą zostać usunięte.

NieruchomościWłaściwości natury jak charakter komunikacjiwłaściwości z jednostką (obiektem) mogą być różne. Rozważ główne typy właściwości.

Właściwość może być liczba mnogalub pojedynczy -tzn. atrybut definiujący właściwość może mieć jednocześnie kilka wartości lub odpowiednio tylko jedną. Na przykład pracownik może mieć kilka specjalizacji, ale jedyną wartością jest Numer Personalny.

Właściwość może być prosty(nie podlega dalszemu podziałowi pod względem zastosowanych zadań) lub kompozyt -jeśli jego wartość składa się z wartości prostych właściwości. Na przykład właściwość „Rok urodzenia” jest prosta, a właściwość „Adres” jest złożona, ponieważ obejmuje wartości prostych właściwości „Miasto”, „Ulica”, „Dom”.

W niektórych przypadkach warto rozróżnić podstawowyi pochodnenieruchomości. Na przykład „Dostawca” może mieć właściwość „Całkowita liczba dostarczonych części”, która jest obliczana poprzez zsumowanie liczby dostarczonych przez niego części w ramach projektu.

Jeśli obecność jakiejś właściwości dla wszystkich instancji jednostki jest opcjonalna, wówczas taka właściwość jest wywoływana warunkowy.Na przykład nie wszyscy pracownicy mają własność „stopnia naukowego”.

Wartości właściwości mogą być stałe - statycznylub dynamicznytj. zmiana w czasie. Na przykład właściwość Numer personelu jest statyczna, a adres dynamiczny. Właściwość może być niejasnyjeśli jest dynamiczny, ale jego bieżąca wartość nie została jeszcze ustawiona.

Właściwość można uznać za kluczjeżeli jego znaczenie jest unikalne i być może w pewnym kontekście jednoznacznie identyfikuje byt. Na przykład podwładny określonego pracownika.

Komunikacja.Oprócz relacji między obiektem i jego właściwościami model infologiczny odzwierciedla relacje między obiektami różnych klas. W połączeniezdefiniowane jako „powiązanie kilku podmiotów”. Powiązanie to może zawsze istnieć między różnymi podmiotami lub między bytem a samym sobą (relacja rekurencyjna).

Podobnie jak istota, komunikacja jest typowykoncepcja, tj. wszystkie instancje powiązanych obiektów są zgodne z regułami wiązania typu. Zasadę różnic w typach relacji między typami i instancjami ilustrują diagramy ER dla typów i instancji pokazanych na ryc. 5.5

Jednostki połączone przez połączenie są wywoływane uczestnicy. Stopień komunikacjizależy od liczby uczestników komunikacji.

Jeśli każda instancja jednostki uczestniczy w co najmniej jednej instancji relacji, wówczas taki udział tej jednostki jest wywoływany kompletny(lub obowiązkowy);inaczej - niekompletny(lub opcjonalny).

Określono ilościowy charakter udziału instancji encji (jednej lub wielu) rodzaj komunikacji(lub moc komunikacji)Możliwe są następujące typy: "Jeden na jednego"(1:1), Jeden za dużo(1 mln), Wiele do jednego(M: 1) Wiele do wielu(M: M).

Należy zauważyć, że narzędzie komunikacji jest środkiem prezentacji złożone obiektyz których każdy może być traktowany jako zestaw w pewien sposób wzajemnie połączony proste przedmioty.Podział na proste i złożone obiekty, a także charakter relacji, jest warunkowy i determinowany jest przez cechy analizy przedmiotowego obszaru, to jest w końcu charakter wykorzystania tych obiektów w rozwiązanych zastosowanych problemach. Co więcej, z punktu widzenia na przykład projektanta, SZCZEGÓŁ jest przedmiotem złożonym, a z punktu widzenia dostawcy jest prosty.

Wśród wielu odmian związków najczęstsze są relacje hierarchiczne, takie jak „część - całość”, „rodzaj - gatunek”.

Relacja część-całość służy do przedstawienia obiekty złożone.Na przykład MASZYNY składają się z WĘZŁÓW, WĘZŁY składają się Z CZĘŚCI. Możliwe tutaj jako związek Jeden za dużotak „Wiele do wielu”.

Relacja „rodzaj - gatunek” - reprezentować obiekty uogólnione. Na przykład, PRACOWNICY są podzieleni według zawodu na PROJEKTANTÓW, PROGRAMATORÓW, PRACOWNIKÓW; PROGRAMATORZY - o PROGRAMOWANIACH APLIKACYJNYCH i PROGRAMATORACH SYSTEMU. Relacje hierarchiczne, a zwłaszcza relacje „klan-gatunek”, są zwykle wykorzystywane jako podstawa do klasyfikowania obiektów według zbiorów charakterystycznych cech. Ponadto obiekty „gatunkowe” dziedziczyćwłaściwości „ogólnego”.

Innym szeroko stosowanym rodzajem połączeń jest agregacja - połączenie prostych obiektów w złożone według zasady ich przynależności agregatlub ich wspólny udział w jakimś procesie. Agregacja, uważana tutaj za bardziej ogólny przypadek relacji hierarchicznych, łączy obiekty o różnym charakterze z jedną wspólną własnością „wspólny udział”. Zagregowane obiekty są zwykle nazywane rzeczownikami werbalnymi, na przykład "Struktura":PODDZIAŁ składa się zPRACOWNIKÓW; "Dostawa":DOSTAWCA kieszonkowe dzieciDETALE.

Nadtypy i podtypy.Element można podzielić na dwa lub więcej wykluczających się wzajemnie podtypyz których każdy zawiera wspólne atrybuty i / lub relacje. Te wspólne atrybuty i / lub relacje są jednoznacznie zdefiniowane raz na wyższym poziomie. Podtypy mogą definiować własne atrybuty i / lub relacje. Zasadniczo alokacja podtypów może być kontynuowana na niższych poziomach, ale w większości przypadków wystarczą dwa lub trzy poziomy.

Nazywa się byt, na podstawie którego określa się podtypy nadtyp.Podtypy muszą tworzyć kompletny zestaw, tzn. Każda instancja nadtypu musi należeć do określonego podtypu. Czasami dla kompletności zestawu konieczne jest zdefiniowanie dodatkowego podtypu, na przykład INNE.

Podtyp dziedziczy właściwości i relacje nadtypu. Na przykład typ jednostki PROGRAMISTAjest podtypem jednostki PRACOWNIK.Programiści mają wszystkie właściwości pracowników i uczestniczą we wszystkich relacjach, ale odwrotność nie jest prawdą.

Rodzaj jednostki, jej podtypy, podtypy tych podtypów itp. Tworzą hierarchia typów jednostek,którego przykład pokazano na ryc. 5,6

W rzeczywistym projekcie struktury bazy danych stosowana jest metoda - tzw modelowanie semantyczne. Modelowanie semantyczne to modelowanie struktury danych oparte na znaczeniu tych danych. Różne opcje są wykorzystywane jako narzędzie do modelowania semantycznego. diagramy relacji między bytami(ER - związek podmiotu).

Pierwsza wersja modelu relacji z bytem została zaproponowana w 1976 roku przez Petera Pin-Sheng Chena. W przyszłości wielu autorów opracowało własne wersje takich modeli (notacja Martina, notacja IDEF1X, notacja Barkera itp.). Również różne oprogramowanieimplementujące tę samą notację mogą różnić się pod względem możliwości. W rzeczywistości wszystkie warianty diagramów relacji między bytami pochodzą z jednego pomysłu - obraz jest zawsze bardziej wizualny niż opis tekstowy. Wszystkie takie diagramy używają graficznego obrazu bytów obszaru tematycznego, ich właściwości (atrybutów) i relacji między bytami.

Opiszemy pracę z diagramami ER zbliżonymi do notacji Barkera, jako dość łatwe do zrozumienia głównych pomysłów. Ten rozdział jest bardziej ilustracją metod modelowania semantycznego niż pełnym wprowadzeniem do tego obszaru.

Koncepcje wykresów ER

Definicja 1: Istotato klasa obiektów tego samego typu, o której informacje należy wziąć pod uwagę w modelu.
Każda istota musi mieć nazwę wyrażoną pojedynczym rzeczownikiem. Przykładami podmiotów mogą być takie klasy obiektów, jak „Dostawca”, „Pracownik”, „Faktura”. Każdy element w modelu jest przedstawiony jako prostokąt o nazwie:

Figa. 1

Definicja 2: Instancja encji- To jest konkretny przedstawiciel tego podmiotu.
Na przykład przedstawicielem podmiotu „Pracownik” może być „Pracownik Iwanow”. Instancje encji muszą być rozróżnialne, tj. Encje muszą mieć pewne właściwości, które są unikalne dla każdego wystąpienia tej encji.

Definicja 3: Atrybut jednostkito nazwana cecha, która jest pewną właściwością bytu.
Nazwa atrybutu powinna być wyrażona w liczbie pojedynczej (być może z charakterystycznymi przymiotnikami). Przykładami atrybutów jednostki „Pracownik” mogą być takie atrybuty jak „Numer personelu”, „Nazwisko”, „Imię”, „Drugie imię”, „Pozycja”, „Wynagrodzenie” itp. Atrybuty są wyświetlane w prostokącie definiującym encję:

Figa. 2)

Definicja 4: Klucz jednostki- Jest to zbędny zestaw atrybutów, których wartości są kolektywnie unikalne dla każdego wystąpienia encji. Redundancja polega na tym, że usunięcie dowolnego atrybutu z klucza narusza jego wyjątkowość. Jednostka może mieć kilka różnych kluczy. Kluczowe atrybuty przedstawiono na schemacie, podkreślając:

Figa. 3)

Definicja 5: Komunikacja- To jakieś powiązanie między dwoma podmiotami. Jeden byt może być powiązany z innym bytem lub z samym sobą.
Relacje pozwalają jednemu podmiotowi znajdować inne powiązane z nim podmioty. Na przykład relacje między podmiotami można wyrazić następującymi zwrotami - „PRACODAWCA może mieć kilka DZIECI”, „każdy PRACOWNIK musi być wymieniony w dokładnie jednym DZIALE”. Relację graficznie przedstawia linia łącząca dwa podmioty:

Figa. 4

Każde połączenie ma dwa końce i jedną lub dwie nazwy. Nazwa jest zwykle wyrażona w czasowniku na czas nieokreślony: „mieć”, „należeć” itd. Każda pozycja odnosi się do końca połączenia. Czasami imiona nie są pisane z powodu ich oczywistości.

Każdy link może mieć jeden z poniższych rodzaje komunikacji:

Figa. 5

Rodzaj związku jeden na jednegooznacza, że \u200b\u200bjedno wystąpienie pierwszego bytu (po lewej) jest powiązane z jednym wystąpieniem drugiego bytu (po prawej). Relacja jeden do jednego najczęściej wskazuje, że w rzeczywistości mamy tylko jeden byt, niepoprawnie podzielony na dwa.

Rodzaj związku jeden za dużooznacza, że \u200b\u200bjedno wystąpienie pierwszego bytu (po lewej) jest powiązane z kilkoma wystąpieniami drugiego bytu (po prawej). Jest to najczęściej używany typ połączenia. Wywoływany jest lewy byt (od „jednej” strony) rodzic, prawo (od strony „wielu”) - pomocniczy. Typowy przykład takiego połączenia pokazano na ryc. 4

Rodzaj związku wiele do wieluoznacza, że \u200b\u200bkażda instancja pierwszej jednostki może być powiązana z kilkoma instancjami drugiej jednostki, a każda instancja drugiej jednostki może być powiązana z kilkoma instancjami pierwszej jednostki. Typ relacji wiele do wielu jest tymczasowym rodzajem połączenia akceptowalnym na wczesnych etapach rozwoju modelu. W przyszłości ten typ połączenia należy zastąpić dwoma relacjami jeden do wielu, tworząc jednostkę pośrednią.

Każdy link może mieć jeden z dwóch sposoby komunikacji:

Figa. 6

Modalność ” mogą”oznacza, że \u200b\u200bwystąpienie jednego podmiotu może być powiązane z jednym lub większą liczbą wystąpień innego podmiotu lub nie może być powiązane z żadnym wystąpieniem.
Modalność ” powinien”oznacza, że \u200b\u200bwystąpienie jednego podmiotu musi być powiązane z co najmniej jednym wystąpieniem innego podmiotu.
Komunikacja może mieć różną modalność z różnych końców (jak na ryc. 4). Opisana składnia graficzna umożliwia jednoznaczne czytanie diagramów przy użyciu następującego schematu budowy fraz:

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>

Każdy link można odczytać od lewej do prawej i od prawej do lewej. Połączenie na ryc. 4 brzmi następująco:

Od lewej do prawej: „każdy pracownik może mieć kilkoro dzieci”.
Od lewej do prawej: „Każde dziecko musi należeć do dokładnie jednego pracownika”.

Przykład opracowania prostego modelu ER

Opracowując modele ER, powinniśmy uzyskać następujące informacje na ten temat:

1. Lista podmiotów z obszaru tematycznego.
2. Lista atrybutów encji.
3. Opis relacji między podmiotami.

Diagramy ER są wygodne, ponieważ proces wyodrębniania jednostek, atrybutów i relacji jest iteracyjny. Po opracowaniu pierwszej przybliżonej wersji diagramów, udoskonalamy je poprzez przesłuchanie ekspertów domeny. Jednocześnie dokumentacją, w której zapisywane są wyniki rozmów, są same diagramy ER.

Załóżmy, że mamy do czynienia z zadaniem opracowania systemu informatycznego dla zamówienia jakiejś hurtowej firmy handlowej. Przede wszystkim musimy przestudiować przedmiot i procesy w nim zachodzące. W tym celu przeprowadzamy wywiady z pracownikami firmy, czytamy dokumentację, badamy formy zamówień, faktur itp.

Na przykład podczas rozmowy z kierownikiem sprzedaży okazało się, że on (kierownik) uważa, że \u200b\u200bzaprojektowany system powinien wykonać następujące działania:

• Przechowuj informacje o kliencie.
• Drukuj faktury za zwolnione towary.
• Monitoruj dostępność towarów w magazynie.

Wybieramy wszystkie rzeczowniki w tych zdaniach - będą to potencjalni kandydaci na byty i atrybuty, i analizujemy je (wyróżnimy niejasne terminy znakiem zapytania):

• Kupujący jest wyraźnym kandydatem na esencję.
• Faktura jest wyraźnym kandydatem dla podmiotu.
• Produkt - wyraźny kandydat na esencję
• (?) Magazyn - ogólnie ile magazynów ma firma? Jeśli kilku, będzie to kandydat na nowy byt.
• (?) Obecność produktu jest najprawdopodobniej atrybutem, ale jaki atrybut bytu?

Natychmiast istnieje oczywisty związek między podmiotami - „kupujący mogą kupować wiele towarów” i „towary mogą być sprzedawane wielu nabywcom”. Pierwsza wersja diagramu wygląda następująco:

Figa. 7

Zadając kierownikowi dodatkowe pytania, dowiedzieliśmy się, że firma ma kilka magazynów. Co więcej, każdy produkt może być przechowywany w kilku magazynach i sprzedawany z dowolnego magazynu.

Gdzie umieścić podmioty „Faktura” i „Magazyn” oraz z czym je połączyć? Zadajemy sobie pytanie, w jaki sposób podmioty te są ze sobą powiązane oraz podmioty „Kupujący” i „Produkt”? Kupujący kupują towary, jednocześnie otrzymując faktury, w których wprowadzane są dane dotyczące ilości i ceny zakupionych towarów. Każdy kupujący może otrzymać kilka faktur. Każda faktura musi być wystawiona na klienta. Każda faktura musi zawierać kilka produktów (nie ma pustych faktur). Z kolei każdy produkt można sprzedać kilku klientom za pomocą kilku faktur. Ponadto każda faktura musi być wystawiona z określonego magazynu, a wiele faktur można wystawić z dowolnego magazynu. Zatem po wyjaśnieniu schemat będzie wyglądał następująco:

Figa. 8

Czas pomyśleć o atrybutach bytu. Rozmawiając z pracownikami firmy, odkryliśmy, co następuje:

• Każdy kupujący jest osoba prawna i ma nazwę, adres, dane bankowe.
• Każdy produkt ma nazwę, cenę, a także charakteryzuje się jednostkami.
• Każda faktura ma unikalny numer, datę wystawienia, listę towarów z ilościami i cenami, a także całkowitą kwotę faktury. Faktura jest wystawiana z określonego magazynu i na konkretnego nabywcę.
• Każdy magazyn ma swoją nazwę.
• Ponownie wypisujemy wszystkie rzeczowniki, które będą potencjalnymi atrybutami, i analizujemy je:
• Osoba prawna to retoryczne pojęcie, nie współpracujemy z osobami fizycznymi. Nie zwracamy uwagi.
• Nazwa kupującego jest jasnym opisem kupującego.
• Adres - wyraźne wskazanie kupującego.
• Dane bankowe - jasny opis kupującego.
• Nazwa towarów jest wyraźną cechą towarów.
• (?) Cena produktu - wydaje się, że jest to cecha charakterystyczna produktu. Czy ta funkcja różni się od ceny na fakturze?
• Jednostka miary - wyraźna cecha towaru.
• Numer faktury jest wyraźną unikalną cechą faktury.
• Data faktury jest wyraźną cechą faktury.
• (?) Lista towarów na fakturze - lista nie może być atrybutem. Prawdopodobnie musisz wybrać tę listę jako oddzielny byt.
• (?) Ilość towarów na fakturze jest oczywistą cechą, ale cechą czego? Ta cecha to nie tylko „towary”, ale „towary na fakturze”.
• (?) Cena towaru na fakturze - znowu powinien to być nie tylko opis towaru, ale charakterystyka towaru na fakturze. Ale cena towaru już się spotkała - czy to to samo?
• Kwota faktury jest wyraźną cechą faktury. Ta cecha nie jest niezależna. Kwota faktury jest równa sumie kosztów wszystkich towarów uwzględnionych na fakturze.
• Nazwa magazynu jest wyraźną cechą magazynu.

W dodatkowej rozmowie z kierownikiem możliwe było wyjaśnienie różnych koncepcji cen. Okazało się, że każdy produkt ma pewną aktualną cenę. Jest to cena, po której produkt jest obecnie sprzedawany. Oczywiście cena ta może z czasem ulec zmianie. Cena tego samego produktu na różnych fakturach wystawianych w różnych momentach może być inna. Istnieją zatem dwie ceny - cena towaru na fakturze i aktualna cena towaru.

Dzięki pojawiającej się koncepcji „Listy towarów na fakturze” wszystko jest całkiem jasne. Podmioty „Faktura” i „Produkt” są ze sobą powiązane relacją wiele do wielu. Takie połączenie, jak zauważyliśmy wcześniej, powinno zostać podzielone na dwie relacje jeden do wielu. Wymaga to dodatkowego bytu. Podmiotem tym będzie podmiot „Lista towarów na fakturze”. Jego powiązanie z podmiotami „Faktura” i „Produkt” charakteryzuje się następującymi zwrotami: „każda faktura musi zawierać kilka wpisów z listy towarów na fakturze”, „każdy wpis z listy towarów na fakturze musi być zawarty w dokładnie jednej fakturze”, „każda pozycja może być zawarta do kilku pozycji z listy towarów na fakturze „”, „każdy wpis z listy towarów na fakturze musi być powiązany z dokładnie jednym produktem”. Atrybuty „Ilość towarów na fakturze” i „Cena towarów na fakturze” są atrybutami podmiotu „Lista towarów na fakturze”.

Zrobimy to samo z połączeniem łączącym podmioty „Magazyn” i „Produkt”. Wprowadzamy dodatkowy podmiot „Produkt w magazynie”. Atrybutem tego podmiotu będzie „Ilość towarów w magazynie”. Tak więc towary będą wymienione w dowolnym magazynie, a ich ilość w każdym magazynie będzie inna.

Teraz możesz dodać to wszystko do diagramu:

Figa. 9

Koncepcyjne i fizyczne modele ER

Przykładowa tabela ER opracowana powyżej jest przykładem. schemat koncepcyjny. Oznacza to, że schemat nie uwzględnia funkcji konkretnego DBMS. Korzystając z tego schematu koncepcyjnego, możesz budować schemat fizyczny, który będzie już uwzględniał takie funkcje DBMS, jak prawidłowe typy i nazwy pól i tabel, ograniczenia integralności itp. Fizyczna wersja schematu pokazanego na ryc. 9 może wyglądać na przykład następująco:

Figa. 10

Na tym schemacie każda jednostka jest tabelą bazy danych, każdy atrybut staje się kolumną odpowiedniej tabeli. Zwracamy uwagę na fakt, że w wielu tabelach, na przykład „CUST_DETAIL” i „PROD_IN_SKLAD” odpowiadających jednostkom „Zapis listy faktur” i „Produkt w magazynie” pojawiły się nowe atrybuty, które nie były w modelu koncepcyjnym - są to kluczowe atrybuty tabel nadrzędnych , migrowałdo tabel podrzędnych w celu zapewnienia relacji między tabelami za pomocą kluczy obcych.

Łatwo zauważyć, że wynikowe tabele są natychmiast w 3NF.

Wyniki

Prawdziwym narzędziem do modelowania danych nie jest formalna metoda normalizacji relacji, ale tzw modelowanie semantyczne.

Różne opcje są wykorzystywane jako narzędzie do modelowania semantycznego. diagramy relacji między bytami(ER - związek podmiotu).

Diagramy relacji encja umożliwiają stosowanie wizualnej notacji graficznej do modelowania encji i ich relacji.

Rozróżniać konceptualistycznyi fizycznyWykresy ER. Schematy koncepcyjne nie uwzględniają cech określonych DBMS. Diagramy fizyczne są budowane na podstawie koncepcji i reprezentują prototyp konkretnej bazy danych. Jednostki zdefiniowane na schemacie koncepcyjnym stają się tabelami, atrybuty stają się kolumnami tabel (uwzględnia to prawidłowe typy danych i nazwy kolumn dla tego DBMS), relacje są realizowane przez migracjakluczowe atrybuty podmiotów nadrzędnych i tworzenie kluczy obcych.

Przy prawidłowej definicji jednostek wynikowe tabele będą od razu znajdować się w 3NF. Główną zaletą tej metody jest to, że model jest budowany metodą sekwencyjnych udoskonaleń oryginalnych diagramów.

Ten rozdział, który jest ilustracją metod modelowania ER, nie omawia bardziej złożonych aspektów diagramowania, takich jak podtypy, role, wykluczanie relacji, relacje nie do zaakceptowania, identyfikowanie relacji itp.

Model logiczny (Niezbędne) dane to niezależna logiczna reprezentacja danych.

Model fizyczny Dane (tabelaryczne) zawierają definicje wszystkich zaimplementowanych obiektów w określonej bazie danych dla określonego DBMS.

Modele są podstawą projektowania. Inżynierowie muszą zbudować model samochodu, opracować wszystkie szczegóły przed wprowadzeniem go do produkcji. W ten sam sposób inżynierowie systemów najpierw opracowują modele do studiowania logiki biznesowej i pogłębiają zrozumienie struktury bazy danych.

W ostatnim wykładzie zapoznaliśmy się z metodologiami IDEF0 i DFD, które pozwalają nam opisać procesy biznesowe zachodzące w systemie informatycznym. W modelu DFD zbadaliśmy element - hurtownię danych, która pokazuje typy informacji, z którymi współpracuje system. Jednak ta metodologia nie ma na celu opisania struktury przechowywanych informacji. W tym celu bardziej odpowiednie są różne relacje między jednostkami - diagramy (diagramy jednostek), których celem jest opisanie struktury przechowywanych danych i relacji między nimi. Opracowano techniki, które pozwalają konwertować takie dane na zestaw poleceń, które utworzą niezbędne magazyny (tabele) w bazie danych systemu informatycznego.

Modelowanie ER

W systemy informacyjneah, dane są podzielone na osobne kategorie lub podmioty. W końcu pamiętamy, że baza danych to zestaw danych strukturalnych. Dane różnych typów są przechowywane osobno. Zadaniem modelu ER jest pokazanie, jakie rodzaje informacji są przechowywane w systemie, jaka jest ich struktura i jak są ze sobą powiązane. Model ER jest budowany na podstawie analizy biznesowej (skonstruowany diagram DF). W takim przypadku początkowo każdy sklep na diagramie DF staje się jednostką na diagramie ER. W trakcie dalszej analizy można je podzielić na części składowe. Należy zauważyć, że modele ER są bardziej odporne na zmiany w strukturze biznesowej niż diagramy DF. Procesy biznesowe mogą ulec zmianie, ale informacje potrzebne do ich wdrożenia często pozostają niezmienione.

Główne zalety modeli ER:

• Dokładny i zrozumiały format do dokumentowania struktury informacji.
• Pozwala określić wymagania dotyczące danych i relacje między nimi.
• Umożliwia wizualne pokazanie struktury repozytorium w celu ułatwienia projektowania bazy danych.
• Istnieją metody mapowania modeli ER na tabele bazy danych iz nich.
• Położyć podwaliny pod integrację z innymi aplikacjami.

Główne typy obiektów na schemacie ER:

• Podmiot - typ obiektów, informacje o których będą przechowywane w bazie danych. Na przykład: działy, pracownicy, towary, faktury.
• Atrybut - elementy, z których składa się jednostka. Na przykład dla jednostki „towary” atrybutami mogą być „nazwa”, „opis”, „ilość”, „cena” i inne, w zależności od potrzeb systemu informatycznego. W zależności od zapisu diagramu ER obok atrybutu, oprócz jego nazwy, wskaż typ i obowiązkowe wypełnienie. Slajd pokazuje schemat ER w notacji „Inżynieria informacji”, zgodnie z którą wskazana jest nazwa atrybutu, typ i jest to płacz zewnętrzny i / lub pierwotny.
• Relacje pokazują relacje między jednostkami. Na przykład pracownik pracuje w dziale, w którym „dział” i „dział” to podmioty.

Istota jest zbiorem obiektów świata rzeczywistego, z których każdy ma następujące cechy:

• Unikatowy (można go w dowolny sposób oddzielić od wszystkich innych)
• Odgrywa rolę w symulowanym systemie
• Może być opisany przez jeden lub więcej elementów informacji (atrybut)

Przykład: ludzie, pracownicy, wydarzenia, zamówienia, sprzedaż, klienci, dostawcy

Atrybut opisuje niektóre właściwości bytu. Jednostka może mieć wiele atrybutów, ale wybierane są tylko te, które są ważne dla systemu. Atrybuty są podzielone na klucze encji i deskryptory encji. Kluczowe atrybuty muszą jednoznacznie identyfikować instancje jednostki. Dla każdego atrybutu należy określić domenę (typ, obszar tematyczny).

Slajd pokazuje, w jaki sposób jednostki i atrybuty są rejestrowane w różnych notacjach modeli ER. We wszystkich notacjach byt jest prostokątnym obiektem, w którego górnej części wskazana jest nazwa bytu. Atrybuty są wymienione pod nazwą jednostki.

Przyjrzyjmy się bliżej, jakie są kluczowe atrybuty. Jest to ważne dla zrozumienia rodzajów relacji między jednostkami.

Podstawowe warunki

Model relacyjny, jeśli to konieczne, można opisać językiem matematycznym, czyli najdokładniejszym z wymyślonych przez człowieka. Poniżej przedstawiono nieostre definicje niektórych pojęć modelu relacyjnego.

• „Typ danych” (typ, domena - domena) - zestaw dopuszczalnych wartości („zakres”) i operacji. Dla wszystkich typów istnieją operacje porównania i przypisania. Wartości nie mają zakazu posiadania struktury, takiej jak obiekt.
• „Relacja” - zestaw atrybutów: unikalne nazwy ze specyfikacją typu danych; plus wiele „zestawów wielkości” („szeregów”) odpowiadających atrybutom. Wartości w zestawach mogą być reprezentowane tylko przez wartości jednostkowe odpowiadające typom atrybutów, to znaczy skalarom („1. postać normalna”).
• „Klucz” to grupa atrybutów, których wartości we wszystkich zestawach są względnie różne w relacji, ale żadna podgrupa tych atrybutów nie posiada już takiej właściwości (właściwość „minimalności” klucza). W szczególności grupa może składać się z jednego atrybutu. Klucz z szacunkiem musi być zawsze obecny, a jeśli jest ich kilka, jeden z nich musi być oznaczony jako „podstawowy”.
• „Klucz obcy” to grupa atrybutów, których wartości w każdym zestawie wartości relacji muszą pokrywać się z kluczowymi wartościami możliwie innej relacji. Klucze obce są opcjonalne w odniesieniu do i są ogłaszane zgodnie z potrzebami symulacji.
• „Operacje” (operacja) - wiele typowych działań na relacjach, w wyniku których ponownie powstaje relacja („operacje zamknięte”). Służy do uzyskiwania nowych relacji na potrzeby późniejszego modelowania lub podczas pobierania niezbędnych danych z bazy danych. Lista operacji może być zdefiniowana na różne sposoby; w pierwszych zdaniach modelu podano osiem operacji (rzutowanie, połączenie, wybór itp.), które nie są już zestawem minimalnym, jako kompromis między brakiem redundancji a użytecznością.
• " Relacyjna baza danych" (relacyjna baza danych) - zestaw relacji.

„Typ danych” jest czasem nazywany „domeną” (domeną), ale czasami tylko „domena” ilości oznacza „domenę”. „Zestaw wielkości” (krotka) w języku rosyjskim jest inaczej nazywany „krotką” lub „n-koi”.

Dla wygody relacje często są przedstawiane w formie tabel, chociaż taka reprezentacja jest niezgodna z prawem (ani kolejność atrybutów, ani kolejność zbiorów wielkości nie są zdefiniowane względem, w przeciwieństwie do tabeli). W SQL, na podstawie którego zbudowano Oracle DBMS, pojęcie „relacji” jako narzędzia do modelowania zastępuje się tylko „tabelą”. Inną reprezentacją danych relacji może być hipersześcian, a czasem wygodnie jest się do nich odwoływać w dyskusjach na temat istniejącej bazy danych.

Jeśli porzucimy definitywne słowo śledzenia „relacyjny”, wówczas termin „relacyjna baza danych” można przetłumaczyć jako „baza danych relacji” (a dokładniej „zbudowana baza danych” przez relacje ”; relacje jako narzędzie, a nie przedmiot modelowania: w przeciwnym razie pierwotnym terminem byłaby baza relacji). W ten sam sposób termin„ model relacyjny ”można przetłumaczyć jako„ model relacji ”, to znaczy„ system pojęć do budowy modelu domeny w postaci zestawu relacje. ”Z wielu powodów, w tym historycznych i językowych, nie było to wtedy zrobione.

Wszystkie relacje danych są opisane. oczywiście i tylko wartości w zestawach (w innych podejściach do modelowania mogą być inne). Nie ma żadnych „domniemanych” zależności (w tym na poziomie logiki programu), z wyjątkiem relacji sformułowanych przez zmienne zmiennych. W podejściu relacyjnym rozróżnia się opis danych i logikę oprogramowania powiązaną z aplikacją (w przeciwieństwie na przykład do podejścia obiektowego).

Powyższy widok relacyjnej bazy danych (zestawu relacji i operacji) jest typowy dla algebra relacyjna. To nie jedyny punkt widzenia. Każdy zestaw wartości w zmiennej relacji może być rozumiany jako prawdziwe stwierdzenie („orzecznik”): taki i taki pracownik ma takie i takie właściwości; taki dział i tak dalej. Tak więc relacyjna baza danych w każdym momencie jest zbiorem prawdziwych stwierdzeń na dany temat, sformułowanych poprzez relacje. W rzeczywistości zestaw instrukcji w relacjach zmiennych tworzy model domeny reprezentowany przez bazę danych. Ten widok relacyjnej bazy danych jest charakterystyczny rachunek relacyjny. Oba poglądy na model relacyjny są dobrze zbadane i udowodniona jest ich ekspresyjna równoważność.

W przypadku terminów wymienionych na poprzednim slajdzie istnieją nieformalne odpowiedniki, aby ułatwić ich zrozumienie i zapamiętanie:

• Relacje → Tabela
• Tuple → String, rekord
• Kardynalność → Liczba rzędów
• Atrybut → Pole kolumny
• Stopień → Liczba kolumn
• Klucz podstawowy → Identyfikator
• Domena → Prawidłowy zakres

Kluczowe pola

Niektóre atrybuty relacji to klucz lub klucze. Istnieje kilka rodzajów kluczy:

• Prosty klucz - składa się z jednego atrybutu, złożony - z kilku.
• Potencjalny klucz - Atrybut lub zestaw atrybutów, które mogą identyfikować każdą krotkę relacji. Na przykład w odniesieniu do urzędu paszportowego („Numer paszportu”) oraz („Nazwisko” i „Data urodzenia”) - potencjalne klucze, które umożliwiają jednoznaczną identyfikację każdej osoby.
• W każdej relacji może być tylko jeden klucz podstawowy - atrybut lub zestaw wartości atrybutów, które jednoznacznie identyfikują każdy rekord. Jeśli kilka zestawów atrybutów ma takie właściwości, wówczas jeden z nich jest wybierany jako podstawowy, a wszystkie pozostałe są wybierane jako alternatywne.
• Klucz obcy - sklepy wartość klucz podstawowy innej relacji. Klucze obce służą do komunikacji między relacjami.

Główny klucz

• Każda relacja relacyjna ma tylko 1 klucz podstawowy, wszystkie pozostałe są alternatywne.
• Wartość wszystkich atrybutów klucza głównego nie może nieokreślony. Na przykład związek przechowuje informacje o mieszkańcach miasta. Klucz podstawowy to klucz złożony (NAME, SURNAME, data urodzenia). System informacyjny został zainstalowany na Islandii, gdzie nazwiska nie są używane, co oznacza, że \u200b\u200batrybut „nazwisko” dla większości krotek będzie pusty. Mimo to złożony klucz podstawowy będzie nadal jednoznacznie identyfikował każdą z krotek. Jednak niedopuszczalne jest, aby wartości wszystkich atrybutów klucza podstawowego były jednocześnie puste.
• Wartość klucza podstawowego nie wpływa na lokalizację krotek w widoku tabeli relacji. Nawet jeśli wartość klucza podstawowego jest liczbą (na przykład 1,2,3 ...) ogólnie, nie gwarantuje to, że krotki w bazie danych są przechowywane w tej samej kolejności i będą wyświetlane w tej samej kolejności. W „ogólnym przypadku” oznacza to, że czasami, ze względu na specyfikę konkretnego DBMS, wiersze mogą być przechowywane posortowane według klucza podstawowego, ale jest to raczej wyjątek. W przypadku wyprowadzania wyników zapytania, musimy jawnie wskazać kolejność wypisywania wierszy, jeśli ta kolejność jest ważna. Wyniki zapytania „daj mi pierwsze 5 osób” są nieprzewidywalne, chyba że wskażemy, według jakich kryteriów powinny one być „pierwsze”.
• Klucz podstawowy nie wpływa na dostęp do atrybutów krotek. Na przykład w związku z „biurem paszportowym” adres rejestracyjny osoby jest przechowywany wraz z imieniem i datą urodzenia. Możemy poprosić bazę danych o wyodrębnienie wszystkich adresów bez znajomości imienia i daty urodzenia.

Klucz zewnętrzny

Klucz obcy służy do ustanowienia relacji między relacjami. Weźmy na przykład dwie relacje „Właściciele” (klucz podstawowy „numer paszportu”) i „Nieruchomość”. Aby ustalić, kto jest właścicielem każdej nieruchomości, powiążemy te relacje z wartością atrybutu „numer paszportu”. W przeciwieństwie do klucza podstawowego, wartość klucza obcego może być niezdefiniowana (wiersz 4 na slajdzie) - jeśli nie znamy właściciela właściwości, nie wskazujemy tego. W przeciwieństwie do klucza podstawowego, wartość klucza obcego można powtórzyć (tonie 1.3 na slajdzie) - jeden właściciel może mieć kilka obiektów nieruchomości. Jednak fakt, że atrybut „numer paszportu” w odniesieniu do „nieruchomości” jest kluczem obcym do klucza podstawowego relacji „Właściciel”, gwarantuje, że wartość atrybutu „numer pastora” może być tylko wartością z klucza podstawowego. Nie możemy wskazać wartości atrybutu jako liczby pastora osoby, która nie jest jeszcze w stosunku do „Właściciela” (wiersz 5).

Ustawiając klucz obcy, możesz jawnie ustawić zachowanie DBMS, jeśli zmienisz wartość klucza podstawowego lub usuniesz krotkę. Jednak reguła „tylko wartości znajdujące się w kluczu podstawowym lub wartości niezdefiniowanej (NULL)” są przechowywane w kluczu zewnętrznym.

Klucz obcy między relacjami jest zwykle ustawiany podczas projektowania bazy danych. Można go jednak usunąć w dowolnym momencie lub zainstalować ponownie, jeśli dodanie tego ograniczenia nie jest sprzeczne z właściwościami klucza obcego. Usuwanie / instalowanie kluczy obcych jest zwykle wykonywane podczas wstawiania bardzo dużych ilości danych, aby przyspieszyć ten proces - DBMS nie może przechowywać niespójnych (niepoprawnych, błędnych) danych, dlatego sprawdza każde ograniczenie podczas wstawiania każdego wiersza.

Modele ER: komunikacja

W modelach ER klucze obce są wyświetlane jako łącza.

Każde połączenie charakteryzuje się 4 właściwościami - siłą, mocą, stopniem i udziałem bytu w połączeniu.

Przeanalizujemy te cechy.

Zaangażowanie podmiotu w komunikację

Jest oznaczony w komunikacji przez linię poprzeczną lub okrąg.

Linia krzyżowa oznacza obowiązkowy (obowiązkowy) udział podmiotu w komunikacji, a krąg - opcjonalny (opcjonalny).

W przypadku obowiązkowego udziału podmiotu w związku, czasownik „ powinien". Z opcjonalnym udziałem podmiotów w komunikacji, użyj czasownika" mogą".

Na Wydziale mogą pracować kilku pracowników. Pracownik powinien pracować w niektórych działach.

Stopień komunikacji ( związek stopień) wskazuje liczbę powiązanych jednostek. Komunikacja binarna ( dwójkowy związek) opisuje powiązania dwóch podmiotów. Komunikacja trójskładnikowa (potrójny związek) ma miejsce, gdy trzy podmioty są połączone. Unary link (unary związek) opisuje powiązania w ramach jednego podmiotu.

Najczęstsze połączenia binarne - łączą dwa różne podmioty („Dział” - „Pracownik”, „Zamówienie” - „Towary”, „Kurs” - „Wykłady”, „Grupa” - „Studenci”). Mniej powszechne, ale wciąż często stosowane są obligacje jednoargumentowe. Z ich pomocą relacja zagnieżdżania jest zwykle ustawiana na obiektach tego samego typu (relacja „Szczegóły” - możemy wskazać, która część jest danym komponentem, relacja „Pracownicy” - możemy wskazać, który z pracowników jest szefem tego).

Moc komunikacji pokazuje, ile wystąpień jednej jednostki jest powiązanych z instancjami innej jednostki.

Moc może być:

• jeden na jednego (1: 1) - w grupie studentów jest jeden naczelnik;
• jeden za dużo (1: N) - wielu pracowników pracuje w jednym dziale;
• wiele do wielu (M: N) - jeden kupujący kupił wiele towarów, wielu kupowało towary.

Siła łącza: silna identyfikacja

Podmiot podrzędny nie może istnieć bez obiektu nadrzędnego. (Nie ma odpowiedzi bez pytania; w koszyku użytkownika nie ma produktu, jeśli sam koszyk nie istnieje)

W takim przypadku klucz podstawowy migruje z elementu nadrzędnego do elementu podrzędnego, gdzie staje się częścią klucza podstawowego.

Na schemacie silne połączenie pokazuje nierozerwalna linia między bytami.

Siła komunikacji: związek nieidentyfikujący

Podmioty nadrzędne i podrzędne są powiązane, ale podrzędny obiekt można utworzyć wcześniej. (Towary należą do zamówienia, ale towary mogą być w magazynie przed utworzeniem zamówienia).

Klucz podstawowy migruje z rodzica do dziecka i nie jest częścią klucza podstawowego (staje się tylko kluczem obcym).

Na schemacie silne połączenie pokazano przerywaną linią między elementami.

Komunikacja rekurencyjna (komunikacja jednoargumentowa)

Najczęściej używany do budowania hierarchii.

Dostawca MOŻE współpracować z ZERO lub WIĘCEJ klientów (id_Customer).

Klient MUSI współpracować z jednym dostawcą (id_Sup).

Ale dostawca i klient - niezależnie od tego, czy organizacja jest firmą - są tego samego rodzaju i dlatego są przechowywane pod tym samym względem.

Relacja wiele do wielu.

Przykład: dostawcy mogą dostarczać wiele rodzajów towarów. Różni dostawcy mogą dostarczać te same rodzaje towarów.

Relacja wiele do wielu jest akceptowalna z punktu widzenia modelu ER, ale nie może być bezpośrednio odzwierciedlona w kategoriach algebry relacyjnej.

Niejasności komunikacyjne rozwiązuje się poprzez wprowadzenie jednostek przejściowych, jak pokazano na slajdzie.

Modele ER i rzeczywistość

Bliższe spojrzenie na relacje jeden do jednego prawie zawsze ujawnia, że \u200b\u200bA i B są w rzeczywistości różnymi podzbiorami tego samego obiektu lub różnymi punktami widzenia, po prostu o różnych nazwach i odmiennie opisanych relacjach i atrybutach.

Wyobraź sobie, że A jest dostawcą, B jest produktem.

Obowiązkowo-obowiązkowo.W przykładzie pokazanym na slajdzie ta relacja oznacza, że \u200b\u200bkażdy dostawca powinien dostarcz tylko jeden wyjątkowy zestaw towarów (faktura). Z punktu widzenia teorii wszystko jest w porządku. W praktyce jest to niedopuszczalne: nikt nie będzie szukał nowego dostawcy, jeśli zweryfikowany dostawca może dostarczyć kilka zakresów produktów. A teraz, jeśli chodzi o emocje, kot doświadczy operatora podczas próby wprowadzenia danych o nowym dostawcy. Nie będzie mógł wprowadzić danych w żadnej z tabel. Tak więc cały bagaż nieprzyzwoitego słownictwa zostanie do Ciebie przesłany.

Opcjonalnie obowiązkowe. Przykład komunikacji pokazano na slajdzie. Jak widzimy, operator ma się dobrze: może wprowadzać dane. Firma znów ma problem: musi szukać nowego dostawcy, nawet jeśli zweryfikowany dostawca może dostarczyć kilka zakresów produktów. Czy biznes potrzebuje problemów? Nie. Musi działać. Jak zadowolić firmę? Odpowiedź jest prosta. Projektując bazę danych, należy pomyśleć o normalizacji. Jeśli Dostawca jest podmiotem, użyj relacji takich jak opcjonalne-obowiązkowe (obowiązkowe-opcjonalne) lub opcjonalne-opcjonalne. Chociaż najczęściej komunikacja jeden do jednego jest błędem.

Opcjonalnie-opcjonalnie. Jak widzimy, operator znów ma się dobrze, ale firma znów ma problem. Podsumowując relację jeden do jednego. Jeżeli podmioty uczestniczą w związku jako: - obowiązkowo-obowiązkowe, wówczas taki związek nie ma prawa do życia; - opcjonalne-obowiązkowe (obowiązkowe-opcjonalne) lub opcjonalne-opcjonalne, wówczas wsparcie biznesowe jest problematyczne.

Relacja jeden do wielu obowiązkowo-obowiązkowa jest dość silną konstrukcją, co sugeruje, że nie można utworzyć wystąpienia bytu B bez jednoczesnego utworzenia co najmniej jednego powiązanego wystąpienia bytu A. Najczęściej jest to związek niepoprawny.

Wiązanie jeden do wielu obowiązkowe-opcjonalne jest najczęstszą formą komunikacji. Zakłada się, że każde wystąpienie bytu A może istnieć tylko w kontekście jednego (i tylko jednego) wystąpienia bytu B. Z kolei występowanie B może istnieć zarówno w związku z wystąpieniem A, jak i bez niego.

Relacja jeden do wielu opcjonalna - opcjonalna - Zarówno A, jak i B mogą istnieć bez relacji między nimi.

W odniesieniu do poprzedniego slajdu diagramy te można zilustrować następującymi przykładami.

Relacje jeden do wielu. Te relacje sugerują, że jeden rekord w jednej tabeli może być logicznie powiązany z kilkoma rekordami w innej tabeli.

Obowiązkowo-obowiązkowo.W przykładzie pokazanym na slajdzie ta zależność oznacza, że \u200b\u200bkażdy dostawca (A) musi dostarczyć jeden lub więcej zestawów towarów (B). Z punktu widzenia teorii wszystko jest w porządku. Jednak w praktyce operator nie będzie mógł wprowadzać danych do żadnej z tabel, ponieważ rekordy są konieczne w tym samym czasie wprowadź w obu tabelach.

Opcjonalnie obowiązkowe.W takim przypadku operator ma już wszystko: może wprowadzać dane, ale firma może mieć problemy. Faktem jest, że relacja fakultatywno-obowiązkowa zakłada, że \u200b\u200bdostawca (A) powinien dostarczyć jeden lub więcej zestawów towarów (B), podczas gdy B mogą należą do dostawcy. Innymi słowy, towary mogą istnieć bez dostawcy, podczas gdy dostawca ma towary. Te. prawdopodobnie niekontrolowany biznes: kto dostarczył towar? Kogo zapytać? Czy biznes potrzebuje problemów? Nie. On musi zarobić. W takim przypadku lepiej jest użyć opcji obowiązkowej-opcjonalnej: dostawca może dostarczyć jeden lub więcej zestawów towarów, podczas gdy towary muszą należeć do dostawcy. Innymi słowy, towary mają dostawcę, a dane dotyczące dostawców, którzy raz dostarczyli towary, zostaną zapisane. Owce są bezpieczne, a wilki pełne - operator może wprowadzać dane, a biznesmen jest w centrum rzeczy.

Opcjonalnie-opcjonalnie.Jak widzimy, operator znów ma się dobrze, ale firma ma problem z brakiem kontroli: produkt może istnieć bez dostawcy i dostawcy bez produktu.
Podsumowując relację jeden do wielu. Jeżeli podmioty są zaangażowane w związek jako: - obowiązkowo-obowiązkowy, wówczas taki związek nie ma prawa do życia, ponieważ niemożliwe jest jednoczesne wprowadzanie rekordów w obu tabelach; - opcjonalnie-opcjonalnie, wtedy wsparcie dla biznesu jest problematyczne.

Relacje wiele do wielu są dopuszczalne na diagramach ER, ale po przekonwertowaniu na widok tabeli taka relacja jest zastępowana przez jednostkę pośrednią.

Wiele do wielu obowiązkowo-obowiązkowych - taka konstrukcja często ma miejsce na początku fazy analizy i oznacza komunikację - albo nie w pełni zrozumiała i wymagająca dodatkowego pozwolenia, albo odzwierciedlająca prosty związek zbiorowy - lista dwukierunkowa.

Wiele do wielu obowiązkowo-opcjonalnie - rzadko używane. Takie relacje zawsze podlegają dalszemu opracowaniu.

Komunikacja rekurencyjna. Te relacje sugerują, że wpisy w tabeli mogą być logicznie powiązane.

Opcjonalnie-opcjonalnie jeden do jednego. W przykładzie pokazanym na slajdzie związek ten oznacza, że \u200b\u200bkażdy mężczyzna (kobieta) może poślubić jedną kobietę (mężczyznę). To połączenie jest wygodne do śledzenia historii pary: po raz pierwszy wielokrotnie ... Innymi słowy, alternatywny typ połączenia.

Opcjonalnie-opcjonalnie jeden do wielu. Przykład komunikacji pokazano na slajdzie. Jest to klasyczna hierarchia (struktura drzewa). Relację pokazaną na slajdzie można interpretować na przykład w następujący sposób: każdy pracownik może być podporządkowany tylko jednemu kierownikowi, podczas gdy kierownik może prowadzić jednego lub wielu pracowników.

Opcjonalnie-opcjonalnie M: M Przykład komunikacji pokazano na slajdzie 3. Jest to struktura sieci.

Lista kontrolna pytań podmiotu

• Czy nazwa bytu odzwierciedla istotę danego obiektu?
• Czy są jakieś skrzyżowania z innymi podmiotami?
• Czy są co najmniej dwa atrybuty?
• Suma atrybutów nie więcej niż osiem?
• Czy są jakieś synonimy / homonimy dla tego podmiotu?
• Czy jednostka jest w pełni zdefiniowana?
• Czy istnieje unikalny identyfikator?
• Czy jest co najmniej jedno połączenie?
• Czy istnieje co najmniej jedna funkcja do tworzenia, wyszukiwania, aktualizacji, usuwania, archiwizacji i używania wartości encji?
• Czy utrzymywana jest historia zmian?
• Czy istnieje zgodność z zasadami normalizacji danych?
• Czy istnieje ten sam podmiot w innym systemie aplikacji, być może pod inną nazwą?
• Czy istota ma zbyt ogólne znaczenie?
• Czy poziom w nim uogólniony jest wystarczający?

Lista kontrolna atrybutów pytań:

• Czy nazwa atrybutu jest liczbą pojedynczą, odzwierciedlającą istotę właściwości oznaczonej przez atrybut?
• Czy nazwa atrybutu zawiera nazwę encji (nie powinna być)?
• Czy atrybut ma jednocześnie tylko jedną wartość?
• Brakuje zduplikowanych wartości (lub grup)?
• Czy opisano format, długość, dopuszczalne wartości, algorytm pobierania itp.?
• Czy ten atrybut może być brakującym bytem przydatnym dla innego systemu aplikacji (istniejącego lub dorozumianego)?
• Czy to może być brakujący link?
• Czy jest gdzieś odniesienie do atrybutu jako „cechy projektu”, który powinien zniknąć po przejściu na poziom aplikacji?
• Czy istnieje potrzeba historii zmian?
• Czy jego znaczenie zależy tylko od danego bytu?
• Jeśli wymagana jest wartość atrybutu, czy zawsze jest znana?
• Czy istnieje potrzeba utworzenia domeny dla tego i podobnych atrybutów?
• Czy jego wartość zależy tylko od części niepowtarzalnego identyfikatora?
• Czy jego wartość zależy od wartości niektórych atrybutów nieuwzględnionych w unikalnym identyfikatorze?

Model relacji jednostka - atrybut - zaproponował Peter Pin-Shen Chenov w 1976 roku. Większość współczesnych podejść do projektowania baz danych (głównie relacyjnych) opiera się na wykorzystaniu odmian modelu ER. Modelowanie domen oparte jest na wykorzystaniu graficznych wykresów, które zawierają niewielką liczbę heterogenicznych składników. Ze względu na przejrzystą prezentację koncepcyjnych schematów baz danych modele ER są szeroko stosowane w systemach CASE, które obsługują automatyczne projektowanie relacyjnych baz danych.

Podstawowymi pojęciami modelu ER są istota, atrybut i związek.

Istota - jest to rzeczywisty lub wymyślony obiekt, którego informacja jest interesująca. Na schematach modelu ER jednostka jest reprezentowana jako prostokąt zawierający nazwę jednostki. W tym przypadku nazwa encji jest nazwą typu, a nie określonego obiektu - instancji tego typu. Każda instancja encji musi być odróżnialna od każdej innej instancji tej samej encji.

Relacja to graficznie przedstawione powiązanie ustanowione między dwoma podmiotami. To powiązanie jest zawsze binarne i może istnieć między dwoma różnymi bytami lub między bytem a sobą (relacja rekurencyjna). W dowolnym połączeniu rozróżnia się dwa końce (zgodnie z parą połączonych podmiotów), na każdym z nich nazwa końca połączenia, stopień zakończenia połączenia (ile instancji danego podmiotu jest połączonych), powiązanie połączenia (tj. Czy w jakimkolwiek wystąpieniu tego podmiotu powinien uczestniczyć to połączenie).

Połączenie jest reprezentowane w postaci linii łączącej dwa byty lub prowadzącej od jednego do siebie samego. Jednocześnie w miejscu, w którym „zadokowane” jest połączenie z bytem, \u200b\u200bstosuje się trzypunktowy wpis w prostokącie bytu, jeśli w relacji można zastosować wiele wystąpień bytu, i jednopunktowy wpis, jeśli tylko jedno wystąpienie bytu może uczestniczyć w związku. Obowiązkowy koniec połączenia jest pokazany linią ciągłą, a opcjonalny linią przerywaną.

Podobnie jak byt, związek jest typową koncepcją, wszystkie przypadki połączenia obu par podmiotów są zgodne z regułami stowarzyszenia. Na ryc. 1. Podany jest przykład obrazu bytów i związek między nimi. Ten diagram można interpretować w następujący sposób:

Każdy STUDENT studiuje tylko w jednej GRUPIE;

Każda GRUPA składa się z jednego lub więcej UCZNIÓW.

Figa. 1. Relacja między podmiotami

Na ryc. 2 przedstawia istotę MAN z połączeniem rekurencyjnym łączącym go ze sobą. Krótka ustna interpretacja diagramu jest następująca:

Każdy CZŁOWIEK jest synem jednego i tylko jednego CZŁOWIEKA;

Każdy MĘŻCZYZNA może być ojcem jednego lub więcej LUDZI („MĘŻCZYZN”).

Figa. 2. Komunikacja rekurencyjna

Atrybut bytu to każdy szczegół, który służy do wyjaśnienia, identyfikacji, klasyfikacji, numerycznej charakterystyki lub wyrażenia stanu bytu. Nazwy atrybutów są wprowadzane w prostokącie przedstawiającym encję pod nazwą encji i są reprezentowane małymi literami:

Unikalny identyfikator jednostki to atrybut, kombinacja atrybutów, kombinacja relacji lub kombinacja relacji i atrybutów, która jednoznacznie odróżnia dowolne wystąpienie bytu od innych wystąpień bytu tego samego typu. Są to najważniejsze koncepcje modelu danych ER. Bardziej złożone elementy modelu obejmują:

Relacje wiele do wielu. Czasami konieczne jest powiązanie podmiotów w taki sposób, aby kilka wystąpień podmiotu mogło być obecnych na obu końcach połączenia (na przykład wszyscy członkowie spółdzielni wspólnie posiadają własność spółdzielni). Aby to zrobić, wprowadza się rodzaj relacji wiele-z-wieloma.

Określone stopnie komunikacji. Czasami przydatne jest określenie możliwej liczby instancji encji zaangażowanych w daną relację (na przykład pracownik może uczestniczyć w nie więcej niż trzech projektach jednocześnie). Aby wyrazić to ograniczenie semantyczne, na końcu połączenia można wskazać jego maksymalny lub obowiązkowy stopień.

Kaskadowe usuwanie instancji encji. Niektóre relacje są tak silne (oczywiście w przypadku relacji jeden do wielu), że usuwając instancję referencyjną encji (odpowiadającą końcowi jednego połączenia), należy usunąć wszystkie instancje encji, które odpowiadają końcowi wielu relacji. Odpowiednie wymaganie „kaskadowego usuwania” można sformułować podczas definiowania jednostki.

Domeny Podobnie jak w przypadku relacyjnego modelu danych, przydatne może być zdefiniowanie potencjalnie prawidłowego zestawu wartości atrybutów encji (domeny).

Te i inne bardziej złożone elementy modelu danych relacja-związek zwiększają jego moc, ale jednocześnie nieco komplikują jego użycie. Oczywiście przy prawdziwym wykorzystaniu diagramów ER do projektowania baz danych należy zapoznać się ze wszystkimi funkcjami.

Najczęściej w praktyce modelowanie ER stosuje się na pierwszym etapie projektowania bazy danych. Jego wynikiem jest z reguły model koncepcyjny obszaru przedmiotowego wyrażony w modelu ER.

Przechodząc do następnego etapu - modelowania schematu bazy danych - deweloper boryka się z problemem wyrażenia modelu koncepcyjnego domeny tematycznej w kategoriach zastosowanego modelu danych (na przykład relacyjnego). Istnieją trzy podejścia do rozwiązania tego problemu.

Pierwsze podejście polega na ręcznym przekształceniu modelu koncepcyjnego domeny tematycznej w schemat bazy danych, wykonywanym zgodnie z metodami, w których wszystkie etapy takiej transformacji są dość wyraźnie określone.

W drugim podejściu wdrażana jest automatyczna kompilacja modelu koncepcyjnego obszaru tematycznego do schematu bazy danych (najczęściej relacyjnej). Znane są dwa rodzaje podejścia:

podejście oparte na wyraźnej reprezentacji modelu koncepcyjnego obszaru tematycznego jako informacji źródłowej do kompilacji;

podejście skoncentrowane na budowie zintegrowanych systemów projektowych z automatycznym tworzeniem modelu koncepcyjnego obszaru tematycznego na podstawie wywiadów z ekspertami w tej dziedzinie.

W obu przypadkach wynikiem jest schemat relacyjnej bazy danych w trzeciej normalnej formie.

Wreszcie, trzecie podejście -jest to bezpośrednia praca z bazą danych w modelu semantycznym, tj. zastosowanie DBMS w oparciu o semantyczne modele danych. W takim przypadku ponownie rozważane są dwie opcje.

Pierwszą opcją jest zapewnienie interfejs użytkownika oparty na semantycznym modelu danych z automatycznym mapowaniem struktur na relacyjny model danych (jest to zadanie o tym samym poziomie złożoności, co automatyczna kompilacja modelu koncepcyjnego domeny tematycznej do schematu bazy danych).

Druga opcja to bezpośrednia implementacja DBMS oparta na pewnego rodzaju semantycznym modelu danych.

Drugą opcją są nowoczesne zorientowane obiektowo DBMS, których modele danych pod wieloma względami są podobne do modeli semantycznych (chociaż w niektórych aspektach są one mocniejsze, a w niektórych są słabsze). Chociaż ogólnie można powiedzieć, że takie podejście nie wykroczyło jeszcze poza projekty badawcze i eksperymentalne.

Obecnie na rynku oprogramowanie pojawiło się całkiem sporo uniwersalnych (niepowiązanych z żadnym konkretnym DBMS) pakietami komputerowego projektowania bazy danych, umożliwiającymi koncepcyjne modelowanie obszaru tematycznego. Prawie wszystkie systemy tego rodzaju opierają się na takiej lub innej interpretacji modelu ER. Takie systemy są implementacją drugiego z powyższych podejść. Jednym z najpopularniejszych programów w tym obszarze jest ERwin firmy Platinum.

Modele danych

Sposób mapowania encji, atrybutów i relacji do struktur danych jest określony przez model danych. Istnieją 4 główne modele danych - listy, relacyjne bazy danych, struktury hierarchiczne i sieciowe. Rozważmy je bardziej szczegółowo.

Najprostszym typem jest lista - struktura danych w sekwencji liniowej.

Hierarchiczne struktury drzew są szeroko stosowane w codziennej działalności człowieka. Hierarchiczne modele danych oparte są na wykorzystaniu graficznych i tabelarycznych form reprezentacji danych. Na graficznym schemacie schematu bazy danych wierzchołek wykresu służy do interpretacji typów jednostek, a łuki do interpretacji typów relacji między typami jednostek. Po zaimplementowaniu wierzchołki są reprezentowane przez tabele opisujące instancje jednostek odpowiedniego typu. Na ryc. Rysunek 3 pokazuje przykład hierarchicznej struktury drzewiastej bazy danych.

Figa. 3. Hierarchiczna struktura drzewa bazy danych

Główne wewnętrzne ograniczenia hierarchicznego modelu danych są następujące:

- wszystkie typy połączeń muszą być funkcjonalne, tj. 1: 1, 1: M, M: 1;

- struktura relacji powinna być podobna do drzewa.

Wynikiem tych ograniczeń jest szereg cech procesu strukturyzacji danych w modelu hierarchicznym.

Struktura drzewa lub drewno, - jest to połączony niekierowany wykres, który nie zawiera cykli. Zwykle podczas pracy z drzewem wybiera się określony wierzchołek, który określa się jako korzeń drzewo i jest szczególnie uważane - żadna krawędź nie wchodzi w tę górę. W takim przypadku drzewo zostaje zorientowane. Orientacja jest zwykle określana od podstaw.

Drzewo główne jako wykres kierunkowy można zdefiniować w następujący sposób:

- istnieje jeden specjalny wierzchołek zwany korzeniem, do którego nie wchodzi ani jedna krawędź;

- we wszystkich innych wierzchołkach wchodzi tylko jedna krawędź i emanuje dowolna liczba krawędzi;

- bez cykli.

Hierarchiczna struktura drzewa, zorientowana od podstaw, spełnia następujące warunki:

- hierarchia zawsze zaczyna się od węzła głównego;

- na pierwszym poziomie hierarchii można zlokalizować tylko węzeł główny;

- na niższych poziomach są wygenerowane przez (zależne) węzły;

- każdy wygenerowany węzeł znajduje się na poziomie L. , powiązane tylko z jednym bezpośrednio źródło węzeł (bezpośrednio węzeł nadrzędny) znajdujący się na wyższym (L - 1) poziomie hierarchii drzew;

- każdy węzeł źródłowy może mieć jeden lub więcej bezpośrednio generowanych węzłów, tzw lubić;

- dostęp do każdego spawnowanego węzła odbywa się poprzez jego bezpośrednio źródłowy węzeł;

- istnieje pojedyncza hierarchiczna ścieżka dostępu do węzła, poczynając od korzenia drzewa (ryc. 4).

Figa. 4. Hierarchiczna ścieżka dostępu do węzła

Innymi słowy, hierarchiczny model reprezentacji wiedzy (lub drzewa) to struktura danych, w której każdy węzeł ma tylko jednego „rodzica”, tj. węzeł dominujący (z wyjątkiem najwyższego węzła) i nieograniczona liczba „potomków”, tj. węzły, nad którymi ten węzeł dominuje.

Modele danych sieciowych opierają się również na graficznej reprezentacji danych. Wierzchołki wykresu służą do interpretacji typów bytów, a łuki - rodzajów relacji. Model sieci reprezentacje wiedzy - struktura danych, w której każdy obiekt, w przeciwieństwie do reprezentacji hierarchicznej, może mieć więcej niż jeden dominujący węzeł (ryc. 5).

Figa. 5 Struktura sieci

W latach 70. zaczęto aktywnie prowadzić badania teoretyczne. relacyjny model danych. Wraz z pojawieniem się komputerów osobistych modele relacyjne zaczęły dominować na rynku systemów informatycznych. Reprezentacja wiedzy relacyjnej- Prezentacja wiedzy w formie relacji.

Zgodnie z relacyjnym modelem danych dane są prezentowane jako zestaw tabel, na których można wykonywać operacje sformułowane w kategoriach relacyjna algebra lub rachunek relacyjny.

Logiczny projekt

W proponowanej metodologii projektowania baz danych cały proces rozwoju jest podzielony na trzy główne fazy: projekt koncepcyjny, logiczny i fizyczny. Logiczny projekt bazy danych - Jest to proces konstruowania ogólnego modelu informacyjnego przedsiębiorstwa na podstawie indywidualnych modeli danych użytkownika, który jest niezależny od cech rzeczywistego DBMS i innych warunków fizycznych.

Na poprzednim etapie uzyskaliśmy zestaw lokalnych modeli danych koncepcyjnych, które odzwierciedlają pogląd użytkownika na przedmiotowe środowisko. Jednak modele te mogą zawierać pewne struktury danych, których implementacja w konwencjonalnych typach DBMS będzie trudna. Na tym etapie takie struktury danych są przekształcane w formę, która nie spowoduje trudności, gdy zostaną zaimplementowane w środowisku istniejących DBMS. Może pojawić się uwaga, że \u200b\u200bdziałania te nie są częścią logicznego projektu baz danych. Jednak proponowana procedura zmusza dewelopera do dokładniejszego rozważenia znaczenia każdego elementu danych, co pozytywnie wpływa na dokładność wyświetlania cech konkretnego przedsiębiorstwa w modelu. Na tym etapie wykonywane są następujące działania:

1. Usuwanie relacji typu M.:N..

2. Usuwanie złożonych relacji.

3. Usuwanie relacji rekurencyjnych.

4. Usuwanie relacji z atrybutami.

5. Usuwanie wielu atrybutów.

6. Ponowne sprawdzenie relacji typu 1: 1.

7. Usuwanie nadmiarowych linków.

1. Usuwanie wiązań typu M: N.Jeśli model koncepcyjny zawiera relacje podobne M.:N. („Wiele do wielu”), należy je wyeliminować poprzez zdefiniowanie jakiegoś pośredniego bytu. Rodzaj związku M.:N. zastąpiony dwoma obligacjami typu 1: M.zestaw z nowo utworzoną jednostką.

Jako przykład rozważ następujące M.:N. komunikacja: gazeta drukuje reklamy wynajmowanych obiektów (ryc. 6)

Figa. 6. M: N Komunikacja

Aby wyeliminować ten związek, definiujemy encję pośrednią AD i tworzymy dwie nowe relacje typu 1: M.. W rezultacie typ relacji M.:N. zostaną zastąpione dwoma wiązaniami (ryc. 7).

Figa. 7. Relacje typu 1: M.

2. Usuwanie złożonych relacji.Złożone jest połączenie istniejące między co najmniej trzema typami bytów. Jeśli w modelu koncepcyjnym występuje złożona relacja, należy ją wyeliminować za pomocą jednostki pośredniej. Łącze złożone zastępowane jest wymaganą liczbą łączy binarnych typu 1: M.zestaw z nowo utworzonym bytem. Na przykład, potrójna obligacja „Do wynajęcia” (pokazana jako romb) odzwierciedla związek, który istnieje między pracownikiem firmy dzierżawiącym, gruntem a najemcą (ryc. 8).

Figa. 8. Złożone połączenie

To złożone połączenie można uprościć, wprowadzając nowy byt i definiując połączenia binarne między nim a każdym z oryginalnych bytów złożonego połączenia.

W naszym przykładzie relację „do wynajęcia” można wyeliminować, wprowadzając nowy słaby podmiot o nazwie Umowa. Nowo utworzony byt zostanie powiązany z oryginalnymi bytami trzema nowymi wiązaniami binarnymi (ryc. 9).

Figa. 9. Uprość złożoną komunikację

3. Usuwanie relacji rekurencyjnych.Rekurencyjne są te relacje, w których jednostka określonego typu oddziałuje ze sobą. Jeśli model koncepcyjny zawiera relacje rekurencyjne, należy je wyeliminować poprzez zdefiniowanie jakiegoś elementu pośredniego. Na przykład, aby odzwierciedlić sytuację, w której jeden z pracowników przewodzi grupie innych pracowników, można ustanowić relację rekurencyjną jeden do wielu (1: M.).

4. Usuwanie relacji z atrybutami.Jeśli w modelu koncepcyjnym istnieją relacje, które mają swoje własne atrybuty, należy je przekształcić, tworząc nowy byt. Rozważmy na przykład sytuację, w której chcesz zapisać liczbę godzin pracy przepracowanych przez personel tymczasowy każdego z działów przedsiębiorstwa. Link „Działa w” ma atrybut o nazwie „Przepracowane godziny”. Przekształcamy relację „działa w” w encję o nazwie „Dystrybucja według działów”, do której przypisujemy atrybut „Przepracowane godziny”, a następnie tworzymy dwie nowe relacje typu 1: M..

5. Usuwanie wielu atrybutów.Wiele atrybutów to atrybuty, które mogą mieć jednocześnie kilka wartości dla tej samej instancji encji. Jeśli w modelu koncepcyjnym występuje wiele atrybutów, należy je przekształcić, definiując nowy byt. Na przykład, aby odzwierciedlić sytuację, gdy ten sam oddział firmy ma kilka numerów telefonów, w modelu koncepcyjnym zdefiniowano wiele atrybutów „ Numer telefonu”, Odnosząc się do istoty„ Oddziału firmy ”. Ten wielokrotny atrybut należy usunąć, definiując nowy obiekt „Telefon”, który ma jeden prosty atrybut „Numer telefonu” i tworząc nową relację typu 1.

6. Ponowne sprawdzenie relacji między typami1:1. W procesie definiowania jednostek można utworzyć dwa różne podmioty, które faktycznie reprezentują ten sam obiekt w domenie aplikacji. Na przykład można utworzyć dwie jednostki „Dział” i „Dział”, które faktycznie reprezentują ten sam typ obiektu. Innymi słowy, nazwa „Departament” jest synonimem nazwy „Departament”. W takim przypadku powinieneś połączyć te dwa podmioty w jeden. Jeśli klucze podstawowe połączonych jednostek są różne, wybierz jeden z nich jako podstawowy, a drugi jako klucz alternatywny.

7. Usuwanie nadmiarowych linków.Połączenie jest redundantne, jeśli te same informacje można uzyskać nie tylko za jego pośrednictwem, ale także przy użyciu innego połączenia. Zawsze należy dążyć do stworzenia minimalnych modeli danych, a zatem, jeśli redundantna komunikacja nie jest oczywiście konieczna, należy ją usunąć. Ustalenie, że istnieje więcej niż jedno połączenie między dwoma podmiotami, jest dość proste. Jednak nie wynika jeszcze z tego, że jedna z tych relacji jest koniecznie zbędna, ponieważ obie mogą reprezentować różne stowarzyszenia, które faktycznie istnieją w organizacji.

W eliminowaniu nadmiarowości dostępu ważne jest określenie czasu. Rozważmy na przykład sytuację, w której konieczne jest modelowanie relacji między bytami „Mężczyzna”, „Kobieta” i „Dziecko”. Oczywiście pomiędzy bytami „Człowiek” i „Dziecko” istnieją dwa sposoby dostępu: jeden poprzez bezpośrednią komunikację “ On jest ojcem ”, a drugi poprzez powiązania “ Żonaty z ”i„ Jest matką ”. Na pierwszy rzut oka wydaje się, że połączenie “ Jest ojcem ”jest zbędny. To stwierdzenie może jednak okazać się błędne z dwóch powodów. Po pierwsze, ojciec może mieć dzieci z poprzedniego małżeństwa, a my modelujemy tylko obecne małżeństwo ojca (poprzez relację 1: 1). Po drugie, ojciec i matka mogą w ogóle nie być małżeństwem lub ojciec może być żonaty z kobietą, która nie jest matką dziecka (lub matka może być żoną mężczyzny, który nie jest ojcem dziecka). Dlatego nie można modelować wszystkich istniejących relacji bez użycia relacji takiej jak „Jest ojcem” (ryc. 10).

Figa. 10. Związek między bytami „Mężczyzna”, „Kobieta”, „Dziecko”

Podobne informacje.