Hello các bạn, chủ đề 7.0. Kiến thức cơ bản về Fact và Dimension trong Data Warehouse đang là chủ đề được rất nhiều người quan tâm. Hôm nay hãy cùng Nói về chủ đề này nhé
Tài liệu đính kèm:
//mega.nz/#F!btFmyYiS!KbeurnAgROGcxRg0DLSB-A
Xin chào bạn ở trong những video lần trước thì có thể là các bạn đã làm quen được với cách sử dụng, Hầu bia rồi, Nhưng mà cái lý thuyết đằng sau, Tại sao chúng ta, Có thể làm những cái như vậy tại sao chúng ta, Giải quyết định, Là, Phải có 3 cái bảng như thế này và bột bả là bạn ở rứa, Hai bảng hai bên và, Tại sao chúng, Lại phải có một cái cấu trúc, Bảng, Thì chúng ta sẽ đến với cả một chút Lý Thu, Lý thuyết này là lý thuyết về đây Towers, Thì đầu ti, Là chúng ta sẽ nói với dimension và fake, Ở đây, Thì ở trong data warehouse thì, Chúng ta sẽ nói đến nhiều là dimension và fake là, Hai cái thành phố, Tất yếu của một cái Town, Và, Để mở các bạn hiểu hơn thì chúng ta sẽ đến với cảm ứng dụng giả sử như là chúng ta, Có đi siêu thị, Ở đây là chúng ta bán văn phòng phẩm trắng, Thì chúng ta sẽ có cái bảng dữ liệu các bạn có thể nhìn thấy ở bên tay phải mình đang chỉ vào đây bảng dữ liệu này thì, Nhiều cột khác nhau và nói chung thì cái dạng dữ liệu ở trong cái bảng này nó có thể chia ra, Thành hai dạng là tôi, Number, Chỉ gồm có là sản phẩm là sản phẩm gì, Được bán ở store nào, Ngày bán ngày nào số lượng là bao nhiêu đơn giá là bao nhiêu unit, Cái, Các doanh thu của sản phẩm đó là bao nhiêu và các transaction ID order ID, Là bao nhiêu, Đây là một cái bảng dữ liệu về các dữ liệu bán hàng của một cái siêu, Thì chúng ta có thể nhận thấy rằng là ở đây nếu mà chúng ta, Chỉ nói tới, Các bạn có thể để ý ở đây là, Twenty tôi chẳng hạn nếu mà quan thi này đứng một mình, Thì chúng nó biết đó là số lẻ, Nhưng mà chúng ta không biết là, Số lượng này, Nó ở trong một cái hoàn cảnh nào nó có ý nghĩa như thế nào, Thì ở đây, Cái con chim này, Thì nó gọi là, Có thể gọi là phê, Thì chúng ta có thể nói rõ hơn về phách như sau, Chúng ta có một cái business process là, Trung tâm bán hàng chúng ta bán văn phòng, Và khách tới mua hàng của chúng ta, Và khi mà chúng ta tính tiền cho khách, Thì là đấy chính là cái businesses có nghĩa là cái tính tiền, Cho khách, Làm một cái report của chúng ta, Và trong thời beepro translate, Hình những cái thông tin nào Đó là sách, Mở những thông tin nào nó là Diamond, Đối với Pháp, Chẳng hạn thì chúng ta có fake nghĩa là gì có nghĩa là phát, Nó sẽ đưa ra là, Số lượng hàng hóa mà khách hàng mua là bao nhiêu, Số tiền khác phải trả là bao nhiêu cái hàng hóa đó chúng ta bán đi thì chúng ta được lại bao nhiêu, Marine như thế nào, Bao nhiêu người vào cửa hàng thì bao nhiêu người mua hàng, Trực tiếp của chúng ta, Thì những cái thư đó Những cái con số đó thì chúng ta gọi là phải, Bài thơ, Đó là những con số cụ thể trên đó không phải là, Cái dữ liệu khác như là ví dụ tên người bán hàng đó là gì, Sản phẩm tên là gì Vân vân, Khi mà chúng ta có những cái con số đó nếu mà những con số này nó đứng một mình, Nó sẽ, Rất là khó hiểu, Chúng ta sẽ không hiểu được những con số này Nó miêu tả cái gì, Thì ở đây, Những cái thứ, Mà miêu tả, Những con số đấy ví dụ như là, Là, Sản phẩm của chúng ta chờ, Hoặc là cái Store là cái nơi mà chúng ta bán sản phẩm đó, Nó đưa cho những cái con số business number của chúng ta, Một cái con dê, Hay là một cái, Môi trường, Hay là một cái hoàn cảnh để mà trong cái hoàn cảnh đó, Chúng ta hiểu được cụ thể là cái con số đó nó nói với điều gì, Thì những cái thông tin đó nó gọi là dimension, Hoặc là những cái thông tin, Metadata, Để mà nó có thể giải thích được, Con số ở trong phòng, Thế nào để chúng ta biết được cái nào là phạm, Thì đơn giản thôi, Để mà biết được là cái nào là phê, Ở trong cái Visa của chúng ta ấy phải hỏi câu, Các câu hỏi của chúng ta, Thường là nó theo dạng, Là như thế này, Là, À cái món hàng, Bút chì trắng, Bán được bao nhiêu, Các món hàng Gucci bán được với giá nào, Em muốn hàng bút chì bán thì lãi bao nhiêu, Cái món hàng bút chì bán được như vậy thì phải, Bỏ ra bao nhiêu chi phí quảng cáo, Các món hàng bút chì bán được như vậy thì phải bỏ ra bao nhiêu chi phí sản xuất, Phải bỏ ra bao nhiêu chi phí này chi phí kia, Và lãi bao nhiêu nhỉ, Hình như cái con số đó, Hoặc là những cái câu hỏi đó thì sẽ giúp chúng ta, Là nhận biết được, Fake, Của chúng ta, Làm như thế nào, Còn với dimagel của chúng ta thì chúng ta lại quay lại cái slide này chúng ta thấy được rằng là, Để mà chúng ta có thể miêu tả được thêm đưa thêm những thông tin cho, Của chúng ta ví dụ như là số lượng bút chì số lượng là cái đó gì gì gì đó Vân Vân chẳng, Thì nếu mà chỉ có mỗi số lượng không thôi Chỉ có mỗi qua đi thì không thôi, Thì chúng, Không thể biết được rằng là con gì đấy nó cho cái gì, Thế nên là cái dimension ví dụ đi lên rừng, Của chúng ta, Thì với clip em trên vùng đất này nó sẽ cho chúng ta biết được rằng là, Ok cây số 50 à, Là 50 cái bay được, 36 này là 36 special, 27 là 27, Chị đó là cái dimension Black của chúng ta, Nó sẽ cho chúng ta biết thông tin về robot, Con, Cái, Dimension Master của chúng ta, Thì cho chúng ta biết được rằng là store đó bán được bao nhiêu, Và kết, Stardock với nhau vậy thì chúng, Cặp thông tin là, Trung tâm bán được bao nhiêu Bút Chì, Mi Store, Nhận định, Và cứ như vậy thì chúng ta cứ thêm thêm thêm những cái dimension khác vào, Chúng ta sẽ trả lời được rất là nhiều những câu hỏi của chúng ta, Ví dụ như là, Cái câu hỏi, Số nào bán được nhiều bút chì nhất chẳng hạn, Thì bạn có muốn trả lời câu hỏi đó không, Nếu bây giờ ví dụ Các bạn thử tưởng tượng xem, Là chúng ta có rất nhiều dữ liệu từ rất nhiều nguồn khác nhau, Rất nhiều sao khác nhau làm sao mà chúng ta có thể phân tích được những cái thông tin đó để đưa ra quyết định cách, Là, Khi mà chúng ta, Đã có được những cái công cụ ở trong tay và chúng ta có lý thuyết để chúng ta có thể biết cách, Để tổ chức kỳ dữ liệu đó, Thì chúng ta sẽ có thể, Đưa ra được những quyết định cho business của chúng ta là chính xác hơn, Ví dụ như làm cái ví dụ điển hình, À mà mọi người hay nhắc đến trước, Đâu đó, Tại sao mà, Chúng ta lại lên đặt bia, Cảnh mới bỉm Trần, Thì đấy là một cái, Thông tin mà qua những cái việc phân tích dữ liệu, Qua, DIY house, Hoặc là thông qua, Những cái công cụ về business intelligence mà người ta đã rút ra cái, Kinh nghiệm rút ra những cái inside hay là, Cái thông tin đó, Bởi vì là, Có thể là các bạn thu thập được rất là nhiều thông tin, Ở đây chúng ta lấy thông tin là nói đến data, Trong tiếng Anh để phân biệt ra khá là hay, Phân biệt ra là Denta và information, Thì nếu mà các bạn ghi nhận được rất nhiều số lẻ, Thì nó chỉ là số liệu mà thôi Nhưng mà từ số liệu đó ra, Bạn có thể đưa ra được những cái Quý, Thì nó mới là information, Nó mới lạ, Những cái thứ, Mà giải, Cho bạn chứ nếu mà cứ bị, Chỉ lưu trữ dữ liệu Thôi thì nó chỉ tốn, Trên ổ cứng, Nước tư dữ liệu đó, Bạn có thể làm được, Làm phân, Các bạn có thể trả lời, Câu hỏi, Bạn cho business, Thì, Dữ liệu đó, Mới có giá trị, Mới mang lại giá trị cho các, Thì mình nghĩ đây là một cái khởi đầu tốt để mà chúng ta có thể bắt đầu, Ở với những cái phần lý thuyết đằng sau nữa, Tạm thời là video này, Sẽ cho các bạn biết được rằng là, Thế nào là Điện Biên chuyển Thế nào là phát, Và, Cho chúng ta một cái ví dụ đầu tiên, Về dimension và và, Vợ chồng chiều hôm nay, Tất nhiên là sau cái phần lý thuyết này, Thì sẽ có, Mỗi phần thực hành Nho Nhỏ, Mà các, Có thể, Thực hành, Biết được rằng là chúng ta sẽ từ một cái bảng dữ liệu như thế này làm sao để mà chúng ta có thể chuyển được, Thành, Một cái starcinema hay là một cái cấu trúc, Dữ liệu, Bảng dữ liệu hình ngôi sao như thế này, Người ta gọi là như thế mà dịch ra tiếng Việt, Star Cinema, Là, Cái thiết kế, Dữ liệu dạng ngôi sao cho nghĩa, Các cái bàn này là ở giữa là bảo phát thầy bùa, Có những cái cánh, Thì là những cái bảng dimension nên họ gọi là, Kiểu dữ liệu ngôi sao, Thì chúng ta sẽ đi tiếp tục ở trong những cái video lần sau Cảm ơn các bạn đã chú ý theo dõi,
Cảm ơn các bạn đã đọc bài viết 7.0. Kiến thức cơ bản về Fact và Dimension trong Data Warehouse. Mong các bạn có thể thư giãn và tìm hiểu kiến thức sau 1 ngày làm việc căng thẳng
Ngày nay, các báo cáo và phân tích quan trọng như là nghiệp vụ chính vậy. Các bản báo cáo có thể được xây dựng lên từ dữ liệu trực tuyến; thường thì kiểu tiếp cận này sẽ hay dùng trong công ty vừa và nhỏ mà không có nhiều dữ liệu. Nhưng khi mọi thứ lớn lên hoặc lượng dữ liệu bắt đầu tăng lên nhanh chóng, đến lúc phải nghĩ đến vấn đề chia tách dữ liệu hệ thống hoạt động [operational systems] và hệ thống báo cáo [reporting system].
Trước khi giải quyết mô hình dữ liệu, chúng ta cần vài hiểu biết nền tảng về hệ thống. Chúng ta cần chia các hệ thống ra thành 2 danh mục: hệ thống hoạt động [operational system] và hệ thống báo cáo [reporting system]. Hệ thống hoạt động thường gọi là OLTP. Các bạn có thể đọc bài Sự khác nhau giữa OLTP và OLAP. Hệ thống báo cáo và phân tích được biết đến là OLAP. OLTP hỗ trợ xử lý giao dịch trong nghiệp vụ kinh doanh. Chúng làm việc với dữ liệu “live” và cần độ chuẩn hoá cao vì nó cần phải tương tác với người dùng tốc độ nhanh. Ngược lại, mục đích chính của OLAP là phân tích. Các hệ thống này sử dụng để tổng hợp dữ liệu, thường được thiết kế theo cấu trúc phi chuẩn cho kho dữ liệu giống sơ đồ ngôi sao. [Phi chuẩn là gì? Đơn giản là giảm dư thừa dữ liệu cho tốc độ nhanh hơn]
Giờ chúng ta đã biết một chút về các hệ thống, hãy bắt đầu nào:
Data Warehouses và Data Marts
Một data warehouse [kho dữ liệu – DWH] là một hệ thống được dùng để lưu trữ thông tin cho việc phân tích và báo cáo. Data Marts là một tập con của data warehouses được dùng để lưu trữ thông tin cần thiết cho một phòng ban hoặc ngay cả một người dùng đơn lẻ. [Tưởng tượng DWH là một toà nhà, data marts là một văn phòng trong toà nhà].
Tại sao lại cần data marts? Tất cả các dữ liệu liên quan được lưu trữ trong công ty DWH. Đối với hầu hết người dùng, họ chỉ cần truy cập vào một tập con dữ liệu cụ thể, giống như bán hàng [sales], sản xuất [production], giao vận [logistic] hoặc marketing. Data marts quan trọng ở cả 2 mặt là bảo mật dữ liệu và tránh nhầm lẫn vì quá nhiều dữ liệu [chúng ta không muốn nhầm lẫn chúng hoặc làm việc với những dữ liệu không liên quan].
Có 2 cách tiếp cận để xây dựng data warehouse và data mart:
- Top-Down: Data mart được tạo từ data warehouse có trước.
- Bottom-Up: Data marts được tạo đầu tiên, sau đó kết hợp chúng lại thành data warehouse.
Quá trình ETL được sử dụng để thêm dữ liệu vào hệ thống OLAP. ETL là viết tắt cảu Extract, Transform và Load. Như tên của nó, chúng ta trích xuất [extract] dữ liệu từ một hoặc nhiều nguồn là các cơ sở dữ liệu hoạt động [OLTP], sau đó chuyển nó [transform] cho phù hợp với cấu trúc của datawarehouse, và load nó vào DWH.
Mô hình chiều dữ liệu [Dimensional modeling] là một phần của thiết kế data warehouse, kết của trong việc tạo mô hình chiều. Có 2 loại bảng tham gia vào:
- Các bảng dimension được sử dụng để mô tả dữ liệu mà chúng ta muốn lưu trữ. Ví dụ: một nhà bán lẻ muốn lưu trữ thời gian, cửa hàng, và nhân viên tham gia vào một hoá đơn. Mỗi một bảng dimension là một danh mục của chính nó [ngày tháng, nhân viên, cửa hàng] và có thể có một hoặc nhiều thuộc tính [attributes]. Với mỗi một cửa hàng, chúng ta lưu chúng các thông tin như vị trí trong thành phố, vùng miền, tỉnh thành và quốc gia. Mỗi một ngày tháng chúng ta lưu năm, tháng, ngày trong tháng, ngày trong tuần…Điều này liên quan đến sự phân cấp của các thuộc tính trong bảng dimension.
Trong sơ đồ ngôi sao, chúng ta sẽ thường tìm một vài thuộc tính là tập con của các thuộc tính khác trong cùng 1 bản ghi. Sự dư thừa này nên rất thận trọng và giúp tăng hiệu năng tốt hơn. Chúng ta có thể dùng ngày tháng, vị trí, và chi nhánh bán hàng để tổng hợp [chính là transform trong ETL] và lưu trữ dữ liệu trong DWH. Trong mô hình dimension, nó rất quan trọng trong việc định nghĩa dimension đúng và phù hợp.
- Bảng Fact chứa dữ liệu mà chúng ta muốn thêm vào reports, tổng hợp trên các giá trị trong các bảng dimension. Một bảng fact chỉ có các cột lưu giá trị và các cột khoá ngoại tham chiếu đến bảng dimensions. Kết hợp tất cả các khoá ngoại và khoá chính trong bảng fact. Ví dụ, một bảng fact có thể lưu trữ một số lượng các hợp đồng và số lượng các nhân viên bán hàng từ các danh sách hợp đồng.
Với các thông tin này chúng ta có thể hiểu và xây dựng được sơ đồ ngôi sao.
Sơ đồ ngôi sao [Star Schema]
Sơ đồ ngôi sao là mô hình đơn giản nhất được sử dụng trong DWH. Bởi vì bảng fact là trung tâm của mô hình với các bảng dimension xung quanh nó, nó nhìn giống như một ngôi sao. Điều này rất rõ ràng khi bảng fact được bao quanh bởi 5 bảng dimension. Một biến thể của sơ đồ ngôi sao là sơ đồ con rết [centipede schema], nơi mà bảng fact được bao quanh bởi số lượng lớn các bảng dimension nhỏ.
Mô hình ngôi sao được sử dụng rộng rãi trong data marts. Chúng ta có thể kết hợp chung trong mô hình top-down. Chúng ta sẽ phân tích mô hình 2 ngôi sao và kết hợp chúng để tạo ra mô hình đơn giản.
Ví dụ sơ đồ ngôi sao [Star schema]: Sales
Báo cáo bán hàng [sales reports] là một trong những báo cáo phổ biết nhất hiện nay. Như chúng ta đã nhắc đến ở trên, hầu hết các trường hợp chúng ta tạo ra báo cáo bán hàng từ hệ thống “live”. Nhưng khi kích thước dữ liệu hoặc nghiệp vụ làm cho chúng trở nên rườm rà, chúng ta sẽ phải xây dựng một data warehouse hoặc một data mart để sắp xếp lại quy trình. Sau khi thiết kế mô hình ngôi sao, một quá trình ETL sẽ lấy dữ liệu từ cơ sở dữ liệu hoạt động [OLTP], chuyển dữ liệu theo định dạng của DWH và bơm vào data warehouse.
Mô hình trình bày ở trên chứa một bảng fact [màu đỏ] và 5 bảng dimension [màu xanh]. Các bảng này là:
- fact_sales –Bảng này chứa tham chiếu đến các bảng dimensions và thêm 2 thông tin chính [giá và số lượng bán]. Chú ý là tất cả 5 khoá ngoại kết hợp với khoá chính của bảng.
- dim_sales_type –Bảng này là loại sales có duy nhất 1 thuộc tính “type_name”.
- dim_employee – Đây là bảng nhân viên, lưu thông tin cơ bản của nhân viên: họ tên và năm sinh.
- dim_product –Bảng này lưu danh sách sản phẩm với 2 thuộc tính [tên và loại sản phẩm].
- dim_time – Bảng này nắm giữ thời gian. Nó bao gồm 5 thuộc tính ngoài khoá chính. Mức thấp nhất là ngày [action_date]. Thuộc tính action_week là số tuần trong năm [Ví dụ tuần đầu trong tháng 1 sẽ là 1; tuần cuối của tháng 12 sẽ là 52, etc.] Thuộc tính actual_month và thuộc tính actual_year lưu trữ tháng và năm bán hàng. Các hông tin này được lấy ra từ thuộc tính action_date. Thuộc tính action_weekday lưu trữ tên của ngày bán hàng.
- dim_store –Mỗi một cửa hàng sẽ lưu thành phố, vùng, tỉnh và quốc gia nơi mà nó đặt. Chúng ta có thể rõ ràng là mô hình ngôi sao được phi chuẩn.
Ví dụ mô hình ngôi sao: Supply Orders
Có nhiều sự tương đồng với mô hình sales ở trên:
Mô hình này tập trung lưu trữ lịch sử của hoá đơn. Chúng ta có một bảng fact và 4 bảng dimension. Các bảng dimension: dim_employee, dim_product và dim_time trích xuất thông tin giống như mô hình sales. Tuy nhiên các bảng dươi đây lại khác:
- fact_supply_order – chứa dữ liệu tổng hợp về hoá đơn.
- dim_supplier – là bảng chứa danh sách nhà cung cấp giống dim_store lưu trữ thông tin cửa hàng trong mô hình sales.
Điểm mạnh và yếu của mô hình ngôi sao.
Có nhiều điểm mạnh của mô hình ngôi sao. Bảng fact liên quan đến mỗi bảng dimension bởi một quan hệ, và chúng ta không cần bất cứ từ điểm bổ sung nào để mô tả các bảng dimension. Đơn giản là truy vấn và giảm thời gian thực thi. Chúng ta có thể tái hiện báo cáo trực tiếp từ hệ thống OLTP, nhúng câu lệnh sẽ phức tạp hơn và có thể ảnh hưởng đến hiệu năng chung của hệ thống. Ví dụ sau đây là câu truy vấn cho mô hình sales sẽ trả về số lượng của tất cả các loại điện thợi được bán ở các cửa hàng đặt tại Berlin trong năm 2016:
SELECT dim_store.store_address, SUM[fact_sales.quantity] AS quantity_sold FROM fact_sales INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id WHERE dim_time.action_year = 2016 AND dim_store.city = 'Berlin' AND dim_product.product_type = 'phone' GROUP BY dim_store.store_id, dim_store.store_addressĐiểm yếu nhất của mô hình ngôi sau là dư thừa. Mỗi bảng dimension lưu trũ tách rời, và đây là nguyên nhân của không chuẩn hoá. Trong ví dụ của chúng ta, thành phố thuộc về một vùng hoặc một tỉnh thành, chúng cũng thuộc về một đất nước; chúng ta không lưu trữ mối quan hệ như là một quy tắc của cơ sở dữ liệu, nhưng chúng ta cứ lặp lại nó. Nghĩa là chúng ta sẽ tốn nhiều dung lượng ổ đĩa và có rủi ro về toàn vẹn dữ liệu.
Mô hình thiên hà [Galaxy Schema]
Chúng ta có thể nhìn vào 2 mô hình trên như là 2 data mart, 1 là cho phòng bán hàng [sales] 2 là cho bộ phận nhà cung cấp [supply]. Mỗi cái đó bao gồm chỉ một bảng fact và một vài bảng dimension. Nếu chúng ta muốn kết hợp 2 data mart vào làm một. Đây là kiểu mô hình chứa vài bảng fact và chia sẻ các bảng dimension nó được gọi là mô hình galaxy [galaxy schema]. Chia sẻ các bảng dimension có thể giảm kích thước của cơ sở dữ liệu đặc biết là khi chia sẻ các bảng dimension có nhiều giá trị. Ý tưởng là các bảng dimension trong cả 2 data mart có chung 1 cách thức. Nếu không chúng ta sẽ phải căn chỉnh cho nó phù hợp với cả 2.
Một mô hình thiên hà [galaxy schema] được xây dựng lên với 2 ví dụ data mart, được hiển thị như hình:
Mô hình ngôi sao [star schema] là một cách tiếp cận để tổ chức data warehouse. Nó rất đơn giản và thường dùng trong data mart. Nếu bạn không phải lo về dung lượng ổ đĩa và chúng ta làm tốt phần toàn vẹn dữ liệu thì mô hình ngôi sao khả thi và là lựa chọn tốt. Nếu không thì các bạn nên nghĩ đến cách tiếp cận khác. Một trong số đó là mô hình bông tuyết [snowflake shema] chúng ta sẽ nói đến sau.
Trích nguồn từ: [vertabelo.com]