Datenbankentwurf Problem Generalisierung?

[egat]

Tag Leute,

hab hier ein kleines Problem. Es soll eine DB erstellt werden (Basis Oracle). Mein Problem ist die Modellierung folgenden Sachhalts:

Es gibt eine Tabelle Mitarbeiter. Gut.

Jeder Mitarbeiter kann ein bestimmtes Inventar haben, z.B. einen Laptop, PC, Handy, UMTS-Karte oder/und PDA, etc. Zu den jeweiligen Geräte müssten dazu noch weitere Infos wie Standort, Rufnummer, etc gespeichert werden.

Wie mache ich das am besten? Ist eine Generalisierung sinnvoll oder ist das Quatsch?

Danke für die Antworten.

Gruß

[dimitri]

Nun Du hast eben noch eine Tabelle Inventar, die einen Verweis auf den user besitzt dem sie Ausgehändigt wurde (FK Constraint auf die Userid).

Für die anderen Infos kannst entweder in die Inventartabelle X Spalten hinzufügen, in die dann die Beschreibung kommt (nicht so ganz normiert). Anhand eines ebenfalls dort gespeicherten typs werden für die einzelnen Spalten dann in einer Klartexttabelle die Bezeichnungen hinterlegt, welche die Anwendung auslesen kann.
Also z.B. die Spalte INFO1 in der Inventartabelle kann je nach Inventartyp Rufnummer oder Standort sein.

Wenn Du es normalisiert haben möchtest, dann lagerst das in eine eigene Tabelle aus und verknüpfst es wieder per FK Constraint.

Dim

[egat]

Naja hätte das Ganze schon gerne normiert. Vllt so:

Tabelle 1: Monitor
---------
InventoryNO (PK)
Bildschirmgröße
Größe
Standort
Primärkontakt
etc.
PersNr (FK)

Tabelle 2: Notebook
---------
InventoryNO (PK)
Notebookart
Standort
Primärkontakt
etc.
PersNr (FK)

Tabelle 1: DesktopPC
---------
InventoryNO (PK)
DesktopPC_Art
Standort
Primärkontakt
etc.
PersNr (FK)

Ist das gut oder nicht? Die PersNr (Inhaber) wird logischerweise als FK eingebunden. Der Primärkontakt ist auch ne PersNr. Wie würde man das dann einbinden??

DANKE!!!!

[dimitri]

Hi,

das ganze mag theoretisch der Normalform entsprechend ist aber extrem unflexibel. Kommt ein neues gerät hinzu, so musst Du eine neue Tabelle anlegen, neue SQLs schreiben etc.

Mit meiner Lösung hättest Du die Normalform ebenfalls erfüllt und könntest ein neues Gerät mit einigen einfachen DML Befehlen hinzufügen.

Kommt eben drauf an, wie oft du neue geräte hinzufügen musst. Aus datenmodellierungssicht würde man hier aber eine Entität Gerät oder Inventar verwenden und nicht zig verschiedene Tabellen.

Dim

[egat]

Danke für die Infos!!!

Aber wegen meiner letzten Frage:
Die PersNr (Inhaber) wird logischerweise als FK eingebunden. Der Primärkontakt ist auch ne PersNr. Wie würde man das dann einbinden??

[Markus Kinzler]

Als weiteres Feld

[egat]

is klar! aber wäre dann der primärkontakt auch ein FK?

[dimitri]

Also der Begriff Primärkontakt ist nicht wirklich ein Datenbankbegriff. Es gibt einen Primary Key.

Der Fk der untergeordneten Tabelle verweist auf die übergeordnete Tabelle. Die untergeordnete Tabelle hat aber natürlich ein eigenes Feld für einen technischen PK. Eine FK Feld wird nie gleichzeitig auch als PK Feld verwendet.

Dim

[kuemmelchen]

Eine FK Feld wird nie gleichzeitig auch als PK Feld verwendet.

Das stimmt leider nicht. Es ist durch aus erlaubt und üblich, dass ein FK Feld auch gleichzeitig ein PK Feld sein darf. Dieser Fall wird gerade bei der Generalisierung/Spezialisierung benötigt.
Es kann auch der Fall eintreten, dass ein Teil des PK gleichzeitig FK ist.

kuemmelchen

[dimitri]

Technisch ist sowas natürlich möglich, praktisch gehören die die sowas machen geteert und gefedert.
Zum einen werden hier fachliche Felder als PK missbraucht, des weiteren kann man sich damit hart ins Datenmodell eine 1:1 Beziehung hineincodieren und last but not least wirds richtig lustig, wenn man den FK mit der Option ON DELETE SET NULL angelegt hat.

In diesem Thread hab ich die Problematik auch schon beschrieben.

Daher kann ich nur abraten für einen FK einen (Teil)PK zu verwenden.

Dim

[kuemmelchen]

last but not least wirds richtig lustig, wenn man den FK mit der Option ON DELETE SET NULL angelegt hat

Im angegebenen Beispiel wird in der Tabelle t_kind der FK mit ON DELETE SET NULL angelegt.

CREATE TABLE t_eltern
(
id number primary key
);


CREATE TABLE t_kind
(
id number primary key REFERENCES t_eltern (id) ON DELETE SET NULL
);

insert into t_eltern values(1);


insert into t_kind values(1);

commit;

Die beiden Tabellen werden ohne Fehler erstellt. Genauso werden die beiden Datensätze akzeptiert und durch COMMIT dauerhaft gespeichert. Wenn nun versucht wird, den Elterndatensatz zu löschen (DELETE t_eltern; ), wird seitens Oracle folgende Fehlermeldung ausgegeben:

delete t_eltern
*
FEHLER in Zeile 1:
ORA-01407: Aktualisieren von ("SYSTEM"."T_KIND"."ID") zu NULL nicht möglich

Das ist auch logisch, da der PK keine NULL-Werte besitzen darf.

hart ins Datenmodell eine 1:1 Beziehung hineincodieren

Bei einer 1:1-Beziehung wird der PK der einen Seite FK der anderen Seite. Dieser FK muss zudem UNIQUE sein. NULL-Werte sind aber für diesen FK immer noch erlaubt.
Aus der Tatsache, dass ein Attribut sowohl PK als auch FK ist, kann nicht auf eine 1:1-Beziehung geschlossen werden. Der PK darf wie bereits erwähnt keine NULL-Werte aufweisen
Ausgehend vom Datenmodell werden die entsprechenden Tabellen erstellt. Aus der Tabellenstruktur kann aber nicht auf das Datenmodell geschlossen werden.

fachliche Felder als PK missbraucht
In diesem Thread hab ich die Problematik auch schon beschrieben.

Es gibt halt die Datenmodellierung und da wird beschrieben, wie entsprechende Beziehungen aufgelöst werden.
Zur Auflösung einer N:M-Beziehung wird eine Zwischenrelation benötigt. Diese Zwischenrelation enthält jeweils den PK der beteiligten Entitäten als FK. Beide FK bilden zusammen den PK dieser Relation.
Alternativ kann diese Zwischenrelation einen eigenen PK besitzen. Trotzdem bleibt es bei der Tatsache, dass jeweils der PK der beteiligten Entitäten FK wird. Desweiteren muss ein UNIQUE über beide FKs gebildet werden, sonst könnte dieselbe Beziehung hier mehrmals eingetragen werden. An einer Beziehung nimmt immer ein Vertreter der beteiligten Entitäten teil, sonst wäre es ja keine Beziehung. Das bedeutet, dass für die eben erwähnten FK keine NULL-Werte erlaubt sind. Da über diese Zwischenrelation die Verknüpfung läuft, ist es empfehlenswert, die FKs auch zu indizieren.
Kurz gesagt, bringt die eben beschriebene Alternative keine Pluspunkte. Für Oracle bedeutet diese Alternative so gar einen Mehraufwand als die Anwendung der entsprechenden Regel. Wenn fachliche Felder nicht als PK missbraucht werden sollen, so muss die alternative Vorgehensweise richtig angewendet werden.

Ich bin mir allerdings nicht ganz sicher, ob ich deinen Begriff "fachliche Felder" richtig verstanden habe.

kuemmelchen

[dimitri]

Das ist auch logisch, da der PK keine NULL-Werte besitzen darf.

Und das beunruhigt dich nicht? Das die art und weise wie ein FK angelegt wird eine Löschoperation erlaubt oder nicht? Naja...

Aus der Tatsache, dass ein Attribut sowohl PK als auch FK ist, kann nicht auf eine 1:1-Beziehung geschlossen werden. Der PK darf wie bereits erwähnt keine NULL-Werte aufweisen

Doch kann es. Da nicht der gleiche Wert nochmal eingefügt werden kann (da ein PK impliziet Unique ist) kann auch kein zweiter Satz hinzugefügt werden, der den gleichen übergeordneten referenziert.

Desweiteren muss ein UNIQUE über beide FKs gebildet werden, sonst könnte dieselbe Beziehung hier mehrmals eingetragen werden.

Sofern das gewünscht ist ja muss aber nicht das kommt auf die fachlichen Anforderungen an.

Ich bin mir allerdings nicht ganz sicher, ob ich deinen Begriff "fachliche Felder" richtig verstanden habe.

Ich denke schon. fachliche Felder sind alle Felder, die im Bereich der Anwendung liegen und über deren Inhalt wir keine (direkte) Kontrolle haben.

Dim