1.1. Datenbankdefinitionen und bekannte DBMS - Begriffwelt der Datenbanken history menue Letztmalig dran rumgefummelt: 06.03.19 04:49:09

Eine Datenbank ist ein mächtiges und in seiner Anwendung beeindruckendes Werkzeug. Hierfür gelten allerdings zwei Einschränkungen: hinter der Anwendung einer Datenbank steckt durchaus eine gehörige Portion „Mengenlehre“ - wird dagegen verstoßen, ist das Ergebnis der Datenbanknutzung zwar wiederum beeindruckend, nur dann mit negativem Vorzeichen. Und: eine Datenbank verwendet Daten mit Strukturen, deren Ergebnis natürlich nur so richtig sein kann, wie die Strukturen und Daten. Veraltete Daten und/oder Strukturen liefern falsche (nämlich veraltete oder falsche) Ergebnisse. Es existieren verschiedene Datenmodelle, eines der zweckmäßigsten für die „mittlere“ Datenhaltung ist das „Relationenmodell“. Eines der ersten und ältesten relationalen Datenbanksysteme war dBASE. Auch wenn neuere Systeme erhöhten Leistungsumfang bieten, gelten immer noch Maßstäbe, die durch dBASE gesetzt wurden. Für praktische Datenbankentwicklung sollte immer die mögliche Erweiterung auf dBASE-Standard in Betracht gezogen werden.

  • Datenbanken vergessen nichts!!!
  • Datenbanken beschreiben „Objekte“ - durch Angabe gemeinsamer Attribute (Merkmale) eindeutig. Jedes zur betrachteten Menge - Diskurs bezeichnet - gehörige Objekt zeichnet sich durch die Möglichkeit der Darstellung solcher Eigenschaften aus (das müssen und werden nicht alle Eigenschaften sein, die das Objekt insgesamt hat!) - denn: eine Datenbank fasst Objekte mit einer notwendigen (also nicht einer möglichen) Sicht zusammen
  • Daten werden in Datenfeldern erfasst, welche durch drei Kriterien eindeutig angegeben werden können (und müssen): der Feldname, der Feldinhalt und der Felddatentyp
  • alle erfassten Eigenschaften eines Objektes bezeichnet man als Datensatz, dabei müssen nicht für jedes Objekt alle Eigenschaften erfasst werden, andererseits darf es keine doppelten Objekte geben
  •  je nach Ansichtsauswahl präsentieren sich Datenbanken als Tabellen oder Formulare, wobei im Formular immer genau ein Datensatz, in der Tabelle pro Zeile ein Datensatz (also insgesamt mehrere) zur Ansicht gelangen und durch entsprechende Vorkehrungen Sicherheiten zur Datenhaltung geschaffen werden können (Überschreibsicher, Eingaben in bestimmten Toleranzbereichen usw.)
  • Reihenfolge der Attribute sowie auch der Datensätze ist informationstechnisch unerheblich (nicht von Bedeutung), da Sortierung bzw. PROJEKTION, JOINING sowie SECTION auf den entsprechenden Kriterien die jeweils benötigte Ordnung schaffen
  • in der Tabellenansicht können sich bei einfach organisierten Datenbanken Redundanzen ergeben
  • von einer Datenbasis erwarten wir sechs Dinge, die aber häufig gar nicht gegeben und/oder im Lebenszyklus einer Datenbasis beizubehalten sind:
    • die Daten sind vollständig - das gilt sowohl auf den Datensätze als auch auf die erfassten Attribute - eventuell bezogen auf den betrachteten Realitätsausschnitt (wenn ich gar nicht alles wissen will, brauch' ich auch nicht alles zu erfassen)
    • eventuell vorhandene NULLWERTE sind eindeutig Werte, welche es definitiv nicht gibt (im Sinne: es gibt definitiv keine Information) - und darüber gibt es keine Zweifel (... das ist praktisch unmöglich!)
    • die Daten sind richtig und aktuell
    • die Daten sind konsistent (widerspruchsfrei)
    • die Daten sind redundanzfrei erfasst (in der Praxis gar nicht so einfach)
    • dBASE-kompatibel (das heißt, am geltenden Standard orientiert)
0. Die zehn Gebote der Datenbanktechnik sowie ganz praktische Tipps
1. Ansatz von Definitionen für wirklich verschiedene Ansprüche - Zusatz: Hinweise zum praktischen Datenhandling
2. Aufbau eines Datendiskurses
3. Aufbau eines Entity-Typs
4. Immer wieder gern begangen: Die Todsünden der Datenbasenverwaltung
5. Tipps'n Tricks
6. Verwandte Themen

Datenbanken

Logo für die Database Management-Systems

inhaltlich auf korrektem Stand - evtl. partiell unvollständig ;-)

Wissen für Fortgeschrittene der Informatik

Quellen:
Datenbankentheorie zu erkennen und Datenbasen auf einem konkreten DBMS zu entwickeln ist kein Spaziergang - dahinter stecken mathematische Denk- und Abstraktionsvermögen und eine gute Portion Erfahrung
Erste Aufgabe einer Datenbank ist das schnelle Auffinden von Informationen - nicht das Halten von Daten
Die Reihenfolge von Attributwerten und Tupeln ist aus informationstechnischer Sicht unerheblich - sie kann durch Queries und/oder Sortierungen jederzeit angepasst werden - mit anderen Worten: die Aneinaderreihung von Informationen ist intern egal ;-)

