데이터 모델링 문제로 어려움을 겪고 있습니다.

Question

데이터 모델로 어려움을 겪고 있습니다. 나는 내가 생각해내는 것에 대해 불안하다. 누군가가 더 나은 접근법을 제안 할 수 있거나 나에게 약간의 참고 사항을 가르쳐 주면 고맙겠습니다.

데이터에는 여러 유형의 조직이 있습니다. 나는 3 수준 분류 (클래스, 범주, 유형)을하려고합니다. 나는 '이탈리안 레스토랑'을 경우, 그것은 다음과 같은 분류

을해야합니다 말 식품 서비스> 레스토랑> 그러나, 조직이 여러 그룹에 속할 수

이탈리아어. 레스토랑은 중국어와 이탈리아어를 제공 할 수도 있습니다. ,

ORG_CLASS (RowId가, ClassCode : 그래서 2 분류

식품 서비스

> 레스토랑> 이탈리아어
음식 서비스> 레스토랑>

중국어

참조 테이블은 다음과 같이 될 것입니다 분류에 맞는 클래스 이름)

1, FOOD, Food Services 

ORG_CATEGORY (RowId가, ClassCode, CategoryCode

내가 허용됩니다, 범주)

1, FOOD, REST, Restaurants 

ORG_TYPE (RowId가, ClassCode, CategoryCode, TypeCode를, TYPENAME)

100, FOOD, REST, ITAL, Italian 
101, FOOD, REST, CHIN, Chinese 
102, FOOD, REST, SPAN, Spanish 
103, FOOD, REST, MEXI, Mexican 
104, FOOD, REST, FREN, French 
105, FOOD, REST, MIDL, Middle Eastern 

실제 데이터 테이블은 다음과 같이 될 것이다 조직 최대 3 분류. ORG_TYPE에서 각 행을 가리키는 3 개의 GroupId가 있습니다. 그래서 나는이 내 ORGANIZATION_TABLE

ORGANIZATION_TABLE (OrgGroupId1, OrgGroupId2, OrgGroupId3, ORGNAME, OrgAddres)

100,103,NULL,MyRestaurant1, MyAddr1 
100,102,NULL,MyRestaurant2, MyAddr2 
100,104,105, MyRestaurant3, MyAddr3 

데이터, 대화 상자가 사용자가 clssa, 카테고리, 유형을 선택할 수 있도록 할 수 추가하고 해당시 GroupId는 ORG_TYPE 테이블의 rowid로 채울 수 있습니다.

검색하는 동안 세 가지 분류를 모두 선택하면보다 구체적입니다. 예를 들어,

음식 서비스> 레스토랑 경우> 이탈리아어 절은 될 기준의입니다 'where OrgGroupId1 = 100'

단지 2 수준

음식 서비스> 레스토랑

내가해야 할을 선택하는 경우 'where OrgGroupId1 in (100,101,102,103,104,105, .....)' - 그 목록에 백 개가있을 수 있습니다

나는 수업 수준 검색을 허용하지 않을 것입니다. 그것은 클래스와 카테고리를 강제로 선택합니다.

ID는 정수입니다. 성능 문제 및 기타 문제를 확인하려고합니다.

전반적으로 이것이 효과가 있습니까? 아니면 이것을 밖으로내어 처음부터 시작해야합니다.

Answer 1

"최대 3 개"분류에 3 개의 열이있는 것을 좋아하지 않습니다. 제 생각에는 조직과 유형 (OrganisationId, OrgGroupId 열이있는 ORGANISATION_GROUPS 테이블) 간의 다 대다 매핑을 허용하는 상호 참조 테이블을 만드는 것이 좋습니다.

서로 다른 수준의 분류를 쿼리 할 수있는 문제를 해결하려면이 교차 참조 표를 실제 분류를 유지하도록 설정할 수 있습니다. 즉, ORGANISATION_GROUPS에는 OrganisationId, ClassCode, CategoryCode, TypeCode 등의 columnns가 있습니다.

이렇게하면 다양한 분류 수준의 쿼리를 매우 쉽게 만들 수 있습니다.

이 체계에서 참조 무결성을 유지하려면 ORG_ * 테이블에 대리형 정수 키를 사용하지 말고 기본 키를 ORG_TYPE의 ClassCode, CategoryCode, TypeCode 등의 실제 고유 키로 설정하는 것이 좋습니다.

Answer 2

디자인에 나타나는 문제점은 약간 딱딱한 점입니다. 고려해야 할 더 유연한 접근 방식은 다음과 같습니다.

먼저 클래스, 카테고리, 유형 및 기타 분류 유형에 대한 테이블을 갖게됩니다. 이 테이블은 자동으로 참조됩니다.

분류 (ID, 설명, PARENT_ID) @ 존 픽업 제안대로 할 것이다

ITAL, Italian, REST 
CHIN, Chinese, REST 
MEXI, Mexican, REST 
REST, Restaurant, FOOD 

다음, 중간 크로스 : 모든 레지스터는 다음과 같이 그 바로 위 부모를 참조 필드 것 (또는 무엇이든간에) 테이블과 복합 기본 키만 포함하는 분류 테이블 사이에 - 참조 테이블을 생성합니다. 그 구성 요소는 두 테이블의 기본 키입니다.

FOODSERVICE_CLASSIFICATION (Rest_Id, CLASS_ID)

100, ITAL 
100, CHIN 
101, MEXI 
102, CHIN 

분류 테이블의 잎 레지스터는 상호 참조 테이블에서 참조 할 수 있도록 제한하는 것이 바람직 할 것이다.

모든 레스토랑을 찾는 예는 REST의 모든 하위 카테고리를 찾고 상호 참조 테이블에서 검색하는 것처럼 간단합니다. 이것은 오라클의 단일 선택으로 작성 될 수 있습니다 (다른 RDBMS에 대해서는 확실하지 않음). 당신이 할 수있는

이 방법 :

• 3 개 종류에 한정되지 않고 레스토랑에 대해 여러 분류가 있습니다.
• 상호 참조 테이블을 사용하여 빠른 검색을 수행하십시오.

이 스키마는 분류가 루트로 작동하는 기본 범주가있는 트리와 같다고 가정 할 때주의해야합니다. 대신 좀 더 느슨한 분류가 필요하다면 태그 접근 방식이 필요할 것입니다.

Btw 또한 @John Pickup에 동의합니다.이 경우 실제 기본 키를 사용하는 것이 좋습니다.

HTH