Das Senden Ihrer guten Arbeit an die Wissensdatenbank ist ganz einfach. Nutzen Sie das untenstehende Formular

Studierende, Doktoranden und junge Wissenschaftler, die die Wissensbasis in ihrem Studium und ihrer Arbeit nutzen, werden Ihnen sehr dankbar sein.

Veröffentlicht am http://www.allbest.ru/

1. Relationales Datenmodell

1.1 Relationales Datenmodell. Grundlegende Definitionen
1.2 Operationen auf Beziehungen

2. Unternehmensinformationssysteme
Literaturverzeichnis

1. Relationales Datenmodell

1.1 Relationales Datenmodell. Grundlegende Definitionen

In mathematischen Disziplinen entspricht der Begriff „Tabelle“ dem Begriff „Relation“. Die Tabelle spiegelt ein reales Objekt wider – eine Entität, und jede ihrer Zeilen spiegelt eine bestimmte Instanz der Entität wider. Jede Spalte hat einen für die Tabelle eindeutigen Namen. Die Zeilen haben keine Namen, ihre Reihenfolge ist nicht definiert und ihre Anzahl ist logisch unbegrenzt. Einer der Hauptvorteile des relationalen Datenmodells ist die Einheitlichkeit (jede Zeile der Tabelle hat das gleiche Format). Der Benutzer entscheidet selbst, ob die entsprechenden Entitäten Homogenität aufweisen. Damit ist das Problem der Modelleignung gelöst.

Grundlegendes Konzept:

* Eine Relation ist eine zweidimensionale Tabelle, die einige Daten enthält.

* Entität ist ein Objekt jeglicher Art, über das Daten in der Datenbank gespeichert werden. Attribute sind Eigenschaften, die eine Entität (Spalten) charakterisieren.

* Verwandtschaftsgrad – Anzahl der Spalten.

* Beziehungsschema – eine Liste von Attributnamen, zum Beispiel MITARBEITER (Nr., vollständiger Name, Geburtsjahr, Position, Abteilung).

* Domäne ist eine Sammlung von Beziehungsattributwerten (Datentyp).

* Tupel ist eine Tabellenzeile.

* Kardinalität (Kardinalität) – die Anzahl der Zeilen in der Tabelle.

* Ein Primärschlüssel ist ein Attribut, das die Zeilen einer Beziehung eindeutig identifiziert. Ein aus mehreren Attributen bestehender Primärschlüssel wird als zusammengesetzter Schlüssel bezeichnet. Der Primärschlüssel darf weder ganz noch teilweise leer sein (den Wert Null haben). Schlüssel, die als Primärschlüssel verwendet werden können, werden Kandidaten- oder Alternativschlüssel genannt.

* Ein Fremdschlüssel ist ein Attribut einer Tabelle, das als Primärschlüssel einer anderen Tabelle dienen kann. Ist ein Verweis auf den Primärschlüssel einer anderen Tabelle.

Normalisierung ist ein Prozess, der darauf abzielt, die Redundanz von Informationen in einer Datenbank zu reduzieren. Neben den Daten selbst können auch verschiedene Titel, Objektnamen und Ausdrücke in der Datenbank normalisiert werden.

Eine nicht normalisierte Datenbank enthält Informationen in einer oder mehreren verschiedenen Tabellen; Gleichzeitig scheint es, dass die Aufnahme von Daten in eine bestimmte Tabelle keine sichtbaren Gründe hat. Dieser Zustand kann sich negativ auf die Datensicherheit, die effiziente Nutzung des Speicherplatzes, die Geschwindigkeit der Abfrageausführung, die Effizienz der Datenbankaktualisierung und, was vielleicht am wichtigsten ist, auf die Integrität der gespeicherten Informationen auswirken. Die Datenbank vor der Normalisierung ist eine Struktur, die noch nicht logisch in kleinere, besser verwaltbare Tabellen unterteilt ist.

Die Normalform ist eine Art Indikator für den Grad oder die Tiefe der Datenbanknormalisierung. Der Normalisierungsgrad einer Datenbank entspricht der Normalform, in der sie vorliegt.

1.2 Operationen auf Beziehungen

Um eine Tabelle in die erste Normalform (1NF) umzuwandeln, müssen Sie zwei Regeln befolgen:

1. Atomarität oder Unteilbarkeit. Jede Spalte muss einen unteilbaren Wert enthalten.

2. Die Tabelle sollte keine doppelten Spalten oder Datengruppen enthalten.

Wenn eine Tabelle beispielsweise die vollständige Adresse einer Person (Straße, Ort, Postleitzahl) in einem Feld enthält, entspricht sie nicht den 1NF-Regeln, da sie unterschiedliche Werte in derselben Spalte enthält, was einen Verstoß darstellt die Atomaritätsregel. Oder wenn die Datenbank Daten zu Filmen enthält und die Spalten „Schauspieler1“, „Schauspieler2“ und „Schauspieler3“ enthält, erfüllt sie ebenfalls nicht die Regeln, da es zu Wiederholungen von Daten kommt.

Die Normalisierung sollte mit der Überprüfung der Datenbankstruktur auf Kompatibilität mit 1NF beginnen. Alle Spalten, die nicht atomar sind, müssen in ihre einzelnen Spalten zerlegt werden. Wenn die Tabelle doppelte Spalten enthält, müssen diese einer separaten Tabelle zugewiesen werden.

So konvertieren Sie eine Tabelle in die erste Normalform:

* Finden Sie alle Felder, die mehrere Informationen enthalten.

* Daten, die in Einzelteile zerlegt werden können, müssen in separate Felder eingegeben werden.

* Platzieren Sie doppelte Daten in einer separaten Tabelle.

* Überprüfen Sie, ob alle Tabellen die Bedingungen der ersten Normalform erfüllen.

Um Tabellen in die zweite Normalform (2NF) zu konvertieren, müssen die zu reduzierenden Tabellen bereits in 1NF vorliegen. Die Normalisierung muss der Reihe nach erfolgen.

Nun muss in der zweiten Normalform die Bedingung erfüllt sein – jede Spalte, die kein Schlüssel ist (einschließlich eines Fremdschlüssels), muss vom Primärschlüssel abhängen. Spalten mit vom Schlüssel unabhängigen Werten sind in der Regel einfach zu definieren. Wenn die in einer Spalte enthaltenen Daten für den Schlüssel, der die Zeile beschreibt, nicht relevant sind, sollte sie in eine eigene separate Tabelle aufgeteilt werden. Der Primärschlüssel muss an die alte Tabelle zurückgegeben werden.

Um die Basis in die zweite Normalform zu bringen, müssen Sie:

* Identifizieren Sie alle Spalten, die nicht direkt vom Primärschlüssel dieser Tabelle abhängig sind.

* Erstellen Sie die erforderlichen Felder in den Benutzer- und Forentabellen, wählen Sie aus vorhandenen Feldern aus oder erstellen Sie Primärschlüssel aus neuen.

* Jede Tabelle benötigt einen eigenen Primärschlüssel

* Erstellen Sie Fremdschlüssel und bezeichnen Sie deren Beziehungen zwischen Tabellen. Der letzte Schritt der Normalisierung auf 2NF wird die Zuweisung von Fremdschlüsseln für die Kommunikation mit zugehörigen Tabellen sein. Der Primärschlüssel einer Tabelle muss ein Fremdschlüssel in einer anderen sein.

Tipps:

Eine andere Möglichkeit, ein Schema in 2NF zu konvertieren, besteht darin, sich die Beziehungen zwischen Tabellen anzusehen. Die ideale Option besteht darin, alle Eins-zu-Viele-Beziehungen zu erstellen. Viele-zu-viele-Beziehungen müssen umstrukturiert werden.

Eine richtig normalisierte Tabelle wird niemals doppelte Zeilen haben (zwei oder mehr Zeilen, deren Werte keine Schlüssel sind und übereinstimmende Daten enthalten).

Eine Datenbank befindet sich in der dritten Normalform, wenn sie auf die zweite Normalform reduziert wird und jede Nichtschlüsselspalte unabhängig voneinander ist. Wenn Sie den Normalisierungsprozess bis zu diesem Punkt korrekt befolgen, treten möglicherweise keine Probleme bei der Konvertierung in 3NF auf. Sie sollten sich darüber im Klaren sein, dass 3NF verletzt wird, wenn die Änderung des Werts in einer Spalte eine Änderung in einer anderen Spalte erfordert.

Um die Basis in die dritte Normalform zu bringen, müssen Sie:

* Bestimmen Sie, welche Felder welcher Tabellen gegenseitige Abhängigkeiten haben, d. h. Felder, die stärker voneinander abhängen als von der Serie als Ganzes.

* Erstellen Sie entsprechende Tabellen. Wenn es in Schritt 1 eine problematische Spalte gibt, erstellen Sie geteilte Tabellen dafür.

* Primärschlüssel erstellen oder zuweisen. Jede Tabelle muss einen Primärschlüssel haben.

* Erstellen Sie die erforderlichen Fremdschlüssel, die eine der Beziehungen bilden.

In der vierten Normalform gilt als zusätzliche Regel, dass mehrwertige Abhängigkeiten ausgeschlossen werden müssen. Mit anderen Worten: Alle Tabellenzeilen müssen unabhängig voneinander sein. Das Vorhandensein einer Zeile X sollte nicht bedeuten, dass sich Zeile Y auch irgendwo in dieser Tabelle befindet.

2. Unternehmensinformationssysteme

relationales Modelldatensystem

Ein System (von griechisch systema – ein Ganzes, eine aus Teilen bestehende Verbindung) ist eine Reihe von Elementen, die miteinander interagieren und eine gewisse Integrität und Einheit bilden. Lassen Sie uns einige Konzepte vorstellen, die häufig zur Charakterisierung eines Systems verwendet werden.

1. Systemelement – Teil des Systems, der einen bestimmten funktionalen Zweck hat. Komplexe Elemente von Systemen, die wiederum aus einfacheren miteinander verbundenen Elementen bestehen, werden oft als Subsysteme bezeichnet.

2. Organisation des Systems – innere Ordnung, Konsistenz im Zusammenspiel der Systemelemente, die sich insbesondere in der Begrenzung der Zustandsvielfalt der Elemente innerhalb des Systems äußert.

3. Systemstruktur – Zusammensetzung, Reihenfolge und Prinzipien der Interaktion von Systemelementen, die die grundlegenden Eigenschaften des Systems bestimmen. Wenn die einzelnen Elemente des Systems auf verschiedene Ebenen verteilt sind und die internen Verbindungen zwischen den Elementen nur von höheren zu niedrigeren Ebenen und umgekehrt organisiert sind, spricht man von einer hierarchischen Struktur des Systems. Rein hierarchische Strukturen sind praktisch selten, daher werden, um diesen Begriff etwas zu erweitern, unter einer hierarchischen Struktur üblicherweise solche Strukturen verstanden, bei denen neben anderen Verbindungen hierarchische Verbindungen von vorrangiger Bedeutung sind.

4. Die Systemarchitektur ist eine Reihe von Systemeigenschaften, die für den Benutzer wichtig sind.

5. Die Integrität des Systems ist die grundsätzliche Irreduzibilität der Eigenschaften des Systems auf die Summe der Eigenschaften seiner einzelnen Elemente (Emergenz von Eigenschaften) und gleichzeitig die Abhängigkeit der Eigenschaften jedes Elements von seinem Ort und Funktion innerhalb des Systems.

Ein Informationssystem ist eine miteinander verbundene Reihe von Mitteln, Methoden und Personal, die zur Speicherung, Verarbeitung und Ausgabe von Informationen im Interesse der Erreichung eines festgelegten Ziels eingesetzt werden.“

Das Bundesgesetz „Über Information, Informatisierung und Informationsschutz“ gibt folgende Definition:

„Ein Informationssystem ist ein organisatorisch geordneter Satz von Dokumenten (Arrays von Dokumenten) und Informationstechnologien, einschließlich der Verwendung von Computertechnologie und Kommunikation, die Informationsprozesse implementieren.“

Klassifizierung nach Maßstab

Informationssysteme werden je nach Maßstab in die folgenden Gruppen eingeteilt:

* einzel;

* Gruppe;

* Unternehmen.

Ein Unternehmensinformationssystem ist ein skalierbares System zur umfassenden Automatisierung aller Arten wirtschaftlicher Aktivitäten großer und mittlerer Unternehmen, einschließlich Konzernen, die aus einer Gruppe von Unternehmen bestehen, die eine einheitliche Verwaltung erfordern.

Unter einem Unternehmensinformationssystem versteht man ein System, das mehr als 80 % der Unternehmensbereiche automatisiert.

In vielen Veröffentlichungen, die sich dem Einsatz von Informationstechnologien bei der Verwaltung von Wirtschaftsobjekten widmen, wird in letzter Zeit häufig der Begriff „Unternehmensinformationssysteme“ verwendet, womit automatisierte Informationssysteme von Wirtschaftsobjekten gemeint sind.

Ein automatisiertes Informationssystem (AIS) ist eine Kombination aus verschiedenen Arten von Software sowie Spezialisten, die darauf ausgelegt sind, die Verarbeitung von Buchhaltungs- und Analyseinformationen zu automatisieren. Die Trägerarten sind in der Regel für unterschiedliche Systeme in ihrer Zusammensetzung homogen, was es ermöglicht, den Grundsatz der Systemkompatibilität im Betrieb umzusetzen. Bei der Untersuchung von AIS als komplexes System ist es notwendig, einzelne Teile und Elemente zu identifizieren und die Merkmale ihrer Verwendung in den Phasen der Erstellung und des Betriebs zu berücksichtigen.

Unternehmensinformationssysteme sind eine Weiterentwicklung von Systemen für Arbeitsgruppen; sie richten sich an große Unternehmen und können geografisch verteilte Knoten oder Netzwerke unterstützen. Grundsätzlich haben sie eine hierarchische Struktur aus mehreren Ebenen. Solche Systeme zeichnen sich durch eine Client-Server-Architektur mit Spezialisierung der Server oder eine mehrstufige Architektur aus. Bei der Entwicklung solcher Systeme können dieselben Datenbankserver verwendet werden wie bei der Entwicklung von Konzerninformationssystemen. In großen Informationssystemen sind die am häufigsten verwendeten Server jedoch Oracle, DB2 und Microsoft SQL Server.

Bei Konzern- und Unternehmenssystemen steigen die Anforderungen an zuverlässigen Betrieb und Datensicherheit deutlich. Diese Eigenschaften werden durch die Aufrechterhaltung der Integrität von Daten, Links und Transaktionen in Datenbankservern bereitgestellt.

Einteilung nach Anwendungsgebiet

Je nach Anwendungsbereich werden Informationssysteme üblicherweise in vier Gruppen eingeteilt:

* Transaktionsverarbeitungssysteme;

* Entscheidungssysteme;

* Informations- und Referenzsysteme;

* Büroinformationssysteme.

Literaturverzeichnis

1. Agaltsov, V.P. Datenbank. In 2 Bänden. T. 2. Verteilte und entfernte Datenbanken: Lehrbuch / V.P. Agaltsow. - M.: ID FORUM, SIC INFRA-M, 2013.

2. Golitsyna, O.L. Datenbanken: Lehrbuch / O.L. Golitsyna, N.V. Maksimov, I.I. Popow. - M.: Forum, 2012.

3. Karpova, I.P. Datenbanken: Lehrbuch / I.P. Karpova. - St. Petersburg: Peter, 2013.

4. Kirillov, V.V. Einführung in relationale Datenbanken. Einführung in relationale Datenbanken / V.V. Kirillov, G. Yu. Gromow. - St. Petersburg: BHV-Petersburg, 2012.

5. Pirogov, V. Yu. Informationssysteme und Datenbanken: Organisation und Design: Lehrbuch / V.Yu. Pirogow. - St. Petersburg: BHV-Petersburg, 2009.

6. G.N. Fedorov. Informationssysteme. - M.: Akademie, 2013.

7. A.E. Satunina, L.A. Sysoeva. Projektmanagement für Unternehmensinformationssysteme. - M.: Finanzen und Statistik, Infra-M, 2009.

Gepostet auf Allbest.ru

...

Epilog

Bei der Vorbereitung dieses Artikels habe ich versucht, mich hauptsächlich auf Architekten, Analysten und Entwickler zu konzentrieren, die direkt mit Data Warehouses arbeiten. Doch es stellte sich heraus, dass sie zwangsläufig „das Thema etwas weiter fasste“ – und andere Leserkategorien kamen in den Blick. Einige Punkte werden kontrovers erscheinen, andere sind unklar, andere sind offensichtlich. Menschen sind unterschiedlich – mit unterschiedlichen Erfahrungen, Hintergründen und Positionen.
Typische Fragen von Managern lauten beispielsweise: „Wann sollte man Architekten engagieren?“, „Wann sollte man sich mit Architektur befassen?“, „Architektur – wird das nicht zu teuer?“ Für uns (Entwickler, Designer) klingen sie ziemlich seltsam, denn für uns erscheint die Architektur eines Systems mit seiner Geburt – egal, ob wir es realisieren oder nicht. Und selbst wenn es keine formale Rolle des Architekten im Projekt gibt, wendet sich ein normaler Entwickler immer „gegen seinen inneren Architekten“.

Im Großen und Ganzen spielt es keine Rolle, wer genau die Rolle eines Architekten ausübt – wichtig ist, dass jemand solche Fragen stellt und nach Antworten darauf sucht. Wenn der Architekt eindeutig identifiziert ist, bedeutet dies nur, dass er in erster Linie für das System und seine Entwicklung verantwortlich ist.
Warum finde ich das Thema „Antifragilität“ für dieses Thema relevant?

„Das Einzigartige an der Antifragilität ist, dass sie es uns ermöglicht, mit dem Unbekannten zu arbeiten, etwas unter Bedingungen zu tun, in denen wir nicht verstehen, was wir tun, und Erfolg zu haben.“/Nassim N. Taleb/

Daher sind die Krise und ein hohes Maß an Unsicherheit keine Entschuldigung für den Mangel an Architektur, sondern Faktoren, die deren Bedarf verstärken.

Tags: Tags hinzufügen

5.1. Organisation von Daten in Unternehmensinformationssystemen.

Betrachtet man das CIS auf der einfachsten Ebene, kann man sagen, dass es ein Unternehmenscomputernetzwerk (Computernetzwerk) und ein spezielles Anwendungssoftwarepaket (APP) zur Lösung von Problemen im Fachgebiet enthält. Sowohl PPP als auch ein Computernetzwerk beinhalten wiederum grundsätzlich die Nutzung von Informationsdaten über den Zustand und die Entwicklung der von ihnen gesteuerten und verwalteten Systeme. Historisch gesehen besteht das CIS aus separaten verzweigten Subsystemen einzelner Unternehmen, die miteinander verbunden sind und oft ein hierarchisches System darstellen. Es liegt nahe, anzunehmen, dass solche Subsysteme sowohl über eigene Quellen als auch über eigene Speicherorte für zugehörige Daten verfügen. Durch die Zusammenführung zu einem System stellen sich Fragen hinsichtlich der gemeinsamen korrekten Nutzung von Daten, die sich geografisch an unterschiedlichen Speicherorten befinden. Um einen Produktionsverbund, der mit einem CIS ausgestattet ist, erfolgreich zu verwalten, benötigt er daher ein zuverlässiges System zur Erfassung, Speicherung und Verarbeitung von Daten. Mit anderen Worten: Es wird eine einheitliche Informationsinfrastruktur benötigt, die strategische BI-Projekte (Business Intelligence) erfüllt, oder eine integrierte Basis für die Speicherung und Nutzung von Daten. Das Hauptziel der Datenintegration besteht darin, ein einheitliches und vollständiges Bild über den Zustand der Unternehmensdaten zu erhalten. Die Integration selbst ist ein komplexer Prozess, auf dessen Grundlage Folgendes hervorgehoben werden sollte:

Technologien,

Produkte,

Anwendungen.

Methoden sind Ansätze zur Datenintegration.

Technologien– Dabei handelt es sich um Prozesse, die bestimmte Methoden der Datenintegration implementieren.

Produkte– Hierbei handelt es sich um kommerzielle Lösungen, die die eine oder andere Datenintegrationstechnologie unterstützen.

Anwendungen– Hierbei handelt es sich um vorgefertigte technische Lösungen, die von Entwicklern gemäß den Wünschen der Kunden – Kunden – bereitgestellt werden.

Abhängig von der Komplexität der Unternehmensinformationssysteme und den Aufgaben, die sie lösen sollen, variiert die Organisation der Daten darin etwas. Insbesondere im CIS, das die effektive Verwaltung von Geschäftsprozessen sowohl einzelner Niederlassungen als auch des gesamten Unternehmens gewährleisten soll, ist es üblich, über das Vorhandensein von Unternehmensdatenbanken zu sprechen. In Unternehmensinformationssystemen, die auf den höchsten Managementebenen eingesetzt werden und meist mit den Prozessen der Betriebsanalyse und Entscheidungsfindung, im Prozess der Planung, Gestaltung und Prognose verschiedener Art verbunden sind Managementtätigkeiten Verwenden Sie die Data-Warehouse-Terminologie. Es ist angebracht zu beachten, dass der Satz Integrierter Datenspeicher beiden inhärent.

5.2. Unternehmensdatenbanken und Anforderungen an sie

Als systemweit integrierter Datenspeicher ist die Unternehmensdatenbank darauf ausgelegt, Informationen für die effektive Verwaltung aller Geschäftsprozesse und Unternehmensbereiche bereitzustellen. Bei der Datenintegration wird eine neue Struktur geschaffen, die Daten aus den Datenbanken einzelner Abteilungen organisch einbezieht. Daher muss eine solche Struktur bestimmte Anforderungen erfüllen:

· Einfache und benutzerfreundliche Dateneingabe in die Datenbank,

· Speichern von Daten in einer Form, die nicht zu einem übermäßigen Datenwachstum führt,

· Verfügbarkeit allgemeiner Informationen für Mitarbeiter aller Unternehmensbereiche, vorbehaltlich der zwingenden Bedingung der Differenzierung der Zugriffsrechte,

· Die benötigten Informationen schnell finden und abrufen,

· Sortieren und Filtern der erforderlichen Daten,

· Gruppierung gleichnamiger Daten,

· Zwischen- und Endberechnungen über Felder,

· Transformation und Klarheit der Ausgabedaten,

· Skalierbarkeit,

· Schutz vor versehentlichen Ausfällen, unwiederbringlichem Datenverlust und unbefugtem Zugriff.

Darüber hinaus ist es bei der Integration separater (verteilter) Datenbanken in eine einzige Unternehmensdatenbank wichtig, die Möglichkeit sicherzustellen, dass mit der Datenbank so gearbeitet werden kann, dass der Benutzer mit ihr wie mit einer nicht verteilten Datenbank arbeitet.

Die Erstellung einer integrierten Unternehmensdatenbank ist mit verschiedenen Methoden möglich, die wichtigsten sind:

· Konsolidierung,

· Föderalisierung,

· Verbreitung.

5.3. Merkmale von Integrationslösungen für Unternehmensdatenbanken

Konsolidierung. Unter Konsolidierung bezieht sich normalerweise auf das Hinzufügen gleichnamiger Daten. Ein ähnlicher Begriff ist in der Bankenbranche weit verbreitet, wo eine jährliche Konzernbilanz erstellt wird, die es ermöglicht, alle Vermögenswerte und Verbindlichkeiten der Mutterbank sowie ihrer Filialen darzustellen.

In Bezug auf ein Unternehmen werden bei dieser Methode Daten aus Primärdatenbanken (DB – Slave) kopiert und gesammelt, indem sie an einem einzigen Speicherort (DB – Master) integriert werden. Als solcher Speicherort wird in der Regel der Server der Zentrale (Zentrale) gewählt (Abb. 5.1).

Abb.5.1. Datenkonsolidierungsmethode

Die Daten in der Master-Datenbank dienen der Berichterstattung, Analyse, Entwicklung und Entscheidungsfindung sowie als Datenquelle für andere Unternehmenszweige.

Die gebräuchlichsten Technologien zur Unterstützung solcher Lösungen während der Konsolidierung sind die folgenden Technologien:

· Extrahieren, transformieren und laden – ETL (Extract Transform Load);

· Content Management für Unternehmen – ECM (Enterprise Content Management).

Die Vorteile der Konsolidierungsmethode sind:

1. Fähigkeit zur Transformation(Umstrukturierung, Abgleich, Bereinigung und/oder Aggregation) erheblicher Datenmengen im Prozess ihrer Übertragung von Primärsystemen zu endgültigen Speicherorten durch ETL-Technologie,

2. Fähigkeit, unstrukturierte Daten zu verwalten, wie Dokumente, Berichte und Seiten dank ECM-Technologielösungen.

Um mit der konsolidierten CIS-Datenbank zu arbeiten, ist etwas Besonderes Geschäftsanwendungen, mit denen Sie Abfragen zu Datenbankdaten und Berichten erstellen und darauf basierend Datenanalysen durchführen können.

Der Nachteil der Integration durch Konsolidierung besteht darin, dass die konsolidierten Daten im integrierten Speicherort aufgrund von Synchronisationskonflikten nicht synchron mit Datenaktualisierungen in den Primärsystemen aktualisiert werden können.

Es gibt eine Zeitverzögerung zwischen den Zeitpunkten der Datenaktualisierung in den Primärsystemen und am endgültigen Speicherort.

Diese Verzögerung kann zwischen einigen Sekunden und mehreren Stunden oder sogar Tagen liegen.

Föderalisierung. Unter Föderalisierung bezieht sich normalerweise auf eine Gewerkschaft. Ein ähnlicher Begriff wird in der Politik häufig bei der Festlegung der Grenzen eines Staates (z. B. Deutschland, Russische Föderation, USA) verwendet.

Der Prozess der Datenföderalisierung in einer Unternehmensdatenbank ist die Erstellung eines virtuellen (scheinbaren) Bildes, das mehrere Primärdatendateien zu einem einzigen virtuellen Ganzen vereint (siehe Abb. 5.2). Tatsächlich besteht die Datenföderalisierung darin, Daten aus Primärsystemen auf der Grundlage externer Anforderungen zu extrahieren. Die Verwaltung der nach der Bundesmethode integrierten Unternehmensdatenbank erfolgt durch Föderalisierungsprozessor.

Abb.2. Datenföderalisierungsmethode

Beim Zugriff auf Daten aus einer virtuellen Datenbank generiert jede Geschäftsanwendung eine Anfrage an das virtuelle Bild. Basierend auf dieser Anfrage ruft der Federation-Prozessor Daten von den entsprechenden Primärsystemen ab, integriert sie gemäß dem virtuellen Bild und stellt das Ergebnis der Geschäftsanwendung zur Verfügung, die die Anfrage generiert hat. In diesem Fall werden alle notwendigen Datentransformationen bereits bei der Extraktion aus den Primärsystemen durchgeführt.

Unterstützung für den föderierten Ansatz zur Datenintegration bietet die Enterprise Information Integration (E I I)-Technologie, was Integration of Corporate Information bedeutet.

Eine Besonderheit der Federation-Lösung besteht darin, dass der Federalization-Prozessor zum Einsatz kommt Metadaten(Wissen), das Daten über die Zusammensetzung und Eigenschaften des virtuellen Bildes, die Datenmenge, semantische Verbindungen zwischen ihnen und Möglichkeiten für den Zugriff darauf enthält und dabei hilft, den Zugriff auf Primärsysteme durch die föderative Lösung zu optimieren.

Die Hauptvorteile des föderalen Ansatzes sind:

· Möglichkeit, auf aktuelle Daten zuzugreifen, ohne eine zusätzliche neue Datenbank zu erstellen,

Machbarkeit der Anwendbarkeit nach der Übernahme oder Fusion von Unternehmen,

· Unverzichtbarkeit in Fällen, in denen aus Sicherheitsgründen lizenzrechtliche Beschränkungen für das Kopieren von Daten aus Primärsystemen bestehen,

· bei Bedarf die hohe Autonomie der lokalen Unternehmensbereiche und die Flexibilität der zentralen Kontrolle ihrer Aktivitäten nutzen,

· hoher Nutzen für große transnationale Konzerne.

Zu den Nachteilen des Ansatzes gehören:

· Reduzierte Produktivität aufgrund zusätzlicher Kosten für den Zugriff auf mehrere Datenquellen,

Die Föderalisierung eignet sich am besten zum Abrufen kleiner Datenmengen.

· hohe Anforderungen an die Qualität der Primärdaten.

Verbreitung. Unter Verbreitung bezieht sich normalerweise auf die territoriale Übertragung multiplizierter Objekte. Unter Datenverteilung versteht man die Vervielfachung primärer Datenbanken und deren Bewegung von einem Ort zum anderen. Bei der Implementierung dieser Methode Geschäftsanwendungen Online arbeiten und Daten je nach eintretenden bestimmten Ereignissen an Ziele verschieben. Für diese technische Lösung wird die Frage der Aktualisierung von Daten, die im synchronen oder asynchronen Modus möglich ist, wichtig. Der synchrone Modus geht davon aus, dass Aktualisierungen sowohl im Primärsystem als auch im Zielsystem während derselben physischen Transaktion erfolgen.

Beispiele für Technologien, die die Implementierung der Datenverbreitungsmethode unterstützen, sind:

· Integration von Unternehmensanwendungen EAI – Enterprise Application Integration,

· Replikation von Unternehmensdaten EDR – Enterprise Data Replication.

Die verallgemeinerte Struktur der Implementierung der Datenverbreitungsmethode sieht wie in Abb. 5.3 aus.

Abb.5.3. Datenverbreitungsmethode

Ein besonderes Merkmal der Datenverteilungsmethode ist die garantierte Übermittlung der Daten an das Zielsystem mit minimaler Latenz, nahezu in Echtzeit.

Die Kombination von Integrations- (EAI) und Replikationstechnologien (EDR) in der Methode bietet mehrere Vorteile in Form der folgenden Vorteile:

· Hochleistung,

· Möglichkeit der Umstrukturierung und Bereinigung von Daten,

· Lastausgleich durch Erstellen von Backups und Wiederherstellen von Daten.

Hybrider Ansatz. Die Realität der Wirtschaftstätigkeit sieht so aus, dass es keine zwei identischen Unternehmen gibt, geschweige denn zwei identische Konzerne. Dieser Umstand prägt den Prozess der Erstellung und Befüllung des CIS. Dies gilt uneingeschränkt für Methoden der Datenintegration in Datenbanken. Aus diesem Grund verwenden viele CIS das sogenannte Hybrid ein Ansatz, der gleichzeitig mehrere Integrationsmethoden umfasst. Beispiele für diesen Ansatz sind Technologien, die ein konsistentes Bild der Kundeninformationen liefern:

· Integration von Kundendaten in CDI-Systeme – Customer Data Integration,

· Integration von Kundendaten in CRM – Customer Relations Management-Module.

Insbesondere die Implementierung von CDI kann auf verschiedene Arten angegangen werden.

Der einfachste Weg besteht darin, eine konsolidierte Kundendatenbank zu erstellen, die Daten aus Primärsystemen enthält. In diesem Fall kann die Informationsverzögerung durch die Verwendung verschiedener Konsolidierungsmodi reguliert werden: operativ oder stapelweise, abhängig von der Häufigkeit der Aktualisierung dieser Informationen.

Die zweite Methode ist die Datenföderalisierung, wenn sie virtuell ist Geschäftspräsentationen Kundendaten, die in Primärsystemen enthalten sind. Und die Metadatendatei kann gemeinsame Schlüsselelemente enthalten, die zur Verknüpfung von Kundeninformationen verwendet werden können.

Somit können allgemeine Kundendaten (z. B. Details) als statischste Daten konsolidiert werden. Und dynamischere Daten (z. B. Informationen zu Bestellungen) können föderalisiert werden.

Darüber hinaus kann der hybride Ansatz durch den Einsatz einer Datenverbreitungsmethode erweitert werden. Beispielsweise ändert ein Kunde, der die Dienste eines Online-Shops nutzt, seine Daten während des Dienstes. Diese Änderungen können an den konsolidierten Teil der Datenbank gesendet und von dort an alle Primärsysteme verteilt werden, die Daten über die Kunden des Geschäfts enthalten.

Unter Berücksichtigung der Vor- und Nachteile jeder Methode ist es ratsam, bei der Anwendung und gemeinsamen Nutzung kreativ vorzugehen.

Beispielsweise ist es ratsam, die Datenföderalisierung in Fällen zu nutzen, in denen die Kosten der Datenkonsolidierung die geschäftlichen Vorteile der Konsolidierung übersteigen. Insbesondere die zeitnahe Bearbeitung von Anfragen und die Erstellung von Berichten ist genau eine solche Situation.

Die praktische Anwendung der Datenverteilungsmethode ist sehr vielfältig, sowohl hinsichtlich der Leistung als auch hinsichtlich der Möglichkeiten zur Umstrukturierung und Bereinigung von Daten.

5.4. Konzept und Strukturlösungen von Data Warehouses

Datenspeicher - Es handelt sich um einen themenorientierten integrierten Informationsspeicher, der externe und betriebliche Daten sowie Daten aus anderen Systemen sammelt, auf deren Grundlage Entscheidungs- und Datenanalyseprozesse aufgebaut werden.

Im Gegensatz zu Datenbanken und Datenbanken bilden Data Warehouses nicht interne, sondern externe Datenquellen: verschiedene Informationssysteme, elektronische Archive, öffentlich zugängliche elektronische Kataloge, Nachschlagewerke und Sammlungen.

Das Konzept von Data Warehouses basiert auf zwei Hauptideen:

1. Integration getrennter Detaildaten (Beschreibung spezifischer Fakten, Eigenschaften, Ereignisse usw.) in einem einzigen Repository.

2. Trennung von Datensätzen und Anwendungen, die zur Verarbeitung und Analyse verwendet werden.

Ein Data Warehouse wird in Fällen organisiert, in denen Folgendes benötigt wird:

· Integration aktueller und historischer Datenwerte,

· Kombinieren von Daten aus unterschiedlichen Quellen,

· Schaffung einer zuverlässigen Datenplattform für Analysezwecke,

· Sicherstellung der Datenhomogenität in der Organisation,

· Erleichtern Sie die Implementierung von Unternehmensdatenstandards, ohne bestehende Betriebssysteme zu ändern.

· Bereitstellung einer breiten historischen Perspektive und Möglichkeiten zur Analyse von Entwicklungstrends.

Historisch gesehen wurden Data Warehouses auf einer, zwei und drei Ebenen aufgebaut.

Einstufige Schemata waren ursprünglich für einfachste Architekturen gedacht, die funktionale DSS beinhalten, mit unzureichend entwickelter Informationsinfrastruktur, wenn die Analyse anhand von Daten aus operativen Systemen erfolgt, nach dem Prinzip: Daten - Formen der Präsentation.

Die Vorteile solcher Systeme sind:

· Schnelle Datenübertragung von operativen Systemen zu einem spezialisierten System ohne Zwischenverbindungen,

· Minimale Kosten durch die Nutzung einer einzigen Plattform.

Mängel:

· Geringe Bandbreite an zu lösenden Problemen aufgrund einer einzigen Datenquelle,

· Geringe Datenqualität aufgrund fehlender Bereinigungsschritte.

Zweistufige Systeme Stellen Sie eine Kette bereit: Daten – Data Marts – Präsentationsformulare. Sie werden in Unternehmen mit einer Vielzahl eigenständiger Abteilungen eingesetzt, die eigene Informationstechnologien nutzen.

Vorteile:

· Die verwendeten Vitrinen sind darauf ausgelegt, eine bestimmte Anzahl von Fragen zu beantworten.

· Es ist möglich, Daten in Storefronts zu optimieren, was die Produktivität verbessert.

Mängel:

· Schwierigkeiten bei der Sicherstellung der Datenkonsistenz aufgrund der wiederholten Wiederholung in Schaufenstern,

· Potenzielle Komplexität beim Füllen von Storefronts mit einer großen Anzahl von Datenquellen,

· Aufgrund der fehlenden Datenkonsolidierung auf Unternehmensebene gibt es kein einheitliches Bild des Unternehmens.

Die Entwicklung der Entwicklung hat dazu geführt, dass mit dem Aufbau eines vollwertigen Data Warehouse für moderne Unternehmenssysteme begonnen wurde dreistufige Architektur (siehe Abb. 5.4).

An Erste Ebene gibt es verschiedene Aufzeichnungssysteme, die als Datenquellen dienen. Solche Systeme können Enterprise-Resource-Planning-Systeme (ERP – Enterprise Resource Planning), Referenz-(Betriebs-)Systeme, externe Quellen oder Systeme, die Daten von Informationsagenturen liefern usw. sein.

An zweite Ebene enthält einen zentralen Speicher, der Daten aus allen Quellen der ersten Ebene sammelt, sowie ein operatives Data Warehouse, das zwei Funktionen erfüllen soll:

· Das Lager ist eine Quelle analytischer Informationen für die Betriebsführung,

· Im operativen Lager werden die Daten für die anschließende Verladung in das Zentrallager vorbereitet. Unter Datenaufbereitung versteht man die Durchführung von Kontrollen und Datentransformationen im Zusammenhang mit verschiedenen Regelungen zum Empfang von Daten aus der ersten Ebene.

Dritte Das Level ist eine Sammlung themenorientierter Data Marts.

Data Marts – Hierbei handelt es sich um relativ kleine, funktionsorientierte Laufwerke, deren Inhalte zur Lösung analytischer Probleme einzelner Unternehmensbereiche beitragen. Data Marts sind im Wesentlichen Teilmengen von Daten aus einem Warehouse. Gleichzeitig haben Endbenutzer die Möglichkeit, auf detaillierte Daten aus dem Lager zuzugreifen, falls nicht genügend Daten im Storefront vorhanden sind, und sich ein umfassenderes Bild der Geschäftslage zu verschaffen.

Abb.5.4. Data Warehouse-Architektur

Die wichtigsten technologischen Operationen der auf diese Weise organisierten Data Warehouses sind:

· Extraktion Daten sind der Prozess der Übertragung von Daten aus heterogenen Quellen in ein operatives Lager.

· Konvertierung Daten sind die Änderung von Daten auf der Grundlage spezieller Regeln mit anschließender Übertragung in einen zentralen Speicher.

· Reinigung Daten bedeutet die Eliminierung der Duplizierung von Daten aus verschiedenen Quellen.

· Aktualisieren Daten sind die Weitergabe von Datenaktualisierungen an die Quelldaten der Basistabellen und abgeleiteten Daten im Warehouse.

Vorteile:

· Das Befüllen von Storefronts wird durch die Verwendung einer einzigen Quelle gelöschter Daten vereinfacht.

· Data Marts werden mit dem Geschäftsbild des Unternehmens synchronisiert, was die Erweiterung des zentralen Speichers und das Hinzufügen von Data Marts erleichtert.

· Garantierte Leistung.

Mängel:

· Das Vorhandensein von Datenredundanz, was zu erhöhten Anforderungen an die Datenspeichertechnologie führt,

5. 5. Datenbankverwaltungssysteme und Datenzugriffstechnologien in der GUS

Datenbankverwaltungssystem(DBMS) ist eine Reihe von Sprach- und Softwaretools, die für die Erstellung, Pflege und gemeinsame Nutzung einer Datenbank durch einen oder mehrere Benutzer konzipiert sind.

Derzeit sind die am weitesten verbreiteten DBMS solche, die auf einem relationalen Datenmodell basieren, das durch einen strengen mathematischen Apparat beschrieben wird. Beziehungstheorien.

Ein Merkmal von DBMS, die in einem CIS arbeiten, ist die Tatsache, dass sie Datenbanken verwalten müssen, die sich auf im Weltraum verteilten Medien befinden.

Um ein zusätzliches Duplizieren oder Kopieren von Daten im ZIS zu vermeiden, wird der Schwerpunkt auf das Prinzip der Datenfernverarbeitung gelegt. Datenbanken im CIS enthalten Daten, die von vielen Benutzern benötigt werden. Der gleichzeitige Zugriff mehrerer Benutzer auf eine Datenbank ist möglich, wenn ein DBMS in einem lokalen Computernetzwerk installiert wird, das mit Benutzern und einer einzelnen Datenbank arbeitet.

Die wichtigsten technologischen Lösungen für die Mehrbenutzerarbeit mit Datenbanken sind Datei/Server- und Client/Server-Technologien. Der Client/Server im CIS nutzt die am besten geeignete Option dieser Technologien und organisiert spezialisierte Systeme für die Verarbeitung verteilter Datenbanken. Gleichzeitig werden verteilte Datenbanken so verwaltet, dass die Daten nicht auf logischer, sondern auf physischer Ebene verteilt werden und die Datenbank selbst als einzelnes „Superschema“ betrachtet wird. In einer verteilten Datenbank werden Verwaltungsfunktionen zwischen dem integrierten Datenbankadministrator und den lokalen Datenbankadministratoren verteilt. Der Administrator der integrierten Datenbank überwacht die Abgrenzung des Zugriffs verschiedener Benutzer auf die Datenbank und gewährleistet die Integrität und Sicherheit der Daten sowie den Schutz der Daten vor gleichzeitiger Korrektur durch mehrere Benutzer. Die Zugriffskontrolle erfolgt entsprechend den den einzelnen Benutzern im Netzwerkbetriebssystem gewährten Rechten.

Ein charakteristisches Merkmal von Programmen, die mit einem DBMS für die Arbeit mit entfernten und verteilten Unternehmensdatenbanken erstellt wurden, ist die Verwendung einer offenen Datenzugriffsschnittstelle – ODBC (Open Data Base Connectivity). Alle Datenübertragungsfunktionen sind der ODBC-Schnittstelle zugeordnet, die eine Verbindungsbrücke zwischen dem integrierten Datenbank-DBMS und dem Client-Anwendungs-DBMS darstellt. Gleichzeitig kann das DBMS des Kunden nicht nur mit seinen lokalen Datenbanken interagieren, sondern auch mit Daten, die sich in der integrierten Datenbank befinden. Der Kunde hat die Möglichkeit, Anfragen an das integrierte Datenbank-DBMS zu senden, Daten von ihnen zu empfangen und eigene aktualisierte Daten zu senden.

Branchendatenmodelle

Der Hauptzweck von Modellen besteht darin, die Orientierung im Datenraum zu erleichtern und bei der Identifizierung von Details zu helfen, die für die Geschäftsentwicklung wichtig sind. Um ein erfolgreiches Unternehmen zu führen, ist es im heutigen Umfeld unbedingt erforderlich, ein klares Verständnis der Zusammenhänge zwischen verschiedenen Komponenten und ein gutes Verständnis des Gesamtbildes der Organisation zu haben. Die Identifizierung aller Details und Zusammenhänge anhand von Modellen ermöglicht die effizienteste Nutzung von Zeit und Werkzeugen zur Organisation der Unternehmensarbeit.

Datenmodelle sind abstrakte Modelle, die beschreiben, wie Daten dargestellt und abgerufen werden. Datenmodelle definieren Datenelemente und Beziehungen zwischen ihnen in einem bestimmten Bereich. Ein Datenmodell ist ein Navigationstool für Geschäfts- und IT-Experten, das einen bestimmten Satz von Symbolen und Wörtern verwendet, um eine bestimmte Klasse realer Informationen genau zu erklären. Dies ermöglicht ein besseres Verständnis innerhalb der Organisation und schafft so eine flexiblere und stabilere Anwendungsumgebung.

Das Datenmodell definiert eindeutig die Bedeutung der Daten, bei denen es sich in diesem Fall um strukturierte Daten handelt (im Gegensatz zu unstrukturierten Daten wie Bildern, Binärdateien oder Texten, bei denen die Bedeutung möglicherweise nicht eindeutig ist).

In der Regel gibt es Modelle höherer Ebene (und inhaltlich allgemeiner) und niedrigerer (bzw. detaillierterer). Die oberste Ebene der Modellierung ist die sogenannte Konzeptionelle Datenmodelle(konzeptionelle Datenmodelle), die ein möglichst allgemeines Bild der Funktionsweise eines Unternehmens oder einer Organisation vermitteln. Das konzeptionelle Modell umfasst die Kernkonzepte oder Themenbereiche, die für das Funktionieren der Organisation von entscheidender Bedeutung sind. normalerweise überschreitet ihre Zahl 12-15 nicht. Ein solches Modell beschreibt Klassen von Entitäten, die für eine Organisation wichtig sind (Geschäftsobjekte), ihre Merkmale (Attribute) und Assoziationen zwischen Paaren dieser Klassen (d. h. Beziehungen). Da die Terminologie in der Geschäftsmodellierung noch nicht vollständig gefestigt ist, werden konzeptionelle Datenmodelle in verschiedenen englischsprachigen Quellen auch als Subject Area Models (übersetzt als Subject Area Models) oder Subject Enterprise Data Models (subjektbezogene Unternehmensdatenmodelle) bezeichnet. .

Die nächste hierarchische Ebene ist logische Datenmodelle(logische Datenmodelle). Sie können auch als Unternehmensdatenmodelle oder Geschäftsmodelle bezeichnet werden. Diese Modelle enthalten Datenstrukturen, deren Attribute und Geschäftsregeln und stellen die vom Unternehmen verwendeten Informationen aus geschäftlicher Sicht dar. In einem solchen Modell werden Daten in Form von Entitäten und Beziehungen zwischen ihnen organisiert. Das Logikmodell stellt Daten auf eine Weise dar, die für Geschäftsanwender leicht verständlich ist. Ein logisches Modell kann ein Datenwörterbuch enthalten – eine Liste aller Entitäten mit ihren genauen Definitionen, die es verschiedenen Benutzerkategorien ermöglicht, ein gemeinsames Verständnis aller Eingabe- und Informationsausgabeströme des Modells zu erlangen. Die nächste, niedrigere Ebene der Modellierung ist die physische Umsetzung des logischen Modells mithilfe spezifischer Software und technischer Plattformen.

Ein Logikmodell enthält eine detaillierte Unternehmensgeschäftslösung, die typischerweise die Form eines normalisierten Modells annimmt. Bei der Normalisierung handelt es sich um einen Prozess, der sicherstellt, dass jedes Datenelement in einem Modell nur einen Wert hat und vollständig und eindeutig vom Primärschlüssel abhängt. Datenelemente werden entsprechend ihrer eindeutigen Identifizierung in Gruppen organisiert. Geschäftsregeln, die Datenelemente steuern, müssen vollständig in das normalisierte Modell einbezogen werden, wobei zunächst ihre Gültigkeit und Richtigkeit überprüft werden muss. Beispielsweise würde ein Datenelement wie „Kundenname“ wahrscheinlich in „Vorname“ und „Nachname“ aufgeteilt und mit anderen entsprechenden Datenelementen in einer Kundenentität mit dem Primärschlüssel „Kunden-ID“ gruppiert.

Das logische Datenmodell ist unabhängig von Anwendungstechnologien wie Datenbanken, Netzwerktechnologien oder Berichtstools und den Mitteln zu ihrer physischen Implementierung. Eine Organisation kann nur ein Unternehmensdatenmodell haben. Logische Modelle umfassen typischerweise Tausende von Entitäten, Beziehungen und Attributen. Beispielsweise kann ein Datenmodell für ein Finanzinstitut oder ein Telekommunikationsunternehmen etwa 3.000 Branchenkonzepte enthalten.

Es ist wichtig, zwischen einem logischen und einem semantischen Datenmodell zu unterscheiden. Das logische Datenmodell repräsentiert die Unternehmensgeschäftslösung und das semantische Datenmodell repräsentiert die Anwendungsgeschäftslösung. Das gleiche logische Unternehmensdatenmodell kann mithilfe verschiedener semantischer Modelle implementiert werden, d. h. Semantische Modelle können als nächste Ebene der Modellierung betrachtet werden und nähern sich physikalischen Modellen. Darüber hinaus stellt jedes dieser Modelle einen separaten „Ausschnitt“ des Unternehmensdatenmodells entsprechend den Anforderungen verschiedener Anwendungen dar. Beispielsweise wird in einem logischen Unternehmensdatenmodell die Client-Entität vollständig normalisiert und in einem semantischen Modell für einen Data Mart kann sie als mehrdimensionale Struktur dargestellt werden.

Ein Unternehmen hat möglicherweise zwei Möglichkeiten, ein logisches Unternehmensdatenmodell zu erstellen: es unabhängig zu erstellen oder ein vorgefertigtes Modell zu verwenden Branchenmodell(Branchenlogisches Datenmodell). In diesem Fall spiegeln die Unterschiede in den Begriffen nur unterschiedliche Ansätze zur Konstruktion desselben logischen Modells wider. Wenn ein Unternehmen eigenständig ein eigenes logisches Datenmodell entwickelt und implementiert, wird ein solches Modell in der Regel einfach als Unternehmenslogikmodell bezeichnet. Entscheidet sich eine Organisation für den Einsatz eines fertigen Produkts eines professionellen Anbieters, dann kann man von einem branchenspezifischen logischen Datenmodell sprechen. Letzteres ist ein vorgefertigtes logisches Datenmodell, das die Funktionsweise einer bestimmten Branche genau widerspiegelt. Ein Branchenlogikmodell ist eine domänenspezifische und integrierte Ansicht aller Informationen, die in einem Unternehmens-Data-Warehouse vorhanden sein müssen, um sowohl strategische als auch taktische Geschäftsfragen zu beantworten. Wie jedes andere logische Datenmodell ist das Branchenmodell unabhängig von Anwendungslösungen. Es enthält auch keine Ableitungen oder andere Berechnungen für einen schnelleren Datenabruf. In der Regel lassen sich die meisten logischen Strukturen eines solchen Modells gut in seine effiziente physische Umsetzung übersetzen. Solche Modelle werden von vielen Anbietern für die unterschiedlichsten Bereiche entwickelt: Finanzdienstleistungen, Fertigung, Tourismus, Gesundheitswesen, Versicherungen usw.

Das logische Branchendatenmodell enthält branchenübliche Informationen und kann daher keine vollständige Lösung für ein Unternehmen darstellen. Die meisten Unternehmen müssen ihr Modell um durchschnittlich 25 % erweitern, indem sie Datenelemente hinzufügen und Definitionen erweitern. Vorgefertigte Modelle enthalten nur die wichtigsten Datenelemente, die restlichen Elemente müssen während der Installation des Modells im Unternehmen zu den entsprechenden Geschäftsobjekten hinzugefügt werden.

Logische Datenmodelle der Branche enthalten eine beträchtliche Anzahl an Abstraktionen. Abstraktionen beziehen sich auf die Gruppierung ähnlicher Konzepte unter gebräuchlichen Namen wie „Ereignis“ oder „Teilnehmer“. Dadurch werden Branchenmodelle flexibler und einheitlicher. Somit ist das Konzept der Events auf alle Branchen anwendbar.

Der Business-Intelligence-Experte Steve Hoberman nennt fünf Faktoren, die bei der Kaufentscheidung für ein Branchendatenmodell zu berücksichtigen sind. Der erste ist der Zeit- und Geldaufwand, der für den Bau des Modells erforderlich ist. Wenn eine Organisation schnell Ergebnisse erzielen muss, bietet ein Branchenmodell einen Vorteil. Die Verwendung eines Branchenmodells bietet möglicherweise nicht sofort einen Überblick über die gesamte Organisation, kann jedoch erheblich Zeit sparen. Anstatt tatsächlich zu modellieren, wird Zeit damit verbracht, bestehende Strukturen mit dem Branchenmodell zu verknüpfen und zu diskutieren, wie es am besten an die Bedürfnisse der Organisation angepasst werden kann (z. B. welche Definitionen geändert und welche Datenelemente hinzugefügt werden sollten).

Der zweite Faktor ist der Zeit- und Geldaufwand, der erforderlich ist, um das Modell funktionsfähig zu halten. Wenn das Unternehmensdatenmodell nicht Teil einer Methodik ist, die seine Genauigkeit und Aktualität gewährleistet, wird das Modell schnell veraltet sein. Das Branchendatenmodell kann diesem Risiko vorbeugen, da es durch externe Ressourcen aktuell gehalten wird. Natürlich müssen innerhalb der Organisation auftretende Änderungen vom Unternehmen selbst im Modell widergespiegelt werden, Branchenveränderungen werden jedoch vom Lieferanten im Modell reproduziert.

Der dritte Faktor ist Erfahrung in der Risikobewertung und -modellierung. Die Erstellung eines Unternehmensdatenmodells erfordert qualifizierte Ressourcen sowohl von Geschäfts- als auch von IT-Personal. Führungskräfte verfügen in der Regel über gute Kenntnisse entweder der Arbeit der gesamten Organisation oder der Aktivitäten einer bestimmten Abteilung. Nur wenige von ihnen verfügen sowohl über umfassende (unternehmensweite) als auch tiefe (abteilungsinterne) Kenntnisse ihres Geschäfts. Die meisten Manager neigen dazu, sich nur in einem Bereich gut auszukennen. Daher erfordert die Erlangung einer unternehmensweiten Sicht erhebliche Geschäftsressourcen. Dadurch steigen auch die Anforderungen an das IT-Personal. Je mehr Geschäftsressourcen zum Erstellen und Testen eines Modells erforderlich sind, desto erfahrener müssen die Analysten sein. Sie müssen nicht nur wissen, wie sie Informationen von Geschäftsleuten erhalten, sondern auch in der Lage sein, in kontroversen Bereichen Gemeinsamkeiten zu finden und alle diese Informationen integriert darzustellen. Die Person, die das Modell erstellt (in vielen Fällen derselbe Analyst), muss über gute Modellierungskenntnisse verfügen. Die Erstellung von Unternehmenslogikmodellen erfordert eine Modellierung „für die Zukunft“ und die Fähigkeit, komplexe Geschäfte buchstäblich in „Quadrate und Linien“ zu übersetzen.

Andererseits ermöglicht Ihnen das Branchenmodell, die Erfahrung externer Spezialisten zu nutzen. Branchenspezifische Logikmodelle nutzen bewährte Modellierungsmethoden und Teams erfahrener Fachleute, um häufige und kostspielige Probleme zu vermeiden, die bei der Entwicklung von Unternehmensdatenmodellen innerhalb einer Organisation auftreten können.

Der vierte Faktor ist die bestehende Anwendungsinfrastruktur und die Beziehungen zu Lieferanten. Wenn eine Organisation bereits viele Tools desselben Lieferanten verwendet und Beziehungen zu diesem aufgebaut hat, ist es sinnvoll, eine Fachbranche beim selben Lieferanten zu bestellen. Ein solches Modell kann problemlos mit anderen Produkten desselben Lieferanten zusammenarbeiten.

Der fünfte Faktor ist der brancheninterne Informationsaustausch. Wenn ein Unternehmen Daten mit anderen Organisationen austauschen muss, die im gleichen Bereich tätig sind, kann ein Branchenmodell in dieser Situation sehr nützlich sein. Organisationen innerhalb derselben Branche verwenden ähnliche Strukturkomponenten und Terminologie. Heutzutage sind Unternehmen in den meisten Branchen gezwungen, Daten auszutauschen, um ein erfolgreiches Geschäft zu führen.

Die effektivsten Branchenmodelle sind diejenigen, die von professionellen Anbietern angeboten werden. Die hohe Effizienz ihres Einsatzes wird durch den hohen Detaillierungsgrad und die Genauigkeit dieser Modelle erreicht. Sie enthalten normalerweise viele Datenattribute. Darüber hinaus verfügen die Ersteller dieser Modelle nicht nur über umfassende Modellierungserfahrung, sondern sind auch versiert im Bau branchenspezifischer Modelle.

Branchendatenmodelle bieten Unternehmen eine einzige, integrierte Sicht auf ihre Geschäftsinformationen. Vielen Unternehmen fällt die Integration ihrer Daten schwer, obwohl dies für die meisten unternehmensweiten Projekte eine Voraussetzung ist. Laut einer Studie des Data Warehousing Institute (TDWI) gaben mehr als 69 % der befragten Unternehmen an, dass die Integration ein erhebliches Hindernis für die Einführung neuer Anwendungen darstellt. Im Gegenteil, die Datenintegration bringt dem Unternehmen erhebliche Einnahmen.

Das Branchendatenmodell bietet neben seiner Anbindung an bestehende Systeme große Vorteile für unternehmensweite Projekte wie Enterprise Resource Planning (ERP), Stammdatenmanagement, Business Intelligence, Datenqualitätsverbesserung und Mitarbeiterentwicklung.

Somit sind branchenlogische Datenmodelle ein wirksames Werkzeug, um Daten zu integrieren und ein ganzheitliches Bild des Unternehmens zu erhalten. Der Einsatz logischer Modelle scheint ein notwendiger Schritt zur Schaffung von Enterprise Data Warehouses zu sein.

Veröffentlichungen

Steve Hoberman. Nutzen Sie das logische Branchendatenmodell als Ihr Unternehmensdatenmodell.
Claudia Imhoff. Schnelle Erstellung von Data Warehouses und Durchführung von Business Intelligence-Projekten mithilfe von Datenmodellierung (Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling)

Die Unternehmensdatenbank ist das zentrale Bindeglied des Unternehmensinformationssystems und ermöglicht die Schaffung eines einheitlichen Informationsraums für das Unternehmen. Unternehmensdatenbanken

Teilen Sie Ihre Arbeit in sozialen Netzwerken

Wenn Ihnen dieses Werk nicht zusagt, finden Sie unten auf der Seite eine Liste ähnlicher Werke. Sie können auch die Suchschaltfläche verwenden

THEMA V. UNTERNEHMENSDATENBANKEN

V .1. Organisieren von Daten in Unternehmenssystemen. Unternehmensdatenbanken.

V .2. DBMS und Strukturlösungen in Unternehmenssystemen.

V.3. Internet-/Intranet-Technologien und Enterprise-Datenbankzugriffslösungen.

V .1. ORGANISATION VON DATEN IN UNTERNEHMENSSYSTEMEN. UNTERNEHMENSDATENBANKEN

Unternehmensbasis Daten sind das zentrale Bindeglied des Unternehmensinformationssystems und ermöglichen die Schaffung eines einheitlichen Informationsraums des Unternehmens. Unternehmensdatenbanken (Abb. 1.1).

Es gibt verschiedene Definitionen von Datenbanken.

Unter der Datenbank (DB) Unter einem Satz von Informationen verstehen, die logisch so miteinander verbunden sind, dass sie einen einzigen Satz von Daten darstellen, die in den Speichergeräten eines Computers gespeichert sind. Dieser Satz dient als Ausgangsdaten von Problemen, die im Funktionsprozess automatisierter Steuerungssysteme, Datenverarbeitungssysteme, Informations- und Computersysteme gelöst werden.

Der Begriff Datenbank lässt sich kurz als eine Sammlung logisch zusammengehöriger Daten formulieren, die zur gemeinsamen Nutzung bestimmt sind.

Unten die Datenbank bezieht sich auf eine Sammlung von Daten, die mit einer so geringen Redundanz zusammen gespeichert werden, dass sie für eine oder mehrere Anwendungen optimal genutzt werden können.

Zweck der Erstellung von Datenbanken als Formen der Datenspeicherung Aufbau eines Datensystems, das nicht von den verwendeten Algorithmen (Software), den verwendeten technischen Mitteln oder dem physischen Speicherort der Daten im Computer abhängt. Die Datenbank geht von einer Mehrzwecknutzung aus (mehrere Benutzer, viele Dokumentenformen und Abfragen eines Benutzers).

Grundvoraussetzungen für Datenbanken:

Vollständigkeit der Datenpräsentation. Die Daten in der Datenbank müssen alle Informationen über das Objekt angemessen darstellen und sollten für ODS ausreichend sein.
Datenbankintegrität. Die Daten müssen während der Bearbeitung ihres SOD und in allen Situationen, die sich während des Arbeitsprozesses ergeben, erhalten bleiben.
Flexibilität der Datenstruktur. Die Datenbank sollte eine Änderung der Datenstrukturen ermöglichen, ohne ihre Integrität und Vollständigkeit zu beeinträchtigen, wenn sich äußere Bedingungen ändern.
Durchführbarkeit. Das bedeutet, dass es eine objektive Darstellung verschiedener Objekte, ihrer Eigenschaften und Beziehungen geben muss.
Verfügbarkeit. Es ist notwendig, einen differenzierten Zugriff auf Daten sicherzustellen.
Redundanz. Die Datenbank muss eine minimale Redundanz bei der Darstellung von Daten zu jedem Objekt aufweisen.

Wissen wird verstanden als eine Reihe von Fakten, Mustern und heuristischen Regeln, mit deren Hilfe Sie ein bestimmtes Problem lösen können.

Wissensdatenbank (KB)  eine Reihe von Datenbanken und verwendeten Regeln, die von Entscheidungsträgern stammen. Die Wissensbasis ist ein Element von Expertensystemen.

Es ist notwendig zu unterscheiden verschiedene Möglichkeiten, Daten darzustellen.

Physische Daten Dabei handelt es sich um Daten, die im Computerspeicher gespeichert sind.

Logische Datendarstellung entspricht der Darstellung physischer Daten durch den Benutzer. Der Unterschied zwischen der physischen und der entsprechenden logischen Darstellung von Daten besteht darin, dass letztere einige wichtige Beziehungen zwischen physischen Daten widerspiegelt.

Unter der Unternehmensdatenbank eine Datenbank verstehen, die in der einen oder anderen Form alle notwendigen Daten und Kenntnisse über die zu automatisierende Organisation vereint. In Unternehmensinformationssystemen hat das Konzept von den konzentriertesten Ausdruck gefundenintegrierte Datenbanken, die das Prinzip der einmaligen Eingabe und wiederholten Nutzung von Informationen umsetzen.

Reis. 1.1. Struktur der Interaktion von Abteilungen mit Informationsressourcen des Unternehmens.

Es gibt Unternehmensdatenbanken konzentriert (zentralisiert) und verteilt.

Fokussierte (zentralisierte) Datenbank ist eine Datenbank, deren Daten physisch auf den Speichergeräten eines Computers gespeichert sind. In Abb. Abbildung 1.2 zeigt ein Diagramm einer Serveranwendung für den Zugriff auf Datenbanken auf verschiedenen Plattformen.

Abb.1.2. Heterogenes Schema zentralisierte Datenbank

Die Zentralisierung der Informationsverarbeitung ermöglichte es, solche Nachteile der traditionellen zu beseitigen Dateisysteme, wie Inkohärenz, Inkonsistenz und Datenredundanz. Mit zunehmender Größe der Datenbanken und insbesondere bei der Nutzung in geografisch getrennten Organisationen treten jedoch Probleme auf. Beispielsweise treten bei konzentrierten Datenbanken am Knotenpunkt eines Telekommunikationsnetzes, über die verschiedene Abteilungen der Organisation auf Daten zugreifen, mit zunehmender Informationsmenge und Anzahl der Transaktionen folgende Schwierigkeiten auf:

Großer Datenaustausch;
Hoher Datenverkehr im Netzwerk;
Geringe Zuverlässigkeit;
Geringe Gesamtleistung.

Obwohl es einfacher ist, die Sicherheit, Integrität und Konsistenz von Informationen bei Aktualisierungen in einer konzentrierten Datenbank zu gewährleisten, führen diese Probleme zu gewissen Schwierigkeiten. Als mögliche Lösung für diese Probleme wird die Datendezentralisierung vorgeschlagen. Mit der Dezentralisierung wird Folgendes erreicht:

Höhere Gleichzeitigkeit der Bearbeitung durch Lastverteilung;
Verbesserung der Nutzung von Vor-Ort-Daten bei der Durchführung von Fernabfragen;
Geringere Kosten;
Einfache Verwaltung lokaler Datenbanken.

Die Kosten für die Erstellung eines Netzwerks, dessen Knoten Workstations (kleine Computer) enthalten, sind viel niedriger als die Kosten für die Erstellung eines ähnlichen Systems mit einem großen Computer. Abbildung 1.3 zeigt das logische Diagramm einer verteilten Datenbank.

Abb.1.3. Verteilte Unternehmensdatenbank.

Lassen Sie uns die folgende Definition einer verteilten Datenbank geben.

Verteilte Datenbank - Hierbei handelt es sich um eine Sammlung von Informationen und Dateien (Beziehungen), die in verschiedenen Knoten des Informationsnetzwerks gespeichert und logisch so verbunden sind, dass sie einen einzigen Datensatz bilden (die Verbindung kann funktionsfähig sein oder über Kopien derselben Datei erfolgen). Es handelt sich also um eine Reihe von Datenbanken, die logisch miteinander verbunden sind, sich jedoch physisch auf mehreren Computern befinden, die Teil desselben Computernetzwerks sind.

Die wichtigsten Anforderungen an die Eigenschaften einer verteilten Datenbank sind:

Skalierbarkeit;
Kompatibilität;
Unterstützung verschiedener Datenmodelle;
Portabilität;
Standorttransparenz;
Autonomie verteilter Datenbankknoten (Site Autonomy);
Bearbeitung verteilter Anfragen;
Ausführen verteilter Transaktionen.
Unterstützung eines homogenen Sicherheitssystems.

Durch die Standorttransparenz können Benutzer mit Datenbanken arbeiten, ohne etwas über ihren Standort zu wissen. Die Autonomie verteilter Datenbankknoten bedeutet, dass jede Datenbank unabhängig von den anderen verwaltet werden kann. Eine verteilte Abfrage ist eine Abfrage (SQL-Anweisung), bei deren Ausführung auf Objekte (Tabellen oder Views) verschiedener Datenbanken zugegriffen wird. Bei der Ausführung verteilter Transaktionen besteht eine Parallelitätskontrolle zwischen allen beteiligten Datenbanken. Oracle7 verwendet eine zweiphasige Informationsübertragungstechnologie, um verteilte Transaktionen durchzuführen.

Die Datenbanken, aus denen eine verteilte Datenbank besteht, müssen nicht unbedingt homogen sein (d. h. von demselben DBMS verwaltet werden) oder in derselben Betriebssystemumgebung und/oder auf demselben Computertyp verarbeitet werden. Beispielsweise kann eine Datenbank eine Oracle-Datenbank auf einem SUN-Computer mit dem Betriebssystem SUN OS (UNIX) sein, die zweite Datenbank kann von einem DB2-DBMS auf einem IBM 3090-Mainframe mit dem MVS-Betriebssystem verwaltet werden und die dritte Datenbank kann dies tun von einem SQL/DS-DBMS verwaltet werden, ebenfalls auf einem IBM-Mainframe, jedoch mit einem VM-Betriebssystem. Es ist nur eine Bedingung erforderlich: Alle Maschinen mit Datenbanken müssen über das Netzwerk, zu dem sie gehören, zugänglich sein.

Die Hauptaufgabe einer verteilten Datenbank Verteilung von Daten über das Netzwerk und Bereitstellung des Zugriffs darauf. Es gibt folgende Möglichkeiten, dieses Problem zu lösen:

Jeder Knoten speichert und verwendet seinen eigenen Datensatz, der für Remote-Abfragen verfügbar ist. Diese Verteilung ist geteilt.
Einige Daten, die häufig an entfernten Standorten verwendet werden, können dupliziert sein. Diese Verteilung wird als teilweise dupliziert bezeichnet.
Alle Daten werden in jedem Knoten dupliziert. Diese Verteilung wird als vollständig dupliziert bezeichnet.
Einige Dateien können horizontal (eine Teilmenge von Datensätzen wird zugewiesen) oder vertikal (eine Teilmenge von Attributfeldern wird zugewiesen) aufgeteilt werden, wobei die zugewiesenen Teilmengen zusammen mit den nicht aufgeteilten Daten in verschiedenen Knoten gespeichert werden. Diese Verteilung wird Split (fragmentiert) genannt.

Beim Erstellen einer verteilten Datenbank auf konzeptioneller Ebene müssen Sie folgende Probleme lösen:

Es ist notwendig, ein einziges konzeptionelles Diagramm des gesamten Netzwerks zu haben. Dies gewährleistet eine logische Transparenz der Daten für den Benutzer, sodass er von einem separaten Terminal aus eine Anfrage an die gesamte Datenbank stellen kann (es ist, als ob er mit einer zentralen Datenbank arbeiten würde).
Es ist ein Schema erforderlich, das definiert, wo sich Daten im Netzwerk befinden. Dadurch wird die Transparenz der Datenplatzierung gewährleistet, sodass der Benutzer nicht angeben muss, wohin er die Anfrage weiterleiten soll, um die erforderlichen Daten zu erhalten.
Es ist notwendig, das Problem der Heterogenität verteilter Datenbanken zu lösen. Verteilte Datenbanken können hinsichtlich Hardware und Software homogen oder heterogen sein. Das Problem der Heterogenität lässt sich relativ einfach lösen, wenn die verteilte Datenbank hinsichtlich der Hardware heterogen, aber hinsichtlich der Software homogen ist (identisches DBMS in Knoten). Werden in den Knoten eines verteilten Systems unterschiedliche DBMS eingesetzt, werden Werkzeuge zur Konvertierung von Datenstrukturen und Sprachen benötigt. Dies sollte eine transparente Konvertierung über verteilte Datenbankknoten hinweg ermöglichen.
Das Problem der Wörterbuchverwaltung muss gelöst werden. Um in einer verteilten Datenbank für jegliche Transparenz zu sorgen, sind Programme erforderlich, die zahlreiche Wörterbücher und Nachschlagewerke verwalten.
Es ist notwendig, Methoden zum Ausführen von Abfragen in einer verteilten Datenbank zu definieren. Methoden zur Ausführung von Abfragen in einer verteilten Datenbank unterscheiden sich von ähnlichen Methoden in zentralisierten Datenbanken, da einzelne Teile von Abfragen am Ort der relevanten Daten ausgeführt werden müssen und Teilergebnisse an andere Knoten übermittelt werden müssen; Gleichzeitig muss die Koordination aller Prozesse gewährleistet sein.
Es ist notwendig, das Problem der parallelen Ausführung von Abfragen zu lösen. Eine verteilte Datenbank erfordert einen komplexen Mechanismus zur Verwaltung der gleichzeitigen Verarbeitung, der insbesondere die Synchronisation bei der Aktualisierung von Informationen gewährleisten muss, was die Datenkonsistenz gewährleistet.
Es ist eine entwickelte Methodik für die Datenverteilung und -platzierung erforderlich, einschließlich der Aufteilung, die eine der Hauptanforderungen für eine verteilte Datenbank darstellt.

Einer der sich aktiv entwickelnden neuen Bereiche der Computersystemarchitektur, die ein leistungsstarkes Mittel zur nichtnumerischen Informationsverarbeitung darstellt, ist Datenbankmaschinen. Datenbank-Engines werden zur Lösung nicht-numerischer Probleme eingesetzt, etwa zum Speichern, Suchen und Transformieren von Dokumenten und Fakten sowie zum Arbeiten mit Objekten. Nach der Definition von Daten als digitale und grafische Informationen über Objekte in der umgebenden Welt hat der Begriff der Daten bei der numerischen und nichtnumerischen Verarbeitung unterschiedliche Inhalte. Bei der numerischen Verarbeitung werden Objekte wie Variablen, Vektoren, Matrizen, mehrdimensionale Arrays, Konstanten usw. verwendet, während bei der nicht numerischen Verarbeitung Objekte Dateien, Datensätze, Felder, Hierarchien, Netzwerke, Beziehungen usw. sein können. Wenn nicht -Die numerische Verarbeitung interessiert direkt an Informationen über Objekte (z. B. einen bestimmten Mitarbeiter oder eine Gruppe von Mitarbeitern) und nicht an der Mitarbeiterakte selbst. Dadurch wird die Mitarbeiterdatei nicht indiziert, um eine bestimmte Person auszuwählen. Hier interessiert Sie eher der Inhalt des gesuchten Datensatzes. Riesige Informationsmengen werden in der Regel einer nicht-numerischen Verarbeitung unterzogen. In verschiedenen Anwendungen können Sie mit diesen Daten beispielsweise folgende Operationen durchführen:

Erhöhung der Gehälter für alle Mitarbeiter des Unternehmens;
Berechnen Sie die Bankzinsen auf den Konten aller Kunden.
Änderungen an der Liste aller vorrätigen Waren vornehmen;
Finden Sie die erforderliche Zusammenfassung aller in der Bibliothek oder im bibliografischen Informationsabfragesystem gespeicherten Texte.
eine Beschreibung des gewünschten Vertrags in einer Datei mit Rechtsdokumenten finden;
Überprüfen Sie alle Dateien mit Patentbeschreibungen und finden Sie ein Patent (falls vorhanden), das dem erneut vorgeschlagenen ähnelt.

Zur Implementierung einer Datenbankmaschine, parallel und assoziativ Architektur als Alternative zum Einzelprozessorvon NeumannStrukturen, die es Ihnen ermöglichen, mit großen Informationsmengen in Echtzeit zu arbeiten.

Datenbankmaschinen gewinnen aufgrund der Erforschung und Anwendung von Konzepten der künstlichen Intelligenz wie Wissensrepräsentation, Expertensystemen, Inferenz, Mustererkennung usw. zunehmend an Bedeutung.

Informationsspeicher. Heutzutage geben viele zu, dass die meisten Unternehmen bereits mehrere Datenbanken betreiben und für die erfolgreiche Arbeit mit Informationen nicht nur unterschiedliche Datenbanktypen, sondern auch unterschiedliche Generationen von DBMS benötigen. Laut Statistik verwendet jede Organisation durchschnittlich 2,5 verschiedene DBMS. Es ist offensichtlich geworden, dass das Geschäft von Unternehmen bzw. die an diesem Geschäft beteiligten Personen von den technologischen Merkmalen von Datenbanken „isoliert“ werden müssen, um Benutzern eine einheitliche Sicht auf Unternehmensinformationen zu ermöglichen, unabhängig davon, wo diese physisch gespeichert sind. Dies stimulierte die Entstehung der Informationsspeichertechnologie ( Data Warehousing, DW).

Das Hauptziel der DW ist Erstellen einer einheitlichen logischen Darstellung von Daten, die in verschiedenen Datenbanktypen enthalten sind, oder mit anderen Worten, eines einheitlichen Unternehmensdatenmodells.

Eine neue Runde der DW-Entwicklung wurde dank der Verbesserung der Informationstechnologie im Allgemeinen möglich, insbesondere durch das Aufkommen neuer Datenbanktypen, die auf der parallelen Abfrageverarbeitung basieren, die wiederum auf Fortschritten im Bereich der Parallelcomputer beruhte. Wurden erschaffen Abfrage-Buildermit einer intuitiven grafischen Oberfläche, die das Erstellen komplexer Datenbankabfragen erleichtert. Vielfalt an SoftwareMiddlewareKommunikation bereitgestelltzwischen verschiedenen Datenbanktypenund fiel schließlich stark im PreisSpeichergeräte.

Zur Struktur einer Kapitalgesellschaft kann eine Datenbank gehören.

Datenbank funktionale und organisatorische Komponente in automatisierte Systeme Verwaltungs- und Informations- und Computersysteme, die eine zentralisierte Informationsunterstützung für eine Gruppe von Benutzern oder eine Reihe von im System gelösten Aufgaben bereitstellen.

Datenbank gilt als Informations- und Referenzsystem, dessen Hauptzweck darin besteht:

in der Ansammlung und Aufrechterhaltung eines betriebsbereiten Zustands einer Reihe von Informationen, die die Informationsbasis des gesamten automatisierten Systems oder einer bestimmten Reihe von darin gelösten Aufgaben bilden;
bei der Bereitstellung der für die Aufgabe oder den Benutzer erforderlichen Daten;
bei der Gewährleistung des kollektiven Zugriffs auf gespeicherte Informationen;
bei der Sicherstellung der notwendigen Verwaltung der Nutzung der in der Informationsdatenbank enthaltenen Informationen.

Somit ist eine moderne Datenbank ein komplexer Software- und Hardwarekomplex, der technische, System- und Netzwerktools, Datenbanken und DBMS sowie Informationsabrufsysteme für verschiedene Zwecke umfasst.

V .2. DBMS UND STRUKTURLÖSUNGEN IN UNTERNEHMENSSYSTEMEN

Datenbank- und Wissensmanagementsysteme

Ein wichtiger Bestandteil moderner Informationssysteme sind Datenbankmanagementsysteme (DBMS).

DBMS eine Reihe von Software- und Sprachtools zum Erstellen, Verwalten und Verwenden von Datenbanken.

Ein Datenbankverwaltungssystem bietet Zugriff auf Datenbanken für Datenverarbeitungssysteme. Wie bereits erwähnt, spielen DBMS eine wichtige Rolle bei der Erstellung von Unternehmensinformationssystemen und insbesondere bei der Erstellung von Informationssystemen, die verteilte Informationsressourcen auf der Grundlage moderner Netzwerkcomputertechnologien nutzen.

Das Hauptmerkmal moderner DBMS besteht darin, dass moderne DBMS Technologien unterstützen wie:

Client/Server-Technologie.
Unterstützung für Datenbanksprachen. DasSchemadefinitionssprache DB (SDL – Schema Definition Language),Datenmanipulationssprache (DML – Data Manipulation Language), integrierte Sprachen SQL (Structured Queue Language), QDB (Query-By-Example) und QMF (Query Management Facility) ) Erweitertes Peripherietool zur Abfragespezifikation und Berichtserstellung für DB 2 usw.;
Direkte Datenverwaltung im externen Speicher.
RAM-Puffer verwalten.
Transaktionsmanagement. OLTP-Technologie (Online-Transaktionsverarbeitung), OLAP Technologie (Online-Analyseverarbeitung) für DW.
Stellen Sie Datenschutz und Integrität sicher. Die Nutzung des Systems ist ausschließlich datenzugriffsberechtigten Nutzern gestattet. Wenn Benutzer Operationen an Daten durchführen, bleibt die Konsistenz der gespeicherten Daten (Integrität) erhalten. Dies ist in unternehmensweiten Mehrbenutzer-Informationssystemen wichtig.
Tagebuch schreiben.

Moderne DBMS müssen sicherstellen, dass die oben aufgeführten Datenbankanforderungen erfüllt sind. Darüber hinaus müssen sie folgende Grundsätze erfüllen:

Datenunabhängigkeit.
Vielseitigkeit. Das DBMS muss über eine leistungsstarke konzeptionelle Datenmodellunterstützung für die Anzeige benutzerdefinierter logischer Ansichten verfügen.
Kompatibilität. Das DBMS muss betriebsbereit bleiben, während sich Software und Hardware weiterentwickeln.
Nichtredundanz der Daten. Im Gegensatz zu Dateisystemen muss eine Datenbank eine einzelne Sammlung integrierter Daten sein.
Datenschutz. Das DBMS muss Schutz vor unbefugtem Zugriff bieten.
Datenintegrität. Das DBMS muss verhindern, dass Benutzer die Datenbank verletzen.
Gleichzeitiges Arbeitsmanagement. Das DBMS muss die Datenbank vor Inkonsistenzen im Shared-Access-Modus schützen. Um einen konsistenten Datenbankstatus sicherzustellen, müssen alle Benutzeranfragen (Transaktionen) in einer bestimmten Reihenfolge ausgeführt werden.
Das DBMS muss universell sein. Es muss verschiedene Datenmodelle auf einer einzigen logischen und physischen Basis unterstützen.
Das DBMS muss sowohl zentralisierte als auch verteilte Datenbanken unterstützen und somit zu einem wichtigen Bindeglied in Computernetzwerken werden.

Betrachten Sie das DBMS als Klasse Softwareprodukte Bei der Ausrichtung auf die Pflege von Datenbanken in automatisierten Systemen können wir zwei wesentliche Merkmale unterscheiden, die die Typen von DBMS definieren. Ihnen zufolge kann ein DBMS aus zwei Blickwinkeln betrachtet werden:

ihre Fähigkeiten in Bezug auf verteilte (Unternehmens-)Datenbanken;
ihre Beziehung zum Typ des im DBMS implementierten Datenmodells.

Bezogen auf unternehmensweite (verteilte) Datenbanken lassen sich grob folgende DBMS-Typen unterscheiden:

Desktop-DBMS. Der Schwerpunkt dieser Produkte liegt vor allem auf der Arbeit mit personenbezogenen Daten (Desktop-Daten). Sie verfügen über Befehlssätze für die gemeinsame Nutzung gemeinsamer Datenbanken, sind jedoch klein (z. B. in einem kleinen Büro). Dies sind zunächst einmal DBMS wie Access, dBASE, Paradox, EcoxPro. Warum Access, dBASE, Paradox, EcoxPro keinen zufriedenstellenden Zugriff auf Unternehmensdaten haben. Tatsache ist, dass es keinen einfachen Weg gibt, die Barriere zwischen persönlichen und Unternehmensdaten zu überwinden. Dabei geht es nicht einmal darum, dass der Mechanismus des DBMS für personenbezogene Daten (oder eines kleinen Büros) auf den Zugriff auf Daten über viele Gateways, Internetwork-Produkte usw. ausgerichtet ist. Das Problem besteht darin, dass diese Mechanismen typischerweise vollständige Dateiübertragungen und keine umfassende Indexunterstützung beinhalten, was dazu führt, dass Serverwarteschlangen auf großen Systemen praktisch zum Stillstand kommen.
Spezialisiertes Hochleistungs-Mehrbenutzer-DBMS. Solche DBMS zeichnen sich durch das Vorhandensein eines Mehrbenutzer-Systemkerns, einer Datenmanipulationssprache und der folgenden Funktionen aus, die für entwickelte Mehrbenutzer-DBMS charakteristisch sind:
Organisation eines Pufferpools;
das Vorhandensein eines Transaktionswarteschlangenverarbeitungssystems;
das Vorhandensein von Mechanismen zur Datenblockierung für mehrere Benutzer;
Führen eines Transaktionsprotokolls;
das Vorhandensein von Zugangskontrollmechanismen.

Diese DBMS wie Oracle, DB2, SQL/Server, Informix, Sybase, ADABAS, Titanium und andere bieten eine breite Palette von Diensten für die Verarbeitung von Unternehmensdatenbanken.

Bei der Arbeit mit Datenbanken kommt ein Transaktionsmechanismus zum Einsatz.

Transaktion ist eine logische Arbeitseinheit.

Transaktion ist eine Folge von ausgeführten Datenmanipulationsoperatorenals ein Ganzes(Alles oder Nichts) und die Übersetzung der Datenbankvon einem Integralzustand in einen anderen Integralzustand.

Eine Transaktion verfügt über vier wichtige Eigenschaften, die als ACID-Eigenschaften bezeichnet werden:

(A) Atomarität . Eine Transaktion wird als atomare Operation ausgeführt – entweder wird die gesamte Transaktion ausgeführt oder die gesamte Transaktion wird nicht ausgeführt.
(C) Konsistenz. Eine Transaktion verschiebt die Datenbank von einem konsistenten (integralen) Zustand in einen anderen konsistenten (integrierten) Zustand. Innerhalb einer Transaktion kann die Datenbankkonsistenz zusammenbrechen.
(I) Isolierung . Transaktionen verschiedener Benutzer sollten sich nicht gegenseitig beeinträchtigen (z. B. so, als ob sie in strenger Reihenfolge ausgeführt würden).
(D) Haltbarkeit. Ist eine Transaktion abgeschlossen, müssen die Ergebnisse ihrer Arbeit in der Datenbank gespeichert werden, auch wenn das System im nächsten Moment abstürzt.

Die Transaktion startet normalerweise automatisch, wenn der Benutzer dem DBMS beitritt, und wird fortgesetzt, bis eines der folgenden Ereignisse eintritt:

Der Befehl COMMIT WORK wurde ausgegeben (Transaktion festschreiben).
Der Befehl ROLLBACK WORK wurde ausgegeben.
Der Benutzer wurde vom DBMS getrennt.
Es gab einen Fehler im System.

Für den Benutzer trägt es normalerweise Atomcharakter. Tatsächlich handelt es sich hierbei um einen komplexen Mechanismus der Interaktion zwischen Benutzer (Anwendung) und Datenbank. Unternehmenssystemsoftware verwendet einen Echtzeit-Tran(Online-Transaktionsverarbeitungssysteme, OLTP), insbesondere Buchhaltungsprogramme, Software zur Entgegennahme und Bearbeitung von Kundenanfragen, Finanzanwendungen, produzieren viele Informationen. Diese Systeme sind für die Bewältigung großer Datenmengen, komplexer Transaktionen und intensiver Lese-/Schreibvorgänge konzipiert (und entsprechend optimiert).

Leider sind die in den Datenbanken von OLTP-Systemen gespeicherten Informationen für die Verwendung durch normale Benutzer nicht sehr geeignet (aufgrund des hohen Normalisierungsgrads der Tabellen, spezifischer Datenpräsentationsformate und anderer Faktoren). Daher werden Daten von verschiedenen Informationsübermittlern gesendet (im Sinne von kopiert). Lagerhaus, Sortierung und anschließende Lieferung an den Verbraucher. In der Informationstechnologie spielen Lager die RolleInformationsspeicher.

Echtzeitanalytische Datenverarbeitungssysteme liefern Informationen an den Endbenutzer (Online-Analyseverarbeitung, OLAP), die einen außergewöhnlich einfachen Zugriff auf Daten durch praktische Möglichkeiten zum Generieren von Abfragen und Analysieren von Ergebnissen ermöglichen. In OLAP-Systemen erhöht sich der Wert eines Informationsprodukts durch den Einsatz verschiedener Analysemethoden und statistischer Verarbeitung. Darüber hinaus sind diese Systeme hinsichtlich der Geschwindigkeit des Datenabrufs und der Erfassung allgemeiner Informationen optimiert und richten sich an normale Benutzer (sie verfügen über eine intuitive Benutzeroberfläche). Wenn OLTP-System gibt Antworten auf einfache Fragen wie „Wie hoch war der Umsatz des Produkts N in der Region M im Januar 199x?“ OLAP-Systeme bereit für komplexere Benutzeranfragen, zum Beispiel: „Geben Sie eine Analyse der Verkäufe von Produkt N in allen Regionen gemäß Plan für das zweite Quartal im Vergleich zu den beiden Vorjahren.“

Client/Server-Architektur

In modernen Systemen verteilte Informationsverarbeitung, Technologie steht im Mittelpunkt Kundenserver. Im System Client-Server-ArchitekturDie Datenverarbeitung ist zwischen dem Client-Computer und dem Server-Computer aufgeteilt, die Kommunikation zwischen ihnen erfolgt über das Netzwerk. Diese Aufteilung der Datenverarbeitungsprozesse basiert auf der Gruppierung von Funktionen. Typischerweise ist ein Datenbankserver-Computer für die Ausführung von Datenbankoperationen vorgesehen, während ein Client-Computer Anwendungsprogramme ausführt. Abbildung 2.1 zeigt ein einfaches Client-Server-Architektursystem, das aus einem Computer besteht, der als Server fungiert, und einem anderen Computer, der als Client fungiert. Jede Maschine führt unterschiedliche Funktionen aus und verfügt über eigene Ressourcen.

		Datenbank
Servercomputer
Netz
IBM-kompatibler PC	IBM-kompatibler PC	IBM-kompatibler PC
		Anwendungen

Reis. 2.1. Client-Server-Architektursystem

Die Hauptfunktion des Client-Computers besteht darin, die Anwendung auszuführen (Benutzeroberfläche und Präsentationslogik) und bei Bedarf mit dem Server zu kommunizieren.

Server Hierbei handelt es sich um ein Objekt (Computer), das auf Anfrage Dienste für andere Objekte bereitstellt.

Wie der Begriff schon vermuten lässt, besteht die Hauptfunktion eines Servercomputers darin, die Bedürfnisse des Clients zu erfüllen. Mit dem Begriff „Server“ werden zwei verschiedene Funktionsgruppen bezeichnet: ein Dateiserver und ein Datenbankserver (im Folgenden sind unter diesen Begriffen je nach Kontext entweder Software gemeint, die diese Funktionsgruppen implementiert, oder Computer mit dieser Software). Dateiserver sind nicht für die Durchführung von Datenbankoperationen konzipiert; ihre Hauptfunktion besteht darin, Dateien zwischen mehreren Benutzern zu teilen, d. h. Gewährleistung des gleichzeitigen Zugriffs vieler Benutzer auf Dateien auf einem Computer – Dateiserver. Ein Beispiel für einen Dateiserver ist das NetWare-Betriebssystem von Novell. Der Datenbankserver kann auf einem Computer installiert und aktiviert werden – einem Dateiserver. Das Oracle DBMS in Form von NLM (Network Loadable Module) läuft in der NetWare-Umgebung auf einem Dateiserver.

Server lokales Netzwerk muss über Ressourcen verfügen, die seinem funktionalen Zweck und den Anforderungen des Netzwerks entsprechen. Beachten Sie, dass der Fokus auf dem Ansatz liegt offene Systeme, ist es richtiger, von logischen Servern zu sprechen (gemeint ist eine Reihe von Ressourcen und Software, die Dienste über diese Ressourcen bereitstellen), die sich nicht unbedingt auf ihnen befinden verschiedene Computer. Ein logischer Server in einem offenen System zeichnet sich dadurch aus, dass, wenn es aus Effizienzgründen ratsam ist, den Server auf einen separaten Computer zu verlagern, dies ohne die Notwendigkeit einer Änderung, weder an ihm selbst noch an der Anwendung, erfolgen kann Programme, die es verwenden.

