Office: (Office 2016) Fragen beim Aufbau einer Datenbank

Ich mache damit mal hier weiter....


Zitat Pf@nne:

siehe auch vorheriger Beitrag

Zitat gpswanderer:

Wozu dann die dynamischen Datenfelder wenn alles einmalig und statisch ist? Für mich wäre ein weiterer Vorteil der dynamischen Nutzung von Datenfeldern, dass mann sich diese nach Bedarf zusammenstecken kann.

Beispiel für meinen Anwendungsfall:
Jeder Wandler hat allgemeine unveränderliche Felder wie z.B. [Seriennummer] und [Baujahr]. Jetzt gibt es aber auch spezifische allgemeine Informationen die einige Wandler haben, andere aber wieder nicht. Um dem Vorzubeugen müsste jetzt jeder Wandlerdatensatz alle spezifischen Felder bereithalten.
Das ist in deinem Beispiel ja schon möglich. In jedem uf können die entsprechen Eigenschaften hinzugefügt werden. Ich wollte das nur ein wenig komfortabler gestallten. Ich möchte z.B. Buttons die eine fertige Standardauswahl erstellen oder eben auch eine Listbox in der man die Auswahl treffen kann.

Ich mache mein Beispiel noch fertig und stelle es dann mal ein.

Gruß
Marco

 

Ich hab mal ein Beispiel dran gehängt.
Hier kann die dynamische Auswahl der Eigenschaften in jedem Datensatz individuell erfolgen. So werden nur die tatsächlich vorhandenen Eigenschaften auch gespeichert. Leere Platzhalter werden dann nicht dauerhaft gespeichert.

Ist das nicht auch ein weiterer Vorteil der dynamischen Verwaltung von Eigenschaften?
Oder habe ich mich da jetzt verrannt?

Edit:
Wie schaut es dann eigentlich mit der Größe der Tabellen aus?
Alle dynamischen Felddaten für eine Datengruppe würden dann ja in einer Tabelle gesammelt werden.
Diese hat zwar wenige Spalten aber später tausende von Zeilen.
Ab wann wird so etwas kritisch?

 

Hallo,
vorab mal noch folgende Frage:

Ist das unbegrenzt unterschiedlich, oder kann man die Wandler in Typen einteilen und jeder Typ hat dann immer die gleichen Eigenschaften ?

 

Tja, wie das mir den Herstellen so ist....
Grundsätzlich gibt es natürlich Normen, was die Hersteller aber nicht daran hindert mal was wegzulassen oder erweiterte Informationen mitzuliefern.

Unbegrenzt wäre jetzt übertrieben, ich würde es mal auf ca. 10 Varianten einschränken.
Hier sehe ich aber ganz klar den Vorteil der dynamischen Speicherung.
Wird was nicht benötigt, lässt man es weg, braucht man es nimmt man es mit rein und kommt etwas völlig neues hinzu erweitert man einfach die Liste.

Warum also nicht flexibel bleiben?

Gruß
Marco

 

In einer relationalen Datenbank gibt es keine Limits für Zeilenanzahlen. Das einzige Limit ist die Einhaltung der maximalen Dateigröße selber, bei einem Accessfile sind das 2 GB, bei "richtigen" Datenbanken dann erheblich mehr.

 

Hallo,
Deine Vorgehensweise hat einen entscheideneden Nachteil. Jedes mal wenn Du zu einem Wandler werte erfassen willst, muss die Zuordnung gemacht werden. Das halte ich für wenig praktikabel bzw. ist viel zu umständlich.
Ich würde auf jeden Fall eine Typisierung der Wandler vornehmen.
Dazu wird eine Tabelle für die Wandlertypen benötigt, mit einem Fremdschlüssel zum Hersteller.
Und dann werden in einer Zuordnungstabelle (n:m) die Eigenschaften dem Typ zugeordnet. Die gleiche Zuordnungstabelle braucht es dann noch mal nur mit dem Feld für den Eintrag.
Hat man einen Wandler legt man den Typ fest (an Hand des Herstellers). Mit einer Anfügeabfrage werden dann die für diesen Typ relevanten Eigenschaften in die Zuordnungstabelle übertragen.
Fehlt eine Eigenschaft kann man diese per Kombi nachtragen, ist eine zuviel wird der Datensatz gelöscht. Kommt ein neuer Wandler des gleichen Typs und Herstellers wird einfach die Anfügeabfrage erneut ausgeführt.
Das halte ich für flexibler als Deine Lösung, da die Eigenschaftszuordnung immer wieder gemacht werden muss.

