Статьи Королевства Дельфи
Моделирование данных
| Часть I: | Раздел Подземелье Магов |
Этот цикл статей посвящен моделированию данных, т.е. некоторым правилам и рецептам, которыми следует (или не следует) руководствоваться, отображая сeмантику предметной области в набор взаимосвязанных таблиц реляционной СУБД. Тексты статей не являются строгим изложением теории и не претендуют на "научность", а являются лишь попыткой поделиться скромным опытом в этой области.
й Королев.
Дата публикации 28 Февраля 2000 г.
| Часть II: Примеры моделирования данных. |
В нормализованную базу проще записывать данные, однако содержательные запросы к таким базам формулируются достаточно сложно: с вложенными подзапросами, с использованием OUTER JOIN или UNION, с большим количеством таблиц, а это в «боевых» условиях приводит к снижению производительности приложений, отвечающих за «чтение» данных из базы.
Требования к приложениям, отвечающим за запись и чтение данных, достаточно противоречивы, и поэтому в одной системе трудно соединить возможности обработки сотен тысяч транзакций в единицу времени и богатые инструменты анализа данных. По этим причинам системы высшего класса содержат подсистему оперативного накопления данных - для этих целей может использовать нормализованная база данных, и подсистему анализа данных - то, что принято называть хранилищем данных (data warehouse). В информационных системах среднего уровня обе функции - быстрой записи и относительного богатства средств анализа - приходится в той или иной степени совмещать.
Чтобы данные было проще читать, мы их денормализуем. Создание модели данных - процесс творческий, тем не менее, встречается довольно много ситуаций, в которых можно применять стандартные решения, проверенные опытом, хотя тот же опыт показывает, что бывает весьма соблазнительно изобрести собственный велосипед, хоть и без руля. В этом тексте приведено несколько проверенных рецептов для решения задач, часто встречающихся в моделировании данных.
Группировка по дате
Если ваша информационная система работает с экономическими данными, то с вероятностью 100% в запросах вам потребуется группировать значения по неделям, месяцам, годам - какому-нибудь сотруднику отдела продаж обязательно захочется узнать, как изменился уровень продаж в текущем квартале по сравнению с прошедшим. В нормализованной таблице для представления даты вы заводите единственное поле и для того, чтобы сгруппировать значения, например, по месяцам, вам будет необходимо указать выражение в разделе GROUP BY. Однако не все СУБД позволят это сделать, и очевидно, что группировка по выражению будет работать медленно. Возможное решение состоит в добавлении нескольких колонок: для номера года, месяца недели и дня. Значения этих полей можно вычислять внутри триггеров before insert и before update. Группировки будут работать максимально быстро.
