최적화에 대한 일반 이론
최적화의 또 다른 형태는 도메인 모델을 변경하는 것입니다. XPath 쿼리가 최대한 최적화되었지만 여전히 앱에서 필요한 성능을 얻지 못하는 경우 다음 단계는 데이터를 저장하는 방식을 변경하는 것입니다. 다음 중 하나를 선택할 수 있습니다:
정규화
여러 곳에 저장되어 있는 고객 이름과 같은 중복 데이터를 제거하여 데이터의 오류 가능성을 줄이거나
비정규화
예를 들어 주문에 고객 이름을 추가하여 주문을 확인할 때 고객 기록을 검색할 필요가 없도록 의도적으로 데이터를 복제하는 것입니다.
이 두 가지 솔루션은 서로 반대되는 개념이지만 인덱스와 마찬가지로 테스트 중에 특정 상황에서 어느 한 쪽을 사용하면 앱 속도가 빨라질 수 있습니다.
정규화
앞서 설명한 대로 정규화는 중복 데이터를 제거하는 작업입니다. AdventureWorks 데이터베이스에 주문 테이블만 있고 고객 테이블이 없다고 가정해 보겠습니다. 주문 테이블은 정규화가 필요한 데이터 모델이 될 것입니다. 왜 그럴까요? 정규화되지 않은 데이터 모델은 문제를 일으킬 수 있기 때문입니다. 주요 문제는 다음과 같습니다:
삽입 이상
이러한 이상 현상으로 인해 의도하지 않은 데이터 중복이 발생합니다. 저희의 경우 주문마다 고객 정보를 반복해야 합니다.
업데이트 이상
이러한 이상 현상으로 인해 잘못된 데이터가 발생합니다. 고객이 주소를 변경한 경우 모든 주문에서 주소를 업데이트해야 합니다. 주문이 누락되면 데이터가 일관되지 않게 됩니다.
삭제 이상
이러한 이상 현상은 잠재적인 데이터 손실을 초래합니다. 고객에 대한 모든 주문이 삭제되면 모든 고객 데이터가 손실된다고 상상해 보세요.
이 예에서는 각 주문에 연결되는 고객 엔티티를 도입하여 데이터 모델을 정규화합니다.
제품 리뷰 정규화하기
이제 AdventureWorks 데이터베이스에서 자체적으로 정규화 작업을 수행할 때입니다. 현재 AdventureWorks가 판매하는 제품에 대한 리뷰는 제품 자체에만 연결되어 있습니다. 고객에 대한 더 많은 정보를 얻으려면 이러한 리뷰를 고객과 연결하는 것이 가장 좋다고 판단한 AdventureWorks 직원들은 이 작업을 진행하기로 결정했습니다.
1. Production 도메인 모델을 열고 ProductReview와 Customer 간의 연결을 추가합니다. Customer 엔티티는 Sales 모듈에 있다는 것을 기억하세요.
이제 고객에 연결했으므로 이제 연결된 Customer 개체에서 해당 속성을 검색할 수 있으므로 ReviewerName 및 EmailAddress 속성을 엔티티에서 제거할 수 있습니다.
비정규화
정규화의 반대 개념은 비정규화로, 중복을 도입하고 예외가 있을 수 있다는 사실을 인정하는 것입니다. 이 작업을 수행하는 몇 가지 이유는 다음과 같습니다:
성능 향상 - 여러 테이블이 아닌 하나의 테이블에 정보를 저장하므로 데이터를 더 빠르게 검색할 수 있습니다.
데이터 관리의 용이성 - 계산된 속성을 도입하는 것이 이러한 기술의 한 예입니다.
리포팅의 용이성 - 경우에 따라 관련 테이블을 검색해야 하는 경우 리포팅이 악몽이 될 수 있습니다. 비정규화를 통해 훨씬 더 빠르게 보고서를 생성할 수 있습니다.
