nicht angemeldet
Hallo Philipp,
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.
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.
Nein, mathematisch betrachtet sind Attribute Elemente einer Menge
und die Daten einer Tabelle ist eine Multimenge (und deshalb per
Definition unsortiert, was einigen Anfängern gerne zum Verhängnis
wird :-)).
Attribute(Felder) sind Elemente der Menge Tupel(Datensatz). Tupels(Datensätze) sind Elemente der Menge Relation(Datenbanktabelle). Somit ist eine Datenbanktabelle eine Menge von Mengen, eine Multimenge. So habe ich das, glaube ich, schon beschrieben.
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.
Ein Datenbanksystem sollte in sich geschlossen sein und nichts mit der
Anwenderebene zu tun haben, mehr noch: selbst der Zugriff auf die
Datenbank (über connect zu query-parser) sollte von den internas
(table handler) getrennt sein. MS SQL-Server ist hier schon sehr gut
zu gebrauchen.
Wie gesagt, man kann Access genau so verwenden. Man schreibt einfach nur Tabellen und Abfragen im Access und nutzt andere Office-Anwendungen oder Programmiersprachen um via ODBC mit SQL darauf zuzugreifen.
Es _gibt_ Nachteile. Die größten sind dadurch begründet, dass die Access DB _eine_ Datei im Filesystem ist. Zugriffsberechtigungen des Filesystems können also nur auf die gesamte Datenbank angewendet werden. Access bietet zwar auch eine interne Benutzerverwaltung, die sich aber leider auch bei den neueren Versionen noch nicht mit der des Betriebssystems verbinden lässt. Außerdem wird durch diese eine, schnell mehrere MByte gross werdende, Datei auch die Replikation zwischen unterschiedlichen WAN-Standorten schnell sehr zeitaufwändig.
viele Grüße
Axel