Logisches Datenmodell

SHARE THE ARTICLE ON

Logisches Datenmodell Logisches Datenmodell-Voxco
Table of Contents

Ein logisches Datenmodell ist ein unspezifisches Datenbankmodell, das die Objekte, über die ein Unternehmen Daten sammeln möchte, und die Beziehungen zwischen diesen Objekten beschreibt.

Ein Wurzelpaketobjekt enthält immer Objekte des logischen Modells. Normalerweise gibt es ein Wurzelpaket, aber wir können zusätzliche Pakete unter dem Wurzelpaket hinzufügen, um ähnliche Objekte zusammenzufassen.

Was ist ein logisches Datenmodell?

Ein logisches Datenmodell definiert die Struktur von Datenteilen sowie die Beziehungen zwischen ihnen. Es unterscheidet sich von der physischen Datenbank, die angibt, wie die Daten implementiert werden. Das logische Datenmodell dient als Plan für die Daten, die verwendet werden. Das logische Datenmodell erweitert die Konzepte der konzeptionellen Datenmodellierung, indem es mehr Informationen enthält.

Das logische Datenmodell fasst alle Informationen zusammen, die für den täglichen Betrieb des Unternehmens wichtig sind.

Leitfaden für die Sondierungsforschung

Die Durchführung von Sondierungsforschung scheint schwierig zu sein, aber ein effektiver Leitfaden kann helfen.

Komponenten des logischen Datenmodells

Ein logisches Datenmodell setzt sich aus drei Hauptkomponenten zusammen:

Entitäten

Eine Person, ein Ort, ein Objekt, ein Ereignis oder ein Begriff, der für einen Einzelhändler von Interesse ist, wird durch einen Entitätstyp dargestellt. Kunden, Artikel, Einzelhandelsgeschäft, Website, Bestellung, Einzelhandelstransaktion und Hunderte von weiteren Substantiven sind Beispiele für Entitäten. Jeder Entitätstyp im ARTS-Datenmodell wird in betriebswirtschaftlichen Begriffen beschrieben. Entitätstypen werden als Rechtecke in einem Entitätsdiagramm dargestellt. Jeder Entitätstyp erhält eine eindeutige, singuläre Substantivphrase als Namen. Jede Entitätstyp-Instanz in einer relationalen Datenarchitektur ist durch einen Primärschlüssel eindeutig identifizierbar. Ein Primärschlüssel ist eine oder mehrere Eigenschaften mit Werten, die zur eindeutigen Identifizierung und Unterscheidung einer Entitätstyp-Instanz von den anderen verwendet werden.

Attribute

Ein Attribut identifiziert, kennzeichnet und spezifiziert ein Merkmal oder eine Eigenschaft einer Entitätsart. Ein Item-Entitätstyp enthält z. B. ein ItemID-Attribut, um ihn eindeutig zu identifizieren. Er enthält eine Eigenschaft Name, die in Katalogen und Etiketten verwendet wird. Er enthält unter anderem eine Eigenschaft Description. Attribute sind die grundlegendsten Komponenten eines Datenmodells. Sie können nicht in untergeordnete Komponenten unterteilt werden. Ein Attribut in einem relationalen Datenmodell kann nicht unabhängig von einem Entitätstyp existieren. Daher werden alle Merkmale immer als Teil von Entitätstypen identifiziert und dargestellt.

Ein Primärschlüssel, wie unter Entitätstyp erläutert, besteht aus einer oder mehreren Eigenschaften und dient als eindeutiger Instanzbezeichner des Entitätstyps.

Beziehungen

Eine Beziehung identifiziert, kennzeichnet und spezifiziert eine Verbindung zwischen zwei Arten von Entitäten. Eine Beziehung verbindet immer zwei und nur zwei Arten von Entitäten. Verbphrasen werden verwendet, um Beziehungsnamen anzugeben. Beziehungsphrasen können für beide Richtungen einer Beziehung zwischen zwei Dingen definiert werden. Die Entitätstypen, die durch eine Beziehung verbunden sind, bieten zwei Funktionen: Eine übergeordnete Entität ist eine einzelne Entität. Eine untergeordnete Entität ist die zweite Entität. Die übergeordnete Entität und die untergeordnete Entität haben die gleiche Identität. Der untergeordnete Entitätstyp wird als abhängiger Entitätstyp bezeichnet, weil er den Hauptschlüssel des übergeordneten Entitätstyps erbt. Ein Fremdschlüssel ist ein Attribut, das von einem übergeordneten und einem untergeordneten Entitätstyp gemeinsam genutzt wird. Ein Attributname in einem Entitätsdiagramm ist ein Fremdschlüssel, der mit dem Suffix „(FK)“ gekennzeichnet ist.

