Saya pikir model draf (mengikuti 6NF
dan 3NF) akan membantu Anda.
Saya menyederhanakan konvensi penamaan dengan menghapus kata kunci 'toko'.
(Juga entitas toko dapat memimpin konsep terpisah AKA SaaS)
Demo SqlFiddle
Tentang pertanyaan di komentar:
Ya, ini adalah pola umum untuk menggunakan pengidentifikasi pengganti
di meja Anda. Seperti yang Anda lihat di artikel, itu akan datang dengan pro dan kontra.
Misalnya, dalam pertanyaan, Anda akan melihat kunci utama ProductSpecification tabel adalah komposisi dari ProductTypeOptions , OptionValue dan Product kunci asing.
Sementara itu kunci utama tabel lain seperti OptionValue adalah kunci komposit (OptionId + ValueName )
Sepertinya hidup akan lebih mudah dengan memiliki ID bidang di setiap tabel sebagai kunci utama, ya, tetapi sebagai perancang basis data Anda akan kehilangan sesuatu yang berharga, logika bisnis .
Dalam desain saat ini, Anda dapat memiliki batasan ini di tabel Spesifikasi Produk, batasan ini akan menampilkan bagian dari logika bisnis Anda:
- Periksa batasan pada
ProductSpecification{OptionValue.optionId = productTypeOption.optionId}yang akan mencegah nilai seperti "Putih" ditetapkan ke "Ukuran". - Periksa batasan pada
ProductSpecification{product.productTypeId = productTypeOption.productTypeId}yang akan mencegah produk seperti"Nike" ditetapkan ke spesifikasi produk "Mobil".
Jika Anda menggunakan pengidentifikasi pengganti, Anda tidak dapat memiliki batasan jenis ini di dalam basis data Anda (coba ini).
Pekerjaan ekstra akan diperlukan untuk dilakukan di dalam implementasi aplikasi Anda untuk mendapatkannya.
BTW gunakan pengenal pengganti, periksa konsistensi data
, jika lebih tertarik lihat memilih Kunci Utama:Alami atau Pengganti
.
Tampaknya "Sepatu Pria" dari "Nike" perlu memiliki harga, stok, dan biaya tambahan, sehingga itu adalah milik alami Product tabel.
