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

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

---

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

---

• 식별 관계 자식 테이블의 행의 존재는 상위 테이블의 행에 의존 할 때이다. 요즘에는 자식 테이블에 대한 의사 키를 만드는 것이 일반적이지만 자식 기본 키의 부모 부분에 외래 키를 만들지 않는 것이 일반적이기 때문에 혼란 스러울 수 있습니다 . 공식적으로 이렇게하는 "올바른"방법은 외래 키를 자녀의 기본 키의 일부로 만드는 것입니다. 그러나 논리적 관계는 부모 없이는 자식이 존재할 수 없다는 것입니다.

  예 : A Person에 하나 이상의 전화 번호가 있습니다. 전화 번호가 하나뿐이라면 간단히 Person. 여러 전화 번호를 지원하기 위해 PhoneNumbers기본 키 person_id에 Person테이블 참조가 포함 된 두 번째 테이블을 만듭니다 .

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

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

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

---

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

---

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

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

그러나 책은 저자가 썼고 저자는 여러 권의 책을 썼을 수 있습니다. 그러나 책은 저자가 써야합니다. 저자 없이는 존재할 수 없습니다. 따라서 책과 저자 사이의 관계는 식별 관계입니다.

---

식별 관계는 상위 개체없이 하위 개체가 존재할 수 없음을 지정합니다.

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

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

---

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

아이가 부모 없이는 존재할 수없는 관계에서 아이가 존재할 수 없다는 말이 계속해서 반복됩니다. (예 : user287724 ). 이것은 사실이지만 요점을 완전히 놓친 것입니다. 이를 달성 하려면 외래 키가 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

---

user287724의 답변 은 책과 저자 관계의 다음 예를 제공합니다.

그러나 책은 저자가 썼고 저자는 여러 권의 책을 썼을 수 있습니다. 그러나 책은 작가가 써야만한다. 작가 없이는 존재할 수 없다. 따라서 책과 저자 사이의 관계는 식별 관계입니다.

이것은 매우 혼란 예이며, 확실히 유효한 예를하지 에 대한 identifying relationship.

Yes, a book can not be written without at least one author, but the author(it's foreign key) of the book is NOT IDENTIFYING the book in the books table!

You can remove the author (FK) from the book row and still can identify the book row by some other field (ISBN, ID, ...etc) , BUT NOT the author of the book!!

I think a valid example of an identifying relationship would be the relationship between (products table) and a (specific product details table) 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

In this example the Product_ID in the printers_details table is considered a FK references the products.id table and ALSO a PK in the printers_details table , this is an identifying relationship because the Product_ID(FK) in the printers table IS IDENTIFYING the row inside the child table, we can't remove the product_id from the child table because we can't identify the row any more because we lost it's primary key

If you want to put it in 2 lines:

an identifying relationship is the relationship when the FK in the child table is considered a PK(or identifier) in the child table while still references the parent table

Another example may be when you have 3 tables (imports - products - countries) in an imports and exports for some country database

The import table is the child that has these fields(the product_id(FK), the country_id(FK) , the amount of the imports , the price , the units imported , the way of transport(air, sea) ) we may use the (product_id, thecountry_id`) to identify each row of the imports "if they all in the same year" here the both columns can compose together a primary key in the child table(imports) and also referencing there parent tables.

Please I'm happy I finally understand the concept of the identifying relationship and non identifying relationship, so please don't tell me I'm wrong with all of these vote ups for a completely invalid example

Yes logically a book can't be written without an author but a book can be identified without the author,In fact it can't be identified with the author!

You can 100% remove the author from the book row and still can identify the book!.

---

Non-identifying relationship

A non-identifying relationship means that a child is related to parent but it can be identified by its own.

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

The relationship between ACCOUNT and PERSON is non-identifying.

Identifying relationship

An identifying relationship means that the parent is needed to give identity to child. The child solely exists because of parent.

This means that foreign key is a primary key too.

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

The relationship between ITEM_LANG and ITEM is identifying. And between ITEM_LANG and LANGUAGE too.

---

The identifing relaionship means the child entity is totally depend on the existance of the parent entity. Example account table person table and personaccount.The person account table is identified by the existance of account and person table only.

The non identifing relationship means the child table does not identified by the existance of the parent table example there is table as accounttype and account.accounttype table is not identified with the existance of account table.

---

If you consider that the child item should be deleted when the parent is deleted, then it is an identifying relationship.

If the child item should be kept even though the parent is deleted, then it is a non-identifying relatioǹship.

As an example, I have a training database with trainees, trainings, diplomas and training sessions :

• trainees have an identifying relationship with training sessions
• trainings have an identifying relationship with training sessions
• but trainees have a non-identifying relationship with diplomas

Only training sessions should be deleted if one of the related trainee, training or diploma is deleted.

---

Do attributes migrated from parent to child help identify¹ the child?

• If yes: the identification-dependence exists, the relationship is identifying and the child entity is "weak".
• If not: the identification-dependence doesn't exists, the relationship is non-identifying and the child entity "strong".

Note that identification-dependence implies existence-dependence, but not the other way around. Every non-NULL FK means a child cannot exist without parent, but that alone doesn't make the relationship identifying.

For more on this (and some examples), take a look at the "Identifying Relationships" section of the ERwin Methods Guide.

P.S. I realize I'm (extremely) late to the party, but I feel other answers are either not entirely accurate (defining it in terms of existence-dependence instead of identification-dependence), or somewhat meandering. Hopefully this answer provides more clarity...

---

¹ The child's FK is a part of child's PRIMARY KEY or (non-NULL) UNIQUE constraint.

---

A good example comes from order processing. An order from a customer typically has an Order Number that identifies the order, some data that occurs once per order such as the order date and the Customer ID, and a series of line items. Each line item contains an item number that identifies a line item within an order, a product ordered, the quantity of that product, the price of the product, and the amount for the line item, which could be computed by multiplying the quantity by the price.

The number that identifies a line item only identifies it in the context of a single order. The first line item in every order is item number "1". The complete identity of a line item is the item number together with the order number of which it is a part.

The parent child relationship between orders and line items is therefore an identifying relationship. A closely related concept in ER modeling goes by the name "subentity", where line item is a subentity of order. Typically, a subentity has a mandatory child-parent identitying relationship to the entity that it's subordinate to.

In classical database design, the primary key of the LineItems table would be (OrderNumber, ItemNumber). Some of today's designers would give an item a separate ItemID, that serves as a primary key, and is autoincremented by the DBMS. I recommend classical design in this case.

---

Like well explained in the link below, an identifying relation is somewhat like a weak entity type relation to its parent in the ER conceptual model. UML style CADs for data modeling do not use ER symbols or concepts, and the kind of relations are: identifying, non-identifying and non-specific.

Identifying ones are relations parent/child where the child is kind of a weak entity (even at the traditional ER model its called identifying relationship), which does not have a real primary key by its own attributes and therefore cannot be identified uniquely by its own. Every access to the child table, on the physical model, will be dependent (inclusive semantically) on the parent's primary key, which turns into part or total of the child's primary key (also being a foreign key), generally resulting in a composite key on the child side. The eventual existing keys of the child itself are only pseudo or partial-keys, not sufficient to identify any instance of that type of Entity or Entity Set, without the parent's PK.

Non-identifying relationship are the ordinary relations (partial or total), of completely independent entity sets, whose instances do not depend on each others' primary keys to be uniquely identified, although they might need foreign keys for partial or total relationships, but not as the primary key of the child. The child has its own primary key. The parent idem. Both independently. Depending on the cardinality of the relationship, the PK of one goes as a FK to the other (N side), and if partial, can be null, if total, must be not null. But, at a relationship like this, the FK will never be also the PK of the child, as when an identifying relationship is the case.

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

---

Let's say we have those tables:

user
--------
id
name


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

relationship between those two tables will identifiying relationship. Because, comments only can be belong to its owner, not other users. for example. Each user has own comment, and when user is deleted, this user's comments also should be deleted.

---

An identifying relationship is between two strong entities. A non-identifying relationship may not always be a relationship between a strong entity and a weak entity. There may exist a situation where a child itself has a primary key but existence of its entity may depend on its parent entity.

For example : a relationship between a seller and a book where a book is being sold by a seller may exist where seller may have its own primary key but its entity is created only when a book is being sold

Reference based on Bill Karwin

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