(TIỂU LUẬN) báo cáo đồ án i đề tài KIẾN TRÚC và THIẾT kế hệ THỐNG KHO dữ LIỆU

Thiết kế khái niệm có thể được thực hiện bằng hai cách tiếp cận khác nhau,tùy theo mức độ phức tạp của hệ thống và kinh nghiệm của nhà phát triển: – Thiết kế từ trên xuống: Các yêu cầu c

VIỆN TOÁN ỨNG DỤNG VÀ TIN HỌC

BÁO CÁO ĐỒ ÁN I

ĐỀ TÀI: KIẾN TRÚC VÀ THIẾT KẾ HỆ THỐNG KHO DỮ LIỆU

Chuyên ngành: Hệ thống thông tin quản lý

Giảng viên hướng dẫn: ThS Lê Quang Hòa

Sinh viên thực hiện: Ngô Quốc Cường - 20185436

HÀ NỘI – 2022

NHẬN XÉT CỦA GIẢNG VIÊN

Lời cảm ơn

Em xin gửi lời cảm ơn chân thành và kính trọng nhất tới Thạc sĩ LêQuang Hòa, người đã tận tình hướng dẫn học phần Đồ án 1, giúp em điđúng hướng, sửa lỗi, cho ý kiến, góp phần hoàn thành bài báo cáo này

Do kiến thức còn hạn hẹp, kỹ năng chắt lọc tài liệu còn yếu kém và trình độngoại ngữ còn hạn chế nên không tránh khỏi những thiếu sót và sai sót về kiếnthức, khi trình bày và trong dịch thuật Em rất mong nhận thêm nữa những đónggóp ý kiến từ thầy để bài báo cáo này đạt kết quả tốt nhất cũng như để em rút rathêm những kinh nghiệm quý báu cho các bài tập, đồ án, dự án sắp tới

Em xin chân thành cảm ơn!

Hà Nội, tháng 08 năm 2022

Sinh viên

Ngô Quốc Cường

Mục lục

2.1 Thiết kế có sở dữ liệu 5

2.2 Cơ sở dữ liệu Northwind 7

2.3 Thiết kế cơ sở dữ liệu khái niệm 9

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

2.4.1 Mô hình quan hệ 13

Chương 3 Khái niệm kho dữ liệu 20 3.1 Mô hình đa chiều dữ liệu 20

3.1.1 Cấu trúc phân mức 23

3.1.2 Số đo 24

3.2 Mô hình OLAP 24

3.3 Kho dữ liệu 27

3.4 Kiến trúc kho dữ liệu 28

3.5 Thiết kế kho dữ liệu 29

Chương 4 Thiết kế kho dữ liệu khái niệm 30 4.1 Thiết kế kho dữ liệu khái niệm 30

4.2 Hệ thống phân mức 33

4.2.1 Phân mức đối xứng 33

4.2.2 Phân mức phi đối xứng 34

4.2.3 Phân mức tổng quát 34

4.2.4 Phân mức thay thế 35

5.1 Mô hình kho dữ liệu logic 375.2 Thiết kế kho dữ liệu quan hệ 38

Danh sách hình vẽ

2.1 Lược đồ khái niệm của cơ sở dữ liệu Northwind 102.2 Kiểu quan hệ OrderDetails được mô hình hóa như một kiểu thực

thể yếu 122.3 Một lược đồ quan hệ tương ứng với lược đồ khái niệm Northwind

Khoan sâu vào mức Month (d) Phân loại sản phẩm theo tên (e)

Xoay Cắt City = ’Paris’ (g) Bóc City = ’Paris’ hoặc ’Lyon’ và

Quarter = ’Q1’ hoặc ’Q2’ (h) Khối lập phương năm 2011 (i) Giao

hai khối (j) Phần trăm thay đổi 253.4 Kiến trúc kho dữ liệu điển hình 293.5 Các giai đoạn thiết kế kho dữ liệu 294.1 (a) Mức (b) Hệ thống phân mức (c) Số đo (d) Dữ kiện và chiều

dữ liệu (e) Các loại số đo (f) Tên mức (g) Thuộc tính phân phối

(h) Các mối quan hệ độc quyền 314.2 Lược đồ khái niệm cho kho dữ liệu Northwind 32

4.3 Một ví dụ về phân mức đối xứng Product → Category 33

4.4 (a) Lược đồ (b) Ví dụ 34

4.5 Một hệ thống phân mức tổng quát (a) Lược đồ (b) Ví dụ 35

4.6 Một hệ thống phân mức thay thế (a) Lược đồ (b) Ví dụ 36

5.1 Ví dụ lược đồ hình sao 39

5.2 Ví dụ lược đô bông tuyết 40

5.3 Ví dụ lược đồ hình sao 40

5.4 Ví dụ lược hồ chòm sao 41

Chương 1

Mở đầu

Từ cuối những năm 1970, công nghệ cơ sở dữ liệu quan hệ đã được hầuhết các tổ chức áp dụng để lưu trữ dữ liệu thiết yếu Tuy nhiên, hiện nay, nhucầu của các tổ chức không còn giống như trước đây Một mặt, sự năng độngcủa thị trường và khả năng cạnh tranh ngày càng gia tăng dẫn đến nhu cầunắm thông tin thích hợp vào đúng thời điểm Các nhà quản lý cần được cungcấp thông tin thích hợp hòng đưa ra các quyết định thật kịp thời theo kịp hoạtđộng kinh doanh đầy biến động Mặt khác, dữ liệu do các tổ chức sở hữuthường nằm rải rác giữa các hệ thống khác nhau, mỗi hệ thống được thiết kếcho một loại hoạt động kinh doanh cụ thể Các hệ thống này lại bị phân phối rảirác theo địa lý, trong các chi nhánh tổ chức khác nhau

Các hệ thống cơ sở dữ liệu truyền thống không phù hợp lắm với những yêucầu mới này, vì chúng được tạo ra chỉ để phục vụ hoạt động hàng ngày hơn là đểphân tích dữ liệu và ra quyết định Do đó, nhiều công nghệ cơ sở dữ liệu mới chocác nhiệm vụ cụ thể bắt đầu xuất hiện trong những năm 1990, cụ thể là kho dữliệu và xử lý phân tích trực tuyến (OLAP), liên quan đến kiến trúc, thuật toán, công

cụ và kỹ thuật để tập hợp dữ liệu từ nhiều nguồn thông tin không đồng nhất thànhmột kho lưu trữ phù hợp cho hoạt động phân tích Trong kho kho dữ liệu, dữ liệuđược tích lũy trong một khoảng thời gian nhất định nhằm mục đích phân tích sựphát triển và khám phá các thông tin chiến lược như xu hướng hay mối tươngquan Kho dữ liệu ngày nay là một công nghệ hoàn thiện

được các tổ chức trong nhiều lĩnh vực sử dụng nhằm cải thiện hoạt động và đạt

được các mục tiêu kinh doanh

2.1 Thiết kế có sở dữ liệu

Thiết kế một hệ thống cơ sở dữ liệu là một công việc tương đối phức tạp,chia thành bốn giai đoạn:

• Đặc tả yêu cầu: Thu thập thông tin về nhu cầu của người dùng đối với

hệ thống cơ sở dữ liệu Các học viện và cá nhân đã phát triển nhiều phươngpháp tiếp cận trong việc đặc tả yêu cầu Các kỹ thuật này giúp gợi ra cácthuộc tính hệ thống cần thiết và các mong muốn từ những người dùng tiềmnăng, để đồng nhất các yêu cầu và chỉ định mức độ ưu tiên cho chúng Tronggiai đoạn này, sự tham gia tích cực của người dùng sẽ làm tăng mức độ hàilong của họ đối với hệ thống được cung cấp và tránh được các lỗi mà có thể

sẽ rất tốn nhiều chi phí sửa chữa khi giai đoạn tiếp theo đã triển khai

• Thiết kế khái niệm nhằm mục đích xây dựng một biểu diễn hướng

người dùng cho cơ sở dữ liệu mà chưa cần cân nhắc triển khai Giai đoạnnày được thực hiện bằng cách sử dụng mô hình khái niệm để xác định cáckhái niệm liên quan đến ứng dụng Mô hình quan hệ thực thể là một trongnhững mô hình khái niệm thường dùng nhất để thiết kế các ứng dụng cơ sở

dữ liệu Ngoài ra, các kỹ thuật mô hình hóa hướng đối tượng khác cũng cóthể áp dụng với bộ ký hiệu UML

Thiết kế khái niệm có thể được thực hiện bằng hai cách tiếp cận khác nhau,tùy theo mức độ phức tạp của hệ thống và kinh nghiệm của nhà phát triển:

– Thiết kế từ trên xuống: Các yêu cầu của nhiều người dùng khác

nhau được hợp nhất trước khi quá trình thiết kế bắt đầu và sử dụng duy nhất một lược đồ trong xây dựng Sau đó, nhà phát triển có thể tách các chế độ xem tương ứng với yêu cầu của từng người dùng Cách tiếp cận này có thể khó khăn và tốn kém đối với cơ sở dữ liệu lớn hoặc khi vào tay nhà phát triển còn non kinh nghiệm

– Thiết kế từ dưới lên: Một lược đồ riêng biệt được xây dựng cho từng

nhóm người dùng một với các yêu cầu khác nhau Sau đó, trong giai đoạn tích hợp chế độ xem, các lược đồ này được hợp nhất để tạo thành một lược đồ khái niệm chung cho toàn bộ cơ sở dữ liệu Đây là cách tiếp cận thường được sử dụng hơn cho các cơ sở dữ liệu lớn

• Thiết kế logic nhằm mục đích biểu diễn các khái niệm của cơ sở dữ liệu thu

được từ giai đoạn trước thành một mô hình logic cụ thể chung cho DBMS Hiện nay,

mô hình logic phổ biến nhất là mô hình quan hệ Các mô hình logic khác có thể kểđến mô hình quan hệ đối tượng, mô hình hướng đối tượng và mô hình bán cấu trúc.Trong bài báo cáo này, ta chỉ tập trung vào mô hình quan hệ Để đảm bảo biểu diễnlogic không thiếu sót, ta cần chỉ định một tập hợp quy tắc ánh xạ phù hợp sao chobiến đổi trọn vẹn, thích hợp các cấu trúc trong mô hình khái niệm thành các cấu trúctrong

mô hình logic.

• Thiết kế vật lý nhằm mục đích tùy chính biểu diễn logic của cơ cở dữ

liệu có được từ giai đoạn trước thành một mô hình vật lý nhắm mục tiêu đếnmột nền tảng DBMS cụ thể Các DBMS phổ biến là SQL Server, Oracle, DB2,MySQL, PostgreSQL, v.v,

Mục tiêu chính của quy trình bốn cấp này là cung cấp tính độc lập dữ liệu,nghĩa là, đảm bảo tối đa rằng các lược đồ ở cấp cao không bị ảnh hưởng bởinhững thay đổi đối với lược đồ ở cấp thấp Tính độc lập dữ liệu logic đề cậpđến khả năng miễn nhiễm của lược đồ khái niệm đối với những thay đổi tronglược đồ logic Ví dụ, miễn là các yêu cầu của ứng dụng vẫn được giữ nguyênthì việc sắp xếp lại cấu trúc của các bảng quan hệ không được ảnh hưởng đếnlược đồ khái niệm Tính độc lập dữ liệu vật lý đề cập đến khả năng miễn nhiễmcủa lược đồ logic đối với những thay đổi trong lược đồ vật lý

Trong chương này và các chương tiếp theo, chúng ta sẽ sử dụng bộ cơ sở dữ

liệu Northwind để làm ví dụ giải thích các khái niệm cơ sở dữ liệu, khái niệm kho

dữ liệu và OLAP Cơ sở dữ liệu Northwind là cơ sở dữ liệu mẫu được Microsoft

sử dụng để chứng minh các tính năng trong một số sản phẩm của hãng, bao gồmSQL Server và Microsoft Access Cơ sở dữ liệu chứa dữ liệu bán hàng củaNorthwind Traders, một công ty xuất khẩu thực phẩm đặc sản hư cấu

2.2 Cơ sở dữ liệu Northwind

Công ty Northwind xuất khẩu một số mặt hàng Để quản lý và lưu trữ dữliệu công ty, cần phải thiết kế một cơ sở dữ liệu quan hệ Các đặc điểmchính của dữ liệu bao gồm:

• Dữ liệu khách hàng, phải gồm nhân dạng, tên khách hàng, tên và chứcdanh người liên hệ, địa chỉ đầy đủ, điện thoại và fax

• Dữ liệu nhân viên, phải gồm số nhận dạng, tên, chức danh, tước hiệu danh

dự, ngày sinh, ngày thuê, địa chỉ, số điện thoại nhà riêng, số máy lẻ và

ảnh Ảnh sẽ được lưu trữ trong hệ thống tệp và cần có đường dẫn đếnảnh Ngoài ra, nhân viên báo cáo với các nhân viên cấp cao hơn trong

tổ chức của công ty

• Dữ liệu địa lý, cụ thể là các lãnh thổ nơi công ty hoạt động, tổ chứcthành từng vùng Một số nhân viên được chỉ định cho một số lãnh thổ, nhưngmỗi một lãnh thổ này không dành riêng cho mỗi một nhân viên: Mỗi nhân viên

có thể liên kết với nhiều vùng lãnh thổ và mỗi lãnh thổ có thể được liên kết vớinhiều nhân viên

• Dữ liệu người gửi hàng, tức là thông tin về các công ty mà Northwind thuê dịch vụ giao hàng Mỗi người đi kèm tên công ty và số điện thoại riêng

• Dữ liệu của nhà cung cấp, bao gồm tên công ty, tên liên hệ và chức danh, địa chỉ đầy đủ, điện thoại, fax và trang chủ

• Dữ liệu về các sản phẩm mà Northwind kinh doanh, chẳng hạn như mãnhận dạng, tên, số lượng trên mỗi loại, đơn giá và chỉ báo nếu sản phẩm đãngừng sản xuất Ngoài ra, cần chú ý tới kho hàng: số lượng hàng tồn kho, sốlượng hàng đã được đặt nhưng chưa giao, mức tái bổ sung hàng (tức là mứchàng giới hạn mà khi chạm mức đó, công ty cần bổ sung thêm vào kho) Sảnphẩm được phân thành nhiều loại, mỗi loại có tên, mô tả và hình ảnh Mỗi sảnphẩm có một nhà cung cấp duy nhất

• Dữ liệu về các đơn hàng bán Thông tin được yêu cầu bao gồm sốnhận dạng, ngày đơn đặt hàng được gửi, ngày giao hàng bắt buộc, ngày giaohàng thực tế, nhân viên tham gia bán hàng, khách hàng, người giao hàngchịu trách nhiệm giao hàng, chi phí vận chuyển và địa chỉ đích đầy đủ Mộtđơn đặt hàng có thể chứa nhiều sản phẩm và mỗi sản phẩm theo kèm đơngiá, số lượng và chiết khấu

2.3 Thiết kế cơ sở dữ liệu khái niệm

Mô hình quan hệ thực thể (ER) là một trong những mô hình khái niệm

thường được sử dụng nhất để thiết kết các ứng dụng cơ sở dữ liệu

Hình 2.1 mô tả mô hình ER cho cơ sở dữ liệu Northwind Tiếp theo, ta sẽ giới

thiệu các khái niệm ER chính thông qua mô hình ER này Trong Hình 2.1, Employees, Orders, và Customers là ví dụ về các kiểu thực thể Một đối tượng

thuộc một kiểu thực thể được gọi là một thực thể Tập hợp các thực thể của một

kiểu thực thể được gọi là tổng thể của kiểu thực thể Theo quan điểm ứng dụng,

tất cả các thực thể của một kiểu thực thể đều có các đặc điểm giống nhau

Trong thế giới thực, các đối tượng không tách biệt hoàn toàn với nhau;

chúng có liên quan với nhau Các kiểu quan hệ được sử dụng để biểu diễn

liên kết giữa các đối tượng Trong ví dụ của ta, Supplies, ReportsTo vàHasCategory là ba ví dụ cho kiểu quan hệ Sự kết hợp giữa các đối tượngcủa một kiểu quan hệ được gọi là mối quan hệ Tập hợp các kết hợp củakiểu quan hệ được gọi là tổng thể của kiểu quan hệ

Sự tham gia của một kiểu thực thể trong một kiểu quan hệ được gọi là một

vai trò và được biểu thị bằng một đường liên kết hai kiểu thực thể Mỗi vai trò

của một kiểu quan hệ gắn liền một cặp số mô tả số lần tối thiểu và tối đa màmột thực thể có thể tham gia vào kiểu quan hệ Ví dụ, vai trò giữa Products vàSupplies có cặp số (1,1), nghĩa là mỗi sản phẩm tham gia chính xác một lầnvào kiểu quan hệ Vai trò giữa Supplies và Suppliers có cặp số (0, n), nghĩa lànhà cung cấp có thể tham gia từ 0 đến n lần (số lần không giơi shanj) trongkiểu quan hệ Mặt khác, cặp số (1, n) giữa Orders và OrderDetails có nghĩa làmỗi đơn hàng có thể tham gia từ 1 đến n lần trong kiểu quan hệ Một vai tròđược cho là tùy chọn hoặc bắt buộc tùy thuộc vào số bé nhất trong cặp số theokèm là 0 hay 1 Một vai trò được cho là đơn giá trị hoặc đa giá trị tùy thuộc vàoviệc số lớn nhất trong cặp số theo kèm là 1 hay n

Hình 2.1: Lược đồ khái niệm của cơ sở dữ liệu Northwind

Một kiểu quan hệ có thể liên quan đến hai hoặc nhiều kiểu đối tượng: Nó đượcgọi là hai ngôi nếu nó liên quan đến hai kiểu đối tượng và n ngôi nếu nó liên quan

đến nhiều hơn hai kiểu đối tượng Trong Hình 2.1, tất cả các kiểu quan hệ là hai

ngôi Tùy thuộc vào số tối đa trong cặp số theo kèm mỗi vai trò, các kiểu quan hệhai ngôi có thể được phân loại thành quan hệ một-một, một-nhiều và nhiều-nhiều

Trong Hình 2.1, kiểu quan hệ Supplies là quan hệ một - nhiều, vì một sản phẩm

được cung cấp bởi nhiều nhất một nhà cung cấp, trong khi

một nhà cung cấp có thể cung cấp nhiều sản phẩm Kiểu quan hệ OrderDetails

là nhiều-nhiều, vì một đơn đặt hàng có liên quan đến một hoặc nhiều sảnphẩm, trong khi một sản phẩm cũng có thể nằm trong nhiều đơn đặt hàng

Có thể xảy ra trường hợp một kiểu thực thể tự liên kết bằng một kiểuquan hệ, như trường hợp của kiểu quan hệ ReportsTo Trong trường hợpnày, kiểu quan hệ được gọi là kiểu quan hệ đệ quy và vai trò cần có tên để

phân biệt Trong Hình 2.1, Subordinate và Supervisor là hai tên vai trò.

Cả hai đối tượng và các mối quan hệ giữa chúng đều có một loạt đặc

điểm cấu trúc mô tả Các thuộc tính được sử dụng để ghi lại các đặc điểm này của các kiểu thực thể hoặc mối quan hệ Ví dụ, trong Hình 2.1, Adress

và Homepage là các thuộc tính của Suppliers, trong khi UnitPrice, Quantity

và Discount là các thuộc tính của OrderDetails

Giống như vai trò, các thuộc tính cũng có cặp số theo kèm, xác định sốlượng giá trị mà một thuộc tính có thể nhận Vì hầu hết cặp số của mộtthuộc tính là (1,1), ta không hiển thị cặp số này trong các lược đồ Mỗi nhàcung cấp sẽ có chính xác một Adress và nhiều nhất một Homepage Cặp sốcủa Homepage là là (0,1), thuộc tính Homepage là tùy chọn Khi cặp số là(1,1), ta nói rằng thuộc tính là bắt buộc Tương tự, các thuộc tính được gọi

là đơn giá trị hoặc đa giá trị tùy thuộc vào việc chúng có thể nhận nhiều nhấtmột hoặc một số giá trị tương ứng Trong ví dụ, tất cả các thuộc tính đều là

đa giá trị Tuy nhiên, nếu trong trường hợp khách hàng có một hoặc nhiều

số điện thoại, thì thuộc tính Phone sẽ được gắn nhãn (1, n)

Ngoài ra, thuộc tính có thể bao gồm nhiều thuộc tính con Ví dụ, thuộc tínhNames của kiểu thực thể Employees, bao gồm FirstName và LastName.Những thuộc tính bao hàm nhiều thuộc tính con được gọi là thuộc tính phứccòn những thuộc tính không bao hàm thuộc tính con thì được gọi là thuộc tínhđơn Cuối cùng, một số thuộc tính có thể được dẫn xuất, chẳng hạn như thuộctính NumberOrders của kiểu thực thể Products Điều này có nghĩa là số lượngđơn đặt hàng mà một sản phẩm xuất hiện có thể được tính bằng công thức liên

quan đến các phần tử khác ngoài lược đồ và được lưu trữ dưới dạng mộtthuộc tính Trong trường hợp của ta, thuộc tính dẫn xuất ghi lại số lần mộtsản phẩm cụ thể tham gia vào kiểu quan hệ OrderDetails.

Một tình huống phổ biến trong các ứng dụng thực là một hoặc một sốthuộc tính xác định duy nhất một đối tượng cụ thể; các thuộc tính như vậy

được gọi là ID Trong Hình 2.1, ID được gạch dưới; ví dụ: thuộc tính

EmployeeID là ID của kiểu thực thể Employees, có nghĩa là mọi nhân viênđều có một giá trị duy nhất cho thuộc tính này Trong hình, tất cả các ID kiểuthực thể đều đơn giản, nghĩa là chúng chỉ bao gồm một thuộc tính, mặc dùthông thường ID sẽ gồm hai hoặc nhiều thuộc tính

Kiểu thực thể không có ID riêng được gọi là kiểu thực thể yếu và đượcbiểu thị với hộp tên viền kép Ngược lại, kiểu thực thể có ID được gọi là

kiểu thực thể mạnh Trong Hình 2.1, không có kiểu thực thể yếu Tuy nhiên,

lưu ý rằng mối quan hệ OrderDetails giữa Orders và Products có thể được

mô hình hóa như trong Hình 2.2.

Hình 2.2: Kiểu quan hệ OrderDetails được mô hình hóa như một kiểu thực thể yếu

Một kiểu thực thể yếu phụ thuộc vào sự tồn tại của một kiểu thực thể khác,được gọi là kiểu thực thể ID hoặc kiểu thực thể sở hữu Kiểu quan hệ liên quanđến kiểu thực thể yếu với kiểu thực thể sở hữu của nó được gọi là kiểu quan hệxác định của kiểu thực thể yếu Kiểu quan hệ không phải là kiểu quan hệ xác định

được gọi là kiểu quan hệ thông thường Do đó, trong Hình 2.2, Orders là kiểu thực

thể sở hữu của kiểu thực thể yếu OrderDetails, và Composed là kiểu

quan hệ ID Như thể hiện trong hình, kiểu quan hệ ID và vai trò kết nối nóvới kiểu thực thể yếu được vẽ bằng các đường kép.

Kiểu thực thể yếu thường có một số ID cục bộ, là một tập hợp các thuộctính xác định duy nhất các thực thể yếu có liên quan đến cùng một thực thể

sở hữu Một ví dụ là thuộc tính LineNo của OrderDetails, thuộc tính này lưutrữ số dòng của mỗi sản phẩm trong một đơn đặt hàng Do đó, cùng một số

có thể xuất hiện nhiều lần trong các đơn hàng khác nhau, mặc dù nó là duynhất trong mỗi đơn hàng

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

Trong phần này, ta mô tả mô hình dữ liệu logic được sử dụng nhiều nhấtcho cơ sở dữ liệu, đó là mô hình quan hệ Ta cũng nghiên cứu hai ngônngữ truy vấn nổi tiếng cho mô hình quan hệ: đại số quan hệ và SQL

2.4.1 Mô hình quan hệ

Cơ sở dữ liệu quan hệ đã được sử dụng thành công trong vài thập kỷ đểlưu trữ thông tin trong nhiều lĩnh vực ứng dụng Bất chấp các công nghệ cơ sở

dữ liệu thay thế đã xuất hiện trong những thập kỷ trước, mô hình quan hệ vẫn

là cách tiếp cận thường được sử dụng nhất để lưu trữ thông tin liên tục, đặcbiệt là thông tin quan trọng đối với hoạt động hàng ngày của một tổ chức hầnlớn thành công của mô hình quan hệ, được Codd giới thiệu vào năm 1970, là

do tính đơn giản, trực quan và nền tảng của nó trên một lý thuyết hình thứcvững chắc: Mô hình quan hệ được xây dựng dựa trên khái niệm quan hệ toánhọc, có thể được xem như một bảng các giá trị và dựa trên lý thuyết tập hợp vàlogic vị từ bậc nhất Nền tảng toán học này cho phép thiết kế các ngôn ngữ truyvấn khai báo và một loạt các kỹ thuật tối ưu hóa phong phú dẫn đến việc triểnkhai hiệu quả Lưu ý rằng mặc dù vậy, chỉ vào đầu những năm 1980, DBMSquan hệ thương mại (RDBMS) đầu tiên mới xuất hiện

Mô hình quan hệ có cấu trúc dữ liệu đơn giản, một quan hệ (bảng) bao

gồm một hoặc một số thuộc tính (cột) Một lược đồ quan hệ mô tả cấu trúc

của một tập hợp các quan hệ Hình 2.3 là một lược đồ quan hệ tương ứng với lược đồ khái niệm Hình 2.1 Như ta sẽ thấy ở phần sau, lược đồ quan

hệ này có được bằng cách áp dụng một tập hợp các quy tắc “biên dịch” cholược đồ ER tương ứng Lược đồ quan hệ của cơ sở dữ liệu Northwind baogồm một tập hợp các quan hệ, chẳng hạn như Employees, Customers vàProducts Mỗi quan hệ này bao gồm một số thuộc tính Ví dụ, EmployeeID,FirstName và LastName là ba thuộc tính của mối quan hệ Employees.Trong phần sau, ta sử dụng ký hiệu R.A để chỉ thuộc tính A của quan hệ R

Hình 2.3: Một lược đồ quan hệ tương ứng với lược đồ khái niệm Northwind trong Hình 2.1

Trong mô hình quan hệ, mỗi thuộc tính được xác định trên một miền hoặc kiểu

dữ liệu, nghĩa là, một tập hợp các giá trị theo kèm một tập hợp các phép toán, cáckiểu dữ liệu điển hình nhất là số nguyên, số thực, ngày tháng và chuỗi Một hạnchế quan trọng của mô hình là các thuộc tính phải là nguyên tử và đơn giá trị Do

đó, các thuộc tính phức tạp như Name của kiểu thực thể Employees trong Hình

2.1 phải được tách thành các giá trị nguyên tử, như FirstName và LastName trong

bảng cùng tên trong Hình 2.3 Một quan hệ R được xác định bởi một lược đồ R

(A1 : D1, A2 : D2, , A n : D n), trong đó R là tên của quan hệ và mỗi thuộc tính Aiđược xác định trên miền Di Quan hệ R được liên kết với một tập các bộ giá trị

