An vielen Stellen in der Prozedur-Dokumentation taucht der Begriff „UserID“ bzw. „PersonID“ auf. Dabei handelt es sich um Benutzer bzw. Personen, die in der Engine (genauer der „Customer-DB“) gespeichert sind - jedoch eine völlig unterschiedliche Bedeutung haben. Klarer ausgedrückt : Benutzer und Personen haben überhaupt nichts miteinander zu tun !

Anmerkung : Aus praktischen Gründen gibt es aber das Feature, beim Anlegen eines Benutzers auch eine Person (eines bestimmten Typs) gleichen Namens zu erstellen. Näheres hierzu wird in der Dokumentation von mi_CreatedStoreUser_Ad (Parameter „@CreatePersonWithPassword„) beschrieben. Einen klassischen Anwendungs-Fall kann man z.B. den Dokumentationen von ac_InsertActionLog_Ad (Hinweis 3) und ac_ModifyCommands_Ad entnehmen.

Mit der Klärung, worum es sich genau bei Benutzern und Personen handelt und wie sie sich unterscheiden, beschäftigen sich die folgenden beiden Abschnitte.

Wann immer von Benutzern die Rede ist, sind Benutzer der Engine gemeint. Diese werden eindeutig über eine „UserID“ (eine „smallint“-Zahl) identifiziert, die in der Tabelle „UserInfo“ gespeichert ist. Der im entsprechenden Datensatz gespeicherte „UserName“ referenziert (eindeutig) einen Datenbank-Benutzer (die Namen stimmen exakt überein), der wiederum einem (Server-)Login zugeordnet ist.

Hierzu kurz eine nicht ganz unwichtige Erläuterung zur Funktionsweise einer „Datenbank-Anmeldung“ beim ASE von Sybase : Wie im Kapitel „Architektur“ (Abschnitt „Datenbank-Software“) schon erwähnt, verwaltet ein (ASE-)Server mehrere Datenbanken. Daher gibt es auch genau genommen keine Datenbank-Logins sondern nur Server-Logins. Diese bestehen aus einem (Login-)Namen und einem zugehörigen Kennwort. Nach erfolgreichem Login hat man (bis auf besondere Ausnahmen hinsichtlich sogenannter „Rollen“, auf die wir hier aber nicht näher eingehen) zunächst ersteinmal nur Zugang auf bestimmte System-Datenbanken. Auf andere Datenbanken kann man nur zugreifen, wenn es dort einen Benutzer gibt, der diesem Login zugeordnet ist - und es kann pro DB nur maximal einen solchen Benutzer geben !

Es ist also prinzipiell möglich, einen Benutzer „Hans“ zu haben, der sich aber mit dem (Login-)Namen „Gretel“ und dem Kennwort „Brotkrumen“ anmeldet. Einen neuen Benutzer sollte man aber, um nicht unnötig Verwirrung zu stiften, immer so anlegen (und zwar mit mi_CreatedStoreUser_Ad), daß Login-Name und Datenbank-Benutzer-Name (und damit automatisch auch Engine-Benutzer-Name) identisch sind.

Benutzer lassen sich ganz grob in…

• SmartGates-Benutzer (für automatisierte Aufgaben wie z.B. Schnittstellen) und
• Anwender (i.d.R. interne oder externe Mitarbeiter)

… unterteilen.

Mehr zu gewissen „vordefinierten“ (also von „SmartGates“ benötigten) Benutzern steht in der Dokumentation von mi_GetUserInfo_Ad.

Sofern nicht aus dem Kontext hervorgeht, daß allgemein „Individuen“ oder „Menschen“ gemeint sind, handelt es sich bei Personen um in der Tabelle „Persons“ gespeicherte Datensätze, die zunächst einmal eindeutig durch eine „PersonID“ (eine „integer“-Zahl) gekennzeichnet sind. Diese besitzen gewisse Eigenschaften, die wir auch „personenbezogene Daten“ nennen - letztlich also z.B. Kunden- oder Lieferantendaten.

Hinsichtlich der Eigenschaften, genauer eigentlich „Merkmale“, lassen sich Personen nach Typen unterteilen, wie z.B. „Privatkunden“, „Community-Mitglieder“ etc. Je nach Typ gibt es unterschiedliche Merkmale, zu denen Personen Eigenschaften besitzen, die sie eindeutig identifizieren. Bei Personen des Typs „Mitarbeiter“ wäre es z.B. das Merkmal „Personal-Nummer“, bei „Privatkunden“ z.B. die „Kunden-Nummer“ oder die „E-Mail-Adresse“.

Genau wie bei Benutzern, die durch eine Information, nämlich den (Login-)Namen, zwar bereits eindeutig identifiziert werden, möchte man jedoch eine oder mehrere zusätzliche Informationen haben, die nur derjenige kennt (oder zumindest kennen sollte), der tatsächlich gemeint ist - klassischerweise ein Kennwort. Zusammengenommen nennen wir diese Informationen bei Personen die „Identifizierungs-Daten“.

Personen werden anhand der Identifizierungs-Daten von Prozeduren identifiziert - die Daten werden immer als Werte-Liste zu einem Parameter übergeben, der i.d.R. „PersonIdentificationValues“ heißt. Der genaue Identifizierungs-Vorgang ist in der Dokumentation zur Prozedur pm_CheckPersonIdentity_Pu beschrieben.

Die Notwendigkeit von Personen und Ihrer eindeutigen Identifizierbarkeit liegt auf der Hand, da man z.B. wohl kaum für jeden Neu-Kunden, der einen Auftrag platzieren möchte, einen Benutzer (und damit auch einen Benutzer in der Datenbank) anlegen will…

Bei Web-Anwendungen, die intern meistens genau ein bestimmtes Login für die Datenbank verwenden (im dStore ist dies der Benutzer „publicuser“), muß zudem sichergestellt werden, daß eine Person z.B. nur ihre eigenen Daten einsehen und ändern kann. Um im Beispiel zu bleiben, würden also die Prozeduren pm_GetPersonProperties_Pu bzw. pm_ModifyPersonData_Pu verwendet werden.

Prozeduren hingegen, denen nur eine „PersonID“ übergeben werden muß, um Daten von Personen einsehen oder ändern zu können, sind aber logischerweise auch notwendig - z.B. für die Bearbeitung durch Call-Center-Agents oder Schnittstellen - denn alles andere ist nicht nur unpraktisch oder sogar unpraktikabel sondern im Vergleich auch zu unperformant. Dafür genau gibt es die „Ad“-Prozeduren, also die bereits erwähnten Prozeduren, deren Name auf „_Ad“ endet und für die nur Benutzer der (Datenbank-)Gruppe „admin“ Ausführungsrechte besitzen. Um wiederum beim Beispiel zu bleiben : pm_GetPersonProperties_Ad und pm_ModifyPersonData_Ad wären da geeignete Kandidaten.

Jetzt braucht man nur noch einen Benutzer, der auch in der Engine die Berechtigung besitzt, die besagte(n) Prozedur(en) auszuführen…