0. Die zehn Gebote der Datenbanktechnik sowie ganz praktische Tipps history menue scroll up
Hier nun folgen heilige Kühe, welche im wahrsten Sinne des Wortes vom Berge Sinaii der Datenbanktechnik herrühren - welche von kaum jemanden gekannt und von den meisten missachtet werden. Sie gelten deshalb nicht weniger und ihre Missachtung ist Schuld an so manchem Computerneukauf und/oder fehlinterpretierten Datenbestäendenusw.
... die zehn Gebote! Kleiner Begriffs- und Erfahrungs-Katalog zum Thema Datenbanksysteme für Anfänger - Stand Februar 2019

Logo für die 10 Gebote der Datenbanktechnik

  • Du sollst als erstes richtige Datenformate wählen und das Dokument speichern!

  • Du sollst die Datenhaltung immer eindeutig, aktuell und korrekt führen!

  • Du sollst zum Datenzellenwechsel nicht die ENTER-Taste benutzen, wohl aber die Tabulator-Taste.

  • Du sollst nicht mehr als eine Information in jede Datenzelle eintragen, es sei denn, es gilt eine zulässige Ausnahme!

  • Du sollst nicht gleiche Merkmale mit verschiedenen Merkmalswerten beschreiben!

  • Du sollst keinen beliebigen Eintrag in unbekannte Datenfelder setzen, sondern sie frei lassen!

  • Du sollst nicht verwenden in Datenbanken Abkürzungen!

  • Du sollst wissen, dass die Anordnung der Datensätze und der Datenfelder für die Datenbank unerheblich ist!

  • Du sollst in Datenbanken nicht formatieren, es sei denn, es handelt sich um einen Standard (€ oder %)!

  • Du sollst nicht benutzen den Datentyp Zahl, wenn in das Datenfeld keine Zahlen eingetragen werden (Telefonnummer, Postleitzahlen)!

