Paradigma: Der englische Name ist Normalform. Er wurde vom Briten E.F. Codd (dem Vorfahren der relationalen Datenbank) zusammengefasst, nachdem er in den 1970er Jahren das relationale Datenbankmodell vorgeschlagen hatte Grundlage unserer Arbeit in relationalen Datenbanken. Die Regeln und Richtlinien, die beim Entwurf einer Datenbankstruktur befolgt werden müssen. Derzeit können 8 Paradigmen verfolgt werden, in der Reihenfolge: 1NF, 2NF, 3NF, BCNF, 4NF, 5NF, DKNF und 6NF. Normalerweise werden nur die ersten drei Normalformen verwendet, nämlich: erste Normalform (1NF), zweite Normalform (2NF) und dritte Normalform (3NF). Im Folgenden finden Sie eine kurze Einführung in diese drei Paradigmen.
◆ Erste Normalform (1NF): Sie betont die Atomizität von Spalten, das heißt, Spalten können nicht in andere Spalten unterteilt werden.
Betrachten Sie eine solche Tabelle: [Kontakt] (Name, Geschlecht, Telefonnummer)
Wenn in einem tatsächlichen Szenario ein Kontakt eine private Telefonnummer und eine geschäftliche Telefonnummer hat, dann erreicht dieser Tabellenstrukturentwurf nicht 1NF . Um 1NF einzuhalten, müssen wir nur die Spalte (Telefon) aufteilen, nämlich: [Kontaktperson] (Name, Geschlecht, private Telefonnummer, Firmentelefonnummer). 1NF ist leicht zu unterscheiden, aber 2NF und 3NF können leicht verwechselt werden.
◆ Zweite Normalform (2NF): Die erste ist 1NF und enthält auch zwei Teile: Erstens muss die Tabelle einen Primärschlüssel haben; zweitens müssen die Spalten, die nicht im Primärschlüssel enthalten sind, vollständig vom Primärschlüssel abhängig sein Schlüssel und kann sich nicht nur auf den Primärschlüssel verlassen.
Betrachten Sie eine Bestelldetailtabelle: [OrderDetail] (OrderID, ProductID, UnitPrice, Discount, Quantity, ProductName).
Da wir wissen, dass mehrere Produkte in einer Bestellung bestellt werden können, reicht eine OrderID allein nicht aus, um der Primärschlüssel zu sein. Der Primärschlüssel sollte (OrderID, ProductID) sein. Offensichtlich sind Discount und Quantity vollständig vom Primärschlüssel (OderID, ProductID) abhängig, während UnitPrice und ProductName nur von ProductID abhängen. Die OrderDetail-Tabelle entspricht also nicht 2NF. Designs, die nicht 2NF entsprechen, sind anfällig für redundante Daten.
Die Tabelle [OrderDetail] kann in [OrderDetail] (OrderID, ProductID, Discount, Quantity) und [Product] (ProductID, UnitPrice, ProductName) aufgeteilt werden, um mehrfache Wiederholungen von UnitPrice und ProductName in der ursprünglichen Bestelltabelle zu vermeiden.
◆ Dritte Normalform (3NF): Erstens ist es 2NF. Darüber hinaus müssen Nicht-Primärschlüsselspalten direkt vom Primärschlüssel abhängen und es darf keine transitive Abhängigkeit geben. Das heißt, es kann nicht existieren: Nicht-Primärschlüssel-Spalte A hängt von Nicht-Primärschlüssel-Spalte B ab, und Nicht-Primärschlüssel-Spalte B hängt vom Primärschlüssel ab.
Stellen Sie sich eine Bestelltabelle [Order] (OrderID, OrderDate, CustomerID, CustomerName, CustomerAddr, CustomerCity) vor, in der der Primärschlüssel (OrderID) ist.
Darunter sind OrderDate, CustomerID, CustomerName, CustomerAddr, CustomerCity und andere Nicht-Primärschlüsselspalten vollständig vom Primärschlüssel (OrderID) abhängig, sodass sie 2NF entsprechen. Das Problem besteht jedoch darin, dass CustomerName, CustomerAddr und CustomerCity direkt von CustomerID (nicht primäre Schlüsselspalte) abhängen, anstatt sich direkt auf den Primärschlüssel zu verlassen. Sie sind bei der Übertragung auf den Primärschlüssel angewiesen und entsprechen daher nicht 3NF.
Erreichen Sie 3NF, indem Sie [Order] in [Order] (OrderID, OrderDate, CustomerID) und [Customer] (CustomerID, CustomerName, CustomerAddr, CustomerCity) aufteilen.
Die Konzepte der zweiten Normalform (2NF) und der dritten Normalform (3NF) können leicht verwechselt werden. Der entscheidende Punkt, um sie zu unterscheiden, ist 2NF: ob die Nicht-Primärschlüsselspalte vollständig vom Primärschlüssel abhängt oder nicht Teil des Primärschlüssels; 3NF: Nicht-Primärschlüsselspalte Ob die Primärschlüsselspalte direkt vom Primärschlüssel abhängt oder direkt von der Nicht-Primärschlüsselspalte abhängt.
Paradigma: Der englische Name ist Normalform. Er wurde vom Briten E.F. Codd (dem Vorfahren der relationalen Datenbank) zusammengefasst, nachdem er in den 1970er Jahren das relationale Datenbankmodell vorgeschlagen hatte Grundlage unserer Arbeit in relationalen Datenbanken. Die Regeln und Richtlinien, die beim Entwurf einer Datenbankstruktur befolgt werden müssen. Derzeit können 8 Paradigmen verfolgt werden, in der Reihenfolge: 1NF, 2NF, 3NF, BCNF, 4NF, 5NF, DKNF und 6NF. Normalerweise werden nur die ersten drei Normalformen verwendet, nämlich: erste Normalform (1NF), zweite Normalform (2NF) und dritte Normalform (3NF). Im Folgenden finden Sie eine kurze Einführung in diese drei Paradigmen.
◆ Erste Normalform (1NF): Sie betont die Atomizität von Spalten, das heißt, Spalten können nicht in andere Spalten unterteilt werden.
Betrachten Sie eine solche Tabelle: [Kontakt] (Name, Geschlecht, Telefonnummer)
Wenn in einem tatsächlichen Szenario ein Kontakt eine private Telefonnummer und eine geschäftliche Telefonnummer hat, dann erreicht dieser Tabellenstrukturentwurf nicht 1NF . Um 1NF einzuhalten, müssen wir nur die Spalte (Telefon) aufteilen, nämlich: [Kontaktperson] (Name, Geschlecht, private Telefonnummer, Firmentelefonnummer). 1NF ist leicht zu unterscheiden, aber 2NF und 3NF können leicht verwechselt werden.
◆ Zweite Normalform (2NF): Die erste ist 1NF und enthält auch zwei Teile: Erstens muss die Tabelle einen Primärschlüssel haben; zweitens müssen die Spalten, die nicht im Primärschlüssel enthalten sind, vollständig vom Primärschlüssel abhängig sein Schlüssel und kann sich nicht nur auf den Primärschlüssel verlassen.
Betrachten Sie eine Bestelldetailtabelle: [OrderDetail] (OrderID, ProductID, UnitPrice, Discount, Quantity, ProductName).
Da wir wissen, dass mehrere Produkte in einer Bestellung bestellt werden können, reicht eine OrderID allein nicht aus, um der Primärschlüssel zu sein. Der Primärschlüssel sollte (OrderID, ProductID) sein. Offensichtlich sind Discount und Quantity vollständig vom Primärschlüssel (OderID, ProductID) abhängig, während UnitPrice und ProductName nur von ProductID abhängen. Die OrderDetail-Tabelle entspricht also nicht 2NF. Designs, die nicht 2NF entsprechen, sind anfällig für redundante Daten.
Die Tabelle [OrderDetail] kann in [OrderDetail] (OrderID, ProductID, Discount, Quantity) und [Product] (ProductID, UnitPrice, ProductName) aufgeteilt werden, um mehrfache Wiederholungen von UnitPrice und ProductName in der ursprünglichen Bestelltabelle zu vermeiden.
◆ Dritte Normalform (3NF): Erstens ist es 2NF. Darüber hinaus müssen Nicht-Primärschlüsselspalten direkt vom Primärschlüssel abhängen und es darf keine transitive Abhängigkeit geben. Das heißt, es kann nicht existieren: Nicht-Primärschlüssel-Spalte A hängt von Nicht-Primärschlüssel-Spalte B ab, und Nicht-Primärschlüssel-Spalte B hängt vom Primärschlüssel ab.
Stellen Sie sich eine Bestelltabelle [Order] (OrderID, OrderDate, CustomerID, CustomerName, CustomerAddr, CustomerCity) vor, in der der Primärschlüssel (OrderID) ist.
Darunter sind OrderDate, CustomerID, CustomerName, CustomerAddr, CustomerCity und andere Nicht-Primärschlüsselspalten vollständig vom Primärschlüssel (OrderID) abhängig, sodass sie 2NF entsprechen. Das Problem besteht jedoch darin, dass CustomerName, CustomerAddr und CustomerCity direkt von CustomerID (nicht primäre Schlüsselspalte) abhängen, anstatt sich direkt auf den Primärschlüssel zu verlassen. Sie sind bei der Übertragung auf den Primärschlüssel angewiesen und entsprechen daher nicht 3NF.
Erreichen Sie 3NF, indem Sie [Order] in [Order] (OrderID, OrderDate, CustomerID) und [Customer] (CustomerID, CustomerName, CustomerAddr, CustomerCity) aufteilen.
Die Konzepte der zweiten Normalform (2NF) und der dritten Normalform (3NF) können leicht verwechselt werden. Der entscheidende Punkt, um sie zu unterscheiden, ist 2NF: ob die Nicht-Primärschlüsselspalte vollständig vom Primärschlüssel abhängt oder nicht Teil des Primärschlüssels; 3NF: Nicht-Primärschlüsselspalte Ob die Primärschlüsselspalte direkt vom Primärschlüssel abhängt oder direkt von der Nicht-Primärschlüsselspalte abhängt.
Das obige ist der detaillierte Inhalt vonWas ist die erste Normalform, die zweite Normalform und die dritte Normalform einer Datenbank?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
