[1. 데이터 모델의 이해]

데이터 모델링

• 정보시스템을 구축하기 위한 데이터관점의 업무 분석 기법
• 현실세계의 데이터(What)에 대해 약속된 표기법에 의해 표현하는 과정
• 데이터베이스를 구축하기 위한 분석/설계의 과정

개념적 데이터 모델링 (Conceptual Data Modeling)

• 추상화 수준이 높고 업무 중심적이고 포괄적인 수준의 모델링 진행. 전사적 데이터 모델링. EA수립시 많이 이용

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

• 시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등을 정확하게 표현. 재사용성이 높음

물리적 데이터 모델링 (Physical Data Modeling)

• 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계

데이터 독립성

• Applications insulated from how data is structured and stored.

데이터베이스 3단계 구조

External Schema (or View)

• Describe how users see the data

Conceptual (or Logical) Schema

• Defines logical structure
• Describe the stored data in terms of data model

Physical Schema

• Describes the files and indexes used
• Describe how the relations in conceptual schema are actually stored on secondary storage devices

-> 이 단계에 따라서 Schema에 따라 독립성을 보장해야함

Logical Data Independence

• Protection from changes in logical structure of data
• Logical schema가 변경되어도 External schema에 영향 X
• 논리적 구조가 변경되어도 응용프로그램에 영향 X

Physical Data Independence

• Protection from changes in physical structure of data
• Physical schema가 변경되어도 External, Logical schema는 영향 X
• 저장장치의 구조변경은 응용프로그램과 Logical schema에 영향 X

사상 (Mapping)

• 논리적 사상: 외부스키마와 개념스키마를 연결
• 물리적 사상: 내부스키마와 개념스키마를 연결

데이터 모델링의 3요소

• Things, Attributes, Relationships

데이터 모델 표기법

• ERM (Entity Relationship Model)
  -> 작업 순서: 1) 엔티티를 그린다 2) 엔티티를 적절하게 배치한다 3) 엔티티간 관계를 설정한다 4) 관계명을 기술한다 5) 관계의 참여도를 기술한다 6) 관계의 필수여부를 기술한다

좋은 데이터 모델의 요소

• 완정성: 업무에서 필요로하는 모든 데이터가 데이터 모델에 정의되어 있어야 한다.
• 중복배제: 하나의 데이터베이스 내에 동일한 사실은 한 번만 기록하여야 한다.
• 업무규칙: 많은 업무규칙을 사용자가 공유하도록 제공해야 한다.
• 데이터 재사용: 데이터가 독립적으로 설계되어야 한다.
• 의사소통: 업무 규칙은 엔티티, 서브타입, 속성, 관계 등의 형태로 최대한 자세하게 표현되어야 한다.
• 통합성: 바람직한 데이터 구조의 형태는 동일한 데이터는 조직의 전체에서 한번만 정의되고 이를 여러 다른 영역에서 참조, 활용하는 것이다.

[2. Entity]

엔티티의 개념

• 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것(Thing), 보이지 않는 개념 포함
• ex)
  '학생': 엔티티
  '학번', '이름', '이수학점': 속성
  '학생1': 인스턴스

엔티티의 특징

1. 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
2. 유일한 식별자에 의해 식별이 가능해야 한다. (primary key)
3. 두 개 이상의 인스턴스의 집합이어야 한다.
4. 엔티티는 업무 프로세스에 의해 이용되어야 한다.
5. 엔티티는 반드시 속성(Attributes)이 있어야 한다.
6. 엔티티는 다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다 -> 통계성/코드성 엔터티는 관계 생략 가능

엔티티의 분류

유무형에 따른 분류

• 유형엔티티: 물리적인 형태가 있고 안정적이며 지속적으로 활용되는 엔티티. ex) 사원, 물품, 강사
• 개념엔티티: 물리적인 형태는 존재하지 않고 관리해야할 개념적 정보로 구분이 되는 엔티티. ex) 조직, 보험상품
• 사건엔티티: 업무를 수행함에 따라 발생되는 엔티티로서 비교적 발생량이 많으며 각종 통계자료에 이용될 수 있다. ex) 주문, 청구, 미납

발생시점에 따른 분류

• 기본엔티티: 그 업무에 원래 존재하는 정보로서 다른 엔티티와 관계에 의해 생성되지 않고 독립적으로 생성이 가능하고 자신은 타 엔티티의 부모의 역할을 하게 된다. 다른 엔티티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가지게 된다. ex) 사원, 부서, 고객, 상품, 자재
• 중심엔티티: 기본엔티티로부터 발생되고 그 업무에 있어서 중심적인 역할을 한다. 데이터의 양이 많이 발생되고 다른 엔티티와의 관계를 통해 많은 행위엔티티를 생성한다. ex) 계약, 사고, 예금원장, 청구, 주문, 매출
• 행위엔티티: 두 개 이상의 부모엔티티로부터 발생되고 자주 내용이 바뀌거나 데이터량이 증가된다. ex) 주문목록, 사원변경이력

엔티티의 명명

• 가능하면 현업에서 사용하는 용어
• 가능하면 약어를 사용하지 않음
• 단수명사를 사용함
• 모든 엔티티에서 유일하게 이름이 부여되어야함
• 엔티티의 생성의미대로 이름을 부여함

[3. Attribute]

속성 (Attribute)의 개념

• 업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위
  -> 업무에서 필요로 한다.
  -> 의미상 더 이상 분리되지 않는다.
  -> 엔티티를 설명하고 인스턴스의 구성요소가 된다.

엔티티, 인스턴스, 속성, 속성값(value)

• 엔티티에는 두 개 이상의 인스턴스가 존재 (한 개의 엔티티는 두 개 이상의 인스턴스의 집합이어야 한다)
• 엔티티는 두 개 이상의 속성을 갖음 (한 개의 엔티티는 두 개 이상의 속성을 갖는다)
• 하나의 인스턴스는 각각의 속성들에 대해 한 개의 속성값만을 가질 수 있음 (한 개의 속성은 한 개의 속성값을 갖는다)

속성의 특징

• 엔티티와 마찬가지로 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
• 정규화 이론에 근간하여 정해진 주식별자에 합수적 종속성을 가져야 한다.
• 하나의 속성에는 한 개의 값만을 가진다. 하나의 속성에 여러 개의 값이 있는 다증값일 경우 별도의 엔티티를 이용하여 분리한다.

속성의 분류

속성의 특성에 따른 분류

• 기본속성: 업무분석을 통해 바로 정의한 속성
• 설계속성: 원래 업무상 존재하지는 않지만 설계를 하면서 도출해내는 속성
• 파생속성: 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성

엔티티 구성방식에 따른 분류

• PK(Primary Key)속성: 엔티티를 식별할 수 있는 속성
• FK(Foreign Key)속성: 다른 엔티티와의 관계에서 포함된 속성
• 일반속성: 엔티티에 포함되어 있고 PK, FK에 포함되지 않은 속성

도메인

• 속성이 가질 수 있는 값의 범위. 데이터 타입, 크기, 제약사항 등 ex) 학점은 0 ~ 4.5 사이의 실수값

속성의 명명

1. 해당 업무에서 사용하는 이름을 부여한다.
2. 서술식 속성명은 사용하지 않는다.
3. 약어사용은 가급적 제한한다.
4. 전체 데이터모델에서 유일성 확보하는 것이 좋다.

[4. Relationship]

관계의 개념

• 엔티티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태로서나 행위로서 서로에게 연관성이 부여된 상태
• 패어링 : 엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것
• 개별 인스턴스가 각각 다른 종류의 관계를 가지고 있다면 두 엔티티 사이에 두 개 이상의 관계가 형성될 수 있다.

관계의 분류

• 연관관계(실선) : 항상 이용하는 관계 ex) 소속된다.
• 의존관계(점선) : 상대 행위에 의해 발생하는 관계 ex) 주문한다.

관계의 표기법

• 관계명: 관계의 이름
• 관계차수: 1:1, 1:M, M:N -> 한 개가 참여하는 경우 실선, 다수가 참여한 경우 까마귀발과 같은 모양
  
• 관계선택사양: 필수관계, 선택관계

[5. 식별자]

식별자(Idendifiers) 개념

• 식별자란 하나의 엔티티에 구성되어 있는 여러 개의 속성 중에 인티티를 대표할 수 있는 속성을 의미하며 하나의 엔티티는 반드시 하나의 유일한 식별자가 존재해야 한다.
• 식별자라는 용어는 업무적으로 구분이 되는 정보로 생각할 수 있으므로 '논리 데이터 모델링' 단게에서 사용하고 키는 데이터베이스 테이블에 접근을 위한 매개체로서 '물리 데이터 모델링' 단계에서 사용한다.

식별자의 특징

• 주식별자에 의해 엔티티내에 모든 인스턴스들이 유일하게 구분되어야 한다. (유일성)
  -> 예) 사원번호가 주식별자가 모든 직원들에 대해 개인별로 고유하게 부여됨

• 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다. (최소성)
  -> 예) 사원번호만으로도 고유한 구조인데 사원분류코드+사원번호로 식별자가 구성될 경우 부적절한 주식별자 구조임

• 지정된 주식별자의 값은 자주 변하지 않는 것이어야 한다. (불변성)
  -> 예) 사원번호의 값이 변한다는 의미는 이전기록이 말소되고 새로운 기록이 발생되는 개념임

• 주식별자가 지정이 되면 반드시 값이 들어와야 한다. (존재성)
  -> 예) 사원번호 없는 회사직원은 있을 수 없음

식별자 분류

대표성 여부

• 주식별자: 엔티티 내에서 각 어커런스를 구분할 수 있는 구분자이며, 타 엔티티와 참조관계를 연결할 수 있는 식별자
• 보조식별자: 엔티티 내에서 각 어커런스를 구분할 수 있는 구분자이나 대표성을 가지지 못해 참조관계 연결을 못함

스스로 생성 여부

• 내부식별자: 엔티티 내부에서 스스로 만들어지는 식별자
• 외부식별자: 타 엔티티와의 관계를 통해 타 엔티티로부터 받아오는 식별자

속성의 수

• 단일식별자: 하나의 속성으로 구성된 식별자
• 복합식별자: 둘 이상의 속성으로 구성된 식별자

대체 여부

• 본질식별자: 업무에 의해 만들어지는 식별자
• 인조식별자: 업무적으로 만들어지지는 않지만 원조식별자가 복잡한 구성을 가지고 있기 대문에 인위적으로 만든 식별자

주식별자 도출기준

• 해당 업무에서 자주 이용되는 속성을 주식별자로 지정한다
• 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않는다
• 복합으로 주식별자로 구성할 경우 너무 많은 속성이 포함되지 않도록 한다 -> 너무 많으면 아래 사진처럼 인조식별자를 생성
  

식별자관계와 비식별자관계에 따른 식별자

식별자 관계

• 자식엔티티의 주식별자로 부모의 주식별자가 상속이 되는 경우
  -> 강한 연결관계 표현, 실선 표기
  -> 식별자 관계로만 설정 시 주식별자 증가로 오류 유발

비식별자 관계

• 부모엔티티로부터 속성을 받았지만 자식엔티티의 주식별자로 사용하지 않고 일반적인 속성으로만 사용하는 경우
  1) 자식엔티티에서 받은 속성이 반드시 필수가 아니어도 무방하기 때문에 부모 없는 자식이 생성될 수 있는 경우
  2) 엔티티별로 데이터의 생명주기(Life Cycle)를 다르게 관리할 경우
  3) 여러 개의 엔티티가 하나의 엔티티로 통합되어 표현되었는데 각각의 엔티티가 별도의 관계를 가질 때
  4) 자식엔티티에 주식별자로 사용하여도 되지만 자식엔티티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단될 때, 비식별자 관계에 의한 외부식별자로 표현한다
  4) SQL 문이 길어져 복잡성 증가되는 것 방지하기 위한 경우