ĐẠ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

Ký hiệu Chuỗi văn bản gốc Mô tả

3NF Third Normal Form Chuẩn hóa 3NF

Client/Server

OLAP

Client/Server Online Analytical

Processing

Xử lý phân tích trực tuyến

khách/chủ

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

CSDL Database Cơ sở dữ liệu

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

DF Datafile Tệp dữ liệu

DWH Data Warehouse Kho dữ liệu

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

ETL

Extraction, Transportation,

Loading

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

ID ID Định danh

NN NOT NULL Khác rỗng

OD Oracle Designer Sản phẩm

OLAP On Line Analytical Processing Xử lý phân tích trực tuyến

OLTP On Line Transaction Processing Xử lý tác nghiệp trực tuyến

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

1

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

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.

3

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.

4

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

5

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.

6

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ủ đề.

7

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.

8

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

OLTP Kho dữ liệu

Tổ chức Ở dạng chuẩn 3NF Mô hình chiều

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

Liên kết bàng Ít Nhiều

Dư thừa dữ liệu Không Có

Dữ liệu tổng hợp Hiếm Phổ biến

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

9

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.

10

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

11

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

12

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.

13

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

Số lượng khóa ngoại Ít Nhiề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.

14

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.

15

Các bảng và các bảng phân vùng.

Các khung nhìn.

Các ràng buộc toàn vẹn.

Các chiều.

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

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

Sự kiện gần như là các hoạt động tác nghiệp của doanh nghiệp hay tổ

chức. Không giống như bảng chiều, bảng sự kiện thường lưu thông tin về bản

thân hoạt động tác nghiệp được thực thi. Bảng sự kiện bao gồm các đại lượ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

16

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

17

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

All Time

Month

Year

Day

Week

All

Quarter

18

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.

200

100 30

tim

cit

produ

L N

Ja

Fe

M

Ap

1

3 2

50

100

tim

produ

cit

1 2

Ja

Fe

M

Ap

LN

3

19

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

20

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.

21

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

Đặc điểm Kimball Inmon

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

định kinh doanh Chiến thuật Chiến lược

Dữ liệu tích hợp yêu cầu Dữ liệu cục bộ Dữ liệu toàn doanh nghiệp

Cấu trúc dữ liệu KPI, hiệu quả kinh doanh Đáp ứng nhiều nhu cầu

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

dữ liệu Hệ thống nguồn ổn định

Hệ thống nguồn có sự thay

đổi nhiều.

Kỹ năng Nhóm nhỏ Nhóm chuyên gia

Hạn chế về thời gian Ngắn, cấp bách Dài

Chi phí xây dựng Chi phí bắt đầu thấp Chi phí bắt đầu cao

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.

22

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.

23

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

24

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:

25

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:

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:

26

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:

27

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

đó.

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.

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

28

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

Một kho dữ liệu cục bộ là một tập hợp các dữ liệu cùng chủ để được tổ

chức nhằm hỗ trợ việc ra quyết định dựa trên nhu cầu cụ thể của một nhóm

người dùng doanh nghiệp hoặc bộ phận. Có hai loại kho dữ liệu cục bộ: kho dữ

liệu cục bộ độc lập và kho dữ liệu cục bộ phụ thuộc.

Kho dữ liệu cục bộ độc lập: dữ liệu tập trung riêng theo một chủ đề và nó

không được thiết kế đáp ứng cho cả doanh nghiệp. Ví dụ: bộ phận sản xuất có

kho dữ liệu cục bộ của họ, bộ phận nhân lực, bộ phận tài chính cũng như

vậy.Kho dữ liệu cục bộ nhận dữ liệu từ nhiều hệ thống giao dịch theo một chủ

đề hoặc theo yêu cầu kinh doanh cụ thể của một bộ phận. Kho dữ liệu cục bộ

độc lập có thể được theo thiết kế chiều hoặc mô hình thực thể quan hệ. Hệ thống

phân tích và quản trị doanh nghiệp thông minh truy vấn dữ liệu công cụ trực tiếp

từ kho dữ liệu cục bộ. Những hình ảnh dưới đây là một Stand-alone kho dữ liệu

cục bộ điển hình.

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

Kho dữ liệu cục bộ phụ thuộc (Dependent kho dữ liệu cục bộ): Theo Inmon,

một kho dữ liệu cục bộ phụ thuộc là một nơi mà dữ liệu của nó đến từ một kho

dữ liệu. Dữ liệu trong một nhà kho dữ liệu được tổng hợp, cơ cấu lại, và tóm tắt

khi nó đi vào kho dữ liệu cục bộ phụ thuộc. Các kiến trúc của một siêu thị dữ

liệu phụ thuộc như sau:

29

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

Lợi ích của việc xây dựng một siêu thị dữ liệu phụ thuộc:

Hiệu suất: khi hiệu suất thực hiện của kho dữ liệu trở thành một vấn đề thì

việc xây dựng một hoặc hai kho dữ liệu cục bộ có thể giải quyết vấn đề. Bởi

vì xử lý dữ liệu được thực hiện bên ngoài các kho dữ liệu.

An ninh: bằng cách đặt các dữ liệu bên ngoài kho dữ liệu trong các kho dữ

liệu cục bộ, từng bộ phận sở hữu dữ liệu của họ và hoàn toàn kiểm soát dữ

liệu của họ.

KPI theo dõi kho dữ liệu cục bộ là nơi lý tưởng để xây dựng và theo dõi KPIs

qua thời gian dài của thời gian.

30

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

2.1. Giới thiệu.

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

Thành lập năm 1993 và chuyển đổi mô hình hoạt động ngân hàng TMCP

từ năm 2007, Ngân hàng TMCP Đại Dương (OceanBank) tự hào là Ngân hàng

TMCP đa năng, hiện đại, có sự bứt phá về doanh thu, tổng tài sản và vốn điều lệ

hàng năm. Hiện ngân hàng được đánh giá là một trong những ngân hàng có cấu

trúc tài chính lành mạnh, an toàn nhất trong hệ thống ngân hàng.

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

OceanBank cung cấp cho khách hàng các sản phẩm, dịch vụ tài chính

ngân hàng đa năng, hiện đại và hiệu quả, phù hợp với nhu cầu và đặc điểm cư

dân, kinh tế vùng miền. Không chỉ cung cấp các dịch vụ ngân hàng truyền

thống, OceanBank đẩy mạnh phát triển các dịch vụ ngân hàng điện tử, tạo ra các

sản phẩm có hàm lượng kỹ thuật công nghệ cao, bảo mật cho các nhóm khách

hàng doanh nghiệp và cá nhân.

Đây là những bước đi vững chắc của OceanBank trong việc phấn đấu mục

tiêu nằm trong Top 5 Ngân hàng hàng đầu Việt Nam có số lượng khách hàng sử

dụng dịch vụ ngân hàng điện tử và doanh số giao dịch qua kênh ngân hàng điện

tử chiếm tỷ trọng cao nhất trong tương lai, áp dụng những giải pháp công nghệ

hàng đầu trong lĩnh vực tài chính, ngân hàng.

Xác định sự phát triển phải gắn liền với lợi ích chung của xã hội,

OceanBank luôn tích cực tham gia các hoạt động xã hội từ thiện: triển khai

chương trình từ thiện "Nguồn sáng", chữa và phẫu thuật các bệnh về mắt có khả

năng gây mù cho người nghèo trên toàn quốc, tài trợ xây dựng trường, trạm y tế,

31

tài trợ từ thiện cho cháu Trần Danh Tùng phẫu thuật do mắc hội chứng Apert,

tặng quà cho trẻ em nghèo…

Với các giá trị tạo ra cho khách hàng, cổ đông, xã hội..., OceanBank đã

giành được nhiều danh hiệu, giải thưởng, bằng khen của các tổ chức trong nước

và quốc tế cho tập thể và cá nhân xuất sắc của ngân hàng, như Ngân hàng bán lẻ

tốt nhất Việt Nam, Ngân hàng bán lẻ có tốc độ tăng trưởng nhanh nhất Việt Nam

do tạp chí Global Banking & Finance Review trao tặng; Giải thưởng STP

(Straight – Through – Processing) dành cho ngân hàng thanh toán đạt chuẩn cao

do Wells Fargo trao tặng; Top 100 Ngân hàng có Bảng cân đối kế toán mạnh

nhất Khu vực Châu Á Thái Bình Dương; Top 500 Ngân hàng Lớn nhất Khu vực

Châu Á Thái Bình Dương; Top 500 doanh nghiệp lớn nhất Việt Nam

(VNR500); Top 200 doanh nghiệp đóng thuế thu nhập doanh nghiệp lớn nhất…

Thành công của OceanBank được kết tinh từ nhiều yếu tố. Đó là sự nhất quán từ

việc xây dựng đường lối, chính sách đến việc thực thi kế hoạch, là sự quyết tâm

theo đuổi chiến lược kinh doanh lấy mục tiêu phát triển bền vững làm trọng tâm,

là sự chủ động trong công tác quản trị, là sự đoàn kết của tập thể cán bộ nhân

viên. Và chắc chắn, vị thế của OceanBank có được ngày hôm nay không thể

được xây đắp nếu không có sự đồng hành của cổ đông, nhà đầu tư và khách

hàng.

Kiên định thực hiện mục tiêu, OceanBank sẽ tiếp tục nỗ lực phấn đấu trở

thành Ngân hàng sáng tạo nhất, quản lý tốt nhất và được khách hàng đánh giá là

ngân hàng "hướng về khách hàng" tốt nhất trong toàn ngành bằng việc nâng cao

các sản phẩm dịch vụ, tăng cường hợp tác với các tập đoàn lớn trong và ngoài

nước, tích cực đồng hành cùng các doanh nghiệp, chú trọng công tác quản lý

đào tạo và phát triển nhân sự, không ngừng ứng dụng và phát triển công nghệ

thông tin để đảm bảo hoạt động ổn định và an toàn của hệ thống

2.1.2. Hệ thống CORE BANKING.

Giải pháp ngân hàng lõi mà Ngân hàng TMCP Đại Dương đang vận hành

sử dụng giải pháp của nhà cung cấp phần mềm Ấn Độ, Oracle Flexcube Core

Banking version 7.3. Cùng với các hệ thống máy chủ chạy trên nền tảng IBM

AIX, được tích hợp với các hệ thống sản phẩm Oracle.

Oracle FLEXCUBE Core Banking cho phép các tổ chức ngân hàng và dịch

vụ tài chính (BFS) để xác định lại các kinh nghiệm ngân hàng bằng cách cho

phép họ cung cấp dịch vụ cá nhân và rất phù hợp với khách hàng trên tất cả các

kênh. Một giải pháp ngăn chặn ngân hàng lõi, FLEXCUBE Core Banking cho

phép các tổ chức BFS để đơn giản hóa và tinh giản quy trình, theo dõi và quản

lý một cách nhanh chóng các giao dịch phức tạp, xác định tắc nghẽn và cải thiện

32

dịch vụ khách hàng. Nhà nước của các giải pháp nghệ thuật cung cấp một cơ sở

hạ tầng phát triển đồng bộ và cởi mở cho phép triển khai linh hoạt hơn và nâng

cấp tùy chọn. Kiến trúc mở, tính linh hoạt và khả năng tích hợp liền mạch với

các hệ thống khác, bao gồm cả phần mềm ngân hàng trong nhà, làm cho nó lý

tưởng cho các tổ chức BFS tìm cách để duy trì một lợi thế cạnh tranh trong

ngành công nghiệp BFS nhanh chóng phát triển.

Kiến trúc ứng dụng Oracle FLEXCUBE Core Banking hỗ trợ nhanh nhẹn

và quy trình kinh doanh quản lý sử dụng Business Process Execution Language

(BPEL), kiến trúc hướng dịch vụ (SOA), và một mô hình dịch vụ Web dựa trên.

Các giải pháp cho phép các tổ chức BFS để đáp ứng yêu cầu quản lý thông qua

một hệ thống quản lý dữ liệu bảo mật cao và cũng cho phép tích hợp các ứng

dụng của bên thứ ba để tạo thuận lợi cho quá trình kinh doanh đơn giản và phức

tạp.

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

Hệ thống core banking là một hệ thống các phân hệ nghiệp vụ cơ bản của

ngân hàng như tiền gửi, tiền vay, khách hàng … Trên hình là mô tả về hệ thống

core với các màng nghiệp vụ theo mô hinh kinh doanh

Ngân hàng bán lẻ (Retail banking): là các dịch vụ tài chính cung cấp cho

các đôi tượng khách hàng nhỏ như cá nhân, hộ gia đình… có đặc điểm số

lượng nhiều nhưng giá trị không lớn.

Ngân hàng bán buôn (Corporate): là dịch vụ tài chính cung cấp cho khách

hàng lớn.

Quản lý tài sản (Wealth Management), dịch vụ bảo hiểm (Insurance), dịch

vụ về thị trường tiền tệ (Capital Makets).

Ngoài ra về mặt tổ chức dữ liệu, các core banking thường được quản lý

theo các module như:

33

Time deposit current account (TDCASA): là nghiệp vụ thiết lập cho hoạt

động tiền gửi tiết kiệm và tài khoản thanh toán. Thông thường là các

nghiệp vụ huy động tiền gửi trên thị trường 1.

Money Market (MM): là nghiệp vụ thiết lập tiền gửi hoặc cho vay trên thị

trường 2.

Retial Lending (CL): là nghiệp vụ cho vay của ngân hàng.

Sổ cái GL: sổ cái các tài khoản kế toán.

Một số phân hệ khác: SE (trái phiếu, tín phiếu, cổ phiếu), FX (kinh doanh

tiền tệ)…

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

Qua tìm hiểu về hiện trạng hệ thống phần mềm nghiệp vụ và nhu cầu sử

dụng báo cáo phân tích để hỗ trợ việc ra quyết định kinh doanh tại Ngân hàng

TMCP Ocean bank. Tôi nhận thấy:

Hệ thống giao dịch nghiệp vụ vào thời điểm đầu và cuối tháng bị quá tải

làm ảnh hưởng đến chất lượng phục vụ khách hàng của đơn vị. Nguyên

nhân là do số lượng báo cáo quản trị tăng đột biến.

Hệ thống báo cáo chạy trên core banking có định dạng excel, pdf và thời

gian lấy dữ liệu dưới 03 tháng là không phù hợp với nhu cầu về phân tích

báo cáo.

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

Nhu cầu thực tế cần một giải pháp nhằm tách biệt hệ thống báo cáo với hệ

thống giao dịch và cung cấp một công cụ mạnh hiệu quả thực hiện việc phân

tích dữ liệu dễ dàng với khoảng thời gian tính theo năm. Việc xây dựng một kho

dữ liệu trung tâm hoàn chỉnh đòi hỏi một đội ngũ chuyên gia lớn. Qua tìm hiểu

và đánh giá các giải pháp, tôi đặt ra bài toá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”.

34

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

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

Bước đầu tiên trong việc phát triển các kho dữ liệu là chọn dữ liệu phù hợp

từ nguồn dữ liệu. Có hai lý do chính cho việc thực hiện này: Việc đẩy toàn bộ

dữ liệu vào kho dữ liệu là không khả thi (chi phí, khẳ năng so với nhu cầu sử

dụng). Do đó, ta phải dựa các yêu cầu về dữ liệu từ hoạt động phân tích. Tất cả

các quyết định liên quan đến mô hình kho dữ liệu xem xét các mục đích và mục

tiêu về dữ liệu. Thứ hai, bước này đã kiềm chế phạm vi của mô hình kho dữ liệu

để chỉ rằng cần thiết trong dự án. Kể từ khi bước này được thiết kế để phục vụ

như một cái phễu để loại bỏ xem xét các yếu tố dữ liệu không cần thiết trong

kho dữ liệu.

Ngoài ra ta phải xác định được các thông tin yêu cầu về dữ liệu trong kho

dữ liệu để làm cơ sở cho việc quyết định thông tin nào sẽ được đẩy vào kho dữ

liệu và cách thức thiết lập kho để đáp ứng yêu cầu.

Việc thiết kế kho dữ liệu phải căn cứ trên yêu cầu về “mong muốn dữ liệu”

của người dùng cụ thể. Nhưng khi đặt câu hỏi “Bạn muốn dữ liệu gì trong kho

dữ liệu” thì hầu hết doanh nghiệp đều trả lời “tất cả”. Chính vì vậy, thay vì hỏi

các câu hỏi thì chúng ta cần tập trung câu hỏi về việc việc “dữ liệu sẽ được sử

dụng như thế nào?”, “cần dữ liệu như thế nào để trả lời cho câu hỏi kinh doanh”

Với Ocean bank, Việc xây dựng kho dữ liệu cần đáp ứng các yêu cầu sau:

Tạo sự tách biệt giữa hệ thống báo cáo phân tích và hệ thống giao dịch

để đảm bảo sự ổn định cho hệ thống giao dịch phục vụ khách hàng.

Kho dữ liệu về hoạt động nghiệp vụ cho vay và huy động: dữ liệu được

tổ chức phải giúp thực hiện các lệnh truy vấn phức tạp với số lượng dữ

liệu xem xét lớn (mức độ hàng năm), dễ dàng thao tác cho người dùng

cuối.

Tính nhất quán về dữ liệu tại mọi thời điểm: dữ liệu được tổ chức đảm

bảo các đối tượng dữ liệu phải nhất quán. Qua đó đảm bảo sự ổn định,

chính xác của số liệu cho việc phân tích.

Thông có kho dữ liệu phải trả lời được câu hỏi như sự biến động của 2

hoạt động nghiệp vụ theo thời gian, theo thông tin về kỳ hạn, lãi suất,

loại khách hàng, vị trí địa lý… qua đó giúp rút ra các dự báo cho tương

lai để hỗ trợ Ban Lãnh đạo ra quyết định.

Phạm vi dự án chỉ tập trung vào 2 nghiệp vụ huy động, cho vay của ngân hàng:

Nghiệp vụ huy động thực hiện trên 03 hệ thống. Core Banking do giao

dịch viên thực hiện và Mplus (smart phone) & Internet Banking do

35

khách hàng thực hiện. Nhưng toàn bộ dữ liệu cuối cùng vẫn được hạch

toán vào core.

Nghiệp vụ cho vay thực hiện trên hệ thống Core Banking do giao dịch

viên thực hiện.

Dữ liệu đẩy vào kho dữ liệu chỉ tập trung trên hệ thống Core Banking về

thông tin tài khoản cho vay & huy động và các thông tin liên quan như: lãi suất,

số dư, sản phẩm, nhóm nợ, khách hàng, ngày tạo tài khoản, ngày hết hạn…

Ngoài ra bổ sung thêm các thông tin tham khảo.

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

Với yêu cầu của bài toán. Nguồn dữ liệu được triết xuất từ hệ thống core

banking gồm 02 hoạt động cơ bản ngân hàng cho vay và huy động.

Mobi B

ankin

gC

ore

Banki

ng

Inte

rnet

Ban

king

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

Nghiệp vụ huy động là việc tạo tài khoản tiền gửi trên hệ thống được thực

hiện từ 03 hệ thống và căn cứ trên loại tài khoản khách hàng chọn để quyết định

các thông tin cơ bản như lãi suất, thời hạn gửi, thời điểm nhận lãi…

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

Nghiệp vụ cho vay trên hệ thống được tạo từ 02 hệ thống gồm: hệ thống

thẻ visa (gồm thanh toán giao dịch mua hàng, đặt phòng… thực hiện theo

phương thức quẹt thẻ máy pos, giao dịch điện tử..) và theo khoản vay được thiết

lập trên core banking.

Về mặt tổ chức dữ liệu, core banking flexcube tại Ocean Bank được thiết

lập với cơ sở dữ liệu quan hệ Oracle 10g và theo các module gồm:

36

Time deposit current account (TDCASA): là nghiệp vụ thiết lập cho hoạt

động tiền gửi tiết kiệm và tài khoản thanh toán.

Money Market (MM): là nghiệp vụ thiết lập tiền gửi hoặc cho vay trên thị

trường 2.

Retial Lending (CL): là nghiệp vụ cho vay của ngân hàng.

Sổ cái GL: sổ cái các tài khoản kế toán.

Một số phân hệ khác: SE (trái phiếu, tín phiếu, cổ phiếu), FX (kinh doanh

tiền tệ)…

Trong phạm vi đề tài thì cần xem xét các đối tượng sau:

CIF (Khách hàng): là cá nhân hoặc tổ chức sử dụng các sản phẩm dịch vụ

của ngân hàng như gửi tiền, vay tiền… của ngân hàng.

BRANCH (Phòng giao dịch): là nơi khách hàng thực hiện dịch vụ như mở

tài khoản tích kết, nộp tiền…

MAIN_BRANCH (Chi nhánh): thông tin để xác định phòng giao dịch

thuộc chi nhánh nào.

BRN_DISTRICT, BRN_CITY, BRN_TERRITORY, BRN_REGION: để

xác định phòng giao dịch về mặt đía lý thuộc vùng miên nào.

CIF_CLASS (Phân loại khách hàng): thông tin về phân loại khách hàng

theo hệ thống như: khách hàng cá nhân, khách doanh nghiệp…

ACC_CLASS (Phân loại tài khoản tiền gửi) là các gói sản phầm như cho

huy động với đặc thù riêng biệt như kỳ hạn, lãi suât…

TD_ACCOUNT: thông tin về các tài khoản tiền gửi (tiết kiệm, thanh

toán) như số dư, mã tài khoản, chủ tài khoản, lãi suất, kỳ hạn…

RATE: là lãi suất ngân hàng trả cho chủ tài khoản tiền gửi.

