이러한 데이터베이스 디자인 스타일 (또는 안티 패턴)에는 이름이 있습니까?

Question

제품 및 직원 테이블이있는 데이터베이스를 고려하십시오. 현재 제품 관리자를 모델링하는 새로운 요구 사항이 있습니다. 이는 제품 책임자 중 하나인데 일부 제품은 제품 관리자가 필요하지 않을 정도로 간단하거나 성숙한 제품입니다. 즉, 각 제품에는 0 개 또는 하나의 제품 관리자가있을 수 있습니다.

접근 1 : 없음 제품 관리자와 제품이 NULL 값으로 모델링되도록 변경 테이블 Product 새로운 NULL 수 열 product_manager_employee_ID를 추가 할 수 있습니다.

접근 방법 2 : 없음 제품 관리자와 제품이이 테이블의 행의 부재로 모델링되도록 product_ID에 고유 제한 조건으로, 비 NULL 수 열 product_ID 및 employee_ID로 새 테이블 ProductManagers을 만듭니다.

다른 방법이 있지만 가장 자주 만나는 두 가지 방법이 있습니다.

이들은 합법적 인 설계 선택 (믿을만한 경향이있는)이고 단순히 다른 스타일을 나타내는 것으로 가정 할 때 이름이 있습니까? 나는 접근법 2를 선호하며, 실제 사례를 사용하지 않고 접근법 1을 선호하는 사람에게 스타일의 차이를 전달하는 것을 어렵게 생각합니다. (여기서 한 것처럼!) 나는 "나는 6NF (또는 무엇이든) 스타일로 나 자신을 표현할 수 있습니다. "

실제로 이러한 패턴 중 하나가 안티 패턴이라고 가정하면 (이 엔티티 중 하나의 속성으로 두 엔티티 간의 관계를 모델링하여 접근법 1의 경우 일 수 있다고 생각하기 때문에)이 안티 패턴은 이름?

Answer 1

첫 번째는 일대 다 관계 (한 제품에서 여러 제품까지)에 불과합니다. 이것은 선택 사항이기 때문에 O : M 관계라고도합니다 (모든 제품에 제품 관리자가있는 것은 아니기 때문에). 또한 모든 직원이 제품 관리자이기 때문에 반대편에서도 선택 사항입니다.

두 번째 테이블은 일반적으로 다 대다 관계에 사용되는 조인 테이블입니다. 그러나 한 쪽은 일대일 (각 제품은 한 번만 테이블에 있습니다)이기 때문에 실제로는 복잡한 일대 다 관계입니다.

개인적으로 나는 첫 번째 것을 선호하지만 둘 다 잘못되었습니다 (또는 나쁘다).

두 번째는 염두에 두 가지 이유로 사용됩니다.

1. 제품에 둘 이상의 관리자가있을 가능성이 있습니다. 또는
2. 제품 관리자가 제품에 대한 내역을 추적하려고합니다. 이것을 수행하면 current_flag 열이 'Y'(또는 유사)로 설정되어 한 번에 하나씩 만 현재 상태가 될 수 있습니다. 이것은 실제로 데이터베이스 중심 애플리케이션에서 꽤 흔한 패턴입니다.

Answer 2

두 가지 모델의 동작이 다른 것처럼 보입니다. 첫 번째 예에서는 제품 당 하나의 제품 관리자를 둘 수 있고 한 명의 직원은 두 개 이상의 제품 (일대 다)에 대한 제품 관리자가 될 수 있습니다. 두 번째 제품에는 제품 당 둘 이상의 제품 관리자가 허용됩니다 (대다수). 이것은 두 가지 솔루션이 서로 다른 상황에서 동등하게 유효하며 비즈니스 규칙에 따라 사용할 수있는 솔루션을 제안합니다.

Answer 3

첫 번째 방법에는 결함이 있습니다. 잠시 동안 비즈니스 요구 사항이 변경되었고 이제는 2 개의 제품 관리자를 제품으로 설정할 수 있어야한다고 상상해보십시오. 너는 무엇을 할 것인가?Product 테이블에 다른 열을 추가 하시겠습니까? 왝. 이것은 분명히 1NF를 위반합니다.

또 다른 옵션은 특정 제품 관리자 < -> 제품 관계에 대한 일부 속성을 저장할 수있는 옵션입니다. 마찬가지로 제품에 대해 두 명의 제품 관리자가있는 경우 그 중 하나를 기본 제품으로 설정할 수 있습니다. 또는 예를 들어 직원이 전화 번호를 가질 수 있지만 제품 관리자는 다른 전화 번호 ... 이것은 또한 특별 테이블로 이동합니다.

Answer 4

접근 1)

1. 모든 데이터베이스에 있지만) 일부 어쩌면 (추가 제품 관리자 필드 Product 테이블의 사용 속도가 느려집니다.
2. Product 테이블에서 Employee 테이블로 연결하는 것은 간단합니다.

접근법 2) 제품 테이블을 사용하여

1. 기존 쿼리는 영향을받지 않습니다.
2. 데이터베이스의 크기가 커집니다. 이제 제품 ID 열을 다른 테이블에 복제 할뿐만 아니라 고유 한 제약 조건과 인덱스를 해당 테이블에 추가했습니다.
3. Product 테이블에서 Employee 테이블로 연결하는 것이 중간 테이블에 먼저 잉크를 써야하므로 비용이 많이 들고 복잡합니다.

얼마나 자주 두 테이블을 연결해야합니까?

제품 테이블을 사용하는 다른 쿼리는 얼마나됩니까?

제품 테이블의 레코드 수는 얼마입니까?

Answer 5

당신이주는 특별한 경우에, 나는 두 테이블에 대한 주된 동기가 누락 된 데이터에 대해 널을 피하는 것이고 그것이 내가 두 접근법을 특징 짓는 방법이라고 생각한다.

장단점에 대한 토론이 있습니다 on wikipedia.

나는이 날짜를 싫어할 때 관계형 이론을 정의하여 다중 테이블 솔루션 만 "유효"하다고 확신합니다. 예를 들어, 단일 테이블 접근법을 "형식이 잘못되었습니다"라고 부를 수 있습니다 (null 유형은 unclear - p4의 인용문 참조).