Morgen ist die Prüfung, wenn ich bestehe dann haben deine Videos auf jeden Fall mehr dazu beigetragen als viele vergeudete Stunden in der Berufsschule, dankechön
Hallo Herr Macke. Vielen Dank für die zahlreichen informativen Videos zum Thema IT! Diese haben mir bisher sehr weitergeholfen. Man darf dabei aber eines nicht vergessen: Chuck Norris bekommt bei Praktiker 20 Prozent auf alles. Auch auf Tiernahrung!
Du hast mir bisher so sehr geholfen, deine Videos und deine Tipps in deinem Podcast sind der Hammer, ich empfehle allen die eine IHK Prüfungen abgelegen wollen den Podcast, die Website, diese Videos und einen vorbereitungskurs der IHK. Danke für diese Tipps und deine Erfahrungen ❤
asserta = am Anfang & oben auf der Datenhalde vs. assertz = zuhinterst und ganz unten des Daten Heaps ... : Normalisierung wäre eine Vereinheitlichung der Datenspeicherung
Vielen Dank für dieses Video! Das hat mir sehr geholfen! Ich habe eine Frage, welche bei mir auf einem Übungsblatt vorkommt. Welche Redundanzen sind denn jeweils noch in der 1. und 2. NF, vor der Überführung in die 3. NF möglich? Sind nicht tatsächlich alle 3 Anomalien noch möglich vor der 3. NF? (Einfüge-, Update-, Löschanomalie)
In der 1. NF sind die Tabellen quasi voll mit Redundanzen. Die wurden ja sogar explizit eingeführt, um Wiederholungsgruppen aufzulösen. Und in der 2. NF führen die transitiven Abhängigkeiten zu Redundanzen. Beispiel: Mehrere Artikel haben die gleiche Artikelgruppe mit dem gleichen Namen/Rabatt, die mehrfach identisch in der Tabelle stehen.
Müste die 1NF nicht heißten: atomare Werte, keine wdh-Gruppen und Bestimmung eines Primärschlüssels? Weil es könnte ja sein, dass die Tabelle in der 0.ten NF, die vorliegt, keinen Primärschlüssel hat. Oder liege ich da falsch?
Den Primärschlüssel solltest du festlegen, das stimmt. Das ist aber nicht direkt Teil der Normalisierung, bei der es ja um die Vermeidung von Redundanzen geht. Und Schlüssel einzuführen verringert nicht die Redundanz. Dennoch ist das ein logischer Schritt, den du in der Praxis in der 1. NF durchführst.
Ist es in der 3. Normalform nicht theoretisch auch richtig, eine neue Tabelle für PLZ & Ort zu schaffen? Da diese ja theoretisch auch redundant auftreten können, da mehrere Kunden aus z.B. Köln kommen können.
Quasi dass Kunde die selben Attribute hat wie bisher, nur dass PLZ in Kunde ein FK ist und in der neuen Tabelle, ich nenne sie mal "Ort" PLZ der PK ist und Ort somit davon abhängig ist. An sich macht das ja keinen großen Unterschied. Aber wäre das auch richtig für die dritte Normalform oder wäre dies nicht gültig?@@StefanMacke
@@schlachs4hn316 Das geht leider so nicht. PLZ kann kein PK werden, weil sie nicht eindeutig ist. Es gibt mehrere Orte, die die gleiche PLZ haben und umgekehrt. Wie gesagt: m:n
heißt das, dass wenn die tabellen in der 3. Normalform vorliegen, dann bestehen nur noch 1:1 Beziehungen? hab das jetzt so verstanden, dass m:n bei der umstellung auf die 2. NF aufgelöst wird und 1:n bei der umstellung auf die 3. NF. sehe ich das richtig? danke für die wirklich sehr guten videos und podcasts.
Nein, die Kardinalitäten zwischen den Entitäten ändern sich nicht durch die Normalformen, nur ihre Abbildung in Tabellen. Aus einer m:n-Beziehung wird keine 1:1-Beziehung, sondern quasi zwei 1:n-Beziehungen. Und ja, die m:n-Beziehungen werden auf NF2 aufgelöst und 1:n auf NF3. Es können aber auch mal 1:n in der NF2 dabei sein, wie @carnaqe1154 schon schrieb.
Sie haben anfänglich erwähnt, dass es manchmal sinnvoll ist, Datenbanken nicht zu normalisieren. Haben Sie dafür noch ein Bsp.? Abgesehen von dem Aufwand, der durch eine Normalisierung entstehen könnte
Durch die Normalisierung werden oft bereits bei "simplen" Abfragen viele Tabellen gejoint, da die Daten auf mehrere Tabellen verteilt und wieder verknüpft werden müssen. Diese Operationen sind recht teuer. Wenn man eine schnelle Massenverarbeitung braucht, kann es sinnvoll sein, die Datenbank zu denormalisieren und dann mit einfachen SELECTs ohne JOIN zu arbeiten. Beispiel: Data Warehouse.
Wäre dann nicht "KundenNr->PLZ->Ort" auch noch transitiv? Wenn ich zwei Kunden aus einem Ort hätte, hätte ich somit weiterhin Redundanz... (oder Fahrradkette ;?)
@@StefanMacke In einer Prüfung des U-Form verlages war genau dies der Fall. Dort wurde erwartet, eine weitere Tabelle "Ort" zu erstellen in welcher man die Spalten "OrtID" "PLZ" und "Ort" hat. Wäre das denn richtig? Außerdem zu dem Thema speichersparen: Auch dazu war eine Frage im U-Form Heft. Da war die "Lösung" dass die Normalisierung zu einem Höheren speicherverbrauch führt, da man mehrere Tabellen hat.
In dieser Tabelle wäre ja die OrtID der eindeutige PK, also richtig so. Mehr Speicherplatz wegen mehr Tabellen!? Quatsch meiner Meinung nach. Nicht die Tabellen kosten Speicher, sondern die enthaltenen Daten.
@@StefanMacke Aber die OrtID könnte man ja auch in Ihrer Tabelle anlegen oder nicht? In der aufgabe des U-Form war diese auch nicht von Anfang an gegeben sondern man sollte diese selbst erstellen
Danke für das tolle Video. Was mich bei solchen Beispielen nur etwas stört, ist, dass sie nicht ganz praxistauglich sind. Was ist z.B. wenn der Kunde umzieht und eine neue Adresse hat. Wenn ich das in deinem Beispiel im Kundenstamm ändere, habe ich die Adressen von allen bereits bestehenden und abgeschlossenen Bestellungen auch geändert. Ich komm dann nie wieder an die alte Adresse. Was macht man da?
Für eine Einführung muss das Beispiel etwas einfacher sein. :-) Die von dir geschilderte Anforderung ist eine "Adresshistorie", bei der du eine m:n-Beziehung zwischen Kunde und Adresse hast. Die wird dann meist über eine Zuordnungstabelle mit zusätzlichen Informationen wie "gültig ab" und "gültig bis" ergänzt. Die Details kann ich hier jetzt nicht im Kommentar darlegen.
@@StefanMacke Ok, hat bisschen gedauert bis ich mich richtig in die Aufgabe hinein gedacht habe. Ja, du hast recht man braucht keine aufteilung, weil entweder nimmt man einen Zusammengesetzten Primärschlüssel aus PLZ und Ort und dann wird die Tabelle überflüssig oder man nimmt eine PLZ_Ort_Nummer. Zu zweiterem: kann sein, hab nur durchgeskippt.
@@StefanMacke Finde aber echt erschreckend, dass ich das insgesamt 3 Mal im Unterricht hatte und es niemandem aufgefallen ist. 1 mal im Informaik Abi und 2 mal in der Ausbildung.
ich hab in 50 Minuten hier mehr gelernt als in 1 1/2 Jahren Umschulung. Vielen Dank! 👌
Das freut mich sehr! 😄
Mega, dass du uns das hier kostenlos zur Verfügung stellst! Hilft mir sehr für unsere Azubis!
Gern geschehen! Freut mich, wenn ich helfen kann.
Ich kommentiere selten, aber das ist mir ein Bedürfnis. Wirklich super erklärt, mit wichtigem Inhalt und aufs Wesentliche fokussiert, Vielen Dank!
Danke, das freut mich. :-)
Die beste Erklärung zur Normalisierung, die ich je gehört habe. Top! 👌.Danke
Danke für das Lob!
Morgen ist die Prüfung, wenn ich bestehe dann haben deine Videos auf jeden Fall mehr dazu beigetragen als viele vergeudete Stunden in der Berufsschule, dankechön
Ich wünsche dir viel Erfolg!
Schreibe in einem Jahr meine Prüfungen und bin ihnen sehr dankbar für ihre Videos. Freue mich auf mehr :D
Ich drücke dir die Daumen! :-)
Sehr unterschätztes Video, meine Lehrerin hat dieselbe Tabelle benutzt, aber sie hat es nicht so gut erklärt wie du. Möge Gott dich segnen.
Danke, das freut mich sehr!
Hallo Herr Macke. Vielen Dank für die zahlreichen informativen Videos zum Thema IT! Diese haben mir bisher sehr weitergeholfen. Man darf dabei aber eines nicht vergessen: Chuck Norris bekommt bei Praktiker 20 Prozent auf alles. Auch auf Tiernahrung!
Hehe 😄 Ich werde beim nächsten Mal dran denken!
Wunderbare Video ich hab 2 mal geschaut und notizen gemacht supi erklärkt danke danke danke!
Gern geschehen :-)
Du hast mir bisher so sehr geholfen, deine Videos und deine Tipps in deinem Podcast sind der Hammer, ich empfehle allen die eine IHK Prüfungen abgelegen wollen den Podcast, die Website, diese Videos und einen vorbereitungskurs der IHK. Danke für diese Tipps und deine Erfahrungen ❤
Danke für dein Feedback. Das freut mich sehr. 😊
DANKE, du bist der erste wo ich es tatsächtlich verstehen konnte
wünschte meine lehrer wären nur so gut -.-
Danke für das Feedback. Gern geschehen! 😊
Schreibe morgen meine Klausur in datenbanken und das hat mir sehr gut geholfen es besser zu verstehen.
Dann wünsche ich dir viel Erfolg!
Vielen Dank, habe es jetzt endlich verstanden, statt nur auswendig gelernt!
So soll es sein! 😊
Vielen Dank, Herr Macke, alles sehr gut erklärt!
Danke für das Feedback. Das freut mich.
Krass gut erklärt, vor allem der part mit Normalisierung der Datenbanken
Freut mich, dass ich helfen kann! 😊
Stefan du bist der beste danke vielmals
Gern geschehen! ;-)
Mega Video
Danke, das freut mich! :-)
asserta = am Anfang & oben auf der Datenhalde vs. assertz = zuhinterst und ganz unten des Daten Heaps
... : Normalisierung wäre eine Vereinheitlichung der Datenspeicherung
Sorry, keine Ahnung was du damit sagen willst.
Vielen Dank für dieses Video! Das hat mir sehr geholfen!
Ich habe eine Frage, welche bei mir auf einem Übungsblatt vorkommt. Welche Redundanzen sind denn jeweils noch in der 1. und 2. NF, vor der Überführung in die 3. NF möglich?
Sind nicht tatsächlich alle 3 Anomalien noch möglich vor der 3. NF? (Einfüge-, Update-, Löschanomalie)
In der 1. NF sind die Tabellen quasi voll mit Redundanzen. Die wurden ja sogar explizit eingeführt, um Wiederholungsgruppen aufzulösen. Und in der 2. NF führen die transitiven Abhängigkeiten zu Redundanzen. Beispiel: Mehrere Artikel haben die gleiche Artikelgruppe mit dem gleichen Namen/Rabatt, die mehrfach identisch in der Tabelle stehen.
Vielen Dank! :) @@StefanMacke
Müste die 1NF nicht heißten: atomare Werte, keine wdh-Gruppen und Bestimmung eines Primärschlüssels? Weil es könnte ja sein, dass die Tabelle in der 0.ten NF, die vorliegt, keinen Primärschlüssel hat. Oder liege ich da falsch?
Den Primärschlüssel solltest du festlegen, das stimmt. Das ist aber nicht direkt Teil der Normalisierung, bei der es ja um die Vermeidung von Redundanzen geht. Und Schlüssel einzuführen verringert nicht die Redundanz. Dennoch ist das ein logischer Schritt, den du in der Praxis in der 1. NF durchführst.
@@StefanMacke Ah ok, danke 🙂👍
Ist es in der 3. Normalform nicht theoretisch auch richtig, eine neue Tabelle für PLZ & Ort zu schaffen? Da diese ja theoretisch auch redundant auftreten können, da mehrere Kunden aus z.B. Köln kommen können.
Wie würde diese Tabelle denn deiner Meinung nach aussehen? Denk daran, dass PLZ Ort eine m:n-Kardinalität hat.
Quasi dass Kunde die selben Attribute hat wie bisher, nur dass PLZ in Kunde ein FK ist und in der neuen Tabelle, ich nenne sie mal "Ort" PLZ der PK ist und Ort somit davon abhängig ist. An sich macht das ja keinen großen Unterschied. Aber wäre das auch richtig für die dritte Normalform oder wäre dies nicht gültig?@@StefanMacke
@@schlachs4hn316 Das geht leider so nicht. PLZ kann kein PK werden, weil sie nicht eindeutig ist. Es gibt mehrere Orte, die die gleiche PLZ haben und umgekehrt. Wie gesagt: m:n
heißt das, dass wenn die tabellen in der 3. Normalform vorliegen, dann bestehen nur noch 1:1 Beziehungen? hab das jetzt so verstanden, dass m:n bei der umstellung auf die 2. NF aufgelöst wird und 1:n bei der umstellung auf die 3. NF. sehe ich das richtig? danke für die wirklich sehr guten videos und podcasts.
Nein, die Kardinalitäten zwischen den Entitäten ändern sich nicht durch die Normalformen, nur ihre Abbildung in Tabellen. Aus einer m:n-Beziehung wird keine 1:1-Beziehung, sondern quasi zwei 1:n-Beziehungen.
Und ja, die m:n-Beziehungen werden auf NF2 aufgelöst und 1:n auf NF3. Es können aber auch mal 1:n in der NF2 dabei sein, wie @carnaqe1154 schon schrieb.
wurde nicht in der 2. Normalform auch schon eine 1 : N Beziehung aufgelöst mit Kunde und Bestellung? Fremdschlüssel in Bestellung?
Ja, das stimmt. Nur die Begründung ist eine andere (Abhängigkeit vom Teilschlüssel statt transitiver Abhängigkeit).
Gibt es irgendwo einen Ort, wo die Themen und evtl sogar m;glichen aufgaben stehen?
it-berufe-podcast.de/GAP1
"atomar" kommt etymologisch vom altgriechischen Wort "atomos", was "unteilbar" bedeuted...
Da hast du recht! Hier steht es auch nochmal: de.wikipedia.org/wiki/Atom
Sie haben anfänglich erwähnt, dass es manchmal sinnvoll ist, Datenbanken nicht zu normalisieren.
Haben Sie dafür noch ein Bsp.?
Abgesehen von dem Aufwand, der durch eine Normalisierung entstehen könnte
Durch die Normalisierung werden oft bereits bei "simplen" Abfragen viele Tabellen gejoint, da die Daten auf mehrere Tabellen verteilt und wieder verknüpft werden müssen. Diese Operationen sind recht teuer. Wenn man eine schnelle Massenverarbeitung braucht, kann es sinnvoll sein, die Datenbank zu denormalisieren und dann mit einfachen SELECTs ohne JOIN zu arbeiten. Beispiel: Data Warehouse.
@@StefanMacke Viel Dank für die schnelle Antwort!
Wäre dann nicht "KundenNr->PLZ->Ort" auch noch transitiv? Wenn ich zwei Kunden aus einem Ort hätte, hätte ich somit weiterhin Redundanz... (oder Fahrradkette ;?)
Ui, klassische Fehlannahme! PLZ/Ort ist eine m:n-Beziehung. Du kannst aus der PLZ nicht direkt auf den Ort schließen und auch nicht umgekehrt.
@@StefanMacke In einer Prüfung des U-Form verlages war genau dies der Fall. Dort wurde erwartet, eine weitere Tabelle "Ort" zu erstellen in welcher man die Spalten "OrtID" "PLZ" und "Ort" hat. Wäre das denn richtig? Außerdem zu dem Thema speichersparen: Auch dazu war eine Frage im U-Form Heft. Da war die "Lösung" dass die Normalisierung zu einem Höheren speicherverbrauch führt, da man mehrere Tabellen hat.
In dieser Tabelle wäre ja die OrtID der eindeutige PK, also richtig so. Mehr Speicherplatz wegen mehr Tabellen!? Quatsch meiner Meinung nach. Nicht die Tabellen kosten Speicher, sondern die enthaltenen Daten.
@@StefanMacke Aber die OrtID könnte man ja auch in Ihrer Tabelle anlegen oder nicht? In der aufgabe des U-Form war diese auch nicht von Anfang an gegeben sondern man sollte diese selbst erstellen
@@Voidyz Ja, aber was soll das bringen? Dadurch sparst du ja keine Redundanz!?
Danke für das tolle Video. Was mich bei solchen Beispielen nur etwas stört, ist, dass sie nicht ganz praxistauglich sind. Was ist z.B. wenn der Kunde umzieht und eine neue Adresse hat. Wenn ich das in deinem Beispiel im Kundenstamm ändere, habe ich die Adressen von allen bereits bestehenden und abgeschlossenen Bestellungen auch geändert. Ich komm dann nie wieder an die alte Adresse. Was macht man da?
Für eine Einführung muss das Beispiel etwas einfacher sein. :-) Die von dir geschilderte Anforderung ist eine "Adresshistorie", bei der du eine m:n-Beziehung zwischen Kunde und Adresse hast. Die wird dann meist über eine Zuordnungstabelle mit zusätzlichen Informationen wie "gültig ab" und "gültig bis" ergänzt. Die Details kann ich hier jetzt nicht im Kommentar darlegen.
also ehrlich jetzt, das waren 20% auf tiernahrung früher ;)
Hehe 😄
Ich bin sad. Du hast für die 3. NF PLZ und Ort vergessen. Und bei der 1. NF Straße und Hausnummer.🥲
Ich bin sad, dass du PLZ/Ort nicht als m:n erkennst. :-P Und Straße/Hausnummer habe ich im Video begründet (glaube ich).
@@StefanMacke Ok, hat bisschen gedauert bis ich mich richtig in die Aufgabe hinein gedacht habe. Ja, du hast recht man braucht keine aufteilung, weil entweder nimmt man einen Zusammengesetzten Primärschlüssel aus PLZ und Ort und dann wird die Tabelle überflüssig oder man nimmt eine PLZ_Ort_Nummer.
Zu zweiterem: kann sein, hab nur durchgeskippt.
@@StefanMacke Finde aber echt erschreckend, dass ich das insgesamt 3 Mal im Unterricht hatte und es niemandem aufgefallen ist. 1 mal im Informaik Abi und 2 mal in der Ausbildung.
@@ramon2282 So sieht es aus! :-) Aber du bist nicht der erste, der PLZ/Ort so nicht auf dem Schirm hatte.