Bara att titta på skor har du en enhet:skor. Den har två direkta attribut:storlek och färg. Domänen för vart och ett av dessa attribut måste vara strikt definierade, vilket anger uppslagstabeller för dem. Det finns två indirekta attribut, pris och kvantitet, men dessa är attribut mer av varje kombination av storlek/färg än för själva skon.
Detta föreslår en enhetstabell:Skor; två uppslagstabeller:Storlekar och Färger; och en trevägs skärningstabell: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 )
);
Således, till exempel, kommer kombinationen ('Penny Loafer', '10 1/2', 'Tan') att ha ett visst pris och kvantitet till hands. Storlek 11 Tan kommer att ha sitt eget pris och kvantitet liksom 10 1/2 Burgandy.
Jag skulle rekommendera en vy som ansluter sig till tabellerna och presenterar resultaten i en mer användbar form som visas ovan snarare än till exempel (15, 4, 3, 45.00, 175). Utlösare på vyn kan tillåta all åtkomst av applikationen genom vyn så att appen förblir agnostisk mot den fysiska layouten av data. Sådana vyer är ett extremt kraftfullt verktyg som avsevärt bidrar till robustheten och underhållbarheten hos den underliggande datan och för själva appen, men som är bedrövligt underutnyttjade.