[1과목] 1장 데이터 모델링의 이해

제1절 데이터 모델의 이해

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

• 업무 정보를 구성하는 기초가 되는 정보들을 일정한 표기법으로 표현한다.
• 분석된 모델로 데이터베이스를 생성하여 개발 및 데이터관리에 사용하기 위한 것이다.
• 데이터베이스를 구축하는 목적으로 데이터 모델링을 수행하며 업무에 대한 설명은 별도의 표기법을 이용한다.
• 데이터 모델링 자체로서 업무의 흐름을 설명하고 분석하는 부분에 의미를 가지고 있다.

해설

1. 데이터 모델링의 정의와 목적
데이터 모델링은 데이터베이스를 설계하거나 기존 시스템을 재구성하기 위해 데이터를 시각적으로 표현하는 과정입니다. 이를 통해 데이터의 구조, 관계, 속성을 정의하고, 비즈니스 요구사항을 반영하여 데이터베이스 설계에 활용합니다.
2. 업무 정보와 데이터 모델링의 관계
데이터 모델링은 업무 정보를 일정한 표기법(예: ERD)으로 표현하며, 이를 통해 비즈니스 요구사항을 분석하고 이를 데이터베이스 설계로 연결합니다. 따라서 업무 정보를 설명하거나 분석하는 과정은 데이터 모델링의 중요한 부분입니다.
3. 오답 분석
문제의 선택지에서 “업무에 대한 설명은 별도의 표기법을 이용한다”는 내용은 부적절합니다. 데이터 모델링 자체가 업무 정보를 설명하고 이를 데이터 구조로 변환하는 역할을 하며, 별도의 표기법이 아닌 표준화된 모델링 기법(예: ER 다이어그램)을 사용합니다.
4. 정답 선택 이유
데이터 모델링은 단순히 데이터베이스 구축만을 목적으로 하지 않으며, 비즈니스 프로세스 및 요구사항을 반영하여 데이터를 설계하는 과정입니다. 또한, 업무 흐름과 데이터를 연결하여 분석하는 것이 핵심이므로 “업무에 대한 설명은 별도의 표기법”이라는 표현은 잘못된 설명입니다.

 

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

• 현실 세계를 일정한 형식메 맞추어 표현하는 추상화의 의미를 가질 수 있다.
• 시스템 구현만을 위해 진행하는 사전단계의 작업으로서 데이터베이스 구축을 위한 사전작업의 의미가 있다.
• 복잡한 현실을 제한된 언어나 표기법으로 이해하기 쉽게 하는 단순화의 의미를 가지고 있다.
• 모호함을 배제하고 누구나 이해가 가능하도록 정확하게 현상을 기술하는 정확화의 의미를 가진다.

해설

데이터 모델링의 개념과 특징

데이터 모델링은 현실 세계의 데이터를 추상화하고 구조화하여 데이터베이스 설계나 시스템 개발에 활용하기 위한 과정입니다. 이를 통해 데이터를 시각적으로 표현하고, 데이터 간의 관계를 명확히 하며, 데이터베이스 설계의 기초를 제공합니다. 데이터 모델링의 주요 특징은 다음과 같습니다.

1. 추상화 (Abstraction)
현실 세계의 복잡한 데이터를 일정한 형식으로 단순화하여 표현합니다. 이를 통해 데이터의 본질적인 부분만을 강조합니다.

2. 단순화 (Simplification)
복잡한 현실 세계를 제한된 언어나 표기법으로 표현하여 이해하기 쉽게 만듭니다.

3. 정확화 (Precision)
모호함을 배제하고, 누구나 이해할 수 있도록 데이터를 정확하게 기술합니다. 이는 데이터베이스 설계와 비즈니스 의사소통에 중요한 역할을 합니다.

4. 목적
데이터 모델링은 단순히 시스템 구현만을 위한 사전 작업이 아니라, 비즈니스 요구사항을 반영하고 데이터 품질과 일관성을 보장하며, 효율적인 데이터 관리와 분석을 지원하는 데 목적이 있습니다.