... siehe auch: Hinweise zur Informationsverwaltung mittels Datenbasen
  • Aufgaben einer Datenbank: ... schnellstens richtige sowie aktuelle "Informationen" sowie Zusammenhänge" finden und auswerten können
  • Relationship - Beziehungen:
    • ... haben z. B. PERSONEN und auf diese angemeldete AUTOS - deswegen auch der Begriff: Relationale Datenbanken
    • ... das ist die "Beziehung" zwischen genau zwei Entity-Types - dazu muss es in den beiden Entity-Types ein typ- sowie namensgleiches Atrribut geben (... das ist die notwendige Redundanz)
  • DBMS: ... das Database-Management-System - die Software, welche einen Datenbestand (Database) verwaltet
    Database: ein Datenbestand, welcher eine Gruppe von Objekten (einen Diskurs) über gemeinsame Eigenschaften eindeutig beschreibt
  • Referenz: ... ist der Verweis wischen zwei zueinander in Beziehung stehenden Entity-Types
  • Entity-Type oder Table: ... Gesamtmenge aller Tupel einer Objektgruppe
  • Datentypen: ... beschreiben das Format, wie die Daten zum Zwecke der Suche bzw. der Suche nach Zusammenhängen
    Attribut: eine Objekteigenschaft - eine Objektbeschreibung
  • Datenkonsistenz:
    • ... Widerspruchsfreiheit - Echtheit, Aktualität sowie Richtigkeit aktueller Datenbestände
    • ... sie  ist die Mutter aller korrekt funktionierenden Datenbasen
    • ... Voraussetzung dazu ist, dass alles ober- sowie unterhalb stehende genau eingehalten wurde
    • ... in der Praxis extrem schwer zu realisieren, wenn Datenbasen wirklich "leben"
  • Daten-Domain: ... das ist der Wertevorrat, welcher als Attributwert zugelassen ist
  • Dateneigenschaften: ... sie setzen sich zusammen aus dem Datentyp sowie der konkreten Beschreibung
  • künstliche Attribute: ... nicht wirkliche Merkmale eines Objektes wie FARBE und TYP - sondern z. B. das KENNZEICHEN an einem Auto
  • Datensatz oder Tupel: ... die Menge konkreter Atrributwerte, welche genau ein Objekt (Entity) beschreibt
  • Datenformat: ... Eigenschaft, wie die Attributwerte rechnerintern abgebildet und ausgewertet werden
  • Zahlenformat: ... in einem Computer ist 2 nicht gleich 2,00, unterschieden wird zwischen ganzen und gebrochenen Zahlen (und diese werden nochmals in verschiedene Typen gegliedert)
  • Textformat: ... hier werden die Datentypen unter anderem nach der Menge oder dem Inhalt sowie des Aufeinanderfolgens der Zeichen unterschieden (256 oder 65536)
  • Atomare Datenhaltung:
    • ... an einer Stelle wird genau eine Information gehalten - also z. B. keine Maßeinheiten - Realnamen wie "Stiller Ozean" sind atomar - er heißt ja so
    • mitunter wird das Konzept der Atomarität in der Praxis "gesprengt", wenn auf das Datenfeld definitiv keine oder nur definitiv immer korrekte Ergebnisse liefernde Operationen angewandt werden sollen
    • ... das ist z. B. für Straße und Hausnummer bzw. für Telefonnummern Vorwahl und Durchwahl in einem Datenfeld
  • Hilfsmittel zur Umsetzung der Atomarität:
    • Möglichkeit Nummer 1: ... es handelt sich um eine "Standard-Maßeinheit" wie "Euro", "km" oder "km²" - diese kann ich als Format schalten
    • Möglichkeit Nummer 2: ... in den Attributbezeichener - also ARC_KM2 (also Fläche (ARC) in Quadratkilometern (KM2))
    • Möglichkeit Nummer 3 - oft die beste: ... Es gibt eine "Legende" in welcher die einzelnen Attribute erklärt sind
  • NULLS:
    • ... gesprochen "NALLS" - das sind echte Nullwerte, diese kann eine Datenbasis korrekt auswerten, aber nur dann, wenn sie wirklich leer
    • ... sind in Databases extrem unerwünscht: es ist in der Praxis nicht mehr möglich, NULLs wahrheitsgemäß auszuwerten - sie lassen Interpretationen zu - die Datenbasis verwendet sie als "nicht vorhanden" - das muss aber nicht der Wahrheit entsprechen
    • statistisch werden sie aber intern korrekt verrechnet und die Ergebnisse sind auch richtig, wenn sie auch in der Praxis einen definitiv nicht existierenden Wert repräsentieren - ansonsten ist das Ergebnis in jedem Falle falsch
  • Redundanz: ... mehrfach vorkommende identische Information - in Datenbasen extrem unerwünscht (eine "notwendige" Redundanz bleibt aber in der Praxis)
  • Abkürzungen: ... werden in Datenbasen zur Objektbeschreibung nicht verwendet - sie lassen "Möglichkeiten" zu und diese sind für Datenbasen extrem unerwünscht
  • Inkonsistenz: ... ergibt sich vor allem durch falsch entwickelte Relationships und nicht beachtete Integritätsregeln - und vor allem: Korrekturen in falsch erstellten Relationen
  • Datenintegrität: ... bewahrt die Unversehrtheit sowie Echtheit der Daten
  • Attribut: ... genau eine Eigenschaft eines Objektes, welches eine Gruppe gleichartiger Objekte gemeinsam hat (z. B. die Farbe eines Autos) - diese Attributnamen werden mit Großbuchstaben notiert und sind maximal 10 Zeichen lang sowie immer in der Einzahl (obwohl mehrere Objekte beschrieben werden)
  • Attributwert: ... sind die realen Objektbeschreibungen, sie sind atomar, verwenden einheitliche Einträge, keine Abkürzungen sowie die wirklichen Zeichen, z. Umlaute sowie Groß- und Kleinschreibung - eben der konkrete Eintrag einer realen Eigenschaft - z. B.: die FARBE des AUTO's ist "blau" - hier wird geschrieben, wie die Realität es vorsieht
  • Datenanordnung: ... der reale Platz, an welchem die Attributwerte einer Objektbeschreibung eingetragen sind - in der Praxis ist sie beliebig
  • Aktualität: ... "unvollständige", "falsche" und/oder "alte" Daten liefern logischerweise "falsche Ergebnisse"
  • Datenbank: ... das ist die Summe aus einem DBMS sowie einem Datenbestand (Datebase)
  • Sortieren: ... eine der Mindestvoraussetzungen, damit Datenbanken schnell Zusammenhänge und/oder Informationen finden können
  • Schlüssel (Key): ... ein System, um Eindeutigkeit und/oder Zusammenhänge der Objekte (Entities) eines Datenbestandes (Database)
  • Primary-Key: ... macht ein Objekt unter vielen gleichen eindeutig identifizierbar (meist ein "künstliches Merkmal"!) kann niemals ein NULL sein - AUTO-Werte sollten nicht als Primarykeys verwendet werden
  • Foreign-Key:
    • ... das ist genau der Key, welcher eindeutig aus einem Tupel einer Objektmenge, eindeutig auf ein Element aus einem Element einer weiteren Menge mit vielen gleichartigen Objekten schließen lässt!
    • ... er muss auf den Primary-Key des anderen Entity-Types zeigen - bzw. umgekehrt: der Primary-Key zeigt auf den Referenzkey
  • Hinweise zu Primary & Foreign-Key:
    • ... nur durch diese können die Relationships der Entities hergestellt werden (... dabei ist es egal, ob es sich um 1 : 1, 1 : n oder m : n-Beziehungen handelt)
    • ... es können zu einem Betrachtungszeitpunkt immer genau zwei Entities miteinander verbunden werden
    • ... Primary- und Foreignkey müssen gleiche Datentypen haben und sie sollten gleiche Attributbezeichner führen (das muss angemerkt werden, weil es auch anders geht, aber dann zu Verwechslungen führen kann)
    • ... bei 1 : 1-Beziehungen ist der Foreignkey der Primarykey des Referenz-Entitiys
  • 1 : 1-Beziehungen:
    • ... sind selten und wenn, dann ist der jeweilige Primarykey die Referenz (er hat dann notwendigerweise den gleichen Datentyp in beiden Enitity-Types und sollte auch wirklich die gleichen Attributbezeichner führen)
    • ... sie dienen in der realen Datenbank-Praxis zur Trennung von Zugriffsrechten, da der Zugriff auf ein EnetityType gesperrt werden kann - jeduch nicht der Zugriff auf ein Attribut innerhalb eines Entity-Types
    • ... es muss nicht jedes Obbjekt mit Notwendigkeit in beiden Entity-Types vertreten sein
    • ... sollten besser 1 : 0-Beziehung heißen, denn es ist möglich, dass auf einer der Seiten NULL's enthalten sind (dies gilt jedoch nicht für die Key-Attribute)
    • zwei AUOTO-Keys können nicht zum Aufbau einer Relation genutzt werden - deswegen verwenden wir diese möglichst gar nicht erst
  • 1 : n-Beziehungen:
    • ... sind die häufigsten aller Relationships, dann ist die 1-Seite der jeweilig beteiligten Enitity-Types der Primarykey für die Referenz - der in der Referenztabelle der Foreignkey
    • ... sie müssen nicht die gleichen Attributbezeichner haben, sollten es es aber
    • ... die referenzierenden Enitity-Type-Attribute müssen über  die gleichen Datentypen verfügen (... dies sind Primary- sowie Foreignkey)
    • ... das Merkmal zur n-Refernz muss immer der Foreignkey sein und folgerichtig auch in der X : n-Tabelle stehen!!!
    • ... auf der n-Seite stehen in der Regel mehr Objekte, als auf der 1-Seite - es ist möglich. dass der Foreignkey NULL's enthält
    • ... Foreignkey können NULL's enthalten
  • m : n-Beziehungen:
    • ... leider entpuppt sich inder Praxis so manche 1 : n gesetzte Beziehung dann doch als m : n Relationship
    • ... hier haben viele Elemente der einen Seite mit vielen Elementen auf der anderen Seite zu tun - dies lässt sich nicht mehr durch gegenseitige Referenzen wie bei 1 : 1 oder 1 : n realisieren
    •  
  • Index: ... das ist der Bezeichner, welcher die Stelle eindeutig beschreibt, an welcher ein Element der gesuchten definierten Menge steht (dabei kann es physisch an einer anderen Stelle stehen)

