Логическое проектирование баз данных

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

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

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

Если какая-то таблица содержит внешний ключ, то она: а) логически связана с таблицей, содержащей соответствующий первичный ключ; б) эта связь имеет характер «один-ко-многим» (таблица, содержащая внешний ключ, находится на стороне «много» в этой связи).

По сути понятия «родитель» — «ребенок» в иерархических моделях, файл-«владелец» — файл-«член» в сетевых моделях и связь «ключ» — «внешний ключ» в реляционных моделях передают одно и то же явление — наличие связи 1 : М между записями соответствующих файлов.

В реляционных СУБД часто используется понятие «взгляд» (view). Он представляет собой виртуальную таблицу, полученную в результате логического соединения нескольких связанных по .значениям общих столбцов таблиц и, возможно, включающую некоторое подмножество из всей совокупности строк, отобранное по заданному условию. Это понятие расширяет традиционное для банков данных понятие «подсхема».

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

2.7 Переход от ER-модели к схеме реляционной базы данных

1. Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы. Каждый простой атрибут становится столбцом таблицы с тем же именем: R1 (И1 , А1 , А2 , А3 ).

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

длина ключа – в качестве первичного ключа выбирается, как правило, самый короткий из вероятных ключей;

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

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

Некоторые СУБД (Access, Paradox и др.) позволяют автоматически генерировать в качестве ключа таблицы поле типа «счетчик». Этот искусственный код можно использовать для простых объектов, если в предметной области не предполагается применение другой системы кодирования (ОКПО, ОКОНХ, ИНН).

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

3. Каждому из многозначных атрибутов ставится в соответствие отношение, полями которого будут идентификатор, выбранный в качестве первичного ключа, и многозначный атрибут. Ключ этого отношения будет составным, включающим оба эти атрибута. Для многозначных атрибутов МА4 и МА5 будут созданы отношения: R2 (И1 , МА4 ) и R3 (И1 ,МА5 ).

4. Если сущность имеет необязательный атрибут, возможны два варианта:

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

если свойством обладает малое число экземпляров, то можно выделить отношение, включающее идентификатор и соответствующий атрибут: R4 (И1 , НА6 ). Отношение будет содержать столько строк, сколько объектов имеет свойство.

5. Если сущность имеет составной атрибут, то возможны два варианта:

составному свойству ставится в соответствие отдельное поле;

каждому из составляющих элементов составного свойства ставится в соответствие отдельное поле.

Выбор варианта зависит от характера обработки данных. При реализации запросов проще объединить поля, чем выделить часть поля. Если предполагается использование компонентов атрибута, лучше вариант 2, иначе – вариант 1.

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

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

R3 (И1 , И2 , А1 , А2 ).

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

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

R1 (И1 , А1 , И2 )

R2 (И2 , А2 )

или

R1 (И1 , А1 )

R2 (И2 , А2 , И1 ).

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

Если класс принадлежности обеих сущностей является необязательным, то, чтобы избежать наличия пустых полей, следует использовать три отношения: по одному для каждой сущности и одно – для отображения связи между ними:

R1 (И1 , А1 )

R2 (И2 , А2 )

R3 (И1 , И2 ).

7. Преобразование бинарной связи один-ко-многим (1:N) зависит только от класса принадлежности N-связной сущности. Если он является обязательным, то можно использовать два отношения (по одному для каждой сущности). В отношение для N-связной сущности добавляется идентификатор 1-связной сущности:

R1 (И1 , А1 )

R2 (И2 , А2 , И1 ).

Если класс принадлежности N-связной сущности является необязательным, то для отображения связи создается третье отношение, которое будет содержать ключи каждой из связанных сущностей:

R1 (И1 , А1 )

R2 (И2 , А2 )

R3 (И1 , И2 ).

8. Для бинарной связи многие-ко-многим (М:N) потребуются три отношения: по одному для каждой сущности и одно дополнительное – для отображения связи между ними. Последнее отношение будет содержать идентификаторы связанных объектов. Ключ этого отношения будет составным:

R1 (И1 , А1 )

R2 (И2 , А2 )

R3 (И1 , И2 ).

9. В случае N-арной связи необходимо использовать (n+1) отношение – по одному для каждой сущности, и одно для связи. Идентификатор каждой сущности станет первичным ключом соответствующего отношения. Отношение, порождаемое связью, будет иметь среди своих атрибутов ключи каждой сущности. Если связь имеет атрибуты, то они становятся атрибутами отношения связи. Например:

R1 (И1 , А1 )

R2 (И2 , А2 )

R3 (И3 , А3 )

R4 (И1 , И2 , И3 , АС4 ).

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

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

Заключение

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

1. Одним из таких направлений является создание «Хранилищ данных» (Data Warehouse), осуществляющих функции предварительной подготовки и хранения данных для систем поддержки принятия решений (СППР).

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

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

Для поиска и выборки данных в процессе работы системы используется стратегия, называемая «оперативной аналитической обработкой» (On-line Analytical Processing, OLAP).

OLAP-системы строятся на основе двух базовых принципов:

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

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

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

Дальнейшее усложнение модели данных может выполняться следующими способами:

1. Увеличивается число измерений. Допустим, сведения о количестве поступивших товаров обобщаются не только по месяцам и товарам, но и по филиалам, магазинам, складам. Такой гиперкуб имеет пять измерений.

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

3. Вводится иерархия в пределах одного измерения. Например, год состоит из кварталов, квартал из месяцев, месяц из недель, неделя из дней.

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

При работе с гиперкубами могут использоваться две стратегии.

В системах MOLAP (Multidimensional OLAP) гиперкуб реализуется как отдельная база данных специальной не реляционной структуры, обеспечивающая максимально эффективный по скорости доступ к данным, но требующая дополнительных ресурсов памяти. Поэтому данные из хранилища вначале помещаются в специальную многомерную базу, а затем обрабатываются OLAP-сервером. Примерами таких систем являются Essbase (компания Arbor Software) и Oracle Express (Oracle).

Для систем ROLAP (Relational OLAP) гиперкуб – это лишь пользовательский интерфейс, который эмулируется на обычной реляционной СУБД. В этой структуре можно хранить очень большие объемы данных, однако ее недостаток заключается в низкой и неодинаковой эффективности OLAP-операций. Примеры таких систем – MetaCube (фирма Informix) и Discoverer 3.0 (Oracle).

Для подготовки решения в рамках OLAP-технологии пользователь анализирует срез данных по одному или нескольким измерениям.

Создание хранилищ данных, поддерживающих работу крупного предприятия, очень сложный и дорогостоящий процесс. Поэтому была предложена и реализована на практике идея «Витрины данных» (Data Mart).