그 표는 Inmons 3NF 방식 (메신저 Northwind 데이터베이스 작업) 일치 : 나는 주소 일을 반복하고 좀 심지어 원자하지 계속 발견이 변경 사항이 northwind 데이터베이스의 3NF와 일치합니까? 내가하고 싶습니다
을 그래서 내가 서로를 넣어하기로 결정 이런 식으로 "주소"라는 그림에서 테이블 :
이 올바른 방법인가? 테이블 주소는 어쨌든 모든 주소를 저장하므로 다른 모든 테이블과 공유 할 수 있습니까?
감사
귀하의 솔루션이 유효하고 확실히 더 정규화된다.
그러나 아직 3NF에 없습니다. 엄밀히 말하자면, 3NF에있는 테이블의 경우 키가 아닌 상호 종속성이 없어야합니다. 예를 들어, 도시와 국가 간 이러한 종속성이 있습니다. 그래서 누군가 파리에 들어올 때마다 프랑스에 입국해야합니다. 누군가가 우연히 독일 파리에 들어간다면 이것은 예외로 이어질 수 있습니다. 3NF의 경우 도시와 해당 국가를 저장하는 City 테이블을 추가로 만들어야합니다. 도시는 키가 될 것이며, 국가는 키가 아닌 속성 일 것입니다. 주소 테이블에는 도시에 대한 외래 키가 있습니다. 간결함을 위해 우편 번호와 지역은 생략되었지만 표준화에 포함시켜야합니다. 그래서이 3NF를 만들려면 몇 개의 엔티티가 더 필요합니다.
이 복잡성 때문에 Kimball의 스타 스키마가 Inmon의 3NF 접근 방식보다 더 인기가 있습니다.
