Konzept zur Datenbanktrennung.

[alzaimar]

Ich habe mir die drei Seiten nicht durchgelesen, aber ich glaube, Du solltest dich mit den Begriffen 'Datawarehouse' und 'Business intelligence' vertraut machen.

Es ist ein Märchen, das heute Datenbanksysteme, und seien sie noch so potent, immer sowohl transaktionale Datensammler als auch potente Statistikerzeuger sein können (bei entsprechendem Datenaufkommen, wohlgemerkt). In der einschlägigen Literatur wird als Standardvorgehensweise eine Trennung von operationalen Daten und sog. dispositiven Daten vorschlagen.

Operative Daten sind die Daten, die für die tägliche Arbeit benötigt werden. Bei einem Großhandel wären das z.B. Kundenstamm, Produkte, Aufträge, Lager, aktuelle Inventur.
Dispositive Daten sind die Daten, die aus den operativen Daten im Laufe der Zeit anfallen (History), oder speziell aufbereitete Daten (z.B. tägliche Zusammenfassungen oder eine Inventurhistory als periodischer Snapshot) und für Statistiken für das Managament herangezogen werden. Diese Daten werden aus dem laufenden Betrieb extrahiert, teilweise zusammengefasst, harmonisiert und fehlerbereinigt (über "ETL-Prozesse").

Gut, wir haben dann also zwei Datenbanken, das ODS (Operational Data Store), mit dem man täglich arbeitet, das aber Daten vergisst (wenn sie nicht mehr benötigt werden), und ein Datawarehouse (bestehend aus mehreren Datamarts) die bestimmte Daten in mehrdimensionalen Datenwürfeln bereithalten. aus diesen Würfeln (Datacubes) können dann geschäftsentscheidende Statistiken extrahiert werden.

Das ODS ist i.d.R. in der 3NF ('Snowflag-Design'), wohingehend ein DWH/DM hochgradig redundant und nur auf performance hin ausgelegt ist ('Star-Design').

Im ODS sollten laufend die ETL-Prozesse (transaktional oder periodisch) Daten in die einzelnen Datamarts überführen und das ODS schlank halten.

So das mal als Überblick. Hoffe, das ich nicht am Thema vorbeigeredet habe.