Сикха Багуи и Ричард Ирп

Sikha Bagui and Richard Earp

Переводчики:

Жоглина Н.Ю.(стр. 3-31 )

Сковородникова Т.В.(стр. 32-57)

Матвеев С.А. (стр. 58-84)

Юденков Е.А. (стр. 85-106)

Романова А.В. (стр. 107-141 )

Федотова О.С.(стр. 142-171)

Попелышева И.А.(стр.172-199)

Холодков П. С.(стр.200-219)

Главный редактор:

Дубовицкий Е.В.

2004 год

Содержание

Глава 1. Процесс программного проектирования и реляционные базы

данных.

Глава 2. Базовая ER-диаграмма – схема построения модели данных

Глава 3. После первой диаграммы сущности

Глава 4. Расширение связей/Структурные ограничения

Глава 5. Слабая сущность

Глава 6. Дальнейшие расширения ER-диаграмм для двоичных связей

Глава 7. Троичные и ER-диаграммы более высокого порядка

Глава 8. Обобщения и специализации

Глава 9. Реляционные преобразования и обратное проектирование

ER–диаграмм

Глава 10. Краткий обзор модели Баркера

Словарь терминов

Глава 1: Процесс программного проектирования и реляционные базы данных.

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

Что такое процесс программного проектирования?

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

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

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

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

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

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

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

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

Среди разработчиков нет общего соглашения о точном числе шагов или фаз при моделировании методом «водопада». Модели варьируются, в зависимости от заинтересованности автора в той или иной части процесса. Вот как выглядит краткое примерное описание процесса программного проектирования:

Шаг 1 (или Фаза 1): Требования.Определение желаний или требований пользователя.

Шаг 2: Спецификация. Максимально точное описание желаний или требований пользователя.

Шаг 2a:Согласование спецификации с пользователем для проверки правильности понимания задачи аналитиком (Вами).

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

Шаг 3: Разработка программы, соответствующей спецификации, начиная с шага 2.

Шаг 3a:Программный проект снова независимо сверяется со спецификациейи корректируется аналитиком, до полного соответствия спецификации.Отметим значимость соглашения на этапе 2 и использование шага 2 в качестве основы для дальнейших действий. На 3 этапе возвращение наверх «водопада» затруднительно – в этом заключается особенность данного метода.

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

Шаг 4:Программа написана (разработана).

Шаг 4a: Как только программное обеспечение написано, оно снова сверяется с проектом, до тех пор, пока аналитик не приведет его в полное соответствие с проектом. Отметим, что спецификация на этапе 2 давно завершена, и здесь допустимы только незначительные изменения проекта.

Шаг 5:Программное обеспечение предлагается пользователю в виде приложения.

Шаг 5a: Потребитель тестирует программу и принимает ее, или не принимает до тех пор, пока она не будет корректно написана(это относится к спецификации и проекту).

Шаг 6:Эксплуатация и техническое обслуживаниепрограммы происходит до тех пор, пока она не будет «утилизирована».

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

ER диаграммы и жизненный цикл программного проектирования

В данном разделе подробно описаны этапы с 1 по 3 жизненного цикла программы, предназначенной для моделирования баз данных. База данных является совокупностью связанных данных. Понятие связанных данных означает, что база данных содержит информацию о некотором предприятии - бизнесе, организации, группе связанных людей или процессов. Например, может быть база данных организации Acme Plumbing, включающая данные о клиентах и продукции. Другая база данных может быть об участниках и деятельности клуба «Over 55 Club» («кому за 55») города. Бессмысленно хранить данные о «Over 55 Club» и Acme Plumbing в одной и той же базе данных, поскольку эти две организации не связаны. А база данных является совокупностью связанныхданных.

Системы баз данных часто моделируют, используя диаграммы сущность-связь (ER) в качестве «плана», содержащего фактические данные – результат фазы проектирования. ER диаграмма – средство, с помощью которого аналитик может схематично представить данные, содержащиеся в информационной системе. Шаг 1, фаза требований, может быть необязательным, так как аналитик должен выявлять нужды и требования пользователя.

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

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

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

Начальные шаги программного проектирования таковы:

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

Шаг 2. Спецификация базы данных.Этот шаг включает грамматические описания и диаграммы того, что, по мнению аналитика, хочет потребитель. Поскольку большинство пользователей не знакомы с понятием диаграммы Entity - Relationship (ERD) (Сущность-Связь), наша методология будет дополнять модель ERD грамматическими описаниями того, что предположительно будет содержаться в базе данных, и как будут взаимосвязаны части базы данных. Часто, техническое описание базы данных - сухое и для пользователя не интересно; однако, когда аналитик формулирует свои мысли по поводу информации, полученной от пользователя, в виде утверждений, между ним и пользователем происходит дискуссия. Например, если аналитик применяет такую формулировку, как, например: «Все служащие должны составлять счета», потребитель может подтвердить, опровергнуть, или изменить описание в зависимости от обстоятельств.

Шаг 3: Проектирование базы данных.После представления базы данных в виде диаграммы и ее окончательном согласовании, ERD будет являться планом для разработки базы данных.