в общих чертах некоторые задачи,
В этой лекции рассматриваются в общих чертах некоторые задачи, которые должен решить проектировщик базы данных в процессе проектирования базы данных.
Даже хорошо спроектированная база данных ничего не стоит без приложений, которые обеспечивают ее жизнедеятельность, переводя ее из одного актуального состояния в другое и тем самым удовлетворяя потребности пользователей в информации. При этом пользователи ждут программ, которые помогали бы им решать их задачи быстро и обладали широкими возможностями поиска и обработки информации. Поэтому проектировщику базы данных следует также обратить внимание на проектирование модулей приложений, которые будут дополнять базу данных.
Как уже отмечалось выше, на этапе анализа аналитики ИТ-проекта разрабатывают функциональную модель предметной области. Эта модель является входными данными для этапа проектирования модулей приложений базы данных.
Элементы функциональной модели позволяют описать функции обработки данных, организовать их в соответствии с бизнес-требованиями и, следовательно, построить отображения этих функций в набор определений модулей приложений. При этом следует придерживаться следующих двух правил: избегать создания дублирующего кода и стараться не создавать больших модулей со сложной логикой.
Как правило, проектирование модулей приложений выполняется параллельно с проектированием физической структуры базы данных. Эти две задачи взаимосвязаны. Практически любое решение в моделировании данных почти всегда выгодно для одних модулей и создает проблемы для других.
Пример. Предположим, что при поиске одного вида структурированного документа, размещенного в таблице базы данных, используются два идентификатора: внутренний номер организации, генерируемый системой, и аббревиатура организации (краткое наименование). Наличие в базе данных этих колонок есть проектное решение. На экранной форме поиска (модуль приложения) в таких документах используются два раскрывающихся списка. Один список сформирован по номеру организации, а другой - по ее аббревиатуре.
Поддержка двух идентификаторов, фактических определяющих однозначно одну и ту же организацию, создает следующую проблему для модуля ввода документа: при ошибке в наборе аббревиатуры одна и та же организация будет иметь два кратких наименования. Чтобы избежать такой ситуации, в модуле ввода документа должен быть предусмотрен код, который обеспечивает ввод аббревиатур через раскрывающийся список, а в модуле ввода данных об организациях предусмотрено, чтобы поле аббревиатуры было не пусто.
Поэтому проектировщик базы данных должен учитывать последствия выбираемых им решений и выбирать компромиссный вариант.