Ein übergeordneter und ein untergeordneter Entitätstyp können in einer relationalen Datenarchitektur auf zwei Arten miteinander verbunden sein. Die erste Methode ist eine identifizierende Beziehung. Eine identifizierende Verbindung zeigt an, dass der Hauptschlüssel der untergeordneten Entität von ihrem übergeordneten Entitätstyp geerbt wird. Das heißt, dass die Existenz des untergeordneten Entitätstyps vom Vorhandensein des übergeordneten Entitätstyps abhängt. Wenn der übergeordnete Entitätstyp in diesem Fall zerstört wird, wird auch das Kind gelöscht. Ein untergeordneter Entitätstyp kann dagegen erst eingegeben werden, wenn der übergeordnete Entitätstyp, auf den er sich bezieht, eingefügt ist. Eine identifizierende Verbindung wird in einem Entitätsdiagramm durch eine durchgezogene Linie dargestellt, die den übergeordneten und den untergeordneten Entitätstyp verbindet.

Eine nicht-identifizierende Verbindung ist die zweite Methode, mit der übergeordnete und untergeordnete Entitätstypen verbunden werden können. Bei einer nicht-identifizierenden Verbindung wird der Primärschlüssel der übergeordneten Entität als Nicht-Primärschlüssel-Eigenschaft an das untergeordnete Objekt vererbt. Dies bedeutet, dass sich die untergeordnete Entität auf ihren übergeordneten Entitätstyp bezieht, aber nicht von der Existenz der übergeordneten Entität abhängig ist. Aus der Sicht einer relationalen Datenbank bedeutet dies, dass die geerbte Eigenschaft null sein kann – das heißt, sie könnte auf nichts verweisen. Eine nicht identifizierende Verbindung wird in einem Entitätsdiagramm durch eine gestrichelte Linie dargestellt, die den übergeordneten und den untergeordneten Entitätstyp verbindet.

Die Kardinalität ist ein zusätzliches Merkmal zwischen Eltern- und Kind-Entitätstypen, das in Beziehungen einbezogen wird. Die Kardinalität gibt die Anzahl der Vorkommen eines untergeordneten Entitätstyps an, die für einen übergeordneten Entitätstyp existieren können. Eine Marke kann sich beispielsweise auf null, eine oder viele Instanzen des Entitätstyps Element beziehen. Im Gegensatz dazu kann ein Element entweder durch null oder eine Marke bezeichnet werden. Die folgende Grafik zeigt diese Kardinalitäten. Die Kardinalität kann auf verschiedene Weise ausgedrückt werden, um die relative Anzahl der übergeordneten Entitätstypen zu den untergeordneten Entitätstypen zu vermitteln.

Die folgende Grafik zeigt eine NICHT IDENTIFIZIERENDE Verknüpfung zwischen Artikel und Marke. Sie zeigt auch, wie Fremdschlüssel und Kardinalität in einem Entitätsdiagramm dargestellt werden können. Sie fügt Owned Attributes hinzu, d. h. Attribute, die NICHT von einem anderen Entitätstyp geerbt werden und nicht Teil des Hauptschlüssels eines Entitätstyps sind.

Zusätzlich zur Kardinalität gibt es eine Subtyp-Verbindung, die es zahlreichen untergeordneten Entitätstypen ermöglicht, Attribute von einem gemeinsamen übergeordneten Entitätstyp zu erben. Dies wird im folgenden Diagramm dargestellt. Der gelbe Block stellt die Definition einer Retail-Transaktion dar. Ein RetailTransaction, wie hier dargestellt, kann null, ein oder viele RetailTransactionLineItem-Entitätsobjekte haben, die mit ihm verbunden sind. Da ein Einzelposten nicht ohne einen RetailTransaktionskopf existieren kann, sind die RetailTransactionLineItem-Entitäten voneinander abhängig.

Der Entitätstyp RetailTransactionLineItem kann erweitert werden, um Verkaufsdaten als SaleReturnLineItem, Rabattdaten für ein Einzelhandelsgeschäft als DiscountLineItem, Steuerdaten als TaxLineItem oder Zahlungsdaten als TenderLineItem aufzuzeichnen. Ein RetailTransactionLineItem hat eine Reihe von Eigenschaften (einschließlich der Positionsnummer), die von allen Subtypen gemeinsam genutzt werden (d. h. von den Kindern des Subtyps geerbt werden können). Eine Instanz des Entitätstyps RetailTransactionLineItem kann nur einen Subtyp haben. Diese relationale Idee des Subtyps ist mit der Vererbung im objektorientierten Design verwandt, die zur Beschreibung von Klassen und Objekten verwendet wird. Die untergeordneten Entitätstypen des Subtyps beschreiben effizient eine Einzelhandelstransaktion und die vielen Arten von Einzelposten, die in diesem Beispiel zur Erfassung von Artikel-, Rabatt-, Steuer- und Angebotsdaten erforderlich sind. Der Beispielbon zeigt, wie jeder Subtyp von RetailTransactionLineItem verschiedene Bonpositionen widerspiegelt.

Domains

Eine Domäne ist eine Art von Datendarstellung, die benannt ist und sich auf ein oder mehrere Merkmale beziehen kann. Die Datendarstellung spezifiziert einen Datentyp, z. B. einen Ganzzahl-, Text-, Fließkomma-, Datums-, Zeit- oder anderen Standarddatentyp, oder eine erweiterte Definition, die einem Basisdatentyp bestimmte Merkmale und Einschränkungen hinzufügt. Domänen ermöglichen die Erstellung von handelsspezifischen Datentypen aus SQL-Basisdatentypen. Zum Beispiel hat ARTS einen IdentityGTIN-Domänentyp, der wie folgt beschrieben wird: Eine Identifikation für Artikel am POS – UCC/EAN definiert Global Trade Item Number (GTIN). Die IdentityGTIN basiert auf einem VARCHAR(14)-Basisdatentyp, der von der großen Mehrheit der SQL-Standarddatenbanken unterstützt wird. Domänen können auch verwendet werden, um die Werte einzuschränken, die einem Attribut in einer Domäne zugewiesen werden können. Beispielsweise sind Flaggen-Domänen auf die beiden Werte „YES“ oder „NO“ beschränkt.

Wozu braucht man ein logisches Datenmodell ?

Da Daten der wichtigste Teil jeder Anwendung, jedes Programms oder Systems sind, müssen hochwertige Datenverarbeitungs- und Speichersysteme auf einer soliden und zuverlässigen Datenstruktur basieren. Eine solide Datenstruktur ermöglicht es den Anwendungsentwicklern, die bestmögliche Benutzeroberfläche, das bestmögliche Verarbeitungssystem oder die bestmögliche statistische Analyse- und Berichtseinrichtung zu schaffen.

Unabhängig davon, wie ausgeklügelt oder komplex unser System ist, muss es Kriterien erfüllen, Vorschriften einhalten und den Zielen des Geschäfts oder Unternehmens dienen, für das es entwickelt wurde – andernfalls ist es nutzlos. Folglich vereint die logische Datenmodellierung die beiden wichtigsten Grundlagen der Anwendungsentwicklung:

  • Geschäftsanforderungen
  • Qualität der Datenstruktur

Merkmale des logischen Datenmodells

Im Folgenden sind die wichtigsten Merkmale eines logischen Datenmodells aufgeführt:

  • Ein logisches Datenmodell kann die Datenanforderungen für jedes Projekt erklären. Es ist jedoch so konzipiert, dass es sich mühelos mit anderen logischen Datenmodellen verbinden lässt, wenn das Projekt dies erfordert.
  • Die Entwicklung und Gestaltung eines logischen Datenmodells kann unabhängig vom Datenbankmanagementsystem erfolgen. Es ist unabhängig von der Art des Datenbankmanagementsystems.
  • Zu den Datenmerkmalen gehören bestimmte Längen und Genauigkeiten für Datentypen.
  • Bei der logischen Datenmodellierung wird kein Haupt- oder Nebenschlüssel festgelegt. Auf dieser Ebene der Datenmodellierung ist es notwendig, die Verbindungsmerkmale, die vor der Erstellung der Beziehungen festgelegt wurden, zu überprüfen und fein abzustimmen.
  • Ein logisches Datenmodell ist eine grafische Darstellung der Informationsanforderungen eines Unternehmens. Es handelt sich dabei nicht um eine Datenbank oder ein Datenbankverwaltungssystem an und für sich.
  • Ein logisches Datenmodell unterscheidet sich von einem physischen Datenspeicher, wie z. B. einem Dateisystem.
  • Ein logisches Datenmodell muss technologieunabhängig konzipiert sein, um von schnellen technologischen Entwicklungen unberührt zu bleiben.

