데이터베이스 정규화

위키백과, 우리 모두의 백과사전.
이동: 둘러보기, 검색

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

관계형 모델의 발견자인 에드거 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 은 최소한 하나의 코스를 강의하게 되어있지만, 삽입하고자 하는 새로운 레코드에는 없다.
삭제 이상. Dr. Giddens의 모든 정보가 그가 ENG-206 강의를 중단시 삭제된다.

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

  • 같은 정보가 복수개의 열에서 표현된다; 그래서 갱신은 논리적인 모순을 낳게 된다. 예를 들어, "고용자의 기술"이라는 테이블에서 모든 레코드가 고용자 ID, 고용자 주소도 포함하고 있다고 하면, 특정 고용자의 주소 변경시 여러개의 레코드를 수정하여야 한다(그 고용자가 보유한 모든 기술만큼의 레코드가 수정되어야 한다). 성공적인 갱신이 이루어지지 않을 경우-즉, 변경된 고용자의 주소가 그가 가지고 있는 기술 레코드들 중에서 일부는 변경되었으나, 일부는 변경되지 않을 경우- "고용자의 기술" 테이블은 모순 상태가 된다. 특히, 그 특정 고용자의 주소가 무엇인가에 대한 질문에 대해서 혼동스러운 답안을 내놓게 된다. 이 현상을 갱신 이상이라고 한다.
  • 어떠한 특정 사실은 전혀 기록되지 않는 경우가 발생한다. 예를 들어, "교수와 그들의 강의"라는 테이블에서는 교수 ID, 교수 이름, 교수 고용일자, 강의 코드를 가지고 있다고 하자. 새 교수를 고용하였을 경우, 그가 아직 맡은 강의가 없기 때문에 강의 코드를 null로 하지 않는 이상 새 교수를 테이블에 추가할 수가 없다. 이 현상을 삽입 이상이라고 한다.
  • 데이터의 삭제가 전혀 다른 사실에 대한 데이터의 삭제도 필요로 하게 되는 현상이 있다. "교수와 그들의 강의"라는 위 예제에도 한 교수가 임시로 강의를 중단하고자 할때 이 이상현상이 발생한다. 이런 경우 그가 기록된 레코드들을 삭제해야 하는데, 그럴 경우 교수 자체가 사라지게 된다. 이 현상을 삭제 이상이라고 한다.

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

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

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

정규화된 테이블들과 정규화된 테이블들간의 관계들은 현실세계에서의 개념들과 그들간의 관계들을 반영한다. 즉 데이터 모델을 사용자에게 더욱 의미(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}는 정확히 하나의 {고용자 생일}만 갖는다고 가정한다.
자명한 함수 종속성 
속성들의 부분집합이 함수 종속성을 가질때, 자명한 함수 종속성이라고 한다. {고용자 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 이면 추이 종속이라고 한다.
다치 종속성 
다치 종속성은 어떤 레코드의 존재가 다른 레코드의 존재로 이어짐을 의미한다.
조인 종속 
테이블 TT의 속성의 부분집합을 가지는 여러 개의 테이블들을 조인하여 만들어 질 수 있을 때, T는 조인 종속성을 가진다고 한다.
슈퍼 키 
슈퍼키는 레코드를 유일하게 식별해낼 수 있는 속성들의 집합이다. 한 개의 테이블은 여러 개의 슈퍼키를 가질 수 있다.
후보 키 
후보 키는 슈퍼 키에서 레코드를 유일하게 식별하는데 있어서 필요없는 속성을 제거한 슈퍼 키의 부분집합이다.

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

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

인용 자료[편집]

  1. Codd, E.F. (1970년 June월). A Relational Model of Data for Large Shared Data Banks. 《Communications of the ACM》 13 (6): 377–387. doi:10.1145/362384.362685.
  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", 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.

바깥 고리[편집]