Seperti yang saya pahami, bentuk normal ketiga (3NF) pada dasarnya berarti harus ada tepat satu kunci.
2NF, 3NF, dan Boyce Codd Normal Form (BCNF) berurusan dengan dependensi fungsional . Tabel di 2NF berarti tidak ada dependensi kunci parsial di mana kolom non-kunci tergantung pada beberapa subset yang tepat dari kunci multi-kolom. Tabel seperti yang ada dalam contoh kita sudah ada di 2NF karena setiap kunci kandidat adalah satu kolom. Tabel dalam 3NF berarti setiap kolom non-kunci juga tidak secara fungsional bergantung pada beberapa kolom non-kunci lainnya, dan dengan demikian menciptakan ketergantungan transitif. Tidak masalah jika ada satu atau seratus kunci kandidat. Sebenarnya itu adalah BCNF, bukan 3NF, yang merupakan bentuk normal "final" berkenaan dengan ketergantungan fungsional. Ini karena sebuah tabel bisa di 3NF namun tidak di BCNF karena mungkin ada beberapa kunci kandidat yang tumpang tindih. Jadi, ketika kita menggunakan istilah 3NF untuk berarti "sepenuhnya dinormalisasi" sehubungan dengan dependensi fungsional, yang kita maksud sebenarnya adalah BCNF.
Jika tabel dengan mengatakan kolom id kenaikan otomatis juga memiliki kolom yang dikenal unik dan bukan nol, misalnya nomor jaminan sosial, kolom lain ini dapat digunakan sebagai kunci.
Tidak hanya itu, harus jika kita ingin memastikan data yang disimpan dalam database tetap konsisten dengan aturan yang telah kita identifikasi di dunia nyata!
Mengabaikan masalah-masalah praktis / bisnis (misalnya risiko lingkungan / privasi ketika melewati SSN sebagai kunci / FK), dari aspek desain skema yang ketat, akankah tabel seperti itu tidak berada di 3NF karena ada 2 kunci yang efektif?
Seperti dijelaskan di atas, apakah tabelnya ada dalam 3NF (atau lebih penting BCNF) adalah ortogonal terhadap berapa banyak kunci kandidat yang dikandungnya.
Apakah jawabannya bervariasi pada apakah ada kunci unik di kolom lain? Jika demikian, mengapa?
Tidak, hanya karena menentukan apakah tabelnya ada atau tidak dalam 3NF tidak ada hubungannya dengan berapa banyak kunci kandidat yang dimilikinya. Alih-alih, semuanya terkait dengan memastikan semua kolom non-kunci sepenuhnya berfungsi tergantung pada kunci kandidat tersebut.
Tapi ini tidak memunculkan hal yang menarik. Perhatikan bahwa kunci unik ketika didefinisikan sebagai kendala dalam DBMS tidak sama dengan pengidentifikasi unik yang didefinisikan sebagai aturan bisnis dalam model bisnis konseptual. Mungkin di dunia kita, kita selalu tahu SSN seseorang dan karenanya berfungsi sebagai kunci kandidat untuk seseorang, dan mungkin kita juga memperkenalkan kunci pengganti dalam skema logis yang kita sebut Person Id . Model bisnis kami mencakup aturan yang menyatakan bahwa SSN adalah pengidentifikasi unik untuk seseorang di dunia kita. Ini menyiratkan ketergantungan fungsionaldari semua atribut deskriptif pada atribut identitas ini. Aturan ini tidak berubah hanya karena kami lupa atau memilih untuk tidak memberi tahu DBMS. Inilah sebabnya mengapa sangat penting kendala dinyatakan - sehingga DBMS dapat memastikan data yang disimpan konsisten dengan aturan model bisnis! Jika kami tidak membuat batasan unik pada SSN, kami sekarang dapat secara tidak sengaja membuat lebih dari satu baris untuk orang yang sama dengan SSN yang sama; setiap baris memiliki Id Orang yang berbeda!
Primer yang sangat baik pada topik ini adalah Seri Yayasan Basis Data Praktis Fabian Pascal dan Desain Basis Data Chris Date dan Teori Relasional , dari mana jawaban ini diperoleh. Sementara setiap makalah dari Fabian's harus dibaca, makalah # 1 (yang jelas mendefinisikan perbedaan antara tingkat konseptual, logis, dan fisik) dan kertas # 4 (yang jelas mendefinisikan berbagai jenis kunci) secara khusus membahas pertanyaan ini. Demikian juga, seluruh buku Chris adalah harus dibaca sementara Bagian II adalah bagian yang ditujukan untuk normalisasi sehubungan dengan ketergantungan fungsional.