Практическое занятие

Тема 5

Практическое занятие 1 (4 часа)

Цель: изучение технологии проектирования инфологических моделей баз данных с использованием современных CASE-систем.

Задачи:

· Освоить инструментальную среду PowerDesigner 10.0

· Научиться в данной среде создавать корректные модели БД

· Научиться создавать все виды ограничений (ограничения по связям, ограничения на атрибут сущности, ограничения на сущность)

· Научиться преобразовывать созданную инфологическую модель в требуемую даталогическую модель БД.

· Научиться читать и анализировать скрипты на языке DDL (Data Definition Language) по создание объектов БД и ограничений.

В качестве CASE- системы используется Power Designer 10.0 фирмы Sybase.

Оглавление.

Задание 1.Создать концептуальную модель БД «Библиотека» в среде Power Designer 10.0. 1

Задание 2. Генерация по построенной концептуальной модели даталогическую модель для MS SQL Server 2000. 15

Задание 3. Генерация скрипт создания всех объектов даталогической модели на языке SQL. 16

Задание 4. Выполнить полученный скрипт в QueryAnalizer MS SQL Server 2000 и получить вновь созданные объекты. 20

Задание 5. Генерация отчетов по концептуальной модели в Power Designer 9.0. 21

Задание 6. Разработать собственную базу данных по индивидуальному заданию, выданному преподавателем. 22

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

Внимание все результаты работы сохранять в своей сетевой папке!!!

Схема БД содержит 5 сущностей

Порядок выполнения работы:

1. Запустите программу PowerDesigner

2. Пуск -> Программы-> Sybase-> PowerDesigner

3. Нажать на крайнюю левую пиктограмму на панели инструментов и выбрать из предлагаемых режимов Conceptual Data Model (концептуальная модель данных). Подтвердить выбор, нажав кнопку «ОК».

4. При создании модели использовать встроенную панель инструментов и пиктограммы “Сущность” (Entity) и Связь (Relationship) . Для создания сущности необходимо щелкнуть левой кнопкой мыши на пиктограмме Сущность и затем, поместив указатель мыши на области диаграммы нажать левую кнопку мыши. Для задания свойств сущности необходимо сбросить режим построения сущностей, нажав правую кнопку мыши и дважды щелкнуть на сущности левой кнопкой мыши.

5. Для каждой сущности кроме имени (Name) и кода (Cod) –задать краткое описание в разделе Notes

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

При создание объектов задать корректно имена сущностей и атрибутов с учетом ограничений MS SQL Server 2000. Имена объектов в концептуальной модели ( Name ) могут быть набраны по-русски и содержать пробелы и другие недопустимые символы. Коды объектов (Code) соответствуют идентификаторам объектов в физической модели и поэтому задаются с учетом ограничений: набор символов, содержащих латинские буквы, цифры и знаки подчеркивания и не содержащий недопустимых символов, длиной не более 128.

Ориентировочные названия кодов и типов данных атрибутов модели “Библиотека ” приведены в таблице 1

Таблица 1

Описание атрибутов БД Библиотека

Name	Code	Тип данныхe	Длинаh
ISBN	ISBN	VarChar	16
Название книги	TITL	VarChar	255
Автор	AUTOR	VarChar	30
Идентификатор автора	ID_Autor	Serial
Год издания	YEARIZD	SmallInteger
Количество страниц	PAGES	SmallInteger
Инвентарный номер	INV_NUMBER	Serial
Присутствие	YES_NO	Char	1
Дата взятия книги	DATA_IN	Data
Дата возврата книги	DATA_RETURN	Data
Код области знаний	KOD_NOW	Serial
Наименование области знаний	TITLE_NOW	VarChar	50
Номер читательского билета	NUM_READER	I
Фамилия и инициалы читателя	NAME_READER	VarChar	30
Адрес	ADRES	VarChar	40
Домашний телефон	HOOM_PHONE	Char	9
Рабочий телефон	WORK_PHONE	Char	9
Дата рождения	BIRTH_DAY	Data
Фамилия	NAME	Char	30
Имя	FIST_NAME	Char	30
Отчество	OTHER_NAME	Char	20

Для поддержки кириллицы необходимо настроить фонты. Для этого выбрать в меню

Tools > general options > fonts

И там выбрать фонт с поддержкой кириллицы.

Задать все ограничения, которые требуются.

Для написания ограничений Вам могут понадобиться функции Transact SQL, описание основных функций приведено в файле TransactSQL.doc. Этот файл лежит в папке «Практика» на диске Free_access.

При описании атрибутов использовать следующие знаки:

M – обязательный

P – входит в Primary Key

D – виден в схеме (выведен в прямоугольнике с сущностью)

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

При указании типа данных для атрибута – он может быть выбран из перечня стандартных типов с использованием панели стандартных типов (кнопочка с многоточием) или комбо-бокс со списком обозначений стандартных типов.

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

MS SQL Server поддерживает инкрементный тип данных, при его описании добавляется признак Identity к типу данных. Если мы хотим сделать поле автоинкрементным, работающим по принципу «счетчика», то Вам надо выбрать тип данных Serial и не задавать ему никакой длины.

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

Для наших работ мы не будем использовать доменную архитектуру.

После создания и описания всех сущностей необходимо создать связи между ними. При описании связи мы определяем обязательность связи и ее тип. В ER-модели поддерживаются 3 типа связей

· Один к одному 1:1

· Один ко многим, 1:М

· Многие ко многим М:М

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

