많은 설계가 RDBMS에서 정규화를 무시하는 이유는 무엇입니까?

의사 결정 단계에서 표준화가 첫 번째 고려 사항이 아닌 많은 디자인을 보았습니다.

대부분의 경우 이러한 설계에는 30 개가 넘는 열이 포함되었으며 주요 접근 방식은 "모든 것을 같은 장소에 두는 것"이었습니다.

내가 기억하는 것에 따르면 정규화는 가장 중요한 첫 번째 것 중 하나이므로 왜 그렇게 쉽게 떨어질까요?

편집하다:

숙련 된 건축가와 전문가가 비정규 화 된 디자인을 선택하고 경험이없는 개발자는 그 반대를 선택하는 것이 사실입니까? 정규화를 염두에두고 디자인을 시작하는 것에 대한 논쟁은 무엇입니까?

이 Q & A 스레드에서 흥미로운 점은 실제로 3 가지 질문이 있다는 것입니다. 모든 사람이 다른 질문에 대답했으며, 첫 번째 사람은 거의 아무도 대답하지 않았습니다.

1. 야생의 일부 데이터베이스가 표준화 되지 않은 이유 는 무엇 입니까?
2. 표준화 된 데이터베이스를 왜 비정규 화 해야합니까?
3. 어떤 상황 에서 처음에는 정규화 하는 것이 해롭 거나 불필요합니까?

경고 독자는이 질문들이 매우 다른 질문이라는 것을 알게 될 것이며, 세부 사항을 피하면서 각 질문에 개별적으로 답변하려고 노력할 것입니다. "너무 많이"라는 말은 이것이 정규화에 찬성하거나 반대하는 다양한 주장의 장점에 대한 확장 된 토론을 수행 할 적절한 맥락이라고 생각하지 않는다는 것을 의미합니다. 나는 그 주장이 무엇인지 설명하고, 몇 가지 경고를 나열하고, 더 구체적인 질문에 대한 철학을 구할 수 있습니다.

또한이 답변에서 "정규화"는 "BCNF, 3NF 또는 적어도 2NF"를 의미 한다고 가정합니다 . 디자이너가 일반적으로 달성하려는 정규화 수준이기 때문입니다. 4NF 또는 5NF 디자인은보기 드문 경우입니다. 그것들은 확실히 불가능한 목표는 아니지만, 단지 그들의 표현 보다는 관계 의 의미론 에 관심을 가지게되는데, 그 영역에 대해 상당히 많은 지식이 필요합니다.

따라서 앞뒤로 :

1. 왜 일부 데이터베이스가 정규화되지 않습니까?

이에 대한 대답은 수 "가되지 않을 것이기 때문"수 있지만 박쥐 그 가정의 권리를 만드는 것은 매우 애처로운 탐정 작품이다. 우리가 항상 무엇을해야한다고 가정한다면 우리는 사회로서 큰 진전을 이루지 못할 것입니다.

데이터베이스가 처음에 정규화되지 않는 실제 이유는 더 복잡합니다. 내가 만난 상위 5 개는 다음과 같습니다.

• 그것을 설계 한 개발자들은 정규화 방법을 모르 거나 이해하지 못했습니다 . 이것에 대한 강력한 증거는 모든 것에 varchar 열을 사용 하거나 의미가없는 테이블 및 열 이름 의 스파게티 엉망을 만드는 것과 같이 다른 많은 나쁜 디자인 선택의 형태로 나타납니다 . TDWTF 기사의 데이터베이스만큼 나쁜 "실제"데이터베이스를 보았습니다.

• 그것을 설계 한 개발자들은 원칙적으로 정규화에 신경 쓰지 않았 거나 적극적으로 반대했습니다 . 여기서 나는 상황 분석에 기초하여 정규화하기로 의도적 인 결정을 한 것이 아니라 정규화가 다소 이해되지만 단순히 무시되거나 습관에서 벗어난 팀이나 회사에 대해 이야기하고 있습니다. 다시, 놀랍게도 일반적입니다.

• 소프트웨어는 Brownfield 프로젝트 로 수행되었습니다 . 많은 순수 주의자들은 정규화되지 않은 기술적 이유 보다는이 합법적 인 비즈니스를 무시합니다 . 때로는 새로운 데이터베이스를 처음부터 새로 설계하지 않고 기존 레거시 스키마에 집중해야하며, 그 시점에서 정규화를 시도하면 너무 많은 고통이 따릅니다. 3NF는 1971 년까지 발명되지 않았으며 일부 시스템, 특히 재무 / 회계 시스템은 그보다 훨씬 더 뿌리를두고 있습니다!

• 데이터베이스 는 원래 정규화 되었지만 장기간에 걸쳐 작은 변경 사항이 누적되거나 광범위하게 분산 된 팀은 미묘한 복제 형식과 원래의 원래 형식에 대한 기타 위반을 도입했습니다. 다시 말해서 정규화 상실은 우연 이었고 리팩토링에 너무 적은 시간이 소요되었습니다.

• 비즈니스 분석이나 데이터베이스 디자인에 시간을 소비하지 않고 "완료"하기로 의도 한 비즈니스 결정 이 내려졌습니다. 이것은 종종 잘못된 경제이고 궁극적으로 기술 부채의 형태가되고 있지만 적어도 당시에 알려진 정보를 바탕으로 합리적인 결정이되기도합니다. 예를 들어, 데이터베이스는 프로토 타입으로 설계되었지만 결국 시간 제약이나 비즈니스 환경의 변화로 인해 프로덕션 사용으로 승격됩니다.

2. 왜 정규화 된 데이터베이스를 비정규 화해야합니까?

이 논의는 데이터베이스 가 시작되도록 정규화 될 때 종종 발생합니다 . 성능이 나쁘거나 쿼리 (조인)에 중복이 많으며, 팀은 현재 디자인에서 할 수있는 한 타당하다고 생각합니다. 정규화 는 대부분 의 경우 성능을 향상 시키며 정규화가 사용자에 대해 작동하는 것처럼 보일 때 과도한 조인을 제거하는 몇 가지 옵션 이 있으며 , 대부분 비정규 화 된 모델로 변경하는 것보다 덜 침습적이고 덜 위험합니다.

• 가장 일반적인 문제 영역을 캡슐화하는 인덱스 된 뷰를 만듭니다. 최신 DBMS는 삽입 또는 업데이트가 가능합니다 (예 : SQL Server INSTEAD OF트리거). 기본 테이블 / 인덱스의 DML 문에 약간의 비용이 발생하지만 일반적으로 시도하는 것이 거의 불가능하고 유지 보수에 거의 비용이 들지 않으므로 시도해야 할 첫 번째 옵션입니다. 물론 모든 쿼리를 인덱스 된 뷰로 변환 할 수있는 것은 아닙니다. 집계 쿼리가 가장 번거 롭습니다. 다음 항목으로 연결됩니다.

• 트리거에 의해 자동으로 업데이트되는 비정규 화 된 집계 테이블을 작성하십시오. 이 테이블 은 정규화 된 테이블 외에 존재 하며 일종의 CQRS 모델을 형성합니다 . 요즘 가장 인기있는 또 다른 CQRS 모델은 pub / sub를 사용하여 쿼리 모델을 업데이트하는 것입니다.이 모델은 비동기식의 이점을 제공하지만 데이터가 오래되지 않는 매우 드문 경우에는 적합하지 않을 수 있습니다.

• 경우에 따라 인덱싱 된 뷰를 사용할 수없고 트랜잭션 속도 및 데이터 볼륨이 너무 커서 허용 가능한 성능으로 트리거를 허용 할 수 없으며 쿼리는 항상 실시간 데이터를 반환해야합니다. 이러한 상황은 드물다-나는 그들이 고주파 거래 또는 법 집행 / 지능 데이터베이스와 같은 것들에 적용될 수 있다고 추측 할 수있다 . 그러나 그것들 은 존재할 수있다. 이 경우 원래 테이블을 비정규화할 수 밖에 없습니다.

3. 어떤 상황에서 처음에는 정규화하는 것이 해롭거나 불필요합니까?

사실 여기 몇 가지 좋은 예가 있습니다.

• 데이터베이스 가보고 / 분석 에만 사용되는 경우 일반적으로 이는 OLTP에 사용되는 정규화 된 추가 데이터베이스가 있으며 이는 ETL 또는 메시징을 통해 분석 데이터베이스와 주기적으로 동기화됩니다.

• 정규화 된 모델을 시행 할 때는 들어오는 데이터에 대한 불필요하게 복잡한 분석이 필요합니다. 예를 들어 여러 외부 시스템이나 데이터베이스에서 수집 한 전화 번호를 저장해야하는 시스템이 있습니다. 당신은 수있는 다른 로케일은 말할 것도없고, 전화 번호 및 지역 번호를 비정규 화,하지만 당신은 다른 가능한 형식, 잘못된 전화 번호, 허영 번호 (1-800-GET-STUFF)의 모든 계정에있는 것입니다. 일반적으로 가치보다 문제가 많으며 전화 번호는 지역 번호에 대한 특정 비즈니스 요구 가없는 한 일반적으로 단일 필드에 입력됩니다 .

• 관계형 데이터베이스가 주로 존재하는 경우 추가 비 관계형 데이터베이스에 대한 트랜잭션 지원을 제공합니다. 예를 들어, 관계형 데이터베이스를 메시지 큐로 사용하거나 기본 데이터가 Redis 또는 MongoDB 등에 저장 될 때 트랜잭션 또는 saga의 상태를 추적 할 수 있습니다. 즉, 데이터는 "제어 데이터"입니다. 실제로 비즈니스 데이터 가 아닌 데이터를 정규화하는 데는 아무런 의미가 없습니다 .

• 실제 데이터베이스를 공유하는 서비스 지향 아키텍처. 이것은 이상한 하나의 비트이지만, 진정한 SOA에, 당신은 것입니다 가끔 서비스를 직접 쿼리 서로의 데이터에 허용되지 않기 때문에 물리적으로 중복 데이터가 있어야합니다. 그들이 경우 발생 동일한 물리적 데이터베이스를 공유 할 데이터가됩니다 표시 정규화 할 수 없습니다 - 그러나 일반적으로, 각 개별 서비스가 소유 한 데이터가 되어 다른 완화 요소 중 하나가 제자리에 있지 않으면 여전히 정상화. 예를 들어, 청구 서비스는 청구 엔티티를 소유 할 수 있지만 회계 서비스는 청구 날짜 및 금액을 해당 연도의 수입에 포함 시키려면 수신 및 저장해야합니다.

내가 나열하지 않은 더 많은 이유가 있다고 확신합니다. 본질적으로 내가 얻는 것은 실제로 구체적이고 그들이 실제로 등장 할 때 분명해질 것이라는 점입니다. OLAP 데이터베이스가되어 가정 사용 스타 스키마로의 SOA가되어 가정 당신은 단순히 정상화 작업을하지 않는 것으로 잘 알려진 아키텍처 모델로 작업하는 경우 등 일부 중복을 가지고, 당신은 정상화하지 마십시오 일반적으로 말하면 아키텍처 모델이 데이터 모델보다 우선합니다.

그리고 마지막 질문에 대답하기 위해 :

숙련 된 건축가와 전문가가 비정규 화 된 디자인을 선택하고 경험이없는 개발자는 그 반대를 선택하는 것이 사실입니까? 정규화를 염두에두고 디자인을 시작하는 것에 대한 논쟁은 무엇입니까?

아니요, 완전하고 완벽한 BS 전문가가 항상 표준화 된 설계를 선택하는 것도 BS입니다 . 전문가들은 단지 진언을 따르지 않습니다. 연구, 분석, 토론, 설명 및 반복 한 다음 특정 상황에 가장 적합한 방법을 선택합니다.

3NF 또는 BCNF 데이터베이스는 일반적으로 전 세계 수만 개의 프로젝트에서 성공적으로 시도되고 입증되었으므로 분석을위한 좋은 출발점 이지만 C도 마찬가지입니다. 새 프로젝트. 실제 상황에서는 모델을 약간 수정하거나 다른 모델을 함께 사용해야 할 수도 있습니다. 당신이 때까지 당신은 모르는 에 그 상황.

질문에 대한 가정과 일부 대답은 정규화가 좋은 데이터베이스 디자인이라는 동의어입니다. 사실 종종 그렇지 않습니다. 정규화는 데이터 요소 간의 관계에 대해 "비즈니스 규칙"을 시행하기 위해 데이터베이스에 크게 의존하는 경우 특정 디자인 목표와 요구 사항을 달성하는 한 가지 방법입니다.

정규화는 몇 가지 주요 이점을 제공합니다.

1. 중복 데이터의 양을 최소화합니다.
2. 데이터의 무결성을 보장하기 위해 데이터베이스의 내장 무결성 메커니즘 (외부 키 제약 조건, 고유성 제약 조건)을 활용할 수있는 범위를 최대화합니다.
3. 행당 열 수를 줄이면 IO의 효율성이 향상 될 수 있습니다. 넓은 행은 검색하는 데 시간이 더 걸립니다.

즉, 비정규 화해야 할 충분한 이유가 있습니다.

1. 정규화로 인해 특히 분석의 성능이 저하 될 수 있습니다. 관계형 데이터베이스에 대한 분석의 경우 비정규 화 된 차원 모델 이 표준 접근법입니다.
2. 데이터베이스 내부에서 데이터 무결성을 강화하면 이점이 줄어들 기 시작합니다. 점점 더 많은 개발이 종종 비즈니스 규칙을 시행하는 객체 지향 중간 계층에 초점을 맞추기 때문에 데이터베이스의 관계 적 제약에 대한 의존은 덜 중요합니다.
3. 다른 사람들이 언급했듯이 정규화는 관련 데이터를 검색하는 데 필요한 쿼리를 복잡하게 만듭니다.

정규화가 좋은 디자인의 신호라는 것은 확실하지 않습니다. 경우에 따라 정규화는 스토리지 공간이 부족하고 비즈니스 규칙 인코딩에 대한 많은 책임이 데이터베이스에있는 시간의 산물입니다 (모든 비즈니스 로직이 아닌 대부분의 2 계층 클라이언트-서버 응용 프로그램에 대해 생각하십시오) 저장 프로 시저). 많은 프로젝트가 데이터베이스 설계 원칙을 제대로 이해하지 못하고 아키텍처 결정에 따라 정규화를 벗어나는 경우가 많습니다.

위의 주석에서 언급 한 Jeff Atwood의 기사는 "아마도 정규화가 정상이 아닙니다"라는 좋은 세부 토론을 제공합니다 .

1. 많은 개발자들은 정규화 나 데이터 모델링 또는 데이터베이스에 대해 알거나 신경 쓰지 않습니다.
2. 일부 작업의 경우 실제로 중요하지 않습니다.
3. 예를 들어 특정 어려운 워크로드를 제대로 수행하기 위해 정규화를 해제해야 할 이유가있을 수 있습니다.
4. 관계형 데이터베이스 개념은 최근 1990 년대와 2000 년대에 비해 유행이 떨어졌습니다. 개발자는 매우 합리적이라고 주장하더라도 패션의 영향을받는 경향이 있습니다. 맛에 대해서는 논쟁 할 필요가 없습니다.

역사적으로 정규화는 역사적으로 거의 종교적인 논쟁의 영토이므로 훨씬 더 많은 것을 말하고 싶습니다.

대규모 프로젝트, 특히 메인 프레임 프로젝트에서는 그렇지 않습니다. 실제로 구직 사이트를 검색하면 데이터 모델러에 대한 여러 위치가 표시됩니다. 또한 단일 테이블에 많은 열이 있어도 정규화되지 않습니다. 그럼에도 불구하고 귀하의 관찰은 일부 프로젝트에 유효합니다.

데이터베이스 디자인은 양질의 시스템을 구축하는 데 필요한 기술 중 하나입니다. 그러나 일부 개발자는 데이터베이스 디자인에 대해 충분히 알지 못하고 여전히 데이터 모델링 및 데이터베이스 디자인 작업에 할당됩니다. 일부 프로젝트는 데이터 모델링을 건너 뛰기도합니다. 많은 프로젝트에 중점을 둔 것은 주로 코딩 및 프론트 엔드 디자인에 있습니다.

데이터베이스 디자인이 열악한 또 다른 요인은 정규화가 4 번째 NF, 5 번째 NF 등의 경우 특별히 사소한 주제가 아니라는 사실입니다. 일반적으로 나쁜 예와 너무 많은 이론이 있습니다. 이로 인해 주제가 인기보다 덜 인기가 있습니다.

데이터베이스 디자인에서 오류를 찾아 보거나 테스트 중에 오류가 발생하지 않으면 오류가 발생하기 어렵습니다. 데이터베이스 설계 품질에 대한 표준이 없으면 오류가 발생할 가능성이 높습니다.

또한 일부 프로젝트는 엄격한 개발 방법론 (데이터베이스 설계를 촉진하는 방법)을 따르지 않으므로 비즈니스 분석가, 개발자 및 DBA간에 책임이 혼합되고 작업이 손실됩니다. 개발자는 OO와 UML에서 DBA가 DD와 ERD에서 대화하고 UML이나 OO를 얻지 못하는 경우가 있습니다. 요컨대, 지식 부족, 명확한 자원 부족, 데이터를 설명 할 통일 된 언어 부족 및 방법론 부족은 모두 책임이 있습니다.