2016-04-12 4 views
0

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

Модель данных будет использоваться для хранения атрибутов местоположения и маркетинга.

Когда клиент посещает один из веб-сайтов компании, они будут вводить свой почтовый индекс и в соответствии с их местоположением атрибуты будут использоваться для организации онлайн-каталога товаров.

Каталог элементов будет отделен от базы данных, поэтому модель данных будет выдавать только атрибуты, используемые для упорядочивания элементов. Каждый элемент в каталоге имеет такие атрибуты, как ItemNumber, Price, Condition, Manufacture и маркетинговые сегменты (Возраст: Взрослый, Образование: Колледж, Доход: Высокий и т. Д.).

**For example:** 
**Input zip code**: 90210 
**Output Attributes**: (ItemNumber:123456, Segment:HighIncome, Condition:New) 

Этот пример говорит для почтового индекса 90210, первый пункт шоу # 123456, а затем все элементы с сегментом высокими доходами, а затем отобразить все не-отремонтированы пунктов.

До сих пор у меня есть 2 таблицы со многими отношениями, и я хотел бы добавить дополнительную таблицу (ы), чтобы я мог включить логику (AND & OR).

В первой таблице будет указана местонахождение и другая информация о том, на каком из сайтов компании находится пользователь.

Table Location(
Location_Unique_Identifier number 
ZipCode varchar2 
State varchar2 
Site varchar2 
.. 
) 

Вторая таблица будет иметь типы атрибутов (производство, Цена, состояние и т.д.) и значения атрибутов (IBM, 10,00, Восстановленное и т.д.).

Table Attributes(
Attribute_Unique_Identifier number 
Attribute_Type varchar2 
Attribute_Value varchar2 
.. 
.. 
) 

В промежутке между этими двумя таблицами, чтобы разбить многие на многие отношения, я бы добавил логическую таблицу. Эта таблица должна позволять мне выводить

item#123456 AND (item#768900 OR Condition:New) 

Проблема, которую я имею с логической таблицы пытается сделать его достаточно гибким, чтобы обрабатывать неизвестное количество AND/ОШ и обрабатывать группировку.

+0

Таблицы используются для представления фактов, а не логики. Логика переходит к запросам и хранимым процедурам. Кроме того, не перерабатывайте базу данных внутри базы данных (ссылаясь на вашу таблицу атрибутов). Таблицы EAV (Entity-Attribute-Value) обычно плохие. – reaanb

ответ

0

Это типичный сценарий совместного использования двух (многих) таблиц, чтобы сделать AND/OR/XOR или что-то еще логичное.

Лучшим выбором является построение метрического представления, которое денормализует атрибуты из нескольких таблиц вместе в одну таблицу (эта таблица называется представлением).

В вашем случае представление может быть:

table location_join_attributes{ 
    number, 
    zipcode, 
    state, 
    site, 
    Manufacture, 
    Price, 
    Condition, 
    ...... 
} 

Тогда вы будете управлять логическим продолжением этой таблицы/вид, как (модифицированный из вашего примера):

item#123456 OR (item#768900 AND Condition:New) AND (more condition) 

Если мы делаем не имеет этого представления, эта операция сначала выберет все записи, имеющие элемент # 768900, а затем отфильтруйте вторую таблицу, чтобы узнать, какие из них имеют условие: новое. Это займет много времени. Если условие сложное, производительность ужасная.

Для быстрого запроса вы должны создать вторичные индексы в столбцах, которые вы используете.

С точки зрения масштабируемости, если ваша бизнес-логика изменяется, вы можете создать новое представление, а старшее будет отброшено. Исходные таблицы не меняются, что также является одним из преимуществ материализованного представления.

 Смежные вопросы

  • Нет связанных вопросов^_^