Nghiên cứu và xây dựng kho dữ liệu sản phẩm tại Ngân hàng TMCP Đại Dương dựa trên nền tảng hệ quản trị CSDL Oracle 10g

Để đảm bảo chất lượng và trong khẳ năng cho phép đề tài xin giới hạn vào nhưng phần cốt lõi của kiến trúc kho dữ liệu trong lĩnh vực ngân hàng trên nền tảng công nghệ Oracle gồm:  Tìm h

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN ĐỨC BÌNH

NGHIÊN CỨU VÀ XÂY DỰNG KHO DỮ LIỆU SẢN PHẨM TẠI NGÂN HÀNG TMCP ĐẠI DƯƠNG TRÊN NỀN TẢNG HỆ QUẢN TRỊ CSDL ORACLE 10G

LUẬN VĂN THẠC SĨ

Hà Nội - 2014

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN ĐỨC BÌNH

NGHIÊN CỨU VÀ XÂY DỰNG KHO DỮ LIỆU SẢN PHẨM TẠI NGÂN HÀNG TMCP ĐẠI DƯƠNG TRÊN NỀN TẢNG HỆ QUẢN TRỊ CSDL ORACLE 10G

Ngành: Công nghệ thông tin Chuyên ngành: Công nghệ phần mềm

Mã số: 60.48.10

LUẬN VĂN THẠC SĨ

Cán bộ hướng dẫn khoa học: GS.TS Vũ Đức Thi

Hà Nội - 2014

LỜI CẢM ƠN

Trước hết, em xin gửi lời cảm ơn trân trọng nhất tới GS.TS Vũ Đức Thi, Viện CNTT, Viện KH&CN VN, người đã trực tiếp hướng dẫn, giúp em định hướng , tận tình chỉ bảo và hỗ trợ em trong suốt quá trình nghiên cứu và thực hiện luận văn

Em xin gửi lời cám ơn tới các thầy cô trong khoa Công Nghệ Thông Tin cùng toàn thể các thầy cô trường Đại học Công Nghệ đã tận tình dạy dỗ và dìu dắt chúng em trong suốt thời gian học tập tại trường

Em xin gửi lời cảm ơn tới Ngân hàng TMCP Đại Dương đã tạo môi trường để em nghiên cứu và cài đặt thử nghiệm hệ thống thành công

Cuối cùng em xin gửi lời cám ơn tới gia đình, bạn bè, những người luôn luôn bên cạnh và tạo mọi điều kiện thuận lợi nhất để em có thể hoàn thành tốt luận văn

Hà Nội, tháng 10 năm 2014 Sinh viên : Nguyễn Đức Bình Lớp K18 Khoa Công Nghệ Thông tin, Trường Đại Học Công Nghệ

LỜI CAM ĐOAN

Tôi xin cam đoan kết quả đạt được trong luận văn là sản phẩm nghiên cứu, tìm hiểu của riêng cá nhân tôi Trong toàn bộ nội dung của luận văn, những điều được trình bày hoặc là của cá nhân tôi hoặc là được ổng hợp từ nhiều nguồn tài liệu Tất cả các tài liệu tham khảo đều có xuất xứ rõ ràng và được trích dẫn hợp pháp

Tôi xin hoàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định cho lời cam đoan của mình

MỤC LỤC

PHẦN MỞ ĐẦU 1

CHƯƠNG 1: LÝ THUYẾT KHO DỮ LIỆU 4

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

1.1.1 Lịch sử phát triển của kho dữ liệu: 4

1.1.2 Định nghĩa 5

1.2 Đặc trưng kho dữ liệu 5

1.2.1 Tính bền vững 5

1.2.2 Biến thời gian 5

1.2.3 Hướng chủ đề 6

1.2.4 Tính tích hợp 7

1.3 Sự khác nhau giữa hệ thống OLTP và kho dữ liệu 7

1.4 Kiến trúc kho dữ liệu 9

1.4.1 Kiến trúc kho dữ liệu cơ bản 9

1.4.2 Kiến trúc kho dữ liệu với vùng đệm 9

1.4.3 Kiến trúc kho dữ liệu với vùng đệm và kho dữ liệu cục bộ 10

1.5 Thiết kế kho dữ liệu 10

1.5.1 Thiết kế logic và thiết kế vật lý trong kho dữ liệu 10

1.5.2 Thiết kế logic 11

1.6 Lược kho dữ liệu 12

1.6.1 Lược đồ sao 12

1.6.2 Lược đồ bông tuyết 12

1.6.3 So sánh lược đồ sao và bông tuyết 13

1.6.4 Lược đồ khác 14

1.7 Thiêt kế vật lý 14

1.7.1 Chuyển thiết kế logic thành thiết kế vật lý 14

1.7.2 Tạo thiết kế vật lý 14

1.8 Đối tượng trong kho dữ liệu 15

1.8.1 Sự kiện và bảng sự kiện 15

1.8.2 Chiều và bảng chiều 15

1.8.3 Khối dữ liệu 15

1.9 Chiến lược xây dựng kho dữ liệu: 18

1.9.1 Chiến lược từ trên xuống 18

1.9.2 Chiến lược từ dưới lên 19

1.9.3 So sánh 02 phương pháp thiết kế 20

1.9.4 Chiết xuất dữ liệu 22

1.9.5 Chuyển đổi dữ liệu 22

1.9.6 Nạp dữ liệu 23

1.10 Kho dữ liệu cục bộ 28

CHƯƠNG 2: XÂY DƯNG KHO DỮ LIỆU SẢN PHẨM 30

2.1 Giới thiệu 30

2.1.1 Ngân hàng TMCP Đại Dương 30

2.1.2 Hệ thống CORE BANKING 31

2.1.3 Thực trạng hệ thống 33

2.2 Xây dựng kho dữ liệu 34

2.2.1 Đặc tả các thông tin cơ bản của dự án: 34

2.2.2 Phân tích nghiệp vụ 35

2.2.3 Xây dựng kho dữ liệu trung tâm 39

2.2.4 Xây dựng kho dữ liệu cục bộ 47

CHƯƠNG 3: CÀI ĐẶT, THỬ NGHIỆM 49

3.1 Giới thiệu về công cụ Oracle Warehouse Builder 49

3.2 Môi trường cài đặt và các thành phần: 50

3.3 Cài đặt với Oracle Warehouse Builder 50

3.3.1 Xây dựng bảng chiều 50

3.3.2 Xây dựng cube 52

3.3.3 Thiết lập nguồn, chiết xuất và xử lý dữ liệu 53

3.3.4 Triển khai 55

3.3.4 Nạp dữ liệu vào kho dữ liệu 56

3.4 Báo cáo dựa trên kho dữ liệu 50

KẾT LUẬN VÀ ĐỊNH HƯỚNG 60

TÀI LIỆU THAM KHẢO 61

Danh mục các ký hiệu, chữ viết tắt

CNTT Information Technology Công nghệ thông tin

DDL Data Define Language Ngôn ngữ định nghĩa dữ liệu OWB Oracle Warehouse Build Công cụ xây dụng kho dữ liệu DBMS Database Management System Hệ quản trị cơ sở dữ liệu

DSS Decision Support System Hỗ trợ quyết định

ETL

Extraction, Transportation, Loading Trích suất, Trao đổi, Tải

DANH MỤC HÌNH VẼ ĐỒ THỊ

Hinh 1 1: Sơ đồ luồng dữ liệu 4

Hinh 1 2: Tính bền vững của DWH 5

Hinh 1 3: Đặc trưng biến thời gian 6

Hinh 1 4: Đặc trưng hướng chủ đề 6

Hinh 1 5: Đặc trưng tính tích hợp 7

Hinh 1 6: So sánh OLTP với DWH 8

Hinh 1 7: Kiến trúc kho dữ liệu cơ bản 9

Hinh 1 8: Kiến trúc kho dữ liệu vùng đệm 9

Hinh 1 9: Kiến trúc DWH với vùng đệm, DM 10

Hinh 1 10: Lược đồ ngôi sao 12

Hinh 1 12: So sánh 2 lược đồ bông tuyết và ngôi sao 13

Hinh 1 11: Lược đồ hình bông tuyết 13

Hinh 1 13: So sánh thiết kế logic với thiết kế vật lý 14

Hinh 1 14: Khối dữ liệu 3 chiều 16

Hinh 1 15: Phép cắt dữ liệu 17

Hinh 1 16: Phép khoan dữ liệu 17

Hinh 1 17: Phép quay dữ liệu 18

Hinh 1 18: Chiến lược xây dựng DWH 18

Hinh 1 19: Kiển trúc Inmon 19

Hinh 1 20: Kiến trúc Kimball 19

Hinh 1 21: So sánh 2 cách Kimball và Inmon 21

Hinh 1 22: Quá trình ETL 21

Hinh 1 23: Cấu trúc chiều cơ bản 23

Hinh 1 24: Chiều thời gian 25

Hinh 1 25: Quá trình hợp nhất các chiều phụ thuộc 26

Hinh 1 26: Kiến trúc kho dữ liệu cục bộ độc lập 28

Hinh 1 27: Kiến trúc Kho dữ liệu cục bộ phụ thuộc 29

Hình 2 1: Giới thiệu Ocean Bank 30

Hình 2 2: Mô tả core banking 32

Hình 2 3: Sơ đồ hệ thống dữ liệu tại Ocean Bank 33

Hình 2 4: Luồng nghiệp vụ huy động 35

Hình 2 5: Luồng nghiệp vụ cho vay 35

Hình 2 6: Mô hình thực thể của nghiệp vụ huy động & cho vay trên core 37

Hình 2 7: Mô hình CSDL quan hệ của nghiệp vụ huy động trên core 38

Hình 2 8: Kiến trúc kho dữ liệu Ocean Bank 40

Hình 2 9: Mô hình giải pháp luồng dữ liệu 41

Hình 2 10: Bảng danh sách thực thể dữ liệu cho kho và nguồn 41

Hình 2 11: Bảng danh sách dữ liệu tham khảo đẩy vào kho dữ liệu 42

Hình 2 12: Bảng danh sách dữ liệu chiều thay đổi theo thời gian 42

Hình 2 13: Thêm thành phần thời gian vào dữ liệu 43

Hình 2 14: Bảng dữ liệu chính trong kho 43

Hình 2 15: Tạo thêm dữ liệu tính toán, tổng hợp 45

Hình 2 16: Danh sách các chiều và phân cấp 45

Hình 2 17: Thiết kế CSDL của kho dữ liệu 47

Hình 2 18: Lược đồ khối dữ liệu cục bộ về huy động 48

Hình 3 1: Các thành phần của OWB 49

Hình 3 2: Bảng chiều thời gian 51

Hình 3 3: Phân cấp bảng chiều thời gian 51

Hình 3 4: Bảng chiều loại hình tiền gửi 51

Hình 3 5: Phân cấp chiều loại hình tiền gửi 52

Hình 3 6: Bảng chiều khách hàng 52

Hình 3 7: Phân cấp bảng chiều khách hàng 52

Hình 3 8: Khối cube huy động 53

Hình 3 9: Đơn vị đo Cube 53

Hình 3 10: Chiều của cube 53

Hình 3 11: Thiết lập nguồn dữ liệu 54

Hình 3 12: Chiết xuất và xử lý dữ liệu chiều thời gian 54

Hình 3 13: Chiết xuất và xử lý dữ liệu chiều loại hình tiền gửi 54

Hình 3 14: Chiết xuất và xử lý chiều phân loại khách hàng 54

Hình 3 15: Giao diện triển khai thiết kế logic 55

Hình 3 16: Giao diện thiết kế kịch bản nạp dữ liệu vào kho 56

Hình 3 17: Thông tin về tiến trình nạp dữ liệu 56

Hình 3 18: Mã nguồn nạp dữ liệu vào kho 57

Hình 3 19: Dữ liệuchiều loại hình tiền gửi 57

Hình 3 20: Dữ liệu cube 58

PHẦN MỞ ĐẦU

1 ĐẶT VẤN ĐỀ

Hệ thống giao dịch Ngân hàng là một hệ thống với số lượng giao dịch cực lớn hàng ngày được thực hiện trải dài trên các phần mềm nghiệp vụ như core bank, Internet Banking, Mobi Banking, Smart Banking… Qua đó tại ra một khối dữ liệu khổng lồ lưu trữ trải dài trên nhiều hệ thống nghiệp vụ và không nhất quán Gây khó khăn việc xử lý và khai thác thông tin hữu ích một cách nhanh chóng để giúp nhà quản trị, lãnh đạo đưa ra các quyết sách đúng đắn, kịp thời và hiệu quả cho cơ quản, tổ chức của mình Ví dụ: thông qua việc nghiên cứu thói quen mua sắm của các khách hàng thì eBay, Amazon có biết chính xác các sản phẩm bạn muốn mua là gì để đưa ra gợi ý Điều ngày giúp cho khách hàng tiết kiệm thời gian, doanh nghiệp bán được nhiều hàng hơn

Với hệ thống dữ liệu tổ chức dữ liệu tốt có thể giúp doanh nghiệp xây dựng các mô hình dự báo như một công ty viễn thông có thể dự đoán tốt hơn

về việc khách hàng rời mạng Hay Wal-Mal có thể dự đoán sản phẩm nào sẽ được bán ra Đặc biệt với lĩnh vực dịch vụ có số lượng lớn giao dịch như tài chính, hàng không, viễn thông… nhu cầu về việc tổ chức dữ liệu lớn để đáp ứng yêu cầu phân tích dự báo là vô cùng cần thiết

Cuộc khủng hoảng kinh tế năm 2010 đã khiến các tổ chức tài chính phải nhìn nhận lại định hướng phát triển bền vững thông qua công tác dự báo nhằm quản lỷ rủi ro mức thấp nhất và nâng cao chất lượng phục vụ khách hàng dựa trên việc nâng cấp hệ thống phần mềm hoạt động ôn định, dựa trên nhu cầu của khách hàng Hệ thống nghiệp vụ liên tục bị quá tải phần lớn là

do tài nguyên dành cho việc thực hiện các báo cáo, các báo cáo nhằm nghiên cứu nhu cầu khách hàng không thể thực hiện hoặc mất quá nhiều thời gian

Để giải quyết vấn đề trên, tôi đề xuất xây dựng kho dữ liệu theo phương pháp tiếp cận phù hợp để giải quyết bái toán Kho dữ liệu sẽ là nền tảng cho việc triển khai hệ thống báo cáo phân tích tách biệt với hệ thống giao dịch nghiệp vụ

2 Mục tiêu luận văn

Trên cơ sở tính cấp thiết và tính thực tiễn của việc triể khai xây dựng một hệ thống phục vụ báo cáo phân tích tách biệt với hệ thống giao dịch nghiệp vụ Tôi đã nghiên cứu và tìm hiểu, chọn đề tài luận văn là “Nghiên cứu và xây dựng kho dữ liệu sản phẩm tại Ngân hàng TMCP Đại Dương dựa trên nền tảng hệ quản trị CSDL Oracle 10g”

Đây là một vấn đề lớn và khó khăn, tôi bước đầu đã tìm hiểu và làm chủ được kiến thức về kiến trúc kho dữ liệu Mục đích của luận văn là nghiên cứu

lý thuyết và áp dụng kiến thức theo cách phù hợp để tiến hành xây dựng kho

dữ liệu tại Ngân hàng TMCP Đại Dương đáp ứng nhu cầu sử dụng hiện tại và làm nền tảng cho việc triển khai hệ thống Business Intelligence

3 Phương pháp và phạm vi nghiên cứu luận văn

Đây là đề tài lớn mang tính áp dụng công nghệ và tính đặc thù của từng lĩnh vực khi triển khai Để đảm bảo chất lượng và trong khẳ năng cho phép

đề tài xin giới hạn vào nhưng phần cốt lõi của kiến trúc kho dữ liệu trong lĩnh vực ngân hàng trên nền tảng công nghệ Oracle gồm:

 Tìm hiểu về kiến trúc kho dữ liệu và tính cần thiết cũng như sự khác biệt so với hệ thống giao dịch nghiệp vụ

 Tìm hiểu về giải pháp kiến trúc kho dữ liệu của nhà cung cấp giải pháp Oracle và các công nghệ hỗ trợ việc phân tích dữ liệu nhằm triết xuất thông tin: Oracle warehouse build, Oracle Business Intelligence Discover

 Nghiên cứu giải pháp xây dựng kho dữ liệu phù hợp với thực trạng về nhân lực, chi phí tại Ngân hàng TMCP Đại Dương

 Tìm hiểu các kiến thức cơ bản về nghiệp vụ ngân hàng thương mại và cách tổ chức dữ liệu tại hệ thống giao dịch nghiệp vụ tại Ngân hàng TMCP Đại Dương

 Tìm hiểu về nhu cầu dữ liệu tri thức từ Ban Điều hành để tổ chức dữ liệu phù hợp

 Xây dựng kho dữ liệu với chủ đề sản phẩm dựa trên nền tảng công nghệ Oracle và thiết lập công cụ khai thác dữ liệu từ kho dữ liệu để chứng mình tính khả thi và đáp ứng yêu cầu của kho dữ liệu đã xây dựng

4 Nội dung luận văn

Luận văn được thực hiện dựa trên nhu cầu thực tế tại Ngân hàng TMCP Ocean Bank Và dựa trên quá tính tìm hiểu thực tế nhu cầu và nghiên cứu, đánh giá các giải pháp công nghệ Luận được tổ chức thành các nội dung chính như sau:

Mở đầu: Đặt vấn đề, mục tiêu và phạm vi nghiên cứu của luận văn

Chương 1: Cơ sở lý thuyết - Trình báy về kiến trúc kho dữ liệu gồm các khái niêm cơ bản: Định nghĩa kho dữ liệu, kiến truc kho dữ liệu, đặc trưng kho dữ liệu phương pháp xây dựng kho dữ liệu, phương pháp khai thác dữ liệu theo

mô hình OLAP

Chương 2: Xây dựng giải pháp kho dữ liệu - Nghiên cứu thực trạng hệ thống

và giải pháp xây dựng kho dữ liệu sản phẩm phù hợp với thực trạng tại Ngân hàng TMCP Đại Dương

Chương 3: Cài đặt, thử nghiệm và đánh giá – Cài đặt kho dữ liệu với công

cụ hỗ trợ Oracle Warehouse Build trên nền tảng Oracle 10g

Kết luận, định hướng: Tổng kết lại kết quả luận văn đã đạt được, kinh nghiệm từ được trong quá trình thực hiện luận văn Và đưa định hướng phát triển trong tương lai

CHƯƠNG 1: LÝ THUYẾT KHO DỮ LIỆU 1.1 Tổng quan về kho dữ liệu

1.1.1 Lịch sử phát triển của kho dữ liệu:

Kho dữ liệu đã được phát triển vào cuối những năm 1980 để đáp ứng nhu cầu ngày càng tăng về phân tích dữ liệu và quản lý thông tin nhưng không thể đạt được bởi hệ thống OLTP Do hệ thống OLTP được thiết kế để tối ưu hóa cho giao dịch nghiệp vụ, số lượng dữ liệu giao dịch đã được phát triển một cách nhanh chóng giữa các phòng ban trong một tổ chức nên việc thực hiện tích hợp dữ liệu khó khăn hơn Điều này tạo ra khó khăn cho việc báo cáo (tích hợp & phân tích dữ liệu)

Kết quả là, một hệ thống riêng được gọi là kho dữ liệuđược thiết kế để giải quyết vấn đề này Kho dữ liệu chứa các dữ liệu được tập hợp từ nhiều nguồn khác nhau như dữ liệu quan hệ, các tập tin phẳng, bảng tính, dữ liệu

từ các nguồn bên ngoài tổ chức… Và được tổ chức trong một cách tối ưu hóa cho mục đích báo cáo Với nền tảng kho dữ liệu được tổ chức tốt sẽ là cơ

sở để triển khai các công cụ báo cáo thân thiện với người sử dụng

Hinh 1 1: Sơ đồ luồng dữ liệu

1.1.2 Định nghĩa

Có nhiều định nghĩa kho dữ liệu những chúng đều có một số điểm chung giống nhau Theo Bill Inmon - người được biết đến như là cha đẻ của kho dữ liệu, kho dữ liệu được quy định như sau:

"Data warehoue là một tập hợp dữ liệu tương đối ổn định (nonvolatile) ,

