Umgang mit unterschiedlich langen Datensätzen

Hi,

wenn man verschieden große Datensätze zu speichern hat wie geht man damit in einer relationalen Datenbank um?

Datensatz1
(A B C D) = (a1, b1, c1, d1)

Datensatz2
(A B D) = (a2, b2, d2)

Datensatz3
(A D) = (a3, d3)

Ich habe überlegt einfach eine Tabelle so einzurichten, dass sie den größten Datensatz aufnehmen kann. Bei den kleineren Datensätze die entsprechenden Einträge als unbesetzt markieren. Geht das eleganter?

Was mache ich wenn ein noch umfangreicherer Datensatz in der Zukunft auftritt?
Einfach eine Spalte an die Tabelle anfügen?

Wie geht man generell damit um, wenn sehr unterschiedlich lange Datensätze auftreten, bei denen die maximale Länge unbekannt ist? Also (a1, a2 ... ax) wobei das x von "ax" unbekannt ist.

SideWinder

Gib ein Beispiel, aber die "Max-Länge"-Idee ist Käse. Meistens regelt sich das mit einer zusätzlichen Tabelle.

Bspw:

Bestellung besteht aus mehreren Bestellpositionen

Tabelle Bestellung:
1 - Bestellung A
2 - Bestellung B

Tabelle Bestellposition:
1 - 1 - 1 - Position 1 in Bestellung A
2 - 1 - 2 - Position 2 in Bstellung A
3 - 2 - 1 - Position 1 in Bestellung B
usw. usf.

MfG SideWinder

SideWinder schrieb:

Gib ein Beispiel, aber die "Max-Länge"-Idee ist Käse. Meistens regelt sich das mit einer zusätzlichen Tabelle.

Bspw:

Bestellung besteht aus mehreren Bestellpositionen

Tabelle Bestellung:
1 - Bestellung A
2 - Bestellung B

Tabelle Bestellposition:
1 - 1 - 1 - Position 1 in Bestellung A
2 - 1 - 2 - Position 2 in Bstellung A
3 - 2 - 1 - Position 1 in Bestellung B
usw. usf.

MfG SideWinder

OK!
Also anstatt eines Datensatzes mit unbekannt vielen Einträgen einfach mehrere Datensätze mit bekannter Länge mit Indizierung machen! Oder habe ich das falsch verstanden?

Zusatz:

ich war darauf gekommen, weil hier irgendwo ein Beitrag war in dem Jemand versucht hat eine Verwaltung für Schulnoten zu machen.

Dabei hatte ich mir dann versucht zu überlegen wie sowas für eine ganze Schule auszusehen hätte.

Probleme die ich gesehen habe:

- Verschiedene Fächerwahl der Schüler, obwohl sie in der selben Klasse sind
- neue Fächer die hinzukommen können (Wie z.B. der islamische Religionsunterricht)
- Schulwechsel von Schülern

Was ist dann z.B. die Haupttabelle? Geht man von den Schülern aus uns gibt Referenzen auf weitere Tabellen zu Fächern? oder von den Fächern mit Referenzen auf die Schüler? (Ich denke die Schüler solltem die Haupttabelle der Datenbank bilden)

Wie integriert man neue Fächer? Ohne das jedesmal ein "Spezialist" eine neue Tabelle einfügen und die GUI anpassen muss?

So ich habe einen Vorschlag überlegt:

Schüler |INT AUTOINCREMENT PRIMARY_KEY Schüler_ID , VARCHAR Vorname, VARCHAR Nachname, DATE Geburtstag, DATE Einschulung, INT Stufe, VARCHAR Adresse

Dann die Verknüpfung der Jahrgangsstufe mit den Stundenplänen:

Jahrgang | Schüler_ID | DATE aktuelles_Jahr | Stundenplan_ID

Dann die Stundenpläne mit den Fächern verknüpfen

Stundenplan |INT PRIMARY_KEY Stundenplan_ID , VARCHAR Fach_Name

Und dann eine Tabelle für jedes Fach z.B.:

Mathematik | BOOL LK, FLOAT Note, VARCHAR Lerherhinweise

Ist die Vorgehensweise so richtig?
Und wie geht man mit neuen Fächern um? Wirklich eine neue Tabelle anlegen?
Wie macht man die GUI das Laien (Lehrer ) eine neue Tabelle anlegen und verwalten können?

Shade Of Mine

MisterX schrieb:

Und dann eine Tabelle für jedes Fach z.B.:

Bis dahin OK.
Aber nur eine Tabelle für ALLE Fächer.

Die Stundenpläne habe ich nicht verstanden.

Zeichne das ganze mal auf.

Shade Of Mine schrieb:

MisterX schrieb:

Und dann eine Tabelle für jedes Fach z.B.:

Bis dahin OK.
Aber nur eine Tabelle für ALLE Fächer.

Die Stundenpläne habe ich nicht verstanden.

Zeichne das ganze mal auf.

OK, Danke!

Kannst du bitte begründen warum nur eine Tabelle für alle Fächer?
(Ich möchte es allgemein lernen und nicht nur in diesem speziellen von mir gewählten künstlichen Beispiel)

Ich dachte bei meiner Idee der Stundenplan sollte die Möglichkeit eröffnen die Datensätze der Fächer des jeweiligen Schülers nach Jahrgang (Klasse) zu trennen.

Der Stundenplan scheint bei zweiter Betrachtung so wirklich nicht zu funktionieren.

Auf das Aufteilen bin ich gekommen weil ich bei der Recherche nach Skripten immer wieder auf Anleitungen und (fünf) Regeln gestoßen bin, die fast immer zum Aufteilen in mehrere Tabellen führen.

Z.B hier: http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/chap4.htm

hustbaer

Wenn du es allgemein lernen willst, dann lies das:
http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)

nman

hustbaer schrieb:

Wenn du es allgemein lernen willst, dann lies das:
http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)

Insbesondere von da http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)#Erste_Normalform_.281NF.29 bis inklusive 3NF.

Ich habe mir die Regeln angesehen und versucht zu verstehen.

Bis jetzt habe ich folgende Überlegungen:

Gespeichert werden muss:
- Vorname, Nachname, Anschrift, Fächerwahl

Die folgende Überlegung hängt nicht mit den Regeln ab:
Zuerst dachte ich, der Vorname + Nachname könnte zusammen ein Primärschlüssel sein. Weil aber Menschen den gleichen vor- und Nachnamen haben können geht das nicht. Selbst zusammen mit der Adresse ist es kein Primärschlüssel, weil Menschen mit gleichem Vor - und Nachnamen in einem Haus leben könnten (Armer Postbote ). Daraus folgt, dass eine eindeutige Schüler ID eingeführt werden muss.

Zusammen mit den Fächern (alle in eine Tabelle) sieht es so aus: (wenn angenommen werden soll, dass nur aufgenommen wird, ob ein Schüler ein Fach hat oder abgewählt hat)

Stundenplan |INT AUTOINCREMENT PRIMARY_KEY Schüler_ID , VARCHAR Vorname, VARCHAR Nachname,VARCHAR Wohnort,VARCHAR Straße, VARCHAR Hausnummer, BOOL Mathe, BOOL Deutsch, BOOL Musik,...)

Hausnummer nicht als INT, sonder VARCHAR weil es z.B Haus 1a geben könnte.

Überprüfung der Regeln

1. Normalform: "Jedes Attribut der Relation muss einen atomaren Wertebereich haben".

Ist erfüll, weil Vor- und Nachname getrennt sind. Außerdem ist die Adresse getrennt in Wohnort, Straße, Hausnummer. Alles Atomar, inklusive der Unterrichtsfächer, wie es sein soll.

2. Normalform: "Eine Relation ist in der zweiten Normalform, wenn die erste Normalform vorliegt und kein Nichtschlüsselattribut funktional abhängig von einer echten Teilmenge eines Schlüsselkandidaten ist".

Da es nur einen einzigen Primärschlüssel gibt, kann kein Nichtschlüsselattribut abhängig von einer echten Teilmenge eines Schlüsselkandidaten sein. Also erfüllt.

3. Normalform: "Die dritte Normalform ist genau dann erreicht, wenn sich das Relationenschema in 2NF befindet, und kein Nichtschlüsselattribut (...) von einem Schlüsselkandidaten transitiv abhängt."

Alles hängt von dem Primärschlüssel ab, also erfüllt.
OK so weit.

Wenn jetzt aber ein Stundenplan für jedes Jah aufgestellt werden soll, wird zusätzlich ein Jahresdatum eingefügt.

Schüler |INT AUTOINCREMENT PRIMARY_KEY Schüler_ID , VARCHAR Vorname, VARCHAR Nachname,VARCHAR Wohnort,VARCHAR Straße, VARCHAR Hausnummer, DATE Jahr, BOOL Mathe, BOOL Deutsch, BOOL Musik,...)

Regel 1 unverändert erfüllt.

Regel 2 unverändert erfüllt.

Regel 3 nicht mehr erfüllt. "Jahr" hängt von der ID ab. Die einzelnen Fächer aber vom "Jahr". Also muss die Tabelle aufgspalten werden:

Schüler |INT AUTOINCREMENT PRIMARY_KEY Schüler_ID , VARCHAR Vorname, VARCHAR Nachname,VARCHAR Wohnort,VARCHAR Straße, VARCHAR Hausnummer, DATE Jahr

Jahresplan | INT Schüler-ID, DATE Jahr, BOOL Mathe, BOOL Deutsch, BOOL Musik,...)

Jetzt müssen bei "Jahresplan" die "Schüler_ID" und Jahr zusammen einen Primärschlüssel bilden.

Regel 1 erfüllt bei beiden Tabellen.
Regel 2 bei der Tabelle Schüler erfüllt, weil es nur einen Primärschlüssel gibt. Bei "Jahresplan" erfüllt weil die Fächerbelegung vom Schülernamen und dem Jahr abhängt.
Regel 3 bei Schüler erfüllt, weil alles direkt von der Schüler_ID abhängt. Bei "Jahresplan" erfüllt weil jedes Fach von keinem anderen Fach, sondern nur direkt von dem zusammengesetzten Primärschlüssel bestehend aus Schüler-ID und Jahr anhängt.

Sind die Überlegungen so richtig?