Beziehungen von verknüpften Access-Tabellen

[LucaE]

Es handelt sich um folgende Thematik:

Mein Thema der Bachelorarbeit beschäftigt sich mit automatisierten Kaufteilpreisanfragen bei Lieferanten. Dazu wollte ich eine Access-Datenbank erstellen, die in das firmeninterne Kalkulationstool integriert wird.
Pro Lieferant soll eine Tabelle in Access vorliegen, die alle nötigen Kaufteilinfos beinhaltet. Die Access-Tabellen sollen mit Excel-Sheets verknüpft werden, die an den Lieferant geschickt werden können, um Preise anzupassen. Nach der Rückmeldung der Listen werden diese auf dem Pfad abgelegt, mit der die jeweiligen Access-Tabellen verknüpft sind.


Das Problem ist folgendes:

Verknüpfte Tabellen können in Access (soweit ich weiß) nicht mit einem Primärschlüssel versehen werden. Das bedeutet ich kann unter den Access-Tabellen keine sinnvollen Beziehungen herstellen. Diese sind jedoch nötig, um die Teilnummern der Lieferanten den internen Bausteinnummern der Teile für die Kalkulationsmasterbibliothek zuzuordnen. Denn es könnte zufällig vorkommen, dass verschiedene Lieferanten eine gleiche Teilenummer besitzen, die ein komplett verschiedenes Bauteil beschreibt.
Haben jemand vielleicht einen Vorschlag für mich, wie ich das Problem lösen könnte?
Alternativ habe ich an einen Import der Excel-Daten gedacht (hier funktioniert das vergeben von Primary Keys). Nur ist hier das Problem, dass die Aktualisierung der Excel-Daten nicht zur Aktualisierung der Access-Tabellen führt. Vielleicht könnte man hierzu eine Makro schreiben, die per Knopfdruck sich aktuelle Daten aus der Excel zieht. Weiß jemand ob so etwas möglich ist?

Über eine Rückmeldung hierüber würde ich mich sehr freuen.

LG Luca

 

[akretschmer]

Pro Lieferant soll eine Tabelle in Access vorliegen,

Falsches Design, das wird für Deine Bachelorarbeit massiv Punkte kosten ...

 

[LucaE]

Bitte genaue Erläuterung. Um die nötige Sicherheit zu gewährleisten zu können muss ich pro Lieferant eine Tabelle zur Verfügung stellen. Die jeweilige verlinkte Excel wird an diesen gesendet um Preise zu aktualisieren.

 

[akretschmer]

Das skaliert halt nicht, wenn Du je Lieferant eine eigene Tabelle anlegst mußt Du z.B. bei einer Abfrage über alle Lieferanten diese jeweils anpassen. Ist halt Murks.

 

[LucaE]

Hättest Du eine Idee zur besseren Gestaltung?

 

[akretschmer]

Hättest Du eine Idee zur besseren Gestaltung?

nun - halt das Gegenteil. Vielleicht solltest Du Dich mal etwas mit Datenbank-Normalisierung beschäftigen.

 

[ukulele]

1.) Also in so einem Projekt wäre die erste Frage die ich stellen würde:
Wie bekommst du vom Lieferanten seine Daten? Ich kann ja nicht einfach meinen Großhändler anrufen und sagen schickt mir mal eure Daten, aber bitte in Access und mit meinem Aufbau. Gibt es Standard-Format? Gibt es Schnittstellen? Gibt es eine API? Das klingt für mich erstmal nach Wunschdenken. Wahrscheinlicher ist eher der Händler bietet einer erlesenen Gruppe von Großkunden eine API. Jeder Händler hat seine eigene API die völlig unterschiedlich arbeiten. Normalerweise schreibt der Händler Angebote als PDF, Gültigkeit X Tage. Preise ändern sich sowieso mehrmals täglich.

