Datenbankstruktur

Diese Seite wurde automatisch aus dem Datenbank-Schema-Dump generiert und kann unvollständig oder fehlerhaft sein.

Dieser Bereich dokumentiert die Datenbankstruktur des enaio®-Systems — also welche Tabellen im Datenbankschema vorhanden sind, welche Spalten sie führen und wie die wiederkehrenden Muster der Objekt-, Stamm- und Register-Tabellen zusammenhängen. Das Schema ist datenbankunabhängig — enaio® unterstützt mehrere relationale Datenbankbackends (z. B. Microsoft SQL Server, Oracle). Datentypen werden in dieser Doku in der SQL-Server-Schreibweise (int, nvarchar, datetime, bigint, smallint, real, image) angegeben; bei Oracle entsprechen sie sinngemäß NUMBER, NVARCHAR2, DATE, NUMBER(19), NUMBER(5), BINARY_FLOAT und BLOB.

Die hier dokumentierten Strukturen sind die unmittelbare physische Speicherform; sie werden in der Regel nicht direkt modifiziert (außer durch ado.ExecuteSQL-Skripte für administrative Korrekturen), sondern über die DMS-, Standard- und Workflow-Engines bearbeitet. Diese Doku ist als Referenz für Administratoren, Reportentwickler und Integrationsentwickler gedacht.

1. Schema-Konventionen

Die Datenbank verwendet eine Mischung aus festen Systemtabellen und typspezifischen Tabellen pro Objekttyp. Folgende Konventionen sind durchgängig:

1.1. Suffix-Schema

Für jeden konfigurierten DMS-Objekttyp existieren mehrere Tabellen, deren Name eine fortlaufende Nummer X trägt. X entspricht dem Haupttyp (haupttyp-Spalte) + 1 — object1 enthält also Objekte mit haupttyp = 0, object17 solche mit haupttyp = 16. Die volle Objekttyp-ID (haupttyp * 65536 + untertyp) ist in Objekttyp-ID beschrieben.

Name Inhalt

objectX / stammX / registerX

Hauptobjekttabelle. Hält je Datensatz ein Objekt vom Typ X. Enthält gemeinsame Systemfelder (id, zeitstempel, Status, Berechtigungs-IDs, …) plus typspezifische Indexfelder.

objectXr / stammXr / registerXr

Rights-Tabelle. Hält Berechtigungseinträge pro Objekt (komplementär zum globalen Sicherheitssystem via ossd). Identische 4-Spalten-Struktur über alle Objekttypen.

objectXs / stammXs / registerXs

Shadow-Tabelle für Indexdaten-Historie. Hält die jeweils vorherigen Indexdatenstände vor jeder Änderung. Gemeinsam ist nur osguid (Snapshot-Identifikator); danach folgen die typspezifischen Indexfelder.

objectXlistY / stammXlistY / registerXlistY

Tabellenfeld-Daten. Eine Tabelle pro auf dem Objekttyp X definierten Tabellenfeld Y (Grid-Feld); enthält pro Zeile des Grids einen Datensatz. Gemeinsame Felder: id (FK auf Hauptobjekt) und line (Zeilennummer im Grid).

objectXlistYs / stammXlistYs / registerXlistYs

Shadow-Variante zu Tabellenfeldern. Gemeinsam: osguid und line.

1.2. Spaltennamen-Konvention

Indexfelder folgen einer historisch gewachsenen, typabhängig-positionellen Notation (ungarische Schreibweise):

  • feld1, feld2, … — Textfelder (nvarchar)

  • zahl1, zahl2, … — Ganzzahlfelder (int / smallint)

  • datum1, datum2, … — Datumsfelder (datetime)

  • real1, real2, … — Dezimal-/Fließkommafelder (decimal / real)

Die Zuordnung „Spaltenname → semantisches Indexfeld" ist pro Objekttyp unterschiedlich konfiguriert und über die DMS-Objektdefinition zugänglich (dms.GetObjDef).

Systemfelder hingegen verwenden sprechende deutsche Namen (anleger, angelegt, archiviert, zeitstempel, medium_doc, …) — ein historisches Erbe.

2. Hierarchische Objekttypen

Die folgenden drei Seiten beschreiben jeweils das Muster — gemeinsame Felder, Rights-, Shadow- und Tabellenfeld-Varianten — nicht einzelne nummerierte Tabellen.

3. Benutzer und Gruppen

4. Mappen und Dokumentzuordnungen

  • mappe — Mappen (Portfolios).

  • mdrel — Mappen-Dokument-Zuordnung.

5. Medien und Archiv

  • medien — Speichermedien, auch die Systemmedien WORK und NOTE.

  • medrel — Medien-Set-Beziehungen.

  • archex — Archiv-Extensions / Serverzuordnung.

6. Sperren und Verknüpfungen

  • doclock — Dokumentsperren (Checkout).

  • hyplnk — Hyperlinks (Querverweise zwischen Objekten).

  • combined — Kombinierte Dokumente (Parent/Child-Beziehungen).

7. Annotationen

8. Externsysteme

9. Audit und Historie

10. Sessions, Geräte und Sperren

11. Berechtigungen und Profile

Die Workflow-Organisationsobjekte (osorg*) sind unter Workflows dokumentiert.

12. System-Events

13. DMS-Objekttypen, Indexfelder und Strukturen

14. Versionen, Hashes und Signaturen

15. Annotationen und Collaboration

16. Mappen / Portfolios (OS-Variante)

17. Bemerkungen und Texte

17.1. Ablageart von Notizen

Notizen an DMS-Objekten treten in zwei Ausprägungen auf, die in verschiedenen Tabellen liegen:

  • Textnotiz — farbiger Freitext am Objekt, verwaltet in remarks.

  • Notizverknüpfung — Verweis auf ein anderes DMS-Objekt, verwaltet in hyplnk und nicht in remarks.

Beide sind an Ordnern, Registern, Dokumenten und Mappen möglich. Ihre Anzahl je Objekt steht zusätzlich in der Spalte links der jeweiligen Indextabelle; daraus speist sich das Notizsymbol in Trefferlisten.

Der Text einer Textnotiz liegt je nach Serverkonfiguration im Dateisystem oder in der Datenbank. Der Schalter steht in der AS.cfg im Abschnitt [System] unter NoteStorage: 0 = Dateisystem, 1 = Datenbank. Er liegt nicht in der Server-Registry und ist über krn.REGetRegValue daher nicht erreichbar; lesbar ist er über adm.GetSystemFile mit FileName = as.cfg, die Datei kommt in UTF-16LE zurück.

Merkmal Dateisystem Datenbank

Ort des Textes

je Notiz eine .txt-Datei unterhalb des NOTE-Verzeichnisses

Spalte ostext in osremarktext, adressiert über remarks.textid

remarks.medium

Medium-ID des Systemmediums NOTE in medien

NULL

medium in der Abfrageausgabe

dieselbe Medium-ID

0

remarks.textid

NULL

Schlüssel in osremarktext

<Text id="…"> in der Abfrageausgabe

leer

die textid

Längenbegrenzung

keine

8000 Zeichen; darüber bricht der Import mit -1028 ab, ohne zu kürzen

Recherche über den Notizinhalt

nicht möglich

möglich

std.GetRemark, std.StoreRemark, std.DeleteRemark

zuständig

nicht verwendbar, siehe die Warnung unten

Anlegen, Ändern, Löschen über XML

dms.XMLUpdate mit <RemarkText>

ebenso
Die drei std-Remark-Jobs setzen die Ablage im Dateisystem voraus. Bei Datenbankablage scheitern std.GetRemark und std.DeleteRemark mit -1043201745, und std.StoreRemark migriert die Notiz stillschweigend zurück ins Dateisystem: der Job liefert 0, legt eine Notizdatei an, setzt remarks.medium auf die Medium-ID und lässt die Zeile in osremarktext mit dem alten Text verwaisen.

Die Angaben dieses Abschnitts sind an enaio®-Server 12.0 gemessen (axsvckrn 12.0.799, DMS-Engine 12.0.769.25242, Datenbank Microsoft SQL Server 2022).

17.1.1. Ort der Notizdateien

Das Wurzelverzeichnis steht in path im Eintrag mit flag = 2, je Servergruppe einer. Darunter staffeln sich die Dateien nach Objekttyp und Notiz-ID. Alle vier Komponenten sind hexadezimal, die Verzeichnisse zweistellig, der Dateiname achtstellig:

<Pfad>\NOTE\<Haupttyp>\<Untertyp>\<Notiz-ID mod 256>\<Notiz-ID>.txt

Beispiel für die Notiz-ID 146610 (0x00023CB2) an einem Objekt mit Haupttyp 4 und Untertyp 1:

C:\enaio\server\NOTE\04\01\B2\00023CB2.txt

Eine vom Server erzeugte Notizdatei beginnt mit der UTF-8-BOM und endet mit einem Nullbyte; elf Textzeichen ergeben so 15 Bytes. Eine über std.StoreRemark übergebene Datei wird dagegen unverändert abgelegt.

17.1.2. Umstellen der Ablageart

Eine automatische Migration gibt es nicht. Nach dem Umstellen auf Datenbank bleiben vorhandene Textdateien unverändert lesbar und behalten ihre Medium-ID in medium.

Eine einzelne Notiz wandert erst, wenn ihr Text geändert wird, also bei <RemarkText action="UPDATE_TEXT">. Dabei erhält sie eine neu vergebene textid, medium wird auf NULL gesetzt und die alte .txt-Datei wird entfernt. UPDATE_COLOR löst den Wechsel nicht aus: die Farbe ändert sich, die Notiz bleibt im Dateisystem.

Ein bestehender langer Text wird beim Wandern nicht gekürzt, weil es keinen Weg gibt, auf dem er übernommen würde. UPDATE_TEXT ersetzt ihn, und ein neuer Text über 8000 Zeichen wird mit -1028 abgewiesen.

18. Volltextsuche

19. Lizenzen und Kryptografie

20. Lokalisierung und Icons

21. Server-Cluster und Konfiguration

22. Aktive Bearbeitung und Temporäres

23. Abonnements und Wiedervorlagen (OS-Backing)

24. Workflows

Die Workflow-Engine speichert Modelle, laufende Prozesse, Historien und Verwaltungsdaten in eigenen Tabellen mit Präfix oswf. Historien-Tabellen tragen zusätzlich das Präfix oswfh. Die Workflow-Organisation (Benutzer, Rollen, Abteilungen, Klassen und Attribute) liegt in den osorg*-Tabellen und wird sowohl von der Workflow-Engine als auch vom DMS-Sicherheitssystem genutzt.

Modelle und Definitionen

Masken und Listen-UI

Prozesse und Aktivitäten (Laufzeit)

Organisation und Bearbeiter

Workflow-spezifische Bearbeiter-Zuordnungen:

Organisations-Stammdaten (osorg*) — Benutzer, Rollen, Abteilungen, Klassen, Attribute:

Timer

Routinglisten

Reports

Historie (oswfh*)

25. Labor (LIMS)

Tabellen der Labordatenintegration (Laboratory Master/Transaction Tables):

26. Medizin (HL7)

Tabellen der medizinischen Datenintegration (Medical Master/Transaction Tables):