Access-o-Mania

Access-Forum (Deutsch/German) => Tabelle/Abfrage => Thema gestartet von: Newcomer2016 am April 13, 2016, 11:55:12

Titel: Zwei Primärschlüsselfelder sinnvoll
Beitrag von: Newcomer2016 am April 13, 2016, 11:55:12
Hallo zusammen,

in meiner Datenbank habe ich zwei Tabellen. Eine mit Informationen zu einem Standort, Tabelle1. U.a. die Felder: "Standort", "Abteilung", "Jahr".
In Tabelle 2 habe ich dann Informationen über ein Projekt, das eben an einem Standort X, Abteilung Y, Jahr Z stattfinden soll/ bzw stattgefunden hat.
Jetzt finde ich keine Lösung für den Primärschlüssel in Tabelle1. Ich brauche jeder der Felder einzelnd, allerdings wird das Projekt nur eindeutig über die Kombination von Standort + Abteilung + Jahr identifiziert.
Jetzt überlege ich, ob es sinnvoll ist, Standort + Abteilung in ein Feld zu packen und dann das als einen Primärschlüssel zu nutzen und das Jahr irgendwie anders einzubauen.

Welche Lösungen gibt es denn da?

Vielen dank schonmal.

Titel: Re: Zwei Primärschlüsselfelder sinnvoll
Beitrag von: Wurliwurm am April 13, 2016, 12:55:49
Zitat von: Newcomer2016 am April 13, 2016, 11:55:12
zwei Tabellen. Eine mit Informationen zu einem Standort, Tabelle1. U.a. die Felder: "Standort", "Abteilung", "Jahr".

Das ist noch zu vage gefragt. Kennst Du die Regeln, wie man so etwas auf unterschiedliche Tabellen aufteilt?

Einmal: Wenn es irgendwelche funktionale Abhängigkeiten zwischen den drei Feldern geben sollte, gehören sie niemals zusammen in den Key.

Ausserdem: Die Nichtschlüsselfelder dürfen dann auch nur vom ganzen Key abhängig sein und nicht von einem Teil davon.
Titel: Re: Zwei Primärschlüsselfelder sinnvoll
Beitrag von: DF6GL am April 13, 2016, 13:00:46
Hallo,


wozu brauchst Du für die(se) Konstellation  zwei Tabellen?

tblProjekte
ProjID (Primärschlüsselfeld,Autowert)
Proj_Standort (Text) evtl. kann/muss dieses Feld zu einem Fremdschlüssel für "tblStandorte" umgebaut werden)
Proj_Abteilung (Text)   dito zu einem Fremdschlüssel für "tblAbteilungen"
Proj_ProjektDatum  (Datum/Uhrzeit,   das Jahr kann aus diesem Datum jederzeit berechnet werden)Proj_ProjektleiterID   (Long,Fremdschlüssel zu "tblMitarbeiter"  )
.
.
.
.

Über Proj_Standort, Proj_Abteilung und Proj_ProjektDatum wird ein zusammengesetzter eindeutiger Index gelegt.

Titel: Re: Zwei Primärschlüsselfelder sinnvoll
Beitrag von: Newcomer2016 am April 13, 2016, 13:42:55
Vielen Dank für die schnellen Antworten.

Als Beispiel für die zwei Tabellen:

Es geht praktisch um Betriebsrevisionen. Da werden ja verschiedene Standorte und deren Abteilungen besucht. Dort werden Begehungen durchgeführt, und die dort erfassten Informationen in einem Bericht ausgegeben.

Jetzt soll tbl1 eben generelle Informationen erfassen:
Standort
Abteilung
Jahr
Projektleiter

tbl2 dann die herausgefundenen Tatsachen und Empfehlungen. Jede einzelne Info und Empfehlung ist ein Datensatz dieser tbl. Muss also eindeutig einem Projekt aus tbl 1 zugeordnet werden können.
Und das , so dachte ich, geht nur eindeutig über Standort+Abteilung+JAhr.

Mir sind die Anzahl an Projekten jetzt schon bekannt und das ganze findet im jährliche Rythmus statt. Also wiederholen sich die Felder Standort und Abteilung im nächsten Jahr in tbl1. Eindeutig macht es dann quasi nur das Jahr, oder ?
Titel: Re: Zwei Primärschlüsselfelder sinnvoll
Beitrag von: MaggieMay am April 13, 2016, 14:03:07
Hallo,

was spricht dagegen, einen Autowert-Key als Primärschlüssel einzusetzen und einen eindeutigen Mehrfelderindex über die drei genannten Datenfelder anzulegen?
Titel: Re: Zwei Primärschlüsselfelder sinnvoll
Beitrag von: Newcomer2016 am April 13, 2016, 14:40:17
Okay,
ich versuche es mal mit diesem eindeutigen Mehrfelderindex.

Danke.
Titel: Re: Zwei Primärschlüsselfelder sinnvoll
Beitrag von: DF6GL am April 13, 2016, 18:36:26
Hallo,

bau die Tabellen gleich korrekt auf und Du hast später keine Probleme....

tblProjekte  (wie vorher beschrieben)   mit dem zusammengesetzten eindeutigen Index.



weiterhin:

tblAudits   
AudID (PK, Autowert)
Aud_ProjektID  (Long ,  Fremdschlüssel tu tblProjekte)
Aud_Bezeichnung (Text)
Aud_Datum (Datum/Uhrzeit)
.
.
.
  Weiter Felder, die für die Begehung Informationen tragen.



Beziehungen:

tblProjekte.ProjID  --- 1:n ----  tblAudits.Aud_ProjID
Titel: Re: Zwei Primärschlüsselfelder sinnvoll
Beitrag von: Newcomer2016 am April 14, 2016, 08:51:28
"Proj_Standort (Text) evtl. kann/muss dieses Feld zu einem Fremdschlüssel für "tblStandorte" umgebaut werden)
Proj_Abteilung (Text)   dito zu einem Fremdschlüssel für "tblAbteilungen" "

Hab deine hilfreichen Vorschläge versucht umzusetzen. Verstehe ich das richtig, das ich "Hilfstabellen" für die Standorte und Abteilungen brauche? Das hab ich dann gemacht und in der Haupttabelle dann per Nachschlageassistent als Drop-down Liste in Beziehung gestellt. Allerdings ist es dann (Zahl) und nicht mehr (Text). 

Beziehungen sind jetzt:
Hilfstabellen             Hauptabelle
tbl Standort          1 : n      tbl Audit_general.Standort_ID (Zahl)
tbl Abteilung         1 : n      tbl Audit_general.Abteilung_ID (Zahl)
tbl Mitarbeiter       1 : n      tbl Audit_general.Mitarbeiter_ID (Zahl)

Um dann die eigtl Hauptbeziehung herzustellen, in dem der Mehrfelderindex quasi vorkommen sollte:

tbl Audit general    1 : n      tbl Findings .Audit_ID (Zahl) (Findings =Begehung)

Falls ich das immer noch nich richtig verstehe, danke ich trotzdem vielmals für die Hilfen.

P.S.: Bei nem Mehrfachindex müssen die einzelnen Felder nicht zwangsläufig eindeutig sein, richtig?
Titel: Re: Zwei Primärschlüsselfelder sinnvoll
Beitrag von: DF6GL am April 14, 2016, 09:50:40
Hallo,

Du bist auf dem richtigen Weg..  :)

Wobei: 
--Sonder- und Lehrzeichen in Objektnamen dringen zu vermeiden sind.
--Dito für Nachschlagefelder in Tabellen.  Diese werden durch Kombifelder in Formularen ersetzt.


was bedeutet  "general" in  "tbl Audit_general"  ?


Insgesamt versteh ich aber jetzt nicht die Tabellennamen .. Ist "Audit" jetzt das frühere "Projekt" ?


ZitatBei einem Mehrfachindex müssen die einzelnen Felder nicht zwangsläufig eindeutig sein, richtig?

korrekt.  Ein solcher Index wird im Tabellenentwurf unter "Indizes"  definiert.



Titel: Re: Zwei Primärschlüsselfelder sinnvoll
Beitrag von: Newcomer2016 am April 14, 2016, 10:19:17
Tabellennamen, Entschuldigung:
die beiden Hauttabellen:
tbl_Audit (=früher Projekt)
tbl_Findings (=alle herausgefundnen Dinge einer Begehungen eines Audits in einem Jahr)
andren Tabellen:
tbl_Standort (bestehend aus ID,Autowert und Standort, kurzer Text)
tbl_Abteilung (dito für Abteilung)
tbl_Mitarbeiter (ganzen relevanten Infos Name, Vorname...)

in der tbl_findings muss ich natürlich die Audit_ID auswählen per  Drop_down Liste. Problem: Da erscheint dann der Zahlencode und nicht die eigtl Namen, was denkbar ungünstig ist...
Man kann quasi nur auswählen:
1     3     12.1.16
1     4     18.1.16  z.B.

Statt der 1 sollte der Standortname und statt der 3 / 4  sollte der Abteilungsname kommen?!  ???
Und kann es sein, das diese Drop-Down Liste unter Umständen ziemlich lang werden könnte? (Bsp.: bei zwanzig Audits /a sind das nach 5 Jahren 100 Audits bzw Audit_ID die dann da zr Auswahl stehen würden.)



Titel: Re: Zwei Primärschlüsselfelder sinnvoll
Beitrag von: DF6GL am April 14, 2016, 10:24:50
Hallo,
wir reden jetzt noch nicht von Formularen.. Die kommen erst dran, wenn die Logik des Tabellenaufbaus (Schlüsselfelder, sonstige Felder(mit den korrekten Datentypen), Tabellennamen und Beziehungen )  stimmig ist.

Lad mal einen Screenshot des Beziehungsfensters hoch..
Titel: Re: Zwei Primärschlüsselfelder sinnvoll
Beitrag von: Newcomer2016 am April 14, 2016, 10:46:34
Okay, hab zwei Bilder mal als Anhang dran.
Titel: Re: Zwei Primärschlüsselfelder sinnvoll
Beitrag von: DF6GL am April 14, 2016, 11:01:51
Hallo,

nochmal: wirf diese Nachschlagefelder aus der Tabelle!

dann erstelle für jede Tabelle ein Endlosform, außer für tblAuditGeneral  (Jeder Tabelle den Prefix "tbl" zuordnen..), das sollte ein Einzelform sein. Die Felder für tblStandorte und tblAbteilungen werden als Kombifelder ausgeführt (und richtig eingestellt natürlich)


Füge dann in Formular  frmAuditGeneral  (auch hier Prefixe benutzen!) eine Ufo-Steuerelement ein, das frmFindings anzeigt (einfach das frmFindings aus dem Navi-Bereich auf frmAuditGeneral ziehen).

Wegen den definierten Beziehungen werden die UFO-Eigenschaften "verknüpfen von/nach" automatisch gesetzt.

Titel: Re: Zwei Primärschlüsselfelder sinnvoll
Beitrag von: Newcomer2016 am April 15, 2016, 09:24:08
So, hab die Formulare erstellt. Wenn ich das richtig verstehe, laufen die Endlosformulare im Hintergrund, heißt, auf irgendwelche Designdinge kann verzichtet werden.

Das frmFindings (bzw sfmFindings) is ja kein Endlosformular, da muss ich ja größtenteils Eingaben vornehmen.

Nun ist noch die letzte Frage zu den Beziehungen von den tblStandort und tblAbteilung.

Ist es:
tblStandort.AutoWert (Zahl) zu tblAuditGeneral.Standort (kurzer Text)

Oder:
tblStandort.Standort (kurzer Text) zu   tblAuditGeneral.Standort(kurzer Text)

dito für Abteilungen.

(Kann ich statt der Idee mit dem Unterformular auch ein Navigationsformular nehmen, aus Gründen der Übersichtlichkeit)

Vielen, vielen Dank.
Titel: Re: Zwei Primärschlüsselfelder sinnvoll
Beitrag von: MzKlMu am April 15, 2016, 10:27:04
Hallo,
Zitatlaufen die Endlosformulare im Hintergrund, heißt, auf irgendwelche Designdinge kann verzichtet werden.
nein, die laufen nicht im Hintergrund, die müssen immer zu sehen sein. Und die Designdinge spielen selbstverständlich eine Rolle.
ZitatDas frmFindings (bzw sfmFindings) is ja kein Endlosformular, da muss ich ja größtenteils Eingaben vornehmen.
Ein Endlosformular ist da sicher zweckmäßiger und darin kannst Du auch Eingaben machen/ändern, das hat mit Endlos oder nicht nichts zu tun.

Was die Beziehungen betrifft, so ist beides falsch. Es sollte so sein:
tblStandort.StandortID (AutoWert) zu tblAuditGeneral.StandortID_F (Zahl, Longinteger)

Beziehungen erfolgen Immer über Primärschlüssel (in diesem Fall Autowert) zu einem extra Feld (LongInteger) als Fremdschlüssel (..._F).

Ein Navi Formular würde ich nicht verwenden.



Titel: Re: Zwei Primärschlüsselfelder sinnvoll
Beitrag von: Newcomer2016 am April 21, 2016, 10:32:35
Übrigens, danke. Ich hab echt lang gebraucht, aber es müsste geklappt haben.