liên kết với thời gian (time-variant), được tích hợp (integrated) theo một chủ

đề (subject-oriented) nhằm hỗ trợ quá trình tạo quyết định về mặt quản lý (Support management’s decision making process)"

1.2 Đặc trưng kho dữ liệu

1.2.1 Tính bền vững

Khi thông tin đã đưa vào kho dữ liệu, dữ liệu không nên thay đổi Điều này là hợp lý vì mục đích của một kho dữ liệu là để cho phép ta phân tích những gì đã xảy ra Dữ liệu đưa vào kho dữ liệu chỉ để đọc, việc sửa dữ liệu hầu như không được tiến hành vì điều này có thể dẫn đến phá vỡ sự toàn vẹn Thông thường người ta không yêu cầu giảm thời gian đưa dữ liệu vào kho dữ liệu xuống mức tối thiểu, nhưng cần tối ưu hoá kho dữ liệu sao cho các truy vấn phục vụ cho việc phân tích đạt tốc độ tốt nhất Các sơ đồ quan hệ sẽ tạo ra các Index hợp lý cũng như tạo ra sẵn các dữ liệu kết hợp

Hinh 1 2: Tính bền vững của DWH.

1.2.2 Biến thời gian

Yêu cầu quan trọng cho kho dữ liệu là phạm vi về thời gian dài hơn so với các hệ thống tác nghiệp Cơ sở dữ liệu tác nghiệp: dữ liệu có giá trị hiện thời Còn dữ liệu của kho dữ liệu: cung cấp thông tin lịch sử (ví dụ như, 5-10 năm trước) Và yếu tố thời gian được lưu trữ trong CSDL

Hinh 1 3: Đặc trưng biến thời gian.

1.2.3 Hướng chủ đề

Dữ liệu được tổ chức theo các đối tượng chính hoặc các quá trình kinh doanh Ví dụ phổ biến của các dữ liệu theo định hướng đối tượng là khách hàng, sản phẩm, nhà cung cấp và giao dịch bán… Tập trung vào việc mô hình hóa và phân tích dữ liệu nhằm hỗ trợ đưa ra quyết định, mà không tập trung vào các hoạt động hay các xử lý giao dịch hàng ngày

Hinh 1 4: Đặc trưng hướng chủ đề.

1.2.4 Tính tích hợp

Dữ liệu từ nhiều nguồn khác nhau như từ của các phòng ban trong tổ chức, từ các nguồn bên ngoài Và nguồn dữ liệu khác nhau có thể có những cách khác nhau để xác định một đối tượng cụ thể Tuy nhiên, trong một kho

dữ liệu chỉ có một định nghĩa của sản phẩm Điều này đạt được bằng cách sử dụng giải quyết xung đột về cách xác định đối tượng trong kho dữ liệu Và khi chúng ta đạt được điều này, chúng ta nói rằng dữ liệu được tích hợp

Hinh 1 5: Đặc trưng tính tích hợp.

1.3 Sự khác nhau giữa hệ thống OLTP và kho dữ liệu

Về cơ bản hệ thống OLTP và kho dữ liệu có một điểm khác biệt chính

đó là kho dư liệu không được tổ chức theo dạng chuẩn 3NF Nhưng 3NF lại

là chuẩn cho hầu hết các hệ thống OLTP

Sự khác nhau giữa hệ OLTP và kho dữ liệu

Chỉ mục Ít: tối ưu cho giao dịch Nhiều: Tối ưu cho báo cáo

Hinh 1 6: So sánh OLTP với DWH.

Kho dữ liệu và các hệ thống OLTP có những yêu cầu rất khác nhau Dưới đây là một số ví dụ về sự khác biệt giữa các kho dữ liệu điển hình và các hệ thống OLTP

 Khối lượng công việc: Kho dữ liệu được thiết kế để phù hợp truy vấn đặc

biệt và phân tích dữ liệu Nên khối lượng dữ liệu cần được xử lý không biết trước được có thể rất nhỏ hoặc rất lớn Do đó, kho phải được tối ưu hóa để thực hiện tốt cho một loạt các thể truy vấn và các hoạt động phân tích Hệ thống OLTP thiết kế hỗ trợ các các giao dịch đã được định nghĩa trước

 Việc chỉnh sửa dữ liệu: kho dữ liệu được cập nhật một cách thường xuyên

bởi quá trình ETL (chạy đêm hoặc hàng tuần) sử dụng kỹ thuật biến đổi

dữ liệu với số lượng lớn Người sử dụng cuối không trực tiếp cập nhập kho dữ liệu trừ một số trường hợp đặc biệt như khai phá dữ liệu… Ngược lại, hệ thống OLTP thì người sử dụng thường xuyên tạo, cập nhập dữ liệu vào cơ sở dữ liệu Cơ sở dữ liệu OLTP là luôn được cập nhật và phản ánh tình trạng hiện tại của mỗi giao dịch kinh doanh

 Mô hình thiết kế: Kho dữ liệu sử dụng mô hình chiều (như mô hình sao)

để tối ưu hóa việc truy vấn và phân tích dữ liệu OLTP sử dụng mô hình thiết kế theo chuẩn (như 3NF) để tối ưu hóa các hoạt động câp nhập/thêm/xóa và để đảm bảo tính nhất quán của dữ liệu

 Hoạt động thông thường: Dữ liệu hoạt động thông thường kho dữ liệu có

thể là hàng nghìn hoặc hàng triệu bản ghi OLTP truy cập thông thường chỉ liên quan đến một số lượng ít bản ghi

 Dữ liệu lịch sử: Kho dữ liệu có thể dữ liệu với thời gian dài như 5 năm, 10

năm… nhằm mục đích hỗ trợ quá trình phân tích OLTP chỉ lưu dữ liệu trong thời gian ngắn Đó là những dữ liệu cần thiết để

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

1.4.1 Kiến trúc kho dữ liệu cơ bản

Với kiến trúc cơ bản, người sử dụng cuối cùng nhận được dữ liệu từ các hệ thống nguồn thông qua kho dữ liệu

Hinh 1 7: Kiến trúc kho dữ liệu cơ bản.

Siêu dữ liệu và dữ liệu thô của một hệ thống OLTP truyền thống là sẵn có Tóm lược rất có giá trị trong kho dữliệu, vì chúng tính toán trước các hoạt động lâu dài như truy vấn kho dữ liệu điển hìnhđể lấy thông tin về lượng hàng được bán trong tháng

1.4.2 Kiến trúc kho dữ liệu với vùng đệm

Hinh 1 8: Kiến trúc kho dữ liệu vùng đệm.

Với kiến trúc này, cần làm sạch và xử lý dữ liệu hoạt động trước khi đưa nó vào kho dữ liệu, mặc dù hầu hết kho dữ liệu sử dụng một vùng trung gian thay thế Một vùng trung gian sẽ làm đon giản hoá việc quản lý kho dữ liệu chung

1.4.3 Kiến trúc kho dữ liệu với vùng đệm và kho dữ liệu cục bộ

Mặc dù kiến trúc trong hình 7 là khá phổ biến, tùy theo yêu cầu ta có thể kiếntrúc kho dữ liệu cho các nhóm khác nhau bên trong của tổ chức Điều này có thế thực hiện bằng cách thêm các kho dữ liệu cục bộ, đó là các hệ thống được thiết kế cho một phạm vi cụ thể của doanh nghiệp Hình 8 minh hoạ một ví dụ nơi mua, bán hàng, và hàng tồn kho được tách ra Trong ví dụ này, một nhà phân tích tài chính có thể muốn phân tích dữ liệu lịch sử cho mua và bán

Hinh 1 9: Kiến trúc DWH với vùng đệm, DM.

1.5 Thiết kế kho dữ liệu

1.5.1 Thiết kế logic và thiết kế vật lý trong kho dữ liệu

Để xây dựng một kho dữ liệu thì cần xác định các yêu cầu kinh doanh

và thống nhất phạm vi ứng dụng để từ đó đưa ra một bản thiết kế khái niệm Bây giờ cần phải chuyển thiết kế khái niệm thành một hệ thống chuyển giao

Để làm như vậy, cần tạo ra các thiết kế logic và thiết kế vật lý cho các kho dữ liệu Cần xác định:

 Nội dung dữ liệu cụ thể

 Mối quan hệ bên trong và giữa các nhóm dữ liệu

 Môi trường hệ thống hỗ trợ kho dữ liệu

 Quá trình biến đổi dữ liệu cần thiết

 Tần suất mà dữ liệu được làm mới

Thiết kế logic xem xét các mối quan hệ logic giữa các chủ thể Thiết

kế vật lýxem xét cách thức hiệu quả nhất của việc lưu trữ và gọi ra các đối tượng, cũng như xử lý chúng từ một chuyển dịch và quan điểm sao lưu, phục hồi

Thiết kế hướng tới các nhu cầu của người dùng cuối Người dùng cuối thường muốn thực hiện phân tích và xem xét dữ liệu tổng hợp, hơn là giao

tác riêng lẻ Tuy nhiên, người dùng cuối có thể không biết những gì họ cần cho đến khi họ nhìn thấy nó Ngoài ra, một thiết kế được lên kế hoạch chu đáo có tính đến sự tăng trưởng và thay đổi khi nhu cầu của người dùng thay đổi và tiến hóa Với thiết kế logic, tập trung vào các yêu cầu thông tin và lưu các chi tiết thực thi cho sau này

1.5.2 Thiết kế logic

Một thiết kế logic là trừu tượng và dựa trên các khái niệm Ta không

đề cập tới những chi tiết cài đặt vật lý Ta chỉ đề cập tới việc xác định những loại thông tin mà ta cần Một kỹ thuật ta cần sử dụng làm mô hình cho các yêu cầu thông tin logic của tổ chức là mô hình thực thể quan hệ Mô hình thực thể quan hệ liên quan đến việc xác định những thứ quan trọng (thực thể), các tính chất của những thuộc tính, và làm thế nào chúng liên hệ được với nhau (các mối quan hệ)

Quá trình thiết kế logic liên quan đến việc sắp xếp dữ liệu thành một chuỗi các mối quan hệ logic được gọi là các thực thể và thuộc tính Một thực thể đại diện cho một mảng của thông tin Trong cơ sở dữ liệu quan hệ, một thực thể thường ánh xạ tới một bảng Một thuộc tính là một thành phần của một thực thể giúp xác định tính duy nhất của thực thể Trong cơ sở dữ liệu quan hệ, một thuộc tính ánh xạ tới một cột

Để chắc chắn rằng dữ liệu ta có là nhất quán, ta cần phải sử dụng định danh duy nhất Một định danh duy nhất là một cái gì đó ta thêm vào bảng để

ta có thể phân biệt các phần tử giống nhau khi nó xuất hiện ở những nơi khác nhau Trong một thiết kế vật lý, đó thường là một chính khoá

Trong khi sơ đồ thực thể quan hệ theo truyền thống được kết hợp với các mô hình chuẩn hóa mức cao như các ứng dụng OLTP, kỹ thuật vẫn còn hữu ích cho thiết kế kho dữ liệu ở dạng mô hình chiều Trong mô hình chiều, thay vì tìm cách phát hiện các đơn vị nguyên tử của thông tin (như các thực thể và các thuộc tính) và tất cả các mối quan hệ giữa chúng, ta xác định thông tin đó thuộc về một bảng sự kiện trung tâm và thông tin đó thuộc các bảng chiều liên kết của chúng Ta xác định các chủ thể nghiệp vụ hoặc các trường

dữ liệu, xác định các mối quan hệ giữa các chủ thể kinh doanh, và tên các thuộc tính cho mỗi chủ thể

Thiết kế logic kết quả nên là một tập thực thể và thuộc tính tương ứng với các bảng sự kiện và các bảng chiều và một mô hình của dữ liệu hoạt động

từ nguồn thành thông tin hướng chủ thể trong lược đồ kho dữ liệu đích

Ta có thể tạo ra những thiết kế logic sử dụng bút và giấy, hoặc sử dụng một công cụ thiết kế như Oracle Warehouse Builder, đặc biệt được thiết

kế để hỗ trợ cho mô hình hóa quá trình ETL; hoặc Oracle Designe, một công

cụ mô hình hóa mục đích chung

1.6 Lược kho dữ liệu

1.6.1 Lược đồ sao

Đây là lược đồ phổ biến nhất được sử dụng trong thiết kế chiều trong kho dữ liệu Có một bảng sự kiện tại trung tâm của lược đồ bao quanh bởi một số bảng chiều Trong lược đồ sao, kích thước liên quan đến nhóm lại với nhau như là các cột trong bảng kích thước và được sử dụng để lưu trữ dữ liệu của sự kiện được lưu trữ trong sự kiện (fact)

1.6.2 Lược đồ bông tuyết

Bao gồm một bảng sự kiện bao quanh bởi nhiều bảng chiều có thể được kết nối với bảng chiều khác thông qua mối quan hệ nhiều-một Lược đồ bông tuyết là một loại lược đồ sao, tuy nhiên nó là phức tạp hơn so với một lược đồ sao Lược đồ bông tuyết được thiết kế từ các lược đồ sao bằng cách tiếp tục chuẩn hóa các bảng kích thước để loại bỏ dữ liệu dư thừa Do đó trong lược đồ bông tuyết, thay vì có một bảng kích thước lớn kết nối với một bảng thực tế thì sẽ có một nhóm các bảng kích thước nhiều Giản đồ này cũng giúp tiết kiệm không gian tuy nhiên nó làm tăng số lượng của bảng kích thước

Hinh 1 10: Lược đồ ngôi sao

1.6.3 So sánh lược đồ sao và bông tuyết

Tùy theo thực tế mà ta lựa chọn lược đồ hình sao hay tuyết rơi Việc lựa chọn được cân nhắc giữa 2 yếu tố: thời gian đáp ứng truy vấn và mức độ kiểm soát tính chặt chẽ dữ liệu Lược đồ dạng tuyết rơi có thể thích hợp khi

dữ liệu bảng chiều trở nên quá lớn và nhiều thuộc tính

Tuy sự khác nhau thể hiện rất nhỏ về mặt lý thuyết nhưng khi thực hiện chúng trong thực tế có thể dẫn tới các kết quả khác hẳn nhau

Sau đây là một số so sánh cơ bản giữa 2 lược đồ

Lược đồ sao Lược đồ bông tuyết

Dễ hiểu

Dễ dàng hơn cho người dùng doanh nghiệp và các nhà phân tích truy vấn dữ liệu

Có thể là khó khăn hơn cho người dùng doanh nghiệp và các nhà phân tích do số lượng dữ liệu phải

xử lý Chiều bảng

Chỉ có một bảng chiều cho mỗi chiều Bảng chiều không theo chuẩn 3NF

Nhiều hơn 1 bảng chiều cho mỗi chiều Bảng chiều chuẩn hóa theo 3NF

Truy vấn phức tạp Các truy vấn là rất đơn giản

và dễ hiểu

Truy vấn phức tạp hơn do phải kết hợp các khóa ngoại giữa các bảng chiều

Hiệu suất truy vấn

Hiệu suất cao Engine có thể tối ưu hóa và tăng hiệu suất truy vấn

Có nhiều liên kết khóa ngoài nên thời gian truy vấn lâu hơn so với lược đồ sao

Không gian lưu trữ Tốn nhiều không gian lưu

trữ cho dữ liệu chiều

Tốn ít không gian lưu trữ dữ liệu chiều

Loại data

warehouse

Phù hợp với bất kỳ kho dữ liệu nào (lớn hoặc nhỏ)

Phù hợp với kho dữ liệu nhỏ, kho

dữ liệu cục bộ

Hinh 1 12: So sánh 2 lược đồ bông tuyết và ngôi sao.

Hinh 1 11: Lược đồ hình bông tuyết

1.6.4 Lược đồ khác

Một số lược đồ trong các môi trường kho dữ liệu sử dụng dạng chuẩn ba hơn là lược đồ hình sao Một lược đồ khác mà đôi khi hữu ích là lược đồ bông tuyết, đó là một lược đồ hình sao với các chiều chuẩn hóa trong một cấu trúc cây

1.7 Thiêt kế vật lý

1.7.1 Chuyển thiết kế logic thành thiết kế vật lý

Thiết kế logic là cái ta vẽ với bút và giấy hoặc thiết kế với Oracle Warehouse Builder hoặc Oracle Designer trước khi xây dựng kho dữ liệu Thiết kế vật lý là việc tạo cơ sở dữ liệu với các lệnh SQL Trong quá trình thiếtkế vật lý, ta chuyển đổi dữ liệu thu thập được trong pha thiết kế logic vào một mô tả của cấu trúc cơ sở dữ liệu vật lý

1.7.2 Tạo thiết kế vật lý

Trong pha thiết kế vật lý, ta xác định một mô hình cho kho dữ liệu gồm các thực thể, các thuộc tính, và các mối quan hệ Các thực thể được liên kết với nhau sử dụng các mối quan hệ Các thuộc tính được sử dụng để mô tả các thực thể Định danh duy nhất phân biệt giữa một trường hợp của một thực thể với các trường hợp khác

Hinh 1 13: So sánh thiết kế logic với thiết kế vật lý.

Trong thiết kế vật lý, ta phải chuyển các lược đồ thiết kế logic thành các cấu trúc dữ liệu thực tế Cụ thể , ta phải ánh xạ:

 Các thực thể tới các bảng

 Các mối quan hệ tới các ràng buộc khóa chính

 Các thuộc tính tới các cột

 Các định danh duy nhất tới các ràng buộc khóa duy nhất

Một khi ta đã chuyển thiết kế logic thành một thiết kế vật lý, ta sẽ cần phải tạo ra một số hoặc tất cả các cấu trúc sau:

 Các không gian bảng

có thể đo lường, đơn vị đo lường trong hoạt động của doanh nghiệp Mỗi DWH bao gồm một hoặc nhiều bảng sự kiện

Tính chất quan trọng nhất của bảng sự kiện là nó chứa các dữ kiện kiểu số, có thể tính tổng hay theo một công thức toán học nào đó để cung cấp thông tin mang tính lịch sử về quá trình tác nghiệp của đơn vị Mỗi bảng sự kiện chứa một chỉ mục nhiều phần, như các khóa ngoài, là các khóa chính tại các bảng chiều có liên quan và chứa các thuộc tính của những bản ghi sự việc

1.8.2 Chiều và bảng chiều

Chiều là một mặt khía cạnh nghiệp vụ mà đơn vị muốn dựa vào đó để xác định kết quả hoạt động Chiều thường được xác định từ các thực thể kinh doanh có tác động đến kết quả Sau một thời gian, có thể chiều này bị loại bỏ

vì mức độ tác động đến sự thay đổi hầu như không có, chiều mới có thể được phát hiện và ghi nhận

Một bảng chiều là bảng chứa các thuộc tính khác nhau có mục đích giải thích cho khóa chiều trong bảng dữ kiện Các thuộc tính này chỉ ra hoàn cảnh của thực thể mà sự kiện nghiệp vụ diễn ra Khác với bảng sự kiện, bảng chiều có chứa các thông tin có tính chất mô tả Giá trị các thuộc tính ở bảng chiều về sau thường được sử dụng để làm nhãn cho cột hay hàng thống kê 1.8.3 Khối dữ liệu

Một khối dữ liệu về cơ bản là có thể có N chiều (N-D) Những cạnh

của khối được gọi là các chiều (dimensions), mà đó là các mặt hoặc các thực thể ứng với những khía cạnh mà tổ chức muốn ghi nhận Mỗi chiều có thể kết hợp với một bảng chiều (dimension table) nhằm mô tả cho chiều đó Ví

dụ, một bảng chiều của Sản phẩm có thể chứa những thuộc tính như

MaSanpham, Mota, Tensanpham, LoaiSP,… mà có thể được chỉ ra bởi nhà quản trị hoặc các nhà phân tích dữ liệu Với những chiều không được phân

loại, như là Thời gian, hệ thống kho dữ liệu sẽ có thể tự động phát sinh tương

ứng với bảng chiều (dimension table) dựa trên loại dữ liệu Cần nói thêm

rằng, chiều Thời gian trên thực tế có ý nghĩa đặc biệt đối với việc hỗ trợ

quyết định cho các khuynh hướng phân tích Thường thì nó được mong muốn

có một vài tri thức gắn liền với lịch và những mặt khác của chiều thời gian Chúng ta có thể hình dung khối dữ liệu được tổ chức xung quanh một chủ đề được thể hiện bởi một bảng sự kiện (fact table) của nhiều độ đo số

học (là các đối tượng của phân tích) Ví dụ, một bảng sự kiện có thể chứa số

mặt hàng bán, thu nhập, tồn kho, ngân sách,… Mỗi độ đo số học phụ thuộc

vào một tập các chiều cung cấp ngữ cảnh cho độ đo đó Vì thế, các chiều kết

hợp với nhau được xem như xác định duy nhất độ đo, là một giá trị trong không gian đa chiều Ví dụ như một kết hợp của Sản phẩm, Thời gian, Thị

trường vào 1 thời điểm là một độ đo duy nhất so với các kết hợp khác

Hinh 1 14: Khối dữ liệu 3 chiều.

Vì vậy, nếu mỗi chiều chứa nhiều mức trừu tượng, dữ liệu có thể được xem từ nhiều khung nhìn linh động khác nhau Một số thao tác điển hình của khối dữ liệu như roll-up (tăng mức độ trừu tượng), drill-down (giảm mức độ trừu tượng hoặc tăng mức chi tiết), slice and dice (chọn và chiếu), và pivot (định hướng lại khung nhìn đa chiều của dữ liệu), cho phép tương tác truy vấn và phân tích dữ liệu rất tiện lợi Những thao tác đó được biết như Xử lý phân tích trực tuyến (On-Line Analytical Processing – OLAP)

Lát cắt (Slice - dice) Lát cắt là một “mặt phẳng” được chỉ ra bởi một tập các chiều nằm trong tập chiều của khối tại các giá trị cố định của các chiều còn lại

Hinh 1 15: Phép cắt dữ liệu.

Phép khoan dữ liệu (drill down): Phép khoan dữ liệu là một kỹ thuật đáp ứng nhu cầu khai thác thông tin thông qua các cấp độ của chiều từ mức

độ tổng thể tới các mức độ chi tiết hơn

Hinh 1 16: Phép khoan dữ liệu.

Phép cuốn dữ liệu (roll up): là phép toán ngược lại phép khoan, đó là

quá trình xem dữ liệu ở cấp độ càng ngày càng tổng quát hơn

Phép quay (Pivot): Là phép thay đổi vị trí các chiều trong thể hiện của báo cáo

Geography

Product

Item Type Category

All

City State Country

Month Year

Day Week

All

Quarter

Hinh 1 17: Phép quay dữ liệu.

1.9 Chiến lược xây dựng kho dữ liệu:

Có 03 cách chiến lược xây dựng kho dữ liệu

 Thực hiện từ trên xuống (Top-down): Xây dựng kho dữ liệu trung tâm trước Sau đó xây dựng các kho dữ liệu cục bộ

 Thực hiện từ dưới lên (Bottom-up): Xây dựng các kho dữ liệu cục bộ Sau đó tích hợp các kho dữ liệu cục bộ thành kho dữ liệu trung tâm

 Tổ hợp của 2 cách tiếp cận trên: Xây dựng kho dữ liệu trung tâm cho kho dữ liệu cụ bộ đầu tiên Sau đó xây dựng kho dữ liệu cục bộ thứ 2 và tích hợp với kho dữ liệu trung tâm

Hinh 1 18: Chiến lược xây dựng DWH.

1.9.1 Chiến lược từ trên xuống

Với phương pháp tiếp cận từ trên xuống, ta có kiến trúc điển hình theo Inmon Bill đề xuất Theo inmon Bill, kiến trúc kho dữ liệu doanh nghiệp thông tin được tập từ các hệ thống nguồn khác nhau được hợp nhất thành một kho lưu trữ trung tâm gọi là một kho dữ liệu doanh nghiệp Ứng dụng kho dữ liệu như các công cụ báo cáo, dữ liệu được truy vấn từ kho dữ liệu cục bộ thay truy vấn trực tiếp vào kho dữ liệu

LN

3

Hinh 1 19: Kiển trúc Inmon

1.9.2 Chiến lược từ dưới lên

Với chiến lược từ dưới lên tương ứng ta có kiến trúc điển hình do Ralph Kimball đề xuất về kho dữ liệu, dữ liệu được mang từ khắp các doanh nghiệp vào một địa điểm trung tâm được gọi là chiều kho dữ liệu Giống như kiến trúc của Inmon về kho dữ liệu, kho dữ liệu chiều cũng đã là trung tâm của doanh nghiệp Trong mô hình Kimball về kho dữ liệu kiến trúc, kho dữ liệu cục bộ là một tập hợp con của bảng liên kết với nhau bằng cách sử dụng lược đồ sao và bông tuyết Không giống như kiến trúc doanh nghiệp của Inmon về kho dữ liệu,

ở mô hình Kimball hệ thống phân tích có thể truy cập dữ liệu trực tiếp từ kho dữ liệu chiều

Hinh 1 20: Kiến trúc Kimball

1.9.3 So sánh 02 phương pháp thiết kế

Cả hai Kimball và Inmon cùng có một tính năng phổ biến là mỗi người có một kho tích hợp dữ liệu nguyên tử Trong kiến trúc Inmon của nó được gọi là kho dữ liệu doanh nghiệp và trong kiến trúc của Kimball, nó được gọi là kho dữ liệu chiều Cả hai kiến trúc có một sự tập hợp dữ liệu doanh nghiệp hỗ trợ phân tích thông tin qua một tổ chức Cách tiếp cận này cho phép để giải quyết các yêu cầu kinh doanh theo một chủ đề mà còn theo nhiều chủ đề khác

Tuy nhiên có một số khác biệt trong kiến trúc kho dữ liệu của cả hai chuyên gia:

 Kimball sử dụng mô hình chiều như lược đồ sao hoặc bông tuyết để tổ chức các dữ liệu trong kho dữ liệu chiều trong khi Inmon sử dụng mô hình ER trong kho dữ liệu doanh nghiệp Inmon chỉ sử dụng mô hình chiều cho kho dữ liệu cục bộ chỉ trong khi Kimball sử dụng nó cho tất

cả các dữ liệu

 Inmon sử dụng các kho dữ liệu cục bộ phân cách vật lý từ kho dữ liệu doanh nghiệp và chúng được xây dựng để sử dụng cho các phòng ban Trong khi trong kiến trúc của Kimball, nó là không cần thiết để tách các kho dữ liệu cục bộ từ kho dữ liệu chiều

 Trong kho dữ liệu chiều của Kimball, phân tích hệ thống có thể truy cập

dữ liệu trực tiếp Trong khi trong kiến trúc của Inmon, hệ thống phân tích chỉ có thể truy cập dữ liệu trong kho dữ liệu doanh nghiệp thông qua các kho dữ liệu cục bộ

So sánh Kimball và Inmon trong cách tiếp cận xây dựng kho dữ liệu

 Bill Inmon đề nghị xây dựng kho dữ liệu theo phương pháp tiếp cận từ trên xuống Trong triết lý của Inmon, nó được bắt đầu với việc xây dựng một kho dữ liệu lớn mà tập trung dữ liệu của doanh nghiệp, nơi tất cả dữ liệu có sẵn từ các hệ thống giao dịch được hợp nhất thành một bộ sưu tập chủ đề theo định hướng, tích hợp, thời gian biến thể và bền vững nhằm hỗ trợ quá trình ra quyết định Sau đó kho dữ liệu cục bộ được xây dựng cho các nhu cầu phân tích của các phòng ban

 Ngược lại với cách tiếp cận Bill Inmon, Ralph Kimball đề nghị xây dựng các kho dữ liệu phương pháp tiếp cận từ dưới lên Trong triết lý của Kimball, nó bắt đầu với kho dữ liệu cục bộ quan trọng phục vụ nhu cầu phân tích của các phòng ban Sau đó, nó được tích hợp các kho dữ liệu cục bộ để nhất quán dữ liệu thông qua information bus Kimball sử dụng mô hình chiều để giải quyết các nhu cầu của các bộ phận với các chủ đề khác nhau trong doanh nghiệp

Lựa chọn giữa cách tiếp cận Kimball hay Inmon để xây dựng kho dữ liệu?

Yêu cầu về hỗ trợ quyết

Tính ổn định của nguồn

đổi nhiều

Hinh 1 21: So sánh 2 cách Kimball và Inmon

Quá trình ETL trong kho dữ liệu

Dữ liệu trong kho dữ liệu phải được thường xuyên cập nhập để có thể phục

vụ mục đích phân tích kinh doanh Để làm điều này, dữ liệu từ một hoặc nhiều

hệ thống hoạt động cần được trích xuất và sao chép vào kho dữ liệu Những thách thức trong quá trình chuyển đổi dữ liệu là việc tích hợp, sắp xếp lại và củng cố khối lượng lớn dữ liệu trên nhiều hệ thống, qua đó cung cấp một cơ sở thông tin mới thống nhất cho kho dữ liệu để phục vụ việc phân tích

Hinh 1 22: Quá trình ETL

Quá trình nén dữ liệu từ hệ thống nguồn và đưa nó vào kho dữ liệu thường được gọi là ETL (Extraction Transformation Loading), đó là viết tắt cho chiết xuất, chuyển đổi và nạp Lưu ý ETL nó liên quan tới một quá trình rộng lớn, chứ không phải ba bước được xác định rõ Các từ viết tắt ETL có lẽ quá đơn giản, bởi vì nó bỏ qua các giai đoạn vận chuyển và ngụ ý rằng mỗi giai đoạn khác của quá trình này là khác biệt Tuy nhiên, toàn bộ quá trình được gọi là ETL

Các phương pháp và nhiệm vụ của ETL đã được biết đến trong nhiều năm,

và không nhất thiết phải duy nhất cho các môi trường kho dữ liệu: một loạt các ứng dụng độc quyền và hệ thống cơ sở dữ liệu là xương sống của bất kỳ doanh nghiệp CNTT Dữ liệu phải được chia sẻ giữa các ứng dụng hoặc hệ thống, cố gắng để tích hợp chúng, tạo ít nhất hai ứng dụng cùng một bức tranh của thế giới Chia sẻ dữ liệu này đã được chủ yếu là giải quyết bằng cơ chế tương tự như những gì chúng ta gọi là ETL

1.9.4 Chiết xuất dữ liệu

Trong thời gian chiết xuất, các dữ liệu cần được xác định và chiết xuất từ nhiều nguồn khác nhau, bao gồm cả hệ thống cơ sở dữ liệu và các ứng dụng Thường thì việc có thể xác định các tập hợp cụ thể cần thiết là không đơn giản,

do đó nhiều dữ liệu hơn mức cần thiết phải được chiết xuất và việc xác định các

dữ liệu có liên quan hay không sẽ được thực hiện tại một thời điểm sau Tuỳ theo khả năng của hệ thống nguồn (ví dụ, hệ điều hành nguồn lực), một số biến đổi có thể diễn ra trong quá trình khai thác này Kích thước của dữ liệu được chiết xuất khác nhau từ hàng trăm kilobyte lên đến GB, tùy thuộc vào hệ thống nguồn và yêu cầu về dữ liệu phân tích

1.9.5 Chuyển đổi dữ liệu

Giai đoạn chuyển đổi dữ liệu áp dụng một loạt các quy tắc hay chức năng

để trích xuất dữ liệu từ các nguồn để lấy được các dữ liệu để tải vào các mục tiêu cuối cùng Một số dữ liệu không yêu cầu bất kỳ chuyển đổi ở tất cả và được gọi là di chuyển trực tiếp hoặc thông qua các dữ liệu trong điều kiện kỹ thuật Một chức năng quan trọng của chuyển đổi dữ liệu là làm sạch các dữ liệu nhằm mục đích để truyền dữ liệu chỉ thích hợp với các mục tiêu Khi các hệ thống khác nhau tương tác với nhau và dựa trên các dữ liệu hệ thống cửa hàng,

có là một thách thức trong giao tiếp / truyền thông với nhau Một số bộ ký tự có thể có sẵn trong một hệ thống có thể không có sẵn ở khác Trường hợp này phải được xử lý một cách chính xác và sau cùng dẫn đến một số vấn đề liên quan đến chất lượng dữ liệu

1.9.6 Nạp dữ liệu

Giai đoạn tải dữ liệu vào kho dữ liệu với nguồn dữ liệu có thể là một tập tin hoặc dữ liệu giao dịch Tùy thuộc vào yêu cầu của tổ chức, quá trình này rất khác nhau Một số kho dữ liệu có thể ghi đè lên các thông tin hiện có thông tin tích lũy; cập nhật trích xuất dữ liệu thường xuyên được thực hiện trên một cơ sở hàng ngày, hàng tuần, hoặc hàng tháng Kho dữ liệu khác (hoặc thậm chí các phần khác của kho dữ liệu tương tự) có thể thêm dữ liệu mới trong một hình thức lịch sử trong khoảng thời gian, ví dụ thường xuyên, hàng giờ Thời gian và phạm vi để thay thế hoặc phụ thêm những sự lựa chọn thiết kế chiến lược phụ thuộc vào thời gian có sẵn và các nhu cầu kinh doanh Nhiều hệ thống phức tạp

có thể duy trì một lịch sử và dấu vết kiểm toán của tất cả các thay đổi đối với dữ liệu được nạp vào kho dữ liệu

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 bên cạnh khoá tự nhiên của nó

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

Hinh 1 23: Cấu trúc chiều cơ bản.

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

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,

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:

Hinh 1 24: Chiều thời gian.

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

Hinh 1 25: Quá trình hợp nhất các chiều phụ thuộc.

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 đó

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: