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.
Adressen normaliseren is een drama, laten we dat vooropstellen.

Als je echter een adres-ID alleen koppelt aan een postcode-ID, dan kan die tabel er ook uit.
Per klant sla je dan postcode-ID (in plaats van adres-ID) plus huisnummmer en huisnummertoevoeging op.

Als je per order meerdere artikelen wilt leveren, heb je daarvoor nog een extra tabel nodig.
Ten eerste: Ik zou altijd proberen de database zo veel mogelijk in het engels te houden als je die taal goed spreekt. Makkelijker als je een keer iets wilt vragen op een engels forum of internationaal gaat met je applicatie. Maar dit is ook een kwestie van persoonlijke voorkeur.

Ten tweede: Addressen normaliseren is inderdaad een ramp. Zelf sla ik al niet meer op dan een postcode en een huisnummer. Deze kun je dan online tegen een database aanhouden of je kunt een postcode database kopen. Als je dit niet doet kun je prima de postcode, huisnummer en plaatsnaam in de klantentabel opslaan (correct me if i'm wrong)

Tips:

Maak een orderregels tabel zet in deze tabel het orderID. Op deze manier kunt je meerdere artikelen aan een order toevoegen. Zet de prijs van de orderregel wel vast in die tabel en laat die niet uit artikelen komen. Zodra de prijs veranderd wil je niet dat de prijs van de order die een tijdje geleden geplaatst hebt veranderd.

Verder, keep up de good work :)
De kraaienpootjes geven de cardinality van de relatie aan:

->0 nul of meer
->| één of meer
-|| één en alleen maar één
-|0 één of nul 
Thanks voor de reacties!

Het ging mij niet zozeer om de tabellen, maar om de opzet van de diagram.

Voorbeeldje iets aangepast op basis van jullie reacties:



Of hoort het zo te zijn ( gelet op de lijntjes en kraaienpootjes en kleurtjes )?




De tabel orders niet als koppeltabel gebruiken maar als "kopregel" voor orderregels. In orders neem je wel het klant id op maar ook de (factuur)datum, naam van degene die besteld heeft, en andere handige gegevens die eenmaal bij een order/factuur horen.
[offtopic]
Ziet er mooi uit zo'n diagram, maar ik ben wel benieuwd of iedereen hier eerst zo'n chique diagram maakt, of gewoon even simpelweg een opzetje op papier krabbelt?
[/offtopic]
Wat bedoel je met "kopregel"?

Ik weet dat er dingen ontbreken en ook uitgebreid kunnen worden, het betreft de opzet van de diagram.

Welke situatie is nou fout? afbeelding 1 of 2 (hierboven weergegeven ).


Edit:
>>> Ziet er mooi uit zo'n diagram, maar ik ben wel benieuwd of iedereen hier eerst zo'n chique diagram maakt, of gewoon even simpelweg een opzetje op papier krabbelt?

Ik krabbel op papier en begin ergens.

Ik heb een bestaande structuur welke ik bijna 1 op 1 over kan nemen en kan verbeteren, alleen ik heb de PK's en FK's etc nooit doorgevoerd...
Dus ik wilde het eens "anders" doen.

Met zo'n diagram krijg je toch wel een bepaalde database inzicht, lijkt me ergens wel handiger dan op papier... scheelt veel denk werk ;-)
>> Een diagram is niet echt belangrijk, maar geeft je wel in 1x inzicht in je database structuur, leek mij erg handig aangezien ik best veel tabellen heb ...

Nou, t ziet er mooi uit hoor :-)

[size=xsmall]Toevoeging op 12/01/2015 17:54:14:[/size]

>> Met zo'n diagram krijg je toch wel een bepaalde database inzicht, lijkt me ergens wel handiger dan op papier... scheelt veel denk werk ;-)

Maar dat moet je toch allemaal "uittekenen"? Dat lijkt me nog veel meer werk :)
Het vullen van zo'n tabelletje is seconden werk als je snapt hoe een tabel word opgebouwd ( voordeel is ook dat je SQL kunt importeren en exporteren).

(van PK's en FK's heb ik kaas gegeten en dan de "symbolen" begrijpen is ook weer iets wat je moet "snappen".)
Op zich is het een mooi programma, simpel, althans, zo komt het over.
Als je dit snapt, dan is het ook seconden werk om aan te passen, schrijven op papier duurt langer.

Vandaar de vraag of iemand mij kon vertellen of ik goed bezig was, los van de inhoud ;-)

Ik neem aan dat dit een foute manier is ( stel dat ik alle orders van een klant wil ophalen ):
Maar tekent dat programma alles zelf? Of moet je die lijnen en posities zelf bepalen en tekenen?

Reageren