Ik denk dat het conceptmodel (volgens 6NF
en 3NF) zullen je helpen.
Ik heb de naamgeving vereenvoudigd door het sleutelwoord 'shop' te verwijderen.
(Ook shop-entiteit kan een apart concept AKA SaaS leiden)
SqlFiddle-demo
Over de vragen in de opmerkingen:
Ja, het is een gebruikelijk patroon om surrogaat-ID
te gebruiken op uw tafels. Zoals u in het artikel kunt zien, heeft dat zijn voor- en nadelen.
In de vraag ziet u bijvoorbeeld die primaire sleutel van ProductSpecification tabel is een samenstelling van ProductTypeOptions , OptionValue en Product buitenlandse sleutels.
Ondertussen primaire sleutel van andere tabellen zoals OptionValue is een samengestelde sleutel (OptionId + ValueName )
Het lijkt erop dat het leven gemakkelijker zal zijn om een ID te hebben veld in elke tabel als de primaire sleutel, ja dat is het, maar als databaseontwerper verlies je iets waardevols, bedrijfslogica .
In het huidige ontwerp kunt u deze beperkingen in de tabel Productspecificaties hebben, ze zullen een deel van uw bedrijfslogica laten zien:
- Controleer de beperking op
ProductSpecification{OptionValue.optionId = productTypeOption.optionId}dat voorkomt dat een waarde als "Wit" wordt toegewezen aan "Grootte". - Controleer de beperking op
ProductSpecification{product.productTypeId = productTypeOption.productTypeId}dat zal voorkomen dat een product als "Nike" wordt toegewezen aan productspecificaties van "Auto's".
Als u surrogaat-ID's gebruikt, kunt u dit soort beperkingen niet in uw database hebben (probeer dit).
Er zal extra werk moeten worden gedaan in uw toepassingsimplementatie om ze te verkrijgen.
BTW gebruik surrogaat-ID, controleer gegevensconsistentie
, als je meer geïnteresseerd bent, zie een primaire sleutel kiezen:natuurlijk of surrogaat
.
Het lijkt erop dat "Herenschoen" van "Nike" prijs, voorraad en toeslag moet hebben, dus zijn ze natuurlijk eigendom van Product tafel.