데이터 모델의 이해

TIL - DAY 1

📝 책에서 기억하고 싶은 내용을 써보세요.

1. 데이터 모델의 이해

1.1. 모델링의 이해

모델링의 정의

모델을 만들어가는 일 자체, 복잡한 현실세계를 일정한 표기법에 의해 표현하는 일
현실세계를 추상화, 단순화, 명확화하기 위해 일정한 표기법에 의해 표현하는 기법

모델링의 특징

추상화: 일정한 형식에 맞춰 표현, 다양한 현상을 일정한 양식인 표기법에 의해 표현
단순화: 약속된 규약에 의해 제한된 표기법이나 언어로 표현
명확화: 이해가 쉽게 하기 위해 정확하게 현상을 기술 하는 것

모델링의 관점

모델링 = 데이터관점(Data, What) + 프로세스관점(Process, How) + 상관관점(Data vs Process)

데이터관점: 업무가 어떤 데이터와 관련이 있는지, 데이터 사이의 관계는 무엇인지
프로세스관점: 업무가 실제하고 있는 일은 무엇인지, 무엇을 해야 하는지
데이터와 프로세스의 상관관점: 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받고 있는지

1.2. 데이터 모델의 기본 개념의 이해

데이터 모델링

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

목적

정보에 대한 표기법을 통일하여 업무 내용 분석 정확도 증대
데이터 모델을 기초로 DB 생성

기능

가시화
명세화
구조화된 틀 제공
문서화
다양한 관점 제공
구체화

1.3. 데이터 모델링의 중요성 및 유의점

파급효과(Leverage)
복잡한 정보 요구사항의 간결한 표현(Conciseness): 정보 요구사항과 한계를 간결하게 표현하는 도구
데이터 품질(Data Quality)
- 유일성: 데이터 중복 저장 방지
- 유연성: 데이터 정의와 데이터 사용 프로세스 분리
- 일관성: 데이터와 데이터간 상호 연관 관계에 대한 명확한 정의

이해관계자: 개발자, DBA, 모델러, 현업전문가, 완성된 모델을 정확히 해석할 수 있어야 함

1.4. 데이터 모델링 3단계 진행

개념적 데이터 모델링: 엔티티와 속성을 도출하고 ERD를 작성함, 업무 중심적이고 포괄적인 수준의 모델링
논리적 데이터 모델링: 식별자를 도출하고 속성과 관계 등을 정의함, 정규화를 수행하여 데이터 모델의 독립성과 재 사용성 확보, 놀리 데이터 모델을 데이터 모델링 완료 상태
물리적 데이터 모델링: DB를 구축함, 성능 및 보안 등 물리적인 완료 상태

1.5. 프로젝트 생명주기(Life Cycle)에서 데이터 모델링

프로젝트 생명주기: 계획 > 분석 > 설계 > 개발 > 테스트 > 전환/이행 단계로 구성

계획과 분석: 개념적 모델링
분석: 논리적 모델링
설계: 물리적 모델링

1.6. 데이터 모델링에서 데이터독립성의 이해

데이터 독립성의 필요성: 데이터의 중복성과 데이터 복잡도 증가로 인한 유지보수 비용증가, 요구사항 대응 저하

데이터베이스 3단계 구조: 외부단계, 개념적 단계, 내부적 단계로 서로 간섭되지 않는 모델 제시

참고: https://agilestarskim.github.io/posts/what-is-database-03

데이터독립성 요소

외부스키마: 각 사용자 단계의 개인적 DB 스키마, 사용자 관점, 응용 프로그램이 접근하는 DB 정의
개념스키마: 조직 전체의 통합된 DB 스키마, 통합 관점, 데이터 모델링의 지향점
내부스키마: 물리적으로 데이터가 저장되는 방법을 표현하는 스키마, 개발자 관점, 물리적 저장 구조

두 영역의 데이터 독립성

논리적 독립성: 외부 스키마가 개념 스키마의 변화에 무관함, 논리적 사상 없음
물리적 독립성: 개념 스키마가 내부 스키마의 변화에 무관함, 물리적 사상 없음

사상(Mapping): 상호 독립적인 개념을 연결시켜주는 다리

외부적/개념적 사상(논리적 사상): 외부적 뷰와 개념적 뷰의 상호 관련성 정의
개념적/내부적 사상(물리적 사상): 개념적 뷰와 저장된 데이터베이스의 상호관련성 정의
1.7. 데이터 모델링의 중요한 세 가지 개념

데이터 모델링의 세 가지 요소

업무가 관여하는 어떤 것(Things)
어떤 것이 가지는 성격(Attributes)
업무가 관여하는 어떤 것 간의 관계(Relationships)

→ 데이터 모델링을 완성해 가는 핵심 개념으로 엔티티, 속성, 관계로 인식

단수와 집합(복수)의 명명

개념	복수/집합 개념 타입/ 클래스	개별/단수개념 어커런스/인스턴스
어떤것(Thing)	엔티티 타입 (Entity Type) 엔티티(Entity)	엔티티(Entity) 인스턴스(Instance), 어커런스(Occurrence)
어떤 것간의 연관(Association between Things)	관계(Relationship)	패어링(Pairing)
어떤 것의 성격(Characteristic of a Thing)	속성(Attribute)	속성 값(Attribute Value)

1.8. 데이터 모델링의 이해관계자

이해관계자의 데이터 모델링 중요성 인식

데이터 모델링 과정이 단지 데이터베이스를 설계한다는 측면보다 업무를 이해하고 분석하여 표현하는 것이 중요, 시스템이 대형화되면 모델링만을 전문적으로 담당하는 모델러를 투입하여 진행하는 경우도 있지만, 실제 모델링 작업은 응용개발을 하는 사람이나 업무분석가 (역할분담이 잘되어 있을 경우)가 담당하고 모델러나 DBA는 정확하게 모델링이 진행될 수 있도록 교육하고 제시하며 현안별로 직접 모델링을 진행하는 역할을 수행한다.

데이터 모델링의 이해관계자

정보시스템을 구축하는 모든 사람
IT기술에 종사하거나 전공하지 않았더라도 해당 업무에서 정보화를 추진하는 위치에 있는 사람

1.9. 데이터 모델의 표기법인 ERD의 이해

데이터 모델 표기법

Entity-relationship model(E-R Model) 표기법: 엔티티는 사각형, 관계는 마름모, 속성은 타원형으로 표현, 현실의 데이터 모두 표현 가능

ERD(entity relationship diagram) 표기법을 이용하여 모델링 하는 방법

ERD 작업순서

엔티티 도출: 따라 Primary Key와 Foreign Key를 ERD 규칙에 따라 기술
엔티티 배치: 가장 중요한 엔터티를 왼쪽상단에 배치하고 이것을 중심으로 다른 엔터티를 나열하면서 전개하면 사람의 눈이 따라가기에 편리한 데이터 모델링을 전개
엔티티간 관계 연결: 관계를 정의한 분석서를 보고 서로 관련있는 엔터티간에 관계를 설정
관계명 기술: 연결된 관계에 관계이름을 부여
관계 참여도 기술(1:1, 1:N, M:N): 얼마나 관계에 참여하는 지를 나타내는 관계차수(Cardinality)를 표현한다.
관계 필수여부 기술(필수/ 선택표시는 관계선에 원을 표현하여 ERD를 그리도록 한다.

1.10. 좋은 데이터 모델의 요소

완전성(Completeness): 업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의되어 있어야 한다.
중복 배제(Non-Redundancy): 하나의 데이터베이스 내에 동일한 사실은 반드시 한 번만 기록하여야 한다.
업무 규칙(Business Rules): 데이터 모델링 과정에서 도출되고 규명되는 수많은 업무규칙을 데이터 모델에 표현하고 이를 해당 데이터 모델을 활용하는 모든 사용자가 공유할 수 있도록 제공하는 것이다.
데이터 재사용(Data Reusability): 데이터의 재사용성을 향상시키고자 한다면 데이터의 통합성과 독립성에 대해서 충분히 고려해야 한다.
의사소통(Communication): 데이터 모델이 진정한 의사소통의 도구로서의 역할을 하게 된다.
통합성(Integration): 동일한 데이터는 조직의 전체에서 한번 만 정의되고 이를 여러 다른 영역에서 참조 활용하는 것이다.

2. 데이터 모델의 이해

2.1. 엔터티의 개념

사람 장소 물건 사건 개념 등의 명사에 해당한다.
업무상 관리가 필요한 관심사에 해당한다.
저장이 되기 위한 어떤 것(Thing)

2.2. 엔터티와 인스턴스에 대한 내용과 표기법

엔터티대부분 사각형으로 표현된다.

2.3. 엔터티의 특징

업무에서 필요로 하는 정보: 반드시 시스템을 구축하고자 하는 업무에서 필요로 하고 관리 하고자 하는 정보여야 한다.
식별이 가능해야 함: 식별자(Unique Identifier)에 의해 식별이 가능해야 한다.
인스턴스의 집합: 영속적으로 존재하는 인스턴스의 집합이 되어야 한다. 하나의 엔터티는 여러 개의 인스턴스를 포함한다.
업무프로세스에 의해 이용: 업무프로세스(Business Process)가 그 엔터티를 반드시 이용해야 한다.
- CREATE, READ, UPDATE, DELETE 등이 발생하지 않는 고립된 엔터티의 경우는 엔터티를 제거하거나 아니면 누락된 프로세스가 존재하는지 살펴보고 해당 프로세스를 추가해야 한다.
속성을 포함: 엔터티에는 반드시 속성 이 포함되어야 한다.
- 예외적으로 관계엔터티(Associative Entity)의 경우는 주식별자 속성만 가지고 있어도 엔터티로 인정한다.
관계의 존재: 다른 엔터티와 최소 한 개 이상의 관계가 존재해야 한다는 것이다.
- 단 데이터 모델링을 하면서 관계를 생략하여 표현해야 하는 경우는 통계성 엔터티 도출, 코드성 엔터티 도출, 시스템 처리시 내부 필요에 의한 엔터티 도출과 같은 경우이다.

2.4. 엔터티의 분류

자신의 성격에 의해 실체유형에 따라 구분하거나, 업무를 구성하는 모습에 따라 구분이 되는 발생시점에 의해 분류해 볼 수 있다.

유무 형에 따른 분류: 유형엔터티(Tangible), 개념엔터티(Conceptual) 사건엔터티(Event)로 구분된다.
발생시점 에 따른 분류: 기본/키엔터티(Fundamental Entity, Key Entity), 중심엔터티(Main Entity), 행위엔티티(Active Entity)로 구분할 수 있다.

2.5. 엔터티의 명명

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

🔥 오늘 TIL 3줄 요약

🤩 오늘 읽은 소감은? 떠오른 생각을 가볍게 적어보세요

🔖 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.