정보처리기사 실기 정규화와 함수 종속 | 복합키·2정규형·3정규형 예제

이 글은 LIFE ARCHITECTURE의 WORK 카테고리 ‘일하며 공부하는 구조’ 기록입니다. 퇴근 후 짧은 시간에 자격증 공부를 이어가려면 의지보다 ‘한 번에 끝낼 수 있는 작은 단위’로 공부를 쪼개는 구조가 필요합니다. 이번에는 수강 기록 표의 함수 종속을 찾아 2정규형과 3정규형으로 나누고, 다시 연결했을 때 원래 기록이 복원되는지 살펴봅니다.

공부를 시작하며 ‘학생·강좌·강사’가 한 표에 모인 문제를 보면 열이 많다는 사실보다 무엇이 무엇을 결정하는지가 먼저 눈에 들어와야 한다. 정규화는 열을 무작정 나누는 일이 아니다. 한 행이 나타내는 대상을 정하고, 키의 일부에만 의존하는 값과 다른 일반 열을 거쳐 결정되는 값을 분리하는 과정이다. 아래 표와 문제는 설명을 위해 만든 독자적인 연습 예제다.

한 행이 ‘학생의 강좌 수강 한 건’임을 먼저 정한다

가상의 수강 기록에서 학생번호 S01인 민서는 강좌 C10과 C20을 듣고, S02인 준은 C10을 듣는다. 한 행은 학생 한 명의 전체 정보가 아니라 특정 학생이 특정 강좌를 수강한 한 건이다. 같은 학생이 여러 강좌를 듣고 같은 강좌에 여러 학생이 등록할 수 있으므로, 이 예제의 수강 행은 학생번호와 강좌번호를 함께 써야 유일해진다. 성적은 바로 그 조합에 붙는다.

학생번호	강좌번호	학생명	강좌명	강사번호	강사명	성적
S01	C10	민서	DB 기초	T7	지윤	A
S02	C10	준	DB 기초	T7	지윤	B
S01	C20	민서	SQL 실습	T8	소라	A

이 표에서는 각 칸에 하나의 값이 들어 있고 학생명1·학생명2처럼 반복되는 열도 두지 않았다. 따라서 여기서는 제1정규형을 만족한다고 가정하고 다음 단계를 본다. 제1정규형을 설명할 때 ‘원자적’이라는 말만 외우기보다 한 칸에 여러 강좌를 쉼표로 넣지 않는다고 생각하면 판단이 쉬워진다. 실제 데이터베이스 설계에서는 이름이 중복될 수 있으므로 학생명은 학생번호를 대신하는 키가 아니다.

함수 종속 화살표는 데이터의 업무 규칙에서 나온다

X → Y는 X의 값이 같으면 Y의 값도 하나로 정해진다는 뜻이다. 이 예제에서는 학생번호 → 학생명, 강좌번호 → 강좌명·강사번호, 강사번호 → 강사명, (학생번호, 강좌번호) → 성적이라는 규칙을 둔다. 이는 표에 우연히 세 행만 있어서 관찰된 패턴이 아니라, 해당 학사 업무에서 지키기로 한 조건이다. 예를 들어 강좌 한 개를 강사 여러 명이 함께 맡는 체계라면 강좌번호 → 강사번호라는 규칙부터 다시 세워야 한다.

결정자와 종속 열을 읽을 때 화살표의 방향을 거꾸로 돌리지 않는다. 강사번호가 같으면 강사명이 같지만, 동명이인이 있을 수 있으므로 강사명으로 강사번호가 하나로 정해진다고 말할 수 없다. 성적 A를 받은 행도 여러 개이므로 성적이 학생과 강좌를 결정하지 않는다. 반대로 학생번호 하나만으로는 어느 강좌에서 받은 성적인지 알 수 없고, 강좌번호 하나만으로도 어느 학생의 성적인지 알 수 없다.

복합키의 절반에만 달린 열을 떼면 제2정규형이다

원래 표의 후보키를 (학생번호, 강좌번호)로 놓으면 학생명은 그중 학생번호에만 달려 있다. 강좌명과 강사번호, 이 예제의 강사명은 강좌번호만 알면 따라 나온다. 이는 복합키 전체가 아닌 진부분집합에 의존하는 부분 함수 종속이다. 성적은 두 번호가 함께 있어야 정해지므로 수강 기록에 남긴다.

따라서 학생(학생번호, 학생명), 강좌(강좌번호, 강좌명, 강사번호, 강사명), 수강(학생번호, 강좌번호, 성적)으로 먼저 나눌 수 있다. 학생 S01의 이름을 바꾸는 일이 생겨도 학생 표의 한 행만 고치면 된다. 강좌 C10을 듣는 학생이 늘어나더라도 강좌명이 수강 행마다 되풀이되지 않는다. 다만 강좌 표의 강사번호와 강사명 사이에는 아직 한 단계 더 검토할 관계가 남아 있다.

강사번호를 거쳐 정해지는 이름은 제3정규형에서 분리한다

강좌 표에서는 강좌번호 → 강사번호이고 강사번호 → 강사명이다. 강사명은 강좌의 키에서 일반 열인 강사번호를 거쳐 결정된다. 이 예제에서 강사명이 키를 구성하지 않는다면 이행 함수 종속을 제거하는 것이 제3정규형으로 가는 단계다. 강좌(강좌번호, 강좌명, 강사번호)와 강사(강사번호, 강사명)로 나누고, 앞의 학생·수강 표는 그대로 둔다.

최종 구조는 학생(학생번호, 학생명), 강사(강사번호, 강사명), 강좌(강좌번호, 강좌명, 강사번호), 수강(학생번호, 강좌번호, 성적) 네 표다. 학생번호와 강좌번호의 조합은 수강 표의 키가 되고, 강좌의 강사번호는 강사 표의 키를 가리킨다. 강사 T7이 강좌를 두 개 맡더라도 이름을 강좌마다 복사하지 않는다. 이름 변경이나 오타 수정이 한곳에서 이루어지는 이유가 여기에 있다.

표를 나눈 뒤 다시 연결하는 감각이 필요하다면 앞서 공개한 SQL JOIN과 NULL을 예제 표로 읽는 글의 ‘한 행이 무엇을 뜻하는가’부터 다시 살펴볼 수 있다. 오늘의 네 표도 학생번호·강좌번호·강사번호라는 연결 고리가 있어야 원래 수강 정보를 읽을 수 있다.

나눈 표를 다시 연결해 원래 세 행을 검산한다

학생 표에는 S01·민서와 S02·준, 강사 표에는 T7·지윤과 T8·소라가 남는다. 강좌 표에는 C10·DB 기초·T7과 C20·SQL 실습·T8이 있고, 수강 표에는 (S01,C10,A), (S02,C10,B), (S01,C20,A)가 있다. 수강 행 S01·C10을 학생번호로 학생 표에, 강좌번호로 강좌 표에 연결하고, 그 강좌의 강사번호 T7을 강사 표에 연결하면 처음 표의 민서·DB 기초·지윤·A가 돌아온다. 나머지 두 수강 행도 같은 방식으로 복원된다.

이 예제에서 분해를 검산할 때는 수강 표의 키 조합 세 개가 그대로 유지되는지, 각 번호가 참조하는 학생·강좌·강사가 한 행으로 정해지는지 확인한다. 명칭만 비슷한 열을 임의로 연결하면 새로운 조합이 생기거나 행이 빠질 수 있다. 정규형 이름을 답으로 적는 순간보다 이 연결을 설명하는 순간에 구조가 분명해진다.

키와 종속을 혼동하기 쉬운 지점을 따로 표시한다

첫째, 복합키라고 해서 표의 모든 열이 반드시 키 전체에 의존하는 것은 아니다. 부분 종속이 있다면 제2정규형을 다시 확인한다. 둘째, 학생번호 → 학생명처럼 키의 한쪽에서 값이 정해질 때 ‘학생명 → 학생번호’도 성립한다고 추측하지 않는다. 셋째, 강사명처럼 사람이 읽는 이름을 고유 번호와 혼동하지 않는다. 넷째, 이미 제2정규형으로 나눈 뒤에도 강좌번호 → 강사번호 → 강사명이라는 경로가 남았는지 살핀다.

이 사례는 관계의 업무 규칙을 명시해 둔 단순 모델이다. 수강 이력에 학기별 재수강이 들어오면 (학생번호, 강좌번호)만으로 행이 유일하지 않을 수 있다. 그때는 학기나 수강번호를 포함해 키를 다시 정해야 한다. 정규화 문제에서 가장 먼저 적어야 할 것은 ‘몇 정규형인가’보다 ‘이 표의 한 행과 유일한 식별자가 무엇인가’다.

작은 연습은 화살표를 직접 그린 뒤 표를 나눈다

자체 연습문제다. 프로젝트 참여(사원번호, 프로젝트번호, 사원명, 프로젝트명, 역할) 표에서 한 행은 한 사원의 특정 프로젝트 참여라고 가정한다. 각 사원번호가 한 사원명을, 각 프로젝트번호가 한 프로젝트명을 정하고, 역할은 두 번호의 조합으로 정해진다. 다른 종속은 없다고 하자. 후보키와 부분 종속을 찾고 제2정규형까지 분해해 보자.

후보키는 (사원번호, 프로젝트번호)다. 사원번호 → 사원명과 프로젝트번호 → 프로젝트명은 키 일부에만 의존한다. 따라서 사원(사원번호, 사원명), 프로젝트(프로젝트번호, 프로젝트명), 참여(사원번호, 프로젝트번호, 역할)로 나눈다. 역할을 사원 표로 옮기면 한 사람이 프로젝트마다 다른 역할을 맡을 수 있다는 조건을 잃는다. 이 예제에는 역할이 다른 일반 열을 거쳐 결정된다는 규칙을 주지 않았으므로 별도의 제3정규형 분해를 만들어내지 않는다.

복습은 표를 외우기보다 결정 규칙을 점검한다

다음 순서로 한 번만 직접 적어 보면 된다.

• 한 행이 나타내는 사건이나 대상을 한 문장으로 쓴다.
• 중복 없이 행을 구분하는 후보키를 찾고, 업무 규칙으로 성립하는 함수 종속만 화살표로 적는다.
• 복합키 일부에만 의존하는 일반 열을 분리해 제2정규형을 확인한다.
• 일반 열을 거쳐 결정되는 일반 열이 남았는지 보고 제3정규형을 확인한다.
• 분해한 표를 키로 연결해 원래 사례의 행을 다시 읽어 본다.

Q. 기본키가 하나의 열이면 제2정규형 검토는 끝인가?
하나의 열로 된 후보키에는 그 키의 진부분집합이 없으므로 그 키에 대한 부분 종속은 없다. 다만 제1정규형을 만족하는지, 다른 후보키가 있는지, 제3정규형에서 볼 이행 종속이 있는지는 별개의 질문이다.

Q. 표를 나누면 조회할 때 반드시 더 빠른가?
정규화의 주된 목표는 중복과 삽입·수정·삭제 이상을 줄여 일관성을 다루기 쉽게 하는 것이다. 여러 표를 읽어야 하는 조회에는 조인이 필요할 수 있다. 실제 성능은 데이터와 인덱스, 질의 조건을 따로 측정해야 한다.

Q. 표에 같은 값이 두 번 보이면 곧바로 함수 종속인가?
아니다. 현재 보이는 몇 행의 우연한 패턴은 전체 업무 규칙을 증명하지 못한다. ‘강좌번호 하나에 담당 강사번호가 언제나 하나인가’처럼 실제로 보장하는 조건을 먼저 확인한다. 강좌에 공동 강사가 생길 수 있다면 관계와 키를 다시 모델링한다.

Q-Net의 정보처리기사 종목 안내에서 2026년 적용 출제기준 안내와 실기 과목 ‘정보처리 실무’를 확인했다. 함수 종속, 부분 종속과 이행 종속의 설명은 IBM의 데이터베이스 정규화 안내와 대조했다. 자료 확인일은 2026년 10월 12일이다. 위 학생·강좌·프로젝트 표는 실제 기출이나 학사 자료가 아닌 설명용 사례다.

오늘 한 장에 네 개의 화살표만 적어 보자. 표를 잘게 나누는 것보다 먼저, 어떤 값이 다른 값을 책임지고 있는지 분명히 하는 연습이다. 그렇게 읽으면 복잡한 표에도 다시 시작할 자리가 생긴다.