오답 분석
• “시스템 구현만을 위해 진행하는 사전단계의 작업”이라는 설명은 부적절합니다.
데이터 모델링은 단순히 시스템 구현 단계 이전에만 사용되는 것이 아닙니다. 이는 비즈니스 요구사항 분석부터 데이터베이스 설계, 그리고 데이터 관리 및 분석까지 전반적으로 활용됩니다. 따라서 “시스템 구현만”이라는 표현은 데이터 모델링의 본질과 범위를 잘못 이해한 것입니다.

 

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

• 여러 장소의 데이터베이스에 같은 정보를 저장하지 않도록 하여 중복성을 최소화한다.
• 데이터의 정의를 데이터의 사용 프로세스와 분리하여 유연성을 높인다.
• 사용자가 처리하는 프로세스나 장표 등에 따라 매핑이 될 수 있도록 프로그램과 테이블 간의 연계성을 높인다.
• 데이터 간의 상호 연관관계를 명확하게 정의하여 일관성 있게 데이터가 유지되도록 한다.

해설

데이터 모델링 시 유의해야 할 사항

데이터 모델링은 데이터베이스 설계와 비즈니스 요구사항을 충족하기 위해 데이터를 구조화하는 과정입니다. 이를 수행할 때 다음과 같은 사항들을 유의해야 합니다:

1. 중복성 최소화
여러 장소에 동일한 데이터를 저장하지 않도록 설계하여 데이터 중복을 줄이고, 데이터 일관성과 효율성을 유지합니다.

2. 유연성 확보
데이터의 정의와 사용 프로세스를 분리하여 데이터 모델이 다양한 상황에서도 적응할 수 있도록 유연성을 높입니다.

3. 일관성 유지
데이터 간의 상호 연관관계를 명확히 정의하여 데이터가 항상 일관성 있게 유지되도록 설계합니다. 이는 데이터 무결성을 보장하는 데 필수적입니다.

오답 분석: “프로그램과 테이블 간의 연계성을 높인다”
이 선택지는 부적절합니다. 데이터 모델링은 비즈니스 요구사항과 데이터 구조를 정의하는 데 초점을 맞추는 작업으로, 특정 프로그램이나 사용자 인터페이스(UI)와의 연계성을 높이는 것이 주된 목적이 아닙니다. UI나 프로그램과의 연계는 구현 단계에서 고려되는 사항이며, 이는 데이터 모델링의 본질적인 목표와는 거리가 있습니다

 

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

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

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

• 외부스키마
• 개념스키마
• 내부스키마
• 논리스키마

해설

개념스키마는 데이터베이스의 3단계 구조(외부 스키마, 개념 스키마, 내부 스키마) 중 하나로, 조직 전체의 관점에서 데이터베이스를 논리적으로 정의한 것입니다. 다음은 개념스키마의 주요 특징입니다.

1. 조직 전체 관점의 통합적 표현
개념스키마는 모든 사용자와 응용 시스템이 필요로 하는 데이터를 통합하여 조직 전체의 데이터베이스를 기술합니다.

2. 데이터 간 관계와 제약조건 정의
데이터베이스에 저장되는 데이터와 그들 간의 관계, 제약조건, 무결성 규칙 등을 포함하여 논리적 구조를 명확히 정의합니다.

3. 단일 스키마
개념스키마는 조직 전체를 대상으로 하므로 하나의 데이터베이스에 단 하나만 존재합니다. 이는 데이터베이스 관리자(DBA)에 의해 설계됩니다

오답 분석
1. 외부스키마
외부스키마는 특정 사용자나 응용 프로그램이 필요로 하는 데이터를 정의한 것으로, 조직 전체가 아닌 개별적인 관점을 다룹니다. 따라서 문제에서 제시된 “조직 전체 관점”과는 맞지 않습니다.
2. 내부스키마
내부스키마는 데이터가 물리적으로 저장되는 방식을 기술하며, 물리적 저장장치와 밀접한 관계가 있습니다. 문제에서 언급된 “논리적 표현”과는 거리가 멉니다.
3. 논리스키마 (Logical Schema)
“논리스키마”라는 용어는 일반적인 데이터베이스 스키마 분류(외부, 개념, 내부)에서는 사용되지 않습니다. 따라서 적절하지 않은 선택지입니다.

 

제2절 엔터티

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

• 속성이 없는 엔터티는 있을 수 없다. 엔터티는 반드시 속성을 가져야 한다.
• 엔터티는 다른 엔터티와 관계가 있어야 한다. 단, 통계성 엔터티나, 코드성 엔터티의 경우 관계를 생략할 수 있다.
• 객체 지향의 디자인 패턴에는 싱글턴패턴이 있어 하나의 인스턴스를 가지는 클래스가 존재한다. 이와 유사하게 엔터티는 한 개의 인스턴스를 가지는 것만으로도 충분한 의미를 부여할 수 있다.
• 데이터로서 존재하지만 업무에서 필요로 하지 않으면 해당 업무의 엔터티로 성립될 수 없다.

해설

엔터티(Entity)는 데이터 모델링에서 중요한 개념으로, 현실 세계에서 독립적으로 존재할 수 있는 객체나 개념을 나타냅니다. 엔터티는 다음과 같은 특징을 가집니다.

1. 속성을 반드시 가져야 한다
엔터티는 정보를 표현하기 위해 속성을 가져야 합니다. 예를 들어, “학생” 엔터티는 이름, 학번, 생년월일 등의 속성을 가질 수 있습니다.

2. 다른 엔터티와 관계를 가질 수 있다
엔터티 간에는 관계가 존재하며, 이를 통해 데이터 간의 연관성을 표현합니다. 단, 통계성 엔터티나 코드성 엔터티처럼 독립적으로 존재하는 경우에는 관계가 생략될 수 있습니다.

3. 업무적 필요성에 따라 정의된다
데이터로서 존재하더라도 업무에서 필요하지 않다면 엔터티로 정의되지 않습니다. 즉, 업무적 중요성이 엔터티로 성립되는 기준이 됩니다.

오답 분석: “싱글턴패턴과 유사하게 한 개의 인스턴스만으로 의미 부여 가능”
이 설명은 부적절합니다.
• 엔터티는 일반적으로 다수의 인스턴스를 가지며, 이를 통해 데이터를 관리하고 분석합니다. 예를 들어, “학생” 엔터티에는 여러 학생(인스턴스)이 포함됩니다.
• 싱글턴 패턴처럼 “하나의 인스턴스만으로도 충분한 의미를 가진다”는 설명은 객체 지향 프로그래밍의 개념에 해당하며, 데이터 모델링에서의 엔터티 개념과는 맞지 않습니다.

정리
• 속성을 반드시 가져야 함.
• 다른 엔터티와 관계를 가질 수 있음(특정 경우 제외).
• 업무적 필요성을 기반으로 정의됨.

• 부적절한 설명:
• 싱글턴 패턴처럼 하나의 인스턴스로 충분히 의미를 가진다는 설명은 데이터 모델링의 엔터티 개념과 맞지 않음.

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

• 관계 엔터티
• 행위 엔터티
• 중심 엔터티
• 기본 엔터티

해설

발생 시점에 따라 구분할 수 있는 엔터티의 유형

데이터 모델링에서 발생 시점에 따라 엔터티는 다음 세 가지로 구분됩니다:
1. 기본 엔터티 (Fundamental Entity)
• 업무에서 독립적으로 존재하며, 다른 엔터티와 관계없이 고유한 데이터를 갖는 엔터티입니다.
• 발생 시점: 처음부터 존재하는 데이터.
• 예시: 고객, 제품, 직원 등.

2. 중심 엔터티 (Main Entity)
• 기본 엔터티와 관련된 데이터를 관리하며, 여러 기본 엔터티와의 관계를 통해 업무의 중심 역할을 합니다.
• 발생 시점: 업무가 진행되면서 생성되는 데이터.
• 예시: 주문, 계약 등.

3. 행위 엔터티 (Active Entity)
• 업무 프로세스에서 발생하는 이벤트나 기록을 저장하는 엔터티입니다.
• 발생 시점: 업무 행위나 사건이 발생할 때 생성되는 데이터.
• 예시: 거래 내역, 수강 기록 등.

 

제3절 속성

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

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

해설

1. 엔터티의 구체적인 정보를 나타냄
• 속성은 엔터티를 설명하는 세부 정보입니다. 예를 들어, “학생” 엔터티의 속성으로는 이름, 학번, 생년월일 등이 있습니다.

2. 엔터티는 두 개 이상의 속성을 가질 수 있음
• 대부분의 엔터티는 여러 속성을 가지며, 이를 통해 엔터티를 더 구체적으로 정의합니다. 예를 들어, “제품” 엔터티는 제품명, 가격, 제조일 등의 속성을 가질 수 있습니다.

3. 속성도 집합으로 간주됨
• 속성은 데이터의 집합으로 볼 수 있으며, 각 속성은 특정 도메인(값의 범위)을 가집니다. 예를 들어, “나이” 속성은 숫자 데이터로 구성된 집합입니다

엔터티, 인스턴스, 속성, 속성값의 관계
- 한 개의 엔터티는 두 개 이상의 인스턴스 집합이어야 한다.
- 한 개의 엔터티는 두 개 이상의 속성을 갖는다.
- 한 개의 속성은 한 개의 속성값을 갖는다.

 

 

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

• 파생속성
• 기본속성
• 설계속성
• PK속성

 

제4절 관계

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

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

해설

선택지 분석
1. “관계는 존재에 의한 관계와 행위에 의한 관계로 구분될 수 있으나 ERD에서는 관계를 연결할 때, 존재와 행위를 구분하지 않고 단일화된 표기법을 사용한다.”
• 적절한 설명:
ERD에서는 관계를 단순히 선과 다이아몬드(relationship symbol)로 표현하며, 존재적 관계와 행위적 관계를 구분하지 않습니다. 이는 ERD의 표기법이 단순화된 데이터 모델링 도구임을 반영합니다.

2. “UML(Unified Modeling Language)에는 클래스다이어그램의 관계 중 연관관계(Association)와 의존관계(Dependency)가 있고 이것은 실선과 점선으로 다르게 표현이 된다.”
• 적절한 설명:
UML 클래스 다이어그램에서는 연관관계(Association)는 실선으로, 의존관계(Dependency)는 점선으로 표현됩니다. 이는 UML 표준에 따른 명확한 구분입니다.

3. “연관관계는 항상 이용하는 관계로 존재적 관계에 해당하고, 의존관계는 상대방 클래스의 행위에 의해 관계가 형성되는 행위적 관계에 해당한다.”
• 적절한 설명:
UML에서 연관관계는 두 클래스 간의 지속적인 연결을 나타내며, 주로 존재적 관계를 의미합니다. 반면, 의존관계는 일시적인 상호작용(예: 메서드 호출 등)을 나타내며 행위적 관계로 볼 수 있습니다.

4. “연관관계는 오퍼레이션에서 파라미터 등으로 이용할 수 있고, 의존관계는 소스코드에서 멤버변수로 선언하여 사용할 수 있다.”
• 부적절한 설명:
이 설명은 UML의 연관관계와 의존관계를 혼동하고 있습니다. 실제로:
• 연관관계는 클래스 간의 지속적인 연결을 나타내며, 주로 멤버 변수(속성)로 선언됩니다.
• 의존관계는 메서드 호출 시 파라미터나 반환값으로 사용되는 일시적인 상호작용을 나타냅니다.
따라서 “연관관계”와 “의존관계”의 역할이 뒤바뀌어 잘못된 설명입니다.

정리
• 올바른 설명:
1. ERD에서는 존재와 행위를 구분하지 않고 단일화된 표기법을 사용.
2. UML에서는 연관관계를 실선으로, 의존관계를 점선으로 표현.
3. UML에서 연관관계는 존재적 관계, 의존관계는 행위적 관계를 의미.
• 부적절한 설명:
• “연관관계는 오퍼레이션에서 파라미터 등으로 이용할 수 있고, 의존관계는 소스코드에서 멤버변수로 선언하여 사용할 수 있다.”

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

• 관계는 존재적 관계와 행위에 의한 관계로 나누어볼 수 있다.
• 관계의 표기법은 관계명, 관계차수, 식별성의 3가지 개념을 사용한다.
• 부서와 사원 엔터티 간의 '소속' 관계는 존재적 관계의 사례이다.
• 주문과 배송 엔터티 간의 '배송근거' 관계는 행위에 의한 관계의 사례이다.

해설

1. 존재적 관계와 행위적 관계
• 관계는 존재적 관계(Existential Relationship)와 행위적 관계(Behavioral Relationship)로 나눌 수 있습니다.
• 예: 부서와 사원 간의 “소속”은 존재적 관계, 주문과 배송 간의 “배송근거”는 행위적 관계입니다.
• ERD에서는 이러한 구분 없이 단일화된 표기법(선과 마름모)을 사용하여 표현합니다.

2. UML에서의 관계 표기법
• UML(Unified Modeling Language)에서는 연관관계(Association)는 실선, 의존관계(Dependency)는 점선으로 구분하여 표현합니다. 이는 UML의 표준적인 방식입니다.

3. 관계 표기법의 구성 요소
• ERD에서 관계를 나타낼 때는 관계명, 카디널리티(다중성), 그리고 **참여도(Participation)**를 주로 사용합니다.
• “관계차수”와 “식별성”은 ERD에서 일반적으로 사용하는 개념이 아닙니다. 따라서 이 설명은 부적절합니다.

선택지 분석
1. “관계는 존재적 관계와 행위에 의한 관계로 나누어볼 수 있다.”
• 적절한 설명입니다. 존재적 관계는 엔터티 간의 본질적인 연결을 나타내고, 행위적 관계는 특정 이벤트나 작업에 의해 형성됩니다.

2. “관계의 표기법은 관계명, 관계차수, 식별성의 3가지 개념을 사용한다.”
• 부적절한 설명입니다. ERD에서는 보통 **카디널리티(다중성)**와 참여도를 사용하며, “관계차수”와 “식별성”은 일반적인 ERD 표기법에서 사용되지 않습니다.

3. “부서와 사원 엔터티 간의 ‘소속’ 관계는 존재적 관계의 사례이다.”
• 적절한 설명입니다. 부서와 사원 간의 “소속”은 본질적으로 존재적 관계에 해당합니다.

4. “주문과 배송 엔터티 간의 ‘배송근거’ 관계는 행위에 의한 관계의 사례이다.”
• 적절한 설명입니다. 주문과 배송 간의 “배송근거”는 특정 행위(배송)에 의해 형성된 행위적 관계입니다.
정리

• 부적절한 설명: “관계의 표기법은 관계명, 관계차수, 식별성의 3가지 개념을 사용한다.”
→ ERD에서는 주로 카디널리티와 참여도를 사용하며, “관계차수”와 “식별성”은 일반적인 표기법에 포함되지 않습니다.

 

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

• 데이터베이스의 파일 구조의 변화가 논리스키마에 영향을 주지 않음
• 데이터베이스의 색인 구조의 변화가 응용 프로그램에 영향을 주지 않음

• 논리적 독립성
• 물리적 독립성
• 개념적 독립성
• 내부적 독립성

해설

물리적 독립성(Physical Data Independence)은 데이터베이스의 물리적 저장 구조가 변경되더라도 논리적 스키마(Conceptual Schema)에 영향을 미치지 않는 특성을 말합니다. 즉, 내부적인 저장 방식(예: 색인 구조, 파일 조직, 데이터 압축 방식 등)이 변경되더라도 데이터베이스의 논리적 설계나 응용 프로그램에는 영향을 주지 않습니다.

선택지 분석
1. “데이터베이스의 파일 구조의 변화가 논리스키마에 영향을 주지 않음”
• 이는 물리적 독립성의 정의에 해당합니다. 파일 구조나 저장 장치의 변경은 물리적 레벨에서 이루어지며, 논리적 스키마와는 무관합니다.

2. “데이터베이스의 색인 구조의 변화가 응용 프로그램에 영향을 주지 않음”
• 색인 구조는 물리적 저장 방식의 일부로, 물리적 독립성에 의해 응용 프로그램이나 논리적 스키마에 영향을 주지 않습니다.

3. 논리적 독립성(Logical Data Independence)
• 논리적 독립성은 논리적 스키마가 변경되더라도 외부 스키마(사용자 관점)나 응용 프로그램에 영향을 미치지 않는 특성을 말합니다. 예를 들어, 테이블에 새로운 속성을 추가하거나 삭제해도 기존 응용 프로그램이 정상적으로 작동하는 것을 보장합니다.
• 하지만 문제에서 언급된 “파일 구조”나 “색인 구조”는 논리적 독립성과 관련이 없습니다.

4. 개념적 독립성 및 내부적 독립성
• “개념적 독립성”이라는 용어는 논리적 독립성과 혼용될 수 있지만, 일반적으로 사용되지 않는 표현입니다.
• “내부적 독립성” 또한 데이터베이스 설계에서 사용되지 않는 용어입니다.

정리
• 정답: 물리적 독립성
• 물리적 저장 구조(예: 색인, 파일 조직) 변경이 논리스키마나 응용 프로그램에 영향을 미치지 않는 특성을 설명합니다.
• 논리적 독립성과 차이점:
• 논리적 독립성은 논리스키마 변경이 외부 스키마나 응용 프로그램에 영향을 미치지 않는 것을 의미하며, 문제와는 관련이 없습니다.

 

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

• 관계명
• 관계차수
• 관계선택사양
• 관계정의

해설

관계차수(Cardinality)는 두 엔터티 간의 관계에서 참여자의 수를 나타내는 개념입니다. 이는 데이터베이스 설계에서 매우 중요한 요소로, 엔터티 간의 연관성을 정의하고 데이터의 구조를 명확히 표현하는 데 사용됩니다.
관계차수의 유형
1. 1:1 (One-to-One)
• 한 엔터티가 다른 엔터티의 하나의 인스턴스와만 연결되는 경우.
• 예: 한 사람은 하나의 주민등록번호를 가짐.
2. 1:N (One-to-Many)
• 한 엔터티가 다른 엔터티의 여러 인스턴스와 연결되는 경우.
• 예: 한 부서는 여러 사원을 가질 수 있음.
3. N:M (Many-to-Many)
• 여러 엔터티가 서로 다수의 인스턴스와 연결되는 경우.
• 예: 학생과 강의 간의 관계(한 학생이 여러 강의를 수강할 수 있고, 한 강의를 여러 학생이 들을 수 있음).

선택지 분석
1. 관계명
• 관계를 식별하기 위해 부여된 이름입니다. 예를 들어, “소속”, “수강” 등이 관계명에 해당합니다.
• 하지만 관계명은 참여자의 수와는 관련이 없습니다.
2. 관계차수
• 두 엔터티 간의 참여자의 수를 나타내며, 1:1, 1:N, N:M과 같은 형태로 표현됩니다.
• 정답에 해당합니다.
3. 관계선택사양
• 관계에서 참여가 필수인지 선택인지 여부를 나타냅니다(예: 필수 참여 또는 선택적 참여).
• 이는 참여자의 수와는 다른 개념입니다.
4. 관계정의
• 관계 자체를 설명하는 일반적인 용어로, 구체적인 개념(참여자의 수 등)을 나타내지는 않습니다.

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

• 두 개의 엔터티 사이에 관심 있는 연관규칙이 존재하는가?
• 두 개의 엔터티 사이에 정보의 조합이 발생되는가?
• 업무기술서, 장표에 관계연결을 가능하게 하는 명사가 있는가?
• 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?

해설

두 개의 엔터티 사이에 정의된 관계를 확인할 때 중요한 요소는 다음과 같습니다:
1. 관심 있는 연관 규칙이 존재하는가?
• 두 엔터티 간의 관계를 정의하려면, 해당 관계가 비즈니스적으로 의미가 있는지 확인해야 합니다.
• 예: “고객”과 “주문” 간의 관계에서 “고객이 주문을 한다”는 규칙이 존재해야 합니다.
2. 정보의 조합이 발생되는가?
• 두 엔터티 간의 관계를 통해 새로운 정보를 생성하거나 조합할 수 있어야 합니다.
• 예: “학생”과 “강의” 간의 관계에서 “학생이 어떤 강의를 수강했는지”라는 정보를 얻을 수 있습니다.
3. 업무기술서나 장표에 관계 연결에 대한 규칙이 서술되어 있는가?
• 비즈니스 규칙은 업무기술서나 장표에 명시되어 있어야 하며, 이를 통해 관계를 정의할 수 있습니다.
• 예: “부서와 직원 간의 소속 관계”는 업무 문서에서 확인 가능한 규칙입니다.
4. 업무기술서나 장표에 관계 연결을 가능하게 하는 명사가 있는가?
• 이 설명은 부적절합니다. 두 엔터티 간의 관계는 명사보다는 **동사(행위나 상태)**로 정의됩니다.
• 예: “소속”, “수강”, “주문” 등은 동사형으로 표현되며, 명사는 엔터티 자체를 나타냅니다(예: 학생, 강의). 따라서 관계를 확인할 때 명사를 기준으로 삼는 것은 적절하지 않습니다.

 

제5절 식별자

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

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

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

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

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

해설

주식별자(Primary Key)는 데이터베이스 테이블에서 각 행을 고유하게 식별하기 위해 사용하는 속성(또는 속성들의 조합)입니다. 주식별자를 지정할 때 고려해야 할 사항은 다음과 같습니다:
1. (가) 주식별자에 의해 엔터티 내의 모든 인스턴스들이 유일하게 구분되어야 한다.
• 주식별자는 반드시 테이블의 각 행을 고유하게 식별할 수 있어야 합니다.
• 이는 주식별자의 기본 조건으로, 중복된 값이 허용되지 않습니다.
2. (나) 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.
• 주식별자는 최소한의 속성으로 구성되어야 하며, 이를 최소성(Irreducibility)이라고 합니다.
• 복잡한 조합 대신 단순하고 효율적인 키를 사용하는 것이 바람직합니다.
3. (다) 지정된 주식별자의 값은 자주 변하지 않는 것이어야 한다.
• 주식별자는 데이터베이스의 무결성을 유지하기 위해 안정적이어야 하며, 값이 자주 변경되지 않아야 합니다.
• 변경이 잦으면 참조 무결성 제약 조건을 유지하기 어렵고 성능에 영향을 미칠 수 있습니다.
4. (라) 주식별자가 지정이 되면 반드시 값이 들어와야 한다.
• 주식별자는 NULL 값을 가질 수 없으며, 모든 행에 반드시 값이 존재해야 합니다.
• 이는 데이터베이스에서 유일성과 무결성을 보장하기 위한 필수 조건입니다

식별자의 종류

1. 엔터티 내에서 대표성을 가지는가에 따라 주식별자와 보조식별자로 구분
2. 엔터티 내에서 스스로 생성되었는지 여부에 따라 내부식별자와 외부식별자로 구분
3. 단일 속성으로 식별이 되는가에 따라 단일식별자와 복합식별자로 구분
4. 원래 업무적으로 의미가 있던 식별자 속성을 대체하여 일련번호와 같이 새롭게 만든 식별자를 구분하기 위해 본질식별자와 인조식별자로 구분

 

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

• 유일성: 주식별자에 의해 엔터티 내의 모든 인스턴스들은 유일하게 구분된다.
• 존재성: 주식별자는 데이터 값이 없을 수 있다.
• 불변성: 주식별자가 한번 특정 엔터티에 지정되면 그 식별자의 값은 변하지 않아야 한다.
• 최소성: 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.

해설

1. 유일성 (Uniqueness)
• 주식별자는 엔터티 내 모든 인스턴스를 유일하게 구분할 수 있어야 합니다.
• 예: 사원번호, 주민등록번호 등.
2. 최소성 (Minimality)
• 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소한의 속성으로 구성되어야 합니다.
• 불필요하게 많은 속성을 포함하지 않아야 합니다.
3. 불변성 (Immutability)
• 주식별자의 값은 한 번 지정되면 변경되지 않아야 합니다.
• 값이 자주 변경되면 데이터 무결성과 참조 무결성이 손상될 가능성이 있습니다.
4. 존재성 (Existence)
• 주식별자는 반드시 값을 가져야 하며, NULL 값을 허용하지 않습니다.
• 이는 데이터베이스에서 무결성을 유지하기 위한 필수 조건입니다.