Tìm hiểu và cải tiến hệ thống kho dữ liệu trong ngân hàng

Tăng cường quan hệ với đối tác: Qua việc phân tích số liệu trên kho dữ liệu, người quản lý sẽ nhận ra được các yếu tố cạnh tranh, chiến lược của các đối tác để có thể đề xuất một cách p

ĐẠI HỌC QUỐC GIA HÀ NỘI

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

HÀ XUÂN TRƯỜNG

TÌM HIỂU VÀ CẢI TIẾN HỆ THỐNG

KHO DỮ LIỆU TRONG NGÂN HÀNG

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS Phạm Hồng Thái

Hà Nội – 2013

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

Hình 1.1.3.1 Kiến trúc của một hệ thống kho dữ liệu 9

Hình 1.2.2.1 Kiến trúc của hệ thống kho dữ liệu ngân hàng 11

Hình 1.2.2.2 Quá trình xử lý dữ liệu trong hệ thống kho dữ liệu ngân hàng 11

Hình 1.2.2.3 Quá trình kết xuất từ dữ liệu nguồn sang vùng tập kết 12

Hình 1.2.3.1 Liên kết giữa bảng tham số và bảng chính 14

Hình 1.2.3.2 Xử lý dữ liệu bảng dữ liệu chính vào bảng dữ liệu lịch sử 15

Hình 1.2.3.3 Quan hệ giữa các bảng chính trong EDM 15

Hình 1.2.4.1 Quá trình chuẩn bị dữ liệu 17

Hình 1.2.4.2 Quá trình chuyển đổi dữ liệu từ Staging sang EDM 18

Hình 1.2.4.3 Một gói DTS xử lý chuyển đổi dữ liệu từ statging sang EDM 19

Hình 1.2.4.4 Quá trình đẩy dữ liệu từ EDM sang kho dữ liệu chuyên đề 20

Hình 1.2.5.1 Mô hình tổng thể hệ thống kho dữ liệu ngân hàng BIDV 21

Hình 2.2.1.1 Cơ chế xử lý [EL][T] 23

Hình 2.2.1.2 Cơ chế xử lý [ET][L] 24

Hình 2.2.1.3 Ví dụ xử lý [EL][T] của DTS 25

Hình 2.2.1.4 Cơ chế xử lý [E][T][L] 25

Hình 2.2.2.1 Mô hình dữ liệu MOLAP 26

Hình 2.2.2.2 Mô hình dữ liệu ROLAP 27

Hình 2.5.1.1 Mô hình hệ thống kho dữ liệu mới 36

Hình 2.5.2.1 Một gói xử lý ETL trong DTS 38

Hình 2.5.2.2 Chi tiết gói xử lý trong DTS 38

Hình 2.5.3.1 Cơ chế tối ưu trong DB2 45

Hình 2.5.4.1 Mô hình hệ thống tập trung khai thác, phân tích 46

và phân phối kho dữ liệu 46

Hình 2.5.4.2 Luồng xử lý các yêu cầu khai thác, phân tích báo cáo 47

Hình 2.6.6 Kết quả sau 4 lần kiểm thử về thời gian trích xuất 53

Hình 2.6.7 Kết quả sau 4 lần kiểm thử về % CPU sử dụng trên core-banking 54

Hình 3.3.1.1 Mô hình logic kho dữ liệu thử nghiệm 56

Hình 3.3.3.1 Luồng thiết kế hệ thống kho dữ liệu thử nghiệm 57

Hình 3.4.2.1 Mô hình quan hệ CSDL SPTG 59

Hình 3.5.1 “Main Job” xử lý trích xuất dữ liệu cho kho dữ liệu SPTG 61

Hình 3.5.2 Job DAILY_SPTG xử lý lấy dữ liệu ngày 61

Hình 3.5.3 Job PARAMETERS_SPTG xử lý trích xuất dữ liệu các bảng chiều 62

Hình 3.6.1.1 Màn hình thiết kế OLAP Metadata trên Design Studio 63

Hình 3.6.4.1 Triển khai OLAP Model lên Cognos Server 64

Hình 3.6.5.1 Đồng bộ nhóm quyền Cognos Server và OLAP Security 64

Hình 3.7.1 Kết quả thử nghiệm cho hệ thống kho dữ liệu báo cáo SPTG 65

DANH MỤC BẢNG BIỂU

Bảng 2.3.2.1 Tiêu chuẩn kỹ thuật kho dữ liệu ngân hàng 29

Bảng 2.3.2.2 Tiêu chuẩn tốc độ tăng trưởng kho dữ liệu ngân hàng 29

Bảng 2.5.2.1 Tiêu chuẩn kỹ thuật giữa DTS và Datastage [6, 8] 37

Bảng 2.5.3.1 Tiêu chuẩn kỹ thuật giữa SQL Server và DB2 [6, 8] 44

Bảng 2.6.1 Cấu hình máy chủ thực nghiệm 48

Bảng 2.6.2 Kết quả test 1 giữa DTS và Datastage 50

Bảng 2.6.3 Kết quả test 2 giữa DTS và Datastage 51

Bảng 2.6.4 Kết quả test 3 giữa DTS và Datastage 52

Bảng 2.6.5 Kết quả test 4 giữa DTS và Datastage 53

Bảng 3.4.2.1 Danh sách các bảng trong CSDL SPTG 60

Bảng 3.7.1 Kết quả thử nghiệm cho hệ thống kho dữ liệu báo cáo SPTG 65

DANH MỤC CHỮ VIẾT TẮT

AS/400 Application System/400

CSDL Cơ sở dữ liệu DTS Data Transformation Services

DWH Data Warehouse

EDM Enterprise Data Model

ETL Extract Transform Load

OLAP Online Analytical Processing

SPTG Sản phẩm tiền gửi

MỤC LỤC

LỜI CẢM ƠN 1

LỜI CAM ĐOAN Error! Bookmark not defined DANH MỤC HÌNH VẼ, ĐỒ THỊ 1

DANH MỤC BẢNG BIỂU 3

DANH MỤC CHỮ VIẾT TẮT 4

MỤC LỤC 7

MỞ ĐẦU 7

Chương 1 HỆ THỐNG KHO DỮ LIỆU 8

1.1 Tổng quan kho dữ liệu 8

1.1.1 Giới thiệu 8

1.1.2 Khái niệm 8

1.1.3 Cấu trúc của một hệ thống kho dữ liệu 9

1.1.4 Mối quan hệ giữa kho dữ liệu và khai phá dữ liệu 9

1.1.5 Các lĩnh vực ứng dụng 10

1.2 Hệ thống kho dữ liệu trong ngân hàng 10

1.2.1 Giới thiệu 10

1.2.2 Kiến trúc của kho dữ liệu ngân hàng 11

1.2.3 Enterprise Data Model 13

1.2.4 Quá trình xử lý dữ liệu trong hệ thống kho dữ liệu 17

1.2.5 Đánh giá các mặt hạn chế của hệ thống 20

Chương 2 XÂY DỰNG HỆ THỐNG KHO DỮ LIỆU CẢI TIẾN 23

2.1 Mục tiêu 23

2.2 Các cấu phần nâng cấp, cải tiến 23

2.2.1 Cơ chế trích lọc dữ liệu 23

2.2.2 Cơ chế xử lý phân tích trực tuyến (OLAP) 26

2.2.3 Cơ chế khai thác và phân phối báo cáo 27

2.3 Các yêu cầu kỹ thuật 28

2.3.1 Yêu cầu về mô hình 28

2.3.2 Yêu cầu về khả năng đáp ứng thực tế của hệ thống 29

2.3.3 Yêu cầu kỹ thuật về công cụ trích lọc dữ liệu 30

2.3.4 Yêu cầu kỹ thuật về kho dữ liệu chuyên đề, dữ liệu đa chiều 31

2.3.5 Yêu cầu kỹ thuật về công cụ khai thác, phân phối dữ liệu 32

2.4 Các giải pháp công nghệ 35

2.4.1 Giải pháp của Microsoft 35

2.4.2 Giải pháp của Oracle 35

2.4.3 Giải pháp của IBM 36

2.5 Thiết kế, xây dựng mô hình cải tiến 36

2.5.1 Mô hình tổng thể 36

2.5.2 Thiết kế, xây dựng gói trích lọc dữ liệu theo mô hình [E][T][L] 37

2.5.3 Xây dựng kho dữ liệu chuyên đề, dữ liệu đa chiều dạng ROLAP 43

2.5.4 Xây dựng hệ thống khai thác và phân phối kho dữ liệu 46

2.6 Kết quả thử nghiệm 54

2.7 Kết luận 54

Chương 3 ÁP DỤNG HỆ THỐNG CẢI TIẾN CHO BÁO CÁO SPTG 55

3.1 Mục tiêu 55

3.2 Yêu cầu chức năng 55

3.3 Thiết kế tổng thể kho dữ liệu 56

3.3.1 Mô hình logic 56

3.3.2 Mô hình vật lý 57

3.3.3 Luồng thiết kế 57

3.3.4 Thiết kế bảo mật 57

3.4 Thiết kế kho dữ liệu chuyên đề SPTG 58

3.4.1 Thiết kế dữ liệu chỉ tiêu 58

3.4.2 Thiết kế chi tiết CSDL 59

3.5 Thiết kế job trích xuất dữ liệu từ EDM vào KDL chuyên đề SPTG 61

3.6 Thiết kế dữ liệu đa chiều SPTG 62

3.6.1 Thiết kế OLAP Metadata 63

3.6.2 Thiết kế OLAP Security 63

3.6.3 Xây dựng hệ thống phân phối báo cáo 63

3.6.4 Triển khai OLAP Metadata lên Cognos Server 63

3.6.5 Đồng bộ nhóm quyền Cognos Server và OLAP Security 64

3.7 Kết quả thử nghiệm 627

KẾT LUẬN 679

TÀI LIỆU THAM KHẢO 70

PHỤ LỤC 71

Lợi ích của kho dữ liệu ngân hàng:

Cải thiện hiệu quả hoạt động: Kho dữ liệu cho phép ngân hàng tổ chức hoạt động

của mình một cách hiệu quả, khoa học với sự hỗ trợ mạnh mẽ, phản ánh thực trạng hoạt động doanh nghiệp thông qua các công cụ phân tích Mặc khác, kho dữ liệu tập trung còn giúp ngân hàng hoạch định các chiến lược kinh doanh hiệu quả, tránh lãng phí và tăng năng suất lao động

Tạo doanh thu: Tạo thêm nhiều cơ hội mới thông qua việc phân tích các khách

hàng tiềm năng, sở thích tiêu dùng cùng các chương trình kinh doanh khuyến mãi tiếp cận một cách nhanh nhất đến khách hàng với các sản phẩm phù hợp đúng nhu cầu khách hàng bằng kênh phân phối thích hợp

Phát triển sản phẩm mới trong thời gian nhanh nhất: Kho dữ liệu cũng cho

người quản lý một cái nhìn về độ phức tạp của sản phẩm từ nhu cầu của khách hàng Chính sự khác biệt này giúp ngân hàng có kế hoạch chuẩn bị các bước cần thiết cho ra đời sản phẩm phù hợp nhu cầu thị trường

Tăng cường quan hệ với đối tác: Qua việc phân tích số liệu trên kho dữ liệu,

người quản lý sẽ nhận ra được các yếu tố cạnh tranh, chiến lược của các đối tác để có thể đề xuất một cách phù hợp những chính sách, mô hình kinh doanh mới

Hầu hết hệ thống công nghệ thông tin của các ngân hàng trong nước đã có kho dữ liệu riêng Tuy nhiên hệ thống kho dữ liệu hiện có thường được chắp vá bởi rất nhiều công nghệ khác nhau, không ổn định và hạn chế về mặt cung cấp kịp thời và tốc độ chuyển đổi, tải dữ liệu Gần đây nhất là ngân hàng Sacombank đã công bố xây dựng được kho dữ liệu trên nền tảng Oracle [3]

Luận văn này tìm hiểu và cải tiến hệ thống kho dữ liệu trong ngân hàng Thương mại Cố phần Đầu tư và Phát triển Việt Nam (BIDV), khắc phục một số hạn chế như tốc độ chuyển đổi, tốc độ truyền tải, tăng độ chính xác, tính kịp thời trong các tác vụ Ngoài ra luận văn cũng thiết kế hệ thống phân phối và khai thác báo cáo đến cho các đầu cuối mà hiện nay BIDV đang thiếu nhằm nâng cao hiệu quả việc khai thác kho dữ liệu phục vụ tốt hơn nữa cho các hoạt động của ngân hàng

Chương 1 HỆ THỐNG KHO DỮ LIỆU

1.1 Tổng quan kho dữ liệu

Kho dữ liệu (tiếng Anh: Data Warehouse) là kho lưu trữ dữ liệu bằng thiết bị điện

tử của một tổ chức Các kho dữ liệu được thiết kế để hỗ trợ việc phân tích dữ liệu và lập báo cáo [7, 12]

Định nghĩa cổ điển này về kho dữ liệu tập trung vào việc lưu trữ dữ liệu Tuy nhiên, các phương tiện cho việc lấy và phân tích, trích rút, biến đổi, nạp dữ liệu, và quản lý dữ liệu từ điển cũng được coi là các thành phần cốt yếu của một hệ thống kho

dữ liệu Nhiều người sử dụng thuật ngữ “kho dữ liệu” với ngữ cảnh rộng hơn Một định nghĩa mở rộng cho kho dữ liệu bao gồm cả các công cụ thông minh, các công cụ

để trích, biến đổi và nạp dữ liệu vào kho, và các công cụ để quản lý và lấy siêu dữ liệu (meta data)

1.1.1 Giới thiệu

Trong quá trình hoạt động kinh doanh, các dữ liệu của doanh nghiệp phát sinh ngày càng nhiều Người ta muốn tận dụng nguồn dữ liệu này để sử dụng cho những mục đích hỗ trợ cho công việc kinh doanh ví dụ như cho mục đích thống kê hay phân tích Quá trình tập hợp và thao tác trên các dữ liệu này có những đặc điểm sau:

 Dữ liệu tích hợp (Atomicity): Dữ liệu tập hợp từ nhiều nguồn khác nhau Điều này sẽ dẫn đến việc quá trình tập hợp phải thực hiện việc làm sạch, sắp xếp, rút gọn dữ liệu

 Theo chủ đề (Consistency): Không phải tất cả các dữ liệu đều được tập hợp, người ta chỉ lấy những dữ liệu có ích

 Biến thời gian (Isolation): Các dữ liệu truy xuất không bị ảnh hưởng bởi các dữ liệu khác hoặc tác động lên nhau

 Dữ liệu cố định (Durable): Khi một Transaction hoàn chỉnh, dữ liệu không thể tạo thêm hay sửa đổi

1.1.2 Khái niệm

Kho dữ liệu là một tập các dữ liệu có những đặc điểm sau: tập trung vào một chủ

đề, tổng hợp từ nhiều nguồn dữ liệu khác nhau, từ nhiều thời gian và không sửa đổi, được dùng trong việc hỗ trợ ra quyết định trong công tác quản lý

a Cấu trúc dữ liệu cho kho dữ liệu

Vì dữ liệu trong kho dữ liệu rất lớn và không có những thao tác như sửa đổi hay tạo mới nên nó được tối ưu cho việc phân tích và báo cáo Các thao tác với dữ liệu của kho dữ liệu dựa trên cơ sở là mô hình dữ liệu đa chiều (multidimensional data model), được mô hình vào đối tượng gọi là data cube Data cube là trung tâm của vấn đề cần phân tích, nó bao gồm một hay nhiều tập dữ kiện (fact) và các dữ kiện được tạo ra từ nhiều chiều dữ kiện khác nhau (dimention)

b Ngôn ngữ cho kho dữ liệu

Ngôn ngữ xử lý phân tích trực tuyến (OLAP – On-Line Analytical Prosessing), rất phù hợp với kho dữ liệu, ngôn ngữ này tương tự với ngôn ngữ truy vấn SQL và tập trung vào các câu lệnh sau:

 Thu nhỏ (roll-up): Ví dụ nhóm dữ liệu theo năm thay vì theo quý

 Mở rộng (drill-down): Ví dụ mở rộng dữ liệu, nhìn theo tháng thay vì theo quý

 Cắt lát (slice): Nhìn theo từng lớp một Ví dụ từ danh mục bán hàng của Q1, Q2, Q3, Q4, chỉ xem của Q1

 Thu nhỏ (dice): bỏ bớt một phần của dữ liệu (tương ứng thêm điều kiện vào câu lệnh WHERE trong SQL)

1.1.3 Cấu trúc của một hệ thống kho dữ liệu

Bao gồm ba tầng :

 Tầng đáy: Là nơi cung cấp dịch vụ lấy dữ liệu từ nhiều nguồn khác sau đó chuẩn hóa, làm sạch và lưu trữ dữ liệu đã tập trung

 Tầng giữa: Cung cấp các dịch vụ để thực hiện các thao tác với kho dữ liệu gọi

là dịch vụ OLAP (OLAP server) Có thể cài đặt bằng Relational OLAP, Multidimensional OLAP hay kết hợp cả hai mô hình trên Hybrid OLAP

 Tầng trên cùng: Nơi chứa các câu truy vấn, báo cáo, phân tích

Hình 1.1.3.1 Kiến trúc của một hệ thống kho dữ liệu 1.1.4 Mối quan hệ giữa kho dữ liệu và khai phá dữ liệu

Cả hai đều có thể đứng độc lập với nhau, tuy nhiên khi kết hợp được kho dữ liệu với khai phá dữ liệu thì lợi ích rất lớn lý do như :

 Dữ liệu của kho dữ liệu rất phù hợp cho việc khai phá dữ liệu do đã được tập hợp và làm sạch

 Cơ sở hạ tầng của kho dữ liệu hỗ trợ rất tốt cho các việc như xuất, nhập cũng như các thao tác cơ bản trên dữ liệu

 OLAP về cung cấp các tập lệnh rất hữu hiệu trong phân tích

1.1.5 Các lĩnh vực ứng dụng

Có thể đưa vào ba mảng ứng dụng chính :

 Xử lý thông tin như tạo ra các báo cáo và trả lời các câu hỏi định trước

 Phân tích và tổng hợp dữ liệu, kết quả được thể hiện bằng các báo cáo và bảng biểu

 Dùng trong các mục đích kế hoạch như khai khoáng dữ liệu

Các lĩnh vực hiện tại có ứng dụng kho dữ liệu bao gồm:

 Thương mại điện tử

 Quản lý quan hệ khách hàng (CRM – Customer Relationship Management)

Hệ thống cung cấp các báo cáo quản trị điều hành ở các mảng sau:

 Báo cáo tiền gửi

 Báo cáo tiền vay

 Báo cáo tài sản nợ

 Báo cáo tài sản có

 Báo cáo kế toán

 Báo cáo quản lý rủi ro

AS/400 là dòng máy chủ IBM iSeries 400, “i” viết tắt của “Integrated”,

“Integrated” là vì máy được thương mại với tất cả chương trình cần thiết cài đặt sẵn trên máy chủ của hãng IBM, hiện đang được sử dụng làm core-banking

1.2.2 Kiến trúc của kho dữ liệu ngân hàng

Excel, text file

SQL Server 2000

AS/400 STAGING AREA ENTERPRISE

DATA MODEL SOURCE

DATA

DD CD LN GL ATM

STAGING DATABASE EDM

MIS (OTHERS)

LOAN DEPOSIT (OTHERS)

USER FRONT-END

REPORTS

(DBF, Text File Format, )

REPORTS

(Excel File Format, )

Sources Extraction Staging Warehousing Delivery

DTS Packages

DTS Packages

OLAP Processing DTS

Packages

Hình 1.2.2.2 Quá trình xử lý dữ liệu trong hệ thống kho dữ liệu ngân hàng

Đầu tiên, dữ liệu từ các nguồn khác nhau (Sources) được kết xuất vào vùng tập kết

dữ liệu (Statging Database) Tất cả các tham số của các nguồn dữ liệu cũng được kết xuất và lưu trong vùng tập kết này Sau đó dữ liệu từ vùng tập kết sẽ được kết xuất ra CSDL EDM Tiếp theo dữ liệu từ EDM được đẩy ra các máy chủ OLAP hoặc các CSDL chuyên đề Cuối cùng là phân phối báo cáo đến người sử dụng từ dữ liệu vùng EDM hoặc từ các máy chủ chuyên đề tùy theo nhu cầu sử dụng Quá trình xử lý dữ

liệu được thiết kế thông qua công cụ DTS (một công cụ ETL của Mirosoft) đặt trên một máy chủ Windows NT độc lập

Sau đây luận văn sẽ đặc tả chi tiết các đối tượng chính trong kiến trúc và quá trình

xử lý kho dữ liệu ngân hàng trong hình 1.2.2.2

a Dữ liệu nguồn (Source data)

Tất cả các dữ liệu nguồn (DD, CD, LN…là các thư viện trong hệ thống AS/400) cần được hợp nhất vào trong DWH

Mỗi dữ liệu nguồn phải có một có sở dữ liệu phù hợp, hoặc ít nhất là một trong số các định dạng cấu trúc mà có thể được chuyển thành một

cơ sở dữ liệu Có thể là những cơ sở dữ liệu SQL server, file kiểu text… Trong hệ thống ngân hàng BIDV, các dữ liệu nguồn hầu hết nằm trong AS/400

DWH không thay đổi dữ liệu nguồn mà chỉ có thể đọc dữ liệu từ đó DWH không yêu cầu có màn hình giao diện để tương tác với dữ liệu nguồn Điều này để tránh ánh hưởng tới hiệu năng của hệ thống

b Vùng tập kết (Staging area)

Staging area là một thư viện trong hệ thống AS/400 Dữ liệu nguồn sau khi được kết xuất sẽ được đưa vào đây Quá trình kết xuất thông qua các package của công cụ DTS đặt trên một máy chủ Windows NT Staging area chỉ chứa những dữ liệu cần thiết cho enterprise data model (EDM), không phải tất cả các bảng, các trường được kết xuất vào trong staging area

Staging area như là 1 lát cắt (snapshot) của dữ liệu nguồn Dữ liệu trong staging không được làm sạch như trong EDM

SOURCE DATA

AS400

DTS EXTRACTION

c Enterprise Data Model (EDM)

Enterprise data model (EDM) là một thư viện trong hệ thống AS/400 Dữ liệu từ staging area được chỉnh sửa cho phù hợp với kiểu

dữ liệu sau đó được thống nhất lại trước khi nó được chuyển vào EDM Mỗi dữ liệu, bản ghi trong EDM được xác định rõ nguồn dữ liệu

EDM lưu dữ liệu lịch sử (ví dụ 1 năm, hàng tháng…) EDM sẽ được mô tả chi tiết trong phần sau

d Data mart

Data mart là các cơ sở dữ liệu hướng chủ đề được trích xuất từ cơ

sở dữ liệu EDM, có thể là cơ sở dữ liệu quan hệ hoặc cơ sở dữ liệu đa chiều, được lưu trữ tại các máy chủ Windows NT riêng rẽ

Các dữ liệu trong cơ sở dữ liệu đa chiều được lưu trong cấu trúc

dữ liệu đa chiều được gọi là cube

Cube là kết quả cuối cùng của quá trình xử lý OLAP trên nền tảng Analysis Services của SQL Server 2000, nó chứa dữ liệu đã được hợp nhất và tổng hợp dựa trên chiều và thước đo giá trị quy định cho từng cube riêng biệt

e Phân phối (User Front-End)

Dữ liệu từ DWH có thể được phân phối cho người dùng từ 2 nguồn: EDM hoặc cơ sở dữ liệu đa chiều

Dữ liệu này có thể được phân phối dưới dạng tệp tin văn bản (text file), tệp tin cơ sở dữ liệu, excel hoặc sử dụng kết nối trực tiếp giữa DWH và máy trạm (truy vấn)

1.2.3 Enterprise Data Model

a Tổng quan

Enterprise Data Model (EDM) là cốt lõi của hệ thống kho dữ liệu Nó lưu dữ liệu

đã hợp nhất từ các hệ thống nguồn khác nhau sau khi hoàn thành các giai đoạn thu thập dữ liệu, làm sạch dữ liệu và chuyển đổi dữ liệu

EDM cũng có thể được gọi là một kho dữ liệu quan hệ, trên thực tế nó là một cơ

sở dữ liệu quan hệ rất lớn Một khác biệt chính là nội dung của một kho dữ liệu đã được hợp nhất thành một thực thể duy nhất, do đó, nó phù hợp với các thông tin cần thiết của toàn bộ tổ chức, không chỉ một hoặc hai bộ phận riêng lẻ

Việc hợp nhất thông tin của một tổ chức sẽ làm giảm dữ liệu dư thừa, giảm sự không thống nhất và thiếu chính xác trong cả tổ chức, đồng thời việc bảo trì cũng dễ

dàng hơn và việc thực hiện các chính sách bảo mật, cập nhật, mở rộng cũng đơn giản

đi nhiều

Hiện tại, thư viện EDM chứa khoảng 500 bảng, với hơn 150 GB dữ liệu, đối với các file dữ liệu ngày lưu lịch sử trong vòng 6 tháng, các file dữ liệu tháng lưu lịch sử 1 năm

Các bảng tham số dùng để chuẩn hóa dữ liệu, loại bỏ sự dư thừa dữ liệu, đồng thời cũng nâng cao hiệu quả và dễ bảo trì

zBranch Branch_ID

Branch_Name

LoanMaster Transaction_ID

Loan_ID Loan_Type

Branch_ID

…

Officer_ID

zOfficer Officer_ID

Hình 1.2.3.1 Liên kết giữa bảng tham số và bảng chính

Trong hình 1.2.3.1 như trên, bảng LoanMaster chứa những ID là tên chi nhánh và tên nhân viên ngân hàng chịu trách nhiệm cho mỗi giao dịch Dung lượng của LoanMaster chứa hàng triệu bản ghi và có hàng trăm những tham chiếu cho những tên này trong các bảng dữ liệu chính khác

