데이터베이스 1 : 1 관계를 사용하는 것이 적절한 시점이 있습니까?

나는 다른 날에 정규화에 대해 생각하고 있었고 데이터베이스에 1 : 1 관계가 있어야하는 시간을 생각할 수 없었습니다.

• Name:SSN? 나는 그것들을 같은 테이블에 넣을 것입니다.
• PersonID:AddressID? 다시 같은 테이블.

나는 1 : many 또는 many : many (적합한 중간 테이블 포함)의 치열한 예제를 만들 수 있지만 결코 1 : 1은 아닙니다.

분명한 것이 빠져 있습니까?

1 : 1 관계는 일반적으로 어떤 이유로 더 큰 엔터티를 분할했음을 나타냅니다. 실제 스키마의 성능상의 이유로 인해 종종 발생하지만 많은 양의 데이터 청크가 동시에 "알 수없는"것으로 예상되는 경우 논리 측면에서도 발생할 수 있습니다 (이 경우 1 : 0 또는 1 : 1이지만 더 이상은 없습니다.

논리 파티션의 예 : 직원에 대한 데이터가 있지만 건강 보험을 갖도록 선택한 경우에만 수집해야하는 더 큰 데이터 세트가 있습니다. 더 쉬운 보안 파티셔닝을 제공하고 보험과 관련이없는 쿼리에서 데이터를 가져 가지 않도록하기 위해 건강 보험 관련 인구 통계 데이터를 다른 테이블에 보관하려고합니다.

물리적 파티션의 예는 여러 서버에서 호스팅되는 동일한 데이터입니다. 의료 보험 적용 인구 통계 데이터를 다른 상태 (예 : HR 사무소)에 유지하고 기본 데이터베이스는 연결된 서버를 통해서만 연결할 수 있습니다. 민감한 데이터는 다른 위치로 복제되지는 않지만 데이터를 다른 위치로 복제 할 수는 없습니다. (드문 가정) 필요한 쿼리.

물리적 분할은 더 큰 엔터티의 일관된 하위 집합이 필요한 쿼리가 있을 때 유용 할 수 있습니다.

한 가지 이유는 데이터베이스 효율성입니다. 1 : 1 관계가 있으면 행 / 테이블 잠금 중에 영향을받는 필드를 분할 할 수 있습니다. 테이블 A에 많은 양의 업데이트가 있고 테이블 b에 많은 양의 읽기가 있거나 (또는 ​​다른 응용 프로그램에서 많은 양의 업데이트가있는 경우) 테이블 A의 잠금은 표 B에서 진행중인 작업에 영향을 미치지 않습니다.

다른 사람들은 좋은 지적을합니다. 응용 프로그램 등이 시스템에 어떤 영향을 미치는지에 따라 보안이 적절한 이유 일 수도 있습니다. 다른 접근법을 사용하는 경향이 있지만 특정 데이터에 대한 액세스를 제한하는 쉬운 방법이 될 수 있습니다. 핀치로 특정 테이블에 대한 액세스를 거부하는 것은 정말 쉽습니다.

그것에 대한 내 블로그 항목.

Sparseness. 데이터 관계는 기술적으로 1 : 1 일 수 있지만 해당 행이 모든 행에 존재할 필요는 없습니다. 따라서 2 천만 개의 행이 있고 그 중 0.5 %에 대해서만 존재하는 값 집합이있는 경우, 열을 드문 드문 채울 수있는 테이블로 밀어 넣으면 공간 절약 효과가 엄청납니다.

순위가 높은 대부분의 답변은 1 : 1 관계에 대해 매우 유용한 데이터베이스 조정 및 최적화 이유를 제공하지만 1 : 1 관계가 자연스럽게 발생하는 "야생적인"예에만 초점을 맞추고 싶습니다.

이러한 대부분의 예에서 데이터베이스 구현의 한 가지 중요한 특성에 유의하십시오. 1 : 1 관계에 대한 기록 정보는 유지되지 않습니다. 즉, 이러한 관계는 특정 시점에서 1 : 1입니다. 데이터베이스 설계자가 시간이 지남에 따라 관계 참여자의 변경 사항을 기록하려는 경우 관계는 1 : M 또는 M : M이됩니다. 그들은 1 : 1의 본성을 잃습니다. 이해가되면 여기에 간다 :

• "Is-A"또는 상위 유형 / 하위 유형 또는 상속 / 분류 관계:이 범주는 한 엔티티가 다른 엔티티의 특정 유형 인 경우입니다. 예를 들어, 모든 직원에게 적용되는 속성을 가진 직원 엔터티가있을 수 있으며 그 다음에 다른 직원으로 인해 직원 유형에 고유 한 속성을 가진 특정 유형의 직원 (예 : Doctor, Accountant, Pilot 등)을 나타낼 수 있습니다. 많은 직원들이 특정 하위 유형의 특수 속성을 갖지 못할 것입니다. 이 범주의 다른 예는 제품을 수퍼 타입으로, 제조 제품 및 유지 보수를 하위 유형으로 할 수 있습니다. 슈퍼 타입으로서의 동물 및 서브 타입으로서의 개 및 고양이; 객체 지향 상속 계층을 관계형 데이터베이스 (예 : 객체 관계형 모델)에 매핑하려고 할 때마다 이러한 시나리오를 나타내는 일종의 관계라는 점에 유의하십시오.

• 조직 단위에는 한 명의 보스 만있을 수 있고 한 사람은 한 명의 조직 단위의 보스 일 수있는 관리자, 의장, 회장 등과 같은 "보스"관계 . 이러한 규칙이 적용되는 경우 부서 관리자 1 명, 회사 CEO 1 명 등 1 : 1 관계가 있습니다. "보스"관계는 사람들에게만 적용되는 것은 아닙니다. 예를 들어 회사의 본사와 같이 하나의 상점 만 있거나 하나의 도시 만 국가의 수도 인 경우에도 동일한 관계가 발생합니다.

• 일부 종류의 부족한 자원 할당 , 예를 들어 한 명의 직원에게 한 번에 하나의 회사 차량 만 할당 할 수 있습니다 (예 : 트럭 트럭 당 트럭 한 대, 택시 운전 사당 택시 한 대 등). 동료가 최근에이 예를 들었습니다.

• 결혼 (적어도 일부 다처제가 불법 인 법적 관할권에서) : 한 사람은 한 번에 한 사람 만 결혼 할 수 있습니다. 회사가 직원들 사이의 결혼을 기록 할 때 1 : 1 단항 관계의 예로 사용한 교과서 에서이 예를 얻었습니다.

• 일치하는 예약 : 고유 한 예약이 이루어진 후 두 개의 개별 엔티티로 이행되는 경우. 예를 들어, 렌터카 시스템은 한 엔터티에 예약을 기록한 다음 실제 엔터티를 별도의 엔터티에 기록 할 수 있습니다. 그러한 상황은 대안 적으로 하나의 실체로 설계 될 수 있지만, 모든 예약이 이행되는 것은 아니며, 모든 임대가 예약을 요구하지는 않으며, 두 상황이 매우 일반적이기 때문에 실체를 분리하는 것이 합리적 일 수있다.

나는 역사적 정보가 기록되지 않은 경우에만 대부분의 1 : 1 관계라는 경고를 반복합니다. 따라서 직원이 조직에서 역할을 변경하거나 관리자가 다른 부서의 책임을 맡거나 직원이 차량을 재 할당하거나 누군가가 미망인과 재혼하면 관계 참가자가 변경 될 수 있습니다. 데이터베이스가 이러한 1 : 1 관계에 대한 이전 기록을 저장하지 않으면 합법적 인 1 : 1 관계로 유지됩니다. 그러나 데이터베이스에 기록 정보 (예 : 각 관계에 대한 시작 및 종료 날짜 추가)가 기록되면 거의 모두 M : M 관계로 바뀝니다.

기록 메모에는 두 가지 예외가 있습니다. 첫째, 일부 관계는 거의 변경되지 않아 기록 정보가 일반적으로 저장되지 않습니다. 예를 들어, 대부분의 IS-A 관계 (예 : 제품 유형)는 변경할 수 없습니다. 즉, 그들은 결코 바꿀 수 없습니다. 따라서, 역사적 기록 포인트는 약하다. 이들은 항상 자연스러운 1 : 1 관계로 구현됩니다. 둘째, 예약-렌탈 관계 상점은 예약 및 렌탈이 각각 자체 날짜가있는 독립된 이벤트이므로 개별적으로 날짜가 지정됩니다. 엔터티에는 시작 날짜가있는 1 : 1 관계 자체가 아닌 자체 날짜가 있으므로 기록 정보가 저장되어 있어도 1 : 1 관계로 유지됩니다.

당신의 질문은 당신이 말한 방식 때문에 여러 가지 방식으로 해석 될 수 있습니다. 응답은 이것을 보여줍니다.

실제 데이터 항목 간에는 1 : 1 관계가있을 수 있습니다. 그것에 대해 의문의 여지가 없습니다. "is"관계는 일반적으로 일대일입니다. 자동차는 차량입니다. 1 대의 차는 1 대의 차입니다. 한 대의 차량이 한 대의 차량 일 수 있습니다. 일부 차량은 트럭이며,이 경우 한 차량은 자동차가 아닙니다. 이 해석에 대한 몇 가지 답변이 있습니다.

그러나 당신이 정말로 요구하는 것은 ... 1 : 1 관계가 존재할 때 테이블이 분할되어야 하는가? 다시 말해, 정확히 동일한 키를 포함하는 두 개의 테이블이 있어야합니까? 실제로 우리 대부분은 다른 후보 키가 아닌 기본 키만 분석하지만 그 질문은 약간 다릅니다.

1NF, 2NF 및 3NF에 대한 정규화 규칙은 동일한 기본 키를 사용하여 테이블을 두 개의 테이블로 분해 (분할) 할 필요가 없습니다. BCNF, 4NF 또는 5NF에 스키마를 넣을 때 동일한 키를 가진 두 개의 테이블이 생길 수 있는지 여부는 해결하지 못했습니다. 내 머리 꼭대기에서 나는 대답이 '아니오'라고 추측 할 것입니다.

6NF라는 정규화 수준이 있습니다. 6NF에 대한 정규화 규칙은 동일한 기본 키를 가진 두 개의 테이블을 생성 할 수 있습니다. 6NF는 NULL을 완전히 피할 수 있다는 5NF에 비해 이점이 있습니다. 이것은 데이터베이스 설계자 모두에게 중요하지만 일부는 아닙니다. 나는 6NF에 스키마를 넣는 것을 귀찮게하지 않았습니다.

6NF에서 누락 된 데이터는 일부 열에 NULL이있는 행 대신 생략 된 행으로 표시 될 수 있습니다.

테이블 분할에 대한 정규화 이외의 이유가 있습니다. 때때로 분할 테이블로 인해 성능이 향상됩니다. 일부 데이터베이스 엔진에서는 실제로 테이블을 분할하는 대신 테이블을 분할하여 동일한 성능 이점을 얻을 수 있습니다. 이를 통해 논리적 설계를 이해하기 쉽게 유지하면서 데이터베이스 엔진에 작업 속도를 높이는 데 필요한 도구를 제공 할 수 있습니다.

몇 가지 이유로 주로 사용합니다. 하나는 데이터 변경 속도의 중요한 차이입니다. 내 테이블 중 일부에는 이전 버전의 레코드를 추적하는 감사 추적이있을 수 있습니다. 감사 추적 메커니즘을 사용하여 5 개의 열을 별도의 테이블로 분할하는 10 개의 열 중 5 개 열의 이전 버전 만 추적하는 것이 더 효율적입니다. 또한 쓰기 전용 레코드 (예 : 회계 앱)가있을 수 있습니다. 실수를 한 경우 달러 금액이나 계좌를 변경할 수 없습니다. 그러면 해당 레코드를 작성하여 잘못된 레코드를 조정 한 다음 수정 항목을 작성해야합니다. 테이블을 업데이트하거나 삭제할 수 없다는 사실을 강요하는 제약이 있지만, 그 개체에 대한 속성이 몇 가지 있습니다. 그것들은 수정에 대한 제한없이 별도의 테이블에 보관됩니다. 또 다른 시간은 의료 기록 응용 프로그램입니다. 사인온 한 후에는 변경할 수없는 방문과 관련된 데이터 및 사인 오프 후 변경할 수있는 방문과 관련된 다른 데이터가 있습니다. 이 경우 데이터를 분할하고 로그 오프 할 때 잠긴 테이블에 대한 업데이트를 거부하지만 의사가 사인온하지 않은 데이터에 대한 업데이트를 허용하는 트리거를 잠긴 테이블에 트리거합니다.

또 다른 포스터는 1 : 1이 정규화되지 않는다고 언급했는데, 일부 상황, 특히 하위 유형에 대해서는 동의하지 않습니다. 직원 테이블이 있고 기본 키가 SSN이라고 가정 해보십시오 (예제입니다.이 키가 다른 키에 적합한 지 여부에 대한 토론을 저장합시다). 직원은 임시 유형 또는 영구 유형과 같이 다른 유형일 수 있으며, 영구적 일 경우 사무실 전화 번호와 같이 더 많은 필드를 채울 수 있으며 유형 = '영구적'인 경우에만 null이 아니어야합니다. 세 번째 정규 형식 데이터베이스에서 열은 직원에만 해당하는 키에만 의존해야하지만 실제로 직원과 유형에 따라 달라 지므로이 경우 1 : 1 관계는 완벽하게 정상이며 바람직합니다. 또한 일반적으로 채워지는 열이 10 개인 경우 지나치게 희소 한 테이블을 방지합니다.

내가 생각할 수있는 가장 일반적인 시나리오는 BLOB가있을 때입니다. 큰 이미지를 데이터베이스에 저장하려고한다고 가정 해 봅시다 (일반적으로 이미지를 저장하는 가장 좋은 방법은 아니지만 제약 조건으로 인해 더 편리합니다). 블롭이 아닌 데이터의 조회를 향상시키기 위해 일반적으로 블롭을 별도의 테이블에두기를 원합니다.

순수한 과학의 관점에서 볼 때, 그들은 쓸모가 없습니다.

실제 데이터베이스에서는 드물게 사용되는 필드를 별도의 테이블에 유지하는 것이 유용합니다.이 필드 만 사용하여 쿼리 속도를 높이려면; 자물쇠 등을 피하기 위해

보기를 사용하여 필드에 대한 액세스를 제한하는 대신 제한된 사용자를 특정 사용자 만 액세스 할 수있는 별도의 테이블에 유지하는 것이 좋습니다.

또한 상속을 사용하는 OO 모델이 있고 상속 트리가 DB에 유지되어야하는 상황을 생각할 수도 있습니다.

예를 들어, Animal에서 상속받은 Bird와 Fish 클래스가 있습니다. DB에는 Animal 클래스의 공통 필드를 포함하는 'Animal'테이블이있을 수 있으며 Animal 테이블은 Bird 테이블과 일대일 관계가 있고 Fish와 일대일 관계가 있습니다. 표.

이 경우 Bird 및 Fish 속성을 보유하기 위해 많은 Null 허용 열이 포함 된 하나의 Animal 테이블이 필요하지 않습니다. 레코드가 조류를 나타낼 때 Fish-data를 포함하는 모든 열이 NULL로 설정됩니다.

대신, Birds-table에는 Animal 테이블의 레코드와 일대일 관계가있는 레코드가 있습니다.

정보가 너무 많으면 1-1 관계도 필요합니다. 테이블의 각 레코드에는 레코드 크기 제한이 있습니다. 레코드 크기가 너무 크지 않도록 테이블이 두 개 (주 테이블에서 가장 일반적으로 쿼리되는 정보와 함께)로 분할되는 경우가 있습니다. 또한 테이블이 좁은 경우 데이터베이스를보다 효율적으로 쿼리 할 수 ​​있습니다.

또한 "실제"데이터베이스 변경보다 위험이 적고 이미 생산중인 테이블을 확장하는 방법이기도합니다. 레거시 시스템에서 1 : 1 관계를 보는 것은 종종 초기 디자인 이후 필드가 추가되었다는 좋은 지표입니다.

SQL에서는 테이블이 읽기 전용이 아닌 경우 양쪽에서 필수 인 두 테이블간에 1 : 1 관계를 시행 할 수 없습니다. 대부분의 실제적인 목적으로 SQL에서 "1 : 1"관계는 실제로 1 : 0 | 1을 의미합니다.

참조 제한 조건에서 필수 카디널리티를 지원할 수 없다는 것은 SQL의 심각한 한계 중 하나입니다. "지연 가능"제약 조건은 제약 조건이 일부 시간 동안 적용되지 않는다고 말하는 방법이기 때문에 실제로 계산되지 않습니다.

인기있는 ORM 중 하나와 함께 데이터를 사용하는 경우 개체 계층 구조와 일치하도록 테이블을 여러 테이블로 분할 할 수 있습니다.

나는 1 : 1 관계를 할 때 관계적인 이유가 아니라 체계적인 이유 때문에 완전히 관계라는 것을 알았습니다.

예를 들어, 사용자의 예약 된 측면을 1 테이블에 배치하고 사용자의 사용자 편집 가능 필드를 다른 테이블에 배치하면 해당 필드에 대한 권한에 대한 규칙을 훨씬 쉽게 작성할 수 있습니다.

그러나 이론 상으로는 1 : 1 관계가 완전히 고안되어 거의 현상에 가깝습니다. 그러나 논리적으로 데이터베이스를 추상화하는 프로그램 및 최적화가 더 쉽습니다.

대부분의 경우 누군가가 "음, 왜 1 : 1이 될 수 없는가?"라고 물을 때까지 디자인은 1 : 1로 간주됩니다. 이 일반적인 시나리오를 예상하여 서로 개념을 조기에 나누는 작업이 수행됩니다. 개인과 주소는 그렇게 긴밀하게 구속되지 않습니다. 많은 사람들이 여러 주소를 가지고 있습니다. 등등...

일반적으로 두 개의 개별 오브젝트 공간은 하나 또는 둘 모두를 곱할 수 있음을 의미합니다 (x : many). 만약 두 물체가 진정으로 1 : 1이고 심지어 철학적으로도 사실이라면 그것은 더 큰 관계입니다. 이 두 "개체"는 실제로 전체 개체의 일부입니다.

특정 시나리오에서만 필요한 확장 정보. 레거시 응용 프로그램 및 프로그래밍 언어 (예 : RPG)에서 프로그램이 테이블에 대해 컴파일되는 경우 (테이블이 변경되는 경우 프로그램을 다시 컴파일해야 함) 파일을 따라 태그를 지정하면 테이블 크기가 걱정되는 경우에도 유용 할 수 있습니다.

대부분 논리적 구조보다 물리적 인 요소입니다. 일반적으로 테이블을 세로로 분할하여 물리적 장치간에 I / O를 분할하거나 액세스 빈도가 낮은 데이터 또는 동일한 개체의 나머지 특성보다 더 안전하게 유지해야하는 데이터를 분리하는 것과 관련된 기타 쿼리 최적화를 활용합니다. (SSN, 급여 등).

1-1 관계를 규정하는 유일한 논리적 고려 사항은 특정 속성이 일부 엔티티에만 적용되는 경우입니다. 그러나 대부분의 경우 엔터티 추출을 통해 데이터를 모델링하는 더 좋고 표준화 된 방법이 있습니다.

1 : 1 관계에 대한 가장 좋은 이유는 데이터베이스 디자인의 SuperType SubType입니다. 이 모델을 기반으로 Real Estate MLS 데이터 구조를 만들었습니다. 5 개의 서로 다른 데이터 피드가있었습니다. 주거, 상업, 다가구, 호텔 및 토지.

5 개의 개별 데이터 피드 각각에 공통된 데이터가 포함 된 속성이라는 SuperType을 만들었습니다. 따라서 모든 데이터 유형에서 매우 간단한 "간단한"검색이 가능합니다.

5 개의 데이터 피드 각각에 대해 고유 한 데이터 요소를 저장하는 5 개의 개별 SubType을 작성합니다. 각 SuperType 레코드는 해당 SubType 레코드와 1 : 1 관계가있었습니다.

고객이 상세 검색을 원하면 PropertyResidential과 같은 수퍼 서브 유형을 선택해야했습니다.

제 생각에는 1 : 1 관계가 클래스 상속을 RDBMS에 매핑합니다. 공통 속성, 즉 참여 클래스 상태를 포함하는 테이블 A가 있습니다. 상속 된 각 클래스 상태는 특수 속성을 포함하는 A 테이블과 1 : 1 관계를 갖는 테이블 B와 함께 RDBMS에서 맵핑됩니다. 테이블 이름 A에는 "캐스팅"기능을 나타내는 "type"필드도 포함됩니다.

안녕 마리오

상당한 성능 이점이있는 경우 일대일 관계 테이블을 작성할 수 있습니다. 거의 사용하지 않는 필드를 별도의 테이블에 넣을 수 있습니다.

1 : 1 관계는 같은 테이블에 유지되므로 1 : 1 관계는 정규화하는 경우 실제로 의미가 없습니다.

그러나 실제 세계에서는 종종 다릅니다. 애플리케이션 인터페이스와 일치하도록 데이터를 분리 할 수 ​​있습니다.

데이터베이스에 유형이 지정된 개체가있는 경우 가능합니다.

테이블 T1에 열 C1, C2, C3…이 있고 일대일 관계가 있다고 가정하십시오. 괜찮습니다. 정규화 된 형식입니다. 이제 테이블 T2에 일대일 관계로 열 C1, C2, C3,… (이름이 다를 수 있지만 유형과 역할이 동일 함)이 있다고 가정하십시오. T1과 같은 이유로 T2도 괜찮습니다.

그러나이 경우 C1, C2, C3 ... 및 T1에서 T3으로, T2에서 T3으로 일대일 관계를 유지하는 별도의 테이블 T3에 적합합니다. C1, C2, C3에 대해 이미 하나가있는 다른 테이블이 있으면 더 적합합니다 ... 테이블 A에서 테이블 B의 여러 행으로 말하십시오. 그런 다음 T3 대신 B를 사용하고 T1에서 B 로의 일대일 관계, T2에서 B 로의 일대일 관계, A에서 B 로의 동일한 일대 다 관계.

나는 정규화가 이것에 동의하지 않는다고 생각하며, 그것은 외부의 아이디어 일 수 있습니다 : 객체 유형을 식별하고 동일한 유형의 객체를 자신의 스토리지 풀로 이동, 일부 테이블의 일대일 관계 및 일대 다 관계 다른 테이블과의 관계.

보안 목적에는 적합하지 않지만 보안 검사를 수행하는 더 좋은 방법이 있습니다. 문을 하나만 열 수있는 열쇠를 만든다고 상상해보십시오. 키가 다른 문을 열 수 있으면 경보 음이 울립니다. 본질적으로 "CitizenTable"과 "VotingTable"을 가질 수 있습니다. 투표 테이블에 저장된 후보자 1에 대한 시민 1 투표. 시민권자가 투표 테이블에 다시 나타나면 경보가되어야합니다. 우리는 후보 필드를 참조하지 않기 때문에 투표 테이블과 시민 테이블을 참조하기 때문에 이것은 일대일 관계입니다.

예:

 Citizen Table
 id = 1, citizen_name = "EvryBod"
 id = 2, citizen_name = "Lesly"
 id = 3, citizen_name = "Wasserman"

 Candidate Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"

그런 다음 투표 테이블을 다음과 같이 보면 :

 Voting Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"
 id = 4, citizen_id = 3, candidate_name = "Hill Arry"
 id = 5, citizen_id = 3, candidate_name = "Hill Arry"

시민 번호 3은 Bern Nie를 속이는 불의 거짓말 쟁이 바지라고 말할 수 있습니다. 단지 예입니다.

타사 제품의 데이터베이스를 처리 할 때 밀접한 연결을 방지하기 위해 데이터베이스를 변경하지 않으려는 경우가 있습니다. 하지만 데이터와 1 : 1에 해당하는 데이터가있을 수 있습니다.

어디에서나 완전히 독립된 두 개체가 일대일 관계를 공유했습니다. 많은 예가 있어야합니다.

사람 <-> 치과 의사 (1 : N이므로 잘못되었습니다!)

사람 <-> 의사 (1 : N이므로 잘못되었습니다!)

사람 <-> 배우자 (1 : 0 | 1, 따라서 대부분 잘못되었습니다!)

편집하다: 예, 특히 나쁜 예였습니다. 특히 항상 양쪽에 0 또는 1이 아닌 1 : 1을 찾고 있다면 특히 그렇습니다. 내 뇌가 잘못 발사 된 것 같아 :-)

