Материал: Методические указания к лабораторной работе № 1 «Автоматизированное проектирование баз данных с помощью CASE-средств». Чопоров О.Н., Разинкин К.А

ГОУВПО «Воронежский государственный технический

университет»

Кафедра технологических и автоматизированных систем

электронного машиностроения

МЕТОДИЧЕСКИЕ УКАЗАНИЯ

к лабораторной работе № 1

«Автоматизированное проектирование баз данных с помощью case-средств»

по курсам «Базы данных», «Управление данными»,

«Базы и банки данных» для студентов специальностей

230104, 230201 И направления 230200

очной формы обучения

Воронеж 2009

Составители: д-р техн. наук, проф. О.Н. Чопоров

д-р техн. наук, доц. К.А. Разинкин

канд. техн. наук В.Г. Мединцев

УДК 651.3

Методические указания к лабораторной работе № 1 «Автоматизированное проектирование баз данных с помощью CASE-средств» по курсам «Базы данных», «Управление данными», «Базы и банки данных» для студентов специальностей 230104, 230201 и направления 230200 очной формы обучения / ГОУ ВПО «Воронежский государственный технический университет»; сост. О.Н. Чопоров, К.А. Разинкин, В.Г. Мединцев. Воронеж, 2009. 27 с.

В работе рассматривается вопрос инфологического проектирования баз данных. Рассматриваются основные понятия и элементы ER-модели в нотации CASE-средства ERwin 4.0. Представлены принципы нормализации БД. Рассматривается физический уровень представления ER-модели.

Методические указания подготовлены в электронном виде в текстовом редакторе MS Word и содержатся в файле “Lab1.doc”

Ил. 9. Библиогр.: 1 назв.

Рецензент канд. техн. наук, доц. Э.И. Воробьев

Ответственный за выпуск зав. кафедрой, д-р техн. наук, проф. О.Н. Чопоров

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

© ГОУ ВПО «Воронежский

государственный технический

университет», 2009

1 Общие методические указания по выполнению лабораторной работы

1.1. Целью лабораторной работы является изучение возможностей case-средств для проектирования БД на основе выбранной предметной области. Для достижения поставленной цели необходимо решить следующие задачи:

изучить основные понятия ER-модели («сущность-связь») данных;

изучить этапы построения модели на основе ER-диаграммы;

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

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

1.2. В результате выполнения работы студенты должны знать:

основные элементы и понятия ER-модели;

три этапа разработки ER-диаграммы;

методы нормализации диаграмм;

1.3. Используемые программно-аппаратные средства: персональный компьютер стандартной конфигурации; операционная система MS Windows 2000/XP; система управления базами данных Microsoft SQL Server 2000 Developer Edition; CASE-средство Computer Associates ERwin 4.0.

1.4. В процессе выполнения лабораторных работ студент должен:

овладеть способами проектирования БД в выбранном case-средстве;

научиться выполнять автоматическое создание (экспорт) БД из case-средства в различные БД.

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

1.6. Указания по оформлению отчета

Отчет должен содержать постановку задачи, описание приемов работы с CASE-средством ERwin 4.0, СУБД SQL Server 2000, результаты выполнения работы, выводы.

1.7. Указания по сдаче зачета преподавателю

Для сдачи зачета необходимо

предъявить отчет;

ответить на контрольные вопросы.

2 Теоретический материал для домашнего изучения

2.1 Жизненный цикл программного изделия и его этапы.

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

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

• проектирование;

• кодирование (программирование);

• тестирование и отладка;

• эксплуатация и сопровождение.

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

Рассмотрим этапы подробнее.

Анализ требований является первой фазой разработки ПО, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос "Что должна делать будущая система?" Важно полно и четко определить системные требования:

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

• описание выполняемых системой функций;

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

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

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

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

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

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

2.2 Понятие структурного анализа.

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

Среди многообразия средств структурного анализа, наиболее часто и эффективно применяются являются следующие:

• DFD (Data Flow Diagrams) - диаграммы потоков данный совместно со словарями данный и спецификациями процессов или миниспецификациями;

• ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь";

• STD (State Transition Diagrams) -диаграммы переходов состояний.

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

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

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

Рис.1 Компоненты логической модели.

2.3 Основные понятия er-модели.

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

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

Рис. 2  Пример типа сущности

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

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

Связь представляется в виде ненаправленной линии, соединяющей две сущности или ведущей от сущности к ней же самой. При этом в месте «стыковки» связи с сущностью используются:

• трехточечный вход в прямоугольник сущности, если для этой сущности в связи могут (или должны) использоваться много (many) экземпляров сущности;

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

Обязательный конец связи изображается сплошной линией, а необязательный – прерывистой линией.

Связь между сущностями  БИЛЕТ и ПАССАЖИР, показанная на рис.3, связывает билеты и пассажиров. Конец связи с именем «для» позволяет связывать с одним пассажиром более одного билета, причем каждый билет должен быть связан с каким-либо пассажиром. Конец связи с именем «имеет» показывает, что каждый билет может принадлежать только одному пассажиру, причем пассажир не обязан иметь хотя бы один билет.

Рис. 3  Пример типа связи

Лаконичная устная трактовка изображенной диаграммы состоит в следующем:

• каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА;

• каждый ПАССАЖИР может иметь один или более БИЛЕТОВ.

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