Реализация транзакций средствами выбранной СУБД
В специализацию транзакций необходимо добавить все транзакции, поддерживающие ПИ, если они еще не включены. Часть этих транзакций можно реализовать внутренними средствами СУБД.
В курсовой проект включаются 10 реализованных средствами СУБД транзакций. Описание реализованных транзакций делается в виде таблицы (см. таблицу №3.2)
Таблица №3.2. Описание реализованных в СУБД MS Access транзакций.
| Имя или номер транзакции по спецификации транзакции | Форма реализации | Имя реализации. |
| Т12. Выбор сотрудников с должностью оператор | Запрос | Операторы |
| Т27. Список договоров, содержащий информацию об арендованных объектах | Сохраняемый запрос | Список_договоров |
В первой колонке не обязательно указывать саму транзакцию, как приведено в таблице. Достаточно указать ее номер по спецификации.
Анализ транзакций на этапе физического проектирования.
Целью анализа является определение функциональных характеристик транзакций, которые будут выполняться в базе данных, и выделение наиболее важных из них.
Для того чтобы разрабатываемый физический проект базы данных обладал требуемым уровнем эффективности, необходимо получить максимум сведений о тех транзакциях, которые будут выполняться в проектируемой базе данных. Нам потребуются как качественные, так и количественные характеристики. Для каждой транзакции необходимо знать следующее:
· ожидаемая частота выполнения транзакций;
· отношения и атрибуты, к которым потребуется иметь доступ при выполнении транзакции, а также тип этого доступа ( R – выборка, I – вставка, U – обновление, D – удаление );
· ограничения, устанавливаемые на время выполнения транзакций.
Во многих случаях проанализировать все транзакции просто невозможно, поэтому необходимо выбрать из них самые «важные». В схеме, на которой проводился анализ транзакций на этапе логического проектирования (см. рис. 3.1), надо установить, какие из отношений наиболее интенсивно используются при выполнении транзакций. Для этого необходимо посчитать количество входящих в каждую сущность стрелочек. Например, в нашем случае получается следующее:
| Сущности | Количество входящих стрелочек |
| Персонал | |
| Менеджеры | |
| Операторы | |
| Договор |
Так как в нашем примере анализировалось небольшое количество транзакций, то количество входящих стрелочек для всех сущностей примерно одинаково. Обычно 2-3 сущности имеют значительно большее количество, чем все остальные. На этапе физического проектирования целесообразно анализировать только те транзакции, которые включают обращения к отношениям с большим количеством входящих стрелочек. В нашем случае это сущности «Персонал» и «Операторы», через которые проходят все заявленные в нашем примере транзакции. Обычно остается для анализа на физическом этапе проектирования около 80% всех транзакций.
Далее необходимо указать ожидаемое количество строк в отношениях, а также среднюю и максимальную кратности каждой связи (см. рис. №3.3). Например, ожидается, что персонал компании составит 50 человек, 4 из которых менеджеры, 40 операторов. Компания владеет 500 объектами жилья, на которые заключается 1000 договоров.
Рис. № 3.3. Указание ожидаемой размерности отношений и связи.
При анализе каждой из транзакций очень важно знать не только среднее и максимальное количество ее вызовов в час, но и иметь сведения о тех днях недели и часах суток, когда она обычно выполняется, включая и данные о времени пиковой нагрузки. Например, частота вызова некоторых транзакций может удерживаться на некотором уровне постоянно, но все же она имеет четко выраженный пик нагрузки в последний четверг месяца с 14-00 до 16-00, вызванный подготовкой отчетов. Другие транзакции вообще могут выполняться только в определенные моменты времени, например - по понедельникам с 9-00 до 10-00, что также является пиком нагрузки.
Когда выполнение потока транзакций требует частого доступа к определенным отношениям, очень большое значение приобретают выбранные для них схемы выполнения. Если выполнение этих транзакций не зависит друг от друга, риск возникновения проблем с производительностью уменьшается. Однако если схемы их выполнения конфликтуют, возможные проблемы могут быть частично устранены посредством тщательного изучения транзакций, что позволит найти способ их модификации с целью повышения их производительности. В нашем случае необходимо рассмотреть транзакции, проходящие через оператора и персонал. Результат анализа заносят в таблицу 3.3.
Таблица № 3.3. Результаты анализа.
| Тран закция | Актив-ность | День недели | Время суток | Частота вызовов в месяц |
| Т1. Список всех операторов | Пиковая | - | - | - |
| Средняя | Понедельник | 9-00 – 12-00 | ||
| От отношения | К отношению | Атрибуты | Тип доступа | Частота вызовов в месяц |
| - | Менеджер | Таб-ном | R(E) | |
| Менеджер | Оператор | Таб-ном-мен Таб-ном | R(E)* | 10 - 15 |
| Оператор | Персонал | Таб-ном * | R(E) R | |
| Тран закция | Актив-ность | День недели | Время суток | Частота вызовов в месяц |
| Т2. Перечень всех договоров конкретного менеджера за конкретный месяц. | Пиковая | Последний четверг месяца | 9-00 – 12-00 | |
| Средняя | - | - | - | |
| От отношения | К отношению | Атрибуты | Тип доступа | Частота вызовов в месяц |
| - | Персонал | Таб-ном | R(E) | |
| Персонал | Договор | Таб-ном * | R(E)* R | 800 - 1200 |
| Тран закция | Актив-ность | День недели | Время суток | Частота вызовов в месяц |
| Т3. Поиск информации об операторе по его ФИО | Пиковая | Последний четверг месяца | 15-00 - 16-00 | |
| Средняя | Понедельник-пятница | Случайным образом | ||
| От отношения | К отношению | Атрибуты | Тип доступа | Частота вызовов в месяц |
| - | Персонал | FIO * | R(E) R |
Заключение.
В заключении к курсовому проекту необходимо в краткой форме подвести выводы по проделанной работе, которые могут включать:
· Мнение студента о проделанной работе;
· Отношение к изученному материалу;
· Оценку средств и методов проектирования.
Приложение 1.