Проектирование БД презентация

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

ЭТАПЫ РАЗРАБОТКИ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ.
Понятие предметной области и модели предметной области.
Критерии оценки качества логической модели данных

ЭТАПЫ РАЗРАБОТКИ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ
При разработке базы данных можно выделить следующие уровни:
Сама предметная область.
Модель предметной области.
Инфологическая модель данных.
Даталогическая модель данных.
Собственно база данных и приложения.

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

Модель предметной области - это наши знания о предметной области.
Модель предметной области описывает процессы, происходящие в предметной области и данные, используемые этими процессами.

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

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

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

Информационно-логическая (инфологическая) модель предметной области
Модель описывает
понятия предметной области,
взаимосвязь понятий предметной области,
ограничения на данные, налагаемые предметной областью.

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

Инфологическая модель данных является начальным прототипом будущей базы данных.
Эта модель строится без привязки к конкретной СУБД.
Основным средством разработки логической модели данных являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь).

Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных.

Даталогическая модель данных.
Даталогическая модель данных описывает данные средствами конкретной СУБД.

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

Ограничения, имеющиеся в логической модели данных, реализуются различными средствами СУБД, например, при помощи индексов, декларативных ограничений целостности, триггеров, хранимых процедур.

Собственно база данных и приложения.

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

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

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

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

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

Этапы работы над моделью данных.

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

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

∙ выбор СУБД.
По результатам выполнения этого этапа создается техническое задание (ТЗ).

II этап. Технический проект. На данном этапе выполняются следующие работы:
уточнение инфологической модели;
создание датологической модели;
проектирование программного обеспечения.

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

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

Логическое проектирование данных

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

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

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

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

Следует различать избыточное и неизбыточное дублирование данных.

Пример неизбыточного дублирования

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

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

Сотрудник__телефон__комната

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

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

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

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

Исходное отношение имеет следующие атрибуты:
Преподаватель_Занятия(ФИО, Должность, Оклад, Стаж, Надбавка за стаж, Кафедра, Предмет, Группа, Вид_занятий, Часы).

Преподаватель_Занятия

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

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

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

Метод нормализации отношений основан на фундаментальном в теории реляционных БД понятии зависимости между атрибутами отношений.

13. Зависимости между атрибутами отношений (функциональные, многозначные, транзитивные)

ЗАВИСИМОСТИ МЕЖДУ АТРИБУТАМИ ОТНОШЕНИЙ
Основные виды зависимостей между атрибутами отношений:
функциональные,
многозначные,
транзитивные.

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

Определение функциональной зависимости:
Атрибут В функционально зависит от атрибута А, если каждому значению А соответствует в точности одно значение В.
Aтрибут А функционально определяет атрибут B (A является детерминантом (определителем) для B, а B является зависимым от A)

А->В
А и В могут быть составными, то есть состоять из двух и более атрибутов.

Примеры функциональных зависимостей в отношении Преподаватель_Занятия
ФИО -> ДОЛЖНОСТЬ,
ДОЛЖНОСТЬ -> ОКЛАД,
ФИО, Предмет, Группа, Вид_занятий -> Часы

В отношении Преподаватель_Занятия первичный ключ является составным и состоит из атрибутов ФИО, Предмет, Группа, Вид_занятий.

Атрибут Предмет входит в первичный ключ, т.к. преподаватель может вести разные предметы, атрибут Вид занятий входит в первичный ключ, т.к. преподаватель может проводить и лекционные и лабораторные занятия по одному и тому же предмету, атрибут Группа входит в первичный ключ т.к. преподаватель может проводить один и тот же вид занятий по одному и тому же предмету в разных группах.
Значения атрибута Часы находятся в зависимости от комбинации атрибутов ФИО, Предмет, Группа, Вид_занятий.

Частичной функциональной зависимостью называют зависимость неключевого атрибута от части составного ключа. ФИО, Предмет, Группа, Вид_занятий -> Часы
ФИО -> ДОЛЖНОСТЬ
В рассматриваемом отношении атрибут Должность находится в функциональной зависимости от атрибута ФИО, являющегося частью составного ключа. Тем самым атрибут должность находится в частичной зависимости от ключа отношения.

ФИО, Предмет, Группа, Вид_занятий -> Часы

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

Определение транзитивной зависимости:
Атрибут С зависит от атрибута А транзитивно, если для атрибутов А,В,С выполняется А->В и В->С, но обратная зависимость отсутствует.
Пример транзитивной зависимости
ФИО->Должность->Оклад.

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

Многозначные зависимости могут быть. «один-ко-многим»(1:М), многие к одному(М:1) или многие ко многим(М:М).
Например, если преподаватели ведут несколько предметов, а каждый предмет может вестись несколькими преподавателями, то имеет место зависимость(М:М) между атрибутами ФИО и Предмет.

Выявим функциональные зависимости между атрибутами отношения Преподаватель_Занятия
ФИО -> Оклад
ФИО -> Должность
ФИО -> Стаж
ФИО -> Надб
ФИО -> Каф
Стаж -> Надбавка
Должн -> Оклад
ФИО.Предмет.Группа. Вид_зан -> Часы

После того, как выделены все функциональные зависимости, следует проверить их согласованность с данными исходного отношения. Например, Должность “доцент” и Оклад “20000” должны соответствовать друг другу во всех кортежах, так как имеет место функциональная зависимость
Должн->Оклад.
Так же следует проверить и остальные данные.

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

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

Исходное отношение Преподаватель_Занятия имеет составной ключ ФИО, Предмет, Группа, Вид_занятий
и находится 1НФ.
Преподаватель_Занятия(ФИО, Должность, Оклад, Стаж, Надбавка за стаж, Кафедра, Предмет, Группа, Вид_занятий, Часы).
В этом отношении можно выделить частичную зависимость атрибутов Стаж, Надбавка, Должность, Оклад, Кафедра от первичного ключа - указанные атрибуты находятся в функциональной зависимости от атрибута ФИО, являющегося частью составного ключа.

Эта частичная зависимость приводит к следующему:
в отношении присутствует явное избыточное дублирование данных, например: повторение данных о стаже, должности и окладе преподавателей, проводящих занятия в нескольких группах и/или по разным предметам;
Следствием избыточного дублирования данных является проблема их редактирования. Например, изменение должности у преподавателя Иванова потребует просмотра всех кортежей отношения и внесения изменений в те из них, которые содержат сведения о данном преподавателе.
Часть избыточности устраняется при переводе отношения в 2НФ.

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

Преподаватель_Занятия(ФИО, Должность, Оклад, Стаж, Надбавка за стаж, Кафедра, Предмет, Группа, Вид_занятий, Часы).

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

Перевод отношения во вторую нормальную форму позволил исключить явную избыточность данных в таблице Преподаватель_Занятия – повторение строк со сведениями о преподавателях.
В отношении Преподаватели по-прежнему имеет место неявное дублирование данных: повторение окладов для преподавателей, занимающих одинаковую должность и надбавок - для преподавателей, имеющих одинаковый стаж. Необходимо преобразовать это отношение в 3НФ.

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

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

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

ФИО -> Должность -> Оклад
ФИО -> Стаж -> Надб

Преобразуем отношение Преподаватели так, чтобы исключить транзитивные зависимости.
В результате получим из него отношения
Преподаватели1 (ФИО, должность, стаж, кафедра)
Должностные_ оклады (Должность, Оклад)
Надбавки(Стаж, надбавка)

Первоначальное определение, данное Коддом для ЗНФ не во всех случаях оказывается удовлетворительным. В частности, оно неадекватно если отношение имеет два (или больше) потенциальных ключа, таких, что эти потенциальные ключи являются составными.
Поэтому впоследствии исходное определение ЗНФ было заменено более строгим определением Бойса—Кодда.

Отношение находится в нормальной форме Бойса-Кодда (НФБК) тогда и только тогда, когда детерминанты всех функциональных зависимостей являются потенциальными ключами.

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

Дано отношение:
Результаты_сессии(Номер_зачетки, ID_Студента, Дисциплина, Дата, Оценка).

Отношение содержит зависимости:
Номер_зачетки, Дисциплина, Дата -> Оценка;
ID_Студента, Дисциплина, Дата ->Оценка;
Номер_зачетки->ID_Студента;
ID_Студента ->Номер_зачетки.

В последних двух зависимостях детерминанты не являются возможными ключами отношения. Поэтому разбиваем отношение Результаты_сессии на два отношения:
Итоги_сессии(Номер_зачетки, Дисциплина, Дата, Оценка)
Сведения о студентах(Номер_зачетки, ID_Студента).
Все отношения находятся в НФБК.

Четвертая нормальная форма
Рассмотрим пример следующей схемы отношения:
ПРОЕКТЫ (ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН)
Отношение ПРОЕКТЫ содержит номера проектов, для каждого проекта - список сотрудников, которые могут выполнять проект, и список заданий, предусматриваемых проектом. Сотрудники могут участвовать в нескольких проектах, и разные проекты могут включать одинаковые задания.

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

Единственным возможным ключом отношения является составной атрибут ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН, и нет никаких других детерминантов.
Следовательно, отношение ПРОЕКТЫ находится в БКНФ. Но при этом оно обладает недостатками: если, например, некоторый сотрудник присоединяется к данному проекту, необходимо вставить в отношение ПРОЕКТЫ столько кортежей, сколько заданий в нем предусмотрено.

В отношении ПРОЕКТЫ существуют следующие две многозначные зависимости:
ПРО_НОМЕР ->-> ПРО_СОТР
ПРО_НОМЕР ->-> ПРО_ЗАДАН
ПРО_НОМЕР ->-> ПРО_СОТР|ПРО_ЗАДАН

Дальнейшая нормализация отношений, подобных отношению ПРОЕКТЫ, основывается на следующей теореме:
Теорема Фейджина
Отношение R (A, B, C) можно спроецировать без потерь в отношения
R1 (A, B) и R2 (A, C) в том и только в том случае, когда существует многозначная зависимость A ->-> B | C.
Под проецированием без потерь понимается такой способ декомпозиции отношения, при котором исходное отношение полностью и без избыточности восстанавливается путем естественного соединения полученных отношений.

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

Предположим, что рестораны производят разные виды пиццы, а службы доставки ресторанов работают только в определенных районах города. Составной ключ таблицы такого отношения включает три поля:
{Ресторан, Вид пиццы, Район доставки}.
Такая таблица не соответствует 4NF, так как существует многозначная зависимость:
{Ресторан} >> {Вид пиццы}
{Ресторан} >> {Район доставки}

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

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

15. Семантическое моделирование БД. Модель сущность-связь. Понятия сущности, экземпляра сущности атрибута, связи. Модальность связи.

Семантическое моделирование БД

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

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

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

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

В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь
(ER - Entity-Relationship).

Оба термина relation и relationship могут быть переведены на русский язык как отношение. Поэтому в русскоязычной литературе ER-модель иногда называют моделью сущность-отношение.

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

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

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

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

Экземпляр сущности - это конкретный представитель данной сущности.
Например, представителем сущности "Сотрудник" может быть "Сотрудник Иванов".
Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности.

Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности.
Примерами атрибутов сущности "Сотрудник" могут быть такие атрибуты как "Табельный номер", "Фамилия", "Имя", "Отчество", "Должность", "Зарплата" и т.п.

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

Связь - это некоторая ассоциация между двумя сущностями.
Связи позволяют по одной сущности находить другие сущности, связанные с нею.
Связи между сущностями могут выражаться следующими фразами - "СОТРУДНИК может иметь несколько ДЕТЕЙ", "каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ".

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

Графически связь изображается линией, соединяющей две сущности:

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

Каждая связь может иметь один из следующих типов связи: 1:1, 1:M, M:M.
Связь типа один-к-одному означает, что один экземпляр первой сущности связан с одним экземпляром второй сущности. Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделённую на две.

Связь типа один-ко-многим означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности. Это наиболее часто используемый тип связи.
Сущность со стороны "один" называется родительской, со стороны "много" - дочерней.

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

Каждая связь может иметь одну из двух модальностей :
-

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

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

Каждая связь может быть прочитана как слева направо, так и справа налево.
Связь на рисунке читается так:
Слева направо: "каждый сотрудник может иметь несколько детей".
Справа налево: "Каждый ребенок обязан принадлежать ровно одному сотруднику".

Пример рекурсивной связи, связывающая сущность МУЖЧИНА
с ней же самой. Конец связи с именем " сын "
определяет тот факт, что несколько людей могут
быть сыновьями одного отца. Конец связи с именем " отец "
означает, что не у каждого мужчины должны быть сыновья.
каждый МУЖЧИНА является сыном одного и только одного МУЖЧИНЫ ;
каждый МУЖЧИНА может являться отцом одного или более МУЖЧИН.

Курсовые работы

Студенты-Специальности

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

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

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

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

Курсовые работы

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

Пример супертипа ЛЕТАТЕЛЬНЫЙ АППАРАТ и его подтипов АЭРОПЛАН, ВЕРТОЛЕТ, ПТИЦЕЛЕТ и ПРОЧИЕ. У подтипа АЭРОПЛАН имеются два собственных подтипа – ПЛАНЕР и МОТОРНЫЙ САМОЛЕТ.
Для супертипа сущности ЛЕТАТЕЛЬНЫЙ АППАРАТ определен атрибут максимальная дальность полета и необязательная связь "многие ко многим" с типом сущности ПИЛОТ.
Эти атрибут и связь наследуется всеми подтипами этого супертипа сущности. У подтипа сущности АЭРОПЛАН определяется один дополнительный атрибут, так что в совокупности у данного типа сущности имеются два атрибута максимальная дальность полета и размах крыльев и одна унаследованная связь с типом сущности ПИЛОТ.

Пример создания инфологической модели
(Библиотека)

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

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

Необходимо предусмотреть ограничения на информацию в системе:
1. Книга может не иметь ни одного автора.
2. В библиотеке должны быть записаны читатели не моложе 17 лет.
…

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

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

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

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

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

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

Сущность Читатели
Каждый экземпляр сущности Читатели будет соответствовать конкретному читателю. В библиотеке каждому читателю присваивается уникальный номер читательского билета, который однозначно идентифицирует читателя. Номер читательского билета будет ключевым атрибутом сущности Читатели. Кроме того, в сущности Читатели должны присутствовать дополнительные атрибуты: ФИО, Адрес читателя, Телефон.

Существует ограничение на возраст читателя, поэтому необходимо ввести атрибут Дата рождения. Каждый читатель может держать на руках несколько экземпляров книг. Для отражения этой ситуации необходимо провести связь между сущностями Читатели и Экземпляры
Между сущностями Читатели и Экземпляры установлена связь 1:М, не обязательная с 2-х сторон, т.к. читатель может в данный момент не иметь ни одной книги на руках, а с другой стороны, данный экземпляр книги может не находиться на руках ни у одного читателя, а стоять на полке.

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

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

16. Преобразование модели «сущность – связь» в реляционную модель. Учет модальности связи при переходе к реляционной модели

ПОЛУЧЕНИЕ РЕЛЯЦИОННОЙ СХЕМЫ ИЗ ER-МОДЕЛИ
Каждая простая сущность превращается в отношение. Имена отношений могут отличаться от имен сущностей, т. к могут быть ограничены требованиями конкретной СУБД;
Каждый атрибут становится возможным столбцом с тем же именем, для каждого атрибута задается допустимый тип данных и обязательность или необязательность этого атрибута;

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

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

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

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

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

Для связи М:М между сущностями Книги и Системный каталог вводится дополнительное связующее отношение, которое связано с каждым исходным связью 1:М.
Атрибутами этого связующего отношения будут первичные ключи связываемых отношений, то есть введем отношение с атрибутами ISBN и KOD. При этом каждый из атрибутов нового отношения является внешним ключом, а вместе они образуют первичный ключ новой связующей сущности.

Учет модальности связи при переходе к реляционной модели

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

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

Для связи 1:M
Если связь имеет тип 1:M и со cтороны М является обязательной, необходимо построить таблицу для каждой сущности. Первичный ключ сущности на стороне 1 добавляется в таблицу на стороне М.
Если связь имеет тип 1:M и со cтороны М является необязательной, необходимо построить 3 таблицы - по одной для каждой сущности и одну для связи. Таблица для связи должна иметь ключи обеих сущностей среди своих атрибутов.

Проверка транзакций!

Если в концептуальной схеме (ER-диаграмме) присутствуют подтипы, то возможны два способа их представления в реляционной схеме:
(a) собрать все подтипы в одной таблице;
(b) для каждого подтипа образовать отдельную таблицу.

При применении способа (a) таблица создается для максимального супертипа - типа сущности, не являющегося подтипом.
Таблица содержит столбцы, соответствующие каждому атрибуту каждого подтипа.

В таблицу добавляется столбец, содержащий код ТИПА; он становится частью первичного ключа. Для каждой строки таблицы значение этого столбца определяет тип сущности, экземпляру которой соответствует строка.
Столбцы, которые соответствуют атрибутам, отсутствующим в данном типе сущности, должны содержать неопределённые значения. Т.е. для ряда экземпляров ряд атрибутов не будет иметь смысла.

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

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

17. Пример логического проектирования базы данных с использованием модели «сущность-связь».

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

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

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

Покупатель – явный кандидат на сущность, т.к. покупатели – множество объектов предметной области , с которыми взаимодействует фирма;
Товар – явный кандидат на сущность, т.к. товары – множество объектов предметной области, которые фирма продает покупателям;

Накладная – явный кандидат на сущность, т.к. накладные – множество документов, в которых фиксируется факт продажи товара;
(?) Склад – сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность;
(?)Наличие товара – это, скорее всего, атрибут, но атрибут какой сущности?

Сразу возникает очевидная связь между сущностями – Покупатели могут покупать много Товаров и Товары могут продаваться многим покупателям.

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

НАКЛАДНЫЕ
Покупатели покупают Товары, получая при этом Накладные, в которые внесены данные о количестве и цене купленного Товара.
Каждый Покупатель может получить несколько Накладных.
Каждая Накладная должна выписываться на одного Покупателя.
Каждая Накладная может содержать несколько Товаров, и должна содержать хотя бы один Товар – не бывает пустых накладных.
Каждый Товар, в свою очередь, может быть продан нескольким покупателям и зафиксирован в нескольких Накладных.
Кроме того, каждая Накладная должна быть выписана с определённого Склада, и с любого Склада может быть выписано много Накладных.

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

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

Сущности Накладная и Товар связаны друг с другом отношением М:М. Такая связь должна быть разделена на две связи типа один-ко-многим. Для этого требуется дополнительная сущность. Этой сущностью будет сущность Запись списка в накладной.

Связь новой сущности с сущностями «Накладная» и «Товар» характеризуется следующим:
Каждая накладная обязана иметь несколько записей из списка товаров в накладной;
Каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную;
Каждый товар может включаться в несколько записей из списка товаров в накладной;
Каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром.

Атрибуты Количество товара в накладной и Цена товара в накладной являются атрибутами сущности «Список товаров в накладной»

Точно также поступим со связью, соединяющей сущности «Склад» и «Товар». Введём дополнительную сущность «Товар на складе». Атрибутом этой сущности будет «Количество товара на складе». Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.

18. CASE-средства для логического проектирования БД. Зависимые и независимые сущности. Типы зависимых сущностей и иерархия наследования. Прямое и обратное проектирование.

СASE-системы для проектирования
баз данных (Computer Aided Software Engineering)
История систем автоматизации проектирования баз данных началась с автоматизации процесса рисования диаграмм, проверки их формальной корректности, обеспечения средств хранения диаграмм и другой проектной документации.
Наличие электронного архива проектной документации помогает при эксплуатации, администрировании и сопровождении базы данных.

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

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

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

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

К числу Сase-средства проектирования баз данных относятся ERwin (CA ERwin Data Modeler r8 ), S-Designеr (SDP) и DataBase Designer.
Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun, PRO-IV.

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

ERWin может на основе диаграммы базы данных сгенерировать SQL-код этой структуры. Или наоборот, по SQL-коду сгенерировать ER-диаграмму базы данных.

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

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

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

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

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

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

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

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

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

Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя).

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

Типы зависимых сущностей и иерархия наследования
Различают несколько типов зависимых сущностей.
Характеристическая - зависимая сущность, которая связана только с одной родительской.

Ассоциативная - сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей.
Пример ассоциативной сущности:

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

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

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

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

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

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

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

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

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

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

Для создания моделей данных в ERwin можно использовать две нотации: IDEF1X и IE (Information Engineering).
Методология IDEF1X была разработана для армии США и широко используется в государственных учреждениях США, финансовых и промышленных корпорациях.
Методология IE, разработанная Мартином и другими авторами, используется преимущественно в промышленности.

Объектно-ориентированные CASE-средства (Rational Rose)
Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации проектирования программного обеспечения c помощью языка UML, а также для генерации кодов на различных языках и выпуска проектной документации.
Но, помимо прочего, язык UML применяется для проектирования реляционных БД. Для этого используется небольшая часть языка (диаграммы классов).
С точки зрения проектирования реляционных БД модельные возможности не слишком отличаются от возможностей ER-диаграмм