First Normal Form의 최종 버전을 얻으려고합니다. 내가 읽는 모든 것은 약간 다른 스핀을 가지고 있습니다.

Date와 같은 많은 당국자들은 관계 상 정의 가 항상 제 1 정상 양식 인 반면 다른 기관은 요구 사항 목록을 제공 한다고 말합니다 . 이는 1NF에 대한 요구 사항이 0에서 많음을 의미합니다.

차이점은 테이블과 관계의 차이점이라고 생각합니다. 테이블은 완전한 혼란이 될 수 있지만 관계는 특정 제한 사항을 따릅니다. 관계가 SQL에서 테이블로 표시된다는 사실은 혼란을 야기합니다.

SQL 데이터베이스와 관련하여 1NF에 특히 중점을 둡니다. 문제는 테이블이 첫 번째 정규 형식인지 확인하기 위해 어떤 속성이 필요합니까?

많은 당국은 테이블이 관계를 나타내는 경우 이미 1NF에 있다고 제안합니다 . 이것은 1NF의 정의를 관계의 정의로 다시 푸시합니다.

1NF 테이블의 일부 속성은 다음과 같습니다.

• 열 순서가 중요하지 않음 [1]
• 행 순서는 중요하지 않습니다
• 모든 행의 길이는 동일합니다 (예 : 행 데이터는 열 머리글과 일치)
• 중복 행이 없습니다 (대리 기본 키를 사용하여 보장 할 수 있지만 PK 자체는 필요하지 않습니다)
• 반복되는 열이 없습니다
• 각 열에는 단일 값 (원자)이 포함됩니다

[1] 기술적으로 특성은 정렬되지 않지만 테이블에서 행 데이터는 열 머리글과 동일한 순서 여야합니다. 그러나 실제 순서는 중요하지 않습니다.

에 여러 데이터 :

원자 데이터 의 개념은 항목을 더 이상 분류 할 수 없다는 것입니다. 이 개념은 기술적으로는 모든 구역을 분류 할 수 있지만 데이터 사용 방법에 따라 해당 데이터를 더 이상 실질적으로 분류 할 수 없다는 점에서 검증 되었습니다 .

예를 들어, 전체 주소 또는 전체 이름은 일반적으로 더 세분화되어야하지만 주어진 이름 또는 도시 이름과 같은 구성 요소는 문자열 일 수 있음에도 불구하고 더 이상 세분화되지 않아야합니다.

안부 열을 반복, 그것은 가지고 불량한 디자인 열인 거의 같은 반복 열 phone1, phone2등을 일반적으로 반복되는 데이터는 관련 부가 테이블에 대한 필요를 나타낸다는.

의존

행이 동일한 헤더를 따르는 것 외에는 행 사이에 관계가 없어야합니다.

열 사이에도 관계가 없어야하지만 더 높은 정규 형식의 주제라고 생각합니다.

문제는 1NF의 정의에서 위의 어느 정도입니까? 독립 행 비트도 들어 옵니까?

예비

정규 형식 의 정의 (1971 년“데이터베이스 관계형 모델의 추가 정규화”에서 첫 번째 정규 형식 으로 알려짐 )와 관계형 패러다임 자체 의 정의는 1970 년에 과학 논문에 발표되었다. 데이터베이스 관리, 즉의 연습을위한 기초, "대형 공유 데이터 은행에 대한 데이터의 관계형 모델" 에 의해 생성 (간결을위한 RM) 박사 EF 커드 튜링 상을받는 사람이며, 관계형 프레임 워크에 관한 권한.

그렇습니다. Dr. Codd의 글에 대해 많은 설명, 해석, 설명, 편차 및 의견이 있지만, 저는 개인적으로 원천을 고수하는 것을 선호하며 스스로 결론을 도출 할 수 있도록 직접 분석 할 것을 적극 권장합니다.

나는 확실히 RM 전체를 이해하지 못하지만, 내가 이해하는 것은 그것의 우수성, 비전, 의도 및 범위를 이해할 수있게 해주 며 수십 년 후에도 약간의 부정확성이 있음을 알 수 있지만, 어떤 식 으로든 그 천재성과 우아함. 해당 분야에서 RM은 독보적 인 방식으로 시간 테스트를 견뎌냈으며, 최고의 비교를 유지하고 있습니다.

앞서 언급 한 부정확성을 강조하는 행위는 자선 용어를 사용하는 것은 불공평 할 것입니다. 상당한 거리에서 볼 때이 중요한 자료는 약간의 개선과 확장이 필요했지만, 작품의 주요 내용은 바로 개념 (그리고 실제로 Dr. Codd는 그러한 개선과 확장을 전부는 아니더라도)으로 만들었습니다.

