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

Содержание

Слайд 2

1. Достоинства и недостатки реляционной модели данных Существует много моделей представ-ления

1. Достоинства и недостатки реляционной модели данных

Существует много моделей представ-ления

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

Мы приступаем к изучению ре-ляционных БД и систем управ-ления ими. Этот

Мы приступаем к изучению ре-ляционных БД и систем управ-ления ими. Этот

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

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

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

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

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

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

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

Отмеченные выше преимущества и постепенное накопление методов и алгоритмов организации реляцион-ных

Отмеченные выше преимущества и постепенное накопление методов и алгоритмов организации реляцион-ных

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

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

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

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

На данной лекции мы введем на сравнительно неформальном уровне основные понятия

На данной лекции мы введем на сравнительно неформальном уровне основные понятия

реля-ционных БД, а также определим существо реляционной модели данных (РМД). Основной целью лекции является демонстрация простоты и возможности интуи-тивной интерпретации этих поня-тий.
Слайд 9

2. Базовые понятия реляционных баз данных Реляционная модель предложена сотрудником фирмы

2. Базовые понятия реляционных баз данных

Реляционная модель предложена сотрудником фирмы

IBM Эдгаром Коддом и основывается на понятии отношения (relation). Компоненты РМД и формы их представления можно изобразить в виде нижеследующей таблицы.
Слайд 10

Таблица 1. – Компоненты РМД Основными понятиями реляционных баз данных, как

Таблица 1. – Компоненты РМД

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

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

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

Для начала покажем смысл этих понятий на примере отношения «Sotrudniki», содержащего

информацию о сотрудниках некоторой организации.
Слайд 12

2. 1. Тип данных Понятие тип данных в реляционной модели данных

2. 1. Тип данных

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

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

2. 2. Атрибуты Атрибуты представляют собой свойства, характеризующие сущность (сущность -

2. 2. Атрибуты

Атрибуты представляют собой свойства, характеризующие сущность (сущность -

объект любой природы, данные о котором хранятся в БД). В структуре таблицы каждый атрибут именуется и ему соответствует заго-ловок некоторого столбца таблицы. В нашем примере Sotrudniki именами атрибутов являются Tab_nomer, Fio, Zarplata, Nomer_otdela.
В реляционных БД перестановка атрибутов не приводит к образованию нового отношения, хотя формально, ес-ли переставить атрибуты в отношении, то получается новая таблица.
Слайд 14

2. 3. Домен Понятие домена более специ-фично для баз данных, хотя

2. 3. Домен

Понятие домена более специ-фично для баз данных,

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

Если вычисление этого логичес-кого выражения дает результат «истина», то элемент данных

Если вычисление этого логичес-кого выражения дает результат «истина», то элемент данных

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

Например, домен «Fio» в нашем примере определен на базовом типе строк

Например, домен «Fio» в нашем примере определен на базовом типе строк

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

В нашем примере значения доменов «Nomer_propuska» и «Nomer_ot-dela» относятся к типу

В нашем примере значения доменов «Nomer_propuska» и «Nomer_ot-dela» относятся к

типу целых чисел, но не являются срав-нимыми. Заметим, что в большинстве реляционных СУБД понятие домена не используется, хотя, например, в СУБД Oracle v.7 оно уже поддер-живается.
Слайд 18

2. 4. Схема отношения, схема базы данных Схема отношения - это

2. 4. Схема отношения, схема базы данных


Схема отношения -

это име-нованное множество пар {имя ат-рибута, имя домена (или типа, если понятие домена не поддержи-вается)}. Степень или «арность» схемы отношения – мощность этого множества. Степень отношения Sotrudniki равна четырем, то есть оно является 4-арным.
Слайд 19

Если все атрибуты одного отно-шения определены на разных доме-нах, осмысленно использовать

Если все атрибуты одного отно-шения определены на разных доме-нах, осмысленно

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

Если в данной СУБД понятие домена не используется, то схема отношения

Если в данной СУБД понятие домена не используется, то схема отношения

– это список имен атрибутов. В нашем примере это строка
Nomer_propuska Fio Zarplata Nomer_otdela
Схема БД (в структурном смысле) - это набор именованных схем отно-шений.
Слайд 21

2. 5. Кортеж Кортеж, соответствующий дан-ной схеме отношения, - это мно-жество

2. 5. Кортеж

Кортеж, соответствующий дан-ной схеме отношения, - это

мно-жество пар {имя атрибута, зна-чение}, которое содержит одно вхождение каждого имени атрибу-та, принадлежащего схеме отноше-ния. «Значение» является допусти-мым значением домена данного атрибута (или типа данных, если понятие домена не поддержи-вается).
Слайд 22

Тем самым, степень или «арность» кортежа, т.е. число элементов в нем,

Тем самым, степень или «арность» кортежа, т.е. число элементов в

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

2. 6. Отношение Отношение - это множество кортежей, соответствующих одной схеме

2. 6. Отношение

Отношение - это множество кортежей, соответствующих одной схеме

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

На самом деле, понятие схемы отношения ближе всего к понятию структурного

На самом деле, понятие схемы отношения ближе всего к понятию

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

Имя схемы отношения в таких БД всег-да совпадает с именем соответствующе-го

Имя схемы отношения в таких БД всег-да совпадает с именем

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

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

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

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

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

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

есть подмноже-ство декартова произведения
,
то есть состоит из кортежей
таких, что ai ∈ Ai, где ai - атрибут, а Ai - домен отношения .
Слайд 28

Реляционная база данных - это набор отношений, имена которых совпадают с

Реляционная база данных - это набор отношений, имена которых совпадают с

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

2. 7. Отсутствие кортежей-дубликатов То свойство, что отношения не со-держат кортежей-дубликатов,

2. 7. Отсутствие кортежей-дубликатов

То свойство, что отношения не со-держат кортежей-дубликатов, сле-дует

из определения отношения как множества кортежей. В классичес-кой теории множеств по определе-нию каждое множество состоит из различных элементов. Из этого свойства вытекает наличие у каж-дого отношения так называемого первичного ключа - набора атрибу-тов, значения которых однозначно определяют кортеж отношения.
Слайд 30

Для каждого отношения, по край-ней мере, полный набор его атри-бутов обладает

Для каждого отношения, по край-ней мере, полный набор его атри-бутов

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

Понятие первичного ключа является исключительно важным в связи с поня-тием целостности

Понятие первичного ключа является исключительно важным в связи с поня-тием

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

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

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

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

2. 8. Отсутствие упорядоченности кортежей Свойство отсутствия упорядочен-ности кортежей отношения также

2. 8. Отсутствие упорядоченности кортежей

Свойство отсутствия упорядочен-ности кортежей отношения также

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

Это не противоречит тому, что при формулировании запроса к БД, например,

Это не противоречит тому, что при формулировании запроса к БД,

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

2. 9. Отсутствие упорядоченности атрибутов Атрибуты отношений не упорядочены, поскольку по

2. 9. Отсутствие упорядоченности атрибутов

Атрибуты отношений не упорядочены, поскольку по

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

Однако в большинстве существу-ющих систем такая возможность не допускается, и хотя

Однако в большинстве существу-ющих систем такая возможность не допускается, и

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

2. 10. Атомарность значений атрибутов Значения всех атрибутов явля-ются атомарными. Это

2. 10. Атомарность значений атрибутов

Значения всех атрибутов явля-ются атомарными. Это

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

Нормализованные отношения сос-тавляют основу классического реля-ционного подхода к организации баз данных.

Нормализованные отношения сос-тавляют основу классического реля-ционного подхода к организации баз

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

3. Реляционная модель данных Когда в предыдущих разделах мы говорили об

3. Реляционная модель данных

Когда в предыдущих разделах мы говорили об

основных понятиях реляционных баз данных, мы не опирались на какую-либо конкрет-ную реализацию. Эти рассуждения в равной степени относились к любой системе, при построении которой использовался реляцион-ный подход. Другими словами, мы использовали понятия так называ-емой реляционной модели данных.
Слайд 40

Модель данных описывает неко-торый набор родовых понятий и признаков, которыми должны

Модель данных описывает неко-торый набор родовых понятий и признаков, которыми должны

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

Хотя понятие модели данных является общим, и можно гово-рить о иерархической,

Хотя понятие модели данных является общим, и можно гово-рить о иерархической,

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

3. 1. Общая характеристика Наиболее распространенная трак-товка реляционной модели данных, по-видимому,

3. 1. Общая характеристика

Наиболее распространенная трак-товка реляционной модели данных, по-видимому,

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

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

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

в реляционных БД, яв-ляется нормализованное n-ар-ное отношение. По сути дела, выше мы рассматривали именно понятия и свойства структурной составляющей реляционной мо-дели.
Слайд 44

3. 2. Целостность сущности и ссылок В целостной части реляционной модели

3. 2. Целостность сущности и ссылок

В целостной части реляционной модели

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

Конкретно требование состоит в том, чтобы любой кортеж любого отношения был

Конкретно требование состоит в том, чтобы любой кортеж любого отношения

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

Второе требование называется требованием целостности по ссылкам (или требованием ссылочной целостности)


Второе требование называется
требованием целостности по
ссылкам (или требованием
ссылочной целостности) и

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

Значение атрибута в любом кортеже отношения должно соответствовать значению атрибута в

Значение атрибута в любом кортеже отношения должно соответствовать значению атрибута

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

Пусть в отношении ρ имеется не клю-чевой атрибут a, значения которого

Пусть в отношении ρ имеется не клю-чевой атрибут a, значения которого

являются значениями ключевого ат-рибута b другого отношения σ. Тогда атрибут a отношения ρ является внешним ключом. Говорят, что от-ношение, в котором определен внеш-ний ключ, ссылается на соот-ветствующее отношение, в котором такой же атрибут является первич-ным ключом. С помощью внешних ключей устанавливаются связи меж-ду отношениями.
Слайд 49

Требование целостности по ссылкам, или требование внешнего ключа сос-тоит в том,

Требование целостности по ссылкам, или требование внешнего ключа сос-тоит в том,

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

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

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

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

Требование целостности по ссылкам, или требование внешнего ключа сос-тоит в том,

Требование целостности по ссылкам, или требование внешнего ключа сос-тоит в том,

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

Наконец, третий подход (каскадное удаление) состоит в том, что при уда-лении

Наконец, третий подход (каскадное удаление) состоит в том, что при уда-лении

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

Поскольку не всякой таблице мож-но поставить в соответствие отноше-ние, резюмируя рассмотренные

Поскольку не всякой таблице мож-но поставить в соответствие отноше-ние, резюмируя

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

2. Имена столбцов таблицы должны быть различны, а их значения про-стыми,

2. Имена столбцов таблицы должны быть различны, а их значения про-стыми,

то есть недопустима группа значений в одном столбце одной строки (свойство атомарности).
3. Все строки одной таблицы дол-жны иметь одну структуру, соответ-ствующую именам и типам (доменам) столбцов (см. понятие домена 3.2.3).
4. Порядок размещения строк в таблице может быть произвольным (свойство 3.2.8).
Слайд 55

Чаще всего таблица с отношением размещается в отдельном файле. БД может

Чаще всего таблица с отношением размещается в отдельном файле. БД может

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

4. Связывание отношений и виды связей При проектировании реальных БД информацию

4. Связывание отношений и виды связей

При проектировании реальных БД информацию

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

Многие СУБД при связывании от-ношений автоматически выполняют контроль целостности вводимых в

Многие СУБД при связывании от-ношений автоматически выполняют контроль целостности вводимых

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

Между отношениями могут уста-навливаться бинарные (между двумя отношениями), тернарные (между тремя

Между отношениями могут уста-навливаться бинарные (между двумя отношениями), тернарные (между

тремя отношениями) и т.д. В общем случае n-арные связи. Чаще всего используются бинар-ные связи. При связывании двух отношений выделяют основное и дополнительное отношение. Ло-гическое связывание отношений производится с помощью ключа связи.
Слайд 59

Ключ связи по аналогии с обычным ключом отношения состоит из одного

Ключ связи по аналогии с обычным ключом отношения состоит из

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

В зависимости от того, как опре-делены атрибуты связи основного и дополнительного

В зависимости от того, как опре-делены атрибуты связи основного и

дополнительного отношений между двумя отношениями в общем случае могут устанавливаться четыре основные вида связи:
один к одному (1:1);
один ко многим (1:M);
многие к одному (M:1);
многие ко многим (M:M).
Слайд 61

Связь вида 1:1 Эта связь образуется в случае, когда все атрибуты

Связь вида 1:1

Эта связь образуется в случае, когда все атрибуты

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

Связи вида 1:M и M:1 Вид связи 1:M имеет место в

Связи вида 1:M и M:1

Вид связи 1:M имеет место в

случае, когда одному кортежу основного отношения соответству-ет несколько кортежей дополни-тельного отношения.
Связь вида M:1 является зер-кальным отражением связи вида 1:M (достаточно поменять ролями основное и дополнительное отношения).
Слайд 63

Связь вида M:M Этот вид связи возникает в слу-чаях, когда нескольким

Связь вида M:M

Этот вид связи возникает в слу-чаях, когда нескольким

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

Контроль целостности связей Контроль целостности связей обычно означает анализ содержи-мого двух

Контроль целостности связей

Контроль целостности связей обычно означает анализ содержи-мого двух

отношений на соблю-дение следующих правил:
Каждому кортежу основного отно-шения соответствует нуль или более кортежей дополнительного от ношения.
- Предыдущая
ИНФОРМАЦИОННЫЕ СИСТЕМЫ В СЕТЯХ INTERNET И INTRANET
Следующая -
СЕТЕВЫЕ ПЛАТФОРМЫ РЕЛЯЦИОННЫХ БД

Похожие презентации

Понятие управленческих решений
«Как не воспитать Пиноккио!?»
Образование поверхностей и решение задач на пересечение поверхностей. (Лекция 4.2)
Командная работа
Типология политических режимов
АРХИТЕКТУРА РОССИИ 1850-1890-х гг.XIX века
ХУДОЖЕСТВЕННОЕ ТВОРЧЕСТВО КАК ДЕЯТЕЛЬНОСТЬ, ПРОЦЕСС И ПРОДУКТ
интерфеенционная формула
Типы конструкций и классификация фундаментов перекачивающих агрегатов и оборудования станций
Чарльз Дарвин
Трудовой договор
Лекция Система складирования
Ремонт конического редуктора
Энергосистемы и системы сбора данных для самолетов и вертолетов
Культура ХХ-ХХІ століття
Закон сохранения механической энергии
Филипп Отто Рунге (1777-1810)
Художественный промысел
Практика 1. Создание веб-страницы
Общие сведения о системах электросвязи
Особенности организации инновационной деятельности в крупном и малом бизнесе
Презентация проекта МАРАМЫГИНА Елена Леонидовна учитель-логопед МКДОУ детский сад № 9 «Росинка»
Journey of Hazard and Hope. Risks and Coping Strategies of Syrian Women Seeking Asylum in Austria
Есептеуіш жүйенің даму тарихы
Таблица-сравнение видеокарт
Особенности готовности к обучению в школе мальчиков и девочек
Как свести к нулю количество конфликтов между проектной командой и командами поддержки или I believe in love. - презентация
Методики экспрессных измерений радона
Вы можете прислать нам Вашу презентацию и мы опубликуем ее на сайте.
Обратная связь
Для правообладателей
Email: Нажмите что бы посмотреть