Erwin методичка

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РЕСПУБЛИКИ БЕЛАРУСЬ

УО «Белорусский государственный экономический университет»

Оскерко В. С.

МОДЕЛИРОВАНИЕ БАЗ ДАННЫХ В СРЕДЕ ERwin

Учебно-методическое пособие

Минск 2011

2

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

……………………… 2

1.ОБЩИЕ СВЕДЕНИЯ О CASE- ……………………… 3

СРЕДСТВЕ ERwin

2.ОСНОВНЫЕ ПОНЯТИЯ, НЕОБХО- ……………………… 5 ДИМЫЕ ДЛЯ РАБОТЫ В ERwin

3. ИНТЕРФЕЙС ERwin

………………………

7

3.1. Описание системы меню

………………………

7

3.2. Описание панелей инструментов

………………………

10

4.МОДЕЛИРОВАНИЕ СТРУКТУРЫ БА- ……………………… 13 ЗЫ ДАННЫХ В СРЕДЕ ERwin

5. ИНДИВИДУАЛЬНЫЕ ЗАДАНИЯ ДЛЯ

33

МОДЕЛИРОВАНИЯ БАЫ ДАННЫХ В

СРЕДЕ ERwin

ПРИЛОЖЕНИЕ

………………………

48

ЛИТЕРАТУРА

………………………

49

ВВЕДЕНИЕ

Данное пособие разработано в методическую поддержку темы «Проектирование базы данных» в разделе «Технологии баз данных и знаний» курса «Компьютерные информационные технологии». Оно преследует цель – ознакомить студентов с инструментальным средством автоматизированного моделирования баз данных ERwin. В пособии приводятся краткие теоретические сведения об этом CASE-средстве и комплекс заданий по освоению его возможностей, предназначенный для выполнения на лабораторных занятиях.

3

1. ОБЩИЕ СВЕДЕНИЯ О CASE-СРЕДСТВЕ ERwin

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

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

С развитием компьютерных технологий появились инструментальные средства для автоматизированного моделирования реляционных БД на основе

ER-моделей, относящиеся к CASE-средствам (Computer Aided Software Engineering). Их достоинством является то, что они позволяют разработчику сконцентрироваться на самом моделировании, а не на проблемах с графическим отображением ER-диаграмм. Они имеют развитые и простые в управлении средства создания различных представлений модели БД и их визуализации.

Лидером на рынке инструментов моделирования БД является продукт

Computer Associates AllFussion Data Modeler (ERwin). Существует несколько модификаций ERwin. В пособии рассматривается версия ERwin 4.1. Это мощное средство для разработки структуры данных в различных предметных областях как на логическом, так и на физическом уровнях.

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

4

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

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

ERwin поддерживает также автоматическую генерацию физической модели БД – создание структуры данных в среде многих настольных и серверных СУБД.

Богаты возможности ERwin по редактированию и дизайну моделей БД. ERwin интегрирован с генератором отчетов и позволяет получать под-

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

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

ВERwin возможно моделирование структуры БД по стандарту IE и стандарту IDEF1X. Наиболее распространенным стандартом для создания моделей БД является стандарт IDEF1X. Стандарт IDEF1X – это регламентация разработки структуры БД с нуля (прямого моделирования БД).

ERwin располагает средствами для коллективной разработки модели БД. Перечисленные инструменты ERwin помогают: свести рутинный труд разработчика к минимуму; снизить потери времени, которые обычно происходят при согласовании моделей БД со специалистами предметной области; об-

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

5

2. ОСНОВНЫЕ ПОНЯТИЯ, НЕОБХОДИМЫЕ ДЛЯ РАБОТЫ В ERwin

Сущность – объект реального мира, информация о котором должна храниться в БД. Сущность имеет множество атрибутов.

Атрибут – свойство сущности.

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

Связь – отношение сущностей, определяющееся взаимодействием объектов реального мира.

Диаграмма «сущность-связь» (ER-диаграмма) – графическое изображение связи междудвумя сущностями.

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

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

Родительская сущность (независимая сущность) – сущность, из которой исходит связь.

Дочерняя сущность (зависимая сущность) – сущность, с которой связывается родительская сущность.

Родительская сущность изображается прямоугольником, а дочерняя – прямо-

угольником со скругленными углами.

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

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

6

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

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

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

Различают четыре типа мощности:

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

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

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

ся символом Z;

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

Уровни отображения ER-диаграммы:

уровень сущностей. Внутри прямоугольников отображается имя сущности (для логической модели) или имя таблицы (для физической модели). Cлужит для удобства обзора большой модели;

7

уровень определений. Приводятся определения сущностей. Служит для презентации диаграммы другим людям;

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

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

уровень иконок. Сущностям ставятся в соответствие иконки. Служит для презентационных целей.

3.ИНТЕРФЕЙС ERwin

3.1.Описание системы меню

FILE

ФАЙЛ

New

Новый

Open

Открыть

Close

Закрыть

Save

Сохранить

Save as

Сохранить Как

Save as New Model Сохранить как новую модель

Import

Импорт

Export

Экспорт

Print

Печать

Print setup

Настройка Печати

Exit

Выход

Zoom

Приближение

Zoom In – увеличение

VIEW

ВИД

Подменю

Redraw dia-

Нарисовать диаграмму

Zoom Out – уменьшение

No Magnification – без

gram

Инструменты

изменения

ToolBars

Fit Model – исправить

Model Explorer

Поиск модели

модель

Stored Display

Показать границузоны разра-

Tabs

ботки таблицы

Select Restangle to Fit –

выбрать фигуру

Status Bar

Панель статуса

8

EDIT

РЕДАКТИРОВАТЬ

Cut

Вырезать

Copy

Копировать

Paste

Вставить

Select All

Выбрать Все

Go To

Перейти К

FORMAT

ФОРМАТ

Подменю

Display Level

Уровни ото-

Entity – Cущность

бражения

Attribute – Атрибут

Primary Key – Первичный ключ

Definition – Определения

Icon – Иконка

Entity Display

Сущности

Rolename/Attribute – Имя/Атрибут

Attribute Datatype – Типданных атрибута

Attribute Domain – Домен атрибута

Primary Key Designator – Отображение пер-

вичных ключей

Foreign Key Designator – Отображение внеш-

них ключей

Alternate Key Designator – Отображение аль-

тернативных ключей

Attribute Icon – Иконка атрибута

Entity Icon – Иконка сущности

Show Migrated Attributes – Показать изме-

ненные атрибуты

Relationship

Панель связи

Verb Phrase – Название связи

Display

Cardinality – Мощностьсвязи

Referential Integrity – Ограничения целостно-

сти

Show Dangling Relationships – Показатьоши-

бочные отношения

Orthogonal Lines – Ортогональные связи

Diagonal Lines – Диагональные связи

Stored Display

Настройка

Settings

дисплея (ото-

бражения)

Preferences

Предпочтения

Default Fonts

Панельцвето-

& Colors

вогооформ-

9

ления

Align or Space

Выравнивание

Align top – Вверх

Evenly

Align Bottom – Вниз

Align Left – Влево

Align Right – Вправо

Space Verticaly – промежуток по вертикали

Space Horizontaly – промежуток по горизон-

тали

Show Shad-

Показать Тени

ows

Show Page

Показать Сет-

Grid

ку

MODEL

МОДЕЛЬ

Subject Area

Областьразработки

Entities

Сущности

Attributes

Атрибуты

Relationships

Связи

Key Groups

Ключевые атрибуты

Domain Dictionary

Набор доменов

Validation Rules

Правила подтверждения

Default Values

Настройки по умолчанию

UDP Dictionary

Словарь UDP

Model Sources

Ресурсы моделей

Model Properties

Свойства модели

TOOLS

ИНСТРУМЕНТЫ

Подменю

Reverse Engineer

Мастер изменений

Complete Com-

Сделать сравнение

pare

Add model

Добавить ресурсы модели

Source

Syncwith Model

Соединиться с ресурсами

Source

модели

Derive New

Вывести новую модель

Model

Report Builder

Построитель отчета

Data Browser

Браузер данных

Names

Имена

Model Naming Options– Оп-

ции имен моделей

Edit Naming Standarts – Из-

менить стандартыимен

Check Standarts Compliance

10

Проверитьсоответствие стан-

дартам

Datatypes

Типы данных

Model Datatype Options

Модель типических опций

Edit Datatypes Standarts

ИзменитьСтандарты типов

данных

Add-Ins

Включить/Выключить?

Customize – выполнить по из-

вестным настройкам

WINDOW

ОКНА

Cascade

Каскадом

Tile Horizontal

Горизонтальная сетка

Tile Vertical

Вертикальная сетка

HELP

СПРАВКА

Help Topics

Темы справки

Tutorial

Туториал

What’s New

Что Нового?

How to UseHelp

Как использовать Справку

About ERwin

О программе ERwin

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

3.2.Описание панелей инструментов

1)Standart ToolBar стандартный набор инструментов. Вид данной панели:

