Course All lectures for VI purposes - Lecture: Nhiệm vụ cơ bản trong thiết kế cơ sở dữ liệu

1.1 Giới thiệu

Thiết kế một cơ sở dữ liệu hơi giống với thiết kế kiến trúc của một dự án Java. Bạn có thể đặt tất cả dữ liệu vào một vài bảng hoặc bạn có thể xây dựng cấu trúc dữ liệu đẹp mắt từ các lược đồ và hàng chục bảng.

Dưới đây là các nhiệm vụ mà nhà phát triển thường phải đối mặt khi thiết kế cơ sở dữ liệu:

Đảm bảo rằng tất cả các thông tin cần thiết được lưu trữ trong cơ sở dữ liệu.
Đảm bảo khả năng lấy dữ liệu về tất cả các yêu cầu cần thiết.
Giảm sự dư thừa và trùng lặp dữ liệu.
Đảm bảo tính toàn vẹn của cơ sở dữ liệu
Tối ưu hóa tốc độ truy cập dữ liệu

Điều chính cần nhớ là bạn không thể tạo một cấu trúc cơ sở dữ liệu lý tưởng, bởi vì. nó, giống như mã của bạn, cũng sẽ thay đổi liên tục. Có ba điều bạn nên ghi nhớ khi thiết kế cấu trúc cơ sở dữ liệu của mình:

Cấu trúc phải đủ tốt.
Phải có logic trong mọi thứ mà người khác có thể hiểu được.
Tối ưu hóa sớm là gốc rễ của mọi điều ác.

Bạn không cần phải tạo cấu trúc cơ sở dữ liệu tốt nhất thế giới. Cô ấy vẫn sẽ thay đổi. Nhiệm vụ của bạn là đảm bảo rằng sau 20 lần thay đổi cấu trúc cơ sở dữ liệu của bạn, việc tìm ra nó đủ dễ dàng.

Rất có thể trong những năm đầu tiên làm việc, sẽ không ai tin tưởng bạn để thiết kế một cơ sở từ đầu. Bạn sẽ thực hiện các thay đổi đối với lược đồ hiện có. Bạn cần cố gắng hiểu nó được sắp xếp dựa trên những nguyên tắc nào và tuân thủ chúng . Với điều lệ của họ, họ không trèo vào tu viện của người khác.

Không tối ưu hóa cơ sở dữ liệu cho đến khi cần thiết. Nếu bảng chỉ có vài trăm hàng, thì rất có thể DBMS sẽ giữ nó trong bộ nhớ và truy vấn bộ nhớ đệm tới nó.

Mặt khác, bạn sẽ có thể tăng tốc công việc của các yêu cầu quan trọng lên hàng chục, thậm chí hàng trăm lần. Và thật tuyệt nếu bạn biết cách làm điều đó. Làm thế nào để họ nói ở trường trung học trong năm đầu tiên? "Hãy quên đi tất cả những gì bạn được dạy ở trường..."

Nếu bạn biết chuẩn hóa cơ sở dữ liệu là gì, thì tôi sẽ nhanh chóng làm hài lòng bạn, trong công việc của bạn, rất có thể bạn sẽ xử lý việc khử chuẩn hóa . Đối với các khu bảo tồn của dự án, không có gì quan trọng hơn tốc độ của cơ sở dữ liệu. Và nếu, để tăng tốc độ lựa chọn dữ liệu từ cơ sở dữ liệu, bạn cần kết hợp 200 (!) Bảng thành một (với độ dư thừa khủng khiếp), thì bạn sẽ phải làm điều này.

1.2 Thiết kế thư viện

Hãy đi sâu vào lĩnh vực chủ đề một chút và suy nghĩ về thiết kế cơ sở dữ liệu bằng cách sử dụng thứ gì đó đơn giản như thư viện sách điển hình.

Nhiệm vụ chính của bất kỳ thư viện nào là xử lý quỹ sách. Có thể dễ dàng phân biệt ba nhóm người dùng hệ thống chính: độc giả, thủ thư, quản trị viên . Hoạt động của mỗi được thể hiện trong một sơ đồ trường hợp sử dụng.

Hiện tại, một số thực thể và mối quan hệ của cơ sở dữ liệu trong tương lai có thể được phân biệt:

Với cách tiếp cận này, không rõ ràng làm thế nào để kết nối người đọc với cuốn sách (người đọc không có sự thống nhất trong mối quan hệ “phát hành / tiếp nhận”. Nếu cuốn sách có nhiều bản, nó có thể được phát hành cho nhiều người đọc. Thậm chí nếu một cuốn sách được hiểu là một bản, thì khi được lưu trong bảng sách của người đọc hiện tại, sẽ không thể biết được thông tin về ai (và bao nhiêu lần) đã lấy cuốn sách này trước đó.

Giải pháp có thể là giới thiệu một thực thể bổ sung - thẻ phát hành sách. Khi cuốn sách được cấp cho người đọc, một thẻ được tạo và khi cuốn sách được bàn giao, một dấu tương ứng sẽ được dán lên đó. Với sự trợ giúp của các thẻ này, các khoản nợ của từng người dùng được xác định và tính toán số liệu thống kê về việc sử dụng sách. Khi người đọc đặt tài liệu, thẻ cũng được bắt đầu; nếu người đọc không lấy tài liệu đã đặt trong một khoảng thời gian nhất định, thẻ sẽ bị hủy. Có giới hạn về số lượng sách mà người đọc có thể đặt.

Khi chọn tài liệu, người dùng xem mục lục tài liệu với khả năng lọc kết quả tìm kiếm theo tác giả, tên sách, năm xuất bản.

Có thể tính toán số liệu thống kê cho tất cả các cuốn sách trong thư viện, trong khi số lượng bản sao của cuốn sách được phát hành trong một khoảng thời gian nhất định. Bạn cũng có thể đặt số lượng bản sao sách tối thiểu mà phép tính được thực hiện. Dựa trên những số liệu thống kê này, những cuốn sách không sử dụng sẽ bị xóa khỏi thư viện.

Các thực thể chính sau đây của lĩnh vực chủ đề có thể được phân biệt:

người dùng (thủ thư và quản trị viên);
người đọc;
phòng đọc;
sách;
thẻ cấp sổ;
đặt phiếu đặt phòng.

Sơ đồ ER đã sửa đổi của cơ sở dữ liệu được hiển thị trong hình.

Theo các trường hợp sử dụng được hiển thị trong Hình 1, cơ sở dữ liệu sẽ thực hiện các truy vấn sau (không phải là danh sách đầy đủ):

trưng bày sách phù hợp với điều kiện quy định;
hiển thị những người dùng có thẻ cấp sách chưa đóng đúng hạn (thủ thư đang tìm người nợ);
hiển thị tất cả các cuốn sách tương ứng với thẻ cho mượn sách của người dùng nhất định không được đóng kịp thời (người dùng đến thư viện để lấy sách mới - bạn cần xem anh ta có phải là con nợ hay không và thông báo cho anh ta về điều đó);
xóa tất cả các thẻ đặt phòng được tạo hơn N giây trước;
hiển thị tất cả các cuốn sách tương ứng với thẻ đặt sách chưa được đóng của người dùng được chỉ định (bạn đọc đặt sách và đến thư viện lấy - thủ thư cần lấy danh sách này để cấp phát).

1.3 Sơ đồ hình thành

Để tạo một lược đồ dữ liệu, trước tiên bạn phải bổ sung sơ đồ ER với các chi tiết của các thực thể (tinh chỉnh nó). Đôi khi, đồng thời, có thể tìm thấy lỗi trong việc xây dựng sơ đồ ER - trong nhiệm vụ này, người ta thấy rằng cuốn sách cần được kết nối “bằng cách nào đó” với sảnh thư viện.

Điều này có thể được thực hiện bằng cách đặt "số phòng" cần thiết vào cuốn sách, tuy nhiên, với cách tiếp cận này, cùng một cuốn sách sẽ phải được mô tả nhiều lần trong cơ sở dữ liệu (nếu nó xuất hiện ở các phòng khác nhau). Một cách tiếp cận chính xác hơn là giới thiệu một thực thể bổ sung "đặt sách". Hình này cho thấy một sơ đồ ER với một thực thể và đạo cụ được thêm vào.

Sơ đồ ER ở trên phản ánh các bảng chính, các mối quan hệ và thuộc tính; trên cơ sở đó, bạn có thể xây dựng một mô hình cơ sở dữ liệu. Không có tiêu chuẩn cho sơ đồ ER, nhưng có một số ký hiệu (Chen, IDEFIX, Martin, v.v.), nhưng không thể tìm thấy tiêu chuẩn cũng như ký hiệu cho mô hình miền. Tuy nhiên, trong quá trình xây dựng sơ đồ như vậy, các trường chính (bên ngoài và bên trong) nhất thiết phải được đánh dấu, đôi khi là chỉ mục và loại dữ liệu.

Trong trường hợp này, trong sơ đồ sau:

đối với các liên kết, ký hiệu của Martin ("vết chân chim" được sử dụng);
các bảng được hiển thị dưới dạng hình chữ nhật được chia thành 3 phần:

bảng tên;
các khóa bên trong (được đánh dấu bằng bút đánh dấu);
các trường còn lại, trong khi các trường bắt buộc được đánh dấu bằng điểm đánh dấu.

Khi phát triển mô hình này, có một mong muốn tham gia bảng quản trị viên với bảng thủ thư - tuy nhiên, hãy thêm bảng người dùng:

quản trị viên không được liên kết với một phòng cụ thể (bạn sẽ phải điền vào trường tương ứng các giá trị null);
điều này có thể sẽ làm phức tạp việc phân phối quyền truy cập - hiện chỉ quản trị viên cơ sở dữ liệu (người làm việc thông qua bảng DBMS đặc biệt và không có tài khoản trong hệ thống đang được phát triển) mới có quyền truy cập vào bảng quản trị viên. Tuy nhiên, khi tham gia các bảng, các truy vấn của người dùng sẽ yêu cầu quyền truy cập vào bảng mới.

Khi xây dựng sơ đồ này, một lỗ hổng trong sơ đồ ER đã được tìm thấy và sửa chữa - một bảng đã được thêm vào librarians_roomsđể hợp nhất các thủ thư và hội trường. Điều này là cần thiết vì một thủ thư có thể làm việc trong nhiều phòng, nhưng nhiều thủ thư có thể làm việc trong cùng một phòng.

Khi thiết kế cơ sở dữ liệu, ít nhất bạn phải có khả năng suy luận như ví dụ trên. Nếu bạn nghĩ rằng mình đã thành công, hãy tiến xa hơn: thậm chí nhiều lý thuyết hơn.