КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ МОДЕЛИ ДАННЫХ

Стр 1 из 10Следующая ⇒

КУРСОВАЯ работа

по дисциплине «Системы баз данных»

на тему «Проектирование базы данных учета материальных ценностей»

Студента

факультета «Экономики и управления»

специальности «Управление

информационными ресурсами»

3-го курса, группы С-31 _______________ _______ Абашев Ф.А.

(дата сдачи на рецензию) (подпись) (И.О.Фамилия)

Научный руководитель доцент Грибовская М.А.

(должность, научная степень) (И.О.Фамилия)

Отметка о допуске к защите _________ ______ _______ ________

(отметка) (дата) (подпись) (И.О.Фамилия)

Защита работы: ______________ _______ _________ ________

(оценка) (дата) (подпись) (И.О.Фамилия)

_________ _________

(подпись) (И.О.Фамилия)

Гомель 2016

СОДЕРЖАНИЕ

Введение. 3

1 Концептуальное проектирование модели данных. 5

1.1 Теоретические основы концептуального моделирования. 5

1.2. Анализ предметной области. 7

1.3 Выделение объектов модели данных и их характеристик. 10

1.4 Выявление связей между объектами, условий, налагаемых на объекты и связи. 11

2 Логическое проектирование модели данных. 15

2.1 Теоретические основы логического моделирования. 15

2.2 Определение отношений, атрибутов и их доменов, обеспечение целостности. 17

2.3 Нормализация отношений модели данных. 22

2.4 Создание логической модели данных и физической модели базы данных с помощью ERWin. 29

3 Физическое проектирование базы данных в. 33

3.1 Теоретические основы физического моделирования. 33

3.2 Генерация базы данных в СУБД Access с помощью физической модели данных. 38

3.3 Организация ввода и корректировки данных. 40

3.4 Описание информационных потребностей пользователей и выбор способов их реализации. 42

3.5 Разработка интерфейса – главной кнопочной формы.. 47

3.6 Разработка руководства пользователю базой данных. 50

3.7 Тестирование базы данных. 52

3.8 Оценка эффективности работы с данными. 53

Заключение. 55

Список использованных источников. 56

Приложение А. Код генерации базы данных Access. 57

Приложение Б. Формы.. 63

Приложение В. Запросы.. 66

Приложение Г. Отчёты.. 70

ВВЕДЕНИЕ

На сегодняшний день использование баз данных (БД) и информационных систем становится неотъемлемой частью функционирования любых организаций и предприятий. В связи с этим большую актуальность приобретает освоение принципов построения и эффективного применения соответствующих технологий и программных продуктов: систем управления базами данных (СУБД), CASE-систем автоматизации проектирования, средств администрирования и защиты баз данных и других.

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

Целью данной работы является информационная поддержка деятельности по распределению материальных ценностей между материально ответственными лицами.

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

В рамках данной работы были поставлены следующие задачи:

· рассмотреть теоретическую основу разработки БД;

· разработать ER-модель;

· построить реляционную модель данных;

· создать модель данных с помощью CASE-метода и сгенерировать ее в базу данных СУБД Access;

· физическое проектирование базы данных в среде СУБДAccess;

· создать БД с контролем целостности данных.

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

Структура курсовой работы: введение, три главы, заключение, список литературы и приложения.

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

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

КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ МОДЕЛИ ДАННЫХ

Теоретические основы концептуального моделирования

Цель этапа концептуального проектирования – создание концептуальной модели данных исходя из представлений пользователей о предметной области. Для ее достижения выполняется ряд последовательных процедур.

1. Определение сущностей и их документирование. Для идентификации сущностей определяются объекты, которые существуют независимо от других. Такие объекты являются сущностями. Каждой сущности присваивается осмысленное имя, понятное пользователям. Имена и описания сущностей заносятся в словарь данных. Если возможно, то устанавливается ожидаемое количество экземпляров каждой сущности.

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

3. Создание ER-модели предметной области. Для представления сущностей и связей между ними используются ER-диаграммы. На их основе создается единый наглядный образ моделируемой предметной области – ER-модель предметной области.

4. Определение атрибутов и их документирование. Выявляются все атрибуты, описывающие сущности созданной ER-модели. Каждому атрибуту присваивается осмысленное имя, понятное пользователям. О каждом атрибуте в словарь данных помещаются следующие сведения:

· имя атрибута и его описание;

· тип и размерность значений;

· значение, принимаемое для атрибута по умолчанию (если такое имеется);

· может ли атрибут иметь Null-значения;

· является ли атрибут составным, и если это так, то из каких простых атрибутов он состоит. Например, атрибут «Ф.И.О. клиента» может состоять из простых атрибутов «Фамилия», «Имя», «Отчество», а может быть простым, содержащим единые значения, как «Иванов Иван Иванович». Если пользователь не нуждается в доступе к отдельным элементам «Ф.И.О.», то атрибут представляется как простой;

· является ли атрибут расчетным, и если это так, то как вычисляются его значения.

5. Определение значений атрибутов и их документирование. Для каждого атрибута сущности, участвующей в ER-модели, определяется набор допустимых значений и ему присваивается имя. Например, атрибут «Тип счета» может иметь только значения «депозитный», «текущий», «до востребования», «карт-счет». Обновляются записи словаря данных, относящиеся к атрибутам, – в них заносятся имена наборов значений атрибутов.

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

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

Анализ предметной области

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

Для каждой книги фиксируется её название, авторы, издательство, год издания, количество страниц, стоимость приобретения, краткое содержание книги, наличие компакт-диска. Менеджер учитывает данные о поставщиках: их название, ИНН, юридический адрес, банк, номер счёта в банке. Покупателям в мелкооптовом магазине может быть любой человек или организация при условии, что количество приобретаемых экземпляров каждой книги не менее 3. При работе с покупателем-организацией необходимо знать её название, юридический адрес, ИНН, ответственное за покупки лицо или директора, телефон, банк, номер счёта в банке. Если покупатель – физическое лицо, то достаточно знать его фамилию, имя, отчество, адрес, телефон. Расчёт с организациями производится через банк, расчёт с физическими лицами – наличными. Покупателю выписывается счёт-фактура, которая имеет уникальный номер, дату и содержит список книг с указанием их стоимости, а также суммы к оплате. После оплаты указанной суммы покупатель получает товар на складе.

Необходимо учесть следующие обстоятельства (условия применения):

· номера счёт-фактур и накладных не повторяются на протяжении всего периода учета;

· каждая книга идентифицируется уникальным инвентарным номером;

· одна и та же книга может упоминаться в разных счёт-фактурах;

· все объекты одной счёт-фактуры принимаются одним покупателем;

· в один день могут быть оформлены несколько счёт-фактур.

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

Рисунок 1 - Функциональная модель предметной области: диаграмма A0

Выполним декомпозицию модели 0-го уровня на шесть работ, которые позволяют достичь цели – закупить и выгодно продать книги. Декомпозиция показана на рисунке 2.

Рисунок 2 - Функциональная модель предметной области: декомпозиция

Рисунок 3 – Функциональная модель предметной области: диаграмма потоков данных DFD(для определения сущности заключения договора)

Из функциональной модели, показанной на рисунке 2, получим модель потоков данных DFD (рисунки 3-5) – это набор данных, необходимых для обеспечения функции.

Рисунок 4 – Функциональная модель предметной области: диаграмма потоков данных DFD(для выписки счёт-фактуры)

Рисунок 5 – Функциональная модель предметной области: диаграмма потоков данных DFD (для определения сущности отгрузки книг)

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

Рисунок 6- Диаграмма ER-экземпляров для связи Имеют

Связь между сущностями Счёт-фаткуры и Книги определяется глаголом Содержат, мощностям этой связи – «многие ко многим» («n: m»), т.к. одна счёт-фактура может содержать несколько наименований книг, и одна книга может быть указана в нескольких счёт-фактурах. Так как книга может не числиться в определённой счёт-фактуре, то степень принадлежности сущности Книги в связи «содержат» является необязательной. Так как в каждой счёт-фактуре указываются книги, то степень принадлежности сущности счёт-фактуры в связи «оформлен» является обязательной. Таким образом, получаем диаграмму ER-экземпляров, приведенную на рисунке 7.

Рисунок 7- Диаграмма ER-экземпляров для связи Содержат

Связь между сущностями Поставщики и Накладные определяется глаголом Выдаётся, мощностям этой связи – «один ко многим» («1: n»), т.к. накладная выписывается только на одного поставщика. В результате получаем диаграмму ER-экземпляров, приведенную на рисунке 8.

Рисунок 8 - Диаграмма ER-экземпляров для связи Выписывается

Связь между сущностями Покупатели и Счёт-фактура определяется глаголом Выписывается, мощностям этой связи – «один ко многим» («1: n»), т.к. счёт-фактура выписывается только на одного покупателя. В результате получаем диаграмму ER-экземпляров, приведенную на рисунке 9.

Рисунок 8 - Диаграмма ER-экземпляров для связи Выписывается

Сущности Покупатели и Поставщики книг не связаны между собой, т.к. поставщик не может являться одновременно и покупателем.

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

Концептуальная модель данных в виде диаграммы Чена представлена на рисунке 9.

Рисунок 9 – Уточнённая концептуальная модель данных

Правило 1

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

Правило 2

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

Правило 3

Если связь типа 1: 1 и класс принадлежности обеих сущностей является необязательным, то необходимо построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

Правило 4

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

Правило 5

Если связь типа 1: М и класс принадлежности сущности на стороне М является необязательным, то необходимо построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

Правило 6

Если связь типа М: N, то необходимо построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

Сущности Поставщики книг, Книги, Покупатели концептуальной модели переходят в соответствующие отношения Поставщики книг, Книги, Получатели реляционной модели.

Характеристики каждой сущности переходят в соответствующие атрибуты. Уникальный идентификатор каждой сущности переходит в первичный ключ отношения.

В концептуальной модели между сущностями Покупатели и Счёт-фактура установлена связь «выписывается» мощности «один ко многим» и имеется обязательная степень принадлежности со стороны «многие» (условие правила 4), поэтому при переходе к реляционной модели:

· получаем два отношения Покупатели и Счёт-фактура;

· уникальный идентификатор каждой сущности переходит в первичный ключ соответствующего отношения;

· первичный ключ Код покупателя отношения Покупатели на стороне связи «один» включается как атрибут в отношение Счёт-фактуры со стороны связи «многие».

Так как для идентификации одной Счёт-фактуры достаточно её уникального номера, то первичный ключ сущности Покупатели не включается в состав первичного ключа сущности Счёт-фактуры. Поэтому связь является не идентифицирующей.

В концептуальной модели между сущностями Поставщики и Накладные установлена связь «выдаётся» мощности «один ко многим» и имеется обязательная степень принадлежности со стороны «многие» (условие правила 4), поэтому при переходе к реляционной модели:

· получаем два отношения Поставщики и Накладные;

· уникальный идентификатор каждой сущности переходит в первичный ключ соответствующего отношения;

· первичный ключ Код поставщика отношения Поставщики на стороне связи «один» включается как атрибут в отношение Накладные со стороны связи «многие».

Так как для идентификации одной Накладной достаточно её уникального кода, то первичный ключ сущности Поставщики не включается в состав первичного ключа сущности Накладные. Поэтому связь является не идентифицирующей.

В концептуальной модели между сущностями Счёт-фактуры и Книги установлена связь «содержат» мощности «многие ко многим» (условие правила 6), поэтому при переходе к реляционной модели:

· получаем три отношения Книги, Строки счёт-фактур и счёт-фактуры;

· уникальный идентификатор каждой сущности переходит в первичный ключ соответствующего отношения;

· первичный ключ Кодкниги отношения Книги на стороне связи «один» включается как атрибут в отношение Строки счёт-фактур со стороны связи «многие».

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

В концептуальной модели между сущностями Накладные и Книги установлена связь «имеют» мощности «многие ко многим» (условие правила 6), поэтому при переходе к реляционной модели:

· получаем три отношения Книги, Строки накладных и накладные;

· уникальный идентификатор каждой сущности переходит в первичный ключ соответствующего отношения;

· первичный ключ Кодкниги отношения Книги на стороне связи «один» включается как атрибут в отношение Строки накладных со стороны связи «многие».

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

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

Запишем для предметной области «Мелкооптовый книжный магазин» реляционную модель, в которой определены структуры (реляционные схемы) отношений, учтены условия целостности отношений с помощью первичных ключей и условия целостности связей с помощью внешних ключей:

· Поставщики книг (КодПоставщика, НаимПоставщика, ИННпост, ЮрАдресПост, БанкПост, НомСчётаПост);

· Книги (КодКниги, Название, Автор, Издательство, ГодИзд, КолСтр, СтоимПриобр, КрСодерж, КомпактД);

· Накладные (КодНакл, КодПоставщика, ДатаНакл);

· Строки накладных (КодКниги, КодНакл, КоличествоКниг);

· Покупатели (КодПокупателя, НазвОрг, ЮрАдресПокуп, ИННпокуп, ФИО, БанкПокуп, НомСчётаПокуп, Телефон);

· Счёт-фактуры (УникНомер, КодПокупателя, Дата);

· Строки счёт-фактуры (КодКниги, УникНомер, Количество);

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

Поскольку не должны выполняться математические операции со значениями атрибутов КодПоставщика, НаимПоставщика, ЮрАдресПост, БанкПост, КодКниги, Название, Автор, Издательство, КрСодерж, КодПокупателя, НазвОрг, ИННпокуп, НомСчётаПокуп, ЮрАдресПокуп, ФИО, БанкПокуп, УникНомер, ИННпост, НомСчётаПост, ГодИзд, КодНакл, Телефон то для этих атрибутов определим домен, состоящий из множества значений символьного типа данных.

Значение атрибутов КолСтр, СтоимПриобр, Количество, КоличествоКниг принадлежат домену с числовым (целые числа) типом данных,

Значение атрибута КомпактД принадлежат домену с типом данных Логический.

Значение атрибута Дата и ДатаНакл принадлежат домену с типом данных Дата (время).

Рисунок 10 – Модель данных в виде сущностей

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

Рисунок 11 – Нормализованная модель данных в виде атрибутов с доменами, типами данных, ключами, свойствами связей

Система ERWin позволяет вносить описания сущностей для адекватного понимания модели данных как проектировщиком, так и любым пользователем этой модели (рисунок 7).

Рисунок 12 – Модель данных в виде описаний

По полученной выше логической модели построим физическую модель для реляционной СУБД Access(рисунок 12).

Рисунок 13 – Физическая модель данных

Рисунок 15 – Диалог генерации схемы БД

Нажатие на кнопку Generate приведет к запуску процесса генерации схемы. Возникает диалог связи с базой данных, устанавливается сеанс связи с сервером-базы данных (СУБД Access), и начинает выполняться SQL-скрипт.

По умолчанию в диалоге Generate Database Schema включена опция Stop If Failure. Это означает, что при первой же ошибке выполнение скрипта прекращается. Щелкнув по кнопке Continue, можно продолжить выполнение. Кнопка Abort прерывает выполнение. При выключенной опции Stop If Failure скрипт будет выполняться, несмотря на встречающиеся ошибки. После выполнения скриптов в среде СУБД Access создается БД физического уровня.

Рисунок 16 – Схема данных БД

Проверим структуры таблиц, уточним свойства (основные и подстановки) полей.

Рисунок 17 – Форма таблицы Книги

Рисунок 18 – Запрос «Закупленные книги» в режиме конструктора

В режиме SQL запрос выглядит данным образом:

SELECT Книги.Название, Книги.КодКниги, Sum([Строки накладных].КоличествоКниг) AS Количество, Sum([Строки накладных]! [КоличествоКниг]*[Книги]! [СтоимПриобр]) AS Итого

FROM Книги INNER JOIN [Строки накладных] ON Книги.КодКниги = [Строки накладных].КодКниги

GROUP BY Книги.Название, Книги.КодКниги;

В запросе также применена сортировка для поля «Итого», чтобы максимальная сумма выводилась выше остальных.

Результат выполнения запроса представлен на рисунке 19:

Рисунок 19 – Результат выполнения запроса «Закупленные книги»

2. Создадим запрос, в котором выведем на экран список покупателей, количество закупленных ими книг за всё время и обшую сумму прибыли, принесённую ими (рисунок 20):

Рисунок 20 – Запрос «Учёт покупателей» в режиме конструктора

В режиме SQL запрос выглядит данным образом:

SELECT Покупатели.КодПокупателя, Покупатели.НазвОрг, Покупатели.ЮрАдресПокуп, Покупатели.ФИО, Sum([Строки счёт-фактур]! [Количество]) AS Количество, Sum([Книги]! [СтоимПриобр]*[Строки счёт-фактур]! [Количество]*1.2) AS [Cумма закупок покупателя]

FROM (Покупатели INNER JOIN [Счёт-фактуры] ON Покупатели.КодПокупателя = [Счёт-фактуры].КодПокупателя) INNER JOIN (Книги INNER JOIN [Строки счёт-фактур] ON Книги.КодКниги = [Строки счёт-фактур].КодКниги) ON [Счёт-фактуры].УникНомер = [Строки счёт-фактур].УникНомер

GROUP BY Покупатели.КодПокупателя, Покупатели.НазвОрг, Покупатели.ЮрАдресПокуп, Покупатели.ФИО;

Результат выполнения запроса представлен на рисунке 21:

Рисунок 21 – Результат выполнения запроса «Учёт покупателей»

Создадим отчет, в котором будут отображаться остатки книг на складе.

Запустим «Мастер отчетов», который представляет собой простейший способ создания отчетов. В окне создания отчетов выберем Запрос «Остаток книг на складе», на основе которого будет формироваться отчет, выберем все поля. Далее можно указать порядок сортировки записей. После необходимо выбрать стиль. На заключительном этапе, необходимо задать имя отчета и в группе переключателей «Дальнейшие действия» выбрать опцию «Просмотреть отчет». После нажатия кнопки «Готово» Мастер отчетов формирует отчет и представляет его в режиме предварительного просмотра.

Рисунок 22 – Отчёт «Остатки товаров на складе»

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

Выполнение отчетов и режим их конструктора можно посмотреть в самой базе данных.

Рисунок 23 – Структура главной кнопочной формы

Для создания элементов подчиненной кнопочной формы «Запросы» необходимо запустить базу данных и создать макросы «Открыть Запрос» или «Открыть Таблицу» с уникальными именами, а затем в кнопочной форме создают кнопки для вызова этих макросов.

При создании макроса необходимо выбрать объект «Макросы» и щелкнуть на пиктограмме «Создать», откроется окно диалога «Макрос». В открывшемся окне, в раскрывающемся списке выберите макрокоманду «Открыть Запрос» и из раскрывающегося списка выберите имя запроса, затем щелкните на кнопке «Закрыть». Затем следует сохранить макрос. Таким образом, создадим макросы для всех запросов и отчета.

Далее в каждом элементе создадим кнопки для возврата на главную кнопочную форму. Отформатировать главную кнопочную форму можно в режиме Конструктор (изменить цвета заливки и надписей, вставить рисунки).

В результате получим кнопочную форму, вид которой представлен на рисунке 24:

Рисунок 24 – Главная кнопочная форма

Рисунок 25 – Форма для ввода накладных

Информация, полученная в результате выполнения запросов, доступна только в режиме чтения.

Для доступа к отчетам необходимо нажать на главной кнопочной форме кнопку «Отчет».

Для выхода из системы нажмите на главной кнопочной форме кнопку «Выход из базы данных».

Тестирование базы данных

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

Цель данного тестирования – убедиться в надежности методов доступа к базе данных, в их правильном исполнении, без нарушения целостности данных.

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

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

При проведении тестирования базы данных «Учет материальных ценностей» ошибок в ее работе выявлено не было.

Результаты запроса “Наиболее популярные книги” представлены на рисунке 26.

Рисунок 26 – Результат запроса «Наиболее популярные книги»

Отчет “Итоги за период с 30.04.2016 до 02.05.2016” представлен на рисунке 27.

Рисунок 27 – Отчёт «Итоги за период»

ЗАКЛЮЧЕНИЕ

Организация автоматизированных информационных систем занимает значительное место в современном мире, нишу в котором теперь будет занимать спроектированная база данных «Учёт материальных ценностей».

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

Также причинами, по которым было необходимо создание базы данных «Учёт материальных ценностей» явилось:

· оперативный доступ к данным по книгам, покупателям, поставщикам, накладным и счёт-фактурам, возможность каждодневного их заполнения и, при необходимости, редактирования;

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

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

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

ПРИЛОЖЕНИЕ А. Код генерации базы данных Access

Dim ERwinWorkspace As Workspace

Dim ERwinDatabase As Database

Dim ERwinTableDef As TableDef

Dim ERwinQueryDef As QueryDef

Dim ERwinIndex As Index

Dim ERwinField As Field

Dim ERwinRelation As Relation

Set ERwinDatabase = ERwinWorkspace.OpenDatabase(" H: \Курсовая СБД\Абашев\база.mdb" )

' CREATE TABLE Книги

Set ERwinTableDef = ERwinDatabase.CreateTableDef(" Книги" )

Set ERwinField = ERwinTableDef.CreateField(" КодКниги", DB_TEXT, 20)

ERwinField.Required = True

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" Название", DB_TEXT, 20)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" Автор", DB_TEXT, 20)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" Издательство", DB_TEXT, 20)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" ГодИзд", DB_LONG)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" КолСтр", DB_LONG)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" СтоимПриобр", DB_LONG)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" КрСодерж", DB_TEXT, 20)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" КомпактД", DB_OLE)

ERwinTableDef.Fields.Append ERwinField

ERwinDatabase.TableDefs.Append ERwinTableDef

Set ERwinField = ERwinQueryDef.Fields(" КодКниги" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " КодКниги: " )

Set ERwinField = ERwinQueryDef.Fields(" Название" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " Название: " )

Set ERwinField = ERwinQueryDef.Fields(" Автор" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " Автор: " )

Set ERwinField = ERwinQueryDef.Fields(" Издательство" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " Издательство: " )

Set ERwinField = ERwinQueryDef.Fields(" ГодИзд" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " ГодИзд: " )

Set ERwinField = ERwinQueryDef.Fields(" КолСтр" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " КолСтр: " )

Set ERwinField = ERwinQueryDef.Fields(" СтоимПриобр" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " СтоимПриобр: " )

Set ERwinField = ERwinQueryDef.Fields(" КрСодерж" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " КрСодерж: " )

Set ERwinField = ERwinQueryDef.Fields(" КомпактД" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " КомпактД: " )

' CREATE INDEX XPKКниги

Set ERwinTableDef = ERwinDatabase.TableDefs(Книги)

Set ERwinIndex = ERwinTableDef.CreateIndex(XPKКниги)

Set ERwinField = ERwinIndex.CreateField(" КодКниги" )

ERwinIndex.Fields.Append ERwinField

ERwinIndex.Primary = True

ERwinTableDef.Indexes.Append ERwinIndex

' CREATE TABLE Накладные

Set ERwinTableDef = ERwinDatabase.CreateTableDef(" Накладные" )

Set ERwinField = ERwinTableDef.CreateField(" КодНакл", DB_TEXT, 20)

ERwinField.Required = True

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" КодПоставщика", DB_TEXT, 20)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" ДатаНакл", DB_DATETIME)

ERwinTableDef.Fields.Append ERwinField

ERwinDatabase.TableDefs.Append ERwinTableDef

Set ERwinField = ERwinQueryDef.Fields(" КодНакл" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " КодНакл: " )

Set ERwinField = ERwinQueryDef.Fields(" КодПоставщика" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " КодПоставщика: " )

Set ERwinField = ERwinQueryDef.Fields(" ДатаНакл" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " ДатаНакл: " )

' CREATE INDEX XPKНакладные

Set ERwinTableDef = ERwinDatabase.TableDefs(Накладные)

Set ERwinIndex = ERwinTableDef.CreateIndex(XPKНакладные)

Set ERwinField = ERwinIndex.CreateField(" КодНакл" )

ERwinIndex.Fields.Append ERwinField

ERwinIndex.Primary = True

ERwinTableDef.Indexes.Append ERwinIndex

' CREATE TABLE Покупатели

Set ERwinTableDef = ERwinDatabase.CreateTableDef(" Покупатели" )

Set ERwinField = ERwinTableDef.CreateField(" КодПокупателя", DB_TEXT, 20)

ERwinField.Required = True

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" НазвОрг", DB_TEXT, 20)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" ЮрАдресПокуп", DB_TEXT, 20)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" ИННПокуп", DB_LONG)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" ФИО", DB_TEXT, 20)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" Телефон", DB_LONG)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" БанкПокуп", DB_TEXT, 20)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField(" НомСчётаПокуп", DB_LONG)

ERwinTableDef.Fields.Append ERwinField

ERwinDatabase.TableDefs.Append ERwinTableDef

Set ERwinField = ERwinQueryDef.Fields(" КодПокупателя" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " КодПокупателя: " )

Set ERwinField = ERwinQueryDef.Fields(" НазвОрг" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " НазвОрг: " )

Set ERwinField = ERwinQueryDef.Fields(" ЮрАдресПокуп" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " ЮрАдресПокуп: " )

Set ERwinField = ERwinQueryDef.Fields(" ИННПокуп" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " ИННПокуп: " )

Set ERwinField = ERwinQueryDef.Fields(" ФИО" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " ФИО: " )

Set ERwinField = ERwinQueryDef.Fields(" Телефон" )

Call SetFieldProp(ERwinField, " Caption", DB_TEXT, " Телефон: " )

Set ERwinField = ERwinQueryDef.Fields(" БанкПокуп" )

12 3 4 5 6 7 8 9 10 Следующая ⇒