[SQLD] 1-1 데이터 모델링의 이해

제1절 데이터 모델의 이해

모델링 - 다양한 현상을 일정한 표기법에 의해 규칙을 가지고 표기하는 것

 

특징

- 추상화(일정한 형식에 맞추어 표현)

- 단순화(약속된 규약에 따른 제한된 표기법을 사용하여 쉽게 이해)

- 명확화(누구나 이해하기 쉽게 애매모호함을 제거하고 정확하게 현상 기술)

 

데이터 모델링

- 정보 시스템 구축을 위해. 해당 업무에 어떤 데이터가 존재하는지 업무가 필요로 하는 정보가 무엇인지 분석하는 방법

 

목적

- 정보시스템 구축 대상이 되는 업무내용 분석 (약속된 표기법 사용)

- DB를 구축하기 위한 분석/설계의 과정 + 그 자체로도 업무를 설명하고 분석

 

기능

- 시스템 가시화

- 시스템 구조와 행동 명세화

- 시스템 구축하는 구조화된 틀 제공

- 시스템 구축과정에서 결정한 사항을 문서화

- 세부 사항은 숨기는 다양한 관점 제공

- 구체화된 상세 수준의 표현방법 제공

 

유의점

1) 중복 - 여러 장소에 같은 정보를 저장하지 말것.

2) 비유연성 - 데이터의 정의를 데이터의 사용 프로세스와 분리

3) 비일관성 - 데이터의 중복이 없어도 발생, 데이터와 데이터간 상호 연관 관계에 대한 명확한 정의 필요

 

개념적 데이터 모델

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

- 주요활동 > 핵심 엔티티와 이들간의 관계 발견, ER 다이어그램을 생성

 

논리적 데이터 모델

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

- 비즈니스 정보의 논리적인 구조와 규칙을 명확하게 표현하는 과정

- 정규화 => 일관성 확보, 중복 제거하여 속성들이 가장 적절한 엔티티에 배치되도록 함

- 상세화 => 식별자 확정, 정규화, 다대다 관계 해소, 참조 무결성 규칙 정의

 

물리적 데이터 모델

- DB에 이식할 수 있도록 성능, 저장 등 물리적 성격을 고려하여 설계

- 물리적으로 어떻게 저장될 것인지 정의 + 사용될 저장 장치, 자료 접근 방법등이 결정

 

외부스키마 ( 사용자 관점)

- 개개 사용자가 보는 개인적인 DB 스키마( 사용자 관점, 접근하는 특성에 따른 스키마 구성)

- DB의 개개 사용자나 응용프로그래머가 접근하는 DB 정의

개념스키마 ( 통합 관점)

- 구성하는 모든 사용자의 관점을 통합한 조직 전체의 DB를 기술

- 모든 응용 시스템들이나 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 DB를 기술한 것

- DB에 저장되는 데이터와 그들간의 관계를 표현하는 스키마

내부스키마 ( 물리적 저장구조)

- DB가 물리적으로 저장된 형식

- 물리적 장치에서 데이터가 실제적으로 저장되는 방법을 표현하는 스키마

=> 상호 독립적인 의미를 가지고 고유한 기능을 가짐

 

데이터 모델링 => 개념 스키마를 만들어가는 과정

 

데이터 모델링 세 가지 요소

1) 업무가 관여하는 어떤 것(Things) => Things

2) 어떤 것이 가지는 성격 (Attrubutes) => 속성

3) 업무가 관여하는 어떤 것 간의 관계(Relationships) => 관계

 

개념	복수/집합개념/타입/클래스	개별/단수개념/어커런스/인스턴스
어떤 것	엔티티 타입	엔티티
	엔티티	인스턴스/어커런스
어떤 것과의 연관	관계	페어링
어떤 것의 성격	속성	속성값

 

데이터 모델 표기법

ER model - 피터첸이 개발/ 엔티티(사각형) 관계(마름모) 속성(타원형)

ERD

- 각 업무분석에서 도출된 엔티티와 엔티티간의 관계를 이해하기 쉽게 도식화된 다이어그램

- 도식화된 그림 + 해당 업무에서 데이터의 흐름과 프로세스와의 연관성을 이야기하는 표기법이자 산출물 

 

ERD 작업순서

1) 엔티티를 그린다

 - 엔티티를 사각형으로 표기

2) 엔티티를 적절하게 배치한다

 - 가장 중요한 엔티티를 왼쪽상단(중앙)에 배치하고 이를 중심으로 나열

 - 업무흐름에 중심이 되는 엔티티는 타 엔티티와 많은 관계가 있기에 중앙에 배치

 - 중심엔티티와 관계를 갖는 엔티티는 중심에 배치된 엔티티 주위에 배치

3) 엔티티간 관계를 설정한다

 - 초기에는 PK로 속성이 상속되는 식별자 관계를 설정

 - 중복되는 관계가 발생하지 않도록 하고 순환 관계도 발생하지 않도록 유의

4) 관계명을 기술한다.

 - 현재형 사용하며 지나치게 포괄적인 용어 사용X

5) 관계의 참여도를 기술한다.

 - 엔티티내에 인스턴스들이 얼마나 관계에 참여하는 지를 나타내는 관계차수 표현

 - 1:1관계는 IE표기법으로는 실선으로 표기하며 Barker표기법은 점선과 실선을 혼합하여 표기

 - 다수참여 관계는 까마귀발과 같은 모양으로 그려줌

6) 관계의 필수여부를 기술한다.

 - 관계의 필수/선택 표시는 관계선에 원을 표기하여 ERD를 그림

 

좋은 데이터 모델의 요소

1)완전성

- 업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의

2) 중복배제

- 하나의 DB내에 동일한 사실은 반드시 한 번만 기록해야함

3) 업무규칙

- 데이터 모델링 관정에서 도출되고 규명되는 수많은 업무규칙을 데이터 모델이 표현하고 이를 해당 데이터 모델을 활용하는 모든 사용자가 공유할 수 있도록 제공하는 것

4) 데이터 재사용

- 데이터의 통합성과 독립성에 대해 충분한 고려 필요

5) 의사소통

- 표현된 많은 업무 규칙들을 해당 정보시스템을 운용, 관리하는 많은 관련자들이 설계자가 정의한 업무규칙들을 동일한 의미로 받아들이고 정보시스템을 활용할 수 있게 하는 역할 

6) 통합성

- 동일한 데이터는 조직 전체에서 한 번만 정의되고 이를 여러 다른 영역에서 참조, 활용하는 것

- 부가적 목적으로 의도적으로 중복시키는 경우가 존재하긴 함.

 

제2절 엔티티

엔티티

 - 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것

 - 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로 그 대상들 간 동질성을 지닌 인스턴스들이나 그들이 행하는 행위의 집합

- 그 집합에 속하는 개체들의 특성을 설명할 수 있는 속성을 가짐

- 이러한 속성 중 엔티티 인스턴스 전체가 공유할 수 있는 공통 속성도 있고 일부에만 해당하는 개별 속성도 있음

- 인스턴스의 집합

- 눈에 보이는 것뿐만 아니라 눈에 보이지 않는 개념도 모두 엔티티가 가능

 

특징

1) 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야함

> 반드시 시스템을 구축하고자 하는 업무에서 필요로 하고 관리하고자 하는 정보여야 함

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

> 엔티티를 도출하는 경우에 각각의 업무적으로 의미를 가지는 인스턴스가 식별자에 의해 한 개씩만 존재

3) 영속적으로 존재하는 인스턴스의 집합이어야함(2개 이상)

4) 엔티티는 업무 프로세스에 의해 이용되어야 한다.

> 필요하다고 생각하여 엔티티로 선정하였으나 업무프로세스에 의해 전혀 이용되지 않는다면 업무분석이 잘 이루어지지 않은 것

5) 엔티티는 반드시 속성이 있어야 한다

> 주식별자만 존재하고 일반속성을 전혀 없는 경우도 적절한 엔티티라고 할 수 없음

> 예외적으로 관계엔티티의 경우 주식별자 속성만 가지고 있어도 엔티티로 인정

6) 엔티티는 다른 엔티티와 최소 한 개 이상의 관계가 있어야 한다.

> 관계가 설정되지 않은 엔티티의 도출은 부적절한 엔티티가 도출되거나 다른 엔티티와 적절한 관계를 찾지 못한 것

 

관계를 생략하여 표현해야 하는 경우

1) 통계를 위한 엔티티 - 통계업무만을 위해 별도로 엔티티를 다시 정의하게 됨

2) 코드를 위한 엔티티 - 너무 많은 엔티티와 엔티티간의 관계 설정으로 인해 데이터 모델의 읽기효율성 저하

3) 시스템 처리시 내부 필요에 의한 엔티티- 트랜잭션이 업무적으로 연관된 테이블과 관계 설정이 필요하나 업무적인 필요가 아니고 시스템 내부적인 필요에 의해 생성된 엔티티로 관계를 생략

 

엔티티의 분류

분류 기준	종류	정의, 특징
유무형에 따른 분류	유형엔티티	물리적 형태가 있고 안정적이며 지속적으로 활용되는 엔티티 ex)사원, 물품, 강사
	개념엔티티	물리적인 형태는 존재하지 않고 관리해야할 개념적 정보 ex) 조직, 보험상품
	사건엔티티	업무를 수행함에 따라 발생되는 엔티티로서 비교적 발생량이 많으며 각종 통계자료에 이용 ex)주문, 청구, 미납
발생시점에 따른 분류	기본/키 엔티티	- 그 업무에 원래 존재하는 정보 - 다른 엔티티와 관계에 의해 생성되지 않고 독립적으로 생성 가능하며 자신은 타 엔티티의 부모의 역할 - 다른 엔티티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가짐 ex)사원, 부서, 고객, 상품, 자재
	중심엔티티	- 기본엔티티로부터 발생되고 그 업무에 있어서 중심적 역할 - 데이터 양이 많이 발생되고 다른 에니티와의 관계를 통해 많은 행위엔티티를 생성 ex)계약, 사고, 예금원장, 청구, 주문, 매출
	행위엔티티	- 두 개 이상의 부모엔티티로부터 자주 발생되고 자주 내용이 바뀌거나 데이터량이 증가 - 상세 설계단계나 프로세스와 상관모델링을 진행하면서 도출될 수 있음. ex) 주문목록, 사원변경이력
생성 주체에 따른 분류	독립엔티티	- 스스로 생성이 가능
	의존엔티티	- 스스로 생성이 불가

명명

1) 현업업무에서 사용하는 용어를 사용

2) 가능하면 약어를 사용하지 말자

3) 단수명사를 사용

4) 모든 엔티티에서 유일하게 이름이 부여

5) 엔티티 생성의미대로 이름을 부여

제3절 속성

속성

- 업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더이상 분리되지 않는 최소의 데이터 단위

- 엔티티를 설명하고 인스턴스의 구성요소

- 엔티티에 속한 엔티티에 대한 자세하고 구체적인 정보를 나타내며 각각의 속성은 구체적인 값을 가짐

 

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

- 한 개의 엔티티는 두 개 이상의 인스턴스 집합이어야함

- 한 개의 엔티티는 두 개 이상의 속성을 가짐

- 한 개의 속성은 한 개의 속성값을 가짐.

 

특징

- 엔티티와 마찬가지로 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야함

- 정규화 이론에 근간하여 정해진 주식별자에 함수적 종속성을 가져야함

- 하나의 속성에는 한 개의 값만 가짐(하나의 속성에 여러 값이 있는 경우 별도의 엔티티를 이용해 분리)

 

속성의 분류

분류기준	종류	특징
속성의 특성에 따른 분류	기본속성	- 업무분석을 통해 바로 정의한 속성 - 코드성 데이터, 엔티티를 식별하기 위해 부여된 일련번호, 다른 속성을 계산하거나 영향을 받아 생성된 속성을 제외한 모든 속성
	설계속성	- 원래 업무상 존재하지는 않지만 설계를 하면서 도출해내는 속성 - 코드성 속성은 원래 속성을 업무상 필요에 의해 변형하여 만든 설계속성이며 일련번호와 같은 속성은 단일한 식별자를 부여하기 위해 모델 상에서 새로 정의하는 설계속성
	파생속성	- 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성 - 보통 계산된 값이 이에 해당 > 데이터의 정합성을 위해 최대한 적게 정의 - 그 값이 계산된 로직을 속성정의서에 기록하여 검증시 활용 - 그 속성이 가지고 있는 계산방법에 대해 반드시 어떤 엔티티에 어떤 속성에 의해 영향을 받는지 정의가 되어야 함
엔티티 구성방식에 따른 분류	PK속성	- 엔티티를 식별할 수 있는 속성
	FK속성	- 다른 엔티티와 관계에서 포함된 속성
	일반속성	- 엔티티에 포함되어 있고 PK,FK에 포함되지 않는 속성
세부 의미를 쪼갤 수 있는지 여부에 따른 분류	단순속성	- 더 이상 다른 속성들로 구성될 수 없는 단순한 속성
	복합속성	- 여러 세부 속성들로 구성가능한 속성
속성 값을 얼마나 가지는지에 따른 분류	단일값 속성	- 속성 하나에 한 개의 값을 가지는 경우
	다중값 속성	- 여러 개의 값을 가지는 경우 - 하나의 엔티티에 포함될 수 없기에 1차 정규화를 하거나 별도의 엔티티를 만들어 관계로 연결해야함

도메인 - 각 속성이 가질 수 있는 값의 범위( 이외의 값은 가질 수 없음)

 

속성의 명명

- 속성 이름을 정확하게 부여하고 용어사전이라는 업무사전을 프로젝트에 사용

- 도메인정의를 미리 정의하여 용어사전과 같이 사용

 

속성부여 원칙

- 현업에서 사용하는 이름을 부여

- 서술식 속성명을 사용하지 말자 => 명사형을 이용하고 수식어가 많이 붙지 않도록 유의하여 작성(소유격X)

- 공용화되지 않은 업무에서 사용하지 않는 약어는 사용하지 않는 것이 좋음

- 모든 속성의 이름은 유일하게 작성하는 것이 좋음

제4절 관계

관계

- 엔티티의 인스턴스 사이의 논리적인 연관선으로 존재의 형태로서나 행위로서 서로의 연관성이 부여된 상태

- 관계는 엔티티 안에 인스턴스가 개별적으로 관계를 가지는 것이고 이것의 집합을 관계로 표현

- 관계 페어링 => 각 엔티티의 인스턴스들은 자신이 관련된 인스턴스들과 관계의 어커런스로 참여하는 형태

-  ERD에서는 관계가 속성을 가질 수 있었으나 최근에는 관계를 위해 속성을 도출X

 

분류

존재에 의한 관계	존재의 형태에 의해 관계가 형성 ex)소속된다
행위에 의한 관계	행위에 의해 관계가 형성 ex)주문한다

UML

- 연관관계 - 항상 이용하는 관계로 존재적 관계

- 의존관계 - 상대방 클래스의 행위에 의해 관계가 형성될 때 구분하여 표현

 

=> ERD에서는 존재적 관계와 행위에 의한 관계를 구분하지 않았다면 클래스다이어그램에서는 이를 구분하여 연관관계와 의존관계로 표현하고 있음

연관관계 > 실선으로 표현되고 소스코드에서 멤버변수로 선언

의존관계 > 점선으로 표현되고 소스코드에서는 행위를 나타내는 Operation에서 파라미터 등으로 이용 가능

 

관계의 개념

관계명(관계의 이름)

- 엔티티가 관계에 참여하는 형태

- 관계시작점/관계끝점  => 모두 관계이름을 가져야 하며 참여자의 관점에 따라 관계이름이 능동적이거나 수동적으로 명명됨

- 애매한 동사를 피한다 (관련이 있다, 이다, 한다)

- 현재형으로 표현

관계차수(1:1,1:N,N:M)

- 두 엔티티간 관계에서 참여자 수를 표현하는 것

- Crow's Foot 모델에서는 선을 이용해 표현(한 개 참여시 실선 유지, 다수 참여시 까마귀발)

관계선택사양(필수관계, 선택관계)

필수참여 > 참여하는 모든 참여자가 반드시 관계를 가지는 관계

선택참여 > 물리속성에서 FK로 연결시 null을 허용할 수 있는 항목

선택참여 관계 > ERD에서 선택참여하는 엔티티 쪽을 원으로 표시

 

관계의 체크사항

- 두 개의 엔티티 사이에 관심있는 연관규칙이 존재?

- 두 개의 엔티티 사이에 정보의 조합이 발생?

- 업무기술서, 장표에 관계연결에 대한 규칙이 서술?

- 업무기술서, 장표에 관계연결을 가능하게 하는 동사가 있는가?

 

관계 읽기

- 기준 엔티티를 한개로 읽고 대상 엔티티의 개수를 읽는다.

- 관계선택사양과 관계명을 읽는다.

제5절 식별자

식별자

- 하나의 엔티티에 구성되어 있는 하나의 유일한 식별자가 존재

- 식별자는 업무적으로 구분이 되는 정보로 논리 데이터 모델링 단계에서 사용하며 키는 데이터베이스 테이블의 접근을 위한 매개체로 물리 데이터 모델링 단계에서 사용

 

특징

- 주식별자에 의해 엔티티내에 모든 인스턴스들이 유일하게 구분되어야함(유일성)

- 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야함(최소성)

- 지정된 주식별자의 값은 자주 변경되지 않아야함(불변성)

- 주식별자가 지정이 되면 반드시 값이 들어와야함(존재성)

 

분류

분류 기준	종류	정의
대표성 여부	주식별자	엔티티 내에서 각 어커런스를 구분할 수 있는 구분자이며, 타 엔티티와 참조관계를 연결할 수 있는 식별자
	보조식별자	엔티티 내에서 각 어커런스를 구분할 수 있는 구분자이나 대표성을 가지지 못해 참조관계 연결이 불가
스스로 생성여부	내부식별자	엔티티 내부에서 스스로 만들어지는 식별자
	외부식별자	타 엔티티와의 관계를 통해 타 엔티티로부터 받아오는 식별자
속성의 수	단일식별자	하나의 속성으로 구성된 식별자
	복합식별자	둘 이상의 속성으로 만들어지는 식별자
대체 여부	본질식별자	업무에 의해 만들어지는 식별자
	인조식별자	업무적으로는 만들어지지 않으나 원조식별자가 복잡한 구성을 가지고 있기에 인위적으로 만든 식별자

주식별자 도출기준

1) 해당 업무에서 자주 이용되는 속성을 주 식별자로 지정

2) 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정X

3) 복합으로 주식별자로 구성할 경우 너무 많은 속성이 포함되지 않도록 해야함.

- 주식별자의 속성의 개수가 많은 경우(7~8개 이상) 새로운 인조식별자를 생성하였을 때 조건절이 단순해짐

 

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

1) 외부식별자

- 자기 자신의 엔티티에서 필요한 속성이 아닌 다른 엔티티와의 관계를 통해 자식 쪽의 엔티티에 생성되는 속성

- DB 생성시 FK역할을 함

- 엔티티에 주식별자가 지정되고 엔티티간 관계를 연결시 부모쪽의 주식별자를 자식엔티티의 속성으로 내려보냄

=> 외부식별자를 자신의 주식별자로 이용할 것인지 부모와 연결되는 속성으로만 이용할 것인지 결정필요

2) 식별자관계

- 부모로부터 받은 식별자를 주식별자로 이용하는 경우는 반드시 부모엔티티가 생성되어야 자기 자신의 엔티티가 생성되는 경우 

- 부모로부터 받은 속성을 자식 엔티티가 받아서 그것만으로 주식별자로 사용시 1:1관계

- 다른 부모엔티티에서 받은 속성을 포함하거나 스스로 가지고 있는 속성과 함께 주식별자로 구성시 1:M관계

식별자 관계 => 자식엔티티의 주식별자로 부모의 주식별자가 상속되는 경우

3) 비식별자관계

- 부모엔티티로부터 속성을 받았으나 자식엔티티의 주식별자로 사용하지 않고 일반적인 속성으로만 사용시

1> 자식 엔티티가 받은 속성이 반드시 필수가 아니어도 상관이 없어서 부모 없는 자식이 생성될 수 있는 경우

2> 엔티티별로 데이터 생명주기를 다르게 관리하는 경우( 부모엔티티의 인스턴스가 자식의 엔티티와 관계가 있었지만 자식만 남겨두고 먼저 소멸될 수 있는 경우)

3> 여러 엔티티가 하나의 엔티티로 통합되어 표현되었는데 각각의 엔티티가 별도의 관계를 가질 때

4> 자식엔티티에 주식별자로 사용하여도 가능하나 자식엔티티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단될 때

 

식별자관계로만 설정시 문제점

- PK속성의 수가 데이터 모델의 흐름이 길어질수록 증가할 수 밖에 없는 구조를 가지게됨.

비식별자관계로만 설정시 문제점

- 속성이 자식엔티티로 상속이 되지 않아 자식엔티티에서 데이터를 처리할 때 부모엔티티까지 찾아가야 하는 경우가 발생

 

식별자관계와 비식별자관계 모델링

- 기본적으로 식별자관계로 모든 관계를 연결

- 독립적으로 주식별자를 구성한다는 의미 > 업무적 필요성+ 성능상 필요성