(hoặc các hàng nếu chúng ta xem quan hệ như một bảng) (t1, t2, , tn) Tập hợp

các bộ giá trị này là một tập con của tích Descartes D1 × D2 x ··· x D n, và đôi khi nó

được gọi là một thể hiện R Mức độ (hoặc độ hiếm) của một quan hệ là số thuộc

tính n trong lược đồ quan hệ của nó

Mô hình quan hệ cho phép một số loại ràng buộc toàn vẹn được định nghĩa

• Một thuộc tính có thể được định nghĩa là khác rỗng, nghĩa là không cho

phép nhận giá trị null (hoặc khoảng trống) Trong Hình 2.3, chỉ các thuộc tính

được đánh dấu bằng cặp số (0,1) mới cho phép nhận các giá trị rỗng

• Một hoặc một số thuộc tính có thể được định nghĩa là một khóa, nghĩa làkhông được phép để hai bộ giá trị khác nhau của mối quan hệ có các giá trị

giống nhau trong các cột tương ứng Trong Hình 2.3, các khóa được gạch chân.

Một khóa bao gồm một số thuộc tính được gọi là khóa tổng hợp; nếu không, nó

là khóa đơn Trong Hình 2.3, bảng Employees có một khóa đơn, EmployeeID,

bảng EmployeeTerritories có một khóa tổng hợp, bao gồm hai thuộc tínhEmployeeID và TerritoryID

• Trong mô hình quan hệ, mỗi quan hệ phải có một khóa chính và có thể

có các khóa thay thế khác Ngoài ra, các thuộc tính tạo khóa chính khôngđược nhận giá trị rỗng

• Tính toàn vẹn tham chiếu chỉ định một liên kết giữa hai bảng, trong đó

một tập hợp các thuộc tính trong một bảng, được gọi là khóa ngoại, thamchiếu đến khóa chính của bảng kia Điều này có nghĩa là các giá trị trong

khóa ngoại cũng phải tồn tại trong khóa chính Trong Hình 2.3, các ràng

buộc toàn vẹn tham chiếu được biểu diễn bằng các mũi tên từ bảng thamchiếu đến bảng được tham chiếu Ví dụ: thuộc tính EmployeeID trongbảng Orders tham chiếu đến khóa chính của bảng Employees Điều nàyđảm bảo rằng mọi nhân viên xuất hiện trong một đơn hàng cũng xuấthiện trong bảng Employees Lưu ý rằng tính toàn vẹn của tham chiếu cóthể liên quan đến khóa ngoại và khóa chính bao gồm một số thuộc tính

• Cuối cùng, ràng buộc kiểm tra xác định một vị từ phải hợp lệ khi thêmhoặc cập nhật một bộ giá trị trong một quan hệ Ví dụ, một ràng buộc kiểm tra cóthể được sử dụng để xác minh rằng trong bảng Order, giá trị của các thuộc tínhOrderDate và RequiredDate cho một đơn đặt hàng nhất định sao cho OrderDateRequiredDate Lưu ý rằng nhiều DBMS giới hạn các ràng buộc kiểm tra đối vớimột bộ dữ liệu duy nhất: không cho phép các tham chiếu đến dữ liệu được lưutrữ trong các bảng khác hoặc trong các bộ dữ liệu khác của cùng một bảng Do

đó, các ràng buộc kiểm tra chỉ có thể được sử dụng để xác minh các ràng buộcđơn giản

Việc dịch một lược đồ khái niệm (được viết trong ER hoặc bất kỳ mô hìnhkhái niệm nào khác) sang một lược đồ quan hệ tương đương được gọi là mộtphép ánh xạ Đây là một quy trình được thực hiện trong hầu hết các công cụthiết kế cơ sở dữ liệu Các công cụ này sử dụng các lược đồ khái niệm để tạođiều kiện thuận lợi cho việc thiết kế cơ sở dữ liệu và sau đó tự động dịch cáclược đồ khái niệm sang các lược đồ logic, chủ yếu là sang mô hình quan hệ.Quá trình này bao gồm định nghĩa của các bảng trong các RDBMS khác nhau

Bây giờ ta phác thảo bảy quy tắc được sử dụng để ánh xạ một lược đồ

ER thành một lược đồ quan hệ

• Quy tắc 1: Kiểu thực thể mạnh E được ánh xạ tới một bảng T chứa các

thuộc tính đơn đơn giá trị và các thành phần đơn của thuộc tính phức đơngiá trị thuộc E ID của E xác định khóa chính của T T cũng định nghĩa cácràng buộc khác rỗng cho các thuộc tính bắt buộc Lưu ý rằng các thuộc tính

bổ sung sẽ được thêm vào bảng này theo các quy tắc tiếp theo

