Zusammengesetzter Primärschlüssel aus technischen + fachlichem PK ?

[Melanin]

Hallo,

was haltet Ihr davon einen zusammengesetzten Primärschlüssel zu bilden aus technischem und fachlichem PK ?

[dr.dimitri]

Nichts. Ein fachliches Feld liegt ausserhalb Deiner Kontrolle und kann sich ändern, was wiederum der Unveränderlichbarkeit eines PK widerspricht.

Wenn dein technisches Feld nicht unique ist, leg ein weiteres nur für den PK an.

Dim

Bearbeitet 18. Dezember 2008 von dr.dimitri

[Melanin]

Nichts.

sowas dachte ich mir... dennoch bleibt die Frage offen:

z.B. N Abteilungen haben M Mitarbeiter sprich Mitarbeiter kann in mehreren Abteilungen zugehörig sein wegen Beteiligungen an verschiedenen Projekten etc... Nun würde ich für Mitarbeiter einen künstlichen PK mitarbeiter_id nehmen und für Abteilung einen fachlichen PK, denn die Abteilung darf ja nicht 2x existieren was bei einem künstlichen abteilung_id PK möglich ist. Löse ich das dann auf Programmebene, wenn ich einen künstlichen PK für Abteilung nehme indem ich teste ob es die Abteilung schon gibt in der Tabelle und ggf. nichts hinzufügen lasse?

[dr.dimitri]

Löse ich das dann auf Programmebene, wenn ich einen künstlichen PK für Abteilung nehme indem ich teste ob es die Abteilung schon gibt in der Tabelle und ggf. nichts hinzufügen lasse?

Bloß nicht. Das ist das Schlimmste was man machen kann (und würd in einer Multiuserumgebung auch nicht funktionieren). Du legst auf das entsprechende fachliche Feld (oder Felder) einen Unique Constraint und fängst die entsprechende Fehlermeldung im Programm ab.

Dim

[Melanin]

Bloß nicht. Das ist das Schlimmste was man machen kann (und würd in einer Multiuserumgebung auch nicht funktionieren). Du legst auf das entsprechende fachliche Feld (oder Felder) einen Unique Constraint und fängst die entsprechende Fehlermeldung im Programm ab.

Dim

nochmals für mich zum Mitschreiben ;-)

Mache ich es so:

fachliches Feld ist PK + gleichzeitig unique

oder so:

künstlicher PK abteilung_id wobei das field abteilung_name fachliches Feld unique ist

hm ersteres macht kein Sinn denke ich da fachlicher PK ja nie einen gleichen Wert erlaubt ^^

ok also mache ich letzteres.

Das heißt also, dass bei N:M Beziehungen immer künstliche PK´s vorzuziehen sind und diese werden dann unique gemacht sprich wenn ich mehrere gleiche Abteilungen hinzufügen will, dann wird eben eine Exception in meinem Programm geworfen auf die ich reagiere ok, das test ich mal... danke!

Was macht es eigentlich für einen Sinn einen künstlichen PK z.B. abteilung_id als unique zu setzen? Damit heble ich ja den auto_Increment aus??

Bearbeitet 21. Dezember 2008 von Melanin

[Melanin]

Was macht es eigentlich für einen Sinn einen künstlichen PK z.B. abteilung_id als unique zu setzen? Damit heble ich ja den auto_Increment aus??

nicht das ich das machen wollte, ich frage weil es möglich ist...

[dr.dimitri]

Das heißt also, dass bei N:M Beziehungen immer künstliche PK´s vorzuziehen sind und diese werden dann unique gemacht

Öhm wie? Ein PK sollte (besser: muss) immer ein rein technischer Schlüssel sein. Egal in welcher Beziehung die Tabelle zu anderen steht. Um eine fachliche Anforderung abzudecken muss auch ein fachliches Feld verwendet werden, und in deinem Fall lautet die fachliche Anforderung: Jeder Abteilungsname darf nur einmal vorkommen -> Uniqueconstraint auf das fachliche Feld. Dieser Constraint hat dann mit dem PK auch rein gar nichts zu tun - so wie es sein sollte.

Was macht es eigentlich für einen Sinn einen künstlichen PK z.B. abteilung_id als unique zu setzen? Damit heble ich ja den auto_Increment aus??

Keine Ahnung was Du damit meinst. Ein PK ist implizit immer schon unique und NOT NULL , das musst Du nicht extra angeben und davon war auch nie die Rede. Wieso denkst Du, dass Du damit irgendwas aushebelst?

