Datenbank struktur

[SaFu]

Hi Habe mal folgende Frage zum Entwurf der Datenbank

Also ich arbeite ja schon länger mit der BDE und will auch schon länger auf FireBird umstellen
Hab mir jetzt mal einiges durchgelesen und habe auch einige Tipps bekommen.
Ich habe immer den großen Fehler gemacht und habe alle Daten in eine Tabelle gepackt. :oops: :oops:

Jetzt hab ich mal ne Frage zu dem Aufbau.

Ist es so richtig das ich z.b. PLZ, Strasse, Telefonnummer, Name, Nachname, Geburtstag usw. in einzelne Tabellen Packe z.B

Tabelle_PLZ
Tabelle_Strasse
Tabelle_Telefonnummer
Tabelle_Name
Tabelle_Nachname
Tabelle_Geburtstag

und diese einfach nur mit dem Feld ID und z.b.Name versehen

Ich wollte mir diesmal eine strucktur aufbauen bevor ich wieder mist Programmiere

[taaktaak]

Moin, Moin,
schau doch mal hier da findet sich einiges zum Thema "Normalisieren", das dürfte dir ein wenig weiter helfen.

[SaFu]

Aha also hat nur 1 Tabelle eine ID und über die wird ein Fremdschlüßel in die andere Tabelle geschrieben??

[mkinzler]

Ich würde jeder Tabelle eine ID (künstlicher Primärschlüssel) verpassen. allerdings ist eine derart extreme Normalisierung, wie du in deinem ursprünglichen Beitrag hast, nicht unbedingt sinnvoll.

[SaFu]

Warum wäre das denn nicht sinnvoll

Ich möchte halt Redundaten vermeiden

[DeddyH]

Die Daten sollen zwar atomar strukturiert sein, aber von Kernspaltung hat niemand geredet :mrgreen:

[SaFu]

Also würde Ihr auch die Daten in eine Tabelle speichern und die Datensätze mit einer ID versehen

[mkinzler]

Ich würde das zusammenhanlten, was eigentlich zusammengehört.

Adresse (ID, Str, Plz, Ort)
KommAdresse ( ID, Person, Art, Wert)
Person ( ID, HauptAdr, Name, Vorname, GebDat, ...)
ZuOrdnung (ID, Art, von, zu)

[SaFu]

Aha das ist dochmal was war schon total verwirt

[Pfoto]

Hallo Sascha,

Meine Vorgehensweis: Ich überlege, auf welche Daten im Laufe der
Zeit mehrfach verwiesen werden könnte und welche untereinander
eine logische Einheit darstellen könnten.
In einem größeren System könnte es sich lohnen, für jede Stadt
eine Tabelle anzulegen, die Name, Kreis und PLZ enthält.
Eine Tabelle, die nur Straßen enthält würde dann auf die Tabelle
der Städte verweisen. Es können also beliebig viele Straßen
einer Stadt hinzugefügt werden.
Ändert sich z.B. die Kreis-Zugehörigkeit einer Stadt musst du
nur einen Eintrag in der Tabelle "Stadt" aktualisieren.

Eine Tabelle "Geburtstag" hätte nur wenig Sinn, da in einer
Datenbank mit wenig Einträgen faktisch jeder Nutzer einen
anderen Geburtstag hätte. Man kann diesen Wert also gleich
in die Tabelle der Personendaten packen.


Sinn für eine weitere Tabelle würde in meinen Augen eine
Tabelle für E-Mails machen, aber nur deswegen, weil die Leute
in der heutigen Zeit oft mehr als eine E-Mail besitzen.

Du könntest also einen Eintrag in der Tabelle "E-Mails"
auf den Eintrag einer Person verweisen.
(Ich glaube, das heißt 1:n Beziehung, da du beliebig viele
E-Mails einer Person zuordnen kannst)



Gruß
Pfoto

[Hansa]

Zitat:

Zitat von fuknersascha

..Ich möchte halt Redundaten vermeiden

Das heißt Redundanzen. Da geht es darum, gleiche Daten nicht doppelt und dreifach an verschiedenen Orten zu halten. Deine "Kernspaltung" :thumb: :wall: bringt da aber absolut nichts ! Eher nur Durcheinander. Du musst ja später das zusammenhängende wieder zusammensuchen. Die im Anfangspost gezeigten Daten gehören IMHO sowieso zusammen. Wenn du also tatsächlich eine Kernspaltung durchführst, dann überlege direkt, wie die anschließende Kernfusion auszusehen hat. :mrgreen:

[mkinzler]

Zitat:

Sinn für eine weitere Tabelle würde in meinen Augen eine
Tabelle für E-Mails machen, aber nur deswegen, weil die Leute
in der heutigen Zeit oft mehr als eine E-Mail besitzen.

Du könntest also einen Eintrag in der Tabelle "E-Mails"
auf den Eintrag einer Person verweisen.
(Ich glaube, das heißt 1:n Beziehung, da du beliebig viele
E-Mails einer Person zuordnen kannst)

Das würde eine Tabelle für Kommunikationsadressen allgemein verwenden (s.o. KommAdr) und dort, Telefonnr., Mobiltelnr., Faxnr., Emailadresse, ICQ, ...

[tr909]

Ich würde auch die Daten zu einer Person die "fest" stehen in eine Tabelle schreiben (z.B. Name, Vorname, Geb.Dat), Kommunikationdaten und evtl. Adresse (falls du auch noch zugriff auf ältere Adressen haben möchtest) in jeweils eine Extra-Tabelle.

Mann könnte natürlich noch eine PLZ/Ort/Strassen-Tabelle machen, und dann bei Eingabe der PLZ automatisch Orte/Straßen vorschlagen lassen, aber das wäre dann eher ein Eingabekomfort. PLZ als Schlüssel geht ja leider nicht, da mehrere Orte die gleiche haben könnten. Bei eine "großen" Menge an Einträgen könnte man natürlich alle PLZ-Ort-Kombinationen mit einer ID versehen und dann die bei der Adresse hinterlegen.

Gruß
tr909

[SaFu]

Ich glaube ich habe das Prinzip jetzt verstanden

Inventar_Raum_Tabelle

ID_IRT | Tische | Stühle | Projektoren | Beamer | PC | Monitore | Divers


Wäre sowas für eine Inventar Tabelle optimal???

Und die Raumnummer kommt in eine Extra Tabelle

[mkinzler]

ich würde die Inventararten in eine eigene Relation auslagern

[SaFu]

Wegen der Bezeichnung und des Typs ?????

[mkinzler]

Um flexibel zu sein. pro art dann einen Eintrag in der Tabelle:

Zimmer
ID Bez
1 A1

Arten
ID Bez
1 Stuhl
2 Tisch
...

Inventar
ID Zimmer Art Anzahl
1 1 1 4
2 1 2 2

[s-off]

Und die Primärschlüssel würde ich 'ID', nicht 'ID_IRGENDWAS' nennen.
Diese Bezeichnung würde ich den IDs geben, wenn Sie als Fremdschlüssel in anderen Tabellen agieren.

Edit: das Beispiel von Markus ist nett und verdeutlicht den eigentlichen Sinn relationaler Datenbanken
Im Prinzip hast Du immer Tabellen mit irgendwelchen Stammdaten (hier Zimmer und Arten) und dann eine Tabelle, die die Relationen zwischen diesen Stammdaten beschreibt (hier Inventar).

Diese Tabelle hat selber einen Primärschlüssel (ID) und stellt je Datensatz die Beziehung zwischen Datensätzen anderer Tabellen her, die hier ebenfalls durch ihre ID vertreten sind, welche als Fremdschlüssel bezeichnet werden.

[quendolineDD]

Ich persönlich arbeite immer mit der 3. Normalform und visualisiere mir den Aufbau meiner Datenbanken mit CRMs und ERDs.
Wo welcher Schlüssel als Sekundärschlüssel (als Verweis auf einen Primärschlüssel einer anderen Tabelle, welche mit dieser in Relation steht) ergibt sich aus den Integritäten.

[Pfoto]

Zitat:

Zitat von fuknersascha

Inventar_Raum_Tabelle

ID_IRT | Tische | Stühle | Projektoren | Beamer | PC | Monitore | Divers


Wäre sowas für eine Inventar Tabelle optimal???

Und die Raumnummer kommt in eine Extra Tabelle

EDIT: Shit, habe den Beitrag oben gar nicht gesehen, ich wollte
fast das gleich sagen:


Man könnte es so aufsplitten (je nachdem, wie genau man es treibt)

Tabelle Inventar
ID|Name

Tabelle Raum
ID|Raumnummer

Tabelle RaumInventarRel
ID|FK_InventarID|FK_RaumID

d.h. in der letzten Tabelle kannst du eine mehrfache Beziehung
zwischen Räumen und dem Inventar herstellen.



Gruß
Pfoto

[grenzgaenger]

Du solltest nicht ausschliesslich nach redundanzen gehen. denn bei extremer normalisierung 4, 5 normalform, kommt es dann zu inkonsistenzen zwischen den daten.

auf was du achten solltest, sind die entitäten und die attribute. wenn ein attribut eine entität ist, dann ist das eine eigene realation, ansonsten gehört es als attribut in die relation, wenn du nicht (aus irgendwelchen anderen gründen) sie dennoch auslagern möchtest. aber jedes solche auslagern muss begründet und begründbar sein.

für deinenen adressatz also folgendermassen:

[@ID; PLZ, Strasse, Telefonnummer, Name, Geburtstag] Wobei man darüber diskutieren kann, ob man nicht ein strassenverzeichnis auflegt, ggf. mit folgenden aufbau [@ID; *Ort; *Strasse; *PLZ] wobei du entweder die ID oder den compount key [@ort, @strasse; @plz] als primary key verwenden kannst. die gliederung muss aber mind. auf dieser ebene erfolgen, da eine strasse mehrere PLZ's haben kann, eine PLZ mehrere strassen, eine PLZ mehrere orte, ein ort mehrere strassen und ein ort mehre PLZ's.

was allerdings sinnvoll wäre, wäre den Ort als eigene entität zu behandeln und nur einen fremdschlüssel in die relation aufzunehmen.

ebenso bei deinen inventar beispiel:

• [@RaumID; Raumbezeichnung, etc.]
• Entität Projektor[@id, hersteller, baujahr, inventar Nr, RaumID, etc.]
• Entität beamer[@id; hersteller, baujahr, inventar Nr, RaumID, etc.]
• entität pc[@id, hersteller, baujahr, betriebssystem, inventar nr, RaumID, etc,]

usw.

<HTH>
GG