Курсовая ПрБД, 2 курс 3 семестр (для ИВТ и т.п.) / ПБД_метод к КР_v07[2024-2025]

Даже в тех случаях, когда связь между двумя сущностями необязательная, стоит подумать об их объединении, с учетом того, что часть полей в записях не будет заполняться. Руководствоваться в таких случаях надо из тех же соображений, что и при использовании производных данных. Например, в компании работают служащие, занятые полный рабочий день (постоянные служащие), совместители и консультанты. Если эту иерархию оставить без изменений, то в БД будет четыре сущности (Сотрудник, Постоянный сотрудник, Совместитель и Консультант), согласованность которых надо будет поддерживать. При выполнении запросов по сотрудникам надо будет оперировать четырьмя таблицами. Таким образом, лучше в БД вместо иерархии запроектировать одну таблицу, в которую добавить атрибуты «Ставка» и «Организация». В атрибуте «Ставка» для постоянного сотрудника всегда будет значение «1», а атрибут «Организация» будет заполняться только для консультантов. Несмотря на избыточность, такая замена с точки зрения обработки данных и эксплуатации более выгодна.

1.2.2) Дублирование атрибутов в связях типа 1:M

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

1.2.3) Использование служебных таблиц (справочных таблиц, клас-

сификаторов, типовых списков значений)

Служебные таблицы, как правило, создаются для атрибутов символьного типа, значения которых могут выбираться из строго определенного и ограниченного списка. Например, значениями атрибута должность могут быть только «Системный аналитик», «Разработчик», «Тестировщик», «Руководитель проекта».

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

Использование служебных таблиц дает следующие преимущества:

21

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

oуменьшается размер исходной таблицы;

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

1.2.4) Введение повторяющихся (многозначных) атрибутов

Для достижения большей производительности при выполнении часто вызываемых запросов может быть целесообразным подход сохранения многозначных атрибутов, чем вынесение их в отдельную таблицу. Например, если количество контактных телефонов у филиала компании невелико (до 10), эта величина постоянная и не увеличится со временем, то в таблице «Филиал» можно предусмотреть атрибуты «Номер телефона 1», …, «Номер телефона 10».

1.2.5) Создание сводных таблиц

Если нагрузка на БД в часы пик велика, а период актуальности отчетов, составляемых на основании данных, – сутки и более, то следует подумать о включении в БД сводных таблиц, обновляемых в часы минимальной нагрузки на БД.

2) Перенос логической схемы данных в среду целевой СУБД

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

–доменов;

–первичных, альтернативных и внешних ключей;

–неопределенных (NULL) и обязательных (NOT NULL) значений;

–значений по умолчанию (DEFAULT);

–правил контроля целостности.

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

22

синтаксиса, принятой в целевой СУБД (соблюдение правил наименования таблиц, атрибутов, типов данных и т.д.).

3) Реализация бизнес-правил и анализ транзакций

Реализацию бизнес-правил можно включить в SQL-операторы создания таблиц (CREATE TABLE опция CHECK для полей или таблицы в целом) или в триггеры (CREATE TRIGGER).

После реализации бизнес-правил необходимо проверить выполнимость и эффективность (время отклика, скорость выборки, объем задействованных данных) выполнения всех транзакций.

4) Разработка механизмов защиты

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

4.1) Разработка пользовательских представлений (видов)

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

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

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

4.2) Определение прав доступа (привилегий)

В СУБД, поддерживающих SQL, возможно выполнение запросов от имени определенного пользователя, которое задается администратором БД. Каждый пользователь обладает строго определенным набором прав (привиле-

23

гий) в отношении конкретной таблицы или представления. Наделение правами выполняется с помощью оператора GRANT, отмена – REVOKE. Операции, на которые можно назначить права: SELECT, INSERT, DELETE и UPDATE. Кроме того, возможно задание передачи прав от одного пользователя к другому.

5) Организация мониторинга и настройка функционирования системы

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

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

2Пример проектирования реляционной БД

Вкачестве примера будет рассмотрена БД организации системы контроля доступа для предприятия. Под понятием «Система контроля и управления доступа» (СКД или СКУД) понимается совокупность технических средств, направленных на контроль входа и выхода в помещение с целью обеспечения безопасности и регулирования посещения определённого объекта.

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

Главными задачами систем контроля являются:

−наложение ограничений на вход;

−допуск в помещение определённому кругу лиц;

24

−контроль рабочего дня;

−обеспечение безопасности;

−расчет зарплаты, при интеграции с бухгалтерской системой.

Как правило, системы контроля и управления доступом имеют следующие составляющие:

−преграждающее устройство (электромагнитные замки, двери, тур-

никеты);

−идентификатор (карточка, брелок, отпечаток пальца);

−контроллер – механизм, определяющий пропускную возможность идентификатора;

−считыватель – устройство, определяющее код идентификатора и передающее его на контроллер.

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

2.1Пример построения концептуальной схемы

На следующем рисунке показан фрагмент концептуальной модели для СКУД (Рис. 12). Схема разработана в программном продукте DBDisigner.

В концептуальной схеме выделены следующие логические блоки дан-

ных:

1)Справочники (нормативно-справочная информация):

−действия;

−тип пропуска;

−тип пользователя;

−кабинет;

−считыватели.

2)Информация о пользователях:

−пользователь;

−пропуск;

3) Отчетная (оперативная) информация:

−выданные пропуска;

−нахождение в кабинете.

25

Рис. 12. Концептуальная модель

2.2Пример построения логической схемы БД

На Рис. 13 приведена логическая схема, построенная с помощью case-продукта DBDesinger. Данная модель соответствует третьей нормальной форме.

26

Рис. 13. Логическая модель

2.3Пример построения физической схемы

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

27

Рис. 14. Физическая модель Структура и характеристики сущностей приведены в табл. 1 – 10.

28

Таблица 3

Настройка прав (SettingPermissions)

Таблица 5

Выданные пропуска (PassesIssued)