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

Лекции: 4 часа

 

Первый шаг:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.1. Правила отношений между сущностями. Определение ключей

Правила формирования отношений основывается на учете следующего:

- степени связи между сущностями (1:1, 1:М, М:1, М:М);

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

Рассмотрим формулировки шести правил формирования отношений на основе диаграмм ER - типа.

Формирование отношения для связи 1:1

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

На рис. 6.1 приведены диаграмма ER - типа и отношение, сформированное по правилу 1 на ее основе.

 

 

 

 

 

Рисунок 6.1. Диаграмма и отношения для правила 1

 

Обозначения: С1, С2 - сущности 1 и 2;

К1, К2 - ключи первой и второй сущности соответственно;

R1 - отношение 1, сформированное на основе первой и второй сущностей;

К1К2 - означает, что ключом сформированного отношения может быть либо К1, либо К2.

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

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

Формирование отношений для связи 1:М

Если две сущности С1 и С2 связаны как 1:М, сущность С1 будем называть односвязной (1-связной), а сущность С2 - многосвязной (м-связной). Определяющим фактором при формировании отношений, связанных этим видом связи, является класс принадлежности м-связной сущности. Так, если класс принадлежности м-связной сущности обязательный, то в результате применения правила получим два отношения, если необязательный - три отношения. Класс принадлежности односвязной сущности не влияет на результат.

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

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

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

Формирование отношений для связи М:М

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

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

Первичные и внешние ключи

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

Если строго, то пусть R - некоторое отношение. Тогда первичный ключ К для R - это подмножество атрибутов R, обладающее свойствами:

1. свойством уникальности - нет двух различных кортежей в R с одинаковым значением К;

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

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

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

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

Формализованное определение: пусть R2 - базовое отношение. Тогда внешний ключ FK в отношении R2 - это подмножество множества R2, такое, что:

1. существует базовое отношение R1 с первичным ключом К;

2. каждое значение FK в текущем значении R2 является или null-значением, или совпадает со значением К некоторого кортежа в текущем значении R1.

Говорят, что внешний ключ одной таблицы является ссылкой на первичный ключ другой таблицы.

ПОЯСНЕНИЯ:

1. Null-значение - специальный маркер, используемый для представления отсутствующей информации (это не нули или пробелы);

2. Метаправило целостности объектов: ни один элемент первичного ключа базового отношения не может быть null-значением;

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

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

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

6. Метаправило ссылочной целостности: БД не должна содержать несогласованных значений внешних ключей. То есть если В ссылается на А, тогда А должно существовать.

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

(ограничить операцию удаления до определенного момента; каскадировать операцию удаления)

Синтаксис определения внешнего ключа:

 

FOREING KEY (Имя атрибута) REFERENCES ИмяСсылочногоБазовогоОтношения

                                                                                    DELETE (RESRRICTED / CASCADES)                                       UPDATE (RESRRICTED / CASCADES)

NULLS (ALLOWED / NOT ALLOWED)

где:

RESRRICTED √ ограничить,

CASCADES √ каскадировать,

ALLOWED √ null-значения допустимы,

NOT ALLOWED - null-значения не допустимы.