2.) Access ist so 1998... Willst du wirklich eine Anwendung, die eventuell Daten mit verschiedenen Formaten importieren soll, die eventuell mit APIs kommunizieren muss, mit Access und Marcos bauen? Du brauchst ein echtes DBMS und ein vernünftiges Frontend. Du kannst dich auf das Backend konzentrieren und Schnittstellen oder Importroutinen bauen aber bitte nicht mit Access oder Office-abhängigen Macros, das knallt bei jeder Gelegenheit.

3.) Du solltest deine Datenbank normalisiert halten. Eventuell kann man für jede Schnittstelle eine eigene Tabelle führen wenn z.B. ganz unterschiedliche Attribute vorliegen aber das Ziel sollte sein eine Tabelle, nennen wir sie "Angebote", mit Spalten für Lieferant, Datum des Angebots, Produktnr des Lieferanten, eigene Produktnr, etc. und dort importierst du deine beim Händler abgefragten Artikel.

 

[dabadepdu]

Dazu wollte ich eine Access-Datenbank erstellen

Schlechte Idee, wurde schon gesagt. Selbst wenn innerhalb der Firma Office genutzt wird.

Pro Lieferant soll eine Tabelle in Access vorliegen

Auch nicht so toll. Pro Lieferant musst Du vielleicht ein Format kennen, ein Interface oder sowas, auch schon angeführt. Ich kann mir vorstellen, dass es branchenspezifische Standards gibt, dann wäre es nicht pro Lieferant, sondern pro Schnittstelle. Dazu würde man ein eigenes Modell definieren und beim Import mappen.
In dem eigenen Modell (Normalisierung: Alle Händlerdaten in gemeinsamen Tabellen) kannst Du dann nach Herzenslust vergleichen und musst nicht für all die Formate dutzende Abfragen in dutzend Varianten bauen.

Die Access-Tabellen sollen mit Excel-Sheets verknüpft werden, die an den Lieferant geschickt werden können, um Preise anzupassen

Excel eignet sich nicht besonders als Datenaustauschformat. Viel Formatierungs Chaos, wenig Sicherheit, allein schon was versehentliches Editieren, Verschieben, Sortieren angeht. Zugriffsrechte usw. auch schlecht regulierbar.

Verknüpfte Tabellen können in Access (soweit ich weiß) nicht mit einem Primärschlüssel versehen werden

Verknüpfte Tabellen übernehmen den Primärschlüssel der remote definiert ist, wenn er definiert ist.

Das bedeutet ich kann unter den Access-Tabellen keine sinnvollen Beziehungen herstellen.

Das ist falsch. In SQL (auch in Access oder in den Access spezifischen Abfragen) kannst Du jedes Feld mit jedem anderen oder mit Ausdrücken verknüpfen. Falls PK und FK Informationen fehlen, hast Du nur keine Garantien zur Konsistenz der Daten.

Insgesamt ist Access auch nicht unbedingt geeignet, weil es sich relativ wenig an SQL Standards hält.
Da es "nur eine Bachelorarbeit" ist, könnte man sagen, egal, wird ja eh nie eingesetzt (in der Firma). Aber in einer Bachelorarbeit geht es ja darum, dass Du Deine Fähigkeiten zeigst. Die würde ich nicht unbedingt mit Access und Excel Makros demonstrieren. Wenn Du beruflich in dieser Firma Fuß fassen willst oder gern mit MS Produkten und für MS arbeitest, ist es vielleicht was anderes. Dann vielleicht lieber ein MS SQL Serverprodukt in Deien Lösung einbeziehen statt MS Access.

 

[LucaE]

Danke dabadepdu für Deine Antwort,

die Situation ist wie folgt: Ich habe eben nur 2 Monate Zeit die Arbeit zu verfassen. Dabei ist es kaum möglich und auch ebenso wenig erwünscht (von der Firmenseite aus) eine neue Softwarelösung zu etablieren. Deshalb das beharren auf MS Access. Wie schon erwähnt ist es nur eine Bachelorarbeit und das zeitlich in einem sehr kurzen Rahmen.

Es wird nicht verlangt von mir das komplette Angebotsanfragesystem umzukrempeln, sondern lediglich ein Konzept zur Effizienzsteigerung vorzustellen. Ich bin im Bereich Wirtschaftsingenieurwesen tätig. Somit ist meine SQL bzw. Datenbankerfahrung sehr beschränkt.

Zum Prozess:
Die Anfragen von Teilen sollen per Mail (MS Outlook) beim Kunden fortgeführt werden. Es könnten Formulare in Access vorgefertigt werden die per Button an Lieferanten gesendet werden. Die Idee, dass jeder betrachtete Lieferant eine eigene Tabelle besitzt hat den Hintergrund, dass die verknüpften Excel-Sheets mit in den Mail-Anhang gepackt werden. In der Excel sind alle relevanten Teile des jeweiligen Lieferanten drin und der dazugehörige Preis. Dieser soll vom Lieferanten aktualisiert werden.

Die rückgemeldete Excel vom Lieferanten wird auf dem definierten Pfad abgelegt und aktualisiert die verknüpfte Access-Tabelle (so der Plan).

In Access soll die Struktur so aussehen, dass eine Übersichtsliste mit allen Lieferanten und eine Übersicht mit allen Komponenten gibt. Darunter sollen Beziehungen so hergestellt werden, dass internen Bezeichnungen für Teile, die dazugehörigen Bezeichnungen der Lieferanten zugeordnet werden, da es möglich ist, dass mehrere Lieferanten die selbe interne Komponente beschreiben.

Meine Problematik ergibt sich dadurch, dass ich nicht weiß wie ich verknüpften Tabellen in Access PKs zuordnen kann. Oder eben, dass die importierten Daten von Excel bei dessen Aktualisierung eben nicht die Access-Tabelle bearbeiten (weil nicht verknüpft).

Ich möchte wissen ob mir dazu jemand behilflich seinen kann. Dass Access nicht das gelbe vom Ei ist weiß ich. Dennoch glaube ich das es im Rahmen dieser Bachelorarbeit zu realisieren ist.

 

[ukulele]

Deine Access DB müsste so aussehen:
Artikel <1 --- n> Artikel_zu_LieferantenartikelA <n --- 1> LieferantenartikelA
Dabei ist LieferantenartikelA die externe Tabelle die dein Lieferant einstellt. Es muss hier einen eindeutigen Bezeichner geben der sich nicht ändert, eine Artikelnummer des Lieferanten oder EAN oder so. In der Artikel-Tabelle müssen alle Artikel von dir gepflegt werden, kommt etwas neues hinzu muss ein neuer Eintrag angelegt werden. Die Zwischentabelle bildet ab welcher Lieferantenartikel zu welchem deiner Artikel gehört. Fremdschlüssel ist einer Seits deine Artikelnr., anderer Seits der eindeutige Bezeichner bei deinem Lieferanten.

Für weitere Lieferanten brauchst du auch weitere Zuordnungstabellen, eine pro Lieferant. Nur dann lassen sich auch saubere Fremdschlüssel setzen allerdings auch nur zwischen Artikel und Artikel_zu_LieferantenartikelA bis Z. Auf die LieferantenartikelA bis Z Tabelle hast du ja keinen Einfluss. Wenn der Lieferant einen Artikel nicht mehr führt verschwindet er vermutlich einfach aus seiner Tabelle, da kann man natürlich keine Referenz drauf setzen.

Einträge in der Zwischentabelle müssen ebenfalls angelegt werden wenn auf beiden Seiten neue Einträge für einen Artikel vorhanden sind, im Zweifelsfall manuell. Man kann sich hier mit Scripten die die Arbeit vereinfachen, z.B. wenn du oder ein anderer Lieferant in seiner Artikeltabelle eine EAN definiert hat kannst du draus die Zuordnung für neue Lieferantenartikel mit der selben EAN ableiten.

Eine Liste mit Lieferanten lässt sich eigentlich nicht sauber verknüpfen, da jeder Lieferant eigene Tabellen hat. Kann man natürlich zusätzlich anlegen und manuell führen.

Mit jedem neuen Lieferanten müssen neue Tabellen erstellt und neue Fremdschlüssel angelegt werden. Wenn es Scripte gibt wie mein Beispiel müssen die angepasst werden.

 

[dabadepdu]

Deshalb das beharren auf MS Access.

sondern lediglich ein Konzept zur Effizienzsteigerung vorzustellen.

Tja, ich weiß, dass es oft solche Ansätze gibt. Eine kleine Verbesserung für ein fragwürdiges System. Meistens die 37. "Verbesserung" ohne grundlegende Verbesserungen. Mir ist vollkommen klar, dass solche Maßnahmen ab und an sein müssen bzw. niemand Zeit, Geld und Nerven aufbringt, anders vorzugehen.
Trotzdem nochmal der Hinweis. Die oben genannte Problematik wird idR nicht besser, in dem man einen günstigen Studenten dran setzt, die Risse im Asphalt zu vergießen.. Gerade mit einem theoretischen Ansatz und den Worten "Konzept zur Effizienzsteigerung" könnte man anders vorgehen und einen Studenten beispielhaft wirklich neue Konzepte probieren lassen.
Diese wären vielleicht sowas wie eine strategische "Modularisierung". Also überhaupt Raum zu schaffen, einzelne Komponenten stärker zu kapseln und austauschbarer zu machen. Wie gesagt, wenn schon Access und Verknüpfungen, dann eben nur Access als Frontend, hinten dran eine richtige SQL DB. Oder: Welche Alternative gibt es zu Datenaustausch per Spreadsheet Files?

dass ich nicht weiß wie ich verknüpften Tabellen in Access PKs zuordnen kann

Das Problem verstehe ich nicht. Ich habe Dir gesagt, wie das funktioniert. (Von allein)
Wenn Dein Problem ist, wie das bei verknüpften Excelsheets zu erreichen ist, dann sieht es anders aus. Es geht Prinzip bedingt nicht. Excel kennt keine PK. Soweit ich mich erinnere, bietet Access die Möglichkeit, bei fehlenden PK (eine Reihe von) Spalten zu definieren, die logisch gesehen einen PK bilden. Das ist eine Krücke und ich weiß nicht, wie das mit aktuellen PK ist bzw. mit dem aktuellen Integrationsniveau zwischen Access und Excel.
In meinen Augen ist das Gebastel. Ich habe neulich mal aus Spaß eine JSON in Excel / Access eingelesen. Für mich wirkt es intransparent, was die "Toolchain" zwischen den beiden Systemen / Formaten da macht.
Wenn Du von "Verknüpfung" und "Aktualisieren" sprichst, ist mir außerdem nicht klar, welche Fälle das einschließt. Aktualisierung bestehender Daten (z.B. neuer Preis, einfach) oder auch entfernen von Artikeln, Hinzufügen, Zusammenführen, Splitten. Gerade die letzteren dürften als Workflow in der Warenwelt sicher existieren und sind etwas komplexer als ein Pupspreisupdate.
Und: Ich setze Access nicht mehr ein, irgendeine alte Version fliegt hier auf einem Rechner rum, das ist alles. Hilfestellung kann ich tatsächlich eher konzeptionell bieten. Ich habe mehrere massive Funktionsbrüche in Access erlebt und würde da nicht mehr drauf setzen. Und damit ich nicht nur rummeckere: Es gibt für mich ein nettes Feature von Access, das ist die Möglichkeit recht einfach über verknüpfte Tabellen heterogene Abfragen zu machen. Das war mal selten, ist aber heute bei nahezu jedem SQL Server auch in irgendeiner Form zu haben.