[과목 I] 자격검정 실전문제(01~50)

게시 2024/05/22

By tonyleekorea 118 분읽는 시간

제 1장 데이터 모델링의 이해

제1절 데이터 모델의 이해

제2절 엔터티

제3절 속성

제4절 관계

제5절 식별자

Q. 데이터 모델링의 특징으로 가장 적절하지 않은 것은?

②

① 현실 세계를 일정한 형식에 맞추어 표현하는 추상화의 의미를 가질 수 있다.

② 시스템 구현만을 위해 진행하는 사전단계의 작업으로서 데이터베이스 구축을 위한 사전작업의 의미가 있다.

③ 복잡한 현실을 제한된 언어나 표기법으로 이해하기 쉽게 하는 단순화의 의미를 가지고 있다.

④ 애매모호함을 배제하고 누구나 이해가 가능하도록 정확하게 현상을 기술하는 정확화의 의미를 가진다.

모델링은 단지 시스템 구현만을 위해 수행하는 태스크가 아니며, 시스템 구현을 포함한 업무분석 및 업무 형상화를 하는 목적도 있다.
모델링: 현실세계를 단순화하여 표현하는 것
모델링의 특징
- 추상화: 일정한 형식에 맞춰 표현함
- 단순화: 제한된 표기법이나 언어로 표현함
- 명확성: 이해하기 쉽게 표현함
모델링의 관점
- 데이터 관점: 업무와 데이터 및 데이터 사이의 관계
- 프로세스 관점: 진행되고 있거나 진행되어야 하는 업무
- 상호 관점: 데이터에 대한 업무 처리

Q. 데이터 모델링에 대한 설명으로 가장 적절하지 않은 것은?

③

① 업무 정보를 구성하는 기초가 되는 정보들을 일정한 표기법으로 표현한다.

② 분석된 모델로 데이터베이스를 생성하여 개발 및 데이터관리에 사용하기 위한 것이다.

③ 데이터베이스를 구축하는 목적으로 데이터 모델링을 수행하며 업무에 대한 설명은 별도의 표기법을 이용한다.

④ 데이터 모델링 자체로서 업무의 흐름을 설명하고 분석하는 부분에 의미를 가지고 있다.

데이터 모델링을 하는 첫 번째 목적은 업무정보를 구성하는 기초 정보들을 일정한 표현하여 정보시스템 구축의 대상이 되는 업무 내용을 정확하게 분석하는 것이다.
두 번째는 분석된 모델로 실제 데이터베이스를 생성하여 개발 및 데이터관리에 사용하기 위한 것이다.
다시 말하면, 데이터 모델링이라는 것은 단지 데이터베이스만을 구축하기 위한 용도로 쓰이는 것이 아니라 데이터 모델링 자체로도 업무를 설명하고 분석하는 부분에서 매우 중요한 의미가 있다고 할 수 있다.
데이터 모델링이란
- 정보시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
- 현실 세계 데이터(what)를 약속된 표기법으로 표현하는 과정
- 데이터베이스를 구축하기 위한 분석 및 설계의 과정
데이터 모델링의 목적
- 정보에 대한 표기법을 통일하여 업무 내용분석 정확도 증대
- 데이터 모델을 기초로 DB 생성
데이터 모델링의 기능 [가구명문]
- 가시화
- 구조화 된 틀 제공, 구체화
- 명세화
- 문서화
- 다양한 관점 제공

Q. 데이터 모델링을 할 때 유의해야 할 사항으로 가장 적절하지 않은 것은?

③

① 여러 장소의 데이터베이스에 같은 정보를 저장하지 않도록 하여 중복성을 최소화한다.

② 데이터의 정의를 데이터의 사용 프로세스와 분리화여 유연성을 높인다.

③ 사용자가 처리하는 프로세스나 장표 등에 따라 매핑이 될 수 있도록 프로그램과 테이블 간의 연계성을 높인다.

④ 데이터 간의 상호 연관관계를 명확하게 정의하여 일관성 있게 데이터가 유지되도록 한다.

데이터 모델링 유의점
- 중복(Duplication)
  - 유일성: 데이터의 중복 저장 방지
- 비유연성(Inflexibility)
  - 유연성: 데이터의 정의와 데이터 사용 프로세스 분리
- 비일관성(Inconsistency)
  - 일관성: 데이터 간 상호 연관관계 명확하게 정의
데이터 모델링을 할 때 유의할 사항은 중복성, 비유연성, 비일관성 등이다.
- 중복(Duplication)
  - 데이터 모델은 같은 데이터를 사용하는 사람, 시간, 그리고 장소를 파악하는 데 도움을 주어 데이터베이스가 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 한다.
- 비유연성(Inflexibility)
  - 데이터 모델을 어떻게 설계했느냐에 따라 사소한 업무변화에도 데이터 모델이 수시로 변경되어 유지보수의 어려움을 가중시킬 수 있다. 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 모델링은 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터 베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.
- 비일관성(Inconsistency)
  - 데이터 중복이 없더라도 비일관성은 발생할 수 있는데, 예를 들면 신용 상태에 대한 갱신 없이 고객의 납부 이력 정보를 갱신하는 경우이다. 개발자가 서로 연관된 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 수정할 수 있기 때문에 이와 같은 문제가 발생할 수 있다. 데이터 모델링을 할 때 데이터와 데이터 간의 상호 연관 관계에 대해 명확하게 정의한다면 이러한 위험을 사전에 예방하는 데 도움을 줄 수 있다.
  - 사용자가 처리하는 프로세스 혹은 이와 관련된 프로그램과 테이블의 연계성을 높이는 것은 데이터 모델이 업무 변경에 대해 취약하게 만드는 단점에 해당한다.

Q. 아래에서 설명하는 데이터 모델링의 유의점은?

② 비유연성

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

① 중복

② 비유연성

③ 비일관성

④ 일관성

데이터 모델링 시의 유의점에 대한 사항 중 비유연성(Inflexibility)에 대한 설명이다.

Q. 데이터 독립성의 구성요소에 대한 설명으로 가장 적절하지 않은 것은?

③

① 통합된 모든 사용자의 관점은 개념스키마와 관련이 있다.

② 물리적인 저장구조를 표현하는 스키마는 내부스키마이다.

③ View 단계는 여러 사용자 관점으로 구성하는 개념스키마에 해당한다.

④ 논리적인 데이터 독립성을 고려하는 단계는 외부단계와 개념적 단계이다.

여러 사용자 관점으로 구성하는 것은 외부스키마이다.
DB의 3단계 구조: 데이터 독립성 확보를 목표로 함
- DB 독립성의 필요성: 데이터의 중복성과 데이터 복잡동 증가로 인한 ① 유지보수 비용 증가 ② 요구사항 대응 저하
- 3층 스키마(3-level-Schema)
  - 외부 스키마: 각 사용자 단계의 개인적 스키마, 사용자 관점, 응용 프로그램이 접근하는 DB를 정의함
  - 개념 스키마: 조직 전체의 통합된 스키마, 설계자 관점 데이터 모델링의 지향점
  - 내부 스키마: 물리적으로 데이터가 저장되는 방법을 표현하는 스키마, 개발자 관점, 물리적 저장 구조임
- 데이터 독립성
  - 논리적 독립성: 외부 스키마가 개념 스키마의 변화에 무관함, 논리적 사상 없음
  - 물리적 독립성: 개념 스키마가 내부 스키마의 변화에 무관함, 물리적 사상 없음
- Mapping(사상): 상호 독립적인 개념을 연결시켜주는 다리
프로젝트 생명주기(Life Cycle)
- 계획 → 분석 → 설계 → 개발 → 테스트 → 전환/이행 단계로 구성됨
- 계획과 분석 단계는 개념적 모델링
- 분석 단계는 논리적 모델링
- 설계 단계는 물리적 모델링

Q. 아래에서 설명하는 스키마 구조로 가장 적절한 것은?

② 개념스키마(Conceptual Schema)
모든 사용자 관점을 통합한 조직 전체 관점의 통합적 표현
모든 응용시스템들이나 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 DB를 기술한 것으로 DB에 저장되는 데이터와 그들 간의 관계를 표현하는 스키마

① 외부스키마(External Schema)

② 개념스키마(Conceptual Schema)

③ 내부스키마(Internal Schema)

④ 논리스키마(Logical Schema)

데이터베이스 스키마 구조 3단계
- 외부스키마(External Schema)
- 개념스키마(Conceptual Schema)
- 내부스키마(Internal Schema)

Q. 아래 ERD에 대한 설명으로 가장 적절하지 않은 것은?

④ 하나의 주문은 고객이 있을 수도 있고 없을 수도 있다.

① 한 명의 고객은 여러 개의 제품을 주문할 수 있다.(1:다)

② 하나의 주문은 반드시 한 명의 고객에 의해 주문된다.(고객은 필수)

③ 하나의 고객은 주문을 할 수도 있고 안 할 수도 있다.(주문은 선택)

④ 하나의 주문은 고객이 있을 수도 있고 없을 수도 있다.(PK는 NOT NULL)

부모 엔터티에 데이터가 입력될 때 자식 엔터티에 해당 값이 존재하는지의 여부와 상관없이 입력될 수 있는 구조로 표현(선택)되어 있기 때문에, 고객 엔터티에 새로운 고객번호 데이터를 입력하는 것은 주문 엔터티에 해당 고객번호가 존재하고 있는지의 여부와 상관없이 가능하다.
PK는 NOT NULL이므로 고객번호나 제품번호가 없이 주문은 성립될수 없다.
- 가로 구분선 위쪽은 PK이다. 고객의 PK인 고객번호가 주문의 FK로 되어 있다. FK가 구분선 위쪽에 있으면, PK에 포함되면 식별관계 FK가 구분선 아래쪽에 있으면, PK에 포함되지 않으면 비식별관계 고객의 PK 는 (고객번호) 주문의 PK 는 (고객번호, 제품번호)
삼발이 있으므로 1:다 관계이다.(없으면 1:1 관계)
동그라미(○)가 있으므로 선택적 관계이다.(없으면 필수 관계) 주문 쪽에 ○ → 주문이 있을 수도 있고 없을 수도 있다는 의미이다.

데이터 모델링 3요소: 엔터티, 속성, 관계
ERD(Entity Relationship Diagram)
- ① 엔터티는 사각형 ② 관계는 마름모 ③ 속성은 타원형으로 표현, 현실의 데이터 모두 표현 가능
- 작성 순서
  ① 엔터티 도출 - 엔터티를 그린다.
  ② 엔터티 배치 - 엔터티를 적절하게 배치한다.
  ③ 엔터티 간 관계를 설정한다.
  ④ 관계명을 기술한다.
  ⑤ 관계차수 표현 - 관계의 참여도를 기술한다.(1:1, 1:N, M:N)
  ⑥ 관계선택사양 표현 - 관계의 필수여부를 기술한다.(필수, 선택)

Q. ERD에 대한 설명으로 가장 적절하지 않은 것은?

④

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

② 일반적으로 ERD를 작성할 때 엔터티 도출 → 엔터티 배치 → 관계 설정 → 관계명 기술의 흐름으로 작업을 진행한다.

③ 관계의 명칭은 관계 표현에서 매우 중요한 부분에 해당한다.

④ 가장 중요한 엔터티를 오른쪽 상단에 배치하고 추가로 발생되는 엔터티들을 왼쪽 편과 하단에 배치하는 것이 원칙이다.

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

Q. 아래 시나리오에서 엔터티로 가장 적절한 것은?

② 환자
S병원은 여러 명의 환자가 존재하고 각 환자의 이름, 주소 등을 관리해야 한다.(단, 업무범위와 데이터의 특성은 위 시나리오에 기술되어 있는 사항만을 근거하여 판단해야 함)

① 병원

② 환자

③ 이름

④ 주소

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

Q. 엔터티의 특징으로 가장 적절하지 않은 것은?

③

① 속성이 없는 엔터티는 있을 수 없다. 엔터티는 반드시 속성을 가져야한다.

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

③ 객체 지향의 디자인 패턴에는 싱글턴패턴이 있어 하나의 인스턴스를 가지는 클래스가 존재한다. 이와 유사하게 엔터티는 한 개의 인스턴스를 가지는 것만으로도 충분한 의미를 부여할 수 있다.

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

엔터티
- 업무에서 관리해야 하는 데이터의 집합, 명사형, 인스턴스의 집합, 보이지 않는 개념 포함
엔터티의 특징은 다음과 같다.
- 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
  - 환자, 토익의 응시횟수, …
- 유일한 식별자에 의해 식별이 가능해야 한다.
- 영속적으로 존재하는 (두 개 이상의) 인스턴스의 집합이어야 한다.
  - ‘한 개’가 아니라 ‘두 개 이상’
- 엔터티는 업무 프로세스에 의해 이용되어야 한다.
- 엔터티는 반드시 속성이 있어야 한다.
- 엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다.

Q. 엔터티의 일반적인 특징으로 가장 적절하지 않은 것은?

①

① 다른 엔터티와의 관계를 가지지 않는다.

② 유일한 식별자에 의해 식별이 가능해야 한다.

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

④ 엔터티는 반드시 속성을 포함해야 한다.

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

Q. 발생 시점에 따라 구분할 수 있는 엔터티의 유형으로 적절하지 않은 것은?

①

① 관계 엔터티(Relation Entity)

② 행위 엔터티(Active Entity)

③ 중심 엔터티(Main Entity)

④ 기본 엔터티(Fundamental Entity)

엔터티의 발생 시점에 따라 기본 엔터티, 중심 엔터티, 행위 엔터티로 구분할 수 있다.
발생 시점에 따른 엔터티 분류
- 기본, 키 엔터티(Fundamental Entity, Key Entity)
  - 독립적으로 생성되는 엔터티
  - 타 엔터티의 부모 역할, 자신의 고유한 주식별자 가짐
  - 사원,부서
- 중심 엔터티(Main Entity)
  - 기본 엔터티와 행위 엔터티의 중간에 존재하는 엔터티
  - 기본 엔터티로부터 발생, 다른 엔터티와의 관계로 많은 행위 엔터티 생성
  - 계약, 사고, 주문
- 행위 엔터티(Active Entity, 사건 엔터티)
  - 2개 이상의 부모 엔터티로부터 발생함
  - 비지니스 프로세스를 실행하면서 생성되는 엔터티
  - 지속적으로 정보가 추가되고 변경되어 데이터 양이 가장 많음
  - 주문목록, 사원변경이력
유무형에 다른 분류
- 유형 엔터티: 물리적 형태가 있고 지속적으로 활용되는 엔터티
  - 사원, 물품, 강사
- 개념 엔터티: 물리적 형태가 없는 엔터티
  - 조직, 보험상품
- 사건 엔터티: 업무 수행시 발생
  - 주문, 청구, 미납
명명 규칙
- 현업 업무에서 사용하는 용어
- 약어 지양
- 단수 명사
- 유일성 보장
- 명확성

Q. 엔터티에 이름을 부여하는 방법으로 가장 적절하지 않은 것은?

①

① 가능하면 약어를 사용하여 엔터티의 이름을 간결하고 명확하게 한다.

② 현업의 업무 용어를 사용하여 업무상의 의미를 분명하게 한다.

③ 모든 엔터티에서 유일한 이름이 부여되어야 한다.

④ 엔터티가 생성되는 의미대로 자연스럽게 부여하도록 한다.

엔터티를 명명하는 일반적인 기준은 다음과 같다.
- 용어를 사용하는 모든 표기법이 다 그렇듯이 첫 번째는 가능하면 현업 업무에서 사용하는 용어를 사용한다.
- 두 번째는 가능하면 약어를 사용하지 않는다.
- 세 번째는 단수명사를 사용한다.
- 네 번째는 모든 엔터티를 통틀어서 유일하게 이름이 부여되어야 한다.
- 다섯 번째는 엔터티 생성의미대로 이름을 부여한다.

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

② 속성

① 도메인

② 속성

③ 엔터티

④ 관계

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

Q. 속성에 대한 설명으로 가장 적절하지 않은 것은?

③

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

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

③ 하나의 인스턴스에서 각각의 속성은 하나 이상의 속성 값을 가질 수 ~~있다.~~

④ 속성도 집합이다.

속성: 엔터티가 가지는 최소 의미 단위, 인스턴스의 구성요소
하나의 인스턴스에서 각각의 속성은 한 개의 속성값을 가져야 한다.
엔터티, 인스턴스, 속성, 속성값의 관계
- 엔터티와 인스턴스 및 속성과 속성값 간의 관계
- 한 개의 엔터티는 두 개 이상의 인스턴스 집합이어야 한다.
- 한 개의 엔터티는 두 개 이상의 속성을 갖는다.
- 한 개의 속성은 한 개의 속성값을 갖는다.

Q. 아래에서 수행한 정규화 작업으로 가장 적절한 것은? (단, 이후 필요한 정규화 작업은 계속 수행될 예정)

② 2차 정규화

① 1차 정규화

② 2차 정규화

③ 3차 정규화

④ 4차 정규화

1st NF를 만족하고, 모든 Non-key 칼럼은 기본키 전체에 종속되어야 한다.
즉, 기본키에 종속적이지 않거나 기본키 일부 칼럼(들)에만 종속적인 칼럼은 분리되어야 한다.
위 문제는 주문상품 엔터티의 주문상품명은 주문상품 코드에만 종속적이다.

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

① 파생 속성(Derived Attribute)

① 파생 속성(Derived Attribute)

② 기본 속성(Basic Attribute)

③ 설계 속성(Designed Attribute)

④ PK 속성(PK Attribute)

데이터를 조회할 때 성능을 빠르게 하기 위해 원래 속성의 값을 계산하여 저장할 수 있도록 만든 속성을 파생속성(Derived Attribute)이라 한다.
속성
- 정의
  - 엔터티가 가지는 최소 의미 단위, 인스턴스의 구성요소
- 특징
  - 업무에서 필요하고 관리하고자 하는 정보
  - 주식별자에 함수적으로 종속됨
  - 속성값 하나만 가짐(하나 이상의 속성값이면 정규화 필요)
- 표기법
  - IE 표기법, Barker 표기법
- 종류
  - 특성에 따른 분류
    - 기본 속성(Basic Attribute)
      - 비지니스 프로세스에서 도출되는 본래의 속성
    - 설계 속성(Designed Attribute)
      - 데이터 모델링 과정에서 업무 규칙화를 위해 발생하는 속성
      - 일련번호
    - 파생 속성(Derived Attribute)
      - 다른 속성에 의해 만들어지는 속성(↔︎ 저장 속성은 유도 속성을 생성하는 데 사용되는 속성)
      - 합
  - 분해 가능 여부에 따른 분류
    - 단일 속성: 하나의 의미
    - 복합 속성: 여러 의미, 단일 속성으로 분해 가능 Ex, 주소
    - 단일값 속성: 하나의 값
    - 다중값 속성: 여러 값, 엔터티로 분해 가능
  - 엔터티 구성방식에 따른 분류
    - 기본키 속성: 엔터티를 식별할 수 있는 속성
    - 외래키 속성: 다른 엔터티와의 관계에서 포함된 속성
    - 일반 속성: 엔터티에 포함되고 PK나 FK 속성이 아닌 속성
도메인
- 속성이 가질 수 있는 값의 범위

Q. 아래 설명이 나타내는 데이터 모델의 개념으로 가장 적절한 것은?

④ 도메인(Domain)

주문이라는 엔터티가 있을 때 단가라는 속성값의 범위는 100에서 10,000 사이의 실수 값이며 제품명이라는 속성은 길이가 20자리 이내의 문자열로 정의할 수 있다.

① 시스템 카탈로그(System Catalog)

② 용어 사전(Word Dictionary)

③ 속성 사전(Attribute Dictionary)

④ 도메인(Domain)

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

Q. 데이터 모델링을 할 때 속성의 명칭을 부여하는 방법으로 가장 적절하지 않은 것은?

③

① 속성의 이름에 약어를 사용할 경우 그 의미를 명확하게 이해할 수 없고 혼돈을 초래하여 커뮤니케이션의 혼란을 야기할 수 있으므로 지나친 약어 사용은 가급적으로 제한하도록 한다.

② 속성의 이름에는 서술식 용어는 사용하지 않도록 한다.

③ 직원 엔터티 이름, 고객 엔터티 이름과 같이 엔터티별로 동일한 속성명을 사용하여 데이터 모델의 일관성을 유지하는 것이 좋다.

④ 데이터 모델링 대상에서 사용하는 용어도 있고 외부에서 사용하는 용어도 있어 중복이 있을 때, 가급적 해당 업무에서 자주 사용하는 이름을 이용하도록 한다.

속성의 명칭은 애매모호하지 않게, 복합 명사를 사용하여 구체적으로 명명하여 전체 데이터모델에서 유일성을 확보하는 것이 반정규화, 통합 등의 작업을 할 때 혼란을 방지할 수 있는 방법이 된다.
속성의 명칭 부여
- 해당 업무에서 사용하는 이름을 부여한다.
- 서술식 속성명은 사용하지 않는다.
- 약어 사용은 가급적 제한한다.
- 전체 데이터 모델에서 유일성을 확보하는 것이 좋다.
유일성 확보는 이름이라고 생각하면 편하다. 이름은 보통 NAME이라고 한다. 부서와 직원 테이블이 있다면, 아래와 같이 다른 속성명으로 하라는 것이다. 둘 다 NAME으로 하면 나중에 검색하기 힘들므로 동일한 속성명 사용x
- 부서테이블 부서코드 : dept_code 부서명 : dept_name
- 직원테이블 직원코드 : emp_code 직원명 : emp_name

Q. 데이터 모델링의 관계에 대한 설명으로 가장 적절하지 않은 것은?

④

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

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

③ 연관관계는 항상 이용하는 관계로 존재적 관계에 해당하고, 의존관계는 상대방 클래스의 행위에 의해 관계가 형성되는 행위적 관계에 해당한다.

④ 연관관계는 오퍼레이션에서 파라미터 등으로 이용할 수 있고, 의존관계는 소스코드에서 멤버변수로 선언하여 사용할 수 있다.

연관관계는 소스코드에서 멤버변수로 선언하여 사용하게 하고 의존관계는 오퍼레이션에서 파라미터 등으로 이용할 수 있도록 되어 있다.
관계
- 정의: : 엔터티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태로서나 행위로서 서로에게 연관성이 부여된 상태, 동사형
- 관계의 페어링: 엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것
- 관계 표기법: ① 관계명 ② 관계차수 ③ 관계선택사양
  - 관계차수(Cardinality): 관계 내 튜플의 전체 개수, 1은 직선, 多는 삼발로 표시
    - M:N 관계 - 관계형 DB에서 M:N 관계의 조인은 카테시안 곱 발생
  - 관계선택사양(Optionality): 필수는 | 선택은 ○로 표시
- 종류
  - ERD 기준: 표기구분 안함
    - 존재 관계: 엔터티 간의 상태
    - 행위 관계: 엔터티 간에 발생하는 행위
  - UML(Unified Modeling Language) 기준
    - 연관 관계(Association): 실선 표기
    - 의존 관계(Dependency): 점선 표기
  - 식별자에 따른 분류
    - 식별 관계: 부모 엔터티의 식별자를 자식 엔터티에서 주식별자로 사용, 강한 연결관계 표현
      - 약한 엔터티: 부모 엔터티에 종속되어 존재(↔︎ 강한 엔터티는 독립적으로 존재함)
      - 식별 관계만으로 연결되면 주식별자 수가 많아질 수밖에 없으므로 ① 관계 강약 분석 ② 자식 엔터티의 독립 PK 필요성 ③ SQL 복잡성과 개발 생산성 고려 필요
    - 비식별 관계: 부모 엔터티의 식별자를 자식 엔터티에서 일반 컬럼으로 참조 사용, 약한 종속관계, 약한 연결관계 표현

Q. 데이터 모델링의 관계에 대한 설명으로 가장 적절하지 않은 것은?

②

① 관계는 존재적 관계와 행위에 의한 관계로 나누어볼 수 있다.

② 관계의 표기법은 관계명, 관계차수, 식별성의 3가지 개념을 사용한다.

③ 부서와 사원 엔터티 간의 ‘소속’ 관계는 존재적 관계의 사례이다.

④ 주문과 배송 엔터티 간의 ‘배송근거’ 관계는 행위에 의한 관계의 사례이다.

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

Q. 아래에서 설명하는 데이터 독립성은?

② 물리적 독립성
데이터베이스의 파일 구조의 변화가 논리스키마(Schema)에 영향을 주지 않음
데이터베이스의 색인 구조의 변화가 응용 프로그램에 영향을 주지 않음

① 논리적 독립성

② 물리적 독립성

③ 개념적 독립성

④ 내부적 독립성

물리적 독립성은 물리 스키마가 변경되어도 논리 스키마에 영향을 주지 않는다.
물리적 독립성은 파일 저장구조의 변경이 논리 스키마와 응용프로그램에 영향을 주지 않는다.

Q. 1:1, 1:M과 같이 두 엔터티 간의 관계에서 참여자의 수를 나타내는 것은?

② 관계차수(Relationship Degree/Cardinality)

① 관계명(Relationship Membership)

② 관계차수(Relationship Degree/Cardinality)

③ 관계선택사양(Relationship Optionality)

④ 관계정의(Relationship Definition)

관계의 기수성을 나타내는 개념은 관계차수에 해당한다.
관계의 표기법
- 관계명(Membership)
  - 관계의 이름
- 관계차수(Cardinality)
  - 1:1, 1:M, M:N
- 관계선택사양(Optionality)
  - 필수관계, 선택관계
관계 읽기
- 각각의/하나의 → 기준 엔터티 → 관계차수 → 대상 엔터티 → 관계선택사양 → 관계명
- 하나의 부서는 여러 명의 사원을 가질 수 있다.

Q. 두 개의 엔터티 사이에 정의한 관계에 대해 확인해야 할 사항으로 가장 적절하지 않은 것은?

③

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

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

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

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