После создания всех связей надо перейти к созданию и описанию ограничений.

Создание ограничений

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

Ограничения для атрибута задаются с использованием кнопки: свойства. Далее Вы можете задать стандартные ограничения на значения Standard Checks (стандартные проверки) или дополнительные проверки : Additional Checks.

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

Кроме того, Вы можете задать ограничения на атрибут в виде правила, для этого надо выбрать закладку Rules

Сначала надо задать имя правила (Name), которое как и все имена объектов в концептуальной модели может быть задано на русском языке, а затем задать Code правила, который является идентификатором ограничения (constraint), которое будет генерировано на языке SQL.

Для ввода самого правила необходимо снова выбрать на панели инструментов опию «Свойства» и тогда мы попадем в редактор правил.

В основной вкладке кроме введенных ранее характеристик правила можно ввести дополнительные комментарии к правилу, но необходимо ввести тип правила. Правила бывают 4 типов:

Definition - это описание характеристик или свойств атрибута на некотором естественном языке, не формализованное описание;

Fact - описание некоторого конкретного факта, чаще всего это можно связать с некоторым значением по умолчанию.

Formula – некоторое вычисляемое значение

Requirement - спецификация, которая скорее относится к функционированию проектируемой информационной системы.

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

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

Для ввода соответствующего выражения необходимо выбрать закладку Expression. В закладке Dependencies указывается с каким атрибутом связано это правило (т. е. от кого оно зависит).

Аналогично правила могут быть связаны с целой сущностью. Для этого можно сначала ввести само правило, выбрав из верхнего меню Model > Business Rules…

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

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

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

Нажать пиктограмму «добавить» и при этом загрузится полный список правил, которые к данному моменту определены в системе.

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

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

После завершения проекта концептуальной модели, необходимо выполнить проверку данной модели. Для этого надо нажать соответствующую кнопку в панели инструментов либо выбрать опцию из меню: Tools > Check Model….

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

Если модель будет признана корректной, то далее необходимо переходить к этапу генерации физической модели БД.

Для выполнения этого этапа необходимо выбрать

Tools > Generate Physical Data Model

Вы попадаете в окно настройки режима генерации:

В основных установках Вам надо выбрать сервер БД (DBMS) ( в нашем случае это MS SQL Server 2000 ), присвоить код создаваемой физической модели и желательно изменить название будущей модели.

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

Для нашей модели там появились две новые сущности (на рисунке они окрашены зеленым цветом), которые развязали связи «многие ко многим» в концептуальной модели.

Можно проверить модель Tools > Check model

А потом необходимо сгенерировать скрипт на языке SQL, который создает все созданные нами объекты: отношения, ограничения и связи.

Для этого надо выбрать в верхнем меню Databases > Generate Database

В разделе File Name советуем задать имя, отличное от стандартного crebas, в разделе Directory указать доступный для Вас директорий, откуда Вы сможете потом считать и скопировать данный файл.

В разделе установок необходимо убрать галочку с операции создания БД

Create database, везде убрать операцию удаления объектов, в разделе Selection проверить все ли сущности и все ли правила попали к Вам в модель.

После этого нажать кнопку «Применить» и затем кнопку OK.

У Вас должно появиться окно со скриптом. Вы можете нажать кнопку Edit и попасть в режим редактирования скрипта.

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

Вы выполняете так же, как Вы писали запросы к Бд на предыдущих практических занятиях, т. е. подключаетесь к MS SQL Server, устанавливайте курсор на Вашу вновь созданную БД, переходите в Query Analyzer, загружаете подготовленный ранее скрипт и нажав на зеленый треугольных, выполняете. Если в процессе выполнения скрипта произойдут ошибки, необходимо их проанализировать, внести требуемые исправления на уровне проекта концептуальной модели БД, снова повторить действия по созданию нового скрипта. Перед тем как запускать исправленный скрипт на исполнение не забудьте удалить все созданные объекты: Вы помните, что SQL – интерпретируемый язык, поэтому все операторы, которые транслятор мог выполнить правильно - он выполнил, и какие-то объекты могли появиться в БД.

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

Нажмите новый отчет.

В нем выбрать шаблон для отчета –ReportTemplate. Выбрать можно Full conceptual Report.

После этого Вы попадаете в экран конфигурирования отчета.

В отчет обязательно включить

· схему в виде графика (diagrams)

· сущности entity

o атрибуты data item

· связи relationship

Отчет сохранить в формате rtf или html.

Для этого находясь в экране формирования отчета выбрать меню

Files > generate > RTF (например.)

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

Теперь Вам необходимо выполнить все 5 пунктов для своего индивидуального проекта. Не забудьте создать новую пустую базу данных на MS SQL Server, а затем уже приступайте к построению инфологической модели БД, созданию физической модели, описанию всех ограничений, получению скрипта и трансляции его на MS SQL Server, и, наконец, проверке всех заданных ограничений.

Вопросы для самопроверки

1. Почему в скрипте создания объектов БД присутствуют операторы Alter Table? Нельзя ли было обойтись без них?

2. Можно ли создать сущность без первичного ключа?

3. Как можно задать возможные ключи отношения?

4. Что означает буква “M”, при описании атрибутов сущности?

5. Какие дополнительные ограничения накладывает PowerDesigner при разработке ER-модели?

6. Что означает тип данных Serial? Как этот тип данных интерпретируется в СУБД MS Access, MS SQL Server?

7. Каков порядок удаления объектов из созданной БД, Может ли этот порядок быть произвольным, если не может, то почему?

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