MySQL Generalisierung / Spezialisierung wie implementieren?

[Joggal]

Hallo Leute,

Angenommen ich habe ein ER Diagramm, mit einer Spezialisierung von Benutzern.

Nämlich: Ein Benutzer kann sein: ein Kunde, oder ein Administrator.
(jeweils 1:1 Beziehung)

Wo ich scheitere ist jedoch, wie ich das in der DB dann tatsächlich implementieren soll... zumal das ganze zB erweiterbar sein soll (z.B. soll Benutzer später auch ein Moderator sein können, mit anderen spezifischen Attributen)

Lösungsansatz:
a ) Wenn ich eine große Tabelle erzeuge mit einer Spalte "art" und da jeweils dann "admin" oder "kunde" eintrage, habe ich einige leere Felder von den anderen Spezialisierungen und bei einfügen von neuen Arten bläht sich die Tabelle schnell auf.

b ) 3 Tabellen (Benutzer, Kunde, Administrator)
Die Spezialisierungen (Kunde, Administrator) erhalten jeweils den Primary Key von Benutzer als deren PK.
Kommt mir aber eher nachteilbehafteter als a) vor, denn:
* Herausfinden welche Art Benutzer es denn jetzt ist, wird sehr umständlich

Hat hier eventuell ein Profi einen Tipp, wie man das ganze in der Praxis umsetzt?

Hoffe auf schnelle Antworten!

 

[Thallius]

Du machst eine Tabelle Kunde mit einer Spalte die den Kunden eindeutig identifiziert. Also z.B. eine Kunden-ID als primary key autoincrement.

Dann machst du eine Tabelle mit den Arten der Zugriffe. Also einen Zeile für Moderator, eine für Administrator etc. Diese haben wieder eine eine Spalte mit einer Unique-ID

Dann machst Du eine Cross-REferenz-Tabelle mit den Spalten Kunden-ID und Zugriffs-ID. Hier kommt dann eben für jeden Kunden soviele Zeilen rein wie er Zugriffe hat. Ist er Administrator und Moderator hast du zwei Einträge mit Kunden-ID -> Adminitrator-ID und Kunden-ID -> Moderator-ID

Gruß

Claus

 

[Dompteur]

Bist du dir sicher, dass du hier eine Ableitungshierarchie vorliegen hast ?

Für mich sind "Kunde" und "Administrator" Rollen einer Person. Eine Rolle erkennt man daran, dass sie sich mit der Zeit ändern kann. Eine Person kann ja zu einem Zeitpunkt Kunde und später (oder auch gleichzeitig) Administrator sein.

Unter Berücksichtigung dieser Tatsache würde ich das mit 3 Tabellen modellieren: Person, Kunde, Administrator. Die Persontabelle bekommt eine eindeutigen ID. Es wird dann ein Kunde- bzw. Administrator-Satz angelegt, wenn diese Person die entsprechende Rolle hat. Diese Sätze haben diese ID aus der Personentabelle als Fremdkey,

 

[ARadauer]

Wäre ein typisches Schulbeispiel, was man in der Praxis nie so umsetzen würde.
Ich würde es so bauen: Ein Benutzer, hat eine Liste von Rollen und eine Rolle hat eine Liste von Rechten.
Jeweils natürlich mit M:N Beziehungen die man auf Datenbankebene genau so abbildet wie Thallius beschrieben hat.

 

[Dompteur]

...Ein Benutzer, hat eine Liste von Rollen und eine Rolle hat eine Liste von Rechten.

Ich habe die Aufgabenstellung nicht so verstanden, dass es um eine Rechteverwaltung geht. Der Halbsatz ".. mit anderen spezifischen Attributen)" weist für mich eher in die Richtung, dass die beiden Rollen jeweils eine Reihe von Attributen haben.

In der Praxis müsste man also den Auftraggeber fragen, wie es wirklich ist...

 

[Tobse]

Ich stimme ARadauer zu. Du hast einfach eine Tabelle user. Ob ein User jetzt Administrator, Kunde, Moderator, Service-Mitarbeiter u.s.w. ist, hängt ganz allein davon ab, was der Nutzer darf.
Und diese Rechte werden ihm über Rollen zugewiesen: User zu Rolle 1:n (oder 1:1 der einfachheit halber), Rolle zu Recht 1:n

 

[fehlerfinder]

b ) 3 Tabellen (Benutzer, Kunde, Administrator)
Die Spezialisierungen (Kunde, Administrator) erhalten jeweils den Primary Key von Benutzer als deren PK.
Kommt mir aber eher nachteilbehafteter als a) vor, denn:
* Herausfinden welche Art Benutzer es denn jetzt ist, wird sehr umständlich

Gute Vorschläge zur Umsetzung hast du ja schon reichlich - zum Thema "umständlich" ist Folgendes zu sagen:

Dieses Problem hast du in vielen Bereichen (der Entwicklung, der EDV, des Lebens... ;-) ). Es ist immer ein Kompromiss zwischen "der reinen Lehre" und "Komfort" (jeweils im weiteren Sinne). Speziell in deinem Beispiel musst du entsprechend wählen zwischen:

a) "einfacher Abfrage"
Dann hast du das "Problem" der leeren Spalten, was tatsächlich kein Problem ist, denn "keine Daten" nehmen typischerweise nicht viel Platz in Anspruch und sowohl beim insert, update oder select kannst du die nicht benötigten Spalten einfach vernachlässigen. Unschön ist's trotzdem!!!

und

b) "Erweiterbarkeit"
Die gewonnene - und typischerweise absolut notwendige(!) - Flexibilität im Hinblick auf zukünftige Erweiterungen oder auch nur Anpassungen erkaufst du dir mit der ein oder anderen zusätzlichen JOIN-Bedingung. Das schreckt im ersten Moment etwas ab. Nach kurzer Zeit ist das reine Routine und du erstellst auch "ad hoc"-Statements für die kleine Abfrage zwischendurch automatisch und spielerisch leicht über fünf Tabellen hinweg.

Soweit das Wort zum Donnerstag ;-)