IDEF3 хорошо приспособлен для сбора данных, требующихся для проведения анализа системы с точки зрения рассогласования/согласования процессов во времени.
Нельзя говорить о достоинствах и недостатках отдельных нотаций. Возможны ситуации, при которых анализ IDEF0 не обнаружил недостатков в деятельности организации с точки зрения технологического или производственного процесса, однако это не является гарантией отсутствия ошибок. Поэтому в следующем этапе анализа необходимо перейти к исследованию информационных потоков с помощью DFD и затем объединить эти пространства с помощью последней нотации - IDEF3.
Что касается IDEF1X, наряду со многими достоинствами, существенным недостатком является невозможность адекватно и полно описать предметную область. Поэтому, код клиентского приложения, генерируемый в дальнейшем на основе информации о структуре БД, не позволяет построить эффективное приложение со сложной бизнес - логикой. Это вызвано тем, что данные для хранения в БД необходимо представить в таблицах, к структуре которой предъявляются требования нормализации.
Цель моделирования данных - обеспечить разработчика ЭИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые может быть относительно легко отображены в любую систему баз данных.
Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD), нотация которых была впервые введена Питером Ченом в 1976 г. и получила дальнейшее развитие в работах Ричарда Баркера. Различные CASE-средства используют несколько отличающиеся друг от друга нотации ERD. Одна из наиболее распространенных нотаций предложена Баркером (Oracle Designer). В CASE-средстве SilverRun используется один из вариантов нотации Чена. CASE-средства ERwin, ER / Studio, Design / IDEF используют методологию IDEF 1Х. [5]
Диаграммы "сущность-связь" (ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними.
Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).
Эти диаграммные техники используются, прежде всего, для проектирования реляционных баз данных (хотя также могут с успехом применяться и для моделирования иерархических и сетевых баз данных).
Диаграммы "сущность-связь" включают:
сущности;
атрибуты;
связи.
Сущность (Entity) - любой объект, событие или концепция, имеющие существенное значение для предметной области, и информация о которых должна сохраняться.
Каждая сущность является множеством подобных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от остальных.
Атрибут (Attribute) - любая характеристика сущности, значимая для рассматриваемой предметной области. Атрибут предназначен для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности.
Каждая сущность может обладать любым количеством связей с другими сущностями. Связь (Relationship) - поименованное логическое соотношение между двумя сущностями, значимое для рассматриваемой предметной области.
Сущность является независимой, если каждый экземпляр ее может быть однозначно идентифицирован без определения его отношений с другими сущностями. Независимая сущность изображается прямоугольником с четко выраженными углами. Сущность является зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности. Зависимая сущность изображается прямоугольником со скругленными углами.
Первичный ключ (Primary Key) - это атрибут или группа атрибутов, однозначно идентифицирующих экземпляр сущности. На диаграмме первичные ключи размещаются выше горизонтальной линии. Ключ может быть сложным, т.е. состоять из нескольких атрибутов.
Альтернативный ключ (Alternate Key) - потенциальный ключ, не ставший первичным. На диаграмме альтернативный ключ обозначается AK n. m, где n - порядковый номер ключа, m - порядковый номер атрибута в ключе.
Внешние ключи (Foreign Key) создаются автоматически, когда сущности соединяются связью (миграция ключа). Связи между таблицами реляционной БД представляются одинаковыми ключами в таблицах (внешними ключами).
Связи (логические отношения между сущностями) именуются глаголами или глагольными фразами. Имена связей выражают некоторые ограничения или бизнес-правила и облегчают чтение диаграмм.
На логическом уровне можно установить:
идентифицирующую связь один-ко-многим;
неидентифицирующую связь один-ко-многим;
связь многие-ко-многим.
Разработка ERD включает следующие основные этапы:
Идентификация сущностей, их атрибутов, а также первичных и альтернативных ключей.
Идентификация отношений между сущностями и указание типов отношений.
Разрешение неспецифических отношений (отношений многие-ко-многим).
Основной функцией любой СУБД является поддержка независимости, целостности и непротиворечивости данных в условиях коллективного использования. Независимость данных понимается как способность СУБД создавать различные представления об одних и тех же хранимых данных, остающихся инвариантными к изменениям среды функционирования БД [25]. Требуемая степень независимости данных достигается в результате введения внешнего, концептуального и внутреннего уровней определения и манипулирования данными. С внешней точки зрения база данных - это совокупность различных информационных моделей ПО, предназначенных для информационных потребностей пользователей; с концептуальной - база данных есть общая модель ПО, обеспечивающая поддержку различных прикладных систем; с внутренней - база данных рассматривается как физическое представление данных в конкретной среде, используемой для хранения информации. Являясь информационной моделью ПО, база данных обеспечивает коллективное использование информации и необходимые условия для естественной эволюции существующих приложений ИС без их разрушения.
Благодаря концепции БД обеспечивается независимость описания предметной области и задач приложений от структур данных и методов их обработки, программ - от логической структуры базы данных, логической структуры данных - от методов их физической организации.
В информационных системах, использующих БД, можно:
сделать программы ввода, модификации и поиска данных независимыми от программ содержательной обработки приложений;
минимизировать объем хранимых данных путем сокращения их дублирования;
избежать противоречий в хранимых данных;
обеспечить сохранность и целостность информации:
многократно использовать одни и те же данные различными прикладными программами;
обеспечить гибкость и адаптивность структуры данных к изменяющимся информационным потребностям пользователей;
поддерживать адекватность базы данных моделируемой ПО;
обеспечить защиту данных от несанкционированного доступа.
Концепция БД позволяет создавать интегрированные информационные системы, поддерживающие сложные и разнообразные структуры объектов предметной области, содержащие большое число типов данных, значительные объемы фактографической или текстовой информации, а также сделать реальной задачу обеспечения высокой достоверности обработки и хранения больших объемов данных. [6]
Функционирование организации по продаже канцелярских товаров: ООО "КТ" осуществляет продажу канцелярских товаров. Хранится следующая информация о предприятиях-клиентах: название, юридический адрес, телефон, руководитель, главный бухгалтер. Клиентами являются магазины, частные предприятия, кафе, туристические фирмы. Менеджер оформляет заказ, в котором указано наименование заказчика, дата заказа, наименование товара, количество товара, а так же отметки о выполнении\не выполнении заказа, и о выполнении\не выполнении оплаты заказчиком. Заключается двусторонний договор. После выполнения заказа составляется отчет в разрезе клиента, в котором указывается наименование клиента, дата заказа, наименование, количество и цена товара, и выводится общий итог по стоимости.
2.2.1 Цель проектирования ИС:
Потребность в создании ИС обусловлена необходимостью автоматизации деятельности фирмы.
2.2.2 Основные функции, требующие автоматизации:
учет клиентов и заказов;
учет договоров.
2.2.3 Используемые документы и их описание:
Товар - внутренний документ, содержащий информацию о наличии товара, о его цене. Функция: учет товара.
Клиент - внутренний документ, содержащий информацию о клиенте. Функция: учет клиентов.
Заказ - внутренний документ, содержит информацию о всех заказах, сделанных клиентами. Функция: учет заказов.
Договор - исходящий документ. Функция: юридическое обоснование.
Отчет - внутренний документ, составляется на основе запроса по клиентам и товару.
Анализ предметной области организации отгрузки товара и получения отчетов по данному процессу проведем с помощью CASE-средства BPwin с использованием двух методов IDF0 и DFD. Выбор данных методов обусловлен следующими факторами: