Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Базы данных проектирование и реализация. Учебное пособие

.pdf

Скачиваний:

Добавлен:

07.09.2026

Размер:

2 Мб

Скачать

☆

<<< < Предыдущая 12 / 122 3 4 5 6 7 8 9 10 11 12 > Следующая >>>

2. ПРОЦЕСС ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ

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

(«An information system is designed to help transform data into information and to manage both data and information. Thus, the database is a very important part of the information system») [17]. Таким образом, база дан-

ных – это центральный элемент и один из основных факторов, ляющий производительность и эффективность ИС.

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

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

технологии, к разработке прикладного программного обеспечения

и созданию организационно-нормативного окружения.

В общем случае критериями выбора СУБД могут служить [18]:

 моделирование данных;

 особенности архитектуры и функциональные возможности;

опреде-

Жизненный цикл информационной системы – развитие системы, про-

дукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения [21].

 контроль работы системы;

 особенности разработки приложений;

 производительность;

 надежность;

 требования к рабочей среде;

 смешанные критерии.

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

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

которых обеспечивает разра-

ботку проекта базы данных, удовлетворяющей заданным требованиям.

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

того, методология предлагает методы планирования, координации, управления, оценки хода разработки проекта, а также структурированный подход к анализу и моделированию всего набора требований, предъявляемых к базе данных, и позволяет выполнить эти действия стандартизированным и организованным образом [19].

Цель проектирования БД заключается в таком представлении дан-

ных и связей между ними

, которое:

 отражает реалии предметной области, существенные для решае-

мых задач (адекватно предметной области);

 обеспечивает экономию объема используемой памяти за счет со-

кращения избыточности хранимых данных;

 не требует многократных операций для ввода и модификации дан-

ных (соблюдается принцип однократный ввод – многократное ис-

пользование);

 удовлетворяет требованиям производительности (скорости

до-

ступа к данным);

 гарантирует целостность и непротиворечивость данных (исклю- чает появление ошибок в данных, в том числе из-за хранения в разных местах сведений об одном и том же объекте);

 обеспечивает безболезненную адаптацию к изменившимся усло- виям эксплуатации (появление новых задач, смена платформы).

Процесс проектирования базы данных представляет последовательность следующих шагов или этапов:

 сбор информации о предметной области (предпроектное обследо- вание);

 анализ требований;

 концептуальное проектирование;

 логическое проектирование;

 физическое проектирование.

2.1. ПРЕДПРОЕКТНОЕ ОБСЛЕДОВАНИЕ

Предпроектное обследование

– это мероприятие, которые проводит

разработчик с целью уточнения целей, задач, объема предстоящих работ. Сбор информации о предметной области – это начальный этап проектирования ИС [20], в ходе которого собираются и анализируются документы, необходимые для деятельности организации, проводятся собеседования со специалистами, занятыми в технологических или бизнес-процессах, с

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

Методы предпроектного обследования включают [21]:

 изучение документов;  метод наблюдения;  фотографию и самофотографию рабочего дня;  хронометраж;  опрос (интервьюирование);  анкетирование;  графический и статистический методы.

В результате предпроектного обследования создается множество документов [24], некоторые из которых должны будут содержать следующие результаты обследования:

 описание изученных бизнес-процессов и документопотоков орга-

низации;

 перечень документов и отчетных форм, используемых в органи-

зации;

 описание ролей пользователей.

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

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

 достоверной, основанной на фактах, первичных материалах, ста- тистических

данных;

 объективной, отражающей подлинную сущность явления, а не субъективное мнение или оценку лица, проводящего обследование;

 стандартной, сопоставимой, обеспечивающей возможность сопо- ставлять во время анализа материалы обследования по разным периодам, аспектам и в различных подразделениях;

 пригодной для машинной обработки.

Анализ результатов предпроектного обследования позволяет сформулировать функциональные требования

к системе, перечень необходи-

мых данных и ограничения (нефункциональные требования).

Требование – утверждение, которое отражает или выражает потребность и связанные с ней ограничения и условия [22].

Требования описывают поведение системы (требуемую функциональность) и различные особенности поведения или эксплуатации:

1) условия или возможности, необходимые пользователю для реше-

ния проблем или достижения целей

;

2) условия или возможности, которыми должна обладать система и

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

3) документированное представление условий или возможностей,

отмечены в п. 1 и 2.

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

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

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

в рамках которых должен выполняться проект и которым должна соответствовать система.

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

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

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

 объектный (предметный), при котором выполняется системный анализ предметной области (ПрО – предметная область). В описание предметной области

в этом случае включаются такие объекты и взаимо-

связи, которые наиболее характерны и наиболее существенны для нее.

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

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

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

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

Любой из подходов изначально ориентируется на функциональный

анализ предметной области, выполняемый

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

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

2.2. АНАЛИЗ ТРЕБОВАНИЙ

Проведение анализа информации о предметной

области в интересах

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

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

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

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

В результате анализа должны быть сформулированы:

 подробное описание объектов предметной области и информаци-

онных процессов;

 конкретные задачи, которые будут решаться данной ИС с кратким

описанием алгоритмов решения;

 описание выходных документов, которые должны генерироваться

в системе;

 описание входных документов, которые служат основанием для

заполнения данными БД.

Цель анализа требований – не создание юридического документа,

а максимально полное описание требований заказчика по проекту.

