Top super erklärt, ich habe mich schon die ganze Zeit gefragt wie ich gegen die zweite Normalform verstoßen könnte und bin im Leben nicht drauf gekommen. Wir sollten ein Beispiel konstruieren um es eben zu normalisieren.
Danke fürs Video. Ist eine tolle Ergänzung zu meinen Vorlesungen. Zum Abschluss die korrekte Tabelle wäre noch toll gewesen. So fühlt sich das ganze etwas unfertig an.
Sehr schön erklärt. 2NF funktioniert halt nur dann korrekt, wenn kein Surrogatschlüssel verwendet wurde. Mit Surrogatschlüssel ist ein zusammengesetzter Schlüssel nicht vorhanden. Den Schluß, fand ich etwas kurz - lag ja vielleicht am Nachbar - also das Zusammensetzen der Tabellen (Stichwort Verbundtreue). Hier hätte vielleicht ein einfaches ERM schnell und übersichtlich gezeigt, wie die Relationen zusammenhänge: Kunde hat mehrere Aufträge(1:n) und Auftrag entält Artikel (n:m).
Gutes Video aber es wurden von bspw. Frau Müller ja trotzdem 2 Artikel gekauft?! Warum muss man diese dann in der 2. Normalform dann nicht mehr darstellen?
Aber beim Schritt zur 2 Normalform fallen doch auch Sachen weg, davor war einmal der Dornfelder mit 10,99 und danach nicht. da fehlen ja dann sachen. Bei mir habe ich auch noch dopplungen, weiß nur nicht wie ich die tilgen soll, ohne welche einfach weg zulassen .
Wäre es nicht denkbar, dass wenn mehrere Personen in einem Haus leben, dass man dann noch einen Adressschlüssel bilden muss. Ansonsten entsteht doch eine Redundanz in der Adresse, oder ?
Vielen lieben Dank Sebi für deine Super-Videos. Ich sehe sie mir zu meinen Aufgaben nocheinmal an und das hilft sooo unglaublich weiter!!! FRAGE: Ich brüte gerade über einer Aufgabe in der ich Teilenummern, Hersteller-ID und den Namen des Teils habe. Aus meiner sicht spräche nichts dagegen beide Nummern als zusammengesetzten Primärschlüssel zu verwenden, da nur beide zusammen einen eindeutigen Primärschlüssel abgeben. Wäre das eine Ausnahme von der Regel?
Das kann ich so nicht beurteilen, es hängt ja von der Beschaffenheit der Nummern ab und wie und in welchem Kontext sie eindeutig sind. Meine Antwort kann daher nur „Kann sein!“ lauten, was dir nicht hilft.
@@SebastianPhilippiTV ja das stimmt leider. Vielleicht klappt es ja so: Hersteller und Teilenummer bestehen jeweils aus einem Buchstaben und drei Ziffern und sie sind nur eindeutig, wenn ich sie zusammen verwende, da die Teilenummern teilweise identisch sind T001 usw. und auch die Produktbezeichnungen teilweise gleich sind (Allerdings haben einige Teile bei gleicher Nummer andere Bezeichnungen) , sie unterscheiden sich hauptsächlich durch den Hersteller.
Hier 4:24 ist doch Redundanzen vorgekommen und redundanzen sollen in 1NF schon verhindert worden sein. also ist die 1NF noch nicht erfüllt oder lege ich falsch?
@Sebastian Philippi 5:20 Streng genommen ist doch Name von RechNr abhängig oder nicht? Ich kann über die RechNr den Namen herrausfinden. Bspw. steht hinter RechNr. 2 immer der Name Müller... Würde mich über eine antwort sehr freuen.
Nachtrag: ist PLZ nicht auch ein Primärschlüssel(kandidat), da hinter derselben PLZ nie unterschiedliche Ortsnamen stehen können? Müsste das nicht auch in eine eigene Tabelle?
@@NPC-xk7ko Ja, das mit der PLZ könnte man so machen. Kommt ein bisschen drauf an, wie man die Orte speichern will. In kleineren Städten und Gemeinden können sich schon mehrere Namen hinter der gleichen PLZ verbergen (am Beispiel unseres Städtchens Weilburg: 35781 Weilburg, 35781 Weilburg-Odersbach, 35781 Weilburg-Waldhausen,...). Diese Ortsnamen könnte man aber weglassen und damit über die PLZ als ID suchen. Was den Namen angeht: Der Name ist deutlich stärker an die Kundennummer gebunden als an die Rechnung. In Datenbanken versuchen wir ja bekanntlich, Redundanzen zu vermeiden. Wenn ich jetzt also in jeder Rechnung immer wieder den Namen hinterlege, der auch in der Entität Kunde gespeichert ist, dann schaffe ich eine Redundanz, die a) sinnlos ist und b) mir im besten Fall später nicht auf die Füße fällt.
@@SebastianPhilippiTV vielen Dank für die schnelle Antwort Kurz zu " Kommt ein bisschen drauf an, wie man die Orte speichern will" Das ist das alte Dilemma zwischen Theorie und Praxis :D. Wenns nicht gefordert ist, hab ich bis jetzt eh Datenbank intuitiv/unbewusst nach den drei Nf gelöst. Mir geht es jetzt so strikt wie möglich um die Definition/Theorie. Weniger "Bauchgefühl". Zu den PLZ: ich hab mir dein Video der 3.Nf angeschaut und dort wird das "PLZ"-Beispiel ja benutzt. Gehen wir davon aus, das sowas wie 35781 Weilburg, 35781 Weilburg-Odersbach nicht existiert. (In der Beispieltabelle existiert es ja tatsächlich nicht). Du gehst in diesem Video nochmal die Definition der 2.Nf durch und sagst "Alle Attribute hängen vom gesamten Primärschlüssel ab". Also praktisch die Definition, die du bereits hier verwendest. Als ich das nochmal gehört habe, ist mir was aufgefallen. Und zwar das deine Definition, weicht leicht von der ab, die bei Wikipedia steht. Zitat: "Eine Relation ist genau dann in der zweiten Normalform, wenn die erste Normalform vorliegt und kein Nichtprimärattribut (Attribut, das nicht Teil eines Schlüsselkandidaten ist) funktional von einer echten Teilmenge eines Schlüsselkandidaten abhängt." Wenn ich das richtig verstehe, ist die "Kollision" zwischen deiner Definition und die von Wikipedia die, dass du dich an den Primärschlüsseln orientierst, Wikipedia jedoch an den potenziellen Primärschlüsseln (Schlüsselkandidaten). Folglich ist die Tabelle, nach der Definition von Wikipedia, aus deinem Video "Dritte Normalform (3NF) | Datenbanken" noch nicht in der 2. Nf, oder? Zu deiner Antwort bzgl. des Namens: Das Name stärker an Kundennummer gebunden ist, geht nirgendwo hervor. Die Funktionale Abhängikeit besagt ja: "Eine Funktionale Abhängigkeit zwischen Attribut Y und Attribut X liegt dann vor, wenn es zu jedem X genau ein Y gibt." Das trifft ja sowohl für Kdnr -> Name und Rechnr.-> Name zu. Aber 1. ist es gesunder Menschenverstand das man Name zu Kunde und nicht zu Rechnung schreibt und 2. wiederspricht es ja keiner Definition. Ich wollte nur anmerken, das man an der Stelle hätte sagen sollen das dort auch eine Abhängigkeit existiert.(und mich vergewissern das ich nicht falsch liege) :)
@@NPC-xk7ko Hi! Da merkt man, dass ich gar nicht vor habe, nach der Definition zu gehen. Natürlich hab ich das alles mal vor vielen Jahren in Datenbankenvorlesungen gehört, aber danach auch nur noch selten angewendet. In meinen Videos versuche ich mehr auf die Grundprinzipien des DB-Entwurfs zu zielen und Definitionsreiterei zu vermeiden. Ganz ehrlich? Die Definitionen müsste ich oftmals selbst nachlesen, weil ich sie nicht mal mehr präsent im Kopf habe. Das stößt natürlich denjenigen wie dir, die es dann wirklich genau wissen wollen, sauer auf. Das kann ich verstehen. :-)
Sehr klares, übersichtliches und gut strukturiertes Video!
Sie haben offiziell mein Leben gerettet!♥
dem schließe ich mich an ;D
@@onlynocturnal wünscht mir glück morgen test
@@mrdenis2707 viel Erfolg ✌️
@@onlynocturnal ICH HABS GESCHAFFT
@@mrdenis2707 nice, sehr gut 👍
Danke, endlich verstehe ich die 2. NF. Habe heute die mündliche Matura über Datenbanken
Danke dir Sebastian 😄
vielen Dank, sehr gut erklärt endlich habe ich es verstanden
Beste Lehrer Dankeschön
sehr nice erklärt
Top super erklärt, ich habe mich schon die ganze Zeit gefragt wie ich gegen die zweite Normalform verstoßen könnte und bin im Leben nicht drauf gekommen. Wir sollten ein Beispiel konstruieren um es eben zu normalisieren.
Danke fürs Video. Ist eine tolle Ergänzung zu meinen Vorlesungen. Zum Abschluss die korrekte Tabelle wäre noch toll gewesen. So fühlt sich das ganze etwas unfertig an.
Sehr schön erklärt. 2NF funktioniert halt nur dann korrekt, wenn kein Surrogatschlüssel verwendet wurde. Mit Surrogatschlüssel ist ein zusammengesetzter Schlüssel nicht vorhanden. Den Schluß, fand ich etwas kurz - lag ja vielleicht am Nachbar - also das Zusammensetzen der Tabellen (Stichwort Verbundtreue). Hier hätte vielleicht ein einfaches ERM schnell und übersichtlich gezeigt, wie die Relationen zusammenhänge: Kunde hat mehrere Aufträge(1:n) und Auftrag entält Artikel (n:m).
Sehr gutes Video. Kurze Anmerkung: In Zelle L6 stimmt der Preis nicht überein mit den anderen Werten
sehr gut erklärt. So muss das sein ! Daumen verdient!
Vielen Dank für das tolle Video
richtig gut erklärt! sehr klare Logik. vielen Dank!
Endlich verstanden! Vielen herzlichen Dank!
Top Video zum Auffrischen!
Tolles Video,alles gut erklärt.Danke
Wow hast mir sehr weiter geholfen vielen dank!
Vielen Dank, alles just in time! Kommenden Freitag IHK FA-Anwenderprüfung. Ich hoffe so das es reicht..
Top
Vielen lieben Dank für dieses Video. Super erklärt.
Top Video danke
Tolle Videos!
Ich finde deine Videos allesamt super!!!!! Vielen Dank für den Content :)
Richtig Nice !! DANKE
super video, vielen dank fürs uploaden!
Dankeschön!
tolles Video aber es gibt einen Fehler : Preis ist abhängig von die drei Primärschlüssel , da ArtikelNr 10 zwei Preise hat.
You are the best!
also bei der 2. NF guckt man jedes attribut an, ob es vom gesamten PK abhängt .... wenn net, extra relation richtig?
So kann man es kurz zusammenfassen.
gilt die zweite NF auch wenn ein nichtschlüsselattribut vom Superkey abängt oder darf das nichtschlüsselattribut nur vom "normalen" key abhängen?
Gutes Video aber es wurden von bspw. Frau Müller ja trotzdem 2 Artikel gekauft?! Warum muss man diese dann in der 2. Normalform dann nicht mehr darstellen?
Aber beim Schritt zur 2 Normalform fallen doch auch Sachen weg, davor war einmal der Dornfelder mit 10,99 und danach nicht. da fehlen ja dann sachen. Bei mir habe ich auch noch dopplungen, weiß nur nicht wie ich die tilgen soll, ohne welche einfach weg zulassen .
Ist man mit der 2. NF schon fertig, wenn man die Tabellen nicht noch verknüpft sondern einfach die 3 Tabellen so lässt?
Frage: Es gibt ja 5 Formen. Werden die Formen 4 und 5 auch noch behandelt bzw. wozu dient die 5.te Form?
Es gibt sogar 6, die Boyce Codd Normalform( nach der 3. NF)
Tolles Video. Kommt der Link zu den Unterlagen noch?
Y th best
Wäre es nicht denkbar, dass wenn mehrere Personen in einem Haus leben, dass man dann noch einen Adressschlüssel bilden muss. Ansonsten entsteht doch eine Redundanz in der Adresse, oder ?
Vielen lieben Dank Sebi für deine Super-Videos. Ich sehe sie mir zu meinen Aufgaben nocheinmal an und das hilft sooo unglaublich weiter!!! FRAGE: Ich brüte gerade über einer Aufgabe in der ich Teilenummern, Hersteller-ID und den Namen des Teils habe. Aus meiner sicht spräche nichts dagegen beide Nummern als zusammengesetzten Primärschlüssel zu verwenden, da nur beide zusammen einen eindeutigen Primärschlüssel abgeben. Wäre das eine Ausnahme von der Regel?
Das kann ich so nicht beurteilen, es hängt ja von der Beschaffenheit der Nummern ab und wie und in welchem Kontext sie eindeutig sind. Meine Antwort kann daher nur „Kann sein!“ lauten, was dir nicht hilft.
@@SebastianPhilippiTV ja das stimmt leider. Vielleicht klappt es ja so: Hersteller und Teilenummer bestehen jeweils aus einem Buchstaben und drei Ziffern und sie sind nur eindeutig, wenn ich sie zusammen verwende, da die Teilenummern teilweise identisch sind T001 usw. und auch die Produktbezeichnungen teilweise gleich sind (Allerdings haben einige Teile bei gleicher Nummer andere Bezeichnungen) , sie unterscheiden sich hauptsächlich durch den Hersteller.
Hier 4:24 ist doch Redundanzen vorgekommen und redundanzen sollen in 1NF schon verhindert worden sein. also ist die 1NF noch nicht erfüllt oder lege ich falsch?
Die 1NF verhindert keine Redundanzen, sie sorgt für Atomarität. :-)
@Sebastian Philippi 5:20 Streng genommen ist doch Name von RechNr abhängig oder nicht? Ich kann über die RechNr den Namen herrausfinden. Bspw. steht hinter RechNr. 2 immer der Name Müller...
Würde mich über eine antwort sehr freuen.
Nachtrag: ist PLZ nicht auch ein Primärschlüssel(kandidat), da hinter derselben PLZ nie unterschiedliche Ortsnamen stehen können? Müsste das nicht auch in eine eigene Tabelle?
@@NPC-xk7ko Ja, das mit der PLZ könnte man so machen. Kommt ein bisschen drauf an, wie man die Orte speichern will. In kleineren Städten und Gemeinden können sich schon mehrere Namen hinter der gleichen PLZ verbergen (am Beispiel unseres Städtchens Weilburg: 35781 Weilburg, 35781 Weilburg-Odersbach, 35781 Weilburg-Waldhausen,...). Diese Ortsnamen könnte man aber weglassen und damit über die PLZ als ID suchen.
Was den Namen angeht: Der Name ist deutlich stärker an die Kundennummer gebunden als an die Rechnung. In Datenbanken versuchen wir ja bekanntlich, Redundanzen zu vermeiden. Wenn ich jetzt also in jeder Rechnung immer wieder den Namen hinterlege, der auch in der Entität Kunde gespeichert ist, dann schaffe ich eine Redundanz, die a) sinnlos ist und b) mir im besten Fall später nicht auf die Füße fällt.
@@SebastianPhilippiTV vielen Dank für die schnelle Antwort
Kurz zu " Kommt ein bisschen drauf an, wie man die Orte speichern will" Das ist das alte Dilemma zwischen Theorie und Praxis :D. Wenns nicht gefordert ist, hab ich bis jetzt eh Datenbank intuitiv/unbewusst nach den drei Nf gelöst. Mir geht es jetzt so strikt wie möglich um die Definition/Theorie. Weniger "Bauchgefühl".
Zu den PLZ: ich hab mir dein Video der 3.Nf angeschaut und dort wird das "PLZ"-Beispiel ja benutzt. Gehen wir davon aus, das sowas wie 35781 Weilburg, 35781 Weilburg-Odersbach nicht existiert. (In der Beispieltabelle existiert es ja tatsächlich nicht).
Du gehst in diesem Video nochmal die Definition der 2.Nf durch und sagst "Alle Attribute hängen vom gesamten Primärschlüssel ab". Also praktisch die Definition, die du bereits hier verwendest.
Als ich das nochmal gehört habe, ist mir was aufgefallen. Und zwar das deine Definition, weicht leicht von der ab, die bei Wikipedia steht. Zitat: "Eine Relation ist genau dann in der zweiten Normalform, wenn die erste Normalform vorliegt und kein Nichtprimärattribut (Attribut, das nicht Teil eines Schlüsselkandidaten ist) funktional von einer echten Teilmenge eines Schlüsselkandidaten abhängt."
Wenn ich das richtig verstehe, ist die "Kollision" zwischen deiner Definition und die von Wikipedia die, dass du dich an den Primärschlüsseln orientierst, Wikipedia jedoch an den potenziellen Primärschlüsseln (Schlüsselkandidaten).
Folglich ist die Tabelle, nach der Definition von Wikipedia, aus deinem Video "Dritte Normalform (3NF) | Datenbanken" noch nicht in der 2. Nf, oder?
Zu deiner Antwort bzgl. des Namens: Das Name stärker an Kundennummer gebunden ist, geht nirgendwo hervor. Die Funktionale Abhängikeit besagt ja: "Eine Funktionale Abhängigkeit zwischen Attribut Y und Attribut X liegt dann vor, wenn es zu jedem X genau ein Y gibt."
Das trifft ja sowohl für Kdnr -> Name und Rechnr.-> Name zu.
Aber 1. ist es gesunder Menschenverstand das man Name zu Kunde und nicht zu Rechnung schreibt und 2. wiederspricht es ja keiner Definition.
Ich wollte nur anmerken, das man an der Stelle hätte sagen sollen das dort auch eine Abhängigkeit existiert.(und mich vergewissern das ich nicht falsch liege) :)
@@NPC-xk7ko Hi! Da merkt man, dass ich gar nicht vor habe, nach der Definition zu gehen. Natürlich hab ich das alles mal vor vielen Jahren in Datenbankenvorlesungen gehört, aber danach auch nur noch selten angewendet. In meinen Videos versuche ich mehr auf die Grundprinzipien des DB-Entwurfs zu zielen und Definitionsreiterei zu vermeiden. Ganz ehrlich? Die Definitionen müsste ich oftmals selbst nachlesen, weil ich sie nicht mal mehr präsent im Kopf habe. Das stößt natürlich denjenigen wie dir, die es dann wirklich genau wissen wollen, sauer auf. Das kann ich verstehen. :-)
@@SebastianPhilippiTV Vielen Dank das du dich meiner angenommen hast :)
Der Preis in Zeile 6 müsste doch ebenfalls 7,99 sein statt 4,99 sein oder?
Sie erklären alles immer so wunderbar, aber in diesem Video haben Sie etwas zu schnell geredet
und was wollte dieser Nachbar xD?
du redest zu schnell, versteht man nicht so gut