— Сreate model (Создатьмодель)

— Open model (Открыть модель)

— Save model (Сохранить модель)

— Print (Печать)

— Data Browser (Информационный браузер)

— Report TemplateBuilder ( Публикация отчета)

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #

Подборка по базе: К выходным параметрам моделирования в системе.docx, ПП-Отчет пример.docx, Введение в компьютерное моделирование.pdf, Лекция 9 Материалы и металлы, применяемые для проектирования.Пу, Порядок проведения (1).docx, Деформация кручение лекция, пример решения.docx, Методы и средства обратного проектирования.docx, Анализ требований обновлённого ФГОС НОО_ Проект содержания Приме, Лабораторная работа №4 «Изучение искусственных сообществ и их об, График проведения СОР и СОЧ (копия).docx


ERwin — средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress, Interbase и др.) и реинжиниринг существующей БД.

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

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

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

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

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

Запуск программы и создание новой модели.

После запуска программы ERwin в появившемся диалоге нужно выбрать пункт «Create model» (Создать модель). После этого появляется диалог, при помощи которого задаются свойства новой модели. Необходимо выбрать тип новой модели (New Model Type) – Logical/Physical, т.е. будет создаваться как логический уровень модели так и ее физическое описание. Также нужно задать вид базы данных (Target Database), для которой будет проведена генерация базы данных – необходимо выбрать InterBase.

Рисунок 10

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

Для внесения сущности в модель необходимо щелкнуть по кнопке сущности на панели инструментов (Erwin Toolbox) . Имя сущности по умолчанию будет «E/1», поменять его можно щелкнув на заголовке и введя новое имя с клавиатуры. Введем имя «Авиамаршрут». Таким же образом вставьте в диаграмму сущности «Рейс», «Член Экипажа», «Личность», «Авиакомпания», и других из модели рассмотренной в предыдущей главе.

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

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

Если щелкнуть по кнопке New, то в появившемся диалоге New Attribute можно указать имя атрибута, имя соответствующей ему в физической модели колонки и домен. Домен атрибута будет использоваться при определении типа колонки на уровне физической модели. При проектировании необходимо представлять, какой тип должен выбираться для каждого атрибута сущности, если атрибут должен представлять текстовую информацию – выбираем «String», если цифровую, то — «Number», если информацию о времени или дате (или о том и другом сразу) то «Datetime», и наконец тип «Blob» используется если информация имеет неструктурированный характер (например текст произвольной длины или изображение).
Для атрибутов первичного ключа в закладке General диалога Attribute Editor необходимо поставить флажок Primary Key.

Очень важно дать атрибуту правильное имя, которое должно записываться в поле «Attribute Name» (Имя Атрибута). Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение.

Согласно синтаксису IDEF1X, имя атрибута должно быть уникальным в рамках модели (а не только в рамках сущности!).


Рисунок 11 Создание атрибута

InterBase не допускает символов кириллицы в именах объектов метаданных. Поэтому нам необходимо изменить имена для физического представления атрибутов, которые должны записываться в поле «Column Name» (имя колонки). Имя колонки может содержать только латинские буквы, цифры и символ подчеркивания, рекомендуется использовать только буквы в верхнем регистре, пробелы в имени не допустимы.

Для систематизации имен колонок рекомендуется использовать единые правила их именования, например, сначала должен следовать префикс, показывающий какой таблице принадлежит эта колонка, затем символ подчеркивания, и, наконец, собственно смысловое имя. Так для атрибута «Код Города» имя колонки будет «CT_CODE», префикс CT от имени таблицы «CITY» (Город).

При переносе атрибутов внутри и между сущностями можно воспользоваться техникой drag&drop, выбрав кнопку в палитре инструментов.

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

После того как определены все сущности, необходимо задать связи между ними. Связь в ERwin трактуется как функциональная зависимость между двумя сущностями. Если рассматривать диаграмму как графическое изображение предметной области, то сущности являются существительными, а связи — глаголами. Например, между сущностями «ГОРОД» и «АЭРОПОРТ» имеет место связь «находиться в».

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

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

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

В закладке General появившегося диалога можно задать мощность, имя и тип связи.

Мощность связи (Cardinality) — служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.

Различают четыре типа мощности:

  • общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности, не помечается каким-либо символом;
  • символом P помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение). (В нашем случае такую мощность имеет смысл проставить для отношения АВИАКОМПАНИЯБОРТ, что означает, что у авиакомпании есть хотя бы один самолет);
  • символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);
  • цифрой помечается случай, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.












Рисунок 12 Панель задания мощности отношения

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

Тип связи (идентифицирующая/неидентифицирующая).

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

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

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

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

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

Имя связи (Verb Phrase) — фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи один-ко-многим идентифицирующей или неидентифицирующей достаточно указать имя, характеризующей отношение от родительской к дочерней сущности (Parent-to-Child). (Например, для отношения АВИАКОМПАНИЯБОРТ имя, характеризующей отношение от родительской к дочерней сущности будет «Имеет», а для отношения Child-to-Parent (Потомок — Родитель) – «Принадлежит»).



Рисунок 13. Панель задания имени связи

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

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


Рисунок 14 Панель задания имени роли


Рисунок 15 Случай обязательности имен ролей

В примере, приведенном на рис.15, в сущности ТАРИФ внешний ключ «Код аэропорта» имеет имя роли «Аэропорт Откуда», которое показывает, какую роль играет этот атрибут в сущности. По умолчанию в списке атрибутов показывается только имя роли. Для отображения полного имени атрибута (как функционального имени, так и имени роли) следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Entities и затем включить опцию Rolename/Attribute. Полное имя показывается как функциональное имя и базовое имя, разделенные точкой

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

Сущности АЭРОПОРТ и ТАРИФ должны быть связаны дважды, и первичный ключ — «Код аэропорта» должен дважды мигрировать в сущность ТАРИФ в качестве внешнего ключа. Необходимо различать эти атрибуты, которые содержат информацию о аэропорте откуда (и куда) проложен маршрут, т.е. атрибуты имеют разный смысл, но ссылаются на одну и ту же сущность ТАРИФ. В примере на рис.15 атрибуты получили имена ролей «Аэропорт Откуда» и «Аэропорт Куда».

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

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

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

Для каждой связи могут быть заданы требования по обработке операций INSERT/UPDATE/DELETE для родительской и дочерней сущности. ERwin предоставляет следующие варианты обработки этих событий:

  • отсутствие проверки (NONE);
  • проверка допустимости (SET NULL);
  • запрет операции (RESTRICT);
  • каскадное выполнение операции DELETE/UPDATE (CASCADE);
  • установка пустого (NULL-значения) или заданного значения по
  • умолчанию (SET DEFAULT)


Рисунок 16 Панель установления правил ссылочной целостности


Рисунок 17 Отношения и правила ссылочной целостности


На рис.17. существуют связи между сущностями ЛИЧНОСТЬ и ЧЛЕН ЭКИПАЖА с одной стороны и РЕЙС и ЧЛЕН ЭКИПАЖА с другой (Это демонстрирует ситуацию, когда одна личность может многократно быть членом экипажа на разных рейсах). Что будет, если удалить рейс? Экземпляр сущности ЧЛЕН ЭКИПАЖА не может существовать без рейса, следовательно нужно либо запретить удаление рейса, пока в нем числится хотя бы один член экипажа, либо удалять вместе с рейсом и всех его членов экипажа. Такие правила удаления (Parent Delete) называются Parent Restrict (ограничение) и Parent Cascade (каскад). Сущности ЛИЧНОСТЬ и ЧЛЕН ЭКИПАЖА, в свою очередь, тоже связаны идентифицирующей связью и, если на удаление личности наложено правило каскадного удаления всех записей о его участии в рейсах (Parent Cascade), то при удалении личности будут удалены все записи об его участии в рейсе как члена экипажа.

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

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

Внешние ключи (Foreign Key) создаются автоматически, когда связь соединяет сущности: связи образуют ссылку на атрибуты первичного ключа в дочерней сущности и эти атрибуты образуют внешний ключ в дочерней сущности (миграция ключа). Атрибуты внешнего ключа обозначаются символом (FK) после своего имени.

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

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

Создание физической модели БД

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

Переименование названий таблиц

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

При переименовании необходимо учитывать, что название таблицы или поля не может совпадать с зарезервированным словом, поэтому вместо зарезервированного слова «ROLE» (роль) будем использовать «RANK» (должность).


Рисунок 18Физический уровень модели.

Редактирование свойств полей

Для редактирования свойств полей таблиц вызываем редактор колонок (Column Editor) В диалоге появляется новая страница с закладкой InterBase — на этой странице можно задать физические свойства колонки: тип данных, опцию NULL, правило валидации (проверки на допустимость) и значение по умолчанию.

Необходимо убедиться, что название поля содержит только латинские буквы, цифры и символ подчеркивания. Особенно нужно следить, чтобы в названии поля отсутствовал символ номера (№), рекомендуется заменять его буквой N. Для переименования колонки (поля таблицы) вызываем диалог при помощи кнопки «Rename».

Проконтролируем тип данных колонки. Сервер InterBase поддерживает типы данных, приведенные в табл.

ТИП РАЗМЕР ДИАПАЗОН/ТОЧНОСТЬ ОПИСАНИЕ
BLOB переменный Размер сегмента ограничен 64 К Предназначен (только!) для хранения больших массивов данных в произвольном формате (рисунки, видео, и т.д.)
CHAR(n) n символов 1 — 32767 байт Текстовая строка фиксированной длины, дополняется пробелами справа до n
DATE 64 бита С 1 января 100 г. по 29 февраля 32768 г Включает также информацию о времени
DECIMAL (precision, scale) переменный precision =1-15 общее число знаков, scale — 1 – 15 число знаков после десятичной точки должно быть < или = precision Число с scale знаков после десятичной точки
DOUBLE PRECISION 64 бита 1 7*10-308- 1.7*1 0308 Точность до 15 знаков
FLOAT. 32 бита 3.4*10-38-3.4*1038
INTEGER — 32 бита 2147483648-2147483647 Длинное целое со знаком
NUMERIC переменный precision =1-15 общее число знаков, scale — 1 — 15 число знаков после деся ичной точки
SMALLINT 16 бит -32768 — 32767 Короткое целое со знаком
VARCHAR(n) n символов 1 — 32767 байт Текстовая строка переменной длины, пробелы справа обрезаются

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

Проконтролируем допустимость присутствия пустого значения (опцию NULL). Очевидно что «Название Города», «Название аэропорта» и другие подобные поля не должны иметь пустых значений (городов или аэропортов без названий не бывает). Особенно внимательно нужно следить чтобы признак «NOT NULL» стоял у полей входящих в первичный ключ.

Приведем соответствие имен таблиц и полей на логическом и физическом уровне.

Вид объекта Название на логическом уровне Название на физическом уровне
Таблица Авиамаршрут AIRLINE
Поле Номер маршрута AL_NUM
Поле Код Типа Самолета AL_PL_CODE
Поле Код Авиакомпании AL_AC_CODE
Таблица Аэропорт AIRPORT
Поле Код аэропорта AP_CODE
Поле Название аэропорта AP_NAME
Поле Код Города AP_CT_CODE
Таблица Авиакомпания AIRCOMPANY
Поле Код Авиакомпании AC_CODE
Поле Название Авиакомпании AC_NAME
Таблица Борт BOARD
Поле Борт номер BRD_NUM
Поле Код Типа Самолета BRD_PL_CODE
Поле Код Авиакомпании BRG_AC_CODE
Таблица Город CITY
Поле Код Города CT_CODE
Поле Название Города CT_NAME
Таблица Член Экипажа EQUIPAGE
Поле Код Члена Экипажа EQ_CODE
Поле Дата вылета EQ_FL_DATE
Поле Номер маршрута EQ_RNK_CODE
Поле Код Личности EQ_PR_CODE
Поле Код роли EQ_FL_NUM
Таблица Рейс FLIGHT
Поле Дата вылета FL_DATE
Поле Номер маршрута FL_NUM
Поле Борт номер FL_BRD_NUM
Таблица Личность PERSON
Поле Код Личности PR_CODE
Поле ФИО PR_NAME
Таблица Тип Самолета PLANE
Поле Код Типа Самолета PL_CODE
Таблица Роль члена экипажа RANK
Поле Код роли RNK_CODE
Поле Роль RNK_NAME
Таблица Тип Салона SALON
Поле Код Типа Салона SL_TYPE
Поле Название Типа Салона SL_NAME
Таблица Салон в Самолете SALON_IN_PLANE
Поле Код Типа Салона SP_SL_TYPE
Поле Код Типа Самолета SP_PL_CODE
Поле Количество мест SP_COUNT
Таблица Расписание TIMETABLE
Поле Код аэропорта TBL_AP_CODE
Поле Номер маршрута TBL_AL_NUM
Поле Время Прилета TBL_DOWN_TIME
Поле Время Вылета TBL_START_TIME
Поле Номер в Маршруте TBL_NUMBER
Таблица Тариф TARIFF
Поле Код Тарифа TR_CODE
Поле Код Типа Салона TR_SL_TYPE
Поле Номер маршрута TR_AL_NUM
Поле Цена билета TR_COST
Поле Аэропорт Откуда TR_AP_FROM
Поле Аэропорт Куда TR_AP_TO
Таблица Билет TICKET
Поле Номер билета TC_NUM
Поле Код Личности TC_PR_CODE
Поле Код Тарифа TC_TR_CODE
Поле Дата вылета TC_FL_DATE
Поле Номер маршрута TC_FL_NUM

