데이터베이스를 얼마나 정규화해야 하는지 어떻게 결정합니까?

https://stackoverflow.com/questions/47711

09-06-2019
|

문제

데이터베이스 구조를 생성할 때 따라야 할 좋은 지침이나 데이터베이스를 어느 정도 정규화해야 하는지 결정하는 좋은 방법은 무엇입니까?정규화되지 않은 데이터베이스를 생성하고 프로젝트가 진행됨에 따라 분리해야 합니까?완전히 정규화된 테이블을 생성하고 성능을 위해 필요에 따라 테이블을 결합해야 합니까?

해결책

최대 3차 정규형까지 정규화된 데이터베이스 설계를 시작하려고 합니다.비즈니스 로직 레이어를 개발하면서 약간 비정규화해야 한다고 결정할 수도 있지만 절대, 절대 3번째 형태 아래로 가세요.항상 1차 및 2차 양식을 준수하세요.성능이 아닌 코드 단순성을 위해 비정규화를 원합니다.이를 위해 인덱스와 저장 프로시저를 사용하세요 :)

"진행하면서 정규화"하지 않는 이유는 데이터베이스 디자인을 수정할 때마다 이미 작성한 코드를 수정해야 하기 때문입니다.

몇 가지 좋은 기사가 있습니다:

http://www.agiledata.org/essays/dataNormalization.html

다른 팁

@GrizzlyGuru 한 현명한 사람이 나에게 "아플 때까지 정규화하고, 작동할 때까지 비정규화"라고 말한 적이 있습니다.

아직 실패하지 않았습니다 :)

나는 정규화되지 않은 형식으로 시작하는 것에 동의하지 않습니다. 그러나 내 경험상 더 정규화된 데이터베이스보다 덜 정규화된 데이터베이스를 처리하도록 애플리케이션을 조정하는 것이 더 쉬웠습니다.또한 "충분히" 작동하여 정규화할 수 없는 상황이 발생할 수도 있습니다(너무 늦을 때까지!).

정규화는 중복된 데이터를 제거하는 것을 의미합니다.즉, 비정규화 또는 비정규화된 데이터베이스는 동일한 정보가 여러 다른 위치에서 반복되는 데이터베이스입니다.이는 어디에서나 동일한 데이터를 업데이트하려면 더 복잡한 업데이트 문을 작성해야 함을 의미합니다. 그렇지 않으면 일관성 없는 데이터가 발생하여 결과적으로 쿼리 출력을 신뢰할 수 없게 됩니다.

이것은 꽤 큰 문제이므로 비정규화가 해롭다고 말하고 싶습니다. 반대의 경우는 아닙니다.

어떤 경우에는 데이터 업데이트에 따른 추가 작업과 데이터 손상 위험보다 이점이 더 크다고 판단되면 의도적으로 데이터베이스의 특정 부분을 비정규화하기로 결정할 수도 있습니다.예를 들어 성능상의 이유로 데이터가 집계되는 데이터웨어 하우스와 초기 입력 후 데이터가 자주 업데이트되지 않아 불일치 위험이 줄어드는 경우가 있습니다.

그러나 일반적으로 성능을 위해 비정규화하는 데 지치십시오.예를 들어, 비정규화된 조인의 성능 이점은 일반적으로 다음을 사용하여 얻을 수 있습니다. 구체화된 뷰 (라고도 함 인덱싱된 뷰), 이는 비정규화된 테이블을 쿼리하는 것만큼 빠르지만 여전히 데이터의 일관성을 보호합니다.

Jeff는 자신의 블로그에서 자신의 철학에 대한 매우 훌륭한 개요를 제공합니다. 어쩌면 정규화가 정상이 아닐 수도 있습니다..가장 중요한 것은 다음과 같습니다.정규화를 과도하게 사용하지 마십시오.하지만 제 생각에 더 중요한 점은 그것이 그다지 중요하지 않을 수도 있다는 것입니다.차세대 Google을 실행하지 않는 한 애플리케이션이 성장할 때까지 큰 차이를 느끼지 못할 것입니다.

데이터베이스 정규화는 예술 형식이라고 생각합니다.

테이블이 너무 많아지고 간단한 개체에 대한 쿼리도 필요한 것보다 오래 걸리기 때문에 데이터베이스를 과도하게 정규화하고 싶지는 않습니다.

제가 따르는 좋은 경험 법칙은 동일한 정보가 반복해서 정규화되는 것입니다.

예를 들어 연락처 관리 애플리케이션을 만드는 경우 주소(거리, 도시, 주, 우편번호 등)가 있어야 합니다..)를 자체 테이블로 사용합니다.

그러나 비즈니스 또는 개인의 2가지 유형의 연락처만 있는 경우 2개만 가질 예정이라면 연락처 유형 테이블이 필요합니까?나에게는 그렇지 않습니다.

먼저 필요한 데이터 유형을 파악하는 것부터 시작하겠습니다.Visio처럼 모델링 프로그램을 사용하면 도움이 됩니다.결국 정규화하게 되므로 정규화되지 않은 데이터베이스로 시작하고 싶지 않습니다.반복되는 데이터를 볼 때 해당 데이터를 새 테이블로 가져가면 논리적 그룹에 개체를 배치하는 것부터 시작합니다.나는 당신이 데이터베이스를 설계했다고 느낄 때까지 그 과정을 계속 따라갈 것입니다.

테이블을 결합해야 하는지 테스트를 통해 알려드립니다.잘 작성된 쿼리는 모든 과잉 정규화를 다룰 수 있습니다.

나는 정규화되지 않은 데이터베이스로 시작하여 진행하면서 정규화된 데이터베이스로 이동하는 것이 일반적으로 시작하기 가장 쉽다고 믿습니다.얼마나 정상화해야 하는지에 대한 질문에 대해 내 철학은 상처가 나기 시작할 때까지 정상화하는 것입니다.약간 경솔하게 들릴 수도 있지만 일반적으로 얼마나 멀리까지 갈 수 있는지 측정하는 좋은 방법입니다.

표준화된 데이터베이스를 사용하면 유연성이 가장 뛰어나고 유지 관리가 가장 쉽습니다.나는 항상 정규화된 데이터베이스로 시작한 다음 해결이 필요한 실제 문제가 있을 때만 정규화를 해제합니다.

나는 이것을 코드 성능과 유사하게 봅니다.유지 관리가 가능하고 유연한 코드를 작성하고 성능을 타협하세요. 알다 성능에 문제가 있다는 거죠.

원본 포스터에는 데이터베이스가 어떤 상황에서 사용될 것인지 설명된 적이 없습니다.어느 시점에서 일부 프런트 엔드에 대한 데이터 처리 큐브(OLAP)가 필요한 모든 유형의 데이터 웨어하우징 프로젝트인 경우, 조사하는 것보다 스타 스키마(팩트 테이블 + 차원)로 시작하는 것이 더 현명할 것입니다. 표준화.이 경우에는 Kimball 서적이 큰 도움이 될 것입니다.

나는 일반적으로 정규화된 DB로 시작한 다음 매우 구체적인 문제를 해결하기 위해 비정규화하는 것이 더 낫다는 데 동의합니다. Boyce-Codd 정규형 제3정규형 대신

진실은 "그것은 의존한다"는 것입니다. 그것은 다음과 같은 많은 요소에 달려 있습니다.

코드(수작업으로 코딩하거나 도구 기반(예: ETL 패키지))
주요 애플리케이션(트랜잭션 처리, 데이터 웨어하우징, 보고)
데이터베이스 유형(MySQL, DB/2, Oracle, Netezza 등)
데이터베이스 아키텍처(테이블 형식, 열 형식)
DBA 품질(선제적, 반응적, 비활성)
예상 데이터 품질(애플리케이션 수준 또는 데이터베이스 수준에서 데이터 품질을 강화하시겠습니까?)

가능한 한 많이 정규화하고 성능에 꼭 필요한 경우에만 비정규화해야 한다는 점에 동의합니다.그리고 구체화된 뷰나 캐싱 체계에서는 이것이 필요하지 않은 경우가 많습니다.

염두에 두어야 할 점은 모델을 정규화하면 불완전하게 정규화된 모델에서 발생할 수 있는 업데이트 예외의 위험을 제거할 수 있도록 데이터를 제한하는 방법에 대한 더 많은 정보를 데이터베이스에 제공한다는 것입니다.

비정규화하는 경우 업데이트 예외 사항이 발생할 수 있다는 사실을 감수하거나 애플리케이션 코드에서 제약 조건 유효성 검사를 직접 구현해야 합니다.이렇게 하면 이러한 제약 조건을 선언적으로 정의할 수 있는 DBMS 사용의 많은 이점이 사라집니다.

따라서 동일한 품질의 코드를 가정하면 비정규화는 실제로 더 나은 성능을 제공하지 못할 수도 있습니다.

또 다른 언급할 점은 요즘 하드웨어 가격이 저렴하기 때문에 문제에 추가 처리 능력을 적용하는 것이 손상된 데이터를 정리하는 데 드는 잠재적인 비용을 감수하는 것보다 비용 효율적이라는 것입니다.

다른 소프트웨어에서 허용하는 한 정규화하면 작업이 완료되는 경우가 많습니다.

예를 들어 객체 관계형 매핑 기술을 사용하면 다양한 다대일 및 다대다 관계에 대한 풍부한 의미 체계 세트를 갖게 됩니다.내부적으로는 효과적으로 2개의 기본 키가 있는 조인 테이블을 제공합니다.상대적으로 드물긴 하지만, 진정한 정규화는 종종 3개 이상의 기본 키와의 관계를 제공합니다.이런 경우에는 다양한 DB 이상 현상을 피하기 위해 O/R을 고수하고 자체 코드를 롤링하는 것을 선호합니다.

상식을 사용하려고 노력하십시오.

또한 어떤 사람들은 보고 관련 쿼리를 제외하고 대부분의 쿼리에서 6개(마법의 숫자) 테이블을 함께 조인하는 경우 약간의 비정규화를 고려할 수 있다고 말합니다.

잊지 마세요 Coding Horror에 대한 모든 데이터베이스 정규화 논쟁의 어머니 (High Scalability 블로그에 요약되어 있음)

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow