Information ausblenden
Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, MariaDB, Oracle, Sql-Server, Postgres, Access uvm

Welche Datenbankschemata vereinfacht die Verwaltung und die Aktualisierung dieser Daten

Dieses Thema im Forum "Datenmodellierung, Datenbank-Design" wurde erstellt von jetwork, 24 September 2014.

  1. jetwork

    jetwork Fleissiger Benutzer

    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,
     
  2. ukulele

    ukulele Datenbank-Guru

    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 gefällt das.
  3. jetwork

    jetwork Fleissiger Benutzer

    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?
     
  4. Hony%

    Hony% Datenbank-Guru

    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.

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

    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.

    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.
     
    jetwork gefällt das.
  5. Hony%

    Hony% Datenbank-Guru

    NEIN! Ein Design das auf regelmäßigen absehbaren Änderungen aufbaut ist schlichtweg ein NoGo.
     
    jetwork gefällt das.
  6. ukulele

    ukulele Datenbank-Guru

    Absolut.
    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.
     
    jetwork gefällt das.
  7. Hony%

    Hony% Datenbank-Guru

    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.
     
    jetwork gefällt das.
  8. ukulele

    ukulele Datenbank-Guru

    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 :)
     
    jetwork gefällt das.
  9. Hony%

    Hony% Datenbank-Guru

    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.

    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.
     
    Zuletzt bearbeitet: 24 September 2014
    jetwork gefällt das.
  10. jetwork

    jetwork Fleissiger Benutzer

    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.
    upload_2014-9-24_15-51-41.png
    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.
     
  11. Hony%

    Hony% Datenbank-Guru

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

    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.

    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.
     
    jetwork gefällt das.
  12. Hony%

    Hony% Datenbank-Guru

    Beispiele für die Bildung der redundanten Daten:

    zuerst_angeboten
    Code:
    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
    Code:
    FROM tbl_beziehungen MAX(jahr)
    INNER JOIN tbl_vorlesung
    ON vorlesung_ref = vorlesung_id
    WHERE vorlesung_id = 123;
     
    jetwork gefällt das.
  13. ukulele

    ukulele Datenbank-Guru

    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 gefällt das.
  14. jetwork

    jetwork Fleissiger Benutzer

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

    jetwork Fleissiger Benutzer

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

Diese Seite empfehlen

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden