Saya memiliki masalah dengan bentuk normal kedua (2NF) dan saya tidak dapat menyelesaikannya dengan menggunakan Google. Itu membuat saya gila karena saya seorang guru dan saya tidak ingin mengajarkan hal-hal yang salah kepada murid-murid saya.

Mari kita punya tabel dengan 5 bidang.

Gradings = {StudentName, SubjectCode, SubjectName, #Exam, Grade}

Ketergantungan seperti ini:

StudentName, SubjectCode, #Exam -> Grade

SubjectCode -> SubjectName

SubjectName -> SubjectCode

Karenanya, kunci kandidat 1 adalah {StudentName, SubjectCode, #Exam} dan kunci kandidat 2 adalah {StudentName, SubjectName, #Exam} .

Atribut prima adalah {StudentName, SubjectCode, SubjectName, #Exam} dan atribut non-prime adalah Grade

Menurut definisi bentuk normal kedua, atribut non-prima tidak dapat bergantung pada bagian dari kunci kandidat. Satu-satunya atribut non-prima (Kelas) tidak bergantung pada bagian dari kunci kandidat sehingga tabel ini tampak di 2NF.

Masalahnya adalah saya pikir ada sesuatu yang salah (dan saya bisa saja salah). Saya pikir subyek harus memiliki meja sendiri.

Gradings = {StudentName, Code Subject, #Exam, Grade}

Subjects = {Kode Subjek, SubjectName}

Tetapi 2NF tidak menghasilkan ini. 3NF adalah tentang ketergantungan antara atribut non-prima sehingga tidak menghasilkan ini juga. Tetapi bagi saya tampaknya ini adalah hasil yang tepat, karena tidak memiliki redundansi.

Saya kira jika atribut non-prima didefinisikan sebagai "atribut yang bukan kunci kandidat", 2NF akan menghasilkan hasil yang diinginkan. Tapi saya telah memeriksa ini berulang-ulang dan atribut non-prima didefinisikan sebagai "atribut yang TIDAK MENDAPAT kunci kandidat".

Apa yang saya lakukan salah?

Relasi Anda dalam 3NF, (dan tidak hanya di 2NF), karena seperti yang Anda katakan, satu-satunya atribut non prime adalah Grade , yang hanya muncul di sisi kanan FD Anda.

Relasinya bukan di BCNF, karena sisi kiri dari dua FD kecil bukanlah superkey.

Anda dapat, bagaimanapun, tanpa henti menguraikan hubungan ke ( SubjectCode , SubjectName ) dan salah satu ( StudentName, SubjectCode, #Exam, Grade ) atau ( StudentName, SubjectName, #Exam, Grade )

Dekomposisi ini memberi Anda dua hubungan BCNF dan mempertahankan semua dependensi fungsional. Ini tidak selalu mungkin (Anda selalu dapat menguraikan hubungan dengan 3NF, tetapi tidak harus dengan BCNF).

2NF

Jika Anda menginginkan contoh 2NF (dan bukan 3NF), relasi Anda harus berisi dependensi transitif.

Misalnya, Anda memiliki kolom Skor. Nilai Intuitif-> Nilai karena semua ujian dengan nilai yang sama harus mendapatkan nilai yang sama (akan lebih tidak adil jika tidak), tetapi perhatikan bahwa kita tidak bisa mengatakan Skor-> Skor karena beberapa skor dapat memiliki nilai yang sama (11% dan 12% mungkin akan "Gagal", misalnya).

Sekarang hubungan Anda adalah:

Gradings ( StudentName, SubjectCode, SubjectName, #Exam, Score, Grade )

dan Anda memiliki bentuk redundansi baru karena setiap kali Anda memasukkan hasil dengan skor yang sama dengan catatan Gradings lain Anda juga harus mengulang Grade yang sesuai. Untuk sampai ke 3NF karena itu Anda dapat membusuk

ScoreGrades ( Score, Grade )

dengan Skor sebagai kuncinya, dan

Skor ( StudentName, SubjectCode, SubjectName, #Exam, Score )

Anda benar dalam semua yang Anda katakan. Kode Subjek, SubjectName harus masuk dalam tabel mereka sendiri untuk menegakkan dependensi yang diinginkan. Ini adalah contoh yang bagus mengapa 2NF dan 3NF tidak cukup untuk menghasilkan desain database yang bagus - Anda perlu Boyce Codd Normal Form (BCNF) sebagai gantinya.

2NF dan 3NF digantikan oleh BCNF yang secara praktis membuat NF yang lebih rendah menjadi usang *. BCNF adalah yang lebih penting dan bisa dibilang lebih mudah untuk dijelaskan dan diterapkan. Sebagai seorang guru saya sarankan Anda menghabiskan lebih banyak waktu untuk BCNF dan lebih sedikit untuk 2NF dan 3NF. Jika sebuah tabel memenuhi persyaratan BCNF maka ia juga memenuhi 2NF dan 3NF juga.

* 3NF bukan Formulir Normal yang mempertahankan ketergantungan tertinggi. Bentuk Normal Kunci Dasar (EKNF) adalah. Sebenarnya EKNF, bukan BCNF, yang membuat 3NF usang, tetapi EKNF diabaikan secara tidak adil dan sebagian besar buku pelajaran dan kursus bahkan tidak menyebutkannya. Apa yang berarti hal yang sama adalah untuk merancang ke BCNF dan kemudian memeriksa bahwa semua dependensi yang diinginkan dan aturan integritas lainnya dapat ditegakkan dengan benar - jika tidak, maka modifikasi desain. Tidak ada NF yang merupakan solusi lengkap untuk integritas data tetapi BCNF umumnya paling dekat dan paling mudah untuk dijelaskan dan digunakan.

Saya tidak akan mengatakan berapa lama sejak saya pertama kali mempelajari semua ini. Tapi saya ingat saya punya seorang profesor yang, setelah dengan patuh mengajari kami arti yang tepat dari "ketergantungan fungsional" dan "atribut non-prima" dan semua kata kunci lainnya, memberi kami serangkaian pertanyaan sederhana untuk diajukan untuk melihat apakah ada yang normal atau tidak. bentuk tercapai. Mari kita lihat apakah saya bisa mengingatnya sejauh itu ...

Kami telah mengidentifikasi kunci kandidat sehingga kami mengajukan pertanyaan ini tentang atribut non-prima yang tersisa. Dalam hal ini, hanya ada satu: kelas.

Apa informasi minimum absolut yang kita butuhkan untuk secara unik mengidentifikasi kelas? Kita perlu mengetahui siswa, subjek dan ujian yang diambil. Baik, ini adalah salah satu kunci kandidat.

EDIT: VVV

Tetapi jawabannya bisa saja nama siswa, nama subjek dan ujian. Ini akan cocok dengan kunci kandidat kedua.

Dengan asumsi bahwa SubjectCode dan SubjectName adalah kunci kandidat untuk entitas Subjek, tidak ada alasan untuk memiliki kedua bidang ini di sini. Satu referensi unik untuk satu baris dalam tabel Subjek sudah cukup. Jadi kita dapat dengan aman menyingkirkan bidang SubjectName sama sekali tanpa mengorbankan integritas model.

Namun, dalam jawaban asli saya, dalam keinginan saya untuk menunjukkan tingkat normalisasi lain, saya mengabaikan bahwa SubjectName telah digunakan dalam kunci kandidat dan menganggapnya hanya atribut non-prima. Saya kira itu sangat jelas bagi saya bahwa ini adalah bidang yang tidak berguna. Saya pikir itu akan sama jelasnya bagi semua orang dan karena bagaimanapun kita menyingkirkan bidang itu, apa masalahnya?

Tetapi alih-alih menghapus bagian dari jawaban itu, saya akan menyimpannya untuk perbandingan.

AKHIR EDIT: ^ ^ ^

Apa informasi minimum absolut yang kita perlukan untuk secara unik mengidentifikasi nama subjek?

SubjectName hanya bergantung pada SubjectCode - bagian dari kunci kandidat. Jadi tuple ini bukan di 2nf. SubjectCode harus menjadi kunci utama dari tabel Subjek sehingga merupakan lokasi yang tepat untuk menempatkan SubjectName. Hapus dari tuple ini dan sekarang di 2nf.

Jika kita mengajukan pertanyaan tentang atribut dan jawabannya tidak semua atau sebagian dari kunci kandidat, maka tupel tidak ada dalam 3nf. Tapi tuple ini juga sepele dalam 3nf dan lebih, karena kami kehabisan bidang untuk mengajukan pertanyaan. ;)

Catatan: ketika kita mengatakan "normalisasi", kita merujuk pada proses yang diterapkan pada entitas logis. Karena tuple yang disediakan tampaknya merupakan definisi entitas yang disebut "kelas", maka kita dapat menormalkannya. Namun, pada satu titik saya berkata "tuple ini bukan di 2nf," yang seharusnya lebih tepat, " entitas ini tidak ada di 2nf." Saya minta maaf jika ini telah menyebabkan kebingungan.

Satu-satunya atribut non-prima (Kelas) tidak bergantung pada bagian dari kunci kandidat sehingga tabel ini tampak di 2NF.

Itu ada di 2NF.

Masalahnya adalah saya pikir ada sesuatu yang salah (dan saya bisa saja salah). Saya pikir subyek harus memiliki meja sendiri.

Tidak ada alasan untuk mengharapkan bahwa subjek harus memiliki tabel sendiri untuk dekomposisi dari tabel asli ke 2NF . Anda membingungkan beberapa gagasan yang kabur tentang "harus" dengan apa yang sebenarnya diberikan oleh bentuk normal tertentu kepada Anda.

3NF adalah tentang ketergantungan antara atribut non-prima sehingga tidak menghasilkan ini juga.

"3NF adalah tentang ketergantungan antara atribut non-prima" bukan definisi yang tepat dari 3NF jadi "sehingga tidak menghasilkan ini juga" bukan kesimpulan yang masuk akal. Meskipun menerapkan definisi aktual tidak menunjukkan bahwa tabel tersebut dalam 3NF, tanpa meja siswa diperlukan. Tetapi sekali lagi, tidak ada alasan untuk berharap akan ada.

Tetapi bagi saya tampaknya ini adalah hasil yang tepat, karena tidak memiliki redundansi.

Sekali lagi, "redundansi" tidak membantu samar-samar, jadi "karena" dan harapan siswa Anda tidak sehat. Bentuk normal yang berbeda bebas dari dan tunduk pada jenis anomali tertentu dan terkait "redundansi". Tetapi "redundansi" lain yang tidak diatasi dengan normalisasi dapat tetap ada.

Tabel ini bukan di BCNF, karena memiliki FD yang tidak keluar dari CK. Penguraian per BCNF mengarah ke memiliki meja siswa. BCNF adalah bentuk normal tertinggi untuk berurusan dengan JD (gabung dependensi) yang menyertai FD. Namun, JD lain dapat bermasalah (yaitu tidak "tersirat oleh CK") dan harus dihapus dengan normalisasi ke 5NF.

PS Tabel asli juga memenuhi nilai FD {StudentName, SubjectName, #Exam} ->.

Ketergantungan seperti ini:

Apa artinya ini? Itu tidak jelas.

Maksud Anda, "Ini semua FD non-sepele yang dimiliki"? Tidak, karena mereka menyiratkan yang keempat. "Ini ada beberapa FD yang menahan"? Tidak, itu berarti bahwa FD dalam penutupan transitif bertahan, tetapi tidak mengatakan bahwa yang lain tidak memegang, namun Anda dapat menentukan CK. "FD yang memegang persis yang ada di penutupan transitif ini"? Jika Anda bermaksud demikian, Anda hanya akan mengetahuinya jika Anda telah menunjukkannya , yaitu Anda harus menemukan penutupan itu (biasanya, melalui penutup minimal / kanonik) dan kemudian menunjukkan bahwa tidak ada FD lain; Apakah kamu? Apapun, apa yang Anda tulis tidak berarti begitu. Jadi saya berharap Anda tidak beralasan tentang situasi FD & CK.

Anda benar, subjek membutuhkan tabel sendiri. Jika Anda memilih salah satu kunci kandidat Anda, salah satu subject_codeatau subject_namemenjadi kunci kandidat non-primer. Anda kemudian menghapus bidang mata pelajaran non-primer dari tabel gradasi.

Anda memiliki ketergantungan fungsional pada subjek yang Anda miliki dua pengidentifikasi unik. Ini ditunjukkan oleh ketergantungan transitif antara subject_codedan subject_name. Ini menunjukkan persyaratan untuk membuat tabel yang berisi dua bidang tersebut dan menghapus salah satu bidang ini dari semua tabel lainnya. Tabel ini dapat memiliki kolom dependen tambahan, meskipun saya tidak melihat satu pun dalam contoh ini. Dalam bentuk normal ke-3 yang telah Anda pilih.

nilai tergantung pada tiga bidang lainnya (kunci kandidat) dalam tabel gradasi baru. Seperti disebutkan di atas Anda harus memilih salah satu bidang kandidat untuk tabel mata pelajaran. Biasanya ini akan menjadi nilai kode jika tersedia karena cenderung lebih stabil. Model yang dihasilkan dalam 3nf karena semua bidang non-kunci sepenuhnya tergantung pada bidang di kunci utama.

Analisis lebih lanjut dari masalah (persyaratan) kemungkinan akan menghasilkan tabel sesi terhadap tanda yang diterapkan. Model saat ini tidak mungkin untuk menutupi siswa yang mengulang suatu kursus. Ini akan dibahas dalam pelajaran selanjutnya.

Siswa juga cenderung menjadi meja terpisah karena dimungkinkan untuk memiliki beberapa siswa dengan nama yang sama. Ini kemungkinan akan diselesaikan dengan penambahan kunci primer sintetis (nomor siswa?).

subjects --->  sessions ---+--> grades
students  -----------------+

Saya sedang bersiap untuk menghapus ini karena dianggap salah

Nama Subjek juga merupakan atribut non-prima dan itu tergantung pada bagian dari Kode Subjek kunci utama (aturan istirahat - tidak boleh ada ketergantungan parsial dari setiap kolom pada kunci primer).

Ini dilarang di Formulir Normal ke-2 dan karenanya harus ditempatkan di meja sendiri seperti yang Anda duga.

Saya pikir di mana Anda berhenti adalah mengidentifikasi dua set kunci kandidat, ketika Anda membuat tabel Anda harus memilih satu set kunci kandidat untuk membuat kunci utama. Kolom yang tersisa menjadi atribut non-prime yaitu, jika Anda memilih kunci kandidat kedua Anda, Kode Subjek menjadi atribut non-prime tergantung pada bagian dari kunci utama (Nama Subjek) dan harus ditempatkan di tabel itu sendiri.

Penting untuk mengajarkan bentuk normal ke-1, ke-2 dan ke-3 agar saling membangun. BCNF pada dasarnya juga merupakan perluasan ke bentuk normal ke-3 sehingga pemahaman yang kuat pada tingkat yang lebih rendah sangat penting.

Lebih lanjut; pengembang yang berpengalaman tidak akan mempertimbangkan tingkat normalisasi yang independen karena banyak aturan menjadi intuitif.

Mereka juga akan tahu kapan harus melanggar aturan normalisasi untuk menyelesaikan masalah desain dan optimisasi tertentu. Normalisasi harus diperlakukan sebagai panduan untuk desain yang baik bukan aturan yang ketat, saya percaya itu juga akan menjadi poin pengajaran yang baik.