Access-o-Mania

Access-Forum (Deutsch/German) => Access-Hilfe => Thema gestartet von: Greif am Februar 25, 2013, 19:44:01

Titel: m:n Beziehung nicht möglich
Beitrag von: Greif am Februar 25, 2013, 19:44:01
Hallo, habe ein kleines Problem:

Ich kann keine m:n Zwischentabelle an eine Primärtabelle anhängen, da in dieser schon der Primärschlüssel für eine andere Tabelle belegt ist und benötigt wird.
Wie kann ich dasw Problem umgehen?
Doppelter Primärschlüssel in der Primätabelle wird beim Setzen der Beziehungennicht zu m:n Verknüpfungstabelle akzeptiert.

Ich bitte um Hilfe, bin Access - Anfänger.....

Schaut bitte mal in den Anhang:

Das Feld MaschineBezeichnung in der Tabelle  m:n Zuordnung lässt sich nicht mit dem Feld Maschinenfreigabe für Maschien in der Tabelle Produktinfo verknüpfen
da der Promärschlüssel bei Fehler ID gesetzt ist. - Den brauch ich aber....

Vielen Dank



[Anhang gelöscht durch Administrator]
Titel: Re: m:n Beziehung nicht möglich
Beitrag von: database am Februar 25, 2013, 21:06:15
Hallo,

ich würde sagen, dass da einige Änderungen anstehen, soweit sich dazu eine konkrete Aussage zum Abbild der Beziehungen erstellen läßt.

Der Tabelle 'Maschinentabelle' solltest du einen numerischen Primärschlüssel verpassen (MaschinenID, AutoWert)
und den derzeitigen Primärschlüssel von 'Maschinenbezeichnung' wegnehmen.
In der Tabelle 'm:n Zuordnung' nimmst du dann dieses Feld auch als Fremschlüssel auf und nimmst 'Maschinen Bezeichnung' raus.
Die Beziehung zwischen 'm:n Zuordnung' und 'Maschinentabelle' stellst du dann über diese beiden Felder her.

In der Tabelle 'Produktinfo' nimmst du das Feld 'Maschinenfreigabe für Maschine' raus.
In die Tabelle'm:n Zuordnung' nimmst du zusätzlich ein Feld 'ProduktID_F', Zahl, LonInteger auf, änderst den Primärschlüssel der Tabelle 'Produktinfo' auf das Feld ProduktID' und stellst die Beziehung zur Tabelle 'Produktinfo' über diese beiden Felder her, das Feld 'ID m:n' benennst du auf 'ZuordnungID' um und änderst es auf AutoWert und verpaßt diesem Feld den Primärschlüssel für diese Tabelle.
Über die Felder ProduktID_F, Maschine Bezeichnung und Maschinenfreigabe für Maschine legst du einen eindeutigen Index um Duplikate zu verhindern.

Das Feld 'FehlerID' muß aus der Tabelle 'Produktinfo' raus und ein Feld ProduktID_F, Zahl, LongInteger in die Tabelle 'Fehler' rein.
Das Feld 'FehlerID' in der Tabelle 'Fehler' änderst du zu AutoWert und vergibst darauf den Primärschlüssel.
Die Beziehung zwischen 'Produktinfo' und 'Fehler' stellst du über die Felder ProduktID und ProduktID_F her.

Wenn mehrere Kunden das gleiche Produkt beziehen können oder Ein Kunde mehrere Produkte beziehen kann, fehlt eine Zwischentabelle  'ProduktKunde' mit den Feldern KundenID_F und ProduktID_F, beide LongInteger und mit den Primärschlüsseln der beiden Tabellen in Beziehung gesetzt.
Dass die Tabelle 'Kundeninfo' einen Primärschlüssel in Form eines AutoWertes benötigt, erklärt sich aus den vorangegangenen Hinweisen.
Also den Primärschlüssel von Feld 'Kunde' entfernen ein Feld 'KundenID', AutoWert, Primärschlüssel einfügen.
Das Feld 'Kunde' ist dann aus der Tabelle 'Produktinfo' zu entfernen.

Danach oder besser noch vor diesen ganzen Dingen nimmst du alle Leerzeichen, Umlaute und Sonderzeichen aus den Feld- und Tabellennamen
und ersetzt Datum durch 'FehlerDatum' - reservierte Namen solltest du ebenfalls tunlichst vermeiden. 'm:n Zuordnung' ist ein denkbar schlechter Tabellenname.

Weiter solltest du in allen anderen Tabellen ebenfalls einen numerischen Primärschlüssel führen und die Fremdschlüsselfelder in den verbundenen Tabellen entsprechend anpassen.

Insgesamt solltest du dich mit den Grundlagen des relationalen Datenbankentwurfs auseinandersetzen, um ein gut fu nktionierendes Datenmodell aufbauen zu können. Diese Grundlagen sind speziell für einsteiger unumgänglich, sie helfen und vermeiden nachfolgenen Frust.  ;)

Du findest hierzu in den Linklisten der Signatur des Benutzers 'DF6GL' (#1 und #1a) sowie unter diesem Link

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)

eine Menge nützlicher und vor Allem wichtiger Informationen dazu.

Titel: Re: m:n Beziehung nicht möglich
Beitrag von: Greif am Februar 26, 2013, 13:57:24
Hallo database,

Danke für deine erstklassige Hilfe!
Dass die Tabelle Kundeninfo einen Promärschlüssel benötigt, ist klar.
Die Zuordnung der Tabellen Fehler und Zuordnung Maschine_m_n (bzw. m:n Zuordnung) ist auch schlüssig; ich hoffe von mir richtig umgesetzt.
Was mir aber nicht ganz klar ist, ist dass ich zwischen der Tabelle Kundeninfo und Produktinfo eine m:n Beziehung erstellen muss:

Ein Produkt soll nur von einem Kunden bezogen werden.
Es gibt zwar mehrere Produkte und mehrere Kunden, ein Produkt wird allerdings nur an einen Kunden verkauft.
Der Kunde kann aber mehrere Produkte beziehen.
Kannst Du mir da noch auf die Sprünge helfen? Danke.

Noch drei Frage nebenbei:
Hast Du beruflich mit Datenbanken zu tun?
Falls ja, was hälst Du von Access im allgemeinen im Vergleich zu Mysql und Oracle?
Wie weit sollte man die Tabellen normalisieren? (3.NF?)

In der Anlage habe ich einen Auszug meiner neu angelegten Beziehungen beigefügt - ich hoffe die sehen jetzt besser aus.

Besten Dank

Gruß Marko :D







[Anhang gelöscht durch Administrator]
Titel: Re: m:n Beziehung nicht möglich
Beitrag von: database am Februar 26, 2013, 16:27:12
Hallo,

zu deinen Fragen:

1. ... hatte ich.
2. ... Access als Desktop-Datenbank und als C/S im Mehrbenutzerumfeld für überschaubare Anwendungen (und überschaubare Benutzeranzahl) durchaus OK.
        MySQL - naja, manchmal eine 'Glaubensfrage' wenn's eine DB-Serverlösung für kleinere Sachen sein soll ginge auch die MS-SQL-Server Express Edition,
        bei größeren Sachen der MS-SQL Server in jeglicher Version.
        Oracle - ein Monster was den Funktionsumfang betrifft etc.
        Alle 3 Varianten sind aber mit Access-Frontends einsetzbar.
3. ... UNBEDINGT bis zur 3.NF!

Zitat
Es gibt zwar mehrere Produkte und mehrere Kunden, ein Produkt wird allerdings nur an einen Kunden verkauft.
Der Kunde kann aber mehrere Produkte beziehen.


Ohne m:n müsstest du für jedes Produkt einen eigenen Kunden-Datensatz erstellen - womit die Normalisierung im Eimer wäre.

Die neue Version schau ich mir gerne am Abend an ...

Titel: Re: m:n Beziehung nicht möglich
Beitrag von: Greif am März 07, 2013, 11:02:27
@database:

Kannst Du mal einen Blick auf die neu angelegten Beziehungen werfen?
Wäre nett, dann kann ich an meiner DB weiterarbeiten...
:-[

Danke

Gruß Marko
Titel: Re: m:n Beziehung nicht möglich
Beitrag von: database am März 07, 2013, 13:10:29
Hallo,

gerne, kannst du statt dem *.pdf nicht die DB komprimiert/repariert und gezippt hier hochladen, ich denke damit kann ich dir leichter und verständlicher helfen.
Titel: Re: m:n Beziehung nicht möglich
Beitrag von: Greif am März 09, 2013, 16:47:04
Hallo database,

hier ist die DB, an der ich angefangen habe....
Sie besteht momentan nur aus Tabellen ohne Inhalt.
Mache erst weiter, wenn die Beziehungen vernünftig eingerichtet sind.
Danke für die Hilfe... :)

Gruß Marko

[Anhang gelöscht durch Administrator]
Titel: Re: m:n Beziehung nicht möglich
Beitrag von: database am März 09, 2013, 17:19:55
Hallo,

ich habe die DB ein klein wenig nachgearbeitet.

Ich vermute mal, dass es hier um eine Sammlung von Fertigungsdaten zur Fehleranalyse geht (im weitesten Sinn)
Sollte es feststellbar sein welche Maschine an der Herstellung eines Produkts beteiligt war, als ein Fehler aufgetreten ist,
wäre es besser die Beziehung zwischen tblProduktinfo und tblFehler zu entfernen, das Feld 'Produkt_ID_F' aus der tblFehler zu entfernen
und statt dessen ein Feld 'Zuordnungs_ID_F' in der tblFehler zu erstellen (Zahl, LongInteger) und dieses mit Zuordnungs_ID in der tblMaschineProdukt 1:n in Beziehung zu setzen.

Ansonst gäbe es nichts auszusetzen  ;D

Die geänderte DB ist im Anhang

HTH


[Anhang gelöscht durch Administrator]
Titel: Re: m:n Beziehung nicht möglich
Beitrag von: Greif am März 10, 2013, 09:40:34
Hallo database,


"Ich vermute mal, dass es hier um eine Sammlung von Fertigungsdaten zur Fehleranalyse geht (im weitesten Sinn)"
;) Gut getippt....


Danke nochmals