Warum kann ich bei 2:12 nicht einfach Datensatz Nr. 5 updaten? Im Video wird behauptet, um das neue Projekt zu Brunhildes hinzuzufügen, muss man zwingend einen neuen Datensatz anlegen. Aber an Datensatz 3 sieht man doch, dass es genügt, die drei Attribute "ProjektNr", "Beschreibung" und "Zeit" upzudaten. Dann habe ich natürlich in Datensatz Nr. 5 die Atomarität verletzt, aber Datensatz 3 zeigt ja, dass an dieser Stelle noch keine Rolle spielt.
Wenn ich z.B. Mitarbeiter 5 einem Projekt zuordnen möchte, z.B. Projekt 3, dann muss ich in der linken Tabelle (= Version A bzw. "Nullte Normalform") eine neue Tabellenzeile komplett ausfüllen ( = 8 Felder) Mache ich das in der 3. Normalform ("Verson B"), dann genügt es tatsächlich, in der Tabelle "Mitarbeiter in Projekten" eine neue Zeile mit lediglich 3 Feldern zu ergänzen. Somit lohnt es sich, die EINE Tabelle (links) in MEHRERE kleine und verknüpfte Tabellen (rechts) aufzuteilen, weil ich mir dann 63% des Aufwands spare.
Wirklich sehr gut erklärt und damit auch hilfreich. Dennoch sind ein paar Fehlerchen bei der Fortführung entstanden. Das dürfte vielleicht insbesondere Anfänger irritieren >> 1. Im Ausgangsdatenbestand bei 0:33 gibt es bereits Name und Vorname. Bei 4:48 wird ein Ausgangsdatenbestand eingeblendet, bei dem Name und Vorname noch in zwei Spalten erscheinen. 2. Namensfehler: Theodor Willschrein (0:33) heißt ein paar Minuten später Theodor Müller. 3. Sophia Lorenz ist später Sophia Lorenz-Meier und Hans-Otto Richter wird zu Otto Richter. Und gerade noch entdeckt: Brunhilde Wiesenland wird zu Hertha Wiesenland
1:40 Da die Tabelle in Version A nicht atomar ist reicht es aus Projektnummer, Beschreibung und Zeit zu ändern. Deshalb ist der Zeitaufwand in diesem Beispiel der gleiche ;).
Muss ein zusammengesetzter Primärschlüssel eigentlich allgemeingültigkeit besitzen, also auch alle zukünftigen Datensätze eindeutig identifizieren? Oder reicht es, wenn man sich auf den aktuellen Bestand der Datensätze konzentriert? Bei Letzterem wäre dann nämlich auch PersNr und Zeit, bzw Projektor und Zeit Schlüsselkandidaten (aber natürlich bei zusätzlichen Datensätzen dann potentiell nicht mehr eindeutig) Das geht aus der Schlüsseldefinition irgendwie nicht hervor...
Ne ernstgemeinte Frage? Die Zeit ist nur ein Attribut und trägt nicht zur Identifizierung bei. Abgesehen davon muss es immer für alle zukünftigen Daten genauso Gültigkeit haben. Dialog: A: Das Projekt 22 hat 92 min. gedauert. B: Ahja, Herr Müller sein Projekt, der braucht immer 92 min. Macht kein Sinn oder...
@@AmnesyInt. Nun, da die Werte des (zusammengesetzten) Primärschlüssels einen Datensatz eindeutig kennzeichnen (die mir bekannte Definition), ist dies in dem Beispiel durch die Zeit durchaus gegeben. Meine Frage ist halt, ob dies nur für bestehende Datensätze gilt, weil das aus der Primärschlüsseldefinition nicht hervorgeht. Dein Einwand mit den zukünftigen Daten ist ja jetzt ersteinmal nur eine Setzung Deinerseits - aber wenn du eine Definition parat hast, aus der das hervorgeht, gerne her damit :) Zu dem Dialog: Gemäß der Beispieldatenbank braucht Herr Müller für Projekt 2 selbstverständlich "immer" 92 Minuten. Zu jeder Projekt-Mitarbeiter-Zuordnung existiert ja schießlich nur eine Zeit.
@@m0ZZaik Das Design muss immer allgemeingültig sein, auch für zukünftige Daten. Eine Datenbank ist ja dazu da um, wenn's sein muss, Millionen von neuen Daten aufzunehmen. Die Definition ergibt sich aus der 2. und 3. Normalform. Die Zeit ist funktional abhängig von der Persnr und der Projektnr.
Es war interessant und informativ allerdings gibt es auch noch zusätzliche Datengedöns .Ist absolut interessant auch grade dann wenn es einem selbst gut erklärt wird .
Ehrlich: tolles Video aber die Argumente überzeugen mich nicht ;) meiner MEinung sind diese sehr konstruiert, da man zwar bspw. zwar von Fehlervermeidung spricht aber nicht darauf eingeht, dass zwei zahlen genauso leicht vertasuscht werden können. auch der ARbeitsaufwand ist bei Version A denkbar gering, denn für das neue Projekt muss in zwei felder folgendes eingegeben eingegeben werden, ",1" ",160". Mir ist schon klar, dass Version B besser ist, aber die Argumente sind für mich nicht griffig genug.
Das ist alles unfassbar verständlich formuliert. Wenn du das Video nicht verstehst, scheinst du ernsthafte Defizite in diesem Bereich zu haben und solltest dir schleunigst nochmal die Grundlagen von SQL anschauen :D
Das ist gut und gleichzeitig nicht zu langatmig erklärt, dankeschön.
Meine Rettung 8 Stunden vor der Prüfung :D
und 4 Stunden bei mir hahahaha
hab noch 24 Stunden, um alles zu lernen ^^
Chill1Sec dann mal viel erfolg, durch das video bestimmt machbar :)
@@sarahsoltany6782 hoffentlich. Ansich auch nicht so schwer. Hast du denn bestanden gehabt? :)
Chill1Sec Ja damals schon. weiß zwar immer noch nicht wie aber tatsächlich ja 😄
Eine bessere ERklärung gibt es nicht! Top
alle 3 Videos perfekt. Danke für deine Mühe.
Hast mir die Klausur gerettet, vielen Dank!
Eine sehr gute "Reihe" zu den Normalformen!
Danke sehr. :)
W12A 22/23 von FOS/BOS ER war hier
Warum kann ich bei 2:12 nicht einfach Datensatz Nr. 5 updaten? Im Video wird behauptet, um das neue Projekt zu Brunhildes hinzuzufügen, muss man zwingend einen neuen Datensatz anlegen. Aber an Datensatz 3 sieht man doch, dass es genügt, die drei Attribute "ProjektNr", "Beschreibung" und "Zeit" upzudaten. Dann habe ich natürlich in Datensatz Nr. 5 die Atomarität verletzt, aber Datensatz 3 zeigt ja, dass an dieser Stelle noch keine Rolle spielt.
Wenn ich z.B. Mitarbeiter 5 einem Projekt zuordnen möchte, z.B. Projekt 3, dann muss ich in der linken Tabelle (= Version A bzw. "Nullte Normalform") eine neue Tabellenzeile komplett ausfüllen ( = 8 Felder)
Mache ich das in der 3. Normalform ("Verson B"), dann genügt es tatsächlich, in der Tabelle "Mitarbeiter in Projekten" eine neue Zeile mit lediglich 3 Feldern zu ergänzen.
Somit lohnt es sich, die EINE Tabelle (links) in MEHRERE kleine und verknüpfte Tabellen (rechts) aufzuteilen, weil ich mir dann 63% des Aufwands spare.
Rettung Rettung und Rettung
und ein letztes mal RETTUNG !!!!
Danke dir!!!!
Sehr gut erklärt, hatte niemand geschafft so anschaulich in meinen 2 Jahren Info an der Schule zu erklären!
Wirklich sehr gut erklärt und damit auch hilfreich. Dennoch sind ein paar Fehlerchen bei der Fortführung entstanden. Das dürfte vielleicht insbesondere Anfänger irritieren >> 1. Im Ausgangsdatenbestand bei 0:33 gibt es bereits Name und Vorname. Bei 4:48 wird ein Ausgangsdatenbestand eingeblendet, bei dem Name und Vorname noch in zwei Spalten erscheinen. 2. Namensfehler: Theodor Willschrein (0:33) heißt ein paar Minuten später Theodor Müller. 3. Sophia Lorenz ist später Sophia Lorenz-Meier und Hans-Otto Richter wird zu Otto Richter. Und gerade noch entdeckt: Brunhilde Wiesenland wird zu Hertha Wiesenland
1:40 Da die Tabelle in Version A nicht atomar ist reicht es aus Projektnummer, Beschreibung und Zeit zu ändern. Deshalb ist der Zeitaufwand in diesem Beispiel der gleiche ;).
Guter Punkt - ein neuer Datensatz wäre nur für einen neuen Mitarbeiter fällig...
Perfekt! Sehr gute Arbeit!
Danke, das ist echt super erklärt
Danke für das Video ! Sehr gut
Muss ein zusammengesetzter Primärschlüssel eigentlich allgemeingültigkeit besitzen, also auch alle zukünftigen Datensätze eindeutig identifizieren? Oder reicht es, wenn man sich auf den aktuellen Bestand der Datensätze konzentriert?
Bei Letzterem wäre dann nämlich auch PersNr und Zeit, bzw Projektor und Zeit Schlüsselkandidaten (aber natürlich bei zusätzlichen Datensätzen dann potentiell nicht mehr eindeutig)
Das geht aus der Schlüsseldefinition irgendwie nicht hervor...
Ne ernstgemeinte Frage?
Die Zeit ist nur ein Attribut und trägt nicht zur Identifizierung bei. Abgesehen davon muss es immer für alle zukünftigen Daten genauso Gültigkeit haben.
Dialog:
A: Das Projekt 22 hat 92 min. gedauert.
B: Ahja, Herr Müller sein Projekt, der braucht immer 92 min.
Macht kein Sinn oder...
@@AmnesyInt. Nun, da die Werte des (zusammengesetzten) Primärschlüssels einen Datensatz eindeutig kennzeichnen (die mir bekannte Definition), ist dies in dem Beispiel durch die Zeit durchaus gegeben. Meine Frage ist halt, ob dies nur für bestehende Datensätze gilt, weil das aus der Primärschlüsseldefinition nicht hervorgeht. Dein Einwand mit den zukünftigen Daten ist ja jetzt ersteinmal nur eine Setzung Deinerseits - aber wenn du eine Definition parat hast, aus der das hervorgeht, gerne her damit :)
Zu dem Dialog: Gemäß der Beispieldatenbank braucht Herr Müller für Projekt 2 selbstverständlich "immer" 92 Minuten. Zu jeder Projekt-Mitarbeiter-Zuordnung existiert ja schießlich nur eine Zeit.
@@m0ZZaik Das Design muss immer allgemeingültig sein, auch für zukünftige Daten. Eine Datenbank ist ja dazu da um, wenn's sein muss, Millionen von neuen Daten aufzunehmen.
Die Definition ergibt sich aus der 2. und 3. Normalform.
Die Zeit ist funktional abhängig von der Persnr und der Projektnr.
Danke für das Video !
Du hast mich grade so richtig gerettett :) (Schreibe am Freitag meine Prüfung darüber)
Kann man die 1. Normalform als ER-Modell darstellen? Wenn ich das ganze richtig verstanden habe ist die 1. Normalform ja "nur" eine Tabelle?
Das ist eigentlich kein Problem - dann hat man eben nur einen Entitätstyp ("Rechteck") mit einer Reihe von Attributen ("Ellipsen").
Es war interessant und informativ allerdings gibt es auch noch zusätzliche Datengedöns .Ist absolut interessant auch grade dann wenn es einem selbst gut erklärt wird .
Super erläutert, danke!
Dankeschön, gute Arbeit
Ist die erste Normalform immer nur EINE Tabelle?
Das können auch mehrere Tabellen sein, die den Anforderungen der 1. NF entsprechen (atomare Werte + eindeutiger Primärschlüssel).
gutes video !
Danke
für jeden den es interessiert: zusammengesetzte Primärschlüssel nennt man auch "funktional abhängig". Sind in der zweiten dann verboten.
Ganz toll erklärt danke
Sehr gut erklärt!
Danke für dieses Video :)
Ich verstehe nicht genau wie man ein weiteren Schlüssel auswählt. Bitte eine Antwort
Das wird doch genau im Video erklärt - ab 6:32 …..
Super Video
kek
war da nicht noch was mit wiederholungsgruppen? scheint mir unvollstaendig.
echt top erklärt :)
Ehrlich: tolles Video aber die Argumente überzeugen mich nicht ;) meiner MEinung sind diese sehr konstruiert, da man zwar bspw. zwar von Fehlervermeidung spricht aber nicht darauf eingeht, dass zwei zahlen genauso leicht vertasuscht werden können. auch der ARbeitsaufwand ist bei Version A denkbar gering, denn für das neue Projekt muss in zwei felder folgendes eingegeben eingegeben werden, ",1" ",160".
Mir ist schon klar, dass Version B besser ist, aber die Argumente sind für mich nicht griffig genug.
Danke fürs Feedback!
Vielen Dank! :)
Vielen Dank!!!
Danke!!!
ich checks nicht, viel zu viele fremdwörter..
Das sind die Grundbegriffe. Um die kommt man nicht herum.
Das ist alles unfassbar verständlich formuliert. Wenn du das Video nicht verstehst, scheinst du ernsthafte Defizite in diesem Bereich zu haben und solltest dir schleunigst nochmal die Grundlagen von SQL anschauen :D
Munanyo
top dankölölöllölöölöö
:)
Ich versteh wirklich garnichts
schade!
Danke!