Access

[timmy_]

Hi,

ich möchte mich Access befassen.
Doch ich bekomme das nicht hin mit mehr als 2 Tabellen und deren Beziehungen.
Kennt einer ein einfaches Beispiel für Access??

Danke im vorraus

[Ilja]

yo,

Doch ich bekomme das nicht hin mit mehr als 2 Tabellen und deren Beziehungen.

in einer datenbank stehen die unterschiedlichen objekte in beziehungen miteinander. dabei betrachtet man immer beide richtungen zweier objekte. man geht zuerst von dem ersten objekt (sagen wir ein Buch) aus, und beschreibt seine beziehung zu dem zweiten objekt (Buchgruppe). danach geht man von objekt zwei aus, und beschreibt seine beziehung zu objekt eins. durch diese zwei unterschiedlichen betrachtungswinkel kommen wie bei dem menschen auch,  unterschiedliche ergebnisse zu tage.

beide sichtweisen werden nun genommen und eingeordnet, um den Typ der Beziehung zwischen den beiden objekten festzulegen. vereinfacht dargestellt gibt es drei arten von beziehungen unter den objekten (tabellen), wobei das ":" dafür dient, die unterschiedlichen betrachtungsrichtungen voneinander zu trennen.

1:1, wir recht selten vorkommen, da man in den meisten fällen solche objekte zusammenführen kann. um das obene gannten objekt buch wieder aufzugreifen. ein buch besitzt folgende eigenschaften titel, seitenzahl, etc. die isbn nummer wird nun aber in eine extra tabelle(objekt) gespeichert. zwischen den beiden tabellen gibt es nun eine 1:1 beziehung. jedes buch hat genau eine isbn nummer in der zweiten tabelle. und jede isbn nummer hat genau ein zugehöriges buch in der buchtabelle. sicherlich wäre es sinnvoller, die isbn nummer gleich in die tabelle buch als eigenschaft mit reinzunehmen. deswegen gibt es diese art der beziehung auch recht selten.

1:n, dieser typ von beziehungen kommt doch recht häufig vor. das oben genanten beispiel mit den büchern ist eine 1:n beziehung. ein buch gehört zu einer buchgruppe (zum beispiel Liebesromane), auf der anderen seite kann eine buchgruppe mehrere bücher beinhalten. damit ich klar, es handelt sich um eine 1:n beziehung.

n:m, bei diesem beziehungstyp, kann sowohl das eine als auch das andere objekt mehrere beziehungen zu dem jeweils anderem objekt besitzen. klingt erst einmal kompliziert, ist es aber nicht. nehmen wir unser buchbeispiel und erweitern es. was bleibt ist, dass jede buchgruppe mehrere bücher beinhalten kann. zusätzlich kann aber nun jedes buch auch mehreren buchgruppen angehören, sprich, ein buch ist sowohl in der buchgruppe für medizin, als auch in der buchgruppe für geisteswissenschaften. nun haben wir eine n:m beziehung zwischen büchern und buchgruppen.

jetzt kommt der interessante teil, nämlich wie bildet man solche beziehungstypen in relationalen (tabellen) datenbanksystemen ab.

bei der 1:1 beziehung kann man sowohl in der ersten tabelle (buch) einen schlüssel haben, der auf die entsprechende isbn in der zweiten tabelle verweist. man kann diesen schlüssel aber auch in die isbn tabelle nehmen, der dann auf das buch verweist. hier hat man die wahl. aber wie gesagt, das komtm recht sleten vor.

bei den 1:m beziehungen bildet man es ebenfalls über einen schlüssel ab. aber diesmal haben wir nicht die wahl, in welche tabelle wir ihn tun, sondern der schlüssel kommt immer in die tabelle, welche die "1er beziehung" besitzt. in unserem fall wäre es die buch tabelle, die auf die buchgruppe verweist.

nun wird es endlich spannend und ich komme nach langen anlauf auf deine frage zurück. bei einer m:n beziehung raicht uns ein schlüssel nicht mehr, um die beziehung in den tabellen abzubilden. wir brauchen genau zwei schlüssel dafür. diese werden nicht etwa in den jeweiligen tabllen (buch, buchgruppe) untergebracht, sondern in einer extra tabelle, auch beziehungstabelle genannt. wir haben als bei einem n:m beziehungstyp immer drei tabellen. un genau in dieser dritten tabelle kommen nun beide schlüssel rein. der eine verweist auf die buch tabelle, der andere auf die gruppe. somit ist es un möglich, dass wir jeden buch beliebig viele buchgruppen zuordnen können. und auf der anderen seite jede buchgruppe beliebig viele bücher beinhalten kann.

ich hoffe, das war ein wenig verständlich und nicht noch mehr verwirrend.

Ilja

[timmy_]

Hallo Ilja,

danke, das fand ich sehr gut beschrieben.
Das werde ich mir merken oder am besten mal ausdrucken und bei bedarf draufschauen!

Vielen Dank!

[zwerg]

Glück auf Ilja!

Danke für die super Beschreibung.
Plane auch gerade eine Datenbank, die mir das kommentieren der Bilder auf meiner Seite ermöglicht. Da war deine ausführliche und leicht verständliche Beschreibung genau das richtige.

Beste Grüße

zwerg Alex

[Hamstar]

1:1, wir recht selten vorkommen, da man in den meisten fällen solche objekte zusammenführen kann.

Wenn man durch Zusammenführen eine Optimierung erreicht ja, aber es gibt natürlich auch den Fall der nullable "1:1"-Beziehung (Beispiel: Lied und Autor, bei Volksliedern gibt es keinen Autor(Komponisten)).

[Ilja]

yo,

Wenn man durch Zusammenführen eine Optimierung erreicht ja, aber es gibt natürlich auch den Fall der nullable "1:1"-Beziehung (Beispiel: Lied und Autor, bei Volksliedern gibt es keinen Autor(Komponisten)).

ich würde anders herum argumentieren, nämlich nicht zu trennen was zusammen gehört, wenn man dadurch nicht einen entscheidenen vorteil bekommt (zum beispiel performance). bezogen auf mein beispiel bedeutet das, die isbn nummer erst gar nicht von den büchern zu unterteilen. und selbst wenn das feld den wert NULL besitzen kann, so ist das in meinen augen kein grund, es auszulagern, sondern auch in diesem fall würde ich es in der tabelle belassen. dann ist eben ein feld mal ohne eintrag. ansonsten müssten ja alle spalten mit NOT NULL deklariert oder ausgelagert werden.

Ilja

[Hamstar]

ich würde anders herum argumentieren, nämlich nicht zu trennen was zusammen gehört,

Erst einmal geht es um das Trennen von dem, was nicht zusammengehört. Ansonsten kommt eine "1:1" erst gar nicht in Frage.

wenn man dadurch nicht einen entscheidenen vorteil bekommt (zum beispiel performance).

Das Performance-Argument kommt immer erst zuletzt bzw. wenn es wirklich einen Engpass gibt. Ich habe schon zu viele idiotische Diskussionen geführt, in denen der das Datendesign nicht Verstehende am Strohalm "Performance" zu saugen begann.
Ich kenne übrigens kein einziges überzeugendes P-Argument für die Aufteilung eines Objekts.

bezogen auf mein beispiel bedeutet das, die isbn nummer erst gar nicht von den büchern zu unterteilen. und selbst wenn das feld den wert NULL besitzen kann, so ist das in meinen augen kein grund, es auszulagern, sondern auch in diesem fall würde ich es in der tabelle belassen.

Mag ja alles sein, aber ich hatte ein Beispiel genannt für eine sinnvolle nullable "1:1", auch wenn es eigentlich ein constraint auf eine "1:n" (wobei n=0 oder n=1) darstellt.

dann ist eben ein feld mal ohne eintrag. ansonsten müssten ja alle spalten mit NOT NULL deklariert oder ausgelagert werden.

Ja genau, das kenne ich, "Spalten auslagern" (nicht etwa Objekte), *brrrr*.

;)

[Frank (no reg)]

Hallo,

was bekommst du nicht hin:
[ ] Anlegen von Tabellen ab der 3. Tabelle
[ ] Anlegen von Beziehungen ab der 3. Tabelle
[ ] Abfragen von mehr als 2 miteinander verknüpften Tabellen
[ ] Die Bedienung von MS Access Wizards oder Designerobjekten

Ein einfaches und eigentlich das Standardbeispiel für MS Access ist die Northwind Datenbank, die zusammen mit MS Access installiert werden worden sollte. Hängt allerdings auch von der MS Access Version ab. Bei neueren 2003 und 2007 ist imho das "Northwind" Beispiel durch "AdventureWorks" ersetzt worden, was es bitzeli komplizierter ist.

Ciao, Frank

[timmy_]

Hi,

eigentlich wollte ich nur ein Beispiel nachbauen.
Und zwar:

Eingabe einer Nummer und man bekommt das den titel einer CD.
Mit MySQL und SQL würde ich das noch hinbekommen, aber mit Access ... ??

Danke

[Frank (no reg)]

Du möchtest dein Beispiel mit einem VBA-Formular (VBA = Visual Basic for Applications) nachbauen, welches ein Eingabefeld hat und bei Eingabe bzw. bei Klick auf einen nebenstehenden Button eine SQL Abfrage mit einem Parameter mit dem Wert aus dem Eingabefeld ausführt und das Ergebnis des ADODB.Recordsets in einer Listbox oder einem Grid anzeigt?

Mit MySQL und SQL würdest du das hinbekommen, aha. Und an was scheitert es nun? Ich tippe mal auf VBA. Aber das ist eben nur geraten, da du ja nicht gerade mit brauchbaren Informationen über dein Vorhaben rausrückst. Sorry, aber dann kann ich dir auch nich weiterhelfen.

Ciao, Frank

... self.close()