Problem beim DB-Design

[cribe]

Hallo.
Der Titel dieses Themas ist zwar etwas wage aber ich versuche mal, mein Problem zu erklären:


Es gibt Personen und Administratoren.
Personen beinhalten andere Daten wie Administratoren.
Am System anmelden können sich alle Administratoren und gewisse Personen.
Die LoginDaten sind in einer separaten Tabelle gespeichert.
Ein Eintrag aus der Login-Tabelle gehört dementsprechent enweder zu einer Person oder zu einem Administrator.

Wie sieht hier jetzt ein korrektes Datenmodell aus? Es ist ja eigentlich keine richtige 1:1 und auch keine richtige 1:n beziehung.
Ich habe es vorher so gelöst, dass ich in der Tabelle Person und in der Tabelle Administrator extra jeweils "Username" und "Passwort" gespeichert habe, aber das war auch umständlich weil ich immer beide Tabellen überprüfen musste, wenn sich ein Benutzer eingeloggt hat und ich musste immer nachsehen ob es nun eine Person oder ein Administrator ist.

So sieht mein ERD jetzt aus.
http://chwe.at/sonstiges/erd.png

Ich hoffe, du kannst mir helfen!

Mfg, Christian

[elrond]

ich denke, dass du es dir ein wenig zu schwierig machst

mein erd zu deinem prob würde so aussehen:
http://www.illner-blankensee.de/pix/edr.jpg

in der tabelle Personentyp steht dann drin ob der angemeldete Benutzer einfacher User oder Admin ist. Ist er admin kannst du den Aufgabenbereich benutzen.

Wenn du wirklich daten zum login speichern willst, kannst du die personid als Fremdschlüssel benutzen...

<klugscheiss>
Tabellen Person und Administrator:

Zwei Tabellen gleicher Struktur in einer DB zu haben ist idR. nur in einem Fall sinnvoll, nähmlich dann wenn die Tabelle sehr groß werden würde und dadurch zu Performanceprobleme zu erwarten sind... :cool:
</klugscheiss>

[cribe]

danke für die antwort.
ich habe es aber mittlerweile so gelöst, wie es mein projektleiter wollte :)
hab jetzt 2 tabellen: "Person" und "Administrator" und jede hat die attribute "username" und "passwort".

andere frage: welches tool hast du verwendet, um das db-modell zu zeichnen und was kann es alles?

Mfg!

[elrond]

naja, ist schon nicht schlecht so ein projektleiter... :rolleyes:

für's DB-Design benutze ich ERwin ein relativ altes Tool ehemals von Platinum jetzt in den Händen von CA

[sticky bit]

ich habe es aber mittlerweile so gelöst, wie es mein projektleiter wollte :)
hab jetzt 2 tabellen: "Person" und "Administrator" und jede hat die attribute "username" und "passwort".Ach du grüne Neune! Mach das bloss nicht, erstens musst Du jetzt in zwei Tabellen nachsehen beim Login und zweitens hohlt man sich mit so ner Verteilung von gleichen Attributen nur Ärger ins Haus. OK ist noch nicht der ganz schlimme Fall (wo Werte redundant gespeichert werden anstatt auf sie referenziert zu werden), aber immerhin, stell Dir jetzt mal vor der Login Name soll erweitert werden, also z. B. statt 32 Zeichen 64, dann musst Du das an zwei Stellen ändern (OK, zwei scheinen jetzt nicht viel, aber wenn so ein System grösser wird kommt da evtl. noch so ne Tabelle und noch eine und nach ner Zeit hat man das dann auch nimmer genau im Kopf dass man sich da um mehr kümmern muss). Tu sowas um Gottes Willen nicht, ich hab mit so nem verkorksten System jeden Tag zu tun was da immer für versteckte Fehlerquellen sind... :/

Nimm doch das was elrond vorgeschlagen hat einfach mit ner Typ-Kennung.
Hat den einzigen Nachteil dass es nicht ganz sauber ist, wenn sich ausser Personen auch z. B. Maschinen einloggen können sollten, dann müsste man entweder den Login und das Passwort wieder in eine eigene Relation packen oder die Maschine halt als Person ansehen, auch wenn dann evtl. die Attribute nicht mehr passen oder die Werte je nach Kontext eine andere Bedeutung haben, was wieder problematisch werden kann. Also wär in dem Fall dein erster Entwurf gar nicht so schlecht, ausser dass vielleicht dann von Person aus auf Administrator referenziert werden sollte sofern der Administrator nur eine Person sein kann. Die Namen sollten allerdings auf jeden Fall nicht doppelt auftauchen, also in Administrator und Person sondern nur in Person...

[mwanaheri]

Ach du grüne Neune! Mach das bloss nicht, erstens musst Du jetzt in zwei Tabellen nachsehen beim Login und zweitens hohlt man sich mit so ner Verteilung von gleichen Attributen nur Ärger ins Haus.

Kann mich nur anschließen. Hier droht eine Speicheranomalie, weil Daten mehrfach gespeichert werden. Der Username ist ja wohl eindeutig, also gehört er als Schlüssel in eine eigene Tabelle, in der dann z.B. auch noch das Passwort gespeichert werden kann.
In allen anderen Tabellen wird dann nur noch darauf referiert (foreign key). Andernfalls besteht einfach die Gefahr, dass in deinen Daten der gleiche User mit zwei Passwörtern auftaucht. Und so was möchte ich nicht in Ordnung bringen müssen. Wenn du das Passwort in einer Tabelle ebenfalls brauchst, erledige so etwas über einen view.

[sticky bit]

Der Username ist ja wohl eindeutig, also gehört er als Schlüssel in eine eigene Tabelle (...)
Auch keine so gute Idee "Nutzdaten" zum schlüsseln zu verwenden, ein Schlüssel sollte was abstraktes sein (Hochgezählte Zahl, Random String, etc.) was sich während der "Lebenszeit" eines Tupels nie ändert. Wenn man nämlich "Nutzwerte" zum Schlüssel her nimmt ist man in den Hintern gekniffen, wenn sich diese ändern sollen (bei nem z. B. Login ja durchaus nicht unmöglich), dann muss man gucken dass man mit Triggern seine Datenbank in Ordnung hält, was Performance kostet, in ungünstigen Konstellationen verhädert man sich mal eben, und wenn man ein DBMS hat was gar keine Trigger kann, dann musste das alles in den Client programmieren und musst bei direkten Änderungen auf der Datenbank immer daran denken oder wenn man nen neuen Client baut, nicht empfehlenswert IMHO so ne Vorgehensweise...

[mwanaheri]

Wenn du von Bewegungsdaten reden würdest, gäbe ich dir recht. Usernamen sind aber eher statische Daten. Und da ein künstlicher Schlüssel nicht nur zusätzliche Daten bedeutet, sondern auch nicht sicherstellt, dass die Daten, auf die es ankommt, nämlich die usernamen, eindeutig sind, widerspreche ich.
Wie willst du - vom Datenmodell her gesehen - sicherstellen, dass ein username nicht zweimal vergeben wird?

[elrond]

in den Modellen die ich kenne ist es üblich eine userid zu vergeben und den usernamen ggf. über constraints eindeutig zu halten. das ist in der db schon über einen uniqe index zu realisieren.

Das eine userid in weiteren tabellen, bzw. Coockies etc. einfacher zu verarbeiten ist als ein Name mit ggf. Sonderzeichen und anderem "Schmutz" ist ein weiterer Grund den Namen nicht direkt zum Schlüssel zu machen.

Wer trotzdem darauf besteht sollte dann wenigstens einen md5 hash bzw. dessen hexwert des namens benutzen...=>sind keine bösen Zeichen drin... ;)

[sticky bit]

Wer trotzdem darauf besteht sollte dann wenigstens einen md5 hash bzw. dessen hexwert des namens benutzen...=>sind keine bösen Zeichen drin... ;)*lol* dann kannste bis Sankt Nimmerlein warten wenn Du z. B. eine Liste mit Usern generien willst und dann anfangen musst per Brute Force den Usernamen zurück zu gewinnen... ;)
(Um keine Missverständnisse zu erzeugen, ich meine sehr wohl Ironie in diesem Deinem Satz erkannt zu haben... ;) )

Übrigens weiterer Punkt der gegen die Usernamen als Schlüssel spricht ist ne Sache die ich weiter oben schon ange,erkt habe, man stelle sich vor man will den Usernamen nun erweitern (z. B. 32 auf 64 Zeichen) dann kann man alle FK Spalten in den Relationen die darauf referenzieren gleich mit ändern. Dass man die (abstrakten) ID Längen oder Datentypen ändert kommt dann doch eher sehr, sehr selten vor, ausser man plant wirklich immer völlig palle oder spart getreu dem Motto Geiz ist Geil auch noch das letzte Bit ein und macht die ID Spalten nur so breit dass sie gerade eben die Menge an Datensätzen in der Tabelle schlüsseln können... ;)

[mwanaheri]

Bezüglich der Speicheranomalie scheint ja Einigkeit zu herrschen.


in den Modellen die ich kenne ist es üblich eine userid zu vergeben und den usernamen ggf. über constraints eindeutig zu halten. das ist in der db schon über einen uniqe index zu realisieren.

Das heißt also, einen natürlichen Schlüssel zugunsten eines künstlichen zu verwerfen, um dann das benötigte Verhalten über Constraints zu rekonstruieren. Umständlich, oder?
Abgesehen davon: Dass etwas üblich ist, beweist die Machbarkeit, aber nicht die Sinnhaftigkeit.
Schau dir mal die Tabellen eines SAP-Systems an. Da sind ganz andere Sachen üblich.


Das eine userid in weiteren tabellen, bzw. Coockies etc. einfacher zu verarbeiten ist als ein Name mit ggf. Sonderzeichen und anderem "Schmutz" ist ein weiterer Grund den Namen nicht direkt zum Schlüssel zu machen.
Wer trotzdem darauf besteht sollte dann wenigstens einen md5 hash bzw. dessen hexwert des namens benutzen...=>sind keine bösen Zeichen drin... ;)
Mal ehrlich, wer will schon Usernamen mit "bösen Zeichen" auf seinem System zulassen? Man wird ja gelegentlich mal den usernamen parsen wollen...
Abgesehen davon sind die "bösen Zeichen" ein Problem des DBMS und nicht des Datenmodells.


Übrigens weiterer Punkt der gegen die Usernamen als Schlüssel spricht ist ne Sache die ich weiter oben schon ange,erkt habe, man stelle sich vor man will den Usernamen nun erweitern (z. B. 32 auf 64 Zeichen) dann kann man alle FK Spalten in den Relationen die darauf referenzieren gleich mit ändern[...]

Das ist nun wieder eine Frage der Felddimensionierung und wiederum keine Frage des Datenmodells.

[elrond]

@mwanaheri

ohne die auf den imaginären schlips treten zu wollen... Arbeitest Du auch praktisch in Datenbanken ? oder anders gefragt... Sind Deine Einwände akademischer Natur, oder hat's einen praktischen Hintergrund?

übrigens:

Die Sache mit dem md5-Hash ist ernst gemeint, dabei bleibt der natürliche Schlüssel erhalten und damit auch dessen Funktion...

[mwanaheri]

@mwanaheri

ohne die auf den imaginären schlips treten zu wollen... Arbeitest Du auch praktisch in Datenbanken ?

Yep.


oder anders gefragt... Sind Deine Einwände akademischer Natur, oder hat's einen praktischen Hintergrund?

Keineswegs akademisch. Zugegeben, ich bin noch recht neu in dem Geschäft, aber der Hinweis auf SAP war kein Zufall.

Was das "Akademische" anbelangt, erinnere ich mich noch gut an das Motto eines hauptberuflichen Datenbankdesigners:
"Den Datenbankdesigner hat nicht zu interessieren, ob ein Design auf einem DBMS umsetzbar ist." Weil man besser die DBMS nach den Erfordernissen des Designs wählt. Das halte ich in der Konsequenz auch für übertrieben.

[elrond]

SAP kenne ich (leider oder zm Glück?) nicht aus der Nähe, daher kann ich zu deren Datenbanken nichts sagen...

Was ich kennen und hassen gelernt habe ist Navision und deren "Datenbanken"... :eek:

[mwanaheri]

Ach, deren Datenbanken sind schon ok, wenn auch reichlich umfangreich -- es wird wirklich alles in die Datenbank gepackt, Lokalisierungen, Feldbezeichnungen, Programme ... Da kommen schnell mal ein paat tausend Tabellen für ein einfaches System zusammen.
Abap allerdings ist eine eher wunderliche Sprache. Prozedurales, strukturiertes und objektorientiertes Programmieren in einer Sprache eingebaut, jeweils mit Sonderfunktionen. Ich habe mitunter den Verdacht, dass das Gehalt von Abap-Entwicklern ein Schmerzensgeld ist ;-)

Ich kann mir schon vorstellen, dass eine Nummernvergabe für den Schlüssel auch bei Usernamen mitunter sinnvoll ist. Ich denke halt nur, dass man das dann nimmt, wenn man muss und nicht von vornherein den direkten Zugang ausschließen sollte -- er vereinfacht ja auch einiges.

[Gaert]

Ich habe mitunter den Verdacht, dass das Gehalt von Abap-Entwicklern ein Schmerzensgeld ist ;-)
Da könntest du recht haben :rolleyes:

[sticky bit]

Das heißt also, einen natürlichen Schlüssel zugunsten eines künstlichen zu verwerfen, um dann das benötigte Verhalten über Constraints zu rekonstruieren. Umständlich, oder?Naja, wenn man mal davon absieht, dass in einigen DBMS einfach ein Unique Constraint (und ein NOT NULL) für eine PK deklarierte Spalte erzeugt wird. Also ich finde diese "unnatürliche" Handlung nun nicht so schlimm wie die Probleme die man nachher evtl. bekommen kann...


Abgesehen davon: Dass etwas üblich ist, beweist die Machbarkeit, aber nicht die Sinnhaftigkeit.Stimmt. Liefert aber auch keinen Gegenbeweis...


Schau dir mal die Tabellen eines SAP-Systems an. Da sind ganz andere Sachen üblich.Die da wären?


Das ist nun wieder eine Frage der Felddimensionierung und wiederum keine Frage des Datenmodells.Naja, zumindest wenn man daran arbeitet ein System Umzusetzen, also zu implementieren, zähle ich die Felddimensionierung zum Datenmodell mit dazu. Mag sein, dass das irgendwoanders anders definiert ist. Ändert aber nichts an der Tatsache, das Systeme sich im Laufe ihres Lebens verändern und diese Veränderungen auch Veränderungen an den Feldlängen mit sich ziehen können und das diese Änderungen wahrscheinlicher an konkreten Nutzdatenspalten auftreten als an reinen abstrakten Schlüsselspalten...

[mwanaheri]

Die da wären?

zum Beispiel so Sachen, dass der für Integerzahlen in Abap zu bevorzugende Datentyp N in der zugrundeliegenden Datenbank als char abgelegt wird. Oder dass für fast alle Felder ein eigener Datentyp (mit Bezeichnungsvarianten, ggf Übersetzungen und Ausgabeoptionen) definiert werden sollte, der dann wiederum in einer Tabelle landet.


Naja, zumindest wenn man daran arbeitet ein System Umzusetzen, also zu implementieren, zähle ich die Felddimensionierung zum Datenmodell mit dazu. Mag sein, dass das irgendwoanders anders definiert ist. Ändert aber nichts an der Tatsache, das Systeme sich im Laufe ihres Lebens verändern und diese Veränderungen auch Veränderungen an den Feldlängen mit sich ziehen können und das diese Änderungen wahrscheinlicher an konkreten Nutzdatenspalten auftreten als an reinen abstrakten Schlüsselspalten...
Ein besseres Argument ist eigentlich, dass -- bei geschäftlichen Daten -- eine Datenhaltungspflicht von 10 Jahren besteht und man alle Daten historisieren müsste, wenn man nicht einen einmal vergebenen Usernamen praktisch gesehen nie mehr verwenden können will. Angesichts der relativ geringen Zahl der gut merkbaren Nutzernamen pro Länge ist das eher ein Problem.