28. Juni 2008 

Ein Rolodex ist eine Volltext-Datenbank mit einem Index auf den ersten Buchstaben. Hier sammele ich hauptsächlich Adressen. Das funktioniert ganz gut, nur das Suchen ist mühselig.

Kaum eine Datenbank ohne Adressen. Eigentlich ist das Thema Adressen simpel. Name, Straße Postleitzahl und Ort ergeben eine Adresse und genauso werden die Felder in einer Tabelle angelegt.
Einen Moment nachdenken und Name sollte ich durch zwei Spalten ersetzen: Firma und Ansprechpartner. Der Ansprechpartner braucht drei Spalten, je eine für Vorname, Name und Anrede. Weitere Spalten sollte ich einrichten für Telefon, Fax, Handy und eMail. Meist reicht eine eMail-Adresse nicht hin, also aufteilen in eMail-Job und eMail-privat.
Mit einem Ansprechpartner komme ich nicht weit … doch nicht so einfach.

Wenn jeder Adressen in seiner Datenbank verwaltet, gibt es dann nicht eine Anleitung, wie das idealerweise geschehen sollte? Das Dilemma fängt schon mit der Bezeichnung an. Mit Adresse wird eine Postadresse oder eine Mailadresse oder eine im Netzwerk benannt. Personen und Firmen sind keine Adresse sondern haben Adressen.

Wo kann ich mich schlau machen?

Wie haben es andere gelöst?

OSX Adressbuch

Das Betriebssystem bringt ein Adressbuch mit. Das pflege ich, weil viele Funktionen von OSX darauf angewiesen sind. Jede Person kann mehrere Vornamen haben, mehr als eine Postadresse, dito Kommunikation, eMail und Homepage und und … das hat Apple nett gelöst.

Die Datenstruktur des OSX Adressbuch wäre eine Basis. Doch die Dokumentation, die ich bei Apple fand, hat mich nicht begeistert.

Weitere Information findet sich unter dem Thema vCard bzw. als RFCc2426 - vCard MIME Directory Profile standardisiert.

vCard ist Text. Ziehen Sie eine Adresse aus dem Adressbuch auf den Schreibtisch erzeugen Sie ein vCard-Dokument. Der Text läßt sich mit einem Texteditor und aus 4D öffnen. Im Texteditor sieht eine vCard so aus:

Für die eigene Datenbank-Struktur ist die Dokumentation zu vCard wenig hilfreich. Ich brauche das Wissen um das vCard-Format nur zum Austausch mit dem Adressbuch auf MacOS X von dort zum iPhone.

iAdressBook php-Lösung fürs Internet. Schöne Auflistung der Felder des Adressbuches.

Hilfreicher fand ich xCIL – eine Vorgabe der

Organization for the Advancement of Structured Information Standards

OASIS beschreibt seine Aufgabe so:

The OASIS Customer Information Quality Committee (CIQ) was formed to consult with the industry and develop open standards for the interchange of customer data. The committee has developed three XML Standards for Customer Information/Profile Management: xCIL, xNAL und xCRL

xCIL : extensible Customer Information Language

xCIL hat mich bestätigt, daß Organisationen (Firmen, Institutionen, Schulen/Universitäten, anderer Öffentlicher Dienst, …) in einer Tabelle zu erfassen sind und die Personen (xNL) in einer eigenen. Weitere Tabellen verwalten die Verbindung zwischen beiden Grundstrukturen und leiten über in xAL und xCRL.

xNAL : extensible Name and Address Language

Eigentlich sind das zwei Strukturen: xNL und xAL für extensible Name Language (Teil der Personen) und extensible Adress Language (Adressbeschreibung).

Vor Jahren habe ich die xCIL-Struktur graphisch aufbereitet. Sobald Personennamen (xNL) und Adress-Feingliederung (xAL) ausufern – es gibt nix, wat et nicht gibt – sind sie nicht mehr in der Graphik enthalten.

xCRL : extensible Customer Relationships Language

Hier ist viel zu finden, fast schon zu viel. Diesen Teil schaue ich mir erneut und genauer an, wenn es gilt eine konkrete Aufgabe zu realisieren oder meine Überlegungen gegen die anderer zu überprüfen.

Die OASIS-Papiere haben mir sehr weitergeholfen.

Andere Quellen

Google hat eine Contacts Data API veröffentlicht. Google schreibt dazu: Contacts are stored in the user's Google Account; most Google services have access to the contact list. Schauen Sie sich an, was Sie unter Kontakt erzeugen finden. Genau! Reicht nicht hin.

Schauen Sie sich die Yahoo! Address Book API an. Nur als Quercheck zu Ihren eigenen Überlegungen. Auch nicht das Gelbe vom Ei.

Normalisierung - Denormalisierung

Es gibt keine Struktur, die allen Anwendungen gerecht wird. Alleine die Protokollierung einer Diskussion um die OASIS-Vorgaben füllte ein Buch. Normalisieren Sie die OASIS-Vorgaben und vergessen Sie nicht als letzten Schritt die Denormalisierung, wie immer mit dem Ziel der Effizienzsteigerung.

Die praktische Umsetzung

Nebenstehende Graphik gibt eine aufs Wesentliche runtergebrochene Datenstruktur wieder. Es sind keine Felder dargestellt und keinerlei Denormalisierung. Metadaten sind in Klassifizierungen und Attribute nur angedeutet.
Customer bedeutet nicht Kunde sondern steht für den Begriff Customer aus xCIL. Es ist die Klammer, die Organisationen mit ihren Filialen und Mitarbeitern oder mehrere Personen zusammenhält. Mitarbeiter ist eine Person, die über ihre Organisation einem Customer zugewiesen ist. Das Customerkonzept aus xCIL macht es einfach sowohl Organisationen als auch Privatperson als Kunden zu haben und gleichwertig in der Datenbank zu organisieren ohne alles doppelt programmieren zu müssen.

Die Anwender meiner Lösungen haben Kunden aus allen Gegenden der Welt. Trotzdem habe ich mich entschieden, vorrangig die mitteleuropäischen Strukturen Firmen, Personen, Adressen abzubilden. Weil ich durch die OASIS-Dokumente mehr Vielfalt kennenlernte, konnte ich mir die Option offenhalten, Elemente aus den xCIL, xNAL und xCRL später einzubinden. Das hat sich bewährt.

Suchen Sie noch einen Sparring-Partner, um Ihre eigene Datenbank zu optimieren oder zu internationalisieren oder in Richtung xCRL auszubauen, stehe ich Ihnen gerne für 4D coaching physisch und online zur Seite – rein alphabetisch bisher von Aruba bis nach Wittmund, auf deutsch und auf englisch.

4D Themen: Berichte in Arbeit