데이터 모델링 - 왜 플랫 테이블이 아닌가?

Question

프로그래밍에 익숙하지 않은 동료와 함께 일하고 있는데 ORM (및 SRP)의 개념을 설명하려고하지만 어떻게 든 실패합니다. 이것은 레일 애플 리케이션입니다.

내가에서 일하고 있어요 응용 프로그램의 클래스 계층 구조는 다음과 같이 진행됩니다

-CallFlow
- 루트 (다형성)
--- RouteOptions

속성이 다양한 특정있다 경로 및 각 RouteType에는 자체 옵션 집합이 있습니다. 이상적으로 나에게 call_flows를위한 테이블, 각각의 라우트 타입을위한 테이블, 옵션을 가진 라우트 타입, 그 라우트 타입을위한 옵션 테이블이있을 것이다. 정말 거친 모형 :

Simple_route 및 outbound_route에는 옵션이 없습니다. 옵션이있는 경로 중에서 has_many 관계로, 해당 경로에 대한 옵션 배열을 제공합니다.

반대로 동료는 각 경로의 모든 필드를 call_flows 테이블에 지정하려고합니다.

그래서 당신은 모든 레코드에 적용되지 않는 필드를 하나 개의 큰 call_flows 테이블을했을 : 이것은 해당 모드의 모형입니다. 사실 소수의 의지 만 있습니다. 내 모델링 결정의 뒤에 나의 추론은 다음과 같습니다

• 그것은 그것은 null 값의 양, 따라서 데시벨 크기를 줄일 수
• 기본 정규화 패턴을 다음과
• 는
• 그것은 기본 SRP 원칙을 다음으로 변경하는 것이 더 유연

나는 무엇이 있습니까? 새 프로그래머가 DB 정규화의 중요성을 이해하는 데 도움이되는 리소스가 있으면 좋을 것입니다.

감사합니다.

Answer 1

정규화의 핵심 개념은 Data Dependency 대 Functional Dependency입니다. 정규화 된 스키마에서 종속성은 비즈니스 또는 데이터의 의미에 의해 결정되는 기능 종속성입니다. 예를 들어 RouteOptions은 Route에 종속됩니다.

정규화되지 않은 테이블에서는 모든 데이터가 모든 위치에 저장되므로 데이터 종속성과 기능 종속성이 있습니다. 이러한 경우 트랜잭션을 실행하는 것이 매우 어렵고 데이터 모델이 일관성이 있다는 것을 100 % 확신 할 수 있습니다.

예를 들어 보겠습니다. 새로운 경로 옵션을 추가하려고합니다. 이것은 귀하의 거래입니다. 정규화 된 테이블에서 RouteOption 테이블에 새 레코드를 만들고 같은 레코드에서 Route_ID를 채 웁니다. 트랜잭션 후 데이터 모델이 일관성이 있다는 것을 100 % 확신합니다.

정규화되지 않은 스키마를 사용하면 동일한 RoutOption Table과 여러 테이블의 열이있는 RouteSummary 테이블이 있다고 가정합니다. 이 스키마에서 위의 트랜잭션을 실행하면 데이터 모델이 일관성이 없습니다. RouteSummary 테이블을 업데이트하려면 "기억"해야합니다. 며칠 후 RouteOption이있는 다른 테이블이 만들어집니다. 기존 트랜잭션은이 새로운 테이블을 알 수 없습니다.

정규화되지 않은 스키마도 있습니다. 데이터 저장소가 트랜잭션이 아닌 경우입니다. 분석 목적으로 주로 사용되는 ReadOnly 스키마 인 경우 트랜잭션이 없으므로 일관성없는 데이터의 위험이 없습니다. 그러므로 그들은 유스 케이스에서는 괜찮습니다.

Answer 2

나는 추가로 * _options 테이블을 가짐으로써 얻을 수있는 것을 정말로 이해하지 못합니다. 나는. 여기에 들어가서 그저 길의 유형에 대한 테이블에 들어갈 수 없었던 것.

다른 루트 유형, 옵션 등으로 설명하는 복잡한 구조의 일종은 NoSQL, 스키마가없는 저장소 접근 방식에 훨씬 더 도움이 될 것입니다. 이 경우 각 특성, 옵션 등에 대해 고유 한 구조를 가질 수있는 라우트 콜렉션을 가질 수 있습니다.

Answer 3

귀하의 사례는 "일반화 특성화"라고하는 디자인 패턴의 인스턴스 또는 간략하게 Gen- 스펙과 유사합니다. 데이터베이스 테이블을 사용하여 gen-spec을 모델링하는 방법에 대한 질문은 항상 SO에서 올 수 있습니다.

Java와 같은 OOPL에서 gen-spec을 모델링하는 경우 하위 클래스 상속 기능을 사용하여 세부 사항을 처리 할 수 ​​있습니다. 일반화 된 객체를 처리하도록 클래스를 정의한 다음 각 하위 클래스가 상위 상위 클래스를 확장하여 하위 클래스의 모음을 정의하면됩니다. 쉽고 간단합니다.

불행히도 관계형 데이터 모델에는 하위 클래스 상속 기능이 내장되어 있지 않으며 SQL 데이터베이스 시스템은 이러한 지식을 제공하지 않습니다. 하지만 너는 운이 좋지 않아. 테이블을 디자인하여 OOP의 클래스 구조와 유사한 방식으로 gen-spec을 모델링 할 수 있습니다. 그런 다음 새 항목이 일반화 된 클래스에 추가되면 고유 한 상속 메커니즘을 구현해야합니다. 세부 사항은 다음과 같습니다.

Martin Fowler 상속을 모방 한 세 가지 테이블 디자인을 식별합니다. 네가 좋아하는 디자인은 파울러가 Class Table Inheritance라고 부르는 디자인에 가깝다. 동료가 선호하는 디자인은 새벽 전화 Single Table Inheritance에 가깝습니다. 각각에는 그것의 이득 및 결점이있다.

클래스 테이블 상속의 흥미로운 부분을 공유 기본 키라고합니다. 여기, 하위 클래스 테이블에는 이중 의무를 수행하는 키가 있습니다. 이것은 기본 키이고 또한 수퍼 클래스 테이블에 대한 외래 키 참조입니다. 새로운 항목이 만들어지면 응용 프로그램에서 수퍼 클래스 테이블의 키 값을 적절한 하위 클래스 테이블로 전파해야합니다.

부드러운 부분은 데이터를 다시 결합해야 할 때 발생합니다. 공유 기본 키 기반의 가입은 매끄럽고 쉽고 빠릅니다.