Тема 5. Средства и методы проектирования БД. Методика диаграмм взаимосвязей между объектами erd-диаграммы. Использование case-технологий при проектировании БД.

Методы и средства проектирования составляют центральную часть выполнения проекта любой БД.

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

Средства проектирования БД обеспечивают моделирование данных и генерацию схем данных на языке SQL для наиболее распространенных СУБД. Средства проектирования БД имеются в составе таких CASE - средств, как Oracle Designer, Paradigm Plus, Power Designer. Наиболее известным средством, ориентированным только на проектирование БД, является Erwin.

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

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

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

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

1. Этап анализа. Результаты:

Модель сущность-отношение

Диаграммы потока данных

ЖЦ сущностей

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

Уникальные идентификаторы

Функциональные определения

Функциональная декомпозиция

2. Этап проектирование. Результаты:

Определение таблиц

Определение столбцов

Ограничения таблиц

Триггеры

Физическая БД

Спецификация модулей

План тестирования системы.

3. Реализация.

 

Базовые понятия.

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

Экземпляры сущности - это конкретный экземпляр класса сущности.

Взаимосвязь - ассоциативная связь между объектами.

Атрибут - характеристика объекта.

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

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

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

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

Первичный ключ не может иметь значение NULL.

Внешний ключ может иметь либо значение первичного ключа на который он ссылается, либо значение NULL.

Домен атрибута - множество допустимых значений атрибута.

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

- один - к - одному

- один - ко многим

- многие ко многим

Необходимо избегать связи многие ко многим.

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

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

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

Это такие программы:

- ERWin фирмы Logic Words

- Desianer/2000 фирмы Oracle.

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

5.2. CASE - приложение ERwin

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

Примером CASE - системы является приложение ERwin.

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

Процесс построения модели в ERwin состоит из следующих шагов:

- определение объектов;

- определение связей между объектами;

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

- определение атрибутов объектов;

- преобразование модели к требуемому уровню нормальной формы (обычно к 3НФ);

- переход к физическому описанию модели: выбор целевой СУБД, назначение соответствий (имя объекта - имя таблицы, атрибут объекта - атрибут таблицы), задание триггеров, процедур и ограничений;

- генерация БД.

Плюсы ERwin

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

Применение ERwin существенно повышает эффективность разработчика ИС.

Основные преимущества:

- повышение скорости разработки ИС за счет мощного редактора диаграмм, автоматической генерации БД, автоматической подготовки документации;

- нет необходимости ручной подготовки SQL - кода для создания БД;

- обратное проектирование позволяет документировать и вносить изменения в существующие ИС;

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

Объекты в ERwin

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

Связь в Erwin

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

Существует три вида связей: один - к - одному, один - ко - многим, многие - ко - многим.

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

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

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

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

 

ERwin интегрирован с популярными программными средствами разработки клиентской части приложения - Power Builder, Visual Basic, что позволяет автоматически генерировать код приложения, который полностью готов к компиляции и выполнению.

После разработки модели данных в ERwin, ее следует связать с функциональной моделью в BРwin. Такая связь гарантирует завершение анализа, т.е. источник данных (сущность) существует для всех потребностей данных (функций). Связи объектов способствуют согласованности, корректности и завершению анализа.

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

 

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

Принципы логического (концептуального) проектирования.

Первый шаг:

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: М означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи, а связь многие-ко-многим (М:М) означает, что один экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и наоборот. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками.

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

- Описание концептуальной схемы БД в терминах выбранной СУБД.

- Описание внешних моделей в терминах выбранной СУБД.

- Описание декларативных правил поддержки целостности базы данных.

- Разработка процедур поддержки семантической целостности базы данных.

- перед тем как описывать построенную схему в терминах выбранной СУБД, нам надо выстроить эту схему.

Мы должны построить корректную схему БД, ориентируясь на реляционную модель данных.

Корректной назовем схему БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений.

Процесс разработки корректной схемы реляционной БД называется логическим проектированием БД.

Проектирование схемы БД может быть выполнено двумя путями:

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

Путем синтеза, то есть путем компоновки из заданных исходных элементарных зависимостей между объектами предметной области схемы БД.

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

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