Thực đơn
trang chủTừ

Ví dụ thiết kế cơ sở dữ liệu Đại học bang Amur. Các bước thiết kế cơ sở dữ liệu

Khi phát triển cơ sở dữ liệu, có thể phân biệt các giai đoạn công việc sau.

Giai đoạn I. Xây dựng vấn đề.

Ở giai đoạn này, một nhiệm vụ tạo cơ sở dữ liệu được tạo ra. Nó mô tả chi tiết thành phần của cơ sở dữ liệu, mục đích và mục đích tạo ra nó, đồng thời liệt kê các loại công việc sẽ được thực hiện trong cơ sở dữ liệu này (lựa chọn, bổ sung, thay đổi dữ liệu, in hoặc xuất báo cáo, v.v.). ).

Giai đoạn II. Phân tích đối tượng.

Ở giai đoạn này, chúng tôi xem xét cơ sở dữ liệu có thể bao gồm những đối tượng nào và thuộc tính của những đối tượng này là gì. Sau khi chia cơ sở dữ liệu thành đồ vật riêng lẻ cần phải xem xét các thuộc tính của từng đối tượng này, hay nói cách khác là thiết lập các tham số mà mỗi đối tượng được mô tả. Tất cả thông tin này có thể được sắp xếp dưới dạng các bản ghi và bảng riêng biệt. Tiếp theo, chúng ta cần xem xét kiểu dữ liệu của từng đơn vị bản ghi riêng lẻ. Thông tin về các loại dữ liệu cũng phải được đưa vào bảng bạn tạo.

Giai đoạn III. Tổng hợp mô hình.

Ở giai đoạn này, theo phân tích ở trên cần phải lựa chọn một mô hình nhất địnhĐB. Tiếp theo, những ưu, nhược điểm của từng mô hình được xem xét và so sánh với yêu cầu, mục tiêu của cơ sở dữ liệu đang được tạo ra. Sau khi phân tích như vậy, một mô hình được chọn có thể đảm bảo tốt nhất việc thực hiện nhiệm vụ. Sau khi chọn mô hình, bạn cần vẽ sơ đồ của nó biểu thị mối quan hệ giữa các bảng hoặc nút.

Giai đoạn IV. Lựa chọn phương pháp trình bày thông tin và công cụ phần mềm.

Sau khi tạo mô hình, tùy theo sản phẩm phần mềm được chọn, cần xác định hình thức trình bày thông tin.

Trong hầu hết các DBMS, dữ liệu có thể được lưu trữ theo hai loại:

  • sử dụng các hình thức;
  • mà không sử dụng các hình thức.

Hình thứcđược người dùng tạo GUIđể nhập dữ liệu vào cơ sở dữ liệu.

Giai đoạn V. tổng hợp mô hình máy tính sự vật.

Trong quá trình tạo mô hình máy tính, có một số giai đoạn điển hình cho bất kỳ DBMS nào.

Giai đoạn 1. Khởi chạy DBMS, tạo tệp cơ sở dữ liệu mới hoặc mở cơ sở dữ liệu đã tạo trước đó.

Giai đoạn 2. Tạo bảng hoặc các bảng ban đầu.

Khi tạo bảng nguồn, bạn phải chỉ định tên và loại của từng trường. Tên trường không được lặp lại trong cùng một bảng. Trong khi làm việc với cơ sở dữ liệu, bạn có thể thêm các trường mới vào bảng. Bảng đã tạo phải được lưu và đặt tên duy nhất trong cơ sở dữ liệu đang được tạo.

1. Thông tin trong bảng không được trùng lặp. Không nên có sự lặp lại giữa các bảng. Khi một số thông tin nhất định chỉ được lưu trữ trong một bảng thì nó sẽ chỉ phải thay đổi ở một nơi. Điều này giúp công việc hiệu quả hơn và cũng loại bỏ khả năng thông tin không khớp giữa các bảng khác nhauỒ. Ví dụ: một bảng phải chứa địa chỉ và số điện thoại của khách hàng.

2. Mỗi bảng chỉ nên chứa thông tin về một chủ đề. Thông tin về từng chủ đề sẽ dễ xử lý hơn nhiều nếu nó được chứa trong các bảng độc lập với nhau. Ví dụ, tốt hơn nên lưu trữ địa chỉ và đơn đặt hàng của khách hàng trong các bảng khác nhau để khi xóa đơn hàng, thông tin về khách hàng vẫn còn trong cơ sở dữ liệu.

3. Mỗi bảng phải chứa các trường bắt buộc. Mỗi trường trong bảng phải chứa thông tin riêng biệt về chủ đề của bảng. Ví dụ: bảng dữ liệu khách hàng có thể chứa các trường tên công ty, địa chỉ, thành phố, quốc gia và số điện thoại. Khi thiết kế các trường cho mỗi bảng, bạn cần nhớ rằng mỗi trường phải liên quan đến chủ đề của bảng. Không nên đưa dữ liệu vào bảng là kết quả của một biểu thức. Bảng phải chứa tất cả thông tin cần thiết. Thông tin phải được chia thành các đơn vị logic nhỏ nhất (Ví dụ: trường Tên và Họ, thay vì trường Tên chung).

4. Cơ sở dữ liệu phải có khóa chính. Điều này là cần thiết để DBMS có thể liên kết dữ liệu từ các bảng khác nhau, ví dụ: dữ liệu khách hàng và đơn đặt hàng của họ.

Giai đoạn 3. Tạo các hình thức màn hình.

Ban đầu, bạn cần chỉ định bảng trên cơ sở biểu mẫu sẽ được tạo. Bạn có thể tạo nó bằng cách sử dụng trình hướng dẫn biểu mẫu, chỉ định loại nó phải có hoặc bạn có thể tự tạo nó. Khi tạo biểu mẫu, bạn có thể chỉ định không phải tất cả các trường mà bảng chứa mà chỉ một số trường trong số đó. Tên của biểu mẫu có thể giống với tên của bảng nơi nó được tạo. Dựa trên một bảng, bạn có thể tạo một số biểu mẫu, có thể khác nhau về loại hoặc số lượng trường được sử dụng từ bảng này. Sau khi tạo biểu mẫu, bạn phải lưu nó. Biểu mẫu đã tạo có thể được chỉnh sửa bằng cách thay đổi vị trí, kích thước và định dạng của các trường.

Giai đoạn 4.Điền vào cơ sở dữ liệu.

Quá trình điền cơ sở dữ liệu có thể được thực hiện dưới hai hình thức: dưới dạng bảng và dưới dạng biểu mẫu. Số và Trường văn bản có thể được điền vào dưới dạng bảng và các trường như MEMO và OLE - dưới dạng biểu mẫu.

Giai đoạn VI. Làm việc với cơ sở dữ liệu đã tạo.

Làm việc với cơ sở dữ liệu bao gồm các hành động sau:

  • tìm kiếm thông tin cần thiết;
  • sắp xếp dữ liệu;
  • lựa chọn dữ liệu;
  • in ấn;
  • thay đổi và thêm dữ liệu.

Bản chất của thiết kế cơ sở dữ liệu, giống như bất kỳ quy trình thiết kế nào khác, là tạo ra một mô tả về một hệ thống mới chưa tồn tại trước đây ở dạng này, mà khi được triển khai sẽ có khả năng hoạt động như mong đợi trong các điều kiện thích hợp. Từ đó, các giai đoạn thiết kế cơ sở dữ liệu phải phản ánh một cách nhất quán và logic bản chất của quy trình này.

Nội dung thiết kế cơ sở dữ liệu và phân kỳ

Mục đích thiết kế dựa trên một số nhu cầu xã hội được hình thành. Nhu cầu này có môi trường để nó xuất hiện và đối tượng mục tiêu là người tiêu dùng sẽ sử dụng kết quả thiết kế. Do đó, quá trình thiết kế cơ sở dữ liệu bắt đầu bằng việc nghiên cứu một nhu cầu nhất định từ quan điểm của người tiêu dùng và môi trường chức năng của vị trí dự kiến. Nghĩa là, giai đoạn đầu tiên là thu thập thông tin và xác định mô hình lĩnh vực chủ đề của hệ thống, cũng như xem xét nó từ quan điểm khán giả mục tiêu. Nhìn chung, để xác định yêu cầu hệ thống, người ta xác định phạm vi hoạt động cũng như ranh giới của các ứng dụng cơ sở dữ liệu.

Tiếp theo, nhà thiết kế, người đã có những ý tưởng nhất định về những gì anh ta cần tạo, làm rõ các nhiệm vụ được cho là do ứng dụng giải quyết, tạo danh sách chúng (đặc biệt nếu phát triển dự án là một cơ sở dữ liệu lớn và phức tạp), làm rõ trình tự giải quyết vấn đề và thực hiện phân tích dữ liệu. Quá trình này cũng là một quá trình từng bước. dự án công việc, nhưng thông thường trong cấu trúc thiết kế, các bước này được hấp thụ bởi giai đoạn thiết kế khái niệm - giai đoạn xác định đối tượng, thuộc tính và kết nối.

Tạo ra khái niệm ( mô hình thông tin) liên quan đến việc hình thành sơ bộ các yêu cầu khái niệm của người dùng, bao gồm các yêu cầu đối với các ứng dụng có thể chưa được triển khai ngay lập tức nhưng có tính đến việc sẽ cải thiện chức năng của hệ thống trong tương lai. Xử lý các biểu diễn của các đối tượng trừu tượng tập hợp (không chỉ định các phương thức lưu trữ vật lý) và các mối quan hệ của chúng, mô hình khái niệm về cơ bản tương ứng với mô hình miền. Vì vậy, trong tài liệu, giai đoạn đầu tiên của thiết kế cơ sở dữ liệu được gọi là thiết kế thông tin.

Tiếp theo, một giai đoạn riêng biệt (hoặc bổ sung cho giai đoạn trước) tiếp theo giai đoạn hình thành các yêu cầu đối với môi trường vận hành, trong đó các yêu cầu về tài nguyên máy tính có khả năng đảm bảo hoạt động của hệ thống được đánh giá. Theo đó, dung lượng cơ sở dữ liệu được thiết kế càng lớn thì hoạt động của người dùng và cường độ yêu cầu càng cao thì yêu cầu về tài nguyên càng cao: về cấu hình máy tính, về chủng loại và phiên bản. hệ điều hành. Ví dụ: chế độ hoạt động nhiều người dùng của cơ sở dữ liệu trong tương lai yêu cầu Kết nối mạng sử dụng hệ điều hành phù hợp cho đa nhiệm.

Bước tiếp theo là người thiết kế chọn hệ thống quản lý cơ sở dữ liệu (DBMS), cũng như các công cụ phần mềm. Sau đó, mô hình khái niệm phải được chuyển sang mô hình dữ liệu tương thích với hệ thống quản lý đã chọn. Nhưng thông thường, điều này liên quan đến việc thực hiện các sửa đổi và thay đổi đối với mô hình khái niệm, vì các mối liên kết giữa các đối tượng được phản ánh trong mô hình khái niệm không phải lúc nào cũng được thực hiện bằng cách sử dụng các phương tiện của một DBMS nhất định.

Tình huống này quyết định sự xuất hiện của giai đoạn tiếp theo - sự xuất hiện của một DBMS cụ thể được cung cấp các công cụ mô hình khái niệm. Bước này tương ứng với giai đoạn thiết kế logic (tạo mô hình logic).