Генерирование SQL-сценария создания БД

Основной целью процесса проектирования является генерация физической схемы БД. Для генерации схемы БД следует выбрать пункт меню «Tasks/ Forward Engineer/Schema Generation…».


Рисунок 19 Диалоговое окно генератора схем

Физическая схема БД генерируется на основе логической схемы и набора установок, задаваемых в диалоговом окне генератора схем (рис. …). Эти установки определяют, какие элементы должны войти в схему БДе диалога содержатся и другие кнопки:

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

А теперь можно сгенерировать схему нашей БД:.

  1. В диалоговом окне генератора схем на странице «Options» выделите в левом списке объект «Trigger» и уберите все флажки в правом списке;
  2. Выделите объект «Index» и уберите все флажки в правом списке;
  3. Нажмите «Preview». В окне просмотра появится SQL-скрипт создания БД:

CREATE TABLE

AIRCOMPANY (

AC_CODE INTEGER NOT NULL,

AC_NAME VARCHAR(20)

);
ALTER TABLE

AIRCOMPANY

ADD PRIMARY KEY (AC_CODE);
CREATE TABLE

AIRLINE (

AL_NUM VARCHAR(20) NOT NULL,

AL_AC_CODE INTEGER NOT NULL,

AL_PL_CODE VARCHAR(20) NOT NULL,

AL_NAME VARCHAR(20)

);
ALTER TABLE

AIRLINE

ADD PRIMARY KEY (AL_NUM);
CREATE TABLE

AIRPORT (

AP_CODE INTEGER NOT NULL,

AP_NAME VARCHAR(20),

AP_CT_CODE INTEGER NOT NULL

);
ALTER TABLE

AIRPORT

ADD PRIMARY KEY (AP_CODE);
CREATE TABLE

BOARD (

BRD_NUM INTEGER NOT NULL,

BRD_PL_CODE VARCHAR(20) NOT NULL,

BRG_AC_CODE INTEGER NOT NULL

);
ALTER TABLE

BOARD

ADD PRIMARY KEY (BRD_NUM);
CREATE TABLE

CITY (

CT_CODE INTEGER NOT NULL,

CT_NAME VARCHAR(20) NOT NULL

);
ALTER TABLE

CITY

ADD PRIMARY KEY (CT_CODE);
CREATE TABLE

EQUIPAGE (

EQ_CODE INTEGER NOT NULL,

EQ_FL_DATE DATE NOT NULL,

EQ_RNK_CODE INTEGER NOT NULL,

EQ_PR_CODE INTEGER NOT NULL,

EQ_FL_NUM VARCHAR(20) NOT NULL

);
ALTER TABLE

EQUIPAGE

ADD PRIMARY KEY (EQ_CODE);
CREATE TABLE

FLIGHT (

FL_DATE DATE NOT NULL,

FL_NUM VARCHAR(20) NOT NULL,

FL_BRD_NUM INTEGER NOT NULL

);
ALTER TABLE

FLIGHT

ADD PRIMARY KEY (FL_DATE, FL_NUM);
CREATE TABLE

PERSON (

PR_CODE INTEGER NOT NULL,

PR_NAME VARCHAR(20)

);
ALTER TABLE

PERSON

ADD PRIMARY KEY (PR_CODE);
CREATE TABLE

PLANE (

PL_CODE VARCHAR(20) NOT NULL

);
ALTER TABLE

PLANE

ADD PRIMARY KEY (PL_CODE);
CREATE TABLE

RANK (

RNK_CODE INTEGER NOT NULL,

RNK_NAME VARCHAR(20)

);
ALTER TABLE

RANK

ADD PRIMARY KEY (RNK_CODE);
CREATE TABLE

SALON (

SL_TYPE INTEGER NOT NULL,

SL_NAME VARCHAR(20)

);
ALTER TABLE

SALON

ADD PRIMARY KEY (SL_TYPE);
CREATE TABLE

SALON_IN_PLANE (

SP_SL_TYPE INTEGER NOT NULL,

SP_PL_CODE VARCHAR(20) NOT NULL,

SP_COUNT INTEGER

);
ALTER TABLE

SALON_IN_PLANE

ADD PRIMARY KEY (SP_SL_TYPE, SP_PL_CODE);
CREATE TABLE

TIMETABLE (

TBL_AP_CODE INTEGER NOT NULL,

TBL_AL_NUM VARCHAR(20) NOT NULL,

TBL_DOWN_TIME VARCHAR(20),

TBL_START_TIME DATE,

TBL_NUMBER INTEGER

);
ALTER TABLE

TIMETABLE

ADD PRIMARY KEY (TBL_AP_CODE, TBL_AL_NUM);
CREATE TABLE

TARIFF (

TR_CODE INTEGER NOT NULL,

TR_SL_TYPE INTEGER,

TR_AL_NUM VARCHAR(20) NOT NULL,

TR_COST INTEGER,

TR_AP_FROM INTEGER NOT NULL,

TR_AP_TO INTEGER NOT NULL

);
ALTER TABLE

TARIFF

ADD PRIMARY KEY (TR_CODE);
CREATE TABLE

TICKET (

TC_NUM INTEGER NOT NULL,

TC_PR_CODE INTEGER NOT NULL,

TC_TR_CODE INTEGER NOT NULL,

TC_FL_DATE DATE NOT NULL,

TC_FL_NUM VARCHAR(20) NOT NULL

);
ALTER TABLE

TICKET

ADD PRIMARY KEY (TC_NUM);
ALTER TABLE

AIRLINE

ADD FOREIGN KEY (AL_AC_CODE)

REFERENCES

AIRCOMPANY;
ALTER TABLE AIRLINE

ADD FOREIGN KEY (AL_PL_CODE)

REFERENCES

PLANE;
ALTER TABLE AIRPORT

ADD FOREIGN KEY (AP_CT_CODE)

REFERENCES

CITY;
ALTER TABLE BOARD

ADD FOREIGN KEY (BRG_AC_CODE)

REFERENCES

AIRCOMPANY;
ALTER TABLE BOARD

ADD FOREIGN KEY (BRD_PL_CODE)

REFERENCES

PLANE;
ALTER TABLE EQUIPAGE

ADD FOREIGN KEY (EQ_RNK_CODE)

REFERENCES

RANK;
ALTER TABLE EQUIPAGE

ADD FOREIGN KEY (EQ_PR_CODE)

REFERENCES

PERSON;
ALTER TABLE EQUIPAGE

ADD FOREIGN KEY (EQ_FL_DATE, EQ_FL_NUM)

REFERENCES

FLIGHT;
ALTER TABLE FLIGHT

ADD FOREIGN KEY (FL_BRD_NUM)

REFERENCES

BOARD;
ALTER TABLE FLIGHT

ADD FOREIGN KEY (FL_NUM)

REFERENCES

AIRLINE;
ALTER TABLE SALON_IN_PLANE

ADD FOREIGN KEY (SP_PL_CODE)

REFERENCES

PLANE;
ALTER TABLE SALON_IN_PLANE

ADD FOREIGN KEY (SP_SL_TYPE)

REFERENCES

SALON;
ALTER TABLE TIMETABLE

ADD FOREIGN KEY (TBL_AL_NUM)

REFERENCES

AIRLINE;
ALTER TABLE TIMETABLE

ADD FOREIGN KEY (TBL_AP_CODE)

REFERENCES

AIRPORT;
ALTER TABLE TARIFF

ADD FOREIGN KEY (TR_AP_TO, TR_AL_NUM)

REFERENCES

TIMETABLE;
ALTER TABLE TARIFF

ADD FOREIGN KEY (TR_AP_FROM, TR_AL_NUM)

REFERENCES

TIMETABLE;
ALTER TABLE TARIFF

ADD FOREIGN KEY (TR_AL_NUM)

REFERENCES

AIRLINE;
ALTER TABLE TARIFF

ADD FOREIGN KEY (TR_SL_TYPE)

REFERENCES

SALON;
ALTER TABLE TICKET

ADD FOREIGN KEY (TC_FL_DATE, TC_FL_NUM)

REFERENCES

FLIGHT;
ALTER TABLE TICKET

ADD FOREIGN KEY (TC_TR_CODE)

REFERENCES

TARIFF;
ALTER TABLE TICKET

ADD FOREIGN KEY (TC_PR_CODE)

REFERENCES

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

CREATE TABLE — создание таблицы;

ALTER TABLE… ADD PRIMARY KEY — добавление первичного ключа;

ALTER TABLE… ADD FOREIGN KEY — добавление внешнего ключа.

Практическая работа №38 и №39

Основы работы в  ERWin. Построение
логической модели

Цель работы

·       
ознакомиться
с технологией построения логической модели в ERWin;

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

·       
изучить
типы связей между сущностями.

Задание:  

Необходимо создать информационную
модель предметной области «Отдел кадров».

