Datenbankaufbau : Skript

dblogo.jpg

Laufkäfer, Käferdatenbank South Kensington

Kapitel 2: Datenbank-Planung und -Design

von Margarete Payer & Alois Payer

(mailto: payer@hbi-stuttgart.de

Zitierweise / cite as:

Payer, Margarete <1942 - >: Datenbankaufbau : Skript / Margarete Payer & Alois Payer. -- Kapitel 2: Datenbank-Planung und -Design. -- Fassung vom 1997-05-17. -- URL: http://www.payer.de/dbaufbau/dbauf02.html. -- [Stichwort].

Letzte Überarbeitung: 1997-05-17

Anlaß: Lehrveranstaltungen an der HBI Stuttgart

©opyright: Dieser Text steht der Allgemeinheit zur Verfügung. Eine Verwertung in Publikationen, die über übliche Zitate hinausgeht, bedarf der ausdrücklichen Genehmigung der Verfasserin.

Dieser Text ist Teil der Abteilung Datenbankaufbau von Tüpfli's Global Village Library

2.0. Übersicht

2.1. Weiterführende Ressourcen

Printed Media:

Connolly, Thomas M.: Database systems : a practical approach to design, implementation and management / Thomas M. Conolly ; Carolyn E. Begg : Anne D. Strachan. -- Wokingham [u.a.] : Addison-Wesley, 1996. -- ISBN 0-201-42277-8. -- S. 122-145

WWW:

Özsu, M. Tamer: Database Management Systems : Lecture Notes. -- Design. -- Sept. 1995. -- URL: http://web.cs.ualberta.ca/~database/courses/c391/Design/. -- Zugriff am 15. Mai 97

2.2. Die Lebensstadien einer Datenbank

Stark schematisiert kann man folgende Lebensstadien einer Datenbank unterscheiden:

  1. Planung der Datenbank: alle Tätigkeiten der Verantwortlichen, die eine Realisierung der folgenden Schritte ermöglichen und erleichtern (Auftrag, große Zielsetzung, Bereitstellung von Ressourcen ...)
  2. Definition von Benutzergruppen, vorgesehenen Anwendungen, Gegenstand und Umfang der Datenbank
  3. Sammlung und Analyse der Anforderungen an die Datenbank (Pflichtenheft)
  4. Datenbank-Design
  5. Auswahl eines Datenbank Management Systems (DBMS)
  6. Design der Anwendungssoftware und der Benutzeroberfläche
  7. Erstellung eines Prototyps, d.h. einer funktionsfähigen Datenbank mit allen wichtigen Features der endgültigen Datenbank
  8. Test am Prototyp und Korrektur bisheriger Schritte
  9. Implementierung der vollen Datenbank
  10. Datenerfassung bzw. Datenkonversion
  11. Test und Korrekturen
  12. Datenbank-Unterhalt, Verbesserung, Sammlung von Erfahrungen für größere Neuentwicklungen

2.3. Datenbank Design

Man unterscheidet beim Datenbank-Design folgende Ebenen:

  1. Konzeptionelles Design (conceptual design): Design der Datenstrukturen, des Gebrauchs der Daten usw. ohne Rücksicht auf ein bestimmtes Datenbank Management System (DBMS)
  2. Logisches Design (logical design): Umwandlung des konzeptionellen Designs auf die Strukturen des vorgesehenen Datenbank Management Systems (DBMS)
  3. Physisches Design (physical design): Design der Implementierung

2.4. Design der Anwendungssoftware und der Benutzeroberfläche

Das Design der Anwendungssoftware und der Benutzeroberfläche hat die gleichen Ebenen wie das Datenbank-Design.

D. Shneiderman stellt folgende Forderungen an eine Benutzeroberfläche:

[Shneiderman, D.: Design the user interface : strategies for effective human-interaction. -- 2. ed. -- 1992; zitiert nach Conolly, 1995. -- S. 143f.]

2.4.1. Minimalanforderungen an die Benutzeroberfläche einer bibliographischen Datenbank

Es wäre wohl eine Utopie, von einem OPAC bei uns alle die tollen Möglichkeiten zu fordern, die es anderswo gibt. Hier wird ein Mindeststandard mit ein paar zusätzlichen Hinweisen vorgeschlagen, an dem man sich für das Regelwerk orientieren kann. Sieht man z.B. Stichwortsuche in einer Körperschaftsnamensliste (-index) vor, erspart man sich sämtliche Übergehungsverweisungen und die Regeln dazu.

Einschränkend soll daraufhingewiesen werden, daß die folgenden Anforderungen für einen OPAC in großen Bibliotheken vorgesehen sind. Insbesondere Lösungen zum Problem Einschränkung der Trefferquote sind bei OPAC's mit über einer Million Titel dringend erforderlich. Wartet man nämlich erstmal bis die Datenbank mit so vielen Titeln bestückt ist, sind sinnvolle Lösungen nur noch mit Einschränkung möglich. Eine gute Begrenzung der Trefferquote kann man z.B. mit der Angabe der Sprache erreichen; nachträglich bei einer Million Titel die Sprache nachzuführen, dürfte aber im allgemeinen nicht machbar sein.

2.4.1.1. Zugangspunkte

Ein OPAC sollte mindestens folgende Zugangspunkte anbieten:

  1. als Primäraspekte, d.h. als Zugangspunkte, die direkt abgefragt werden können:
  2. als Sekundäraspekte, d.h. als Einschränkung einer Abfrage über einen primären Zugangspunkt:
  3. weitere Zugangspunkte in Spezialsammlungen: Für Spezialsammlungen sind weitere Aspekte (als Primär- und Sekundäraspekte) sinnvoll: z.B.

2.4.1.2. Verschiedene Suchmodi

  1. Stichwortsuche d.h. Suche mit einzelnen Worten, üblicherweise ohne die Stopworte ("und" u.ä.).

    [ Hilfreich wäre für die Einschränkung der Treffer die Anwendung des Abstands- oder Nachbarschaftsoperators ("adjacency"), wodurch man z.B. erreichen kann, daß die angegebenen Stichworte direkt aufeinander folgen müssen. Z.B. können die Stichworte "Weltgeschichte Biographien" zu dem Titel "Epochen der Weltgeschichte in Biographien" führen, nicht aber zu "Biographien aus allen Epochen der Weltgeschichte". Mit diesem Operator kann man aber auch angeben, daß die angegebenen Stichworte nur aus einer grammatikalischen Einheit stammen dürfen.]

    Man sollte unterscheiden:

  2. Exakte Suche ("phrase") d.h. Suche mit der vorliegenden Wortfolge, deckt das vom Kartenkatalog her gewöhnte Suchen ab, bietet aber weit mehr. Je vollständiger und korrekter die Angabe ist, desto besser ist der Erfolg. Es muß gewährleistet sein, daß es ausreicht, den Anfang einer Wortfolge oder die korrekte Wortfolge ab einer bestimmten Stelle einzugeben. Für kurze Titel, Namen oder Schlagworte, die aus sehr allgemeinen Worten bestehen, ist es unumgänglich, der Maschine mitteilen zu können, daß nur diese Wortfolge zu suchen ist.

    Man sollte unterscheiden:

  3. Browsing oder Blättern in den Indices: durch "Blättern" in alphabetisch angeordneten Indices kann man sich einen Überblick über den Bestand, über verwandte Namen bzw. Körperschaften und Schlagworte verschaffen. Man kann damit das vom fortgeschrittenen Benutzer gewohnte Blättern im Kartenkatalog ersetzen. Personen und Körperschaftsnamen und Schlagworte müssen mit ihren Verweisungen oder Hinweisen auf über- und untergeordnete Elemente (z.B. Schlagworte) u.ä. indiziert sein.

    Browsing muß möglich sein:

2.4.1.3. Suchhilfen

  1. Trankierung d.h. man gibt nur einen Teil eines Wortes ein.

    Man muß unterscheiden zwischen:

  2. Orthographische Varianten (sprachbezogen): Suche nach verschiedenen Schreibweisen ein- und desselben Namens oder Wortes. z.B. Payer, Paier, Peyer ...; organisation, organization
  3. Boolesche Verknüpfungen: UND, ODER und UND NICHT: Solche Verknüpfungs-Operatoren innerhalb und zwischen den Zugangspunkten ermöglichen z.B. die Verknüpfung von Person und Titel, Körperschaft und Titel u.ä.
  4. Bindestrichregelung: Das System sollte bei Wörtern mit Bindestrich auch automatisch unter den einzelnen Wortteilen suchen (wichtig insbesondere für die Bindestrichanwendung im Englischen) z.B. "year-book" auch unter "year" und "book"
  5. Sucheinschränkungen. Es sollte möglich sein die Suche mit den oben genannten Aspekten zu begrenzen:

    Diese Aspekte sollten auch verknüpft angewendet werden können: z.B. "Studien zum Orient" + Zeitschrift + Mikrofiche.

2.4.1.4. Weitere Erwartungen

  1. Interne Verknüpfungen: Mindestens Folgendes sollte intern verknüpft sein, damit der Benutzer solche Verknüpfungen nicht selbst herstellen muß:
  2. Anzeige auf dem Bildschirm: Neben den verschiedenen Anzeigen in Listenform sollte auch die Anzeige in der ISBD-Form ermöglicht werden. Damit man mehrere Titel gleichzeitig auf dem Bildschirm ansehen kann, sollte es neben der ausführlichen ISBD-Form eine ISBD in Kurzfassung geben. Diese Kurzfassung ist zu standardisieren. Als Minimalnorm ist wohl die Möglichkeit eines vom jeweiligen Benutzer definierten Anzeigeformates nicht durchsetzbar.

2.4.1.5. Abfragemodi

Dem Benutzer sind verschiedene Abfragemodi je nach Expertise und Vorlieben des Benutzers anzubieten (d.h. sowohl Menue- als auch kommandogebundene Abfragen).

Zu Kapitel 3: Datenbank-Design: Entity-Relationship (ER) Modelling