Natuurlijk! Hier is een overzicht van hoe je een genormaliseerd SQL-databasemodel kunt ontwerpen, inclusief datatypes, relaties en uitleg over normalisatieniveaus: 1. Entiteiten en attributen: - Klant: - KlantID: INTEGER, PRIMARY KEY - Naam: VARCHAR(100) - Email: VARCHAR(100) - Product: - ProductID: INTEGER, PRIMARY KEY - Naam: VARCHAR(100) - Prijs: DECIMAL(10,2) - Bestelling: - BestellingID: INTEGER, PRIMARY KEY - KlantID: INTEGER, FOREIGN KEY verwijzend naar Klant(KlantID) - Datum: DATE (optioneel, voor bestellingsdatum) - Bestelling_Product (om de veel-op-veel relatie tussen Bestelling en Product te modelleren): - BestellingID: INTEGER, FOREIGN KEY verwijzend naar Bestelling(BestellingID) - ProductID: INTEGER, FOREIGN KEY verwijzend naar Product(ProductID) - Aantal: INTEGER 2. Normalisatieprincipes: - **Eerste normaalvorm (1NF):** Zorg dat alle attributen atomair zijn en dat elke kolom enkelvoudige waarden bevat. Bijvoorbeeld, in de tabel Bestelling_Product bevat Aantal slechts één waarde per rij. - **Tweede normaalvorm (2NF):** Alle niet-sleutel attributen moeten volledig afhankelijk zijn van de hele primaire sleutel. Omdat Bestelling_Product een samengestelde sleutel heeft (BestellingID, ProductID), moeten kolommen zoals Aantal volledig afhankelijk zijn van beide. In de andere tabellen is dit vanzelfsprekend omdat elke tabel een enkele primaire sleutel heeft. - **Derde normaalvorm (3NF):** Geen transitieve afhankelijkheden. Bijvoorbeeld, als je een kolom 'KlantAdres' zou hebben, zou die niet afhankelijk moeten zijn van KlantID, maar dat is hier niet het geval. 3. Voorbeeld van normalisatie in je ontwerp: - **Probleem bij redundantie:** Zonder een aparte tabel voor Bestelling_Product zou je kunnen denken dat je het aantal producten direct in de Bestelling plaatst, maar dat beperkt de flexibiliteit en creëert redundantie als je meerdere producten hebt. - **Oplossing:** Door een tussentabel (Bestelling_Product) te gebruiken, voorkom je redundantie en houd je de data consistent. 4. Voorbeeld SQL-schema: ```sql CREATE TABLE Klant ( KlantID INT PRIMARY KEY, Naam VARCHAR(100), Email VARCHAR(100) ); CREATE TABLE Product ( ProductID INT PRIMARY KEY, Naam VARCHAR(100), Prijs DECIMAL(10,2) ); CREATE TABLE Bestelling ( BestellingID INT PRIMARY KEY, KlantID INT, Datum DATE, FOREIGN KEY (KlantID) REFERENCES Klant(KlantID) ); CREATE TABLE Bestelling_Product ( BestellingID INT, ProductID INT, Aantal INT, PRIMARY KEY (BestellingID, ProductID), FOREIGN KEY (BestellingID) REFERENCES Bestelling(BestellingID), FOREIGN KEY (ProductID) REFERENCES Product(ProductID) ); ``` **Samenvatting:** Door gebruik te maken van genormaliseerde tabellen en een tussentabel voor de veel-op-veel relatie, minimaliseer je redundantie en verbeter je de dataintegriteit. Zorg dat elke tabel een duidelijke primaire sleutel heeft en dat buitenlandse sleutels referenties correct zijn. Dit ontwerp voldoet aan de principes van normalisatie en is flexibel voor verdere uitbreidingen.

Zeker, ik help je graag met het ontwerpen van een genormaliseerde SQL-database. Hier is een gedetailleerd ontwerp volgens de normalisatieprincipes: ## Database Schema Ontwerp ### Tabellen en Datatypes **Klant Tabel:** ```sql CREATE TABLE Klant ( KlantID INT PRIMARY KEY AUTO_INCREMENT, Naam VARCHAR(100) NOT NULL, Email VARCHAR(255) NOT NULL UNIQUE, CONSTRAINT chk_email_format CHECK (Email LIKE '%_@__%.__%') ); ``` **Product Tabel:** ```sql CREATE TABLE Product ( ProductID INT PRIMARY KEY AUTO_INCREMENT, Naam VARCHAR(100) NOT NULL, Prijs DECIMAL(10,2) NOT NULL CHECK (Prijs >= 0), CONSTRAINT chk_prijs_positief CHECK (Prijs >= 0) ); ``` **Bestelling Tabel:** ```sql CREATE TABLE Bestelling ( BestellingID INT PRIMARY KEY AUTO_INCREMENT, KlantID INT NOT NULL, Besteldatum TIMESTAMP DEFAULT CURRENT_TIMESTAMP, Totaalbedrag DECIMAL(10,2) DEFAULT 0, FOREIGN KEY (KlantID) REFERENCES Klant(KlantID) ON DELETE CASCADE ); ``` **Bestelregel Tabel (junction table):** ```sql CREATE TABLE Bestelregel ( BestellingID INT NOT NULL, ProductID INT NOT NULL, Aantal INT NOT NULL CHECK (Aantal > 0), PrijsPerStuk DECIMAL(10,2) NOT NULL, PRIMARY KEY (BestellingID, ProductID), FOREIGN KEY (BestellingID) REFERENCES Bestelling(BestellingID) ON DELETE CASCADE, FOREIGN KEY (ProductID) REFERENCES Product(ProductID) ON DELETE RESTRICT ); ``` ## Toepassing Normalisatieniveaus ### 1NF (Eerste Normaalvorm) - Elimineer herhalende groepen - Elke tabel heeft een primaire sleutel - Alle velden bevatten atomaire waarden (niet verder deelbaar) - Geen herhalende groepen kolommen ### 2NF (Tweede Normaalvorm) - Verwijder gedeeltelijke afhankelijkheden - Alle niet-sleutelattributen zijn volledig functioneel afhankelijk van de primaire sleutel - In Bestelregel: PrijsPerStuk is afhankelijk van zowel BestellingID als ProductID ### 3NF (Derde Normaalvorm) - Verwijder transitieve afhankelijkheden - Geen transitieve afhankelijkheden (niet-sleutelattributen zijn alleen afhankelijk van de primaire sleutel) - Totaalbedrag in Bestelling wordt berekend, niet opgeslagen (zie trigger voorbeeld) ## Voorbeeld Queries **Insert voorbeeld:** ```sql -- Klant toevoegen INSERT INTO Klant (Naam, Email) VALUES ('Jan Jansen', 'jan@voorbeeld.nl'); -- Product toevoegen INSERT INTO Product (Naam, Prijs) VALUES ('Laptop', 899.99); -- Bestelling plaatsen INSERT INTO Bestelling (KlantID) VALUES (1); INSERT INTO Bestelregel (BestellingID, ProductID, Aantal, PrijsPerStuk) VALUES (1, 1, 2, (SELECT Prijs FROM Product WHERE ProductID = 1)); ``` **Query voor bestellingsoverzicht:** ```sql SELECT b.BestellingID, k.Naam AS KlantNaam, p.Naam AS ProductNaam, br.Aantal, br.PrijsPerStuk, (br.Aantal * br.PrijsPerStuk) AS Totaal FROM Bestelling b JOIN Klant k ON b.KlantID = k.KlantID JOIN Bestelregel br ON b.BestellingID = br.BestellingID JOIN Product p ON br.ProductID = p.ProductID; ``` ## Aanvullende Optimalisaties **Trigger voor automatisch totaalbedrag:** ```sql CREATE TRIGGER update_bestelling_totaal AFTER INSERT ON Bestelregel FOR EACH ROW BEGIN UPDATE Bestelling SET Totaalbedrag = ( SELECT SUM(Aantal * PrijsPerStuk) FROM Bestelregel WHERE BestellingID = NEW.BestellingID ) WHERE BestellingID = NEW.BestellingID; END; ``` Dit ontwerp minimaliseert redundantie, behoudt data-integriteit en volgt de normalisatieprincipes strikt. De junction table (Bestelregel) is essentieel voor de many-to-many relatie tussen Bestellingen en Producten.