Cuối cùng, giai đoạn cuối cùng của thiết kế cơ sở dữ liệu là thiết kế vật lý - giai đoạn liên kết cấu trúc logic và môi trường lưu trữ vật lý.

Vì vậy, các giai đoạn chính của thiết kế ở dạng chi tiết được trình bày theo các giai đoạn sau:

  • thiết kế thông tin,
  • Xây dựng các yêu cầu về môi trường hoạt động
  • lựa chọn hệ thống điều khiển và phần mềmĐB,
  • thiết kế logic,
  • thiết kế vật lí

Những điều quan trọng sẽ được thảo luận chi tiết hơn dưới đây.

Thiết kế thông tin

Việc xác định các thực thể tạo thành cơ sở ngữ nghĩa của thiết kế thông tin. Một thực thể ở đây là một đối tượng (trừu tượng hoặc cụ thể), thông tin về đối tượng đó sẽ được tích lũy trong hệ thống. Trong mô hình thông tin của lĩnh vực chủ đề trong thân thiện với người dùng về mặt không phụ thuộc vào việc triển khai cụ thể của cơ sở dữ liệu, cấu trúc và thuộc tính động của lĩnh vực chủ đề sẽ được mô tả. Nhưng các điều khoản được thực hiện trên một thang đo tiêu chuẩn. Nghĩa là, sự mô tả được thể hiện không phải thông qua các đối tượng riêng lẻ của lĩnh vực chủ đề và các mối quan hệ của chúng, mà thông qua:

  • mô tả các loại đối tượng,
  • ràng buộc toàn vẹn liên quan đến loại được mô tả,
  • các quá trình dẫn đến sự phát triển của một lĩnh vực chủ đề - sự chuyển đổi của nó sang trạng thái khác.

Một mô hình thông tin có thể được tạo bằng một số phương pháp và cách tiếp cận:

  1. Cách tiếp cận chức năng dựa trên các nhiệm vụ được giao. Nó được gọi là chức năng vì nó được sử dụng nếu các chức năng và nhiệm vụ của những người, với sự trợ giúp của cơ sở dữ liệu được thiết kế, sẽ phục vụ họ. nhu cầu thông tin.
  2. Cách tiếp cận chủ đề tập trung vào thông tin về thông tin sẽ có trong cơ sở dữ liệu, mặc dù thực tế là cấu trúc truy vấn có thể không được xác định. Trong trường hợp này, nghiên cứu về một lĩnh vực chủ đề tập trung vào việc hiển thị đầy đủ nhất nó trong cơ sở dữ liệu trong bối cảnh có đầy đủ các yêu cầu thông tin dự kiến.
  3. Một cách tiếp cận tích hợp sử dụng phương pháp “mối quan hệ thực thể” kết hợp những ưu điểm của hai phương pháp trước. Phương pháp này bao gồm việc chia toàn bộ khu vực chủ đề thành các phần cục bộ, được mô hình hóa riêng biệt và sau đó kết hợp lại thành toàn bộ khu vực.

Vì việc sử dụng phương pháp mối quan hệ thực thể là một phương pháp thiết kế kết hợp cho ở giai đoạn này, nó trở thành ưu tiên thường xuyên hơn những thứ khác.

Khi được phân chia một cách có phương pháp, nếu có thể, các đại diện địa phương nên bao gồm thông tin đủ để giải quyết một vấn đề riêng biệt hoặc đáp ứng yêu cầu của một nhóm người dùng tiềm năng nhất định. Mỗi khu vực này chứa khoảng 6-7 thực thể và tương ứng với một ứng dụng bên ngoài riêng biệt.

Sự phụ thuộc của các thực thể được thể hiện ở việc phân chia chúng thành mạnh (cơ sở, cha mẹ) và yếu (con). Một thực thể mạnh (ví dụ: một trình đọc trong thư viện) có thể tự tồn tại trong cơ sở dữ liệu, nhưng một thực thể yếu (ví dụ: đăng ký của trình đọc này) được “gắn liền” với một thực thể mạnh và không tồn tại riêng biệt.

Cần tách biệt khái niệm “thể hiện thực thể” (đối tượng được đặc trưng bởi các giá trị thuộc tính cụ thể) và khái niệm “kiểu thực thể” - đối tượng mà nó mang tính chất đặc trưng. tên gọi chung và một danh sách các thuộc tính.

Đối với mỗi thực thể riêng lẻ, các thuộc tính (một tập hợp thuộc tính) được chọn, tùy thuộc vào tiêu chí, có thể là:

  • xác định (với một giá trị duy nhất cho các thực thể thuộc loại đó, biến chúng thành các khóa tiềm năng) hoặc mô tả;
  • giá trị đơn hoặc đa giá trị (với số lượng giá trị thích hợp cho một thể hiện thực thể);
  • cơ bản (độc lập với các thuộc tính khác) hoặc dẫn xuất (được tính dựa trên giá trị của các thuộc tính khác);
  • đơn giản (một thành phần không thể chia cắt) hoặc hỗn hợp (kết hợp từ nhiều thành phần).

Sau đó, thuộc tính được chỉ định, các kết nối được chỉ định trong chế độ xem cục bộ (được chia thành tùy chọn và bắt buộc) và các chế độ xem cục bộ được hợp nhất. Nếu số lượng khu vực cục bộ lên tới 4-5, chúng có thể được kết hợp trong một bước . Nếu số lượng tăng lên, việc hợp nhất nhị phân các khu vực sẽ diễn ra theo nhiều giai đoạn.

Trong giai đoạn này và các giai đoạn trung gian khác, bản chất lặp lại của thiết kế được phản ánh, điều này được thể hiện ở đây ở chỗ để loại bỏ mâu thuẫn, cần quay lại giai đoạn mô hình hóa các biểu diễn cục bộ để làm rõ và thay đổi (ví dụ: thay đổi cùng tên của các đối tượng khác nhau về mặt ngữ nghĩa hoặc để phối hợp các thuộc tính toàn vẹn trên cùng các thuộc tính trong các ứng dụng khác nhau).

Lựa chọn hệ thống điều khiển và phần mềm cơ sở dữ liệu

Việc lựa chọn hệ quản trị cơ sở dữ liệu phụ thuộc vào triển khai thực tế hệ thống thông tin. Các tiêu chí quan trọng nhất trong quá trình lựa chọn là các thông số sau:

  • loại mô hình dữ liệu và sự phù hợp của nó với nhu cầu của lĩnh vực chủ đề,
  • dự trữ các khả năng trong trường hợp mở rộng hệ thống thông tin,
  • đặc tính hiệu suất của hệ thống được lựa chọn,
  • độ tin cậy hoạt động và sự thuận tiện của DBMS,
  • công cụ dành cho nhân viên quản trị dữ liệu,
  • chi phí của chính DBMS và phần mềm bổ sung.

Những sai sót trong việc lựa chọn DBMS gần như chắc chắn sẽ dẫn đến nhu cầu điều chỉnh các mô hình khái niệm và logic.

Thiết kế cơ sở dữ liệu logic

Cấu trúc logic của cơ sở dữ liệu phải tương ứng với mô hình logic của lĩnh vực chủ đề và tính đến sự kết nối của mô hình dữ liệu với DBMS được hỗ trợ. Do đó, giai đoạn bắt đầu bằng việc chọn một mô hình dữ liệu, trong đó điều quan trọng là phải tính đến tính đơn giản và rõ ràng của nó.

Sẽ thích hợp hơn khi cấu trúc dữ liệu tự nhiên trùng khớp với mô hình đại diện cho nó. Vì vậy, ví dụ, nếu dữ liệu được trình bày dưới dạng cấu trúc phân cấp thì tốt hơn nên chọn mô hình phân cấp. Tuy nhiên, trong thực tế, sự lựa chọn như vậy thường được xác định bởi hệ thống quản lý cơ sở dữ liệu hơn là bởi mô hình dữ liệu. Do đó, mô hình khái niệm thực sự được chuyển thành mô hình dữ liệu tương thích với hệ thống quản lý cơ sở dữ liệu đã chọn.

Điều này cũng phản ánh bản chất của thiết kế, cho phép khả năng (hoặc sự cần thiết) quay trở lại mô hình khái niệm để thay đổi nó nếu mối quan hệ giữa các đối tượng (hoặc thuộc tính đối tượng) được phản ánh ở đó không thể được triển khai bằng cách sử dụng DBMS đã chọn.

Sau khi hoàn thành giai đoạn này, các lược đồ cơ sở dữ liệu của cả hai cấp độ kiến ​​trúc (khái niệm và bên ngoài) sẽ được tạo ra, được tạo bằng ngôn ngữ định nghĩa dữ liệu được DBMS đã chọn hỗ trợ.

Các lược đồ cơ sở dữ liệu được hình thành bằng một trong hai cách tiếp cận khác nhau:

  • hoặc sử dụng cách tiếp cận từ dưới lên, khi công việc được thực hiện từ mức thấp xác định các thuộc tính được nhóm thành các mối quan hệ biểu diễn các đối tượng dựa trên các mối quan hệ tồn tại giữa các thuộc tính;
  • hoặc sử dụng cách tiếp cận ngược, từ trên xuống, được sử dụng khi số lượng thuộc tính tăng lên đáng kể (lên tới hàng trăm và hàng nghìn).

Cách tiếp cận thứ hai liên quan đến việc xác định một số thực thể cấp cao và mối quan hệ của chúng với các chi tiết tiếp theo đến mức yêu cầu, ví dụ, được phản ánh trong một mô hình được tạo dựa trên phương pháp “mối quan hệ thực thể”. Nhưng trong thực tế, cả hai phương pháp này thường được kết hợp với nhau.

Thiết kế cơ sở dữ liệu vật lý

Ở giai đoạn tiếp theo của thiết kế vật lý của cơ sở dữ liệu, cấu trúc logic được hiển thị dưới dạng cấu trúc lưu trữ cơ sở dữ liệu, nghĩa là nó được liên kết với môi trường lưu trữ vật lý nơi dữ liệu sẽ được đặt hiệu quả nhất có thể. Ở đây lược đồ dữ liệu được mô tả chi tiết, cho biết tất cả các loại, trường, kích thước và hạn chế. Ngoài việc phát triển các chỉ mục và bảng, các truy vấn cơ bản cũng được xác định.

Việc xây dựng một mô hình vật lý liên quan đến việc giải quyết các vấn đề trái ngược nhau:

  1. nhiệm vụ giảm thiểu không gian lưu trữ dữ liệu,
  2. những thách thức để đạt được tính toàn vẹn, bảo mật và hiệu suất tối đa.

Nhiệm vụ thứ hai xung đột với nhiệm vụ đầu tiên vì, ví dụ:

  • để các giao dịch hoạt động hiệu quả, bạn cần dành dung lượng đĩa cho các đối tượng tạm thời,
  • để tăng tốc độ tìm kiếm, bạn cần tạo các chỉ mục, số lượng chỉ mục được xác định bởi số lượng tất cả các tổ hợp trường có thể có liên quan đến tìm kiếm,
  • để phục hồi dữ liệu sẽ được tạo bản sao lưu cơ sở dữ liệu và ghi lại tất cả các thay đổi.

Tất cả điều này làm tăng kích thước của cơ sở dữ liệu, do đó, nhà thiết kế đang tìm kiếm sự cân bằng hợp lý trong đó các vấn đề được giải quyết một cách tối ưu bằng cách đặt dữ liệu một cách thông minh vào không gian bộ nhớ nhưng không gây tổn hại đến bảo mật cơ sở dữ liệu, bao gồm cả bảo vệ khỏi truy cập trái phép và bảo vệ từ những thất bại.

Để hoàn thành việc tạo mô hình vật lý, các đặc tính hoạt động của nó được đánh giá (tốc độ tìm kiếm, hiệu quả thực hiện truy vấn và mức tiêu thụ tài nguyên, tính chính xác của hoạt động). Đôi khi giai đoạn này, giống như các giai đoạn triển khai, thử nghiệm và tối ưu hóa cơ sở dữ liệu, cũng như bảo trì và vận hành, được đưa ra ngoài thiết kế trực tiếp của cơ sở dữ liệu.

Bài giảng 8. Các giai đoạn thiết kế cơ sở dữ liệu

Không thể tạo cơ sở dữ liệu mà không có mô tả chi tiết về nó, cũng như không thể tạo ra bất kỳ sản phẩm phức tạp nào nếu không có bản vẽ và mô tả chi tiết về công nghệ sản xuất nó. Nói cách khác, chúng ta cần một dự án. Dự án Người ta thường chấp nhận xem xét bản phác thảo của một số thiết bị, sau này sẽ được chuyển thành hiện thực.

Quá trình thiết kế cơ sở dữ liệu là một quá trình chuyển đổi từ mô tả bằng lời nói không chính thức cấu trúc thông tin lĩnh vực chủ đề để mô tả chính thức các đối tượng của khu vực chủ đề theo một mô hình nhất định. Mục tiêu cuối cùng của thiết kế là xây dựng một cơ sở dữ liệu cụ thể. Rõ ràng, quá trình thiết kế rất phức tạp và do đó, việc chia nó thành các phần - giai đoạn hoàn thiện một cách hợp lý là điều hợp lý.

Có năm giai đoạn chính của thiết kế cơ sở dữ liệu:

1. Thu thập thông tin và phân tích hệ thống của lĩnh vực chủ đề.

2. Thiết kế thông tin.

3. Lựa chọn một DBMS.

4. Thiết kế dữ liệu.

5. Thiết kế vật lí.

Thu thập thông tin và phân tích hệ thống của lĩnh vực chủ đề - đây là lần đầu tiên và giai đoạn quan trọng nhất khi thiết kế cơ sở dữ liệu. Cần phải thực hiện mô tả chi tiết bằng lời nói về các đối tượng của lĩnh vực chủ đề và các mối liên hệ thực tế giữa các đối tượng thực tế. Điều mong muốn là phần mô tả xác định được mối quan hệ giữa các đối tượng trong lĩnh vực chủ đề.

TRONG trường hợp chung Có hai cách tiếp cận để lựa chọn thành phần và cấu trúc của một lĩnh vực chủ đề:

· Cách tiếp cận chức năng – được sử dụng khi các chức năng của một nhóm người nhất định và các nhóm nhiệm vụ mà cơ sở dữ liệu này được tạo ra đã được biết trước, tức là. tối thiểu có thể nhìn thấy rõ ràng bộ cần thiếtđối tượng của lĩnh vực chủ đề để mô tả.

· Cách tiếp cận chủ đề – khi nhu cầu thông tin của cơ sở dữ liệu khách hàng không được ghi lại rõ ràng và có thể mang tính đa chiều, năng động. TRONG trong trường hợp này đặt tối thiểu Rất khó để chọn các đối tượng miền. Mô tả lĩnh vực chủ đề bao gồm các đối tượng và mối quan hệ đặc trưng và cần thiết nhất cho lĩnh vực đó. Đồng thời, cơ sở dữ liệu trở nên chuyên biệt theo chủ đề và phù hợp để giải quyết nhiều vấn đề (có vẻ hấp dẫn nhất). Tuy nhiên, khó khăn trong việc bao quát toàn bộ lĩnh vực chủ đề và không thể xác định rõ nhu cầu của người dùng dẫn đến sự dư thừa. sơ đồ phức tạp Một cơ sở dữ liệu sẽ không hiệu quả đối với một số nhiệm vụ.

Phân tích hệ thống phải kết thúc miêu tả cụ thể thông tin về các đối tượng của lĩnh vực chủ đề cần được lưu trữ trong cơ sở dữ liệu với công thức nhiệm vụ cụ thể, vấn đề này sẽ được giải quyết bằng cơ sở dữ liệu này với mô tả ngắn gọn các thuật toán cho giải pháp của mình, mô tả các tài liệu đầu ra và đầu vào khi làm việc với cơ sở dữ liệu.

Thiết kế thông tin – mô tả chính thức hóa một phần các đối tượng trong lĩnh vực chủ đề theo một mô hình ngữ nghĩa nhất định.

Tại sao cần có mô hình thông tin và nó mang lại lợi ích gì cho các nhà thiết kế? Thực tế là quá trình thiết kế kéo dài và đòi hỏi phải thảo luận với khách hàng và các chuyên gia về chủ đề đó. Ngoài ra, khi phát triển doanh nghiệp nghiêm túc hệ thông thông tin dự án cơ sở dữ liệu là nền tảng để xây dựng toàn bộ hệ thống và câu hỏi về khả năng cho vay thường được các chuyên gia ngân hàng quyết định trên cơ sở một dự án cơ sở dữ liệu thông tin được xây dựng tốt. Do đó, mô hình thông tin nên bao gồm một mô tả chính thức về lĩnh vực chủ đề mà không chỉ các chuyên gia cơ sở dữ liệu sẽ dễ dàng nhận ra. Mô tả phải đầy đủ để người ta có thể đánh giá độ sâu và tính chính xác của quá trình phát triển dự án cơ sở dữ liệu.

Ngày nay, mô hình được sử dụng rộng rãi nhất là mô hình “Mối quan hệ mật thiết” của Chen ( Mối quan hệ thực thể ), nó đã trở thành tiêu chuẩn thực tế trong mô hình hóa thông tin và được gọi là ER – mô hình.

Chọn một DBMS được thực hiện trên cơ sở các yêu cầu khác nhau đối với cơ sở dữ liệu và theo đó là khả năng của DBMS, cũng như tùy thuộc vào kinh nghiệm hiện có của các nhà phát triển.

Thiết kế dữ liệu có mô tả cơ sở dữ liệu theo mô hình dữ liệu logic dữ liệu được chấp nhận. Trong cơ sở dữ liệu quan hệ, thiết kế logic hoặc dữ liệu dẫn đến sự phát triển của lược đồ cơ sở dữ liệu, tức là. tập hợp các sơ đồ mối quan hệ mô hình hóa đầy đủ các đối tượng của lĩnh vực chủ đề và các mối quan hệ ngữ nghĩa giữa các đối tượng. Cơ sở để phân tích tính đúng đắn của mạch điện là phụ thuộc chức năng giữa các thuộc tính cơ sở dữ liệu. Trong một số trường hợp, sự phụ thuộc không mong muốn có thể xuất hiện giữa các thuộc tính mối quan hệ, gây ra tác dụng phụ và bất thường khi sửa đổi cơ sở dữ liệu. Dưới sửa đổi hiểu việc thêm dữ liệu mới vào cơ sở dữ liệu, xóa dữ liệu khỏi cơ sở dữ liệu cũng như cập nhật giá trị của một số thuộc tính. Để loại bỏ những bất thường có thể xảy ra, người ta lên kế hoạch bình thường hóa các mối quan hệ cơ sở dữ liệu.

Giai đoạn thiết kế logic không chỉ là thiết kế sơ đồ quan hệ. Kết quả của giai đoạn này, theo quy định, phải thu được các tài liệu kết quả sau:

· Mô tả lược đồ khái niệm của cơ sở dữ liệu theo DBMS đã chọn.

· Sự miêu tả mô hình bên ngoài về DBMS đã chọn.

· Mô tả các quy tắc khai báo để duy trì tính toàn vẹn của cơ sở dữ liệu.

· Phát triển các thủ tục để duy trì tính toàn vẹn ngữ nghĩa của cơ sở dữ liệu.

Thiết kế vật lí bao gồm việc liên kết cấu trúc logic của cơ sở dữ liệu và môi trường lưu trữ vật lý để đặt dữ liệu một cách hiệu quả nhất, tức là. ánh xạ cấu trúc logic của cơ sở dữ liệu vào cấu trúc lưu trữ. Vấn đề đặt dữ liệu được lưu trữ trong không gian bộ nhớ, chọn phương pháp hiệu quả truy cập vào Các thành phần khác nhau cơ sở dữ liệu “vật lý”, các vấn đề được giải quyếtđảm bảo an toàn, bảo mật dữ liệu.Các ràng buộc trong mô hình dữ liệu logic được triển khai bằng nhiều cách khác nhau Ví dụ, DBMS sử dụng các chỉ mục, các ràng buộc toàn vẹn khai báo, các trình kích hoạt, các thủ tục được lưu trữ. Đồng thời, một lần nữa, các quyết định được đưa ra ở cấp độ mô hình hóa logic xác định một số ranh giới trong đó có thể phát triển mô hình vật lý dữ liệu. Tương tự như vậy, trong những ranh giới này người ta có thể chấp nhận giải pháp khác nhau. Ví dụ: các mối quan hệ có trong mô hình dữ liệu logic phải chuyển thành bảng nhưng với mỗi bảng bạn có thể khai báo thêm chỉ số khác nhau, tăng tốc độ truy cập dữ liệu.

Bên cạnh đó , các tính năng có thể được sử dụng để cải thiện hiệu suất tiến trình song song dữ liệu. Kết quả là cơ sở dữ liệu có thể được đặt trên một số mạng máy tính. Mặt khác, những ưu điểm của hệ thống đa bộ xử lý có thể được sử dụng.

Để đảm bảo an toàn, bảo mật dữ liệu, các vấn đề về khôi phục sau lỗi được giải quyết, Dự trữ bản sao thông tin, thiết lập hệ thống bảo vệ phù hợp với chính sách bảo mật đã chọn, v.v.

Cần lưu ý rằng một số hiện đại cơ sở dữ liệu quan hệ chủ yếu sử dụng các cấu trúc vật lý và phương pháp truy cập dựa trên công nghệ thiết kế tệp, về cơ bản loại bỏ vấn đề về thiết kế vật lý.

Vì vậy, rõ ràng là các quyết định được đưa ra ở từng giai đoạn xây dựng mô hình và phát triển cơ sở dữ liệu sẽ ảnh hưởng đến các giai đoạn tiếp theo. Đó là lý do tại sao sự chấp nhận đóng một vai trò đặc biệt quyết định đúng đắn trong giai đoạn đầu của mô hình hóa.

Câu hỏi kiểm soát

1. Dự án là gì?

2. Những giai đoạn nào của thiết kế cơ sở dữ liệu thường được phân biệt?

3. Mục đích của việc phân tích hệ thống là gì?

4. Những phương pháp tiếp cận nào có thể được sử dụng trong phân tích hệ thống của một lĩnh vực chủ đề?

5. Giai đoạn thiết kế thông tin là gì?

6. Sự khác biệt giữa các giai đoạn thiết kế thông tin và dữ liệu là gì?

7. Cần có những tài liệu và mô hình nào khi hoàn thành giai đoạn thiết kế khoa học dữ liệu?

8. Nêu kết quả thiết kế vật lý.

Nhiệm vụ cho làm việc độc lập

Đọc kỹ phần mô tả miền mẫu và xác định những điểm chính nào được xác định trong phần mô tả và điểm nào có thể không. Đi đến kết luận.

Ví dụ về mô tả lĩnh vực chủ đề của dự án “Thư viện”

Giả sử bạn cần phát triển một hệ thống thông tin để tự động hóa việc hạch toán nhận và xuất sách trong thư viện. Hệ thống phải cung cấp các phương thức để duy trì danh mục hệ thống phản ánh danh sách các lĩnh vực kiến ​​thức có sách trong thư viện. Trong thư viện, các lĩnh vực kiến ​​thức trong danh mục hệ thống có thể có một địa chỉ duy nhất số mở rộng và tên đầy đủ. Mỗi cuốn sách có thể chứa thông tin từ một số lĩnh vực kiến ​​thức. Mỗi cuốn sách trong thư viện có thể có nhiều bản. Mỗi cuốn sách được lưu trữ trong thư viện được đặc trưng bởi các tham số sau:

· mật mã duy nhất;

· Tên;

· nơi xuất bản (thành phố);

· nhà xuất bản;

· năm xuất bản;

· số trang;

· giá của cuốn sách;

· số bản sao của một cuốn sách trong thư viện.

Sách có thể có cùng tên, nhưng chúng khác nhau ở mật mã duy nhất (ISBN).

Thư viện có duy trì danh mục thẻ độc giả.

Các thông tin sau được nhập vào mục lục thẻ cho mỗi đầu đọc:

· Họ và tên;

· địa chỉ nhà;

· Ngày sinh.

Mỗi độc giả được cấp một số thẻ thư viện duy nhất. Mỗi người đọc có thể giữ không quá 5 cuốn sách cùng một lúc. Người đọc không nên giữ nhiều bản sao của một cuốn sách cùng tên cùng một lúc.

Mỗi cuốn sách trong thư viện có thể có nhiều bản. Mỗi trường hợp có các đặc điểm sau:

· số hàng tồn kho duy nhất;

· mật mã sách, khớp với mật mã duy nhất trong mô tả sách;

· vị trí trong thư viện.

Nếu một bản sao của một cuốn sách được cấp cho độc giả, thư viện sẽ giữ một tờ phụ trang đặc biệt trong đó phải ghi lại các thông tin sau:

· số vé của người đọc đã lấy sách;

· ngày phát hành cuốn sách;

· ngày trở lại.

Cung cấp những hạn chế sau về thông tin trong hệ thống:

2. Thư viện phải có độc giả đăng ký từ 17 tuổi trở lên.

3. Thư viện chứa những cuốn sách được xuất bản từ năm 1960 đến nay.

4. Mỗi đầu đọc được chứa không quá 5 cuốn sách.

5. Khi đăng ký tại thư viện, mỗi độc giả phải cung cấp số điện thoại để liên lạc: có thể là cơ quan hoặc nhà riêng.

6. Mỗi lĩnh vực kiến ​​thức có thể tham khảo nhiều sách, nhưng mỗi cuốn sách có thể tham khảo khu vực khác nhau kiến thức.

Phải làm việc với hệ thống thông tin này các nhóm sau người dùng:

· thủ thư;

· độc giả;

· quản trị thư viện,

Khi làm việc với hệ thống, thủ thư cần có khả năng giải quyết các nhiệm vụ sau:

1. Nhận sách mới và đăng ký vào thư viện.

2. Phân bổ sách theo một hoặc nhiều lĩnh vực kiến ​​thức.

3. Sách danh mục, nghĩa là ấn định số lượng tồn kho mới cho những cuốn sách mới được chấp nhận và đặt chúng trên kệ thư viện, ghi nhớ vị trí của mỗi bản sao.

4. Tiến hành lập danh mục bổ sung nếu thư viện đã nhận được nhiều bản sao của một cuốn sách đã có trong khi thông tin về cuốn sách đó không được nhập vào danh mục chủ đề và mỗi bản sao mới được gán một số gia nhập mới và một vị trí trên kệ thư viện được gán cho nó.

5. Loại bỏ những cuốn sách cũ và không còn nhu cầu sử dụng. Chỉ có thể sao chép sách nếu người đọc không có một bản sao nào. Việc xóa sổ được thực hiện theo một đạo luật xóa sổ đặc biệt đã được ban quản lý thư viện phê duyệt.

6. Lưu giữ hồ sơ sách đã phát cho độc giả, trong trường hợp này giả định có hai phương thức hoạt động: phát sách cho độc giả và nhận sách do độc giả trả về thư viện. Khi phát hành sách, người ta ghi lại thời điểm và bản sao của cuốn sách được phát hành cho một độc giả nhất định và đến thời điểm nào người đọc phải trả lại bản sách này. Khi phát hành sách, sự sẵn có của một bản sao miễn phí và con số cụ thể có thể được xác định bằng mã sách duy nhất nhất định hoặc số lượng hàng tồn kho có thể được biết trước. Không cần thiết phải duy trì “lịch sử” đọc sách, tức là nó chỉ cần phản ánh hiện trạng của thư viện. Khi chấp nhận một cuốn sách được độc giả trả lại, số tồn kho được trả lại của cuốn sách sẽ được kiểm tra để khớp với số tồn kho đã phát hành và nó được đặt vào vị trí cũ trên kệ thư viện.

7. Xóa sổ sách mà người đọc bị thất lạc theo đạo luật xóa hoặc thay thế đặc biệt được ban quản lý thư viện ký.

8. Đóng đăng ký của người đọc, nghĩa là hủy dữ liệu về anh ta, nếu người đọc muốn ra khỏi thư viện và không phải là con nợ của nó, tức là anh ta không có một cuốn sách thư viện nào.

Người đọc có thể giải quyết các vấn đề sau:

1. Xem danh mục hệ thống, tức là danh sách tất cả các lĩnh vực kiến ​​thức về sách có trong thư viện.

2. Đối với lĩnh vực kiến ​​thức đã chọn, hãy lấy danh sách đầy đủ các cuốn sách có trong thư viện.

3. Đối với cuốn sách đã chọn, hãy lấy số tồn kho của bản sao sách miễn phí hoặc thông báo rằng không có bản sao miễn phí của cuốn sách đó. Nếu không có sẵn bản sao của một cuốn sách, người đọc có thể tìm ra ngày dự kiến ​​trả lại bản sao của cuốn sách này. Người đọc không thể tìm ra thông tin về người đã Hiện nay có sẵn các bản sao của cuốn sách này (để đảm bảo an toàn cá nhân cho những người nắm giữ cuốn sách được yêu cầu).

Ban quản lý thư viện phải có khả năng thu thập thông tin về những độc giả thư viện mắc nợ không trả sách đã mượn đúng hạn; thông tin về những cuốn sách không phổ biến, tức là không có một bản sao nào

không nằm trong tay độc giả; thông tin về giá của một cuốn sách cụ thể để xác định khả năng hoàn trả chi phí cho cuốn sách bị mất hoặc khả năng thay thế nó bằng một cuốn sách khác; thông tin về những cuốn sách phổ biến nhất, nghĩa là tất cả các bản sao của chúng đều nằm trong tay độc giả.

Cái này hoàn toàn ví dụ nhỏ cho thấy rằng trước khi bắt đầu phát triển, cần phải có ý tưởng chính xác về những gì nên được thực hiện trong hệ thống của chúng tôi, những gì người dùng sẽ làm trong đó, những nhiệm vụ mà mỗi người dùng sẽ giải quyết. Và điều này đúng, vì khi xây một tòa nhà, chúng ta cũng giả định trước; nó được dự định cho mục đích gì, nó sẽ tồn tại trong khí hậu nào, trên đất gì và tùy thuộc vào điều này, các nhà thiết kế có thể cung cấp cho chúng tôi dự án này hoặc dự án kia. Tuy nhiên, thật không may, rất thường xuyên liên quan đến cơ sở dữ liệu, người ta tin rằng mọi thứ có thể được xác định sau này, khi dự án hệ thống đã được tạo. Việc không có mục tiêu rõ ràng để tạo cơ sở dữ liệu có thể phủ nhận mọi nỗ lực của các nhà phát triển và dự án cơ sở dữ liệu sẽ trở nên “xấu”, bất tiện và không tương ứng với đối tượng thực tế đang được mô hình hóa hoặc các nhiệm vụ cần giải quyết. sử dụng cơ sở dữ liệu này.

Quá trình thiết kế cơ sở dữ liệu là một chuỗi các quá trình chuyển đổi từ mô tả bằng lời nói không chính thức về cấu trúc thông tin của một lĩnh vực chủ đề sang mô tả chính thức các đối tượng phần mềm theo một mô hình nhất định. Nói chung, có thể phân biệt các giai đoạn thiết kế sau:

TÔI. Phân tích hệ thống và mô tả bằng lời của các đối tượng thông tin phần mềm. Có hai cách tiếp cận để lựa chọn thành phần và cấu trúc của một lĩnh vực chủ đề:

· Cách tiếp cận chức năng. Nó thực hiện nguyên tắc di chuyển “từ các nhiệm vụ” và được sử dụng khi biết rõ chức năng của một nhóm người và nhóm nhiệm vụ nhất định, để phục vụ nhu cầu thông tin mà cơ sở dữ liệu được tạo ra. Trong trường hợp này, có thể xác định rõ ràng tập đối tượng tối thiểu cần thiết phải được mô tả.

· Cách tiếp cận chủ đề. Nhu cầu thông tin của người dùng trong tương lai không được cố định chặt chẽ. Không thể chọn được tập đối tượng tối thiểu cần mô tả. Trong trường hợp này, mô tả phần mềm bao gồm các đối tượng và mối quan hệ đặc trưng và cần thiết nhất cho nó. Cơ sở dữ liệu được thiết kế được gọi là cơ sở dữ liệu chủ đề và có thể được sử dụng cho nhiều nhiệm vụ khác nhau được xác định trước. Cách tiếp cận này có vẻ hứa hẹn nhất, nhưng nó có thể dẫn đến sự dư thừa trong nhiệm vụ hoặc nhu cầu của người dùng, mặt khác, nó phải tính đến khả năng phát triển các ứng dụng mới.

II. Thiết kế mô hình thông tin phần mềm. Nhiệm vụ của giai đoạn thiết kế thông tin là thu được các mô hình dữ liệu ngữ nghĩa (có ý nghĩa) (ví dụ: theo mô hình ER) hiển thị nội dung thông tin của phần mềm cụ thể. Đầu tiên, phần cần thiết của phần mềm được tách biệt khỏi thực tế được nhận thức, ranh giới của nó được xác định và các phần không quan trọng được trừu tượng hóa cho một ứng dụng cụ thể của cơ sở dữ liệu. Kết quả là, các đối tượng, thuộc tính và mối quan hệ của chúng được xác định sẽ có ý nghĩa quan trọng đối với người dùng hệ thống trong tương lai.

III. Thiết kế cơ sở dữ liệu logic hoặc dữ liệu, I E. mô tả cơ sở dữ liệu theo mô hình dữ liệu logic dữ liệu được chấp nhận (ví dụ: quan hệ). Nhiệm vụ của giai đoạn thiết kế logic là tổ chức dữ liệu được chọn ở giai đoạn trước thành dạng được chấp nhận trong DBMS cụ thể đã chọn, sử dụng các kiểu và mô hình dữ liệu của nó. Khuyến nghị được đưa ra để lựa chọn phương pháp truy cập dữ liệu.

IV. Thiết kế cơ sở dữ liệu vật lý, I E. chọn vị trí cơ sở dữ liệu hiệu quả trên phương tiện truyền thông bên ngoàiđể đảm bảo nhất công việc hiệu quả các ứng dụng. Nhiệm vụ của giai đoạn thiết kế vật lý là lựa chọn cấu trúc lưu trữ dữ liệu hợp lý. và các phương pháp truy cập chúng, dựa trên kho công cụ và phương pháp mà một DBMS cụ thể cung cấp cho nhà phát triển.

Khi thiết kế cơ sở dữ liệu, hai vấn đề chính được giải quyết:

    Làm cách nào để ánh xạ các đối tượng miền tới các đối tượng mô hình dữ liệu trừu tượng? Vấn đề này được gọi là vấn đề thiết kế cơ sở dữ liệu logic.

    Làm thế nào để đảm bảo thực hiện hiệu quả các truy vấn cơ sở dữ liệu, tức là. làm thế nào, hãy ghi nhớ các tính năng của một DBMS cụ thể, để sắp xếp dữ liệu theo bộ nhớ ngoài, nên tạo những cấu trúc bổ sung nào (ví dụ: chỉ mục), v.v.? Vấn đề này được gọi là vấn đề thiết kế cơ sở dữ liệu vật lý.

Trong trường hợp cơ sở dữ liệu quan hệ, rất khó để cung cấp bất kỳ công thức chung nào cho thiết kế vật lý. Ở đây có quá nhiều phụ thuộc vào DBMS được sử dụng. Do đó, chúng ta sẽ giới hạn ở các vấn đề về thiết kế logic của cơ sở dữ liệu quan hệ, những vấn đề cần thiết khi sử dụng bất kỳ DBMS quan hệ nào.

Hơn nữa, chúng ta sẽ không đề cập đến một khía cạnh rất quan trọng của thiết kế - định nghĩa về ràng buộc toàn vẹn (ngoại trừ ràng buộc khóa chính). Thực tế là khi sử dụng một DBMS với các cơ chế ràng buộc toàn vẹn được phát triển (ví dụ, các hệ thống hướng SQL), rất khó để đề xuất bất kỳ cách tiếp cận chung nào để xác định các ràng buộc toàn vẹn. Những hạn chế này có thể rất hình thức chung, và công thức của chúng cho đến nay liên quan nhiều đến lĩnh vực nghệ thuật hơn là kỹ năng kỹ thuật. Điều được đề xuất nhiều nhất về vấn đề này trong tài liệu là kiểm tra tự động tính nhất quán của một tập hợp các ràng buộc toàn vẹn.

    cơ sở dữ liệu nên bao gồm những mối quan hệ nào và

    mối quan hệ này nên có những thuộc tính gì?

Có ba cách tiếp cận chính để thiết kế cơ sở dữ liệu:

1. thu thập thông tin về các đối tượng của vấn đề đang được giải quyết trong một bảng và sự phân tách tiếp theo của nó thành một số bảng có liên quan với nhau dựa trên các quy trình chuẩn hóa ( phương pháp cổ điển);

2. chuyển đổi từ mô hình ngữ nghĩa (thông tin) của giai đoạn thứ hai bằng cách sử dụng các công cụ CASE sang sơ đồ làm sẵn DB hoặc thậm chí là hệ thống thông tin ứng dụng (IS) được tạo sẵn;

3. Cấu trúc thông tin để sử dụng trong hệ thống thông tin trong quá trình phân tích hệ thống dựa trên bộ quy tắc và khuyến nghị thực tế.

Đầu tiên, chúng ta sẽ xem xét cách tiếp cận cổ điển, trong đó toàn bộ quá trình thiết kế được thực hiện theo mô hình dữ liệu quan hệ bằng phương pháp xấp xỉ liên tiếp với một tập hợp các mẫu quan hệ thỏa đáng. Điểm bắt đầu là biểu diễn phần mềm dưới dạng một hoặc nhiều quan hệ và ở mỗi bước thiết kế, một tập hợp sơ đồ quan hệ nhất định với các đặc tính tốt nhất sẽ được tạo ra. Quá trình thiết kế là một quá trình bình thường hóa các mẫu quan hệ, trong đó mỗi dạng chuẩn tiếp theo có các đặc tính tốt hơn dạng chuẩn trước đó.

Trong lý thuyết về cơ sở dữ liệu quan hệ, chuỗi các dạng chuẩn thường sau đây thường được phân biệt:

    dạng bình thường đầu tiên (1NF);

    dạng chuẩn thứ hai (2NF);

    dạng chuẩn thứ ba (3NF);

    dạng chuẩn Boyce-Codd (BCNF);

    dạng bình thường thứ tư (4NF);

    dạng chuẩn thứ năm (5NF hoặc PJ/NF).

Các tính chất cơ bản của dạng chuẩn:

    mỗi dạng chuẩn tiếp theo theo một nghĩa nào đó đều tốt hơn dạng trước đó;

    khi chuyển sang phần tiếp theo dạng bình thường các thuộc tính của các thuộc tính bình thường trước đó được bảo tồn.

Quá trình thiết kế dựa trên phương pháp chuẩn hóa, phân hủy một quan hệ được tìm thấy ở dạng chuẩn trước đó thành hai hoặc nhiều quan hệ thỏa mãn các yêu cầu của dạng chuẩn tiếp theo.

Các dạng quan hệ chuẩn tắc quan trọng nhất trong thực tế đều dựa trên khái niệm cơ bản trong lý thuyết cơ sở dữ liệu quan hệ. sự phụ thuộc chức năng. Để thảo luận thêm, chúng ta sẽ cần một số định nghĩa.

Định nghĩa 1. Sự phụ thuộc chức năng

Đối với R, thuộc tính Y phụ thuộc chức năng vào thuộc tính X (X và Y có thể là hỗn hợp) khi và chỉ khi mỗi giá trị của X tương ứng với chính xác một giá trị của Y: R.X ->R.Y.

Định nghĩa 2 . Phụ thuộc đầy đủ chức năng

Sự phụ thuộc hàm R.X ->R.Y được gọi là đầy đủ nếu thuộc tính Y không phụ thuộc hàm vào bất kỳ tập con chính xác nào của X.

Định nghĩa 3. Sự phụ thuộc chức năng bắc cầu

Một phụ thuộc hàm R.X -> R.Y được gọi là bắc cầu nếu có thuộc tính Z sao cho có các phụ thuộc hàm R.X -> R.Z và R.Z -> R.Y và không có phụ thuộc hàm R.Z ---> R.X.

Định nghĩa 4. Thuộc tính không khóa

Thuộc tính không khóa là bất kỳ thuộc tính nào của mối quan hệ không phải là một phần của khóa chính (cụ thể là khóa chính).

Định nghĩa 5 . Thuộc tính độc lập lẫn nhau

Hai hoặc nhiều thuộc tính độc lập lẫn nhau nếu không có thuộc tính nào phụ thuộc chức năng vào các thuộc tính khác.

Bởi vì Yêu cầu của dạng chuẩn đầu tiên là yêu cầu cơ bản của mô hình quan hệ cổ điển dữ liệu, chúng tôi sẽ giả định rằng tập hợp các mối quan hệ ban đầu đã đáp ứng yêu cầu này, tức là. tất cả các thuộc tính là nguyên tử. Nếu bảng chứa các thuộc tính ghép thì bạn có thể chuyển đổi nó thành 1NF bằng cách sử dụng Thuật toán chuẩn hóa do E. Codd đề xuất:

    bắt đầu từ bảng nguồn, lấy khóa chính của nó và thêm nó vào từng bảng con (thuộc tính tổng hợp);

    Khóa chính của mỗi bảng mở rộng bao gồm khóa chính của bảng con và khóa chính cha được thêm vào;

    sau đó, tất cả các thuộc tính không đơn giản sẽ bị xóa khỏi bảng cha và quy trình này được lặp lại cho từng bảng phụ;

    điều kiện để kết thúc thuật toán là tính nguyên tử của tất cả các thuộc tính.

Ví dụ 5.1 Hãy coi một tổ chức nào đó thực hiện một số dự án là một lĩnh vực chủ đề. Chúng tôi mô tả mô hình miền trong văn bản không chính thức sau:

    Nhân viên của tổ chức thực hiện các dự án.

    Các dự án bao gồm một số nhiệm vụ.

    Mỗi nhân viên có thể tham gia một hoặc nhiều dự án hoặc tạm thời không tham gia bất kỳ dự án nào.

    Một số nhân viên có thể làm việc trên mỗi dự án hoặc dự án có thể tạm dừng và không có nhân viên nào làm việc trên đó.

    Chính xác một nhân viên làm việc trên mỗi nhiệm vụ trong dự án.

    Mỗi nhân viên được đăng ký ở một bộ phận.

    Mỗi nhân viên có một điện thoại đặt tại phòng của nhân viên.

Trong quá trình làm rõ thêm những dữ liệu nào cần được tính đến, những điều sau đã trở nên rõ ràng:

    Mỗi nhân viên phải có mã số nhân sự. Mã số nhân sự của mỗi nhân viên là duy nhất.

    Mỗi khoa có một số duy nhất.

    Mỗi dự án có một số. Số dự án là duy nhất.

    Mỗi nhiệm vụ trong dự án có một số duy nhất trong dự án.

Hãy tưởng tượng một sơ đồ mối quan hệ (tất cả thông tin trong một bảng):

NHÂN VIÊN-Bộ phận-DỰ ÁN

(COTR_NUMBER, COTR_ZARP, DEPARTMENT_NUMBER, PRO_NUMBER, COTR_SET)

Khóa chính:

COTR_NUMBER, PRO_NUMBER

Phụ thuộc chức năng:

COTR_NUMBER -> COTR_ZARP

COTR_NUMBER -> DEPARTMENT_NUMBER

DEPARTMENT_NUMBER -> SOTR_ZARP

COTR_NUMBER, PRO_NUMBER -> COTR_JOB

Như bạn có thể thấy, mặc dù khóa chính là thuộc tính tổng hợp COTR_NUMBER, PRO_NUMBER, nhưng các thuộc tính COTR_ZARP và STD_NUMBER phụ thuộc về mặt chức năng vào một phần của khóa chính, thuộc tính COTR_NUMBER. Do đó, chúng ta sẽ không thể chèn vào mối quan hệ NHÂN VIÊN-BỘ PHẬN-DỰ ÁN một bộ dữ liệu mô tả một nhân viên chưa làm việc trong bất kỳ dự án nào (khóa chính không được chứa giá trị null). Khi xóa một bộ dữ liệu, chúng tôi không chỉ phá hủy kết nối của nhân viên này với dự án này mà còn mất thông tin rằng anh ta làm việc trong một bộ phận nhất định. Khi chuyển một nhân viên sang bộ phận khác, chúng ta sẽ buộc phải sửa đổi tất cả các bộ dữ liệu mô tả nhân viên này, nếu không chúng ta sẽ nhận được kết quả không nhất quán. Hiện tượng khó chịu như vậy được gọi là sự bất thường các sơ đồ quan hệ. Chúng được loại bỏ thông qua bình thường hóa.

Định nghĩa 6 . Dạng bình thường thứ hai(định nghĩa này giả định rằng khóa duy nhất của mối quan hệ là khóa chính)

Mối quan hệ R ở dạng chuẩn thứ hai (2NF) khi và chỉ nếu nó ở dạng 1NF và mọi thuộc tính không khóa đều hoàn toàn phụ thuộc vào khóa chính.

Bạn có thể phân tách mối quan hệ NHÂN VIÊN-BỘ PHẬN-DỰ ÁN sau đây thành hai mối quan hệ NHÂN VIÊN-BỘ PHẬN và NHÂN VIÊN-DỰ ÁN:

NHÂN VIÊN-BỘ PHẬN (COTR_NUMBER, COTR_SARP, DEPARTMENT_NUMBER)

Khóa chính:

COTR_NUMBER

Phụ thuộc chức năng:

COTR_NUMBER -> COTR_ZARP

COTR_NUMBER -> DEPARTMENT_NUMBER

DEPARTMENT_NUMBER -> SOTR_ZARP

Khóa chính:

COTR_NUMBER, PRO_NUMBER

Phụ thuộc chức năng:

COTR_NUMBER, PRO_NUMBER -> COTR_SET

Mỗi mối quan hệ trong số hai mối quan hệ này đều ở dạng 2NF và chúng loại bỏ các điểm bất thường đã nêu ở trên (dễ dàng xác minh rằng tất cả các hoạt động được chỉ định đều được thực hiện mà không gặp vấn đề gì).

Chúng ta hãy nhìn lại mối quan hệ NHÂN VIÊN-BỘ PHẬN được tìm thấy trong 2NF. Lưu ý rằng sự phụ thuộc hàm SOTR_NUMBER -> SOTR_ZARP có tính bắc cầu; đó là hệ quả của sự phụ thuộc chức năng SOTR_NUMBER -> OTD_NUMBER và OTD_NUMBER -> SOTR_ZARP. Nói cách khác, mức lương của một nhân viên thực sự không phải là đặc điểm của nhân viên đó mà là đặc điểm của bộ phận nơi anh ta làm việc (đây không phải là một giả định quá tự nhiên, nhưng đủ cho ví dụ).

Do đó, chúng tôi sẽ không thể nhập thông tin mô tả mức lương của một bộ phận vào cơ sở dữ liệu cho đến khi có ít nhất một nhân viên xuất hiện trong bộ phận này (khóa chính không được chứa giá trị không xác định). Nếu chúng ta xóa bộ mô tả nhân viên cuối cùng của một bộ phận nhất định, chúng ta sẽ mất thông tin về lương của bộ phận đó. Để thay đổi mức lương của phòng ban một cách nhất quán, trước tiên chúng ta phải tìm tất cả các bộ dữ liệu mô tả nhân viên của phòng ban đó. Những thứ kia. Vẫn còn những bất thường về BỘ PHẬN NHÂN VIÊN. Những điều này có thể được loại bỏ thông qua việc bình thường hóa hơn nữa.

Định nghĩa 7. Dạng bình thường thứ ba(Định nghĩa được đưa ra giả định sự tồn tại của một khóa duy nhất.)

Mối quan hệ R ở dạng chuẩn thứ ba (3NF) khi và chỉ khi nó ở dạng 2NF và mỗi thuộc tính không khóa không phụ thuộc bắc cầu vào khóa chính.

Có thể phân tách mối quan hệ NHÂN VIÊN-BỘ PHẬN thành hai mối quan hệ NHÂN VIÊN và BỘ PHẬN:

NHÂN VIÊN (JOB_NUMBER, DEPARTMENT_NUMBER)

Khóa chính:

COTR_NUMBER

Phụ thuộc chức năng:

COTR_NUMBER -> DEPARTMENT_NUMBER

CÁC BỘ PHẬN (DEPARTMENT_NUMBER, COTR_ZARP)

Khóa chính:

DTD_NUMBER

Phụ thuộc chức năng:

DEPARTMENT_NUMBER -> SOTR_ZARP

Mỗi mối quan hệ trong số hai mối quan hệ này đều ở dạng 3NF và không có các điểm bất thường được ghi nhận.

Nếu chúng ta loại bỏ ràng buộc rằng một quan hệ có một khóa duy nhất thì định nghĩa 3NF sẽ có dạng sau:

Định nghĩa 7*

Một quan hệ R ở dạng chuẩn thứ ba (3NF) khi và chỉ nếu nó ở dạng chuẩn 2NF và mỗi thuộc tính không khóa không phụ thuộc bắc cầu vào bất kỳ khóa nào của R.

Trong thực tế, dạng sơ đồ quan hệ chuẩn thứ ba là đủ trong hầu hết các trường hợp và bằng cách giảm xuống dạng chuẩn thứ ba trong quá trình thiết kế. cơ sở quan hệ dữ liệu thường hết.

Tuy nhiên, đôi khi việc tiếp tục quá trình bình thường hóa sẽ rất hữu ích.

Ví dụ 5.2 Hãy xem xét ví dụ sau về sơ đồ mối quan hệ:

NHÂN VIÊN-DỰ ÁN (JOB_NUMBER, JOB_NAME, PRO_NUMBER, JOB_TASK)

Các phím có thể có:

COTR_NUMBER, PRO_NUMBER

COTR_NAME, PRO_NUMBER

Phụ thuộc chức năng:

COTR_NUMBER -> COTR_NAME

COTR_NUMBER -> PRO_NUMBER

CORR_NAME -> CORR_NUMBER

SOTR_NAME -> PRO_NUMBER

COTR_NUMBER, PRO_NUMBER -> COTR_SET

COTR_NAME, PRO_NUMBER -> COTR_JOB

Trong ví dụ này, chúng tôi giả định rằng danh tính của một nhân viên hoàn toàn được xác định bởi cả mã số và tên của họ (một lần nữa, đây không phải là một giả định thực tế lắm, nhưng nó đủ tốt cho ví dụ này).

Theo định nghĩa 7*, mối quan hệ NHÂN VIÊN-DỰ ÁN nằm trong 3NF. Tuy nhiên, thực tế là có sự phụ thuộc chức năng của các thuộc tính quan hệ vào một thuộc tính là một phần của khóa chính dẫn đến sự bất thường. Ví dụ: để thay đổi tên của một nhân viên bằng một số cho trước một cách nhất quán, chúng ta cần sửa đổi tất cả các bộ dữ liệu có chứa số của anh ta.

Định nghĩa 8. Bản ngã

Yếu tố quyết định là bất kỳ thuộc tính nào mà một số thuộc tính khác phụ thuộc đầy đủ về mặt chức năng.

Định nghĩa 9 . Dạng Boyce-Codd bình thường

Quan hệ R ở dạng chuẩn Boyce-Codd (BCNF) khi và chỉ khi mỗi định thức là một khóa khả dĩ.

Rõ ràng, yêu cầu này không được đáp ứng đối với mối quan hệ NHÂN VIÊN-DỰ ÁN. Bạn có thể phân tách nó thành các mối quan hệ NHÂN VIÊN và NHÂN VIÊN-DỰ ÁN:

NHÂN VIÊN (CORPORATE_NUMBER, CORPORATE_NAME)

Các phím có thể có:

COTR_NUMBER

Phụ thuộc chức năng:

COTR_NUMBER -> COTR_NAME

COTR_NAME -> COTR_NUMBER

NHÂN VIÊN-DỰ ÁN (COTR_NUMBER, PRO_NUMBER, COTR_TASK)

Chìa khóa có thể:

COTR_NUMBER, PRO_NUMBER

Phụ thuộc chức năng:

COTR_NUMBER, PRO_NUMBER -> COTR_SET

Có thể phân tách thay thế nếu bạn chọn SOTR_NAME làm cơ sở. Trong cả hai trường hợp, mối quan hệ NHÂN VIÊN và NHÂN VIÊN-DỰ ÁN thu được đều ở BCNF và không biểu hiện những điểm bất thường đã lưu ý.

Ví dụ 5.3 Hãy xem xét một ví dụ về sơ đồ mối quan hệ sau:

DỰ ÁN (PRO_NUMBER, PRO_SOTR, PRO_TASKED)

Mối quan hệ DỰ ÁN chứa số dự án, cho mỗi dự án một danh sách nhân viên có thể thực hiện dự án và danh sách các nhiệm vụ do dự án cung cấp. Nhân viên có thể tham gia vào nhiều dự án và các dự án khác nhau có thể liên quan đến cùng một nhiệm vụ.

Mỗi bộ quan hệ liên kết một dự án với một nhân viên tham gia vào dự án đó và một nhiệm vụ mà nhân viên đó thực hiện như một phần của dự án đó (chúng tôi giả định rằng bất kỳ nhân viên nào tham gia vào dự án đều thực hiện tất cả các nhiệm vụ cho dự án đó). Do các điều kiện được xây dựng ở trên, khóa quan hệ duy nhất có thể có là thuộc tính tổng hợp PRO_NUMBER, PRO_COTR, ​​​​PRO_SET và không có yếu tố quyết định nào khác. Do đó, mối quan hệ DỰ ÁN nằm trong BCNF. Nhưng đồng thời, nó cũng có nhược điểm: chẳng hạn, nếu một nhân viên tham gia một dự án nhất định, thì cần phải chèn bao nhiêu bộ dữ liệu vào quan hệ DỰ ÁN cũng như số nhiệm vụ trong đó.

Định nghĩa 10 . Phụ thuộc đa giá trị

Trong quan hệ R(A,B,C) tồn tại sự phụ thuộc nhiều giá trị R.A -> -> R.B khi và chỉ khi tập giá trị B tương ứng với một cặp giá trị A và C chỉ phụ thuộc vào A và không không phụ thuộc vào C.

Liên quan đến DỰ ÁN, tồn tại hai sự phụ thuộc đa giá trị sau:

PRO_NUMBER -> -> PRO_COTR

PRO_NUMBER -> -> PRO_SET

Dễ dàng chứng minh rằng trong trường hợp tổng quát, trong quan hệ R(A,B,C) tồn tại sự phụ thuộc nhiều giá trị R.A -> -> R.B khi và chỉ khi có sự phụ thuộc nhiều giá trị R.A -> -> RC

Việc bình thường hóa hơn nữa các quan hệ tương tự như quan hệ DỰ ÁN dựa trên định lý sau:

Định lý Fagin

Mối quan hệ R(A,B,C) có thể được chiếu mà không bị mất vào các quan hệ R1(A,B) và R2(A,C) khi và chỉ khi MVD A -> -> B | C.

Phép chiếu không mất mát đề cập đến một phương pháp phân rã quan hệ trong đó quan hệ ban đầu được khôi phục hoàn toàn và không có sự dư thừa bằng cách kết nối tự nhiên của các quan hệ kết quả.

Định nghĩa 11 . Dạng bình thường thứ tư

Một quan hệ R ở dạng chuẩn 4 (4NF) khi và chỉ khi, với sự tồn tại của một phụ thuộc đa giá trị A -> -> B, tất cả các thuộc tính khác của R đều phụ thuộc hàm vào A.

Trong ví dụ của chúng ta, chúng ta có thể phân tách mối quan hệ DỰ ÁN thành hai mối quan hệ DỰ ÁN-NHÂN VIÊN và DỰ ÁN-NHIỆM VỤ:

DỰ ÁN-HỢP TÁC (PRO_NUMBER, PRO_COTR)

DỰ ÁN-NHIỆM VỤ (PRO_NUMBER, PRO_TASK)

Cả hai tỷ lệ này đều ở mức 4NF và không có các điểm bất thường được ghi nhận.

Trong tất cả các chuẩn hóa được xem xét cho đến thời điểm này, việc phân rã một quan hệ thành hai đã được thực hiện. Đôi khi điều này không thể thực hiện được mà phải phân hủy thành số lớn hơn các mối quan hệ, mỗi mối quan hệ đều có những đặc tính tốt nhất.

Ví dụ 5.4 Ví dụ, hãy xem xét mối quan hệ

NHÂN VIÊN-BỘ PHẬN-DỰ ÁN (JOB_NUMBER, DEPARTMENT_NUMBER, PRO_NUMBER)

Giả sử rằng cùng một nhân viên có thể làm việc ở nhiều phòng ban và thực hiện nhiều dự án ở mỗi phòng ban. Khóa chính của mối quan hệ này là tập hợp đầy đủ các thuộc tính của nó; không có sự phụ thuộc chức năng hoặc đa giá trị.

Do đó mối quan hệ là ở 4NF. Tuy nhiên, có thể có những bất thường trong đó có thể được loại bỏ bằng cách phân tách thành ba mối quan hệ.

Định nghĩa 12. Phụ thuộc kết nối

Quan hệ R (X, Y, ..., Z) thỏa mãn phụ thuộc kết nối * (X, Y, ..., Z) khi và chỉ nếu R được khôi phục không mất mát bằng cách kết nối các hình chiếu của nó trên X, Y, .. ., Z.

Định nghĩa 13 . Dạng bình thường thứ năm

Một mối quan hệ R ở dạng chuẩn thứ năm (dạng chuẩn tắc chiếu-nối - PJ/NF) khi và chỉ khi bất kỳ sự phụ thuộc nối nào trong R xuất phát từ sự tồn tại của một số khóa có thể có trong R.

Hãy nhập tên sau đây của các thuộc tính tổng hợp:

CO = (COTR_NUMBER, DEPARTMENT_NUMBER)

SP = (COTR_NUMBER, PRO_NUMBER)

OP = (DEPARTMENT_NUMBER, PRO_NUMBER)

Giả sử có sự phụ thuộc kết hợp trong mối quan hệ NHÂN VIÊN-BỘ PHẬN-DỰ ÁN:

* (SO, SP, OP)

Có thể dễ dàng chỉ ra bằng các ví dụ rằng các vấn đề có thể phát sinh khi chèn và xóa các bộ dữ liệu. Chúng có thể được loại bỏ bằng cách phân tách mối quan hệ ban đầu thành ba mối quan hệ mới:

NHÂN VIÊN-BỘ PHẬN (JOB_NUMBER, DEPARTMENT_NUMBER)

NHÂN VIÊN-DỰ ÁN (EMPLOYEE_NUMBER, PRO_NUMBER)

SỞ-DỰ ÁN (DEPARTMENT_NUMBER, PRO_NUMBER)

Dạng chuẩn thứ năm là dạng chuẩn cuối cùng có thể thu được bằng cách phân rã. Các điều kiện của nó khá không tầm thường và trong thực tế, 5NF không được sử dụng. Lưu ý rằng phần phụ thuộc nối là sự khái quát hóa của cả phần phụ thuộc đa giá trị và phần phụ thuộc hàm.

Bình luận . Nếu các mối quan hệ không được bình thường hóa thì vấn đề sẽ nảy sinh sự dư thừa, sự không nhất quán tiềm tàng (các dị thường cập nhật), các dị thường về bao gồm, các bất thường về xóa.

Chủ đề: các giai đoạn thiết kế cơ sở dữ liệu, thiết kế cơ sở dữ liệu dựa trên mô hình kiểu quan hệ đối tượng.

Trước khi tạo cơ sở dữ liệu, nhà phát triển phải xác định cơ sở dữ liệu nên bao gồm những bảng nào, dữ liệu nào cần được đặt trong mỗi bảng và cách liên kết các bảng. Những vấn đề này được giải quyết ở giai đoạn thiết kế cơ sở dữ liệu.

Do quá trình thiết kế, cấu trúc logic của cơ sở dữ liệu phải được xác định, tức là thành phần của các bảng quan hệ, cấu trúc của chúng và các mối quan hệ giữa các bảng.

Trước khi tạo cơ sở dữ liệu, cần có bản mô tả về lĩnh vực chủ đề đã chọn, bao gồm các đối tượng và quy trình thực, xác định tất cả các nguồn thông tin cần thiết để đáp ứng các yêu cầu dự kiến ​​của người dùng và xác định nhu cầu xử lý dữ liệu.

Dựa trên mô tả như vậy, ở giai đoạn thiết kế cơ sở dữ liệu, thành phần và cấu trúc của dữ liệu lĩnh vực chủ đề được xác định, dữ liệu này phải có trong cơ sở dữ liệu và đảm bảo thực hiện các truy vấn cần thiết và nhiệm vụ của người dùng. Cấu trúc dữ liệu của lĩnh vực chủ đề có thể được hiển thị bằng mô hình logic thông tin. Dựa trên mô hình này, cơ sở dữ liệu quan hệ có thể được tạo dễ dàng.

Các giai đoạn thiết kế và tạo cơ sở dữ liệu được xác định theo trình tự sau:

Xây dựng mô hình dữ liệu logic thông tin của môn học;

Xác định cấu trúc logic của cơ sở dữ liệu quan hệ;

Thiết kế các bảng cơ sở dữ liệu;

Tạo lược đồ dữ liệu;

Nhập dữ liệu vào bảng (tạo bản ghi);

Phát triển các biểu mẫu, truy vấn, macro, mô-đun, báo cáo cần thiết;

Phát triển giao diện người dùng.

Trong quá trình phát triển mô hình dữ liệu, cần lựa chọn các đối tượng thông tin đáp ứng yêu cầu chuẩn hóa dữ liệu và xác định mối quan hệ giữa chúng. Mô hình này cho phép bạn tạo cơ sở dữ liệu quan hệ mà không bị trùng lặp, đảm bảo rằng dữ liệu chỉ được nhập một lần. tải xuống ban đầu và điều chỉnh cũng như tính toàn vẹn của dữ liệu khi thực hiện thay đổi.

Khi phát triển mô hình dữ liệu, có thể sử dụng hai cách tiếp cận. Trong cách tiếp cận đầu tiênĐầu tiên, các nhiệm vụ chính được xác định cho giải pháp mà cơ sở được xây dựng, nhu cầu dữ liệu của các nhiệm vụ được xác định và thành phần, cấu trúc được xác định tương ứng. đối tượng thông tin. Ở cách tiếp cận thứ hai Các đối tượng điển hình của lĩnh vực chủ đề sẽ được cài đặt ngay lập tức. Sự kết hợp hợp lý nhất của cả hai phương pháp. Điều này là do thực tế là ở giai đoạn đầu, theo quy luật, không có thông tin toàn diện về tất cả các nhiệm vụ. Việc sử dụng công nghệ như vậy càng hợp lý hơn vì các công cụ linh hoạt để tạo cơ sở dữ liệu quan hệ cho phép bạn thực hiện các thay đổi đối với cơ sở dữ liệu và sửa đổi cấu trúc của nó ở bất kỳ giai đoạn phát triển nào mà không làm hỏng dữ liệu đã nhập trước đó.


Quá trình xác định các đối tượng thông tin của lĩnh vực chủ đề đáp ứng các yêu cầu chuẩn hóa có thể được thực hiện trên cơ sở cách tiếp cận trực quan hoặc hình thức. Cơ sở lý thuyết Phương pháp tiếp cận hình thức được phát triển và trình bày đầy đủ trong các chuyên khảo về tổ chức cơ sở dữ liệu của nhà khoa học nổi tiếng người Mỹ J. Martin.

Với cách tiếp cận trực quan, các đối tượng thông tin tương ứng với các đối tượng thực có thể dễ dàng được xác định. Tuy nhiên, mô hình logic thông tin thu được, như một quy luật, đòi hỏi những biến đổi sâu hơn, đặc biệt là chuyển đổi các mối quan hệ đa giá trị giữa các đối tượng. Với cách tiếp cận này, có thể xảy ra lỗi nghiêm trọng nếu không có đủ kinh nghiệm. Việc xác minh sau đó về việc tuân thủ các yêu cầu chuẩn hóa thường cho thấy sự cần thiết phải làm rõ các đối tượng thông tin.

Hãy xem xét các quy tắc chính thức có thể được sử dụng để làm nổi bật các đối tượng thông tin:

Dựa trên mô tả lĩnh vực chủ đề, xác định các tài liệu và thuộc tính của chúng sẽ được lưu trữ trong cơ sở dữ liệu;

Xác định sự phụ thuộc chức năng giữa các thuộc tính;

Chọn tất cả các thuộc tính phụ thuộc và chỉ ra cho mỗi thuộc tính chính của nó, tức là những thuộc tính mà nó phụ thuộc vào;

Các thuộc tính nhóm phụ thuộc như nhau vào các thuộc tính chính. Các nhóm thuộc tính phụ thuộc kết quả, cùng với các thuộc tính chính của chúng, tạo thành các đối tượng thông tin.

Khi xác định cấu trúc logic của cơ sở dữ liệu quan hệ dựa trên mô hình, mỗi đối tượng thông tin được biểu diễn đầy đủ bằng một bảng quan hệ và các mối quan hệ giữa các bảng tương ứng với mối quan hệ giữa các đối tượng thông tin.

Trong quá trình tạo, các bảng cơ sở dữ liệu tương ứng với các đối tượng thông tin của mô hình dữ liệu được xây dựng sẽ được xây dựng đầu tiên. Tiếp theo, một lược đồ dữ liệu có thể được tạo trong đó các kết nối logic hiện có giữa các bảng được ghi lại. Những kết nối này tương ứng với các kết nối của các đối tượng thông tin. Lược đồ dữ liệu có thể được cấu hình để duy trì tính toàn vẹn của cơ sở dữ liệu nếu mô hình dữ liệu được thiết kế để đáp ứng các yêu cầu chuẩn hóa. Tính toàn vẹn dữ liệu có nghĩa là cơ sở dữ liệu đã thiết lập và duy trì chính xác mối quan hệ giữa các bản ghi của các bảng khác nhau khi tải, thêm và xóa các bản ghi trong các bảng liên quan cũng như khi thay đổi giá trị của các trường khóa.

Sau khi lược đồ dữ liệu được hình thành, dữ liệu nhất quán từ các tài liệu thuộc lĩnh vực chủ đề sẽ được nhập vào.

Dựa trên cơ sở dữ liệu đã tạo, các truy vấn, biểu mẫu, macro, mô-đun, báo cáo cần thiết được tạo ra để thực hiện việc xử lý dữ liệu cơ sở dữ liệu cần thiết và cách trình bày của chúng.

Sử dụng các công cụ và công cụ cơ sở dữ liệu tích hợp, cơ sở dữ liệu được tạo giao diện người dùng, cho phép bạn quản lý các quá trình nhập, lưu trữ, xử lý, cập nhật và trình bày thông tin cơ sở dữ liệu.

Thiết kế cơ sở dữ liệu dựa trên mô hình quan hệ đối tượng

Có sẵn toàn bộ dòng kỹ thuật tạo ra thông tin và mô hình logic. Một trong những phương pháp phổ biến nhất hiện nay để phát triển mô hình là sử dụng ERD (Sơ đồ mối quan hệ thực thể). Trong văn học tiếng Nga, những sơ đồ này được gọi là “đối tượng - mối quan hệ” hoặc “bản chất - kết nối”. Mô hình ERD được Peter Ping Shen Chen đề xuất vào năm 1976. Cho đến nay, một số biến thể đã được phát triển, nhưng tất cả chúng đều dựa trên biểu đồ đồ họa, do Chen đề xuất. Sơ đồ được xây dựng từ một số lượng nhỏ các thành phần. Do cách trình bày rõ ràng nên chúng được sử dụng rộng rãi trong các công cụ CASE (Kỹ thuật phần mềm hỗ trợ máy tính).

Chúng ta hãy xem xét thuật ngữ và ký hiệu được sử dụng.

thực thể- một đối tượng có thật hoặc tưởng tượng có ý nghĩa quan trọng đối với lĩnh vực chủ đề đang được xem xét, thông tin về đối tượng đó sẽ được lưu trữ.

Mỗi thực thể phải có một mã định danh duy nhất. Mỗi phiên bản của một thực thể phải được nhận dạng duy nhất và khác biệt với tất cả các phiên bản khác thuộc loại này(các thực thể).

Mỗi thực thể phải có những thuộc tính nhất định:

Có một cái tên duy nhất; Hơn nữa, cách giải thích tương tự (định nghĩa thực thể) phải luôn được áp dụng cho tên này. Và ngược lại: không thể áp dụng cách giải thích tương tự cho tên khác nhau, trừ khi chúng là bí danh;

Sở hữu một hoặc nhiều thuộc tính thuộc sở hữu của thực thể hoặc được kế thừa thông qua mối quan hệ;

Có một hoặc nhiều thuộc tính xác định duy nhất từng phiên bản của một thực thể.

Một thực thể có thể độc lập hoặc phụ thuộc. Dấu hiệu của thực thể phụ thuộc là sự hiện diện của các thuộc tính được kế thừa thông qua mối quan hệ (Hình 1.).

Mỗi thực thể có thể có số lượng kết nối bất kỳ với các thực thể khác trong mô hình.

Mối quan hệ- một liên kết được đặt tên giữa hai thực thể có ý nghĩa quan trọng đối với lĩnh vực chủ đề đang được xem xét. Một trong các thực thể tham gia vào mối quan hệ là độc lập, được gọi là thực thể cha, thực thể còn lại là thực thể phụ thuộc, được gọi là thực thể con hoặc thực thể con cháu. Thông thường, mỗi phiên bản của thực thể cha được liên kết với số lượng phiên bản tùy ý (bao gồm cả 0) của thực thể con. Mỗi phiên bản của thực thể con được liên kết với chính xác một phiên bản của thực thể mẹ của nó. Do đó, một thể hiện của thực thể con chỉ có thể tồn tại nếu thực thể cha tồn tại.

Mối nối được đặt tên, thể hiện bằng cách chuyển ngữ pháp của động từ và đặt gần đường nối.

Tên của mỗi mối quan hệ giữa hai thực thể nhất định phải là duy nhất nhưng tên của các mối quan hệ trong mô hình không nhất thiết phải là duy nhất. Mọi kết nối đều có một định nghĩa. Định nghĩa mối quan hệ được hình thành bằng cách kết hợp tên của thực thể cha, tên của mối quan hệ, biểu thức mức độ kết nối và tên của thực thể con.

Ví dụ: mối quan hệ của người bán với hợp đồng có thể được xác định như sau:

Bên bán có thể nhận được tiền bồi thường cho một hoặc nhiều Hợp đồng;

Hợp đồng phải được khởi xướng bởi chính xác một Người bán.

Trong sơ đồ, kết nối được mô tả dưới dạng một đoạn (đa tuyến). Các đầu của đoạn sử dụng chỉ định đặc biệt(Hình 2) cho biết mức độ kết nối. Ngoài ra, bản chất của đường—nét đứt hoặc liền—chỉ ra rằng kết nối là bắt buộc.

Thuộc tính- bất kỳ đặc điểm nào của thực thể có ý nghĩa quan trọng đối với lĩnh vực chủ đề đang được xem xét. Nó nhằm mục đích xác định, xác định, phân loại, định lượng hoặc thể hiện trạng thái của một thực thể. Thuộc tính đại diện cho một loại đặc điểm (thuộc tính) được liên kết với một tập hợp các đối tượng thực hoặc trừu tượng (con người, địa điểm, sự kiện, trạng thái, ý tưởng, cặp đối tượng, v.v.) (Hình 3).

Ví dụ thuộc tính là một đặc tính nhất định của một thể hiện cụ thể của một thực thể. Một phiên bản thuộc tính được xác định bởi loại đặc tính (ví dụ: "Màu sắc") và giá trị của nó (ví dụ: "màu tím"), được gọi là giá trị thuộc tính. Trong mô hình ER, các thuộc tính được liên kết với các thực thể cụ thể. Mỗi thực thể phải có một giá trị cụ thể cho mỗi thuộc tính của nó.

Thuộc tính có thể là bắt buộc, hoặc không bắt buộc. Bắt buộc có nghĩa là thuộc tính không thể chấp nhận giá trị null. Một thuộc tính có thể mang tính mô tả (tức là một bộ mô tả thông thường của một thực thể) hoặc một phần của định danh duy nhất(khóa chính).

Mã định danh duy nhất là một thuộc tính hoặc một tập hợp các thuộc tính và/hoặc mối quan hệ đặc trưng duy nhất cho từng trường hợp của một loại thực thể nhất định. Trong trường hợp nhận dạng đầy đủ, một thể hiện của một loại thực thể nhất định được xác định đầy đủ bởi các thuộc tính khóa của chính nó, nếu không thì các thuộc tính của thực thể khác, thực thể cha, cũng tham gia vào việc nhận dạng.

Bản chất của việc nhận dạng được hiển thị trong sơ đồ trên đường truyền thông (Hình 4).

Mỗi thuộc tính được xác định bằng một tên duy nhất, được thể hiện bằng một cụm danh từ ngữ pháp mô tả đặc tính mà thuộc tính đó đại diện. Các thuộc tính được biểu diễn dưới dạng danh sách các tên trong một khối thực thể liên kết, với mỗi thuộc tính chiếm một dòng riêng biệt. Các thuộc tính xác định khóa chính được đặt ở đầu danh sách và được đánh dấu bằng dấu “#”.

Mỗi thực thể phải có ít nhất một khóa có thể. Khóa ứng viên cho một thực thể là một hoặc nhiều thuộc tính có giá trị xác định duy nhất từng phiên bản của thực thể. Khi có nhiều khóa có thể, một trong số chúng được chỉ định làm khóa chính và các khóa còn lại làm khóa thay thế.

Hiện tại, dựa trên cách tiếp cận của Chen, phương pháp IDEF1X đã được tạo ra, được thiết kế có tính đến các yêu cầu như tính dễ học và khả năng tự động hóa. Sơ đồ IDEFlX được sử dụng bởi một số công cụ CASE phổ biến (đặc biệt là ERwin, Design/IDEF).

Một thực thể trong phương pháp IDEF1X được gọi là định danh độc lập hoặc đơn giản là độc lập nếu mỗi phiên bản của thực thể có thể được xác định duy nhất mà không cần xác định mối quan hệ của nó với các thực thể khác. Một thực thể được gọi là phụ thuộc vào định danh hoặc đơn giản là phụ thuộc nếu việc nhận dạng duy nhất một phiên bản của thực thể phụ thuộc vào mối quan hệ của nó với thực thể khác (Hình 5).

Mỗi thực thể được cấp một tên và số duy nhất, được phân tách bằng dấu gạch chéo "/" và được đặt phía trên khối.

Nếu một thể hiện của thực thể con được xác định duy nhất bởi mối quan hệ của nó với thực thể cha thì mối quan hệ đó được gọi là xác định, nếu không thì nó được gọi là không xác định.

Mối quan hệ xác định giữa thực thể cha và thực thể con được mô tả dưới dạng một đường liền nét. Trong bộ lễ phục. 5: Số 2 - thực thể phụ thuộc, Mối quan hệ 1 - mối quan hệ xác định. Thực thể con trong mối quan hệ nhận dạng là thực thể phụ thuộc vào định danh. Thực thể mẹ trong mối quan hệ xác định có thể là thực thể độc lập hoặc thực thể phụ thuộc vào định danh (điều này được xác định bởi mối quan hệ của nó với các thực thể khác).

Đường đứt nét thể hiện mối quan hệ không xác định. Trong bộ lễ phục. 5: Số 4 - thực thể độc lập, Mối quan hệ 2 - mối quan hệ không xác định. Một thực thể con trong một mối quan hệ không xác định sẽ độc lập với mã định danh trừ khi nó cũng là một thực thể con trong một số mối quan hệ xác định.

Mối quan hệ có thể được xác định rõ hơn bằng cách chỉ định mức độ hoặc số lượng (số lượng phiên bản của thực thể con có thể tồn tại cho mỗi phiên bản của thực thể cha).

Các quyền hạn liên kết sau đây có thể được thể hiện trong IDEF1X:

Mỗi phiên bản thực thể cha có thể có 0, một hoặc nhiều phiên bản thực thể con được liên kết với nó;

Mỗi thực thể mẹ phải có ít nhất một thực thể con được liên kết với nó;

Mỗi phiên bản thực thể cha phải có nhiều nhất một phiên bản thực thể con được liên kết với nó;

Mỗi phiên bản của thực thể cha được liên kết với một số phiên bản cố định của thực thể con.

Sức mạnh truyền thông được biểu thị như trong hình. 6 (nguồn mặc định - N).

Các thuộc tính được biểu diễn dưới dạng danh sách các tên bên trong một khối thực thể. Các thuộc tính xác định khóa chính được đặt ở đầu danh sách và được phân tách với các thuộc tính khác bằng một đường ngang (Hình 7).

Kết quả là một mô hình logic thông tin được sử dụng bởi một số công cụ CASE phổ biến, chẳng hạn như ERwin, Design/IDEF. Ngược lại, công nghệ CASE có tiềm năng cao trong việc phát triển cơ sở dữ liệu và hệ thống thông tin, cụ thể là tăng năng suất lao động, nâng cao chất lượng. sản phẩm phần mềm, hỗ trợ một phong cách làm việc thống nhất và nhất quán.

Các thực thể cũng có thể có khóa ngoại. Trong mối quan hệ xác định, chúng được sử dụng như một phần hoặc toàn bộ khóa chính; trong mối quan hệ không xác định, chúng đóng vai trò là thuộc tính không phải là khóa. Trong danh sách thuộc tính khóa ngoàiđược đánh dấu bằng các chữ cái FK trong ngoặc.