Nguyễn Quang Hưng - cđtt (Recovered)

Nguyễn Quang Hưng Chuyên Đề Thực Tập
MỤC LỤC
CHƯƠNG I:TỔNG QUAN VỀ CƠ SỞ THỰC TẬP VÀ ĐỀ TÀI NGHIÊN CỨU..............................7
1.1. TỔNG QUAN VỀ CÔNG TY GIẢI PHÁP PHẦN MỀM TÀI CHÍNH FSS...................................7
1.1. 1.Giới thiệu chung về công ty FSS...............................................................................................7
1.1.2. Thực trạng hoạt động tại công ty...............................................................................................9
1.2. TỔNG QUAN VỀ ĐỀ TÀI............................................................................................................10
1.2.1. Lý do chọn đề tài.....................................................................................................................10
1.2.2. Mục tiêu và phạm vi nghiên cứu..............................................................................................11
1.2.3. Phương pháp và phạm vi nghiên cứu.......................................................................................11
1.2.4. Nội dung đề tài........................................................................................................................11
CHƯƠNG II: CƠ SỞ PHƯƠNG PHÁP LUẬN....................................................................................12
2.1. LÝ THUYẾT KHO DỮ LIỆU(DATA WAREHOUSE)................................................................12
2.1.1.Tổng quan về kho dữ liệu.............................................................................................................12
2.1.2. Đặc trưng kho dữ liệu..............................................................................................................12
2.1.3. Kiến trúc kho dữ liệu...............................................................................................................14
2.1.4. Lược kho dữ liệu......................................................................................................................16
2.1.5.Thiêt kế vật lý...........................................................................................................................17
2.1.6. Đối tượng trong kho dữ liệu.....................................................................................................18
2.1.7. Datamart, EDW trong kho dữ liệu và Bussiness Intelligence..................................................19
2.2.HIỆN TRẠNG HỆ THỐNG KHO DỮ LIỆU TRONG NGÂN HÀNG BIDV................................22
2.2.1. Tổng quan hệ thống báo cáo trong ngân hàng..........................................................................22
2.2.2. Kiến trúc của kho dữ liệu trong ngân hàng..............................................................................22
2.2.3 Đánh giá các mặt hạn chế của hệ thống kho dữ liệu hiện tại.....................................................23
2.2.4. Một số giải pháp công nghệ mới về kho dữ liệu......................................................................25
2.2.5.Kết luận....................................................................................................................................26
CHƯƠNG III: ỨNG DỤNG QUY TRÌNH ETL VÀO XÂY DỰNG QUẢN LÝ THÔNG TIN GIAO
DỊCH NGÂN HÀNG BIDV VÀ THỰC HÀNH ĐẨY DỮ LIỆU TỪ SATGING LÊN DATAMART
.................................................................................................................................................................. 27
3.1. GIỚI THIỆU VỀ CÔNG CỤ..........................................................................................................27
3.1.1.Giới thiệu về công cụ Designer Client......................................................................................27
3.1.2.Giới thiệu về công cụ Dbeaver..................................................................................................29
3.2. Khái quát quy trình ETL và mục tiêu thiết kế kho dữ liệu..............................................................33
3.2.1. Khái quát quy trình ETL trong kho dữ liệu..............................................................................33
1
3.2.2. Mục tiêu phân tích thiết kế kho dữ liệu....................................................................................33

3.3. Quy tắc đặt tên ETL........................................................................................................................33
3.3.1. Job...........................................................................................................................................33
3.3.2. Stage connection trong job.......................................................................................................34
3.4. Tầng Staging...................................................................................................................................34
3.4.1. Các bảng Master......................................................................................................................34
3.4.2. Summary..................................................................................................................................42
3.4.3. Job Today................................................................................................................................47
3.4.3. Job Preday..........................................................................................................................49
3.4.4. Job Minus................................................................................................................................50
3.5. Tầng Atomic...................................................................................................................................70
3.5.1 Các vùng trong Atomic.............................................................................................................70
3.5.2 Sơ đồ tổng quát của Atomic......................................................................................................71
3.5.3. ETL tầng Atomic.....................................................................................................................73
3.5.4. Tạo job tầng Atomic................................................................................................................75
3.6. Tầng Data Mart...............................................................................................................................88
3.6.1. Tổng quát về DataMart, Dimension và Fact............................................................................88
3.6.2. Các job DIMENSION trong DataMart....................................................................................91
3.6.3. Các Job Fact trong Datamart..................................................................................................100
3.7.KẾT QUẢ SAU KHI ĐẨY DỮ LIỆU TỪ STAGING VÀO DATAMART.................................111
3.7.1. Dữ liệu bảng đích CCY_DIM_2022(Currency Dimension)...................................................111
3.7.2. Dữ liệu bảng đích RI_DIM_2022(Resource Item Dimension)...............................................112
3.7.3. Dữ liệu bảng đích AR_ANL_2022(Arrangement Analyst Fact)............................................113
3.7.4. Dữ liệu bảng đích RI_ANL_2022(Resource Item Dimension)..............................................113
3.7.5. Dữ liệu bảng đích CST_DIM_2022(Customer Dimension)...................................................113
3.7.6. Dữ liệu bảng đích PD_DIM_2022(Product Dimension)........................................................114
3.7.7. Dữ liệu bảng đích OU_DIM_2022(Organization Unit Dimension).......................................114
3.7.8. Dữ liệu bảng đích CARD_AR_FCT_2022(Card Arrangement Fact).....................................114
3.7.9. Dữ liệu bảng đích CST_AR_ANL_2022(Customer Arrangement Analyst Dimension)........115
2
DANH MỤC HÌNH ANHR
Hình 3. 1: Màn hình đăng nhập vào IBM Infosphere DataStage................................................................28

Hình 3. 2: Giao dện IBM Infosphere Data..................................................................................................29
Hình 3. 3: Giao diện Dbeaver.....................................................................................................................31
Hình 3. 4: Màn hình kết nối Database.......................................................................................................32
Hình 3. 5: Quy trình ETL.............................................................................................................................33
Hình 3. 6: ETL các bảng Master..................................................................................................................35
Hình 3. 7: ETL các bảng Summary..............................................................................................................43
Hình 3. 8: Chạy job today bảng IFTB_Master.............................................................................................49
Hình 3. 9: Chạy job Preday bảng IFTB_Master...........................................................................................51
Hình 3. 10: Chạy job Minus bảng IFTB_Master..........................................................................................53
Hình 3. 11: Chạy job minus IFTB_Card_Master.........................................................................................56
Hình 3. 12: Chạy job Minus của bảng IFTB_BRANCH.................................................................................59
Hình 3. 13: Chạy ob MINUS của bảng IFTB_Currency................................................................................62
Hình 3. 14: Chạy job Minus của bảng IFTB_CUSTOMER............................................................................65
Hình 3. 15: Chạy job MINUS của bảng IFTB_DEP_MASTER........................................................................68
Hình 3. 16: Chạy job MINUS của bảng IFTB_LOAN_MASTER.....................................................................71
Hình 3. 17: Các thực thể chính và quan hệ trong Atomic..........................................................................72
Hình 3. 18: ETL vùng Atomic cho vùng Involved Party...............................................................................74
Hình 3. 19: Quy trình chạy ETL vùng Atomic cho vùng Arrangement........................................................74
Hình 3. 20: Chạy job tạm vùng Atomic của Resource Item Val..................................................................75
Hình 3. 21: Chạy job đích vùng Atomic của Resource Item Val..................................................................76
Hình 3. 22: Chạy job tạm vùng Atomic của Resource Item X IP.................................................................77
Hình 3. 23: Chạy job đích vùng Atomic của Resource Item X IP.................................................................78
Hình 3. 24: Chạy job vùng Atomic của Resource Item...............................................................................79
Hình 3. 25: Chạy job đích vùng Atomic của Resource Item........................................................................80
Hình 3. 26: Chạy job tạm vùng Atomic của Organization Unit...................................................................81
Hình 3. 27: Chạy job đích vùng Atomic của Organization Unit..................................................................82
Hình 3. 28: Chạy job tạm vùng Atomic của Involved Party X IP.................................................................83
Hình 3. 29: Chạy job đích ùng Atomic của Involved Party X IP...................................................................84
Hình 3. 30: Sơ đồ mô hình logic các Dimension chính...............................................................................90
Hình 3. 31: Chạy job tạm vùng Datamart của Currency.............................................................................92
Hình 3. 32: Chạy job đích ùng DataMart của Currency..............................................................................93
Hình 3. 33: Chạy job tạm vùng DataMart vủa Customer...........................................................................95
Hình 3. 34: Chạy job đích vùng DataMart của Customer...........................................................................96
Hình 3. 35: Chạy job tạm vùng DataMart của Arrangement Analysis Fact..............................................103
Hình 3. 36: Chạy job đích vùng DataMart của Arrangement Analysis Fact..............................................105
Hình 3. 37: Chạy job tạm vùng DataMart của Card Arrangement Analysis Fact......................................106
Hình 3. 38: Chạy job đích vùng DataMart của Card Arrangement Analysis Fact......................................108
3
Hình 3. 39: Dữ liệu bảng đích CCY_DIM_2022.........................................................................................111

Hình 3. 40: Dữ liệu bảng đích RI-DIM_2022.............................................................................................112
Hình 3. 41: Dữ liệu bảng đích AR_ANL_2022...........................................................................................113
Hình 3. 42: Dữ liệu bảng đích CST_DIM_2022.........................................................................................113
Hình 3. 43: Dữ liệu bảng OU_DIM_2022.................................................................................................114
Hình 3. 44: Dữ liệu bảng đích CARD_AR_FCT_2022.................................................................................114
Hình 3. 45: Dữ liệu bảng đích CST_AR_ANL_2022...................................................................................115
4
LỜI NÓI ĐẦU

Cùng với sự phát triển nhanh chóng và không ngừng mở rộng quy mô của các tổ chức tài
chính ngân hàng, trong quá trình hoạt động khối lượng dữ liệu thông tin lưu trữ ngày
càng gia tăng. Trong suốt quá trình phát triển đó việc thu thập và xử lý kho dữ liệu khổng
lồ ngày càng trở lên quan trọng hơn bao giờ hết. Việc tổ chức lưu trữ và khai thác kho dữ
liệu một cách hiệu quả sẽ giúp cho các tổ chức tài chính ngân hàng thực hiện tốt công tác
quản trị điều hành, quản trị rủi ro, hỗ trợ ra quyết định và hoạch định chiến lược kinh
doanh. Hệ thống kho dữ liệu trong ngân hàng sẽ giúp xây dựng một nền tảng dữ liệu và
công nghệ mạnh mẽ, tin cậy, giúp đáp ứng các yêu cầu hiện tại và nhu cầu phát triển và
mở rộng trong tương lai. Là trung tâm của các hệ thống phân tích thông tin, dữ liệu toàn
ngân hàng sẽ được hợp nhất tại kho dữ liệu. Nhằm đáp ứng và cung cấp thông tin một
cách kịp thời, chính xác, đồng thời là nền tảng cho việc xây dựng các ứng dụng phân tích
dữ liệu, hỗ trợ ra quyết định.
Với thực trạng hiện nay của ngân hàng, việc phân tích quy trình ETL trong kho dữ liệu để
đáp ứng cho việc quản lý một số lượng dữ liệu lơn trong ngân hàng là điều vô cùng cần
thiết. Thông qua những kiến thức đã học ở trường, và những điều học hỏi được trong quá
trình thực tập tại công ty FSS. Em xin chọn đề tài “Phân tích quy trình ETL trong kho
dữ liệu để quản lý thông tin của ngân hàng BIDV”
Nội dung chính của đề tài gồm 3 chương:
Chương 1: Tổng quan về cơ sở thực tập và đề tài nghiên cứu
Chương 2: Cơ sở phương pháp luận
Chương 3: Ứng dụng quy trình ETL vao xây dụng quản lý thông tin giao dịch ngân hàng
BIDV và thực hành đẩy dữ liệu từ Staging lên Datamart
Cuối cùng là kết luận và hướng phát triển tiếp theo của đề tài trong tương lai
5
6
CHƯƠNG I:TỔNG QUAN VỀ CƠ SỞ THỰC TẬP VÀ ĐỀ TÀI NGHIÊN CỨU

1.1. TỔNG QUAN VỀ CÔNG TY GIẢI PHÁP PHẦN MỀM TÀI CHÍNH FSS
1.1. 1.Giới thiệu chung về công ty FSS
GIỚI THIÊU CÔNG TY
Công ty cổ phần giải pháp phần mềm tài chính (FSS) được thành lập ngày
18/03/2008 bởi các chuyên gia đã có nhiều năm kinh nghiệm trong việc phát triển và
triển khai giải pháp công nghệ thông tin cho các đơn vị hoạt động trong lĩnh vực tài
chính, ngân hàng, chứng khoán tại Việt Nam và khu vực.
Sau hơn 12 năm hoạt động, với một đội ngũ hơn 250 chuyên gia làm việc trong
lĩnh vực phần mềm, FSS đã trở thành một trong những công ty phần mềm tài chính –
ngân hàng hàng đầu tại Việt Nam và được nhiều khách hàng tin tưởng, lựa chọn. Khách
hàng của FSS bao gồm các ngân hàng và các công ty chứng khoán lớn như BIDV,
TechcomBank, VPBank, MBBank, VNDirect, VCBS, BSC, BVSC,…
Với phương châm hoạt động dựa trên sự cam kết lâu dài, tính chuyên nghiệp cao
và hiểu biết sâu sắc nhu cầu khách hàng, FSS luôn nỗ lực hết mình để mang lại sự thành
công và lợi ích lâu dài cho khách hàng.
SỨ MỆNH – TẦM NHÌN
Công ty cổ phần giải pháp phần mềm tài chính FSS mong muốn và không ngừng
nỗ lực để trở thành công ty hàng đầu ở Việt Nam và có tên tuổi trong khu vực trong lĩnh
vực cung cấp sản phẩm và dịch vụ phần mềm tài chính – ngân hàng; thông qua các sản
phẩm, dịch vụ của mình mang lại sự thành công cho khách hàng, cổ đông, nhân viên
công ty và đóng góp cho cộng đồng
GIÁ TRỊ CỐT LÕI
Kinh nghiệm và đội ngũ
Đội ngũ nhân sự của FSS bao gồm các chuyên gia hàng đầu trong lĩnh vực phần
mềm tài chính – ngân hàng tại Việt nam. Với việc liên tục làm việc và tích lũy kinh
nghiệm trong lĩnh vực này 15 - 20 năm, FSS có khả năng thấu hiểu được các yêu cầu
nghiệp vụ của khách hàng, qua đó đưa ra những giải pháp công nghệ phù hợp nhất, đảm
bảo quá trình triển khai dự án thành công.
Sản phẩm
Các sản phẩm của FSS được nghiên cứu, đầu tư xây dựng dựa trên các chuẩn mực
quốc tế về sản phẩm phần mềm, đồng thời kết hợp giữa các kiến thức nghiệp vụ chuẩn
quốc tế với các thực tiễn nghiệp vụ tại Việt Nam. Các sản phẩm phần mềm sàn giao dịch
7
vàng, sàn giao dịch hàng hóa, core giao dịch chứng khoán của FSS đều được đánh giá
thuộc loại sản phẩm tốt nhất trên thị trường Việt Nam.
Cam kết lâu dài
FSS luôn cam kết cao và lâu dài với khách hàng và thị trường. Các dự án do FSS triển
khai có tỷ lệ thành công 100%. Ngoài ra, FSS liên tục đầu tư vào phát triển sản phẩm và
đội ngũ nhằm mục đích cung cấp được các sản phẩm và dịch vụ tốt nhất không những
hiện tại mà cả tương lai. Một trong những mục tiêu chiến lược của FSS là đồng hành
cùng khách hàng trong suốt quá trình phát triển của khách hàng.
Quy trình phù hợp
FSS không áp dụng một quy trình xây dựng và triển khai phần mềm chung cho tất cả các
dự án. Ở FSS, mỗi loại hình dự án được nghiên cứu, xây dựng và áp dụng một quy trình
phù hợp, bao gồm từ tổ chức dự án, các bước tiến hành dự án đến các mẫu biểu chi tiết
cho loại hình dự án đó.
LĨNH VỰC HOẠT ĐỘNG
FSS hoạt động trong lĩnh vực cung cấp và triển khai các sản phẩm dịch vụ phần mềm cho
các ngân hàng, công ty chứng khoán và các tổ chức tài chính. Hiện tại, FSS cung cấp và
triển khai các sản phẩm dịch vụ phần mềm cho 3 lĩnh vực chính:
Cung cấp và triển khai hệ thống core giao dịch chứng khoán.
Triển khai hệ thống Data warehouse & Business Intelligence cho các ngân hàng.
Cung cấp các dịch vụ tư vấn, phát triển và triển khai phần mềm theo yêu cầu cho các
khách hàng lớn như Tổng cục thuế, Trung tâm Lưu ký Chứng khoán Việt Nam....
Vào năm 1977, Larry Ellison, Bob Miner, và Ed Oates thành lập một công ty và đặt tên là
Relation Software Incorporated(RSI). Công ty này xây dựng một hệ quản trị cơ sở dữ liệu
gọi là Oracle. Ellison, Miner và Oates quyết định phát triển hệ này bằng C và giao tiếp
SQL. Ngay sau một thời gian ngắn, họ đưa ra phiên bản một như một nguyên mẫu. Năm
1979, RSI phân phối sản phẩm đầu tiên cho khách hàng: hệ quản trị cơ sở dữ liệu Oracle
phiên bản 2, làm việc trên Digital PDP-11 chạy hệ điều hành RSX-11 và ngay sau đó
chuyển sang hệ thống DEC VAX.
Năm 1983 phiên bản 3 được giới thiệu với những thay đổi trong ngôn ngữ SQL. Không
như các phiên bản trước đây , phiên bản 3 được viết toàn bộ bằng C. Vào thời điểm này ,
RSI được đổi tên thành Oracle Corporation.
Phiên bản 4 được phát hành vào năm 1984. Phiên bản 5 được giới thiệu vào năm 1985,
là mốc lịch sử vì nó đưa công nghệ Client/ Server vào thị trường với việc sử dụng
SQL*Net.
8
Năm 1988, Oracle đưa ra phiên bản 6, giới thiệu việc khoá ở mức thấp. Oracle 7 được
phát hành năm 1992 bao gồm nhiều thay đổi kiến trúc về bộ nhớ, CPU và tiện ích xuất
/nhập. Năm 1997 Oracle giới thiệu Oracle8, thêm phần mở rộng đối tượng cũng như
nhiều tính năng và công cụ quản trị mới đặc biệt Oracle 8i phiên bản hỗ trợ nhiều tính
năng mới và đặc biệt là các ứng dụng cơ sở dữ liệu Internet.
1.1.2. Thực trạng hoạt động tại công ty
Hệ thống giao dịch chứng khoán FLEX
FLEX là hệ thống phần mềm quản lý và giao dịch chứng khoán được thiết kế dựa trên
kiến trúc nền tảng tài chính (financial framework), với các tham số linh hoạt, cho phép
các công ty chứng khoán vừa đẩy mạnh kinh doanh bằng cách đa dạng hóa sản phẩm, vừa
kiểm soát được các rủi ro gắn liền với các sản phẩm đó. FLEX cũng hỗ trợ tự động hóa
hoàn toàn quy trình giao dịch của công ty chứng khoán, tối ưu hóa hiệu quả hoạt động
của công ty chứng khoán.
Những đặc điểm nổi bật của Hệ thống quản lý và giao dịch chứng khoán FLEX bao gồm:
• Giao dịch trực tuyến: các giao dịch được hiện từ xa, mọi lúc, mọi nơi và an toàn qua tất
cả các kênh giao dịch web trading, home trading, mobile trading.
• Tham số linh hoạt cho phép các công ty chứng khoán thiết kế các sản phẩm nghiệp vụ
và chính sách cho nhà đầu tư đa dạng, linh hoạt; đặc biệt là các sản phẩm và dịch vụ tài
chính: margin, ứng trước, cầm cố, bảo lãnh...
• Kiểm soát rủi ro chặt chẽ: rủi ro quy trình, rủi ro sản phẩm, rủi ro từ phía nhà đầu tư, rủi
ro chính sách…
• Tự động xử lý nhiều loại nghiệp vụ
• Tích hợp dễ dàng với các hệ thống khác như: hệ thống giao dịch của Sở giao dịch chứng
khoán, hệ thống core banking của Ngân hàng, phần mềm kế toán nội bộ, hệ thống đặt
lệnh Bloomberg, Reuters…
• Resfull Open API: Cho phép các hệ thống, các công cụ giao dịch, các robot trading có
thể dễ dàng tích hợp giao dịch qua hệ thống FLEX.
• Tăng khả năng cạnh tranh, giảm chi phí hoạt động và hỗ trợ ra quyết định.
FLEX hiện đã được triển khai thành công ở hơn 20 công ty chứng khoán và được đánh
giá là một trong những sản phẩm core chứng khoán tốt nhất trên thị trường Việt Nam
hiện nay. Danh sách các công ty chứng khoán sử dụng sản phẩm Flex bao gồm: công ty
chứng khoán VNDirect, công ty chứng khoán Vietcombank, công ty chứng khoán Bảo
Việt, công ty chứng khoán BIDV, công ty chứng khoán KBSV, công ty chứng khoán Phú
Hưng, công ty chứng khoán Techcombank….
9
Với những tính năng ưu việt của mình, FLEX chắc chắn sẽ là lựa chọn hàng đầu của các
công ty chứng khoán về hệ thống phần mềm lõi chứng khoán triển khai tại công ty mình.
Hệ thống giá vốn nội bộ và phân bổ chi phí iFTP
Sản phẩm iFTP được FSS xây dựng dựa trên nền tảng cơ sở dữ liệu Data warehouse của
Ngân hàng. Sản phẩm iFTP cung cấp bộ tham số linh hoạt, cho phép Ngân hàng tự khai
báo các công thức tính toán giá vốn và phân bổ chi phí, đồng thời hỗ trợ tốt các ngoại lệ
đặc thù tại thị trường ngân hàng Việt Nam.
iFTP hỗ trợ các bộ phận nghiệp vụ:
Khai báo giá mua/bán vốn nội bộ trong ngân hàng
Khai báo công thức và các bước phân bổ chi phí cho các khối/phòng ban
Bộ báo cáo về giá mua bán vốn, NIM, PnL của từng tài khoản/khách hàng
Bộ báo cáo phân bổ chi phí: Báo cáo PnL trước và sau phân bổ chi phí theo từng khối,
phòng ban, bộ phận.
Hiện tại sản phẩm FTP&Cost Allocation đã được triển khai thành công tại Ngân hàng
TMCP Hàng Hải Việt Nam (Maritime Bank) và Ngân hàng TMCP Đại chúng Việt Nam
(PVcomBank), Ngân hàng TMCP Tiên Phong (TPBank), Ngân hàng TMCP Quốc Dân
(NCB) và Ngân hàng Bưu Điện Liên việt (LienVietPostBank).
1.2. TỔNG QUAN VỀ ĐỀ TÀI
1.2.1. Lý do chọn đề tài
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.
10
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ụ.
1.2.2. Mục tiêu và phạm vi nghiên cứu
Trên cơ sở tính cấp thiết và tính thực tiễn của việc triển 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ụ. Em đã nghiên cứu và tìm
hiểu, chọn đề tài là “Phậno tích quy trình ETL trong kho dữ liệu để quản lý thông tin
trong ngân hàng BIDV”.
Đây là một vấn đề lớn và khó khăn, em bước đầu đã tìm hiểu và làm chủ được kiến thức
về ETL và kiến trúc kho dữ liệu. Mục đích của chuyên đề thực tập 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
BIDV đá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
1.2.3. Phương pháp và phạm vi nghiên cứu.
Đây là đề tài 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 IntelligenceDiscover
Nghiên cứu quy trinhg ETL để xây dựng kho dữ liệu phù hợp với thực trạng về nhân lực,
tại Ngân hàng BIDV.
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 BIDV.
11
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.
1.2.4. Nội dung đề tài.
Đề tài được tổ chức thành các nội dung chính như sau:
CHƯƠNG II: CƠ SỞ PHƯƠNG PHÁP LUẬN

2.1. LÝ THUYẾT KHO DỮ LIỆU(DATA WAREHOUSE)
2.1.1.Tổng quan về kho dữ liệu.
2.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.
2.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ủakho 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) "
2.1.2. Đặc trưng kho dữ liệu.
2.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
12
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.
2.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.
2.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
2.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.
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.
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.
13
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.
2.1.3. Kiến trúc kho dữ liệu.
2.1.3.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ừ 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
2.1.3.2. Kiến trúc kho dữ liệu với 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.
2.1.3.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
2.1.3.5. Thiết kế kho dữ liệu
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:
14
Nội dung dữ liệu cụ thể.

Mối quan hệ bên trong và giữa các nhóm dữ liệu.
Môi trường hệ thống hỗ trợ kho dữ liệu.
Quá trình biến đổi dữ liệu cần thiết.
Tần suất mà dữ liệu được làm mới.
Thiết kế logic xem xét các mối quan hệ logic giữa các chủ thể. Thiết kế vật lý xem xét
cách thức hiệu quả nhất của việc lưu trữ và gọi ra các đối tượng, cũng như xử lý chúng từ
một chuyển dịch và quan điểm sao lưu, phục hồi.
Thiết kế hướng tới các nhu cầu của người dùng cuối. Người dùng cuối thường muốn thực
hiện phân tích và xem xét dữ liệu tổng hợp, hơn là giao tác riêng lẻ. Tuy nhiên, người
dùng cuối có thể không biết những gì họ cần cho đến khi họ nhìn thấy nó. Ngoài ra, một
thiết kế được lên kế hoạch chu đáo có tính đến sự tăng trưởng và thay đổi khi nhu cầu của
người dùng thay đổi và tiến hóa. Với thiết kế logic, tập trung vào các yêu cầu thông tin và
lưu các chi tiết thực thi cho sau này.
2.1.3.6. 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
15
trường dữ liệu, xác định các mối quan hệ giữa các chủ thể kinh doanh, và tên các thuộc
tính cho mỗi chủ thể.
Thiết kế logic kết quả nên là một tập thực thể và thuộc tính tương ứng
với các bảng sự kiện và các bảng chiều và một mô hình của dữ liệu hoạt động
từ nguồn thành thông tin hướng chủ thể trong lược đồ kho dữ liệu đích. Ta có thể tạo ra
những thiết kế logic sử dụng bút và giấy, hoặc sử dụng một công cụ thiết kế như Oracle
Warehouse Builder, đặc biệt được thiết kế để hỗ trợ cho mô hình hóa quá trình ETL; hoặc
Oracle Designe, một công cụ mô hình hóa mục đích chung.
2.1.4. Lược kho dữ liệu.
2.1.4.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).
2.1.4.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. 11: Lược đồ hình bông tuyết.
2.1.4.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
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.
Lược đồ bông tuyết
16
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ý
Dễ hiểu
Chỉ có một bảng chiều cho Nhiều hơn 1 bảng chiều cho mỗi Chiều bảng mỗi chiều. Bảng
chiều không theo chuẩn 3NF. Bảng chiều chuẩn hóa theo 3NF. 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
Các truy vấn là rất đơn giản và dễ hiểu
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
2.1.5.Thiêt kế vật lý.
2.1.5.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 OracleWarehouse 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ết kế 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ý.
2.1.5.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.
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:
17
Các không gian bảng.

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.
2.1.6. Đối tượng trong kho dữ liệu.
2.1.6.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.
2.1.6.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ê.
2.1.6.3. Khối dữ liệu.
Một khối dữ liệu về cơ bản là có thể có N chiều (N-D). Những cạnh của khối được gọi là
các chiều (dimensions), mà đó là các mặt hoặc các thực thể ứng với những khía cạnh mà
tổ chức muốn ghi nhận. Mỗi chiều có thể kết hợp với một bảng chiều (dimension table)
nhằm mô tả cho chiều đó. Ví dụ, một bảng chiều của Sản phẩm có thể chứa những thuộc
tính như MaSanpham, Mota, Tensanpham, LoaiSP,… mà có thể được chỉ ra bởi nhà quản
trị hoặc các nhà phân tích dữ liệu. Với những chiều không được phân loại, như là Thời
gian, hệ thống kho dữ liệu sẽ có thể tự động phát sinh tương ứng với bảng chiều
18
(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.
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.
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.
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.
2.1.7. Datamart, EDW trong kho dữ liệu và Bussiness Intelligence
Kho dữ liệu đóng vai trò là kho lưu tự động của một tổ chức dữ liệu, được thiết kế để tạo
điều kiện thuận lợi cho báo cáo và phân tích, và là một phần thiết yếu của BI trong doanh
nghiệp.
Kho dữ liệu mở rộng định nghĩa về kho dữ liệu bằng các công cụ và quy trình cho
❑ Trích xuất, chuyển đổi và tải dữ liệu vào kho lưu trữ,
❑ Quản lý và truy xuất siêu dữ liệu,
❑ Ánh xạ các tài sản thông tin doanh nghiệp với các thuật ngữ kinh doanh và các thực
thể / thuộc tính của mô hình dữ liệu logic EDW, quản trị dữ liệu
Lưu trữ dữ liệu thích hợp là chìa khóa cho BI (Business Intelligence) thành công
19
❑ Cho phép ra quyết định tốt hơn ở các cấp quản lý khác nhau.
✓ Kho dữ liệu là một định hướng chủ đề, tích hợp, biến thể theo thời gian và không thu
thập dữ liệu biến động để hỗ trợ việc ra quyết định của ban lãnh đạo tiến trình.
❑ Định hướng theo chủ đề: được sử dụng để phân tích một lĩnh vực chủ đề cụ thể
• Ví dụ: “khách hàng” / “bữa tiệc”, “sản phẩm”, “sự kiện”, “kênh”, v.v.
❑ Tích hợp: tích hợp dữ liệu từ nhiều nguồn dữ liệu

• Ví dụ: nguồn A và nguồn B có thể có các cách khác nhau để xác định một sản phẩm,
nhưng trong một dữ liệu kho hàng, sẽ chỉ có một cách duy nhất để xác định một sản
phẩm.
❑ Biến thể theo thời gian: lưu giữ dữ liệu lịch sử, có thể nghiên cứu các xu hướng và
thay đổi
• Ví dụ, một người có thể truy xuất dữ liệu từ 3 tháng, 6 tháng, 12 tháng, hoặc thậm chí
dữ liệu cũ hơn.
• Trong hệ thống giao dịch, thường chỉ dữ liệu gần đây nhất được lưu giữ. Ví dụ, một hệ
thống giao dịch có thể giữ địa chỉ gần đây nhất của khách hàng, nơi kho dữ liệu có thể
chứa tất cả các địa chỉ được liên kết với một khách hàng.
❑ Không bay hơi: chỉ đọc; một khi dữ liệu nằm trong kho dữ liệu, nó sẽ không thay đổi.
Cho nên, dữ liệu lịch sử không bị thay đổi trừ khi có các vấn đề cụ thể về chất lượng dữ
liệu.
✓ Giải nén, biến đổi và tải là một quá trình:
❑ Trích xuất dữ liệu từ các nguồn dữ liệu đồng nhất hoặc không đồng nhất.
❑ Biến đổi dữ liệu để lưu trữ nó ở định dạng hoặc cấu trúc thích hợp để truy vấn và mục
đích phân tích.
❑ Tải nó vào đích cuối cùng (trong trường hợp này là kho dữ liệu).
Kiến trúc thiết kế tấng edw:
Các yêu cầu đối với tầng EDW:
✓ Tính mềm dẻo:

• Cho phép lưu đủ thông tin tương ứng với quy trình nghiệp vụ tại các thời kỳ khác nhau
(quá khứ, hiện tại, tương lai)
20
• Cho phép bổ sung dữ liệu với các nghiệp vụ phát sinh trong tương lai mà không ảnh
hưởng (hoặc ảnh hưởng tối thiểu) đến hệ thống hiện tại.
✓ Khả năng lưu trữ tối ưu: Thiết kế cho phép lưu trữ lượng dữ liệu lớn một cách tối ưu
✓ Tính chuẩn hóa: thuật ngữ, kiến trúc
✓ Core Banking là phần mềm lõi của ngân hàng cho các hoạt động tác nghiệp.
✓ Enteprise Data Warehouse là cơ sở dữ liệu lõi của Data Warehouse, cung cấp thông tin
cho các Data Mart phân tích.
✓ Phạm vi dữ liệu: Toàn doanh nghiệp / Lĩnh vực đối tượng hoặc ngành nghề kinh doanh
hoặc
bộ phận định hướng
✓ Làm mới dữ liệu: Thời gian thực / Chế độ hàng loạt
✓ Phương sai thời gian: Chỉ dữ liệu hiện tại / Dữ liệu hiện tại và lịch sử
✓ Mức độ chi tiết của dữ liệu: Dữ liệu chi tiết / Dữ liệu tổng hợp
✓ Mô hình dữ liệu: Mô hình dữ liệu ngành tham chiếu / Mô hình dữ liệu nguồn
Các tùy chọn Kho dữ liệu doanh nghiệp hiện tại được gạch chân.
Hệ thống ghi
▪ Dữ liệu hoạt động hàng ngày được hợp nhất trong Hệ thống BDW
Ghi lại (định kỳ hoặc đột xuất)
- Ví dụ, tất cả các thông tin liên quan đến Khách hàng và khách hàng được lưu trữ trong
"Khách hàng" và đó là các thực thể được liên kết
- Do đó, điều này không chỉ làm giảm sự dư thừa dữ liệu mà còn mang lại chế độ xem
toàn bộ dữ liệu 360 độ trong toàn tổ chức
- Tất cả thông tin từ mọi bộ phận có thể được tổng hợp vào một nơi trong khi vẫn duy trì
thông tin cụ thể về mỗi bộ phận
- Rủi ro, Tài chính, Khả năng sinh lời, Hiệu suất và các thông tin khác đó là silo điển hình
có thể được tích hợp
- Cho phép các tổ chức trả lời các câu hỏi trước đây không thể đạt được, ví dụ: tác động
rủi ro ảnh hưởng đến mối quan hệ với khách hàng, mức độ ảnh hưởng của sự tiêu hao của
khách hàng như thế nào lợi nhuận, v.v.
21
▪ Thông tin Cá nhân: - Tên, Tên thay thế, Bằng cấp, Số điện thoại, Địa chỉ, Tình trạng
hôn nhân, Việc làm, Gia đình, Hộ gia đình, Tài sản, Tài khoản, Tổng giá trị ròng, Chia sẻ
trên Wallet, Xếp hạng mức độ hài lòng, v.v.
▪ Khuyết tật của khách hàng và thông tin khả năng tiếp cận, rủi ro khoan dung, lựa chọn
sản phẩm, tương tác cơ sở vật chất, v.v.
▪ Trạng thái Vòng đời của Khách hàng - Hiện tại, Trước đây, Đã qua đời và Khách hàng
tiềm năng, v.v.
▪ Tương tác với khách hàng - giao dịch tài chính, thông tin liên lạc (thắc mắc, khiếu nại,
từ chối.), Đầy đủ
chủ đề giao tiếp, hoạt động và sự kiện, đánh giá, v.v.
Kiến trúc thiết kế tầng datamart
Trí tuệ nhân tạo (Bussiness Intelligence)
Business Intelligence (BI) là quy trình, kiến trúc, công nghệ và công cụ giúp các công ty
chuyển đổi dữ liệu của họ thành chính xác, có thể hành động và thông tin kịp thời và phổ
biến thông tin đó trong toàn tổ chức.
Nó bao gồm, nhưng không giới hạn, lập mô hình dữ liệu, lưu trữ dữ liệu, quản trị dữ liệu,
siêu dữ liệu, siêu dữ liệu, dữ liệu tổng thể quản lý, làm sạch dữ liệu, phân tích dự đoán,
báo cáo (bao gồm cảnh báo, trang tổng quan và phiếu ghi điểm).
2.2.HIỆN TRẠNG HỆ THỐNG KHO DỮ LIỆU TRONG NGÂN HÀNG
BIDV
2.2.1. Tổng quan hệ thống báo cáo trong ngân hàng
Từ năm 2004 đến nay ngân hàng đã trang bị hệ thống Core Banking mạnh phục vụ các
mảng kinh doanh của mình. Song song với đó các hệ thống báo cáo phục vụ công tác
thống kê, quản lý lần lượt đưa vào khai thác. Tuy nhiên, các hệ thống báo cáo này vẫn
chưa đầy đủ và còn manh mún, nằm rời rạc ở các vị trí khác nhau. Hệ thống báo cáo rời
rạc chia thành các nhóm cụ thể như sau:
Hệ thống báo cáo tại Core banking: nằm trên hệ thống Core banking phục vụ công tác
hàng ngày của hoạt động tác nghiệp trong ngân hàng.
Hệ thống báo cáo kho dữ liệu: là hệ thống báo cáo phân tích đa chiều lớn gồm hàng trăm
báo cáo dựa trên công nghệ của Microsoft.
Hàng trăm hệ thống báo cáo đơn lẻ do ngân hàng tự xây dựng và phát triển.
22
2.2.2. Kiến trúc của kho dữ liệu trong ngân hàng

Hệ thống kho dữ liệu trong ngân hàng được xây dựng và duy trì từ năm 2005 đến nay,
được thiết kế bởi nhà thầu Silverlake.
Hình: Mô tả hệ thống kho dữ liệu hiện tại của ngân hàng.
Hình : Kiến trúc kho dữ liệu trong ngân hàng
Hệ thống kho dữ liệu lưu trữ dữ liệu bao gồm khu vực dữ liệu nguồn (Source data) và
khu vực kho dữ liệu nằm chính trên máy chủ triển khai hệ thống Core Banking (máy chủ
AS400) có nghĩa là máy chủ triển khai hệ thống Core Banking cũng đồng thời là máy chủ
xử lý chính của kho dữ liệu, hai hệ thống trên cùng một máy chủ hệ thống tác nghiệp và
hệ thống báo cáo kho dữ liệu với cơ sở dữ liệu là DB2 được tích hợp luôn trên máy chủ.
Dữ liệu nguồn hầu hết nằm chính tại máy chủ AS400 bao gồm toàn bộ dữ liệu tác nghiệp
của Core Banking, dữ liệu từ các hệ thống khác hầu như không có. Dữ liệu nguồn sẽ
được tập kết tại một chỗ gọi là khu vực STG từ khu vực này dữ liệu sẽ được làm giàu,
làm sạch, tổng hợp, chuẩn hóa dữ liệu, chuẩn bị được đẩy vào khu vực EDM bằng cung
cụ DTS, một sản phẩm trong bộ SQL Server của Microsoft. Dữ liệu sau khi đã được hợp
nhất, tính toán, làm giàu, làm sạch từ khu vực EDM dữ liệu sẽ được chuyển sang dạng dữ
liệu đa chiều (OLAP) theo các bài toán chủ đề khác nhau để người dùng khai thác thông
qua công cụ Excel. Dữ liệu đa chiều được thực hiện tổng hợp thông qua công cụ DTS và
được lưu trữ trên cơ sở dữ liệu SQL Server 2000.
Như vậy về tổng quan kho dữ liệu hiện tại của ngân hàng được nhìn dưới ba góc độ về hạ
tầng như sau:
Cơ sở dữ liệu dùng cho bài toán kho dữ liệu: Cơ sở dữ liệu DB2 được tích hợp sẵn trên
máy chủ AS400 (máy mainframe).
Công cụ trích lọc dữ liệu: Sử dụng DTS một trong các công cụ của SQL Server về trích
lọc dữ liệu.
Công cụ khai thác, phân tích: Sử dụng Excel kết nối tới OLAP được lưu trữ trên SQL
Server 2000.
2.2.3 Đánh giá các mặt hạn chế của hệ thống kho dữ liệu hiện tại
Dựa vào những phương diện sau để phân tích đánh giá những mặt hạn chế của kho dữ
liệu hiện tại trong ngân hàng bao gồm:
CSDL dùng cho bài toán kho dữ liệu.
Công cụ trích lọc dữ liệu.
Công cụ phân phối báo cáo.
Mô hình thiết kế của kho dữ liệu.
23
Từ đó đưa ra hướng giải pháp mới nhằm nâng cao hiệu quả về hiệu năng xử lý của kho
dữ liệu.
2.2.3.1. CSDL dùng cho bài toán kho dữ liệu
Cơ sở dữ liệu DB2 được tính hợp sẵn trên máy chủ AS400 được triển khai cùng với Core
banking, hệ cơ sở dữ liệu này được triển khai nhằm mục đích chính cho bài toán tác
nghiệp phù hợp với bài toán OLTP của ngân hàng và cấu phần kho dữ liệu được triển
khai thêm sau đó.
Do vậy tồn tại bài toán tác nghiệp và bài toán xử lý kho dữ liệu trên cùng một máy chủ
Core banking điều này ít nhiều làm ảnh hưởng tới hiệu năng của hệ thống tác nghiệp do
phải chia sẻ tài nguyên cho hệ thống kho dữ liệu. Thông thường hệ thống tác nghiệp sẽ
bắt đầu ngày làm việc mới khoảng 8h mỗi sáng nhưng hệ thống kho dữ liệu thì kết thúc
muộn hơn rất nhiều. Hệ thống kho dữ liệu thường bắt đầu từ 2h sáng và thường kết thúc
vào 12h giờ hàng với tổng dương lượng dữ liệu xử lý vào khoảng 30GB điều này gây áp
lực rất lớn lên hệ thống giao dịch hàng ngày của ngân hàng và cũng gây khó khăn cho
việc khai thác phân tích số liệu phục vụ công tác quản trị điều hành tại ngân hàng.
2.2.3.2, Công cụ trích lọc dữ liệu
Hiện tại ngân hàng đang sử dụng công cụ DTS để thực hiện quá trình trích lọc dữ liệu,
công cụ này hiện nay đang gặp phải một số hạn chế như sau:
Không có khả năng mở rộng về hạ tầng và chạy trên nền tảng của Microsoft chỉ phù hợp
đối với các bài toán nhỏ và vừa. Hiện nay với việc xử lý dữ liệu đầu ngày khoảng 300G
đã gây ra áp lực rất lớn lên hệ thống ETL của ngân hàng.
Chỉ hỗ trợ mô hình triển khai theo hướng ET-L hoặc E-TL có nghĩa là máy chủ cài đặt
DTS chỉ làm nhiệm vụ trích xuất (Extract) hoặc truyền tải (Load) còn chuyển đổi
(Transform) sẽ được thực hiện tại nguồn hoặc đích. Việc thiết kế này phụ thuộc hoàn
toàn vào hiệu năng xử lý của máy của nguồn hoặc đích. Không có khả năng mở rộng về
các cụm máy chủ chỉ để dùng cho việc chuyển đổi số liệu khi bài toán dữ liệu ngày càng
tăng trưởng. Do đó mô hình này cũng đã một phần ngây tải cho hệ thống xử lý tác nghiệp
hàng ngày trong ngân hàng.
2.2.3.3. Công cụ phân phối báo cáo
Việc khai thác và phân phối báo cáo theo chủ đề hiện nay tại ngân hàng sử dụng qua công
cụ Excel kết nối tới mô hình dữ liệu đa chiều (OLAP) qua phương thức kết nối ODBC
mà chưa có một công cụ chuyên biệt để thực hiện việc phân phối báo cáo tới người dùng.
Một số hạn chế khi sử dụng công cụ Excel cho bài toán phân tích hiện nay trong ngân
hàng như sau:
24
Dữ liệu khai thác trên Excel chỉ khai thác được trên tập dữ liệu nhỏ và dữ liệu OLAP
được lưu trên SQL server bị giới hạn dung lượng do đó bài toán này chỉ phù hợp với dữ
liệu vừa và nhỏ không phù hợp với dữ liệu lớn.
Việc khai thác trên các dữ liệu chuyên đề không linh hoạt gây khó khăn cho người dùng
đối với các phân tích cần lọc dữ liệu thì Excel sẽ thực hiện việc load toàn bộ data lên
Excel rồi mới thực hiện việc lọc điều này dẫn đến nhiều bài toán phân tích trên dữ liệu
chuyên đề không thực hiện được do bị giới hạn về số lượng bản ghi hiển trị trên Excel
tùy thuộc từng phiên bản của Excel.
Dữ liệu trong kho dữ liệu mới chỉ được cung cấp tại Hộ sở chính mà chưa được phân
phối
trên toàn ngân hàng.
Cơ chế phân quyền bảo mật đối với việc khai thác báo cáo qua Excel chưa đảm bảo.
2.2.3.4. Mô hình thiết kế kho dữ liệu
Việc triển khai kho dữ liệu trong ngân hàng chưa có một mô hình thiết kế tổng thể để từ
đó có thể dễ dàng mở rộng và phát triển các bài toán phân tích khác nhau phục vụ nhu
cầu quản trị điều hành trong môi trường cạnh tranh ngày càng mãnh liệt.
Chưa có một mô hình tổng thể bao trùm các mảng phân tích trong ngân hàng như: quản
lý rủi ro, phân tích khác hàng, quản lý tài sản nợ có, phân tích khách hàng trung thành dời
đi, phân tích bán chéo sản phẩm, các bài toán về báo cáo tuân thủ, v.v… hiện tại kho dữ
liệu mới chỉ dừng lại ở các bài toán phục vụ tác nghiệp là chính chưa có những mô hình
chuyên sâu, chuyên biệt để thực hiện phát triển, kiểm soát các hoạt động của ngân hàng
trong xu hướng phát triển mới.
2.2.4. Một số giải pháp công nghệ mới về kho dữ liệu
Có nhiều phương thức để đánh giá các giải pháp kho dữ liệu hiện tại trên thế giới. Các
hãng phân tích lớn và uy tín trên thế giới sử dụng các phân tích đa chiều, đồng thời theo
xu hướng phát triển của Công nghệ thông tin như Gartners. Tuy nhiên, theo nhận định
chung thì có bốn yếu tố chính ảnh hưởng đến việc lựa chọn một nền tảng công nghệ kho
dữ liệu thích hợp đó là: giao diện, tính năng, hỗ trợ và nền tảng hệ thống. Các yếu tố này
ảnh hưởng trực tiếp đến thành công của một dự án triển khai và áp dụng kho dữ liệu vào
trong tổ chức/doanh nghiệp. Các giải pháp kho dữ liệu lớn trên thế giới [5] đang theo xu
hướng thay đổi để thích hợp với xu hướng phát triển của BI cũng yêu cầu càng ngày càng
phức tạp hơn trong việc phân tích dữ liệu. Một số giải pháp hiện nay có trên thị trường
bao gồm: Microsoft, Oracle, IBM.
Giải pháp của Microsoft: Microsoft cung cấp giải pháp kho dữ liệu khá toàn diện và đẩy
đủ với cơ sở dữ liệu SQL Server 2008, hệ thống Analyze Services, là giải pháp tương đối
25
phổ biến.
Ưu điểm: thân thiện, dễ dùng, dễ phát triển, dễ bảo trì.
Nhược điểm:
Hạn chế khi xử lý lượng dữ liệu lớn
Phù hợp với các bài toán vừa và nhỏ
Hệ thống bảo mật kém do sử dụng nền tảng windows
Giải pháp của Oracle: Oracle được đánh giá là một trong những công ty hàng đầu trong
lĩnh vực giải pháp về kho dữ liệu với đầy đủ các công cụ chuyên biệt cho bài toán kho dữ
liệu đặc biệt với giải pháp Oracle Exadata Database Machine đã tối ưu rất nhiều cho bài
toán kho dữ liệu.
Ưu điểm:
Thị phần Oracle chiếm trên thị trường khá lớn khoảng 48%
Tiện dụng, thuận lợi cho việc tiếp cận và phát triển
Hệ thống cơ sở dữ liệu và máy chủ kho dữ liệu đã tích hợp thành máy duy nhất cung cấp
hiệu năng xử lý tốt hơn
Nhược điểm:
Thông thường khi triển khai giải pháp của Oracle sẽ tốn công sức triển khai hơn
Chi phí về bản quyền phần mềm của Oracle cũng thường cao hơn các nhà cung cấp khác.
Giải pháp của IBM: được đánh giá là đơn vị cung cấp giải pháp kho dữ liệu và phân tích
số liệu hàng đầu ở hầu hết các tổ chức đánh giá độc lập (cụ thể là Gartner và Forrester).
Hiện tại IBM đang cung cấp hai giải pháp chính và chuyên dụng cho bài toán khai thác,
phân tích báo cáo theo mô hình kho dữ liệu. Cả hai giải pháp [1] đều có mô hình gần
giống nhau, Data Stage làm công cụ ETL, công cụ Cognos cho cấu phần khai thác và
phân phối báo cáo, mô hình dữ liệu IBM Banking Data Model. Chỉ khác nhau về cấu
phần CSDL lưu trữ
ISAS (IBM Smart Analytics System): sử dụng appliance máy chủ ISAS 7710; kho dữ
liệu xây dựng trên cơ sở dữ liệu DB2. Dữ liệu đa chiều cube xây dựng trên Inforsphere
warehouse gắn chặt với cơ sở dữ liệu DB2. Đây là giải pháp Hybrid (Hệ thống máy chủ
có thể dùng cho cả bài toán phân tích báo cáo và giao dịch).
Netezza: sử dụng theo cơ chế appliance; tích hợp toàn bộ phần cứng, phần mềm (hệ điều
hành, cơ sở dữ liệu, v.v…) trong một thiết bị duy nhất. Đây là giải pháp chỉ dùng cho hệ
thống phân tích, khai thác báo cáo.
26
2.2.5.Kết luận
Nội dung chương này đề cập tới khái niệm kho dữ liệu, kiến trúc chung của kho dữ liệu
và một số mô hình logic thường sử dụng trong kho. Ngoài ra phần chính của chương để
cập tới hiện trạng kho dữ liệu tại ngân hàng với các mặt hạn chế về CSDL, công cụ trích
lọc, công cụ phân phối báo cáo và mô hình thiết kế. Với quy mô ngày càng lớn của ngân
hàng, lượng khách hàng, lượng giao dịch, tần suất giao dịch, đều sẽ tăng với tốc độ cao,
tác giả nhận thấy nhu cầu cần phải có một kho dữ liệu mới đáp ứng được hiệu năng xử lý
cho ngân hàng. Bài toán quản lý nghiệp vụ ngân hàng hết sức quan trọng và không hề
đơn giản, hơn nữa lại luôn luôn thay đổi. Kho dữ liệu mới sẽ giảm tải cho hệ thống Core
Banking, hỗ trợ các báo cáo phân tích, tổng hợp cần đến thường xuyên cũng như các báo
cáo phức tạp hơn trong tương lai.
CHƯƠNG III: ỨNG DỤNG QUY TRÌNH ETL VÀO XÂY DỰNG QUẢN LÝ
THÔNG TIN GIAO DỊCH NGÂN HÀNG BIDV VÀ THỰC HÀNH ĐẨY DỮ LIỆU
TỪ SATGING LÊN DATAMART
3.1. GIỚI THIỆU VỀ CÔNG CỤ
3.1.1.Giới thiệu về công cụ Designer Client
• Công cụ IBM InfoSphere DataStage Designer Client được dùng để phát triển,
chỉnh sửa và vận hành job ETL.
Sử dụng công cụ Designer Client
- Click dúp chuột trái vào biểu tượng để khởi động công cụ IBM
InfoSphere DataStage Designer Client, sau khi điền tên đăng nhập và mật khẩu, chọn
project sử dụng tại mục Project.
27
Hình 3. 1: Màn hình đăng nhập vào IBM Infosphere DataStage
- Màn hình sau khi đăng nhập
28
Hình 3. 2: Giao dện IBM Infosphere Data
Khu vực (1) : thanh công cụ

Khu vực (2) : thanh chứa các công cụ quick access
Khu vực (3) : cây repository ,chứa các danh mục job, data connection, … phục vụ cho hệ
thống Job ETL.
Khu vực (4) : dòng trên chứa các phím chức năng dùng để start/stop/reset job và phí dưới
là khu vực lưu log của job khi chạy.
Mục tiêu
- Mô tả thiết kế chi tiết của kho dữ liệu mới với đầy đủ các tầng Atomic, Data Mart cũng
như thiết kế luồng trích xuất xử lý dữ liệu
- Áp dụng với bài toán phân tích khách hàng của ngân hàng thương mại dựa trên hệ thống
báo cáo tập trung (BI).
- Thử nghiệm đảm bảo hiệu năng của kho dữ liệu
3.1.2.Giới thiệu về công cụ Dbeaver
DBeaver là phần mềm hoạt động như một công cụ cơ sở dữ liệu chung Dành cho các nhà
phát triển và quản trị cơ sở dữ liệu.
29
DBeaver có giao diện người dùng được thiết kế tốt, nền tảng dựa trên khung mã nguồn
mở và cho phép viết nhiều phần mở rộng, cũng như tương thích với bất kỳ cơ sở dữ liệu
nào cũng bao gồm hỗ trợ cho các máy khách MySQL và Oracle, quản lý trình điều khiển,
trình soạn thảo SQL và định dạng. DBeaver là một ứng dụng đa nền tảng vì nó hỗ trợ cho
các nền tảng MacOS, Windows và Linux.
Click dúp chuột trái vào biểu tượng để khởi động công cụ Dbeaver, sau khi
điền tên đăng nhập và mật khẩu, chọn project sử dụng tại mục Project.
Bây giờ chúng ta sẽ thực hiện kết nối Dbeaver tới máy chủ 192.168.1.214. Ở đây em
chọn Oracle.
Các bước như hình bên dưới:
(1) Click vào đây để thực hiện kết nối đến cơ sở dữ liệu
30
Hình 3. 3: Giao diện Dbeaver
(2) Em chọn kết nối đến hệ quản trị cơ sở dữ liệu Oracle.

=> Sau khi bấm Next ở bước trước thì sẽ có một hộp thoại được hiển thị lên như sau.
(1) Bao gồm các thông tin về server (Server Host: địa chỉ máy chủ, Port: cổng, Database:
database các bạn định kết nối)
(2) Authentication: Các thông tin về username và password để truy cập vào hệ quản trị cơ
sở dữ liệu.
(3) Bấm Test Connection…
Em điền thông tin như sau
Ở bước này các bạn bấm OK => và chọn Finish để hoàn tất kết nối.
31
Hình 3. 4: Màn hình kết nối Database
Vậy là chúng ta đã thực hiện kết nối thành công đến hệ quản trị cơ sở dữ liệu.
Nhận xét: Với phần mềm Dbeaver thì quá trình kết nối đến hệ quản trị cơ sở dữ liệu
tương đối đơn giản, không phải cấu hình quá nhiều. Đặc biệt là Dbeaver hỗ trợ hầu hết
các hệ quản trị cở dữ liệu phổ biến hiện nay.
32
3.2. Khái quát quy trình ETL và mục tiêu thiết kế kho dữ liệu
3.2.1. Khái quát quy trình ETL trong kho dữ liệu
Hình 3. 5: Quy trình ETL
Hình: Mô hình khái quát ETL trong kho dữ liệu

Như mô hình trên ta có thể thấy, quy trình ETL bắt đầu từ các nguồn dữ liệu hàng ngày
như Core Banking, FTP, ERP hoặc Excel, với mỗi nguồn dữ liệu, các công ty có thể sử
dụng các hệ thống cơ sở dữ liệu quan hệ khác nhau để kết nối đến các nguồn dữ liệu đó
tùy theo quy mô cũng như nhu cầu sử dụng dữ liệu của doanh nghiệp, sau đấy, dữ liệu từ
các nguồn sẽ được đẩy lên lớp tích hợp Staging, sau đó, tùy từng loại bảng
Fundamental/Master, Relationship, Summary sẽ đẩy lên Atomic theo những cách khác
nhau, tiếp theo sẽ đẩy dữ liệu lên Datamart, tạo điều kiện hoàn thành các báo cáo BI.
3.2.2. Mục tiêu phân tích thiết kế kho dữ liệu
- Mô tả thiết kế chi tiết của kho dữ liệu với đầy đủ các tầng Staging, Atomic, Data Mart
cũng như thiết kế luồng trích xuất xử lý dữ liệu
- Thực hành tạo job và đẩy dữ liệu đối với từng bảng tương ứng trong mỗi tầng
- Lưu trữ dữ liệu trong bảng đích ở tầng Datamart
3.3. Quy tắc đặt tên ETL
3.3.1. Job
Tên Job ETL sẽ có cấu trúc sau :
<loại job>_<tầng ghi dữ liệu>_<tên bảng đích ghi dữ liệu>_<mode ghi dữ liệu>
Trong đó :
<loại job> : Có 2 giá trị PAR, SEQ
33
<tầng ghi dữ liệu> : STG, SOR, DMT

<tên bảng đích> : tên bảng mà job đẩy dữ liệu tới : TWT_AR, AR…..
<mode ghi dữ liệu> : các giá trị Ins, DelIns, TruncIns, UpdIns. Chỉ có đối với job
parallel. Sequence job không cần mục này.
Ví dụ:
Parallel Job : PAR_SOR_AR_UpdIns
Sequence Job : SEQ_SOR_AR
3.3.2. Stage connection trong job
Tên Stage connect tới database trong job ETL sẽ có cấu trúc sau:
<loại DB lấy/ghi dữ liệu>Conn_<tầng lấy/ghi dữ liệu>_<tên bảng lấy/ghi dữ liệu chính>
Trong đó:
<loại DB lấy/ghi dữ liệu> : Ví dụ ORA (ORACLE) , SQLSERVER, MYSQL, DB2…
<tầng lấy/ghi dữ liệu> : STG, SOR, DMT
<tên bảng lấy/ghi dữ liệu chính> : Tên bảng mà stage lấy dữ liệu hoặc ghi dữ liệu.
Ví dụ : OraConn_SOR_TWT_AR, DB2Conn_STG_FCC_CUSTOMER_TDY
Trong đề tài này, em xin phép lấy dùng Connection: “ORA_CONN_FSSTRAINING” là
Connection chung của công ty em đang thực tập ạ.
3.4. Tầng Staging
Ở tầng Staging, chúng ta sẽ đẩy dữ liệu từ các bảng nguồn lên các bảng đích.
Các bảng nguồn sẽ chia thành hai dạng:
- Master
- Summary
Tại tầng Staging, các parallel job sẽ chia thành 3 loại chính:
- Job Today
- Job Preday
- Job Minus
3.4.1. Các bảng Master
Master là loại bảng có số lượng dòng ít, thay đổi hàng ngày < 100k dòng.
34
Dưới đây là ETL các bảng Master
Hình 3. 6: ETL các bảng Master
Sau đây chúng ta sẽ tiến hành tạo các bảng TDY, PDY và MNS liên quan đến từng bảng
nguồn để thực hành đẩy dư liệu lên tầng Staging
a. IFTB_CLT_MASTER: Bảng này sẽ là bảng cung cấp thông tin về các hợp động tài
sản
Các thuộc tính của bảng này bao gồm:
35
Ta sẽ tạo lần lượt bảng IFTB_CLT_MASTER_TDY, IFTB_CLT_MASTER_PDY và

IFTB_CLT_MASTER_MNS để thực hiện quá trình đẩy dữ liệu từ bảng nguồn
IFTB_CLT_MASTER lên tầng Staging
Dùng Dbeaver kết nối với máy chủ fsstraining để tiến hành quá trình tạo bảng
Với bảng IFTB_CLT_MASTER_TDY_2022 thì ta sẽ thực hiện câu lệnh sau:
CREATE TABLE IFTB_CLT_MASTER_TDY_2022
( ETL_DATE DECIMAL(8,0),
CLT_CODE Varchar(30),
CCY_CODE VARCHAR(30),
MAT_DT DECIMAL(8,0),
CLT_VAL_LCY decimal(23,5),
CLT_VAL_FCY decimal(23,5),
CLT_TP_CODE varchar(100),
OWNER_ID varchar(30),
ISSUER_ID varchar(30),
EFF_DT decimal(8,0)
)
Với bảng IFTB_CLT_MASTER_PDY_2022 ta cũng sẽ thực hiện câu lệnh tương tự:
CREATE TABLE IFTB_CLT_MASTER_PDY_2022
( ETL_DATE DECIMAL(8,0),
CLT_CODE Varchar(30),
CCY_CODE VARCHAR(30),
MAT_DT DECIMAL(8,0),
CLT_VAL_LCY decimal(23,5),
CLT_VAL_FCY decimal(23,5),
CLT_TP_CODE varchar(100),
OWNER_ID varchar(30),
ISSUER_ID varchar(30),
EFF_DT decimal(8,0)
)
Với bảng MINUS vì ta chỉ so sánh sự khác nhau giữa bảng TDY và PDY nên ta chỉ có 2
thuộc tính:
Ta sẽ thực hiện câu lệnh:

CREATE TABLE IFTB_CLT_MASTER_2022_MNS
( CLT_CODE VARCHAR(30),
REC_IND CHAR(1),
PPN_DT DECIMAL(38,0)
36
b. IFTB_CARD_MASTER: Bảng này sẽ là bảng cung cấp thông tin về các hợp đổng thẻ
Ta sẽ tạo lần lượt bảng IFTB_CARD_MASTER_TDY, IFTB_CARD_MASTER_PDY

và IFTB_CARD_MASTER_MNS để thực hiện quá trình đẩy dữ liệu từ bảng nguồn
IFTB_CLT_MASTER lên tầng Staging
Với bảng IFTB_CARD_MASTER_TDY_2022 thì ta sẽ thực hiện câu lệnh sau:
CREATE TABLE IFTB_CARD_MASTER_TDY_2022
( CST_ID varchar(80),
CARD_NO varchar(80),
GL_CODE char(3),
EFF_DT decimal(8,0),
MAT_DT decimal(8,0),
CCY_CODE varchar(4),
OU_CODE varchar(50),
SUBS_F char(1),
CLS_BAL_LCY decimal(25,5)
)
Với bảng IFTB_CARD_MASTER_PDY_2022 ta cũng sẽ thực hiện câu lệnh tương tự:
CREATE TABLE IFTB_CARD_MASTER_PDY_2022
CARD_NO varchar(80),
GL_CODE char(3),
SUBS_F char(1),
CLS_BAL_LCY decimal(25,5)
37
thuộc tính:

CREATE TABLE IFTB_CARD_MASTER_MNS_2022_HUNGTDH
( CARD_NO varchar(80),
CST_ID varchar(80),
REC_IND char(1),
PPN_DT decimal(8,0)
)
c. IFTB_DEP_MASTER: Bảng này sẽ là bảng cung cấp thông tin về các hợp đổng huy
động vốn
38
Ta sẽ tạo lần lượt bảng IFTB_DEP_MASTER_TDY, IFTB_DEP_MASTER_PDY và

IFTB_DEP_MASTER_MNS để thực hiện quá trình đẩy dữ liệu từ bảng nguồn
IFTB_DEP_MASTER lên tầng Staging
Với bảng IFTB_DEP_MASTER_TDY_2022 thì ta sẽ thực hiện câu lệnh sau:
CREATE TABLE CLT_DEP_MASTER_TDY_2022
( ETL_DATE decimal(8,0),
CTR_ID varchar(30),
CTR_NAME varchar(250),
CST_ID varchar(30),
GL_CODE char(4),
PD_CODE varchar(30),
BR_CODE varchar(30),
CLS_BAL_FCY decimal(23,5),
CLS_BAL_LCY decimal(23,5),
RATE_PCT decimal(23,5),
SUBS_F char(1),
ACR_BAL_LCY decimal(23,5)
)
CREATE TABLE CLT_DEP_MASTER_PDY_2022
39
CTR_ID varchar(30),
CST_ID varchar(30),
GL_CODE char(4),
SUBS_F char(1),
ACR_BAL_LCY decimal(23,5)
)
thuộc tính:

CREATE TABLE IFTB_DEP_MASTER_MNS_2022
( CTR_ID varchar(30),
REC_IND char(1),
PPN_DT Decimal(38,0)
)
d. IFTB_LOAN_MASTER: Bảng này sẽ là bảng cung cấp thông tin về các hợp đổng huy
động vốn
40
Ta sẽ tạo lần lượt bảng IFTB_LOAN_MASTER_TDY, IFTB_LOAN_MASTER_PDY

và IFTB_LOAN_MASTER_MNS để thực hiện quá trình đẩy dữ liệu từ bảng nguồn
IFTB_LOAN_MASTER lên tầng Staging
Với bảng IFTB_LOAN_MASTER_TDY_2022 thì ta sẽ thực hiện câu lệnh sau:
CREATE TABLE IFTB_LOAN_MASTER_TDY_2022
CTR_ID varchar(30),
CST_ID varchar(30),
GL_CODE char(4),
41
ACR_BAL_LCY decimal(23,5),
LOAN_PPS_CODE varchar(200),
DSBR_DT decimal(8,0),
THOAI_LAI decimal(23,5),
MRTG_TP varchar(30),
SEC_F char(1),
SUBS_F char(1),
TOT_DSBR_AMT_LCY decimal(23,5),
SPC_LN_IDC_TP_CODE varchar(30)
)
CREATE TABLE IFTB_LOAN_MASTER_PDY_2022
CTR_ID varchar(30),
CST_ID varchar(30),
GL_CODE char(4),
ACR_BAL_LCY decimal(23,5),
LOAN_PPS_CODE varchar(200),
DSBR_DT decimal(8,0),
THOAI_LAI decimal(23,5),
MRTG_TP varchar(30),
SEC_F char(1),
SUBS_F char(1),
TOT_DSBR_AMT_LCY decimal(23,5),
SPC_LN_IDC_TP_CODE varchar(30)
)
thuộc tính:
42
CREATE TABLE IFTB_LOAN_MASTER_MNS_2022

( CARD_NO varchar(80),
REC_IND char(1),
PPN_DT decimal(8,0),
CSST_ID varchar(80)
)
3.4.2. Summary
Summary: Số lượng dòng lớn, phát sinh hàng ngày xấp xỉ 500k dòng.
Dưới đây là ETL các bảng Summary.
Hình 3. 7: ETL các bảng Summary
a. IFTB_CUSTOMER: Bảng này sẽ là bảng cung cấp thông tin về các danh mục khách
hàng
43
Ta sẽ tạo lần lượt bảng IFTB_CUSTOMER_ TDY, IFTB_CUSTOMER _PDY và

IFTB_CUSTOMER _MNS để thực hiện quá trình đẩy dữ liệu từ bảng nguồn
IFTB_CUSTOMER lên tầng Staging
Với bảng IFTB_CUSTOMER _TDY_2022 thì ta sẽ thực hiện câu lệnh sau:
CREATE TABLE IFTB_CUSTOMER_2022_TDY
CST_ID varchar(30),
CST_NAME varchar(250),
CST_STATUS varchar(30),
IDY_CODE varchar(250),
CST_MSEG_CODE varchar(30),
ORG_TAX_IDENTN_NBR varchar(30),
IDENT_NBR varchar(30),
BRTH_DT decimal(8,0),
CST_PERF_ST_CODE varchar(30),
CST_PERF_ST_NM varchar(50),
PRIM_BR varchar(30),
EFF_CST_DT decimal(8,0),
END_CST_DT decimal(8,0),
SECTOR varchar(30),
ESTB_DT decimal(8,0),
44
PRIM_CMRCL_NM varchar(50),
INR_CST varchar(1)
)
Với bảng IFTB_CUSTOMER_PDY_2022 ta cũng sẽ thực hiện câu lệnh tương tự:
CREATE TABLE IFTB_CUSTOMER_2022_PDY
CST_ID varchar(30),
CST_NAME varchar(250),
CST_STATUS varchar(30),
IDY_CODE varchar(250),
CST_MSEG_CODE varchar(30),
ORG_TAX_IDENTN_NBR varchar(30),
IDENT_NBR varchar(30),
BRTH_DT decimal(8,0),
CST_PERF_ST_CODE varchar(30),
CST_PERF_ST_NM varchar(50),
PRIM_BR varchar(30),
EFF_CST_DT decimal(8,0),
END_CST_DT decimal(8,0),
SECTOR varchar(30),
ESTB_DT decimal(8,0),
PRIM_CMRCL_NM varchar(50),
INR_CST varchar(1)
)
thuộc tính:

CREATE TABLE IFTB_CUSTOMER_2022_MNS
REC_IND char(1),
PPN_DT decimal(8,0),
PRIM_BR varchar(30)
)
b. IFTB_BRANCH: Bảng này sẽ là bảng cung cấp thông tin về các danh mục các chi
nhánh
45
Ta sẽ tạo lần lượt bảng IFTB_BRANCH_ TDY, IFTB_BRANCH_PDY và

IFTB_BRANCH_MNS để thực hiện quá trình đẩy dữ liệu từ bảng nguồn
IFTB_BRANCH lên tầng Staging
Với bảng IFTB_BRANCH _TDY_2022 thì ta sẽ thực hiện câu lệnh sau:
CREATE TABLE IFTB_BRANCH_TDY_2022
( REGION_NAME varchar(250),
ETL_DATE decimal(8,0),
BR_NAME varchar(250),
REGION_CODE varchar(30)
)
Với bảng IFTB_BRACH_PDY_2022 ta cũng sẽ thực hiện câu lệnh tương tự:
CREATE TABLE IFTB_BRANCH_PDY_2022
( REGION_NAME varchar(250),
ETL_DATE decimal(8,0),
BR_NAME varchar(250),
REGION_CODE varchar(30)
)
thuộc tính:

CREATE TABLE IFTB_BRANCH_MNS_2022_01
( BR_CODE varchar(30),
REC_IND char(1),
PPN_DT numeric(8,0)
46
c. IFTB_CCY: Bảng này sẽ là bảng cung cấp thông tin về các danh mục các loại tiền tệ
Ta sẽ tạo lần lượt bảng IFTB_CCY_ TDY_2022, IFTB_CCY _PDY_2022 và

IFTB_CCY _MNS_2022 để thực hiện quá trình đẩy dữ liệu từ bảng nguồn IFTB_CCY
lên tầng Staging
Với bảng IFTB_CCY _TDY_2022 thì ta sẽ thực hiện câu lệnh sau:
CREATE TABLE IFTB_CCY_TDY_2022
( CCY_ID varchar(30),
CCY_NM varchar(100),
CCY_CODE varchar(100)
)
Với bảng IFTB_CUSTOMER_PDY_2022 ta cũng sẽ thực hiện câu lệnh tương tự:
CREATE TABLE IFTB_CCY_PDY_2022
)
thuộc tính:

CREATE TABLE IFTB_CCY_MNS_2022
47
)
3.4.3. Job Today

Vì quá trình tạo Job Today và Job Preday của các bảng là giống nhau, và độ dài đề tài
không cho phép, nên ở đây em xin phép trình bày quy trình tạo của bảng nguồn
IFTB_CLT_MASTER
Đối với job today của bảng nguồn IFTB_CLT_MASTER:
• Đẩy dữ liệu từ CSDL nguồn hoặc từ file nguồn vào Staging
o Stage input : Set connection là connection là FSS Training tới CSDL nguồn tương
ứng:
o Stage output : Set connection là connection tới Staging (ORA_CONN_STG),

Write mode là Insert, Table action là Truncate:
48
o Đối với những bảng dữ liệu 1 ngày quá lớn có thể bỏ index trên bảng và để chế độ
Bulk Load để tăng tốc độ load dữ liệu.
Kết quả sau khi chạy job Today:
Hình 3. 8: Chạy job today bảng IFTB_Master
49
3.4.3. Job Preday

Vì quá trình tạo Job Today và Job Preday của các bảng là giống nhau, và độ dài đề tài
không cho phép, nên ở đây em xin phép trình bày quy trình tạo của bảng nguồn
IFTB_CLT_MASTER
• Đẩy dữ liệu từ bảng Today sang bảng Preday theo từng nguồn dữ liệu. Job sẽ xác
định các bảng preday đã được tạo dưới database Staging bằng cách select trong bảng
user_tables với table_name like ‘%_PDY’, do vậy các bảng nào cần so sánh dữ liệu giữa
ngày hôm nay và hôm qua cần tạo cấu trúc bảng dưới Staging trước.
Với job FCC_IFTB_CLT_MASTER_PDY_2022, input sẽ là:
Và job output:
50
Kết quả sau khi chạy job preday:
Hình 3. 9: Chạy job Preday bảng IFTB_Master
51
3.4.4. Job Minus

a. Với job PAR_IFTB_CLT_MASTER_2022_MNS_Trunclns
So sánh dữ liệu của ngày hôm nay và hôm qua thông qua 2 bảng Today và Preday.
Stage input : Set connection là connection tới Staging (ORA_CONN_STG).
Với câu SQL sau :

(
SELECT A.CLT_CODE ,'I' REC_IND, #pdate# PPN_DT
FROM IFTB_CLT_MASTER_TDY_2022 A
MINUS
SELECT B.CLT_CODE, 'I' REC_IND, #pdate# PPN_DT
FROM IFTB_CLT_MASTER_PDY_2022 B
)
UNION ALL
(
SELECT B.CLT_CODE, 'D' REC_IND, #pdate# PPN_DT
MINUS
SELECT A.CLT_CODE, 'D' REC_IND, #pdate# PPN_DT
)
UNION ALL
(
SELECT C.CLT_CODE, 'U' REC_IND, #pdate# PPN_DT
FROM
(
SELECT A.*
FROM IFTB_CLT_MASTER_TDY_2022 A, IFTB_CLT_MASTER_PDY_2022 B
WHERE A.CLT_CODE=B.CLT_CODE
MINUS
SELECT B.*
52
) C
)
Stage output : Set connection là connection tới Staging (ORA_CONN_STG), Write mode
là Insert, Table action là Truncate
Kết quả sau khi chạy job PAR_IFTB_CLT_MASTER_2022_MNS_Trunclns:
Hình 3. 10: Chạy job Minus bảng IFTB_Master
b. Với job PAR_IFTB_CLT_MASTER_2022_MNS_Trunclns

53

(
SELECT A.CARD_NO, A.CST_ID , A.OU_CODE ,'I' REC_IND, #pdate# PPN_DT
FROM N3_IFTB_CARD_MASTER_TDY A
MINUS
SELECT B.CARD_NO,B.CST_ID , B.OU_CODE ,'I' REC_IND, #pdate# PPN_DT
FROM N3_IFTB_CARD_MASTER_PDY B
)
UNION ALL
(
SELECT B.CARD_NO, B.CST_ID ,B.OU_CODE , 'D' REC_IND, #pdate# PPN_DT
MINUS
SELECT A.CARD_NO, A.CST_ID , A.OU_CODE ,'D' REC_IND, #pdate# PPN_DT
FROM N3_IFTB_CARD_MASTER_TDY A
)
UNION ALL
(
SELECT C.CARD_NO, C.CST_ID, C.OU_CODE , 'U' REC_IND, #pdate# PPN_DT
FROM
(
SELECT A.*
FROM N3_IFTB_CARD_MASTER_TDY A, N3_IFTB_CARD_MASTER_PDY B
54
WHERE A.CARD_NO=B.CARD_NO
MINUS
SELECT B.*
) C
)
Kết quả sau khi chạy job PAR_IFTB_CARD_MASTER_2022_MNS_Trunclns:
55
Hình 3. 11: Chạy job minus IFTB_Card_Master
c. Với job PAR_IFTB_BRANCH _2022_MNS_Trunclns

56

(SELECT A.BR_CODE , 'I' REC_IND, #pdate# PPN_DT
FROM IFTB_BRANCH_TDY_2022 A
MINUS
SELECT B.BR_CODE, 'I' REC_IND, #pdate# PPN_DT
FROM IFTB_BRANCH_PDY_2022 B
)
UNION ALL
(
SELECT B.BR_CODE, 'D' REC_IND, #pdate# PPN_DT
MINUS
SELECT A.BR_CODE, 'D' REC_IND, #pdate# PPN_DT
FROM IFTB_BRANCH_TDY_2022 A
)
UNION ALL
(
SELECT C.BR_CODE, 'U' REC_IND, #pdate# PPN_DT
FROM
(
SELECT A.*
FROM IFTB_BRANCH_TDY_2022 A, IFTB_BRANCH_PDY_2022 B
WHERE A.BR_CODE =B.BR_CODE
57
MINUS
SELECT B.*
) C
)
;
Kết quả sau khi chạy job PAR_IFTB_CLT_MASTER_2022_MNS_Trunclns:
58
Hình 3. 12: Chạy job Minus của bảng IFTB_BRANCH
d. Với job PAR_IFTB_CCY _2022_MNS_Trunclns

59

(SELECT A.CCY_CODE , 'I' REC_IND, #pdate# PPN_DT
FROM IFTB_CCY_TDY_2022 A
MINUS
SELECT B.CCY_CODE, 'I' REC_IND, #pdate# PPN_DT
FROM IFTB_CCY_PDY_2022 B
)
UNION ALL
(
SELECT B.CCY_CODE, 'D' REC_IND, #pdate# PPN_DT
MINUS
SELECT A.CCY_CODE , 'D' REC_IND, #pdate# PPN_DT
FROM IFTB_CCY_TDY_2022 A
)
UNION ALL
(
SELECT C.CCY_CODE, 'U' REC_IND, #pdate# PPN_DT
FROM
(
SELECT A.*
FROM IFTB_CCY_TDY_2022 A, IFTB_CCY_PDY_2022 B
60
WHERE A.CCY_CODE =B.CCY_CODE

MINUS
SELECT B.*
) C)
Kết quả sau khi chạy job PAR_IFTB_CCY_2022_MNS_Trunclns:
61
Hình 3. 13: Chạy ob MINUS của bảng IFTB_Currency
e. Với job PAR_IFTB_CUSTOMER_2022_MNS_Trunclns

62

(SELECT A.CST_ID, A.PRIM_BR, 'I' REC_IND, #pdate# PPN_DT
FROM IFTB_CUSTOMER_2022_TDY A
MINUS
SELECT B.CST_ID, B.PRIM_BR, 'I' REC_IND, #pdate# PPN_DT
FROM IFTB_CUSTOMER_2022_PDY B
)
UNION ALL
(
SELECT B.CST_ID, B.PRIM_BR, 'D' REC_IND, #pdate# PPN_DT
MINUS
SELECT A.CST_ID,A.PRIM_BR, 'D' REC_IND, #pdate# PPN_DT
FROM IFTB_CUSTOMER_2022_TDY A
)
UNION ALL
(
SELECT C.CST_ID,C.PRIM_BR, 'U' REC_IND,#pdate# PPN_DT
FROM
(
SELECT A.*
FROM IFTB_CUSTOMER_2022_TDY A, IFTB_CUSTOMER_2022_PDY B
WHERE A.CST_ID =B.CST_ID
63
MINUS
SELECT B.*
) C
)
Kết quả sau khi chạy job PAR_IFTB_CUSTOMER_2022_MNS_Trunclns:
64
Hình 3. 14: Chạy job Minus của bảng IFTB_CUSTOMER
f. Với job PAR_IFTB_DEP_MASTER_2022_MNS_Trunclns

65

(
SELECT A.CTR_ID ,'I' REC_IND, #pdate# PPN_DT
FROM IFTB_DEP_MASTER_TDY_2022 A
MINUS
SELECT B.CTR_ID, 'I' REC_IND, #pdate# PPN_DT
FROM IFTB_DEP_MASTER_PDY_2022 B
)
UNION ALL
(
SELECT B.CTR_ID, 'D' REC_IND, #pdate# PPN_DT
MINUS
SELECT A.CTR_ID, 'D' REC_IND, #pdate# PPN_DT
FROM IFTB_DEP_MASTER_TDY_2022 A
)
UNION ALL
(
SELECT C.CTR_ID, 'U' REC_IND, 20220101 PPN_DT
FROM
(
SELECT A.*
FROM IFTB_DEP_MASTER_TDY_2022 A, IFTB_DEP_MASTER_PDY_2022 B
66
WHERE A.CTR_ID=B.CTR_ID
MINUS
SELECT B.*
) C
)
Kết quả sau khi chạy job PAR_IFTB_DEP_MASTER_2022_MNS_Trunclns:
67
Hình 3. 15: Chạy job MINUS của bảng IFTB_DEP_MASTER
g. Với job PAR_IFTB_LOAN_MASTER_2022_MNS_Trunclns

68

(
SELECT A.CTR_ID ,'I' REC_IND, #pdate# PPN_DT
FROM IFTB_LOAN_MASTER_TDY_2022 A
MINUS
SELECT B.CTR_ID, 'I' REC_IND, #pdate# PPN_DT
FROM IFTB_LOAN_MASTER_PDY_2022 B
)
UNION ALL
(
SELECT B.CTR_ID, 'D' REC_IND, #pdate# PPN_DT
MINUS
SELECT A.CTR_ID, 'D' REC_IND, #pdate# PPN_DT
FROM IFTB_LOAN_MASTER_TDY_2022 A
)
UNION ALL
(
SELECT C.CTR_ID, 'U' REC_IND, #pdate# PPN_DT
FROM
(
SELECT A.*
69
FROM IFTB_LOAN_MASTER_TDY_2022 A, IFTB_LOAN_MASTER_PDY_2022 B

WHERE A.CTR_ID=B.CTR_ID
MINUS
SELECT B.*
) C
)
Kết quả sau khi chạy job PAR_IFTB_DEP_MASTER_2022_MNS_Trunclns:
70
Hình 3. 16: Chạy job MINUS của bảng IFTB_LOAN_MASTER
3.5. Tầng Atomic

3.5.1 Các vùng trong Atomic
Hệ thống bản ghi đã được chia thành các vùng để dễ hiểu và trực quan. Các vùng sau đây
đã được xác định:
Arrangement: sắp xếp các đơn vị cơ bản, tiền đặt cọc, thế chấp
Involved Party: các đơn vị ghi lại thông tin cơ bản về khách hàng và thông tin liên lạc của
họ (điện thoại, email, địa chỉ, vv)
Classification: các đơn vị dữ liệu chính như Sản phẩm, Lịch sử Tỷ giá, Đơn vị tiền tệ, Giá
trị phân loại
Resource Item: bất kỳ hạng mục giá trị nào được Tổ chức Tài chính quan tâm cụ thể.
71
3.5.2 Sơ đồ tổng quát của Atomic
Hình 3. 17: Các thực thể chính và quan hệ trong Atomic
Đây là mô hình tổng quát và mối liên hệ giữa các thực thể chính thuộc các nhóm chính đã
đề cập ở trên.
Arrangement (hợp đồng): Arrangement đại diện cho một hợp đồng, có tiềm năng hoặc
thực tế, liên quan đến hai hoặc nhiều Bên tham gia, cung cấp và khẳng định các quy tắc
và nghĩa vụ liên quan đến việc bán, trao đổi hoặc cung cấp hàng hoá và dịch vụ; Ví dụ
như Hợp đồng # 123 (Một chứng chỉ cụ thể của hợp đồng tiền gửi giữa tổ chức tài chính
và John Doe), Hợp đồng # 346 (thỏa thuận sẽ cụ thể giữa tổ chức tài chính và John Doe
bao gồm Mary Doe là người thụ hưởng nhưng không tham gia vào hợp đồng).
* Lưu ý thiết kế *
Mặc dù mô hình lôgic cho AR chứa nhiều cấp độ phân lớp phụ, mô hình vật lý mặc định
sẽ làm giảm hai thành phần này - một AR và một tập hợp các phân nhóm AR cụ thể. Mô
hình vật lý mặc định được xây dựng bằng cách thiết lập các giá trị logic-only / physical-
only trên các thực thể, các thuộc tính và các mối quan hệ. Bằng cách thay đổi các flag
này, các tổ chức tài chính có thể điều chỉnh mô hình vật lý của hệ thống AR phù hợp với
nhu cầu của họ, ví dụ: Hợp đồng Supertype có thể bị sụp đổ vào tất cả các phân nhóm.
Arrangement / Involved Party Rltnp (Quan hệ AR/IR): Quan hệ AR phải có một quan hệ
tới IP. Ví dụ: IP John Doe là chủ sở hữu của một hợp đồng cho một khoản vay; IP Mary
Doe cung cấp tài chính cho một hợp đồng.
72
* Lưu ý thiết kế *
Mối quan hệ nhất định giữa các IP và các AR được xác định cụ thể hơn ở Arrangement
Subtype Level.
Arrangement/ Product Rltnp (Quan hệ AR/ Product): Quan hệ AR/ Product ghi lại tất cả các mối
quan hệ giữa AR và Product. Ví dụ: AR # 72291 (Một thoả thuận đầu tư) đầu tư vào Product #
7821 (một thị trường công cụ tài chính)
Involved Party (Bên tham gia): IP xác định bất kỳ cá nhân, nhóm cá nhân, tổ chức, đơn vị tổ chức
hoặc vị trí việc làm mà tổ chức tài chính mong muốn giữ thông tin; Ví dụ: IP 124 (John Smith), IP
# 432 (Tổ chức Tài chính Xyz), IP # 453 (Phòng Marketing của Tổ chức Tài chính Xyz), IP # 681
(thương gia nước ngoài).
Customer (Khách hàng): Customer là một vai trò của một IP được xem là nhận các dịch vụ hoặc
sản phẩm từ Tổ chức Tài chính hoặc một trong các Đơn vị Tổ chức của nó, hoặc là người có tiềm
năng nhận các dịch vụ hoặc sản phẩm đó.
Organiztion Unit (Đơn vị tổ chức): Organization Unit là một IP là một bộ phận hoặc phân khu của
Tổ chức được thành lập nhằm xác định các trách nhiệm chức năng riêng biệt; Ví dụ: Tổ chức # 66
(Ngân hàng Xyz) có thể chứa một số Đơn vị tổ chức như Phân khu A, Chi nhánh B, Uỷ ban C,
Đội D hoặc các nhóm ít chính thức hơn như Dự án P hoặc Nhóm T.
Involved Party/ Classification (quan hệ IP/CL): Quan hệ IP/CL cung cấp một lịch sử thay đổi giá
trị của một Involved Party Rltnp Classification Scheme được áp dụng cho một IP. Ví dụ một cá
nhân (quan hệ IP/CL) có thể là Độc thân, sau đó lập gia đình, sau đó ly hôn, rồi cưới, rồi Góa phụ
(Ed), sau đó cưới, rồi Ly dị. Cũng có nhiều hơn một Classification Value trong một Scheme có thể
áp dụng tại bất cứ lúc nào - một cá nhân có thể có nhiều hơn một trạng thái không đủ tư cách pháp
lý.
Involved Party/ Involved Party Rltnp (quan hệ IP/IP): Quan hệ IP / IP xác định tất cả các mối quan
hệ giữa hai IP. Hai IP đều có thể có liên quan đến một số loại quan hệ; Ví dụ: IP (Quan hệ IP/IP) #
4632 (Công ty A) 'Là Khách hàng' cũng là 'Nhà cung cấp' của IP # 2392 (Tổ chức Tài chính Abc).
Currency (tiền tệ): Currency là phương tiện trao đổi cho các giao dịch hàng hoá hoặc dịch vụ
thường được phát hành và bảo lãnh bởi cơ quan có thẩm quyền hợp pháp. Ví dụ: Đô la Mỹ,
Sterling, Euro, v.v ...
Resource Item : Bất kỳ một tài sản nào liên quan tới quá trình hoạt động kinh doanh của ngân
hàng.
73
3.5.3. ETL tầng Atomic

ETL tầng Atomic cho Involved Party
Hình 3. 18: ETL vùng Atomic cho vùng Involved Party
Chú ý, đối với thông tin Khách hàng Cá nhân, Doanh nghiệp, Định chế, cần thực hiện
mapping dữ liệu để đẩy thông tin lên các bảng tương ứng IND và ORG.
Đối với thông tin về IP_ID của Cán bộ quản lý khách hàng (là nhân viên của BIDV)
sẽ được cập nhật sau khi hoàn thành ETL cho IP, CST, IND và ORG.
Associatives
Hình 3. 19: Quy trình chạy ETL vùng Atomic cho vùng Arrangement
Đối với Term Deposit, quy trình ETL như sau:
74
3.5.4. Tạo job tầng Atomic

Ở Atomic thì ta sẽ phải tạo 2 job, 1 job đẩy dữ liệu lên bảng tạm, job còn lại đẩy dữ liệu
từ bảng tạm lên bảng đích
a. Resource Item Val
Với job đẩy dữ liệu lên bảng tạm, với câu SQL ở INPUT là:
SELECT FUNCTION_HASH02('RI|IFTB_CLT_MASTER', A.CLT_CODE ) AS RI_ID,
FUNCTION_HASH02 ('CL|SRC_STM', 'IFTB.CLT_MASTER') SRC_STM_ID,
FUNCTION_HASH02 ('CL|IFTB.CCY', B.CCY_CODE) CCY_ID,
B.CLT_VAL_LCY VAL_LCY,
B.CLT_VAL_FCY VAL_FCY,
#pdate# PPN_DT,
#pdate# EFF_DT,
99991231 END_DT,
A.REC_IND REC_IND
FROM IFTB_CLT_MASTER_MNS_2022 A
LEFT JOIN IFTB_CLT_MASTER_TDY_2022 B ON A.CLT_CODE = B.CLT_CODE;
Hình 3. 20: Chạy job tạm vùng Atomic của Resource Item Val
75
Với job đẩy dữ liệu từ bảng tạm lên bảng đích, với câu SQL ở INPUT là:
SELECT A.RI_ID,
A.SRC_STM_ID,
A.CCY_ID,
A.VAL_LCY,
A.VAL_FCY,
NVL(B.EFF_DT, A.EFF_DT) EFF_DT,
DECODE (A.REC_IND, 'D', #pdate#, NVL (B.END_DT, A.END_DT)) END_DT,
A.PPN_DT
FROM TWT_RI_VAL_2022_Kien A
LEFT JOIN SOR_RI_VAL_2022 B ON A.RI_ID = B.RI_ID;
Hình 3. 21: Chạy job đích vùng Atomic của Resource Item Val
b. Resource Item/ Involved Party Rltnp

SELECT FSSTRAINING.FUNCTION_HASH02('RI' || '|' || 'IFTB_CLT_MASTER' ,A.CLT_CODE ) AS RI_ID,
FSSTRAINING.FUNCTION_HASH02 ('CL' ||'|'|| 'SRC_STM', 'IFTB.CLT_MASTER') src_stm_id ,
76
FSSTRAINING.FUNCTION_HASH02('CL' || '|' || 'RI_X_IP_TP', 'RI_X_CST') RIX_IP_RLTNP_TP_ID ,
FSSTRAINING.FUNCTION_HASH02('IP' || '|' || 'IFTB.CUSTOMER' , B.OWNER_ID ) IP_ID,
#pdate# EFF_DT, 9991231 END_DT, #pdate# PPN_DT, A.REC_IND REC_IND
FROM IFTB_CLT_MASTER_MNS_2022 A LEFT JOIN IFTB_CLT_MASTER_TDY_2022 B
ON A.CLT_CODE = B.CLT_CODE
Hình 3. 22: Chạy job tạm vùng Atomic của Resource Item X IP
SELECT TWT.RI_ID,
TWT.IP_ID,
TWT.SRC_STM_ID,
#pdate# PPN_DT,
TWT.RIX_IP_RLTNP_TP_ID,
#pdate# EFF_DT,
99991231 END_DT
FROM TWT_RIX_IP_RLTNP_2022 TWT
LEFT JOIN RIX_IP_RLTNP_2022 B
ON TWT.RI_ID = B.RI_ID
77
Hình 3. 23: Chạy job đích vùng Atomic của Resource Item X IP
c. Resource Item
SELECT
FUNCTION_HASH02('RI' || '|' || 'IFTB_CLT_MASTER' ,CLT_CODE ) AS RI_ID,
FUNCTION_HASH02('RI' || '|' || 'RI_TP' , 'CLT' ) AS RI_TP_ID,
A.CLT_CODE UNQ_ID_IN_SRC_STM,
A.MAT_DT PPN_DT
78
Hình 3. 24: Chạy job vùng Atomic của Resource Item
SELECT A.RI_ID,
A.UNQ_ID_IN_SRC_STM,
A.RI_TP_ID,
A.PPN_DT
FROM TWT_RI_2022_Kien A
LEFT JOIN SOR_RI_2022 B ON A.RI_ID = B.RI_ID;
79
Hình 3. 25: Chạy job đích vùng Atomic của Resource Item
d. Organization Unit
SELECT FUNCTION_HASH02('IP' || '|' || 'IFTB.BRANCH' , A.BR_CODE) OU_ID, #pdate# ppn_dt,
FSSTRAINING.FUNCTION_HASH02('CL|SRC_STM','IFTB.BRANCH') src_stm_id, B.BR_CODE

ORG_CODE, A.REC_IND REC_IND
FROM IFTB_BRANCH_MNS_2022 A LEFT JOIN IFTB_BRANCH_TDY_2022 B
ON A.BR_CODE = B.BR_CODE
80
Hình 3. 26: Chạy job tạm vùng Atomic của Organization Unit
SELECT A.OU_ID,
A.PPN_DT,
A.SRC_STM_ID,
A.ORG_CODE
FROM TWT_IP_OU_2022 A LEFT JOIN OU_2022 C ON A.OU_ID = C.OU_ID
81
Hình 3. 27: Chạy job đích vùng Atomic của Organization Unit
e. Involved Party/ Involved Party Rltnp

SELECT FSSTRAINING.FUNCTION_HASH02('IP' || '|' || 'IFTB.CUSTOMER' , A.CST_ID) SBJ_IP_ID,
FSSTRAINING.FUNCTION_HASH02('IP' || '|' || 'IFTB.BRANCH' , A.PRIM_BR) OBJ_IP_ID,
FSSTRAINING.FUNCTION_HASH02 ('CL' ||'|'|| 'SRC_STM', 'IFTB.CUSTOMER') src_stm_id ,
FSSTRAINING.FUNCTION_HASH02('CL' || '|' || 'IP_X_IP_TP', 'IP_X_OU') IPX_IP_RLTNP_TP_ID,
#pdate# ppn_dt,
B.EFF_CST_DT EFF_DT,
B.END_CST_DT END_DT, A.REC_IND REC_IND
FROM IFTB_CUSTOMER_2022_MNS A LEFT JOIN IFTB_CUSTOMER_2022_TDY B
ON A.CST_ID = B.CST_ID
82
Hình 3. 28: Chạy job tạm vùng Atomic của Involved Party X IP
SELECT TWT.SBJ_IP_ID,
TWT.OBJ_IP_ID,
TWT.SRC_STM_ID,
#pdate# PPN_DT,
TWT.IPX_IP_RLTNP_TP_ID,
#pdate# EFF_DT,
19991231 END_DT
FROM TWT_IPX_IP_RLTNP_CST_2022 TWT
LEFT JOIN IPX_IP_RLTNP_2022 B
ON TWT.SBJ_IP_ID = B.SBJ_IP_ID
83
Hình 3. 29: Chạy job đích ùng Atomic của Involved Party X IP
f. Customer
SELECT
FSSTRAINING.FUNCTION_HASH02('IP' || '|' || 'IFTB.CUSTOMER' ,A.CST_ID) CST_ID,
FSSTRAINING.FUNCTION_HASH02('CL|IP_LC_ST_TP',B.CST_STATUS) cst_lcs_tp_id,
A.cst_id UNQ_ID_IN_SRC_STM,
FUNCTION_HASH02('CL|CST_TP',
CASE WHEN B.CST_MSEG_CODE IN ('D/NGHIEP','DN-FPT','NGAN HANG') THEN B.CST_MSEG_CODE END)

CST_TP_ID,
FSSTRAINING.FUNCTION_HASH02('CL|IDY_TP', B.IDY_CODE) idy_tp_id,
B.EFF_CST_DT EFF_DT,
99991231 END_CST_DT,
FSSTRAINING.FUNCTION_HASH02('CL|CST_MKT_SGMNT', B.CST_MSEG_CODE) CST_MKT_SEQ_ID,
A.REC_IND REC_IND
84
FROM IFTB_CUSTOMER_2022_MNS A left join IFTB_CUSTOMER_2022_TDY B
on A.CST_ID = B.CST_ID ;
SELECT A.CST_ID,
A.CST_LCS_TP_ID,
A.UNQ_ID_IN_SRC_STM,
A.CST_TP_ID ,
A.IDY_TP_ID,
NVL (C.EFF_CST_DT, A.EFF_CST_DT) EFF_CST_DT,
DECODE (A.REC_IND, 'D', #pdate#, NVL (C.END_CST_DT, A.END_CST_DT)) END_CST_DT,
A.CST_MKT_SQE_ID
FROM TWT_IP_CST_CIF_2022 A LEFT JOIN CST_2022 C ON A.CST_ID = C.CST_ID
85
g. Currency
SELECT
FUNCTION_HASH02 ('CL' ||'|'|| 'IFTB.CCY', C.CCY_CODE) CCY_ID ,
C.CCY_CODE CCY_CODE ,
FUNCTION_HASH02 ('CL' ||'|'|| 'SRC_STM', 'IFTB.CCY') SRC_STM_ID ,
20220101 PPN_DT,
B.REC_IND
FROM
IFTB_CCY_MNS_2022 B LEFT JOIN IFTB_CCY_TDY_2022 C
ON C.CCY_CODE = B.CCY_CODE;
86
SELECT A.CCY_ID ,
A.CCY_CODE,
A.SRC_STM_ID ,
A.PPN_DT,
A.REC_IND
FROM TWT_CCY_2022 A LEFT JOIN IFTB_CCY C ON A.CCY_ID = C.CCY_ID;
87
3.6. Tầng Data Mart

3.6.1. Tổng quát về DataMart, Dimension và Fact
a. Khái niệm Data Mart
Một tập hợp các bảng Dimension và Fact có liên quan kết hợp để tạo thành Data Mart
Tác giả chọn mô hình hình sao nhằm tối ưu hóa tốc độ và dễ dàng phân tích nhiều chiều.
b. Định nghĩa Dimension
Bảng Dimension chứa các dữ liệu về thuộc tính dùng để phân loại dữ liệu trong bảng
Fact.
Bảng Dimension thường có một yếu tố thứ bậc, nhờ đó dimension có thể được 'drill' lên
hoặc xuống. Ví dụ: sản phẩm ở cấp độ chi tiết có thể được phân loại thành nhóm cao hơn
để cung cấp thông tin về mức tóm tắt.
c. Đặc trưng của Dimension
Mỗi dimension phải có một bộ giá trị đầy đủ và hợp lệ, phải được xác định trước hoặc có
nguồn gốc từ hệ thống của bản ghi.
Mỗi dimension có thể được sử dụng lại trên các data mart để đảm bảo tính nhất quán của
thông tin và phân tích.
88
Tất cả các phân cấp được định nghĩa trong chính bảng dimension của nó.
Không có giá trị 'mã' nào được định nghĩa là thuộc tính dimension, trừ khi mã mang ý
nghĩa kinh doanh (ví dụ: đơn vị tiền tệ). Tất cả các cột của bản ghi Phân loại đã được
chuyển đổi sang tên hoặc từ mô tả tương đương.
Tất cả khóa chính của mỗi dimension (và khoá ngoại trong mỗi fact) đều có tiêu chuẩn
đặt tên của Dimension ID với định dạng xxxxxxx
Hệ thống bản ghi định danh được giữ như một thuộc tính của dimension trong trường hợp
có Hệ thống Bản ghi tương đương (ví dụ: Khách hàng, Tổ chức và Đơn vị Tổ chức).
Khóa chính là 'Dimension Id' nói trên. Mỗi lần có thay đổi đối với bản ghi dimension,
một dimension Id mới được tạo và tất cả dữ liệu fact được liên kết với khoá của
dimension mới đó. Các định danh Surrogate key của hệ thống bản ghi không thay đổi
nhằm mục đích lưu lịch sử.
d. Cấu trúc Dimension
Công cụ báo cáo yêu cầu dữ liệu thứ bậc của dimension được 'trải' ra; Điều này có nghĩa
là cha của một phần tử báo cáo xuất hiện trong một cột ở bên trái mục. Tất cả các mục
‘thiếu' được "thêm" để tạo ra một cấu trúc chuẩn. Cấu trúc trải được sử dụng để drill lên
và xuống và tóm tắt bảng thực tế một cách dễ dàng.
e. Sơ đồ mô hình logic các Dimension chính
Như đã định nghĩa ở trên, những điều sau đây được coi là các dimension chính hoặc phổ
biến. Khách hàng và hợp đồng có thể được sử dụng như là các vùng phân tích theo quyền
của họ.
89
Hình 3. 30: Sơ đồ mô hình logic các Dimension chính
f. Định nghĩa Fact

Bảng Fact chứa các dữ liệu đã được tính toán hoặc thống kê cho nghiệp vụ ngân hàng
(chi phí, doanh thu, lợi nhuận…). Bảng Fact thông thường chỉ có hai loại trường dữ liệu
là số (numeric value) và khóa ngoài (foreign key) tham chiếu đến các bảng Dimension.
Trong bảng Fact có nhiều giá trị số được gọi là các Measure.
g.Đặc trưng của Fact
Tất cả các khoản tiền được ghi nhận ở cả LCY (VND) và FCY (các loại tiền tệ khác).
Chỉ có thể tính tổng số tiền LCY, và tất nhiên là số tiền FCY cũng có thể tính tổng khi
cùng một loại tiền tệ.
Các measure cũng có thể được tái sử dụng trên các khu vực phân tích, nhưng giá trị có
thể khác nhau vì nó sẽ bị hạn chế bởi một tập hợp các dimension khác nhau.
Giá trị measure luôn luôn tương ứng với mức chi tiết thấp nhất của fact; Nói cách khác,
nếu mức thấp nhất của fact là một hợp đồng thì sau đó số dư cuối kỳ sẽ là số dư cuối kỳ
của hợp đồng; Nếu mức thấp nhất của fact là Khách hàng thì số dư cuối kỳ sẽ là một số
dư cuối kỳ trung bình của các hợp đồng mà khách hàng sở hữu.
Các loại measure sau đây được sử dụng trong thiết kế data mart:
Số dư cuối kỳ - của mỗi hợp đồng bằng đồng nội tệ (VND) và ngoại tệ (đồng tiền gốc của
hợp đồng, có thể là VND, chỉ có thể tính tổng với các giá trị LCY)
90
Số dư trung bình - số dư trung bình cho mỗi lần sắp xếp được tính cho các khoảng thời
gian sau
Tháng đến ngày - từ ngày đầu tiên của tháng đến ngày phân tích hiện tại
Quý đến ngày - từ ngày đầu tiên của quý đến ngày phân tích hiện tại
Năm đến ngày - từ ngày đầu tiên của năm đến ngày phân tích hiện tại.
3.6.2. Các job DIMENSION trong DataMart
Job đẩy dữ liệu từ Atomic vào bảng tạm trên Datamart
Job này sẽ xác định những bản ghi thay đổi ở Atomic ngày hôm nay và chuẩn bị dữ liệu
cần sử dụng trên bảng đích ở Datamart đẩy vào bảng tạm.
a. Currency Dimension
Stage Input, sử dụng câu lệnh SQL:
SELECT
A.CCY_DIM_ID,
A.CCY_ID CCY_ID,
A.CCY_CODE CCY_CODE,
A.SRC_STM_ID SRC_STM_ID,
#pdate# EFF_DT,
99991231 END_DT
FROM CCY_DIM_2022 A INNER JOIN TWT_CCY_DIM_2022 B ON A.CCY_ID =
B.CCY_ID
WHERE A.EFF_DT <= #pdate# AND A.END_DT > #pdate#
AND NOT (NVL (A.CCY_CODE, '$X$') = NVL (B.CCY_CODE, '$X$')
AND NVL (A.SRC_STM_ID, '$X$') = NVL (B.SRC_STM_ID, '$X$'));
Stage Ouput: Set connection là connection tới Datamart (ORA_CONN_DMT), Write

mode là Insert, Table action là Truncate.
Kết quả sau khi chạy job:
91
Hình 3. 31: Chạy job tạm vùng Datamart của Currency
Đây là Job Dimension nên mình áp dụng đẩy dữ liệu từ bảng tạm trên Datamart vào
bảng đích
Job sẽ sử dụng dữ liệu từ bảng tạm vừa chuẩn bị ở trước đẩy vào bảng đích.
Stage Input, ta sử dụng câu lệnh SQL:
Câu select lấy bản ghi mới, hoặc thay đổi và lấy bản ghi cũ thay đổi ngày END_DT
SELECT CCY_ID, CCY_CODE, SRC_STM_ID, PPN_DT FROM CCY_2022
WHERE PPN_DT = #pdate#
Stage Output : Set connection là connection tới Datamart (ORA_CONN_DMT), Write
mode là Delete then Insert, Table action là Append:
92
Hình 3. 32: Chạy job đích ùng DataMart của Currency
b. Customer Dimension
SELECT CST.CST_ID CST_ID,
IP.UNQ_ID_IN_SRC_STM CST_CODE,
IP.IP_NM CST_NM,
TYP.CL_CODE CST_TP,
STT.CL_CODE CST_LC_ST_TP,
K.ORG_CODE PRIM_OU_CODE,
CST.EFF_CST_DT EFF_CST_DATE,
CST.END_CST_DT END_CST_DATE
FROM
cst_khoanv CST
LEFT JOIN IP_KHOANV IP ON
93
CST.CST_ID = IP.IP_ID
LEFT JOIN (
SELECT
OU.ORG_CODE ,
CST_OU.OBJ_IP_ID,
CST_OU.SBJ_IP_ID ,
CST_OU.EFF_DT ,
CST_OU.END_Dt
FROM
IP_RLTNP_KHOANV CST_OU
LEFT JOIN OU_KHOANV OU ON
OU.OU_ID = cst_ou.OBJ_IP_ID ) K
ON K.SBJ_IP_ID = CST.CST_ID
AND K.EFF_DT <= #pdate# AND K.END_DT > #pdate#
LEFT JOIN CV_KHOANV TYP
ON TYP.CL_ID = CST.CST_TP_ID
LEFT JOIN CV_KHOANV STT
ON STT.CL_ID = CST.CST_LCS_TP_Id;
94
Hình 3. 33: Chạy job tạm vùng DataMart vủa Customer
bảng đích theo mô hình input old-new
Câu select lấy bản ghi mới, hoặc thay đổi và lấy bản ghi cũ thay đổi ngày END_DT
SELECT A.CST_DIM_ID,
A.CST_ID,
A.CST_CODE,
A.CST_NM,
A.CST_TP,
A.CST_LC_ST_TP,
A.PRIM_OU_CODE,
A.EFF_DT,
95
#pdate# END_DT
FROM CST_DIM_2022 A INNER JOIN TWT_CST_DIM_2022 B ON A.CST_ID =
B.CST_ID
AND NOT (
NVL(A.CST_NM, '$X$') = NVL(B.CST_NM, '$X$')
AND NVL(A.CST_TP, '$X$') = NVL(B.CST_TP, '$X$')
AND NVL(A.CST_LC_ST_TP, '$X$') = NVL(B.CST_LC_ST_TP, '$X$')
AND NVL(A.PRIM_OU_CODE, '$X$') = NVL(B.PRIM_OU_CODE, '$X$'));
Hình 3. 34: Chạy job đích vùng DataMart của Customer
c. Organization Unit
96
SELECT OU_ID OU_ID, ORG_CODE OU_CODE, SRC_STM_ID SRC_STM_ID

FROM OU_2022 WHERE PPN_DT = #pdate#;

bảng đích
Câu select lấy bản ghi mới, hoặc thay đổi và lấy bản ghi cũ thay đổi ngày END_DT:
SELECT SEQ_OU_DIM.NEXTVAL OU_DIM_ID ,
A.OU_ID ,
97
A.OU_CODE,
A.SRC_STM_ID,
#pdate# EFF_DT,
99991231 END_DT
FROM TWT_OU_DIM A
WHERE NOT EXISTS
(
SELECT 1 FROM OU_DIM_2022 B
WHERE A.OU_ID = B.OU_ID
AND NVL(A.OU_CODE, '$X$') = NVL(B.OU_CODE, '$X$')
AND NVL(A.SRC_STM_ID, '$X$') = NVL(B.SRC_STM_ID, '$X$')
AND B.EFF_DT <= #pdate# AND B.END_DT > #pdate#);
98
d. Resource Item Dimension

SELECT A.RI_ID AS RSC_ID, A.UNQ_ID_IN_SRC_STM AS RSC_CODE,
A.PPN_DT AS EFF_DT, 99991231 AS END_DT
FROM SOR_RI_2022 A
WHERE A.PPN_DT = 20220101
bảng đích
Câu select lấy bản ghi mới, hoặc thay đổi và lấy bản ghi cũ thay đổi ngày END_DT:
99
SELECT A.RI_DIM_ID ,
A.RSC_ID ,
A.RSC_CODE ,
#pdate# EFF_DT,
99991231 END_DT
FROM TWT_RI_DIM_2022 B JOIN RI_DIM_2022 A ON A.RSC_ID = B.RSC_ID
AND A.RSC_ID = B.RSC_ID
AND NVL(A.RSC_CODE, '$X$') = NVL(B.RSC_CODE, '$X$')
3.6.3. Các Job Fact trong Datamart

a. Arrangement Analysis Fact
SELECT
100
SMY.CLS_BAL_FCY,
SMY.CLS_BAL_LCY,
SMY.MSR_PRD_ID,
PD.UNQ_ID_IN_SRC_STM PD_CODE,
CST.CST_ID,
OU.ORG_CODE OU_CODE,
AR.AR_ID,
SMY.CCY_ID
FROM AR_TVR_SMR_2022 SMY

INNER JOIN AR_2022 AR ON SMY.AR_ID = AR.AR_ID
LEFT JOIN AR_PD_RLTNP_2022 AR_X_PD ON
(AR.AR_ID = AR_X_PD.AR_ID
AND AR_X_PD.EFF_DT <= #pdate#
AND AR_X_PD.END_DT > #pdate#)
LEFT JOIN CV AR_X_PD_RLTNP_TP ON

(AR_X_PD.ARX_PD_RLTNP_TP_ID = AR_X_PD_RLTNP_TP.CL_ID
AND AR_X_PD_RLTNP_TP.CL_CODE='MASTER_PRODUCT' )
LEFT JOIN PD PD ON AR_X_PD.PD_ID = PD.PD_ID

LEFT JOIN SOR_ARX_IP_SMR_2022 AR_X_CST ON
(AR.AR_ID = AR_X_CST.AR_ID
AND AR_X_CST.EFF_DT <= #pdate#
AND AR_X_CST.END_DT > #pdate#)
LEFT JOIN CV AR_X_CST_RLTNP_TP ON
101
(AR_X_CST.ARX_IP_RLTNP_TP_ID = AR_X_CST_RLTNP_TP.CL_ID
AND AR_X_CST_RLTNP_TP.CL_CODE = 'AR_X_CST')
LEFT JOIN TWT_IP_CST_CIF_2022 CST ON AR_X_CST.IP_ID = CST.CST_ID

LEFT JOIN N3_ARX_IP_RLTNP AR_X_BR ON
(AR.AR_ID = AR_X_BR.AR_ID
AND AR_X_BR.EFF_DT <= #pdate#
AND AR_X_BR.END_DT > #pdate#)
LEFT JOIN CV AR_X_BR_RLTNP_TP ON

(AR_X_BR.ARX_IP_RLTNP_TP_ID = AR_X_BR_RLTNP_TP.CL_ID
AND AR_X_BR_RLTNP_TP.CL_CODE = 'AR_X_OU')
LEFT JOIN TWT_IP_OU_2022 OU ON AR_X_BR.IP_ID = OU.OU_ID

102
Hình 3. 35: Chạy job tạm vùng DataMart của Arrangement Analysis Fact
Đây là Job Fact nên chúng ta áp dụng kiểu đẩy dữ liệu 1-1
Stage Input : Set connection là connection tới Datamart (ORA_CONN_DMT)
Ta sử dụng câu lệnh SQL:
SELECT
NVL(AC_AR_DIM.AC_AR_DIM_ID, 999999),
NVL(CST_DIM.CST_DIM_ID, 999999),
NVL(CCY_DIM.CCY_DIM_ID, 999999),
NVL(PD_DIM.PD_DIM_ID, 999999),
NVL(OU_DIM.OU_DIM_ID, 999999),
FCT.CLS_BAL_FCY,
FCT.CLS_BAL_LCY,
FCT.MSR_PRD_ID RPT_DT_DIM_ID
FROM TWT_AR_ANL_FCT_2022 FCT
LEFT JOIN AC_AR_DIM_2022 AC_AR_DIM ON
103
(AC_AR_DIM.AC_AR_ID = FCT.AR_ID
AND AC_AR_DIM.EFF_DT <= #pdate#
AND AC_AR_DIM.END_DT > #pdate#)
LEFT JOIN CST_DIM_2022 CST_DIM ON
( CST_DIM.CST_ID = FCT.CST_ID
AND CST_DIM.EFF_DT <= #pdate#
AND CST_DIM.END_DT > #pdate# )
LEFT JOIN CCY_DIM_2022 CCY_DIM ON
(CCY_DIM.CCY_ID = FCT.CCY_ID
AND CCY_DIM.EFF_DT <= #pdate#
AND CCY_DIM.END_DT > #pdate# )
LEFT JOIN PD_DIM_2022 PD_DIM ON
(PD_DIM.PD_CODE = FCT.PD_CODE
AND PD_DIM.EFF_DT <= #pdate#
AND PD_DIM.END_DT > #pdate# )
LEFT JOIN OU_DIM_2022 OU_DIM ON
(OU_DIM.OU_CODE = FCT.OU_CODE
AND OU_DIM.EFF_DT <= #pdate#
AND OU_DIM.END_DT > #pdate#)
Stage Output : Set connection là connection tới Datamart (ORA_CONN_DMT) , Write

mode là Insert, Table action là Append, tại mục Run before and after SQL statements
chọn Yes, điền câu delete ngày dữ liệu = ngày chạy dữ liệu vào mục Before SQL
statement.
104
Hình 3. 36: Chạy job đích vùng DataMart của Arrangement Analysis Fact
b. Card Arrangement Analysis Fact

SELECT AR.AR_ID AC_AR_ID, CST.IP_ID CST_ID, OU.IP_ID OU_ID,
SMY.CLS_BAL_FCY, SMY.CLS_BAL_LCY , #pdate# RPT_DT_DIM_ID
FROM AR_2022 AR
LEFT JOIN AR_TVR_SMR_2022 SMY
ON AR.AR_ID = SMY.AR_ID
AND AR.SRC_STM_ID = FUNCTION_HASH02 ('CL' ||'|'|| 'SRC_STM',
'IFTB.CARD_MASTER')
LEFT JOIN N3_ARX_IP_RLTNP CST
ON AR.AR_ID = CST.AR_ID
AND CST.ARX_IP_RLTNP_TP_ID = FUNCTION_HASH02('CL' || '|' ||
'AR_X_IP_TP', 'AR_X_CST')
AND CST.EFF_DT <= #pdate# AND #pdate# < CST.END_DT
105
LEFT JOIN N3_ARX_IP_RLTNP OU

ON AR.AR_ID = OU.AR_ID
AND OU.ARX_IP_RLTNP_TP_ID = FUNCTION_HASH02('CL' || '|' ||
'AR_X_IP_TP', 'AR_X_OU')
AND OU.EFF_DT <= #pdate# AND #pdate# < OU.END_DT
Hình 3. 37: Chạy job tạm vùng DataMart của Card Arrangement Analysis Fact
SELECT TWT.RPT_DT_DIM_ID,
nvl(aa.AC_AR_DIM_ID, 999999) AC_AR_DIM_ID,
nvl(cst.CST_DIM_ID, 999999) CST_DIM_ID,
ou.OU_DIM_ID,
106
nvl(twt.CLS_BAL_FCY,0) CLS_BAL_FCY,
nvl(twt.CLS_BAL_LCY,0) CLS_BAL_LCY
FROM TWT_CARD_AR_ANL_FCT_2022 twt
LEFT JOIN AC_AR_DIM_2022 AA
ON AA.AC_AR_ID = TWT.AC_AR_ID AND aa.EFF_DT <= #pdate# AND
aa.END_DT > #pdate#
LEFT JOIN CST_DIM_2022 CST
ON TWT.CST_ID = cst.CST_ID AND cst.EFF_DT <= #pdate# AND cst.END_DT >
#pdate#
LEFT JOIN OU_DIM_2022 ou
ON twt.OU_ID = ou.OU_ID
WHERE twt.RPT_DT_DIM_ID = #pdate#
statement.
107
Hình 3. 38: Chạy job đích vùng DataMart của Card Arrangement Analysis Fact
c. Resource Analysis
SELECT
NVL(E.CST_DIM_ID,999999) CST_DIM_ID,
NVL(C.CCY_DIM_ID,999999) CCY_DIM_ID,
NVL(B.VAL_LCY,0) CLS_BAL_LCY,
NVL(B.VAL_FCY,0) CLS_BAL_FCY,
#pdate# RPT_DT_DIM_ID
FROM SOR_RI_2022 A
LEFT JOIN SOR_RI_VAL_2022 B ON A.RI_ID = B.RI_ID
LEFT JOIN CCY_DIM_2022 C ON B.CCY_ID = C.CCY_ID AND B.EFF_DT <=
#pdate# AND #pdate# < B.END_DT
LEFT JOIN TWT_RIX_IP_RLTNP_MAS_2022 D ON A.RI_ID = D.RI_ID
108
LEFT JOIN CST_DIM_2022 E ON D.IP_ID = E.CST_ID AND E.EFF_DT <= #pdate#

AND E.END_DT > #pdate#;
SELECT TWT.RPT_DT_DIM_ID,
nvl(aa.AC_AR_DIM_ID, 999999) AC_AR_DIM_ID,
nvl(cst.CST_DIM_ID, 999999) CST_DIM_ID,
ou.OU_DIM_ID,
nvl(twt.CLS_BAL_FCY,0) CLS_BAL_FCY,
nvl(twt.CLS_BAL_LCY,0) CLS_BAL_LCY
FROM TWT_CARD_AR_ANL_FCT_2022 twt
109
LEFT JOIN AC_AR_DIM_2022 AA

ON AA.AC_AR_ID = TWT.AC_AR_ID AND aa.EFF_DT <= #pdate# AND
aa.END_DT > #pdate#
LEFT JOIN CST_DIM_2022 CST
ON TWT.CST_ID = cst.CST_ID AND cst.EFF_DT <= #pdate# AND cst.END_DT >
#pdate#
LEFT JOIN OU_DIM_2022 ou
ON twt.OU_ID = ou.OU_ID
WHERE twt.RPT_DT_DIM_ID = #pdate#
statement.
110
3.7.KẾT QUẢ SAU KHI ĐẨY DỮ LIỆU TỪ STAGING VÀO DATAMART

3.7.1. Dữ liệu bảng đích CCY_DIM_2022(Currency Dimension)
Hình 3. 39: Dữ liệu bảng đích CCY_DIM_2022
111
3.7.2. Dữ liệu bảng đích RI_DIM_2022(Resource Item Dimension)
Hình 3. 40: Dữ liệu bảng đích RI-DIM_2022
112
3.7.3. Dữ liệu bảng đích AR_ANL_2022(Arrangement Analyst Fact)
Hình 3. 41: Dữ liệu bảng đích AR_ANL_2022
3.7.4. Dữ liệu bảng đích RI_ANL_2022(Resource Item Dimension)

3.7.5. Dữ liệu bảng đích CST_DIM_2022(Customer Dimension)
Hình 3. 42: Dữ liệu bảng đích CST_DIM_2022
113
3.7.6. Dữ liệu bảng đích PD_DIM_2022(Product Dimension)

3.7.7. Dữ liệu bảng đích OU_DIM_2022(Organization Unit Dimension)
Hình 3. 43: Dữ liệu bảng OU_DIM_2022
3.7.8. Dữ liệu bảng đích CARD_AR_FCT_2022(Card Arrangement Fact)
Hình 3. 44: Dữ liệu bảng đích CARD_AR_FCT_2022
114
3.7.9. Dữ liệu bảng đích CST_AR_ANL_2022(Customer Arrangement Analyst

Dimension)
Hình 3. 45: Dữ liệu bảng đích CST_AR_ANL_2022
115
KẾT LUẬN
Sau một thời gian thực tập, em đã nghiên cứu và học hỏi được rất nhiều điều. Và cuối
cùng cũng đã hoàn thành đề tài với sự hướng dẫn nhiệt tình của giáo viên hướng dẫn và
anh chị đội ngũ Database ở Công ty FSS.
Các kết quả đạt được
Mục tiêu của đề tài phân tích quy trình ETL trong kho dữ liệu để quản lý lượng thông tin
lớn của ngân hàng. Sau đó thực hành việc đẩy dữ liệu qua quy trình ETL trong kho dữ
liệu.
Thông qua nội dung của đề tài từ chương 1 tới chương 3, em đã lần lượt trình bày về khái
niệm chung của kho dữ liệu, kiến trúc chung cũng như các mô hìnhlogic thường dùng,
hiện trạng kho dữ liệu hiện nay của ngân hàng. Tiếp theo em đã trình bày kiến trúc kho
dữ liệu mới dựa trên nền tảng công nghệ của hãng IBM từ CSDL đến công cụ ETL và
ứng dụng khai thác báo cáo.
Trên cơ sở tầng Atomic và Data Mart, với mô tả chi tiết các thực thể dữ liệu, từ cấu trúc
đến liên kết giữa các thực thể, hệ thống phân phối báo cáo trên công nghệ IBM Cognos sẽ
cung cấp các báo cáo phục vụ phân tích khách hàng.
Những điểm còn hạn chế
Mô hình của kho dữ liệu đưa ra trong đề tài chưa được kiểm nghiệm thực tế trong một
khoảng thời gian đủ dài để đảm bảo khả năng đáp ứng hiệu năng của ngân hàng.
Kho dữ liệu chưa có điều kiện thử nghiệm tích hợp từ các nguồn dữ liệu có độ phức tạo
cao.
Về thời gian đáp ứng, kho dữ liệu chưa xử lý được dữ liệu giao dịch trong ngày mà chỉ
kết xuất và xử lý vào cuối ngày.
Hướng phát triển trong tương lai
Tối ưu hóa lưu trữ trong CSDL để giảm thời gian trích xuất dữ liệu phục vụ báo cáo. Tối
ưu luồng xử lý đề giảm thời gian vận hành của kho dữ liệu hàng ngày, đẩy thời gian sẵn
sàng về báo cáo của ngân hàng lên càng sớm càng tốt.
Nhu cầu về các bài toán tổng hợp phân tích dữ liệu của ngân hàng luôn luôn phát triển,
dựa trên nghiệp vụ thực tế của Ngân hàng nhà nước, các thông tư và nghị định mới xuất
hiện liên tục vì vậy kho dữ liệu bắt buộc phải cập nhật theo thời gian thực.
Sau khi hoàn thành đề, em sẽ tiếp tục tìm hiểu và nghiên cứu, xử lý các lỗi ngoài ý muốn
và tăng các tính năng, tối ưu hóa tốc độ xử lý để đem lại hiệu quả cao hơn và cải tiến hệ
thống này lên trang web.
116
Tuy nhiên do kinh nghiệm chuyên môn chưa sâu và thời gian hoàn thành có hạn nên đề
tài của em vẫn còn những thiếu sót, em rất mong nhận được những ý kiến đóng góp của
cô và các bạn để đề tài của em được hoàn thiện hơn.
Em xin chân thành cảm ơn!
117
DANH MỤC THAM KHẢO:

- GIỚI THIỆU CÔNG TY FSS
- ĐỒ ÁN TỐT NGHIỆP PHÂN TÍCH THIẾT KẾ HỆ THỐNG BÁN HÀNG TẠI
CÔNG TY VINDA
118

Nguyễn Quang Hưng - cđtt (Recovered)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nguyễn Quang Hưng - cđtt (Recovered)

Uploaded by

Copyright:

Available Formats

Nguyễn Quang Hưng Chuyên Đề Thực Tập

3.2.2. Mục tiêu phân tích thiết kế kho dữ liệu....................................................................................33

DANH MỤC HÌNH ANHR

Hình 3. 1: Màn hình đăng nhập vào IBM Infosphere DataStage................................................................28

Hình 3. 39: Dữ liệu bảng đích CCY_DIM_2022.........................................................................................111

LỜI NÓI ĐẦU

CHƯƠNG I:TỔNG QUAN VỀ CƠ SỞ THỰC TẬP VÀ ĐỀ TÀI NGHIÊN CỨU

CHƯƠNG II: CƠ SỞ PHƯƠNG PHÁP LUẬN

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

Các không gian bảng.

❑ Quản lý và truy xuất siêu dữ liệu,

❑ Tích hợp: tích hợp dữ liệu từ nhiều nguồn dữ liệu

✓ Giải nén, biến đổi và tải là một quá trình:

✓ Tính mềm dẻo:

✓ Tính chuẩn hóa: thuật ngữ, kiến trúc

✓ Làm mới dữ liệu: Thời gian thực / Chế độ hàng loạt

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

Hình 3. 1: Màn hình đăng nhập vào IBM Infosphere DataStage

- Màn hình sau khi đăng nhập

Hình 3. 2: Giao dện IBM Infosphere Data

Khu vực (1) : thanh công cụ

Hình 3. 3: Giao diện Dbeaver

(2) Em chọn kết nối đến hệ quản trị cơ sở dữ liệu Oracle.

Hình 3. 4: Màn hình kết nối Database

Hình 3. 5: Quy trình ETL

Hình: Mô hình khái quát ETL trong kho dữ liệu

<tầng ghi dữ liệu> : STG, SOR, DMT

Dưới đây là ETL các bảng Master

Hình 3. 6: ETL các bảng Master

Ta sẽ tạo lần lượt bảng IFTB_CLT_MASTER_TDY, IFTB_CLT_MASTER_PDY và

Ta sẽ thực hiện câu lệnh:

Ta sẽ tạo lần lượt bảng IFTB_CARD_MASTER_TDY, IFTB_CARD_MASTER_PDY

Ta sẽ thực hiện câu lệnh:

Ta sẽ tạo lần lượt bảng IFTB_DEP_MASTER_TDY, IFTB_DEP_MASTER_PDY và

Ta sẽ thực hiện câu lệnh:

Ta sẽ tạo lần lượt bảng IFTB_LOAN_MASTER_TDY, IFTB_LOAN_MASTER_PDY

Ta sẽ thực hiện câu lệnh:

CREATE TABLE IFTB_LOAN_MASTER_MNS_2022

Hình 3. 7: ETL các bảng Summary

Ta sẽ tạo lần lượt bảng IFTB_CUSTOMER_ TDY, IFTB_CUSTOMER _PDY và

Ta sẽ thực hiện câu lệnh:

Ta sẽ tạo lần lượt bảng IFTB_BRANCH_ TDY, IFTB_BRANCH_PDY và

Ta sẽ thực hiện câu lệnh:

Ta sẽ tạo lần lượt bảng IFTB_CCY_ TDY_2022, IFTB_CCY _PDY_2022 và

Ta sẽ thực hiện câu lệnh:

3.4.3. Job Today

o Stage output : Set connection là connection tới Staging (ORA_CONN_STG),

Hình 3. 8: Chạy job today bảng IFTB_Master

3.4.3. Job Preday

Kết quả sau khi chạy job preday:

Hình 3. 9: Chạy job Preday bảng IFTB_Master

3.4.4. Job Minus

Với câu SQL sau :

Kết quả sau khi chạy job PAR_IFTB_CLT_MASTER_2022_MNS_Trunclns:

Hình 3. 10: Chạy job Minus bảng IFTB_Master

b. Với job PAR_IFTB_CLT_MASTER_2022_MNS_Trunclns

Với câu SQL sau :

Kết quả sau khi chạy job PAR_IFTB_CARD_MASTER_2022_MNS_Trunclns:

Hình 3. 11: Chạy job minus IFTB_Card_Master

c. Với job PAR_IFTB_BRANCH _2022_MNS_Trunclns

Với câu SQL sau :

Kết quả sau khi chạy job PAR_IFTB_CLT_MASTER_2022_MNS_Trunclns:

Hình 3. 12: Chạy job Minus của bảng IFTB_BRANCH