오답노트 ( 데이터 모델링 )

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

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

정답 3번

 

해설

"데이터모델링은 DB 구축 목적"만 있다고 하면 틀린 설명!

데이터모델링은 업무 분석까지 포함

 

4번이 아닌 이유

데이터 모델링을 하는 첫번째 목적은 업무정보를 구성하는 기초 정보들을 일정한 표기법으로 표현하여 정보시스템 구축의 대상이 되는 업무 내용을 정확하게 분석하는 것이다. 두 번째는 분석된 모델로 실제 데이터베이스를 생성하여 개발 및 데이터관리에 사용하기 위한 것이다. 다시 말하면, 데이터 모델링이라는 것은 단지 데이터베이스만을 구축하기 위한 용도로 쓰이는 것이 아니라 데이터 모델링 자체로도 업무를 설명하고 분석하는 부분에서 매우 중요한 의미가 있다고 할 수 있다

 

2️⃣ ERD에 대한 설명으로 가장 적절하지 않은 것은?

1. 1976년 피터 첸에 의해 Entity-Relationship Model 이라는 표기법이 만들어졌다
2. 일반적으로 ERD를 작성할 때 엔터티 도출 → 엔터티 배치 → 관계 설정 → 관계명 기술의 흐름으로 작업을 진행한다
3. 관계의 명칭은 관계 표현에서 매우 중요한 부분에 해당한다
4. 가장 중요한 엔터티를 오른쪽 상단에 배치하고 추가로 발생되는 엔터티들을 왼쪽 편과 하단에 배치하는 것이 원칙이다

정답 4번

 

해설

엔터티를 어디에 배치하는가에 대한 문제는 필수사항은 아니다

하지만 데이터 모델링 툴 사용여봐 상관없이 가독성 측면에서 사람의 눈은 왼쪽에서 오른쪽으로 위에서 아래로 이동하는 경향이 있기 때문에, 가장 중요한 엔터티를 왼쪽 상단에 배치하는 것이 효과적이다

 

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

1. 가능하면 약어를 사용하여 엔터티의 이름을 간결하고 명확하게 한다
2. 현업의 업무 용어를 사용하여 업무상의 의미를 분명하게 한다
3. 모든 엔터티에서 유일한 이름이 부여되어야 한다
4. 엔터티가 생성되는 의미대로 자연스럽게 부여하도록 한다

정답 1번

 

해설

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

1. 가능하면 현업 업무에서 사용 하는 용어
2. 가능하면 약어를 사용하지 않는다
3. 단수명사 사용
4. 모든 엔터티를 통틀어서 유일하게 이름이 부여되야함
5. 엔터티 생성의미대로 이름을 부여

 

4️⃣ 속성에 대한 설명으로 가장 적절하지 않은 것은?

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

정답 3번

 

해설

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

 

4번이 적절한 이유

속성의 도메인은 집합으로 표현할 수 있다

하지만

"속성 자체가 집합이다" 라고 말하면 애매함

• 속성은 본래 값을 저장하는 단일 필드(예: 이름, 나이, 이메일 등) 를 의미한다
• 이를 "집합"이라고 부르면 마치 속성 하나가 여러 값을 동시에 가진다(다치 속성)는 뜻처럼 받아들여질 수 있다
• 하지만 일반적인 속성은 단일값(Single-valued) 속성이 원칙입니다.

→ 그래서 "속성도 집합이다"는 표현은 기술적으로 부정확하거나 애매합니다.

 

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

1. 파생 속성
2. 기본 속성
3. 설계 속성
4. PK 속성

정답 1번

 

속성	특징
파생 속성	다른 속성값을 바탕으로 계산된 값. 성능 향상을 위해 컬럼에 저장하기도 함 (ex. 나이, 합계 금액 등).
기본 속성	엔터티가 원래부터 가지고 있는 속성. 변환 없이 바로 저장됨 (ex. 이름, 생년월일).
설계 속성	데이터 모델 설계 시 특별한 목적으로 추가하는 속성. 시스템 관리용이거나 관계 설정용 (ex. 이력관리 플래그, 상태값).
PK 속성 (Primary Key)	엔터티의 각 인스턴스를 유일하게 식별하는 속성. 중복 불가, Null 불가 (ex. 회원 ID).

 

6️⃣ 아래에서 설명하는 데이터 독립성은?

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

