Lược đồ sao trong mongodb

Ngày nay, báo cáo và phân tích quan trọng như nghiệp vụ chính vậy. Các bản báo cáo có thể được xây dựng từ dữ liệu trực tuyến; . 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 đề phân tách dữ liệu hệ thống hoạt động (hệ thống vận hành) và hệ thống báo cáo (hệ thống báo cáo)

Trước khi giải quyết cấu hình dữ liệu, chúng ta cần một vài hiểu biết về nền tảng về hệ thống. Chúng ta cần chia các hệ thống thành 2 danh mục. hệ thống hoạt động (hệ điều hành) và hệ thống báo cáo (hệ thống báo cáo). Hệ thống hoạt động thường được 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 hệ thống được gọi là OLAP. Hỗ trợ OLTP xử lý giao dịch trong nghiệp vụ kinh doanh. Chúng ta làm việc với dữ liệu “live” và cần chuẩn hóa tốc độ 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 được sử dụng để tổng hợp dữ liệu, thường được thiết kế theo cấu trúc phi tiêu 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 để tăng 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

Kho dữ liệu (kho dữ liệu – DWH) là một hệ thống được sử 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 tin của kho dữ liệu được sử 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 DWH là tòa nhà, data mart là văn phòng trong tòa nhà)

In sao lại cần data mart? . Đối với hầu hết người dùng, họ chỉ cần truy cập vào một tập dữ liệu cụ thể, giống như bán hàng (bán hàng), sản xuất (sản xuất), giao thông vận tải (hậu cần) hoặc tiếp thị. 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 kho dữ liệu và siêu thị dữ liệu

• Từ trên xuống. Data mart được tạo từ kho dữ liệu có trước
• Từ dưới lên. Data marts được tạo lần đầu tiên, sau đó kết hợp chúng lại thành kho dữ liệu

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ủa Extract, Transform và Load. Như tên của nó, chúng ta trích xuất (trích xuất) dữ liệu từ một hoặc nhiều nguồn là cơ sở dữ liệu hoạt động (OLTP), sau đó chuyển nó (biến đổi) cho phù hợp với cấu trúc của kho dữ liệu và tải nó.

Mô hình chiều dữ liệu (Mô hình chiều) là một phần của kho dữ liệu thiết kế, kết quả của việc tạo mô hình chiều. Có 2 loại bảng tham gia vào

• Các kích thước bảng được sử dụng để mô tả dữ liệu mà chúng tôi muốn lưu trữ. Ví dụ. một nhà bán lẻ muốn lưu thời gian lưu trữ, cửa hàng và nhân viên tham gia vào một hóa đơn. Mỗi thứ nguyên của bảng 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 (thuộc tính). Với mỗi cửa hàng, chúng ta lưu các thông tin như vị trí trong thành phố, miền, tỉnh thành và quốc gia. Mỗi ngày một 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 kích thước bảng

Trong sơ đồ ngôi sao, chúng ta sẽ thường tìm một vài thuộc tính là tập tin con của các thuộc tính khác nhau trong cùng 1 bản ghi. Sự dư thừa này nên rất quan trọng và giúp nâng cao hiệu quả tốt hơn. Chúng ta có thể sử dụng ngày tháng, vị trí và chi nhánh bán hàng để tổng hợp (chính là biến đổi trong ETL) và lưu trữ dữ liệu trong DWH. Trong kích thước mô hình, nó rất quan trọng trong việc định nghĩa kích thước đúng và phù hợp

• Bảng Fact chứa dữ liệu mà chúng ta muốn thêm vào báo cáo, tổng hợp trên các giá trị trong các kích thước của bảng. Một bảng thực tế chỉ có các cột lưu giá trị và các cột khóa ngoại tham chiếu đến kích thước bảng. Kết hợp tất cả các khóa ngoại và khóa chính trong bảng thực tế. Ví dụ, một bảng thực tế 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 những 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 thực tế là trung tâm của mô hình với các kích thước bảng xung quanh nó, nó nhìn giống như một ngôi sao. Điều này rõ ràng khi bảng thực tế được bao quanh bởi 5 kích thước bảng. Một biến thể của sơ đồ ngôi sao là sơ đồ con rết (lược đồ rết), trong đó bảng thực tế bị bao vây bởi số lượng lớn các kích thước bảng nhỏ

Mô hình ngôi sao được sử dụng rộng rãi trong data mart. Chúng ta có thể kết hợp chung trong mô hình từ trên xuống. Chúng ta sẽ phân chia 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). Việc bán hàng

Báo cáo bán hàng (sales report) là một trong những báo cáo phổ biến 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 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 ta trở nên nên xem xét, chúng ta sẽ phải xây dựng một kho dữ liệu 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, 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à chuyển vào kho dữ liệu

Mô hình trình bày ở trên chứa một bảng fact (màu đỏ) và 5 bảng dimensions (màu xanh). This table are

• fact_sales –Bảng này bao gồm tham chiếu đến các kích thước của bảng và thêm 2 thông tin chính (giá và số lượng bán). Chú ý là tất cả 5 khóa ngoại kết hợp với khóa chính của bảng
• dim_sales_type –Bảng này là loại bán hàng 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 – This timeholding Table. Nó bao gồm 5 thuộc tính ngoài khóa 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 tháng 1 sẽ là 1; tuần cuối tháng 12 sẽ là 52, v.v. ) Thuộc tính thực_tháng và thuộc tính thực_năm lưu trữ tháng và năm bán hàng. Các phần thông báo này được lấy 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 cửa hàng sẽ lưu thành phố, vùng, tỉnh và quốc gia nơi nó đặt. We are could not be clear as a star to setting

Ví dụ mô hình ngôi sao. đơn đặt hàng cung cấp

Có nhiều sự tương đồng với mô hình bán hàng ở trên

Mô hình này tập trung lưu trữ lịch sử của hóa đơn. We have a fact table and 4 dimensions table. Kích thước các bảng. dim_employee, dim_product và dim_time trích xuất thông tin giống như mô hình bán hàng. Tuy nhiên các bảng này lại khác nhau

• fact_supply_order – chứa tổng hợp dữ liệu về đơn hàng
• 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 bán hàng

Điểm mạnh và điểm 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 thực tế liên quan đến mỗi kích thước bảng 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ả kích thước bảng. Đơ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, lệnh nhúng 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 hỏi doanh số bán mô hình sẽ trả về số lượng của tất cả các loại máy móc được bán tại các cửa hàng đặt tại Berlin vào 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 cấu hình mô hình sau là dư thừa. Mỗi kích thước bảng được lưu trước khi tách rời, và đây là nguyên nhân của việc không chuẩn hóa. 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 vùng đất nước; . Nghĩa là chúng ta sẽ chiếm nhiều dung lượng ổ đĩa và có rủi ro về toàn bộ 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 (bán hàng) 2 là cho bộ phận nhà cung cấp (cung cấp). Mỗi cái đó bao gồm chỉ một bảng dữ kiện và một vài bảng chiều. 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 thực tế và chia sẻ các kích thước bảng mà nó được gọi là mô hình thiên hà (lược đồ thiên hà). Chia sẻ các kích thước bảng có thể giảm kích thước của cơ sở dữ liệu đặc biệt là khi chia sẻ các kích thước bảng có nhiều giá trị. Ý tưởng là các bảng dimensions 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à (lược đồ thiên hà) được xây dựng với 2 ví dụ data mart, được hiển thị như hình

Mô hình ngôi sao (lược đồ sao) là một cách tiếp cận để tổ chức kho dữ liệu. Nó rất đơn giản và thường dùng trong data mart. Nếu bạn không lo về dung lượng ổ đĩa và chúng ta làm tốt phần dữ liệu hoàn toàn nguyên chất 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