Die Idee hinter Multidimensionale Datenbanken - Attrappen

Multidimensionale Datenbanken (MDDBs) die Konventionen ihrer relationalen Vorfahren werfen und organisieren, Daten in einer Weise, die sehr förderlich für die multidimensionale Analyse ist. Um mehrdimensionale Datenbanken zu verstehen, müssen Sie daher zunächst die Grundlagen der analytischen Funktionen verstehen, die mit den in ihnen gespeicherten Daten ausgeführt werden.

Die mehrdimensionale Analyse basiert auf ein paar einfachen Datenorganisationskonzepten - insbesondere Fakten und Dimensionen:

• Daten: A Tatsache ist eine Instanz von einem bestimmten Ereignis oder ein Ereignis und die Eigenschaften des Ereignisses alle in einer Datenbank gespeichert. Haben Sie am letzten Freitagnachmittag eine Uhr an einen Kunden verkauft? Das ist Fakt. Hat Ihr Geschäft gestern eine Lieferung von 76 Klassenringen von einem bestimmten Lieferanten erhalten? Das ist eine andere Tatsache.

• Abmessungen: A Dimension ist ein Tastenbeschreibungs-, ein Index, mit dem Sie Tatsachen entsprechend dem Wert zugreifen können (oder Werte) Sie wollen. Beispielsweise könnten Sie Ihre Verkaufsdaten nach diesen Dimensionen organisieren: Zeit, Kunde und Produkt.

Die Grundlagen

In diesen einfachen Beispielen können Sie Ihre Verkaufsdaten als dreidimensionales Array organisieren, das nach der Zeit, dem Kunden und den Produktdimensionen indexiert ist:

• Im Oktober 2008 (die Zeitdimension) kaufte Kunde A (die Kundendimension) Klassenringe (die Produktdimension) - 79 davon für 8 833.

• 2007 (die Zeitdimension) kaufte Kunde A (die Kundendimension) viele verschiedene Produkte (die Produktdimension) - insgesamt 3 333 Einheiten für 55, 905 (die Fakten).

Beachten Sie die feinen Unterschiede zwischen der Verwendung der Dimensionen in diesen beiden Beispielen. Im ersten Fall bezieht sich die Zeitdimension auf einen Monat; die Kundendimension bezieht sich auf einen bestimmten Kunden; und die Produktdimension ist für ein bestimmtes Produkt.

Im zweiten Beispiel ist die Zeit jedoch für ein Jahr und nicht für einen Monat; Kunde ist immer noch derselbe (ein individueller Kunde); und Produkt ist für die gesamte Produktlinie.

Die mehrdimensionale Analyse unterstützt den Begriff der Hierarchien in Dimensionen. Beispielsweise können Sie die Zeit in einer Hierarchie von Jahr → Quartal → Monat organisieren. Sie können Fakten (oder die Konsolidierung von Fakten) in der Datenbank auf einer dieser Ebenen anzeigen: nach Jahr, Quartal oder Monat.

Ebenso können Sie Produkte in einer Hierarchie der Produktfamilie → Produkttyp → spezifische Produkte organisieren. Klassenringe können ein Produkttyp sein; "Klassischer Ring, moderner Stil, Onyx Stein" könnte ein spezifisches Produkt sein.Außerdem würden sich Ringe, Uhren, andere Ringe und andere Gegenstände in die Schmuckproduktfamilie einreihen.

Gibt es eine Begrenzung für die Anzahl der Dimensionen?

Theoretisch können Sie so viele Dimensionen in Ihrem multidimensionalen Modell haben wie nötig. Es besteht jedoch immer die Frage, ob Ihr mehrdimensionales Datenbankprodukt sie unterstützen kann. Aber hier ist eine wichtigere Frage - auch wenn ein Produkt eine bestimmte Anzahl von Dimensionen zulässt (zum Beispiel 15), macht es Sinn, ein Modell dieser Größe zu erstellen?

Sie sollten eng mit Ihren Benutzern zusammenarbeiten, um festzustellen, ob die Anzahl der Dimensionen Ihre Lösung zu komplex macht - und dadurch die Benutzerzahl begrenzt - oder die Benutzerfreundlichkeit verbessert - und somit die Benutzeranzahl erhöht.

Sie können beispielsweise der Dimensionsliste, die Zeit, Kunde und Produkt enthält, eine Geografie hinzufügen, damit Sie Fakten gemäß Vertriebsgebieten, Bundesstaaten, Städten und bestimmten Geschäften sehen und organisieren können.

Wie sollten Sie die Ebenen in einer Hierarchie auswählen?

Die Ebenen in einer Hierarchie ermöglichen es Ihnen, Drill-Down -Funktionalität auszuführen. Und da Sie mehrere Ebenen in einer Hierarchie haben, können Sie schnell Antworten auf Ihre Fragen erhalten, da die Informationen auf jeder dieser angegebenen Ebenen eingerichtet wurden, sodass die Informationen nur auf Ihre Abfragen warten.

Da mehrdimensionale Datenbanken recht starre Strukturen haben, die um die vor - Berechnung von Fakten herum aufgebaut sind (Erstellen und Speichern von Aggregaten in der Datenbank, anstatt eine Aggregation und Berechnung der Berichtszeit durchzuführen), Je mehr Dimensionen Sie haben und je mehr Ebenen in jeder Dimension vorhanden sind, desto größer sind Ihre Speicheranforderungen und desto länger sind Ihre Build- oder Ladezeiten.

Physikalische Datenbankstrukturen in einer MDDB

Obwohl fast alle MDDB-Produkte auf dem Konzept von Fakten, Dimensionen und Hierarchien aufgebaut sind, hat niemand eine MDDB-Standarddefinition entwickelt. In der Beziehungswelt war die Nichtstandardisierung auch ein Problem, insbesondere in Bezug auf Mehrwertfunktionen wie Einschränkungen und gespeicherte Prozeduren.

Die grundlegende relationale Tabellenzeilen-Spaltenstruktur war jedoch ziemlich einfach zu exportieren oder in eine einfache Datei eines Typs zu entladen und dann in ein anderes RDBMS-Produkt neu zu laden.

In der MDDB-Welt haben Anbieter eine Vielzahl unterschiedlicher Ansätze für die physische Darstellung von Daten ihrer jeweiligen Produkte gewählt. Sie alle suchen nach Möglichkeiten, Speicher- und Komplexitätsprobleme zu überwinden, die durch eine große Anzahl von Dimensionen (zum Beispiel mehr als 15) und tiefe Ebenen von Hierarchien (zum Beispiel 20 Ebenen tief) verursacht werden.

Wenn Sie Produkte evaluieren, sollten Sie sich nicht um physikalische Speichertechniken sorgen: Stellen Sie nur sicher, dass die logischen Darstellungen, die mit den Produkten geliefert werden (wie z. B. Hierarchien, Ebenen und Fakten) Ihre Geschäftsanforderungen erfüllen können… Beseitigen Sie Produkte, die klobig wirken oder beispielsweise ein Hierarchiemodell haben, das für Ihre Daten nicht richtig erscheint.

Nachdem Sie Produkte gefunden haben, die zu Ihrem Unternehmen passen, treten Sie (sozusagen) ein wenig in die Reifen, um zu sehen, wie sie im Inneren funktionieren.