Apakah pernah ada waktu di mana menggunakan hubungan basis data 1: 1 masuk akal?


162

Saya memikirkan hari lain tentang normalisasi, dan terlintas di benak saya, saya tidak dapat memikirkan waktu di mana seharusnya ada hubungan 1: 1 dalam database.

  • Name:SSN? Saya akan memilikinya di meja yang sama.
  • PersonID:AddressID? Sekali lagi, meja yang sama.

Saya dapat menghasilkan jutaan contoh 1: banyak atau banyak: banyak (dengan tabel perantara yang sesuai), tetapi tidak pernah 1: 1.

Apakah saya kehilangan sesuatu yang jelas?


7
SSN bukan nomor unik. Mereka digunakan kembali.

Lebih mudah untuk membagi database menjadi beberapa perangkat fisik ketika dipisahkan seperti ini.
Pacerier

2
Maafkan komentar pada komentar yang sangat lama di atas: SSN's tidak digunakan kembali dan memang mengidentifikasi seseorang secara unik.
Derek

Benar, tetapi berdasarkan beberapa matematika di balik amplop, sekitar setengah dari angka yang mungkin telah dikeluarkan. SSA mengklaim akan ada banyak untuk beberapa generasi lagi tetapi cepat atau lambat mereka akan kehabisan angka kecuali kebijakan / hukum berubah. Temukan lebih lanjut di: ssa.gov/history/hfaq.html
Pulsehead

2
Anda bisa bayangkan suasana hati macam apa yang dialami Mark Brady pada 5 Februari 2009 antara pukul 23:10 dan 23:33. Hehe.
Robert

Jawaban:


161

Hubungan 1: 1 biasanya menunjukkan bahwa Anda telah mempartisi entitas yang lebih besar untuk beberapa alasan. Seringkali itu karena alasan kinerja dalam skema fisik, tetapi itu bisa terjadi di sisi logika juga jika sebagian besar data diharapkan "tidak diketahui" pada saat yang sama (dalam hal ini Anda memiliki 1: 0 atau 1: 1, tetapi tidak lebih).

Sebagai contoh partisi logis: Anda memiliki data tentang seorang karyawan, tetapi ada serangkaian data yang lebih besar yang perlu dikumpulkan, jika dan hanya jika mereka memilih untuk memiliki cakupan kesehatan. Saya akan menyimpan data demografis mengenai cakupan kesehatan dalam tabel yang berbeda untuk memberikan partisi keamanan yang lebih mudah dan untuk menghindari pengangkutan data di dalam pertanyaan yang tidak terkait dengan asuransi.

Contoh dari partisi fisik adalah data yang sama yang di-host di beberapa server. Saya dapat menyimpan data demografis cakupan kesehatan di negara bagian lain (di mana kantor HR, misalnya) dan basis data primer hanya dapat menautkannya melalui server tertaut ... menghindari replikasi data sensitif ke lokasi lain, namun tetap membuatnya tersedia untuk (dengan asumsi jarang ada di sini) pertanyaan yang membutuhkannya.

Partisi fisik dapat berguna setiap kali Anda memiliki kueri yang membutuhkan himpunan bagian yang konsisten dari entitas yang lebih besar.


32
Contoh sempurna dari ini adalah tabel yang berisi file. Anda mungkin (karena alasan yang jelas) ingin memiliki satu tabel yang hanya berisi data meta file (nama file, tipe mime, dll) dan tabel lain, dipetakan 1: 1, yang berisi data gumpalan aktual. Ini akan mengurangi overhead dalam meminta / menyortir file dalam beberapa kasus.
Kevin Peno

2
Iya. Itu tergantung pada database (desain modern menyimpan gumpalan di filesystem hanya dengan menggunakan jenis yang benar) dan bahkan dengan dukungan seperti itu kita harus berhati-hati untuk mengecualikan kolom (dalam daftar kolom eksplisit SQL adalah normal, tetapi beberapa ORM ingin menyeret seluruh catatan). Triknya adalah mengetahui pola penggunaan Anda: jika sebagian besar waktu data aktual diabaikan, saya akan menggunakan tabel gumpalan 1: 1. Jika sebagian besar akses adalah unduhan data saya akan menggunakan mekanisme penyimpanan asli.
Godeke

@Ochado Sementara saya setuju bahwa Anda memiliki banyak alasan (non-fisik) yang muncul secara alami untuk 1: 1, lubang "jika Anda tidak memiliki informasi historis" membuat kasus-kasus yang saya mungkin tidak akan menggunakan hubungan 1: 1 untuk melaksanakan.
Godeke

1
@Ochado Saya pikir hubungan IS-A adalah contoh yang baik. Saya mencoba menghindari mencoba memaksakan konsep berorientasi objek pada tabel saya (sebagai gantinya, menggunakan ORM sebagai pustaka data), tetapi saya telah melihat kasus di mana saya tergoda. Kinerja sistem semacam itu pada skala membunuh percobaan itu. Namun, itu mungkin contoh terbaik dari contoh terkait non-kinerja.
Godeke

Sebenarnya, IS-A dan juga skenario reservasi yang cocok kemungkinan akan tetap 1: 1, bahkan jika data historis disimpan.
Tripartio

125

Salah satu alasannya adalah efisiensi database. Memiliki hubungan 1: 1 memungkinkan Anda untuk membagi bidang yang akan terpengaruh selama kunci baris / tabel. Jika tabel A memiliki banyak pembaruan dan tabel b memiliki banyak pembacaan (atau memiliki banyak pembaruan dari aplikasi lain), maka penguncian tabel A tidak akan memengaruhi apa yang terjadi pada tabel B.

Yang lain memunculkan poin yang bagus. Keamanan juga bisa menjadi alasan yang baik tergantung pada bagaimana aplikasi dll memukul sistem. Saya cenderung mengambil pendekatan yang berbeda, tetapi ini bisa menjadi cara mudah untuk membatasi akses ke data tertentu. Sangat mudah untuk hanya menolak akses ke meja tertentu dalam keadaan darurat.

Entri blog saya tentang itu.


47

Kekurangan. Hubungan data mungkin secara teknis 1: 1, tetapi baris yang sesuai tidak harus ada untuk setiap baris. Jadi, jika Anda memiliki dua puluh juta baris dan ada beberapa set nilai yang hanya ada untuk 0,5% dari mereka, penghematan ruang sangat besar jika Anda mendorong kolom-kolom itu ke dalam tabel yang dapat dihuni secara jarang.


8
"tetapi baris yang sesuai tidak harus ada untuk setiap baris" Maka itu bukan 1: 1. Anda berbicara tentang 1: 0,1.

1
Ya. Tidak tahu apakah OP menarik perbedaan.
kekacauan

2
Yah, saya berasumsi mereka melakukannya karena 1: 0,1 memiliki banyak kegunaan, termasuk milik Anda tetapi 1: 1 memiliki jauh lebih sedikit. Dan mereka berjuang untuk menemukan kegunaan, jadi saya akan mengatakan OP menarik perbedaan.

12
Asumsi kerja saya berlawanan karena dia menyebutkan 1: 1, 1: banyak, dan banyak: banyak tanpa menyebutkan 1: 0,1.
kekacauan

26

Sebagian besar jawaban berperingkat tinggi memberikan penyetelan basis data dan alasan optimisasi yang sangat berguna untuk hubungan 1: 1, tetapi saya tidak ingin berfokus pada contoh selain "di alam liar" di mana hubungan 1: 1 terjadi secara alami.

Harap perhatikan satu karakteristik penting dari implementasi database dari sebagian besar contoh ini: tidak ada informasi historis yang disimpan tentang hubungan 1: 1. Artinya, hubungan ini adalah 1: 1 pada suatu titik waktu tertentu. Jika perancang basis data ingin mencatat perubahan dalam hubungan peserta dari waktu ke waktu, maka hubungan tersebut menjadi 1: M atau M: M; mereka kehilangan sifat 1: 1 mereka. Dengan memahami itu, begini:

  • "Is-A" atau hubungan supertipe / subtipe atau warisan / klasifikasi: Kategori ini adalah ketika satu entitas adalah tipe spesifik dari entitas lain. Misalnya, mungkin ada entitas Karyawan dengan atribut yang berlaku untuk semua karyawan, dan entitas yang berbeda untuk menunjukkan tipe karyawan tertentu dengan atribut unik untuk tipe karyawan itu, misalnya Dokter, Akuntan, Pilot, dll. Desain ini menghindari beberapa nol sejak banyak karyawan tidak akan memiliki atribut khusus dari subtipe tertentu. Contoh lain dalam kategori ini dapat berupa Produk sebagai supertipe, dan ManufacturingProduct and MaintenanceSupply sebagai subtipe; Hewan sebagai supertipe dan Anjing dan Kucing sebagai subtipe; Dll. Perhatikan bahwa setiap kali Anda mencoba memetakan hierarki warisan berorientasi objek ke dalam basis data relasional (seperti dalam model objek-relasional), ini adalah jenis hubungan yang mewakili skenario seperti itu.

  • Hubungan "bos" , seperti manajer, ketua, presiden, dll., Di mana unit organisasi hanya dapat memiliki satu bos, dan satu orang dapat menjadi bos dari hanya satu unit organisasi. Jika aturan itu berlaku, maka Anda memiliki hubungan 1: 1, seperti satu manajer departemen, satu CEO perusahaan, dll. Hubungan "bos" tidak hanya berlaku untuk orang. Jenis hubungan yang sama terjadi jika hanya ada satu toko sebagai kantor pusat perusahaan, atau jika hanya satu kota yang menjadi ibu kota suatu negara, misalnya.

  • Beberapa jenis alokasi sumber daya yang langka , misalnya satu karyawan hanya dapat ditugaskan satu mobil perusahaan (misalnya satu truk per sopir truk, satu taksi per pengemudi taksi, dll). Seorang kolega memberi saya contoh ini baru-baru ini.

  • Perkawinan (setidaknya dalam yurisdiksi hukum di mana poligami ilegal): satu orang hanya dapat menikah dengan satu orang pada satu waktu. Saya mendapatkan contoh ini dari buku teks yang menggunakan ini sebagai contoh hubungan 1: 1 unary ketika perusahaan mencatat pernikahan antara karyawannya.

  • Reservasi yang cocok : ketika reservasi unik dibuat dan kemudian dipenuhi sebagai dua entitas yang terpisah. Misalnya, sistem penyewaan mobil mungkin mencatat reservasi di satu entitas, dan kemudian sewa aktual di entitas terpisah. Meskipun situasi seperti itu dapat dirancang sebagai satu kesatuan, mungkin masuk akal untuk memisahkan entitas tersebut karena tidak semua reservasi terpenuhi, dan tidak semua penyewaan membutuhkan reservasi, dan kedua situasi tersebut sangat umum.

Saya ulangi peringatan yang saya buat sebelumnya bahwa sebagian besar dari ini adalah hubungan 1: 1 hanya jika tidak ada informasi historis yang dicatat. Jadi, jika seorang karyawan mengubah peran mereka dalam suatu organisasi, atau seorang manajer mengambil tanggung jawab dari departemen yang berbeda, atau seorang karyawan ditugaskan kembali sebuah kendaraan, atau seseorang menjadi janda dan menikah lagi, maka hubungan para peserta dapat berubah. Jika database tidak menyimpan riwayat sebelumnya tentang hubungan 1: 1 ini, maka mereka tetap hubungan 1: 1 yang sah. Tetapi jika database mencatat informasi historis (seperti menambahkan tanggal mulai dan berakhir untuk setiap hubungan), maka mereka semua berubah menjadi hubungan M: M.

Ada dua pengecualian untuk catatan sejarah: Pertama, beberapa hubungan jarang berubah sehingga informasi historis biasanya tidak disimpan. Misalnya, sebagian besar hubungan IS-A (misalnya jenis produk) tidak dapat diubah; yaitu, mereka tidak pernah bisa berubah. Dengan demikian, titik catatan sejarah diperdebatkan; ini akan selalu diimplementasikan sebagai hubungan 1: 1 yang alami. Kedua, toko hubungan sewa-reservasi bertanggal secara terpisah, karena reservasi dan sewa adalah acara independen, masing-masing dengan tanggalnya sendiri. Karena entitas memiliki tanggal sendiri, alih-alih hubungan 1: 1 sendiri memiliki tanggal mulai, ini akan tetap sebagai hubungan 1: 1 meskipun informasi historis disimpan.


2
Saya sangat suka bagaimana Anda terjebak pada semangat pertanyaan asli tentang kapan hubungan seperti itu benar dan tidak ketika itu berguna karena alasan duniawi seperti sifat fisik komputer.
user1852503

21

Pertanyaan Anda dapat ditafsirkan dalam beberapa cara, karena cara Anda mengucapkannya. Tanggapan menunjukkan ini.

Pasti ada hubungan 1: 1 antara item data di dunia nyata. Tidak ada pertanyaan tentang itu. Hubungan "is a" umumnya satu lawan satu. Mobil adalah kendaraan. Satu mobil adalah satu kendaraan. Satu kendaraan mungkin satu mobil. Beberapa kendaraan adalah truk, dalam hal ini satu kendaraan bukan mobil. Beberapa jawaban menjawab penafsiran ini.

Tapi saya pikir apa yang sebenarnya Anda tanyakan adalah ... ketika hubungan 1: 1 ada, haruskah tabel terpecah? Dengan kata lain, apakah Anda pernah memiliki dua tabel yang berisi kunci yang persis sama? Dalam praktiknya, kebanyakan dari kita hanya menganalisis kunci primer, dan bukan kunci kandidat lainnya, tetapi pertanyaan itu sedikit berbeda.

Aturan normalisasi untuk 1NF, 2NF, dan 3NF tidak pernah mengharuskan penguraian (pemisahan) tabel menjadi dua tabel dengan kunci primer yang sama. Saya belum mengetahui apakah meletakkan skema di BCNF, 4NF, atau 5NF dapat menghasilkan dua tabel dengan kunci yang sama. Dari atas kepala saya, saya akan menebak bahwa jawabannya adalah tidak.

Ada tingkat normalisasi yang disebut 6NF. Aturan normalisasi untuk 6NF pasti dapat menghasilkan dua tabel dengan kunci primer yang sama. 6NF memiliki keunggulan dibandingkan 5NF sehingga NULLS dapat sepenuhnya dihindari. Ini penting untuk beberapa, tetapi tidak semua, perancang basis data. Saya tidak pernah repot-repot memasukkan skema ke 6NF.

Dalam 6NF data yang hilang dapat diwakili oleh baris yang dihilangkan, bukan baris dengan NULL di beberapa kolom.

Ada alasan selain normalisasi untuk tabel pemecahan. Terkadang tabel split menghasilkan kinerja yang lebih baik. Dengan beberapa mesin basis data, Anda bisa mendapatkan manfaat kinerja yang sama dengan mempartisi tabel alih-alih membaginya. Ini dapat memiliki keuntungan menjaga desain logis mudah dipahami, sambil memberikan mesin database alat yang dibutuhkan untuk mempercepat.


19

Saya menggunakannya terutama karena beberapa alasan. Salah satunya adalah perbedaan signifikan dalam tingkat perubahan data. Beberapa tabel saya mungkin memiliki jejak audit di mana saya melacak versi catatan sebelumnya, jika saya hanya ingin melacak versi sebelumnya dari 5 dari 10 kolom yang membelah 5 kolom tersebut ke tabel terpisah dengan mekanisme jejak audit di atasnya lebih efisien. Juga, saya mungkin memiliki catatan (katakan untuk aplikasi akuntansi) yang hanya menulis. Anda tidak dapat mengubah jumlah dolar, atau akun yang digunakan untuk itu, jika Anda membuat kesalahan maka Anda perlu membuat catatan terkait untuk menulis, menyesuaikan catatan yang salah, kemudian membuat entri koreksi. Saya memiliki batasan pada tabel yang mendukung fakta bahwa mereka tidak dapat diperbarui atau dihapus, tetapi saya mungkin memiliki beberapa atribut untuk objek yang dapat ditempa, mereka disimpan dalam tabel terpisah tanpa batasan modifikasi. Lain waktu saya melakukan ini adalah dalam aplikasi rekam medis. Ada data yang terkait dengan kunjungan yang tidak dapat diubah setelah ditutup, dan data lain yang terkait dengan kunjungan yang dapat diubah setelah keluar. Dalam hal ini saya akan membagi data dan meletakkan pemicu di meja terkunci menolak pembaruan ke meja terkunci ketika ditandatangani, tetapi memungkinkan pembaruan data yang tidak ditandatangani oleh dokter.

Poster lain mengomentari 1: 1 tidak dinormalisasi, saya akan tidak setuju dengan itu dalam beberapa situasi, terutama subtyping. Katakanlah saya memiliki tabel karyawan dan kunci utama adalah SSN mereka (ini adalah contoh, mari kita simpan perdebatan apakah ini kunci yang baik atau tidak untuk utas lainnya). Karyawan dapat dari berbagai jenis, katakan sementara atau permanen dan jika mereka permanen mereka memiliki lebih banyak bidang yang harus diisi, seperti nomor telepon kantor, yang seharusnya tidak hanya nol jika tipe = 'Permanen'. Dalam database bentuk normal ke-3, kolom seharusnya hanya bergantung pada kunci, yang berarti karyawan, tetapi sebenarnya tergantung pada karyawan dan jenisnya, sehingga hubungan 1: 1 sangat normal, dan diinginkan dalam hal ini. Ini juga mencegah tabel terlalu jarang, jika saya memiliki 10 kolom yang biasanya diisi,


1
@ShaneD +1 untuk contoh kata nyata. Saya juga suka perbedaan "Read Only".
Michael Riley - AKA Gunny

13

Skenario paling umum yang bisa saya pikirkan adalah ketika Anda memiliki BLOB. Katakanlah Anda ingin menyimpan gambar besar dalam database (biasanya, bukan cara terbaik untuk menyimpannya, tetapi terkadang kendala membuatnya lebih nyaman). Anda biasanya ingin gumpalan berada di tabel terpisah untuk meningkatkan pencarian data non-gumpalan.


Serius? Biasanya bukan cara terbaik? Satu-satunya vendor musik online terbesar menyimpannya, ahem, MP3, dalam database.

1
@Ark, ada beberapa pertanyaan yang berhubungan dengan cara terbaik untuk menyimpan gambar, baik dalam database atau keluar, dan konsensus tampaknya untuk sebagian besar sistem file lebih cepat. Saya membayangkan jika itu benar, maka hal yang sama berlaku untuk MP3.
James McMahon

1
"Anda biasanya menginginkan BLOB dalam tabel terpisah" - Biasanya BLOB tidak disimpan sebaris (jika mereka melebihi panjang baris spesifik db-spesifik). Gumpalan jika tidak sebaris, biasanya disimpan sebagai 'penunjuk' ke lokasi fisik mereka di halaman DB.
blispr

1
Dapat diperdebatkan apakah masuk akal untuk menyimpan data besar (file) dalam database, ada pula yang menentang semua memiliki alasan yang valid, tetapi +1 untuk contoh 1: 1.
Kevin Peno

