Малков О.Б., Гегечкори Е.Т. Базы данных

Подождите немного. Документ загружается.

коллективной разработке проекта – при обсуждении модели с конечными

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

модели, которая имеет для него интерес. Декомпозиция модели облегчает

процесс проектирования.

Еще одним критерием сравнения СASE-средств является степень

проверки правильности построенных моделей. Ни одна система

автоматизации проектирования не может гарантировать соответствия

построенной концептуальной модели реалиям предметной области. Это

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

предметной области и умением отобразить ее в модели.

Наличие средств проверки моделей может помочь устранить ошибки,

связанные с невнимательностью – отсутствие идентификатора у сущности,

отсутствие связи объекта с другими объектами, неправильное задание имен,

отсутствие информации, необходимой при дальнейшем проектировании

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

п.), противоречия в модели (что особенно важно при коллективной

разработке) и др.

Многие CASE-средства этим позволяют задавать в модели ограничения

целостности и генерируют программы (триггеры, хранимые процедуры),

проверяющие эти ограничения при эксплуатации БД. Кроме того, CASE-

средства могут генерировать программы ведения БД.

Многие CASE-средства позволяют экспортировать модели в другие

системы и, наоборот, импортировать их из других систем.

4.2. Пример нотации ER-модели – метод IDEF1X

Методики представления ER-моделей, используемые в разных

литературных источниках, а также в разных CASE-системах, несколько

отличаются друг от друга. В ряде CASE-средств (ERwin, ERStudio)

реализован метод IDEF1X, входящий в семейство стандартов IDEF. Метод

разработан для армии США и широко используется в государственных

учреждениях, финансовых и промышленных корпорациях. Он прост в

изучении и обеспечивает возможность автоматизации. Позволяет построить

модель данных, эквивалентную РМД, приведенной к 3НФ.

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

косой чертой и помещаемые над блоком (рис. 27). Первичный ключ (Primary

Key) – это атрибут (атрибуты), однозначно идентифицирующий экземпляр

сущности. На диаграмме первичные ключи размещаются выше

горизонтальной линии.

Рис. 27. Графическое обозначение сущности в IDEF1X

В одной сущности может быть несколько потенциальных ключей

(Candidate Key) – атрибутов, претендующих на роль первичного ключа.

Альтернативный ключ (Alternate Key) – потенциальный ключ, не ставший

первичным. На диаграмме обозначается AK n.m, где n – номер ключа, m –

номер атрибута в ключе. Инверсионный вход (Inversion Entries) – это атрибут

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

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

экземплярам. На диаграмме обозначается IE n.m, где n – номер

инверсионного входа, m – номер атрибута во входе.

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

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

сущностями. Сущность является зависимой, если однозначная

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

сущности. Ассоциированная (ассоциативная) сущность – сущность,

связанная с двумя и более другими сущностями. Изображения независимой и

зависимой сущностей показаны на рис. 28.

Рис. 28. Зависимая и независимая сущности

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

сущностями модели. Одна из участвующих в связи сущностей называется

родительской сущностью, другая – дочерней или сущностью-потомком.

Связи именуются глаголами или глагольными фразами, которые

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

сотрудника с заказом может быть определена следующим образом (рис. 29):

 СОТРУДНИК выполняет один или более ЗАКАЗОВ;

 ЗАКАЗ должен выполняться ровно одним СОТРУДНИКОМ.

Рис. 29. Связи на диаграмме

На логическом уровне можно установить:

1) идентифицирующую связь один-ко-многим (обозначается );

2) неидентифицирующую связь один-ко-многим (обозначается ----);

3) связь многие-ко-многим (обозначается ).

При установлении идентифицирующей связи дочерняя сущность

автоматически превращается в зависимую. Атрибуты первичного ключа

родительской сущности автоматически мигрируют в зону атрибутов

первичного ключа дочерней сущности как внешние ключи (Foreign Key) (рис.

30).

Рис. 30. Идентифицирующая связь

При установлении неидентифицирующей связи дочерняя сущность не

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

мигрируют в область неключевых атрибутов дочерней сущности (рис. 31).

Рис. 31. Неидентифицирующая связь

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

ключа получит признак NOT NULL, хотя внешний ключ не войдет в состав

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

внешний ключ может принимать значение NULL. Необязательная

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

родительской сущности.

Мощность связи обозначает отношение числа экземпляров родительской

сущности к числу экземпляров дочерней сущности. Различают случаи

(рис.Z32):

1) когда одному экземпляру родительской сущности соответствует 0, 1

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

2) когда одному экземпляру родительской сущности соответствует 0

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

3) когда одному экземпляру родительской сущности соответствует один

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

4) когда одному экземпляру родительской сущности соответствует

заданное число экземпляров дочерней сущности (например, 5).

Рис. 32. Мощность связи

Иерархия наследования – особый тип объединения сущностей, имеющих

общие характеристики. Например, из общих свойств постоянных

сотрудников и совместителей можно сформировать обобщенную сущность

(предок) СОТРУДНИК. Специфическая информация может быть

расположена в категориальных сущностях (потомках) ПОСТОЯННЫЙ

СОТРУДНИК и СОВМЕСТИТЕЛЬ (рис. 33).

Рис. 33. Иерархия наследования

Дискриминатор – атрибут родового предка, который показывает, как

отличить одну категориальную сущность от другой. В нашем примере – это

тип.

Категория является неполной, если в родовом предке могут существовать

экземпляры, не имеющие экземпляров в потомках. Например, сотрудник

может быть консультантом, но сущность КОНСУЛЬТАНТ не внесена в

иерархию. Возможна комбинация полной и неполной категорий (рис. 34).

Рис. 34. Комбинация полной и неполной категорий

Отношения многие-ко-многим являются неспецифическими для РБД.

Они могут быть установлены в концептуальной (в CASE – логической)

модели. На этапе создания даталогической (в CASE – физической) модели

такие отношения потребуют разрешения. CASE-средства автоматически

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

(ассоциативных) сущностей.

Неспецифическое отношение на рис. 35 указывает, что СТУДЕНТ может

изучать много ПРЕДМЕТОВ, а ПРЕДМЕТ может изучаться многими

СТУДЕНТАМИ. Мы не можем определить, какой студент изучает какой

предмет, пока не введем третью (ассоциативную) сущность ИЗУЧЕНИЕ

ПРЕДМЕТА. Каждый экземпляр введенной сущности связан с одним

студентом и с одним предметом (рис. 36).

Рис. 35. Отношение многие-ко-многим

Рис. 36. Разрешение отношения многие-ко-многим

4.3. Автоматическая генерация базы данных

На рис. 37 показан интерфейс CASE-средства ER/Studio.

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

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

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

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

атрибуты отображаются в Проводнике.

Рис. 37. Интерфейс CASE-средства ER/Studio

Генерация физической модели осуществляется автоматически. В

некоторых средствах используется Мастер, проводящий пользователя через

все этапы.

В CASE-средстве ER/Studio генерация физической модели

осуществляется по команде Create Physical Model за восемь шагов.

1. Определяется имя физической модели, из списка выбирается целевая

платформа будущей БД, принимается решение о проверке правильности

модели.

2. Выбираются объекты (таблицы), включаемые в физическую модель.

Определяется способ обработки внешних ключей от не вошедших в модель

таблиц.

3. Принимается решение о включении или невключении в физическую

модель подмоделей и текстовых блоков логической модели. Определяется

способ разрешения связей многие-ко-многим.

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

таблиц (для первичных, альтернативных ключей, инверсионных входов и

т.Zд.). Принимается решение, будет ли добавляться префикс к названию

таблиц.

5. Определяется, как будут обрабатываться пробелы и символы

верхнего и нижнего регистра в названиях.

6. Выбирается логика проверки законченности и целостности таблиц

(таблицы без столбцов, таблицы без первичных ключей, таблицы с типом

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

7. Выбирается логика проверки соглашения об именах (длина имен,

проверка ключевых слов, которые не должны использоваться как названия и

т.Zд.).

8. Выбирается способ проверки целостности индексов таблицы

(проверка таблиц без индексов, проверка таблиц с индексами,

превышающими пределы).

Настройки, предлагаемые Мастером по умолчанию, во многих случаях

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

формируется отчет с информацией об ошибках, обнаруженных в процессе

создания модели.

Следующим шагом является генерация кода. Возможны разные

варианты воплощения физической модели. Пользователь должен определить,

как реализовать ссылочную целостность, связи через первичные и внешние

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

администратора БД важна настройка физических хранилищ и т. д. Эти

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

командой Generate Target SQL.

1. Выбираются таблицы и представления для включения в генерацию

кода БД.

2. Определяется, как будут реализованы первичные и альтернативные

ключи.

3. Определяется, будут ли генерироваться неуникальные индексы и

триггеры и как будет осуществляться ссылочная целостность.

4. Определяются параметры имеющихся в наличии физических

хранилищ.

5. Выбираются дополнительно к таблицам, индексам и триггерам

другие типы объектов БД. Можно генерировать правила, значения по

умолчанию, типы данных, определяемые пользователем, хранимые

процедуры иZт.Zд.

6. Выбирается вариант генерации исходного текста SQL или генерации

объектов БД. Генерация SQL-скрипта позволяет создать БД в любое другое

время.

7. Принимается решение, будет ли использована для генерации

существующая БД или же создана новая. Создается источник данных ODBC.

После генерации БД на экран выводится отчет о создании БД. Наиболее

распространенная ошибка – задание типов данных, не поддерживаемых

выбранной платформой БД. После генерации БД работа с CASE-средством

закончена. Созданная БД может быть открыта уже непосредственно из

СУБД.

5. РАСПРЕДЕЛЕННАЯ ОБРАБОТКА ДАННЫХ

5.1. Требования к распределенным базам данных

Распределенная база данных (DDB – Distributed DataBase) – это

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

компьютерной сети. БД распределена физически, но логически едина (имеет

общую схему данных).

В системах с распределенными БД используются разные технологии

распределения данных по узлам сети – фрагментация и тиражирование.

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

составные части (фрагменты), хранящиеся в разных узлах сети. Разбиение

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

критериям.

При использовании тиражирования в нескольких узлах сети создаются

и поддерживаются в согласованном состоянии (синхронизируются) копии

всей БД или ее фрагментов. Копия БД называется репликой.

В системах с централизованной БД (много клиентов/один сервер)

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

сервере. В системах с распределенной БД проектирование, реализация

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

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

Технологии распределения данных видоизменяют преимущества и

недостатки систем. Одно из преимуществ БД – сокращение дублирования –

теряется при использовании тиражирования. При этом сохраняются

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

Ведущими поставщиками СУБД сформулированы следующие свойства

идеальной системы управления распределенными БД:

 прозрачность относительно расположения данных – СУБД должна

представлять все данные так, как если бы они были локальными;

 гетерогенность системы – СУБД должна работать с данными,

которые хранятся в системах с различной архитектурой и

производительностью;

 прозрачность относительно сети – СУБД должна одинаково

работать в условиях разнородных сетей;

 поддержка распределенных запросов – пользователь должен иметь

возможность объединять данные из любых баз, даже размещенных в разных

системах;

 поддержка распределенных изменений – пользователь должен иметь

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

есть права;

 поддержка распределенных транзакций – СУБД должна выполнять

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

поддерживать целостность БД при возникновении отказов как в системах, так

и в сети;

 безопасность – СУБД должна обеспечивать защиту всей распре-

деленной БД от несанкционированного доступа;

 универсальность доступа – СУБД должна обеспечивать единую

методику доступа ко всем данным.

Ни одна из существующих СУБД не достигает этого идеала поскольку:

 низкая и несбалансированная производительность сетей снижает

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

 обеспечение целостности данных в распределенных транзакциях

базируется на принципе «все или ничего» и требует специального протокола,

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

 необходимо обеспечить совместимость данных, для хранения

которых в разных системах используются разные форматы и кодировки;

 если каталог хранится в одной системе, то удаленный доступ будет

замедлен; если будет размножен – изменения придется синхронизировать;

 необходимо обеспечить совместимость СУБД разных типов и

поставщиков;

 велика потребность в ресурсах для обнаружения и устранения

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

Эти причины определили поэтапность введения в СУБД возможностей

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

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

СУБД сама проводит аутентификацию удаленного клиента и устанавливает

сетевое соединение.

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

выделить два класса систем:

 системы распределенной обработки данных;

 системы распределенных баз данных.

Системы распределенной обработки данных базировались на

многопользовательских операционных системах с БД на центральном

компьютере. Клиентские места реализовались в виде терминалов, не

имеющих собственных ресурсов. Развитие сетевых технологий, распро-

странение персональных ЭВМ и стандартов открытых систем привело к

появлению систем распределенных БД, размещенных в сети разнотипных

компьютеров. Система состоит из узлов, каждый из которых является СУБД.

БД любого узла доступна пользователю.

При обработке данных в сетевой среде выделяют следующие группы

функций:

 презентационная логика (PL – Presentation Logic): ввод и

отображение данных – внешний (пользовательский) уровень реализации

функциональной обработки и представления;

 бизнес-логика (BL – Business Logic): функциональная обработка,

реализующая алгоритм решения задач пользователя;

 манипулирование данными БД в рамках приложения, которое

обычно реализуется средствами SQL (DL – Database Logic);

 управление данными и другими ресурсами БД, реализуемое

внутренними средствами конкретной СУБД обычно в рамках файловой

системы ОС;

 управление процессами обработки: связывание и синхронизация

процессов обработки данных разного уровня.