Als je alleen naar schoenen kijkt, heb je één entiteit:schoenen. Het heeft twee directe kenmerken:maat en kleur. Het domein van elk van deze attributen moet strikt worden gedefinieerd, wat de opzoektabellen voor hen aangeeft. Er zijn twee indirecte kenmerken, prijs en hoeveelheid, maar dit zijn meer kenmerken van elke combinatie van maat/kleur dan van een schoen zelf.
Dit suggereert één entiteitstabel:schoenen; twee opzoektabellen:maten en kleuren; en een driewegkruisingstabel:ShoeStyles:
create table ShoeStyles(
ShoeID int not null,
SizeID smallint not null,
ColorID char( 1 ) not null,
Price currency,
Qty int not null default 0,
constraint FK_ShoeStyles_Shoe foreign key references Shoes( ID ),
constraint FK_ShoeStyles_Size foreign key references Sizes( ID ),
constraint FK_ShoeStyles_Color foreign key references Colors( ID ),
constraint PK_ShoeStyles primary key( ShoeID, SizeID, ColorID )
);
Zo heeft de combinatie ('Penny Loafer', '10 1/2', 'Tan') bijvoorbeeld een bepaalde prijs en hoeveelheid beschikbaar. De maat 11 Tan heeft zijn eigen prijs en hoeveelheid, net als de 10 1/2 Burgandy.
Ik zou een weergave aanbevelen die de tabellen verbindt en de resultaten in een meer bruikbare vorm presenteert, zoals hierboven weergegeven in plaats van bijvoorbeeld (15, 4, 3, 45,00, 175). Triggers op de weergave kunnen alle toegang door de toepassing via de weergave toestaan, zodat de app onwetend blijft over de fysieke lay-out van de gegevens. Dergelijke weergaven zijn een uiterst krachtige tool die aanzienlijk bijdraagt aan de robuustheid en onderhoudbaarheid van de onderliggende gegevens en van de app zelf, maar die jammerlijk onderbenut wordt.