[SQLD자격증] # 5. (1과목) 데이터 모델링의 이해 - 데이터 모델의 이해

데이터 모델링의 이해

---

⬛ 데이터 모델링

  - 데이터 모델링은 현실 세계를 데이터베이스로 표현하기 위해서 추상화 한다.
  - 데이터 모델링을 하기 위해서는 고객과의 의사소통을 통해 고객의 업무프로세스를 이해해야 한다.
  - 고객의 업무 프로세스를 이해한 후 데이터 모델링 표기법을 사용해서 모델링을 한다.
  - 데이터 모델링은 고객이 쉽게 이해할 수 있도록 복잡하지 않게 모델링 해야 한다.
  - 데이터 모델링은 고객의 업무 프로세스를 추상화하고, 소프트웨어를 분석, 설계하면서 점점 더 상세해진다.
  - 데이터 모델링은 고객의 비즈니스 프로세스를 이해하고 비즈니스 프로세스의 규칙을 정의
    정의된 비즈니스 규칙을 데이터 모델로 표현
  - 데이터 모델링 자체로서 업무의 흐름을 설명(별도의 표기 필요없음)하고 분석하는 부분에 의미를 가짐. 
  - 분석된 모델을 가지고 데이터베이스 생성하여 개발 및 데이터관리에 사용하기 위함
 
  - (데이터 모델링의 유의점)

     - 중복 : 같은 데이터를 사용하는 사람, 시간 장소를 파악하는데 도움을 줌. 여러 장소의 데이터베이스에 같은 정보를 저장하지 않도록 중복성을 최소화함.
     - 비유연성 : 사소한 업무변화에 데이터 모델이 수시로 변경되면 안됨. 데이터의 정의를 데이터의 사용 프로세스와 분리하여 유연성을 높임.(사용자가 처리하는 프로세스 혹은 이와 관련된 프로그램과 테이블의 연계성을 높이는 것은 데이터 모델이 업무 변경에 대해 취약하게 만드는 단점에 해당)
     - 비일관성 :  데이터간의 상호 연관관계를 명확하게 정의하여 일관성 있게 데이터가 유지되도록 함. (예를 들면 신용 상태에 대한 갱신 없이 고객의 납부 이력 정보 갱신 안됨. 서로 연관된 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 개발자가 수정할 수 있어 문제 발생할 수 있음.)

 
⬛ 데이터 모델링의 특징
  - 데이터 모델링은 추상화 해야 한다. → 추상화는 공통적인 특징을 찾고 간략하게 표현한다.
  - 데이터 모델링은 단순화 해야 한다. → 복잡한 문제를 피하고 누구나 이해할 수 있게 표현한다.  
  - 데이터 모델링은 명확해야 한다. → 의미적 해석이 모호하지 않고 명확하게 해석되어야 한다.
 
⬛ 데이터 모델링 단계
  ① 개념적 모델링(Conceptual Data Modeling)  
      - 고객의 비즈니스 프로세스를 분석하고 업무 전체에 대해서 업무 중심적이고 포괄적인 수준의 데이터 모델링을 정한다.    
      - 복잡하게 표현하지 않고 중요한 부분을 위주로 모델링하는 단계
      - 업무적 관점에서 모델링하며 기술적인 용어는 가급적 사용하지 않는다.
      - 추상화 수준이 가장 높은 수준의 모델링
      - 엔터티(Entity)와 속성(Attribute)을 도출하고 개념적 ERD(Entity Relationship fingar)를 작성한다.
      - 엔터티란 실체, 객체라는 의미. 즉 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것 
        (사람, 장소, 물건, 사건, 개념 등의 명사에 해당, 업무상 관리가 필요한 관심사에 해당한다.
 
  ② 논리적 모델링(Logical Data Modeling)
       - 개념적 모델링을 논리적 모델링으로 변환하는 작업으로 특정 데이터베이스 모델에 종속한다.
       - 식별자를 도출하고 필요한 모든 관계, 속성 등을 정의한다. 
       - 정규화를 수행해서 데이터 모델의 독립성을 확보하고 재사용성을 높인다.
       - 정규화의 기본 목표는 테이블 간에 중복된 데이터를 허용하지 않는다는 것이다.
       - 중복된 데이터를 허용하지 않음으로써 무결성(Integrity)를 유지할 수 있으며, DB의 저장 용량 역시 줄일
         수 있다.
       - M:N 관계형 식별자 확정, 정규화, 무결성 정의 등을 수행
       - 비즈니스 정보의 논리적 구조 및 구축을 파악


  ③ 물리적 모델링(Physical Modeling)
       - 데이터베이스를 실제 구축하는 단계. 즉, 테이블, 인덱스, 함수 등을 생성하는 단계
       - 성능, 보안, 가용성을 고려해서 데이터베이스를 구축

 
⬛ 데이터 모델링을 위한 ERD(Entity Relationship Diagram)

  - 1976년 피터첸(Peter Chen)이 Entity Relationship Model 표기법을 만들었으며, 사실상 데이터 모델링의 표준으
    로 사용되고있다.
  - 엔터티와 엔터티 간의 관계를 정의하는 모델링 방법이다.
  - 가장 중요한 엔터티를 왼쪽 상단에 배치. 
  - 아래 표기법은 IE 표기법 (만약, O | 표기가 없음 Barker 표기법)

  - ERD 작성 절차
  ⓐ 엔터티를 도출하고 그림

    : 업무에서 관리해야 하는 집합을 도출

  ⓑ 엔터티를 배치
    : 엔터티를 도출한 후 엔터티를 배치. 중요한 엔터티를 왼쪽 상단에 배치
  ⓒ 엔터티 간의 관계를 설정
  ⓓ 관계명을 서술
    : 엔터티 간의 어떤 행위나 존재가 있는지 표현
  ⓔ 관계 참여도를 표현
    : 관계 참여도는 한 개의 엔터티와 다른 엔터티 간의 참여하는 관계수를 의미
     즉, “고객이 여러 개의 계좌를 개설할 수 있다.” 와 같은 의미를 표현.
  ⓕ 관계의 필수 여부를 표현
    : 필수는 반드시 존재해야 하는 것. 예를 들어 “모든 고객은 반드시 하나의 계좌를 개설해야 한다.” 와     
      같은 의미를 표현
 
⬛ 데이터 모델링 고려사항
   ① 데이터 모델의 독립성
   - 독립성이 확보된 모델은 고객의 업무변화에 능동적으로 대응할 수 있음
   - 독립성을 확보하기 위해서는 중복된 데이터를 제거해야 한다. 데이터 중복을 제거하는 방법이 바로 정규화이다.
   ② 고객 요구사항의 표현
   - 데이터 모델링으로 고객과 데이터 모델러 간에 의사소통을 할 수 있어야 하므로, 고객의 요구 사항을 간결하
    고 명확하게 표현. 
   ③ 데이터 품질 확보
   - 데이터베이스 구축시에 데이터 표준을 정의하고 표준 준수율을 관리해야 한다.     
   - 데이터 표준을 확보해야 데이터 품질을 향상시킬 수 있다.
 
⬛ 좋은 데이터 모델의 요소
   ① 완전성 : 업무에 필요한 모든 데이터가 모델에 정의
   ② 중복배제 : 하나의 DB내에 동일한 사실은 한번만
   ③ 업무 규칙 : 많은 규칙을 사용자가 공유하도록 제공
   ④ 데이터 재사용 : 데이터가 독립적으로 설계돼야 함
   ⑤ 의사소통 : 업무 규칙은 엔터티, 서브타입, 속성, 관계 등의 형태로 최대한 자세히 표현
   ⑥ 통합성 : 동일한 데이터는 한번만 정의, 참조 활용
 
⬛ 데이터 모델링의 중요 개념
   ① 업무가 관여하는 어떤 것(Things)
   ② 업무가 관여하는 어떤 것의 성격(Attributes)
   ③ 업무가 관여하는 어떤 것의 관계(Relationships)
 
⬛ 데이터 모델링의 관점
   ① 데이터에 대한 관점; 업무가 어떤 데이터와 관련 있는지 또는 데이터 간의 관계는 무엇인지에 대해 분석 (구조 분석)
   ② 프로세스에 대한 관점; 업무에서 실제로 하는 일은 무엇인지 또는 무엇을 해야 하는 지 분석 (업무시나리오 분석)
   ③ 데이터와 프로세스 관점 ; 업무에서 처리하는 일의 방법에 따라 데이터가 어떻게 영향을 받는지 분석 (CRUD 매트릭스)

3층 스키마(3-Level Schema)

---

⬛ 3층 스키마

   - 사용자, 설계자, 개발자가 데이터베이스를 보는 관점에 따라 데이터베이스를 기술하고 이들 간의 관계를 정의한
     ANSI 표준(← 오라클, MySql 등에서 호환되도록 정의한 표준)
  - 3층 스키마는 데이터베이스의 독립성을 확보하기 위한 방법이다. 데이터의 독립성을 확보하면
     데이터 복잡도 감소, 데이터 중복 제거, 사용자 요구사항 변경에 따른 대응력 향상, 관리 및 유지보수 비용 절감
     등 의 장점을 갖는다.
  - 3단계 계층으로 분리해서 독립성을 확보하는 방법으로 각 계층을 뷰(View)라고도 한다.
  - 논리적 독립성) 개념 스키마가 변경되도 외부 스키마가 영향 받지 않음
  - 물리적 독립성) 내부 스키마가 변경되도 개념 스키마가 영향 받지 않음
 * Mapping(사상)  : 상호 독립적인 개념을 연결시켜주는 다리
     (논리적 사상 : 외부-개념 스키마 연결, 물리적 사상 : 개념-내부 스키마 연결)
 

3층 스키마 구조

 

	구조	설명
1	외부 스키마	- 사용자 관점, 업무상 관련 있는 데이터 접근(권한 설정), 사용자가 보는 개인적 DB 스키마 - 관련 데이터베이스의 일부를 표시. 뷰(View)를 표시 - 응용 프로그램이 접근하는 데이터베이스를 정의
2	개념 스키마	- 설계자 관점, 사용자 전체 관점을 통합한 전체 데이터베이스 구조 - 전체 데이터베이스 내의 규칙과 구조를 표현 - 통합 데이터베이스 구조
3	내부 스키마	- 개발자 관점, 데이터베이스의 물리적 저장 구조 - 데이터 저장 구조, 레코드 구조, 필드 정의, 인덱스 등을 의미 - 운영체제와 하드웨어에 종속적

 

엔터티(Entity)

---

⬛ 엔터티(Entity)

  - 엔터티는 업무에서 관리해야 하는 데이터 집합을 의미
  - 저장되고 관리되어야 하는 데이터
  - 엔터티는 개념, 사건, 장소 등의 명사

  - 엔터티는 고객의 비즈니스 프로세스에서 관리되어야 하는 정보를 추출해야 함
  (ex. 고객이 회원가입. 가입 시 회원Id, PW, 이름, 주소, 번호 입력. 가입 위해 반드시 하나의 계좌 개설. 고객은 계좌를 여러 개 개설 가능. 계좌 개설 시 계좌번호, 계좌명, 예수금, 계좌개설지점 등이 입력 → 고객과 계좌 엔터티 도출)
 
⬛ 엔터티(Entity)의 특징

	엔터티 특징	설명
	식별자	- 엔터티는 유일한 식별자가 있어야 함 ex) 회원ID, 계좌번호
	인스턴스 집합	- 2개 이상의 인스턴스가 있어야 함 (* 인스턴스 : 릴레이션이 가질 수 있는 값, 행의 수를 의미) ex) 고객정보는 2명 이상이 있어야 함 - 엔터티 하나의 인스턴스는 다른 엔터티의 인스턴스 간 관계인 Paring을 가짐
	속성	- 엔터티는 반드시 속성을 가지고 있음 2개 이상의 속성 ex) 고객 엔터티에 회원ID, PW, 이름, 주소 전화번호
	관계	- 엔터티는 다른 엔터티와 최소한 한 개 이상 관계가 있어야 함 ex) 고객은 계좌를 개설
	업무	- 엔터티는 업무에서 관리되어야 하는 집합. - 반드시 해당 업무에서 필요하고 관리하고자 하는 정보 - 엔터티는 업무 프로세스에 의해 이용되어야 함 ex) 고객, 계좌

⬛ 엔터티(Entity)의 종류
(1) 유형과 무형에 따른 엔터티 종류

	종류	설명
	유형 엔터티	- 업무에서 도출되어 지속적으로 사용되는 엔터티 ex) 고객, 사원, 물품 등
	개념 엔터티	- 유형 엔터티는 물리적 형태가 있지만, 개념 엔터티는 물리적 형태가 없음 - 개념적으로 사용되는 엔터티 ex) 조직, 보험상품
	사건 엔터티	- 비즈니스 프로세스를 실행하면서 생성되는 엔터티 ex) 주문, 체결, 취소주문 등

 
(2) 발생시점에 따른 엔터티 종류

	종류	설명
	기본 엔터티	- 키 엔터티라고 부르며, 다른 엔터티로부터 영향 받지 않고 독립적으로 생성되는 엔터티 - 타 엔터티의 부모 역할,  타 엔터티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가짐 ex) 고객, 상품, 부서 등
	중심 엔터티	- 기본 엔터티와 행위 엔터티 간의 중간에 있는 것 - 기본 엔터티로부터 발생되고 행위 엔터티를 생성하는 것 ex) 계좌, 주문, 취소, 체결 등
	행위 엔터티	- 2개 이상의 엔터티로부터 발생 - 자주 바뀌거나 양이 증가 ex) 주문 이력, 체결 이력 등

* 교차 엔터티 - 다:다 관계를 해소하기 위해 인위적으로 만들어진 엔터티 

⬛ 엔터티(Entity)의 명명
- 현업업무에서 사용하는 용어 사용, 약어 사용금지, 단수명사 사용, 고유한 이름 사용, 생성되는 의미대로 부여

속성(Attribute)

---

⬛속성(Attribute)

  - 속성이라는 것은 업무에서 필요한 정보인 엔터티가 가지는 항목
  - 속성은 더 이상 분리되지 않는 단위로, 업무에 필요한 데이터를 저장할 수 있음
  - 인스턴스의 구성요소이고 의미적으로 더 이상 분해되지 않는다
 
⬛속성(Attribute)의 특징
  ① 속성은 업무에서 관리되는 정보
  ② 속성은 하나의 값만 가짐 (하나의 엔터티는 2개 이상의 속성을 가짐. 하나의 인스턴스에서 각각의 속성은 한 개의 속성값을 가짐)
  ③ 주식별자에게 함수적으로 종속. 즉, 기본키가 변경되면 속성의 값도 변경됨
 
⬛속성(Attribute)의 종류
(1) 분해 여부에 따른 속성의 종류

	종류	설명
	단일 속성	- 하나의 의미로 구성된 것 ex) 회원ID, 이름
	복합 속성	- 여러 개의 의미가 있는 것 ex) 주소 - 시/군/동 등으로 분해 가능
	다중값 속성	- 속성에 여러 개의 값을 가질 수 있는 것 ex) 상품 리스트 - 다중값 속성은 엔터티로 분해된다

(2) 특성에 따른 속성의 종류

	종류	설명
	기본 속성	- 비즈니스 프로세스에서 도출되는 본래의 속성 - 일반적이고 많은 속성 ex) 회원ID, 이름
	설계 속성	- 데이터 모델링 과정에서 발생되는 속성, 업무를 규칙화하기 위해 새로 만들거나 변형/정의하는 속성 - 유일한 값을 부여, 코드성 속성 ex) 상품코드, 지점 코드, 일련번호 등
	파생 속성	- 다른 속성에 의해서 만들어지는 속성, 빠른 성능을 낼 수 있도록 원래 속성의 값을 계산 - 가급 적 속성이 적을수록 좋음 - 자신의 속성이 없어도 다른 속성을 이용. 다른 속성을 영향을 받아 발생하는 속성으로서 보통 계산된 값들 - 다른 속성에 영향을 받기 때문에 프로세스 설계 시 데이터 정합성을 유지하기 위해 유의해야 할 점이 많음 ex) 합계, 평균

 
⬛ 도메인

  - 속성이 가질 수 있는 값의 범위. ex) 성별 속성 → 도메인: 남자와 여자
  - 속성에 대한 데이터 타입, 크기, 제약사항을 지정
     (ex. 속성에 대해 NOT NULL 제약사항을 설정하여 NULL값 허용 안함)
  - 속성명과 도메인명이 반드시 동일할 필요 없음
  - 각 엔터티 속성에 도메인을 할당
  - 속성을 명사로 분리함
  - 릴레이션에서 모든 속성의 도메인은 원자적이어야 함(공통 발생하는 명사는 여러 개 도메인 생성x)
  - 속성에 값을 입력할 때 CHECK 기능을 사용해 입력값을 검사
 (* 외래키는 참조무결성을 준수하기 위해 사용, 도메인과 관련 없음)
 
⬛속성(Attribute)의  명명

  ① 해당 업무에서 사용하는 이름 부여
  ② 서술식 속성명은 사용 금지 (복합명사)
  ③ 약어 사용 금지
  ④ 전체 데이터모델에서 유일성 확보

 
 

관계(Relationship)

---

⬛ 관계(Relationship)

  - 관계는 엔터티 간의 관련성을 의미
  - 엔터티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태로서나 행위로서 서로에게 연관성이 부여된 상태, 관계 페어링의 집합
  - ex) 강사 - 가르친다(관계) - 수강생
(* 패어링 : 엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것)
  - 관계 표기법은 관계명, 관계차수, 선택성(선택사양) 3가지 개념으로 표현
 
⬛ 관계(Relationship) 종류
  - 존재 관계 : 엔터티 간의 상태를 의미
   ex) 고객이 은행에 회원가입을 하면, 관리점이 할당되고, 그 할당된 관리점에서 고객을 관리한다.
  - 행위 관계 : 엔터티 간에 어떤 행위가 있는 것
    ex)계좌를 사용해서 주문을 발주하는 관계가 만들어짐. 증권 회사는 계좌를 개설하고 주문을 발주하는 것
  - ERD에서는 관계 연결할 때 존재와 행위를 구분하지 않고 단일화된 표기법 사용
 
⬛ 관계 차수(Cardinality)
  - 두 개의 엔터티 간에 관계에 참여하는 수를 의미 (선택도 * 전체 레코드 수)
  - ex) 한 명의 고객은 여러 개의 계좌를 개설 가능 →  이러한 경우는 1대N 관계
 
⬛ 관계 차수의 종류
  ① 1대1 관계
    - 완전 1대1 관계와 선택적 1대1 관계가 있음
   ex)  한 명의 고객은 하나의 고객등급이 부여되거나 고객등급이 없을 수도 있음
    - 완전 1대1 : 하나의 엔터티에 관계되는 엔터티의 관계가 하나인 경우로, 반드시 존재
    - 선택적 1대1 :  하나의 엔터티에 관계되는 엔터티의 관계가 하나이거나 없을 수도 있음
  ② 1대N 관계
    - 엔터티에 행이 하나 있을 때 다른 엔터티의 값이 여러 개 있는 관계이다.
    - ex) 고객은 여러 개의 계좌를 가질 수 있음
  ③ M대N 관계
    - 두 개 엔터티가 서로 여러 개의 관계를 가지고 있는 것
    - ex) 한 명의 학생이 여러 개의 과목을 수강 가능 반대로 한 개의 과목은 여러 명의 학생이 수강
    - 관계형 데이터베이스에서 M대N 관계의 조인(Join)은 카테시안 곱이 발생.     
       M대N 관계를 1대 N, N대1로 해소 해야 함
  ④ 필수적 관계와 선택적 관계
    - 필수적 관계는 반드시 하나는 존재해야 하는 관계, “ | ”로 표현
    - 선택적 관계는 없을 수도 있는 관계이다. 필수적 관계, “0”으로 표현
 
 
⬛ UML(통합모델링 언어)에서의 관계
  - 연관(존재적)관계 : 항상 이용하는 관계 (ex. 소속된다)
  - 의존관계 : 상대 행위에 의해 발생하는 관계 (ex. 주문한다)
  - UML에서는 이를 구분하여 연관관계는 실선, 의존관계는 점선으로 표현
 
⬛ 관계 체크사항

  ① 2개의 엔터티 사이에 관심있는 연관 규칙o?
  ② 2개의 엔터티 사이에 정보의 조합 발생o?
  ③ 업무기술서, 장표에 관계 연결에 대한 규칙 서술o?
  ④ 업무기술서, 장표에 관계 연결을 가능케 하는 동사o?
 
⬛ 식별자 관계
  1) 식별 관계(Identification Relationship)

  ⓐ 고객과 계좌 엔터티에서 고객은 독립적으로 존재할 수 있는 강한 개체(Strong Entity)
  ⓑ 강한 개체는 어떤 다른 엔터티에게 의존하지 않고 독립적으로 존재
  ⓒ 강한 개체는 다른 엔터티와 관계를 가질 때 다른 엔터티에게 기본키를 공유
  ⓓ 강한 개체는 식별 관계로 표현
  ⓔ 식별 관계란 고객 엔터티의 기본키인 회원ID를 계좌 엔터티의 기본키의 하나로 공유하는 것
  ⓕ 강한 개체의 기본키 값이 변경되면 식별관계(기본키를 공유 받은)에 있는 엔터티의 값도 변경
  ⓖ 여기서 계좌 엔터티는 약한 개체(Week Entity)

  2) 비식별 관계(Non-Identification Relationship)
  ⓐ 강한 개체의 기본키를 다른 엔터티의 기본키가 아닌 일반 칼럼으로 관계를 가지는 것이다. 
  ⓑ 예를 들어 부서 엔터티의 기본키는 부서 코드이고 사원 엔터티와 비식별 관계 라고 하면
      즉, 부서 코드는 고객 엔터티의 기본키가 아닌 일반 칼럼으로 참조.
  ⓒ 비식별 관계는 점선으로 표현한다.

  3) 강한 개체(Strong Entity)와 약한 개체(Weak Entity)
  ⓐ 강한 개체는 누구에게도 지배되지 않는 독립적인 개체(Entity)
  ⓑ 약한 개체는 개체의 존재가 다른 개체의 존재에 달려 있는 개체
 

엔터티 식별자(Entity Indentifier)

---

- 엔터티 내에서 인스턴스를 구분하는 구분자
- 식별자는 논리적, Key는 물리적 데이터 모델링 단계에 사용
- 엔터티를 대표할 수 있는 유일성을 만족하는 속성
ex) 회원ID, 계좌번호, 주민등록번 호, 외국인 등록번호, 여권 번호 등이 있음
 

⬛ 키 종류

	종류	설명
	기본 속성	- 비즈니스 프로세스에서 도출되는 본래의 속성 ex) 회원ID, 이름
	설계 속성	- 데이터 모델링 과정에서 발생되는 속성, 업무를 규칙화하기 위해 새로 만들거나 변형/정의하는 속성 - 유일한 값을 부여 ex) 상품코드, 지점 코드, 일련번호 등
	파생 속성	- 다른 속성에 의해서 만들어지는 속성, 빠른 성능을 낼 수 있도록 원래 속성의 값을 계산 - 적을수록 좋음 ex) 합계, 평균

 
⬛ 식별자의 종류

  1) 식별자의 대표성
  - 주식별자 : 엔터티를 대표할 수 있는 식별자 (ex. 회원ID는 고객 엔터티에 주식별자)  
     - 주식별자는 다른 엔터티와 참조 관계로 연결될 수 있음
     - 주식별자 도출 기준)
       해당 업무에서 자주 이용되는 속성,
       명칭/내역 등과 같이 이름으로 기술되면 X,
       복합으로 주식별를 구성할 경우 너무 많은 속성X(너무 많으면 인조식별자 생성)
     - 유일성 : 엔터티 내 모든 인스턴스들은 유일
     - 최소성 : 속성의 수는 유일성을 만족해야 하고 최소의 수가 되어야 함
     - 불변성 : 식별자의 값은 변하지 않아야 함
     - 존재성 : 반드시 값이 존재해야 함
  - 보조 식별자 :  유일성과 최소성은 만족하지만 대표성을 만족하지 못하고 참조 관계로 연결될 수 없는 식별자
 
  2) 생성 여부 
   - 내부 식별자 : 엔터티 내부에서 스스로 생성되는 식별자 (ex. 부서코드, 종목 코드 등)
   - 외부 식별자 : 다른 엔터티와의 관계로 만들어지는 식별자(ex. 계좌 엔터티에 회원ID)
 
  3) 속성의 수
   - 단일 식별자 : 하나의 속성으로 구성 (ex. 고객 엔터티의 회원ID)
   - 복합 식별자 : 두 개 이상의 속성으로 구성
 
  4) 대체 여부
   - 본질 식별자 : 비즈니스 프로세스에서 만들어지는 식별자
   - 인조 식별자 : 인위적으로 만들어지는 식별자. 식별자로 후보 식별자 중에서 주식별자로 선정할 것이 없거나
                           주식별자가 너무 많은 컬럼으로 되어 있는 경우에 사용하는데 그 예는 순서 번호를 사용
 
 
⬛ 식별자 관계와 비식별자 관계

1) 주식별자 : 자식의 주식별자로 부모의 주식별자 상속
 - 부모로부터 받은 식별자를 자식엔터티의 주식별자로 이용하는 경우
 - 강한 연결관계 표현, 실선 표기
 - 부모엔터티의 주식별자를 자식엔터티에서 받아 손자엔터티까지 계속 흘려 보내기 위해서는 식별자관계를 고려해야 함
 
2) 비식별자 : 부모 속성을 자식의 일반 속성으로 사용
  ① 부모엔터티에 참조값이 없어도 자식엔터티의 인스턴스가 생성될 수 있는 경우
  ② 부모와 자식의 생명주기가 다른 경우(부모엔터티의 인스턴스가 자식의 엔터티와 관계를 가지고 있었지만 자식만 남겨두고 먼저 소멸될 수 있는 경우)
  ③ 여러 개의 엔터티가 하나의 엔터티로 통합(각각의 엔터티가 갖고 있던 여러 개의 개별 관계가 통합)되어 표현되었는데
      각각의 엔터티가 별도의 관계를 가진 경우
  ④ 자식엔터티에 별도의 주식별자를 생성하는 것이 더 유리한 경우
  ⑤ SQL 문장이 길어져 복잡성 증가되는 것 방지
  - 약한 연결관계 표현, 점선 표기

항목	식별자 관계	비식별자 관계
목적	강한 연결관계 표현	약한 연결관계 표현
자식 주식별자 영향	자식 주식별자의 구성에 포함됨	자식 일반 속성에 포함됨
표기법	실선 표현	점선 표현
연결 고려사항	- 반드시 부모엔터티 종속 - 자식 주식별자구성에 부모 주식별자 포함 필요 - 상속받은 주식별자 속성을 타엔터티에 이전 필요	- 약한 종속관계 - 자식 주식별자구성을 독립적으로 구성 - 자식 주식별자구성에 부모 주식별자 부분 필요 - 상속받은 주식별자 속성을 타 엔터티에 차단 필요 - 부모쪽의 관계 참여가 선택 관계