Tải bản đầy đủ (.pdf) (75 trang)

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

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.49 MB, 75 trang )


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






Hà Nội – 2013

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

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Ô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
1
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
2
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




3
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
4

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

Từ viết tắt
Nghĩa của 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

5
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
6
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
7
MỞ ĐẦU

Hiện tại mỗi hệ thống ngân hàng tại Việt Nam có khoảng vài triệu khách hàng và
mục tiêu đặt ra là thu hút được càng nhiều khách hàng càng tốt. Để đạt được mục tiêu
đề ra, hệ thống nghiệp vụ cần quản lý hiệu quả hoạt động kinh doanh của mình thông
qua sự hỗ trợ của hệ thống kho dữ liệu ngân hàng (Banking Data Warehouse).
Việc xây dựng hệ thống kho dữ liệu cho ngân hàng đã được nghiên cứu và xây
dựng trong thời gian qua, hỗ trợ tốt cho công tác dự báo, phân tích và ra quyết định
kinh doanh trong thời gian ngắn nhất.
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.

8
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).
9
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.
10
 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)
 Chăm sóc sức khỏe
 Viễn thông
 …
1.2. Hệ thống kho dữ liệu trong ngân hàng
1.2.1. Giới thiệu
Hệ thống kho dữ liệu do nhà thầu Silver Lake xây dựng cung cấp một nền tảng báo
cáo quản trị điều hành theo công nghệ OLAP SQL Server 2000 cho ngân hàng TMCP
Đầu tư và Phát triển Việt Nam. Các thông tin sau được tham khảo từ các tài liệu của
ngân hàng nơi tác giả đang công tác [11].
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

 …
Cho phép người dùng phân tích dữ liệu theo nhiều chiều, khoan sâu dữ liệu theo
nhiều lớp (sử dụng công nghệ OLAP).
Giao diện khai thác phía người sử dụng cuối là Microsoft Excel, sử dụng công
nghệ Pivot Table để giao tiếp với cơ sở dữ liệu của kho dữ liệu.
Kho dữ liệu được xây dựng trên nền tảng AS/400, kết hợp với Microsoft SQL
Server 2000, hệ điều hành Windows NT/2000.
11
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, )
DTS DTS
DTS

Hình 1.2.2.1. Kiến trúc của hệ thống kho dữ liệu ngân hàng
DD
CD
LN
GL
ATM
Transformation
Staging
Database
Transformation
EDM
DATA MART
AS400
AS400 AS400 NT SERVER
Front-end
Windows Client
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ữ
12
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
DD
CD
LN
GL
ATM
AS400
Transformation
Staging
Database
AS400
DTS
EXTRACTION
NT SERVER

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
SOURCE
DATA

DD
CD
LN
GL
ATM
AS400
Transformation
Staging
Database
AS400
13
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ễ
Enterprise Data
Model
EDM
AS400
Front-end
Windows Client
DATA MART
NT SERVER
14
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.
 Tham số
Tham số được sử dụng để mô tả thông tin trong những bảng dữ liệu chính (master
tables). Chúng đóng một vai trong quan trọng là thiết lập những kết nối giữa các mục
dữ liệu mà có chung những thuộc tính, được định nghĩa trong bảng tham số (parameter
tables). Hầu như tất cả những bảng dữ liệu chính có liên quan với nhau thông qua
những tham số.
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
Officer_Name
Branch_ID
Branch_ID Branch_Name
001 Chi nhánh Hà Nội
002 Chi nhánh Cầu Giấy
003 Chi nhánh Hà Đông
004 …
Bảng tham số zBranch


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ử.
15
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
1
n
n n
1
n

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

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.
 zACC
zACC lưu tất các các mức thông tin tài khoản, không phân biệt nguồn gốc của tài
khoản. Tuy nhiên thông tin mức giao dịch sẽ không được lưu trong bảng này.
Khóa duy nhất của zACC là trường số tài khoản Acc_ID, bao gồm trường số ID chi
nhánh và số ID chi nhánh con.
zACC rất lớn, nó có 80 trường, các thước đo giá trị (measure) trong zACC được tách
thành nhiều phần, bao gồm tài sản có, tài sản nợ, thu nhập, chi phí, dự phòng tài sản nợ -
tài sản có (Contingency Assets and Contingency Liabilities), sau đó tiếp tục chia thành
các giá trị trung bình, dư có, dư nợ …
 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.
17
1.2.4. Quá trình xử lý dữ liệu trong hệ thống kho dữ liệu
a. Chuẩn bị dữ liệu
DD
CD
LN
GL

ATM
Transformation
Staging
Database
Enterprise Data
Model
EDM
DATA MART
AS400
AS400 AS400 NT SERVER
Front-end
Windows Client
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.
18
b. Chuyển đổi dữ liệu vào Enterprise Data Model (EDM)
DD
CD
LN
GL
ATM
Transformation
Staging
Database
Transformation
EDM
DATA MART
AS400
AS400 AS400 NT SERVER
Front-end
Windows Client
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.
19
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.
20
c. Chuẩn bị báo cáo (The Final Reports)
DD
CD
LN
GL
ATM
Transformation
Staging
Database
Transformation
EDM
DATA MART

AS400
AS400 AS400 NT SERVER
Front-end
Windows Client
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.
21
- 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 DTS
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.
22
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.
23
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.

DTS
SERVER
EXTRACT LOAD
TRANSFORM
SOURCE DESTINATION

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

×