Главная Учебники - Разные Лекции (разные) - часть 13
|
Министерство образования Российской Федерации
Международный образовательный консорциум
«Открытое образование»
Московский государственный университет экономики,
статистики и информатики
АНО «Евразийский открытый институт»
В.В. Назаров Проектирование и реализация
Москва 200
4
УДК ББК Назаров В.В.
Базы данных. Проектирование и реализация:
Практикум по курсу / Московский государственный университет экономики, статистики и информатики – М., 2004. – 21 c. Рекомендовано Учебно-методическим объединением по образованию в области прикладной информатики (по областям) в экономике в качестве практикума для студентов высших учебных заведений, обучающихся по специальности 351400 «Прикладная информатика в экономике (по областям)» и другим междисциплинарным специальностям. Практикум предназначен для студентов очной и заочной форм обучения для выполнения контрольных работ и курсовых проектов по курсу «Базы данных». Ó Назаров В. В., 2004. Содержание
Введение 158
Темы курсовых и контрольных работ 158
Типовое содержание курсового проекта 159
Типовое содержание контрольной работы 160
Пример проектирования базы данных «Учет депозитных договоров Введение 161 Литература 171
Приложение 172
Введение
В качестве предметной области для проектирования и реализации базы данных выбирается законченная задача или комплекс задач, выполняемых конкретным экономическим подразделением предприятия или организации. В процессе выполнения курсового проекта студент комплексно применяет полученные в процессе изучения дисциплины теоретические и практические навыки: анализ и описание предметной области, построение инфологической, реляционной моделей, обоснование и выбор СУБД, реализация даталогической модели, оценка полученных структур баз данных, разработка и генерация форм, запросов, макросов и отчетов. При решении контрольной работы студентом выполняются основные этапы проектирования и реализации баз данных на фрагменте экономической предметной области. Темы курсовых и контрольных работ
1. Проектирование базы данных Учета расчетов с поставщиками и подрядчиками. 2. Проектирование базы данных Учета основных средств. 3. Проектирование базы данных Учета движения материалов на предприятии. 4. Проектирование базы данных Учета движения материалов на складе. 5. Проектирование базы данных Учета заработной платы. 6. Проектирование базы данных Учета расчетов по единому социальному налогу. 7. Проектирование базы данных Учета нематериальных активов. 8. Проектирование базы данных Учета реализации. 9. Проектирование базы данных Расчетов по подоходному налогу. 10. Проектирование базы данных Учета расчетов с бюджетом. 11. Проектирование базы данных Учета кассовых операций. 12. Проектирование базы данных Учета банковских операций. 13. Проектирование базы данных Учета валютных операций. 14. Проектирование базы данных Учета затрат на производство и калькулирование себестоимости продукции. 15. Проектирование базы данных Сводного синтетического учета. 16. Проектирование базы данных Планирования и анализа деятельности предприятия. 17. Проектирование базы данных Бронирования номеров и учета клиентов гостиницы. 18. Проектирование базы данных Учета расчетов с клиентами гостиницы. 19. Проектирование базы данных Планирования деятельности персонала гостиницы. 20. Проектирование базы данных Учета расчетов с контрагентами в туристическом агентстве. 21. Проектирование базы данных Планирования, составления и калькулирования туристических маршрутов. 22. Проектирование базы данных Учета в библиотеке. 23. Проектирование базы данных Учета на торговом предприятии. 24. Проектирование базы данных Анализа биржевых операций. 25. Проектирование базы данных Учета расчетов с клиентами в банке. 26. Проектирование базы данных Учета и отчетности отдела валютных операции коммерческого банка. 27. Проектирование базы данных Планирования и учета в кредитном отделе банка. 28. Проектирование базы данных Учета и анализа деятельности коммерческой службы знакомств. 29. Проектирование базы данных Риэлторского агентства по жилым помещениям. 30. Проектирование базы данных Риэлторского агентства по нежилым помещениям. 31. Проектирование базы данных Налогового учета на предприятии. 32. Проектирование базы данных Книги покупок и Книги продаж и расчетов с бюджетом по НДС. 33. Исследовательские темы по вопросу проектирования баз данных и эксплуатации различных СУБД в разных программно-аппаратных средах. Студентом может быть выбрана тема курсового проекта и самостоятельно, исходя из следующих требований к предметной области: 1. Экономическое содержание предметной области. 2. Наличие не менее 3-х входных документов. 3. Наличие не менее 3-х выходных документов (отчетов). 4. Наличие не менее 10-ти запросов к предметной области (всех типов, реализуемых средствами генерации СУБД). Типовое содержание курсового проекта
Введение 1. Описание предметной области. 1.1. Общее описание предметной области. 1.2. Описание входных документов и сообщений. 1.3. Описание выходных документов и сообщений. 1.4. Описание запросов к базе данных. 1.5. Список ограничений. 2. Выбор и описание используемой СУБД. 3. Инфологическая модель (ИЛМ). 3.1. Граф алгоритмической взаимосвязи показателей. 3.2. ER-модель. 4. Датологическая модель. 4.1. Нормализованная реляционная модель. 4.2. Варианты ДЛМ в среде выбранной СУБД. а) состав файлов / таблиц баз данных; б) структура и ключи файлов / таблиц баз данных; в) схема данных. 5. Функциональная структура программной системы обработки данных. 6. Оценка вариантов ДЛМ в среде выбранной СУБД. 7. Заключение. 8. Список литературы. Приложения. 1. Листинги структуры базы данных выбранного варианта ДЛМ. 2. Схема данных. 3. Листинги реализованных форм / отчетов / запросов / программ / макросов. а) конструкторские структуры; б) результаты выполнения. Типовое содержание контрольной работы
1. Описание предметной области. 1.1. Общее описание предметной области. 1.2. Описание входных документов и сообщений. 1.3. Описание выходных документов и сообщений. 1.4. Описание запросов к базе данных. 1.5. Список ограничений. 2. Инфологическая модель (ИЛМ). 2.1. Граф алгоритмической взаимосвязи показателей. 2.2. ER-модель. 2.3. Нормализованная реляционная модель. 3. Датологическая модель в среде выбранной СУБД. 3.1. Нормализованная реляционная модель. 3.2. Структура базы данных. а) состав файлов / таблиц баз данных; б) структура и ключи файлов / таблиц баз данных; в) схема данных. 4. Схема функциональной структуры программной системы обработки данных. 5. Список литературы. Приложения. 1. Листинги структуры файлов / таблиц базы данных. 2. Листинги компонент реализованных форм / отчетов / запросов / меню. Требования к контрольной работе: 1. Экономическое содержание предметной области. 2. Наличие не менее 1-го входного документа. 3. Наличие не менее 1-го выходного документа (отчета). 4. Наличие не менее 3-х запросов к предметной области. Пример проектирования базы данных
«Учет депозитных договоров в коммерческом банке»
Введение
Определяется цель работы, описываются применяемые технические и общесистемные программные средства. Раскрывается назначение разрабатываемой системы, ее место в общей системе управления, определяются пользователи системы. 1. Описание предметной области
Общее описание предметной области
Необходимо разработать базу данных для системы учета депозитных договоров и платежей по депозитным договорам в соответствующем отделе коммерческого банка (КБ). Депозитный отдел заключает с юридическими лицами – как клиентами банка, так и сторонними организациями – депозитные договора. В них банк обязуется принять от клиента на определенный срок в календарных днях определенную сумму в рублях, а после окончания срока договора возвратить данную сумму с начисленными процентами, размер которых определяется в договоре. Денежные суммы по договору перечисляются безналичным путем платежными поручениями. Описание входных документов и сообщений
Входными документами являются: 1. Депозитные договора: - номер договора; - дата подписания договора; - сумма договора в рублях*; - дата начала договора; - срок договора в днях*; - начисляемый процент годовых*; - реквизиты клиента: название организации, адрес, идентификационный номер налогоплательщика (ИНН), номер расчетного счета, название банка, город банка, номер корреспондентского счета, БИК банка, телефон; - реквизиты банка: название банка, адрес, идентификационный номер налогоплательщика (ИНН), номер расчетного счета по депозитному обслуживанию, номер корреспондентского счета, БИК банка, телефон. 2. Платежные поручения клиентов банка на покрытие депозита: Реквизиты документа: - номер платежного поручении; - дата платежного поручения; - реквизиты плательщика: идентификационный номер налогоплательщика (ИНН), название организации, номер расчетного счета, название банка, город банка, номер корреспондентского счета, БИК банка; - реквизиты получателя: идентификационный номер налогоплательщика (ИНН), название организации, номер расчетного счета, название банка, город банка, номер корреспондентского счета, БИК банка; - назначение платежа: номер депозитного договора, дата договора; - сумма в рублях*. 3. Платежные поручения банка на возврат депозита и перечисление начисленных процентов по депозиту. Реквизиты документа: - номер платежного поручения; - дата платежного поручения; - реквизиты плательщика: идентификационный номер налогоплательщика (ИНН), название организации, номер расчетного счета, название банка, город банка, номер корреспондентского счета, БИК банка; - реквизиты получателя: идентификационный номер налогоплательщика (ИНН), название организации, номер расчетного счета, название банка, город банка, номер корреспондентского счета, БИК банка; - назначение платежа: номер депозитного договора, дата договора, тип платежа – возврат депозита / перечисление процентов; - сумма в рублях*.; 4. Выписка банка по выделенному депозитному счету: Используемые реквизиты: - дата выписки; - номер платежного поручения; - признак поступления / расходования средств; - ИНН плательщика; - номер договора; - тип платежа: внесение депозита, возврат депозита, перечисление процентов; - сумма в рублях*. Приводятся формы данных документов с образцами заполнения. Если форма документа студенту неизвестна, то она разрабатывается им оригинально. Описание выходных документов и сообщений
Выходным документом является «Ведомость начисления процентов по завершенным договорам и сальдо расчетов с клиентами по состоянию на ____ число ______месяца 20__года». Образцы заполнения документов приводятся. Описание запросов к базе данных
1. Выдать список всех депозитных договоров со сроком действия больше 1 года № договора Дата начала договора Дата конца договора Название организации Количество дней договора* >366, сортировка Пример выходного документа
Ведомость начисления процентов по завершенным договорам и сальдо расчетов с клиентами по состоянию на 23 число 12 месяца 2002 года Название клиента ИНН № договора Дата договора Сумма договора* Перечислено в депозит, руб * Начислено %* Всего к перечислению* Перечислено руб* Дата перечисления Сальдо расчетов, руб Артос 7700000001 12 23.04.02 50000 50000 12000 62000 50000 26.08.02 12000 45 12.06.02 40000 40000 9000 49000 0 49000 Итого 90000* 90000* 21000* 111000* 50000* 61000* Ариан 7700000003 Всего 1000000* 300000* 1300000* 900000* 400000* 2. Выдать действующие депозитные договора объемом более 100 000 рублей с фамилиями и должностями клиентов. № договора ФИО руководителя Должность руководителя Дата конца договора Название организации Объем договора, рублей * <= текущей дате >100000, сортировка 3. Выдать названия клиентов, номера и суммы договоров текущего года, отсортированных по убыванию процентных ставок. № договора Дата договора Процентная ставка Название организации Объем договора, рублей * = текущий год сортировка по убыванию Список ограничений
1. Один клиент может заключить с банком несколько депозитных договоров. 2. Номера договоров уникальны. 3. Клиент покрывает депозит по одному договору одним платежным поручением. 4. Банк возвращает клиенту основную сумму и проценты двумя разными платежными поручениями. 5. Реквизиты клиентов банка постоянны для разных договоров. 2. Выбор и описание используемой СУБД
В качестве СУБД можно выбрать MS Access, FoxPro, Oracle, Informix, Paradox или другую доступную вам систему. Описывается выбранная СУБД, показываются ее преимущества и, по возможности, недостатки. 3. Инфологическая модель (ИЛМ)
Граф алгоритмической взаимосвязи показателей
Первоначально определяются экономические показатели[2]. Обычно показатели включают один реквизит-основание и несколько характеризующих его реквизитов признаков. В описании документов и запросов реквизиты-основания нами обозначены значками (*). При определении показателей важно проанализировать их экономический смысл, при этом устранить дублируемость, синонимию, омонимию и возможную противоречивость. Далее при определении алгоритмических зависимостей будут использоваться условные обозначения, приведенные в таблице. Условные обозначения
Условное обозначение Значение НД Номер договора ДД Дата договора ЧМГ Число Месяц Год НПП Номер платежного поручения ДПП Дата платежного поручения ТП Тип платежа ИНН Идентификационный номер налогоплательщика Граф алгоритмической взаимосвязи показателей строится один на всю предметную область вне зависимости от количества входных и выходных документов и запросов. Его цель – определить реквизитный состав показателей, алгоритмические зависимости показателей. В результате определяется состав исходных показателей, которые потом участвуют в построении дальнейших моделей: ER-модели, реляционной и даталогической моделей. Промежуточные и результатные показатели в моделях не показываются и в базе данных не хранятся с целью минимизации базы данных, повышения ее устойчивости и гарантии непротиворечивости показателей. Они рассчитываются при формировании соответствующих запросов и отчетов на базе исходных показателей. Исходя из вышеприведенного, можно построить граф алгоритмической взаимосвязи показателей (рис. 1). Исходные показатели отмечены на рисунке звездочкой – их всего 5. Только эти показатели будем в дальнейшем рассматривать в моделях и хранить в БД. Все остальные показатели можно рассчитать на их основе. В базе данных будем хранить реквизиты-признаки, которые: - входят в состав хранимых показателей; - входят в состав выходных документов и запросов; - будут использованы при ближайшем развитии системы. ER-модель
Правила построения ЕR-модели приведены в [1]. ER-модель для учета депозитных договоров приведена на рис. 2. Овал характеризует объект. Вверху – название объекта, под чертой – ключ объекта, ниже – зависимые свойства. Ромб характеризует процесс – отношения объектов. В ромбе – название процесса, под ним – зависимые от всех связанных с данным процессов объектов свойства. Линиями на схеме обозначены связи. В данном случае все связи имеют тип 1:М. На стороне стрелки находится отношение М. Например, каждому экземпляру объекта КЛИЕНТ соответствует М экземпляров объекта ДОГОВОР, а любому экземпляру объекта ДОГОВОР соответствует только единственный экземпляр объекта КЛИЕНТ. Модель включает: два полных объекта ДОГОВОРа и КЛИЕНТы, два неполных объекта (нет неключевых свойств) ДАТА ПЛАТЕЖА и ТИП ПЛАТЕЖА; два процесса ПЛАТЕЖИ КЛИЕНТОВ и ПЛАТЕЖИ БАНКА. Возможные неточности ЕR-модели устраняются ее преобразованием в реляционную модель с дальнейшей нормализацией.
Срок договора в днях* Процент годовых* НД, ИНН НД НД
Начислено по договору Сумма платежа* клиента по договору Сумма платежа банка по договору* НД, ЧМГ, ИНН НД, ЧМГ, НП, ТП, ИНН НД, ЧМГ, НПП, ТП, ИНН
Всего к перечислению
Перечислено в депозит по договору Перечислено банком
НД, ЧМГ, ИНН НД, ЧМГ, ИНН НД, ЧМГ, ИНН
Всего к перечислению
Перечислено в депозит по клиенту Перечислено банком
Всего к перечислению
Перечислено в депозит
Перечислено банком на дату ЧМГ ЧМГ ЧМГ Сумма договора по клиенту Сальдо расчетов по договору ЧМГ, ИНН НД, ЧМГ, ИНН Сальдо расчетов по клиенту ЧМГ, ИНН Сальдо расчетов на дату ЧМГ Рис.1. Граф алгоритмической взаимосвязи показателей
ДОГОВОР КЛИЕНТ № договора ИНН Дата подписания Название Сумма договора Адрес Дата начала Телефон Срок в днях расч. счет % годовых Банк ИНН клиента город банка корсчет БИК ФИО руководителя должность руководителя Дата платежа платежи клиентов ЧМГ № поручения дата поручения сумма Тип платежа Признак типа платежи банка № поручения дата поручения сумма Рис. 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) на наличие функциональных зависимостей согласно приведенным теоремам. Первая и вторая теоремы применимы к отношениям, имеющим многоатрибутный ключ. Проверяем отношения ПЛАТЕЖИ КЛИЕНТОВ и ПЛАТЕЖИ БАНКА. Третья теорема применима к отношениям, имеющим одноатрибутный ключ. Проверяем отношения КЛИЕНТ и ДОГОВОР. Четвертая теорема наиболее проста в применении и состоит в нахождении и объединении отношений с одинаковыми ключами. Имеется, однако, ряд концептуально-технологических факторов, ограничивающих прямое применение правил этой теоремы, такие, например, как неоднородность происхождения и целевого назначения данных, принципиальные различия цикла жизни и технологии обработки информации, представленных в отношениях с одинаковыми ключами. В приведенном примере отношения с одноатрибутными ключами корректны по функциональным зависимостям. В отношениях с многоатрибутными ключами находим следующие ранее не установленные функциональные зависимости. 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
Состав таблиц базы данных D
EPOSIT
Приложение 2
Структура таблицы ДОГОВОР
Приложение 3
Структура таблицы КЛИЕНТ
Приложение 4
Структура таблицы ПЛАТЕЖИ КЛИЕНТОВ
Приложение 5
Структура таблицы ПЛАТЕЖИ БАНКА
Приложение 6
Схема данных
Приложение 7
Структура запроса
SELECT ДОГОВОР. N _ договора, ДОГОВОР. Дата _ начала, [Дата _ начала] + [Срок _ в _ днях] AS Дата _ конца, КЛИЕНТ. Название, ДОГОВОР. Срок _ в _ днях FROM КЛИЕНТ INNER JOIN ДОГОВОР ON КЛИЕНТ. ИНН = ДОГОВОР. ИНН WHERE (((ДОГОВОР. Срок _ в _ днях)>366)) ORDER BY ДОГОВОР. Срок _ в _ днях;
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||