2.3. Инфологическое моделирование предметной области
Инфологическая модель базы данных представляет собой описание объектов (сущностей), с набором атрибутов и связей между ними, которые выявляются в процессе исследования как входных, так и выходных данных. Она предназначается для структурного образования предметной области, с ориентированием на информационное внимание пользователей, разрабатываемой системы. Так же инфологическая модель должна быть как стабильной, так и неизменной, и являться представлением аспекта пользователя на описанную раннее предметную область. Однако, при проектировании инфологической модели, должна присутствовать возможность для её увеличения и вставки вспомогательных данных.
Самая распространенная модель в инфологическом моделировании это модель "сущность-связь", к главным компонентам её относятся - сущности и связи. Под понятием сущности трактуется содержание объекта, о котором набирают необходимую информацию. Экземпляром сущности представляется - чёткий объект. Сущность определяется атрибутами, которые в свою очередь описаны определёнными характеристиками. Связи должны показывать определённые отношения между сущностями. Во время построения инфологической модели чаще используют графические схемы.
Рис.2.1. Инфологическая модель
Модель включает сущности:
Магазин. Атрибутами сущности являются – Наименование, Адрес, Номер Телефона.
Товар. Атрибуты – Наименование, Единица измерения.
Поставщик. Атрибутам – Наименование, Адрес, Номер Телефона, Банковские реквизиты.
Товарная группа необходима для оценки результатов экономической деятельности по группам в целом. Примерами товарных групп могут быть – Хлеб и Хлебобулочные изделия, Рыбопродукты и т.д. Имеет один атрибут – Наименование.
Агрегированный объект – Поставка. Атрибут – Дата поставки.
Между выделенными сущностями можно выделить следующие связи:
«Товар» находится в «товарной группе»;
Агрегированный объект «Поставка» содержит в себе объекты «Поставщик», «Магазин», а также сам поставляемый «Товар».
Разработка логической структуры базы данных
В ходе рассмотрения бизнес – процессов было принято решение разработать АРМ для экономиста, ведущего учёт экономических показателей, выполняющего следующие функции:
ввод и редактирование данных о товарах предприятия;
ввод и редактирование данных о поставках;
ввод и редактирование данных о поставщиках и магазинах;
хранение форм первичных документов;
просмотр данных;
формирование статистических отчётов.
Ранее в дипломе были выделены сущности Товар, Магазин, Поставщик, Поставка, Товарная группа. В базе данных будут созданы данные таблицы с такими же наименованиями. С определенными связями. Также необходимо создать справочную информацию по первичным документам, реквизиты которых понадобятся для дальнейшей обработки информации. Такими таблицами будут Данные Товарных накладных, Данные Товарных отчётов, Данные Справок о товарах.
Сейчас определим взаимосвязи между сущностями. Они наглядно представлены в таблице 2.1.
Таблица 2.1.
Связи между сущностями
Вид связи |
Сущность |
Сущность |
1:М |
Поставщик |
Поставка |
1:М |
Товар |
Поставка |
1:М |
Магазин |
Поставка |
1:1 |
Данные Товарных Накладных |
Поставка |
1:М |
Товарная группа |
Товар |
А теперь перейдём к атрибутам. Необходимо выделить атрибут или набор атрибутов, которые могли бы однозначно определить экземпляр сущности (потенциальные ключи). Так, для сущности Товары потенциальным ключом является атрибут Наименование. Но данный атрибут является строковым, и использовать его в качестве первичного ключа было бы нерационально. Поэтому введем дополнительный атрибут Код_товара, который присваивался бы экземпляру сущности Товары при внесении его в БД и не менялся за все время существования данной записи в БД.
Для однозначной идентификации экземпляра сущности Поставка введем атрибут Код_Поставки, для сущности Магазин Код_магазина, для сущности Поставщик Код_поставщика, для сущности Накладная № Накладной, для сущности Товарная группа – Код_товарной группы Также введем внешние ключи для связи сущностей: атрибуты Код_поставщика, Код_магазина и Код_товара в сущности Поставка.
Далее необходимо внести не ключевые атрибуты.
Таким образом, мы получили 7 отношений:
Товар (Код товара, Наименование, Единица измерения);
Магазин (Код магазина, Наименование, Адрес, Номер телефона);
Поставщик (Код поставщика, Наименование, Адрес, Номер телефона, Банковские реквизиты);
Поставки (Код поставки, Код_поставщика, Код_товара, Код_магазина, Количество, Дата поставки, Текущая цена);
Товарная группа (Код_товарной группы, Наименование);
Накладная (№ накладной, Дата составления);
Товарный отчет (№ документа, Код_магазина, Дата составления, Остаток на приход, Итого по приходу, Расход, Итого по расходу, Остаток).
Справка по товарам (№ документа, Код_магазина, Дата составления, Товарные группы, Розница, Остаток).
Далее проводится приведение модели к требуемому уровню нормальной формы. Соответствие модели какой-либо нормальной форме показывает, насколько оптимально спроектирована модель.
Первая нормальная форма
Схема отношения находится в первой нормальной форме (1НФ), если значения каждого атрибута отношения являются атомарными. Как можно заметить, все атрибуты всех отношений являются атомарными. Таким образом, схема БД находится в 1НФ. Такой атрибут как Ф.И.О. сотрудника в данной ИС рассматривается как атомарный, т.к. не предполагается запрашивать отдельные его составляющие.
Вторая нормальная форма
Схема отношения находится во второй нормальной форме (2НФ) тогда и только тогда, когда отношение находится в 1НФ и нет неключевых атрибутов, зависящих от части сложного ключа. В нашем случае все схемы отношений удовлетворяют данному условию, т.е. схема БД находится в 2НФ.
Третья нормальная форма
Отношение находится в третьей нормальной форме (3НФ) тогда и только тогда, когда отношение находится в 2НФ и все неключевые атрибуты взаимно независимы. Атрибуты называются взаимно независимыми, если ни один из них не является функционально зависимым от другого.
В итоге мы получим примерную схему будущей базы данных рисунок 2.2.
Рис. 2.2. Схема данных
Последнее, что производится – это физическое описание модели в соответствии с выбранной системой управления базами данных (СУБД). Мы будем опираться на СУБД Access. Физическое описание модели удобнее всего представить в виде таблиц. База данных будет содержать следующие таблицы.
Таблица 2.2.
Структура таблицы «Товар»
№ п/п |
Название поля |
Тип данных |
Свойства поля |
Описание |
1. |
Код_товара |
Числовой |
Размер поля - Целое, Ключевое, Индексированное (Совпадения не допускаются) |
Уникальный код товара |
2. |
Наименование |
Текстовый |
Размер поля – 50, Индексированное (Совпадения допускаются), Обязательное |
Название товара |
|
|
Единица измерения |
Текстовый |
Размер поля – 10, Индексированное (Совпадения допускаются), Обязательное |
В каких единицах измеряется |
|
|
Товарная группа |
Текстовый |
Размер поля – 50, Индексированное (Совпадения допускаются) |
К какой товарной группе относится товар |
Таблица 2.3.
Структура таблицы «Поставщик»
№ п/п |
Название поля |
Тип данных |
Свойства поля |
Описание |
1. |
Код_поставщика |
Числовой |
Размер поля - Целое, Ключевое, Индексированное (Совпадения не допускаются) |
Уникальный код поставщика |
2. |
Наименование |
Текстовый |
Размер поля – 50, Индексированное (Совпадения не допускаются), Обязательное |
Наименование поставщика |
3. |
Адрес |
Поле МЕМО |
Индексированное (Совпадения не допускаются) |
Контактная информация |
4. |
Номер телефона |
Поле МЕМО |
Индексированное поле (Совпадения не допускаются) |
Контактная информация |
5. |
Банковские реквизиты |
Поле МЕМО |
Индексированное (Совпадения не допускаются) |
|
Таблица 2.4.
Структура таблицы «Магазин»
№ п/п |
Название поля |
Тип данных |
Свойства поля |
Описание |
1. |
Код_магазина |
Числовой |
Размер поля - Целое, Ключевое, Индексированное (Совпадения не допускаются) |
Уникальный код магазина |
2. |
Наименование |
Текстовый |
Размер поля – 50, Индексированное (Совпадения не допускаются), Обязательное |
Наименование магазина |
3. |
Адрес |
Поле МЕМО |
Индексированное (Совпадения не допускаются) |
Контактная информация |
4. |
Номер телефона |
Числовой |
Размер поля – Целое, Индексированное поле (Совпадения не допуск.) |
Контактная информация |
Таблица 2.5.
Структура таблица «Накладная»
№ п/п |
Название поля |
Тип данных |
Свойства поля |
Описание |
1. |
№ накладной |
Числовой |
Размер поля - Целое, Ключевое, Индексированное (Совпадения не допускаются) |
Уникальный код документа |
2. |
Дата составления |
Дата/время |
Формат поля – краткий формат даты, Индексированное (Совпадения допускаются), Обязательное |
Дата составления |
Таблица 2.6.
Структура таблицы «Поставка»
№ п/п |
Название поля |
Тип данных |
Свойства поля |
Описание |
1. |
Код_поставки |
Числовой |
Размер поля - Целое, Ключевое, Индексированное (Совпадения не допускаются) |
Уникальный код поставки |
2. |
Код_поставщика |
Числовой |
Размер поля - Целое, Внешний Ключ, Индексированное (Совпадения не допускаются) |
Уникальный код поставщика |
3. |
Код_товара |
Числовой |
Размер поля - Целое, Внешний Ключ, Индексированное (Совпадения не допускаются) |
Уникальный код товара |
4. |
Код_магазина |
Числовой |
Размер поля - Целое, Внешний Ключ, Индексированное (Совпадения не допускаются) |
Уникальный код магазина |
5. |
Количество |
Числовой |
Размер поля – Действительное, Индексированное (Совпадения допускаются), Обязательное |
Количество поставленного товара |
6. |
Дата поставки |
Дата/время |
Формат поля – краткий формат даты, Индексированное (Совпадения допускаются), Обязательное |
Дата поставки товара |
7. |
Текущая цена |
Денежный |
Формат поля – Денежный, Индексированное поле (Совпадения допускаются), Обязательное |
Цена, установленная на момент поставки. Она может варьироваться со временем. |
Таблица 2.7.
Структура таблицы «Товарный отчет»
№ п/п |
Название поля |
Тип данных |
Свойства поля |
Описание |
1. |
№ документа |
Числовой |
Размер поля - Целое, Ключевое, Индексированное (Совпадения не допускаются) |
Уникальный код документа |
2. |
Код_магазина |
Числовой |
Размер поля - Целое, Внешний Ключ, Индексированное (Совпадения не допускаются) |
Уникальный код магазина |
3. |
Дата составления |
Дата/время |
Формат поля – краткий формат даты, Индексированное (Совпадения допускаются), Обязательное |
Дата составления Товарного отчёта |
4. |
Остаток на приход |
Денежный |
Формат поля – Денежный, Индексированное поле (Совпадения допускаются), Обязательное |
Остаток на приход |
|
|
Итого по приходу |
Денежный |
Формат поля – Денежный, Индексированное поле (Совпадения допускаются), Обязательное |
Итого по приходу товара |
|
|
Расход |
Денежный |
Формат поля – Денежный, Индексированное поле (Совпадения допускаются), Обязательное |
Расход товара |
|
|
Итого по расходу |
Денежный |
Формат поля – Денежный, Индексированное поле (Совпадения допускаются), Обязательное |
Итого расходованного товара |
|
|
Остаток |
Денежный |
Формат поля – Денежный, Индексированное поле (Совпадения допускаются), Обязательное |
Остаток товара в денежном измерении |
Таблица 2.8.
Структура таблицы «Справка по товару»
№ п/п |
Название поля |
Тип данных |
Свойства поля |
Описание |
1. |
№ документа |
Числовой |
Размер поля - Целое, Ключевое, Индексированное (Совпадения не допускаются) |
Уникальный код документа |
2. |
Код_магазина |
Числовой |
Размер поля - Целое, Внешний Ключ, Индексированное (Совпадения не допускаются) |
Уникальный код магазина |
3. |
Дата составления |
Дата/время |
Формат поля – краткий формат даты, Индексированное (Совпадения допускаются), Обязательное |
Дата составления Товарного отчёта |
4. |
Товарные группы |
Текстовый |
Размер поля - 50, Индексированное поле (Совпадения не допускаются), Обязательное |
Группа, к которой относится товар,н-р, Морепродукты |
|
|
Розница |
Денежный |
Формат поля – Денежный, Индексированное поле (Совпадения допускаются), Обязательное |
Сумма по каждой товарной группе |
|
|
Остаток |
Денежный |
Формат поля – Денежный, Индексированное поле (Совпадения допускаются), Обязательное |
Сумма остатка товаров в магазине |
РАЗРАБОТКА ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА
Проектирование иерархического меню
Структура программной системы обработки экономических показателей согласно построенным моделям данных в среде MS Access представляет собой «кнопочную» форму (главное «меню») со следующей программной иерархией:
Меню АРМ
Экономиста ФЭО
Выход
Отчёты
Запросы
Формы ввода/просмотра/редактирования
Сервисные
процедуры
Формы №3, 7- Торги
Товар
Отчёты
Поставщик
Данные
Справок о тов.
Данные
Тов.отчётов
Данные
накладных
Магазин
Рис. 2.3. Иерархическое меню АРМ экономиста финансово-экономического отдела
Проектирование экранных форм для ввода и просмотра данных
Экранные формы в настоящее время образуют основу интерфейса в человеко-машинном диалоге.
Порядок проектирования экранной формы подразумевает следующие этапы:
Проектирование содержание экранной формы;
Проектирование её формы представления (формы экрана);
Программное обеспечение экранной формы.
Содержание экранной формы зависит от её назначения. По назначению можно выделить 4 класса экранных форм:
Для ввода информации в базу данных, т.е. для формирования и ведения базы данных; различают экранные формы для ввода справочной информации на этапе конфигурирования информационной системы (базовые формы) и экранные формы для ввода переменной информации;
Для ввода параметров обработки информации по задаче и идентификаторов запросов (условия выборки);
Для ввода результатов решения задачи и справочной информации;
Комбинированные экранные формы, предусматривающие многоцелевое назначение;
Проектирование сценария диалогового режима решения задачи состоит в разработке взаимосвязанной последовательности экранных форм и правил перехода между ними.
Содержание экранных форм должно отвечать принципу «дружественности»: обозначения реквизитов должны быть представлены на русском языке в соответствии с привычной для пользователя терминологией, процесс ввода информации должен сопровождаться подсказками и контролем. Следует обратить особое внимание на контроль правильности вводимой информации, поскольку основная доля ошибок происходит по вине пользователя, а не машины.
Универсальным методом контроля является визуальный контроль. Контроль количественных реквизитов может состоять в проверке соответствия области допустимых значений. Контроль количественных реквизитов может состоять в проверке на соответствие области допустимых значений. Контроль реквизитов можно осуществлять путём проверки на соответствие разрешенным значениям.
Повышение достоверности при вводе реквизитов-признаков может быть достигнуто за счёт того, что они не вводятся с клавиатуры, а выбираются из предложенного на экране списка.
Используются также методы контрольных сумм, верификации, формальный и логический контроль. Примерный эскиз экранной формы выглядит следующим образом в среде MS Access.
Рис.
2.4. «Поставщик»
Имеются кнопки «Следующая запись», «Предыдущая запись», «Сохранить», «Удалить» для манёвренности. Таких форм будет ровно столько, сколько таблиц в БД. Т.е. формы - «Товар», «Товарная группа», «Магазин», «Поставщик», «Поставки», «Товарный отчёт», «Накладная», «Справка по товарам».