Hallo zusammen,
nachdem ich nun mein Datenbankmodell erfolgreich auf Papier umgesetzt habe, bin ich nun dabei dies in Access umzusetzen.
Auf meinem Papierentwurf habe auch schon alle Kardinalitäten zwischen den Tabellen aufgeschrieben.
Nun weiß ich nicht wie ich diese in Access umsetzen kann. Auf der Suche im Internet und auch hier im Forum bin ich zwar oft auf die gleiche Frage gestoßen, doch wirklich beantwortet hat die Frage bisher noch niemand wirklich. Es wurde immer nur nach dem "Warum" nach der Kardinalität gefragt und dem Fragesteller mitgeteilt er soll das anders lösen.... aber das kann ja nicht die Lösung sein.
Bei den Kardinalitäten in einem Datenbankmodell kann ja zwischen 16 Kardinalitäten unterschieden werden.
Nun würde ich in Access gerne die Kardinalität 1:1 und 1:c umsetzen.
Der Unterschied zwischen beiden sieht wie folgt aus:
Bei 1:1 muss A ein B und B muss ein A zugeodent sein.
Bei 1:c kann A ein B aber B muss ein A zugeorndet werden.
In den meisten Antworten die ich bisher gefunden habe, wurde vorgeschlagen die 1:c als 1:n Beziehung umzusetzen. Dies ist aber falsch, weil es nicht dieser Kardinalität entspricht. Ebenso falsch ist es, die als 1:1 Beziehung umzusetzen.
Auch finde ich die Lösung nicht gut, die Tabelle wegzulassen und alles in einer Tabelle zu lösen, denn damit verletzte ich eine der Normalformen.
Leider weiß ich aber nicht, wie ich diese 1:c-Kardinalität umsetze?
Die Idee ist, dies über den Verknüpfungstyp bzw. die Verknüpfungseigenschaft zu lösen. Nur ich weiß leider nicht welchen ich hier wählen muss.
Zumindest bin ich mir sicher, dass bei einer 1:1-Beziehung die Verknüpfungseigenschaft 1 der 1:1-Kardinalitöt entspricht.
Nun liegt die Vermutung nahe, dass die Verknüpfungseigenschaften 2 und 3, die beiden anderen Möglichkeiten 1:c und c:1 repräsentieren.
Nur welche Eigenschaft gehört zu welcher Kardinalität?
Ich hoffe mir kann hier jemand weiterhelfen.
Gruß
Nach etwas rumprobieren, würde ich mich für folgende Zuordnungen entscheiden:
1:1 Verknpüfungseigenschaft 1
1:c Verknpfüungseigenschaft 3
c:1 Verknüpfungseigenschaft 2
Ist dies richtig?
Hallo,
Zitatin einem Datenbankmodell kann ja zwischen 16 Kardinalitäten
...und die wären bitte welche?
Scheinbar gibt es ein Definitionsproblem zum Begriff Kardinalität - siehe dazu bitte da kurz rein:
http://www.dbwiki.net/wiki/Access_Anf%C3%A4nger:_Grundlagen_des_Datenbank-Designs (http://www.dbwiki.net/wiki/Access_Anf%C3%A4nger:_Grundlagen_des_Datenbank-Designs)
Da sich auf dem Papierentwurf sowie im physikalischen Datenmodell kein Unterschied bei der Erstellung von Beziehungen ergeben sollte - in beiden Fällen werden diese über die Primärschlüssel und deren Fremdschlüssel festgelegt - ergeben sich 3 Verknüpfungseigenschaften - 1:n, 1:1 und n:m.
1:n besagt, dass einem Datensatz der 1-Seite ein, kein oder mehrere Datensätze der n-Seite zugeordnet werden können. (Standard)
1:1 besagt, dass einem Datensatz der linken 1-Seite GENAU ein Datensatz der rechten 1-Seite zugeordnet werden DARF. (Äusserst selten benötigt, zeigt in der Regel an, dass eine Tabelle mehr oder weniger geteilt wurde)
n:m besagt, dass beliebig vielen Datensätzen der n-Seite beliebig viele Datensätze der m-Seite zugeordnet werden können. (Handlungsbedarf)
Da mit direkten n:m Beziehungen NICHT gearbeitet werden kann, werden diese Beziehungen über eine s.g. Zwischentabelle in 2x 1:n aufgelöst.
Wenn du nun deine Tabellen in Access erstellt und die Primärschlüssel bestimmt hast, auf den jeweiligen n-Seiten entsprechende Fremdschlüssel in den Tabellen stehen und die Feld-Datentypen
der Schlüsselfelder übereinstimmen kannst du die Beziehungen erstellen, indem du den Primärschlüssel der 1:Seite auf den Fremdschlüssel der n-Seite per Drag&Drop legst.
In den Beziehungseigenschaften setzt du dann noch den Haken bei 'Mit referentieller Integrität' und das wars auch schon.
Du gibst im Daten- / Tabellenmodell keine Verknüpfungseigenschaften an, das ist vollkommen unnötig!
Näheres zu Datenmodellierung, Tabellendesign und relationalem Datenbankdesign findest du in den Links #1 und #1a in der Signatur von DF6GL
oder vielen anderen einschlägigen Internetseiten, die sich mit diesem Thema beschäftigen.
Zitatund dem Fragesteller mitgeteilt er soll das anders lösen.... aber das kann ja nicht die Lösung sein
Schätze, dass das normal ist, da sich die Frage immer auf ein BESTIMMTES Problem bezogen haben wird und so eine problembezogene Antwort gegeben wird.
Allgemeines zu Datenbankdesign wirst du also in Forenbeiträgen nicht vorrangig finden können, wenn ein bestimmtes Problem diskutiert wird.
Hallo database,
kann zein dass es dawirklich ein Definitions- oder Verständnisproblem gibt.
Zitat von: database am Oktober 08, 2011, 08:02:01
Hallo,
Zitatin einem Datenbankmodell kann ja zwischen 16 Kardinalitäten
...und die wären bitte welche?
Scheinbar gibt es ein Definitionsproblem zum Begriff Kardinalität - siehe dazu bitte da kurz rein:
http://www.dbwiki.net/wiki/Access_Anf%C3%A4nger:_Grundlagen_des_Datenbank-Designs (http://www.dbwiki.net/wiki/Access_Anf%C3%A4nger:_Grundlagen_des_Datenbank-Designs)
Da sich auf dem Papierentwurf sowie im physikalischen Datenmodell kein Unterschied bei der Erstellung von Beziehungen ergeben sollte - in beiden Fällen werden diese über die Primärschlüssel und deren Fremdschlüssel festgelegt - ergeben sich 3 Verknüpfungseigenschaften - 1:n, 1:1 und n:m.
1:n besagt, dass einem Datensatz der 1-Seite ein, kein oder mehrere Datensätze der n-Seite zugeordnet werden können. (Standard)
1:1 besagt, dass einem Datensatz der linken 1-Seite GENAU ein Datensatz der rechten 1-Seite zugeordnet werden DARF. (Äusserst selten benötigt, zeigt in der Regel an, dass eine Tabelle mehr oder weniger geteilt wurde)
n:m besagt, dass beliebig vielen Datensätzen der n-Seite beliebig viele Datensätze der m-Seite zugeordnet werden können. (Handlungsbedarf)
Da mit direkten n:m Beziehungen NICHT gearbeitet werden kann, werden diese Beziehungen über eine s.g. Zwischentabelle in 2x 1:n aufgelöst.
Soweit geb ich Dir vollkommen Recht und soweit hab ich das auch alles verstanden. Nur wenn wir jetzt die "Optionalität" (
muss/muss; kann/kann; kann/muss und muss/kann) ins Spiel bringen komm ich auf 16 Kardinalitäten.
Ich hab meinem Post eine Abbildung mit einer Matrix dieser 16 möglichen Kardinalitäten angehängt. Diese Abbildung ist nicht von mir, sondern aus dem Buch: Bodendorf, F.: Daten- und Wissensmanagement; 2. Aufl.; Berlin/Heidelberg; 2006; S. 17
Ähnliche Einteilungen habe ich auch noch in anderen Büchern gefunden. Um noch ein weiteres Beispiel zu nennen: Jarosch, H.; Grundkurs Datenbankentwurf - Eine beispielorientierte Einführung für Studenten und Praktiker; 2. Aufl.; Wiesbaden; 2003; S. 51
Die 16 Kardinalitäten sind ja nicht meine Idee. Aber eigentlich ist ja nicht die Bezeichnung einer Sache das Problem von mir. Ich möchte ja konkret ab mit Access umsetzen und wie das dann heisst ist mir egal.
Und zwar geht es um folgenden Sachverhalt:
- Tabelle A kann (keine/eine) Tabelle B ODER (keine/eine) Tabelle C zugeordnet werden
- Tabelle B muss A zugeordente werden
- Tabelle B muss A zugeordente werden
Vielleicht ein kleines Beispiel noch dazu:
Ich habe eine Tabelle
Firmen der die Tabelle
Mitarbeiter zugeordnet ist. Hier hab ich eine
1:N Beziehung, weil ich einer Firma mehrere Mitarbeiter zuordene und einem Mitarbeiter muss ich eine Firma zuordenen.
Nun stehen in der Tabelle
Mitarbeiter alle Attribute, die für alle Mitarbeiter gleich sind. Nun können die Mitarbeiter aber unterschiedliche Funktionen in der Firma haben wobei jede Funktion unterschiedliche Attribute hat, die dem Mitarbeiter zugeordnet werden. Nehmen wir an es gibt nur zwei Funktionen, Chef und Angestellter. Hierfür mach ich dann zwei Tabellen. Eine Tabelle
Chef und eine Tabelle
Mitarbeiter, denen ich dann die passendenen Attribute zuweise.
Somit weiße ich der Tabelle
Mitarbeiter, je nach Funktion entweder die Tabelle
Chef oder die Tabelle
Mitarbeiter zu.
Wie würde ich das umsetzen?
Gruß
[Anhang gelöscht durch Administrator]
Hallo,
berücksichtige mal nur Beziehungen (auf Access bezogen und ohne jetzt "Kardinalität zu sagen):
1:1
1:n bzw. m:n = 1:n:m:1
und dabei nur den Verknüpfungstyp "bei denen .... der Felder.... gleich sind"
1:1 ist in aller Regel unbrauchbar (und nur in einigen Sonderfällen vernünftig)
"Tabelle a darf nur einen DS in Tabelle b besitzen" ist auch mit 1:n darzustellen. "darf" kann mit entspr. Programmierung/Überprüfung erledigt werden.
"Nehmen wir an es gibt nur zwei Funktionen, Chef und Angestellter. Hierfür mach ich dann zwei Tabellen."
wiederspricht den Normalisierungs-Regeln. "Attribute" dürfen nicht als "Tabellen" abgebildet werden.
Ob ein Mitarbeiter "Chef" oder "Angestellter" ist , ist ein Status (Funktion) , also ein Attribut des Mitarbeiters und muß demzufolge als Feld (Spalte) in der Tabelle tblMitarbeiter (bzw. tblFirmenmitarbeiter, siehe unten ) zu stehen kommen.
Je nach Konstellation Deiner Daten könnte sich eine solche Tabellenkonstruktion ergeben:
tblPersonen ( alle Personen, die (auch) als Mitarbeiter bei irgendwelchen Firmen in Frage kommen)
tblFirmen (alle Firmen, die im DB-Umfeld bekannt sein sollen)
tblFirmenMitarbeiter (oder "tblFirmenPersonen" in konsequenter Benamsung. Zuordnung der einzelnen Personen als Mitarbeiter zu den bestimmten Firmen)
tblFunktionen (Alle möglichen Funktionen, die Mitarbeiter einnehmen können)
Beziehungen:
tblFirmen --1:n -- tblFirmenMitarbeiter --m:1-- tblPersonen
tblFirmenMitarbeiter --n:1-- tblFunktionen
Verknüpfungstyp:1
Um zu vermeiden,(wenn es denn nicht sein darf) dass eine Person nicht mehrmals zu einer Firma zugeordnet werden darf (z. B. weil er nur den Chef und sonst nichts spielen darf) kann ein eindeutiger Index über die beiden Fremdschlüssel FirmaID und PersID in tblFirmenMitarbeiter gesetzt werden.
Verknüpfungstypen 2 und 3 sind eher nur für Auswertungen sinnvoll.
Hallo,
ich will da auch mal meinen Senf dazu geben. ;D
Der Begriff Kardinalität bildet nach meiner Auffassung die Anzahl der möglichen/erforderlichen Datensätze einer Beziehung ab und hat mit der Beziehung selbst nichts zu tun.
Die Kardinalität wird durch ein Zeichen gekennzeichnet, den man an die Beziehungsart dranhängt.
Zitat von: WikipediaDamit wird durch eine zusätzliche "Min-Angabe" mit '0' oder 'c' ('conditioned') festgelegt, dass die Beziehung optional ist - bzw. mit '1', dass die Beziehung (bei 'n' mindestens einmal) existieren muss. Beispiele: 1,1 : 0,n oder 1 : 1c
Eigentlich gibt es nur 2 Beziehungsarten.
1:1 Sehr selten sinnvoll und meist ein Hinweis auf ein falsches Datenmodell.
1:n Die häufigste Beziehungsart
n:m Ist keine eigenständige Beziehung, sondern 2 1:n Beziehungen.
Die Kardinalitäten muss man dann durch besondere Maßnahmen erreichen, die da z.B. sind:
- Pflichteingabe in Fremdschlüsselfeld
- Zusammengesetzter Index
- Datensatzzahl der n-Seite prüfen
Im Beziehungsfenster würde ich nur den Beziehungstyp 1 verwenden, alle anderen Typen nur in Abfragen falls erforderlich.
Die Beziehungend er Abfragen haben Vorrang.
Zitat"Nehmen wir an es gibt nur zwei Funktionen, Chef und Angestellter. Hierfür mach ich dann zwei Tabellen."
Und das das gründlich falsch ist, hat ja Franz schon erläutert.
Hallo,
vielen Dank Euch zwei für Eure Antworten, ich muss aber trotzdem nochmal nachbohren:
Zitat von: DF6GL am Oktober 08, 2011, 18:03:47
Beziehungen:
tblFirmen --1:n -- tblFirmenMitarbeiter --m:1-- tblPersonen
tblFirmenMitarbeiter --n:1-- tblFunktionen
Dann greif ich das Beispiel mal. Die tblFirmenMitarbeiter brauch ich doch eigentlich nicht, wenn ich jeder Person nur einer Firma zuordnen kann. Ich hab in meinem Fall aber auch keine m:n Beziehung zwischen den Tabellen Firmen und Personen, sondern eine 1:n.
Das würde dann meiner Meinung nach folgendermaßen aussehen. Ich erweitere das Beispiel mal noch um beispielhafte Attribute der Firmen. Die Unterstrichenen Attribute stellen den Primärschlüssel da. Enthält ein Attribut am Ende
-ID stellt es einen Fremdschlüssel da.
tblFirmen {
Firma-ID; Firma-Name; Firma-Adresee;}
1:n
tblMitarbeiter {
Mitarbeiter-ID;Firma-ID;Funktion-ID; Mitarbeiter-Name;}
n:1
Funktionen {Funktion-ID; Funktion-Bezeichnung}
in der tblFunktionen würde dann "nur" als Inhalte stehen:
Chef, Vertriebler, Entwickler
jetzt hab ich dann aber für jede "Funktion" eine eigene Tabelle, sprich:
tblChef {
Chef-ID;Mitarbeiter-ID; Zuständigkeit;Projekt; Vertretung}
tblVertriebler {
Vertrieb-ID; Mitarbeiter-ID; Kunde; Produkt}
tblEntwickler {
Entwickler-ID; Mitarbeiter-ID; Forschungsgebiet; CAD-System}
Nun möchte zwischen der tblMitarbeiter in Abhängigkeit seiner Funktion eine der Tabellen tblChef, tblVertriebler oder tblEntwickler zuordnen, wobei der (einzelne)
Mitarbeiter nur mit einer dieser Tabellen in Beziehung sein darf.
Ich weiß im Moment einfach nicht wie ich diese abhängige Beziehung abbilden kann.
Gruß
Hallo,
kannst Du bitte mal genau den Sinn der 3 letzten Tabellen beschreiben. Das habe ich nicht verstanden. Ich glaube nicht, dass das so sinnvoll ist.
Hallo,
Zitatjetzt hab ich dann aber für jede "Funktion" eine eigene Tabelle, sprich:
um es deutlich zu sagen:
das ist DB-technischer Unsinn.
Zitat von: DF6GL am Oktober 09, 2011, 09:49:28
Zitatjetzt hab ich dann aber für jede "Funktion" eine eigene Tabelle, sprich:
um es deutlich zu sagen:
das ist DB-technischer Unsinn.
Ok, danke für den Hinweis, nur weiß ich keine andere Lösung.
Aber wie löse ich es dann sinnvoll?
Ich versuch einfach mal verbal zu beschreiben.
Ich habe Firmen, den kann ich keinen/einen/mehrere Mitarbeiter zuordenen.
Ich habe Mitarbeiter, denen muss ich genau eine Firma zuordnen.
Die Mitarbeiter haben unterschiedliche Funktionen (z.B. Chef, Vertriebler, Entwickler,...)
Ein Chef kann einem/keinen/mehreren Mitarbeitern zugeordnet werden.
Ein Vertiebler kann einem/keinen/mehreren Mitarbeitern zugeordnet werden.
Ein Entwickler kann einem/keinen/mehreren Mitarbeitern zugeordnet werden.
ABER ein Mitarbeiter kann nur Chef, oder Vertiebler, oder Entwickler sein.
Ein Chef hat komplett andere Attribute/Eigenschaften, wie ein Vertiebler und ein Entwickler usw... daher die Tabellen für jede Funktion.
Und ich möchte diese entweder/oder-Konstruktion abbilden. Ich hab aber auch absolut keine Ahnung wie ich das umgehenen kann.
Meine Idee, die mir im Schlaf kam, war folgende (vermutlich aber auch total Unsinn):
Meine tblFirma: {
Firma-ID;Firma-Name;Firma-Gründungsjahr}
beispielhafte Datensätze:
- 1 - XYZ - 1900
- 2 - TV - 200
- n - .... - xxxx
Ich habe eine tblFunktion {
Funktion-ID; Funktion-Bezeichnung}
mit folgenden Datensätze:
- 1 - Chef
- 2 - Vertriebler
- 3 - Entwickler
Die tblMitarbeiter, würde dann wie folgt aussehen {
Mitarbeiter-ID;
Firma-ID;Funktion-ID;Mitarbeiter-Name;....}
Beispielsweise mit Folgenden Datensätzen:
- 1 - 2 - 2 - Mr. Propper
- 2 - 1 - 1 - Mister X
- 3 - 1 - 2 - Mister Y
- 4 - 2 - 1 - Q
- 5 .....
Nun kämen meine (wohl unsinnigen, aber ich hab keine andere Idee wie ich es anders machen kann, aber eine Idee, wie meine unsinnige Lösung umsetze und somit wohl noch unsinniger mache)) Tabellen ins Spiel.
tblChef {
Chef-ID;Mitarbeiter-ID;Funktion-ID;Zuständigkeit;Vertretung(ja/nein)}
Ich darf jetzt hier aber nur Mitarbeiter zuordenen, deren Funktion-ID=1 ist. (Ginge das über Gültigkeitsprüfung?)
der Datensetz würde dann bspw. so aussehen:
- 1 - 2 - 1 - wirtschaftliche Belange - nein
- 2 - 4 - 1 - technische Belange - ja
tblVertiebler {
Vertriebler-ID;Mitarbeiter-ID;Funktion-ID;Produktsparte;Region}
Ich darf jetzt hier aber nur Mitarbeiter zuordenen, deren Funktion-ID=2 ist.
der Datensetz würde dann bspw. so aussehen:
- 1 - 3 - 2 - Werkzeugmaschinen - Nord
- 2 - 1 - 2 - Waschmittel - Süd
tblVertiebler {
Vertriebler-ID;Mitarbeiter-ID;Funktion-ID;Forschungsgebiet;Anzahl-Patente}
Ich darf jetzt hier aber nur Mitarbeiter zuordenen, deren Funktion-ID=3 ist.
der Datensetz würde dann bspw. so aussehen:
Da bisher kein Mitarbeiter, die Funktion "Entwickler" zugeordnet wurde, ist dieser Datensatz leer.
Kann ich das so umsetzen? Ist das Datenbanktechnischer Schwachsinn? Wie würde das sinnvoll sein?
Gruß und vielen Dank für Eure Hilfe und Geduld,
@MzKlMU: Entspricht dieses Überprüfen, dem was du vorgeschlagen hast?
Zitat
Die Kardinalitäten muss man dann durch besondere Maßnahmen erreichen, die da z.B. sind:
- Pflichteingabe in Fremdschlüsselfeld
- Zusammengesetzter Index
- Datensatzzahl der n-Seite prüfen
Ich hab meine "Lösungsidee" aus dem Beitrag obendrüber mal ausprobiert und es funktioniert so.
Vielleicht ist es von der Datenbanktheorie her falsch und Unsinn, aber es ist praktikabel. Damit kann ich zumindest im Moment mit Leben.
D.h. aber nicht, dass mich die richtige sinnvolle Lösung nicht interssiert. Denn ich will ja nicht einfach ne Datenbank bauen, sondern ich will mir das Thema ja erarbeiten und dazu gehört es dann auch, dazuzulernen.
Daher wäre ich froh, wenn ich doch noch irgendwann für mein "Problem" eine sinnvolle und praktikable Lösung bekomm.
Gruß
Hallo,
Meine Ansicht:
Ich habe Firmen, den kann ich keinen/einen/mehrere Mitarbeiter zuordenen.
-- OK, entspricht der tblFirmenMitarbeiter
Ich habe Mitarbeiter, denen muss ich genau eine Firma zuordnen.
-- OK, ergibt sich von allein aus 1-n Bez. zwischen tblFirmen und tblFirmenmitarbeiter UND darin definiertem zusammengesetzten Index aus FirmaID und MAID
Die Mitarbeiter haben unterschiedliche Funktionen (z.B. Chef, Vertriebler, Entwickler,...)
-- Nicht ok , d. h. die "Funktion" ist kein Attribut des MA, sondern eine "FirmenMitarbeiters"
Ein Chef kann einem/keinen/mehreren Mitarbeitern zugeordnet werden.
-- ?? Ein "Chef" kann niemanden zugeordnet werden. Lediglich eine "Funktion" kann einem FirmenMitarbeiter aufgedrückt werden....
Ein Vertiebler kann einem/keinen/mehreren Mitarbeitern zugeordnet werden.
-- ?? dito
Ein Entwickler kann einem/keinen/mehreren Mitarbeitern zugeordnet werden.
-- ?? dito
ABER ein Mitarbeiter kann nur Chef, oder Vertiebler, oder Entwickler sein.
-- OK, ergibt sich von allein aus der o. g. Zuordnung
Ein Chef hat komplett andere Attribute/Eigenschaften, wie ein Vertiebler und ein Entwickler usw... daher die Tabellen für jede Funktion.nicht ok. "Chef" ist ein "Funktion"-Wert (als Attribut "Bezeichung" zu einer "Funktion" )
Aus
Ein Chef hat komplett andere Attribute/Eigenschaften (---> Jede Funktion hat verschiedene Attribute)
ergibt sich eine weitere Tabelle "tblFunktionAttribute" (FAID, FunktionID, FA_Attributbezeichnung, ... ) mit Beziehung tblFunktion --1:n-- tblFunktionAttribute"
PS: ich hoffe, Du kannst trotz "db-technischem Schwachsinn" in Zukunft wieder oder weiterhin gut schlafen ;) :)