Rajah menunjukkan jadual (nisbah darjah 5) yang mengandungi beberapa maklumat tentang pekerja sebuah perusahaan hipotesis. Barisan jadual sepadan dengan tupel. Setiap baris sebenarnya adalah perihalan satu objek dunia sebenar (dalam kes ini, pekerja), yang ciri-cirinya terkandung dalam lajur. Hubungan perhubungan sepadan dengan set entiti, dan tupel sepadan dengan entiti. Lajur dalam jadual yang mewakili hubungan hubungan dipanggil sifat-sifat.

Setiap atribut ditakrifkan pada domain, jadi domain boleh dianggap sebagai set nilai yang sah untuk atribut tertentu. Atribut berbilang perhubungan yang sama, malah atribut perhubungan yang berbeza, boleh ditakrifkan pada domain yang sama.

Atribut yang nilainya secara unik mengenal pasti tupel dipanggil kunci (atau hanya kunci). Kuncinya ialah atribut Nombor Kakitangan, kerana nilainya adalah unik untuk setiap pekerja perusahaan. Jika tupel dikenal pasti hanya dengan menggabungkan nilai beberapa atribut, maka hubungan itu dikatakan mempunyai kunci komposit.

Kunci utama- dalam model data hubungan, salah satu kunci potensi perhubungan, dipilih sebagai kunci utama (atau kunci lalai).

Perhubungan boleh mengandungi berbilang kunci. Salah satu kunci sentiasa diisytiharkan utama, nilainya tidak boleh dikemas kini. Semua kunci perhubungan lain dipanggil kunci yang mungkin.

Dari sudut pandangan teori, semua kunci perhubungan yang berpotensi (kemungkinan) adalah setara, iaitu, ia mempunyai keunikan dan sifat minima yang sama. Walau bagaimanapun, kunci utama biasanya dipilih daripada kunci berpotensi yang paling mudah untuk tujuan praktikal tertentu, contohnya, untuk mencipta luaran kunci dalam aspek lain atau untuk mencipta indeks berkelompok. Oleh itu, sebagai peraturan, yang mempunyai saiz terkecil (storan fizikal) dan/atau termasuk bilangan atribut terkecil dipilih sebagai kunci utama.

Jika kunci utama terdiri daripada satu atribut, ia dipanggil dengan kunci mudah.

Jika kunci utama terdiri daripada dua atau lebih atribut, ia dipanggil kunci kompaun. Jadi, nama pertama, nama keluarga, patronimik, nombor pasport, siri pasport tidak boleh menjadi kunci utama secara individu, kerana ia mungkin sama untuk dua orang atau lebih. Tetapi tidak ada dua dokumen peribadi daripada jenis yang sama dengan siri dan nombor yang sama. Oleh itu, dalam hubungan yang mengandungi data tentang orang, kunci utama boleh menjadi subset atribut yang terdiri daripada jenis dokumen peribadi, siri dan nombornya.

Tidak seperti model data hierarki dan rangkaian, model hubungan tidak mempunyai konsep hubungan kumpulan. Untuk mencerminkan perkaitan antara tupel perhubungan yang berbeza, penduaan kuncinya digunakan.

Atribut yang merupakan salinan kunci perhubungan lain dipanggil kunci asing.

Sebagai contoh, hubungan antara JABATAN dan perhubungan PEKERJA dicipta dengan menyalin kunci utama "Nombor_Jabatan" daripada perhubungan pertama hingga kedua. Oleh itu, untuk mendapatkan senarai pekerja jabatan tertentu, adalah perlu: 1) Dari jadual JABATAN, tetapkan nilai atribut "Nombor_Jabatan" , sepadan dengan "Nama_Jabatan" ini. 2) pilih semua rekod daripada jadual PEKERJA, nilai atribut "Nombor_Jabatan" yang sama dengan yang diperoleh pada langkah sebelumnya. Untuk mengetahui di jabatan mana pekerja bekerja, anda perlu melakukan operasi terbalik: 1) Tentukan "Nombor_Jabatan" daripada jadual PEKERJA. 2) Menggunakan nilai yang diperolehi, kita dapati entri dalam jadual JABATAN.

18. Normalisasi dalam pangkalan data hubungan, konsep bentuk normal dalam reka bentuk pangkalan data.

Bentuk biasa - sifat perhubungan dalam model data hubungan, mencirikannya dari sudut pandangan redundansi, yang berpotensi membawa kepada keputusan persampelan atau perubahan data yang salah secara logik. Bentuk normal ditakrifkan sebagai satu set keperluan yang mesti dipenuhi oleh hubungan.

Proses menukar pangkalan data kepada bentuk biasa dipanggil normalisasi . Normalisasi bertujuan untuk membawa struktur pangkalan data kepada bentuk yang memberikan redundansi minimum, iaitu normalisasi tidak bertujuan untuk mengurangkan atau meningkatkan produktiviti kerja atau mengurangkan atau meningkatkan volum pangkalan data. Matlamat utama normalisasi adalah untuk mengurangkan potensi ketidakkonsistenan maklumat yang disimpan dalam pangkalan data.

Penghapusan redundansi dijalankan, sebagai peraturan, dengan menguraikan hubungan sedemikian rupa sehingga hanya fakta utama disimpan dalam setiap hubungan (iaitu, fakta yang tidak disimpulkan daripada fakta tersimpan lain).

Kebergantungan fungsional.

Pangkalan data hubungan mengandungi maklumat struktur dan semantik. Struktur pangkalan data ditentukan oleh bilangan dan jenis perhubungan yang terkandung di dalamnya, dan perhubungan satu-ke-banyak yang wujud antara tupel perhubungan ini. Bahagian semantik menerangkan set kebergantungan fungsi yang wujud antara atribut perhubungan ini. Mari kita tentukan pergantungan fungsi.

19. 1NF: Takrif asas dan peraturan transformasi.

Untuk membincangkan bentuk normal pertama, dua definisi diperlukan:

Atribut ringkas - atribut yang nilainya adalah atom (tidak boleh dibahagikan).

Atribut kompleks - diperoleh dengan menyambungkan beberapa atribut atom yang boleh ditakrifkan pada domain yang sama atau berbeza (ia juga dipanggil vektor atau agregat data).

Takrif bentuk normal pertama:

hubungan berada dalam 1NF jika nilai semua atributnya adalah atom. . Jika tidak, ia bukan jadual sama sekali dan atribut tersebut mesti diuraikan.

Mari lihat contoh:

Dalam pangkalan data jabatan HR perusahaan, adalah perlu untuk menyimpan maklumat tentang pekerja yang boleh cuba dibentangkan berhubung dengan

PEKERJA(NOMBOR_PEKERJA, NAMA, TARIKH LAHIR, SEJARAH_KERJA, KANAK-KANAK).

Daripada pertimbangan yang teliti terhadap hubungan ini, ia berikutan bahawa sifat-sifat "sejarah kerja" Dan "kanak-kanak" adalah kompleks, lebih-lebih lagi, atribut "sejarah kerja" termasuk satu lagi atribut kompleks "sejarah_gaji".
Unit-unit ini kelihatan seperti ini:

 JOB_HISTORY (TARIKH_RESEPTION, NAMA, GAJI_SEJARAH),

 GAJI_SEJARAH (TARIKH_LANTIKAN, GAJI),

 KANAK-KANAK (ANAK_NAMA, BIRTH_YEAR).

Sambungan mereka ditunjukkan dalam Rajah. 3.3.

Rajah.3.3. Sikap awal.

Untuk membawa SERVANT hubungan asal kepada bentuk normal yang pertama, adalah perlu untuk menguraikannya kepada empat hubungan, kerana ini ditunjukkan dalam rajah berikut:

Rajah.3.4. Set perhubungan yang dinormalisasi.

Di sini, kunci utama setiap perhubungan diserlahkan dengan bingkai biru, nama kunci asing adalah dalam fon biru. Ingat bahawa kunci asing digunakan untuk mewakili kebergantungan fungsi yang wujud dalam hubungan sumber. Kebergantungan fungsi ini ditunjukkan oleh garisan dengan anak panah.

Algoritma normalisasi diterangkan oleh E.F. Codd seperti berikut:

• Bermula dengan hubungan di bahagian atas pokok (Rajah 3.3.), kunci utamanya diambil, dan setiap hubungan bawahan serta-merta dikembangkan dengan memasukkan domain atau gabungan domain kunci primer itu.
• Kunci Utama bagi setiap perhubungan yang dikembangkan dengan cara ini terdiri daripada Kunci Utama yang terdapat pada perhubungan sebelum sambungan dan Kunci Utama tambahan perhubungan induk.
• Selepas ini, semua domain bukan mudah dipadamkan daripada perhubungan induk, nod atas pokok dialih keluar, dan prosedur yang sama diulang untuk setiap subpokok yang tinggal.

20. 2NF: Takrif asas dan peraturan transformasi.

Selalunya kunci utama perhubungan termasuk beberapa atribut (dalam hal ini ia dipanggil komposit) - lihat, sebagai contoh, hubungan KANAK-KANAK yang ditunjukkan dalam Rajah. 3.4 soalan 19. Pada masa yang sama, konsep ini diperkenalkan pergantungan fungsi penuh.

Definisi:

atribut bukan kunci secara fungsional bergantung sepenuhnya pada kunci komposit jika ia bergantung secara fungsional pada keseluruhan kunci secara keseluruhan, tetapi tidak bergantung secara fungsional pada mana-mana atribut konstituennya.

Contoh:

Biarkan ada hubungan SUPPLY (N_SUPPLIER, PRODUCT, PRICE).
Pembekal mungkin membekalkan produk yang berbeza, dan produk yang sama mungkin dibekalkan oleh pembekal yang berbeza. Maka kunci perhubungan ialah "N_pembekal + produk". Biarkan semua pembekal membekalkan barangan pada harga yang sama. Kemudian kita mempunyai kebergantungan fungsi berikut:

• N_pembekal, produk -> harga
• produk -> harga

Kebergantungan fungsi atribut harga yang tidak lengkap pada kunci membawa kepada anomali berikut: apabila harga item berubah, paparan penuh perhubungan diperlukan untuk menukar semua rekod tentang pembekalnya. Anomali ini adalah akibat daripada fakta bahawa dua fakta semantik digabungkan dalam satu struktur data. Peluasan berikut memberikan hubungan dalam 2NF:

• PENGHANTARAN (N_SUPPLIER, PRODUCT)
• PRODUCT_PRICE (PRODUCT, PRICE)

Jadi anda boleh memberi

Takrif bentuk normal kedua: Sesuatu hubungan berada dalam 2NF jika ia berada dalam 1NF dan setiap atribut bukan kunci bergantung sepenuhnya pada kunci tersebut.

21. 3NF: Takrif asas dan peraturan transformasi.

Sebelum membincangkan bentuk normal ketiga, adalah perlu untuk memperkenalkan konsep: pergantungan fungsi transitif.

Definisi:

Biarkan X, Y, Z ialah tiga sifat bagi sesuatu hubungan. Dalam kes ini, X --> Y dan Y --> Z, tetapi tiada surat-menyurat terbalik, i.e. Z -/-> Y dan Y -/-> X. Kemudian Z bergantung transitif pada X.
Biar ada hubungan STORAGE ( TEGAS, GUDANG, VOLUME), yang mengandungi maklumat tentang syarikat yang menerima barangan dari gudang dan jumlah gudang ini. Atribut utama - "tegas". Jika setiap syarikat boleh menerima barang dari hanya satu gudang, maka dalam hal ini terdapat kebergantungan fungsi berikut:

• tegas -> stok
• stok -> isipadu

Dalam kes ini, anomali timbul:

• jika pada masa ini tiada syarikat menerima barang dari gudang, maka data pada volumnya tidak boleh dimasukkan ke dalam pangkalan data (kerana atribut utama tidak ditentukan)
• jika volum gudang berubah, adalah perlu untuk melihat keseluruhan perhubungan dan menukar kad untuk semua syarikat yang dikaitkan dengan gudang ini.

Untuk menghapuskan anomali ini, adalah perlu untuk menguraikan hubungan asal kepada dua:

• PENYIMPANAN ( TEGAS, STOK)
• STORAGE_VOLUME ( STOK, JILID)

Takrif bentuk normal ketiga:

Perhubungan berada dalam 3NF jika ia berada dalam 2NF dan setiap atribut bukan kunci tidak bergantung secara transitif pada kunci primer.

Ini adalah repositori elektronik maklumat yang diakses menggunakan satu atau lebih komputer. Biasanya, pangkalan data dicipta untuk menyimpan dan mengakses data yang mengandungi maklumat tentang kawasan subjek tertentu, iaitu, beberapa kawasan aktiviti manusia atau sebahagian daripada dunia nyata.

DBMS ialah alat perisian untuk mencipta, mengisi, mengemas kini dan memadam pangkalan data.

Unit maklumat yang disimpan dalam pangkalan data ialah jadual. Setiap jadual ialah koleksi baris dan lajur, di mana baris sepadan dengan kejadian objek, peristiwa atau fenomena tertentu, dan lajur sepadan dengan atribut (ciri, ciri, parameter) objek, peristiwa atau fenomena. Setiap baris mengandungi maklumat tentang acara tertentu.

Dalam istilah pangkalan data, lajur jadual dipanggil medan, dan barisnya dipanggil rekod.

Hubungan mungkin wujud antara jadual pangkalan data individu, iaitu, maklumat dalam jadual sebelumnya boleh ditambah kepada satu lagi. Pangkalan data yang mempunyai hubungan antara jadual individu dipanggil hubungan. Jadual yang sama boleh menjadi jadual utama berhubung dengan satu jadual pangkalan data dan jadual anak berhubung dengan yang lain.

Jadual yang disambungkan oleh hubungan berinteraksi mengikut prinsip tuan-hamba. Jadual yang sama boleh menjadi jadual utama satu jadual pangkalan data dan anak kepada yang lain.

Sebuah objek – adalah sesuatu yang sedia ada dan boleh dibezakan, memiliki satu set sifat. Perbezaan antara satu objek dengan objek lain ditentukan oleh nilai sifat tertentu.

Intipati – pantulan objek dalam ingatan seseorang atau komputer.

Atribut – nilai khusus mana-mana sifat entiti.

Padang ialah satu elemen rekod yang menyimpan nilai atribut tertentu.

Bidang komunikasi – Ini ialah medan yang menghubungkan dua jadual.

Kekunci primer dan sekunder

Setiap jadual pangkalan data boleh mempunyai kunci utama - ini adalah medan atau koleksi medan yang mengenal pasti rekod secara unik.

Nilai kunci utama dalam jadual pangkalan data mestilah unik, iaitu, tidak boleh ada dua atau lebih rekod dalam jadual dengan nilai kunci utama yang sama.

Kekunci utama menjadikannya lebih mudah untuk mewujudkan hubungan antara jadual. Oleh kerana kunci utama mestilah unik, tidak semua medan dalam jadual boleh digunakan untuknya.

Jika jadual tidak mempunyai medan yang nilainya unik, untuk mencipta kunci utama, medan berangka tambahan biasanya dimasukkan ke dalamnya, nilai yang boleh dilupuskan oleh DBMS mengikut budi bicaranya.

Kekunci sekunder ditetapkan oleh medan yang sering digunakan semasa mencari atau mengisih data: indeks yang dibina pada kekunci sekunder akan membantu sistem mencari nilai yang diperlukan yang disimpan dalam medan yang sepadan dengan lebih cepat.

Tidak seperti kunci primer, medan untuk kunci sekunder boleh mengandungi maklumat bukan unik.

Hubungan perkaitan antara jadual

Satu lawan satu. Perhubungan satu dengan satu berlaku apabila satu rekod dalam jadual induk sepadan dengan satu rekod dalam jadual anak.

Hubungan ini adalah kurang biasa daripada hubungan satu-ke-banyak; ia digunakan jika anda tidak mahu jadual pangkalan data membengkak dengan jadual sekunder. Perhubungan satu dengan satu bermakna membaca maklumat berkaitan dalam berbilang jadual memerlukan berbilang operasi baca, yang melambatkan pengambilan semula maklumat yang diperlukan. Selain itu, pangkalan data yang mengandungi jadual dengan perhubungan satu dengan satu tidak boleh dianggap dinormalisasi sepenuhnya.

Seperti hubungan satu dengan ramai, hubungan satu dengan satu boleh menjadi sama ada keras atau lembut.

Meja

Dalam pangkalan data hubungan, maklumat disusun ke dalam jadual hubungan, dibahagikan kepada baris dan lajur, di persimpangan yang mana nilai data terkandung.

Jadual - ini ialah beberapa struktur biasa yang terdiri daripada set rekod terhingga daripada jenis yang sama.

Jadual mencerminkan jenis objek dunia sebenar (entiti). Baris sepadan dengan kejadian objek, peristiwa atau fenomena tertentu. Lajur sepadan dengan atribut (ciri, ciri, parameter) objek, peristiwa, fenomena. Setiap jadual mempunyai nama unik dalam pangkalan data yang menerangkan kandungannya.

Setiap lajur dalam jadual mempunyai nama, yang biasanya berfungsi sebagai tajuk lajur. Semua lajur dalam jadual yang sama mesti mempunyai nama unik, tetapi anda dibenarkan memberikan nama yang sama kepada lajur dalam jadual yang berbeza. Dalam model data relasi, atribut perhubungan tidak disusun, iaitu medan sentiasa diakses mengikut nama dan bukan mengikut lokasi. Walau bagaimanapun, SQL membenarkan pengindeksan lajur jadual, dan lajur dipertimbangkan mengikut tertib dari kiri ke kanan (urutan mereka ditentukan apabila jadual dibuat).

Mana-mana jadual sentiasa mempunyai sekurang-kurangnya 1 lajur. Standard ANSI/ISO tidak menyatakan bilangan maksimum lajur setiap jadual, tetapi hampir semua DBMS komersial mempunyai had. Dalam Firebird, had ini ialah 32,767 lajur.

Dalam model data hubungan RMD, konsep tuple digunakan untuk menandakan baris hubungan. Perwakilan lapisan fizikal tuple ialah baris dalam jadual pangkalan data. Baris jadual tidak mempunyai nama dan tiada susunan tertentu. Jadual boleh mengandungi sebarang bilangan baris. Ia boleh diterima dengan sempurna untuk mempunyai jadual dengan baris sifar. Jadual sedemikian dipanggil kosong. Jadual kosong mengekalkan struktur yang ditakrifkan oleh lajurnya; ia hanya tidak mengandungi data. Sebagai peraturan, tiada sekatan pada bilangan baris dalam jadual, dan dalam kebanyakan DBMS saiz jadual hanya dihadkan oleh ruang cakera kosong komputer. DBMS lain mempunyai had maksimum, tetapi ia agak tinggi - kira-kira dua bilion baris, dan kadangkala lebih.

Marilah kita menggambarkan dengan lebih jelas struktur salah satu jadual dalam pangkalan data latihan (lihat Lampiran A). Dalam Rajah. 1.1 menunjukkan struktur jadual Abonent, yang mengandungi maklumat tentang pelanggan syarikat perumahan dan perkhidmatan komunal.

nasi. 1.1. Struktur jadual hubungan Abonent

Setiap baris mendatar jadual ini mewakili entiti fizikal yang berasingan - satu pelanggan. Dua belas baris jadual bersama-sama mewakili semua pelanggan. Semua data yang terkandung dalam baris tertentu jadual mewakili satu set nilai atribut untuk pelanggan tertentu, yang diterangkan oleh baris ini.

Setiap lajur menegak jadual mewakili koleksi nilai untuk atribut tertentu objek. Contohnya, lajur AccountCD mengandungi nombor akaun pelanggan unik. Lajur Telefon mengandungi nombor telefon pelanggan.

Persilangan setiap baris dengan setiap lajur jadual mengandungi tepat satu nilai data. Contohnya, dalam baris yang mewakili pelanggan V.S. Konyukhov, lajur Fio mengandungi nilai "V.S. Konyukhov." Lajur AccountCD pada baris yang sama mengandungi nilai "015527", iaitu nombor akaun peribadi pelanggan dengan nama penuh V. S. Konyukhov.

Semua nilai yang terkandung dalam lajur yang sama adalah jenis data yang sama. Contohnya, lajur Fio hanya mengandungi perkataan, manakala lajur StreetCD mengandungi integer yang mewakili ID jalan. Dalam model data hubungan, jumlah set nilai dari mana nilai sebenar untuk atribut tertentu (lajur) diambil dipanggil domain. Domain lajur Fio, sebagai contoh, ialah satu set nama keluarga, nama pertama dan patronim (nama penuh) pelanggan. Setiap lajur sentiasa ditakrifkan pada satu domain.

Dalam pangkalan data hubungan, domain ditakrifkan dengan menentukan sekurang-kurangnya beberapa jenis data asas yang mana elemen domain dimiliki, dan selalunya juga ungkapan Boolean sewenang-wenangnya digunakan pada elemen jenis data tersebut (kekangan domain).

Domain berikut ditakrifkan dalam pangkalan data latihan:

§ Boolean: KECIL. Medan yang ditakrifkan dalam domain ini hanya boleh menerima nilai integer sama dengan 0 atau 1. Ini dicapai dengan mengenakan syarat semakan (CHECK) dalam domain pada nilai yang diterima oleh domain ini.

§ Wang: NUMERIC(15,2). Domain ini bertujuan untuk menentukan medan dalam jadual yang menyimpan jumlah kewangan.

§ PKField: INTEGER. Domain digunakan untuk menentukan kunci utama dan kunci asing bagi jadual. Tiada keperluan data wajib (BUKAN NULL) untuk domain ini. Ia dikenakan apabila mengisytiharkan kunci utama jadual. Ini dilakukan supaya kunci asing boleh ditakrifkan pada domain ini tanpa syarat NOT NULL.

§ TBulan (Bulan): KECIL. Domain ini bertujuan untuk menentukan medan dalam jadual yang mengandungi nombor bulan. Nilai integer dalam medan sedemikian boleh berada dalam julat 1...12.

§ TYear (Tahun): SMALLINT. Domain ini bertujuan untuk menentukan medan yang mengandungi nombor tahun. Nilai integer boleh berada dalam julat 1990...2100.

Oleh kerana baris dalam jadual hubungan tidak disusun, anda tidak boleh memilih baris mengikut nombornya dalam jadual. Tiada baris "pertama", "terakhir" atau "ketiga belas" dalam jadual. Kemudian bagaimana anda boleh menunjukkan baris tertentu dalam jadual, sebagai contoh, baris untuk pelanggan dengan nama penuh Aksenov S.A.?

Elemen data utama ialah elemen yang daripadanya nilai elemen data lain boleh ditentukan.

Dalam pangkalan data hubungan, setiap jadual mempunyai 1 atau lebih lajur yang nilainya berbeza dalam setiap baris. Lajur ini dipanggil kunci utama jadual.

Kunci utama - ialah atribut atau kumpulan atribut yang mengenal pasti secara unik setiap baris dalam jadual.

Mari kita kembali melihat jadual Abonent pangkalan data latihan (Rajah 1.1). Pada pandangan pertama, kedua-dua lajur AccountCD dan lajur Fio boleh berfungsi sebagai kunci utama jadual Abonent. Walau bagaimanapun, jika 2 pelanggan dengan nama penuh yang sama didaftarkan, lajur Fio tidak lagi dapat berfungsi sebagai kunci utama. Dalam amalan, pengecam seperti nombor akaun peribadi unik pelanggan (AccountCD dalam jadual Abonent), pengecam jalan (StreetCD dalam jadual Jalan), dsb. biasanya harus dipilih sebagai kunci utama jadual.

Jika jadual tidak mempunyai medan yang nilainya unik, untuk mencipta kunci utama, medan tambahan biasanya dimasukkan ke dalamnya, nilai yang boleh dilupuskan oleh DBMS mengikut budi bicaranya.

Jika kunci utama ialah gabungan lajur, maka kunci primer sedemikian dipanggil komposit.

Kunci Sekunder ditetapkan oleh medan yang sering digunakan semasa mencari atau mengisih data. Tidak seperti kunci utama, medan untuk kunci sekunder boleh mengandungi nilai bukan unik.

Kehadiran hubungan, rujukan silang antara jadual adalah salah satu sifat asas yang membezakan pangkalan data hubungan daripada set jadual ringkas. Untuk melaksanakan perhubungan sedemikian, hampir semua DBMS membenarkan anda menentukan kunci utama dan asing dalam jadual dan mempunyai mekanisme untuk mengekalkan integriti rujukan.

Kunci utama

Kami telah menyentuh secara ringkas tentang konsep kunci utama dalam artikel mengenai normalisasi pangkalan data. Kunci utama ialah lajur atau kumpulan lajur yang mengenal pasti rekod secara unik. Kunci primer adalah mengikut definisi unik: jadual tidak boleh mempunyai dua baris berbeza dengan nilai kunci primer yang sama. Lajur yang membentuk kunci utama tidak boleh NULL. Setiap jadual hanya boleh mempunyai satu kunci utama.

Kunci unik

Kunci unik ialah lajur atau kumpulan lajur yang nilainya (gabungan nilai untuk sekumpulan lajur) tidak boleh diulang. Perbezaan antara kunci unik dan kunci utama ialah:

• Terdapat beberapa kunci unik untuk satu jadual (soalan pantas untuk mereka yang membaca artikel tentang normalisasi: peraturan bentuk biasa manakah yang akan dilanggar? ;)
• kunci unik boleh mempunyai nilai NULL, dan jika terdapat beberapa baris dengan nilai kunci unik NULL, baris tersebut dianggap berbeza (unik) mengikut standard SQL 92.

Kunci luaran

Kunci asing adalah mekanisme utama untuk mengatur hubungan antara jadual dan mengekalkan integriti dan konsistensi maklumat dalam pangkalan data.

Kunci asing ialah lajur atau kumpulan lajur yang merujuk lajur atau kumpulan lajur dalam jadual lain (atau yang sama). Jadual yang dirujuk oleh kunci asing dipanggil jadual induk, dan lajur yang dirujuk oleh kunci asing dipanggil kunci induk. Kunci induk mestilah kunci utama atau unik, tetapi nilai kunci asing boleh diulang beberapa kali. Iaitu, hubungan satu-ke-banyak disokong menggunakan kunci asing. Jenis data (dan dalam beberapa DBMS, dimensi) lajur kunci asing dan induk yang sepadan mesti sepadan.

Dan yang paling penting. Semua nilai kunci asing mesti sepadan dengan salah satu nilai kunci induk. (Perhatikan dalam kurungan tentang padanan/ketakpadanan: nuansa timbul apabila NULL ditemui dalam nilai lajur kunci sekunder. Jangan pergi ke nuansa ini buat masa ini). Nilai kunci asing yang tidak mempunyai nilai kunci induk yang sepadan tidak dibenarkan. Di sinilah kita dengan lancar beralih kepada konsep integriti rujukan.

Integriti rujukan

Peraturan pertama integriti rujukan sebenarnya telah dinyatakan dalam perenggan sebelumnya: baris tidak dibenarkan muncul dalam jadual (tidak kira semasa menambah atau mengubah suai) kunci asing yang tidak sepadan dengan mana-mana nilai sedia ada kunci ibu bapa.

Detik yang lebih menarik timbul apabila kami memadam atau menukar baris jadual induk. Bagaimana untuk mengelakkan penampilan baris \"terjuntai di udara\" meja kanak-kanak? Untuk tujuan ini, terdapat peraturan integriti rujukan ON UPDATE dan ON DELETE, yang, menurut standard SQL 92, boleh mengandungi pernyataan berikut:

• CASCADE - memastikan bahawa perubahan yang sama yang dibuat dalam kunci induk dilakukan secara automatik dalam jadual anak. Jika kunci induk telah ditukar - ON UPDATE CASCADE akan memastikan perubahan kunci asing yang sama dalam jadual anak. Jika satu baris dalam jadual induk telah dipadamkan, ON DELETE CASCADE akan memastikan bahawa semua baris yang sepadan dalam jadual anak dipadamkan.
• SET NULL - Apabila memadamkan baris dalam jadual induk, ON DELETE SET NULL akan menetapkan semua lajur kunci sekunder dalam baris yang sepadan dalam jadual anak kepada NULL. Apabila menukar kunci induk, ON UPDATE SET NULL akan menetapkan lajur yang sepadan bagi baris yang sepadan (oh bagaimana:) jadual anak kepada NULL.
• SET DEFAULT - berfungsi sama dengan SET NULL, hanya ia menulis nilai lalai ke sel yang sepadan dan bukannya NULL.
• TIADA TINDAKAN (ditetapkan secara lalai) - apabila kunci induk berubah, tiada tindakan diambil pada kunci asing dalam jadual anak. Tetapi jika menukar nilai kunci induk membawa kepada pelanggaran integriti rujukan (iaitu, penampilan baris jadual anak "bergantung di udara"), maka DBMS tidak akan membenarkan perubahan sedemikian dibuat ke meja induk.

Nah, sekarang - dari umum kepada khusus.

Kunci dan integriti rujukan dalam MySQL dan Oracle

Oracle menyokong kunci utama, unik, asing sepenuhnya. Oracle menyokong peraturan integriti rujukan berikut:

• TIADA TINDAKAN (ditetapkan secara lalai) dalam versi yang lebih ketat daripada standard SQL 92: menukar dan memadam baris jadual induk yang mempunyai baris berkaitan dalam jadual anak adalah dilarang.
• PADA DELETE CASCADE.

Peraturan integriti rujukan yang lebih kompleks dalam Oracle boleh dilaksanakan melalui mekanisme pencetus.

MySQL versi 4.1 (versi stabil terkini pada masa penulisan) membolehkan anda menentukan frasa RUJUKAN / UTAMA ASING dalam arahan CREATE / ALTER TABLE, tetapi tidak mengambil kira dalam apa cara sekalipun dan sebenarnya tidak mencipta kunci asing. Sehubungan itu, peraturan integriti rujukan yang dilaksanakan melalui kunci asing tidak disokong dalam MySQL. Dan semua kebimbangan mengenai memastikan integriti dan konsistensi maklumat dalam pangkalan data MySQL jatuh ke atas bahu pembangun aplikasi klien.

