M : n Relationen zu 1 : n ?

Computer: Software & Programmierung Datenbanken allgemein
#1

Jetzt kommt mal was für alle Theoretiker:
Ich brauch eigentlich nur eine Meinung von euch, ob mein Gedankengang richtig ist.

Also stellt euch vor ihr habt eine relationale Datenbank und wollt da Daten aus einem Prozess eintragen. Am besten zu jedem Fehler die Ursache. Nun kann jeder Fehler beliebig viele Ursachen haben und umgekehrt. Also eine m : n (Ursache : Fehler) Relation. Die müssen also irgendwie vorher auf 1:n Relationen herunter gebrochen werden. Die Ursachen kann ich nicht pro Fehler verkleinern (an 1 annähern) aber ich könnte die Anzahl der Fehler pro Ursache vergrößern (also detaillierter erfassen) und dadurch Ursachen ausschließen. Da käme ich doch näherungsweise auch an 1:n Relationen heran, oder?

PS: Ich weiß selber nur Müll abgefragt wird wenn die Relationen nicht sauber sind.

#2

Hallo Mike,
warum must du es denn auf eine 1:n relation bringen? warum machst du nicht einfach eine m:n relation? über eine zusätzliche „link“ tabelle?

dann könnten jdeder fehlerbeschreibung beliebig viele ursachen zugeordnet werden und umgekehrt. und das ist doch das was dein problem offensichtlih am besten darstellt?

gruss chris

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#3

Hi!
Nimm einfach das Datum dazu und mach eine Art
Fehlerliste draus (FehlerToUrsachen)

Situation bisher:
n : m
Fehler : Ursachen

ein Fehler kann VIELE ursachen haben
eine Ursache kann VIELE fehler haben

Situation nachher:
(1) : (n) : (1)
Fehler : Fehler2Ursachen : Ursachen

ein Eintrag in der Liste gehört zu EINEM Fehler
ein Fehler hat VIELE einträge in der Liste
ein Eintrag in der Liste gehört zu EINER Ursache
ein Ursache hat VIELE einträge in der Liste

Hoffe ich konnte Dir weiterhelfen!
Liebe Grüße
Björn

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#4

Vielen Dank …
… an Cris und Bjorn. Das ist genau was ich brauche. Ich nehm als Linktabelle einfach einen Fehlercode. Dann kann ich mir immer noch überlegen ob ich einfach Ursachen n:1 zuordne oder spezifische Ursachen definiere als 1:1 Zuordnung. Bei zweiter Möglichkeit würden die Ursachen menge viel größer werden und ich wär wieder bei meiner Anfangsfrage. Das wär dann eine 1:n:m Verknüpfung mit n = m. Also nochmal DANKE

#5

Moin, Mike,

Jetzt kommt mal was für alle Theoretiker:

ich hoffe, auch Praktiker dürfen was dazu sagen :smile:

Der saubere Weg ist die Auflösung in zwei 1:n-Relationen, damit ist immer gewährleistet, dass die Datenbank für alles offenbleibt.

Vorher wäre eine Begriffsbestimmung nötig: Was ist ein Fehler - ein Schadbild oder ein Ereignis? Ein Schadbild kann beschrieben werden, das Ereignis hat nur zwei Eigenschaften, nämlich Zeit und Ort. Was ist eine Ursache - ein Anlass oder ein Grund?

Die Praxis zeigt, dass eine Definition wie

kann jeder Fehler beliebig viele Ursachen haben und umgekehrt.

sorgfältigst hinterfragt werden muss, damit sie einer vernünftigen Analyse standhält.

m:n-Relationen sind nur dann gegeben, wenn die Partner, die daran teilhaben, sauber beschrieben werden können, sprich: Eigenschaften haben und jeweils eine eigene Identität besitzen.

Gruß Ralf

#6

Moin, Mike,

Jetzt kommt mal was für alle Theoretiker:

ich hoffe, auch Praktiker dürfen was dazu sagen :smile:

Der saubere Weg ist die Auflösung in zwei 1:n-Relationen,
damit ist immer gewährleistet, dass die Datenbank für alles
offenbleibt.

Mein Reden, zwei 1:n

Vorher wäre eine Begriffsbestimmung nötig: Was ist ein Fehler

  • ein Schadbild oder ein Ereignis? Ein Schadbild kann
    beschrieben werden, das Ereignis hat nur zwei Eigenschaften,
    nämlich Zeit und Ort. Was ist eine Ursache - ein Anlass oder
    ein Grund?

Das könnte man doch umgehen indem man die Tabelle in der die
Fehler und Ursachen Tabellen zusammenlaufen „Fehler2Ursachen“
nennt und als spalten: „id_fehler“, „id_ursache“, „datum“ benutzt
oder sehe ich das falsch?

Die Praxis zeigt, dass eine Definition wie

kann jeder Fehler beliebig viele Ursachen haben und umgekehrt.

sorgfältigst hinterfragt werden muss, damit sie einer
vernünftigen Analyse standhält.

m:n-Relationen sind nur dann gegeben, wenn die Partner, die
daran teilhaben, sauber beschrieben werden können, sprich:
Eigenschaften haben und jeweils eine eigene Identität
besitzen.

Gruß Ralf

Viele Grüße
Björn

#7

Moin, Björn,

Das könnte man doch umgehen

was könnte man umgehen - die Analyse?

indem man die Tabelle in der die Fehler und Ursachen Tabellen
zusammenlaufen „Fehler2Ursachen“ nennt und als spalten:
„id_fehler“, „id_ursache“, „datum“ benutzt
oder sehe ich das falsch?

Weiß ich nicht, das könnte nur der Mike beantworten. Ein Ereignis identifiziert sich durch Ort und Zeit, gültige Paarungen von Fehler und Ursache durch deren beide Ids. Wie schon E.F. Codd so schön sagte: „It’s the key, only the key and nothing but the key!“

Gruß Ralf

#8

Hey Ralf

Moin, Björn,

Das könnte man doch umgehen

was könnte man umgehen - die Analyse?

nicht die analyse umgehen,
meinte es zu umgehen sich gedanken für den tabellennamen zu machen.

indem man die Tabelle in der die Fehler und Ursachen Tabellen
zusammenlaufen „Fehler2Ursachen“ nennt und als spalten:
„id_fehler“, „id_ursache“, „datum“ benutzt
oder sehe ich das falsch?

Weiß ich nicht, das könnte nur der Mike beantworten. Ein
Ereignis identifiziert sich durch Ort und Zeit, gültige
Paarungen von Fehler und Ursache durch deren beide Ids. Wie
schon E.F. Codd so schön sagte: „It’s the key, only the key
and nothing but the key!“

Genau! hehe
„The Key, the whole Key, and nothing but the Key, so help me CODD“

Gruß Ralf

Schönen Abend noch,
Gruß
Björn

#9

Moin, Björn,

sich gedanken für den tabellennamen zu machen.

das ist ein Kapitel für sich. Mit A_zu_B wird man nicht lange glücklich, das scheitert vor allem dann, wenn die Beziehungen komplexer werden und zB A2B mit C verknotet werden soll, außerdem mit D und was da rauskommt nochmal mit E.

Sinnvoller scheint mir, für das Ereignis einen Namen zu finden, aus dem ein neues Exemplar von A2B oder A2B2C oder A2B2C2D ensteht. Die Fachleute haben dafür fast immer einen festen Begriff - schönes Beispiel ist die Relation, die bei den Logistikern eine Lieferbeziehung zwischen zwei Orten bezeichnet.

Gruß Ralf