IDEF1X - IDEF1X

Przykład diagramu IDEF1X.

Integracja DEFinition for information modeling (IDEF1X) to język modelowania danych służący do tworzenia semantycznych modeli danych . IDEF1X służy do wytworzenia graficznego o modelu , która przedstawia strukturę i semantyka z informacji w środowisku lub systemu .

IDEF1X umożliwia budowę semantycznych modeli danych, które mogą służyć do wspomagania zarządzania danymi jako zasobem, integracji systemów informatycznych oraz budowy komputerowych baz danych . Ten standard jest częścią rodziny języków modelowania IDEF w dziedzinie inżynierii oprogramowania .

Przegląd

Modelowanie danych technika jest używana do modelu danych w standardzie, konsekwentny i przewidywalny sposób, aby zarządzać go jako zasób. Może być stosowany w projektach wymagających standardowych środków definiowania i analizowania zasobów danych w organizacji. Takie projekty obejmują włączenie techniki modelowania danych do metodologii , zarządzanie danymi jako zasobami, integrację systemów informatycznych lub projektowanie komputerowych baz danych . Podstawowymi celami standardu IDEF1X jest zapewnienie:

Środki do pełnego zrozumienia i analizy zasobów danych organizacji
Typowe sposoby przedstawiania i komunikowania złożoności danych
Technika prezentacji ogólnego obrazu danych potrzebnych do prowadzenia przedsiębiorstwa
Środki do definiowania niezależnego od aplikacji widoku danych, które mogą być sprawdzane przez użytkowników i przekształcane w fizyczny projekt bazy danych
Technika wyprowadzania zintegrowanej definicji danych z istniejących zasobów danych.

Głównym celem IDEF1X jest wspieranie integracji . Podejście do integracji koncentruje się na przechwytywaniu, zarządzaniu i wykorzystaniu pojedynczej semantycznej definicji zasobu danych zwanej „ schematem koncepcyjnym ”. „Schemat koncepcyjny” zapewnia pojedynczą, zintegrowaną definicję danych w przedsiębiorstwie, która nie jest ukierunkowana na żadne pojedyncze zastosowanie danych i jest niezależna od sposobu fizycznego przechowywania danych lub uzyskiwania do nich dostępu. Podstawowym celem tego schematu koncepcyjnego jest zapewnienie spójnej definicji znaczenia danych i wzajemnych relacji między nimi, które można wykorzystać do integracji, udostępniania i zarządzania integralnością danych. Schemat koncepcyjny musi mieć trzy ważne cechy:

Spójne z infrastrukturą biznesową i prawdziwe we wszystkich obszarach zastosowań
Rozszerzalny, tak że nowe dane mogą być definiowane bez zmiany wcześniej zdefiniowanych danych
Możliwość przekształcenia zarówno w wymagane widoki użytkownika, jak i do różnych struktur przechowywania danych i dostępu.

Historia

Potrzeba semantycznych modeli danych została po raz pierwszy uznana przez Siły Powietrzne Stanów Zjednoczonych w połowie lat 70. XX wieku w wyniku programu Integrated Computer Aided Manufacturing (ICAM). Celem tego programu było zwiększenie wydajności produkcji poprzez systematyczne stosowanie technologii komputerowej. Program ICAM wskazał na potrzebę lepszych technik analizy i komunikacji dla osób zaangażowanych w poprawę produktywności produkcji. W rezultacie w ramach programu ICAM opracowano szereg technik znanych jako metody IDEF (definicja ICAM), które obejmowały:

IDEF0 używany do tworzenia „modelu funkcji”, który jest ustrukturyzowaną reprezentacją działań lub procesów w środowisku lub systemie
IDEF1 używany do tworzenia „modelu informacji”, który reprezentuje strukturę i semantykę informacji w środowisku lub systemie
IDEF2 używany do tworzenia „modelu dynamiki”.