Ví dụ: kiểu thực thể mạnh Products trong Hình 2.1 được ánh xạ tới bảng Products trong Hình 2.3, với khóa chính ProductID.

• Quy tắc 2: Chúng ta hãy xem xét một kiểu thực thể yếu W, với kiểu

thực thể sở hữu O Giả sử Wid là ID một phần của W và Oid là ID của O Wđược ánh xạ đến một bảng T giống như một loại thực thể mạnh Trongtrường hợp này, T cũng phải bao gồm Oid làm thuộc tính, với ràng buộc toànvẹn tham chiếu cho thuộc tính O.Oid Hơn nữa, ID của T là sự kết hợp củaWid và Oid

Ví dụ, kiểu thực thể yếu OrderDetails trong Hình 2.2 được ánh xạ tới bảng cùng tên trong Hình 2.4 Khóa bao gồm các thuộc tính OrderID và

LineNo, trong đó OrderID là một bảng tham chiếu khóa ngoại Orders

Hình 2.4: Phép dịch mối quan hệ của lược đồ trong Hình 2.2

• Quy tắc 3: Kiểu mối quan hệ một-một giữa hai kiểu thực thể E1 và E2,

được ánh xạ tương ứng với bảng T1 và T2 Ngoài ra, các thuộc tính đơn giátrị đơn và các thành phần đơn của thuộc tính phức được đơn giá trị cũngđược bao gồm trong T2 Bảng này cũng xác định các ràng buộc không rỗngcho các thuộc tính bắt buộc

• Quy tắc 4: Xem xét một kiểu quan hệ một-nhiều liên quan đến các kiểu thực

thể E1 và E2, trong đó T1 và T2 là các bảng kết quả từ việc ánh xạ các thực thểnày Ngoài ra, các thuộc tính đơn giá trị đơn giản và các thành phần đơn giản củathuộc tính phức tạp được đơn giá trị của R được đưa vào T1, xác định các ràng

buộc không rỗng tương ứng cho các thuộc tính bắt buộc Ví dụ, trong Hình 2.1, kiểu

quan hệ một-nhiều Supplies giữa Products và Suppliers được ánh xạ bằng cách bao

gồm thuộc tính SupplierID trong bảng Products, làm khóa ngoại, như trong Hình 2.3.

• Quy tắc 5: Hãy xem xét một kiểu quan hệ nhiều-nhiều giữa các kiểu

thực thể E1 và E2, sao cho T1 và T2 là các bảng kết quả từ việc ánh xạ cácthực thể cũ Bảng T chứa các khóa của T1 và T2 như là các khóa ngoại.Khóa của T là sự hợp nhất của các khóa này Ngoài ra, mã định danh mốiquan hệ, nếu có, có thể xác định khóa của bảng

• Quy tắc 6: Thuộc tính đa giá trị của thực thể hoặc kiểu quan hệ E

được ánh xạ tới bảng T, bảng này cũng bao gồm ID của thực thể hoặc kiểuquan hệ Một ràng buộc toàn vẹn tham chiếu liên quan mã định danh này vớibảng được liên kết với E Khóa chính của T bao gồm tất cả các thuộc tính củanó

• Quy tắc 7: Mối quan hệ tổng quát hóa giữa siêu kiểu E1 và kiểu con

E2 có thể được xử lý theo ba cách khác nhau:

• Quy tắc 7a: Cả E1 và E2 đều được ánh xạ tương ứng tới các bảng T1 và

T2, trong trường hợp đó mã định danh của E1 được truyền tới T2 Một ràng buộctoàn vẹn tham chiếu liên quan đến định danh này với T1

• Quy tắc 7b: Chỉ E1 được liên kết với bảng T1, bảng này chứa tất cả các

thuộc tính của E2 Tất cả các thuộc tính này trở thành tùy chọn trong T1

• Quy tắc 7c: Chỉ E2 được liên kết với bảng T2, trong trường hợp này

tất cả các thuộc tính E1 được kế thừa trong T2

Cần phải lưu ý rằng có sự khác biệt đáng kể về sức mạnh biểu đạt giữa môhình ER và mô hình quan hệ Sự khác biệt này có thể được giải thích bởi thực

tế là mô hình ER là một mô hình khái niệm nhằm thể hiện các khái niệm cànggần với quan điểm của người dùng càng tốt, trong khi mô hình quan hệ là một

mô hình logic được nhắm mục tiêu đến các nền tảng triển khai cụ thể Một sốkhái niệm ER không có sự tương ứng trong mô hình quan hệ và do đó chúngphải được thể hiện chỉ bằng cách sử dụng các khái niệm có sẵn trong mô hình,

đó là quan hệ, thuộc tính và các ràng buộc liên quan