Thực đơn
trang chủSự cố

Thiết kế cơ sở dữ liệu. Phát triển cơ sở dữ liệu thư viện

1. THIẾT KẾ CƠ SỞ DỮ LIỆU

1.1. Cơ sở dữ liệu quan hệ và cấu trúc của nó

Cơ sở dữ liệu (DB) là tập hợp thông tin về các đối tượng, quá trình, sự kiện hoặc hiện tượng liên quan đến một lĩnh vực, chủ đề hoặc nhiệm vụ nhất định, được tổ chức theo các quy tắc nhất định và được lưu giữ trong bộ nhớ máy tính. Nó được tổ chức theo cách nhằm cung cấp nhu cầu thông tin của người dùng, cũng như lưu trữ thuận tiện bộ sưu tập dữ liệu này, cả về tổng thể và bất kỳ phần nào của dữ liệu đó.

Cơ sở dữ liệu quan hệ là một tập hợp các bảng được kết nối với nhau, mỗi bảng chứa thông tin về các đối tượng thuộc một loại nhất định. Mỗi hàng của bảng chứa dữ liệu về một đối tượng (ví dụ: ô tô, máy tính, khách hàng) và các cột của bảng chứa các đặc điểm khác nhau của các đối tượng này - thuộc tính (ví dụ: số động cơ, nhãn hiệu bộ xử lý, số điện thoại của công ty hoặc khách hàng).

Các hàng trong bảng được gọi là bản ghi. Tất cả các bản ghi bảng đều có cùng cấu trúc - chúng bao gồm các trường (phần tử dữ liệu) trong đó các thuộc tính của đối tượng được lưu trữ (Hình 1). Mỗi trường bản ghi chứa một đặc điểm của đối tượng và thể hiện một kiểu dữ liệu được chỉ định (ví dụ: chuỗi văn bản, số, ngày). Khóa chính được sử dụng để xác định các bản ghi. Khóa chính là một tập hợp các trường bảng có sự kết hợp các giá trị xác định duy nhất từng bản ghi trong bảng.

Cơm. 1. Tên các đối tượng trong bảng

Hệ thống quản lý cơ sở dữ liệu (DBMS) được sử dụng để làm việc với dữ liệu. Các chức năng chính của DBMS:

– định nghĩa dữ liệu (mô tả cấu trúc cơ sở dữ liệu);

– xử lí dữ liệu;

– Quản lý dữ liệu.

Phát triển cấu trúc cơ sở dữ liệu là nhiệm vụ quan trọng nhất được giải quyết khi thiết kế cơ sở dữ liệu. Cấu trúc của cơ sở dữ liệu (tập hợp, biểu mẫu và các mối quan hệ của các bảng) là một trong những quyết định thiết kế chính khi tạo các ứng dụng sử dụng cơ sở dữ liệu. Cấu trúc cơ sở dữ liệu do nhà phát triển tạo được mô tả bằng ngôn ngữ định nghĩa dữ liệu DBMS.

Bất kỳ DBMS nào cũng cho phép bạn thực hiện các thao tác sau với dữ liệu:

– thêm bản ghi vào bảng;

– xóa các bản ghi khỏi bảng;

– cập nhật giá trị của một số trường trong một hoặc nhiều bản ghi trong bảng cơ sở dữ liệu;

– tìm kiếm một hoặc nhiều bản ghi thỏa mãn một điều kiện nhất định.

Để thực hiện các hoạt động này, một cơ chế truy vấn được sử dụng. Kết quả của việc thực hiện truy vấn là một tập hợp các bản ghi được chọn theo tiêu chí nhất định hoặc những thay đổi trong bảng. Các truy vấn tới cơ sở dữ liệu được hình thành bằng ngôn ngữ được tạo riêng cho mục đích này, được gọi là

“ngôn ngữ truy vấn có cấu trúc” (SQL – Ngôn ngữ truy vấn có cấu trúc).

Quản trị dữ liệu thường đề cập đến việc bảo vệ dữ liệu khỏi bị truy cập trái phép, hỗ trợ xử lý dữ liệu nhiều người dùng và đảm bảo tính toàn vẹn và nhất quán của dữ liệu.

1.2. Các giai đoạn thiết kế cơ sở dữ liệu quan hệ

Lý do chính khiến việc thiết kế cơ sở dữ liệu trở nên khó khăn là vì các đối tượng trong thế giới thực và mối quan hệ giữa chúng không nhất thiết và nói chung là không có cấu trúc nhất quán với mô hình dữ liệu quan hệ. Khi thiết kế, nhà phát triển phải đưa ra cách biểu diễn các đối tượng thực và mối quan hệ của chúng dưới dạng bảng, trường, thuộc tính, bản ghi, v.v., nghĩa là dưới dạng trừu tượng của mô hình dữ liệu quan hệ. Do đó, trong bối cảnh này, thuật ngữ “thiết kế” có thể được hiểu vừa là một quá trình, kết quả của nó là một dự án, vừa là một quá trình, kết quả của nó là một hình chiếu.

Phát triển một cơ sở dữ liệu hiệu quả bao gồm một số bước. Quá trình phát triển cơ sở dữ liệu bắt đầu bằng việc phân tích yêu cầu. Nhà thiết kế ở giai đoạn phát triển này phải tìm câu trả lời cho các câu hỏi sau: phần tử dữ liệu nào sẽ được lưu trữ, ai sẽ truy cập chúng và bằng cách nào.

Ở giai đoạn thứ hai, cấu trúc logic của cơ sở dữ liệu được tạo ra. Để làm điều này, hãy xác định cách dữ liệu sẽ được nhóm một cách hợp lý. Cấu trúc của cơ sở dữ liệu ở giai đoạn này được thể hiện dưới dạng các đối tượng ứng dụng và mối quan hệ giữa chúng.

Ở giai đoạn cuối cùng (thứ ba), cấu trúc logic của cơ sở dữ liệu được chuyển đổi thành cấu trúc vật lý, có tính đến các khía cạnh hiệu suất. Các phần tử dữ liệu ở giai đoạn này nhận các thuộc tính và được xác định dưới dạng các cột trong các bảng của DBMS được chọn để triển khai cơ sở dữ liệu.

Hãy xem xét việc áp dụng khái niệm cơ sở dữ liệu quan hệ trong thực tế. Hãy tưởng tượng các hoạt động của một công ty du lịch. Rõ ràng, để nó hoạt động, cần phải lưu trữ và theo dõi một bộ thông tin nhất định về khách hàng của một công ty du lịch nhất định (khách du lịch), về các chuyến tham quan được cung cấp cho họ, về việc đăng ký và thanh toán chứng từ. Việc này có thể được thực hiện bằng một cuốn sổ tay giấy thông thường, nhưng theo thời gian, việc tìm kiếm các hồ sơ cần thiết và báo cáo tài chính sẽ là một công việc khá thường xuyên và tốn thời gian.

1.2.1. Xác định yêu cầu

Các yêu cầu đối với một ứng dụng cơ sở dữ liệu thường được phát triển thông qua khảo sát và trò chuyện với người dùng cuối. Đây là một quá trình lặp đi lặp lại trong đó các nhà phát triển xác định cấu trúc hội thoại của người dùng, tiêu chí tìm kiếm tài liệu và phản ứng có thể có của người dùng.

Một kỹ thuật chung để xác định và ghi lại các yêu cầu cơ sở dữ liệu là biên soạn từ điển dữ liệu. Từ điển dữ liệu liệt kê và định nghĩa các thành phần dữ liệu riêng lẻ phải được lưu trữ trong cơ sở dữ liệu. Bản thảo ban đầu của từ điển dữ liệu dành cho người quản lý đại lý du lịch được trình bày trong Bảng 1.

Bảng 1

Từ điển dữ liệu ứng dụng cơ sở dữ liệu quản lý đại lý du lịch

Phần tử dữ liệu

Sự miêu tả

Họ của khách du lịch

Tên du lịch

Họ

Tên bảo trợ của khách du lịch

Số và sê-ri hộ chiếu du lịch

Số điện thoại liên lạc du lịch

Thành phố nơi cư trú của khách du lịch

Nước cư trú của khách du lịch

Địa chỉ du lịch mã bưu điện

Tên chuyến đi

Giá một chuyến du lịch

ngày bắt đầu

Thời điểm bắt đầu chuyến du lịch

Ngày cuối

Thời điểm kết thúc chuyến du lịch

Thông tin

Thông tin bổ sung về chuyến tham quan

ngày thanh toán

Ngày thanh toán cho chuyến đi

Số tiền thanh toán

Biên soạn từ điển là một cách hay để bắt đầu xác định các yêu cầu cơ sở dữ liệu của bạn. Nhưng một từ điển là không đủ để xác định cấu trúc của cơ sở dữ liệu, vì từ điển dữ liệu không mô tả các phần tử có liên quan với nhau như thế nào, dữ liệu được tạo, cập nhật và chọn như thế nào, ai sẽ sử dụng cơ sở dữ liệu và cách thức sử dụng.

Yêu cầu đặc điểm chức năng, phản ánh thông tin về số lượng người dùng đồng thời, tần suất các bản ghi sẽ được chèn và cập nhật cũng như cách lấy thông tin từ cơ sở dữ liệu.

Ví dụ, mô tả chức năng cho ứng dụng cơ sở dữ liệu người quản lý đại lý du lịch có thể bao gồm các yêu cầu sau:

Ứng dụng sẽ được sử dụng bởi người đứng đầu công ty du lịch, 2 quản lý bán hàng, một kế toán, một nhân viên thu ngân và 2 nhân viên văn phòng của công ty du lịch - tổng cộng là 7 người dùng. Giả định rằng không quá 3 nhân viên sẽ làm việc đồng thời với cơ sở dữ liệu. Để làm việc, nhân viên kế toán chỉ cần truy cập vào dữ liệu thanh toán du lịch.

Tất cả người dùng có thể thêm thông tin vào cơ sở dữ liệu bất cứ lúc nào. Khi thông tin được thêm hoặc thay đổi, người dùng thực hiện thay đổi và ngày giờ thay đổi phải được ghi lại.

Một trong những nhân viên văn phòng sẽ được bổ nhiệm làm quản trị viên hệ thống. Chỉ có anh ta mới nên duy trì tài khoản người dùng.

Đặc tả chức năng và từ điển dữ liệu thường được phát triển đồng thời vì các tài liệu này bổ sung cho nhau về mặt thông tin.

Một phần quan trọng của phân tích yêu cầu là dự đoán nhu cầu của người dùng, vì không phải lúc nào họ cũng có thể giải thích đầy đủ và rõ ràng các yêu cầu của riêng họ đối với hệ thống. Trong thực tế, mô tả chức năng phải trình bày hệ thống một cách đầy đủ và chi tiết nhất có thể.

1.2.2. Mô hình logic

sơ đồ ER

Một cách phổ biến để biểu diễn mô hình cơ sở dữ liệu logic là xây dựng sơ đồ ER (Mối quan hệ thực thể). Trong mô hình này, một thực thể được định nghĩa là một đối tượng riêng biệt mà các phần tử dữ liệu được lưu trữ và mối quan hệ mô tả mối quan hệ giữa hai đối tượng.

TRONG Trong ví dụ về người quản lý đại lý du lịch, có 5 đối tượng chính:

Khách du lịch

Chuyến tham quan

Chứng từ

Các mùa

Thanh toán

Mối quan hệ giữa các đối tượng này có thể được định nghĩa bằng thuật ngữ đơn giản:

Mỗi du khách có thể mua một hoặc nhiều (nhiều) voucher.

Mỗi chứng từ tương ứng với khoản thanh toán của nó (thanh toán

có lẽ một số

nếu chứng từ, ví dụ,

bán chịu).

Mỗi chuyến tham quan có thể có

nhiều mùa.

Gói du lịch

rao bán

một mùa của một chuyến du lịch.

Những đối tượng và mối quan hệ này

có thể được đại diện bởi ER-

biểu đồ,

như được hiển thị

Cơm. 2. Sơ đồ ER cho ứng dụng DB

giám đốc công ty du lịch

Đối tượng, thuộc tính và khóa

Mô hình được phát triển hơn nữa bằng cách xác định các thuộc tính cho từng đối tượng. Thuộc tính đối tượng là các thành phần dữ liệu liên quan đến một đối tượng cụ thể cần được lưu trữ. Chúng tôi phân tích từ điển dữ liệu đã biên dịch, chọn các đối tượng và thuộc tính của chúng trong đó, đồng thời mở rộng từ điển nếu cần. Các thuộc tính cho từng đối tượng trong ví dụ được trình bày trong Bảng 2.

Các đối tượng và thuộc tính cơ sở dữ liệu

ban 2

Tên

ngày bắt đầu

ngày thanh toán

Ngày cuối

Họ

Thông tin

Thuộc tính

Xin lưu ý rằng một số mục bị thiếu. Thông tin đăng ký được đề cập trong đặc tả chức năng đã bị bỏ qua. Làm thế nào để tính đến nó, bạn sẽ tự suy nghĩ và hoàn thiện ví dụ đề xuất. Nhưng quan trọng hơn, các thuộc tính cần thiết để kết nối các đối tượng với nhau vẫn còn thiếu. Các phần tử dữ liệu này không được biểu diễn trong mô hình ER.

trên thực tế không phải là thuộc tính “tự nhiên” của vật thể. Chúng được xử lý khác nhau và sẽ được tính đến trong mô hình dữ liệu quan hệ.

Mô hình quan hệ được đặc trưng bởi việc sử dụng các khóa và các mối quan hệ. Có sự khác biệt trong bối cảnh cơ sở dữ liệu quan hệ giữa các thuật ngữ quan hệ và mối quan hệ. Một mối quan hệ được coi là một bảng hai chiều không có thứ tự với các hàng không liên quan. Lược đồ dữ liệu được hình thành giữa các mối quan hệ (bảng) thông qua các thuộc tính chung là các khóa.

Có một số loại khóa và đôi khi chúng chỉ khác nhau về mối quan hệ với các thuộc tính và mối quan hệ khác. Khóa chính xác định duy nhất một hàng trong một mối quan hệ (bảng) và mỗi mối quan hệ chỉ có thể có một khóa chính, ngay cả khi có nhiều thuộc tính là duy nhất. Trong một số trường hợp, cần có nhiều thuộc tính để xác định các hàng trong mối quan hệ. Tập hợp các thuộc tính này được gọi phím ghép. Trong các trường hợp khác, khóa chính phải được tạo (tạo) đặc biệt. Ví dụ: trong quan hệ “Du khách”, sẽ hợp lý hơn khi thêm một mã định danh du lịch duy nhất (mã du lịch) làm khóa chính của quan hệ này để tổ chức các kết nối với các quan hệ cơ sở dữ liệu khác.

Một loại khóa khác, được gọi là khóa ngoại, chỉ tồn tại dưới dạng lược đồ dữ liệu giữa hai mối quan hệ. Khóa ngoại trong một mối quan hệ là một thuộc tính là khóa chính (hoặc một phần của khóa chính) trong một mối quan hệ khác. Đây là thuộc tính phân tán tạo thành lược đồ dữ liệu giữa hai mối quan hệ trong cơ sở dữ liệu.

Đối với cơ sở dữ liệu được thiết kế, chúng ta sẽ mở rộng các thuộc tính của đối tượng với các trường mã làm khóa chính và sử dụng các mã này trong quan hệ cơ sở dữ liệu để tham chiếu đến các đối tượng cơ sở dữ liệu như sau (Bảng 3).

Còn quá sớm để coi lược đồ cơ sở dữ liệu đã được xây dựng là hoàn chỉnh vì cần phải chuẩn hóa nó. Một quy trình được gọi là chuẩn hóa cơ sở dữ liệu quan hệ được sử dụng để nhóm các thuộc tính theo những cách đặc biệt nhằm giảm thiểu sự dư thừa và phụ thuộc chức năng.

Các đối tượng và thuộc tính DB có trường mã mở rộng

bàn số 3

Mã du lịch

Mã chuyến đi

Mã mùa

Mã thanh toán

Mã du lịch

Tên

ngày bắt đầu

ngày thanh toán

Thuộc tính

Mã mùa

Ngày cuối

Họ

Thông tin

Mã chuyến đi

Chuẩn hóa

Sự phụ thuộc chức năng xảy ra khi giá trị của một thuộc tính có thể được xác định từ giá trị của thuộc tính khác. Một thuộc tính có thể được xác định được gọi là phụ thuộc chức năng từ thuộc tính là yếu tố quyết định. Do đó, theo định nghĩa, tất cả các thuộc tính không khóa (không có khóa) sẽ phụ thuộc về mặt chức năng vào khóa chính trong mọi mối quan hệ (vì khóa chính xác định duy nhất mỗi hàng). Khi một thuộc tính của mối quan hệ không xác định duy nhất một thuộc tính khác mà giới hạn nó ở một tập hợp các giá trị được xác định trước, thì nó được gọi là phụ thuộc đa giá trị xảy ra khi thuộc tính mối quan hệ phụ thuộc chức năng vào một thuộc tính của khóa tổng hợp. Sự phụ thuộc bắc cầu được quan sát thấy khi một thuộc tính không khóa phụ thuộc chức năng vào một hoặc nhiều thuộc tính không khóa khác trong mối quan hệ.

Quá trình chuẩn hóa bao gồm việc xây dựng cơ sở dữ liệu ở dạng chuẩn (NF).

Dạng bình thường đầu tiên (1NF) rất đơn giản. Tất cả các bảng cơ sở dữ liệu phải đáp ứng một yêu cầu duy nhất - mỗi ô trong bảng phải chứa một giá trị nguyên tử, nói cách khác, giá trị được lưu trữ trong miền của ứng dụng cơ sở dữ liệu không được có cấu trúc bên trong, các phần tử của nó có thể được yêu cầu bởi ứng dụng.

Dạng chuẩn thứ hai (2NF) được tạo khi tất cả các phụ thuộc một phần bị loại bỏ khỏi các mối quan hệ cơ sở dữ liệu. Nếu không có khóa tổng hợp trong mối quan hệ thì mức độ chuẩn hóa này có thể dễ dàng đạt được.

Dạng chuẩn thứ ba (3NF) của cơ sở dữ liệu yêu cầu loại bỏ tất cả các phụ thuộc bắc cầu.

Dạng bình thường thứ tư (4NF) được tạo khi tất cả các phụ thuộc đa giá trị bị loại bỏ.

Cơ sở dữ liệu trong ví dụ của chúng tôi ở dạng 1NF, vì tất cả các trường của bảng cơ sở dữ liệu đều có nội dung nguyên tử. Cơ sở dữ liệu của chúng tôi cũng ở dạng 2NF, vì chúng tôi đã đưa một cách giả tạo vào mỗi bảng các mã duy nhất cho từng đối tượng (Mã du lịch, Mã du lịch, v.v.), nhờ đó chúng tôi đã đạt được 2NF cho từng bảng cơ sở dữ liệu và toàn bộ cơ sở dữ liệu nói chung. Nó vẫn còn để giải quyết các hình thức bình thường thứ ba và thứ tư.

Lưu ý rằng chúng chỉ tồn tại liên quan đến các loại phụ thuộc thuộc tính cơ sở dữ liệu khác nhau. Có các phần phụ thuộc - bạn cần định giá cơ sở dữ liệu NF, không có phần phụ thuộc nào - cơ sở dữ liệu đã ở dạng NF. Nhưng tùy chọn thứ hai thực tế không bao giờ được tìm thấy trong các ứng dụng thực tế.

Vì vậy, những sự phụ thuộc bắc cầu và đa giá trị nào có trong ví dụ của chúng ta về cơ sở dữ liệu người quản lý đại lý du lịch?

Hãy phân tích thái độ của “Khách du lịch”. Hãy xem xét sự phụ thuộc giữa các thuộc tính “Mã du lịch”, “Họ”, “Tên”, “Người bảo trợ” và “Hộ chiếu” (Hình 3). Mỗi khách du lịch, được thể hiện trong mối quan hệ bằng sự kết hợp “Họ - Tên - Người bảo trợ”, chỉ có một hộ chiếu trong suốt chuyến đi, trong khi những người trùng tên đầy đủ phải có số hộ chiếu khác nhau. Vì vậy, các thuộc tính “Họ - Tên - Họ” và “Hộ chiếu” tạo thành một khóa tổng hợp cho khách du lịch.

Tổ hợp phím

Họ

Mã du lịch

Cơm. 3. Ví dụ về sự phụ thuộc bắc cầu

Như có thể thấy trong hình, thuộc tính “Hộ chiếu” phụ thuộc quá mức vào khóa “Mã du lịch”. Do đó, để loại bỏ sự phụ thuộc bắc cầu này, chúng ta chia khóa tổng hợp của quan hệ và chính mối quan hệ đó thành 2 theo mối quan hệ một-một. Mối quan hệ đầu tiên, hãy để nó với cái tên “Khách du lịch”, bao gồm các thuộc tính “Mã du lịch” và “Họ”, “Tên”, “Tên bảo trợ”. Mối quan hệ thứ hai, tạm gọi là “Thông tin về khách du lịch”, được hình thành bởi các thuộc tính “Mã du lịch” và tất cả các thuộc tính còn lại của mối quan hệ “Khách du lịch”: “Hộ chiếu”, “Điện thoại”, “Thành phố”, “Quốc gia”, "Mục lục". Hai quan hệ mới này không còn phụ thuộc bắc cầu nữa và nằm trong 3NF.

Không có sự phụ thuộc đa giá trị trong cơ sở dữ liệu đơn giản hóa của chúng tôi. Ví dụ: giả sử rằng đối với mỗi khách du lịch, một số số liên lạc phải được lưu trữ (nhà riêng, cơ quan, điện thoại di động, v.v., rất phổ biến trong thực tế) chứ không chỉ một, như trong ví dụ. Chúng tôi nhận được sự phụ thuộc nhiều giá trị của khóa - “Mã du lịch” và các thuộc tính “Loại điện thoại” và “Điện thoại” trong tình huống này, khóa không còn là khóa nữa. Phải làm gì? Vấn đề cũng được giải quyết bằng cách tách lược đồ quan hệ thành 2 lược đồ mới. Một trong số chúng phải thể hiện thông tin về điện thoại (quan hệ “Điện thoại”) và thông tin thứ hai về khách du lịch (quan hệ “Khách du lịch”), những người được liên hệ bằng cách sử dụng trường “Mã du lịch”. “Mã du lịch” liên quan đến “Khách du lịch” sẽ là khóa chính và liên quan đến “Điện thoại” nó sẽ là khóa bên ngoài.

1.2.3. Mô hình vật lý

Mô hình dữ liệu vật lý phụ thuộc vào DBMS được chọn. Ví dụ: nếu bạn định sử dụng Oracle DBMS thì cơ sở dữ liệu vật lý sẽ bao gồm các tệp dữ liệu, vùng bảng, phân đoạn khôi phục, bảng, cột

và chỉ mục.

TRONG Sổ tay hướng dẫn này sẽ đề cập đến việc tạo mô hình cơ sở dữ liệu vật lý bằng cách sử dụng Microsoft Access DBMS và máy chủ cơ sở dữ liệu Microsoft SQL Server 2005 Express Edition.

1.3. Tạo cơ sở dữ liệu trong Microsoft Access DBMS

1.3.1. Những cái bàn

Để tạo bảng trong Microsoft Access DBMS, chúng tôi sử dụng chế độ thiết kế (Hình 4).

Cơm. 4. Lựa chọn chế độ thiết kế

Cơm. 5. Danh sách đầy đủ các trường của bảng

Trong cửa sổ “Bảng1: bảng” xuất hiện, bạn phải xác định tên của các trường sẽ trở thành tiêu đề trong bảng này. Hãy nhập tên trường sau (Hình 5).

Khi bạn nhập tên trường, cho nó

kiểu dữ liệu mặc định được xác định

"chữ". Để thay đổi loại:

Không thể chọn giá trị mong muốn từ menu thả xuống

danh sách đưa ra (Hình 6).

Cơm. 6. Xác định kiểu dữ liệu trường

Mô tả các kiểu dữ liệu có thể

Dữ liệu Microsoft Access được đưa ra trong bảng.

Bảng 4

Các kiểu dữ liệu Microsoft Access

Loại dữ liệu

Sự miêu tả

Chữ

Văn bản hoặc sự kết hợp giữa văn bản và số, chẳng hạn như địa chỉ và

những con số không cần tính toán, ví dụ như số điện thoại,

số hàng tồn kho hoặc mã bưu chính. Lưu trữ tối đa 255 ký tự.

