Một bài viết trong loạt bài viết về cách tạo một dự án Java (có liên kết đến các tài liệu khác ở cuối). Mục tiêu của nó là phân tích các công nghệ chủ chốt, kết quả là viết một bot điện tín.
Xin chào tất cả mọi người, những Seniors và Senioritas tương lai của lĩnh vực phần mềm. Như mình đã nói ở phần trước ( kiểm tra bài tập về nhà ), hôm nay sẽ có tài liệu mới. Đối với những người đặc biệt háo hức, tôi đã đào một bài tập về nhà thú vị để những người đã biết mọi thứ và những người chưa biết nhưng muốn google có thể thực hành và kiểm tra kỹ năng của họ. Hôm nay chúng ta sẽ nói về các loại kết nối và liên kết.
Các loại mối quan hệ trong cơ sở dữ liệu
Để hiểu mối quan hệ là gì, bạn cần nhớ khóa ngoại là gì. Đối với những người đã quên, chào mừng bạn đến với phần đầu của bộ truyện .
Một-nhiều
Hãy nhớ lại ví dụ của chúng ta với các quốc gia và thành phố. Rõ ràng là một thành phố phải có một quốc gia. Làm thế nào để liên kết một quốc gia với một thành phố? Cần phải gắn cho mỗi thành phố một mã định danh (ID) duy nhất của quốc gia mà thành phố đó thuộc về: chúng tôi đã thực hiện việc này. Đây được gọi là một trong những kiểu kết nối - một với nhiều (cũng sẽ rất tốt nếu biết phiên bản tiếng Anh - một với nhiều). Để diễn giải, chúng ta có thể nói: nhiều thành phố có thể thuộc về một quốc gia. Đó là cách bạn nên nhớ: mối quan hệ một-nhiều. Cho đến nay mọi chuyện đã rõ ràng, phải không? Nếu không, thì đây là bức ảnh đầu tiên từ Internet: Nó cho thấy có khách hàng và đơn đặt hàng của họ. Điều hợp lý là một khách hàng có thể có nhiều đơn hàng. Có một-nhiều :) Hoặc một ví dụ khác: Có ba bảng: nhà xuất bản, tác giả và sách. Nhà xuất bản nào không muốn phá sản và muốn thành công đều có nhiều hơn một tác giả, bạn có đồng ý không? Đổi lại, mỗi tác giả có thể có nhiều hơn một cuốn sách - không thể nghi ngờ gì về điều đó. Và điều này một lần nữa có nghĩa là sự kết nối của một tác giả với nhiều cuốn sách, một nhà xuất bản với nhiều tác giả . Còn rất nhiều ví dụ nữa có thể được đưa ra. Khó khăn trong nhận thức lúc đầu có thể chỉ nằm ở việc học cách suy nghĩ trừu tượng: nhìn từ bên ngoài vào các bàn và sự tương tác của chúng.
Một đối một (một đối một)
Có thể nói đây là trường hợp đặc biệt của giao tiếp một-nhiều. Tình huống trong đó một bản ghi trong một bảng chỉ liên quan đến một bản ghi trong bảng khác. Những ví dụ nào có thể có từ cuộc sống? Nếu loại trừ chế độ đa thê thì có thể nói rằng giữa vợ và chồng có mối quan hệ một đối một. Dù cho dù có nói được phép đa thê thì mỗi người vợ vẫn chỉ được có một chồng. Điều tương tự cũng có thể nói về cha mẹ. Mỗi người chỉ có thể có một cha ruột và chỉ có một mẹ ruột. Rõ ràng mối quan hệ một-một. Trong khi viết bài này, tôi chợt nảy ra một ý nghĩ: tại sao lại chia mối quan hệ một-một thành hai bản ghi trong các bảng khác nhau, nếu chúng đã có mối quan hệ một-một? Tôi đã tự mình đưa ra câu trả lời. Những bản ghi này cũng có thể được liên kết với các bản ghi khác theo những cách khác. Tôi đang nói về cái gì vậy? Một ví dụ khác về mối quan hệ một-một là giữa đất nước và tổng thống. Có thể ghi lại tất cả dữ liệu về tổng thống vào bảng “quốc gia” không? Có, bạn có thể, SQL sẽ không nói một lời nào. Nhưng nếu bạn nghĩ rằng tổng thống cũng là một người... Và ông ấy cũng có thể có vợ (một mối quan hệ một-một khác) và các con (một mối quan hệ một-nhiều khác) và khi đó hóa ra là sẽ như vậy cần thiết để kết nối đất nước với vợ con tổng thống…. Nghe có vẻ điên rồ phải không? :D Có thể có nhiều ví dụ khác cho kết nối này. Hơn nữa, trong tình huống như vậy, bạn có thể thêm khóa ngoại vào cả hai bảng, không giống như mối quan hệ một-nhiều.
Nhiều nhiều
Dựa vào cái tên là bạn có thể đoán được chúng ta sẽ nói về điều gì rồi. Thông thường trong cuộc sống và chúng ta lập trình cho cuộc sống của mình, có những tình huống mà những kiểu kết nối trên không đủ để mô tả những thứ chúng ta cần. Chúng ta đã nói về nhà xuất bản, sách và tác giả. Có quá nhiều kết nối ở đây... Mỗi ấn phẩm có thể có nhiều tác giả - kết nối một-nhiều. Đồng thời, mỗi tác giả có thể có nhiều nhà xuất bản (tại sao không, nhà văn được xuất bản ở một nơi, tranh giành tiền bạc, đi đến nhà xuất bản khác chẳng hạn). Và đây lại là mối quan hệ một-nhiều. Hoặc thế này: mỗi tác giả có thể có nhiều cuốn sách, nhưng mỗi cuốn sách cũng có thể có nhiều tác giả. Một lần nữa, mối quan hệ một-nhiều giữa tác giả và sách, sách và tác giả. Từ ví dụ này chúng ta có thể rút ra một kết luận chính thức hơn:
Nếu chúng ta có hai bảng A và B.
A có thể liên hệ với B như một với nhiều.
Nhưng B cũng có thể liên hệ với A như một người liên quan đến nhiều người.
Điều này có nghĩa là họ có mối quan hệ nhiều-nhiều.
Cách thiết lập các loại kết nối trước đó trong SQL đã rõ ràng: chúng ta chỉ chuyển ID của kết nối đó cho các bản ghi đó, trong đó có rất nhiều, phải không? Một quốc gia cung cấp ID của mình làm khóa ngoại cho nhiều thành phố. Phải làm gì với mối quan hệ nhiều-nhiều ? Phương pháp này không phù hợp. Chúng ta cần thêm một bảng khác để kết nối hai bảng. Ví dụ: chúng ta hãy truy cập MySQL, tạo một cơ sở dữ liệu mới manytomany, tạo hai bảng, tác giả và sách, sẽ chỉ chứa tên và ID của chúng: TẠO CƠ SỞ DỮ LIỆU manytomany; SỬ DỤNG nhiều thứ; TẠO BẢNG tác giả( id INT AUTO_INCREMENT, tên VARCHAR(100), PRIMARY KEY (id) ); TẠO BẢNG sách( id INT AUTO_INCREMENT, name VARCHAR(100), PRIMARY KEY (id) ); Bây giờ, hãy tạo một bảng thứ ba có hai khóa ngoại từ bảng tác giả và sách của chúng ta, và liên kết này sẽ là duy nhất. Nghĩa là, sẽ không thể thêm một bản ghi có cùng khóa hai lần: TẠO BẢNG tác giả_x_books ( book_id INT NOT NULL, Author_id INT NOT NULL, FOREIGN KEY (book_id) REFERENCES book(id), FORIGN KEY (author_id) REFERENCES tác giả (id ), ĐỘC ĐÁO (book_id, tác giả_id) ); Ở đây chúng tôi đã sử dụng một số tính năng mới cần được nhận xét riêng:
NOT NULL có nghĩa là trường này phải luôn được điền và nếu chúng ta không điền, SQL sẽ cho chúng ta biết như vậy;
ĐỘC ĐÁO nói rằng một trường hoặc một loạt trường phải là duy nhất trong bảng. Điều thường xảy ra là ngoài mã định danh duy nhất, một trường nữa phải là duy nhất cho mỗi bản ghi. Và UNIQUE chịu trách nhiệm chính xác về vấn đề này.
Theo thực tế của tôi: khi chuyển từ hệ thống cũ sang hệ thống mới, chúng tôi, với tư cách là nhà phát triển, phải lưu trữ ID của hệ thống cũ để làm việc với hệ thống đó và tạo hệ thống của riêng mình. Tại sao phải tạo của riêng bạn và không sử dụng cái cũ? Chúng có thể không đủ độc đáo hoặc phương pháp tạo ID này có thể không còn phù hợp và bị hạn chế nữa. Với mục đích này, chúng tôi đã đặt tên ID cũ cũng là duy nhất trong bảng. Để kiểm tra điều này, bạn cần thêm dữ liệu. Thêm sách và tác giả: NSERT INTO book (tên) GIÁ TRỊ ("cuốn sách1"); CHÈN VÀO tác giả (tên) GIÁ TRỊ ("tác giả1"); Chúng ta đã biết từ các bài viết trước rằng chúng sẽ có ID 1 và 1. Do đó, chúng ta có thể thêm ngay một bản ghi vào bảng thứ ba: INSERT INTOauthor_x_books VALUES (1,1); Và mọi thứ sẽ ổn cho đến khi chúng ta muốn lặp lại lệnh cuối cùng một lần nữa: tức là viết lại các ID giống nhau: Kết quả sẽ tự nhiên - một lỗi. Sẽ có một bản sao. Mục nhập sẽ không được ghi lại. Đây là cách kết nối nhiều-nhiều sẽ được tạo ra... Tất cả điều này rất hay và thú vị, nhưng một câu hỏi hợp lý được đặt ra: làm thế nào để có được thông tin này? Làm cách nào để kết hợp dữ liệu từ các bảng khác nhau và nhận được một câu trả lời? Đây là những gì chúng ta sẽ nói ở phần tiếp theo))
Kết nối (Tham gia)
Trong phần trước, tôi đã giúp bạn hiểu ngay phép nối là gì và nơi sử dụng chúng. Bởi vì tôi tin chắc rằng ngay khi hiểu ra thì mọi thứ sẽ ngay lập tức trở nên rất đơn giản, và tất cả các bài viết về phép nối sẽ rõ ràng như đôi mắt của em bé :D Nói chung và nói chung, các phép nối đang nhận được kết quả từ nhiều bảng bằng nhiều cách của THAM GIA (tham gia từ tiếng Anh tham gia). Và chỉ vậy thôi...) Và để tham gia, bạn cần chỉ định trường mà các bảng sẽ được tham gia. Ma quỷ không đáng sợ như người ta vẽ, phải không?) Tiếp theo, chúng ta sẽ chỉ nói về những loại mối nối và cách sử dụng chúng. Có nhiều loại liên kết và chúng tôi sẽ không xem xét tất cả chúng. Chỉ những thứ chúng ta thực sự cần. Đó là lý do tại sao chúng tôi không quan tâm đến những phép nối kỳ lạ như Cross và Natural. Tôi hoàn toàn quên mất, chúng ta cần nhớ thêm một sắc thái: bảng và trường có thể có bí danh - bút danh. Chúng được sử dụng thuận tiện để tham gia. Ví dụ: bạn có thể thực hiện việc này: CHỌN * TỪ bảng1; nếu truy vấn thường sử dụng bảng1 thì bạn có thể đặt bí danh cho nó: SELECT* FROM table1 as t1; hoặc thậm chí dễ viết hơn: SELECT * FROM table1 t1; và sau đó trong truy vấn, có thể sử dụng t1 làm bí danh cho bảng này.
THAM GIA TRONG
Sự tham gia phổ biến và đơn giản nhất. Nó nói rằng khi chúng ta có hai bảng và một trường mà nó có thể được nối với nhau, tất cả các bản ghi có mối quan hệ tồn tại trong hai bảng sẽ được chọn. Thật khó để nói bằng cách nào đó. Hãy xem một ví dụ: Hãy thêm một bản ghi vào cơ sở dữ liệu thành phố của chúng ta. Một mục nhập cho các thành phố và một mục nhập cho các quốc gia: $ INSERT INTO country VALUES(5, "Uzbekistan", 34036800); và $ CHÈN VÀO thành phố (tên, dân số) GIÁ TRỊ("Tbilisi", 1171100); Chúng tôi đã thêm một quốc gia không có thành phố vào bảng của chúng tôi và một thành phố không liên kết với một quốc gia trong bảng của chúng tôi. Vì vậy, INNER JOIN tham gia vào việc phát hành tất cả các bản ghi cho các kết nối nằm trong hai bảng. Đây là cú pháp chung khi chúng ta muốn nối hai bảng table1 và table2: SELECT * FROM table1 t1 INNER JOIN table2 ON t1.id = t2.t1_id; và sau đó tất cả các bản ghi có mối quan hệ trong hai bảng sẽ được trả về. Đối với trường hợp của chúng tôi, khi chúng tôi muốn nhận thông tin về các quốc gia cùng với các thành phố, kết quả sẽ như thế này: $ SELECT * FROM city ci INNER JOIN country co ON ci.country_id = co.id; Ở đây, mặc dù tên giống nhau nhưng có thể thấy rõ rằng trường thành phố có trước, sau đó đến trường quốc gia. Nhưng hai mục mà chúng tôi đã thêm ở trên không có ở đó. Bởi vì đó chính xác là cách INNER JOIN hoạt động.
CHỖ NỐI BÊN TRÁI
Có những trường hợp và khá thường xuyên, khi chúng ta không hài lòng với việc mất các trường của bảng chính do không có bản ghi nào cho nó ở bảng liền kề. Đây chính là mục đích của LEFT JOIN. Nếu trong yêu cầu trước đó, chúng tôi chỉ định LEFT thay vì INNER, chúng tôi sẽ thêm một thành phố khác vào phản hồi - Tbilisi: $ SELECT * FROM city ci LEFT JOIN country co ON ci.country_id = co.id; Có một mục mới về Tbilisi và mọi thứ liên quan đến đất nước này đều vô hiệu . Đây thường là cách nó được sử dụng.
QUYỀN THAM GIA
Ở đây sẽ có điểm khác biệt so với LEFT JOIN ở chỗ tất cả các trường sẽ được chọn không phải ở bên trái mà ở bên phải trong kết nối. Nghĩa là, không phải thành phố, mà tất cả các quốc gia sẽ được lấy: $ SELECT * FROM city ci RIGHT JOIN country co ON ci.country_id = co.id; Bây giờ rõ ràng là trong trường hợp này sẽ không có Tbilisi mà chúng ta sẽ có Uzbekistan. Đại loại như thế…))
Bảo vệ các mối nối
Bây giờ tôi muốn cho các bạn xem một bức tranh điển hình mà các bạn trẻ nhồi nhét trước khi phỏng vấn để thuyết phục họ hiểu bản chất của phép nối: Ở đây mọi thứ đều được thể hiện dưới dạng tập hợp, mỗi vòng tròn là một bảng. Và những nơi nó được sơn lên là những phần sẽ được hiển thị trong CHỌN. Hãy xem:
INNER JOIN chỉ là giao điểm của các tập hợp, tức là những bản ghi có kết nối với hai bảng - A và B;
LEFT JOIN là tất cả các bản ghi từ bảng A, bao gồm tất cả các bản ghi từ bảng B có giao điểm (kết nối) với A;
RIGHT JOIN hoàn toàn trái ngược với LEFT JOIN - tất cả các bản ghi trong bảng B và các bản ghi từ A có mối quan hệ.
Sau tất cả những điều này, bức ảnh này sẽ rõ ràng))
Bài tập về nhà
Lần này các nhiệm vụ sẽ rất thú vị và tất cả những ai giải quyết thành công chúng có thể yên tâm rằng họ đã sẵn sàng bắt đầu làm việc về phía SQL! Các bài tập không được nhai kỹ và được viết cho học sinh cấp hai nên sẽ không dễ và nhàm chán đối với bạn :) Tôi sẽ cho bạn một tuần để tự làm bài, sau đó tôi sẽ xuất bản một bài viết riêng kèm theo phân tích chi tiết về giải pháp cho các nhiệm vụ mà tôi đã giao cho bạn.
Nhiệm vụ thực tế:
Viết script SQL tạo bảng “Student” với các trường sau: id (khóa chính), name, Last_name, e_mail (duy nhất).
Viết script SQL tạo bảng “Book” với các trường sau: id, title (id + title = khóa chính). Liên kết 'Sinh viên' và 'Sách' với mối quan hệ một-nhiều 'Sách' 'Học sinh'.
Viết script SQL tạo bảng “Teacher” với các trường sau: id (khóa chính), name, Last_name, e_mail (duy nhất), chủ đề.
Liên kết 'Học sinh' và 'Giáo viên' với mối quan hệ 'Học sinh' nhiều-nhiều Giáo viên'.
Chọn 'Học sinh' có 'oro' trong họ của họ, ví dụ 'Sid oro v', 'V oro novsky'.
Chọn từ bảng 'Học sinh' tất cả các họ ('last_name') và số lần lặp lại của chúng. Hãy xem xét rằng có những cái tên trùng tên trong cơ sở dữ liệu. Sắp xếp theo số lượng giảm dần. Nó sẽ giống như thế này:
họ
Số lượng
Petrov
15
Ivanov
12
Sidorov
3
Chọn 3 cái tên được lặp lại nhiều nhất từ 'Học sinh'. Sắp xếp theo số lượng giảm dần. Nó sẽ giống như thế này:
tên
Số lượng
Alexander
27
Serge
10
Peter
7
Chọn 'Học sinh' có số lượng 'Sách' lớn nhất và được liên kết với 'Giáo viên'. Sắp xếp theo số lượng theo thứ tự giảm dần. Nó sẽ giống như thế này:
Họ_của giáo viên
Họ_tên của học sinh
Số lượng sách
Petrov
Sidorov
7
Ivanov
thợ rèn
5
Petrov
Kankava
2>
Chọn 'Giáo viên' có số lượng 'Sách' lớn nhất trong số tất cả 'Học sinh' của mình. Sắp xếp theo số lượng giảm dần. Nó sẽ giống như thế này:
Họ_của giáo viên
Số lượng sách
Petrov
9
Ivanov
5
Chọn 'Giáo viên' có số 'Sách' cho tất cả 'Học sinh' của mình là từ 7 đến 11. Sắp xếp theo số lượng giảm dần. Nó sẽ giống như thế này:
Họ_của giáo viên
Số lượng sách
Petrov
mười một
Sidorov
9
Ivanov
7
In tất cả 'last_name' và 'name' của tất cả 'Giáo viên' và 'Học sinh' với trường 'loại' (học sinh hoặc giáo viên). Sắp xếp theo thứ tự bảng chữ cái theo 'last_name'. Nó sẽ giống như thế này:
họ
kiểu
Ivanov
học sinh
Kankava
giáo viên
thợ rèn
học sinh
Sidorov
giáo viên
Petrov
giáo viên
Thêm cột 'giá' vào bảng 'Sinh viên' hiện có, cột này sẽ lưu trữ khóa học mà sinh viên hiện đang tham gia (giá trị số từ 1 đến 6).
Mục này không bắt buộc nhưng sẽ là một điểm cộng. Viết hàm sẽ duyệt qua tất cả 'Sách' và xuất ra tất cả 'tiêu đề' được phân tách bằng dấu phẩy.
Phần kết luận
Loạt bài về cơ sở dữ liệu đã kéo dài một chút. Đồng ý. Tuy nhiên, chúng ta đã đi được một chặng đường dài và kết quả là chúng ta đã có được kiến thức về vấn đề này! Cảm ơn tất cả các bạn đã đọc, tôi xin nhắc các bạn rằng tất cả những ai muốn tiếp tục và theo dõi dự án cần tạo một tài khoản trên GitHub và đăng ký tài khoản của tôi :) Sắp tới sẽ có thêm thông tin - hãy nói về Maven và Docker. Cảm ơn mọi người đã đọc. Tôi nhắc lại một lần nữa: người đi sẽ làm chủ con đường;)
Hôm nay chúng ta sẽ nói về các loại kết nối và liên kết.
Để hiểu mối quan hệ là gì, bạn cần nhớ khóa ngoại là gì. Đối với những người đã quên, chào mừng bạn đến với phần đầu của bộ truyện .
đây là bức ảnh đầu tiên từ Internet: Nó cho thấy có khách hàng và đơn đặt hàng của họ. Điều hợp lý là một khách hàng có thể có nhiều đơn hàng. Có một-nhiều :) Hoặc một ví dụ khác: 
Có ba bảng: nhà xuất bản, tác giả và sách. Nhà xuất bản nào không muốn phá sản và muốn thành công đều có nhiều hơn một tác giả, bạn có đồng ý không? Đổi lại, mỗi tác giả có thể có nhiều hơn một cuốn sách - không thể nghi ngờ gì về điều đó. Và điều này một lần nữa có nghĩa là sự kết nối của một tác giả với nhiều cuốn sách, một nhà xuất bản với nhiều tác giả . Còn rất nhiều ví dụ nữa có thể được đưa ra. Khó khăn trong nhận thức lúc đầu có thể chỉ nằm ở việc học cách suy nghĩ trừu tượng: nhìn từ bên ngoài vào các bàn và sự tương tác của chúng.
Bây giờ, hãy tạo một bảng thứ ba có hai khóa ngoại từ bảng tác giả và sách của chúng ta, và liên kết này sẽ là duy nhất. Nghĩa là, sẽ không thể thêm một bản ghi có cùng khóa hai lần: TẠO BẢNG tác giả_x_books ( book_id INT NOT NULL, Author_id INT NOT NULL, FOREIGN KEY (book_id) REFERENCES book(id), FORIGN KEY (author_id) REFERENCES tác giả (id ), ĐỘC ĐÁO (book_id, tác giả_id) ); 
Ở đây chúng tôi đã sử dụng một số tính năng mới cần được nhận xét riêng:
Kết quả sẽ tự nhiên - một lỗi. Sẽ có một bản sao. Mục nhập sẽ không được ghi lại. Đây là cách kết nối nhiều-nhiều sẽ được tạo ra... Tất cả điều này rất hay và thú vị, nhưng một câu hỏi hợp lý được đặt ra: làm thế nào để có được thông tin này? Làm cách nào để kết hợp dữ liệu từ các bảng khác nhau và nhận được một câu trả lời? Đây là những gì chúng ta sẽ nói ở phần tiếp theo))
Ở đây, mặc dù tên giống nhau nhưng có thể thấy rõ rằng trường thành phố có trước, sau đó đến trường quốc gia. Nhưng hai mục mà chúng tôi đã thêm ở trên không có ở đó. Bởi vì đó chính xác là cách INNER JOIN hoạt động.
Có một mục mới về Tbilisi và mọi thứ liên quan đến đất nước này đều vô hiệu . Đây thường là cách nó được sử dụng.
Bây giờ rõ ràng là trong trường hợp này sẽ không có Tbilisi mà chúng ta sẽ có Uzbekistan. Đại loại như thế…))
Ở đây mọi thứ đều được thể hiện dưới dạng tập hợp, mỗi vòng tròn là một bảng. Và những nơi nó được sơn lên là những phần sẽ được hiển thị trong CHỌN. Hãy xem:
GO TO FULL VERSION