40. Проектирование базы данных (бд). Краткая характеристика этапов проектирования бд (нет)

41. Инфологическое (концептуальное) моделирование. Краткая характеристика этапов инфологического моделирования

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

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

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

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

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

Определение атрибутов сущности

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

Атрибуты – данные, описывающие свойства сущности. Примеры атрибутов: фамилия, цвет, стоимость, дата.

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

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

Тип сущности – признак принадлежности к некоторому классу (множеству) объектов (явлений). Тип сущности характеризуется множеством ее атрибутов.

Экземпляр сущности – конкретный объект, принадлежащий определенному классу объектов. Экземпляр сущности определяется значениями ее атрибутов.

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

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

В приведенном ранее примере атрибут «номер телефона» становится кандидатом на создание сущности «номер телефона».

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

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

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

При реализации модели на языке конкретной СУБД домены приводятся в соответствие с имеющимися типами данных.

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

Определение связи между сущностями. После определения сущностей следует описать связи (взаимоотношения) между ними.

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

Виды связей:

• Один-к-одному

• Один-ко-многим

• Многие-ко-многим

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

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

Возможное применение связи «один-к-одному» – хранить отдельно некоторый набор секретных атрибутов, для доступа к которым нужны более высокие привилегии. Пример – связь между сущностями «клиент» и «кредитная карта».

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

Пример связи «один-ко-многим» – связь между клиентом и его заказами. Клиент может сделать много заказов (или ни одного), но заказ может быть связан только с одним клиентом. Другой пример: в кошельке может одновременно находиться много денежных банкнот, но каждая банкнота в определенный момент времени может находиться не более, чем в одном кошельке.

Между приведенными примерами есть отличие: заказ обязательно должен быть связан с 1 клиентом (без клиента он не существует), а банкнота может быть связана с 0 кошельков или с 1 кошельком (она способна существовать без кошелька).

«Один-ко-многим» - самый распространенный вид связи в реляционных базах данных.

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

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

Реляционная модель баз данных не позволяет реализовать связь «многие-ко-многим». Эта проблема может быть решена введением дополнительной сущности.

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

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

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

Первая нормальная форма (1NF)

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

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

Вторая нормальная форма (2NF)

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

Третья нормальная форма (3NF)

Согласно определению Кодда, таблица находится в 3НФ тогда и только тогда, когда выполняются следующие условия:

• Отношение R (таблица) находится во второй нормальной форме;

• Каждый непервичный атрибут R находится в нетранзитивной (то есть прямой) зависимости от каждого ключа R.

Таким образом, отношение находится в 3NF тогда и только тогда, когда оно находится во 2NF и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых. Транзитивной зависимостью неключевых атрибутов от ключевых называется следующая: A → B и B → C, где A — набор ключевых атрибутов (ключ), B и С — различные множества неключевых атрибутов.

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

Нормальная форма Бойса — Кодда (BCNF)

Это более строгая версия третьей нормальной формы.

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

Четвёртая нормальная форма (4NF)

Таблица находится в 4NF, если она находится в BCNF и не содержит нетривиальных многозначных зависимостей. Многозначная зависимость не является функциональной, она существует в том случае, когда из факта, что в таблице содержится некоторая строка X, следует, что в таблице обязательно существует некоторая определённая строка Y. То есть, таблица находится в 4NF, если все ее многозначные зависимости являются функциональными.

Пятая нормальная форма (5NF)

Таблица находится в 5NF, если она находится в 4NF и любая многозначная зависимость соединения в ней является тривиальной. Пятая нормальная форма в большей степени является теоретическим исследованием и практически не применяется при реальном проектировании баз данных. Это связано со сложностью определения самого наличия зависимостей «проекции — соединения», поскольку утверждение о наличии такой зависимости должно быть сделано для всех возможных состояний БД.

Доменно-ключевая нормальная форма (DKNF)

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

Шестая нормальная форма (6NF)

Введена К. Дейтом в его книге, как обобщение пятой нормальной формы для темпоральной базы данных.