лабы / gorev_akhajan_makakshiripov_ehffektivnaja_rabota_s_subd

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

Типы моделей данных

Иерархическая и сетевая модели данных стали применяться в системах управления базами данных в начале 60-х годов. В начале 70-х годов была предложена реляционная модель данных. Эти три модели различаются в основном способами представления взаимосвязей между объектами.

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

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

Рис. 2.8.

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

www.books-shop.com

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

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

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

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

Этап 1. Определение сущностей

Исходя из задачи, описанной в первой главе, выделим следующие сущности:

1.МОДЕЛЬ;

2.АВТОМОБИЛЬ;

3.КЛИЕНТ;

4.ПРОДАВЕЦ;

5.ЗАКАЗ;

6.ПРОДАЖА;

7.СЧЕТ.

Этап 2. Определение взаимосвязей между сущностями

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

Необходимо отметить что на рис. 2.2,а взаимосвязь между объектами КЛИЕНТ и ЗАКАЗ рассматривается в определенный момент времени, для примера связи "один к одному". Однако анализируя данную взаимосвязь более широко, получим, что один клиент в разное время может производить несколько заказов. С другой стороны, один заказ принадлежит только одному клиенту и поэтому на рис. 2.12 между сущностями КЛИЕНТ и ЗАКАЗ установлена взаимосвязь "один ко многим".

Рис. 2.12.

Этап 3. Задание первичных и альтернативных ключей, определение атрибутов сущностей

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

www.books-shop.com

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

Атрибуты, включаемые в состав БД для рассматриваемой модели, приведены в табл. 2.1. Информационная модель после третьего этапа проектирования приведена на рис. 2.13.

Рис. 2.13.

Таблица 2.1. Атрибуты и первичные ключи сущностей информационной модели

Наименование

модели

Наименование

фирмы

Наименование

страны

Рабочий объем двигателя

Количество

цилиндров

Мощность Крутящий момент

Наименование

топлива

Максимальная

скорость

www.books-shop.com

Время разгона до

100 км/ч

Наименование шин

Наименование

кузова Количество дверей Количество мест Длина Ширина Высота

Расход топлива при

90 км/ч

Расход топлива при

120 км/ч

Расход топлива при городском цикле

АВТОМОБИЛЬ Уникальный ключ Уникальный ключ автомобиля автомобиля

Уникальный ключ клиента

Уникальный ключ модели

Уникальный ключ продавца

www.books-shop.com

ПРОДАВЕЦ Уникальный ключ Уникальный ключ продавца продавца

Фамилия

Имя

Отчество

Этап 4. Приведение модели к требуемому уровню нормальной формы

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

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

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

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

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

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

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

Транзитивная зависимость выявляет дублирование данных в одном отношении. Если A, B и C - три атрибута одного отношения и C зависит от B, а B от A, то говорят, что C транзитивно зависит от A, как это схематично показано на рис. 2.14,а. Преобразование в третью нормальную форму происходит за счет разделения исходного отношения на два, как это показано на рис. 2.14,б.

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

www.books-shop.com

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

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

Давайте сформулируем основные правила, которым нужно следовать при проектировании базы данных:

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

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

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

С учетом выше изложенного в нашей модели необходимо видоизменить список атрибутов сущности МОДЕЛЬ и добавить такие новые сущности, как ТОПЛИВО, ШИНЫ, КУЗОВ, ФИРМА, СТРАНА (рис. 2.15).

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

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

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

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

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

Таблица 2.2. Атрибуты и первичные ключи измененных или добавленных сущностей информационной модели

Сущность Первичный Атрибуты ключ

МОДЕЛЬ Уникальный ключ Уникальный ключ модели модели

Наименование модели

Уникальный ключ фирмы

Наименование страны

Рабочий объем двигателя

Количество цилиндров Мощность

www.books-shop.com