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

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

Текст:

­­Белорусский республиканский союз потребительских обществ

Учреждение образования

«Белорусский торгово-экономический университет

потребительской кооперации»

Кафедра информационно-вычислительных систем

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

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

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

Студента

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

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

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

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 КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ МОДЕЛИ ДАННЫХ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выделим базовые объекты (сущности) предметной области согласно диаграмме DFD (см. рисунок 3): поставщики книг, покупатели, книги, счёт-фактуры. Определим характеристики, присущие каждому объекту:

·                   Поставщики книг: код поставщика, наименование поставщика, идентификационный номер налогоплательщика (ИНН), юридический адрес, банк, номер счёта в банке;

·                   Книги: код книги, название книги, автор(ы), издательство, год издания, количество страниц, стоимость приобретения, краткое содержание книги, наличие компакт-диска;

·                   Покупатели: Если покупатель юридическое лицо: код покупателя, название организации, юридический адрес, ИНН, ответственное за покупки лицо или директор, телефон, банк, номер счёта в банке. Если покупатель физическое лицо: код покупателя, фамилия, имя, отчество, адрес, телефон.

·                   Счёт-фактуры: уникальный номер, дата, книги, стоимость, сумма к оплате.

·                   Накладные: код накладной, дата, книги, стоимость, сумма к оплате.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ МОДЕЛИ ДАННЫХ

2.1 Теоретические основы логического проектирования

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

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

2. Определение набора таблиц исходя из ER-модели и их документирование. Для каждой сущности ER-модели создается таблица. Имя сущности – имя таблицы. Осуществляется формирование структуры таблиц на основании изложенных в параграфе 1.4 правил. Устанавливаются связи между таблицами посредством механизма первичных и внешних ключей. Структуры таблиц и установленные связи между ними документируются.

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

4. Проверка логической модели данных  на предмет возможности выполнения всех транзакций, предусмотренных пользователями. Транзакция – это набор действий, выполняемых отдельным пользователем или прикладной программой с целью изменения содержимого базы данных. Так, примером транзакции в проекте БАНК может быть передача права распоряжаться счетами некоторого клиента другому клиенту. В этом случае в базу данных потребуется внести сразу несколько изменений. Если во время выполнения транзакции произойдет сбой в работе компьютера, то база данных окажется в противоречивом состоянии, так как некоторые изменения уже будут внесены, а остальные еще нет. Поэтому все частичные изменения должны быть отменены для возвращения базы данных в прежнее непротиворечивое состояние.

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

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

·                   обязательные данные. Выясняется, есть ли атрибуты, которые не могут иметь Null-значений;

·                   ограничения для значений атрибутов. Определяются допустимые значения для атрибутов;

·                   целостность сущностей. Она достигается, если первичный ключ сущности не содержит Null-значений;

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

·                   ограничения, накладываемые бизнес-правилами. Например, в случае с проектом БАНК может быть принято правило, запрещающее клиенту распоряжаться, скажем, более чем тремя счетами.

·                   Сведения обо всех установленных ограничениях целостности данных помещаются в словарь данных.

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

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

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

Для каждой сущности создается таблица. Причем каждому атрибуту сущности соответствует столбец таблицы.

Правила генерации таблиц из ER-диаграмм опираются на два основных фактора – тип связи и класс принадлежности сущности. Изложим их.

Правило 1

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

Правило 2

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

Правило 3

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

Правило 4

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

Правило 5

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

Правило 6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первая нормальная форма (1NF) – переменная отношения находится в первой нормальной форме тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов.

В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение.

Что же касается различных таблиц, то они могут не быть правильными представлениями отношений и, соответственно, могут не находиться в 1NF. В соответствии с определением К. Дж. Дейта для такого случая, таблица нормализована (эквивалентно — находится в первой нормальной форме) тогда и только тогда, когда она является прямым и верным представлением некоторого отношения. Конкретнее, рассматриваемая таблица должна удовлетворять следующим пяти условиям:

·                   Нет упорядочивания строк сверху-вниз (другими словами, порядок строк не несет в себе никакой информации).

·                   Нет упорядочивания столбцов слева-направо (другими словами, порядок столбцов не несет в себе никакой информации).

·                   Нет повторяющихся строк.

·                   Каждое пересечение строки и столбца содержит ровно одно значение из соответствующего домена (и больше ничего).

·                   Все столбцы являются обычными.

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

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

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

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

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

Третья нормальная форма (3NF) – Переменная отношения R находится в 3NF тогда и только тогда, когда выполняются следующие условия:

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

Пояснения к определению:

Неключевой атрибут отношения R — это атрибут, который не принадлежит ни одному из потенциальных ключей R.

Функциональная зависимость множества атрибутов Z от множества атрибутов X (записывается X → Z, произносится «икс определяет зет») является транзитивной, если существует такое множество атрибутов Y, что X → Y и Y → Z. При этом ни одно из множеств X, Y и Z не является подмножеством другого, то есть функциональные зависимости X → Z, X → Y и Y → Z не являются тривиальными.

Определение 3NF, эквивалентное определению Кодда, но по-другому сформулированное, дал Карло Заниоло в 1982 году. Согласно ему, переменная отношения находится в 3NF тогда и только тогда, когда для каждой из её функциональных зависимостей X → A выполняется хотя бы одно из следующих условий:

Х содержит А (то есть X → A — тривиальная функциональная зависимость)

Х — суперключ

А — ключевой атрибут (то есть А входит в состав потенциального ключа).

Определение Заниоло четко определяет разницу между 3NF и более строгой нормальной формой Бойса-Кодда (НФБК): НФБК исключает третье условие («А — ключевой атрибут»).

Проведем нормализацию полученной модели данных.

Рассмотрим отношение  ПоставщикиКниг. В результате концептуального проектирования получим реляционную схему этого отношения:

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

Проверим его на соответствие 1НФ. Так как значения всех атрибутов атомарны, значит отношение ПоставщикиКниг соответствует 1НФ.

Проверим на соответствие 2НФ. Отношение ПоставщикиКниг имеет 2НФ, так как все не ключевые атрибуты зависят от первичного ключа.

Проверим, находится ли отношение в 3НФ. Так как отношение ПоставщикиКниг не имеет транзитивных зависимостей, то  оно имеет 3НФ.

В результате проверки на соответствия нормальным формам мы получаем:

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

Рассмотрим отношение Книги. В результате концептуального проектирования получили реляционную схему отношения Книги:

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

Проверим его на соответствие 1НФ.  Значения всех атрибутов атомарны, поэтому отношение имеет 1НФ.

Отношение Книги имеет 2НФ, так как все не ключевые атрибуты зависят от несоставного первичного ключа.

Проверим его на соответствие 3НФ. Так как отношение Книги не имеет транзитивных зависимостей, то оно имеет 3НФ.

В результате проверки на соответствия нормальным формам мы получаем:

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

Рассмотрим отношение Счёт-фактуры: В результате концептуального проектирования получили реляционную схему этого отношения:

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

Проверим его на соответствия 1НФ. Значения всех атрибутов атомарны, поэтому отношение имеет 1НФ.

Отношение Счёт-фактуры имеет 2НФ, так как все не ключевые атрибуты зависят от несоставного первичного ключа.

Так как отношение Счёт-фактуры не имеет транзитивных зависимостей, то оно имеет 3НФ.

В результате проверки на соответствия нормальным формам мы получаем:

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

Рассмотрим отношение Накладные: В результате концептуального проектирования получили реляционную схему этого отношения:

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

Проверим его на соответствия 1НФ. Значения всех атрибутов атомарны, поэтому отношение имеет 1НФ.

Отношение Накладные имеет 2НФ, так как все не ключевые атрибуты зависят от несоставного первичного ключа.

Так как отношение Накладные не имеет транзитивных зависимостей, то оно имеет 3НФ.

В результате проверки на соответствия нормальным формам мы получаем:

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

Рассмотрим отношение Покупатели: В результате концептуального проектирования получили реляционную схему этого отношения:

Покупатели (КодПокупателя, НазвОрг, ЮрАдресПокуп, ИННпокуп, ФИО, Телефон, БанкПокуп, НомСчётаПокуп). Проверим его на соответствия 1НФ. Значения всех атрибутов атомарны, поэтому отношение имеет 1НФ.

Отношение Покупатели имеет 2НФ, так как все не ключевые атрибуты зависят от несоставного первичного ключа.

Так как отношение Покупатели не имеет транзитивных зависимостей, то оно имеет 3НФ.

В результате проверки на соответствия нормальным формам мы получаем:

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

Рассмотрим отношение Строки счёт-фактур: В результате концептуального проектирования получили реляционную схему этого отношения:

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

Проверим его на соответствия 1НФ. Значения всех атрибутов атомарны, поэтому отношение имеет 1НФ.

Отношение Строки счёт-фактур имеет 2НФ, так как все не ключевые атрибуты зависят от несоставного первичного ключа.

Так как отношение Строки счёт-фактур не имеет транзитивных зависимостей, то оно имеет 3НФ.

В результате проверки на соответствия нормальным формам мы получаем:

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

Рассмотрим отношение Строки накладных: В результате концептуального проектирования получили реляционную схему этого отношения:

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

Проверим его на соответствия 1НФ. Значения всех атрибутов атомарны, поэтому отношение имеет 1НФ.

Отношение Строки накладных имеет 2НФ, так как все не ключевые атрибуты зависят от несоставного первичного ключа.

Так как отношение Строки накладных не имеет транзитивных зависимостей, то оно имеет 3НФ.

В результате проверки на соответствия нормальным формам мы получаем:

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

Получили нормализованную модель данных:

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

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

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

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

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

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

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

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

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

ERwin является инструментом, который дает возможность логично продолжить разработку информационной системы в рамках единой технологической цепочки, создавая тесно интегрированную с функциональной моделью модель данных, генерируя соответствующую структуру на любом из поддерживаемых им серверов БД (а таковых более двадцати) и автоматически генерируя код клиентского приложения на PowerBuilder или VisualBasic.

Достоинство системы ERwin состоит  в следующем – построив один раз полноценную модель базы данных Вы можете легко ее развивать, модифицировать и переносить с одного сервера базы данных на другой. Кроме того, с помощью удобного представления Вы имеете возможность донести до конечного разработчика все нюансы разрабатываемой базы. Используя стандарт IDEF1X, разработанный военно-воздушными силами США, ERwin позволяет создавать сложные документы в виде простом для понимания. Вы используете ERwin для рисования диаграмм, но это больше чем просто инструмент для рисования.  ERwin не только позволяет Вам создать логическую модель, он также автоматически строит физические структуры данных по информации в Вашей диаграмме. Нет необходимости тратить время на создание скриптов, создающих базу. База теперь создается в считанные минуты. ERwin полностью поддерживает возможности FRE (ForwardAndReverseEngineering) с использованием каталогов целевого сервера. Учитывая приведенные выше замечания можно сказать, что система является незаменимым инструментом для разработчика баз данных.

Все сущности, их атрибуты и связи между сущностями представлены на ERWin-модели в различных видах. На рисунке 5 представлена модель данных в виде сущностей.

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

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

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

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

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

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

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


3 ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ СУБД ACCESS

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

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

Физическое проектирование является третьим и последним этапом создания проекта базы данных, при выполнении которого проектировщик принимает решения о способах реализации разрабатываемой базы данных. Во время предыдущего этапа проектирования была определена логическая структура базы данных (которая описывает отношения и ограничения в рассматриваемой прикладной области). Хотя эта структура не зависит от конкретной целевой СУБД, она создается с учетом выбранной модели хранения данных, например реляционной, сетевой или иерархической. Однако, приступая к физическому проектированию базы данных, прежде всего необходимо выбрать конкретную целевую СУБД. Поэтому физическое проектирование неразрывно связано с конкретной СУБД. Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных.

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

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

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

2.                определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;

3.                разработка средств защиты создаваемой системы.

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

Они связаны с совершенно разными аспектами системы, поскольку отвечают на вопрос, что делать, а не как делать.

Они выполняются в разное время, поскольку понять, что надо сделать, следует прежде, чем решить, как это сделать.

Они требуют совершенно разных навыков и опыта, поэтому требуют привлечения специалистов различного профиля.

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

Этапы физического проектирования баз данных:

1.                Перенос глобальной логической модели данных в среду целевой СУБД.

2.                Проектирование основных отношений.

3.                Разработка способов получения производных данных.

4.                Реализация ограничений предметной области.

5.                Проектирование физического представления базы данных.

6.                Анализ транзакций.

7.                Выбор файловой структуры.

8.                Определение индексов.

9.                Определение требований к дисковой памяти.

10.           Проектирование пользовательских представлений.

11.           Разработка механизмов защиты.

12.           Обоснование необходимости введения контролируемой избыточности.

13.           Текущий контроль и настройка операционной системы.

Физическое проектирование баз данных включает шесть основных этапов. Концептуальное и логическое проектирование охватывает три первых этапа разработки баз данных, а физическое проектирование — этапы 4-9. Этап 4 стадии физического проектирования включает разработку основных отношений и реализацию ограничений предметной области с использованием доступных функциональных средств целевой СУБД, На этом этапе должно быть также принято решение по выбору способов получения производных данных, которые включены в модель данных.

Этап 5 включает выбор файловой организации и индексов для основных отношений. Как правило, СУБД для персональных компьютеров имеют фиксированную структуру внешней памяти, а другие СУБД предоставляют несколько альтернативных вариантов файловой организации для хранения данных. С точки зрения пользователя организация внутренней структуры хранения отношений должна быть совершенно прозрачной — пользователь должен иметь возможность получать доступ к любому отношению и к отдельным его строкам без учета способа хранения данных. Это означает, что СУБД должна обеспечивать полную независимость физического хранения данных от их логической организации. Только в этом случае внесение изменений в физическую организацию базы данных не окажет никакого влияния на работу пользователей. Соответствие между логической моделью данных и физической моделью данных определяется внутренней схемой базы данных. Разработчик должен предоставить подробные физические проекты базы данных с учетом применяемой СУБД и операционной системы. В проекте реализации базы данных в СУБД разработчик должен определить структуры файлов, которые будут использоваться для представления каждого отношения. В проекте реализации базы данных в операционной системе разработчик должен указать расположение отдельных файлов и обеспечить необходимую их защиту. Прежде чем приступить к изучению этапа 5 рассматриваемой методологии, рекомендуем читателю ознакомиться со сведениями о файловой организации и структурах внешней памяти, приведенными в приложении В.

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

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

Проектирование физического представления базы данных:

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

·        Анализ транзакций

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

·        Выбор файловой структуры

- Определение наиболее эффективной файловой структуры для каждого базового отношения.

·        Выбор индексов

- Определение того, будет ли добавление индексов способствовать повышению производительности системы.

·        Определение требований к дисковому пространству

- Оценка объема дискового пространства, необходимого для размещения базы данных.


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

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

Затем открываем ER-диаграмму в среде ERwin и с помощью списка выбора в стандартной панели инструментов производим переключение между логической и физической моделью. При переключении, если физической модели еще не существует, она будет создана автоматически. Теперь надо выбрать СУБД, в которой будем производить генерацию БД физического уровня. Для этого следует выполнить команду DATABASE / Choose database, в появившемся диалоговом окне (рисунок 14) выбрать интересующую СУБД Access и щелкнуть по кнопке <ОК>.

Рисунок 14 – Диалог выбора СУБД (сервера)

Для установления соединения БД из ERwin c целевой СУБД Access необходимо выполнить команду DATABASE/Database connection. В появившемся диалоговом окне необходимо указать путь к БД в СУБД Access, вписать имя admin и нажать кнопку Connect. Для генерации БД физического уровня в среде СУБД Access необходимо выполнить команду TOOLS/Forward Engineering/Schema Generation.

Кнопка Preview вызывает диалог Schema Generation Preview, в котором отображается SQL-скрипт, создаваемый ERwin для генерации системного каталога СУБД (рисунок 15).

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

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

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

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

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

3.3 Организация ввода и корректировки данных (формы)

Access предоставляет возможность вводить данные как непосредственно в таблицу, так и с помощью форм. Форма в БД - это структурированное окно, которое можно представить так, чтобы оно повторяло форму бланка. Формы создаются из набора отдельных элементов управления.

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

Форма предоставляет возможности для:

1.  ввода и просмотра информации базы данных

2.  изменения данных

3.  печати

4.  создания сообщений

Форму в Microsoft Access 2010 можно создать различными способами:

1.  Конструктор форм (предназначен для создания формы любой сложности);

2.  Мастер форм (позволяет создавать формы различные как по стилю, так и по содержанию);

3.  Автоформа: в столбец (многостраничная – поля для записи выводятся в один столбец, в форме одновременно отображаются данные для одной записи);

4.  Автоформа: ленточная (все поля записи выводятся в одну строку, в форме отображаются все записи);

5.  Автоформа: табличная (отображение записей осуществляется в режиме таблица);

6.  Автоформа: сводная таблица;

7.  Автоформа: сводная диаграмма;

8.  Диаграмма (создается форма с диаграммой, построенной Microsoft Graph);

9.  Сводная таблица (создается форма Access, отображаемая в режиме сводной таблицы Excel);

Алгоритм создания форм следующий:

1)    Открыть окно БД;

2)    В окне БД выбрать вкладку Формы;

Щелкнуть по пиктограмме «Создать», расположенной на панели инструментов окна БД.

В появившемся диалоговом окне «Новая форма» Выбрать способ создания формы и источник данных

Щелкнуть по кнопке ОК.

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

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

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

Применяются два типа запросов: по образцу (QBE – Query by example) и структурированный язык запросов (SQL – Structured Query Language).

QBE – средство для отыскания необходимой информации в базе данных. Он формируется не на специальном языке, а путем заполнения бланка запроса в окне Конструктора запросов.

SQL – это запросы, которые составляются (программистами) из последовательности SQL – инструкций. Эти инструкции задают, что надо сделать с входным набором данных для генерации выходного набора. Все запросы Access строит на основе SQL запросов, чтобы посмотреть их, необходимо в активном окне проектирования запроса выполнить команду Вид/SQL.

По результатам действий и особенностям выполнения запросы можно разделить следующим образом:

1)    запросы на выборку, используемые для того, чтобы отобрать и представить в удобном виде данные из одной или нескольких таблиц (или запросов);

2)    параметрические запросы, которые позволяют задавать конкретные условия отбора непосредственно при выполнении запроса;

3)    перекрестные запросы, которые позволяют провести группировку и вычисления, а также представить данные в компактном виде, близком к сводной таблице Microsoft Excel;

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

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

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

Чтобы вызвать Конструктор запросов, необходимо в окне база данных выбрать вкладку Запросы и дважды щелкнуть на пиктограмме Создание запроса в режиме конструктора. Появится активное окно Добавление таблицы на фоне неактивного окна «Запрос: запрос на выборку».

В окне Добавление таблицы следует выбрать таблицу – источник или несколько таблиц из представленного списка таблиц, на основе которых будет проводиться выбор данных, и щелкнуть на кнопке «Добавить». После этого закрыть окно Добавление таблицы, окно «Запрос: запрос на выборку» станет активным.

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

В нижней части окна находится Бланк построения запроса QBE (Query by Example), в котором каждая строка выполняет определенную функцию:

1.       Поле – указывает имена полей, которые участвуют в запросе.

2.       Имя таблицы – имя таблицы, с которой выбрано это поле.

3.       Сортировка – указывает тип сортировки.

4.       Вывод на экран – устанавливает флажок просмотра поля на экране.

5.       Условия отбора  - задаются критерии поиска.

6.       Или – задаются дополнительные критерии отбора.

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

Данный запрос в режиме Конструктора должен иметь следующий вид:

Рисунок 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 – Отчёт «Остатки товаров на складе»

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

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

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

Главная кнопочная форма – это главное меню базы данных. Главная кнопочная форма отображается при запуске базы данных и обеспечивает навигацию по базе данных и придает ей законченный вид. Элементами главной кнопочной формы являются объекты форм и отчётов.
Технология создания кнопочных форм следующая:

1) создать страницу главной кнопочной формы;

2) создать необходимое количество страниц подчиненных кнопочных форм (например, формы для ввода данных, для отчетов, для запросов и т.д.);

3) создать элементы главной кнопочной формы;

4) создать элементы для кнопочных форм отчетов и форм ввода или изменения данных;

5) создать макросы для запросов или для таблиц с уникальными именами;

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

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

Необходимо создать четыре страницы кнопочной формы: Таблицы, Отчеты, Запросы, Формы и Выход. Для этого следует щелкнуть на кнопке «Создать» и в появившемся окне ввести имя новой страницы «Таблицы» и щелкнуть на кнопке «ОК». Будет создана страница кнопочной формы «Таблицы».

Аналогичным образом создаются остальные кнопки.

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

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

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

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

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

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

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

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

Разработанная БД предназначена для предоставления всей необходимой информации для автоматизации процесса оборота книг в мелкооптовом магазине.

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

При открытии файла «База.mdb» запустится  СУБД MS Access.

Для ввода данных использует формы, в которые информации вносится с помощью клавиатуры. Для ввода и редактирования данных, необходимо выделить необходимое поле и ввести или отредактировать данные.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

,

Где  – длина записи в i-й таблице (в байтах);

Ni – примерное (максимально возможное) количество записей в i-й таблице;

Na – количество записей в архиве i-й таблицы.

Коэффициент 2 перед суммой необходим для того, чтобы выделить памяти для хранения индексов, промежуточных данных, для выполнения объёмных операций (например, сортировки) и т.п.

Рассчитаем приблизительно, какой объем памяти необходим для хранения данных в базе  “Учет материальных ценностей” за первый год. Предположим, что в базе хранится информация о 1000 книг (по 1 кбайту на каждую книгу), 3000 накладных (по 1 кбайту на каждую накладную), 3000 счёт-фактур (по 1 кбайту на каждую счёт-фактуру),  50 Поставщиков (по  1 кбайту на каждого поставщика), 50 покупателей (по 1 кбайту на каждого покупателя). Тогда объем памяти для хранения данных приблизительно составит

ПД=2*(1000*1+1*3000+1*3000+50*1+50*1)= 14200 кбайтов.


ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1.           Рудикова, Л. В. Проектирование баз данных : учеб. Пособие /Л.В. Рудикова. – Минск: ИВЦ Минфина, 2009. – 352 с.

2.           Кузнецов, С.Д. Основы баз данных : учеб. Пособие / С.Д. Кузнецов. – М. : Интернет-УИТ

3.           Моисеенко, С. И. SQL. Задачи и решения / С.И. Моисеенко. – СПб. : Питер,  2006. – 1168 с.

4.           Гарсиа-Молина, Г. Системы баз данных. Полный курс : [пер. с англ.] / Г. Гарсиа-Молина, Дж. Ульман, Дж. Уидом. – М. : Вильямс, 2003. – 1088 с.

5.           Коннолли, Т. Базы данных: проектирование, реализация и сопровождение. Теория и практика : [пер. с англ.] / Т. Коннолли, К. Бегг. – 2-е изд. – М. : Вильямс, 2000. – 1120 с.

6.           Вейскас, Дж. Эффективная работа с Microsoft Office Access 2003 : [пер. с англ.] / Дж. Вейскас. – СПб. : Питер, 2005. – 1168 с.

7.           Коннолли, Т. Базы данных: проектирование, реализация и сопровождение. Теория и практика : [пер. с англ.] / Т. Коннолли, К. Бегг. – 3-е изд. – М. : Вильямс, 2003. – 1440 с.

8.           Роб, П. Системы баз данных: проектирование, реализация, управление : [пер. с англ.] / П. Роб, К. Коронел. – 5-е изд., перераб. и доп. – СПб. : БХВ-Петербург, 2004. – 1040 с.


ПРИЛОЖЕНИЕ А. Код генерации базы данных 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("БанкПокуп")

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_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_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 , "НомСчётаПост:")

"  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)

ERwinField.Required = True

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 , "КоличествоКниг:")

"  CREATE INDEX XPKСтроки накладных

Set ERwinTableDef = ERwinDatabase.TableDefs(Строки накладных)

Set ERwinIndex = ERwinTableDef.CreateIndex(XPKСтроки накладных)

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

ERwinIndex.Fields.Append ERwinField

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)

ERwinField.Required = True

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 , "Количество:")

"  CREATE INDEX XPKСтроки счёт-фактур

Set ERwinTableDef = ERwinDatabase.TableDefs(Строки счёт-фактур)

Set ERwinIndex = ERwinTableDef.CreateIndex(XPKСтроки счёт-фактур)

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

ERwinIndex.Fields.Append ERwinField

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_DATETIME)

ERwinTableDef.Fields.Append ERwinField

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

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 RELATIONSHIP Выдаётся

Set ERwinRelation = ERwinDatabase.CreateRelation(Выдаётся, Поставщики книг, Накладные)

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

ERwinField.ForeignName = КодПоставщика

ERwinRelation.Fields.Append ERwinField

ERwinDatabase.Relations.Append ERwinRelation

"  CREATE RELATIONSHIP Хранят

Set ERwinRelation = ERwinDatabase.CreateRelation(Хранят, Накладные, Строки накладных)

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

ERwinField.ForeignName = КодНакл

ERwinRelation.Fields.Append ERwinField

ERwinDatabase.Relations.Append ERwinRelation

"  CREATE RELATIONSHIP Имеют

Set ERwinRelation = ERwinDatabase.CreateRelation(Имеют, Книги, Строки накладных)

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

ERwinField.ForeignName = КодКниги

ERwinRelation.Fields.Append ERwinField

ERwinDatabase.Relations.Append ERwinRelation

"  CREATE RELATIONSHIP Включают

Set ERwinRelation = ERwinDatabase.CreateRelation(Включают, Книги, Строки счёт-фактур)

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

ERwinField.ForeignName = КодКниги

ERwinRelation.Fields.Append ERwinField

ERwinDatabase.Relations.Append ERwinRelation

"  CREATE RELATIONSHIP Содержат

Set ERwinRelation = ERwinDatabase.CreateRelation(Содержат, Счёт-фактуры, Строки счёт-фактур)

Set ERwinField = ERwinRelation.CreateField( "УникНомер" )

ERwinField.ForeignName = УникНомер

ERwinRelation.Fields.Append ERwinField

ERwinDatabase.Relations.Append ERwinRelation

"  CREATE RELATIONSHIP Выписываются

Set ERwinRelation = ERwinDatabase.CreateRelation(Выписываются, Покупатели, Счёт-фактуры)

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

ERwinField.ForeignName = КодПокупателя

ERwinRelation.Fields.Append ERwinField

ERwinDatabase.Relations.Append ERwinRelation

ERwinDatabase.Close

ERwinWorkspace.Close

"   Terminating Access Basic DAO Session...


ПРИЛОЖЕНИЕ Б. Формы

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

Рисунок Б.2 – Форма «Книги»

Рисунок Б.3 – Форма «Покупатели»

Рисунок Б.4 – Форма «Поставщики книг»

Рисунок Б.5 – Форма «Накладные»

Рисунок Б.6 – Форма «Счёт-фактуры»


ПРИЛОЖЕНИЕ В. Запросы

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

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

Рисунок В.2 – Запрос «Проданные книги» в режиме Конструктор

SELECT Книги.Название, Книги.КодКниги, Sum([Строки счёт-фактур].Количество) AS Количество, Sum([Строки счёт-фактур]![Количество]*[Книги]![СтоимПриобр]*1.2) AS Итого FROM Книги INNER JOIN [Строки счёт-фактур] ON Книги.КодКниги = [Строки счёт-фактур].КодКниги GROUP BY Книги.Название, Книги.КодКниги;

Рисунок В.3 – Запрос «Наиболее активные покупатели» в режиме Конструктор

SELECT Покупатели.КодПокупателя, Покупатели.НазвОрг, Sum([Количество]+0) AS [Количество книг], Sum([Строки счёт-фактур]!Количество*Книги!СтоимПриобр*1.2) AS [Сумма прибыли] FROM (Покупатели INNER JOIN [Счёт-фактуры] ON Покупатели.КодПокупателя = [Счёт-фактуры].КодПокупателя) INNER JOIN (Книги INNER JOIN [Строки счёт-фактур] ON Книги.КодКниги = [Строки счёт-фактур].КодКниги) ON [Счёт-фактуры].УникНомер = [Строки счёт-фактур].УникНомер GROUP BY Покупатели.КодПокупателя, Покупатели.НазвОрг ORDER BY Sum([Количество]+0) DESC , Sum([Строки счёт-фактур]!Количество*Книги!СтоимПриобр*1.2) DESC;

Рисунок В.4 – Запрос «Наиболее популярные книги» в режиме Конструктор

SELECT Книги.КодКниги, Книги.Название, Книги.Автор, Sum([Строки счёт-фактур].Количество) AS Продано FROM [Счёт-фактуры] INNER JOIN (Книги INNER JOIN [Строки счёт-фактур] ON Книги.КодКниги = [Строки счёт-фактур].КодКниги) ON [Счёт-фактуры].УникНомер = [Строки счёт-фактур].УникНомер GROUP BY Книги.КодКниги, Книги.Название, Книги.Автор ORDER BY Sum([Строки счёт-фактур].Количество) DESC;

Рисунок В.5 – Запрос «Остаток книг на складе» в режиме Конструктор

SELECT Книги.Название, [Закупленные книги]![Количество]-[Проданные книги]![Количество] AS [Остаток книг] FROM (Книги INNER JOIN [Закупленные книги] ON Книги.КодКниги = [Закупленные книги].КодКниги) INNER JOIN [Проданные книги] ON Книги.КодКниги = [Проданные книги].КодКниги GROUP BY Книги.Название, [Закупленные книги]![Количество]-[Проданные книги]![Количество];

Рисунок В.6 – Запрос «Учёт поставщиков» в режиме Конструктор

SELECT [Поставщики книг].КодПоставщика, [Поставщики книг].НаимПоставщика, Sum([Строки накладных].КоличествоКниг) AS [Количество проданных нам книг], Sum(Книги!СтоимПриобр*[Строки накладных]!КоличествоКниг) AS [Сумма всех поставок] FROM [Поставщики книг] INNER JOIN (Накладные INNER JOIN (Книги INNER JOIN [Строки накладных] ON Книги.КодКниги = [Строки накладных].КодКниги) ON Накладные.КодНакл = [Строки накладных].КодНакл) ON [Поставщики книг].КодПоставщика = Накладные.КодПоставщика GROUP BY [Поставщики книг].КодПоставщика, [Поставщики книг].НаимПоставщика;

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

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

Рисунок В.8 – Запрос «Итоги за период» в режиме Конструктор

SELECT First(СуммаЗакупокЗаПериод.[Количество книг]) AS [Количесто закупленных книг], СуммаЗакупокЗаПериод.Итого AS [Сумма закупок], СуммаПродажЗаПериод.Количество AS [Количество проданных книг], СуммаПродажЗаПериод.Итого AS [Сумма продаж], [СуммаПродажЗаПериод]![Итого]-[СуммаЗакупокЗаПериод]![Итого] AS [Финансовый итог] FROM Книги, СуммаЗакупокЗаПериод, СуммаПродажЗаПериод

GROUP BY СуммаЗакупокЗаПериод.Итого, СуммаПродажЗаПериод.Количество, СуммаПродажЗаПериод.Итого, [СуммаПродажЗаПериод]![Итого]-[СуммаЗакупокЗаПериод]![Итого];

ПРИЛОЖЕНИЕ Г. Отчёты

Рисунок Г.1 – Отчёт «Финансовые итоги за день» в режиме Конструктор

Рисунок Г.2 – Отчёт «Финансовые итоги за период» в режиме Конструктор

Рисунок Г.3 – Отчёт «Остаток книг» в режиме Конструктор

Информация о файле
Название файла Проектирование базы данных учета материальных ценностей от пользователя Гость
Дата добавления 5.5.2020, 18:14
Дата обновления 5.5.2020, 18:14
Тип файла Тип файла (zip - application/zip)
Скриншот Не доступно
Статистика
Размер файла 4.59 мегабайт (Примерное время скачивания)
Просмотров 468
Скачиваний 129
Оценить файл