LSNB: là lãi suất mua bán vốn giử phòng giao dịch và hội sở. Lợi nhuận

tiền gửi, cho vay của phòng giao dịch chính là chênh lệch giữa lsnb và

rate.

PRODUCT: quy định loại sản phẩm với các đặc thù riêng về lãi suất, kỳ

hạn, loại ưu đãi..

ACC_LOAN: thông tin về tài khoản vay của khách hàng như số tài

khoản, người vay, số tiền vay, định kỳ giải ngân…

CONTRACT: là các thông tin về hợp đồng tiền gửi

GL_CODE: danh sách các tài khoản kế toán thiết lập trong core.

37

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

Nghiệp vụ huy động và cho vay tại ngân hàng ocean bank thiết lập trên

core tại 2 phân hệ: TDCASA từ thị trường 1 (thị trường giữa ngân hàng với

người dân), MM từ thị trường 2 ( thị trường liên ngân hàng giữa ngân hàng và tổ

chức tín dụng khác).

Danh sách các bảng dữ liệu:

CUST_ACCOUNTS: Danh sách các tài khoản tiết kiệm, thanh toán và

các thuộc tính như số tài khoản, ngày mở tài khoản, loại sản phẩm, bộ

cung cụ tính lãi, chi nhánh mở tài khoản, tài khoản hạch toán vào GL

nào…

ACCOUNT_CLASS: Định nghĩa một sản phẩm tiền gửi như tiền gửi linh

hoạt (có thể rút trong kỳ), tiền gửi tích lũy (định kỳ hàng tháng gửi 1 số

tiền vào)… mỗi loại sản phẩm có lãi suất, kỳ hạn… khác nhau.

PR_INT_ACLASS: Bộ tính lãi áp dụng cho một sản phẩm căn cứ theo

ngày ban hành.

CCY: Danh sách mã tiền tệ trong hệ thống (hệ thống luôn có bảng tham

chiếu tỉ giá phục vụ việc tính toán quy đổi theo đơn vị tiền tệ yêu cầu)

ICTM_ACC_UDEVALS: Bảng lưu thông tin cụ thể một tài khoản trong 1

kỳ hạn sẽ ăn theo biểu lãi suất nào.

ICTM_ACC: Lưu thông tin về các kỳ hạn của tài khoản.

BRANCH: Danh sách phòng giao dịch.

TDCASA_BALANCE: Thông tin lịch sử về tài khoản được lưu định kỳ

vào cuối ngày như số dư, lãi suất…

CUSTOMER: Danh sách khách hàng với định danh là CIF (mỗi khách

hàng chỉ có duy nhất 1 CIF)

CONTRACT_MASTER: Danh sách các hợp đồng tiền gửi của tổ chức tín

dụng, tổ chức kinh tế cùng các thông tin về số hợp đồng, ngày gửi, ngày

đáo hạn…

38

PRODUCT_ACCROLE: Bộ lãi suất áp dụng cho với hợp đồng tiền gửi

bên MM.

GLTM_GLMASTER: Danh sách các tài khoản GL.

ACCOUNT_APPS_MASTER: Danh sách các tài khoản vay cùng với các

thông tin như CIF, loại sản phẩm, bộ tính lãi, ngày vay, ngày đáo hạn…

TCKT_BALANCE: Lưu thông tin lịch sửa về tài khoản vay hàng ngày

như số dư, lãi suất, hạch toán vào GL…

CUST_ACCOUNTS

PK,FK4 BRNPK,FK4 ACCPK,FK3 CUSTOMER_NOPK,FK2 ACCOUNT_CLASS

BRANCH_CODECUST_AC_NOCUST_NOCCYAC_OPEN_DATEDR_GLCR_GLPRODUCT_CODE

CCY

PK,FK1 BRNPK,FK1 ACCPK,FK1 CUSTOMER_NOPK,FK1 ACCOUNT_CLASS

CCY_CODECCY_NAMECOUNTRY

ACCOUNT_CLASS

PK ACCOUNT_CLASS

DESCRIPTIONDEFAULT_TENOR_DAYSDEFAULT_TENOR_MONTHSDEFAULT_TENOR_YEARSCLOSE_ON_MATURITY

PR_INT_ACLASS

PK,FK2 BRNPK,FK2 ACCPK,FK2 CUSTOMER_NOPK,FK1,FK2 ACCOUNT_CLASS

PRODUCT_CODEACLASSCCYUDE_EFF_DTUDE_IDUDE_VALUERATE_CODE

ICTM_ACC_UDEVALS

PK,FK1 CUSTOMER_NOPK,FK1 ACCOUNT_CLASSPK,FK1 BRNPK,FK1 ACC

PRODUDE_EFF_DTUDE_IDUDE_VALUERATE_CODE

TDCASA_BALANCE

PK,FK3 BRNPK,FK3 ACCPK,FK2,FK3 CUSTOMER_NOPK,FK3 ACCOUNT_CLASS

DAY_TO_RUNACCTNOCURRENCYAC_BRANCHRATELSNBCUR_BALANCE

CUSTOMER

PK CUSTOMER_NO

CUSTOMER_TYPECUSTOMER_NAME1ADDRESSNATIONALITYLOCAL_BRANCHUNIQUE_ID_VALUE

BRANCH

PK,FK1,FK2 BRNPK,FK1,FK2 ACCPK,FK1,FK2 CUSTOMER_NOPK,FK1,FK2 ACCOUNT_CLASS

BRN_CODEBRN_NAMEBRN_ADDRPARENT_BRANCHBRN_STRESSBRN_CITYBRN_CONTRY

CONTRACT_MASTER

PK,FK2 PRODUCT_CODEPK,FK1 BRNPK,FK1 ACCPK,FK1 CUSTOMER_NOPK,FK1 ACCOUNT_CLASS

BRANCHCONTRACT_REF_NOPRODUCTCOUNTERPARTYCURRENCYBOOKING_DATEVALUE_DATEMATURITY_DATEVERSION_NO

ICTM_ACC

PK BRNPK ACC

INT_START_DATEMATURITY_DATENEXT_MATURITY_DATE

GLTM_GLMASTER

PK,FK2 PRODUCT_CODEPK,FK1 BRNPK,FK1 ACCPK,FK1 CUSTOMER_NOPK,FK1 ACCOUNT_CLASS

GL_CODEGL_DESCPARENT_GL

PRODUCT_ACCROLE

PK PRODUCT_CODE

ACCOUNTING_ROLEROLE_TYPESTATUSACCOUNT_HEAD

ACTB_HISTORY1

PK ACR_SEQUEST

BRANCHTRN_REF_NODR_CR_INDACC_NOCCYLCY_AMOUNTFCY_AMOUNTTRN_DTVALUE_DT

FK1 PRODUCT_CODEFK1,FK2 BRNFK1,FK2 ACCFK1,FK2 CUSTOMER_NOFK1,FK2 ACCOUNT_CLASS

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

39

Hình 2.6 là mô hình dữ liệu nghiệp vụ được mô tả các thực thể được lựa

chọn để đẩy dữ liệu vào kho dữ liệu. Để dễ quan sát mối quan hệ các thực thể,

NLLV đã chủ động không vẽ các quan hệ không cần thiết.

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

2.2.3.1. Phương pháp thiết kế.

Với kiến trúc kho dữ liệu đề xuất và căn cứ khối lượng dữ liệu, kho dữ liệu

sẽ được xây dựng theo phương pháp tổng hợp của 2 cách tiếp cận và được phát

triển theo nhu cầu cụ thể của từng giao đoạn. Cụ thể như sau:

Xây dựng kho dữ liệu quan hệ ban đầu gồm các dữ liệu cần thiết cho

kho dữ liệu cục bộ đầu tiên.

Xây dựng kho dữ liệu cục bộ đầu tiên.

Khi nhu cầu kinh doanh phát sinh. Tiến hành bổ sung dữ liệu cần thiết

cho kho dữ liệu cục bộ mới vào kho dữ liệu.

Xây dựng kho dữ liệu cục bộ tiếp theo.

Quá trình trên thực hiện lặp để đảm bảo kho dữ liệu phát triển và đáp ứng

nhu cầu kinh doanh ở từng giai đoạn. Ngoài ra, theo tài liệu “Mastering Data

Warehouse Design” Wiley Publishing phát hành thì để đảm tính hiệu quả kho

dữ liệu nên được thiết lập qua 08 bước sau:

Lựa chọn dữ liệu phù hợp : yêu cầu, phạm vi, nguồn dữ liệu…

Thêm thông tin thời gian vào dữ liệu: do OTLP là hệ thống phản ánh dữ

liệu hiện trạng còn kho dữ liệu là dữ liệu phản ánh quá trình thời gian.

Thêm thông tin tính toán dữ liệu: các thông tin hỗ trợ việc xử lý thông

tin như ngày làm việc hoặc ngày nghỉ, ngày thuộc tuần nào? Tháng

nào.. mục đích phục vụ việc cải thiện hiệu suất.

Quyết định mục độ chi tiết của dữ liệu sẽ đẩy vào kho dữ liệu.

Thực hiện việc tính toán các dữ liệu tổng hợp và lưu trữ sẵn sàng để

phục vụ truy vấn dữ liệu.

Gộp các thực thể có chung mục đích để tối ưu hệ thống.

Tạo mảng dữ liệu theo nhu cầu kinh doanh về phân tích dữ liệu.

Phân chia dữ liệu.

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

Để đáp ứng các yêu cầu đặt ra về việc sử dụng và vận hành kho dữ liệu.

NLV đề xuất sử dụng kiến trúc kho dữ liệu với vùng đệm làm sạch dữ liệu và

kho dữ liệu cục bộ.

40

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

Kiến trúc kho dữ liệu sẽ gồm:

Nguồn dữ liệu: chiết suất lấy từ hệ thống giao dịch core banking và file dữ

liệu (do Ban kế toán xây dựng).

Vùng đệm: là vùng hệ thống bảng tạm để thực hiện việc làm sạch, tích hợp

và thêm giá trị thời gian vào dữ liệu. Và thực hiện việc sao lưu dữ liệu.

Kho dữ liệu: Sau khi dữ liệu đã được làm sạch sẽ được nạp vào kho dữ liệu.

Sau đó thêm các dữ liệu phục vụ cho tính toán và dữ liệu tổng hợp theo yêu

cầu phân tích. Sử dụng cơ sở dữ liệu quan hệ.

Kho dữ liệu cục bộ: Là cơ sở dữ liệu tổ chức theo mô hình chiều với dữ liệu

được nạp từ kho dữ liệu trung tâm.

Người dùng: là người sử dụng đầu cuối sử dụng dữ liệu.

Lí do chọn kiến trúc trên cho kho dữ liệu:

Vùng đệm: Giúp đơn giả hóa và lưu nhất ký xử lý của quá trình ETL dữ

liệu vào kho. Do vùng đệm đã thực hiện các công việc phức tạp trong việc

tính toán và đảm bảo tính nhất quán của dữ liệu.

Kho dữ liệu cục bộ: được tổ chức theo mô hình chiều giúp đơn giản và dễ

dàng cho người dùng sử dụng. Ẩn đi sự phức tạp và giảm sự ảnh hưởng đến

việc sử dụng của người dùng khi kho dữ liệu thay đổi.

Để đảm bảo tính chính xác và hiệu năng hệ thống. Kho dữ liệu sẽ định kỳ

làm mới 01 lần/ ngày. Hệ thống sẽ tiến hành lấy dữ liệu từ nguồn core đẩy vào

kho dữ liệu sau quá trình đóng ngày cũ và mở ngày mới. Mô hình chiết xuất dữ

liệu như hình dưới đây.

41

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

2.2.3.3. Nguồn dữ liệu cho kho dữ liệu cho việc chiết xuất.

Thông qua việc làm rõ yêu cầu của kho dữ liệu ở mục 2.2.1 và mục 2.2.3 ta

đã xác định được các thực thể dữ liệu cần được đẩy vào kho dữ liệu từ dữ liệu

nguồn và chi tiết nguồn dữ liệu như bảng dưới.

Thực thể Nguồn Bảng dữ liệu chiết xuất Khóa

CIF Core Banking sttm_customer Customer_no

BRANCH Core Banking Ot_branch Branch_code

MAIN_BRANCH Core Banking it_main_sub Sub_branch

BRN_DISTRICT,

BRN_CITY,

BRN_TERRITORY,

BRN_REGION

Core Banking Ot_branch Branch_code

CIF_CLASS Core Banking OJB_Customer_Class Customer_no

ACC_CLASS Core Banking Sttm_account_class Account_class

TD_ACCOUNT Core Banking Sttm_customer_account Account_no

RATE Core Banking ICTMS_PR_INT_UDEVALS Product_code,

aclass, ccy, eff_dt,

rate_code, branch.

LSNB Core Banking ICTMS_LSNB Product_code,

aclass, ccy_code,

eff_dt, rate_code,

branch.

PRODUCT Core Banking Sttm_product_code Product_code

ACC_LOAN Core Banking cltb_account_apps_master Account_number

CONTRACT Core Banking Sttm_contract_master Contract_ref_no

GL_CODE Core Banking GLTM_GLMASTER gl_code

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

42

Dữ liệu tham khảo cần bổ sung vào kho dữ liệu để nhằm mục đích tra cứu

và xác thực tính đứng đắn của dữ liệu như bộ tính lãi product code và danh sách

phân loại tài khoản. Vì việc xác định lãi suất của một tài khoản khi mở sẽ phụ

thuộc vào phân loại tài khoản, bộ lãi suất.

Dữ liệu tham

khảo Nguồn Bảng dữ liệu chiết xuất Ghi chú

Product_code Core Banking ICTMS_PR_INT_UDEVALS Sự thay đổi về lãi suất

Working day Core Banking STTM_LCL_HOLIDAY Ngày làm việc hay nghỉ

Rate_tranfer Core Banking ICTM_ACC_UDEVALS Tỉ giá quy đổi theo loại tiền

LSNB Core Banking IT_LSNB Lãi suất nội bộ cho việc

mua bán vốn trong nội bộ.

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

Ngoài ra chúng cần làm rõ các quan hệ giữa các thực thể. Việc đặc tả các

quan hệ giữa các thực thể dữ liệu trong core banking đã được mô tả tại hình 2.3.

2.2.3.4. Xử lý dữ liệu chuyển đổi và nạp vào kho.

Sự khác biệt lớn nhất giữa mô hình dữ liệu nghiệp vụ và mô hình dữ liệu

