Hanya dengan melihat sepatu, Anda memiliki satu entitas:sepatu. Ini memiliki dua atribut langsung:ukuran dan warna. Domain dari masing-masing atribut ini harus didefinisikan secara ketat, yang menunjukkan tabel pencarian untuk atribut tersebut. Ada dua atribut tidak langsung, harga dan kuantitas, tetapi ini lebih merupakan atribut dari setiap kombinasi ukuran/warna daripada sepatu itu sendiri.
Ini menyarankan satu tabel entitas:Sepatu; dua tabel pencarian:Ukuran dan Warna; dan satu tabel persimpangan tiga arah: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 )
);
Jadi, misalnya, kombinasi ('Penny Loafer', '10 1/2', 'Tan') akan memiliki harga dan kuantitas tertentu. Ukuran 11 Tan akan memiliki harga dan kuantitasnya sendiri seperti halnya 10 1/2 Burgandy.
Saya akan merekomendasikan tampilan yang menggabungkan tabel dan menyajikan hasilnya dalam bentuk yang lebih bermanfaat seperti yang ditunjukkan di atas daripada, katakanlah, (15, 4, 3, 45.00, 175). Pemicu pada tampilan dapat mengizinkan semua akses oleh aplikasi melalui tampilan sehingga aplikasi tetap agnostik terhadap tata letak fisik data. Tampilan seperti itu adalah alat yang sangat kuat yang secara signifikan menambah kekokohan dan kemampuan pemeliharaan data yang mendasarinya dan aplikasi itu sendiri, tetapi sayangnya kurang dimanfaatkan.
