정규화 : 1 년과 같은 정적 숫자 값을 자체 테이블로 분할하는 것이 호환되는 것으로 간주됩니까?

정규화에 대한 다른 데이터베이스 디자이너와 흥미로운 토론을하고 있습니다. 이 예에서는 GameTitles 테이블이 있으며 각 레코드에는 게임이 출시 된 연도가 포함되어야합니다. 그는 2NF는 모든 것이 정규화되어야한다고 규정하고 있기 때문에, 연도 필드는 GameTitles 테이블이 참조하는 자체 기본 키를 사용하여 ReleaseYears 테이블로 분리되어야한다고 말합니다. GameTitles 테이블 자체에 필드로 남아 있어야한다고 말합니다.

이것에 대한 나의 주장은 연도는 본질적으로 정적이 아닌 기본이 아닌 숫자 값이라는 것입니다 (즉, 2011은 항상 2011입니다). 이로 인해 고유 식별자로 사용되며 참조이므로 참조 할 필요가 없습니다. 또한 참조 용으로 새해를 테이블에 추가해야하므로 추가 유지 보수가 도입되었습니다. 연도가 넓은 테이블을 미리 채우면 잠재적으로 전혀 참조하지 않는 추가 레코드가 있습니다. 또한 추가 테이블, 레코드 오버 헤드 및 연도에 대한 추가 기본 키가 있으므로 데이터베이스 크기도 증가합니다. 연도를 GameTitles 테이블에서 필드로 유지하면이 추가 유지 보수 및 오버 헤드가 모두 제거됩니다.

이것에 대한 생각?

편집 : 이것을 StackOverflow에 게시해야합니다. 누군가 이것을 삭제하거나주의를 끌기 위해 투표 할 수 있습니까?

다른 데이터베이스 디자이너는 단순히 틀리지 만 당신의 추론도 틀리다. 단일 후보 키 "game_title"이있는이 테이블로 시작한다고 가정 해 봅시다.

Table: game_titles

game_title                      year_first_released
--
The first game                  1998
The second game                 1999
Best game: the third one        2001
The fourth game                 2003
Forty-two, the end of games     2011

이러한 질문을함으로써 2NF에 있는지 평가합니다.

Q : 우선 1NF입니까?

A : 그렇습니다.

Q : 주요 속성 (후보 키의 일부인 속성)은 무엇입니까?

A : "game_title"은 유일한 주요 속성입니다.

Q : 프라임 이외의 속성은 무엇입니까?

A : "year_first_released"만이 유일합니다.

Q : "year_first_released"는 기능적으로 "game_title"전체 또는 일부에 의존합니까?

A : 유일한 후보 키인 "game_title"은 단일 열입니다. 심지어 부품이 없습니다. "year_first_released"는 "game_title"전체에 기능적으로 의존합니다.

Voilà. 2NF를 찾았습니다.

1NF에 속하는지 먼저 질문 한 다음이 질문에 대답하여 일부 공식 용어를 줄일 수 있습니다.

Q : 복합 후보 키가 있습니까?

A : 아니요.

Voilà. 2NF를 다시 찾았습니다.

정의에 따라 테이블이 2NF를 위반하려면 둘 이상의 열이있는 하나 이상의 후보 키가 있어야합니다.

친구의 의견을 거부 한 이유는 다음과 같습니다.

• 연도는 기본이 아닌 숫자 값입니다.
• 1 년은 본질적으로 정적입니다.
• 연도는 고유 식별자로 사용됩니다.
• 몇 년 동안 추가 유지 보수가 도입되었습니다.
• 연도 테이블에는 참조되지 않은 추가 행이있을 수 있습니다.
• 년의 테이블은 데이터베이스 크기를 증가시킵니다.

이러한 이유들 중 어느 것도 테이블이 2NF인지 여부와는 전혀 관련이 없습니다.

데이터베이스를 디자인 할 때 유지 관리 문제, 데이터베이스 크기, 참조되지 않은 행, 범위 제약 조건 등을 고려하는 것은 잘못이 아닙니다. 그것들을 표준화라고 부르는 것은 잘못입니다.

아, 그리고 위에서 제공 한 2 열 테이블은 5NF입니다.

속성에 대해 별도의 테이블을 만드는 것은 정규화와 관련이 없습니다. 2NF, 3NF, BCNF, 4NF, 5NF는 모두 키가 아닌 종속성 제거와 관련이 있습니다. 새 테이블에 대한 단일 속성을 제거하고 외래 키 속성으로 바꾸면 테이블의 종속성이 논리적으로 이전과 동일하게 변경되므로 테이블의 수정 된 버전이 더 이상 정규화되지 않습니다. 전에 있었다.

내 관점에서 볼 때 "연도"가 달력 연도가 아닌 경우 (예 : 10 년에서 10 월로 여러 회계 연도에 걸쳐 회계 연도) 별도의 연도 테이블이 의미가 있습니다.

이 테이블에는 회계 연도의 정의 (실제 시작 및 종료 날짜)가 포함됩니다.

에서 http://en.wikipedia.org/wiki/Second_normal_form :

후보 키 K 및 후보 키의 구성 요소가 아닌 속성 A가 주어지면 A가 단지 K의 일부가 아니라 K 전체에 의존하는 경우에만 1NF 테이블은 2NF에 있습니다.

연도가 후보 키의 일부인지 여부를 표시하지는 않았지만 2NF가 연도에 관한 한 만족할 수 있기 때문에 중요하지는 않습니다.

실질적인 수준에서 당신이 열거 한 모든 이유로 인해 연도를 분리하는 것은 나쁜 생각입니다.

크기가 다르거 나 사용되지 않는 행이 있기 때문에 별도의 테이블에 대한 인수를 싫어합니다. 이 표에 1000 년을 넣어도 크기는 무시할 수 있습니다.

즉, 나는 테이블이 전혀 필요하다고 생각하지 않습니다. 연중 별도의 테이블을 갖는 요점은 무엇입니까? 이 데이터는 이미 기본 테이블에 있으며 두 번째 테이블을 생성하여 아무것도 저장하지 않습니다.

인수는 달력 테이블에서 다를 수 있습니다. 여기서 각 행은 요일을 나타내며 다른 속성 (요일, UTC 오프셋, 휴일 여부 등)을 가질 수 있습니다.

그러나 1 년만? 아냐, 나는 전혀 아무런 이익도 보지 못한다 ... 그리고 다른 사람들이 지적했듯이, 그들이 왜 그것이 더 정규화되었다고 생각하는지 물어보십시오? 아니면 그들이 얻는 것? 당신이 같은 쿼리를 작성하려고하는 경우

WHERE othertable.year = 2011

대신에

WHERE dt >= 20110101 AND dt < 20120101

그런 다음 후자가 성능 (dt가 색인화되었다고 가정) 및 저장에 훨씬 우수하다는 것을 설득하려고합니다. 코딩 단순성이 가장 중요한 경우 지속 계산 열이 다른 테이블보다 낫습니다.

한 가지 점을 제외하고는 Catcall의 대답에 전적으로 동의합니다. "연도"가 항상 기본 값은 아니지만 데이터베이스 설계 개념보다 비즈니스 논리 개념에 가깝습니다.

동일한 디자인을 유지하면서 연도는 출시가 허용 된 연도 여야한다고 가정합니다. 그런 식으로 기본 숫자 값을 다루지 않고 그 하위 집합을 처리하고 하위 집합에는 기본 구현이 없으므로 자체적으로 (별도의 테이블?)해야하고 참조해야합니다. (FK 포함). 이러한 방식으로 우리는 여전히 몇 년 동안 이야기하고 있지만 개념적으로 의미를 변경했기 때문에 다른 방식으로 관리해야합니다. 그러나 그들은 여전히 ​​"해고의 해"이지만 도메인 지식을 가진 사람에게 어떤 의미가 있는지에 대해서는 개념적으로 다릅니다.

이 특정 사례에 대해 Catcall의 답변이 정확하지만 다시 지적하고 싶었습니다. (죄송합니다. 아직 충분한 답변이 없습니다.)