Tabel anak (A.K.A. entitas lemah ) adalah tabel yang atribut kunci utamanya bergantung di tabel lain, sehingga tabel anak diidentifikasi atau diidentifikasi sebagian oleh baris dalam tabel itu tergantung pada (induk). Baris dalam tabel anak tidak bisa ada tanpa baris yang sesuai di tabel induknya.
Sebagai ilustrasi, mari kita ambil contoh sederhana dan relevan yang kita semua kenal:Orang tua dan anak-anak dalam konteks keluarga . Kita dapat memodelkan hubungan ini dengan tabel seperti ini:
Pada model di atas, setiap baris dalam Parents tabel diidentifikasi secara unik oleh SSN . SSN adalah atribut intrinsik dan unik untuk setiap induk, sehingga merupakan entitas yang berdiri sendiri atau "kuat" karena tidak bergantung pada tabel lain untuk mendefinisikan identitasnya.
Namun anak-anak, membutuhkan orang tua agar ada (Parent_SSN harus referensi ke SSN yang ada di Parents meja).
Perhatikan kunci utama komposit (Parent_SSN, Name ) di Children meja. Ini berarti bahwa anak-anak diidentifikasi secara unik dengan kombinasi dari Parent_SSN dan Name . Anda tidak dapat melakukan kueri untuk satu anak hanya berdasarkan Name karena beberapa orang tua mungkin memiliki anak dengan nama yang sama. Demikian juga, Anda tidak dapat melakukan kueri untuk anak individual hanya berdasarkan Parent_SSN lapangan karena satu orang tua mungkin memiliki banyak anak. Mempertimbangkan hal itu, anak-anak sebagian diidentifikasi oleh orang tua mereka, oleh karena itu mengidentifikasi hubungan.
Tetapi tidak bisakah anak-anak diidentifikasi secara unik oleh SSN juga? Mengapa ya, tentu saja. Mari kita lanjutkan dan sesuaikan model kita untuk menyertakannya:
Dalam versi model ini, perhatikan bahwa kami telah memperkenalkan SSN kolom untuk Children . Identitas unik anak-anak sekarang ditentukan oleh SSN intrinsik dan unik mereka sendiri . Identitas mereka tidak lagi bergantung pada Parents meja. Meskipun Parent_SSN bidang masih merujuk pada SSN dari Parents tabel, ia tidak memiliki bagian dalam identitas unik anak, sehingga orang tua memiliki non-identifikasi hubungan dengan anak-anak mereka, dan kedua tabel sekarang dapat dianggap sebagai entitas mandiri yang "kuat".
Selain itu, versi model ini memiliki beberapa keunggulan dibandingkan yang pertama:
- Satu orang tua sekarang dapat memiliki dua atau lebih anak dengan nama yang sama, sedangkan integritas entitas kendala dalam model sebelumnya tidak memungkinkan untuk ini.
- Anda dapat mengizinkan
Parent_SSNbidang berisiNULLuntuk memperhitungkan peristiwa bahwa Anda memiliki data tentang anak tersebut, tetapi tidak tahu siapa orang tuanya.
Dalam kedua model di atas, Parents tabel dianggap sebagai tabel induk dari Children meja. Namun, dalam non-identifikasi hubungan seperti pada model kedua, Parents hanya tabel induk dalam konteks kunci asing Parent_SSN karena Parent_SSN referensi/tergantung di SSN di Parents tabel, tetapi tidak memiliki bagian dalam menentukan identitas sebenarnya dari anak-anak.
Untuk mengilustrasikan mengapa konteks penting ketika memutuskan tabel mana yang merupakan tabel induk/anak, pertimbangkan contoh berikut yang melibatkan ketergantungan melingkar:
Dalam contoh ini, karyawan dan departemen diidentifikasi secara unik oleh atribut mereka sendiri dan tidak memperoleh bagian dari identitas mereka dari tabel lain.
Di sini, kami memiliki dua hubungan non-identifikasi:seorang karyawan bekerja untuk sebuah departemen (DeptNo di Employee tabel), dan departemen dikelola oleh seorang karyawan (ManagerSSN di Department meja). Yang mana yang merupakan tabel induk? ...Meja anak?
Itu tergantung pada konteks — hubungan kunci asing mana yang Anda bicarakan? Tabel Departemen akan dianggap sebagai tabel induk dalam konteks DeptNo di Employee tabel karena DeptNo adalah merujuk/bergantung di Department meja.
Namun, tabel Karyawan akan dianggap sebagai tabel induk dalam konteks ManagerSSN di Department tabel karena ManagerSSN adalah merujuk/bergantung pada Employee tabel.
