카테고리를 결정하는 상위 유형 / 하위 유형 : 완전 분리 또는 불완전 겹치기

데스크톱 컴퓨터, 랩톱, 스위치, 라우터, 휴대폰 등과 같은 IT 하드웨어를 저장하는 인벤토리 데이터베이스를 구축하고 있습니다. 모든 장치가 단일 테이블에 저장되는 수퍼 타입 ​​/ 서브 타입 패턴과 특정 정보를 사용하고 있습니다. 하위 유형 테이블에 배치됩니다. 내 딜레마는 다음 두 가지 디자인 중에서 선택합니다.

상단 다이어그램에서 모든 장치는 공통 하위 유형을 공유합니다. 예를 들어 데스크톱 컴퓨터 및 랩톱에는 Device, NetworkDevice 테이블에 레코드가 있습니다. 스위치에는 Device, NetworkDevice에 레코드가 있습니다. 라우터에는 Device, NetworkDevice, WANDevice에 레코드가 있습니다. 위치를 추적하는 모든 장치는 위치에 레코드를 갖습니다. 이 설정에 대해 생각한 몇 가지 장단점 :

• 장점 : 호스트 이름 또는 LocationID와 같은 공통 필드를 기반으로 레코드를 선택하는 것이 더 쉽습니다.
• 장점 : null 필드가 없습니다.
• 단점 : 특정 장치에 대한 CRUD 작업에 포함되어야하는 테이블은 명확하지 않으며 향후 DBA와 혼동 될 수 있습니다.

하단 다이어그램에서 모든 장치에는 고유 한 하위 유형이 있습니다 (여기에 표시되지 않은 더 많은 장치 클래스가 있음). 이 상황에서는 어떤 테이블 레코드가 삽입되거나 선택되는지가 분명합니다. 데스크톱 컴퓨터와 랩톱은 컴퓨터 등에 사용됩니다.이 설정에 대해 생각한 장단점은 다음과 같습니다.

• 장점 : 하위 유형에 대한 CRUD 작업에 어떤 테이블을 사용할지 즉시 알 수 있습니다.
• 장점 : CRUD 작업에는 하나의 테이블 만 사용해야합니다.
• 단점 : 공통 하위 유형 필드를 기반으로 레코드를 선택하려면 모든 테이블을 결합해야합니다 (예 : 호스트 이름 또는 LocationID로 검색).

두 가지 상황에서 ClassDiscriminator 필드는 삽입 할 수있는 유형을 제어하기 위해 CHECK 제약 조건과 함께 사용하기 위해 하위 유형 테이블에 배치됩니다.

더 나은 디자인에 대한 권장 사항이 있습니까, 아니면 완전히 데이터베이스의 의도 된 목적에 의존하고 있습니까?

편집 : 내가 테이블 "NetworkDevice"의 중복 특성에 관한 특정 질문. 이 표는 호스트 이름 및 / 또는 IP 주소를 가진 모든 장치 (컴퓨터, 스위치 또는 라우터)에 대한 네트워크 정보를 보유하기위한 것입니다. 이 테이블의 겹치는 특성으로 인해 문제가 발생할 수 있습니까, 아니면 이런 식으로 구현해도됩니까?

입력하신 내용에 대해 미리 감사드립니다. 추가 정보가 필요한지 문의하십시오.

데이터베이스에서 하위 유형을 실제로 구현하는 것은 복잡한 문제입니다. 강력한 이점을 제공하는 상황이 아닌 한 (아래의 하나 또는 두 개의 예 참조) 구현에 복잡성을 더 해주면서 상대적으로 적은 가치를 제공합니다.

정말 복잡한 하위 유형 (법원 사건 관리 시스템의 응용 프로그램 및 문장, 이질적인 복합 보험 계약 구조) 으로이 작업을 수행 한 결과 이것에 대해 약간의 관찰이 있다고 생각합니다. 몇 가지 중요한 경우는 다음과 같습니다.

• 하위 유형에 대한 데이터베이스 필드의 총 수가 상대적으로 적거나 (예 : 100 미만) 하위 유형간에 공통점이있는 경우 하위 유형을 별도의 실제 테이블로 분리하는 것은 가치가 거의 없습니다. 보고 쿼리 및 검색에 상당한 오버 헤드가 추가됩니다. 대부분의 경우 단일 테이블을 갖고 응용 프로그램 내에서 하위 유형을 관리하는 것이 가장 좋습니다. (아마도 문제에 가장 가깝습니다)

• 하위 유형이 매우 분리되어 있고 다른 하위 유형에 유형 종속 데이터 구조가있는 경우 (예 : 하위 테이블 또는 더 복잡한 구조) 하위 유형 테이블이 의미가 있습니다. 이 경우, 각 하위 유형은 아마도 응용 프로그램 내에서 공통성이 거의 없을 것입니다 (즉, 응용 프로그램 내에 해당 하위 유형 전용의 전체 서브 시스템이있을 수 있습니다). 대부분의보고 및 쿼리는 주어진 하위 유형 내에서 발생할 수 있으며 교차 유형 쿼리는 주로 소수의 공통 필드로 제한됩니다. (법원 관리 시스템)

• 서로 다른 속성을 가진 많은 수의 하위 유형이 있거나이를 구성 가능하게하는 요구 사항이있는 경우 일반적인 구조와 추가 메타 데이터가 더 적합 할 수 있습니다. 몇 가지 가능한 접근 방식에 대한 요약 은 이 SO 게시물 을 참조하십시오 . (보험 정책 관리 시스템)

• 하위 유형에 공통점이 거의없고 하위 유형 테이블에 대해 쿼리 할 필요가 거의없는 필드가 매우 많은 경우 (즉, 하위 유형 테이블에 대한 다 방향 외부 조인 방식에는 별다른 영향이 없음) 유형 테이블은 열 스프롤을 관리하는 데 도움이 될 수 있습니다. (병리 적으로 복잡한 버전의 문제)

• 일부 O / R 맵퍼는 하위 클래스 관리에 대한 특정 접근 방식 만 지원할 수 있습니다.

대부분의 경우 DB 스키마의 물리적 하위 유형 테이블은 잠재적으로 바람직하지 않은 부작용이 있기 때문에 문제를 찾는 데 약간의 솔루션입니다.

귀하의 경우에는 비교적 적은 수의 하위 유형과 관리 가능한 수의 속성이 있다고 가정합니다. 다이어그램과 질문에는 자식 테이블을 레코드에서 끊으려는 의도가 표시되지 않습니다. 위에서 제안한 첫 번째 옵션을 사용하여 하나의 테이블을 유지 관리하고 응용 프로그램 내에서 하위 유형을 관리하는 것이 좋습니다.

먼저 David Hay의 저서 인 Enterprise Model Patterns 에있는 데이터 모델링 분류 계층 규칙을 사용하여 건전한 논리 데이터 모델을 개발해보십시오 . 분류 계층을 만들 때 각 항목 (행)은 하나의 하위 유형이어야합니다. 이는 하위 유형이 상호 배타적임을 의미합니다. 분류는 하나의 기본적이고 변하지 않는 특성을 기반으로해야합니다. 이 기본 규칙을 사용하면 모델에 많은 명확성이 제공됩니다. 보유하고있는 모델에서 분류 할 단일 특성은 장치 (전화, 네트워크 스위치, 컴퓨터, 라우터 등)의 목적입니다. 각 장치는 이러한 유형 중 하나만 있어야합니다. 예를 들어 location은 하위 유형이 아닙니다. IP 주소와 같은 속성은 수퍼 유형에 속합니다.

다른 답변에서 언급했듯이 장치 유형의 수가 EAV 패턴을 보장하기에 충분히 클 것이라고 생각합니다. 내가 참조하는 David Hay 책은이 패턴을 매우 효과적으로 다루고 있습니다. 그러나 하위 유형의 수가 적 으면 널 입력 가능 열이 많은 수퍼 유형 테이블 만, 열이 중복 된 하위 유형 테이블 만 또는 둘 다 구현하도록 결정하는 경험이 있습니다. 각 하위 유형의 속성이 크게 다르고 수퍼 유형 레벨에서 관계가없는 경우 하위 유형 테이블 만 사용할 수 있습니다. 반대의 경우, 수퍼 유형 테이블 만 사용할 수 있습니다. 믹스가 있으면 둘 다 구현하십시오.

마지막으로 항상 EAV 패턴을 기본 테이블 스키마로 구현 한 다음 애플리케이션에 데이터를 수퍼 및 서브 타입 테이블로 제공하는보기 추상화 계층을 작성할 수 있습니다. 이를 통해 스토리지 계층에는 유연성이 있지만 응용 프로그램보기 계층에는 이해가 가능합니다.

제품은 재고가 아닙니다. 재고와 제품은 서로 다릅니다.

제품은 실제 제품이 아니라 제품 사양입니다.

물리적 인 것은 회사가 소유하거나 저장하는 자산입니다. 일련 번호로 추적하는 자산 (이산 자산) 또는 수량으로 만 추적하는 자산 (인벤토리 자산)을 가질 수 있습니다.

Silverston의 Data Model Resource Book Vol 1을 살펴 보겠습니다. 그는 자랑 스러움, 기능, 가격, 인벤토리에 대한 훌륭한 스키마를 가지고 있습니다. 시간을 많이 절약 할 수 있습니다.

내가 묻는 질문 중 하나는 왜 재고 품목의 다양한 속성을 추적하는 것입니까? -또는 더 구체적으로, 이 속성 정보로 무엇을하고 있습니까?

특정 속성에 특정한 의미를 갖는 많은 보고서 나 양식이있는 경우 ConcernedOfTunbridgeWell에서 권장하는 접근 방식을 사용해야합니다. 반면에 이러한 속성을 나열하기 위해 또는 유사한 장치의 유사한 속성과 비교하기 위해 이러한 속성을 기록하는 경우 실제로는 EAV를 사용하는 데 대한 (예시) 좋은 변명이있을 수 있습니다. 특정 애플리케이션에 문제가 발생하지 않는 매우 드문 경우를 제외하고는 여러 가지 이유로 "EAV는 순수한 악"이라는 것을 알고 있습니다. 당신 은 그런 응용 프로그램 일 수 있습니다.

a의 디자인에 대한이 답변에서보세요 장치 인벤토리 시스템 과의 디자인에 대한이 답변 제품 카탈로그 시스템 EAV의 접근 방식은 EAV의 위험이 정확히 무엇인지에 대한 논의와 방법에 따라 응용 프로그램을 단순화하는 방법을 볼 수 이러한 위험이 특정 적용에 적용되지 않을 수 있는지 판단하십시오.