Data Warehousing und die Infrastructure Challenge - Dummies

Die Natur eines Data Warehouse (das hauptsächlich oder ausschließlich aus Daten besteht, die von anderswo kommen, andere Anwendungen) Datenbanken, und wird in ein Daten-Asset konvertiert) bedeutet, dass es nicht als eigenständige Einheit innerhalb Ihrer Organisation stehen kann.

Das phänomenale Wachstum der verteilten Datenverarbeitung (Internet und Intranet, sowie Data Warehousing interne und externe Daten) Dies hat zu einem fundamentalen Wandel in der Art und Weise geführt, wie Anwendungen aufgebaut werden: In den alten Zeiten von Großrechnern und Minicomputern enthielt ein einzelnes physisches System weitgehend die Infrastruktur (Betriebssysteme, Datenbanken und Dateisysteme sowie Kommunikations- und Transaktionsmanager).

< ! --1 ->

Da verteiltes Rechnen heute das dominante Modell ist (selbst Großrechner und Minicomputer sind normalerweise Teil einer größeren verteilten Umgebung), ist die Infrastruktur auf viele in Ihrem Unternehmen und möglicherweise außerhalb Ihres Unternehmens.

Wenn Sie eine Anwendung oder ein System entwickeln, entweder Data Warehousing oder eine traditionellere Transaktionsverarbeitungsanwendung, haben Sie erhebliche Abhängigkeiten von Teilen der Gesamtumgebung, über die Sie keine direkte Kontrolle haben. Hier einige Beispiele für Data Warehousing:

• Sie entwerfen ein Data-Warehouse, das auf Basis der Geschäftsanforderungen und der Datenverfügbarkeitsrichtlinien der Anwendungen etwa 25 Gigabyte an neuen und aktualisierten Daten benötigt, die jeden Abend aus verschiedenen Quellen extrahiert und über das Netzwerk an das Netzwerk gesendet werden. Hardwareplattform, auf der das Data Warehouse läuft.

  Ihre Unternehmensnetzwerkinfrastruktur ist immer noch zu klein. Nach einer zusätzlichen Analyse kann das Netzwerk den Durchsatz, der erforderlich ist, um die Daten im verfügbaren Zeitfenster in Ihr Lager zu verschieben, nicht annähernd unterstützen.

• Während der Gültigkeitsphase des Data Warehousing-Projekts stellen Sie fest, dass eine Push-Strategie zur Aktualisierung des Data Warehouse das am besten geeignete Modell ist, dem Sie folgen sollten. Um eine Push-Strategie zu implementieren, müssen Sie jedoch jede Quellanwendung dahingehend ändern, dass Code eingeschlossen wird, der erkennt, wann diese Anwendung Daten an das Data Warehouse senden ( senden) muss.

  Die Legacy-Anwendungen, die Daten an das Warehouse liefern, sind leider so schwer zu verstehen, dass für jede Anwendung nur dann die Politik gilt, keine Änderungen vorzunehmen, wenn dies absolut notwendig ist.

• Sie entscheiden sich für eine relationale OLAP (oder ROLAP) -Lösung und führen eine Reihe von Benchmarks für drei relationale DBMS-Produkte (RDBMS) durch, um zu sehen, welche die Informations- und Entscheidungsunterstützungsverarbeitung (und nicht die Transaktionsverarbeitung) am besten unterstützt.

  Das Produkt, das in Ihren Benchmarks am schlechtesten abschneidet, ist leider auch Ihr Unternehmensstandard, und jede relationale Datenbank, die irgendwo in Ihrem Unternehmen installiert ist, muss von dieser Vielfalt sein, egal wie Sie es verwenden möchten.

Denken Sie konzeptionell (ohne sich Gedanken über Implementierungsdetails zu machen) in den frühen Phasen eines Data-Warehousing-Projekts oder bei anderen Anwendungsentwicklungsbemühungen - es ist nicht nur akzeptabel, sondern auch eine gute Systementwicklungspraxis.

An einem gewissen Punkt müssen Sie jedoch Hardware, Software, Kosten, Budget und andere Arten von realen Einschränkungen berücksichtigen. Bevor Sie mit der Konstruktion beginnen, sollten Sie alles berücksichtigen, was sich auf Ihre Entwürfe und Pläne für Ihr Data Warehouse auswirken kann.

Dieses Projekt ist dem Bau eines Hauses sehr ähnlich. Sie folgen einem Prozess, bei dem Sie Ihre Bedürfnisse bestimmen, und dann erstellt der Architekt Blaupausen. Die Entwürfe heben die Materialien hervor, die Sie benötigen, um Ihre Anforderungen zu erfüllen - und stellen sicher, dass das fertige Produkt die zu Beginn etablierte Vision erfüllt.