Требование к программе и программному изделию.

а) Требование к функциональным характеристикам:

- хранение входной информации;

- непротиворечивость данных;

- поиск данных на основе пользовательских запросов;

- вывод отчетов в разрезе заказчиков и договоров, содержащих оплаченные суммы и недоплату по заказанным заданным товарам.

б) Требования к надежности.

Чтобы избежать нарушения надежности информации при разработке информационной системы следует учесть следующие моменты:

- возможность повторного ввода информации;

- каскадное удаление данных;

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

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

в) Требования к составу и параметрам технических средств.

Для внедрения и дальнейшего использования информационной системы необходимо иметь рабочую станцию с процессором IntelCorei7, тактовой частотой 2.7 ГГц, оперативной памятью ddr4 объемом 1 Гб. Необходимо иметь сетевое оборудование для создания режима клиент-сервер. Так же важно наличие у рабочей станции устройств ввода/вывода.

г) Требования к информационной и программной совместимости.

Программа должна работать корректно и обрабатываться под управлением СУБД MicrosoftAccess 2007, в среде ОС Windows 7/8/8.1/10. Также в СУБД необходимо наличие высокоуровневого языка программирования VisualBasicApplication(VBA).

д) Требования к программной документации.

При проектировании информационной системы должно быть описание базы данных, её схема, иналичие таких документов как:

- описание программы;

- техническое задание;

- пояснительная записка к проекту;

- инструкции по эксплуатации;

- руководство программиста;

- руководство пользователя.

    2. Проектная часть.

    2.1. Концептуальное проектирование.

    Концептуальное проектирование – это сбор, анализ и редактирование требований к данным. Для концептуального проектированиянеобходимо осуществить описание сущностей и их атрибутов, а также описание связей между сущностями. После описания сущностей и связей между ними мы получаем концептуальную модель (приложение Б, рисунок Б1). Чаще всего она представлена в виде модели «сущность-связь». При анализе предметной области выявлено 5 сущностей.

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

    2. Сущность «Счет» содержит атрибуты: № счета, № договора, наименование плательщика, адрес плательщика, ИНН плательщика, наименование товара, единица измерения, количество, цена, сумма, общая сумма. дата счета. В качестве первичного ключа для сущности «Счет» выбраны атрибуты: наименование товара и № счета.

    3. Сущность «Платежное поручение» содержит атрибуты: №платежного поручения, № документа основания, дата, наименование плательщика, адрес плательщика, ИНН плательщика, наименование товара, единица измерения, цена, количество, сумма, общая сумма. В качестве первичного ключа для сущности «Платежное поручение» выбраны атрибуты: № платежного поручения, № документа основания, наименование товаров.

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

    5. Сущность «Справочник плательщиков» содержит атрибуты: ИНН плательщика, наименование плательщика, адрес плательщика. В качестве первичного ключа для сущности «Справочник плательщиков» выбран атрибут: наименование плательщика.

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

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

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

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

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

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

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

    Между сущностью «Договор» и сущностью «Счет» установлена связь с показателем кардинальности «многие ко многим». Со стороны «многих» сущность «Счет», со стороны «многие» сущность «Договор». Связь проходит через атрибут «№ договора».

          2.2. Логическое проектирование.

          2.2.1. Нормализация отношений.

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

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

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

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

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

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

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

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