‘업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?’ 가 되어야 한다.
동사는 관계를 서술하는 업무기술서의 가장 중요한 사항이다.

Q. 두 개의 엔터티 사이에서 관계를 도출할 때 확인해야 할 사항을 모두 고른 것은?

(가), (나), (다), (라)

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

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

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

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

4개의 항목 모두 관계를 정의할 때 점검해야 할 항목이다.

Q. 주식별자를 지정할 때 고려해야 할 사항을 모두 고른 것은?

(가), (나), (다), (라)

(가) 주식별자에 의해 엔터티 내의 모든 인스턴스들이 유일하게 구분되어야 한다.

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

(다) 지정된 주식별자의 값은 자주 변하지 않는 것이어야 한다.

(라) 주식별자가 지정이 되면 반드시 값이 들어와야 한다.

주식별자도 변할 수 있다. 특히 본질식별자를 주식별자로 사용할 때이다. 개인의 경우 주민등록번호를 개인을 구분하는 식별자로 많이 사용하고, 사업자의 경우 사업자등록번호를 주식별자로 많이 사용하는데, 주민등록번호와 사업자등록번호는 변경 가능하다. 이러한 변경 사항에 유연하게 대처하기 위하여 인조식별자를 사용한다.

Q. 아래에서 사원 엔터티의 특성에 해당하지 않는 것은?

④ 인조식별자

① 주식별자

② 단일식별자

③ 내부식별자

④ 인조식별자

사번은 업무적으로 의미 있는 식별자로 시스템적으로 부여된 인조식별자가 아니라 일반적으로 사원 인스턴스의 탄생과 함께 업무적으로 부여되는 사원 인스턴스의 본질적인 속성에 해당한다 할 수 있기 때문에 본질식별자로 볼 수있다.
식별자의 종류
- 엔터티 내에서 대표성을 가지는가에 따라 주식별자(Primary Identifier)와 보조식별자(Alternate Identifier)로 구분
- 엔터티 내에서 스스로 생성되었는지 여부에 따라 내부식별자와 외부식별자(Foreign Identifier)로 구분
- 단일 속성으로 식별이 되는가에 따라 단일식별자(Single Identifier)와 복합식별자(Composite Identifier)로 구분
- 원래 업무적으로 의미가 있던 식별자 속성을 대체하여 일련번호와 같이 새롭게 만든 식별자를 구분하기 위해 본질식별자와 인조식별자로 구분

Q. 식별자로 가장 적절하지 않은 것은?

②

명칭, 내역 등과 같이 이름으로 기술되는 것들은 주식별자로 지정하기에 적절하지 않다. 특히 사람의 이름은 동명이인이 있을 수 있기 대문에 주식별자로서 더더욱 부적절하다.
주식별자 도출기준
- 해당 업무에서 자주 이용되는 속성
- 명칭,내역 등과 같이 이름으로 기술되는 것들은 명명 지양
- 복합 식별자 지양(너무 많은 속성x)

Q. 주식별자의 특징과 그에 대한 설명으로 가장 적절하지 않은 것은?

②

① 유일성: 주식별자에 의해 엔터티 내의 모든 인스턴스들은 유일하게 구분된다.

② 존재성: 주식별자는 데이터 값이 없을 수 있다.(NULL 존재 가능)

③ 불변성: 주식별자가 한번 특정 엔터티에 지정되면 그 식별자의 값은 변하지 않아야 한다.

④ 최소성: 주식별자가 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.

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

Q. 데이터 모델링에서 비식별자 관계로 연결하는 경우로 가장 적절하지 않은 것은?

③

① 엔터티와 엔터티가 1:M 관계의 부모와 자식관계에서 데이터가 부모 없이 자식쪽 엔터티의 인스턴스가 먼저 생성될 수 있을 경우 비식별자 관계로 연결해야 한다.

② 부모 엔터티의 인스턴스가 자식 엔터티의 인스턴스보다 먼저 소멸하는 경우 비식별자 관계로 연결해야 한다.

③ SQL 문의 조인 관계를 최소화 하는 경우 비식별자 관계로 연결해야 한다.

④ 자식 엔터티의 식별자가 부모 엔터티의 주식별자를 상속받아 생성하는 것보다 별도의 주식별자를 생성하는 것이 더 유리하다고 판단되는 경우 비식별자 관계로 연결해야 한다.

③ SQL 문의 조인관계를 최소화하기 위해 식별자 관계로 연결해야 한다.

조회 패턴을 보면 고작 점검번호=301 정도의 단순하게 걸리는 이 하나의 조회 조건도 비식별자관계로만 데이터 모델링을 전개하다 보면 SQL 구문에 많은 조인이 걸리게 되고 그에 따라 복잡성이 증가하고 성능이 저하되게 되는 것이다. 오른쪽과 같이 식별자관계를 통해 연결하다보면, 부모의 모든 주식별자 속성을 상속받음으로 인해 맨 하위에 있는 자식엔터티에서 바로 조회의 조건을 이용하여 원하는 정보를 가져올 수 있다. 이 경우는 당연히 성능과 개발 용이성 측면에서는 식별자관계가 우위에 있음을 보여준다.

식별자관계와 비식별자관계 모델링 - 비식별자관계 선택 프로세스 기본적으로 식별자관계로 모든 관계가 연결되면서 다음 조건에 해당할 경우 비식별자관계로 조정하면 된다.

식별자로만 하면 SQL 구문이 복잡해지는 단점이 있고, 비식별자로만 하게 될 경우 조인이 많아져 그에 따라 복잡성이 증가하고 성능이 저하되게 된다.
식별자로 연결하면 주식별자에 종속이 되므로 조인할 항목이 하나 줄어드는 것과 같다고 생각하면 된다.

  식별자 관계
  주식별자: 자식의 주식별자로 부모의 주식별자 상속 
  1. 부모로부터 받은 식별자를 자식엔터티의 주식별자로 이용하는 경우
  강한 연결관계 표현, 실선 표기
        
  비식별자: 부모 속성을 자식의 일반 속성으로 사용 
  1. 부모 없는 자식이 생성될 수 있는 경우
  2. 부모와 자식의 생명주기가 다른 경우
  3. 여러 개의 엔터티가 하나의 엔터티로 통합되어 표현 되었는데 각각의 엔터티가 별도의 관계를 가진 경우 
  4. 자식엔터티에 별도의 주식별자를 생성하는 것이 더 유리한 경우
  5. SQL 문장이 길어져 복잡성 증가되는 것 방지
  약한 연결관계 표현, 점선 표기

식별자와 비식별자 관계 비교
- 식별자 관계
  - 목적
    - 강한 연결관계 표현
  - 자식 주식별자 영향
    - 자식 주식별자의 구성에 포함됨
  - 표기법
    - 실선 표현
  - 연결 고려사항
    - 반드시 부모 엔터티에 종속
    - 자식 주식별자 구성에 부모 주식별자 포함 필요
    - 상속받은 주식별자 속성을 타엔터티에 이전 필요
- 비식별자 관계
  - 목적
    - 약한 연결관계 표현
  - 자식 주식별자 영향
    - 자식 일반 속성에 포함됨
  - 표기법
    - 점선 표현
  - 연결 고려사항
    - 약한 종속관계
    - 자식 주식별자 구성을 독립적으로 구성
    - 자식 주식별자 구성에 부모 주식별자 부분 필요
    - 상속받은 주식별자 속성을 타 엔터티에 차단 필요
    - 부모쪽의 관계참여가 선택관계

① 엔터티와 엔터티가 1:M 관계의 부모와 자식관계에서 데이터가 부모 없이 자식쪽 엔터티의 인스턴스가 먼저 생성될 수 있을 경우 비식별자 관계로 연결해야 한다. → 부모 없이 자식 쪽에 엔터티스가 먼저 생성될 수 있나요?

부모 없는 자식
- 자식 엔터티의 부모 항목이 널 가능이면 널값으로 부모 없는 자식 생성 가능
- 식별자는 NOT NULL 이므로 비식별자여야 NULL 가능

② 부모 엔터티의 인스턴스가 자식 엔터티의 인스턴스보다 먼저 소멸하는 경우 비식별자 관계로 연결해야 한다. → 어떤 엔터티 간에 먼저 소멸한다는데 무슨 말이죠?

부모 먼저 삭제
- 자식이 없어야만 부모 삭제가 가능한데 ①번과 마찬가지로 자식 쪽에 널이 가능하면 자식 삭제 없이 널로만 업데이트 하면 부모 삭제 가능
- 식별자는 NOT NULL이므로 비식별자여야 NULL 가능
상속받은 주식별자 속성을 타엔터티에 이전 필요 → 왜 이전이 필요하죠?
상속받은 주식별자 속성을 타 엔터티에 차단 필요 → 차단이 왜 필요하죠?
왜 이전이 필요한가? 가 아니라
- 이전이 필요하면 식별관계
- 이전이 필요 없으면 비식별관계
- 필요성은 업무적인 관점에서 프로세스를 분석하고 결정을 내리는 것이다.

Q. 아래 식별자에 대한 설명이 올바르게 짝지어진 것은?

주식별자, 보조식별자, 본질식별자, 외부식별자

(가) 대표성을 가지며, 엔터티 내의 여러 인스턴스 중 하나를 유일하게 구분할 수 있는 식별자

(나) 엔터티 내의 여러 인스턴스 중 하나를 유일하게 구분할 수 있으나, 대표성을 가지지 못하는 식별자

(다) 엔터티 내의 집합을 명확하게 설명할 수 있는 업무적으로 의미가 부여된 식별자

(라) 다른 엔터티로부터 상속되어 정의된 식별자

식별자는 대표성 여부에 따라 주식별자와 보조식별자, 스스로 생성 여부에 따라 내부식별자와 외부식별자, 속성의 수의 따라 단일식별자, 복합식별자, 대체여부에 따라 본질식별자, 인조식별자로 구분된다.
식별자
- 정의: 엔터티를 대표할 수 있는 유일성을 만족하는 속성
- 특징: ① 유일성 ② 최소성 ③ 불변성 ④ 존재성
- 종류
  - 대표성 여부
    - 주식별자
      - 대표성을 만족하는 식별자
      - 엔터티 내에서 각 어커런스를 구분할 수 있는 구분자이며, 타 엔터티와 참조관계를 연결할 수 있는 식별자
    - 보조식별자
      - 유일성과 최소성만 만족하는 식별자
      - 엔터티 내에서 각 어커런스를 구분할 수 있는 구분자이나 대표성을 가지지 못해 참조관계 연결을 못함
      ※ DB 키의 종류
      - 기본키(PK; Primary Key): 엔터티를 대표하는 키, 후보키 중 선정됨
      - 후보키: 유일성과 최소성을 만족하는 키
      - 슈퍼키: 유일성만 만족하는 키
      - 대체키: 기본키를 제외한 나머지 후보키
      - 외래키(FK; Foreign Key): 여러 테이블의 기본 키 필드, 참조 무결성(Referential Integrity)을 확인하기 위해 사용됨(허용된 데이터 값만 저장하기 위함)
      - 식별자는 논리 데이터 모델링 단계에 사용 Key는 물리 데이터 모델링 단계에 사용
  - 스스로 생성여부
    - 내부식별자
      - 엔터티 내부에서 스스로 만들어지는 식별자
      - 자연스럽게 존재하는 식별자(~ 본질식별자)
    - 외부식별자
      - 타 엔터티와의 관계를 통해 타 엔터티로부터 받아오는 식별자
  - 속성의 수
    - 단일식별자
      - 하나의 속성으로 구성된 식별자
    - 복합식별자
      - 둘 이상의 속성으로 구성된 식별자
  - 대체여부
    - 본질식별자
      - 업무에 의해 만들어지는 식별자
      - 대체될 수 없는 식별자
    - 인조식별자
      - 업무적으로 만들어지지는 않지만 원조식별자가 복잡한 구성을 가지고 있기 때문에 인위적으로 만들어진 식별자
      - 인위적으로 만들어지는 대체가능한 식별자 (순서번호(Sequence Number)를 사용하여 생성된 식별자), ① 후보 식별자 중 주식별자로 선정할 것이 없거나 ② 주식별자가 너무 많은 칼럼으로 구성되어 있을 때 사용
엔터티 어커런스(Occurrence) : 정의된 레코드의 구조에 따라 데이터베이스에 구체적이고 실제적인 정보를 저장하고 있는 데이터 레코드, RDBMS에서는 튜플을 의미한다. 쉽게 말해 각 엔터티의 인스턴스의 각각의 데이터를 뜻한다.

Q. 속성이 가질 수 있는 값의 범위를 지칭하는 용어는?

② 도메인

① 제약 사항

② 도메인

③ 데이터 타입

④ 데이터 크기

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

Q. 아래 빈칸 ㉠, ㉡, ㉢에 해당하는 것은?

기본 속성, 설계 속성, 파생 속성

업무분석을 통해 바로 정의한 속성을 ㉠, 원래 업무상 존재하지는 않지만 설계를 하면서 도출해 내는 속성을 ㉡, 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성을 ㉢이라고 한다.

업무분석을 통해 바로 정의한 속성을 기본속성(Basic Attribute), 원래 업무상 존재하지는 않지만 설계를 하면서 도출해 내는 속성을 설계속성(Designed Attribute), 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성을 파생속성(Derived Attribute)이라고 한다.
일반속성은 엔터티 구성방식에 따른 분류 속성으로 엔터티에 포함되어 있고 PK, FK에 포함되지 않은 속성이다.
속성의 종류
- 특성에 따른 분류
  - 기본 속성(Basic Attribute)
    - 비지니스 프로세스에서 도출되는 본래의 속성
  - 설계 속성(Designed Attribute)
    - 데이터 모델링 과정에서 업무 규칙화를 위해 발생하는 속성
    - 일련번호
  - 파생 속성(Derived Attribute)
    - 다른 속성에 의해 만들어지는 속성(↔︎ 저장 속성은 유도 속성을 생성하는 데 사용되는 속성)
    - 합
- 분해 가능 여부에 따른 분류
  - 단일 속성: 하나의 의미
  - 복합 속성: 여러 의미, 단일 속성으로 분해 가능 Ex, 주소
  - 단일값 속성: 하나의 값
  - 다중값 속성: 여러 값, 엔터티로 분해 가능
- 엔터티 구성방식에 따른 분류
  - 기본키 속성: 엔터티를 식별할 수 있는 속성
  - 외래키 속성: 다른 엔터티와의 관계에서 포함된 속성
  - 일반 속성: 엔터티에 포함되고 PK나 FK 속성이 아닌 속성

제2장 데이터 모델과 SQL

제1절 정규화

제2절 관계와 조인의 이해

제3절 모델이 표현하는 트랜잭션의 이해

제4절 NULL 속성의 이해

제5절 본질식별자 vs. 인조식별자

Q. 속성(a, b, c, d, e)로 구성된 릴레이션에서 아래와 같은 함수 종속성(Functional Dependency)이 존재할 때, 이 릴레이션의 후보 키로 가장 적절하지 않은 것은?

③ ac

ab → cde, e → b, d → ab

① d

② ab

③ ac

④ ae

함수적종속성: 데이터들이 어떤 기준 값에 의해 종속되는 현상
기본적으로 데이터는 속성 간의 함수종속성에 근거하여 정규화되어야 한다. 정규화는 선택이 아니라 필수사항
ab는 자신인 ab와 cde를 결정하므로 모든 속성을 결정한다. 따라서 후보 키가 된다.
e → b 양쪽에 a를 추가하면 ae → ab 이고 ab → cde 이므로 ae → cde
ae는 모든 속성을 결정한다. 따라서 후보 키가 된다.
d → ab이고, ab → cde이므로 d → cde이다. d는 모든 속성을 결정한다. 따라서 후보 키가 된다.

d는 ab를 대표하는데 ab는 cde를 대표하므로, d는 전체를 대표한다. (d -> ab)
ab는 cde를 대표하므로 pass (ab -> cde)
ac는 어떠한 값도 대표하지 못한다. (ac -> 종속성 없음)
e는 b를 대표하므로, ae는 ab를 대표한다. ab는 cde를 대표하므로, ae는 전체를 대표한다. (ae -> ab -> cde)

식별자 후보키 함수종속성
- d - ab(or ae) - cde 의 릴레이션이므로 ac는 등장하지도 않고 시작점도 될 수 없다. 왜 ab or ae 인가? e가 b로 종속되므로 ab는 ae로도 가능하다.
- 간단하게 화살표 왼편이 오른편의 대표자인 속성이므로 왼편에 온적이 없는 c는 후보키가 될 수 없다.
후보키란 테이블의 각 행을 유일하게 식별할 수 있는 최소한의 속성들의 집합을 말한다. 후보키는 기본키가 될 수 있는 후보들이며 유일성과 최소성을 동시에 만족해야 한다.

Q. 아래 주문상세 엔터티의 주식별자가 (주문번호, 상품번호)일 때, 이 엔터티가 만족하지 않는 정규형은?

제2정규형

[주문상세]

주문번호	상품번호	상품명
10001	901	DB 전문가 가이드
10001	876	딥러닝 전문가 가이드
10002	901	DB 전문가 가이드
10003	901	DB 전문가 가이드
10004	876	딥러닝 전문가 가이드

제2정규형에서 엔터티의 일반 속성은 주식별자에 함수 종속이다. 주문상세 엔터티(entity)의 주식별자는 (주문번호, 상품번호)이지만, 상품번호 → 상품명의 함수 종속관계가 존재하므로, 제2정규형에 맞지 않는다.
정규형
- 제1정규형 : 모든 속성은 반드시 하나의 값을 가져야 한다.
- 제2정규형: 엔터티의 일반속성은 주식별자 전체에 종속이어야 한다.
- 제3정규형: 엔터티의 일반속성 간에는 서로 종속적이지 않다.

Q. 아래 엔터티에 필요한 정규화와 분리된 스키마 구조로 가장 적절한 것은?

③

함수종속성(FD) :

{관서번호, 납부자번호} → {직급명, 통신번호}

{관서번호} → {관리점번호, 관서명, 상태, 관서등록일자}

① 2차 정규화- 정규화테이블{관서번호, 납부자번호, 관리점번호, 관서명, 상태, 관서등록일자}

② 3차 정규화 - 정규화테이블{관서번호, 납부자번호, 관리점번호, 관서명, 상태, 관서등록일자}

③ 2차 정규화 - 정규화테이블{관서번호, 관리점번호, 관서명, 상태, 관서 등록일자}

④ 3차 정규화 - 정규화테이블{관서번호, 관리점번호, 관서명, 상태, 관서 등록일자}

함수 종속성의 규칙에 따라 {관서번호} → {관리점번호, 관서명, 상태, 관서등록일자}인 관서번호가 PK인 엔터티가 2차 정규화로 분리되어야 한다.

Q. 정규화의 성능에 대한 설명으로 가장 적절하지 않은 것은?

④

① 정규화를 수행하면 중복 속성을 제거하여 용량을 최소화시킬 수 있다.

② 일반적으로 정규화 수행 시 데이터처리 성능이 향상된다.

③ 반정규화가 조회 성능을 향상 향상시키는 것은 아니며, 때로는 정규화에 의해 성능이 향상될 수도 있다.

④ 정규화를 수행하면 조회 성능을 보장받을 수 있다.

정규화로 인해 조회성능이 저하될 수 있다. 이 때문에 반정규화를 고려한다.

Q. 아래와 같이 전제조건이 있을 때 테이블에서 나타날 수 있는 현상으로 가장 적절한 것은?

④

전제조건: 유형기능분류코드에 해당하는 속성들은 분포도가 양호하며, SQL Where절에서 각각의 값이 상수 값으로 조건 입력될 수 있는 특징을 가진다.

① 조회 조건이 유형기능분류코드에 따라 반복되는 그룹이 칼럼단위로 되어 있으므로 ~~제1정규형~~이라고 할 수 있다.

② 유형기능분류코드에 대해 where절에 조건으로 들어오는 값이 있으므로 PK와 이에 대한 인덱스만 있으면 SQL 문장은 빠르게 수행될 수 있다고 할 수 있다.

③ 유형기능분류코드가 일반속성 안에서 반복적으로 속성이 구분되어 있기 때문에 이전종속을 수행해야 하는 ~~제2정규형~~이라고 할 수 있다.

④ 조회 성능을 위해 각각에 대하여 개별로 인덱스를 모두 생성할 경우 입력, 수정, 삭제 때 성능이 저하되므로 제1차 정규화를 수행한 후 인덱스를 적용하는 것이 좋다.

칼럼에 의한 반복적인 속성값을 갖는 형태는 속성의 원자성을 위배한 1차 정규화의 대상이 된다.
이와 같은 반복적인 속성 나열 형태에서는 각 속성에 대해 ‘or’ 연산자로 연결된 조건들이 사용되는데, 이때 어느 하나의 속성이라도 인덱스가 정의되지 않으면 ‘or’로 연결된 모든 조건절들이 인덱스를 사용하지 않고 한 번의 전체 데이터 스캔으로 처리되게 되어 성능 저하가 나타날 수 있다.
또한 모든 반복 속성에 인덱스를 생성하면 검색 속도는 좋아지겠지만 반대로 너무 많은 인덱스 때문에 입력, 수정, 삭제의 성능이 저하되므로, 1차 정규화로 자연스럽게 문제가 해결될 수 있도록 해야 한다.
④ 제1정규화 조건이 PK, 원자성인데 보기는 칼럼 여러 개가 반복되어서 제1정규화 실행해야 하는 대상이다.
② 지문 자체는 말이 될 수 있으나(유형코드조건으로 상수값 검색 시 인덱스만 있으면 빠르게 조회됨) 운영상 또 하나의 유형코드가 추가되면 인덱스를 또 추가해야 하는 문제가 발생된다. 결국 전체 시스템 가용량의 문제가 된다. 즉, PK + 유형코드 1~9까지 총 9개의 인덱스를 비효율적으로 생성할 수 있다. 인덱스 구성에 대한 설명이 없으므로 결과적으로 SQL 문장이 빠르게 수행할 수 있다고 확실히 장담할 수 있는 내용은 없다.
③ 반복 속성의 제거가 되어야 제1정규형이 되므로 제2정규형을 언급하는 것은 틀린 내용이다.
제1정규화 → 모델 테이블, 모델 기능 테이블(모델명, 기능분류코드), 기능테이블(기능코드, 기능명) 이렇게 3개의 테이블이 나올 수 있으며, 모델 테이블 1:N 모델 기능 테이블, 모델 기능 테이블 1:1 기능 테이블의 관계차수를 가질 수 있다.
제1정규화와 관련된 문제는 칼럼 이름 자체가 반복되는 형식

Q. 아래 논리 데이터 모델을 3차 정규화까지 수행했을 때 도출되는 엔터티 수로 가장 적절한 것은? (하나의 대출자에 대해 하나의 대출번호로 여러 개의 도서 대출/반납을 관리하고자 한다고 가정하고, 엔터티 통합은 고려하지 않음)

7

3차 정규화까지 수행하면 학과, 학생, 교수, LAB실이용신청, (도서)대출, 대출도서, 도서 이렇게 총 7개의 엔터티가 도출된다.
- 학생과 관련 없는 엔터티 분리 및 관계 설정
  1. 학과 엔터티
    - 학생과 학과는 분리하는 것이 좋다.
    - 학과 정보는 학과 엔터티로 분리하고, 학과 번호는 학생 테이블에 남겨 학과와의 관계를 유지한다.
  2. 랩실 이용 현황 엔터티
    - 랩실 이용 현황은 학생의 학번을 통해 연결된다.
    - 그러나 학번만으로는 PK가 될 수 없으므로, 이용 번호나 이용 아이디와 같은 인조식별자를 생성한다.
    - 교수 번호도 남겨 누가 승인했는지 기록하며, 교수에 대한 상세 정보는 교수 테이블에서 가져온다.
  3. 도서 대출 엔터티
    - 대출자에 대한 정보를 따로 대출자 엔터티로 분리하고, 대출자 번호를 도서 대출 엔터티에 남긴다.
    - 도서 대출 엔터티에는 도서 번호도 남겨 도서와의 관계를 유지한다.
  4. 관계 설정
    - 학생 엔터티와 학과 엔터티는 학과 번호로 연결된다.
    - 랩실 이용 현황 엔터티는 학번과 교수 번호로 연결된다.
    - 도서 대출 엔터티는 대출자 번호와 도서 번호로 연결된다.
- 최종 엔터티 구조
  1. 학생 엔터티
    - 학번
    - 성명
    - 학과 번호 (학과와의 관계)
  2. 학과 엔터티
    - 학과 번호 (PK)
    - 학과 명
  3. 랩실 이용 현황 엔터티
    - 이용 번호 (PK, 인조식별자)
    - 학번 (학생과의 관계)
    - 교수 번호
    - 기타 이용 정보
  4. 교수 엔터티
    - 교수 번호 (PK)
    - 교수 명
  5. 도서 대출 엔터티
    - 대출 번호 (PK)
    - 대출자 번호 (대출자와의 관계)
    - 도서 번호 (도서와의 관계)
    - 반납일자
  6. 대출자 엔터티
    - 대출자 번호 (PK)
    - 대출자명
    - 대출자 신분 구분
  7. 도서 엔터티
    - 도서 번호 (PK)
    - 도서명
    - 기타 도서 정보
- 관계 설정과 키 상속
  - 관계는 데이터베이스 설계에서 엔터티 간의 연결을 정의하는 중요한 개념이다. 관계를 설정하는 과정에서 키를 상속하여 연결 고리를 만든다. 이를 통해 엔터티 간의 관계를 명확히 하고 데이터의 무결성을 유지할 수 있다.
  - 키 상속
    - 관계를 설정할 때, 한 엔터티의 기본 키(Primary Key)를 다른 엔터티에 상속시켜 외래 키(Foreign Key)로 사용한다.
    - 이 외래 키를 통해 두 엔터티 간의 관계를 명확히 정의할 수 있다.
    - 예: 학생 엔터티의 학과 번호를 학과 엔터티에 상속시켜 두 엔터티를 연결한다.

제1정규형 : 모든 속성은 반드시 하나의 값(Single Value)을 가져야 한다. 즉, 반복형태가 있어서는 안 된다.
- 반복되는 형태 존재 여부 확인, 반복되는 속성 분리
  - 학생 - LAB실이용시작일 ~ LAB실이용승인교수명 속성이 1~4로 부여되어 반복되는 형태
    - 만약, 5 이상이 더 필요하다면 엔터티의 속성을 또 만들어야 한다.
    - 이름으로 조회가 자주되어 이름 속성에 인덱스를 부여해야 한다면? 현재는 4개. 업무 변경에 따른 이름속성에 계속 인덱스를 추가해주어야 한다.
  - 도서대출 - 한 번의 대출에 여러 도서를 빌릴 수 있으므로 대출도서번호 ~ ISBN는 반복되어 나타나는 속성들이다.
- 제1정규화를 수행 시 1:M의 자식 테이블이 만들어진다.(학생과 LAB실이용, 대출과 대출도서) 기존 도서대출 엔터티명을 대출로 변경하고, 신규로 대출도서라는 엔터티를 생성하였다.

제2정규형 : 식별자가 아닌 모든 속성들은 식별자 전체 속성에 완전 종속되어야 한다.
- 보기는 식별자가 각각 1개이므로(학생 엔터티의 학번, 도서대출의 대출번호 - 인조식별자) 제2정규형에 위배되는 사항은 없다.(식별자에 모두 종속)
- 제1정규형 대출도서 엔터티의 식별자는 대출번호, 대출도서번호로 일반속성인 대출도서명 ~ ISBN은 대출도서번호에 부분 종속되어 있다.
- 제2정규화 수행 시 해당 엔터티의 부모 엔터티가 도출된다. 부모엔터티(도서)가 있어야만 자식엔터티(대출도서)를 만들 수 있다. - 대출도서번호가 PK로 사용되기 때문

제3정규형 : 식별자를 제외한 나머지 속성들 간의 종속이 존재하면 안된다.
- 학생 엔터티의 학과번호와 학과명은 종속관계이다.
- 도서대출 엔터티의 대출자번호와 대출자명은 종속관계이다. 대출자번호는 학생 엔터티의 학번을 의미한다. 대출자명은 학생 엔터티의 성명과 동일하여 대출자명 속성은 불필요한 중복 속성이다.
- LAB실이용 엔터티의 LAB실이용승인교수번호와 LAB실이용승인교수명은 종속관계이다. 이를 분리해내면 다음과 같다.
- 제3정규화 수행 시 해당 엔터티의 참조엔터티가 생성된다. 학생 엔터티는 학과번호가 없어도 생성이 될 수 있다. 그래서 참조엔터티라 명한다.

Q. 아래에서 빈칸 ㉠, ㉡에 들어갈 용어로 가장 적절한 것은?

제2정규형, 제3정규형

어떤 릴레이션 R이 ㉠이고, 기본키에 속하지 않은 속성 모두가 기본키에 이행적 함수종속이 아닐 때 ㉡에 속한다.

어떤 릴레이션 R이 제2정규형이고, 기본 키에 속하지 않은 속성 모두가 기본 키에 이행적 함수 종속이 아닐 때 제3정규형에 속한다.

Q. 데이터 모델링의 정규화에 대한 설명으로 가장 적절하지 않은 것은?

①

① 정규화는 개념 데이터 모델의 일관성을 확보하고 중복을 제거하여 속성들이 가장 적절한 엔터티에 배치되도록 한다.

② 제1정규형은 모든 인스턴스가 반드시 하나의 값을 가져야 함을 의미한다.

③ 제3정규형을 만족하는 엔터티의 일반속성은 주식별자 전체에 종속적이다.

④ 반정규화는 성능을 위해 데이터 중복을 허용하는 것이지만 성능의 향상을 항상 보장하는 것은 아니다.

정규화는 논리 데이터 모델 상세화 과정의 대표적인 활동으로, 논리 데이터 모델의 일관성을 확보하고 중복을 제거하여 속성들이 가장 적절한 엔터티에 배치되도록 함으로써 보다 더 신뢰성 있는 데이터구조를 얻는 데 목적이 있다.
② 모든 인스턴스는 반드시 하나의 값을 가질 필요는 없다. 다만, 문제에 제공된 제1정규형의 경우 모든 속성값은 원자값(하나의 값)으로 이루어져 있어야 하고, 이는 곧 모든 속성에 하나의 값이 들어갔다는 것을 의미한다. 이는 곧 모든 인스턴스가 하나의 값은 가지고 있다는 의미이다.
보통 인스턴스라고 표현하는 것은 테이블 ROW를 의미하는데 인스턴스가 아니라 속성으로 표현해야 맞는 표현 같다. NULL 값도 허용되기 때문에, 모든 인스턴스가 반드시 하나의 값을 가질 필요는 없다.
③ 제3정규형을 만족하려면 제2정규형이 만족된 상태여야 하기 때문에 옳은 설명이다.(제3정규형은 제2정규형의 부분집합으로 제2정규형도 만족하기 때문이다.)
설계는 개논물! 스키마는 외개내!
- 데이터 모델 설계
  - 요구조건 분석 → 개념적 설계 → 논리적 설계 → 물리적 설계 → 구현
- 스키마
  - 외부스키마 → 개념 스키마 → 내부 스키마

Q. 관계(Relationship)와 조인(Join)에 대한 설명으로 가장 적절하지 않은 것은?

②

① 조인(Join)이란 식별자를 상속하고, 상속된 속성을 매핑키로 활용하여 데이터를 결합하는 것을 의미한다.

② 부모의 식별자를 자식의 일반속성으로 상속하면 식별 관계, 부모의 식별자를 자식의 식별자에 포함하면 비식별 관계라고 할 수 있다.

③ 관계(Relationship)를 맺는다는 것은 식별자를 상속시키고 해당 식별자를 매핑키로 활용해 데이터를 결합해 보겠다는 것을 의미한다.

④ “SELECT B.고객명 FROM 주문 A, 고객 B WHERE A.고객번호 = B.고객번호” 쿼리에서 조인키(Join Key)는 “고객번호”이다.

부모의 식별자를 자식의 식별자에 포함하면 식별관계, 부모의 식별자를 자식의 일반속성으로 상속하면 비식별관계라고 할 수 있다.
SQL 문의 조인관계를 최소화하기 위해 식별자 관계로 연결해야 한다.
식별자로만 하면 SQL 구문이 복잡해지는 단점이 있고, 비식별자로만 하게 될 경우 조인이 많아져 그에 따라 복잡성이 증가하고 성능이 저하되게 된다.
식별자로 연결하면 주식별자에 종속이 되므로 조인할 항목이 하나 줄어드는 것과 같다고 생각하면 된다.

Q. 아래에서 설명하는 정규형으로 가장 적절한 것은?

제2정규형

엔터티의 일반속성은 주식별자 전체에 종속적이어야 한다.

Q. 아래와 같이 수강지도 엔터티를 만들었을 때 이에 해당하는 정규형과 정규화의 대상으로 가장 적절한 것은?

①

① 1차 정규형, 2차 정규화 대상

② 2차 정규형, 3차 정규화 대상

③ 3차 정규형, 보이스-코드 정규화대상

④ 보이스-코드정규형, 4차 정규화 대상

PK에 대해 반복이 되는 그룹(Repeating)이 존재하지 않으므로 1차 정규형이라고 할 수 있으며, 부분 함수종속의 규칙을 가지고 있으므로 2차 정규형이라고 할 수 없음. 2차 정규화의 대상이 되는 엔터티임
PK에 대해 반복적인 그룹
- 모델코드라는 PK에 대해서 전공필수 과목코드, 전공선택 과목코드, 교양필수 과목코드처럼 동일한 속성에서 반복적으로 사용되는 그룹으로 1차 정규화 수행 대상
1차 정규화
- 중복속성에 대한 분리가 1차 정규화의 대상이 되며, 로우단위의 중복도 1차 정규화의 대상이 되지만 칼럼 단위로 중복이 되는 경우도 1차 정규화의 대상이다.
- #제1정규형 : 모든 속성은 반드시 하나의 값(Single Value)을 가져야 한다. 즉, 반복형태가 있어서는 안된다.
- 제1정규형은 모든 속성은 유일값이어야 한다는 것

Q. 고객번호를 식별자로 하는 아래 엔터티에서 필요한 정규화 작업으로 가장 적절한 것은?

1차 정규화

고객번호	고객명	주민등록번호	취미코드	취미명
10	김00	123456-7890123	10, 11	노래, 댄스
20	이00	234567-8901234	12, 13	검도, 게임
30	박00	345678-9012345	11, 15, 16	댄스, 등산, 수영

1정규화로 모든 속성은 반드시 하나의 값만을 가져야 한다.

Q. NULL에 대한 설명으로 가장 적절하지 않은 것은?

③

① 모르는 값을 의미한다.

② 값이 부재를 의미한다.

③ 공백문자(Empty String) 혹은 숫자 0을 의미한다.

④ NULL과의 모든 비교(IS NULL 제외)는 알 수 없음(Unknown)을 반환한다.

NULL은 공백문자(Empty String) 혹은 숫자 0과 동일하지 않다.
널(NULL)의 특성
- 널 값은 아직 정의되지 않은 값으로 0 또는 공백과 다르다. 0은 숫자이고, 공백은 하나의 문자이다.
- 테이블을 생성할 때 NOT NULL 또는 PRIMARY KEY로 정의되지 않은 모든 데이터 유형은 널 값을 포함할 수 있다.
- 널 값을 포함하는 연산의 경우 결괏값도 널 값이다. 모르는 데이터에 숫자를 더하거나 빼도 결과를 마찬가지로 모르는 데이터인 것과 같다.
- 결괏값을 NULL이 아닌 다른 값을 얻고자 할 때 NVL/ISNULL 함수를 사용한다. 널 값의 대상이 숫자 유형 데이터인 경우는 주로 0(Zero)으로, 문자 유형 데이터인 경우는 공백보다는 ‘x’ 같이 해당 시스템에서 의미 없는 문자로 바꾸는 경우가 많다.

Q. 아래와 같이 테이블을 변환하였을 때 이에 대한 설명으로 가장 적절하지 않은 것은? (단, (A)에서 주식별자는 사번이며, 함수 종속성 부서 → 사무실이 존재한다고 가정)

① 제1정규화를 수행한 것에 해당한다.

(A)

사번	부서	사무실
001	총무	서울
002	영업	부산
003	총무	서울
004	연구	대전
005	영업	부산

(B)

사번	부서
001	총무
002	영업
003	총무
004	연구
005	영업

부서	사무실
총무	서울
영업	부산
연구	대전

① 제1정규화를 수행한 것에 해당한다.

② 제2정규화를 수행한 것에 해당한다.

③ (B)는 제3정규형을 만족한다.

④ 주어진 사번의 사무실을 검색하는 작업의 성능이 저하된다.

해당 작업은 제2정규화를 수행한 것에 해당하며, (B)는 2차 정규형뿐만 아니라 3차 정규형도 만족한다. 또한 정규화를 수행하면 일반적으로 검색 작업의 성능이 저하된다.

Q. 순차적으로 수행되는 작업 A와 B가 반드시 수행되거나 모두 수행되지 않아야 한다고 할 때, 이에 대한 설명으로 가장 적절하지 않은 것은?

②

① A와 B는 하나의 트랜잭션으로 묶여 처리되어야 한다.

② A와 B를 수행한 후 각각 커밋(Commit)을 해주어야 한다.

③ A와 B에 주어진 조건은 트랜잭션의 원자성(Atomicity)에 해당한다.

④ A까지만 수행되고 시스템 장애가 발생했다면 A를 undo해야 한다.

A와 B가 하나의 트랜잭션으로 묶여 처리되어야 하므로 커밋은 A와 B를 모두 수행한 다음에 해주어야 한다.

Q. NULL 값에 대한 설명으로 가장 적절한 것은?

①

① NULL 값에 어떤 숫자를 더해도 결과는 항상 NULL이다.

② NULL 값과 어떤 숫자의 크기를 비교해도 결과는 항상 NULL이다.

③ “NULL = NULL” 연산의 결과는 TRUE이다.

④ 집계 함수를 계산할 때 NULL 값은 0으로 처리된다.

NULL 값과 어떤 숫자를 비교한 결과는 항상 unknown이다.
“NULL = NULL” 연산의 결과는 FALSE 또는 unknown이다.
집계 함수를 계산할 때 NULL 값은 0이 아니라 계산에서 제외된다.

Q. 본질식별자와 인조식별자에 대한 설명으로 가장 적절하지 않은 것은?

④

① 인조식별자는 대체로 본질식별자가 복잡한 구성을 가질 때 만들어진다.

② 인조식별자를 사용하면 중복 데이터를 막기 어려워진다.

③ 인조식별자를 사용하면 본질식별자를 사용할 때와 비교하여 추가적인 인덱스가 필요해진다.

④ 인조식별자는 개발 편의성을 높여주기 때문에 되도록 사용하는 것이 바람직하다.

인조식별자는 단점도 존재하므로 꼭 필요한 경우에만 사용하는 것이 바람직하다.
① 인조식별자는 대체로 본질식별자가 복잡한 구성을 가질 때 만들어진다.
- 개인을 부모로 갖는 “주문”은 개인의 #복합식별자(성명,생년월일,성별코드)를 모두 상속받아 PK를 구성하게 된다. 주문을 부모로 갖는 수많은 엔터티들도 주문의 PK인 4개 컬럼 이상의 PK를 가지게 되어 복잡한 PK를 가지게 된다. 이럴 경우 상위 개념의 엔터티(키엔터티, 메인엔터티)는 인조식별자로 정의하여 하위의 많은 자식들의 PK 수나 속성 수를 간편하게 하기 위하여 인조식별자를 사용한다.
② 인조식별자를 사용하면 중복 데이터를 막기 어려워진다.
- 개인 엔터티의 PK를 본질식별자인 주민등록번호로 하면 동일 주민등록번호 입력 시 PK중복으로 에러메시지를 발생시키고 해당 데이터는 INSERT가 되지 않는다. DBMS차원에서 자동으로 중복을 막아준다.
- 그런데 인조식별자를 사용하게 되면 개인번호만 중복되지 않으면 데이터를 INSERT 할 수 있기 때문에 동일 주민등록번호가 들어올 수 있는 환경을 준다.
- 이를 위하여 인조식별자인 개인번호를 PK로 하였을 경우 일반속성인 주민등록번호 속성에 Unique Index를 부여하거나, 프로그램에서 동일 주민등록번호가 있는지 체크 후 입력할 수 있는 별도의 검증 장치를 마련해야한다.
③ 인조식별자를 사용하면 본질식별자를 사용할 때와 비교하여 추가적인 인덱스가 필요해진다.
- 본질식별자를 PK로 사용하면 일반적으로 PK 인덱스를 생성하여 사용한다. 개인 엔터티의 주민등록번호를 PK로 하면 주민등록번호 칼럼에 PK 인덱스가 부여된다. 하지만 인조식별자인 개인번호를 PK로 사용하면 개인번호에 PK 인덱스를 부여하고, 주민등록번호를 조회조건으로 많은 업무에서 사용할 경우 조회 성능 향상을 위하여 주민등록번호 속성에 인덱스를 별도로 부여해야 한다.
④ 인조식별자는 개발 편의성을 높여주기 때문에 되도록 사용하는 것이 바람직하다.
- 인조식별자는 개발편의성을 높여준다. 개인 엔터티의 개인번호를 PK로 하였다면 개인 엔터티의 주민등록번호 속성 값만 바꾸어주면 된다.
- 엔터티의 특성을 고려하여 일반적으로는 상위 개념의 엔터티(Key 엔터티, Main 엔터티)들은 인조식별자로 정의하고, 행위(Active) 엔터티들은 본질식별자로 정의하는 것이 바람직하다.
- 인조식별자로 정의하였을 경우, 보기 ②, ③과 같이 후속으로 고려해야 할 사항이 많기 때문이다.
엔터티의 발생 시점에 따라 기본 엔터티, 중심 엔터티, 행위 엔터티로 구분할 수 있다.
- 발생 시점에 따른 엔터티 분류
  - 기본, 키 엔터티(Fundamental Entity, Key Entity)
    - 독립적으로 생성되는 엔터티
    - 타 엔터티의 부모 역할, 자신의 고유한 주식별자 가짐
    - 사원,부서
  - 중심 엔터티(Main Entity)
    - 기본 엔터티와 행위 엔터티의 중간에 존재하는 엔터티
    - 기본 엔터티로부터 발생, 다른 엔터티와의 관계로 많은 행위 엔터티 생성
    - 계약, 사고, 주문
  - 행위 엔터티(Active Entity, 사건 엔터티)
    - 2개 이상의 부모 엔터티로부터 발생함
    - 비지니스 프로세스를 실행하면서 생성되는 엔터티
    - 지속적으로 정보가 추가되고 변경되어 데이터 양이 가장 많음
    - 주문목록, 사원변경이력

참고 자료

Certificate, [SQLD] 개념 및 문제풀이

제 1장 데이터 모델링의 이해

제2장 데이터 모델과 SQL

인기 태그