보고서 디자인 모범 사례
이 항목에서는 Application Studio를 사용하여 OLAP 큐브 위에 보고서를 작성할 때 고려해야 할 주요 요소에 대해 설명합니다.
프런트엔드 고려 사항
이 표는 프런트엔드 보고서 디자인에 대한 주요 고려 사항을 보여줍니다.
| 고려 사항 | 설명 |
|---|---|
| 보고서에 중첩된 하이퍼블록이 포함되어 있나요? | 슬라이스를 기반으로 하고 하이퍼블록을 필터링하여 예를 들어 null 값을 제외하는 보고서의 성능이 더 우수합니다. 슬라이스 사용과 관련된 학습 곡선이 있고 일부 바람직한 함수가 누락되었지만, 사용 가능한 함수는 사용 사례의 80%를 충족합니다. |
| 보고서에 수직 스크롤이 필요한가요? | 그렇다면 보고서 바닥글에 페이징 웹 확장 기능을 통합합니다. 사용자 경험과 성능이 향상됩니다. |
| 보고서에서 조건부 서식을 활용하나요? | 조건부 서식은 강력한 기능이지만, 조건이 평가될 때 성능에 영향을 미치므로 신중하게 사용해야 합니다. 숫자 형식을 사용할 때는 조건부 서식을 피하고 데이터베이스에 정의된 숫자 형식을 사용해야 합니다. Application Studio는 수식의 데이터 요청을 클러스터링하여 OLAP 데이터베이스로 전송합니다. 결과적으로 여러 개의 단일 셀 쿼리 대신 하나의 전체 쿼리가 생성됩니다. 클러스터형 쿼리는 단일 셀 접근보다 빠릅니다. 조건부 서식과 보고서 점프 내의 데이터 읽기 수식은 클러스터링될 수 없으며 항상 단일 셀 요청으로 쿼리됩니다. |
| 스타일 시트 보고서가 과도하게 설계되었나요? | 새 스타일시트를 개발할 때는 단순성을 고려하고 가능하면 기존 스타일시트에 콘텐츠를 계속 추가하지 않는 것이 좋습니다. 스타일의 수가 많을수록 보고서의 크기가 커집니다. |
| 보고서 엔터티에 대한 초기 선택을 지정했습니까? | 사용자가 마지막으로 시각화한 엔터티가 저장되어 있으면 보고서가 더 빨리 로드됩니다. 예를 들어, 모든 엔터티 수준에서 보고서를 로드하는 경우 훨씬 더 많은 데이터를 가져와야 하며 보고서를 로드하는 데 더 많은 시간이 걸립니다. |
| 목록 뷰를 기반으로 하는 컨트롤 대신, Lookup 개체와 같은 상태 비저장 컨트롤을 사용하고 있나요? | 콤보 상자와 같은 목록 뷰 기반 컨트롤은 보고서가 로드될 때 요소 목록을 검색합니다. 상태 비저장 컨트롤은 요소 목록을 검색하지 않으므로 로드 속도가 더 빠릅니다. |
| 보고서를 철저히 테스트하나요? | 문자열을 연결하여 요소 ID를 도출하는 보고서를 작성할 수 있지만, 존재하지 않는 요소에 대한 요청을 OLAP 서버로 보내면 오류 및 시간 초과가 발생할 위험이 있습니다. 테스트에서는 항상 최종 사용자 보안 설정을 고려해야 합니다. |
| 목록 필터 | 일부 필터 유형은 다른 필터 유형보다 느립니다. 예를 들어, 특성 필터는 값 필터보다 느립니다. 일반적으로 필터는 구조 선택보다 느립니다. 필터에서 큰 데이터 영역을 사용하지 마십시오. 차원당 선택하는 요소가 많을수록 필터 속도가 느려집니다. |
| 전역 작업 | 단일 보고서의 계산 시간을 단축하기 위해 전역 작업을 사용하는 것을 고려합니다. 전역 작업은 사용자가 로그인하는 동안, 리포지토리 모델이 생성된 후, 엔진이 생성되기 전에 실행됩니다. 보고서가 로드되기 전에 전역 변수 값이 이미 설정됩니다. |
| 보고서 변수 | 변수에 큰 문자열을 사용하지 마십시오. |
백엔드, 환경 및 개인 간 관계 고려 사항
성공적인 프로젝트에서는 보고서 개발자와 큐브 작성자 사이에 피드백 루프가 생성됩니다. 잘못된 큐브 설계는 성능 저하의 가장 큰 요인일 것입니다. 다음 표는 고려해야 할 중요한 요소를 보여줍니다.
| 고려 사항 | 설명 |
|---|---|
| 현실적인 데이터 세트를 사용하여 보고서 작성 및 테스트 | 차원에 최대 30개의 요소가 포함되고 큐브에 수백 개의 데이터 요소가 포함된 보고서는 성능이 우수하지만 데이터 세트가 크기 때문에 유지 관리가 어렵습니다. 현실적인 데이터 세트를 사용하여 테스트를 수행하는 것이 중요합니다. |
| 올바른 OLAP 규칙 작성. 잘못 작성된 규칙의 예: [수입] = [가격] * [수량] 또는 [계정 1] = [계정 2} + [계정 3] + [계정 4] | OLAP 규칙 작성에 대한 모범 사례를 숙지하십시오. 자세한 내용은 온라인 설명서를 참조하십시오. |
| 구조가 잘못된 차원 | 상위 요소가 '모든 제품'이지만 10,000개의 하위 요소를 가진 제품 차원을 생각해 보십시오. 어느 시점에서 사용자는 모든 요소를 검색하고 잠재적으로 표시해야 하는 OLAP 서버에 대한 요청을 트리거할 가능성이 높습니다. 중간 수준에서는 계층 구조에 기반한 보고서의 성능이 더욱 향상됩니다. |
| 사용자 수가 많음 | 사용자 수가 가장 많은 업무 시간대에는 치수 변경을 피하십시오. |
| 차원에 상위 항목 요소가 누락됨(예: 연도 총 요소) | 숨겨진 열에서 일별 데이터를 불러와 합산하여 연간 총합으로 표시하는 보고서는 총합이 OLAP 데이터베이스에서 계산되는 보고서보다 훨씬 느립니다. |
| 특성 오용 | 특성은 자유롭게 정의하여 보고서를 필터링하는 데 사용할 수 있지만, 필터링된 보고서는 잠재적 특성 값으로 요소를 그룹화하는 계층 구조보다 성능이 떨어집니다. |
| OLAP 서버에 충분한 RAM이 있는지 확인하십시오. | OLAP는 인메모리 데이터베이스입니다. 잘못 작성된 쿼리는 상당한 양의 RAM을 소모할 수 있습니다. OLAP 서버가 페이징을 수행 중이라면 성능 저하가 예상됩니다. |
| 거래 데이터를 큐브에 넣지 마십시오 | Infor OLAPsms 계정 수준 보고에 최적화되어 있습니다. 응용 프로그램에 의해 방해받지 않고도 성능이 좋지 않은 보고서를 작성할 수 있습니다. 예를 들어, 구매 주문 라인 파일에 대한 자세한 큐브 작성할 수 있지만 성능이 좋지 않을 가능성이 높습니다. |
| 단기적인 해결책으로 잘못된 보고서 작성 | 성과가 없는 보고서를 작성하라는 프로젝트의 압박을 거부하십시오. 우려 사항을 서면으로 작성하고 대안을 제시하십시오. |
| 큐브에 0 저장 금지 | 0은 OLAP 메모리에 저장되어야 하며 규칙 계산에서 평가되어야 하는 숫자인 반면, 대안인 null은 그렇지 않습니다. 큐브 내의 0을 null로 대체할 수 있는 Application Engine 프로세스를 생성할 수 있습니다. |
| 최적의 계산 위치 | 이는 계산된 값이 얼마나 자주 필요한지 등 여러 요인에 따라 달라집니다. 다음은 계산을 수행할 위치에 대한 예시 옵션(우선순위 순)입니다.
|
| 특정 기본 요소 설정 | 계층적 차원에 대한 특정 기본 요소를 선택하지 않으면 최상위 요소 기본값으로 선택됩니다. 기본 요소를 다시 설정하기 위해서는 더 많은 시간이 필요합니다. 현재 기본 요소는 차원의 확장 속성에 설정됩니다. |
| XML 인터페이스 사용은 버전 11의 기본 제공 인터페이스를 통한 통신보다 느립니다. | 통신 속도를 높이려면 단일 셀 요청으로 값을 읽지 말고 OLAP에 하나 또는 몇 개의 요청으로 값을 넣는 것이 좋습니다. 이 작업은 큐브 읽기 요청에 여러 개의 CellCoordinate 태그를 추가하여 수행할 수 있습니다. |
| 서버 측 페이징 사용하여 표시되는 값만 쿼리하는 보고서를 만듭니다. | 하이퍼블록 페이지의 페이징은 클라이언트 측에서 수행됩니다. 모든 셀은 서버에서 반환되지만, 페이지만 그려집니다.
OLAP 목록에서는 서버 측에서 페이지를 구분하기 위해 subset 함수를 사용합니다. 관계형 목록에서는 쿼리에서 고급 메서드를 사용하여 하위 집합을 만듭니다. |
| 차원의 모든 요소를 쿼리하지 않도록 쿼리를 필터링합니다. | 채워진 셀만 표시하고, 전체 차원 대신 특정 상위 항목 아래의 모든 요소를 표시하려면 null 제거를 사용합니다. 슬라이스 및 목록의 초기 확장 수준을 낮춥니다. |
| 축에 많은 양의 치수를 넣지 마십시오. | 최적의 양은 행 축당 3차원, 열 축당 1차원입니다. |