Ini harus benar-benar menjadi pertanyaannya sendiri yang ingin saya lihat. Dengan masukan dari orang-orang pintar yang mengukur waktu / prestanda untuk berbagai harddisk / OS / RDBMS. HARUS ada jawaban pasti untuk pertanyaan ini, tidak boleh diperdebatkan, jika diukur dengan benar. Belum ada yang melakukan semuanya?
Stefan

9

Dalam hal ilmu murni, ya, mereka tidak berguna.

Dalam database nyata terkadang berguna untuk menyimpan bidang yang jarang digunakan dalam tabel terpisah: untuk mempercepat permintaan menggunakan ini dan hanya bidang ini; untuk menghindari kunci, dll.


3
@ Mark Brady: tidak, tidak, karena ada Na2SO4 dan KCl. Saat membuat basis data semesta, Anda harus membuat t_atom (id INT, proton INT, neutron INT), t_molecule (id INT, atom_id INT) dan membuat gabungan. Itu adalah hubungan satu-ke-banyak.
Quassnoi

2
Pada pemikiran kedua, INT mungkin tidak cukup di sini, karena ada 10 ^ 78 atom di alam semesta. Bahkan dua GUID yang direkatkan bersama hanya dapat menampung 1/10 atom. Kami membutuhkan RAW (40) kunci utama - kalau-kalau database kami akan tumbuh terlalu cepat. Materi gelap, Anda tahu, tentang sesuatu.
Quassnoi

1
Oh, jadi hanya teori relasional yang murni sains. Tidak menyadari bahwa kimia bukanlah ilmu murni kecuali kita membangun database untuk itu.

1
@ Mark Brady: tidak bisakah Anda hanya mengatakan apa yang tidak Anda setujui? Saya tidak mendapatkan sarkasme Anda, sungguh :)
Quassnoi

Quassnoi (dan Mark Brady) Anda mendapat upvote untuk LOL yang baru saja Anda berikan kepada saya.
Pulsehead

8

Daripada menggunakan tampilan untuk membatasi akses ke bidang, terkadang masuk akal untuk menyimpan bidang terbatas dalam tabel terpisah yang hanya dapat diakses oleh pengguna tertentu.


8

Saya juga bisa memikirkan situasi di mana Anda memiliki model OO di mana Anda menggunakan warisan, dan pohon warisan harus dipertahankan untuk DB.

Misalnya, Anda memiliki Burung dan Ikan kelas yang keduanya mewarisi dari Hewan. Dalam DB Anda, Anda bisa memiliki tabel 'Hewan', yang berisi bidang umum dari kelas Hewan, dan tabel Hewan memiliki hubungan satu-ke-satu dengan tabel Burung, dan hubungan satu-ke-satu dengan Ikan meja.

Dalam hal ini, Anda tidak harus memiliki satu tabel Hewan yang berisi banyak kolom yang dapat dibatalkan untuk menyimpan properti Burung dan Ikan, di mana semua kolom yang berisi data Ikan diatur ke NULL saat catatan mewakili burung.

Sebaliknya, Anda memiliki catatan di tabel Burung yang memiliki hubungan satu-ke-satu dengan catatan di tabel Hewan.


Jawaban ini terkait dengan pertanyaan lain: yaitu dari hubungan 1 hingga 0-1.
Hibou57

8

1-1 hubungan juga diperlukan jika Anda memiliki terlalu banyak informasi. Ada batasan ukuran rekaman pada setiap catatan dalam tabel. Kadang-kadang tabel dibagi menjadi dua (dengan informasi yang paling sering ditanyakan dalam tabel utama) hanya agar ukuran rekaman tidak terlalu besar. Database juga lebih efisien dalam kueri jika tabelnya sempit.


6

Ini juga merupakan cara untuk memperpanjang tabel yang sudah di produksi dengan risiko yang lebih kecil (dirasakan) daripada perubahan database "nyata". Melihat hubungan 1: 1 dalam sistem legacy seringkali merupakan indikator yang baik bahwa bidang ditambahkan setelah desain awal.


Mengapa menghindar? Apakah Anda berpikir bahwa meja baru spankin merek memiliki risiko sebanyak mengubah tabel yang ada. Harap sebutkan hal-hal yang pecah ketika tabel baru ditambahkan. Satu-satunya hal yang dapat saya pikirkan adalah kode yang beroperasi di atas metadata yaitu SELECT * Dari USER_TABLES loop <something> end loop.

1
Ini kurang bahwa hal-hal akan rusak daripada sering dibutuhkan lebih banyak pekerjaan untuk menambahkan tabel 1: 1 dengan benar daripada menambahkan bidang tambahan. Sekarang catatan baru berarti memperbarui dua tabel, bukan hanya satu. Menghapus catatan? Dua pertanyaan juga. Sekarang kami mempertahankan lebih banyak kode daripada mengubahnya satu kali.
JT Grimes

@ Mark Brady, dataset sangat diketik bisa menjadi neraka untuk mengelola ketika menambahkan beberapa filed dalam database. Jika tableadapter dalam dataset memiliki banyak querys dan sebagainya, jauh lebih mudah untuk hanya menyeret tabel baru dan kemudian selesai.
Stefan

@Stefan: Tidak ada sisipan Cascade.
JT Grimes

@Boofus, well .. kadang-kadang kita harus menggunakan keyboard dan program sedikit untuk uang yang kita hasilkan. ;)
Stefan

5

Dalam SQL tidak mungkin untuk menegakkan hubungan 1: 1 antara dua tabel yang wajib di kedua sisi (kecuali tabel hanya baca-saja). Untuk tujuan paling praktis, hubungan "1: 1" dalam SQL benar-benar berarti 1: 0 | 1.

Ketidakmampuan untuk mendukung kardinalitas wajib dalam batasan referensial adalah salah satu keterbatasan serius SQL. Kendala "yang bisa ditangguhkan" tidak benar-benar diperhitungkan karena itu hanyalah cara untuk mengatakan bahwa kendala tersebut tidak ditegakkan beberapa saat.


4

Jika Anda menggunakan data dengan salah satu ORM populer, Anda mungkin ingin memecah tabel menjadi beberapa tabel agar sesuai dengan Hirarki Objek Anda.


3
Sedih, alasan sedih. Jika ORM tidak dapat menangani perbedaan antara model objek dan penyimpanan fisik maka .... bersedih.

Sebenarnya, jika saya mengerti dengan benar, ini berarti menerapkan pusaka klasifikasi dalam basis data relasional. Ini adalah kasus hubungan 1: 1 yang sepenuhnya sah dan alami; tidak ada yang "menyedihkan" tentang itu.
Tripartio

4

Saya telah menemukan bahwa ketika saya melakukan hubungan 1: 1 sepenuhnya karena alasan sistemik, bukan alasan relasional.

Sebagai contoh, saya telah menemukan bahwa menempatkan aspek-aspek yang disediakan pengguna dalam 1 tabel dan menempatkan bidang pengguna yang dapat diedit pengguna dalam tabel yang berbeda memungkinkan secara logis menulis aturan-aturan tentang izin pada bidang-bidang itu jauh lebih mudah.

Tetapi Anda benar, dalam teori, hubungan 1: 1 sepenuhnya dibuat-buat, dan hampir merupakan fenomena. Namun secara logis itu memungkinkan program dan optimasi abstrak database lebih mudah.


Fenomena: adalah fakta atau peristiwa yang memiliki kepentingan ilmiah yang rentan dijelaskan dan / atau dijelaskan secara ilmiah. Saya tidak berpikir Anda bermaksud menggunakan kata itu.

1
Saya memang bermaksud menggunakannya, dalam konotasinya, menjadi hal yang langka. Biasanya fenomena digunakan untuk menggambarkan outlier, meskipun definisinya, mendefinisikan kebutuhan Anda untuk memperbaiki setiap kata dalam posting saya.
DevelopingChris

@DevelopingChris Saya setuju bahwa 1: 1 adalah fenomena. Kecuali untuk teori sekolah, ada sangat sedikit situasi dunia nyata yang ada.
Michael Riley - AKA Gunny

4

Sebagian besar waktu, desain dianggap 1: 1 sampai seseorang bertanya, "mengapa tidak bisa 1: banyak"? Menceraikan konsep satu sama lain secara prematur dilakukan untuk mengantisipasi skenario umum ini. Orang dan Alamat tidak mengikat begitu erat. Banyak orang memiliki banyak alamat. Dan seterusnya...

Biasanya dua ruang objek terpisah menyiratkan bahwa satu atau keduanya dapat dikalikan (x: banyak). Jika dua objek benar-benar 1: 1, bahkan secara filosofis, maka itu lebih merupakan hubungan-is. Dua "objek" ini sebenarnya adalah bagian dari satu objek utuh.


3

informasi tambahan yang hanya diperlukan dalam skenario tertentu. dalam aplikasi lama dan bahasa pemrograman (seperti RPG) di mana program dikompilasi di atas tabel (jadi jika tabel berubah Anda harus mengkompilasi ulang program). Tag bersama file juga bisa berguna jika Anda harus khawatir tentang ukuran tabel.


2

Paling sering itu lebih merupakan konstruksi fisik daripada logis. Ini biasanya digunakan untuk mempartisi tabel secara vertikal untuk mengambil keuntungan dari pemisahan I / O di perangkat fisik atau optimasi kueri lainnya yang terkait dengan memisahkan data atau data yang jarang diakses yang perlu dijaga lebih aman daripada atribut lainnya pada objek yang sama. (SSN, Gaji, dll).

Satu-satunya pertimbangan logis yang menentukan hubungan 1-1 adalah ketika atribut tertentu hanya berlaku untuk beberapa entitas. Namun, dalam kebanyakan kasus ada cara yang lebih baik / lebih normal untuk memodelkan data melalui ekstraksi entitas.


2

Alasan terbaik yang dapat saya lihat untuk hubungan 1: 1 adalah SuperType SubType dari desain database. Saya membuat struktur data MLS Real Estat berdasarkan model ini. Ada lima umpan data yang berbeda; Perumahan, Komersial, Multi-Keluarga, Hotel & Tanah.

Saya membuat properti SuperType yang disebut yang berisi data yang umum untuk masing-masing dari lima umpan data terpisah. Ini memungkinkan pencarian "sederhana" yang sangat cepat di semua tipe data.

Saya membuat lima SubTipe terpisah yang menyimpan elemen data unik untuk masing-masing dari lima umpan data. Setiap catatan SuperType memiliki hubungan 1: 1 dengan catatan SubType yang sesuai.

Jika pelanggan menginginkan pencarian terperinci, mereka harus memilih jenis Sub-Super misalnya PropertyResidential.


1

Menurut pendapat saya hubungan 1: 1 memetakan warisan kelas pada RDBMS. Ada tabel A yang berisi atribut umum, yaitu status kelas partent. Setiap status kelas yang diwariskan dipetakan pada RDBMS dengan tabel B dengan hubungan 1: 1 ke tabel A, berisi atribut khusus. Namend tabel A juga berisi bidang "tipe" yang mewakili fungsionalitas "casting"

Sampai jumpa Mario


1

Anda dapat membuat tabel hubungan satu lawan satu jika ada manfaat kinerja yang signifikan. Anda bisa meletakkan bidang yang jarang digunakan ke dalam tabel terpisah.


0

Hubungan 1: 1 tidak benar-benar masuk akal jika Anda masuk ke normalisasi karena apa pun yang akan 1: 1 akan disimpan dalam tabel yang sama.

Namun di dunia nyata, seringkali berbeda. Anda mungkin ingin memecah data Anda agar sesuai dengan antarmuka aplikasi Anda.


Saya tidak setuju dengan teori satu meja. Ada kalanya hubungan SuperType SubType paling baik diungkapkan dengan hubungan 1: 1.
Michael Riley - AKA Gunny

1
Sebenarnya, jika Anda melakukan normalisasi ekstrem maka Anda akan memiliki lebih banyak hubungan 1: 1. Bentuk-bentuk awal normalisasi yang diusulkan oleh Date termasuk aturan bahwa tidak ada kolom yang mengizinkan NULL. Itu berarti bahwa jika sebuah kolom mungkin NULL untuk sebuah tabel maka itu harus di dalam tabelnya sendiri dan satu baris ditambahkan hanya ketika itu dinilai. Aturan ini sebagian besar telah dibuang, termasuk oleh Codd.
Tom H

0

Mungkin jika Anda memiliki beberapa jenis objek yang diketik dalam database Anda.

Katakan dalam tabel, T1, Anda memiliki kolom C1, C2, C3 ... dengan relasi satu ke satu. Tidak apa-apa, itu dalam bentuk normal. Sekarang katakan dalam tabel T2, Anda memiliki kolom C1, C2, C3, ... (nama mungkin berbeda, tetapi katakan jenis dan perannya sama) dengan relasi satu ke satu juga. Tidak apa-apa untuk T2 karena alasan yang sama dengan T1.

Namun dalam kasus ini, saya melihat cocok untuk tabel T3 yang terpisah, memegang C1, C2, C3 ... dan hubungan satu ke satu dari T1 ke T3 dan dari T2 ke T3. Saya bahkan lebih melihat cocok jika ada tabel lain, dengan yang sudah ada satu ke beberapa C1, C2, C3 ... katakanlah dari tabel A ke beberapa baris dalam tabel B. Kemudian, alih-alih T3, Anda menggunakan B, dan memiliki relasi satu ke satu dari T1 ke B, sama untuk dari T2 ke B, dan masih sama untuk relasi berganda dari A ke B.

Saya percaya normalisasi tidak setuju dengan ini, dan itu mungkin ide di luarnya: mengidentifikasi tipe objek dan memindahkan objek dari tipe yang sama ke kumpulan penyimpanan mereka sendiri, menggunakan hubungan satu ke satu dari beberapa tabel, dan satu ke beberapa hubungan dari beberapa tabel lainnya.


0

Tidak perlu bagus untuk tujuan keamanan tetapi ada cara yang lebih baik untuk melakukan pemeriksaan keamanan. Bayangkan, Anda membuat kunci yang hanya bisa membuka satu pintu. Jika kunci dapat membuka pintu lain, Anda harus membunyikan alarm. Intinya, Anda dapat memiliki "CitizenTable" dan "VotingTable". Citizen One memberikan suara untuk Calon Satu yang disimpan dalam Voting Table. Jika satu warga muncul di meja pemungutan suara lagi, maka mereka harus menjadi alarm. Jadilah saran, ini adalah hubungan satu lawan satu karena kami tidak merujuk ke bidang kandidat, kami merujuk pada tabel pemungutan suara dan tabel warga.

Contoh:

 Citizen Table
 id = 1, citizen_name = "EvryBod"
 id = 2, citizen_name = "Lesly"
 id = 3, citizen_name = "Wasserman"

 Candidate Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"

Lalu, jika kita melihat tabel pemilihan sebagai berikut:

 Voting Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"
 id = 4, citizen_id = 3, candidate_name = "Hill Arry"
 id = 5, citizen_id = 3, candidate_name = "Hill Arry"

Kita bisa mengatakan bahwa warga negara nomor 3 adalah pembohong terbakar yang menipu Bern Nie. Contoh saja.


0

Ketika Anda berurusan dengan database dari produk pihak ketiga, maka Anda mungkin tidak ingin mengubah database mereka untuk mencegah kopling ketat. tetapi Anda mungkin memiliki data yang sesuai 1: 1 dengan data mereka


-4

Di mana saja ada dua entitas yang sepenuhnya independen berbagi hubungan satu-ke-satu. Pasti ada banyak contoh:

orang <-> dokter gigi (1: N, jadi salah!)

orang <-> dokter (1: N, jadi itu juga salah!)

pasangan <-> pasangan (1: 0 | 1, jadi sebagian besar salah!)

EDIT: Ya, itu adalah contoh yang sangat buruk, terutama jika saya selalu mencari 1: 1, bukan 0 atau 1 di kedua sisi. Saya kira otak saya salah menembak :-)

Jadi, saya akan coba lagi. Ternyata, setelah sedikit berpikir, bahwa satu-satunya cara Anda dapat memiliki dua entitas terpisah yang harus (sejauh perangkat lunak berjalan) bersama-sama sepanjang waktu adalah agar mereka ada bersama dalam kategorisasi yang lebih tinggi. Kemudian, jika dan hanya jika Anda jatuh ke dalam dekomposisi yang lebih rendah, semuanya terpisah dan harus terpisah, tetapi pada tingkat yang lebih tinggi mereka tidak dapat hidup tanpa satu sama lain. Konteks, maka kuncinya.

Untuk basis data medis, Anda mungkin ingin menyimpan informasi yang berbeda tentang wilayah tubuh tertentu, menjadikannya sebagai entitas yang terpisah. Dalam hal ini, seorang pasien hanya memiliki satu kepala, dan mereka perlu memilikinya, atau mereka bukan pasien. (Mereka juga memiliki satu hati, dan sejumlah organ tunggal lain yang diperlukan). Misalnya, jika Anda tertarik untuk melacak operasi, maka setiap wilayah harus menjadi entitas terpisah yang unik.

Dalam sistem produksi / inventaris, jika Anda melacak perakitan kendaraan, maka Anda tentu ingin menyaksikan kemajuan mesin secara berbeda dari bodi mobil, namun ada hubungan satu ke satu. Perawatan harus memiliki mesin, dan hanya satu (atau tidak akan menjadi 'mobil' lagi). Mesin hanya milik satu mobil.

Dalam setiap kasus Anda dapat menghasilkan entitas yang terpisah sebagai satu catatan besar, tetapi mengingat tingkat dekomposisi, itu akan salah. Mereka, dalam konteks khusus ini, benar-benar entitas independen, meskipun mereka mungkin tidak muncul pada tingkat yang lebih tinggi.

Paul.


Seorang dokter gigi memiliki satu pasien? Seorang dokter hanya memiliki satu pasien? Seseorang untuk pasangan hanya 1: 1 jika Anda menempatkan 1 pasangan di satu meja dan pasangan lainnya di meja lain (saya akan mengatakan laki-laki di satu dan perempuan di yang lain. Oh well)

Mark, Anda bisa saja melakukan tabel "Pasangan" di mana baris selalu berpasangan. Tapi kalau tidak saya setuju dengan, ehm ... kata-kata kasar Anda. : P
JohannesH

Ya, saya setuju dengan Mark juga. :-) (Saya saya diizinkan untuk menonaktifkan jawaban bodoh saya sendiri?)
Paul W Homer

Yeh, mengakui "kebodohan" membuktikan betapa pandainya Anda. Pengecut nyata menghapus jawaban bodoh mereka ... untung mereka bukan dokter, menghapus catatan medis. Sebenarnya, kami juga tidak beruntung; reboot akan menjadi perawatan medis yang buruk.

2
Saya selalu membayangkan bahwa bahkan orang paling cerdas di dunia (siapa pun yang mungkin saat ini) masih memiliki momen kebodohan ambing mereka. Itu adalah kutukan manusia :-) Sedangkan komputer saya memiliki saat-saat yang nyaris intelijen.
Paul W Homer
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.