Жизненные циклы БД

Лекция №04 - Жизненные циклы БД

Краткое описание: Жизненные циклы информационных систем. Цели и задачи проектирования. Проектирование баз данных (о трех этапах). Формулирование и анализ требований. Концептуальное проектирование. Модель «сущность-связь». Критерии выбора первичного ключа.

Содержание

[убрать]

1 Обзор жизненного цикла информационных систем
- 1.1 Жизненный цикл приложения баз данных
2 Цели и задачи проектирования
3 Проектирование баз данных(о трех этапах)
- 3.1 Подходы к проектированию базы данных
- 3.2 Моделирование данных
- 3.3 Критерии оценки модели данных
- 3.4 Этапы проектирования базы данных
  - 3.4.1 Концептуальное проектирование базы данных
  - 3.4.2 Логическое проектирование базы данных
  - 3.4.3 Физическое проектирование базы данных
4 Формулирование и анализ требований
- 4.1 Определение требований к системе
- 4.2 Пользовательские представления
- 4.3 Сбор и анализ требований пользователей
5 Концептуальное проектирование базы данных
6 Модель "сущность-связь"
- 6.1 Элементы модели
  - 6.1.1 Один к одному (обозначается 1 : 1 )
  - 6.1.2 Один ко многим ( 1 : n )
  - 6.1.3 Много к одному (n : 1 )
  - 6.1.4 Многие ко многим ( n : n )
7 Критерии выбора первичного ключа

Обзор жизненного цикла информационных систем

Начиная с 1970-х годов системы баз данных стали постепенно заменять файловые системы, использовавшиеся как часть инфраструктуры информационных систем (Information System — IS) организаций. Параллельно с этим росло признание того факта, что данные являются важным корпоративным ресурсом, к которому нужно относиться так же бережно, как и к другим ресурсам организации. Это привело к тому, что во многих организациях появились целые отделы или функциональные подразделения, занимавшиеся администрированием данных (АД) и администрированием баз данных (АБД). Они отвечали за обработку и управление корпоративными данными и корпоративными базами данных.

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

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

Жизненный цикл приложения баз данных

Как уже упоминалось выше, система базы данных является фундаментальным компонентом более широкого понятия — информационной системы организации. Следовательно, жизненный цикл приложений баз данных неразрывно связан с жизненным циклом информационной системы. Этапы жизненного цикла приложения базы данных показаны на рисунке. Следует признать, что эти этапы не являются строго последовательными, а предусматривают в некоторых случаях возврат к предыдущим этапам с помощью обратных связей (feedback loops). Например, при проектировании базы данных могут возникнуть проблемы, для разрешения которых потребуется вернуться к этапу сбора и анализа требований. Обратные связи могут возникать почти между всеми этапами, но на рисунке показаны только наиболее важные из них. Основные сведения о наиболее важных мероприятиях, связанных с реализацией каждого этапа жизненного цикла приложения базы данных, приведены в таблице.

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

[показать]Картинка

Основные действия, выполняемые на каждом этапе жизненного цикла приложения базы данных:

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

Цели и задачи проектирования (В начало)

В настоящее время ключевая роль в достижении успеха большинства компьютеризованных систем принадлежит не используемому оборудованию, а программному обеспечению. Однако существующие исторические свидетельства о разработке программного обеспечения систем не производят столь глубокого впечатления, как хронологические обзоры стремительного прогресса в области аппаратных средств вычислительной техники. В последние десятилетия прикладные программы проделали путь от маленьких и сравнительно простых приложений из нескольких строк кода до очень больших и сложных приложений, состоящих из нескольких миллионов строк. Многие из этих приложений требовали постоянного сопровождения, включая исправление выявленных ошибок, реализацию новых требований пользователей, а также перенос программного обеспечения на новые или модернизированные вычислительные платформы. Усилия и ресурсы, затрачиваемые на сопровождение программного обеспечения, возрастали угрожающими темпами. В результате разработка и реализация многих крупных проектов затягивалась, их стоимость превосходила запланированную, а окончательный продукт получался ненадежным, сложным в сопровождении и обладавшим недостаточной производительностью. Все это привело к ситуации, которая известна под названием "кризис программного обеспечения". Хотя первые упоминания о кризисе были сделаны еще в конце 1960-х годов, даже спустя более чем 40 лет его все еще не удалось преодолеть. В настоящее время многие авторы даже называют этот кризис "депрессией программного обеспечения". В Великобритании специальная Группа по изучению организационных аспектов информатики (Organizational Aspects Special Interest Group - OASIG) исследовала эту проблему и сформулировала следующие выводы:

Примерно 80-90% компьютеризованных систем не обладают требуемой производительностью.
При разработке около 80% систем были превышены установленные для этого временные и бюджетные рамки.
Разработка около 40% систем закончилась неудачно или была прекращена до завершения работы.
Менее чем 40% систем предусматривали профессиональное обучение и повышение квалификации пользователей во всем необходимом объеме.
Гармонично интегрировать интересы бизнеса и используемой технологии удалось не более чем в 25% систем.
Только 10-20% систем отвечают всем критериям достижения успеха.

Неудачи при создании программного обеспечения были вызваны следующими причинами:

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

Для разрешения этой проблемы был предложен структурный подход к разработке программного обеспечения, называемый жизненным циклом информационных систем (Information Systems Lifecycle), или жизненным циклом разработки программного обеспечения (Software Development LifeCycle — SDLC). Далее будет использоваться только термин "жизненный цикл информационных систем".

Проектирование баз данных(о трех этапах)

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

Пример применения метода интеграции представлений к управлению пользовательскими представлениями (Рисунок не в тему)

Подходы к проектированию базы данных

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

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

Более подходящей стратегией проектирования сложных баз данных является использование нисходящего подхода. Начинается этот подход с разработки моделей данных, которые содержат несколько высокоуровневых сущностей и связей, затем работа продолжается в виде серии нисходящих уточнений низкоуровневых сущностей, связей и относящихся к ним атрибутов. Нисходящий подход демонстрируется в концепции модели "сущность-связь". В этом случае работа начинается с выявления сущностей и связей между ними, интересующих данную организацию в наибольшей степени. Например, сначала можно было бы идентифицировать сущности PrivateQwner (Владелец) и PropertyForRent (Объект недвижимости), затем установить между ними связь PrivateOwner Owns (Владеет) PropertyForRent и лишь после этого определить связанные с ними атрибуты — например, PrivateOwner {ownerNo, name, address) и PropertyForRent (propertyNo, address). (Не в тему)

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

Моделирование данных

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

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

Модели данных могут использоваться для демонстрации понимания разработчиком тех требований к данным, которые существуют на предприятии. Если обе стороны знакомы с системой обозначений, используемой для создания модели, то наличие модели данных будет способствовать более плодотворному общению пользователей и разработчиков. На предприятиях все шире применяются средства стандартизации для моделирования данных путем выбора определенного метода моделирования и использования его во всех проектах разработки базы данных. Самая популярная технология высокоуровневого моделирования данных, чаще всего используемая при разработке реальных баз данных, построена на концепции модели "сущность-связь" (Entity-Relationship model — ER-модель).

Критерии оценки модели данных

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

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

Этапы проектирования базы данных

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

Концептуальное проектирование базы данных

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

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

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

Логическое проектирование базы данных

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

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

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

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

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

Физическое проектирование базы данных

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

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

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

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

Этапы концептуального и логического проектирования больших систем следует отделять от этапов физического проектирования. На это есть несколько причин.

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

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

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

Соответствие этапов моделирования данных и элементов архитектуры ANSI-SPARC

(Рисунок не нужен)

Формулирование и анализ требований

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

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

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

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

Определение требований к системе

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

Задачи системы для приложения базы данных

Пользовательские представления

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

Любое пользовательское представление определяет требования к приложению базы данных в части хранимых в ней данных и транзакций, выполняемых над данными (т.е. оно определяет, какие действия и над какими данными должен выполнять тот или иной пользователь). Требования пользовательского представления могут относиться только к данному представлению или частично совпадать с требованиями других представлений. На рисунке схематически изображена предметная область приложения базы данных с несколькими пользовательскими представлениями (которые обозначены цифрами 1-6). Обратите внимание, что требования некоторых пользовательских представлений (1—3, а также 5 и 6) частично перекрываются (это показано штриховкой), а требования пользовательского представления 4 являются индивидуальными.

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

Сбор и анализ требований пользователей

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

Описание применяемых или вырабатываемых данных.
Подробные сведения о способах применения или выработки данных.
Все дополнительные требования к создаваемому приложению базы данных.

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

Сбор и анализ требований является предварительным этапом концептуального проектирования базы данных, в ходе которого спецификации требований пользователей анализируются с целью выяснения всех необходимых сведений. Объем собранных данных зависит от сути проблемы и действующих бизнес-правил предприятия. Слишком тщательный анализ легко может привести к параличу сверханализа (paralysis by analysis), а слишком поверхностный — к пустой трате времени и денежных средств на проведение работ по реализации решения, которое окажется ошибочным в результате неправильной формулировки проблемы.

Собранная на этом этапе информация может быть плохо структурирована и включать некоторые неформальные заявления пользователей, которые впоследствии потребуется преобразовать и представить в виде более четко сформулированных требований. Эта цель достигается с помощью методов составления спецификаций требований, к числу которых относятся, например, технология структурного анализа и проектирования (Structured Analysis and Design — SAD), диаграммы потоков данных (Data Flow Diagrams — DFD) и графики "вход-процесс-выход" (Hierarchical Input Process Output — HIPO), дополненные соответствующей документацией. Как будет показано ниже, для получения гарантий того, что составленный набор требований является полным и непротиворечивым, могут использоваться CASE-инструменты, предназначенные для автоматизированного проектирования и создания программ.

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

[показать]Выбор пользовательского представления

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

Централизованный подход.
Метод интеграции представлений.
Сочетание обоих подходов.

Централизованный подход

Пример применения централизованного подхода к управлению пользовательскими представлениями 1-3

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

Централизованный подход предусматривает объединение требований к различным пользовательским представлениям в единый набор требований, который в дальнейшем именуется общим представлением. Общему представлению присваивается собирательное имя, которое, в частности, указывает, какая функциональная область охвачена этим объединенным пользовательским представлением. На этапе проектирования базы данных создается глобальная модель данных, соответствующая общему представлению, иными словами, моделируемой области деятельности предприятия. Глобальная модель данных состоит из схем и документации, которая формально описывает требования пользователей базы данных. На рисунке показана схема применения централизованного подхода к управлению пользовательскими представлениями 1-3. Как правило, такой подход в основном применяется, если требования к каждому пользовательскому представлению в значительной степени перекрываются и приложение базы данных является не слишком сложным.

Метод интеграции представлений

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

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

(Не было на лекции)

Концептуальное проектирование базы данных (Добавить к предыдущему конц. проектированию).

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

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

Этапы концептуального проектирования:

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

Охват предметной области данного предприятия.

Определение типов сущностей.

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

Определение типов связей.

Определение важнейших типов связей, существующих между сущностями, выделенными на предыдущем этапе.

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

Связывание атрибутов с соответствующими типами сущностей или связей.

Определение доменов атрибутов.

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

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

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

Обоснование необходимости использования понятий расширенного моделирования (необязательный этап).

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

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

Проверка на отсутствие какой-либо избыточности данных в модели.

Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям.

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

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

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

TODO:

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

Модель "сущность-связь"

http://www.mstu.edu.ru/education/materials/zelenkov/ch_2_1.html

Прежде, чем приступать к созданию системы автоматизированной обработки информации, разработчик должен сформировать понятия о предметах, фактах и событиях, которыми будет оперировать данная система. Для того, чтобы привести эти понятия к той или иной модели данных, необходимо заменить их информационными представлениями. Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель "сущность-связь" (entity - relationship model, ER - model).

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

Элементы модели

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

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

Набор сущностей (entity set) - множество сущностей одного типа (обладающих одинаковыми свойствами). Примеры: все люди, предприятия, праздники и т.д. Наборы сущностей не обязательно должны быть непересекающимися. Например, сущность, принадлежащая к набору МУЖЧИНЫ, также принадлежит набору ЛЮДИ.

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

