|
> Verzeichnis der Dokumente mit den theoretischen Grundlagen |
|
Letzte
Bearbeitung dieses Dokuments: |
Voraussetzungen für das Verständnis dieses Dokuments:* Kenntnisse über
relationale Datenbanken. |
Ungefährer Zeitbedarf zum Durcharbeiten dieses Dokuments:Das
ist ein Dokument zur Erklärung des theoretischen
Hintergrundes über das Konzept von Business-Objects
(Geschäfts-Objekten), die Daten aus mehreren
Datenbank-Tabellen zusammenfassen. |
Dieses Dokument gibt einen Überblick wozu ein Business-Object (BO) sinnvoll verwendet werden kann.
Ein
BO enthält eine Datenstruktur in der Form, wie sie bei der
Abwicklung eines Geschäftsfalles sinnvoll angewendet werden
kann.
Das bedeutet, daß die Daten aus mehreren
Datenbank-Tabellen im BO zusammengefaßt sind.
Als
Beispiel für die Erklärungen in diesem Dokument wird die
'Rechnung' verwendet.
Dies deswegen, weil sich die Daten einer
Rechnung nicht in einer Datenbank-Tabelle abbilden lassen ohne alle
Regeln für den Entwurf relationaler Datenbanken zu verletzen.
Vorbedingungen
Warum
ist die Verwendung von BO (Business-Objects) sinnvoll ?
* Warum
nicht gleich Objekt-Datenbanken (statt relationale Datenbanken)
?
* BO können
Methoden enthalten, die die Datenintegrität prüfen
* Java
kann die komplexe Struktur eines BO über ein Netzwerk
übertragen
Wie
werden die Daten eines BO über das Netzwerk 'kopiert'
Weitere
Schritte und verwandte Dokumentation
Keine speziellen; Sie sollten aber Grundkenntnisse über den Entwurf von relationalen Datenbank-Tabellen und die Variablen und Methoden in Java-Klassen haben.
. . . . und nicht die Verwendung von 'Etwas', das mehr Rücksicht auf die entworfenen Datenbank-Tabellen nimmt ?
Tabellen in relationalen Datenbanken müssen – grob gesprochen - den Regeln folgen, daß der Wert von Attributen, die nicht als Schlüssel definiert sind, eindeutig von dem jeweiligen Schlüssel abhängen und die Kombination der Werte, die den Schlüssel bilden, nur einmal vorkommen darf.
Am Beispiel einer Rechnung:
Für eine Position der Rechnung besteht der Schlüssel aus Rechnungsnummer und Positionsnummer – und diese Kombination darf innerhalb des gesamten Unternehmens nur einmal vorkommen.
Daten, die für die gesamte Rechnung gelten, z.B. Name und Anschrift des Rechnungsempfängers, sind aber nur von der Rechnungsnummer abhängig und Ändern sich nicht für jede Position.
Für
jemanden, der im Entwurf von relationalen Datenbanken geübt
ist, ist klar erkennbar, daß für die 'Rechnungen' eines
Unternehmens mindestens zwei Datenbank-Tabellen notwendig sind:
*
Eine Tabelle mit den 'Rechnungs-Köpfen', die mindestens
Rechnungsnummer und Name und Anschrift des Rechnungsempfängers
enthalten.
* Eine Tabelle mit den 'Rechnungs-Positionen', die
Informationen über das Produkt und den geforderten Betrag
enthalten.
Die Grafik zeigt, in welchen Datenbank-Tabellen die Daten für ein einfaches BO für eine 'Rechnung' gehalten werden.
Mit der Weiterentwicklung und Einsatzreife objekt-orientierter Datenbanken stellen Sie sich vielleicht jetzt die Frage, warum überhaupt BO entworfen werden sollen.
Ich will Ihnen nicht abraten, gleich eine objekt-orientierte Datenbank einzusetzen – aber einige Überlegungen auflisten, die Sie bei der Entscheidung berücksichtigen sollten.
Objekt-Orientierte
Datenbanken sind nicht für jedes Betriebssystem erhältlich.
Die
Hersteller dieser Datenbanken konzentrieren sich auf die populärsten
Betriebssysteme.
Wenn Sie Standard-Software herstellen, hat ihr
Kunde vielleicht ein System im Einsatz für das es keine Version
der verwendeten objekt-orientierten Datenbank gibt.
Auch bei der
Entwicklung individueller Software könnten Sie vielleicht in
Zukunft einmal ein anderes Betriebssystem verwenden wollen.
Java
würde darauf laufen, ein relationales Datenbanksystem mit
normierten SQL-Kommandos würde verfügbar sein – aber
gerade das objekt-orientierte Datenbanksystem ist für das
gewünschte Betriebssystem nicht verfügbar.
Objekt-orientierte
Datanbanksysteme haben (noch) keinen normierten Befehlssatz.
Zum
Zeitpunkt der Erstellung dieses Dokumentes (März 2007) hatte
jeder Hersteller eigene Erweiterungen des Befehlssatzes.
Damit
muß bei der Entwicklung darauf Rücksicht genommen werden,
daß keine Hersteller-spezifischen Befehle verwendet werden
oder das Applikationsprogramm ist an das einmal gewählte
objekt-orientierte Datenbanksystem gebunden.
In den BO können Methoden programmiert werden die komplexe Prüfungen auf Datenintegrität durchführen können.
Zum
Beispiel kann beim Löschen eines Produktes geprüft
werden, ob eine Bestellung für dieses Produkt an einen
Lieferanten gesendet wurde.
In diesem Fall kann das Löschen
verweigert werden solange die Bestellung nicht storniert wurde.
Ähnliche
Prüfungen sind auch über 'Stored Procedures' bei
relationalen Datenbanken möglich.
Ich persönlich habe
aber die Erfahrung gemacht, daß die Suche von Fehler in 'Stored
Procedures' ungleich schwieriger ist als das 'Debuggen' einer Methode
in einem BO.
Java
hat die Fähigkeit, ein beliebig aufgebautes Java-Objekt (und
damit auch ein Objekt einer BO-Klasse) über ein Netzwerk mit
TCP/IP-Protokoll zu übertragen.
Diese Technologie von Java
wird als RMI (Remote Management Invocation) bezeichnet.
Die
Methoden von RMI müssen aber nie explizit aufgerufen werden –
sie sind in den Klassen für das Aufrufen von EJB (Enterprise
Java Beans) enthalten.
Die graphische Darstellung eines Beispiels zeigt, wie die Variationen eines BO auf Client- und Server-Seite zusammen arbeiten.
Zuerst das Abfragen von Daten:
Dann das Ändern von Daten:
Java bietet mit der Remote Management Invocation (RMI) die Möglichkeit, ganze Objekte über ein TCP/IP-Netzwerk zu übertragen und eine Methode auf dem entfernten Computer auszuführen.
Diese Möglichkeit wird genutzt, um beim Lesen von Daten das passende BO auf der Server-Seite zu konstruieren, die Methode zur Abfrage auf der Datenbank aufzurufen und dann den jenen geerbten Teil des BO, der hauptsächlich die Variablen mit den Werten enthält (General Class) auf die Client-Seite zu übertragen und die Daten auf das BO der Client-Seite zu übertragen.
Beim Schreiben passiert das Übertragen der Daten in der Gegenrichtung (Client-Seite zu Server-Seite) und dann wird beim passenden BO auf der Server-Seite die Methode zum Ändern der Daten auf der Datenbank aufgerufen.
Hier
eine schematische Darstellung der Zusammenarbeit der verschiedenen
abgeleiteten Arten der Business Objekte.
Kursiv
geschriebene Teile der Klassen-Namen sind symbolische Namen und
werden durch den Namen der Anwendung (app)
und den Namen des BO (entity)
ersetzt.
|
Dokument |
Inhalt |
|
Liste der Dokumente mit detaillierten Beschreibungen. |