-
Die Erfindung bezieht sich auf ein
Datenverarbeitungssystem (DV-System)
zur eingabemaskengestützten Überwachung
und/oder Steuerung von Prozessen eines damit überwachten und/oder gesteuerten
Systems nach dem Oberbegriff des Anspruchs 1.
-
Ein solches Datenverarbeitungssystem
beinhaltet als wesentliche Mensch/Maschine-Schnittstelle eine typischerweise
auf einem Bildschirm optisch wiedergebbare Bedienoberfläche mit
Eingabemasken, wobei jede Maske einem entsprechenden Prozessschritt
des überwachten
bzw. gesteuerten Systems zugeordnet ist. Die Masken weisen jeweils
ein oder mehrere, meist eine Vielzahl von Feldern zum Eingeben und/oder
Anzeigen von Daten auf, vorliegend der Einfachheit halber einheitlich
als Eingabefelder bezeichnet. Die Daten werden in einer Datenbank
geeigneten Aufbaus gehalten. Datenverarbeitende Mittel stehen einerseits
mit der Datenbank und andererseits mit der Bedienoberfläche in Verbindung.
-
Bei bisherigen Systemen dieser Art
wird die Verknüpfung
der Maske und deren Inhalte mit der Datenbank zur Speicherung der
Inhalte über
geeignete, für
jede Maske spezifische Programme bewirkt. Liegt der Verknüpfung der
Maske mit der Datenbank das Transaktionskonzept zugrunde – wie dies
z.B. in einer Web-Umgebung der Fall ist -, so besteht zwischen der
Eingabemaske und der Datenbank lediglich eine virtuelle Verbindung.
So wird beispielsweise bei einer Kommunikation zwischen einem Webserver und
einem anwenderseitigen Browser nach Aufruf einer Maske die betreffende
Maske als HTML-Seite vom Webserver zum Browser gesendet. Nach diesem
Sendevorgang kann die Verbindung physikalisch wieder unterbrochen
werden. Nach anwenderseitigem Ausfüllen bzw. Ändern der Maskeneinträge wird
ein Speichervorgang initiiert. Dazu wird bei der herkömmlichen
Technik auf Seiten des Servers der Maskeninhalt und eventuell bereits
vorhandener Datenbankinhalt durch ein maskenindividuelles Programm
analysiert und daraus abgeleitet die notwendige Speicherungsmaßnahme durchgeführt.
-
In der deutschen Patentanmeldung
101 12 231.4-53 ist ein Datenverarbeitungssystem der eingangs genannten
Art beschrieben, das eine verbesserte Überwachung und/oder Steuerung
einschließlich
Automatisierung von Systemprozessen ermöglicht und dabei hochflexibel
vergleichsweise einfach an Veränderungen
und/oder Erweiterungen der zu überwachenden
bzw. zu steuernden Prozesse anpassbar ist. Zu diesem Zweck ist dort
u.a. die Maßnahme
angegeben, ein doppeltes Schlüsselkonzept zu
implementieren, welches für
ein jeweiliges Eingabefeld zur Steuerung der Speicherung seiner
Daten die Zuweisbarkeit eines datenbankorientierten Schlüssels und
eines davon verschiedenen anwendungsbezogenen Schlüssels beinhaltet.
Zur Anwenderkonfigurierbarkeit dieses doppelten Schlüsselkonzeptes
sind die Eingabefelder bezüglich
vorgebbarer Eigenschaften parametrisiert.
-
Die vorliegende Anmeldung ist eine
Zusatzanmeldung zu dieser deutschen Patentanmeldung 101 12 231.4-53,
deren Inhalt hier zur Vermeidung unnötiger Wiederholungen in vollem
Umfang durch Verweis aufgenommen wird und die im Folgenden als Hauptpatentanmeldung
bezeichnet wird.
-
Der Erfindung liegt als technisches
Problem die Bereitstellung eines Datenverarbeitungssystems der eingangs
genannten Art zugrunde, das eine verbesserte Überwachung und/oder Steuerung
einschließlich
Automatisierung von Systemprozessen ermöglicht und dabei hochflexibel
vergleichsweise einfach an Veränderungen
und/oder Erweiterungen der zu überwachenden
bzw. zu steuernden Prozesse anpassbar ist und das insbesondere ein
weiter verbessertes Datenspeicherverhalten aufweist.
-
Die Erfindung löst dieses Problem durch die Bereitstellung
eines Datenverarbeitungssystems mit den Merkmalen des Anspruchs
1.
-
Dieses erfindungsgemäße Datenverarbeitungssystem
umfasst Datenspeichermittel, die derart ausgelegt sind, dass sie
eine Datenspeicherung unter Verwendung eines maskenunspezifischen
Algorithmus auf Basis des doppelten Schlüsselkonzeptes realisieren,
wie es in der Hauptpatentanmeldung 101 12 231.4-53 in seinen Grundlagen
beschrieben ist. Bei diesem System sind maskenindividuelle Programme
zur Speicherung von Maskeninhalten in einer Transaktionsumgebung
nicht zwingend erforderlich und können daher entfallen. Stattdessen
werden die Maskenfelder direkt den Datenbankfeldern zugeordnet,
wobei die Felder mit geeigneten formalen Attributen zur Steuerung
des Speichervorgangs versehen werden. Die herkömmlichen maskenindividuellen
Programme zur Speicherung von Maskeninhalten können erfindungsgemäß durch
ein allgemeines, maskenunspezifisches Programm ersetzt werden, das über die
Interpretation der feldbezogenen formalen Attribute die Speicherung
der Inhalte beliebiger Masken übernimmt.
-
In Weiterbildung der Erfindung nach
Anspruch 2 ist eine verfeinerte Steuerung der Datenspeicherung dahingehend
vorgesehen, dass einem Maskenfeld, dem ein bestimmtes Speicherattribut
zugewiesen ist, ein oder mehrere weitere feldbezogene Attribute
zugeordnet sind.
-
In einer Weiterbildung der Erfindung
nach Anspruch 3 ist das Datenverarbeitungssystem mit seinen Speichersteuermitteln
so ausgelegt, dass eine Abspeicherung von Daten über einen allgemeinen, maskenunspezifischen
Algorithmus nach dem doppelten Schlüsselkonzept in mehrere, miteinander verknüpfte Datenbanktabellen
möglich
ist.
-
Vorteilhafte Ausführungsformen der Erfindung
sind in den Zeichnungen dargestellt und werden nachfolgend beschrieben.
Hierbei zeigen:
-
1 ein
schematisches Blockdiagramm eines typischen Webserver-Browser-Kommunikationsvorgangs
mit serverseitiger Abspeicherung von Maskeninhalten,
-
2 eine
Blockdiagrammdarstellung von Datenbankfeldern mit zugeordneten Attributen
für ein Beispiel
zur Erfassung von Temperaturkurven einer technischen Anlage und
-
3 ein
Blockdiagramm zur Veranschaulichung eines Speichervorgangs von auftragsbezogenen
Maskeninhalten für
ein Beispiel mit mehreren Datenbanktabellen.
-
Das in den 1 bis 3 veranschaulichte
Datenverarbeitungssystem entspricht in seinem Aufbau aus Hard- und/oder
Software-Komponenten und in seiner Funktionsweise demjenigen, wie
es in der zugehörigen
Hauptpatentanmeldung beschrieben ist, worauf verwiesen werden kann,
soweit im Folgenden nichts Anderes oder Ergänzendes gesagt ist. Er gänzend ist
insbesondere eine spezielle Implementierung der Speichersteuermittel
unter Verwendung des doppelten Schlüsselkonzeptes, auch als redundantes
Schlüsselkonzept
bezeichnet, vorgesehen, die eine Speicherung von Maskeninhalten über ein
allgemeines, maskenunspezifisches Programm ermöglicht. Dies wird nachfolgend
anhand eines Ausführungsbeispiels
erläutert,
bei dem Temperaturkurven einer technischen Anlage erfasst werden
sollen, und zwar speziell eine stündliche Erfassung der Temperatur
von drei Backöfen
und einer Gare in einer Bäckerei.
Die Erfassung soll manuell über
eine Eingabemaske erfolgen, und das Ergebnis soll als Protokoll
in einer Datenbank abgelegt werden.
-
Beispielhaft sei zunächst unter
Bezugnahme auf 1 ein
typischer Ablauf eines Speichervorgangs bei einer virtuellen Verbindung
zwischen Eingabemaske und Datenbank anhand eines entsprechenden
Kommunikationsprozesses zwischen einem anwenderseitigen Browser 1 und
einem Webserver 2 mit zugehöriger Datenbank 3 betrachtet.
Im gezeigten Beispiel besitzt der Webserver 2 direkten
Zugang zur Datenbank 3.
-
Wie aus 1 ersichtlich, wird anwenderseitig eine
HTML-Seite angefordert, die dann serverseitig erzeugt und zum Browser 1 geliefert
wird und z.B. eine leere oder ganz oder teilweise befüllte Eingabemaske
beinhaltet. Browserseitig werden die Eingabefelder der Maske befüllt oder
geändert,
und die Maskeninhalte werden dann zum Server 2 gesendet.
Dort erfolgt eine Auswertung der Maskeninhalte und die Durchführung entsprechender
Operationen, wie insbesondere eine Speicherung der Maskeninhalte
in der Datenbank 3. Eine vom Server 2 erzeugte HTML-Ergebnisseite wird
zum Browser 1 gesendet und dort dargestellt. Herkömmlich erfolgt
die zugehörige
Steuerung des Kommunikations- und Speicherungsvorgangs auf dem Webserver 2 durch
maskenindividuelle Programme. Die Erfindung macht diese Vorgehensweise
und insbesondere maskenindividuelle Programme zur Speicherung der
Maskeninhalte in einer Transaktionsumgebung überflüssig, indem die Felder der Maske
direkt den Feldern in der Datenbank zugeordnet werden und die Felder
mit formalen Attributen zur Steuerung des Speichervorgangs erweitert
werden. Ein allgemeiner, maskenunspezifischer Algorithmus übernimmt über die
Interpretation der feldbezogenen formalen Attribute die Speicherung
der Inhalte beliebiger Masken.
-
Die für das betrachtete Beispiel
der stündlichen
Temperaturerfassung der drei (Ofen und der Gare verwendete Eingabemaske
weist dazu folgende Eingabefelder auf:
- – Bezeichnung
des technischen Geräts
für das
die Temperatur zu messen ist. Mögliche
Feldinhalte sind z.B. Ofen1, Ofen2, Ofen3 und Gare. Feldname ist „Gerät".
- – Datum
und Zeitpunkt der Messung, Feldname ist „Messzeitpunkt".
- – Temperatur,
Feldname ist „Temperatur".
- – Erfasser
(wobei dieser bereits über
den Login vorbelegt sein kann), Feldname ist „Erfasser".
-
Die Datenverarbeitungsanlage ist
hierzu geeignet ausgelegt, wie in der Hauptpatentanmeldung grundsätzlich erläutert, siehe
dort z.B. 2 mit zugehöriger Beschreibung.
Insbesondere kann die Maske sowohl zur Neueingabe von Temperaturwerten
als auch zur Korrektur von Temperaturwerten verwendet werden. Im
ersteren Fall steht dem Anwender eine leere Maske zur Verfügung, die
er vollständig ausfüllen muss,
während
im zweiten Fall dem Anwender (über
Suchfunktion) eine bereits befüllte Maske
zur Verfügung
gestellt wird, in der er einzelne Felder korrigieren kann.
-
Klickt der Anwender dann auf „Speichern", so
werden die Inhalte der Maske dem zu speichernden Programm übergeben,
und dieses muss die Datensätze
korrekt in der Datenbank ablegen. Um dieses Programm allgemein und
unabhängig
von der konkreten Maske halten zu können, wird ein redundantes
Schlüsselkonzept
gemäß Hauptpatentanmeldung
in einer spezifischen Implementierung eingeführt. 2 zeigt die für diese beispielhafte Umsetzung
des durch die entsprechenden Speichersteuermittel realisierten redundanten
Schlüsselkonzepts benutzten
Datenbankfelder mit ihren zugeordneten formalen Attributen zur Steuerung
der Speicherung und die Maskenfelder mit einigen beispielhaften
Datenbankfeldern.
-
Zur Verallgemeinerung des Speichervorganges
sind die Felder der Datenbanktabelle mit folgenden Speicherattributen
versehen:
Interner Schlüssel:
Das Attribut „Interner
Schlüssel" kennzeichnet
den Datenbankschlüssel
der Tabelle. Das zugehörige
Feld, im gezeigten Beispiel mit „ID" bezeichnet, wird über einen
sogenannten Autozähler realisiert,
d.h. die Datenbank vergibt die Werte für ID. Jeder Datensatz in der
Tabelle kann über
ID eindeutig angesprochen werden. ID beinhaltet keine Information
aus Sicht der Anwendung. Innerhalb einer Tabelle kann nur einem
einzigen Feld das Attribut „Interner
Schlüssel"
zugeordnet werden.
Redundanter Schlüssel: Mit „Redundanter Schlüssel" werden
die Felder bezeichnet, die gemeinsam aus Anwendungssicht einen Datensatz
eindeutig kennzeichnen. So kann z.B. der Datensatz „Ofen1"
zum Messzeitpunkt „12:00"
nur einmal vorhanden sein. Aufgrund des redundanten Schlüsselkonzeptes
ist der Zugriff auf jeden Datensatz entweder über den internen Schlüssel oder über den
redundanten Schlüssel
(der normalerweise den Schlüssel
aus Anwendungssicht darstellt) möglich.
Inhaltsfeld:
Felder mit dem Attribut "Inhaltsfeld" zeichnen sich dadurch aus,
dass sie keine Schlüsselinformation,
sondern lediglich den Inhalt verwalten. Alle Datenbankfelder, denen
nicht die Attribute „Interner
Schlüssel"
oder „Redundanter
Schlüssel"
zugeordnet wurden, sind automatisch Inhaltsfelder.
-
Mit Hilfe des redundanten Schlüsselkonzeptes
können
nun beim Speichern der Inhalte der Maske sämtliche auftretbaren Situationen
erkannt werden, und die Speicherung kann über ein allgemeines, maskenunspezifisches
Programm erfolgen, das lediglich folgende Informationen benötigt:
- – Zuordnung
der Maskenfelder zu Datenbankfeldern.
- – Information über „Internes
Schlüsselfeld"
und „Redundante
Schlüsselfelder".
-
Voraussetzung für die korrekte Funktion ist, dass
das interne Schlüsselfeld
als nicht sichtbares Feld in der Maske mitgeführt wird.
-
Die möglichen Szenarien und Situationen sind
im folgenden aufgezeigt. In einem ersten Szenarium wird die Maske
leer geöffnet,
und die Felder werden befüllt
(ID ist leer). Folgende beispielhafte Situationen treten auf:
- - ID ist leer, Gerät = „Ofen1", Messzeitpunkt = „13:00".
In diesem Fall wird ein neuer Datensatz wird angelegt (erfolgt über SQL-Insert-Anweisung).
- - ID ist leer, Gerät
= „Ofen1",
Messzeitpunkt = „12:00".
Dies ist eine Konfliktsituation, da der Datensatz mit redundantem
Schlüssel „Ofen1"
und „12:00"
bereits existiert. Es kann eine Warnung ausgegeben werden mit Handlungsalternativen „Abbruch"
oder „Überschreiben".
Bei „Überschreiben"
erfolgt der Überschreibvorgang
per SQL-Update-Anweisung.
-
In einem zweiten Szenarium wird der
Datensatz mit ID = 2 zwecks Datenkorrektur geladen. Folgende beispielhafte
Situationen treten auf:
- – Temperatur =„160" wird
geändert,
Schlüssel bleiben
unverändert.
In diesem Fall wird der Datensatz aktualisiert per SQL-Update-Anweisung.
- - Gerät
wird von „Ofen2"
auf „Gare"
verändert. Dies
ist eine Konfliktsituation, da der redundante Schlüssel verändert wurde.
Der Datensatz mit redundantem Schlüssel „Gare" und „13:00"
existiert noch nicht. Es kann eine Warnung ausgegeben werden mit
den Handlungsalternativen „Abbruch", „neuer
Datensatz anlegen" und „neuer
Datensatz anlegen und Datensatz mit ID = 2 löschen". Das Anlegen des Datensatzes
erfolgt über
SQL-Insert-Anweisung und das eventuelle Löschen über SQL-Delete-Anweisung.
- - Gerät
wird von „Ofen2"
auf „Ofen1"
verändert. Dies
ist eine Konfliktsituation, da der redundante Schlüssel verändert wurde.
Der Datensatz mit redundantem Schlüssel „Ofen1" und „13:00"
existiert bereits. Es kann eine Warnung ausgegeben werden mit den
Handlungsalternativen „Abbruch", „Datensatz
mit ID = 3 überschreiben"
und „Datensatz
mit ID = 3 überschreiben
und Datensatz mit ID = 2 löschen".
Der eventuell initiierte Überschreibvorgang
erfolgt per SQL-Update-Anweisung.
-
Das oben beschriebene Verfahren stellt
sicher, dass die Datensätze
in der Maske und in der Datenbank ggf. definiert wieder zueinander
finden. Das Verfahren zur Speicherung vollkommen allgemeiner Maskeninhalte
kann in folgender Weise noch verfeinert werden. Erstens kann beim Maskenfeld
mit dem Speicherattribut „Inhaltsfeld"
hinterlegt werden, ob das Feld aktualisiert werden soll oder nicht.
Ein Feld, das mit „Aktualisierung
= Nein" versehen wird, kann, nachdem der Datensatz einmal gespeichert wurde,
nicht mehr korrigiert werden. Zweitens kann beim Maskenfeld mit
dem Speicherattribut „Inhaltsfeld"
hinterlegt werden, ob das Feld, wenn es leer ist, mit <null> in der Datenbank abgespeichert
werden soll oder ob es bei der Speicherung keine Berücksichtigung
finden soll, sofern es leer ist. Bei einem Feld, das mit „Speichern
bei leer = Nein" versehen wird, kann der Feldinhalt zwar noch überschrieben, aber
nicht mehr gelöscht
werden.
-
Um komplex strukturierte Informationen,
wie z.B. einen Auftrag mit vielen Positionen, speichern zu können, wird
die oben beschriebene Erfindung so erweitert, dass sie folgende
zusätzliche
Anforderungen erfüllt.
Der Maskeninhalt wird in mehreren Tabellen abgespeichert, die über Relationen
miteinander verknüpft
sind, und die Speicherung und der Aufbau der Relation erfolgen innerhalb
einer Transaktion, um Transaktionssicherheit zu gewährleisten. 3 veranschaulicht den zugehörigen Speichervorgang
bei voneinander abhängigen
Tabellen.
-
Folgende Prinzipien liegen der Speicherung der
Maske in mehrere Datenbanktabellen zugrunde:
- – Für jedes
Feld in der Maske wird festgelegt, in welche DB-Tabelle(n) und in
welches Feld oder welche Felder der Maskeninhalt gespeichert werden
soll.
- – Das
oben beschriebene redundante Speicherkonzept wird auf jede DB-Tabelle
für sich
angewendet. Während
z.B. die Auftragsnummer redundanter Schlüssel für die Tabelle „Auftragskopf ` ist, ist die Auftragsnummer zusammen mit
der Positionsnummer redundanter Schlüssel für die Tabelle „Auftragspositionen".
- – Es
wird ein weiteres Speicherattribut „Relation" eingefügt. Dieses
Attribut stellt sicher, dass die KopfID in der Tabelle Position
mit dem Wert des internen Schlüssels
der Tabelle „Auftragskopf"
befüllt
wird. Das Datenbankfeld mit dem Speicherattribut „Relation"
hat damit – wie
das Feld „ID" – keinen
Bezug zur Anwendung, sondern dient lediglich dem Aufbau von Relationen
zwischen Datenbanktabellen.
-
3 zeigt
die SQL-Transaktion mit Ermittlung des Kopf-IDs über den redundanten Schlüssel, nachdem
der Kopfsatz innerhalb der Transaktion gespeichert wurde.
-
Wie die obige Beschreibung eines
konkreten Ausführungsbeispiels
deutlich macht, ermöglicht
das erfindungsgemäße Datenverarbeitungssystem
eine besonders komfortable und flexible Speicherung von Eingabemaskeninhalten
in einer Datenbank über
einen maskenunspezifischen Algorithmus auf der Basis des redundanten
Schlüsselkonzepts.
Es versteht sich, dass je nach Bedarf das beschriebene System um
weitere Hard- und/oder Software-Komponenten ergänzt sein kann, wie sie in der
zugehörigen
Hauptpatentanmeldung angegeben sind, wodurch dann die entsprechenden
zusätzlichen
Eigenschaften und Vorteile erzielt werden, wie in der Hauptpatentanmeldung
ausgeführt,
worauf verwiesen werden kann.