Wstępne podejście do modelowania informacji IDEF (IDEF1) zostało opublikowane przez program ICAM w 1981 r., W oparciu o aktualne badania i potrzeby przemysłu. Teoretyczne korzenie tego podejścia wywodzą się z wczesnych prac Edgara F. Codda na temat teorii modeli relacyjnych i Petera Chena na temat modelu relacji jednostka . Początkowa technika IDEF1 została oparta na pracy dr RR Browna i pana TL Rameya z Hughes Aircraft i pana DS Colemana z D. Appleton Company (DACOM), z krytycznym przeglądem i wpływem Charlesa Bachmana , Petera Chen , dr MA Melkanoffa i Dr GM Nijssen .

W 1983 roku Siły Powietrzne Stanów Zjednoczonych zainicjowały projekt Integrated Information Support System (I2S2) w ramach programu ICAM. Celem tego projektu było zapewnienie technologii umożliwiającej logiczną i fizyczną integrację sieci heterogenicznego sprzętu komputerowego i oprogramowania. W wyniku tego projektu i doświadczenia branżowego uznano potrzebę ulepszonej techniki modelowania informacji.

Z punktu widzenia administratorów kontraktu programu Air Force IDEF, IDEF1X był wynikiem projektu ICAM IISS-6201 i został rozszerzony o projekt IISS-6202. Aby spełnić wymagania dotyczące udoskonalenia modelowania danych, które zostały zidentyfikowane w projekcie IISS-6202, podwykonawca DACOM uzyskał licencję na technikę projektowania logicznej bazy danych (LDDT) i jej oprogramowanie pomocnicze (ADAM). Z punktu widzenia zawartości technicznej techniki modelowania, IDEF1X to zmiana nazwy LDDT.

W dniu 2 września 2008 r. Powiązany standard NIST, FIPS 184, został wycofany (decyzja w sprawie Rejestru Federalnego, tom 73 / strona 51276 [1] ).

Od września 2012 r. IDEF1X jest częścią międzynarodowej normy ISO / IEC / IEEE 31320-2: 2012. Standard opisuje składnię i semantykę IDEF1X97, który składa się z dwóch języków modelowania koncepcyjnego: języka „klucza” zgodnego w dół z FIPS 184, który obsługuje relacyjne i rozszerzone relacyjne bazy danych, oraz nowszego języka „stylu tożsamości” odpowiedniego dla obiektowe bazy danych i modelowanie obiektowe.

Technika projektowania logicznych baz danych

Technika logicznego projektowania baz danych (LDDT) została opracowana w 1982 roku przez Roberta G. Browna z The Database Design Group całkowicie poza programem IDEF i bez znajomości IDEF1. Niemniej jednak główny cel IDEF1 i LDDT był taki sam: stworzenie neutralnego dla bazy danych modelu trwałych informacji potrzebnych przedsiębiorstwu poprzez modelowanie zaangażowanych podmiotów w świecie rzeczywistym. LDDT łączyło elementy relacyjnego modelu danych, modelu ER i generalizacji danych w sposób specjalnie przeznaczony do wspierania modelowania danych i przekształcania modeli danych w projekty baz danych.

LDDT obejmował hierarchię środowiskową (przestrzeń nazw), wiele poziomów modelu, modelowanie uogólnień / specjalizacji oraz wyraźną reprezentację relacji za pomocą kluczy podstawowych i obcych, wspieraną przez dobrze zdefiniowaną funkcję nazewnictwa ról. Klucze podstawowe i klucze obce o jednoznacznych nazwach ról wyrażały czasami subtelną wyjątkowość i więzy integralności, które musiały być znane i honorowane przez dowolny typ bazy danych, który został ostatecznie zaprojektowany. Decyzja o tym, czy w projekcie bazy danych wykorzystano klucze oparte na ograniczeniach integralności modelu LDDT jako klucze dostępu do bazy danych lub indeksy, było całkowicie odrębną decyzją. Precyzja i kompletność modeli LDDT była ważnym czynnikiem umożliwiającym stosunkowo płynne przekształcanie modeli w projekty baz danych. Wczesne modele LDDT zostały przekształcone w projekty baz danych dla hierarchicznej bazy danych IBM, IMS . Późniejsze modele zostały przekształcone w projekty baz danych dla sieciowej bazy danych Cullineta, IDMS i wielu odmian relacyjnych baz danych.

Oprogramowanie LDDT, ADAM, obsługiwane wprowadzanie widoku (modelu), łączenie widoków, przeglądanie selektywne (podzbiór), dziedziczenie przestrzeni nazw, normalizacja, analiza zapewniania jakości widoków, wykres relacji encji i generowanie raportów, transformacja do relacyjnej bazy danych wyrażona jako dane SQL deklaracje deklaracji i SQL sprawdzania integralności referencji. Modele logiczne zostały serializowane za pomocą języka modelowania strukturalnego.

Graficzna składnia LDDT różniła się od tej z IDEF1 i, co ważniejsze, LDDT zawierało wiele powiązanych ze sobą koncepcji modelowania, których nie ma w IDEF1. Dlatego zamiast rozszerzać IDEF1, Mary E. Loomis z DACOM napisała zwięzłe podsumowanie składni i semantyki znacznego podzbioru LDDT, używając terminologii zgodnej z IDEF1, gdy tylko było to możliwe. DACOM oznaczył wynik jako IDEF1X i dostarczył go do programu ICAM, który opublikował go w 1985 r. (IEEE 1998, s. Iii) (Bruce 1992, s. Xii) DACOM również przekształcił oprogramowanie ADAM w C i sprzedawał je pod nazwą Leverage .

Bloki konstrukcyjne IDEF1X

Składnia jednostki
Hierarchia domen
Przykład atrybutu
Składnia klucza podstawowego

Podmioty: Reprezentacja klasy rzeczy rzeczywistych lub abstrakcyjnych (ludzie, przedmioty, miejsca, zdarzenia, idee, kombinacja rzeczy itp.), Które są rozpoznawane jako instancje tej samej klasy, ponieważ mają te same cechy i mogą uczestniczyć w tych samych relacjach .
Domeny: Nazwany zestaw wartości danych (stałych lub prawdopodobnie nieskończonych) wszystkich tego samego typu danych, na podstawie których rysowana jest rzeczywista wartość dla instancji atrybutu. Każdy atrybut musi być zdefiniowany w dokładnie jednej podstawowej domenie. Wiele atrybutów może być opartych na tej samej podstawowej domenie.
Atrybuty: Właściwość lub cecha wspólna dla niektórych lub wszystkich wystąpień jednostki. Atrybut reprezentuje użycie domeny w kontekście jednostki.
Klucze: Atrybut lub kombinacja atrybutów jednostki, której wartości jednoznacznie identyfikują każdą instancję jednostki. Każdy taki zestaw stanowi klucz kandydujący.
Klucze podstawowe: Klucz kandydata wybrany jako unikalny identyfikator jednostki.
Klucz obcy: Atrybut lub kombinacja atrybutów instancji jednostki podrzędnej lub kategorii, której wartości są zgodne z wartościami w kluczu podstawowym powiązanej instancji jednostki nadrzędnej lub ogólnej. Klucz obcy można postrzegać jako wynik „migracji” klucza podstawowego jednostki nadrzędnej lub jednostki ogólnej za pośrednictwem określonego połączenia lub relacji kategoryzacji. Atrybutowi lub kombinacji atrybutów w kluczu obcym można przypisać nazwę roli odzwierciedlającą jej rolę w jednostce podrzędnej lub kategorii.

Składnia liczności relacji
Identyfikowanie składni relacji
Składnia relacji kategoryzacji
Niespecyficzna składnia relacji

Relacje: Skojarzenie między wystąpieniami dwóch jednostek lub między wystąpieniami tej samej encji.
Relacje połączeń: Relacja nie mająca żadnej semantyki poza skojarzeniem. Zobacz ograniczenie, liczność.
Relacje kategoryzacji: Relacja, w której wystąpienia obu bytów reprezentują tę samą rzeczywistą lub abstrakcyjną rzecz. Jedna jednostka (jednostka ogólna) reprezentuje kompletny zbiór rzeczy, druga (jednostka kategorii) reprezentuje podtyp lub podklasyfikację tych rzeczy. Encja kategorii może mieć jedną lub więcej cech lub relację z instancjami innej jednostki, która nie jest wspólna dla wszystkich instancji jednostki ogólnej. Każda instancja jednostki kategorii jest jednocześnie instancją jednostki ogólnej.
Niespecyficzne relacje: Relacja, w której jedna instancja jednej encji może być powiązana z dowolną liczbą instancji drugiej.
Zobacz poziomy: W IDEF1X zdefiniowano trzy poziomy widoku: relacje encji (ER), oparte na kluczach (KB) iw pełni przypisane (FA). Różnią się poziomem abstrakcji. Poziom ER jest najbardziej abstrakcyjny. Modeluje najbardziej fundamentalne elementy obszaru tematycznego - byty i ich relacje. Zwykle ma szerszy zakres niż inne poziomy. Poziom KB dodaje klucze, a poziom FA dodaje wszystkie atrybuty.

Tematy IDEF1X

Podejście oparte na trzech schematach

Podejście trzy schematu .

Podejście trzech schematów w inżynierii oprogramowania jest podejście do budowania systemów informacyjnych i systemów zarządzania informacją, że promuje model koncepcyjny jako klucz do osiągnięcia integracji danych .

Schemat jest modelem , zazwyczaj przedstawiany przez diagramie , a czasami towarzyszy opisu języka. Trzy schematy zastosowane w tym podejściu to:

Schemat zewnętrzny dla widoków użytkownika
Schemat koncepcyjny integruje zewnętrzne schematy
Schemat wewnętrzny definiujący fizyczne struktury pamięci.

W centrum, schemat pojęciowy definiuje ontologię z pojęciami jak użytkownicy o nich myśleć i mówić o nich. Schemat fizyczny opisuje wewnętrzne formaty danych przechowywanych w bazie danych , a schemat zewnętrzny określa widok danych prezentowanych aplikacjom . Framework próbował pozwolić na użycie wielu modeli danych dla zewnętrznych schematów.

Wytyczne dotyczące modelowania

Syntetyzacja bytu w fazie pierwszej - definicja bytu

Proces modelowania można podzielić na pięć etapów tworzenia modelu.

Faza zero - rozpoczęcie projektu

Cele fazy inicjacji projektu obejmują:

Definicja projektu - ogólne stwierdzenie, co należy zrobić, dlaczego i jak to zostanie zrobione
Materiał źródłowy - plan pozyskania materiału źródłowego, w tym indeksowanie i archiwizacja
Konwencje autorskie - podstawowa deklaracja konwencji (metod opcjonalnych), według których autor decyduje się na tworzenie modelu i zarządzanie nim.

Faza pierwsza - definicja encji: Celem fazy definiowania encji jest zidentyfikowanie i zdefiniowanie jednostek wchodzących w zakres modelowanej domeny problemu.

Faza druga - definicja relacji

Celem fazy definiowania relacji jest identyfikacja i zdefiniowanie podstawowych relacji między podmiotami. Na tym etapie modelowania niektóre relacje mogą być niespecyficzne i wymagać dopracowania w kolejnych fazach. Podstawowe dane wyjściowe z fazy drugiej to:

Macierz relacji
Definicje relacji
Diagramy na poziomie jednostki.

Macierz relacji encji
Diagram na poziomie jednostki
Przykład diagramu na poziomie jednostki
Schemat odniesienia

Faza trzecia - kluczowe definicje

Cele fazy kluczowych definicji to:

Uściślij niespecyficzne relacje z fazy drugiej
Zdefiniuj kluczowe atrybuty dla każdej jednostki
Przeprowadź migrację kluczy podstawowych, aby ustanowić klucze obce
Sprawdź relacje i klucze.

Przykładowy schemat referencyjny
Niespecyficzne zawężenie relacji
Zakres widoku funkcji
Przykłady atrybutów
Udoskonalenie reguły bez powtórzeń
Udoskonalenie reguł
Asercje dotyczące ścieżki
Przykład schematu widoku funkcji fazy trzeciej

Faza czwarta - definicja atrybutu

Celem fazy definiowania atrybutu jest:

Opracuj pulę atrybutów
Ustal własność atrybutu
Zdefiniuj atrybuty małpy
Sprawdź i dopracuj strukturę danych.

Stosowanie zasady braku powtórzeń
Przykład funkcji fazy czwartej

Meta model IDEF1X

Meta model IDEF1X.

Meta model to model konstrukcji systemu modelowania. Jak każdy model służy do przedstawiania i rozumowania tematu modelu - w tym przypadku IDEF1X. Meta model służy do wnioskowania o IDEF1X, tj. Jakie są konstrukcje IDEF1X i jak są ze sobą powiązane. Przedstawiony model to model IDEF1X IDEF1X. Takie metamodele mogą być używane do różnych celów, takich jak projektowanie repozytorium, projektowanie narzędzi lub w celu określenia zestawu prawidłowych modeli IDEF1X. W zależności od celu powstają nieco inne modele. Nie ma „jednego właściwego modelu”. Na przykład model narzędzia, które obsługuje budowanie modeli przyrostowo, musi dopuszczać modele niekompletne lub nawet niespójne. Meta model formalizacji kładzie jednak nacisk na zgodność z koncepcjami formalizacji, a zatem niekompletne lub niespójne modele są niedozwolone.

Meta modele mają dwa ważne ograniczenia. Najpierw określają składnię, ale nie semantykę. Po drugie, meta model musi zostać uzupełniony o ograniczenia w języku naturalnym lub formalnym. Formalna teoria IDEF1X zapewnia zarówno semantykę, jak i środki do precyzyjnego wyrażenia niezbędnych ograniczeń.

Meta model dla IDEF1X jest podany na sąsiednim rysunku. Nazwa widoku to mm . Podana jest również hierarchia domen i ograniczenia. W formalnej teorii metamodelu ograniczenia są wyrażone jako zdania. Meta model nieformalnie definiuje zestaw prawidłowych modeli IDEF1X w zwykły sposób, jako przykładowe tabele instancji, które odpowiadają poprawnemu modelowi IDEF1X. Meta model również formalnie definiuje zbiór prawidłowych modeli IDEF1X w następujący sposób. Meta model, jako model IDEF1X, ma odpowiednią teorię formalną. Semantyka teorii jest zdefiniowana w standardowy sposób. Oznacza to, że interpretacja teorii składa się z domeny jednostek i zestawu zadań:

Do każdej stałej w teorii przypisana jest jednostka w dziedzinie
Do każdego n-arnego symbolu funkcji w teorii przypisana jest n-arna funkcja w dziedzinie
Do każdego n-arnego symbolu predykatu w teorii przypisana jest n-arna relacja w dziedzinie.

W zamierzonej interpretacji domena jednostek składa się z poglądów, takich jak produkcja; podmioty, takie jak część i sprzedawca; domeny, takie jak qty_on_hand; relacje połączeń; klastry kategorii; i tak dalej. Jeśli każdy aksjomat teorii jest prawdziwy w interpretacji, wówczas interpretację nazywa się modelem teorii. Każdy model dla teorii IDEF1X odpowiadający metamodelowi IDEF1X i jego ograniczeniom jest prawidłowym modelem IDEF1X.

Zobacz też

Bibliografia

Ten artykuł zawiera materiały należące do domeny publicznej z witryny National Institute of Standards and Technology https://www.nist.gov .

Dalsza lektura

Thomas A. Bruce (1992). Projektowanie wysokiej jakości baz danych z modelami informacyjnymi Idef1X . Wydawnictwo Dorset House.
Y. Tina Lee i Shigeki Umeda (2000). „Model informacyjny IDEF1x do symulacji łańcucha dostaw” .

Linki zewnętrzne

ISO / IEC / IEEE 31320-2: 2012
Publikacja FIPS 184 ogłaszająca standard IDEF1X grudzień 1993 przez Computer Systems Laboratory of the National Institute of Standards and Technology (NIST). (Wycofany przez NIST 08 września 02, patrz Wycofany FIPS według Numerical Order Index )
Federal Register vol. 73 / strona 51276 decyzja o wycofaniu
Przegląd IDEF1X na www.idef.com
Przegląd IDEF1X firmy Essential Strategies, Inc.

Languages

In other projects