обозначения .

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

В рассмотренных ранее примерах стержни - это "Студент", "Квартира", "Мужчины", "Врач", "Брак" (из примера 2.2) и другие, названия которых помещены в прямоугольники.

Ассоциативная сущность (ассоциация ) - это связь вида "многие-ко-многим" ("-ко-многим" и т.д.) между двумя или более сущностями или экземплярами сущности (как в примере 2.4). Ассоциации рассматриваются как полноправные сущности:

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

могут обладать свойствами, т.е. иметь не только набор ключевых атрибутов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь. Например, ассоциации "Брак" из примеров 2.1 и 2.4 содержат ключевые атрибуты "Код_М", "Код_Ж" и "Табельный номер мужа", "Табельный номер жены", а также уточняющие атрибуты "Номер свидетельства", "Дата регистрации", "Место_регистрации", "Номер записи в книгу ЗАГС" и т.д.

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

Существование характеристики полностью зависит от характеризуемой сущности: женщины лишаются статуса жен, если умирает их муж.

Для описания характеристики используется новое предложение ЯИМ, имеющее в общем случае вид:

ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, ...) {СПИСОК ХАРАКТЕРИЗУЕМЫХ СУЩНОСТЕЙ}.

Расширим также язык ER-диаграмм, введя для изображения характеристики трапецию (рис. 2.2).

Рис. 2.2. Элементы расширенного языка ER-диаграмм

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

Рассмотрим пример, связанный с зачислением сотрудников в различные отделы организации.

При отсутствии жестких правил (сотрудник может одновременно зачисляться в несколько отделов или не зачисляться ни в один отдел) необходимо создать описание с ассоциацией Зачисление:

Отделы (Номер отдела, Название отдела, ...) Служащие (Табельный номер, Фамилия, ...) Зачисление [Отделы M, Служащие N] (Номер отдела, Табельный номер, Дата зачисления).

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

Отделы (Номер отдела, Название отдела, ...) Служащие (Табельный номер, Фамилия, ... , Номер отдела, Дата зачисления)[Отделы]

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

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

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

ОБОЗНАЧЕНИЕ (атрибут 1, атрибут 2, ...)[СПИСОК ОБОЗНАЧАЕМЫХ СУЩНОСТЕЙ].

Как правило, обозначения не рассматриваются как полноправные сущности, хотя это не привело бы к какой-либо ошибке.

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

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

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

Рис. 2.3. Пример кулинарного рецепта

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

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

Анализ объектов позволяет выделить:

• стержни Блюда, Продукты и Города;
• ассоциации Состав (связывает Блюда с Продуктами) и

Поставки (связывает Поставщиков с Продуктами);

• обозначение Поставщики;
• характеристики Рецепты и Расход.

ER-диаграмма модели показана на рис. 2.4. а модель на языке ЯИМ имеет следующий вид:

Блюда (БЛ, Блюдо, Вид) Продукты (ПР, Продукт, Калорийность) Поставщики (ПОС, Город, Поставщик) [Город] Состав [Блюда M, Продукты N] (БЛ, ПР, Вес (г)) Поставки [Поставщики M, Продукты N] (ПОС, ПР, Дата_П, Цена, Вес (кг)) Города (Город, Страна) Рецепты (БЛ, Рецепт) {Блюда} Расход (БЛ, Дата_Р, Порций) {Блюда}

В этих моделях Блюдо, Продукт и Поставщик - наименования, а БЛ, ПР и ПОС - цифровые коды блюд, продуктов и организаций, поставляющих эти продукты.

Рис. 2.4. Инфологическая модель базы данных "Питание"

[ Назад ] [ Содержание ] [ Вперед ]

Базы данных: Классификация сущностей

страницы в данном разделе

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

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

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

Таблица 4.5

Описание типов сущностей Тип сущности Примечание Номер заказа Номер заказа Дата заказа Дата заказа Номер товара Номер товара Наименование Цена товара Цена товара Стоимость Стоимость Вычисляется: Стоимость Стоимость Вычисляется: 511М(<7>) по заказу <1> Символьная стоимость Символьная стоимость заказа Формируется переводом числового значения в символьное выражение Количество Количество

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

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

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

Числовые тины данных и приравненный к ним логический тип данных всегда имеют фиксированную размерность:

• Boolean, Logical, Tinylnt, Bit - логический (Boolean, Logical) тин данных, содержащий значения "True" (истина) и "False" (ложь), идентичен малому целочисленному тину (Tinylnt) или биту (Bit) с минимальной размерностью 1 байт (1 бит при идентичности типу Bit) и значениями "О" или "1";
• Bit - целочисленный тип данных, представляющий значения "О" или "1", размерностью 1 бит;
• Tinylnt - целочисленный тип данных размерностью 1 байт;
• Smalllnt - целочисленный тип данных размерностью 2 байта;
• Integer - целочисленный тип данных размерностью 4 байта;
• Biglnt, Long - целочисленный тип большой размерности (8 байт);
• Date - тип данных даты, представляемый в символьном варианте, размерностью 8 символов (байт);
• Time - тип данных времени, представляемый в символьном варианте, размерностью 8 символов (байт).

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

Text, CLOB - текстовый тип данных, представляющий большие текстовые сведения, хранимые особым образом, а в таблице базы данных показываются набором первых символов, количество которых является размерностью атрибута данного типа;

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

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

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

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

Информационная модель предметной области базы данных содержит следующие основные конструкции:

• диаграммы " сущность-связь " (Entity - Relationship Diagrams);
• определения сущностей;
• уникальные идентификаторы сущностей ;
• определения атрибутов сущностей ;
• отношения между сущностями;
• супертипы и подтипы.

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

Сущности, атрибуты и идентификаторы (ключи) сущности, домены атрибутов

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

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

Внимание! При представлении сущности в базе данных хранятся только ее атрибуты.

Одним из основных компьютерных способов распознавания сущностей в базе данных является присвоение сущностям идентификаторов (Entity identifier). Часто идентификатор сущности называют ключом. Задача выбора идентификатора сущности является семантически субъективной задачей. Поскольку сущность определяется набором своих атрибутов, то для каждой сущности целесообразно выделить такое подмножество атрибутов, которое однозначно идентифицирует данную сущность.

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

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

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

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

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

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

Отношения, связи

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

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

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

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

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

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

Подтипы и супертипы

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

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

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

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

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

Термин «реляционный» означает «основанный на отношениях». Реляционная база данных состоит из сущностей (таблиц), находящихся в некотором отношении друг с другом. Название произошло от английского слова relation-отношение.
Проектирование базы данных состоит из двух основных фаз: логического и физического моделирования.
Во время логического моделирования вы собираете требования и разрабатываете модель базы данных, не зависящую от конкретной СУБД (системы управления реляционными базами данных). Это похоже на то, как если бы вы создавали чертежи вашего дома. Вы могли бы продумать и начертить все: где будет кухня, спальни, гостиная. Но это все на бумаге и в макетах.
Во время физического моделирования вы создаете модель, оптимизированную для конкретного приложения и СУБД. Именно эта модель реализуется на практике. Если вернуться к дому из предыдущего абзаца, на этом этапе вам придется строить где-нибудь дом - таскать бревна, кирпичи…

Процесс проектирования базы данных состоит из следующих этапов:

• сбор информации;
• определение сущностей;
• определение атрибутов для каждой сущности;
• определение связей между сущностями;
• нормализация;
• преобразование к физической модели;
• создание базы данных.

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

Логическая фаза

Логическая фаза состоит из нескольких этапов. Далее они все рассмотрены.

Сбор требований

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

Определение сущностей

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

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

Сущности состоят из атрибутов (столбцов таблицы) и записей (строк в таблице).

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

Любая таблица имеет следующие характеристики:

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

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

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

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


Для каждого атрибута определяется тип данных, их размер, допустимые значения и любые другие правила. К их числу относятся правила обязательности заполнения, изменяемости и уникальности.
Правило обязательности заполнения определяет, является ли атрибут обязательной частью сущности. Если атрибут является необязательной частью сущности, то он может принимать NULL-значение, иначе - нет.
Также вы должны определить, является ли атрибут изменяемым. Значения некоторых атрибутов не могут измениться после создания записи.
И, наконец, вам нужно определить, является ли атрибут уникальным. Если это так, то значения атрибута не могут повторяться.

Ключи