다시 시도하겠습니다. 약간의 생각 후에 소프트웨어가 항상 함께 있어야하는 두 개의 분리 된 엔티티를 가질 수있는 유일한 방법은 더 높은 분류에서 함께 존재하는 것입니다. 그런 다음 낮은 분해에 빠질 경우에만 사물이 분리되어 있어야하지만 더 높은 수준에서는 서로없이 살 수 없습니다. 문맥이 바로 그 열쇠입니다.

의료 데이터베이스의 경우 신체의 특정 영역에 대한 다른 정보를 저장하여 별도의 개체로 유지하려고 할 수 있습니다. 이 경우 환자는 머리가 하나만 있어야하며 머리가 필요하거나 환자가 아닙니다. (그들은 또한 하나의 마음과 다른 많은 단일 기관을 가지고 있습니다). 예를 들어 수술 추적에 관심이있는 경우 각 지역은 고유 한 독립 체 여야합니다.

생산 / 재고 시스템에서 차량 조립을 추적하는 경우 엔진과 차체가 다르게 진행되는 것을 확인하고 싶지만 일대일 관계가 있습니다. 케어에는 엔진이 있어야하며 하나만 있어야합니다 (또는 더 이상 '자동차'가 아님). 엔진은 하나의 자동차에만 속합니다.

각각의 경우에 별도의 엔티티를 하나의 큰 레코드로 생성 할 수 있지만 분해 수준이 주어지면 이는 잘못된 것입니다. 이러한 특정 맥락에서 그들은 더 독립적으로 나타나지는 않지만, 독립된 독립 체입니다.

폴