Pembangun MySQL berjanji untuk melaksanakan kerja dengan kunci asing dan mengekalkan integriti rujukan dalam versi 5.0. Nah, apabila versi MySQL 5.0 menjadi stabil, kita akan melihat apa yang berlaku di sana pada akhirnya. Saya sangat, sangat suka MySQL untuk menyokong integriti rujukan (tanpa mengorbankan prestasi :).

• Terjemahan

Saya menyiarkan sambungan terjemahan siri artikel untuk pemula.
Ini dan yang seterusnya mengandungi lebih banyak maklumat tentang merit.
Mulakan - .

4. JADUAL DAN KUNCI UTAMA

Seperti yang anda sedia maklum dari bahagian sebelumnya, data disimpan dalam meja, yang mengandungi garisan atau dengan cara lain rekod. Terdahulu saya telah memberikan contoh jadual yang mengandungi maklumat tentang pelajaran. Mari kita lihat semula.

Terdapat 6 pelajaran dalam jadual. Kesemua 6 adalah berbeza, tetapi untuk setiap pelajaran nilai medan yang sama disimpan dalam jadual, iaitu: tutorial_id (pengecam pelajaran), tajuk (tajuk) dan kategori (kategori). Tutorial_id – kunci utama jadual pelajaran. Kunci utama ialah nilai yang unik untuk setiap rekod dalam jadual.
Dalam jadual pelanggan di bawah, customer_id ialah kunci utama. Dalam kes ini, kunci utama juga merupakan nilai unik (nombor) untuk setiap rekod.

Kunci utama dalam kehidupan seharian

Dalam pangkalan data, kunci utama digunakan untuk pengenalan. Dalam kehidupan, kunci utama ada di mana-mana di sekeliling kita. Pada bila-bila masa anda menemui nombor unik, nombor itu boleh berfungsi sebagai kunci utama dalam pangkalan data (boleh, tetapi tidak semestinya perlu, digunakan seperti itu. Semua pangkalan data mampu menjana nilai unik secara automatik untuk setiap rekod sebagai nombor yang ditambah dan dimasukkan secara automatik bersama setiap rekod baharu [Kunci utama yang dipanggil sintetik atau pengganti – lebih kurang terjemahan]).

Beberapa contoh

• Nombor pesanan yang anda terima semasa membeli di kedai dalam talian boleh menjadi kunci utama beberapa jadual pesanan dalam pangkalan data kedai ini, kerana ia adalah nilai yang unik.
• Nombor keselamatan sosial boleh menjadi kunci utama dalam sesetengah jadual dalam pangkalan data kerajaan kerana... ia juga unik, seperti dalam contoh sebelumnya.
• Nombor invois boleh digunakan sebagai kunci utama dalam jadual pangkalan data yang menyimpan invois yang dikeluarkan kepada pelanggan.
• Nombor pelanggan berangka sering digunakan sebagai kunci utama dalam jadual pelanggan.

Apakah persamaan contoh ini? Hakikat bahawa dalam kesemuanya nilai unik dan tidak berulang untuk setiap rekod dipilih sebagai kunci utama. sekali lagi. Nilai medan jadual pangkalan data yang dipilih sebagai kunci utama sentiasa unik.

Apakah ciri kunci utama? Ciri-ciri kunci utama.

Kunci utama digunakan untuk mengenal pasti rekod.

Kunci utama digunakan untuk pengenalan rekod dalam jadual, supaya setiap rekod menjadi unik. Analogi lain... Apabila anda menghubungi sokongan teknikal, pengendali biasanya meminta anda memberikan beberapa nombor (kontrak, telefon, dll.) yang membolehkan anda dikenal pasti dalam sistem.
Jika anda terlupa nombor anda, pengendali sokongan teknikal akan meminta anda memberikan beberapa maklumat lain yang akan membantu mengenal pasti anda secara unik. Contohnya, gabungan hari lahir dan nama keluarga anda. Mereka juga boleh menjadi kunci utama, atau lebih tepatnya gabungan mereka.

Kunci utama adalah unik.

Kunci utama sentiasa mempunyai nilai unik. Bayangkan maknanya tidak unik. Kemudian ia tidak boleh digunakan untuk mengenal pasti data dalam jadual. Ini bermakna bahawa sebarang nilai kunci utama boleh muncul sekali sahaja dalam lajur yang dipilih sebagai kunci utama. RDBMS direka bentuk sedemikian rupa sehingga ia tidak membenarkan anda memasukkan pendua ke dalam medan kunci utama, anda akan mendapat ralat.
Satu lagi contoh. Bayangkan anda mempunyai jadual dengan medan first_name dan last_name dan terdapat dua rekod:

| nama_pertama | nama belakang |
| vasya |pupkin |
| vasya |pupkin |

Itu. terdapat dua Vasya. Anda ingin memilih Vasya tertentu dari jadual. Bagaimana hendak melakukannya? Entri tidak berbeza antara satu sama lain. Di sinilah kunci utama membantu. Tambahkan lajur id (versi klasik kunci utama sintetik) dan...

Id | nama_pertama | nama belakang |
1 | vasya |pupkin |
2 | vasya |pupkin |

Kini setiap Vasya adalah unik.

Jenis kunci utama.

Biasanya kunci utama ialah nilai angka. Tetapi ia juga boleh menjadi mana-mana jenis data lain. Ia bukan amalan biasa untuk menggunakan rentetan sebagai kunci utama (rentetan ialah sekeping teks), tetapi secara teori dan praktikal mungkin.
Kekunci utama komposit.
Selalunya kunci utama terdiri daripada satu medan, tetapi ia juga boleh menjadi gabungan beberapa lajur, contohnya dua (tiga, empat...). Tetapi anda ingat bahawa kunci utama sentiasa unik, yang bermaksud gabungan nombor ke-n medan, dalam kes 2 ini, mestilah unik. Saya akan memberitahu anda lebih lanjut mengenai perkara ini kemudian.

Penomboran automatik.

Medan kunci utama selalunya, tetapi tidak selalu, diproses oleh pangkalan data itu sendiri. Anda pada asasnya boleh memberitahu pangkalan data untuk memberikan nilai angka unik secara automatik kepada setiap rekod apabila ia dibuat. Pangkalan data biasanya mula bernombor pada 1 dan menambah nombor ini sebanyak satu untuk setiap rekod. Kunci utama sedemikian dipanggil auto-incrementing atau auto-numbering. Menggunakan kunci penambahan automatik ialah cara yang baik untuk menentukan kunci utama yang unik. Nama klasik untuk kunci sedemikian ialah kunci utama pengganti [Seperti yang dinyatakan di atas. – lebih kurang. terjemah]. Kunci sedemikian tidak mengandungi maklumat berguna yang berkaitan dengan entiti (objek), maklumat tentang yang disimpan dalam jadual, itulah sebabnya ia dipanggil pengganti.

5. MEMAUTKAN MEJA MENGGUNAKAN KUNCI ASING

Apabila saya mula membangunkan pangkalan data, saya sering cuba menyimpan maklumat yang kelihatan berkaitan dalam satu jadual. Saya boleh, sebagai contoh, menyimpan maklumat pesanan dalam jadual pelanggan. Lagipun tempahan milik pelanggan kan? Tidak. Pelanggan dan pesanan adalah entiti yang berasingan dalam pangkalan data. Kedua-duanya memerlukan meja mereka sendiri. Dan rekod dalam kedua-dua jadual ini boleh dikaitkan untuk mewujudkan hubungan antara mereka. Reka bentuk pangkalan data ialah penyelesaian kepada dua isu:

• menentukan entiti yang ingin anda simpan di dalamnya
• apakah hubungan yang wujud antara entiti ini?

Satu-ke-banyak.

Pelanggan dan pesanan mempunyai hubungan (berhubungan) satu-ke-banyak kerana satu klien mungkin ada banyak pesanan, tetapi setiap pesanan tertentu (mereka sekumpulan) dikeluarkan sahaja satu pelanggan, i.e. hanya boleh mempunyai seorang pelanggan. Jangan risau jika pemahaman anda tentang sambungan ini tidak jelas pada ketika ini. Saya akan bercakap lebih lanjut mengenai sambungan di bahagian akan datang.

Satu perkara yang penting sekarang ialah untuk komunikasi satu-ke-banyak adalah perlu dua meja berasingan. Satu untuk pelanggan, satu lagi untuk pesanan. Mari kita berlatih membuat dua jadual ini.

Apakah maklumat yang akan kami simpan? Mari kita selesaikan soalan pertama.

Sebagai permulaan, kami akan memutuskan maklumat mengenainya pesanan dan tentang pelanggan kami akan simpan. Untuk melakukan ini, kita mesti bertanya kepada diri sendiri soalan: "Apakah unit maklumat yang berkaitan dengan pelanggan, dan apakah unit maklumat yang berkaitan dengan pesanan?"

Mereka bentuk meja pelanggan.

Pesanan benar-benar milik pelanggan, tetapi pesanan itu tidak blok maklumat minimum, yang berkaitan dengan pelanggan (iaitu blok ini boleh dibahagikan kepada yang lebih kecil: tarikh pesanan, alamat penghantaran pesanan, dll., contohnya).
Medan di bawah ialah butiran minimum maklumat yang digunakan untuk pelanggan:

• id_pelanggan (kunci utama) – pengecam pelanggan
• nama_pertama - nama
• nama akhir - nama tengah
• alamat - alamat
• zip_code – poskod
• negara - negara
• tarikh_lahir – tarikh lahir
• nama pengguna – nama pendaftaran pengguna (log masuk)
• kata laluan – kata laluan

Mari kita teruskan untuk mencipta jadual ini secara langsung dalam SQLyog (sudah tentu, anda boleh menggunakan mana-mana program lain). Di bawah ialah contoh jadual yang mungkin kelihatan dalam SQLyog setelah dibuat. Semua aplikasi pengurusan pangkalan data grafik mempunyai struktur antara muka yang lebih kurang sama. Anda juga boleh membuat jadual menggunakan baris arahan tanpa menggunakan utiliti grafik.

Mencipta jadual dalam SQLyog. Perhatikan bahawa kotak semak kunci utama (PK) untuk medan customer_id dipilih. Medan customer_id ialah kunci utama. Kotak semak Auto Incr juga dipilih, yang bermaksud bahawa pangkalan data akan secara automatik memasukkan nilai angka unik yang, bermula pada sifar, akan meningkat satu setiap kali.

Mereka bentuk jadual pesanan.
Apakah maklumat minimum yang kami perlukan untuk pesanan?

• order_id (kunci utama) – pengecam pesanan
• tarikh_pesanan – tarikh dan masa pesanan
• pelanggan – pelanggan yang membuat pesanan

Di bawah ialah contoh jadual dalam SQLyog.

Kedua-dua jadual ini ( pelanggan Dan pesanan) disambungkan kerana medan pelanggan dalam jadual pesanan merujuk kepada kunci utama ( ID pelanggan) meja pelanggan. Sambungan ini dipanggil hubungan utama asing. Anda harus menganggap kunci asing sebagai salinan ringkas (salinan nilai) kunci utama jadual lain. Dalam kes kami, nilai medan ID pelanggan daripada meja pelanggan disalin ke jadual pesanan setiap kali rekod dimasukkan. Oleh itu, dengan kami, setiap pesanan dipautkan kepada pelanggan. Dan setiap pelanggan boleh mempunyai banyak pesanan, seperti yang dinyatakan di atas.

Mewujudkan hubungan utama asing.

Anda mungkin tertanya-tanya, "Bagaimana saya boleh memastikan atau bagaimana saya boleh melihat bahawa medan pelanggan dalam jadual pesanan merujuk kepada medan customer_id dalam jadual pelanggan." Jawapannya mudah - anda tidak boleh melakukan ini kerana saya belum menunjukkan kepada anda cara membuat sambungan.
Di bawah ialah tetingkap SQLyog dengan tetingkap yang saya gunakan untuk mencipta hubungan antara jadual.

Mewujudkan hubungan utama asing antara pesanan dan jadual pelanggan.

Dalam tetingkap di atas, anda boleh melihat cara medan pelanggan jadual pesanan di sebelah kiri dipautkan kepada kunci utama (customer_id) jadual pelanggan di sebelah kanan.

Sekarang apabila anda melihat data yang mungkin ada dalam jadual, anda akan melihat bahawa kedua-dua jadual adalah berkaitan.

Pesanan dikaitkan dengan pelanggan melalui medan pelanggan, yang merujuk kepada jadual pelanggan.

Dalam imej anda boleh melihat bahawa pelanggan mary membuat tiga pesanan, pelanggan pablo meletakkan satu, dan pelanggan john- tiada sesiapa.
Anda mungkin bertanya: “A Apa Adakah itu yang diperintahkan oleh semua orang ini?” Itu soalan yang bagus. Anda mungkin menjangkakan untuk melihat item yang dipesan dalam jadual pesanan. Tetapi ini adalah contoh reka bentuk yang tidak baik. Bagaimanakah anda memasukkan beberapa produk ke dalam satu entri? barang ialah entiti berasingan yang mesti disimpan dalam jadual berasingan. Dan hubungan antara jadual pesanan Dan barang akan menjadi hubungan satu-dengan-banyak. Saya akan bercakap tentang ini lebih lanjut.

6. BUAT GAMBARAJAH HUBUNGAN ENTITI

Sebelum ini, anda telah mempelajari cara rekod daripada jadual berbeza dipautkan antara satu sama lain dalam pangkalan data hubungan. Sebelum membuat dan memautkan jadual, adalah penting untuk anda fikirkan entiti yang wujud pada sistem anda (yang mana anda mencipta pangkalan data) dan tentukan bagaimana entiti ini dihubungi bersama-sama. Dalam reka bentuk pangkalan data, entiti dan perhubungannya biasanya disediakan dalam gambar rajah perhubungan entiti (ERD). Gambar rajah ini adalah hasil daripada proses reka bentuk pangkalan data.

Entiti.

Anda mungkin tertanya-tanya apa itu entiti. Nah... ia adalah "perkara" dalam sistem. di sana. Ibu saya sentiasa mahu saya menjadi seorang guru kerana saya sangat pandai menerangkan sesuatu.

Dalam konteks reka bentuk pangkalan data intipati adalah sesuatu yang patut jadual anda sendiri dalam model pangkalan data anda. Apabila anda mereka bentuk pangkalan data, anda mesti menentukannya intipati pada sistem yang anda cipta pangkalan data. Ia lebih kepada soal dialog dengan pelanggan atau dengan diri anda sendiri untuk mengetahui data yang sistem anda akan berfungsi.

Mari kita ambil kedai dalam talian sebagai contoh. Kedai dalam talian menjual barang. produk boleh menjadi entiti yang jelas dalam sistem kedai dalam talian. barang sedang diperintahkanpelanggan. Jadi anda dan saya melihat dua entiti yang lebih jelas: pesanan Dan pelanggan.

Tempahan dibayar oleh pelanggan... ini menarik. Adakah kami akan membuat jadual berasingan untuk pembayaran dalam pangkalan data kedai dalam talian kami? Mungkin. Tetapi adakah pembayaran benar-benar maklumat minimum yang berkaitan dengan pesanan? Ini juga mungkin.

Jika anda tidak pasti, cuma fikirkan tentang maklumat pembayaran yang ingin anda simpan. Anda mungkin mahu menyimpan kaedah pembayaran atau tarikh pembayaran. Tetapi ini masih merupakan maklumat minimum yang boleh dikaitkan pesanan. Anda boleh menukar perkataan. Kaedah pembayaran - kaedah pembayaran untuk pesanan. Tarikh pembayaran - tarikh pembayaran pesanan. Jadi saya tidak nampak keperluan untuk bertahan pembayaran ke dalam jadual yang berasingan, walaupun secara konseptual anda boleh membezakan pembayaran sebagai entiti, kerana anda boleh menganggap pembayaran sebagai wadah maklumat (kaedah pembayaran, tarikh pembayaran).

Jangan terlalu akademik.

Seperti yang anda lihat, terdapat perbezaan antara entiti dan jadual itu sendiri dalam pangkalan data, i.e. ia bukan perkara yang sama. Profesional industri IT boleh menjadi SANGAT akademik dan pedantik tentang perkara ini. Saya bukan pakar seperti itu. Perbezaan ini bergantung pada sudut pandangan anda pada data anda, maklumat anda. Jika anda melihat pemodelan data dari perspektif perisian, anda mungkin mempunyai banyak entiti yang tidak boleh dipindahkan terus ke pangkalan data. Dalam tutorial ini, kami melihat data secara ketat dari perspektif pangkalan data, dan dalam dunia kecil kami, entiti itu ialah jadual.

Tunggu di sana, anda benar-benar hampir untuk mendapatkan ijazah pangkalan data anda.

Seperti yang anda lihat, menentukan entiti yang ada pada sistem anda adalah sedikit proses intelektual yang memerlukan sedikit pengalaman dan sering menjadi subjek untuk perubahan, semakan, refleksi, tetapi sudah tentu ia bukan sains roket.

Gambar rajah perhubungan entiti boleh menjadi agak besar jika anda sedang mengusahakan aplikasi yang kompleks. Sesetengah carta mungkin mengandungi ratusan atau bahkan ribuan jadual.

Sambungan

Langkah kedua dalam reka bentuk pangkalan data ialah memilih perhubungan yang wujud antara entiti dalam sistem anda. Ini mungkin agak sukar untuk difahami sekarang, tetapi sekali lagi, ia bukan sains roket. Dengan sedikit pengalaman dan memikirkan semula kerja yang dilakukan, anda akan melengkapkan model pangkalan data seterusnya dengan betul atau hampir betul.

Jadi. Saya memberitahu anda tentang sambungan satu-ke-banyak dan saya akan memberitahu anda lebih lanjut tentang sambungan dalam bahagian kemudian dalam panduan ini, jadi saya tidak akan membincangkannya lagi buat masa ini. Ingatlah bahawa memutuskan hubungan yang akan dimiliki oleh entiti anda adalah bahagian penting reka bentuk pangkalan data dan sambungan ini dipaparkan dalam rajah hubungan entiti.