[SQLD] 1-1 핵심 개념 정리

제1절 데이터 모델의 의해

모델링의 특징

- 현실세계를 '일정한 형식'에 맞추어 표현하는 추상화의 의미

- 제한된 언어나 표기법으로 이해하기 쉽게하는 단순화의 의미

- 애매모호함을 제거하고 누구나 이해할수 있도록 정확히 기술하는 정확화의 의미

 

모델링의 목적

- DB를 구축 혹은 시스템 구현을 위해 진행하는 사전 작업의 의미뿐만 아니라 그 자체로도 업무를 설명하고 분석

 

모델링의 유의점

1) 중복- 여러 장소에 같은 정보 저장X

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

3) 비일관성- 데이터간의 상호 연간관계를 명확하게 정의하여 일관성 유지

 

개념적 데이터 모델링

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

논리적 데이터 모델링

- 시스템으로 구축하고자 하는 업무에 대해 key, 속성, 관계를 명확히 표현( 정규화, 상세화)

물리적 데이터 모델링

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

 

외부스키마

- 사용자가 보는 개인적인 DB스키마

개념스키마

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

내부스키마

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

 

데이터 모델링의 3요소

1) 관계 2) 속성 3) Things

 

데이터 모델 표기법

ERD - 피터첸에 의해 개발/ 엔티티간의 관계를 도식화한 다이어그램

      - 데이터의 흐름과 프로세스와의 연관성을 이야기하는 표기법

 

과정 순서

1) 엔티티 그림

2) 엔티티를 적절히 배치( 왼쪽 상단에 중요 엔티티, 흐름의 중심이 되는 경우 중앙)

3) 엔티티 간의 관계 설정( 식별자 관계 설정)

4) 관계명 기술

5) 관계의 참여도 기술

6) 관계 필수여부 기술

 

제 2절 엔티티

엔티티

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

- 이를 설명하는 속성을 가짐

- 인스턴스의 집합

- 유무형 여부 상관없이 모두 가능

 

특징

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

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

3. 2개 이상의 인스턴스의 집합( 지속적으로 1개의 인스턴스만 존재한다면 불필요)

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

5. 반드시 주식별자를 제외한 일반 속성이 있어야함( 관계 엔티티는 주식별자만 있어도 상관없음)

ex) 다대다 관계에서 둘 사이를 연결해주는 엔티티를 만들게 되는데 이때 이 엔티티는 FK의 집합을 PK로 가짐

6. 다른 엔티티와 최소 1개 이상의 관계가 필요

 

관계를 생략하는 경우

1) 통계를 위한 엔티티 2) 코드를 위한 엔티티 3) 시스템 처리시 내부 필요에 의한 엔티티

 

엔티티의 분류

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

명명

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

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

3) 단수명사를 사용

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

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

 

제 3절 속성

속성

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

 

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

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

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

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

 

속성의 분류

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

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

 

속성부여 원칙

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

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

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

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

 

제 4절 관계

- 엔티티의 인스턴스간의 연관성이 부여된 상태

 

분류

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

 

관계의 요소

1) 관계명 - 관계의 이름

2) 관계차수 - 두 엔티티 간 관계에서 참여자 수를 표현

3) 관계선택사양- 필수관계인지 선택관계인지

 

관계의 체크사항

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

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

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

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

 

제 5절 식별자

식별자

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

- 식별자는 업무적으로 구분이 되는 정보로 논리 데이터 모델링 단계에서 사용하며

- 키는 데이터베이스 테이블의 접근을 위한 매개체로 물리 데이터 모델링 단계에서 사용

 

특징

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

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

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

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

 

분류

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

 

주식별자 도출기준

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

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

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

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

 

<식별자관계>

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

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

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

 

 

<비식별자관계>

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

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

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

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

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

 

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

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

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

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

 

기본적으로 식별자 관계로 모든 관계 연결하고 비식별자 관계 고려 요건

1) 약한 관계 2) 독립 PK 구성 3) PK속성 단순화