Group by funktioniert nicht

[Philipp Hasenfratz]

Halihallo Axel

Hm. Deine Definition. Ich bin damit nicht wirklich einverstanden, da
sie nicht impliziert eine Relationship mit einer anderen Tabelle auf-
zubauen, oder zumindest die Grundvoraussetzung dafür zu erfüllen.
Doch, jede Tabelle, welche sich an die Definition hält, also jede Datenbanktabelle, erfüllt die Grundvoraussetzungen für eine Beziehung zu einer anderen Datenbanktabelle. Eine Beziehung definiert sich von Attribut einer Relation zu Attribut einer zweiten Relation. Einzige Voraussetzung hierfür ist, dass beide Attribute Attribute des selben Typs sind oder zumindest in einen Typ überführt werden können.

Zugestanden. Beziehungen lassen sich auch über nicht ausdrücklich
dafür bestimmte Attribute herstellen, jedoch ist dies in der
Theorie - wie ich schoneinmal bemerkte - *nicht umbedingt*
vorgesehen.

Zurück zur Definition. Eine Relation ist im mathematischen Sinne eine
Zuordnung von Elementen aus einer oder mehreren Mengen und ist eine
Teilmenge des kartesischen Produktes dieser Mengen. Praktisch lässt
sich dieses kartesische Produkt natürlich durch irgendeine Join-
Bedingung einschränken, theoretisch ist es jedoch vorgeschlagen die
Bedingungen über (Fremd-)Schlüssel im Datenschema zu definieren.

Und in der Tat: Du musst diese (im mathematischen Sinne) Relation
irgendwie ausdrücken|definieren (falls denn eine Tabelle eine
Relation sein soll) und dies geschieht über Primary und Foreign Keys.

Nehmen wir mal folgendes:

Person

person_id     PRIMARY KEY
adresse_id    FOREIGN KEY
name

Adresse

adresse_id    PRIMARY KEY
name

Diese zwei Tabellen definieren die mathematische Relation:

R = {(person_id,adresse_id) | durch Inhalt bestimmt}

oder konkret z.B.:

R = {(1,15),(2,13),(3,15)};  // Adresse 15 beherbergt zwei Personen,
                             // die Personen 1 und 3.

Durch PRIMARY und FOREIGN KEY in Person ist diese Relation bereits
vollständig definiert und deshalb ist meiner Meinung nach Person
eine Relation (nicht nur eine Tabelle). Adresse selber ist auch
eine Relation, nämlich die Identitsche => jeder PRIMARY KEY wird auf
sich selber abgebildet.
Ohne PRIMARY und FOREIGN KEY liesse sich eine Relation nur dynamisch
durch eine SQL-Abfrage definieren, die Tabelle selber ist jedoch
keine Relation! - Erst die Ausführung des Queries generiert dynamisch
eine Relation.

Es sei denn, du definierst ID ausdrücklich als PRIMARY KEY, dann
wäre ich einverstanden.
Es ist nicht zwingend ein Primary Key an einer Beziehung beteiligt. Es kann auch n:m - Beziehungen geben.

n:m Beziehungen werden in der Theorie durch eine dritte Tabelle
gelöst, welche jeweils von jeder der zwei Tabellen den Primary Key
nimmt. Aber auch hier kannst du die Relation natürlich dynamisch
über die Attribute erstellen, aber wozu bräuchtest du denn noch
Primary und Foreign Keys?
Zugestanden, es ist nicht immer ein primary key an der Beziehung
beteiligt, aber falls dem so ist, sind diese Tabellen
keine Relationen, sondern es sind lediglich Tabellen, über die du
mit einer geeigneten Join-Bedingung dynamisch und "temporär" eine
Relation definierst.

Access ist schon schlimm genug :-)
Warum?
[X/4] Weil es von Microsoft ist.
[X/4] Weil ich es nicht kenne bzw. beherrsche.
Ich kenne es nicht gut, habe aber schon damit gearbeitet.
[X/2] Aus folgenden, mir wichtigen Gründen:
Access wiederspiegelt einen meiner Meinung nach typischen
konzeptionellen Fehler von Microsoft. Sie vermischen verschiedene
Abstraktionsgrade (Darstellung/Formular - Datenebene) vermeindlich
zu Gunsten von Endanwendern und Otto-Normal-Usern.
Darin kann ich keinen Nachteil sehen. Tabellen und gespeicherte Abfragen _sind_ von Formularen und Berichten getrennt. Die Möglichkeit, Formulare und Berichte zu erstellen, bieten das, was Access eben sein soll, ein RDBMS mit Office-Benutzerschnittstelle. Man muss diese Schnittstelle nicht nutzen. Meiner Meinung nach, fehlt aber genau diese Möglichkeit im OpenOffice noch. Wobei man natürlich auch dort Tabellendokumente mit externen Datenbanken verbinden kann, allerdings lange nicht so komfortabel, wie mit Access im MS-Office. Der _normale_ Office-Nutzer verlässt sich zwar meist auf einen Datenbankadministrator. Ich kenne aber mehrere Anwender, die sich einen solchen nicht leisten können/wollen.

Naja, einverstanden :-)

Viele Grüsse

Philipp