Penso che la bozza del modello (segue 6NF
e 3NF) ti aiuteranno.
Ho semplificato la convenzione di denominazione rimuovendo la parola chiave "negozio".
(Anche l'entità negozio può guidare un concetto separato AKA SaaS)
SqlFiddle Demo
Informazioni sulle domande nei commenti:
Sì, è un modello comune utilizzare identificatore surrogato
sulle tue tavole Come puoi vedere nell'articolo, questo avrà i suoi pro e contro.
Ad esempio, nella domanda, vedrai la chiave primaria di ProductSpecification table è una composizione di ProductTypeOptions , OptionValue e Product chiavi esterne.
Nel frattempo chiave primaria di altre tabelle come OptionValue è una chiave composta (OptionId + ValueName )
Sembra che la vita sarà più facile avere un ID campo in ogni tabella come chiave primaria, sì, ma come progettista di database perderai qualcosa di prezioso, logica aziendale .
Nel design attuale puoi avere questi vincoli nella tabella Product-Specification, mostreranno parte della tua logica aziendale:
- Controlla il vincolo su
ProductSpecification{OptionValue.optionId = productTypeOption.optionId}ciò impedirà che un valore come "Bianco" venga assegnato a "Taglia". - Controlla il vincolo su
ProductSpecification{product.productTypeId = productTypeOption.productTypeId}ciò impedirà che un prodotto come "Nike" venga assegnato alle specifiche del prodotto di "Auto".
Se usi l'identificatore surrogato non puoi avere questo tipo di vincoli all'interno del tuo database (prova questo).
Sarà necessario del lavoro extra all'interno dell'implementazione dell'applicazione per ottenerli.
BTW usa un identificatore surrogato, verifica la coerenza dei dati
, se sei più interessato vedi scegliere una chiave primaria:naturale o surrogata
.
Sembra che la "Scarpa da uomo" di "Nike" debba avere prezzo, stock e sovrapprezzo, quindi sono proprietà naturali di Product tabella.
