In der betrieblichen Datenverarbeitung ist die Datenbank als umfassender Informationspool ein zentrales Medium der Integration. Um einen verläßlichen Ausgangspunkt für Softwareprojekte zu bieten, muß ihr Aufbau auf lange Sicht stabil bleiben. Der logische DB-Entwurf ist deshalb in der Rahmenplanung anzusiedeln und sollte alle von der DV zu unterstützenden Funktionen berücksichtigen .

Ein System der Unternehmensplanung besteht meist aus drei Stufen: langfristig wirkende Entscheidungen werden im Rahmen der strategischen Planung gefällt; solche mit mittelfristigen Horizont in der taktischen Planung; kurzfristige Entscheidungen, die den tatsächlichen Aktionen vorausgehen, zählt man zur operativen Planung.

Längerfristige Entscheidungen beschränken den Spielraum der kürzerfristigen; sie bilden quasi einen Rahmen für diese. Strategische und taktische Planung kann deshalb auch als Rahmenplanung bezeichnet werden.

Planung geschieht im Betrieb meist periodisch. Auch die langfristigen strategischen Pläne mit einem Horizont von zehn Jahren und mehr werden jährlich überarbeitet und an die veränderte Umwelt angepaßt ("rollende Planung").

Planungselemente sind miteinander verbunden

Im Bereich der EDV gilt es, strategische, taktische und operative Entscheidungen zu fällen. Bei der langfristigen Planung sind neben der Organisation des Datenverarbeitungsbereichs besonders die Software- und die Hardwarestrategie hervorzuheben. Die Softwarestrategie beinhaltet die Entscheidung, welche betrieblichen Funktionen von der DV unterstützt werden sollen, die Entscheidung für Eigenentwicklung, Standardsoftware oder eine Kombination von beiden; einen Zeitrahmen und möglichst auch schon Entscheidungen über die Softwarelieferanten.

In der Hardwarestrategie ist die Entscheidung für den oder die Hersteller enthalten, deren Geräte aufgestellt werden sollen. Auch die Rechnersysteme selbst können von der Größenordnung her schon festgelegt werden.

Natürlich sind diese Planungselemente miteinander verbunden. Auch das besonders wichtige Unternehmensmodell kann nicht ohne Bezug zu Software- und Hardwarestrategie entworfen werden.

Im Gegensatz zur betriebswirtschaftlichen Planung wird auf der operativen Ebene zum größten Teil nicht periodisch, sondern projektbezogen und von Fall zu Fall geplant. Bei kurzfristig wirkenden Entscheidungen ist dies auch angemessen. Leider werden in den Unternehmen auch viele langfristig wirkende und projektübergreifende Entscheidungen im Verlauf von Einzelprojekten gefällt. Es gibt zuviel Projekt- und zuwenig Rahmenplanung.

Eine betriebliche Datenverarbeitung kann als integriert bezeichnet werden, wenn die Programme hinsichtlich ihrer Funktionen und Daten aufeinander abgestimmt sind.

Die funktionsbezogene Integration ist gegeben, wenn zwischen den Aufgaben, die die Programme wahrnehmen, weder Lücken noch Überschneidungen auftreten. Überschneidungen bedeuten Mehrarbeit und häufig verschiedene Lösungen desselben Problems; Lücken führen dazu, daß Daten zwischen aufeinander aufbauenden Programmen manuell bearbeitet und für das Folgeprogramm noch einmal eingegeben werden müssen.

Die Programme eines Betriebs sind eng miteinander verknüpft. Sie benutzen zum Teil dieselben Stammdaten und tauschen Daten aus. In der konventionellen Datenverarbeitung besaß jedes Programm seine eigenen Dateien. Der Datenaustausch wurde mit Brückenprogrammen und Bändern durchgeführt. Damit mehrfach vorhandene Daten nicht auseinanderliefen, wurden regelmäßig Abgleichsläufe durchgeführt. Abgesehen davon, daß die Abgleiche nicht die permanente Übereinstimmung paralleler Daten sicherstellen können, ist mit der "Transfer-und-Abgleichs-DV" auch ein immenser Zeitaufwand verbunden.

Aus heutiger Sicht läßt sich eine datenbezogene Integration nur mit Datenbanken verwirklichen. Das Prinzip ist einfach (siehe Abbildung 1): Alle Programme greifen auf die Datenbank zu; eigene Dateien kann es nur bei "privaten" Daten geben. Der Datenaustausch erfolgt über die Datenbank, die als umfassende Schnittstelle fungiert. Daten, die ein Programm dort ablegt, können unmittelbar danach von nachfolgenden Programmen aufgenommen werden. Die Daten können nicht auseinanderlaufen, weil sie entweder nur einmal vorhanden sind oder aber - bei verteilten Datenbanken - parallel aktualisiert werden.