Các tham số phải được bảo trì liên tục, nghĩa là bất kỳ sản phẩm mới, chi nhánh và các nhóm khác phải được đưa vào trong các bảng tham số ngay sau khi dữ liệu mới nhận được Tương tự như vậy, những thay đổi khác như gỡ bỏ, định nghĩa lại những tham số hiện tại cũng phải thực hiện ngay lập tức

 Duy trì dữ liệu lịch sử

Trong EDM, có một số bảng dữ liệu lịch sử (history tables) Các bảng dữ liệu chính (master tables) giữ những bản dữ liệu “snapshot” hàng tháng của tổ chức, trong khi đó các bảng dữ liệu lịch sử lưu trữ dữ liệu lịch sử

Cấu trúc của các bảng lịch sử tương tự như các bảng dữ liệu trong EDM và các bảng dữ liệu chính khác

Master tables (Snapshot Data)

History tables (Historical Data)

ENTERPRISE DATA MODEL

Hình 1.2.3.2 Xử lý dữ liệu bảng dữ liệu chính vào bảng dữ liệu lịch sử

Trước khi xử lý hàng tháng, nội dung của những bảng chính được đổ vào bảng dữ liệu lịch sử Sau khi hoàn thành, nội dung của các bảng chính này được xóa đi

Qua thời gian, các bảng dữ liệu lịch sử sẽ phát triển lớn hơn nhưng tính lịch sử của

nó không thay đổi trong suốt thời gian tồn tại

Có 2 quy tắc trong kho dữ liệu:

- Dữ liệu trong kho dữ liệu phải đươc phát triển liên tục

- Khi đã trong kho dữ liệu, dữ liệu lịch sử không được sửa đổi bằng bất kỳ cách nào để bảo tồn tính toàn vẹn dữ liệu

b Cấu trúc EDM

EDM bao gồm một số những bảng dữ liệu chính (master tables), bảng dữ liệu lịch

sử và một số lượng lớn các bảng tham số (parameter tables), tất cả được liên kết với nhau bằng các khóa chính/ khóa ngoại

Việc đẩy dữ liệu vào EDM được thực hiện hàng ngày, việc này được thực hiện bởi các gói “packages” trong DTS (Data Transformation Services) – một công cụ ETL của Microsoft SQL Server 2000

zCUS

Cus_ID

zACC

Cus_ID Fac_ID

zCOL

Col_ID

zFAC

Fac_ID Col_ID

1n

Hình 1.2.3.3 Quan hệ giữa các bảng chính trong EDM

EDM bao gồm một số các bảng chính sau:

 zCUS

zCUS là bảng thông tin khách hàng của ngân hàng Cấu trúc của nó được thiết kế

để đồng bộ hóa tất cả các tệp tin khách hàng khác trong hệ thống nguồn Khóa chính của zCUS là trường mã số khách hàng Cus_ID Khách hàng có thể ở phân hệ tiền vay, tiền gửi, ATM,…Trường Soure_ID được sử dụng để xác định nguồn dữ liệu trong phân hệ nào đó của khách hàng

 zCOL, zFAC

zCOL lưu tất cả dữ liệu tài sản thế chấp cho tất cả các sản phẩm với những tài sản được cầm cố để đảm bảo hỗ trợ tài chính Khóa của zCOL là trường số tài sản thế chấp Col_ID, Fac_ID

zFAC là bảng lưu các bản ghi liên kết giữa tài khoản ở bảng zACC và tài sản ở bảng zCOL

zCOL liên kết với 2 bảng chính là zFAC và zACC thông qua trường Fac_ID và Appl_ID

1.2.4 Quá trình xử lý dữ liệu trong hệ thống kho dữ liệu

Enterprise Data Model

Sources Extraction Staging Warehousing Delivery

DTS Packages

DTS Packages

OLAP Processing DTS

Packages

Hình 1.2.4.1 Quá trình chuẩn bị dữ liệu

Quá trình này gồm 3 cấu phần chính:

 Source Data: Dữ liệu nguồn Các nguồn dữ liệu này thường chủ yếu là các thư viện/schema trong hệ thống AS/400

 Staging Database: là một cơ sở dữ liệu tập hợp từ các nguồn khác nhau Vùng staging cũng là một thư viện trong hệ thống AS/400

 DTS Packages: là các gói vận hành được thiết kế bằng DTS (Data Transformation Services) của SQL Server 2000 và đặt trên một máy chủ hệ điều hành Windows NT riêng biệt Các gói này được thiết kế để trích xuất

dữ liệu từ dữ liệu nguồn sang vùng staging

Đầu tiên, dữ liệu từ các nguồn khác nhau được trích xuất vào Staging area thông qua các gói “packages” vận hành trên DTS của SQL Server 2000 Các nguồn dữ liệu này thường là các thư viện trong hệ thống AS/400

Tất cả những tham số từ dữ liệu nguồn cũng được trích xuất và lưu trữ trong vùng Staging Bằng cách tập trung hết dữ liệu cần thiết vào một vùng duy nhất tạo điều kiện cho việc xử lý bên trong EDM dễ dàng hơn

Thời gian vận hành quá trình này bắt đầu lúc 2 giờ sáng hằng ngày, kết thúc khoảng 3 giờ Tổng thời gian mất khoảng 1 tiếng

b Chuyển đổi dữ liệu vào Enterprise Data Model (EDM)

Sources Extraction Staging Warehousing Delivery

DTS Packages

DTS Packages

OLAP Processing DTS

Packages

Hình 1.2.4.2 Quá trình chuyển đổi dữ liệu từ Staging sang EDM

Quá trình gồm 3 cấu phần chính:

 Staging Database: Cơ sở dữ liệu tập trung các nguồn dữ liệu trên AS/400

 EDM Database: Cơ sở dữ liệu Enterprise Data Model

 DTS Packages: Các gói vận hành DTS được thiết kế để chuyển đổi dữ liệu

từ vùng staging sang vùng EDM Các packages này cũng nằm trên cùng một máy chủ Windows NT trong phần chuẩn bị dữ liệu

Quá trình chuyển đổi dữ liệu vào EDM là quá trình quan trọng trong hệ thống kho

dữ liệu, gồm 2 giai đoạn:

 Chuyển đổi dữ liệu tham số (parameter)

 Chuyển đổi dữ liệu các bảng chính (master tables)

Chuyển đổi dữ liệu tham số

Đầu tiên các dữ liệu tham số từ vùng Staging được chuyển vào các bảng dữ liệu tham số của EDM Các tham số EDM này phải được tạo ra trước để đảm bảo tính toàn vẹn dữ liệu

Sau khi các bảng tham số được tạo ra, khóa chính và index cho tất cả những bảng này cũng được định nghĩa trước khi dữ liệu của tham số được nạp vào EDM Sau đó mới đẩy dữ liệu vào các bảng chính EDM

Chuyển đổi dữ liệu các bảng chính

Dữ liệu được trích xuất và chuyển đổi từ vùng staging vào các bảng dữ liệu chính trong EDM Việc phân loại dữ liệu chính xác được hỗ trợ bởi các tham số trong EDM

đã được nạp vào trong quá trình trước đó

Trong thời gian này, một số các xử lý được thực hiện, bao gồm:

- Thêm và chỉnh sửa các định nghĩa tham số và mã

- Tính toán số dư hiện thời

- Thay thế những giá trị NULL bằng các giá trị đại diện cho số 0 hoặc ký tự trắng

Hình 1.2.4.3 Một gói DTS xử lý chuyển đổi dữ liệu từ statging sang EDM

Quá trình trích xuất, chuyển đổi dữ liệu đều được thiết kế bằng công cụ DTS Đặc điểm thiết kế của nhà thầu Silver Lake là phần dữ liệu nguồn, vùng staging và EDM đều nằm trên AS/400 Các thiết kế trích xuất chuyển đổi dữ liệu từ vùng này sang vùng khác đều thực hiện trên cùng một cơ sở dữ liệu, dựa vào hầu hết hiệu năng tính toán, xử lý của core-banking AS/400 Như hình 1.2.4.3 ở trên, các chuyển đổi thực chất chỉ là insert, update dữ liệu trên các thư viện khác nhau trong core-banking AS/400

Quá trình chuyển đổi dữ liệu vào EDM là quá trình quan trọng nhất trong kho dữ liệu, quá trình này mất khoảng 3 tiếng 30 phút Kết thúc lúc 6 giờ 30 phút sáng hàng ngày

c Chuẩn bị báo cáo (The Final Reports)

Sources Extraction Staging Warehousing Delivery

DTS Packages

DTS Packages

OLAP Processing DTS

Packages

Hình 1.2.4.4 Quá trình đẩy dữ liệu từ EDM sang kho dữ liệu chuyên đề

Mặc dù chi tiết các module báo cáo khác nhau, nhưng cũng đều theo một số các bước như sau:

- Dữ liệu được kết xuất từ EDM tới vùng data mart, thiết kế trích xuất chủ yếu dưới dạng [ET][L] (tức là trích xuất và chuyển đổi trên máy chủ dữ liệu nguồn), tập trung trong bảng zACC trong EDM, bảng zACC có 80 cột và khoảng hơn 13 triệu bản ghi, kích thước khoảng 32 GB Các dữ liệu đưa vào data mart này cũng có thể được lấy từ các nguồn bên ngoài nếu cần thiết Hai nhóm dữ liệu được định rõ: dữ liệu chính

và các tham số

- Dữ liệu đã xử lý được sử dụng để đưa vào các bảng trong SQL Server với cấu trúc gần giống với cấu trúc của các báo cáo cuối cùng

- Dữ liệu cuối cùng được lưu trữ có thể ở dạng bảng hoặc dạng dữ liệu đa chiều

- Nội dung của những bảng này được xuất sang các định dạng text, excel và các định dạng khác

Quá trình này thường mất khoảng 3 tiếng 30 phút bao gồm trích xuất, chuyển đổi

dữ liệu khoảng 2 tiếng 30 phút, xử lý dữ liệu đa chiều cube khoảng 1 tiếng và kết thúc khoảng hơn 10 giờ sáng hàng ngày

1.2.5 Đánh giá các mặt hạn chế của hệ thống

Các cấu phần sử dụng trong hệ thống kho dữ liệu ngân hàng BIDV:

- Dữ liệu nguồn, Staging Area, EDM nằm trên AS/400 (core-banking)

- Data marts, Cube đặt trên các máy chủ độc lập sử dụng CSDL SQL Server

2000 và Analysis Services của Microsoft

- Công cụ ETL dùng DTS của SQL Server 2000, được đặt chung trên một máy chủ Windows riêng

Excel, text file

SQL Server 2000

AS/400 STAGING AREA ENTERPRISE

DATA MODEL SOURCE

DATA

DD CD LN GL ATM

STAGING DATABASE EDM

MIS (OTHERS)

LOAN DEPOSIT (OTHERS)

USER FRONT-END

REPORTS

(DBF, Text File Format, )

REPORTS

(Excel File Format, )

DTS

Hình 1.2.5.1 Mô hình tổng thể hệ thống kho dữ liệu ngân hàng BIDV

Quá trình xử lý chuẩn bị dữ liệu và chuyển đổi dữ liệu vào EDM đều thực hiện trên máy chủ AS/400 thông qua công cụ DTS Nguồn dữ liệu, vùng staging và EDM đều là các thư viện trên AS/400, các thao tác của quá trình chuẩn bị dữ liệu và chuyển đổi dữ liệu vào EDM chủ yếu xử lý tính toán dữ liệu trên cùng một hệ thống core-banking của IBM là AS/400 Hai quá trình này kết thúc trước 6 giờ 30 sáng, tận dụng tài nguyên, hiệu năng core-banking, không gây ảnh hưởng tới giao dịch của hệ thống (Vì giao dịch ngân hàng thường bắt đầu từ lúc 8 giờ sáng) Tuy nhiên, kết quả trích xuất, chuẩn bị báo cáo còn tiếp tục đến 10 giờ sáng ảnh hưởng đến tốc độ giao dịch của đầu ngày lẫn quản trị điều hành

Hệ thống kho dữ liệu hiện tại còn một số tồn tại như sau:

1 Hệ thống ngân hàng thường hoạt động giao dịch từ 8 giờ sáng Quá trình chuẩn

bị báo cáo hơn 10 giờ sáng mới kết thúc, điều này sẽ làm hệ thống AS/400 phải phân tải tài nguyên, một phần thực hiện giao dịch core-banking, một phần chuyển đổi kho

dữ liệu, gây ảnh hưởng phần nào đó đến tốc độ giao dịch Mặt khác việc kết thúc chuyển đổi kho dữ liệu quá muộn như vậy sẽ không đảm bảo xử lý kịp thời về mặt nghiệp vụ quản trị điều hành, nắm bắt các thông tin cần thiết một cách nhanh nhất Khi vận hành xử lý chuyển đổi kho dữ liệu trong thời gian giao dịch từ 8 giờ sáng trở đi, hệ thống core-banking CPU chịu tải tăng thêm khoảng 20 – 30 %

Quá trình xử lý chuẩn bị báo cáo hàng ngày đẩy khoảng 35 GB dữ liệu tới hơn 15 chương trình khác nhau phục vụ công tác quản trị điều hành

Sau hơn 10 năm hoạt động, số lượng tài khoản cũng như dữ liệu lịch sử lớn dần, quá trình chuyển đổi dữ liệu rất chậm chạp, phải mất hơn 8 tiếng, vận hành từ 2 giờ sáng tới hơn 10 giờ mới kết thúc

2 Thiếu hệ thống phân phối và khai thác báo cáo đến người sử dụng

Hiện tại hệ thống tại ngân hàng TMCP BIDV chỉ cung cấp về mặt nền tảng công nghệ báo cáo OLAP, gần như chưa có mảng phân phối đến người sử dụng cuối Không

hỗ trợ được người sử dụng chi nhánh khai thác báo cáo, do tính chất bảo mật của công nghệ hiện tại chưa được đáp ứng

Mặt khác hệ thống chỉ hỗ trợ khai thác trực tiếp qua mạng LAN Người sử dụng ở hội sở chính khai thác trực tiếp kho dữ liệu, cần qua hai tầng bảo mật:

- Phải có tài khoản của hệ điều hành do máy chủ kho dữ liệu cung cấp

- Phải có tài khoản bảo mật mức ứng dụng

Qua mức bảo mật ứng dụng hệ thống chỉ cho phép phân quyền theo file báo cáo (file Excel) mà người sử dụng được phép khai thác, chưa thiết lập phân quyền theo mức dữ liệu Cube trên OLAP Server

Từ những hạn chế này, luận văn đặt và giải quyết một số các vấn đề còn tồn tại như được trình bày trong các chương tiếp theo của luận văn

Chương 2 XÂY DỰNG HỆ THỐNG KHO DỮ LIỆU CẢI TIẾN

2.1 Mục tiêu

Dựa vào những hạn chế đã được đánh giá ở chương 1 của hệ thống kho dữ liệu do nhà thầu Silver Lake cung cấp, luận văn sẽ đưa ra phương án nâng cấp, cải tiến hệ thống kho dữ liệu với các mục tiêu sau:

1 Hạn chế tối đa mức độ ảnh hưởng phân tải tài nguyên tới hệ thống core-banking của quá trình trích xuất, chuyển đổi kho dữ liệu trong thời gian giao dịch Rút ngắn thời gian quá trình chuẩn bị báo cáo một cách chính xác, đầy đủ và nhanh chóng, phục vụ báo cáo quản trị điều hành sớm nhất có thể được

 Với mục tiêu này, cần xây dựng lại mô hình trích xuất, chuyển đổi dữ liệu trong hệ thống kho dữ liệu

2 Cung cấp hệ thống khai thác và phân phối báo cáo chuyên nghiệp đến người sử dụng cuối (hội sở chính và các đơn vị chi nhánh)

 Ở mục tiêu này, luận văn dự kiến xây dựng thêm hệ thống khai thác và phân phối báo cáo tập trung

2.2 Các cấu phần nâng cấp, cải tiến

Với mục tiêu đã đề ra, luận văn sẽ tập trung phân tích, thiết kế lại các cấu phần chính sau đây

2.2.1 Cơ chế trích lọc dữ liệu

Cơ chế trích lọc dữ liệu trong kho dữ liệu ngân hàng BIDV chỉ được thiết kế dưới dạng [ET][L] và [EL][T] Tức là máy chủ DTS (máy chủ cài đặt công cụ ETL) chỉ có nhiệm vụ trích xuất (Extract) hoặc truyền tải (Load) dữ liệu, việc chuyển đổi (Transform) dữ liệu chỉ có thể được thực hiện trên máy chủ CSDL nguồn hoặc máy chủ CSDL đích Máy chủ DTS không có chức năng chuyển đổi, tính toán dữ liệu

Ví dụ: Cơ sở dữ liệu nguồn có 2 bảng KHACHHANG lưu thông tin khách hàng,

bảng GIAODICH lưu giao dịch của từng khách hàng, 2 bảng này liên kết với nhau qua trường MaKH

KHACHHANG MaKH TenKH

GIAODICH MaGD MaKH SoTien

Câu lệnh truy vấn SQL cho ví dụ trên:

SELECT B.MaGD, A.TenKH, B.SoTien FROM KHACHHANG A INNER JOIN GIAODICH B

ON A.MaKH=B.MaKH

Nếu thiết kế DTS dưới dạng [EL][T] thì hai bảng KHACHHANG và GIAODICH

sẽ được kết xuất từ máy chủ nguồn sang máy chủ đích Máy chủ DTS chỉ có nhiệm vụ chuyển dữ liệu 2 bảng KHACHHANG và GIAODICH sang CSDL đích Việc tính toán chuyển đổi “join” giữa hai bảng được thực hiện trên máy chủ cơ sở dữ liệu đích

Đối với bài toán kho dữ liệu ngân hàng hiện tại, ta có thể giảm tải được hệ thống core-banking vào đầu giờ giao dịch bằng việc thiết kế gói xử lý chuyển đổi dữ liệu trong quá trình “chuẩn bị báo cáo” dưới dạng [E][T][L].

2.2.2 Cơ chế xử lý phân tích trực tuyến (OLAP)

Xử lý phân tích trực tuyến, hay còn gọi là OLAP nhằm cung cấp khả năng truy xuất nhanh đến dữ liệu của kho dữ liệu Tạo khối (cube) cho dữ liệu trong các bảng chiều (dimension table) và bảng sự kiện (fact table) trong kho dữ liệu và cung cấp khả năng thực hiện các truy vấn tinh vi và phân tích cho các ứng dụng client

Trong khi kho dữ liệu và data mart lưu trữ dữ liệu cho phân tích, thì OLAP là kỹ thuật cho phép các ứng dụng client truy xuất hiệu quả dữ liệu này OLAP cung cấp nhiều lợi ích cho người phân tích, cho ví dụ như:

- Cung cấp mô hình dữ liệu đa chiều trực quan cho phép dễ dàng lựa chọn, định hướng và khám phá dữ liệu

- Cung cấp một ngôn ngữ truy vấn phân tích, cung cấp sức mạnh để khám phá các mối quan hệ trong dữ liệu kinh doanh phức tạp

- Dữ liệu được tính toán trước đối với các truy vấn thường xuyên nhằm làm cho thời gian trả lời rất nhanh đối với các truy vấn đặc biệt

- Cung cấp các công cụ mạnh giúp người dùng tạo các khung nhìn mới của dữ liệu dựa trên một tập các hàm tính toán đặc biệt

OLAP được đặt ra để xử lý các truy vấn liên quan đến lượng dữ liệu rất lớn mà nếu cho thực thi các truy vấn này trong hệ thống OLTP sẽ không thể cho kết quả hoặc sẽ mất rất nhiều thời gian

Mô hình lưu trữ hỗ trợ OLAP gồm Multidimentional OLAP, Relational OLAP và Hybird OLAP [4, 10, 12]

Hệ thống hiện tại sử dụng Analysis Services lưu trữ dữ liệu đa chiều theo mô hình Multidimentional OLAP (MOLAP)

Mô hình OLAP đa chiều dạng MOLAP lưu trữ dữ liệu cơ sở (là dữ liệu từ các

bảng của kho dữ liệu hoặc kho dữ liệu chuyên đề) và thông tin tổng hợp (là các giá trị được tính toán từ các bảng) trong các cấu trúc đa chiều gọi là các khối (cube) Các cấu trúc này được lưu bên ngoài cơ sở dữ liệu chuyên đề hoặc kho dữ liệu

Hình 2.2.2.1 Mô hình dữ liệu MOLAP

Lưu trữ các khối (cube) trong cấu trúc MOLAP là tốt nhất cho các truy vấn tổng hợp dữ liệu thường xuyên mà cần thời gian hồi đáp nhanh Tuy nhiên cần bước xử lý

dữ liệu để tạo khối OLAP, quá trình này mất khá nhiều thời gian

Mô hình OLAP quan hệ (ROLAP – Relational OLAP) lưu trữ dữ liệu cơ sở và

thông tin tổng hợp trong các bảng quan hệ Các bảng này được lưu trữ trong cùng cơ

sở dữ liệu như là các bảng của data mart hoặc kho dữ liệu

Hình 2.2.2.2 Mô hình dữ liệu ROLAP

Lưu trữ dữ liệu trong cấu trúc ROLAP cung cấp các ưu điểm sau:

- ROLAP cho phép cơ chế tự động tạo chỉ mục

- ROLAP ánh xạ các tổng hợp có sẵn từ data mart hoặc kho dữ liệu Quản lý ROLAP được phép sử dụng các tổng hợp có sẵn để tổng hợp mà không cần tính toán lại cho mỗi truy vấn

- Truy cập trực tiếp từ kho dữ liệu, không có độ trễ vì không có bước xử lý tạo khối như trong mô hình MOLAP

Nhìn chung, mô hình MOLAP và ROLAP đều có đặc điểm nổi trội riêng Tuy

nhiên, đối với bài toán khai thác và phân phối kho dữ liệu trong ngân hàng, ROLAP bỏ qua một số bước như tạo khối, tính toán lại mỗi truy vấn nên thời gian sẽ rút ngắn hơn

so với mô hình MOLAP đang sử dụng Thực tế, việc thử nghiệm mô hình mới do tác giả xây dựng với kho dữ liệu hiện tại của BIDV cho thấy thời gian xử lý so với mô hình MOLAP đã được rút ngắn khoảng 1 tiếng, tối ưu quá trình xử lý chuẩn bị báo cáo, phục vụ kịp thời công tác quản trị điều hành của ngân hàng

Vì vậy, thiết kế dữ liệu đa chiều theo mô hình ROLAP, có thể đảm bảo việc chuyển đổi dữ liệu, chuẩn bị báo cáo của kho dữ liệu trước 9 giờ sáng, phục vụ công tác quản trị điều hành của nghiệp vụ như mục tiêu của luận văn đã đề ra

2.2.3 Cơ chế khai thác và phân phối báo cáo

Qua phần đánh giá hệ thống kho dữ liệu ngân hàng hiện tại đã nêu trên, việc khai thác và phân phối báo cáo chỉ áp dụng được đối với bộ phận nghiệp vụ của hội sở

chính, không hỗ trợ người sử dụng chi nhánh khai thác Đa phần người sử dụng đang khai thác báo cáo trên kho dữ liệu chuyên đề và dữ liệu đa chiều bằng Excel, hệ thống chưa cung cấp được một công cụ khai thác, phân tích và phân phối dữ liệu hiệu quả Công cụ Excel của Microsoft rất mạnh về mặt thao tác tính toán dữ liệu, tuy nhiên, đối với việc khai thác dữ liệu đa chiều cũng như khai thác trên kho dữ liệu chuyên đề còn nhiều hạn chế

Một số nhược điểm của công cụ Excel khi sử dụng trên mô hình OLAP:

- Dữ liệu hiển thị tối đa 65,000 dòng đối với Excel 2003, 1 triệu dòng đối với Excel 2007 trở lên [3]

- Cơ chế hiển thị dữ liệu đa chiều không linh hoạt

Xét một ví dụ sau: Dữ liệu đa chiều có bảng fact gồm 3 triệu bản ghi, mỗi bản ghi lưu dữ liệu tiền gửi của một khách hàng Cần khai thác dữ liệu các khách hàng có tiền gửi lớn hơn 1 tỷ (Kết quả trả về khoảng 1000 khách hàng) Excel thực hiện như sau: Hiển thị tất cả dữ liệu tiền gửi, sau đó lọc các khách hàng có tiền gửi lớn hơn 1 tỷ, mặc dù thao tác lọc là được thao tác trên ứng dụng trước Như vậy, việc hiển thị 3 triệu bản ghi là không thực hiện được Đối với bài toán này, Excel không làm được và không khả thi

 Cần thiết một hệ thống khai thác, phân tích và phân phối kho dữ liệu một cách hiệu quả

2.3 Các yêu cầu kỹ thuật

2.3.1 Yêu cầu về mô hình

Đảm bảo vẫn giữ được mô hình chuẩn gồm các tầng: Datawarehouse, Data Marts, OLAP Server và Front-end tools

Data Integration (ETL, CDC & Quality)

Data Warehouse

Data Mart MIS

Data Marts Enterprise Data Warehouse

Data Mart SBV

Data Mart Risk Mgt

Data Mart ABC

Data Mart FTP

Reports

OLAP Cubes

BI

Excel, PDF, email

Hình 2.3.1.1 Mô hình chuẩn kho dữ liệu

2.3.2 Yêu cầu về khả năng đáp ứng thực tế của hệ thống

Đáp ứng yêu cầu kho dữ liệu tại BIDV với các thông số kỹ thuật cụ thể như bảng 2.3.2.1 sau [11]:

Bảng 2.3.2.1 Tiêu chuẩn kỹ thuật kho dữ liệu ngân hàng

Số người dùng đăng nhập đồng thời 160

Tốc độ tăng trưởng người dùng trong 3 năm tới ( 2012-2015) 100%

Thời gian phản hồi cho các câu truy vấn trực tiếp đã có công

thức hay biểu mẫu mà không có đồ họa

3-5 giây

Thời gian phản hồi cho các câu truy vấn trực tiếp mới ( chưa

có công thức hay biểu mẫu) và có đồ họa

15-30 giây

Khoảng thời gian lưu trữ dữ liệu trực tuyến (online/active)

của kho dữ liệu toàn ngân hàng

