Relationsships und Keys

Hallo,

ich habe zwei Tabellen, FIRMA und MITARBEITER. Eine Firma kann mehrer
Mitarbeiter haben, ein Mitarbeiter aber nur bei einer Firma sein, ok.
Ein Mitarbeiter hat die Attribute: geschlecht, department, email, telefon,
name und foreign key auf firma_id.
wie mache ich es am besten mit dem primary key, ein weg waere doch zu sagen
name und (fk)firma_id ergeben zusammen den primary key, weil in einer Firma
nur ein Mal ein Name auftauchen darf. So klappt es auch. Wenn ich aber eine
dritte Tabelle habe die einen Foreign Key auf einen PK in MITARBEITER setzen
will, wie mache ich das?
Kann ich jetzt in Tabelle3 eine Spalte definieren die sich aus
MITARBEITER-NAME und MITARBEITER-Firmen-Id zusammensetzt?
Wenn ja, wie? Oder ist es besser bei Mitarbeiter eine id als PK zu
definieren und trotzdem sicherzustellen dass es immer nur eine Kombination
von MITARBEITER-NAME und MITARBEITER-Firmen-Id in der Tabelle gibt? Wenn ja,
wie mache ich das?
Oder gibt es eine bessere Moeglichkeit?

Vielen Dank fuer die Hilfe!

Gruss
Dennis

P.S. Mehr Daten ueber einen Mitarbeiter (Geburtsdatum oder Strasse) kann ich
leider an dieser Stelle zur Unterscheidung nicht bekommen.

Re: Relationsships und Keys

Dennis Kuntzemann schrieb:
> ich habe zwei Tabellen, FIRMA und MITARBEITER. Eine Firma kann mehrer
> Mitarbeiter haben, ein Mitarbeiter aber nur bei einer Firma sein, ok.
> Ein Mitarbeiter hat die Attribute: geschlecht, department, email, telef=
on,
> name und foreign key auf firma_id.
> wie mache ich es am besten mit dem primary key, ein weg waere doch zu s=
agen
> name und (fk)firma_id ergeben zusammen den primary key, weil in einer F=
irma
> nur ein Mal ein Name auftauchen darf.

Warum genau, gibt es bei dir keine Firma, in der zwei=20
Maier/Müller/Smith/Schmidt arbeiten? Ist das eine Bedingung, wenn man=20
Geschäfte mit dir machen möchte? ;-)

> So klappt es auch. Wenn ich aber eine
> dritte Tabelle habe die einen Foreign Key auf einen PK in MITARBEITER s=
etzen
> will, wie mache ich das?
> Kann ich jetzt in Tabelle3 eine Spalte definieren die sich aus
> MITARBEITER-NAME und MITARBEITER-Firmen-Id zusammensetzt?
> Wenn ja, wie? Oder ist es besser bei Mitarbeiter eine id als PK zu
> definieren und trotzdem sicherzustellen dass es immer nur eine Kombinat=
ion
> von MITARBEITER-NAME und MITARBEITER-Firmen-Id in der Tabelle gibt? Wen=
n ja,
> wie mache ich das?

Ja... ich würde an deiner Stelle die ID vergeben. Auch wenn ich mir=20
nicht vorstellen kann, wie du andere Firmen dazu zwingst, die Leute um=20
Namensänderungen zu bitten, kannst du einen UNIQUE INDEX über die bei=
den=20
Spalten vergeben.

> Oder gibt es eine bessere Moeglichkeit?

Verzichte auf die Bedingung.

--=20
HTH,
Fabian

Re: Relationsships und Keys

"Dennis Kuntzemann" wrote:

[ FIRMA 1<>n MITARBEITER ]

> wie mache ich es am besten mit dem primary key, ein weg waere doch zu sagen
> name und (fk)firma_id ergeben zusammen den primary key, weil in einer Firma
> nur ein Mal ein Name auftauchen darf.

Warum diese Einschränkung? Ist das wirklich realistisch, daß in einer
Firma nur ein Herr/Frau Müller arbeiten darf? Vergib eine numerische
ID per AUTO_INCREMENT und gut ist.

Es gibt auch noch einen zweiten Grund für einen numerischen PK für
Tabelle MITARBEITER. Foreign Keys bedeutet InnoDB. Und InnoDB bedeutet
möglichst kurzen PK (idealerweise: INT UNSIGNED AUTO_INCREMENT).

> Kann ich jetzt in Tabelle3 eine Spalte definieren die sich aus
> MITARBEITER-NAME und MITARBEITER-Firmen-Id zusammensetzt?

Nein. Dazu müßtest du einen zusammengesetzten FK machen. Bsp:

CREATE TABLE foo {
firma VARCHAR(20),
name VARCHAR(20),
...
PRIMARY KEY (firma, name)
}

CREATE TABLE bar {
fk_firma VARCHAR(20),
fk_name VARCHAR(20),
...
INDEX (fk_firma, fk_name),
FOREIGN KEY (fk_firma, fk_name) REFERENCES foo (firma, name)
}

Damit merkst du auch gleich, warum das keine gute Idee ist: du
duplizierst Daten.

> ... trotzdem sicherzustellen dass es immer nur eine Kombination
> von MITARBEITER-NAME und MITARBEITER-Firmen-Id in der Tabelle gibt?
> wie mache ich das?

Mit einem UNIQUE Index.


XL

Re: Relationsships und Keys

Dennis Kuntzemann schrieb:

> wie mache ich es am besten mit dem primary key, ein weg waere doch zu sagen
> name und (fk)firma_id ergeben zusammen den primary key, weil in einer Firma
> nur ein Mal ein Name auftauchen darf.

Soso.

Bewerbungsschreiben:

| Sehr geehrte Damen un Herren!
|
| Hiermit blabla..
|
| mfg,
| Hans Müller


Antwortschreiben:

| Sehr geehrter Herr Müller!
|
| Nach Rücksprache mit dem Verantwortlichen unserer Personaldatenbank,
| Herrn Dennis Kuntzemann, müssen wir Ihnen zu unserem Bedauern
| mitteilen, dass Sie für die vakante Stelle nicht in Frage kommen,
| weil wir bereits einen Hans Müller in unserem Unternehmen
| beschäftigen.
|
| mfg,
| [krakel]


SCNR ;-).

Bei einer Firma würde ich "Personalnummer" als PK-Kanditat in Erwägung
ziehen, bei mehreren einfach eine auto_increment-Spalte.

gruss, heli