Ist diese Datenbankstruktur optimal?

[Frederic]

Hallo,

ich will mir eine Datenbank basteln (mysql), in die ich wöchentlich Spielernoten eintragen kann, um so am Ende der Saison oder auch über mehrere Saisons hinweg Statistiken zu führen oder ein schönes Nachschlagewerk zu haben.

Leider bin ich mir nicht ganz sicher, ob meine Datenbankstruktur optimal gewählt ist, weshalb ich hier mal um Hilfe nachfrage.

Letztlich sinds 3 Tabellen, die mir Sorgen bereiten:

1. Spielertabelle
SpielerID (primary key)
Name
Vorname
Geburtsdatum
Nationalität
Größe
Gewicht
usw.

2. Saisontabelle
SaisonID (primary key)
SpielerID (key)
Spielzeit
Verein
Trainer
Saisonanfang
Saisonende

3. Bewertunstabelle
BewertungsID (primary key)
SpielerID (key)
Bewertungsdatum
Gegner
Spieltyp (Pokal, Nationalelf oder Bundesliga)
Note
gelbe Karte (ja/nein)
rote Karte (ja/nein)
usw.

Wichtig wäre mir, die Spielertabelle beibehalten zu können, weil ich die Datenbank wirklich Spielerbasiert aufbauen möchte (und auch, weil ich die wesentlichen Scripte zur Tabelle bereits geschrieben habe), aber sind die 2. und 3. Tabelle günstig sortiert (auch im Hinblick auf Spielertransfers und garantierte Transfers in den nachfolgenden Jahren) oder gibts hierzu Verbesserungsvorschläge?

Grüße, Frederic

[Daniel Thoma]

Hallo Frederic,

Du hast also Spieler, Saisons und Bewertungen.
Bis jetzt hast Du Deine Datenbank so aufgebaut, dass eine Saisons und eine Bewertung jeweils zu einem Spieler gehören.
Gerade das mit der Saison scheint mir unpassend, sollte es nicht eher so sein, dass eine Bewertung zu einem Spieler und einer Saison gehört?

Du solltest versuchen die Relationen zu erkennen, die zwischen den Objekten (Spieler, Saisons, Bewertung) bestehen, und ob diese wirklich direkt sind oder sich aus anderen ergeben.
Ich würde z.B. vermuten, dass es für einen Spieler viele Bewertungen aber für eine Bewertung einen Spieler gibt, und dass das bezüglich Saison und Bewertung genau so ist.
Zwischen Saison und Spieler gibt es zwar auch eine Relation, die sollte sich aber aus der zwischen Bewertung und Saison und Spieler und Saison ergeben.

Wenn Du etwas theoretische Hintergrundinformation haben willst sind vielleicht http://de.wikipedia.org/wiki/Relation_(Datenbank) und http://de.wikipedia.org/wiki/Normalisierung_(Datenbank) brauchbare Einstiegspunkte.

Grüße

Daniel

[Frederic]

Hallo Frederic,

Hallo Daniel,

Du hast also Spieler, Saisons und Bewertungen.

sowie die Unterscheidung zwischen Bundesligaspiel, Pokalspiel und einem Spiel für die Nationanmanschaft des Spielers.

Bis jetzt hast Du Deine Datenbank so aufgebaut, dass eine Saisons und eine Bewertung jeweils zu einem Spieler gehören.

Hatte auch schon andere Modelle, die mir aber auch irgendwie unpassend erschienen. Deshalb bin ich jetzt mal mit diesem Model fragenderweise hier ins Forum rein.

Gerade das mit der Saison scheint mir unpassend, sollte es nicht eher so sein, dass eine Bewertung zu einem Spieler und einer Saison gehört?

...und zum Spieltyp. Ja, genau so hatte ichs gedacht.

Du solltest versuchen die Relationen zu erkennen, die zwischen den Objekten (Spieler, Saisons, Bewertung) bestehen, und ob diese wirklich direkt sind oder sich aus anderen ergeben.

Daran knacke ich nun schon den ganzen Tag und sehe inzwischen vor Bäumen den Wald nicht mehr.

Ich würde z.B. vermuten, dass es für einen Spieler viele Bewertungen aber für eine Bewertung einen Spieler gibt,

absolut.

»»und dass das bezüglich Saison und Bewertung genau so ist.

Als Gesamtbewertung meinst Du? Ja, so ist es gedacht.

Zwischen Saison und Spieler gibt es zwar auch eine Relation, die sollte sich aber aus der zwischen Bewertung und Saison und Spieler und Saison ergeben.

Hatte ich nur gemacht, weil ich ja auch den Verein und sewinen Trainer einem Spieler für eine bestimmte Saison zuordnen will.

Wenn Du etwas theoretische Hintergrundinformation haben willst sind vielleicht http://de.wikipedia.org/wiki/Relation_(Datenbank) und http://de.wikipedia.org/wiki/Normalisierung_(Datenbank) brauchbare Einstiegspunkte.

Danke für die Links, ich schau sofort mal rein.

Dennoch nochmal die Frage: Wie würdest Du die Tabellen wählen, ausgehend davon, daß die Spielertabelle bestehen bleibt?

Grüße, Frederic

Grüße

Daniel

[Daniel Thoma]

Hallo Frederic,

Daran knacke ich nun schon den ganzen Tag und sehe inzwischen vor Bäumen den Wald nicht mehr.

Also ich würde sowas vorschlagen:

Spieler <-- 1:n --> Bewertung <-- n:1 --> Saison

A <-- 1:n --> B liest sich als "1 A hat n B" (n im Sinne von beliebig viele). Eine improvisierte Variante von < ER-Modellen http://de.wikipedia.org/wiki/Entity-Relationship-Modell>
Sowas ist ganz nett, um einen überblick zu bekommen. Es gibt da Zick Varianten mit viel Blabla dazu, aber im wesentlichen reduziert es sich auf eine grafische Notation der Beziehungen wie ich es hier gemacht habe

Ein Spieler hat also viele Saisons in denen er spielt und viele Bewertungen, die er bekommt.

Daraus ergeben sich nun direkt die Tabellen:

Spieler
---------------------
id      primary key
...     weitere daten

Saison
---------------------
id      primary key
...     weitere daten

Bewertung
---------------------
id      primary key
spieler ref(Spieler.id)
saison  ref(Saison.id)
...     weitere daten

Das ist natürlich ein sehr einfaches Modell. Es gibt ja z.B. gar kein Spiel in diesem Modell. Es wäre also erstmal sinnvoll, möglichst alle wichtigen Objekte zu identifizieren. Womöglich sind die jetzt identifizierten Relationen eigentlich nur indirekt und eine Bewertung ist nur über ein Spiel mit einer Saison verknüpft.

Zwischen Saison und Spieler gibt es zwar auch eine Relation, die sollte sich aber aus der zwischen Bewertung und Saison und Spieler und Saison ergeben.
Hatte ich nur gemacht, weil ich ja auch den Verein und seinen Trainer einem Spieler für eine bestimmte Saison zuordnen will.

Hier wird es etwas komplizierter. Erstmal gibt es Trainer, womöglich können Trainer auch noch gleichzeitig irgendwo Spieler sein. Vielleicht sollte man Personen extra modellieren und Spieler und Trainer nur als darauf verweisende Rollen betrachten? Da tun sich einige Fragen auf, die Du Dir erstmal stellen solltest.

Zum eigentlichen Problem. Für Spieler gibt es Daten, die von der Saison abhängen. Die Eigenschaften kann man daher weder dem Spieler noch der Saison zuordnen. Also denken wir uns eben ein neues Objekt "Vereinszugehoerigkeit" oder sowas aus.
Eine Vereinszugehoerigkeit hat nun offensichtlich Beziehungen zu einem Spieler, einem Verein und einer, oder besser vielleicht mehrerer Saisons.
Der Trainer ist eine Eigenschaft des Vereins, nicht der Zugehörigkeit.
Du kannst Dir das ja mal als Bild aufmalen ich schreib mal direkt Tabellen hin:

Verein
-------------------
id       primary key
trainer  ref(Trainer.id), ref(Person.id), String, oder was immer der Anwendung angemessen ist.
...

Vereinszugehoerigkeit
-------------------
id       primary key
spieler  ref(Spieler.id)

VereinszugehoerigkeitZuSaison
-------------------
zugehoerigkeit  ref(Vereinszugehoerigkeit.id)
saison          ref(Saison.id)

Das letzte ist eine reine Zuordnungstabelle, die man braucht um n-zu-n-Relationen abzubilden.
Bei normalen Tabellen repräsentiert ja eine Zeile ein Objekt und die Relationen zwischen Objekten sind irgendwie mit darin verstaut. (Über Fremdschlüssel)
Im Falle dieser Zuordnungstabellen wird nur die Relation dargestellt.

Deine Postings wären übrigens angenehmer zu lesen, wenn Du nicht ganz so viele Absätze machen würdest ;-)

Grüße

Daniel

[Frederic]

Hallo Frederic,

Hallo Daniel,

Erstmal vielen Dank für Deine ausführliche Antwort und die Mühe.

Hm. Irgendwie raff ichs trotzdem nicht vollständig und hab schon den ganzen Abend darüber sinniert, sowie mir jede Menge Stoff über Normalisierung und Beziehungsmodelle in Datenbanken durchgelesen. :-(

Spielertabelle ist klar. Saisontabelle schon nicht mehr. Warum kann ich nicht in die Saisontabelle als Beziehungsschlüssel die SpielerID eintragen und gleich auch noch den Verein? Wobei, sicher würde das die Tabelle Saison mal so richtig aufblähen.

Aber die Bewertungstabelle: Kann ich dort nicht einfach die Spiele mit eintragen? Also:

Bewertung
---------------------
 id      primary key
 spieler ref(Spieler.id)
 saison  ref(Saison.id)
 spielgegner
 spieltyp (Pokal,BL,National)
 usw.

Die Trainergeschichte kann ich rauslassen, die ist nicht so wichtig.

Bleibt noch die Tabelle Vereinszugehörigkeit, die ich wieder verstehe.

Siehst Du irgendwelche gravierenden Nachteile bei diesem Datenbankmodell?

Grüße, Frederic

[EKKi]

Mahlzeit,

Aber die Bewertungstabelle: Kann ich dort nicht einfach die Spiele mit eintragen? Also:

Bewertung

id      primary key
spieler ref(Spieler.id)
saison  ref(Saison.id)
spielgegner
spieltyp (Pokal,BL,National)
usw.

Siehst Du irgendwelche gravierenden Nachteile bei diesem Datenbankmodell?

Also zumindest ich ja. Was ist, wenn Du mehrere Spieler, die an diesem Spiel teilgenommen habe, bewerten willst? Dann hättest du wieder redundante Informationen in der Bewertungstabelle. Mach lieber eine Tabelle "Spiele", trage dort die relevanten Daten dieser Begegnung ein und packe in die Tabelle "Bewertung" eine Referenz zum entsprechenden Spiel.

MfG,
EKKi

[Frederic]

Also zumindest ich ja. Was ist, wenn Du mehrere Spieler, die an diesem Spiel teilgenommen habe, bewerten willst? Dann hättest du wieder redundante Informationen in der Bewertungstabelle.

Hallo EKKi,
Redundant heißt, mehrfach vorhanden abgespeicherte Informationen? Ok. Stimmt. Ist ein Nachteil. Danke.

Mach lieber eine Tabelle "Spiele", trage dort die relevanten Daten dieser Begegnung ein und packe in die Tabelle "Bewertung" eine Referenz zum entsprechenden Spiel.

Ja, guter hinweis. Hätt ich auch selber drauf kommen dürfen :-)

Danke, Frederic

MfG,
EKKi

[Frederic]

Hallo an alle am Thread Beteiligten,

ich habe versucht, alle Eure Tips und Hinweise in die Tabellenstruktur einfließen zu lassen und habe sämtliche Tabellen neu überarbeitet.

Wäre nett, wenn Ihr mal einen Blick über den (gekürzten) mysql-Dump werft, um mir zu sagen, obs gelungen ist oder immer noch Verbesserungen möglich sind.

Viele Grüße, Frederic

CREATE TABLE prefix_saison (
  SaisonID int(6) NOT NULL auto_increment,
  SaisonName varchar(50) NOT NULL default '',
  PRIMARY KEY  (SaisonID)
) TYPE=MyISAM;

--------------------------------------------------------

CREATE TABLE prefix_verein (
  VereinID int(6) NOT NULL auto_increment,
  SaisonID int(5) NOT NULL default '0',
  VereinTrainer varchar(100) NOT NULL default '0',
  PRIMARY KEY  (VereinID),
  KEY SaisonID (SaisonID)
) TYPE=MyISAM;

--------------------------------------------------------

CREATE TABLE prefix_vereinzugehoerigkeit (
  VereinzugehoerigkeitID int(5) NOT NULL auto_increment,
  SpielerID int(5) NOT NULL default '0',
  SaisonID int(5) NOT NULL default '1',
  PRIMARY KEY  (VereinzugehoerigkeitID),
  KEY SpielerID (SpielerID),
  KEY SaisonID (SaisonID)
) TYPE=MyISAM;

--------------------------------------------------------

CREATE TABLE prefix_spiele (
  SpielID int(5) NOT NULL auto_increment,
  SaisonID int(5) NOT NULL default '0',
  VereinID int(5) NOT NULL default '0',
  SpielDatum int(20) NOT NULL default '0',
  SpielTyp varchar(100) NOT NULL default '',
  SpielGegner varchar(255) NOT NULL default '',
  PRIMARY KEY  (SpielID),
  KEY SaisonID (SaisonID),
  KEY VereinID (VereinID)
) TYPE=MyISAM;

--------------------------------------------------------

CREATE TABLE prefix_Spielerbewertung (
  SpielerNotenID int(5) NOT NULL auto_increment,
  SpielerID int(5) NOT NULL default '0',
  SpielID int(5) NOT NULL default '0',
  SpielerNote int(5) NOT NULL default '0',
  PRIMARY KEY  (SpielerNotenID),
  KEY SpielerID (SpielerID),
  KEY SpielID (SpielID)
) TYPE=MyISAM;

--------------------------------------------------------

[Daniel Thoma]

Hallo Frederic,

Was mir auf den ersten Blick aufgefallen ist:

• Verein hat eine direkte Beziehung zu Trainer und Saison. Willst Du da einem Verein für eine Saison ein Spieler zuordnen? Wenn ja, dann solltest Du das wie bei der Vereinszugehörigkeit modellieren (Trainervertrag oder sonst was). Sonst kannst Du keinen Trainerwechsel abbilden.
• Spiel hat nur eine Beziehung zu einem Verein. Sind da nicht zwei beteiligt? Ergibt sich zudem der Verein nicht schon indirekt über Bewertung und Spieler?
• Wieso gibt es bei Spiel ein Feld "Spielgegner" sollte da nicht irgend ein Fremdschlüssel stehen?

Grüße

Daniel

[Ilja]

yo,

Zwischen Saison und Spieler gibt es zwar auch eine Relation, die sollte sich aber aus der zwischen Bewertung und Saison und Spieler und Saison ergeben.

Eine Relation ist eine Tabelle und keine Beziehung. Was du meinst ist Relationship.

Ilja

[Daniel Thoma]

Hallo Ilja,

Eine Relation ist eine Tabelle und keine Beziehung. Was du meinst ist Relationship.

Wenn man klugscheißen will, sollte man es können.

"Relationship" ist überhaupt kein deutsches Wort, eigentlich auch kein deutsches Fachwort, als Fachwort wird es ab und an in "Entity-Relationship-Modell" verendet.

Eine Relation ist im allgemeinsprachlichen gebrauch erstmal einfach eine Beziehung. Siehe dazu auch: http://de.wikipedia.org/wiki/Relation
Im Englischen gibt es in dieser Bedeutung sowohl Relation als auch Relationship, mit etwas unterschiedlichem Sprachgebrauch der aber in diesem Technischen zusammenhang unbedeutend ist.

Es gibt nun auch ein mathematisches Konzept der Relation, das Analog zur allgemeinsprachlichen Bedeutung des Begriffs eben eine Beziehung zwischen zwei oder mehreren Objekten bezeichnet: http://de.wikipedia.org/wiki/Relation_(Mathematik)

Ich habe mich in meiner Antwort im Bereich der Analyse des Problems bewegt, es ging mir also erstmal um ein abstraktes Verständnis von Objekt und Relation.

Nun kommen wir zu den Datenbanken. Relationen werden dort tatsächlich technisch als Tabellen realisiert: http://de.wikipedia.org/wiki/Relation_(Datenbank)
Wenn Du mal versuchst, aus Deinen "Relationships" eine Datenbank zu basteln, wirst Du merken, dass es da plötzlich auch nur noch Tabellen gibt. Tabellen sind nichts anderes als die technische Abbildung von Relationen (also Beziehungen) zwischen den Werten der Einträge.

Etwas schwierig wird es, weil man die oft gemachte unterscheidung zwischen Attributen von Objekten und Relationen zwischen Objekten in Tabellen nicht mehr klar erkennt. Das liegt im wesentlichen daran, dass es eine solche Unterscheidung im abstrakten Sinne nicht gibt.

Es wäre mir recht, wenn Du zukünftig etwas besser recherchieren und Deine Ansichten gründlicher belegen würdest, wenn Du schon meinst, mich belehren zu müssen.

Grüße

Daniel

[Ilja]

yo,

Im Englischen gibt es in dieser Bedeutung sowohl Relation als auch Relationship, mit etwas unterschiedlichem Sprachgebrauch der aber in diesem Technischen zusammenhang unbedeutend ist.

dann sind wir uns zumindestents in diesem bezug einig, das man nicht einfach zu leo surfen kann, das wort relation eingibt und dann schaut, was rauskommt. Selbst wenn das wort mit beziehung übersetzt wird, somit ist damit noch nicht geklärt, um welche beziehungen es sich letztlich handelt. es gibt nämlich nicht nur beziehungen zwischen den E/R Objekten, sondern auch welche innerhalb einer tabelle.

Es gibt nun auch ein mathematisches Konzept der Relation, das Analog zur allgemeinsprachlichen Bedeutung des Begriffs eben eine Beziehung zwischen zwei oder mehreren Objekten bezeichnet: http://de.wikipedia.org/wiki/Relation_(Mathematik)

das lese ich anderes, wobei ich auch kein mathematiker bin. ich zitiere mal die definition von relationen, die dort angegeben wurde: "eine Relation R ist eine Menge von n-Tupeln. Dinge, die in der Relation R zueinander stehen, bilden ein n-Tupel, das Element von R ist."

ein tupel entspricht einem datensatz, demzufolge ist eine menge von datensätze eine tabelle, bzw. eine relation.

verwirent ist sicherlich, dass in diesem kapitel im zusammenhang zwischen beziehungen von zwei dingen gesprochen wird. damit ist aber nicht die bezieung in einem E/R modell zwischen zwei objekten die rede, sondern die beziehungen innerhalb der tabelle (x/y).

nun kommen wir aber zu dem Kontext, in dem ich behaupte, relationensind tabellen und beizehungen sind relationships, nämlich im bereich der rdbms. und dort steht es eigentlich schwarz auf weis, wass relationen sind. ich denke, da ist wenig raum für missverständnisse. ich zitiere mal aus deinem link:

"Eine Datenbanktabelle entspricht so anschaulich einer Relation"

Wenn Du mal versuchst, aus Deinen "Relationships" eine Datenbank zu basteln, wirst Du merken, dass es da plötzlich auch nur noch Tabellen gibt. Tabellen sind nichts anderes als die technische Abbildung von Relationen (also Beziehungen) zwischen den Werten der Einträge.

wenn du folgendes zitat, wieder aus deinem link dir noch mal vor augen führst, dann sollte dir auch klar sein, wie bei rdbms beziehungen dargestellt werden, nämlich nicht über tabellen, sondern über fremdschlüssel. natürlich sind auch diese fremdschlüssel in tabelle untergerbacht. das liegt aber i der natur der sache, dass eben alles, selbst der systemkatalog in tabellen abgebildet werden.

oder mal anders ausgedrückt, um es deutlich zumachen. wenn du nur eine einzige tabelle hast (ohne selbstbezug), dann dürfte ich laut deiner aussage auch keine relation haben. schließlich gibt es ja keine weitere tabelle (von mir aus auch objekt), mit der es eine beziehung haben könnte. laut deinen eigenen quellen ist aber sehr wohl eine relation vorhanden. ich gebe dir mal die entscheidene stellle aus deinem link.

"Eine Relation beschreibt nicht den Zusammenhang zwischen verschiedenen Tabellen. Diese werden in Datenbanksystemen durch Fremdschlüssel beschrieben. Diese Beziehungen sind jedoch nicht Teil der Relationalen Algebra und haben auch nicht zur Namensgebung dieser beigetragen, wie dies oft fälschlich vermutet wird."

es gibt ein argument, dass macht es schwierig, dem entgegen zu wirken, nämlich dass die mehrheit unter relation eben eine beziehung versteht. fachlich gesehen ist das falsch, ich hoffe, da sind wir uns nun einig. wie man nun damit in der praxis umgeht, ist schon schwieriger zu beantworten. ich denke, es ist von vorteil beides zu wissen.

Es wäre mir recht, wenn Du zukünftig etwas besser recherchieren und Deine Ansichten gründlicher belegen würdest, wenn Du schon meinst, mich belehren zu müssen.

nun ja, was soll ich dazu sagen, ich habe deine eigenen quellen benutzt, um meine meinung zu stützen, dort steh die gleiche aussage, dass relationen tabellen sind 1:1 so wort wörtlich drin. keine ahnung, was dich sonst noch überzeugen soll

Ilja

[Daniel Thoma]

Hallo Ilja,

das lese ich anderes, wobei ich auch kein mathematiker bin. ich zitiere mal die definition von relationen, die dort angegeben wurde: "eine Relation R ist eine Menge von n-Tupeln. Dinge, die in der Relation R zueinander stehen, bilden ein n-Tupel, das Element von R ist."

Ja klar. Es gibt abstrakt gesehen keinen unterschied zwischen "Beziehung zwischen Elementen" und "Menge von Tupeln". Dieser unterschied ist ein rein Sprachlicher. Relationale Datenbanken heißen relational, weil sie Bezeihungen zwischen Elementen verwalten können, dahinter steht die relationale Algebra die Operationen auf Relationen/Beziehungen wir joins u.ö. formalisiert. Eine Relationship-Algebra gibt es nicht, weil es schlicht ein solches Konzept, das sich von dem der Relation unterscheiden würde, nicht gibt.

verwirent ist sicherlich, dass in diesem kapitel im zusammenhang zwischen beziehungen von zwei dingen gesprochen wird. damit ist aber nicht die bezieung in einem E/R modell zwischen zwei objekten die rede, sondern die beziehungen innerhalb der tabelle (x/y).

Wenn man sich die relationale Algebra ansieht, sind nicht nur die Basis-Relationen, die man typischerweise in Tabellen darstellt, Relationen, sondern eben auch die, die indirekt bestimmt werden, bspw. durch join-Operationen. Von der mathematischen Seite her ist das Thema wirklich absolut klar.

nun kommen wir aber zu dem Kontext, in dem ich behaupte, relationensind tabellen und beizehungen sind relationships, nämlich im bereich der rdbms. und dort steht es eigentlich schwarz auf weis, wass relationen sind. ich denke, da ist wenig raum für missverständnisse. ich zitiere mal aus deinem link:

Hm, ich hätte den Artikel wohl ganz lesen sollen um zu erkennen, dass er ziemlich dürftig ist ;-)
Fremdschlüssel sind natürlich keine Relationen in diesem sinne. Eine Relation ist erst, was man berechnet, wenn man mehrere Tabellen aggregiert um zwei verbundene Tabellen zusammen zu führen.
Auf diesen Zusammenhang geht der Datenbankartikel nicht ein.
Ich habe allerdings auch nie von Fremndschlüsseln geredet. Fremdschlüssel stellen im wesentlichen ja nur Gültigkeitsbedingungen für eine Datenbank dar.
Die Relation, die man berechnen würde, um einem Fremdschlüssel zu folgen, könnte man genau so gut explizit in der Datenbank darstellen (auch wenn diese natürlich dann nicht normalisiert wäre).

oder mal anders ausgedrückt, um es deutlich zumachen. wenn du nur eine einzige tabelle hast (ohne selbstbezug), dann dürfte ich laut deiner aussage auch keine relation haben. schließlich gibt es ja keine weitere tabelle (von mir aus auch objekt), mit der es eine beziehung haben könnte.

Natürlich, Objekte in diesem Sinne sind nicht Datensätze sondern einzelne Werte. Zwischen diesen Werten gibt es Relationen. Einige davon repräsentiert man explizit als Tabellen. Das versucht man natürlich optimal zu tun um keine redundante Information zu speichern.

"Eine Relation beschreibt nicht den Zusammenhang zwischen verschiedenen Tabellen. Diese werden in Datenbanksystemen durch Fremdschlüssel beschrieben. Diese Beziehungen sind jedoch nicht Teil der Relationalen Algebra und haben auch nicht zur Namensgebung dieser beigetragen, wie dies oft fälschlich vermutet wird."

Nein, die Fähigkeit mit Relationen zu rechnen, hat dazu beigetragen. Fremndschlüssel sind eigentlich ein unbedeutenderes Konzept. Man benötigt sie nur um die Zulässigkeit der Daten zu prüfen, nicht um irgendwelche Beziehungen zwischen den Daten zu berechnen.

es gibt ein argument, dass macht es schwierig, dem entgegen zu wirken, nämlich dass die mehrheit unter relation eben eine beziehung versteht.

Nein, aber nachdem ich nun auch noch den englischen Artikel dazu gelesen habe, verstehe ich glaube ich das Missverständnis.
Das mathematische Konzept der Relation ist eindeutig eine Formalisierung des Konzeptes der Beziehung zwischen Dingen (als Tupel, aber das ist nur die Formalisierung).
Die Darstellung dieses Konzeptes findet aber nicht in Form von Primär-/Fremdschlüsseln statt. Das habe ich auch nicht behauptet.
Allerdings ist es falsch, dass nur Tabellen Relationen sind. Sie sind die einzig explizit repräsentierten Relationen, das ist richtig.
Fremdschlüssel aber auch nicht notwendig für eine Datenbank. Man kann ganz toll Beziehungen ohne sie darstellen. Natürlich ist dann in der Datenbank nicht mehr Dokumentiert, was man gemeint hat und nicht sicher gestellt, dass die Bedingungen eingehalten werden. Aber es geht prinzipiell keine Information über die Daten verloren.

nun ja, was soll ich dazu sagen, ich habe deine eigenen quellen benutzt, um meine meinung zu stützen, dort steh die gleiche aussage, dass relationen tabellen sind 1:1 so wort wörtlich drin. keine ahnung, was dich sonst noch überzeugen soll.

Dass sie die technische Darstellung von Relationen sind, habe ich selbst überall gesagt.
Überzeugen würde mich eine Definition des Begriffes "Relationship". Es gibt natürlich eine im Kontext von ERDs. Dort kommt aber wiederum der Begriff "Relation" gar nicht vor.

Relationship scheint mir im wesentlichen der im Englischen gebräuchlichere Begriff für "Beziehung" in diesem Kontext zu sein.
Von Relation habe ich gesprochen, weil ich das Thema eher abstrakt angehen wollte und erstmal den Blick von der Technik und dem Denken in Tabellen und Schlüsseln lösen wollte.
Mein Fokus lag also klar auf dem mathematischen Konzept der Relation und damit habe ich schon des öfteren Beziehungen modelliert ;-)

Ich habe den Eindruck, dass die ganze Diskussion im wesentlichen auf dem basiert, was mir manchmal als die Krankheit der Datenbankwelt erscheint.
Es gibt da unzählige technische Begriffe, Tabelle, Attribute, Fremdschlüssel, Vererbung (ja das machen DBs ja mittlerweile auch), Komponenten, Schemata, und was der Teufel noch alles und oft merkt keiner mehr, dass das alles Dinge sind, die man mathematisch schlicht als Relation modellieren würde.

Grüße

Daniel

[Daniel Thoma]

Ah noch ein Nachtrag:

A Relational Model of Dta for Large Shared Data Banks, Codd, 1970:
"Associated with a data bank are two collections of relations: the named set and the expressible set" The named set is the collection of all those relations, that the community of users can identify by means of a simple name (or idenftifier) [...] The expressible set is the total collection of relations that can be designated by expressions in the data language. Such expressions are constructed form simple names of relations in the named set, names of generations, roles, and domains, logical connectives, the quantifiers of the predicate calculus an certain constant relation symbols such as =, >. The named set is a subset of the expressible set - usually a very small set"
Tatsächlich gespeicherte Relationen werden als Stored Relations (oder Tabellen) bezeichnet.
"Named Relations" meint wohl so etwas wie Views.
Interessant für unsere Diskussion finde ich vor allem die Bemerkung, dass "Expressable Relations" unter anderem solche sind, die sich aus "logical connectivities" ergeben.
Relationen in diesem Sinne sind also genau alle Bezeihungen in den Daten die durch die Datenbank repräsentiert werden. Das trifft eigentlich ziemlich genau das, was ich meine.

Der zitierte Artikel hat das Gebiet der RDBMS wohl praktisch begründet. Nachzulesen ist er unter anderem hier http://www.cs.nott.ac.uk/~nza/G51DBS/codd.pdf

Grüße

Daniel

[Ilja]

yo,

"Named Relations" meint wohl so etwas wie Views.

meiner meinung nach sind die "named relations" die tabellen in einer datenbank und "Expressable Relations" ist die menge aller möglichen  ergebnis-tabellen, die durch eine datenbanksprache erzeugt werden können. oder anders gesagt, eine abfrage hat auch immer wieder eine tabelle als ergebnis und die sind eben die "Expressable Relations"

Ilja

[Ilja]

yo,

Relationale Datenbanken heißen relational, weil sie Bezeihungen zwischen Elementen verwalten können,

das ist falsch, relationale datenbanken. bzw. relationale datenbankmanagmentsysteme heissen so, weil sie auf tabellen basieren. es gab vorher schon andere datenbankmodelle wie hierachische, bzw. netzwerk Datenbanken, die auch schon beziehungen abbilden konnten, die neuerung bei rdbms besteht darin, nicht beziehungen abbilden zu können, sondern auf den mengenlehre zu basieren und alles in tabellen abzubilden.

Hm, ich hätte den Artikel wohl ganz lesen sollen um zu erkennen, dass er ziemlich dürftig ist ;-)

diese aussage, nachdem du behauptet hast, ich sollte besser recherchieren, bevor ich dich korregiere ? merkwürdig, merkwürdig. ;-)

Eine Relation ist erst, was man berechnet, wenn man mehrere Tabellen aggregiert um zwei verbundene Tabellen zusammen zu führen.

woher hast du diese aussage ? ich kann keine quellen dazu finden, die solches behaupten würden.

Fremdschlüssel stellen im wesentlichen ja nur Gültigkeitsbedingungen für eine Datenbank dar.

nein, das ist die referentielle integrität. es gibt aber auch fremdschlüssel, ohne eine solche gültigkeitsprüfung.

Fremndschlüssel sind eigentlich ein unbedeutenderes Konzept. Man benötigt sie nur um die Zulässigkeit der Daten zu prüfen, nicht um irgendwelche Beziehungen zwischen den Daten zu berechnen.

fremdschlüssel sind bei rdbms ein wesentliches konzept, das eben die relationships der einzelnen relationen abbildet.

Allerdings ist es falsch, dass nur Tabellen Relationen sind.

doch, bei rdbms und im kontext von datenbanken ist es so.

Fremdschlüssel aber auch nicht notwendig für eine Datenbank. Man kann ganz toll Beziehungen ohne sie darstellen.

dann bin ich gespannt, wie willst du ohne einen einzigen fremdschlüssel, eine beziehung in rdbms darstellen ?

Überzeugen würde mich eine Definition des Begriffes "Relationship". Es gibt natürlich eine im Kontext von ERDs. Dort kommt aber wiederum der Begriff "Relation" gar nicht vor.

aber da kommt das wort relationship vor. und was macht wohl ein E/R Modell ? genau es stellt die einzelnen entitäten (objekte da) und deren beziehungen (Relationships). selbst da kann man erkennen, dass relationship für beziehungen der entitäten steht und nicht relation.

Ilja

[Chris]

Hallo,

da scheint noch nicht ganz klar zu sein, welche Eigenschaften einwertig und welche mehrwertig sind.

LG
Chris

[Frederic]

Hallo,

da scheint noch nicht ganz klar zu sein, welche Eigenschaften einwertig und welche mehrwertig sind.

LG
Chris

Hallo Chris,

umso froher bin ich, nicht einfach so weitergemacht zu haben, sondern mal vorsichtig hier nachgefragt zu haben.

Du meinst den Beziehungstyp zwischen Tabellen?

1:1 1:m m:m usw.??

Grüße, Frederic