Office: (Office 2016) Verbindung mehrerer „Namenstabellen“

Hallo liebe Office- und besonders Access-Gemeinde,

Gleich vorweg bitte ich den wenig aussagekräftigen Titel zu entschuldigen. Ich befasse mich mit Access erst seit einer Woche und mir fehlen noch die Worte, um meine Frage überhaupt knapp auf den Punkt zu bringen *Smilie

Ich benutze Access 2016 und arbeite an einer Datenbank, mit der sich Daten über Transaktionen erfassen und auswerten lassen. Im dritten Anlauf habe ich nun auch verstanden, wie man es in Access(typischerweise) am besten angeht:

Ich habe eine Tabelle „Transaktionen“ (primary key = AutoNumber) und mehrere Tabellen mit Charakteristika von Transaktionen, so zum Beispiel eine Tabelle „Bedingungen“ (primary key = AutoNumber). Beide finden zusammen in einer Link Table, für das Beispiel Bedingungen die Tabelle „Transaktionsbedingungen“ (primary key, foreign key „Transaktionen“ und foreign key „Bedingungen“ = AutoNumber). Die Link Table enthält daneben ggf. weitere Informationen, die spezifisch für die verlinkte Transaktion und die konkrete Bedingung sind.

So weit, so klar *Smilie

Ein bestimmtes Charakteristikum einer Transaktion macht mir jedoch Schwierigkeiten und das sind die Parteien.

Grundsätzlich ist es klar und in den diversen Beispielen im Internet ja auch für „Customer“-Tabellen gut beschrieben - letztlich läuft es genau so, wie oben beschrieben. Auch eine query, um die Felder „Vorname“ und „Nachname“ zu verketten, so dass z.B. „Nachname, Vorname“ dabei herauskommt, ist mir schon gelungen.
Allerdings (und das Problem muss ja auch in anderen Datenbanken durchaus vorkommen): Nicht jede Partei einer Transaktion oder Kunde eines Unternehmens ist zwingend eine individuelle Person. Es könnte auch ein anderes Unternehmen sein. Ein Unternehmen hätte als Namensbestandteile aber „Firma“ und „Rechtsform“, also zum Beispiel „Deutsche Bank“ und „AG“ (Rechtsform, also „AG“, „GmbH“ etc würde man wahrscheinlich wiederum noch einmal in eine Tabelle auslagern können...) und beide Bestandteile würden auch unterschiedlich - nämlich ohne Komma - verkettet. In der gesamten Datenbank werden an mehreren Stellen solche Rechtssubjekte vorkommen und je nach Zusammenhang können dies entweder nur natürliche Personen, nur Unternehmen, nur bestimmte Teilmengen der Unternehmen (z.B. Banken) oder Kombinationen davon sein.

Grundsätzlich erscheint es mir am sinnvollsten, für natürliche Personen und Unternehmen erstmal jeweils einzelne Tabellen anzulegen, sagen wir tblNatürlichePersonen und tblUnternehmen. So kann ich die aber mit dem jeweiligen Feld für den foreign key „ParteiID“ in der tblTransaktionen nicht verknüpfen, denn das wäre nicht eindeutig. Naheliegende Lösung wäre daher, tblUnternehmen und tblNatürlichePersonen in einer weiteren Tabelle zusammenzuführen, tblPartei, die dann ihren eigenen primary key = AutoNumber hat, sowie Felder für die foreign keys von tblUnternehmen und tblNatürlichePersonen. Einer von beiden foreign keys bleibt dann jeweils leer. So könnten die Relationen funktionieren.

Aber dann habe ich zwei Folgeprobleme, bei denen mir die Lösung nicht einfällt:

Wenn meine Datenbank sich entwickelt, muss ich sicherstellen, dass für jeden neuen Eintrag in tblUnternehmen oder tblNatürlichePersonen ein entsprechender neuer Eintrag in tblPartei angelegt wird. Wahrscheinlich funktioniert das mit einer append query (habe ich bisher nicht benutzt, nur gesehen als Auswahl gesehen...). Später soll natürlich nur über Forms mit der Datenbank interagiert werden, jetzt im Entwurfsstadium schreibe ich aber durchaus schon mal schnell ein paar Werte in eine Tabelle. Kann ich eine query auch bei einem direkten Eintrag in eine Tabelle ausführen oder irgendwie anders sicherstellen, dass tblPartei automatisch aktualisiert wird?

Wie formuliere ich nachher das SQL statement für die Combobox, aus der ich nachher - sofern es sich um eine Parteirolle handelt, die sowohl eine natürliche Person als auch ein Unternehmen ausfüllen kann - eine Partei auswähle? Dieses müsste ja abhängig davon, welcher foreign key in tblPartei vorhanden ist, entweder auf tblUnternehmen oder tblNatürlichePerson „durchgreifen“, dort die korrekten zwei Felder nehmen und dann - wiederum abhängig davon, worum es sich handelt - entweder mit Komma oder ohne verketten.

Abschließend: Gibt es vielleicht eine viel einfachere Lösung, die ich nicht sehe?

Für jeden Hinweis bin ich dankbar *Smilie Ich brauche auch keine fertige Lösung, wenn jemand einen Artikel oder Beitrag kennt, der das Problem behandelt, reicht mir das schon. Ich scheitere im Moment bereits am Suchen, weil ich mit meinen Suchbegriffen nur Beiträge zu den allgemeinen Konzepten (Verketten für Namen, Nutzung von IDs und Relationships etc.) finde, nicht zu diesem „Spezialproblem“.

Danke + viele Grüße
ich.pdf

:)

 

Hallo,
erst mal:

Primärschlüssel und Fremdschlüssel müssen gleich laufen. Daher darf der Fremdschlüssel niemals ein Autowert sein.

Ich würde natürliche Personen und Unternehmen in einer Tabelle führen.
Die Verkettung der Namensteile dann in ein Modul auslagern und je nach nach Art verketten.


Zeige mal ein Bild des Beziehungsfensters.

 

Da habe ich mich bereits unklar ausgedrückt *wink.gif* Die foreign keys in tblTransaktionsbedingungen sind natürlich „Number“, wollte damit nur zum Ausdruck bringen, dass diese Beziehung auf einem AutoNumber primary key in tblBedingungen basiert, nicht etwa auf einem Short Text primary key.

Ein Bild liefere ich alsbald nach *Smilie Danke!

 

Benutze bitte deutsche Ausdrücke, wenn Du die Abfragen und Tabellen beschreibst, das hilft hier besser weiter als das Mischmasch DEU/ENGL.
Statt (primary key = AutoNumber) ist Primärschlüssel = AutoWert besser verständlich. Fremdschlüssel statt foreign key. Verknüpfte Tabelle statt Link Table....)
Was jedoch bisher vollkommen fehlt, ist eine Beschreibung, was Du mit der Datenbankanwendung überhaupt erreichen bzw. organisieren willst.
Da ist von Parteien die Rede, von Unternehmen und von Transaktionen - nur erschließt sich damit für uns noch nicht, was Du erreichen willst. Um Hilfestellung beim Aufbau eines Datenmodelles zu geben bedarf es einer verständlichen Beschreibung.

 

Würde ich auf keinen Fall machen.
Die Bezeichnung der juristischen Person kommt einfach in das Feld Nachname.
Da gibt es absolut keinen Grund dafür zwei Tabellen zu führen.
Du machst dir damit in der Regel eine Unmenge an zusätzlichem Aufwand.

Was man natürlich überlegen kann:
Ich hab manchmal eine eigene 1:1 Tabelle geführt um spezielle Infos zu speichern, die nur für einen geringen Teil der Adressen gelten.
Die kann man aber genauso in einer Tabelle führen.

 

Ich verwende Access leider auf Englisch und die Tutorials, die ich mir bislang angesehen habe, sind ebenfalls auf Englisch. Daher sind mir die deutschen Begriffe nicht unbedingt geläufig, aber ich versuch's.

Es geht darum, mit der Datenbank Transaktionen zu erfassen, empirisch auszuwerten und Transaktionen mit bestimmten Charakteristika später schnell aufzufinden - man könnte sagen eine Präzedenzfall-Datenbank.

Ich hatte auch schon mal überlegt, lediglich eine Tabelle "Rechtssubjekte" zu führen, die dann zwei Felder hat "Name Teil 1" und "Name Teil 2" und vielleicht "Typ" (Natürliche Person oder Unternehmen). Dann hätte ich aber zumindest immer noch das Problem mit der Verkettung, da die beiden Namensbestandteile bei Unternehmen anders verkettet würden als bei natürlichen Personen.

 

Daraus kann ich nicht ableiten, was wirklich passiert. Eine Transaktion liegt z.B. auch schon vor, wenn ich ein Paket mit DHL von A nach B versende.
Als Charakteristika käme wohl DHL als Transporteur in Frage. Aber das ist dennoch noch kein Präzedenzfall. - Sorry, aus Deiner Beschreibung ist nicht zu erkennen, wofür die Datenbank nun wirklich gut sein soll. Das musst Du an Hand eines Beispieles näher erklären.
Wegen der engl. Version von ACCESS habe ich natürlich vollstes Verständnis da Du als ACCESS-Neuling ja noch nicht lange genug mit der deutschen Version zu tun hattest.

 

Und was könnte da das Problem sein?
Als angehender Programmierer, darf man sich auch mal an simple Logik ranwagen.

 

Da hast du vollkommen recht, das war nicht hinreichend erklärt, sorry *Smilie

Also, zum Hintergrund. Bei den Transaktionen, die ich erfassen möchte, handelt es sich um öffentliche Angebote zum Erwerb von Aktien börsennotierter Unternehmen nach dem WpÜG. Eine Transaktion lässt sich vereinfacht so zerlegen:

Zu einem bestimmten Zeitpunkt erklärt ein Bieter öffentlich, dass er Aktien einer Zielgesellschaft zu einem bestimmten Preis erwerben will.

In Wirklichkeit ist der ganze Prozess sehr viel komplexer und wird von der BaFin überwacht - es ist daher sehr interessant, Angebote der Vergangenheit zu erfassen um schnell herausfinden zu können, welche von zahlreichen denkbaren Konstellationen schon einmal von der BaFin akzeptiert wurden, welche Marktstandards sich für bestimmte Situationen etabliert haben etc.

Daher ist es notwendig, den Prozess "öffentliches Angebot" in seine einzelnen, durchaus von einander abhängigen, Charakteristika zu zerlegen.

Der Satz von eben noch einmal:

Zu einem bestimmten Zeitpunkt (genaugenommen gibt es mehrere relevante Zeitpunkte - Veröffentlichung der Absicht, Veröffentlichung der Angebotsunterlage, Dauer der Annahmefrist...)
erklärt ein Bieter öffentlich, (genaugenommen können es auch mehrere Bieter sein - oder mehrere wirtschaftliche Bieter, die über ein gemeinsames Investmentvehikel, das als Bieter agiert, das Angebot abgeben; oder eine Kombination davon, hinzu kommen ggf. Co-Investoren)
dass er Aktien (möglich sind Stammaktien oder Stamm- und Vorzugsaktien)
einer Zielgesellschaft (in Frage kommen alle börsennotierten Gesellschaften, mithin Aktiengesellschaft, Kommanditgesellschaft auf Aktien, Societas Europaea)
zu einem bestimmten Preis (es kann sich um eine Bargegenleistung oder aber um zum Tausch angebotene Aktien einer anderen börsennotierten Gesellschaft handeln - theoretisch auch mehrerer anderer Gesellschaften, wobei das bislang praktisch meines Wissens nach nicht vorgekommen sein dürfte; auch hier spielt die Aktiengattung (Stamm- oder Vorzugsaktie) wieder eine Rolle, zudem müssen alle Gegenleistungselemente nach bestimmten gesetzlichen Vorschriften bewertet werden bzw. einer Mindestpreisanforderung genügen)
erwerben will.