1. 논리적 독립성
2. 물리적 독립성
3. 개념적 독립성
4. 내부적 독립성

정답 2번

 

해설

독립성	설명	예시
물리적 독립성	물리적 저장 구조(파일, 색인 등)의 변화가 논리적 스키마(테이블 구조)에 영향을 주지 않음	데이터 파일을 SSD에서 HDD로 옮겨도 테이블 설계는 그대로
논리적 독립성	논리적 스키마(테이블 구조)의 변화가 응용 프로그램(애플리케이션)에 영향을 주지 않음	테이블에 새로운 컬럼 추가해도 프로그램 코드 수정 안 해도 됨
개념적 독립성	사용자 뷰(External Schema)의 변경이 논리적 스키마에 영향을 주지 않음	사용자가 보는 보고서에서 특정 컬럼을 빼도 DB 구조는 그대로
내부적 독립성	→ 사실상 물리적 독립성과 같은 의미로 간주됨 (현대 DBMS에서는 따로 구분 안 하는 경우가 많음)	파일 포맷이 바뀌어도 논리 설계 영향 없음

 

4번이 아닌 이유

 

내부적 독립성 → 거의 공식 용어로 안 씀. (일부 책에서만 설명용으로 사용)

물리적 독립성 → 국가공인시험, 대학 교재, SQLD 시험 모두 이 용어 사용.

 

내부적 독립성 = 물리적 독립성과 같은 뜻이지만, 공식 답안에서는 물리적 독립성을 사용한다.

 

 

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

1. 주식별자
2. 단일식별자
3. 내부식별자
4. 인조식별자

정답 4번

 

해설

식별자 종류	특징	예시
주식별자 (Primary Identifier)	엔터티 내에서 인스턴스를 대표하는 유일한 식별자.	주민등록번호, 학번, 사번
내부식별자	엔터티 내 자체적으로 생성되는 식별자.	상품번호, 회원번호 (엔터티 내부에서 자동 생성)
단일식별자 (Single Identifier)	하나의 속성만으로 유일하게 인스턴스를 식별할 수 있는 경우.	주민등록번호, 학번
본질식별자	원래 업무적으로 의미를 가진 자연 속성이 식별자가 된 경우.	주민등록번호, 이메일주소 (이미 업무에서 고유하게 존재)
인조식별자	업무적으로 의미는 없지만 시스템 편의를 위해 새로 만든 일련번호형 식별자.	사용자ID(auto increment), 주문번호(UUID)

‘사번’은 업무적으로 의미 있는 식별자로 시스템적으로 부여된 인조식별자가 아니라 본질식별자로 볼 수 있다.

 

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

[학생]

학번
성명
학과번호
학과명
LAB실이용신청일1
LAB실이용시작일1
LAB실이용만기일1
LAB실이용승인교수번호1
LAB실이용승인교수명1
LAB실이용신청일2
LAB실이용시작일2
LAB실이용만기일2
LAB실이용승인교수번호2
LAB실이용승인교수명2
LAB실이용신청일3
LAB실이용시작일3
LAB실이용만기일3
LAB실이용승인교수번호3
LAB실이용승인교수명3
LAB실이용신청일4
LAB실이용시작일4
LAB실이용만기일4
LAB실이용승인교수번호4
LAB실이용승인교수명4

[도서대출]

대출번호
대출자번호(FK)
대출자명
대출자신분구분(학생,교수)
대출일자
대출도서번호
대출도서명
출판사명
출판년월
대표저자명
ISBN
반납일자

1. 5
2. 6
3. 7
4. 8

정답 3번

 

해설

3차 정규화까지 수행시

학과, 학생, 교수, LAB실이용신청,(도서)대출,대출도서,도서 이렇게 7개의 엔터티가 도출됨

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

[수강지도]

학번
과목코드
------------------
성적
지도교수명
학과명

 

[함수종속성]

1. 학번||과목코드 → 성적
2. 학번 → 지도교수명
3. 학번 → 학과명 

 

1. 1차 정규형, 2차 정규화 대상
2. 2차 정규형 3차 정규화 대상
3. 3차 정규형, 보이스-코드 정규화 대상
4. 보이스-코드정규형, 4차 정규화 대상

정답 1번

 

해설

PK에 대해 반복이 되는 그룹이 존재하지 않으므로 1차 정규형이라고 할 수 있으며,

부분 함수종속의 규칙을 가지고 있으므로 2차 정규형이라고 할 수 없음.

2차 정규화의 대상이 되는 엔터티임.

 

'지도교수명과 학과명은 과목코드에 의존하지 않고, 학번만으로 결정되기에 2차 정규화 대상임'

 

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

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

1. 1차 정규화
2. 2차 정규화
3. 3차 정규화
4. 4차 정규화

정답 1번

 

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

( 취미코드와 취미명에 2-3개씩 들어감 )

 

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

[전제조건]

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

모뎀
모뎀코드
-----------------------------
모델명
제품류코드
물품가
출하가
A유형기능분류코드1
B유형기능분류코드2
C유형기능분류코드3
D유형기능분류코드4
E유형기능분류코드5
F유형기능분류코드6
G유형기능분류코드7
H유형기능분류코드8
I유형기능분류코드9
바코드
가로
세로
높이
모뎀구분
…

1. 조회 조건이 유형기능분류코드에 따라 반복되는 그룹이 컬럼단위로 되어 있으므로 제1정규형이라고 할 수 있다
2. 유형기능분류코드에 대해 where절에 조건으로 들어오는 값이 있으므로 PK와 이에 대한 인덱스만 있으면 SQL 문장을 빠르게 수행될 수 있다고 할 수 있다
3. 유형기능분류코드가 일반속성 안에서 반복적을 속성이 구분되어 있기 때문에 이전종속을 수행해야 하는 제2정규형이라 할 수 있다
4. 조회 성능을 위해 유형기능분류코드 각각에 대하여 개별로 인덱스를 모두 생성할 경우 입력,수정,삭제 때 성능이 저하되므로 제 1차 정규화를 수행한 후 인덱스를 적용하는 것이 좋다

정답 4번

 

해설

 

지금 테이블 구조는 어떤 상태?

A유형기능분류코드1
B유형기능분류코드2
...
I유형기능분류코드9

→ 유형기능분류코드가 같은 의미인데 이름만 바뀌어 9개의 컬럼으로 나뉘어 있음

 

실제 구조 예시

비정규화된 테이블 (1NF 위반 상태)

모뎀코드	모델명	유형기능분류코드1	유형기능분류코드2	유형기능분류코드3
M001	ABC123	WIRELESS	VPN	LTE

→ 기능코드가 컬럼으로 나뉘어 반복됨 → 제1정규형 위반

---

정규화된 테이블 (1NF 만족)

모뎀코드	기능순번	유형기능분류코드
M001	1	WIRELESS
M001	2	VPN
M001	3	LTE

→ 기능 하나당 행(row) 하나 → 원자값 유지 → 제1정규형 만족

 

WHERE절에서 상수로 조건 줄 수 있다는 건 무슨 뜻?

이 말은 단지 "각 컬럼이 독립적으로 쿼리 조건에 쓸 수 있다"는 의미

WHERE A유형기능분류코드1 = 'XXX'

✅ 이건 기술적으로 가능하고, 실행은 됨

하지만 논리적 데이터 모델 설계 관점에서는 잘못된 구조

---

보기 해석

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

🟥 틀렸어요.

• 반복되는 그룹이 컬럼 단위로 존재 → 제1정규형 위반 상태입니다.
• 원자값이어야 하는데, 속성이 컬럼 이름으로 반복됨 → 1NF가 아님

---

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

🟧 불완전한 주장입니다.

• PK 인덱스만으로는 충분하지 않을 수 있음
• 여기서 조회 조건은 유형기능분류코드1~9 각각에 대해 발생
• → 각 컬럼별 인덱스가 있어야 빠름, PK만으로는 부족

---

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

🟥 틀렸어요.

• "이전종속"이라는 말은 이행 종속 또는 부분 종속을 혼동한 표현으로 보임
• 이건 제2정규형과 관련된 개념이 아님
• → 제1정규형도 아직 만족 못한 상태임

---

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

🟩 맞습니다!

• 유형기능분류코드1~9: 컬럼으로 반복 → 제1정규형 위반
• 이대로 인덱스를 각각 다 걸면 → 조회는 빨라질 수 있지만
• → 삽입/수정/삭제 시 성능 저하
• 따라서 먼저 정규화(1NF)를 해서 반복 속성을 행으로 분리한 후 → 필요한 컬럼에만 인덱스 적용하는 것이 좋은 설계