Datenbank Alternativen und Anzahl verknüpfen und darstellen

[MrB]

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.

Sie dürfen in diesem Board keine Dateianhänge sehen.
Sie dürfen in diesem Board keine Dateianhänge sehen.

[Bitsqueezer]

Hallo,

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

• Warum Benennungen englisch und deutsch mixen? Am besten für eine Sprache entscheiden (meine Wahl wäre hier i.d.R. Englisch) und dann dabei bleiben.
• Wozu die Zahlen-Präfixe? Auch das macht die Orientierung im Tabellenaufbau schwierig. Namen sollten auch besser nicht mit Zahlen anfangen. "tbl" sollte der Prefix sein.
• Bis "ProjektPhase" wäre ich dabei, wenn dies eine Stammdatentabelle ist, so daß die gleichen Phasen immer für jedes Projekt wiederverwendet werden können. Wenn nicht, wäre 1:n ausreichend zu Projekten. Dann kann jedes Projekt seine eigenen Phasen haben. Aber wie gesagt - ist OK so.
• Bei Building zu Phasen wäre ich nicht mehr dabei. Die Tabelle ist überflüssig. Du hast bereits Phasen, die Du einem Projekt zugeordnet hast. Jede Zeile hier ist eine Phase eines Projektes (das hoffentlich per Unique Index so eingestellt ist, daß die gleiche Phase nur einmal dem gleichen Projekt zugeordnet werden kann)
• Ein Gebäude, sofern es nicht Teil der Bauplanung ist, hat bereits Räume und Stockwerke, was weitestgehend unveränderlich ist. Also gibt es Gebäude mit Stockwerken mit Räumen. Drei 1:n-Verbindungen. Diese sollten sich i.d.R. nicht mehr ändern. Es geht ja um Ausstattung und nicht um Gebäudebau, richtig?
• Die unterste Einheit (also der Raum) wird einer Projektphase zugeordnet, also der ersten m:n-Tabelle. Denn der Raum "weiß", zu welchem Stockwerk er gehört und das Stockwerk "weiß", zu welchem Gebäude es gehört. Das hat nichts mit der Verarbeitung im Formular zu tun, hier kann man später jede Art von Komfort einbauen, etwa alle Räume eines Stockwerkes einer Phase zuordnen.
  Also m:n zwischen gewünschten Räumen einer Phase und der 1. m:n-Tabelle, die ja eine spezifische Phase eines spezifischen Projektes beschreibt.
• Aufzählungsfelder sind in 99,9999% aller Fälle falsch. "Phase1,2,3" sind Aufzählungsfelder. Die gehören hier nicht hin oder Du mußt erklären, wozu die gut sein sollen
• Bei der Teileverwaltung kann man nicht so genau sehen, welche Idee dahinterstecken soll. Ein Teil wird erstmal als Stammdaten definiert. Das Teil kann dann per m:n verschiedenen Lieferanten zugeordnet werden. So kann jedes Teil von verschiedenen Lieferanten geliefert werden oder umgekehrt kann jeder Lieferant verschiedene Teile anbieten. Mit der Konstellation können dann auch Preislisten etc. eingebaut werden. Diese Informationen sind alle generell und haben erst mal nichts mit Projekten oder Phasen zu tun.
• Wenn es konkret wird, ein bestimmtes Teil für einen bestimmten Raum zu planen, dann wäre die Zuordnung hier TeileID zu RaumID. Also der oben genannten 2. m:n-Tabelle, bei der die einzelnen Räume den Phasen eines Projektes zugeordnet werden. Nicht zur Raumtabelle. Somit hätte man hier jedes Einzelteil jedem Raum jeder Phase jedes Projektes mit nur einer ID in der Teileliste-Tabelle identifiziert. Die Teileliste kann man natürlich auch noch mit Gruppen versehen oder anderem Komfort.
• Wenn Du Liefercontainer/Raum verwenden willst, wäre das damit auch gleich machbar, da der Liefercontainer auch nur eine 1:n-Verbindung wäre. Außer Du willst den gleichen Container wiederverwenden, dann mit m:n.
• Ich weiß nicht, wo Du eine Begrenzung für 14 (oder 28) Räume siehst. Die Anzahl Räume je Stockwerk ist mit der beschriebenen Tabellenkonstellation genauso unendlich wie die Anzahl Stockwerke je Gebäude und die Anzahl der Gebäude. Ebenso wie die Anzahl der Phasen und die Anzahl der Projekte.
• Teile lassen sich natürlich auch hierarchisch organisieren, aber das wäre wieder eine weitere Ebene.

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

Gruß

Christian

[MrB]

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
Sie dürfen in diesem Board keine Dateianhänge sehen.
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

(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.

Ein 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

[Bitsqueezer]

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

[MrB]

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.

Ein 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.

Du 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)

Die 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

Die 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

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.

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

[Bitsqueezer]

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