1 DB Design > Conceptual Data Modeling

1.1 ER model concept 및 구성 요소

1.1.1 개체 (Entity)

실 세계에 존재하는 의미있는 하나의 정보 단위
표현: 사각형으로 표시
물리적 개체 뿐 아니라 추상적(개념적) 개체도 포함
- 물리적 개체: (학생, 자동차, 강의실, 등)
- 추상적 개체 : (프로젝트, 직업, 교과목)
개체는 둥근 직사각형으로 표시

1.1.2 관계 (Relationship)

개체들 사이의 연관성
- 학생과 교과목 사이의 수강 관계
- 표현: 마름모로 표시, 선으로 관련 엔티티에 연결, ex) [Student] - < Register > -[Subject]
실제로는 개체와 관계를 구분짓기 매우 힘듦 \(\rightarrow\) ER modeling 할때 의미가 없어짐 (깊게 생각하지 말것)
- ex) 결혼을 개체로 둘건지 관계로 둘건지 애매
  - [결혼] - <진행> - [예식장] vs [남자] - <결혼> - <여자>
관계는 마름모로 표시

1.1.3 속성 (attribute) (=필드명)

개체 또는 관계의 본질적 특성이나 성질
그러므로 instance는 속성들의 값의 집합
표현: 타원형으로 표시, 선으로 엔티티에 연결
예시
- 학생(개체)이 가지는 속성은 학번, 혈액형, 나이, 핸폰 번호, 성별, 학년 등이 있음
- 과목(개체)이 가지는 속성은 학점(credit), 시간(hour), 부서(department), 장소(location) 등이 있음

개체나 관계에서 파생되는 수많은 속성을 나열하고 명확하게 분리하는 것은 어려움, why?
- 다음 개체 및 관계에서 주어진 속성의 주인(Owner)은?
  - 개체: [학생], [교과목]
  - 관계: <수강>
  - 속성: (성별), (나이), (과목), (학점), (평점), (이수구분)
  - [학생]: (성별), (나이)
    - (성별), (나이) 는 비교적 명확하게 [학생] 개체에 대응되는 속성이다
  - [교과목] : (과목), (학점)
    - (과목명), (학점) 는 비교적 명확하게 [교과목] 개체에 대응되는 속성이다
  - 개체 기준으로 (평점), (이수구분) 속성은 구분짓기 애매함
    - [학생]이 (평점) 속성을 갖게 되면 학생 A에게 평점을 물어볼경우 대답을 할 수가 없음
    - 왜냐하면, 여러 과목에 대한 평점이 존재하기 때문에 어떤 교과목에 대한 평점을 얘기해야하는지 모름.
    - 즉, (평점)은 [학생]의 고유 속성이 아님.
    - 반대로, (평점) 속성의 주인이 [교과목] 개체라 가정할 경우, 교과목에 평점을 물어보면 학생이 몇 십명이기 때문에 어떤 학생의 평점을 얘기해야하는지 애매해짐.
    - 즉 (평점)은 [교과목]의 고유 속성이 아님
- (평점)과 (이수구분) 과 같은 애매한 속성은 관계로 구분 지으면 해결될 경우가 있음!
  - 관계: 개체 사이에 관계를 맺어주는 이벤트 또는 함수
  - <수강>: 학생이 교과목을 수강한 이벤트
    - (평점) : 학생 1명이 과목 1개를 수강하여 평점을 산출
    - (이수구분): 학생 1명이 과목 1개를 수강하여 이수여부 산출
  - <수강>: (평점), (이수구분)
  - 사실, (평점)과 (이수구분)과 같이 관계에 의하여 파생되는 속성은 해당 배경지식이 없는 외부인이라면 파악하기 매우 힘듦 (업무기술서가 명확히 적혀 있어야 해결 가능).

1.1.3.1 Types of Attributes(속성의 유형)

속성의 유형을 여러 기준으로 분류할 수 있음
Multi-valued (다중값 속성)
- 하나의 엔티티 인스턴스가 여러 값을 가질 수 있는 속성
- 표기: single valued (동그라미 1개로 표기) vs Multi-valued (동그라미 2개로 표기)
- 예)
  - (나이)는 한 시점에 여러 개의 값을 가질 수 없음
  - (취미)는 한 시점에 여러 개의 값을 가질 수 있음
  - CAR(자동차) ERD
    - color가 multi-valued가 2개인 이유
      - 차 한대에 여러 색상이 들어갈 수 있기 때문에
    - 싱글 value가 multi value보다 훨 씬 많음

composite attribute(복합 속성)
- simple attribute : 더이상 쪼개지지 않는 원자값을 갖는 속성
  - ex) 나이, 학번
- composite attribute
  - 여러 하위 속성으로 구성된 속성
  - 즉, 몇 개의 요소로 분해 될 수 있는 속성, 쪼개어 져도 의미를 갖을 수 있어야함
  - ex) 주소: 시 + 군 + 구 + 번지
- simple 와 composite attribute를 구분짓는 기준은 나라의 사회 제도나 단체의 시스템의 특성에 따라 변한다
  - ex) 한국은 우편 수집 창고와 우체국의 시스템에 따라 주소를 시 + 군 + 구 + 번지 또는 시 + 군 + 구 가 필요로 할 수 있다
  - 하지만 다른 나라는 주소 전체를 쓰는 시스템이라면 주소 속성이 simple attribute 로 남을 수 있다.
  - 이름의 경우 성과 이름을 가르는 시스템이 필요한 미국과 full name을 사용하는 한국의 시스템의 경우 각 상황에 맞게 modeling을 해야한다.
  - 어떤 속성이든 분해해야할 용도가 있다면 쪼개야한다.
- 위의 그림 예시에서
  - composite attribute: registration (자동차 번호판)
  - simple attribute: state(주이름) & number(자동차 고유번호)
derived vs stored attributes
- derived attribute (점선으로 표기) : 저장된 다른 데이터로부터 유도 가능한 속성
  - 총 학생 수: 그냥 instance나 학생 수를 카운트 하면 됨, 총 학생 수라는 속성은 없어도 됨
  - 각 과목의 성적 : 총점(derived), 평점(derived)
  - 주민등록번호: 나이(derived), 생일(derived)
  - derived attribute는 자주 쓰이는 통계치를 구할 때 자주 쓰임. DB에 저장할 필요는 없다.
- stored attribute: 위에서 말한 총 학생 수, 총점, 평점, 나이, 생일과 같은 derived attribute의 연산이 너무 무겁거나 너무 빈번하게 사용되는 상황이라면 DB에 data를 적재하여 연산량을 줄이는 방법 도 있다.
  - 설계자의 재량에 따라 stored와 derived의 구분 짓는다.
  - 실무에서는 파생 변수(derived)가 자주 쓰인다면 stored (실선)로 남긴다
  - 학계에서는 derived는 가급적 점선으로 표시하여 derived상태로 남긴다
Key Attributes
- key attributes: 유일성 + 최소성 을 만족시켜야함
  - 어떤 개체에 대해서 그 인스턴스가 항상 유일한 값을 갖는 속성 또는 속성들의 집합
    - 중복되는 값을 가지면 안됨
    - 키 속성은 밑줄을 그어 표시
    - ex) 학생의 학번, 책의 ISBN, 차량번호
- 특정 스냅샷이 아닌 해당 개체의 모든 가능한 스냅샷의 집합을 고려하여 파악되어야함 (개체가 아무리 많아 지더라도 항상 유일한 값을 가져야함)
  - ex) 다음의 ssn, 이름, 혈액형 중 키 속성은 ssn
- composite key(복합키)
  - entity에서 키 속성자체가 없을 경우 attributes의 조합으로도 생성가능
  - 복합키는 최소성을 가져야함 : 최소한의 attributes로 복합키를 만들어야함
- 용어 정리
  - conceptual design: key는 identifier라고 부르고
  - logical design: key는 primary key라고 부름.
    - table을 만들게 되면서 primary key라 부름
  - 하지만 identifier ≠ primary key.
  - 보통 identifier로 primary key를 만듦
- primary key 한 table에 반드시 1개만 있어야함. 없어도 안됨. primary key없으면 DB가 아님
Entity Types
- 강성 개체(strong entity)
  - 각 개체는 하나 이상의 key 속성을 가질 수 있음
  - 대부분의 개체는 key를 갖기 때문에 강성 개체라 부르는 경우는 별로 없다. 그냥 개체라 부름
- 약성 개체 (weak entity)
  - 어떤 개체는 key를 갖지 않을 수 있음
  - 자체적으로 식별될 수 없고, 다른 엔티티에 의존하는 엔티티

1.1.4 기수성 (Cardinality)

관계에 참여하는 엔티티 인스턴스의 수
표현: 1:1, 1:N, M:N 등으로 표시
ex) 한 학생은 여러 강의를 수강할 수 있음 (1:N)

1.1.5 참여 제약 (Participation Constraint):

엔티티의 관계 참여 여부
필수 참여 (전체 참여): 이중선으로 표시
선택 참여 (부분 참여): 단일선으로 표시

1.1.6 특화/일반화 (Specialization/Generalization)

상위 엔티티와 하위 엔티티 간의 관계
표현: 삼각형으로 연결
ex) ‘사람’ 엔티티의 특화로 ‘학생’과 ’교수’ 엔티티