В Access [4] агреги-рованным понятиям соответствуют Таблицы, бинарным отношениям ,…, — запросы, реализующие отношения (связи) между Таблицами. Рассмотрим понятие Клиент:
Имя — Клиент: — =={ (Иванов, 42, А3, 3, 10%, 1000, Увеличить нагрузку,(Москва, 499, a@b)}, — ={ ФИО, Возраст, Комплекс, Посещаемость, Скидки, Цена, Пожелания, Реквизиты (Адрес, Телефон, Почта)} - part-off иерархия для понятия Клиент. Загрузка тренажеров: — =={ (а1, в1, 1000 }, — ={ Тренажер, Комплекс, Цена} - part-off иерархия для понятия Загрузка тренажеров. Таким образом представляются все понятия, полученные на этапе анализа требований к ИС. Концептуальнаямодель.
ПОявляетсярезультатомобработки информации, полученнойна стадии анализа требований и предпроектногообследования конкретной системы (реально функционирующей). Понятия КМ ПО мы можем разбить на несколько классов: по сложности — простые: Интенсионал не содержит агрегаций (Дата, Цена, Количество, …), только is-aиерархии; сложные: Интенсионал содержит агрегации Адрес (Город, Улица, дом), …. По функциональности: Объекты ПО (Объекта управления Системы), Процессы в ПО (преобразование ситуации на Объекте управления Системы — всегда сложные понятия), по зависимостям: НДС=Стоимость*18% и т. д. В результате мы получили следующие понятия КМ ПО (простые понятия не содержат скобок () и перечислены в агрегациях:
Заказчик={ Имя, Важность, Преференции, Адрес, Почта, Заказы }, Заказы Клиентов={ Заказчик, количество, Сумма, Частота заказов}.На этапе анализа требований к ИС выделяется входная, выходная (для пользователей системы), справочная информация, ее структура и требуемые алгоритмы обработки в виде системы понятий КМ ПО, информация о которых (Экстенсионалы) необходима ЛПР. После создания концептуальной модели ПО необходимо отобразить ее на логическую модель хранимых данныхна реляционную модель БД. В общем случае под реляционной моделью БД понимается множество отношений (таблиц) R1, R2,…, Rn, связей между ними: один-к-одному, один-ко-многим, многие-ко-многим, и множество операций реляционной алгебры [1,2], все отношения должны находится, как минимум в 3-ей нормальной форме. RiA1A2…An — декартово произведение, где Ai — атрибуты (домены, поля) отношения Ri, им соответствуют имена понятий и их агрегации КМ ПО, если n-ка (ai, a2,…, an) Ri ее называют кортежем (записью) Ri. Aj называется ключевым атрибутом, если все его значения в Ri различны и однозначно определяют каждый кортеж. Приведение R1, R2,…, Rn к нормальной форме называется процедурой нормализации, которая определяет отображение КМ ПОна логическую модель БД. Отношение Ri находится в первой нормальной форме, если все ее атрибуты простые (не имеют внутренней логической структуры, не агрегированы).Отношение Ri находится во второй нормальной форме, если оно удовлетворяет требованиям 1НФ и все ее не ключевые атрибуты однозначно определяются ключевым. Отношение Ri находится в третьей нормальной форме, если оно удовлетворяет требованиям 2НФ и между всеми не ключевыми атрибутами отсутствуют транзитивные (функциональные зависимости).
2.Логическая модель данных. Под логической моделью данных понимается описание общей структуры хранимых данных на языке описания данных конкретной СУБД (defactoSQL) и набор операций, заданный над этой структурой, включая критерии целостности БД: таблицы — описание сложных понятий КМ ПО с помощью агрегаций, процедуры нормализации и примеров понятий (типы данных), связи между таблицами — Схема данных, понятия-процессы — запросы, интерфейс с пользователем — формы, отчеты, возможны описания вспомогательных функций: макросы, экспорт-импорт и т. д.
2.1. Таблицы. Схема данных. Итак мы построили КМ ПО. Сопоставим каждому агрегированному понятию таблицу БД с учетом процедуры нормализации[ 1 ]: Понятия Таблицы БД после нормализации.
ЗаказыЗаказы, Стоимость=Цена*Количество*%Скидки.
ЗаказчикКлиент, Реквизиты.
Заказы Клиентов Заказы Клиентов. С учетом требований нормализации структура и примеры таблиц приведены на Рис.
3. Рис. 3. Структура таблиц и схема данных.
2.2. Формы, запросы, отчеты. Для ввода (или быстрого просмотра) информации в БД в привычном для пользователя виде используются Формы, пример приведен на Рис. 4. Для ввода (или быстрого просмотра) информации в БД в привычном для пользователя виде используются Формы, пример приведен на Рис. 4.
3.Физическая модель. На этапе физического проектирования принимаются решения о физическом размещении БД [ 1,7 ], в том числе строится модель распределенных БД. В работе была выбрана концепция локального размещения ИС. Каждый пользователь имеет санкционированный доступ к единой БД со своего рабочего места.
Заключение
.
В рамках выполненной работы была построена ИС на базе MSAccess, были разработаны:
таблицы и схема БД, — формы для ввода информации в систему, — отчеты и запросы для отображения информации в удобном и привычном для пользователя виде. Система может быть интегрирована в любую информационную систему управления на основе реляционных баз данных.
СПИСОК ЛИТЕРАТУРЫ
Голицина О.Л., Максимов Н. В., Попов И. И. Базы данных. — М.: Издательство: Форум: ИНФРА-М, 2005. — 352 с.Дейт.
К.Дж.
Введение
в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с. Елиферов В. Г., В. В. Репин. Бизнес-процессы. Регламентация и управление.
М.:ИНФРА-М, 2009.
Бекаревич, Ю. Б. Самоучитель Access 2010 / Ю. Б. Бекаревич, Н.
В. Пушкина. — СПб.: Издательство БХВ-Петербург, 2011. — 432 с.
Месарович М., Мако Д., Такахара И. Теория многоуровневых иерархических систем. Издательство: Мир, М.: 1973. — 344 с. Поспелов Д. А. Ситуационное управление: теория и практика.
Издательство: Наука, 1986. — 288 с. Советов Б. Я., Водяхо А. И., Дубенецкий В. А., Цехановский В.
В. Архитектура информационных систем. Издательство — Academia, год издания — 2012, с. 288, ISBN: 9 785 769 588 273.
Фаулер М., Райс Д., Фоммел М., Хайет Э., Ми Р. Шаблоны корпоративных приложений: пер. с англ. М.: Вильямс, 2014, 543 с. Хоп Г., Б. Вульф. Шаблоны интеграции корпоративных приложений. Издательство: Вильямс, 2007.
— 672 с. Стандарты и другие документы1. ГОСТ 34.
601. Информационная технология. Комплекс стандартов наавтоматизированные системы. Автоматизированные системы. Стадии создания.
2. ГОСТ Р ИНСО 15 704−2008.
Промышленные автоматизированныесистемы. Требования к стандартным архитектурам и методологиямпредприятия. Электронный ресурс:
http://protect.gost.ru/document.aspx?control=7&id=1 753 813. ГОСТ 34.003−90 Информационная технология. Комплекс стандартовна автоматизированные системы. Автоматизированные системы. Термины и определения;
4. ГОСТ 34.602−89 Информационная технология. Комплекс стандартовна автоматизированные системы. Техническое задание на созданиеавтоматизированной системы;
6. ISO 15 704:
2000. Industrial automation systems — Requirements forenterprise-reference architectures and methodologies.
7. ISO 35.
100. «Open systems interconnection»;8. ISO-15 704, Industrial automation systems — Requirements for enterprisereferencearchitectures and methodologies. August 20, 1999;9. FEA Consolidated Reference Model Document, May 2005; IEEERecommended Practice for Architectural Description, Draft 3.0 of IEEEP1471, May 1998;10.OMG Unified Modeling Language (UML) Specification, March 2003Version 1.
5.11. Глоссарий Фонда поддержки системного проектирования, стандартизации и управления проектами (ФОСТАС ;
http://www.fostas.ru).
