MỞ ĐẦU: Trình bày lí do chọn đề tài, mục đích, đối tượng và phạm vi nghiên cứu.

TỔNG QUAN: Phân tích đánh giá các hướng nghiên cứu đã có của các tác giả

trong và ngoài nước liên quan đến đề tài; nêu những vấn đề còn tồn tại; chỉ ra

những vấn đề mà đề tài cần tập trung, nghiên cứu giải quyết.

NGHIÊN CỨU THỰC NGHIỆM HOẶC LÍ THUYẾT: Trình bày cơ sở lí thuyết,

lí luận, giả thiết khoa học và phương pháp nghiên cứu đã được sử dụng trong khoá

luận .

TRÌNH BÀY, ĐÁNH GIÁ BÀN LUẬN VỀ CÁC KẾT QUẢ: Mô tả ngắn gọn công

việc nghiên cứu khoa học đã tiến hành, các kết quả nghiên cứu khoa học hoặc kết

quả thực nghiệm. Đối với các đề tài ứng dụng có kết quả là sản phẩm phần mềm

phải có hồ sơ thiết kế, cài đặt, ... theo một trong các mô hình đã học (UML, ...)

KẾT LUẬN: Trình bày những kết quả đạt được, những đóng góp mới và những đề

xuất mới. Phần kết luận cần ngắn gọn, không có lời bàn và bình luận thêm.

HƯỚNG PHÁT TRIỂN: Kiến nghị về những hướng nghiên cứu tiếp theo.

DANH MỤC TÀI LIỆU THAM KHẢO: Chỉ bao gồm các tài liệu được trích dẫn,

sử dụng và đề cập tới để bàn luận trong khoá luận .

PHỤ LỤC.

1

Chương 1. Kho dữ liệu..........................................................................................6

1.1. Tổng quan về kho dữ liệu..............................................................................6

1.1.1. Khái niệm............................................................................................6

1.1.2. Các nhu cầu thực tế của kho dữ liệu...................................................6

1.1.3. Các đặc trưng của kho dữ liệu.............................................................6

1.2. Kiến trúc kho dữ liệu.....................................................................................7

1.2.1. Các kiến trúc chính..............................................................................7

1.2.1.1. Kiến trúc DDS đơn..........................................................................8

1.2.1.2. Kiến trúc NDS+DDS.....................................................................10

1.2.1.3. Kiến trúc ODS+DDS.....................................................................11

1.2.2. Vùng xử lí..........................................................................................12

1.2.3. Cơ sở dữ liệu chuẩn hoá....................................................................13

1.2.4. Kho dữ liệu đầu cuối.........................................................................15

1.3. Các thách thức đối với kho dữ liệu..............................................................16

1.3.1. Chất lượng dữ liệu.............................................................................16

1.3.2. Khối lượng dữ liệu và hiệu suất hoạt động.......................................17

1.3.3. Nắm bắt các thay đổi trên dữ liệu......................................................18

1.3.4. Yêu cầu người dùng thay đổi............................................................19

1.4. Các xu hướng xây dựng kho dữ liệu...........................................................19

Chương 2. Mô hình hoá sử dụng lược đồ hình sao.............................................20

2.1. So sánh phương pháp mô hình hoá của Bill Inmon và Ralph Kimball.......20

2.2. Lược đồ hình sao.........................................................................................21

2.2.1. Bảng chiều và bảng dữ kiện..............................................................22

2.2.2. Các đặc trưng của lược đồ hình sao..................................................23

2

2.3. Truy vấn trên lược đồ hình sao....................................................................23

2.4. Kiến trúc buýt..............................................................................................23

2.5. Các nguyên tắc thiết kế...............................................................................24

2.5.1. Sử dụng khoá đại diện:......................................................................24

2.5.2. Quy tắc đặt tên và kiểu......................................................................24

2.5.3. Độ mịn và mức tổng hợp...................................................................25

2.5.4. Ngày giờ............................................................................................25

2.5.5. Khoá vô danh....................................................................................25

Chương 3. Tích hợp dữ liệu................................................................................27

3.1. Khái niệm....................................................................................................27

3.2. Các bước tiến hành của quá trình tích hợp dữ liệu......................................27

3.2.1. Kết xuất dữ liệu:................................................................................27

3.2.2. Biến đổi dữ liệu:................................................................................31

3.2.3. Nạp dữ liệu........................................................................................33

3.3. Các vấn đề gặp phải khi xây dựng hệ thống tích hợp dữ liệu và giải pháp.43

3.3.1. Vấn đề cập nhật dữ liệu trong thời gian thực....................................43

3.3.2. Vấn đề về không nhất quán dữ liệu khi thực hiện truy vấn...............44

Chương 4. Phần mềm tích hợp dữ liệu mã nguồn mở Kettle..............................47

4.1. Giới thiệu tổng quan:...................................................................................47

4.1.1. Giới thiệu:..........................................................................................47

4.1.2. Một số khái niệm trong Kettle:.........................................................47

4.1.3. Một số bước thường dùng và các chú ý trong Kettle:.......................48

4.1.3.1. Table input:....................................................................................48

4.1.3.2. Modified java script:......................................................................49

3

4.1.3.3. Filter rows:.....................................................................................50

4.1.3.4. Dimension lookup/ update:............................................................50

4.1.3.5. Combination lookup/ update:........................................................52

4.1.3.6. Update:...........................................................................................54

Chương 5. Xây dựng kho dữ liệu phục vụ các hệ thống học tập trực tuyến.......56

5.1. Mô tả yêu cầu ứng dụng..............................................................................56

5.1.1. Các yêu cầu phân tích dữ liệu đối với các hệ thống học tập trực

tuyến: 56

5.1.2. Ma trận kiến trúc buýt:......................................................................56

5.2. Kiến trúc của ứng dụng...............................................................................57

5.3. Thiết kế kho dữ liệu.....................................................................................57

5.3.1. Vùng xử lí..........................................................................................57

5.3.1.1. Moodle...........................................................................................57

5.3.1.2. Kết quả học tập..............................................................................59

5.3.1.3. Dữ liệu học ky, năm học................................................................59

5.3.2. Cơ sở dữ liệu chuẩn hoá....................................................................60

5.3.2.1. Lược đồ..........................................................................................60

5.3.2.2. Các diễn giải liên quan đến thiết kế...............................................61

5.3.2.3. Đặc tả cơ sở dữ liệu.......................................................................61

5.3.3. Kho dữ liệu đầu cuối.........................................................................65

5.3.3.1. Lược đồ cơ sở dữ liệu....................................................................65

5.3.3.1. Các diễn giải liên quan đến thiết kế...............................................66

5.3.3.2. Đặc tả cơ sở dữ liệu.......................................................................68

5.3.3.3. Phân cấp các chiều:........................................................................73

4

5.4. Thiết kế hệ thống tích hợp dữ liệu...............................................................74

5.4.1. Rút trích dữ liệu – ETL cho vùng xử lí.............................................74

5.4.2. Biến đổi dữ liệu – ETL cho cơ sở dữ liệu chuẩn hoá........................75

5.4.3. Nạp dữ liệu – ETL cho kho dữ liệu...................................................77

5.5. Xây dựng ứng dụng đóng gói......................................................................79

5.6. Triển khai ứng dụng....................................................................................79

5.6.1. Các phần mềm đi kèm:......................................................................79

5.6.2. Cài đặt...............................................................................................79

5.6.3. Sử dụng.............................................................................................79

5

Chương 1. Kho dữ liệu

1.1. Tổng quan về kho dữ liệu

1.1.1. Khái niệm

Khái niệm kho dữ liệu (data warehouse) lần đầu tiên được đưa ra bởi hai kiến

trúc sư người Ireland của công ty IBM là Barry Devlin và Paul Murphy năm

1988. Từ đó đến nay, khái niệm kho dữ liệu hầu như không có nhiều thay đổi.

Theo Barry Devlin và Paul Murphy, kho dữ liệu được hiểu là: “Một nhà kho

luận lí chứa tất cả những thông tin cần thiết phục vụ cho các báo cáo nghiệp vụ”

(Pentaho Solutions – Trang 111).

1.1.2. Các nhu cầu thực tế của kho dữ liệu

Kho dữ liệu là một cơ sở dữ liệu được thiết kế đặc biệt cho các nhu cầu liên

quan đến việc hỗ trợ ra quyết định. Từ góc nhìn của người dùng, kho dữ liệu

mang lại những lợi ích sau:

Dữ liệu lưu trữ tập trung tại một nơi

Thông tin luôn được cập nhật: Thông tin từ nhiều nguồn được cập nhật

định kì vào kho.

Truy xuất nhanh: Kho dữ liệu được thiết kế đặc biệt cho việc truy xuất

nhanh với khối lượng thông tin lớn.

Không giới hạn kích thước

Lưu mọi thông tin lịch sử: Toàn bộ lịch sử dữ liệu được lưu vết, phục vụ

việc phân tích số liệu theo thời gian.

Dễ hiểu: Kho dữ liệu được mô hình hoá dựa trên những thuật ngữ nghiệp

vụ, gần gũi và dễ hiểu.

Rõ ràng và đồng nhất: Dữ liệu được hợp nhất và thống nhất dựa trên các

khái niệm nghiệp vụ.

Dữ liệu chuẩn hoá: Tất cả dữ liệu được chuẩn hoá theo một chuẩn

chung.

6

1.1.3. Các đặc trưng của kho dữ liệu

Kho dữ liệu có các đặc trưng sau đây (theo Bill Inmon):

Hướng chủ thể (subject oriented): Tất cả các thực thể và sự kiện liên

quan đến một chủ thể được kết nối với nhau.

Biến thiên theo thời gian: Tất cả các thay đổi trên dữ liệu được theo dõi

để thể hiện sự biến đổi theo thời gian.

Tính ổn định (non-volatile): Khi dữ liệu được lưu vào kho, nó sẽ không

bao giờ bị ghi đè hoặc xoá. Với nhiều kiến trúc cao cấp, tính chất này

không được duy trì trên từng phần nhưng về tổng thể cần được bảo đảm.

Tính tích hợp: Kho dữ liệu chứa dữ liệu được tích hợp từ nhiều hệ thống

nguồn sau khi đã được làm sạch và chuẩn hoá.

Kho dữ liệu được xây dựng nhằm mục đích:

Bảo đảm hiệu suất hoạt động của hệ thống sản xuất không bị gián đoạn

bởi các truy vấn dạng đặc biệt dạng phân tích. Các truy vấn loại này vốn

có thời gian truy vấn lâu trên lượng dữ liệu lớn.

Bảo đảm các thông tin không bị thay đổi trong khi người dùng cuối truy

vấn.

1.2. Kiến trúc kho dữ liệu

1.2.1. Các kiến trúc chính

Kiến trúc chung của một kho dữ liệu thường gồm nhiều vùng chứa dữ liệu

(data store) nhỏ. Những vùng chứa dữ liệu này được phân loại dựa trên cấu

trúc bao gồm (Building a DW – With examples in SQL Server – Trang 29-39):

Vùng xử lí (staging area): Là vùng chứa dữ liệu chuẩn bị cho việc biến

đổi dữ liệu thu được từ nguồn trước khi chuyển qua các vùng chứa dữ

liệu khác trong kho dữ liệu. Trong các hình vẽ, vùng này được viết tắt là

“staging” hay “STG”.

Vùng chứa dữ liệu dạng chuẩn hoá (normalized data store): Là vùng

chứa dữ liệu trung gian sau khi đã được biến đổi và tích hợp từ nhiều

7

nguồn khác nhau. Trong vùng này, dữ liệu được lưu trữ ở dạng chuẩn

cao, thường là dạng chuẩn 3. Dữ liệu trong vùng này đã sẵn sàng được

nạp vào vùng kho dữ liệu đầu cuối mà không cần nhiều biến đổi phức

tạp. Trong các hình vẽ, vùng này được viết tắt là NDS.

Vùng chứa dữ liệu hoạt động (operational data store): Là vùng chứa dữ

liệu dạng lai (hybrid) giữa vùng dữ liệu chuẩn hoá và cơ sở dữ liệu hoạt

động (operational database). Mục đích của nó ngoài việc hỗ trợ cho việc

nạp dữ liệu vào kho dữ liệu đầu cuối, còn được dùng như là cơ sở dữ liệu

hoạt động tập trung (centralized).

Kho dữ liệu đầu cuối, còn gọi là vùng dữ liệu đa chiều (dimesional data

store): Là vùng kho dữ liệu đầu cuối, phía người dùng. Trong vùng này,

dữ liệu được lưu trữ dưới dạng mô hình hoá đa chiều (dimensional

modeling) nhằm hỗ trợ các ứng dụng hay truy vấn dạng phân tích đầu

cuối. Trong các hình vẽ, vùng này được viết tắt là DDS, DW hay DWH.

Kho dữ liệu có rất nhiều loại kiến trúc. Từ đơn giản nhất, chỉ gồm một kho

dữ liệu đầu cuối, đến rất phức tạp, bao gồm nhiều kho dữ liệu trung gian, được

sử dụng trong những hệ thống lớn. Tuy nhiên, hầu hết các kiến trúc đều dựa

trên 3 kiến trúc chung phổ biến sau:

Kiến trúc DDS đơn (single DDS) chỉ bao gồm kho dữ liệu đầu cuối và

một vùng xử lí.

Kiến trúc NDS+DDS là kiến trúc bao gồm vùng xử lí, vùng dữ liệu

chuẩn hoá, và kho dữ liệu đầu cuối.

Kiến trúc ODS+DDS tương tự như kiến trúc NDS+DDS nhưng sử dụng

vùng dữ liệu hoạt động thay cho vùng dữ liệu chuẩn hoá.

Mỗi kiến trúc đều có những ưu điểm và nhược điểm riêng. Sau đây, chúng

ta sẽ phân tích sơ qua từng kiến trúc.

1.2.1.1. Kiến trúc DDS đơn

