- •Разработка программного обеспечения автоматизированной информационной системы учета продажи канцелярских товаров в оптово-розничном магазине
- •Содержание
- •Введение
- •1 Постановка задачи
- •1.1 Описание и анализ бизнес-процесса
- •1.2 Описание задачи
- •1.3 Описание исходной (входной) информации
- •1.4 Описание результатной (выходной) информации
- •1.5 Разработка информационной модели данных
- •1.5.1 Определение сущностей
- •1.5.2 Определение взаимосвязей между сущностями
- •1.5.3 Определение отношений первой нормальной формы
- •1.5.4 Определение отношений второй нормальной формы
- •1.5.5 Определение отношений третьей нормальной формы
- •1.5.6 Определение структуры базы данных
- •1.6 Описание алгоритма решения задачи
- •1.6.1 Описание пользовательского интерфейса
- •1.6.2 Выбор и обоснование языка программирования
- •2 Программная документация на изделие
- •2.1 Описание программы
- •2.2 Руководство пользователя
- •2.2.4 Сообщения пользователю
- •3 Экспериментальное исследование программного изделия
- •4 Экономическое обоснование дипломного проекта
- •4.1 Группировка затрат по статьям калькуляции
- •4.3 Расчет заработной платы
- •4.3.1 Дополнительная заработная плата
- •4.3.2 Отчисления на социальные нужды
- •4.4 Расходы на содержание и эксплуатацию техники
- •Полная себестоимость
- •4.5 Расчет прибыли
- •4.6 Определение оптовой цены программного продукта
- •4.7 Обоснование инвестиций и расчеты эффективности проекта
- •5 Эргономичность проекта
- •5.1 Анализ и оценка состояния разработки дипломного проекта с точки зрения эргономичности
- •5.1.1 Качество разработки интерфейса
- •5.1.2 Простота освоения и запоминания операций системы
- •5.1.3 Быстрота достижения целей задачи
- •5.1.4 Субъективная удовлетворенность при эксплуатации системы
- •5.2 Оптимизация зрительных условий труда на рабочем месте
- •Заключение
- •Библиографический список
1.5 Разработка информационной модели данных
Для определения структуры каждой таблицы необходимо выполнить анализ функциональных зависимостей. В результате количество необходимых таблиц определяется числом функциональных зависимостей. Формально нормализация данных обеспечена, если набор таблиц удовлетворяет первым трем правилам, которые называются нормальными формами. Для приведения модели базы данных к требуемому уровню нормальной формы, а это является основой построения реляционной базы данных, процесс проектирования должен пройти несколько этапов.
1.5.1 Определение сущностей
Исходя из задачи, выделим следующие сущности:
товары;
поставщики;
клиенты.
1.5.2 Определение взаимосвязей между сущностями
Определим взаимосвязи между сущностями согласно требованиям к базе данных. В соответствии с этим диаграмма «сущность-связь» будет выглядеть следующим образом:
Рисунок 20 – Схема взаимосвязей между сущностями
1.5.3 Определение отношений первой нормальной формы
Следует иметь в виду, что чрезмерное увеличение количества таблиц приводит к потере общей идеи создания базы данных, и сама база данных становится трудной для восприятия. В среде реляционных баз данных такие проблемы можно разрешить достаточно легко. Для этого надо произвести нормализацию базы данных.
Применим к сущностям условия первой нормально формы:
должны отсутствовать повторяющиеся записи;
должны отсутствовать повторяющиеся атрибуты;
каждый атрибут (поле) должен быть неделимым.
Для каждой сущности определим атрибуты, которые будут храниться в базе данных (таблица 1).
Таблица 1 – Определение атрибутов сущностей
Сущность |
Атрибут |
Товары |
Уникальный ключ товара |
Группа товара |
|
Серия товара |
|
Наименование товара |
|
Количество в наличии |
|
Цена товара на продажу |
|
Цена покупки |
|
Дата покупки |
|
Дата продажи |
|
Количество покупки |
|
Количество продажи |
|
Сумма покупки |
|
Сумма продажи |
|
Поставщики |
Уникальный ключ поставщика |
Наименование |
|
Адрес |
|
Телефон |
|
Клиенты |
Уникальный ключ клиента |
ФИО представителя |
|
Адрес |
|
Телефон |
|
Фирма |
1.5.4 Определение отношений второй нормальной формы
Отношение находится во второй нормальной форме, если оно удовлетворяет следующим условиям:
выполняются условия первой нормальной формы;
первичный ключ однозначно определяет всю запись;
все поля записи зависят от первичного ключа;
первичный ключ имеет минимальную форму (отсутствует избыточность).
Анализируя первую нормальную форму, видим, что в сущности «Товар» первичный ключ «Уникальный ключ товара» однозначно не определяет записи в этой будущей таблице, т.к. от него не зависят атрибуты «Серия товара», «Группа товара», «Дата покупки», «Дата продажи». Исходя из этого, необходимо видоизменить список атрибутов сущности «Товары» и добавить новые сущности «Серия», «Группа», «Покупка» и «Продажа».
Также, чтобы получить вторую нормальную форму, необходимо разорвать связи «многие-ко-многим» между сущностями «Товар» и «Поставщик», а также «Товар» и «Клиент». Для этого добавим таблицы «Покупка» «Продажа».
В соответствии с вышесказанным, приведем таблицу отношений сущностей и их атрибутов во второй нормальной форме (таблица 2).
Таблица 2 – Определение второй нормальной формы
Сущность |
Первичный ключ |
Атрибуты |
Товары |
Уникальный ключ товара |
Уникальный ключ товара |
Уникальный ключ группы товара |
||
Уникальный ключ серии товара |
||
Наименование товара |
||
Количество в наличии |
||
Цена товара на продажу |
||
Описание |
||
Поставщики |
Уникальный ключ поставщика |
Уникальный ключ поставщика |
Наименование поставщика |
||
Адрес |
||
Телефон |
||
Серия |
Уникальный ключ серии |
Уникальный ключ серии |
Наименование серии |
||
Группа |
Уникальный ключ группы |
Уникальный ключ группы |
Наименование группы |
||
Покупка |
Уникальный ключ покупки |
Уникальный ключ покупки |
Дата покупки |
||
Уникальный ключ поставщика |
||
Уникальный ключ товара |
||
Количество покупки |
||
Цена покупки |
||
Сумма покупки |
||
Клиенты |
Уникальный ключ клиента |
Уникальный ключ клиента |
ФИО представителя |
||
Адрес |
||
Телефон |
||
Фирма |
||
Продажа |
Уникальный ключ продажи |
Уникальный ключ продажи |
Дата продажи |
||
Уникальный ключ клиента |
||
Уникальный ключ товара |
||
Количество продажи |
||
Сумма продажи |
Приведем диаграмму взаимосвязей между атрибутами сущностей во второй нормальной форме (рисунок 21):
Рисунок 21 – Информационная модель базы данных во второй нормальной форме