Es ist also ein komplexes Thema und es gibt zahlreiche weitere Merkmale, die man berücksichtigen kann *wink.gif* Daher ist meine Herangehensweise bislang die, Informationen, Voraussetzungen und Charakteristika in möglichst kleine, möglichst gut miteinander zu kombinierende Bausteine einzuteilen und dabei redundante Informationen soweit es geht zu vermeiden - soweit ich das mit der Normalisierung bislang verstanden hatte, ist das jedenfalls mal eine gute Faustregel, um eine hohe Normalform zu erreichen.

Also habe ich das, was ich - es mag da einen Fachbegriff für geben - Ressourcen-Tabellen nenne: Eine Tabelle, die nur mögliche Aktiengattungen enthält, eine die nur alle denkbaren Bewertungsmaßstäbe enthält etc. Eine (oder eben zwei) dieser Ressourcen-Tabellen sollen Namen von natürlichen Personen und Namen von Unternehmen enthalten. Der gemeinsame Oberbegriff für Personen und Unternehmen wäre wohl "Rechtssubjekte", also Träger von Rechten Pflichten. Jetzt können solche Rechtssubjekte an unterschiedlicher Stelle relevant werden. Eine Zielgesellschaft kann logischerweise nur ein Unternehmen sein, ein Bieter oder wirtschaftlicher Bieter kann ebenso gut eine natürliche Person sein. Ein Unternehmen kann einmal Bieter und ein anderes Mal Zielgesellschaft sein, ein drittes Mal ist es vielleicht ein bisheriger Großaktionär der Zielgesellschaft. Dabei ist der "zweite Namensbestandteil" eines Unternehmens, die Rechtsform, durchaus eine Information, die ich in eine weitere Tabelle auslagern könnte, denn es gibt nur beschränkt viele Rechtsformen und sie wiederholen sich entsprechend häufig.

Du siehst, ich habe mir nicht gerade den einfachsten Anwendungsfall für meine erste Datenbank ausgesucht und ich bringe - außer eines gemessen am Durchschnitt relativ großen "Anwenderwissens" von Office Produkten - kaum Programmierkenntnisse mit. Ich bin aber ein ganz guter Autodidakt und das Thema interessiert mich. Da ich nicht unbeschränkt Zeit in Experimente stecken kann, bin ich aber gerade bei den Fragestellungen, bei denen ich mir gut vorstellen kann, dass sie anderer Stelle schon mal relevant geworden sind (-> "wie erfasse ich Personen und Unternehmen als zwei ungleichartige Kundengruppen am Besten?"), sehr daran interessiert, den Weg zu erfahren, der sich zur Lösung eines Problems vielleicht schon etabliert hat.

Zurück zur Datenbank: Ich habe nachher eine Tabelle "Transaktionen", die wahrscheinlich nicht viel mehr enthält als ihren Primärschlüssel, die relevanten Kalenderdaten und eine ganze Reihe von Fremdschlüsseln, die auf verknüpfte Tabellen verweisen (Gegenleistung, Bewertung, Bedingungen etc.), die wiederum Fremdschlüssel auf die rechtlichen und tatsächlichen Bausteine enthalten (Vorschriften, Bedingungstypen, Aktiengattungen, Namen). Auf Anwenderebene soll man nachher in einem Formular arbeiten, dass einem alle Informationen, vermutlich in Tabs organisiert, darstellt. Für sämtliche verknüpften Tabellen gibt es Unterformulare (=Subforms?), da sich so nach meiner bisherigen Kenntnis variierende Zahlen von Charakteristika (es kann einen Bieter geben oder zwei, es kann keine Bedingungen geben oder aber zahlreiche etc.) am Besten darstellen lassen.

