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

국민대학교 김남규 교수님 강의를 보고 정리한 글입니다.

---

1. 모델링이란?

- 복잡한 현실세계를 추상화, 단순화하여 일정한 표기법에 의해 명확하게 표현하는 것

- 추상화(덜 중요한 것을 가리고 더 중요한것을 강조), 단순화, 명확화⁠ → ⁠⁠⁠구체화, 복잡화, 일반화 등이 아님

- 모델(Model) : 현실 세계의 추상화된 반영 (ER 모델링을 통해 ER모델이 나옴)

2. 모델링의 관점

- 데이터 관점 (What) : 무엇이 필요한지에 대한 관점

1. 데이터와 데이터 간 관계, 업무와 데이터 간 관계를 모델링 (프로세스에서 사용하는 데이터를 모델링한다.)

2. 데이터에 접근하는 방법(How), 사람(Who)과는 무관

- 프로세스 관점 (How) : 어떤 절차로, 어떤 순서로 이루어지는지에 대한 관점

3. 데이터 모델링의 단계 (학계와 산업계의 이해)

현실세계의 개체를 개념적 데이터 모델링을 수행하면 개념적 구조가 나오게 되고
개념적 구조에 대해 논리적 데이터 모델링을 수행하게 되면 논리적 구조가 나오고
논리적 구조에 대해 물리적 데이터 모델링을 수행하면 물리적 구조가 나오는데 그 물리적 구조가 DB가 된다.

논리적 구조와 물리적 구조를 합쳐서 물리 세계라고 부르고
개념적 구조와 논리적 구조를 합쳐서 개념세계라고 부르게 된다.

(학계와 산업계의 이해)

4. 데이터 독립성

- 파일 시스템

1. 같은 데이터가 여러곳에서 중복되기 때문에 공간적, 계산적 낭비가 심하다.

2. 정보가 바뀌면 데이터 불일치 현상이 일어난다.

3. 동일한 데이터를 중복으로 관리했기 때문에 문제가 발생했다.

- 데이터베이스 시스템

1. 동일한 데이터는 중복 관리하지 말고, 한곳에서 관리해서 나눠서 쓰자 (데이터 중복 제거)

2. 프로그램과 데이터를 구분해서 독립성을 보장

- 데이터베이스의 3단계 구조

→ 데이터 모델링은 통합 관점의 개념 스키마를 만들어 가는 과정

1. 외부 스키마(External Schema) : 응용 프로그램 관점에서 요구사항을 말함
   각 사용자 또는 응용프로그램이 바라보는 스키마

2. 개념 스키마(Conceptual Schema) : 외부 스키마가 필요로한 데이터들을 모아둔것. 어떻게 모아둬야 위에 있는 응용 프로그램들이 효율적으로 잘 가져갈 수 있을까를 설계하는 과정 → 데이터베이스 모델링이 여기에 해당
   모든 사용자의 관점을 통합한 스키마. DB에 저장되는 데이터와 그들 간의 관계를 표현

3. 내부 스키마(Physical Schema) : 개념 스키마를 실제 물리적으로 저장해두는 구조
   DB가 물리적으로 저장된 형식

- 데이터의 독립성과 종속성

1. 데이터의 종속성 : 응용 프로그램에 대한 데이터의 종속성
   ex) 파일 시스템
   - 응용 프로그램과 데이터가 상호 의존적
   - 데이터를 저장한 파일 구조가 변경되면 이에 대응되는 응용 프로그램도 변경되어야 함

2. 데이터 독립성
   데이터 구조가 변경되어도 응용 프로그램이 변경될 필요가 없음. 논리적 독립성 + 물리적 독립성으로 실형됨

3. 데이터 독립성이 유지되지 않으면? (데이터 시스템을 안쓰고 파일 시스템을 사용하면?)
   - 데이터의 중복성 및 복잡도 증가 (파일 시스템의 단점)
   - 요구사항 대응 난이도 증가 → 데이터 유지보수 비용 증가

- 데이터 독립성

1. 논리적 독립성
   논리적 사상(외부적/ 개념적 사상)을 통해 논리적 독립성이 보장됨

   • 개념 스키마가 변경되어도 외부 스키마에는 영향을 미치지 않음
   • 논리적 구조가 변경되어도 응용 프로그램에는 영향이 없음

2. 물리적 독립성
   물리적 사상(개념적/ 내부적 사상)을 통해 물리적 독립성이 보장됨

   • 내부스키마가 변경되어도 외부/개념 스키마는 영향을 받지 않음
   • 저장장치의 구조변경은 응용프로그램과 개념스키마에 영향을 주지 않음

5. 데이터 모델링의 요소

데이터 모델링의 3가지 구성 요소

- 개체(Entity) : 업무와 관련된 어떤 것

- 속성(Attribute) : 어떤 것이 갖는 성격

- 관계(Relationship) : 어떤 것 간의 관계

⁠엔터티의 인스턴스, 관계의 패어링, 속성의 속성값

