eunzae's develog
[데이터 모델링] 논리적 데이터 모델링(Logical Data Modeling) 본문
Relational Data Model(RDB, 관계형 데이터베이스)
용어 | 설명 |
Table (Relation) |
행과 열의 2차원 구조를 가진 데이터 저장 객체(Object) |
Column (Field, Attribute) |
테이블에서 세로 방향으로 이루어진 개별 속성 |
Row (Record, Tuple) |
테이블에서 가로 방향으로 이루어진 연결된 데이터 |
Relational Model Constraints
도메인 제약(Domail Constraints): 속성(Attribute)에 대한 제약
- 속성 값은 원자성*을 가지며, 도메인에서 정의된 값이어야 함
* 원자성: 더 이상 분해되지 않음
- Composite Attribute와 Multivalued Attribute는 허용되지 않음
· cf) 주소 = 시군구 + 상세주소
- Null 값은 허용됨(Not Null이 아닌 경우)
<도메인 제약조건에 위배되는 튜플 예시>
학번 | 이름 | 나이 | 차량번호 | 취미 |
1234 | 홍길동 | 21 | 01가 1234 | 체조 |
5678 | 강감찬 | 고려 | 축구, 농구, 배구 |
키 제약(Key Constraints): 릴레이션(Relation)에 대한 제약
- 릴레이션의 모든 튜플(Tuples)은 서로 실별 가능해야 함
- Super Key(유일하게 구별할 수 있는 속성들의 집합), Candidate Key(후보키), Primary Key(PK, 주키, 기본키)
<키 제약조건에 위배되는 릴레이션 예시>
- 키로 설정할 수 있는 속성이 없음
이름 | 나이 | 혈액형 | 전공 |
홍길동 | 21 | A | 경영정보 |
강감찬 | 22 | O | 정보시스템 |
<키 제약조건에 위배되지 않는 릴레이션 예시>
- 학번, 주민번호 → 후보키(Candidate Key)
이름 | 나이 | 학번 | 주민번호 |
홍길동 | 21 | 1234 | 111-2222 |
강감찬 | 22 | 5678 | 333-4444 |
개체 무결성 제약(Entity Integrity Constraints): 기본키(Primary Key)에 대한 제약
- 기본키(PK, Primary Key)는 UNIQUE 하고 Not null이어야 함
<개체 무결성 제약조건에 위배되지 않는 튜플 예시>
학번 | 이름 | 나이 | 차량번호 |
1234 | 홍길동 | 21 | 01가 1234 |
5678 | 강감찬 | 22 | |
김유신 | 23 | ||
1234 | 유관순 | 02나 3456 |
참조 무결성 제약(Referential Integrity Constraints): 외래키(Foreign Key)에 대한 제약
- 외래키(FK, Foreign Key)
· 릴레이션 R1이 릴레이션 R2를 참조하는 경우, R2의 기본키는 R1에서 외래키로 사용됨
· 외래키는 자기 자신이 속한 릴레이션을 참조할 수도 있음(Unary Relationship)
<학생 테이블>
학번 | 이름 | 나이 | 소속 | 멘토 |
1234 | 홍길동 | 21 | MIS | |
2345 | 강감찬 | 22 | MIS | 1234 |
3456 | 김유신 | 23 | 경영 | |
4567 | 유관순 | 22 | 컴공 | 2345 |
<학과 테이블>
학과명 | 정원 | 위치 |
MIS | 100 | 경상관 |
경영 | 200 | 경상관 |
컴공 | 100 | 공학관 |
수학 | 50 | 자연관 |
<참조 무결성 제약조건에 위배되는 튜플 예시>
학번 | 이름 | 나이 | 소속 | 멘토 |
1234 | 홍길동 | 21 | MIS | |
2345 | 강감찬 | 22 | MIS | 1234 |
3456 | 김유신 | 23 | 5678 | |
4567 | 유관순 | 22 | 자동차 | 2345 |
학과명 | 정원 | 위치 |
MIS | 100 | 경상관 |
경영 | 200 | 경상관 |
컴공 | 100 | 공학관 |
수학 | 50 | 자연관 |
ER-to-Relational Model 변환 규칙
Step1: Mapping of Strong Entity Types(about Entity) → Table
Step2: Mapping of Weak Entity Types(about Entity) → Table
Step3: Mapping of Binary 1:N Relationship Types(about Relationship) → 관계 삭제 → FK
Step4: Mapping of Binary 1:1 Relationship Types(about Relationship) → 관계 삭제 → FK
Step5: Mapping of Binary M:N Relationship Type(about Relationship) → Table
Step6: Mapping of N-ary Relationship Types(about Relationship) → Table
Step7: Mapping of Multivalued Attributes(about Attributes) → Table
Step1: Strong Entity Types
ⓛ 각 strong entity E에 대응되는 릴레이션 R을 생성함
- E의 Single-valued/Simple/Stored attributes를 모두 R의 속성으로 포함시킴
- Composite Attributes의 경우 각 하위 컴포넌트만 포함시킴
- Multivalued Attributes는 추후 고려
② E의 키 속성 중 하나를 선택하여 R의 기본키(Primary Key)로 정함
- Composite Key의 경우, 이에 속한 속성들의 조합이 R의 기본키가 됨
<직원 엔터티>
* Composite Attributes인 '주소'는 하위 컴포넌트인 '시도'와 '상세주소'만 포함
<부서 엔터티>
* Multivalued Attributes인 지역은 추후 고려
* Identifier인 '부서명'과 '부서번호' 중 '부서번호'를 기본키(Primary Key)로 지정(주로 코드화된 번호를 기본키로 지정)
<프로젝트 엔터티>
* Multivalued Attributes인 지역은 추후 고려
* '지역'을 그냥 사용해도 무방하나, 여러 엔터티에 '지역' 속성이 있으니 설계와 활용을 고려하여 직관적인 '프로젝트지역'이라는 명칭을 사용
Step2: Weak Entity Types
ⓛ 각 weak entity W에 대응되는 릴레이션 R을 생성하고, W의 Single-valued/Simple/Stored attributes를 모두 R의 fields로 포함시킴
② W의 식별 개체 E에 대해서, E의 기본키를 R의 외래키로 포함시킴
③ R의 기본키는 E의 기본키와 W의 부분키(Partial Key)의 조합으로 구성
<부양가족 엔터티>
* Weak Entity의 identifying relationship(식별관계) 건너편에 있는 Strong Entity의 Primary Key를 사용
- '부양가족' 엔터티는 Weak Entity 이므로, '직원' 엔터티의 기본키인 '주민번호'를 '부양가족' 엔터티의 기본키로 지정
* '직원_주민번호'와 '부양가족명'은 각각 Partial Key이며, 이 두 키를 합쳐 Composite Key라고 부른다
Step3: Binary 1:N RelationShip ation Types
각 Bianry 1:N Relationship RS에 대해, 이 Relationship에 참여하는 두 Entity를 각각 S(N-Side)와 T(1-side)라고 하면
- T의 기본키를 S의 외래키로 포함
- RS에 속한 모든 Simple attributes를 S에 포함시킴
<소속 릴레이션십>
* 1이 표기된 반대쪽의 엔터티인 '직원'엔터티로 '부서'엔터티의 기본키를 포함시킴
* '직원'테이블의 '부서번호'는 '부서'테이블의 '부서번호'를 참조한 Foriegn Key가 됨
<관리 릴레이션십>
<감독 릴레이션>
* Unary Relationship이므로 상사의 주민번호를 Foreign Key로 포함시킴
Step4: Binary 1:1 RelationShip Types
릴레이션십을 원하는 엔터티쪽으로 이동시킴(어느 쪽으로 가도 상관없음)
<관리 릴레이션십>
* '직원'테이블에 본인이 관리하고 있는 '관리_부서번호'를 적거나, '부서'테이블에 '관리자_주민번호'를 포함시킴
* '관리'릴레이션에 속해있는 '관리시작일' 속성도 함께 포함시킴
※ 실무에서는 릴레이션이 속성을 가질 수 없음
Step5: Binary 1:1 RelationShip Types
ⓛ 각 Binary M:N Relationship RS에 대해, 이 Relationship에 참여하는 두 entity를 각각 S와 T라고 하면
② RS에 대응되는 새로운 릴레이션 R을 생성함
③ RS에 속한 모든 Simple attributes를 R에 포함시킴
④ S와 T의 기본키를 R의 외래키로 포함
- R의 기본키는 S에서 온 외래키와 T에서 온 외래키의 조합으로 구성
<참여 릴레이션십>
Step6: N-ary RelationShip Types
ⓛ 각 N-ary Relationship RS에 대해, 새로운 릴레이션 R을 생성함
- (N>2인 경우 해당됨)
② RS의 모든 Simple Attributes를 R의 속성으로 포함시킴
③ RS에 참여하는 모든 Entity의 기본키를 R의 외래키로 포함시킴
④ R의 기본키는 모든 외래키의 조합으로 구성됨
- 단 대응수가 1인 관계로부터 가져온 외래키는 기본키의 조합에서 빠짐
<N-ary Relationship 예시>
* SUPPLY 테이블 생성 후 SUPPLY에 참여하는 모든 기본키를 속성으로 포함시킴
* 'Sname'은 대응수가 1이므로 기본키의 조합에서 제외
Step7: Multivalued attributes
ⓛ Entity E에 속한 Multivalued Attribute MA에 대해 릴레이션 R 생성
② MA의 속성을 R에 포함시킴(→ Attribute A)
③ E의 기본키 K를 R의 외래키로 포함시킴
④ R의 기본키는 K와 A의 조합으로 구성됨
기타: Generalization(일반화)
참고: https://www.youtube.com/watch?v=T9UFLT7_MhY&list=PLg_wJlcMiuKtlmoC2Pn8H2LY84NzVKUXg&index=2
'Database > Data Architecture' 카테고리의 다른 글
[데이터모델링] 정규화 (0) | 2023.03.16 |
---|---|
[정보계]OLTP vs OLAP (1) | 2023.03.14 |
[데이터 모델링]개념 데이터 모델링(Conceptual Data Modeling) (0) | 2022.12.21 |
[DA] 코드, ID, 번호 도메인의 차이점 (0) | 2022.08.09 |
[Datastage]컬럼명 변경 절차 (0) | 2022.05.07 |