Datenbankbegriffe - die Vertiefung

  1 : n Relationship  
 

1 : n-Beziehung

1 : n-Beziehung

 
Praktische Tipps und Tricks im Umgang mit DBMS:
Datenbanken sind als Informationssammlungen nicht neu - sie werden nur seit neuerer Zeit auf Computern eingesetzt
Datenbanken liefern bei Abfragen die Genauigkeit, die bei der Dateneingabe, Aktualisierung und Fehlerbereinigung aufgewandt worden ist (fehlerhafte Datenbanken liefern falsche Ergebnisse!)
Pro Merkmal darf genau eine Information stehen, wenn die Ausnahme nicht begründet oder definiert ist (Straße und Hausnummer oder Landesbezeichnungen)!!!
alle Objekte mit gleichen Eigenschaften müssen auch durch gleiche Merkmalswerte beschrieben werden also Volkswagen und nicht VW miteinander mischen!!! Kläre die eindeutige Schreibweise aller konkreten Datenmerkmale für gleiche Informationen - also entweder für die Herkunft der Pferde "England" oder "englische Abstammung", aber keinesfalls diese Einträge beide in einem Diskurs verwenden!
Nicht bekannte oder nicht existente Informationen werden als NULLWERTE bezeichnet und bleiben frei!!! ABER: NULLWERTE sind in der Interpretation problematisch
Datenbanken dienen dem schnellen Informationszugriff!!!
Die Informationen einer Datenbank werden in Datenfeldern gespeichert! Datenfelder bestehen aus Feldnamen und -inhalt! Datenfelder besitzen einen Datentyp, welcher für die korrekte Datenverwaltung von fundamentaler Bedeutung ist!
einfache Datenbankmanagementsysteme unterstützen kein Schlüssel- sowie Relationenmodell und sie verfügen auch nur über ein minimales Sicherheitssystem! (Datensätze können problemlos doppelt eingetragen werden, falsche Eingaben werden nicht abgefangen)

1. Datenbankdefinitionsversuche history menue scroll up
Datenbanken beschreiben Objekte durch Angabe gemeinsamer Eigenschaften (Merkmale) eindeutig. Die Menge aller Eigenschaften eines Objektes bilden den Datensatz (Tupel). Zusammengehörige aber nicht gleiche Objekte mit gemeinsamen (wiederum nicht gleichen!) Eigenschaften werden in einem Diskurs zusammengefasst. Die Informationen in Datenbasen nennt man Merkmals- oder Attributwerte. Die Menge aller möglichen Attributwerte nennt man "Domain" - nicht zu verwechseln mit einer Internet-Domain. Attributwerte können auch einen NULLWERT enthalten. NULLWERTe sind kritisch - sie lassen Interpretationen offen, also genau das, was eine Datenbasis überhaupt nicht gebrauchen kann.
Datenbasen werden auf einem Datenbanken Managementsystem erstellt. Erst die Summe von Datenbasis und Datenbanken-Magementsystem ergibt die Datenbank
Datenbasen , erstellt auf einem Datenbanken Managementsystem sind durch Konvertierung grundsätzlich anpassungsfähig - einzige Vorraussetzung; die Standards werden gehalten - werden sie aber in der Praxis nicht (wahrscheinlich von mir auch nicht 100%-ig)
Datenbanksysteme sind die Gesamtheit der nach einem vorgegebenen Datenmodell in externen Massespeichern aufbewahrten Datenmengen (Datei), die zu einem bestimmten Sachgebiet gehören. Datenbanksysteme dienen der Erfassung, Verwaltung, Verarbeitung, Änderung und Speicherung großer Mengen anfallender Daten nach einem bestimmten Ordnungsprinzip unter Berücksichtigung notwendiger Erfassungskriterien immer unter dem Aspekt der schnellen Verfügbarkeit von Detailinformationen. Eine Datenbank ist damit eine selbständige und auf Dauer ausgelegte Datenorganisation, welche einen Datenbestand sicher und flexibel verwalten kann.

Datenbank, System zur Speicherung großer Datenbestände mit dem Ziel, optimale Informationsgewinnung bei sehr kurzen Zugriffszeiten zu ermöglichen. In der kommerziellen Datenverarbeitung versteht man unter einer Datenbank die Zusammenfassung von Dateien, die die Basis für ein formalisiertes Informationssystem in einem abgeschlossenen Organisationsbereich bilden.

Definition und Aufgaben:

Es geht also darum, beliebige Daten verwalten zu können. Bei diesen Daten kann es sich z.B. um Personendaten handeln, welche nur gewissen Benutzern zugänglich sein dürfen. Unter dem Verwalten von Daten versteht man das Eingeben von neuen Daten, das Löschen veralteter Daten sowie das Nachführen bestehender Daten (aktualisieren). Außerdem können Informationen abgefragt und die vorhandenen Daten vor Verlust geschützt werden.

relevante Datenbankbegriffe Datenbanken im Informatikunterricht DBMS-Modell Datenbanken

Datenbankbegriffe

Datenbaksysteme und Elemente im Kontext des Unterrichts

... hier als CorelDraw-Grafik

Allgemeines DBMS-Modell

  • Definition: Ein Datenbanksystem (DBS) ist die Zusammenfassung
    einer Datenbank (DB) und eines Datenbankbetriebssystems (DBBS)
    DBS = [DB,DBBS]

  • ... n der Literatur findet man anstelle des Begriffes Datenbankbetriebssystem auch die Begriffe Datenbankmanagementsystem (DBMS) oder Datenbankverwaltungssystem (DBVS).

Allgemeines Datenbankmodell

die wichtigsten DBMS in der Übersicht
DBMS seit 1) Bemerkungen 2)
Allgemeine Systeme
System / R 1973 IBM-erste Implementation
INGRES 1976 ursprünglich Entwicklung einer Universität
PASCAL / R 1978 Erweiterung von PASCAL (heute Borland Database Engine)
QBE 1978 IBM
ORACLE 1979 Oracle Corporation
RAPPORT  1979  
System R / SQL 1979 IBM
MIMER 1980 Universität Uppsala  / MIMER AB
RAPID 1980 Kanada: Statistisches Landesamt
SAS 1980 integriert in Statistiksystem
DB 2 1983 (?) IBM
SIR 1983  
INFORMIX 1985 (?) Informix Inc.
SYBASE 1986 Sybase Inc. 
Microsoft SQL-Server   Microsoft Corporation
spezielle PC-Systeme
dBASE II 1981 (?) Ashton-Tate
Clipper 1984 Nantucket Corp.
dBASE III 1984 Ashton-Tate
dBASE III Plus 1985 Ashton-Tate
PARADOX 1985 Ansa Software (heute: Borland)
Foxbase 1986 (?)  Fox Software Inc.
FoxPro 1989 Fox Holding
dBASE IV 1991 (?) Borland-Ashton-Tate
FoxPro 2.0 (unter Windows) von 1993 bis 2003 Fox Holding (heute: Microsoft) - nach der Version 6.0 nicht mehr weiter entwickelt - aber enorme Verbreitung
MS-ACCESS (unter Windows) ab 1993 Microsoft
PARADOX (unter Windows) ab 1993  Borland

allgemeine Systeme für verschiedene Plattformen

Im folgenden ist mindestens der Standard SQL89 zugrunde gelegt. Jedoch werden weitere, z. Z. noch nicht standardisierte Sprachelemente und Eigenschaften einbezogen, wobei der Schwerpunkt auf die Produkte der Firmen INFORMIX, MIMER und ORACLE gelegt wird.

1) Die Zeitangaben können nicht immer korrekt ermittelt werden.
2) Die Entwickler/Vertreiber sind durch Konzentration und Fusion ziemlich dynamisch zu sehen.

Aufgrund der unterschiedlichen Erweiterungen des gültigen Standards und der unterschiedlichen Vorgriffe auf zukünftige Versionen des SQL-Standards kann die Darstellung nicht vollkommen einheitlich und schon gar nicht vollständig sein. In der praktischen Arbeit mit Datenbankbetriebssystemen und SQL wird man immer auf die zugehörigen Dokumentationen zur spezifischen Implementation und Version des Datenbankbetriebssystems zurückgreifen müssen. Zu beachten ist insbesondere, dass auch bei gleicher Syntax des SQL-Statements durchaus erhebliche Unterschiede in der Semantik vorkommen können. Ziel der Darlegungen zu SQL, ACCESS und FOXPRO ist es, den Lernenden in die Lage zu versetzen, mit dem ihm vorliegenden konkreten DBMS zu arbeiten und auch komplizierte Aufgaben zu lösen. Detaillierte Fragen sind ohne weitergehende Studien jedoch kaum zu lösen.
In den vorliegenden Beiträgen zu SQL versuchen wir, eine weitgehend vollständige Beschreibung der Sprache zu erreichen. Die Dokumente sollen nicht nur dem Wissenserwerb die­nen, sondern auch als Nachschlagewerk zu verwenden sein. Die Darstellung erfolgt von den Basiskonstrukten bis zu den vollständigen Statements (Anweisungen). Die Anweisungen sind in der Reihenfolge geordnet, wie sie normalerweise beim Aufbau und der Nutzung einer Datenbank zu verwenden sind:

  • Definition der Datenbankstruktur (Definieren von Metadaten)

  • Statements zur Datenmanipulation (Eingabe, Verändern, Löschen von Daten), - Datenabfrage.

