1) 주제영역
연관성을 가진 엔터티 그룹화 → 가독성 향상
여러 개발자간 업무 분할 용이
2) 엔터티
- 5개 유형 (Thomas Bruce, 1992)
순번 | 항목 |
예시 | 비고 |
1 | 관계업무자 |
법인, 고객, 회원 | 업무의 시발점 관계를 맺는 table이 多 → PK 구조를 단순화해야 함 (본질식별자 < 인조식별자) |
2 | 자원/아이템 |
상품, 부동산, 주식 |
|
3 | 계약 |
구매계약 | 본 업무로, 빈번한 insert가 발생. pk 채번 효율화 |
4 | 거래/이벤트 |
주문, 신청 |
|
5 | 위치/장소 |
지역, 건물 |
- 실제 엔터티 작성 시 '속성' 으로 설정할 것인지, '엔터티'로 작성할 것인지 고민 필요 ex) 교사, 남자 교사를 구분해야 할 때, 교사 엔터티 안에 교사성별 속성으로 남자 교사를 표시할지, 남자 교사 엔터티를 별도로 작성할지 업무에 따라 고민해야 함
- 식별자가 인조식별자인 경우, max 채번 < sequence
(why? select max를 수행하면 해당 table 전체에 lock이 걸린다. insert가 빈번하게 발생하는 경우라면, 성능상 문제가 될 수 있다.)
단, max 채번은 업무규칙을 쉽게 이해할 수 있는 장점이 있다. 또한 사번, 학번과 같이 실제로 사용자들이 현실에서 사용하는 번호라면, max로 채번하는 것이 좋다. (학번이 sequence 결과 값이라고 해보자..-_-;) 관리자 page insert, 배치의 경우 max 채번도 가능함.
3) 관계
속성 |
설명 |
cardinality |
1:1, 1:N, M:N 관계 RDB 에서 속성값은 atomic value 로 여러개의 값이 들어가지 못한다. 따라서 M:N 관계를 2개의 table로는 표현할 수 없다. 별도의 관계 테이블을 생성해야 한다. |
optionality |
optional, mandatory 자식이 optional/mandatory 여부 : 부모에 transaction(ex. insert)이 발생했을 때, 자식에 transaction(ex. insert) 발생 여부 부모에 optional/mandatory 여부 : 자식 table 의 외래키가 nullable (optional), not null (mandatory) |
membership |
쌍방 간에 업무상 어떤 관계가 있는가 표시, erd 에서 표시하지 않는다. |
관계 유형
- 식별 관계 (Identifying Relationship) VS. 비식별 관계 (Non-identifying Relationship)
식별 관계 |
- 외래키가 자식 table 의 PK로, 외래키로 자식 테이블 식별 가능 - 관계선은 실선, 자식 테이블은 모서리가 둥근 직사각형 |
비식별 관계 |
외래키가 자식 table 의 일반 속성으로, 외래키로 자식 테이블 식별 불가능 - 관계선은 점섬, 자식 테이블은 직사각형 |
4) 식별자
구분 |
설명 | 특성 |
본질식별자 |
기본 속성 중 일부가 식별자가 됨 | 업무규칙을 쉽게 이해할 수 있음 |
인조식별자 |
sequence | 자식 엔터티의 주식별자를 단순화할 수 있음 |
5) 속성
분류 |
특성 |
기본 속성 |
ex. 이름, 성별 |
설계 속성 |
성별구분코드, 사원번호 |
파생 속성 |
연계되어 파생된 속성, 연계된 기본 속성이 변경되면 파생 속성도 변경되어야 함. 따라서 data integrity를 해칠 수 있음. 파생 속성은 최소화 |
'Programming Theory > Data Modeling' 카테고리의 다른 글
Data Modeling pattern (0) | 2016.07.22 |
---|---|
Data Modeling 절차 (0) | 2016.07.21 |
정규화 (0) | 2016.07.20 |