Перечислим основные риски при сборе и анализе требований.

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

пользователям. Не увеличивайте количество сущ-

ностей сверх необходимого («бритва Оккама»).

2. Риск «невовлеченности» заказчика. Непонимание заказчиком необходимости сбора и анализа требований приводит к провалу проекта. Заказчику может быть невыгодно иметь формализованный и согласованный список требований. В этом случае он может «давить» на разработчика, требуя выполнения работ, ранее не предусмотренных. Иногда проблема возникает при недобросовестности либо некомпетентности менеджера заказчика, ведущего проект.

3. Риск формализации, когда слишком много времени и сил уходит на полную формализацию требований.

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

множество объектов, реальных или виртуальных, информация о которых должна храниться в базе данных.

Выделенные в предметной области объекты определяют состав базы данных информационной системы. Для этого каждому объекту предметной области ставится в соответствие его информационный аналог – объект, сохраняемый в базе данных. Множества однотипных информационных объектов, обладающих одинаковыми наборами

свойств, образуют

сущности предметной области. Каждая сущность имеет набор атрибутов, которые соответствуют свойствам объектов предметной области.

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

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

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

При проектировании для уменьшения трудоемкости предметную область разбивают на ряд локальных областей (представлений), описывают

каждое локальное представление, а затем их объединяют. Объеди-

нение выполняется путем:

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

 установления связей между наборами сущностей разных пред- ставлений;

 агрегации – введения новых агрегированных элементов для пред- ставления связей между элементами разных представлений

. Агрегация – это абстракция, которая превращает связь между объектами в некоторый агрегированный объект;

 обобщения – объединения различных подобных сущностей, поз-

воляющего трактовать эти сущности как одну обобщенную сущность.

Чтобы гарантировать успешное проектирование базы данных, необ-

ходимо:

1) поддерживать постоянную и активную связь с будущими пользо-

вателями системы;

2) при

проведении процедур концептуального и логического моде-

лирования данных использовать обоснованные методологии;

3) создавать модель данных с учетом требований поддержки их

структурной целостности и согласованности;

4) для представления результатов проектирования базы данных как

можно шире использовать схемы;

5) ориентироваться на создание приложений, управляемых дан-

ными;

6) для уменьшения трудоемкости проектирования и увеличения наглядности результатов проектирования использовать программные средства поддержки процесса проектирования;

7) создавать словарь описания данных как неотъемлемое приложе- ние к схемам моделей данных.

3. КОНЦЕПТУАЛЬНОЕ

ПРОЕКТИРОВАНИЕ ДАННЫХ

Концептуальное проектирование – это наиболее общее описание данных предметной области, не учитывающее никаких деталей реализации. Этап концептуального проектирования необходим для согласованного (заказчиком и разработчиком) понимания задачи.

Понятие концептуального проектирования относится к начальной стадии проектирования ИС и примерно соответствует стадиям 1 – 3 разработки по ГОСТ 34.601–90 [20] или этапам от определения требований до проектирования

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

Визуализация концептуальной модели обычно выполняется в виде

ER-диаграмм. Аббревиатура lation (связь), поэтому в некоторых источниках эти диаграммы назы-

вают диаграммами сущность–связь [24].

Модель «сущность–связь» была предложена в 1976 г. Питером ПинШэн Ченом, русский перевод его статьи «Модель “сущность–связь” – шаг к единому представлению данных» имеется в [25].

Основными элементами концептуальной модели являются сущности, атрибуты и связи.

Для построения ER-диаграмм вательность действий.

в моделях жизненного цикла [23].

ER составлена из Entity (сущность) и Re-

предлагается определенная последо-

1. Выделение всех элементов данных, необходимых для решения за-

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

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

получает допустимые значения из некоторого именованного множества, называемого доменом. По сути своей имя домена характеризует тип значений [26], его составляющих.

Набор конкретных значений атрибутов конкретной сущности представляет экземпляр сущности – объект предметной области, реальный или виртуальный (абстрактный). Сущность является множеством объектов, каждый из которых обладает собственным набором значений составляющих атрибутов, удовлетворяющих следующему:

 объекты могут обладать любым количеством атрибутов, но объ- екты, объединенные понятием сущность, являются однородными, т. е. характеризуются одинаковым набором атрибутов;

 каждый атрибут должен иметь уникальное имя в пределах сущ- ности;

 каждый атрибут должен быть атомарен, т. е. значение атрибута не может быть разделено

на составные части без потери смысла.

3. Выделение связей между сущностями. Связи представляют некоторые отношения между экземплярами сущностей (объектами), которые проецируются на связи между сущностями.

4. Классификация связей. Характеристиками связей являются:

 имя связи, определяющее ее смысл (семантику). Имя связи вы- ражает некоторое ограничение или бизнес-правило и облегчает пони мание диаграммы. Как правило, связи именуются глаголом или глагольным выражением: Работает в должности, Проживает на улице и т. п.;

 значность (кардинальность), количество экземпляров одной сущ- ности, связанных с экземплярами другой сущности (1 : 1, 1 : М, М : М или М : N, где М, N – произвольные или фиксированные значения):

– связь 1 : 1 (один к одному

) означает, что каждый экземпляр одной

сущности связан не более чем с одним экземпляром другой сущности и наоборот;

<<< < Предыдущая 12 / 122 3 4 5 6 7 8 9 10 11 12 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]