Relationale Datenbanken vs. Dimensional, was ist der Unterschied?

Question

Ich versuche, über OLAP und Data Warehousing zu lernen, und ich bin über den Unterschied zwischen relationalen und dimensionalen Modellierung verwechselt. Ist dimensionale Modellierung im Grunde relationale Modellierung, aber so dass für redundante / un-normalisierte Daten?

Zum Beispiel, sagen wir, ich historische Verkaufsdaten auf (Produkt, Stadt, # Umsatz) haben. Ich verstehe, dass die folgenden ein relationaler Point-of-View wäre:

Product | City | # Sales
Apples, San Francisco, 400
Apples, Boston, 700
Apples, Seattle, 600
Oranges, San Francisco, 550
Oranges, Boston, 500
Oranges, Seattle, 600

Während der folgenden ist eine mehrdimensionale Point-of-View:

Product | San Francisco | Boston | Seattle
Apples, 400, 700, 600
Oranges, 550, 500, 600

Aber es scheint, als ob beiden Standpunkte dennoch in einem identischen Sternschema implementiert werden würde:

Fact table: Product ID, Region ID, # Sales
Product dimension: Product ID, Product Name
City dimension: City ID, City Name

Und es ist nicht, bis Sie auf jede Dimension Hinzufügen einige zusätzliche Details beginnen, dass die Unterschiede auftauchen beginnen. Zum Beispiel, wenn Sie Regionen verfolgen, auch wollen, eine relationale Datenbank würde dazu neigen, einen separaten Bereich Tisch zu haben, um alles zu halten, normalisierte:

City dimension: City ID, City Name, Region ID
Region dimension: Region ID, Region Name, Region Manager, # Regional Stores

Während eine dreidimensionale Datenbank für Normalisierungs erlauben würde, die Bereichsdaten in der Stadt Dimension zu halten, um es einfacher zu machen, um die Daten zu schneiden:

City dimension: City ID, City Name, Region Name, Region Manager, # Regional Stores

Ist das richtig?

Answer 1

Ein Sternschema wirklich liegt an der Kreuzung des relationalen Modells von Daten und dem dreidimensionalen Modell von Daten. Es ist wirklich eine Art und Weise mit einem dreidimensionalen Modell des Startens und in SQL-Tabellen zuordnen, die etwas die SQL-Tabellen, die Sie bekommen ähneln, wenn Sie von einem relationalen Modell starten.

Ich sage etwas ähneln, weil viele relationalen Design-Methoden in einem normalisierten Design führen oder zumindest ein nahezu normalisierte Design. Ein Sternschema wird erhebliche Abweichungen von der vollständigen Normalisierung.

Jede Abweichung von vollständiger Normalisierung trägt damit eine konsequente Datenaktualisierung Anomalie. (Ich bin einschließlich anomlaies auf Einfügen, Aktualisieren und Löschen von Operationen unter einem Dach). Diese Anomalien haben nichts mit dem zu tun, was Datenmodell Sie begann mit.

Der Kommentar auf OLTP im Vergleich zu OLAP ist hier relevant. Update Anomalien haben unterschiedliche Auswirkungen haben auf die Leistung und / oder Programmierung Schwierigkeiten in diesen beiden Situationen.

Neben ein Sternschema in einer SQL-databaase gibt es dimensionale Datenbankprodukte gibt, die Speicherung von Daten in einer physischen Form, die zu diesem Produkt einzigartig ist. Mit diesen Produkten, sehen Sie nicht ein Star-Schema so viel wie Sie eine direkte Umsetzung des dreidimensionalen Modells zu sehen, und eine Schnittstelle, die speziell für das Produkt sein könnten. Einige dieser Schnittstellen ermöglichen OLAP-Operationen vollständig Point-and-Click sein.

So wie ein Exkurs aus Ihrer Frage, ich einmal ein Star-Schema als einen Zwischenschritt zwischen einer OLTP-Datenbank aufgebaut, die eine Transaktion basierte Anwendung und einem Datenwürfel innerhalb Cognos PowerPlay unterstützt. Unter Verwendung von Standard ETL-Techniken, die kombinierte Übertragung von der OLTP-Datenbank des Sternschema und dann aus dem Sternschema auf den Datenwürfel tatsächlich die direkte Übertragung von der OLTP-Datenbank auf den Datenwürfel übertroffen. Dies war ein unerwartetes Ergebnis.

Hope, das hilft.

Answer 2

In einfachen Worten normalisierte Datenbank OLTP mit optimalste „transaktionale“ Sicht ausgelegt. Datenbanken werden normalisiert optimal auf ein Transaktionssystem zu arbeiten. Wenn ich Optimierung von Transaktionssystem sagen, ich meine, zu einem Design Zustand der Datenbankstruktur ..getting wo alle transaktionalen Operationen wie Löschen, Einfügen, Aktualisieren und ausgewogen wählen gleich oder optimalen Wert auf alle von ihnen an jedem Punkt der Zeit zu geben .. .as sind sie ebenso in einem Transaktionssystem bewertet.

Und das, was ein normalisiertes Systemangebot ..minimal aktualisiert möglich, dass eine Aktualisierung der Daten, minimal Einsatz möglich für neuen Eintrag, einem Ort für die Kategorie löschen Löschen usw. (zB neue Produktkategorie) ... all dies ist möglich, ein wir Zweig ein Master-Tabellen erstellen ..... aber dies geht auf Kosten von „wählen Sie“ Betriebsverzögerung ..aber wie ich sagte, dass seine (Normalisierung) nicht die effizienteste Modell für alle Operationen ..its „Optimal“ ... gesagt haben wir bekommen andere Methoden zur Verbesserung der Daten speed..like Indizierung usw. Abrufen

Auf der anderen Seite Dimensional Modell (meist für Daten-ware-Haus-Design verwendet wird) .. bedeutete für Bedeutung zu geben, um nur eine Art von Operationen, das ist Auswahl der Daten ... wie in Daten-Lägern ..data Aktualisierung / Einfügen periodisch ..und sein eine einmalige Kosten geschieht.

Also, wenn ein Versuch normalisierte Datenstruktur zu optimieren, so dass nur die Auswahl der wichtigste Vorgang zu jedem beliebigen Zeitpunkt ist ... wir werden am Ende immer eine denormalized (I teilweise denormalized sagen würde) .. dimensionale Sternstruktur.

• alle Fremdschlüssel ein einem Ort Fact -NO Dimension zu Dimension verbinden (das heißt zu Master-Master-Tabelle beitreten) .. Snowflake repräsentiert gleiche Dimension
  • ideal ausgelegt Tatsachen tragen nur Zahlen ..measures oder Fremdschlüssel
  • Dimension wird verwendet, um Carry Beschreibung und nicht aggregierbare info
  • Redundanz von Daten ignoriert ... aber in seltenen Fällen, wenn Maße selbst zu viel .snowflake Design wachsen sieht, wie option..but dass noch vermeidbar ist

Weitere Informationen über detaillierte Bücher zu diesem Thema finden Sie.

Answer 3

Ich habe gerade vor kurzem lesen, auf der Differenz zwischen Dimensional und Relationale Datenmodellierung, da wir in erster Linie Relationale Modelle an meinem Geschäft verwenden, wo wir ein Enterprise Data Warehouse (EDW) speichern.

Laut Steve Hoberman in seinem Buch „Datenmodellierung Made Simple“ die Unterscheidung zwischen den zwei Arten von Modellen, ist dies:

• Relationale Datenmodelle erfasst die Business-Lösung für, wie ein Teil der Geschäfts Arbeiten, a.k.a Geschäftsprozess
• Dimensional Datenmodelle erfassen die Details um die geschäftlichen Anforderungen zu beantworten Fragen darüber, wie gut es tut

Es kann argumentiert werden, dass ein relationales Modell kann auch als Grundlage verwendet wird, auf das Business-Fragen zu beantworten, aber auf taktischer Ebene. „Wie viele Aufträge sind in einem unerfüllten Zustand für Kunden x aufgrund von Kredit halten?“ Aber der Unterschied ist, dass, wo die Berichterstattung Frage braucht das ‚nativen Korn‘ der Tabelle, und wenn der Bericht Frage kann mit zusammengefassten Daten beantwortet werden.

In Ihren obigen 2 Beispielen sind sie tatsächlich beiden Beispiele von Dimensional Datenmodellierung, da keiner der zwei Tabellen Kundenauftrag wird die Speicherung an seinem ‚nativen Korn‘ und daher nicht das Geschäfts nicht erfassen Prozess einen Kundenauftrag zu schaffen. Der einzige Unterschied zwischen den zwei Tabellen ist, dass die Stadt Dimension in der zweiten Tabelle hat sich in der Faktentabelle umgesetzt worden.

Answer 4

ich die Beschreibung gefunden Ich habe bei http://www.orafaq.com/node/2286 sehr hilfreich sein, wenn sie auf star-Schema ist aus einer relationalen Perspektive kommt.

Betrachten wir ein vollständig normalisiert Datenmodell. Jetzt denken Sie an genau das Gegenteil, wo Sie voll relationales Datenmodell denormalize so dass Sie nur eine flache Platte wie eine big'ol Tabelle mit einer sehr breiten Reihe haben. Jetzt von dieser Wohnung Rekord sichern nur ein wenig so gebissen, dass Sie ein Datenmodell, die nur zwei Ebenen tief ist; ein großer Tisch, und mehrere kleine Tabellen, dass die großen Tabellenpunkte zurück. Dies ist ein Star-Schema. So ein echter Star-Datenmodell hat zwei Attribute, es immer zwei Ebenen tief ist, und ein echter Star Modell enthält immer nur einen großen Tisch, die im Mittelpunkt des Modells ist.