Dieser Artikel befasst sich mit der Unmöglichkeit, fachliche Attribute zu technisieren. Der Schaden, der durch die Verwendung fachlicher Attribute in Schlüsselsystemen angerichtet wurde, ist nie berechnet worden, dürfte aber die weltweiten Kosten des Y2K-'Bugs' zzgl. aller Kosten der Euro-Umstellung in Europa um ein Mehrfaches übersteigen.

Fast jedes Unternehmen betreibt (oder begrub stillschweigend) Software-Investitionsruinen, deren Datenbestand und Applikationslogik durch die Vermengung fachlicher und technischer Aspekte nicht extrahiert und in zeitgemäße n-tier Architekturen übertragen werden kann. Die Verwendung fachlicher Attribute als Primärschlüssel ist dabei nur eine Ursache von vielen, aber eine, die besonders weitreichende Folgen hat.

Das hier erläuterte Konzept der Eindeutigen Objektidentität gilt nicht nur für die objektorientierte Softwareentwicklung. Technische Schlüsselsysteme können in jeder Architektur eingesetzt werden und (zwar sehr kostenintensiv aber strategisch unverzichtbar) in jedem System fachliche Schlüssel ablösen.

Was ist ein UUID und wozu wird eine Objektidentität (OID) benötigt?

UUID steht für Universal Unique IDentifier, OID steht für Object IDentifier.

Objektidentität

Objektorientierte Softwaresysteme arbeiten intern mit Pointern, die auf ein Objekt zeigen, um Beziehungen herzustellen. Ein Objekt existiert dabei nur ein einziges mal im Speicher, selbst, wenn es von sehr vielen anderen Objekten referenziert wird. Durch diese ein-eindeutige Objektidentität ist jederzeit sichergestellt, dass die Objektnetze konsistent bleiben.

Das funktioniert im lokalen Speicher schon sehr schön, in Mehrbenutzerumgebungen ist es jedoch notwendig, die Identität persistenter Objekte (via Framework) auch in der Datenbank mitzuführen. Hierbei können selbstverständlich lokale und temporäre Pointer nicht verwendet werden, es müssen also ObjectIdentifier (OID's) benutzt werden, die plattformübergreifend auf jedem System doublettenfrei erzeugt werden können.

Die absolute Mindestanforderung an die persistente OID ist die Eindeutigkeit innerhalb einer Klasse. In der Praxis wird es damit allerdings Probleme geben, sobald an den Klassenhierarchien 'geschraubt' wird. Die Maximalanforderung ist die Eindeutigkeit über alle Strukturen hinweg. In unserem Fall ist diese Maximalanforderung leicht zu erfüllen, und außerdem noch 'billig'.

OID

OID's (Objektidentitäten) sind technische Schlüssel, die unabhängig von irgendwelchen fachlichen Attributen in Objektnetzen und allen DB-Systemen (ab und nach RDBMS) Objekte (in der RDB Tupel) ein-eindeutig identifizieren und Referenzen/Beziehungen repräsentieren.

In der klassischen Software-Entwicklung wird hier von ID's gesprochen, die i.d.R. von DB-Systemen als Sequence (systemverwaltete -meist transaktionsresistente- lfd. Nummer) bereitgestellt werden (DB2 kann das -Stand 04/1999- leider nicht, vergl. deshalb die NextValue[SequenceName]-Funktion etc. in anderen DB-Systemen wie Progress oder Oracle). Ein Nachteil dieser Sequences ist, dass aufgrund des Datentyps Integer die Reichweite auf zwei Milliarden Tupel per Tabelle begrenzt ist (vier Milliarden, wenn der negative Bereich mitgenutzt wird). Ein mit Datenbank-IDs versorgter objektübergreifender Primärschlüssel ist nur in sehr kleinen, isolierten Applikationen denkbar, sprich in der wirklichen Welt gar nicht realisierbar.

OID's werden in jeder (Parent-)Tabelle als PrimaryKey definiert und bei den Children als ForeignKey angegeben (one to many). Many to many relationships mit und ohne LinkAttributes sind eigene Objekte, werden also auch mit einem eigenen OID persistent gemacht.

Nach dem Stand der Technik und Wissenschaft wird jeder Tupel einer Tabelle in relationalen und objektrelationalen DB-Systemen durch einen ein-eindeutigen technischen Schlüssel identifiziert. Zur eindeutigen Identifikation eines Tupels werden weder aus mehreren Attributen zusammengesetzte Schlüssel noch fachliche Attribute verwendet.

UUID

Die m.E. beste Repräsentation eines OID ist der UUID, der unabhängig von der erzeugenden Maschine weltweit bis ins Jahr 3.400 christlicher Zeitrechnung eindeutig bleibt und auch in Umgebungen mit extrem hohen Allokationsraten (Mainframes) mit zehn Millionen Instanzen per Sekunde und Node (MAC-Adresse der ersten Netzwerkkarte eines Rechners) risikofrei einsetzbar ist.

Viele Betriebssysteme liefern heute bereits UUIDs. Es gibt auch andere Konzepte, die aber alle den kleinen Nachteil haben, daß sie neu implementiert werden müssen. Deren Vorteil ist die Unabhängigkeit von proprietären Komponenten. Ich vertrete die Auffassung, dass es in Kauf genommen werden kann, proprietäre UUID-Generatoren zu verwenden, solange diese Funktion gekapselt ist, und damit jederzeit durch eine andere Implementierung abgelöst werden kann.

Primary Key: OID vs. (Aneinanderreihung) fachlicher Attribute

Seit Jahrzehnten werden fachliche Schlüssel für eindeutig erklärt, und gegen jeden gesunden Menschenverstand als Primärschlüssel eingesetzt. Wenn kein einzelner 'eindeutiger' fachlicher Schlüsselwert für ein Objekt (Tabelle) identifiziert werden kann, werden solange weitere Attribute an den Primärschlüssel angehängt, bis die Eindeutigkeit erreicht zu sein scheint.

Der Kardinalfehler hierbei besteht darin, dass Geschäftsprozessen und deren Objekten Statik im Sinne von Unveränderbarkeit für den angenommenen Lebenszyklus der Software unterstellt wird, zudem ist das Handling segmentierter Primärschlüssel schon aus rein technischer Sicht angewandter Wahnsinn.

Geschäftsprozesse jedoch sind wandelbar. Sie ändern sich schneller, als die Fachabteilung Verifikationen an die Softwareentwickler weitergeben kann. Die Implementierung dieser Updates in hoher Kadenz übersteigt zudem die Leistungsfähigkeit der meisten Entwicklungsteams, weil sie sehr unprofessionell technische und fachliche Aspekte vermengen und/oder mit 'gegebenen' (veralteten und zillionenfach duplizierten) Strukturen zurechtkommen müssen. Viele Projekte gehen 'nie' in Produktion, weil die Fachabteilungen 'ihr Geschwätz von gestern heute nicht mehr interessiert' und die Produkte vor Fertigstellung verworfen werden müssen. Wie kann man in solchen Umgebungen von Statik ausgehen?

Was die Fähigkeit von Entwicklern zur Einschätzung von Lebenszyklen angeht, sei nur auf das Problem der zweistelligen Jahreszahlen im Datum verwiesen. Noch heute werden unzählige kommerzielle Applikationen in Assembler oder Cobol-61 gewartet und betrieben, weil sie 'nicht ersetzbar' sind. Selbst bei Revamps und Portierungen ist es hier und da unumgänglich, die Datenstrukturen mehr oder weniger unverändert zu belassen. Wie kann man mit diesem Wissen von 'best before' Zeitachsen für komplexe Softwarewelten träumen?

Pro OID

1) Es gibt keine dauerhaft eindeutigen 'fachlichen Schlüssel', da sich verändernde Geschäftsprozesse irgendwann bei jedem Attribut eine Änderung erzwingen. Selbst Konto, Personal- oder Kundennummern, die aufgrund der Herkunft aus dem externen Rechnungswesen oft als 'unveränderbar' betrachtet werden, werden sich beim Überlauf der gewählten Nummernkreise, einer Fusion o.ä. ändern (müssen). Auch die Idee, verbreitete externe Nummernkreise wie Postleitzahlen usw. zu benutzen, scheitert nicht nur nach einer großen gelben Reorganisation (wie der Umstieg von 4 auf 5stellige PLZ), sondern schon beim ersten Umzug des referenzierten Objekts.
Werden Relationen mit sog. 'fachlichen Schlüsseln' implementiert, ist diese spätere Änderung fast unmöglich bzw. artet in mehrjährige ABM-Maßnahmen aus. Werden dagegen technische ID's verwendet, wird der fachliche Wert (an der Oberfläche von der verantwortlichen Fachabteilung, ohne Involvierung der IT/Orga) eben geändert und Inkonsistenzen sind trotzdem sicher ausgeschlossen. Der Begriff 'fachlicher Primärschlüssel' existiert nicht, dieser Sprachmissbrauch ist nur im unternehmensspezifischen Kontext vieler Grossanwender (sog. '1:1-Übernahme' angeblich rein fachlicher Modelle ins phys. Design) überhaupt ansatzweise erklärbar.

2) Primary Keys, die aus einer Sequenz mehrerer fachlicher Attribute bestehen, sind sehr schwer zu handhaben. Die Joins sind viel zu kompliziert und langsam (teuer), Konsistenzchecks und Validierungen sind unnötig komplex und last but not least können sämtliche (state of the art) Design- und sonstigen Tools mit solch fragwürdigen Konstrukten gar nicht umgehen (führt zu schlimmem Fehlverhalten wie z.B. automatische Erzeugung der für FK's fehlenden Attribute). Dass RDB's das überhaupt zulassen, ist ausschliesslich historisch motiviert (die ersten RDB-Implementierungen waren nicht etwa Neuentwicklungen oder Redesigns, sondern Ablösungen proprietärer (ISAM ...) Files durch Datenbanktabellen) und kann nicht als Argumentation für unprofessionelles Design herhalten. RI und vergleichbare Validierung hat nach dem Stand der Technik (entgegen der die relationale DB Theorie -zumindest in ihrer praktischen Anwendung- fehlinterpretierenden -sprich: vergewaltigenden- landläufigen Lehrmeinung) im fachlichen Code nichts zu suchen. Punkt.

3) Auch im 'herkömmlichen' Design (frühere Paradigmen) entspricht es dem Stand der installierten Technik und Wissenschaft, dass Tupel durch einen einzigen technischen Schlüssel (Primary Key) identifiziert und so auch jegliche Beziehungen realisiert werden. Seit Einführung der RDB's wurden trotzdem unzählige Mannjahrtausende damit verschwendet, dieses Gesetz zu umgehen und dann anschließend noch einmal unendliche Zeit dafür verbraten, die Folgen zu beseitigen, wenn die 'Ergebnisse' nicht einfach weggeworfen wurden (das ist nämlich billiger und außerdem sicher).

4) Objekte benötigen eine ein-eindeutige Identität. Der Versuch, ein on-the-fly-mapping fachlicher Attribute (üblicherweise noch über viele Columns) zu Objektidentitäten zu installieren, muss spätestens bei Software-Systemen fehlschlagen, die das gleiche/identische Objekt zur Laufzeit in verschiedenen Rollen verwenden ... von der Unmöglichkeit der Realisierung mit Bordmitteln auch großer Unternehmen einmal ganz abgesehen.

Contra OID

Es gibt Situationen, in denen ein OID nicht zwingend benötigt wird. Dazu gehört z.B. die Quelle bei Einmalverarbeitungen flacher 'Wegwerfobjekte' in großen Massen sowie auch möglicherweise Entitäten wie Währungen, Sprachen, Länder usw., bei denen die Ein-Eindeutigkeit des Schlüssels durch ein internationales Gremium sichergestellt ist (Anmerkung: auch bei diesen Schlüsseln handelt es sich letztlich meist um technische Schlüssel. Leider sie sind nicht ganz änderungssicher, z.B. der numerische CountryCode der ISO-3166 unterlag bereits Änderungen).

Im ersten Fall kann allerdings, sofern aus den Quelldaten normalisierte BusinessObjekte erzeugt werden, beim Ziel selbstverständlich nicht auf die OID verzichtet werden, und das ist normalerweise sogar noch mit einer nicht einmal geringen Speicherplatzersparnis verbunden. Es ist unmöglich, hier an eine gegebene Liste von Attributen in einer Entität einfach ein weiteres namens 'OID' anzuhängen und fertig ist das BusinessObject. OO-Software wird mit solchen datengetriebenen Strukturen mit Sicherheit nicht funktionieren. Diese Datensätze enthalten i.d.R. einige Felder, die im Objektmodell nicht (mehr) benötigt werden (Kennziffern u.ä. stehen oft für Verhalten und werden im Objektmodell transient. Strings mit wenigen Variationen weisen auf Subklassen hin, und schon 'mappen' mehrere Klassen eine Entität, was auch zu weniger Speicherverbrauch führt, da jede Klasse nur noch die eigenen Attribute persistent macht u.s.w. u.s.f.). Es mag natürlich Ausnahmen geben, aber i.d.R. wird die Summe der erzeugten Objekte weniger Speicher belegen als die Quelldaten.

Im zweiten Fall bietet sich aufgrund der geringen Anzahl von Instanzen allerdings an, auf zusätzliche Komplexität in der Klassenhierarchie, Entwicklung und Test zu verzichten, und auch diese wenigen Objekte mit OID zu führen.

Ein schönes Summary dazu von Scott W. Ambler

Keys With Business Meaning Are a Bad Idea...
Experience with mapping objects to relational databases leads to the observation that keys shouldn't have business meaning, which goes directly against one of the basic tenets of relational theory. The basic idea is that any field that has business meaning is out of the scope of your control and therefore you risk having its value or its layout change. Trivial changes in your business environment, perhaps customer numbers increase in length, can be expensive to change in the database because the customer number attribute is used in many places as a foreign key. Yes, many relational databases now include administration tools to automate this sort of change, but even so it's still a lot of error-prone work. In the end I believe that it simply does not make sense for a technical concept, a unique key, to be dependent on business rules. The interesting thing is that data modelers call keys with business meaning 'smart keys,' yet experience has shown that a more appropriate term would have been 'incredibly stupid keys.' Goes to show what data modelers know!
...And So Are Composite Keys
While I'm attacking the sacred values of DBAs everywhere, composite keys (keys made up of more than one column) are also a bad idea. Composite keys increase the overhead in your database as foreign keys, increase the complexity of your database design, and often incur additional processing requirements when many fields are involved. My experiences is that an object id (OID), a single column attribute that has no business meaning and which uniquely identifies the object, is the best kind of key. Ideally OIDs are unique within the scope of your enterprise-wide database(s), in other words any given row in any given table has a unique key value. OIDs are simple and efficient, their only downside is that experienced relational DBAs often have problems accepting them at first (although fall in love with them over time).


Aus Mapping Objects To Relational Databases by Scott W. Ambler

Ich behaupte: Prinzipiell kann man auf den OID nirgendwo verzichten. Aber die Welt ist nicht in jeder Ecke schön und ein Slum wird nicht dadurch wohnlich, daß man einen Weihnachtsbaum darin aufstellt. Deshalb sollte man sich die konkrete Aufgabe und den Kontext genau ansehen und individuell und pragmatisch entscheiden. Purismus zahlt sich wenig aus.

Kosten, Risiken, Nebenwirkungen


Kosten

In dezentralen Umgebungen lässt sich der UUID sozusagen kostenlos über OS-APIs beziehen. Auf dem Mainframe muss der Algorithmus in Cobol bzw. PL1 mit der Adresse einer vernichteten Netzwerkkarte 'nachgebaut' werden. Viele IBM-Anwender haben das bereits seit längerem realisiert, so dass Musterroutinen leicht erhältlich sein sollten.

Der UUID als OID benötigt je Tupel 16 Byte Speicher. Bei kleinen Tabellen spielt das keine Rolle und bei sehr großen Datenbeständen ist alternativ die Eindeutigkeit selten über die Verkettung fachlicher Attribute sicherzustellen. Falls kurzfristig und vorübergehend doch einmal, zumindest nur mit einem Mehr an 'Speicherverbrauch'.

Die tatsächlichen Kosten spielen sich also gar nicht in diesem konventionell kalkuliertem Bereich ab, sondern verbergen sich eher in Ausbildungsmaßnahmen und Aufwendungen im Redesign bzw. der Nachrüstung.

Risiken

Das wesentliche Risiko des OID ist, dass er nicht konsequent überall dort eingesetzt wird, wo es Sinn macht, denn Softwaresanierung ist extrem teuer und tut gerade nach erst kurzen Lebenszyklen besonders weh. Noch einmal vorsichtshalber: es bringt keinen Sinn, ohne logische Änderungen, also Redesign, an vorhandene Datenbestände einfach einen OID anzuhängen. Aber überall dort, wo laufende (MVS-)Projekte technische Schlüssel einsetzen, und natürlich bei jeder Neuentwicklung, sollte mit OID/UUID gearbeitet werden, und zwar auf jeder Plattform incl. MVS.