Основные таблицы модели:

                  
Работники
  (Код сотрудника, Фамилия, Имя, Отчество, Дата рождения);

                  
Должности
(Код должности, Наименование, Оклад);

                  
Отделы (Код
отдела, Название, Подразделение);

Основные правила:

                               
отдел
может входить в другой отдел;

                               
в разных
отделах могут быть одинаковые должности;

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

Ход работы

Первым шагом при
создании логической модели БД является построение диаграммы ERD (Entity
Relationship Diagram). ERD-диаграммы состоят из трех частей: сущностей,
атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты —
прилагательными или модификаторами, взаимосвязи — глаголами.

·                  
Откройте
программу Пуск – Программы –
Computer Associates Erwin 4.0 — Erwin 4.0.

·                  
В
открывшемся окне выберите
Greate a new model (создать новую модель).

·                  
В
открывшемся окне выберите
Logical (логическая модель)

·                  
Выберите
элемент Таблица на Панели инструментов . Щелкните по рабочей области и введите название
таблицы «Работники».

·                  
Определим
атрибуты таблицы. Для этого щелкните два раза по созданному элементу.

·                  
Откроется окно (Рисунок 1). Для ввода полей нажмите
кнопку
New.

Рисунок 1 — Ввод
полей таблицы

·                  
В открывшемся окне New Attribute в поле
Attribute name
введите Код сотрудника и выберите тип данных в окне
DomainNumber и нажмите
ОК.

·          
Аналогичным образом создайте остальные поля таблицы Работники 
— Фамилия, Имя, Отчество, Дата рождения.

·         
Для задания ключевых полей выберите переключатель Primary key
(рисунок 1), для задания полей обязательных для ввода выберите переключатель
Required (рисунок
2).

Рисунок 2 – Указание поля, обязательного для ввода

·           
Самостоятельно
создайте таблицы Отделы и Должности. Определите
ключевые атрибуты (рисунок 3).

Рисунок 3 – Созданные таблицы

2.2. Создание связей между сущностями

Связь является
логическим соотношением между сущностями. Связь имеет имя, мощность, тип.

Имя связи
(Verb Phrase
)
– фраза, характеризующая отношение между главной и подчиненной сущностями.

Мощность связи
(Cardinality)

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

Различают четыре
типа мощности:

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

                                                       P

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

                                                        Z

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

                                                      N

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

В Erwin различают два типа связей: идентифицирующая
и неидентифицирующая.

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

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

·        
Согласно
правилам модели отдел может входить в другой отдел, Создадим соответствующую неидентифицирующую
связь с помощью кнопки на панели инструментов Non-identifying relationship
, щелкнув дважды на
таблице «Отдел». Дважды щелкнув на появившейся связи, перейдем в редактор ее
свойств (рисунок 4). Дадим имя связи – «включает в себя». Поскольку уровень
вложенности строго не задан, установим параметры – «
zero, one or more» (неидентифицирующая связь,
один ко многим).

Рисунок 4 – Параметры
связи

·         
Созданная
связь показана на рисунке 5.

Рисунок 5 – Правило «Отдел может входить в другой отдел»

·        
Для
отображения параметров связи выберите в меню
Format и
поставьте галочку на вкладке
Logical verb Phrase.

·         
Создадим
связь между таблицами «Отдел» и «Работники» (рисунок 6). В отделе есть хотя бы
один сотрудник, поэтому укажем размерность «
one or more» (идентифицирующая связь,
один ко многим) (рисунок 7).

Рисунок 6 – Связь между таблицами «Работники» и «Отдел»

Рисунок 7 – Настройка связи

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

Рисунок 8– Реализация связи «многие ко многим»

·                  
Логическая
модель базы данных построена.

Задание для самостоятельной работы.

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

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

Экипаж состоит из нескольких сотрудников авиакомпании. Каждый
член экипажа имеет ФИО, должность (командир, пилот, стюардесса) и лётный стаж,
исчисляющийся в количестве вылетов.

Задача 2. За поликлиникой закреплены
несколько участков (по адресам больных). На каждом участке прием ведет один
врач. Кроме участковых терапевтов есть врачи-специалисты (ЛОР, окулист,
хирург…).

БД должна
содержать сведения о врачах (специальность, ФИО, дату рождения адрес, телефон),
о пациентах, их адресах, месте работы, возрасте, о заболеваниях; кто, в каких
числах и с каким диагнозом находился на больничном, о типах заболеваний
(простудные, травмы…), о расписании приема для каждого врача (дни недели,
часы).

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *