[database-design] 정규화 (또는 정규화) 란 무엇입니까?

왜 데이터베이스 담당자가 정규화를 계속하는 걸까요?

뭔데? 어떻게 도움이됩니까?

데이터베이스 외부에 적용됩니까?



답변

정규화는 기본적으로 중복 및 중복 데이터를 방지하는 데이터베이스 스키마를 설계하는 것입니다. 일부 데이터가 데이터베이스의 여러 위치에서 중복되는 경우 한 위치에서 업데이트되지만 다른 위치에서는 업데이트되지 않아 데이터가 손상 될 위험이 있습니다.

1. 정규 형식에서 5. 정규 형식까지 여러 정규화 수준이 있습니다. 각 일반 양식은 일반적으로 중복성과 관련된 특정 문제를 제거하는 방법을 설명합니다.

몇 가지 일반적인 정규화 오류 :

(1) 셀에 둘 이상의 값이 있습니다. 예:

UserId | Car
---------------------
1      | Toyota
2      | Ford,Cadillac

여기에서 “Car”열 (문자열)에는 여러 값이 있습니다. 이는 각 셀에 하나의 값만 있어야한다는 첫 번째 정규 형식을 위반합니다. 자동차 당 별도의 행을 사용하여이 문제를 정규화 할 수 있습니다.

UserId | Car
---------------------
1      | Toyota
2      | Ford
2      | Cadillac

하나의 셀에 여러 값을 갖는 문제는 업데이트하기가 까다 롭고 쿼리하기가 까다 롭고 인덱스, 제약 조건 등을 적용 할 수 없다는 것입니다.

(2) 키가 아닌 중복 데이터 (즉, 여러 행에서 불필요하게 반복되는 데이터). 예:

UserId | UserName | Car
-----------------------
1      | John     | Toyota
2      | Sue      | Ford
2      | Sue      | Cadillac

이 디자인은 이름이 항상 UserId에 의해 결정되지만 이름이 각 열마다 반복되기 때문에 문제가됩니다. 이로 인해 이론적으로 한 행에서 Sue의 이름을 변경할 수 있으며 다른 행은 변경할 수 없습니다. 이는 데이터 손상입니다. 이 문제는 테이블을 두 개로 분할하고 기본 키 / 외래 키 관계를 생성하여 해결됩니다.

UserId(FK) | Car               UserId(PK) | UserName
---------------------          -----------------
1          | Toyota            1          | John
2          | Ford              2          | Sue
2          | Cadillac

이제 UserId가 반복되기 때문에 여전히 중복 데이터가있는 것처럼 보일 수 있습니다. 그러나 PK / FK 제약 조건은 값이 독립적으로 업데이트 될 수 없도록 보장하므로 무결성이 안전합니다.

그것은 중요한가? 예, 매우 중요합니다. 정규화 오류가있는 데이터베이스를 사용하면 유효하지 않거나 손상된 데이터가 데이터베이스에 들어갈 위험이 있습니다. 데이터가 “영원히 유지”되기 때문에 처음 데이터베이스에 들어갔을 때 손상된 데이터를 제거하는 것은 매우 어렵습니다.

정규화를 두려워하지 마십시오 . 정규화 수준에 대한 공식적인 기술적 정의는 매우 헷갈립니다. 정규화가 복잡한 수학적 과정 인 것처럼 들리게합니다. 그러나 정규화는 기본적으로 상식 일 뿐이며 상식을 사용하여 데이터베이스 스키마를 설계하면 일반적으로 완전히 정규화됩니다.

정규화와 관련하여 여러 가지 오해가 있습니다.

  • 일부는 정규화 된 데이터베이스가 더 느리고 비정규 화로 인해 성능이 향상된다고 생각합니다. 그러나 이것은 매우 특별한 경우에만 해당됩니다. 일반적으로 정규화 된 데이터베이스도 가장 빠릅니다.

  • 때때로 정규화는 점진적인 설계 프로세스로 설명되며 “중지시기”를 결정해야합니다. 그러나 실제로 정규화 수준은 다른 특정 문제를 설명합니다. 세 번째 NF 이상의 정규 형식으로 해결되는 문제는 처음에는 매우 드문 문제이므로 스키마가 이미 5NF에있을 가능성이 있습니다.

데이터베이스 외부에 적용됩니까? 직접적으로는 아닙니다. 정규화의 원칙은 관계형 데이터베이스에 매우 구체적입니다. 그러나 다른 인스턴스가 동기화되지 않을 수있는 경우 중복 데이터가 없어야한다는 일반적인 기본 테마는 광범위하게 적용 할 수 있습니다. 이것은 기본적으로 DRY 원칙 입니다.


답변

정규화 규칙 (출처 : 알 수 없음)

  • 열쇠 ( 1NF )
  • 전체 키 ( 2NF )
  • 그리고 열쇠 ​​( 3NF )

… 그래서 Codd를 도와주세요 .


답변

가장 중요한 것은 데이터베이스 레코드에서 중복을 제거하는 역할을합니다. 예를 들어 한 사람의 이름이 나올 수있는 장소 (테이블)가 두 개 이상있는 경우 이름을 별도의 테이블로 이동하고 다른 모든 곳에서 참조합니다. 이렇게하면 나중에 사람 이름을 변경해야하는 경우 한 곳에서만 변경하면됩니다.

적절한 데이터베이스 디자인을 위해 중요하며 이론적으로 데이터 무결성을 유지하기 위해 가능한 한 많이 사용해야합니다. 그러나 많은 테이블에서 정보를 검색 할 때 약간의 성능이 손실되므로 성능이 중요한 응용 프로그램에서 사용되는 비정규 화 된 데이터베이스 테이블 (평탄화라고도 함)을 볼 수 있습니다.

내 조언은 좋은 수준의 정규화로 시작하고 실제로 필요할 때만 비정규 화를 수행하는 것입니다.

추신은 또한이 기사를 확인하십시오 : http://en.wikipedia.org/wiki/Database_normalization 주제와 소위 일반 형식에 대해 더 많이 읽으십시오.


답변

테이블의 열 간의 중복성과 기능적 종속성을 제거하는 데 사용되는 프로 시저를 정규화합니다.

일반적으로 숫자로 표시되는 몇 가지 일반 형식이 있습니다. 숫자가 클수록 중복 및 종속성이 줄어 듭니다. 모든 SQL 테이블은 1NF (첫 번째 정규 형식, 정의상 거의 정의)로되어 있습니다. 정규화는 가역적 인 방식으로 스키마를 변경 (종종 테이블 분할)하여 중복성과 종속성이 적은 것을 제외하고는 기능적으로 동일한 모델을 제공합니다.

데이터의 중복성과 종속성은 데이터를 수정할 때 불일치로 이어질 수 있으므로 바람직하지 않습니다.


답변

데이터 중복을 줄이기위한 것입니다.

보다 공식적인 토론은 Wikipedia http://en.wikipedia.org/wiki/Database_normalization을 참조하십시오 .

다소 단순한 예를 들어 보겠습니다.

일반적으로 가족 구성원을 포함하는 조직의 데이터베이스를 가정합니다.

id, name, address
214 Mr. Chris  123 Main St.
317 Mrs. Chris 123 Main St.

다음과 같이 정규화 될 수 있습니다.

id name familyID
214 Mr. Chris 27
317 Mrs. Chris 27

그리고 패밀리 테이블

ID, address
27 123 Main St.

BCNF (Near-Complete Normalization)는 일반적으로 프로덕션에 사용되지 않지만 중간 단계입니다. 데이터베이스를 BCNF에 넣은 후 다음 단계는 일반적으로 쿼리 속도를 높이고 특정 공통 삽입의 복잡성을 줄이기 위해 논리적 방식으로 비정규 화 하는 것입니다. 그러나 먼저 제대로 정규화하지 않으면이 작업을 잘 수행 할 수 없습니다.

중복 정보가 단일 항목으로 축소된다는 아이디어입니다. 이는 Chris가 자신의 주소를 Unit-7 123 Main St.로 제출하고 Chris가 Suite-7 123 Main Street를 나열하는 주소와 같은 필드에서 특히 유용합니다.

일반적으로 사용되는 기술은 반복되는 요소를 찾고 해당 필드를 고유 ID가있는 다른 테이블로 분리하고 반복 된 요소를 새 테이블을 참조하는 기본 키로 바꾸는 것입니다.


답변

CJ 날짜 인용 : 이론은 실용적입니다.

정규화에서 벗어나면 데이터베이스에 특정 이상이 발생합니다.

First Normal Form에서 이탈하면 액세스 이상이 발생하므로 찾고있는 항목을 찾기 위해 개별 값을 분해하고 스캔해야합니다. 예를 들어, 값 중 하나가 이전 응답에서 제공 한 “Ford, Cadillac”문자열이고 “Ford”의 모든 항목을 찾고있는 경우 문자열을 끊고 확인해야합니다. 부분 문자열. 이것은 관계형 데이터베이스에 데이터를 저장하는 목적을 어느 정도 무효화합니다.

첫 번째 정규형의 정의는 1970 년 이후로 변경되었지만 지금은 이러한 차이점에 대해 걱정할 필요가 없습니다. 관계형 데이터 모델을 사용하여 SQL 테이블을 디자인하는 경우 테이블은 자동으로 1NF가됩니다.

두 번째 정규 형식 이상에서 출발하면 동일한 사실이 둘 이상의 위치에 저장되므로 업데이트 이상이 발생합니다. 이러한 문제로 인해 존재하지 않을 수있는 다른 사실을 저장하지 않고 일부 사실을 저장할 수 없으므로 발명해야합니다. 또는 사실이 변경되면 사실이 저장되어있는 모든 위치를 찾아서 모든 위치를 업데이트해야 할 수 있습니다. 데이터베이스 자체가 모순되지 않도록해야합니다. 그리고 데이터베이스에서 행을 삭제하려고 할 때 삭제하면 여전히 필요한 사실이 저장되는 유일한 위치를 삭제하는 것임을 알 수 있습니다.

이는 성능 문제 나 공간 문제가 아니라 논리적 문제입니다. 때로는 신중한 프로그래밍으로 이러한 업데이트 이상을 피할 수 있습니다. 때때로 (종종) 정상적인 형태를 고수함으로써 처음부터 문제를 예방하는 것이 더 낫습니다.

이미 말한 값에도 불구하고 정규화는 하향식 접근 방식이 아니라 상향식 접근 방식이라는 점을 언급해야합니다. 데이터 분석과 초기 설계에서 특정 방법론을 따르면 설계가 최소한 3NF를 준수한다는 것을 보장 할 수 있습니다. 대부분의 경우 디자인은 완전히 정규화됩니다.

정규화에서 배운 개념을 실제로 적용하고 싶은 곳은 레거시 데이터, 레거시 데이터베이스 또는 레코드로 구성된 파일을 제공하고 데이터가 일반 형식과 이탈의 결과를 완전히 무시하도록 설계되었을 때입니다. 그들에게서. 이러한 경우 정규화에서 벗어난 것을 발견하고 설계를 수정해야 할 수 있습니다.

경고 : 정규화는 마치 완전한 정규화에서 벗어나는 모든 것이 죄인 것처럼 코드에 대한 공격 인 것처럼 종교적 배음으로 가르치는 경우가 많습니다. (거기 약간 말장난). 그것을 사지 마십시오. 실제로 데이터베이스 디자인을 배우면 규칙을 따르는 방법을 알 수있을뿐만 아니라 규칙을 어기는 것이 안전한시기도 알게됩니다.


답변

정규화는 기본 개념 중 하나입니다. 그것은 두 가지가 서로 영향을 미치지 않는다는 것을 의미합니다.

데이터베이스에서 특히 두 개 (또는 그 이상의) 테이블이 동일한 데이터를 포함하지 않는다는 것을 의미합니다. 즉, 중복성이 없습니다.

동기화 문제를 일으킬 가능성이 거의 0에 가까워서 정말 좋은 첫눈에 볼 때 데이터가 어디에 있는지 항상 알고 있습니다.하지만 아마도 테이블 수가 증가하고 데이터를 교차하는 데 문제가있을 것입니다. 요약 결과를 얻을 수 있습니다.

따라서 결국에는 순수 정규화되지 않은 데이터베이스 디자인과 약간의 중복성 (일부 가능한 정규화 수준에 있음)을 사용하여 완료합니다.