You've got to find what you love.

# 엔터티를 찾기 위한 사고의 전개

- 엔터티의 개수들은 점점 많아지지만 우리가 해야 할 것이 그렇게 많아지는 것은 아니다. 키가 되는 엔터티들을 찾고 키가 되지 않는 엔터티들은 키가 되는 엔터티들을 기준으로 파생시켜 나가면 되는 것이다.
- 이러한 개념을 기준으로 엔터티의 종류를 세 가지로 나눌 수 있다.
키 엔터티(Key Entity), 메인 엔터티(Main Entity), 액션 엔터티(Action Entity)가 바로 그것이다.
물론 이 외에도 M:M관계를 해소시켜주는 릴레이션 엔터티(Relation Entity)도 있으며 어떤 사람들은 메이저 엔터티(Major Entity)의 존재를 이야기하기도 하지만, 여기서 엔터티의 종류를 나누는 것은 우리가 어떻게 키 엔터티에서 나머지 엔터티들을 파생시켜 나갈 것인가 하는 것을 알기 위해서 이다.

* 키 엔터티, Key Entity
부모를 가지지 않는 독립적인 엔터티라 할 수 있다.
키 엔터티는 전체 개체-관계도에서 가장 주어가 되는 엔터티들이다. 예를 들어 고객은 키 엔터티이다. 고객이라는 데이터를 발생시키기 위한 엔터티들이 있는가? 사원 또한 키 엔터티이다.
사원과 일대다 관계를 맺는 부서라는 엔터티가 있을 수 있지만 이것은 릴레이션쉽의 문제로 실제 사원 데이터가 발생하는 것과는 아무런 연관이 없다. 그리고 부서가 없는 사원도 있을수 있으니 말이다(일반적으로 신입사원으로 연수를 받는 도중에는 부서가 없다).
되도록이면 엔터티 후보들을 찾을 때, 가장 우선해서 키 엔터티들을 찾아내야 한다. 그래야만 다른 엔터티들을 파생시킬 수 있다(물론 찾아내지 못한 키 엔터티들은 나중에 다른 엔터티들에서 도출될 수도 있다).
예) 사원, 고객, 강좌, 학생, 교수, 상품, 계정

* 메인 엔터티, Main Entity
부모를 가지지만 스스로 업무의 핵심이 되어서 많은 자손 엔터티들을 가지는 것이 바로 메인 엔터티이다. 업무에는 이러한 데이터들이 많이 존재한다.
주문과 같은 엔터티의 경우, 상품이나 고객과 같은 주문이라는 데이터를 낳게 한 부모들을 가지고 있다.
주문 엔터티는 다른 엔터티들에서 파생된 엔터티이기는 하지만 업무의 중심으로, 또한 다른 엔터티들을 많이 파생시키기도 한다.
예) 주문, 가입계약, 납입계약, 보험계약, 예금원장

* 액션 엔터티, Action Entity
키 엔터티나 메인 엔터티가 아니라면 나머지는 액션 엔터티 밖에는 없을 것이다. 앤ㄱ션 엔터티는 메인 엔터터에서 파생되어 나온 엔터티들이다.
예를 들어 주무이라는 엔터티에서 파생되어 나온 주문 상세 엔터티 또는, 키 엔터티인 고객의 접속 기록을 관리하는 접속 기록 엔터티와 같은 경우도 앤ㄱ션 엔터티들이다. 액션 엔터티들도 나중에 업무가 변화하고 확장되면 메인 엔터티로 지위가 향상될 수 있다.
예) 주문 상세, 접속 기록

- 엔터티들을 키 엔터티, 메인 엔터티, 액션 엔터티로 나누는 것에 크게 주의를 기울일 필요는 없다. 중요한 것은 가장 먼저 찾아야 하는 것이 키 엔터티라는 것이다.


참고자료 : 소설처럼 읽는 DB 모델링 이야기(영진닷컴)

# 분할되어 있는 엔터티들에 주의하라.

