나는 다른 날에 정규화에 대해 생각하고 있었고 데이터베이스에 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가있을 때입니다. 큰 이미지를 데이터베이스에 저장하려고한다고 가정 해 봅시다 (일반적으로 이미지를 저장하는 가장 좋은 방법은 아니지만 제약 조건으로 인해 더 편리합니다). 블롭이 아닌 데이터의 조회를 향상시키기 위해 일반적으로 블롭을 별도의 테이블에두기를 원합니다.
