Практикум по курсу Москва 200 4 (стр. 4 из 4)

Третья теорема применима к отношениям, имеющим одноатрибутный ключ. Проверяем отношения КЛИЕНТ и ДОГОВОР.

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

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

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

1) Согласно ограничению 4 из списка ограничений (см. п.1.5) платеж банка одного типа выполняется только один раз:

ПЛАТЕЖИ БАНКА (Признак типа, N договора) ->

ЧМГ, N поручения, дата поручения, сумма

2) Согласно ограничению 3 из списка ограничений платеж клиента одного типа выполняется только один раз:

ПЛАТЕЖИ КЛИЕНТОВ (Признак типа, N договора) ->

ЧМГ, N поручения, дата поручения, сумма

3) В отличие от клиентов, номера платежных поручений которых на перечисление средств банку могут совпадать, номера платежных поручений самого банка уникальны. Это ограничение должно быть добавлено в список сформированных ограничений. Таким образом, номер платежного поручения банка определяет все остальные свойства платежа в отношении ПЛАТЕЖИ БАНКА:

ПЛАТЕЖИ БАНКА (N поручения) ->

Признак типа, N договора, ЧМГ, дата поручения, сумма

В результате исходная РМ преобразовывается в третью нормальную форму с учетом принятых в п.1.5 ограничений (рис. 4).

В случае изменения и уточнения ограничений реляционная модель в 3НФ может принять иной вид.

КЛИЕНТ (ИНН, Название, Адрес, Телефон, Расчетный счет, Банк, Город банка, Корсчет, БИК, ФИО рук, Должность руководителя)

ДОГОВОР (№ договора, Дата подписания, Сумма договора, Дата начала, Срок в днях, % годовых, ИНН)

ПЛАТЕЖИ КЛИЕНТОВ (№ договора, Признак типа, ЧМГ, № поручения, дата поручения, сумма)

ПЛАТЕЖИ БАНКА (№ поручения, № договора, ЧМГ, Признак типа, дата поручения, сумма)

Рис. 4. Реляционная модель в 3 нормальной форме

Для конкретных условий предметной области часто бывает целесообразным проведение денормализации – модификации реляционной модели, представленной в третьей нормальной форме. Например, в случаях изменения реквизитов клиентов от договора к договору или наличия незначительного числа клиентов, имеющих много договоров, возможно является целесообразным слияние таблиц КЛИЕНТ и ДОГОВОР в одну таблицу ДОГОВОР c ключом Номер Договора или объединения таблиц ПЛАТЕЖИ КЛИЕНТОВ и ПЛАТЕЖИ БАНКА в одну таблицу ПЛАТЕЖИ с использованием общего ключевого поля N договора+Признак типа.

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

Приводится один из вариантов датологической модели «Учет депозитных договоров в коммерческом банке» в среде выбранной СУБД, например, MS Access.

а) состав таблиц:

КЛИЕНТ,

ДОГОВОРА,

ПЛАТЕЖИ КЛИЕНТОВ,

ПЛАТЕЖИ БАНКА

б) структура таблиц

Приводятся описания полей всех таблиц, согласно требованиям конкретной СУБД, включая определение ключей и индексов.

в) схема данных

Приводится экранная форма схемы данных в МS Access.

5. Функциональная структура программной системы обработки данных

Структура программной системы обработки депозитных договоров согласно построенным моделям данных в среде MS Access представляет собой «кнопочную» форму (главное «меню») со следующей программной иерархией

Головная форма кнопочная
Формы ввода/просмотра/ редактирования	Запросы		Отчеты		Выход
Клиенты	Запрос 1		Ведомость № 1		Сервисные процедуры
Депозитные договора	Запрос 2
Платежи клиентов	Запрос 3
Платежи банка

Рис. 5. Функциональная структура главной управляющей формы

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

В отчете учащегося приводятся разработанные компоненты: формы, запросы, отчеты и, при необходимости, макросы. Компоненты отражаются в рабочем режиме и в режиме «конструктора». Созданные запросы приводятся также в виде SQL-предложений.

Интерфейсные возможности СУБД типа MS Access являются достаточно развитыми, поэтому разработка программ на языках типа Visual Basic for Application [5] является оправданной только тогда, когда другие встроенные в СУБД средства генерации не дают желаемого результата. Во многих случаях функции программ можно значительно быстрее реализовать имеющимися интерфейсными средствами СУБД.

6. Оценка вариантов ДЛМ

Для оценки своих проектных решений слушателем формируется вторая структура базы данных, отличная от выбранной, или от модели, соответствующей 3НФ.

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

Существуют два крайних варианта ДЛМ:

1) ДЛМ – соответствует реляционной модели в ЗНФ;

2) ДЛМ – представлена в виде одной единственной таблицы.

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

Сравнение вариантов ДЛМ проводится по ряду частных и интегрированных критериев [4]. C учетом нормированных весов, имеющих конкретное значение для условий каждой предметной области, можно сформировать нормированную интегральную оценку каждого варианта ДЛМ.

Критерии качества ДЛМ делятся на статические и динамические.

К числу основных статических критериев относятся:

- удовлетворение информационных потребностей;

- объемы требуемой для хранения данных дисковой памяти;

- время реакции системы на запросы;

- сложность реализации процедур работы с БД;

- вероятность выполнения запросов в фиксированный период времени;

- удобство пользователя при работе с БД.

Основные динамические критерии эффективности:

- затраты на адаптацию базы данных к изменению предметной области и информационных потребностей пользователей;

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

Для конкретных СОД состав критериев может видоизменяться.

Статические критерии эффективности оценивают качество проекта базы данных по отношению к текущим потребностям, динамические – оценивают проект базы данных на перспективу.

Слушателям предлагается оценить варианты ДЛМ по критерию «Объем, требуемый для хранения данных, дисковой памяти» количественно, по остальным – охарактеризовать качественно.

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

Литература

1. Диго С.М. Проектирование и использование баз данных. – М.: Финансы и статистика, 1995.

2. Джексон Г. Проектирование реляционных баз данных для использования в микроЭВМ. – М.: Мир, 1991.

3. Мишенин А.И. Теория экономических информационных систем. – М.: Финансы и статистика, 1999.

4. Назаров В.В. Прототипный подход проектирования баз данных в локальных сетях ПЭВМ. – М.: Вниипас,1990.

5. Харитонова И., Вольман Н. Программирование в Access 2002. – СПб.: Питер, 2002.

Приложение 1

Состав таблиц базы данных DEPOSIT

Приложение 2

Структура таблицы ДОГОВОР

Приложение 3

Структура таблицы КЛИЕНТ

Приложение 4

Структура таблицы ПЛАТЕЖИ КЛИЕНТОВ

Приложение 5

Структура таблицы ПЛАТЕЖИ БАНКА

Приложение 6

Схема данных

Приложение 7

Структура запроса

SELECT ДОГОВОР. N _ договора, ДОГОВОР. Дата _ начала,

[Дата _ начала] + [Срок _ в _ днях] AS Дата _ конца, КЛИЕНТ. Название, ДОГОВОР. Срок _ в _ днях

FROM КЛИЕНТ INNER JOIN ДОГОВОР ON КЛИЕНТ. ИНН = ДОГОВОР. ИНН

WHERE (((ДОГОВОР. Срок _ в _ днях)>366))

ORDER BY ДОГОВОР. Срок _ в _ днях;