- 엔터티의 분할을 파티셔닝(Pratitioning)이라고 하는데, 실제 물리적인 데이터베이스 설계에 있어서는 상당히 중요한 부분으로 애플리케이션이나 데이터베이스의 성능을 높이기 위해 자주 사용되는 기법이다.
파티셔닝은 보통 수직적(Vertical)과 수평적(Horizontal) 파티셔닝으로 나눌 수 있다.
간단히 설명하면, 수직적 파티셔닝은 엔터티를 분할하는 것이다. 예를 들어 엔터티에 에트리뷰트가 30개 있다면 검색 용도로 자주 사용되는 엔터티 1-1에 애트리뷰트 10개를 놓고 업데이트 용으로 자주 사용되는 엔터티 1-2에 애트리뷰트 20개를 놓도록 엔터티 1을 분리하는 것이다(이를 테이블 구조로 놓고 보았을때 정확히 세로로 칼을 대는 것인 만큼 수직적 파티셔닝이라고 이야기 한다.)

- 반대로 수평적 파티셔닝은 엔터티의 인스턴스를 기준으로 자르는 것이다. 해당 연도별로 데이타가 쌍이는 경우 1999년 엔터티, 2000년 엔터티, 2001년 엔터티와 같이 들어있는 데이터를 기준으로 엔터티를 나누는 것으로 하나의 엔터티가 가지는 인스턴스의 양을 줄여서 나중에 테이블 검색 속도를 빠르게 할 수 있다.

- 연기서 논의가 되는 파티셔닝은 수직적 파티셔닝으로 엔터티의 구조를 분리해 놓은 것에 주의하자.
실제 예를 들어보자. 엔터티 후보들을 찾다 보면 고객에 대한 일반적인 데이터들을 다루는 것과 고객에 대한 상세적인 데이터들을 다루는 것들이 분리되어 있는 경우가 있다.

- 이러한 경우 앞의 것을 '고객 일반정보'라는 엔터티 후보로, 뒤의 것을 '고객 상세정보'라는 엔터티 후보로 도출할 수 있다. 이 경우 언뜻 보면, 유형이 중복된 것이 아닌가 하고 이 두 엔터티를 살펴볼 수 있다. 하지만 두 엔터티 간에는 중복 관계도, 포함 관계도 없다.

하지만 아래 그림처럼 고객이라는 하나의 엔터티를 두 엔터티로 분리 시켜 놓은 것이므로 그럴 수 밖에 없을 것이다. 이렇게 파티셔닝 된 엔터티들은 모두 일대일 릴레이션쉽(One to One Relationship)을 맺게 된다. 그럴 수 밖에 없다. 나를 낳아준 조상이 있는 것이 아니라 잘 있는 나한테 칼을 대서 생이별을 시켜놓았으니 나머지 나의 반쪽(혹은 그 이사의 파티셔닝이 일어난 경우에는 여러 반쪽들)과 나를 합치면, 원래의 나로 돌아가게 된다.











- 엔터티 후보들을 조사하다가 이렇게 서브 타입이나 중복 관계가 아니면서 일대일 관계가 나타나면 이것이 하나의 엔터티가 쪼개어진 파티셔닝 엔터티가 아닌지 의심해 봐야 한다.
만일 그렇다면 이렇게 쪼개어진 엔터티들을 합쳐서 원래의 나로 돌아가게 하자. 절대로 논리적인 모델링에서 엔터티들을 파티셔닝 하지 말자. 파티셔닝은 오로지 물리적인 모델링에서 필요한 기술이다.



참고자료 : 소설처럼 읽는 DB 모델링 이야기(영진닷컴)

# 식별 관계 Identifying과 Non-Identifying Relationship
- Identifying 이라는 단어는 식별하고 있느냐라고 해석할 수 있다.
   ID는 식별자와 같다. ID의 원어는 Identifier 이다.
   어떤 릴레이션쉽이 Identifying이냐 Non-Identifying이냐를 구분하는 기준은 페어런트 엔터티(Parent Entity)와 차일드 엔터티(Child Entity)간에서(일대다 관계에서는 일이 되는 엔터티가 페어런트 엔터티이고, 다가 되는 엔터티가 차일드 엔터티이다) 차일드 엔터티가 페어런트 엔터티의 UID(PK, Primary Key)를 참조하는데 이 참조되는 UID가 차일드 엔터티의 UID로 포함이 되느냐이다.







- 위의 그림에서 차일드 엔터티는 페어런트 엔터티의 PK를 참조하고 있는데, 참조되는 페어런트 엔터티의 PK를 차일드 엔터티의 PK로 사용하고 있다. 이 경우 차일드 엔터티의 PK는 Child UID, Parent UID를 결합하여 사용한다.
- 차일드 엔터티가 의존적인 엔터티(Dependent Entity)로 표현된 것에 주의하자. Identifying Relationship 상태에 있기 때문에 차일드 엔터티는 페어런트 엔터티에 의존적이다. 페어런트 엔터티에 값이 없으면 차일드 엔터티가 생성될 수 없다.
- 이러한 관계를 Identifying이라고 부르는 이유는 페어런트 엔터티의 UID가 차일드 엔터티의 인스턴스를 식별하는 역할을 수행하기 때문이다. 이 경우 반드시 Child UID가 있을 필요는 없지만 Child UID와 결합하는 것이 더 일반적이다.
- 위의 그림은 하나의 엔터티만을 참조하고 있으므로 최소한 하나의 Parent UID를 차일드 엔터티가 가져야만 한다.
하지만 여러개의 엔터티들을 참조하고 있다면, 그 엔터티의 수만큼 Parent UID를 가지게 된다.
그리고 이런 경우 차일드 엔터티에 있는 Parent UID들은 페어런트 엔터티들을 참조하고 있는 것이 되므로 외부키(FK, Foreign Key)가 된다.

# Mandatory와 Optional 의 차이점은 NULL값을 허용 하느냐, 허용하지 않느냐의 차이가 있다.
- Mandatory : 필수적인 혹은 의무적인 (생략하면 안되는)
- Optional : 선택적인 (생략해도 괜찮은)








- 위의 그림은 Non-Identifying 이라 부른다.
Non-Identifying 은 그림과 같이 차일드 엔터티에서 참조하는 페어런트 엔터티의 UID 값을 참조하지만 PK로 사용 되지 않고 있다.
릴레이션에서 Parent Entity 쪽에 마름모 모양이 없으므로 Mandatory 방식이다.
이 Mandatory 에서는 NULL 값을 허용하지 않는다.
그러므로 Parent Entity에 존재하는 Parent UID 값을 Child Entity에 하나 이상 입력해야 한다.







- 위의 그림의 릴레이션에서는 Parent Entity쪽에 마름모 모양이 있으므로 Optional 방식이다.
이 Optional 방식은 Child Entity의 Parent UID 값에 NULL 값을 허용한다는 의미이다.
# 주의 할점은 NULL값을 허용하지만, NULL값이 아닐경우 반드시 Parent Entity에서 존재하는 Parent UID 값이어야 한다.


# 관계의 차수
- 릴레이션쉽에서 카디널리티라는 것은 One-to-Many 릴레이션쉽을 기준으로 페어런트 엔터티 인스턴스 하나에 몇개의 차일드 엔터티 인스턴트들이 관련되는 지를 따지는것.


참고자료 : 소설처럼 읽는 DB 모델링 이야기(영진닷컴)

# ER/Studio 자료




ER/Studio를 설치한 후 가장 먼저 확인해야 할 내용은 어떠한 표기방식을 사용할 지를 결정하는 것으로 이 것은 설치 단계에서 정의할 수도 있으나 설치된 후에도 얼마든지 ER/Studio의 표기 방식을 변경할 수 있다.
 
ER/Studio는 산업표준 설계 표기법을 지원하는데 ER/Studio에서 지원하는 표기 방식은 크게 두 가지로 하나는 IDEF1x(Integration DEFinition for Information Modeling) 표기 방식이며 다른 하나는 IE(정보공학, Information Engineering) 표기 방식이다.
 
IDEF1x 표기방식은 1986년 미 국방부에 의해 정보/데이터 모델링을 위한 표준 방법으로 채택되었고 1993년 미연방 정보처리 표준으로 채택된 모델로써 정보공학(Information Engineering) 표기법과 함께 가장 일반적으로 사용되는 표기 방법이다.
 
또한 ER/Studio에서는 정보공학(Information Engineering)표기 방식도 James Martin, Crow’s Feet, Filtered IE 등 다양한 산업 표준 설계 표기법을 지원한다.
 
ER/Studio의 표기 방식을 변경하거나 현재 정의되어 있는 표기 방식을 확인하기 위해서는 Model 메뉴 / Model Options 메뉴를 선택하면 나타나는 Model Options 대화상자의 Notation영역을 통해서 확인할 수 있다.

흔히 오리발이라 불리는 가장 일반적으로 사용되는 IE(Crow’s Feet)을 사용할 것이다.