Bảng 2.3.2.2 Tiêu chuẩn tốc độ tăng trưởng kho dữ liệu ngân hàng

tại

Tốc độ tăng trưởng

SIBS Core-banking Khoảng 550 GB

Khoảng 30%/năm

Quản lýcán bộ 1 GB 300 MB

Quản lý thông tin dịch vụ tin nhắn 16 GB 6 GB/năm

Quản lý user tập trung 14 MB 1 GB/năm

Quản lý thông tin chi nhánh 27.5 GB 1.5 GB/năm

2.3.3 Yêu cầu kỹ thuật về công cụ trích lọc dữ liệu

Không được cài thêm bất kỳ phần mềm nào trên máy chủ nguồn dữ liệu

Công cụ ETL cho phép tích hợp dữ liệu trên nhiều hệ thống có nền tảng khác nhau

và xử lý khối lượng lớn dữ liệu

Công cụ ETL phải có giao diện đồ họa thân thiện với người sử dụng để có thể thiết

kế các “job” cho việc quản lý việc tập hợp, chuyển đổi, xác nhận và tải dữ liệu từ các nguồn khác nhau

Ứng dụng có khả năng tích hợp siêu dữ liệu (meta data) để phân tích và bảo trì Ứng dụng phải cung cấp dữ liệu có chất lượng và độ tin cậy cho việc phân tích kinh doanh và để báo cáo

Hỗ trợ tích hợp với công cụ đồng bộ dữ liệu thời gian thực

Ứng dụng cung cấp các điều khiển logic để có thể tùy chỉnh các dataflow

Cung cấp các công cụ cho việc triển khai, lập kế hoạch và theo dõi các “job”

Khi thiết kế các “job”, thì các “job” này không phụ thuộc nhiều đến cấu trúc của hệ thống, và không cần thay đổi các job khi hệ thống thay đổi tức là khi hệ thống thay đổi, được nâng cấp thì không cần phải thiết kế lại job

Ứng dụng có thể thực thi các “job” một cách song song trên nhiều CPU và hoàn toàn có khả năng mở rộng, có nghĩa là việc thiết kế các job có thể chạy trên tài nguyên của một máy tính đơn hoặc tận dụng các tính năng của nền tảng song song như cluster, GRID hay kiến trúc MPP (massively parallel processing)

Ứng dụng không cần dựa vào các chức năng xử lý của cơ sở dữ liệu để thực hiện chuyển đổi dữ liệu mà ứng dụng phải có khả năng tạo ra các câu lệnh SQL phức tạp Ứng dụng được thiết kế như một công cụ đa tích hợp dữ liệu Do đó không cần phải đầu tư các cơ sở dữ liệu để hỗ trợ công cụ này

Hỗ trợ một số lượng hầu như không giới hạn các nguồn dữ liệu kể cả có cấu trúc và không có cấu trúc: các tập tin văn bản, cấu trúc dữ liệu phức tạp trong XML, các hệ thống ERP (Enterprise resource planning) như SAP và PeopleSoft, hầu như bất kỳ cơ

sở dữ liệu nào (DB2, Sql Server,Oracle, Teradata … bao gồm cả cơ sở dữ liệu phân vùng), các dịch vụ Web, SAS, Cognos

Cho phép giải quyết các vấn đề liên quan đến xử lý khối lượng dữ liệu lớn với hiệu năng cao Bằng cách tận dụng khả năng xử lý song song của nền tảng phần cứng Có khả năng tận dụng các nguồn tài nguyên máy tính lớn hiện có để tối đa hóa giá trị của khoản đầu tư CNTT

Hỗ trợ cách thức chạy theo cơ chế batch

Hỗ trợ vòng lặp trong các đối tượng chuyển đổi

Hỗ trợ các phương thức tự tạo bản ghi để phục vụ mục đích testing

Hỗ trợ tái cấu trúc các job: hỗ trợ các toán tử join, merge, union, null-handling

Hỗ trợ các loại nguồn dữ liệu: RDBMS, XML, CLOB, BLOB

Hỗ trợ tính sử dụng lại

Tham số hoá

Chia sẻ các cấu phần con

Chọn loại database tại thời điểm chạy

Hỗ trợ quản lý người sử dụng và phân quyền đến các thành phần trên giao diện đồ hoạ

Hỗ trợ đa ngôn ngữ

2.3.4 Yêu cầu kỹ thuật về kho dữ liệu chuyên đề, dữ liệu đa chiều

Dễ bảo trì

Thời gian triển khai ngắn

Tập trung cơ sở dữ liệu cho nguồn báo cáo tập trung, khả năng xử lý và lưu trữ dữ liệu lớn Đáp ứng được bài toán xây dựng kho dữ liệu tập trung của BIDV Khả năng lưu dữ liệu lớn của BIDV: 3-5 TB, trong vòng 5 năm

Năng lực xử lý dữ liệu lớn của máy chủ và CSDL, đảm bảo tốc độ xử lý dữ liệu

Đủ năng lực xử lý hỗ trợ hàng trăm người sử dụng truy cập kho siêu dữ liệu trực tiếp cùng một lúc, qua cùng các công cụ hoặc ứng dụng phân tích Số lượng người sử dụng truy vấn đồng thời vào CSDL: 300-500 users

Độ bảo mật và an toàn của kho dữ liệu

Công cụ quản trị, vận hành kho dữ liệu chính xác và kịp thời Độ tự động hóa cao trong việc tối ưu hóa quản trị cơ sở dữ liệu

Giải pháp phải có hỗ trợ khả năng multi-platforms

Có công cụ theo giám sát health monitoring và có các hướng dẫn hỗ trợ dạng wizard cho DBA trong việc giám sát và ngăn ngừa những khả năng không mong muốn

Phải hỗ trợ khả năng lưu trữ tự động (Automatic Storage) mà không cần sự can thiệp của DBA khi dữ liệu tăng trưởng

Hỗ trợ các chuẩn mở như WebServices và Xquery

Phải có cơ chế Automatic Summary Tables với các phương pháp “refresh deferred” hoặc “immediate”

Hỗ trợ online and offline backup với mức ảnh hưởng tối thiểu tới các các hoạt động hàng ngày

Tích hợp cơ chế Adviser (wizards) để tự động thiết lập các tham số cấu hình hệ thống

Cung cấp cơ chế index, cho phép dữ liệu được tổ chức trong các cấu trúc đa chiều, thuận lợi cho việc truy vấn cũng như tải dữ liệu

Có khả năng tự tuning và tự quản lý, cung cấp cơ chế tự động và wizard để DBA nhanh chóng cấu hình, tuning và quản lý

Hỗ trợ cơ chế tối ưu hoá dựa trên cơ chế cost-based để điều khiển hiệu năng hệ thống và các câu query lớn có tự động được đặt lịch chạy ngoài giờ cao điểm

Các câu query có thể phân loại theo user profile và các cơ chế có thể được thiết lập theo sự chỉ định nguồn lực hệ thống

Hỗ trợ một giải pháp kết hợp lưu dữ liệu trong database và dữ liệu XML trong Native XML mà không cần biên dịch lại

Phải có khả năng nén dữ liệu và hỗ trợ cơ chế nén sâu với tỷ lệ hơn 50%

Dữ liệu phải được nén cả ở memory, bufferpools và trên đĩa để tăng tính hiệu quả Nén dữ liệu phải hỗ trợ các loại thao tác sau:

 Insert

 Update

 Load

2.3.5 Yêu cầu kỹ thuật về công cụ khai thác, phân phối dữ liệu

Business Intelligence (BI) là công nghệ ứng dụng thông tin vào việc ra quyết định

BI không giống với ứng dụng kho dữ liệu (Data Warehouse) chỉ quan tâm nhiều đến việc lưu trữ thông tin BI cũng toàn diện hơn ứng dụng khai thác dữ liệu (Data Mining) Với BI, thông tin thể hiện giá trị thực của nó và nhiều người có thể cùng sử dụng, cùng chia sẻ giá trị đó

Công cụ báo cáo chuyên nghiệp BI là giải pháp duy nhất cung cấp đầy đủ chức năng BI trong một sản phẩm trong một cấu trúc đơn đã được kiểm chứng Nó cho phép lập báo cáo, phân tích, lập bảng điểm so sánh, tạo bảng điều khiển và quản lý sự kiện

Nó hiển thị tất cả các hệ thống và nguồn dữ liệu Nó đơn giản hóa môi trường IT của bạn và cách thức mọi người xử lý thông tin Kết quả đạt được là mức độ áp dụng cao

hơn của người dùng, quyết định tốt hơn và đáp ứng nhanh hơn với các mối đe dọa và

cơ hội trên cả tổ chức Công cụ báo cáo chuyên nghiệp BI là một lựa chọn rõ ràng cho việc tiêu chuẩn hóa BI và là nền tảng của quản lý hiệu năng tốt hơn

Các nền tảng BI không chỉ tập trung vào báo cáo mà còn cung cấp khả năng hành động theo định hướng cái nhìn sâu sắc về dữ liệu Điều này có nghĩa là cho phép người dùng nhanh chóng nắm bắt được gốc nguyên nhân của vấn đề và có hành động đáp ứng cho sự kiện

Thông tin xác thực, kịp thời, phù hợp, dễ sử dụng và được đặt trong từng trường hợp cụ thể là những yếu tố đặc biệt quan trọng trong công nghệ BI

Yêu cầu công cụ báo cáo chuyên nghiệp BI phải thể hiện 03 tính chất sau:

 Đơn giản: Triển khai một sản phẩm trên một kiến trúc nền dịch vụ Web duy

nhất cho mọi yêu cầu về trí tuệ doanh nghiệp của công ty Kiến trúc linh hoạt, chuẩn hóa có thể được gắn gọn vào môi trường IT hiện tại Triển khai một lần

và sử dụng các năng lực theo yêu cầu của điều kiện kinh doanh và nhu cầu của người dùng đang thay đổi Cung cấp cho mọi người trong tổ chức một nguồn thông tin đáng tin cậy đơn nhất Loại bỏ việc quản lý và bảo trì các dịch vụ trùng lặp như dịch vụ bảo mật Mô hình dữ liệu đặc tả (metadata) tập trung cho phép người dùng ứng dụng các quy tắc kinh doanh nhất quán, tính toán và định

cỡ dữ liệu Triển khai Web làm đơn giản hơn nữa việc bảo dưỡng, nâng cấp và

sử dụng cho những người dùng IT và kinh doanh

nghiệp đầy đủ các chức năng BI cần thiết để cải thiện quá trình ra quyết định – báo cáo rộng, phân tích so sánh đầy đủ, bảng điều khiển tích cực, bảng điểm so sánh hữu dụng và tự động hóa quản lý sự kiện kinh doanh.Cung cấp các loại người dùng khác nhau thông tin và những năng lực BI đáp ứng được nhu cầu của họ Kết nối các hệ thống dữ liệu riêng biệt để đem đến một cái nhìn chung

về doanh nghiệp Truy vấn, báo cáo hay phân tích theo tất cả các cấu trúc dữ liệu – đa chiều (OLAP) hay dữ liệu quan hệ Ứng dụng các quy tắc kinh doanh nhất quán, tính toán vào hệ thống và nguồn điều hành của tổ chức để tạo ra một cái nhìn đầy đủ, nhất quán của bất kỳ vấn đề nào trong kinh doanh

 Đƣợc minh chứng: Công cụ báo cáo chuyên nghiệp BI được xây dựng trên

kiến trúc đã được minh chứng Sản phẩm đã được triển khai cho hàng ngàn khách hàng và đã trở thành tiêu chuẩn công ty trong lĩnh vực lập báo cáo Hệ thống BI là nhà sáng tạo có uy tín trong lĩnh vực trí tuệ doanh nghiệp

Có khả năng tích hợp được với LDAP một cách tự động

Cung cấp các tiện ích Dashboard như Metric Dials, Graphs để hiển thị và theo dõi các số liệu

Tất cả các giải pháp phân tích được cung cấp (được mô tả như khả năng ở trên) phải chia sẻ chung một kiến trúc định hướng dịch vụ, dịch vụ truy cập dữ liệu phổ biến, cơ sở hạ tầng tính toán phân tích và phổ biến, dịch vụ quản lý siêu dữ liệu phổ biến, mô hình kinh doanh phổ biến, mô hình an ninh chung và giải pháp quản lý phổ biến

Các nền tảng BI phải dựa trên cơ sở dữ liệu duy nhất, nhất quán trên các hệ thống Điều này sẽ đảm bảo rằng người dùng doanh nghiệp có quan điểm thống nhất của tất

cả các thông tin có thể truy cập

Người sử dụng cuối cùng sẽ có thể tương tác trực quan với lớp BI bằng cách sử dụng qua nhiều kênh phân phối Điều này có nghĩa là người dùng cuối có thể truy cập các kênh phân tích có liên quan thông qua web và điện thoại di động

Các nền tảng BI phải cung cấp khả năng để làm phân tích trên cả dữ liệu tác nghiệp (OLTP các hệ thống) và dữ liệu lịch sử (hệ thống kho dữ liệu) Cụ thể cho phép phân tích nâng cao trên các hệ thống hoạt động lưu trữ trên trung tâm dữ liệu, nền tảng BI phải cung cấp hỗ trợ cho khả năng như ETL, giám sát hoạt động nghiệp vụ (Business Activity Monitoring), các dữ liệu liên kết (Federated data), truy cập dữ liệu trực tiếp từ các hệ thống OLTP

BI có thể làm việc liên tục với bất kỳ ứng dụng nguồn dữ liệu kinh doanh phổ biến,

và cơ sở hạ tầng an ninh

Lớp trình bày của nền tảng BI phải được dựa trên kiến trúc thuần túy của web trên nền tảng HTML, DHTML và JavaScript, không cần tải thêm các phần mềm cũng như không cần plug-in, ActiveX và Applet

Người dùng cuối có thể cá nhân hoá các cấu trúc của giao diện làm việc của họ bao gồm xác định các view, bố trí bảng biểu, và các bảng pivot…

Có thể chạy trên các platform như Redhat Linux, MS Windows, IBM và HP

Giải pháp cần phải có khả năng để xác thực quyền sử dụng trong ứng dụng

Có khả năng tích hợp với LDAP, AD và các hệ thống Single Sign On (SSO)

Dữ liệu nội bộ và dữ liệu truyền phải được mã hóa

Các tập tin tạm thời nội bộ được tạo ra ở phía máy chủ cũng phải được mã hóa và đảm bảo tính bảo mật

Phải có giải pháp bảo mật ở các mức cube level, table level, row và column cũng như mức cell level

Tính năng Báo cáo: Giúp mang lại những thông tin thường xuyên, kịp thời và cho phép người dùng truy vấn để có thông tin chi tiết hơn

Tính năng Phân tích: Phân tích OLAP theo nhiều chiều giúp so sánh các thông tin theo nhiều tiêu chí và từ đó có thể tìm ra được xu hướng của tình hình

Tính năng Scorecarding (đo lường, đánh giá hoạt động): Thể hiện những tiêu chí quan trọng đánh giá hoạt động và cho bạn biết rằng liệu mình có vượt qua được ngưỡng đã đề ra hay không

Tính năng Dashboard: Thể hiện góc nhìn tổng quan tình hình hoạt động giúp trình bày thông tin với hình thức trực quan, dễ hiểu và gắn liền với tình huống cụ thể

2.4 Các giải pháp công nghệ

2.4.1 Giải pháp của Microsoft

Microsoft cung cấp giải pháp về kho dữ liệu khá toàn diện với SQL Server, Integration Services và hệ thống Analysis Services, là giải pháp tương đối phổ biến trên thế giới [8]

Ưu điểm giải pháp:

- Thân thiện, dễ dùng, dễ phát triển

- Tích hợp toàn diện với hệ thống Microsoft Office

Nhược điểm:

- Hạn chế khi xử lý số lượng dữ liệu lớn

- Hệ thống bảo mật kém do sử dụng nền tảng Windows

2.4.2 Giải pháp của Oracle

Oracle được đánh giá là một trong những giải pháp hàng đầu trong việc lưu trữ dữ liệu, lợi thế của giải pháp là phát triển trên nền tảng CSDL Oracle chiếm 41.3% thị phần kho dữ liệu Năm 2008 Oracle giới thiệu giải pháp Oracle Exadata kết hợp với máy chủ HP Năm 2009 Oracle chuyển nền tảng sang SUN Năm 2010 Oracle mua lại SUN Máy chủ Exadata được phát triển mang thương hiệu Oracle Exadata Database Machine [9]

Ưu điểm giải pháp:

- Oralce đưa ra các gói giải pháp khá linh động: Oracle Database 11g, hệ thống CSDL Oracle trên máy chủ, storage đã được xác thực hoặc hệ thống Appliant Exadata Bằng việc mua lại Sun Oracle đưa ra giải pháp tổng thể cả phần cứng, phần mềm do

đó khách hàng chỉ cần 1 nhà cung cấp duy nhất

- Oracle 11g cải thiện đáng kể materialized view và quản lý cube tăng tính hiệu quả trong việc triển khai kho dữ liệu Thêm vào đó Oracle 11g bổ sung tính tăng Partition Advisor thuận tiện hơn cho việc thiết kế kiểu dữ liệu ứng với kiến trúc partition

- Giải pháp Oracle Exadata được trang bị các tính năng Smart Scan, Hybrid Columnar Compression, Exadata Smart Flash Cache (có thể nạp tới 5TB trên ổ Flash) làm tăng hiệu năng hệ thống gấp 10 lần so với chạy Oracle Stand Alone