Bericht sortiert nach Ja-Nein-Feldern

[BotschafterSarek]

Hallo zusammen,

ich habe die folgende Tabelle:



Die AgeXX-Felder geben an, daß ein bestimmtes Angebot für eine bestimmte Altersklasse geeignet ist. Ein Angebot kann für mehrere Altersgruppe geeignet sein. Nun möchte ich einen Bericht erzeugen, der nach Altersstufen sortiert ist. Wenn ein Angebot für mehrere Altersgruppen geeignet ist, soll es auch bei all diesen Altersgruppen erscheinen. Das müßte also etwa so aussehen:

Alter 0 bis 5 Jahre
Taufvorbereitung
Kindergottesdienst
Familiengottesdienst

Alter 6 bis 13 Jahre
Erstkommunionvorbereitung
Kindergottesdienst
Familiengottesdienst
Gottesdienst
Sternsingeraktion

Alter 14 bis 20 Jahre
Firmvorbereitung
Familiengottesdienst
Gottesdienst
Sternsingeraktion

Alter 21 bis 30 Jahre
Taufvorbereitung
Familiengottesdienst
Gottesdienst

Alter 31 bis 65 Jahre
Taufvorbereitung
Familiengottesdienst
Gottesdienst

Alter ab 66 Jahre
Familiengottesdienst
Gottesdienst
Seniorennachmittag



Wie kann ich so etwas realisieren?



Danke im Voraus,
Sarek

[Anhang gelöscht durch Administrator]

[DF6GL]

Hallo,

die Tabelle mit diesem Aufbau ist an sich nicht geeignet für eine relationale Datenbank... Es sind keine Normalisierungsregeln umgesetzt (mehrere Tabellen, die in Beziehung zueinander stehen. Das erfordert zudem die Vergabe von Primärschlüsselfeldern.)

In diesem Fall kann die Aufgabe mittels einer Union-Abfrage gelöst werden, die insgesamt 6 Einzelabfragen (für die 6 Altersbereiche) mit den jeweils passenden Kriterienangaben enthält .

[BotschafterSarek]

die Tabelle mit diesem Aufbau ist an sich nicht geeignet für eine relationale Datenbank... Es sind keine Normalisierungsregeln umgesetzt (mehrere Tabellen, die in Beziehung zueinander stehen. Das erfordert zudem die Vergabe von Primärschlüsselfeldern.)

Diese Tabelle ist eine Demo, die ich extra für die Verdeutlichung meines Problems angelegt habe. In der Originaldatenbank gibt es natürlich mehrere Tabellen. Auch diese Tabelle hat mehrere Felder und einen Schlüssel - allerdings keinen Primärschlüssel, sondern in diesem Fall einen Sekundärschlüssel.

Ich wüßte aber nicht, was man in diesen Informationen noch normalisieren sollte. Da sind ja schon gar keine Redundanzen mehr drin ...

In diesem Fall kann die Aufgabe mittels einer Union-Abfrage gelöst werden, die insgesamt 6 Einzelabfragen (für die 6 Altersbereiche) mit den jeweils passenden Kriterienangaben enthält .

Union-Abfrage habe ich noch nie gehört. Gibt es das auch unter Access 2003?

[DF6GL]

Hallo,

Ich wüßte aber nicht, was man in diesen Informationen noch normalisieren sollte. Da sind ja schon gar keine Redundanzen mehr drin ...

Die Auflistungsfelder (Felder mit identischem inhaltlichem Sinn (--> "Altersbereich")  gehören in eine extra Tabelle und sollten nicht aus "Werten" abgeleitet sein.
Genau aus dieser Nicht-Normalisierung heraus ergibt sich die Notwendigkeit der (nur manuell unterstützten) Union-Abfrage..

Union-Abfrage habe ich noch nie gehört. Gibt es das auch unter Access 2003?

Sicher....  Allerdings nicht unterstützt vom Abfrageentwurf-GUI. Eine solche Abfrage muss als SQL-String in der SQL-Ansicht im Abfrageentwurf eingegeben werden.

Code [Auswählen] Erweitern

Select "Alter 0 bis 5 Jahre" as Titel, Angebot from Angebote where Age00 <>0
Union
Select "Alter 6 bis 13 Jahre" as Titel, Angebot from Angebote where Age06 <>0
Union
Select "Alter 14 bis 20 Jahre" as Titel, Angebot from Angebote where Age14 <>0
.
.    ......      order by Age00,Age06,Age14,Age21,Age31,Age66
.

[BotschafterSarek]

Die Auflistungsfelder (Felder mit identischem inhaltlichem Sinn (--> "Altersbereich")  gehören in eine extra Tabelle und sollten nicht aus "Werten" abgeleitet sein.

Das habe ich jetzt nicht wirklich verstanden

Sicher....  Allerdings nicht unterstützt vom Abfrageentwurf-GUI. Eine solche Abfrage muss als SQL-String in der SQL-Ansicht im Abfrageentwurf eingegeben werden.

Also, ich habe das wie folgt verstanden und ergänzt:

Code [Auswählen] Erweitern


Select "Alter 0 bis 5 Jahre" as Titel, Angebot from Angebote where Age00 <>0
Union
Select "Alter 6 bis 13 Jahre" as Titel, Angebot from Angebote where Age06 <>0
Union
Select "Alter 14 bis 20 Jahre" as Titel, Angebot from Angebote where Age14 <>0
Union
Select "Alter 21 bis 30 Jahre" as Titel, Angebot from Angebote where Age21 <>0
Union
Select "Alter 31 bis 65 Jahre" as Titel, Angebot from Angebote where Age31 <>0
Union
Select "Alter ab 66 Jahre" as Titel, Angebot from Angebote where Age66 <>0
order by Age00,Age06,Age14,Age21,Age31,Age66


Access hat daraus (wenn ich es speichere und wieder öffne) das gemacht:

Code [Auswählen] Erweitern


Select "Alter 0 bis 5 Jahre" as Titel, Angebot from Angebote where Age00 <>0
Union
Select "Alter 6 bis 13 Jahre" as Titel, Angebot from Angebote where Age06 <>0
Union
Select "Alter 14 bis 20 Jahre" as Titel, Angebot from Angebote where Age14 <>0
Union
Select "Alter 21 bis 30 Jahre" as Titel, Angebot from Angebote where Age21 <>0
Union
Select "Alter 31 bis 65 Jahre" as Titel, Angebot from Angebote where Age31 <>0
UNION Select "Alter ab 66 Jahre" as Titel, Angebot from Angebote where Age66 <>0
ORDER BY Age00, Age06, Age14, Age21, Age31, Age66;


Wenn ich die Abfrage ausführen will, melde Access:
Der ODER BY-Ausdruck (Age00) schließt Felder ein, die nicht durch die Abfrage ausgewählt wurden. Nur Felder, die in der ersten Abfrage angegeben wurden, können in dem ORDER BY-Ausdruck verwendet werden.

Was bedeutet das? Leider habe ich von SQL absolut keine Ahnung ...

[Wurliwurm]

Das Feld, nach dem sortiert wird, muß in jeder Zeile vorhanden sein.

Verbesserungsvorschlag:

Code [Auswählen] Erweitern

Select "Alter 0 bis 5 Jahre" as Titel, Angebot, '0' AS Sortierer from Angebote where Age00 <>0
Union
Select "Alter 6 bis 13 Jahre" as Titel, Angebot,  '1' AS Sortierer  from Angebote where Age06 <>0
...
order by Sortierer

[BotschafterSarek]

Brauche ich die Sortierung überhaupt? Wenn ich die weglasse ist es auch schon richtig sortiert. Und selbst wenn nicht, kann ich ja im Report noch sortieren ...

[Wurliwurm]

Ne, dann ist das schon durch die Reihenfolge der einzelnen Abfrage richtig sortiert.
Und laß Dich nicht verunsichern, daß Deine Daten "nicht aureichend normalisiert" sind.

http://home.f1.htw-berlin.de/scheibl/db/index.htm?./Grund/Entwurf.htm
Entwurfsfehler II: Zuviele Tabellen

[BotschafterSarek]

Ne, dann ist das schon durch die Reihenfolge der einzelnen Abfrage richtig sortiert.

Ok, danke ... da spare ich mir das mit dem ORDER BY. Aber nun noch mal eine Frage: Wenn in der Tabelle jetzt noch eine Spalte "Ort" hinzukäme, die genau wie "Angebot" in der Abfrage angezeigt werden soll - wie füge ich das in das SQL-Statement ein?

Und laß Dich nicht verunsichern, daß Deine Daten "nicht aureichend normalisiert" sind.

Hehe, ich dachte mir schon, daß es da unterschiedliche Meinungen zu gibt. Ich wüßte auch ehrlich gesagt nicht, was ich da noch normalisieren könnte. Ich bräuchte genausoviele Felder für Schlüssel wie ich jetzt für Inhalte bräuchte. Und es würde kein einziges Feld eingespart. Es sei denn, ich verschlüssele die einzelnen Altersgruppe binär, so daß 1 = 0 bis 5, 2 = 6 bis 13, 4= 14 bis 20 und so weiter. Dann könnte ich in einem Feld mit dem Wert 3 sagen, daß es sowohl für 0 bis 5 als auch von 6 bis 13 geeignet ist. Aber naja ....

[DF6GL]

Hallo,

ich würde eher dies zitieren wollen:

http://home.f1.htw-berlin.de/scheibl/db/index.htm?./Grund/Entwurf.htm


als Verstoß gegen die 1NF,  wodurch "nicht aureichend normalisiert" genau zu diesen Union-Konstrukt führt, was in aller Regel an dieser Stelle keine Aussicht auf weitere Verwendbarkeit (als für einen Bericht) bietet, soll heißen, das an anderer Stelle angedeutete "Optimum" eben nicht darstellt. Es barucht lediglich eine weiterer Altersbereich hinzukommen oder auch wegfallen, dann "optimiert" man wieder in der Urschleimsuppe.


Das ist auch nicht zu vergleichen mit wirklich überflüssigen "Stammtabellen" wie einer solchen für die Hinterlegung des Geschlechtes, bei dem es in näherer Zukunft vermutlich keine Änderung geben wird.. 

[Wurliwurm]

Es barucht lediglich eine weiterer Altersbereich hinzukommen oder auch wegfallen, dann "optimiert" man wieder in der Urschleimsuppe.

Einen Tod muß man sterben. Wenn das in einer m:n-Tabelle abgebildet wird, kann man leicht neue Altersgruppen hinzufügen. Auf der anderen Seite wird es komplizierter, wenn man Abfragen braucht, welche Angebote für bestimmte Altergruppen NICHT geeignet sind.

Alles ist relativ. Was die Geschlechter betrifft, so kann es durchaus sein, daß es bald nicht mehr politisch korrekt ist, wenn jeder sich für ein Geschlecht m/w entscheiden muß.

[BotschafterSarek]

Was die Geschlechter betrifft, so kann es durchaus sein, daß es bald nicht mehr politisch korrekt ist, wenn jeder sich für ein Geschlecht m/w entscheiden muß.

Ich dachte, das entscheidet unser Erbgut für uns?  XX=weiblich, XY=männlich ...

[DF6GL]

Hallo,

und ich sterbe lieber unter der Vorstellung, nach wie vor zum männlichen Geschlecht zu gehören....  

Vorher schlage ich aber vor, dieses Thema in die Rubrik "Small Talk" zu verschieben.  

[MzKlMu]

Hallo,

ich dachte mir schon, daß es da unterschiedliche Meinungen zu gibt. Ich wüßte auch ehrlich gesagt nicht, was ich da noch normalisieren könnte.

eigentlich kann es da keine unterschiedlichen Meinungen geben. Die DB verstößt gegen die Normaliserungsregeln, die 3. Normalform sollte im Regelfall eingehalten werden. Im hier vorliegenden Fall ist das Datenmodell falsch, da gibt es keinen Spielraum, da darf es auch keine unterschiedlichen Meinungen geben. Bei korrektem, normalisierten Aufbau der DB ist ein solcher Bericht ganz einfach. Da braucht es kein Union oder sonstige Hilfskonstrukte. Wer in einer DB eine Unionabfrage benötigt, hat im Aufbau meist was falsch gemacht.

Um nicht nur besserwisserich zu sein   , habe ich mir mal die Mühe gemacht, die DB mit einer n:m Beziehung aufzubauen.
Es gibt ein Formular zur Zuordnung der Angebote zur Altersgruppe. In diesem Formular habe ich auch einen Button zum Aufruf des Berichts, der wie gewünscht sortiert ist. Ich habe auch mal eine Kreuztabelle (Abfrage) gemacht für eine andere Darstellungsweise.

Zum Vergleich, füge mal in Deiner Version noch das Angebot "Sammeln für Brot für die Welt" dazu.
Was musst Du in Deiner Version alles ändern?

Bei meinem Vorschlag, kommt einfach ein weiterer Datensatz für das Angebot in die Angebotstabelle und fertig, alles passt.

Wenn in der Tabelle jetzt noch eine Spalte "Ort" hinzukäme,

Wie ist das gemeint mit dem Ort?
Z.B. Der Kindergottesdienst ist dort, der Seniorennachmittag hier und kann ein Gottesdienst (oder andere Angebote) an verschiedenen Orten sein?
Das wäre noch sorgfältig zu klären.

DB anbei

[Anhang gelöscht durch Administrator]

[Wurliwurm]

eigentlich kann es da keine unterschiedlichen Meinungen geben. Die DB verstößt gegen die
Normaliserungsregeln, die 3. Normalform sollte im Regelfall eingehalten werden. Im hier vorliegenden Fall
ist das Datenmodell falsch, da gibt es keinen Spielraum, da darf es auch keine unterschiedlichen
Meinungen geben.

Ich habe da halt nicht so die dogmatische Leidenschaft und Regeltreue. Normalisierung ist kein Zweck, es
dient der Vermeidung von Anomalien. In dem Beispiel liegt keine Verletzung von 3NF vor, da kein
Nichtschlüsselattribut eines anderes funktional bestimmt. Die Flags sind unabhängig voneinander. Sie
hängen auch nur vom Schlüssel ab. Es können keine Anomalien entstehen.

Da braucht es kein Union oder sonstige Hilfskonstrukte. Wer in einer DB eine Unionabfrage benötigt, hat im
Aufbau meist was falsch gemacht.

Als dogmatische Aussage ist das falsch. UNION ist kein Hilfskonstrukt, sondern eine ganz elementare Operation der relationalen Algebra. In Deinem Bsp brauchst Du das "Hilfskonstrukt"  der Kreuztabelle, und wenn das nicht im Access fest eingebaut wäre, wäre es durchaus nicht ganz trivial, das in SQL zu schreiben.

Man kann doch auch in dem Urprungsbeispiel ganz einfach neue Angebote einführen und ankreuzen, für welche Altergruppen diese geeignet sind. Es wird erst dann aufwändiger, wenn neue Altersgruppen hinzukommen.