ИНФОЛОГИЧЕСКОЕ МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

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

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

Рис.2.1. Инфологическая модель

Модель включает сущности:

• Магазин. Атрибутами сущности являются – Наименование, Адрес, Номер Телефона.

• Товар. Атрибуты – Наименование, Единица измерения.

• Поставщик. Атрибутам – Наименование, Адрес, Номер Телефона, Банковские реквизиты.

• Товарная группа необходима для оценки результатов экономической деятельности по группам в целом. Примерами товарных групп могут быть – Хлеб и Хлебобулочные изделия, Рыбопродукты и т.д. Имеет один атрибут – Наименование.

Агрегированный объект – Поставка. Атрибут – Дата поставки.

Между выделенными сущностями можно выделить следующие связи:

• «Товар» находится в «товарной группе»;

• Агрегированный объект «Поставка» содержит в себе объекты «Поставщик», «Магазин», а также сам поставляемый «Товар».

• РАЗРАБОТКА ЛОГИЧЕСКОЙ СТРУКТУРЫ БАЗЫ ДАННЫХ

В ходе рассмотрения бизнес – процессов было принято решение разработать АРМ для экономиста, ведущего учёт экономических показателей, выполняющего следующие функции:

• ввод и редактирование данных о товарах предприятия;

• ввод и редактирование данных о поставках;

• ввод и редактирование данных о поставщиках и магазинах;

• хранение форм первичных документов;

• просмотр данных;

• формирование статистических отчётов.

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

Сейчас определим взаимосвязи между сущностями. Они наглядно представлены в таблице 2.1.

Таблица 2.1.

Связи между сущностями

А теперь перейдём к атрибутам. Необходимо выделить атрибут или набор атрибутов, которые могли бы однозначно определить экземпляр сущности (потенциальные ключи). Так, для сущности Товары потенциальным ключом является атрибут Наименование. Но данный атрибут является строковым, и использовать его в качестве первичного ключа было бы нерационально. Поэтому введем дополнительный атрибут Код_товара, который присваивался бы экземпляру сущности Товары при внесении его в БД и не менялся за все время существования данной записи в БД.

Для однозначной идентификации экземпляра сущности Поставка введем атрибут Код_Поставки, для сущности Магазин Код_магазина, для сущности Поставщик Код_поставщика, для сущности Накладная № Накладной, для сущности Товарная группа – Код_товарной группы Также введем внешние ключи для связи сущностей: атрибуты Код_поставщика, Код_магазина и Код_товара в сущности Поставка.

Далее необходимо внести не ключевые атрибуты.

Таким образом, мы получили 7 отношений:

• Товар (Код товара, Наименование, Единица измерения);

• Магазин (Код магазина, Наименование, Адрес, Номер телефона);

• Поставщик (Код поставщика, Наименование, Адрес, Номер телефона, Банковские реквизиты);

• Поставки (Код поставки, Код_поставщика, Код_товара, Код_магазина, Количество, Дата поставки, Текущая цена);

• Товарная группа (Код_товарной группы, Наименование);

• Накладная (№ накладной, Дата составления);

• Товарный отчет (№ документа, Код_магазина, Дата составления, Остаток на приход, Итого по приходу, Расход, Итого по расходу, Остаток).

• Справка по товарам (№ документа, Код_магазина, Дата составления, Товарные группы, Розница, Остаток).

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

Первая нормальная форма

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

Вторая нормальная форма

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

Третья нормальная форма

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

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

Рис. 2.2. Схема данных

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

Таблица 2.2.

Структура таблицы «Товар»

Таблица 2.3.

Структура таблицы «Поставщик»

Таблица 2.4.

Структура таблицы «Магазин»

Таблица 2.5.

Структура таблица «Накладная»

Таблица 2.6.

Структура таблицы «Поставка»

Таблица 2.7.

Структура таблицы «Товарный отчет»

Таблица 2.8.

Структура таблицы «Справка по товару»

• РАЗРАБОТКА ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

Проектирование иерархического меню

Структура программной системы обработки экономических показателей согласно построенным моделям данных в среде MS Access представляет собой «кнопочную» форму (главное «меню») со следующей программной иерархией:

Меню АРМ

Экономиста ФЭО

Выход

Отчёты

Запросы

Формы ввода/просмотра/редактирования

Сервисные

процедуры

Формы №3, 7- Торги

Товар

Отчёты

Поставщик

Данные

Справок о тов.

Данные

Тов.отчётов

Данные

накладных

Магазин

Рис. 2.3. Иерархическое меню АРМ экономиста финансово-экономического отдела

Проектирование экранных форм для ввода и просмотра данных

Экранные формы в настоящее время образуют основу интерфейса в человеко-машинном диалоге.

Порядок проектирования экранной формы подразумевает следующие этапы:

• Проектирование содержание экранной формы;

• Проектирование её формы представления (формы экрана);

• Программное обеспечение экранной формы.

Содержание экранной формы зависит от её назначения. По назначению можно выделить 4 класса экранных форм:

• Для ввода информации в базу данных, т.е. для формирования и ведения базы данных; различают экранные формы для ввода справочной информации на этапе конфигурирования информационной системы (базовые формы) и экранные формы для ввода переменной информации;

• Для ввода параметров обработки информации по задаче и идентификаторов запросов (условия выборки);

• Для ввода результатов решения задачи и справочной информации;

• Комбинированные экранные формы, предусматривающие многоцелевое назначение;

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

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

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

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

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

Рис. 2.4. «Поставщик»

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

• РАЗРАБОТКА ОСНОВНЫХ ВЫХОДНЫХ ДОКУМЕНТОВ (ОТЧЕТОВ)

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

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

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

Результаты проектирования отчёта представляются в виде таблицы 2.9.

Таблица 2.9.

Реквизитный состав формы отчёта «Форма № 3-Торг»

ЗАКЛЮЧЕНИЕ

Итогом выполненной работы является АРМ экономиста – статиста по учету экономических показателей производственной деятельности РАЙПО. Система полностью отвечает требованиям, сформулированным при постановке задачи. Это означает, что специфическая цель, поставленная в рамках данной работы, достигнута.

В ходе разработки АРМ были осуществлены следующие работы:

• сформулированы основные задачи, которые необходимо автоматизировать;

• обоснован выбор программного, технологического и информационного обеспечения и технологии проектирования;

• разработаны проектные решения по информационному, программному, техническому и технологическому обеспечению комплекса задач;

• представлены основные схемы документооборота, технологии обработки информации;

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

• разработаны входные и выходные экранные и печатные формы;

• обоснована методика и выполнен расчет показателей экономической эффективности от внедрения АРМ экономиста, а также обоснована целесообразность внедрения данного проекта.

Внедрение АРМ позволит существенно сократить затраты квалифицированного труда на подготовку отчётных документов. Срок окупаемости затрат на разработку и внедрение проекта составляет ориентировочно 1 год.

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

• Автоматизированные информационные технологии в экономике: Учебник/ Под ред. Г.А.Титоренко. – М.: ЮНИТИ, 2007, 400 с.;

• Базы данных. Проектирование и реализация: Практикум по курсу / Московский государственный университет экономики, статистики и информатики, Назаров В.В. – М., 2007. – 21 c.;

• Основы проектирования информационных систем: Учебное пособие/Под ред. Золотов С.Ю. – Томск, ТУСУР, 2007. – 96 с.;

• Базы данных: проектирование и использование: Учебник/Под ред. Диго С.М. - М.:Финансы и статистика, 2008. - 592 с: ил. ISBN 5-279-02571-2;

• Проектирование программного обеспечения экономических

информационных систем: Учебник /Под ред. Вендров А.М. — 2-е изд., перераб. и доп. — М.: Финансы и статистика, 2007.— 544 с.;

• Разработка баз данных в системе Microsoft Access: учебник /

В.М.Демин, А.В. Кузин. – М.: Гриф, 2009. — 224 с.;

• Устав Цивильского Районного Потребительского Сообщества, 2009 г.;

• Должностные инструкции экономиста РАЙПО;

• Базы данных. Учебное пособие/ Швецов В.И., Визгунов А.Н., Мееров

И.Б.. Нижний Новгород: Изд-во ННГУ, 2007. 217 с.;

• Реинжиниринг бизнес-процессов. Тельнов Ю.Ф. М.: Финансы и

статистика, 2007, – 320 с.;

• Проектирование баз данных: Учебник./ Диго С.М. - М.: Финансы и

статистика, 2008.

Не нашли, что искали? Воспользуйтесь поиском: