SQLD 공부 1. 데이터 모델링의 이해

1. 데이터 모델링의 특징

데이터 모델링이란?

• 현실 세계의 비즈니스 프로세스와 데이터 요구 사항을 추상적이고 구조화된 형태로 표현하는 과정
• 데이터베이스의 구조와 관계를 정의하며, 이를 통해 데이터의 저장, 조작, 관리 방법을 명확하게 정의

 

1. 추상화

• 현실세계를 일정한 형식에 맞추어 간략하게 대략적으로 표현하는 과정
• 다양한 현상을 일정한 양식인 표기법에 따라 표현

2. 단순화

• 현실을 단순화하여 핵심 요소에 집중하고 불필요한 세부 사항을 제거
• 단순화를 통해 복잡한 현실 세계를 이해하고 표현하기 쉬워짐

3. 명확화

• 대상에 대한 애매모호함을 최대한 제거하고 정확하게 현상을 기술하는 과정
• 명확화를 통해 모델을 이해하는 이들의 의사소통을 원활히 함

 

2. 데이터 모델링 시 유의사항

유의사항1 : 중복(Duplication)
데이터 모델은 같은 데이터를 사용하는 사람, 시간, 그리고 장소를 파악하는 데 도움을 주어 데이터베이스가 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 한다.

유의사항2 : 비유연성(Inflexibility)
데이터 모델을 어떻게 설계했느냐에 따라 사소한 업무변화에도 데이터 모델이 수시로 변경 되어 유지보수의 어려움을 가중시킬 수 있다. 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 모델링은 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터 베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.

유의사항3 : 비일관성(Inconsistency)
데이터 중복이 없더라도 비일관성은 발생할 수 있는데, 예를 들면 신용 상태에 대한 갱신 없이 고객의 납부 이력 정보를 갱신하는 경우이다. 개발자가 서로 연관된 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 수정할 수 있기 때문에 이와 같은 문제가 발생할 수 있다. 데이터 모델링을 할 때 데이터와 데이터 간의 상호 연관 관계에 대해 명확하게 정의한다면 이러한 위험을 사전에 예방하는 데 도움을 줄 수 있다.
사용자가 처리하는 프로세스 혹은 이와 관련된 프로그램과 테이블의 연계성을 높이는 것은 데이터 모델이 업무 변경에 대해 취약하게 만드는 단점에 해당한다.

- 데이터베이스 내의 정보가 모순되거나 상반된 내용을 갖는 상태.

- 데이터 간 상호연관 관계를 명확히 정의, 데이터 품질 관리 필요 
 

3. 스키마

데이터베이스 스키마 구조는 3단계로 구분되고 각각은 상호 독립적인 의미를 가지고 고유한 기능을 가진다.
 

외부 스키마

여러 사용자 관점으로 구성

개념 스키마

통합관점의 스키마 구조를 표현한 것을 개념 스키마(Conceptual Schema)라고 하며, 데이터 모델링은 통합관점의 뷰를 가지고 있는 개념 스키마를 만들어가는 과정으로 이해할 수 있다.
모든 응용시스템들이나 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 db를 기술한 것으로 db에 저장되는 데이터와 그들 간의 관계를 표현하는 스키마

내부 스키마

물리적인 저장구조를 표현.
 
 
논리적인 데이터 독립성을 고려하는 단계는 외부단계와 개념적 단계이다.
 

 

아래 설명이 나타내는 데이터 모델의 개념으로 가장 적절한 것은?
아 래
주문이라는 엔터티가 있을 때 단가라는 속성값의 범위는 100에서 10,000 사이의 실수 값이며 제품명이라는 속성은 길이가 20자리 이내의 문자열로 정의할 수 있다.
① 시스템 카탈로그(System Catalog)
② 용어 사전(Word Dictionary)
③ 속성( Attribute Dictionary)
④ 도메인(Domain)

 

데이터 모델링을 할 때 속성의 명칭을 부여하는 방법으로 가장 적절하지 않은 것은?
① 속성의 이름에 약어를 사용할 경우 그 의미를 명확하게 이해할 수 없고 혼돈을 초래하여 커뮤니케이션의 혼란을 야기할 수 있으므로 지나친 약어 사용은 가급적 제한하도록 한다.
② 속성의 이름에는 서술식 용어는 사용하지 않도록 한다.
③ 직원 엔터티의 이름, 고객 엔터티의 이름과 같이 엔터티별로 동일한 속성명을 사용하여 데이터 모델의 일관성을 유지하는 것이 좋다.
④ 데이터 모델링 대상에서 사용하는 용어도 있고 외부에서 사용하는 용어도 있어 중복이 있을 때, 가급적 해당 업무에서 자주 사용하는 이름을 이용하도록 한다.

 

 

 

4. 엔터티

• 현실 세계에서 독립적으로 식별 가능한 객체나 사물을 나타냄
• 엔터티는 업무상 분석해야 하는 대상(인스턴스)들로 이루어진 집합
• 인스턴스는 엔터티의 특정한 속상 값들로 구성되며, 엔터티의 개념을 현실에서 구체적으로 나타낸 것
• 예) 엔터티와 속성, 인스턴스 등의 관계

 

엔터티의 특징

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.(예. 환자, 토익의 응시횟수, )
• 유일한 식별자에 의해 식별이 가능해야 한다.
• 영속적으로 존재하는 인스턴스의 집합 이어야 한다. ('한 개'가 아니라 '두 개' 이상)
• 엔터티는 업무 프로세스에 의해 이용되어야 한다.
• 엔터티는 반드시 속성이 있어야 한다.
• 엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다. 공통코드, 통계성 엔터티의 경우는 관계를 생략 가능

 

발생 시점에 따른 엔터티 분류

• 기본, 키 엔터티(Fundamental Entity,Key Entity)
• 중심 엔터티(MainEntity)
• 행위 엔터티(ActiveEntity)

 

 

부모 엔터티에 데이터가 입력될 때 자식 엔터티에 해당 값이 존재하는지의 여부와 상관없이 입력될 수 있는 구조로 표현

해설 : 엔터티를 어디에 배치하는가에 대한 문제는 필수사항은 아니지만 데이터 모델링 툴 사용 여부와 상관없이 데이터 모델의 가독성 측면에서 중요하다. 일반적으로 사람의 눈은 왼쪽에서 오른쪽, 위쪽에서 아래쪽으로 이동하는 경향이 있기 때문에, 데이터 모델링에서도 가장 중요한 엔터티를 왼쪽 상단에 배치하고, 이것을 중심으로 다른 엔터티를 나열하면서 전개하면 사람의 눈이 따라가기에 편리한 데이터 모델을 작성할 수 있다. 해당 업무에서 가장 중요한 엔터티는 왼쪽 상단에서 조금 아래쪽 중앙에 배치하여 전체 엔터티와 어울릴 수 있도록 하면 향후 관련 엔터티와 관계선을 연결할 때 선이 꼬이지 않고 효과적으로 배치할 수 있게 된다.

해설 : 병원은 S병원 1개이므로 엔터티로 성립되지 않으며, 이름, 주소는 엔터티의 속성으로 인식될 수 있다.
엔터티는 2개 이상의 속성과 2개 이상의 인스턴스를 가져 소위 면적으로 표현될 수 있어야 비로소 기본적인 엔터티의 자격을 갖췄다 할 수 있으므로 여러 명'의 복수 인스턴스와 이름, 주소 등의 복수 속성을 가진
'환자가 엔터티로 가장 적절하다고 할 수 있다.


해설 : 엔터티의 중요한 특징의 하나는 다른 엔터티와 관계를 가져야 한다는 것이다. 그러나 공통코드, 통계성 엔터티의 경우는 관계를 생략할 수 있다.

해설 : 엔터티의 발생 시점에 따라 기본 엔터티, 중심 엔터티, 행위 엔터티로 구분할 수 있다.

 

 

엔터티를 명명하는 일반적인 기준

용어를 사용하는 모든 표기법이 다 그렇듯이

첫 번째는 가능하면 현업 업무에서 사용하는 용어를 사용한다.

두 번째는 가능하면 약어를 사용하지 않는다.
세 번째는 단수명사를 사용한다.

네 번째는 모든 엔터티를 통틀어서 유일하게 이름이 부여되어야 한다.
다섯 번째는 엔터티 생성 의미대로 이름을 부여한다.

 

ERD 작성 순서

① 엔터티를 그린다
② 엔터티를 적절하게 배치한다
③ 엔터티 간 관계를 설정한다.
④ 관계명을 기술한다.
⑤ 관계의 참여도를 기술한다.
⑥ 관계의 필수여부를 기술한다.

 

두 개의 엔터티 사이에 정의한 관계에 대해 확인해야 할 사항으로 가장 적절 하지 않은 것은?
1 두 개의 엔터티 사이에 관심 있는 연관규칙이 존재하는가?
② 두 개의 엔터티 사이에 정보의 조합이 발생되는가?
③ 업무기술서, 장표에 관계연결을 가능하게 하는 명사(Noun)가 있는가?
4 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?

 

두 개의 엔터티 사이에서 관계를 도출할 때 확인해야 할 사항을 모두 고른 것은?
아래
(가) 두 개의 엔터티 사이에 관심 있는 연관규칙이 존재하는가?
(나) 두 개의 엔터티 사이에 정보의 조합이 발생되는가?
(다) 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
(라) 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가
있는가?

① (가),(나), (다)
② (가), (나), (라)
③ (가), (다), (라)
4 (가), (나), (다), (라)

 

5. 속성

속성이란 사전적인 의미로는 사물의 성질, 특징 또는 본질적인 성질이다. 그것이 없다면 실체를 생각할 수 없는 것으로 정의할 수 있다. 본질적 속성이란 어떤 사물 또는 개념에 없어서는 안 될 정표의 전부이다. 이 징표는 사물이나 개념이 어떤 것인지를 나타내고 그것을 다른 것과 구별하는 성질이라고 할 수 있다. 이런 사전적인 정의 외에 데이터 모델링 관점에서 속성을 정의하자면, "업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더 분리되지 않는 최소의 데이터 단위"로 정의할 수 있다.
업무상 관리가 가능한 최소의 의미 단위로 생각할 수 있고, 이것은 엔터티에서 한 분야를 담당하고 있다.
하나의 인스턴스에서 각각의 속성은 한 개의 속성값을 가져야 한다.
업무에서 필요로 하는 고유한 성질, 특징을 의미 -> 컬럼으로 표현할 수 있는 단위

속성의 명칭 부여
• 해당 업무에서 사용하는 이름을 부여한다.
• 서술식 속성명은 사용하지 않는다.
• 약어 사용은 가급적 제한한다.
• 전체 데이터 모델에서 유일성을 확보하는 것이 좋다.

 

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

• 한 개의 엔터티는 두 개 이상의 인스턴스 집합이어야 한다.
• 한 개의 엔터티는 두 개 이상의 속성을 갖는다.
• 한 개의 속성은 한 개의 속성값을 갖는다.
속성은 엔터티에 속한 엔터티에 대한 자세하고 구체적인 정보를 나타냄. 각 속성은 구체적인 값을 가짐

속성의 분류

속성의 특성에 따른 분류

• 기본 속성 : 업무로 부터 추출된 모든 속성
• 설계 속성 : 업무를 규칙화하기 위해 새로 만들어지거나 기본 속성 변형하여 만들어지는 속성. 상품코드 지점코드 등
• 파생 속성 : 다른 속성에 의해 만들어짐. 일반적으로 계산된 값. 합계 평균 이자 등

해설 : 업무분석을 통해 바로 정의한 속성을 기본속성(Basic Attribute), 원래 업무상 존재하지는 않지만 설계를 하면서 도출해 내는 속성을 설계속성(Designed Attribute), 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성을 파생속성(Derived Attribute)이라고 한다. 일반속성은 엔터티 구성방식에 따른 분류 속성으로 엔터티에 포함되어 있고 PK, FK에 포함되지 않은 속성이다.

 

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

• 기본키
• 외래키
• 일반 속성

분해 여부에 따른 분류

- **단순 속성**: 더 이상 나눌 수 없는 속성. 하나의 의미로 구성
- **복합 속성**: 여러 개의 의미로 구성된 경우. 예를 들어 주소(시도 시군구 읍면동 )
- **다중 값 속성**: 여러 개의 값을 가질 수 있는 속성입니다. 상품 리스트 등

 

 

도메인

각 속성은 가질 수 있는 값의 범위가 있는데 이를 그 속성의 도메인(Domain)이라 하며, 엔터티 내에서 속성에 대한 데이터 타입과 크기 그리고 제약사항을 지정하는 것이다.

 

해설 : 도메인은 속성이 가질 수 있는 값의 범위를 의미하며, 엔터티 내에서 속성에 대한 데이터 타입과 크기,
여러 가지 제약 사항 등을 지정하는 것이다.

 

문제

데이터를 조회할 때 빠른 성능을 낼 수 있도록 하기 위해 원래 속성값을 계산하여 저장할 수 있도록 만든 속성은?
1. 파생 속성(Derived Attribute)
2. 기본 속성 (Basic Attribute)
3. 설계 속성 (Designed Attribute)
4. PK 속성(PK Attribute)

 

아래 설명이 나타내는 데이터 모델의 개념으로 가장 적절한 것은?
아 래
주문이라는 엔터티가 있을 때 단가라는 속성값의 범위는 100에서 10,000 사이의 실수 값이며 제품명이라는 속성은 길이가 20자리 이내의 문자열로 정의할 수 있다.
① 시스템 카탈로그(System Catalog)
② 용어 사전(Word Dictionary)
③ 속성( Attribute Dictionary)
④ 도메인(Domain)

 

데이터 모델링을 할 때 속성의 명칭을 부여하는 방법으로 가장 적절하지 않은 것은?
① 속성의 이름에 약어를 사용할 경우 그 의미를 명확하게 이해할 수 없고 혼돈을 초래하여 커뮤니케이션의 혼란을 야기할 수 있으므로 지나친 약어 사용은 가급적 제한하도록 한다.
② 속성의 이름에는 서술식 용어는 사용하지 않도록 한다.
③ 직원 엔터티의 이름, 고객 엔터티의 이름과 같이 엔터티별로 동일한 속성명을 사용하여 데이터 모델의 일관성을 유지하는 것이 좋다.
④ 데이터 모델링 대상에서 사용하는 용어도 있고 외부에서 사용하는 용어도 있어 중복이 있을 때, 가급적 해당 업무에서 자주 사용하는 이름을 이용하도록 한다.. 관계

 

 

 

6. 관계

관계의 표기법
• 관계명(Membership) : 관계의 이름
• 관계자수(Cardinality): 1:1, 1:M, M:N
• 관계선택사양(Optionality) : 필수관계, 선택관계

 

문제

데이터 모델링의 관계에 대한 설명으로 가장 적절하지 않은 것은?
1 관계는 존재적 관계와 행위에 의한 관계로 나누어볼 수 있다.
② 관계의 표기법은 관계명, 관계차수, 식별성의 3가지 개념을 사용한다.
③ 부서와 사원, 엔터티 간의 '소속' 관계는 존재적 관계의 사례이다.
① 주문과 배송 엔터티 간의 '배송근거' 관계는 행위에 의한 관계의 사례 이다.

 

1:1, 1:M과 같이 두 엔터티 간의 관계에서 참여자의 수를 나타내는 것은?
( 관계명(Relationship Membership)
② 관계차수(Relationship Degree/Cardinality)
③ 관계선택사양(Relationship Optionality)
④ 관계정의(Relationship Definition)

 

두 개의 엔터티 사이에서 관계를 도출할 때 확인해야 할 사항을 모두 고른 것은?
아래
(가) 두 개의 엔터티 사이에 관심 있는 연관규칙이 존재하는가?
(나) 두 개의 엔터티 사이에 정보의 조합이 발생되는가?
(다) 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
(라) 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가
있는가?

 

데이터 모델링의 관계에 대한 설명으로 가장 적절하지 않은 것은?
1) 관계는 존재에 의한 관계와 행위에 의한 관계로 구분될 수 있으나 ERID에서는 관계를 연결할 때, 존재와 행위를 구분하지 않고 단일화된 표기법을 사용한다.
2) UML(Unifed Modeling language)에는 클래스다이어그램의 관계 중 연관관계(Association)와 의존관계(Dependency)가 있고 이것은 실선과 점선의 표기법으로 다르게 표현이 된다.
3) 연관관계는 항상 이용하는 관계로 존재적 관계에 해당하고, 의존관계는 상대방 클래스의 행위에 의해 관계가 형성되는 행위적 관계에 해당 한다.
4 연관관계는 오퍼레이션에서 파라미터 등으로 이용할 수 있고, 의존관계는 소스코드에서 멤버변수로 선언하여 사용할 수 있다.

7.식별자

주식별자의 특징
• 유일성: 주식별자에 의해 엔터티 내에 모든 인스턴스들을 유일 하게 구분함
• 최소성: 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 함
• 불변성: 주식별자가 한번 특정 엔터티에 지정되면 그 식별자의 값은 변하지 않아야 함
• 존재성: 주식별자가 지정되면 반드시 데이터 값이 존재해야 함(NULL 허용 안됨)

 

해설 : - 주식별자에 의해 엔터티 내에 모든 인스턴스들이 유일하게 구분되어야 한다.
- 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.
- 지정된 주식별자의 값은 자주 변하지 않는 것이어야 한다.
- 주식별자가 지정이 되면 반드시 값이 들어와야 한다.

 

해설 : 사번은 업무적으로 의미 있는 식별자로 시스템적으로 부여된 인조식별자가 아니라 일반적으로 사원 인스턴스의 탄생과 함께 업무적으로 부여되는 사원 인스턴스의 본질적인 속성에 해당한다 할 수 있기 때문에 본질식별자로 볼 수 있다

 

해설 : 명칭, 내역 등과 같이 이름으로 기술되는 것들은 주식별자로 지정하기에 적절하지 않다. 특히 사람의
이름은 동명이인이 있을 수 있기 때문에 주식별자로서 더더욱 부적절하다.

 

해설 : 식별자 특징 중 존재성은 주식별자는 반드시 데이터값이 존재함을 의미한다.
해설 : SQL 문의 조인관계를 최소화하기 위해 식별자 관계로 연결해야 한다.
해설 : 식별자는 대표성 여부에 따라 주식별자와 보조식별자, 스스로 생성 여부에 따라 내부식별자와 외부식별자, 속성의 수에 따라 단일식별자, 복합식별자, 대체여부에 따라 본질식별자, 인조식별자로 구분된다.
위의 문제에서 가)는 주식별자, 나)는 보조식별자, 다)는 본질식별자, 라)는 외부식별자를 설명하고 있다.

8. 정규형

 정규형
• 제1정규형 : 모든 속성은 반드시 하나의 값을 가져야 한다.
• 제2정규형 : 엔터티의 일반속성은 주식별자 전체에 종속이어야 한다.
• 제3정규형 : 엔터티의 일반속성 간에는 서로 종속적이지 않다.

 

9. 트랜잭션

 

 

10. NULL

 

11. 본질 식별자 vs 인조 식별자

: