Office: (Office 2003) Datenbank aufbauen Teil-1

Wofür soll das Feld "fiArtikel&Lieferant" in der Tabelle "tblArtikellieferanten" dienen?

Sascha hat es glaube ich schon einmal erwähnt: Wenn sich die Beanstandung nur auf Artikel beziehen kann, die von einem Lieferanten kommen, dann könntest du überlegen, ob du fiLieferant und fiArtikel die Beziehung später direkt auf den PK von tblArtikellieferanten setzt. Sollte es jedoch möglich sein, nur einen Lieferanten oder nur einen Artikel, oder einen Artikel und einen Lieferanten, die nicht in der Tabelle tblArtikellieferanten gemeinsam angeführt sind zu verwenden, dann würden 2 Beziehung (1x zu Artikel und 1x zu Lieferanten) passen.


etwas zur Beanstandungsmaßnahme:
Wenn ich den Namen der Tabelle richtig interpretieren, gibt es so eine Maßnahme nur in Verbindung mit einer Beanstandung. (anfangs bilde ich mir ein, waren das nur Maßnahmen)
Wenn so eine Beanstandungsmaßnahme fix mit einer Beanstandung verbunden ist, dann würde ich mir die Verknüpfungstabelle schenken. Einerseits wird das Verknüpfen einfacher und zweitens kannst du so vorgeben, dass ein Datensatz in der Tabelle tbl_Beanstandungsmaßnahmen nur existiert, wenn dazu eine Beanstandung vorhanden ist.
Außer: tblBeanstandungsdetails ist mehr als nur die Verknüpfungstabelle.

und:

=> das wäre dann sogar eine 1:1-Beziehung

Du bist doch schon die ganze Zeit dabei die Beziehungen zu definieren. *wink.gif*

Tipp: Bevor du die Beziehungen zw. den Tabellen in Access erstellt, lege zuerst in jeder Tabelle den PK fest.

Im Anhang noch ein Beispiel für einen PK mit 2 Feldern.
Und als Anregung für die tbl_artikelLieferanten-Tabellen: vielleicht willst du auch die Katalognummer o.ä. abspeichern. Weiters kann es nie schaden in einem Feld festzulegen, ob die Artikel-Lieferanten-Kombination noch gültigkeit hat (ob. z.B. diese Kombination in neuen Lieferungen noch vorkommen darf)
Ob du diese 2 Felder wie im Bild gezeigt einsetzt, musst du entscheiden - also nicht einfach übernehmen, wenn du sie nicht benötigst. *wink.gif*

 

Hallo Josef,

habe mal versucht PK-FK zuzuordnen, was meinst du richtig verstanden oder.
mit Artikellieferanten, bin ich noch am Überlegen. Im Grunde brauche ich das aber nicht unbedingt berücksichtigen, da der Artikel doch hinzugefügt werden muss in der Verwaltung? oder wie seht ihr das

mfg
Erich

 

Nabend Ihr Beiden!

Die Tabelle tbl_Artikellieferanten stellt sicher, das ein Artikel von mehrerern Lieferanten kommen kann. Der zusammengesetzte PK stellt dann sicher, das eine Kombination aus Artikel & Lieferant nur 1 x vorkommen kann.

Sollte ich was überlesen haben?

 

Hi Erich!

Ich befürchte Du warst in Deiner DB V01 mit den PK s zu spendabel! Hast Du noch ein Verständnis Problem mit den PK und FK? Dann frag einfach!*Smilie

 

Sorry.

Ich nochmal:

Jetzt habe ich Deine Frage verstanden. Das Feld ergibt überhaupt keinen Sinn, hatte mir das in der Muster Db V01 eben angeschaut.

 

Hallo Erich,

habe jetzt mal das Modell angeschaut und Dir ein Bild mit Hinweisen erstellt. Davon ausgehend, das pro Beanstandung mehrere Fehlertexte verwendet werden können, sollten wir mit einer zusätzlichen Tabelle arbeiten.

Wir haben:

tbl_Fehlertexte
FehlertextID
Fehlertext
fiFehlerKategorie

tbl_FehlerKategorien
FehlerKategorieID
FehlerKategorie

tbl_Beanstandungen
BeanstandungID
fiArtikel
fiLieferant
fiPerson

Wir brauchen:

Eine Tabelle, die uns erlaubt eine beliebige Anzahl von Fehlertexten zu einer Beanstandung zu erfassen.

tbl_BeanstandungFehlertexte
BeanstandungFehlertextID
fiFehlertext
fiBeandstandung

Allgemein: Mir ist klar, das die Entwicklung eines vernünftigen Datenmodells ziemlich viel Zeit kostet. Erst recht dann, wenn man dies nicht so richtig kann und noch so einiges dazu lernen will. Ich sage Dir aber, dass dies der wichtigste Part einer Datenbank ist. In Prinzip steht und fällt sie damit! Verstehe das Datenmodell als Fundament Deiner DB. Und wer baut schon gerne ein Haus auf wackeligem Fundament?

Ein Fehler im VBA Code lässt sich mit wenig Aufwand beheben. Ein Fehler im Datenmodell ist nur mit extrem großen Aufwand zu beheben. Insbesondere dann, wenn die DB fertig ist und sich in der Anwendung befindet.

Mit Access gelingen einen schnell "optische" Ergebnisse, die dazu verleiten sich NICHT ausreichend mit Datenmodellierung zu beschäftigen. Und nur mal so: Meine erste DB (mit 78 Tabellen!) darf ich jetzt neu Entwickeln, weil das Datenmodell "Schrott" ist und ich lerne jeden Tag was dazu! *Smilie (Insofern ich mich hier im MOF bewege)