Ключом (key) называется набор атрибутов, однозначно определяющий запись. Ключи делятся на два класса: простые и составные.
Простой ключ состоит только из одного атрибута. Например, в базе «Паспорта граждан страны» номер паспорта будет простым ключом: ведь не бывает двух паспортов с одинаковым номером.
Составной ключ состоит из нескольких атрибутов. В той же базе «Паспорта граждан страны» может быть составной ключ со следующими атрибутами:
фамилия, имя, отчество, дата рождения. Это - как пример, т. к. этот составной ключ, теоретически, не обеспечивает гарантированной уникальности записи.
Также существует несколько типов ключей, о которых рассказано далее.

Возможный ключ

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

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

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

Альтернативные ключи

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

Внешние ключи

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

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

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

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

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

Каждой записи первой сущности соответствует только одна запись из второй сущности. А каждой записи второй сущности соответствует только одна запись из первой сущности. Например, есть две сущности: Люди и Свидетельства о рождении. И у одного человека может быть только одно свидетельство о рождении.

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

Каждой записи первой сущности могут соответствовать несколько записей из второй сущности. Однако каждой записи второй сущности соответствует только одна запись из первой сущности. Например, есть две сущности: Заказ и Позиция заказа. И в одном заказе может быть много товаров.

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

Каждой записи первой сущности могут соответствовать несколько записей из второй сущности. Однако и каждой записи второй сущности может соответствовать несколько записей из первой сущности. Например, есть две сущности: Автор и Книга. Один автор может написать много книг. Но у книги может быть несколько авторов.
По критерию обязательности отношения делятся на обязательные и необязательные.

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

Нормализация

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

Первая нормальная форма

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

Для приведения сущности Дом в первую нормальную форму необходимо удалить повторяющиеся группы значений, т. е. удалить атрибуты Владелец 1-3, поместив их в отдельную сущность. Результат (Сущность Дом, приведенная к первой нормальной форме):

Вторая нормальная форма

Таблица во второй нормальной форме содержит только те данные, которые к ней относятся. Значения не ключевых атрибутов сущности зависят от первичного ключа. Если более точно, то атрибуты зависят от первичного ключа, от всего первичного ключа и только от первичного ключа.
Для соответствия второй нормальной форме сущности должны быть в первой нормальной форме.
Например, у сущности Дом на рисунке есть атрибут Цена литра бензина, который не имеет ничего общего с домами. Этот атрибут удаляется (или вы можете перенести его в другую сущность). А также мы переносим атрибут Мэр в отдельную сущность - этот атрибут зависит от города, где находится дом, а не от дома.
На рисунке изображена сущность Дом во второй нормальной форме (Сущность Дом, приведенная ко второй нормальной форме).

Третья нормальная форма

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

Ограничения

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

Хранимые процедуры

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

ПРИМЕЧАНИЕ
Хранимые процедуры находятся в базе данных и выполняются на сервере базы данных. Как правило, они быстрее операторов SQL, поскольку хранятся в компилированном виде.

Целостность данных

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

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

Триггеры

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

Деловые правила

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

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

Все эти возможности можно применять для реализации деловых правил в базе данных.

Физическая модель

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

Денормализация

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

Атрибут.

Предметная область.

Банк данных. Определение.

СУБД. Определение.

База данных. Определение.

Третья нормальная форма. Определение. Пример.

Переменная отношения R находится в третьей нормальной форме тогда и только тогда, когда выполняются следующие условия:

· R находится во второй нормальной форме.

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

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

База данных - это один или несколько файлов данных, предназначенных для хранения, изменения и обработки больших объемов взаимосвязанной информации, систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ)

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

Банк данных - автоматизированная информационная система централизованного хранения и коллективного использования данных. В состав банка данных входят одна или несколько баз данных, справочник баз данных, СУБД, а также библиотеки запросов и прикладных программ.

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

Атрибут – наименьшая единица структуры данных. К каждому элементу при создании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке.

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

Перечислите функции СУБД

Основные функции СУБД:

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

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

3) Обеспечение логической и физической независимости данных.

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

5) Защита физической целостности - средства восстановления базы данных (транзакции).

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

7) Синхронизация работы нескольких пользователей.

8) Управление ресурсами среды хранения - СУБД выделяет ресурсы памяти для новых данных, перераспределяет освободившуюся память, организует ведение очереди запросов к внешней памяти и тому прочее.

9) Поддержка деятельности системного персонала