Любая сущность отличная от других сущностей. Основные понятия реляционной модели данных

Основные понятия реляционной модели данных

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

Сущность – это любой различимый, отличный от других, реальный или воображаемый, объект, информация о котором будет храниться в базе данных. Понятие сущности относится к основополагающим понятиям теории баз данных и используется для моделирования класса однотипных объектов. В рамках рассматриваемой предметной области в процессе ее анализа выделяются сущности (классы объектов) и экземпляры объектов. Например, для химической базы данных можно выделить сущность (класс объектов) ХИМИЧЕСКИЙ ЭЛЕМЕНТ и экземпляры объектов – отдельные химические элементы, например, ВОДОРОД или ГЕЛИЙ. Каждый класс объектов имеет свое уникальное в рамках предметной области имя, позволяющее отличить одну сущность от другой.

Каждый объект, относящийся к данной сущности, имеет свой набор атрибутов – характеристик, определяющих свойства данного класса объектов и позволяющих однозначно идентифицировать объект и отличить его от других. Все экземпляры объектов, принадлежащие одной сущности, имеют одинаковый набор атрибутов и различаются только значениями атрибутов. Так, например, сущность ХИМИЧЕСКИЙ ЭЛЕМЕНТ имеет такие атрибуты, как ПОРЯДКОВЫЙ НОМЕР, НАИМЕНОВАНИЕ, СИМВОЛ, АТОМНАЯ МАССА и ряд других. Каждый атрибут сущности имеет свое уникальное имя, однако разные сущности могут иметь одинаковые названия атрибутов. Например, атрибут ПОРЯДКОВЫЙ НОМЕР может быть у любого упорядоченного множества объектов.

Домен – это диапазон значений, которые может принимать атрибут. Домен может быть задан перечислением возможных значений либо в абстрактном виде. Например, атрибут ДЕНЬ НЕДЕЛИ может принимать значения из ограниченного множества {«Пн», «Вт», «Ср», «Чт», «Пт», «Сб», «Вс»}, а атрибут ПОРЯДКОВЫЙ НОМЕР относится к домену целых положительных чисел. Различные атрибуты объекта могут принимать значения из одного и того же домена, например, ПОРЯДКОВЫЙ НОМЕР и АТОМНАЯ МАССА относятся к домену целых положительных чисел.

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

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

ОСНОВНЫЕ ПОНЯТИЯ

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

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

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

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

Тип сущности это набор однородных личностей, предметов, событий или идей, выступающих как целое. Например, типом сущности может быть ГОРОРД,АВТОМОБИЛЬ.

Экземпляр сущности – это конкретная вещь в наборе. Например, экземпляром сущности будут – Москва, Киев, «Жигули», «Москвич» и т.д.

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

Например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.

Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются Тип, Марка, Номерной Знак, Цвет и т.д.

Здесь также существует различие между типом и экземпляром. Тип атрибута Цвет имеет много экземпляров или значений: Красный, Синий, и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута.

Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Например, для автомобильного завода ЦВЕТ- это только атрибут продукта производства, а для лакокрасочной фабрики ЦВЕТ – тип сущности.

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

Связь – ассоциирование двух или более сущностей.

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

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

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

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

Например, книга может иметь несколько характеристик переиздания (дополненное, переработанное и т.д.), муж может иметь несколько жен и т.д.

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

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

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

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

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

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

В языке инфологического моделирования (ЯИМ), сущности и ассоциации представляются предложениями вида:

СУЩНОСТЬ (атрибут 1, атрибут 2, …, атрибут n);

АССОЦИАЦИЯ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, …]

(атрибут 1, атрибут 2, …, атрибут n);

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

ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, …)

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

[СПИСОК ОБОЗНАЧАЕМЫХ СУЩНОСТЕЙ].

Таблица 1. Элементы языков инфологической модели

		Классы сущностей
		Стержневая (стержень)	Ассоциативная (ассоциация)	Характеризующая (характеристика)	Обозначающая (обозначение)
ER - диаграмма
	(…, … )	[…, …, …, … ]		{..., …, … }	[…, …, … ]