See Voxco survey software in action with a Free demo.

Semantik des Datenmodells

Semantik ist die Lehre von der Bedeutung in Sprachen und Logik. Logische Modelle definieren nicht nur Entitäten, Eigenschaften, Verbindungen und Domänen, sondern klären auch, was jede Instanz dieser Objekte bedeutet. Diese Definitionen stellen die semantische Substanz eines Datenmodells dar und sind entscheidend für die kommerzielle Relevanz eines relationalen Modells. Die folgende Grafik zeigt die Zuweisung einer Definition zum ItemID-Attribut. Definitionen sollten in der Geschäftssprache verfasst sein und die Geschäftsideen widerspiegeln, die durch eine Datenmodellentität, ein Attribut, eine Beziehung, eine Domäne oder andere Modellobjekte dargestellt werden.

Warum ein Datenmodell entwickeln?

Datenmodelle sind nicht nur etwas für IT-Experten. In der heutigen Geschäftswelt sind Datenmodelle für den Betrieb eines Einzelhandelsunternehmens erforderlich.

Die Verwendung von Informationen als Währung und Vermögenswert

Im einundzwanzigsten Jahrhundert geht es im Einzelhandel ebenso sehr um die Verwaltung von Informationen wie um die Verwaltung von Bargeld, Produkten, Kunden, Geschäften, Lieferanten und anderen „realen“ Unternehmensressourcen. Da sie nicht jede Verkaufsstelle besuchen und überwachen können, sind die meisten Entscheidungsträger im Einzelhandel auf Informationen angewiesen, um ihre Auswahl zu treffen. Um wertvoll zu sein, müssen Informationen erkannt, beschriftet, charakterisiert und in eine logische Struktur gebracht werden, die die Entscheidungsträger verstehen können. Die Datenmodellierung bietet eine Reihe von Werkzeugen und Techniken zur Umwandlung von Informationen in aussagekräftige Daten.

Die Formalität und Disziplin der Datenmodellierung sind entscheidend dafür, welche Einzelhandelsberichte die Entscheidungsträger wirklich informieren. Schauen Sie sich die Begriffe Artikel, Artikel, Produkt, SKU und Handelsware an. Jeder dieser Begriffe hat für verschiedene Menschen unterschiedliche Bedeutungen. Durch die Spezifizierung der einzelnen Entitätstypen legt das Datenmodell fest, was jedes Wort bedeutet. Wenn einige Wörter als Synonyme verwendet werden, werden sie eindeutig als solche angegeben. Dies wird als geregeltes Vokabular bezeichnet und ist ein wichtiger Aspekt der Datenmodellierung, der einen Mehrwert darstellt. Es schafft eine Standardsprache für Einzelhandelsunternehmen und Einzelpersonen, um durch die Verwendung spezifisch spezifizierter Terminologie zu kommunizieren.

Fehlinterpretation und inkonsistente Semantik Kosten

Einzelhändler müssen ein kompliziertes Beziehungsgeflecht aus Verbrauchern, Lieferanten, Steuerbehörden, Aufsichtsbehörden, Arbeitnehmern und einer Vielzahl anderer Parteien verwalten. Einzelhändler, die nicht über eine einheitliche Standardmethode zur Identifizierung, Benennung, Definition und Beschreibung von Dingen, Angebotsarten, Steuergesetzen, Werbeaktionen, Lieferantenangeboten usw. verfügen, können kostspielige Fehler bei der Transaktionsverarbeitung machen. Die Genauigkeit der Daten hat einen klaren und unverkennbaren Einfluss auf das Endergebnis. Wenn ein bestellter Artikel nicht korrekt mit dem Produktcode im Katalog des Anbieters übereinstimmt und die Bestellung aufgegeben wird, wird er jemandem (dem Verbraucher, Einzelhändler, Anbieter usw.) in Rechnung gestellt. Durch die Forderung nach einem relationalen Modell in dritter Normalform verringert das Datenmodell diese Gefahr, indem es auf einer konsistenten Darstellung jedes Datenelements an einer einzigen Stelle im Datenmodell besteht. Ein ähnliches Problem stellt sich bei der Erstellung von Berichten. Einzelhändler, denen eine Standardmethode zur Identifizierung, Benennung und Beschreibung von Entitäten, Merkmalen und Beziehungen fehlt, verschwenden viel Zeit und Geld mit dem Abgleich inkonsistenter zusammenfassender Berichte. Mittlere und leitende Angestellte in bestimmten Unternehmen verbringen übermäßig viel Zeit mit dem manuellen Abgleich inkonsistent spezifizierter Daten. Einer der Gründe für die Dateninkonsistenz wird durch Datenmodelle beseitigt, die ein unternehmensweit geregeltes Vokabular bereitstellen.

Annahmen, Einschränkungen und Geschäftsregeln, die sich im Datenmodell widerspiegeln

Wichtige Annahmen und Grenzen des Einzelhandelsgeschäfts spiegeln sich in den Datenmodellen wider. Die Verbindung zwischen Besteuerung, Produkt und Dienstleistungen des Einzelhändlers kommt beispielsweise in der Art und Weise zum Ausdruck, wie Dinge, Steuern, Steuerbehörden, Einzelhandelstransaktionen, Bestandsführungsunterlagen usw. in einem Datenmodell miteinander verknüpft sind. Die Richtlinien für die Behandlung von Staffelrabatten durch einen Einzelhändler spiegeln sich ebenfalls in der Art und Weise wider, wie Preisänderungsregeln mit Retouren und Sonderangeboten verknüpft sind. Das komplexe Beziehungsgeflecht, das die Geschäftsregeln eines Einzelhändlers definiert, wird explizit durch Entity-Relationship-Modelle dargestellt.

Regulatorische Berichterstattung und Rechenschaftspflicht & Datenmodellierung

Datenmodelle sind für Einzelhändler erforderlich, um sich in der heutigen komplizierten Umgebung der gesetzlichen Berichterstattung zurechtzufinden. Der Sarbanes-Oxley Act von 2002 verlangt eine strenge Berichterstattung und Nachverfolgung der betrieblichen und finanziellen Kontrollen in Unternehmen. Diese Art der Überwachung setzt voraus, dass Händler verstehen, wie Daten organisiert, gefüllt, aufbewahrt und geschützt werden. Unternehmenssysteme für Finanzen, Vertrieb, Marketing, Inventar, Einkauf und damit verbundene operative Systeme erstellen Daten für die Einhaltung von Vorschriften. Je nach Größe und Komplexität des Unternehmens sind diese Systeme Teil einer Sammlung von Anwendungen, deren Daten in Informationen umgewandelt und dann über Berichte in Wissen für die Führungsebene umgewandelt werden müssen. Die Daten werden gesammelt und in Datenstrukturen wie Tabellen und Dateien gespeichert und dann konvertiert und transportiert – um in Berichten, die von den Geschäftsführern unterzeichnet werden, zu Wissen zu werden. Die geschäftlichen und technischen Metadaten für diese Systemdaten bilden eine Informationsarchitektur, die sowohl die Schaffung interner Kontrollen vorantreiben als auch den Führungskräften des Unternehmens die Gewissheit geben kann, dass die von ihnen unterzeichneten Berichte korrekt sind. Die in diesem Artikel behandelten Datenmodellprinzipien bieten die Art von Unterstützung, die notwendig ist, um die Einhaltung gesetzlicher Vorschriften für die Berichterstattung zu erleichtern. Darüber hinaus sind zusätzliche Datenübertragungs- und -umwandlungsfunktionen erforderlich. Das ARTS ODM V7.0/7.1 zu ARTS DWM V3.0 Extrahieren, Konvertieren und Laden Mapping erfüllt teilweise die gesetzlichen Anforderungen an die Datenmobilität.

Die Einhaltung der PCI-Vorschriften (Payment Card Industry), in denen die Verfahren festgelegt sind, die Geschäfte zur Sicherung der Kreditkartenkonten ihrer Kunden anwenden müssen, setzt voraus, dass die Einzelhändler die Arten von Daten, die sie sammeln, erfassen und verstehen. Die PCI-Compliance konzentriert sich zwar auf die Identifizierung von Zahlungskonten, ebnet aber den Weg für weitere Einschränkungen in Bezug auf Kundenidentität und persönliche Daten. Für all diese Regelungen müssen Händler ihre Datenbestände inventarisieren und verstehen.

Was passiert, wenn das logische Datenmodell nicht entwickelt wird?

Einfach gesagt: Es kann zu Problemen kommen. Die Benutzer könnten sich in Verfahren und Aktivitäten verstricken, wenn sie nicht daran erinnert werden, dass Daten und nicht die Technologie der wichtigste Faktor sind, der bei der Entwicklung eines neuen Systems zu berücksichtigen ist. Ein Datenmodell, das sich nur auf den physischen Arbeitsablauf konzentriert, verpasst es, die kritischen Geschäftsanforderungen zu reflektieren.

Tabellen und Dateien, die von Designern erstellt werden, ohne dass die Daten entsprechend den Geschäftsanforderungen beschrieben werden, sind oft unorganisiert und weisen keine solide Grundstruktur auf. Die Entdeckung und der Versuch, zusätzliche Daten aus Bildschirm- oder Berichtslayouts während des Kodierungs-, Test- oder sogar Bereitstellungsprozesses einzubeziehen, ermutigt Entwickler dazu, eher reaktiv als proaktiv zu handeln. Das Ergebnis ist ein unzusammenhängender Organismus, der schwer zu betreiben und zu warten ist und der mit Fehlern oder überflüssigem Text gespickt ist, der die Systemdokumentation überflüssig, zeitraubend und möglicherweise unbrauchbar macht.

Da das logische Datenmodell die Struktur von Datenteilen auf der Grundlage zentraler Geschäftsanforderungen sowie die Verbindungen zwischen ihnen festlegt, bedeutet das Fehlen eines solchen Modells, dass viele Chancen zur Optimierung von Geschäftsprozessen verpasst werden. Die Entwickler müssen sich damit begnügen, laufende Vorgänge zu automatisieren oder Altsysteme auf einer neueren technischen Plattform zu replizieren, die in Zukunft möglicherweise veraltet sein wird.

Die Verwendung der logischen Datenmodellierung hilft Datenanalysten, unabhängig von der neuesten Technologie zu denken und sich auf die Verbesserung der Geschäftsprozesse zu konzentrieren.

Folglich muss ein logisches Datenmodell ein wesentlicher und unumkehrbarer Bestandteil jeder Anwendungsentwicklung werden. Es ist eine kritische Phase, die idealerweise vor dem Datenbankdesign liegen sollte.

Vorteile des logischen Datenmodells

  • Da Daten im Laufe der Zeit stabil bleiben, ist eine logische Datenarchitektur ebenfalls stabil und äußerst günstig für die Wiederverwendung von Daten und die gemeinsame Nutzung von physischen Daten, was zu weniger redundanter Datenspeicherung führt.
  • Wenn andere Teams ihre (oft wechselnden) Anforderungen einbringen, können die Komponenten eines logischen Datenmodells wiederverwendet und geändert werden.
  • Die Kosten für die Entwicklung und Pflege eines logischen Datenmodells werden langfristig durch die Vorteile aufgewogen, die es bietet, nicht zuletzt dadurch, dass alle geschäftlichen Anforderungen und Vorschriften von Anfang an erkannt und integriert werden.
  • Infolge der Integration und der Klarheit der Geschäftsregeln werden die Komponenten des Konstruktionsprozesses, wie Entwurf, Kodierung, Tests und Bereitstellung, schneller vorangetrieben.
  • Wenn ein logisches Datenmodell vorhanden ist, ist es einfacher und damit kostengünstiger, Änderungen vorzunehmen, Fehler zu beheben oder fehlende Daten vor der Implementierung während des Entwicklungszyklus hinzuzufügen.
  • Durch proaktives Handeln kann der Bedarf der Benutzer an Anpassungen reduziert werden.
  • Da jede Geschäftsaktivität und jede Regel darin verknüpft ist, können logische Datenmodelle für die Wirkungsanalyse verwendet werden.
  • Da die Elemente im logischen Datenmodell textuelle Definitionen in der Geschäftssprache haben, ist die Systemdokumentation leicht zu pflegen und abrufbar.

Read more