데이터베이스를 디자인 할 때 반복되는 데이터 세트를 별도의 테이블로 이동하는 경향이 있다는 것을 알고있었습니다. 예를 들어, 나는 각자가 한 주에 살고있는 사람들의 테이블을 가지고 있다고 말한다. 그런 다음이 반복되는 상태를 별도의 테이블로 이동하고 외래 키로 참조합니다.정상화의 단계는 무엇입니까? (반복되는 데이터를 별도의 테이블로 이동)
그러나 상태에 대한 데이터를 더 저장하지 않으면 어떻게됩니까? 그러면 StateID와 State가있는 테이블이 생깁니다.이 작업이 맞습니까? 상태는 사용자 테이블의 기본 키에 따라 달라 지므로이 테이블을 자체 테이블 도움말로 이동하면 아무 것도 표시되지 않습니까? 국가 테이블이 사용자 테이블 키와 관계가 없어야한다
테이블 내의 반복되는 데이터의 하위 집합을 제거하고 테이블 자체에 배치하는 것은 두 번째 정규 서식에 테이블을 배치하는 과정에서 필요하다고 생각합니다.
상태 약어를 자체 테이블로 옮기는 것은 데이터베이스를 정상화하는 방법입니다. 그것은 켄터키에 대한 약자 "KY"가 "KQ"로 업데이트되는 이유를 알려주는 업데이트 이상으로부터 "사용자"테이블을 보호합니다. 상태 테이블의 기본 키가 들어있는 사용자 테이블에 외래 키를 배치하면 모든 사용자에 대해이 항목을 수정하기 위해 상태 테이블을 한 번만 업데이트하면됩니다.
그 말은 상태 약어가 자주 변경되지 않는다는 것이 아주 분명해 보입니다. 따라서 데이터베이스가 상태에 대한 더 많은 정보를 저장할 필요가 없다는 사실을 안다면 상태 테이블을 사용자 테이블에 남겨 두는 것이 논리적이고 근본적으로 효과적입니다. 그러한 문제의 정규화는 일반적입니다. 사용자 테이블에서 데이터의 가독성을 높이고 조인 오버 헤드를 줄입니다. 그러나 그것은 선호됩니다.
덕분에, 그것은 단지 상태에 대한 데이터를 포함해야합니다.
각 테이블을 최대한 단순하게 유지하려면 사용자 테이블에 사용자 데이터를 유지하고 State 테이블에 상태 데이터를 저장 한 다음 다음과 같은 외래 키 관계가있는 조인 테이블을 작성하십시오. 사용자 테이블과 상태 테이블.
정상화의 어떤 형태인지는 확실하지 않습니다.
나는 당신이 말하는 것을보고 있지만 약간의 오해가있을 수 있다고 생각합니다. 상태 테이블의 사용자에게 링크 상태를 표시하지 않겠습니다. 기본적으로 상태를 가리키는 stateID를 포함하는 Users 테이블이 있다고 말합니다. 그러나, Im에 상태에 대한 더 이상의 정보를 저장하지 않으면, 요점이 있습니까? 쿼리를 좀 더 복잡하게 만드는 것처럼 보입니다. – Sergio
"사용자 테이블의 기본 키에 상태가 달려 있습니다"라는 마지막 질문에 혼란 스러웠을 것입니다. 사용자 레코드에 대한 상태를 연결하는 관계가 있음을 의미했습니다. 데이터를 표준화 할 때마다 쿼리의 복잡성이 증가하는 것이 옳습니다. 한계 수익을 줄이는 확실한 사례가 있으며 데이터베이스를 지나치게 정규화 할 수 있습니다. 상태 데이터를 별도의 테이블로 이동하는 경우 얻을 수있는 이점 중 하나는 향후 확장에서 필요할 경우 State 테이블에 더 많은 열을 쉽게 추가 할 수 있다는 것입니다. –
세 번째 가능성은 응용 프로그램의 필드에서 조회를 사용하지만 사용자 이름 테이블을 저장하는 것입니다. 그런 다음 조회에서 올바른 값으로 제한된 데이터를 가져오고 테이블의 데이터를 재사용 할 수 있으며 추가 조인을 수행 할 필요가 없습니다. 이것은 룩업 테이블이 상태와 거의 같지 않고 거의 변경되지 않을 때만 실행 가능합니다. 그렇지 않으면 수백만 개의 레코드를 업데이트 할 수 있습니다. – HLGEM