식별 및 식별되지 않는 관계에 대해 여전히 혼란 스러움

식별 및 식별되지 않는 관계에 대해 여전히 혼란 스러움

---

그래서, 저는 제 데이터베이스 디자인에서 식별과 비 식별 관계에 대해 읽어 왔으며 SO에 대한 많은 답변이 저에게 모순되는 것 같습니다. 내가보고있는 두 가지 질문은 다음과 같습니다.

1. 식별 및 비 식별 관계의 차이점은 무엇입니까
2. 식별 또는 식별되지 않는 관계 결정 문제

각 질문의 상위 답변을 살펴보면 식별 관계가 무엇인지에 대한 두 가지 다른 아이디어를 얻은 것 같습니다.

첫 번째 질문의 응답은 식별 관계가 "하위 테이블의 행 존재가 상위 테이블의 행에 의존하는 상황을 설명합니다"라고 말합니다. 이에 대한 예는 "저자가 많은 책을 쓸 수 있지만 (1 대 n 관계) 책은 저자 없이는 존재할 수 없습니다."입니다. 그것은 나에게 의미가 있습니다.

그러나 두 번째 질문에 대한 답을 읽으면 "아이가 부모를 식별하면 식별 관계입니다"라고 말하면서 혼란스러워집니다. 그런 다음 대답은 사회 보장 번호 (사람을 식별 함) 와 같은 예를 제공하기 위해 계속 되지만 주소는 그렇지 않습니다 (많은 사람들이 한 주소에 살 수 있기 때문입니다). 나에게 이것은 기본 키와 비 기본 키 사이의 결정의 경우처럼 들립니다.

내 직감 (및 다른 사이트에 대한 추가 연구)은 첫 번째 질문과 그에 대한 응답이 정확하다는 것을 지적합니다. 그러나 데이터베이스 디자인을 이해하기 위해 노력하면서 잘못된 것을 배우고 싶지 않기 때문에 계속 진행하기 전에 확인하고 싶었습니다. 미리 감사드립니다.

---

식별 관계의 기술적 정의는 자녀의 외래 키가 기본 키의 일부라는 것입니다.

CREATE TABLE AuthoredBook (
  author_id INT NOT NULL,
  book_id INT NOT NULL,
  PRIMARY KEY (author_id, book_id),
  FOREIGN KEY (author_id) REFERENCES Authors(author_id),
  FOREIGN KEY (book_id) REFERENCES Books(book_id)
);

보다? book_id외래 키이지만 기본 키의 열 중 하나이기도합니다. 따라서이 테이블에는 참조 된 테이블과 식별 관계가 Books있습니다. 마찬가지로 Authors.

YouTube 동영상에 대한 댓글은 각 동영상과 식별 관계가 있습니다. 는 video_id 해야 의 기본 키의 일부가 될 Comments테이블.

CREATE TABLE Comments (
  video_id INT NOT NULL,
  user_id INT NOT NULL,
  comment_dt DATETIME NOT NULL,
  PRIMARY KEY (video_id, user_id, comment_dt),
  FOREIGN KEY (video_id) REFERENCES Videos(video_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
);

요즘에는 복합 기본 키 대신 직렬 대리 키만 사용하는 것이 일반적인 관행이므로 이해하기 어려울 수 있습니다.

CREATE TABLE Comments (
  comment_id SERIAL PRIMARY KEY,
  video_id INT NOT NULL,
  user_id INT NOT NULL,
  comment_dt DATETIME NOT NULL,
  FOREIGN KEY (video_id) REFERENCES Videos(video_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
);

이것은 테이블에 식별 관계가있는 경우를 모호하게 만들 수 있습니다.

본인은 SSN이 식별 관계를 나타내는 것으로 간주 하지 않습니다 . 어떤 사람들은 존재하지만 SSN이 없습니다. 다른 사람들은 새로운 SSN을 받기 위해 신청할 수 있습니다. 따라서 SSN은 실제로는 개인의 기본 키의 일부가 아닌 속성 일뿐입니다.

---

@Niels의 다시 코멘트 :

따라서 복합 기본 키 대신 대리 키를 사용하면 사용 식별 또는 비 식별 관계 사이에 눈에 띄는 차이가 없습니다.

나는 그렇게 생각. 대리 키를 사용하여 테이블 간의 논리적 관계를 변경하지 않았기 때문에 그렇습니다 . 즉, 기존 동영상을 참조하지 않고는 댓글을 작성할 수 없습니다. 그러나 이는 video_id가 NULL이 아니어야 함을 의미합니다. 그리고 논리적 측면은 저에게 관계를 식별하는 데있어 중요한 점입니다.

그러나 관계를 식별하는 물리적 측면도 있습니다. 그리고 그것은 외래 키 열이 기본 키의 일부라는 사실입니다 (기본 키는 반드시 복합 키일 필요는 없으며 Comments의 기본 키이자 Videos 테이블의 외래 키인 단일 열일 수 있음) 하지만 이는 동영상 당 하나의 댓글 만 저장할 수 있음을 의미합니다.)

관계 식별은 엔티티-관계 다이어그램 작성을 위해서만 중요한 것으로 보이며 이는 GUI 데이터 모델링 도구에서 나타납니다.

---

"잘못된 것을 배우고 싶지 않기 때문에".

글쎄, 당신이 정말로 그것을 의미한다면 ER 용어와 용어에 대해 걱정하지 않아도됩니다. 부정확하고, 혼란스럽고, 혼란스럽고, 일반적으로 동의하지 않으며, 대부분 무관합니다.

ER은 종이에 그려진 직사각형과 직선의 무리입니다. ER은 의도적으로 비공식 모델링을 위한 수단으로 사용됩니다 . 따라서 이는 데이터베이스 설계의 귀중한 첫 번째 단계이지만 그뿐 아니라 첫 번째 단계이기도합니다.

ER 다이어그램이 D로 공식적으로 작성된 데이터베이스 디자인의 정확성, 정확성 및 완전성에 근접해서는 안됩니다.

---

Identifying / non-identifying relationships are concepts in ER modelling - a relationship being an identifying one if it is represented by a foreign key that is part of the referencing table's primary key. This is usually of very little importance in relational modelling terms because primary keys in the relational model and in SQL databases do not have any special significance or function as they do in an ER model.

For example, suppose your table enforces two candidate keys, A and B. Suppose A is also a foreign key in that table. The relationship thus represented is deemed to be "identifying" if A is designated to be the "primary" key, but it is non-identifying if B is the primary key. Yet the form, function and meaning of the table is identical in each case! This is why in my opinion I don't think the identifying / non-identifying concept is really very important.

---

I believe only difference between an identifying and non identifying relationship is about Nullability of the foreign key. If a FK cannot be NULL, the relationship it represents is identifying (child cannot exist without parent) else it is non identifying.

---

part of the issue here is the confusion of terminology. identifying relationships are useful for avoiding long join paths.

The best definition i have seen is "an identifying relationship includes the PK as of the parent in the the child PK. In other words the PK of the child includes the FK to the parent as well as the "actual" PK of the child.

---

Yes, go with first one, but i don't think second one contradicts the first one. It's just formulated a little bit confusing..

UPDATE:

Just checked - second question's answer is wrong in some assumptions,.. book-author is not necessarily 1:n relation, as it could be m:n. In relational databases that creates intersection table for this m:n relation, and you get identifying relations between intersection table and those other 2 tables..

---

identifying relationship gives out one to many optional relationship when we have to define parent to child relationship.in addition it gives one to only one relationship from child to parent flow.since parent entity primary key will be the part of primary key of child entity, child entity instance will identify the parent entity instance.it is represented by solid line in er diagram.

where as non identifying relationship will many to many relationship.For the existence of child entity instance there should have parent entity instance but each entity instance in child entity may be related to many entity instance of parent entity.this is the reason why primary key of parent entity well be the foreign key of child entity, but child entity will not take parent entity primary key as its primary key.it will have its own primary key. many to many relation doesn't exist in real world er diagram. so it need to be resolved

---

An identifying relationship is indeed an ERD concept as this is the domain of conceptual modelling, modelling our understanding of the 'universe of discourse'. It is a parent-child relationship whereby we model the fact that identity of each child object is (at least in part) established/determined by the identity of the parent object. It is therefore mandatory, and immutable.

A real world example is with the perennial challenge of identifying people. A person's unique identity can be (in part) defined by their relationship with their birth mother and father. When known, these are immutable facts. Therefore the relationship between birth parent and child is an identifying relationship in that it contributes (immutably) to defining the identity of the child.

It is these qualities and the use of relational dbms constructs that result in the PK of the child being a composite key that includes, via FK, the PK of the parent. As a PK, the identity of the child is mandatory and immutable (it can't change) A 'change' in a PK is in fact instantiating a new object. Therefore the PK must not be able to be changed. The immutability of a PK should also be constrained. DB constraints can be used to implement that quality of PKs.

참고URL : https://stackoverflow.com/questions/2814469/still-confused-about-identifying-vs-non-identifying-relationships