Dim

[dr.dimitri]

nicht das ich das machen wollte, ich frage weil es möglich ist...

Ein PK und ein AutoInc Feld haben nichts miteinander zu tun. Beides kann auch ohne den anderen existieren.

Dim

[Melanin]

Öhm wie? Ein PK sollte (besser: muss) immer ein rein technischer Schlüssel sein.

ich dachte das sein immer eher wichtig bei Datawarehouse anwendungen der technische PK. Warum darf der PK kein fachlicher Schlüssel sein, gibt zig Beispiele dafür??

Egal in welcher Beziehung die Tabelle zu anderen steht. Um eine fachliche Anforderung abzudecken muss auch ein fachliches Feld verwendet werden, und in deinem Fall lautet die fachliche Anforderung: Jeder Abteilungsname darf nur einmal vorkommen -> Uniqueconstraint auf das fachliche Feld. Dieser Constraint hat dann mit dem PK auch rein gar nichts zu tun - so wie es sein sollte.

das heißt also das fachliche feld abteilungsname welches nur einmal vorkommen darf wird unique gesetzt ABER NICHT als PK gesetzt?

Keine Ahnung was Du damit meinst. Ein PK ist implizit immer schon unique ... Wieso denkst Du, dass Du damit irgendwas aushebelst?

department_id.......department_name

1........................Entwicklung

2........................Buchhaltung

3........................Auftragsbearbeitung

Klar hier ist department_id unique(einzigartig) aber der department_name eben nicht sprich ich könnte ohne weiteres einen doppelten department_name hinzufügen ohne dass die Datenbank anstalten macht.

vergiss das mit dem aushebeln, war verständnisproblem

[dr.dimitri]

ich dachte das sein immer eher wichtig bei Datawarehouse anwendungen der technische PK.

Ein PK wird für die RI benötigt, welche einen konsistenten Datenstand sicherstellt. Ob das jetzt eine OLAP oder OLTP Anwendung ist, ist egal - wenn die Anforderung da ist, wird es gemacht.

Warum darf der PK kein fachlicher Schlüssel sein, gibt zig Beispiele dafür??

Ja gibt auch zig Beispiele dafür wo das ganz gründlich in die Hose gegangen ist. Du könntest natürlich einen fachlichen Wert als PK verwenden - der DB ist das erstmal egal. Aber spielen wir das mal anhand deiner Anwendung weiter.

Du hast eine n:m Verknüpfung von Abteilung und Mitarbeiter, bedeutet du brauchst auch eine Auflösungstabelle in die der PK der Abteilung und des Mitarbeiters eingetragen wird. Kommt jetzt irgendwer auf die Idee die Abteilung umzubenennen, würde das deinen PK verändern und damit hast ein echtes Problem, denn alle Tabellen die deine Abteilungstabelle referenzieren müssen angepasst werden. Sprich FK-Constraints ausschalten, Wert ändern, FK-Constraints wieder einschalten. Während dieser Zeit dürfen natürlich keine Änderungen vorgenommen werden, Du hast als Downtime.

Verwendest Du statt des fachlichen Feld ein technisches Feld, interessiert dich das Umbenennen der Abteilung nicht die Bohne. Du kannst das sogar per Programmoberfläche anbieten und musst dich nicht weiter drum kümmern.

das heißt also das fachliche feld abteilungsname welches nur einmal vorkommen darf wird unique gesetzt ABER NICHT als PK gesetzt?

Richtig.

Klar hier ist department_id unique(einzigartig) aber der department_name eben nicht sprich ich könnte ohne weiteres einen doppelten department_name hinzufügen ohne dass die Datenbank anstalten macht.

Nein das Feld ist ja auch per Unique Constraint geschützt. Ich würd mir sogar überlegen, ob du nicht ein zweites Feld anlegst, in dem immer der UPPER oder LOWER Wert der Abteilung abgespeichert wird, und Du dort den Unique Constraint drauf legst anstatt auf department_name. Damit wären dann z.B. entwicklung und Entwicklung nicht erlaubt.

Zum Thema fachliches Feld als PK kann ich nur soviel sagen:

Jeder, der das ernsthaft vorschlägt hat entweder keine Ahnung oder keine Erfahrung in der Entwicklung von Datenbankanwendungen.

Jeder fachliche PK in einem ER-Modell ist ein potentieller Bug.

Daher: Am besten nicht einmal drüber nachdenken ob man einen fachlichen oder technischen PK verwenden soll. Ist verlorene Zeit. Immer einen technischen PK. Kostet absolut nichts. (Was natürlich nicht bedeutet, dass man nicht fragen darf/sollte warum ein technischer PK richtig und ein fachlicher falsch ist!)

Dim

Bearbeitet 21. Dezember 2008 von dr.dimitri

[Melanin]

ok danke dir nur wie gehts jetzt weiter:

das heißt also das fachliche feld abteilungsname welches nur einmal vorkommen darf wird unique gesetzt ABER NICHT als PK gesetzt?

Richtig.

1.) wenn Tabelle Abteilung keinen PK hat worauf referenziere ich dann den FK der Mitarbeiter?

2.) Ich muss mich in ein ORM tool einarbeiten bei dem jede Tabelle aber einen PK benötigt... dann stehe ich jetzt dumm da, wenn ich abteilung_name nur als unique setze...

[dr.dimitri]

Ähm hast dir auch genau durchgelesen was ich (und auch Du) geschrieben haben?

Es gibt (mindestens) zwei Spalten in der Tabelle Abteilung. Eine Spalte die heißt ID ist als autoinc definiert und besitzt einen PK Constraint. Dann gibt es eine zweite Spalte department_name die hat einen Uniqueconstraint. Wo ist da das Problem?

Dim

[Melanin]

Ähm hast dir auch genau durchgelesen was ich (und auch Du) geschrieben haben?

Es gibt (mindestens) zwei Spalten in der Tabelle Abteilung. Eine Spalte die heißt ID ist als autoinc definiert und besitzt einen PK Constraint. Dann gibt es eine zweite Spalte department_name die hat einen Uniqueconstraint. Wo ist da das Problem?

Dim

ja ich habs durchgelesen das ist es ja gerade, oben kam es anders rüber und zwar so:

ich habe eine Tabelle department mit EINEM Feld department_name und setze das lediglich unique.

Also ist es doch so wie ich am Angang dachte

DEPARTMENT:

department_id(PK+autoinc)........department_name(unique)

1.........................Entwicklung

2.........................Buchhaltung

3.........................Tarife

danke dir!

[Melanin]

ok habs getestet wie im letzten post funzt 1a gleiche department Namen eingegeben wird ne UpdateException geworfen auf die ich reagieren kann

[dr.dimitri]

Wenn Du das ganze noch caseinsensitive machen möchtest gehst wie folgt vor:

department_id | department_name | dep_upper_name |

1             | Entwicklung     | ENTWICKLUNG    |

2             | Personal        | PERSONAL       | 

Wenn Du jetzt anstelle von department_name den Unique Constraint auf die Spalte dep_upper_name legst, verhindest Du auch, dass jemand den gleichen Abteilungsnamen nochmal mit anderer Gross/Kleinschreibweise verwendet.

Ohne dieses Konstrukt ist es nämlich möglich die Namen Personal, personal pErsonal etc etc. zu verwenden ohne dass es eine Verletzung des Uniqueconstraints gibt.

Dim

PS: Je nach verwendetem Datenbansystem kannst auch einen funktionsbasierten Index dafür verwenden und dir somit die extra Spalte sparen.

Bearbeitet 21. Dezember 2008 von dr.dimitri

[Melanin]

Wenn Du jetzt anstelle von department_name den Unique Constraint auf die Spalte dep_upper_name legst, verhindest Du auch, dass jemand den gleichen Abteilungsnamen nochmal mit anderer Gross/Kleinschreibweise verwendet.

Ohne dieses Konstrukt ist es nämlich möglich die Namen Personal, personal pErsonal etc etc. zu verwenden ohne dass es eine Verletzung des Uniqueconstraints gibt.

Hm... das verstehe ich nicht. wenn dann NUR department_upper_name einen unique constraint hat ist es immer noch möglich in department_name das gleiche einzugeben eben kleingeschrieben.

Weiterhin stellt sich die Frage in welches Feld ich jetzt versuche den Abteilungsnamen abzuspeichern? Klar eigentlich in beide damit kleiner/großer geschriebener Abteilungsname nicht persistiert werden kann, geiles Wort!

Doch jedesmal in 2 felder was einlesen ist ähm ja...

Gibts so einen funktionsbasierten index für SQLite ?

[dr.dimitri]

ist es immer noch möglich in department_name das gleiche einzugeben eben kleingeschrieben.

Über deine Eingabemaske bekommst den Wert in einer Variablen. Und deinem Insert übergiebst eben diese Variable zusätzlich noch ein zweites mal nur eben, dass Du sie dann vorher per Stringfunktion "geuppert" hast. Bei einem Update das gleiche. Das ist ein Aufwand von ca. einer Minute das einzubauen (mal grob geschätzt).

das würd pseudocodemäßig so aussehen:

insert into abteilung (department_name,dep_upper_name) values(deine_variable,UPPER(deine_variable))

Im SELECT wird natürlich weiterhin nur die Spalte department_name gelesen.

Gibts so einen funktionsbasierten index für SQLite ?

Nein. Soweit ich weiß gibts dort nicht mal referentielle Integrität. Du kannst zwar einen Primary und Foreign Key anlegen aber sqlite ignoriert das stillschweigend. Ich würd mit so kleinen Datenbanken wirklich nur Daten verwalten die nicht besonders wichtig sind.

Evtl. für kleinere Tests oder Anwedungen wie iTunes die irgendwelche Daten lokal für einen User speichern müssen oder im embedded Bereich mit knappen Ressourcen.

Zum Üben ist sqlite m.M. nach eher ungeeignet da vieles nicht unterstützt wird was eine DB eigentlich ausmacht.

Um welche Anwendung handelt es sich denn bei dir denn? Nur eine Übung oder wird das auch mal produktiv eingesetzt? Evtl. noch von mehreren Usern gleichzeitig?

Dim

[Melanin]

Über deine Eingabemaske bekommst den Wert in einer Variablen. Und deinem Insert übergiebst eben diese Variable zusätzlich noch ein zweites mal nur eben, dass Du sie dann vorher per Stringfunktion "geuppert" hast. Bei einem Update das gleiche. Das ist ein Aufwand von ca. einer Minute das einzubauen (mal grob geschätzt).

das würd pseudocodemäßig so aussehen:

insert into abteilung (department_name,dep_upper_name) values(deine_variable,UPPER(deine_variable))

Im SELECT wird natürlich weiterhin nur die Spalte department_name gelesen.

Nein. Soweit ich weiß gibts dort nicht mal referentielle Integrität. Du kannst zwar einen Primary und Foreign Key anlegen aber sqlite ignoriert das stillschweigend. Ich würd mit so kleinen Datenbanken wirklich nur Daten verwalten die nicht besonders wichtig sind.

Evtl. für kleinere Tests oder Anwedungen wie iTunes die irgendwelche Daten lokal für einen User speichern müssen oder im embedded Bereich mit knappen Ressourcen.

Zum Üben ist sqlite m.M. nach eher ungeeignet da vieles nicht unterstützt wird was eine DB eigentlich ausmacht.

Um welche Anwendung handelt es sich denn bei dir denn? Nur eine Übung oder wird das auch mal produktiv eingesetzt? Evtl. noch von mehreren Usern gleichzeitig?

Dim

wir sind alle produktiv hier! ne spasseken ist ein Übungsfeld um mic in sql einzuarbeiten... ich hab mit Abteilungen net viel am Hut ist aber oftmals ein Musterbeispiel... Sqlite keine RI? stimmt OnDelete Cascade geht da net wenn die Master Table flöten geht... Ja selbst die lokal db sql ce vo MS hat RI naja vllt. schau ich mir mal firebird an.

[dr.dimitri]

naja vllt. schau ich mir mal firebird an.

Vom Regen in die Traufe wie? Nimm leiber gleich was vernünftiges. PostgreSQL oder die kostenlose Oracle XE

Dim

[Melanin]

Vom Regen in die Traufe wie? Nimm leiber gleich was vernünftiges. PostgreSQL oder die kostenlose Oracle XE

Dim

ach das hab ich vergessen, nene sollte eine lokale DB sein kein server da gibts halt nur sqlite,firebird etc leider... dabei werden die lokalen db`s doch immer wichtiger wegen android,iphone,windows mobile etc

[Melanin]

witzig gerade probiert: Die sql ce hat RI + macht keinen Unterschied zwischen "test" oder "TEST" das ist nett im Vergleich zu sqlite ^^

[Melanin]

Gibts so einen funktionsbasierten index für SQLite ?

Nein.

habe das department_name feld bei Collate auf "NOCASE" gesetzt. Jetzt wird nicht mehr unterschieden zwischen "TeSt" und "test" bei sqlite 3