Ergänzt werden diese Gruppen durch Statements zum Datenschutz und zur Datensicherheit sowie zur Transaktionensteuerung. Nehmen Sie SQL als formalisierte Datenbanksprache nicht nur als isoliertes Mittel zur Kommunikation zwischen Anwender bzw. Anwendung und Computer bzw. Datenbank. SQL ist auch unverzichtbar, wenn Sie graphikorientierte Datenbankmanagementsysteme, wie ACCESS oder FoxPro/Windows verwenden. Beide Systeme gestatten (und erfordern oftmals) die Anwendung von SQL direkt, um kompliziertere Operationen auf der Datenbank anzuweisen.


2. Aufbau eines Entity-Types (Datentabelle) history menue scroll up
Das Entity-Type-Modell fasst einzelne Objekte mit gleichen Merkmalen zusammen. Das einzelne Objekt - das Entity - wird so im Entitype mit weiteren Objekten in Verbindung gebracht - die Objekte werden durch gemeinsame Merkmale beschrieben.

vereinfachtes Entity-Type-Modell

komplexes Entity-Type-Modell

  • in der Zeile werden die Eigenschaften eines Objektes beschrieben - das nennen wir den Datensatz oder das Tupel - hier dürfen keine Doppelungen vorkommen
  • in der Spalte werden alle Attributwerte, welche alle Objekte in einem Punkt gemeinsam besitzen, innerhalb der Domain des Attributs beschrieben - das nennen wir Attribut - hier dürfen Doppelungen vorkommen

Atomare Daten-Einträge

in einer Atrributwert-Einheit (man könnte sie auch Datenzelle nennen, darf sie dann aber nicht mit der Tabellenkalkulation verwechseln), steht genau eine gekapselte Information

Entity-Typen

Sie sind die Zusammenfassung von Objekten mit gemeinsamen Merkmalen - mehr dazu hier

Objekte - Entities

Objekte sind Elemente der uns umgebenden Welt, die sich durch Merkmale beschreiben lassen. Dabei kann ein Objekt wiederum aus Teilobjekten aufgebaut sein. Das Objekt Auto besteht z. B. aus den Teilobjekten Motor, Karosserie, Getriebe u. s. w. Objekte können auch unsichtbar sein (Strom, Gefühle, Wissen um einen Tatbestand)

Tupel oder Datensatz

Logo für den Datensatz oder das Tupel

  • ist genau ein Objekt innerhalb des Entity-Types mit all seinen Merkmalen einschließlich Nullwerten - hier wird genau ein Objekt möglichst redundanzfrei beschrieben
  • das Tupel entspricht genau einer Zeile innerhalb einer Datentabelle, wobei zugehörige Information zu diesem Objekt auch auf mehrere Entity-Types verteilt sein können

NULLWERTE

Logo für die Datenbasen-NULLWERTE

Datenbestand mit NULL's

Nullwerte sind freie Datenfelder, deren Informationsgehalt nicht dargestellt werden kann oder darf. Sie haben in Bezug auf Datenbasen kritische Eigenschaften, denn sie lassen Interpretationen zu - wir versuchen hier einmal zu interpretieren, was dies bedeuten kann, wenn ein Datenfeld leer ist:

  • Daten sind definitiv nicht vorhanden - und das ist auch exakt bekannt - es existiert keinerlei Unsicherheitsfaktor - ich kann den Attributwert nicht beschreiben
  • Daten sind definitiv vorhanden, aber nicht genau oder gar nicht bekannt - es existiert keinerlei Unsicherheitsfaktor in der Beschreibung - in der Auswertung schon - ich kann den Attributwert nicht beschreiben, da ich ihn nicht kenne
  • Daten sind vielleicht vorhanden - es existiert ein absoluter Unsicherheitsfaktor in der Beschreibung
  • Daten sind definitiv nicht vorhanden - es existiert keinerlei Unsicherheitsfaktor in der Beschreibung - in der Auswertung schon - ich kann den Attributwert nicht beschreiben, da er nicht vorhanden ist

Problem, welches bleibt: "... ich weiß es nicht, welcher der möglichen Interpretationspunkte gilt aktuell!"

NULL's werden von der SQL richtig und korrekt verarbeitet, aber eben nur so richtig, wie der Datenbestand selbst ist!

... und nun kommt, was der Fachmann nicht weiß und so auch folgerichtig nicht vermutet: Basis-JOIN einer Datenbasis ist das Karthesische Produkt - daraus folgt: "jeder existente "NULL" wird mit jedem anderen korrekten "NULL" verbunden - jegliche statistische Auswertung erfolgt anschließend - das nennt man dann einen "Ratenschwanz" von fehlern" - dies allein aus der "Ungewißheit der Zustände heraus!!!

Attribute - Datenfelder (Merkmale)

Das Datenfeld ist gekennzeichnet durch die Einheit von Datentyp, Feldbezeichnung, Feldinhalt und die Feldeigenschaften, wobei in gleichen Merkmalen auch identische Merkmalswerte anzugeben sind. Es darf also zum Kfz-Typ nicht einmal „Volkswagen" und ein anderes Mal „VW" eingetragen werden.

Attributwerte (Merkmalswerte, Kennzeichen)

... sind die einzelnen Eigenschaften eines Objektes, meist sind sie natürliche Kennzeichen des selben. Mitunter verwendet man aber auch künstliche Eigenschaften zur Objektbeschreibung - insbesondere, um Eindeutigkeit zu erzielen (siehe Primary Keys).

Domain

... das ist der Wertevorrat aller theoretisch möglichen Datenfeldeinträge eines Attributes, wobei gleiche Objekteigenschaften auch mit gleichen Merkmalen beschrieben werden müssen. Dabei muss die Domain in der konkreten Datenbank nicht vollständig ausgenutzt werden

Beispiel: Autos könnten blau sein, also ist "blau" ein Element der Domain "Farbe". Wenn aber kein blaues Auto vorhanden ist, dann kommt das theoretisch mögliche Merkmal eben konkret und aktuell nicht vor

View

... das ist Sicht auf einen Datenbestand oder dessen Teile. Ergebnis einer sinnvollen Sicht können u, U. mehr Daten sein, als aktuell eingegeben wurden - so genannte generierende Abfragen


3. Aufbau eines Diskurses history menue scroll up
Das Diskurs-Modell verbindet einzelne Objekte mit nicht gemeinsamen Merkmalen, jedoch gemeinsamen Zusammenhängen in einer Datenbasis. Datenbasis sowie Diskurs bilden somit eine begriffliche Einheit. Aus Sicht der Datenorganisation sprechen wir von einer Datenbasis, aus Sicht der Datenimplementation sprechen wir von einem Diskurs. Ein Diskurs besteht in aller Regel aus mehreren Entity-Types und diese sind untereinander durch das Key-Konzept in Verbindung gebracht worden.

vereinfachtes Diskurs-Modell

komplexes relational verknüpftes Diskurs-Modell

Diskurs

Diskurse

Der Diskurs ist eine Zusammenfassung mehrerer Entity-Types mit dem Ziel, Objekte, welche keine gemeinsamen Merkmale Attribute) besitzen, jedoch untereinander in Beziehung stehen, informationstechnisch miteinander zu verbinden. Er beschreibt eine Menge von Datentabellen, welche zu einer Datenbasis gehören. Das Diskursmodell dient zum Verringern von Redundanzen (Wiederholung von Daten). Redundanz gleich Null ist praktisch unmöglich - zudem dient der Diskurs zur Trennung von Datenbeständen, welche u. U. nicht gegenseitig einsehbar sein sollen oder dürften.

Relationenmodell

Der Diskurs ist eine Zusammenfassung mehrerer Entity-Types mit dem Ziel, Objekte, welche keine gemeinsamen Merkmale Attribute) besitzen, jedoch untereinander in Beziehung stehen, informationstechnisch miteinander zu verbinden. Er beschreibt eine Menge von Datentabellen, welche zu einer Datenbasis gehören. Das Diskursmodell dient zum Verringern von Redundanzen (Wiederholung von Daten). Redundanz gleich Null ist praktisch unmöglich - zudem dient der Diskurs zur Trennung von Datenbeständen, welche u. U. nicht gegenseitig einsehbar sein sollen oder dürften.


4. Die Todsünden der Datenbankarbeit history menue scroll up
Was wir niemals tun wollen, aber ausführen werden: das vollkommen falsche Verhalten parallel zu präzise geschriebene Regeln.
  • Dateninkonsistenz (widersprüchliche Daten, bedingt durch Korrekturen oder einfach Übertragungsfehler)

  • falsche Schlüsselkonzepte

  • Abkürzungen in Datenfeldinhalten (Abkürzungen ausschließen!)

  •  falsche Datentypen - Zahlen müssen Zahlen bleiben (Maßeinheiten gehören nicht in den Datenbestand oder müssen vom System selbst generiert werden)

  • NULLWERTE in Datenfeldern sind bezüglich der Datenbankauswertung immer kritisch - schon die Struktur (Datenfelder und Datentypen) muss so aufgebaut sein, dass möglichst keine Leerfelder vorhanden sind

  • krasser Fehler: NULL's zu verwischen z. B.: "?"; "unbekannt";"-" - wenn es wirklich nicht vorhandene Informationen sind, werden Sie in der SQL richtig verarbeitet

  •  nicht zu wissen, wie sich Leerfelder eines Datenbankmanagementsystems bei statistischer Auswertung verhalten

  • veraltete Daten

  • ENTER-Tasten statt TAB-Stop's

  • Leerzeichen in Datenfeldern besonders am Anfang

  • Apostroph statt Akcent (Rene' statt René)

  • mehrere Information pro Datenfeld (nicht atomare Informationsdarstellung)

  • Redundanzen (Wiederholungen) in den Datensätzen

  • falsche Datentypen und -relationen - diese zu korrigieren ist im Extremfall ohne Datenverlust unmöglich

  • für eine bestimmte Anwendung sollte man sich für ein Datenbanksystem entscheiden - im Nachhinein zu wechseln kann schwierig werden (WORKS z. B. verwendet kein Datentypenmodell - beim Konvertieren in dBASE gehen Daten verloren) - Anmerkung: WORKS 4.0 setzt mit Datentypen an und kennt aus Kompatibilitätsgründen immer noch den Datentyp „STANDARD“  


5. Tipps'n Tricks history menue scroll up
Was wir niemals tun wollen, aber ausführen werden: das vollkommene Verhalten neben präzise geschriebene Regeln.
  • verwenden Sie die für Ihre Daten relevanten Datentypen (Datum vom Typ Datum, Postleitzahlen vom Typ Text (denn sie sind Text!))
  • professionelle Datenbanken fordern ein minimales Schlüssel-Konzept, welches von Works nicht unterstützt wird. Schlüssel sind Datenfelder, die ein eindeutiges Unterscheidungskriterium schaffen, welches sich damit nicht wiederholen darf. Namensfelder sind dazu nicht gut geeignet, da sich Nachnamen schnell wiederholen können. Günstig ist, jedem Datensatz eine eindeutige „Schlüsselnummer“ zu vergeben
  • tragen Sie in jedes Datenfeld genau eine Information ein (wobei sich wenige sinnvolle Ausnahmen in der Datenhaltung durchgesetzt haben, z. B. Straße und Hausnummer gemeinsam zu erfassen, denn diese beiden Informationen stehen in einem jedermann bekanntem Zusammenhang) - dies muss jedoch bereits bei der Strukturplanung der Datenbank berücksichtigt werden
    Dateneinträge wie „1876 -1934“ für Lebensdaten sind also falsch, genau wie „2 km“ und „Romantik, Impressionismus, Rennissance“ - Ausweg: diese Datenfelder sind zu trennen oder die Maßeinheiten im Datenfeldnamen unterzubringen, etwa: „Entfernung in km“, „Epoche_1“, „Epoche_2“, „Epoche_3“ (dies ist zwar nicht die eleganteste, aber eine richtige Lösung). Dagegen ist der Eintrag „Rose Marie“ als Vorname richtig, ebenso wie „Äquatorial-Guyana“, da dies ja zusammengesetzte Namen und damit eine Information sind
  • Datenfelder, für die augenblicklich keine Information existiert, bleiben frei - man spricht von NULLWERTEN (die aber nicht die Interpretation = 0 erlauben, denn 0 ist eine konkrete Information. Dagegen bedeutet ein NULLWERT „unbekannt“!)
  • NULLWERTE verhalten sich in der Datenverwaltung immer kritisch - deshalb sind sie möglichst zu vermeiden
  • Sie erhalten völlig falsche Auswertungen der Daten, wenn Sie in NULLWERTE Informationen, wie z. B. „unbekannt“, einen Bindestrich oder „leer“ eintragen - Datenbanken gehen mit NULLWERTEN richtig um - Sie verfremden also mit solchen Einträgen Informationen
  • Reihenfolgen in der Anordnung der Datenfelder und der Datensätze sind völlig beliebig und haben für die Auswertung der Datenbank keinerlei Bedeutung. Eine Datenbank muss nur vollständig und aktuell sein!

6. Verwandte Themen history menue scroll up
Alle modernen elektronischen System arbeiten auf Basis eines Taksignales, welches heute oft über Quarzgeneratoren erzeugt wird. Computer bilden dabei eigentlich eher die Spitze des Eisberges - aber dort ist das Taktsignal noch am bekanntesten, denn die Arbeitsfrequenz der CPU ist eines der wichtigsten Merkmale der Computertechnik.
Bereich Datenbanken-Grund- und Aufbauwissen

Daten

Datensicherheit und Datenpiraterie

Datenschatten

Zahlensysteme

Anforderungen an DBMS

richtige oder falschen Datenbasen

System-Query-Language

 

Datenbasen-Entwurf

mengentheoretischen Grundlagen der Mathematik

mengentheoretischen Grundlagen der SQL

   
Bereich Begriffswelt der Informatik

Informationsbegriff

Nachrichten

Wissen

Systembegriff

Modellbegriff

Simulation

Denken und Sprache

Zahlen, Daten und Datentypen

Gegenläufigkeit und Verklemmung

Pattern-Matching

   
Bereich Datenfernübertragung

Datenübertragungsverfahren

OSI Referenz-Schichtenmodell

die RS232-Schnitttstelle

Tabelle des UNICODES

Kryptologie

Digitale Signale

Information, Nachricht und Signalbegriff

 

   
Bereich Kryptologie

Grundlagen der Kryptologie

Allgemeines zur Verschlüsselung

Steganografie

CÄSAR-Chiffre

Vigenère-Chiffre

der Babbage bzw. Kasiski-Test

Angriff auf den ENIGMA-Chiffre: Projekt ULTRA- oder Shark

   


zur Hauptseite
© Samuel-von-Pufendorf-Gymnasium Flöha © Frank Rost am 17. Januar 2008

... dieser Text wurde nach den Regeln irgendeiner Rechtschreibreform verfasst - ich hab' irgendwann einmal beschlossen, an diesem Zirkus (das haben wir schon den Salat - und von dem weiß ich!) nicht mehr teilzunehemn ;-)

„Dieses Land braucht eine Steuerreform, dieses Land braucht eine Rentenreform - wir schreiben Schiffahrt mit drei „f“!“

Diddi Hallervorden, dt. Komiker und Kabarettist

Diese Seite wurde ohne Zusatz irgendwelcher Konversationsstoffe erstellt ;-)