이런 종류의 역정규화를 한 단계 더 진행할 수도 있다. 예를 들어 데이터 웨어하우스 시스템에서는 고객 이름으로 청구서 정보를 많이 검색한다는 사실을 알았다면, Invoices 테이블에 CustomerID뿐만 아니라 고객 이름도 저장하고 인덱스까지 만들어 놓으면 좋을 것이다. 물론 이렇게 하면 한 테이블에 여러 주제(청구서와 고객)와 관련된 정보를 저장하고, 고객 이름을 많은 로우에 반복해서 저장하므로 정규화 규칙을 위반하게 된다. 하지만 데이터 웨어하우스 시스템의 주 목적은 정보를 신속하고 쉽게 찾는 것이므로, 고객 이름 정보를 가져올 때 조인을 피할 수 있다면 엄청난 자원을 절약하는 효과를 볼 수 있다.

또 다른 일반적 접근 방법은 다른 테이블을 가리키는 필드를 추가하는 것이다. 이렇게 하면 성능이 향상될 뿐만 아니라 이력 정보를 관리하는 데도 도움이 된다. 완전히 정규화된 스키마는 보통 현재 상태만 보여 준다. 고객의 현 주소는 Customers 테이블에 저장되어 있다. 고객이 이사하면 이전 주소가 새 주소로 바뀐다. 고객의 주소 이력 정보를 관리하지 않는다면 나중에 이전 청구서의 정확한 사본을 출력하기는 불가능하다. 하지만 Invoices 테이블에 청구한 시점의 고객 주소 정보를 복사해 보관한다면 정확한 청구서 정보를 가져올 수 있다.