В дальнейшем для определения сущности и ее атрибутов будем использовать обозначение вида

СОТРУДНИК (ТАБЕЛЬНЫЙ_НОМЕР, ИМЯ, ВОЗРАСТ).

Множество значений (область определения) атрибута называется доменом.

Отсюда определяется ключ сущности - группа атрибутов, такая, что отображение набора сущностей в соответствующую группу наборов значений является взаимнооднозначным отображением. Другими словами: ключ сущности - это один или более атрибутов уникально определяющих данную сущность. В нашем примере ключем сущности СОТРУДНИК является атрибут ТАБЕЛЬНЫЙ_НОМЕР (конечно, только в том случае, если все табельные номера на предприятии уникальны).

Связь (relationship) - это ассоциация, установленная между несколькими сущностями. Примеры:

поскольку каждый сотрудник работает в каком-либо отделе, между сущностями СОТРУДНИК и ОТДЕЛ существует связь "работает в" или ОТДЕЛ-РАБОТНИК;
так как один из работников отдела является его руководителем, то между сущностями СОТРУДНИК и ОТДЕЛ имеется связь "руководит" или ОТДЕЛ-РУКОВОДИТЕЛЬ;
могут существовать и связи между сущностями одного типа, например связь РОДИТЕЛЬ - ПОТОМОК между двумя сущностями ЧЕЛОВЕК;

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

К сожалению, не существует общих правил определения, что считать сущностью, а что связью. В рассмотренном выше примере мы положили, что "руководит" - это связь. Однако, можно рассматривать сущность "руководитель", которая имеет связи "руководит" с сущностью "отдел" и "является" с сущностью "сотрудник".

Связь также может иметь атрибуты. Например, для связи ОТДЕЛ-РАБОТНИК можно задать атрибут СТАЖ_РАБОТЫ_В_ОТДЕЛЕ.

Роль сущности в связи - функция, которую выполняет сущность в данной связи. Например, в связи РОДИТЕЛЬ-ПОТОМОК сущности ЧЕЛОВЕК могут иметь роли "родитель" и "потомок". Указание ролей в модели "сущность-связь" не является обязательным и служит для уточнения семантики связи.

Набор связей (relationship set) - это отношение между n (причем n не меньше 2) сущностями, каждая из которых относится к некоторому набору сущностей.

Пример:

сущности наборы сущностей

---------- ----------------

e1 принадлежит E1

e2 принадлежит E2

. . .

en принадлежит En

тогда [e1,e2,...,en] - набор связей R

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

В случае n=2, т.е. когда связь объединяет две сущности, она называется бинарной. Доказано, что n-арный набор связей (n>2) всегда можно заменить множеством бинарных, однако первые лучше отображают семантику предметной области.

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

Один к одному (обозначается 1 : 1 )

Это означает, что в такой связи сущности с одной ролью всегда соответствует не более одной сущности с другой ролью. В рассмотренном нами примере это связь "руководит", поскольку в каждом отделе может быть только один начальник, а сотрудник может руководить только в одном отделе. Данный факт представлен на следующем рисунке, где прямоугольники обозначают сущности, а ромб - связь. Так как степень связи для каждой сущности равна 1, то они соединяются одной линией.

Таким образом, говорят, что сущность "СОТРУДНИК" имеет обязательный класс принадлежности (этот факт обозначается также указанием интервала числа возможных вхождений сущности в связь, в данном случае это 1,1), а сущность "ОТДЕЛ" имеет необязательный класс принадлежности (0,1). Теперь данную связь мы можем описать как 0,1:1,1. В дальнейшем кардинальность бинарных связей степени 1 будем обозначать следующим образом:

Один ко многим ( 1 : n )

В данном случае сущности с одной ролью может соответствовать любое число сущностей с другой ролью. Такова связь ОТДЕЛ-СОТРУДНИК. В каждом отделе может работать произвольное число сотрудников, но сотрудник может работать только в одном отделе. Графически степень связи n отображается "древообразной" линией, так это сделано на следующем рисунке.

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

Здесь также необходимо учитывать класс принадлежности сущностей. Каждый сотрудник должен работать в каком-либо отделе, но не каждый отдел (например, вновь сформированный) должен включать хотя бы одного сотрудника. Поэтому сущность "ОТДЕЛ" имеет обязательный, а сущность "СОТРУДНИК" необязательный классы принадлежности. Кардинальность бинарных связей степени n будем обозначать так:

Много к одному (n : 1 )

Эта связь аналогична отображению 1 : n. Предположим, что рассматриваемое нами предприятие строит свою деятельность на основании контрактов, заключаемых с заказчиками. Этот факт отображается в модели "сущность-связь" с помощью связи КОНТРАКТ-ЗАКАЗЧИК, объединяющей сущности КОНТРАКТ(НОМЕР, СРОК_ИСПОЛНЕНИЯ, СУММА) и ЗАКАЗЧИК(НАИМЕНОВАНИЕ, АДРЕС). Так как с одним заказчиком может быть заключено более одного контракта, то связь КОНТРАКТ-ЗАКАЗЧИК между этими сущностями будет иметь степень n : 1.

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

Многие ко многим ( n : n )

В этом случае каждая из ассоциированных сущностей может быть представлена любым количеством экземпляров. Пусть на рассматриваемом нами предприятии для выполнения каждого контракта создается рабочая группа, в которую входят сотрудники разных отделов. Поскольку каждый сотрудник может входить в несколько (в том числе и ни в одну) рабочих групп, а каждая группа должна включать не менее одного сотрудника, то связь между сущностями СОТРУДНИК и РАБОЧАЯ_ГРУППА имеет степень n : n.

Если существование сущности x зависит от существования сущности y, то x называется зависимой сущностью (иногда сущность x называют "слабой", а "сущность" y - сильной). В качестве примера рассмотрим связь между ранее описанными сущностями РАБОЧАЯ_ГРУППА и КОНТРАКТ. Рабочая группа создается только после того, как будет подписан контракт с заказчиком, и прекращает свое существование по выполнению контракта. Таким образом, сущность РАБОЧАЯ_ГРУППА является зависимой от сущности КОНТРАКТ. Зависимую сущность будем обозначать двойным прямоугольником, а ее связь с сильной сущностью линией со стрелкой:

Заметим, что кардинальность связи для сильной сущности всегда будет (1,1). Класс принадлежности и степень связи для зависимой сущности могут быть любыми. Предположим, например, что рассматриваемое нами предприятие пользуется несколькими банковскими кредитами, которые представляются набором сущностей КРЕДИТ(НОМЕР_ДОГОВОРА,СУММА, СРОК_ПОГАШЕНИЯ, БАНК). По каждому кредиту должны осуществляться выплаты процентов и платежи в счет его погашения. Этот факт представляется набором сущностей ПЛАТЕЖ(ДАТА, СУММА) и набором связей "осуществляется по". В том случае, когда получение запланированного кредита отменяется, информация о нем должна быть удалена из базы даных. Соответственно, должны быть удалены и все сведения о плановых платежах по этому кредиту. Таким образом, сущность ПЛАТЕЖ зависит от сущности КРЕДИТ.

[показать]Диаграмма "сущность-связь".

Ссылка на статью

Критерии выбора первичного ключа

[показать]Терминология

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

Суперключ (superkey). Атрибут или множество атрибутов, которое единственным образом идентифицирует кортеж данного отношения.

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

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

Потенциальный ключ К для данного отношения R обладает двумя свойствами.

Уникальность. В каждом кортеже отношения R значение ключа К единственным образом идентифицируют этот кортеж.
Неприводимость. Никакое допустимое подмножество ключа К не обладает свойством уникальности.

Отношение может иметь несколько потенциальных ключей. Если ключ состоит из нескольких атрибутов, то он называется составным ключом.

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

Первичный ключ. Потенциальный ключ, который выбран для уникальной идентификации кортежей внутри отношения.

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

Внешний ключ. Атрибут или множество атрибутов внутри отношения, которое соответствует потенциальному ключу некоторого (может быть, того же самого) отношения.

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

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

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

Источник — «http://wiki.auditory.ru/%D0%91%D0%94:%D0%9B%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%E2%84%9604»

Жизненные циклы БД