Логическая и физическая независимость данных

Основные понятия баз данных. Этапы развития СУБД. Функции СУБД. Требования к системам управления базами данных.

Основные понятия баз данных

Информация, хранящаяся в базах данных, является отражением объектов реального мира. В традиционной терминологии объекты реального мира, сведения о которых хранятся в базе данных, называются сущностями — entities, а их актуальные признаки — атрибутами (attributes).

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

Важнейшая задача компьютерных систем — хранение и обработка данных. Для ее решения были предприняты усилия, которые привели к появлению в конце 60-х годов специализированного программного обеспечения — систем управления базами данных (СУБД, database management systems).

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

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

Сервер БД является неотъемлемым компонентом модели взаимодействия «клиент-сервер», которая стала фактическим стандартом архитектуры современных СУБД и одним из этапов их развития от систем с централизованной архитектурой и систем с файловым сервером.

 

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

 

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

Описание данных называется системным каталогом (system catalog), или словарем данных (data dictionary), а сами элементы описания принято называть метаданными (metadata), т.е. «данными о данных».

Именно наличие самоописания данных в базе данных обеспечивает независимость между программами и данными.

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

 

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

 

Функции СУБД.

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

· Позволяет определять базу данных, что осуществляется с помощью языка определения данных (DDL – Data Definition Language). Язык DDL предоставляет пользователям средства указания типа данных и их структуры, а также средства задания ограничений для информации, хранимой в базе данных.

· Позволяет вставлять, обновлять и извлекать информацию из базы данных, что осуществляется с помощью языка управления данными (DML - Data Manipulation Language). Наличие централизованного хранилища всех данных и их описаний позволяет использовать язык DML как общий инструмент организации запросов, который иногда называют языком запросов.

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

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

· системы поддержки целостности данных, обеспечивающей непротиворечивое состояние хранимых данных;

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

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

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

 

Этапы развития СУБД

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

1) Начальный этап был связан с созданием первого поколения СУБД, опиравшихся на иерархическую и сетевую модели данных (на основе спецификаций CODASYL). По времени он совпал с периодом, когда на рынке вычислительной техники доминировали большие ЭВМ (mainframe), которые в совокупности с СУБД первого поколения составили аппаратно-программную платформу больших информационных систем.

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

2) С созданием реляционной модели данных был начат новый этап в эволюции СУБД. Простота и гибкость модели привлекли к ней внимание разработчиков и снискали ей множество сторонников. Реляционная модель данных стала доминирующей. Условно эту группу систем можно назвать "вторым поколением СУБД". Его характеризовали две основные особенности — реляционная модель данных и язык запросов SQL (Structured Query Language).

3) Представители второго поколения в настоящее время сохраняют определенную популярность среди производителей СУБД и развились в системы третьего поколения, к которому и относятся современные СУБД.

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

 

Требования к системам управления базами данных

· СУБД должна удовлетворять актуальным информационным потребностям организации. Получаемая информация должна по структуре и содержанию соответствовать решаемым задачам.

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

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

 

2. Архитектура баз данных. Логическая и физическая независимость данных. Схема прохождения запросов к БД. Классификация моделей данных. Архитектура и модели "клиент-сервер" в технологии БД.

Архитектура баз данных

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American Standards Institute) трехуровневая система организации БД:

Рис. 1. Архитектура баз данных

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

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

· все сущности, их атрибуты и связи;

· накладываемые на данные ограничения;

· семантическая информация о данных;

· информация о мерах обеспечения безопасности и поддержки целостности данных.

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

Разделение функций

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

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

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

1) Представление (Presentation Logic).

2) Обработка (Business Logic).

3) Хранение (Data manipulation Logic) и данные (Data).

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

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

· формирование экранных изображений;

· чтение и запись в экранные формы информации;

· управление экраном, движением мыши, клавиатуры.

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

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

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

Модель файлового сервера

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

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

К недостаткам модели можно отнести:

· высокий сетевой трафик (пересылаются файлы целиком, даже полезной в нем является всего одна строка);

· узкий спектр операций манипулирования с данными, который определяется файловыми командами;

· отсутствие средств безопасности доступа к данным (только на уровне файловой системы).

 

Рис. 5. Модель файлового сервера

Модель сервера баз данных

Модель сервера баз данных (Database Server, DBS) (рис. 7) поддерживается большинством современных СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server. Основу данной модели составляет механизм хранимых процедур как средство программирования SQL-сервера, механизм триггеров как механизм отслеживания текущего состояния информационного хранилища и механизм ограничений на пользовательские типы данных, который иногда называется механизмом поддержки доменной структуры.

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

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

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

 

Рис. 7. Модель сервера баз данных

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

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

Модель сервера приложений

Модель сервера приложений (Application Server, AS) является расширением двухуровневой модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Архитектура трехуровневой модели приведена на рис. 8. Этот промежуточный уровень содержит один или несколько серверов приложений.

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

Нужно отметить, что эта модель обладает большей гибкостью, чем двухуровневые модели. Наиболее заметны преимущества модели сервера приложений в тех случаях, когда клиенты выполняются сложные аналитические расчеты над базой данных, которые относятся в области OLAP-приложений (On-line analytical processing). В этой модели большая часть бизнес-логики клиента изолирована от возможностей расширенного SQL, реализованного в конкретной СУБД, и может быть выполнена на стандартных языках программирования, таких как C, C++, Object Pascal, Java. Это повышает переносимость системы, ее масштабируемость.

Рис.8. Модель сервера приложений

Реляционная модель БД, ее основные достоинства. Таблица, кортеж, атрибут, домен, первичный ключ, внешний ключ. Фундаментальные свойства отношений. Обеспечение целостности данных.

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

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

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

Рис. 14. Основные понятия реляционной модели

 

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

К основным достоинствам реляционной модели относят:

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

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

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

Таблица, кортеж, атрибут, домен, первичный ключ, внешний ключ.

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

Домен – это, также как и тип данных, характеристика, задающая перечень всевозможных значений атрибута, но, как правило, этот перечень более «узкий». Например, если атрибут ВОЗРАСТ имеет тип данных ЦЕЛОЕ ЧИСЛО, который задает диапазон от –32768 до 32767, то при попытке записать в этот атрибут отрицательное число, СУБД успешно выполнит данную команду. При помощи домена можно наложить ограничение, например, (ВОЗРАСТ > 0 И ВОЗРАСТ < 100), которое не позволит для атрибута ВОЗРАСТ использовать значения, выходящие за указанный диапазон.

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

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

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

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

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

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

 

Таблица 1. Соответствие формальных реляционных терминов и их неформальных эквивалентов

Формальный реляционный термин	Неформальный эквивалент
Отношение Кортеж Кардинальное число Атрибут Степень Первичный ключ Домен	Таблица Строка Количество строк Столбец Количество столбцов Уникальный идентификатор Совокупность допустимых значений

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

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

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

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

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

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

· целостность по ссылкам (ссылочная целостность – referential integrity);

· целостность, определяемая пользователем (семантическая целостность);

· физическая целостность (целостность файлов операционной системы).

 

Декларативная целостность – целостность по сущностям. Ограничения целостности, необходимые для обеспечения декларативной целостности обычно задаются при объявлении (декларировании, от слова declaration – «объявление») сущности в базе данных.

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

· тип данных;

· размер типа данных;

· опция NOT NULL;

· домен;

· первичный ключ;

· уникальный ключ.

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

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

Опция NOT NULL – назначается атрибуту в том случае, если нужно, чтобы тот не мог содержать неопределенное значение.

Домен – это, также как и тип данных, характеристика, задающая перечень всевозможных значений атрибута, но, как правило, этот перечень более «узкий». Например, если атрибут ВОЗРАСТ имеет тип данных ЦЕЛОЕ ЧИСЛО, который задает диапазон от –32768 до 32767, то при попытке записать в этот атрибут отрицательное число, СУБД успешно выполнит данную команду. При помощи домена можно наложить ограничение, например, (ВОЗРАСТ > 0 И ВОЗРАСТ < 100), которое не позволит для атрибута ВОЗРАСТ использовать значения, выходящие за указанный диапазон.

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

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

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

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

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

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

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

· Каскадирование: операция удаления «каскадируется» с тем, чтобы удалить также поставки этого поставщика.

· Ограничение: удаляются лишь те поставщики, которые еще не осуществляли поставок. Иначе операция удаления отвергается.

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

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

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

· Ограничение: обновляются первичные ключи лишь тех поставщиков, которые еще не осуществляли поставок. Иначе операция обновления отвергается.

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

 

4. Основы реляционной алгебры. Операторы реляционной алгебры. Понятия полной и транзитивной функциональной зависимости. Нормализация, третья нормальная форма, шаги нормализации.

 

Основные понятия

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

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

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

Наконец, третья возможность – это непосредственная работа с базой данных в семантической модели, т.е. СУБД, основанные на семантических моделях данных.

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

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

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

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