Essbase-Anwendung analysieren und planen

Um sicherzustellen, dass Ihre Essbase-Anwendung Ihre Geschäftsinformationen effizient analysiert, erstellen Sie einen detaillierten Plan, in dem Datenquellen, Benutzeranforderungen und potenzielle Datenbankelemente beschrieben werden. Die Aufmerksamkeit auf diese Designphase kann Ihnen Entwicklungs- und Implementierungszeit sparen.

Die Planungs- und Analysephase umfasst folgende Aufgaben:

• Quelldaten analysieren

• Benutzeranforderungen identifizieren

• Sicherheitsplan in einer Umgebung mit mehreren Benutzern

• Datenbankmodelle erstellen

Berücksichtigen Sie beim Entwerfen einer mehrdimensionalen Anwendung die folgenden Faktoren:

• Wie Informationen innerhalb des Unternehmens fließen – wer verwendet welche Daten für welche Zwecke?

• Die Berichtsarten des Unternehmens – welche Datentypen müssen in der Gliederung enthalten sein, um die Anforderungen der Benutzerberichte zu erfüllen

  Hinweis:

  Die Definition von nur einer Datenbank pro Anwendung verbessert die Speichernutzung und die einfache Datenbankverwaltung.

Quelldaten analysieren

Bewerten Sie die Daten, die in die Essbase-Datenbank aufgenommen werden sollen. Überlegen Sie, woher es kommt, und die erforderliche Häufigkeit und Größe von Updates. Sie sollten nur das in Essbase laden, was für Pivot-Berichte und Drillthroughs erforderlich ist. Der Rest kann in einer relationalen Quelle verbleiben, auf die durch Partition oder Drillthrough zugegriffen werden kann.

Ermitteln Sie den Geltungsbereich der Datenbank. Wenn eine Organisation über zahlreiche Produktfamilien verfügt, die eine große Anzahl von Produkten enthalten, können Sie Datenwerte nur für Produktfamilien speichern. Interviewmitglieder aus jeder Benutzerabteilung, um herauszufinden, welche Daten sie verarbeiten, wie sie heute Daten berechnen und melden und wie sie dies in Zukunft tun möchten.

Definieren Sie die Berichts- und Analyseanforderungen sorgfältig.

• Wie möchten Benutzer Daten anzeigen und analysieren?

• Wie viele Details sollte die Datenbank enthalten?

• Unterstützt die Daten die gewünschten Analyse- und Reportingziele?

• Wenn nicht, welche zusätzlichen Daten benötigen Sie und wo finden Sie sie?

Bestimmen Sie den Speicherort der aktuellen Daten.

• Wo speichert jede Abteilung derzeit Daten?

• Sind Daten in einem Formular enthalten, das Essbase verwenden kann?

• Speichern Abteilungen Daten in relationalen Datenbanken auf Windows- oder UNIX-Servern oder in Excel-Tabellen?

• Wer aktualisiert die Datenbank und wie häufig?

• Haben diejenigen, die Daten aktualisieren müssen, Zugriff darauf?

Stellen Sie sicher, dass die Daten zum Laden in Essbase bereit sind.

• Kommen Daten aus einer einzigen Quelle oder aus mehreren Quellen?

• Sind Daten in einem Format, das Essbase verwenden kann? Eine Liste der gültigen Datenquellen, die Sie in Essbase laden können, finden Sie unter Datenquellen.

• Sind alle Daten, die Sie verwenden möchten, sofort verfügbar?

Benutzeranforderungen identifizieren

Wenn Sie die Essbase-Datenbank planen, besprechen Sie die Informationsanforderungen mit den aktuellen Benutzern der Daten, und fordern Sie Beispielberichte von ihnen an. Prüfen Sie die von ihnen verwendeten Informationen und die Berichte, die sie zur Prüfung durch andere generieren müssen.

Ermitteln Sie die folgenden Anforderungen:

• Welche Analysetypen benötigen Benutzer?

• Benötigen Benutzer Ad-hoc-Berichte (Pivot-Stil) und strukturierte Berichte?

• Welche Zusammenfassungs- und Detailebenen von Informationen benötigen Benutzer?

• Benötigen einige Benutzer Zugriff auf Informationen, die anderen Benutzern nicht angezeigt werden sollen?

Sicherheitsplan in einer Umgebung mit mehreren Benutzern

Ermitteln Sie im Rahmen der Planung, wie Sie Essbase-Sicherheitsberechtigungen einrichten, unterschiedliche Ebenen von Benutzerinformationen. Am Ende Ihrer Analyse sollten Sie eine Liste der Benutzer und die erforderlichen Berechtigungen haben.

Verwenden Sie diese Checkliste, um die Sicherheit zu planen:

• Wer sind die Benutzer und welche Berechtigungen sollten sie zum Lesen oder Schreiben von Daten in der Datenbank haben?

• Wer sollte über Ladeberechtigungen verfügen?

• Wer sollte die Berechtigung zur Ausführung von Berechnungen haben?

• Welche Benutzer können gruppiert und ähnlichen Berechtigungen zugewiesen werden?

Hierzu wird auch auf Benutzer und Rollen verwalten verwiesen.

Datenbankmodelle erstellen

Modell der Essbase-Datenbank erstellen Um das Modell zu erstellen, müssen Sie die Perspektiven und Ansichten identifizieren, die für Ihr Unternehmen wichtig sind. Diese Views werden in die Dimensionen des Datenbankmodells übersetzt.

Viele Unternehmen analysieren die folgenden Ansichten:

• Zeitperioden

• Kennzahlen

• Szenarios

• Produkte

• Customers

• Geografische Regionen

• Geschäftseinheiten

Um Informationen zu sammeln und Entscheidungen zu treffen, müssen Sie Datenanalyseziele identifizieren, die Datenbankdimensionen und -elemente bestimmen und das Datenbankdesign analysieren.

Analyseziele identifizieren

Nachdem Sie die Hauptansichten der Informationen in einem Unternehmen identifiziert haben, entscheidet der nächste Schritt beim Entwerfen einer Essbase-Datenbank, wie die Datenbank die Datenanalyse aktiviert. Beispiel: Sie müssen Daten nach Zeitraum, nach Geografie oder nach Produkttyp anzeigen.

• Wenn Sie nach Zeit analysieren, welche Zeiträume sind erforderlich? Sollte die Analyse nur das aktuelle Jahr oder mehrere Jahre umfassen? Sollte die Analyse vierteljährliche und monatliche Daten enthalten? Sollte es Daten nach Saison enthalten?

• Wie definieren Sie bei der Analyse nach geografischer Region die Regionen? Definieren Sie Regionen nach Vertriebsgebieten? Definieren Sie Regionen nach geografischen Grenzen, wie Bundesstaaten und Städte?

• Wenn Sie nach Produktlinie analysieren, sollten Sie die Daten für jedes Produkt überprüfen? Können Sie Daten in Produktklassen zusammenfassen?

Unabhängig von den Geschäftsansichten müssen Sie die Perspektive und die Details bestimmen, die in der Analyse erforderlich sind. Jeder von Ihnen analysierte Geschäftsbereich bietet eine andere Ansicht der Daten.

Dimensionen und Elemente bestimmen

Die ausgewählten Essbase-Dimensionen bestimmen, welche Analysetypen Sie ausführen können. Innerhalb jeder Dimension stellen Hierarchien von Elementen Aspekte des Unternehmens dar. Beispiel: Eine Zeithierarchie kann Quartale und Monate umfassen. Eine Produkthierarchie klassifiziert Produkte. Eine regionale Hierarchie basiert auf geografischen Märkten.

Sie können jede Geschäftsansicht als separate Standarddimension in der Datenbank darstellen. Sie können hören, dass sich Business Analysts auf die "Bys" ihres Unternehmens beziehen, z. B. nach Produkt, nach Region und nach Zeitraum. Wenn Sie eine Geschäftsansicht nach Klassifizierung oder Attribut analysieren müssen, z.B. nach Größe oder Farbe von Produkten, können Sie Attributdimensionen oder -eigenschaften zur Darstellung der Klassifizierungsansichten verwenden.

Sie können beliebig viele Dimensionen für die Analyse verwenden. Wenn Sie ungefähr wissen, welche Dimensionen und Elemente Sie benötigen, entwickeln Sie ein vorläufiges Datenbankdesign.

Nachdem Sie die Dimensionen des Datenbankmodells bestimmt haben, wählen Sie die Elemente oder Elemente in jeder Dimension. Diese Elemente werden zu Hierarchien und Elementen ihrer jeweiligen Dimensionen. Beispiel: Eine Zeithierarchie kann die Zeitperioden enthalten, die Sie analysieren möchten, z.B. Quartale und Monate innerhalb von Quartalen. Jedes Quartal und jeder Monat wird ein Element der Dimension, die Sie für die Zeit erstellen. Quartale und Monate stellen eine Hierarchie von Elementen und deren untergeordneten Elementen auf zwei Ebenen dar. Monate innerhalb eines Quartals können für jedes Quartal auf eine Summe konsolidiert werden.

Beziehungen zwischen Dimensionen

Betrachten Sie die Beziehungen zwischen den Dimensionen. Die Struktur einer Essbase-Datenbank erleichtert es Benutzern, Informationen aus vielen Perspektiven zu analysieren. Ein Finanzanalyst kann beispielsweise folgende Fragen stellen:

• Was sind Verkäufe für einen bestimmten Monat? Wie sieht diese Zahl im Vergleich zum Umsatz im selben Monat der letzten fünf Jahre aus?

• Um welchen Prozentsatz steigt die Gewinnspanne?

• Wie nah sind die Istwerte an den budgetierten Werten?

Mit anderen Worten, der Analyst möchte möglicherweise Informationen aus drei Dimensionen untersuchen – Zeit, Konto und Szenario. Die folgende Beispieldatenbank stellt diese drei Dimensionen dar, wobei eine Dimension entlang jeder der drei Achsen dargestellt ist:

• Eine Zeitdimension, die Jan, Feb, Mar und die Summe für Qtr1 umfasst, wird entlang der X-Achse angezeigt.

• Eine Kontendimension, die aus Buchhaltungszahlen wie Umsatz, COGS, Gewinnspanne und Gewinnspanne% besteht, wird entlang der Y-Achse angezeigt.

• Eine weitere Dimension, die einen anderen Point of View bietet, wie Budget für Budgetwerte und Ist für Istwerte, wird entlang der Z-Achse angezeigt.

Abbildung 1-1 Cube mit drei Datenbankdimensionen

Die Zellen im Cube, in denen sich die Elemente überschneiden, enthalten die Daten, die für alle drei sich überschneidenden Elemente relevant sind, z.B. den tatsächlichen Umsatz im Januar.

Beispiel-Dimensionselementstruktur

Die folgende Tabelle zeigt eine Zusammenfassung der TBC-Dimensionen. Der Anwendungsdesigner hat drei Spalten erstellt, wobei die Dimensionen in der linken Spalte und die Elemente in den beiden rechten Spalten angezeigt werden. Die Elemente in Spalte 3 sind Unterkategorien der Elemente in Spalte 2. In einigen Fällen werden Elemente in Spalte 3 in eine andere Ebene von Unterkategorien unterteilt. Beispiel: Die Dimension "Marge of the Measures" wird in "Sales" und "COGS" unterteilt.

Tabelle 1-1: TBC - Beispieldimensionen

Dimensionen	Members	Untergeordnete Mitglieder
Jahr	Qrt 1	Jan, Feb, Mär
Jahr	Quartal 2	Apr, Mai, Jun
Jahr	Quartal 3	Jul, Aug, Sep
Jahr	Quartal 4	Okt, Nov, Dez
Kennzahlen	Gewinn	Gewinnspanne: Umsatz, COGS Gesamtaufwand: Marketing, Entgeltabrechnung, Sonstige
Kennzahlen	Bestand	Bestand öffnen, Zugänge, Endbestand
Kennzahlen	Verhältnis	Gewinnspanne %, Gewinn %, Gewinn pro Unze
Product	Colas (100)	Cola (100-10), Cola-Diät (100-20), Cola ohne Koffein (100-30)
Product	Wurzelbier (200)	Old Fashioned (200-10), Diätwurzelbier (200-20), Sarsaparilla (200-30), Birkenbier (200-40)
Product	Sahne Soda (300)	Dark Cream (300‑10), Vanillecreme (300‑20), Diätcreme Soda (300‑30)
Product	Obstsoda (400)	Traube (400‑10), Orange (400‑20), Erdbeere (400‑30)
Market	Ost	Connecticut, Florida, Massachusetts, New Hampshire, New York
Market	West	Kalifornien, Nevada, Oregon, Utah, Washington
Market	Süd	Louisiana, New Mexico, Oklahoma, Texas
Market	Zentral	Colorado, Illinois, Iowa, Missouri, Ohio, Wisconsin
Scenario	Tatsächlich	N/V
Scenario	Budget	N/V
Scenario	Abweichung	N/V
Scenario	Varianz %	N/V

Darüber hinaus hat der Anwendungsdesigner die folgenden Attributdimensionen hinzugefügt, um eine Produktanalyse basierend auf Größe und Verpackung zu ermöglichen:

Tabelle 1-2: TBC - Beispielattributdimensionen

Dimensionen	Members	Untergeordnete Mitglieder
Unzen	Groß Klein	64, 32, 20 16, 12
Packungstyp	Flasche Kann	N/V

Checkliste zur Bestimmung von Dimensionen und Elementen

Verwenden Sie die folgende Checkliste, um die Dimensionen und Elemente der Modelldatenbank zu bestimmen:

• Was sind die Kandidaten für Dimensionen?

• Klassifizieren oder beschreiben eine der Dimensionen andere Dimensionen? Diese Dimensionen sind Kandidaten für Attribute-Dimensionen.

• Möchten Benutzer ihre Ansicht einer Dimension qualifizieren? Die Kategorien, nach denen sie eine Dimension qualifizieren, sind Kandidaten für Attribute-Dimensionen.

• Was sind die Kandidaten für Mitglieder?

• Wie viele Ebenen benötigen die Daten?

• Wie werden die Daten konsolidiert?

Datenbankdesign analysieren

Prüfen Sie das anfängliche Essbase-Dimensionsdesign gemäß diesen Richtlinien hinsichtlich der Anzahl der Dimensionen, ihres kombinierten Analysewerts und der Vermeidung von Wiederholungen. Durch die Durchführung dieser Vorabanalyse können Sie ein effizientes Datenbankdesign erreichen, das Ihre Datenkonsolidierungs- und Berechnungsziele erfüllt.

Die Anzahl der Elemente, die zur Beschreibung eines potenziellen Datenpunkts erforderlich sind, muss die Anzahl der Dimensionen bestimmen. Wenn Sie nicht sicher sind, ob Sie eine Dimension löschen sollen, behalten Sie sie bei und wenden Sie weitere Analyseregeln an, bis Sie sicher sind, dass Sie sie löschen oder beibehalten.

Dicht und dünn besetzte Abmessungen

Welche Dimensionen dünn und welche dicht sind, wirkt sich auf die Performance aus. Siehe:

• Dünn besetzt und dicht besetzte Dimensionen

• Entwurf einer Gliederung zur Optimierung der Leistung

Standard- und Attributdimensionen

Der Einfachheit halber zeigen die Beispiele in diesem Thema alternative Anordnungen für das, was ursprünglich als zwei Dimensionen konzipiert wurde. Sie können dieselbe Logik auf alle Kombinationen von Dimensionen anwenden.

Betrachten Sie das Design für ein Unternehmen, das Produkte an mehrere Kunden über mehrere Märkte verkauft. Die Märkte sind für jeden Kunden einzigartig:

             Cust A  Cust B  Cust C
New York     100     N/A     N/A
Illinois     N/A     150     N/A
California   N/A     N/A     30

Cust A ist nur in New York, Cust B nur in Illinois und Cust C nur in Kalifornien. Das Unternehmen kann die Daten in einer Standarddimension definieren:

Market
  New York
    Cust A
  Illinois
    Cust B
  California
    Cust C

Wenn Sie sich jedoch eine größere Auswahl an Daten ansehen, können Sie feststellen, dass sich viele Kunden in jedem Markt befinden können. Cust A und Cust E sind in New York, Cust B, Cust M und Cust P in Illinois, Cust C und Cust F in Kalifornien. In dieser Situation definiert das Unternehmen in der Regel die große Dimension "Kunde" als Standarddimension und die kleinere Dimension "Markt" als Attributdimension. Die Firma ordnet die Elemente der Market-Dimension als Attribute der Elemente der Customer-Dimension zu. Die Elemente der Market-Dimension beschreiben die Standorte der Kunden – jeder Kunde hat genau einen Markt.

Customer (Standard dimension)
  Cust A (Attribute:New York)
  Cust B (Attribute:Illinois)
  Cust C (Attribute:California)
  Cust E (Attribute:New York)
  Cust F (Attribute:California)
  Cust M (Attribute:Illinois)
  Cust P (Attribute:Illinois)
Market (Attribute dimension)
  New York
  Illinois
  California

Betrachten Sie eine andere Situation. Auch hier verkauft das Unternehmen Produkte an mehrere Kunden über mehrere Märkte, aber das Unternehmen kann an einen Kunden verkaufen, der Standorte in verschiedenen Märkten hat:

             Cust A  Cust B  Cust C
New York     100      75     N/A
Illinois     N/A     150     N/A
California   150     N/A      30

Cust A ist in New York und Kalifornien. Cust B ist in New York und Illinois. Cust C ist nur in Kalifornien. Die Verwendung einer Attribute-Dimension funktioniert in dieser Situation nicht. Ein Kundenelement kann nicht mehrere Attributelemente haben. Daher entwirft das Unternehmen die Daten in zwei Standarddimensionen:

Customer
  Cust A
  Cust B
  Cust C
Market
  New York
  Illinois
  California

Dimensionskombinationen

Brechen Sie jede Kombination von zwei Dimensionen in eine zweidimensionale Matrix auf. Beispiel: Vorgeschlagene Dimensionen bei TBC enthalten die folgenden Kombinationen:

• Jahr über Kennzahlen

• Jahr über Produkt

• Marktübergreifend

• Jahr über Szenario

• Kennzahlen nach Produkt

• Marktweite Kennzahlen

• Kennzahlen über Szenario

• Markt nach Produkten

• Markt über Szenario

• Szenario nach Produkt

• Unzen nach Pakettyp

Unzen und Pakettyp als Attributdimensionen, die der Product-Dimension zugeordnet sind, können bei der Product-Dimension berücksichtigt werden.

Um die einzelnen Dimensionen zu visualisieren, zeichnen Sie eine Matrix, und nehmen Sie einige der Elemente der ersten Generation auf. Die folgende Abbildung zeigt einen vereinfachten Satz von Matrizen für drei Dimensionen.

Abbildung 1-2: Dimensionale Beziehungen analysieren

Stellen Sie für jede Kombination von Dimensionen drei Fragen:

• Gibt es einen analytischen Wert?

• Wird ein Dienstprogramm für das Reporting hinzugefügt?

• Vermeidet es einen Überschuss an nicht verwendeten Kombinationen?

Anhand der Antworten auf die Fragen kann für jede Kombination bestimmt werden, ob die Kombination für die Datenbank gültig ist. Idealerweise ist die Antwort auf jede Frage ja. Wenn nicht, können Sie die Daten in sinnvollere Dimensionen umordnen. Besprechen Sie während der Arbeit mit den Benutzern den Informationsbedarf.

Wiederholung in Gliederungen

Die Wiederholung von Elementen in einem Umriss weist oft darauf hin, dass Dimensionen aufgeteilt werden müssen. Die folgenden Beispiele zeigen Ihnen, wie Sie Wiederholungen vermeiden.

In diesem Beispiel zeigt die linke Spalte mit der Bezeichnung "Wiederholung" in der Account-Dimension "Gewinn", "Gewinnspanne", "Umsatz", "COGS" und "Aufwendungen", die unter "Budget" und "Ist" wiederholt werden. In der rechten Spalte mit der Bezeichnung "Keine Wiederholung" werden Budget und Ist in eine andere Dimension (Szenario) aufgeteilt. Dabei bleibt nur ein Satz der Elemente "Gewinn", "Gewinnspanne", "Umsatz", "COGS" und "Aufwand" in der Dimension "Konten" übrig. Dieser Ansatz vereinfacht das Outline und bietet einen einfacheren Überblick über das Budget und die tatsächlichen Zahlen der anderen Dimensionen in der Datenbank.

Abbildung 1-3: Beispiel für die Eliminierung von Wiederholungen durch Erstellen einer Szenariodimension

In diesem Beispiel verwendet die linke Spalte mit der Bezeichnung "Wiederholung" gemeinsame Elemente in der Dimension "Diät", um Diätgetränke zu analysieren. Die Mitglieder 100-20, 200-20 und 300-20 werden wiederholt: einmal unter der Diät und einmal unter ihren jeweiligen Eltern. Die rechte Spalte mit der Bezeichnung "Keine Wiederholung" vereinfacht die Modellstruktur, indem eine Diätattributdimension des Typs "Boolesch" (Wahr oder Falsch) erstellt wird. Alle Mitglieder werden nur einmal unter ihren jeweiligen Eltern angezeigt und mit dem entsprechenden Attribut ("Diät: Wahr" oder "Diät: Falsch") gekennzeichnet.

Abbildung 1-4: Beispiel zum Eliminieren von Wiederholungen durch Erstellen einer Attribute-Dimension

