64 Как можно улучшить структуру бд? Оптимизация структур данных

Правильно построенная модель БД позволяет избежать проблем со скоростью доступа к информации, а также обеспечивает возможность дальнейшего масштабирования БД и подключения дополнительных источников данных. Хорошо построенная модель данных может сделать систему быстрой, гибкой и функциональной. Критериями оптимальности модели БД являются скорость поиска, уменьшение числа связей таблиц, стандартизация структур данных. Модель БД должна содержать структуры таблиц, отражающие измерения во времени или жизненный цикл объекта хранения в БД, а также статические свойства объектов (атрибуты метаданных). Избегайте добавления новых полей в БД, иначе рано или поздно экран ввода информации будет представлять собой форму с множеством полей. А главное никто не будет заполнять все поля этой формы. Модели данных должны быть построены для физического уровня хранения данных, усвоения данных на уровне бизнес-логики и для презентационного уровня, рис.1.

Рисунок 1 - Схема уровней представления данных [12]

Физический уровень отвечает за сбор информации из используемых источников данных, их очистку, агрегацию и загрузку в БД. На проектирование физической модели БД влияют следующие параметры СУБД:

• размер табличных пространств для хранения таблиц, индексов, полей BLOB;

• кластеры и их параметры;

• размер словаря данных, включая все хранимые процедуры, функции, триггеры, пакеты, команды SQL;

• управляющие файлы;

• файлы журнала работы процессов;

• интенсивность потока запросов, модифицирующих данные и индексы;

• файлы временных табличных пространств (для хранения временных таблиц, которые строятся, например, при выполнении group by, а также других временных объектов);

• интенсивность потока запросов, инициирующих создание временных таблиц;

• потоки транзакций read-write, read-only, объем модифицируемых и считываемых ими данных, характеристики параллельной работы транзакций (какие и сколько их);

• количество приложений, работающих параллельно с БД;

• количество соединений с БД для каждого приложения;

• файлы параметров старта ядра СУБД;

• загрузочные модули ядра и утилиты СУБД;

• входные и выходные данные, генерируемые пользовательскими программами;

• скрипты управления СУБД.

Уровень бизнес-логики преобразует данные из структур физического уровня в структуры, предназначенные для решения конкретных задач. Здесь происходит вычисление показателей и индикаторов, строятся иерархии, и для каждой предметной области связываются в схемы, используемые в ней таблицы фактов и метаданных. Правильно построенная модель бизнес-логики обеспечивает конечных пользователей полноценным для решения поставленных задач набором показателей, а также позволяет добавлять новые предметные области и описывать дополнительные объекты [2,3].

Модель бизнес-логики является самым сложным объектом БД. Модель бизнес-логики должна быстро адаптироваться под требования бизнеса, повышать в конечном итоге его успешность. Модель должна позволять оперативно создавать и изменять сотни показателей, измерений. Аналитик должен достаточно быстро выбрать список необходимых показателей и затем очень долго подбирать набор условий, которыми он хочет ограничить выборку и в разрезе которых рассчитать эти показатели. Причем сначала он использует одно условие, затем, увидев результат, накладывает дополнительное условие и т.д. Таким образом, оптимальность модели во многом зависит от того, насколько быстро аналитик сможет определить набор условий в виде списка показателей, которыми он хочет ограничиться. Для каждой задачи рекомендуется создать отдельное view-представление показателей и индикаторов, действительно необходимых для ее решения [6]. На уровне модели бизнес-логики можно проводить расчет показателей, алгоритм вычисления которых может изменяться. Такой подход позволяет избежать проблем с показателями, которые в разных случаях должны рассчитываться по-разному, а также повысить скорость и удобство работы конечного пользователя, предоставляя ему действительно необходимый для поддержки решения набор атрибутов.

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

Рекомендации. Создавайте стабильные и легко поддерживаемые структуры. Сведение нескольких таблиц к view-представлению означает, что большинство изменений затронет только одну таблицу. Рекомендации по использованию структур данных [1]:

• храните множество используемых классификаторов в одной таблице за счет добавления нового атрибута «Идентификатор классификатора»;

• используйте счетчики повторяющихся групп в иерархических структурах данных;

• применяйте многомерные структуры при необходимости создания множества таблиц для родственных объектов и словари атрибутов для обозначения свойств атрибутов;

• создавайте каталоги данных для организации хранения и поиска объектных файлов (документов, графических файлов, др.);

• типизируйте структуры данных для временных рядов, сеточных данных, каталогов;

• разрабатывайте обобщенные атрибуты данных, например, вместо создания для каждого произведенного товара своего имени атрибута (количество компьютеров, ТВ, холодильников, др.), используйте следующие атрибуты: Товар: тип, Товар: объем, Товар: единица измерений;

• не детализируйте сущности, а создавайте общую концепцию и выделяйте основные сущности;

• описываемые сущности храните в XML-схемах, что позволяет добавлять объекты и атрибуты без вероятности потери ранее записанных данных и без необходимости глубоко изучать предметную область;

• для всех сущностей выделяйте общие поля (идентификатор, дата/время создания, дата/время редактирования, автор, в том числе поля для организации связи между сущностями и т.д.);

• пользовательский интерфейс создавайте в виде синхронизированных атрибутов на основе их значений в БД.