Hilfe bei Normalisierung einer DB-Struktur

[blacky1985]

Hallo ....

habe ein kleines Prob mit der Normalisierung einer Datenbank....hoffe ihr könnt mir da weiterhelfen um die DB in die 3.Normalform zu bringen...

also bisher habe ich die DB-Struktur wie folgt aufgebaut...allerdings ist das ja sicherlich noch nicht in der 3.Normalform...wie die 3 Normalformen lauten wieß ich auch...habe aber speziell bei dieser DB das Problem sie dahingehen aufzulösen, dass die Struktur der 3.Normalform entspricht...

hoffe hier finden sich einige, die mir bei diesem Problem helfen können Dank im Voraus...

++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++

CREATE TABLE ADDRESS

(

ID INT(11) unsigned NOT NULL auto_increment,

Firma VARCHAR(32) NOT NULL,

Name VARCHAR(32) NOT NULL,

Vorname VARCHAR(32) NOT NULL,

Strasse VARCHAR(32) NOT NULL,

Haus_Nr VARCHAR(6) NOT NULL,

PLZ INT(5) NOT NULL,

Ort VARCHAR(32) NOT NULL,

Telefon VARCHAR(32),

Fax VARCHAR(32),

Mobile VARCHAR(32),

PRIMARY KEY (ID)

);

CREATE TABLE USERS

(

ID int(11) unsigned NOT NULL auto_increment,

Autologin VARCHAR(32) NULL,

IP VARCHAR(15) NOT NULL,

SessionID VARCHAR(32) NOT NULL,

UserNick VARCHAR(32) NOT NULL,

UserPwd VARCHAR(32) NOT NULL,

UserMail VARCHAR(70) NOT NULL,

Reg_Date DATE NULL,

Last_Login INT NOT NULL DEFAULT '0',

Last_Action INT NOT NULL DEFAULT '0',

Activate VARCHAR(32),

PRIMARY KEY (ID),

Foreign Key (ID) references ADDRESS(ID),

UNIQUE (UserNick, UserMail)

)

[kingofbrain]

Servus,

was sind Deine Ansätze bis jetzt und wo hängst Du genau? Ich denke nicht, das Dir hier jemand eine komplette Lösung zimmert.

Peter

[johnhaltonx]

+ da fehlt ein Haufen Informationen

- was für ein Projekt?

- ziel ?

- sind das alle Tabellen ?

- Privatnutzer oder Firmen (mehrere Addressen ) ?

und eine reine 3. Normalform ist nur akademisch interessant und wird in den seltensten Fällen real implementiert.

[blacky1985]

danke für di ersten schnellen rezessionen....leider habe ich grad auch gemerkt das ich euch besser etwas mehr über den genauen hintergrund erzählen sollte...

also bei dem projekt geht es um eine firmeninterne projektarbeit von mir ... un da die am ende bewertet wird von nem prüfungsausschuss sozusagen...hänge ich aktuell so ein bissel in der luft bezüglich einer optimalen db-struktur...

die db soll dazu benutzt werden, dass sich externe firmenkunden registrieren können (...also von unterschiedlichen firmen, aber auch mehrere leute von ein und derselben firma, von denen sich jeder einen eigenen account registrieren lassen kann)...

daher habe ich auch zuerst einmal mir überlegt welche daten ich dafür alles benötige und welche sinnvoll sind...dabei bin ich dann auf die oben aufgeführten werte gekommen, habe mir für jeden wert einen meiner meinung nach geeigneten datentyp überlegt und mir gedacht es sei sinnvoll die accountdaten auf zwei tabellen auf jeden fall aufzuteilen...einmal die reinen adressdaten (tabelle ADRESS) und eninmal accountspezifische daten (tabelle USERS)....

meine frage ist eigentlich nun bzw. mein problem, ob es sinnvoll ist die daten anders zu strukturieren bzw. aufgrund der 3.Normalform anders aufzuteilen und auf noch mehr einzelne tabellen zu verteilen, oder ob man an meiner struktur etwas verbessern kann noch, da ich mir da momentan recht unsicher bin ob dies die optimale struktur für diesen zweck ist...

zu der letzten frage noch.....ja, dass hier sind alle datenwerte und tabellen, die ich eigentlich brauche bzw. benutze für das projekt...

falls ihr noch infos braucht oder fragen habt, postet einfach und ich werd mich bemühen sie zu beantworten....bleibt für mich nur die frage an euch un der dank im voraus für eure mithilfe, was ihr mir nun empfehlen würdet um eine optimal datenbankstruktur zu implementieren...

weil wenn ich z.b. nach der 3.NF gehen würde, müsste ich die daten ja so klein zerlegen, dass ich auch z.b. PLZ und Ort in eine extra tabelle übertragen müsste...hab dann aber ja irgendwann doch das problem wenn ich es richtig sehe, dass ich beim auslesen der db eine unnötig lange n komplizerte abfrage jedes mal starten muss.-...von daher binb ich mir jetzt halt unschlüssig, da ich ja noch azubi bin, wie ich weitermachen soll an dieser stelle....die db struktur so lassen wie sie ist, oder leiber etwas umändern....

grüße andreas

[dakingno1]

bedenke aber, dass die Anwendugn immer leicht erweiterbar sein soll. Das beste Beispiel mit der PLZ ist, dass man evtl. mal nach Stadt Filtern will, also lass die bitte getrennt.

Wichtig ist auf jedenfall dass du dieersten 3 Normalformen auf jedenfall einhältst.

Ich werde auch nochmal über deine Struktur schauen undevtl. meinen Vorschlag posten...

[dakingno1]

ICh nehme mal an in den folgenden Feldern stehen die Namen der benutzer?

Name VARCHAR(32) NOT NULL,

Vorname VARCHAR(32) NOT NULL,

Dann ist deine DB total inkonsistent. Falls du noch keine andere Struktur hast oder dir jemand geholfen hat, dann schreib mal rein und ich werde die DB umbauen...

[Goos]

Wichtig ist auf jedenfall dass du dieersten 3 Normalformen auf jedenfall einhältst.

Auf jeden Fall?

Ich halte das fuer reinen Unsinn

Goos

[Goos]

ICh nehme mal an in den folgenden Feldern stehen die Namen der benutzer?

Name VARCHAR(32) NOT NULL,

Vorname VARCHAR(32) NOT NULL,

Dann ist deine DB total inkonsistent.

Wie kommst du auf eine solche Aussage?

Goos

[dakingno1]

Wie kommst du auf eine solche Aussage?

Goos

Wenn du gelesen hast, was er vorhat, dann ist es ja wohl so.

Er hat mehrere Firmen und von jeder Firma kann sich ein User anmelden. Dann stell dir mal vor, was passiert, wenn ein neuer User sich registriert...

Jeder USer muss die Daten seiner Firma angeben und dann in der User Tabelle seine weiteren Daten. Das passt irgendwie nicht zusammen, richtig?

Berichtige mich, wenn ich was falsch sehe!

[dakingno1]

Auf jeden Fall?

Ich halte das fuer reinen Unsinn

Goos

Dann scheine ich mich in dem Fall wohl zu irren!

[Goos]

Dann scheine ich mich in dem Fall wohl zu irren!

Vermut ich mal, ja

Natuerlich muss noch normalisiert werden, die beiden Tabellen sind so nicht praxistauglich, aber eine unbedingte dritte Normalform in der Regel auch nicht.

Goos

[Goos]

Er hat mehrere Firmen und von jeder Firma kann sich ein User anmelden. Dann stell dir mal vor, was passiert, wenn ein neuer User sich registriert...

...was passiert?

Er registriert sich und gibt die vielleicht schon vorhandenen Firmendaten erneut ein

Wir haetten dann redundante Daten, aber keine Inkonsistenz.

Goos

[dakingno1]

entschuldige. Du hast natürlich recht, aber die blöden Fachbegriffe.... *argh*

Jedenfalls isses schlecht... lol

[blacky1985]

ICh nehme mal an in den folgenden Feldern stehen die Namen der benutzer?

Name VARCHAR(32) NOT NULL,

Vorname VARCHAR(32) NOT NULL,

Dann ist deine DB total inkonsistent. Falls du noch keine andere Struktur hast oder dir jemand geholfen hat, dann schreib mal rein und ich werde die DB umbauen...

richtig wie du das siehst....in Name und Vorname steht der Name des Mitarbeiters, also der real-name...

bin weiterhin froh für jeden weietren vorschlag, da ich mir da schon seit tagen den kopf zerbreche eine praxistaugliche lösung der db struktur zu finden.....habe das mir auch überlegt das ich dann doppelte daten habe in der db, wenn ich die struktur so lasse, wenn sich z.b. 2 mitarbeiter derselben firma einen account registrieren...genau da liegt ja auch das kernproblem....wie ihr schon sagtet...wenn ich das bis zur 3.NF zerlege glaub ich, habe ich zwar die 3.NF aber das wäre net praxistauglich wie einer von euch meinte....un so wie es jetzt ist kanns ja auch net bleiben weil ich dann redundante daten entstehen....;-) ....

also kurz gesagt so wie die db strultur jetzt ist, entstehen ja redundante daten und keine inkonsistenz....wäre euch echt dankbar für weitere hilfe um eine praxistaugliche, optimale läösung der db struktur zu finden ^^ dake nochmals im voraus....

[dakingno1]

ick mach jetzt mal deine db nach meinem sinn praxistauglich....

[dakingno1]

CREATE TABLE Tbl_company

(

ID INT(11) unsigned NOT NULL auto_increment,

Name_Firma VARCHAR(32) NOT NULL,

Strasse VARCHAR(32) NOT NULL,

Haus_Nr VARCHAR(6) NOT NULL,

PLZ INT(5) NOT NULL,

Ort VARCHAR(32) NOT NULL,

Telefon VARCHAR(32),

Fax VARCHAR(32),

Mobile VARCHAR(32),

PRIMARY KEY (ID)

);

*/ Je nachdem was du noch für Infos von der Firma benötigst

(Geschäftsführer o.ä.) kommen in der Tabelle Company

*/

CREATE TABLE Tbl_USER

(

ID int(11) unsigned NOT NULL auto_increment,

Autologin VARCHAR(32) NULL,

IP VARCHAR(15) NOT NULL, // IP´s speichern?

SessionID VARCHAR(32) NOT NULL,

UserNick VARCHAR(32) NOT NULL,

UserPwd VARCHAR(32) NOT NULL,

UserMail VARCHAR(70) NOT NULL,

UserName VARCHAR(32) NOT NULL,

UserVorname VARCHAR(32) NOT NULL,

Reg_Date DATE NULL,

Last_Login INT NOT NULL DEFAULT '0',

Last_Action INT NOT NULL DEFAULT '0',

Activate VARCHAR(32),

PRIMARY KEY (ID),

Foreign Key (ID) references ADDRESS(ID),

UNIQUE (UserNick, UserMail)

)

/*Wenn jeder User nur einer Firma angehören kann ,dann reichen dir die beiden Tabellen aus!

Mehr gibt es meiner Meinugn nach gar nicht mehr zu ändern.

Zur Erklärung:

In der Tbl_company speichert man alle Firmen und jeder User der sich anmeldethat dann einen Zusammenhang zu einer Firma. Deshalb entsteht eine 1:n Bezihung. Falls es noch andere Vorschläge gibt oder Fragen, dann schreibt einfach... */

[Jan Jansen]

Geh am besten so vor wie in der BS vorgeschlagen:

Erst ein Entity-Relationship-Diagramm, dann die Tabellen entwerfen

1. Entitäten bestimmen:

In deinem Beispiel könnte man 4 Entitäten festlegen (jede Entität bekommt eine eigene Tabelle):

Mitarbeiter

Firma

Userdaten

Verbindungsinformationen (IP usw. würde ich vom User trennen)

2. Kardinaliäten bestimmen

Firma : Mitarbeiter wäre 1:n

usw.

3. Anhand der Kardinalitäten kannst du jetzt die Schlüsselbeziehungen Festlegen

In die Tabelle Mitarbeiter gehört z.B. ein Schlüssel auf Firma (Firma_ID)

4. Sammeln der restlichen Felder und Festlegen der Datentypen für die 4 Tabellen

Hier könnte sich z.B. zeigen das man die Telefonnummer einmal in Firma aufnimmt und einmal für den Mitarbeiter direkt.

Achte bei den Datentypen auf ausreichende Größe und auf die zu erwartenden Eingaben.

Z.B. sollte man die PLZ nicht als Zahl speichern

Damit bist du schon fast in der 3. Normalform

(PLZ und Ort in einer Tabelle zu haben widerspricht zwar dieser 3. NF, aber für dein Beispiel würde ich es nicht ändern)

[blacky1985]

vielen dank für eure anrgeungen und tips bisher ;-) die haben mir glaube ich um einiges weitergeholfen....ich setz mich die tag dran die DB struktur neu aufzusetzen und werd mich dann hier wieder zu wort melden ;-) nicht das ihr meint ich würd hier nur drauf warten eine optimal lösung von jemandem gepostet zu bekommen um nichts selbst schaffen zu müssen^^....also dann bis die tage ....

[blacky1985]

so habe jetzt mal das ganze überarbeitet und so en art er-modell daraus erstellt....vielleicht könntet ihr mal drüberschauen und mir feedback gegeben, was ihr von dieser db struktur haltet und wo noch fehler sind oder verbesserungen vorgenommen werden können....;-) danke wiederum im voraus...

[dakingno1]

sieht doch gut aus denke ich...