Если мы учтем, что между вторым и третьим этапами необходимо принять решение, с использованием какой стандартной СУБД будет реализовываться наш проект, то условно процесс проектирования можно представить последовательностью выполнения пяти соответствующих этапов (рис. 4.1).

Рис. 4.1 - Этапы проектирования БД

С точки зрения проектирования БД в рамках системного анализа, необходимо осуществить первый этап, то есть провести подробное словесное описание объектов предметной области и реальных связей, которые присутствуют между описываемыми объектами. Желательно, чтобы данное описание позволяло корректно определить все взаимосвязи между объектами предметной области.

В общем случае существуют два похода к выбору состава и структуры предметной области:

Ш Функциональный подход - он реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая СУБД. В этом случае мы можем четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.

Ш Предметный подход - когда информационные потребности будущих пользователей БД жестко не фиксируются. Они могут быть многоаспектными и весьма динамичными. Мы не может точно выделить минимальный набор объектов предметной области, которые необходимо описывать. В описание предметной области в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для нее. БД, конструируемая при этом, называется предметной, то есть она может быть использована при решении множества разнообразных, заранее не определенных задач. Конструирование предметной БД в некотором смысле кажется гораздо более заманчивым, однако трудность всеобщего охвата предметной области с невозможностью конкретизации потребностей пользователей может привести к избыточно сложной схеме БД, которая для конкретных задач будет неэффективной.

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

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

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

Мифологическое проектирование связано, прежде всего, с попыткой представления семантики предметной области в модели БД. Реляционная модель данных в силу своей простоты и лаконичности не позволяет отобразить семантику, то есть смысл предметной области. Ранние теоретико-графовые модели в большей степени отображали семантику предметной области. Они в явном виде определяли иерархические связи между объектами предметной области.

4.2 Анализ предметной области

В данной магистерской работе нужно разработать базу данных (БД) автоматизированного рабочего места (АРМ) мастера механического цеха с помошью программы Microsoft Access, которая будет использоваться мастером участка для сбора, внесения и редактирования необходимой информации. В данном случае необходимо автоматизировать работу мастера участка.

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

Microsoft Access предоставляет максимальную свободу в задании типа данных (текст, числовые данные, даты, время, денежные значения, рисунки, звук, электронные таблицы). Можно задавать также форматы хранения представления этих данных при выводе на экран или печать. Для веренности, что в базе хранятся только корректные значения, можно задать условия на значения различной степени сложности.

Так как Microsoft Access является современным приложением Windows, можно использовать в работе все возможности DDE (динамический обмен анными) и OLE (связь и внедрение объектов). DDE позволяет осуществлять обмен данными между Access и любым другим поддерживающим DDE приложением Windows. В Microsoft Access можно при помощи макросов или Access Basic осуществлять динамический обмен данными с другими приложениями.

OLE является более изощренным средством Windows, которое позволяет установить связь с объектами другого приложения или внедрить какие-либо объекты в базу данных Access. Такими объектами могут быть картинки, диаграммы, электронные таблицы или документы из других поддерживающих OLE приложений Windows.

Microsoft Access предоставляет дополнительные средства разработки приложений, которые могут работать не только с собственными форматами данных, но и с форматами других наиболее распространенных СУБД. Возможно, наиболее сильной стороной Access является его способность обрабатывать данные электронных таблиц, текстовых файлов, файлов dBASE, Paradox, Btrieve, FoxPro и любой другой базы данных SQL, поддерживающей стандарт ODBE. Это означает, что можно использовать Access для создания такого приложения Windows, которое может обрабатывать данные, поступающие с сетевого сервера SQL или базы данных SQL на главной ЭВМ. Графически представлена схема выполнения работ, обмена информацией, документооборота визиализирует модель бизнесс-процесса. Также изложение этой информации позволяет перевести задачи управления организацией из области сложного ремесла в сферу инженерных технологий. AllFusion Process Modeler 7 (BPwin) помагает четко документировать важные аспекты любых бизнес-процессов: действия, которые необходимо предпринять , способы их осуществления и контроля, требующиеся для этого ресурсы, а также визуализировать получаемые от этих действий результаты.

4.3 Инфологическая модель БД

МОДЕЛЬ - это идеализированное представление достаточно близко отражающее описываемую систему.

Мощность модели заключается в ее способности упростить реальную систему, что дает возможность предсказывать факты в системе на основании соответствующих фактов представленных в модели.

Допустим, необходимо описать операцию производственной системы. Вероятно, можно произвести достаточно полное описание. Но, где ответ на вопрос в достаточности описания операции. Попробуем получить два описания операции производственной системы. Пусть операцию описывает руководитель производственной системы (назовем его руководитель) и человек, участвующий в описываемой операции (рабочий). Это будут два различных описания, две различных точки зрения на выполнение операции. Первое описание, описание руководителя, будет очень абстрагировано, и по сути скорее будет напоминать описание той технологии, согласно которой должна выполняться операция. Необходимо отметить, что человеку проще описывать некоторую реальную ситуацию, в которой он сам участвовал или наблюдал со стороны. В такой ситуации находится рабочий, но вероятнее всего его описание производственной операции тоже будет иметь свои недостатки. Проблема заключается в ответе на вопрос: не будет ли эта ситуация слишком частной, кроме того любая конкретная ситуация, которую скорее всего и будет описывать рабочий, всегда излишне детализирована. Итак, у нас есть два описания производственной операции, но ни одно из них не является моделью производственной операции. Итак, модель - форма описания, но не наоборот. Модели необходимы для создания данных прогноза и анализа, что не доступно в описаниях. Основная цель моделирования состоит в том, чтобы идентифицировать и документировать все аспекты работы системы. Поэтому первым этапом любого исследования является постановка задачи, которая определяется заданной целью. От того, как адекватно выбрана цель моделирования, зависит и вид модели, и выбор программной среды и получаемые результаты.

В большинстве случаев, единственным набором изложенных правил, в соответствии с которыми должно функционировать предприятие, является набор отдельных положений и должностных инструкций. Чаще всего эти документы составлялись не один год назад, слабо структурированы и невзаимосвязаны между собой и, вследствие этого, просто пылятся на полках. На начальных этапах создания ИС обязательно возникает необходимость в изучении того, как работает предприятие, какие технологические процессы обработки циркулирующей информации существуют. Обычно никто в организации ни знает, как она работает в той мере подробности, которая необходима для создания ИС:

* руководитель хорошо знает работу в целом, но не в состояния вникнуть в детали работы каждого рядового сотрудника;

* рядовой сотрудник хорошо знает, что творится на его рабочем месте, но плохо знает, как работают коллеги.

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

Создание и внедрение интегрированной ИС на предприятии, особенно в условиях виртуального предприятия, связано с глубокими исследованиями процессов, составляющих ЖЦ изделия. Для моделирования сложных систем существуют достаточно большое количество методологий и стандартов. К ним относятся, в частности, методологии семейства IDEF, основанных на графическом представлении систем, с помощью которых можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом глубина исследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.

CASE-средство верхнего уровня BPwin - это инструмент визуального моделирования ИС, позволяющий:

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

* проверить модель на соответствие стандартам ISO9000. Для отечественных предприятий сертификация по ИСО 9000 - это пропуск на международный рынок, а также действенное средство для эффективного улучшения работы всего предприятия;

* спроектировать структуру информационных потоков, а соответственно, и модернизировать организационную структуру предприятия;

* четко выявить факторы, оказывающие влияние на бизнес: какие операции являются наиболее критичными, как повысить их эффективность, какие ресурсы требуются для этого; * снизить издержки и повысить производительность;

* повысить гибкость и эффективность.

BPwin входит в семейство продуктов AllFusion компании Computer Associates под именем AllFusion Process Modeler и предназначен для поддержки всех стадий жизненного цикла разработки ИС. - В линейку продуктов AllFusion Modeling Suite кроме BPwin для поддержки всех стадий разработки программного обеспечения, входят CASE-средств ERwin, BPwin, ModelMart, Paradigm Plus, ERwin Examiner и средства управления проектами. Совместное применение этих продуктов обеспечивает прочный фундамент для построения, развертывания и управления приложениями. При этом не накладываются ограничения на выбор базовых технологий, методов и платформ разработки. AllFusion Modeling Suite предлагает моделирование и управление процессами, проектами, изменениями, конфигурациями.

BPwin - инструмент моделирования, который используется не только для анализа и документирования, но и реорганизации сложных процессов. BPwin соответствует требованиям к инструментам для разработки ИС, так как позволяет четко документировать различные действия, которые необходимо предпринять, а также способы их осуществления и требуемые для этого ресурсы. BPwin является интуитивно понятным визуальным инструментом, позволяющим сформировать целостную картину деятельности предприятия: от моделей организации работы в маленьких отделах до сложных иерархических структур. В руках же системных аналитиков и разработчиков BPwin - мощное средство моделирования процессов при создании корпоративных информационных систем (КИС).

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11