Thứ Hai, 11 tháng 10, 2010
Các khái niệm cơ bản của Multidimensional Modeling
1. Fact table
Fact table có thể được hiểu như là bảng chứa các dữ liệu có tính chất đo lường (measurement). Một fact (hay còn gọi là measure) trong data warehouse được dùng để minh họa cho một trường (field/column) chứa một giá trị đo lường được và đóng một vai trò quan trọng với business. Trên thực tế, ta hay gặp nhất các fact ở dạng số (numeric) và có tính chất cộng (additive).
Dưới đây là một ví dụ đơn giản về một fact table:
Daily Sales Fact Table
Date Key (FK)
Product Key (FK)
Store Key (FK)
Quantity Sold
Dollar Sales Amount
Có thể dễ dàng nhận thấy fact table Daily Sales chỉ có 2 loại dữ liệu chính: Foreign Key và Fact. Date Key, Product Key, và Store Key là các foreign keys. Quantity Sold và Dollar Sales Amount là các fact (measure). Date Key, Product Key, và Store Key liên kết đến các dimension table tương ứng là Date, Product, Store. Ta sẽ nói về dimension table ở phần sau.
Với cách tổ chức như trên, việc tính tổng lượng hàng hóa bán ra hoặc tổng thu nhập khá là đơn giản. Ta chỉ việc thực hiện phép toán cộng trên các record là xong. Cũng không khác nhiều lắm so với việc dùng table trong operational database. Điều khác biệt ở đây là tốc độ và sự thuận tiện.
Do cấu trúc của fact table khá đơn giản chỉ chứa duy nhất foreign key và fact, ngoài ra không có bất cứ thông tin nào khác nên tốc độ truy cập bảng khá nhanh. Một kỹ thuật hay dùng là tạo index cho các foreign key. Một kỹ thuật nữa là xây dựng sẵn các aggregate tables để tính toán trước một đại lượng nào đó dựa trên fact table.
2. Fact grain
Fact grain (độ mịn) là một khái niệm để xác định mức độ chi tiết của thông tin chứa trong fact table. Một quy định bắt buộc khi thiết kế fact table là: Tất cả các record trong fact table phải có cùng độ mịn.
Hãy xét bảng Daily Sales ở trên. Fact grain hiện tại của nó là: một loại sản phẩm (product) được bán tại một cửa hàng (store) trong một ngày (date). Bảng có các record sau:
Date Key Product Key Store Key Quantity Sold $ Sales Amount
2009-11-01 ABC XYZ 400 2000
2009-11-02 ABC XYZ 300 1500
2009-11-02 DEF UVW 500 2500
Với độ mịn như trên và giả sử rằng giá trị đơn vị của một sản phẩm là $5, ta có thể nói như sau:
- Loại sản phẩm ABC được bán tại cửa hàng XYZ trong ngày 2009-11-01 với số lượng là 400, thu về khoản tiền $2000.
- Loại sản phẩm ABC được bán tại cửa hàng XYZ trong ngày 2009-11-01 với số lượng là 300, thu về khoản tiền $1500.
- Loại sản phẩm DEF được bán tại cửa hàng UVW trong ngày 2009-11-02 với số lượng là 500, thu về khoản tiền $2500.
Tất cả các record ở trên đều thỏa mãn điều kiện: một loại sản phẩm (product) được bán tại một cửa hàng (store) trong một ngày (date). Nếu ta muốn tính tổng số lượng hàng hóa bán ra trong ngày 2009-11-02 trên mọi cửa hàng và mọi sản phẩm, ta sẽ có được con số sau: 300 + 500 = 800. Nếu ta muốn tính tổng số tiền thu được từ cửa hàng ABC trong tuần đầu tiên của tháng 11 trên mọi loại sản phẩm, ta có: 2000 + 1500 = $3500.
Giả sử rằng ta thay đổi độ mịn của fact table như sau: một loại sản phẩm (product) được bán tại một cửa hàng (store) trong một tuần (date). Dữ liệu trong bảng sẽ bắt buộc phải thay đổi theo để phù hợp với fact grain:
Date Key Product Key Store Key Quantity Sold $ Sales Amount
2009-11-Week-1 ABC XYZ 700 3500
2009-11-Week-1 DEF UVW 500 2500
Có thể thấy rằng khi độ mịn giảm, cụ thể trong trường hợp này là từ ngày đến tuần, số lượng record trong bảng cũng thay đổi theo, đồng nghĩa với tốc độ truy cập nhiều khả năng sẽ nhanh hơn. Thế nhưng đơn vị thời gian nhỏ nhất mà ta có thể tính toán được bây giờ là tuần. Nếu người dùng muốn tính toán theo đơn vị ngày, yêu cầu này không thể thực hiện được.
Giả sử bây giờ ta tăng độ mịn của fact table như sau: một loại sản phẩm (product) được bán tại một cửa hàng (store) tại một thời điểm (date). Lúc này fact table sẽ chứa dữ liệu như sau:
Date Key Product Key Store Key Quantity Sold $ Sales Amount
2009-11-01 9 a.m ABC XYZ 150 750
2009-11-01 10 a.m ABC XYZ 250 1250
2009-11-02 8:30 a.m ABC XYZ 100 500
2009-11-02 12 p.m ABC XYZ 200 1000
2009-11-02 9:45 a.m DEF UVW 50 250
2009-11-02 1:00 p.m DEF UVW 400 2000
2009-11-02 2 p.m DEF UVW 50 250
Một cách trực quan mà nói, độ mịn tăng dẫn đến số lượng record tăng lên đáng kể. Điều này có thể ảnh hưởng đến tốc độ truy cập nhưng bù lại nó giúp cho người dùng có nhiều lựa chọn hơn. Chẳng hạn nếu ta muốn xem tổng doanh số bán hàng trong buổi sáng trên mọi cửa hàng và mọi sản phẩm, ta có công thức sau: 750 + 1250 + 500 + 250 = $2750. So sánh với doanh số bán hàng vào buổi chiều 1000 + 2000 + 250 = $3250, một giám đốc kinh doanh có thể rút ra kết luận rằng xem ra người tiêu dùng có xu hướng đi shopping nhiều hơn vào buổi chiều, nhất là giờ nghỉ trưa. Từ đó, vị giám đốc này có thể đưa ra quyết định tung ra một chiến dịch khuyến mãi mới như giảm giá 10% mặt hàng ABC đồng thời tặng kèm một suất ăn nhanh miễn phí ngay tại cửa hàng .
Tóm lại, fact grain là thành tố cơ bản của fact table. Xác định đúng fact grain là một công tác quan trọng bậc nhất trong việc xây dựng một mô hình đa chiều. Đây là công việc đòi hỏi người thiết kế phải là những Data Architect giàu kinh nghiệm và có hiểu biết sâu sắc về business domain đang làm.
3.Dimension table
Nếu như fact table chứa các FK (foreign key) và measure, thì dimesion table chứa các thông tin miêu tả nghiệp vụ. Trong không gian của mô hình đa chiều, các thông tin này được gọi là thuộc tính (attribute) của dimension. Còn khi được lưu trữ cụ thể trong một cơ sở dữ liệu quan hệ, các thông tin này chính là các columns của table.
Một nguyên tắc thiết kế của data warehouse là cố gắng đưa càng nhiều thông tin vào dimension thì càng tốt. Nói cách khác, ta tìm cách "làm phẳng" hay "phi chuẩn hoá 3NF" đối với một dimension table. Lấy Product dimension làm ví dụ. Ở source database, giả sử ta có 3 tables được thiết kế theo đúng tiêu chí của 3NF là Product, SubCategory, Category. Do cả 3 tables này đều cùng miêu tả một đối tượng là Product nên khi chuyển sang dimensional model, ta chỉ cần một Product dimension bao gồm luôn thông tin từ cả 3 tables nói trên.
Với cách làm như vậy, dễ hiểu khi ta thấy có những dimension table có từ 50 đến 100 columns. Số lượng bản ghi trong một dimension table thường không nhiều. Trong ví dụ nói trên, Product dimension sẽ có cùng số lượng bản ghi như của Product table trong source database. Mỗi dimension table cũng có một primary key (PK) để xác định đính duy nhất của một bản ghi. Primary Key này sẽ được join với Foreign Key tương ứng nằm trên Fact table, và do đó kết nối Dimension và Fact với nhau.
Dimension table đóng một vai trò sống còn trong data warehouse. Do chúng chứa các thông tin miêu tả nghiệp vụ, nên đây là nguồn được dùng để sàng lọc dữ liệu, gộp nhóm, và tạo các nhãn trình bày. Trong ví dụ ở trên, nếu người dùng muốn xem tổng số tiền bán hàng theo tuần và loại hàng hóa, hiển nhiên fact table chỉ có thể cung cấp số liệu về số tiền thu được. Thông tin về loại hàng hóa chỉ có thể lấy được từ Product dimension, trong khi thông tin về thời gian cũng chỉ có thể tìm được trong Date dimension. Nói cách khác, người dùng tương tác với data warehouse chủ yếu là qua dimension table, còn fact table chỉ cung cấp các số liệu. Tuỳ theo cách nhìn của người dùng đối với nghiệp vụ, họ sẽ dùng các attributes của dimension hoặc là để sàng lọc dữ liệu, hoặc là để tạo ra các kết quả tổng hợp theo nhóm....vv
Các attributes của dimension table thường chứa dữ liệu dạng text và có tính rời rạc. Một attribute có thể chứa một miêu tả ngắn (10 - 15 ký tự) hoặc dài (30-50 ký tự), tên hàng, tên loại hàng, kiểu đóng gói, kích cỡ... vv. Mặc dù kích cỡ là một giá trị dạng số và dường như thích hợp cho fact table, nhưng về bản chất mà nói, nó mang tính miêu tả cho một hàng hóa cụ thể chứ không mang nhiều giá trị đo lường.
Các attributes trong một dimesion thường tạo thành các cây phân cấp (hierarchy). Trong Product dimension đã nói ở trên, Product là cấp thấp nhất (leaf level). Ngay phía trên là SubCategory, và trên cùng là Category. Một cách rất tự nhiên, người dùng có thể dễ dàng xem được tổng doanh thu của một Category rồi đi sâu xuống (drill down) xem sự phân bố của doanh thu theo các SubCategory trong cùng Category đó. Mức thấp nhất sẽ là doanh thu của từng Product trong một SubCategory. Quá trình ngược lại được gọi là drill up. Drill up/down là những thao tác thông dụng nhất của các ứng dụng data warehouse. Sở dĩ các thao tác này trở nên dễ dàng và nhanh chóng là do các thông tin về SubCategory và Category đã được đưa vào Product dimesion, hay nói cách khác, ta đã "làm phẳng" dimension này. Giả sử ta đua SubCategory và Category vào các dimesion tương ứng rồi liên kết chúng với Product dimension qua các foreign keys thích hợp. Cách làm không hề sai và thiết kế theo kiểu này được gọi là mô hình "bông tuyết" (snow flake) bởi hình dạng mà chúng tạo ra giống hệt một bông tuyết. Tuy nhiên, truy cập vào SubCategory và Category bây giờ phải được thực hiện trên 3 dimensions thay vì 1 như trước đây. Không kể đến việc người dùng sẽ phải làm nhiều thao tác hơn, tốc độ truy cập chắc chắn sẽ giảm đi đáng kể.
Có thể nói, trong thiết kế dimension table, ta hy sinh chuẩn 3NF để đổi lấy sự đơn giản và tốc độ. Đây có thể coi là một nguyên tắc vàng của dimensional modeling.
4. Star schema:
Với những kiến thức về fact table, fact grain, dimension table đã đề cập ở trên, khái niệm cuối cùng trong dimensional modeling, và cũng được cấu thành từ 3 khái niệm trên, là star schema. Khi ta liên kết fact table và dimension table lại với nhau dựa trên các Primary Key của dimension và Foreign Key tương ứng của fact, ta được một mô hình dữ liệu dạng hình sao - star schema.
Date Dimension
Date Key (PK)
Date attributes...
Store Dimension
Store Key (PK)
Store attributes...
Daily Sales Facts
Date Key (FK)
Product Key (FK)
Store Key (FK)
Facts...
Product Dimension
Product Key (PK)
Product attributes..
Không quá khó để thấy rằng star schema có thiết kế tương đối đơn giản và mang tính đối xứng. Nếu xét từ góc độ thuần túy nghiệp vụ, thiết kế này gần nhất với cái nhìn của người dung cuối về nghiệp vụ của họ. Trong nhiều trường hợp, đây chính là bức tranh chính xác của nghiệp vụ mà người dùng làm việc trong đó.
Thực ra nếu ta suy nghĩ sâu hơn một chút về quá trình xây dựng một cơ sở dữ liệu quan hệ cho một ứng dụng rồi xây dựng data warehouse cho ứng dụng đó, nó gần như tạo thành một vòng tuần hoàn. Những ai đã từng thiết kế cơ sở dữ liệu quan hệ - relational database - đều biết rằng một trong những bước đầu tiên là phải xác định được mô hình quan hệ - thực thể (Entity – Relationship). Sau khi các thực thể và các mối quan hệ giữa chúng đã được xác định, ta mới tiến hành xây dựng các table và column và rồi áp dụng chuẩn 3NF. Trong quá trình này, các thực thể có thể được phân nhỏ ra để tạo nên các table mới với các quan hệ 1-N. Các mối quan hệ đa chiều N-N trong mô hình E-R sẽ được thể hiện bằng một bảng trung gian với các quan hệ 1-N tương ứng. Bằng cách này, một mô hình E-R với một lượng nhỏ thực thể ban đầu có thể phát triển thành một cơ sỡ dữ liệu lớn với hàng trăm bảng được kết nối với nhau qua các mối quan hệ 1-N hoặc 1-1. Khối lượng thông tin như vậy rõ ràng là không hề dễ hiểu với người dùng cuối, vốn là những đối tượng hầu như không có chút khái niệm nào về database.
Khi xây dựng một data warehouse theo dạng star schema, một cách tự nhiên ta đã biến một cơ sở dữ liệu phức tạp quay trở lại một dạng mô hình E-R gần như ban đầu. Dĩ nhiên trong thực tế, một star schema thường tập trung vào một góc nhỏ của relational database. Do đó, từ một cơ sở dữ liệu ban đầu có thể xây dựng nhiều star schema, và mỗi star schema tập trung vào một khía cạnh cụ thể của nghiệp vụ. Trong ví dụ trên, Product là một thực thể. Khi được đưa vào cơ sở dữ liệu quan hệ, nó được chuẩn hóa theo 3NF và tách ra thành 3 bảng Product, SubCategory, Category. Khi đưa vào data warehouse, Product lại quay về hình dạng của thực thể Product ban đầu.
Một kinh nghiệm mà người viết bài này nhận thấy khi sử dụng nguyên tắc thiết kế dimensional modeling cho data warehouse hoặc cube là hãy cứ tạm thời quên đi các bảng biểu phức tạp trong database. Thay vào đó, hãy xác định các thực thể nghiệp vụ trước rồi đặt chúng trong những mối quan hệ với nhau. Về cơ bản đây chính là những gì mà người dùng muốn data warehouse làm được khi bỏ tiền ra để xây dựng một ứng dụng như vậy.
Do nó đơn giản, nên star schema là mô hình thiết kế đề cao tốc độ. Với số lượng ít hơn hẳn các table và relationship, việc truy cập dữ liệu trong table và thực hiện các phép toán join đạt tốc độ nhanh hơn rõ rệt.
Copy from fotech.org
Tác giả: Huy Nguyen
Các thành phần của Data Warehouse
Một hệ thống data warehouse về mặt lô gích được cho là có 4 thành phần
1. Nguồn dữ liệu (Operational Source Systems).
2. Khu vực xử lý (Staging Area).
3. Khu vực trình bày (Data Presentation Area).
4. Công cụ truy cập dữ liệu (Data Access Tools).
Các thành phần trên tương tác với nhau như sau:
- Data từ Nguồn dữ liệu được nạp vào Khu vực xử lý.
- Data đã qua xử lý được nạp từ Khu vực xử lý vào Khu vực trình bày.
- Công cụ truy cập dữ liệu do người dùng cuối thao tác sẽ làm việc trên dữ liệu trong Khu vực trình bày.
I. Nguồn dữ liệu:
Nói một cách đơn giản, đây là nơi mà data xuất phát và thường là cơ sở dữ liệu của một ứng dụng nào đó. Và khách quan mà nói, nguồn dữ liệu là một thành phần nằm ngoài data warehouse. Như đã trình bày trong phần trước, dữ liệu của một hệ thống data warehouse thường đến từ nhiều nguồn khác nhau. Ví dụ: trong cùng một tổ chức, có phòng ban nhập dữ liệu vào Access database, trong khi phòng ban khác lại dùng bảng biểu Excel. Thậm chí có nơi dữ liệu được xuất ra từ những mainframe server 50, 60 tuổi theo dạng csv file. Do tính chất đa dạng của nguồn dữ liệu, nên các phương pháp chuyển tải dữ liệu từ nhiều nguồn về cùng một chỗ khá phong phú. Tùy theo quy định riêng của từng tổ chức, bạn có thể được phép truy cập trực tiếp dữ liệu nguồn. Nhưng cũng có nơi dữ liệu chỉ được truy cập qua Email, FTP, File Sharing... Thậm chí bạn có thể phải tạo ra các modules riêng để truy cập Web Services để lấy dữ liệu về. Nói như vậy để thấy, làm data warehouse không chỉ đơn thuần là database mà đòi hỏi developer phải có kiến thức rộng và tổng hợp cũng như những kỹ năng lập trình ứng dụng khác.
Xác định được dữ liệu đến từ những nguồn nào là một phần quan trọng trong việc xây dựng kiến trúc cho hệ thống data warehouse (data warehouse architecture) và là một trong những bước đầu tiên của ETL process.
1. Nguồn dữ liệu (Operational Source Systems).
2. Khu vực xử lý (Staging Area).
3. Khu vực trình bày (Data Presentation Area).
4. Công cụ truy cập dữ liệu (Data Access Tools).
Các thành phần trên tương tác với nhau như sau:
- Data từ Nguồn dữ liệu được nạp vào Khu vực xử lý.
- Data đã qua xử lý được nạp từ Khu vực xử lý vào Khu vực trình bày.
- Công cụ truy cập dữ liệu do người dùng cuối thao tác sẽ làm việc trên dữ liệu trong Khu vực trình bày.
I. Nguồn dữ liệu:
Nói một cách đơn giản, đây là nơi mà data xuất phát và thường là cơ sở dữ liệu của một ứng dụng nào đó. Và khách quan mà nói, nguồn dữ liệu là một thành phần nằm ngoài data warehouse. Như đã trình bày trong phần trước, dữ liệu của một hệ thống data warehouse thường đến từ nhiều nguồn khác nhau. Ví dụ: trong cùng một tổ chức, có phòng ban nhập dữ liệu vào Access database, trong khi phòng ban khác lại dùng bảng biểu Excel. Thậm chí có nơi dữ liệu được xuất ra từ những mainframe server 50, 60 tuổi theo dạng csv file. Do tính chất đa dạng của nguồn dữ liệu, nên các phương pháp chuyển tải dữ liệu từ nhiều nguồn về cùng một chỗ khá phong phú. Tùy theo quy định riêng của từng tổ chức, bạn có thể được phép truy cập trực tiếp dữ liệu nguồn. Nhưng cũng có nơi dữ liệu chỉ được truy cập qua Email, FTP, File Sharing... Thậm chí bạn có thể phải tạo ra các modules riêng để truy cập Web Services để lấy dữ liệu về. Nói như vậy để thấy, làm data warehouse không chỉ đơn thuần là database mà đòi hỏi developer phải có kiến thức rộng và tổng hợp cũng như những kỹ năng lập trình ứng dụng khác.
Xác định được dữ liệu đến từ những nguồn nào là một phần quan trọng trong việc xây dựng kiến trúc cho hệ thống data warehouse (data warehouse architecture) và là một trong những bước đầu tiên của ETL process.
II. Khu vực xử lý (Data Staging Area):
Có thể hiểu đây là nơi các hoạt động xử lý data diễn ra. Khu vực xử lý vừa là một nơi lưu trữ dữ liệu vừa nơi diễn ra các quá trình chuyển đổi dữ liệu trước khi chúng được đưa sang Khu vực trình bày.
Lý do cho sự tồn tại của thành phần này trong một hệ thống data warehouse là bởi vì quá trình ETL khá phức tạp. Dữ liệu phải được làm sạch (cleanse), chuyển đổi (convert), chuẩn hóa (conform). Những công đoạn này nhìn chung đòi hỏi phải xây dựng các temp tables để chứa dữ liệu đang được xử lý và các control tables để chứa metadata về quá trình ETL.
Staging Area cũng là nơi mà dữ liệu nguồn được lưu trữ như một dạng backup storage. Do quá trình ETL hoàn toàn có khả năng gặp trục trặc giữa chừng trong khi đang nạp dữ liệu từ Khu vực xử lý sang Khu vực trình bày, nên dữ liệu nguồn cần phải được lưu trữ để lúc nào cũng có thể được sử dụng lại. Có người sẽ hỏi tạo sao không yêu cầu các nguồn dữ liệu cung cấp lại dữ liệu một lần nữa ? Việc này trên thực tế nhiều lúc hoàn toàn không khả thi.
Một ví dụ đơn giản như sau: Quá trình ETL chạy vào buổi tối sử dụng dữ liệu của ngày hôm đó. Vì một lý do nào đó, nó buộc phải dừng lại giữa chừng. Ngày hôm sau, ETL phải chạy lại trong chế độ recovery. Ngoài việc phải dọn dẹp sạch sẽ những gì đã được lưu trữ dở dang trong presentation area, ETL đòi hỏi phải có dữ liệu nguồn để bắt đầu lại từ đầu. Lúc này, do đã sang ngày mới nên dữ liệu trong các cơ sở dữ liệu nguồn hoàn toàn có khả năng đã bị thay đổi và mất đi giá trị nguyên thủy của ngày hôm qua. Nếu vẫn tiếp tục, ETL sẽ sử dụng các dữ liệu không đúng, và do vậy phá vỡ tính đúng đắn của cả hệ thống. Nếu như dữ liệu nguồn đã được lưu trữ trong staging area từ tối hôm trước, mọi việc trở nên đơn giản hơn nhiều mà vẫn đảm bảo được tính vẹn toàn của data warehouse.
Các công cụ ETL hiện đại trên thị trường hiện nay có khả năng xử lý tương đối tốt một lượng lớn những yêu cầu về cleansing & converting, lookup, aggregation.... Nhiều lúc nó khiến người dùng cảm thấy có thể nạp dữ liệu trực tiếp từ nguồn vào data warehouse database, bỏ qua staging area. Nhưng như đã trình bày ở trên, cách làm này tuy có thể tiết kiệm được thời gian và không gian nhưng không hề ổn định. Những người làm data warehouse lâu năm có một nguyên tắc vàng: "Luôn phải có staging area".
Có thể hiểu đây là nơi các hoạt động xử lý data diễn ra. Khu vực xử lý vừa là một nơi lưu trữ dữ liệu vừa nơi diễn ra các quá trình chuyển đổi dữ liệu trước khi chúng được đưa sang Khu vực trình bày.
Lý do cho sự tồn tại của thành phần này trong một hệ thống data warehouse là bởi vì quá trình ETL khá phức tạp. Dữ liệu phải được làm sạch (cleanse), chuyển đổi (convert), chuẩn hóa (conform). Những công đoạn này nhìn chung đòi hỏi phải xây dựng các temp tables để chứa dữ liệu đang được xử lý và các control tables để chứa metadata về quá trình ETL.
Staging Area cũng là nơi mà dữ liệu nguồn được lưu trữ như một dạng backup storage. Do quá trình ETL hoàn toàn có khả năng gặp trục trặc giữa chừng trong khi đang nạp dữ liệu từ Khu vực xử lý sang Khu vực trình bày, nên dữ liệu nguồn cần phải được lưu trữ để lúc nào cũng có thể được sử dụng lại. Có người sẽ hỏi tạo sao không yêu cầu các nguồn dữ liệu cung cấp lại dữ liệu một lần nữa ? Việc này trên thực tế nhiều lúc hoàn toàn không khả thi.
Một ví dụ đơn giản như sau: Quá trình ETL chạy vào buổi tối sử dụng dữ liệu của ngày hôm đó. Vì một lý do nào đó, nó buộc phải dừng lại giữa chừng. Ngày hôm sau, ETL phải chạy lại trong chế độ recovery. Ngoài việc phải dọn dẹp sạch sẽ những gì đã được lưu trữ dở dang trong presentation area, ETL đòi hỏi phải có dữ liệu nguồn để bắt đầu lại từ đầu. Lúc này, do đã sang ngày mới nên dữ liệu trong các cơ sở dữ liệu nguồn hoàn toàn có khả năng đã bị thay đổi và mất đi giá trị nguyên thủy của ngày hôm qua. Nếu vẫn tiếp tục, ETL sẽ sử dụng các dữ liệu không đúng, và do vậy phá vỡ tính đúng đắn của cả hệ thống. Nếu như dữ liệu nguồn đã được lưu trữ trong staging area từ tối hôm trước, mọi việc trở nên đơn giản hơn nhiều mà vẫn đảm bảo được tính vẹn toàn của data warehouse.
Các công cụ ETL hiện đại trên thị trường hiện nay có khả năng xử lý tương đối tốt một lượng lớn những yêu cầu về cleansing & converting, lookup, aggregation.... Nhiều lúc nó khiến người dùng cảm thấy có thể nạp dữ liệu trực tiếp từ nguồn vào data warehouse database, bỏ qua staging area. Nhưng như đã trình bày ở trên, cách làm này tuy có thể tiết kiệm được thời gian và không gian nhưng không hề ổn định. Những người làm data warehouse lâu năm có một nguyên tắc vàng: "Luôn phải có staging area".
Mục tiêu của data-warehouse
Một Data Warehouse phải đảm bảo được các mục tiêu sau:
Truy cập dễ dàng:
Thông tin lưu trữ trong data warrehouse phải trực quan và dễ hiểu đối với người dùng. Nói cách khác, dữ liệu nên được trình bày thông qua các tên gọi quen thuộc và gần gũi với nghiệp vụ của người dùng.
Qua một số dự án đã làm tôi thấy có thể phân chia businiess user ra 2 loại. Người dùng cấp thấp chủ yếu thao tác trên các thông tin chi tiết. Chẳng hạn như nhập số liệu về một khách hàng, theo dõi các giao dịch của khách hàng cụ thể đó... Report cho dạng công việc kiểu này thường là thông tin chi tiết về một khách hàng, hoặc một danh sách các khách hàng. Những report kiểu này có thể lấy ra trực tiếp từ operational database.
Người dùng cấp cao lại chủ yếu xử lý dữ liệu ở mức độ tổng hợp, để từ đó phân tích rồi đưa ra các quyết định mang tính định hướng cho nghiệp vụ. Họ không quan tâm đến một khách hàng cụ thể nào cũng như không cần phải để ý cả một danh sách 1000 khách hàng. Thay vào đó, cái làm họ bận tâm là số lượng khách hàng sử dụng dịch tăng/giảm 25% trong quý IV so với quý III cùng năm và tăng/giảm 45% so với cùng quý IV năm ngoái. Từ các thông số này, họ mới đưa ra quyết định sẽ làm gì để cải thiện tình hình hoặc đặt ra mục tiêu tăng trưởng 30% cho quý IV năm tới. Đây là đối tượng chủ yếu của Data Warehouse.
Do vậy, thông tin cho loại đối tượng này càng dễ hiểu và gần với thực tế càng tốt. Một ví dụ dễ thấy là thay vì sử dụng các code, data warehouse nên thể hiện thông tin bằng các description hoặc name.
Một điều nữa cần bàn đến là tốc độ truy cập data warehouse phải nhanh. Do phải xử lý một số lượng lớn bản ghi cùng một lúc, performance là một trong những yêu cầu phải có của một dw. Đây là nơi mà các kỹ thuật tuning database được dịp phát huy hết công suất: query tuning, query hints, indexes, parallel processing, partition, materialized views....
Riêng bản thân tôi nghĩ, đối với những người xây dựng dw, đây là mảnh đất tốt để nâng cao khả năng làm việc với database lên mức expert. Mặc dù không chính thức bắt buộc, nhưng phần lớn những người làm dw tốt đều có kiến thức rất sâu về database. Nhiều người thậm chí còn ở mức DB Administrator. Với nhu cầu về dữ liệu càng lúc càng lớn như hiện nay, sở hữu nhiều kỹ năng tốt cùng một lúc có thể đem lại cho bạn nhiều lựa chọn và lợi thế hơn trong thị trường việc làm.
Thông tin nhất quán:
Dữ liệu trong một data warehouse nhìn chung thường đến từ nhiều nguồn khác nhau. Do vậy, cùng một thông tin nhưng các nguồn khác nhau có thể trình bày nó theo các kiểu khác nhau, thậm chí còn sai lệch ít nhiều. Một ví dụ đơn giản là cùng khách hàng tên Huy Nguyen, database A lưu trữ thông tin này trong 2 trường First_Name và Last_Name, trong khi database B có thể chỉ có một trường duy nhất Ho_va_Ten. Một cái tên công ty như International Business Trading trong database A được thể hiện đầy đủ như trên, nhưng trong database B có khi lại được trình bày dưới dạng viết tắt như Intl. Biz Trading.
Một đặc điểm nữa của dữ liệu database là không có database nào chứa dữ liệu sạch 100%. Cho dù có là dữ liệu của một công ty hàng đầu về IT như Google, Amazon, Microsoft... đảm bảo vẫn có lỗi. Database càng to càng dễ có dữ liệu không sạch. Một ví dụ dễ thấy là một trường Description có thể chứa các ký tự điều khiển CR LF. Điều này xảy ra khi người dùng nhấn Enter nhiều lần để tạo ra các đoạn văn bản trong cùng một ô area box. Nhiều lúc dữ liệu sai xuất hiện trong database là do lỗi lập trình. Tôi đã gặp một trường hợp như sau. Một trường datetime trong Oracle database có giá trị hẳn hoi (not null) nhưng không sao convert được sang kiểu varchar2. Tìm hiểu một hồi mới thấy trong một số bản ghi, giá trị thực của trường đó là... vô định, tức là dữ liệu thì có nhưng nó không mang một giá trị cụ thể nào. Lý do có lẽ là một Java developer nào đó khi tạo lập một Date instance .... quên mất không assign một giá trị nào cho đối tượng đó. Do vậy, đối tượng thì có nhưng giá trị thực trong nó thì vô định. Về mặt kỹ thuật mà nói, điều này vẫn hợp lệ nên vẫn được chèn vào database. Chỉ khi nào convert dữ liệu thì lỗi này mới xuất hiện, nếu không nó sẽ "nằm im" trong suốt cả vòng đời của ứng dụng mà không ai biết.
Nói vậy để thấy, trước khi được đưa vào data warehouse, dữ liệu cần phải được làm sạch và đảm bảo về chất lượng. Có làm sạch rồi thì việc đồng nhất dữ liệu mới trở nên dễ dàng. Một nguyên tắc đơn giản được đặt ra cho quá trình này là:
- Nếu dữ liệu có cùng tên, chúng bắt buộc phải cùng chỉ đến một thực thể.
- Ngược lại, nếu dữ liệu chỉ đến các thực thể khác nhau, chúng phải được đặt tên khác nhau.
Đây chính là những công việc chủ đạo của quá trình ETL (Extract - Transform - Load).
Thích nghi với thay đổi:
Thay đổi là điều không thể tránh khỏi cho bất cứ ứng dụng nào, không riêng gì data warehouse. Do vậy, data warehouse cần phải được thiết kế để xử lý những thay đổi có thể xảy ra. Nói vậy có nghĩa là khi có thay đổi mới, dữ liệu cũ trong data vẫn phải được bảo tồn tính đúng đắn.
Bảo mật:
Dữ liệu trong data warehouse đến từ nhiều nguồn khác nhau, do vậy hiển nhiên việc bảo đảm những thông tin không lộ ra ngoài là một yêu cần thiết yếu. Để lộ dữ liệu của một database đã là cực kỳ nghiêm trọng. Để lộ dữ liệu từ nhiều database là thảm họa.
Hỗ trợ ra quyết định:
Đây có thể nói là mục tiêu quan trọng nhất của doanh nghiệp khi xây dựng data warehouse. Mặc dù có những trường hợp xây dựng một cơ sở dữ liệu tập trung để thu thập data từ nhiều nguồn khác nhau, nhưng tôi cho rằng những trường hợp như vậy nên gọi là data integration (tích hợp dữ liệu) chứ không phải data warehouse. Một doanh nghiệp trước khi xây dựng data warehouse, nên tự đặt câu hỏi liệu data warehouse đó có giúp ích gì trong việc ra quyết định kinh doanh của doanh nghiệp không.
Lý thuyết về các hệ hỗ trợ quyết định (Decision Support System) thì có lẽ đủ để viết mấy quyển sách dày hàng trăm trang. Tôi còn nhớ hồi đi học ở khoa Công nghệ đã từng được học một môn như vây, nhưng chỉ dừng ở mức lý thuyết. Đến khi đi làm về data warehouse, mới dần dần nắm bắt được thế nào là một DSS. Nói một cách nôm na trong phạm vi của data warehouse, người ta muốn dựa vào thông tin để từ đó thấy được cần phải làm những gì để kinh doanh đạt kết quả tốt nhất.
Công cụ gần nhất và dễ dùng nhất là dựa trên các báo cáo (report) và phân tích. Kinh nghiệm của tôi cho thấy người dùng thường tạo ra các trend report để thể hiện xu hướng hoạt động thay đổi như thế nào theo thời gian. Đây là một chỉ số quan trọng và thông dụng trong nhiều tổ chức. Các KPI (Key Performance Indicators) có lẽ được xây dựng dựa trên thực tế này. Một kiểu report nữa hay gặp là dashboard, trong đó thực ra là chứa rất nhiều reports liên quan với nhau được thể hiện dưới dạng các biểu đồ (chart). Lợi thế của dashboard là nó rất trực quan, nhìn vào đó người ta có thể ngay lập tức hình dung được tình hình hoạt động của công ty.
Với data warehouse, người dùng có thể dễ dàng xây dựng các report như trên. Đồng thời, từ data warehouse, người ta có thể xây dựng các cube mà không tốn quá nhiều công sức. Dựa trên cube, các công cụ phân tích sẽ được dùng để phân tích dữ liệu cực kỳ nhanh chóng và trực quan.
Thành công:
Hiển nhiên sản phẩm được tạo ra cũng phải hướng đến thành công. Trong trường hợp của data warehouse, nó phải đem lại giá trị thực tế cho người dùng như đã nói ở trên và phải được dùng liên tục thì mới được coi là thành công. Việc có hay không có Data Warehouse trong một tổ chức hoàn toàn không mang tính bắt buộc. Không có data warehouse, người ta vẫn có thể tạo ra report nhưng dĩ nhiên mất nhiều công sức hơn. Để được công nhận, giá trị business mà data warehoue đem lại phải lớn hơn công sức và tiền của bỏ ra đầu tư vào nó.
Trong nhiều tổ chức, business user ban đầu thường không hề có chút ý niệm về data warehouse hoặc thậm chí hoài nghi về nó. Nhưng một khi người dùng đã quen với nó, người ta sẽ thích nó và muốn ngày càng có nhiều dữ liệu hơn trong data warehouse đơn giản bởi vì nó cung cấp rất nhiều lựa chọn và hỗ trợ ra quyết định khá tốt. Đó gọi là thành công.
copy from fotech.org
Tác giả: Huy Nguyen
Truy cập dễ dàng:
Thông tin lưu trữ trong data warrehouse phải trực quan và dễ hiểu đối với người dùng. Nói cách khác, dữ liệu nên được trình bày thông qua các tên gọi quen thuộc và gần gũi với nghiệp vụ của người dùng.
Qua một số dự án đã làm tôi thấy có thể phân chia businiess user ra 2 loại. Người dùng cấp thấp chủ yếu thao tác trên các thông tin chi tiết. Chẳng hạn như nhập số liệu về một khách hàng, theo dõi các giao dịch của khách hàng cụ thể đó... Report cho dạng công việc kiểu này thường là thông tin chi tiết về một khách hàng, hoặc một danh sách các khách hàng. Những report kiểu này có thể lấy ra trực tiếp từ operational database.
Người dùng cấp cao lại chủ yếu xử lý dữ liệu ở mức độ tổng hợp, để từ đó phân tích rồi đưa ra các quyết định mang tính định hướng cho nghiệp vụ. Họ không quan tâm đến một khách hàng cụ thể nào cũng như không cần phải để ý cả một danh sách 1000 khách hàng. Thay vào đó, cái làm họ bận tâm là số lượng khách hàng sử dụng dịch tăng/giảm 25% trong quý IV so với quý III cùng năm và tăng/giảm 45% so với cùng quý IV năm ngoái. Từ các thông số này, họ mới đưa ra quyết định sẽ làm gì để cải thiện tình hình hoặc đặt ra mục tiêu tăng trưởng 30% cho quý IV năm tới. Đây là đối tượng chủ yếu của Data Warehouse.
Do vậy, thông tin cho loại đối tượng này càng dễ hiểu và gần với thực tế càng tốt. Một ví dụ dễ thấy là thay vì sử dụng các code, data warehouse nên thể hiện thông tin bằng các description hoặc name.
Một điều nữa cần bàn đến là tốc độ truy cập data warehouse phải nhanh. Do phải xử lý một số lượng lớn bản ghi cùng một lúc, performance là một trong những yêu cầu phải có của một dw. Đây là nơi mà các kỹ thuật tuning database được dịp phát huy hết công suất: query tuning, query hints, indexes, parallel processing, partition, materialized views....
Riêng bản thân tôi nghĩ, đối với những người xây dựng dw, đây là mảnh đất tốt để nâng cao khả năng làm việc với database lên mức expert. Mặc dù không chính thức bắt buộc, nhưng phần lớn những người làm dw tốt đều có kiến thức rất sâu về database. Nhiều người thậm chí còn ở mức DB Administrator. Với nhu cầu về dữ liệu càng lúc càng lớn như hiện nay, sở hữu nhiều kỹ năng tốt cùng một lúc có thể đem lại cho bạn nhiều lựa chọn và lợi thế hơn trong thị trường việc làm.
Thông tin nhất quán:
Dữ liệu trong một data warehouse nhìn chung thường đến từ nhiều nguồn khác nhau. Do vậy, cùng một thông tin nhưng các nguồn khác nhau có thể trình bày nó theo các kiểu khác nhau, thậm chí còn sai lệch ít nhiều. Một ví dụ đơn giản là cùng khách hàng tên Huy Nguyen, database A lưu trữ thông tin này trong 2 trường First_Name và Last_Name, trong khi database B có thể chỉ có một trường duy nhất Ho_va_Ten. Một cái tên công ty như International Business Trading trong database A được thể hiện đầy đủ như trên, nhưng trong database B có khi lại được trình bày dưới dạng viết tắt như Intl. Biz Trading.
Một đặc điểm nữa của dữ liệu database là không có database nào chứa dữ liệu sạch 100%. Cho dù có là dữ liệu của một công ty hàng đầu về IT như Google, Amazon, Microsoft... đảm bảo vẫn có lỗi. Database càng to càng dễ có dữ liệu không sạch. Một ví dụ dễ thấy là một trường Description có thể chứa các ký tự điều khiển CR LF. Điều này xảy ra khi người dùng nhấn Enter nhiều lần để tạo ra các đoạn văn bản trong cùng một ô area box. Nhiều lúc dữ liệu sai xuất hiện trong database là do lỗi lập trình. Tôi đã gặp một trường hợp như sau. Một trường datetime trong Oracle database có giá trị hẳn hoi (not null) nhưng không sao convert được sang kiểu varchar2. Tìm hiểu một hồi mới thấy trong một số bản ghi, giá trị thực của trường đó là... vô định, tức là dữ liệu thì có nhưng nó không mang một giá trị cụ thể nào. Lý do có lẽ là một Java developer nào đó khi tạo lập một Date instance .... quên mất không assign một giá trị nào cho đối tượng đó. Do vậy, đối tượng thì có nhưng giá trị thực trong nó thì vô định. Về mặt kỹ thuật mà nói, điều này vẫn hợp lệ nên vẫn được chèn vào database. Chỉ khi nào convert dữ liệu thì lỗi này mới xuất hiện, nếu không nó sẽ "nằm im" trong suốt cả vòng đời của ứng dụng mà không ai biết.
Nói vậy để thấy, trước khi được đưa vào data warehouse, dữ liệu cần phải được làm sạch và đảm bảo về chất lượng. Có làm sạch rồi thì việc đồng nhất dữ liệu mới trở nên dễ dàng. Một nguyên tắc đơn giản được đặt ra cho quá trình này là:
- Nếu dữ liệu có cùng tên, chúng bắt buộc phải cùng chỉ đến một thực thể.
- Ngược lại, nếu dữ liệu chỉ đến các thực thể khác nhau, chúng phải được đặt tên khác nhau.
Đây chính là những công việc chủ đạo của quá trình ETL (Extract - Transform - Load).
Thích nghi với thay đổi:
Thay đổi là điều không thể tránh khỏi cho bất cứ ứng dụng nào, không riêng gì data warehouse. Do vậy, data warehouse cần phải được thiết kế để xử lý những thay đổi có thể xảy ra. Nói vậy có nghĩa là khi có thay đổi mới, dữ liệu cũ trong data vẫn phải được bảo tồn tính đúng đắn.
Bảo mật:
Dữ liệu trong data warehouse đến từ nhiều nguồn khác nhau, do vậy hiển nhiên việc bảo đảm những thông tin không lộ ra ngoài là một yêu cần thiết yếu. Để lộ dữ liệu của một database đã là cực kỳ nghiêm trọng. Để lộ dữ liệu từ nhiều database là thảm họa.
Hỗ trợ ra quyết định:
Đây có thể nói là mục tiêu quan trọng nhất của doanh nghiệp khi xây dựng data warehouse. Mặc dù có những trường hợp xây dựng một cơ sở dữ liệu tập trung để thu thập data từ nhiều nguồn khác nhau, nhưng tôi cho rằng những trường hợp như vậy nên gọi là data integration (tích hợp dữ liệu) chứ không phải data warehouse. Một doanh nghiệp trước khi xây dựng data warehouse, nên tự đặt câu hỏi liệu data warehouse đó có giúp ích gì trong việc ra quyết định kinh doanh của doanh nghiệp không.
Lý thuyết về các hệ hỗ trợ quyết định (Decision Support System) thì có lẽ đủ để viết mấy quyển sách dày hàng trăm trang. Tôi còn nhớ hồi đi học ở khoa Công nghệ đã từng được học một môn như vây, nhưng chỉ dừng ở mức lý thuyết. Đến khi đi làm về data warehouse, mới dần dần nắm bắt được thế nào là một DSS. Nói một cách nôm na trong phạm vi của data warehouse, người ta muốn dựa vào thông tin để từ đó thấy được cần phải làm những gì để kinh doanh đạt kết quả tốt nhất.
Công cụ gần nhất và dễ dùng nhất là dựa trên các báo cáo (report) và phân tích. Kinh nghiệm của tôi cho thấy người dùng thường tạo ra các trend report để thể hiện xu hướng hoạt động thay đổi như thế nào theo thời gian. Đây là một chỉ số quan trọng và thông dụng trong nhiều tổ chức. Các KPI (Key Performance Indicators) có lẽ được xây dựng dựa trên thực tế này. Một kiểu report nữa hay gặp là dashboard, trong đó thực ra là chứa rất nhiều reports liên quan với nhau được thể hiện dưới dạng các biểu đồ (chart). Lợi thế của dashboard là nó rất trực quan, nhìn vào đó người ta có thể ngay lập tức hình dung được tình hình hoạt động của công ty.
Với data warehouse, người dùng có thể dễ dàng xây dựng các report như trên. Đồng thời, từ data warehouse, người ta có thể xây dựng các cube mà không tốn quá nhiều công sức. Dựa trên cube, các công cụ phân tích sẽ được dùng để phân tích dữ liệu cực kỳ nhanh chóng và trực quan.
Thành công:
Hiển nhiên sản phẩm được tạo ra cũng phải hướng đến thành công. Trong trường hợp của data warehouse, nó phải đem lại giá trị thực tế cho người dùng như đã nói ở trên và phải được dùng liên tục thì mới được coi là thành công. Việc có hay không có Data Warehouse trong một tổ chức hoàn toàn không mang tính bắt buộc. Không có data warehouse, người ta vẫn có thể tạo ra report nhưng dĩ nhiên mất nhiều công sức hơn. Để được công nhận, giá trị business mà data warehoue đem lại phải lớn hơn công sức và tiền của bỏ ra đầu tư vào nó.
Trong nhiều tổ chức, business user ban đầu thường không hề có chút ý niệm về data warehouse hoặc thậm chí hoài nghi về nó. Nhưng một khi người dùng đã quen với nó, người ta sẽ thích nó và muốn ngày càng có nhiều dữ liệu hơn trong data warehouse đơn giản bởi vì nó cung cấp rất nhiều lựa chọn và hỗ trợ ra quyết định khá tốt. Đó gọi là thành công.
copy from fotech.org
Tác giả: Huy Nguyen
Khái niệm về data warehouse
Data Warehouse là gì ?
Một định nghĩa chính thức của data warehouse trong wikipedia chẳng hạn cũng mất cả một trang để giải thích. Bản thân tôi nếu được hỏi, có lẽ câu trả lời sẽ là: data warehouse là một cơ sở dữ liệu được tập hợp từ nhiều nguồn của một tổ chức và chủ yếu được dùng cho việc báo cáo (reporting) và phân tích (analysis). Cách tốt nhất để hiểu khái niệm này theo tôi là nên trực tiếp xây dựng một data warehouse database.
Trước hết, có lẽ những ai học xong 4 năm IT trong trường đều biết một cơ sở dữ liệu là như thế nào. Một ứng dụng (application) thường có một database để chứa các thông tin hoạt động của ứng dụng đó. Một tổ chức (organization, company...etc) có thể có nhiều ứng dụng, do vậy nhiều database khác nhau. Mỗi ứng dụng thường tập trung vào một lĩnh vực hoạt động hay kinh doanh (domain) cụ thể nào đó. Lấy ví dụ một ngân hàng thường sẽ có một ứng dụng banking để quản lý các tài khoản và giao dịch cá nhân như checking account (debit card), saving account, credit card... Đồng thời, ngân hàng cũng có một ứng dụng khác chuyên quản lý về các khoản vay, chẳng hạn vay tiền để mua nhà hoặc để đi học. Như vậy trong trường hợp này, ít nhất có 2 operational database cùng tồn tại trong một ngân hàng.
Operational database thứ nhất chuyên về các giao dịch cá nhân (banking transaction) hàng ngày. Cuối tháng công ty của bạn trả lương bằng cách nạp (deposit) một khoản tiền vào tài khoản. Còn bạn thì hăm hở đi ra ATM ở Vincom để rút tiền (credit) vào tối thứ sáu trước khi đưa bạn gái đi ăn tối ở tầng 15 khách sạn Melia và xem phim Mùa hè 500 ngày ở rạp Tháng Tám. Do đó, có ít nhất 2 transaction records đã được chèn vào database.
Tương tự, khi bạn cần vay ngân hàng tiền để mua một căn hộ mới ở khu Mỹ Đình để chung sống cùng cô vợ mới cưới (với điều kiện dinner + movie worked pretty well), thông tin về bạn sẽ được nạp vào một operational database chuyên về các khoản vay. Mỗi tháng ngân hàng yêu cầu bạn đóng một khoản tiền để trả nợ bao gồm cả lãi suất trong đó. Một transaction record sẽ được đưa vào database chuyên về cho vay này hàng tháng.
Như vậy có thể thấy 2 cơ sở dữ liệu ở trên được dùng với mục đích duy trì hoạt động hàng ngày của ngân hàng. Do vậy, được gọi là Operational Database.
Một ngày đẹp trời, ngân hàng của bạn quyết định đưa ra một chiến lược kinh doanh mới để thúc đẩy các hoạt động trong mảng cho vay bởi đây là thị trường rất tiềm năng. Để làm được điều này, ngân hàng cần biết đối tượng nào có nhu cầu mua nhà nhất, thường mua nhà loại nào, giá nhà nằm trong khoảng nào, khả năng chi trả ra sao. Một cách để biết được điều này là ngân hàng có thể so sánh số liệu của 2 năm 2008 và 2009 nhằm vào đối tượng là tầng lớp trung lưu văn phòng tuổi 25-30, thu nhập hàng tháng $500-$700, nhà mua là loại căn hộ 2 phòng ngủ, địa điểm là quanh khu đô thị mới Phạm Hùng. Nếu số liệu của năm 2009 cao hơn 2008, có thể dự đoán là nhu cầu của nhóm này tăng lên, do vậy ngân hàng có thể phát động các gói khuyến mãi dành riêng cho lớp này. Chẳng hạn, khoản vay có thể lớn hơn, lãi suất ưu đãi hơn, ngân hàng sẽ chịu trách nhiệm trong việc làm sổ đỏ...vv.
Để thực hiện điều này, rõ ràng ngân hàng của bạn sẽ phải thu gom dữ liệu từ 2 cơ sở dữ liệu trên hoặc mua dữ liệu từ một cơ quan chuyên về địa ốc nào đó. Do tên của bạn có thể sẽ xuất hiện trong các operational database khác nhau, người ta sẽ phải tìm cách để đồng nhất các thông tin này rồi dựa trên đó áp dụng các công thức tính toán thích hợp để dẫn đến cái báo cáo như ở trên.
Do đây là một quá trình không hề đơn giản, nhiều khả năng ngân hàng sẽ phải dùng một câu lệnh SQL cực kỳ phức tạp và dài ngoằng. Gặp trường hợp dữ liệu đến từ nhiều nguồn khác nhau (csv, xml...), thậm chí có thể sẽ phải xây dựng các temp tables ngay trong operational database để thực hiện các bước trung gian. Một cách khác có thể là lập trình riêng một module cho báo cáo này. Tất cả những cách tiếp cận nói trên đều không mang tính hệ thống và thậm chí ảnh hưởng đến operational database.
Từ những lý do này, một cơ sở dữ liệu riêng cần phải được thành lập để có thể tập hợp thông tin từ nhiều nguồn khác nhau, chuẩn hóa nó, tối ưu tốc độ để phục vụ cho việc phân tích và lập báo cáo. Nói cách khác, đó là một data warehouse.
Nhận xét của cá nhân:
Data warehouse nên được xây dựng từ trên yêu cầu của business. Thường thì các yêu cầu này liên quan đến việc sử dụng các số liệu tổng hợp, chẳng hạn count, sum, max, min, average... Thường thì người ta sử dụng các số liệu kiểu này để phân tích xu hướng (trend).
Nếu không được định hướng bởi business, hoặc đơn giản chỉ bởi vì ai đó muốn xây dựng data warehouse... theo phong trào, một data warehouse như vậy nhiều khi không khác gì một bản copy của operational database với khác biệt duy nhất là nó chạy trên một máy tính mà thôi. Hiển nhiên là như vậy là lãng phí tiền bạc và công sức, trừ khi người ta thực sự muốn như thế.
Một data warehouse thường làm việc với hàng trăm, hàng nghìn, hàng triệu record một lúc. Trong khi đó, một operational database thường làm việc với 1 record.
copy from fotech.org
Tác giả: Huy Nguyen
Một định nghĩa chính thức của data warehouse trong wikipedia chẳng hạn cũng mất cả một trang để giải thích. Bản thân tôi nếu được hỏi, có lẽ câu trả lời sẽ là: data warehouse là một cơ sở dữ liệu được tập hợp từ nhiều nguồn của một tổ chức và chủ yếu được dùng cho việc báo cáo (reporting) và phân tích (analysis). Cách tốt nhất để hiểu khái niệm này theo tôi là nên trực tiếp xây dựng một data warehouse database.
Trước hết, có lẽ những ai học xong 4 năm IT trong trường đều biết một cơ sở dữ liệu là như thế nào. Một ứng dụng (application) thường có một database để chứa các thông tin hoạt động của ứng dụng đó. Một tổ chức (organization, company...etc) có thể có nhiều ứng dụng, do vậy nhiều database khác nhau. Mỗi ứng dụng thường tập trung vào một lĩnh vực hoạt động hay kinh doanh (domain) cụ thể nào đó. Lấy ví dụ một ngân hàng thường sẽ có một ứng dụng banking để quản lý các tài khoản và giao dịch cá nhân như checking account (debit card), saving account, credit card... Đồng thời, ngân hàng cũng có một ứng dụng khác chuyên quản lý về các khoản vay, chẳng hạn vay tiền để mua nhà hoặc để đi học. Như vậy trong trường hợp này, ít nhất có 2 operational database cùng tồn tại trong một ngân hàng.
Operational database thứ nhất chuyên về các giao dịch cá nhân (banking transaction) hàng ngày. Cuối tháng công ty của bạn trả lương bằng cách nạp (deposit) một khoản tiền vào tài khoản. Còn bạn thì hăm hở đi ra ATM ở Vincom để rút tiền (credit) vào tối thứ sáu trước khi đưa bạn gái đi ăn tối ở tầng 15 khách sạn Melia và xem phim Mùa hè 500 ngày ở rạp Tháng Tám. Do đó, có ít nhất 2 transaction records đã được chèn vào database.
Tương tự, khi bạn cần vay ngân hàng tiền để mua một căn hộ mới ở khu Mỹ Đình để chung sống cùng cô vợ mới cưới (với điều kiện dinner + movie worked pretty well), thông tin về bạn sẽ được nạp vào một operational database chuyên về các khoản vay. Mỗi tháng ngân hàng yêu cầu bạn đóng một khoản tiền để trả nợ bao gồm cả lãi suất trong đó. Một transaction record sẽ được đưa vào database chuyên về cho vay này hàng tháng.
Như vậy có thể thấy 2 cơ sở dữ liệu ở trên được dùng với mục đích duy trì hoạt động hàng ngày của ngân hàng. Do vậy, được gọi là Operational Database.
Một ngày đẹp trời, ngân hàng của bạn quyết định đưa ra một chiến lược kinh doanh mới để thúc đẩy các hoạt động trong mảng cho vay bởi đây là thị trường rất tiềm năng. Để làm được điều này, ngân hàng cần biết đối tượng nào có nhu cầu mua nhà nhất, thường mua nhà loại nào, giá nhà nằm trong khoảng nào, khả năng chi trả ra sao. Một cách để biết được điều này là ngân hàng có thể so sánh số liệu của 2 năm 2008 và 2009 nhằm vào đối tượng là tầng lớp trung lưu văn phòng tuổi 25-30, thu nhập hàng tháng $500-$700, nhà mua là loại căn hộ 2 phòng ngủ, địa điểm là quanh khu đô thị mới Phạm Hùng. Nếu số liệu của năm 2009 cao hơn 2008, có thể dự đoán là nhu cầu của nhóm này tăng lên, do vậy ngân hàng có thể phát động các gói khuyến mãi dành riêng cho lớp này. Chẳng hạn, khoản vay có thể lớn hơn, lãi suất ưu đãi hơn, ngân hàng sẽ chịu trách nhiệm trong việc làm sổ đỏ...vv.
Để thực hiện điều này, rõ ràng ngân hàng của bạn sẽ phải thu gom dữ liệu từ 2 cơ sở dữ liệu trên hoặc mua dữ liệu từ một cơ quan chuyên về địa ốc nào đó. Do tên của bạn có thể sẽ xuất hiện trong các operational database khác nhau, người ta sẽ phải tìm cách để đồng nhất các thông tin này rồi dựa trên đó áp dụng các công thức tính toán thích hợp để dẫn đến cái báo cáo như ở trên.
Do đây là một quá trình không hề đơn giản, nhiều khả năng ngân hàng sẽ phải dùng một câu lệnh SQL cực kỳ phức tạp và dài ngoằng. Gặp trường hợp dữ liệu đến từ nhiều nguồn khác nhau (csv, xml...), thậm chí có thể sẽ phải xây dựng các temp tables ngay trong operational database để thực hiện các bước trung gian. Một cách khác có thể là lập trình riêng một module cho báo cáo này. Tất cả những cách tiếp cận nói trên đều không mang tính hệ thống và thậm chí ảnh hưởng đến operational database.
Từ những lý do này, một cơ sở dữ liệu riêng cần phải được thành lập để có thể tập hợp thông tin từ nhiều nguồn khác nhau, chuẩn hóa nó, tối ưu tốc độ để phục vụ cho việc phân tích và lập báo cáo. Nói cách khác, đó là một data warehouse.
Nhận xét của cá nhân:
Data warehouse nên được xây dựng từ trên yêu cầu của business. Thường thì các yêu cầu này liên quan đến việc sử dụng các số liệu tổng hợp, chẳng hạn count, sum, max, min, average... Thường thì người ta sử dụng các số liệu kiểu này để phân tích xu hướng (trend).
Nếu không được định hướng bởi business, hoặc đơn giản chỉ bởi vì ai đó muốn xây dựng data warehouse... theo phong trào, một data warehouse như vậy nhiều khi không khác gì một bản copy của operational database với khác biệt duy nhất là nó chạy trên một máy tính mà thôi. Hiển nhiên là như vậy là lãng phí tiền bạc và công sức, trừ khi người ta thực sự muốn như thế.
Một data warehouse thường làm việc với hàng trăm, hàng nghìn, hàng triệu record một lúc. Trong khi đó, một operational database thường làm việc với 1 record.
copy from fotech.org
Tác giả: Huy Nguyen
dw - cube
1. Khái niệm
Cube có thể coi là một dạng cơ sở dữ liệu đa chiều và thường để chứa thông tin tổng hợp (summary, count, max, min....). Khái niệm của cube khá gần với data warehouse, chủ yếu cũng loanh quanh về dimensions và measures (fact).
Về mặt lưu trữ vật lý, người ta lưu trữ cube trong các file thông thường được tổ chức theo một cấu trúc nhất định nào đó. Cách này là nhanh nhất để truy cập dữ liệu của cube nhưng đồng thời cũng rất tốn dung lượng. Một cách nữa để lưu trữ dữ liệu của cube là dùng relational database. Cách này tiết kiệm được dung lượng nhưng truy cập sẽ chậm hơn.
Về mặt lý thuyết mà nói, người ta hoàn toàn có thể xây dựng các file chứa dữ liệu dạng cube với dữ liệu được lấy trực tiếp từ các source databases (relational, flat file, xml, maineframe...). Trong thực tế, mình thấy người ta thường xây dựng một data warehouse trước rồi từ đó mới xây dựng cube. Cách này có vẻ dễ hơn, đỡ phải tính toán nhiều bởi vì các tool đã làm cho hết rồi.
Mỗi lần có dữ liệu mới, người ta phải build lại cube. Tùy theo tần suất update mà cube được build theo giờ, ngày, tuần, tháng, năm... Data Warehouse database cũng được update theo kiểu này.
2. Update cube
Tần suất update cube càng gần với real time thì càng ảnh hưởng nhiều đến downtime của cube và dung lượng. Tất cả các yếu tố này phải được đánh giá dựa trên nhu cầu của người dùng và sẽ phải có thỏa hiệp.
Một kỹ thuật mình có nghe người ta nói là khi có dữ liệu mới, một cube mới được built trong khi cube cũ vẫn được dùng song song trong lúc đó. Sau khi cube mới đã built xong, switch từ cube cũ qua cube mới. Như vậy cube không bao giờ bị down. Thỏa hiệp ở đây là dữ liệu trong cube sẽ hơi chậm một chút so với real time bù lại người dùng có thể luôn truy cập cube mà không phải chờ hàng tiếng đồng hồ.
3. Partition
Cách partition thông dụng nhất là theo thời gian bởi vì thường thì người ta có xu hướng truy cập các thông tin gần nhất. Ví dụ bạn partition cube theo năm (hoặc tháng) và thường thì dữ liệu của năm 2009 sẽ được truy cập nhiều nhất. Khi đó, chỉ có partition của 2009 được truy cập và do đó sẽ tăng tốc độ đọc cube lên rất nhiều. Điều này cũng giúp ích cho update cube bởi vì cũng chỉ các dữ liệu của 2009 là hay được cập nhật nhất. Khi đó, chỉ việc update riêng partition của 2009 nơi mà thay đổi thực sự diễn ra, các partition khác đâu có thay đổi nên vẫn có giữ nguyên.
4. Công cụ
Một công cụ để tiếp cận cube dễ dàng là SSAS. SSAS rất tốt và dễ sử dụng. Sách vở về nó cũng nhiều.
copy có chọn lọc từ diễn đàn fotech.org
Tác giả: Huy Nguyen
Cube có thể coi là một dạng cơ sở dữ liệu đa chiều và thường để chứa thông tin tổng hợp (summary, count, max, min....). Khái niệm của cube khá gần với data warehouse, chủ yếu cũng loanh quanh về dimensions và measures (fact).
Về mặt lưu trữ vật lý, người ta lưu trữ cube trong các file thông thường được tổ chức theo một cấu trúc nhất định nào đó. Cách này là nhanh nhất để truy cập dữ liệu của cube nhưng đồng thời cũng rất tốn dung lượng. Một cách nữa để lưu trữ dữ liệu của cube là dùng relational database. Cách này tiết kiệm được dung lượng nhưng truy cập sẽ chậm hơn.
Về mặt lý thuyết mà nói, người ta hoàn toàn có thể xây dựng các file chứa dữ liệu dạng cube với dữ liệu được lấy trực tiếp từ các source databases (relational, flat file, xml, maineframe...). Trong thực tế, mình thấy người ta thường xây dựng một data warehouse trước rồi từ đó mới xây dựng cube. Cách này có vẻ dễ hơn, đỡ phải tính toán nhiều bởi vì các tool đã làm cho hết rồi.
Mỗi lần có dữ liệu mới, người ta phải build lại cube. Tùy theo tần suất update mà cube được build theo giờ, ngày, tuần, tháng, năm... Data Warehouse database cũng được update theo kiểu này.
2. Update cube
Tần suất update cube càng gần với real time thì càng ảnh hưởng nhiều đến downtime của cube và dung lượng. Tất cả các yếu tố này phải được đánh giá dựa trên nhu cầu của người dùng và sẽ phải có thỏa hiệp.
Một kỹ thuật mình có nghe người ta nói là khi có dữ liệu mới, một cube mới được built trong khi cube cũ vẫn được dùng song song trong lúc đó. Sau khi cube mới đã built xong, switch từ cube cũ qua cube mới. Như vậy cube không bao giờ bị down. Thỏa hiệp ở đây là dữ liệu trong cube sẽ hơi chậm một chút so với real time bù lại người dùng có thể luôn truy cập cube mà không phải chờ hàng tiếng đồng hồ.
3. Partition
Cách partition thông dụng nhất là theo thời gian bởi vì thường thì người ta có xu hướng truy cập các thông tin gần nhất. Ví dụ bạn partition cube theo năm (hoặc tháng) và thường thì dữ liệu của năm 2009 sẽ được truy cập nhiều nhất. Khi đó, chỉ có partition của 2009 được truy cập và do đó sẽ tăng tốc độ đọc cube lên rất nhiều. Điều này cũng giúp ích cho update cube bởi vì cũng chỉ các dữ liệu của 2009 là hay được cập nhật nhất. Khi đó, chỉ việc update riêng partition của 2009 nơi mà thay đổi thực sự diễn ra, các partition khác đâu có thay đổi nên vẫn có giữ nguyên.
4. Công cụ
Một công cụ để tiếp cận cube dễ dàng là SSAS. SSAS rất tốt và dễ sử dụng. Sách vở về nó cũng nhiều.
copy có chọn lọc từ diễn đàn fotech.org
Tác giả: Huy Nguyen
Lưu trữ dữ liệu trong data warehouse
Giả sử bạn đã có một DW database được thiết kế theo nguyên tắc hình sao (star schema). Cơ sở dữ liệu này (target) được cập nhật định kỳ hàng ngày từ các cơ sở dữ liệu nguồn (source). Giả sử bạn có một dimesion Person như sau:
DW_ID Business_ID First_Name Last_Name
1001 10001 Hoang Le
1002 10002 Lan Nguyen
Nguyên tắc cập nhật thường thấy của một DW là chỉ những record đã thay đổi từ source database mới được đưa sang target database, tức là DW database. Một record được coi là "thay đổi" khi thỏa mãn 1 trong 3 điều kiện sau:
1. Record hoàn toàn mới (insert).
2. Một số columns thay đổi giá trị (update).
3. Record bị xóa (delete).
Hai trường hợp hay gặp nhất là insert và update. Việc xử lý deleted record thường khó hơn hoặc thậm chí đôi khi không thể làm được hoặc là người ta đơn giản bỏ qua. Giả sử sau một ngày làm việc, source database có những records sau:
Business_ID First_Name Last_Name
10001 Hoang Tran
10002 Lan Nguyen
10003 Vinh Ly
Như vậy, bản ghi 10001 có Last_Name đã thay đổi. Do đó nó sẽ được ETL process đưa sang target database. Bản ghi 10002 vẫn giữ nguyên giá trị do đó nó sẽ không được đưa sang data warehouse. Bản ghi 10003 thì mới keng, chắc chắn sẽ được đưa sang data warehouse.
Okay, bây giờ mới đến phần thú vị. Bản ghi 10003 do mới tinh nên có thể dễ dàng chèn nó vào dw như sau:
DW_ID Business_ID First_Name Last_Name
1001 10001 Hoang Le
1002 10002 Lan Nguyen
1003 10003 Vinh Ly
Vấn đề nằm ở bản ghi có Business_ID 10001. Có một số cách xử lý như sau:
1. Viết đè giá trị của bản ghi hiện thời trong dw. Tức là:
DW_ID Business_ID First_Name Last_Name
1001 10001 Hoang Tran
1002 10002 Lan Nguyen
1003 10003 Vinh Ly
Làm như Last_Name cũ biến mất hoàn toàn cả trong source database và dw. Người ta gọi là Slowly Changing Dimensions Type 1.
2. Tạo một record mới với giá trị mới.
DW_ID Business_ID First_Name Last_Name Record_Active
1001 10001 Hoang Le N
1002 10002 Lan Nguyen Y
1003 10003 Vinh Ly Y
1004 10001 Hoang Tran Y
Như vậy, một record mới với giá trị mới của cùng Business_ID 10001 được chèn vào dw. Record cũ được đánh dấu là non-active. Column mới Record_active được gọi là metadata column bởi vì nó không chứa bất cứ giá trị nào liên quan đến business. Nó được tạo ra với mục đích để miêu tả cấu trúc của dữ liệu. Thay vì một column như vậy, ta có thể tạo ra 2 column Active_start_date, Active_end_date để miêu tả rõ hơn nữa trong khoảng thời gian nào thì record được coi là active. Người ta gọi là Slowly Changing Dimensions Type 2.
3. Tạo một column để lưu giữ giá trị cũ.
DW_ID Business_ID First_Name Last_Name Prior_Last_Name
1001 10001 Hoang Tran Le
1002 10002 Lan Nguyen
1003 10003 Vinh Ly
Người ta gọi là Slowly Changing Dimensions Type 3.
Có thể thấy rằng cách làm thứ 2 và 3 lưu giữ được dữ liệu cũ. Do vậy mà người ta nói dw chứa dữ liệu có tính lịch sử. Điều này nhiều lúc rất quan trọng nếu như người ta muốn biết tại một thời điểm nào đó, dữ liệu "đã" chứa giá trị nào. Hiển nhiên là source database không thể làm được điều này bởi vì cùng một bản ghi đó, nhưng giá trị ban đầu của một số trường đã bị mất đi viễn vĩnh. Trong khi đó, dw lại có chứa những thông tin này. Thậm chí có khi bản ghi đã bị xóa đi trong source database, nhưng vẫn được giữ lại trong dw.
Với cách xây dựng như trên có thể thấy dữ liệu không bao giờ mất đi trong dw. Nói cách khác, dữ liệu chỉ có một đường đi vào. Đặc biệt nếu dùng Type 2, 3 thì dữ liệu không bao giờ thay đổi. Một đặc điểm nữa của dw là dữ liệu thường đến từ nhiều nguồn, nhưng một khi đã vào data warehouse nó bắt buộc phải được "chuẩn hóa" (conformed).
copy from: fotech.org tác giả Huy Nguyen
DW_ID Business_ID First_Name Last_Name
1001 10001 Hoang Le
1002 10002 Lan Nguyen
Nguyên tắc cập nhật thường thấy của một DW là chỉ những record đã thay đổi từ source database mới được đưa sang target database, tức là DW database. Một record được coi là "thay đổi" khi thỏa mãn 1 trong 3 điều kiện sau:
1. Record hoàn toàn mới (insert).
2. Một số columns thay đổi giá trị (update).
3. Record bị xóa (delete).
Hai trường hợp hay gặp nhất là insert và update. Việc xử lý deleted record thường khó hơn hoặc thậm chí đôi khi không thể làm được hoặc là người ta đơn giản bỏ qua. Giả sử sau một ngày làm việc, source database có những records sau:
Business_ID First_Name Last_Name
10001 Hoang Tran
10002 Lan Nguyen
10003 Vinh Ly
Như vậy, bản ghi 10001 có Last_Name đã thay đổi. Do đó nó sẽ được ETL process đưa sang target database. Bản ghi 10002 vẫn giữ nguyên giá trị do đó nó sẽ không được đưa sang data warehouse. Bản ghi 10003 thì mới keng, chắc chắn sẽ được đưa sang data warehouse.
Okay, bây giờ mới đến phần thú vị. Bản ghi 10003 do mới tinh nên có thể dễ dàng chèn nó vào dw như sau:
DW_ID Business_ID First_Name Last_Name
1001 10001 Hoang Le
1002 10002 Lan Nguyen
1003 10003 Vinh Ly
Vấn đề nằm ở bản ghi có Business_ID 10001. Có một số cách xử lý như sau:
1. Viết đè giá trị của bản ghi hiện thời trong dw. Tức là:
DW_ID Business_ID First_Name Last_Name
1001 10001 Hoang Tran
1002 10002 Lan Nguyen
1003 10003 Vinh Ly
Làm như Last_Name cũ biến mất hoàn toàn cả trong source database và dw. Người ta gọi là Slowly Changing Dimensions Type 1.
2. Tạo một record mới với giá trị mới.
DW_ID Business_ID First_Name Last_Name Record_Active
1001 10001 Hoang Le N
1002 10002 Lan Nguyen Y
1003 10003 Vinh Ly Y
1004 10001 Hoang Tran Y
Như vậy, một record mới với giá trị mới của cùng Business_ID 10001 được chèn vào dw. Record cũ được đánh dấu là non-active. Column mới Record_active được gọi là metadata column bởi vì nó không chứa bất cứ giá trị nào liên quan đến business. Nó được tạo ra với mục đích để miêu tả cấu trúc của dữ liệu. Thay vì một column như vậy, ta có thể tạo ra 2 column Active_start_date, Active_end_date để miêu tả rõ hơn nữa trong khoảng thời gian nào thì record được coi là active. Người ta gọi là Slowly Changing Dimensions Type 2.
3. Tạo một column để lưu giữ giá trị cũ.
DW_ID Business_ID First_Name Last_Name Prior_Last_Name
1001 10001 Hoang Tran Le
1002 10002 Lan Nguyen
1003 10003 Vinh Ly
Người ta gọi là Slowly Changing Dimensions Type 3.
Có thể thấy rằng cách làm thứ 2 và 3 lưu giữ được dữ liệu cũ. Do vậy mà người ta nói dw chứa dữ liệu có tính lịch sử. Điều này nhiều lúc rất quan trọng nếu như người ta muốn biết tại một thời điểm nào đó, dữ liệu "đã" chứa giá trị nào. Hiển nhiên là source database không thể làm được điều này bởi vì cùng một bản ghi đó, nhưng giá trị ban đầu của một số trường đã bị mất đi viễn vĩnh. Trong khi đó, dw lại có chứa những thông tin này. Thậm chí có khi bản ghi đã bị xóa đi trong source database, nhưng vẫn được giữ lại trong dw.
Với cách xây dựng như trên có thể thấy dữ liệu không bao giờ mất đi trong dw. Nói cách khác, dữ liệu chỉ có một đường đi vào. Đặc biệt nếu dùng Type 2, 3 thì dữ liệu không bao giờ thay đổi. Một đặc điểm nữa của dw là dữ liệu thường đến từ nhiều nguồn, nhưng một khi đã vào data warehouse nó bắt buộc phải được "chuẩn hóa" (conformed).
copy from: fotech.org tác giả Huy Nguyen
Thứ Sáu, 8 tháng 10, 2010
Sống.
Mỗi người chì có một cuộc đời, dù chỉ là 1 hài nhi còn chưa thấy mặt trời hay những ông bà đã sống qua tuổi trăm.
Nếu mỗi sáng thức dậy, bạn thấy mình còn thở, còn thấy ánh ban mai lấp lánh bên khung cửa, thấy bạn đang hòa vào dòng người tấp nập hối hả ngoài kia, ấy vẫn còn là niềm hạnh phúc. Bởi vì, bạn đang được sống.
Bạn chỉ có một cuộc đời thôi, buồn hay vui là do bạn lựa chọn, dù bạn cứ nhấn chìm mình mãi trong những chuỗi ngày của cô đơn, hờn ghen, đau khổ... thời gian vẫn cứ trôi qua. Sao bạn không chọn những tiếng cười, chọn những hạnh phúc nhỏ nhoi, chọn những niềm vui sống cho trọn một ngày..
Sinh ra, ai cũng sẽ được ban tặng một tờ giấy trắng và một hộp màu, trang nhật ký đời người của bạn sẽ rực rỡ hay rặt màu xám, ấy là do chính tay bạn tô nên.
Hạnh phúc nằm trong tay những người biết nắm giữ. Niềm vui nằm trong tiếng cười của những người biết cho phép bản thân mình vui tươi..
Nếu mỗi sáng thức dậy, bạn thấy mình còn thở, còn thấy ánh ban mai lấp lánh bên khung cửa, thấy bạn đang hòa vào dòng người tấp nập hối hả ngoài kia, ấy vẫn còn là niềm hạnh phúc. Bởi vì, bạn đang được sống.
Bạn chỉ có một cuộc đời thôi, buồn hay vui là do bạn lựa chọn, dù bạn cứ nhấn chìm mình mãi trong những chuỗi ngày của cô đơn, hờn ghen, đau khổ... thời gian vẫn cứ trôi qua. Sao bạn không chọn những tiếng cười, chọn những hạnh phúc nhỏ nhoi, chọn những niềm vui sống cho trọn một ngày..
Sinh ra, ai cũng sẽ được ban tặng một tờ giấy trắng và một hộp màu, trang nhật ký đời người của bạn sẽ rực rỡ hay rặt màu xám, ấy là do chính tay bạn tô nên.
Hạnh phúc nằm trong tay những người biết nắm giữ. Niềm vui nằm trong tiếng cười của những người biết cho phép bản thân mình vui tươi..
Thứ Năm, 7 tháng 10, 2010
Làm việc
Làm việc là vì trách nhiệm với công việc được giao, không phải vì nghĩa vụ.
Làm việc là vì muốn khẳng định bản thân, không phải vì chưa hết giờ làm.
Làm việc là vì muốn trau dồi kiến thức, không phải để copy chỗ này rồi paste sang chỗ kia.
Làm việc, nghĩa là tập trung, không facebook, không chat chit nữa. Haizz.
Phải biết quản lý tốt thời gian của mình chứ. zzZZ
Rất giàu lòng quyết tâm, nhưng chưa đủ kiên nhẫn.
Rất giàu ý tưởng, nhưng vẫn rất ham vui.
Mỗi ngày nhích một tý, rùi sẽ tới được đích ;)
Làm việc là vì muốn khẳng định bản thân, không phải vì chưa hết giờ làm.
Làm việc là vì muốn trau dồi kiến thức, không phải để copy chỗ này rồi paste sang chỗ kia.
Làm việc, nghĩa là tập trung, không facebook, không chat chit nữa. Haizz.
Phải biết quản lý tốt thời gian của mình chứ. zzZZ
Rất giàu lòng quyết tâm, nhưng chưa đủ kiên nhẫn.
Rất giàu ý tưởng, nhưng vẫn rất ham vui.
Mỗi ngày nhích một tý, rùi sẽ tới được đích ;)
Ở bãi gửi xe
1 cô gái trẻ, xe lx, áo hoa, quần sooc, tóc vàng: "Cho gửi cái xe".
Chú bảo vệ, khoảng 40->50 tuổi: Đi chỗ khác mà gửi.
Nga đang loay hoay lấy xe gần đấy.
Chú bảo vệ: Con người phải biết tôn trọng nhau chứ cháu nhỉ?
Nga: Hoan hô chú :D
Chú bảo vệ, khoảng 40->50 tuổi: Đi chỗ khác mà gửi.
Nga đang loay hoay lấy xe gần đấy.
Chú bảo vệ: Con người phải biết tôn trọng nhau chứ cháu nhỉ?
Nga: Hoan hô chú :D
Thứ Ba, 5 tháng 10, 2010
Nguyên tắc của coder
Dù đã từng bị bắt lỗi, bị phạt tiền, mình vẫn thường xuyên dính lỗi này ;(. Giờ mới thấy rằng nhìn coding convention ngon, đẹp, rõ ràng, comment đầy đủ Anh ra Anh, Việt ra Việt thật là đã mắt 
)
vài điều thấy cần nhớ:
- Luôn có comment về người tạo, package, thời gian update, version trên đầu mỗi trang.
- Các hàm, class, comment… khi viết cần thống nhất dùng một thứ ngôn ngữ, Anh, Việt, hay Nhật. Cá nhân mình ủng hộ việc viết toàn bộ bằng tiếng Anh, tại như thế sẽ ít gặp lỗi về font, người upgrade sau này không phải lo không hiểu “thằng cha trước” nó viết gì )
- Bản trên svn, dù cho là server test cũng không nên để lại các lỗi về cú pháp, không tìm thấy file hay còn nguyên các hàm debug, test xử lý logic bên trong.
- Không nên tiết kiệm các dấu xuống dòng, các comment, nhìn một page toàn code là code dính sát sàn sạt nhau thấy vô cùng hãi hùng :-S
- Hãy luôn luôn suy nghĩ đến cụm từ “tối ưu”, dù là một dòng lệnh, một đoạn code hay khi thiết kế cơ sở dữ liệu. Mình chứng kiến rất nhiều người đi lo tối ưu đâu đâu trong khi code thì nham nhở, truy vấn cơ sở dữ liệu thì cái gì cũng SELECT *, thiết kế csdl thì loằng ngoằng phức tạp.
- Không bao giờ tác động thẳng vào core code, sau này làm sao update được.
- Chỉ cần một cái tặc lưỡi, bạn sẽ đổ xuống sông công sức coding convention bạn làm bấy lâu. Chỉ cần một cái à uôm bỏ qua, phần mềm (trang web) của bạn sẽ bị giảm chất lượng đi vài phần. Vì thế, dù cho bạn thuộc nằm lòng các qui tắc, hãy nhớ rằng thuộc chưa đủ mà còn phải biết vận dụng nó nữa.
(Chưa đủ, sẽ sưu tập dần dần)
Chữ ký trong thư điện tử
Thế nào là một chữ ký chuẩn, haiz, có lẽ không có định nghĩa, nhưng theo mình một chữ ký có thể chấp nhận được sẽ gồm có:
Câu kết (Thanks and best regards, sincerely…)
Họ và tên
Chức danh
Bộ phận – Công ty
Địa chỉ công ty
Website công ty
skype:
mobile
email.
cũng không khó để nhớ, tuy nhiên để viết chuẩn được thì lại không phải là một điều dễ dàng, nhất là trong trường hợp viết bằng tiếng Anh.
Hôm trước lướt một vòng mail của những người trong hòm mail của mình, mới thấy giật mình vì mỗi người ký một kiểu. Tên công ty thậm chí có người còn viết chưa chuẩn (thực ra trước đó mình cũng ghi sai tên công ty =))), địa chỉ công ty cũng mỗi người ghi mỗi kiểu, rồi có người ghi lẫn cả Anh lẫn Việt, có người đưa quá nhiều thông tin vào chữ ký làm bức mail trở nên dài loằng ngoằng, hoặc có bạn lại ghi chữ THANKS AND BEST REGARDS to đùng, đọc như bị hét vào mặt chứ chẳng phải lời lịch sự gì cho cam. Nhân đây mình cũng phô trương chữ ký của mình, biết đâu ai đó ghé thăm nhận ra lỗi sai thì comment giúp ^^
Thanks and Best regards,
Hồ Thị Nga
—————————————–
Web Developer
SOHA Game Team
Vietnam Communications Corporation
Addr: 23rd floor, Vincom City Towers B, 191 Ba Trieu, Hai Ba Trung, Hanoi
Skype: abcxyz
Mobile: 097….
Xem chừng mình hay để ý những điều rất nhỏ, nhưng mình thấy rằng có một chữ ký đẹp cũng thể hiện được mức độ chuyên nghiệp của người sở hữu mail, và quan trọng là cái gì có thể làm tốt được thì nên cố gắng để làm tốt nó ^^.
Thứ Hai, 1 tháng 3, 2010
I'm return..
So long time I was in invisible, I lost my key, my target.
But from now, I'm return to paint my dream.
It's too difficult, but I will not give up.
Hand my hands...
But from now, I'm return to paint my dream.
It's too difficult, but I will not give up.
Hand my hands...
Đăng ký:
Bài đăng (Atom)