Office: (Office 2016) Beziehungen zu dynamsichen Untertabellen erstellen

Hallo,

ich habe eine Datenbank in der Produkte, Dokumente, etc. gespeichert werden. Produkte, sowie Daten besitzen einheitlich Grundinformationen. Jedoch hat fast jeder Eintrag in der Datenbank einige Unterschiede, die ich gerne in eine individuelle Untertabelle einpflegen möchte. Diese Untertabellen sind dynamisch in ihrer Größe. Ich möchte gerne, dass die Grundinformationen mit der individuellen Unterdatenbank über eine Beziehung verbunden ist. Dies hat glaube ich den Vorteil, dass wenn ich später auf die Daten zugreifen möchte via Formulare, alle Informationen zu einer bestimmten ID erhalte.

Da ich jedoch sehr viele Untertabellen habe, möchte ich die Beziehung nicht manuell mit der Grundlagentabelle verknüpfen. Ist es möglich dies zu automatisieren? Gerne möchte ich dies in Access umsetzten. Gibt es Jemanden der vielleicht eine Solche Datenbank aufgebaut hat, die ich ggf. verwenden und Anpassen könnte? Leider habe ich im Internet noch nicht das passende gefunden.

Grüße Tim

:)

 

Hallo,
das sind 1:1 Beziehungen, die Du einmalig manuell im Beziehungsfenster anlegen solltest. Mit eingestellter referentieller Integrität.
Das ist eine einmalige Aktion, welchen Vorteil versprichst Du Dir von einer Automatisierung?

In welcher Größe, Datensatzzahl ?

 

Moin,
könntest du vielleicht ein zwei konkrete Beispiele nennen? "Sehr viele Untertabellen" klingt mir irgendwie nach einem möglicherweise besser anders zu realisierenden Modell (1:n, m:n).
maike

 

Hallo Tim,

den Begriff "Untertabelle" kenn ich in dem Zusammehang nicht - nur mal so - und das Daten in einer Tabelle stehen ist auch klar.

Wenn die Produkte unterschiedliche Merkmale haben, also nicht einfach nur z.B. sich die Farbe ändert, lagert man die Merkmale in einer Merkmalstabelle aus.
Über eine (1:n) Beziehung kann dann ein Produkt mehrere Merkmale haben und jedes Merkmal hat dann einen spezifischen Wert.
Können mehrere Produkte das gleiche Merkmal aber mit unterschiedlichen Werten haben, teilt man das nochmal auf. Das gibt es zusätzlich noch eine Zuordnungstabelle zwischen Produkt und dem Merkmal. Dann steht der spezifische Produkt-Merkmal Wert in dieser Zuordnungstabelle, weilche dann über eine (m:n) Beziehung eingebunden wird. auf der einen Seite die Produkte und auf der anderen Seite die Merkmale.
Dein Datenmodell sollte nur von den Daten ausgehen und die Überlegungen bezüglich der Darstellung in Formularen spielen zunächst keine Rolle.

Gruß Ulrich

 

Moin und herzlich willkommen!

Deine Bescheibung riecht sehr nach der Datenbank "Ebbs" (schwäbisch für Etwas): Eine führende Tabelle mit einem derart abstrakten Wesen, dass sie sich nicht benamsen lässt - vielleicht Objekt, Kopf, Element, am besten "Ebbs". Alle anderen Entitäten zeichen sich dadurch aus, dass sie "ebbs" mit dem Fährungselement zu tun haben, wobei genau genommen nur feststeht, dass sie gedanklich unterhalb vom Ebbs eingeordnet werden können. Irgendwie.

Mein Vorschlag: Datenmodell aufbauen nach den Regeln der Kunst (sprich aus realen oder abstrakten Gegenständen oder Ereignissen des Interesses Entitäten ableiten) und dann nochmal draufschauen. Vermutlich löst sich Dein ursprüngliches Vorhaben dann in Wohlgefallen auf.

 

Hallo Tim,
Unabhängig von den (wahrscheinlich gerechtfertigten) Einwänden der anderen, -
über das Datenbankobjekt (CurrentDb) erhältst du Zugriff auf die Auflistung
.Relations. Diese stellt dir Eigenschaften und Methoden für die Bearbeitung
der Beziehungen zur Verfügung.
gruss ekkehard

 

Idee ist es, dass ich alle was in meinem Haushalt ist in die Datenbank einpflegen kann und ggf. Verlinkungen zueinander hat, basierend auf einer eindeutigen ID. Zum Beispiel der Eintrag „Katze“, diese hat Eigenschaften wie z.B. Alter, Größe etc.). Jetzt möchte ich jedoch auch noch den Impfpass der Katze als Eintrag in die Datenbank einpflegen, dieser hat eine Verlinkung zur Katze, soll jedoch auch eine eigene ID bekommen.

Zudem möchte ich noch den Eintrag Musikbox einpflegen auch mit einer eigenen ID hat. Die Musikbox hat wiederum eine Verlinkung zu dem Stromkabel. Das wiederum eine eigene ID aufweist. Da ich jedoch vorher noch nicht weiß was ich in paar Jahren kaufe oder ob die Katze Nachwuchs bekommt und wie viele Eigenschaften dieser Neue Eintrag dann hat, wollte ich das dynamisch machen.

 

Kann es sein, dass das auf eine Art Stückliste hinausläuft?

 

hmm ja, also eine Stückliste in den jeder Eintrag unterschiedliche Eigenschaften, wobei die Anzahl der Eigenschaften unterschiedlich ist und diese untereinander Verlinkungen haben.

 

Hallo Tim,

also dafür brauch man keine Datenbank, sondern eher ein Karteikastensystem.
Siehe mal:
CUEcards 2005 - mhst.net

Gruß Ulrich

 

Klingt für mich ein wenig nach Data Vault.

https://blogs.sas.com/content/sasdac...nmodellierung/

 

Hallo Mike,
habs mir kurz angesehen.
Grundsätzlich kann ich in dem Konzept aber nichts entnehmen, was nicht durch nachträgliche 1:1 oder n:m Beziehungen abgedeckt wird.
Den großen Wurf kann ich darin noch nicht erkennen.

Natürlich hat die Hash Organisation gewisse Vorteile und natürlich auch Nachteile gegenüber einem gruppierten Index, aber das sind nur noch Detailfragen.

Da würde mich deine Sicht interessieren und vor allem ob du da praktische Erfahrung hast.

Zum Thema und der genannten Beispiele habe ich eher das Gefühl, das dem TS das Grundverständnis bezüglich Datenorganisation fehlt.

 

Beziehungen kann man doch ganz simpel via SQL Anweisung (Constraint), oder bei Access Tabellen mittels DAO Relation Objekt erstellen.
Ich mach das beim SQL Server immer per SQL.
Zu bedenken ist natürlich, dass es bei Access bei allem relativ enge Limitierungen gibt und ich daher im entsprechenden Business Umfeld von Access -
außer bei simplen Stand-Alone Projekten abraten würde.

 

Hallo,

das erinnert mich irgendwie an eine zurückliegende Aufgabenstellung: "Ich will zukünftig Gruppen von Leuten zusammenstellen können, auch nach Kriterien, von denen ich jetzt noch nicht weiß, dass ich sie mal brauche". Meine Lösung war letztlich, eine Tabelle mit sogenannten Attributen anzulegen, die nutzerseitig beliebig um Attribute erweitert werden können. Dazu gibt es dann sogenannte Eigenschaften in einer weiteren Tabelle, auch die ist nutzerseitig erweiterbar. Für ein Attribut wie "Rentner" gäbe es nur die Ausprägungen "ja" und "nein", für ein Attribut "Sprachkenntnis" gäbe es natürlich deutlich mehr mögliche Ausprägungen. Wenn also eine Person Deutsch, Englich und Spanisch spricht, ordne ich ihr das Attribut "Sprachkenntnis" dreimal zu, jeweils mit einer anderen Sprache als Ausprägung. Zwischen den beiden Tabellen werden dann mögliche Verbindungen definiert, und nur diese Verbindungen können zugeordnet werden, damit dann eine Kombination aus "Rentner" und "Spanisch" nicht zugeordnet werden kann.
Somit kann man z. B. einer Katze ein Attribut "Rasse" zuordnen, das bei einem Haushaltsgerät nicht vorkäme. Das Gerät könnte aber ein Attribut "Stromverbrauch" haben. Beide könnten allerdings ein Attribut "Farbe" haben.
Das ist natürlich mit Pflegeaufwand und einem gewissen Anspruch an das intellektuelle Niveau der User verbunden, wobei das erste meiner Erfahrung nach leichter zu erfüllen ist als das zweite. Aber es ist "flexibel bis zur Konzeptionslosigkeit".

Gruß
Fred

 

Moin,

für Datenmodelle zieht i.A. der Nutzer eine natürliche Grenze: Sie umfassen alle Infos, die dem Anwender von Nutzen sein können.

Als Heimwerker habe ich Dutzende Schachteln mit Nägeln und Schrauben unterschiedlichster Form und Größe, teils voll, teils halbleer. Was sollte mich dazu bewegen, sowas in einer DB abzulegen? Soll mir eine Beziehung zeigen, dass die alle in der Werkstatt rumstehen? Weiß ich auch so. Und wenn in einer Schachtel der Grund zu sehen ist, dann schließe ich messerscharf, dass ich eine neue brauche. Eine Bestandsführung mit automatischem Druck des Bestellzettels bei Unterschreitung der Mindestanzahl lohnt sich eher nicht.