Attribute-Dimensionen bieten auch zusätzliche Analysefunktionen. Siehe Vorteile von Essbase-Attributen.

Interdimensionale Irrelevante

Interdimensionale Irrelevanz tritt auf, wenn viele Elemente einer Dimension über andere Dimensionen hinweg irrelevant sind. Essbase definiert irrelevante Daten als Daten, die Essbase nur auf Summenebene (Dimensionsebene) speichert. In einer solchen Situation können Sie möglicherweise eine Dimension aus der Datenbank entfernen und ihre Elemente einer anderen Dimension hinzufügen oder das Modell in separate Datenbanken aufteilen.

Beispiel: TBC analysierte Gehälter als Element der Measures-Dimension. Gehaltsinformationen erweisen sich jedoch im Kontext einer Unternehmensdatenbank oft als irrelevant. Die meisten Gehälter sind vertraulich und gelten für Einzelpersonen. Die Person und das Gehalt stellen in der Regel eine Zelle dar, ohne dass sich eine andere Dimension überschneidet.

TBC überlegte, Mitarbeiter in eine separate Dimension zu trennen. Die folgende Tabelle zeigt ein Beispiel dafür, wie TBC die vorgeschlagene Employee-Dimension auf interdimensionale Irrelevanz analysiert hat. Die Elemente der vorgeschlagenen Employee-Dimension (in der Tabellenheaderzeile dargestellt) werden mit Elementen der Measures-Dimension (in der Spalte ganz links dargestellt) verglichen. Die Dimensionswerte "Kennzahlen" (z.B. "Umsatz") gelten für alle Mitarbeiter. Nur die Kennzahl "Gehalt" ist für einzelne Mitarbeiter relevant.

Tabelle 1-3 Beispiel für interdimensionale Irrelevanz

	Joe Smith	Mary Jones	Mike Garcia	Alle Mitarbeiter
Revenue	Irrelevanz	Irrelevanz	Irrelevanz	Relevanz
Variable Kosten	Irrelevanz	Irrelevanz	Irrelevanz	Relevanz
COGS	Irrelevanz	Irrelevanz	Irrelevanz	Relevanz
Advertisement wird ausgeführt	Irrelevanz	Irrelevanz	Irrelevanz	Relevanz
Gehälter	Relevanz	Relevanz	Relevanz	Relevanz
Feste Kosten	Irrelevanz	Irrelevanz	Irrelevanz	Relevanz
Aufwendungen	Irrelevanz	Irrelevanz	Irrelevanz	Relevanz
Gewinn	Irrelevanz	Irrelevanz	Irrelevanz	Relevanz

Gründe für die Aufteilung von Datenbanken

Da einzelne Mitarbeiterinformationen für die anderen Informationen in der Datenbank irrelevant sind und das Hinzufügen einer Employee-Dimension den Datenbankspeicherbedarf erheblich erhöhen würde, hat TBC eine separate HR-Datenbank erstellt. Die neue HR-Datenbank enthält eine Gruppe zugehöriger Dimensionen und umfasst Gehälter, Leistungen, Versicherungen und 401(k)-Pläne.

Es gibt viele Gründe für die Aufteilung einer Datenbank. Beispiel: Ein Unternehmen verwaltet eine Organisationsdatenbank, die mehrere internationale Tochtergesellschaften in mehreren Zeitzonen enthält. Jede Tochtergesellschaft stützt sich auf zeitkritische Finanzberechnungen. Sie können die Datenbank für Gruppen von Tochtergesellschaften in derselben Zeitzone aufteilen, um sicherzustellen, dass Finanzberechnungen zeitnah sind. Sie können auch eine partitionierte Anwendung verwenden, um Informationen nach Tochtergesellschaft zu trennen.

Checkliste zur Analyse des Datenbankdesigns

Mit der folgenden Checkliste können Sie das Datenbankdesign analysieren:

• Haben Sie die Anzahl der Dimensionen minimiert?

• Haben Sie für jede Dimensionskombination gefragt:

  • Gibt es einen analytischen Wert?

  • Wird ein Dienstprogramm für das Reporting hinzugefügt?

  • Vermeidet es einen Überschuss an nicht verwendeten Kombinationen?

• Haben Sie die Wiederholung im Outline vermieden?

• Haben Sie interdimensionale Irrelevanz vermieden?

• Haben Sie die Datenbanken nach Bedarf aufgeteilt?