5.2. Case - приложение eRwin
CASE - системы (приложения, поддерживающие автоматизированное проектирование реляционной БД) позволяют создавать и преобразовывать ER - диаграммы в реляционную модель.
Примером CASE - системы является приложение ERwin.
Реализация моделирования в ERwin базируется на теории реляционных БД и на методологии IDEF1X. Методология IDEF1X определяет стандарты терминологии, используемой при информационном моделировании, и графического изображения типовых элементов на диаграммах.
Процесс построения модели в ERwin состоит из следующих шагов:
- определение объектов;
- определение связей между объектами;
- задание первичных ключей;
- определение атрибутов объектов;
- преобразование модели к требуемому уровню нормальной формы (обычно к 3НФ);
- переход к физическому описанию модели: выбор целевой СУБД, назначение соответствий (имя объекта - имя таблицы, атрибут объекта - атрибут таблицы), задание триггеров, процедур и ограничений;
- генерация БД.
Плюсы ERwin
ERwin создает визуальную модель данных для решаемой задачи. Ее можно использовать для анализа, уточнения и распространения как части документации, необходимой в цикле разработки. Однако ERwin - не только инструмент для рисования диаграмм. Это приложение позволяет определять первичные и внешние ключи, индексы, а также автоматически создает стандартный SQL - код определения данных, который поможет создать таблицы и индексы.
Применение ERwin существенно повышает эффективность разработчика ИС.
Основные преимущества:
- повышение скорости разработки ИС за счет мощного редактора диаграмм, автоматической генерации БД, автоматической подготовки документации;
- нет необходимости ручной подготовки SQL - кода для создания БД;
- обратное проектирование позволяет документировать и вносить изменения в существующие ИС;
- поддержка ERwin настольных СУБД (типа Access) позволяет использовать для одиночных и групповых ИС современную технологию, что значительно упрощает переход к системам в технологии клиент - сервер.
5.2.1. Объекты в eRwin
Объект - это логическое понятие. На физическом уровне объекту соответствует таблица реальной СУБД. Для каждого первичного ключа Erwin создает при генерации структуры уникальный индекс.
5.2.2. Связь в Erwin
Связь - это функциональная зависимость между двумя объектами. Если между некоторыми объектами существует связь, то факты из одного объекта ссылаются или некоторым образом связаны с фактами из другого объекта.
Существует три вида связей: один - к - одному, один - ко - многим, многие - ко - многим.
Связь называется идентифицирующей, если экземпляр дочернего объекта идентифицируется через ее связь с родительским объектом. Атрибуты, составляющие первичный ключ родительского объекта, при этом входят в первичный ключ дочернего объекта.
Связь называется неидентифицирующей, если экземпляр дочернего объекта идентифицируется иначе, чем через связь с родительским объектом. Атрибуты, составляющие первичный ключ родительского объекта, при этом входят в состав неключевых атрибутов дочернего объекта.
Для определения связей Erwin выбирает тип связи, затем мышью указывается родительский и дочерний объект. Идентифицирующая связь изображается сплошной линией, неидентифицирующая - пунктирной. Линии заканчиваются точкой со стороны дочернего объекта.
Связь - это понятие логического уровня, которому соответствует внешний ключ на физическом уровне.
ERwin интегрирован с популярными программными средствами разработки клиентской части приложения - Power Builder, Visual Basic, что позволяет автоматически генерировать код приложения, который полностью готов к компиляции и выполнению.
После разработки модели данных в ERwin, ее следует связать с функциональной моделью в BРwin. Такая связь гарантирует завершение анализа, т.е. источник данных (сущность) существует для всех потребностей данных (функций). Связи объектов способствуют согласованности, корректности и завершению анализа.
Первым шагом связывания моделей является экспорт из ERwin в BPwin. Главная задача моделирования в ERwin - определить какая информация необходима для реализации функций, описанных диаграммой IDEF0. ERwin создает визуальную модель данных, но ERwin - не только инструмент для рисования диаграмм, он позволяет проводить процессы прямого и обратного проектирования БД.
Тема 6. Принципы логического (концептуального) проектирования. Инфологическое моделирование, даталогические модели. Понятие сущности атрибута, взаимосвязи. Типы взаимосвязей. Правила отношений между сущностями. Определение ключей. Нормализация БД. Денормализация БД
Лекции: 4 часа
Первый шаг:
1. создание концептуальной модели данных, на основе анализа выделяют сущности.
2 схематично изображают как связаны между собой эти сущности.
3 определяеа типы связей между сущностями.
Второй шаг:
Отношения между таблицами регулируются тремя правилами:
Если две таблицы находятся в отношении один-к-одному, то поле ключ одной таблицы должно быть помешено и во вторую таблицу.
Есди две таблицы в отношении один-ко-многим, то поле ключ таблицы 1 должно быть помещено в таблице 2 много.
Если две таблицы находятся в отношении многие-ко-многим, то требуется создать новую таблицу, содержащую ключи обеих исходных таблиц. Такая таблица называется таблицей пересечения.
Третий шаг: Определение атрибутов и ключей. Реляционная схема БД-список содержащий имена реляционных таблиц, имена атрибутов, ключевые атрибуты и внешние ключи. Ключ-минимальный набор атрибутов однозначно определяющий каждую строку реляционной таблицы. FK-набор атрибутов одной таблицы, являющийся ключем другой таблицы, используется для установления логической взаимосвязи между таблицами.
Преобразование ERD-модели в реляционной модели . Диаграмма ERD просто преобразуется в реляционную модель. Объекты (сущность) диаграммы становятся таблицами, а атрибуты столбцами, атрибуты-идентификаторы превращаются в первичные ключи. Преобразование ERD в реляционную модель можно выполнить с помощью case-системы, т.е. с помощью case-системы можно построить ERD, специфицировать внешние и первичные ключи, индексы, ограничения, и даже сформировать стандартный SQL код.
Инфологическая модель применяется на втором этапе проектирования БД, т.е. после словесного описания предметной области инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет читаться не только специалистами по базам данных. Описание должно быть емким, чтобы можно было оценить глубину и корректность проработки проекта БД, оно не должно быть привязано к конкретной СУБД. Выбор СУБД ─ это отдельная задача.
Инфологическое проектирование прежде всего связано с попыткой представления семантики предметной области в модели БД. Реляционная модель данных в силу своей простоты и лаконичности не позволяет отобразить семантику, то есть смысл предметной области.
В 70-х предложено несколько моделей данных, названных семантическими моделями.
И в настоящий момент именно модель Чена ⌠сущность─связь■, или Entity Relationship■, стала фактическим стандартом при инфологическом моделировании баз данных. Сокращенное название ER-модель, большинство современнных CASE-средств содержат инструментальные средства для описания данных в формализме этой модели. Разработаны методы автоматического преобразования проекта БД из ER-.модели в реляционную, при этом преобразование выполняется в даталогическую модель, соответствующую конкретной СУБД. Все CASE-системы имеют развитые средства документирования процесса разработки БД, автоматические генераторы отчетов позволяют подготовить отчет о текущем состоянии проекта БД с подробным описанием объектов БД и их отношений как в графическом виде, так и в виде готовых стандартных печатных отчетов, что существенно облегчает ведение проекта.
В настоящий момент не существует единой общепринятой системы обозначений для ER-модели и разные CASE-системы используют разные графические нотации, но разобравшись в одной, можно легко понять и другие нотации.
Сущность, с помощью которой моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Так как сущность соответствует некоторому классу однотипных объектов, то предполагается, что в системе существует множество экземпляров данной сущности. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов ─ характеристик, определяющих свойства данного представителя класса.
Между сущностями могут быть установлены связи (бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой). Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности.
Связи делятся на три типа по множественности: одип-к-одному (1:1), одии-ко-многим (1:М), многие-ко-многим (М:М). Связь один-к-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности. Связь 1: М означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи, а связь многие-ко-многим■ (М:М) означает, что один экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и наоборот. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками.
В реляционных БД даталогическое или логическое проектирование приводит к разработке схемы БД, то есть совокупности схем отношений, которые адекватно моделируют абстрактные объекты предметной области и семантические связи между этими объектами. Основой анализа корректности схемы являются так называемые функциональные зависимости между атрибутами БД. Некоторые зависимости между атрибутами отношений являются нежелательными из-за побочных эффектов и аномалий, которые они вызывают при модификации БД. При этом под процессом модификации БД мы понимаем внесение новых данных в БД или удаление некоторых данных из БД, а также обновление значений некоторых атрибутов. Однако этап логического или даталогического проектирования не заканчивается проектированием схемы отношений. В общем случае в результате выполнения этого этапа должны, быть получены следующие результирующие документы:
- Описание концептуальной схемы БД в терминах выбранной СУБД.
- Описание внешних моделей в терминах выбранной СУБД.
- Описание декларативных правил поддержки целостности базы данных.
- Разработка процедур поддержки семантической целостности базы данных.
- перед тем как описывать построенную схему в терминах выбранной СУБД, нам надо выстроить эту схему.
- Мы должны построить корректную схему БД, ориентируясь на реляционную модель данных.
Корректной назовем схему БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений.
Процесс разработки корректной схемы реляционной БД называется логическим проектированием БД.
Проектирование схемы БД может быть выполнено двумя путями:
путем декомпозиции (разбиения), когда исходное множество отношений, входящих в схему БД заменяется другим множеством отношений (число их при этом возрастает), являющихся проекциями исходных отношений;
путем синтеза, то есть путем компоновки из заданных исходных элементарных зависимостей между объектами предметной области схемы БД.
Классическая технология проектирования реляционных баз данных связана с теорией нормализации, основанной на анализе функциональных зависимостей между атрибутами отношений. Понятие функциональной зависимости является фундаментальным в теории нормализации реляционных баз данных. Функциональные зависимости определяют устойчивые отношения между объектами и их свойствами в рассматриваемой предметной области. Именно поэтому процесс поддержки функциональных зависимостей, характерных для данной предметной области, является базовым для процесса проектирования.
Процесс проектирования с использованием декомпозиции представляет собой процесс последовательной нормализации схем отношений, при этом каждая последующая итерация соответствует нормальной форме более высокого уровня и обладает лучшими свойствами по сравнению с предыдущей.