Datenbank struktur

[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