나는이 탁월한 지식 원에 대한 이해를 강화하기 위해 지속적으로 RM을 계속해서 다시 읽습니다. 목표는 거인의 어깨에서는 것입니다.

관계 및 테이블

관계는 추상적 자원이기 때문에 Dr. Codd 는 관계 를 표 형식으로 표현하는 유틸리티를 계획했습니다. 관계형 데이터베이스 (RDB)의 사용자, 디자이너 및 관리자는보다 친숙하거나 구체적 으로 접근 할 수 있습니다 . 따라서 RDB 구현의 맥락에서 테이블 을 관계 의 속기 로 사용하는 것이 유효합니다.상기 표가 실제 관계를 나타내는 한. 이 기능은 테이블이 첫 번째 정규 형식 (1NF)을 준수하는 관계를 나타내는 지 여부를 평가하기 전에 관계를 정확하게 나타내야하기 때문에 매우 중요합니다.

RM에는 자연스럽게 테이블이 실제로 관계를 나타내는 지 결정해야하는 자질이 포함되어 있지만 여기에 대한 비공식적이고 소박한 해석을 제공 할 것입니다 (또 하나, 예!).

• 이름이 있어야합니다 (데이터베이스 구조의 각 특정 관계는 나머지와 구별되어야합니다).
• 각 행 은 해당 관계의 정확히 하나의 튜플 을 나타내야합니다 .
• 행 의 순서 는 전혀 중요하지 않습니다.
• 각 열 은 관련 관계 의 정확히 하나의 도메인 의 의미를 나타내는 이름을 가져야하며, 해당 이름은 테이블의 나머지 열의 이름과 달라야합니다 (열은 고유하게 구별되어야하며 운반해야합니다) 데이터베이스 모델러와 비즈니스 전문가가 각 의미 영역을 정확하게 정의하는 역할이 가장 중요합니다.)
• 위해 그 열은 의미가 없습니다.
• 모든 행의 열 수가 동일해야합니다.
• 행을 통해 묘사 된 모든 튜플을 고유하게 식별하는 하나 이상의 열 또는 하나의 열 조합 이 있어야합니다 . 이러한 방식으로 모든 행이 달라야합니다 (예, 하나 이상의 KEY를 선언해야하는 중요성을 강조하고 둘 이상의 KEY가있는 경우 실제적인 이유에 따라 PRIMARY로 정의해야하며 나머지는 ALTERNATE로 간주되지만 결정을 내리기 전에 각 KEY는 PRIMARY로 정의하기위한“후보”였습니다.

실제로 관계를 나타내는 테이블을 갖는 것은 관계형 조작 조작을 수행 할 때 결과가 다시 관계를 나타내는 테이블이므로 중요합니다. 이러한 방식으로, 상기 테이블의 거동은 예측 가능하다 .

원자 도메인 (열)

RM의 첫 번째 섹션에서 Dr. Codd는 몇 가지 개념을 소개하기 위해 몇 가지 관계 샘플을 제시합니다. 따라서 atomic domain 의 의미를 이해하기 위해 RM에서 발췌 한 몇 가지 관련 요점을 살펴 보겠습니다.

지금까지 우리는 단순한 도메인 (요소가 원자 (분해 할 수없는) 값인 도메인)에 정의 된 관계의 예에 대해 논의했습니다. 비 원자 값은 관계형 프레임 워크 내에서 논의 될 수 있습니다. 따라서 일부 도메인은 요소로 관계가있을 수 있습니다. 이러한 관계는 차례로 단순하지 않은 도메인 등에서 정의 될 수 있습니다.

이런 식으로, 앞에서 언급 한 해설 관계 각각이 종류 A 또는 종류 B 와 같은 두 종류 중 하나에 적합 하다고 말할 수 있습니다 .

• 종류 A 는 모든 튜플 (행)에 독점적으로 간단한 값 을 포함하는 도메인 (열)으로 구성된 관계 (테이블) 만 그룹화합니다 . 즉, 이러한 도메인 (열)에는 값으로 관계 (테이블)가 포함되지 않습니다. 이 문맥은 값이 새로운 관계 (테이블) 로 연속해서 분해 될 수 없기 때문에 값이 원자적임을 의미합니다 . 따라서이 등급의 관계는 정규화 되는 관계입니다 . 즉, 1NF를 준수하면 형태가 바람직합니다.

• 종류 B 는 각각의 튜플 (행)의 값으로 관계를 유지하는 하나 이상의 도메인 (열)을 갖는 관계 (테이블)에 의해 독점적으로 통합되며, 그 값은 이후에 새로운 관계로 분류 될 수 있기 때문에 비원 자적 임을 나타냅니다. (테이블), 즉 분해 가능 합니다. 따라서 이러한 종류의 관계는 정규화되지 않습니다. 즉, 1NF를 침해하며 바람직하지 않은 형태입니다.

표준화

Codd 박사는 RM의 정규화에 관한 섹션을 다음 단락과 함께 소개합니다.

도메인이 모두 간단한 관계는 위에서 논의 된 종류의 2 차원 열-균질 어레이에 의해 저장에서 표현 될 수있다. 하나 이상의 단순하지 않은 도메인과의 관계에는 좀 더 복잡한 데이터 구조가 필요합니다. 이러한 이유로 (및 아래에 인용 할 다른 것) 단순하지 않은 도메인을 제거 할 가능성은 조사 할 가치가있는 것으로 보입니다! 실제로 매우 간단한 제거 절차가 있으며이를 정규화라고합니다.

그런 다음 그는 계속해서 보여줍니다.

1. 비정규 화 된 관계 그룹 (관계가 값으로 포함 된 도메인, 즉 비 원자, 즉 단순하지 않은 도메인)

2. 정규화 된 관계 그룹 (즉, 분해 된 관계, 즉 관계가 부여 된 도메인이 원자임을 나타내는 간단한 것으로 분류 된 관계)

그리고 나서 그는 정규화되지 않은 관계로부터 정규화 된 관계를 얻는 절차를 설명합니다.

이와 관련하여 그가 정규화 운동을 설명하기 위해 그가 사용한 관계와 운동 설명 자체는 매우 명확하며 다시 분석하는 것이 좋습니다 (또한 일부 독자가 텍스트를 사용하도록 권장하기를 바랍니다).

그는 다음과 같이 지적합니다.

정규화 종류의 추가 작업이 가능합니다. 이에 대해서는이 백서에서 다루지 않습니다.

그리고 상기 동작, 즉, 제 2 및 제 3 정규형 (2NF 및 3NF)은 실제로 "데이터베이스 관계형 모델의 추가 표준화"및 상기 언급 된 바와 같이 본 논문의 발표 (및 추후 인쇄 및 출판) 후에 상세하게 설명된다 상기 원 통상의 형태는 제 1 정규형 알려졌다.

실무자가 관찰 할 수 있듯이 정규화되지 않은 관계 (테이블)가 있으면 RDB 구현에 (거의 항상 불필요한) 컨볼 루션 이 발생합니다.

Codd 박사가 다음 줄에서 지적한 것처럼 1NF를 만족하는 관계는 정규화되지 않은 관계 (테이블)에 필요한 것보다 덜 복잡한 데이터 하위 언어를 사용하여 구현할 수있는 제약 조건 및 데이터 조작 작업의 정의를 용이하게합니다.

위에서 설명한 것처럼 관계형 데이터 모델을 채택하면 적용된 술어 미적분을 기반으로 범용 데이터 하위 언어를 개발할 수 있습니다. 관계의 수집이 정상적인 형태이면 1 차 술어 미적분이면 충분합니다. 그러한 언어는 다른 모든 제안 된 데이터 언어에 언어 능력의 척도를 제공 할 것이며, 그 자체가 다양한 호스트 언어 (프로그래밍, 명령 또는 문제 중심)에 (적절한 구문 수정으로) 포함시키기위한 강력한 후보가 될 것입니다. […]

[…]

데이터 하위 언어의 보편성은 기술 능력 (컴퓨팅 능력이 아닌)에 있습니다.

당황

내 관점에서, 당황 인해 1NF 약 등의 해석, 설명,의 (a), 상기 과잉에 생겨났다 하는 상기 시도 RM 자체 때문에 (B)를 재정의 1NF를 그 상태로 그 관계를 갖는 관계가있는 값을 보유하는 도메인의 경우 관계 는 해당하는 튜플마다 하나의 단일 값인 한 1NF를 준수 합니다.

당신의 다른 포인트를 받아

행이 동일한 헤더를 따르는 것 외에는 행 사이에 관계가 없어야합니다.

나는 그 진술의 의도를 올바르게 이해하고 있는지 확실하지 않지만 동일한 헤더를 따르는 것 외에도 관계 (테이블)의 (튜플) 행 사이 에 연결 이 있어야합니다 . 관계 (표)가 나타내는 특정 엔티티 유형 (관심있는 비즈니스 컨텍스트로 정의)의 특정 발생.

열 사이에도 관계가 없어야하지만 더 높은 정규 형식의 주제라고 생각합니다.

나는 그 진술의 의미를 올바르게 해석하고 있는지 알지 못하지만 실제로는 이전 측면에 대한 나의 반응에 따라 관계 (테이블)의 도메인 (열) 사이에 관계 가 있어야합니다 이것이 관계 ( 관계형 모델과 구체적인 RDB 구현 의 필수 구조) 인 이유 입니다.

가설 관계와 관련하여 예시하기 위해 (표)

• Salary (PersonNumber, EffectiveDate, Amount)

튜플 (행)

• Salary (x, y, z)

의미를 전달할 것이다

• The Salary payed to the Person identified by PersonNumber x, on EffectiveDate y corresponds to the Amount of z

따라서 Salary관계 (테이블 )의 각 튜플 (행)은 위에 표시된 어설 션의 구조에 맞아야하며 차이는 관련 도메인 (열) 값을 대체하지만, (a) 사이에는 관계가 있어야합니다. 모든 Salary도메인 (열) 및 또한 (b) 각 튜플 (행)에 대한 모든 해당 값; 그런 관계는 없어서는 안될 관계입니다.

더 높은 정규형 (2NF 및 3NF)은 관계 (테이블)의 도메인 (열) 사이의 기능적 종속성을 제거하는 데 유용하며 , 바람직하지 않은 연결 은 업데이트 예외 의 도입을 허용하므로 도메인 (열) 간의 바람직하지 않은 연결 을 피하는 데 도움이됩니다. . 2NF와 3NF는 특정 RDB 구현에서 관계 (테이블) 구조의 건전성을 테스트하는 데 도움이됩니다.

삽화. 일반적인 미국 주소가 포함 된 텍스트 문자열을 사용하십시오.

"123 Cornhusk Rd., South Succotash, NY 12345"

Cornhusk Road의 모든 거주자 또는 South Succotash 도시의 특정 거주자 또는 뉴욕 주를 찾기위한 쿼리를 작성하는 것은 어려운 작업입니다. 특히 데이터에 다음 문자열이있는 경우 :

"123 Cornhusk Road, South Succotash, NY 12345"
"123 Cornhusk Rd., South Succotash, New York 12345"
"123 Cornhusk, South Succotash, NY 12345"
"123 Cornhusk Rd., SOUTH SUCCOTASH, NY 12345"

이들 각각은 동일한 실제 주소를 지정합니다 (그리고 이것은 "Succatash"와 같은 철자가 틀린 것으로 간주되지는 않습니다). 그러나 그것들을 성공적으로 비교하기위한 알고리즘을 작성하는 것은이 지구상에서 남은 지난 몇 년을 바치고 싶지 않은 것입니다.

첫 번째 일반 양식을 입력하십시오. 나는 그 방법에 대한 세부 사항을 다루지 않고 대부분의 데이터베이스에서 볼 수있는 일반적인 형태를 고려하십시오.

create table Addresses(
  ...
  Street  varchar,
  City    int        references Cities( ID ),
  State   char( 2 )  references States( ID ),
  Zip     int
  ...
);

이것은 완전한 정규화가 아닙니다. 예를 들어 Street를 StreetNum과 StreetName으로 더 나눌 수 있지만 이것은 간단한 설명을하기에는 충분하며 실제로는 정규화 프로세스가 수행되는 정도입니다. Cornhusk Road의 모든 거주자를 찾는 데 여전히 작은 문제가 있지만 Street에서 하위 문자열 "Cornhusk"를 검색하면 Cornhusk라는 도시가 있었는데 적어도 혼란을 유발하지는 않습니다.

Date 등이 제공 한 정의의 문제점은 데이터 내부를 조사하지 못하고 해당 데이터의 의미를 고려한다는 것입니다. 내가 특별히 그들을 비난하는 것이 아니라, 상당히 어려울 수 있습니다.

따라서 "문자열"을 가져 와서 "주소"로 바꿔야합니다. 그러나 주소에 대한 포괄적 인 정의를 내는 것은 그다지 간단하지 않습니다. 특히 여러 국가에서 주소를 다루는 경우.

먼저 문맥을 수정합니다. 문맥이 없으면 의미가 없습니다. 우리의 맥락은 address 입니다. 이러한 맥락에서 Street , City 등과 같은 특정 의미를 갖는 데이터 부분을 볼 수 있습니다 . 각 의미를 별도의 필드에 할당합니다.

어려운 부분은 단어와 같은 데이터가 다른 사람들에게 다른 의미를 가질 수 있거나 어떤 사람들은 다른 사람들이 아닌 곳에서 의미를 볼 수 있다는 것입니다. 그것은 그 자체로 프로젝트가 될 수 있으며 많은 협력 노력이 필요합니다. 그러나 이는 우수한 데이터베이스 디자인에서 중요한 요소입니다.

정규화 지점은 이상 데이터 를 제거하거나 최소한 최소화 하는 것입니다. 위 표에서 선택한 상태에 존재하지 않는 도시 또는 우편 번호를 입력 할 수 있다는 사실을 고려하십시오. 또는 선택한 도시에 실제로 존재하지 않는 거리가 입력되었습니다. 아, 그러나 지금 우리는 두 번째와 세 번째 정상적인 형태로 들어가고 있으며 그것은 또 다른 주제입니다.

1NF를 특정 데이터 구조 나 고정 된 규칙 세트가 아니라 수학적 관계 개념에 대한 소개로 생각하십시오. 관계와 같은 수학적 구조는 다른 방식으로 표현 될 수 있습니다. 표는 가장 편리한 방법 중 하나입니다. 테이블을 사용할 때, 의도 된 관계를 명확하게 나타내고 테이블에 대한 조작이 표시된 관계에 대해 논리적으로 건전하다는 제한이 있습니다.

열 및 행 순서와 중복이 중요하지 않다고 말하면 모든 중요한 정보가 테이블에 값으로 기록되고 쿼리에 액세스 할 수 있고 테이블 표시로 인코딩되지 않아야합니다. 저자가 표에서 색상 사용을 명시 적으로 금지 한 사람은 거의 없지만 위의 제한의 목적을 이해하면 의미있는 표현 색상의 사용을 유사하게 배제하여 중요한 색상 값을 명시 적으로 기록해야합니다. 날짜와 다른 작성자도 같은 이유로 숨겨진 행 식별자를 더 이상 사용하지 않습니다.

원자 성의 개념은 모든 중요한 구조가 관계로 표현되도록하여 모든 데이터의 종속성을 분석 하고 이상을 방지하고 관계형 작업에 모든 의미있는 구조에 균일하게 액세스 할 수 있도록하는 것입니다. 복합 값은 유효하지 않지만 도메인 별 연산자의 압축을 풀어야하므로 복잡성이 증가하고 중복성을 유발할 수 있습니다. 물론 실제로는 간단한 복합 유형과 관련 연산자가 편리하고 쿼리의 압축성과 표현성을 높이는 데 도움이되지만 이론과 모순되지는 않습니다.

다중 값 종속성과 같은 행 종속성은 1NF를 위반하지 않지만 열 간의 종속성과 마찬가지로 더 높은 정규 형식의 주제입니다. 거의 반복 열 좋아 phone1, phone2등, 비록 그들이있는 거 가난한 디자인을 1NF 중 하나를 위반하지 않습니다.

1NF에 대한 WikiPedia 의 정의와 설명 은 꽤 좋습니다. -조 놀로

Wikipedia 기사에서 한 문장으로 확장 :

전화 번호로 볼 때 텍스트는 원자가 아닙니다

이렇게하면 혼동이 많은 이유를 파악할 수 있습니다. 이것이 단지 텍스트의 덩어리라면, 그것은 원자 적입니다. 그러나 전화 번호로 볼 경우 원자가 아닙니다. 날짜와 다른 사람들이이 문제를 회피했습니다. 데이터의 의미와 관련이 있습니다. 주제를 분석 할 때는 데이터의 의미를 파악해야합니다.

더 세분화 할 필요가 있는지 여부는 첫 번째 정규 양식이 충족되었는지 여부와 관련이 있습니다. 1NF의 핵심은 모든 데이터에 대한 키 액세스를 제공하는 것입니다. 그러나 키 액세스를 통해 검색 한 항목에 하위 구조가있는 경우 하위 구조에 대한 키 액세스 권한이 없습니다. - 월터 미티

"1NF"는 여러 가지 다른 것을 의미하는데 사용되는데 , 그중 많은 것들이 동시에 무의미하고 일반적입니다. 링크를 포함하여 "데이터베이스 관리 시스템의 정규화"에 대한 내 답변을 참조하십시오 . 그 중 하나는 "dbms의 원 자성이란 무엇입니까"에 대한 나의 대답 입니다. (스택 오버플로 모두) -philipxy

_{질문에 남은 댓글에서 작성된 커뮤니티 위키 답변}