Moderne Datenbanksysteme sind in mehreren Ebenen aufgebaut (siehe Abbildung 2). In der obersten Ebene werden den Anwendungsprogrammen die Daten zur Verfügung gestellt, die sie brauchen. Man nennt einen solchen Datenausschnitt die "Sicht" des Programms auf die Daten. Eine ebenfalls gebräuchliche Bezeichnung ist "Subschema".

Alle Sichten werden aus einer einzigen Datenzusammenstellung zusammengesetzt. Diese Kombinationsstellung heißt "logisches Schema" Dabei wird mit dem Wort "logisch" auf die inhaltliche Betrachtungsweise hingewiesen - im Gegensatz zu einer Sicht, die sich an der Art und Weise der physischen Speicherung orientiert. Diese ist Gegenstand des sogenannten "internen Schemas''. In ihm ist festgelegt, wo die einzelnen Daten gespeichert sind und in welcher Organisationsform.

Der Datenbankentwurf (Datendesign) betrifft alle drei Ebenen. Das Kernstück ist allerdings das logische Schema, also die inhaltliche Zusammenstellung der gesamten Daten der Datenbank. Versorgt die Datenbank den größten Teil der Funktionsbereiche eines Unternehmens, dann ist das logische Schema eine Zusammenstellung nahezu aller Unternehmensdaten. In diesem Fall kann man es auch als "Unternehmensmodell" bezeichnen..

Beim Entwurf eines Unternehmensmodells muß anders vorgegangen werden als beim Entwurf einer kleinen, isolierten Datenbank. Während jene in einem Zug entworfen und eingerichtet werden kann, sollte das Unternehmensmodell Gegenstand der Rahmenplanung sein, und zwar aus folgenden Gründen:

- Die Datenbank ist als alleinige und umfassende Schnittstelle das Medium der Integration. Sie ist nicht etwa Programm- oder Projektspezifisches, sondern der gemeinsame Datenfundus aller Programme.

- Nicht alle Programme können zur gleichen Zeit realisiert werden. Andererseits aber läßt sich der Datenaustausch zwischen den Programmen nur korrekt verwirklichen, wenn bei jedem Programm von demselben Schema ausgegangen werden kann und dieses Schema auf lange Sicht stabil bleibt.

Würde man nur von Projekt zu Projekt das logische Schema um neue Datenfelder erweitern, dann könnte sich bald herausstellen, daß irgendwelche Daten von vorausgehenden, bereits realisierten Programmen nicht bereitgestellt werden. Allerdings kann sich die Notwendigkeit ergeben, daß das in der

Rahmenplanung entworfene logische Schema im Verlauf eines Projekts erweitert werden muß, wenn

die DV-Funktionen genauer durchdacht werden. Meist müssen zusätzliche Datenfelder aufgenommen werden. Es gibt also keine Garantie für eine völlige Stabilität des Unternehmensmodells.

Internes Schema für jedes Projekt neu überdenken

Die Datensichten (Subschemata) werden im Verlauf der operativen Projektplanung festgelegt. Für jedes Programm müssen aus den Daten des logischen Schemas die benötigten herausgesucht werden. Werden dabei Lücken im logischen Schema festgestellt, so muß dieses Schema, wie beschrieben, ergänzt werden.

Das interne Schema ist ebenfalls der operativen Planung zuzuordnen. Es wird maßgeblich durch die Art und Häufigkeit der Zugriffe auf die einzelnen Datenelemente bestimmt. Werden durch ein Projekt zusätzliche betriebliche Funktionen von der Datenbank versorgt, so kann sich diese Zugriffssituation ändern. Deshalb muß das gesamte interne Schema von Projekt zu Projekt neu überdacht werden. Anpassungen sind bei den meisten Datenbanken leicht möglich.

Die Freiheit, ein logisches Datenbankschema ganz nach den betrieblichen Erfordernissen zu realisieren, hat ein Unternehmen gewöhnlich nur, wenn es die gesamte Software selbst entwickelt. Standardpakete haben mehr oder weniger eng vorgegebene Datengliederungen, die leider nicht immer nach den Lehrsätzen der Theorie entworfen wurden. Der Käufer hat zwar meistens Anpassungsmöglichkeiten, die Datengrundstruktur kann er jedoch nicht ändern. In der Praxis wird häufig der betriebliche Ablauf geändert, damit ein bestimmtes Paket eingesetzt werden kann.

Es ist eine Überlegung wert, ob ein Unternehmen nicht auch dann ein Unternehmensmodell entwickeln lassen sollte, wenn es mehr zur Standardsoftware neigt. Der Vergleich des Modells mit den Datengliederungen der angebotenen Pakete hilft herauszufinden, inwieweit diese Pakete den betrieblichen Gegebenheiten entsprechen, und wie schwierig es sein wird, sie vollends diesen Gegebenheiten anzupassen.

Das logische Schema soll so beschaffen sein, daß einerseits alle Programme mit den benötigten Datenzusammenstellungen (Sichten) versorgt werden können, andererseits die Richtigkeit (Konsistenz) der Daten auf Dauer erhalten werden kann. Die zweite Forderung läßt sich am besten mit einem redundanzarmen Schema verwirklichen. Die Redundanzarmut ist auch für sich alleine von Wert, weil sie Speicherkosten erspart.

Es gibt heute weitgehende Übereinstimmung darüber, was einen guten Datrenbankentwurf im Sinne der genannten Ziele auszeichnet. Im Rahmen der Relationentheorie wurden die Kriterien der dritten Normalform (3NF) und der Boyce-Codd-Normalform (BCNF), einer etwas schärferen Bedingung, formuliert.

Ein geeignetes Schema ist auf unterschiedlichen Wegen zu erreichen. Es werden heute vorwiegend zwei Arten von Entwurfsmethoden für das logische Schema angewandt: formal-analytische und semantisch-konstruktive.

Die formal-analytische Methode

Diese Methode wurde von Ted Codd in Zusammenhang mit dem Relationenmodell propagiert. Aus Datenzusammenstellungen in Form von Formularen und Übersichten, die im Betrieb vorkommen ("unnormalisierte Relationen"), wird durch fortgesetzte Zerlegung eine Reihe von Datenzusammenstellungen (Relationen) gewonnen, die die gewünschte redundanzarme Speicherung in der Datenbank gestattet. Beurteilungskriterium für die Eignung einer Relation ist die dritte Normalform. "Formal" ist diese Methode, weil sie auch mit einer Menge allgemeiner Datenfelder a1, a2,. . . an durchgeführt werden kann, wenn die Abhängigkeiten zwischen diesen Datenfeldern bekannt sind.

Semantisch-konstruktive Methoden

Bei den semantischen Methoden spielt die Bedeutung eines Datums während des gesamten Entwurfs eine Rolle. Die für die DV relevanten betrieblichen Realitäten werden in einem Modell dargestellt beziehungsweise rekonstruiert. Es gibt verschiedene Ansätze mit unterschiedlichen Beschreibungsmitteln . Die einfachste und am weitesten verbreitete Methode ist die von Chen. Die Wirklichkeit wird dabei durch eine Anzahl von Objekttypen (entity types) und Arten von Beziehungen (relationships types) zwischen ihnen dargestellt.

Semantische Methode bietet viele Vorteile

Abbildung 3 faßt das Vorgehen der beiden Methoden zusammen. Die formal-analytische Methode geht von unnormalisierten Relationen aus die gewöhnlich nicht einem bestimmten Objekt- oder Beziehungstyp zugeschrieben werden können. Erst durch die "Normalisierung" (das Überführen in die 3NF) kann man Relationen gewinnen, die bestimmte Objekt oder Beziehungstypen vertreten. Bei der Konstruktion arbeitet man von vornherein mit Objekt- und Beziehungstypen. Die Redundanzarmut ergibt sich durch Konstruktionskriterien, die inhaltlich denen der 3NF beziehungsweise BCNF entsprechen.

Im folgenden wird von der semantisch-konstruktiven Methode ausgegangen, die sich am Ansatz Chens orientiert, und zwar aus folgenden Gründen:

- Diese Methode ist auch dem Mitarbeiter aus der Fachabteilung verständlich. Das ist wichtig, weil von diesem Mitarbeiter das Wissen über die im Modell darzustellende Realität eingebracht werden muß. Die mit der Konstruktion verbundene graphische Darstellung ist anschaulich und erlaubt ein schnelles Erfassen der Zusammenhänge.

- Mit der semantischen Methode können sowohl relationale Datenbanken als auch Netzwerkdatenbanken entworfen werden, während die formale Methode speziell auf relationale Datenbanken zugeschnitten ist. Wenn in den kommenden Jahren neue Datenmodelle, zum Beispiel das NF2-Modell, Anwendung finden, so können semantische Methoden mit geringen Anpassungen weiterverwendet werden.

- Die Qualität eines formal-analytischen Entwurfs ist sehr von den verwendeten Ausgangstabellen abhängig. Werden Tabellen vergessen, dann bleibt der Entwurf lückenhaft.

- Die semantische Methode erfolgt "top-down" und entspricht damit besonders den Erfordernissen einer Rahmenplanung.