kho dữ liệu đó là thời gian. Với mô hình dữ liệu nghiệp vụ thì dữ liệu luôn miêu

tả về trạng thái hiện tại của doanh nghiệp (mang tính thời điểm) còn với kho dữ

liệu thì theo quan điểm dữ liệu gắn liền với thời gian (mang tính lịch sử). Do vậy

khi thiết kế kho ta cần chú ý việc thêm và các thành phần thời gian tới các thực

thể có thể thay đổi. Giải pháp sử dụng là bổ sung thêm cột dữ liệu xác định thời

gian của dữ liệu và với mỗi khi thuộc tính của thực thẻ thay đổi ta sẽ thêm một

bản ghi mới vào kho dữ liệu. Qua đó đảm bảo tính nhất quán về dữ liệu cho kho.

Xem xét yêu cầu và mô hình nghiệp vụ thì dữ liệu đẩy vào kho dữ liệu

ngoài một số dữ liệu bất biến theo thời gian như: số tài khoản, số CIF, lãi suất,

lsnb… thì còn một số dữ liệu có khẳ năng thay đổi chậm như: phân loại khách

hàng (khách hàng trong quá khứ là doanh nghiệp siêu nhỏ nhưng hiện tại có thể

là doanh nghiệp vừa và nhỏ). Để đảm bảo kho dữ liệu lưu giữ chính xác thông

tin và đưa ra dữ liệu nhất quán trong quá khứ thì phải có mốc để xác định chính

xác giá trị dữ liệu ứng với thời điểm quá khứ.

Chiều Thuộc tính Thay đổi Tần suất

cập nhập

Thuộc tính

bổ sung

CIF Class Phân loại khách hàng Có Tháng MonthYear

Khu vực Branch Phân loại khu vực Có Tháng MonthYear

Main Branch Trực thuộc chi nhánh Có Tháng MonthYear

CCy Loại tiền của TK Không

Account_Class Phân loại tk Không

Product_code Bộ tính lãi suất Có Ngày Dữ liệu tham khảo

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

43

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

Theo yêu cầu về dự án, dữ liệu phân tích chi tiết nhất chính là số dư tài

khoản tại ngày. Nên thay vì lưu toàn bộ dữ liệu giao dịch thì dữ liệu trong kho sẽ

được tổng hợp theo số dư tài khoản theo ngày. Quá trình xử lý tại vùng đệm sau

đó đẩy vào kho:

Đầu vào: Dữ liệu thông tin tài khoản trên core banking vào cuối ngày.

Đầu ra: Thông tin tài khoản được đẩy vào bảng trung gian gồm số tài

khoản, ngày, lãi suất… với huy động là bảng it_lsnb_tdcasa_daily, cho

vay là bảng it_lsnb_tckt_cl_daily.

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

Việc tạo và duy trì các kết nối giữa các thực thể được sử dụng với khóa đạ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. Trong kho dữ liệu, khoá này gọi là

khoá tự nhiên. Vì những lí 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

44

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.2.3.5. Tạo thêm các dữ liệu tính toán.

Để cải thiện tốc độ truy vấn của kho dữ liệu. Ta sẽ bổ sung thêm 02 loại dữ

liệu sau:

Dữ liệu phục vụ việc tính toán it_timE.

IT_TIME

CALENDAR_YEAR_CAL_YEAR_CODE NUMBER

CALENDAR_YEAR_END_DATE DATE

CALENDAR_YEAR_TIME_SPAN NUMBER

CALENDAR_YEAR_DESCRIPTION VARCHAR2(2000)

CALENDAR_YEAR_NAME VARCHAR2(25)

CAL_YEAR_NUMBER NUMBER

CAL_YEAR_START_DATE DATE

CALENDAR_QUART_CAL_QUARTER_CO NUMBER

CALENDAR_QUARTER_END_DATE DATE

CALENDAR_QUARTER_TIME_SPAN NUMBER

CALENDAR_QUARTER_DESCRIPTION VARCHAR2(2000)

CALENDAR_QUARTER_NAME VARCHAR2(25)

CAL_QUARTER_NUMBER NUMBER

QUARTER_OF_YEAR NUMBER

CAL_QUARTER_START_DATE DATE

CALENDAR_MONTH_CAL_MONTH_CODE NUMBER

CALENDAR_MONTH_END_DATE DATE

CALENDAR_MONTH_TIME_SPAN NUMBER

CALENDAR_MONTH_DESCRIPTION VARCHAR2(2000)

CALENDAR_MONTH_NAME VARCHAR2(25)

CAL_MONTH_NUMBER NUMBER

CAL_MONTH_START_DATE DATE

MONTH_OF_QUARTER NUMBER

MONTH_OF_YEAR NUMBER

DAY_DATE DATE

DAY_DAY_CODE NUMBER

DAY_START_DATE DATE

DAY_END_DATE DATE

DAY_TIME_SPAN NUMBER

45

JULIAN_DATE NUMBER

DAY_DESCRIPTION VARCHAR2(2000)

DAY_NAME VARCHAR2(25)

DAY_OF_CAL_WEEK NUMBER

DAY_OF_CAL_MONTH NUMBER

DAY_OF_CAL_QUARTER NUMBER

DAY_OF_CAL_YEAR NUMBER

Dữ liệu tổng hợp theo yêu cầu báo cáo bảng ojb_objective

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

Dữ liệu phục vụ việc tính toán bổ sung thêm bảng thông tin về thời gian

(it_time_day) sẽ trả về thông tin chi tiết của một ngày là thuộc tuần nào? Tháng

nào? Quý nào? Năm nào? Là ngày làm việc hay ngày nghỉ.

Dữ liệu tổng hợp là việc tính trước dữ liệu tổng hợp theo tháng ứng phân

loại tài khoản, phân loại khách hàng, loại tiền..

2.2.3.6. Tạo phân cấp dữ liệu.

Qua xem xét dữ liệu và yêu cầu kinh doanh, kho dữ liệu sẽ bao gồm các

phân cấp dữ liệu như sau:

Phân cấp về khu vực địa lý.

Phân cấp về loại tiền.

Phân cấp về phòng giao dịch, chi nhánh.

Phân cấp về loại tài khoản.

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

46

2.2.3.7. Mô hình dữ liệu kho.

Kho được tổ chức theo mỗi hình dữ liệu quan hệ như gồm loại bảng:

Bảng dữ liệu chiều: như thông tin khách hàng, tài khoản, loại tiền…

Bảng dữ liệu phục vụ tính toán: bảng thời gian.

Bảng dữ liệu tổng hợp.

Bảng dữ liệu tham khảo.

Việc quản lý và duy trì quan hệ trong kho dữ liệu được tổ chức thông qua

một khóa đại diện thay vì sử dụng khóa có sẵn từ hệ thống hay khóa theo bộ mã

tiêu chuẩn quốc tế. Việc sử dụng khóa đại diện kiểu number giúp việc truy vấn

hệ thống nhanh hơn và đảm bảo việc nhất quán cùng một dữ liệu trên OLTP

nhưng tại 2 thời điểm khác nhau lại có các thuộc tính xem xét khác nhau.

47

CUST_ACCOUNTS

PK,FK2 CUSTOMER_NOPK,FK1 EFFECTIVE_DATEPK,FK1 ACCOUNT_CLASS

BRANCH_CODECUST_AC_NOCUST_NOCCYAC_OPEN_DATEDR_GLCR_GLPRODUCT_CODE

