Nghiên Cứu Xây Dựng Hệ Thống Thông Tin Hỗ Trợ Định Biên Nhân Sự Trong Trường Đại Học (LV thạc sĩ)Nghiên Cứu Xây Dựng Hệ Thống Thông Tin Hỗ Trợ Định Biên Nhân Sự Trong Trường Đại Học (LV thạc sĩ)Nghiên Cứu Xây Dựng Hệ Thống Thông Tin Hỗ Trợ Định Biên Nhân Sự Trong Trường Đại Học (LV thạc sĩ)Nghiên Cứu Xây Dựng Hệ Thống Thông Tin Hỗ Trợ Định Biên Nhân Sự Trong Trường Đại Học (LV thạc sĩ)Nghiên Cứu Xây Dựng Hệ Thống Thông Tin Hỗ Trợ Định Biên Nhân Sự Trong Trường Đại Học (LV thạc sĩ)Nghiên Cứu Xây Dựng Hệ Thống Thông Tin Hỗ Trợ Định Biên Nhân Sự Trong Trường Đại Học (LV thạc sĩ)Nghiên Cứu Xây Dựng Hệ Thống Thông Tin Hỗ Trợ Định Biên Nhân Sự Trong Trường Đại Học (LV thạc sĩ)Nghiên Cứu Xây Dựng Hệ Thống Thông Tin Hỗ Trợ Định Biên Nhân Sự Trong Trường Đại Học (LV thạc sĩ)Nghiên Cứu Xây Dựng Hệ Thống Thông Tin Hỗ Trợ Định Biên Nhân Sự Trong Trường Đại Học (LV thạc sĩ)Nghiên Cứu Xây Dựng Hệ Thống Thông Tin Hỗ Trợ Định Biên Nhân Sự Trong Trường Đại Học (LV thạc sĩ)Nghiên Cứu Xây Dựng Hệ Thống Thông Tin Hỗ Trợ Định Biên Nhân Sự Trong Trường Đại Học (LV thạc sĩ)
Trang 1HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG
-
Nguyễn Minh Trí
NGHIÊN CỨU XÂY DỰNG
HỆ THỐNG THÔNG TIN HỖ TRỢ ĐỊNH BIÊN
NHÂN SỰ TRONG TRƯỜNG ĐẠI HỌC
LUẬN VĂN THẠC SĨ KỸ THUẬT
(Theo định hướng ứng dụng)
Trang 2Nguyễn Minh Trí
NGHIÊN CỨU XÂY DỰNG
HỆ THỐNG THÔNG TIN HỖ TRỢ ĐỊNH BIÊN
NHÂN SỰ TRONG TRƯỜNG ĐẠI HỌC
Chuyên ngành:Hệ thống thông tin
Trang 3LỜI CAM ĐOAN
Tôi cam đoan đây là công trình nghiên cứu của riêng tôi
Các số liệu, kết quả nêu trong luận văn là trung thực và chưa từng được ai công
bố trong bất cứ công trình nào
TP Hồ Chí Minh, ngày 25 tháng 5 năm 2017
Học viên thực hiện luận văn
Nguyễn Minh Trí
Trang 4LỜI CÁM ƠN
Đầu tiên em xin gửi lời cảm ơn sâu sắc đến TS Tân Hạnh, người đã trực tiếp
hướng dẫn em tận tình trong suốt thời gian làm luận văn tốt nghiệp
Tiếp đến, em rất cảm ơn đến toàn thể Quý thầy, cô tại Học viện Công nghệ Bưu chính Viễn thông đã tận tình chỉ bảo em trong suốt thời gian học tập tại nhà trường
Bên cạnh đó, em xin chân thành cảm ơn gia đình, bạn bè và đồng nghiệp - Những người luôn kịp thời động viên và giúp đỡ em vượt qua những khó khăn trong cuộc sống
Nhưng vì thời gian có hạn nên chắc rằng luận văn của em không tránh khỏi những thiếu sót Em rất mong nhận được sự thông cảm và chỉ bảo tận tình của Quý thầy, cô
Trân trọng cám ơn
TP Hồ Chí Minh, ngày 25 tháng 5 năm 2017
Học viên thực hiện luận văn
Nguyễn Minh Trí
Trang 5LỜI CAM ĐOAN i
LỜI CÁM ƠN ii
DANH MỤC CÁC THUẬT NGỮ, CHỮ VIẾT TẮT v
DANH SÁCH BẢNG vi
DANH SÁCH CÁC HÌNH VẼ vii
Chương 1 - TỔNG QUAN VỀ ĐỀ TÀI NGHIÊN CỨU 1
1.1 Tính cấp thiết của đề tài 1
1.2 Mục tiêu nghiên cứu 3
1.3 Cấu trúc của luận văn 4
Chương 2 - TỔNG QUAN VỀ KHO DỮ LIỆU 5
(DATA WAREHOUSE) VÀ BUSINESS INTELLIGENCE (BI) 5
2.1 Kho dữ liệu 5
2.1.1 Khái niệm 5
2.1.3 Mục tiêu 7
2.2 Xây dựng luồng ETL (Extract - Transform - Load) 29
2.2.1 Khái niệm ETL 29
2.2.2 Kiến trúc ETL 30
2.2.3 Vai trò của ETL trong việc xây dựng hệ thống tích hợp [1, tr.28] 31
2.2.4 Các yếu tố quan trọng đối với ETL 33
2.2.5 Những khó khăn khi xây dựng tiến trình ETL 33
2.3 Khái niệm Business Intelligence (BI) 33
2.4 Các công nghệ hỗ trợ BI (Technologies supporting for BI) [13] 34
2.5 Những hoạt động của BI liên quan đến vấn đề nghiên cứu [13] 35
2.5.1 Truy vấn và báo cáo (query and reporting) 35
2.5.2 Phân tích xử lý trực tuyến (OLAP - Online Analitical Proccessing) 35
2.5.3 Phân tích thống kê (statistical analysis) 36
Chương 3 - XÂY DỰNG HỆ THỐNG THÔNG TIN HỖ TRỢ ĐỊNH BIÊN 37
3.1 Khảo sát nguyên tắc, đặt vấn đề và thu thập nguồn dữ liệu cho công tác định biên tại Trường Đại học Kinh tế TP Hồ Chí Minh 37
3.1.1 Nguyên tắc định biên 37
3.1.2 Đặt vấn đề 38
3.1.3 Thu thập dữ liệu 39
3.2 Phân tích, thiết kế hệ thống thông tin phục vụ định biên 39
3.2.1 Tổng quan về hệ thống thông tin định biên 39
3.2.2 Thiết kế kho dữ liệu 42
Trang 63.2.3 Thiết kế tiến trình ETL 46
3.2.3.1 Chuẩn bị dữ liệu 46
3.2.3.2 Sử dụng SSIS để thực hiện ETL 47
3.2.4 Sử dụng SSAS để xây dựng cube cho cơ sở dữ liệu 02 khối 49
3.2.4.1 Xây dựng cube kho dữ liệu chủ đề khối quản lý 49
3.2.4.2 Xây dựng cube kho dữ liệu chủ đề khối giảng dạy 50
3.2.5 Thử nghiệm kết quả bằng câu truy vấn MDX [7] và sử dụng phần mềm Power BI Desktop của Microsoft để làm báo cáo [18] 51
3.2.5.1 Các truy vấn đa chiều (MDX) 51
3.2.5.2 Sử dụng Power BI Desktop của Microsoft để làm báo cáo 55
3.3 Cài đặt và đánh giá hệ thống 57
3.3.1 Cài đặt hệ thống 57
3.3.2 Đánh giá hệ thống 63
KẾT LUẬN 66
DANH MỤC CÁC TÀI LIỆU THAM KHẢO 68
PHỤ LỤC: KHỐI LƯỢNG CÔNG VIỆC TỪNG ĐẦU VIỆC 69
Trang 7DANH MỤC CÁC THUẬT NGỮ, CHỮ VIẾT TẮT
DW,
DWH
OLAP Online Transaction Processing Xử lý giao dịch trực tuyến
ETL Extract, Transform, Load Tiến trình trích xuất, chuyển đổi và
nạp dữ liệu DDS Dimensional Data Store Kho dữ liệu đa chiều
NDS Normalized Data Store Kho dữ liệu dạng chuẩn hoá
ODS Operational Database Store Kho dữ liệu tác nghiệp
ERD Entity Relationship Diagram Sơ đồ liên kết thực thể
DSA Data Staging Area Cơ sở dữ liệu trung chuyển
EM Enterprise Model Mô hình doanh nghiệp
BI Business Intelligence Kinh doanh thông minh
SSIS SQL Server Integration Services Dịch vụ tích hợp dữ liệu của SQL
Server SSAS SQL Server Analysis Services Dịch vụ phân tích dữ liệu của SQL
Server SSRS SQL Server Reporting Services Dịch vụ quản lý báo cáo của SQL
Server MSSQL Microsoft SQL Server Hệ quản trị cơ sở dữ liệu của
Microsoft MDX Multidimensional eXpressions Ngôn ngữ truy vấn đa chiều
BIDS Business Intelligence
Development Studio
Công cụ phát triển Kinh doanh thông minh
Trang 8DANH SÁCH BẢNG
3.1 Ma trận kiến trúc buýt mô tả các tác nghiệp và đối
3.2 Ma trận kiến trúc buýt mô tả các tác nghiệp và đối
Trang 92.2 Lợi ích của DW trong hỗ trợ ra quyết định 6
3.1 Sơ đồ tổng quan về hệ thống thông tin phục vụ định biên 35 3.2 Sơ đồ thiết kế kho dữ liệu khối quản lý 42 3.3 Sơ đồ thiết kế kho dữ liệu khối giảng viên 42
3.11 Sơ đồ các bảng chiều và sự kiện trong cube khối giảng dạy 51
3.13 Kết quả truy vấn số giờ thực hiện công việc và mức độ hiệu
quả tương ứng của các nhân sự
52
3.14 Kết quả truy vấn giờ thực hiện theo kế hoạch và giờ thực tế
Phòng Cơ sở vật chất đảm nhận tương ứng với độ hiệu quả qua
3.16 Kết quả truy vấn tổng giờ thực hiện theo từng năm khoảng
giữa 02 phòng Cơ sở vật chất và Công nghệ thông tin
54
Trang 10nhân sự thực hiện công việc trong năm 2016
3.19 Kết quả truy vấn số lượng nhân sự theo công thức định biên và
số lượng nhân sự thực tế từng đơn vị năm 2016
55
3.20 Báo cáo dạng biểu đồ số lượng định biên và số lượng hiện tại 56 3.21 Báo cáo dạng grid số lượng định biên và số lượng hiện tại 56 3.22 Báo cáo số lượng định biên và số lượng hiện tại theo năm 57 3.23 Báo cáo nhân sự khối quản lý, năm 2015 57
3.28 Triển khai thành công khối dữ liệu dành cho khối quản lý 62
3.31 Đăng nhập vào tài khỏa Power BI của Microsoft 64
3.33 Báo cáo hiệu quả công việc của nhân sự theo từng công việc,
đầu việc
65
3.34 Báo cáo tình hình thực hiện công việc chi tiết từng nhân sự
theo đơn vị qua từng năm
65
3.35 Báo cáo tình hình nhân sự thực hiện công việc qua 3 năm
2014, 2015 và 2016 với tổng giờ thực hiện ít hơn 1800 giờ
66
3.36 Báo cáo tình hình đơn vị, nhân sự thực hiện công việc năm
2016 với trung bình mức độ hiệu quả lớn hơn 80%
66
Trang 11Chương 1 - TỔNG QUAN VỀ ĐỀ TÀI NGHIÊN CỨU
1.1 Tính cấp thiết của đề tài
Ngày nay, trong bất kỳ tổ chức nào trên thế giới cũng như ở Việt Nam, nguồn nhân lực đang trở thành nguồn lực tối quan trọng đối với sự thành bại của một tổ chức Để tạo ra năng lực cạnh tranh của một tổ chức thì lợi thế thông qua con người luôn được xem là lợi thế hàng đầu Con người luôn là nguồn lực căn bản, có tính quyết định và không thể thiếu của mọi thời đại
Phát triển và nâng cao chất lượng nguồn nhân lực càng đặc biệt quan trọng trong các trường đại học cũng đồng nghĩa với việc đem đến cho các trường đại học một thách thức không nhỏ đó là làm sao để xác định được một cơ cấu, số lượng nhân sự tối ưu trong điều kiện nguồn lực tài chính là có hạn Điều này không thể thiếu vai trò của công nghệ thông tin trong việc cung cấp dữ liệu để nhà quản lý có thể phân tích, đánh giá cũng như đưa ra kết quả định biên tốt nhất
Tuy nhiên, do nhiều yếu tố khách quan, việc ứng dụng công nghệ thông tin của một số tổ chức tại đơn vị vẫn chưa được khai thác thật sự có hiệu quả do phần mềm sử dụng không thống nhất tại các bộ phận trong cùng một tổ chức Dữ liệu thường được quản lý bởi những hệ quản trị cơ sở dữ liệu khác nhau (MySQL, SQL Server, Visual Foxpro, Access,…) hoặc chỉ là những tập tin định dạng khác (TXT, CSV, XML, excel,…)
Điều này dẫn đến việc dữ liệu không đồng nhất, thông tin trùng lắp, không nhất quán nên khó để theo dõi, quản lý một cách tổng quát các hoạt động, các lĩnh vực trong cùng một tổ chức mà cụ thể trong công tác định biên càng gặp nhiều khó khăn khi mà việc thu thập, xử lý dữ liệu trên excel lại tốn rất nhiều thời gian nhưng lại dễ sai sót Càng khó khăn hơn khi nội dung định biên cần phân tích trên nhiều yếu tố, dữ liệu lịch sử
Vấn đề đặt ra là làm sao để có được một hệ thống thông tin về nhân sự giúp nhà quản lý khai thác, sử dụng và phân tích thông tin một cách có hiệu quả Do vậy, tôi chọn đề tài “Xây dựng hệ thống thông tin hỗ trợ định biên trong Trường Đại học Kinh tế TP Hồ Chí Minh” làm đề tài nghiên cứu
Trang 12Tổng quan về vấn đề nghiên cứu:
Hình 1.1: Sơ đồ tổng quan về đề tài nghiên cứu
Tìm hiểu nhu cầu dữ liệu cũng như những yếu tố cần thiết để phân tích, đánh giá và đưa đến kết quả định biên nhân sự tại Trường Đại học Kinh tế TP Hồ Chí Minh Từ đó thu thập những nguồn dữ liệu tại các lĩnh vực có liên quan
Tổng hợp và lưu trữ dữ liệu thô: Là việc tổng hợp dữ liệu thô từ những nguồn đã thu thập vào một nơi lưu trữ chung phục vụ cho việc khai thác dữ liệu
Sàng lọc dữ liệu: Dữ liệu thô chưa xử lý thường lớn và có thể trùng lặp, không cần thiết, sàng lọc dữ liệu khiến cho chất lượng dữ liệu đầu vào chính xác và phù hợp với nhu cầu sử dụng hơn
Lưu trữ dữ liệu: Thông qua việc tìm hiểu nhu cầu của công tác định biên, dữ liệu được sàng lọc và lưu trữ vào kho dữ liệu
Phân tích dữ liệu: Sử dụng các nguồn dữ liệu từ kho dữ liệu, xây dựng các cấu trúc dữ liệu tạo thành các Data Marts Data Marts là lớp đưa các dữ liệu từ kho
dữ liệu tới người dùng cuối
Tạo báo cáo (Reporting): Các báo cáo, thống kê, phân tích được xây dựng sử dụng cấu trúc từ
Tìm hiểu về Business Intelligence (BI):
- Truy vấn và báo cáo (query and reporting)
Trang 13- Phân tích xử lý trực tuyến (OLAP - Online analytical processing)
- Phân tích thống kê (statistical analysis)
1.2 Mục tiêu nghiên cứu
Xây dựng một hệ thống hỗ trợ định biên nhân sự dựa trên Data Warehouse và Business Intelligence
Hệ thống đáp ứng được yêu cầu:
- Tích hợp dữ liệu đa nguồn
- Phân tích dữ liệu phục vụ việc định biên nhân sự
- Báo cáo và thống kê dữ liệu theo thời điểm cần thiết
Hệ thống thông tin quản lý trong các trường đại học là hệ thống lớn gồm nhiều đơn vị và có nhiều đối tượng sử dụng Khi khai thác dữ liệu phục vụ cho việc định biên thường gặp không ít khó khăn, tốn thời gian và dễ sai sót Vì vậy, đề tài luận văn nghiên cứu thu thập những nguồn dữ liệu là yếu tố liên quan đến vấn đề định biên, xây dựng kho dữ liệu phục vụ tốt nhất cho việc hỗ trợ nhà quản lý phân tích, xác định cơ cấu, số lượng nhân sự tối ưu, giúp nhà quản lý lập kế hoạch tuyển dụng cho tương lai
Mong muốn đề tài sẽ áp dụng rộng ra các nhiều lĩnh vực khác trong trường từ nhiều nguồn dữ liệu khác
Đối tượng và phạm vi nghiên cứu:
Đối tượng nghiên cứu:
Kho dữ liệu (Data Warehouse)
Business Intelligence (BI)
SQL Server hoặc Oracle
Phạm vi nghiên cứu:
Định biên nhân sự trong Trường Đại học Kinh tế TP Hồ Chí Minh, theo quy định của Nhà nước
Từ những nguồn dữ liệu có cấu trúc:
Dữ liệu nhân sự (NHANSU)
Dữ liệu tài chính (TAICHINH)
Trang 14 Dữ liệu về giảng dạy (DAOTAO)
Dữ liệu về nghiên cứu khoa học (NCKH)
Phương pháp nghiên cứu: Thu thập dữ liệu liên quan đến việc định biên như
thông tin nhân sự, khối lượng giảng dạy, hoạt động chuyên môn, nghiên cứu khoa
học của từng nhân sự, kế hoạch thực hiện các đầu việc và phân công công việc
Tìm hiểu về Data Warehouse
Tìm hiểu về Tiến trình ETL
Tìm hiểu về Business Intelligence (BI):
- Truy vấn và báo cáo (query and reporting)
- Phân tích xử lý trực tuyến (online analytical processing (OLAP))
- Phân tích thống kê (statistical analysis)
Dựa trên lý thuyết đã tìm hiểu, xây dựng hệ thống giúp phân tích, đánh giá
và đưa ra kết quả định biên nhân sự
1.3 Cấu trúc của luận văn
Luận văn gồm 3 chương với các nội dung:
Chương 1: Khảo sát nhu cầu về thông tin cần thiết cho việc định biên, từ đó thu
thập những nguồn dữ liệu có liên quan Tìm hiểu những công trình nghiên cứu có liên quan qua đó nêu ra những vấn đề, đối tượng nghiên cứu mà đề tài quan tâm Nêu làm rõ sự cấp thiết của vấn đề cần nghiên cứu và tổng quan vấn đề nghiên cứu
để người đọc có một cái nhìn tổng quát ban đầu
Chương 2: Mô tả lý thuyết về Data Warehouse và tiến trình ETL Phân tích vai
trò của ETL trong việc xây dựng hệ thống tích hợp Tìm hiểu về cách thức thu thập,
xử lý và trích chọn dữ liệu Tìm hiểu về business intelligenge (BI) và những hoạt động của BI có liên quan đến vấn đề nghiên cứu
Chương 3: Tìm hiểu về nguyên tắc định biên để từ đó xác định nguồn dữ liệu
cũng như mô tả tổng quát hệ thống thông tin cần xử lý để giúp nhà quản lý phân tích, đánh giá và đưa ra kết quả định biên Tiến hành xây dựng hệ thống thông tin dựa trên lý thuyết đã tìm hiểu từ những chương trước Thử nghiệm hệ thống và đánh giá kết quả
Trang 15Chương 2 - TỔNG QUAN VỀ KHO DỮ LIỆU
(DATA WAREHOUSE) VÀ BUSINESS INTELLIGENCE (BI)
2.1 Kho dữ liệu
2.1.1 Khái niệm
Data Warehouse (DW) - Kho dữ liệu là thuật ngữ được William H Inmon đưa ra trong những năm 1970 Kho dữ liệu là hệ thống tập trung dữ liệu từ các nguồn khác nhau nhằm mục đích khai thác, phân tích thông tin và hỗ trợ quyết định [2], các đặc trưng về mặt dữ liệu là: Tích hợp, hướng chủ đề, tích lũy theo thời gian
Trang 16học, hay tại các phòng ban chức năng như quản lý nghiên cứu khoa học - dữ liệu về hoạt động nghiên cứu khoa học của giảng viên, phòng tài chính kế toán - dữ liệu thanh toán giờ giảng, Dữ liệu tại mỗi phòng ban là một khung nhìn Hệ thống DW
sẽ tập hợp tất cả dữ liệu tại các nguồn này tạo nên một khung nhìn tổng thể về định biên nhân sự tại trường đại học
Tính tích hợp còn được thể hiện trong việc thống nhất các kiểu, định dạng của dữ liệu, độ đo hay các thuật ngữ chung trong doanh nghiệp
Ví dụ: Dữ liệu số điện thoại trong ứng dụng tác nghiệp được lưu theo định dạng +84 943 nhưng trong tập tin được quản lý nhân sự lại được lưu theo định dạng 0943 Dữ liệu này trong DW sẽ được lưu theo một định dạng thống nhất phù hợp với tổ chức (doanh nghiệp hay trường đại học,…)
- Hướng chủ đề (Subject-Oriented): Dữ liệu của DW được tổ chức và lưu trữ theo các chủ đề nghiệp vụ mà người khai thác quan tâm
Ví dụ: Dữ liệu của một doanh nghiệp trong DW có các chủ đề sau:
+ Thực thể doanh nghiệp: Khách hàng, đối tác, đại lý
+ Hoạt động của doanh nghiệp: Bán hàng, phân phối, chế tạo
- Tích lũy theo thời gian (Time-Variant): Dữ liệu lưu trữ có tính chất lịch
sử, theo dòng thời gian tính từ một thời điểm trong quá khứ cho đến hiện tại và các
dữ liệu sẽ phát sinh trong tương lai 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
- Bất biến (Non-Volatile): Dữ liệu đã đưa vào trong DW nói chung ở dạng chỉ đọc (read-only) và rất hiếm khi thay đổi (không sửa, không xóa) DW là những
CSDL được thiết kế cho mục đích khai thác và phân tích thông tin (query - truy vấn) chứ không phải mục đích cập nhật (update - cập nhật, delete - xóa) như trong CSDL của các ứng dụng tác nghiệp
Trang 172.1.3 Mục tiêu
Hình 2.2: Lợi ích của DW trong hỗ trợ ra quyết định [9]
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
Nhà quản lý sẽ được giải phóng khỏi các quyết định dựa trên dữ liệu hạn chế
và mang tính cảm xúc của mình Các quyết định có ảnh hưởng đến chiến lược và hoạt động của tổ chức sẽ được dựa trên những thực tế đáng tin cậy với các bằng chứng và số liệu thực tế được tổ chức rõ ràng Ngoài ra, DW và BI có thể được áp dụng trực tiếp vào các quá trình kinh doanh bao gồm phân khúc thị trường, quản lý hàng tồn kho, quản lý tài chính và bán hàng
Hệ thống DW được tách riêng biệt khỏi hệ thống tác nghiệp (OLTP) nên các
giao dịch trực tuyến không bị ảnh hưởng và gián đoạn bởi các truy vấn báo cáo
Trang 18Trong khi đó, hệ thống DW được thiết kế để lưu trữ một lượng lớn dữ liệu với tốc
độ truy vấn dữ liệu nhanh
Nhiều doanh nghiệp, hệ thống thông tin doanh nghiệp bao gồm nhiều hệ
thống con, tách biệt nhau và được xây dựng trên các nền tảng khác nhau Trong khi
để kinh doanh thông minh thì việc sát nhập dữ liệu từ các hệ thống con này là một nhu cầu thiết yếu Hệ thống DW giải quyết được nhu cầu thiết yếu này bởi đặc trưng tích hợp dữ liệu từ các nguồn khác nhau Với DW, các nhà quản lý chỉ cần truy cập dữ liệu tại một nơi, giảm bớt gánh nặng thu thập, tổng hợp thông tin và có khung nhìn duy nhất về toàn cảnh hoạt động của doanh nghiêp chứ không phải là nhiều góc nhìn có thể đến từ báo cáo của các hệ thống con
Dữ liệu được cập nhật liên tục và kịp thời: Trong DW, dữ liệu từ nhiều nguồn khác nhau sẽ được lập lịch cập nhật định kỳ một cách tự động theo một chu
kỳ thời gian (tiến trình ETL) phù hợp với mục đích khai thác dữ liệu của doanh nghiệp Khi đó người dùng không phải mất thời gian chờ dữ liệu được tích hợp từ nhiều nguồn khác nhau Ngoài ra, dữ liệu được tổng hợp và truy cập thông qua giao diện của hệ thống BI, để có được dữ liệu mới, người dùng chỉ cần thực hiện thao tác làm mới (refresh) dữ liệu mà không cần phải chờ đợi các chuyên gia xây dựng các báo cáo Thay vào đó, người dùng có thời gian để phân tích dữ liệu và đưa ra quyết định đúng đắn
Kinh doanh thông minh từ dữ liệu lịch sử: Các hệ thống tác nghiệp chỉ lưu trữ dữ liệu trong một khoảng thời gian nhất định và đáp ứng nhu cầu báo cáo, phân
tích trong khoảng thời gian đó Với đặc trưng tích lũy theo thời gian của DW, dữ liệu được lưu trữ trong nhiều năm, cho phép những người quản lý doanh nghiệp có được sự phân tích về xu hướng phát triển và dự đoán xu hướng trong tương lai Với các lợi ích kinh doanh thông minh và hỗ trợ ra quyết định, hệ thống DW và BI giúp cho tăng doanh thu và giảm chi phí làm cho doanh nghiệp phát triển nhanh chóng
Trang 192.1.1 Kiến trúc DW
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 ([6], Tr 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 DW 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 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ý
Trang 20 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
Hình 2.3: Kiến trúc kho dữ liệu dạng DDS đơn [6, tr.34]
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 tiến trình ETL (2.2) Tiến trình 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 tiến trình 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
Trang 21Nhược điểm:
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
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 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
đổi-Hình 2.4: Kiến trúc kho dữ liệu dạng NDS+DDS [6, tr.35]
Đâ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:
Lưu trữ dữ liệu tập trung đã được làm sạch
Chứa dữ liệu lịch sử
Sẵn sàng cho việc nạp vào nhiều kho dữ liệu đầu cuối
Tái sử dụng được các gói ETL
Nhược điểm:
Trang 22 Kiến trúc phức tạp
Tốn thêm không gian lưu trữ
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
Vùng chứa dữ liệu trung gian không được tận dụng vào mục đích khác
Hình 2.5: Kiến trúc kho dữ liệu dạng ODS+DDS [6, tr.38]
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 2.5, 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:
Ưu điểm:
Lưu trữ dữ liệu tập trung đã được làm sạch
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:
Không chứa dữ liệu lịch sử
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
Trang 23 Vùng dữ liệu hoạt động có thể bị gián đoạn khi nạp kho dữ liệu
Không tái sử dụng được các gói ETL
Hình 2.6: Vùng xử lý [6]
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
Tuy 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
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
Trang 24Vù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ủ
Hình 2.7: Cơ sở dữ liệu chuẩn hoá [6]
Đố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
Trang 25 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ý
Hình 2.8: Kho dữ liệu đầu cuối [6]
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
Trang 26dữ 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
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 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
Việc tổ chức dữ liệu trong cơ sở dữ liệu của DW được tiếp cận theo 2 hướng sau:
- Giản đồ hình sao (Star Schema) - Phương pháp mô hình hoá đa chiều của Ralph Kimball: Là cơ sở dữ liệu quan hệ được thiết kế logic dạng hình sao bao gồm một bảng dữ liệu chi tiết ở vị trí trung tâm quan hệ với các bảng dữ liệu danh mục xung quanh (kiểu N:1) Mỗi bảng danh mục đều là bảng duy nhất của nhánh, không
Trang 27có quan hệ với bảng danh mục nào khác 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) Ví dụ, trong giản đồ hình sao sau đây, bảng dữ liệu trung tâm thể hiện các đầu việc theo thực tế phân công, các bảng danh mục xung quanh là: Ngày tháng, đầu việc, đơn vị và nhân sự
Trùng lắp dữ liệu nhiều, khiến cho kích thước kho lớn
- Giản đồ hình bông tuyết (Snowflake Schema) - Phương pháp mô hình hoá dạng chuẩn hoá của Bill Inmon: Là cơ sở dữ liệu hình sao nhưng được chuẩn hóa theo một dạng chuẩn khác (dạng chuẩn 3), mỗi bảng danh mục được tách thành các
Trang 28bảng danh mục phân cấp nếu có để đảm bảo không dư thừa dữ liệu Trong ví dụ Hình 2.10, nhánh Nhân sự được tách thành Khối(quản lý hoặc giảng viên) và Loại (Cơ hữu, thỉnh giảng hoặc lao động ngắn hạn)
Hình 2.10: Giản đồ hình bông tuyết
Mục tiêu của mô hình bông tuyết là kế thừa việc truy vấn nhanh của mô hình sao; không để dưa thừa dữ liệu
Ư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
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
Kiến trúc buýt
Để đư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) [1] Đâ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
Khối Loại
Trang 29Hình 2.11: Ma trận kiến trúc buýt [1, tr.386]
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 (nếu
có là X, ngược lại Null)
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 đó:
Các dòng: Là các bảng dữ kiện
Các cột: Là các bảng chiều
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)
a Những thuật ngữ trong Data Warehouse
- Bảng chiều (Dimension Table): Là bảng danh mục trong giản đồ hình sao hoặc bông tuyết, lưu trữ thông tin về các đối tượng như: Nhân sự, đơn vị, thời
Trang 30gian,… Các trường (fields) của bảng danh mục bao gồm Primary key là kiểu số, ví
dụ: Mã nhân sự và các trường thông tin thuộc tính, ví dụ: Mã nhân sự, tên nhân sự,
trình độ,…
- Trong giản đồ hình sao, bảng danh mục còn có thêm các trường sau:
Các trường thông tin tổng hợp (Aggregate data): Các giá trị tổng hợp và
tính sẵn (ví dụ: Tổng số số giờ thực hiện công việc, tổng số công việc
Primary key: Kiểu số, định danh duy nhất một dòng dữ liệu của bảng sự
kiện, ví dụ: Id phân giảng
Foreign key: Tham chiếu tới Primary Key của các bảng danh mục, ví dụ:
Các trường thông tin không phải kiểu số, ví dụ: Ghi chú, mô tả phân
công,…
Bảng phụ không dùng Foreign Key đến các bảng danh mục
Trang 31- Khóa giả (Surrogate Key): Là trường kiểu số, dùng để làm Primary Key cho các bảng danh mục hoặc bảng sự kiện trong trường hợp Primary Key gốc của các
bảng này không phải là kiểu số hoặc là khóa tổ hợp của nhiều trường
- Measure (hay còn gọi là Fact): Là những thông tin có thể đo lường được, mỗi measure tương ứng với một trường thông tin phát sinh trong bảng sự kiện như:
Số lượng, doanh số,
- Chiều (Dimension): Là những chiều tổng hợp, phân tích về các tiêu chuẩn để
đánh giá (measure), ví dụ: Chiều nhân sự, chiều thời gian,…; thông tin về
dimension được lưu ở bảng danh mục; trong dữ liệu chi tiết phát sinh, dimension chính là các trường Foregn Key của bảng sự kiện Dimension bao gồm một tập các
thuộc tính (attribute) đi kèm, ví dụ: Dimension Giảng viên bao gồm các thuộc tính sau: Mã giảng viên, tên giảng viên, giới tính, trình độ, chuyên môn, loại (thỉnh
giảng hay cơ hữu)…
- Hệ phân cấp (Hierarchy): Là quan hệ phân cấp bên trong một dimension; trong một dimension có thể có nhiều hệ phân cấp Hieararchy là căn cứ để thực hiện
các thao tác trên dữ liệu tổng hợp: Tổng hợp lên (roll-up) hoặc chi tiết xuống
(drill-down) Ví dụ: Trong dimension Giảng viên, có 2 hierarchy sau:
Hieararchy Giảng viên - Trình độ là: Giảng viên << Trình độ <<
Chuyên môn << Nơi đào tạo
Hieararchy Giảng viên - Loại là: Giảng viên << Loại (Thỉnh giảng hay
cơ hữu)
b Kho dữ liệu chuyên đề (Data Mart - DM)
- DM là CSDL được thiết kế theo giản đồ hình sao, chứa dữ liệu về một chủ
đề thông tin xác định, phục vụ một lớp đối tượng người dùng cụ thể Trong một
DW, có thể có nhiều DM, mỗi DM tương ứng với một chủ đề thông tin [15]
- Dựa trên các kết quả đã có từ giai đoạn khảo sát và phân tích về nhu cầu thông tin, dựa trên việc phân tích khả năng cung cấp những thông tin có thể lấy ra
từ dữ liệu nguồn, các bước để thiết kế DM bao gồm:
Trang 32 Xác định danh sách các chủ đề thông tin mà hệ thống cần đáp ứng Mỗi chủ đề thông tin cần có các nội dung sau:
Các measure: Các giá trị số, những con số nghiệp vụ như số giờ giảng, giá trị bán thể hiện chủ đề định biên khối giảng dạy
Các dimension: Các chiều phân tích thông tin Ví dụ: Giảng viên, khoa, bộ môn, thời gian,…
Với mỗi chủ đề, thiết kế một DM:
Vẽ sơ đồ thực thể quan hệ (ERD, giản đồ hình sao)
Thiết kế bảng sự kiện, mỗi DM chỉ có một bảng sự kiện
+ Primary key: kiểu số, dùng Surrogate Key (khóa giả) nếu Primary Key hiện thời chưa phải là kiểu số
+ Foreign Key: sang các bảng danh mục
Thiết kế các index
Trang 33+ Với bảng sự kiện: Index trên các trường Foreign Key (trừ Foreign Key đã được chọn để chia partition)
+ Với các bảng danh mục: Index trên các trường có nhu cầu tìm kiếm (trừ trường đã được chọn để chia partition)
Thiết kế giải pháp phi chuẩn: Làm dư thừa dữ liệu để tăng tốc độ thực hiện các câu lệnh truy vấn, ví dụ: mview trong Oracle
Hình 2.12 là một ví dụ về ERD của một Data Mart
Hình 2.12: Lược đồ quan hệ kho dữ liệu chủ đề Khối quản lý
c Mô hình doanh nghiệp (Enterprise Model - EM)
Enterprise Model là CSDL được thiết kế theo mô hình bông tuyết, chứa dữ liệu tích hợp của tất cả các chủ đề thông tin mà hệ thống cần đáp ứng, cung cấp dữ liệu cho tất cả các DM Trong một DW, chỉ có một EM, nhưng bên trong EM này có thể
có một hoặc nhiều bảng sự kiện
Dựa trên bản thiết kế logic các DM đã có, các bước để thiết kế EM bao gồm:
- Phân tích bản thiết kế logic các DM đã có
- Chuẩn hóa và tích hợp các bảng danh mục:
+ Sau khi chuẩn hóa, những bảng danh mục nào tương đương nhau (cùng ý nghĩa nghiệp vụ, cùng primary key,…) thì tích hợp thành một bảng (primary key là chung, các trường thuộc tính là hợp từ hai bảng);
Trang 34những bảng danh mục còn lại được giữ nguyên cấu trúc và nếu có quan hệ thì tạo Foreign Key với các bảng danh mục khác
+ Mỗi DM có một tập hợp các bảng danh mục, mỗi bảng này cần được chuẩn hóa (tách bảng) thành các bảng quan hệ theo dạng chuẩn 3 để không bị dư thừa dữ liệu
+ Tích hợp các bảng slave (nếu có): Tương tự và đi kèm với bảng sự kiện + Vẽ sơ đồ thực thể quan hệ (ERD, mô hình bông tuyết, có thể có nhiều bảng sự kiện)
- Thiết kế các bảng danh mục theo dạng chuẩn 3, một số đặc điểm:
+ Riêng với bảng danh mục quan hệ trực tiếp với bảng sự kiện: Primary Key phải là kiểu số (có thể dùng Surrogate Key nếu cần)
+ Không cần các trường thông tin tổng hợp, thông tin dẫn xuất
- Thiết kế các bảng sự kiện: tương tự trong DM
+ Primary Key: Kiểu số, dùng Surrogate Key nếu Primary Key hiện thời chưa phải là kiểu số
+ Foreign Key: Sang các bảng danh mục
Trang 35+ Với bảng sự kiện: thường chia partition theo chiều thời gian (tức là chia theo trường Foreign Key sang bảng danh mục thời gian)
+ Với các bảng danh mục lớn, có sự tăng trưởng dữ liệu: chia partition theo trường có nhu cầu tìm kiếm chủ yếu (nếu xác định được)
Hình 2.13 là một ví dụ về ERD của một Enterprise Model
Hình 2.13: ERD của một Enterprise Model
e CSDL trung chuyển (Data Staging Area - DSA)
Trang 36Data Staging Area (DSA) là một tập các CSDL đóng vai trò trung chuyển dữ liệu giữa các nguồn dữ liệu với EM DSA là môi trường dữ liệu trung gian, lưu trữ
tạm thời dữ liệu để xử lý, làm sạch và tích hợp trước khi đưa vào EM
Đặc điểm dữ liệu tại DSA:
- Chỉ lưu trữ tạm thời của một phiên, khi xử lý xong thì xóa đi để chuẩn bị xử
lý cho phiên tiếp theo
- Có hai loại DSA:
+ DSA đích:
Là CSDL có cấu trúc tương đương với EM (CSDL hình bông tuyết), là nơi chứa dữ liệu kết quả cuối cùng của giai đoạn xử lý, làm sạch và tích hợp trước khi đưa vào EM
Chỉ có một DSA đích
+ DSA nguồn:
Là CSDL có cấu trúc tương đương với dữ liệu nguồn (mô hình CSDL quan hệ thông thường) và chứa dữ liệu nguyên bản của nguồn (sau đó mới xử lý, làm sạch)
Có nhiều DSA nguồn: Mỗi dữ liệu nguồn cần một DSA nguồn
Các bước thực hiện thiết kế DSA
- Thiết kế DSA đích dựa trên bản thiết kế EM đã có:
+ Vẽ sơ đồ ERD cho DSA đích giống với ERD của EM (nên tạo các bảng trùng tên với bảng tương ứng trong EM)
+ Thiết kế các bảng danh mục, các bảng sự kiện, các bảng slave giống như trong EM
+ Thiết kế các index: Giống như index EM
- Thiết kế các DSA nguồn:
+ Mục tiêu của thiết kế các DSA nguồn:
Cấu trúc DSA nguồn đảm bảo tính nguyên bản của dữ liệu nguồn (kiểu dữ liệu tương đương, nội dung dữ liệu tương đương) tại thời điểm trước khi xử lý
Trang 37 Cấu trúc DSA nguồn đảm bảo cung cấp đầy đủ dữ liệu nguồn cho DSA đích
+ Dựa trên tài liệu khảo sát dữ liệu nguồn, xác định danh sách các nguồn dữ liệu cần đưa vào DW, với mỗi nguồn dữ liệu thiết kế một DSA nguồn:
Phân tích sơ đồ ERD của CSDL nguồn để nắm được mối quan hệ
dữ liệu giữa các bảng dữ liệu nguồn
Phân tích mối quan hệ dữ liệu giữa các bảng dữ liệu nguồn với các bảng trong DSA đích, từ đó xác định danh sách các bảng, các trường
sẽ đưa vào DSA nguồn
Vẽ sơ đồ ERD cho DSA nguồn (dựa trên các kết quả phân tích)
Thiết kế các bảng cho DSA nguồn: Cấu trúc các bảng của DSA nguồn tương đương với cấu trúc các bảng của CSDL nguồn (tương đương về kiểu dữ liệu của các trường, về primary key, foreign key)
- Thiết kế các index trên các trường Primary Key, Foreign Key
f Siêu dữ liệu (Metadata)
Metadata là lớp dữ liệu lưu trữ các thông tin mô tả về chính các thành phần của DW Thực chất việc thiết kế metadata cho DW là thiết kế một CSDL quan hệ
để lưu trữ các loại dữ liệu sau:
- Cấu trúc và ý nghĩa của từng CSDL trong DW (dữ liệu nguồn, DSA, EM, DM): mô tả về các bảng, các trường, ý nghĩa ngiệp vụ
- Quan hệ tham chiếu giữa các trường, bảng của các CSDL khác nhau
- Dữ liệu nghiệp vụ của người dùng: các measure, các dimension, các thuộc tính đi kèm (attribute), các phân cấp (hieararchy)
- Dữ liệu quản lý tiến trình ETL: dữ liệu về từng công đoạn chuyển đổi, các phiên thực hiện,…
- Dữ liệu về tầng khai thác và phân tích thông tin: cấu trúc và ý nghĩa các đơn
vị của lớp dữ liệu tham chiếu; danh mục các kết quả đầu ra (báo cáo, phân tích), danh sách user và quyền truy cập
Trang 38- Vai trò của metadata:
o Lưu trữ hình ảnh về toàn bộ thiết kế của hệ thống DW và BI, phục vụ việc tra cứu thông tin về hệ thống, bảo trì và mở rộng hệ thống
o Cung cấp các dữ liệu cơ sở (thông tin đầu vào) cho giai đoạn thiết kế vật lý: thiết kế vật lý các CSDL, tiến trình ETL, các công cụ quản trị
và vận hành
f Tầng khai thác và phân tích thông tin
Nhìn chung, mục đích hướng đến của việc thiết kế DW là ra được các DM
Về mặt logic, các DM được thiết kế theo ý tưởng đa chiều với các bảng danh mục (các chiều) xoay quanh bảng dữ liệu chi tiết về các giao dịch phát sinh; kiểu thiết kế này giúp đáp ứng nhanh và linh hoạt các nhu cầu thông tin đa dạng, đa chiều của người dùng Nhưng về bản chất lưu trữ dữ liệu, DM vẫn là một tập các bảng dữ liệu quan hệ (các bảng với 2 chiều dòng và cột), để đưa ra được các báo cáo đa chiều, cần thực hiện các câu lệnh truy vấn (SQL) để join các bảng với nhau
Để tạo sự thuận tiện và chủ động cho người dùng cuối, đồng thời tăng tốc độ đáp ứng các nhu cầu thông tin, cần tạo thêm một lớp dữ liệu nữa ở dạng tính toán sẵn và gần gũi hơn với nhu cầu thông tin của người dùng, lớp dữ liệu đó chính là OLAP
OLAP là tầng dữ liệu phía trên các DM, có cấu trúc lưu trữ đặc biệt (không
sử dụng các bảng quan hệ thông thường) để lưu trữ các dữ liệu đa chiều ở dạng tính toán sẵn, các dữ liệu này rất gần với nhu cầu thông tin của người dùng
Với OLAP, người dùng chỉ cần chọn và lấy ra các thông tin mình cần (các dimension, các measure) để thực hiện việc báo cáo và phân tích vì các thông tin này
đã được tính toán sẵn trong OLAP
OLAP được tổ chức thành các OLAP cube (Khối dữ liệu đa chiều), mỗi OLAP cube phục vụ một nhóm nhu cầu thông tin của người dùng Tương ứng với một chủ đề thông tin (DM), có thể tạo ra nhiều OLAP cube Ngoài ra, tùy thuộc nhu cầu phân tích thông tin, cũng có thể tạo ra một OLAP cube từ các DM khác nhau
Trang 39Căn cứ vào việc phân tích các nhu cầu thông tin của người dùng, căn cứ bản thiết kế các DM, thiết kế tầng dữ liệu OLAP theo các bước sau:
- Xác định danh sách các OLAP cube dựa trên các nhóm nhu cầu thông tin
đã biết
- Thiết kế từng OLAP cube:
+ Cấu trúc của cube: Các Measure, các Dimension
+ Thủ tục chuyển dữ liệu từ DM vào cube
f Tầng khai thác và phân tích thông tin
Tầng khai thác và phân tích thông tin là môi trường thuận tiện và an toàn để người dùng tương tác với hệ thống, môi trường này bao gồm các thành phần sau:
- Lớp dữ liệu tham chiếu:
+ Là một cấu trúc lưu trữ xác định mối quan hệ tham chiếu giữa các thuật ngữ nghiệp vụ (của người dùng cuối) với các đối tượng dữ liệu tin học (các bảng, các trường)
+ Đóng vai trò cầu nối để người dùng cuối có thể khai thác được dữ liệu của các CSDL trong DW bằng cách lựa chọn và kéo thả các thông tin nghiệp vụ mình cần thay vì việc viết các câu lệnh truy vấn SQL
- Lớp thông tin kết quả: Là tập hợp các file kết quả báo cáo, phân tích,… của người dùng và được lưu tại các thư mục xác định
- Các công cụ khai thác và phân tích thông tin: Là các chương trình ứng dụng
để người dùng phân tích, lập báo cáo và chia sẻ các thông tin
- Cổng thông tin: Là giao diện để người dùng truy cập hệ thống và lấy các thông tin kết quả Ví dụ: web portal, ms office,…
2.2 Xây dựng luồng ETL (Extract - Transform - Load)
2.2.1 Khái niệm ETL
Là nền tảng của kho dữ liệu Một tiến trình được thiết kế cho việc lấy dữ liệu
từ nhiều nguồn dữ liệu khác nhau, chuyển đổi dữ liệu nhằm tích hợp những nguồn
dữ liệu này Dữ liệu sau chuyển đổi được đưa vào kho dữ liệu phục vụ mục đích phát triển ứng dụng hay phục vụ các mục đích kho dữ liệu [1, tr.xii]
Trang 402.2.2 Kiến trúc ETL
Hình 2.14: Các thành phần của ETL [6]
Trích xuất (Extract): Dữ liệu từ rất nhiều nguồn khác nhau và có thể có rất
nhiều cấu trúc dữ liệu khác nhau như nhiều loại cơ sở dữ liệu, từ tệp dữ liệu excel
hay từ tệp dữ liệu thô Vì thế nhiệm vụ chính của bước này là trích xuất dữ liệu từ
hệ thống nguồn để xử lý Đây là công đoạn khai thác và đưa dữ liệu từ các nguồn
vào cơ sở dữ liệu trung chuyển (các DSA nguồn), chưa xử lý gì đối với dữ liệu
Chuyển đổi (Transform): Là quá trình rất phức tạp dùng để chuyển đổi dữ liệu
nguồn một mô hình khác phù hợp và chuyển vào cơ sở dữ liệu đích Ở bước này sẽ
phải sử dụng các phép chuyển đổi:
Chọn các cột dữ liệu phù hợp (chỉ chọn các cột cần thiết )
Chuyển đổi dữ liệu
Tạo ra các trường dữ liệu cần thiết mới
Lọc dữ liệu theo chủ đề
Sắp xếp dữ liệu theo các tiêu chí lưu trữ
Thực hiện các phép tổng hợp dữ liệu từ dữ liệu nguồn
Tạo ra các giá trị mới
Tìm kiếm hay so sánh dữ liệu