Содержание

• 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-модель).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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