[SQLD자격증독학] 제 1장 데이터 모델링의 이해 문제 정리

1. 모델링은 현실세계에 대해서 표현하는 것으로 이해할 수 있다.

- 추상화의 의미

- 단순화의 의미

- 정확화의 의미

- 업무분석 및 업무형상화를 하는 목적 있음

2. 데이터 모델링이 필요한 주요 이유

- 일정한 표기법

: 업무 내용을 정확하게 분석하는 것

- 분석된 모델

: 실제 데티어베이스를 생성하여 개발 및 데이터 관리에 사용

-> 데이터베이스만을 구축하기 위한 용도로 쓰이는 것이 아니라 데이터 모델링 자체로서 업무를 설명하고 분석하는 부분에서 매우 중요한 의미 지님.

3. 데이터 모델링을 할 때 유의해야 할 사항

- 중복(Duplication)

- 비유연성(Inflexibility)

- 비일관성(Inconsistency)

4. 데이터 모델링의 유의점에 해당하는 특성

프로세스의 작은 변화가 애플리케이션과 데이터 베이스에 중대한 변화를 일으킬 수 있는 가능성 -> 비유연성

5. 데이터 모델링 개념

- 개념적 데이터 모델링

: 추상화 수준 높다

: 업무 중심적

- 논리적 데이터 모델링

: Key, 속성, 관계 등을 정확하게 표현

: 재사용성 높다

- 물리적 데이터 모델링

: 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계

6. ANSI-SPARC에서 정의한 3단계 구조(three-level architecture)

- 외부 스키마(External Schema)

: 각 사용자의 관점

- 개념 스키마(Conceptual Schema)

: 모든 사용자 관점을 통합한 조직 전체 관점의 통합적 표현

- 내부 스키마(Internal Schema)

: 물리적인 접근 방법

7. ERD 표기법

ㅁ : 개체, O : 0개, ㅣ : 1개, ㅌ : 1개 이상

실선 : 부모테이블의 기본키를 자식 테이블이 기본 키로 사용할 경우

점선 : 부모테이블의 기본키를 자식 테이블에서 기본 키로 사용하지 않을 경우

8. ERD에 대한 설명

- 1976년 피터첸(Peter Chen)에 의해 Entity-Relationship Model(E-R Model)이라는 표기법이 만들어졌다

- 일반적으로 ERD를 작성하는 방법

1) 엔터티를 그린다

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

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

4) 관계명을 기술한다

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

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

- 관계의 명칭은 관계 표현에 잇어서 매우 중요한 부분이다

- 가장 중요한 엔터티를 왼쪽 상단에 배치

- 해당 업무에서 가장 중요한 엔터티는 왼쪽 상단에서 조금 아래쪽 중앙에 배치

9. 엔터티는 2개 이상의 속성과 2개 이상의 인스턴스를 가져야함.

S병원은 여러명의 환자가 존재하고 각 환자에 대한 이름, 주소 등을 관리해야 한다.

S병원 -> 1개

환자 -> 여러명, 속성(이름, 주소 등) -> 엔터티의 기본 자격을 갖춤

10. 엔터티의 특징

- 속성이 없는 엔터티 X, 반드시 속성을 가져야 한다.

- 엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 있어야한다. 단, 통계성 엔터티나, 코드성 엔터티의 경우 관계를 생략할 수 있다.

- 영속적으로 존재하는 인스턴스의 집합이어야 한다. (한 개 이상이 아니라 두 개 이상)

- 데이터로서 존재하지만 업무에서 필요로 하지 않으면 해당 업무의 엔터티로 성립 될 수 X.

12. 엔터티의 분류

- 유무형에 따른 분류

-> 유형 엔터티

: 물리적인 형태가 있다

: 안정적

: 지속적으로 활용되는 엔터티

ex) 사원, 물품, 강사 등

-> 개념 엔터티

: 관리해야 할 개념적 정보로 구분되는 엔터티

ex) 조직, 보험 상품 등

-> 사건 엔터티

: 업무를 수행함에 따라 발생되는 엔터티

: 비교적 발생량이 많다

: 각종 통계자료에 이용

ex) 주문, 청구, 미납 등

- 발생 시점에 따른 분류

-> 기본 엔터티(키엔터티)

: 다른 엔터티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가진다.

: 독립적으로 생성 가능

: 타 엔터티의 부모의 역할을 하게 된다.

ex) 사원, 부서, 고객, 상품, 자재 등

-> 중심 엔터티(메인엔터티)

: 기본 엔터티로부터 발생되고 그 업무에 있어서 중심적인 역할

: 데이터 양이 많이 발생

: 다른 엔터티와의 관계를 통해 많은 행위 엔터티를 생성

ex) 계약, 사고, 예금원장, 청구, 주문, 매출 등

-> 행위 엔터티

: 두 개 이상의 부모엔터티로부터 발생

: 자주 내용이 바뀌거나 데이터량이 증가

: 분석 초기 단계에서 잘 나타나지 X

ex) 주문목록, 사원 변경이력

13. 엔터티의 이름을 부여하는 방법

- 현업의 업무 용어 사용

- 가능하면 약어 사용하지 X

- 단수 명사

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

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

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

15. 속성에 대한 설명

- 엔터티에 대한 자세하고 구체적인 정보를 나타낸다

- 하나의 엔터티는 두 개 이상의 속성을 갖는다

- 하나의 인스턴스에서 각각의 속성은 한 개의 속성값을 가져야 한다

( 한 개의 속성은 한 개의 속성값을 갖는다 )

- 속성도 집합이다

16. 속성의 특성에 따른 분류

- 기본속성

: 업무로부터 추출한 모든 속성

: 가장 일반적이고 많은 속성을 차지

: 코드성데이터, 엔터티를 식별하기 위해 부여된 일련번호, 다른 속성을 계산하거나 영향을 받아 생성도니 속성을 제외한 모든 속성

: 업무로부터 분석한 속성이라도 이미 업무상 코드로 정의한 속성이 많다는 것

-> 이러한 경우, 속성의 값이 원래 속성을 나타내지 못하므로 기본 속성 X

- 설계속성

: 업무상 필요한 데이터 이외에 데이터 모델링을 위해, 업무를 규칙화하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성

: 대개 코드성 속성은 원래 속성을 업무상 필요에 의해 변형하여 만든 설계속성

: 일련번호와 같은 속성은 단일한 식별자를 부여하기 위해 모델 상에서 새로 정의하는 설계속성

- 파생속성

: 다른 속성에 영향을 받아 발생하는 속성

: 보통 계산된 값들이 이에 해당

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

- 우리은행은 예금분류(일반예금, 특별예금 등)의 원금, 예치기간, 이자율을 관리할 필요가 있다. 또한 원금에 대한 이자율을 적용하여 계산된 이자에 대해서도 속성으로 관리하고자 한다.

: 일반예금은 코드 엔터티를 별도로 구분하고 값에는 코드값만 포함한다

: 예금분류는 설계 속성이다

: 원금, 예치기간은 기본 속성이다.

: 이자율도 기본 속성이고 이자가 파생속성이다

17. 파생속성

: 데이터를 조회할 때 빠른 성능을 낼 수 있도록 하기 위해 원래 속성의 값을 계산하여 저장할 수 있도록 만든 속성

18. 도메인(Domain)

: 각 속성이 가질 수 있는 범위

20. 데이터모델링의 관계에 대한 설명

- 관계는 존재에 의한 관계와 행위에 의한 관계로 구분될 수 있으나 ERD에서는 관계를 연결할 때, 존재와 행위를 구분하지 않고 단일화된 표기법을 사용

-> ERD는 존재적 관계와 행위에 의한 관계를 구분 X

- UML(Unified Modeling Language)에는 클래스다이어그램의 관계 중 연관관계와 의존관계가 있고 이것은 실선과 점선의 표기법으로 다르게 표현된다.

-> UML은 존재적 관계와 행위에 의한 관계를 구분하여 연관관계와 의존관계로 표현

21. 관계에 대한 설명

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

- 관계의 표기법은 관계명, 관계차수, 선택성(선택사양)의 3가지 개념으로 표현

22. 관계명 : 관계의 이름, 관계의 차수 : 1:1, 1:M, N:M, 관계선택사양 : 필수관계, 선택관계

23. 두 개의 엔터티 사이에 정의한 관계를 체크하는 사항

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

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

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

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

26. 식별자의 종류

- 주 식별자 | 보조 식별자

: 엔터티 내에서 대표성을 가지는 가에 따라

- 내부 식별자 | 외부 식별자

: 엔터티 내에서 스스로 생성되었는지 여부에 따라

- 단일 식별자 | 복합 식별자

: 단일 속성으로 식별이 되는가에 따라

- 본직 식별자 | 인조 식별자

: 원래 업무적으로 의미가 있던 식별자 속성을 대체하여 일련번호와 같이 새롭게 만든 식별자를 구분하기 위해

- 사원 엔터티 -> 사번, 부서번호, 주민등록번호

: 주식별자, 단일식별자, 내부식별자, 본질식별자

28. 주식별자의 특징

: 유일성, 최소성, 불변성, 존재성

30. 비식별자 관계로 연결하는 것을 고려해야 하는 경우

- 부모엔터티에 참조값이 없어도 자식엔터티의 인스턴스가 생성될 수 있는 경우

- 부모 엔터티의 인스턴스가 자식 엔터티와 관계를 가지고 있었지만 자식만 남겨두고 먼저 소멸될 수 있는 경우

- 여러 개의 엔터티를 하나로 통합하면서 각각의 엔터티가 갖고 있던 여러 개의 개별 관계가 통합되는 경우

- 자식쪽 엔터티의 주식별자를 부모엔터티와는 별도로 생성하는 것이 더 유리하다고 판단하는 경우

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