Is deze database volgens 2de normaalvorm ?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Arvid eenachternaam

Arvid eenachternaam

02/06/2016 14:15:23
Quote Anchor link
Beste PHPhulp,

Ik moet voor school een database maken. De database moet genormaliseerd worden tot de 2de normaal vorm.
De database heb ik al gemaakt, maar ik vraag me toch af of dit voldoet aan de 2de normaal vorm.
Kunnen jullie dit voor mij controleren?

Met deze SQL query heb ik de tabellen gemaakt.

CREATE TABLE Product (
Object_ID int NOT NULL AUTO_INCREMENT,
Artikel varchar(6) NOT NULL,
Fabrikant varchar(7) NOT NULL,
Typenummer varchar(20) NOT NULL,
Voorraad int NOT NULL,
Status varchar(12) NOT NULL,
Vestiging varchar(9) NOT NULL,
CONSTRAINT Producten_pk PRIMARY KEY (Object_ID)
);

CREATE TABLE Prijs (
Prijs_ID int NOT NULL AUTO_INCREMENT,
Object_ID int NOT NULL,
Inkoop decimal(6,2) NOT NULL,
Huidige_Waarde decimal(6,2) NOT NULL,
CONSTRAINT Prijs_pk PRIMARY KEY (Prijs_ID)
);

CREATE TABLE Poort (
Poort_ID int NOT NULL AUTO_INCREMENT,
Object_ID int NOT NULL,
Type varchar(15) NOT NULL,
Aantal int NOT NULL,
CONSTRAINT Poort_pk PRIMARY KEY (Poort_ID)
);

Na het invoeren van wat gegevens ziet de database er zo uit:
http://s33.postimg.org/t6vuwtga7/database.png

Als bijvoorbeeld veel routers in Amsterdam staan komt dit meerdere keren voor in de database.
Bij de 2de normaalvorm mag je geen dubbele gegevens hebben. Dus mijn vraag is klopt dit ontwerp?
Overige tips over dit ontwerp zijn uiteraard ook welkom.

Met vriendelijke groet,

Arvid
 
PHP hulp

PHP hulp

16/11/2024 03:32:42
 
Ward van der Put
Moderator

Ward van der Put

02/06/2016 14:25:03
Quote Anchor link
Er ontbreken relaties, die niet onbelangrijk zijn voor een relationele database.

Verder is de tabel met prijzen nu zó opgezet dat een product verschillende prijzen kan hebben. Dat kan best kloppen, bijvoorbeeld bij in de tijd variërende inkoopprijzen, maar je kunt de huidige prijs van een specifiek product niet vinden.

De tabel voor de poorten kun je uitsplitsen in één tabel voor het type poort plus een koppeltabel met de aantallen van een type poort per product.

Ik zie trouwens ook nog wat repeterende attributen in de producten: fabrikanten en vestigingen komen waarschijnlijk meerdere keren voor, dus die moeten beide naar een aparte tabel.
Gewijzigd op 02/06/2016 14:35:24 door Ward van der Put
 
Arvid eenachternaam

Arvid eenachternaam

02/06/2016 14:48:29
Quote Anchor link
Ik dacht dat de relaties zijn gemaakt door middel van de:
CONSTRAINT Producten_pk PRIMARY KEY (Object_ID)
CONSTRAINT Prijs_pk PRIMARY KEY (Prijs_ID)
CONSTRAINT Poort_pk PRIMARY KEY (Poort_ID)
Hoe zou ik dit dan wel goed kunnen doen?

Het is de bedoeling dat 1 product 1 prijs heeft.
En 1 product meerdere poorten.
Hoe kan ik dit veranderen?

Oke dus een tabel vestigingen met vestiging_id en naam_vestiging
en een tabel met fabrikanten met fabrikant_id en naam_fabrikant
?
 
Ward van der Put
Moderator

Ward van der Put

02/06/2016 15:02:28
Quote Anchor link
Arvid eenachternaam op 02/06/2016 14:48:29:
Het is de bedoeling dat 1 product 1 prijs heeft.

• Heeft één product ook bij alle vestigingen dezelfde verkoopprijs?
Zo nee, dan is er een één-op-één-relatie tussen product en verkoopprijs en kan de verkoopprijs naar de producttabel.

• Veranderen de inkoopprijzen van producten?
Dat is in de praktijk vaak wel het geval en dan moet je de historisch kostprijs in een aparte tabel opslaan. Is er echter maar één inkoopprijs per product, dan is dat opnieuw een één-op-één-relatie tussen product en inkoopprijs en kan ook de inkoopprijs naar de producttabel.
 
Arvid eenachternaam

Arvid eenachternaam

02/06/2016 15:31:21
Quote Anchor link
Het gaat om een product database voor een bedrijf (alleen intern) zodat ze weten wat er in de voorraad zit enzovoort. Ik denk eigenlijk dat ik Inkoop en Huidige_Waarde vervang door prijs, aangezien deze informatie niet echt van belang is. In dit geval is het dus een één-op-één-relatie dus de prijs ga ik verplaatsen naar de product tabel. Dan is de prijs tabel dus weg. En ik ga dus 2 tabellen maken "vestigingen" en "fabrikanten". Ik denk dat de belangrijkste vraag nu dan nog is hoe maak ik op de juiste manier een relatie tussen deze tabellen?
Gewijzigd op 02/06/2016 15:31:35 door Arvid eenachternaam
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.