CCY

PK,FK1 CUSTOMER_NOPK,FK1 ACCOUNT_CLASSPK,FK1 EFFECTIVE_DATE

CCY_CODECCY_NAMECOUNTRY

ACCOUNT_CLASS

PK ACCOUNT_CLASSPK EFFECTIVE_DATE

DESCRIPTIONDEFAULT_TENOR_DAYSDEFAULT_TENOR_MONTHSDEFAULT_TENOR_YEARSCLOSE_ON_MATURITY

TDCASA_BALANCE

PK,FK2,FK3 CUSTOMER_NOPK,FK3 EFFECTIVE_DATEPK,FK3 ACCOUNT_CLASS

DAY_TO_RUNACCTNOCURRENCYAC_BRANCHRATELSNBCUR_BALANCE

CUSTOMER

PK CUSTOMER_NO

CUSTOMER_TYPECUSTOMER_NAME1ADDRESSNATIONALITYLOCAL_BRANCHUNIQUE_ID_VALUE

BRANCH

PK,FK1 CUSTOMER_NOPK,FK1 ACCOUNT_CLASSPK,FK1 EFFECTIVE_DATE

BRN_CODEBRN_NAMEBRN_ADDRPARENT_BRANCHBRN_STRESSBRN_CITYBRN_CONTRY

CONTRACT_MASTER

PK,FK1,FK3 CUSTOMER_NOPK,FK1,FK3 ACCOUNT_CLASSPK,FK1,FK3 EFFECTIVE_DATE

BRANCHCONTRACT_REF_NOPRODUCTCOUNTERPARTYCURRENCYBOOKING_DATEVALUE_DATEMATURITY_DATEVERSION_NO

GLTM_GLMASTER

PK GL_CODE

GL_DESCPARENT_GLEFFECTIVE_DATE

PRODUCT_ACCROLE

GL_CODEPRODUCT_CODEROLE_TYPESTATUSACCOUNT_HEAD

ACCOUNT_APPS_MASTER

PK,FK1 ACCTNOPK,FK2,FK3 CUSTOMER_NOPK,FK2,FK3 ACCOUNT_CLASSPK,FK2,FK3 EFFECTIVE_DATE

ACCOUNT_NUMBERBRANCH_CODECUSTOMER_IDPRODUCT_CODEVALUE_DATEMATURITY_DATEAMOUNT_FINANCED

TCKT_BALANCE

PK ACCTNO

DAY_TO_RUNPRODUCT_CODECURRENCYAC_BRANCHRATELSNBCUR_BALANCEGL_COE

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

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

Kho dữ liệu cục bộ về huy động, cho vay được chiết xuất dữ liệu từ kho dữ

liệu trung tâm. Và là nơi người dùng truy cập thực hiện các truy vấn dữ liệu.

Kho dữ liệu cục bộ được tổ chức theo mô hình chiều

Lược đồ dữ liệu về kho sản phẩm:

48

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

Bảng sự kiện: dữ liệu từ bảng TDCASA_BALANCE.

Bảng chiều thời gian: thiết lập hệ thống tự sinh.

Bảng chiều khách hàng: dữ liệu nạp từ bảng CUSTOMER.

Bảng chiều phòng giao dịch: dữ liệu nạp từ bảng BRANCH.

Bảng chiều location: dữ liệu được nạp từ bảng BRANCH.

Bảng chiều loại tài khoản acc_class.

49

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

Với bản thiết kế logic về kho dữ liệu sản phẩm nhằm đáp ứng nhu cầu về

hệ thống báo cáo cho Ban lãnh đội. NLLV tiến hành cài đặt thử nghiệm hệ

thống để đánh giá kết quả với công cụ Oracle Warehouse Builder trên nền tảng

Oracle Database 10g với nguồn dữ liệu thực tế năm 2011 của Ngân hàng TMCP

Đại Dương.

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

Oracle Warehouse Builder (OWB) còn được gọi là Warehouse Builder

(WB) là một framework có khả năng mở rộng, một phần không thể thiếu của

Oracle Database. Nó cung cấp các giải pháp thiết kế, triển khai và quản lý KDL

cho doanh nghiệp, các KDL cục bộ và các ứng dụng quản trị doanh nghiệp

thông minh.

OWB còn là một công cụ thực hiện quá trình trích chiết, chuyển đổi và nạp

(ETL) dữ liệu vào trong KDL.

OWB gồm hai thành phần như hình 13: thành phần thiết kế (design

environment) và thành phần thực thi (runtime environment). Mỗi thành phần xử

lý các khía cạnh khác nhau của hệ thống. Thành phần thiết kế xử lý dữ liệu

metadata, thành phần thực thi xử lý dữ liệu vật lý.

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

Thành phần thiết kế bao gồm kho dữ liệu metadata ( metadata

repository) được chứa trong cơ sở dữ liệu oracle và một tập các công cụ thiết kế

và báo cáo phía client, công cụ này được viết bằng Java hoặc HTML

Tạo ra metadata là một hoạt động thiết kế cho phép sử dụng các công cụ

phía client để thiết kế các đối tượng, các quy trình và luồng công việc.

Warehouse Builder hỗ trợ thiết kế lược đồ cơ sở dữ liệu quan hệ, lược đồ đa

50

chiều, quá trình xử lý ETL và các công cụ hỗ trợ người dùng cuối thông qua

client.

Các hệ thống nguồn (source system) đóng một vai trò quan trọng trong bất

kỳ giải pháp ETL nào và thay vì việc thực hiện ETL một cách thủ công thì

Warehouse Builder cung cấp các thành phần tích hợp các thông tin liên quan

vào trong kho của nó.

Một thế mạnh của kiến trúc OWB là quy trình quản lý vòng đời, nó cho

phép metadata được cập nhật dựa trên thay đổi của các dữ liệu nguồn. Sau đó

OWB dễ dàng cập nhật những thay đổi và tiến trình ETL và đến hệ thống đích.

Thành phần thực thi:

Khi người dùng đã thiết kế hệ thống ETL dựa trên một mức logic, họ cần

chuyển nó vào môi trường cơ sở dữ liệu vật lý. Trước khi điều này được thực

hiện thì thông tin về cơ sở dữ liệu được bổ sung vào thiết kế logic. Sau khi quá

trình cấu hình được hoàn thành thì mã code được sinh ra.

OWB tạo ra một ngôn ngữ chuyên biệt cho tiến trình ETL và các câu lệnh

SQL DDL cho các đối tượng cơ sở dữ liệu. Mã code sinh ra được triển khai

hoặc tới hệ thống hoặc tới cơ sở dữ liệu.

Thực hiện các chức năng ETL có nghĩa là chạy các mã code đã được triển

khai vào trong cơ sở dữ liệu. Quá trình ETL chuyển dữ liệu từ nguồn và cơ sở

dữ liệu đích.

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

Thành phần Mô tả

Dữ liệu nguồn –

Oracle Data base 10g Dữ liệu thực tế 2010 cài đặt trên hệ thống máy chủ

Dữ liệu đích Laptop Core i3, RAM 2GB cài đặt công cụ Oracle

Warehouse Builder 11gR2 và Orace data base 11g

NLV tiến hành cài đặt và xây dựng kho dữ liệu đầu cuối về sản phẩm huy động để kiểm tra khẳ năng đáp ứng yêu cầu và tính đứng đắn của bản thiết kế của chương 2. 3.3. Các bước thao tác.

3.3.1. Xây dựng các bảng chiều.

Sử dụng OWB để tạo các bảng chiều theo thiết kế.

REAL_TIME: về thời gian với phân cấp theo lịch chuẩn với mức độ

ngày, tháng, quý, năm. Và lưu trữ theo RLOAP.

51

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

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

REAL_CLASS_ACCT: loại tiền gửi tiền.

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

52

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

REAL_CUSTOMER: về phân loại khách hàng.

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

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

3.3.2. Tạo cube

Tạo 02 khôi dữ liệu về hoạt động huy động.

53

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

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

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

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

OWB cho phép ta dễ dàng định nghĩa các kết nối tới nguồn dữ liệu cần

chiết xuất và cung cấp một công cụ trực quan hóa giúp ta dễ dàng thiết lập việc

xử lý dữ liệu.

Nguồn dữ liệu là hệ thống core bank (dữ liệu năm 2010) được thiết lập với

tên KZ. OWB cho phép ta chọn các đối tượng dữ liệu sẽ được chiết vào core và

nạp vào các dữ liệu meta của đối tượng để phục vụ cho việc thiết kế.

54

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

Quá trình chiết xuất và xử lý dữ liệu với giao diện đồ họa thân thiện.

Chiều thời gian: OWB cung cấp wizard để xây dựng chiều thời

gian.

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

Chiều loại hình tiền gửi: chiết xuất và thiết lập các dữ liệu tổng hợp

phục vụ tính toán.

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

Chiều phân loại khách hàng.

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

55

3.3.4. Triển khai.

Toàn bộ các thiết kế phía trên là thiết kế logic và nó chưa thực sự tồn tại

trong cơ sở dữ liệu. Triển khai là công việc thực hiện chuyển đổi các thiết kế

logic thành thiết kế vật lý lưu trữ trong cơ sơ dữ liệu. OWB có wizard hỗ trợ

việc triển khai.

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

Sau khi triển khai ta sẽ có các đối tượng vật lý trong cơ sở dữ liệu như

bảng, squenes… các bảng sẽ được thiết lập với index tối ưu phục vụ cho các

truy suất dữ liệu. Toàn bộ các bảng sẽ được liên kết theo một khóa đại diện (kiểu

number) do OWB tự sinh ra theo đặc tả thiết kế logic.

Ngoài các bảng trực quan ta thấy trên giao diện, hệ thống sẽ sinh thêm các

bảng dữ liệu hỗ trợ việc xử lý dữ liệu như: bảng phân cấp (bảng cầu nối chỉ ra

phân cấp của dữ liệu), bảng dữ liệu tổng hợp được tính toán trước…

56

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

Oracle warehouse Build là công cụ mạnh hỗ trợ cho quá trình ETL dữ liệu từ

nguồn vào kho dữ liệu. Với giao diện trực quan dễ sử dụng.

Quá trình nạp dữ liệu gồm:

Bước 1: Nạp dữ liệu các bảng chiều

Bước 2: Khi bước 1 hoàn thành tiền hành dựng cube dữ liệu

Bước 3: Trả về thông báo kết quả.

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

Thiết kế logic cho quá trình nạp dữ liệu vào kho dữ liệu ta tiến hành triển

khai để biến thiết kế logic thành thiết kế vật lý cụ thể là script mã nguồn quá

trình nạp dữ liệu.

Sau đó ta tiến hành chạy nạp dữ liệu vào kho thông qua công cụ OWB cung cấp sẵn. Chi tiết về qua trình nạp dữ liêu như hình dưới.

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

57

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

Bây giờ các đối tượng vật lý sẽ có dữ liệu được chiết xuất từ hệ thống

nguồn. Ta có thể truy cập dữ liệu thông qua các công cụ SLQ Plus, SQL

Developer hoặc đơn giản xem dữ liệu trực tiếp trên OWB.

Dữ liệu bảng chiều.

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

58

Dữ liệu cube.

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

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

Kho dữ liệu đã được thiết lập với các dữ liệu phù hợp với việc phân tích dữ

liệu và được đánh chỉ mục phù hợp với báo cáo.Sử dụng công cụ truy xuất dữ

liệu để thiết lập dữ liệu phục cho các báo cáo cơ bản

Báo cáo sự biến động loại hình tiền gửi không kỳ hạn việt nam đồng

Biến động số dư loại hình tiền gửi có kỳ hạn việt nam đồng.

59

Cơ cấu tỉ trọng tiền gửi theo loại hình tiền gửi việt nam đồng.

Báo cáo biến động và so sánh loại hình tiền gửi có kỳ hạn và không kỳ hạn

Thông qua kho dữ liệu, người dùng đầu cuối sẽ nhanh chóng và dễ dàng

nhận được dữ liệu để phục vụ việc công việc. Ngoài ra một số ứng dụng còn

cung cấp cho người dùng công cụ để tự định nghĩa báo cáo và chia sẻ.

60

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

Với việc tìm hiểu và nghiên cứu kiến trúc kho dữ liệu và áp dụng vào lĩnh

vực Ngân hàng thương mại. Tôi đã học tập thêm được nhiều kỹ năng, kiến thức

về tổ chức và khai thác dữ liệu với hệ thống lớn. Qua đó có cái nhìn tổng thể và

toàn diện hơn về việc xử lý dữ liệu khối lượng lớn.

Dù trong quá trình làm luận văn, tôi đã cố gắng nhưng kết quả đạt được vẫn

còn nhiều hạn chế.

1. Các kết quả đạt được.

- Đưa ra giải pháp khả thi cho việc xây dựng kho dữ liệu phù hợp với chi phí

và điều kiện tại Ocean Bank

- Cài đặt thử nghiệm kho dữ liệu cục bộ sản phảm.

- Kho dữ liệu xây dựng là nền tảng cho việc triển khai các hệ thống báo cáo

quản trị mạnh.

2. Định hướng phát triển.

- Hoàn thiện kho dữ liệu như khách hàng, lợi nhuận, đánh giá hiệu suất nhân

viên KPI.

- Nghiên cứu về nhu cầu dữ liệu để có thể tổ chức dữ liệu tốt. Nhằm người

dùng tự tạo báo cáo theo nhu cầu.

- Xử lý các vấn đề phát sinh: cách thức làm mới kho dữ liệu, chu kỳ cấp nhập

dữ liệu.

- Triển khai hệ thống BI là công cụ mạnh hỗ trợ việc khai thác dữ liệu nhằm

chiết xuất thông tin

61

TÀI LIỆU THAM KHẢO

Tiếng Việt.

[1] Hà Quang Thụy, Kho dữ liệu và khai phá dữ liệu. Bài giảng môn học

khoa Công nghệ thông tin, trường Đại học Công nghệ, 2010.

Tiếng Anh.

[1] Oracle Data Warehousing and Business Intelligence Solutions, Wiley,

2007.

[2] Mastering Data Warehouse Design Relational and Dimensional

Techniques, Wiley, 2003.

[3] Introduction to Data Warehousing and Business Intelligence, Christian S.

Jensen & Torben Bach Pedersen & Christian Thomsen, 2009.

[4] Oracle Warehouse Builder User's Guide 10g, 2009

[5] Oracle Database Data Warehousing Guide, 11g Release 2, 2013.