언제 비정규 화해야합니까?

우리 모두는 데이터베이스 정규화에 익숙하다고 생각 합니다 .

내 질문은 : 테이블을 비정규 화하려는 경우 사용하는 몇 가지 지침은 무엇입니까?

OLAP 작업 인 경우 비정규 화, OLTP 인 경우 정규화 (비정규 화 섹션의 링크 된 기사에서)

온라인 트랜잭션 처리 (OLTP) 용 데이터베이스는 일반적으로 온라인 분석 처리 (OLAP) 용 데이터베이스보다 정규화됩니다. OLTP 응용 프로그램은 슈퍼마켓 계산대에서 판매 기록을 업데이트하는 것과 같이 대량의 소량 거래가 특징입니다. 각 트랜잭션은 데이터베이스를 일관된 상태로 유지해야합니다. 반대로 OLAP 작업을위한 데이터베이스는 주로 "대부분 읽기"데이터베이스입니다. OLAP 응용 프로그램은 오랜 기간 동안 축적 된 기록 데이터를 추출하는 경향이 있습니다. 이러한 데이터베이스의 경우 중복 또는 "비정규 화 된"데이터가 비즈니스 인텔리전스 응용 프로그램을 용이하게 할 수 있습니다. 특히 스타 스키마의 차원 테이블에는 비정규 화 된 데이터가 포함되는 경우가 많습니다. 추출, 변환,로드 (ETL) 처리 중에 비정규 화 된 또는 중복 데이터는 신중하게 제어해야하며, 사용자는 데이터가 일관된 상태가 될 때까지 데이터를 볼 수 없습니다. 스타 스키마의 정규화 된 대안은 눈송이 스키마입니다. 대부분의 경우 컴퓨터 및 RDBMS 소프트웨어가 더욱 강력 해짐에 따라 비정규 화의 필요성이 줄어들었지만 일반적으로 하드웨어 및 소프트웨어 성능과 함께 데이터 볼륨이 증가함에 따라 OLAP 데이터베이스는 여전히 비정규 화 된 스키마를 사용합니다.

비정규 화는 또한 컴퓨터 화 된 금전 등록기 및 모바일 장치에서와 같이 소규모 컴퓨터의 성능을 향상시키는 데 사용됩니다. 데이터 조회 만 (예 : 가격 조회) 데이터를 사용할 수 있기 때문입니다. 플랫폼 (예 : Palm)에 RDBMS가 없거나 데이터를 변경하지 않고 신속한 대응이 중요한 경우 비정규 화를 사용할 수도 있습니다.

아플 때까지 정규화하고 작동 할 때까지 비정규 화하십시오 (예 : 성능이 수용 가능해집니다) :)

제어 된 비정규 화 를 적용해야 할 가능성이있는 한 가지 이유 는 그렇지 않은 데이터에 일부 무결성 제약 조건을 적용 할 수 있기 때문입니다. 대부분의 SQL DBMS는 다중 테이블 제약 조건에 대한 지원이 극히 제한되어 있습니다. SQL에서 경우에 따라 특정 제한 조건을 구현하는 유일한 효과적인 방법은 제한 조건에 포함 된 속성이 모두 동일한 테이블에 있는지 확인하는 것입니다. 정규화가 별도의 테이블에 속한다고 지시 할 때에도 마찬가지입니다.

제어 된 비정규 화는 중복 데이터로 인해 불일치가 발생하지 않도록 메커니즘이 구현됨을 의미합니다. 비정규 화가 가치가 있는지 여부를 결정할 때 이러한 추가 관리 비용과 일관성이없는 데이터의 위험을 고려해야합니다.

비정규 화의 또 다른 일반적인 이유는 스토리지 구조의 일부 변경을 허용하거나 DBMS가 달리 허용하지 않는 다른 물리적 최적화를 허용하기위한 것입니다. 물리적 데이터 독립성 의 원칙에 따라 DBMS는 데이터베이스에서 데이터의 논리적 표현을 불필요하게 변경하지 않고 내부 스토리지 구조를 구성 할 수있는 수단을 가져야합니다. 불행히도 많은 DBMS는 주어진 데이터베이스 스키마에 사용할 수있는 물리적 구현 옵션을 매우 제한합니다. 이들은 원하는 논리적 모델의 차선 구현 만 지원함으로써 물리적 데이터베이스 독립성을 손상시키는 경향이 있습니다.

분명해야하지만 여전히 말해야합니다. 모든 경우에 내부 데이터 구조, 파일, 인덱싱, 하드웨어 등과 같은 기능-성능을 지시 할 수있는 물리적 구현 기능 만 변경됩니다. 정규화 및 비정규 화는 성능 또는 스토리지 최적화와 관련이 없습니다.

이 질문 에 대한 답변에서 제안 된 것처럼 계산 된 데이터에 자주 액세스하는 경우 비정규 화하십시오 . 계산 된 데이터를 저장하고 유지 관리하는 비용은로드 프로파일이 읽기 무거운 경우 반복해서 계산하는 비용보다 적습니다.

제약 조건으로 데이터 무결성을 강화할 수 있도록 일상적으로 비정규 화합니다. 한 예는 이 사이트의 최근 질문 입니다. 다른 테이블의 열을 복제하여 CHECK 제약 조건을 사용하여 다른 열과 비교할 수 있습니다. 이 기술의 또 다른 예는 내 블로그 게시물 입니다.

CHECK 제한 조건을 사용하여 호출 된 스칼라 UDF에서 이러한 기능을 랩핑하지 않으면 다른 행이나 다른 테이블의 열을 비교하기 위해 CHECK 제한 조건을 사용할 수 없습니다. 비즈니스 규칙을 적용하기 위해 실제로 다른 행이나 다른 테이블의 열을 비교해야하는 경우 어떻게해야합니까? 예를 들어, 의사의 근무 시간을 알고 있고 모든 약속이 근무 시간 내에 맞는지 확인하고 싶다고 가정하십시오. 물론 트리거 또는 저장 프로 시저를 사용하여이 비즈니스 규칙을 구현할 수 있지만 트리거 또는 저장 프로시 저는 모든 데이터가 깨끗하다는 100 % 보증을 제공 할 수 없습니다. 누군가가 트리거를 비활성화 또는 삭제하거나 데이터가 더러 우면 트리거를 다시 활성화하거나 다시 만드십시오. 또한 누군가가 저장 프로 시저를 무시하고 테이블을 직접 수정할 수 있습니다.

FK 및 CHECK 제약 조건 만 사용하여이 비즈니스 규칙을 구현하는 방법을 설명하겠습니다. 모든 제약 조건이 신뢰할 수있는 한 모든 데이터가 비즈니스 규칙을 충족시킬 수 있습니다.

또 다른 예는 일정 기간에 틈이없고 겹치지 않도록 강제하는 방법 입니다.