2014-09-10 2 views
0

관계형 데이터베이스 디자인에 익숙하지 않아이 데이터베이스를 올바르게 디자인하기위한 정보 하나를 명확히하려고 노력하고 있습니다. 플랫폼으로 Filemaker를 사용하고 있지만 이것이 보편적 인 질문이라고 생각합니다.관계 데이터베이스 디자인 - 개체가 많거나 많다. 자체 조인 테이블 또는 새 테이블을 사용하여 해결할 수 있습니까?

모든 일대 다 관계가 이상적이며 별도의 테이블을 사용하거나 테이블을 조인하여 이상을 해결하는 논리를 사용합니다.

여러 제품 범주로 여러 브랜드로 만든 여러 제품이있는 데이터베이스가 있습니다. 또한 사용자의 요구가 끊임없이 변하기 때문에 가능한 한 많은 방법으로 데이터를 슬라이스하고 다룰 수있는보고 기능을 최대한 확장 할 수 있기를 바랍니다.

그래서 "각 브랜드에는 여러 제품이 있습니까?"라는 질문을하고 "각 제품에 여러 브랜드가 있습니까?"대답은 아니오입니다. 그래서 이것은 일대 다 관계지만 자체 조인 테이블이 필요한 모든 것을 줄 수도 있습니다.

또한이 방법론은 제품 범주와 같은 다른 "제품 관련"정보에 대한 토끼 구멍을 내린 것처럼 보입니다. 각 제품은 하나의 제품 범주에 묶여 있지만 하나의 제품 범주 만 제품과 관련되어 있습니다.

그래서 두 가지 가능성을 확인하고, 세 개의 테이블을 만들고 기본 및 외래 키와 결합합니다 (하나는 브랜드 용, 하나는 제품 카테고리 용, 다른 하나는 제품 용).

두 번째 가능성은 브랜드와 제품 카테고리 및 제품 정보가 모두 하나의 테이블에 포함되어있는 하나의 테이블을 생성하는 것입니다 (모두 제품 관련이므로). 자체 조인 및 다른 쿼리 기반 테이블을 사용하여 향후보고 요구 사항은 시간이 지남에 따라 변경 될 것입니다.

나는 올바른 방향으로 나를 가리킬 수있는 경험으로부터의 의견을 찾고있다. 사전에

감사합니다!

+0

세 개의 테이블 ... 시도해보고 정상화해야합니다. 데이터에 따라 세 개 이상을 사용하고 슬라이스와 다이스를 어느 정도 필요로 할 수도 있습니다. –

+0

답장을 보내 주셔서 감사합니다. 중복성을 줄이거 나 제거하면 관계 데이터베이스에 "일대 다"테이블이 너무 많습니다. –

+0

다른 열이 다른 데이터를 가지고 있기 때문에 테이블에 데이터를 복제하는 경우 다른 테이블로 나누는 것이 더 좋습니다 :) –

답변

0

자기 조인을위한 공간이 어디에 있는지 잘 모르겠습니다. 나에게는 당신이 말하고있는 것처럼 보인다 : 나는 제품 표를 가지고있다; 각 제품에는 하나의 브랜드와 하나의 (?) 카테고리가 있습니다. 그런 경우는 다음의 경우에 당신은 두 세 개의 테이블이 필요합니다 - 전용 파일 메이커에 -

Brands -<Products>- Categories 

또는 당신이 중 하나를 대체 할 수 또는 값 목록을 모두 브랜드와 카테고리 테이블 (가정 당신이 브랜드 이름을 변경되지 않습니다/범주 및 일부보고 기능이 필요함). 그래서 실제로 어떤 유형의 정보를 최종적으로 내고 싶은지에 달려 있습니다.

0

브랜드 (회사 URL, 전화 번호 등) 또는 제품 범주 (설명 등)에 대한 추가 정보를 저장하고 싶습니까?

대답이 예인 경우 확실히은 3 개의 테이블을 사용하려고합니다. 그렇게하지 않으면 동일한 브랜드 또는 동일한 카테고리에 속한 모든 단일 항목에 대해 모든 정보가 반복됩니다.

대답이 '아니오'인 경우 3 개의 테이블을 사용하면 여전히 이점이 있으므로 오타 또는 기타 철자 불일치가 데이터베이스에 들어 가지 않도록 할 수 있습니다. 예를 들어 일부 품목에서는 '코카콜라'로, 다른 품목에서는 '코카콜라'로 브랜드를 작성하지 못하게됩니다. 이러한 불일치는 데이터베이스가 커짐에 따라 찾아 내고 수정하기가 점점 어려워집니다. 각 브랜드를 자신의 테이블에 한 번만 나열하면 항상 동일한 방식으로 작성됩니다.

여러 테이블의 단점은 쿼리의 SQL이 더 복잡하다는 것입니다. 분명히 절충안이 있지만 의심 스러울 때는 여러 테이블로 정규화하십시오. 더 많은 경험으로 비정규 화하는 것이 더 나을 때를 배웁니다.

0

솔루션을 확장 가능한 상태로 유지하려면 지금 데이터를 구문 분석하고 파티션해야합니다. 그렇지 않으면 솔루션의 크기가 커지면서 솔루션을 다시 구조화해야합니다. 또한 파싱하고 새 테이블로 데이터를 재배치해야합니다. Filemaker를 외부 데이터 소스에 연결하려는 경우 SQL 및 MySQL 태그도 포함되었으므로 게임을 구조적으로 향상시켜야합니다. 하나 개의 테이블에있는 모든 건물

은 본질적으로 엑셀 작업을 할 파일 메이커를 사용하고 등 SQL, MySQL은,

자체에 연결하는 경우 그것을 잘라하지 않습니다 것은 테이블이 훌륭한 도구입니다 가입 할 수 있습니다. 그러나 실제로는 작은 데이터 요소를 계산할 때만 사용해야하며보고 기능의 피벗 점이나 기초로 사용해서는 안됩니다. 시간이 지남에 따라 통제가 어려워지고 백엔드를 깨끗하게 유지해야합니다.

요약 및 하위 요약보고 기능을 사용하여 제품 기반 데이터를 조각화합니다.

Filemaker/SQL/또는 "Brand"또는 "Vendor"에 관계없이 소매 및 일반 제품 관리 솔루션의 경우 자체 테이블입니다. 그런 다음 "제품"테이블 (일치 키는 "브랜드 ID")을 갖게됩니다.

"제품 범주"필드는 "제품"테이블의 필드 여야합니다. 표준 값 목록을 작성하거나 "Product Category"테이블을 기반으로 값 목록을 작성하여 범주 값을 관리 할 수 ​​있습니다. 두 번째 시나리오는 장기간 관리에 더 좋습니다.