데이터 모델링

정의

• 일상 생활에서 자주 사용되는 모델링의 정의
  • 우리가 살고 있는 3차원의 현실 세계를 단순화하여 표현
  • 현실 세계를 추상화하여 그 구조를 표현
  • 현실 세계에 존재하는 사물이나 사건에 관한 관점 및 양상을 연관된 주체를 위하여 명확하게 하는것

핵심

• 복잡한 것을 단순화시켜 표현 -> 명확하게 함

특징

• 추상화 : 복잡한 것 -> 일정한 형식에 맞게 표현
• 단순화 : 서로가 약속한 규약을 준수하는 표기법이나 언어로 표현
  • 모두가 알아들을 수 있게 한다는 의미
• 명확화
  • 명확하게 기술
  • 애매모호함 제거 -> 여러 사람이 이해하기 쉽게

모델링이란 복잡한 현실 세계를 추상화, 단순화 명확화하기 위해 일정한 표기법으로 모델을 표현하는 기법

모델링의 3가지 관점

• 데이터 관점(Data, What) : 비즈니스와 관련된 데이터는 무엇인지, 데이터 간의 관계는 무엇인지에 대한 관점
• 프로세스 관점(Process, How) : 해당 일로 인해 어떤 일이 일어나는지에 대한 관점
• 상관 관점(Data, Process) : 위의 두 관점 간 서로 어떤 영향을 받는지에 대한 관점

데이터 모델링의 정의

• 현실 세계의 비즈니스를 IT 시스템으로 구현하기 위해 데이터 관점으로 업무를 분석하는 기법
• 현실 세계의 비즈니스를 약속된 표기법으로 표현하는 과정
• DB를 구축하기 위한 분석 및 설계의 과정

대부분의 IT 시스템은 관계형 데이터베이스(RDBMS, Relational DataBase Management System) 기반으로 구축

데이터 모델링을 통해 정의된 데이터 모델을 기반으로 물리적인 DB가 구축

SQL문을 활용 -> 데이터가 INSERT 입력, UPDATE 수정, DELETE 삭제, SELECT 조회

데이터 모델의 기능

• 가시화 : IT 시스템의 모습을 가시화
• 명세화 : IT시스템의 구조와 발생하는 동작을 명세화
• 구조화된 틀 제공 : IT 시스템을 구현하는데 필요한 구조화된 틀 제공
• 문서화 : IT 시스템 구축 시 산출물로 사용되는 문서 제공
• 다양한 관점 제공 : 다른 영역의 세부사항을 숨김 -> 다양한 영역에 집중할 수 있는 관점 제공
• 상세 수준의 표현 방법 제공 : 원하는 목표에 따라 구체화된 상세 수준의 표현 방법을 제공

데이터 모델의 중요성

• 파급효과(Leverage) : 데이터 설계 과정에서 비효율적인 데이터 설계, 업무 요건을 충족하지 못하는 데이터 설계 -> 개발/테스트/오픈/운영의 전 과정에서 엄청난 비용 발생 가능
• 복잡한 정보 요구사항의 간결한 표현(Conciseness) : 좋은 데이터 모델 설계 -> IT 시스템에서 구현해야 할 정보 요구사항을 명확하고 간결하게 표현 가능
• 데이터 품질(Data Quality)
  • 데이터 모델의 잘못된 설계로 인해 데이터 중복, 비유연성, 비일관성 발생 가능
  • 데이터 중복, 비유연성, 비일관성으로 인해 데이터 품질 저하될 수 있다.

데이터 모델링의 3단계 진행

• 현실 세계 -개념 데이터 모델링(추상적)-> 개념적 구조 -논리 데이터 모델링-> 논리적 구조 -물리 데이터 모델링(구체적)-> 물리 구조(데이터베이스)

데이터 모델링의 3단계

• 개념적 데이터 모델링
  • IT 시스템에서 구현하고자 하는 대상에 대해 포괄적 수준의 데이터 모델링을 진행
  • 전사적 데이터 모델링 시 많이 사용하는 단계
• 논리적 데이터 모델링
  • IT 시스템에서 구현하고자 하는 비즈니스를 만족하기 위한 기본키, 속성, 관계, 외래키 등을 정확하게 표현하는 단계
• 물리적 데이터 모델링
  • 논리 데이터 모델을 기반으로 실제 물리 DB 구축을 위해 성능, 저장공간 등의 물리적인 특성을 고려하여 설계하는 단계

프로젝트 생명 주기에서 데이터 모델링

• 프로젝트 생명 주기의 각 단계는 정보전략계획 -> 분석 -> 설계 -> 개발 -> 테스트 -> 전환/이행 단계에 따라 진행됨
• 개념적 데이터 모델링 : 정보전략계획, 분석 단계에 포함됨
• 논리적 데이터 모델링 : 분석 단계에 포함됨
• 물리적 데이터 모델링 : 설계 단계에 포함됨

데이터 독립성의 필요성

• 데이터의 독립성 : 하위 단계의 데이터 구조가 변경, 상위 단계에는 영향을 미치지 않음
  • 데이터 구조가 변경되더라도 응용 프로그램 단에는 아무런 영향을 미치지 않도록 하는것

데이터 독립성의 출현 배경

• 보유한 데이터 복잡도를 낮추고, 중복된 데이터를 줄임 -> IT 시스템의 유지보수 비용 절감

• 사용자의 요구사항은 지속적으로 발생, 화면과 물리 DB 간 서로 독립성을 유지

• 문제점
  • 유지보수 비용 증가
  • 데이터 중복성 증가
  • 데이터 복잡도 증가
  • 요구사항 대응 저하
• 데이터 독립성 확보
  • 각 View의 독립성을 유지, 계층별 View에 영향을 주지 않고 변경 가능
  • 단계별 Schema에 따라 데이터 정의어(DDL)와 데이터 조작어(DML)가 다름을 제공

데이터베이스 3단계 구조

• ANSI/SPARC 3단계 구성의 데이터 독립성 모델 : 외부 단계, 개념적 단계, 내부적 단계로 구성. 서로 간섭 X
• 물리적 데이터 독립성 : 내부 스키마가 변경되어도 개념 스키마에 영향 X
• 논리적 데이터 독립성 : 개념 스키마가 변경되어도 외부 스키마에 영향 X

---

• 데이터베이스의 3단계 구조 표

단계명	설명	비고
외부 스키마	각각의 사용자가 보는 DB스키마 개인 사용자 혹은 응용 프로그램 개발자가 접근하는 DB 스키마	사용자 관점
개념 스키마	모든 사용자의 관점을 하나로 통합한 비즈니스 전체의 DB를 기술한 스키마 응용 프로그램 및 사용자들이 필요한 데이터를 통합한 전체 DB를 기술한 것 DB에 저장되는 데이터와 으용 프로그램 및 사용자들 간의 관계를 표현하는 스키마	통합 관점
내부 스키마	DB가 물리적으로 저장된 형식을 표현한 스키마 물리적 하드웨어 장치에 데이터가 실제로 저장되는 방법을 표현한 스키마	물리적 관점

데이터베이스 3단계 구조에서의 2가지 데이터 독립성

독립성	설명	비고
논리적 데이터 독립성	개념 스키마가 변경되어도 외부 스키마에는 영향을 미치지 않도록 지원하는 것 논리적 구조가 변경되어도 응용 프로그램에 영행을 비치지 않음	사용자 특성에 맞는 변경이 가능 통합 구조의 변경이 가능
물리적 데이터 독립성	내부 스키마가 변경되어도 외부/개념 스키마는 영향을 받지 않도록 지원하는 것 저장 장치의 구조 변경은 응용 프로그램/개념 스키마에 영향을 미치지 않음	물리 구조에 영향 없이 개념 구조의 변경이 가능 개념 구조에 영향 없이 물리 구조의 변경이 가능

• 각 단계별 데이터 독립성의 보장이 가능한 이유
  • 각 단계와 안계 사이를 연결하는 사상(매핑)이 있기 때문

사상	설명	비고
외부적/개념적 사상(논리적 사상)	외부적 뷰와 개념적 뷰의 상호 호환성을 정의	사용자가 접근하는 형식에 따라 다른 타입의 필드를 가질 수 있다. 개념적 뷰의 필드 타입 변화 X
개념적/내부적 사상(물리적 사상)	개념적 뷰와 저장된 데이터베이스의 상호 관련성을 정의하는 사상	저장된 데이터베이스 구조가 바뀐다면 개념적/내부적 사상이 바뀌어야함. 개념 스키마가 그대로 남아있어야 하기 때문

데이터 모델링의 3가지 요소와 데이터 모델링 용어

• 데이터 모델링의 3가지 요소
  • 업무가 관여하는 어떤 것(Things)
  • 어떤 것이 가지는 성격(Attributes)
  • 업무가 관여하는 어떤 것 간의 관계(Relationships)

• 데이터 모델링의 3가지 요소가 결합되어 데이터 모델이 탄생.

• 데이터 모델링 용어

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

• 엔터티 타입 : 어떤 것의 전체를 지칭
• 인스턴스/어커런스 : 엔터티 내에 실제로 추가된 값
• 페어링 : 관계에 포함된 개별 연관성
• 속성 : 어떤 것이 가지는 속성
• 속성값 : 실제로 속성이 표현된 값

ERD를 그리는 작업 순서

• ERD 데이터 모델을 표기하는 표기법
  • ERD를 그린다 = 데이터 모델링 작업을 한다

ERD를 그리는 순서

• 비즈니스에 필요한 엔터티를 그린다
• 1번에서 그린 엔터티를 적절하게 배치한다
• 각 엔터티 간의 관계를 설정
• 설정한 관계의 관계명을 기술
• 설정한 관계의 참여도를 기술
• 설정한 관계의 필수 여부를 기술

IT 시스템을 구축하는 모든 사람은 적어도 데이터 모델을 정확하게 해석할 수 있어야 함

좋은 데이터 모델의 요소

• 완전성 : 업무에 필요한 데이터가 모두 정의되어야 함
• 중복 배제 : 동일한 사실은 단 한번만 저장
• 업무 규칙 : 데이터 모델 분석만으로도 비즈니스 로직이 이해되어야 함
• 데이터 재사용 데이터 통합성과 독립성을 고려하여 재사용이 가능해야함
• 의사소통 : 데이터 모델을 보고 이해 당사자들끼리 의사소통이 가능해야함
• 통합성 : 동일한 데이터는 유일하게 정의, 다른 영역에서 참조

엔터티

엔터티의 개념

• 비즈니스 관점에서 IT 시스템을 통해 저장 및 관리해야 하는 집합적인 어떤 것
  • 사람, 사물, 사건, 개념 등의 명사
  • IT 시스템을 통해 관리고 필요한 관심사
  • 저장해야 하는 어떤 것

엔터티와 인스턴스

• 엔터티 : 인스턴스의 집합
  • 1:M 관계

엔터티의 표기법

• 모서리가 둥근 사각형을 그림
  • 맨 위에 엔터티명을 기재

엔터티의 특징

• 비즈니스 요구 조건 만족을 위해 반드시 필요하고, 저장 및 관리하고자 하는 정보
• 유일한 식별자에 의해 식별이 가능해야함. 집합 내에서 단 1건을 콕 짚어낼 수 있어야 함
• 영속적으로 존재하는 인스턴스의 집합
• 엔터티는 비즈니스 프로세스에 의해 반드시 이용되어야 함
• 엔터티는 반드시 속성을 가지고 있어야 함
• 엔터티는 다른 엔터티와 최소 1개 이상의 관계가 있어야 함

엔터티의 특징을 모두 만족하지 않아도 엔터티로 도출되는 경우도 있음

특징	설명
업무에서 필요로 하는 정보	비즈니스 요구 조건 만족을 위해 반드시 필요하고 저장 및 관리하고자 하는 정보여야 한다
식별가능해야함	유일한 식별자에 의해 식별이 가능해야 함
인스턴스의 집합	영속적으로 존재하는 2개 이상의 인스턴스 집합이어야 한다
업무 프로세스에 의해 이용	엔터티는 비즈니스 프로세스에 의해 반드시 이용되어야 한다 업무 프로세스에 의해 INSERT, SELECT, UPDATE, DELETE 등이 발생하지 않는 고립된 엔터티의 경우는 엔터티를 제거하거나 누락된 프로세스가 존재하는지 살펴보고 해당 프로세스를 추가해야 한다
속성을 포함	엔터티에는 반드시 속성이 포함되어야 한다 속성을 포함하지 않고 엔터티의 이름만 가지고 있는 경우는 관계가 생략되어 있거나 업무 분석이 미진하여 속성 정보가 누락되는 경우에 해당
관계의 존재	엔터티는 다른 엔터티와 최소 1개 이상의 관계가 있어야 한다

엔터티의 분류

• 유무형에 따른 분류

구분	예시	설명
유형	사원, 물품, 강사	실체가 존재하고 물리적인 형태가 있으며 안정적이고 지속적으로 활용되는 엔터티
개념	조직, 보험상품	물리적인 형태가 존재하는 것은 아님. 비즈니스적으로 관리해야 할 개념적 정보를 저장하는 엔터티
사건	주문, 청구, 미납	비즈니스를 수행함으로써 발생되는 엔터티 유행/개념 엔터티에 비해 데이터 발생량이 많으며, 다양한 통계 자료에 이용될 수 있음

• 발생시점에 따른 분류

구분	예시	설명
기본	사원, 부서, 고객, 상품, 자재	비즈니스에서 스스로 태어난 존재에 대한 정보, 독립적으로 생성이 가능 타 엔터티의 부모 역할을 하게됨
중심	계약, 사고, 매출 등등	기본 엔터티로부터 발생되며 비즈니스에 있어서 중심적인 역할을 하는 엔터티 데이터의 양이 많이 발생됨, 타 엔터티와의 관계 속에서 많은 행위 엔터티를 도출시킴
행위	주문목록, 사원변경이력	2개 이상의 부모 엔터티로부터 발생되는 엔터티 다양하고 복잡한 비즈니스를 처리하는 과정에서 데이터양이 많아질 수 있다 상세 설계 단계 혹은 프로세스와 상관 모델링을 진행하면서 도출됨

엔터티의 명명

• 규칙
  • 가능한한 업무 담당자들이 사용하는 용어를 사용
  • 약어 사용 지양
  • 단수명사 사용
  • 해당 모델 내에서 유일한 이름
  • 생성 의미에 맞게 이름을 부여

속성

개념

• 비즈니스에서 필요로 함
• 엔터티에 대한 설명이며 인스턴스의 구성요소가 됨
• 의미상 더 이상 분리되지 않는 데이터 단위

엔터티, 인스턴스, 속성, 속성값의 관계

• 속성은 엔터티에 대한 자세하고 구처적인 정보를 나타냄
• 각각의 속성은 구체적인 값을 갖게 됨
  • 엔터티 : 지하철역
  • 속성 : 노선명, 역명 : 속성
  • 1호선(노선), 신촌(역명) : 속성값
• 1개의 엔처치는 여려개의 인스턴스를 가질 수 있음
• 하나의 인스턴스는 여러개의 속성을 가짐
• 하나의 속성은 단 하나의 속성값을 가짐

속성의 표기법

• 엔터티 내의 속성 이름을 표현
• 속성명에 #을 붙여 식별자임을 표시
• 속성명에 *을 붙이면 필수값
• ㅇ을 붙임 -선택값

속성의 특징

• 반드시 비즈니스에서 필요로 하고 IT 시스템에서 저장 및 관리하고자 하는 정보여야 함
• 정규화 이론에 따라 속성이 속해 있는 엔터티의 주식별자에 함수적 종속성을 가져야 한다
• 하나의 속성에는 1개의 값만 가진다.
• 하나의 속성에 여러 개의 값이 있는 다중 값일 경우 별도의 엔터티를 이용하여 분리

속성의 분류

• 특성에 따른 분류

특성	설명
기본 속성	비즈니스 분석을 통해 도출된 속성
설계 속성	비즈니스 분성르 통해 도출된 것은 아님 데이터 모델 설계를 하면서 도출하는 속성
파생 속성	다른 속성에 의해서 계산이나 변형이 되어 생성되는 속성

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

구성방식	설명
PK(Primary Key) 속성	엔터티에서 단 하나의 인스턴스를 식별할 수 있는 속성
FK(Foreign Key) 속성	타 엔터티와의 관계를 통해 포함된 속성
일반 속성	엔터티 내에 존재하면서 PK 혹은 FK 속성이 아닌 속성

도메인

• 각 속성이 갖는 값의 범위 및 유형
• 각 속성의 속성값은 정의된 도메인 이외의 값을 가질 수 없다

속성의 명명

• 비즈니스에 사용하는 이름을 부여
• 속성명을 서술식으로 명명X
• 속성 명명시 약어 사용 지양
• 전체 데이터 모델 내에서 유일한 이름의 속성명으로 명명

관계

관계의 정의

• 엔터티끼리 상호 연관성이 있는 상태
• 데이터 모델 내에 존재하는 엔터티 간 논리적인 연관성

관계의 페어링

• 관계 페어링 : 엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것
• 이것의 집합을 관계로 표현
• 개별 인스턴스가 각각 다른 종류의 관계를 가지고 있다면 두 엔터티 사이에 2개 이상의 관계가 형성될 수 있음

관계의 표기법

• 관계의 표기 시 관계 차수 및 관계 선택사양을 명확하게 해야 함
• 관계차수 : 2개의 엔터티 간 관계에서 참여자의 수를 표현하는 것
  • 1:1 관계 : 모든게 실선으로 표현됨
  • 1:M 관계 : 포함하는 엔터티는 점선으로 이어가고 포함되는 엔터티는 실선으로 이어감. 포함되는 쪽은 까치발
  • M:M 관계 : 다 점선에 까치발
• 관계 선택사양
  • 필수참여관계
    • 필수적으로 있어야 하는 관계 ex) 열차의 문이 닫혀야 열차 출발. 이 때 열차문의 완전한 닫힘과 출발은 필수적인 관계
    • 실선
  • 선택참여관계
    • 관련은 있지만 필수적인 상황은 아님 ex) 열차의 안내방송과 열차의 출발은 관련이 있지만 필수적인 관계는 아님. 안내방송이 안나온다고 열차가 출발을 못하는 것이 아님.
    • 점선

관계정의 시 체크 사항

• 아래의 체크사항을 만족하는지 확인해야함
  • 2개의 엔터티 사이에 관심 있는 연관 규칙이 존재하는가
  • 2개의 엔터티 사이에 정보의 조합이 발생되는가
  • 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가
  • 업무기술서, 장표에 관계연결을 가능하게 하는 동사가 있는가

식별자

식별자의 개념

• 단 하나의 인스턴스를 구별해낼 수 있는 논리적인 이름
• 엔터티의 각 인스턴스를 개별적으로 식별하기 위해 사용되는 단 하나의 속성 혹은 속성들의 집합

식별자의 특징

특징	내용	예시
유일성	엔터티 내에 존재하는 각각의 인스턴스 집합은 주식별자에 의해 유일하게 구분할 수 있다	사원엔터티의 사원번호 속성은 주식별자이다.
최소성	유일성을 만족한다면 주식별자를 구성하는 속성의 수는 최소한의 수로 이루어져야함	사원번호만으로도 충분, 사원분류코드까지 추가되면 최소성을 어김
불변성	엔터티 내 특정 인스턴스에 주식별자가 한번 정해지면 그 값은 변하지 말아야 한다	한번 정해진 사원번호의 값은 다른 값으로 변경되지 말아야 함
존재성	주식별자가 지정되면 반드시 데이터 값이 존재해야 함 주식별자로 정해진 속성은 반드시 데이터 값이 존재해야함. NULL 허용 X	사원번호가 없는 직원은 없음

식별자의 분류

• 대표성 여부
  • 주식별자
    • 엔터티 내에서 각각의 행을 구분할 수 있는 구분자.
    • 다른 엔터티와 참조관계를 가질 때 연결할 수 있는 식별자
  • 보조식별자
    • 엔터티 내에서 각각의 행을 구분할 수 있다
    • 다른 엔터티와 참고관계를 가질 때 연결 불가능
• 스스로 생성 여부
  • 내부식별자
    • 엔터티 내부에서 스스로 만들어지는 식별자
  • 외부식별자
    • 다른 엔터티와의 관계를 통해 다른 엔터티로부터 받아오는 식별자
• 속성의 수
  • 단일식별자
    • 하나의 속성으로 구성된 식별자
  • 복합식별자
    • 둘 이상의 속성으로 구성된 식별자
• 대체 여부
  • 본질식별자
    • 비즈니스에 의해 만들어지는 식별자
  • 인조식별자
    • 비즈니스적으로 만들어지지는 않지만 본질식별자가 복잡한 구성을 가지고 있기 때문에 인위적으로 만든 식별자

식별자 도출 기준

• 비즈니스에서 자주 이용되는 속성을 주식별자로 지정
• 명칭, 장소와 같이 이름으로 기술되는 속성은 가능하면 주식별자로 하지 않음
• 주식별자를 복합식별자로 할 경우 지나치게 많은 속성이 포함되지 않도록 한다

식별자 관계와 비식별자 관계의 결정

• 외부식별자 : 자기 자신의 엔터티에서 필요한 속성이 아니라 다른 엔터티와의 관계를 통해 자식쪽 엔터티에 생성되는 속성
  • 데이터베이스 생성 시 외래키 역할을 함
• 식별자 관계 : 자식 엔터티의 주식별자로 부모 엔터티의 주식별자가 상속이 되는 경우
  • 자식 엔터티에서 외부식별자가 주식별자 역할을 함
  • 부모엔터티의 식별자가 자식 엔터티에서도 식별자 역할을 함
• 비식별자 관계 : 부모 엔터티로부터 속성을 물려받았지만 자식 엔터티의 주식별자로 사용하지 않고 일반적인 속성으로만 사용하는 경우
  • 비식별자 관계를 갖는 경우
    • 자식 엔터티에서 받은 속성이 반드시 필수가 아니어도 무방 -> 부모 없는 자식이 생성될 수 있는 경우
    • 부모 엔터티의 주식별자를 자식 엔터티의 주식별자 속성으로 사용해도 되지만, 자식 엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단될 때, 비식별자 관계에 의한 외부식별자로 표현

식별자 관계로만 설정할 경우의 문제점

• PK속성의 수가 지속적으로 증가 -> SQL문의 복잡성 증가 -> 조인 조건이 누락되는 실수가 발생할 확률이 높아짐

식별자 관계 VS 비식별자 관계

• 식별자 관계/비식별자 관계 연결 고려사항

항목	식별자 관계	비식별자 관계
목적	강한 연결 관계를 표현	약한 연결 관계를 표현
자식 주식별자 영향	부모 엔터티의 주식별자 속성이 자식 엔터티의 주식별자의 구성에 포함	부모 엔터티의 주식별자 속성이 자식 엔터니의 일반 속성이 됨
연결 고려사항	부모 엔터티에 종속되는 경우에 사용 자식 엔터티의 주식별자 구성에 부모 엔터티의 주식별자 속성이 필요한 경우에 사용 부모 엔터티에게서 상속받은 주식별자 속성을 타 엔터티에 이전이 필요한 경우 사용	부모/자식 간 약한 종속 관계인 경우에 사용 자식 엔터티의 주식별자 구성을 독립적으로 구성할 경우에 사용 부모 엔터티로부터 상속받은 주식별자 속성을 타 엔터티에게 이전하지 않도록 차단이 필요한 경우에 사용 부모 엔터티의 주식별자가 NULL이 허용되는(선택 관계) 경우에 사용