데이터베이스 정규 화 에 대한 설명 . . 관계 형 데이터베이스 의 설계 에서 중복 을 최소 화 하 게 데이터 를 구조 화 하 는 프로세스 를 정규 화 라고 한다 . 데이터베이스 정규 화 의 목표 는 이상 이 있 는 관계 를 재 구성 하 여 작 고 잘 조직 된 관계 를 생성 하 는 것 에 있 다 . 일반 적 으로 정규 화 란 크 고 , 제대로 조직 되 지 않 은 테이블 들 과 관계 들 을 작 고 잘 조직 된 테이블 과 관계 들 로 나누 는 것 을 포함 한다 . 정규 화 의 목적 은 하나 의 테이블 에서 의 데이터 의 삽입 , 삭제 , 변경 이 정의 된 관계 들 로 인하 여 데이터베이스 의 나머지 부분 들 로 전파 되게 하 는 것 이 다 . 관계 형 모델 의 발견자 인 에드거 F . 커드 는 1970 년 에 제 1 정규 화 ( 1 NF ) 로 알려진 정규 화 의 개념 을 도입 하 였 다 . [ 1 ] 에드거 F . 커드 는 이어서 제 2 정규 화 ( 2 NF ) 와 제 3 정규 화 ( 3 NF ) 를 1971 년 에 정의 하 였으며 , [ 2 ] 1974 년 에 는 레이먼드 F . 보이스 와 함께 보이스 - 코드 정규 화 ( BCNF ) 를 정의 하 였 다 . [ 3 ] 4 NF 이상 의 정규 화 는 이후 에 다른 이론가 들 에 의해서 정의 되 었 으며 , 가장 최근 에 소개 된 정규 화 는 2002 년 에 크리스토퍼 J . 데이트 , 허그 다위 , 니코스 로렌츠 에 의해 소개 된 제 6 정규 화 ( 6 NF ) 이 다 . [ 4 ] 비 공식 적 으로 관계 형 데이터베이스 테이블 ( 컴퓨터 공학 적 표현 으로 는 관계 ) 이 제 3 정규 ( 3 NF ) 화 가 되 었 으면 정규 화 되 었 다 라고 한다 . [ 5 ] 3 NF 테이블 의 대부분 이 삽입 , 변경 , 삭제 이상 이 없 으며 , 3 NF 테이블 의 대부분 이 BCNF , 4 NF , 5 NF 이 다 . ( 그러나 일반 적 으로 6 NF 는 아니 다 . ) 데이터베이스 디자인 표준 가이드 는 데이터베이스 가 완전히 정규 화 되 게 디자인 되 어야 한다 ; 그 뒤 에 일부 가 성능 상 의 이유 로 비 정규 화 될 수 는 있 다 . [ 6 ] 그러나 , 데이터 웨어 하우스 디자인 을 위한 관점 모델링 과 같 은 일부 모델링 규칙 에서 는 예외 적 으로 비 정규 화 된 디자인 을 추천 한다 . 즉 대 규모 부분 에서 의 디자인 은 3 NF 가 아니 다 . [ 7 ] 정규 화 의 목적 [ 편집 ] 1970 년 에드거 F . 커드 에 의해 정의 된 제 1 정규 형 의 기본 적 의 목적 은 1 차 논리 에 기반 을 둔 " 보편 적 데이터 부 언어 " 에 의해 데이터 가 질의 되 고 조작 되 게 하 기 위해서 였 다 . [ 8 ] ( SQL 이 이 데이터 부 언어 의 대표 적 인 예 이 지만 , 정작 에드거 F . 커드 는 이 언어 는 심각 한 결함 을 가지 고 있 다고 생각 하 였 다 . ) [ 9 ] 에드거 F . 커드 에 의해 정의 된 제 1 정규 화 ( 1 NF ) 의 목적 은 아래 와 같 다 : 1 . 고려 되 지 않 은 삽입 , 갱신 , 삭제 의존 에서부터 관계 의 집합 을 배제 한다 ; 2 . 새로운 자료 형 이 나타날 때 , 관계 들 의 집합 의 재 구성 의 필요 성 을 낮추 고 , 그 로 인하 여 응용 프로그램 의 생명 주기 를 연장 한다 ; 3 . 사용자 에게 관계 모델 을 더욱 의미 있 게 한다 ; 4 . 관계 들 의 집합 을 질의 의 통계 로부터 중립 적 이 게 한다 . 질의 들 은 시간 이 지남 에 따라 변경 되 기 때문 이 다 ;— E . F . Codd , " Further Normalization of the Data Base Relational Model "[ 10 ] 이 목적 들 을 아래 에서 더욱 자세히 알아본다 . 데이터베이스 의 변경 시 이상 현상 제거 [ 편집 ] 갱신 이상 . Employee 519 는 다른 레코드 에서 다른 주소 를 가지 고 있 다 . 삽입 이상 . 새로운 교수 인 Dr . Newsome 은 최소한 하나 의 코스 를 강의 하 게 되 어 있 지만 , 삽입 하 고자 하 는 새로운 레코드 에 는 없 다 . 삭제 이상 . Dr . Giddens 의 모든 정보 가 그 가 ENG - 206 강의 를 중단 시 삭제 된다 . 테이블 을 수정 ( 갱신 , 삽입 , 삭제 ) 시 , 원치 않 던 부작용 이 발생 할 수 있 다 . 이 부작용 은 충분히 정규 화 되 지 않 은 테이블 에서 발생 할 수 있 다 . 충분히 정규 화 되 지 않 은 테이블 은 아래 와 같 은 특성 들 이 있 다 : 같 은 정보 가 복수 개 의 열 에서 표현 된다 ; 그래서 갱신 은 논리 적 인 모순 을 낳 게 된다 . 예 를 들 어 , " 고용자 의 기술 " 이 라는 테이블 에서 모든 레코드 가 고용자 ID , 고용자 주소 도 포함 하 고 있 다고 하 면 , 특정 고용자 의 주소 변경 시 여러 개 의 레코드 를 수정 하 여야 한다 ( 그 고용자 가 보유 한 모든 기술 만큼 의 레코드 가 수정 되 어야 한다 ) . 성공 적 인 갱신 이 이루어지 지 않 을 경우 - 즉 , 변경 된 고용자 의 주소 가 그 가 가지 고 있 는 기술 레코드 들 중 에서 일부 는 변경 되 었 으나 , 일부 는 변경 되 지 않 을 경우 - " 고용자 의 기술 " 테이블 은 모순 상태 가 된다 . 특히 , 그 특정 고용자 의 주소 가 무엇 인 가 에 대한 질문 에 대해서 혼동 스러운 답안 을 내놓 게 된다 . 이 현상 을 갱신 이상 이 라고 한다 . 어떠 한 특정 사실 은 전혀 기록 되 지 않 는 경우 가 발생 한다 . 예 를 들 어 , " 교수 와 그 들 의 강의 " 라는 테이블 에서 는 교수 ID , 교수 이름 , 교수 고용 일자 , 강의 코드 를 가지 고 있 다고 하 자 . 새 교수 를 고용 하 였을 경우 , 그 가 아직 맡 은 강의 가 없 기 때문 에 강의 코드 를 null 로 하 지 않 는 이상 새 교수 를 테이블 에 추가 할 수 가 없 다 . 이 현상 을 삽입 이상 이 라고 한다 . 데이터 의 삭제 가 전혀 다른 사실 에 대한 데이터 의 삭제 도 필요 로 하 게 되 는 현상 이 있 다 . " 교수 와 그 들 의 강의 " 라는 위 예제 에 도 한 교수 가 임시 로 강의 를 중단 하 고자 할 때 이 이상 현상 이 발생 한다 . 이런 경우 그 가 기록 된 레코드 들 을 삭제 해야 하 는데 , 그럴 경우 교수 자체 가 사라지 게 된다 . 이 현상 을 삭제 이상 이 라고 한다 . 데이터베이스 구조 확장 시 재 디자인 최소 화 [ 편집 ] 정규 화 된 데이터베이스 구조 에서 는 새로운 데이터 형 의 추가 로 인한 확장 시 , 그 구조 를 변경 하 지 않 아도 되 거나 일부 만 변경 해도 되 는 경우 가 있 다 . 이 는 이 데이터베이스 와 연동 된 응용 프로그램 에 최소한 의 영향 만 을 주 며 , 응용 프로그램 의 생명 을 연장 시킨다 . 사용자 에게 데이터 모델 을 더욱 의미 있 게 [ 편집 ] 정규 화 된 테이블 들 과 정규 화 된 테이블 들 간 의 관계 들 은 현실 세계 에서 의 개념 들 과 그 들 간 의 관계 들 을 반영 한다 . 즉 데이터 모델 을 사용 자 에게 더욱 의미 ( informative ) 있 게 한다 . 다양 한 질 의 지원 [ 편집 ] 정규 화 된 테이블 은 일반 적 인 목적 의 질의 에 적합 하 다 . 이 는 테이블 에 대하 여 세부 사항 이 예측 되 지 않 은 장래 의 질의 를 포함 한 어떠 한 질의 도 지원 한다는 의미 이 다 . 반 대로 정규 화 되 지 않 은 테이블 은 ( 향후 발생 할 수 있 는 ) 어떤 질의 들 은 지원 하 지 않 을 수 있 다 . 예 를 들 어서 , 고객 이 가지 고 싶 은 책 들 의 목록 을 가지 고 있 는 온라인 서점 을 생각 해 보 자 . 분명 하 게 예상 되 는 질의 -- 고객 이 원 하 는 책 은 무엇 인가 ? -- 는 고객 이 가지 고 싶 은 책 들 의 목록 테이블 에 저자 와 제목 이 있 으면 된다 . 이 테이블 디자인 은 그 한 질의 에 대해서 는 답 할 수 있 다 . 그러나 다른 예상 되 거나 관심 있 는 질의 들 은 답 할 수 없 다 : 고객 들 이 가장 선호 하 는 책 은 ? 어떤 고객 들 이 2 차 세계 대전 스파이 들 에 대해서 관심 있 는가 ? 이 질의 에 대한 답 을 구하 기 위해서 는 데이터베이스 와 완전히 분리 되 어 이 질의 를 다루 는 소프트웨어 를 구현 하 여야 하 며 , 이 소프트웨어 의 목표 는 한 가지 이 다 : 비 정규 화 된 항목 을 정규 화 한다 . 정규 화 된 테이블 에서 는 예측 되 지 않 는 질의 라고 하 여도 순전히 데이터베이스 의 테두리 안 에서 쉽 게 답변 이 가능 하 다 . 예제 [ 편집 ] 고객 들 의 신용 카드 사용 내역 을 표현 한 테이블 을 가정 하 자 . 이 테이블 이 제 1 정규 화 가 안 되 었 을 경우 , 데이터 의 질의 와 조작 은 필요 이상 으로 복잡 해진다 : 고객 사용 내역 강지영 거래 번호 일자 잔고 128902010 - 10 - 14 − 87129042010 - 10 - 15 − 50 구하라 거래 번호 일자 잔고 128982010 - 10 - 14 − 21 한승연 거래 번호 일자 잔고 129072010 - 10 - 15 − 18149202010 - 11 - 20 − 70150032010 - 11 - 27 − 60 각 고객 들 마다 , 거래 의 반복 이 있 다 . 그래서 고객 의 거래 에 대한 질의 에 답 하 기 위해서 는 아래 의 2 단계 가 필요 하 다 : 각 거래 들 을 조사 하 기 위해서 하나 이상 의 고객 들 의 거래 들 의 모임 으로부터 각 거래 를 추출 하 여 그룹 화위 첫 단계 의 결과 로부터 질의 의 결과 를 도출 예 를 들 어서 , 모든 고객 들 에 대하 여 2010 년 10 월 에 이루어진 모든 거래 의 거래량 ( 돈 ) 의 합 을 구하 기 위해서 는 : 각 고객 들 로부터 고객 들 의 거래 의 모임 을 각 거래 들 로 추출 일자 가 2010 년 10 월 인 거래 들 의 잔고 의 합 을 구한다 . 에드거 F . 커드 는 이러 한 데이터 구조 의 복잡 성 이 완전히 제거 되 었 을 때 질의 가 ( 사용자 와 응용 프로그램 에 의해서 ) 표현 되 고 ( DBMS 에 의해서 ) 수행 됨 에 있 어서 더욱 강력 하 고 유연 해진다고 보 았 다 . 위 구조 를 정규 화 하 면 아래 와 같 다 : 고객 거래 번호 일자 잔고 강지영 128902010 - 10 - 14 − 87 강지영 129042010 - 10 - 15 − 50 구하라 128982010 - 10 - 14 − 21 한승연 129072010 - 10 - 15 − 18 한승연 149202010 - 11 - 20 − 70 한승연 150032010 - 11 - 27 − 60 이제 각 열 은 각 신용 카드 거래 를 의미 하 며 , DBMS 는 위 질의 에 대해서 2010 년 10 월 에 해당 하 는 모든 열 을 구해서 그 들 의 잔고 를 합하 면 된다 . 이 데이터 구조 는 모든 값 이 동등 한 입장 을 가지 며 , DBMS 에 직접 적 으로 반영 되 어 질의 에 잠재 적 으로 참여 할 수 있 게 된다 ; 이전 의 상황 에서 는 각 값 이 하위 레벨 구조 로 묶여서 질의 시 따로 취급 되 어야 했 다 . 이런 이유 로 정규 화 된 디자인 은 일반 적 인 목적 의 질의 에 적합 하 며 , 비 정규 화 된 디자인 은 그렇 지 않 다 . 배경 지식 : 정의 [ 편집 ] 함수 종속 성 관계 스키마 중 에서 어느 속성 군 의 값 이 정해 지 면 다른 속성 군 의 값 이 정해 지 는 것 . A , B 가 각각 관계 R 의 속성 인 경우 , 임의 시점 에서 A 의 어떤 값 도 반드시 B 의 하나 의 값 에 대응 되 지만 , B 의 하나 의 값 이 A 의 복수 의 값 에 대응 되 는 경우 에 B 는 A 에 함수 종속 이 라고 하 며 A → B 와 같이 표기 한다 . 예 를 들 어 , " 고용자 " 테이블 이 " 고용자 ID " 속성 과 " 고용자 생일 " 속성 을 가질 때 , { 고용자 ID }->{ 고용자 생일 } 또는 { 고용자 생일 } 은 { 고용자 ID } 에 함수 종속 이 다 . 실제로 는 { 고용자 생일 } 이 null 이거 나 어떤 { 고용자 생일 } 에 도 대응 되 지 않 을 수 있 으므로 맞 지 않 을 수 도 있 으나 , 여기 에서 는 { 고용자 ID } 는 정확히 하나 의 { 고용자 생일 } 만 갖 는다고 가정 한다 . 자명 한 함수 종속 성 속성 들 의 부분집합 이 함수 종속 성 을 가질 때 , 자명 한 함수 종속 성 이 라고 한다 . { 고용자 ID }->{ 고용자 생일 } 이면 { 고용자 ID , 고용자 주소 }->{ 고용자 생일 } 은 자명 하 다 . 전 함수 종속 성 A , B 가 각각 관계 R 의 속성 이 고 B 가 A 에 함수 종속 ( A → B ) 인 경우 , A 의 임의 의 부분 집합 에 대하 여 B 의 어떤 값 도 A 의 부분 집합 의 값 에 대응 하 지 않 으면 B 는 A 에 전 함수 종속 이 라고 한다 . 추이 종속 성 A , B , C 가 각각 관계 R 에 상호 중복 되 지 않 는 속성 ( 다만 , A 는 1 차 키 이외 의 속성 ) 인 경우 에 , A 가 B 에 함수 종속 적 이 아니 면 이때 C 는 A 에 추이 종속 이 라고 한다 . 제 2 정규 형 ( 2 NF ) 의 관계 에 추이 종속 성 이 있 는 경우 , 그것 을 배제 하 고 분해 한 관계 를 제 3 정규 형 ( 3 NF ) 이 라고 한다 . A -> B 이 고 B -> C 일 경우 에 만 A -> C 이 면 추이 종속 이 라고 한다 . 다 치 종속 성 다 치 종속 성 은 어떤 레코드 의 존재 가 다른 레코드 의 존재 로 이어짐 을 의미 한다 . 조인 종속 테이블 T 가 T 의 속성 의 부분 집합 을 가지 는 여러 개 의 테이블 들 을 조인 하 여 만들 어 질 수 있 을 때 , T 는 조인 종속 성 을 가진다고 한다 . 슈퍼 키 슈퍼 키 는 레코드 를 유일 하 게 식별 해낼 수 있 는 속성 들 의 집합 이 다 . 한 개 의 테이블 은 여러 개 의 슈퍼 키 를 가질 수 있 다 . 후보 키 후보 키 는 슈퍼 키 에서 레코드 를 유일 하 게 식별 하 는데 있 어서 필요 없 는 속성 을 제거 한 슈퍼 키 의 부분집합 이 다 . 예제 : { 이름 },{ 나이 },{ 주민 등록 번호 },{ 전화 번호 } 속성 을 가지 는 테이블 에서 슈퍼 키 는 { 주민 등록 번호 }, { 전화 번호 , 이름 }, { 주민 등록 번호 , 이름 } 3 개 이 다 . 이 들 중 { 주민 등록 번호 } 가 후보 키 이 며 , 나머지 속성 들 은 레코드 를 유일 하 게 식별 하 는데 있 어서 는 필요 없 는 속성 들 이 다 . 비 일 차 속성 비 일 차 속성 은 어떤 후보 키 에 도 나타나 지 않 는 속성 이 다 . { 이름 },{ 나이 },{ 주민 등록 번호 },{ 전화 번호 } 속성 을 가지 는 테이블 에서 { 나이 } 는 비 일 차 속성 이 다 . 일 차 키 관계 데이터베이스 ( RDB ) 에서 관계 ( 데이터베이스 테이블 ) 내 의 특정 투 플 ( 열 ) 을 일의 적 으로 식별 할 수 있 는 키 필드 . 주 키 ( major key ) 라고 도 한다 . 파일 에서 특정 레코드 를 검색 하 거나 레코드 들 을 정렬 할 때 우선 적 으로 참조 된다 . 관계 내 의 키 필드 가 하나 밖에 없 을 때 에 는 자동 적 으로 그 관계 의 일차 키 가 된다 . 그러나 하나 의 관계 내 에 복수 의 키 가 있 을 때 에 는 그 중 의 하나 를 일차 키로 지정 해야 한다 . 일차 키로 지정 되 지 않 은 키 를 대체 키 ( alternate key ) 라고 한다 . 출처 는 전량 위키백과 입니다 . 공유 하 기 글 요소