Datenbank - Data Base

Def.: Eine Datenbank ist ein System zur Beschreibung, Speicherung

Das Data Dictionary enthält die Beschreibungen aller Tabellen einer Datenbank. (Ist damit eine Beschreibung der Beschreibung; Metadaten).

Die deutsche Bezeichnung "Bank" läßt einem an zwei Dinge denken: zum einen an den Datenschutz im Sinne der Regelungen der Zugriffsrechte zur Verhinderung von unbefugten Datenzugriffen, Datenveränderungen und Datenlöschungen; zum anderen die Datensicherheit als Schutz vor technisch bedingten Störungen die beispielsweise zu Datenverlusten durch Löschung oder zu Veränderungen der Daten führen.

Datensicherungen zur Rekonstruktion von Datenbeständen lassen sich auf drei Ebenen durchführen:

Daneben gibt es noch die Datenbank-Logs: Protokolle, die alle Änderungen an der Datenbank aufzeichnen und so ebenfalls eine Rekonstruktion ermöglichen.

Bei Online-Datenbanken werden Vollsicherungen im laufenden Betrieb, also während der gleichzeitigen Nutzung, gefahren. Dieses Verfahren ist entsprechend anspruchsvoller.

Der Sinn einer Datenbank liegt in der betrieblichen Information. Die strukturierte Aufbereitung aller verfügbaren Daten ist zum einen eine betriebliche Dokumentation und ermöglicht zugleich das sichere Auffinden jedes Eintrages. Entsprechende Filterungen der Daten lassen beliebige Nutzungen zu: Data Warehouses bieten verdichtetet Daten über längere Zeiträume für Managementfunktionen an.

Die Daten liegen in maschinenlesbarer Form vor, werden möglichst schon maschinell erzeugt. Unter betriebswirtschaftlichen Aspekten lassen sich diese Daten schnell unter den verschiedensten Aspekten aufbereiten:

• Performanz; die Geschwindigkeit des Systems hängt von verschiedenen Parametern ab:
  • der Hardware;
  • der Indexierung der Daten;
  • der Suche nach HASH-Verfahren;
    • HASH Verfahren bieten eine Lösung für das Problem aus einer großen Anzahl von Daten ein bestimmtes Datum schnell herausfinden zu können. Dazu wird ein HASH-Schlüssel gebildet durch den die Daten durch eine große Anzahl von Klassen indexiert werden, so daß verschiedenen Teilmengen mit ähnlichen Attributen entstehen. (Z. B. die alphabetische Ordnung der Namen in einem Telefonbuch). Über diese Tabelle wird dann ein Inhaltsverzeichnis des Inhaltsverzeichnisses gelegt, über das der Suchvorgang beschleunigt werden kann. Der Nachteil diese Systems besteht darin, das neue Daten eine Ergänzung der Tabelle und eine damit verbundene sorgfältige Pflege des Indexes erforderlich machen.
  • der angemessenen Art der Informationsdarstellung;
  • dem mehr oder weniger geschickten Datenbankentwurf.
• Preis-Leistungsverhältnis:
  • Fixkosten:
    • Anschaffungskosten für Soft- und Hardware;
    • Entwicklungskosten für neue Datenbanken;
    • Migrationskosten bei bestehenden Datenbanken auf neue Software (und ev. auch Hardware);
  • variable Kosten:
    • Sicherungskosten;
    • Administration;
    • Lizenzgebühren ( von der Anzahl der Benutzer abhängige Gebührenstaffelung etwa 1 - 50 Nutzern, 51 - 100, etc.)
      • Releasewechsel: diese können einen ganzen Ratenschwanz von Veränderungen nach sich ziehen, etwa die eingeschränkte Zusammenarbeit mit einer bestimmten Softwareversion einer mit dieser zusammen genutzten Software, vielleicht sogar eines Updates des Betriebssystems, damit verbunden einer Hardewareaufrüstung bis zur Neuanschaffung der Hardeware.
  • Die Skalierbarkeit einer Datenbank. Ingenieurtechnisch ausgedrückt: Der Hersteller bietet ein Baukastensystem mit unterschiedlich leistungsstarken Komponenten, aus denen die richtige nicht nur für den Moment , sondern auch für die absehbare Zukunft herauszugreifen ist - unter Berücksichtigung des Kostenaspektes!
  • Redundanzprobleme der Datenbank: Jede Information sollte nur an einem Ort abgelegt werden. Die Ablage an verschiedenen Orten sorgt in der Folge für Unübersichtlichkeit.
  • Konsistenz: Die logische Widerspruchsfreiheit einer Datenbank kann nur durch eindeutige Informationskennzeichnung erreicht werden.
  • Integrität: ist die Konsistenz und die Korrektheit ( d. h. der richtige Eintrag der Daten an der richtigen Stelle in der Datenbank).
  • Gute Administrierbarkeit durch klare Anlage und Dokumentation der Datenbank.
  
  
  

  Historischer Exkurs: Wie kam es überhaupt zu Datenbanken?

  Es geht um die Integration betriebswirtschaftlicher Daten. In der Anfangszeit der Elektronischen Datenverarbeitung verlief diese anwendungs- oder applikationszentriert: Jede Anwendung hatte "ihre" Datenformate auf ihren Magnetbändern und nur sie konnte auf diese zurückgreifen. Damit waren die Applikationen aber auch von ihrem Datenformat abhängig. Nur bei einer Einigung über ein gemeinsames Format war es überhaupt möglich, das zwei Applikationen auf denselben Datenbestand zugreifen konnten. Erst eine Standardisierung der Datenformate führte zu einer Unabhängigkeit der Applikationen und der Möglichkeit, die unterschiedlichsten Daten in einem einheitlichen Datenbankkonzept zusammenzufassen und Applikationen hierauf zugreifen zu lassen.
  
  
  
  

  Das 3-Ebenen-Konzept:

  

  Zu Beachten sind die unterschiedlichen Normenkonventionen in der Bezeichnung der verschiedenen Elemente in den verschiedenen Ebenen!
  
  

  Constraints sind zugesicherte Eigenschaften eines Feldes, auf die hin ein Wert geprüft wird, bevor er in ein bestimmtes Feld eingetragen werden kann.
  
  

  
  
  

  Die Datenbankmodellierung: Das Entity-Relationsship-Modell
  
  

  Unter einer Entität wird die gedankliche Einheit verstanden, die unabhängig von anderen Entitäten einer Datenbank existieren kann. Realisiert wird sie in einer Datenbank als Tabelle. Eine Entität hat Attribute; realisiert als Spaltenüberschriften.
  
  

  Schreibkonventionen:

  ( ) bedeutet: besteht aus;
  [ ] bedeutet: zusammengesetztes Attribut;
  { } bedeutet: optionales Attribut (hier wäre ein NULL-Eintrag zulässig).
  
  
  
  

  Die Relation ist die Beiziehung zwischen zwei oder mehr Entitäten. Sie ist von der Existenz der Entitäten abhängig und hat eine bestimmte Ausprägung.
  
  
  
  

  Binäre Relation:

  

  1 bedeutet: eine Relation muß vergeben werden ( einer muß reparieren);

  0..n bedeutet: (0) die Relation muß nicht vergeben werden, (n) kann aber beliebig oft vergeben werden.
  
  

  Auch hier gilt: die Notationen beruhen auf Übereinkünften, die von Firma zu Firma unterschiedlich sein können!
  
  

  Optionale Relation: kann, aber muß nicht eintreten.

  Relation höherer Ordnung: mehrstellige Relation

  

  Mehrstellige Relationen lassen sich in binäre Relationen und eine zusätzliche Entität auflösen. Die zusätzliche Entität enthält die Zuordnung der Ausgangsrelationen.
  
  

  Beispiel: Entwicklung einer Datenbank für ein Autohaus: KFZ-Verkauf und Wartung:

  
  
  
  
  

  es bedeuten:

  ^1... eine MUSS-Relation; jedes Teil muß mindestens einem Element der anderen Entität zugeordnet sein.

  0... eine KANN-Relation; es kann zugeordnet werden, es muß aber nicht zwangsläufig ein Element geben, das zugeordnet werden muß!
  
  

  Beschreibungen der Relationen:

  muß haben
  
  

  

  wird vergeben an

  1 wenn nur die Monteure einen Ausweis haben;

  0 wenn auch andere Mitarbeiter einen Ausweis haben.

  

  wird ausgeführt von

  0 Monteur steht noch nicht fest

  [oder: 1 Monteur muß zugeordnet sein]

  verantwortet

  0 keine

  n mehrere

  [oder: die Zuordnung eines Meisters, der für die Reparatur verantwortlich ist.]
  
  

  

  Benötigt

  0 keine Ersatzteile

  n Ersatzteile

  wird benötigt

  0 Teil ist im Augenblick nur für das Lager bestimmt

  1 wird in einem oder mehreren Exemplaren benötigt
  
  

  

  wird durchgeführt am

  1 für ein KFZ

  benötigt

  0 Aufnahme in DB ist nicht von Reparaturauftrag abhängig

  n kann mehrere Reparaturen benötigen
  
  

  

  gehört

  0 (Neu-)Wagen im Firmenbesitz

  1 gehört einem Kunden

  ist Eigentum von

  0 hat kein KFZ

  n kann beliebig viele KFZ haben
  
  
  
  

  Problemfälle bei der Bestimmung von Relationen:
  
  

  Mehrstellige Relationen sollten möglichst in binäre Relationen aufgelöst werden, indem Entitäten aufgespalten werden. Ist dieses nicht möglich, so kann man diese über eine neue Entität, welche die Zuordnung enthält, aufgelöst werden:

  

  Eine n : m -Relationen kann mit Hilfe einer Entität "Zuordnungstabelle" auf zwei 1 : n -Relationen reduziert werden:

  

  Eine weitere Möglichkeit besteht darin, daß ich eine Entität in zwei Entitäten aufspalte, die in einer 1 : 1-Relation zueinander stehen.
  
  
  
  

  Primärschlüssel und Fremdschlüssel
  
  

  Primärschlüssel sind an Entitäten gebunden. Potentiell hat jede Entität einen Primärschlüssel, auch wenn es Fälle geben mag, in denen er nicht angelegt wird.
  
  

  Ein Primärschlüssel muß:

  1. eindeutig sein, d. h. dieser Eintrag darf genau nur einmal auftreten und nur einmal an eine Entität vergeben werden.
  2. Ein Schlüsselfeld ist ein Pflichtattribut, das einen Eintrag heben muß (Musseintrag).
  1. Unter Umständen können verschiedenen Attribute einer Tabelle für die Funktion Primärschlüssel in Frage kommen.
  2. Ein Primärschlüssel kann unter Umständen durch die Kombination mehrerer Attribute einer Tabelle gebildet werden - Kombinationsschlüssel.

  
  
  

  Beispiel: Zwei Niederlassungen eines Konzerns vergeben unabhängig voneinander Personalnummern. In einer Tabelle "Mitarbeiter", in der alle Angestellte des Konzerns eingetragen sind, können die Attribute "Werk-Nr." und "Personalnummer" zusammen den Primärschlüssel bilden.
  
  

  Notation: Attribute, die den Primärschlüssel darstellen, werden unterstrichen. Eine gestrichelte Linie kennzeichnet den Fremdschlüssel.

  

  Ein Fremdschlüssel ist eine Deklaration an einem oder mehreren Feldern (entsprechend dem Primärschlüssel der Entität) in einer anderen Entität. Lege ich zur Auflösung einer mehrstelligen oder einer n : m - Relation eine neue Entität an, so entsprechen die dort angelegten Attribute jeweils dem oder den Schlüsselattribut(en) der durch die neue Entität verbundenen Entitäten. Dadurch wird referentielle Integrität erzwungen:

  1. Die Einträge des Fremdschlüssel werden nur entsprechend dem Primärschlüssel vergeben.
  2. Im Primärschlüssel können Einträge nur dann gelöscht werden, wenn diese nicht auch vom Fremdschlüssel verwendet werden.
  
  
  

  Wird die Kombination aller Attribute der erzeugten Entität zum Primärschlüssel (Kombinationsschlüssel) deklariert, so werden damit Doppeleinträge ausgeschlossen. Wird ein Primärschlüssel auch als Fremdschlüssel verwendet, so kann er nicht bearbeitet werden. Schlüsselfelder dürfen keine NULL-Einträge haben und müssen unique sein: jeder Wert darf nur einmal auftreten. Wird ein Eintrag des Primärschlüssels im ebenfalls im Fremdschlüssel geführt, so kann er nicht bearbeitet werden.
  
  

  Vorsicht: der Begriff Sekundärschlüssel kann synonym mit diesem Begriff des Fremdschlüssels verwendet werden.

  Aber: Zum Sekundärschlüssel kann ein Attribut in einer Entität deklariert werden, in der schon ein Primärschlüssel deklariert ist. Das Attribut muß ebenfalls den Voraussetzungen eines Primärschlüssels entsprechen.
  
  SQL - Befehle für Access