pel

so bin jetzt nochmals in mich gegangen, habe das GUI-Front-End aus meinem Kopf verdrängt, da es doch zu dominierend war und störte. Ich denke so dürfte die Information mittles select + join Abfragbar sein:

1. Datum Stunde Klasse Fach Inhalt Hausaufgabe
   
2. 15.10.2008 1 10b Mathe bla1 bla2
   
3. 15.10.2008 2 10b English bla3 bla4
   
4. 15.10.2008 3 10b Mathe bla5 bla6
   

Was meint Ihr zu unterem Bild?

ok ich habs mal so probiert, was hälst du davon? wichtig ist die rote Seite:

Ich habe eine N:M Beziehung zwischen Schulklasse + Fach erstellt mit den 2 Attributen Inhalt + Hausaufgabe damit jede Schulklasse + Fach-Kombination individuelle Inhalte+Hausaufgaben haben kann. Und dazu noch eine 1:N Beziehung sprich 1 Unterrichtstag hat eine eindeutige Schulklase+Fach-Kombination mit individuellem Inhalt+Hausaufgaben.

Da fehlt die Beziehung Schüler - Note.

was macht in der Tabelle Vorfall der Name?

Soll das der Name des meldenden Lehrer sein?

huch dämliches maestro, der visual designer ist buggy in einem anderen diagramm stimmts:

Das ist der Vorname + Nachname des Schülers + die Schulklasse die man in der GUI auswählen kann. Danach wird alles in eine Tabelle eingefügt und als VORFALL angezeigt.

Diese Tabelle ist eine Liste für alle Vorfälle bei der man nach Klassenspalte bzw. vorname/nachname spalte sortieren kann.

Was ist hier wenn 1 Vorfall mehrere Schüler betrifft? auch mehrmals eintragen?

Also wieder Auflösungstabelle.

Was mich am meisten interressiert ist wie ich diese Beziehung lösen kann:

1 Unterrichtstag hat N Unterrichtsstunden.

Angezeigt werden je Zeile

1 :Klasse : Fach : Aktivität : Hauseaufgaben

2 ...

Klasse und Fach bestehen bereits nur ohne Beziehung und dann müsste man das ganze mit dem Unterrichtstag + Unterrichtsstunde verknüpfen (1:N) fällt dir dazu was weises ein wie sonst auch?

komisch dass ich nicht editieren kann...

Würdet Ihr die Tabellen Schueler, Schulklasse, Fach als ternäre Beziehung beschreiben?

Sonst besorg dir doch einfach Visio...

Einfach, effizient, praktisch

so habe mal wieder etwas Zeit an dem Projekt weiter zu arbeiten wie versprochen nach langer Zeit das Diagramm Bilder siehe Anhang.

Das andere Bild sprich die farbige Tabelle soll die Grafische Oberfläche bzw. den Unterrichtsplan darstellen in meinem Programm. Wenn ich ein Datum vor oder zurück springe via button_click werden alle Datensätze zu einem Datum geladen.

Daher habe ich damals eingeführt:

1 Unterrichtstag hat N Unterrichtsstunden.

Unterrichtstag:

date datum;

Unterrichtsstunde:

unterrichtsstunde_id

klasse

fach

activity

homework

Meine Frage ist jetzt wie verbinde ich jetzt die Tabellen Unterrichtstag und Unterrichtsstunde mit den Tabellen Schulklasse + Fach und den beiden Feldern activity+homework? Vielleicht ist ja jemand so nett und hilft mir bitte dabei das ganze etwas aufzudröseln?

ist das ein Problem nicht zu helfen? Wenn ja warum ?

JA auch...

Hallöle ich bins wieder auf der Suche nach der Wahrheit

1.)

ERM = Grafische Darstellung mit Entitäten, Attributen sowie Primärschlüssel

ERD = Entitäten mit Beziehungen (Kardinalitäten) sowie der Raute in der Mitte

stimmt das so?

2.)

Kann mir jemand erklären wie Entitäten die disjunkt/nicht-disjunkt sind dargestellt werden mit Ihren Relationen, PK`s und FK`s ? z.B.

Ein Berater ist ein It-Berater und Finanzberator zu gleichen Zeit.

UND

Darstellung von disjunkt mit "X"-Symbol

Darstellung von nicht-disjunkt mit "o"-Symbol

ODER

Darstellung von disjunkt mit "G"-Symbol (Ein Berater kann entweder ein it-berater oder ein Finanzberater sein aber nicht beides)

Darstellung von nicht-disjunkt mit "Gs"-Symbol (It-berater kann auch Finanzberater sein)

Welche Symbole sind richtig, warum gibt es da keine einheitliche Darstellung und jeder macht was er will?

3.)

Das habe ich mir so zusammengeschrieben da ich oft unvollständige Info in Büchern + Inet finde, könntet Ihr das checken , ob die Merkmale der verschiedenen Normalisierungsstufen so stimmen?

Erste Normalform:

- Es gibt nicht mehrere Werte in einer Zelle einer Tabelle, nur 1 Wert je Tabellenfeld

- Spaltenwerte müssen atomar sein. Attribute wie Adresse müssen aufgeschlüsselt werden

- Es gibt einen Primärschlüssel der jeden Datensatz eindeutig identifiziert.

Zweite Normalform:

- Die 1.Normalform muss erfüllt sein

- Zerlegen der Relation in mehrere Relationen/Entitäten

- Keine Wiederholwerte in Spalten, sonst Änderung derer an mehreren Stellen. Besser ist das Attribut in eine eigene Tabelle setzen und via FK muss das ganze nur 1 mal geändert werden.

- Jedes Nichtschlüsselattribut muss vom Schlüsselkandidaten voll funktional abhängig ist.

Dritte Normalform:

- Die 2.Normalform muss erfüllt sein

- Ein Nichtschlüsselattribut darf nicht von einer Menge abhängig sein, die ausschließlich aus Nichtschlüsselattributen besteht, z.B. AbtBezeichung ist von AbtNr abhängig -> unterbringen in einer neuen Tabelle: ABTEILUNG

edit ging nicht mehr...

Was spricht gegen meine Lösung? Die Tabelle CD bleibt gleich, habe nur die Tabelle Lieder angepasst:

so jetzt nehm ich mal alles außenander was mir net koscher erscheint ich wills einfach wissen...

untenstehendes Bild habe ich von wiki "gerippt". Die Relation ist angeblich in der 2.Normalform.

zitat:"sowie die Tabelle einen eindeutigen Primärschlüssel (Verbundschlüssel aus den Spalten CD_ID und Track) ..."

wo ist dann in der Tabelle Lieder der Fremdschlüssel, der ja die Relation herstellt zur Tabelle CD ? gibts keinen FK obwohl 1:N Beziehung. Sag mir Dimi bitte das Beispiel ist falsch... vor allem den zusammengesetzten PK finde ich nicht gut. Bitte Dimi wie würdest du die CD/Lied Relation richtig machen?

Normalisierung (Datenbank ? Wikipedia)

Weiterhin habe ich immer noch massive Probleme mit diesen Entitäts-Kopien dies es laut dir nicht gibt, mir fehlt es da irgendwie an Vorstellungsvermögen oder das es "klick" macht.

1 CD hat mehrere Lieder,

1 Lied ist auf mehreren CDs -> ja ne das eine Lied kann ja nur auf einer CD sein ... kann man daraus eine N:M Relation machen? das verwirrt mich gewaltig.

achso obiges ist keine 1:N Beziehung 1 Student hat 1 Adresse... stimmt nicht, sondern eine Adresse hat auch mehrere Studenten siehe Studenten-WG :eek sprich realistisch gesehen muss es eine M:N Relation sein. Nur so am Rande...

Sicher. Der PK ist nicht unique, der FK referenziert keinen übergeordneten Schlüssel. Bis auf den ersten Adressatz würde keine DB die ich kenne das Einfügen der anderen erlauben.

Dim

richtig... mir ist schon klar , dass ein Lehrer für jedes Beispiel keine super normalisierte TAbelle hinlegen muss um zu zeigen was insert anomalie ist doch das mindeste ist, dass man drunter schreibt was an der Tabelle noch fehlt, weil so findet man keinen roten Faden in den Unterlagen... da siehste mal was für ein ******* ich lernen muss!

Danke Dimi nochmals ich denk echt du rockst und der Rest ****t! schön dass ich dieses Forum entdeckt habe

Die angegebene Tabelle ist also eindeutig falsch aufgebaut, Deine Aussage bezüglich den FKs und dem technischen PK ist eindeutig richtig.

Fazit: Verkauf dieses ominöse Buch oder besser: verbrenn' es.

Dim

du machst es mir nicht leicht. Stehe jetzt auch vor einer Art Gewissenskonflikt... wem glaube ich? Ich habe hier Lernunterlagen und das DB-Buch von Frank Geisler... egal nochmals was von meiner inkompetenten Lehrerin: 1 Student hat N Adressen kann durchaus sein (Bei Familie und in Studentenwohnheim...) doch schau dir mal die Tabelle ADRESSE an und die PK`s und FK`s fällt dir was auf?

Du könntest natürlich auch einen FK über die jeweiligen Felder anlegen und einen eigenen PK genieren, aber wie stellst Du die Verbindung her !? Im Grunde immer über die zusammengesetzten Felder, d.h. Du hättest mit einem eigenen Schlüssel eine unnötige Information, die nicht nötig ist

Phil

z.B. die Schueler/Fach ZwischenTabelle... da sind nur 2 FK`s drin (1PK würde da noch reinkommen da jede Tabelle einen PK braucht nur die excel zeichnung ist alt...)

http://forum.fachinformatiker.de/datenbanken/118624-haltet-diesem-erd-bitte-um-kritik.html

http://forum.fachinformatiker.de/attachments/a/2046-haltet-diesem-erd-bitte-um-kritik-erd.png

Das sind auch beides Fremdschlüssel, wenn man sie je für sich sehen würde. Da man die beiden aber zusammen nimmt und so eine einzigartige Beziehung entsteht, braucht man keinen "neuen" Primärschlüssel, sondern fasst diese beiden zu einem Primärschlüssel zusammen.

Hallo Allerseits

In meinen Lernunterlagen/Datenbank-Buch finde eine M:N Beziehung die mich verwirrt...

Mitarbeiter (PersonalNr , Name , Vorname , AbtNr, AbutBezeichnung)

Projekt (ProjNr , ProjektBeschreibung)

TätigkeitMA (PersonalNr , ProjNr , Tätigkeit ) (JOIN-Tabelle)

Warum wird hier ein zusammengestzter Primärschlüssel benutzt der sich aus beiden PK`s der anderen Tabellen zusammensetzt, anstatt einen künstlichen PK wie TätigkeitMA_ID zu nehmen? Weiterhin frage ich mich bzw. eigentlich müssten die beiden PK`s doch Fremdschlüssel sein... jeder zeigt auf seine Tabelle bzw. deren Tupel.

In einem guten Datenmodell sollte jede Tabelle einen PK haben. Zum einen ist das die Voraussetzung für ein normalisiertes ER-Modell (ohne PK kann man bei einer Tabelle nie von irgend einer Art von Normalisierung sprechen) und zum anderen kann man damit technisch eindeutig einen Datensatz identifizieren.

PK auch in einer Auflösungstabelle?? Mich wundert es nur, da dies in meinem DB-buch so nicht gezeigt wird... aber in dem einen bild siehe oben wirds so gezeigt,da hast recht. OK PK für jede TAbelle eingeplant bzw. LinQ afair erlaubt eh keine Tabellen ohne PK hehe von daher...

In der Tabelle Fach ist die Schüler_ID zuviel drin.

Du löst ja die Beziehung Fach <-> Schüler über die Zwischentabelle Schueler_Fach auf.

oh man ja das liegt an dem blöden tabellenkalk. programm mit dem ich das DB design mache , mal schauen was ob die neuen SQL 2008 server express/compact(free) Versionen bieten hinsichtlich Datenbank Design und Entitäten Visualisierung. Dann präsentier ich hier noch die letzte final version schön übersichtlich danke euch allen wieder was gelernt :e@sy

Könnt Ihr mir noch sagen, wass der PrimaryKey in der Auflösungstabelle

für eine Bedeutung hat? Denn ich habe in keiner meiner Auflösungstabellen einen PK!

Bedeutet: Enno hat recht und Du brauchst eine Auflösungstabelle z.B. Klausurergebnis

ok ich hab nochmals alles Überflogen und alle Eure Vorschläge eingebaut, ja auch Erno`s Datum Vorschlag mit Nachklausur-Datum... denke es schadet net und für einen vergesslichen Lehrer kann das ganz nützlich sein

Fällt euch sonst noch was auf oder Verbesserungsvorschläge? Wie sagte mein Lehrer:"90% des Programmes macht das Datenbank-Design aus". Naja etwas übertrieben, scheint der hat noch nie programmiert

Nö. An 1 Klausur nehmen doch X Schüler teil. Oder irre ich mich?

teilnehmen ist ja ein anderes Verb bzw. Ausdrucksweise... mit Klausur meine ich die Klassenarbeit(papierstück) selbst.

1 Schueler hat N Klausuren und jede Klausur hat 1 Note als Feld ist doch ok?

Du willst also wenn 20 Schüler in der Klasse sitzen, für eine Klausur 20 Einträge in der Tabelle machen?

1 Schüler hat Y Noten in Y Klausuren

1 Klausur hat X Schüler als Teilnehmer.

mit Y fange ich datenbanktechnisch nichts an

1 Schüler hat N Klausuren mit dem Feld Note.

1 Klausur wird von genau einem Schüler geschrieben.

Ach Datum da drin. Damit kannst du dann auch die Nachschreibenote unterscheiden.

Note ist Note egal wann die geschrieben wurde. Da wird nicht unterschieden warum auch.

1 Schüler hat N Vorfälle, aber hat 1 Vorfall N Schüler?

Das kommt drauf an wie man das ganze sieht finde ich. Wenn ich nur den Schüler in der DB haben will der z.B. das Opfen/Täter ist kann ich die anderen Beteiligten Namen in einen Bemerkungfeld schreiben. So würde 1 Vorfall hat 1 Schüler passen. Oder ich schreibe für 3 Schüler die beteiligt sind am Vorfall je einen Datensatz mit der gleich Vorfall ID eben was aber zuviel Aufwand ist. daher bevorzuge ich andere erstere Methode. Was meint Ihr - Herr Dotore? :floet:

Grundsätzlich hast Du natürlich recht. Allerdings gehört zu jedem Datenbankentwurf auch die schon angesprochene Denormalisierung, bei der man sich überlegt, welche Entitäten man sinnvollerweise zusammenlegen kann.

Das hat folgende Gründe:

- Vereinfachung des Datenmodells

- Vereinfachung der SQLs und des Applicationsdesigns

- Erhöhung der Performance

- Reduzierte Kosten wegen obiger Punkte. In einem normalen Projekt kannst pro Entität mal als Faustregel 25-30 Tsd Euro rechnen.

Man darf es natürlich nicht übertreiben, aber ein etwas umfangreicheres Datenmodell das sich in der 3 (oder sogar 4,5 NF) befindet ist in der Praxis praktisch nicht benutzbar.

Yo mittlerweile kenne ich Denormalisierung/Normalisierung und dass die beiden sich die Waage halten sollten... schnelle bzw. effekte sql statements mit möglichst wenig joins sind das Ziel bei gleichzeit kontrollierter Redundanz :bimei

Enno:

was mir grade aufgefallen ist.

du speicherst in der Tabelle Klausur die Note mit.

Das bringt nichts.

Für wen ist die Note?

Oder willst du für jeden Schüler einen eigenen eintrag in der Klausur anlegen?

Also auch mit Zwischentabelle arbeiten, die die Klausuren und die Schüler zusammenbringt.

yo 1 KLause hat 1 Note also kommt das in eine Tabelle. Die Note ist für die Klausur. 1 Schüler hat N Klausuren / 1 Klausur gehört zu 1 Schüler = 1:N Beziehung. Warum brauche ich da eine Zwischen-/Auflösungtabelle?

Pff. Ihr Kassenpatienten könnt mir garnix :bimei

- In der Tabelle Fach ist immer noch eine Schüler Id

yo und es scheint als hat sich in meinem Buch(Frank Geisler , Datenbanken 2.Auflage) ein Fehler eingeschlichen...

Kann es sein wenn du dir dieses Bild anschaust(ist ein Beispiel aus obigem Buch), dass der BERATER_ID FK ganz rechts überflüssig ist?? Er ergibt zumindest für mich keinen Sinn wenn ja, dann ist die SCHUELER_ID natürlich auch quark!

- Eine Auflösungstabelle hat einen eigene technischen PK und zwei Felder die dann, in Deinem Fall, ein Fach mit einem Schüler verbinden, keinen zusammengesetzten PK der diese Aufgabe übernimmt.

habs mal verbessert: das mit dem zusammengesetzten PK war quark

- Unterrichtsstunde und Unterrichtstag würd ich in einer Tabelle abspeichern. Man muss es nicht übertreiben ;-)

Beide Tabellen in eine Tabelle macht man ja nur wenn es eine 1:1 Beziehung wäre, ist hier ja aber nicht der Fall.

1 U.TAG hat N U.STD d.h. ein U.TAG verweist auf mehrere Unterrichtseinheiten die individuelle Inhalte und Hausaufgaben haben. Würde ich dies zu einer Tabelle zusammenfügen, so hätte solche Einträge in der Tabelle UNTERRICHT:

1. 
   
2. DATUM_ID TAGESDATUM STUNDENNR INHALT HAUSAUFGABE
   
3. 1............. 12.10.2008 ...... 1................bla.............bla
   
4. 2............. 12.10.2008 ...... 2................test ...........test
   
5. 3............. 12.10.2008 ...... 3................bla............... bla
   

das TAGESDATUM ist doch sehr redundant daher fände ich die Aufteilung auf 2 Tabellen ok.

Allerdings würd mich interessieren welchen Mehrwert an informtion du dadurch erhalten willst, denn es fehlt eine Verbindung zu einem Fach. Ein Stundenplan ist so nicht möglich.

HM... so ists wenn man sich zu sehr an bestehenden englischen Alternativprogrammen orientiert und deren Designfähler übernimmt

Das Fach ist eigentlich unwichtig bei dem Unterrichtstagesplaner, den die Bezeichnung für das Fach befindet isch in dem Klassennamen z.B. E7b heißt Englisch Klasse 7b.

Natürlich könnte man noch eine Spalte Fach einfügen neben die Spalte Klasse.

Doch wie würdest du da einen Beziehung herstellen?

1 U.STD hat 1 FACH ? also der Tabelle UNTERRICHtSSTUNDE das Feld "Fachname" hinzufügen? Das klingt ok ^^

Ja. Fach und schüler ist eine n:m Zuordnung. Ein Schüler kann mehrere Fächer haben und ein Fach wird von mehreren Schülern besucht.

das dachte ich mir auch schon, nur du liest die Beziehungen anders wie ich , daher fand ich meine Beziehung etwas komisch... :

Ein Schüler kann mehrere Fächer haben und mehrere Fächer werden von vielen Schülern besucht. <-- Dies verwirrte mich...

So habe es mal umgeschrieben und die M:N Beziehung aufgelöst.

Dann gibt es noch das Problem mit dem Vorfall , welcher vorher eine 1:N Beziehungen war, doch dann dachte ich nochmals drüber nach und eigentlich ist es auch eine M:N Beziehung. Siehe Bild was ich dort schrieb, was denkst du?

Habs jetzt aber nur mal überflogen.

Das Programm ist für meine Freundin(noch Referendar...) daher fällt der Lehrer hier untern Tisch

Also vom Text her wärs ok, leider hast das aber nicht so umgesetzt.

Dim

yo hast recht da hab ich geschlafen bzw. alles falsch rumgemacht

siehst du sonst noch unstimmigkeiten? Ist ja keine große DB...

Hallo,

was haltet Ihr von dieser Datenbankstruktur?

Bitte um Kritik was man besser machen könnte!