Eine der wichtigen Anforderungen an den Server besteht darin, dass das Betriebssystem, auf dem sich der Datenbankserver befindet, Multitasking-fähig (und vorzugsweise, aber nicht unbedingt, Multiuser-fähig) sein muss. Beispielsweise kann ein Oracle DBMS, das auf einem PC mit einem MS-DOS- (oder PC-DOS-)Betriebssystem installiert ist, das die Multitasking-Anforderungen nicht erfüllt, nicht als Datenbankserver verwendet werden. Und dasselbe Oracle DBMS, das auf einem Computer mit einem Multitasking-Betriebssystem (wenn auch nicht für mehrere Benutzer) OS/2 installiert ist, kann ein Datenbankserver sein. Viele Arten von UNIX-Systemen, MVS, VM und einigen anderen Betriebssystemen sind sowohl Multitasking- als auch Multiuser-Systeme.

Verteiltes Rechnen

Der Begriff „verteiltes Rechnen“ wird häufig für zwei unterschiedliche, sich jedoch ergänzende Konzepte verwendet:

Verteilte Datenbank;
Verteilte Datenverarbeitung.

Die Anwendung dieser Konzepte ermöglicht es Endbenutzern, den Zugriff auf auf mehreren Computern gespeicherte Informationen mithilfe verschiedener Tools zu organisieren.

Es gibt viele Arten von Servern:

Datenbankserver;
Druck Server;
Fernzugriffsserver;
Faxserver;
Webserver usw.

Basierend auf der zugrunde liegenden Client/Server-Technologie Es gibt solche grundlegenden Technologien wie:

Betriebssystemtechnologien, das Konzept der Interaktion offener Systeme, die Schaffung objektorientierter Umgebungen für das Funktionieren von Programmen;
Telekommunikationstechnologien;
Netzwerktechnologien;
Grafische Benutzeroberflächentechnologien ( GUI);
Usw.

Vorteile der Client-Server-Technologie:

Die Client/Server-Technologie ermöglicht das Rechnen in heterogenen Computerumgebungen. Plattformunabhängigkeit: Greifen Sie auf heterogene Netzwerkumgebungen zu, die verschiedene Computertypen mit unterschiedlichen Betriebssystemen umfassen.
Unabhängigkeit von Datenquellen: Zugriff auf Informationen aus heterogenen Datenbanken. Beispiele für solche Systeme sind DB2, SQL/DS, Oracle, Sybase.
Lastausgleich zwischen Client und Server.
Führen Sie Berechnungen dort durch, wo sie am effizientesten stattfinden.
Bieten Sie die Möglichkeit, effektiv zu skalieren;
Plattformübergreifendes Computing. Unter Cross-Plattform-Computing versteht man einfach die Implementierung von Technologien in heterogenen Computerumgebungen. Hier muss gesorgt werden folgende Möglichkeiten:
Die Anwendung muss auf mehreren Plattformen laufen;
Es muss auf allen Plattformen über die gleiche Schnittstelle und Bedienlogik verfügen;
Die Anwendung muss in die native Betriebsumgebung integriert werden.
Es sollte sich auf allen Plattformen gleich verhalten;
Es sollte eine einfache und konsistente Unterstützung haben.

 Verteiltes Rechnen. Beim verteilten Rechnen geht es darum, die Arbeit auf mehrere Computer zu verteilen (obwohl verteiltes Rechnen ein umfassenderes Konzept ist).

 Disaggregation. Entbündelte Übertragung von Anwendungen für große Computer auf kleine Computerplattformen.

Reduzierte Infrastruktur- und Hardwarekosten. Kostengünstig: Die Verfügbarkeit kostengünstiger Computerausrüstung und die zunehmende Verbreitung lokaler Netzwerke machen die Client-Server-Technologie kostengünstiger als andere Datenverarbeitungstechnologien. Die Ausrüstung kann bei Bedarf aufgerüstet werden.

 Reduzierung der Gesamtausführungszeit der Anwendung;

 Reduzierung der Client-Speichernutzung;

 Reduzierung des Netzwerkverkehrs.

Fähigkeit, mit Multimedia zu arbeiten: Bisher wurden viele Multimedia-Programme für PCs erstellt. Entweder gibt es keine vergleichbaren Programme für die Terminal-Host-Konfiguration oder sie sind sehr teuer.
Möglichkeit, große Rechenressourcen für Datenbankoperationen anzuziehen: Da Anwendungen auf Client-Computern ausgeführt werden, setzt der Servercomputer zusätzliche Ressourcen (im Vergleich zur Terminal-Host-Konfiguration) für Datenbankoperationen frei, wie z. B. CPU-Rechenressourcen und Betriebsspeicher.
Erhöhte Produktivität der Programmierer: Die Produktivität der Programmierer steigt mit Tools wie SQL*Forms und CASE, mit denen Sie Anwendungen schneller entwickeln können als mit Programmiersprachen wie C, PL1 oder COBOL.
Erhöhte Endbenutzerproduktivität: Heutzutage beherrschen viele Endbenutzer Systeme wie Lotus, Paradox, Word Perfect, Harvard Graphics usw.

Die Backend-Schnittstelle ist definiert und festgelegt. Daher ist es möglich, neue Client-Teile eines bestehenden Systems zu erstellen (ein Beispiel für Interoperabilität auf Systemebene).

Reis. 2.2. Darstellung des Clientzugriffs auf eine vom Server freigegebene Ressource.

So implementieren Sie die Client-Server-Technologie

Im Folgenden wird die Installation eines Systems besprochen, das auf Client-Server-Technologie basiert und zur verteilten Datenverarbeitung fähig ist. Folgende Computerhardware und -software ist erforderlich:

Datenbankservercomputer;
Client-Computer;
Kommunikationsnetzwerk;
Netzwerksoftware;
Anwendungssoftware.

SQL-Sprache . Abfragesprache auf hoher Ebene - SQL (Structured Query Language). ) wird zur Implementierung von Abfragen an Datenbanken wie NMD, DML und PYAD verwendet und ist als Standard akzeptiert. Sprache SQL wurde ursprünglich als Datensprache für die Softwareprodukte des Unternehmens übernommen IBM und YaMD relationales DBMS SYSTEM R von IBM . Ein wichtiges Merkmal der Sprache SQL ist, dass dieselbe Sprache durch zwei verschiedene Schnittstellen dargestellt wird, nämlich durch eine interaktive Schnittstelle und durch eine An(dynamisch). SQL). Dynamisches SQL besteht aus vielen integrierten Sprachfunktionen SQL , speziell für die Gestaltung interaktiver Anwendungen vorgesehen, wo unten interaktive Anwendung bezieht sich auf ein Programm, das geschrieben wurde, um den Datenbankzugriff durch einen Endbenutzer zu unterstützen, der auf einem interaktiven Terminal ausgeführt wird. Sprache SQL Bietet die Funktionen zum Definieren, Bearbeiten und Verwalten von Datenbankdaten und ist für den Benutzer aus Sicht des implementierten DBMS transparent.

Reis. 2.3. Schema zum Ausführen von Benutzerabfragen an verteilte Datenbanken.

Die interne Struktur von Datenbanken wird durch die verwendeten Datenmodelle bestimmt. Das konzeptionelle Modell verfügt im Vergleich zu externen Modellen über größere Abstraktionsfähigkeiten und eine umfassendere Semantik. Externe Modelle werden oft als syntaktische oder operative Modelle bezeichnet und beziehen sich auf die syntaktische Natur der Steuerung und Anwendung als Mittel zur Benutzerinteraktion mit der Datenbank. Bei der Informationsmodellierung gibt es verschiedene Abstraktionsebenen, von der Ebene des konzeptionellen Modells bis zur Ebene des physischen Datenmodells, die sich auf die Architektur des DBMS auswirken.

Das Datenmodell besteht aus drei Komponenten:

Die Datenstruktur zur Darstellung der Datenbank aus Benutzersicht.
Gültige Vorgänge, die an der Datenstruktur ausgeführt werden. Es ist notwendig, mit dieser Struktur mithilfe verschiedener DML- und NMD-Operationen arbeiten zu können. Eine umfangreiche Struktur ist wertlos, wenn es keine Möglichkeit gibt, mit ihren Inhalten umzugehen.
Einschränkungen für die Integritätskontrolle. Das Datenmodell muss mit Mitteln ausgestattet sein, um seine Integrität zu wahren und zu schützen. Betrachten Sie als Beispiel die folgenden zwei Einschränkungen:
Jeder Teilbaum muss einen Quellknoten haben. Hierarchische Datenbanken können keine untergeordneten Knoten ohne den übergeordneten Knoten speichern.
In Bezug auf eine relationale Datenbank kann es keine identischen Tupel geben. Für eine Datei erfordert diese Anforderung, dass alle Datensätze eindeutig sind.

Eine der wichtigsten Eigenschaften eines DBMS ist die Fähigkeit, Objekte zu verknüpfen.

Es gibt folgende Arten von Verbindungen zwischen Objekten:

Eins-zu-eins (1:1). Ein Objekt einer Menge kann mit einem Objekt einer anderen Menge verknüpft werden.
Eins-zu-Viele (1:M). Ein Objekt einer Menge kann mit vielen Objekten einer anderen Menge verknüpft sein.
Viele-zu-Viele (M:N). Ein Objekt einer Menge kann mit vielen Objekten einer anderen Menge verknüpft sein, ein Objekt einer anderen Menge kann jedoch mit vielen Objekten der ersten Menge verknüpft sein.
Verzweigt . Ein Objekt einer Menge kann mit Objekten mehrerer Mengen verknüpft werden.
Rekursiv . Ein Objekt gegebener Satz kann durch ein Objekt derselben Menge verbunden werden.

Es gibt folgende grundlegende Datenmodelle:

Relationales Datenmodell.
Hierarchisches Datenmodell.
Unvollständiges Netzwerkdatenmodell.
CODASYL-Datenmodell.
Erweitertes Netzwerkdatenmodell.

V.3. INTERNET-/INTRANET-TECHNOLOGIEN UND UNTERNEHMENSLÖSUNGEN FÜR DEN DATENBANKZUGRIFF

Das Hauptproblem von Systemen, die auf einer Client-Server-Architektur basieren, besteht darin, dass sie gemäß dem Konzept offener Systeme in einer möglichst breiten Klasse offener System-Hardware- und Softwarelösungen mobil sein müssen. Auch wenn wir uns auf UNIX-basierte lokale Netzwerke beschränken, verwenden verschiedene Netzwerke unterschiedliche Hardware und Kommunikationsprotokolle. Versuche, Systeme zu schaffen, die alle möglichen Protokolle unterstützen, führen dazu, dass sie mit Netzwerkdetails überlastet werden, was zu Lasten der Funktionalität geht.

Ein noch komplexerer Aspekt dieses Problems ist mit der Möglichkeit verbunden, unterschiedliche Datendarstellungen in verschiedenen Knoten eines heterogenen lokalen Netzwerks zu verwenden. Unterschiedliche Computer können unterschiedliche Adressierung, Zahlendarstellung, Zeichenkodierung usw. haben. Dies ist besonders wichtig für High-Level-Server: Telekommunikation, Computer, Datenbanken.

Eine gängige Lösung für das Problem der Mobilität von Systemen, die auf einer Client-Server-Architektur basieren, besteht darin, sich auf Softwarepakete zu verlassen, die RPC-Protokolle (Remote Procedure Call) implementieren. Bei Verwendung solcher Tools sieht der Aufruf eines Dienstes auf einem Remote-Knoten wie ein normaler Prozeduraufruf aus. RPC-Tools, die natürlich alle Informationen über die Besonderheiten der lokalen Netzwerkausrüstung und Netzwerkprotokolle enthalten, übersetzen den Anruf in eine Abfolge von Netzwerkinteraktionen. Somit bleiben die Besonderheiten der Netzwerkumgebung und der Protokolle dem Anwendungsprogrammierer verborgen.

Wenn eine Remote-Prozedur aufgerufen wird, konvertieren RPC-Programme Client-Datenformate in maschinenunabhängige Zwischenformate und dann in Server-Datenformate. Bei der Übertragung von Antwortparametern werden ähnliche Transformationen durchgeführt.

Andere ähnliche Werke, die Sie interessieren könnten.vshm>
6914.		Datenbankkonzept	11,56 KB
	Eine Datenbank ist eine Sammlung unabhängiger Materialien, die in objektiver Form präsentiert werden, Berechnungsartikel zu normativen Rechtsakten von Gerichtsentscheidungen und anderen ähnlichen Materialien, die so systematisiert sind, dass diese Materialien mit einem elektronischen Computer des Bürgerlichen Gesetzbuches der Russischen Föderation gefunden und verarbeitet werden können Föderationskunst. Eine nach bestimmten Regeln organisierte und im Computerspeicher gespeicherte Datenbank ist ein Datensatz, der den aktuellen Zustand einiger ... charakterisiert.
8064.		Verteilte Datenbanken	43,66 KB
	Verteilte Datenbanken Unter einer verteilten Datenbank (RDB) versteht man einen Satz logisch miteinander verbundener gemeinsam genutzter Daten, die physisch über verschiedene Knoten eines Computernetzwerks verteilt sind. Der Zugriff auf Daten sollte nicht vom Vorhandensein oder Fehlen von Datenreplikaten abhängen. Das System muss automatisch Methoden zur Durchführung von Datenfusionsverbindungen ermitteln: einen Netzwerkkanal, der das Volumen der übertragenen Informationen bewältigen kann, und einen Knoten, der über ausreichende Rechenleistung zum Verbinden von Tabellen verfügt. Das RDBMS muss in der Lage sein...
20319.		Datenbanken und deren Schutz	102,86 KB
	Mitte der 1960er Jahre entstanden Online-Betriebsdatenbanken. Operationen an Betriebsdatenbanken wurden interaktiv über Terminals abgewickelt. Einfache indexsequentielle Datensatzorganisationen entwickelten sich schnell zu einem leistungsfähigeren satzorientierten Datensatzmodell. Charles Bachman erhielt den Turing Award für seine Leitung der Data Base Task Group (DBTG), die eine Standardsprache zur Beschreibung und Bearbeitung von Daten entwickelte.
5031.		Datenbankentwicklungsbibliothek	11,72 MB
	Datenbankdesigntechnologie. Definieren Sie Beziehungen zwischen Entitäten und erstellen Sie ein Datenmodell. Die Hauptideen der modernen Informationstechnologie basieren auf dem Konzept, dass Daten in Datenbanken organisiert werden sollten, um die sich verändernde reale Welt angemessen abzubilden und den Informationsbedürfnissen der Benutzer gerecht zu werden. Diese Datenbanken werden von speziellen Softwaresystemen namens DBMS-Datenbankverwaltungssystemen erstellt und betrieben.
13815.		HIERARCHISCHES DATENBANKMODELL	81,62 KB
	Die Grundideen der modernen Informationstechnologie basieren auf dem Konzept der Datenbanken, wonach die Grundlage der Informationstechnologie in Datenbanken organisierte Daten sind, die den Stand eines bestimmten Fachgebiets angemessen widerspiegeln und dem Benutzer aktuelle Informationen liefern diesem Themengebiet. Es ist notwendig, die Tatsache zu erkennen, dass Daten...
14095.		Entwicklung einer Bibliotheksdatenbank	11,72 MB
	Die Zunahme des Umfangs und der strukturellen Komplexität der gespeicherten Daten sowie die Erweiterung des Nutzerkreises von Informationssystemen haben zu einer weit verbreiteten Verwendung des bequemsten und relativ leicht verständlichen relationalen (tabellarischen) DBMS geführt.
5061.		Erstellung einer Klinikdatenbank	2,4 MB
	Die Entwicklung der Computertechnologie und Informationstechnologie hat Möglichkeiten für die Schaffung und weit verbreitete Nutzung automatisierter Informationssysteme (AIS) für verschiedene Zwecke eröffnet. Informationssysteme zur Verwaltung wirtschaftlicher und technischer Anlagen werden entwickelt und implementiert
13542.		Geologische Informationsdatenbanken	20,73 KB
	In jüngster Zeit werden Computertechnologien und insbesondere Datenbanken in rasantem Tempo in den wissenschaftlichen Bereich eingeführt. Dieser Prozess geht nicht an der Geologie vorbei, da gerade in den Naturwissenschaften die Notwendigkeit besteht, große Informationsmengen zu speichern und zu verarbeiten.
9100.		Datenbank. Grundlegendes Konzept	26,28 KB
	Eine Datenbank ist eine Sammlung von Informationen über bestimmte Objekte der realen Welt in einem beliebigen Fachgebiet, Wirtschaft, Management, Chemie usw. Der Zweck eines Informationssystems besteht nicht nur darin, Daten über Objekte zu speichern, sondern diese Daten auch zu manipulieren und zu erfassen Berücksichtigen Sie die Verbindungen zwischen Objekten. Jedes Objekt ist durch einen Satz von Dateneigenschaften gekennzeichnet, die in der Datenbank als Attribute bezeichnet werden.
5240.		Aufbau der Datenbank „Universitätsdekanat“.	1,57 MB
	Eine Datenbank (DB) ist eine Sammlung miteinander verbundener Daten, die gemeinsam auf externen Computerspeichermedien gespeichert sind und deren Organisation und minimale Redundanz eine optimale Nutzung für eine oder mehrere Anwendungen ermöglichen

Zweck der Vorlesung

Nachdem Sie den Stoff dieser Vorlesung studiert haben, wissen Sie:

was Unternehmensdatenmodell ;
wie man konvertiert Unternehmensdatenmodell zum Data-Warehouse-Modell;
wesentliche Elemente Unternehmensdatenmodell ;
Darstellungsebenen des Unternehmensdatenmodells ;
Algorithmus zur Konvertierung eines Unternehmensdatenmodells in ein mehrdimensionales Data-Warehouse-Modell ;

und lernen:

Entwickeln Sie Data-Warehouse-Modelle basierend auf Unternehmensdatenmodell Organisationen;
Entwickeln Sie ein Sternschema mit CASE-Tools.
Partitionstabellen mehrdimensionales Modell mit CASE-Tools.

Unternehmensdatenmodell

Einführung

Der Kern eines jeden Data Warehouse ist sein Datenmodell. Ohne ein Datenmodell wird es sehr schwierig sein, Daten in einem Data Warehouse zu organisieren. Daher müssen HD-Entwickler Zeit und Mühe in die Entwicklung eines solchen Modells investieren. Die Entwicklung des HD-Modells liegt auf den Schultern des HD-Designers.

Im Vergleich zum Design von OLTP-Systemen weist die Data-Warehouse-Designmethodik eine Reihe von Besonderheiten im Zusammenhang mit der Ausrichtung von Speicherdatenstrukturen auf die Lösung von Analyseproblemen und Informationsunterstützung für den Entscheidungsprozess auf. Das Datenmodell des Data Warehouse muss genau für diese Probleme eine effektive Lösung bieten.

Der Ausgangspunkt beim Entwurf eines Data Warehouse kann das sogenannte sein Unternehmensdatenmodell(Corporate Data Model oder Enterprise Data Model, EDM), das während des Designprozesses der OLTP-Systeme einer Organisation erstellt wird. Beim Entwerfen Unternehmensdatenmodell Normalerweise wird versucht, auf der Grundlage von Geschäftstransaktionen eine Datenstruktur zu erstellen, die alle Informationsbedürfnisse der Organisation sammelt und zusammenfasst.

Auf diese Weise, Unternehmensdatenmodell enthält die notwendigen Informationen zum Erstellen eines Data Warehouse-Modells. Wenn daher in der ersten Phase ein solches Modell in der Organisation vorhanden ist, Ein Data-Warehouse-Designer kann mit dem Entwurf eines Data-Warehouse beginnen, indem er das Transformationsproblem löst Unternehmensdatenmodell zum HD-Modell.

Unternehmensdatenmodell

So lösen Sie das Transformationsproblem Unternehmensdatenmodell zum HD-Modell? Um dieses Problem zu lösen, benötigen Sie dieses Modell, d. h. Unternehmensdatenmodell muss gebaut werden und dokumentiert. Und Sie müssen es verstehen Was von diesem Modell und Wie sollte in ein Datenspeichermodell umgewandelt werden.

Lassen Sie uns das Konzept aus der Sicht eines HD-Designers erläutern Unternehmensdatenmodell. Unter Unternehmensdatenmodell eine mehrstufige, strukturierte Beschreibung der Fachgebiete der Organisation, Fachgebietsdatenstrukturen, Geschäftsprozesse und Geschäftsabläufe, in der Organisation akzeptierte Datenflüsse, Zustandsdiagramme, Datenprozessmatrizen und andere Modelldarstellungen verstehen, die in den Aktivitäten der Organisation verwendet werden . Im weitesten Sinne des Wortes Unternehmensdatenmodell ist eine Reihe von Modellen auf verschiedenen Ebenen, die die Aktivitäten einer Organisation charakterisieren (Modell auf einer abstrakten Ebene), d. h. Inhalt Unternehmensmodell hängt direkt davon ab, welche Modellstrukturen in einer bestimmten Organisation darin enthalten waren.

Hauptelemente Unternehmensdatenmodell Sind:

Beschreibung der Fachgebiete der Organisation (Definition der Tätigkeitsbereiche);
Beziehungen zwischen den oben definierten Themenbereichen;
Informationsdatenmodell (ERD-Modell oder Entity-Relationship-Modell);
für jede Themenbereichsbeschreibung:
- Entitätsschlüssel;
- Entitätsattribute;
- Subtypen und Supertypen;
- Verbindungen zwischen Entitäten;
- Attributgruppierungen;
- Beziehungen zwischen Fachgebieten;
Funktionsmodell oder Geschäftsprozessmodell;
Datenflussdiagramme;
Zustandsdiagramme;
andere Modelle.

Auf diese Weise, Unternehmensdatenmodell enthält Entitäten, Attribute und Beziehungen, die den Informationsbedarf einer Organisation darstellen. In Abb. 16.1 zeigt die Hauptelemente Unternehmensdatenmodell.

Darstellungsebenen des Unternehmensdatenmodells

Das Unternehmensdatenmodell ist nach Themenbereichen unterteilt, die Gruppen von Entitäten darstellen, die für die Unterstützung spezifischer Geschäftsanforderungen relevant sind. Einige Themenbereiche decken möglicherweise bestimmte Geschäftsfunktionen wie Vertragsmanagement ab, während andere möglicherweise Einheiten umfassen, die Produkte oder Dienstleistungen beschreiben.

Jedes logische Modell muss einer vorhandenen Problemdomäne entsprechen Unternehmensdatenmodell. Erfüllt das logische Modell diese Anforderung nicht, muss ein domänendefinierendes Modell hinzugefügt werden.

Ein Unternehmensdatenmodell verfügt typischerweise über mehrere Darstellungsebenen. Eigentlich hohes Level(hohes Level) Unternehmensdatenmodell Es erfolgt eine Beschreibung der Hauptthemenbereiche der Organisation und ihrer Beziehungen auf Entitätsebene. In Abb. 16.2 zeigt ein Fragment Unternehmensdatenmodell Höchststufe.

Reis. 16.2.

Das in der Abbildung dargestellte Diagramm zeigt vier Themenbereiche: „Käufer“ ( Kunde), "Überprüfen" ( Konto), "Befehl" ( Befehl) und „Produkt“ ( Produkt). Typischerweise geben Modellansichten auf der obersten Ebene nur Angaben an direkte Verbindungen zwischen Themenbereichen, die beispielsweise folgenden Sachverhalt festhalten: Der Käufer bezahlt eine Rechnung für die Bestellung von Waren. Detaillierte Informationen und indirekte Beziehungen auf dieser Ebene Unternehmensmodell sind nicht gegeben.

Beim nächsten Durchschnittsniveau(Mittlere Stufe) Unternehmensdatenmodell Zeigt detaillierte Informationen zu Domänenobjekten an, d. h. Schlüssel und Entitätsattribute, ihre Beziehungen, Subtypen und Supertypen usw. Für jede Domäne des Top-Level-Modells gibt es ein Middle-Level-Modell. In Abb. Abbildung 16.3 zeigt das durchschnittliche Präsentationsniveau Unternehmensmodell für ein Fragment des Themenbereichs „Bestellung“.

Aus Abb. 16.3 können Sie sehen, dass der Themenbereich „Bestellung“ ( Befehl) umfasst mehrere Entitäten, die durch ihre Attribute und die Beziehungen zwischen ihnen definiert werden. Mit dem vorgestellten Modell können Sie Fragen wie das Datum der Bestellung, wer die Bestellung aufgegeben hat, wer die Bestellung gesendet hat, wer die Bestellung erhalten hat und viele andere beantworten. Aus dem obigen Diagramm geht hervor, dass es in dieser Organisation zwei Arten von Aufträgen gibt – Aufträge für eine Werbeaktion ( Kommerziell) und Einzelhandelsbestellungen ( Einzelhandel).

beachte das Unternehmensdatenmodell können verschiedene Aspekte der Aktivitäten einer Organisation mit unterschiedlichem Detaillierungsgrad und Vollständigkeit darstellen. Wenn Unternehmensmodell repräsentiert alle Aspekte der Aktivitäten der Organisation, es wird auch genannt Organisationsdatenmodell(Unternehmensdatenmodell).

Aus der Sicht des Entwurfs eines Data Warehouse ein wichtiger Faktor bei der Entscheidung, ein Modell eines Data Warehouse zu erstellen Unternehmensdatenmodell ist der Staat Vollständigkeit Unternehmensdatenmodell.

Das Unternehmensdatenmodell einer Organisation weist die Eigenschaft der Evolution auf, d. h. es entwickelt sich ständig weiter und verbessert sich. Einige Themenbereiche Unternehmensdatenmodell vielleicht schon gut ausgearbeitet, für manche hat die Arbeit vielleicht noch nicht begonnen. Wenn ein Teil des Themengebiets nicht ausgearbeitet ist Unternehmensdatenmodell, dann ist es nicht möglich, dieses Modell als Ausgangspunkt für den Entwurf eines Data Warehouse zu verwenden.

Abschlussgrad Unternehmensmodell können bei der Gestaltung der Lagereinrichtung wie folgt ausgeglichen werden. Da der Prozess der Entwicklung eines Data Warehouse in der Regel zeitlich in eine Abfolge von Phasen unterteilt ist, kann der Prozess seines Entwurfs mit synchronisiert werden Abschlussprozess Entwicklung einzelner Fragmente Unternehmensdatenmodell Organisationen.

Am niedrigsten Darstellungsebene des Unternehmensdatenmodells Zeigt Informationen über die physischen Eigenschaften der entsprechenden Datenbankobjekte an logisches Datenmodell Durchschnitt Darstellungsschicht des Unternehmensdatenmodells.

IT-Experten richten ihre Aufmerksamkeit zunehmend auf Datenmanagementlösungen, die auf branchenüblichen Datenmodellen und Geschäftsentscheidungsvorlagen basieren. Mithilfe der herunterladbaren komplexen physischen Datenmodelle und Geschäftsanalyseberichte für bestimmte Tätigkeitsbereiche können Sie die Informationskomponente der Aktivitäten eines Unternehmens vereinheitlichen und die Ausführung von Geschäftsprozessen erheblich beschleunigen. Lösungsvorlagen ermöglichen es Dienstanbietern, die Leistungsfähigkeit nicht standardmäßiger Informationen zu nutzen, die in vorhandenen Systemen verborgen sind, und so Projektlaufzeiten, Kosten und Risiken zu reduzieren. Beispielsweise zeigen reale Projekte, dass Datenmodell- und Geschäftsentscheidungsvorlagen den Entwicklungsaufwand um 50 % reduzieren können.

Ein Branchenlogikmodell ist eine domänenspezifische, integrierte und logisch strukturierte Darstellung aller Informationen, die in einem Unternehmens-Data-Warehouse vorhanden sein müssen, um sowohl strategische als auch taktische Geschäftsfragen zu beantworten. Der Hauptzweck von Modellen besteht darin, die Orientierung im Datenraum zu erleichtern und bei der Identifizierung von Details zu helfen, die für die Geschäftsentwicklung wichtig sind. Um ein Unternehmen erfolgreich zu führen, ist es unter modernen Bedingungen unbedingt erforderlich, ein klares Verständnis der Zusammenhänge zwischen verschiedenen Komponenten und ein gutes Verständnis des Gesamtbildes der Organisation zu haben. Die Identifizierung aller Details und Zusammenhänge anhand von Modellen ermöglicht die effizienteste Nutzung von Zeit und Werkzeugen zur Organisation der Unternehmensarbeit.

Ein Beispiel für das Modell „GIS für Regierung und Kommunalverwaltung“.

Heutzutage ist es für Software- und Serviceanbieter von strategischer Bedeutung, schnell auf Veränderungen in der Branche reagieren zu können, die mit technologischen Innovationen, der Aufhebung staatlicher Beschränkungen und der Komplexität der Lieferketten einhergehen. Mit den Veränderungen im Geschäftsmodell steigen auch die Komplexität und die Kosten der Informationstechnologien, die zur Unterstützung der Unternehmensaktivitäten erforderlich sind. Besonders schwierig ist die Datenverwaltung in einem Umfeld, in dem sich die Informationssysteme von Unternehmen sowie die funktionalen und geschäftlichen Anforderungen an sie ständig ändern.

Branchendatenmodelle sollen dabei helfen, diesen Prozess zu erleichtern, zu optimieren und den IT-Ansatz auf ein modernes Niveau zu bringen.

Branchendatenmodelle des UnternehmensEsri

Datenmodelle für die Esri ArcGIS-Plattform bieten Arbeitsvorlagen für den Einsatz in GIS-Projekten und die Erstellung von Datenstrukturen für verschiedene Anwendungsbereiche. Zum Erstellen eines Datenmodells gehört die Erstellung eines Konzeptentwurfs, einer logischen Struktur und einer physischen Struktur, die dann zum Aufbau einer persönlichen oder Unternehmens-Geodatenbank verwendet werden können. ArcGIS stellt Werkzeuge zum Erstellen und Verwalten Ihres Datenbankschemas bereit, und es werden Datenmodellvorlagen verwendet Schnellstart GIS-Projekte für verschiedene Anwendungen und Branchen. Esri und die Benutzergemeinschaft haben viel Zeit in die Entwicklung einer Reihe von Vorlagen investiert, die einen schnellen Einstieg in das Design von Enterprise-Geodatabases ermöglichen. Diese Projekte werden unter support.esri.com/datamodels beschrieben und dokumentiert. Nachfolgend finden Sie in der Reihenfolge, in der sie auf dieser Website erwähnt werden, die semantische Übersetzung der Namen der Esri-Branchenmodelle:

Adressregister
Landwirtschaft
Meteorologie
Grundlegende räumliche Daten
Biodiversität
Innenraum von Gebäuden
Treibhausgasbilanzierung
Verwaltungsgrenzen wahren
Bewaffnete Kräfte. Nachrichtendienst
Energie (einschließlich des neuen ArcGIS MultiSpeak-Protokolls)
Ökologische Strukturen
Ministerium für Notsituationen. Brandschutz
Waldkataster
Forstwirtschaft
Geologie
Nationales GIS (e-gov)
Grundwasser und Abwasser
Gesundheitspflege
Archäologie und Denkmalschutz
nationale Sicherheit
Hydrologie
Internationale Hydrographische Organisation (IHO). S-57-Format für ENC
Bewässerung
Grundbuch
Kommunalverwaltung
Meeresnavigation
Staatskataster
Öl- und Gasstrukturen
Pipelines
Rasterspeicher
Bathymetrie, Meeresbodentopographie
Telekommunikation
Transport
Wasserversorgung, Kanalisation, Wohnungsbau und kommunale Dienstleistungen

Diese Modelle enthalten alle notwendigen Funktionen des Industriestandards, nämlich:

sind frei verfügbar;
sind nicht an die Technologie des „ausgewählten“ Herstellers gebunden;
entstanden als Ergebnis der Umsetzung realer Projekte;
erstellt unter Beteiligung von Branchenexperten;
Entwickelt, um die Informationsinteraktion zwischen verschiedenen Produkten und Technologien sicherzustellen;
nicht im Widerspruch zu anderen Standards und Regulierungsdokumenten stehen;
wird in abgeschlossenen Projekten auf der ganzen Welt verwendet;
sind so konzipiert, dass sie während des gesamten Lebenszyklus des zu erstellenden Systems mit Informationen arbeiten und nicht mit dem Projekt selbst;
erweiterbar, um den Kundenbedürfnissen gerecht zu werden, ohne dass die Kompatibilität mit anderen Projekten und/oder Modellen verloren geht;
begleitet von zusätzlichen Materialien und Beispielen;
Verwendung in Richtlinien und technischen Materialien verschiedener Industrieunternehmen;
eine große Teilnehmergemeinschaft, deren Zugang allen offen steht;
zahlreiche Verweise auf Datenmodelle in Veröffentlichungen der letzten Jahre.

Esri-Experten sind Teil eines Expertengremiums unabhängiger Gremien, die verschiedene Branchenmodelle zur Verwendung empfehlen, wie z. B. PODS (Pipeline Open Data Standards – ein offener Standard für die Öl- und Gasindustrie; derzeit gibt es eine Implementierung von PODS als Geodatenbank Esri PODS Esri Spatial 5.1.1) oder Geodatabase (GD) von ArcGIS for Aviation, die ICAO- und FAA-Empfehlungen sowie den NAIXM 5.0 berücksichtigt. Darüber hinaus gibt es empfohlene Modelle, die sich strikt an bestehende Industriestandards halten, wie z. B. S-57 und ArcGIS for Maritime (Marine und Küste), sowie Modelle, die auf der Grundlage der Arbeit von Esri Professional Services erstellt wurden und die „De-facto“-Standards sind in ihren jeweiligen Fachgebieten. Beispielsweise haben GIS für das Land und die Kommunalverwaltung die NSDI- und INSPIRE-Standards beeinflusst, und Wasser und Grundwasser werden in ArcHydros frei verfügbaren professionellen Paketen und kommerziellen Produkten von Drittanbietern umfassend verwendet. Es ist zu beachten, dass Esri auch „De-facto“-Standards wie NHDI unterstützt. Alle vorgeschlagenen Datenmodelle sind dokumentiert und können in den IT-Prozessen des Unternehmens verwendet werden. Zu den Begleitmaterialien zu den Modellen gehören:

UML-Entitätsbeziehungsdiagramme;
Datenstrukturen, Domänen, Verzeichnisse;
vorgefertigte Geodatenbank-Vorlagen im ArcGIS GDB-Format;
Beispieldaten und Beispielanwendungen;
Beispiele für Skripte zum Laden von Daten, Beispiele für Analyse-Dienstprogramme;
Nachschlagewerke zur vorgeschlagenen Datenstruktur.

Esri fasst seine Erfahrungen beim Aufbau von Branchenmodellen in Büchern zusammen und lokalisiert die veröffentlichten Materialien. Esri CIS hat die folgenden Bücher lokalisiert und veröffentlicht:

Geodatendienstorientierte Architektur (SOA);
Entwurf von Geodatenbanken für den Transport;
Geografische Informationssysteme für Unternehmen;
GIS: Neue Energie von Strom- und Gasunternehmen;
Öl und Gas auf einer digitalen Karte;
Modellierung unserer Welt. Esri Geodatabase Design Guide;
Denken Sie über GIS nach. GIS-Planung: Ein Leitfaden für Manager;
Geografisches Informationssystem. Grundlagen;
GIS für Verwaltungs- und Wirtschaftsmanagement;
Web-GIS. Grundsätze und Anwendung;
Systems Design Strategies, 26. Auflage;
68 Ausgaben des ArcReview-Magazins mit Veröffentlichungen von Unternehmen und Anwendern von GIS-Systemen;
... und viele weitere thematische Notizen und Veröffentlichungen.

Zum Beispiel das Buch Unsere Welt modellieren..." (Übersetzung) ist ein umfassender Leitfaden und eine Referenz für die Datenmodellierung in GIS im Allgemeinen und Geodatenbank-Datenmodelle im Besonderen. Das Buch zeigt, wie man die richtigen Datenmodellierungsentscheidungen entwickelt, Entscheidungen, die in jeden Aspekt eines GIS-Projekts einfließen Datenbankdesign über Daten und Datenerfassung bis hin zu räumlicher Analyse und Visualisierung. Beschreibt im Detail, wie man eine für ein Projekt geeignete geografische Datenbank entwirft, Datenbankfunktionen ohne Programmierung konfiguriert, Arbeitsabläufe in komplexen Projekten verwaltet, eine Vielzahl von Netzwerkstrukturen wie Flüsse modelliert, Transport- oder Stromnetze, integrieren Weltraumvermessungsdaten in den Prozess der geografischen Analyse und Anzeige sowie erstellen 3D-Modelle von GIS-Daten. Buch " Entwerfen von Geodatenbanken für den Transport„Enthält methodische Ansätze, die in einer Vielzahl von Projekten getestet wurden und den gesetzlichen Anforderungen Europas und der USA sowie internationalen Standards vollständig entsprechen. Und im Buch „ GIS: Neue Energie von Strom- und Gasunternehmen„Veranschaulicht anhand realer Beispiele die Vorteile, die ein Unternehmens-GIS einem Energieversorger bringen kann, einschließlich Aspekten wie Kundenservice, Netzwerkbetrieb und anderen Geschäftsprozessen.

Einige der Bücher, übersetzt und im Original, wurden auf Russisch von Esri CIS und DATA+ veröffentlicht. Sie befassen sich sowohl mit konzeptionellen Fragen im Zusammenhang mit der GIS-Technologie als auch mit vielen angewandten Aspekten der Modellierung und Bereitstellung von GIS in verschiedenen Maßstäben und für verschiedene Zwecke.

Betrachten wir den Einsatz von Branchenmodellen am Beispiel des BISDM (Building Interior Space Data Model, Informationsmodell des Innenraums eines Gebäudes) Version 3.0. BISDM ist eine Weiterentwicklung des allgemeineren BIM-Modells (Building Information Model) und ist für den Einsatz bei der Planung, dem Bau, dem Betrieb und der Stilllegung von Gebäuden und Bauwerken vorgesehen. Durch die Verwendung in GIS-Software können Sie Geodaten effektiv mit anderen Plattformen austauschen und mit ihnen interagieren. Gehört zur allgemeinen Gruppe der FM-Aufgaben (Organisational Infrastructure Management). Lassen Sie uns die Hauptvorteile des BISDM-Modells auflisten, dessen Verwendung Folgendes ermöglicht:

den Informationsaustausch in einem heterogenen Umfeld nach einheitlichen Regeln organisieren;
eine „physische“ Verkörperung des BIM-Konzepts und empfohlene Regeln für das Bauprojektmanagement erhalten;
Pflege eines einzigen Repositorys mithilfe von GIS während des gesamten Lebenszyklus eines Gebäudes (vom Entwurf bis zur Stilllegung);
koordinieren Sie die Arbeit verschiedener Spezialisten im Projekt;
Visualisieren Sie den festgelegten Zeitplan und die Bauphasen für alle Teilnehmer.
Geben Sie eine vorläufige Schätzung der Kosten und der Bauzeit ab (4D- und 5D-Daten);
den Fortschritt des Projekts überwachen;
Gewährleistung eines qualitativ hochwertigen Betriebs des Gebäudes, einschließlich Wartung und Reparaturen;
Werden Sie Teil des Asset-Management-Systems, einschließlich Funktionen zur Analyse der Effizienz der Flächennutzung (Vermietung, Lagerflächen, Mitarbeiterverwaltung);
Berechnungen durchführen und Aufgaben zur Gebäudeenergieeffizienz verwalten;
simulieren die Bewegung menschlicher Ströme.

BISDM definiert die Regeln für die Arbeit mit räumlichen Daten auf der Ebene interner Räumlichkeiten in einem Gebäude, einschließlich des Zwecks und der Nutzungsarten, der verlegten Kommunikation, der installierten Ausrüstung, der Abrechnung von Reparaturen und Wartungsarbeiten, der Protokollierung von Vorfällen und der Beziehungen zu anderen Vermögenswerten des Unternehmens. Das Modell hilft bei der Erstellung eines einheitlichen Repositorys für geografische und nicht geografische Daten. Die Erfahrung weltweit führender Unternehmen wurde genutzt, um Einheiten zu identifizieren und auf Geodatenbankebene die räumlichen und logischen Beziehungen aller physischen Elemente zu modellieren, die sowohl das Gebäude selbst als auch sein Inneres bilden. Das Befolgen der Prinzipien von BISDM kann die Aufgaben der Integration mit anderen Systemen erheblich vereinfachen. Der erste Schritt ist in der Regel die CAD-Integration. Während des Betriebs des Gebäudes kommt dann der Datenaustausch mit ERP- und EAM-Systemen (SAP, TRIRIGA, Maximo etc.) zum Einsatz.

Visualisierung von BISDM-Strukturelementen mithilfe von ArcGIS.

Im Falle der Nutzung von BISDM erhält der Kunde/Eigentümer der Anlage einen durchgängigen Informationsaustausch von der Idee zur Errichtung der Anlage bis zur Entwicklung eines kompletten Projekts, der Bauüberwachung mit Erhalt von Aktualisierungen. aktuelle Informationen bis zur Inbetriebnahme der Anlage, Kontrolle der Parameter während des Betriebs und sogar während des Umbaus oder der Stilllegung der Anlage. Dem BISDM-Paradigma folgend werden GIS und die mit seiner Hilfe erstellte Geodatenbank zu einem gemeinsamen Datenspeicher für verwandte Systeme. Häufig enthält die Geodatenbank Daten, die von Drittsystemen erstellt und verwaltet werden. Dies muss bei der Gestaltung der Architektur des zu erstellenden Systems berücksichtigt werden.

Ab einem bestimmten Punkt ermöglicht Ihnen die angesammelte „kritische Masse“ an Informationen, auf ein neues qualitatives Niveau zu gelangen. Nach Abschluss der Entwurfsphase eines neuen Gebäudes ist es beispielsweise in GIS möglich, automatisch Übersichts-3D-Modelle zu visualisieren, eine Liste der installierten Geräte zu erstellen, die Kilometer der installierten Versorgungsnetze zu berechnen, eine Reihe von Überprüfungen durchzuführen und sogar eine zu erstellen vorläufige finanzielle Einschätzung der Projektkosten.

Wir möchten noch einmal darauf hinweisen, dass es bei der gemeinsamen Verwendung von BISDM und ArcGIS möglich wird, anhand der gesammelten Daten automatisch 3D-Modelle zu erstellen, da die Geodatenbank eine vollständige Beschreibung des Objekts enthält, einschließlich Z-Koordinaten, Zugehörigkeit zum Boden und Verbindungstypen der Elemente, Methoden zur Installation der Ausrüstung, Material, zugängliche Wege, Bewegung des Personals, funktionaler Zweck jedes Elements usw. usw. Es ist zu berücksichtigen, dass nach dem ersten Import aller Entwurfsmaterialien in die BISDM-Geodatenbank ein Bedarf an zusätzlichen Informationsinhalten besteht für:

Platzieren von 3D-Modellen von Objekten und Geräten an bestimmten Orten;
Sammeln von Informationen über die Materialkosten und das Verfahren für deren Verlegung und Installation;
Verkehrskontrolle basierend auf den Abmessungen der installierten nicht standardmäßigen Ausrüstung.

Die Verwendung von ArcGIS vereinfacht den Import zusätzlicher 3D-Objekte und Nachschlagewerke aus externen Quellen, weil Mit dem ArcGIS Data Interoperability-Modul können Sie Verfahren zum Importieren solcher Daten und deren korrekte Platzierung im Modell erstellen. Alle in der Branche verwendeten Formate werden unterstützt, einschließlich IFC, AutoCAD Revit und Bentlye Microstation.

Branchendatenmodelle von IBM

IBM bietet eine Reihe von Speicherverwaltungstools und -modellen für verschiedene Tätigkeitsbereiche:

IBM Banking and Financial Markets Data Warehouse (Finanzen)
IBM Banking Data Warehouse
IBM Bankprozess- und Servicemodelle
IBM Health Plan-Datenmodell (Gesundheitswesen)
IBM Insurance Information Warehouse (Versicherung)
IBM Versicherungsprozess- und Servicemodelle
IBM Retail Data Warehouse (Einzelhandel)
IBM Telecommunications Data Warehouse (Telekommunikation)
InfoSphere Warehouse-Paket:
- für Customer Insight (um Kunden zu verstehen)
- für Market and Campaign Insight (um das Unternehmen und den Markt zu verstehen)
- für Supply Chain Insight (um Lieferanten zu verstehen).

Zum Beispiel Modell IBMBankwesenUndFinanziellMärkteDatenLager ist darauf ausgelegt, spezifische Probleme der Bankenbranche aus Datensicht zu lösen IBMBankwesenVerfahrenUndServiceModelle- aus Sicht der Prozesse und SOA (serviceorientierte Architektur). Vorgestellte Modelle für die Telekommunikationsbranche IBMInformationFrameWork (IFW) Und IBMTelekommunikationDatenLager (TDW). Sie tragen dazu bei, den Prozess der Erstellung analytischer Systeme erheblich zu beschleunigen und die Risiken zu reduzieren, die mit der Entwicklung von Geschäftsanalyseanwendungen, der Verwaltung von Unternehmensdaten und der Organisation von Data Warehouses unter Berücksichtigung der Besonderheiten der Telekommunikationsbranche verbunden sind. Die Fähigkeiten von IBM TDW decken das gesamte Spektrum des Telekommab – von Internetanbietern und Kabelnetzbetreibern, die drahtgebundene und drahtlose Telefondienste, Datenübertragung und Multimediainhalte anbieten, bis hin zu multinationalen Unternehmen, die Telefon-, Satelliten-, Fern- und internationale Kommunikationsdienste anbieten sowie Organisationen globale Netzwerke. Heutzutage wird TDW von großen und kleinen Festnetzbetreibern genutzt Kabellose Kommunikation weltweit.

Ein Tool namens InfoSphere Warehouse-Paket für Kundeneinblicke bietet strukturierte, einfach zu implementierende Geschäftsinhalte für eine wachsende Zahl von Geschäftsprojekten und Branchen, darunter Banken, Versicherungen, Finanzen, Krankenversicherungen, Telekommunikation, Einzelhandel und Vertrieb. Für Geschäftsanwender InfoSphere Warehouse Pack für Markt- und Kampagneneinblicke hilft, die Effektivität von Marktanalyseaktivitäten und Marketingkampagnen durch einen schrittweisen Entwicklungsprozess und unter Berücksichtigung der Besonderheiten des Unternehmens zu maximieren. Mit Hilfe InfoSphere Warehouse Pack für Supply Chain Insight Organisationen können aktuelle Informationen über die Abläufe in der Lieferkette erhalten.

Die Position von Esri innerhalb der Lösungsarchitektur von IBM.

Der Ansatz von IBM gegenüber Strom- und Versorgungsunternehmen verdient besondere Aufmerksamkeit. Um den wachsenden Kundenanforderungen gerecht zu werden, benötigen Versorgungsunternehmen eine flexiblere Architektur als derzeit verwendet sowie ein branchenübliches Objektmodell, um den freien Informationsfluss zu erleichtern. Dies wird die Kommunikationsfähigkeiten von Energieunternehmen verbessern, ihnen eine kosteneffektivere Zusammenarbeit ermöglichen und den neuen Systemen eine größere Transparenz über alle benötigten Ressourcen geben, unabhängig davon, wo sie sich innerhalb der Organisation befinden. Grundlage für diesen Ansatz ist SOA (serviceorientierte Architektur), ein Komponentenmodell, das eine wiederverwendbare Zuordnung zwischen den Funktionen von Abteilungen und den Diensten verschiedener Anwendungen herstellt. Die „Dienste“ solcher Komponenten tauschen Daten über Schnittstellen ohne starre Bindung aus und verbergen so vor dem Benutzer die volle Komplexität der dahinter stehenden Systeme. In diesem Modus können Unternehmen ganz einfach neue Anwendungen hinzufügen, unabhängig vom Softwareanbieter, dem Betriebssystem, der Programmiersprache oder anderen internen Softwaremerkmalen. Basierend auf SOA wird das Konzept umgesetzt SICHER ( Solution Architecture for Energy ermöglicht es Versorgungsunternehmen, eine auf Standards basierende, ganzheitliche Sicht auf ihre Infrastruktur zu erhalten.

Esri ArcGIS® ist eine international anerkannte Softwareplattform für geografische Informationssysteme (GIS), die die Erstellung und Verwaltung digitaler Assets von Strom-, Gastransport-, Verteilungs- und Telekommunikationsnetzen ermöglicht. Mit ArcGIS können Sie eine möglichst vollständige Bestandsaufnahme der Komponenten des Stromverteilungsnetzes unter Berücksichtigung ihrer räumlichen Lage durchführen. ArcGIS erweitert die IBM SAFE-Architektur erheblich, indem es die Tools, Anwendungen, Workflows, Analysen und Inbereitstellt, die für die Verwaltung eines intelligenten Versorgungsunternehmens erforderlich sind. ArcGIS в рамках IBM SAFE позволяет получать из различных источников информацию об объектах инфраструктуры, активах, клиентах и сотрудниках с точными данными об их местоположении, а также создавать, хранить и обрабатывать геопривязанную информацию об активах предприятия (опоры, трубопроводы, провода, трансформаторы, кабельная канализация usw.). Mit ArcGIS innerhalb der SAFE-Infrastruktur können Sie wichtige Geschäftsanwendungen dynamisch integrieren, indem Sie Daten aus GIS-, SCADA- und Kundendienstsystemen mit externen Informationen wie Verkehrsaufkommen, Wetterbedingungen oder Satellitenbildern kombinieren. Versorgungsunternehmen nutzen solche kombinierten Informationen für verschiedene Zwecke, von S.O.R. (Gesamtbetriebsbild) bis hin zu Standortinspektionen, Wartung, Netzwerkanalyse und Planung.

Die Informationskomponenten eines Energieversorgungsunternehmens können über mehrere Ebenen modelliert werden, die von der niedrigsten – physischen – bis zur höchsten, komplexesten Ebene der Geschäftsprozesslogik reichen. Diese Schichten können integriert werden, um typische Branchenanforderungen zu erfüllen, wie z. B. automatisierte Messprotokollierung und SCADA-Steuerung (Supervisory Control and Data Acquisition). Durch den Aufbau der SAFE-Architektur unternehmen Versorgungsunternehmen wichtige Schritte zur Weiterentwicklung eines branchenweiten offenen Objektmodells namens Common Information Model (CIM) für Energie und Versorgungsunternehmen. Dieses Modell bietet vielen Unternehmen die notwendige Grundlage für den Übergang zu einer serviceorientierten Architektur, da es die Verwendung offener Standards für die Strukturierung von Daten und Objekten fördert. Indem sichergestellt wird, dass alle Systeme dieselben Objekte verwenden, werden die Verwirrung und Inelastizität, die mit unterschiedlichen Implementierungen derselben Objekte verbunden sind, auf ein Minimum reduziert. Auf diese Weise wird die Definition der Kundeneinheit und anderer wichtiger Geschäftseinheiten in allen Versorgungssystemen vereinheitlicht. Mit CIM können Dienstanbieter und Verbraucher nun eine gemeinsame Datenstruktur nutzen, was die Auslagerung kostspieliger Geschäftskomponenten erleichtert, da CIM eine gemeinsame Basis schafft, auf der der Informationsaustausch aufgebaut werden kann.

Abschluss

Umfassende Branchendatenmodelle bieten Unternehmen eine einzige, integrierte Sicht auf ihre Geschäftsinformationen. Vielen Unternehmen fällt die Integration ihrer Daten schwer, obwohl dies für die meisten unternehmensweiten Projekte eine Voraussetzung ist. Laut einer Studie des Data Warehousing Institute (TDWI) gaben mehr als 69 % der befragten Unternehmen an, dass die Integration ein erhebliches Hindernis für die Einführung neuer Anwendungen darstellt. Im Gegenteil: Die Datenintegration bringt dem Unternehmen spürbare Einnahmen und eine höhere Effizienz.

Ein ordnungsgemäß konstruiertes Modell definiert eindeutig die Bedeutung von Daten, bei denen es sich in diesem Fall um strukturierte Daten handelt (im Gegensatz zu unstrukturierten Daten wie Bildern, Binärdateien oder Texten, bei denen die Bedeutung möglicherweise nicht eindeutig ist). Die effektivsten Branchenmodelle werden von professionellen Anbietern angeboten, darunter Esri und IBM. Die hohen Erträge aus der Verwendung ihrer Modelle werden durch ihren hohen Detaillierungsgrad und ihre Genauigkeit erzielt. Sie enthalten normalerweise viele Datenattribute. Darüber hinaus verfügen Esri und IBM nicht nur über umfassende Modellierungserfahrung, sondern sind auch versiert im Aufbau branchenspezifischer Modelle.

Dieser Artikel konzentriert sich auf die Data Warehouse-Architektur. Was ist beim Aufbau zu beachten, welche Ansätze funktionieren – und warum.

„Das Märchen ist eine Lüge – aber es steckt ein Hinweis darin …“

Großvater hat... eine Lagerstätte angelegt. Und es entstand ein großes, sehr großes Lager. Ich wusste einfach nicht wirklich, wie es funktionierte. Und mein Großvater begann eine Rezension. Der Großvater rief Großmutter, Enkelin, Katz und Maus zum Familienrat zusammen. Und er sagt folgendes Thema: „Unser Lager ist gewachsen. Daten aus allen Systemen fließen zusammen, Tabellen sind sichtbar und unsichtbar. Benutzer erstellen ihre eigenen Berichte. Alles scheint in Ordnung zu sein – leben und leben. Es gibt nur eine Traurigkeit – niemand weiß, wie es funktioniert. Es erfordert Scheiben, scheinbar oder unsichtbar – man kann nicht genug bekommen! Und dann gewöhnten sich die Benutzer daran, mit verschiedenen Beschwerden zu mir zu kommen: Manchmal friert der Bericht ein, manchmal sind die Daten veraltet. Ansonsten ist es eine völlige Katastrophe – wir kommen mit Berichten an den Zarenvater, aber die Zahlen stimmen nicht überein. Die Stunde ist nie sicher – der König wird wütend sein – dann werden weder ich noch du den Kopf verlieren. Also habe ich beschlossen, Sie zusammenzubringen und zu besprechen: Was werden wir tun?“

Er schaute sich in der Versammlung um und fragte:
- Weißt du, Oma, wie unser Lager eingerichtet ist?
- Nein, Großvater, ich weiß es nicht. Und woher soll ich das wissen? Es gibt einige tapfere Jungs, die ihn bewachen! Was für ein Schnurrbart! Du wirst dich nicht nähern. Eines Tages besuchte ich sie und backte ein paar Kuchen. Und sie aßen die Kuchen, wischten sich den Schnurrbart ab und sagten: „Warum bist du gekommen, Oma? Welche Art von Speicher benötigen Sie? Sagen Sie uns einfach, welche Art von Bericht Sie benötigen und wir erledigen das für Sie! Die Hauptsache ist, öfter Kuchen mitzubringen! Sie sind zu lecker.
- Und du, geliebte Enkelin, weißt du, wie unser Lager funktioniert?
- Nein, Großvater, ich weiß es nicht. Sie haben mir irgendwie Zugang dazu verschafft. Ich habe mich verbunden, ich habe geschaut – und da waren Tische – scheinbar und unsichtbar. Und in den Diagrammen sind verschiedene versteckt. Die Augen laufen wild... Ich war zuerst verwirrt. Und dann schaute ich genauer hin – einige waren leer, andere gefüllt, aber nur die Hälfte. Und die Daten scheinen sich zu wiederholen. Kein Wunder, dass man bei dieser Redundanz nicht genug Festplatten bekommen kann!
- Nun, Katze, was kannst du über unser Lager sagen? Gibt es etwas Gutes daran?
- Wie kann ich es nicht sagen, Großvater, ich werde es sagen. Auf Wunsch meiner Enkelin habe ich versucht, einen Piloten in einem separaten Muster anzufertigen – einer kleinen Vitrine. Um zu verstehen, welcher Handel für unseren Staat profitabel ist – welche Produkte für Händler gut sind, zollen sie Tribut – die Staatskasse wird aufgefüllt. Und welche sind wirklich schlecht. Und ich begann, Daten aus diesem Repository für mich selbst auszuwählen. Ich habe Fakten gesammelt. Und er begann, sie mit den Produkten zu vergleichen. Und was, Großvater, ich habe gesehen – die Produkte scheinen gleich zu sein, aber wenn man sich die Schilder ansieht, sind sie unterschiedlich! Dann fing ich an, sie mit dem Kamm meiner Enkelin zu kämmen. Gekratzt und gekratzt – und führte zu einer gewissen Gleichmäßigkeit, die das Auge streichelte. Aber schon früh freute ich mich – am nächsten Tag startete ich meine Skripte, um die wunderbaren Daten im Anzeigefenster zu aktualisieren – und bei mir ging alles schief! "Wie so?" - Ich denke - meine Enkelin wird verärgert sein - heute sollten wir dem Minister unseren Piloten zeigen. Wie können wir mit solchen Daten umgehen?
- Ja, du erzählst traurige Geschichten, Katze. Na, du kleine Maus, hast du nicht wirklich versucht, etwas über das Lager herauszufinden? Du bist ein lebhaftes, flinkes, geselliges Mädchen! Was werden Sie uns sagen?
- Warum, Opa, warum versuchst du es nicht? Natürlich bin ich eine ruhige Maus, aber eine flinke. Einmal bat mich die Enkelin der Katze, ein Datenmodell aus unserem staatlichen Repository zu holen. Und die Katze kam natürlich zu mir – meine ganze Hoffnung ruht auf dir, sagt er, Maus! Warum also nicht eine gute Tat für gute Menschen (und Katzen) tun? Ich ging zum Schloss, wo der Leiter des Lagers das Datenmodell in einem Safe versteckt. Und sie versteckte sich. Ich wartete, bis er das Modell aus dem Safe holte. Sobald er Kaffee holen ging, sprang ich auf den Tisch. Ich schaue mir das Modell an und kann nichts verstehen! Wie so? Ich erkenne unser Lager nicht! Wir haben Tausende von unzähligen Tabellen, endlose Datenströme! Und hier ist alles harmonisch und schön... Er schaute sich dieses Modell an und legte es zurück in den Safe.
- Ja, du hast uns sehr seltsame Dinge erzählt, Maus.
Der Großvater dachte tief nach.
- Was machen wir, meine Freunde? Schließlich wird man mit diesem oder jenem Speicher nicht lange leben... Benutzer werden bald völlig die Geduld verlieren.

Was auch immer unser Großvater aus dem Märchen beschließt – ein neues Lager zu bauen oder zu versuchen, ein bestehendes wiederzubeleben – wir müssen Schlussfolgerungen ziehen, bevor wir wieder „die Ärmel hochkrempeln“.
Lassen wir organisatorische Aspekte beiseite – wie die Gefahr der Konzentration von Fachwissen in einer engen geschlossenen Gruppe, das Fehlen von Kontrollprozessen und die Gewährleistung der Transparenz der Architektur der im Unternehmen verwendeten Systeme usw.
Heute möchte ich mich auf den Aufbau der Architektur eines bestimmten Systems (oder einer Gruppe von Systemen) konzentrieren – Data Warehouses. Worauf muss zunächst geachtet werden, wenn ein Unternehmen ein so komplexes und teures System wie den Speicher aufbauen möchte?

Nachbesprechung

Keiner von uns, der an der Schaffung und Entwicklung eines Systems arbeitet, möchte, dass es sich um eine „behelfsmäßige“ Lösung handelt oder um eine Lösung, die in ein oder zwei Jahren „aussterben“ wird, weil wird nicht in der Lage sein, die Anforderungen und Erwartungen von Kunden und Unternehmen zu erfüllen. Unabhängig davon, wie stark die Vorliebe für „agile Methoden“ heute zu beobachten ist, ist es für einen Menschen viel angenehmer, sich wie ein „Meister“ zu fühlen, der Geigen baut, als wie ein Handwerker, der Stöcke für Einwegtrommeln schnitzt.
Unsere Absicht klingt natürlich: solide und qualitativ hochwertige Systeme zu schaffen, die uns keine regelmäßigen „Nachtwachen mit der Akte“ erfordern, für die wir uns vor den Endbenutzern nicht schämen und die nicht wie eine aussehen „Black Box“ an alle „uneingeweihten“ Follower.

Lassen Sie uns zunächst eine Liste typischer Probleme erstellen, auf die wir bei der Arbeit mit Lagereinrichtungen regelmäßig stoßen. Schreiben wir einfach auf, was wir haben – vorerst, ohne zu versuchen, es zu organisieren und zu formalisieren.

Im Prinzip haben wir einen guten Speicher: Wenn man ihn nicht anfasst, funktioniert alles. Es stimmt, sobald eine Änderung erforderlich ist, kommt es zu „lokalen Zusammenbrüchen“.
Das Laden der Daten erfolgt gemäß den Vorschriften täglich innerhalb eines großen Prozesses innerhalb von 8 Stunden. Und das passt zu uns. Wenn jedoch plötzlich ein Fehler auftritt, ist ein manueller Eingriff erforderlich. Und dann kann alles lange Zeit unvorhersehbar funktionieren, weil... Die Beteiligung des Menschen an diesem Prozess ist erforderlich.
Die Veröffentlichung ist da – erwarten Sie Probleme.
Eine Quelle konnte die Daten nicht rechtzeitig bereitstellen – alle Prozesse warten.
Die Integrität der Daten wird von der Datenbank kontrolliert – daher stürzen unsere Prozesse bei Verstößen mit einem Fehler ab.
Wir verfügen über einen sehr großen Speicher – 2000 Tabellen in einem gemeinsamen Schema. Und weitere 3000 in vielen anderen Systemen. Wir haben bereits keine Ahnung, wie sie funktionieren und aus welchem Grund sie entstanden sind. Daher kann es für uns schwierig sein, etwas wiederzuverwenden. Und viele Probleme müssen neu gelöst werden. Weil es einfacher und schneller ist (als „den Code eines anderen“ zu verstehen). Dadurch kommt es zu Unstimmigkeiten und doppelten Funktionalitäten.
Wir erwarten, dass die Quelle qualitativ hochwertige Daten liefert. Es stellt sich jedoch heraus, dass dies nicht der Fall ist. Daher verbringen wir viel Zeit damit, unsere Abschlussberichte abzugleichen. Und das gelang ihnen sehr gut. Wir haben sogar einen optimierten Prozess. Stimmt, es braucht Zeit. Aber Benutzer sind es gewohnt...
Der Nutzer traut unseren Berichten nicht immer und verlangt eine Begründung für diese oder jene Zahl. In manchen Fällen hat er Recht, in anderen wiederum Unrecht. Aber es fällt uns sehr schwer, sie zu rechtfertigen, weil... Wir bieten keine „End-to-End-Analyse“-Tools (oder Datenherkunftstools) an.
Wir könnten weitere Entwickler gewinnen. Aber wir haben ein Problem – wie können wir sie in unsere Arbeit einbeziehen? Wie lässt sich die Arbeit am effizientesten parallelisieren?
Wie kann man das System schrittweise entwickeln, ohne ein ganzes Jahr damit zu verbringen, den „Kern des Systems“ zu entwickeln?
Das Data Warehouse ist mit dem Unternehmensmodell verknüpft. Aber wir wissen mit Sicherheit (wir haben es in der XYZ-Bank gesehen), dass die Erstellung eines Modells unendlich viel Zeit in Anspruch nehmen kann (in der XYZ-Bank gingen sie sechs Monate lang herum und diskutierten über Geschäftseinheiten, ohne sich zu bewegen). Warum braucht sie es überhaupt? Oder ist es vielleicht besser ohne sie, wenn es so viele Probleme mit ihr gibt? Vielleicht lässt es sich irgendwie generieren?
Wir haben uns entschieden, das Modell laufen zu lassen. Doch wie entwickelt man systematisch ein Lagerdatenmodell? Brauchen wir „Spielregeln“ und wie könnten diese aussehen? Was bringt uns das? Was ist, wenn wir mit dem Modell einen Fehler machen?
Sollten wir Daten oder den Verlauf ihrer Änderungen speichern, wenn „das Unternehmen sie nicht benötigt“? Ich möchte keinen „Müll speichern“ und die Verwendung dieser Daten für echte Aufgaben erschweren. Soll das Repository den Verlauf bewahren? Wie ist es? Wie funktioniert die Speicherung im Laufe der Zeit?
Sollten wir versuchen, die Daten im Speicher zu vereinheitlichen, wenn wir über ein Stammdatenverwaltungssystem verfügen? Wenn es MDM gibt, ist dann das gesamte Stammdatenproblem gelöst?
Es wird erwartet, dass wir bald wichtige Buchhaltungssysteme ersetzen werden. Sollte das Data Warehouse auf Quelländerungen vorbereitet sein? Wie erreicht man das?
Brauchen wir Metadaten? Was meinen wir damit? Wo genau können sie eingesetzt werden? Wie kann es umgesetzt werden? Müssen sie „an einem Ort“ aufbewahrt werden?
Unsere Kunden sind in ihren Anforderungen und Wünschen äußerst instabil – es verändert sich ständig etwas. Generell ist unser Geschäft sehr dynamisch. Solange wir etwas tun, wird es unnötig. Wie können wir sicherstellen, dass wir schnellstmöglich Ergebnisse liefern – wie warme Semmeln?
Benutzer verlangen Effizienz. Aber wir können unsere Haupt-Download-Prozesse nicht oft ausführen, weil... Dies belastet die Quellsysteme (beeinträchtigt stark die Leistung) – daher fügen wir zusätzliche Datenströme hinzu – die genau das aufnehmen, was wir brauchen. Stimmt, es gibt viele Threads. Und dann werden wir einige der Daten wegwerfen. Darüber hinaus wird es ein Konvergenzproblem geben. Aber es geht nicht anders...

Es ist schon einiges passiert. Dies ist jedoch keine vollständige Liste – sie kann leicht ergänzt und weiterentwickelt werden. Wir werden es nicht in der Tabelle verstecken, sondern an einer gut sichtbaren Stelle aufhängen – so bleiben diese Themen bei unserer Arbeit im Mittelpunkt unserer Aufmerksamkeit.
Unsere Aufgabe ist es, am Ende eine umfassende Lösung zu entwickeln.

Antifragilität

Wenn wir uns unsere Liste ansehen, können wir eine Schlussfolgerung ziehen. Es ist nicht schwer, eine Art „Datenbank für die Berichterstattung“ zu erstellen, dort Daten hinzuzufügen oder sogar eine Art Regulierungsprozess für die Aktualisierung von Daten aufzubauen. Das System beginnt irgendwie zu leben, Benutzer erscheinen und mit ihnen entstehen Verpflichtungen und SLAs, neue Anforderungen entstehen, zusätzliche Quellen werden angeschlossen, Methoden ändern sich – all dies muss im Entwicklungsprozess berücksichtigt werden.

Nach einiger Zeit sieht das Bild so aus:
„Hier ist der Lagerraum. Und es funktioniert, wenn man es nicht berührt. Probleme entstehen, wenn wir etwas ändern müssen.“

Es kommt zu uns eine Veränderung, deren Auswirkungen wir nicht abschätzen und nachvollziehen können (da wir solche Werkzeuge ursprünglich nicht in das System eingebaut haben) – und um kein Risiko einzugehen, greifen wir nicht an, was da ist, sondern machen etwas anderes Erweiterung nebenbei, und noch eine, und auch - unsere Lösung in Slums umzuwandeln, oder wie man in Lateinamerika sagt, „Favelas“, in die selbst die Polizei Angst hat, einzudringen.
Es entsteht ein Gefühl von Kontrollverlust über das eigene System, Chaos. Um bestehende Prozesse zu unterstützen und Probleme zu lösen, werden immer mehr Hände benötigt. Und Veränderungen werden immer schwieriger. Mit anderen Worten: Das System wird gegenüber Stress instabil und reagiert nicht mehr auf Veränderungen. Und außerdem besteht eine starke Abhängigkeit von Charakteren, die „das Fairway kennen“, da niemand eine „Karte“ hat.

Diese Eigenschaft eines Objekts besteht darin, unter dem Einfluss von Chaos, zufälligen Ereignissen und Erschütterungen zusammenzubrechen – nennt Nassim Nicholas Taleb Zerbrechlichkeit . Und führt auch das gegenteilige Konzept ein: Antifragilität – wenn ein Gegenstand durch Stress und Unfälle nicht zerstört wird, sondern einen direkten Nutzen daraus zieht. („Antifragil. Wie man vom Chaos profitiert“)
Ansonsten kann es aufgerufen werden Anpassungsfähigkeit oder Widerstand zur Aenderung .

Was bedeutet das in diesem Zusammenhang? Was sind die „Chaosquellen“ für IT-Systeme? Und was bedeutet es aus Sicht der IT-Architektur, „vom Chaos zu profitieren“?
Der erste Gedanke, der einem in den Sinn kommt, sind Veränderungen, die von außen kommen. Was ist die Außenwelt für das System? Insbesondere zur Aufbewahrung. Natürlich gibt es zunächst einmal Änderungen bei den Datenquellen für die Speicherung:

Ändern der Formate eingehender Daten;
Ersetzen eines Datenquellensystems durch ein anderes;
sich ändernde Systemintegrationsregeln/Plattformen;
sich ändernde Interpretationen von Daten (Formate bleiben erhalten, die Logik der Arbeit mit Daten ändert sich);
Ändern des Datenmodells, wenn die Integration auf Datenebene erfolgt (Analyse der Datenbank-Transaktionsprotokolldateien);
Wachstum des Datenvolumens – während es im Quellsystem nur wenige Daten gab und die Last gering war – Sie konnten es jederzeit annehmen, bei jeder großen Anfrage wuchsen die Daten und die Last – jetzt gibt es strenge Einschränkungen;
usw.

Die Quellsysteme selbst, die Zusammensetzung der Informationen und ihre Struktur, die Art der Integrationsinteraktion sowie die Logik der Arbeit mit Daten können sich ändern. Jedes System implementiert sein eigenes Datenmodell und Ansätze für die Arbeit damit, die den Zielen und Vorgaben des Systems entsprechen. Und egal, wie sehr man danach strebt, Branchenmodelle und Referenzpraktiken zu vereinheitlichen, es werden unweigerlich Nuancen auftauchen. (Außerdem macht der Prozess der Branchenvereinigung selbst aus verschiedenen Gründen keine großen Fortschritte.)
Die Kultur der Arbeit mit Unternehmensdaten – das Vorhandensein und die Kontrolle der Informationsarchitektur, ein einheitliches semantisches Modell, Master-Data-Management-Systeme (MDM) – erleichtern die Konsolidierung von Daten in einem Lager etwas, schließen ihre Notwendigkeit jedoch nicht aus.

Nicht weniger kritische Änderungen werden durch Speicherverbraucher (Anforderungsänderungen) initiiert:

Früher gab es genügend Daten, um einen Bericht zu erstellen – jetzt war es notwendig, zusätzliche Felder oder eine neue Datenquelle zu verbinden;
Bisher implementierte Datenverarbeitungstechniken sind veraltet – die Algorithmen und alles, was davon betroffen ist, müssen überarbeitet werden;
Früher war jeder mit dem aktuellen Wert des Verzeichnisattributs im Informationsfeld zufrieden – jetzt ist ein Wert erforderlich, der zum Zeitpunkt des Eintretens des analysierten Sachverhalts/Ereignisses relevant ist;
Es entstand eine Anforderung an die Tiefe der Datenspeicherhistorie, die es vorher nicht gab – Daten nicht für 2 Jahre, sondern für 10 Jahre zu speichern;
Früher reichten die Daten ab „Tages-/Zeitraumende“ aus – jetzt benötigen Sie den Datenstand „innerhalb eines Tages“ oder zum Zeitpunkt eines bestimmten Ereignisses (z. B. Entscheidung über einen Kreditantrag - für Basel II);
Früher waren wir mit der Berichterstattung über die Daten von gestern (T-1) oder später zufrieden, jetzt brauchen wir T0;
usw.

Sowohl Integrationsinteraktionen mit Quellsystemen als auch Anforderungen von Warehouse-Datenkonsumenten sind externe Faktoren für das Data Warehouse: Einige Quellsysteme ersetzen andere, Datenmengen wachsen, eingehende Datenformate ändern sich, Benutzeranforderungen ändern sich usw. Und das alles sind typische äußere Veränderungen, auf die unser System – unser Speicher – vorbereitet sein muss. Mit der richtigen Architektur sollten sie das System nicht zerstören.

Aber das ist noch nicht alles.
Wenn wir über Variabilität sprechen, erinnern wir uns zunächst an externe Faktoren. Schließlich können wir im Inneren alles kontrollieren, denken wir doch, oder? Ja und nein. Ja, die meisten Faktoren, die außerhalb des Einflussbereichs liegen, sind externer Natur. Es gibt aber auch „innere Entropie“. Und gerade wegen seiner Präsenz müssen wir manchmal „zum Punkt 0“ zurückkehren. Beginnen Sie das Spiel von vorne.
Im Leben neigen wir oft dazu, bei Null anzufangen. Warum ist das charakteristisch für uns? Und ist das so schlimm?
Auf die IT angewendet. Das kann für das System selbst sehr gut sein – die Möglichkeit, einzelne Entscheidungen zu überdenken. Vor allem, wenn wir es vor Ort tun können. Refactoring ist der Prozess der Entwirrung des „Webs“, das regelmäßig im Prozess der Systementwicklung entsteht. Es kann hilfreich sein, zum Anfang zurückzukehren. Aber es hat einen Preis.
Bei richtiger Verwaltung der Architektur wird dieser Preis gesenkt – und der Prozess der Systementwicklung selbst wird kontrollierter und transparenter. Ein einfaches Beispiel: Wenn das Modularitätsprinzip befolgt wird, kann man ein separates Modul neu schreiben, ohne die externen Schnittstellen zu beeinträchtigen. Und das ist mit einer monolithischen Struktur nicht möglich.

Die Antifragilität eines Systems wird durch die darin eingebettete Architektur bestimmt. Und genau diese Eigenschaft macht es anpassungsfähig.
Wenn wir darüber reden adaptive Architektur– Wir meinen, dass das System in der Lage ist, sich an Veränderungen anzupassen, und keineswegs, dass wir die Architektur selbst ständig ändern. Im Gegenteil: Je stabiler und stabiler die Architektur, je weniger Anforderungen eine Überarbeitung mit sich bringt, desto anpassungsfähiger ist das System.

Lösungen, die eine Überarbeitung der gesamten Architektur erfordern, werden einen deutlich höheren Preis haben. Und um sie zu akzeptieren, muss man sehr gute Gründe haben. Eine solche Grundlage könnte beispielsweise eine Anforderung sein, die innerhalb der bestehenden Architektur nicht umsetzbar ist. Dann heißt es, es sei eine Anforderung aufgetaucht, die sich auf die Architektur auswirkt.
Daher müssen wir auch unsere „Antifragilitätsgrenzen“ kennen. Architektur entsteht nicht „im luftleeren Raum“, sondern orientiert sich an aktuellen Anforderungen und Erwartungen. Und wenn sich die Situation grundlegend ändert, müssen wir verstehen, dass wir über die aktuelle Architektur hinausgegangen sind – und wir müssen sie überdenken, eine andere Lösung entwickeln – und über Übergangsmöglichkeiten nachdenken.
Wir gingen beispielsweise davon aus, dass wir am Ende des Tages immer Daten im Speicher benötigen würden; wir würden täglich Daten über Standardsystemschnittstellen (über eine Reihe von Ansichten) sammeln. Dann kamen Forderungen aus der Risikomanagementabteilung, dass die Daten nicht erst am Ende des Tages, sondern zum Zeitpunkt der Kreditentscheidung eingeholt werden müssten. Es besteht keine Notwendigkeit, zu versuchen, „das Ungestreckte zu dehnen“ – Sie müssen nur diese Tatsache erkennen – je früher, desto besser. Und fangen Sie an, an einem Ansatz zu arbeiten, der es uns ermöglicht, das Problem zu lösen.
Hier gibt es einen sehr schmalen Grat: Wenn wir nur die „aktuellen Anforderungen“ berücksichtigen und nicht ein paar Schritte (und ein paar Jahre) vorausschauen, dann erhöhen wir das Risiko, auch auf eine Anforderung zu stoßen, die sich auf die Architektur auswirkt spät - und die Kosten unserer Änderungen werden sehr hoch sein. Ein wenig nach vorne zu schauen – innerhalb der Grenzen unseres Horizonts – hat noch niemandem geschadet.

Das Beispiel eines Systems aus dem „Speichermärchen“ ist gerade ein Beispiel für ein sehr wackeliges System, das auf fragilen Designansätzen aufbaut. Und wenn dies geschieht, kommt es insbesondere bei dieser Klasse von Systemen recht schnell zu einer Zerstörung.
Warum kann ich das sagen? Das Thema Lagerung ist nicht neu. Die in dieser Zeit entwickelten Ansätze und Ingenieurspraktiken zielten genau darauf ab – die Lebensfähigkeit des Systems zu erhalten.
Ein einfaches Beispiel: Einer der häufigsten Gründe für das Scheitern von Storage-Projekten „on takeoff“ ist der Versuch, Storage auf in der Entwicklung befindlichen Quellsystemen aufzubauen, ohne sich auf Integrationsschnittstellen zu einigen – ein Versuch, Daten direkt aus dem zu übernehmen Tische. Infolgedessen gingen sie in die Entwicklung – während dieser Zeit änderte sich die Quelldatenbank – und die Upload-Streams zum Speicher wurden nicht mehr funktionsfähig. Es ist zu spät, etwas noch einmal zu machen. Und wenn Sie sich noch nicht durch den Aufbau mehrerer Tischschichten im Lager abgesichert haben, können Sie alles wegwerfen und von vorne beginnen. Dies ist nur ein Beispiel und eines der einfachsten.

Talebs Kriterium für fragil und antifragil ist einfach. Der Hauptrichter ist die Zeit. Wenn ein System den Test der Zeit besteht und seine „Überlebensfähigkeit“ und „Unzerstörbarkeit“ zeigt, verfügt es über die Eigenschaft der Antifragilität.
Wenn wir beim Entwurf eines Systems die Antifragilität als Anforderung berücksichtigen, wird uns dies dazu ermutigen, beim Aufbau seiner Architektur solche Ansätze zu verwenden, die das System anpassungsfähiger sowohl an „Chaos von außen“ als auch an „Chaos von innen“ machen .“ Und letztendlich wird das System eine längere Lebensdauer haben.
Keiner von uns möchte „temporäre Gebäude“ errichten. Und machen Sie sich nichts vor, dass es heute unmöglich ist, anders zu handeln. Ein paar Schritte nach vorne zu blicken, ist für einen Menschen jederzeit normal, insbesondere in einer Krise.

Was ist ein Data Warehouse und warum bauen wir es?

Ein Artikel über Speicherarchitektur geht davon aus, dass der Leser nicht nur weiß, was es ist, sondern auch Erfahrung mit ähnlichen Systemen hat. Dennoch hielt ich es für notwendig, dies zu tun – zu den Ursprüngen, zum Anfang des Weges zurückzukehren, denn... Hier liegt der „Drehpunkt“ der Entwicklung.

Wie kamen die Menschen zu dem Schluss, dass Data Warehouses notwendig sind? Und wie unterscheiden sie sich von einer „sehr großen Datenbank“?
Vor langer Zeit, als es auf der Welt einfach „Geschäftsdatenverarbeitungssysteme“ gab, gab es keine Einteilung der IT-Systeme in Klassen wie Front-End-OLTP-Systeme, Backoffice-DSS, Textdatenverarbeitungssysteme, Data Warehouses usw .
Zu dieser Zeit wurde das erste relationale DBMS, Ingres, von Michael Stonebreaker erstellt.
Und das war die Zeit, als die Ära der Personalcomputer wie ein Wirbelsturm in die Computerindustrie einbrach und alle Vorstellungen der damaligen IT-Community für immer veränderte.

Damals war es einfach, Unternehmensanwendungen zu finden, die auf Basis von DBMS der Desktop-Klasse wie Clipper, dBase und FoxPro geschrieben waren. Und der Markt für Client-Server-Anwendungen und DBMS gewann gerade an Dynamik. Nach und nach erschienen Datenbankserver, die lange Zeit ihre Nische im IT-Bereich besetzen würden – Oracle, DB2 usw.
Und der Begriff „Datenbankanwendung“ war weit verbreitet. Was beinhaltete dieser Antrag? Vereinfacht – einige Eingabeformulare, über die Benutzer gleichzeitig Informationen eingeben konnten, einige Berechnungen, die „per Knopfdruck“ oder „nach einem Zeitplan“ gestartet wurden, sowie einige Berichte, die auf dem Bildschirm angezeigt oder als Dateien gespeichert und an die Versiegelung gesendet werden konnten.
„Nichts Besonderes – eine reguläre Bewerbung, nur eine Datenbank“, bemerkte einer meiner Mentoren zu Beginn meiner Karriere. „Ist es nichts Besonderes?“ - Dachte ich damals.

Wenn man genau hinschaut, gibt es noch einige Features. Wenn die Benutzer wachsen, die Menge der eingehenden Informationen zunimmt und die Belastung des Systems zunimmt, greifen seine Entwickler und Designer auf bestimmte „Tricks“ zurück, um die Leistung auf einem akzeptablen Niveau zu halten. Das allererste ist die Aufteilung eines monolithischen „Geschäftsdatenverarbeitungssystems“ in eine Buchhaltungsanwendung, die die Online-Arbeit der Benutzer unterstützt, und eine separate Anwendung für die Stapelverarbeitung und Berichterstattung von Daten. Jede dieser Anwendungen verfügt über eine eigene Datenbank und wird sogar auf einer separaten Instanz des Datenbankservers gehostet, mit unterschiedlichen Einstellungen für verschiedene Lastarten – OLTP und DSS. Und zwischen ihnen werden Datenflüsse aufgebaut.

Das ist alles? Es scheint, dass das Problem gelöst ist. Was passiert als nächstes?
Und dann wachsen Unternehmen, ihr Informationsbedarf vervielfacht sich. Auch die Zahl der Interaktionen mit der Außenwelt nimmt zu. Und dadurch gibt es nicht eine große Anwendung, die alle Prozesse vollständig automatisiert, sondern mehrere verschiedene, von unterschiedlichen Herstellern. Die Zahl der Systeme, die Informationen generieren – Datenquellensysteme – in einem Unternehmen nimmt zu. Und früher oder später wird es notwendig sein, die von verschiedenen Systemen empfangenen Informationen einzusehen und zu vergleichen. So entstehen Data Warehouses im Unternehmen – eine neue Klasse von Systemen.
Die allgemein akzeptierte Definition dieser Systemklasse lautet wie folgt.

Data Warehouse (oder Data Warehouse)– eine themenorientierte Informationsdatenbank, die speziell für die Erstellung von Berichten und Geschäftsanalysen zur Unterstützung der Entscheidungsfindung in einer Organisation entwickelt und bestimmt ist

Auf diese Weise, Konsolidierung Daten aus verschiedenen Systemen, die Fähigkeit, sie auf eine bestimmte „einzige“ (einheitliche) Weise zu betrachten, ist eine der Schlüsseleigenschaften von Data Warehouse-Klassensystemen. Aus diesem Grund sind Speicher im Zuge der Weiterentwicklung der IT-Systeme entstanden.

Hauptmerkmale von Data Warehouses

Lass uns genauer hinschauen. Welche Hauptmerkmale haben diese Systeme? Was unterscheidet Data Warehouses von anderen Unternehmens-IT-Systemen?

Erstens handelt es sich um große Volumina. Sehr groß. VLDB – so nennen führende Anbieter solche Systeme, wenn sie Empfehlungen zum Einsatz ihrer Produkte geben. Aus allen Systemen des Unternehmens fließen Daten in diese große Datenbank und werden dort „ewig und unveränderlich“ gespeichert, wie es in Lehrbüchern heißt (in der Praxis gestaltet sich das Leben als komplizierter).

Zweitens handelt es sich hierbei um historische Daten – „Unternehmensgedächtnis“ – so werden Data Warehouses genannt. Was die Arbeit mit der Zeit in Lagereinrichtungen angeht, ist alles sehr interessant. In Buchhaltungssystemen sind die Daten aktuell. Anschließend führt der Benutzer einen bestimmten Vorgang aus und die Daten werden aktualisiert. Der Änderungsverlauf bleibt jedoch möglicherweise nicht erhalten – dies hängt von den Buchhaltungspraktiken ab. Nehmen Sie zum Beispiel Ihren Kontostand. Möglicherweise interessiert uns der aktuelle Kontostand zum „Jetzt“, am Ende des Tages oder zum Zeitpunkt eines Ereignisses (z. B. zum Zeitpunkt der Berechnung des Punktestands). Wenn die ersten beiden ganz einfach zu lösen sind, wird das letzte höchstwahrscheinlich besondere Anstrengungen erfordern. Der Benutzer, der mit dem Speicher arbeitet, kann auf vergangene Zeiträume zugreifen, diese mit dem aktuellen vergleichen usw. Es sind genau solche zeitbezogenen Fähigkeiten, die Data Warehouses deutlich von Buchhaltungssystemen unterscheiden – die Erfassung des Zustands von Daten an verschiedenen Punkten der Zeitachse – bis zu einer gewissen Tiefe in der Vergangenheit.

Drittens dies Konsolidierung Und Datenvereinheitlichung . Damit ihre gemeinsame Analyse möglich wird, ist es notwendig, sie in eine gemeinsame Form zu bringen – einheitliches Datenmodell Vergleichen Sie Fakten mit einheitlichen Nachschlagewerken. Hier kann es mehrere Aspekte und Schwierigkeiten geben. Vor allem - konzeptionell – Verschiedene Personen aus verschiedenen Abteilungen können unter demselben Begriff unterschiedliche Dinge verstehen. Und umgekehrt – etwas anders zu nennen, was im Wesentlichen dasselbe ist. Wie kann eine „einheitliche Sicht“ sichergestellt und gleichzeitig die Spezifität der Vision einer bestimmten Benutzergruppe gewahrt werden?

Viertens ist das Arbeit mit Datenqualität . Während des Ladens von Daten in das Warehouse werden Datenbereinigung sowie allgemeine Transformationen und Transformationen durchgeführt. Allgemeine Transformationen müssen an einem Ort durchgeführt und dann zum Erstellen verschiedener Berichte verwendet werden. Dadurch werden die Unstimmigkeiten vermieden, die bei Geschäftsanwendern so viel Ärger hervorrufen – insbesondere beim Management, dem Zahlen aus verschiedenen Abteilungen vorgelegt werden, die nicht miteinander übereinstimmen. Eine schlechte Datenqualität führt zu Fehlern und Unstimmigkeiten in den Berichten, was einen Rückgang des Niveaus zur Folge hat Benutzervertrauen auf das gesamte System, auf den gesamten Analysedienst als Ganzes.

Architekturkonzept

Wer schon einmal auf ein Lager gestoßen ist, hat höchstwahrscheinlich eine Art „Schichtstruktur“ beobachtet – denn. Es ist dieses Architekturparadigma, das sich für Systeme dieser Klasse durchgesetzt hat. Und das nicht zufällig. Speicherschichten können als separate Komponenten des Systems wahrgenommen werden – mit eigenen Aufgaben, Verantwortungsbereichen und „Spielregeln“.
Die geschichtete Architektur ist ein Mittel zum Umgang mit der Komplexität des Systems – jede nachfolgende Ebene wird von der Komplexität der internen Implementierung der vorherigen abstrahiert. Mit diesem Ansatz können Sie ähnliche Probleme identifizieren und auf einheitliche Weise lösen, ohne das „Fahrrad“ jedes Mal von Grund auf neu erfinden zu müssen.
Das konzeptionelle Architekturdiagramm ist in der Abbildung schematisch dargestellt. Dies ist ein vereinfachtes Diagramm, das nur die Schlüsselidee – das Konzept – widerspiegelt, jedoch ohne die „anatomischen Details“, die bei einer tieferen Ausarbeitung der Details entstehen.

Wie im Diagramm dargestellt, heben wir konzeptionell die folgenden Ebenen hervor. Drei Hauptebenen, die den Datenspeicherbereich (gekennzeichnet durch ein ausgefülltes Rechteck) und die Software zum Laden von Daten (üblicherweise durch gleichfarbige Pfeile dargestellt) enthalten. Und auch eine Hilfsschicht – die Serviceschicht, die jedoch eine sehr wichtige verbindende Rolle spielt – Datenlademanagement und Qualitätskontrolle.

Primäre Datenschicht – primäre Datenschicht (oder Inszenierung , oder Betriebsschicht ) – konzipiert für das Laden aus Quellsystemen und das Speichern von Primärinformationen ohne Transformationen – in Originalqualität und -unterstützung vollständige GeschichteÄnderungen.
Der Zweck dieser Ebene– Abstrahieren nachfolgender Speicherebenen von der physischen Struktur von Datenquellen, Methoden zur Datenerfassung und Methoden zur Isolierung von Delta-Änderungen.

Kerndatenschicht – Speicherkern – eine zentrale Komponente des Systems, die das Repository von einer einfachen „Batch-Integrationsplattform“ oder einem „Big-Data-Dump“ unterscheidet, da seine Hauptaufgabe darin besteht Datenkonsolidierung aus unterschiedlichen Quellen, Reduktion auf einheitliche Strukturen, Schlüssel. Beim Laden in den Kernel werden die Hauptarbeiten zur Datenqualität und allgemeinen Transformationen durchgeführt, die recht komplex sein können.
Der Zweck dieser Ebene– Abstrahieren Sie Ihre Verbraucher von den Besonderheiten der logischen Struktur von Datenquellen und der Notwendigkeit, Daten aus verschiedenen Systemen zu vergleichen, und stellen Sie die Integrität und Qualität der Daten sicher.

Data Mart Layer – analytische Schaufenster – eine Komponente, deren Hauptfunktion darin besteht, Daten in für die Analyse geeignete Strukturen umzuwandeln (wenn BI mit Storefronts arbeitet, handelt es sich normalerweise um ein Dimensionsmodell) oder entsprechend den Anforderungen des Verbrauchersystems.
In der Regel beziehen Storefronts Daten aus dem Kern – als verlässliche und verifizierte Quelle – d.h. Nutzen Sie den Dienst dieser Komponente, um Daten in ein einziges Formular zu bringen. Wir werden solche Vitrinen nennen regulär . In einigen Fällen können Storefronts Daten direkt aus dem Staging übernehmen – unter Verwendung von Primärdaten (in Quellschlüsseln). Dieser Ansatz wird normalerweise für lokale Aufgaben verwendet, bei denen keine Konsolidierung von Daten aus verschiedenen Systemen erforderlich ist und bei denen Effizienz wichtiger ist als Datenqualität. Solche Vitrinen nennt man betriebsbereit . Einige analytische Indikatoren verfügen möglicherweise über sehr komplexe Berechnungsmethoden. Daher sind für solche nicht trivialen Berechnungen und Transformationen sogenannte sekundäre Vitrinen .
Aufgabe „Ebene präsentieren“.– Aufbereitung von Daten gemäß den Anforderungen eines bestimmten Verbrauchers – BI-Plattform, Benutzergruppe oder externes System.

Die oben beschriebenen Schichten bestehen aus einem persistenten Datenspeicherbereich sowie einem Softwaremodul zum Laden und Transformieren von Daten. Diese Einteilung in Schichten und Bereiche ist logisch. Die physische Implementierung dieser Komponenten kann unterschiedlich sein – Sie können sogar verschiedene Plattformen verwenden, um Daten auf verschiedenen Ebenen zu speichern oder umzuwandeln, wenn dies effizienter ist.
Speicherbereiche enthalten technische Daten (Puffertabellen), die im Prozess der Datentransformation verwendet werden und Zieltabellen, auf die von der konsumierenden Komponente zugegriffen wird. Es empfiehlt sich, Zieltabellen mit Ansichten zu „überdecken“. Dies erleichtert die spätere Wartung und Weiterentwicklung des Systems. Daten in den Zieltabellen aller drei Schichten sind mit speziellen technischen Feldern (Metaattributen) gekennzeichnet, die zur Unterstützung von Datenladeprozessen sowie zur Informationsprüfung der Datenflüsse in das Lager dienen.

Außerdem wird eine spezielle Komponente (oder ein Satz von Komponenten) identifiziert, die Servicefunktionen für alle Schichten bereitstellt. Eine seiner Hauptaufgaben ist die Steuerungsfunktion – die Bereitstellung von „Level-Spielregeln“ für das gesamte System als Ganzes, wobei für jede der oben beschriebenen Ebenen unterschiedliche Implementierungsmöglichkeiten vorbehalten bleiben – inkl. Verwenden Sie unterschiedliche Technologien zum Laden und Verarbeiten von Daten, unterschiedliche Speicherplattformen usw. Rufen wir ihn an Serviceschicht . Es enthält keine Geschäftsdaten, verfügt aber über eigene Speicherstrukturen – es enthält einen Metadatenbereich sowie einen Bereich zum Arbeiten mit Datenqualität (und ggf. weitere Strukturen, abhängig von den ihm zugewiesenen Funktionen).

Eine solche klare Aufteilung des Systems in einzelne Komponenten erhöht die Beherrschbarkeit der Systementwicklung deutlich:

die Komplexität der Aufgabe, die dem Entwickler der Funktionalität einer bestimmten Komponente zugewiesen wird, wird reduziert (er muss nicht gleichzeitig Probleme der Integration mit externen Systemen lösen, Datenbereinigungsverfahren durchdenken und über die optimale Darstellung von Daten nachdenken). für Verbraucher) – die Aufgabe ist einfacher, eine kleine Lieferung zu zerlegen, zu bewerten und durchzuführen;
Sie können verschiedene Künstler (und sogar Teams oder Auftragnehmer) in die Arbeit einbeziehen – denn Mit diesem Ansatz können Sie Aufgaben effektiv parallelisieren und ihre gegenseitige Beeinflussung verringern.
Das Vorhandensein von persistentem Staging ermöglicht es Ihnen, Datenquellen schnell zu verbinden, ohne den gesamten Kernel oder Showcases für den gesamten Themenbereich entwerfen zu müssen, und dann die verbleibenden Schichten nach und nach nach Prioritäten aufzubauen (und die Daten befinden sich bereits im Speicher und sind für das System zugänglich). Analysten, was die Aufgaben der späteren Entwicklung des Speichers erheblich erleichtern wird);
Das Vorhandensein des Kernels ermöglicht es, die gesamte Arbeit mit der Datenqualität (sowie mögliche Fehler und Irrtümer) vor den Storefronts und dem Endbenutzer zu verbergen, und was am wichtigsten ist, durch die Verwendung dieser Komponente als einzige Datenquelle für die Storefronts. Probleme mit der Datenkonvergenz können durch die Implementierung gemeinsamer Algorithmen an einem Ort vermieden werden;
Durch die Hervorhebung von Showcases können Sie die Unterschiede und das spezifische Verständnis von Daten berücksichtigen, die Benutzer verschiedener Abteilungen möglicherweise haben. Durch deren Gestaltung gemäß BI-Anforderungen können Sie nicht nur aggregierte Zahlen erstellen, sondern durch die Bereitstellung auch die Zuverlässigkeit der Daten sicherstellen die Fähigkeit, einen Drilldown zu primären Indikatoren durchzuführen;
Das Vorhandensein einer Serviceschicht ermöglicht Ihnen die Durchführung einer End-to-End-Datenanalyse (Datenherkunft), die Verwendung einheitlicher Datenprüfungstools, allgemeine Ansätze zur Identifizierung von Delta-Änderungen, die Arbeit mit Datenqualität, Lastmanagement, Überwachungs- und Fehlerdiagnosetools usw beschleunigt die Problemlösung.

Dieser Zersetzungsansatz macht das System auch widerstandsfähiger gegen Veränderungen (im Vergleich zu einer „monolithischen Struktur“) und gewährleistet seine Antifragilität:

Änderungen aus den Quellsystemen werden im Staging verarbeitet – im Kernel werden nur die Threads geändert, die von diesen Staging-Tabellen beeinflusst werden; die Auswirkungen auf Storefronts sind minimal oder fehlen;
Änderungen der Anforderungen von Verbrauchern werden größtenteils in Storefronts verarbeitet (es sei denn, es werden zusätzliche Informationen benötigt, die nicht bereits im Repository vorhanden sind).

Als Nächstes gehen wir die einzelnen oben vorgestellten Komponenten durch und betrachten sie etwas genauer.

Systemkern

Beginnen wir „in der Mitte“ – dem Kern des Systems oder der mittleren Schicht. Nein wird als Kernschicht bezeichnet. Der Kernel übernimmt die Rolle der Datenkonsolidierung – Reduzierung auf einheitliche Strukturen, Verzeichnisse, Schlüssel. Hier wird die Hauptarbeit mit der Datenqualität geleistet – Bereinigung, Transformation, Vereinheitlichung.

Das Vorhandensein dieser Komponente ermöglicht die Wiederverwendung von Datenströmen, die von Quellsystemen empfangene Primärdaten nach allgemeinen Regeln und Algorithmen in ein einheitliches Format umwandeln, anstatt die Implementierung derselben Funktionalität separat für jede Anwendungspräsentation zu wiederholen, was zusätzlich zu Eine ineffiziente Nutzung von Ressourcen kann zu Datendiskrepanzen führen.
Der Speicherkern wird in einem Datenmodell implementiert, das sich im Allgemeinen sowohl von den Modellen der Quellsysteme als auch von den Formaten und Strukturen der Verbraucher unterscheidet.

Speicherkernmodell und Unternehmensdatenmodell

Die Hauptaufgabe der mittleren Lagerschicht ist die Stabilität. Deshalb liegt hier der Schwerpunkt auf dem Datenmodell. Es wird allgemein als „Unternehmensdatenmodell“ bezeichnet. Leider hat sich um ihn herum ein gewisser Heiligenschein aus Mythen und Absurditäten entwickelt, der manchmal dazu führt, dass seine Konstruktion ganz aufgegeben wird, aber vergeblich.

Mythos 1. Das Unternehmensdatenmodell ist ein riesiges Modell, das aus Tausenden von Entitäten (Tabellen) besteht.
Tatsächlich. In jedem Fachgebiet, in jedem Geschäftsbereich, in den Daten eines jeden Unternehmens, selbst der komplexesten, gibt es nur wenige Hauptentitäten – 20 bis 30.

Mythos 2. Es besteht keine Notwendigkeit, ein „eigenes Modell“ zu entwickeln – wir kaufen ein Branchenreferenzmodell und machen alles danach. Wir geben Geld aus, erzielen aber garantierte Ergebnisse.
Tatsächlich. Referenzmodelle können tatsächlich sehr nützlich sein, weil... verfügen über Branchenerfahrung in der Modellierung dieses Bereichs. Daraus können Sie Ideen, Ansätze und Benennungspraktiken ableiten. Überprüfen Sie die „Abdeckungstiefe“ des Bereichs, um nichts Wichtiges zu verpassen. Es ist jedoch unwahrscheinlich, dass wir ein solches Modell „out of the box“ – so wie es ist – nutzen können. Dies ist derselbe Mythos wie beispielsweise der Kauf eines ERP-Systems (oder CRM) und die Implementierung ohne jegliche „Anpassung“. Der Wert solcher Modelle liegt in ihrer Anpassung an die Realitäten dieses bestimmten Geschäfts, dieses bestimmten Unternehmens.

Mythos 3. Die Entwicklung eines Speicherkernmodells kann viele Monate dauern, in denen das Projekt praktisch eingefroren wird. Es erfordert auch wahnsinnig viele Besprechungen und viele beteiligte Personen.
Tatsächlich. Das Repository-Modell kann zusammen mit dem Repository iterativ und stückweise entwickelt werden. Für nicht abgedeckte Bereiche werden „Extension Points“ oder „Stubs“ platziert – also Es werden einige „universelle Designs“ verwendet. Gleichzeitig müssen Sie wissen, wann Sie aufhören müssen, damit Sie nicht mit einem superuniversellen Ding bestehend aus 4 Tabellen enden, in das es schwierig ist, Daten zu „einzufügen“ und (noch schwieriger) zu bekommen es raus. Und was leistungstechnisch äußerst suboptimal funktioniert.

Es wird in der Tat einige Zeit dauern, das Modell zu entwickeln. Dies ist jedoch nicht die Zeit, die für das „Zeichnen von Entitäten“ aufgewendet wird, sondern die Zeit, die benötigt wird, um den Themenbereich zu analysieren und zu verstehen, wie die Daten strukturiert sind. Deshalb sind Analysten in diesen Prozess sehr eng eingebunden, aber auch verschiedene Wirtschaftsexperten sind beteiligt. Und das geschieht punktuell, punktuell. Und nicht, indem man Meetings organisiert, an denen wahnsinnig viele Leute teilnehmen, riesige Fragebögen verschickt usw.
Eine qualitative Geschäfts- und Systemanalyse ist der Schlüssel zum Aufbau eines Speicherkernmodells. Sie müssen viele Dinge verstehen: wo (in welchen Systemen) die Daten generiert werden, wie sie organisiert sind, in welchen Geschäftsprozessen sie zirkulieren usw. Eine qualitative Analyse hat noch nie einem einzigen System geschadet. Im Gegenteil: Probleme entstehen durch „blinde Flecken“ in unserem Verständnis.

Bei der Entwicklung eines Datenmodells geht es nicht darum, etwas Neues zu erfinden und zu entwickeln. Tatsächlich existiert das Datenmodell des Unternehmens bereits. Und der Entwurfsprozess ähnelt eher einer „Ausgrabung“. Das Modell wird sorgfältig und behutsam aus dem „Boden“ der Unternehmensdaten ans Licht gebracht und in eine strukturierte Form gebracht.

Mythos 4. In unserem Unternehmen ist das Geschäft so dynamisch und alles ändert sich so schnell, dass es für uns sinnlos ist, ein Modell zu erstellen – es wird veraltet sein, bevor wir diesen Teil des Systems in Betrieb nehmen.
Tatsächlich. Denken wir daran, dass der Schlüsselfaktor des Kerns die Stabilität ist. Und vor allem die Topologie des Modells. Warum? Denn es ist diese Komponente, die zentral ist und alles andere beeinflusst. Stabilität ist auch eine Voraussetzung für das Kernelmodell. Wenn ein Modell zu schnell veraltet, bedeutet das, dass es falsch konzipiert wurde. Für seine Entwicklung wurden die falschen Ansätze und „Spielregeln“ gewählt. Und das ist auch eine Frage der qualitativen Analyse. Der Kern des Unternehmensmodells ändert sich äußerst selten.
Aber wenn es uns in den Sinn kommt, für ein Unternehmen, das beispielsweise Süßwaren verkauft, statt des Verzeichnisses „Produkte“ „Süßigkeiten“, „Kuchen“ und „Kuchen“ zu erstellen. Wenn Pizza in der Warenliste erscheint, müssen Sie viele neue Tabellen eingeben. Und das ist nur eine Frage der Herangehensweise.

Mythos 5. Die Erstellung eines Unternehmensmodells ist eine sehr ernste, komplexe und verantwortungsvolle Angelegenheit. Und es ist beängstigend, einen Fehler zu machen.
Tatsächlich. Obwohl das Kernmodell stabil sein sollte, ist es dennoch nicht „in Metall gegossen“. Wie bei jeder anderen Entwurfsentscheidung kann seine Struktur überprüft und geändert werden. Diese Qualität sollte man einfach nicht außer Acht lassen. Das heißt aber keineswegs, dass man darauf „nicht atmen“ kann. Und das bedeutet nicht, dass temporäre Lösungen und „Stubs“, die für die Verarbeitung eingeplant werden sollten, inakzeptabel sind.

Mythos 6. Wenn unsere Datenquelle beispielsweise ein Master-Data-Management-System (oder ein Master-Data-Management-System – MDM) ist, dann sollte es bereits gut zum Unternehmensmodell passen (insbesondere, wenn es erst kürzlich entworfen wurde und noch keine Zeit hatte, es zu erwerben). Nebenwirkungen“, „Traditionen“ und temporäre Bauten). Es stellt sich heraus, dass wir für diesen Fall kein Kernelmodell benötigen?
Tatsächlich. Ja, in diesem Fall wird die Erstellung eines Speicherkernelmodells erheblich vereinfacht – weil Wir folgen einem vorgefertigten konzeptionellen Modell auf höchster Ebene. Aber es ist nicht völlig ausgeschlossen. Warum? Denn beim Erstellen eines Modells eines bestimmten Systems gelten bestimmte Regeln – welche Tabellentypen (für jede Entität) verwendet werden sollen, wie Daten versioniert werden, mit welcher Granularität der Verlauf gespeichert werden soll, welche Metaattribute (zu verwendende technische Felder) usw .

Unabhängig davon, wie wunderbar und umfassend unser Stammdaten- und Datenverwaltungssystem ist, wird es in der Regel Nuancen geben, die mit der Existenz lokaler Verzeichnisse „ungefähr gleich“ in anderen Buchhaltungssystemen verbunden sind. Und dieses Problem muss, ob wir es wollen oder nicht, im Lager gelöst werden – schließlich werden hier Berichte und Analysen gesammelt.

Primäre Datenschicht (oder historisierte Staging- oder Betriebsschicht)

Sie wird als primäre Datenschicht bezeichnet. Die Rolle dieser Komponente ist: Integration mit Quellsystemen, Laden und Speichern von Primärdaten sowie vorläufige Datenbereinigung – Überprüfung der Einhaltung der Formatregeln und der logischen Steuerung, die in der „Interaktionsschnittstellenvereinbarung“ mit der Quelle festgelegt sind.
Darüber hinaus löst diese Komponente eine sehr wichtige Aufgabe für das Repository – die Isolierung des „wahren Deltas der Änderungen“ – unabhängig davon, ob die Quelle es Ihnen ermöglicht, Änderungen in den Daten zu verfolgen oder nicht und wie (nach welchem Kriterium können sie „abgefangen“ werden) ). Sobald die Daten im Staging angekommen sind, ist für alle anderen Schichten die Frage der Delta-Allokation bereits klar – dank der Markierung mit Metaattributen.

Daten in dieser Schicht werden in Strukturen gespeichert, die möglichst nahe am Quellsystem liegen – um die Primärdaten so nah wie möglich an ihrer ursprünglichen Form zu halten. Ein anderer Name für diese Komponente ist „Operational Layer“.
Warum nicht einfach den etablierten Begriff „Inszenierung“ verwenden? Tatsache ist, dass früher, vor der „Ära von Big Data und VLDB“, Festplattenplatz es war sehr teuer – und oft wurden die Primärdaten, wenn überhaupt, nur für einen begrenzten Zeitraum gespeichert. Und oft wird auch der Begriff „Inszenierung“ genannt reinigbar Puffer.
Jetzt hat die Technologie Fortschritte gemacht – und wir können es uns leisten, nicht nur alle Primärdaten zu speichern, sondern sie auch mit dem Grad an Granularität zu historisieren, der möglich ist. Dies bedeutet nicht, dass wir das Datenwachstum nicht kontrollieren sollten und beseitigt nicht die Notwendigkeit, den Lebenszyklus von Informationen zu verwalten und die Kosten der Datenspeicherung abhängig von der „Nutzungstemperatur“ zu optimieren – d. h. Verlagerung „kalter Daten“, die weniger gefragt sind, auf günstigere Medien- und Speicherplattformen.

Was bringt uns die Präsenz der „historisierten Inszenierung“:

die Möglichkeit, Fehler zu machen (in Strukturen, in Transformationsalgorithmen, in der Granularität der Geschichte) – da wir vollständig historisierte Primärdaten im Speicherbereich haben, können wir unsere Tabellen jederzeit neu laden;
eine Gelegenheit zum Nachdenken – wir können uns in dieser speziellen Iteration der Repository-Entwicklung Zeit lassen, ein großes Fragment des Kernels zu entwickeln, weil in unserer Inszenierung werden sie es auf jeden Fall sein, und zwar mit einem gleichmäßigen Zeithorizont (der „Bezugspunkt der Geschichte“ wird einer sein);
Möglichkeit der Analyse – wir speichern auch die Daten, die sich nicht mehr in der Quelle befinden – sie könnten dort verloren gegangen sein, ins Archiv gegangen sein usw. – bei uns bleiben sie zur Analyse verfügbar;
die Möglichkeit einer Informationsprüfung – dank der detailliertesten Primärinformationen können wir dann herausfinden, wie der Download bei uns funktioniert hat, dass wir letztendlich solche Zahlen erhalten haben (dafür müssen wir auch Meta-Attribut-Markierungen und die entsprechenden Metadaten haben). wie der Download funktioniert - dies wird auf der Serviceschicht entschieden).

Welche Schwierigkeiten können bei der Konstruktion einer „historisierten Inszenierung“ auftreten:

Es wäre praktisch, Anforderungen an die Transaktionsintegrität dieser Schicht festzulegen, aber die Praxis zeigt, dass dies schwierig zu erreichen ist (das bedeutet, dass wir in diesem Bereich die referenzielle Integrität der übergeordneten und untergeordneten Tabellen nicht garantieren) – der Integritätsabgleich erfolgt auf der nächsten Ebene Lagen;
Diese Schicht enthält sehr große Volumina (die umfangreichsten im Speicher – trotz aller Redundanz der analytischen Strukturen) – und Sie müssen in der Lage sein, mit solchen Volumina umzugehen – sowohl aus der Sicht des Ladens als auch aus der Sicht der Abfragen (Andernfalls kann die Leistung des gesamten Speichers erheblich beeinträchtigt werden).

Was kann man sonst noch Interessantes über diese Schicht sagen?
Erstens, wenn wir uns vom Paradigma der „End-to-End-Ladeprozesse“ entfernen, dann funktioniert die Regel „Die Karawane bewegt sich mit der Geschwindigkeit des letzten Kamels“ für uns nicht mehr; genauer gesagt, wir geben die „Karawane“ auf. Prinzip und gehen zum „Förderer“-Prinzip über: Wir nehmen Daten von der Quelle – legen sie in Ihre Ebene ein – bereit für die nächste Portion. Das bedeutet es
1) Wir warten nicht darauf, dass die Verarbeitung auf anderen Ebenen erfolgt.
2) Wir sind nicht auf den Datenbereitstellungsplan anderer Systeme angewiesen.
Einfach ausgedrückt planen wir einen Ladeprozess, der Daten von einer Quelle über eine bestimmte Art der Verbindung übernimmt, sie prüft, ein Delta zuweist – und die Daten in den Ziel-Staging-Tabellen ablegt. Und alle.

Zweitens sind diese Prozesse, wie Sie sehen, sehr einfach aufgebaut – aus logischer Sicht könnte man sagen: trivial. Dadurch lassen sie sich sehr gut optimieren und parametrisieren, was die Belastung unseres Systems reduziert und den Prozess der Quellenanbindung (Entwicklungszeit) beschleunigt.
Damit dies geschieht, müssen Sie die technologischen Merkmale der Plattform, auf der diese Komponente läuft, genau kennen – und dann können Sie ein sehr effektives Werkzeug erstellen.

Analytische Schaufensterebene

Layer Showcases (Data Mart Layer) ist für die Aufbereitung und Bereitstellung von Daten für Endbenutzer – Personen oder Systeme – verantwortlich. Auf dieser Ebene werden die Anforderungen des Verbrauchers so weit wie möglich berücksichtigt – sowohl logisch (konzeptionell) als auch physisch. Der Dienst sollte genau das bieten, was benötigt wird – nicht mehr und nicht weniger.

Handelt es sich beim Konsumenten um ein externes System, so bestimmt er in der Regel die benötigten Datenstrukturen und die Regeln zur Informationsbeschaffung. Ein guter Ansatz ist, dass der Verbraucher selbst für die korrekte Datenerhebung verantwortlich ist. Das Data Warehouse hat die Daten aufbereitet, den Showcase erstellt, die Möglichkeit der inkrementellen Datenerfassung bereitgestellt (Markierung mit Metaattributen zur späteren Identifizierung des Änderungsdeltas) und das Verbrauchersystem verwaltet und ist dann dafür verantwortlich, wie es diesen Showcase nutzt. Es gibt jedoch einige Besonderheiten: Wenn das System keine aktive Komponente zum Sammeln von Daten hat, ist entweder eine externe Komponente erforderlich, die die Integrationsfunktion übernimmt, oder der Speicher fungiert als „Integrationsplattform“ – und sorgt für das korrekte inkrementelle Laden von Daten über die Speicherung hinaus. Hier kommen viele Nuancen zum Vorschein und die Regeln der Schnittstelleninteraktion müssen durchdacht und für beide Seiten verständlich sein (allerdings wie immer, wenn es um Integration geht). In der Regel unterliegen solche Storefronts einer routinemäßigen Datenbereinigung/-archivierung (es ist selten erforderlich, dass diese „Transitdaten“ über einen längeren Zeitraum gespeichert werden).

Den größten Wert aus Sicht analytischer Aufgaben haben Showcases „für Menschen“ – genauer gesagt für die BI-Tools, mit denen sie arbeiten.
Es gibt jedoch eine Kategorie „besonders fortgeschrittener Benutzer“ – Analysten, Datenwissenschaftler –, die weder BI-Tools noch regulatorische Prozesse zum Befüllen externer Spezialsysteme benötigen. Sie benötigen eine Art „gemeinsames Schaufenster“ und eine „eigene Sandbox“, in der sie nach eigenem Ermessen Tabellen und Transformationen erstellen können. In diesem Fall liegt die Verantwortung des Repositoriums darin, dafür zu sorgen, dass diese gemeinsamen Storefronts vorschriftsgemäß mit Daten gefüllt werden.
Unabhängig davon können wir Verbraucher wie Data-Mining-Tools hervorheben – eine umfassende Datenanalyse. Solche Tools haben ihre eigenen Anforderungen an die Datenvorbereitung und auch Data-Mining-Experten arbeiten mit ihnen. Für das Repository besteht die Aufgabe wiederum darin, einen Dienst zum Laden bestimmter Showcases in einem vereinbarten Format zu unterstützen.

Kehren wir jedoch zu den analytischen Schaufenstern zurück. Sie sind aus Sicht der Speicherentwickler in dieser Datenschicht von Interesse.
Meiner Meinung nach ist der Ansatz von Ralph Kimball der bewährteste Ansatz zur Gestaltung von Data Marts, auf den mittlerweile fast alle BI-Plattformen „zugeschnitten“ sind. Es ist bekannt als dimensionale Modellierung – mehrdimensionale Modellierung. Es gibt sehr viele Veröffentlichungen zu diesem Thema. Die Grundregeln finden sich beispielsweise in der Publikation von Marga Ross. Und natürlich können Sie es von einem Guru für mehrdimensionale Modellierung empfehlen. Eine weitere nützliche Ressource sind Kimballs Tipps
Der multidimensionale Ansatz zur Erstellung von Storefronts wird sowohl von den „Evangelisten der Methode“ als auch von den führenden Softwareanbietern so gut beschrieben und ausgearbeitet, dass es keinen Sinn macht, hier im Detail darauf einzugehen – die Originalquelle ist immer vorzuziehen.

Ich möchte nur einen Schwerpunkt hervorheben. „Reporting und Analytics“ können unterschiedlich sein. Es gibt „Heavy Reporting“ – vorbestellte Berichte, die in Form von Dateien generiert und über die bereitgestellten Lieferkanäle an Benutzer übermittelt werden. Und es gibt Informationstafeln – BI-Dashboards. Im Kern handelt es sich dabei um Webanwendungen. Und an die Reaktionszeit dieser Anwendungen gelten die gleichen Anforderungen wie an jede andere Webanwendung. Das bedeutet, dass die normale Aktualisierungszeit des BI-Dashboards Sekunden und nicht Minuten beträgt. Es ist wichtig, dies bei der Entwicklung einer Lösung zu berücksichtigen. Wie erreicht man das? Standardmethode Optimierung: Wir schauen, was die Reaktionszeit ausmacht und was wir beeinflussen können. Was verschwendet Ihre Zeit am meisten? Für physische (Festplatten-)Datenbankablesungen, für die Datenübertragung über das Netzwerk. Wie kann die pro Anfrage gelesene und übertragene Datenmenge reduziert werden? Die Antwort liegt auf der Hand und ist einfach: Sie müssen entweder die Daten aggregieren oder einen Filter auf große Tabellen auf die an der Abfrage beteiligten Faktentabellen anwenden und die Verbindung großer Tabellen ausschließen (Verweise auf Faktentabellen sollten nur über Dimensionen erfolgen).

Warum brauchen Sie BI? Wie ist es bequem? Warum ist ein mehrdimensionales Modell effektiv?
BI ermöglicht dem Benutzer die Durchführung sogenannter „Ad-hoc-Abfragen“. Was bedeutet das? Das bedeutet, dass wir die genaue Anfrage nicht im Voraus kennen, aber wir wissen, welche Indikatoren in welchen Abschnitten der Benutzer anfordern kann. Der Benutzer generiert eine solche Abfrage, indem er die entsprechenden BI-Filter auswählt. Und die Aufgabe des BI-Entwicklers und Storefront-Designers besteht darin, eine solche Anwendungslogik sicherzustellen, sodass die Daten entweder gefiltert oder aggregiert werden, um eine Situation zu vermeiden, in der zu viele Daten angefordert werden und die Anwendung hängen bleibt. Normalerweise beginnen sie mit aggregierten Zahlen, gehen dann tiefer auf detailliertere Daten ein, installieren aber nebenbei die notwendigen Filter.

Es reicht nicht immer aus, nur den „richtigen Stern“ zu bauen und eine geeignete Struktur für BI zu erhalten. Manchmal müssen Sie irgendwo eine Denormalisierung anwenden (und dabei prüfen, wie sich dies auf die Last auswirkt), und irgendwo müssen Sie sekundäre Showcases und Aggregate erstellen. Fügen Sie irgendwo Indizes oder Projektionen hinzu (je nach DBMS).

Somit ist es durch „Versuch und Irrtum“ möglich, eine für BI optimale Struktur zu erhalten, die die Merkmale sowohl des DBMS und der BI-Plattform als auch die Anforderungen des Benutzers an die Datenpräsentation berücksichtigt.
Wenn wir Daten aus dem „Kern“ entnehmen, ist eine solche Verarbeitung von Storefronts lokaler Natur, ohne dass die komplexe Verarbeitung von Primärdaten, die direkt aus Quellsystemen stammen, in irgendeiner Weise beeinträchtigt wird – wir „übertragen“ die Daten lediglich in ein für sie geeignetes Format BI. Und wir können es uns leisten, dies viele Male, auf unterschiedliche Weise und entsprechend unterschiedlicher Anforderungen zu tun. Mithilfe von Kernel-Daten ist dies viel einfacher und schneller als das Sammeln von Kernel-Daten (deren Struktur und Regeln, wie wir wissen, auch „schweben“ können).

Serviceschicht

Die Serviceschicht ( - Service Layer) ist für die Implementierung allgemeiner (Dienst-)Funktionen verantwortlich, die zur Verarbeitung von Daten in verschiedenen Speicherschichten verwendet werden können – Lastmanagement, Datenqualitätsmanagement, Problemdiagnose- und Überwachungstools usw.
Das Vorhandensein dieser Ebene gewährleistet Transparenz und Struktur der Datenflüsse im Speicher.

Diese Schicht umfasst zwei Datenspeicherbereiche:

Metadatenbereich – wird für den Mechanismus zur Steuerung des Datenladens verwendet;
Datenqualitätsbereich – zur Implementierung von Offline-Datenqualitätsprüfungen (d. h. solcher, die nicht direkt in ETL-Prozesse integriert sind).

Sie können den Download-Verwaltungsprozess auf unterschiedliche Weise strukturieren. Einer der möglichen Ansätze ist dieser: Wir unterteilen den gesamten Satz an Ablagetischen in Module. Ein Modul kann nur Tabellen aus einer Ebene enthalten. Die in jedem Modul enthaltenen Tabellen werden in einem separaten Prozess geladen. Rufen wir ihn an Kontrollprozess . Der Start des Kontrollprozesses ist geplant. Der Masterprozess orchestriert Aufrufe an atomare Prozesse, die jeweils eine Zieltabelle laden, und enthält außerdem einige allgemeine Schritte.
Offensichtlich reicht es aus, die Staging-Tabellen einfach in Module zu unterteilen – entsprechend den Quellsystemen, genauer gesagt, ihren Verbindungspunkten. Für den Kernel ist dies jedoch bereits schwieriger, weil Dort müssen wir die Datenintegrität sicherstellen, das heißt, wir müssen Abhängigkeiten berücksichtigen. Diese. Es entstehen Konflikte, die gelöst werden müssen. Und es gibt verschiedene Methoden, sie zu lösen.

Ein wichtiger Punkt im Lastmanagement ist die Entwicklung eines einheitlichen Ansatzes zur Fehlerbehandlung. Fehler werden nach Schweregrad klassifiziert. Wenn ein kritischer Fehler auftritt, muss der Prozess gestoppt werden, und zwar so schnell wie möglich, denn Sein Auftreten weist auf ein erhebliches Problem hin, das zu einer Datenbeschädigung im Speicher führen kann. Beim Lastmanagement geht es also nicht nur darum, Prozesse zu starten, sondern auch darum, sie zu stoppen und einen (versehentlichen) vorzeitigen Start zu verhindern.

Zum Betrieb der Serviceschicht wird eine spezielle Metadatenstruktur erstellt. In diesem Bereich werden Informationen über Ladeprozesse, geladene Datensätze, Prüfpunkte, die zum Inkrementieren verwendet werden (welcher Prozess hat bis zu welchem Punkt gelesen) und andere Serviceinformationen gespeichert, die für das Funktionieren des Systems erforderlich sind.
Es ist wichtig zu beachten, dass alle Zieltabellen in allen Ebenen mit einem speziellen Satz von Metafeldern gekennzeichnet sind, von denen eines die Kennung des Prozesses ist, der diese Zeile aktualisiert hat. Für Tabellen innerhalb des Repositorys ermöglicht diese Prozesskennzeichnung eine einheitliche Möglichkeit, das Änderungsdelta nachträglich hervorzuheben. Beim Laden von Daten in die primäre Datenschicht ist die Situation komplizierter – der Delta-Zuteilungsalgorithmus für verschiedene geladene Objekte kann unterschiedlich sein. Aber die Logik, akzeptierte Änderungen zu verarbeiten und sie auf Zieltabellen für den Kernel und Storefronts zu übertragen, ist viel komplizierter als beim Staging, wo alles ziemlich trivial ist – es ist einfach, wiederverwendbare Standardschritte (Prozeduren) zu parametrisieren und zu durchdenken.

Ich möchte mich hier nicht vollständig mit dem Thema „Verladungsorganisation“ befassen, sondern nur Punkte hervorheben, die es wert sind, beachtet zu werden.
Der obige Ansatz ist nur eine Option. Es ist ziemlich anpassungsfähig. Und sein „konzeptioneller Prototyp“ war das Toyota-Förderband und das Just-in-Time-System. Diese. Hier entfernen wir uns von dem weit verbreiteten Paradigma des ausschließlich „nächtlichen Datenladens“ und dem Laden in kleinen Portionen tagsüber – da die Daten in verschiedenen Quellen bereitliegen: Es wurde heruntergeladen, was hereinkam. Gleichzeitig laufen bei uns viele parallele Prozesse. Und der „heiße Schwanz“ neuer Daten wird ständig „blinken“ – und nach einiger Zeit wird er sich einpendeln. Wir müssen diese Funktion berücksichtigen. Und erstellen Sie bei Bedarf individuelle Vitrinen in „Scheiben“, in denen bereits alles fertig ist. Diese. Es ist unmöglich, gleichzeitig Effizienz und Konsistenz (Integrität) zu erreichen. Wir brauchen Balance – an manchen Orten ist das eine wichtig, an anderen das andere.

Es ist wichtig, Protokollierungs- und Überwachungsfunktionen bereitzustellen. Eine bewährte Vorgehensweise ist die Verwendung typisierter Ereignisse, bei denen Sie verschiedene Parameter festlegen und ein Benachrichtigungssystem konfigurieren können – Abonnements für bestimmte Ereignisse. Weil Es ist sehr wichtig, dass der Systemadministrator, wenn ein Eingreifen erforderlich ist, so früh wie möglich davon erfährt und alle erforderlichen Diagnoseinformationen erhält. Protokolle können auch zur nachträglichen Analyse von Problemen sowie zur Untersuchung von Vorfällen von Systemausfällen verwendet werden, z. Datenqualität.

Design und Pflege von Lagerdatenmodellen

Warum ist es wichtig, bei der Entwicklung eines Systems, das eine Datenbank (und insbesondere ein Warehouse) umfasst, auf den Entwurf von Datenmodellen zu achten? Warum nicht einfach überall ein Tischset aufstellen – sogar hinein Texteditor? Warum brauchen wir „diese Bilder“?
Seltsamerweise stellen selbst erfahrene Entwickler ähnliche Fragen.
Tatsächlich hindert Sie nichts daran, Tabellen zu skizzieren und mit deren Verwendung zu beginnen. Wenn... wenn gleichzeitig im Kopf (!) der Entwickler ein schlüssiges Gesamtbild der Struktur hat, die er modelliert. Was ist, wenn es mehrere Entwickler gibt? Was passiert, wenn jemand anderes diese Tabellen verwendet? Was passiert, wenn die Zeit vergeht – eine Person diesen Bereich verlässt und dann wieder dorthin zurückkehrt?

Ist es möglich, es ohne Modell herauszufinden? Im Prinzip ist es möglich. Und finden Sie es heraus und „finden Sie Bilder auf einem Blatt Papier heraus“ und „säubern und wählen Sie“ die Daten aus. Aber es ist viel einfacher, klarer und schneller, ein vorgefertigtes Artefakt zu verwenden – ein Datenmodell. Und auch die „Logik seiner Struktur“ verstehen – d.h. Es wäre schön, allgemeine Spielregeln zu haben.

Und das Wichtigste ist nicht einmal das. Das Wichtigste ist, dass wir beim Entwerfen eines Modells gezwungen sind (einfach ohne Optionen!), Das Themengebiet, die Merkmale der Datenstruktur und ihre Verwendung in verschiedenen Geschäftsfällen genauer und tiefer zu untersuchen. Und diese Fragen, die wir leicht als schwierig „beiseite schieben“ konnten, haben wir „verwischt“, indem wir unsere Zeichen hochgeworfen haben, ohne es wirklich zu versuchen Design Modell – wir werden gezwungen sein, es jetzt, während der Analyse und des Designs, einzurichten und zu entscheiden, und nicht später – wenn wir Berichte erstellen und darüber nachdenken, „wie wir das Unvereinbare zusammenbringen“ und „das Rad jedes Mal neu erfinden“ können.

Dieser Ansatz ist eine dieser technischen Praktiken, die es uns ermöglicht, antifragile Systeme zu erstellen. Da sie klar gestaltet, transparent und einfach zu entwickeln sind und ihre „Grenzen der Fragilität“ sofort sichtbar sind, können Sie das „Ausmaß der Katastrophe“ genauer einschätzen, wenn neue Anforderungen auftauchen, und die Zeit, die für eine Neugestaltung (falls erforderlich) erforderlich ist. .
Daher ist das Datenmodell eines der Hauptartefakte, die während der Entwicklung des Systems gepflegt werden müssen. Im positiven Sinne sollte es „auf dem Tisch“ jedes Analysten, Entwicklers usw. sein. – alle, die an Systementwicklungsprojekten beteiligt sind.

Das Entwerfen von Datenmodellen ist ein separates, sehr umfassendes Thema. Bei der Gestaltung von Lagereinrichtungen werden hauptsächlich zwei Ansätze verwendet.
Der Ansatz funktioniert gut für den Kernel „Entitätsbeziehung“ - wenn ein normalisiertes (3NF) Modell speziell auf der Grundlage der Untersuchung des Fachgebiets oder genauer gesagt des ausgewählten Bereichs erstellt wird. Hier kommt das gleiche „Unternehmensmodell“ zum Einsatz, wie oben beschrieben.

Geeignet für die Gestaltung analytischer Vitrinen mehrdimensionales Modell . Dieser Ansatz passt gut zum Verständnis der Business-Anwender – denn... Dies ist ein für die menschliche Wahrnehmung einfaches und praktisches Modell – Menschen arbeiten mit verständlichen und vertrauten Konzepten von Metriken (Indikatoren) und den Abschnitten, anhand derer sie analysiert werden. Dadurch können wir den Prozess der Anforderungserhebung einfach und klar strukturieren – wir erstellen eine Reihe von „Abschnitts- und Indikatorenmatrizen“ und kommunizieren mit Vertretern verschiedener Abteilungen. Und dann kombinieren wir sie zu einer Struktur – einem „Analysemodell“: Wir bilden einen „Messbus“ und ermitteln die darauf definierten Fakten. Nebenbei arbeiten wir an Hierarchien und Aggregationsregeln.

Dann ist es sehr einfach, zum physischen Modell überzugehen und Optimierungselemente unter Berücksichtigung der Merkmale des DBMS hinzuzufügen. Für Oracle ist dies beispielsweise eine Partitionierung, eine Reihe von Indizes usw. Für Vertica werden andere Techniken verwendet – Sortieren, Segmentieren, Partitionieren.
Möglicherweise ist auch eine spezielle Denormalisierung erforderlich – wenn wir absichtlich Redundanz in die Daten einführen, wodurch wir die Leistung von Abfragen verbessern, aber gleichzeitig die Aktualisierung der Daten erschweren (da die Redundanz während des Prozesses berücksichtigt und aufrechterhalten werden muss). Datenladevorgang). Um die Leistung zu verbessern, müssen wir möglicherweise auch zusätzliche Aggregattabellen erstellen oder zusätzliche DBMS-Funktionen wie Projektionen in Vertica verwenden.

Bei der Modellierung von Lagerdaten lösen wir also tatsächlich mehrere Probleme:

die Aufgabe, ein konzeptionelles (logisches) Modell des Kernels zu erstellen – System- und Geschäftsanalyse – Erforschung des Themenbereichs, Vertiefen in Details und Berücksichtigung der Nuancen von „Live-Daten“ und deren Verwendung in der Wirtschaft;
die Aufgabe, ein Analysemodell und anschließend ein konzeptionelles (logisches) Modell von Schaufenstern zu erstellen;
Die Aufgabe des Aufbaus physischer Modelle besteht darin, die Datenredundanz und die Optimierung unter Berücksichtigung der Funktionen des DBMS für Abfragen und Datenladen zu verwalten.

Bei der Entwicklung konzeptioneller Modelle berücksichtigen wir möglicherweise nicht die Merkmale des spezifischen DBMS, für das wir die Datenbankstruktur entwerfen. Darüber hinaus können wir ein konzeptionelles Modell verwenden, um mehrere physische Modelle zu erstellen – für verschiedene DBMS.

Fassen wir zusammen.

Ein Datenmodell besteht nicht aus einer Reihe „hübscher Bilder“, und der Prozess des Entwerfens ist nicht der Prozess des Zeichnens. Das Modell spiegelt unser Verständnis des Themengebiets wider. Und der Prozess der Zusammenstellung ist ein Prozess des Studiums und der Erforschung. Hier wird Zeit verschwendet. Und schon gar nicht, um „zu zeichnen und zu malen“.
Ein Datenmodell ist ein Projektartefakt, eine Möglichkeit, Informationen in strukturierter Form zwischen Teammitgliedern auszutauschen. Dazu muss es für jedermann verständlich (dies erfolgt durch Notation und Erläuterung) und zugänglich (veröffentlicht) sein.
Das Datenmodell wird nicht einmalig erstellt und eingefroren, sondern wird während der Entwicklung des Systems erstellt und weiterentwickelt. Wir selbst legen die Regeln für seine Entwicklung fest. Und wir können sie ändern, wenn wir sehen, wie wir sie besser, einfacher und effektiver machen können.
Das Datenmodell (physisch) ermöglicht die Konsolidierung und Nutzung eines Sets empfohlene Vorgehensweise, auf Optimierung ausgerichtet – d.h. Verwenden Sie die Techniken, die für dieses DBMS bereits funktioniert haben.

Merkmale von Data Warehouse-Projekten

Lassen Sie uns auf die Besonderheiten der Projekte eingehen, in denen das Unternehmen Data Warehouses aufbaut und entwickelt. Und betrachten wir sie unter dem Gesichtspunkt des Einflusses des architektonischen Aspekts. Warum ist es wichtig, Architektur für solche Projekte zu bauen, und zwar von Anfang an? Und es ist das Vorhandensein einer durchdachten Architektur, die einem Data-Warehouse-Projekt Flexibilität verleiht, eine effektive Arbeitsverteilung zwischen den Ausführenden ermöglicht und außerdem die Vorhersage des Ergebnisses erleichtert und den Prozess vorhersehbarer macht.

Data Warehouse ist kundenspezifische Software

Ein Data Warehouse ist immer eine „kundenspezifische Entwicklung“ und keine Paketlösung. Ja, es gibt branchenspezifische BI-Anwendungen, die ein Referenzdatenmodell, vorkonfigurierte ETL-Prozesse aus gängigen Quellen (z. B. ERP-Systemen) und eine Reihe standardmäßiger BI-Dashboards und -Berichte umfassen. Doch in der Praxis wird die Lagerung äußerst selten umgesetzt – als „Box“. Ich arbeite seit etwa 10 Jahren mit Lagereinrichtungen und habe noch nie eine solche Geschichte gesehen. Es gibt immer Nuancen, die mit den einzigartigen Merkmalen des Unternehmens verbunden sind – sowohl im Geschäfts- als auch im IT-Umfeld. Daher ist es etwas leichtsinnig zu hoffen, dass die Architektur von einem „Anbieter“ bereitgestellt wird, der die Lösung liefert. Die Architektur solcher Systeme „reift“ oft innerhalb der Organisation selbst. Oder es wird von Spezialisten des Auftragnehmerunternehmens gebildet, das der Hauptauftragnehmer des Projekts ist.

Data Warehouse ist ein Integrationsprojekt

Das Data Warehouse lädt und verarbeitet Informationen aus vielen Quellsystemen. Und um „freundschaftliche Beziehungen“ zu ihnen aufrechtzuerhalten, muss man ihnen gegenüber äußerst vorsichtig sein. Unter anderem ist es notwendig, die Belastung der Quellsysteme zu minimieren, die Fenster „Verfügbarkeit und Nichtverfügbarkeit“ zu berücksichtigen, Interaktionsschnittstellen unter Berücksichtigung ihrer Architektur auszuwählen usw. Dann hat der Speicher die Möglichkeit, Daten so früh wie möglich und in der erforderlichen Häufigkeit abzurufen. Andernfalls werden Sie auf eine Backup-Schaltung „übertragen“, die nicht mit der effizientesten Häufigkeit aktualisiert wird.
Darüber hinaus muss der „Faktor Mensch“ berücksichtigt werden. Bei der Integration geht es nicht nur um die Interaktion von Maschinen. Es ist auch Kommunikation zwischen Menschen.

Das Data Warehouse ist ein Teamprojekt

In einem großen Unternehmen kann ein solches System selten allein von einem Team implementiert werden. In der Regel arbeiten hier mehrere Teams, die jeweils ein bestimmtes Problem lösen.

Die Architektur muss die Möglichkeit bieten, ihre parallele Arbeit zu organisieren und gleichzeitig ihre Integrität zu wahren und die Duplizierung derselben Funktionalität an verschiedenen Orten und durch verschiedene Personen zu vermeiden. Zusätzlich zu unnötigen Arbeitskosten kann eine solche Duplizierung später zu Datendiskrepanzen führen.

Wenn außerdem so viele, oft unterschiedliche Personen und Teams in den Prozess der Systementwicklung involviert sind, stellt sich unweigerlich die Frage: Wie kann die Kommunikation und Informationsinteraktion zwischen ihnen aufgebaut werden? Je mehr standardisierte und verständliche Ansätze und Praktiken verwendet werden, desto einfacher, bequemer und effektiver kann diese Arbeit sein. Und es lohnt sich auch, über die Zusammensetzung der „Arbeitsartefakte“ nachzudenken, unter denen die Nummer 1 für Data Warehouses Datenmodelle sind (siehe vorheriger Abschnitt).

Das Data Warehouse hat im Vergleich zu anderen Systemen eine längere Lebensdauer

Lassen Sie mich das klarstellen: Die Aussage gilt für ein „lebendiges“, funktionierendes Lager, das in wichtige Quellen integriert ist, über historische Daten verfügt und Informations- und Analysedienste für viele Unternehmensbereiche bereitstellt.

Welchen Grund habe ich, das zu glauben?
Erstens ist der Bau eines Lagers ein sehr ressourcenintensiver Prozess: Neben den tatsächlichen Kosten für Ausrüstung, Lizenzen für die notwendige technologische Software und Entwicklung sind auch nahezu alle Systeme und Bereiche des Unternehmens daran beteiligt. Den gesamten Vorgang noch einmal von Grund auf zu wiederholen, ist ein sehr mutiges Unterfangen.

Zweitens: Wenn der Speicher über die richtige Architektur verfügt, kann er Änderungen in den Quellsystemen, das Aufkommen neuer Anforderungen von Endbenutzern und das Wachstum der Datenmengen problemlos überstehen.
Wenn die Architektur korrekt ist, Informationsflüsse transparent - dann kann ein solches System über einen langen Zeitraum hinweg entwickelt werden, ohne dass die Gefahr besteht, bei Änderungen aufgrund von Schwierigkeiten bei der Folgenabschätzung in eine Erstarrungssituation zu geraten.

Schrittweise iterative Entwicklung

Das Letzte, was der Kunde möchte, wenn er sich auf eine Speichersituation einlässt, ist, seine Anforderungen für ein oder zwei Jahre einzufrieren, während ein vollständiges Unternehmensdatenmodell entworfen wird, alle Quellen vollständig verbunden sind usw.

In den Augen der Kunden wirkt das Data Warehouse oft wie ein absolutes Monster – so umfangreich sind die Aufgaben, Ziele und der Entwicklungshorizont des Systems. Und oft hat der Kunde Angst, dass die IT-Abteilung „auf Kosten seines Budgets“ einige „eigene Probleme“ lösen wird. Und wieder stehen wir vor der Frage der Interaktion zwischen Menschen und der Fähigkeit, in Ruhe seine Position zu äußern und zu verhandeln.

Kompetente Architekturansätze ermöglichen es Ihnen, das System iterativ zu entwickeln und die Funktionalität schrittweise zu erhöhen, ohne mehrere Jahre in die „Entwicklung“ zu gehen, bevor Sie mit der Erzielung von Ergebnissen beginnen.

Wobei zu beachten ist, dass „Wunder nicht geschehen“ – und der „Anfang“ auch Zeit braucht. Bei Speichern kann es recht groß sein – da es sich um große Datenmengen handelt, es handelt sich um historische Daten – für alte Zeiträume, in denen die Regeln für die Verarbeitung von Informationen von den aktuellen abweichen können. Daher ist genügend Zeit für analytische Arbeiten, die Interaktion mit Quellsystemen und eine Reihe von „Versuchen und Irrtümern“ erforderlich, einschließlich Belastungstests mit realen Daten.

Data Warehouses – „Multiprojekthistorie“

Es ist schwierig, einen einzelnen Geschäftskunden für ein Data Warehouse zu identifizieren. Und es wird (nicht ohne Grund) angenommen, dass der Schlüsselfaktor für den Erfolg eines Lagerbauprojekts die Unterstützung durch die Unternehmensleitung ist – die erste Person direkt.
Speicher werden selten im Rahmen desselben Projekts gebaut und entwickelt. In der Regel gibt es unterschiedliche Anforderungen an die Datenkonsolidierung und -analyse, hinter denen unterschiedliche Kunden und Benutzergruppen stehen. Daher wird das Repositorium häufig im Rahmen mehrerer paralleler Projekte entwickelt.

Balance aus Innovation und bewährten Lösungen

Dabei ist das Thema Speicher sehr „alt“ (sofern ein solches Wort auf eine so junge Branche wie die IT zutrifft) und recht konservativ. Doch der Fortschritt steht nicht still – und die bisherigen Einschränkungen durch teure und langsame Festplatten, teuren Speicher etc. – wurden inzwischen entfernt. Gleichzeitig ist es an der Zeit, einige architektonische Ansätze zu überdenken. Darüber hinaus gilt dies sowohl für Technologieplattformen als auch für die Architektur darauf basierender Anwendungssysteme.

Hier gilt es, ein Gleichgewicht zu wahren – und einen einigermaßen „ökologischen“ Umgang sowohl mit den Ressourcen als auch mit den gespeicherten Informationen beizubehalten. Ansonsten kann man den Speicher sehr schnell in eine schwach strukturierte „Mülldeponie“ verwandeln, was, wenn man ihn entsorgen kann, mit ziemlichem Aufwand zu bewerkstelligen ist.
Ja, wir haben mehr Möglichkeiten, aber das bedeutet nicht, dass wir alle etablierten und bewährten Praktiken leugnen müssen, bei denen klar ist, wie und warum sie anzuwenden sind, und „große Anstrengungen unternehmen“ müssen, nur geleitet von dem nebligen Gespenst der „Innovation“. ”
Das Gleichgewicht zu wahren bedeutet, neue Methoden und Ansätze dort einzusetzen, wo sie neue Möglichkeiten eröffnen, gleichzeitig aber auch Altbewährtes zu nutzen, um drängende Probleme zu lösen, die nicht aufgehoben wurden.
Was können wir als Entwickler und Designer von Anwendungslösungen tun? Zunächst einmal müssen Sie die technologischen Veränderungen der Plattformen, auf denen wir arbeiten, sowie deren Fähigkeiten, Funktionen und Anwendungsgrenzen kennen und verstehen.

Schauen wir uns das DBMS an – als die kritischste und wichtigste Technologieplattform für die Speicherung.
In jüngster Zeit ist bei relationalen Datenbanken, die ursprünglich als „universell“ konzipiert wurden, eine deutliche Tendenz zur Spezialisierung zu beobachten. Führende Anbieter veröffentlichen seit langem verschiedene Optionen für Anwendungen unterschiedlicher Klassen (OLTP, DSS & DWH). Darüber hinaus ergeben sich zusätzliche Möglichkeiten für die Arbeit mit Text, Geodaten etc.

Aber die Sache beschränkte sich nicht darauf – es tauchten Produkte auf, die zunächst auf eine bestimmte Aufgabenklasse ausgerichtet waren – d.h. spezialisiertes DBMS. Sie können das relationale Modell verwenden oder auch nicht. Wichtig ist, dass sie zunächst nicht nur für die Speicherung und Verarbeitung von „Geschäftsinformationen“ im Allgemeinen, sondern für bestimmte Aufgaben „zugeschnitten“ sind.

Anscheinend sind Zentralisierung und Spezialisierung zwei komplementäre Trends, die sich regelmäßig gegenseitig ersetzen und so für Entwicklung und Ausgewogenheit sorgen. Sowie evolutionäre (allmähliche) allmähliche Entwicklung und dramatische Veränderungen. So war Michael Stonebraker in den 90er Jahren einer der Autoren des Generation III Database Manifesto, das klar zum Ausdruck brachte, dass die Welt keine weitere Revolution in der Welt der Datenbanken braucht. Doch 10 Jahre später veröffentlicht er Werke, in denen er – gerade aufgrund ihrer Spezialisierung – die Voraussetzungen für den Beginn einer neuen Ära in der Welt der DBMS ankündigt.
Er konzentriert sich auf die Tatsache, dass gängige universelle DBMS auf einer „one-size-fits-all“-Architektur basieren, die weder Änderungen bei Hardwareplattformen noch die Aufteilung von Anwendungen in mögliche Klassen berücksichtigt mit mehr optimale Lösung anstatt universelle Anforderungen umzusetzen.
Und er beginnt, nach dieser Idee eine Reihe von Projekten zu entwickeln. Eines davon ist C-Store – ein spaltenorientiertes DBMS, das auf der Shared Nothing (SN)-Architektur basiert und ursprünglich speziell für Data-Warehouse-Klassensysteme entwickelt wurde. Dieses Produkt wurde als HP Vertica kommerziell weiterentwickelt.

Epilog

„Das Einzigartige an der Antifragilität ist, dass sie es uns ermöglicht, mit dem Unbekannten zu arbeiten, etwas unter Bedingungen zu tun, in denen wir nicht verstehen, was wir tun, und Erfolg zu haben.“/Nassim N. Taleb/

Daher sind die Krise und ein hohes Maß an Unsicherheit keine Entschuldigung für den Mangel an Architektur, sondern Faktoren, die deren Bedarf verstärken.

In Verbindung stehende Artikel:
Warum lohnt es sich, den Standard zu ändern? Typischerweise ist eine Anwendung zum Tätigen von Anrufen in verschiedenen Modellen... Unterschied zwischen Daten und Informationen Informationen sind Informationen über etwas. Konzept und Arten von Informationen, Übermittlung... Was ist Android und warum wird es benötigt? Dieser Artikel richtet sich an Benutzer, die zum ersten Mal...

Unternehmensdatenbanken. Erstellen eines Data-Warehouse-Modells basierend auf dem Unternehmensdatenmodell von Informations- und Referenzsystemen

Das Senden Ihrer guten Arbeit an die Wissensdatenbank ist ganz einfach. Nutzen Sie das untenstehende Formular

1. Relationales Datenmodell

2. Unternehmensinformationssysteme

relationales Modelldatensystem

1. Systemelement – ​​Teil des Systems, der einen bestimmten funktionalen Zweck hat. Komplexe Elemente von Systemen, die wiederum aus einfacheren miteinander verbundenen Elementen bestehen, werden oft als Subsysteme bezeichnet.

2. Organisation des Systems – innere Ordnung, Konsistenz im Zusammenspiel der Systemelemente, die sich insbesondere in der Begrenzung der Zustandsvielfalt der Elemente innerhalb des Systems äußert.

4. Die Systemarchitektur ist eine Reihe von Systemeigenschaften, die für den Benutzer wichtig sind.

Ein Informationssystem ist eine miteinander verbundene Reihe von Mitteln, Methoden und Personal, die zur Speicherung, Verarbeitung und Ausgabe von Informationen im Interesse der Erreichung eines festgelegten Ziels eingesetzt werden.“

Das Bundesgesetz „Über Information, Informatisierung und Informationsschutz“ gibt folgende Definition:

„Ein Informationssystem ist ein organisatorisch geordneter Satz von Dokumenten (Arrays von Dokumenten) und Informationstechnologien, einschließlich der Verwendung von Computertechnologie und Kommunikation, die Informationsprozesse implementieren.“

Klassifizierung nach Maßstab

Informationssysteme werden je nach Maßstab in die folgenden Gruppen eingeteilt:

* einzel;

* Gruppe;

* Unternehmen.

Ein Unternehmensinformationssystem ist ein skalierbares System zur umfassenden Automatisierung aller Arten wirtschaftlicher Aktivitäten großer und mittlerer Unternehmen, einschließlich Konzernen, die aus einer Gruppe von Unternehmen bestehen, die eine einheitliche Verwaltung erfordern.

Unter einem Unternehmensinformationssystem versteht man ein System, das mehr als 80 % der Unternehmensbereiche automatisiert.

Bei Konzern- und Unternehmenssystemen steigen die Anforderungen an zuverlässigen Betrieb und Datensicherheit deutlich. Diese Eigenschaften werden durch die Aufrechterhaltung der Integrität von Daten, Links und Transaktionen in Datenbankservern bereitgestellt.

Einteilung nach Anwendungsgebiet

Je nach Anwendungsbereich werden Informationssysteme üblicherweise in vier Gruppen eingeteilt:

* Transaktionsverarbeitungssysteme;

* Entscheidungssysteme;

* Informations- und Referenzsysteme;

* Büroinformationssysteme.

Literaturverzeichnis

Ähnliche Dokumente

Epilog

Branchendatenmodelle

Veröffentlichungen

THEMA V. UNTERNEHMENSDATENBANKEN

Unternehmensdatenmodell

Einführung

Unternehmensdatenmodell

Darstellungsebenen des Unternehmensdatenmodells

„Das Märchen ist eine Lüge – aber es steckt ein Hinweis darin …“

Nachbesprechung

Antifragilität

Was ist ein Data Warehouse und warum bauen wir es?

Hauptmerkmale von Data Warehouses

Architekturkonzept

Systemkern

Speicherkernmodell und Unternehmensdatenmodell

Primäre Datenschicht (oder historisierte Staging- oder Betriebsschicht)

Analytische Schaufensterebene

Serviceschicht

Design und Pflege von Lagerdatenmodellen

Merkmale von Data Warehouse-Projekten

Data Warehouse ist kundenspezifische Software

Data Warehouse ist ein Integrationsprojekt

Das Data Warehouse ist ein Teamprojekt

Das Data Warehouse hat im Vergleich zu anderen Systemen eine längere Lebensdauer

Schrittweise iterative Entwicklung

Data Warehouses – „Multiprojekthistorie“

Balance aus Innovation und bewährten Lösungen

Epilog

1. Systemelement – Teil des Systems, der einen bestimmten funktionalen Zweck hat. Komplexe Elemente von Systemen, die wiederum aus einfacheren miteinander verbundenen Elementen bestehen, werden oft als Subsysteme bezeichnet.