Datenbank Beziehungen Erklärung

[Retsam-Master]

Hallo zusammen

Ich nutze Power Bi und kappiere den Aufbau der Beziehungen nicht,
Wann brauche ich sozusagen was?
ich habe auch eine Doku gefunden aber ich wird irgendwie dennoch nicht schlau draus
und Zwar kapier ich das hier nicht:

https://docs.microsoft.com/de-de/power-bi/desktop-create-and-manage-relationships

Kann mir das jemand in einem Praktischen Beispiel erklären? (von mir aus für dumme )

Ich hab jetzt sehr lange an einem Problem (Beziehungen) gearbeitet bis ich kappiert habe, das ich eine m:n in beide Richtungen brauche. was ich effektiv damit gemacht habe, keine Ahnung

ERGÄNZUNG

Manchmal habe ich auch das Problem das ich wählen kann "Table1 filtert Table2" aber nicht "beide" möglich oder auch nicht "Table2 filtert Table1" kappier ich auch nicht warum

 

[KillerCow]

Die Suchmaschine deines Vertrauens hast du benutzt? https://de.wikipedia.org/wiki/Kardinalität_(Datenbankmodellierung) finde ich jetzt garnicht so schlecht.

 

[ella_one]

Microsoft Dynamics ohne theoretische Grundlagenkenntnisse zu verwenden ist schon recht verwegen!!!

 

[Retsam-Master]

@KillerCow
Da macht aber etwas keinen Sinn

Wen in "Tabelle1" die KundenID ist und in "Tabelle2" auch KundenID vorhanden ist und ich diese verknüpfe, kann ich nur n:m wähle obwohl ja eigentlich 1:1 sein müsste
Aber da krieg ich einen Fehler das dies nicht möglich ist....
Sowas versteh ich jetzt zb. nicht.

@ella_one

Da dies nichts mit meinem Problem zu tun hat oder nichts dazu Beiträgt möchte ich nachfragen warum dieser Beitrag?

 

[RalphS]

Weil er recht hat. Tabelle 1 gegen Tabelle 2 ist entweder 1:1 oder 1:n, niemals m:n. Mit ein bißchen Grundlagenwissen versteht auch jeder, daß. das sofort ausgeschlossen ist.

Simples Beispiel. Ich hab ein Fahrrad (Tabelle 1) und einen Fahrer dazu (Tabelle 2).

Option A: Exakt ein Fahrer auf ein Fahrrad. Nur der mit dem Schlüssel zum Fahrradschloß kann das Fahrrad bedienen und es gibt nur ein Schloß.

Ergebnis: 1:1.
Umsetzung: Meine Fahrer.ID und meine Fahrrad.ID sind identisch und beide Primärschlüssel.



Option 2. Ich habe eine Anzahl Fahrräder, diesmal ohne Schloß, und eine Anzahl Fahrer dazu. Jeder Fahrer kann sich auf ein Fahrrad setzen, aber nur ein Fahrer paßt auf ein Rad.

Ergebnis: 1:n. n Fahrer auf jeweils ein Fahrrad.
Umsetzung: Ich hab eine Fahrer.ID als extra Spalte in Fahrräder. Da rein kommt die ID desjenigen Fahrers, der auf diesem Fahrrad halt sitzt. Ein neuer Fahrer überschreibt notwendigerweise die bisherige Fahrer-ID in der Räder-Tabelle.


Option 3 macht sich mit Fahrrädern etwas schwieriger. Weichen wir deshalb aus auf Fahrrad-Sharing und sagen: es gibt einen Pool von n Fahrrädern und einen Pool von m Fahrern. Jeder Fahrer kann eine Anzahl Fahrräder reservieren, zB für seine Family.

Jetzt hab ich eine Tabelle Fahrer und eine Tabelle Fahrräder. Die Zuordnung krieg ich dort NICHT mehr unter. Ich muß ja mehr als eins zuordnen.

Ergebnis: M:N:
Implementierung: M:N zeichnet sich dadurch aus, daß es eine zusätzliche Zuordnungstabelle gibt, hier sowas wie FahrerZuFahrrad. Dort stehen beide IDs in Zuordnung drin: (FahrerID; FahrradID). Evtl mehr, zB Ausleihzeiten, Beginn und/oder Ende, vereinbarter Preis. Derlei Dinge, die weder mit dem Fahrer noch dem Rad zu tun haben, sondern die insbesondere die Zuordung dieser Fahrer auf diesem Rad betreffen.



Wie bereits geschrieben. Einfach mal ein bißchen Google anstrengen und die absoluten Basics von Datenbanken anschauen. Sonst geht alles in Folge gegen den Baum.