Welche Datenbankschemata vereinfacht die Verwaltung und die Aktualisierung dieser Daten

[jetwork]

Hallo Zusammen,

Ich habe eine neue Frage ähnlich wie meine letzte Frage.
Ich erstelle gerade eine Datenbank für das Vorlesungsverzeichnis einer Universität.

Es gibt eine Tabelle namens Dozenten und eine Tabelle namens Vorlesungen. Für jedes Jahr ändert sich ein Teil der Vorlesungen. Manchmal kommen neue Vorlesungen, manchmal ändert man die Namen einige Vorlesungen. Manchmal sind einige Vorlesungen nicht mehr angeboten.
Es passiert auch natürlich, dass eine Vorlesung bei einem anderen Dozent gehalten werden soll. Ich meine, die Beziehungen zwischen Dozenten und Vorlesungen ändern sich auch und natürlich der Inhalt der Tabelle von Dozenten ändert sich auch.
Es ist für uns auch wichtig alle Jahrgänge später zurückrufen zu können. Jetzt werde ich in der Datenbank alle Daten ab 2010 bis jetzt importieren. Später werden wir diese Datenbank jeder Jahrgang immer aktualisieren. Ich meine, die historischen Daten müssen auch in der Datenbank bleiben. Ich bekomme alle Daten in Excel Tabellen und importiere sie in die Datenbank und %90 der Daten bleiben unverändert.

Bis jetzt habe ich die folgenden Tabellen vorbereitet und die Excel Tabellen vom Jahr 2010 schon importiert.
tbl_dozent
dozent_id
dozent_name
usw.

tbl_beziehungen
dozent_ref
vorlesung_ref
jahrgang

tbl_vorlesung
vorlesung_id
beschreibung
usw.

Wenn das Datenbankschema so ist. Müssen wir für jeden Jahrgang die ganze Daten nochmal importieren. Wie gesagt, %90 der Daten bleiben aber eigentlich unverändert, deswegen wollen sie nicht jeder Jahrgang alle Daten nochmal importieren. Sie wollen die Anzahl der Datensätze kleiner halten und den Aufwand zum Importieren verringern. Deshalb wollen sie ein Schemata dass sie für jedes Jahr nur die Änderungen aktualisieren sollen. Was wäre eine bessere Vorgehensweise.

Meine Fragen:
Erstens: Ist es wirklich sinnvoll nur die Änderungen zu speichern oder macht man wie ich es schon gemacht habe? Wenn ja ich kann darauf bestehen, dass meine Lösung schon sinnvoll ist.

Zweitens: Wie kann ich für jeden Jahrgang nur die Änderungen speichern?



Danke im Voraus,

 

[ukulele]

Wenn du nur Änderungen speichern willst musst du die Beziehungen sowie die Vorlesungen mit einem Zeitraum statt einem Jahrgang versehen. Eine Beziehung sowie eine Vorlesung kann dann mehr als ein Jahrgang existieren.

Deine bisherige Variante hat den Reiz das sie leichter zu "verstehen" ist und auch Abfragen simpel sind. Nur Änderungen zu speichern ist sicherlich eleganter und entspricht der Normalform, erfordert aber etwas mehr Arbeit.

 

[jetwork]

Vielen Dank Ukulele

Sehr guter Punkt. Ich denke auch nur die Änderungen zu speichern erfordert mehr Arbeit auch während der Aktualisierungen als alle Daten nochmal zu importieren. Danke. Du meinst das oder?

Wie wäre aber das Schemata wenn ich nur die Änderungen speichern würde. Ich finde es sinnvoll die Beziehungen sowie die Vorlesungen mit einem Zeitraum statt einem Jahrgang zu versehen.

Hier ist mein Vorschlag.
tbl_dozent
dozent_id
dozent_2010_id
dozent_2011_id
dozent_2012_id
dozent_name
usw.

tbl_beziehungen_2010
dozent_2010_ref
vorlesung_2010_ref
jahr

tbl_beziehungen_2011
dozent_2011_ref
vorlesung_2011_ref
jahr

tbl_beziehungen_2012
dozent_2012_ref
vorlesung_2012_ref
jahr

tbl_vorlesung
vorlesung_id
vorlesung_2010_id
vorlesung_2011_id
vorlesung_2012_id
beschreibung
usw.

Ich füge jedes Jahr eine neue Spalte in die Tabellen hinzu. Wenn eine Vorlesung nicht mehr angeboten wird oder einige neue Vorlesungen kommen. Diese Vorlesungen werden als Einträge in einiger „vorlesung_jahr_id“ Spalten null Einträge haben.

Ist das so sinnvoll?

 

[Hony%]

Zweitens: Wie kann ich für jeden Jahrgang nur die Änderungen speichern?

Entweder wie @ukulele anmerkte als Range-Typ oder als "Ewigkeitsdaten". Range-Typen müssen natürlich ebenso jedes Jahr aufs neue aktualisiert werden. Beim Import von Daten aus einer Excel-Datei spart das also keine Zeit sondern wird technisch betrachtet lediglich anspruchsvoller.

Die Alternative dazu wäre lediglich den ersten Jahrgang zu speichern und davon auszugehen, dass alle folgenden Jahre inbegriffen sind bis eine Änderung vorliegt. Allerdings müssen dann implizite Informationen zusätzlich gespeichert werden, da sonst zum Beispiel nicht mehr feststellbar ist ob eine Vorlesung nicht mehr angeboten wird.

Nur Änderungen zu speichern ist sicherlich eleganter und entspricht der Normalform, erfordert aber etwas mehr Arbeit.

Ehrlich gesagt wüsste ich gerade nicht welche Normalform damit erreicht beziehungsweise gegen welche der vorgeschlagene Ansatz verstoßen soll.

Erstens: Ist es wirklich sinnvoll nur die Änderungen zu speichern oder macht man wie ich es schon gemacht habe? Wenn ja ich kann darauf bestehen, dass meine Lösung schon sinnvoll ist.

Es kommt drauf an. Wenn nur Änderungen gespeichert werden muss in der Folge zu jeder Abfrage der tatsächliche Zustand berechnet werden. Da ich bei einer solchen Datenbank deutlich mehr Lese- als Schreibzugriffe vermute halte ich deine Lösung für die sinnvollste.

Wie gesagt, %90 der Daten bleiben aber eigentlich unverändert, deswegen wollen sie nicht jeder Jahrgang alle Daten nochmal importieren. Sie wollen die Anzahl der Datensätze kleiner halten und den Aufwand zum Importieren verringern. Deshalb wollen sie ein Schemata dass sie für jedes Jahr nur die Änderungen aktualisieren sollen.

Von wie viel Zeitersparnis sprechen wir hier eigentlich? 1 Stunde? 1 Tag? Ein Schema orientiert sich am üblichen Gebrauch und nicht daran ob ein einmaliger Import mit weniger Aufwand betrieben werden kann. Ich gehe davon aus, dass die Datenbank später nicht über die Konsole sondern über eine Oberfläche gepflegt wird. Hier lassen sich zum Beispiel die Daten des Vorjahres als Vorlage heranziehen.

 

[Hony%]

Ich füge jedes Jahr eine neue Spalte in die Tabellen hinzu. Wenn eine Vorlesung nicht mehr angeboten wird oder einige neue Vorlesungen kommen. Diese Vorlesungen werden als Einträge in einiger „vorlesung_jahr_id“ Spalten null Einträge haben.

Ist das so sinnvoll?

NEIN! Ein Design das auf regelmäßigen absehbaren Änderungen aufbaut ist schlichtweg ein NoGo.

 

[ukulele]

NEIN! Ein Design das auf regelmäßigen absehbaren Änderungen aufbaut ist schlichtweg ein NoGo.

Absolut.

Ehrlich gesagt wüsste ich gerade nicht welche Normalform damit erreicht beziehungsweise gegen welche der vorgeschlagene Ansatz verstoßen soll.

Nun wenn ein Kurs oder eine Vorlesung länger als ein Semester angeboten wird würde ich sagen verstößt er gegen die 3. NF da die Informationen wie Kursname etc. ja jedes Semester neu angelegt werden, dabei bleiben sie immer gleich.

 

[Hony%]

Nun wenn ein Kurs oder eine Vorlesung länger als ein Semester angeboten wird würde ich sagen verstößt er gegen die 3. NF da die Informationen wie Kursname etc. ja jedes Semester neu angelegt werden, dabei bleiben sie immer gleich.

In dem Fall hättest du natürlich Recht. Ich habe den Entwurf aber eher so verstanden, dass die Vorlesung einmalig in tbl_vorlesung angelegt wird und in tbl_beziehungen (anbei ein schlechter Name, da wenig aussagekräftig) die n:m Beziehung zwischen Dozent und Vorlesung unter Berücksichtigung des Jahrganges abgebildet wird.

 

[ukulele]

Stimmt so war es wohl gedacht. In dem Fall wäre der Verstoß aber eventuell dennoch gegeben weil die Relation ja immer wieder erstellt wird, obwohl man sagen könnte das sie einfach nur über mehrere Semester bestand.

Problematisch wäre das denke ich nicht, aber auch nicht nach der heiligen Normalform

 

[Hony%]

Problematisch wäre das denke ich nicht, aber auch nicht nach der heiligen Normalform

Da muss ich dir widersprechen. Da in tbl_beziehungen=(dozent_ref, vorlesung_ref, jahrgang) alle Attribute zusammen den Superschlüssel bilden und es keine weiteren FA gibt befindet sich die Tabelle automatisch in der BCN.

obwohl man sagen könnte das sie einfach nur über mehrere Semester bestand.

Könnte man. Aber dann müsste die Relation auch zwingend mit einem Range-Typ oder Start und Ende gebildet werden. Damit wird letztendlich ein anderer Sachverhalt abgebildet.

 

[jetwork]

Danke an euch beide.

Sorry. Bei mir kann eine Vorlesung nur bei einem Dozent gehalten werden. Ein Dozent kann aber mehrere Vorlesungen halten. Ich sollte das ganz am Anfang schreiben

Ist das folgende Schema in Ordnung? Ich habe noch die Tabelle Student hinzugefügt. Alle Beziehungen in dem Schema sind 1 to 1 Beziehungen.

Erstens: Ist alles so in Ordnung?
Zweitens: Wie wäre eine getrennte Datenbank für jedes Jahr zu erstellen. Wir können für jedes Jahr eine neue Database mit gleichem Schema erstellen. Dateninput ist schon über Excel Dateien. Die Excel Datein kann man danach sehr leicht importieren.

Danke im Voraus.

 

[Hony%]

Sorry. Bei mir kann eine Vorlesung nur bei einem Dozent gehalten werden. Ein Dozent kann aber mehrere Vorlesungen halten. Ich sollte das ganz am Anfang schreiben

Dann ändert sich lediglich der Schlüsselkandidat auf: tbl_beziehungen=(dozent_ref, vorlesung_ref, jahrgang)

Erstens: Ist alles so in Ordnung?

Die ID in tbl_beziehungen ist meiner Meinung nach Quatsch und wird nicht benötigt. Du kannst ja einen eindeutigen Schlüssel bilden. Die Studenten haben darin nichts verloren da du so gegen die 2.NF verstößt. Entwerfe hier eine weitere Relationentabelle.

Die DATE Felder in Vorlesung und Dozent sind redundant und überflüssig. Diese Informationen lassen sich über die tbl_Beziehungen bilden. Im schlimmsten Fall produzierst du auch hier Verstöße gegen die 2. NF.

Zweitens: Wie wäre eine getrennte Datenbank für jedes Jahr zu erstellen. Wir können für jedes Jahr eine neue Database mit gleichem Schema erstellen. Dateninput ist schon über Excel Dateien. Die Excel Datein kann man danach sehr leicht importieren.

Die Anzahl an Datenbanken, Tabellen, Attributen bleibt immer gleich solange sich die Anforderungen nicht ändern.

Wenn es nur um den einfachen Import geht kannst das natürlich machen und anschließend die Daten zusammen führen. Als Design ist das aber untauglich.

 

[Hony%]

Beispiele für die Bildung der redundanten Daten:

zuerst_angeboten

SELECT MIN(jahr)
FROM tbl_beziehungen
INNER JOIN tbl_vorlesung
ON vorlesung_ref = vorlesung_id
WHERE vorlesung_id = 123

zuletzt_angeboten (nicht_mehr angeboten_ab)
Hier muss gegebenenfalls noch ein Jahr hinzu addiert werden. Möglicherweise gibt es auch eine Tabelle mit Semesterdaten die die notwendigen Informationen bereit hält

FROM tbl_beziehungen MAX(jahr)
INNER JOIN tbl_vorlesung
ON vorlesung_ref = vorlesung_id
WHERE vorlesung_id = 123;

 

[ukulele]

Bei mir kann eine Vorlesung nur bei einem Dozent gehalten werden. Ein Dozent kann aber mehrere Vorlesungen halten.

Wenn ich mir das Schema so angucke sehe ich die tbl_beziehung zwischen Dozenten und Vorlesungen als komplett überflüssig an, sofern du sagst jede Vorlesung existiert ein Semester und hat immer nur einen Dozent.

tbl_personen (Dozenten und Studenten)
pk
name

tbl_vorlesungen
pk
fk_dozent
name
vz

tbl_student_besucht_vorlesung
fk_student
fk_vorlesung
vz

Wenn man die Möglichkeit in betracht zieht das ein Dozent auch innerhalb eines Semesters wechseln kann (alter Dozent beim Komasaufen verstorben?) oder ein Student nachträglich einsteigt oder eine Vorlesung mehrere Perioden lang angeboten wird dann würde ich sagen:

tbl_personen
pk
name

tbl_vorlesungen
pk
name

tbl_person_beziehung_vorlesung
fk_person
fk_vorlesung
von
bis
funktion (Dozent oder Student)

 

[jetwork]

@ukulele
Eine Vorlesung existiert nich nur ein Semester. Meinst du soll ich für jeden Semester eine neue Datenbank erstellen?

 

[jetwork]

@ukulele
Mein Hauptproblem ist irgendwie die historische Daten in der Datenbank zu behalten und sie effizienz wieder nachfragen zu können.