DE102010010035A1 - Verfahren zum Erstellen von Objekten einer objektorientierten Datenbank - Google Patents

Verfahren zum Erstellen von Objekten einer objektorientierten Datenbank Download PDF

Info

Publication number
DE102010010035A1
DE102010010035A1 DE102010010035A DE102010010035A DE102010010035A1 DE 102010010035 A1 DE102010010035 A1 DE 102010010035A1 DE 102010010035 A DE102010010035 A DE 102010010035A DE 102010010035 A DE102010010035 A DE 102010010035A DE 102010010035 A1 DE102010010035 A1 DE 102010010035A1
Authority
DE
Germany
Prior art keywords
relations
objects
relation
way
placeholders
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE102010010035A
Other languages
English (en)
Inventor
Michael Veigl
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG Oesterreich
Original Assignee
Siemens AG Oesterreich
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG Oesterreich filed Critical Siemens AG Oesterreich
Priority to DE102010010035A priority Critical patent/DE102010010035A1/de
Publication of DE102010010035A1 publication Critical patent/DE102010010035A1/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/289Object oriented databases

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Erstellen von Objekten (O1) einer objektorientierten Datenbank. Dabei weist ein Objekt (O1) zumindest eine Relation (C1, C2, C3, R1, R2) zu zumindest einem anderen Objekt (K1, K2, TO, P) auf. Diese Relation (C1, C2, C3, R1, R2) kann als sogenannte Containment-Relation (C1, C2, C3) oder als einseitige Relation (R1) oder als beidseitige Relation (R2) ausgestaltet sein. Zum Erstellen von neuen Objekten (Ob1) werden dabei aus bestehenden Objekten (O1) Objektvorlagen (T) generiert (1 bis 6), in welchen Informationen über jeweils enthaltene Objekte (K1, K2) und die zugehörigen Containment-Relationen (C2, C3) sowie einseitige Relationen (R1) abgespeichert werden (2, 3, 4). Weiters werden in den Objektvorlagen (T) die beidseitigen Relationen (R2) durch Platzhalter (PH) ersetzt. Beim Erstellen von neuen Objekten (Ob1) werden dann die generierten Objektvorlagen (T) herangezogen (7 bis 12). Dabei werden auf Basis der in den Objektvorlagen (T) hinterlegten Informationen die jeweils enthaltenen Objekte (K1b, K2b) mit den zugehörigen Containment-Relationen (C2b, C3b) sowie die einseitigen Relationen (R1b) generiert (8, 9, 10) und die Platzhalter (PH) werden aufgelöst und wieder durch die entsprechenden beidseitigen Relationen (R2b) ersetzt (11). Durch das erfindungsgemäße Verfahren werden auf einfache Weise Arbeitsaufwand und Fehlerhäufigkeit beim Erstellen von Objektvorlagen (T) und neuen Objekten (Ob1) auf Basis dieser Objektvorlagen (T) erheblich reduziert.

Description

  • Technisches Gebiet
  • Die vorliegende Erfindung bezieht sich allgemein auf das Gebiet der objektorientierten Datenbank. Insbesondere betrifft die vorliegende Erfindung ein Verfahren zum Erstellen von Objekten für eine derartige Datenbank, wobei ein Objekt der objektorientierten Datenbank zumindest eine Relation zu zumindest einem anderen Objekt dieser Datenbank aufweisen kann. Relationen zwischen Objekten können dabei als sogenannte Containment-Relationen, als einseitige Relationen oder als beidseitige Relationen ausgestaltet sein.
  • Stand der Technik
  • In der Informationstechnik wird unter dem Begriff „Objektorientierung” bzw. „objektorientiert” üblicherweise eine Sichtweise auf komplexe Systeme (z. B. Kommunikationsprogramme, Datenbanken, etc.) verstanden, bei welcher ein derartiges System durch ein Zusammenspiel kooperierender bzw. kommunizierender Objekte beschrieben wird. Die Objektorientierung wird heute hauptsächlich im Bereich der sogenannten objektorientierten Programmierung sowie bei objektorientierten Datenbanken, welche häufig einer objektorientierten Programmierung zugrunde liegen, angewandt, insbesondere um eine Komplexität von entstehenden Programmen und/oder Datenbankstrukturen zu verringern.
  • Grundlegender Gedanke bei der Objektorientierung ist beispielsweise, dass sich Einheiten (z. B. Datenstrukturen, Dateien, Vorgänge, etc.) nicht nur über Daten oder anders geartete Parameter der verschiedensten Art definieren, sondern auch über Eigenschaften, sogenannte Attribute. Beides zusammen – d. h. eine Einheit sowie ihre Eigenschaften – werden dann als Objekt bezeichnet. Der Begriff „Objekt” beschreibt damit eine Einheit (z. B. Datenstrukturen, Dateien, Vorgänge, etc.) sowie ihre Eigenschaften, durch welche festgelegt wird, was mit einem Objekt bzw. dessen Daten geschehen kann. Dem Objekt sind zusätzlich auch sogenannte Methoden zugeordnet, durch welche ein Verhalten des Objekts definiert wird. Ein Objekt im Rahmen der Objektorientierung stellt damit Daten und Funktionen mit eindeutig definierbaren Eigenschaften und zugeordneten Methoden dar, welche daher in der Lage ist, von anderen Objekten Nachrichten zu empfangen bzw. an andere Objekt Nachrichten zu senden. Gleichartige Objekte – d. h. Objekte mit gleichen Eigenschaften und Methoden – werden dann in sogenannten Klassen zusammengefasst, wobei von allen Objekten einer Klasse die dieser Klasse zugeordneten Methoden genutzt werden können.
  • Innerhalb von Anwendungen stehen Objekte nicht allein, sondern können Beziehungen, so genannte Relationen, zu anderen Objekten aufweisen. Damit können mittels der Relationen aus mehreren einfachen Objekten komplexe Objekte, so genannte Aggregationen, für Anwendungen erzeugt werden. Dabei können die einzelnen Objekte bzw. Teile, welche ein komplexes Objekt bilden, in unterschiedlichen Beziehungen bzw. Relationen zueinander stehen.
  • Bei komplexen Objekten bzw. Aggregationen werden daher beispielsweise verschiedene Arten von Relationen unterschieden. Eine Relation, von welcher eine sogenannte Teil-von- bzw. Besteht-aus-Beziehung beschrieben wird, wird auch als so genannte Containment-Relation bezeichnet. Das bedeutet, ein komplexes Objekt kann beispielsweise eines oder mehrere Objekte eines bestimmten Typs enthalten, auf welche die Containment-Relation verweist. Von einer Containment-Relation wird damit ein physisches Enthaltensein eines Objekts in einem anderen Objekt beschrieben.
  • Eine weitere Art einer Relation stellt die so genannte einseitige Relation dar. Bei einer einseitigen Relation ist die Beziehung zwischen zumindest zwei Objekte nur in eine Richtung lesbar. D. h. ein Typobjekt, von welchem beispielsweise Eigenschaften oder Informationen für mehrere Objekte einer Anwendung zur Verfügung gestellt werden, existiert für diese Anwendung nur einmal. Es können aber alle Objekte, die diesen Typ aufweisen, mit diesem Typobjekt mittels der einseitigen Relation verbunden werden. Den Objekten, welche mittels der einseitigen Relation z. B. auf das Typobjekt verweisen, ist das Typobjekt bekannt. Vom Typobjekt kann allerdings nicht festgestellt werden, welche Objekte bzw. wie viele Objekte mit ihm eine Relation aufweisen.
  • Neben einseitigen Relationen können bei komplexen Objekten und/oder in Anwendungen auch so genannte beidseitige Relationen eingesetzt werden. Dabei handelt es sich beispielsweise um Verweise von Objekten auf andere Objekte, von welchen eine Menge repräsentiert wird (z. B. elektrische Module – Modulpool, Buch – Bibliothek, etc.). D. h. ein Objekt einer bestimmten Klasse ist genau einem anderen Objekt, welches eine Menge bzw. einen Pool für Objekte dieser Klasse repräsentiert, zugeordnet. Von diesem Mengen-Objekt kann aber auf ein oder mehrere Objekte dieser Klasse verwiesen werden, wobei dem Mengen-Objekt alle Objekte, welche seiner Menge angehören bzw. die auf es verweisen, bekannt sind.
  • Um das Erstellen von neuen Objekten, insbesondere von komplexen bzw. stark vernetzten Objekten zu vereinfachen, werden üblicherweise Objektvorlagen, sogenannte Templates, eingesetzt. Derartige Templates werden beispielsweise aus bereits bestehenden Objekten abgeleitet. Objektvorlagen oder Templates stellen üblicherweise Schablonen bzw. Gerüste dar, welche einen Teil des Inhalts oder der Gestaltung des neuen Objekts bereits vorgeben. Durch Einsetzen und/oder Ergänzen von fehlenden Bestandteilen wird dann aus der Objektvorlage ein neues Objekt, welches dem ursprünglichen, existierenden Objekt weitgehend entspricht und wie dieses von der jeweiligen Anwendung verwendet werden kann.
  • Derzeit werden Objektvorlagen für komplexe Objekte beispielsweise durch einen Anwender auf Basis bereits existierender Objekt händisch erstellt. Eine derartige Vorgehensweise weist allerdings den Nachteil auf, dass sie relativ zeitaufwändig und fehleranfällig ist. Denn das existierende Objekt muss zuerst genau analysiert und dann durch den Anwender die entsprechenden Komponenten und Relationen für die Objektvorlage kopiert und/oder nachgebaut werden. Dabei besteht auch die Gefahr, dass Komponenten und/oder Beziehungen – insbesondere bei komplexen bzw. stark vernetzten Objektvorlagen – vergessen oder übersehen werden.
  • Eine weitere Methode um komplexe Objektvorlagen zu generieren, ist beispielsweise ein Importieren von Objektvorlagen mittels einer Importfunktion aus externen Datei bzw. anderen Anwendungen. Auch in diesem Fall müssen die importierten Objektvorlagen auf die Gegebenheiten der jeweiligen Anwendung – meist händisch durch den Anwender – angepasst werden. Insbesondere können Verknüpfungen bzw. Relationen mit anderen Objekten eines neuen, mittels Templates erzeugten Objekts z. B. nur manuell durch den Anwender durchgeführt werden. Dadurch kann es ebenfalls zu Fehler wie z. B. vergessenen oder falsch erzeugten Relationen kommen, durch welche letztendlich Fehler in einer Anwendung oder Datenbank erzeugt werden.
  • Darstellung der Erfindung
  • Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren zum Erstellen von Objekten einer objektorientierten Datenbank anzugeben, bei welchen auf einfache Weise Aufwand, Fehlerwahrscheinlichkeit und eine Anzahl an Arbeitsschritten beim Erstellen von neuen Objekten reduziert wird.
  • Die Lösung dieser Aufgabe erfolgt durch ein Verfahren der eingangs angegebenen Art, wobei aus bestehenden Objekten Objektvorlagen generiert werden, in welchen Informationen über jeweils enthaltene Objekte und die zugehörigen Containment-Relationen sowie einseitige Relationen abgespeichert und in welchen die beidseitigen Relationen durch Platzhalter ersetzt werden. Für ein Erstellen von neuen Objekten werden dann die derart erstellten Objektvorlagen herangezogen, wobei auf Basis der in den Objektvorlagen hinterlegten Informationen die jeweils enthaltenen Objekte mit den zugehörigen Containment-Relationen sowie die einseitigen Relationen generiert und dann die Platzhalter für beidseitige Relationen durch die entsprechenden beidseitigen Relationen ersetzt werden.
  • Der Hauptaspekt der erfindungsgemäß vorgeschlagenen Lösung besteht darin, dass auf Basis einfacher und durch den Anwender definierbarer Regeln, aus einem Objekt, insbesondere einem komplexen und/oder stark vernetzten Objekt, eine Objektvorlage generiert wird, aus welcher auf einfache Weise neue Objekte erzeugt werden können. Durch die Regeln kann beispielsweise festgelegt werden, welche Komponenten (d. h. Objekte) des bestehenden Objekts zu einer Objektvorlage gehören und wie mit den Relationen umgegangen werden soll. Dadurch wird auf einfache Weise der manuelle Aufwand und die Fehlerwahrscheinlichkeit beim Erzeugen der Objektvorlagen sowie beim Generieren eines neuen Objekts reduziert, insbesondere da die Regeln nur einmal für ein existierendes Objekt erstellt werden müssen. Eine komplette Objektvorlage kann dann in einem Arbeitsschritt vom Anwender aus diesem vorhandenen Objekt erstellt werden, wobei durch ein Ersetzen der beiseitigen Relationen durch Platzhalter ein Kopieren von einer Vielzahl von Objekten verhindert wird.
  • Weiters bestimmen die definierbaren Regeln auch ein Ableiten eines neuen Objekts aus der Objektvorlage. Dadurch werden ebenfalls der Arbeitsaufwand sowie die Wahrscheinlichkeit reduziert, dass beispielsweise Relationen vergessen oder falsch erzeugt werden. Einen zusätzlichen Vorteil des erfindungsgemäßen Verfahrens stellt die Möglichkeit dar, die Regeln zum Generieren der Objektvorlage bzw. des neuen Objekts rasch an geänderte Anforderungen anpassen zu können.
  • Zur Lösung der Aufgabe ist auch vorgesehen, dass für ein Generieren der Objektvorlagen aus bestehenden Objekten zuerst in den bestehenden Objekten enthaltene Objekte sowie die zugehörigen Containment-Relationen kopiert und gespeichert werden. Dann werden die einseitige Relationen kopiert und gespeichert und zuletzt die kopierten beidseitigen Relationen der bestehenden Objekte aufgelöst und durch Platzhalter ersetzt, durch welche die beidseitigen Relationen beschrieben werden.
  • Der Vorteil dieser Ausgestaltung des erfindungsgemäßen Verfahrens besteht darin, dass anhand einfacher Regeln bestimmt wird, welche Objekte des existierenden Objekts zur zu generierenden Objektvorlage gehören. Zusätzlich wird eine einfache Handhabung der jeweiligen im existierenden Objekt vorkommenden Relationen definiert. Dadurch kann eine Objektvorlage mit sehr geringem Aufwand – beispielsweise in einem Arbeitsschritt – von einem vorhandenen Objekt abgeleitet werden, ohne dass vom Anwender einzelne Objekte der Objektvorlage manuell erstellt werden müssen.
  • Eine zweckmäßige Ausgestaltung der Erfindung sieht auch vor, dass für ein Erstellen von neuen Objekten auf Basis der generierten Objektvorlagen zuerst die enthaltenen Objekte sowie die zugehörigen Containment-Relationen kopiert werden. Dann werden auf Basis der Objektvorlagen die einseitigen Relationen erzeugt und danach die in den Platzhaltern abgelegten Informationen derart aufgelöst, dass die entsprechenden beidseitigen Relationen erzeugt werden.
  • Dabei wird vorteilhafter Weise von definierbaren Regeln festgelegt, welche Objekte der Objektvorlage Bestandteil des neuen Objekts sind und welche Relationen im neuen Objekt zu erstellen sind. Insbesondere beidseitige Relationen können mit Hilfe der Information in den Platzhaltern erzeugt werden. Dadurch wird, insbesondere bei stark vernetzten Objekten, einerseits der manuelle Aufwand stark vermindert und andererseits vermieden, dass Relationen in neuen Objekten vergessen und/oder falsch erzeugt werden.
  • Es ist auch vorteilhaft, wenn die Platzhalter für beidseitige Relationen als sogenannte Relationsobjekte ausgestaltet werden, in welchen Schlüssel zum Auffinden von Zielobjekten für die beidseitigen Relationen hinterlegt werden. Dabei ist es auch günstig, wenn die Schlüssel zum Auffinden der Zielobjekte als sogenannte Attribute in den jeweiligen Relationsobjekten hinterlegt werden. Durch eine Gestaltung der Platzhalter als Relationsobjekte können auf einfache Weise die Informationen für beidseitige Relationen in Objektvorlagen beschrieben und hinterlegt werden. Beim Erstellen eines neuen Objekts auf Basis der Objektvorlage können die Relationsobjekte ebenfalls mittels einfacher Regeln aufgelöst und die beidseitigen Relationen wieder hergestellt werden.
  • Bei einer bevorzugten Fortbildung der Erfindung ist auch vorgesehen, dass beim Erzeugen von beidseitigen Relationen in neuen Objekten zuerst aus den Platzhaltern die entsprechenden Zielobjekte für die beidseitigen Relationen ermittelt werden, und dass dann die entsprechenden, zugehörigen beidseitigen Relation zu den Zielobjekten erzeugt werden. Damit wird auf einfache Weise festgelegt, welche beidseitigen Relationen in neuen Objekten zu bestimmten Zielobjekten hergestellt werden sollen, ohne dass Relationen vergessen oder falsch erzeugt werden.
  • Kurzbeschreibung der Zeichnung
  • Die Erfindung wird nachfolgend in beispielhafter Weise anhand der beigefügten Figuren erläutert. Die Figuren zeigen beispielhaft und schematisch:
  • 1 den Ablauf des erfindungsgemäßen Verfahrens zum Erstellen von Objekten einer objektorientierten Datenbank
  • 2a ein Generieren einer Objektvorlage aus einem beispielhaften, existierenden Objekt
  • 2b ein Erstellen eines beispielhaften, neuen Objekts auf Basis der generierten Objektvorlage
  • Ausführung der Erfindung
  • In 1 ist beispielhaft in schematischer und vereinfachter Weise ein Ablauf des erfindungsgemäßen Verfahrens dargestellt. Dabei kann das erfindungsgemäße Verfahren zum Erstellen von Objekten einer objektorientierten Datenbank beispielsweise in zwei Abschnitte unterteilt werden. In einem ersten Abschnitt werden auf Basis existierenden Objekte, welche insbesondere komplex bzw. stark vernetzt sind, Objektvorlagen generiert. In einem zweiten Abschnitt werden dann auf Basis der erzeugten Objektvorlagen neue Objekte z. B. für Anwendungen hergestellt.
  • Das erfindungsgemäße Verfahren bzw. der erste Abschnitt des Verfahrens beginnt mit einem ersten Verfahrensschritt 1 zum Erstellen von Objektvorlagen. Dabei wird im ersten Verfahrensschritt 1, der auch den Startschritt des Verfahrens darstellt, beispielsweise von in einer Anwendung existierenden Objekten ausgegangen. Diese Objekte weisen üblicherweise Relationen auf, welche als sogenannte Containment-Relationen, einseitige Relationen oder als beidseitige Relationen ausgestaltet sein können. Über die sogenannten Containment-Relationen können die Objekte weitere – meist einfache – Objekte enthalten.
  • In einem zweiten Verfahrensschritt 2 werden dann für die jeweiligen Objektvorlagen Informationen über die jeweils enthaltenen Objekte abgespeichert. In einem dritten Verfahrensschritt 3 werden dann Informationen über die entsprechenden, zu den jeweiligen enthaltenen Objekten zugehörigen Containment-Relationen in den Objektvorlagen hinterlegt.
  • Bei einem vierten Verfahrensschritt 4 werden in der Folge Informationen über in den existierenden Objekten einseitige Relationen in den Objektvorlagen herlegt. Dabei stellen einseitige Relationen Verknüpfungen dar, welche in eine eindeutige Richtung lesbar bzw. interpretierbar sind, wobei ein Objekt (z. B. Typobjekt), auf welches von einer einseitigen Relation verwiesen wird, in einer Anwendung üblicherweise nur einmal existiert. Es ist aber diesem Objekt (z. B. Typobjekt) nicht bekannt, welche weiteren Objekte noch eine einseitige Relation zu ihm aufweisen.
  • In einem fünften Verfahrensschritt 5 werden in existierenden Objekten bestehende beidseitige Relationen durch entsprechende Platzhalter ersetzt, in welchen die Information über die jeweiligen beidseitigen Relationen hinterlegt wird. Ein derartiger Platzhalter kann beispielsweise als sogenanntes Relationsobjekt ausgestaltet sein, in welchem ein Schlüssel zum Auffinden für das jeweilige Zielobjekt z. B. als Attribut hinterlegt ist. Als beidseitige Relationen werden üblicherweise Relationen bezeichnet, welche in beide Richtungen interpretierbar sind. D. h. heißt ein bestimmtes Objekt ist über eine derartige Relation beispielsweise mit einem sogenannten Mengenobjekt verknüpft. Dieses Objekt wird durch die beidseitige Relation diesem Mengenobjekt eindeutig zugeordnet. Dem Mengeobjekt ist aber auch bekannt, welche Objekte eine Relation zum ihm aufweisen. Es wird damit vom Mengenobjekt gewusst, dass das bestimmte Objekt mit ihm verknüpft ist. Aufgrund dieser Verknüpfung können beidseitige Verbindungen nicht in Objektvorlagen übernommen werden, da sonst unnötiger Weise z. B. eine Vielzahl von Objekten kopiert wird bzw. schlimmstenfalls die gesamte Datenbank auf sich selbst kopiert werden würde.
  • In einem sechsten Verfahrensschritt 6 werden dann die jeweiligen Objektvorlagen erhalten, welche als Basis für neue Objekte herangezogen werden können, welche mit den existierenden Ausgangsobjekten weitestgehend identisch sind. Zur Vereinfachung können die Verfahrensschritte vom ersten 1 bis zum sechsten Verfahrensschritt 6 beispielsweise von einem Anwender als Regeln definiert werden, welche dann in einem ersten Arbeitsschritt F1 abgearbeitet werden. Das bedeutet, der erste Abschnitt des erfindungsgemäßen Verfahrens stellt den ersten Arbeitsschritt F1 dar, durch welchen von einem existierenden Objekt eine entsprechende Objektvorlage abgeleitet. Der erste Arbeitsschritt F1 wird im Folgenden noch detaillierter anhand der 2a erläutert, wobei von einem beispielhaften Objekt O1 (z. B. einem Schaltschrank) ausgegangen wird.
  • 2a zeigt schematisch und beispielhaft auf einer linken Seite ein übergeordnetes Objekt UO – z. B. einen Raum, welcher einer Klasse Raum angehört. Im übergeordneten Objekt UO der Klasse Raum ist beispielhaft ein Objekt O1 wie z. B. ein Schaltschrank mit der Klasse Schrank zugeordnet, wobei das übergeordnete Objekt UO mehrere Objekt O1 der Klasse Schrank enthalten kann. Die Zuordnung des Objekts O1 zum übergeordneten Objekt UO wird durch eine erste Containment-Relation C1 erwirkt.
  • Weiters zeigt 2a auf der linken Seite, dass das Objekt O1 über einen zweite Containment-Relation C2 beispielhaft ein erstes sogenanntes Kindobjekt K1 enthält, welches einer Klasse Einschub angehört. Dem ersten Kindobjekt K1 ist dabei zumindest ein beispielhaftes zweites Kindobjekt K2 über eine dritte Containment-Relation C3 zugeordnet, welches einer Klasse Modul angehört. Die beiden Kindobjekte K1 und K2 sind damit über die Containment-Relationen C2, C3 im Objekt O1 der Klasse Schrank enthalten.
  • Zusätzlich weist das Objekt O1 ein erstes Attribut A1 auf, durch welches beispielsweise ein Typ des Objekts O1 näher beschrieben werden kann. Dazu wird z. B. das Objekt O1 über eine einseitige Relation R1 mit einem Typobjekt TO einer Klasse Schranktyp verknüpft. Das Typobjekt TO kann beispielsweise ein zweites Attribut A2 aufweisen, durch welches die Klasse Schranktyp näher spezifiziert wird. Das Typobjekt TO ist dabei üblicherweise nur ein einziges Mal in einer Anwendung bzw. objektorientierten Datenbank vorhanden. Von allen Objekten dieses Typs wird dann – üblicherweise mittels einer einseitigen Relation R1 auf dieses Typobjekt TO verwiesen, wobei dem Typobjekt die verweisenden Objekte nicht bekannt sind.
  • Weiters weist das zweite Kindobjekt K2 ein drittes Attribut A3 auf, durch welches z. B. eine Zugehörigkeit des zweiten Kindobjekts K2 der Klasse Modul zu einem Mengen-Objekt P einer Klasse Modulpool beschrieben wird. Die Verknüpfung des zweiten Kindobjekts K2 mit Mengen-Objekt P, welches – beschrieben durch ein viertes Attribut A4 des Mengen-Objekts P – viele Objekte der Klasse Modul enthalten kann, wird durch eine beidseitige Relation R2 realisiert. Durch die beidseitige Relation R2 ist nicht nur das zweite Kindobjekt K2 mit dem Mengen-Objekt P verknüpft, sondern es ist auch dem Mengen-Objekt P damit bekannt, dass von ihm auf das zweite Kindobjekt K2 verwiesen wird.
  • Durch den ersten Arbeitsschritt F1 wird nun aus dem beispielhaften auf der linken Seite der 2a dargestellten, existierenden Objekt O1 eine Objektvorlage T erstellt. Dazu wird zuerst die erste Containment-Relation C1 zum übergeordneten Objekt UO aufgelöst bzw. nicht kopiert. In der Folge werden dann einen erste Kopie O1a des Objekts O1 sowie entsprechende Kopien K1a, K2a der Kindobjekte K1, K1 angelegt. Alle diese Kopien bzw. kopierten Objekte O1a, K1a, K2a weisen die jeweiligen Attribute A1, A3 der Ausgangsobjekte O1, K1, K2 auf. Danach werden Kopien C2a, C3a der zweiten und dritten Containment-Relation C2, C3 erstellt und in der Objektvorlage T gespeichert. Dann wird auch die einseitige R1 als Kopie R1a in der Objektvorlage T erzeugt und gespeichert, um dort ebenfalls eine Typspezifikation für die Objektkopie O1a bzw. eine Verweis auf das Typobjekt TO zu hinterlegen.
  • Abschließend wird die beidseitige Relation R2 zum Mengen-Objekt P in der Objektvorlage T durch einen Platzhalten PH ersetzt. Als Platzhalter PH wird dabei ein sogenanntes Relationsobjekt PH erzeugt und eingesetzt, das beispielsweise eine Klasse Relation aufweist. Im Relationsobjekt PH ist als fünftes Attribut ziel ein Schlüssel zum Auffinden des Mengen-Objekts P hinterlegt. Damit wird vom Relationsobjekt PH der Objektvorlage T die beidseitige Relation R2 zwischen dem zweiten Kindobjekt K2 und dem Mengen-Objekt P beschrieben. Das Relationsobjekt PH ist auch über eine Relation RP, welche z. B. als einseitige Relation ausgeführt sein kann, mit der Kopie K2a des zweiten Kindobjekts in der Objektvorlage T verknüpft. Anhand dieser Vorgehensweise, welche den in 1 dargestellten Verfahrensschritten 1 bis 6 entspricht, werden Objektvorlagen T für existierende Objekte O1 generiert, in welchen Informationen für alle enthaltenen Objekte K1, K2, alle zugehörigen Containment-Relationen C2, C3, einseitigen Relationen R1 sowie Platzhalten PH für beidseitige Relationen R2 hinterlegt sind.
  • Wurden nun Objektvorlagen gemäß dem in der 1 beispielhaft dargestellten erfindungsgemäßen Verfahren bzw. gemäß dem in 2a beispielhaft und schematisch dargestellten Arbeitsschritt F1 erstellt, so beginnt der zweite Abschnitt des erfindungsgemäßen Verfahrens mit einem siebenten Verfahrensschritt 7 der 1, bei welchen auf Basis von Objektvorlagen mit dem Erstellen von neuen Objekten begonnen wird. In einem achten Verfahrensschritt 8 werden auf Basis der in den Objektvorlagen abgelegten Informationen die enthaltenen Objekte für die neuen Objekte erzeugt. Dann werden in einem neunten Verfahrensschritt 9 die entsprechenden zugehörigen Containment-Relationen für diese enthaltenen Objekte auf Basis der Informationen in den Objektvorlagen hergestellt.
  • In einem zehnten Verfahrensschritt 10 werden dann anhand der Informationen in den Objektvorlagen die jeweiligen einseitigen Relationen für die neuen Objekte entsprechend spezifiziert und erzeugt. In einem elften Verfahrensschritt 11 werden dann die Platzhalter bzw. die als Platzhalter genutzten Relationsobjekte aufgelöst und wieder durch die entsprechenden beidseitigen Relationen ersetzt.
  • In einem zwölften Verfahrensschritt 12 sind dann die neuen Objekte anhand der Objektvorlagen fertig erstellt. Diese neuen Objekte sind mit den jeweiligen Ausgangsobjekten weitgehend identisch. Zur einfacheren Benutzung können auch die Verfahrensschritte 7 bis 12 zu einem zweiten Arbeitsschritt für den Anwender zusammengefasst werden, welcher dem zweiten Abschnitt des erfindungsgemäßen Verfahrens entspricht. Damit werden auf einfache Weise für objektorientierte Anwendungen bzw. Datenbanken neue Objekte auf Basis von bestehenden Objekten generiert, wobei die Wahrscheinlichkeit, Relationen zu vergessen und/oder falsch zu erzeugen, erheblich reduziert wird. Eine beispielhafte, detaillierte Beschreibung des zweiten Arbeitschritts bzw. Abschnitts wird in der Folge anhand der 2b beschrieben.
  • 2b zeigt auf einer linken Seite wieder die beispielhafte Objektvorlage T, in welcher eine kopiertes Objekt O1a der Klasse Schrank enthalten ist. Im kopierten Objekt O1a sind über entsprechende Containment-Relationen C2a, C3a Kindobjektkopien K1a, K2a enthalten. Die Objektvorlage weist auch die kopierte einseitige Relation R1a sowie den als Relationsobjekt ausgestalteten Platzhalter PH für die beidseitige Relation R2 auf.
  • Im zweiten Arbeitsschritt F2 soll das auf der rechten Seite der 2b dargestellte Objekt O1b auf Basis der Objektvorlage T für das übergeordnete Objekt UO erstellt werden, da diese übergeordnete Objekt UO ein zweites Objekt O1b der Klasse Schrank enthalten soll.
  • Dazu wird zuerst auf Basis der Objektvorlage T das Objekt O1b der Klasse Schrank erzeugt. Dann werden die in der Objektvorlage T abgespeicherten Kindobjekte K1a, K2a kopiert und als Kindobjekte K1b, K2b des Objekts O1b erzeugt. Die auf Basis der Objektvorlage T erzeugten Objekte O1b, K1b, K2b weisen wieder die jeweiligen Attribute A1, A3 der Ausgangsobjekte O1, K1, K2 auf. D. h. das Objekt O1b umfasst das erste Attribut A1, durch welches der Typ des Objekts O1b näher beschrieben wird, und das Kindobjekt K2b weist wieder das dritte Attribut A3 auf, durch welches die Zugehörigkeit zum Mengen-Objekt P festgelegt wird.
  • Dann werden auf Basis der Objektvorlage T die Containment-Relationen C2b, C3b durch Kopie erzeugt. In der Folge wird auch die einseitige Relation R1b auf Basis der Information in der Objektvorlage T vom neuen Objekt O1b zum Typobjekt TO aufgebaut. Danach wird der Platzhalter bzw. das Relationsobjekt PH der Objektvorlage T derart aufgelöst, dass daraus wieder die beidseitige Relation R2b zwischen dem zweiten Kindobjekt K2b des neuen Objekt O1b und dem Mengen-Objekt P erzeugt wird. Das Mengen-Objekt P als Ziel der beidseitigen Relation R2b wird dabei aus dem fünften Attribut ziel des Relationsobjekts PH ermittelt. Von der beidseitigen Relation R2b wird damit die Relation RP der Objektvorlage T und vom Mengen-Objekt P das Relationsobjekt der Objektvorlage T ersetzt.
  • Damit wurde auf einfache Weise und mit relativ geringer Fehlerwahrscheinlichkeit in zwei Arbeitsschritten F1, F2 auf Basis der Objektvorlage T aus dem existierenden Objekt O1 der Klasse Schrank ein neues Objekt O1b generiert, welches weitgehend eine Kopie des existierenden Objekts O1 darstellt und wieder über eine Containment-Relation C1b mit dem übergeordneten Objekt UO der Klasse Raum verbunden werden kann.

Claims (6)

  1. Verfahren zum Erstellen von Objekten (O1b) einer objektorientierten Datenbank, wobei ein Objekt (O1) zumindest eine Relation, welche als sogenannte Containment-Relation (C1, C2, C3) oder als einseitige Relation (R1) oder als beidseitige Relation (R2) ausgestaltet sein kann, zu zumindest einem weiteren Objekt (K1, K2, TO, P) aufweist, dadurch gekennzeichnet, dass aus bestehenden Objekten (O1) Objektvorlagen (T) generiert werden (1 bis 6), in welchen Informationen über jeweils enthaltene Objekte (K1, K2) und die zugehörigen Containment-Relationen (C2, C3) sowie einseitige Relationen (R1) abgespeichert (1, 2, 3, 4) und in welchen die beidseitigen Relationen (R2) durch Platzhalter (PH) ersetzt werden (5), und dass zur Erstellung von neuen Objekten (Ob1) die Objektvorlagen (T) herangezogen werden (7 bis 12), wobei auf Basis der in den Objektvorlagen (T) hinterlegten Informationen die jeweils enthaltenen Objekte (K1b, K2b) mit den zugehörigen Containment-Relationen (C2b, C3b) sowie die einseitigen Relationen (R1b) generiert werden (8, 9, 10), und wobei die Platzhalter (PH) für beidseitige Relationen (R2) durch die entsprechenden beidseitigen Relationen (R2b) ersetzt werden (11).
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass für ein Generieren der Objektvorlagen (T) aus bestehenden Objekten (O1) zuerst in den bestehenden Objekten enthaltene Objekte (K2, K3) sowie die zugehörigen Containment-Relationen (C2, C39 kopiert und gespeichert werden (2, 3), dass dann einseitige Relationen (R1) kopiert und gespeichert werden (4), und dass dann beidseitige Relationen (R2) der bestehenden Objekte (O1) aufgelöst und durch Platzhalter (PH) ersetzt werden (5), von welchen die beidseitigen Relationen (R2) beschrieben werden.
  3. Verfahren nach einem der Ansprüche 1 bis 2, dadurch gekennzeichnet, dass für ein Erstellen von neuen Objekten (O1b) auf Basis der generierten Objektvorlagen (T) zuerst die enthaltenen Objekte (K1b, K2b) sowie die zugehörigen Containment-Relationen (C2b, C3b) kopiert werden (8, 9), dass dann auf Basis der Objektvorlagen (T) die einseitigen Relationen (R1b) erzeugt werden (10), und dass dann die in den Platzhaltern (PH) abgelegten Informationen derart aufgelöst werden (11), dass die entsprechenden beidseitigen Relationen (R2b) erzeugt werden.
  4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Platzhalter (PH) für beidseitige Relationen (R2) als sogenannte Relationsobjekte (PH) ausgestaltet werden (5), in welchen Schlüssel (ziel) zum Auffinden von Zielobjekten (P) für die beidseitigen Relationen (R2) hinterlegt werden.
  5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass ein Schlüssel (ziel) zum Auffinden von Zielobjekten als sogenanntes Attribut in einem Relationsobjekt (PH) hinterlegt wird.
  6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass beim Erzeugen von beidseitigen Relationen (R2b) in neuen Objekten (Ob1) zuerst aus den Platzhaltern (PH) die entsprechenden Zielobjekte (P) für die beidseitigen Relationen (R2b) ermittelt werden, und dass dann die entsprechenden, zugehörigen beidseitigen Relationen (R2b) zu den Zielobjekten (P) erzeugt werden (11).
DE102010010035A 2010-03-03 2010-03-03 Verfahren zum Erstellen von Objekten einer objektorientierten Datenbank Ceased DE102010010035A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102010010035A DE102010010035A1 (de) 2010-03-03 2010-03-03 Verfahren zum Erstellen von Objekten einer objektorientierten Datenbank

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102010010035A DE102010010035A1 (de) 2010-03-03 2010-03-03 Verfahren zum Erstellen von Objekten einer objektorientierten Datenbank

Publications (1)

Publication Number Publication Date
DE102010010035A1 true DE102010010035A1 (de) 2011-09-08

Family

ID=44502830

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102010010035A Ceased DE102010010035A1 (de) 2010-03-03 2010-03-03 Verfahren zum Erstellen von Objekten einer objektorientierten Datenbank

Country Status (1)

Country Link
DE (1) DE102010010035A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019210909A1 (de) 2018-05-02 2019-11-07 Gerhard Biermann Objektdatenbank zur geschäftsmodellierung mit verbesserter datensicherheit

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019210909A1 (de) 2018-05-02 2019-11-07 Gerhard Biermann Objektdatenbank zur geschäftsmodellierung mit verbesserter datensicherheit

Similar Documents

Publication Publication Date Title
EP3158462A1 (de) Gerät mit kommunikationsschnittstelle und verfahren zur steuerung eines datenbankzugriffs
EP1430369B1 (de) Dynamischer zugriff auf automatisierungsressourcen
EP1638028A2 (de) Rechnergestützte Erzeugung und Änderungsmanagement für Bedienoberflächen
DE60225785T2 (de) Verfahren zur codierung und decodierung eines pfades in der baumstruktur eines strukturierten dokuments
EP2439691A1 (de) Vorrichtung und Verfahren zum maschinellen Erstellen eines Prozessdiagramms
EP3137999B1 (de) Verfahren und vorrichtung zur transaktionserweiterung bei opc ua
EP3213266A1 (de) Verfahren zur integration einer semantischen datenverarbeitung
DE102010010035A1 (de) Verfahren zum Erstellen von Objekten einer objektorientierten Datenbank
DE19908204A1 (de) Fraktales Netz n-ter Ordnung zum Behandeln komplexer Strukturen
WO2006108801A2 (de) Synchronisation von daten
DE102016005519A1 (de) Verfahren zur Erstellung eines Metadaten-Datenmodells für eine BI-Infrastruktur
EP2329374A1 (de) Testmodul und verfahren zum testen einer o/r-abbildungs-middleware
EP1234231B1 (de) Verfahren zur erzeugung grafischer benutzerschnittstellen für computerprogramme
EP2757466B1 (de) Computerimplementiertes Verfahren zum Generieren von Computerprogrammcode
WO2015014955A1 (de) Verfahren und system zur synchronisation von daten
EP1515244A2 (de) Abbildung einer Klassenhierarchie auf ein relationales Datenbanksystem
DE10109876B4 (de) Verfahren und Einrichtung zum Datenmanagement
DE102012209674A1 (de) Verfahren zum Umwandeln von Ausgangsdaten in Zieldaten gemäß ASN.1
DE102006037968B4 (de) Universelle und erweiterbare Datenverwaltung mit Beobachtungs- und Interprozesskommunikations-Mechanismen
WO2015014957A1 (de) Verfahren zum konnektieren von objekten in einer softwareanwendung
EP1332446A2 (de) System, verfahren und computerprogramm zur konfiguration von objekten
DE102020123509A1 (de) Verfahren zum Bereitstellen und Validieren alternativer Objektbezeichner sowie zum Ermitteln von Referenzen alternativer Objektbezeichner innerhalb einer OPC-UA basierenden Kommunikationsumgebung
Keller ABAP-Referenz
EP4035342A1 (de) Verfahren zum bereitstellen und validieren alternativer objektbezeichner sowie zum ermitteln von referenzen alternativer objektbezeichner innerhalb einer opc-ua-basierenden kommunikationsumgebung
WO2004042556A2 (de) Strukturierung, speicherung und verarbeitung von daten gemäss einem generischen objektmodell

Legal Events

Date Code Title Description
R016 Response to examination communication
R016 Response to examination communication
R016 Response to examination communication
R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final

Effective date: 20111221