Office: (Office 2016) Fragen beim Aufbau einer Datenbank

\@Klaus

ich meinte die Tatsache, dass zu einem Equipment = Wandler n Kerne und m Wicklungen gehören - kein Wunder, dass plötzlich und unerwartet die maximale Feldanzahl gesprengt wird. Bei SAP scheint das ERM unbekannt zu sein.

 

\@Marco
ich mache Dir mal einen Vorschlag. Wird aber ein paar Tage dauern.

 

Prima, danke dir!

Ich werde dann in der Zwischenzeit noch ein wenig mit ACCESS spielen.
Da kommen bestimmt noch genug Fragen auf....

Gruß
Marco

 

Moin Klaus,

als Anlage mal mein bisheriger "Testaufbau" mit und ohne die Anlagen/Abzweige.

Gruß und Dank!
Marco

weitere Hinweise aus dem anderen Beitrag:

 

Wenn der SAP-Export in die normalisierte Struktur importiert wird, dann müssten auch der Hersteller und der Wandlertyp in der Struktur normalisiert werden.

 

Hallo,
die Zusammenhänge zwischen Technischer Platz und Anlage ist mir noch nicht klar.
In früheren Beschreibungen hast Du je geschrieben, dass ein techn. Platz 10 Einträge hat (die Du aufdröseln willst).
Ist das dann eine Anlage ?
Also eine Anlage umfasst 10 techn. Plätze oder ist jeder techn. Platz eine Anlage?

 

Moin Klaus,

ich versuche mal die Zusammenhänge und Begrifflichkeiten zusammenzufassen. Das hätte ich sinnvoller Weise gleich zu Beginn machen sollen, leider war mir da noch nicht wirklich klar wo die Reise hingeht.

Also:
Es gibt an einem geographischen Standort "n" Anlagen (elektrische Schaltanlage) in "1" Anlage kann es "n" Abzweige (Kabel- und Freileitungsabgänge) geben.
In "1" Abzweig können "n" Wandler verbaut sein.

"1" Wandler ist von einem Typ.
Jeder Wandlertyp kann "n" Kerne und "n" Wicklungen haben.
Die Anzahl der Kerne und Wicklungen ist nicht fest an den Typ gebunden.
Wandlertyp 0815 kann z.B. 3 Kerne und 1 Wicklung haben oder aber auch 5 Kerne und 4 Wicklungen, je nach Bestellung.
Viele DatenWerte der Kerne bzw. Wicklungen können in tab_Listen als Auswahlfeld vorgegeben werden, andere Eingaben müssen aber zulässig sein.

Im SAP-Export sind viele Informationen in den Feldern [Techn# Platz] und [Bezeichnung] enthalten, diese Infos müssen aus dem String gesplittet werden.
Der [Techn# Platz] kann auch noch variieren, das habe ich aber schon aufgedröselt.
Wie schon angesprochen macht es dann Sinn die SAP-Daten beim importieren direkt in die weitestgehend normalisierte DB zu übernehmen.
Die SAP-Daten würden dann bei einem Import nur temporär geöffnet werden.

Gruß und schönes WE
Marco

 

Hab noch am Entwurf geschraubt.....

 

Hallo,
ich bin da immer noch am Brüten.
Ich denke das linke Bild ist OK. Die Zusammenhänge kannst auch nur Du wissen.
Das rechte Bild für die Werte ist so nicht OK.

Noch Fragen:
- Ist es wichtig, dass die eingebenen Werte eines Wandlers auf Sinnhaftigkeit geprüft werden ?
- Die einzutragenden Werte, sind das Messwerte oder Spezifikationen ?

 

Moin Klaus,

Klares JEIN, grundsätzlich sollten alle Daten frei änderbar sein.
Eine konsistente Eingabe ist aber grundsätzlich nicht zwingend erforderlich.
Bei einigen Feldern macht es aber Sinn Auswahlmöglichkeiten aus Listen zur Verfügung zu stellen.

Hierbei handelt es sich ausschließlich um Daten des Betriebsmittels "Wandler".

 

Hallo,
im Anhang findest Du mal einen ersten Entwurf.
Es sind jetzt nur mal die Daten der Kerne enthalten. Für die Wicklungen muss das analog aufgebaut werden.
Die Daten der Kerneigenschaften und Wicklungseigenschaften würde man auf 2 Registern anordnen.
Die anderen Tabellen habe ich jetzt mal außen vor gelassen.

Versuche das mal zu verstehen. Das lässt sich alles noch komfortabler machen.
So können später die ganzen Eigenschaften automatisch angefügt werden, sodass nur die Werte einzutragen sind.
Wenn Dir das Konzept passt, sehen wir dann weiter.

 

Moin Klaus,

erstmal vielen Dank für deinen Entwurf!

Ich habe mir den Aufbau mal angesehen und möchte mein Verständnis dazu einmal wiedergeben um zu sehen ob ich es richtig verstanden habe.

1. In tab_Kerne werden die einzelnen Kerne eines Wandlers eindeutig mit [KernID] gespeichert.
2. Jeder Kern hat feste Eigenschaften (Überlastbarkeit, Verwendung, ect.) die auch Teils über zugehörige Listen (Klasse, Norm, ect.) ausgewählt werden können.
3. Zusätzlich hat jeder Kern aber auch noch flexible Eigenschaften jede dieser flexiblen Eigenschaften ist in tab_EigenschZuKern hinterlegt.
4. Bei Neuanlage eines [KernID] können beliebig viele flexible Eigenschaften genutzt werden.

Aus meiner Sicht liegt hier der große Vorteil in der flexiblen Handhabung der Eigenschaften. Eine flexible Eigenschaft kann später ohne Änderung der bestehenden Datensätze hinzugefügt werden. Die neue Eigenschaft wir dann nur in den zukünftigen Datensätzen genutzt und angezeigt.

Habe ich das soweit richtig verstanden?

Hierzu habe ich noch ein paar Fragen:

1. Was ist, wenn sie eine feste Eigenschaft ändert? Hier hätte man doch dann auch Rückwirkungen auf alle bestehenden Datensätze. Das könnte man nur umgehen, wenn diese Eigenschaften ebenfalls Bestandteil der flexiblen Eigenschaften werden würden.
2. Wie aufwändig ist es die flexiblen Eigenschaften "fest zu verankern". Momentan gibt es ja nur die flexible Eigenschaften die auch explizit angelegt werden.
3. Wie implementiert man eine Funktion die aufpasst, dass keine flexible Eigenschaft doppelt angelegt wird?
4. Kann man die Lesbarkeit der Struktur erhöhen? Für einen ungeübten Verwender sind die Zusammenhänge der Datenfelder recht abstrakt.
5. Ist diese Vorgehensweise bei einer "guten" Datenbank ein Muss oder eher ein Kann?

Mein Eindruck ist, dass die Flexibilisierung zu lasten der Übersichtlichkeit der Datenstruktur geht. Hier ist ein geübter Umgang Voraussetzung.
Auch ist mir nicht so ganz klar wann man auf die flexiblen Eigenschaften umsteigen sollte. In meinem Fall ist das Betriebsmittel "Wandler" recht starr.
Hier ist mit keiner großen Änderung der Datenfelder zu rechnen.
Macht dann Sinn die Eigenschaften flexibel zu gestalten?
Es fällt mir momentan schwer dies zu entscheiden.


Gruß
Marco

 

Hallo,
ich kann Dir erst heute Abend ausführlich antworten.

 

Hallo,
die Verständnispunkte 1-4 hast Du zu 100% richtig verstanden.

Zu Deinen weiteren Fragen:

Zu 1. Sollte sich eine feste Eigenschaft ändern, würde man diese ebenfalls in die entsprechende Liste aufnehmen. Man sollte auch bedenken, dass man einer festen Eigenschaft eine andere Beziechnung geben will mit der Vorgabe auch in bestehende Datensätze den anderen Namen anzuzeigen. Dann ist es besonders einfach, weil einfach der Text geändert wird, fertig.

Zu 2.
Die flex. Eigenschaften würde man in der fertigen Datenbank ohnehin automatisch anlegen (geht unsichtbar im Hintergrund mit einer Anfügeabfrage) wenn man einen neuen Kern anlegt. Damit sind alle flex. Eigenschaften sofort im Ufo sichtbar und die Werte können eingetragen werden. Das bekäme der User gar nicht mit.

Zu 3.
Da bedarf es keiner Funktion. Über fs_Kern und fs_Kerneigenschaft einen zusammengesetzten eindeutigen Index legen und Doppelungen werden unüberlistbar verhindert. Kann mit einer eigenen aussagefähigen Meldung verbunden werden.

Zu 4.
Der ungeübte Verwender hat mit der Struktur nichts zu tun und kriegt diese auch nicht zu Gesicht. Die Frage stellt sich also nicht. Eine Benutzerführung muss natürlich dazu gemacht werden. Da ist mein einfaches Beispiel noch weit davon entfernt.

Zu 5.
Für mich ist das eher ein Muss, gerade bei so vielen Datenfeldern. Es muss auch bedacht werden, dass Access nur 255 Spalten je Tabelle zulässt. Sind wir zwar noch davon entfernt, aber wer weis ?

Da sind wir wieder bei der bereits erwähnten Benutzerführung, was eine Aufgabe des Entwicklers ist.
Ich bin auch der Auffassung, dass die Übersichtlichkeit mit meinem Vorschlag (im Endausbau) besser ist.

Ich hatte ja gefragt, ob Du eine Validierung der Einträge haben willst, was Du mit einem klaren Jein *grins beantwortet hast. Ich habe diese Validierung daher mal eingeplant. Für jede flex. Eigenschaft gibt es 2 Felder für die Grenzwerte. Diese Grenzwerte werden im Ufo auch angezeigt, was die Prüfung sehr einfach macht.
Wenn Du das mit starren Feldnamen machen willst, braucht Du in der Tabelle für jede starre Eigenschaft noch 2 zusätzliche Felder für die Grenzwerte und noch ein Feld für die Einheit. Wenn es also 20 starr angelegte Eigenschaften gibt brauchst 80 Felder in der Tabelle (jeweils Eigenschaft, Grenzwertunten, Grenzwertoben, Einheit).
Man könnte auch Gültigkeitsregeln anlegen, aber das müsste dann im Entwurf gemacht werden und Gültigkeitsregeln gehen nicht immer.
Bei den festen Eigenschafte die per Kombi aus den list Tabelle gewählt werden, ist die Validierung kein Thema, weil ja nur gültige Werte gewählt werden können.

Eine gute Datenbank sollte auch sachliche Fehler verhindern.
Wenn der User z.B. die Einheit frei eintragen kann, könnte er bei der Leistung als Einheit A eintragen.

Die Entscheidung liegt bei Dir, wie weit Du es treiben willst.
Meine Meinung kennst Du.

Bis dann.

PS:
Ich habe jetzt etwas schnell geschrieben, sind wahrscheinlich einige Tippfehler etc. enthalten.

 

Moin Klaus,

Das beruhigt mich, damit besteht noch Hoffnung....*tongue.gif*

Zitat:
Mein Eindruck ist, dass die Flexibilisierung zu lasten der Übersichtlichkeit der Datenstruktur geht. Hier ist ein geübter Umgang Voraussetzung.

Damit meine ich eigentlich mich als unerfahrenen Entwickler.....*biggrin.gif*

Würde man das nicht gleich in der Formatierung des jeweiligen Feldes machen?
Also einfach ein " A" hinten dran hängen?

Ich bin im Grunde überzeugt, dass diese Variante des Datenbankaufbaus sinnvoll ist. Wie ist eigentlich der Fachausdruck für diese Art des Aufbaus?

Ich sehe noch weitere Vorteile. Ich würde jetzt meinen Entwurf dahingehend ändern, dass ich alle Felder die zu 100% vorkommen (z.B. Baujahr, Seriennummer, etc.) in den festen Teil übernehme. Alle allgemeinen Daten die es bei einigen Wandlen gibt, bei anderen aber wiederum nicht werde ich in den flexiblen Teil der "WandlerAllgDaten" überführen.
Bei den einzelnen Kerndaten werden alle Felder in den flexiblen Teil übernommen. Hier gebt es ja verschiedene Kerntypen mit unterschiedlichen Feldern. Damit könnte man sich dann für die einzelnen Kerntypen eine Art template anlegen.
Somit gibt es dann für jede Datengruppe feste und flexible Eigenschaften.
Das würde dann den Wandler selber (WandlerAllgDaten) als auch die Kerne und die Wicklungen betreffen. Den Grundaufbau hierzu hast du ja bereits skizziert.

Der Vorteil wäre dann ja, dass nicht pauschal alle Felder als Datenspeicher vorgehalten werden. So werden auch nur die Daten gespeichert die tatsächlich relevant sind. Ich denke, dass das auch ein wesentlicher Aspekt für die Art von DB-Struktur ist.

Macht das so Sinn?

Ein noch viel wichtigerer Vorteil ist die Tatsache, dass du mit an Bord bist....

*mrcool

Schönes Restwochenende