Thuộc tính “FieldSize” xác định số lượng tối đa

Số ký tự có thể nhập vào trường

trường MEMO

Được thiết kế để nhập thông tin văn bản, âm lượng vượt quá

255 ký tự. Trường như vậy có thể chứa tối đa 65.535 ký tự

con bò Kiểu dữ liệu này khác với kiểu Văn bản ở chỗ

đứng tách biệt. Do đó, việc xử lý bảng (sắp xếp) được tăng tốc

đào bới, tìm kiếm...). Trường thuộc loại MEMO không thể là khóa hoặc

được lập chỉ mục

Số

Dữ liệu được sử dụng để tính toán toán học, ngoại trừ

tài chính

tính toán (đối với chúng bạn nên sử dụng loại

"Tiền tệ"). Lưu trữ 1, 2, 4 hoặc 8 byte. Loại chi cụ thể

trường từ được xác định bởi giá trị của thuộc tính Kích thước trường

Ngày giờ

Giá trị ngày và giờ. Lưu trữ 8 byte

Tiền tệ

Được sử dụng cho các giá trị tiền tệ và để ngăn chặn việc làm tròn

leniya trong quá trình tính toán. Lưu trữ 8 byte

Tự động chèn chuỗi tuần tự duy nhất (tăng

trên 1) hoặc số ngẫu nhiên khi thêm bản ghi. đồng-

lưu trữ 4 byte

Hợp lý

Dữ liệu chỉ nhận một trong hai giá trị có thể

chẳng hạn như Có/Không, Đúng/Sai, Bật/Tắt. Giá trị null thì không

được cho phép. Lưu trữ 1 bit.

Trường đối tượng

Các đối tượng OLE (chẳng hạn như tài liệu Microsoft Word, tài liệu điện tử

Bảng tính Microsoft Excel, bản vẽ, bản ghi âm hoặc dữ liệu khác ở dạng

định dạng nhị phân) (giới hạn bởi dung lượng ổ đĩa)

Thật khó để tôi đưa ra lời khuyên vì tôi không biết chính xác người khác đã làm điều đó như thế nào. Nhưng nếu dự án của bạn nhằm mục đích tự giáo dục, thì tôi nghĩ trước tiên bạn nên thực sự thực hành trên cơ sở dữ liệu quan hệ cổ điển và sau đó mới chuyển sang một số tùy chọn kỳ lạ hơn. Bạn cần chuyển từ đơn giản sang phức tạp và chỉ khi đơn giản không còn đủ nữa. Nhìn chung, cơ sở dữ liệu quan hệ với cấu trúc cứng nhắc và các hạn chế nghiêm ngặt mà bạn đặt ra là bạn của mình vì họ đang cố gắng cứu dữ liệu của bạn khỏi bị phá hủy.

Về việc hiển thị các loại sản phẩm khác nhau trong các bảng khác nhau. Quyết định này có cả mặt tốt và mặt xấu. Ưu điểm chính là bạn hoàn toàn có thể tạo từng bảng như vậy, có tính đến tất cả các chi tiết cụ thể của từng loại sản phẩm. Nhưng mặt xấu là trong trường hợp này bạn sẽ phải lưu ý rằng mỗi bảng như vậy sẽ được xử lý riêng biệt. Bởi vì nếu các bảng có thiết kế khác nhau thì phương pháp xử lý cũng sẽ khác nhau.

Có lẽ giải pháp tối ưu là bạn phải suy nghĩ cẩn thận về những thông số sản phẩm bạn sẽ cần cho việc tìm kiếm và đặt chúng thành các cột riêng biệt có thể lập chỉ mục trong bảng chung về sản phẩm. Đối với một số loại sản phẩm, các trường này sẽ trống. Và các thông số khác chỉ mô tả đơn giản về sản phẩm chứ không nhằm mục đích tìm kiếm, bạn có thể kết hợp và lưu trữ dưới dạng này trong một cột. Và giải nén khi cần thiết, khi chúng cần được trao cho người dùng. Bạn có thể đặt tất cả mọi thứ ở đó mà không phải lo lắng rằng những thứ này có thể thay đổi đối với một sản phẩm cụ thể. Điều chính là lưu trữ nó dưới dạng các cặp giá trị để biết đâu là gì - bạn muốn thêm vào mô tả sản phẩm rằng cá sấu có màu nâu xám chứ không phải màu tím, giống như những người khác - đó là những gì bạn viết - Cá sấu => màu nâu xám.

Mặt khác, không phải lúc nào bạn cũng biết mình muốn thêm danh mục sản phẩm nào tiếp theo. Nhưng bóp méo, thổi phồng và “xả” bảng hàng hóa tổng hợp không phải là ý kiến ​​hay. Từ quan điểm tổng quát này, ý tưởng của bạn về các bảng khác nhau cho các sản phẩm khác nhau có thể rất tốt. Rốt cuộc, sau khi đã phát triển cơ sở - đã thực hiện nhiều cách xử lý khác nhau cho các bảng sản phẩm khác nhau, khi thêm một loại sản phẩm mới, bạn chỉ cần tạo một bảng và cung cấp cho nó một trình xử lý phù hợp với nó. Bạn không phải lo lắng về cách các bảng khác hoạt động.

Ví dụ: chúng tôi chọn danh mục sản phẩm máy tính xách tay và tìm kiếm theo các thông số vốn chỉ dành cho máy tính xách tay.

Bài học

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

Mô hình kiến ​​trúc đa cấp của hệ thống cơ sở dữ liệu. Thiết kế các công cụ tự động hóa

1. Mô hình kiến ​​trúc đa cấp của hệ thống cơ sở dữ liệu

Trong lĩnh vực thiết kế và phát triển hệ thống cơ sở dữ liệu, nhiều công cụ mô hình hóa khác nhau được sử dụng và ngay cả trong khuôn khổ của một hệ thống cụ thể, cần có toàn bộ các mô hình cho các mục đích khác nhau.

Báo cáo ANSI/X3/SPARC, xuất bản năm 1975, ghi lại không chỉ sự chấp nhận rộng rãi các khái niệm về kiến ​​trúc hệ thống cơ sở dữ liệu nhiều tầng mà còn nhu cầu xác định rõ ràng một đặc điểm khái niệm mức độ trình bày cơ sở dữ liệu, thống nhất cho tất cả các ứng dụng của nó và độc lập với chúng. Ngoài cấp độ này, hai cấp độ nữa đã được cung cấp: cấp độ bên trong, cấp độ này sẽ cung cấp hỗ trợ cho chế độ xem cơ sở dữ liệu được lưu trữ và cấp độ bên ngoài, sẽ hỗ trợ chế độ xem cơ sở dữ liệu “từ quan điểm” của các ứng dụng. Ở mỗi cấp độ kiến ​​trúc, việc sử dụng mô hình dữ liệu này hoặc mô hình dữ liệu khác đã được giả định. Ngoài ra, ở cấp độ bên ngoài (ứng dụng, người dùng) có thể có một số mô hình như vậy. Các mô hình, cũng như các sơ đồ được chỉ định trên cơ sở của chúng, lần lượt được gọi là bên ngoài, khái niệm và bên trong.

Rõ ràng, 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ể, ở mức độ này hay mức độ khác, thể hiện ý tưởng của người thiết kế về lĩnh vực chủ đề và các nhiệm vụ được người dùng giải quyết bằng cách sử dụng cơ sở dữ liệu đã tạo. Xem xét cơ sở dữ liệu như triển khai cụ thể mô hình, về cơ bản chúng tôi thiết lập trình tự của quy trình bằng cách tách biệt giai đoạn xác định các nguyên tắc (cơ sở nào phải be) từ giai đoạn triển khai các nguyên tắc này khi triển khai cơ sở dữ liệu trong môi trường DBMS, hệ điều hành và ngôn ngữ lập trình cụ thể. Và, như thực tế cho thấy, luôn có sự khác biệt giữa việc triển khai cơ sở dữ liệu và các nguyên tắc xây dựng chúng. Sự khác biệt là hệ quả của nhiều lý do khác nhau, nhưng thông thường nhất đó là sự từ chối rõ ràng hoặc ngầm định đối với một số hạn chế cơ bản được áp đặt, ví dụ, bởi mô hình dữ liệu hoặc thuật toán xử lý cơ bản (tích hợp), ủng hộ một giải pháp cụ thể, theo ý kiến ​​của người thiết kế, chẳng hạn như sẽ hiệu quả hơn để hiểu hoặc xử lý dữ liệu.

Tầm quan trọng của việc tách biệt thiết kế ở mức độ trừu tượng khỏi việc triển khai thực tế là bằng cách khai báo các nguyên tắc, chúng ta cách xây dựng chúng tôi giới hạn phạm vi ứng dụng. Thứ nhất, quy mô và độ phức tạp của vấn đề cần phảiđược giảm đến mức có thể thực hiện được trong các điều kiện cụ thể - tài nguyên môi trường, tính chuyên nghiệp của người thiết kế, sự chuẩn bị của người dùng, v.v. Thứ hai, vì cơ sở dữ liệu, theo định nghĩa, được dùng để đa chức năng sử dụng nhiều người dùng, đồng thời - đối với các yêu cầu dịch vụ, không lường trước được Khi thiết kế, việc tuyên bố rõ ràng về các nguyên tắc như vậy sẽ giúp không gây hiểu lầm cho người dùng và không tạo ra các ứng dụng để giải quyết các vấn đề mà do sự khác biệt cơ bản của chúng so với những vấn đề được xem xét trong quá trình thiết kế, sẽ dẫn đến việc xử lý dữ liệu không hiệu quả. Thứ ba, thiết kế là một quá trình phối hợp các quan điểm của hai đối tượng chính: người dùng và người thiết kế cơ sở dữ liệu. Người dùng được đặc trưng bởi các yêu cầu về mức độ tổng quát và bề rộng trình bày cao (chứ không phải sự rườm rà của các mô tả chi tiết), cho phép anh ta có được đủ thông tin mà không tốn nhiều thời gian hoặc nguồn lực trí tuệ. Đối với quản trị viên thiết kế và tối ưu hóa hệ thống cơ sở dữ liệu, cần có mức độ chi tiết và hình thức hóa cao để đảm bảo tính hợp lệ của các giải pháp kỹ thuật cũng như khả năng tự động hóa thiết kế.

7.2. Kiểu chữ của mô hình

Sự khác biệt chính giữa bất kỳ phương pháp trình bày thông tin nào nằm ở cách nắm bắt ngữ nghĩa của lĩnh vực chủ đề. Tuy nhiên, cần đặc biệt lưu ý rằng đối với mọi cấp độ và đối với bất kỳ phương pháp thể hiện lĩnh vực chủ đề nào (nhưng đối với chúng tôi, điều quan trọng là trong bối cảnh tạo và sử dụng cơ sở dữ liệu máy) cơ sở của việc hiển thị (tức là sự hình thành thực tế của biểu diễn) là mã hóa niệm và mối quan hệ giữa các khái niệm. Một hệ thống đa cấp của các mô hình biểu diễn thông tin được minh họa slide 2, 3, 4 (Loại hình mô hình) .

Một giai đoạn quan trọng trong quá trình phát triển bất kỳ hệ thống thông tin nào là tiến hành phân tích hệ thống: chính thức hóa lĩnh vực chủ đề và trình bày hệ thống như một tập hợp các thành phần. Phân tích hệ thống một mặt cho phép hiểu rõ hơn “điều gì cần phải làm” và “ai cần làm việc đó” (nhà phân tích, nhà phát triển, người quản lý, người dùng) và mặt khác, để theo dõi những thay đổi trong mô hình theo xem xét theo thời gian và cập nhật dự án.

Sự phân rã, làm cơ sở cho phân tích hệ thống, có thể mang tính chức năng (xây dựng hệ thống phân cấp chức năng) hoặc dựa trên đối tượng.

Tuy nhiên, trong hầu hết các hệ thống, chẳng hạn như cơ sở dữ liệu, kiểu dữ liệu là phần tử tĩnh hơn cách chúng được xử lý. Do đó, các phương pháp phân tích hệ thống như Sơ đồ luồng dữ liệu đã nhận được sự phát triển chuyên sâu. Ngược lại, sự phát triển của cơ sở dữ liệu quan hệ đã kích thích sự phát triển của các phương pháp xây dựng mô hình dữ liệu, và đặc biệt, Sơ đồ ER (Sơ đồ mối quan hệ thực thể ). Nhưng cả sơ đồ dữ liệu và phân rã chức năng chỉ cung cấp một mặt cắt ngang nhất định của lĩnh vực chủ đề đang được nghiên cứu, nhưng không cho phép người ta có được sự biểu diễn của toàn bộ hệ thống.

Các phương pháp hiển thị được sử dụng ở giai đoạn xây dựng mô hình dữ liệu, phản ánh phương pháp xác định các phần tử và kết nối, nhưng quan trọng nhất là trong bối cảnh biểu diễn tương lai của chúng trong không gian bộ nhớ một chiều của máy tính, cũng khác nhau. Các mô hình được chia thành thực tế - tập trung vào việc trình bày thông tin có cấu trúc tốt và tài liệu - thể hiện cách phản ánh thông tin bán cấu trúc phổ biến nhất. Nếu trong trường hợp đầu tiên họ nói về các mô hình dữ liệu quan hệ, phân cấp hoặc mạng, thì trong trường hợp thứ hai họ nói về mạng ngữ nghĩa và mô hình tài liệu. Mặc dù, việc phân chia thành thực tế và tư liệu trong nhóm mô hình này khá có điều kiện. Một tài liệu dưới dạng một chuỗi các trường có thể được biểu diễn, trong số những thứ khác, bằng một mô hình quan hệ. Và trong trường hợp này, việc lựa chọn một giải pháp chuyên biệt thường được quyết định bởi yêu cầu về hiệu quả tổng thể.

Khi thiết kế hệ thống thông tin, các thuộc tính của đối tượng (đặc điểm của chúng) được xác định bởi các thuộc tính. Chính các giá trị thuộc tính cho phép xác định cả các đối tượng (loại đối tượng) khác nhau trong vùng chủ đề và các trường hợp khác nhau của chúng giữa các đối tượng cùng loại. Việc biểu diễn các thuộc tính được mô hình hóa thuận tiện nhất bằng các mối quan hệ lý thuyết tập hợp. Mối quan hệ được biểu diễn trực quan dưới dạng bảng, trong đó mỗi hàng là một bộ của mối quan hệ và mỗi cột (miền) đại diện cho một tập hợp các giá trị thuộc tính. Danh sách các tên thuộc tính quan hệ tạo thành lược đồ quan hệ và tập hợp các lược đồ quan hệ được sử dụng để biểu diễn cơ sở dữ liệu, lần lượt tạo thành lược đồ cơ sở dữ liệu.

Biểu diễn các lược đồ cơ sở dữ liệu dưới dạng sơ đồ mối quan hệ giúp đơn giản hóa quy trình thiết kế cơ sở dữ liệu. Điều này giải thích việc tạo ra si các hệ thống trong đó thiết kế cơ sở dữ liệu được thực hiện dưới dạng liên quan mô hình dữ liệu và làm việc với cơ sở dữ liệu được DBMS hỗ trợmột trong những loại được mô tả trong sách hướng dẫn này.

Bằng cách này hay cách khác, mô hình dữ liệu phải cung cấp cơ sở để mô tả dữ liệu và thao tác dữ liệu, cũng như cung cấp phương tiện phân tích và tổng hợp cấu trúc dữ liệu. Bất kỳ mô hình theo được xây dựng ít nhiều chính xác theo quan điểm toán học, bản thân nó tạo ra các đối tượng để nghiên cứu và bắt đầu sống như sẽ song song với thực hành.

Mô hình quan hệ được đưa ranykh trực tiếp sử dụng khái niệm mối quan hệ làm cơ sở cho việc lập bản đồ. Nó gần nhất với cái gọi là mô hình khái niệm về môi trường chủ thể và thường làm cơ sở cho mô hình sau.

Không giống như các mô hình lý thuyết đồ thị, trong mô hình quan hệ, các kết nối giữa các mối quan hệ được triển khai ngầm và chúng được sử dụng trong đó. chìa khóa mối quan hệ. Ví dụ: mối quan hệ thuộc loại phân cấp được triển khai theo cơ chế khóa chính/khóa ngoài, khi mối quan hệ cấp dưới phải chứa một tập hợp các thuộc tính liên kết mối quan hệ này với mối quan hệ chính. Một tập hợp các thuộc tính như vậy trong mối quan hệ chính sẽ được gọi là khóa chính và trong mối quan hệ phụ - khóa phụ.

Sự tiến bộ trong việc phát triển các ngôn ngữ lập trình, chủ yếu liên quan đến việc gõ dữ liệu và sự xuất hiện của các ngôn ngữ hướng đối tượng, đã giúp tiếp cận việc phân tích các hệ thống phức tạp theo quan điểm biểu diễn phân cấp - các lớp đối tượng có đặc tính đóng gói , tính kế thừa và tính đa hình, các sơ đồ phản ánh không chỉ dữ liệu và các mối quan hệ của chúng mà còn cả các phương pháp xử lý dữ liệu.

Theo nghĩa này, cách tiếp cận hướng đối tượng là một phương pháp lai và cho phép hình thức hóa toàn bộ hệ thống một cách tự nhiên hơn. Do đó, điều này giúp giảm bớt rào cản hiện có giữa các nhà phân tích và nhà phát triển (nhà thiết kế và lập trình viên), tăng độ tin cậy của hệ thống và đơn giản hóa việc bảo trì, đặc biệt là tích hợp với các hệ thống khác.

7.3. Các giai đoạn thiết kế và mô hình hóa đối tượng

Thiết kế cơ sở dữ liệu là một quá trình có trật tự, chính thức nhằm tạo ra hệ thống mô tả có liên quan với nhau, những thứ kia. các mô hình miền như vậy kết nối (ghi lại) dữ liệu được lưu trữ trong cơ sở dữ liệu với các đối tượng miền được mô tả bởi dữ liệu này. Mục đích thực tế của những mô tả này là để đảm bảo rằng người dùng hầu như không biết gì về tổ chức dữ liệu trong cơ sở dữ liệu (vị trí vật lý của dữ liệu trong bộ nhớ và cơ chế tìm kiếm chúng), khi áp dụng một truy vấn vào cơ sở dữ liệu, sẽ có cơ hội thực tế để có được thông tin đầy đủ về tình trạng của đối tượng trong lĩnh vực chủ đề. (Slide 5 - Sân khấu và đối tượng)

Thiết kế bắt đầu bằng việc phân tích lĩnh vực chủ đề và xác định các yêu cầu chức năng cũng như các yêu cầu khác đối với hệ thống được thiết kế. Quá trình này sẽ được thảo luận chi tiết hơn bên dưới, nhưng ở đây chúng tôi lưu ý rằng thiết kế thường được thực hiện bởi một người (nhóm người) - nhà phân tích hệ thống (và trong thực tế, thường là quản trị viên cơ sở dữ liệu), người này có thể là người được chỉ định đặc biệt. nhân viên hoặc người dùng cơ sở dữ liệu trong tương lai, khá quen thuộc với việc xử lý dữ liệu máy.

Kết hợp các ý tưởng riêng lẻ về nội dung của cơ sở dữ liệu thu được từ khảo sát người dùng và ý tưởng của riêng mình về dữ liệu có thể cần thiết để giải quyết các vấn đề thực tế, trước tiên, nhà phân tích hệ thống tạo ra một mô tả không chính thức tổng quát về cơ sở dữ liệu được tạo. Mô tả này, được thực hiện bằng ngôn ngữ tự nhiên, biểu thức toán học, bảng, đồ thị và các công cụ khác dễ hiểu đối với tất cả những người làm việc về thiết kế cơ sở dữ liệu, được gọi là mô hình thông tin.

Mô hình hướng tới con người như vậy gần như hoàn toàn độc lập với các thông số vật lý của phương tiện lưu trữ dữ liệu, có thể là bộ nhớ của con người hoặc máy tính. Do đó, mô hình thông tin không thay đổi cho đến khi một số thay đổi trong thế giới thực (phần được gán cho lĩnh vực chủ đề) yêu cầu thay đổi mô hình của đoạn mô tả tương ứng để mô hình này tiếp tục phản ánh đầy đủ chủ đề. khu vực.

Các mô hình còn lại là định hướng máy. Với sự trợ giúp của họ, DBMS cho phép các chương trình và người dùng chỉ truy cập dữ liệu được lưu trữ bằng tên của họ mà không phải lo lắng về vị trí vật lý của dữ liệu này.

Vì dữ liệu được truy cập bằng một DBMS cụ thể nên các mô hình phải được trình bày bằng ngôn ngữ mô tả dữ liệu của DBMS này. Mô tả như vậy, được tạo bằng mô hình dữ liệu thông tin, được gọi là mô hình dữ liệu dữ liệu.

Để định vị và tìm kiếm dữ liệu trên các thiết bị lưu trữ bên ngoài, DBMS sử dụng mô hình vật lý dữ liệu.

Kiến trúc ba cấp được trình bày (cấp độ thông tin, dữ liệu và vật lý) giúp đảm bảo tính độc lập của dữ liệu được lưu trữ với các chương trình sử dụng chúng. Dữ liệu được lưu trữ có thể được ghi lại sang phương tiện khác hoặc cấu trúc vật lý của nó có thể được tổ chức lại, bao gồm cả việc thêm các trường cho ứng dụng mới, nhưng điều này sẽ chỉ kéo theo một sự thay đổi trong mô hình vật lý và có thể cả dữ liệu của dữ liệu. Điều chính là những thay đổi như vậy trong mô hình vật lý và dữ liệu sẽ không được người dùng hệ thống chú ý (chúng sẽ “minh bạch” đối với họ). Ngoài ra, tính độc lập của dữ liệu giúp có thể tạo ra các ứng dụng mới để giải quyết các vấn đề mới mà không phá hủy các vấn đề hiện có.

Đoạn trích trên ( Trang trình bày 6) vẫn còn phù hợp, mặc dù cuốn sách đã được xuất bản hơn 20 năm trước. Thật vậy, các công cụ thiết kế không ngừng phát triển, nhưng các nhiệm vụ mà giải pháp mà người dùng mong muốn được tự động hóa bằng cách sử dụng hệ thống cơ sở dữ liệu đã trở nên phức tạp hơn đáng kể và để sử dụng hiệu quả các công cụ tự động hóa và chính thức hóa thì cần phải hiểu bản chất của mô hình. hệ thống.

Từ quan điểm của các đối tượng mô hình hóa, cần phân biệt giữa mô hình miền và mô hình cơ sở dữ liệu. Các mô hình này được kết nối với nhau vì chúng thể hiện các hình ảnh của cùng một bản gốc - một tập hợp đối tượng nhất định trong thế giới thực, thông tin mà chúng ta dự định lưu trữ và xử lý bằng cơ sở dữ liệu được thiết kế. Bản chất của các mối quan hệ (và theo đó là sự khác biệt) cũng thể hiện trong quá trình thiết kế hệ thống cơ sở dữ liệu. Mô hình miền có nhiều khả năng được liên kết với cấp độ không chính thức của mô hình ngữ nghĩa và mô hình cơ sở dữ liệu được liên kết với cấp độ chính thức của hệ thống (và đặc biệt là DBMS).

Sự đa dạng của các mô hình cũng gắn liền với sự khác biệt trong các mô hình mô hình được sử dụng, về cơ bản xác định cách thức đại diện mối quan hệ giữa các đối tượng ở cấp độ cấu trúc dữ liệu. Từ quan điểm này, các mô hình quan hệ, mạng, phân cấp, đối tượng, đối tượng-quan hệ, tài liệu và các loại mô hình khác được phân biệt. Theo đó, các sơ đồ cơ sở dữ liệu được mô tả bằng phương tiện của chúng cũng khác nhau.

7.4. Phương pháp thiết kế cơ sở dữ liệu

Có hai cách tiếp cận chính để thiết kế cơ sở dữ liệu: giảm dần Và tăng dần (trang 7)

Tại tăng dần tiếp cận, công việc bắt đầu ngay từ đầucấp độ thấp hơn của các thuộc tính (tức là thuộc tính của các thực thể và mối quan hệ), dựa trênphân tích các kết nối hiện có giữa chúng được nhóm lại thành các mối quan hệ, trướctạo thành các loại thực thể và các kết nối giữa chúng. Tiếp theo chúng ta sẽ thảo luận chi tiếtquá trình bình thường hóa quan hệ, là một lựa chọn từ dưới lêncách tiếp cận chung để thiết kế cơ sở dữ liệu. Chuẩn hóa cung cấp tạo ra chuẩn mực mối quan hệ được xác định dựa trên sự phụ thuộc chức năng giữa các thuộc tính.

Cách tiếp cận từ dưới lên là phù hợp nhất cho thiết kếcơ sở dữ liệu đơn giản với số lượng thuộc tính tương đối nhỏ. Tuy nhiên, việc sử dụng phương pháp này trở nên phức tạp hơn đáng kể khi thiết kế cơ sở dữ liệu với số lượng lớn các thuộc tính, trong đó mọi thứ đều tồn tại.sự phụ thuộc chức năng hiện có là khó khăn. Bởi vìCác mô hình dữ liệu logic và khái niệm cho cơ sở dữ liệu phức tạp có thể chứa hàng trăm đến hàng nghìn thuộc tính, điều quan trọng là chọn một cách tiếp cận phù hợp.sẽ giúp đơn giản hóa giai đoạn thiết kế. Hơn nữa, trong giai đoạn đầu Việc xây dựng các yêu cầu dữ liệu có thể khó khănnhưng cài đặt tất cả các thuộc tính, phải được đưa vào mô hình dữ liệu.

Một chiến lược phù hợp hơn để thiết kế cơ sở dữ liệu phức tạp làcách sử dụng đi xuống cách tiếp cận này xác định trước mức độ ưu tiên của việc phát triển mô hình khái niệm của SbA. Mô hình này chứa một số thực thể và kết nối cấp cao, được tinh chỉnh (chi tiết và mở rộng) cho đến khi tất cả các đối tượng, thuộc tính và kết nối giữa chúng, phản ánh chi tiết cụ thể về nhiệm vụ của một SbA cụ thể, được xác định.

Ví dụ, trong trường hợp SbA phức tạp, cách tiếp cận từ dưới lên thường là một quy trình rất bất tiện đối với bản thân người thiết kế. Hơn nữa, nó xuất hiện ở đây hạn chế của mô hình quan hệ, đặc biệt: (trang 8)

- mô hình quan hệ không cung cấp đủ phương tiện để nắm bắt ý nghĩa của dữ liệu, tức là. ngữ nghĩa của lĩnh vực chủ đề không được cố định trực tiếp trong các mối quan hệ;

- Đối với nhiều ứng dụng, rất khó để mô hình hóa miền bài toán dựa trên bảng phẳng;

- mặc dù toàn bộ quá trình thiết kế diễn ra trên cơ sở tính đến các phụ thuộc nhưng mô hình quan hệ không có phương tiện biểu diễn (phản ánh ngữ nghĩa) của các phụ thuộc này;

- Mặc dù quá trình thiết kế bắt đầu bằng việc xác định một số đối tượng miền cần thiết cho ứng dụng ("thực thể") và xác định mối quan hệ giữa các thực thể này, mô hình dữ liệu quan hệ không cung cấp bất kỳ công cụ nào để phân biệt giữa các thực thể và mối quan hệ.

Ngoài những phương pháp thiết kế này,các cách tiếp cận khác, ví dụ, cách tiếp cận “tổng quát đến cụ thể” hoặc “hỗn hợp”chiến lược thiết kế". Một cách tiếp cận" Từ chung đến cụ thể"gợi nhớ đến Nishocách tiếp cận này, nhưng khác ở chỗ một tập hợp các nguyên tắc cơ bản được xác định trước tiênbất kỳ thực thể nào với việc mở rộng phạm vi các thực thể đang được xem xét sau đó, các kết nối và thuộc tính tương tác với các kết nối được xác định ban đầucác thực thể. TRONG chiến lược hỗn hợp tăng dần và giảm dần được sử dụng đầu tiêncác phương pháp đi bộ để tạo ra các phần khác nhau của mô hình, sau đó mọi thứcác mảnh ghép lại thành một tổng thể duy nhất.

Nhìn về phía trước một chút, chúng tôi lưu ý mối quan hệ giữa hai phương pháp nổi tiếng để lập mô hình cấp độ thông tin - phòng cấp cứu -sơ đồ và phương pháp chuẩn hóa, thường được coi là thay thế. Trong thực tế, việc chuẩn hóa bằng cách sử dụng các phương pháp được chính thức hóa tốt cung cấp sự phân tách các quan hệ ban đầu (các biến) có chiều lớn thành tập hợp lớn nhất có thể của các quan hệ, nhưng có chiều thấp hơn. Những phương pháp này không phụ thuộc vào đặc điểm của môn học, nhưng kết quả là chúng không cho phép chúng tôi xác định mối quan hệ ban đầu và theo đó, ngữ nghĩa của dữ liệu được xử lý. Vì điều này thuận lợi sử dụng các kỹ thuật như phòng cấp cứu -sơ đồ - chúng được đặc trưng bởi các phương pháp tiếp cận công nghệ thiết kế từ trên xuống và đưa ra ý tưởng “nói chung”, nhưng chính xác vì lý do này (do tính đơn giản so sánh) chúng không cho phép thiết kế chính thức của phần đế. là, chúng ta có thể nói rằng phương pháp chuẩn hóa và phòng cấp cứu -sơ đồ về cơ bản là bổ sung.

7.5. Các mô hình thông tin (phân tích hệ thống) của lĩnh vực chủ đề

Bản thân cơ sở dữ liệu có giá trị tương đối. Cơ sở dữ liệu luôn là quan trọng nhất, nhưng chỉ một trong thành phần của một số hệ thống thông tin. Và cần lưu ý rằng bất kỳ hệ thống thông tin nào nhằm mục đích quản lý vận hành của doanh nghiệp hoặc lưu trữ và truy xuất tài liệu không chỉ là chương trình, dữ liệu và thông tin liên lạc mà còn cả con người (khách hàng, người dùng, nhà phân tích, nhà phát triển), cơ cấu tổ chức cũng như mục tiêu, động lực làm việc của doanh nghiệp hoặc cá nhân. Và tất cả các thành phần này phải dễ hiểu đối với cả người thiết kế và người dùng, đồng thời phải được kết nối một cách nhất quán trong một hệ thống.

Ý tưởng chính của quá trình phối hợp như vậy là nó phải bắt đầu bằng việc phân tích các đặc điểm quan trọng nhất của lĩnh vực chủ đề, xem xét các khía cạnh nội dung quan trọng nhất. Và nó phải được thực hiện không phải “tinh thần” hay “bằng lời nói”, mà dựa trên những mô tả (mô hình) rõ ràng về các đối tượng trong lĩnh vực chủ đề, cho phép người ta nhìn thấy tất cả các mối quan hệ thiết yếu. Nhưng cần lưu ý rằng những nỗ lực sử dụng các ký hiệu thông thường của các mô hình hình thức (cấu trúc, đối tượng hoặc bất kỳ mô hình nào khác) ở giai đoạn này sẽ dẫn đến mức độ thể hiện lĩnh vực chủ đề thấp hơn (chi tiết hơn và đồng thời giới hạn về thời gian) hơn mức cần thiết. để có sự hiểu biết chung.

Nhìn chung, có hai cách tiếp cận để xác định thành phần và cấu trúc của một môn học. (Slide 9 Chức năng - Tiếp cận đối tượng)

chức năngCách tiếp cận giả định rằng thiết kế bắt đầu bằng việc phân tích các nhiệm vụ và theo đó là các chức năng đảm bảo thực hiện các nhu cầu thông tin.

Tại khách quan Cách tiếp cận (chủ đề), nhu cầu thông tin của người dùng (nhiệm vụ) không được cố định chặt chẽ và trọng tâm chính tập trung vào việc xác định các đối tượng thiết yếu - đối tượng và kết nối, thông tin về những đối tượng này có thể được sử dụng trong các nhiệm vụ được áp dụng của người dùng.

Tính quy ước của sự phân chia như vậy là khá rõ ràng, do đó, trong thực tế, các phương án thỏa hiệp được sử dụng để khi hệ thống phát triển, sẽ mở rộng cả thành phần đối tượng và phạm vi nhiệm vụ được áp dụng.

Mục đích của việc phân tích hệ thống của lĩnh vực chủ đề ở giai đoạn thiết kế là làm nổi bật lĩnh vực chủ đề Làm sao một hệ thống các đối tượng và các mối quan hệ của chúng,đã xác định yêu cầu về chức năng và thông tin cho việc trình bày tiếp theo của chúng dưới dạng một hệ thống dữ liệu được kết nối với nhau.

Kết quả chính của giai đoạn phân tích hệ thống là việc xác định mô hình mô hình thông tin (thông tin): các yêu cầu đối với phương tiện trình bày hệ thống được xác định dựa trên phân tích mức độ cấu trúc của thông tin và bản chất nhận thức của người dùng về ngữ nghĩa của nó (chính xác/gần đúng, rõ ràng/không chắc chắn).

Ví dụ, sự lựa chọn hình thức đại diện thuộc tính các đối tượng của lĩnh vực chủ đề, theo đó, sẽ dẫn tới việc lựa chọn khung mẫu cơ sở dữ liệu thực tế, MỘT bằng lời nói- nhu cầu lựa chọn cơ sở dữ liệu tài liệu. Trong phần trình bày sau đây, chúng tôi sẽ chỉ xem xét quy trình thiết kế và các công cụ cho trường hợp cơ sở dữ liệu thực tế sử dụng mô hình quan hệ.

Lược đồ khái niệm kết quả của cơ sở dữ liệu (theo mô hình ngữ nghĩa) sau đó được chuyển đổi thành lược đồ quan hệ.

7.6. Mô hình dữ liệu

Nhiệm vụ của giai đoạn tiếp theo trong việc thiết kế hệ thống cơ sở dữ liệu là chọn một DBMS phù hợp và ánh xạ các đặc tả của mô hình thông tin miền vào môi trường của nó (cấu trúc dữ liệu). Nói cách khác, mô hình miền của hệ thống đang được phát triển phải được trình bày dưới dạng mô hình dữ liệu mức khái niệm của DBMS cụ thể đã chọn. Giai đoạn này được gọi là thiết kế cơ sở dữ liệu logic (hoặc dữ liệu) và kết quả của nó là sơ đồ cơ sở dữ liệu khái niệm, bao gồm định nghĩa tất cả các thành phần thông tin (đơn vị) và các mối quan hệ, bao gồm định nghĩa các loại, đặc điểm và tên.

Mặc dù thiết kế khoa học dữ liệu không hoạt động với các bản ghi vật lý mà với các khái niệm logic gắn liền với cấu trúc của cơ sở dữ liệu, tuy nhiên, các tính năng trình bày dữ liệu, quy tắc và ngôn ngữ để tổng hợp và thao tác dữ liệu có ảnh hưởng quyết định. Không phải tất cả các loại mối quan hệ, chẳng hạn như nhiều-nhiều, đều có thể được biểu diễn trực tiếp trong mô hình logic.

Ngoài ra, có thể có nhiều tùy chọn để ánh xạ mô hình thông tin của lĩnh vực chủ đề vào mô hình dữ liệu của cơ sở dữ liệu. Ở đây cần tính đến ảnh hưởng của hai yếu tố quan trọng sau đây liên quan đến thực tiễn phát triển cơ sở dữ liệu.

Thứ nhất, các kết nối của khu vực chủ đề có thể được hiển thị theo hai cách, cả khai báo - trong sơ đồ logic và thủ tục - bằng cách xử lý các kết nối thông qua các mô-đun phần mềm xử lý (liên kết) dữ liệu được lưu trữ tương ứng.

Thứ hai, bản chất của việc xử lý thông tin có thể là một yếu tố quan trọng. Ví dụ: việc truy cập thường xuyên vào dữ liệu được xử lý chung rõ ràng ngụ ý việc lưu trữ chung của chúng và dữ liệu (đặc biệt là có kích thước lớn) hiếm khi được truy cập phải được lưu trữ riêng biệt với dữ liệu được sử dụng thường xuyên.

7.7. Mô hình vật lý

Giai đoạn thiết kế cơ sở dữ liệu vật lý thường bao gồm:

- lựa chọn phương pháp tổ chức cơ sở dữ liệu;

- phát triển đặc tả lược đồ nội bộ bằng cách sử dụng mô hình dữ liệu cấp độ nội bộ của nó;

- mô tả việc ánh xạ một sơ đồ khái niệm tới một sơ đồ bên trong.

Điều quan trọng cần lưu ý là, không giống như các DBMS ban đầu, nhiều hệ thống hiện đại không cung cấp cho nhà phát triển bất kỳ lựa chọn nào ở giai đoạn này. Trong thực tế, các vấn đề của việc thiết kế mô hình vật lý bao gồm việc lựa chọn sơ đồ sắp xếp dữ liệu (tách thành các tệp hoặc kiểu dữ liệu).đột kích -array) và xác định số lượng cũng như loại chỉ mục (ví dụ: được nhóm hoặc không được nhóm trong trường hợp Máy chủ MS SQL).

Phương thức lưu trữ cơ sở dữ liệu được xác định tự động bởi các cơ chế DBMS “theo mặc định” dựa trên các đặc tả của lược đồ cơ sở dữ liệu khái niệm và lược đồ bên trong không được sử dụng rõ ràng trong các hệ thống như vậy.

Cũng cần lưu ý rằng các lược đồ cơ sở dữ liệu bên ngoài thường được xây dựng trong quá trình phát triển ứng dụng.

7.8. Thiết kế các công cụ tự động hóa

Kiến thức chính thức về một lĩnh vực chủ đề thường có thể được trình bày dưới dạng mô tả văn bản: bộ mô tả công việc, quy tắc kinh doanh, v.v. Tuy nhiên, cách biểu diễn mô hình miền bằng văn bản không hiệu quả. Nhiều thông tin và hữu ích hơn khi phát triển cơ sở dữ liệu và hệ thống thông tin là các mô tả về lĩnh vực chủ đề, được thực hiện bằng cách sử dụng các ký hiệu đồ họa chuyên dụng để thực hiện các phương pháp biểu diễn kiến ​​thức về lĩnh vực chủ đề. Nổi tiếng nhất hiện nay là các phương pháp phân tích cấu trúc SADT (Kỹ thuật phân tích và thiết kế có cấu trúc) ) và ký hiệu dựa trên nó IDEF 0, sơ đồ mảng dữ liệu, kỹ thuật phân tích hướng đối tượng UML (Ngôn ngữ mô hình hóa thống nhất ) v.v. Bất kỳ mô hình nào trong số này một mặt đều mô tả các quá trình xảy ra trong lĩnh vực chủ đề và mặt khác là dữ liệu được các quá trình này sử dụng.

Hệ thống mô hình hoàn chỉnh nhất, dựa trên các phương pháp mô hình hóa chức năng, thông tin và hành vi của SbA, được trình bày trong họ tiêu chuẩn IDEF (Định nghĩa tích hợp )(trang 10).

Phương pháp thiết kế khái niệm, dựa trên các kỹ thuật đồ họa trực quan, đã cung cấp cho các nhà phát triển hệ thống thông tin những phương pháp chính thức, chặt chẽ để mô tả hệ thống thông tin và các quyết định kỹ thuật được đưa ra. Các mô hình này về cơ bản đại diện cho một hệ thống thỏa thuận đảm bảo sự hiểu biết lẫn nhau giữa nhà phân tích kinh doanh, người đại diện cho thực tế của lĩnh vực chủ đề và lập trình viên (hoặc công cụ phần mềm), người tạo ra mô hình dữ liệu để phản ánh trạng thái của SbA này. Nếu các thỏa thuận được triển khai chính xác trong các sản phẩm phần mềm dựa trên phương pháp này thì một hệ thống tự động có thể “đọc” các mô hình do nhà phân tích phát triển sẽ cho phép bạn kiểm soát cú pháp của mô hình và cuối cùng tạo ra lược đồ dữ liệu.

Theo phương pháp thiết kế khái niệm, phần mềm chuyên dụng và các công cụ công nghệ thuộc loại đặc biệt đã xuất hiện - các công cụ CASE thực hiện công nghệ tạo và duy trì IS.

Công nghệ CASE là một phương pháp thiết kế IS, đồng thời là một bộ công cụ cho phép bạn lập mô hình trực quan một lĩnh vực chủ đề, phân tích mô hình này ở tất cả các giai đoạn phát triển và bảo trì IS cũng như phát triển ứng dụng phù hợp với nhu cầu thông tin của người dùng.

Các công cụ CASE, theo định hướng chức năng của chúng đối với các quy trình nhất định trong vòng đời IS, có thể được chia thành các nhóm sau(slide 11 – SAS.E.).


Các ngôn ngữ hình thức được sử dụng để thể hiện lĩnh vực chủ đề không cho phép mô tả Tất cả các mối quan hệ mà người thiết kế coi là quan trọng. Mặt khác, nhiều dự án (và đặc biệt là những dự án đang được xem xét ví dụ ) được coi là khá đơn giản và các giải pháp thiết kế có vẻ hiển nhiên. Ngoài ra, một lập trình viên có kinh nghiệm luôn có thể đưa ra một số cách thực nghiệm và có lẽ thực sự hiệu quả để trình bày và xử lý thông tin cần thiết theo mục tiêu. Tuy nhiên, điều này có nghĩa là từ bỏ chủ nghĩa hình thức duy nhất, cùng với sự gia tăng lượng dữ liệu và kết nối. , làm phức tạp đáng kể các vấn đề về quản lý cơ sở dữ liệu và đặc biệt là hiểu tổ chức người dùng và các phương pháp truy cập.

Sẽ đúng hơn nếu nói về tính không chính thức gắn liền với việc không thể biện minh được rõ ràng các đối tượng lựa chọn (từ đời thực) của các công cụ được sử dụng để mô hình hóa.

30.03.17 3351

Bằng cách làm theo các nguyên tắc được mô tả trong bài viết này, bạn có thể tạo cơ sở dữ liệu hoạt động như mong đợi và có thể được điều chỉnh cho phù hợp với các yêu cầu mới trong tương lai. Chúng ta sẽ xem xét các nguyên tắc cơ bản thiết kế cơ sở dữ liệu cũng như cách tối ưu hóa nó.

Quy trình thiết kế cơ sở dữ liệu

Cơ sở dữ liệu có cấu trúc hợp lý:

  • Giúp tiết kiệm dung lượng ổ đĩa bằng cách loại bỏ dữ liệu không cần thiết;
  • Duy trì tính chính xác và toàn vẹn của dữ liệu;
  • Cung cấp khả năng truy cập dữ liệu thuận tiện.

Phát triển cơ sở dữ liệu bao gồm các giai đoạn sau:

  1. Phân tích yêu cầu hoặc xác định mục đích cơ sở dữ liệu;
  2. Tổ chức dữ liệu trong bảng;
  3. Chỉ định khóa chính và phân tích các mối quan hệ;
  4. Chuẩn hóa các bảng.

Chúng ta hãy xem xét từng giai đoạn thiết kế cơ sở dữ liệu biết thêm chi tiết. Xin lưu ý rằng hướng dẫn này bao gồm mô hình cơ sở dữ liệu quan hệ của Edgar Codd, được viết bằng SQL ( thay vì các mô hình phân cấp, mạng hoặc đối tượng).

Phân tích yêu cầu: Xác định mục đích của cơ sở dữ liệu

Ví dụ: nếu bạn đang tạo cơ sở dữ liệu cho thư viện công cộng, bạn cần xem xét cách cả người đọc và thủ thư nên truy cập cơ sở dữ liệu.

Dưới đây là một số cách để thu thập thông tin trước khi tạo cơ sở dữ liệu:

  • Phỏng vấn những người sẽ sử dụng nó;
  • Phân tích các hình thức kinh doanh như hóa đơn, lịch trình, khảo sát;
  • Xem xét tất cả các hệ thống dữ liệu hiện có ( bao gồm các tập tin vật lý và kỹ thuật số).

Bắt đầu bằng cách thu thập dữ liệu hiện có sẽ được đưa vào cơ sở dữ liệu. Tiếp theo, xác định loại dữ liệu bạn muốn lưu. Cũng như các đối tượng mô tả dữ liệu này. Ví dụ:

Khách hàng

  • Địa chỉ;
  • Thành phố, Tiểu bang, Mã Zip;
  • Địa chỉ email.

Các mặt hàng

  • Tên;
  • Giá;
  • Số lượng trong kho;
  • Số lượng đặt hàng.

Đơn đặt hàng

  • Số thứ tự;
  • Đại diện bán hàng;
  • Ngày của;
  • Sản phẩm;
  • Số lượng;
  • Giá;
  • Giá.

Khi thiết kế cơ sở dữ liệu quan hệ, thông tin này sau này sẽ trở thành một phần của từ điển dữ liệu, mô tả các bảng và trường của cơ sở dữ liệu. Chia thông tin thành những phần nhỏ nhất có thể. Ví dụ: hãy cân nhắc việc tách các trường địa chỉ đường phố và tiểu bang để bạn có thể lọc mọi người theo tiểu bang nơi họ sinh sống.

Khi bạn đã quyết định dữ liệu nào sẽ được đưa vào cơ sở dữ liệu, dữ liệu sẽ đến từ đâu và cách sử dụng dữ liệu đó, bạn có thể bắt đầu lập kế hoạch cho cơ sở dữ liệu thực tế.

Cấu trúc cơ sở dữ liệu: các khối xây dựng

Bước tiếp theo là thể hiện trực quan cơ sở dữ liệu. Để làm được điều này, bạn cần biết chính xác cơ sở dữ liệu quan hệ được cấu trúc như thế nào. Trong cơ sở dữ liệu, dữ liệu liên quan được nhóm thành các bảng, mỗi bảng bao gồm các hàng và cột.

Để chuyển đổi danh sách dữ liệu thành bảng, hãy bắt đầu bằng cách tạo bảng cho từng loại đối tượng, chẳng hạn như sản phẩm, doanh số, khách hàng và đơn hàng. Đây là một ví dụ:

Mỗi hàng trong bảng được gọi là một bản ghi. Hồ sơ bao gồm thông tin về điều gì đó hoặc ai đó, chẳng hạn như một khách hàng cụ thể. Cột (còn gọi là trường hoặc thuộc tính) chứa cùng loại thông tin được hiển thị cho mỗi bản ghi, ví dụ: địa chỉ của tất cả khách hàng được liệt kê trong bảng.

Để đảm bảo tính nhất quán giữa các bản ghi khi thiết kế mô hình cơ sở dữ liệu của bạn, hãy chỉ định loại dữ liệu thích hợp cho từng cột. Các kiểu dữ liệu phổ biến bao gồm:

  • CHAR - độ dài văn bản cụ thể;
  • VARCHAR - văn bản có độ dài khác nhau;
  • TEXT - số lượng lớn văn bản;
  • INT là số nguyên dương hoặc âm;
  • FLOAT , DOUBLE — số dấu phẩy động;
  • BLOB - dữ liệu nhị phân.

Một số DBMS cũng cung cấp kiểu dữ liệu Autonumber, kiểu dữ liệu này tự động tạo ra một số duy nhất trên mỗi hàng.

Trong cách biểu diễn trực quan của cơ sở dữ liệu, mỗi bảng sẽ được biểu diễn bằng một khối trong sơ đồ. Tiêu đề của mỗi khối phải nêu rõ dữ liệu trong bảng đó mô tả gì và các thuộc tính phải được liệt kê bên dưới:

Tại thiết kế cơ sở dữ liệu thông tin bạn cần quyết định thuộc tính nào, nếu có, sẽ đóng vai trò là khóa chính cho mỗi bảng. Khóa chính ( PK) là mã định danh duy nhất cho đối tượng này. Với nó, bạn có thể chọn dữ liệu của một khách hàng cụ thể, ngay cả khi bạn chỉ biết giá trị đó.

Các thuộc tính được chọn làm khóa chính phải là duy nhất, không thể thay đổi và không thể được đặt thành NULL ( chúng không thể trống). Vì lý do này, số đơn hàng và tên người dùng là khóa chính phù hợp, nhưng số điện thoại hoặc địa chỉ thì không. Bạn cũng có thể sử dụng nhiều trường cùng lúc làm khóa chính ( đây được gọi là khóa tổng hợp).

Khi đến lúc tạo cơ sở dữ liệu thực tế, bạn triển khai cả cấu trúc logic và vật lý thông qua ngôn ngữ định nghĩa dữ liệu được DBMS của bạn hỗ trợ.

Bạn cũng cần đánh giá kích thước cơ sở dữ liệu của mình để đảm bảo rằng bạn có thể đạt được mức hiệu suất cần thiết và có đủ không gian để lưu trữ dữ liệu.

Tạo mối quan hệ giữa các thực thể

Bây giờ dữ liệu đã được chuyển thành bảng, chúng ta cần phân tích mối quan hệ giữa chúng. Độ phức tạp của cơ sở dữ liệu được xác định bởi số lượng phần tử tương tác giữa hai bảng có liên quan. Việc xác định độ phức tạp giúp đảm bảo rằng bạn chia dữ liệu thành các bảng theo cách hiệu quả nhất.

Mỗi đối tượng có thể được kết nối với nhau bằng cách sử dụng một trong ba loại mối quan hệ:

Giao tiếp một-một

Khi chỉ có một thể hiện của đối tượng A cho mỗi thể hiện của đối tượng B, chúng được cho là có mối quan hệ một-một ( thường được ký hiệu là 1:1). Bạn có thể biểu thị loại mối quan hệ này trong sơ đồ ER bằng một đường có dấu gạch ngang ở mỗi đầu:

Nếu bạn không có lý do gì để tách dữ liệu này khi thiết kế và phát triển cơ sở dữ liệu thì mối quan hệ 1:1 thường chỉ ra rằng tốt hơn là nên kết hợp các bảng này thành một.

Nhưng trong một số trường hợp nhất định, việc tạo bảng có mối quan hệ 1:1 sẽ hợp lý hơn. Nếu bạn có trường dữ liệu tùy chọn, chẳng hạn như "mô tả", được để trống cho nhiều bản ghi, thì bạn có thể di chuyển tất cả mô tả vào một bảng riêng biệt, loại bỏ các trường trống và cải thiện hiệu suất cơ sở dữ liệu.

Để đảm bảo dữ liệu có mối tương quan chính xác, bạn cần đưa ít nhất một cột giống nhau vào mỗi bảng. Nhiều khả năng đây sẽ là khóa chính.

Giao tiếp một-nhiều

Những mối quan hệ này xảy ra khi một bản ghi trong một bảng có liên quan đến nhiều bản ghi trong một bảng khác. Ví dụ: một khách hàng có thể đặt nhiều sách hoặc một độc giả có thể mượn nhiều cuốn sách từ thư viện. Mối quan hệ một-nhiều (1:M) được biểu thị bằng cái gọi là dấu chân quạ, như trong ví dụ này:

Để triển khai mối quan hệ 1:M, hãy thêm khóa chính từ bảng "một" làm thuộc tính cho bảng kia. Nếu khóa chính được chỉ định theo cách này trong một bảng khác thì nó được gọi là khóa ngoại. Bảng ở phía "1" của mối quan hệ là bảng cha với bảng con ở phía bên kia.

Giao tiếp nhiều-nhiều

Khi một số đối tượng của một bảng có thể liên quan đến một số đối tượng của bảng khác. Họ nói họ có mối liên hệ" nhiều nhiều» ( M:N). Ví dụ, trong trường hợp sinh viên và khóa học, vì một sinh viên có thể tham gia nhiều khóa học và mỗi khóa học có thể có nhiều sinh viên tham gia.

Trong sơ đồ ER, các mối quan hệ này được thể hiện bằng các dòng sau:

Khi thiết kế cấu trúc cơ sở dữ liệu, không thể thực hiện kiểu kết nối này. Thay vào đó, bạn cần chia chúng thành hai mối quan hệ một-nhiều.

Để làm điều này, bạn cần tạo một thực thể mới giữa hai bảng này. Nếu có mối quan hệ M:N giữa doanh số bán hàng và sản phẩm, bạn có thể gọi đối tượng mới này là " đã bán_sản phẩm", vì nó sẽ chứa dữ liệu cho mỗi lần bán hàng. Cả bảng doanh số và bảng sản phẩm sẽ có mối quan hệ 1:M với sell_products . Loại đối tượng trung gian này được gọi là bảng liên kết, đối tượng kết hợp hoặc bảng liên kết trong nhiều mô hình khác nhau.

Mỗi mục trong bảng quan hệ sẽ tương ứng với hai thực thể từ các bảng lân cận. Ví dụ: một bảng kết nối giữa sinh viên và khóa học có thể trông như thế này:

Bắt buộc hay không?

Một cách khác để phân tích các kết nối là xem xét mặt nào của mối quan hệ phải tồn tại để mặt kia tồn tại. Mặt tùy chọn có thể được đánh dấu bằng một vòng tròn trên đường thẳng. Ví dụ: một quốc gia phải tồn tại để có đại diện tại Liên hợp quốc chứ không phải ngược lại:

Hai đối tượng có thể phụ thuộc lẫn nhau ( cái này không thể tồn tại nếu không có cái kia).

Kết nối đệ quy

Đôi khi khi thiết kế cơ sở dữ liệu, một bảng sẽ trỏ đến chính nó. Ví dụ: một bảng nhân viên có thể có thuộc tính "người quản lý" đề cập đến một người khác trong cùng một bảng. Điều này được gọi là liên kết đệ quy.

Kết nối bổ sung

Các kết nối không liên quan là những kết nối được thể hiện nhiều lần. Thông thường, bạn có thể xóa một trong những mối quan hệ này mà không làm mất bất kỳ thông tin quan trọng nào. Ví dụ: nếu đối tượng “học sinh” có mối quan hệ trực tiếp với một đối tượng khác gọi là “giáo viên”, nhưng cũng có mối quan hệ gián tiếp với giáo viên thông qua “môn học” thì bạn cần loại bỏ mối quan hệ giữa “học sinh” và “giáo viên”. Bởi vì cách duy nhất để học sinh được phân công giáo viên là thông qua các môn học.

Chuẩn hóa cơ sở dữ liệu

Sau khi thiết kế cơ sở dữ liệu sơ bộ, bạn có thể áp dụng các quy tắc chuẩn hóa để đảm bảo rằng các bảng được cấu trúc chính xác.

Đồng thời, không phải tất cả cơ sở dữ liệu đều cần được chuẩn hóa. Nói chung, cơ sở dữ liệu xử lý giao dịch theo thời gian thực ( OLTP), phải được chuẩn hóa.

Cơ sở dữ liệu với xử lý phân tích tương tác ( OLAP), cho phép phân tích dữ liệu dễ dàng hơn và nhanh hơn, có thể hiệu quả hơn với một mức độ không chuẩn hóa nhất định. Tiêu chí chính ở đây là tốc độ tính toán. Mỗi hình thức hoặc mức độ chuẩn hóa bao gồm các quy tắc liên quan đến các hình thức thấp hơn.

Hình thức chuẩn hóa đầu tiên

Hình thức chuẩn hóa đầu tiên ( viết tắt 1NF) phát biểu rằng trong thời gian thiết kế cơ sở dữ liệu logic Mỗi ô trong bảng chỉ có thể có một giá trị chứ không phải danh sách các giá trị. Do đó, bảng như bảng bên dưới không tương ứng với 1NF:

Bạn có thể muốn khắc phục hạn chế này bằng cách chia dữ liệu thành các cột bổ sung. Nhưng điều này cũng trái với quy tắc: một bảng có các nhóm thuộc tính trùng lặp hoặc có liên quan chặt chẽ với nhau sẽ không tuân theo hình thức chuẩn hóa đầu tiên. Ví dụ: bảng bên dưới không tương ứng với 1NF:

Thay vào đó, trong quá trình thiết kế cơ sở dữ liệu vật lý, hãy chia dữ liệu thành nhiều bảng hoặc bản ghi cho đến khi mỗi ô chỉ chứa một giá trị và không có cột bổ sung. Dữ liệu như vậy được coi là được chia nhỏ thành kích thước nhỏ nhất có thể sử dụng được. Trong bảng trên các bạn có thể tạo thêm một bảng " Chi tiết bán hàng”, sẽ phù hợp với các sản phẩm cụ thể với doanh số bán hàng. "Bán hàng" sẽ có mối quan hệ 1:M với " Chi tiết bán hàng».

Hình thức chuẩn hóa thứ hai

Hình thức chuẩn hóa thứ hai ( 2NF) quy định rằng mỗi thuộc tính phải phụ thuộc hoàn toàn vào khóa chính. Mỗi thuộc tính phải phụ thuộc trực tiếp vào toàn bộ khóa chính và không được gián tiếp thông qua thuộc tính khác.

Ví dụ: thuộc tính “tuổi” phụ thuộc vào “ngày sinh”, do đó, thuộc tính này phụ thuộc vào “ID sinh viên”, có sự phụ thuộc một phần chức năng. Một bảng chứa các thuộc tính này sẽ không tuân theo dạng chuẩn hóa thứ hai.

Ngoài ra, một bảng có khóa chính bao gồm một số trường sẽ vi phạm hình thức chuẩn hóa thứ hai nếu một hoặc nhiều trường không phụ thuộc vào từng phần của khóa.

Do đó, bảng có các trường này sẽ không khớp với dạng chuẩn hóa thứ hai, vì thuộc tính "tên sản phẩm" phụ thuộc vào ID sản phẩm chứ không phụ thuộc vào số đơn đặt hàng:

  • Số thứ tự (khóa chính);
  • ID sản phẩm (khóa chính);
  • Tên sản phẩm.

Hình thức chuẩn hóa thứ ba

Hình thức chuẩn hóa thứ ba ( 3NF) : Mỗi cột không có khóa phải độc lập với mọi cột khác. Nếu tại thiết kế cơ sở dữ liệu quan hệ việc thay đổi một giá trị trong một cột không khóa sẽ gây ra thay đổi ở một giá trị khác, bảng này không tuân theo hình thức chuẩn hóa thứ ba.

Theo 3NF, bạn không thể lưu trữ bất kỳ dữ liệu phái sinh nào trong một bảng, chẳng hạn như cột "Thuế", cột này trong ví dụ bên dưới phụ thuộc trực tiếp vào tổng chi phí của đơn hàng:

Đã có lúc, các hình thức bình thường hóa bổ sung đã được đề xuất. Bao gồm dạng chuẩn hóa Boyce-Codd, các dạng từ bốn đến sáu và chuẩn hóa khóa miền, nhưng ba dạng đầu tiên là phổ biến nhất.

Dữ liệu đa chiều

Một số người dùng có thể cần truy cập vào nhiều chế độ xem của cùng một loại dữ liệu, đặc biệt là trong cơ sở dữ liệu OLAP. Ví dụ: họ có thể muốn biết doanh số bán hàng theo khách hàng, quốc gia và tháng. Trong tình huống này, tốt hơn là tạo một bảng trung tâm để các bảng khách hàng, quốc gia và tháng có thể tham chiếu. Ví dụ:

Quy tắc toàn vẹn dữ liệu

Cũng đang sử dụng công cụ thiết kế cơ sở dữ liệu cần phải định cấu hình cơ sở dữ liệu có tính đến khả năng kiểm tra dữ liệu xem có tuân thủ các quy tắc nhất định hay không. Nhiều DBMS, chẳng hạn như Microsoft Access, tự động áp dụng một số quy tắc này.

Quy tắc toàn vẹn nêu rõ rằng khóa chính không bao giờ có thể là NULL. Nếu một khóa bao gồm nhiều cột thì không có cột nào có thể là NULL. Nếu không, nó có thể xác định mục nhập một cách mơ hồ.

Quy tắc toàn vẹn tham chiếu yêu cầu mọi khóa ngoại được chỉ định trong một bảng phải được ánh xạ tới một khóa chính trong bảng mà nó tham chiếu. Nếu khóa chính bị thay đổi hoặc bị xóa, những thay đổi đó phải được triển khai trong tất cả các đối tượng được tham chiếu bởi khóa đó trong cơ sở dữ liệu.

Các quy tắc toàn vẹn logic nghiệp vụ đảm bảo rằng dữ liệu tuân theo các tham số logic nhất định. Ví dụ: thời gian họp phải trong giờ làm việc tiêu chuẩn.

Thêm chỉ mục và lượt xem

Chỉ mục là bản sao được sắp xếp của một hoặc nhiều cột có giá trị theo thứ tự tăng dần hoặc giảm dần. Việc thêm chỉ mục cho phép bạn tìm bản ghi nhanh hơn. Thay vì sắp xếp lại từng truy vấn, hệ thống có thể truy cập các bản ghi theo thứ tự do chỉ mục chỉ định.

Mặc dù các chỉ mục giúp tăng tốc độ truy xuất dữ liệu nhưng chúng có thể làm chậm việc thêm, cập nhật và xóa dữ liệu vì chỉ mục phải được xây dựng lại bất cứ khi nào bản ghi thay đổi.

Chế độ xem là một yêu cầu đã lưu cho dữ liệu. Chế độ xem có thể bao gồm dữ liệu từ nhiều bảng hoặc hiển thị một phần của bảng.

Thuộc tính nâng cao

Sau đó thiết kế mô hình cơ sở dữ liệu Bạn có thể tinh chỉnh cơ sở dữ liệu của mình bằng cách sử dụng các thuộc tính nâng cao như văn bản trợ giúp, dấu hiệu nhập và quy tắc định dạng áp dụng cho một lược đồ, dạng xem hoặc cột cụ thể. Ưu điểm của phương pháp này là vì các quy tắc này được lưu trữ trong cơ sở dữ liệu nên việc trình bày dữ liệu sẽ nhất quán trên nhiều chương trình truy cập dữ liệu.

SQL và UML

Ngôn ngữ mô hình hóa thống nhất ( UML) là một cách trực quan khác để thể hiện các hệ thống phức tạp được tạo bằng ngôn ngữ hướng đối tượng. Một số khái niệm được đề cập trong hướng dẫn này được gọi bằng nhiều tên khác nhau trong UML. Ví dụ: một đối tượng trong UML được gọi là một lớp.

Ngày nay UML không được sử dụng thường xuyên. Ngày nay, nó được sử dụng trong học thuật và trong giao tiếp giữa các nhà phát triển phần mềm và khách hàng của họ.

Hệ thống Quản lý Dữ liệu

Cấu trúc của cơ sở dữ liệu được thiết kế phụ thuộc vào DBMS bạn đang sử dụng. Một số phổ biến nhất:

  • Oracle DB;
  • MySQL;
  • Máy chủ Microsoft SQL;
  • PostgreSQL ;
  • IBMDB2.

Một hệ thống quản lý cơ sở dữ liệu phù hợp có thể được lựa chọn dựa trên chi phí, hệ điều hành được cài đặt, tính sẵn có của các tính năng khác nhau, v.v.

Dịch bài viết" Hướng dẫn thiết kế và cấu trúc cơ sở dữ liệu» Đội ngũ dự án thân thiện.

Tốt xấu

Các bước thiết kế cơ sở dữ liệu

Tất cả sự tinh tế trong việc xây dựng mô hình thông tin về một lĩnh vực chủ đề nhất định của hoạt động con người đều theo đuổi một mục tiêu - có được cơ sở dữ liệu tốt. Hãy để chúng tôi giải thích thuật ngữ - một cơ sở dữ liệu tốt và đưa ra các yêu cầu mà cơ sở dữ liệu đó phải đáp ứng:

1. Cơ sở dữ liệu phải đáp ứng nhu cầu thông tin của người sử dụng (tổ chức) và có cấu trúc, nội dung phù hợp với nhiệm vụ đang giải quyết;

2. Cơ sở dữ liệu phải cung cấp dữ liệu cần thiết trong thời gian có thể chấp nhận được, tức là. đáp ứng yêu cầu thực hiện;

3. Cơ sở dữ liệu dễ dàng được mở rộng khi tổ chức lại lĩnh vực chuyên môn;

4. Cơ sở dữ liệu phải dễ thay đổi khi môi trường phần mềm và phần cứng thay đổi;

5. Dữ liệu đúng được tải vào cơ sở dữ liệu phải chính xác (dữ liệu phải được kiểm tra tính chính xác khi nhập vào).

Hãy xem xét các giai đoạn thiết kế chính (Hình 3.5):

Giai đoạn đầu. Lập kế hoạch phát triển cơ sở dữ liệu. Ở giai đoạn này, cách hiệu quả nhất để thực hiện các giai đoạn của vòng đời hệ thống sẽ được nêu bật.

Giai đoạn thứ hai. Xác định các yêu cầu của hệ thống. Phạm vi và ranh giới của ứng dụng cơ sở dữ liệu được xác định và các yêu cầu của người dùng được thu thập và phân tích.

Giai đoạn thứ ba. Thiết kế mô hình cơ sở dữ liệu khái niệm Quá trình tạo cơ sở dữ liệu bắt đầu bằng việc xác định một mô hình khái niệm thể hiện các đối tượng và mối quan hệ của chúng mà không chỉ rõ cách chúng được lưu trữ vật lý. Những nỗ lực ở giai đoạn này nên nhằm mục đích cấu trúc dữ liệu và xác định mối quan hệ giữa chúng. Quá trình này có thể được chia thành nhiều bước nhỏ:

a) Làm rõ vấn đề. Ngay cả trước khi bắt đầu làm việc trên một ứng dụng cụ thể, nhà phát triển thường có một số ý tưởng về những gì mình sẽ phát triển. Trong các trường hợp khác, khi một cơ sở dữ liệu cá nhân nhỏ đang được phát triển, những khung nhìn như vậy có thể khá hoàn chỉnh. Trong các trường hợp khác, khi một cơ sở dữ liệu tùy chỉnh lớn đang được phát triển, có thể có rất ít chế độ xem như vậy hoặc rất có thể chúng sẽ rất hời hợt. Rõ ràng là còn quá sớm để bắt đầu phát triển ngay bằng cách xác định các bảng, trường và mối quan hệ giữa chúng. Cách tiếp cận này có thể dẫn đến việc thiết kế lại hoàn toàn phần lớn ứng dụng. Do đó, bạn nên dành chút thời gian để biên soạn danh sách tất cả các nhiệm vụ chính mà về nguyên tắc, ứng dụng này sẽ giải quyết, bao gồm cả những nhiệm vụ có thể phát sinh trong tương lai.

Cơm. 3.5. Sơ đồ thiết kế cơ sở dữ liệu

b) Làm rõ trình tự công việc. Để ứng dụng hoạt động logic và thuận tiện, tốt nhất bạn nên sắp xếp các công việc chính thành các nhóm rồi sắp xếp công việc của từng nhóm sao cho theo đúng thứ tự hoàn thành. Việc nhóm và thể hiện bằng đồ họa trình tự thực hiện chúng sẽ giúp xác định thứ tự tự nhiên của các nhiệm vụ.

c) Phân tích dữ liệu. Sau khi xác định danh sách nhiệm vụ, mỗi nhiệm vụ cần tạo một danh sách chi tiết các dữ liệu cần thiết để giải quyết nó. Sau giai đoạn phân tích dữ liệu, bạn có thể bắt đầu phát triển một mô hình khái niệm, tức là. để làm nổi bật các đối tượng, thuộc tính và mối quan hệ.

Giai đoạn thứ tư. Xây dựng mô hình logic Xây dựng mô hình logic bắt đầu bằng việc chọn mô hình dữ liệu. Khi chọn một mô hình, vai trò quan trọng được thể hiện bởi tính đơn giản, rõ ràng và khả năng so sánh cấu trúc dữ liệu tự nhiên với mô hình đại diện cho nó. Ví dụ: nếu cấu trúc phân cấp vốn có trong chính dữ liệu thì việc chọn mô hình phân cấp sẽ thích hợp hơn. Nhưng thường sự lựa chọn này được xác định bởi sự thành công (hoặc tính khả dụng) của một hoặc một DBMS khác. Nghĩa là, nhà phát triển chọn DBMS chứ không phải mô hình dữ liệu. Do đó, ở giai đoạn này, mô hình khái niệm được chuyển thành mô hình dữ liệu tương thích với DBMS đã chọn. Có thể các mối quan hệ giữa các đối tượng hoặc một số thuộc tính của các đối tượng được hiển thị trong mô hình khái niệm sau đó sẽ không thể thực hiện được bởi DBMS đã chọn. Điều này sẽ đòi hỏi một sự thay đổi trong mô hình khái niệm. Phiên bản của mô hình khái niệm có thể được cung cấp bởi một DBMS cụ thể được gọi là mô hình logic. Quá trình xác định các mô hình khái niệm và logic đôi khi được gọi là định nghĩa cấu trúc dữ liệu.

Giai đoạn thứ năm. Xây dựng mô hình vật lý. Mô hình vật lý xác định bố cục dữ liệu, phương pháp truy cập và kỹ thuật lập chỉ mục. Ở giai đoạn thiết kế vật lý, chúng ta bị ràng buộc với một DBMS cụ thể và mô tả lược đồ dữ liệu chi tiết hơn, chỉ ra các loại, kích thước trường và các hạn chế. Ngoài việc thiết kế bảng và chỉ mục, giai đoạn này còn liên quan đến việc xác định các truy vấn cơ bản.

Khi xây dựng một mô hình vật lý, người ta phải giải quyết hai vấn đề trái ngược nhau. Đầu tiên là giảm thiểu không gian lưu trữ dữ liệu và thứ hai là đạt được hiệu suất, tính toàn vẹn và bảo mật dữ liệu tối đa. Ví dụ: để đảm bảo tốc độ tìm kiếm cao, cần phải tạo các chỉ mục và số lượng của chúng sẽ được xác định bởi tất cả các tổ hợp có thể có của các trường tham gia tìm kiếm; Để khôi phục dữ liệu, bạn cần ghi nhật ký tất cả các thay đổi và tạo bản sao lưu cơ sở dữ liệu; Để các giao dịch hoạt động hiệu quả, cần phải dành dung lượng đĩa cho các đối tượng tạm thời, v.v., điều này dẫn đến sự gia tăng (đôi khi đáng kể) kích thước của cơ sở dữ liệu.

Giai đoạn thứ sáu. Đánh giá mô hình vật lý. Ở giai đoạn này, việc đánh giá hiệu suất được thực hiện. Tại đây bạn có thể kiểm tra hiệu quả thực hiện truy vấn, tốc độ tìm kiếm, tính chính xác và dễ dàng thực hiện các thao tác cơ sở dữ liệu, tính toàn vẹn dữ liệu và hiệu quả của tài nguyên máy tính. Nếu các đặc tính hiệu suất không đạt yêu cầu, có thể quay lại sửa đổi các mô hình dữ liệu vật lý và logic, lựa chọn DBMS và loại máy tính.

Giai đoạn thứ bảy. Triển khai cơ sở dữ liệu. Nếu hiệu suất đạt yêu cầu, bạn có thể chuyển sang tạo bố cục ứng dụng, tức là một tập hợp các bảng, truy vấn, biểu mẫu và báo cáo cơ bản. Mô hình sơ bộ này có thể được trình diễn cho khách hàng và nhận được sự chấp thuận trước khi triển khai ứng dụng chi tiết.

Giai đoạn thứ tám. Thử nghiệm và tối ưu hóa. Một giai đoạn bắt buộc là thử nghiệm và tối ưu hóa ứng dụng đã phát triển.

Giai đoạn chín, cuối cùng. Bảo trì và vận hành. Vì không thể xác định và loại bỏ tất cả các lỗi ở giai đoạn thử nghiệm nên giai đoạn bảo trì là điều bình thường đối với cơ sở dữ liệu.

Có hai cách tiếp cận chính để thiết kế lược đồ dữ liệu: từ trên xuống và từ dưới lên. Với cách tiếp cận từ dưới lên, công việc bắt đầu ở cấp độ thấp hơn - cấp độ xác định các thuộc tính, dựa trên phân tích các mối quan hệ tồn tại giữa chúng, được nhóm thành các mối quan hệ đại diện cho các đối tượng và kết nối giữa chúng. Quá trình chuẩn hóa các bảng cho mô hình dữ liệu quan hệ là một ví dụ điển hình của phương pháp này. Cách tiếp cận này rất phù hợp để thiết kế cơ sở dữ liệu tương đối nhỏ. Khi số lượng thuộc tính tăng lên vài trăm hoặc thậm chí hàng nghìn, cách tiếp cận từ trên xuống là chiến lược thiết kế phù hợp hơn. Cách tiếp cận này bắt đầu bằng việc xác định một số thực thể cấp cao và mối quan hệ giữa chúng. Các đối tượng này sau đó được chi tiết đến mức yêu cầu. Một ví dụ về phương pháp thiết kế này là việc sử dụng mô hình mối quan hệ thực thể. Trong thực tế, các phương pháp này thường được kết hợp. Trong trường hợp này, chúng ta có thể nói về cách tiếp cận thiết kế hỗn hợp.