eunzae's develog

[데이터 모델링] 논리적 데이터 모델링(Logical Data Modeling) 본문

Database/Data Architecture

[데이터 모델링] 논리적 데이터 모델링(Logical Data Modeling)

eunzae 2022. 12. 26. 09:44

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