Рефераты | Рефераты по информатике, программированию | MIDAS. Практическое применение |
Кому |
||
|
Получатель1(имя) |
Получатель2(имя) |
... |
|
|
Поставщик1(имя) |
Сумма |
Сумма |
|
|
Поставщик2(имя) |
Сумма |
Сумма |
|
|
... |
В отчет будут входить суммы из документов, даты которых попадают в заданный период.
Отчет, разумеется, получается также достаточно оторванным от жизни, мне просто хотелось показать с его помощью дополнительные возможности MIDAS.
Блокировки
Поскольку работать с БД будут сразу несколько пользователей, важно заблокировать документ на время редактирования документа пользователем. “Почетная обязанность” синхронизации работы пользователей возлагается в данном случае на сервер приложений. В принципе, все это можно реализовать и средствами SQL сервера, но, во-первых, для сервера Interbase блокировки записей довольно неестественны, во-вторых, как будет видно ниже, сервер приложений позволяет легко блокировать сразу весь документ как единый объект.
Структура БД
Требования к приложению описаны, и теперь можно приступить к следующему этапу – созданию БД. Нам нужны три таблицы (магическое число три выбрано исключительно для простоты): для документа, содержимого документа и справочника клиентов. Документ содержит две ссылки на справочник клиентов – “Поставщик” и "Получатель", а содержимое документа имеет ссылку на документ. На рисунке 1 представлена ER-диаграмма этой БД.
Рисунок 1. ER-модель БД.
В данной базе целостность данных обеспечивается по следующим правилам:
При упоминании в каком-либо документе поставщика или получателя удаление этой строки из справочника клиентов не допускается.
При удалении документа удаляются и все связанные с ним строки из таблицы "Содержимое документа".
Вставка в таблицу "Содержимое документа" допускается только при условии, что поле ID ссылается на существующий документ.
Как видно, в таблице "Заголовок документа" есть поле "Сумма". Это поле должно содержать полную сумму документа (сумму полей "Сумма" содержимого документа). При изменении содержимого документа приходится пересчитывать значение этого поля. Наличие такого поля, является нарушением принципов нормализации. Эту сумму всегда можно посчитать в SQL-запросе при выводе данных пользователю. Но при выдаче списка документов расчет суммы каждого из них увеличивает нагрузку на сервер БД. Отслеживать актуальность этого поля можно на триггерах СУБД, но раз уж мы создаем сервер приложений, почему бы не возложить на него эту задачу? К тому же, это обеспечивает некоторую независимость от особенностей функционирования сервера БД, что может оказаться полезным, например, при переходе на другой сервер.
Ниже приведен скрипт, создающий подопытную БД:
