식별 관계와 비식별 관계의 차이점은 무엇입니까?

식별 관계와 비식별 관계의 차이점은 무엇입니까?

저는 그 차이점들을 완전히 파악하지 못했습니다.당신은 두 개념을 설명할 수 있고 실제 세계의 예를 사용할 수 있습니까?

• 식별 관계란 자식 테이블의 행 존재가 부모 테이블의 행에 의존하는 경우를 말합니다.요즘에는 자녀 테이블에 대한 의사 키를 만드는 것이 일반적이지만 자녀의 기본 키에서 부모 키에 대한 외부 키는 만들지 않기 때문에 혼란스러울 수 있습니다.공식적으로, 이를 위한 "올바른" 방법은 외산 키를 아이의 기본 키의 일부로 만드는 것입니다.하지만 논리적인 관계는 아이가 부모 없이는 존재할 수 없다는 것입니다.

  예: APerson하나 이상의 전화번호를 가지고 있습니다.만약 그들이 단지 하나의 전화번호를 가지고 있다면, 우리는 그것을 단순히 열에 저장할 수 있습니다.Person두 . .PhoneNumbers에는 , 합니다가 됩니다.person_id 참조Person블.

  전화번호는 별도의 테이블의 속성으로 모델링된 경우에도 사용자의 것으로 간주할 수 있습니다.은 (다도)를 ) 이것이 한 단서입니다.person_id의 기본 PhoneNumbers).

• 비식별 관계란 부모의 기본 키 속성이 자식의 기본 키 속성이 되어서는 안 될 때를 말합니다.이것의 좋은 예는 외부 키와 같은 룩업 테이블입니다.Person.state키States.state.Person입니다에 입니다.States 한 로.Person.state기여하다.예.state다의 .Person.

  비식별 관계는 선택적이거나 필수 관계일 수 있으며, 이는 외부 키 열이 각각 NULL을 허용하거나 NULL을 허용하지 않음을 의미합니다.

---

다음 항목을 참조하십시오. 식별에 대한 여전히 혼란스러운 정보 vs. 비식별 관계

현실 세계에서 온 또 다른 설명이 있습니다.

책은 소유자의 것이고, 소유자는 여러 권의 책을 소유할 수 있습니다.하지만, 책은 주인이 없어도 존재할 수 있고, 책의 소유권은 한 주인에서 다른 주인으로 바뀔 수 있습니다.책과 소유자의 관계는 비식별적인 관계입니다.

하지만 책은 작가가 쓴 것이고, 작가는 여러 권의 책을 썼을 수도 있습니다.하지만, 이 책은 작가가 써야 합니다. 작가 없이는 존재할 수 없습니다.그러므로 책과 저자의 관계는 동일시되는 관계입니다.

빌의 대답은 맞지만, 다른 모든 대답들 중에서 가장 중요한 부분을 지적하는 사람이 아무도 없다는 것은 충격적입니다.

부모 없이는 아이가 존재할 수 없다는 것은 계속해서 말해왔습니다.(예: user287724).이것은 사실이지만, 요점을 완전히 놓치고 있습니다.이를 달성하기 위해서는 외국 키가 null이 아닌 것으로 충분합니다.기본 키의 일부일 필요는 없습니다.

그래서 진짜 이유는 다음과 같습니다.

식별 관계의 목적은 외국 키가 주요 키의 일부이기 때문에 절대로 변하지 않아야 한다는 것입니다.그러니 신원확인!!!

식별 관계는 자식 개체가 부모 개체 없이는 존재할 수 없음을 지정합니다.

비식별 관계는 개체 간의 규칙적인 연결(1:1 또는 1:n 카디널리티)을 지정합니다.

부모 테이블 카디널리티를 설정하여 부모가 필요하지 않은 경우 비식별 관계를 선택 사항으로 지정하거나 부모가 필요한 경우 필수 관계로 지정할 수 있습니다.

여기 좋은 설명이 있습니다.

두 개체 간의 관계는 "식별" 또는 "비식별"으로 분류될 수 있습니다.상위 엔티티의 기본 키가 하위 엔티티의 기본 키에 포함될 때 식별 관계가 존재합니다.반면에 비식별 관계는 지배기업의 기본 키가 자식기업에 포함되지만 자식기업의 기본 키의 일부가 아닌 경우에 존재합니다.또한, 비식별 관계는 "필수" 또는 "비필수"로 더 분류될 수 있습니다.하위 테이블의 값이 null일 수 없는 경우에는 비식별 관계가 필수적으로 존재합니다.반면 하위 테이블의 값이 null일 수 있는 경우에는 비필수 비식별 관계가 존재합니다.

http://www.sqlteam.com/article/database-design-and-modeling-fundamentals

관계를 파악하는 간단한 예는 다음과 같습니다.

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (PK, FK to Parent.ID) -- notice PK
Name

이에 해당하는 비식별 관계는 다음과 같습니다.

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (FK to Parent.ID) -- notice no PK
Name

비식별 관계

비식별 관계란 자녀가 부모와 관련이 있지만 스스로 식별할 수 있다는 것을 의미합니다.

PERSON    ACCOUNT
======    =======
pk(id)    pk(id)
name      fk(person_id)
          balance

ACCORTH와 PERSORTH 사이의 관계는 식별되지 않습니다.

관계 파악

동일시 관계란 자녀에게 정체성을 부여하기 위해 부모가 필요하다는 것을 의미합니다.그 아이는 오직 부모 때문에 존재합니다.

이것은 외국 키도 기본 키라는 것을 의미합니다.

ITEM      LANGUAGE    ITEM_LANG
====      ========    =========
pk(id)    pk(id)      pk(fk(item_id))
name      name        pk(fk(lang_id))
                      name

ITEM 사이의 관계_LANG와 ITEM이 식별되고 있습니다.그리고 ITEM 사이_LANG랑 LANGURE도.

user287724의 답변은 책과 저자의 관계에 대해 다음과 같은 예를 제시합니다.

하지만 책은 작가가 쓴 것이고, 작가는 여러 권의 책을 썼을 수도 있습니다.하지만 이 책은 작가가 써야 합니다. 작가 없이는 존재할 수 없습니다.그러므로 책과 저자의 관계는 동일시되는 관계입니다.

이것은 매우 혼란스러운 예이며 확실히 유효한 예는 아닙니다.identifying relationship.

, a.book다 는 쓸 수 .author , .author (입니다)의book다음과 같은 정보를 확인하지 않는 중입니다.bookbooks블!

를 할 수 .author () (FK) (FK) (FK) (FK) 에서book책할 수 다()ISBN,ID, ... 등), 하지만 책의 저자는 아닙니다!!

엔, 의 합니다.identifying relationship 표)와 표)입니다 될 것입니다.1:1

products table
+------+---------------+-------+--------+
|id(PK)|Name           |type   |amount  |
+------+---------------+-------+--------+
|0     |hp-laser-510   |printer|1000    |
+------+---------------+-------+--------+
|1     |viewsonic-10   |screen |900     |
+------+---------------+-------+--------+
|2     |canon-laser-100|printer|200     |
+------+---------------+-------+--------+

printers_details table
+--------------+------------+---------+---------+------+
|Product_ID(FK)|manufacturer|cartridge|color    |papers|
+--------------+------------+---------+---------+------+
|0             |hp          |CE210    |BLACK    |300   |
+--------------+------------+---------+---------+------+
|2             |canon       |MKJ5     |COLOR    |900   |
+--------------+------------+---------+---------+------+
* please note this is not real data

에서는 Product_IDprinters_details는 FK를 참조하는 됩니다.products.id표 및 PK 인printers_details표,입니다,입니다이기 입니다.Product_ID프린터 테이블의 (FK)는 하위 테이블 내부의 행을 식별하므로 제거할 수 없습니다.product_id 때문에 더 할 수 없기 때문에 에서.

두 줄로 표시하려면 다음과 같이 하십시오.

식별 관계는 자식 테이블의 FK가 자식 테이블의 PK(또는 식별자)로 간주되는 동시에 부모 테이블을 참조할 때의 관계입니다.

다른 예로는 일부 국가 데이터베이스에 대한 수출입에 3개의 테이블(수입 - 제품 - 국가)이 있는 경우를 들 수 있습니다.

import입니다)를 입니다.product_id (),country_idFK), , , , (, ) we may use the (product_id, the는 각두은 모두 할 수 country_id')을 할 수 있습니다. country_id')는 "의"" () 을 합니다.

의 개념을 드디어 그 개념을 이해하게 되었습니다.identifying relationship그리고.non identifying relationship, 그러니 제발 이 모든 투표가 완전히 무효인 예를 들어 잘못됐다고 말하지 말아주세요.

네 논리적으로 책은 저자 없이는 쓸 수 없지만 책은 저자 없이는 동일시될 수 있습니다. 사실 책은 저자와 동일시될 수 없습니다!

책 행에서 저자를 100% 삭제할 수 있으며, 책을 식별할 수 있습니다!

상위 항목을 삭제할 때 하위 항목을 삭제해야 한다고 생각한다면 이는 식별 관계입니다.

부모 항목이 삭제되어도 자식 항목이 유지되어야 하는 경우 비식별 관계 ǹ 관계입니다.

예를 들어, 저는 훈련생, 훈련, 졸업장 및 훈련 세션에 대한 훈련 데이터베이스를 가지고 있습니다.

• 훈련생이 훈련 세션과 동일한 관계를 갖습니다.
• 교육이 교육 세션과 식별 관계를 갖습니다.
• 하지만 훈련생들은 졸업장과 정체불명의 관계를 갖고 있습니다

관련 연수생, 연수생 또는 졸업장 중 한 명이 삭제된 경우에는 연수만 삭제해야 합니다.

식별 관계는 자식 개체가 부모 개체의 존재에 전적으로 의존한다는 것을 의미합니다.

예: 계정 테이블 사용자 테이블 및 사용자 계정.사용자 계정 테이블은 계정과 사용자 테이블의 존재만으로 식별됩니다.

비식별 관계는 자식 테이블이 부모 테이블의 존재로 식별되지 않음을 의미합니다.

계정으로서의 A 표 예제유형 및 계정.계정계정 테이블이 있는 경우 유형 테이블이 식별되지 않습니다.

아래 링크에서 잘 설명된 것처럼 식별 관계는 ER 개념 모형에서 모체에 대한 약한 실체 유형 관계와 다소 유사합니다.데이터 모델링을 위한 UML 스타일 CAD는 ER 기호나 개념을 사용하지 않으며, 관계의 종류는 식별, 비식별 및 비특정입니다.

식별하는 것은 자식이 일종의 약한 개체(전통적인 ER 모델에서도 식별 관계라고 함)인 관계 부모/자녀입니다. 이 관계는 고유한 속성에 의해 실제 기본 키를 가지고 있지 않으므로 고유하게 식별할 수 없습니다.물리적 모델에서 자식 테이블에 대한 모든 액세스는 부모의 기본 키에 의존적으로(의미론적으로 포함), 자식의 기본 키의 일부 또는 전체(또한 외부 키)가 되어 일반적으로 자식 측에 복합 키가 됩니다.자식 자체의 최종적인 기존 키는 유사 키 또는 부분 키에 불과하므로 부모의 PK가 없으면 해당 유형의 엔티티 또는 엔티티 세트의 인스턴스를 식별하기에 충분하지 않습니다.

비식별 관계는 완전히 독립적인 개체 집합의 일반적인 관계(부분 또는 전체)로, 인스턴스는 서로의 기본 키에 의존하지 않고 고유하게 식별됩니다. 비록 부분 또는 전체 관계에 대해 외부 키가 필요할 수 있지만 자식의 기본 키로는 필요하지 않습니다.아이에게는 기본 키가 있습니다.부모 아이디.둘 다 독립적으로.관계의 카디널리티에 따라 한 쪽의 PK는 다른 쪽(N쪽)으로 FK로 진행되며, 부분적인 경우 null일 수 있고, 전체적인 경우 null일 수 없습니다.하지만 이런 관계에서 FK는 동일시 관계일 때와 마찬가지로 결코 아이의 PK가 될 수 없을 것입니다.

http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships

부모에서 자식으로 마이그레이션된 속성이 자식을 식별하는¹ 데 도움이 됩니까?

• yes인 경우: 식별 종속성이 존재하고 관계가 식별되고 하위 개체가 "취약"합니다.
• 그렇지 않은 경우: 식별 종속성이 존재하지 않으며, 관계가 비식별화되고 하위 개체가 "강력"합니다.

식별 의존성은 존재 의존성을 의미하지만, 그 반대는 아니라는 점에 유의하십시오.NULL이 아닌 모든 FK는 부모 없이는 자식이 존재할 수 없다는 것을 의미하지만, 그것만으로는 관계를 확인할 수 없습니다.

이에 대한 자세한 내용(및 일부 예)은 ERwin 방법 안내서의 "관계 식별" 섹션을 참조하십시오.

추신. 파티에 늦었다는 것은 (극도로) 알고 있지만, 다른 대답들은 완전히 정확하지 않거나(식별 의존 대신 존재 의존성으로 정의) 다소 구불구불하다고 생각합니다.이 대답이 좀 더 명확해지길 바랍니다.

---

¹ 어린이의 FK는 어린이의 기본 키 또는 (NULL이 아닌) 고유 제약 조건의 일부입니다.

좋은 예는 주문 처리에서 나옵니다.고객의 주문에는 일반적으로 주문을 식별하는 주문 번호, 주문 날짜 및 고객 ID와 같이 주문당 한 번씩 발생하는 일부 데이터, 일련의 라인 항목이 있습니다.각 라인 항목에는 주문 내의 라인 항목을 식별하는 품번, 주문한 제품, 해당 제품의 수량, 제품의 가격, 라인 항목에 대한 금액이 포함되어 있으며, 이는 수량에 가격을 곱하여 계산할 수 있습니다.

선 항목을 식별하는 숫자는 단일 주문의 컨텍스트에서만 식별합니다.모든 순서의 첫 번째 줄 항목은 "1"번 항목입니다.라인 항목의 완전한 동일성은 항목 번호와 그 항목이 포함된 주문 번호입니다.

그러므로 주문과 줄 항목 사이의 부모 자식 관계는 식별 관계입니다.ER 모델링에서 밀접하게 관련된 개념은 "subentity"라는 이름으로 통하는데, 여기서 선 항목은 순서의 하위 개체입니다.일반적으로 하위 개체는 종속된 개체에 대해 의무적인 자식-부모 식별 관계를 가집니다.

기존 데이터베이스 설계에서 LineItems 테이블의 기본 키는 (OrderNumber, ItemNumber)입니다.오늘날의 디자이너 중 일부는 한 아이템에 별도의 아이템을 주기도 합니다.기본 키 역할을 하는 ID로 DBMS에 의해 자동 증가됩니다. 이 경우 클래식 디자인을 추천합니다.

Daniel Dinnyes의 답변을 보완합니다.

식별되지 않는 관계에서는 동일한 값을 가진 동일한 기본 키 열("ID"라고 하자)을 두 번 가질 수 없습니다.

그러나 식별 관계를 사용하면 "ID" 열에 대해 동일한 값을 두 번 표시할 수 있습니다. 다른 "기타 열"이 있는 한기본 키는 두 열의 조합이기 때문에 ID " 외부 키 값입니다.

참고로 FK가 "non-null"인지 아닌지는 중요하지 않습니다. ;-)

우리가 그 테이블을 가지고 있다고 가정해 보겠습니다.

user
--------
id
name


comments
------------
comment_id
user_id
text

두 테이블 사이의 관계는 관계를 식별할 것입니다.댓글은 다른 사용자가 아닌 소유자의 것일 수 있기 때문입니다.예를들면.각 사용자는 고유한 주석을 가지고 있으며, 사용자가 삭제되면 해당 사용자의 주석도 삭제해야 합니다.

식별 관계는 두 개의 강력한 개체 사이에 있습니다.비식별 관계가 항상 강한 실체와 약한 실체 사이의 관계는 아닐 수 있습니다.자식 자체가 기본 키를 가지고 있지만 개체의 존재는 부모 개체에 의존할 수 있는 상황이 있을 수 있습니다.

예를 들어, 판매자와 판매자에 의해 판매되고 있는 책 사이의 관계는 판매자가 자신의 주요 키를 가질 수 있지만 그 실체는 책이 판매되고 있을 때만 생성됩니다.

빌 카윈을 기준으로 한 참고 문헌

언급URL : https://stackoverflow.com/questions/762937/whats-the-difference-between-identifying-and-non-identifying-relationships