Pengantar
Menyimpan data adalah satu hal; menyimpan makna, berguna, benar data adalah hal lain. Sementara makna dan utilitas itu sendiri adalah kualitas subjektif, kebenaran setidaknya dapat didefinisikan dan ditegakkan secara logis. Jenis sudah memastikan bahwa angka adalah angka dan tanggal adalah tanggal, tetapi tidak dapat menjamin bahwa bobot atau jarak adalah angka positif atau mencegah rentang tanggal tumpang tindih. Batasan tuple, tabel, dan database menerapkan aturan pada data yang disimpan dan menolak nilai atau kombinasi nilai yang tidak lolos.
Batasan tidak membuat teknik validasi input lainnya tidak berguna dengan cara apa pun, bahkan ketika mereka menguji pernyataan yang sama. Waktu yang dihabiskan untuk mencoba dan gagal menyimpan data yang tidak valid adalah waktu yang terbuang. Pesan pelanggaran, seperti assert dalam sistem dan bahasa pemrograman aplikasi, hanya mengungkapkan masalah pertama dengan catatan kandidat pertama secara lebih rinci daripada siapa pun yang tidak langsung terlibat dengan kebutuhan database. Tetapi sejauh menyangkut kebenaran data, kendalanya adalah hukum, baik atau buruk; yang lainnya adalah saran.
On Tuples:Not Null, Default, and Check
Batasan non-null adalah kategori paling sederhana. Tuple harus memiliki nilai untuk atribut yang dibatasi, atau dengan kata lain, kumpulan nilai yang diizinkan untuk kolom tidak lagi menyertakan kumpulan kosong. Tidak ada nilai berarti tidak ada tupel:penyisipan atau pembaruan ditolak.
Melindungi dari nilai null semudah mendeklarasikan column_name COLUMN_TYPE NOT NULL di CREATE TABLE atau ADD COLUMN . Nilai null menyebabkan seluruh kategori masalah antara database dan pengguna akhir, jadi mendefinisikan batasan non-null secara refleks pada kolom mana pun tanpa alasan yang baik untuk mengizinkan null adalah kebiasaan yang baik.
Penyediaan nilai default jika tidak ada yang ditentukan (dengan penghilangan atau NULL explicit eksplisit ) dalam sisipan atau pembaruan tidak selalu dianggap sebagai kendala, karena catatan kandidat dimodifikasi dan disimpan, bukan ditolak. Di banyak DBMS, nilai default dapat dihasilkan oleh suatu fungsi, meskipun MySQL tidak mengizinkan fungsi yang ditentukan pengguna untuk tujuan ini.
Aturan validasi lainnya yang hanya bergantung pada nilai dalam satu tupel dapat diimplementasikan sebagai CHECK paksaan. Dalam arti tertentu, NOT NULL itu sendiri adalah singkatan dari CHECK (column_name IS NOT NULL); pesan kesalahan yang diterima dalam pelanggaran membuat sebagian besar perbedaan. CHECK , bagaimanapun, dapat menerapkan dan menegakkan kebenaran dari setiap predikat Boolean atas satu tupel. Misalnya, tabel yang menyimpan lokasi geografis harus CHECK (latitude >= -90 AND latitude < 90) , dan juga untuk garis bujur antara -180 dan 180 -- atau, jika tersedia, gunakan dan validasikan GEOGRAPHY tipe data.
Pada Tabel:Unik dan Pengecualian
Batasan tingkat tabel menguji tupel satu sama lain. Dalam batasan unik, hanya satu catatan yang mungkin memiliki kumpulan nilai tertentu untuk kolom yang dibatasi. Nullability dapat menyebabkan masalah di sini, karena NULL tidak pernah sama dengan apa pun, hingga dan termasuk NULL diri. Batasan unik pada (batman, robin) oleh karena itu memungkinkan salinan tak terbatas dari Batman Robinless apa pun.
Kendala pengecualian hanya didukung di PostgreSQL dan DB2, tetapi mengisi ceruk yang sangat berguna:mereka dapat mencegah tumpang tindih. Tentukan bidang dibatasi dan operasi yang masing-masing akan dievaluasi, dan catatan baru hanya akan diterima jika tidak ada catatan yang berhasil dibandingkan dengan setiap bidang dan operasi. Misalnya, schedules tabel dapat dikonfigurasi untuk menolak konflik:
-- text, int, etc. comparisons in exclusion constraints require this-- Postgres extensionCREATE EXTENSION btree_gist;CREATE TABLE schedules ( schedule_id SERIAL NOT NULL PRIMARY KEY, room_number TEXT NOT NULL, -- a range of TIMESTAMP WITH TIME ZONE provides both start and end duration TSTZRANGE, -- table-level constraints imply an index, since otherwise they'd -- have to search the entire table to validate a candidate record; -- GiST (generalized search tree) indexes are usually used in -- Postgres EXCLUDE USING GIST ( room_number WITH =, duration WITH && ));INSERT INTO schedules (room_number, duration)VALUES ('32A', '[2020-08-20T10:00:00Z,2020-08-20T11:00:00Z)');-- the same time in a different room: acceptedINSERT INTO schedules (room_number, duration)VALUES ('32B', '[2020-08-20T10:00:00Z,2020-08-20T11:00:00Z)');-- a half-hour overlap for an already-scheduled room: rejectedINSERT INTO schedules (room_number, duration)VALUES ('32A', '[2020-08-20T10:30:00Z,2020-08-20T11:30:00Z)');
Operasi upsert seperti PostgreSQL ON CONFLICT klausa atau ON DUPLICATE KEY UPDATE MySQL gunakan batasan level tabel untuk mendeteksi konflik. Dan seperti batasan non-null dapat dinyatakan sebagai CHECK batasan, batasan unik dapat dinyatakan sebagai batasan pengecualian pada kesetaraan.
Kunci Utama
Kendala unik memiliki kasus khusus yang sangat berguna. Dengan batasan non-null tambahan pada kolom atau kolom unik, setiap record dalam tabel dapat diidentifikasi secara tunggal oleh nilainya untuk kolom yang dibatasi, yang secara kolektif disebut kunci . Beberapa kunci kandidat dapat hidup berdampingan dalam sebuah tabel, seperti users terkadang masih memiliki email unik dan non-null yang berbeda s dan username s; tetapi mendeklarasikan kunci utama menetapkan kriteria tunggal yang dengannya catatan diketahui publik dan eksklusif. Beberapa RDBMS bahkan mengatur baris pada halaman dengan kunci utama, yang disebut untuk tujuan ini sebagai indeks berkerumun , untuk melakukan pencarian berdasarkan nilai kunci utama secepat mungkin.
Ada dua jenis kunci primer. Kunci alami didefinisikan pada kolom atau kolom "secara alami" termasuk dalam data tabel, sedangkan pengganti atau kunci sintetis diciptakan semata-mata untuk tujuan menjadi kunci. Kunci alami memerlukan perawatan -- lebih banyak hal dapat berubah daripada yang sering dikreditkan oleh perancang basis data, dari nama hingga skema penomoran. Tabel pencarian yang berisi nama negara dan wilayah dapat menggunakan kode ISO 3166 masing-masing sebagai kunci utama alami yang aman, tetapi users tabel dengan kunci alami berdasarkan nilai yang dapat diubah seperti nama atau alamat email mengundang masalah. Jika ragu, buat kunci pengganti.
Jika kunci alami mencakup beberapa kolom, kunci pengganti setidaknya harus selalu dipertimbangkan karena kunci multi-kolom membutuhkan lebih banyak upaya untuk dikelola. Namun, jika kunci alami cocok, kolom harus diurutkan dengan spesifisitas yang lebih tinggi seperti halnya dalam indeks:kode negara lalu kode wilayah, bukan sebaliknya.
Kunci pengganti secara historis berupa kolom bilangan bulat tunggal, atau BIGINT di mana miliaran akhirnya akan diberikan. Basis data relasional dapat secara otomatis mengisi kunci pengganti dengan bilangan bulat berikutnya dalam rangkaian, fitur yang biasanya disebut SERIAL atau IDENTITY .
Penghitung numerik autoincrementing bukan tanpa kekurangan:menambahkan catatan dengan kunci yang dibuat sebelumnya dapat menyebabkan konflik, dan jika nilai sekuensial diekspos ke pengguna, mudah bagi mereka untuk menebak apa kunci valid lainnya. Pengidentifikasi Unik Universal, atau UUID, menghindari kelemahan ini dan telah menjadi pilihan umum untuk kunci pengganti, meskipun mereka juga jauh lebih besar di halaman daripada angka sederhana. Jenis UUID v1 (berbasis alamat MAC) dan v4 (pseudorandom) paling sering digunakan.
Di Basis Data:Kunci Asing
Basis data relasional hanya mengimplementasikan satu kelas batasan multi-tabel,
"Diagram hubungan entitas" informal atau ERD ini menunjukkan awal dari skema untuk database perpustakaan dan koleksi serta pelanggannya. Setiap sisi mewakili hubungan antara tabel yang terhubung. | mesin terbang menunjukkan satu catatan di sisinya, sedangkan mesin terbang "kaki gagak" mewakili banyak:perpustakaan menyimpan banyak buku dan memiliki banyak pelanggan.
Kunci asing adalah salinan dari kunci utama tabel lain, kolom untuk kolom (titik yang mendukung kunci pengganti:hanya satu kolom untuk disalin dan dirujuk), dengan nilai yang menghubungkan catatan dalam tabel ini ke catatan "induk" di dalamnya. Dalam skema di atas, books tabel mempertahankan library_id kunci asing ke libraries , yang menampung buku, dan author_id kepada authors , yang menulisnya. Namun apa jadinya jika sebuah buku disisipkan dengan author_id yang tidak ada di authors ?
Jika kunci asing tidak dibatasi -- yaitu, itu hanya kolom atau kolom lain -- sebuah buku dapat memiliki penulis yang tidak ada. Ini adalah masalah:jika seseorang mencoba mengikuti tautan antara books dan authors , mereka berakhir di mana-mana. Jika authors.author_id adalah bilangan bulat seri, ada juga kemungkinan bahwa tidak ada yang memperhatikan sampai author_id palsu akhirnya ditugaskan, dan Anda mendapatkan salinan tertentu dari Don Quixote pertama dikaitkan dengan tidak ada yang diketahui dan kemudian ke Pierre Menard, dengan Miguel Cervantes tidak dapat ditemukan.
Membatasi kunci asing tidak dapat mencegah buku disalahartikan jika author_id yang salah arahkan ke catatan yang ada di authors , jadi pemeriksaan dan pengujian lainnya tetap penting. Namun, himpunan nilai kunci asing yang masih ada hampir selalu merupakan bagian kecil dari mungkin nilai kunci asing, sehingga batasan kunci asing akan menangkap dan mencegah sebagian besar nilai yang salah. Dengan batasan kunci asing, Quixote dengan penulis yang tidak ada akan ditolak alih-alih direkam.
Apakah Dari sinilah "Relasional" dalam "Database Relasional" Berasal?
Kunci asing membuat hubungan antar tabel, tetapi tabel seperti yang kita ketahui secara matematis relasi di antara kumpulan nilai yang mungkin untuk setiap atribut. Tuple tunggal menghubungkan nilai untuk kolom A dengan nilai untuk kolom B dan seterusnya. Makalah asli E.F. Codd menggunakan "relasional" dalam pengertian ini.
Hal ini telah menyebabkan kebingungan yang tiada akhir dan kemungkinan akan terus berlanjut selamanya.
Untuk Nilai Tertentu yang Benar
Ada lebih banyak cara di mana data mungkin salah daripada dibahas di sini. Kendala membantu, tetapi bahkan mereka hanya begitu fleksibel; banyak spesifikasi intra-tabel umum, seperti batas dua atau lebih tinggi pada berapa kali nilai diizinkan untuk muncul dalam kolom, hanya dapat diterapkan dengan pemicu.
Tetapi ada juga cara di mana struktur tabel dapat menyebabkan inkonsistensi. Untuk mencegah hal ini, kita perlu menyusun kunci primer dan kunci asing tidak hanya untuk mendefinisikan dan memvalidasi tetapi untuk menormalkan hubungan antar tabel. Namun, pertama-tama, kita baru saja membahas bagaimana hubungan antar tabel mendefinisikan struktur database itu sendiri.