Schema, Instance

**1.**데이터베이스 스키마(schema)

- 데이터 모델링의 대상

- 데이터베이스 구조, 데이터 타입, 제약조건에 대한 명제

- 데이터베이스 설계 단계에서 명시되며 자주 변경되지 않음

2.데이터베이스 인스턴스(instance)

- 특정 시점에 데이터베이스에 실제로 저장되어 있는 데이터의 값

6. 데이터 모델 표기법

7. ERD 작성 순서

1. 엔터티를 그린 후 적절하게 배치
   가급적 선이 꼬이지 않게 배치, 왼쪽 → 오른쪽, 위 → 아래 순으로 읽어나가기 편하게 배치

2. 엔터티간 관계 설정
   식별자 관계를 우선 설정, 가급적 cycle 관계도 발생하지 않아야함

3. 관계명 기술(양방향)
   현재형 사용(등록 한다 (O), 등록 했다 (X)), 지나치게 포괄적인 단어는 지양

4. 관계차수와 선택성 표시

8. 좋은 데이터 모델

완전성, 업무규칙 비슷/ 중복배제, 데이터 재사용, 통합성 비슷

1. 완전성 (completeness) : 업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의되어야 함 (what)

2. 중복배제 (non-redundancy) : 동일한 사실은 반드시 한번만 기록하여야 함

3. 업무규칙 (business rules) : 업무규칙이 데이터 모델에 표현되어야 함 (사원에는 정규직, 임시직이 있으며, 정규직만 호봉 정보를 가짐)
   (how. 규칙을 모델로 표현하겠다는 것이 아닌 그 규칙을 프로세스에서 관리하기 위해 필요한 데이터가 모델에 포함되어 있어야함)

4. 데이터 재사용 (data reusability) : 회사 전체 관점에서 데이터를 도출하고 이를 전 영역에서 사용할 수 있도록 설계해야 함

5. 통합성 (integration) : 동일한 데이터는 조직의 전체에서 한번만 정의되고, 이를 여러 다른 영역에서 참조, 활용해야 함

9. 엔터티 (Entity)

병원 관리 시스템, 도서 관리 시스템 등 굵직하고 주인공 급으로 할 수 있는 것들을 엔터티라고 한다.

과목, 강사, 교실 사건 등

→ 업무에 필요한 정보를 저장하고 관리하기 위한 집합적인 것 (thing)

엔터티의 분류

1. 유형(tangible) 엔터티
   - 스스로 값을 가질 수 있음
   - 물리적인 형태가 있고 안정적이며 지속적으로 활용됨
   - 교수, 강의실, 학생 등

2. 개념(conceptual) 엔터티
   - 처음 만들 때 데이터가 한두개 쌓이고 없어지는 것
   - 물리적인 형태는 존재하지 않으나 관리해야 할 개념적 정보
   - 수업, 보험상품 등

3. 사건(event) 엔터티
   - 데이터가 많이 쌓이고 변경되는 것
   - 업무 수행 과정에서 발생하며 비교적 발생량이 많음 (각종 통계 자료에 이용됨)
   - 수강신청, 주문, 입금 등

엔터티와 인스턴스

엔터티는 스키마를 나타내고, 인스턴스는 인스턴스를 나타낸다.

인스턴스를 모아둔 것을 엔터티라 부른다.

엔터티의 특징

1. 해당 업무에서 필요하고 관리하고자 하는 정보를 포함해야 함

2. 유일한 식별자에 의해 식별이 가능해야 함

3. 영속적으로 존재하는 둘 이상 인스턴스의 집합이어야 함

4. 업무 프로세스에 의해 이용되어야 함

- 업무 프로세스에 의해 CRUD가 발생해야 함
  - CRUD가 발생하지 않는다면 부적절한 엔터티 도출 또는 업무 누락

1. 반드시 속성을 가져야 함

- 속성 없이 엔터티의 이름만 존재할 수 없음

1. 주식별자만 존재하고 일반속성은 없는 경우도 바람직하지 않음

- 단 연관 엔터티는 주식별자 속성만 갖고 있어도 인정

엔터티의 명명

1. 엔터티 생성 의미대로 실제 업무에서 사용하는 용어를 사용한다.

2. 약어를 사용하지 않는다.

3. 단수 명사를 사용한다.

4. 이름이 동일한 엔터티가 중복으로 존재할 수 없다.

엔터티의 특징

IE 표기법

1. 다른 엔터티와 최소 한개 이상의 관계를 가져야 함 (연결되어 있어야한다.)
   - 고립 엔터티 : 부적절한 엔터티 도출 또는 관계 누락

2. 아래의 경우 고립 엔터티를 인정한다.
   → 실제 업무와 밀접하게 관련있는 것이 아닌 쿼리를 수행할 때 참고하려고
   - 통계성 엔터티
   - 코드성 엔터티
   - 시스템 처리용 내부 엔터티 (트랜잭션 로그 테이블 등)