Правило 1 ко многим

Правило 1 ко многим

Правило 1 ко многим

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

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

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

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

А вот результат преобразования в модель.

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

www.firststeps.ru

Записки программиста

Как спроектировать схему базы данных

Время от времени я заглядываю на toster.ru и иногда даже отвечаю там на вопросы. Чаще всего люди спрашивают две вещи — как стать программистом и как правильно спроектировать схему базы данных. Мне лично кажется очень странным, что так много людей задают последний вопрос. Мне почему-то всегда казалось, что это такая простая вещь, которую умеют вообще все. Но, раз так много людей интересуются, здесь я постараюсь дать достаточно развернутый и в то же время краткий ответ.

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

Рисуем диаграмму

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

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

Если раньше вам не доводилось работать с такими диаграммами, не пугайтесь, тут все просто. Прямоугольнички — это таблицы, строки в прямоугольничках — имена столбцов, стрелочками обозначаются внешние ключи, а ключиками — первичные ключи. При желании тут можно разглядеть даже индексы, типы столбцов и обязательность их заполнения (null / not null), но для нас сейчас это не так важно.

Генерируем SQL и скармливаем его СУБД

Нетрудно заметить, что данная диаграмма легко отображается в код для создания схемы базы данных на языке SQL. В DbSchema сгенерировать SQL можно, сказав Schema → Generate Schema and Data Script. Затем полученный скрипт можно скормить используемой вами СУБД:

Я использовал PostgreSQL. Информацию о том, как установить эту СУБД, вы найдете в этой заметке.

Итак, чем же я руководствовался при проектировании схемы?

Нормальные формы

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

Грубо говоря, таблица находится в первой нормальной форме (1НФ), если на пересечении любой строки и любого столбца в таблице находится ровно одно значение. В современных РСУБД это условие всегда выполняется. Даже если СУБД поддерживает множества или массивы, на пересечении строки и столбца хранится ровно одно значение типа множество или массив. Но в таблице (user varchar(100), phone integer) не может быть строки alex — 1234, 5678 . В 1НФ может быть только две сроки — alex — 1234 и alex — 5678 .

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

Таблица находится в третьей нормальной форме, если она находится в 2НФ и ни один неключевой атрибут не находится в транзитивной функциональной зависимости от первичного ключа. Например, рассмотрим таблицу (employee varchar(100) primary key, department varchar(100), department_phone integer) . Очевидно, что она находится в 2НФ. Но телефон отдела находится в транзитивной функциональной зависимости от имени сотрудника, так как сотрудник однозначно задает отдел, а отдел однозначно задает телефон отдела. Для приведения таблицы в 3НФ нужно разбить ее на две таблицы — employee — department и departmnet — phone .

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

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

Отношение один ко многим

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

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

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

Жанры и страны в приведенной схеме иногда еще называют «словарями». Это сравнительно небольшие таблицы, состоящие из двух столбцов — id и названия. Если, например, мы захотим переименовать страну Russia в Russian Federation, нам придется поменять всего лишь одну строчку в таблице countries, а не править кучу строк в таблице artists, что может привести к очень большому количеству дисковых операций. Кроме того, если требуется отобразить в диалоге создания нового исполнителя выпадающий список с выбором страны, нам не придется делать дорогих группировок по таблице artists, достаточно сделать простую выборку из countries.

Отношение многие ко многим

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

Оно моделируется путем введения дополнительной таблицы. В нашем примере эта таблица называется albums_songs. Первичный ключ в этой таблицы состоит из двух внешних ключей — album_id и song_id. Теперь нетрудно с помощью пары join’ов получить все песни, входящие в данный альбом или все альбомы, в которые входит заданная песня. Кроме того, ничто не мешает завести в связующей таблице дополнительные столбцы. Например, столбец, хранящий номер трека, под которым песня входит в заданный альбом.

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

Отношение родитель-потомок (или общее-частное)

Исполнители могут быть разных типов. Это может быть отдельно взятый(ая) певец/певица, или же группа. У всех исполнителей, независимо от конкретного типа, есть что-то общее. Например, страна, адрес официального сайта и так далее. Но кроме того, есть некоторые свойства, характерные только для данного типа. У певицы явно нет никакого названия группы, а у группы нет имени, фамилии и пола. Аналогичная ситуация возникает, скажем, если у вас есть сотрудники, занимающие различные должности и свойства сотрудников зависят от занимаемых должностей.

Один из способов моделирования такой ситуации заключается в введении по отдельной таблице на каждый из возможных подтипов. В приведенном примере это таблицы groups и persons. В качестве первичного ключа в каждой из этих таблиц используется artist_id, первичный ключ родительской таблицы artists. Кто-то при использовании такой схемы предпочитает добавить в родительскую таблицу столбец type, но, строго говоря, он является избыточным. Недостаток этого метода заключается в том, что можно создать исполнителя, являющегося как группой, так и человеком одновременно.

Есть и другие подходы. В PostgreSQL, например, есть наследование таблиц, предназначенное для решения как раз такой вот проблемы. Если вы работаете с PostgreSQL, нет причин не использовать этот механизм. Кто-то предпочитает ввести одну таблицу для всех типов с дополнительным столбцом type. Если некий столбец не имеет смысла для заданного типа, в него пишется null. Но это, как вы можете подозревать, не очень-то удобно, если у вас 10 типов, каждый из которых имеет по дюжине столбцов, характерных только для этого типа, а также парочку собственных подтипов. Кроме того, можно опрометчиво реализовать смену типа, как простое обновление столбца type, и получить массу интереснейших эффектов.

Что еще нужно принять во внимание

Принцип при моделировании других отношений тот же. Например, один человек имеет двух родителей и при этом один человек может иметь сколько угодно детей. Казалось бы, связь 2:N, этого мы не проходили. На самом деле, это просто две связи 1:N. Вводим столбцы mother_id, father_id и вперед. Да, связь в рамках одной таблицы, ну и что?

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

В общем, все, что нужно, это немного здравого смысла.

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

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

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

Заключение

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

Проект для DbSchema, а также сгенерированный из него SQL, вы можете скачать здесь. Как всегда, если у вас есть вопросы или дополнения, не стесняйтесь писать их в комментариях.

eax.me

Руководство по связям между таблицами

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

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

В этой статье

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

1. Эта форма содержит данные из таблицы клиентов,

4. и сведений о заказах.

Имя клиента в поле Плательщик получено из таблицы «Клиенты», значения кода заказа и даты заказа — из таблицы «Заказы», наименование товара — из таблицы «Товары», а цена и количество — из таблицы «Заказано». Чтобы можно было передать данные в форму, эти таблицы связаны друг с другом несколькими способами.

В приведенном примере поля в таблицах должны быть согласованы таким образом, чтобы отображать сведения об одном и том же заказе. Это согласование осуществляется путем установления связей между таблицами. Связь между таблицами устанавливает отношения между значениями в ключевых полях — часто между полями, имеющими одинаковые имена в обеих таблицах. В большинстве случаев с первичным ключом одной таблицы, являющимся уникальным идентификатором каждой записи, связывается внешний ключ другой таблицы. Например, для связывания сотрудников с заказами, за которые они отвечают, можно создать связь между полями «Код сотрудника» в таблицах «Сотрудники» и «Заказы».

1. Поле «Код сотрудника» отображается в двух таблицах: как первичный ключ.

2. и как внешний ключ.

Типы связей между таблицами

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

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

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

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

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

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

Зачем создавать связи между таблицами?

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

Связи между таблицами предоставляют сведения для структурирования запросов

Для работы с записями из нескольких таблиц часто приходится создавать запросы, соединяющие таблицы. Запрос сопоставляет значения в поле первичного ключа первой таблицы с полем внешнего ключа второй таблицы. Например, чтобы получить строки, в которых перечислены все заказы для каждого из клиентов, можно создать запрос, соединяющий таблицу «Клиенты» с таблицей «Заказы» на основе поля «Код клиента». В окне отношений можно вручную указать поля для соединения. Но если отношение между таблицами уже существует, Access использует соединение по умолчанию на основе существующего отношения между таблицами. Кроме того, при использовании одного из мастеров запросов Access использует сведения об уже определенных связях между таблицами, чтобы предоставить пользователю выбор и подставить в параметры свойств соответствующие значения по умолчанию.

Связи между таблицами предоставляют сведения для структурирования форм и отчетов

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

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

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

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

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

Предположим, между таблицами «Грузоотправители» и «Заказы» существует связь «один-ко-многим», и нужно удалить грузоотправителя. Если у грузоотправителя, которого нужно удалить, есть заказы в таблице «Заказы, они станут потерянными записями после удаления записи грузоотправителя. В таблице «Заказы» останется код грузоотправителя, но он будет недействителен, поскольку запись, на которую он ссылается, уже не существует.

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

Целостность данных обеспечивается путем ее включения при создании межтабличного отношения (см. пошаговое руководство Обеспечение целостности данных). Если однажды обеспечить целостность данных, Access будет отклонять все обновления, нарушающие ее для этого межтабличного отношения. Это значит, что Access будет отклонять как обновление целевого объекта ссылки, так и его удаление. Но может понадобиться изменить первичный ключ для грузоотправителя, имеющего заказы в таблице «Заказы». В таких случаях нужно, чтобы приложение Access автоматически обновило все задействованные строки за одну операцию. Так Access гарантирует, что обновление полностью завершено и база данных не оказалась в несогласованном состоянии (одни строки обновлены, а другие — нет). Для этого в Access есть параметр «Каскадное обновление связанных полей». Если при обеспечении целостности данных выбрать параметр «Каскадное удаление связанных полей», а затем обновить первичный ключ, Access автоматически обновит все поля, ссылающиеся на этот ключ.

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

Просмотр связей между таблицами

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

Вызов окна «Схема данных»

В диалоговом окне Открытие файла базы данных выберите и откройте базу данных.

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

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

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

Когда открыто окно «Схема данных», на ленте доступны указанные ниже команды.

На вкладке Конструктор в группе Сервис

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

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

Отчет о связях . Создает отчет, отображающий таблицы и связи базы данных. В отчете отображаются только таблицы и связи, не скрытые в окне «Схема данных».

На вкладке Конструктор в группе Отношения

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

Скрыть таблицу . Скрывает выбранную таблицу в окне «Схема данных».

Прямые связи . Отображает все связи и связанные таблицы для выбранной таблицы в окне «Схема данных», если они еще не отображены.

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

Закрыть . Закрывает окно «Схема данных». Если в макет окна «Схема данных» были внесены какие-либо изменения, будет предложено сохранить их.

Создание связи между таблицами

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

Создание связи между таблицами с помощью окна «Схема данных»

На вкладке Работа с базами данных в группе Отношения щелкните элемент Схема данных.

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

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

Выберите одну или несколько таблиц или запросов и нажмите кнопку Добавить. По завершении добавления таблиц и запросов в окно «Схема данных» нажмите кнопку Закрыть.

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

Откроется диалоговое окно Изменение связей.

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

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

Нажмите кнопку Создать.

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

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

Создание отношения «один-ко-многим». У поля на стороне отношения «один» (как правило, поля первичного ключа) должен быть уникальный индекс. Это означает, что свойство Индексированное этого поля должно иметь значение Да (без повторов). Поле на стороне «многие» не должно иметь уникального индекса. Это поле может быть индексированным, но для него должны допускаться повторы. Это означает, что свойство Индексированное этого поля должно иметь значение Нет или Да (с повторами). Когда у одного поля однозначный индекс, а у другого — нет, в приложении Access создается отношение «один-ко-многим».

Создание связи между таблицами с помощью области «Список полей»

Добавить поле к существующей таблице, открытой в режиме таблицы, можно путем его перетаскивания из области Список полей. В области Список полей отображаются поля, доступные в связанных, а также в других таблицах. При перетаскивании поля из другой (несвязанной) таблицы и заполнения полей с помощью мастера подстановок автоматически создается новое отношение «один-ко-многим» между таблицей из области Список полей и таблицей, в которую было перемещено поле. Это отношение, созданное приложением Access, не гарантирует целостность данных по умолчанию. Чтобы обеспечить целостность, необходимо соответствующим образом изменить отношение. Дополнительные сведения см. в разделе Изменение межтабличного отношения.

Открытие таблицы в режиме таблицы

На вкладке Файл нажмите кнопку Открыть.

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

Открытие области «Список полей»

Нажмите клавиши ALT+F8.

Будет отображена область Список полей.

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

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

Добавление поля и создание связи из области «Список полей»

В области Список полей в группе Доступные поля в другой таблице щелкните знак плюс (+) рядом с именем таблицы.

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

Когда появится линия вставки, вставьте поле в нужное место.

Появится окно мастера подстановок.

Следуйте инструкциям мастера подстановок.

Поле будет отображено в таблице в режиме таблицы.

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

Удаление отношения между таблицами

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

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

Щелкните линию связи, которую требуется удалить. Выделенная линия связи станет жирной.

Нажмите клавишу DEL

Щелкните правой кнопкой мыши и выберите команду Удалить.

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

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

Изменение связи между таблицами

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

Внесите изменения в диалоговом окне «Изменение связей».

На вкладке Работа с базами данных в группе Отношения нажмите кнопку Схема данных.

На вкладке Конструктор в группе Связи нажмите кнопку Все связи.

Появятся все таблицы с отношениями, а также соответствующие линии.

Щелкните линию связи, которую требуется изменить. Выделенная линия связи станет жирной.

Дважды щелкните линию связи.

Внесите изменения и нажмите кнопку ОК.

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

Указание типа соединения

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

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

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

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

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

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

Указание типа соединения

В диалоговом окне Изменение связей нажмите кнопку Тип соединения.

Откроется диалоговое окно Параметры соединения.

Выберите нужные параметры и нажмите кнопку ОК.

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

support.office.com

admin

Обсуждение закрыто.