Also: Ich bin erst am So wieder im MOF, weil Schwiegermutter-Alarm bei uns ist. Dir und Josef (und allen anderen Mitlesern) ein schönes WE!

 

Guten morgen ihr beiden,

Danke, für eure geduldige Unterstützung mit Rat und Tat!

ich muss mir das nun noch mal in Ruhe anschauen da es nun ja eine ganze Menge Informationen dazu gibt. Da nun Samstag ist und wir auf Hochzeit müssen, werde ich heute wohl erst mal abschalten. Morgen klinke ich mich wieder ein.

Ja so wirklich verstanden trotz der Erläuterungen zum Thema PK-FK habe ich das scheinbar noch nicht. Ich glaube aber das liegt daran wenn ich im Menü Indices den PK-Wert setze gibt es das Feld FK nicht.

und irgendwie meine ich das wir noch keine vernüftigen Attributs benannt haben, aber die können immer noch genannt werden? es soll ja nachher nicht nur Zahlen in der DB stehen.
mfg
Erich

 

Hallo @alle,

Sascha, habe die Tabelle hinzugefügt. Das Datenmodell angepasst und die Beziehungen definiert, das sieht mir aber noch nicht OK aus, nun frage ich die Profis wieder um Rat.

tbl_Beanstandung
tbl_BeanstandungsDetails sind nicht difeniert (habe ich einen Hänger)

die neue tbl_BeanstandungFehlertexte bin mir nicht ganz sicher.

Was glaubt ihr bekomme ich da noch überhaubt ein stabiles Fundament hin.

mfg
Erich *wink.gif* *Smilie

 

In der Tabelle tbl_Notizen hast du einen 2-Felder-PK eingerichtet, obwohl NotzenID bereits eindeutig ist (Autowert)

Öfter hast du auch "fiBeanstandung" verfehlt und den PK der Sub-Tabelle erwischt.
- tbl_BeanstandungFehlertexte
- tbl_BeanstandungDetails

Ich habe immer noch den Eindruck, dass du die Vorschläge aus diesem Thread einfach übernimmst, auch wenn du nicht genau weißt, ob sie überhaupt passen. Dadurch entstehen dann im Modell "Lücken".

z.B. Was ist mit tbl_BeanstandungFehlertexte / tbl_Fehlertexte
Wenn damit die Fehler der Beanstandung beschreiben werden sollen, ist dann die Fehlerklasse in der Beanstandungstabelle richtig? ... oder gehört die Fehlerklasse eher zum Fehler (also der Fehlerbeschreibung?) - oder vielleicht sogar noch eher zur Fehlerkategorie und die Fehlerklasse der Beanstandung ermittelt sich dann über die höchste Fehlerklasse der verknüpften Fehlerbeschreibungen (über Fehlerbeschreibung - Fehlertext - Fehlerkategorie könnte man z.B. auch zur Fehlerklasse kommen)
Ich weiß aber nicht, was du unter Fehlerklasse und Fehlerkategorie verstehst. Vielleicht hängen die auch überhaupt nicht zusammen und sind 2 unterschiedliche Kennungen. (z.B. Fehlerklasse: kritisch, ... und Fehlerkategorie: Bearbeitungsfehler, Materialfehler, Transport, ...)

Das wichtigste ist immer, dass du den Grund für die Beziehungen verstehst. Es bringt nichts, wenn du mit Unterstützung ein Modell aufbaust und dir der Grund für diese Struktur aber unklar ist. Dann wirst du das Modell nicht im FE nutzen können.
Leider kann ich dir bei dem Verstehen dieser Grundprinzipien nicht mehr weiterhelfen, da mir keine bessere Beschreibung mehr einfällt als die Beschreibungen, die in diesem Thread bereits gefallen sind.

mfg
Josef

 

Hi Erich, hi Josef.

Bevor wir nun hier weiter am Modell basteln und Erich scheinbar ein Gewisses Grundprinzip noch nicht versteht, möchte ich Erich fragen welcher Knoten so fest ist, dass er nicht platzen kann?*Smilie

Wir lassen Dein Modell mal außen vor. Vielmehr ist es wichtig, dass Du das Prinzip verstehst, weil dann der Knoten leichter platzen könnte. Kann es vielleicht sein, dass Du ein bißchen ungeduldigt bist und am liebsten jetzt schon am Gestalten der grafischen Oberfläche wärest? Wie schon häufiger erwähnt, die bringt die beste grafische Oberfläche nichts, wenn das Modell nicht stimmt.

Grundsätzlich brauchst Du Dir aber keine Gedanken machen und an Deiner Person zweifeln. Du darfst mir glauben (Josef wird s bestätigen), das viele Fehler die hier im MOF besprochen werden, häufig auch mit einem falschen Modell zusammen hängen.

Du versuchst Dich ja wenigsten damit auseinander zu setzen. Wichtig ist - wie Josef schon schreib -Du musst es auch verstehen ! Und wenn Du es nicht verstehst, dann frag nach. Frag, frag, frag.

Mal extrem formuliert: Lieber versuchen wir Dir 20 x den Sinn und Zweck eines PK zu erklären, als 50 Beiträge später festzustellen, dass Du den den Sinn und Zweck noch nicht GANZ verstanden hast.

Insofern Du die Geduld mitbringst und gewillt bist Dich damit auseinander zu setzen, sage ich: JA!

BTW: Jedes gute Access Buch geht am Anfang immer auf das Thema "relationale Datenbanken" ein. Erklärt die Modellierung und Normalformen. Das Thema scheint sehr trocken, ist aber unumgäglich. Hat Du schon einmal eines gelesen?

Bitte jetzt das alles nicht falsch verstehen. Wir helfen alle gerne, sonst wären wir hier nicht !*Smilie