Access-o-Mania

Access-Forum (Deutsch/German) => Access-Hilfe => Thema gestartet von: MrB am Oktober 17, 2024, 10:47:58

Titel: Datenbank Alternativen und Anzahl verknüpfen und darstellen
Beitrag von: MrB am Oktober 17, 2024, 10:47:58
Hallo
ich arbeite schon seit einiger Zeit an einer Datenbank, die zu liefernde Teile beinhaltet (von Schraube über Drehbank bis Bett, alles mögliche).
Über diese Datenbank werden Gebäude mit Räumen ausgestattet in denen sich Untergruppen finden, die auch für verschiedene Einsätze mehr oder weniger werden können, oder Alternativen enthalten.
Als Beispiel ein Klassenraumgebäude:
Das Gebäude enthält max 28 Klassenräume in 2 Stockwerken.
Falls weniger gebraucht werden, kann auch ein Stockwerk weggelassen werden, sodas nur noch 14 möglich sind.
Es werden auch Räume anders Ausgestattet zB für IT.
In der Ausstattung der Räume gibt es unterschiedliche Möglichkeiten der Bestuhlung (Schreibtisch mit 2 Stühlen oder Bank mit festem Tisch).
Diese Dinge können von Projekt zu Projekt unterschiedlich sein und in der Planungsphase mehrfach verändert werden.
Zusätzlich kann es sein, das ein Projekt in mehreren Phasen abläuft und nicht alles gleichzeitig Gebaut wird, sodas eine zusätzliche Aufteilung in Phasen nötig wird.
Also muss ich flexibel sein, welche Gebäude ich in welche Phase nehme, oder ob ich die überhaupt brauche und in welcher Anzahl + Ausführung.
Gleiches gilt für die Räume und Untergruppen in den Räumen.
Die Datenbank ist jetzt in Tabellen und Verbindungstabellen aufgeteilt in denen die einzelnen Daten hinterlegt sind.
Beziehungen habe ich angehängt.

Wie kann ich in Anzahl der Gebäude, der Räume, Untergruppen die pro Phase ausgestattet werden und zusätzlich alternative Untergruppen oder Räume definieren, ohne die Verbindungstabellen völlig ausufernd zu gestalten?
Zusätzlich füge ich ein Bild an, das die Zusammenhänge etwas zu erklären versucht.

Screenshot 2024-10-17 103507.png
Screenshot 2024-10-17 104258.png


Titel: Re: Datenbank Alternativen und Anzahl verknüpfen und darstellen
Beitrag von: Bitsqueezer am Oktober 17, 2024, 17:33:47
Hallo,

also was mir spontan hier auffällt (keinen Anspruch auf Vollständigkeit):

Soviel erst mal dazu. Mehr kann man anhand der Infos nicht sagen. Da müßtest Du schon mehr Details verraten.

Gruß

Christian
Titel: Re: Datenbank Alternativen und Anzahl verknüpfen und darstellen
Beitrag von: MrB am Oktober 18, 2024, 10:33:13
Hallo und danke für deine Antwort, ich versuche alle nach bestem Wissen zu beantworten
1. gewachsene Struktur leider, sollte ich vielleicht nochmal angehen, auch den Rest zu beseitigen
2. zur besseren Sortierung, ob das nötig ist weiss ich nicht, kam von einem Kollegen
Screenshot 2024-10-18 095748.png
3. Die Phasen werden sich von Projekt zu Projekt unterscheiden, alles was dort drunter ist muss flexibel sein, um Dinge hinzuzufügen oder wegzunehmen. In der Planungsphase muss der Inhalt jederzeit umplanbar sein, wegen Kostenanpassungen
4. gebe ich dir recht, war super unflexibel
Zitat(das hoffentlich per Unique Index so eingestellt ist, daß die gleiche Phase nur einmal dem gleichen Projekt zugeordnet werden kann
das zB fehlt mir, mit deinem Hinweis denke ich kann ich das finden
5.
ZitatEin Gebäude, sofern es nicht Teil der Bauplanung ist, hat bereits Räume und Stockwerke, was weitestgehend unveränderlich ist.
da wir das sehr frei Planen können (grüne Wiese) steht hier auch die Bauplanung nicht vollkommen fest, in anderen Fällen müssen wir Gebäudeinhalte an Gegebenheiten anpassen und die Räume können ihre Widmung ändern (zB vom Klassenraum zu IT Klasse)
6. ein Raum kann in mehreren Gebäuden vorkommen und auch in der Planung von einem Gebäude in ein anderes wechseln. Raum zu Phase war auch meine Überlegung, ich muss aber auch das Gebäude festlegen. Hatte schon überlegt eine Tabelle zu erstellen in der jedem Gebäude alle in ihm möglichen Räume zugeordnet sind, was aber auch keine Lösung brachte.
7. Phase 1,2,3 sind Tickfelder, über die wir bisher die Phasen zugeordnet haben, ist nur eine Krücke
8. Ein Teil kann nicht nur einem Raum zugeordnet werden, zB ein Schreibtisch steht in einem Klassenraum oder auch in Büros
9. sind bereits erstellt, SubContainer sind Teilegruppen die in mehreren Räumen vorkommen können, oder auch nur Zusammenfassungen, um die Tabelle für den Raum kleinzuhalten. Räume können auch mehrfach verwendet werden, daher müssen die auch in m:n zugeordnet sein
10. in der Größe der Gebäude, es gehen zB in ein Klassenraumgebäude max 28 Klassen, die aber auch IT Räume sein können(26 Klassen, 2 IT Räume) und auch die Anzahl der Stockwerke kann variieren, es steht dort noch kein Gebäude, also kann man immer noch alles anpassen und je nach Projekt kann es sein, das nur 1Stöckig gebaut werden kann/darf.

Ich hoffe die Infos sind besser, ich sehe viel Arbeit auf mich zukommen :)


Titel: Re: Datenbank Alternativen und Anzahl verknüpfen und darstellen
Beitrag von: Bitsqueezer am Oktober 18, 2024, 21:27:53
Hallo,

ich sehe da auch noch viel Designbedarf.. :)
Die Sortierung erfolgt alphabetisch, so sollte man auch die Namen gestalten, um Dinge schnell wiederfinden zu können (davon ab, daß man natürlich im Navi-Fenster die Filterung benutzen kann, aber das ist mir persönlich zu umständlich).

Also zum Beispiel:
tblBestellungen
tblBestellungenDetails

Beide stehen dann untereinander und man weiß sofort, was zusammengehört. Namen dürfen dabei auch namentlich inkorrekt sein, um die Reihenfolge zu gewährleisten. Also nicht "Bestelldetails" sondern "BestellungenDetails", um den Namen der Haupttabelle zu wiederholen und dann die Untertabelle darauf zu beziehen. So ist die Untertabelle immer unterhalb der Haupttabelle - das ist meine Methode.
Zahlen als Sortierung ist völlig unpraktisch, denn unter welcher Zahl in einer Liste suchst Du jetzt "Bestellungen"? Wenn Du das Zahlenschema nicht auswendig kennst, suchst Du Dich tot. Davon ab, daß die Namen hier auch nicht konsistent sind, "VerbStuecklisten" fängt z.B. nicht mit "tbl" an, wie bei den meisten anderen.

Wenn die Phasen jedesmal neu definiert ist und nicht Standardphasen wie "Planung", "Umsetzung" usw. verwendet werden, kannst Du auch eine 1:n-Tabelle aus Deiner m:n machen. Ich denke, Phasen sollte dann vielleicht "PhasenName" oder dergleichen sein, denn die Standardnamen will man ja vielleicht nicht mit jedem Projekt neu definieren. Aber das mußt Du wissen.

Ein Raum kann in einer Planung niemals in mehreren Gebäuden vorkommen, das würde keinen Sinn machen. Du planst meinetwegen einen Raum in mehreren Planungsvarianten, dann wäre das Teil der Datenstruktur. Die Varianten wiederum kannst Du dann den Phasen zuordnen und hättest mehrere mögliche Planungsvarianten pro Phase. Ich würde es allerdings eher praxisnah machen: Die Planung ist der eine Bereich, in der man Varianten bestimmen kann. Die Phasen eines Projektes sind normalerweise aber Stufen in der Umsetzung, bei der Planung nur die oder eine der ersten Phasen ist. Ab konkreter Umsetzung fängt man ja nicht an, verschiedene Planungsvarianten umzusetzen - dann hat man sich für eine entschieden. In der Struktur einer Planungsvariante kann je Variante ein Raum weiterhin nur in einem Gebäude sein, alles andere würde wenig Sinn machen.
Aber ich habe keine Ahnung von dem Geschäftsmodell, das müßtest Du dann schon detaillierter erläutern.

Variante <- Gebäude <- Stockwerke <- Räume
Innerhalb von einer Variante ist alles festgelegt. Wenn Du einen Raum "verschieben" willst, weist Du dessen Parent-ID (also hier das Stockwerk) dem gewünschten Stockwerk (also dessen ID) einer anderen Planungsvariante zu. Schon ist er verschoben und Bestandteil einer anderen Planung.

Eine neue Variante ist schnell erstellt, indem man alle Datensätze in den vier Tabellen, die zu einer Variante gehören, in eine neue Variante kopiert. Das gleiche Gebäude existiert dann 2mal in den Varianten, ist datentechnisch aber ein neues Gebäude (und ebenso Stockwerk/Raum). So kann jede Variante nun Änderungen an den Daten vornehmen, ohne eine andere Variante dadurch durcheinanderzubringen.
Die Daten zu den Gebäuden/Stockwerken/Räumen können dabei natürlich auch in zusätzlichen Stammdaten festgelegt werden, um bei einer neuen Variante ebenso "bei Null" anfangen zu können.

Wie Du siehst, es gibt viele Möglichkeiten. Als erstes muß man sich aber bewußt sein, was man eigentlich genau am Ende haben will.

Die Tickfelder (Boolfelder) würde ich entfernen, sind überflüssig.

Die Teile sind am Ende eigentlich nur eine Erweiterung der Hierarchie. Ich würde hier aber strikt trennen zwischen Umgebungsdaten G/St/R und Teiledaten, da wäre der Aufwand, eine ganze Teileliste unterschiedlichen Planungsvarianten je Raum zuzuweisen, eher ziemlich groß - das handhabt dann keiner mehr.

Wenn es um Klassenräume geht, wäre eher anzunehmen, daß es einen Klassenraumtyp gibt, also z.B. eine Grundschulklasse, die sicherlich eine andere Ausstattung hat als eine Abuturientenklasse, die vielleicht eher digital ausgestattet sein soll. Diesem Raumtyp würde ich dann Teilelisten zuordnen, so kann man sie schnell zuordnen zu einem Raum und somit auch mal eben die gesamte Ausstattung wechseln.

Viel mehr kann ich dazu nicht sagen.

Gruß

Christian
Titel: Re: Datenbank Alternativen und Anzahl verknüpfen und darstellen
Beitrag von: MrB am Oktober 21, 2024, 11:32:33
OK
die Namen anpassen ok da fehlen die Prefixe teilweise,
die Nummern sind da, um eine Art Hierarchie zu erzeugen (laut meinem Kollegen), denke darüber kann man auch sortieren statt über Alphabet
Phasen sind jedesmal neu, kommt immer drauf an was schon vorhanden ist und was benötigt wird Diese Phasen beinhalten nur Stufen der Ausrüstung (zB im ersten Zeitraum(Phase) alle Klassenräume + 1 IT Labor + 2 Werkstätten).
Planung und ähnliches wird in einem zusätzlichen Dokument berücksichtigt. Hier geht es nur um Anzahlen und Preise, keine echten Zeiträume, kann 6 Monate sein oder auch 12.

ZitatEin Raum kann in einer Planung niemals in mehreren Gebäuden vorkommen, das würde keinen Sinn machen.
Naja, zB ein Büro, das in jeder Werkstatt und auch nochmal im Verwaltungsgebäude vorkommt?

Ich will Räume planen und diese dann flexibel in verschiedenen Gebäuden einsetzen.

ZitatDu planst meinetwegen einen Raum in mehreren Planungsvarianten, dann wäre das Teil der Datenstruktur.
Diese Räume müssten entweder flexibel sein, oder ich muss jede Ausstattungsvariante vorausahnen und fest anlegen(sollte möglich sein)

ZitatDie Varianten wiederum kannst Du dann den Phasen zuordnen und hättest mehrere mögliche Planungsvarianten pro Phase.
Die Räume plane ich pro Gebäude und die Gebäude pro Phase und hier muss ich irgendwie flexibel werden, das ich eine Phase und/oder ein Gebäude verändern kann.
zB Phase 1 vom Projekt 1 war geplant mit 26 Klassenräumen und 2 IT Klassen, jetzt sagt der Kunde, das reicht mir nicht, ich möchte 4 IT Klassen, also muss ich das Klassenraumgebäude dem anpassen und 24 Klassenräume und 4 IT Klassen in das Gebäude bringen.
Diese Daten sind im Endeffekt nur dafür da, Mengen und Preise aufgrund von Vorgaben festzulegen, die sich manchmal täglich mehrfach ändern. Planung der Phasen und Gebäude erfolgt an anderer Stelle

ZitatDie Tickfelder (Boolfelder) würde ich entfernen, sind überflüssig.
Sind nur eine Krücke, werden so schnell wie möglich rausgenommen, fand die von Anfang an schon schlecht

ZitatWenn es um Klassenräume geht, wäre eher anzunehmen, daß es einen Klassenraumtyp gibt, also z.B. eine Grundschulklasse, die sicherlich eine andere Ausstattung hat als eine Abuturientenklasse, die vielleicht eher digital ausgestattet sein soll. Diesem Raumtyp würde ich dann Teilelisten zuordnen, so kann man sie schnell zuordnen zu einem Raum und somit auch mal eben die gesamte Ausstattung wechseln.
So bereits geschehen in Tabelle 04_03_VerbStuecklistenSubcontainer

Also wird mir kaum was anderes überbleiben, wie eine Art Filterschlüssel zu erstellen, den ich anpassen kann.
In dem dann die Parameter wie, welches Projekt, in welcher Phase mit welchem Gebäude, Anzahl, Räume, Anzahl Räume zugeordnet werden.
Wobei ich keinen Schimmer habe wie das funktionieren soll, hatte dazu schon was probiert, ist aber irre kompliziert und hat auch nicht zu 100% funktioniert.
Das Anpassen stellt die nächste Hürde da, da ich den Filter dann in einem Formular anzeigen müsste und dann danach Anpassungen vornehmen und wieder in der zu erstellenden Tabelle tblFilter speichern.

Danke für deine Anregungen, muss ich weiter drüber nachdenken, ob das so überhaupt möglich ist.
 
Cord

Titel: Re: Datenbank Alternativen und Anzahl verknüpfen und darstellen
Beitrag von: Bitsqueezer am Oktober 30, 2024, 01:27:08
Hallo,

naja, ein Raum ist halt immer nur einmal physisch im Gebäude.
Wenn Du also 26 Klassenräume in einem Gebäude planst, würde man z.B. 26 Datensätze in einer Tabelle "tblRaeume" speichern, die dem Gebäude zugeordnet sind. Jeder Raum bekommt einen Raumtyp, der dann in einer Raumtypen-Tabelle die Standards festlegt, so daß man das nicht für jeden Raum neu machen muß.
Dann kannst Du also z.B. 26 Räume anlegen und allen den Typ "Klassenraum" zuordnen, und individuelle Abweichungen wie z.B. "Wandfarbe" o.Ä. in der Raumtabelle genau anpassen, da diese Informationen ja nicht allgemeingültig sind für den Raumtyp Klassenraum für jedes Gebäude.
Also alles, was man immer wieder braucht, in den Raumtyp (der ebenso weitere Untertabellen haben kann) und alles, was zu dem physischen Raum im spezifischen Gebäude gehört, in die Raumtabelle. Umgekehrt kannst Du auch eine Raumtyptabelle quasi wie eine Word-Vorlage benutzen, die einfach die gleichen Felder hat und deren Inhalt in die passenden Felder der Raumtabelle kopiert werden. So kannst Du die Arbeit ersparen, alles jedesmal neu machen zu müssen und hast dennoch die Freiheit, jeden Raum danach individuell anzupassen.
Hier kann man mit UPDATE und INSERT auch viele Komfortfunktionen einbauen.

Du siehst, es gibt viele Wege.

Gruß

Christian