Office: (Office 2010) Access Anwendung, Step 1: Welche Tabellenstruktur? Alles in 1 Tabelle?

Hallo,

und damit hast Du genau getroffen, warum das Abstrahieren meist unsinnig ist. Es verfälscht den eigentlichen Aufbau und verleitet zu völlig falschen Annahmen. Der der helfen will hat ja keine Ahnung vom wirklichen Aufbau und kann sich nur an dem orientieren was der TE schreibt. Wenn das jetzt eine n:m ist, kannst Du das was Du jetzt hast fast alles in die Tonne treten, auch die Formulare werden dann vermutlich anders werden. Und die Beziehungen sowieso, da fehlt dann noch eine Tabelle.

 

Momentaner inhaltlicher Umfang:
- Hauptgruppe 1 hat 10 Untergruppen à 6 Prozesspunkte, wobei ein Prozesspunkt eine Frage ist die zirka so lang ist: "Wurde hier und dort dies und das unter Betracht der Regularien blabla und blibli erledigt?".
- Hauptgruppe 2 hat 1 Untergruppe à 6 Prozesspunkte.


Ich wurde gebeten es so zu gestalten, das es möglich sei bis zu 30 Hauptgruppen à bis zu 30 Untergruppen à bis zu 10 Prozesspunkte hinzufügbar zu machen.

Ich hätte das - mit der jetzigen Anwendung - schlichtweg über Redundanzen geregelt.
D.h. Wenn Hauptgruppe A und Hauptgruppe B beide die Untergruppe X haben, dann hätte ich X halt einfach zwei mal angelegt in tblUntergruppe. Einmal für Hauptgruppe_FK = A und einmal für Hauptgruppe_FK = B.

Sofern es nicht zu umständlich wäre es so umzugestalten wie du meinst, und sofern du mir konkret verraten würdest wie diese eine zusätzliche Tabelle aussehen würde.
Ich vermute eine weitere m:n Zuordnungstabelle tblHauptUnter_Zuordnung mit
- FK auf tblHauptgruppe.ID_Hauptgruppe
- FK auftblUntergruppe.ID_Untergruppe und einer
- ID_HauptUnter_Zuordnung welche dann in tblProzesschritt anstatt der tblProzessschritt.Untergruppe_FK festgehalten würde ?


/edit 10:01:

Angeschaut.
Adaptiert.
Sehr sehr geil.

Genau sowas suche ich wenn ich sage das ich die Anwendung möglichst "gut" machen will.
Minimal VBA, maximal Access interna Features.

 

Hallo!

Das kann meiner Meinung nach je nach "Inhaltslogik" sogar besser als eine n:m-Struktur passen - dann wäre es allerdings keine Redunanz. *wink.gif*

Überlegung:

Bei einer Stückliste wäre das Anlegen eines Teilestamms je Stücklistenposition redundant und daher zu vermeiden. => n:m ist besser.

Bei einem Fragebogen, bei dem sich eine Frage z. B. auf eine übergeordnete Gruppe bezieht, muss das meiner Meinung nach nicht der Fall sein - nur weil eine Frage den gleichen Wortlaut hat, bedeutet das nicht unbedingt, dass diese Frage mit der gleichnamigen Frage aus einer anderen Gruppe zusammenhängt bzw. identisch ist. (Es gibt auch Personen die gleich heißen und trotzdem erstellt man je Person einen eigenen Datensatz mit dem passenden Geburtsdatum, Sozialversicherungsnummer o. ä.)

Einfacher Test: wenn man den Text der Frage ändert (z. B. eine genauere Beschreibung ergänzt) - muss er sich dann für alle Gruppen ändern, die den gleichen (alten) Text hatten oder kann es sein, dass nur in einer Gruppe der Text geändert werden soll, obwohl der Inhalt der Frage gleich bliebt (also keine neue Frage in der "Fragentabelle" angelegt werden soll).

=>
Es hängt von der inhaltlichen Verwendung dieser Fragen ab, ob man die Fragen mehrfach verwendet (n:m-Struktur) oder ob man den Text einer Frage mehrfach in den Fragenkatalog einträgt und die Fragen als unabhängige Fragen, die zufällig den gleichen Text nutzen, behandelt. (Möglicherweise muss beides möglich sein.)

mfg
Josef

 

Ich habe zwischenzeitlich eine fachlich strukturelle Änderung vorgelegt bekommen, die dazu geführt hat das ich mein Tabellenschema wie folgt geändert habe. (Siehe Anhang)

Was bliebt:
- Man legt einen Fall für einen Kunden an
- Ein Kunde hat mehrere Konten
- Ein Fall besteht aus einer Sammlung von Hauptgruppen/ Untergruppen/ Prozesspunkten

Neu:
- Legt man einen Fall strukturell an, so kann man (optional) zu einer Hauptgruppe Konten anbinden.

Ein Beispiel wäre etwa:
- Ein Kunde hat ein Payback Konto 123 und ein Bonuskonto 456.
- Wenn man einen Fall für einen Kunden anlegt, etwa die Reparatur seines Autos, so kann man zu der Hauptgruppe (Autoreparatur) das Paybackkonto und/oder das Bonuskonto und/oder garkein Konto dazu anlegen.

Diese fachliche Herausforderung habe ich technisch interpretiert als eine m:n Beziehung zwischen Konto Arbeitsschritt und habe sie deswegen wie im Bild zu sehen über eine Zuordnungstabelle impelmentiert, da ich durch Google interpetiert habe das man so mit m:n Beziehungen umgeht.

Nun mein neues, gar nicht mal so triviales Problem:
Meine Suchmaske soll unter anderem folgende Informationen anzeigen:

Fallnummer, Kundennummer, Hauptgruppe, Konto, Status
, , , , Offen
, , , , Offen
...

Problem: Die notwendigen Joins dauern sehr lange.

Konkrete Beispieldaten:
- 10 Aufträge
- 2500 Arbeitsschritte
- 70 Prozesspunkte
- 12 Untergruppe
- 2 Hauptgruppen
- 16 Kunden
- 20 Konten
- 18000 Zuordnungen KontoArbeitsschritt

Query Dauer: ~15 Sekunden.

Ich hoffe hier irgendetwas falsch gemacht zu haben was man einigermaßen schnell fixen kann ohne alles von vorne machen zu müssen.

Code:

 

Hab das ganze nun so realisiert, dass die Technik näher am fachlichen ist.

Bis jetzt, siehe Anhang im vorherigen Post:
- Fachlich: Zuordnung Konto an Hauptgruppe
- Technisch: Zuordnung Konto an Arbeitsschritt

Am jetzt, siehe Anhang in diesem Post:
- Fachlich: Zuordnung Konto an Hauptgruppe
- Technisch: Zuordnung Konto an Hauptgruppe und Auftrag

Da die Zuordnungstabelle im bisherigen Fall bei 10 Aufträgen schon im fünfstelligen Bereich Zuordnungen hat, die jetzite Lösung in selben Szenario noch im zweistelligen Zuordnungsbereich ist erhoffe ich mir bei den ganzen Joins eine annehmbare Performance.

Da ich auf dem Gebiet kein Profi bin, hier jedoch einige sehr erfahrene Datenbankmodellierer rumlaufen würde ich mich über nachträgliches Feedback sehr freuen.

Für den Moment ist mein Problem jedoch beseitigt und das Thema somit als erledigt abgehakt.