ĐỀ 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ý

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
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


i

NHẬN XÉT CỦA GIẢNG VIÊN
1. Mục tiêu
(a)
(b)
(c)
2. Nội dung
(a)
(b)
(c)
3. Đánh giá kết quả đạt được
(a)
(b)
(c)
Hà Nội, tháng 08 năm 2022
Giảng viên

ThS. Lê Quang Hòa


ii

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 hồ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ến
thức, khi trình bày và trong dịch thuật. Em rất mong nhận thêm nữa những
đóng gó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 ra thê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


iii

Mục lục
Danh sách hình vẽ

1

Chương 1 Mở đầu

3

Chương 2 Cơ sở dữ liệu

5

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
3.1

20

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


iv

4.2.4

Phân mức thay thế . . . . . . . . . . . . . . . . . . . . . . 35

Chương 5 Thiết kế kho dữ liệu logic

37

5.1

Mơ hình kho dữ liệu logic . . . . . . . . . . . . . . . . . . . . . . 37

5.2

Thiết kế kho dữ liệu quan hệ . . . . . . . . . . . . . . . . . . . . . 38

Chương 6 Tổng kết

42

Chương 7 Tài liệu tham khảo

44


1

Danh sách hình vẽ
2.1

Lược đồ khái niệm của cơ sở dữ liệu Northwind . . . . . . . . . . 10

2.2

Kiểu quan hệ OrderDetails được mơ hình hóa như một kiểu thực
thể yếu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4

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

3.1

Khối lập phương dữ liệu bán hàng với ba chiều dữ liệu Product,
Time, Customer và một số đ Quantity . . . . . . . . . . . . . . . 22

3.2

Sơ đồ phân mức của các chiều dữ liệu Hierarchies of the Product,
Time, and Customer dimensions . . . . . . . . . . . . . . . . . . . 23

3.3

a) Khối lập phương ban đầu. (b) Tổng hợp đến mức Country. (c)
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. . . . . . . . . . . . . . . . . . . 25

3.4

Kiến trúc kho dữ liệu điển hình . . . . . . . . . . . . . . . . . . . 29

3.5

Các giai đoạn thiết kế kho dữ liệu . . . . . . . . . . . . . . . . . . 29

4.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 . . . . . . . . . . . . . . . . . . . 31

4.2

Lược đồ khái niệm cho kho dữ liệu Northwind . . . . . . . . . . . 32


2

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


3

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ầu hế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, nhu cầ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 động của thị
trường và khả năng cạnh tranh ngày càng gia tăng dẫn đến nhu cầu nắm thơng
tin thích hợp vào đúng thời điểm. Các nhà quản lý cần được cung cấ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ữu thườ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ải rá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êu
cầ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
cho cá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
tố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ành mộ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ương quan. Kho dữ liệu ngày nay là một công nghệ hoàn thiện


4

đượ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.

5

Chương 2
Cơ sở dữ liệu
Cơ sở dữ liệu cấu thành thành phần cốt lõi của hệ thống thông tin ngày này.
Cơ sở dữ liệu là một tập hợp (chia sẻ được) các dữ liệu liên quan logic và những
mô tả về các dữ liệu đó, được thiết kế để đáp ứng nhu cầu thông tin và hỗ trợ
hoạt động của một tổ chức. Cơ sở dữ liệu sẽ triển khai trên hệ quản trị cơ sở
dữ liệu (DBMS), một hệ thống phần mềm dùng để định nghĩa, tạo, thao tác và
quản trị cơ sở dữ liệu.

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ả 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ương
phá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ác
thuộc tính hệ thống cần thiết và các mong muốn từ những người dùng
tiềm năng, để đồng nhất các yêu cầu và chỉ định mức độ ưu tiên cho chúng.
Trong giai đ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ài long 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.


6

• 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ạn này được
thực hiện bằng cách sử dụng mơ hình khái niệm để xác định các khái niệm
liên quan đến ứng dụng. Mơ hình quan hệ thực thể là một trong nhữ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ễn logic 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 cho biế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úc trong

7

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 đến
mộ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ởi
nhữ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 trong lược
đồ logic. Ví dụ, miễn là các yêu cầu của ứng dụng vẫn được giữ nguyên thì 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 đến lượ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ễm củ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ồm SQL Server và Microsoft Access. Cơ sở dữ liệu chứa dữ liệu bán
hàng của Northwind 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ểm chí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ức

danh 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à


8

ảnh. Ảnh sẽ được lưu trữ trong hệ thống tệp và cần có đường dẫn đến ảnh.
Ngồ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ức thành
từng vùng. Một số nhân viên được chỉ định cho một số lãnh thổ, nhưng
mỗ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ới nhiề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ức hàng giới hạn mà khi chạm mức đó, cơng ty cần bổ sung thêm
vào kho). Sản phẩ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ản phẩ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 giao
hàng thực tế, nhân viên tham gia bán hàng, khách hàng, người giao hàng
chị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 đơn
giá, số lượng và chiết khấu.


9

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 hồn tồ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ượng củ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ủa kiể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ần và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) trong kiể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ố theo kè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ào việc
số lớn nhất trong cặp số theo kèm là 1 hay n.


10

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ó
được gọ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


11

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ản phẩ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ểu quan
hệ, như trường hợp của kiểu quan hệ ReportsTo. Trong trường hợp nà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ột thuộ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ất mộ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).
Ngồi ra, thuộc tính có thể bao gồm nhiều thuộc tính con. Ví dụ, thuộc
tính Names 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ức
cị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ộc
tí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


12

quan đến các phần tử khác ngoài lược đồ và được lưu trữ dưới dạng một thuộ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ột sả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ểu thự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à được biể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


13

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ộc
tí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ưu trữ
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à duy nhấ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ất cho
cơ sở dữ liệu, đó là mơ hình quan hệ. Ta cũng nghiên cứu hai ngôn ngữ 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, đặc biệ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ần lớ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ức vững chắc:
Mơ hình quan hệ được xây dựng dựa trên khái niệm quan hệ tốn họ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ữ truy vấ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ển khai
hiệu quả. Lưu ý rằng mặc dù vậy, chỉ vào đầu những năm 1980, DBMS quan 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

14

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” cho lược đồ ER
tương ứng. Lược đồ quan hệ của cơ sở dữ liệu Northwind bao gồ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


15

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
tốn, các kiể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ạn chế 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 , ..., An : Dn ), 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 Dn , 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 tồ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ính EmployeeID 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. Ngồ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 tồn vẹn tham chiếu chỉ định một liên kết giữa hai bảng, trong đó


16

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, tham
chiế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 tham
chiếu đến bảng được tham chiếu. Ví dụ: thuộc tính EmployeeID trong bả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ất hiện trong
bảng Employees. Lưu ý rằng tính tồ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êm
hoặ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ính OrderDate và RequiredDate cho một đơn đặt hàng nhất
định sao cho OrderDate RequiredDate. Lưu ý rằng nhiều DBMS giới hạn
các ràng buộc kiểm tra đối với một bộ dữ liệu duy nhất: không cho phép
các tham chiếu đến dữ liệu được lưu trữ 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ình
khái niệm nào khác) sang một lược đồ quan hệ tương đương được gọi là một
phé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ác
lượ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


17

thuộc tính đơn đơn giá trị và các thành phần đơn của thuộc tính phức đơn
giá 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ác rà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. Trong
trườ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
tồn vẹ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ủa Wid 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ỗng cho các thuộc tính bắt buộc.


18

• 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ủa thuộ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ác

thự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. Ngồi ra, mã định danh mối
quan 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ểu quan
hệ. Một ràng buộc toàn vẹn tham chiếu liên quan mã định danh này với
bả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ủa nó.
• Quy tắc 7: Mối quan hệ tổng qt 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ộc toà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.


19

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àng
gầ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úng
phả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.

20

Chương 3
Khái niệm kho dữ liệu
3.1

Mơ hình đa chiều dữ liệu

Tầm quan trọng của phân tích dữ liệu đã tăng dần từ đầu những năm 1990,
khi các tổ chức trong tất cả các lĩnh vực buộc phải cải tiến quy trình ra quyết
định để duy trì lợi thế cạnh tranh. Các hệ thống cơ sở dữ liệu truyền thống
không thỏa mãn yêu cầu phân tích dữ liệu. Chúng được thiết kế và điều chỉnh
để hỗ trợ các hoạt động hàng ngày của một tổ chức và mối quan tâm hàng đầu
của chúng chỉ là đảm bảo truy cập nhanh, đồng thời vào dữ liệu. Điều này đòi
hỏi khả năng xử lý giao dịch và kiểm soát đồng thời, cũng như các kỹ thuật khơi
phục đảm bảo tính nhất qn cdữ liệu. Các hệ thống này được gọi là cơ sở dữ
liệu hoạt động hoặc hệ thống xử lý giao dịch trực tuyến (OLTP). Mơ hình
OLTP tập trung vào các giao dịch. Trong ví dụ về cơ sở dữ liệu Northwind, một
giao dịch đơn giản có thể liên quan đến việc nhập một đơn đặt hàng mới, đặt
trước sản phẩm. Cuối cùng, người dùng có thể muốn biết trạng thái của một
đơn đặt hàng nhất định. Vì hệ thống OLTP phải hỗ trợ tải giao dịch lớn, thiết
kế của chúng phải ngăn chặn sự bất thường của bản cập nhật và do đó, cơ sở dữ
liệu OLTP được chuẩn hóa cao. Chúng sẽ hoạt động kém khi thực hiện các truy
vấn phức tạp cần nối nhiều bảng quan hệ với nhau hoặc để tổng hợp khối lượng
lớn dữ liệu.
Các nhu cầu phức tạp địi hỏi một mơ hình mới được định hướng cụ thể để