Das Problem mit den Namen muss ich aber relativ bald lösen, denn solche Angebote haben selbst ja keine Namen, sondern werden vom Anwender identifiziert als "Angebot von X auf Aktien der Y AG am ZZ.ZZ.ZZZZ". Damit ich also bald zu einem einigermaßen tauglichen Entwurf komme, sollte ich die Namen schon einmal korrekt abbilden können, so dass ich einen bzw. mehrere Testdatensätze schreiben kann. Mit allem weiteren kann ich dann im Einzelnen experimentieren, schließlich kann ich alle benötigten weiteren Ressourcen und Verknüpften Tabellen einfach in die bestehende Struktur "einhängen".

Deshalb würde es mich interessieren, ob das "Namensproblem" schon einmal aufgetaucht ist. Bei der Eintabellenlösung von markusxy würde mich stören, dass ich ungleichartige Information in demselben Feld unterbringe, zum Beispiel "Nachname" und "Rechtsform". Umgehen ließe sich das mit mehreren Feldern. Eine Eintabellenlösung könnte also so aussehen:

ID -> AutoWert
Subjektstyp -> Fremdschlüssel einer Tabelle, die die Einträge "natürliche Person" und "Unternehmen" enthält
Vorname -> Text
Nachname -> Text
Firma -> Text
Rechtsform -> Fremdschlüssel einer Tabelle, die Einträge für jede Rechtsform enthält, also "AG", "GmbH" etc.

Zwangsläufig bleiben bei dieser Tabelle immer zwei von sechs Feldern leer, weshalb ich ursprünglich dachte, eine Tabelle für jeden Subjektstyp wäre sinnvoller (und sie erscheint mir immer noch "ordentlicher", ohne dass ich das konkret an etwas festmachen könnte...). Und es bleibt das Problem mit der Verkettung.

Vielen Dank - ich bin ja selber ein großer Fan der sokratischen Methode, dennoch wäre eine (klitze-)kleine Hilfestellung ganz großartig gewesen *wink.gif* Zum Beispiel so:

"Es ist möglich, in das SQL Statement, mit dem du eine Verkettung machst, eine IF-Abfrage einzubauen, schau mal hier - den Code müsste man dann entsprechend abwandeln."

In meiner Eintabellenlösung oben müsste ich den Subjektstyp im IF-Teil abfragen (sagen wir ich frage nach natürlicher Person) und dann die Verkettung [Nachname] & ", " & [Vorname] auslösen, und da es nur einen anderen Subjektstyp gibt im ELSE-Teil die Verkettung [Firma] & " " & [Rechtsform] - wobei das Feld Rechtsform in dieser Tabelle nur einen Fremdschlüssel enthält, daher müsste ich an dieser Stelle auf die entsprechende Ressourcen-Tabelle "durchgreifen" und mir den zu verkettenden String von dort holen.

Wenn das geht, heißt das. Und wenn es nicht eine elegantere Lösung dafür gibt. Ich hab' ja keine Ahnung und bin auch kein angehender Programmierer, deswegen bin ich hier und frag' *Smilie

Beste Grüße
ich.pdf

 

Das sollte einen nicht wirklich belasten. Für Eingabezwecke könnte man die Tabelle in zwei Abfragen/Unterformulare zerlegen, die dann pro Typ die relevanten Felder zeigen.
Vorteil ist aber: Du hättest alle Einzelbieter (und potentielle Zielgesellschaften) sofort in einer Tabelle.

Die Verkettung wird erst für Darstellung nach außen interessant und für die wenigen Felder problemfrei als Abfragelösung lösbar über
- IIF()
- Leerzeichen in kombiniertem Feld vermeiden
- gezielter Einsatz von Nz (könnte bei leerem Feld den Inhalt eines oder mehrerer anderer Felder im Datensatz liefern)

Ggf. kann man auch eine VBA-Funktion einsetzen, die die Feldinhalte als Argumente entgegennimmt und den zusammengesetzten Ausdruck als Rückgabewert an die Abfrage zurückliefert. Innerhalb der Funktion kann man die Zusammensetzen-Logik etwas übersichtlicher gestalten.