Thông lệ thiết kế báo cáo tốt nhất
Chủ đề này mô tả các yếu tố chính cần cân nhắc khi sử dụng Application Studio để ghi báo cáo trên khối OLAP.
Những cân nhắc về giao diện người dùng
Bảng này hiển thị những cân nhắc chính khi thiết kế báo cáo giao diện người dùng:
Cân nhắc | Mô tả |
---|---|
Báo cáo của bạn có chứa hyperblock lồng không? | Báo cáo dựa trên một lát cắt và trong đó các hyperblock được lọc để hoạt động tốt hơn, ví dụ như để loại trừ các giá trị rỗng. Có một đường cong học tập được liên kết đến việc sử dụng các lát cắt và còn thiếu một số chức năng mong muốn nhưng các chức năng có sẵn đáp ứng 80% trường hợp sử dụng. |
Báo cáo có cần cuộn dọc không? | Nếu có, hãy kết hợp phần mở rộng web phân trang vào chân trang báo cáo của bạn. Điều đó cải thiện trải nghiệm và hiệu suất người dùng. |
Báo cáo có sử dụng định dạng có điều kiện không? | Định dạng có điều kiện là một tính năng mạnh mẽ nhưng hãy sử dụng một cách hạn chế vì ảnh hưởng đến hiệu suất khi đánh giá các điều kiện. Bạn tránh định dạng có điều kiện khi sử dụng định dạng số và dựa vào các định dạng số được xác định trong cơ sở dữ liệu. Application Studio nhóm các yêu cầu dữ liệu của công thức, các yêu cầu này được gửi đến cơ sở dữ liệu OLAP. Kết quả là một truy vấn tổng thể thay vì nhiều truy vấn ô đơn lẻ. Truy vấn theo cụm nhanh hơn truy cập từng ô đơn lẻ. Công thức đọc dữ liệu trong định dạng có điều kiện và bước nhảy báo cáo không thể được nhóm lại và luôn được truy vấn dưới dạng yêu cầu ô đơn lẻ. |
Các báo cáo tờ mẫu có được thiết kế quá mức không? | Hãy nghĩ đến tính đơn giản khi phát triển tờ mẫu mới và kiềm chế ham muốn không ngừng thêm nội dung vào tờ mẫu hiện có nếu có thể. Số lượng kiểu sẽ làm tăng kích thước của báo cáo. |
Bạn đã xác định lựa chọn ban đầu cho các thực thể báo cáo chưa? | Báo cáo tải nhanh hơn nếu thực thể cuối cùng mà người dùng trực quan hóa được lưu trữ. Ví dụ: nếu báo cáo được tải ở cấp độ Toàn bộ Thực thể thì sẽ phải lấy nhiều dữ liệu hơn và cần nhiều thời gian hơn để tải báo cáo. |
Bạn có đang sử dụng các điều khiển không trạng thái như đối tượng Tra cứu thay vì các điều khiển dựa trên dạng xem danh sách không? | Điều khiển dựa trên dạng xem danh sách, chẳng hạn như hộp tổ hợp, sẽ truy xuất danh sách thành phần khi tải báo cáo. Điều khiển không trạng thái không truy xuất danh sách thành phần, giúp tải báo cáo nhanh hơn. |
Bạn có kiểm tra kỹ lưỡng báo cáo của mình không? | Bạn có thể xây dựng các báo cáo ghép nối các chuỗi để lấy ID thành phần nhưng nếu bạn gửi yêu cầu đến máy chủ OLAP đối với các thành phần không tồn tại thì bạn có nguy cơ gặp lỗi và hết thời gian chờ. Việc thử nghiệm luôn phải cân nhắc đến các thiết lập bảo mật của người dùng cuối. |
Danh sách bộ lọc | Một số loại bộ lọc chậm hơn những loại khác, ví dụ bộ lọc thuộc tính chậm hơn bộ lọc giá trị. Bộ lọc nói chung chậm hơn so với lựa chọn cấu trúc. Tránh vùng dữ liệu lớn trong bộ lọc. Càng chọn nhiều thành phần cho mỗi chiều thì lọc càng chậm. |
Thao tác Toàn cục | Hãy cân nhắc sử dụng các hành động toàn cục để giảm thời gian tính toán cho các báo cáo đơn lẻ. Các hành động toàn cục được chạy trong quá trình người dùng đăng nhập, sau khi tạo mô hình kho và trước khi tạo bất kỳ công cụ nào. Giá trị biến toàn cục đã được thiết lập trước khi bắt đầu tải bất kỳ báo cáo nào. |
Biến báo cáo | Tránh sử dụng chuỗi dài trong biến. |
Những cân nhắc về mặt back end, môi trường và quan hệ giữa các cá nhân
Trong dự án thành công, sẽ có vòng lặp phản hồi giữa người phát triển báo cáo và tác giả của các khối. Thiết kế khối kém có lẽ là yếu tố lớn nhất gây ra hiệu suất kém. Bảng này nêu ra những yếu tố quan trọng cần cân nhắc:
Cân nhắc | Mô tả |
---|---|
Ghi và thử nghiệm báo cáo với tập hợp dữ liệu thực tế | Báo cáo có chiều bao gồm tới 30 thành phần và khối bao gồm hàng trăm điểm dữ liệu có thể hoạt động tốt nhưng khó duy trì vì tập hợp dữ liệu lớn. Điều quan trọng là phải thực hiện thử nghiệm với tập hợp dữ liệu thực tế. |
Ghi các quy tắc OLAP chính xác. Ví dụ về quy tắc được phát triển kém: [Doanh thu] = [Giá] * [Số lượng] hoặc [Tài khoản 1] = [Account2} + [Account3] + [Account4] | Tìm hiểu các phương pháp hay nhất để ghi quy tắc OLAP. Tham khảo tài liệu trực tuyến để được hướng dẫn. |
Kích thước có cấu trúc không tốt | Hãy xem xét một chiều sản phẩm với thành phần cao nhất là Tất cả Sản phẩm nhưng có 10.000 thành phần con. Vào một thời điểm nào đó, người dùng có thể kích hoạt yêu cầu tới máy chủ OLAP để yêu cầu truy xuất và có khả năng thì hiển thị tất cả các thành phần. Các cấp độ trung gian giúp báo cáo dựa trên phân cấp có hiệu suất cao hơn. |
Số lượng người dùng cao | Tránh thay đổi chiều trong giờ làm việc, khi lượng người dùng trực tuyến cao nhất. |
Thiếu các thành phần cha trong chiều, ví dụ như thành phần tổng trong năm | Báo cáo truy xuất dữ liệu hàng ngày trong các cột ẩn để cộng lại và hiển thị dưới dạng tổng trong năm chậm hơn nhiều so với báo cáo tính tổng trong cơ sở dữ liệu OLAP. |
Sử dụng sai thuộc tính | Thuộc tính có thể được định nghĩa và sử dụng tùy ý để lọc báo cáo, nhưng báo cáo được lọc sẽ kém hiệu quả hơn so với phân cấp nhóm các thành phần theo giá trị thuộc tính tiềm năng. |
Đảm bảo máy chủ OLAP có đủ RAM | OLAP là cơ sở dữ liệu trong bộ nhớ. Các truy vấn được soạn kém có thể tốn một lượng RAM đáng kể. Nếu máy chủ OLAP của bạn đang phân trang, bạn có thể thấy hiệu suất kém. |
Không đặt dữ liệu giao dịch vào khối | Infor OLAP được tối ưu hóa cho báo cáo cấp độ số dư. Bạn có thể dựng báo cáo không hiệu quả mà không bị ứng dụng ngăn chặn. Ví dụ: bạn có thể dựng một khối chi tiết trên tệp dòng Đơn Mua hàng, nhưng khả năng sẽ không hiệu quả. |
Ghi một báo cáo không tốt như một giải pháp ngắn hạn | Chống lại áp lực dự án, làm điều gì đó tạo ra báo cáo không hiệu quả. Ghi ra những lo ngại của bạn và đề xuất giải pháp thay thế. |
Không lưu trữ số không trong khối của bạn | Số không là số phải được lưu trữ trong bộ nhớ OLAP và được đánh giá trong các phép tính quy tắc trong khi giá trị thay thế rỗng thì không. Bạn có thể tạo một quy trình Application Engine có thể thay thế số không trong một khối bằng giá trị rỗng. |
Nơi tốt nhất để thực hiện tính toán | Điều này phụ thuộc vào nhiều yếu tố, bao gồm tần suất yêu cầu các giá trị tính toán. Sau đây là ví dụ về tùy chọn nơi thực hiện tính toán theo thứ tự ưu tiên:
|
Thiết lập thành phần mặc định cụ thể | Nếu bạn không chọn thành phần mặc định cụ thể cho chiều phân cấp, thành phần cao nhất sẽ được chọn làm thành phần mặc định. Trường hợp này cần nhiều thời gian hơn để đặt lại thành phần mặc định. Thành phần mặc định hiện tại được thiết lập trong thuộc tính mở rộng của chiều. |
Việc sử dụng giao diện XML chậm hơn so với giao tiếp thông qua giao diện cài sẵn trong phiên bản 11 | Để tăng tốc độ giao tiếp, chúng tôi khuyên bạn không nên đọc giá trị theo từng yêu cầu đơn lẻ mà hãy gộp thành một hoặc một vài yêu cầu gửi tới OLAP. Có thể thực hiện điều này với yêu cầu Đọc Khối bằng cách thêm nhiều thẻ CellCoordinate . |
Sử dụng phân trang phía máy chủ để tạo báo cáo chỉ truy vấn các giá trị nhìn thấy được | Việc phân trang trong các trang hyperblock được thực hiện ở phía máy khách. Tất cả các ô đều được trả về từ máy chủ nhưng chỉ có một trang được vẽ.
Trong danh sách OLAP, hãy sử dụng hàm tập hợp con để phân trang trên phía máy chủ. Trong danh sách liên quan, hãy sử dụng các phương pháp nâng cao trong truy vấn để tạo tập hợp con. |
Lọc các truy vấn của bạn để đảm bảo bạn không truy vấn tất cả các thành phần từ một chiều | Sử dụng tùy chọn bỏ giá trị rỗng để chỉ hiển thị các ô đã điền, hiển thị tất cả các thành phần trong một thành phần cha nhất định thay vì toàn bộ một chiều. Giảm cấp độ mở rộng ban đầu trong các lát cắt và danh sách. |
Tránh đặt một lượng lớn chiều vào trục | Số lượng tối ưu là ba chiều trên mỗi trục hàng, một chiều trên mỗi trục cột. |