Datenbank Forum - für Anfänger und Profis

Willkommen im Datenbank Forum von Datenbanken-verstehen.de - Das Datenbank, Data Warehouse & Business Intelligence Forum!

Das Datenbank Forum für Anfänger und Profis ist eine Community zu den Themen Datenbanken, Data Warehouse & Business Intelligence. Nimm teil an der Community von Datenbanken-verstehen.de und tausch dich mit deinen Fragen und Lösungen mit anderen Nutzern aus.

Als registrierter Benutzer genießt Du viele Vorteile, wie

  • den vollen Zugang zu allen Foren und Unterforen
  • Kostenloses Lernmaterial inkl. Lösungen zum Thema Datenbanken
  • Zugriff auf DB-Tutorials, Best Practices und SQL-Snippets

Bevor Du einen Beitrag verfassen möchtest, kannst Du dich einfach kostenlos registrieren.

oder Einloggen mit



Beachte bitte die Forenregeln von Datenbanken-verstehen.de. Wir wünschen Dir viel Spaß im Datenbank Forum! - Dein Datenbanken-verstehen.de-Team

Dritte Normalform erreicht -> trotzdem Anomalien

Im Bereich Datenbank Grundlagen werden alle Grundlagen zu Datenbanken besprochen.
Hier fühlen sich Datenbank Anfänger wohl...

Dritte Normalform erreicht -> trotzdem Anomalien

Beitragvon Verena » Do 5. Sep 2019, 08:51

Liebe Nutzer,
beim Durcharbeiten der Normalformen stoße ich immer wieder auf selbstentwickelte Beispiele, bei denen die ersten drei Normalformen nicht zu einer zufriedenstellenden Lösung führen. Ich würde mich sehr freuen, wenn jemand bereit ist, diese mal anzusehen. Derartige Beispiele konnte ich bisher nirgends finden.

Der Datenbank im Anhang liegen folgende Bedingungen zugrunde:
- Jeder Schüler wählt genau ein Projekt. Daher ist die Schüler-ID der Primärschlüssel der Tabelle, da jeder Schüler genau einmal vorkommt.
- Jedes Projekt kann mehrfach vorkommen, wenn es von verschiedenen Schülern gewählt wird
- Jedes Projekt (auch wenn es ein und derselbe Kurs ist!) kann von verschiedenen Lehrern geleitet werden (Beispiel: Musik ist immer genau derselbe Musikkurs und genau gleich aufgebaut. Er kann in derselben Form angeboten werden aber von verschiedenen Personen)
(ein verständlicheres Beispiel wäre z.B. ein Sprachenkurs Deutsch B1, der von verschiedenen Personen angeboten wird)
- Ein Lehrer kann verschiedene Kurse anbieten

Die Datenbank liegt meines Erachtens in der dritten Normalform vor! Dies liegt speziell daran, dass zwischen Projekten und Projektleitern eine m:n Beziehung vorliegt, welche die beiden Attribute unabhängig voneinander macht und die dritte Normalform hier nicht zum Auslagern der Informationen führt.

Dennoch ist der Aufbau der Tabelle nicht sinnvoll in Hinblick auf Einfüge- und Löschanomalien. Die Projekte und die Projektleiter sollten jeweils eigene Entitätsmengen darstellen und in eigene Tabellen ausgelagert werden.

Mache ich einen Fehler bei der Normalisierung oder erreicht diese hier ihre Grenze und erkennt die verschiedenen Entitätsmengen aufgrund der Gegebenheiten nicht?
Dateianhänge
Schülerprojekte.PNG
Verena
 
Beiträge: 1
Registriert: Do 5. Sep 2019, 08:32

Re: Dritte Normalform erreicht -> trotzdem Anomalien

Beitragvon acinup » Mi 11. Sep 2019, 20:41

Hallo Verena,
aus deinen Bedingungen folgt, dass es in deiner Datenbank Entitäten geben soll, zwischen denen eine 1:n bzw. n:m Beziehung besteht. Daraus folgt, dass du mehrere Tabellen (für jede Entität eine) benötigst, zwischen denen diese Beziehungen bestehen. Jede Entität sollte dann einen Primärschlüssel besitzen, damit jeder Datensatz eindeutig identifizierbar ist.