Ein abzuwägendes Risiko ist der Einsatz eines properitären UUID-Generators. Es wäre auch denkbar, die Klasse OID mit Generator für ein Unternehmen oder Rechenzentrum selbst zu implementieren.

Nebenwirkungen

Keine bekannt ... (Fragen Sie Ihren Arzt oder Apotheker, die kennen ähnliche Verfahren (z.B. bei Artikel- und Chargennummern) bereits seit Jahrzehnten und werden Ihnen sicherlich zum durchgängigen Einsatz der OID raten.)

(Technische) Implementierung

· Alle persistenten Instanzen innerhalb des Objektnetzes werden eindeutig durch einen OID (UUID) bezeichnet. Der OID ist über alle Klassen hinweg eindeutig.

· Der OID darf niemals irgendeine fachliche Bedeutung bekommen (was beim Einsatz der UUID's wunderbarerweise (bis auf wenige Anwender mit eiditischem Gedächnis) einfach durch die Unmöglichkeit des Merkens gegeben ist).

· Der OID ist Primary Key jeder Tabelle.

· Der ColumnName der OID setzt sich aus dem (unternehmensweit eindeutigen) Tabellenpräfix und dem String 'OID' zusammen (Beispiel: 'kneOID' in der mit 'kne' gepräfixten Tabelle 'KreditNehmerEinheit').

· Alle Beziehungen werden über den OID hergestellt, ForeignKey-ColumnNames werden dabei nicht gepräfixt (Beispiel: In der Tabelle 'KreditNehmerEinheit' heißt der ForeignKey zur 'Organisationseinheit' 'orgeOID', nicht etwa 'FS_ORGE' oder 'FS_ORGEOID').

· Soweit es irgendwie möglich ist, werden Mehrfachreferenzierungen normalisiert, also möglichst sichergestellt, dass ForeignKey-Columns keine Namensabweichung zur PrimaryKey-Column aufweisen (Bedeutet: weitere Klasse(n), wenn ein Objekt in verschiedenen Rollen Attribut in einem anderen Objekt ist). Wird in Einzelfällen von dieser Regel abgewichen, darf in den Designtools niemals versucht werden, Beziehungen automatisch generieren/erkennen zu lassen, da das zu unkontrollierbaren und falschen Arbeitsergebnissen führt.

· Der 128Bit-OID wird in einem 16ByteArray CHAR (16) FOR BIT DATA gespeichert, nicht im Display-Format CHAR (32) oder CHAR (36).

· Sequentiell nur einmal zu verarbeitende Eingabedaten benötigen keinen OID. Werden aus diesen Daten allerdings Objekte erzeugt, z.B. zur Umsetzung von Historisierungsanforderungen mit Onlineverfügbarkeit, kann auf Normalisierung und Speicherung mit OID nicht verzichtet werden.



Author: Sebastian
LastUpdate: April 1999



Dieser Artikel ist die Kürzung einer Entscheidungsvorlage für eine deutsche Bank und wurde inhaltlich nicht überarbeitet, da die technische Entwicklung der letzten Jahre dies nicht rechtfertigt.

· Home

· Databases

· Object Identifier

· Web Links

· Link to us

· Contact

· What's new

· Site map

· Get Help


Most popular:

· Site Feeds

· Database Design Guide

· Google Sitemaps

· smartDataPump

· Spider Support

· How To Link Properly

· Der Organisations-Architekt

· Home Page Checkliste

· DB Primärschlüssel


Free Tools:

· Sitemap Validator

· Simple Sitemaps

· Spider Spoofer

· Ad & Click Tracking



Search Google
Web Site

Add to My Yahoo!
Syndicate our Content via RSS FeedSyndicate our Content via RSS Feed



To eliminate unwanted email from ALL sources use SpamArrest!






Digg this · Add to del.icio.us · Add to Furl · We Can Help You!




Home · Categories · Articles & Tutorials · Syndicated News, Blogs & Knowledge Bases · Web Log Archives


Top of page

No Ads


Copyright © 2004, 2005 by Smart IT Consulting · Reprinting except quotes along with a link to this site is prohibited · Contact · Privacy