Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

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

«АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ

БАЗ ДАННЫХ С ПОМОЩЬЮ CASE-СРЕДСТВ»

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

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

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

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

Воронеж 2009г.

Методические указания к лабораторной работе № 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-модели являются сущность, связь и атрибут. Сущность - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступной.http://www.intuit.ru/department/database/rdbintro/9/footnote.2.1.htm В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности - это имя типа, а не некоторого конкретного экземпляра этого типа. Для большей выразительности и лучшего понимания имя сущности может сопровождаться примерами конкретных экземпляров этого типа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4 Уникальные идентификаторы типов сущности

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

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

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

На рис. 5 показан тип сущности КНИГА, пригодный для использования в базе данных книжного склада. При издании любой книги в любом издательстве (кроме пиратских, которыми мы для простоты пренебрежем) ей присваивается уникальный номер - ISBN. Понятно, что значение атрибута isbn будет уникально идентифицировать партию книг на складе. Кроме того, конечно, в качестве уникального идентификатора годится и комбинация атрибутов <автор, название, номер издания, издательство, год издания.

Рис. 5 Тип сущности, экземпляры которого идентифицируются атрибутами

На рис. 6 диаграмма включает два связанных типа сущности. У каждого взрослого человека имеется один и только один паспорт (мы снова не берем в расчет особый случай, когда у одного человека имеется несколько паспортов), и каждый паспорт может принадлежать только одному взрослому человеку (некоторые уже готовые паспорта могут быть еще никому не выданы). Тогда связь человека с его паспортом (конец связи ИМЕЕТ) уникально идентифицирует взрослого человека, т. е., грубо говоря, паспорт определяет взрослого человека. Поскольку могут существовать паспорта, еще не выданные какому-либо человеку, эта связь не является уникальным идентификатором сущности ПАСПОРТ.

Рис. 6 Тип сущности, экземпляры которого идентифицируются связью

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

Другими словами, между сущностями ПРОФЕССОР и ДИСЦИПЛИНА определена связь «многие ко многим». Каждый профессор может готовить курсы по любой доступной ему дисциплине. Каждой дисциплине может быть посвящено несколько учебных курсов. Но каждый профессор может готовить только один курс по любой доступной ему дисциплине, и каждый курс может быть посвящен только одной дисциплине. Тем самым, каждый экземпляр типа сущности КУРС уникально идентифицируется экземпляром сущности ПРОФЕССОР и экземпляром сущности ДИСЦИПЛИНА, т. е. парой связей с именами концов ГОТОВИТСЯ и ПОСВЯЩЕН на стороне сущности КУРС. Заметим, что сущности ПРОФЕССОР и ДИСЦИПЛИНА связями не идентифицируются.

На рис. 8 приведен пример типа сущности, уникальный идентификатор которого является комбинацией атрибутов и связей. Это несколько уточненный вариант сущности с рекурсивной связью. У каждого человека могут быть дети, и у каждого человека имеется отец. Тогда, если предположить, что близнецам, появившимся на свет одновременно, не дают одинаковых имен, то уникальным идентификатором типа сущности ЧЕЛОВЕК может быть комбинация атрибутов <дата рождения, ФИО> и связь с именем конца РЕБЕНОК.

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

программный идентификатор база данные



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

2.6 Построение модели

Разработка ERD включает следующие основные этапы:

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

2. Идентификация отношений между сущностями и указание типов отношений

3. Разрешение неспецифических отношений (отношений n*m - "многие ко многим")

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

Следующий шаг - упрощение схемы при помощи нормализации.

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

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

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

Рис. 9 Алгоритм приведения ненормализованной схемы в 3НФ

На практике отношения 1НФ и 2НФ имеют тенденцию возникать при попытке описать несколько реальный сущностей в одной схеме (заказ, книга, проект и сотрудник).

Этап 2 служит для выявления и определения отношений между сущностями, а также для идентификации типов отношений. На данном этапе некоторые отношения могут быть неспецифическими (n*m - многие ко многим). Такие отношения потребуют дальнейшей детализации на этапе 3.

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

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

2.7 Построение моделей в ERwin

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

ERwin предоставляет возможности создавать и управлять этими двумя различными уровнями представления одной диаграммы (модели), равно как и иметь много вариантов отображения на каждом уровне. Термин "логический уровень" в ERwin соответствует концептуальной модели.

Этапы построения информационной модели:

· определение сущностей;

· определение зависимостей между сущностями;

· задание первичных и альтернативных ключей;

· определение атрибутов сущностей;

· приведение модели к требуемому уровню нормальной формы;

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

· задание триггеров, процедур и ограничений;

· генерация базы данных.

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

2.7.1 Создание сущности

