위키백과

데이터베이스 정규화

(제 6 정규형에서 넘어옴)

관계형 데이터베이스의 설계에서 중복을 최소화하게 데이터를 구조화하는 프로세스를 정규화(Normalization)라고 한다. 데이터베이스 정규화의 목표는 이상이 있는 관계를 재구성하여 작고 잘 조직된 관계를 생성하는 것에 있다. 일반적으로 정규화란 크고, 제대로 조직되지 않은 테이블들과 관계들을 작고 잘 조직된 테이블과 관계들로 나누는 것을 포함한다. 정규화의 목적은 하나의 테이블에서의 데이터의 삽입, 삭제, 변경이 정의된 관계들로 인하여 데이터베이스의 나머지 부분들로 전파되게 하는 것이다.

관계형 모델의 발견자인 에드거 F. 커드는 1970년에 제 1 정규화(1NF)로 알려진 정규화의 개념을 도입하였다.[1] 에드거 F. 커드는 이어서 제 2 정규화(2NF)와 제 3 정규화(3NF)를 1971년에 정의하였으며,[2] 1974년에는 레이먼드 F. 보이스와 함께 보이스-코드 정규화(BCNF)를 정의하였다.[3] 4NF 이상의 정규화는 이후에 다른 이론가들에 의해서 정의되었으며, 가장 최근에 소개된 정규화는 2002년에 크리스토퍼 J. 데이트, 허그 다위, 니코스 로렌츠에 의해 소개된 제 6 정규화(6NF)이다.[4]

비공식적으로 관계형 데이터베이스 테이블(컴퓨터 공학적 표현으로는 관계)이 제 3 정규(3NF)화가 되었으면 정규화되었다라고 한다.[5] 3NF 테이블의 대부분이 삽입, 변경, 삭제 이상이 없으며, 3NF 테이블의 대부분이 BCNF, 4NF, 5NF이다.(그러나 일반적으로 6NF는 아니다.)

데이터베이스 디자인 표준 가이드는 데이터베이스가 완전히 정규화되게 디자인되어야 한다; 그 뒤에 일부가 성능상의 이유로 비정규화될 수는 있다.[6] 그러나, 데이터 웨어하우스 디자인을 위한 관점 모델링과 같은 일부 모델링 규칙에서는 예외적으로 비 정규화된 디자인을 추천한다. 즉 대규모 부분에서의 디자인은 3NF가 아니다.[7]

정규화의 목적 편집

1970년 에드거 F. 커드에 의해 정의된 제 1 정규형의 기본적 목적은 1차 논리에 기반을 둔 "보편적 데이터 부언어"에 의해 데이터가 질의되고 조작되게 하기 위해서였다.[8] (SQL이 이 데이터 부언어의 대표적인 예이지만, 정작 에드거 F. 커드는 이 언어는 심각한 결함을 가지고 있다고 생각하였다.)[9]

에드거 F. 커드에 의해 정의된 제 1 정규화(1NF)의 목적은 아래와 같다.

1. 고려되지 않은 삽입, 갱신, 삭제 의존에서부터 관계의 집합을 배제한다.
2. 새로운 자료형이 나타날 때, 관계들의 집합의 재구성의 필요성을 낮추고, 그로 인하여 응용 프로그램의 생명주기를 연장한다.
3. 사용자에게 관계 모델을 더욱 의미있게 한다.
4. 관계들의 집합을 질의의 통계로부터 중립적이게 한다. 질의들은 시간이 지남에 따라 변경되기 때문.
—E.F. Codd, "Further Normalization of the Data Base Relational Model"[10]

이 목적들을 아래에서 더욱 자세히 알아본다.

데이터베이스의 변경시 이상 현상 제거 편집

 
갱신 이상. Employee 519는 다른 레코드에서 다른 주소를 가지고 있다.
 
삽입 이상. 신입 교수인 Dr. Newsome은 아직 수업을 배정받지 않았다는 이유로 교수 정보를 관리하는 이 테이블에 Newsome 교수 레코드를 삽입할 수가 없다.
 
삭제 이상. ENG-206 수업이 끝나 해당 레코드를 삭제하면, Dr. Giddens 교수의 모든 정보가 삭제된다.

테이블 수정(갱신, 삽입, 삭제)시, 원치 않던 부작용이 발생할 수 있다. 이 부작용은 충분히 정규화되지 않은 테이블에서 발생할 수 있는데, 충분히 정규화 되지 않은 테이블은 아래와 같은 특성들이 있다:

  • 같아야 하는 정보가 복수 개의 행에서 표현되면, 갱신 시 논리적인 모순을 초래할 수 있다. 예를 들어, ＂직원 보유기술"이라는 테이블에서 모든 레코드가 직원 ID, 직원 보유기술, 직원 주소를 포함하고 있다고 하면, 특정 직원의 주소 변경 시 여러 개의 레코드를 함께 수정해야 한다(그 직원이 보유한 모든 보유기술에 대해 레코드가 수정되어야 한다). 성공적인 갱신이 이루어지지 않을 경우-즉, 변경된 직원의 주소가 그가 가지고 있는 레코드 중에서 일부는 변경되었으나, 일부는 변경되지 않을 경우- "직원 보유기술" 테이블은 모순 상태가 된다. 즉, 그 특정 직원의 주소가 무엇인가에 대한 질문에 대해서 혼동스러운 답안을 내놓게 된다. 이런 현상을 갱신 이상이라고 한다.
  • “교수와 그들의 강의”라는 테이블에서 교수 ID, 교수 이름, 교수 임용일자, 수업 코드를 가지고 있다고 하자. 새 교수를 임용하였을 경우, 그가 맡은 강의가 없으면 수업 코드가 널(빈값)이어서 수업 코드가 식별컬럼(널 비허용)인 이 테이블에 추가할 수가 없게 되는데, 이런 현상을 삽입 이상이라고 한다.
  • 어떤 정보를 삭제하는데, 삭제되면 안 되는 다른 사실이 함께 삭제되는 현상이 있을 수 있다. 예를 들어, “교수와 그들의 강의”라는 위 예제에서 Dr. Griddens 교수가 ENG-206 수업을 임시로 중단하고자 하면, 이런 이상현상이 발생한다. 다시 말해 그가 맡은 수업 정보가 기록된 레코드들을 삭제하는 경우, 교수 정보 전체가 사라지게 되는데, 이런 현상을 삭제 이상이라고 한다.

데이터베이스 구조 확장시 재 디자인 최소화 편집

정규화된 데이터베이스 구조에서는 새로운 데이터 형의 추가로 인한 확장시, 그 구조를 변경하지 않아도 되거나 일부만 변경해도 되는 경우가 있다. 이는 이 데이터베이스와 연동된 응용 프로그램에 최소한의 영향만을 주며, 응용 프로그램의 생명을 연장시킨다.

사용자에게 데이터 모델을 더욱 의미있게 편집

정규화된 테이블들과 정규화된 테이블들간의 관계들은 현실세계에서의 개념들과 그들간의 관계들을 반영한다. 즉 데이터 모델을 사용자에게 더욱 의미(informative)있게 한다.

다양한 질의 지원 편집

정규화된 테이블은 일반적인 목적의 질의에 적합하다. 이는 테이블에 대하여 세부사항이 예측되지 않은 장래의 질의를 포함한 어떠한 질의도 지원한다는 의미이다. 반대로 정규화되지 않은 테이블은 (향후 발생할 수 있는) 어떤 질의들은 지원하지 않을 수 있다.

예를 들어서, 고객이 가지고 싶은 책들의 목록을 가지고 있는 온라인 서점을 생각해보자. 분명하게 예상되는 질의 -- 고객이 원하는 책은 무엇인가? --는 고객이 가지고 싶은 책들의 목록 테이블에 저자와 제목이 있으면 된다.

이 테이블 디자인은 그 한 질의에 대해서는 답할 수 있다. 그러나 다른 예상되거나 관심있는 질의들은 답할 수 없다: 고객들이 가장 선호하는 책은? 어떤 고객들이 2차 세계대전 스파이들에 대해서 관심있는가? 이 질의에 대한 답을 구하기 위해서는 데이터베이스와 완전히 분리되어 이 질의를 다루는 소프트웨어를 구현하여야 하며, 이 소프트웨어의 목표는 한가지이다: 비 정규화된 항목을 정규화한다.

정규화된 테이블에서는 예측되지 않는 질의라고 하여도 순전히 데이터베이스의 테두리 안에서 쉽게 답변이 가능하다.

예제 편집

고객들의 신용카드 사용 내역을 표현한 테이블을 가정하자. 이 테이블이 제 1 정규화가 안 되었을 경우, 데이터의 질의와 조작은 필요 이상으로 복잡해진다:

고객 사용내역
홍길동
거래번호 일자 잔고
12890 2010-10-14 −87
12904 2010-10-15 −50
최철수
거래번호 일자 잔고
12898 2010-10-14 −21
한영미
거래번호 일자 잔고
12907 2010-10-15 −18
14920 2010-11-20 −70
15003 2010-11-27 −60

각 고객들마다, 거래의 반복이 있다. 그래서 고객의 거래에 대한 질의에 답하기 위해서는 아래의 2단계가 필요하다:

  1. 각 거래들을 조사하기 위해서 하나 이상의 고객들의 거래들의 모임으로부터 각 거래를 추출하여 그룹화
  2. 위 첫 단계의 결과로부터 질의의 결과를 도출

예를 들어서, 모든 고객들에 대하여 2010년 10월에 이루어진 모든 거래의 거래량(돈)의 합을 구하기 위해서는 :

  1. 각 고객들로부터 고객들의 거래의 모임을 각 거래들로 추출
  2. 일자가 2010년 10월인 거래들의 잔고의 합을 구한다.

에드거 F. 커드는 이러한 데이터 구조의 복잡성이 완전히 제거되었을 때 질의가 (사용자와 응용 프로그램에 의해서)표현되고 (DBMS에 의해서) 수행됨에 있어서 더욱 강력하고 유연해진다고 보았다. 위 구조를 정규화하면 아래와 같다:

고객 거래번호 일자 잔고
홍길동 12890 2010-10-14 −87
홍길동 12904 2010-10-15 −50
최철수 12898 2010-10-14 −21
한영미 12907 2010-10-15 −18
한영미 14920 2010-11-20 −70
한영미 15003 2010-11-27 −60

이제 각 행은 각 신용카드 거래를 의미하며, DBMS는 위 질의에 대해서 2010년 10월에 해당하는 모든 행을 구해서 그들의 잔고를 합하면 된다. 이 데이터 구조는 모든 값이 동등한 입장을 가지며, DBMS에 직접적으로 반영되어 질의에 잠재적으로 참여할 수 있게 된다; 이전의 상황에서는 각 값이 하위 레벨 구조로 묶여서 질의시 따로 취급되어야 했다. 이런 이유로 정규화된 디자인은 일반적인 목적의 질의에 적합하며, 비정규화된 디자인은 그렇지 않다.

배경 지식 : 정의 편집

함수 종속성
관계 스키마 중에서 어느 속성군의 값이 정해지면 다른 속성군의 값이 정해지는 것. A, B가 각각 관계 R의 속성인 경우, 임의 시점에서 A의 어떤 값도 반드시 B의 하나의 값에 대응되지만, B의 하나의 값이 A의 복수의 값에 대응되는 경우에 B는 A에 함수 종속이라고 하며 A→B와 같이 표기한다. 예를 들어, "직원" 테이블이 "직원 ID" 속성과 "직원 생일" 속성을 가질 때, {직원 ID}->{직원 생일} 또는 {직원 생일}은 {직원 ID}에 함수 종속이다. 실제로는 {직원 생일}이 null 이거나 어떤 {직원 생일}에도 대응되지 않을 수 있으므로 맞지 않을 수도 있으나, 여기에서는 {직원 ID}는 정확히 하나의 {직원 생일}만 갖는다고 가정한다.
자명한 함수 종속성
속성들의 부분집합이 함수 종속성을 가질때, 자명한 함수 종속성(FD)이라고 한다. {직원 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정규형(2NF)의 관계에 이행함수 종속성이 있는 경우, 그것을 배제하고 분해한 관계를 제3정규형(3NF)이라고 한다. A->B 이고 B->C 일 경우에만 A->C 이면 이행함수(적) 종속이라고 한다.
다치 종속성
다치 종속성(MVD)은 어떤 레코드의 존재가 다른 레코드의 존재로 이어짐을 의미한다. 다치종속성은->>으로 표시하는데, R｛A,B,C｝일 때 (A,C)->>｛B｝≡(A) ->｛B｝ 성립한다. , A->>B이면 A->>C도 성립하고 A->>B│C이다. (Fagin정리에 따라) R｛A,B,C｝에서 다치종속 A->>B│C이면 R1｛A,B｝와 R2｛A,C｝로 무손실 분해가 가능하다. 이를 제4정규형(4NF)의 관계에 있다고 말한다.
조인 종속
조인종속(JD)는 릴레이션 R이 그의 프로젝션 A,B,.....,Z의 조인과 동일하면 R은 JD*(A,B,....,Z )를 만족한다. 이때 A,B,....,Z는 R의 애트리뷰트에 대한 부분집합이다. 다시말해서 테이블 R이 R의 속성의 부분집합을 가지는 여러 개의 테이블들을 조인하여 만들어질 수 있을 때, R은 조인 종속성을 가진다고 한다. 이를 제5정규형(5NF)이라고 한다.
슈퍼 키
슈퍼키는 레코드를 유일하게 식별해낼 수 있는 속성들의 집합이다. 한 개의 테이블은 여러 개의 슈퍼키를 가질 수 있다.
후보 키
후보 키는 슈퍼 키에서 레코드를 유일하게 식별하는데 있어서 필요없는 속성을 제거한 슈퍼 키의 부분집합이다.

예제 : {이름},{나이},{주민등록 번호},{전화번호} 속성을 가지는 테이블에서 슈퍼키는 {주민등록 번호}, {전화번호, 이름}, {주민등록 번호, 이름} 3개이다. 이들중 {주민등록 번호}가 후보 키이며, 나머지 속성들은 레코드를 유일하게 식별하는데 있어서는 필요없는 속성들이다.

비일차 속성
비일차 속성은 어떤 후보 키에도 나타나지 않는 속성이다. {이름},{나이},{주민등록 번호},{전화번호} 속성을 가지는 테이블에서 {나이}는 비일차 속성이다.
일차키
관계 데이터베이스(RDB)에서 관계(데이터베이스 테이블) 내의 특정 투플(열)을 일의적으로 식별할 수 있는 키 필드. 주 키(major key)라고도 한다. 파일에서 특정 레코드를 검색하거나 레코드들을 정렬할 때 우선적으로 참조된다. 관계 내의 키 필드가 하나밖에 없을 때에는 자동적으로 그 관계의 일차 키가 된다. 그러나 하나의 관계 내에 복수의 키가 있을 때에는 그중의 하나를 일차 키로 지정해야 한다. 일차 키로 지정되지 않은 키를 대체 키(alternate key)라고 한다.

인용 자료 편집

  1. ↑ Codd, E.F. (1970년 6월). “A Relational Model of Data for Large Shared Data Banks”. 《Communications of the ACM》 13 (6): 377–387. doi:10.1145/362384.362685. 2007년 6월 12일에 원본 문서에서 보존된 문서. 2007년 6월 12일에 확인함. 
  2. ↑ Codd, E.F. "Further Normalization of the Data Base Relational Model." (Presented at Courant Computer Science Symposia Series 6, "Data Base Systems," New York City, May 24th-25th, 1971.) IBM Research Report RJ909 (August 31st, 1971). Republished in Randall J. Rustin (ed.), Data Base Systems: Courant Computer Science Symposia Series 6. Prentice-Hall, 1972.
  3. ↑ Codd, E. F. "Recent Investigations into Relational Data Base Systems." IBM Research Report RJ1385 (April 23rd, 1974). Republished in Proc. 1974 Congress (Stockholm, Sweden, 1974). , N.Y.: North-Holland (1974).
  4. ↑ C.J. Date, Hugh Darwen, Nikos Lorentzos. Temporal Data and the Relational Model. Morgan Kaufmann (2002), p. 176
  5. ↑ C.J. Date. An Introduction to Database Systems. Addison-Wesley (1999), p. 290
  6. ↑ Chris Date, for example, writes: "I believe firmly that anything less than a fully normalized design is strongly contraindicated ... [Y]ou should "denormalize" only as a last resort. That is, you should back off from a fully normalized design only if all other strategies for improving performance have somehow failed to meet requirements." Date, C.J. Database in Depth: Relational Theory for Practitioners. O'Reilly (2005), p. 152.
  7. ↑ Ralph Kimball, for example, writes: "The use of normalized modeling in the data warehouse presentation area defeats the whole purpose of data warehousing, namely, intuitive and high-performance retrieval of data." Kimball, Ralph. The Data Warehouse Toolkit, 2nd Ed.. Wiley Computer Publishing (2002), p. 11.
  8. ↑ "The adoption of a relational model of data ... permits the development of a universal data sub-language based on an applied predicate calculus. A first-order predicate calculus suffices if the collection of relations is in first normal form. Such a language would provide a yardstick of linguistic power for all other proposed data languages, and would itself be a strong candidate for embedding (with appropriate syntactic modification) in a variety of host Ianguages (programming, command- or problem-oriented)." Codd, "A Relational Model of Data for Large Shared Data Banks" Archived 2007년 6월 12일 - 웨이백 머신, p. 381
  9. ↑ Codd, E.F. Chapter 23, "Serious Flaws in SQL", in The Relational Model for Database Management: Version 2. Addison-Wesley (1990), p. 371-389
  10. ↑ Codd, E.F. "Further Normalization of the Data Base Relational Model", p. 34
  • Paper: "Non First Normal Form Relations" by G. Jaeschke, H. -J Schek ; IBM Heidelberg Scientific Center. -> Paper studying normalization and denormalization operators nest and unnest as mildly described at the end of this wiki page.

외부 링크 편집

원본 주소 "https://ko.wikipedia.org/w/index.php?title=데이터베이스_정규화&oldid=35069210"