Attributes, resp. data items are one of the most elementary ressources of information management. Although source of much effort, data items are often neglegted. This paper reports a concept of natural naming conventions, which is founded on types of attributes. Typing allows the reuse of attributes in the context of different entity types or data base tables. The reuse reduces the number of attributes dramatically. The attribute names are also reused as variable names of programs without aliasing, which raises the self documentation power of a firm’s information resource software. The concept was empirically developped in a large renewal software project (44 man years) over more than 6 years and successfully applied by 36 developpers. The application is quantitatively analysed. 1 Problemstellung und Überblick Die Bedeutung der Ressource Information für den Erfolg von Unternehmen und als Teil davon der Daten wird seit langem betont [Nol79]. Dem steht eine Realität gegenüber, die Vetter schon 1982 drastisch beschrieb und die sich nach Einschätzung des Autors bis heute nicht wesentlich geändert hat: „Das Jahrhundertproblem der Informatik besteht in: 1. Der Bewältigung des Datenchaos, das infolge unkontrolliert gewachsener Datenbestände fast überall entstanden ist. 2. Der Schaffung einer Datenbasis, die für die effiziente Nutzung zukunftsträchtiger Möglichkeiten der Informatik ... unerläßlich ist.“ [Vett90, 5, 1.Aufl.1982]. Als Lösung aus der Krise werden seit Ende der 70er Jahre Unternehmens-Datenmodelle empfohlen [Sche78] und seit Mitte der 80er Jahre verstärkt in großen Unternehmen erstellt [vgl. z.B. MüEt89, Hanf91, Mert91, Fi92, Hell94]. Es gibt sogar ein sehr erfolgreiches Softwareprodukt, das System R/3 der Firma SAP, das auf Basis eines Datenmodells entwickelt wurde und gepflegt wird [Sche94]. Über die Nützlichkeit eines Unternehmens-Datenmodells (UDM) ist man sich einig und auch darüber, daß der Weg dorthin langwierig und aufwendig ist [Ortn91]. Aufwand und lange Entwicklungszeit entstehen durch Komplexität, Abstimmungsprozesse und Mengengerüste. Die Komplexitätsreduktion des unüberschaubaren Netzwerkes von Entitätsund Beziehungstypen ist Gegenstand verschiedener Vorschläge. Zum einen werden die Netze in eine übersichtlichere und leichter überprüfbare Struktur gebracht [Sinz88, Mis91]. Andere Autoren empfehlen eine topdown-Entwicklung [Vett90, 77ff.] oder zumindest eine hierarchische Darstellung in Ebenen [Sche94, 716f.]. Folgt man dem Gedanken der Ebenen, läßt sich das Mengenproblem eines UDM folgendermaßen darstellen: Tab. 1: Verfeinerungsebenen und Mengengerüste eines Unternehmens-Datemodells Ebene Bezeichnung Objekttpen Verwendung 1 Unternehmens-Datenmodell 7 30 grober Überblick („strategisches Modell“) 2 Detailmodell 200 500 Schulung, Überblick Funktionsbereiche 3 operatives Datenmodell 300 2.000 Softwareentwicklung Eine Zahl von 2.000 Objekttypen (Synonym: Entitätstypen) bildet entsprechend komplexe Strukturen betriebwirtschaftlicher Realität ab, die sich nicht ohne semantischen Leistungsverlust des Datenmodells reduzieren läßt. Hier gibt es so lange keinen Ansatzpunkt zur Komplexitätsreduktion, wie mit satzorientierten Datenhaltungssystemen implementiert wird, die über Schlüsselbeziehungen vernetzt sind (relationales Konzept). Doch was bedeuten 2.000 Objekttypen auf der Ebene der Attribute? Wenn wir durchschnittlich 10 Attribute pro Objekttyp annehmen und unterstellen, daß die Attribute disjunkt sind, erhalten wir 20.000 Elemente als kleinste für das Informationsmanagement zu handhabende Einheiten. Hier setzt der vorliegende Beitrag an, indem er ein Konzept vorstellt, die Zahl der Attribute des UDM und damit die Komplexität der betrieblichen Datenbasis drastisch zu reduzieren. Da die Begriffe Attribut, Datenelement und Feld nicht einheitlich benutzt werden, sei folgendes festgelegt: Ein Attribut ist die kleinste bedeutungstragende Einheit eines UDM und beschreibt eine Eigenschaft eines Objekttyps durch einen Namen und einen zulässigen Wertebereich (Typ oder Domäne). Wird ein Attribut in einer Datenbasis abgespeichert und damit um technische Eigenschaften erweitert, wird es zum Datenelement. Es kann mehrere (syntaktische) Datenelemente zu einem Attribut geben, wenn z.B. mehrere Programmiersprachen eingesetzt werden. Wird dasselbe Datenelement verschieden repräsentiert (Bildschirmmasken, Listen, spezielle Codierungen auf mehreren Servern), können daraus mehrere Felder werden wie Abbild 1 zeigt.
[1]
Thorsten Spitta,et al.
Entwicklung und Ergebnisse eines allgemeingültigen Fachkonzeptes für die Prüfungsverwaltung an Hochschulen
,
1995
.
[2]
Gordon C. Everest.
Database management : objectives, system functions, and administration
,
1986
.
[3]
Thorsten Spitta,et al.
Sechs Jahre Anwendungsentwicklung mit Prototyping
,
1993,
Requirements Engineering.
[4]
Helmut Mertes,et al.
Vorgehensweise für die Erstellung eines unternehmensweiten Datenmodells bei der Hoesch AG
,
1991,
Wirtsch..
[5]
Rom Narayan.
Data dictionary: implementation, use, and maintenance
,
1988
.
[6]
Thomas W. Hellmuth.
Datenmodellierung zur marktgerechten Führung der Produktionsbereiche
,
1994,
Informatik und Unternehmensführung.
[7]
Erich Ortner,et al.
Entwicklung und Verwaltung standardisierter Datenelemente
,
1990,
Inform. Spektrum.
[8]
Erich Ortner.
KASPER - Ein Projekt zur natürlichsprachlichen Entwicklung von Informationssystemen
,
1994,
Wirtsch..
[9]
Gabriele Dobenecker,et al.
Datenmodellverdichtung: Vom Projektdatenmodell zur Unternehmensdatenarchitektur
,
1992,
EMISA Forum.
[10]
Breck Carter,et al.
On choosing identifiers
,
1982,
SIGP.
[11]
Volker Hanf.
Integrierte Datenmodellierung bei BMW - ein Erfahrungsbericht
,
1991,
Wirtsch..
[12]
Erich Ortner.
Unternehmensweite Datenmodellierung als Basis für integrierte Informationsverarbeitung in Wirtschaft und Verwaltung
,
1992,
EMISA Forum.
[13]
Rainer Frölich.
Piloteinsatz der Ssystem-Entwicklungs-Technologie (SET) für den Anwendungsentwurf eines kommerziellen Großprojektes
,
1983,
GI Jahrestagung.
[14]
Elmar J. Sinz.
Das Strukturierte Entity-Relationship-Modell (SER-Modell)
,
1988,
Angew. Inform..
[15]
Andrea Back-Hock,et al.
Vorarbeiten für die Datenmodellierung am Beispiel zweier Industrieunternehmen: Automatisierte Dateninventur und elektronischer Begriffskatalog
,
1994,
Wirtsch..
[16]
Heinz Mistelbauer.
Datenmodellverdichtung: Vom Projektdatenmodell zur Unternehmens- Datenarchitektur
,
1991,
Wirtsch..
[17]
Gottfried Vossen,et al.
Datenmodelle, Datenbanksprachen und Datenbank-Management-Systeme
,
1990
.
[18]
Thomas Myrach.
Konzeption und Stand des Einsatzes von data dictionaries
,
1994
.