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

Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром - Москва, Киев и т. д. ER-модели строятся на уровне типов сущностей, а не отдельных экземпляров сущностей.

Наименование атрибута должно быть уникальным для конкретного типа сущности. Оно называется идентификатором. Идентификатор может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СТОЛ, АВТОМОБИЛЬ, НЕБО и т. д.). Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: Красный, Синий, Белый и т. д., однако каждому экземпляру сущности присваивается только одно значение атрибута.

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

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

Атрибут (attribute)- поименованная характеристика сущности, которая принимает значения из некоторого множества значений.

Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Основное назначение атрибута – описание свойств сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т. д.; для сущности СОТРУДНИК – ТАБЕЛЬНЫЙ НОМЕР, ФИО, ГОД РОЖДЕНИЯ, СПЕЦИАЛЬНОСТЬ и т. д.

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

IV. Атрибутам присущи свойства. Природа свойств может быть различной.

1.2. Основные виды свойств

1.  Свойство может быть множественным или единичным – т. е. атрибут, задающий свойство, может одновременно иметь несколько значений или только одно. Например, СОТРУДНИК может иметь несколько СПЕЦИАЛЬНОСТЕЙ, знать несколько ИНОСТРАННЫХ ЯЗЫКОВ, но единственное значение свойств – ТАБЕЛЬНЫЙ НОМЕР, ДАТА РОЖДЕНИЯ, СТАЖ РАБОТЫ.

2.  Свойство может быть простым, состоящим из одного компонента с независимым существованием, или составным, если его значение составляется из значений простых свойств. Например, свойство ГОД РОЖДЕНИЯ является простым, а свойство АДРЕС – составным, т. к. включает значения простых свойств ГОРОД, УЛИЦА, ДОМ, КВАРТИРА. Простые свойства называют атомарными.

3.  Свойство может быть базовым или производным, зависящим от значения связанного с ним свойства или некоторого множества свойств, принадлежащих некоторой (не обязательно данной) сущности. Например, свойство ПОСТАВЩИК может иметь свойство ОБЩЕЕ КОЛИЧЕСТВО ПОСТАВЛЯЕМЫХ ДЕТАЛЕЙ, которое вычисляется суммированием количества деталей, поставляемых им. Тогда ПОСТАВЩИК – базовое свойство, свойство ОБЩЕЕ КОЛИЧЕСТВО ПОСТАВЛЯЕМЫХ ДЕТАЛЕЙ – производное свойство.

Или, свойство ВОЗРАСТ СОТРУДНИКА является величиной, производной от его свойства ДАТА_РОЖДЕНИЯ, поэтому атрибуты ВОЗРАСТ и ДАТА_РОЖДЕНИЯ являются связанными. Причем атрибут ВОЗРАСТ является производным атрибутом, значение которого вычисляется на основании значения атрибута ДАТА_РОЖДЕНИЯ.

Производными могут быть не только количественные, но и качественные свойства. Например, для сущности СТУДЕНТ имеется свойство ОТЛИЧНИК. Значение этого свойства определяется по следующему правилу: ОТЛИЧНИКОМ считается СТУДЕНТ, защитивший все курсовые работы на «отлично», сдавший все экзамены на «отлично», а также выполнивший в заданный срок все остальные, предусмотренные учебным планом контрольные мероприятия.

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

5.  Значения свойств могут быть постоянными – статическими или динамическими, т. е. меняться со временем. Например, свойства ТАБЕЛЬНЫЙ НОМЕР, ДАТА РОЖДЕНИЯ являются статическими, а АДРЕС, СТАЖ РАБОТЫ – динамическими.

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

7.  Свойство может быть ключевым, если его значение уникально и однозначно идентифицирует сущность. Например, ПОДЧИНЕННЫЙ некоторого определенного СОТРУДНИКА.

1.3. Классификация связей

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

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

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

Степень связи (или кардинальность) определяется количеством участников связи:

-  Связь со степенью 2 называется бинарной.

-  Связь со степенью 3 называется тернарной.

-  Связь со степенью 4 называется кватернарной.

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

Связь, как и сущность, имеет атрибуты или свойства.

1.4. Свойства связей

1.  Если каждый экземпляр сущности участвует, по крайней мере, в одном экземпляре связи, то такое участие этой сущности называется полным (или обязательным), в противном случае – неполным (или необязательным, частичным). Например, связь между сущностями СОТРУДНИК и ИНОСТРАННЫЙ ЯЗЫК. Некоторые СОТРУДНИКИ знают ИНОСТРАННЫЙ ЯЗЫК, но ни один из них не владеет более, чем одним ИНОСТРАННЫМ ЯЗЫКОМ. Есть некоторые СОТРУДНИКИ, которые не владеют ни одним ИНОСТРАННЫМ ЯЗЫКОМ. Естественно, что имеется много ИНОСТРАННЫХ ЯЗЫКОВ, которыми не владеет ни один из СОТРУДНИКОВ, а также, что некоторые из СОТРУДНИКОВ владеют одним и тем же ИНОСТРАННЫМ ЯЗЫКОМ. В данном случае участие обеих сущностей в связи является неполным.

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

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

«одинкодному» (1:1) (one-to-one relationship);

«одинкомногим» (1:N) (one-to-many relationship);

«многиекодному» (N:1) (many-to-one relationship);

«многиекомногим» (N:N) (many – to – many relationship).

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

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

На рис. 7.1 любой записи в таблице Автомобили в зависимости от значения поля тип соответствует запись либо в таблице Иномарки, либо в таблице Отечественные.

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

Или, например, если есть 2 сущности "Студент" и "Преподаватель" и связь между ними – руководство дипломными проектами, то каждый студент имеет только одного руководителя, но один и тот же преподаватель может руководить несколькими студентами-дипломниками (рис. 7.2).

рис. 7.1. Схема связи «один-к-одному».

 
 

рис. 7.2. Схема связи «один-ко-многим».

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

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

Другим примером связи "многие – ко - многим" является следующий: имеются две таблицы: СТУДЕНТ и ПРЕПОДАВАТЕЛЬ и между ними установлена связь - лекции (рис. 7.3).Один студент слушает лекции разных преподавателей, а преподаватель читает лекции многим студентам.

рис. 7.3. Схема связи «многие-ко-многим».

Для реализации такой связи введем дополнительную сущность ЛЕКЦИИ
(рис. 7.4).

рис. 7.4. Реализация связи «многие-ко-многим» в реляционной модели данных.

Инструмент связей – это средство представления сложных объектов, каждый из которых может рассматриваться как множество взаимосвязанных простых объектов. Деление на простые и сложные объекты, также как и характер взаимосвязи, является условным и определяется особенностями анализа предметной области, т. е. характером использования данных о предметах в решаемых прикладных задачах. При этом с точки зрения, например, конструктора, ДЕТАЛЬ является сложным объектом, а с точки зрения ПОСТАВЩИКА – простым.

2.  ER-диаграмма

ER-модели очень широко используются в практике создания БД. Причем они применяются как при ручном, так и при автоматизированном проектировании. В ER-модели должно быть отображено все, о чем идет речь в данной предметной области.

Для представления ER-модели используются графические языки. Каждый тип сущности в ER-диаграммах представляется в виде прямоугольника, содержащего имя сущности. Свойства служат для уточнения, идентификации, характеристики или выражения состояния сущности или связи. Свойства заносятся в прямоугольник, изображающий сущность, под именем сущности и изображаются малыми буквами. Имена ключевых свойств подчеркиваются. Связь представляется в виде линии, связывающей две сущности. В любой связи выделяются два конца, на каждом из которых указывается имя конца связи, степень конца связи (сколько экземпляров данной сущности связывается), обязательность связи (т. е. любой ли экземпляр данной сущности должен участвовать в данной связи). Тип связи указывается индексами «1» или «N» над соответствующей линией. Например, связь между сущностями РУКОВОДИТЕЛЬ и ПРОЕКТ имеет тип «один – ко – многим»: один руководитель может руководить многими проектами; связь между сущностями СОТРУДНИК и ПРОЕКТ имеет тип «многие – ко – многим»: один сотрудник может участвовать во многих проектах, в проекте могут участвовать многие сотрудники.

Одну и ту же ситуацию в предметной области можно представить в ER-модели разными способами.

Особенности отображения ER-модели

Выделяют следующие типы ER-моделей:

-  рекурсивное (по «кольцу») множество связей, в котором участвуют несколько сущностей;

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

-  множество n-арных связей, например, тернарных (четыре связи, «исходящие от одной сущности»).

Вопросы для самоконтроля

1.  Расскажите о модели «сущность-связь».

2.  Какие основные конструктивные элементы используются при построении модели «сущность-связь»?

3.  Дайте определение сущности. Приведите примеры сущностей для разных предметных областей.

4.  Какие разновидности сущностей Вы знаете?

5.  Дайте определения типа сущности и экземпляра сущности. Приведите примеры.

6.  Дайте определение атрибута. Приведите примеры.

7.  Перечислите основные виды атрибутов. Приведите примеры.

8.  Дайте определение связи.

9.  Что такое кардинальность связи? Приведите примеры.

10.  Перечислите основные свойства связей.

11.  Какие типы связей Вам известны. Расскажите о каждом из них, приведите примеры.

12.  Для чего используются ER-диаграммы? Каковы особенности отображения ER-диаграмм?


Тема 8. Этапы проектирования баз данных.

1.  Системный анализ. Определить информационные потребности БД.

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

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

4.  Определить атрибуты, которые уникальным образом идентифицируют каждый объект.

5.  Выработать правила, которые будут устанавливать и поддерживать целостность данных.

6.  Установить связи между объектами (таблицами, полями).

7.  Провести нормализацию таблиц.

8.  Спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации.

Рассмотрим детально перечисленные этапы проектирования БД.

1.  Системный анализ

Ключевым этапом при разработке любой информационной системы является проведение системного анализа:

1.  формализация предметной области;

2.  представление системы как совокупности компонент.

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

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

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

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

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

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

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

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

2.  БД должна обеспечивать получение требуемых данных за приемлемое время, т. е. обеспечивать заданную производительность.

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

4.  БД должна быть рассчитана на возможность расширения при реорганизации и расширении предметной области.

5.  БД должна легко изменяться при изменении программной и аппаратной среды.

6.  Загруженные в БД корректные данные должны оставаться корректными.

7.  Данные до включения в БД должны проверяться на достоверность.

8.  Доступ к данным, размещаемым в БД, должны иметь только лица с соответствующими полномочиями.

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

2.  Формирование из объектов предметной области сущностей
и их характеристик

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

Моделирование концептуального уровня БД включает в себя:

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

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

-  идентификацию характеристик этих сущностей. Например, сущность РАБОТНИК может включать такие характеристики как Идентификатор Работника, Фамилия, Имя, Отчество, Профессия, Зарплата.

-  идентификацию взаимосвязей между сущностями. Например, каким образом сущности РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ взаимодействуют друг с другом? Работник имеет одну профессию (для простоты!) и значится в одном отделе, в то время как в одном отделе может находиться много работников.

3.  Установка соответствия между сущностями и таблицами,
характеристиками сущностей и столбцами таблиц

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

Получение реляционной схемы из ER-диаграммы:

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

2.  Каждый атрибут становится столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут. Если атрибут является множественным, то для него строится отдельное отношение.

4.  Определение первичных ключей

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

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

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

-  суммарной длины атрибутов;

-  минимального количества атрибутов в ключе;

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

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

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

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

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

В БД можно указать, какое поле считать индексированным, и создать индексный файл (INDEX FILE), в котором будет храниться содержание указанного поля и порядковый номер каждой записи.

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

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

5.  Определение правил целостности данных

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

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

Правила целостности данных включают:

-  определение типа данных;

-  создание полей, опирающихся на экземпляры сущности;

-  установка значений по умолчанию;

-  определение ограничений целостности;

-  определение проверочных условий.

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

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

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

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

I.  В процессе проектирования:

1.  при получении достоверных данных из источников;

2.  при построении структуры;

3.  при заполнении БД данными.

II.  При эксплуатации:

1.  машинные сбои;

2.  ошибки оператора.

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

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

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

2.  Целостность по ссылкам.

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

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

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

3.  Корпоративная целостность или целостность, определяемая пользователем.

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

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

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

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

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

6.  Установка связей между объектами

На шестом шаге устанавливаются связи между объектами (таблицами и столбцами).

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

Использование связей позволяет:

1.  уменьшить объем хранимых данных;

2.  обеспечить полноту и корректность данных на уровне их структуры за счет соблюдения следующего правила: данные об одном объекте вводятся в БД только один раз.

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

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

8.  Планирование вопросов надежности данных
и сохранения секретности информации

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

Вопросы для самоконтроля

1.  Перечислите основные этапы проектирования баз данных. Для какой модели данных используются эти этапы?

2.  Установите соответствие между уровнями и этапами проектирования баз данных.

3.  Расскажите об этапе системного анализа.

4.  Чем отличаются функциональный и объектный подходы к описанию предметной области? Какой подход используется чаще на практике?

5.  Как формируются из объектов предметной области сущности? Как определяются их характеристики?

6.  Каков алгоритм перехода от инфологической к даталогической модели?

7.  Дайте определение первичного ключа. Какие виды ключей используются в реляционной модели данных?

8.  Что такое индекс и для чего он нужен?

9.  Дайте определение целостности данных.

10.  Назовите группы и типы правил целостности данных?

11.  Приведите примеры использования корпоративной целостности данных.

12.  Какие типы связей Вам известны?

13.  Для чего используются связи в реляционной модели данных?


Тема 9. Нормализация.

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

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10