wbuch

3.1 Aufgabenstellung

Weltausschnitt / Anwendungsbereich

Es geht um die Produkte eines Verlages, der Wörterbücher (z.B. Deutsch nach Englisch), digital oder auch gedruckt, herstellt und verkauft und der seit einiger Zeit auch Übersetzungsprogramme anbietet. Seine Produkte sollen in einer Datenbank verwaltet werden. Einige Attribute sind schon angeführt. Zu erfassen ist folgendes:

• Alle Wörterbücher und Volltextübersetzer (vgl. unten) mit den Sprachen, die abgedeckt sind (z.B. deutsch nach englisch und englisch nach deutsch, deutsch nach französisch und französisch nach deutsch), …). Es ist grundsätzlich möglich, dass ein Wörterbuch auch nur eine Richtung abdeckt.
• Für jedes gedruckte Wörterbuch wird auch festgehalten, wieviele Einträge es hat (Einträge), für welche Zielgruppe es gedacht ist (Schüler, Studierende, „Anwender“, „Profi-Anwender“, Übersetzer) (Zielgruppe), wann es auf den Markt gebracht wurde (ErschDatum), wieviele Seiten es hat (AnzSeiten).
• Für jedes digitale Wörterbuch wird auch festgehalten, wann es auf den Markt gebracht wurde (ErschDatum), welche Bezeichnung (SWBez) die aktuelle Software hat (z.B. Professional English 7.0), wieviele Einträge es hat (Einträge) und für welche Zielgruppe es gedacht ist (Schüler, Studierende, „Anwender“, „Profi-Anwender“, Übersetzer) (Zielgruppe).
• Für jeden „Volltextübersetzer“ (Programm zur automatischen Übersetzung) wird auch festgehalten, welche Sprachen abgedeckt sind, wieviele Einträge das Systemlexikon hat (Einträge), für welche Zielgruppe das Produkt gedacht ist und wann es auf den Markt gebracht wurde. Festgehalten wird außerdem, ob das Systemlexikon durch den Anwender erweiterbar ist (Erweiterbarkeit) und ob man den Käufern anbietet, es durch Internetzugriffe regelmäßig aktualisieren zu lassen. Falls ja, wie lange dies möglich ist (AktJahre), z.B. 5 Jahre ab Kauf. Falls ein Produkt mit der Möglichkeit der Internetaktualisierung nicht mehr angeboten wird, wird dies auch festgehalten (RunterVomMarkt).
• Die Volltextübersetzer beruhen jeweils auf einem Übersetzungsprogramm. Es kann sein, dass ein Volltextübersetzer mit verschiedenen Programmen angeboten wird (z.B. Zielgruppenspezifisch). Natürlich dient ein Programm u.U. vielen Volltextübersetzern (z.B. Deutsch nach Englisch, Französisch nach Deutsch). Für diese Programme wird festgehalten, welche Dokumentarten (DokArten) sie auswerten können (Word, PDF, Bildformate, usw.) und ob es möglich ist, die Programmleistung in Textprogramme zu integrieren (Integrierbarkeit).
• Die Programme für die digitalen Wörterbücher werden nicht erfasst.
• Für die Programme der Volltextübersetzer werden außerdem die Softwarehäuser, die an der Erstellung mitgearbeitet haben, mit ihrer Anschrift (nur die Zentrale) festgehalten. Es wird auch die zentrale E-Mail-Adresse erfasst. Es kommt durchaus vor, dass ein Programm von mehreren Softwarehäusern erstellt wird.
  Festgehalten wird auch, wann die Zusammenarbeit mit dem Softwarehaus bzgl. eines Programmes begann (Beginn) und – gegebenenfalls – wann sie endete (Ende). Diese Angaben sind natürlich i.d.R. je nach Produkt, bei dem zusammengearbeitet wurde, unterschiedlich.

Für alle digitalen Produkte (Wörterbücher/Systemlexikon usw. + Programme) werden außerdem die Systemvoraussetzungen festgehalten. Welche minimale Hardwareanforderung (Hardware) gegeben ist (anhand des Prozessors, z.B. „Pentium IV oder vergleichbar“), wieviel Arbeitsspeicher sie benötigen (ArbSpeich), wieviel freier Plattenspeicher (PlattSpeich) nötig ist (in MB) und welche Betriebssystemversion (BS) genutzt werden kann (Windows XP, Windows 2000, Windows Vista). Dies sind in der Regel mehrere.

Beachten Sie, dass „Adresse“ kein Attribut ist, sondern nur die Bestandteile von „Adresse“.

Soweit die Aufgabenstellung.

3.2 Lösungsschritte

Hier wird nun obiger Text Schritt für Schritt bearbeitet und das Datenmodell erarbeitet. Zuerst kommt jeweils der Text der Aufgabenstellung, dann seine Auswertung.

Es geht um die Produkte eines Verlages, der Wörterbücher (z.B. von Deutsch nach Englisch), digital oder auch gedruckt, herstellt und verkauft und der seit einiger Zeit auch Übersetzungsprogramme anbietet. Seine Produkte sollen in einer Datenbank verwaltet werden. Einige Attribute sind schon angeführt. Zu erfassen ist folgendes:

- Alle Wörterbücher und Volltextübersetzer (vgl. unten) mit den Sprachen, die abgedeckt sind (z.B. deutsch nach englisch und englisch nach deutsch, deutsch nach französisch und französisch nach deutsch), …). Es ist grundsätzlich möglich, dass ein Wörterbuch auch nur eine Richtung abdeckt.

Hier sind zwei Tatsachen ableitbar. Erstens, dass es wohl Wörterbücher und Volltextübersetzer als solche gibt – und zwar wahrscheinlich als „Spitze“ einer Generalisierungshierarchie. Nennen wir sie Produkte und geben ihnen den Schlüssel #ProdNr. Zweites, dass die abgedeckten Sprachen zu erfassen sind.

PRODUKTE (#ProdNr, …

PRODUKTE_SPRACHEN (#(ProdNr, Sprachen))

Im Attribut Sprachen wird jeweils eine Kombination festgehalten. Z.B. „Deutsch – Englisch“ oder „Englisch – Deutsch“ für ein Wörterbuch. Hier sind, wie auch in den Klausurlösungen sichtbar wurde, andere Lösungen denkbar.

- Für jedes gedruckte Wörterbuch wird auch festgehalten, wieviele Einträge es hat (Einträge), für welche Zielgruppe es gedacht ist (Schüler, Studierende, „Anwender“, „Profi-Anwender“, Übersetzer) (Zielgruppe), wann es auf den Markt gebracht wurde (ErschDatum), wieviele Seiten es hat (AnzSeiten).

Hier wird eine erste Spezialisierung deutlich: Gedruckte Wörterbücher. Sie werden Buch_WöBü genannt und haben (erstmal) die angeführten Attribute.

- Für jedes digitale Wörterbuch wird auch festgehalten, wann es auf den Markt gebracht wurde (ErschDatum), welche Bezeichnung (SWBez) die aktuelle Software hat (z.B. Professional English 7.0), wieviele Einträge es hat (Einträge) und für welche Zielgruppe es gedacht ist (Schüler, Studierende, „Anwender“, „Profi-Anwender“, Übersetzer) (Zielgruppe).

Damit ist die zweite Spezialisierung klar: digitale Wörterbücher. Diese Relation wird Digitale_WöBü genannt. Da hier zum Teil dieselben Attribute wie in Buch-WöBü auftauchen, gibt es also Attribute, die der Generalisierung zuzuordnen sind: Einträge und Zielgruppe. Konkret ergibt sich damit insgesamt aus obigem:

PRODUKTE (#ProdNr, ErschDatum, Einträge, Zielgruppe)

BUCH_WÖBÜ (#ProdNr, AnzSeiten)

DIGITALE_WÖBÜ (#ProdNr, ErschDatum, SWBez)

In einer Attributmatrix zur Klärung der Generalisierung / Spezialisierung ergibt sich damit folgendes:

- Für jeden „Volltextübersetzer“ (Programm zur automatischen Übersetzung) wird auch festgehalten, welche Sprachen abgedeckt sind, wieviele Einträge das Systemlexikon hat (Einträge), für welche Zielgruppe das Produkt gedacht ist (Zielgruppe) und wann es auf den Markt gebracht wurde (ErschDatum). Festgehalten wird außerdem, ob das Systemlexikon durch den Anwender erweiterbar ist (Erweiterbarkeit) und ob man den Käufern anbietet, es durch Internetzugriffe regelmäßig aktualisieren zu lassen. Falls ja, wie lange dies möglich ist (AktJahre), z.B. 5 Jahre ab Kauf. Falls ein Produkt mit der Möglichkeit der Internetaktualisierung nicht mehr angeboten wird, wird dies auch festgehalten (RunterVomMarkt).

Obiger Spiegelstrich zeigt eine weitere Relation: Volltextübersetzer. Tragen wir sie und ihre Attribute in die Attributtabelle ein, wird deutlich, dass damit eine weitere Spezialisierung von Produkte vorliegt.

Die Attribute AktJahre und RunterVomMarkt machen eine eigene Relation Volltextübersetzer_mit_Akt nötig (die Spezialisierung von Volltextübersetzer ist), da diese Attribute ja nur für eine Teilmenge der Objekte der Relation Gültigkeit haben. Zusätzlich sind in der folgenden Attributtabelle für alle Relationen außer der obersten Generalisierung alle Attribute gelöscht, die in den übergeordneten Generalisierungen angelegt sind. Dies macht die Generalisierung / Spezialisierung noch deutlicher.

Damit ergeben sich folgende zusätzlichen Relationen [Anmerkung] :

VOLLTEXTÜBERSETZER (#ProdNr, Erweiterbarkeit)

VOLLTEXTÜBERSETZER_MIT_AKT (#ProdNr, AktJahre, RuntervomMarkt)

Die Relation Volltextübersetzer ist hier ebenfalls Spezialisierung von Produkte.

Insgesamt haben wir bis hierher folgendes Ergebnis:

• Allgemeine Generalisierung:

PRODUKTE (#ProdNr, ErschDatum, Einträge, Zielgruppe)

• Spezialisierungen von Produkte:

BUCH_WÖBÜ (#ProdNr, AnzSeiten)

DIGITALE_WÖBÜ (#ProdNr, SWBez)

VOLLTEXTÜBERSETZER (#ProdNr, Erweiterbarkeit)

• Spezialisierung von Volltextübersetzer:

VOLLTEXTÜBERSETZER_MIT_AKT (#ProdNr, AktJahre, RuntervomMarkt)

• Außerdem noch unabhängig von der Generalisierung / Spezialisierung:

PRODUKTE_SPRACHEN (#(ProdNr, Sprachen))

Anmerkung zu den Spezialisierungen: Die Objekte jeder Spezialisierung sind eine Teilmenge der Objekte der zuständigen Generalisierung. Für die Ausprägungen der Schlüssel bedeutet dies, dass der Schlüssel der Generalisierung alle Schlüsselausprägungen umfasst, die Schlüssel der Spezialisierungen jeweils eine Teilmenge.

Jetzt weiter mit den Lösungsschritten.

- Die Volltextübersetzer beruhen jeweils auf einem Übersetzungsprogramm. Es kann sein, dass ein Volltextübersetzer mit verschiedenen Programmen angeboten wird (z.B. Zielgruppenspezifisch). Natürlich dient ein Programm u.U. vielen Volltextübersetzern (z.B. Deutsch nach Englisch, Französisch nach Deutsch). Für diese Programme wird festgehalten, welche Dokumentarten (DokArten) sie auswerten können (Word, PDF, Bildformate, usw.) und ob es möglich ist, die Programmleistung in Textprogramme zu integrieren (Integrierbarkeit).

Hier werden nun die Übersetzungsprogramme zu einem Datenbankobjekt. Es wird auch gleich die Beziehung zwischen Übersetzungsprogrammen und den Volltextübersetzern geklärt.  Da gleich auch noch Attribute für die Programme angegeben werden, muß für sie tatsächlich eine Relation angelegt werden.

Programme können mehrere Dokumentarten auswerten. Deshalb muß der Zusammenhang zwischen Programmen und Dokumentarten in einer eigenen Relation erfasst werden. Insgesamt ergibt sich:

ÜB_PROGRAMME (#ProgID, DokArten, IntegrierbarkeitJN)

ÜB_PROGRAMME_DOKART (#(ProgId, Dokumentart))

Da ein Übersetzungsprogramm vielen Volltextübersetzern dienen kann, umgekehrt aber ein bestimmter Volltextübersetzer nur ein Übersetzungsprogramm hat, wird außerdem der Schlüssel von ÜB_Programme zu einem Fremdschlüssel in Volltextübersetzer:

VOLLTEXTÜBERSETZER (#ProdNr, Erweiterbarkeit, ProgrID)

Da Volltextübersetzer_mit_Akt eine Spezialisierung hiervon ist, muß dort ProgrID nicht eingefügt werden.

- Die Programme für die digitalen Wörterbücher werden nicht erfasst.

Dies gibt den Hinweis, dass beim „Einbau“ der Software an die digitalen Wörterbücher nicht gedacht werden muß.

Für die Programme der Volltextübersetzer werden außerdem die Softwarehäuser, die an der Erstellung mitgearbeitet haben, mit ihrer Anschrift (nur die Zentrale) festgehalten. Es wird auch die zentrale E-Mail-Adresse erfasst. Es kommt durchaus vor, dass ein Programm von mehreren Softwarehäusern erstellt wird.

Festgehalten wird auch, wann die Zusammenarbeit mit dem Softwarehaus bzgl. eines Programmes begann (Beginn) und – gegebenenfalls – wann sie endete (Ende). Diese Angaben sind natürlich i.d.R. je nach Produkt, bei dem zusammengearbeitet wurde, unterschiedlich.

Obiger Punkt führt die Softwarehäuser als Datenbankobjekte ein:

SOFTWAREHÄUSER (#Bez, Ort, PLZ, Straße, E-Mail)

Der zweite Satz gibt den Hinweise, dass zwischen Programmen und Softwarehäusern eine n:m-Beziehung vorliegt, wenn man davon ausgeht, dass ein Softwarehaus im Zeitverlauf auch an mehreren Programmen unseres Verlags mitgearbeitet hat. Zusammen mit dem Hinweise auf die zu erfassenden Start- und Endtermine für die Zusammenarbeit ergibt sich folgende Relation:

PROGRAMME_SH (#(ProgId, SHBez), Beginn, Ende))

Für alle digitalen Produkte (Wörterbücher/Systemlexikon usw. + zugehörige Programme) werden außerdem die Systemvoraussetzungen festgehalten. Welche minimale Hardwareanforderung (Hardware) gegeben ist (anhand des Prozessors, z.B. „Pentium IV oder vergleichbar“), wieviel Arbeitsspeicher sie benötigen (ArbSpeich), wieviel freier Plattenspeicher (PlattSpeich) nötig ist (in MB) und welche Betriebssystemversion (BS) genutzt werden kann (Windows XP, Windows 2000, Windows Vista). Dies sind in der Regel mehrere.

Es ist nicht gleich zu erkennen, aber die Formulierung „Für alle digitalen Produkte ...“ deutet es an: Obiger Punkt führt über die Festlegung der Systemanforderungen eine neue Spezialisierung ein: digitale Produkte (Digitale_Pr), da hier Attribute für alle digitalen Produkte vorliegen. Diese wird als Generalisierung der digitalen Wörterbücher und der Volltextübersetzer mit den angeführten Attributen in das Datenmodell eingebaut. Insoweit ändert sich damit also die bisherige Generalisierungs- / Spezialisierungsstruktur.

Außerdem wird die Information zu den Betriebssystemversionen, damit keine Mehrfacheinträge auftreten, gleich in eine eigene Relation ausgegliedert:

DIGITALE_PR (#ProdNr, Hardware, ArbSpeich, PlattSpeich)

DIGITALE_PR_BS (#(ProdNr, BS))

Auch in der Attributtabelle wird dies klar. Ergänzen wir obige Tabelle um die Relation DIGITALE_PR mit den Attributen Hardware, ArbSpeich, PlattSpeich, dann ergibt sich folgende Tabelle, die den den oben agbeleiteten Tatbestand ebenfalls bestätigt.

Attributtabelle x

Damit ist die in diesem Weltausschnitt vorliegende Generalisierung / Spezialisierung vollständig beschrieben.

Beachten Sie, dass „Adresse“ kein Attribut ist.

Dies gibt den Hinweis, „Adresse“ nicht als Attribut, sondern über Einzelattribute zu modellieren, was oben schon geschehen ist.

3.3 Generalisierung / Spezialisierung direkt

Eine andere wenn auch ähnliche Methode, die Generalisierung / Spezialisierung in einem Weltausschnitt zu klären, besteht darin, eine Matrix mit den zu verarbeitenden Attributen und den vermuteten Relationen zu erstellen. Hierzu ein Beispiel mit den obigen Daten.

Zuerst entnimmt man der Beschreibung die Information, welche Relationen wohl als Generalisierung bzw. als Spezialisierungen anzulegen sind. Dies sind hier die folgenden, um die Darstellung einfach zu halten, werden Abkürzungen eingeführt:

1: Produkte

2: Gedruckte Wörterbücher

3: Digitale Produkte

4: Digitale Wörterbücher

5: Volltextübersetzer

6: Volltextübersetzer mit Aktualisierung

Dann legt man eine Matrix an, bei der in einer Dimension diese zu erwartenden Relationen eingetragen werden. In die andere Dimension trägt man die Attribute ein, die in der Beschreibung des Weltausschnitts genannt werden und die für diese Relationen Bedeutung haben. Für jedes Attribut kreuzt man dann das Matrixsegment an, das die Zugehörigkeit von Attribut zu Relation angibt.

In obigem Beispiel ergibt sich dann folgende Matrix.

Dies ist noch etwas unübersichtlich. Sortiert man aber die Reihen und Spalten so um, dass horizontal und vertikal die Attribute einer Relation nebeneinanderliegen, ebenso wie die Relationen mit denselben Attributen, ist die Generalisierung / Spezialisierung klar zu erkennen.

Die ersten drei Attribute gehören zu allen Relationen, also kommen sie in die oberste Generalisierung. Wäre diese noch nicht angelegt, müßte man sie hier erkennen und anlegen.

Das Attribut AnzSeiten kommt in die Spezialisierung Relation 2. Die Attribute Hardware, ArbSpech und PlattSpeich haben die Relationen 3 bis 6 gemeinsam. Also entsteht eine Generalisierung als Relation 3 für die Relationen 4, 5 und 6. Relation 3 ist gleichzeitig Spezialisierung von Relation 1.

Die Relationen 4, 5 und 6 entstehen als Spezialisierungen, weil sie zusätzlich die Attribute SWBez, Erweiterbarkeit bzw. AktJahre und RunterVomMarkt haben.

Hilfreich ist auch, v.a. bei höherer Komplexität, die Markierungen bei den Spezialisierungen zu entfernen, die in die Generalisierung wandern. Vgl. die folgende Matrix

3.4 Das textliche Datenmodell

Insgesamt ergeben sich damit bisher folgende Relationen:

PRODUKTE (#ProdNr, ErschDatum, Einträge, Zielgruppe)

BUCH_WÖBÜ (#ProdNr, AnzSeiten)

DIGITALE_PR (#ProdNr, Hardware, ArbSpeich, PlattSpeich)

DIGITALE_WÖBÜ (#ProdNr, SWBez)

VOLLTEXTÜBERSETZER (#ProdNr, Erweiterbarkeit, ProgrID)

VOLLTEXTÜBERSETZER_MIT_AKT (#ProdNr, AktJahre, RuntervomMarkt)

DIGITALE_PR_BS (#(ProdNr, BS))

PRODUKTE_SPRACHEN (#(ProdNr, Sprachen))

SOFTWAREHÄUSER (#Bez, Ort, PLZ, Straße, E-Mail)

ÜB_PROGRAMME (#ProgID, IntegrierbarkeitJN)

ÜB_PROGRAMME_DOKART (#(ProgId, Dokumentart))

SH_P (#(ProgId, SHBez), Beginn, Ende))

Die Generalisierung / Spezialisierung wurde im folgenden grafischen Datenmodell durch die Anordnung der Relationen angedeutet. Vgl. hierzu auch das entsprechende ERM-Lösungsbeispiel.

3.5 Das grafische Datenmodell

Dem entspricht das folgende grafische relationale Modell.