Построение информационной модели

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

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

При ответе на вопрос «что лежит в основе бизнеса данной организации?», как правило, выявляются наиболее важные для данного бизнеса или производственного процесса компоненты.

Ответы на второй вопрос «как это делается?» позволяют получить список основных бизнес-процессов, происходящих в организации.

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

Ответ на вопрос «кто выполняет эти процессы?» даст организационная структура организации.

Важно получить и ответ на вопрос «когда выполняется то или иное действие?». Это внесет ясность в частоту осуществляемых бизнес-процессов и позволит правильно расставить акцепты в будущей прикладной программе.

Последний вопрос «почему эти действия выполняются?» позволяет определить основные мотивации производственной деятельности организации. Типичные бизнес-задачи могут быть представлены следующим списком: достижение наилучшего соотношения: «затраты — удобство для клиентов»; обеспечение условий для успешной деятельности персонала; получение приемлемой прибыли; повышение доходов при автоматизации обработки данных.

Ответы на шесть перечисленных вопросов позволяют подойти к главному моменту в постановке задачи — получению информационной модели организации. В простейшем виде такая модель может быть отражена в виде взаимосвязей между бизнес-компонентами и бизнес-процессами. В практике проектирования информационных систем такие схемы получили название ER-диаграмм {Entity-relationship diagram — ERD) — диаграммы «сущность — связь». ER-диаграммы хорошо вписываются в методологию структурного анализа и проектирования информационных систем. Такие методологии обеспечивают строгое и наглядное описание проектируемой системы, которое начинается с ее общего обзора и затем детализируется, давая возможность получить различную степень детализации объекта с разным количеством уровней.

Для проектирования сложных информационных моделей с помощью ER-диаграмм используются CASE-системы (Computer-aided Software Engineering). Эти системы позволяют проектировать информационные системы на основании построения в виде диаграмм многоуровневых потоков данных, создавать на их основе логическую и физическую модель БД.

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

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

• • внешняя сущность — материальный предмет или физическое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад;
• • система/подсистема; при построении модели сложной информационной системы она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого либо может быть декомпозирована на ряд подсистем;
• • процесс, представляющий собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом; физически процесс может быть реализован различными способами: это могут быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно-реализованное логическое устройство и т. д.;
• • накопитель данных, являющийся абстрактным устройством для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми;
• • поток данных, определяющий информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой, и т. д.

Пример построения модели потока данных при планировании технического обслуживания (ТО) автомобилей приведен на рис. 1.17. Этот бизнеспроцесс отражается в виде окружности и отнесен к первому уровню. Внешние по отношению к этому процессу сущности с необходимыми данными изображены в виде прямоугольников.

Рис. 1.17. Модель потока данных при планировании технического.

обслуживания Концептуальная модель транслируется затем в модель данных, совместимую с выбранной СУБД. Возможно, что отраженные в концептуальной модели взаимосвязи между объектами окажутся впоследствии нереализуемыми средствами выбранной СУБД. Это потребует изменения концептуальной модели.

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

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

Построение на основе концептуальной модели данных реляционной модели производится относительно просто. Каждый объект концептуальной модели отражается в одном отношении, которое отражает представление пользователя в удобном для него табличном формате. Простота отражения связана с тем, что при разработке концептуальной модели, как правило, используется реляционный подход. Пример логической модели автоматизированного рабочего места (АРМ) диспетчера автотранспортной организации (АТО) приведен на рис. 1.18.

Рис. 1.18. Логическая модель автоматизированного рабочего места диспетчера автотранспортной организации

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

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

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

Ограничения целостности — это набор определенных правил, которые определяют допустимость данных и связей между ними. Ограничения целостности в большинстве случаев зависят от особенностей предметной области. Например, мощность двигателя серийного легкового автомобиля вряд ли может быть ниже 30 л.с. Ограничения целостности могут относиться к разным объектам БД: атрибутам (полям), записям, отношениям, связям между ними и т. п. Для полей, как правило, могут использоваться следующие виды ограничений:

• • тип и формат поля автоматически допускают ввод только данных определенного типа. — выбор типа ноля Date в формате ДД.ММ.ГГ позволит пользователю ввести только шесть чисел, при этом первая пара цифр не сможет превысить в лучшем случае значения 31, а вторая — 12;
• • задание диапазона значений, как правило, используется для числовых полей — диапазон допустимых значений может быть ограничен или с двух сторон (закрытый диапазон), или с какой-то одной: верхней или нижней (открытый диапазон);
• • недопустимость пустого поля позволяет избежать появления в БД «ничейных» записей, в которых пропущены какие-либо обязательные атрибуты;
• • задание списка значений дает возможность избежать излишнего разнообразия данных, если его можно ограничить. Например, для указания типа кузова мы можем ограничить фантазию пользователя только общепринятыми названиями: седан, кабриолет и т. д.;
• • проверка на уникальность значения какого-то ноля позволяет избежать записей-дубликатов; вряд ли будет удобно в справочнике клиентов иметь несколько записей для одного и того же лица.

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