Goedemiddag allemaal.

Ik ben mij aan het inlezen over normalisatie en probeer nu het programma mysql workbench uit.

Op de Nederlandse pagina's krijg je veel verwijzingen naar het database ontwerp van Yapf en soms kom je een artikel op deze website tegen.

Op basis hiervan heb ik even een opzetje gemaakt( welke uiteraard niet af is), hieronder de code zoals ik hem terug krijg van het programma:


-- MySQL Script generated by MySQL Workbench
-- 01/12/15 15:13:48
-- Model: New Model    Version: 1.0
-- MySQL Workbench Forward Engineering

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';

-- -----------------------------------------------------
-- Schema mydb
-- -----------------------------------------------------

-- -----------------------------------------------------
-- Schema mydb
-- -----------------------------------------------------
CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ;
USE `mydb` ;

-- -----------------------------------------------------
-- Table `mydb`.`postcodes`
-- -----------------------------------------------------
DROP TABLE IF EXISTS `mydb`.`postcodes` ;

CREATE TABLE IF NOT EXISTS `mydb`.`postcodes` (
  `postcodeID` INT NOT NULL,
  `postcode` VARCHAR(45) NOT NULL,
  `straatnaam` VARCHAR(45) NOT NULL,
  `plaats` VARCHAR(45) NOT NULL,
  PRIMARY KEY (`postcodeID`))
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`adressen`
-- -----------------------------------------------------
DROP TABLE IF EXISTS `mydb`.`adressen` ;

CREATE TABLE IF NOT EXISTS `mydb`.`adressen` (
  `adresID` INT NOT NULL,
  `postcodeID` INT NOT NULL,
  PRIMARY KEY (`adresID`),
  CONSTRAINT `postcodeID`
    FOREIGN KEY (`postcodeID`)
    REFERENCES `mydb`.`postcodes` (`postcodeID`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`klanten`
-- -----------------------------------------------------
DROP TABLE IF EXISTS `mydb`.`klanten` ;

CREATE TABLE IF NOT EXISTS `mydb`.`klanten` (
  `klantID` INT NOT NULL AUTO_INCREMENT,
  `voornaam` VARCHAR(45) NOT NULL,
  `tussenvoegsel` VARCHAR(45) NOT NULL,
  `achternaam` VARCHAR(45) NOT NULL,
  `adresID` INT NOT NULL,
  `huisnummer` VARCHAR(45) NOT NULL,
  `huisnummer_toevoeging` VARCHAR(45) NOT NULL,
  PRIMARY KEY (`klantID`),
  INDEX `adresID_idx` (`adresID` ASC),
  CONSTRAINT `adresID`
    FOREIGN KEY (`adresID`)
    REFERENCES `mydb`.`adressen` (`adresID`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`artikelen`
-- -----------------------------------------------------
DROP TABLE IF EXISTS `mydb`.`artikelen` ;

CREATE TABLE IF NOT EXISTS `mydb`.`artikelen` (
  `artikelID` INT NOT NULL AUTO_INCREMENT,
  `artikelnaam` VARCHAR(45) NOT NULL,
  PRIMARY KEY (`artikelID`))
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`orders`
-- -----------------------------------------------------
DROP TABLE IF EXISTS `mydb`.`orders` ;

CREATE TABLE IF NOT EXISTS `mydb`.`orders` (
  `orderID` INT NOT NULL AUTO_INCREMENT,
  `artikelID` INT NOT NULL,
  `klantID` INT NOT NULL,
  `aantal` DECIMAL(10,0) NOT NULL,
  `prijs` DECIMAL(5,2) NOT NULL,
  PRIMARY KEY (`orderID`),
  INDEX `klantenID_idx` (`klantID` ASC),
  INDEX `artikelID_idx` (`artikelID` ASC),
  CONSTRAINT `klantenID`
    FOREIGN KEY (`klantID`)
    REFERENCES `mydb`.`klanten` (`klantID`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `artikelID`
    FOREIGN KEY (`artikelID`)
    REFERENCES `mydb`.`artikelen` (`artikelID`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;


Dit geeft mij de volgende diagram:



Ik weet dat het niet geoptimaliseerd is, maar ik ben niet bekend met de kleurtjes en kraaienpootjes en op YAPF missen er afbeeldingen.

Ik zou denken dat ik goed op weg ben, kan er iemand een blik op werken?

ps: varchar 45 is een standaard waarde in de workbench, het gaat mij om het diagram en de opzet er van.
Gaat vanzelf.
Dat is het mooie er nou van ;-)

Vandaar ook dat ik wil weten of ik goed op weg ben.
Je kan geen twee relaties tussen twee tabellen hebben, dit impliceert een n-n relatie en dan heb je altijd een extra tabel nodig.

orderID in tabel orders zou de PK moeten zijn.

In orderregels is de (nep)sleutel regelID niet nodig. Je maakt van de combinatie orderID, artikelID de primary key. Je zal dan zien dat tussen orderregels en de tabellen orders en artikelen doorgetrokken lijntjes ontstaan.

Dat is het verschil tussen identifying en non-identifying. Identifying wil zeggen dat de FK in de child tabel deel uit maakt van de primary key.
>> Je maakt van de combinatie orderID, artikelID de primary key.

Ger, hoe werkt dit precies? Twee velden, maar één PK? Hoe gebruik je die PK dan in een select query?
Verzamelingenleer Ozzie: als je order x en artikel y hebt, is één orderregel uniek dankzij de vereniging {x,y}.
Daar heb je een samengestelde sleutel voor nodig: x en y alleen zijn ieder voor zich niet uniek, want één order (x) kan meerdere artikelen bevatten en één artikel (y) kan voorkomen in meerdere orders.
>> Ger, hoe werkt dit precies? Twee velden, maar één PK? Hoe gebruik je die PK dan in een select query?

Eigenlijk nooit in een select query, daarom is een pseudo key ook overbodig.

>> als je order x en artikel y hebt, is één orderregel uniek dankzij de vereniging {x,y}.

Ja, dat begrijp ik ...

>> Eigenlijk nooit in een select query, daarom is een pseudo key ook overbodig.

Oké, maar stel dat je die orderregel wilt verwijderen? Misschien moet ik de vraag anders stellen. Als je van 2 velden ('abc' en 'def') één PK maakt, ontstaat er dan daadwerkelijk een nieuw PK-veld 'abcdef'?
Dan blijven het twee sleutels maar vormen die één index.

Het punt bij een n : m-relatie is dat je altijd beide sleutels nodig hebt om één specifieke rij te vinden. Gebruik je slechts één sleutel, dan krijg je meerdere rijen: bij het ordernummer alle artikelen in die order en bij een artikelnummer alle orders met daarin dat ene artikel.
Thanks voor alle input!

ps: @Ozzie, toevallig al wezen spelen met het programma? ;-)
phpMyAdmin heeft een vergelijkbare designer.

Ozzie PHP op 12/01/2015 22:13:58

Oké, maar stel dat je die orderregel wilt verwijderen? Misschien moet ik de vraag anders stellen. Als je van 2 velden ('abc' en 'def') één PK maakt, ontstaat er dan daadwerkelijk een nieuw PK-veld 'abcdef'?

Één van de regels bij normalisatie:
Non key columns are dependent on the key, and nothing but the whole key (, so help me Codd).

In de orderregels tabel zijn alleen aantal en prijs de non-key kolommen, dus wordt niet aan die regel voldaan, dus zou je het artikelnummer en het ordernummer aan de PK op regelID moeten toevoegen. Maar dat is maar gewoon een nietszeggend nummer dus kan je die kolom net zo goed weglaten.

Als je dan een specifieke orderregel wilt verwijderen of bijwerken moet je dus het order_id en artikelnummer controleren.



Reageren