IDEF1X

Przykład diagramu IDEF1X.

Integration DEFinition for information modeling (IDEF1X) to język modelowania danych służący do tworzenia semantycznych modeli danych . IDEF1X służy do tworzenia graficznego modelu informacyjnego , który przedstawia strukturę i semantykę informacji w środowisku lub systemie .

IDEF1X pozwala na 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ą IDEF w dziedzinie inżynierii oprogramowania .

Przegląd

Technika modelowania danych służy do modelowania danych w standardowy, spójny i przewidywalny sposób w celu zarządzania nimi jako zasobem. Może być stosowany w projektach wymagających standardowego sposobu definiowania i analizowania zasobów danych w organizacji. Takie projekty obejmują włączenie modelowania danych do metodologii , zarządzanie danymi jako zasobem, integrację systemów informatycznych lub projektowanie komputerowych baz danych . Podstawowe cele standardu IDEF1X to zapewnienie:

Środki do pełnego zrozumienia i analizy zasobów danych organizacji
Typowe sposoby przedstawiania i komunikowania złożoności danych
Technika przedstawiania całościowego obrazu danych potrzebnych do prowadzenia przedsiębiorstwa
Środki do definiowania niezależnego od aplikacji widoku danych, który może zostać zweryfikowany przez użytkowników i przekształcony w projekt fizycznej bazy danych
Technika uzyskiwania 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 wykorzystywaniu pojedynczej semantycznej definicji zasobu danych, określanej jako „ schemat pojęciowy” . ”. „Schemat pojęciowy” 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. Głównym celem tego schematu pojęciowego jest zapewnienie spójnej definicji znaczeń i wzajemnych relacji między danymi, które można wykorzystać do integracji, udostępniania i zarządzania integralnością danych. Schemat pojęciowy musi mieć trzy ważne cechy:

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

Historia

Potrzeba semantycznych modeli danych została po raz pierwszy zauważona 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 zidentyfikował potrzebę lepszych technik analizy i komunikacji dla osób zaangażowanych w poprawę wydajności produkcji. W rezultacie program ICAM opracował szereg technik znanych jako metody IDEF (ICAM Definition), które obejmowały:

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

Wstępne podejście do modelowania informacji IDEF (IDEF1) zostało opublikowane przez program ICAM w 1981 r. w oparciu o aktualne potrzeby badawcze i branżowe. Teoretyczne korzenie tego podejścia wywodziły się z wczesnych prac Edgara F. Codda na temat teorii modeli relacyjnych i Petera Chena na temat modelu relacji między jednostkami . Początkowa technika IDEF1 była oparta na pracy dr RR Browna i pana TL Rameya z Hughes Aircraft i pana DS Colemana z D. Appleton Company (DACOM), z krytyczną recenzją i wpływem Charlesa Bachmana , Petera Chena , dr MA Melkanoff 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 dostarczenie technologii umożliwiającej logiczną i fizyczną integrację sieci heterogenicznego sprzętu komputerowego i oprogramowania. W wyniku tego projektu i doświadczeń branżowych uznano potrzebę udoskonalonej techniki modelowania informacji.

Z punktu widzenia administratorów kontraktowych programu Air Force IDEF, IDEF1X był wynikiem projektu ICAM IISS-6201 i został rozszerzony przez projekt IISS-6202. Aby spełnić wymagania dotyczące ulepszeń modelowania danych, które zostały określone w projekcie IISS-6202, podwykonawca, DACOM, uzyskał licencję na Logical Database Design Technique (LDDT) i towarzyszące mu oprogramowanie (ADAM). Z punktu widzenia treści technicznej techniki modelowania, IDEF1X jest przemianowaniem LDDT.

W dniu 2 września 2008 r. powiązany standard NIST, FIPS 184, został wycofany (decyzja w sprawie Rejestru Federalnego t. 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 „w stylu klucza” kompatybilnego w dół z FIPS 184, który obsługuje relacyjne i rozszerzone relacyjne bazy danych, oraz nowszego języka „w stylu tożsamości” odpowiedniego dla obiektowe bazy danych i modelowanie obiektowe.

Logiczna technika projektowania 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 ze świata rzeczywistego. LDDT połączył elementy relacyjnego modelu danych, modelu ER i uogólnienia danych w sposób specjalnie przeznaczony do wspierania modelowania danych i przekształcania modeli danych w projekty baz danych.

LDDT obejmował hierarchię środowiskową (przestrzeni nazw), wiele poziomów modelu, modelowanie uogólnienia/specjalizacji oraz wyraźną reprezentację relacji za pomocą kluczy podstawowych i obcych, wspieraną przez dobrze zdefiniowane narzędzie nazewnictwa ról. Klucze podstawowe i klucze obce o jednoznacznie nazwanych rolach wyrażały czasami subtelną wyjątkowość i ograniczenia integralności referencyjnej, które musiały być znane i honorowane przez każdy ostatecznie zaprojektowany typ bazy danych. To, czy projekt bazy danych wykorzystywał klucze oparte na ograniczeniu integralności modelu LDDT jako klucze dostępu do bazy danych lub indeksy, było całkowicie oddzielną decyzją. Precyzja i kompletność modeli LDDT była ważnym czynnikiem umożliwiającym stosunkowo płynne przekształcenie 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 Cullinet, IDMS i wielu odmian relacyjnych baz danych.

Oprogramowanie LDDT, ADAM, obsługiwane wprowadzanie widoków (modeli), łączenie widoków, przeglądanie selektywne (podzbiorów), dziedziczenie przestrzeni nazw, normalizacja, analiza zapewniania jakości widoków, generowanie wykresów relacji encji i raportów, transformacja do relacyjnej bazy danych wyrażonej jako dane SQL deklaracje i sprawdzanie integralności referencyjnej SQL. Modele logiczne zostały zserializowane za pomocą języka modelowania strukturalnego.

Graficzna składnia LDDT różniła się od składni IDEF1, a 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 tam, gdzie to możliwe, terminologii zgodnej z IDEF1. DACOM oznaczył wynik IDEF1X i dostarczył go do programu ICAM, który opublikował go w 1985 r. (IEEE 1998, s. iii) (Bruce 1992, s. xii) DACOM przekonwertował również oprogramowanie ADAM na C i sprzedał je pod nazwą Leverage .

Bloki konstrukcyjne IDEF1X

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

Byty: Reprezentacja klasy rzeczywistych lub abstrakcyjnych rzeczy (ludzi, przedmiotów, miejsc, zdarzeń, idei, kombinacji rzeczy itp.), które są uznawane za instancje tej samej klasy, ponieważ mają te same cechy i mogą uczestniczyć w tym samym relacje.
Domeny: Nazwany zestaw wartości danych (stała lub nieskończona liczba) wszystkich tego samego typu danych, na podstawie których rysowana jest rzeczywista wartość instancji atrybutu. Każdy atrybut musi być zdefiniowany dokładnie w jednej podstawowej domenie. Wiele atrybutów może być opartych na tej samej domenie bazowej.
Atrybuty: Właściwość lub cecha, która jest wspólna dla niektórych lub wszystkich instancji jednostki. Atrybut reprezentuje użycie domeny w kontekście encji.
Klucze: Atrybut lub kombinacja atrybutów encji, której wartości jednoznacznie identyfikują każdą instancję encji. Każdy taki zestaw stanowi klucz kandydujący.
Klucze podstawowe: Klucz kandydujący 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 ogólnej poprzez określone połączenie lub relację kategoryzacji. Atrybutowi lub kombinacji atrybutów w kluczu obcym można przypisać nazwę roli odzwierciedlającą jego rolę w jednostce podrzędnej lub kategorii.

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

Relacje: Powiązanie między instancjami dwóch encji lub między instancjami tej samej encji.
Relacje połączeń: Relacja nie posiadająca żadnej semantyki poza skojarzeniem. Zobacz ograniczenie, kardynalność.
Relacje kategoryzacji: Relacja, w której instancje obu bytów reprezentują tę samą rzeczywistą lub abstrakcyjną rzecz. Jedna jednostka (jednostka ogólna) reprezentuje pełny zestaw rzeczy, druga (encja kategorii) reprezentuje podtyp lub podklasyfikację tych rzeczy. Jednostka kategorii może mieć jedną lub więcej cech lub związek z instancjami innej jednostki, które nie są wspólne dla wszystkich instancji jednostek ogólnych. Każda instancja encji kategorii jest jednocześnie instancją encji ogólnej.
Relacje niespecyficzne: Relacja, w której instancja jednej jednostki może być powiązana z dowolną liczbą instancji drugiej.
Zobacz poziomy: W IDEF1X zdefiniowano trzy poziomy widoku: relacja encji (ER), oparty na kluczach (KB) i w pełni przypisany (FA). Różnią się poziomem abstrakcji. Poziom ER jest najbardziej abstrakcyjny. Modeluje najbardziej podstawowe elementy obszaru tematycznego - podmioty i ich relacje. Zwykle ma szerszy zakres niż inne poziomy. Poziom KB dodaje klucze, a poziom FA dodaje wszystkie atrybuty.

Tematy IDEF1X

Podejście trzech schematów

na trzech schematach .

Podejście oparte na trzech schematach w inżynierii oprogramowania to podejście do budowania systemów informatycznych i zarządzania informacjami w systemach, które promuje model koncepcyjny jako klucz do osiągnięcia integracji danych .

Schemat to model , zwykle przedstawiony na diagramie , któremu czasem towarzyszy opis w języku. Trzy schematy stosowane w tym podejściu to:

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

W centrum schemat pojęciowy definiuje ontologię pojęć , gdy użytkownicy myślą o nich i rozmawiają o nich. Schemat fizyczny opisuje wewnętrzne formaty danych przechowywanych w bazie danych , a schemat zewnętrzny definiuje widok danych prezentowanych programom użytkowym . Ramy próbowały zezwolić na użycie wielu modeli danych w zewnętrznych schematach.

Wytyczne dotyczące modelowania

Syntetyzowanie bytu w fazie pierwszej – definicja bytu

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

Faza zerowa – Inicjacja projektu

Cele fazy inicjowania 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 indeksowania i archiwizacji
Konwencje autorskie – podstawowa deklaracja konwencji (opcjonalnych metod), według których autor decyduje się na wykonanie modelu i zarządzanie nim.

Faza pierwsza – definicja encji: Celem fazy definicji encji jest zidentyfikowanie i zdefiniowanie encji, które mieszczą się w modelowanej domenie problemu.

Faza druga – definicja relacji

Celem fazy definicji relacji jest zidentyfikowanie i zdefiniowanie podstawowych relacji pomiędzy podmiotami. Na tym etapie modelowania niektóre zależności mogą być niespecyficzne i będą wymagały dodatkowego dopracowania w kolejnych fazach. Podstawowe wyniki fazy drugiej to:

Macierz relacji
Definicje relacji
Diagramy na poziomie jednostki.

Macierz relacji encji
Diagram poziomu jednostki
Przykład diagramu poziomu 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
Migruj klucze podstawowe, aby ustanowić klucze obce
Sprawdź relacje i klucze.

Przykładowy schemat referencyjny
Niespecyficzne udoskonalanie relacji
Zakres widoku funkcji
Przykłady atrybutów
Udoskonalenie reguły bez powtórzeń
Udoskonalenie reguły
Asercje ścieżki
Przykład diagramu widoku funkcji fazy trzeciej

Faza czwarta - definicja atrybutu

Cele fazy definiowania atrybutów to:

Opracuj pulę atrybutów
Ustal własność atrybutu
Zdefiniuj atrybuty małpy
Zweryfikuj i uściślij strukturę danych.

Stosowanie zasady „nie powtarzaj się”.
Przykład funkcji fazy czwartej

Metamodel IDEF1X

Metamodel IDEF1X.

Metamodel to model konstrukcji systemu modelowania. Jak każdy model, służy do reprezentowania i wnioskowania o przedmiocie modelu - w tym przypadku IDEF1X. Metamodel jest używany do wnioskowania na temat IDEF1X, tj. czym są konstrukty IDEF1X i jak odnoszą się do siebie. Przedstawiony model to model IDEF1X z IDEF1X. Takie metamodele mogą być wykorzystywane do różnych celów, takich jak projektowanie repozytoriów, 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 słusznego modelu”. Na przykład model narzędzia obsługującego stopniowe budowanie modeli musi umożliwiać tworzenie niekompletnych lub nawet niespójnych modeli. Jednak metamodel formalizacji kładzie nacisk na zgodność z koncepcjami formalizacji, dlatego modele niekompletne lub niespójne są niedozwolone.

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

Metamodel dla IDEF1X przedstawiono na sąsiednim rysunku. Nazwa widoku to mm . Podano również hierarchię domen i ograniczenia. W formalnej teorii metamodelu ograniczenia są wyrażone jako zdania. Metamodel nieformalnie definiuje zestaw prawidłowych modeli IDEF1X w zwykły sposób, jako przykładowe tabele instancji odpowiadające prawidłowemu modelowi IDEF1X. Metamodel również formalnie definiuje zestaw prawidłowych modeli IDEF1X w następujący sposób. Metamodel, jako model IDEF1X, ma odpowiednią teorię formalną. Semantyka teorii jest zdefiniowana w sposób standardowy. Oznacza to, że interpretacja teorii składa się z dziedziny jednostek i zbioru przypisań:

Do każdej stałej w teorii przypisany jest osobnik w dziedzinie
Każdemu symbolowi funkcji n-arnej w teorii przypisuje się funkcję n-arną w dziedzinie
Każdemu n-arnemu symbolowi predykatu w teorii przypisywana jest n-arna relacja w dziedzinie.

W zamierzonej interpretacji domeną jednostek są poglądy, takie 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 w teorii jest prawdziwy w interpretacji, wówczas interpretacja nazywana jest modelem dla teorii. Każdy model dla teorii IDEF1X odpowiadający metamodelowi IDEF1X i jego ograniczeniom jest poprawnym modelem IDEF1X.

Zobacz też

Ten artykuł zawiera materiały należące do domeny publicznej z Narodowego Instytutu Standardów i Technologii .

Dalsza lektura

Thomas A. Bruce (1992). Projektowanie jakościowych baz danych za pomocą modeli informacyjnych 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 r., wydana przez Laboratorium Systemów Komputerowych Narodowego Instytutu Standardów i Technologii (NIST). (Wycofane przez NIST 08 września 2002 r., patrz Wycofane FIPS według indeksu porządku numerycznego )
Rejestr Federalny tom. 73/strona 51276 decyzja cofnięcia
Przegląd IDEF1X zarchiwizowany 08.03.2016 w Wayback Machine na www.idef.com
Przegląd IDEF1X firmy Essential Strategies, Inc.