Ein möglicherweise unterschätztes Problem ist oft tiefes Unverständnis darüber, dass Daten aufgeteilt und normalisiert werden müssen, um vernünftig relational abgebildet werden zu können. Dieser Vorgang wird erheblich beargwöhnt, selbst von Leuten, die es wissen müssten. Es gibt tatsächlich nicht selten Fälle, in denen (in einer Frage von so zentraler Bedeutung!) das Management selbst und eigenhändig (d.h. mit PowerPoint) aufwendige Datenmodellierung betreibt. — Diese Modelle sind oft auffällig durch Excel geprägt. Meist besteht die ganz elementare Anforderung, Daten direkt, d.h. mit Cut & Paste, aus oder nach Excel übernehmen zu können. Das führt zu gleich mehreren Konsequenzen:
- Man muss sich hinsichtlich der möglichen Datentypen einschränken und darf am besten nur Text-Typen verwenden.
- Man muss hinsichtlich der Primärschlüssel und relationalen Verknüpfungen und Bedingungen (constraints) sehr vorsichtig sein und darf nur laxe (oft gar keine) konkreten Festlegungen treffen.
- Beziehungen werden "durch Programmlogik" abgebildet, d.h. oft sind zeitaufwendige Suchen und komplexe joins notwendig, um die einfachsten Dinge zu ermitteln, weil keine klaren Beziehungen definiert sind.
- Inkonsistente Daten gelten nur als kleines Übel, denn das Vertrauen in die eigene Arbeit ist durchaus hoch.
- Daten, die sich ohne Aufteilung nicht unterbringen lassen, werden generell in Frage gestellt - am Ende verzichtet man sogar freiwillig darauf.
- Auch nicht zusammengehörende, sogar typfremde Informationen stehen zusammen in einer Tabelle.
Datenbankserver unterliegen offenbar einer gewissen, latenten Gefahr, zur Karrikatur ihrer selbst gemacht zu werden. Ein interessanter Fall, wo eine konkrete Benutzeroberfläche auf ein Design zurückwirkt.







0 Kommentare:
Kommentar veröffentlichen