10.2. Datenbestände in Normalformen history menue Letztmalig dran rumgefummelt: 02.03.16 19:38:49
Datenbanknormalisierung ist der mehr oder weniger gut geglückte Versuch, einen Datendiskurs aus informationstechnischer Sicht so aufzubereiten, dass er nur minimal redundant ist, konsistent auch in der Phase der Datenpflege bleibt, wenig NULLWERTE enthält und den Ausschnitt aus der Welt in der Nutzung der Datenbasis sauber darstellt. Alle Objekte müssen dazu eindeutig durch gemeinsame Merkmale beschrieben worden sein und relational ohne Zirkelverbund miteinander verknüpft sein.
Eindeutige DB-Normalisierung vermeidet Anomalien, welche sich in der Datenpflege ansonsten in jedem Falle ergeben.
  1. Eigenschaften von Datenbeständen - Firmen & Kunden
  2. Analyse eines Datenbestandes
  3. Projektmanagement in der praktischen Datenbanktechnik
  4. dBASE-Formulare

Datenbanken

Logo der Daten-Normalisierung

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

Informatik-Profi-Wissen
Quellen:

http://www.echtermann-online.de/computer/access/datenbankdesign.htm
1. Eigenschaften von Datenbeständen - Firmen & Kunden history menue scroll up
Die Normalformen beschreiben den Übergang vom einfachen Datenbestand zum maximal Objektrelationen Modell einschließlich sauberem Schlüsselkonzept sowie Einhaltung der Integritätsbestimmungen.

redundanzfreie sowie konsistente Datenbasis

Hier wird der Datenbestand einfach durch die formale und unkomplizierte Erfassung der Eigenschaften der Objekte beschrieben. So werden typische "Datenbanken" von Anfängern beispielsweise mit Works erstellt - professionelle Datenbanken lassen solche Arbeitsweise gar nicht zu! Fehlende Elemente sind momentan "NULL's", da sie derzeit nicht bekannt sind!

zugehörige Dateien sind derzeit:

kunden_und_firmen.txt

sowie normalisierung010.mdb

Firma Chef-Name Kunden-Name Kunden-Adresse Betreuer Betreuer-
Anschrift		 Firmen-Bank Vertriebs-Nummer der Firma Firmen-Umsatz 
Müller AG Herr Peters Frau Monske

Herr Schmitt

Frau Honkste

 München, Auweg 5

Magdeburg, Am Torweg 5

Chemnitz, Markthalle 5

 Herr Aukamp

Herr Fothe

Frau Marks

 

 Dortmund, Alleestraße 12

Magdeburg, Domplatz 17

Gera, Otto-Dix-Staraße 41

 HAUSBANK24

AKTIA T-BANK

 EH 1/02: 12.021,-

2/03: 13.232,-

3/09: 149.227,-

11/10: 67.092.-
Schneider Herr Wolff Frau Fordanow

Frau Wuddka

 Köln,  Brückstraße 1

Neustadt, Goethestraße 51

 Herr Gohlers

 

 Dortmund,  Alleestraße 122 FINALBANK FB 1/01: 11.890,-

2/03: 10.898,-
WFGKS Herr Hubert Frau Uhlmann

Frau Hokerls

 Köln, Am Ring 23

 

 Frau Maisel Dortmund, Am Teich 5 BLAULICHT5 EO 1/02: 12.800,-
 
Paper Connection Frau Schleske Herr Frokers

Frau Dannkers

 Berlin,  Brückstraße1

Gera, Bahnhofstraße 9

 Herr Söhnke

Herr Michal

 Potsdam, Platanenstraße 54

Leipzig, Grimmasches Tor 2

 GGGH-Bank

DHKP-HOST

FINALBANK

CHI-Bank

 UH 1/01: 11.890,-

2/03: 10.898,-
MEDIA-XXL Frau Peters Frau Gellke Hauptwohnsitz: Chemnitz, Markt 5

Nebenwohnsitz: Niederwürschnitz Adelsbergstraße 65

 Herr Strüweller Mittweida, Südstraße 21 CHESTNUT26

MOME-CONTROL

 CZ 1/07: 142.756,-

