V. MÔ HÌNH DỮ LIỆU
5.1Lược đồ hình sao
Lược đồ hình sao được đưa ra bởi Dr. Ralph Kimball. Lược đồ hình sao cho phép một hệ thống đối tượng có thể kết nối với nhiều đối tượng khác. Mô hình này thể hiện cách nhìn của NSD về nhiều vấn đề trong tác nghiệp. Trong lược đồ hình sao, dữ liệu được xác định và phân loại theo 2 kiểu:
-Các sự kiện được tổ chức thành bảng Fact. Bảng Fact chứa các thông tin cơ sở ở mức giao tác ở trong nghiệp vụ mà các ứng dụng cần thiết. Các bảng Fact thường rất lớn, chứa hàng triệu dòng mà phần lớn là số.
-Các chiều của dữ liệu được tổ chức thành các bảng chiều. Bảng chiều thường là tương đối nhỏ so với các bảng Fact, chứa các thông tin mô tả. Đó là các bộ lọc hoặc các ràng buộc của những sự kiện ở bảng Fact. Bảng chiều chứa các dữ liệu cần thiết cho việc thực hiện các giao tác nghiệp vụ theo một chiều, hay phạm vi nào đó.
Ưu điểm của sơ đồ hình sao: Hỗ trợ rất đa dạng các câu truy vấn và xử lý khá hiệu quả những câu truy vấn đó. Phù hợp với cách mà NSD nhận và sử dụng dữ liệu và qua đó làm cho dữ liệu được hiểu trực quan hơn. Nguyên lý cơ bản của sơ đồ hình sao là một dạng dư thừa dữ liệu cải thiện sự thực hiện các truy vấn. Với sơ
đồ hình sao, người thiết kế có thể dễ dàng mô phỏng những chức năng của cơ sở dữ liệu đa chiều. Sự phi chuẩn hóa có thể coi là sự tiền kết nối (pre-joining) các bảng để cho các ứng dụng không phải thực hiện công việc kết nối, làm giảm thời gian thực hiện. Dễ dàng nhận thấy, lược đồ hình sao được thiết kế là để khắc phục những hạn chế của mô hình quan hệ hai chiều. Với cơ sở dữ liệu được thiết kế theo lược đồ hình sao, những truy vấn với những câu hỏi phức tạp liên quan tới nhiều bảng và số liệu tổng cộng trở nên đơn giản hơn và số lượng công việc cần thực hiện để đưa được ra câu trả lời là ít nhất so với một mô hình quan hệ chuẩn. Lược đồ hình sao cải thiện đáng kể thời gian truy vấn và cho phép thực hiện một số tính năng đa phạm vi. Sơ đồ này rất trực quan, dễ sử dụng, thể hiện khung nhìn đa chiều của dữ liệu dùng ngữ nghĩa của cơ sở dữ liệu quan hệ. Khóa của bảng sự kiện được tạo bởi những khóa của các bảng chứa thông tin theo từng bảng chiều. Tất cả các khóa đều được xác định với cùng một chuẩn đặt tên.
Những bảng Fact có chứa khóa của các bảng chiều, có thể là với tên khác đi để đảm bảo tính duy nhất của mỗi hàng. Các bảng chiều thường có định danh duy nhất và chứa đựng những thông tin về chiều của bảng đó. Số lượng các bảng chiều của mỗi bảng Fact là từ 3 đến 5.
Vì bảng Fact được tổng hợp từ trước và được kết hợp theo nhiều chiều nên xu hướng có rất nhiều hàng và tăng trưởng một cách nhanh chóng trong khi đó các bảng chiều không có nhiều hàng và sự tăng trưởng là tĩnh. Bảng Fact có thể bao gồm hàng triệu hàng. Bảng chiều chứa đựng các thuộc tính có thể được sử dụng như các tiêu chí tìm kiếm và thường có kích thước nhỏ hơn nhiều, rất quen thuộc với người sử dụng từ trước. Khoá của nó không là khoá ghép như bảng sự kiện. Nếu một bảng chiều bắt đầu có sự tương đồng với các bảng Fact thì có thể nó cần được chia ra thành các bảng chiều.
Để cải thiện công suất của các truy vấn trong sơ đồ hình sao có thể thực hiện những kỹ như: Xác định sự kết hợp các bảng Fact đang tồn tại hay tạo ra một sự kết hợp mới các bảng Fact. Phân chia bảng Fact đến mức mà hầu hết các truy vấn chỉ truy nhập tới phần đó. Tạo ra các bảng Fact riêng rẽ. Tạo ra những tệp chỉ số đơn duy nhất hoặc các kĩ thuật khác để cải thiện năng suất kết hợp.
5.1.1 Vấn đề thiết kế sơ đồ hình sao liên quan tới những người quản trị CSDL
Mặc dầu hầu hết các chuyên gia đều đồng ý rằng sơ đồ hình sao thích hợp cho phương pháp thiết lập mô hình cho phương pháp DW nhưng vẫn còn một số vấn đề của hệ quản trị cơ sở dữ liệu quan hệ liên quan tới việc cài đặt sơ đồ hình sao.
a/ Đánh chỉ số (chỉ mục)
Sử dụng việc đánh chỉ số có thể đảm bảo sự duy nhất của các khóa và có thể cải thiện năng suất đọc. Vì các bảng trong thiết kế hình sao điển hình chứa sự phân cấp tổng thể của các thuộc tính (chẳng hạn với chiều thời kỳ Period), sự phân rã
này có thể là ngày→ tuần→ tháng→ quí→ năm, nghĩa là tạo ra một khóa nhiều
thành phần của ngày, tuần, tháng, quí, năm. Cách thức này được chấp nhận cho những thiết kế bình thường nhưng nó cũng thể hiện một vài vấn đề trong mô hình sơ đồ hình sao. Đó là:
-Nó đòi hỏi một sự định nghĩa Metadata phức tạp để xác định một quan hệ đơn. Điều này làm cho thiết kế thêm phức tạp và năng suất kém đi nhiều.
-Vì bảng Fact phải chứa tất cả các khóa thành phần như một phần của khóa chính, việc thêm vào hay xóa bỏ một mức trong sơ đồ phân cấp sẽ đòi hỏi sự thay đổi vật lí ở các bảng liên quan mất nhiều thời gian và hạn chế tính linh hoạt trong truy vấn.
-Chứa tất cả các đoạn khóa của mỗi chiều trong bảng Fact làm tăng kích thước của bảng chỉ số và tác động mạnh tới công suất và sự ổn định.
Một phương pháp đối với khóa ghép như trên là cắt khóa ra thành các khóa đơn (chẳng hạn khóa bao gồm tất cả các thuộc tính- ngày, tuần, tháng, quí, năm). Cách này giải quyết được 2 vấn đề đầu nhưng kích thước của bảng chỉ số vẫn là một vấn đề.
Cách tốt nhất là thay những khóa có ý nghĩa bằng việc sử dụng một khóa do mình tạo ra là một khóa nhỏ nhất có thể mà vẫn bảo đảm tính duy nhất của mỗi bản ghi. Những khóa có nghĩa được thay thế như nói ở trên không cần thiết phải hủy bỏ, chúng có thể dơn giản là được chuyển đến một thuộc tính không phải là khóa. Kết quả thiết kế theo mô hình hình sao bao gồm một bảng Fact với một khóa chính có đúng một cột khóa cho mỗi chiều tại đó mỗi khóa là khóa được tạo ra. Phương pháp này cho khả năng linh hoạt ở mức cao nhất, việc bảo trì là ít nhất và công suất cao nhất có thể.
b/ Chỉ thị về mức
Để định hướng các chiều một cách thành công, việc thiết kế các bảng chiều thường bao gồm một mức chỉ dẫn phân cấp cho mỗi bản ghi. Mỗi truy vấn lấy dữ liệu từ các bản ghi chi tiết của một bảng lưu trữ chi tiết và những dữ liệu kết hợp phải sử dụng chỉ dẫn này như một ràng buộc thêm để thu được kết quả đúng. Mức này là một công cụ có ích cho các môi trường được kiểm soát chặt chẽ bởi các DBA và trong môi trường đó một vài truy vấn đặc biệt được cho phép sử dụng. Nếu người sử dụng không quan tâm tới những chỉ thị về mức hoặc giá trị của nó không đúng thì mặc dù quá trình truy vấn là đúng vẫn có thể đưa ra kết quả không hợp lệ.
Sự lựa chọn tốt nhất cho việc dùng chỉ thị về mức là sử dụng sơ đồ bông tuyết. Trong sơ đồ loại này, các bảng Fact kết hợp được tạo ra một cách riêng biệt từ những bảng chứa dữ liệu chi tiết. Thêm vào với các bảng Fact chính, sơ đồ hình tuyết rơi còn chứa các bảng Fact riêng rẽ cho mỗi mức kết hợp, vì vậy không mắc lỗi trong việc lựa chọn các bản ghi chi tiết. Tuy nhiên sơ đồ hình tuyết rơi phức tạp
hơn sơ đồ hình sao và thường đòi hỏi những câu lệnh SQL phức tạp hơn để nhận được câu trả lời.
5.1.3 Những vấn đề thiết kế lược đồ hình sao liên quan tới các phương tiện của hệ quản trị cơ sở dữ liệu quan hệ và kĩ thuật tối ưu.
a/ Vấn đề kết hợp từng cặp 2 bảng
Hệ quản trị cơ sở dữ liệu quan hệ không được thiết kế để dùng cho một tập lớn các câu truy vấn phức tạp có thể được đưa ra đối với một sơ đồ hình sao. Một cách cụ thể khả năng lấy được thông tin liên quan từ một số bảng trong một câu truy vấn đơn- được gọi là xử lí kết hợp - rất bị hạn chế.
Một số hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) chỉ có thể kết hợp 2 bảng tại một thời điểm. Nếu một sự kết hợp phức tạp liên quan tới nhiều hơn 2 bảng thì RDBMS cần phải tách câu truy vấn thành một chuỗi các cặp 2 bảng kết hợp với nhau. Đó không phải là hạn chế khắt khe nhất đối với những câu hỏi đơn giản được thực hiện bởi cơ sở dữ liệu OLTP tuy nhiên những kĩ thuật kết hợp như vậy không thể thực hiện một cách đầy đủ trong môi trường DW.
Yêu cầu là liệt kê phần đóng góp của tất cả số lượng hàng bán được theo mỗi sản phẩm trong các thị trường, các loại và các giai đoạn khác nhau. Như vậy chúng ta phải kết hợp dữ liệu từ 4 bảng: SalesFact, Priod, Market, Product.
Số lượng phép kết hợp được đánh giá là tăng theo hàm mũ so với số lượng các bảng được đem ra kết hợp nên trật tự kết hợp không còn là vấn đề quan trọng nhất, nó được tối ưu để có thể thực hiện trong một khoảng thời gian hợp lí. Sự kết hợp có nhiều thuật toán khác nhau. Mỗi thuật toán trong những thuật toán này cần được đánh giá cho mọi sự kết hợp. Chẳng hạn có 5 thuật toán kết hợp RDBMS, cần đánh giá 10!*5=18 triệu phép toán kết hợp cho một câu truy vấn liên quan tới 10 bảng. Con số này qua lớn khiến cho một số cơ sở dữ liệu không chạy những truy vấn cố gắng kết hợp quá nhiều bảng. Một RDBMS điển hình phải quyết định trật tự kết hợp từng cặp 2 bảng trước khi một truy vấn bắt đầu được thực hiện vì vậy việc thực hiện bị trễ đi một khoảng thời gian khá dài.
b/ Vấn đề kết hợp đối với sơ đồ hình sao
Vì số lượng các cặp bảng cần kết hợp với nhau thường quá lớn cho một sự đánh giá đầy đủ, rất nhiều RDBMS tối ưu hạn chế phép chọn dựa trên một tiêu chí cụ thể, thường là nhặt ra kết hợp các bảng liên quan trực tiếp với nhau. Đối với ví dụ trình bày ở trên thì việc kết hợp SalesFact với Perid thì tốt hơn là Product kết hợp với Market. Chiến lược này có vẻ có lí đối với sơ đồ OLTP truyền thống chứa một mạng phức tạp rất nhiều các bảng có quan hệ trực tiếp với nhau. Trong khi đó nó tỏ ra không hiệu quả lắm với DW vì trong sơ đồ hình sao chỉ có một bảng liên quan trực tiếp tới hầu hết các bảng còn lại đó là bảng Facts. Điều đó có nghĩa là bảng Facts là thành phần quan trọng nhất cho sự kết hợp đầu tiên. Nhưng kích thước của bảng Facts thường là lớn nhất nên chiến lược này tạo ra tập các bảng (adsbygoogle = window.adsbygoogle || []).push({});
trung gian rất lớn. Điều này ảnh hưởng tới năng suất thực hiện truy vấn. Vấn đề công suất này là giả thiết rằng RDBMS có thể chọn được cặp 2 bảng kết hợp với nhau tốt nhất được đánh giá theo trật tự trong tập giới hạn các trật tự. Trong một RDBMS được tối ưu cho OLTP, truy vấn được phân tích và kế hoạch được lựa chọn dựa trên sự ước lượng độ lớn của bảng kết quả trung gian. Những ước lượng này dựa trên sự thống kê của bản thân dữ liệu và thường không được chính xác. Trong bất kì một môi trường tính toán nào, sự lan truyền về lỗi chỉ làm cho vấn đề trở nên tồi tệ thêm: nếu có một lỗi trong lần đánh giá đầu tiên thì lỗi này sẽ được nhân lên trong mỗi lần đánh giá mới tiếp theo vì vậy chỉ một lỗi nhỏ sẽ trở nên rất nghiêm trọng. Hiệu quả của mạng là ở chỗ RDBMS có thể gạt bỏ trật tự tối ưu nhất khi phải trả cái giá quá cao do lỗi xảy ra trong quá trình ước lượng chi phí.