14. Пример задания свойств связи между сущностями «Заказчик» и «Заявка»

Следующей важной задачей логического проектирования является определение групп (ролей) пользователей и их прав в БД. Для этого автоматизируемые функции разбиваются на группы в соответствии с задачами пользователей в предметной области. Так, в рассматриваемом примере появится группа диспетчеров, осуществляющих прием заявок, проектировщиков, формирующих смету и техническую документацию, бухгалтеров, администратора БД и т.д. Группам даются понятные имена, ставятся в соответствие данные (таблицы и столбцы таблиц), для которых устанавливаются необходимые права доступа (включение, удаление, чтение, изменение). Для пользователей определяются учетные записи, которые распределяются по группам.

Материалы данного этапа, обосновывающие результат логического проектирования, включаются в основную часть пояснительной записки.

Для описания структуры таблиц можно использовать нотацию выбранной СУБД. Схема реляционной БД в нотации СУБД MySQL представлена на рисунке 345. Схема реляционной БД в нотации СУБД MS SQL Server представлена на рисунке 347.

Добавить рисунки

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

3.3 Содержание раздела «Физическое проектирование базы данных»

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

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

• количество и типы используемых носителей информации;

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

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

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

• способы и средства обеспечения надежности (резервирования и восстановления) данных.

Описание таблиц в пояснительной записке

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

Таблица 1 – Структура таблицы Users

Наименование поля	Тип поля	Назначение	Заполнение
Id	int	Первичный ключ	автозаполнение
Users	varchar	Название учетной записи	обязательно
Indentifical	varchar	Пароль в зашифрованном виде	обязательно
Date_beg	datetime	Дата начала действия	обязательно
Date_end	datetime	Дата окончания действия
Working	bit	Признак окончания действ.
Foto	image	Автор (Фотография)
S1	bit	Признак доступа к справочнику «Подразделений и отделов»	обязательно (умолч. - false)
S2	bit	Признак доступа к справочнику «Источники финансовых средств»	обязательно (умолч. - false)
S3	bit	Признак доступа к справочнику «Статей расходов и материалов»	обязательно (умолч. - false)
Rpln	bit	Признак доступа к модулю «Роспись плана»	обязательно (умолч. - false)
Lpln	bit	Признак доступа к модулю «Учет изменений в росписи плана»	обязательно (умолч. - false)
Rgpln	bit	Признак доступа к модулю «Роспись годового плана государственных закупок»	обязательно (умолч. - false)
Lgpln	bit	Признак доступа к модулю «Учет изменений в росписи годового плана государственных закупок»	обязательно (умолч. - false)
del	bit	Признак доступа к модулю «Удаление данных из справочников»	обязательно (умолч. - false)

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

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

Решения, принимаемые на этапе физического проектирования, мало влияют на логические возможности обработки данных, но в значительной мере определяют времена выполнения запросов и объемы расходуемой памяти. Использование средств, предоставляемых СУБД для физического проектирования, позволяет увеличить скорость выполнения одних запросов за счет дополнительного расхода памяти и снижения скорости других. Задача разработчика БД - обеспечить максимальную эффективность работы с БД за счет повышения производительности наиболее частых запросов.

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

Вопросы физического проектирования освещаются в пояснительной записке в разделе «Физическое проектирование».

Если на предыдущих этапах в процессе обследования, документирования и проектирования БД использовались средства автоматизации разработки информационных систем (CASE средства), то основная часть работы по написанию скрипта и генерации базы может быть выполнена автоматически используемым CASE средством. При ручном проектировании в создании базы участвуют только средства используемой СУБД.

Заканчивается процесс проектирования созданием структуры БД и учетных записей пользователей в выбранной СУБД. При этом необходимо стремиться представить в определении объектов базы наибольшее количество свойств предметной области с тем, чтобы максимально разгрузить приложение от проверки правильности данных и целостности базы. В зависимости от выбранной СУБД структура данных создается либо в интерактивном режиме с помощью графического интерфейса, либо написанием скрипта (программы на DDL), который создает новую пустую БД. При любом способе создания необходимо предусмотреть возможность быстрого восстановления структуры базы данных (копированием, выполнением сценария и др.).