Hallo meine lieben Access Gurus :)
habe eine tabelle mit LieferantenWerkzeug dort sind alle Preise enthalten die ein Lieferant für das "Werkzeug" 2009/2010 hat.
Dazu habe ich eine Tabelle tblLiefAngebot wo ein Lieferant im Jahr 2009/2010 vom 1.5.2009 bis 1.6.2009 ein Angebot zu einein oder mehreren Werkzeugen haben kann.
Leider bin ich mir nicht sicher ob die "Werkzeuge" die selben Artikel Nummern haben oder diese beim Angebot sich ändern.
Wenn ich aber nun diese Angebote oder NormalPreise sozusagen mit meinen Bestellungen verlinke dann würden sich ja die Preise 2010/2011 auch auf die Bestellungen 2009/2010 auswirken!?
Soll man deshalb wieder eine neue Tabelle anlegen? Wenn Ja bitte wie?? Oder gibt es einen Trick der die alten Bestellungen sozusagen nicht mehr weiter aktualisiert?
Wäre auch natürlich gut irgendwann zu wissen um welche Prozente die Werkzeuge sicher verteuert haben.
Wäre Euch dankbar wenn Ihr eventuell mir eine Hilfe geben könntet wie Ihr vieleicht das selbe Problem gelöst habt.
Vielen Dank für Eure Hilfe!!!
Viele Grüße
Albert
Hallo,
in Anlehnung an meine Ausführungen in deiner anderen Anfrage (tblLiefAngebot enthält keine Infos zu Artikeln) ist generell zu überlegen, wie du das händlen willst.
Du könntest rein theoretisch ein Angebot deines Lieferanten zu einer Bestellung machen. Die Preisinformation des Lieferanten wird aber m.E. in deiner bestellung nicht zum Tragen kommen, hier bestellst du (entsprechende dem Angebot Nr. xy) xx Stück des Artikels abc.
Den Vergleich zwischen angebotenem Preis und tatsächlichem erhältst du frühestens bei Rechnungslegung durch den Lieferanten.
Zu dem existiert zwischen LiefAngebot, LiefWerkzeug und Bestellung KEINERLEI Bezug!
ZitatLeider bin ich mir nicht sicher ob die "Werkzeuge" die selben Artikel Nummern haben oder diese beim Angebot sich ändern
Na ja, nach welchen Kriterien bestellst du denn dann? Das klingt ja fast als würdest du eine Zange bestellen aber der Lieferant hat eine Säge angeboten .... ???
Um eine Preishistory zu führen baut man an eine Artikeltabelle eine 1:n verbundene Preistabelle mit Artikel_id und einem Datumsfeld, in dem das Datum der Gültigkeit ab gespeichert ist.
Der Preis ist dann solange aktuell, bis ein neuer Datensatz mit einem neuen Datum gespeichert wird.
Der Preisdatensatz wird dann über das Gültigkeitsdatum als Kriterium aus allen benötigten Abfragen den richtigen, zum Gültigkeitsdatum passenden Preis eines Artikels liefern.
Hallo Peter hab leider nicht gesehen das Du geschrieben hast!!
Ich habe danach noch etwas gebastelt und einige Beziehungen gemacht aber ich bin mir eben nicht sicher ob es so stimmt.
Wie auch immer ich meinte das ich keine Rechnung zur hand habe wo ich weis ob es ein Angebot war oder nicht deshalb weis ich nicht wie die Lieferanten es handhaben.
Und ich hatte bisher immer jemanden im Büro deshalb würd ich nun 2 Jahre Rechnungen kontrollieren müssen um rauszufinden ob die Artikel Nummern anders sind.
Ich werde es erst wieder bei neubestellungen und neuen Angeboten herausfinden.
Also ich komme immer noch etwas durcheinander wenn ich eine N:M Beziehung habe wo ich dann am besten eine neue Tabelle verlinke.
Soll diese an der Link tabelle oder nicht?
Ich denke das kann man auch nicht so beantworten oder? Aber ich finde hier einfach nicht immer die richtige Lösung.
Vergesse immer noch diese Optionen anzuklicken damit ich verständigt werde :)
Tut mir leid das musste ich noch nachholen.
Hallo,
ZitatAlso ich komme immer noch etwas durcheinander wenn ich eine N:M Beziehung habe wo ich dann am besten eine neue Tabelle verlinke.
Das ist ja ganz einfach!
Eine n:m Beziehung besteht IMMER zwischen 2 Tabellen, in denen mehrere Datensätze der einen Tabelle mit mehreren Datensätzen der anderen Tabelle in Beziehung stehen können.
Klassisches Beispiel Schauspieler und Filme - mehrere Schauspieler spielen in einem Film mit, ein Schauspieler wirkt in mehreren Filmen mit:
Um die Datenaufzeichung zu realisieren müsste für
jeden mitwirkenden Schauspieler
ein Datensatz in der Filmtabelle erstellt werden - natürlich mit allen Informationen zum Film nur die Schauspielernummer wäre anders.
Umgekehrt wäre der Fall dann so, dass gleichzeitig ein Schauspieler in
mehreren Filmen mitspielen kann, wodurch dann für jeden Film in dem der Schauspieler mitgespielt hat, ein Datensatz in der Schauspielertabelle eingetragen werden müsste - natürlich mit allen Informationen zum Schauspieler nur die Filmnummer wäre anders.
Somit ist eine solche Beziehung in 2x 1:n Beziehungen aufzulösen um eindeutige Aussagen zu erhalten und die Mehrfachspeicherung von Daten zu verhindern..
Zu dem Zweck wird eine 'Zwischentabelle' erzeugt, welche die Primärschlüssel
BEIDER Tabellen als Fremdschlüssel enthält.
Also:
Schauspieler_id_FK Film_id_FK
1 1
2 1
3 1
4 1
1 2
3 2
2 3
4 3
Die Schauspieler 1,2,3 und 4 wirken alle im Film 1 mit.
1 und 3 wirken auch im Film 2 mit und 3 und 4 hingegen auch im Film 3
Durch diese 'Auflösung' gelingt es, in den Tabellen Schauspieler und Film nun eindeutige (Unique) Datensätze zu speichern (Jeder Eintrag kommt genau 1x vor)
Um die Tabelle zu indizieren kann nun ein eindeutiger Index über BEIDE Felder gelegt werden - damit kann auch verhindert werden, dass ein Schauspieler mehrfach dem gleichen Film zugeordnet wird.
War das verständlich?
Peter na das verstehe ich eh,
tut mir leid ich hab mich vieleicht falsch ausgedrückt
Ich meine wenn von einer N:M Beziehung noch andere Beziehungen weitergehen.
Dann weis ich nicht ob ich sagen wir mal vom Schauspieler oder von der Link tabelle aus die Beziehung aufbauen muss.
Hallo,
ZitatIch meine wenn von einer N:M Beziehung noch andere Beziehungen weitergehen
...also in Abhängigkeit einer gespeicherten Kombination
z.B Schauspieler1 und Film1 zu einer Tabelle tblGagenzahlung ... ;D
dann benötigt man in der tblSchauspielerFilm einen Primärschlüssel so wie in jeder anderen Tabelle auch
beispielsweise SF_id als Autowert - und der fungiert dann als Fremdschlüssel in der Tabelle, die mit der Zwischentabelle in Beziehung stehen soll.
Mit angesprochener Gagenzahlung - um festzustellen ob Schauspieler für die Darbietungen einem bestimmten Film die Gage erhalten haben:
SF_id Schauspieler_id_FK Film_id_FK Gage_id SF_id_FK
1 1 1 1 1
2 2 1 2 5
3 3 1 3 8
4 4 1
5 1 2
6 3 2
7 2 3
8 4 3
So ginge aus der Information hervor, dass Schauspieler 1 für seine Darbietung im Film1 und im Film2 bezahlt wurde und Schauspieler 4 für den Film3 seine Kohle erhalten hat.
ZitatDann weis ich nicht ob ich sagen wir mal vom Schauspieler oder von der Link tabelle aus die Beziehung aufbauen muss
Das ist ja nicht vom Vorhandensein einer Zwischentabelle abhängig sondern davon welche Information du an eine andere Tabelle weitergeben musst.
Wenn es - um beim obigen Beispiel zu bleiben - darum geht, welcher Schauspieler auch beim Theater engagiert ist, ist eine Beziehung zwischen Tabelle Schauspieler und Tabelle Theater einzurichten (1:n)
Das berührt aber die oben gezeigte n:m - Geschichte gar nicht sondern stellt wiederum eine neue Beziehung dar.
Jetzt besser?
Ja wird schön langsam danke für Dein Bemühen!
Vieleicht hattest Du auch Zeit Dir meine ganze Struktur anzuschauen??
Würde gern wieder a bissl weiter kommen mit der Geschichte :)
Lg Albert
Hallo Albert,
ZitatVieleicht hattest Du auch Zeit Dir meine ganze Struktur anzuschauen??
mhmmm .... "Vergesse immer noch diese Optionen anzuklicken damit ich verständigt werde"
Na dann sieh mal da rein ...
http://www.access-o-mania.de/forum/index.php?topic=13869.msg78783#msg78783 (http://www.access-o-mania.de/forum/index.php?topic=13869.msg78783#msg78783)
Bis dann mal ...