8

Hình 1.2.1.1-1: Kiến trúc kho dữ liệu dạng DDS đơn

Kiến trúc DDS đơn là một trong những dạng kiến trúc đơn giản nhất của

kho dữ liệu. Kiến trúc này có thành phần chính là một kho dữ liệu trung

tâm.

Dữ liệu từ nhiều hệ thống nguồn được nạp vào vùng xử lí thông qua một

gói ETL (Extract-Transform-Load: Rút trích-Biến đổi-Nạp – Xem chương

3). Gói ETL này sẽ rút trích dữ liệu từ nhiều nguồn khác nhau, thực hiện

một số phép biến đổi dữ liệu đơn giản. Dữ liệu sau đó được chứa trong

vùng xử lí.

Dữ liệu trong vùng xử lí sau khi được xử lí sơ bộ sẽ được biến đổi thông

qua một gói ETL khác để đưa vào kho dữ liệu đầu cuối. Quá trình biến đổi

này bao gồm nhiều công đoạn từ việc làm sạch, chuẩn hoá dữ liệu đến việc

quản lí chất lượng và lịch sử thay đổi của dữ liệu.

Kho dữ liệu đầu cuối chứa những dữ liệu đã được biến đổi, chuẩn hoá, và

lưu trữ dưới dạng mô hình đa chiều, sẵn sàng phục vụ cho các ứng dụng

đầu cuối.

Ưu điểm:

o Kiến trúc đơn giản.

o Ít công đoạn xử lí.

o Thuận lợi khi xây dựng những kho dữ liệu nhỏ.

Nhược điểm:

9

o Không hỗ trợ việc tạo ra nhiều kho dữ liệu phục vụ cho nhiều mục

đích khác nhau dựa trên dữ liệu sẵn có. Nếu có nhu cầu chỉ cần sử

dụng một phần của kho dữ liệu (data-mart) thì phải xây dựng một

gói ETL khác phục vụ quá trình này.

o Không tái sử dụng được gói ETL đã làm. Mỗi một quy trình rút

trích-biến đổi-nạp cho từng thành phần trong kho dữ liệu đầu cuối

được thực hiện độc lập. Việc này gây khó khăn cho việc xây dựng

những kho dữ liệu lớn.

1.2.1.2. Kiến trúc NDS+DDS

Hình 1.2.1.2-1: Kiến trúc kho dữ liệu dạng NDS+DDS

Đây là một kiến trúc khá phổ biến. Kiến trúc này tương tự như kiến trúc

DDS đơn, nhưng có thêm một vùng chứa dữ liệu trung gian là vùng chứa

dữ liệu chuẩn hoá NDS.

Dữ liệu sau khi được làm sạch, thay vì đưa thẳng vào kho dữ liệu đầu

cuối, nó được lưu trong vùng chứa dữ liệu trung gian. Vùng chứa dữ liệu

trung gian đóng vai trò như là một cơ sở dữ liệu tập trung, đã được chuẩn

hoá, bao gồm cả dữ liệu lịch sử. Việc nạp vào kho dữ liệu đầu cuối sẽ

không cần qua công đoạn làm sạch và quản lí chất lượng dữ liệu nữa.

Ưu điểm:

o Lưu trữ dữ liệu tập trung đã được làm sạch.

o Chứa dữ liệu lịch sử.

10

o Sẵn sàng cho việc nạp vào nhiều kho dữ liệu đầu cuối.

o Tái sử dụng được các gói ETL.

Nhược điểm:

o Kiến trúc phức tạp

o Tốn thêm không gian lưu trữ.

o Thời gian thực hiện một chu kì nạp dữ liệu lâu hơn so với kiến trúc

DDS đơn.

o Vùng chứa dữ liệu trung gian không được tận dụng vào mục đích

khác.

1.2.1.3. Kiến trúc ODS+DDS

Hình 1.2.1.3-1: Kiến trúc kho dữ liệu dạng ODS+DDS

Kiến trúc này có nhiều điểm tương đồng với kiến trúc NDS+DDS. Như

trong hình vẽ, thay vì sử dụng một vùng dữ liệu chuẩn hoá làm vùng dữ liệu

trung gian, người ta sử dụng một vùng dữ liệu hoạt động thay cho nó.

Vùng dữ liệu hoạt động này cũng là một cơ sở dữ liệu dạng chuẩn hoá

cao. Tuy nhiên, nó không lưu dữ liệu lịch sử. Vùng dữ liệu hoạt động có

cấu trúc nghiêng về dạng cơ sở dữ liệu phục vụ giao tác (OLTP) nhiều hơn.

Nó đóng vai trò như là một cơ sở dữ liệu tập trung mà ở đó, ứng dụng đầu

cuối cho phép khai thác trên nó.

Có thể thấy những ưu điểm và nhược điểm của nó so với kiến trúc

NDS+DDS như sau:

11

Ưu điểm:

o Lưu trữ dữ liệu tập trung đã được làm sạch.

o Tận dụng làm cơ sở dữ liệu tập trung phục vụ giao tác cho ứng

dụng đầu cuối.

Nhược điểm:

o Không chứa dữ liệu lịch sử.

o Các gói ETL để đưa dữ liệu từ vùng dữ liệu hoạt động vào kho dữ

liệu đầu cuối phức tạp hơn.

o Vùng dữ liệu hoạt động có thể bị gián đoạn khi nạp kho dữ liệu.

o Không tái sử dụng được các gói ETL.

Trong nội dung của cuốn khoá luận này, nội dung sẽ tập trung vào kiến

trúc NDS+DDS.

1.2.2. Vùng xử lí

Hình 1.2.2-1: Vùng xử lí

Thông thường, trong tất cả các kiến trúc kho dữ liệu, luôn có một vùng

chứa dữ liệu gọi là vùng xử lí. Dữ liệu được chuyển từ nhiều nguồn vào vùng

xử lí mà không thông qua (hoặc rất ít) công đoạn xử lí nào.

Hẳn nhiên, có thể nạp trực tiếp dữ liệu từ nguồn vào kho dữ liệu đầu cuối.

Tuy vậy, việc sử dụng một vùng xử lí có các lợi ích sau:

Giảm thiểu tối đa thời gian rút trích dữ liệu từ nguồn. Việc này nhằm

tránh gián đoạn đến hoạt động của các cơ sở dữ liệu nguồn. Thông

thường, người ta sẽ sao chép y nguyên dữ liệu nguồn vào vùng này.

12

Khi sử dụng các vùng xử lí độc lập cho từng nguồn, cho phép thao tác

trên một tập hợp nhỏ các dữ liệu mà ta cần sử dụng, thay vì truy vấn toàn

bộ dữ liệu nguồn.

Vùng xử lí nếu được cài đặt chỉ mục hợp lí, sẽ hỗ trợ việc nạp dữ liệu

vào kho dữ liệu nhanh hơn.

Vùng xử lí cho phép phục hồi sau sự cố. Dữ liệu khi đã được nạp vào

vùng xử lí, có thể được xem là an toàn. Trong quá trình nạp dữ liệu vào

kho dữ liệu, nếu bị gián đoạn do sự cố, quá trình nạp dữ liệu dễ dàng

được phục hồi bằng cách nạp tiếp dữ liệu đang nạp từ vùng này. Bởi vì

trong mỗi lần nạp, dữ liệu ở vùng xử lí không bị thay đổi, nên hoàn toàn

không ảnh hưởng đến quá trình nạp. Nếu nạp trực tiếp từ nguồn, nơi dữ

liệu thay đổi thường xuyên, quá trình nạp phải được làm lại từ đầu, bao

gồm cả việc loại bỏ các dữ liệu đang nạp dở dang.

Vùng xử lí có thể lưu trữ dữ liệu dài hạn, như là một cơ sở dữ liệu trung

gian. Nhưng thông thường, người ta sẽ xoá đi sau mỗi lần nạp dữ liệu. Đặc

biết đối với các kiến trúc cấp cao như NDS+DDS hay ODS+DDS, việc lưu trữ

dữ liệu trong vùng xử lí sau mỗi công đoạn nạp là hoàn toàn không cần thiết.

Cấu trúc của dữ liệu vùng xử lí như sau:

Đối với dữ liệu nguồn là cơ sở dữ liệu: Dữ liệu trong vùng xử lí là tất cả

các bảng chứ dữ liệu cần thiết cho việc nạp dữ liệu, nhưng chỉ chứa các

cột dữ liệu cần thiết mà thôi. Các bảng được loại bỏ các ràng buộc khoá

chính, khoá ngoại và chỉ mục. Việc này nhằm tăng tốc cho sao chép dữ

liệu nguồn. Để tránh việc dữ liệu không nhất quán, các gói ETL cần được

thiết kế cẩn thận để giải quyết việc này.

Đối với dữ liệu nguồn là dạng tập tin: Đơn giản chỉ cần sao chép nó đến

máy chủ.

1.2.3. Cơ sở dữ liệu chuẩn hoá

13

Hình 1.2.3-1: Cơ sở dữ liệu chuẩn hoá.

Đối với kiến trúc NDS+DDS, vùng chứa dữ liệu dạng chuẩn hoá, còn được

gọi là cơ sở dữ liệu chuẩn hoá đóng vai trò là một cơ sở dữ liệu tập trung. Cơ

sở dữ liệu này có các đặc điểm sau:

Là nơi tập trung dữ liệu từ nhiều nguồn. Tất cả dữ liệu này đều đã được

làm sạch.

Cơ sở dữ liệu được tổ chức ở dạng chuẩn hoá cao, nhằm bảo đảm chất

lượng dữ liệu, các ràng buộc toàn vẹn trên dữ liệu cũng như tính nhất quá

của dữ liệu.

Các thông tin về lịch sử của dữ liệu được lưu lại toàn bộ ở đây. Nếu dữ

liệu nguồn không chứa thông tin lịch sử, gói ETL dùng biến đổi dữ liệu

vào cơ sở dữ liệu chuẩn hoá sẽ đảm nhận việc bổ sung các dữ liệu lịch

sử. Thường là ngày tháng khi lấy dữ liệu. Nếu dữ liệu nguồn chứa thông

tin lịch sử, gói ETL dùng biến đổi dữ liệu sẽ chuyển đổi các thông tin

lịch sử tương ứng từ nguồn vào cơ sở dữ liệu chuẩn hoá. Các thông tin

này cho phép nắm bắt lịch sử dữ liệu tại một nơi tập trung duy nhất.

Cấu trúc của cơ sở dữ liệu chuẩn hoá rất gần với cấu trúc của kho dữ liệu

đầu cuối, tuy nhiên được tổ chứ ở dạng chuẩn cao. Việc này giúp tăng

tốc cho các tính toán số liệu trong khi nạp các dữ kiện vào kho dữ liệu.

Dữ liệu sau mỗi lần nạp thành công vào cơ sở dữ liệu chuẩn hoá, sẽ được

xoá trong vùng xử lí. Khi quá trình nạp dữ liệu bị gián đoạn, quá trình nạp dữ

liệu được thực hiện tiếp tục trên những dữ liệu chưa được nạp thành công, tức

là vẫn còn dữ liệu trên vùng xử lí.

14

1.2.4. Kho dữ liệu đầu cuối

Hình 1.2.4-1: Kho dữ liệu đầu cuối

Trong một hệ thống kho dữ liệu, kho dữ liệu đầu cuối là thành phần quan

trọng nhất, ở đó, dữ liệu được tổ chức theo một cấu trúc đặc biệt: mô hình đa

chiều (dimensional). Đây là cấu trúc dạng tối ưu phục vụ truy vấn đầu cuối

cho các ứng dụng phân tích như OLAP, khai thác dữ liệu,…

Đây là kiểu cấu trúc dựa trên mô hình khối đa chiều (multi-dimension

cube). Mỗi khối đa chiều là bao gồm một bảng dữ kiện (fact) và các bảng

chiều (dimension). Dữ kiện là các độ đo, các số liệu được tính toán từ các

chiều. Cấu trúc dữ liệu này có đặc trưng là phi chuẩn hoá (denormalized). Đây

là một đặc trưng quan trọng của kho dữ liệu mô hình hoá đa chiều.

Cấu trúc và phương pháp mô hình hoá đa chiều được đề cập trong Chương

2 - Mô hình hoá sử dụng lược đồ hình sao.

Nói một cách tóm tắt, kho dữ liệu đầu cuối nhằm mục đích sau:

Tăng tốc tối đa thời gian truy vấn trên các dữ liệu dạng phân tích. Dữ

liệu truy vấn trên kho dữ liệu cho tốc độ rất cao. Ở những hệ thống lớn,

với nhiều nguồn dữ liệu, một câu truy vấn chạy trực tiếp trên dữ liệu

nguồn có thể mất hàng giờ đồng hồ, nhưng khi chạy trên hệ thống kho

dữ liệu chỉ mất vài phút. Việc rút ngắn thời gian như vậy là rất đáng kể.

Ngoài ra, nó còn giúp hạn chế việc gián đoạn hoạt động của các hệ thống

nguồn.

Hỗ trợ phân tích các thay đổi mang tính lịch sử trên dữ liệu. Kho dữ liệu

được tổ chức để theo dõi toàn bộ các thay đổi của dữ liệu. Vì vậy, các

15

phân tích dữ liệu theo dòng thời gian là đặc biệt nhanh chóng và hiệu

quả.

Đối với những truy vấn có được phát biểu dưới dạng tương tự nhau, câu

truy vấn SQL/MDX trên kho dữ liệu có rất ít khác biệt. Các truy vấn phát

biểu dạng này cũng dễ hiểu và gần gũi người dùng cuối. Chẳng hạn: câu

truy vấn “Tương quan tỉ lệ sinh viên đậu/rớt trong năm nay so với các

năm trước?” và “Tương quan giữa thời gian sử dụng hệ thống học tập

trực tuyến và điểm số của sinh viên?” là những câu truy vấn có cấu trúc

tương tự nhau.

Hỗ trợ xây dựng khối OLAP nhanh, hiệu quả. OLAP là một trong những

ứng dụng đầu cuối phổ biến trong việc sử dụng hệ thống kho dữ liệu.

Khối OLAP mặc dù có thể xây dựng trên cơ sở dữ liệu thông thường,

nhưng nếu được xây dựng trên kho dữ liệu, sẽ giảm thiểu thời gian xây

dựng khối và tăng tốc các truy vấn OLAP.

1.3. Các thách thức đối với kho dữ liệu

Việc xây dựng kho dữ liệu là một công việc phức tạp và đòi hỏi nhiều vấn đề

cần được nghiên cứu kĩ càng trước khi cài đặt. Đối với kho dữ liệu, nhưng thách

thức sau đây luôn được đặt lên hàng đầu:

1.3.1. Chất lượng dữ liệu

Thách thức lớn nhất là việc quản lí chất lượng dữ liệu. Bởi vì bản thân các

hệ thống nguồn thường không bao giờ không bị lỗi trên dữ liệu, việc xây dựng

kho dữ liệu bảo đảm cung cấp đầy đủ thông tin và nhiều ý nghĩa là liên hệ

sống còn đến tính hiệu quả của kho dữ liệu. Quản lí chất lượng dữ liệu bao

gồm:

Dữ liệu trùng lắp: Xảy ra khi cùng một dữ liệu được ghi nhiều lần vào

kho, nhưng không thể theo dõi được do thiếu các ràng buộc khoá.

16

Dữ liệu không đầy đủ: Dữ liệu thiếu trong quá trình nhập liệu, chẳng hạn

sinh viên thiếu thông tin về địa chỉ tạm trú/thường trú. Việc này làm

giảm hiệu quả của các phân tích đầu cuối.

Dữ liệu sai: Là trường hợp dữ liệu bị lỗi chẳng hạn như lỗi đánh máy, lỗi

chính tả, chữ hoa, chữ thường…

Xung đột dữ liệu: Đây là trường hợp cùng một dữ liệu nhưng được lưu

trữ trên nhiều bảng hoặc thậm chí nhiều nguồn khác nhau, nhưng không

nhất quán.

Siêu dữ liệu không rõ nghĩa: Thường là do cùng một đối tượng dữ liệu

nhưng khác kiểu dữ liệu hoặc sai lệch về ngữ nghĩa của dữ liệu trên các

nguồn khác nhau. Chẳng hạn cùng tên cột, cùng bảng, nhưng trên 2

nguồn khác nhau có ngữ nghĩa hoàn toàn khác nhau.

Thiếu dữ liệu: Là trường hợp dữ liệu lẽ ra phải có để bảo đảm toàn vẹn

(tham chiếu…), nhưng không tìm thấy các dữ liệu này ở nơi khác.

Dữ liệu NULL: Đây là dạng dữ liệu rất chung chung và tối nghĩa. Nó cần

được dịch ra để phù hợp với ngữ cảnh.

1.3.2. Khối lượng dữ liệu và hiệu suất hoạt động

Nếu như lượng dữ liệu trung bình cho mỗi cơ sở dữ liệu khoảng vài đến vài

chục Gigabyte, dữ liệu trong kho dữ liệu có thể lên đến vài chục Terabyte,

thậm chí còn được tính bằng đơn vị Petabytes (1Petabytes = 1024Terabytes).

Điều này là hoàn toàn dễ hiểu vì 2 lí do sau:

Dữ liệu được mô hình hoá đa chiều, tổ chức dưới dạng phi chuẩn

(denormalized) khiến cho khối lượng dữ liệu trùng lắp tăng đáng kể.

Dữ liệu lịch sử được lưu lại ở mức chi tiết nhất có thể, theo thời gian, sẽ

tăng lên rất nhanh.

Đối với lượng dữ liệu lớn như vậy, các đề nghị sau cần được xem xét để

tăng hiệu suất hoạt động cho kho:

Xây dựng hệ thống vật lý độc lập nguồn: Việc này làm giảm tải xử lí cho

hệ thống nguồn. Tuy rằng việc tổ chức trên cùng một hệ thống vật lí với 17

hệ thống nguồn cho phép tăng thời gian nạp, ngược lại, lại làm giảm hiệu

suất hoạt động của chính hệ thống nguồn. Hơn nữa, các hệ thống nguồn

nằm rải rác thì không thể tổ chức một hệ thống kho dữ liệu phân tán trên

đó được.

Cài đặt chỉ mục: Hoạt động chính của kho dữ liệu là việc đọc dữ liệu hơn

là ghi dữ liệu lên đó. Các câu truy vấn chủ yếu tốn thời gian ở việc tìm

kiếm dữ liệu. Cài đặt chỉ mục hợp lí là phương pháp hiệu quả để tăng tốc

truy vấn. Các truy vấn thường dùng cần được phân tích cho việc cài đặt

chỉ mục.

Chỉ mục dạng bitmap: Đây là dạng chỉ mục rất hiệu quả đối với những

bảng có số lượng các giá trị rời rạc (cardinality) thấp. Xem xét việc cài

đặt chỉ mục dạng này cũng làm tăng đáng kể hiệu suất truy vấn.

Dữ liệu tổng hợp (Aggregation): Có thể xem xét việc tiền xử lí các dữ

kiện, chẳng hạn như xây dựng các bảng trung gian, chứa các dữ liệu

được tổng hợp (sum, count, average) ở độ mịn cao.

1.3.3. Nắm bắt các thay đổi trên dữ liệu

Việc nạp dữ liệu từ nguồn vào vùng xử lí thoạt nhìn có vẻ đơn giản. Nhưng

không hẳn như vậy. Người ta không thể mỗi lần nạp dữ liệu đều sao chép toàn

bộ dữ liệu từ nguồn vào vùng xử lí. Đây là việc làm rất tốn kém và không hiệu

quả. Thay vào đó, người ta cố gắng nắm bắt được các thay đổi trên dữ liệu,

bao gồm các dữ liệu mới và các dữ liệu cũ vừa bị thay đổi.

Có 4 kĩ thuật nắm bắt thay đổi dữ liệu nguồn, được chia làm 2 loại chính:

Kĩ thuật xâm nhập (intrusive): Là các kĩ thuật ở đó cần thực hiện truy

vấn trên dữ liệu nguồn mà gây ảnh hưởng đến hiệu suất hoạt động của

nó. Bao gồm:

o Nắm bắt thay đổi dựa trên dữ liệu nguồn: Là kĩ thuật nắm bắt thay đổi

dựa trên chính các thuộc tính trong dữ liệu nguồn.

Dựa trên nhãn thời gian: dựa vào các nhãn thời gian có sẵn trên dữ

liệu nguồn như nhãn thêm, nhãn sửa…18

Dựa trên định danh tự động tăng: chỉ nắm bắt được thay đổi của dữ

liệu mới.

o Nắm bắt thay đổi dựa trên trigger: Bằng cách cài đặt thêm trigger vào

cơ sở dữ liệu nguồn. Các dữ liệu lịch sử này được lưu riêng, cho phép

hệ thống kho dữ liệu truy vấn để rút trích dữ liệu mới hoặc đã thay

đổi.

o Nắm bắt thay đổi dựa trên ảnh chụp dữ liệu (snapshot): Đây là kĩ thuật

mà ở đó, vùng xử lí lưu lại toàn bộ dữ liệu của lần nạp trước như là

một ảnh chụp dữ liệu. Dữ liệu ở lần nạp sau được so sánh với dữ liệu

trước để so sánh thay đổi trước khi quyết định sẽ lấy dữ liệu nào. Kĩ

thuật này được sử dụng đối với dữ liệu nguồn thiếu thông tin lịch sử,

và tránh việc phải thay đổi hệ thống nguồn (bằng trigger).

Kĩ thuật phi xâm nhập (non-intrusive): Là các kĩ thuật không gây ảnh

hưởng đến hiệu suất hoạt độn của dữ liệu nguồn.

o Nắm bắt thay đổi dựa trên log: Trên mỗi hệ thống nguồn, có thể sử

dụng có sẵn (đối với cơ sở dữ liệu) hay cài đặt một chương trình ghi

log, quản lí toàn bộ lịch sử thay đổi của nguồn.

1.3.4. Yêu cầu người dùng thay đổi

Cũng giống như mọi dự án phần mềm khác, việc xây dựng hệ thống có thể

bảo đảm được cho việc thay đổi yêu cầu người dùng trong tương lai là thách

thức rất lớn.

1.4. Các xu hướng xây dựng kho dữ liệu

Kho dữ liệu ảo

Kho dữ liệu thời gian thực

Kho dữ liệu phân tích

19

Chương 2. Mô hình hoá sử dụng lược đồ hình sao

Như đã đề cập ở chương 1, việc tối ưu hoá tốc truy vấn cho kho dữ liệu là điều

kiện tiên quyết cho hiệu quả triển khai một dự án kho dữ liệu. Vì vậy cấu trúc cơ sở

dữ liệu của kho dữ liệu cần được tổ chức theo một mô hình đặc trưng riêng. Đó là

phương pháp mô hình hoá đa chiều.

2.1. So sánh phương pháp mô hình hoá của Bill Inmon và Ralph Kimball

Việc tổ chức dữ liệu trong cơ sở dữ liệu của kho dữ liệu được tiếp cận theo 2

hướng sau:

Phương pháp mô hình hoá dạng chuẩn hoá của Bill Inmon (lược đồ

bông tuyết): Cơ sở dữ liệu được tổ chức dưới dạng chuẩn hoá, tuân theo luật

chuẩn hoá như đối với cơ sở dữ liệu quan hệ thông thường (dạng chuẩn 3).

o Ưu điểm:

Dữ liệu được nạp từ nguồn vào đích dễ dàng.

Dạng chuẩn cao giúp bảo đảm các ràng buộc toàn vẹn của dữ liệu,

tránh trùng lắp.

o Nhược điểm:

Việc kết các bảng để cho ra kết quả truy vấn mong muốn phức tạp

Đòi hỏi người dùng phải hiểu được cấu trúc tổ bên dưới của kho dữ

liệu.

Tốc độ truy vấn chậm do việc kết các bảng có kích thước lớn.

Phương pháp mô hình hoá đa chiều của Ralph Kimball (lược đồ hình

sao): Cơ sở dữ liệu được lưu trữ dưới dạng phi chuẩn hoá. Bao gồm bảng

dữ kiện (fact) chứa thông tin các giao tác và các bảng chiều (dimension)

đóng vai trò như là bảng tham chiếu lấy thông tin. Các bảng này đều được

lưu dưới dạng chuẩn thấp (dạng chuẩn 1 hoặc 2)

o Ưu điểm:

Truy vấn người dùng cuối dễ dàng được thực hiện mà không đòi hỏi

người dùng phải hiểu rõ về cấu trúc của kho dữ liệu.

20

Thiết kế hướng nghiệp vụ, là ánh xạ trực tiếp từ quy trình nghiệp vụ

của doanh nghiệp.

Tốc độ truy vấn cao.

o Nhược điểm:

Dữ liệu nguồn cần phải được phi chuẩn hoá (denormalized) và bảo

đảm ràng buộc toàn vẹn trong quá trình nạp dữ liệu vào kho.

Trùng lắp dữ liệu nhiều, khiến cho kích thước kho lớn (Trong điều

kiện công nghệ hiện nay, đây không hẳn là một trở ngại lớn!)

Xu hướng hiện tại, đa số các dự án trên kho dữ liệu được cài đặt dưới dạng mô

hình hoá đa chiều bằng lược đồ hình sao do hiệu suất hoạt động vượt trội của nó.

Các nhược điểm của mô hình dạng này không phải là trở ngại lớn.

Trong nội dung của luận văn này, chúng ta chỉ bàn đến các thiết kế dựa trên

lược đồ hình sao.

2.2. Lược đồ hình sao

Như đã nói ở trên, phương pháp mô hình hoá đa chiều với lược đồ hình sao

thể hiện những ưu điểm vượt trội của mình. Bởi vì kho dữ liệu được thiết kế cho

mục đích đọc nhiều hơn là ghi trên nó, đặc biệt, nó không phải là cơ sở dữ liệu

phục vụ giao tác (OLTP), việc tránh dư thừa dữ liệu là không cần thiết.

Hình 2.2-1: Lược đồ hình sao.

21

Lược đồ hình sao được gọi theo mô hình của nó. Như mô tả trong hình vẽ,

lược đồ hình sao bao gồm một bảng trung tâm gọi là bảng dữ kiện. Bảng này

tham chiếu đến các bảng xung quanh, gọi là bảng chiều.

2.2.1. Bảng chiều và bảng dữ kiện

Để hiểu một cách đơn giản cho khái niệm bảng chiều và bảng dữ kiện, ta

hãy xem xét ví dụ sau:

Hệ thống của trường ghi lại việc “Một sinh viên SV vào trang web Moodle

của khoa để xem thông tin của một môn học MH vào lúc 12h trưa ngày

06/06/2006, thời gian truy cập 60 giây.”

Ta xem mỗi lần sinh viên vào trang web môn học được xem như một giao

tác. Như vậy, hệ thống đã ghi nhận có một giao tác, liên quan đến các đối

tượng sau:

Sinh viên SV

Môn học MH,

12h trưa

Ngày 06/06/2006

Ở đây, ta có một ngữ cảnh liên quan đến 4 đối tượng trên, và một con số đo

thời gian 60 giây.

Các đối tượng tham gia vào giao tác, hay là ngữ cảnh của giao tác đó,

được gọi là chiều.

Con số thể hiện một độ đo của một giao tác gọi là dữ kiện của giao tác đó.

Ở đây, con số 60giây là dữ kiện của giao tác truy cập trang web trên. Ta có thể

vẽ một lược đồ hình sao như sau:

22

Hình 2.2.1-1: Ví dụ lược đồ hình sao

2.2.2. Các đặc trưng của lược đồ hình sao

Xem xét cấu trúc một lược đồ hình sao như sau:

Hình 2.2.2-1: Cấu trúc lược đồ hình sao

Tất cả các dòng trong bảng dữ kiện được lưu với độ mịn thấp nhất có thể.

Độ mịn là mức độ chi tiết của dữ liệu. Một dữ kiện được tính theo ngày

có độ mịn thấp hơn dữ kiện được tính theo giờ…

Độ mịn của dữ kiện được xác định bằng độ mịn của các chiều liên quan.

Tất cả các độ đo trong bảng dữ kiện có thể được cuộn lên (roll-up) hoặc

gom nhóm theo chiều. Chẳng hạn có thể tính doanh thu theo tháng, năm,

gom nhóm theo sản phẩm,…

2.3. Truy vấn trên lược đồ hình sao

(Cần bổ sung các so sánh truy vấn giữa lược đồ hình sao và lược đồ chuẩn

hoá)

2.4. Kiến trúc buýt

23

Để đưa ra thiết kế chính xác cho kho dữ liệu, người ta sử dụng ma trận kiến

buýt (bus matrix) (Ralph Kimball - The Data Warehouse Toolkit). Đây là một

bảng mô tả mối liên hệ giữa các nghiệp vụ với các đối tượng liên quan.

Hình 2.4-1: Ma trận kiến trúc buýt

Bảng trên đây mô tả mối liên hệ giữa các nghiệp vụ:

Các dòng: Thể hiện các nghiệp vụ

Các cột: Thể hiện các đối tượng

Các ô: Mô tả một đối tượng có liên quan đến nghiệp vụ đó hay không.

Bằng việc phân tích yêu cầu người dùng và đưa ra được ma trận kiến trúc

buýt, có thể dễ dàng xây dựng lược đồ hình sao cho kho dữ liệu trong dó:

Các dòng: Là các bảng dữ kiện.

Các cột: Là các bảng chiều.

Chú ý rằng các bảng dữ kiện khác nhau có thể cùng tham chiếu đến một chiều.

Các chiều này được gọi là các chiều chuẩn (conformed dimension)

2.5. Các nguyên tắc thiết kế

Có một số nguyên tắc chung khi thiết kế kho dữ liệu như sau:

2.5.1. Sử dụng khoá đại diện:

Thông thường, mỗi bảng đều có một khoá chính dùng định danh cho từng

dòng của nó. Khoá này có thể tạo bởi 1 hay nhiều cột. Trong dữ liệu nguồn,

khoá này là không thống nhất, và có thể mang nhiều kiểu khác nhau, cũng có

thể được tạo tự động bởi cơ sở dữ liệu nguồn. Chẳng hạn môn học TTH-294 là

một khoá chính. Trong kho dữ liệu, khoá này gọi là khoá tự nhiên. Vì những lí

24

do trên đây, khoá tự nhiên của dữ liệu nguồn không thể được sử dụng trong

một hệ thống chung của kho dữ liệu. Thay vào đó, người ta sử dụng khoá đại

diện, với các đặc điểm sau:

Chỉ bao gồm 1 cột: Đơn giản cho phép kết

Là số nguyên không âm: Tăng tốc cho việc đánh số chỉ mục và kết bảng

Tạo bởi gói ETL trong lúc nạp dữ liệu: Thống nhất giữa nhiều nguồn dữ

liệu.

2.5.2. Quy tắc đặt tên và kiểu

Để dễ hiểu cho người dùng cuối trong khi truy vấn, người ta sử dụng các

quy tắc sau:

Đặt tên bảng có chứa tiền tố (fct_ cho bảng dữ kiện, dim_ cho bảng chiều,

lkp_ cho bảng tìm kiếm…)

Tất cả các khoá của chiều được đặt tên theo tên bảng với hậu tố _key

Tất cả khoá của các chiều sử dụng số nguyên không âm nhỏ nhất có thể.

Tên của các cột phải có ý nghĩa, tránh viết tắt.

Sử dụng những tên chuẩn cho các cột theo dõi (xem mục 2.5.4)

2.5.3. Độ mịn và mức tổng hợp

Đối với việc lưu dữ liệu ở nhiều độ mịn, quy tắc duy nhất: Lưu với độ mịn

thấp nhất có thể.

Đối với việc tổng hợp dữ liệu: Tất cả các dữ kiện có nhu cầu truy xuất trong

khi truy vấn cần được tính toán sẵn ở mức thấp nhất. Tránh việc phải tính toán

lại trong quá trình truy vấn đầu cuối. Chẳng hạn: Truy vấn đầu cuối có mục

tiêu phải tính được thời gian truy cập của từng lượt truy cập, trong khi dữ liệu

nguồn chỉ lưu thời gian bắt đầu và kết thúc của một truy cập. Như vậy, cần

phải tính sẵn thời gian truy cập để lưu vào bảng dữ kiện thay vì lưu thời gian

bắt đầu và kết thúc riêng!

2.5.4. Ngày giờ

25

Thời gian là một đối tượng đặc biệt trong kho dữ liệu. Chi tiết việc nạp

chiều thời gian (bao gồm ngày và giờ) được mô tả trong Chương 3 – Tích hợp

dữ liệu. Một số chú ý sau:

Độ mịn được đặt ở mức thấp nhất có thể theo yêu cầu của người dùng.

Lưu riêng ngày và giờ trong ngày thành 2 chiều khác nhau.

Sử dụng giờ chuẩn quốc tế.

Sử dụng khoá thông minh cho ngày giờ, với định dạng: YYYYMMDD

hay HHMMSS. Ở đây ta không sử dụng khoá đại diện vì việc sử dụng

khoá chính cho chiều thời gian cho phép phân vùng (partitioning) dữ liệu

theo thời gian. Hơn nữa, chiều thời gian là chiều được nạp độc lập với

các chiều khác.

2.5.5. Khoá vô danh

Mỗi bảng chiều có một dòng với khoá đại diện là 0, các trường khác đặt giá

trị mặc định. Dòng này mô tả trạng thái nạp một dữ kiện vào bảng dữ kiện

nhưng không tìm thấy đối tượng tương ứng với dữ kiện đó trong chiều mà nó

tham chiếu tới.

Việc này giúp tránh dữ liệu NULL ở khoá ngoại bảng dữ kiện, đồng thời

mang ý nghĩa rõ ràng cho người dùng cuối rằng: “không tìm thấy đối tượng

liên quan đến ngữ cảnh đang có!”

26

Chương 3. Tích hợp dữ liệu

3.1. Khái niệm

Hệ thống tích hợp dữ liệu, hay còn gọi là hệ thống ETL (Extract-Load-

Transform) là một hệ thống được thiết kế để làm các nhiệm vụ sau:

Kết xuất dữ liệu từ các hệ thống nguồn.

Kiểm tra chất lượng dữ liệu và các tiêu chuẩn toàn vẹn.

Biến đổi dữ liệu để dữ liệu từ nhiều hệ thống có thể được sử dụng cùng

nhau.

Nạp dữ liệu vào một dạng trung gian cho phép các nhà phát triển cho thể

xây dựng ứng dụng và người dùng cuối có thể ra quyết định dựa trên dữ

liệu và ứng dụng đó.

3.2. Các bước tiến hành của quá trình tích hợp dữ liệu

3.2.1. Kết xuất dữ liệu:

Một công ty hoặc tổ chức thông thường cần nhiều hệ thống tin học để điều

khiển hoạt động của mình. Ví dụ: hệ thống quản lý bán hàng, quản lý kho, quản

lý nhân viên, quản lý sản phẩm... Những hệ thống này có thể không tương thích

về mặt logic hoặc vật lý, điều này gây ra những khó khăn cho việc tích hợp dữ

liệu. Những khó khăn đó có thể do các hệ thống khác nhau về:

Hệ quản trị CSDL.

Hệ điều hành.

Phần cứng.

Các giao thức truyền thông tin giữa nguồn dữ liệu và bên ngoài.

Như vậy, với những nguồn dữ liệu khác nhau, để tích hợp dữ liệu vào kho dữ

liệu, ta phải xây dựng các quy tắc ánh xạ dữ liệu từ dữ liệu nguồn đến kho dữ

liệu. Với kiến trúc và tính chất của nguồn dữ liệu khác nhau, đòi hỏi phải xây

dựng một bảng ánh xạ vật lý từ dữ liệu được lưu trữ ở nguồn đến kho dữ liệu.

27

Trước khi xây dựng một bảng ánh xạ vật lý, ta cần một bảng ánh xạ dữ liệu logic

từ các trường của nguồn dữ liệu đến các trường của bảng trong kho dữ liệu.

Cấu trúc của một bảng ánh xạ dữ liệu logic phải bao gồm các thông tin sau:

+ Tên bảng đích: tên vật lý của bảng trong kho dữ liệu.

+ Tên cột đích: tên cột trong bảng trong kho dữ liệu.

+ Loại bảng: xác định đó là bảng fact, bảng chiều hay bảng chiều con.

+ SCD: xác định loại chiều thay đổi chậm (Slowly Changing Dimension),

dùng để lưu lịch sử dữ liệu.

+ CSDL nguồn: tên CSDL phía nguồn.

+ Tên bảng nguồn: tên bảng phía nguồn.

+ Tên cột nguồn: tên cột trong bảng phía nguồn.

+ Biến đổi: cách xử lý logic đối với dữ liệu nguồn để đưa về cùng định dạng

với dữ liệu đích. Phép biến đổi này thường được viết bằng mã giả SQL.

28

Ví dụ về bảng ánh xạ dữ liệu logic:

Hình 1

Để có được một bảng ánh xạ dữ liệu logic như vậy, sau khi hoàn tất công đoạn

phân tích yêu cầu và thiết kế kho dữ liệu, ta phải tìm hiểu và nhận dạng các hệ

thống nguồn đáp ứng các yêu cầu dữ liệu của kho dữ liệu, phân tích cấu trúc của

hệ thống nguồn đó thông qua lược đồ CSDL, xác định các khóa, loại dữ liệu, mối

quan hệ giữa các bảng,... và phân tích chính bản thân dữ liệu để tìm hiểu các lỗi

tiềm tàng của dữ liệu và cách khắc phục. Ví dụ:

+ Y nghĩa và cách khắc phục đối với các trường dữ liệu null

29

+ Các trường ngày tháng không đúng định dạng chuẩn.

Sau khi hoàn tất bảng ánh xạ dữ liệu logic, ta sẽ xây dựng bảng ánh xạ dữ liệu

vật lý dựa trên kiến trúc, cách lưu trữ và cấu trúc của dữ liệu nguồn và dữ liệu

đích.

Trong phạm vi của khóa luận, nhóm chỉ tiến hành tìm hiểu trên các nguồn dữ

liệu khác nhau về cấu trúc và cách lưu trữ. Cụ thể là tích hợp dữ liệu trên nhiều

CSDL và tập tin khác nhau.

Trong quá trình tích hợp dữ liệu, việc lấy tất cả dữ liệu từ nguồn rất mất thời

gian và không cần thiết, do đó ta chỉ lấy những dữ liệu mới từ nguồn mà kho dữ

liệu chưa cập nhật hoặc những dữ liệu được thay đổi ở nguồn sau khi cập nhật

vào kho dữ liệu. Quá trình lấy dữ liệu như vậy được gọi là lắng nghe và kết xuất

dữ liệu thay đổi. Có nhiều phương pháp để nhận biết sự thay đổi ở dữ liệu nguồn

để cập nhật vào kho dữ liệu. Sau đây là các phương pháp thường được sử dụng:

+ Sử dụng cột kiểm tra (audit columns): được thêm vào cuối của mỗi bảng để

lưu dữ liệu về ngày giờ cập nhật hoặc điều chỉnh một dòng dữ liệu. Dữ liệu của

cột kiểm tra này thường được cập nhật bởi trigger hoặc ứng dụng người dùng

cuối. Rủi ro của phương pháp này là kho dữ liệu có thể cập nhật thiếu dữ liệu nếu

cột kiểm tra bị cập nhật sai.

+ Sử dụng log scraping và sniffing: sử dụng các bảng log của các giao tác làm

thay đổi dữ liệu để kiểm tra sự thay đổi.

+ Sử dụng các kết xuất thời gian: cũng giống như phương pháp sử dụng cột

kiểm tra, phuoưng pháp này sử dụng trường ngày tạo (hoặc cập nhật) để lấy dữ

liệu mới thêm vào theo chu ky. Ví dụ: lấy dữ liệu theo chu ky là 1 ngày thì lúc

lấy dữ liệu sẽ chọn hết tất cả những dòng dữ liệu có ngày tạo (hoặc ngày cập

nhật) là ngày trước ngày cập nhật một ngày. Rủi ro của phương pháp này là nếu

quá trình kết xuất dữ liệu bị lỗi vào một ngày nào đó thì dữ liệu ngày đó sẽ không

bào giờ được lấy lại nữa, do vậy cần có các cơ chế lấy lại dữ liệu trong những

trường hợp lỗi.

30

  + Kỹ thuật loại trừ: lưu một bản sao của phiên bản trước vào vùng lưu trữ

(staging area), khi kết xuất dữ liệu từ nguồn, ta chỉ tìm các dòng dữ liệu chưa có

trong vùng lưu trữ (dựa vào khóa) hoặc đã bị thay đổi so với dữ liệu trong vùng

lưu trữ.

3.2.2. Biến đổi dữ liệu:

Biến đổi dữ liệu thực chất là việc kiểm tra dữ liệu và đề ra các tiêu chuẩn cho

biết dữ liệu có thể được sử dụng trong kho dữ liệu hay không và đưa ra các giải

pháp biến đổi phù hợp.

Dữ liệu được đưa vào data warehouse phải là dữ liệu chính xác. Tính chính

xác được hiểu là dữ liệu phải có những tính chất sau:

+ Đúng đắn: dữ liệu phải mô tả trung thực đối tượng mà nó phản ánh. Ví dụ:

dữ liệu mô tả những căn nhà ở Tp.Hồ Chí Minh thì bắt buộc trong địa chỉ phải

chứa tên thành phố là Hồ Chí Minh.

+ Không mơ hồ: xác định rõ ý nghĩa của đối tượng được mô tả. Ví dụ: dữ liệu

về dân số ở quận Thủ Đức, Tp Hồ Chí Minh. Nếu trong địa chỉ chỉ xác định là

quận Thủ Đức, thì nó có thể là một địa danh khác ở đâu đó, điều này gây ra mơ

hồ, không rõ nghĩa.

+ Nhất quán: các giá trị và mô tả dữ liệu phải sử dụng một quy ước thống nhất

để biểu diễn. Ví dụ Tp Hồ Chí Minh, nếu quy ước viết tắt là Tp.HCM, thì trong

tất cả các thể hiện của CSDL Tp Hồ Chí Minh đều phải được biểu diễn là

Tp.HCM

+ Đầy đủ: thể hiện ở hai điểm: các trường dữ liệu không phải là null và các giá

trị suy biến phản ánh đầy đủ và chính xác.

Như vậy, vệc cần phải làm ở giai đoạn biến đổi dữ liệu là phải phát hiện dữ

liệu không chính xác để có bước xử lý thích hợp. Và để đánh giá chất lượng dữ

liệu, người ta dựa vào các độ đo chất lượng dữ liệu.

Yếu tố đầu tiên cần được xây dựng trong quá trình làm sạch dữ liệu là một

bảng fact gọi là bảng sự kiện lỗi (error event table) và các chiều của nó. Mỗi một

31

lỗi hay vấn đề phát sinh trong quá trình làm sạch dữ liệu được lưu thành một

dòng trong bảng fact.

Lược đồ của bảng sự kiện lỗi:

Hình 2

+ Chiều ngày tháng (date dimension) là chiều chuẩn đại diện cho trường ngày

tháng.

+ Chiều screen chứa thông tin về bước kiểm tra chất lượng dữ liệu (thông

thường việc kiểm tra tính đúng đắn của dữ liệu được chia ra làm nhiều bước, mỗi

bước được gọi là một screen). Mục đích của bảng này để mô tả screen đó làm gì

và được áp dụng khi nào, ngoài ra còn có các định nghĩa về các lỗi thường gặp,

cách ứng phó khi gặp lỗi (cho qua, từ chối dữ liệu hay dừng toàn bộ hệ thống để

phân tích lỗi)và độ nghiêm trọng của lỗi (severity score),...

+ Chiều khối (batch) chứa thông tin về khối dữ liệu và dòng (row) dữ liệu sinh

ra lỗi trong khối đó.

Người ta thường phân loại việc kiểm tra chất lượng dữ liệu thành 4 nhóm:

+ Kiểm tra theo cột thuộc tính: bao gồm các bước kiểm tra giá trị null trong

những cột yêu cầu giá trị, kiểm tra giá trị số nằm ngoài khoảng quy ước, độ dài

32

của trường quá dài hoặc quá ngắn (không mong đợi), kiểm tra giá trị cột ngoài

tập giá trị định sẵn hoặc không theo khuôn mẫu, kiểm tra lỗi chính tả.

  + Kiểm tra theo cấu trúc dữ liệu: kiểm tra các bảng dữ liệu có các khóa

chính và khóa tham chiếu đảm bảo ràng buộc tham chiếu.

+ Kiểm tra dữ liệu có đúng với các quy tắc nghiệp vụ hay giá trị của dữ liệu

suy biến có đúng hay không.

Sơ đồ mô tả việc kiểm tra dữ liệu qua các screen:

Hình 3

Để nâng cao tốc độ kiểm tra tính đúng đắn của dữ liệu, người ta tìm cách lập

lịch để các screen có thể chạy song song.

3.2.3. Nạp dữ liệu

33

Ở giai đoạn này, hệ thống ETL sẽ chuyển dữ liệu đã được kết xuất và xử lý

đến data warehouse. Dữ liệu đã được xử lý không chỉ là cơ sở dữ liệu mà còn là

các dạng dữ liệu khác như flat file, tài liệu XML, bảng tính,... Yêu cầu của giai

đoạn này thay đổi đối với mỗi hệ thống. Hệ thống có thể lựa chọn ghi đè dữ liệu

theo từng tuần hoặc theo giờ. Các hệ thống phức tạp hơn có thể lưu các lịch sử

dữ liệu thay đổi trong data warehouse.

Cấu trúc chiều: Tất cả các chiều cần được tổ chức vật lí sao cho có ít thành

phần nhất có thể. Người ta thường gắn thêm một thuộc tính không có ý nghĩa

thực tế để làm khoá đại diện (surrogate) bên cạnh khoá tự nhiên (natural key)

của nó.

Cấu trúc của một chiều thông thường như sau:

Bình thường, với mỗi khoá tự nhiên sẽ ứng với một khoá đại diện (1-1),

nhưng khi cần theo dõi dữ liệu mang tính lịch sử, mỗi khoá tự nhiên có thể ứng với

nhiều khoá đại diện (xem SCD Type 2 sẽ được đề cập bên dưới)

Các thuộc tính trong mỗi chiều thường không chứa số. Vì các thuộc tính

mang giá trị số hầu như chắc chắn là các fact. Trong khoảng 2% các trường hợp,

34

có thể rất khó đưa ra quyết định một trường chứa giá trị số thực ra có phải là fact

hay không (ví dụ giá sản phẩm). Trong trường hợp này, cần xác định:

Yêu cầu người dùng

Thuộc tính này có phải dạng SCD Type 2 hay không (nếu là SCD

Type 2, đây là fact)

Nạp các chiều phẳng và các chiều bông tuyết:

Nếu như bước làm sạch dữ liệu, dữ liệu vẫn được giữ ở dạng chuẩn cao

(dạng bông tuyết) để bảo đảm tính nhất quán, thì ở bước nạp dữ liệu, dữ liệu sẽ

được giảm dạng chuẩn (dạng phẳng) để giúp tăng tối đa tốc độ truy vấn và kết

xuất dữ liệu. Vì thế, người ta thường cố gắng tránh tổ chức các chiều dạng bông

tuyết.

Dữ liệu có phân cấp theo nhiều cách khác nhau đối với cùng một chiều

(chẳng hạn chiều sản phẩm phân cấp theo vùng địa lí hay theo vùng tiếp thị). Để

làm phẳng, mọi thuộc tính liên quan đến các cách phân cấp này đều được lưu

trong cùng một chiều.

Chiều thời gian (bao gồm cả ngày-tháng):

Đây là một chiều rất quan trọng vì được dùng hầu như trong mọi bảng fact.

Bởi vì tính chất quan trọng của nó, chiều thời gian thường được tổ chức đặc biệt

và không có nguồn nhập. Chiều này thường được dùng chung (dạng tham chiếu)

cho nhiều chiều khác.

Cấu trúc của chiều thời gian thường tổ chức như sau:

35

Có một số chú ý sau đối với chiều thời gian:

Chiều thời gian thường được phân vùng vật lý do tính chất lịch sử của

nó. Việc này làm tăng tốc độ cập nhật của dữ liệu.

Chiều ngày-tháng thường là một bảng vật lí cơ bản.

o Nếu cần chiều tháng, sẽ sử dụng khoảng chặn ngày đầu tháng-

cuối tháng để tổ chức.

36

o Nếu cần tính chi tiết ở mức giờ, phút, giây, để bảo đảm không

bị tràn, người ta thường sử dụng thêm một thuộc tính nhãn thời

gian.

Các chiều lớn: thường là các chiều được tạo thành từ nhiều nguồn, nhiều

hệ thống khác nhau, do nhu cầu cần phải dữ lại quá nhiều thông tin. Để giảm

kích thước các chiều lớn, người ta cần làm các bước sau:

Loại bỏ trùng lắp

Chuẩn hoá dữ liệu

Hợp nhất

Quá trình này được mô tả trong hình sau:

37

Vấn đề lựa chọn phân tách/hợp nhất chiều:

Nếu hai chiều có tương quan với nhau, người ta thường cố gắng tổ chức

thành hai chiều độc lập và sử dụng bảng fact để mô tả mối tương quan đó, thay

vì hợp nhất thành một chiều.

Nếu việc roll-up một chiều cho ra chiều còn lại (chẳng hạn product và

brand), thì nhất thiết không được tách thành hai chiều.

Các trường hợp còn lại, cần cân nhắc yêu cầu của người dùng.

Chiều nhập vai (role-playing dimension): Là chiều được gắn nhiều lần vào

cùng một bảng fact nhưng với các vai trò khác nhau. Ví dụ điển hình là chiều

thời gian. Đối với chiều nhập vai, người ta thường tổ chức một chiều. Các chiều

tham chiếu từ bảng fact là các view được tạo ra từ chiều chung đó.

38

Nạp các chiều suy biến:

Chiều suy biến là chiều dẫn xuất từ bảng fact mà không chứa thuộc tính nào

(còn gọi là chiều rỗng). Chiều suy biến thường chỉ chứa một khoá tự nhiên để

lưu vết các giao tác.

Nạp các chiều thay đổi chậm (Slowly Changing Dimension – SCD): Là chiều

có thuộc tính thay đổi giá trị rất chậm theo thời gian vì một lí do nào đó. Có 3

loại:

SCD loại 1 (ghi đè): đây là loại chiều không cần lưu lại lịch sử thay đổi.

Chỉ việc ghi đè lên bản ghi cũ.

SCD loại 2 (dữ liệu lịch sử hết hiệu lực): đây là loại chiều cần lưu lại lịch

sử. Thay vì ghi đè lên chiều cũ, người ta tạo ra một dòng mới với cùng

khoá tự nhiên nhưng khác khoá đại diện. Lúc đó, chỉ cần thay đổi tham

chiếu từ bảng fact.

SCD loại 3 (dữ liệu lịch sử còn hiệu lực): đây là trường hợp các giá trị

lịch sử vẫn còn hiệu lực sử dụng đồng thời với các giá trị mới. Thay vì

tạo thêm một dòng mới trong bảng chiều, người ta tạo thêm các cột mới

để lưu vết.

Thông thường, người ta tránh sử dụng loại 2 vì nó làm thay đổi cấu trúc của

hệ thống. Hơn nữa, việc xác định tính hiệu lực của dữ liệu thường được quy định

trong nghiệp vụ và được lưu như là một thuộc tính bình thường của chiều đó.

39

Nạp chiều đến sau và sửa lỗi dữ liệu:

Dữ liệu đến sau là những dữ liệu thay đổi sau khi đã xây dựng DW. Dữ liệu

này phân ra làm 2 loại:

Dữ liệu cần sửa đổi: do phát hiện sai sót (về thời gian) trong quá trình xây

dựng DW.

Dữ liệu cập nhật theo thời gian thực: do tính chất thời gian thực, dữ liệu

đang được truy vấn là dữ liệu cũ, và dữ liệu được cập nhật là dữ liệu mới

nhưng chưa được nạp vào hệ thống. (xem phần 4)

Các chiều đến sau cần được nạp vào DW bằng một hệ thống ETL độc lập và

cần được kiểm tra kĩ trên hệ thống thử nghiệm vì việc này ảnh hưởng sâu sắc

đến hệ thống.

Dữ liệu cần sửa đổi do phát hiện lỗi sai (về thời gian) được sửa theo 3 bước

sau:

Thêm một bản ghi mới với các thông tin cập nhật cho thuộc tính tương

ứng, ứng với mốc thời gian cần thay đổi.

Xác định từ mốc thời gian đó, tất cả các thay đổi xảy ra về sau nó và ghi

đè bằng các giá trị mới của thuộc tính

Cập nhật lại khoá ngoại cho bảng fact tất cả các bản ghi tham chiếu đến

các bản ghi đã thay đổi trong chiều đó.

Nạp chiều đa giá trị và bảng cầu nối:

Các chiều đa giá trị là các chiều có quan hệ n-n đến bảng fact. Trong trường

hợp này, cần phải tạo bảng cầu nối và bảng phân nhóm (để tránh quan hệ n-n

đến bảng fact).

Ví dụ:

40

Nạp các chiều phân cấp không đều (Ragged Hierarchies):

Các chiều phân cấp không đều là các chiều được phân cấp cha-con theo độ

sâu không xác định. Ví dụ: nhân viên-quản lí.

Để giải quyết dạng cây phân cấp này, có 2 giải pháp:

Đệ quy:

Đây là cách tổ chức trực quan, quen thuộc đối với CSDL quan hệ thông

thường.

Ưu điểm:

o Toàn bộ cây phân cấp được tổ chức chỉ trong một chiều.

o Việc quản lí (di chuyển, thay đổi) trong cây phân cấp được thực

hiện dễ dàng

Nhược điểm:

o Câu SQL truy vấn phức tạp và hiệu suất kém

o Chỉ có thể thể hiện được cây phân cấp mà mỗi con chỉ có 1 cha

o Nếu một chiều tồn tại nhiều cách phân cấp, không thể chuyển đổi

được giữa các cách phân cấp này

o Nếu chiều này là SCD loại 2, việc quản lí là rất khó khăn.

Bảng cầu nối phân cấp:

41

Ưu điểm:

o Dễ dàng truy vấn với SQL

o Dễ dàng tổng quát hoá cho những cây phức tạp

o Cho phép chuyển đổi giữa các dạng phân cấp.

o Dễ dàng thích ứng với SCD loại 2

Nhược điểm

o Cần biểu diễn mọi quan hệ cha-con (đa cấp) trong cây. Do đó số

bản ghi trong bảng cầu nối rất lớn.

o Không trực quan như kiểu đệ quy

o Khi áp dụng SCD loại 2 đối với chiều, cần cập nhật bảng cầu nối.

Nạp chiều văn bản đối với dạng fact văn bản:

Đôi lúc có những yêu cầu mà ở đó fact là dạng text. Chẳng hạn khi quy định

điểm số dạng A, B, C, D.

42

Đối với trường hợp này, để theo dõi các thay đổi để đưa ra giá trị fact liên

quan, người ta chọn hướng tiếp cận tương tự với SCD loại 3.

3.3. Các vấn đề gặp phải khi xây dựng hệ thống tích hợp dữ liệu và giải

pháp

3.3.1. Vấn đề cập nhật dữ liệu trong thời gian thực

Ngày nay, các quyết định trong kinh doanh cần được đưa ra nhanh, phù hợp

với sự thay đổi liên tục của thị trường, do đó các hệ thống hỗ trợ ra quyết định

cũng cần phải đáp ứng được sự thay đổi liên tục của dữ liệu, đó là lý do của việc

xuất hiện nhu cầu cập nhập dữ liệu trong thời gian thực của data warehouse.

Tuy nhiên, việc xây dựng hệ thống ETL để cập nhật dữ liệu theo thời gian

thực có một số khó khăn nhất định.

Khó khăn đầu tiên là từ việc chuyển đổi cách cập nhật dữ liệu như trước đây -

cập nhật dữ liệu theo lô (batch). Với cách cập nhật dữ liệu này, người ta lập lịch

để xử lý các dữ liệu mới theo thời gian cố định (theo ngày, theo tháng,...) và

người ta thường chọn thời gian thấp điểm của hệ thống để tiến hành việc cập nhật

(có thể là lúc nửa đêm, khi hệ thống có ít người sử dụng). Tuy nhiên, với việc cập

nhật dữ liệu theo thời gian thực, dữ liệu được cập nhật liên túc bất kể tình trạng

của hệ thống, điều này gây ra sự quá tải đối với hệ thống vào một số thời điểm

nhất định. Người ta đã đề xuất một số giải pháp cho vấn đề này như sau:

+ Cách 1: đây là cách đơn giản nhất, thay vì cập nhật dữ liệu theo thời gian

thực, ta điều chỉnh tần suất cập nhật dữ liệu. Ví dụ trước đây là 1 lần một tuần,

bây giờ đổi thành 1 lần một ngày, hoặc 3 lần một ngày.

43

+ Cách 2: cập nhật từng phần nhỏ. Bất kể khi nào phát sinh sự kiện chỉnh sửa

hoặc thêm các trường vào dữ liệu giao tác, ta đều tiến hành song song việc cập

nhật dữ liệu tương ứng vào các bảng của data warehouse. Tuy nhiên, điều này

gây ra nhiều vấn đề về giao tác (transaction) khi dữ liệu quá lớn. Với mỗi giao

tác sẽ phải tiến hành hai thao tác cập nhật dữ liệu thay vì chỉ một như trước đây,

và khi dữ liệu quá lớn, sẽ phải mất thêm thời gian chờ.

+ Cách 3: cập nhật từng phần nhỏ và xoay vòng. Cách giải quyết này có thể

giải quyết vấn đề dữ liệu lớn trong data warehouse. Thay vì thêm hoặc sửa dữ

liệu trực tiếp trong data warehouse, ta tạo các bảng fact có cùng cấu trúc như

trong data warehouse nhưng chỉ lưu dữ liệu trong ngày hoặc giờ hiện tại (không

lưu dữ liệu lịch sử), Sau một chu ky sẽ tiến hành cập nhật dữ liệu này vào các

bảng fact trong data warehouse.

+ Cách 4: lưu dữ liệu được cập nhật trong thời gian thực vào vùng đệm

(cache), sau một chu ky định sẵn sẽ tiến hành cập nhật vào data warehouse. Mỗi

khi có một truy vấn trên data warehouse, hệ thống sẽ truy vấn đồng thời trên các

bảng fact và trong cả vùng đệm.

Vấn đề về mô hình hóa dữ liệu: đối với các dữ liệu tổng hợp. Ví dụ dữ liệu

tổng hợp theo chiều thời gian, thì những dữ liệu này có thể bị bất đồng bộ hóa

với dữ liệu được cập nhật trong thời gian thực. Thật ra đây cũng không hẳn là

vấn đề, bởi vì về bản chất dữ liệu bình thường và dữ liệu theo thời gian thực là

giống nhau, vấn đề là ở chỗ một số ứng dụng người dùng cuối sử dụng kỹ thuật

catch và cho rằng dữ liệu sẽ được cập nhật sau một khoảng thời gian nào đó đối

với kỹ thuật cũ, cho nên chỉ cần lưu ý vấn đề này là được.

3.3.2. Vấn đề về không nhất quán dữ liệu khi thực hiện truy vấn.

44

Ví dụ:

                Hình 4

Đây là một truy vấn gồm nhiều câu lệnh SQL, mục địch là để tính toán số tiền

bán ra của mỗi loại hàng hóa và phần trăm của số tiền đó trên tổng số doanh thu.

Câu truy vấn này thực hiện như sau: tạo 2 bảng tạm TEMP1, và TEMP2, đưa

dữ liệu về số lượng tiền của mỗi loại hàng hóa vào bàng TEMP1, đưa tổng số

tiền bán được vào bảng TEMP2, sau đó sẽ đưa ra bảng tổng kết như khung hình

bên phải.

Vấn đề ở đây là nếu sau khi thực hiện việc đưa dữ liệu vào bảng TEMP1 và

chưa kịp dưa dữ liệu vào bảng TEMP2 thì xảy ra hiện tượng không đồng nhất dữ

liệu, điều này có nghĩa là tổng số phần trăm bên khung nhìn bên phải sẽ không

bằng 100%.

Các giải pháp cho vấn đề này được đề xuất như sau:

+ Cách 1:sử dụng cách tiếp cận “gần thời gian thực” (near real-time): thực

hiện việc cập nhật dữ liệu trong một chu ky nhất định, và không cho phép việc

thực hiện truy vấn trong thời gian cập nhật dữ liệu.

45

+ Cách 2: tách dữ liệu được tổng hợp trong thời gian thực và dữ liệu lịch sử và

lưu trong vùng nhớ cache, như vậy sẽ tránh được trường hợp dữ liệu không nhất

quán. Khi thực hiện truy vấn, ta sẽ thực hiện truy vấn đồng thời trên cả 2 dữ liệu.

Cảnh báo thời gian thực: các hệ thống cảnh báo được sử dụng trong data

warehouse chủ yếu để gửi các báo cáo đến người dùng sau khi load dữ liệu trong

mỗi chu ky. Tuy nhiên đối với các hệ thống data warehouse hoạt động trong thời

gian thực, hệ thống cảnh báo được sử dụng để thông báo khi mà điều kiện đặt ra

được đáp ứng. Các giải pháp đặt ra cho vấn đề thông báo theo thời gian thực:

+ Lập lịch theo vòng n phút (n-Minute Cycle Schedule): chú ý rằng cần phải

xác định ngưỡng thấp nhất của vòng lặp, vì ở một giới hạn nào đó, có thể xảy ra

một số vấn đề về khả năng chịu tải của hệ thống hoặc lần cảnh báo sau bắt đầu

trước khi lần cảnh báo trước kết thúc, điều này gây ra trùng cảnh báo.

+ Thông báo bằng cách theo dõi và chặn (trigger) theo thời gian thực: đặt các

chặn (trigger) để kiểm tra mỗi khi có sự thay đổi dữ liệu để cảnh báo. Về phương

pháp này, cần chú ý về giới hạn của phần cứng và bộ nhớ để đáp ứng các xử lý

liên tục.

46

Chương 4. Phần mềm tích hợp dữ liệu mã nguồn mở Kettle

4.1. Giới thiệu tổng quan:

4.1.1. Giới thiệu:

Kettle là phần mềm mã nguồn mở dùng để xây dựng các hệ thống tích hợp dữ

liệu. Kettle bao gồm nhân tích hợp dữ liệu và giao diện đồ họa cho phép người

dùng định nghĩa các biến đổi (transformation) và các công việc (job – bao gồm

các bước biến đổi được tiến hành tuần tự hoặc song song).

Kettle bao gồm các công cụ và tiện ích sau:

- Spoon: IDE đồ họa cho việc tạo các biến đổi (transformation) và các công

việc (job) cho Kettle.

- Kitchen: công cụ command-line để chạy các công việc (job) của Kettle.

- Pan: công cụ command-line để chạy các biến đổi (transformation) của

Kettle.

- Carte: đóng vai trò làm máy chủ khi chạy các biến đổi và các công việc của

Kettle trên một máy khác.

4.1.2. Một số khái niệm trong Kettle:

- Bước (step): là một hoạt động cụ thể trên một hoặc nhiều luồng dữ liệu. Ví

dụ: Access Input dùng để lấy dữ liệu từ tập tin access, Sort rows dùng để

sắp xếp các dòng trong luồng dữ liệu vào, value mapper dùng để ánh xạ dữ

liệu,… Trong mỗi bước ta có thể định nghĩa các thuộc tính để xử lý dữ liệu

đi vào bước đó, các thuộc tính này được gọi là siêu dữ liệu (metadata)

- Các bước có thể được nối với nhau qua các cầu nối gọi là các hop. Các hop

này được xem như là những “đường ống” để chuyển dữ liệu từ bước (step)

này qua bước khác.

- Biến đổi (transform): bao gồm các bước, siêu dữ liệu tương ứng với từng

bước và các hop.

47

- Công việc (job): bao gồm một hoặc nhiều biến đổi. Ví dụ: khi nạp dữ liệu

có lược đồ hình sao, việc đầu tiên ta cần xây dựng một biến đổi để kết xuất

dữ liệu từ hệ thống nguồn, xây dựng các biến đổi để nạp từng bảng chiều

và bảng fact. Công việc (job) được dùng để đặt các biến đổi đó lại với nhau

theo một thứ tự thích hợp để có thể thực hiện việc nạp dữ liệu.

4.1.3. Một số bước thường dùng và các chú ý trong Kettle:

4.1.3.1. Table input:

- Chức năng: lấy dữ liệu từ một cơ sở dữ liệu sử dụng một kết nối đã được

cấu hình và câu lệnh SQL.

- Cấu hình:

Cấu hình Mô tảStep name Tên bước, tên của mỗi bước là duy

nhất trong mỗi biến đổiConnection Các cấu hình kết nối CSDL để đọc

dữ liệuSQL Câu lệnh SQL dùng để đọc dữ liệu

48

từ kết nối đã được cấu hình ở trênEnable lazy convertion Khi được kích hoạt, quá trình lấy

dữ liệu sẽ tránh những thao tác ép kiểu không cần thiết để tăng tốc độ.

Replace variables in script? Khi được kích hoạt, quá trình lấy dữ liệu sẽ đặt các tham số từ bước trước đó vào câu lệnh SQL tại những dấu “?” lần lượt theo thứ tự của tham số.

Insert data from step Khi được kích hoạt, câu lệnh SQL sẽ được phép sử dụng dữ liệu từ bước xác định trước để lấy dữ liệu từ kết nối đã được cấu hình sẵn.

Execute for each row? Khi được kích hoạt, quá trình lấy dữ liệu được tiến hành cho mỗi dòng dữ liệu được nạp vào từ bước trước đó

Limit size Giới hạn số dòng dữ liệu được đọc từ CSDL, 0 có nghĩa là đọc tất cả các dòng.

4.1.3.2. Modified java script:

- Chức năng: bước này cho phép ta sử dụng cú pháp và các hàm javascript

để biến đổi dữ liệu.

49

- Cấu hình:

Compatibility mode? Khi được kích hoạt, javascript sẽ sử dụng engine phiên bản 2.5; nếu không thì sẽ sử dụng phiên bảng 3.0

- Chú ý: ở bước này, tên các trường dữ liệu của bước trước được xem như

các hằng số, các biến được định nghĩa mới có thể được thêm vào dữ liệu

đầu ra của bước. Hàm javascript được chạy mỗi khi có một dòng (record)

đi vào bước này.

4.1.3.3. Filter rows:

- Chức năng: lọc dữ liệu dựa trên điều kiện

- Cấu hình:

Cấu hình Mô tảSend ‘true’ data to step Dữ liệu đúng với điều kiện được

chuyển đến bước này.Send ‘false’ data to step Dữ liệu không đúng với điều kiện

được chuyển đến bước này.- Chú ý: các bước mà dữ liệu “đúng” và “sai” được chuyển đến phải được

nối với bước hiện tại thông qua các hop.

4.1.3.4. Dimension lookup/ update:

50

- Chức năng: dùng để cập nhật dữ liệu cho các bảng có chiều thay đổi chậm

loại 1 hoặc loại 2.

- Cấu hình:

Cấu hình Mô tảTechnical key field Khóa chính (primary key) của bảng

chiều.Version field Đánh dấu phiên bảng của dòng dữ

liệu trong chiều thay đổi chậmDate range start field Ngày bắt đầu có hiệu lực của dòng

dữ liệuTable daterange end Ngày cuối cùng có hiệu lực của

dòng dữ liệuKeys Khóa tự nhiên được sử dụng trong

dữ liệu nguồn51

Field Chứa thông tin của chiều

- Chú ý:

+ Khi thực thi, trước hết bước này sẽ tìm dữ liệu trong bảng chiều

tương ứng với các khóa được xác định trong mục cấu hình “Key fields”.

Nếu không tìm thấy dữ liệu yêu cầu, dữ liệu mới sẽ được thêm (insert) vào

bảng chiều. Ngược lại, dữ liệu tìm thấy sẽ được so sánh với các dữ liệu đưa

vào và tiến hành cập nhật (update) hay thêm (insert) tùy thuộc vào loại

chiều thay đổi chậm được xác định trên mỗi trường dữ liệu.

+ Việc cấu hình chiều thay đổi chậm được tiến hành ở mục “Lookup/

Update fields”, với các trường có chiều thay đổi chậm loại một, ở mục

“Type of dimension update” sẽ được thiết lập giá trị là “Update”. Giá trị

“Insert” được thiết lập cho các trường có chiều thay đổi chậm loại 2. Các

giá trị còn lại như “Last version”, “Date of last insert”, … để xác định các

thông tin kèm theo chiều thay đối chậm.

4.1.3.5. Combination lookup/ update:

- Chức năng: sử dụng để tìm hoặc sinh khóa chính với các trường tìm kiếm

tương ứng. Trước tiên, bước này sẽ tìm kiếm dữ liệu trong bảng được xác

định thông qua các trường “Connection” và “Target table” với các thông

tin khóa tìm kiếm ứng với thông tin được đưa vào. Nếu tìm thấy sẽ trả về

khóa chính tương ứng, nếu không sẽ phát sinh khóa chính mới và thêm

(insert) một dòng dữ liệu vào bảng, nội dung những dòng dữ liệu này chỉ

52

bao gồm thông tin khóa và các trường dữ liệu được sử dụng để tìm kiếm ở

trên, các trường còn lại có giá trị null hoặc giá trị mặc định của trường đó.

- Cấu hình:

Cấu hình Mô tảDimension field Trường tìm kiếm trong bảng chiềuField in stream Trường dữ liệu tương ứng với

trường tìm kiếm trong bảng chiều

- Chú ý:

+ Việc kết hợp nhiều trường để tìm kiếm có thể làm tốc độ xử lý chậm

lại. Trong trường hợp này, ta có thể đánh dấu tùy chọn “Use hashcode” để

thêm giá trị băm tương ứng vào bảng, như vậy quá trình tìm kiếm trên

nhiều chiều thực chất chỉ còn tìm kiếm trên giá trị băm.

53

+ Do ở bước này chỉ thêm mới giá trị khóa chính và các giá trị tìm

kiếm, nên thường được đi kèm với bước “Update” đằng sau để cập nhật

các trường không phải trường tìm kiếm.

4.1.3.6. Update:

- Chức năng: tìm kiếm các dòng trong bảng sử dụng một hoặc nhiều khóa

tìm kiếm kết hợp. Nếu dòng dữ liệu được tìm thấy, dữ liệu sẽ được so sánh

với các giá trị tương ứng ở trường cập nhật, nếu dữ liệu khác nhau sẽ tiến

hành cập nhật.

- Cấu hình:

54

Cập nhật Mô tảThe key(s) to look up the value(s) Các khóa được sử dụng để tìm kiếmUpdate fields Các trường dữ liệu sẽ được so sánh

với dữ liệu đưa vào và tiến hành cập nhật nếu có giá trị khác nhau.

55

Chương 5. Xây dựng kho dữ liệu phục vụ các hệ thống học tập trực tuyến

5.1. Mô tả yêu cầu ứng dụng

Yêu cầu của ứng dụng thử nghiệm là xây dựng một hệ thống tích hợp dữ liệu

từ nhiều nguồn vào kho dữ liệu phục vụ cho nhu cầu phân tích dữ liệu của các hệ

thống học tập trực tuyến. Hệ thống cho phép mở rộng để đưa dữ liệu từ các

nguồn chưa được hỗ trợ vào kho dữ liệu.

5.1.1. Các yêu cầu phân tích dữ liệu đối với các hệ thống học tập trực

tuyến:

Có 2 nhu cầu khi phân tích hệ thống giảng dạy trực tuyến:

- Xem xét hiệu quả của hệ thống đối với người học:

+ Phân tích mối quan hệ của thời gian sinh viên tham gia hệ thống đối với

kết quả học tập trong từng môn học (kết quả được đánh giá theo từng học

ky).

+ Phân tích mối quan hệ của tần suất sinh viên tham gia hệ thống đối với

kết quả học tập trong từng môn học .

+ Phân tích mối quan hệ của thời gian giáo viên tham gia hệ thống đối với

kết quả học tập của sinh viên trong môn học đó.

+ Phân tích mối quan hệ của tần suất giáo viên tham gia hệ thống đối với

kết quả học tập của sinh viên trong môn học đó.

+ Phân tích (thời gian, tần suất, tỉ lệ) các hoạt động mà sinh viên tham gia

trong hệ thống và sự liên quan đến kết quả học tập.

- Xem xét hiệu năng sử dụng của hệ thống để phân phối lại các bài học vào

các thời điểm thích hợp.

+ Phân tích thời lượng truy cập vào hệ thống theo thời gian.

+ Phân tích ty lệ truy cập vào các chức năng của hệ thống theo thời gian.

5.1.2. Ma trận kiến trúc buýt:

Ma trận mô tả các nghiệp vụ và ngữ cảnh liên quan:

56

Ngữ cảnhThời

gianNgười

dùngHọc

phầnChức

năngN

ghiệ

p vụ

Khảo sát thời gian sử dụng hệ thống x x x x

Khảo sát tần suất truy cập hệ thống x x x x

Khảo sát kết quả học tập x x

5.2. Kiến trúc của ứng dụng

Ứng dụng thử nghiệm xây dựng dựa trên kiến trúc NDS+DDS, với mô hình

như sau:

Với yêu cầu cho phép mở rộng để đưa dữ liệu từ các nguồn khác nhau vào kho

dữ liệu, hệ thống tích hợp dữ liệu được thiết kế để việc mở rộng là thuận tiện

nhất. Ở đây CSDL chuẩn hóa, kho dữ liệu và quá trình tích hợp dữ liệu từ CSDL

chuẩn hóa vào kho dữ liệu là chung cho tất cả các loại nguồn dữ liệu. Với một

loại nguồn dữ liệu sẽ có cấu trúc vùng xử lý khác nhau, quá trình tích hợp dữ liệu

từ dữ liệu nguồn vào vùng xử lý và từ vùng xử lý vào CSDL chuẩn hóa khác

nhau.

5.3. Thiết kế kho dữ liệu

57

5.3.1. Vùng xử lí

5.3.1.1. Moodle

Hệ thống Moodle có khoảng 200 bảng dữ liệu. Tuy nhiên để lấy dữ liệu

cho data warehouse được thiết kế ở trên ta chỉ sử dụng các bảng và các

trường sau:

Hình 5.3.1.1-1. Vùng xử lí cho dữ liệu nạp từ Moodle

Ở đây có một số chú ý đối với dữ liệu trong vùng xử lí của Moodle:

Trường full_path_name của bảng stg_course_categories là

khoá tự nhiên sinh ra trong quá trình rút trích dữ liệu. Lí do là

dữ liệu nguồn không có khoá tự nhiên khác với định danh hệ

thống. Việc tạo ra khoá tự nhiên nhằm tránh xung đột về dữ

liệu.

Vùng xử lí chỉ bao gồm khoá tự nhiên và các thuộc tính cần

thiết, không bao gồm khoá chính, khoá ngoại hay chỉ mục,

nhằm tăng tốc quá trình sao chép dữ liệu từ nguồn.

58

Những bảng có trường last_update là những bảng không chứa

thông tin lịch sử thay đổi của nguồn. last_update là trường do

hệ thống ETL tạo ra trong quá trình rút trích nhằm ghi nhận các

thay đổi này. Các bảng khác sử dụng trường timemodified

trong dữ liệu nguồn để ghi nhận thay đổi từ nguồn.

5.3.1.2. Kết quả học tập

Dữ liệu về kết quả học tập, học ky, năm học không có trong moodle. Cho

nên nếu muốn phân tích các vấn đề liên quan tới các dữ liệu này, người

dùng cần phải nhập dữ liệu bằng file excel có cấu trúc như sau (do ứng

dụng bao đóng quy định):

Dữ liệu kết quả học tập: file excel với cột 1 chứa mã khóa học (có header

là CourseID), cột 2 là mã sinh viên (có header là StudentID), cột 3 là điểm

(có header là Value)

Hình 5.3.1.2-1. Cấu trúc tập tin chứa kết quả học tập

5.3.1.3. Dữ liệu học ky, năm học

File excel với cột 1 chứa số thứ tự học ky trong năm học (có header là

TermNumber), cột 2 chứa tên học ky (có header là TermName), cột 3 chứa

năm bắt đầu năm học (có header là AcademicYear), cột 4 chứa tên năm học

(có header là AcademicYearName), cột 5 và cột 6 chứa ngày bắt đầu và

ngày kết thúc học ky (có header lần lượt là BeginDate và EndDate). Ngày

tháng có định dạng năm/tháng/ngày (YYYY/mm/DD)

59

Hình 5.3.1.3-1. Cấu trúc tập tin chứa thông tin các học kì, năm học

5.3.2. Cơ sở dữ liệu chuẩn hoá

5.3.2.1. Lược đồ

Cơ sở dữ liệu chuẩn hoá được tổ chức dưới dạng chuẩn 3, như hình dưới

đây:

60

5.3.2.2. Các diễn giải liên quan đến thiết kế

Các thuộc tính category_full_path và parent_category_full_path là các

khoá tự tạo trong quá trình trích xuất dữ liệu từ nguồn đưa vào vùng xử

lí như đã trình bày bên trên. (Xem mục 5.3.1.1. Moodle)

61

Các thuộc tính last_update của các bảng là thời gian cập nhật dòng dữ

liệu lần cuối cùng từ nguồn. Đối với các bảng mà dữ liệu nguồn có lưu

lịch sử thay đổi, last_update là giá trị thời gian của cột tương ứng trong

bảng đó. Đối với các bảng mà dữ liệu nguồn không lưu lịch sử thay

đổi, sử dụng thời điểm rút trích dữ liệu cho thuộc tính last_update.

5.3.2.3. Đặc tả cơ sở dữ liệu

Nds_modules: lưu trữ thông tin về các mô đun trong hệ thống

Tên thuộc tính Kiểu giá trị Ý nghĩa

module_name varchar Tên mô đun website hệ thống nguồn (khoa

chinh)

module_description text Mô tả mô đun

last_update datetime Thời điểm cập nhật cuối cùng

Nds_categories: lưu trữ thông tin về nhóm các khóa học

Tên thuộc tính Kiểu giá trị Ý nghĩa

category_full_path varchar Khoá tự nhiên của nhóm khoá

học, tạo ra bằng cách ghép nối tên

các nhóm khoá học từ nó lên đến

nút gốc trên cây phân cấp, ngăn

cách bằng dấu ‘;’

parent_category_full_path varchar Khoá tự nhiên của nhóm môn học cha.

category_name varchar Tên nhóm khóa học

category_description text Mô tả nhóm khóa học

depth tinyint Độ sâu của nhóm khoá học trên

cây phân cấp.

last_update datetime Thời điểm cập nhật cuối cùng

Nds_courses: lưu trữ thông tin về khóa học

62

Tên thuộc tính Kiểu giá trị Ý nghĩa

course_code varchar Mã khóa học

category_full_name varchar Nhom khoá học. Khoá ngoại tham chiếu

đến bang nds_categories

term_number tinyint Thứ tự học ky

year_number int Năm học

course_name varchar Tên khóa học

course_description text Mô tả khóa học

course_start_date datetime Ngày bắt đầu khóa học

course_created_date datetime Ngày khởi tạo khóa học trong hệ

thống

last_update datetime Thời điểm cập nhật cuối cùng

Nds_terms: lưu trữ thông tin về học ky

Tên thuộc tính Kiểu giá trị Ý nghĩa

term_number int Thứ tự học ky trong năm học

year_number tinyint Năm học, tham chiếu đến bảng

nds_academic_years

term_name varchar Tên học ky

begin_date date Ngày bắt đầu học ky

end_date date Ngày kết thúc học ky

last_update datetime Thời điểm cập nhật cuối cùng

Nds_academic_years:

Tên thuộc tính Kiểu giá trị Ý nghĩa

year_number int Năm học

academic_year_name varchar Tên năm học

last_update datetime Thời điểm cập nhật cuối cùng

63

Nds_role: lưu trữ thông tin vai trò người dùng trong hệ thống

Tên thuộc tính Kiểu giá trị Ý nghĩa

role_name varchar Tên vai trò

role_description text Mô tả vai trò

last_update datetime Thời điểm cập nhật cuối cùng

Nds_users: lưu trữ thông tin người dùng

Tên thuộc tính Kiểu giá trị Ý nghĩa

user_name varchar Tên đăng nhập của người dùng

description text Mô tả người dùng

first_name varchar Họ người dùng

last_name varchar Tên thật người dùng

email varchar Email người dùng

phone_1 varchar Số điện thoại người dùng

phone_2 varchar Số điện thoại người dùng

institution varchar Tên cơ quan

department varchar Tên phòng ban

address varchar Địa chỉ người dùng

city varchar Thành phố người dùng đang ở

last_update timestamp Thời điểm sửa đổi cuối cùng

Nds_actions:lưu trữ thông tin các thao tác trong hệ thống

Tên thuộc tính Kiểu giá trị Ý nghĩa

action_name varchar Tên thao tác

action_description text Mô tả thao tác

last_update datetime Thời điếm cập nhật cuối cùng

Nds_logs: lưu trữ thông tin log của hệ thống

Tên thuộc tính Kiểu giá trị Ý nghĩa64

course_code varchar Mã khóa học, tham chiếu đến

bảng nds_courses

user_name varchar Mã người dùng, tham chiếu đến

bảng nds_users

module_name varchar Tên mô đun, tham chiếu đến bảng

nds_modules

action_name varchar Tên hoạt động, tham chiếu đến

bảng nds_actions

access_time datetime Thời điểm truy cập vào hệ thống

last_update datetime Thời điểm cập nhật cuối cùng

Nds_results: lưu trữ thông tin kết quả học tập

Tên thuộc tính Kiểu giá trị Ý nghĩa

course_code varchar Ma khoa học, tham chiếu đến bang

nds_courses

user_name varchar Tên người dùng, tham chiếu đến

bảng nds_users

grade float Điếm số của người dùng với khóa

học tương ứng

last_update datetime Thời điểm cập nhật cuối cùng

Nds_role_assignments: lưu thông tin về vai trò của người dùng ở một

khóa học trong hệ thống.

Tên thuộc tính Kiểu giá trị Ý nghĩa

user_name varchar Tên người dùng, tham chiếu đến

bảng nds_users

course_code varchar Mã khóa học, tham chiếu đến

bảng nds_courses

65

role_name varchar Tên vai trò, tham chiếu đến bảng

nds_roles

last_update datetime Thời điểm cập nhật cuối cùng

5.3.3. Kho dữ liệu đầu cuối

5.3.3.1. Lược đồ cơ sở dữ liệu

66

5.3.3.1. Các diễn giải liên quan đến thiết kế

67

Bảng category_bridge được tạo ra nhằm khử truy vấn đệ quy trên

nhóm khoá học. Đây là cây phân cấp không giới hạn độ sâu.

Chẳng hạn:

Có cây phân cấp đệ quy không giới hạn độ sâu như sau:

Hình 5.3.3.1-1. Cây phân cấp không giới hạn độ sâu.

Bảng cầu nối được tạo ra có nội dung như sau:

Hình 5.3.3.1-2. Bảng cầu nối được tạo ra

Ở đây, mỗi dòng trong bảng cầu nối mô tả một quan hệ cha con.

Mỗi dòng cho biết các thông tin sau:

o manager_key: khoá đại diện của cha

o employee_key: khoá đại diện của con

o nest_level: độ sâu từ cha đến con.

o is_top/is_bottom: cho biết con có phải là nút gốc/nút lá của

cây hay không.

Bảng dim_role_group và role_group_bridge được tạo ra để giải

quyết tình trạng dữ kiện đa trị (multivalued fact). Ở đây, mỗi một 68

người dùng ghé thăm một trang môn học nào đó, người dùng đó có

thể đóng một hoặc nhiều vai trò (role) trong. Chẳng hạn một người

có thể vừa là sinh viên, vừa là trưởng nhóm.

Thuộc tính role_count cho biết số lượng vai trò trong nhóm đó.

Thuộc tính weighting_factor là trọng số, xác định mức độ tham gia

của một vai trò trong một nhóm vai trò nào đó. Thuộc tính này

nhằm tránh tình trạng thống kê kép. Được tính theo công thức sau:

weighting_factor = 1 / role_count

5.3.3.2. Đặc tả cơ sở dữ liệu

Các bảng chiều:

dim_date: chiều ngày tháng, sử dụng đơn vị học ky, năm học

Tên thuộc tính Kiểu giá trị Ý nghĩa

date_key Int Khoá chính (Khoá đại diện)

date_alternate_key date Ngày tháng đầy đủ

day_number_of_week tinyint Thứ tự ngày trong tuần

day_name_of_week varchar Tên ngày trong tuần

day_number_of_month tinyint Thứ tự ngày trong tháng

day_number_of_term smallint Thứ tự ngày trong học ky

week_number_of_term tinyint Thứ tự tuần trong học ky

month_number_of_year tinyint Thứ tự tháng trong năm

month_name_of_year varchar Tên tháng

year_number tinyint Năm

term_name varchar Tên học kì

term_number smallint Thứ tự học ky trong năm

academic_year_name varchar Tên năm học (vd: 2007-2008)

academic_year smallint Năm bắt đầu của năm học

is_weekend tinyint Có phải là ngày cuối tuần hay không?

is_holiday tinyint Có phải là ngày nghỉ hay không?

69

last_update timestamp Thời điểm sửa đổi cuối cùng

dim_time: chiều thời gian

Tên thuộc tính Kiểu giá trị Ý nghĩa

time_key int Khoá chính (Khoá đại diện)

time_alternate_key time Thời gian đầy đủ

hour tinyint Giờ

minute tinyint Phút

second tinyint Giây

dim_user: Chiều người dùng

Tên thuộc tính Kiểu giá trị Ý nghĩa

user_key int Khoá chính (Khoá đại diện)

user_business_key varchar

Khóa tự nhiên của người dùng

trong CSDL chuẩn hóa

user_name varchar Tên đăng nhập của người dùng

user_description text Mô tả người dùng

first_name varchar Họ người dùng

last_name varchar Tên thật người dùng

email varchar Email người dùng

phone_1 varchar Số điện thoại người dùng

phone_2 varchar Số điện thoại người dùng

institution varchar Tên cơ quan

department varchar Tên phòng ban

address varchar Địa chỉ người dùng

city varchar Thành phố người dùng đang ở

last_update timestamp Thời điểm sửa đổi cuối cùng

dim_role: chiều vai trò người dùng70

Tên thuộc tính Kiểu giá trị Ý nghĩa

role_key int Khoá chính (Khoá đại diện)

role_business_key varchar Khóa tự nhiên của vai trò trong

CSDL chuẩn hóa

role_name varchar Tên vai trò

role_description text Mô tả vai trò

valid_from date Ngày bắt đầu có hiệu lực của vai

trò (ở trường hiện tại), dùng để

quản lý chiều thay đổi chậm loại 2

valid_to date Ngày kết thúc có hiệu lực của vai

trò (ở trường hiện tại), dùng để

quản lý chiều thay đổi chậm loại 2

version tinyint Phiên bản, dùng để quản lý chiều

thay đổi chậm loại 2

is_current varchar Vai trò ở trường hiện tại có đang

được sử dụng hay không, dùng để

quản lý chiều thay đổi chậm loại 2

last_update datetime Thời điểm sửa đổi cuối cùng

dim_course: chiều học phần

Tên thuộc tính Kiểu giá trị Ý nghĩa

course_key int Khoá chính (Khoá đại diện)

course_business_key varchar Khóa tự nhiên của khóa học trong

CSDL chuẩn hóa

course_code varchar Mã khóa học

course_name varchar Tên khóa học

course_description text Mô tả khóa học

course_start_date datetime Ngày bắt đầu khóa học

course_created_date datetime Ngày khởi tạo khóa học trong hệ

71

thống

term_number tinyint Thứ tự học ky trong năm học

term_name varchar Tên học ky

academic_year smallint Năm bắt đầu năm học

academic_year_name varchar Tên năm học

category_key int Mã nhóm khóa học

last_update datetime Thời điểm cập nhật cuối cùng

dim_role_group: chiều nhóm vai trò

Tên thuộc tính Kiểu giá trị Ý nghĩa

role_group_key int Khóa chính (khóa đại diện)

natural_key varchar Khóa tự nhiên của nhóm vai trò

trong CSDL chuẩn hóa

role_count int Số lượng vai trò trong nhóm

role_group_bridge: bảng cầu nối giữa chiều vai trò và chiều nhóm vai trò

Tên thuộc tính Kiểu giá trị Ý nghĩa

role_group_key int Mã nhóm vai trò

role_key int Mã vai trò

weighting_factor float Trọng số, có giá trị là

1/role_count (bảng

dim_role_group)

dim_junk_activity: chiều chức năng của hệ thống

Tên thuộc tính Kiểu giá trị Ý nghĩa

activity_key int Khóa chính (khóa đại diện)

module_name varchar Tên mô đun của chức năng

action_name varchar Tên hoạt động

last_update datetime Thời điểm cập nhật cuối cùng72

lkp_category: bảng tìm kiếm nhóm khóa học

Tên thuộc tính Kiểu giá trị Ý nghĩa

category_key int Khóa chính (khóa đại diện)

category_business_key varchar Khóa tự nhiên của nhóm khóa học

trong CSDL chuẩn hóa

category_name varchar Tên nhóm khóa học

category_description text Mô tả nhóm khóa học

last_update datetime Thời điểm cập nhật cuối cùng

category_bridge: bảng cầu nối nhóm khóa học.

Tên thuộc tính Kiểu giá trị Ý nghĩa

parent_category_key int Mã khóa học cha (mỗi khóa học

cha chứa nhiều khóa học con)

child_category_key int Mã khóa học con

nest_level tinyint Số tầng phân cấp

is_top tinyint Có là quan hệ cha-con ở trên cùng

hay không

is_bottom tinyint Có là quan hệ cha-con ở dưới

cùng hay không

Chú thích: Bảng cầu nối này nhằm mục đích khử truy vấn đệ quy cho cây

phân cấp với độ sâu không giới hạn.

Các bảng dữ kiện:

fct_traffic: dữ kiện thống kê về truy cập trên hệ thống

Tên thuộc tính Kiểu giá Ý nghĩa

73

trị

date_key int

Khoá ngoại tham chiếu bảng

dim_date

time_key int

Khoá ngoại tham chiếu bảng

dim_time

user_key int

Khoá ngoại tham chiếu bảng

dim_user

activity_key int

Khoá ngoại tham chiếu bảng

dim_activity

course_key int

Khóa ngoại tham chiếu bảng

dim_course

role_group_key int

Khóa ngoại tham chiếu bảng

dim_role_group

duration int Thời gian truy cập tính theo giây

view_count int Số lượt truy cập

last_update datetime Thời điểm sửa đổi cuối cùng

fct_grade: Dữ kiện thống kê về kết quả học tập của sinh viên trong từng

môn học.

Tên thuộc tính Kiểu giá trị Ý nghĩa

user_key int

Khoá ngoại tham chiếu bảng

dim_user

course_key int

Khoá ngoại tham chiếu bảng

dim_course

grade tinyint

Điểm của sinh viên trong khóa học

tương ứng.

last_update datetime Thời điểm cập nhật cuối cùng

74

5.3.3.3. Phân cấp các chiều:

Chiều ngay

Năm học Học kì Tuần Ngày

Chi u giê ơTh i đi m trong ngay ơ ê Gi ơPhut

Chiều học phần

Nhóm học phần Nhóm học phần con Học phần

Chiều chức năng

Mô đun Ch c năngưHoạt động Chức năng

5.4. Thiết kế hệ thống tích hợp dữ liệu

5.4.1. Rút trích dữ liệu – ETL cho vùng xử lí

Hình 5.4.1-1. Giai đoạn rút trích dữ liệu cho vùng xử lí.

Ở giai đoạn này, dữ liệu chủ yếu được sao chép nguyên trạng từ nguồn

vào vùng xử lí. Quá trình này trải qua các gia đoạn chính dựa trên thuật toán

sau:

Kiểm tra các bảng trong vùng xử lí có trống hay không.

Nếu không có dữ liệu:

75

o Thực hiện rút trích dữ liệu từ nguồn.

Nếu dữ liệu nguồn có thông tin lịch sử: Truy vấn lấy dữ liệu có

ngày giờ thay đổi sau ngày giờ last_update trong vùng dữ liệu

chuẩn hoá.

Ngượclại, thực hiện truy vấn toàn bộ từ dữ liệu nguồn và dữ

liệu trong vùng cơ sở dữ liệu chuẩn hoá để so sánh. Chỉ lấy ra

những dòng dữ liệu mới hoặc có thay đổi để đưa vào vùng xử

lí. Trường last_update được tạo ra trong giai đoạn này, lưu

ngày tháng hiện hành đối với các bảng không chứa thông tin

lịch sử.

o Ngược lại, ngưng không rút trích.

Hình 5.4.1-2. Quá trình rút trích dữ liệu

5.4.2. Biến đổi dữ liệu – ETL cho cơ sở dữ liệu chuẩn hoá

76

Hình 5.4.2.1-Giai đoạn biến đổi dữ liệu đưa vào vùng CSDL chuẩn hoá

Quy trình biến đổi dữ liệu để đưa dữ liệu từ vùng xử lí vào cơ sở dữ liệu

chuẩn hoá được thực hiện qua các bước chính sau:

Nạp các bảng không chứa khoá ngoại (các bảng không bị ràng buộc

khoá ngoại đến bảng khác):

o Đưa dữ liệu trong vùng xử lí vào cơ sở dữ liệu chuẩn hoá.

o Nếu hoàn tất, xoá dữ liệu trong vùng xử lí.

Nạp các bảng chứa khoá ngoại.

o Tìm kiếm khoá ngoại trên những chiều tham chiếu đến.

o Đưa dữ liệu trong vùng xử lí vào cơ sở dữ liệu chuẩn hoá.

o Nếu hoàn tất, xoá dữ liệu trong vùng xử lí.

Hình 5.4.2-2. Các bước chính đưa dữ liệu vào CSDL chuẩn hoá.

77

Hình 5.4.2-3. Các bước chính đưa dữ liệu vào từng bảng trong CSDL chuẩn

hoá.

5.4.3. Nạp dữ liệu – ETL cho kho dữ liệu

Hình 5.4.3-1. Giai đoạn nạp dữ liệu vào kho dữ liệu đầu cuối

Quy trình biến đổi và nạp dữ liệu vào kho dữ liệu dựa trên thuật toán sau:

Nạp các bảng chiều:

o Kiểm tra nếu bảng dim_date và dim_time được nạp hay chưa:

Nếu chưa nạp thì thực hiện nạp 2 bảng này.

Ngược lại, nếu đã nạp thì qua bước tiếp theo.

78

o Thực hiện cập nhật dữ liệu cho chiều ngày tháng nếu có.

o Thực hiện nạp dữ liệu cho các bảng chiều.

o Thực hiện nạp dữ liệu cho các bảng cầu nối.

Thực hiện nạp các bảng dữ kiện:

Hình 5.4.3-2. Các bước chính nạp dữ liệu vào kho dữ liệu

Hình 5.4.3-3. Nạp các bảng chiều.

79

Hình 5.4.3-4. Nạp các bảng dữ kiện.

5.5. Xây dựng ứng dụng đóng gói

5.6. Triển khai ứng dụng

5.6.1. Các phần mềm đi kèm:

Trước khi sử dụng ứng dụng, cần cài đặt các gói phần mềm sau:

Java Runtime Environment – JRE 6u15 trở lên.

.NET Framework Runtime 4.0 trở lên.

5.6.2. Cài đặt

5.6.3. Sử dụng

80