Практикум по курсу Москва 200 4 (стр. 3 из 4)
Сумма договора*
Срок договора в днях*
Процент годовых*
НД, ИНН
НД
НД
Начислено
по договору
Сумма платежа* клиента
по договору
Сумма платежа банка
по договору*
НД, ЧМГ, ИНН
НД, ЧМГ, НП, ТП, ИНН
НД, ЧМГ, НПП, ТП, ИНН
Всего к перечислению
по договоруПеречислено в депозит
по договору
Перечислено банком
по договоруНД, ЧМГ, ИНН
НД, ЧМГ, ИНН
НД, ЧМГ, ИНН
Всего к перечислению
по клиентуПеречислено в депозит
по клиенту
Перечислено банком
по клиенту
ЧМГ, ИНН
ЧМГ, ИНН
ЧМГ, ИННВсего к перечислению
на датуПеречислено в депозит
на датуПеречислено банком
на дату
ЧМГ
ЧМГ
ЧМГ
Сумма договора
по клиенту
Сальдо расчетов
по договору
ЧМГ, ИНН
НД, ЧМГ, ИНН
Сальдо расчетов
по клиенту
ЧМГ, ИНН
Сальдо расчетов на дату
ЧМГ
 |
| ДОГОВОР | КЛИЕНТ | |||||
| № договора | ИНН | |||||
| Дата подписания | Название | |||||
| Сумма договора | Адрес | |||||
| Дата начала | Телефон | |||||
| Срок в днях | расч. счет | |||||
| % годовых | Банк | |||||
| ИНН клиента | город банка | |||||
| корсчет | ||||||
| БИК | ||||||
| ФИО руководителя | ||||||
| должность руководителя | ||||||
| Дата платежа | платежи клиентов | |||||
| ЧМГ | ||||||
| № поручения | ||||||
| дата поручения | ||||||
| сумма | ||||||
| Тип платежа | ||||||
| Признак типа | ||||||
| платежи банка | ||||||
| № поручения | ||||||
| дата поручения | ||||||
| сумма | ||||||
Рис. 2. ER-модель
4. Датологическая модель в среде выбранной СУБД
Датологическая модель в среде выбранной СУБД включает описание:
а) состава файлов/таблиц баз данных;
б) структуры и ключей файлов/таблиц баз данных;
в) схемы данных.
Часто, но не всегда, наиболее рациональным является создание ДЛМ по подобию реляционной модели в 3 нормальной форме. Такая структура таблиц / файлов базы данных является очень стабильной и, во многих случаях, минимальна по объему занимаемой памяти.
Нормализованная реляционная модель
Обычно исходная реляционная модель формируется из ER-модели путем преобразования полных объектов и процессов в самостоятельные отношения.
Каждому полному объекту ставится в соответствие реляционное отношение. Все свойства объекта образуют атрибуты отношения. Название отношения – название объекта, ключ отношения – ключ (идентификатор) объекта. Под полным объектом понимается объект, который, кроме ключевых свойств, имеет еще и неключевые свойства.
Каждому процессу ставится в соответствие реляционное отношение. В состав атрибутов отношения включают все зависимые свойства процесса и ключи всех связанных с данным процессом объектов. Название отношения – название процесса, ключ отношения – ключи всех связанных с данным процессом объектов.
Правило невключения в реляционную модель неполных объектов является не абсолютным. Часто наличие в модели неполных объектов означает недостаточное изучение их свойств, которые в случае более детального изучения предметной области могут представляться весьма существенными для контроля целостности базы данных или для целей дальнейшего развития системы. Например, объект ТИПЫ ПЛАТЕЖА может иметь свойства, которые интегрируют разрабатываемую систему в общую систему учета и управления банком через дебетуемые и кредитуемые счета (дополнительные свойства) и т.п. Кроме того, при ведении отдельного отношения ТИПЫ ПЛАТЕЖА можно обеспечить логический (на уровне данных, а не программ) контроль правильности значений платежей по данному свойству. Ясно, что дополнительные отношения всегда усложняют систему, и следует избегать дополнительных отношений, если только на это нет веских оснований.
Исходная реляционная модель, сформированная из ER-модели, приведена на рис.3. Ключи отношений подчеркнуты.
| КЛИЕНТ (ИНН, Название, Адрес, Телефон, Расчетный счет, Банк, Город банка, Корсчет, БИК, ФИО рук, Должность руководителя) |
| ДОГОВОР (№ договора, Дата подписания, Сумма договора, Дата начала, Срок в днях, % годовых, ИНН) |
| ПЛАТЕЖИ КЛИЕНТОВ (№ договора, ЧМГ, Признак типа, № поручения, дата поручения, сумма) |
| ПЛАТЕЖИ БАНКА (№ договора, ЧМГ, Признак типа, № поручения, дата поручения, сумма) |
Рис. 3. Исходная реляционная модель
В дальнейшем модель нормализуется. При этом анализируются и уточняются функциональные связи между реквизитами отношений, состав ключей, которые существенным образом зависят от специфики предметной области. Эта специфика последовательно отражается студентом в разделе «Ограничения». Детально алгоритм нормализации реляционной модели описан в [3].
Для нормализации обычно достаточно бывает применить к исходной реляционной модели несколько теорем, в результате которых отношения разделяются и сливаются:
1. Все неключевые реквизиты должны полностью зависеть от всего ключа отношения.
2. Не должно быть функциональных зависимостей внутри ключа отношения.
3. В отношении не должно быть транзитивных зависимостей.
4. Отношения с одинаковыми ключами объединяются.
| № п/п | Имеются отношения | В отношении имеются функциональные зависимости | Новые отношения |
| 1. | R(A, B, C, D) | A, B -> C B -> D | R1(A, B, C) R2(B, D) |
| 2. | R(A, B, C, D) | A,B,C -> D B -> C | R1(A, B, C,D) R2(B, C) |
| 3. | R(A, B, C) | A -> B B -> C | R1(A, B) R2(B, C) |
| 4. | R1(A, B) R2(A, C) | R(A, B, C) |
Проверим исходные реляционные отношения (рис. 3) на наличие функциональных зависимостей согласно приведенным теоремам.
Первая и вторая теоремы применимы к отношениям, имеющим многоатрибутный ключ. Проверяем отношения ПЛАТЕЖИ КЛИЕНТОВ и ПЛАТЕЖИ БАНКА.