Борьба с проблемой моделирования данных

Question

Я борюсь с моделью данных (я использую MySQL для базы данных). Мне неловко от того, что я придумала. Если бы кто-то мог предложить лучший подход или указать на какой-нибудь справочный материал, я был бы признателен за это.

Данные будут иметь организации многих типов. Я пытаюсь сделать 3 уровня классификации (класс, категория, тип). Скажем, если у меня есть «Итальянский ресторан», он будет иметь следующую классификацию

Услуги по питанию> Рестораны> Итальянские

Однако организация может принадлежать нескольким группам. Ресторан также может служить китайский и итальянский. Таким образом, он будет вписываться в 2 классификации

Услуги по питанию> Рестораны> Итальянские
Питание> Рестораны> Китайская

Справочные таблицы классификации будут выглядеть следующим образом:

ORG_CLASS (RowId, ClassCode, ClassName)

1, FOOD, Food Services

ORG_CATEGORY (RowId, ClassCode, CategoryCode, CategoryName)

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 классификации. У меня будет 3 GroupIds, каждый из которых указывает на строку в ORG_TYPE. Итак, у меня есть 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, category, type, а соответствующий GroupId может быть заполнен rowid из таблицы ORG_TYPE.

Во время поиска, если выбраны все три классификации, это будет более конкретно. Например, если

Услуги по питанию> Рестораны> Итальянский критерий, где пункт будет 'where OrgGroupId1 = 100'

Если выбраны только 2 уровня

Общественное питание> Рестораны

Я должен сделать 'where OrgGroupId1 in (100,101,102,103,104,105, .....)' - В этом списке может быть сотня

Я запрещу поиск на уровне класса. То есть заставлю выбор класса и категории

Идентификаторы будут целыми числами. Я пытаюсь увидеть проблемы с производительностью и другие проблемы.

В целом, это будет работать? или мне нужно выбросить это и начать с нуля.

Answer 1

Мне не нравится наличие трех столбцов для классификации «до трех».По моему мнению, было бы лучше иметь таблицу перекрестных ссылок, которая позволяет сопоставлять многие многие для организации и типа, то есть таблицу ORGANISATION_GROUPS со столбцами OrganisationId, OrgGroupId.

Чтобы разобраться с проблемойвозможность запрашивать разные уровни указанной классификации, вы можете настроить эту таблицу перекрестных ссылок для хранения фактических классификаций, т. е. вместо ORGANISATION_GROUPS есть столбцы: OrganisationId, ClassCode, CategoryCode, TypeCode.

Это будет выполнять запросы на разных уровняхклассификации очень просто.

Чтобы ссылочная целостность работала с этой схемой, я бы тогда предложил не использовать суррогатные целочисленные ключи для ваших таблиц ORG_ *, а вместо этого установить первичный ключ в качестве реального уникального ключа, то есть ClassCode,CategoryCode, TypeCode для ORG_TYPE.

Answer 2

Проблема, которую я вижу в вашем дизайне, заключается в том, что он немного жесткий.Более гибкий подход, который вы можете рассмотреть, заключается в следующем:

Сначала у вас будет таблица для классов, категорий, типов и любого другого типа классификации.Эта таблица будет автоматически ссылаться.Все регистры будут иметь поле, ссылающееся на его непосредственного родителя, например:

КЛАССИФИКАЦИЯ (Id, Description, Parent_Id)

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

Далее вы должны иметь, какРекомендуется раскладка @John, промежуточная таблица перекрестных ссылок между таблицей вашего ресторана (или чем угодно) и классификационной таблицей, которая будет содержать только составной первичный ключ, а его компоненты являются первичным ключом обеих таблиц.

FOODSERVICE_CLASSIFICATION (Rest_Id, Class_Id)

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

Желательно ограничить его, чтобы в таблице перекрестных ссылок можно было ссылаться только на листовые регистры таблицы CLASSIFICATION.

Ваш пример поиска всех ресторанов будет таким же простым, как поиск всех дочерних категорий REST и поиск их в таблице перекрестных ссылок.Это можно записать в Oracle в виде единого выбора (не уверен насчет других СУБД).

Таким образом, вы можете:

• иметь несколько категорий для ваших ресторанов, не ограничиваясь тремя категориями.
• Выполните быстрый поиск с использованием таблицы перекрестных ссылок.

Обратите внимание, эта схема будет работать, если предположить, что ваша категоризация похожа на дерево с базовой категорией, действующей в качестве корня.Если вместо этого вам нужна более свободная категоризация, вам, вероятно, понадобится подход с использованием тегов.

Кстати, я также согласен с @John Pickup, что в этом случае лучше использовать реальные первичные ключи.

HTH