Виды связей. Между двумя сущностями возможны следующие виды связей:

Первый тип – связь ОДИН – К – ОДНОМУ (1:1); в каждый момент времени каждому экземпляру сущности А соответствует 1 или 0 представителей сущностей В.

Второй тип – связь ОДИН – КО – МНОГИМ (1:М); одному представителю сущности А соответствуют 0,1 или несколько представителей сущности В.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ – К – ОДНОМУ (М:1) и МНОГИЕ – КО – МНОГИМ (М:N). Кроме того, существуют и более сложные связи (ПРИЛОЖЕНИЕ 1):

Множество связей между одним и теми же сущностями;

Тренарные связи;

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

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

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

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

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

Рис. 1. Структуры: а – ассоциации; в – обозначения; (характеристики)

1. Определить сущности.

2. Выявить связи между сущностями.

3. Изобразить инфологическую модель предметной области в виде ER – диаграммы и средствами ЯИМ.

Примечание: Варианты заданий выдаются преподавателям.

ВОПРОСЫ ДЛЯ САМОПРОВЕРКИ

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

назовите основные конструктивные элементы инфологических моделей.

Назовите классы и подклассы сущностей.

Охарактеризуйте стержневую; ассоциативную; характеристическую; обозначающую сущности.

назовите одно из основных требований к организации базы данных.

Какие языки можно использовать при построений инфологических моделей?

Для каких моделей используется язык ER – диаграмм?

Какими фигурами изображаются основные конструктивные элементы ER – диаграмм?

В каком виде представляются основные конструктивные элементы я ЯИМ? Приведите пример.

Какие типы связей возможны между сущностями?

В чем заключается отличие между первичными и внешними ключами?

Какова связь между первичными и внешними ключами сущностей?

Приложение 1

Таблица П1. Примеры описания связей инфологической модели различными языками

	ER -диаграмм
		Брак (номер свидетельства, Фамилия мужа, Имя мужа, Дата рождения мужа, Место регистрации и т.д.)
		Брак (номер свидетельства, Код М, Фамилия жены, Дата регистрации) (Жены)
		Брак (номер свидетельства, Код М, ФИО жены, Дата регистрации) (Мужья)
		Брак (номер свидетельства, Код М, код Ж, ФИО жены,) (Мужья, Жены) Мужья (код М, ФИО, Дата рождения, Место рождения) Жены (код Ж, ФИО, Дата рождения, Место рождения)

Приложение 2. пример построения инфологической модели БД «Питание»

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

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

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

2. Для каждого поставщика продуктов: наименование, адрес, название поставляемого продукта, дата поставки и цена на момент поставки.

3. Ежедневное потребление блюд (расход): блюдо, количество порций, дата

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

Стержни Блюда, Продукты, Города;

Ассоциации Состав (связывает блюда с Продуктами) и

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

Обозначение Поставщики;

Характеристики Рецепты и Расход.

ER – диаграмма показана на рисунке

М

продукты

N

М 1

Модель БД НА языке ЯИМ имеет следующий вид: Блюда (БЛ, Блюдо, Вид), Продукты (ПР, Продукт, Калорийность), Поставщики (ПОС, Город, Поставщик),Состав [Блюда М, Продукты N] (БЛ,ПР, Вес(г)) Поставки [Поставщики М, Продукты N] (ПОС, ПР, Дата П, Цена, Вес(кг))

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

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

Понимать свое тело на уровне клеток и испускаемых ими вибраций не так уж и сложно.

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

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

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

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

Еще одной интересной практикой в общении с другими людьми является такая:

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

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

Из диалога про излучение и генерирование:

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

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

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

2.3. Классификация сущностей

Три класса сущностей

Настал момент разобраться в терминологии. К.Дейт [3 ] определяет три основные класса сущностей: стержневые , ассоциативные и характеристические , а также подкласс ассоциативных сущностей – обозначения .

Стержневая сущность (стержень)

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

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

Ассоциативная сущность (ассоциация)

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

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

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

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

Характеристическая сущность (характеристика)

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

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

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

ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, ...)

{СПИСОК ХАРАКТЕРИЗУЕМЫХ СУЩНОСТЕЙ}.

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

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

Обозначающая сущность или обозначение

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

Пример

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

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

Служащие (Табельный номер, Фамилия, ...)

Зачисление [Отделы M, Служащие N]

(Номер отдела, Табельный номер, Дата зачисления).

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

Отделы (Номер отдела, Название отдела, ...)

Служащие (Табельный номер, Фамилия, ... , Номер отдела,

Дата зачисления)[Отделы]

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

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

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

ОБОЗНАЧЕНИЕ (атрибут 1, атрибут 2, ...)[СПИСОК

ОБОЗНАЧАЕМЫХ СУЩНОСТЕЙ].

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

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

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

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

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

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

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

Для каждого поставщика продуктов: наименование, адрес, название поставляемого продукта, дата поставки и цена на момент поставки.

Ежедневное потребление блюд (расход): блюдо, количество порций, дата.

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

стержни Блюда, Продукты и Города;

ассоциации Состав (связывает Блюда с Продуктами) и

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

обозначение Поставщики;

характеристики Рецепты и Расход.

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

Блюда (БЛ, Блюдо, Вид)

Продукты (ПР, Продукт, Калорийность)

Поставщики (ПОС, Город, Поставщик) [Город]

Состав [Блюда M, Продукты N] (БЛ, ПР, Вес (г))

Поставки [Поставщики M, Продукты N] (ПОС, ПР, Дата_П, Цена, Вес (кг))

Города (Город, Страна)

Рецепты (БЛ, Рецепт) {Блюда}

Расход (БЛ, Дата_Р, Порций) {Блюда}

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

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

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

2.4. О первичных и внешних ключах

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

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

Теперь о внешних ключах :

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

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

В п. 2.3 рассматривался пример, где "Служащие" обозначали "Отделы" и включали внешний ключ "Номер отдела", соответствующий первичному ключу сущности "Отделы".

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

Рис. 2.5. Структуры: а - ассоциации; б - обозначения (характеристики)

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

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

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

2. Что должно случиться при попытке УДАЛЕНИЯ целевой сущности, на которую ссылается внешний ключ? Например, при удалении поставщика, который осуществил по крайней мере одну поставку. Существует три возможности:

3. Что должно происходить при попытке ОБНОВЛЕНИЯ первичного ключа целевой сущности, на которую ссылается некоторый внешний ключ? Например, может быть предпринята попытка обновить номер такого поставщика, для которого имеется по крайней мере одна соответствующая поставка. Этот случай для определенности снова рассмотрим подробнее. Имеются те же три возможности, как и при удалении:

КАСКАДИРУЕТСЯ	Операция обновления "каскадируется" с тем, чтобы обновить также и внешний ключ впоставках этого поставщика.
ОГРАНИЧИВАЕТСЯ	Обновляются первичные ключи лишь тех поставщиков, которые еще не осуществляли поставок. Иначе операция обновления отвергается.
УСТАНАВЛИВАЕТСЯ	Для всех поставок такого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем обновляется первичный ключ поставщика. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.

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

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

NULL-значения не допустимы

УДАЛЕНИЕ ИЗ (цель) КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЕ (первичный ключ цели) КАСКАДИРУЕТСЯ

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

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

2.5. Ограничения целостности

Понятие целостности данных

Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1,2,3,4,5,6,7).

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

Виды целостности

Выделяют три группы правил целостности:

Целостность по сущностям.

Целостность, определяемая пользователем.

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

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

Значение внешнего ключа должно либо:

быть равным значению первичного ключа цели;

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

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

уникальность тех или иных атрибутов,

диапазон значений (экзаменационная оценка от 2 до 5),

принадлежность набору значений (пол "М" или "Ж").

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

2.6. О построении инфологической модели

Введение

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

Требования к БД со стороны администратора и прикладного программиста

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

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

четко разграничивать такие понятия как запрос на данные и ведение данных (ввод, изменение и удаление);

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

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