5/09: 25.987,-

5/12: 678.886,-

die "nullte" Normalform wird auch als ein Datenbestand bezeichnet

  • es existieren schon Attribute und es werden Objekt beschrieben
  • der Datenbestand ist konsistent
  • die Objekte werden durch ihre Merkmale beschrieben
  • ein Auffinden von Informationen ist grundsätzlich möglich - jauch ohne die mathematischen Modellen einer Datenbank
  • der Datenbestand ist redundanzfrei
Folgende Fehler und Probleme werden hierbei jedoch auftreten:
  1. Redundanz: Mehrfache Datenerfassung führt zu Datenduplikaten (z.B. Adresse des Betreuers Hr. Aukamp), Fehler bei der Dateneingabe führen dann sehr schnell zu Mehrdeutigkeiten im Datenbestand (siehe Fehler in der Adresse). Außerdem führt Redundanz zu Speicherplatzverschwendung: In kleinen Datenbanken wäre die Speicherplatzverschwendung zwar zu verkraften, denn ob die Datenbank 96 KB oder 2 MB groß ist, ist relativ bedeutungslos auf modernen Computern. Aber in großen Datenbanken spielt es schon eine Rolle, ob sie 10 MB oder 200 MB groß sind!
  2. Einfügeanomalie: Wird ein neuer Betreuer eingestellt und in die Datenbank eingegeben, der noch keinem Kunden zugeordnet ist, müsste eine fiktive Kundennummer vergeben werden (da jede Zeile einem Kunden entspricht!)
  3. Änderungsanomalie: Die Änderungsanomalie ist in der Praxis die schwerwiegendste. Inkonsistenzen im Datenbestand werden durch Tippfehler sehr leicht entstehen (Wenn z.B. der Betreuer Hr. Aukamp durch einen anderen Mitarbeiter ersetzt wird, müsste in jeder Zelle der Name und die Anschrift geändert werden). Würden Zellen dabei vergessen werden, so wäre der Datenbestand nicht mehr eindeutig. Man kann zwar durch Suchen & Ersetzen den Namen "Aukamp" durch "Breuer" ersetzen, aber nur, wenn der Name "Aukamp" auch immer richtig geschrieben wurde. Ein Datensatz mit dem falsch geschriebenen Namen "Aukamb" würde also nicht automatisch geändert werden, die Folge wäre eine Inkonsistenz im Datenbestand.
  4. Löschanomalie: Die Kundenbetreuerin Fr. Maisel ist momentan nur für einen Kunden zuständig. Würde dieser Kunde (also die komplette Zeile) gelöscht werden, wären auch die Daten der Kundenbetreuerin Fr. Maisel gelöscht.
Lösungen könnten wie folgt aussehen:

 
2. Analyse eines gegebenen Datenbestandes history menue scroll up

Voraussetzung für die Entwicklung eines praktisch auch funktionierenden Datenmodells sind konsistente (einander nicht widersprechende Daten - ein LKW kann zu einem Zeitpunkt nicht auf zwei verschiedenen Straßen unterwegs sein - das ist in der Welt und natürlich auch in der Datenhaltung falsch

Datenbestand

 
3. Projektmanagement in der Datenbanktechnik history menue scroll up
Hier zeigen wir von der simplen, jedoch integren Datenhaltung, wie man zu einem sauberen Schlüsselkonzept gelangt. Weder ist die Datenhaltung atomar, noch ist sie relational und somit logischerweise auch nicht frei von Redundanzen sowie "NULLWERTEN". Streng genommen entsteht jedoch die Masse der praktischen Datenerfassung genau auf diese Art und Weise.
   
   
4. dBASE-Enitity-Typen - Standard-Tables history menue scroll up
 

zur Hauptseite		 © Samuel-von-Pufendorf-Gymnasium Flöha © Frank Rost am 8. Dezember 2009 um 6.49 Uhr

... dieser Text wurde nach den Regeln irgendeiner Rechtschreibreform verfasst - ich hab' irgendwann einmal beschlossen, an diesem Zirkus nicht mehr teilzunehmen ;-)

„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 ;-)