Welche Datenbankschemata vereinfacht die Verwaltung und die Aktualisierung dieser Daten

[jetwork]

Die DATE Felder in Vorlesung und Dozent sind redundant und überflüssig. Diese Informationen lassen sich über die tbl_Beziehungen bilden.

Einfach mal einen sehr herzlichen vielen Dank

Ich brauche genau das. Ich weiß aber nicht wie ich das machen kann.

Hier ist mein dumme Vorschlag. Ich kann mir leider nichts besseres denken:


Wie macht man aber die Abfragen? Wie kann ich z. B. die Beziehungen von Jahr 2012 abrufen?

 

[Hony%]

Wie macht man aber die Abfragen? Wie kann ich z. B. die Beziehungen von Jahr 2012 abrufen?

Angenommen du hast folgende 3 Tabellen:

sqlite> SELECT * FROM tbl_dozent;
1|Hubert
2|Mayer
3|Schmidt

sqlite> SELECT * FROM tbl_beziehung;
1|1|01-06-2010|31-05-2013
2|2|01-06-2010|
3|3|01-06-2013|

sqlite> SELECT * FROM tbl_vorlesung;
1|Datenbankdesign
2|Relationale Algebra
3|Der Join im Wandel der Zeit

Die Tabelle tbl_beziehung enthält bei beziehung_ende NULL Werte da die Vorlesung weiterhin angeboten wird.

Du kannst alle Vorlesungen die im Jahr 2012 angeboten wurden hiermit abfragen:

sqlite> SELECT dozent_name, vorlesung_name
   ...> FROM tbl_beziehung
   ...> INNER JOIN tbl_dozent
   ...>     ON dozent_ref = dozent_id
   ...> INNER JOIN  tbl_vorlesung
   ...>     ON vorlesung_ref = vorlesung_id
   ...> WHERE beziehung_start <= '01-06-2012'
   ...> AND (beziehung_ende >= '31-05-2013' OR beziehung_ende IS NULL);
Hubert|Datenbankdesign
Mayer|Relationale Algebra

Ob die letzte Abfrage funktioniert hängt sehr vom DBMS ab. Aber der grundsätzliche Ansatz sollte klar sein denke ich.

 

[ukulele]

Auf jeden Fall nur eine Datenbank für alle Daten.

Im wesentlichen hat Hony% recht. Jede Beziehung die NULL als Endatum hat ist gültig sofern das Anfangsdatum nicht in der Zukunft liegt. Ergänzend gilt die Bedingung von wann bis wann das Semester für die Abfrage gebraucht wird. Also wenn du wissen willst was genau jetzt an Semester-Kursen verfügbar ist kannst du z.B. mit getdate() arbeiten:

SELECT    dozent_name,
        vorlesung_name
FROM    tbl_beziehung
INNER JOIN tbl_dozent
ON        dozent_ref = dozent_id
INNER JOIN tbl_vorlesung
ON        vorlesung_ref = vorlesung_id
WHERE    beziehung_start <= getdate()
AND    (    beziehung_ende >= getdate()
OR        beziehung_ende IS NULL )

 

[Hony%]

Jede Beziehung die NULL als Endatum hat ist gültig sofern das Anfangsdatum nicht in der Zukunft liegt.

So weit würde ich nicht einmal gehen. Was spricht dagegen eine geplante Vorlesung für 2015 einzutragen? Letztendlich kommt es natürlich auf die Anforderungen an.

 

[ukulele]

Mit Gültig meinte ich soll ausgewählt werden wenn man nach aktuell vorhandenen Kursen sucht. Natürlich kann man die schon für die Zukunft eintragen.

 

[jetwork]

Danke schön. Ihr habt mir unheimlich viel geholfen.

Jetzt noch eine Frage. Ich habe dieses Problem in mehrere Stellen in meiner Datenbanken. Deswegen möchte ich noch eine Allgemeine Frage stellen. Dieses mall Tabelle A, B und C sind Tabellen die einmal im Jahr aktualisiert werden müssen und wie immer die historischen Beziehungen müssen in meiner Datenbank bleiben. Die Beziehungen zwischen Tabellen ändern sich in gleichen zeitscheiben falls sie sich ändern.

Welchen der folgenden Schemas würdet ihr benutzen? Welche vor und Nachteile haben diese Scenarios?

Scenario 1:

Scenerio 2:

 

[ukulele]

Beide Szenarien können sinnvoll sein. Wenn es dir um die Abbildung der Studenten geht wäre es aber definitiv die #2 denn auf eine Dozenten-Beziehung kommen vieleicht 50 oder 100 Studentenbeziehungen. Würdest du Variante #1 wählen, hättest du 50 oder 100 mal den Dozenten FK in der Beziehungstabelle. Das wäre falsch weil redundant, es müssten sich mehr Datensätze ändern bei einem Update und plötzlich brauchst du auch 2 Zeiträume denn für was gilt beziehung_start und _ende? Für den Dozenten oder für den Studenten?

 

[jetwork]

Ich habe am meisten fälle die Folgende Relationen:
Beziehungen zwischen Elementen A, B, C sind one to many. Ein Element A hat mindestens ein Element B oder mehrere Element B. Ein Element B hat mindestens ein Element C oder mehrere C.

 

[jetwork]

Danke @ukulele Ich glaube für diese Relationen soll ich das zweiten Szenerio nehmen oder?
Und das allgemeine Ziel ist die Anzahl der Datensätze in der Beziehungstabelle so gering wie möglich halten oder?

 

[ukulele]

Ja das denke ich.

 

[Hony%]

Es gibt eigentlich nur einen Anwendungsfall für Szenario 1. Nämlich dann, wenn sich eine(C) der drei Relationen auf die Relation zwischen den anderen Beiden(A,B) bezieht.

Angenommen beziehung_start und beziehung_ende würden sich immer auf ein Semester beziehen und gelten daher für zum Beispiel alle Vorlesungen des Jahrgangs 2012 würden sich bei 50 Vorlesungen 50 mal die gleichen redundanten Daten in der Datenbank finden. Hier wäre es sinnvoll eine Tabelle Semester anzulegen und per Fremdschlüssel zu referenzieren.

Dein Fall von Dozent<>Vorlesung<>Student ist eigentlich eindeutig. Dem Dozenten dürfte es im Grunde egal sein welche Studenten in der Vorlesung sitzen und die Studenten interessieren sich bestenfalls auf sozialer Ebene für ihren Dozenten. Fachlich ausgedrückt besteht zwischen Dozent und Student nur eine transitive funktionale Abhängigkeit.

Und das allgemeine Ziel ist die Anzahl der Datensätze in der Beziehungstabelle so gering wie möglich halten oder?

Als Faustregel gilt: Nur so viele Datenbanken, Tabelle, Attribute, Constraints wie unbedingt nötig.

Die Anzahl der Datensätze innerhalb einer Relationentabelle hängt auch davon ab welcher Sachverhalt abgebildet werden soll. In deinem ersten Ansatz wolltest du folgenden Sachverhalt abbilden:

Vorlesung 1 (2010) <> Dozent 1
Vorlesung 1 (2011) <> Dozent 1
Vorlesung 1 (2012) <> Dozent 1
Vorlesung 1 (2014) <> Dozent 2

Der jetzige bildet eher das hier ab:

Vorlesung 1 (2010-2012) <> Dozent 1
Vorlesung 1 (2014-) <> Dozent 2

Abhängig davon ob man eine Vorlesung als pro Semester eigenständiges oder unbefristetes Ereignis ansieht ergeben sich aus beiden Ansätzen unterschiedliche semantische Aussagen. Während sich im ersten Fall problemlos zusätzliche, nach Jahrgang spezifische, Informationen speichern lassen wird ein solches Vorhaben im zweiten Fall deutlich komplizierter.

Unabhängig davon lassen sich zum Beispiel beim ersten Ansatz historische Daten über das Sicherheitssystem einer Datenbank vor unbefugten Veränderungen schützen. Der zweite Ansatz macht das annähernd unmöglich. Aber da ist ein ganz anderes Thema.

 

[jetwork]

Die 2 Szenario habe ich umgesetzt aber bekam ich das folgende Problem:
Ich möchte Dozenten mit der Vorlesungen zuzuordnen. Wie schon erwähnt manchmal ändert sich der Dozent einer Vorlesung aber die Vorlesung Ids bleibt unverändert.
Wie soll ich für die Tabelle Vorlesungen einen Primär Schlüssel wählen? Soll ich noch eine Spalte für Jahr hinzufügen und Jahr und Vorlesungsid beide zusammen als primärer Schlüssel wählen. Gibt es bessere Lösungen?

 

[Hony%]

Deine Vorlesungsid ist doch schon ein künstlicher Primärschlüssel und dient doch dem Zweck einen einspaltigen Schlüssel zu liefern.

sqlite> SELECT * FROM tbl_beziehung;
1|1|01-06-2010|31-05-2013
2|2|01-06-2010|
3|3|01-06-2013|

In diesem Beispiel habe ich doch schon gezeigt wie die Zuordnung funktioniert. Was genau kannst du damit nicht abbilden?

 

[jetwork]

Sorry. Ich sollte ausführlicher schreiben.
Die Vorlesungen haben schon eine Vorlesungsnummer. Die Vorlesungsnummer muss ich auch in der Tabelle speichern. Ich wollte es einfach als primärer Schlüssel benutzen. Ich habe aber bemerkt bei diesem Ansatz, ist diese Spalte nicht mehr eindeutig.
z. B. Es kann sein dass der Name einer Vorlesung in einem neuen Jahr geändert wird aber die Vorlesungsid bleibt gleich. In diesem Fall soll ich noch ein Eintrag in der Vorlesungstabelle mit dem neuen Name aber mit der gleichen Vorlesungsid erstellen. Dann ist die Vorlesungsid nicht mehr eindeutig.

Mein Vorschlag ist noch eine Spalte für Jahr zu erstellen. Wenn ich einen neuen Eintrag hinzufüge, muss ich auch hinzufügen ab welches Jahr dieser Eintrag gilt und danach die beide spalten zusammen werde ich als primär Schlüssel benutzen. Ich weiß aber nicht wie ich später die Tabelle Dozenten über die Beziehungstabelle mit diese beide Spalten in Verbindung setzen kann. Ich glaube es ist nicht möglich oder?
Muss ich sowieso selbst ein Primärschlüssel generieren?

 

[Hony%]

z. B. Es kann sein dass der Name einer Vorlesung in einem neuen Jahr geändert wird aber die Vorlesungsid bleibt gleich. In diesem Fall soll ich noch ein Eintrag in der Vorlesungstabelle mit dem neuen Name aber mit der gleichen Vorlesungsid erstellen. Dann ist die Vorlesungsid nicht mehr eindeutig.

Eine neue oder geänderte Vorlesung führt in einem solchen Fall auch zu einer neuen ID. In dem von dir vorgestellten Entwurf ist die ID auch nur dann sinnvoll wenn vergleichbare Vorlesungen mit gegebenenfalls gleichem Namen unterschieden werden sollen.

Wenn Dozent A von 2010-2012 die Vorlesung 1|X hält und ab 2013 die Vorlesung 2|X oder 2|X-Y lässt sich das problemlos abbilden. Dein Problem ergibt sich aus der Anforderung heraus historische Daten zu erhalten. Würdest du hingegen nur den Ist-Zustand verwalten wollen würde es reichen 1|X in 1|X-Y umzubenennen.

Wenn du abbilden willst, dass Vorlesung 2|X aus 1|X hervorgegangen ist kannst du das mit einem zusätzlichen Attribut in tbl_vorlesung machen. Dabei setzt du einfach einen optionalen Fremdschlüssel auf die ID der selben Relation.