Для внесения сущности в модель необходимо щелкнуть по кнопке сущности на панели инструментов (Erwin Toolbox) , затем - по тому месту на диаграмме, где необходимо расположить новую сущность. Щелкнув правой кнопкой мыши по сущности и выбрав из всплывающего меню пункт Entity Editor, можно вызвать диалог Entity Editor, в котором определяются имя, описание и комментарии сущности.

Каждая сущность должна быть полностью определена с помощью текстового описания в закладке Definition. Эти определения полезны как на логическом уровне, поскольку позволяют понять, что это за объект, так и на физическом уровне, поскольку их можно экспортировать как часть схемы и использовать в реальной БД (CREATE COMMENT on entity_name). Закладки Note, Note2, Note3, UDP (User Defined Properties - Свойства, определенные пользователем) служат для внесения дополнительных комментариев и определений к сущности. В закладке Icon каждой сущности можно поставить в соответствие изображение, которое будет отображаться в режиме просмотра модели на уровне иконок и изображение, которое будет отображаться на всех других уровнях.

Закладка UDP диалога Entity Editor служит для определения свойств, определяемых пользователем (User - Defined Properties). При нажатии на кнопку этой закладки вызывается диалог User - Defined Property Editor (также вызывается из меню Edit/UDPs). В нем необходимо указать вид объекта, для которого заводится UDP (диаграмма в целом, сущность, атрибут и т.д.) и тип данных. Для внесения нового свойства следует щелкнуть в таблице по кнопке и внести имя, тип данных, значение по умолчанию и определение.

2.7.2 Создание атрибутов

Для описания атрибутов следует, щелкнув правой кнопкой по сущности, выбрать в появившемся меню пункт Attribute Editor. Появится диалог Attribute Editor.

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

Для атрибутов первичного ключа в закладке General диалога Attribute Editor необходимо сделать пометку в окне выбора Primary Key. Закладки Definition, Note и UDP несут те же функции, что и при определении сущности, но на уровне атрибутов. Для большей наглядности диаграммы каждый атрибут можно связать с иконкой. Это можно сделать при помощи списка выбора Icon в закладке General. Очень важно дать атрибуту правильное имя. Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение. Согласно синтаксису IDEF1X, имя атрибута должно быть уникальным в рамках модели (а не только в рамках сущности!). По умолчанию при попытке внесения уже существующего имени атрибута ERwin переименовывает его. Например, если атрибут Комментарий уже существует в модели, другой атрибут (в другой сущности) будет назван Комментарий/2, затем Комментарий/3 и т.д. При переносе атрибутов внутри и между сущностями можно воспользоваться техникой drag&drop, выбрав кнопку в палитре инструментов.

2.7.3 Создание связи

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

В закладке General появившегося диалога можно задать мощность, имя и тип связи. Мощность связи (Cardinality) - служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней. Различают четыре типа мощности:

· общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности, не помечается каким-либо символом;

· символом P помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);

· символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);

· цифрой помечается случай, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.

По умолчанию символ, обозначающий мощность связи, не показывается на диаграмме. Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Relationship и затем включить опцию Cardinality.

Тип связи (идентифицирующая/неидентифицирующая). В IDEF1X различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю связь в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами.

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

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

Для неидентифицирующей связи можно указать обязательность (Nulls в закладке General диалога Relationship Editor). В случае обязательной связи (No Nulls) при генерации схемы БД атрибут внешнего ключа получит признак NOT NULL, несмотря на то, что внешний ключ не войдет в состав первичного ключа дочерней сущности. В случае необязательной связи (Nulls Allowed) внешний ключ может принимать значение NULL. Необязательная неидентифицирующая связь помечается прозрачным ромбом со стороны родительской сущности.

Имя связи (Verb Phrase) - фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи один-ко-многим идентифицирующей или неидентифицирующей достаточно указать имя, характеризующей отношение от родительской к дочерней сущности (Parent-to-Child). Для связи многие-ко-многим следует указывать имена как Parent-to-Child, так и Child-to-Parent. Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Relationship и затем включить опцию Verb Phrase.

Имя роли или функциональное имя (Rolename) - это синоним атрибута внешнего ключа, который показывает, какую роль играет атрибут в дочерней сущности. Задать имя роли можно в закладке Rolename/RI Actions диалога Relationship Editor.

Правила ссылочной целостности (Referential Integrity (RI)) - логические конструкции, которые выражают бизнес-правила использования данных и представляют собой правила вставки, замены и удаления. Задать правила ссылочной целостности можно в закладке Rolename/RI Actions диалога Relationship Editor. При генерации схемы БД на основе опций логической модели будут сгенерированы правила декларативной ссылочной целостности, которые должны быть предписаны для каждой связи, и триггеры, обеспечивающие ссылочную целостность.

Связь многие-ко-многим возможна только на уровне логической модели данных. Такая связь обозначается сплошной линией с двумя точками на концах. Связь многие-ко-многим должна именоваться (Verb Phrase) двумя фразами - в обе стороны. Это облегчает чтение диаграммы. Для разрешения неспецифического отношения многие-ко-многим надо использовать кнопку - many to many transform. При этом каждое неспецифическое отношение преобразуется в два специфических отношения с введением новых сущностей.

2.7.4 Создание ключей

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

Первичный ключ (primary key) - это атрибут или группа атрибутов, однозначно идентифицирующие экземпляр сущности. Атрибуты первичного ключа на диаграмме не требуют специального обозначения - это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии. При внесении нового атрибута в диалоге Attribute Editor для того, чтобы сделать его атрибутом первичного ключа, нужно включить флажок Primary Key в нижней части закладки General. На диаграмме ключевой атрибут можно внести в состав первичного ключа, воспользовавшись режимом переноса атрибутов (кнопка в палитре инструментов).

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

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

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

Альтернативный ключ (Alternative Key) - это потенциальный ключ, не ставший первичным.

Каждому ключу соответствует индекс, имя которого также присваивается автоматически. Имена ключа и индекса при желании можно изменить вручную.

На диаграмме атрибуты альтернативных ключей обозначаются как (Akn.m.), где n - порядковый номер ключа, m - порядковый номер атрибута в ключе. Когда альтернативный ключ содержит несколько атрибутов, (Akn.m.) ставится после каждого.

Внешние ключи (Foreign Key) создаются автоматически, когда связь соединяет сущности: связи образуют ссылку на атрибуты первичного ключа в дочерней сущности и эти атрибуты образуют внешний ключ в дочерней сущности (миграция ключа). Атрибуты внешнего ключа обозначаются символом (FK) после своего имени. Зависимая сущность может иметь один и тот же ключ из нескольких родительских сущностей. Сущность может также получить один и тот же внешний ключ несколько раз от одного и того же родителя через несколько разных связей. Когда ERwin обнаруживает одно из этих событий, он распознает, что два атрибута одинаковы, и помещает атрибуты внешнего ключа в зависимой сущности только один раз. Это комбинирование или объединение идентичных атрибутов называется унификацией. Есть случаи, когда унификация нежелательна. Например, когда два атрибута имеют одинаковые имена, но на самом деле они отличаются по смыслу, и необходимо, что бы это отличие отражалось в диаграмме. В этом случае необходимо использовать имена ролей внешнего ключа.

2.8 Физический уровень представления БД

Физический уровень представления модели зависит от выбранного сервера. Для выбора СУБД служит редактор Target Server (меню Server/Target Server... доступно только на физическом уровне). ERwin поддерживает практически все распространенные СУБД, всего более 20 реляционных и нереляционных БД. Диалог Target Server позволяет задать тип данных и опцию NULL для новых колонок, а также правила ссылочной целостности, принимаемые по умолчанию. Группа кнопок Default Non-Key Null Option позволяет разрешить или запретить значения NULL для неключевых колонок.

По умолчанию ERwin генерирует имена таблиц и индексов по шаблону на основе имен соответствующих сущностей и ключей логической модели. Окна Table Name Macro и Index Name Macro позволяют изменить шаблон генерации имен. Кнопка Reset Names вызывает диалог Globally Reset DBMS Property, который позволяет заменить все имена таблиц, связей, индексов, колонок и соответствующих свойств, заданных вручную, на значения по умолчанию. Имена таблиц и колонок по умолчанию будут сгенерированы на основе имен сущностей и атрибутов логической модели. Если в имени сущности или атрибута встречается пробел, он будет заменен на символ "_". При смене СУБД ERwin предлагает автоматически преобразовать тип данных, связанный с каждым атрибутом, на ближайший, доступный для новой СУБД.

2.8.1 Прямое и обратное проектирование

Процесс генерации физической схемы БД из логической модели данных называется прямым проектированием (Forward Engineering). При генерации физической схемы ERwin включает триггеры ссылочной целостности, хра-нимые процедуры, индексы, ограничения и другие возможности, доступ-ные при определении таблиц в выбранной СУБД.

Процесс генерации логической модели из физической БД называется обратным проектированием (Reverse Engineering). ERwin позволяет создать модель данных путем обрат-ного проектирования имеющейся БД. После того как модель создана, мож-но переключиться на другой сервер (модель будет конвертирована) и про-извести прямое проектирование структуры БД для другой СУБД. Кроме режима прямого и обратного проектирования ERwin поддерживает синхронизацию между логической моделью и системным каталогом СУБД на протяжении всего жизненного цикла создания ИС.

Для генерации системного каталога БД следует выбрать пункт меню Tasks/Forward Engineer/Schema Generation или нажать кнопку на панели инструментов. Появляется диалог Schema Generation.

Диалог Schema Generation имеет три закладки:

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

В закладке Summary отображаются все опции, заданные в закладке Options. Список опций в Summary можно редактировать так же, как и в Options.

Comment. Позволяет внести комментарий для каждого набора опций. Каждый набор опций может быть именован (окно Option Set, кнопки New, Rename и Delete) и использован многократно.

Кнопка Preview вызывает диалог Schema Generation Preview, в котором отображается SQL-скрипт, создаваемый ERwin для генерации системного каталога СУБД. Нажатие на кнопку Generate приведет к запус-ку процесса генерации схемы.

Кнопка Print предназначена для вывода на печать создаваемого ERwin SQL-скрипта.

Кнопка Report сохраняет тот же скрипт в ERS или SQL текстовом файле. Эти команды можно в дальнейшем редактировать любым текстовым редактором и выполнять при помощи соответствующей утилиты сервера.

Кнопка Generate запускает процесс генерации схемы. Возникает диалог связи с БД, устанавливается сеанс связи с сервером и начинает выполняться SQL-скрипт. При этом возникает диалог Generate Database Schema. Для выполнения обратного проектирования следует выбрать пункт меню Tasks/Reverse Engineer. При этом возникает диалог ERwin Template Selection, в ко-тором нужно выбрать шаблон диаграммы, затем диалог выбора СУБД и, наконец, диалог задания опций обратного проектирования Reverse Engineer - Set Options.

В диалоге Reverse Engineer - Set Options можно задать следующие опции:

Группа Reverse Engineer From позволяет задать источник обратного проектирования - БД или SQL(DDL)-скрипт. При помощи кнопки Browse можно выбрать текстовый файл, содержащий SQL-скрипт.

Группа Items to Reverse Engineer позволяет задать объекты БД, на основе которых будет создана модель. При помощи списка выбора Option Set, a также кнопок New, Update и Delete можно создавать и редактировать име-нованные конфигурации объектов БД, которые могут быть использованы многократно при других сеансах обратного проектирования.

Группа Reverse Engineer (доступна только при обратном проектировании из БД) позволяет включить в модель системные объекты (окно выбора System Objects) и установить фильтр на извлекаемые таблицы по их владельцу. В процессе работы модель может изменяться и дополняться. С другой стороны, системный каталог БД может редактироваться другими проектировщиками. В результате спустя некоторое время после последнего сеанса обратного проектирования могут возникнуть расхождения между реальным состоянием системного каталога и моделью данных.

Для синхронизации системного каталога БД и текущей модели следует выбрать пункт меню Tasks/Complete Compare или нажать кнопку на панели инструментов.

Возникает диалог Complete Compare - Set Options, который во многом похож на описанный выше диалог Reverse Engineer-Set Options. Разница заключается в том, что в отличие от обратного проек-тирования сравнивать текущую модель можно не только с БД или SQL-скриптом, но и с другой моделью ERwin, хранящейся в файле или репозитории ModelMart.

3. ДОМАШНЕЕ ЗАДАНИЕ

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

4 МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО ВЫПОЛНЕНИЮ ЛАБОРАТОРНОЙ РАБОТЫ

1. Разработать и построить диаграмму по базе данных с учетом особенностей проектирования.

2. Выполнить автоматическое создание (экспорт) БД из case-средства ERwin в СУБД SQL Server 2000.

5. КОНТРОЛЬНЫЕ ВОПРОСЫ

1. Что такое диаграмма "сущность-связь" (ERD), ее основные элементы, типы связей.

2. Что является уникальными идентификаторами типов сущности.

3. В чем заключается нормализация ER-диаграмм.

4. Каково назначение пакета ERwin и его основные функции?

5. Опишите этапы построения информационной модели.

6. Как устранить неспецифические отношения "многие ко многим"? Что при этом происходит?

7. Из каких элементов состоит диаграмма "сущность-связь" в Erwin? Их особенности.

8. Какие типы ключей используются в пакете ERwin, каково их назначение?

9. Какой смысл в прямом и обратном проектировании базы данных? Что создается в результате этих процессов?

6. ВАРИАНТЫ ЗАДАНИЙ

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

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

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

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

5. Создать БД, содержащую информацию о компьютерах: наименование, фирма, страна, оборот фирмы, служба поддержки и рейтинг фирмы, стоимость компьютера, модель процессора, объем ОЗУ, тип НЖМД, покупатель компьютера, место жительства и телефон покупателя.

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

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

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

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

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

7. СПИСОК ЛИТЕРАТУРЫ

1. Гарсиа М., Рединг Дж., Уолен Э., ДеЛюк С. Microsoft SQL Server 2000. Справочник администратора. 2-е изд. : Пер. с англ. - М.: СП ЭКОМ, 2004.

Размещено на Allbest.ru