CodeGym/Java Course/All lectures for KO purposes/데이터베이스 정규형

데이터베이스 정규형

사용 가능

3.1 데이터베이스 정규화

정규 형식은 관계형 데이터 모델의 관계 속성으로 중복성 측면에서 특성화되어 데이터 샘플링 또는 변경 시 논리적으로 잘못된 결과를 초래할 수 있습니다. 일반 형식은 관계(데이터베이스의 테이블)가 충족해야 하는 요구 사항 집합으로 정의됩니다.

데이터베이스 관계를 일반 형식을 준수하는 형식으로 변환하는 프로세스를 정규화라고 합니다. 정규화는 데이터베이스의 구조를 최소한의 논리적 중복성을 제공하는 형태로 만들기 위한 것이며 성능을 감소 또는 증가 시키 거나 데이터베이스의 물리적 볼륨을 감소 또는 증가시키기 위한 것이 아닙니다 .

정규화의 궁극적인 목표는 데이터베이스에 저장된 정보의 잠재적인 불일치를 줄이는 것입니다. 정규화 프로세스의 일반적인 목적은 다음과 같습니다.

  • 특정 유형의 중복성 배제;
  • 일부 업데이트 이상을 수정합니다.
  • 실제 세계를 충분히 "고품질"로 표현하고 직관적이며 후속 확장을 위한 좋은 기반이 될 수 있는 데이터베이스 프로젝트 개발
  • 필요한 무결성 제약 조건을 적용하는 절차를 단순화합니다.

중복성은 일반적으로 각 릴레이션에 기본 팩트만 저장되도록(즉, 저장된 다른 팩트에서 파생되지 않은 팩트) 관계를 분해하여 제거됩니다.

정규화 아이디어는 데이터베이스 디자인에 매우 유용하지만 결코 데이터베이스 디자인의 품질을 향상시키는 보편적이거나 철저한 수단은 아닙니다. 이는 정규화로 제거할 수 없는 데이터베이스 구조에 발생할 수 있는 오류와 단점이 너무 많기 때문입니다.

이러한 고려 사항에도 불구하고 정규화 이론은 데이터베이스 프로젝트의 품질에 대한 과학적으로 엄격하고 합리적인 기준과 이 품질을 개선하기 위한 형식적인 방법을 제공하기 때문에 관계 이론과 실제의 매우 귀중한 성과입니다. 이것은 정규화 이론이 다른 데이터 모델에서 제공되는 순전히 경험적인 설계 접근 방식과 차별화됩니다. 또한 정보 기술의 전체 분야에서 관계형 데이터베이스의 정규화 이론과 형식적 엄격성 수준에서 비교할 수 있는 설계 솔루션을 평가하고 개선하는 방법이 거의 없다고 주장할 수 있습니다.

정규화는 때때로 "상식일 뿐"이라는 이유로 비판을 받기도 하며 유능한 전문가라면 종속 이론을 적용하지 않고도 완전히 정규화된 데이터베이스를 "자연스럽게" 설계할 것입니다.

그러나 크리스토퍼 데이트(Christopher Date) 교수가 지적한 바와 같이 정규화는 정확히 성숙한 설계자를 마음속에 안내하는 상식의 원리, 즉 정규화의 원리는 형식화된 상식입니다 . 한편, 상식의 원리를 규명하고 공식화하는 것은 매우 어려운 작업이며, 이를 해결하는 데 성공하는 것은 상당한 성과입니다.

3.2 제1정규형

1NF(1차 정규형)는 관계형 데이터 모델에서 관계의 기본 정규형입니다.

관계 변수는 해당 변수의 유효한 값에서 각 관계 튜플이 각 속성에 대해 정확히 하나의 값을 포함하는 경우에만 첫 번째 정규 형식입니다.

관계형 모델에서 관계는 관계 개념의 정의에 따라 항상 제1정규형입니다.

다양한 테이블의 경우 올바른 관계 표현이 아닐 수 있으므로 1NF에 속하지 않을 수 있습니다. 이러한 경우에 대한 Christopher Date의 정의에 따르면, 테이블이 일부 관계의 직접적이고 진정한 표현인 경우에만 테이블이 정규화됩니다(동등하게는 첫 번째 정규 형식임). 보다 구체적으로 해당 테이블은 다음 다섯 가지 조건을 충족해야 합니다.

  • 위에서 아래로 행의 순서가 없습니다(즉, 행의 순서는 정보를 전달하지 않습니다).
  • 열의 왼쪽에서 오른쪽 순서는 없습니다(즉, 열 순서에는 정보가 없습니다).
  • 중복 라인이 없습니다.
  • 행과 열의 각 교집합에는 해당 도메인의 정확히 하나의 값만 포함됩니다.
  • 모든 열은 "일반"입니다.

테이블의 모든 열의 "정규성"은 일반 열 이름을 참조하는 대신 일부 특수 연산자를 호출할 때만 액세스할 수 있거나 행에 부작용을 일으키는 "숨겨진" 구성 요소가 테이블에 없음을 의미합니다. 또는 표준 연산자를 호출할 때 테이블.

원래의 비정규화(즉, 일부 관계의 올바른 표현이 아님) 테이블:

직원 전화 번호
Ivanov I.I.

283-56-82

390-57-34

페트로프 P.P. 708-62-34
Sidorov S.S.

일부 관계의 올바른 표현인 1NF로 축소된 테이블:

직원 전화 번호
Ivanov I.I. 283-56-82
Ivanov I.I. 390-57-34
페트로프 P.P. 708-62-34

3.3 제2정규형

관계 변수는 제1정규형이고 키가 아닌 모든 속성이 (모든) 후보 키에 환원 불가능하게 종속 되는 경우에만 제2정규형에 속합니다 .

비환원성은 잠재적인 키가 이 기능적 종속성도 파생될 수 있는 속성의 더 작은 하위 집합을 포함하지 않음을 의미합니다. 환원 불가능한 기능적 종속성의 경우 "완전한 기능적 종속성"이라는 동등한 개념이 자주 사용됩니다.

후보 키가 단순하다면, 즉 단일 속성으로 구성되어 있으면 이에 대한 기능적 종속성을 줄일 수 없습니다(완전함). 후보 키가 복합 키인 경우 제2 정규형의 정의에 따라 복합 후보 키의 일부에 의존하는 관계에 키가 아닌 속성이 없어야 합니다.

관계를 제2정규형 으로 변환하는 예

속성 쌍 {Company branch, Position}이 다음 관계에서 기본 키를 형성하도록 합니다.

아르 자형
회사 지점 직함 샐러리 컴퓨터의 가용성
톰스크 지점 청소기 20000 아니요
모스크바 지사 프로그램 제작자 40000 먹다
톰스크 지점 프로그램 제작자 25000 먹다

급여는 지점과 직책에 따라 달라지고 컴퓨터의 가용성은 직책에만 달려 있다고 가정해 보겠습니다.

기능적 종속성이 있습니다. 위치 -> 좌변(결정자)이 기본 키의 일부일 뿐인 컴퓨터를 가짐으로써 제2 정규형의 조건을 위반합니다.

2NF로 축소하려면 원래 관계를 두 관계로 분해해야 합니다.

R1
회사 지점 직함 샐러리
톰스크 지점 청소기 20000
모스크바 지사 프로그램 제작자 40000
톰스크 지점 프로그램 제작자 25000
R2
직함 컴퓨터의 가용성
청소기 아니요
프로그램 제작자 먹다
프로그램 제작자 먹다

3.4 제3정규형(3NF)

관계 변수 R은 다음 조건이 참인 경우에만 3NF에 있습니다.

  • 아르 자형제2정규형이다.
  • 키가 아닌 속성 없음아르 자형후보 키에 전이적 기능적 종속성이 없습니다.아르 자형.

정의에 대한 설명:

관계 R의 키가 아닌 속성은 R의 어떤 후보 키에도 속하지 않는 속성입니다.

속성 집합 X에 대한 속성 집합 Z의 기능적 의존성(X → Z로 표기, "x가 z를 결정한다"라고 발음함)은 속성 집합 Y가 X → Y 및 Y → Z인 경우 전이적입니다. 경우에 집합 X, Y 및 Z 중 어느 것도 다른 집합의 부분 집합이 아닙니다. 즉, 기능적 종속성 X → Z, X → Y 및 Y → Z는 사소하지 않으며 기능적 종속성 Y → X도 없습니다.

1982년 Carlo Zaniolo는 Codd와 동일하지만 다르게 표현된 3NF의 정의를 제시했습니다. 그것에 따르면 관계 변수는 각각의 기능적 종속성 X → A가 다음 조건 중 적어도 하나를 충족하는 경우에만 3NF에 있습니다.

  • X는 A를 포함합니다(즉, X → A는 사소한 함수 종속성임).
  • X - 슈퍼키
  • A는 키 속성입니다(즉, A는 후보 키의 일부임).

Zaniolo의 정의는 3NF와 보다 엄격한 BCNF(Boyce-Codd Normal Form) 간의 차이점을 명확하게 정의합니다. BCNF는 세 번째 조건("A는 키 속성입니다")을 제외합니다.

Codd의 3NF 정의에 대한 기억에 남고 전통적으로 설명적인 요약은 Bill Kent가 제공했습니다. 키가 아닌 각 속성은 "키, 전체 키 및 에 대한 정보를 제공해야 합니다 ."

키가 아닌 속성의 "전체 키"에 의존하는 조건은 관계가 제2정규형임을 보장합니다. "열쇠만"에 의존하는 조건은 제3정규형이라는 것입니다.

Chris Date는 Kent의 요약을 3NF의 "직관적으로 매력적인 기능"이라고 말하고 약간의 수정을 통해 더 엄격한 Boyce-Codd 일반 형식의 정의 역할을 할 수 있다고 관찰합니다. "각 속성은 키에 대한 정보를 제공해야 합니다. , 전체 키, 그리고 키 외에는 아무 것도 아닙니다.

Kent 버전의 3NF 정의는 데이터 공식의 Boyce-Codd 일반 형식 버전보다 덜 엄격합니다. 전자는 키가 아닌 속성이 키에 의존한다고만 명시하기 때문입니다.

기본 속성(키 또는 그 일부)은 기능적으로 종속될 필요가 전혀 없습니다. 각각은 키 자체 또는 그 일부를 제공하여 키에 대한 정보를 제공합니다. 여기에서 이 규칙은 키가 아닌 속성에만 유효하다는 점에 유의해야 합니다. 모든 속성에 적용하면 이러한 키의 각 요소가 "전체 키" 조건을 위반하기 때문에 모든 복잡한 대체 키가 완전히 비활성화되기 때문입니다.

예를 들어 관계 변수 R1을 고려하십시오.

R1
직원 부서 전화
그리신 회계 11-22-33
바실리예프 회계 11-22-33
페트로프 공급 44-55-66

각 직원은 한 부서에만 속합니다. 각 부서에는 하나의 전화기가 있습니다. Employee 속성은 기본 키입니다. 직원은 개인 전화가 없으며 직원의 전화 번호는 전적으로 부서에 따라 다릅니다.

이 예에서는 직원 → 부서, 부서 → 전화, 직원 → 전화와 같은 기능적 종속성이 존재합니다.

관계 변수 R1은 각 속성이 잠재적 키 Employee에 대해 축소할 수 없는 기능적 종속성을 갖기 때문에 두 번째 정규형입니다.

Employee → Phone 관계는 전이적이므로 관계는 제3정규형이 아닙니다.

R1을 분할하면 3NF에 있는 두 개의 관계 변수가 생성됩니다.

R2
부서 전화
회계 11-22-33
공급 44-55-66

R3
직원 부서
그리신 회계
바실리예프 회계
페트로프 공급

필요한 경우 초기 관계 R1은 관계 R2와 R3을 결합하는 작업의 결과로 쉽게 얻을 수 있습니다.

코멘트
  • 인기
  • 신규
  • 이전
코멘트를 남기려면 로그인 해야 합니다
이 페이지에는 아직 코멘트가 없습니다