[SQLD] DATA ON - AIR (1장 ~ 3장) : 엔터티, 속성, 관계

1. 엔터티

(1) 엔터티의 개념

- 사람, 장소, 물건, 사건, 개념 등의 명사에 해당

- 업무상 관리가 필요한 관심사

- 저장이 되기 위한 어떤 것(Thing)

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

 

- 엔터티는 속성을 가진다.   ex. 대학생 - 학번, 이름, 학년, 전공 과목... 

- 엔터티는 인스턴스의 집합이다.   ex. 과목 - 수학, 영어, 국어, 사회, 과학...

- 엔터티는 눈에 보이지 않는 개념도 포함! 

** 실제 업무상에는 눈에 보이지 않는 것이 엔터티로 도출되는 경우 多

 

(2) 엔터티와 인스턴스에 대한 내용과 표기법

- 대부분 사각형으로 표현됨.

(3) 엔터티의 특징

- 해당 업무에서 필요하고 관리하고자 하는 정보

- 유일한 식별자에 의해 식별 가능: 각각의 업무적으로 의미를 가지는 인스턴스가 식별자에 의해 한 개씩만 존재하는지 검증해보아야 함.

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

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

(사용되지 않는 엔터티의 경우, 1) 엔터티 제거 OR 2) 누락 프로세스가 존재할 시, 해당 프로세스에 추가)

- 반드시 속성이 존재.

- 다른 엔터티와 최소 한 개 이상의 관계 (존재적 연관성, 행위적 연관성을 가지고 있어야 함.)

 

(4) 엔터티의 분류

1) 유무형에 따른 분류

 - 유형엔터티 ~ 물리적 형태 존재. ex. 사원, 물품, 강사

- 개념엔터티 ~ 물리적 형태 존재  x. ex. 조직, 보험상품

- 사건엔터티 ~ 업무 수행에 따라 발생되는 엔터티 ex. 주문, 청구, 미납

2) 발생시점에 따른 분류

- 기본엔터티 ~ 업무에 원래 존재하는 정보. 독립적으로 생성 가능. 타 엔터티의 부모 역할. 자신의 고유한 주 식별자 가짐. ex. 사원, 부서, 고객, 상품, 자재

- 중심엔터티 ~ 기본엔터티로부터 발생. 다른 엔터티와의 관계를 통해 많은 행위엔터티 생성. ex. 계약, 사고, 예금원장, 청구, 주문, 매출

- 행위엔터티 ~ 두 개 이상의 부모엔터티로부터 발생. 자주 내용 바뀌거나 데이터량 증가. ex. 주문목록, 사원변경이력

3) 엔터티 분류 방법의 예

4) 엔터티 자가 생성 여부: 독립 엔터티, 의존 엔터티

 

(5) 엔터티의 명명

- 현업업무에서 사용하는 용어 사용

- 약어 사용 X

- 단수 명사 사용

- 모든 엔터티에서 유일하게 이름 부여

- 엔터티 생성 의미대로 이름 부여

---

2. 속성

(1) 속성의 개념

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

- 엔터티를 설명하고 인스턴스의 구성요소가 된다.

 

(2) 엔터티, 인스턴스와 속성, 속성값에 대한 내용과 표기법

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

- 한 개의 엔터티: 두 개 이상의 인스턴스의 집합, 2개 이상의 속성을 가짐.

- 한 개의 속성: 한 개의 속성값을 가짐

2) 속성의 표기법 : 엔터티 내에 이름을 포함하여 표현

 

 

(3) 속성의 특징

- 해당 업무에서 필요하고 관리하고자 하는 정보

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

- 하나의 속성에는 한 개의 값

 

(4) 속성의 분류

1) 속성의 특성에 따른 분류

- 기본 속성: 업무 분석을 통해 바로 정의한 속성

- 설계 속성: 업무상에는 존재 X. 설계를 하면서 도출해내는 속성 (데이터 모델링, 업무 규칙화를 위해 속성을 새로 생성/변형하여 정의) ex. 코드성 속성 (변형에 의한 설계 속성), 일련번호와 같은 속성 (새로 정의하는 설계 속성)

- 파생 속성: 다른 속성으로부터 계산/변형되어 생성되는 속성 ex. 계산된 값 

** 가급적 파생 속성을 적게 정의하는 것이 좋다.

 

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

- PK(Primary Key) 속성: 엔터티를 식별할 수 있는 속성

- FK(Foreign Key) 속성: 다른 엔터티와의 관계에서 포함된 속성

- 일반 속성: 엔터티에 포함, PK, FK에 포함되지 않은 속성

** 다중값 속성: 하나의 엔터티에 포함 X. > 1차 정규화 OR 별도의 엔터티를 만들어 관계로 연결

 

(5) 도메인

- 각 속성에서 가질 수 있는 값의 범위

- 엔터티 내에서 속성에 대한 데이터 타입, 크기, 제약사항을 지정

 

(6) 속성의 명명

- 속성명 > 사용자 인터페이스 (UI)를 나타냄 > 업무와 직결되는 항목

- 속성의 명칭 부여 원칙

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

2) 서술식 속성명은 사용 X (소유격도 사용 X)

3) 약어 사용은 가급적 제한

4) 전체 데이터 모델에서 유일성 확보 (데이터 정합성에 큰 도움, 안정적으로 반정규화 적용 가능)

---

3. 관계

(1) 관계의 개념

1) 관계의 정의

- 엔터티의 인스턴스 사이의 논리적인 연관성

- 존재의 형태/행위로서 서로에게 연관성이 부여된 상태

2) 관계의 패어링

- 관계: 엔터티 안에서 인스턴스가 개별적으로 관계를 가지는 것(패어링) > 이것의 집합을 관계로 표현

> 개별 인스턴스가 각각 다른 종류의 관계를 가지고 있다면, 두 엔터티 사이에 두 개 이상의 관계가 형성 可

- 정성철(강사)는 이춘식(수강생), 황종하(수강생)를 강의함.

- 조시형(강사)은 황종하(수강생)를 강의함. 

=> 인스턴스가 개별적으로 관계를 가짐 => 이것의 집합을 강사, 강의한다, 수강생으로 구성된 관계로 표현!!

 

(2) 관계의 분류

- 존재에 의한 관계와 행위에 의한 관계

1) 소속: 존재의 형태   2) 주문: 행위

- UML: 연관관계(존재적 관계, 실선으로 표현)와 의존관계(행위에 의해 관계가 형성, 점선)

 

(3) 관계의 표기법

1) 관계명(Membership) : 관계의 이름

- 엔터티가 관계에 참여하는 형태를 지칭

- 관계시작점과 관계끝점

- 명명규칙 : 애매한 동사 피하기. 현재형으로 표현

 

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

- 두 개의 엔터티간 관계에서 참여자의 수를 표현

- 고려사항: 한 개의 관계가 존재하느냐 아니면 두 개 이상의 멤버쉽이 존재하는지 파악

- 1:1(ONE TO ONE) 관계

- 1:M(ONE TO MANY) 관계

- M:M(MANY TO MANY) 관계

 

3) 관계선택사양(Optionality) : 필수관계, 선택관계

- 필수참여관계 ex. “반드시 지하철의 문이 닫혀야만 지하철은 출발한다.” > 지하철출발과 지하철문닫힘은 필수(Mandatory)적으로 연결 관계

- 선택참여관계 ex. 지하철의 출발과 지하철방송 (정보로서 관련은 있음. BUT 방송시점이 조금씩 다르거나 안내 방송 시스템이 고장나도 지하철 운행에 큰 영향은 주지 X) 

- 필수참여: 참여하는 모든 참여자가 반드시 관계를 가지는, 타 엔터티의 참여자와 연결이 되어야 하는 관계

                 : ex. 주문서 - 주문목록

                 : 엔터티 쪽에 아무런 표시를 하지 않는다.

- 선택 참여: 물리속성에서 Foreign Key로 연결될 경우 Null을 허용 가능

                  : ERD에서 관계를 나타내는 선에서 선택참여하는 엔터티 쪽을 원으로 표시

                  : ex. 목록 - 주문목록 (목록은 주문될 수도, 안 될수도 있음)

 

(4) 관계의 정의 및 읽는 방법

1) 관계 체크사항

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

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

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

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

 

2) 관계 읽기

- 기준(Source) 엔터티를 한 개(One) 또는 각(Each)으로 읽는다.

- 대상(Target) 엔터티의 관계참여도 즉 개수(하나, 하나 이상)를 읽는다.

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