Das Datenmodell aus meinem Vorschlag muss dann aber geändert werden. Ich mache das mal, braucht aber noch etwas.

 

Genau so soll es später werden.

Die einzelnen Wandlertypen werden spezifiziert.
Beim Anlegen des neuen Wandlertyps werden dann ebenfalls die Eigenschaften zugewiesen.
Die Form der Typisierung hatte ich auch schon mal skizziert.

 

Ich habe mal versucht die Struktur weiter zu entwickeln.
Dabei habe ich jetzt 3 Datengruppen (Primär, Kerne, Wicklungen) mit dynamischen Eigenschaften erstellt. Diese 3 Gruppen werden von einem Wandlertypen gehalten.

1 Wandlertyp (Bezeichnung des Herstellers) kann jeweils verschiedene Primär- / Kern- / und Wicklungstypen enthalten.
So wie bei einem Auto, ein Hersteller BMW / Typ 530d kann auch eine unterschiedliche Innenausstattung haben.
Ich habe jetzt einen Knoten im Kopf wie ich da am sinnvollsten darstelle.
Auch fällt es mir schwer zu erkennen wo in meiner Struktur die eigentliche Datenhaltung, also "n" Datensätze zu welchem übergeordneten IDFeld gehören.

Ich habe irgendwie das Pferd von hinten aufgezäumt ohne dabei den späteren Workflow zu berücksichtigen.
Der solle so sein:

Workflow "neuer Datensatz"

1. Wandlerhersteller wählen
2. Wandlertyp wählen
3. Primärkonfiguration wählen
   (automatische Konfiguration der dynamischen Felder)
4. Kernkonfiguration wählen
   (automatische Konfiguration der dynamischen Felder)
5. Wicklungskonfiguration wählen
   (automatische Konfiguration der dynamischen Felder)
6. Dateneingabe

 

Moin,

>> Ich habe irgendwie das Pferd von hinten aufgezäumt ohne dabei den späteren Workflow zu berücksichtigen.

mir scheint, Du packst hier Dinge ins Datenmodell, die dort nichts verloren haben. Ein Datenmodell kümmert sich aus guten Gründen nicht um den Workflow, sondern stellt Zusammenhänge zwischen Entitäten dar. Für die Modellierung von Eigenschaften zB ist es unerheblich, ob Eigenschaften immer vorhanden sind oder nur wahlweise; zur Entscheidung reicht ein Bit, ein Byte, ein Buchstabe, der bei Bedarf abgefragt wird.

>> Auch fällt es mir schwer zu erkennen wo in meiner Struktur die eigentliche Datenhaltung, also "n" Datensätze zu welchem übergeordneten IDFeld gehören.

Das gehört auch nicht in die Struktur, sondern in die Daten und wird zu gegebener Zeit durch Berichte dargestellt.

Im übrigen sollte durch die Wahl des Wandlertyps bereits ein Satz von Eigenschaften festgelegt sein.

Ganz nebenbei: Eine Entität hat Eigenschaften, die vorliegen müssen und solche, die vorliegen können; wo da die Dynamik herkommt, erschließt sich mir nicht.

 

Hallo,
@marco
Du hast es noch nicht verstanden. Du musst unterscheiden zwischen Zuordnung der Eigenschaften und der eigentlichen Datenerfassung. Die Zuordnung ist ein einmaliger Prozess. Die Zuordnung wird nur dann geändert, wenn sich was ändert.
Auch kommen alle Eigenschaften (egal ob Primär, Kerne, Wicklungen) in eine Tabelle (was ich ganz weit oben schon mal gesagt hatte). Zur Unterscheidung wird eine Tabellle angelegt für die 3 Datengruppen. Der PS dieser Tabelle kommt als FS in die Eigenschaftstabelle, sodass Du die Eigenschaften differenzieren kannst.
Das mit der Typisierung war von mir anders gedacht. Diese Typisierung hat mit echten Typen von Wandlern nichts zu tun. Bei der von mir angedachten Typisierung wird nur festgelegt welche Eigenschaften welcher Hersteller für welche Datengruppen hat. Auch als einmalige Aktion. Die Tabellenzahl wird dadurch deutlich verkleinert.
Bis hierher ich noch kein einziger Datenpunkt erfasst.

Die eigentliche Datenerfassung erfolgt in einer Tabelle mit exakt 3 (ggf. 4) Feldern.

- Primärschlüssel (Autowert)
- FS zur Eigenschaft
- Eintrag (Value)
- Ggf. Feld für eine Anmerkung

Willst Du einen neuen Wandler erfassen werden dessen Daten eingetragen
Da im Vorfeld über die oben beschriebenen Zuordnungstabellen (mit dem von mir erfunden Typ) festgelegt wurden welche Eigenschaft für welchen Hersteller und Datengruppe zu erfassen ist werden genau die FS dieser Eigenschaften per Anfügeabfrage in die Datenerfassungstabelle übertragen. Hier kann dann auch noch bei Bedarf eine fehlende Eigenschaft nachgetragen werden.

Das hört sich jetzt nach viel Tabellen, werden aber letztlich weniger sein, gegenüber Deinem Aufbau.

Wie von Ralf schon gesagt bleibt beim Aufbau des Datenmodells der spätere Workflow unbeachtet.
Der Workflow wird um das Datenmodell entwickelt nicht umgekehrt. Meistens wird der Workflow mit einem korrekten Datenmodell viel einfacher.

Ich hatte Dir ja gesagt, dass ich Dir das mal umbaue, aber das kann ich nicht aus dem Ärmel schütteln. Könnte morgen was werden.

 

Hallo,
ich tue mir unheimlich schwer, Deinen Aufbau zu überblicken.
Was ist für Dich der Unterschied zwischen den Eigenschaften und den dynProperties? Properties ist ja nur ein anderes Wort für Eigenschaften.

 

OK, da habe ich ja wohl noch nicht alles durchdrungen....*rolleyes.gif*

Im Grunde keiner. Damit wollte ich nur kenntlich machen, dass es sich um eine flexible (dynamische) Eigenschaft handelt. Die festen Eigenschaften hatte ich mit static kenntlich gemacht.

Soll ich die Zusammenhänge der Wandlertypen nochmal beschreiben?
Also welche Zusammenhänge zwischen der "echten" Wandlertypenbezeichnung und den anzulegenden Eigenschaften bestehen?

 

Hallo,
was lange währt ....

Anbei mal ein Vorschlag für ein Datenmodell.
Es gibt zunächst mal 3 Tabellen mit Static Feldern. Diese Felder sind im Formular dann ausschließlich Kombifelder die feste Werte (Z.B. die Norm, Klasse, Überstromkennziffer) aufnehmen. Die Tabellen dazu fehlen noch.
Dann gibt es die Tabelle tbl_Eigenschaften in der die flexiblen Eigenschaften mit Einheiten erfasst werden und Minimum Und Maximum.
Dann gibt es die Tabelle tab_Eigenschaften Zuordnung in der die Eigenschaften der Datengruppe (Kern, Wicklung, Primär) und dem Hersteller zugeordnet wird. Das ist eine einmalige Aufgabe für einen Wandler eines Herstellers.
Die eigentlichen Einträge für den Eigenschaftswert erfolgt in Tabelle tab_Eigenschaftseintrag.

Wenn ein neuer Wandler kommt, kennst Du ja den Hersteller. Dann werden per Anfügeabfrage alle Eigenschaften herstellerbezogen aus der Tabelle tab_EigenschaftenZuordnung in die Tabelle tab_Eigenschaftseintrag übertragen. Die Werte können dann eingetragen werden.

Zur Werteerfassung müsste man ein Hafo machen, in dem die Wandler angezeigt werden. mit einem Register mit 3 Seiten (Kern, Wicklung, Primär). Darin jeweils ein Ufo zur Anzeige der Static Felder (Kombis). Das ist jeweils je Wandler ein Datensatz.
In diesen Ufo dann je ein Endlosformular für die flexiblen Eigenschaften.

Ob das alles so klappt, wie ich mir das gerade denke, musst Du jetzt auch mal überdenken. Die Formulare müssen auch noch wohl überlegt sein.

 

Moin Klaus,

erstmal vielen Dank für deinen Entwurf!

Ich habe das eben nur überflogen, muss da aber nochmal genauer drauf schauen. Aktuell überfordert mich die Struktur noch.
Ich versuche da aber mal einzusteigen...

Gruß
Pf@nne