식별과 식별이 아닌 관계의 차이점은 무엇입니까?

차이점을 완전히 파악할 수 없었습니다. 두 가지 개념을 설명하고 실제 사례를 사용할 수 있습니까?

• 식별 관계 자식 테이블의 행의 존재는 상위 테이블의 행에 의존 할 때이다. 이것은 자식 테이블에 대한 pseudokey을 만들려면 다음 일 것이 일반적이기 때문에 혼동 될 수 있지만 하지 하위의 1 차 키의 상위 부분에 외래 키를 확인합니다. 공식적으로 이렇게하는 "올바른"방법은 외래 키를 자녀의 기본 키의 일부로 만드는 것입니다. 그러나 논리적 관계는 부모가 없으면 자식이 존재할 수 없다는 것입니다.

  예 : A Person에 하나 이상의 전화 번호가 있습니다. 전화 번호가 하나 뿐인 경우 간단히 열에 저장할 수 Person있습니다. 여러 전화 번호를 지원하기 위해 PhoneNumbers기본 키 person_id에 Person테이블 참조를 포함 하는 두 번째 테이블을 만듭니다 .

  전화 번호는 별도의 테이블 속성으로 모델링 되었더라도 개인의 전화 번호라고 생각할 수 있습니다. 이것은 (우리가 문자 그대로 person_id기본 키에 포함하지 않더라도) 이것이 식별 관계라는 강력한 단서입니다 PhoneNumbers.

• 비 식별 관계는 기본 키는 부모의 속성 때입니다 안 기본 키가 하위의 속성이된다. 이에 대한 좋은 예 Person.state는 기본 키 를 참조 하는 외래 키와 같은 조회 테이블 입니다 States.state. Person에 대한 자식 테이블입니다 States. 그러나 행 입력은 Person해당 state속성으로 식별되지 않습니다 . 즉 state의 기본 키의 일부가 아닙니다 Person.

  비 식별 관계는 선택적 또는 필수 일 수 있습니다. 즉, 외래 키 열은 각각 NULL을 허용하거나 NULL을 허용하지 않습니다.

비 식별 관계 식별과 비 식별 관계에 대해 여전히 혼란에 대한 내 답변을 참조하십시오.

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

책은 소유자에게 속해 있으며 소유자는 여러 권의 책을 소유 할 수 있습니다. 그러나 책은 소유자 없이도 존재할 수 있으며 책의 소유권은 소유자마다 다를 수 있습니다. 책과 소유자 간의 관계는 비 식별 관계입니다.

그러나 한 권의 책은 저자가 작성했으며 저자는 여러 권의 책을 쓸 수있었습니다. 그러나이 책은 저자가 작성해야합니다. 저자 없이는 존재할 수 없습니다. 따라서 책과 저자의 관계는 식별 관계입니다.

Bill의 대답 은 정확하지만 다른 모든 대답 중에서 아무도 가장 중요한 측면을 지적하지 않는 것이 충격적 입니다.

아이가 부모 없이는 존재할 수 없다고 말하고 관계를 반복해서 말합니다. (예 : user287724 ). 이것은 사실이지만 요점을 완전히 놓친 것입니다. 이를 달성 하려면 외래 키가 널 이 아닌 것으로 충분 합니다. 기본 키의 일부일 필요는 없습니다.

여기 진짜 이유가 있습니다 :

식별 관계의 목적이다 외래 키 결코 변경 이 기본 키의 일부이므로 .. 따라서 식별 !!!

식별 관계는 상위 오브젝트없이 하위 오브젝트가 존재할 수 없음을 지정합니다.

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

비 식별 관계는 상위 테이블 카디 낼 리티를 설정하여 상위가 필요하지 않은 경우 선택적이거나 상위가 필요한 경우 필수로 지정할 수 있습니다.

다음은 좋은 설명입니다.

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

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

user287724의 답변 은 다음과 같은 책과 저자 관계를 보여줍니다.

그러나 한 권의 책은 저자에 의해 쓰여졌으며 저자는 여러 권의 책을 쓸 수있었습니다. 그러나이 책은 저자가 쓸 수 없으며 저자 없이는 존재할 수 없습니다. 그러므로 책과 저자 사이의 관계는 식별 관계입니다.

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

예,이 book적어도 하나없이 기록 할 수 author있지만, author(가)의 (가 외래 키의) book되어 식별되지book 에서 books표를!

당신은 제거 할 수 author로부터 (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_ID에서 printers_details표의 표는 FK가 products.id표를 참조하고 표 에서도 PK 를 참조하는 것으로 간주됩니다. 이는 프린터 표의 (FK) 가 하위 표 내부의 행을 식별printers_details 하기 때문에 식별 관계이므로 제거 할 수 없습니다. 우리가 기본 키의 손실 때문에 자식 테이블에서 우리는 더 이상 행을 식별 할 수 없기 때문에Product_IDproduct_id

두 줄에 넣으려면 다음을 수행하십시오.

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

일부 국가 데이터베이스의 가져 오기 및 내보내기에 3 개의 테이블 (수입-제품-국가)이있는 경우를 예로들 수 있습니다.

import표 (이들 필드가 아이입니다 product_id(FK)는 country_id, 단위는 수송의 방법 (항공, 해상) 수입 (FK), 수입품의 양, 가격) we may use the (PRODUCT_ID , the각각을 식별 할 수 country_id`를) 가져 오기 행 "모두 같은 해에있는 경우"두 열 모두 하위 테이블 (가져 오기)의 기본 키를 구성하고 상위 테이블을 참조 할 수 있습니다.

나는 행복 드디어의 개념을 이해 해요하시기 바랍니다 identifying relationship및 non identifying relationship그래서 나는 이러한 투표 업의 모든 잘못이야 말하지 마십시오, 완전히 잘못된 예

논리적으로 책은 저자 없이는 쓸 수 없지만 저자 없이는 책을 식별 할 수 있습니다. 사실 저자와 동일하게 식별 할 수 없습니다!

책 행에서 저자를 100 % 제거 할 수 있으며 여전히 책을 식별 할 수 있습니다! .

비 식별 관계

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

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

ACCOUNT와 PERSON의 관계는 식별되지 않습니다.

관계 식별

식별 관계는 부모가 자녀에게 정체성을 부여하기 위해 필요하다는 것을 의미합니다. 아이는 부모 때문에 존재합니다.

이것은 외래 키도 기본 키임을 의미합니다.

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

ITEM_LANG과 ITEM의 관계가 식별됩니다. ITEM_LANG과 LANGUAGE도 마찬가지입니다.

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

부모 항목이 삭제 된 경우에도 자식 항목을 보관해야하는 경우 이는 식별 할 수없는 관계입니다.

예를 들어, 연수생, 교육, 졸업장 및 교육 세션이있는 교육 데이터베이스가 있습니다.

• 연수생은 교육 세션과 식별 관계가 있습니다
• 훈련은 훈련 세션과 식별 관계가 있습니다
• 그러나 연수생은 학위와 비 식별 관계가 있습니다

관련 교육생, 교육 또는 졸업 증서 중 하나가 삭제 된 경우 교육 세션 만 삭제해야합니다.

식별 관계는 자식 개체가 부모 개체의 존재에 전적으로 의존한다는 것을 의미합니다. 계정 테이블 개인 테이블 및 개인 계정 예제 개인 계정 테이블은 계정 및 개인 테이블의 존재만으로 식별됩니다.

비 식별 관계는 자식 테이블이 부모 테이블의 존재로 식별되지 않음을 의미합니다. 테이블은 accounttype으로 존재하고 account.accounttype 테이블은 계정 테이블의 존재로 식별되지 않습니다.

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

식별하는 것은 자식이 약한 실체 (종종 ER 모델이라고도 식별 관계라고 함)의 일종 인 부모 / 자식의 관계로, 고유 한 특성으로 실제 기본 키가 없으므로 고유 한 고유 키로 식별 할 수 없습니다. . 실제 모델에서 하위 테이블에 대한 모든 액세스는 상위의 기본 키에 의존적으로 (의미 적으로) 종속되며, 이는 하위의 기본 키 (일부 외래 키)의 일부 또는 전체가되며 일반적으로 복합 키가됩니다. 아이쪽에. 자식 자체의 최종 기존 키는 의사 또는 부분 키일 뿐이며 부모의 PK없이 해당 유형의 엔터티 또는 엔터티 집합의 인스턴스를 식별하기에는 충분하지 않습니다.

비 식별 관계는 완전히 독립적 인 엔터티 집합의 일반적인 관계 (부분 또는 전체)이며, 부분 또는 전체 관계를위한 외래 키가 필요할 수 있지만 인스턴스는 서로의 기본 키를 고유하게 식별하기 위해 서로 의존하지 않습니다. 아이의 기본 키로. 아이는 자신의 기본 키를 가지고 있습니다. 부모님. 둘 다 독립적으로. 관계의 카디널리티에 따라 하나의 PK가 다른쪽에 대한 FK로 이동하고 (N 측), 부분적인 경우 null 일 수 있으며, 총계 인 경우 null이 아니어야합니다. 그러나 이와 같은 관계에서 FK는 식별 관계가있는 경우와 같이 결코 어린이의 PK가 될 수 없습니다.

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

마 아이의 도움으로 부모로부터 마이그레이션 속성을 식별 ^한 아이를?

• 예인 경우 : 식별-의존이 존재하면 관계가 식별되고 하위 엔티티가 "약합니다".
• 그렇지 않은 경우 : 식별 의존성이 존재하지 않으면 관계는 식별되지 않으며 하위 엔티티는 "강력"합니다.

식별-의존은 존재-의존을 의미하지만 다른 방법은 아닙니다. NULL이 아닌 모든 FK는 부모가없는 자녀는 존재할 수 없지만 그 자체만으로는 관계를 식별하지는 않습니다.

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

추신. 나는 파티에 늦게 도착했다는 것을 알고 있지만, 다른 답변은 완전히 정확하지는 않지만 (식별 의존 대신 존재 의존성으로 정의) 또는 다소 사소한 느낌이 든다. 이 답변이 더 명확하게 제공되기를 바랍니다.

¹ 자녀의 FK는 자녀의 PRIMARY KEY 또는 NULL이 아닌 UNIQUE 제약 조건의 일부입니다.

좋은 예는 주문 처리에서 비롯됩니다. 고객의 주문에는 일반적으로 주문을 식별하는 주문 번호, 주문 날짜 및 고객 ID와 같이 주문 당 한 번 발생하는 일부 데이터 및 일련의 광고 항목이 있습니다. 각 광고 항목에는 주문 내의 광고 항목, 주문한 제품, 해당 제품의 수량, 제품 가격 및 광고 항목의 수량을 식별하는 품목 번호가 포함됩니다. 가격.

광고 항목을 식별하는 숫자는 단일 주문의 맥락에서만 식별합니다. 모든 주문의 첫 번째 광고 항목은 항목 번호 "1"입니다. 광고 항목의 완전한 ID는 품목 번호와 해당 품목의 주문 번호입니다.

따라서 광고 주문과 광고 항목 간의 상위 하위 관계는 식별 관계입니다. ER 모델링에서 밀접하게 관련된 개념은 광고 항목이 주문의 하위 항목 인 "subentity"라는 이름으로 이루어집니다. 일반적으로 하위 엔터티에는 하위 엔터티와의 필수 자식-부모 아이덴티티 관계가 있습니다.

클래식 데이터베이스 디자인에서 LineItems 테이블의 기본 키는 (OrderNumber, ItemNumber)입니다. 오늘날의 일부 디자이너는 기본 키 역할을하며 DBMS에 의해 자동 증분되는 별도의 ItemID를 항목에 제공합니다. 이 경우 클래식 한 디자인을 권장합니다.

그 테이블이 있다고 가정 해 봅시다.

user
--------
id
name


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

이 두 테이블 간의 관계는 관계를 식별합니다. 댓글은 다른 사용자가 아닌 소유자에게만 속할 수 있기 때문입니다. 예를 들어. 각 사용자는 자신의 의견을 가지고 있으며 사용자가 삭제되면이 사용자의 의견도 삭제되어야합니다.

식별 관계는 두 개의 강력한 엔터티 사이에 있습니다. 비 식별 관계가 항상 강력한 실체와 취약한 실체 사이의 관계는 아닙니다. 자식 자체에 기본 키가 있지만 해당 개체의 존재가 부모 개체에 따라 달라질 수있는 상황이있을 수 있습니다.

예를 들어, 판매자와 판매자가 책을 판매하는 책 사이의 관계는 판매자가 자체 기본 키를 가지고 있지만 책이 판매 될 때만 엔티티가 생성되는 곳에 존재할 수 있습니다.

Bill Karwin에 기초한 참고