Artikel daripada siri tentang mencipta projek Java (pautan ke bahan lain ada di penghujung). Matlamatnya adalah untuk menganalisis teknologi utama, hasilnya menulis bot telegram.
Hello semua, bakal Senior dan Senioritas perisian. Seperti yang saya katakan pada bahagian sebelum ini ( menyemak kerja rumah ), hari ini akan ada bahan baru. Bagi mereka yang teringin terutamanya, saya telah menggali tugasan kerja rumah yang menarik supaya mereka yang sudah tahu segala-galanya dan mereka yang tidak tahu tetapi ingin meng-google boleh berlatih dan menguji kemahiran mereka. Hari ini kita akan bercakap tentang jenis sambungan dan sambungan.
Jenis perhubungan dalam pangkalan data
Untuk memahami apa itu perhubungan, anda perlu ingat apa itu kunci asing. Bagi yang terlupa, selamat datang ke permulaan siri ini .
Satu-ke-banyak
Mari kita ingat contoh kita dengan negara dan bandar. Jelas bahawa sebuah bandar mesti mempunyai sebuah negara. Bagaimana untuk menghubungkan negara dengan bandar? Adalah perlu untuk melampirkan pada setiap bandar pengecam unik (ID) negara tempat ia berada: kami telah pun melakukan ini. Ini dipanggil salah satu jenis sambungan - satu kepada banyak (ia juga bagus untuk mengetahui versi bahasa Inggeris - satu-ke-banyak). Untuk menghuraikan, kita boleh katakan: beberapa bandar boleh menjadi milik satu negara. Itulah cara anda harus mengingatinya: hubungan satu-dengan-banyak. Setakat ini ia jelas, bukan? Jika tidak, maka inilah gambar pertama dari Internet: Ia menunjukkan bahawa terdapat pelanggan dan pesanan mereka. Masuk akal bahawa seorang pelanggan boleh mempunyai lebih daripada satu pesanan. Terdapat satu-ke-banyak :) Atau contoh lain: Terdapat tiga jadual: penerbit, pengarang dan buku. Setiap penerbit yang tidak mahu muflis dan ingin berjaya ada lebih daripada seorang penulis, setuju tak? Sebaliknya, setiap pengarang mungkin mempunyai lebih daripada satu buku - tidak ada keraguan tentang itu sama ada. Dan ini bermakna, sekali lagi, sambungan seorang pengarang kepada banyak buku, satu penerbit kepada banyak pengarang . Terdapat banyak lagi contoh yang boleh diberikan. Kesukaran dalam persepsi pada mulanya mungkin hanya terletak pada belajar berfikir secara abstrak: untuk melihat dari luar pada jadual dan interaksi mereka.
Satu lawan satu (satu lawan satu)
Ini boleh dikatakan sebagai kes khas komunikasi satu-ke-banyak. Situasi di mana satu rekod dalam satu jadual dikaitkan dengan hanya satu rekod dalam jadual lain. Apakah contoh yang boleh didapati daripada kehidupan? Jika kita mengecualikan poligami, maka kita boleh mengatakan bahawa terdapat hubungan satu-satu antara suami isteri. Walaupun kita katakan poligami itu dibenarkan, maka setiap isteri masih boleh mempunyai seorang suami sahaja. Perkara yang sama boleh dikatakan tentang ibu bapa. Setiap orang hanya boleh mempunyai seorang bapa kandung dan hanya seorang ibu kandung. Hubungan satu dengan satu yang jelas. Semasa saya menulis ini, saya terfikir: mengapa kemudian membahagikan hubungan satu dengan satu kepada dua rekod dalam jadual yang berbeza, jika mereka sudah mempunyai hubungan satu dengan satu? Saya sendiri yang menjawabnya. Rekod ini juga boleh dikaitkan dengan rekod lain dengan cara lain. Apa yang saya cakapkan? Satu lagi contoh hubungan satu dengan satu ialah antara negara dan presiden. Adakah mungkin untuk menulis semua data tentang presiden dalam jadual "negara"? Ya, anda boleh, SQL tidak akan berkata sepatah pun. Tetapi jika anda berfikir bahawa presiden juga seorang... Dan dia juga mungkin mempunyai seorang isteri (satu-dengan-satu hubungan lain) dan anak-anak (satu lagi hubungan satu-dengan-banyak) dan kemudian ternyata ia akan menjadi perlu untuk menghubungkan negara dengan isteri dan anak-anak presiden…. Bunyi gila, kan? :D Terdapat banyak contoh lain untuk sambungan ini. Selain itu, dalam keadaan sedemikian, anda boleh menambah kunci asing pada kedua-dua jadual, tidak seperti perhubungan satu dengan banyak.
Banyak-ke-banyak
Sudah berdasarkan nama, anda boleh meneka apa yang akan kami bincangkan. Selalunya dalam kehidupan, dan kita memprogramkan kehidupan kita, terdapat situasi apabila jenis sambungan di atas tidak mencukupi untuk menerangkan perkara yang kita perlukan. Kami telah pun bercakap tentang penerbit, buku dan pengarang. Terdapat begitu banyak sambungan di sini... Setiap penerbitan boleh mempunyai beberapa pengarang - sambungan satu-ke-banyak. Pada masa yang sama, setiap penulis mungkin mempunyai beberapa penerbit (mengapa tidak, penulis diterbitkan di satu tempat, bergaduh kerana wang, pergi ke rumah penerbitan lain, misalnya). Dan ini sekali lagi hubungan satu-dengan-banyak. Atau ini: setiap pengarang boleh mempunyai beberapa buku, tetapi setiap buku juga boleh mempunyai beberapa pengarang. Sekali lagi, hubungan satu-ke-banyak antara pengarang dan buku, buku dan pengarang. Daripada contoh ini kita boleh membuat kesimpulan yang lebih formal:
Jika kita mempunyai dua jadual A dan B.
A boleh mengaitkan B sebagai satu kepada banyak.
Tetapi B juga boleh dikaitkan dengan A kerana satu berkaitan dengan banyak.
Ini bermakna mereka mempunyai hubungan ramai-ke-banyak.
Sudah jelas cara untuk menetapkan jenis sambungan sebelumnya dalam SQL: kita hanya menghantar ID yang satu itu kepada rekod tersebut, yang mana terdapat banyak, bukan? Satu negara memberikan IDnya sebagai kunci asing kepada banyak bandar. Apa yang perlu dilakukan dengan hubungan ramai-ke-banyak ? Kaedah ini tidak sesuai. Kita perlu menambah jadual lain yang akan menyambungkan kedua-dua jadual. Sebagai contoh, mari pergi ke MySQL, cipta pangkalan data baharu manytomany, buat dua jadual, pengarang dan buku, yang akan mengandungi hanya nama dan ID mereka: CREATE DATABASE manytomany; GUNAKAN manytomany; CREATE TABLE author( id INT AUTO_INCREMENT, name VARCHAR(100), PRIMARY KEY (id) ); CREATE TABLE book( id INT AUTO_INCREMENT, name VARCHAR(100), PRIMARY KEY (id) ); Sekarang mari kita buat jadual ketiga yang akan mempunyai dua kunci asing daripada pengarang dan jadual buku kami, dan pautan ini akan menjadi unik. Iaitu, tidak mungkin untuk menambah rekod dengan kekunci yang sama dua kali: CREATE TABLE authors_x_books ( book_id INT NOT NULL, author_id INT NOT NULL, FOREIGN KEY (book_id) REFERENCES book(id), FOREIGN KEY (author_id) RUJUKAN pengarang (id ), UNIK (id_buku, id_pengarang) ); Di sini kami menggunakan beberapa ciri baharu yang perlu diulas secara berasingan:
NOT NULL bermakna medan mesti sentiasa diisi, dan jika tidak, SQL akan memberitahu kami;
UNIQUE mengatakan bahawa medan atau sekumpulan medan mestilah unik dalam jadual. Selalunya berlaku bahawa sebagai tambahan kepada pengecam unik, satu lagi medan mesti unik untuk setiap rekod. Dan UNIQUE bertanggungjawab untuk perkara ini.
Daripada amalan saya: apabila beralih daripada sistem lama kepada sistem baharu, kami, sebagai pembangun, mesti menyimpan ID sistem lama untuk bekerja dengannya dan mencipta ID kami sendiri. Mengapa membuat sendiri dan tidak menggunakan yang lama? Ia mungkin tidak cukup unik, atau pendekatan untuk mencipta ID ini mungkin tidak lagi relevan dan terhad. Untuk tujuan ini, kami menjadikan nama ID lama juga unik dalam jadual. Untuk menyemak ini, anda perlu menambah data. Tambah buku dan pengarang: NSERT INTO buku (nama) NILAI ("buku1"); MASUKKAN KE DALAM pengarang (nama) NILAI ("pengarang1"); Kita sudah tahu daripada artikel sebelumnya bahawa mereka akan mempunyai ID 1 dan 1. Oleh itu, kita boleh serta-merta menambah rekod pada jadual ketiga: INSERT INTO authors_x_books NILAI (1,1); Dan semuanya akan baik-baik saja sehingga kita mahu mengulangi perintah terakhir sekali lagi: iaitu, tulis ID yang sama sekali lagi: Hasilnya akan menjadi semula jadi - ralat. Akan ada pendua. Kemasukan tidak akan direkodkan. Beginilah cara sambungan banyak-ke-banyak akan dibuat... Semua ini sangat keren dan menarik, tetapi persoalan logik timbul: bagaimana untuk mendapatkan maklumat ini? Bagaimana untuk menggabungkan data daripada jadual yang berbeza bersama-sama dan mendapatkan satu jawapan? Inilah yang akan kita bincangkan dalam bahagian seterusnya))
Sambungan (Sertai)
Pada bahagian sebelumnya, saya menyediakan anda untuk segera memahami apa itu gabungan dan di mana untuk menggunakannya. Kerana saya sangat yakin bahawa sebaik sahaja pemahaman datang, segala-galanya akan menjadi sangat mudah, dan semua artikel tentang gabungan akan menjadi jelas seperti mata bayi :D Secara kasar dan secara umum, gabungan mendapat hasil daripada beberapa jadual dengan cara daripada JOIN (menyertai daripada English join). Dan itu sahaja...) Dan untuk menyertai, anda perlu menentukan medan yang mana jadual akan disertai. Syaitan tidak seram seperti yang dilukis, bukan?) Seterusnya, kita hanya akan bercakap tentang jenis cantuman yang ada dan cara menggunakannya. Terdapat banyak jenis penyertaan, dan kami tidak akan menganggap semuanya. Hanya mereka yang benar-benar kita perlukan. Itulah sebabnya kami tidak berminat dengan gabungan eksotik seperti Cross dan Natural. Saya benar-benar terlupa, kita perlu ingat satu lagi nuansa: jadual dan medan boleh mempunyai alias - nama samaran. Ia mudah digunakan untuk sambungan. Sebagai contoh, anda boleh melakukan ini: SELECT * FROM table1; jika pertanyaan selalunya menggunakan table1, maka anda boleh memberikannya alias: SELECT* FROM table1 as t1; atau lebih mudah untuk menulis: PILIH * DARI jadual1 t1; dan kemudian dalam pertanyaan itu mungkin untuk menggunakan t1 sebagai alias untuk jadual ini.
SERTAI DALAM
Gabungan yang paling biasa dan mudah. Ia mengatakan bahawa apabila kita mempunyai dua jadual dan medan yang boleh dicantumkan, semua rekod yang hubungannya wujud dalam dua jadual akan dipilih. Ia adalah sukar untuk mengatakan entah bagaimana. Mari kita lihat contoh: Mari tambah satu rekod pada pangkalan data bandar kita. Satu entri untuk bandar dan satu untuk negara: $ INSERT INTO country VALUES(5, "Uzbekistan", 34036800); dan $ INSERT INTO city (nama, populasi) VALUES("Tbilisi", 1171100); Kami menambah negara yang tidak mempunyai bandar dalam jadual kami dan bandar yang tidak dikaitkan dengan negara dalam jadual kami. Jadi, INNER JOIN terlibat dalam mengeluarkan semua rekod untuk sambungan yang terdapat dalam dua jadual. Beginilah rupa sintaks umum apabila kita ingin mencantumkan dua jadual table1 dan table2: SELECT * FROM table1 t1 INNER JOIN table2 ON t1.id = t2.t1_id; dan kemudian semua rekod yang mempunyai hubungan dalam kedua-dua jadual akan dikembalikan. Untuk kes kami, apabila kami ingin menerima maklumat untuk negara bersama dengan bandar, ia akan menjadi seperti ini: $ PILIH * DARI bandar ci DALAM SERTAI negara co DI ci.country_id = co.id; Di sini, walaupun nama adalah sama, anda dapat melihat dengan jelas bahawa bidang bandar didahulukan, kemudian bidang negara. Tetapi dua entri yang kami tambah di atas tidak ada. Kerana itulah cara INNER JOIN berfungsi.
KIRI SERTAI
Terdapat kes, dan agak kerap, apabila kita tidak berpuas hati dengan kehilangan medan jadual utama kerana fakta bahawa tidak ada rekod untuknya dalam jadual bersebelahan. Inilah gunanya LEFT JOIN. Jika dalam permintaan kami sebelum ini, kami menentukan KIRI dan bukannya INNER, kami akan menambah bandar lain dalam jawapan - Tbilisi: $ PILIH * DARI bandar ci KIRI SERTAI negara bersama DI ci.country_id = co.id; Terdapat entri baru tentang Tbilisi dan semua yang berkaitan dengan negara itu adalah batal . Ini selalunya bagaimana ia digunakan.
BETUL SERTAI
Di sini akan terdapat perbezaan daripada LEFT JOIN kerana semua medan akan dipilih bukan di sebelah kiri, tetapi di sebelah kanan dalam sambungan. Iaitu, bukan bandar, tetapi semua negara akan diambil: $ PILIH * DARI bandar ci KANAN JOIN country co DI ci.country_id = co.id; Kini jelas bahawa dalam kes ini tidak akan ada Tbilisi, tetapi kita akan mempunyai Uzbekistan. Sesuatu seperti itu…))
Menjamin Gabungan
Sekarang saya ingin menunjukkan kepada anda gambar biasa yang dijejalkan oleh junior sebelum temu duga untuk meyakinkan mereka bahawa mereka memahami intipati gabungan: Di sini semuanya ditunjukkan dalam bentuk set, setiap bulatan adalah jadual. Dan tempat di mana ia dicat adalah bahagian yang akan ditunjukkan dalam SELECT. Mari lihat:
INNER JOIN hanyalah persilangan set, iaitu rekod yang mempunyai sambungan kepada dua jadual - A dan B;
LEFT JOIN ialah semua rekod daripada jadual A, termasuk semua rekod daripada jadual B yang mempunyai persilangan (sambungan) dengan A;
RIGHT JOIN betul-betul bertentangan dengan LEFT JOIN - semua rekod dalam jadual B dan rekod daripada A yang mempunyai hubungan.
Selepas semua ini, gambar ini sepatutnya jelas))
Kerja rumah
Tugasan kali ini akan menjadi sangat menarik dan semua orang yang berjaya menyelesaikannya boleh yakin bahawa mereka sudah bersedia untuk mula bekerja di bahagian SQL! Tugasan tidak dikunyah dan ditulis untuk pelajar pertengahan, jadi ia tidak akan menjadi mudah dan membosankan untuk anda :) Saya akan memberi anda masa seminggu untuk melakukan tugasan itu sendiri, dan kemudian saya akan menerbitkan artikel berasingan dengan analisis terperinci penyelesaian kepada tugasan yang saya berikan kepada anda.
Tugas sebenar:
Tulis skrip SQL untuk mencipta jadual 'Pelajar' dengan medan berikut: id (kunci utama), nama, nama belakang, e-mel (unik).
Tulis skrip SQL untuk mencipta jadual 'Buku' dengan medan berikut: id, tajuk (id + tajuk = kunci utama). Pautkan 'Pelajar' dan 'Buku' dengan perhubungan 'Buku' 'Pelajar' satu-ke-banyak.
Tulis skrip SQL untuk mencipta jadual 'Guru' dengan medan berikut: id (kunci utama), nama, nama belakang, e_mel (unik), subjek.
Pautkan 'Pelajar' dan 'Guru' dengan hubungan 'Pelajar' ramai-ke-banyak Guru.
Pilih 'Pelajar' yang mempunyai 'oro' dalam nama keluarga mereka, contohnya 'Sid oro v', 'V oro novsky'.
Pilih daripada jadual 'Pelajar' semua nama keluarga ('last_name') dan bilangan ulangan mereka. Pertimbangkan bahawa terdapat nama dalam pangkalan data. Isih mengikut kuantiti dalam tertib menurun. Ia sepatutnya kelihatan seperti ini:
nama terakhir
kuantiti
Petrov
15
Ivanov
12
Sidorov
3
Pilih 3 nama teratas yang paling kerap berulang daripada 'Pelajar'. Isih mengikut kuantiti dalam tertib menurun. Ia sepatutnya kelihatan seperti ini:
nama
kuantiti
Alexander
27
Sergey
10
Peter
7
Pilih 'Pelajar' yang mempunyai bilangan terbesar 'Buku' dan 'Guru' yang berkaitan. Isih mengikut kuantiti dalam tertib menurun. Ia sepatutnya kelihatan seperti ini:
Nama keluarga_guru
Nama belakang pelajar
Kuantiti buku
Petrov
Sidorov
7
Ivanov
Smith
5
Petrov
Kankava
2>
Pilih 'Guru' yang mempunyai bilangan 'Buku' terbanyak daripada semua 'Pelajar'nya. Isih mengikut kuantiti dalam tertib menurun. Ia sepatutnya kelihatan seperti ini:
Nama keluarga_guru
Kuantiti buku
Petrov
9
Ivanov
5
Pilih 'Guru' yang bilangan 'Buku' untuk semua 'Pelajar'nya adalah antara 7 dan 11. Isih mengikut kuantiti dalam tertib menurun. Ia sepatutnya kelihatan seperti ini:
Nama keluarga_guru
Kuantiti buku
Petrov
sebelas
Sidorov
9
Ivanov
7
Cetak semua 'nama_akhir' dan 'nama' semua 'Guru' dan 'Pelajar' dengan medan 'jenis' (pelajar atau guru). Isih mengikut abjad mengikut 'last_name'. Ia sepatutnya kelihatan seperti ini:
nama terakhir
menaip
Ivanov
pelajar
Kankava
cikgu
Smith
pelajar
Sidorov
cikgu
Petrov
cikgu
Tambahkan lajur 'kadar' pada jadual 'Pelajar' sedia ada, yang akan menyimpan kursus yang pelajar sedang pelajari (nilai angka dari 1 hingga 6).
Item ini tidak diperlukan, tetapi akan menjadi tambahan. Tulis fungsi yang akan melalui semua 'Buku' dan mengeluarkan semua 'tajuk' yang dipisahkan dengan koma.
Kesimpulan
Siri tentang pangkalan data telah berlarutan sedikit. Setuju. Walau bagaimanapun, kami telah melangkah jauh dan hasilnya kami muncul dengan pengetahuan tentang perkara itu! Terima kasih semua kerana membaca, saya mengingatkan anda bahawa semua orang yang ingin meneruskan dan mengikuti projek itu perlu membuat akaun di GitHub dan melanggan akaun saya :) Lebih banyak lagi akan datang - mari kita bercakap tentang Maven dan Docker. Terima kasih semua kerana membaca. Saya ulang sekali lagi: orang yang berjalan akan menguasai jalan ;)
Hari ini kita akan bercakap tentang jenis sambungan dan sambungan.
Untuk memahami apa itu perhubungan, anda perlu ingat apa itu kunci asing. Bagi yang terlupa, selamat datang ke permulaan siri ini .
inilah gambar pertama dari Internet: Ia menunjukkan bahawa terdapat pelanggan dan pesanan mereka. Masuk akal bahawa seorang pelanggan boleh mempunyai lebih daripada satu pesanan. Terdapat satu-ke-banyak :) Atau contoh lain: 
Terdapat tiga jadual: penerbit, pengarang dan buku. Setiap penerbit yang tidak mahu muflis dan ingin berjaya ada lebih daripada seorang penulis, setuju tak? Sebaliknya, setiap pengarang mungkin mempunyai lebih daripada satu buku - tidak ada keraguan tentang itu sama ada. Dan ini bermakna, sekali lagi, sambungan seorang pengarang kepada banyak buku, satu penerbit kepada banyak pengarang . Terdapat banyak lagi contoh yang boleh diberikan. Kesukaran dalam persepsi pada mulanya mungkin hanya terletak pada belajar berfikir secara abstrak: untuk melihat dari luar pada jadual dan interaksi mereka.
Sekarang mari kita buat jadual ketiga yang akan mempunyai dua kunci asing daripada pengarang dan jadual buku kami, dan pautan ini akan menjadi unik. Iaitu, tidak mungkin untuk menambah rekod dengan kekunci yang sama dua kali: CREATE TABLE authors_x_books ( book_id INT NOT NULL, author_id INT NOT NULL, FOREIGN KEY (book_id) REFERENCES book(id), FOREIGN KEY (author_id) RUJUKAN pengarang (id ), UNIK (id_buku, id_pengarang) ); 
Di sini kami menggunakan beberapa ciri baharu yang perlu diulas secara berasingan:
Hasilnya akan menjadi semula jadi - ralat. Akan ada pendua. Kemasukan tidak akan direkodkan. Beginilah cara sambungan banyak-ke-banyak akan dibuat... Semua ini sangat keren dan menarik, tetapi persoalan logik timbul: bagaimana untuk mendapatkan maklumat ini? Bagaimana untuk menggabungkan data daripada jadual yang berbeza bersama-sama dan mendapatkan satu jawapan? Inilah yang akan kita bincangkan dalam bahagian seterusnya))
Di sini, walaupun nama adalah sama, anda dapat melihat dengan jelas bahawa bidang bandar didahulukan, kemudian bidang negara. Tetapi dua entri yang kami tambah di atas tidak ada. Kerana itulah cara INNER JOIN berfungsi.
Terdapat entri baru tentang Tbilisi dan semua yang berkaitan dengan negara itu adalah batal . Ini selalunya bagaimana ia digunakan.
Kini jelas bahawa dalam kes ini tidak akan ada Tbilisi, tetapi kita akan mempunyai Uzbekistan. Sesuatu seperti itu…))
Di sini semuanya ditunjukkan dalam bentuk set, setiap bulatan adalah jadual. Dan tempat di mana ia dicat adalah bahagian yang akan ditunjukkan dalam SELECT. Mari lihat:
GO TO FULL VERSION