Notice
Recent Posts
Recent Comments
05-21 07:17
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Archives
Today
Total
관리 메뉴

Byeol Lo

Database Management - E/R Model II 본문

BackEnd/Database Management

Database Management - E/R Model II

알 수 없는 사용자 2023. 4. 1. 14:27

 앞서 살펴본 개념적 모델링을 위해 E/R 모델을 설계할때, Entity Sets 간의 Relationship(rhombus 마름모)으로 이어지게 되는데, 이게 관계를 정의하기 위한 syntax이다. 이때 관계는 함수로 볼 수 있는데, 각각의 행(record, entity)들이 서로 연결되는 것이다. 이 연결은 다음과 같은 특성을 지닐 수 있다.

 

Multiplicity

One-to-one relatioship : 연결된 서로의 entity sets 에서 한 개의 개체당 한 개의 개체로 연결되는 것

Many-to-one : A correspond many-to-one to B라는 말은 A의 각 개체들이 B에게 하나씩 대응되는 것

One-to-many : A correspond one-to-many to B = B correspond many-to-one to A

Many-to-many : A correspond many-to-many to B A, B 모든 개체들이 서로 네트워크 처럼 자유롭게 연결되어 있음

 

E/R Design 대표적 예제들

다음 예제를 보자.

Entity+Binary

Entity+Binary 형태의 E/R 모델이다.(색깔은 중요하지 않다.) 여기서 해당 모델을 다음과 같이 바꿀 수도 있었을 것이다.

Multi-way

 하지만 이는 각각의 Entity들에 대해 세부적인 설정이 불가능한 형태이다. 첫 번째의 형태는 각각의 관계나 엔티티에 대해 Constrains(제약조건) 등을 세밀히 지정할 수 있다. 하지만, 밑의 경우는 그러지 못한다. 하지만 밑의 모델도 틀렸다고 하는 것은 아니다. 우리는 때로 각각의 Entity set의 정보들을 서로 끌어와서 다 같이 보여주고 싶게 할 수 있다. 그럴 때는 Multi-way가 더 좋다. 따라서 다음과 같이 정리할 수 있다.

Multi-way Entity+Binary
All entity sets are related in data access More-fine-grained constraints

 

다른 예제를 보자.

Only Entity Set

 위는 전형적인 엔티티 셋의 속성들을 그려놓은 E/R 모델이다. 만약 해당 Entity가 사원이고 Attribute 두 개가 각각 주소를 나타내는 속성이라고 하자. 이 모델은 과연 괜찮은 모델일까? 아래의 예제를 보자.

Attribute

 위의 예제에서 Attribute를 추가하여 Entity set을 하나 더 생성한 후 Relationship을 통해 접근하도록 한다. 위, 아래 전부 틀린 모델은 아니다. 그러나 만약 임시적으로 속성들에 값들을 넣고 싶은 거라면 전자, 그 값들을 계속 유지하면서 유연성 있게 쓰려면 후자가 낫다. 나는 후자를 선택하겠다.

 이러한 Relationship들과 Entity set들은 RDBMS에서 관계(Table)로 표현되게 된다.

Comments