In deinem Beispiel würde ich die Entität Schüler in eine Tabelle packen (inhaltlich bestehend aus den ersten drei Spalten deines angegebenen Beispiels. Die Klasse gehört nicht dazu!) Ich würde diese Tabelle vorerst mit folgenden Attributen anlegen:
tblSchueler(schueID, schueFamilienname, schueVorname)
Die Vorsilben tbl und schue vor jedem Attribut folgen aus der sog. ungarischen Notation. (Bei den Attributen ist diese nicht unbedingt üblich, sorgen aber dafür, dass jedes Attribut eine eindeutige Bezeichnung erhält.) Später werden wir gegebnenfalls noch Fremdschlüssel ergänzen.
Die Klasse eines Schülers gehört nicht zur tblSchueler, denn im nächsten Schuljahr ändert sich ja in der Regel die Klassenbezeichnung aufgrund der Versetzung der Schüler. Würden wir die Klasse als Attribut zur Entität Schüler hinzunehmen, so widerspricht dies der 3. Normalform (Schlagwort: Historie).
Wenn wir unsere Datenbank nur in diesem Jahr einsetzen wollen und im nächsten Schuljahr nicht mehr nutzen wollen, spricht natürlich nichts dagegen, das Klassenattribut der Entität Schüler hinzuzufügen (als SchueKlasse). Im folgenden mach ich das mal so, sonst würde mein Text noch länger. Also: Datenbank, mit der ich nur in diesem Schuljahr arbeiten kann mit der Tabelle
tblSchueler(schueID, schueFamilienname, schueVorname, schueKlasse)

Die Projekte bilden eine eigene Entität, benötigen also eine eigene Tabelle (tabProjekte), wobei ich mir bei deinen Vorgaben nicht sicher bin, ob du nicht zwei verschiedene Dinge als Projekt bezeichnet hast. Für mich in diesem Text sind Projekte Unterrichte, die in einem bestimmten Schuljahr mit einem bestimmten Dozenten und einer bestimmten Lerngruppe durchgeführt wird. Davon unterscheide ich deutlich die Entität Lerninhalte (mir fällt spontan kein besseres Wort ein), die die Inhalten eines Projekts beinhalten, die aber in verschiedenen Projekten recycelt werden können. Es besteht als eine 1:n Beziehung zwischen den Projekten und den Lerninhalten: Ein Projekt hat einen bestimmten Lerninhalt. Ein Lerninhalt kann aber in mehreren Projekten vorkommen. Beispiel: Lerninhalt Deutsch auf B1 Niveau wird im Projekt Deutschprojekt A und Deutschprojekt B behandelt. Da diese beiden Projekte zeitgleich stattfinden, werden diese Projekte von verschiedenen Dozenten angeboten und auch von verschiedenen Schülern belegt.
Ich habe deine Bedingungen so verstanden, dass du kein Teamteaching zulassen willst, sondern dass es zu jedem Projekt jeweils genau einen Dozenten gibt. n:1 zwischen Projekt und Dozent. Eine 1:n Beziehung wird übrigens dadurch realisiert, dass auf der n-Seite (also hier das Projekt) der Primärschlüssel der 1-Seite (also hier die DozenzenId) als Fremdschlüssel eingefügt wird.
Ich müsste noch viel erklären, hab aber jetzt keine Lust mehr. Vielleicht ergänze ich später noch weitere Erklärungen.
Ich schließe mit der Angabe der Entitäten, wie sie sich aus obigen Erklärungen ergeben (wie gesagt ohne Berücksichtigung der Tatsache, dass Schüler im Laufe ihrer Schullaufbahn verschiedene Klassenstufen durchlaufen.)

tblSchueler(schueID, schueFamilienname, schueVorname, schueKlasse, schueProjeIdRef)

tbl Dozenten (DozenID, DozenName,...)

tblLerninhalte(lerniId, lerniBezeichnung,...)

tblProjekte(projeId, projeBezeichnung, projeLerniIdRef, projeDozenIdRef,...)

Die Ref-Attribute in den Tabellen sind jeweils Fremdschlüssel, anhand dessen der zugehörige Datensatz in der Bezugstabelle identifiziert werden kann.
acinup
 
Beiträge: 1
Registriert: Mi 11. Sep 2019, 19:53


Zurück zu Datenbank Grundlagen

 


  • Related topics
    Antworten
    Zugriffe
    Letzter Beitrag

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste

  • Jetzt Fan werden
  • Newsletter abonnieren? Hier anmelden!

    Alle Informationen aus dem Portal, Blog und Forum in einem Newsletter!

    E-Mail-Adresse: