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

Выделим следующие объекты:

1. ТОВАР - (Т);

2. ЗАКАЗЧИК - (З);

3. ПОСТАВЩИК - (П);

4. СЧЕТА - (С);

5. ДОГОВОР - (Д);

6. НАКЛАДНЫЕ - (Н).

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

 
 

  Т  
З   П
  С  
Н   Д

 

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

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

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

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

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

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

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

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

Транзитивная зависимость выявляет дублирование данных в одном отношении. Если А, В и С - три свойства одного отношения и С зависит от В, а В от А, то говорят, что С транзитивно зависит от А. Преобразование в третью нормальную форму происходит за счет разделения исходного отношения на два.

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

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

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

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

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

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

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

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

 

3. Модель "сущность-связь"

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

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

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

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

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

Компонентами ИЛМ являются информационные объекты и структурные связи между ними. ИО – это информационное отображение определенной сущности (отличимый объект реального мира). Сведения об ИО (о сущности) имеют вид атрибутов – реквизит (свойство), характеризующий сущность, и связей – ассоциирование двух или более сущностей. У каждой сущности ноль или более атрибутов. Если нет ни атрибутов, ни связей, то это не сущность. Каждый экземпляр сущности (строка таблицы) имеет ровно одно значение, возможно, NULL).

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

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

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

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

Функциональная связь имеется между ИО, если необходима совместная обработка данных, представленных соответствующими ИО. Реальные отношения могут быть нескольких типов: один к одному (1:1); один ко многим (1 : М); многие ко многим (М : М).

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

При связи один ко многим (1:М) одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А. В такой связи имеют место иерархические групповые отношения между экземплярами разных типов. При этом один ИО определяется как главный , а другой 0 как подчиненный..

Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В и наоборот. Такие отношения можно охарактеризовать как сетевые.

Модель сущность-связь представляется ER-диаграммами, представляющими сущность в виде прямоугольника, в котором записаны атрибуты сущности, а связи между сущностями указываются линиями. Например, отобразим две сущности «Заказчик» и «Товар» и связь между ними: