데이터베이스 1:1 관계를 사용하는 것이 타당한 시기가 있습니까?

데이터베이스 1:1 관계를 사용하는 것이 타당한 시기가 있습니까?

일전에 정상화에 대해 생각하고 있었는데, 데이터베이스에 1:1 관계가 있어야 할 때가 생각나지 않습니다.

• Name:SSN저는 그것들을 같은 테이블에 두겠습니다.
• PersonID:AddressID다시 한 번, 같은 테이블.

저는 1: 다 또는 다의 무수한 예를 생각해 낼 수 있습니다: 다(적절한 중간 표 포함). 하지만 1:1은 절대 아닙니다.

제가 뭔가 명백한 것을 놓쳤나요?

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

논리적 파티션의 예를 들어, 직원에 대한 데이터가 있지만, 직원이 건강 보험에 가입하도록 선택한 경우에만 수집해야 하는 데이터 집합이 더 많습니다.나는 보안 분할을 더 쉽게 하고 보험과 관련 없는 쿼리에서 데이터를 이동하지 않기 위해 건강 보장과 관련된 인구 통계 데이터를 다른 표에 보관할 것입니다.

물리적 파티션의 예로는 여러 서버에서 호스팅되는 동일한 데이터를 들 수 있습니다.의료 서비스 인구 통계 데이터를 다른 상태(예: HR 사무실)로 유지하고 기본 데이터베이스는 연결된 서버를 통해서만 연결할 수 있습니다.중요한 데이터를 다른 위치로 복제하지 않고 필요한 쿼리에 사용할 수 있도록 합니다.

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

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

다른 사람들은 좋은 지적을 제기합니다.보안은 애플리케이션 등이 시스템에 미치는 영향에 따라 적절한 이유가 될 수도 있습니다.다른 접근 방식을 택하는 경향이 있지만 특정 데이터에 대한 액세스를 제한하는 쉬운 방법이 될 수 있습니다.위기 상황에서 특정 테이블에 대한 접근을 거부하는 것은 정말 쉽습니다.

그것에 대한 나의 블로그 엔트리.

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

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

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

• "A" 또는 슈퍼타입/하위타입 또는 상속/분류 관계:이 범주는 한 엔터티가 다른 엔터티의 특정 유형인 경우입니다.예를 들어, 모든 직원에게 적용되는 속성을 가진 직원 엔티티가 있고, 해당 직원 유형에 고유한 속성을 가진 특정 유형의 직원을 나타내는 다른 엔티티(예: 의사, 회계사, 파일럿 등)가 있을 수 있습니다.이 설계는 많은 직원이 특정 하위 유형의 특수 속성을 가지지 않으므로 여러 개의 null을 방지합니다.이 범주의 다른 예로는 슈퍼타입으로서의 제품, 서브타입으로서의 제조 제품 및 유지보수 공급품, 슈퍼타입으로서의 동물, 서브타입으로서의 개와 고양이 등이 있습니다.개체 지향 상속 계층을 관계형 데이터베이스(예: 개체 관계형 모델)에 매핑하려고 할 때마다 이러한 시나리오를 나타내는 관계입니다.

• 관리자, 이사장, 사장 등 조직 단위에 상사가 한 명만 있을 수 있고, 한 사람이 한 조직 단위의 상사가 될 수 있는 '보스' 관계.그 규칙들이 적용된다면, 여러분은 부서의 관리자 한 명, 회사의 CEO 한 명 등과 같은 1:1 관계를 맺게 됩니다. "보스" 관계는 사람들에게만 적용되는 것이 아닙니다.같은 종류의 관계는 한 회사의 본사와 같은 하나의 점포만 있거나, 한 나라의 수도가 오직 하나의 도시인 경우에 발생합니다.

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

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

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

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

기록 노트에는 두 가지 주목할 만한 예외가 있습니다.첫째, 일부 관계는 너무 드물게 변경되어 일반적으로 과거 정보가 저장되지 않습니다.예를 들어, 대부분의 IS-A 관계(예: 제품 유형)는 불변입니다. 즉, 절대 변경할 수 없습니다.따라서, 역사적 기록 지점은 모호합니다. 이러한 것들은 항상 자연스러운 1:1 관계로 구현됩니다.둘째, 예약과 대여는 각각의 날짜가 있는 독립적인 행사이기 때문에 예약-대여 관계 상점은 별도로 날짜를 지정합니다.기업은 1:1 관계 자체가 시작일이 아닌 고유한 날짜를 가지고 있기 때문에 과거 정보가 저장되더라도 이러한 관계는 1:1 관계로 유지됩니다.

당신의 질문은 당신이 그것을 표현하는 방식 때문에 여러 가지로 해석될 수 있습니다.반응은 이것을 보여줍니다.

현실 세계에서 데이터 항목 간에는 분명히 1:1 관계가 있을 수 있습니다.의심에 여지가 없어요."isa" 관계는 일반적으로 1 대 1입니다.자동차는 탈것입니다.한 대의 차는 한 대의 차입니다.한 대의 차량이 한 대의 차량일 수 있습니다.일부 차량은 트럭이며, 이 경우 한 차량은 자동차가 아닙니다.이 해석을 다루는 몇 가지 답변이 있습니다.

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

1NF, 2NF 및 3NF에 대한 정규화 규칙에서는 테이블을 동일한 기본 키를 가진 두 테이블로 분해(분할)할 필요가 없습니다.BCNF, 4NF 또는 5NF에 스키마를 넣으면 같은 키를 가진 두 개의 테이블이 생성될 수 있는지 여부는 아직 파악하지 못했습니다.즉석에서, 저는 답이 "아니오"라고 추측할 것입니다.

6NF라고 불리는 정규화 수준이 있습니다.6NF에 대한 정규화 규칙은 동일한 기본 키를 가진 두 개의 테이블을 생성할 수 있습니다. 6NF는 5NF에 비해 NULL을 완전히 피할 수 있는 이점이 있습니다.이것은 일부 데이터베이스 설계자들에게 중요하지만 전부는 아닙니다.저는 6NF에 스키마를 넣으려고 노력한 적이 없습니다.

6NF에서 결측 데이터는 일부 열에 NULL이 있는 행 대신 생략된 행으로 나타낼 수 있습니다.

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

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

다른 포스터는 1:1이 정상화되지 않았다고 댓글을 달았는데, 저는 일부 상황, 특히 서브타이핑에서 그것에 동의하지 않을 것입니다.예를 들어, 직원 테이블이 있고 기본 키가 SSN입니다(예를 들어, 이 키가 다른 스레드에 적합한 키인지 여부에 대한 논쟁은 저장).직원의 유형은 다양합니다. 예를 들어 임시 또는 영구적일 경우 사무실 전화 번호와 같이 입력해야 할 필드가 더 많습니다. 이 필드는 유형 = '영구적'인 경우에만 null이 되지 않아야 합니다.세 번째 정규 양식 데이터베이스에서 열은 직원을 의미하는 키에만 의존해야 하지만 실제로는 직원과 유형에 따라 달라지므로 1:1 관계는 완전히 정상이며 이 경우에 적합합니다.또한 일반적으로 채워진 열이 10개이지만 특정 유형에 대해서만 추가 열이 20개인 경우 테이블이 너무 희박해지는 것을 방지합니다.

제가 생각할 수 있는 가장 흔한 시나리오는 여러분이 BLOB를 가지고 있을 때입니다.큰 이미지를 데이터베이스에 저장하려고 합니다(일반적으로 저장하는 가장 좋은 방법은 아니지만 때로는 제약으로 인해 더 편리한 경우도 있습니다).일반적으로 비블로이드 데이터의 룩업을 개선하기 위해 블롭을 별도의 테이블에 배치할 수 있습니다.

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

실제 데이터베이스에서는 거의 사용되지 않는 필드를 별도의 테이블에 보관하는 것이 유용할 수 있습니다. 즉, 이 필드와 이 필드만 사용하여 쿼리 속도를 높이고 잠금을 방지하는 것입니다.

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

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

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

이 경우 Bird 및 Fish 속성을 유지하기 위해 null 가능한 열이 많이 포함된 Animal 테이블을 하나만 가질 필요는 없습니다. 여기서 Fish-data를 포함하는 모든 열은 레코드가 새를 나타내는 경우 NULL로 설정됩니다.

대신 새 표의 레코드가 동물 표의 레코드와 일대일 관계를 맺고 있습니다.

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

SQL에서는 테이블이 읽기 전용인 경우를 제외하고 양쪽에서 필수적인 두 테이블 간의 1:1 관계를 적용하는 것이 불가능합니다.대부분의 실질적인 목적에서 SQL의 "1:1" 관계는 실제로 1:0|1을 의미합니다.

참조 제약 조건에서 필수 카디널리티를 지원할 수 없다는 점은 SQL의 심각한 제한 사항 중 하나입니다."지연 가능한" 제약 조건은 실제로 중요하지 않습니다. 왜냐하면 제약 조건은 때때로 시행되지 않기 때문입니다.

또한 "실제" 데이터베이스 변경보다 적은 위험(인식된)으로 이미 운영 중인 테이블을 확장할 수 있습니다.레거시 시스템에서 1:1 관계를 확인하는 것은 초기 설계 후 필드가 추가되었음을 나타내는 좋은 지표가 되는 경우가 많습니다.

대부분의 경우, 누군가가 "글쎄, 왜 1:다수가 될 수 없을까?"라고 묻기 전까지는 디자인은 1:1로 생각됩니다.이러한 일반적인 시나리오를 예상하여 서로의 개념을 조기에 이혼하는 것이 이루어집니다.사용자와 주소가 너무 꽉 묶이지 않습니다.많은 사람들이 여러 개의 주소를 가지고 있습니다.등등...

일반적으로 두 개의 개별 객체 공간은 하나 또는 둘 다 곱할 수 있음을 의미합니다(x:many).만약 두 물체가 정말로, 정말로, 1:1이라면, 심지어 철학적으로도, 그것은 더 'is-relation'에 가깝습니다.이 두 "객체"는 실제로 하나의 전체 개체의 일부입니다.

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

저는 제가 1:1 관계를 할 때 관계적인 이유가 아니라 완전히 체계적인 이유 때문이라는 것을 알게 되었습니다.

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

하지만 당신이 옳습니다, 이론적으로, 1:1 관계는 완전히 꾸며진 것이고, 거의 하나의 현상입니다.그러나 논리적으로 데이터베이스를 추상화하는 프로그램과 최적화를 더 쉽게 허용합니다.

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

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

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

제가 1:1 관계를 확인할 수 있는 가장 좋은 이유는 데이터베이스 설계의 SuperType SubType입니다.저는 이 모델을 기반으로 부동산 MLS 데이터 구조를 만들었습니다.주거용, 상업용, 다세대, 호텔 및 토지의 다섯 가지 데이터 피드가 있었습니다.

저는 5개의 개별 데이터 피드 각각에 공통적인 데이터를 포함하는 SuperType이라는 속성을 만들었습니다.따라서 모든 데이터 유형에서 매우 빠른 "단순" 검색이 가능합니다.

5개의 데이터 피드 각각에 대해 고유한 데이터 요소를 저장하는 5개의 개별 하위 유형을 만듭니다.각 SuperType 레코드는 적절한 SubType 레코드와 1:1 관계를 가집니다.

고객이 자세한 검색을 원하는 경우 PropertyResidential과 같은 Super-Sub 유형을 선택해야 합니다.

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

안녕 마리오

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

정규화에 관심이 있다면 1:1 관계는 같은 테이블에 유지될 것이기 때문에 말이 되지 않습니다.

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

데이터베이스에 입력된 개체가 있을 수 있습니다.

예를 들어, 표 T1에서 열 C1, C2, C3이 1대 1 관계를 가지고 있다고 가정합니다.괜찮습니다, 정상화된 형태입니다.이제 표 T2에서 열 C1, C2, C3, …(이름은 다를 수 있지만 유형과 역할은 동일하다고 가정함)이 일대일 관계와 함께 있다고 가정합니다.T1과 같은 이유로 T2도 괜찮습니다.

하지만 이 경우에는 C1, C2, C3...와 T1에서 T3까지, 그리고 T2에서 T3까지 일대일 관계를 유지하는 별도의 테이블 T3에 적합합니다.테이블 A에서 테이블 B의 여러 행까지 1에서 여러 C1, C2, C3까지 이미 존재하는 다른 테이블이 있다면 적합성이 더욱 커집니다.그런 다음 T3 대신 B를 사용하고 T1에서 B까지 일대일 관계를 가지며 T2에서 B까지 동일한 관계를 가지며 A에서 B까지 동일한 관계에서 다중 관계를 가집니다.

정규화는 이것과 일치하지 않으며, 그 밖의 아이디어일 수도 있습니다. 개체 유형을 식별하고 동일한 유형의 개체를 자신의 저장소 풀로 이동합니다. 일부 테이블에서는 일대일 관계를 사용하고 다른 테이블에서는 일대일 관계를 사용합니다.

보안을 위해 불필요하게 유용하지만 보안 검사를 수행하는 더 나은 방법이 있습니다.하나의 문만 열 수 있는 열쇠를 만든다고 상상해 보세요.키가 다른 문을 열 수 있다면 알람을 울려야 합니다.본질적으로, 당신은 "시민 테이블"과 "투표 테이블"을 가질 수 있습니다.투표 테이블에 저장된 후보자 1에게 시민 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번 시민이 번 니를 속인 거짓말쟁이라고 말할 수 있습니다.예를 들어 보겠습니다.

타사 제품의 데이터베이스를 다루는 경우 엄격한 결합을 방지하기 위해 데이터베이스를 변경하고 싶지 않을 수 있습니다. 그러나 데이터와 1:1에 해당하는 데이터가 있을 수 있습니다.

어느 곳에서나 두 개의 완전히 독립적인 실체는 일대일 관계를 공유합니다.많은 예가 있을 것입니다.

person <-> 치과의사 (1:N이므로 틀렸습니다!)

사람 <-> 의사 (1:N이므로, 그것도 틀렸습니다!)

person <-> 배우자 (1:0|1이므로 대부분 틀렸습니다!)

편집: 네, 그것들은 꽤 나쁜 예들이었습니다. 특히 제가 항상 양쪽에서 0이나 1이 아닌 1:1을 찾고 있었다면요.내 뇌가 잘못 발사된 것 같아요 :-)

다시 해보겠습니다.좀 더 생각해 본 결과, (소프트웨어에 관한 한) 항상 함께 있어야 하는 두 개의 독립된 엔티티를 가질 수 있는 유일한 방법은 그들이 더 높은 범주로 함께 존재하는 것입니다.그리고 나서, 만약 당신이 낮은 분해에 빠질 경우에만, 그것들은 분리되어야 하고 분리되어야 하지만, 더 높은 수준에서는 서로 없이는 살 수 없습니다.그렇다면, 상황이 관건입니다.

의료 데이터베이스의 경우 신체의 특정 부위에 대한 다양한 정보를 별도의 개체로 유지하여 저장할 수 있습니다.이 경우, 환자는 머리가 하나뿐이고, 머리가 있어야 합니다. 그렇지 않으면 환자가 아닙니다. (그들은 또한 하나의 심장과 여러 개의 다른 필요한 단일 장기를 가지고 있습니다.)예를 들어 수술 추적에 관심이 있다면 각 지역은 고유한 독립체여야 합니다.

생산/재고 시스템에서 차량의 조립을 추적하는 경우, 엔진의 진행 상황을 차체와 다르게 보고 싶을 것입니다. 단, 일대일 관계가 존재합니다.관리에는 엔진이 있어야 하고, 하나만 있어야 합니다(그렇지 않으면 더 이상 '차'가 아닐 것입니다).엔진은 한 대의 자동차에만 속합니다.

각각의 경우 개별 엔티티를 하나의 큰 레코드로 생성할 수 있지만, 분해 수준을 고려할 때 이는 잘못된 것입니다.이러한 구체적인 맥락에서 볼 때, 그들은 더 높은 수준에서 그렇게 보이지 않을 수도 있지만, 진정으로 독립적인 실체입니다.

폴.

언급URL : https://stackoverflow.com/questions/517417/is-there-ever-a-time-where-using-a-database-11-relationship-makes-sense