Saya memiliki 4 tabel terkait seperti ini (ini contohnya):

Company:
ID
Name
CNPJ

Department:
ID
Name
Code
ID_Company 

Classification:
ID
Name
Code
ID_Company

Workers:
Id 
Name
Code
ID_Classification
ID_Department

Misalkan saya punya classificationdengan id = 20, id_company = 1. Dan departmentyang memiliki id_company = 2(yang mewakili perusahaan lain).

Ini akan memungkinkan penciptaan pekerja yang berasal dari dua perusahaan karena klasifikasi dan departemen terkait dengan perusahaan secara terpisah. Saya tidak ingin itu terjadi, jadi saya pikir saya memiliki masalah dengan hubungan saya dan saya tidak tahu bagaimana menyelesaikannya.

Masalah Anda berasal dari kenyataan bahwa ada jenis entitas yang hilang dari model Anda. Pertimbangkan ERD berikut:

Perhatikan bahwa saya telah menambahkan jenis entitas persimpangan antara DEPARTMENTdan CLASSIFICATION. Jenis entitas baru ini: POSITIONmemberikan informasi yang tersirat dalam model Anda, bahwa departemen tertentu memiliki serangkaian pekerjaan dari berbagai klasifikasi.

Menambahkan POSITIONke model Anda sebagai entitas eksplisit memiliki beberapa keuntungan.

1. Ini menghindari masalah yang Anda khawatirkan dengan WORKERkemungkinan ditugaskan ke departemen dan klasifikasi di perusahaan yang berbeda.
2. Ini memberi Anda lokus untuk predikat lain yang mungkin berlaku untuk suatu posisi, seperti tingkat gaji, dll.
3. Ini memungkinkan Anda untuk merekam fakta bahwa suatu posisi ada, bahkan jika tidak ada WORKERposisi saat ini, yang merupakan informasi yang sangat berguna.

Perhatikan bahwa untuk menghindari masalah posisi yang ditetapkan untuk departemen dan klasifikasi yang ada di perusahaan yang berbeda, saya telah memperluas kunci keduanya DEPARTMENTdan CLASSIFICATION, yang bagus untuk alasan yang dapat Anda baca panjang lebar dalam jawaban Todd Everett.

WASPADALAH Model di atas menganggap penyederhanaan. Secara khusus, diasumsikan bahwa setiap posisi dicatat hanya sekali. Ini mungkin atau mungkin tidak cocok dengan aturan bisnis Anda. Jika Anda memerlukan banyak POSITIONcatatan untuk departemen dan klasifikasi yang sama dalam suatu perusahaan, maka Anda bisa memasukkan kunci pengganti POSITION.

Saya tidak berpikir Anda memiliki masalah dengan hubungan. Saya pikir sebagai gantinya masalahnya adalah bahwa dengan menggunakan kunci pengganti (yaitu Id) untuk setiap tabel, basis data yang dihasilkan tidak dapat mencegah Pekerja dimasukkan yang Departemennya merupakan satu Perusahaan sementara Klasifikasi adalah yang lain dan sebaliknya. Cara yang baik untuk memahami ini adalah memvisualisasikan skema menggunakan alat Diagram ER. Saya akan menggunakan alat Oracle Data Modeler yang merupakan unduhan gratis.

Diagram ER

Seperti berdiri, Anda dapat memiliki 2 perusahaan - katakan IBMdan Microsoft. IBMdapat memiliki Software Developmentdepartemen, dan Microsoft dapat memiliki Desktop Softwaredepartemen. IBM dapat memiliki Software Engineerklasifikasi, dan Microsoft dapat memiliki Software Developerklasifikasi. Sekarang, karena Anda memiliki kunci pengganti untuk Departmentdan Classification, fakta bahwa itu Software Developmentadalah IBMdepartemen dan Desktop Softwaremerupakan Microsoftdepartemen hilang untuk hubungan anak di masa depan. Ini juga terjadi dengan Classification. Oleh karena itu mudah untuk secara tidak sengaja menugaskan Harlan Mills, yang merupakan IBMkaryawan di Software Developmentdepartemen, klasifikasi Software Developeryang adalah aMicrosoftklasifikasi! Demikian juga, pekerja dapat diberikan klasifikasi yang benar dan departemen yang salah! Berikut adalah diagram yang menunjukkan contoh pertama:

1 Id mewakili IBM, dan 2 Id mewakili Microsoft. Saya telah menyoroti dalam warna merah skenario di mana Harlan Millsdan Bill Gatesditugaskan ke departemen yang salah, yang divisualisasikan oleh 10 departemen terkait dengan 200 klasifikasi ID dan sebaliknya.

Opsi untuk Diselesaikan

Jadi apa saja pilihan untuk mencegahnya terjadi? Ada dua opsi langsung. Yang pertama adalah menyadari bahwa dengan menggunakan kunci pengganti untuk setiap tabel masalah ini ada dan memperkenalkan pemrograman tambahan untuk memverifikasi itu tidak terjadi. Ini dapat dilakukan dalam aplikasi, tetapi jika memasukkan dan memperbarui dapat terjadi di luar aplikasi maka asosiasi yang salah masih dapat terjadi. Pendekatan yang lebih baik adalah membuat pemicu yang menyala saat memasukkan dan memperbarui seorang karyawan untuk memastikan bahwa departemen yang ditugaskan adalah perusahaan yang sama dengan klasifikasi yang ditugaskan, dan jika tidak gagal memasukkan atau memperbarui.

Opsi kedua adalah tidak menggunakan kunci pengganti untuk setiap tabel. Sebaliknya, gunakan tombol pengganti hanya untuk Companymeja, yang mendasar dan tidak memiliki orang tua, dan kemudian membuat mengidentifikasi hubungan dengan Departmentdan Classificationanak tabel. The Departmentdan Classificationmeja sekarang memiliki PK dari Company Idditambah Sequence Number atau Nama untuk membedakan mereka. Kemudian, hubungan dari Departmentdan Classificationke Workerjuga menjadi identifyingdan dengan demikian PK dari Workermenjadi Company Id, ditambah Department Number(saya menggunakan nomor urut dalam contoh ini), ditambah Classification Number. Hasilnya hanya ada one Company Iddi Workertabel. Sekarang tidak mungkin untuk menetapkanWorkerke Departmentdalam satu Companydan ke Classificationdalam yang lain Company.

Mengapa ini tidak mungkin? Hal ini mungkin karena skema menerapkan integritas referensial antara Workerdan Departmentdan Classification. Jika dilakukan usaha untuk menyisipkan Workeruntuk Departmentdalam satu Companydan dan Classificationdari yang lain, kombinasi yang tidak ada dalam tabel induk yang sesuai akan memicu pelanggaran integritas referensial dan insert tidak akan bekerja.

Berikut adalah diagram yang diperbarui dari implementasi opsi kedua:

Opsi Pilihan

Dari dua opsi, saya benar-benar lebih suka yang kedua - menggunakan hubungan identifikasi dan kunci cascading - karena dua alasan. Pertama, opsi ini mencapai aturan yang diinginkan tanpa pemrograman tambahan. Mengembangkan pemicu bukanlah hal sepele. Itu harus dikodekan, diuji, dan dipelihara. Memastikan logika pemicu optimal agar tidak berdampak kinerja juga tidak sepele. Buku Matematika Terapan untuk Profesional Basis Data menyediakan banyak detail tentang kerumitan solusi semacam itu. Kedua, aturan menyiratkan bahwa Departemen dan Klasifikasi tidak dapat eksis di luar konteks Company, dan skema sekarang lebih akurat mencerminkan dunia nyata.

Ini adalah pertanyaan yang bagus karena menunjukkan mengapa hanya mengasumsikan setiap tabel memerlukan kunci pengganti adalah ide yang buruk. Fabian Pascal memiliki postingan blog yang luar biasa tentang topik ini yang menunjukkan bahwa bukan hanya kunci pengganti yang dapat menjadi ide buruk dari sudut pandang integritas data, juga dapat membuat proses pengambilan lebih lambatpada tingkat fisik justru karena gabungan diperlukan bahwa, seandainya kunci telah dijuntai dengan benar, tidak perlu. Topik menarik lainnya yang diungkapkan oleh pertanyaan ini adalah bahwa basis data tidak dapat memastikan bahwa semua data yang dimasukkan ke dalamnya akurat berkenaan dengan dunia nyata. Sebagai gantinya, itu hanya dapat memastikan bahwa data yang dimasukkan ke dalamnya konsisten dengan aturan yang dideklarasikan kepadanya. Dalam hal ini kita dapat melakukan yang terbaik dengan menggunakan pendekatan kunci kaskade untuk memastikan DBMS dapat menjaga data konsisten sehubungan dengan aturan bahwa a Workerdari suatu Companykebutuhan harus ditetapkan Classificationdan Departmentsama Company. Tetapi, jika di dunia nyata Microsoftmemiliki departemen yang disebut Desktop Softwaretetapi pengguna database menegaskan departemen itu sebagai gantinyaSoftware Development DBMS tidak dapat melakukan apa pun kecuali menganggapnya telah diberikan fakta yang sebenarnya.

Cara saya memahami pertanyaannya adalah, bidang ID_Classification dari tabel 'Pekerja' seharusnya hanya memungkinkan klasifikasi yang ditentukan untuk masing-masing perusahaan pekerja. Oleh karena itu, memvalidasi (dengan melampirkan ATURAN atau melalui PEMICU) informasi yang disisipkan / diperbarui ke bidang Pekerja.ID_Klasifikasi memadai untuk memenuhi persyaratan ini.

Dari bacaan saya, saya masih tidak mengerti apa Klasifikasi ini dan mengapa perlu memiliki ID_Company . Jika itu seperti posisi sebagai seseorang yang disebutkan di sini, saya pikir tabel statis untuk memuat semua posisi akan lebih baik.

Jika Anda melakukan ini agar dapat dengan mudah menemukan klasifikasi / posisi di sebuah perusahaan, silakan tambahkan permintaan / tampilan sederhana untuk menghubungkan departemen-pekerja-departemen dan mengambil id perusahaan dari klasifikasi.

saat ini, ada pandangan atau teknologi yang lebih cerdas seperti pandangan terwujud dan bergabung dengan indeks, jadi jika masalah Anda adalah kinerja permintaan, gunakanlah.