Тема 2. реляционные базы данных. ограничения целостности

ТЕМА 1. ВВЕДЕНИЕ В БАЗЫ ДАННЫХ. ОСНОВНЫЕ ПОНЯТИЯ И ОПРЕДЕЛЕНИЯ.

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

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

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

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

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

Понятие «данные» в концепции баз данных — это набор конкретных значений, параметров, характеризующих объект, условие, ситуацию или любые другие фак­торы, Примеры данных: Петров Николай Степанович, $30 и т. д. Данные не об­ладают определенной структурой, данные становятся информацией тогда, когда пользователь задает им определенную структуру, то есть осознает их смысловое содержание. Поэтому центральным понятием в области баз данных является понятие модели. Не существует однозначного определения этого термина, у раз­ных авторов эта абстракция определяется с некоторыми различиями но, тем не менее, можно выделить нечто общее в этих определениях.

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

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

· иерархическую

· сетевую

· реляционную

· объектно-ориентированную

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

В сетевойБД данные организуются в виде графа. Недостатком сетевой структуры является жесткость структуры и сложность ее организации.

РеляционнаяБД получила свое название от английского термина relation (отношение). Была предложена в 70-м году сотрудником фирмы IBM Эдгаром Коддом. Реляционная БД представляет собой совокупность таблиц, связанных отношениями. Достоинствами реляционной модели данных являются простота, гибкость структуры. Кроме того ее удобно реализовывать на компьютере. Большинство современных БД для персональных компьютеров являются реляционными.

Объектно-ориентированные БД объединяют сетевую и реляционную модели и используются для создания крупных БД с данными сложной структуры.

Базы данных можно разделить на базы данных первого поколения: иерархические, сетевые; второго поколения:реляционные; третьего поколения:объектно-ориентированные, обектно-реляционные.

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

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

Различают фактографические автоматизированные информационные системы (АИС), у которых базы данных составляются из форматированных (формализованных) записей, и документальные АИС, записями которых могут служить различные неформализованные документы (статьи, письма и т.п.). В фактографических АИС примером форматированных записей могут служить, скажем, записи об операциях по приему и выдаче денег в сберкассе; запись имеет четыре основных атрибута: дата, характер операции (принято, выдано), сумма, остаток вклада.

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

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

ТЕМА 1. ВВЕДЕНИЕ В БАЗЫ ДАННЫХ. ОСНОВНЫЕ ПОНЯТИЯ И ОПРЕДЕЛЕНИЯ.

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

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

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

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

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

Понятие «данные» в концепции баз данных — это набор конкретных значений, параметров, характеризующих объект, условие, ситуацию или любые другие фак­торы, Примеры данных: Петров Николай Степанович, $30 и т. д. Данные не об­ладают определенной структурой, данные становятся информацией тогда, когда пользователь задает им определенную структуру, то есть осознает их смысловое содержание. Поэтому центральным понятием в области баз данных является понятие модели. Не существует однозначного определения этого термина, у раз­ных авторов эта абстракция определяется с некоторыми различиями но, тем не менее, можно выделить нечто общее в этих определениях.

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

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

· иерархическую

· сетевую

· реляционную

· объектно-ориентированную

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

В сетевойБД данные организуются в виде графа. Недостатком сетевой структуры является жесткость структуры и сложность ее организации.

РеляционнаяБД получила свое название от английского термина relation (отношение). Была предложена в 70-м году сотрудником фирмы IBM Эдгаром Коддом. Реляционная БД представляет собой совокупность таблиц, связанных отношениями. Достоинствами реляционной модели данных являются простота, гибкость структуры. Кроме того ее удобно реализовывать на компьютере. Большинство современных БД для персональных компьютеров являются реляционными.

Объектно-ориентированные БД объединяют сетевую и реляционную модели и используются для создания крупных БД с данными сложной структуры.

Базы данных можно разделить на базы данных первого поколения: иерархические, сетевые; второго поколения:реляционные; третьего поколения:объектно-ориентированные, обектно-реляционные.

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

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

Различают фактографические автоматизированные информационные системы (АИС), у которых базы данных составляются из форматированных (формализованных) записей, и документальные АИС, записями которых могут служить различные неформализованные документы (статьи, письма и т.п.). В фактографических АИС примером форматированных записей могут служить, скажем, записи об операциях по приему и выдаче денег в сберкассе; запись имеет четыре основных атрибута: дата, характер операции (принято, выдано), сумма, остаток вклада.

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

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

ТЕМА 2. РЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ. ОГРАНИЧЕНИЯ ЦЕЛОСТНОСТИ

Американский математик Э.Ф.Кодд (E.F.Codd) в 1970 впервые сформулировал основные понятия и ограничения реляционной модели. Цели создания реляционной модели формулировались следующим образом:

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

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

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

Коммерческие системы на основе реляционной модели данных начали появляться в конце 70-х – начале 80-х годов. Благодаря популярности реляционной модели многие нереляционные системы те­перь обеспечиваются реляционным пользовательским интерфейсом, независимо от используемой базовой модели.

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

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

Отношение– это плоская таблица, состоящая из столбцов и строк.

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

Атрибут - это поименованный столбец отношения.

В реляционной модели отношения используются для хранения информации об объектах, представленных в базе данных. Отношение обычно имеет вид двумерной табли­цы, в которой строки соответствуют отдельным записям, а столбцы - атрибутам. При этом атрибуты могут располагаться в любом порядке, независимо от их переупорядочивания, отношение будет оставаться одним и тем же, а потому иметь тот же смысл. Например, информация об отделениях компании может быть представлена отно­шением Branch, включающим столбцы с атрибутами Вno (Номер отделения), Street (Улица), City (Город), Postcode (Почтовый индекс), Tel_ No (Номер телефона) и Fax_ No (Номер факса). Аналогично, информация о работниках компании может быть представлена отношением Staff (Персонал), включающим столбцы с атрибутами Sno (Личный номер сотрудника), FName (Имя), LName (Фамилия), Address (Адрес), Tel_No (Номер телефона), Position (Должность), Sex (Пол), DOB (Дата рождения), Salary (Зарплата), INN (Личный номер социального страхования) и Вno (Номер отделения, в котором данный сотрудник работает). В табл. 1 и 2 показаны примеры отношений Branch и Staff. Каждый столбец содержит значения од­ного и того же атрибута, например столбец Вnо содержит только номера сущест­вующих отделений компании.

Элементами отношения являются кортежи, или строки, таблицы. Кортеж – это строка отношения. В отношении Branch каждая строка содержит 6 значений, по одному для каждого атрибута. Кортежи могут располагаться в любом порядке, при этом отношение будет оставать­ся тем же самым, а значит, и иметь тот же смысл.

Примеры отношений Branch и Staff.

Отношение Branch

Таблица 1

Bno	City	Postcode	Street	Tel_No	Fax_No
	Москва		Победы
	Ростов		Октябрьская
	Самара		Лесная

Отношение Staff

Таблица 2

Sno	FName	LName	Adress	Tel_No	Position	Sex	DOB	Salary	INN	Bno
	Иван	Иванов	Москва Победы 14-24		Менеджер	м	01.01.67	500$
	Марина	Смирнова	Москва Ленина 215-35		Менеджер	ж	01.01.75	500$

Степень отношения определяется количеством атрибутов, кото­рое оно содержит.

Отношение Branch (см. табл. 1) имеет шесть атрибутов и, следовательно, его степень равна шести. Это значит, что каждая строка таблицы является 6-арным кортежем, т.е. кортежем, содержащим шесть значений. Отношение только с одним атрибутом имеет степень 1 и называетсяунарным (unary) отношением (или 1-арным кортежем). Отношение с двумя атрибутами называетсябинарным (binary), отноше­ние с тремя атрибутами –тернарным (ternary), а для отношений с большим количеством атрибутов используется терминn-арный (n-ary). Определение степени отношения является частью заголовка отношения.

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

Альтернативная терминология.Терминология, используемая в реляционной модели, порой может привести к пу­танице, поскольку помимо предложенных терминов существует еще один. Отношение в нем называется таблицей , кортежи – записями (records), а атрибуты – полями (fields). Эта терминология основана на том факте, что физически СУБД может хранить каждое отношение в отдельном файле. В табл. 3 показаны соответствия, существующие между упомянутыми выше группами терминов.

Таблица 3

Альтернативные варианты терминов в реляционной модели

Вариант1	Вариант2
Отношение	Таблица
Кортеж	Запись
Атрибут	Поле

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

Фундаментальные свойства отношений (таблиц)

Отношение обладает следующими характеристиками:

· оно имеет имя, которое отличается от имен всех других отношений;

· каждая ячейка отношения содержит только атомарное (неделимое) значение;

· каждый атрибут имеет уникальное имя;

· значения атрибута берутся из одного и того же домена;

· порядок следования атрибутов не имеет никакого значения;

· каждый кортеж является уникальным, т.е. дубликатов кортежей быть не может;

· теоретически порядок следования кортежей в отношении не имеет никако­го значения. (Однако практически этот порядок может существенно по­влиять на эффективность доступа к ним.)

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

Имена столбцов, указанные в их верхней строке, соответствуют именам атрибутов отношения. Значения атрибута Bno берутся из домена BRANCH_NUMBERS - не допускается размещение в этом столбце иных значений, например почтового индекса. Столбцы можно менять местами при условии, что имя атрибута перемещается вместе с его значениями. Таблица все еще будет представлять то же отношение, если атрибут Tel_No расположить в ней перед атрибутом Postcode, хотя для лучшей читабельности ра­зумнее было бы располагать отдельные части адреса поблизости.

Отношение не может содержать кортежей-дубликатов. Например, строка ( 23, Москва, 111111, Победы, 1231112, 1231113) может быть представлена в отношении только один раз. При необходимости строки можно менять местами произвольным образом (например, переместить строку отделения ‘23’ на место строки отделения ‘24’), само отношение при этом останется прежним.

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

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

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

Рассмотрим терми­нологию, используемую при работе с реляционными базами данных.

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

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

Требования, предъявляемые к первичному ключу:

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

· первичный ключ не должен содержать пустых значений.

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

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

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

Связи между таблицами. Записи в таблице могут зависеть от одной или несколь­ких записей другой таблицы. Такие отношения между таблицами называются связями. Связь определяется следующим образом: поле или несколько полей одной таблицы, называемое внешним ключом, ссылается на первичный ключ другой таблицы. Рассмотрим пример. Так как каждый заказ должен исходить от определенного клиента, каждая запись таблицы Orders (заказы) должна ссылаться на соответствующую запись таблицы Customers (клиенты). Это и есть связь между таблицами Orders и Customers. В таблице Orders должно быть поле, где хранятся ссылки на те или иные записи таблицы Customers.

Существует три типа связей между таблицами.

Один к одному — каждая запись родительской таблицы связана только с одной запи­сью дочерней. Такая связь встречается на практике намного реже, чем отношение один ко многим и реализуется путем определения уникального внешнего ключа. Связь один к одному используют, если не хотят, чтобы таблица «распухала» от большого числа полей. Базы данных, в состав которых входят таблицы с такой связью не могут считаться полностью нормализованными.

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

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

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

Таблица «Товары»

Таблица 4

Товар	Ед изм	Цена
Сахар	кг
Макароны	кг
Куры	кг
Фанта	бут

Таблица «Отпуск товаров»

Таблица 5

Товар	Дата	Количество
Сахар	10.12.07.
Сахар	12.12.07.
Сахар	14.12.07
Макароны	10.12.07
Макароны	12.12.07
Фанта	07.12.07
Фанта	05.12.07

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

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

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

Рассмотрим первый случай. Если изменить значения поля «Товар» с «Сахар» на «Рафинад» в таблице «Товары», а в таблице «Отпуск товаров» значение поля связи «Сахар» оставить прежним. В результате получим:

• в дочерней таблице «Отпуск товаров» для товара «Рафинад» (таблица «Товары») нет сведений о его отпуске со склада;

• некоторые записи таблицы «Отпуск товаров» содержат сведения об отпуске то­вара «Сахар», о котором нет информации в таблице «Товары».

Рассмотрим второй случай. Пусть в одной из записей таблицы «Отпуск товаров» значение поля связи «Сахар» изменилось на «Рафинад». В результате:

• в дочерней таблице «Отпуск товаров» недостоверны сведения об отпуске со склада товара «Сахар» (таблица «Товары»);

• одна из записей таблицы «Отпуск товаров» содержит данные об отпуске товара «Рафинад», сведения о котором отсутствуют в таблице «Товары».

И в первом, и втором случае мы наблюдаем нарушение целостности базы данных; это означает, что хранящаяся в ней информация становится недостоверной.

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

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

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

• при удалении записи в родительской таблице следует удалить соответствующие записи в дочерней таблице.

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

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

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