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

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

До появления программы Access 2007 связующие таблицы были единственным средством создания связей "многие-ко-многим". Но для поддержки средств интеграции сервисов SharePoint в Access 2007 включена новая функциональная возможность — многозначные поля.
Как следует из названия, многозначное поле может хранить более одного значения. Эта возможность очень удачно решает проблему связей "многие-ко-многим". Идея состоит в настройке связующего поля в таблице-потомке как многозначного поля. Рассмотрим пример с авторами и книгами. При отсутствии связующей таблицы вам нужно вставить столбец AuthorID в таблицу с записями о книгах для обозначения каждого автора, написавшего данную книгу.
Но обычное поле хранит единственное значение. Таким образом, в этой таблице можно указать только одного из нескольких авторов книги (если её пишет авторский коллектив).
Если же разрешить хранение нескольких значений в поле AuthorID, можно ввести список авторов.

За кадром многозначное поле в действительности использует связующую таблицу. Но программа Access скрывает эту подробность от вас, что существенно облегчает объединение связанных записей.
Для создания поля с несколькими значениями следует использовать подстановку. Как вы знаете, эта функциональная возможность выбирается на последней странице мастера Создание подстановки. С другой стороны, если у вас уже есть подстановка, в поле, необходимо внести небольшое изменение. Откройте таблицу в Конструкторе, выберите поле с подстановкой и затем в области Свойства поля щелкните кнопкой мыши вкладку Подстановка (Lookup). Найдите свойство Разрешение нескольких значений (Allow Multiple Values) и измените его значение с Нет на Да.

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

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

Многозначные поля доступны, только если применяется БД нового формата с расширением accdb . В файле с расширением mdb (БД, созданной программой Access 2003 и еще не преобразованной) вы не сможете их использовать.

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

Примечание
Поля с множественными значениями не создают проблем при переносе вашей БД на Share-Point Server.

Работа со связями "многие-ко-многим"

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

Большинство фанатов БД будут приверженцами связующим таблицам. Такие таблицы приняты, укоренились и не скрывают внутреннего функционирования вашей БД. Связующие таблицы особенно удобны, если вы хотите добавить дополнительную информацию о связи между двумя конкретными таблицами. Предположим, что вы создаете таблицу Students_Classes для учета учебных курсов, которые все студенты слушают в популярном учебном заведении. В таблицу Students_Classes можно включить дополнительные поля, такие как EnrollmentDate (дата записи на курс), Соn-firmationLetterSentDate (дата отправки подтверждающего письма) и Prerequi-sitesChecked (необходимые условия приема проверены).

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

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

Использовано:
Многозначные поля
Руководство по полям, одновременно допускающим несколько значений
Использование в запросах полей, одновременно допускающих несколько значений

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

-------------------------------------------------------------
А ты вложил уже свой кровный рубль в 50-ти миллиардное состояние Билла Гейтса?

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

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

А так создаётся впечатление, что сами авторы таких книг не слишком хорошо разбираются в предмете...

Однозначно, поля, допускающие несколько значений нельзя использовать, если Вы планируете в будущем переход на SQL Server. Их то и ввели, что бы улучшить совместимость с SharePoint. В многозначных полях мне нравится выбор значений при помощи чекбоксов. Для связной таблицы у меня реализован выбор при помощи комбобоксов. Видел выбо при помощи списка, как в настройке Access/ Из одного списка элементы перемещаешь во второй, а потом подтверждаешь выбор. Можно придумать, как и чекбоксами реализовать. Вроде здесь на форуме это обсуждалось.

Предлагаю маленький пример.
Как описано в первом посте - три таблицы: Authors , Books и таблица связи Authors_Books
Таблица Books уже доработана для множества значений. Откройте её и в поле AuthorID Вы это увидите.

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

Для его создания нужен дополнительный запрос qry_Books_Authors , созданный с участием связующей таблицы Authors_Books , и функции fnSumString()

Функция взята вот здесь . Я её когда-то разрабатывал для похожих целей

alex_p_nТак называемые "многозначные поля" - это значит, таблица ненормализована, даже к 1НФ не приведена.
По Дж. Мартину, поле должно быть атомарным. Это - основа теории БД. Всё остальное - от лукавого, и от неумения нормализовывать отношения.
ИМХО мелкомягкий Аксесс - это зло... Ну, большинству всё это прекрасно известно. А на счёт последнего утверждения... Если при забивании гвоздей, попадаешь не по гвоздю, а по пальцам, то в 99,9% виноват не гвоздь и молоток, а тот, кто забивает.

Access очень хорош в своей нише, и альтернативы ему пока нет.

ПЕНСИОНЕРКАsdku,

за последнее время смотрела 3 базы с множественным выбором
1. спичечные этикетки --поле цвет (красный,синий,зеленый...)
вполне приемлемо, пока не потребуется количество красных или зеленых

2. служба знакомств --поле цвет волос (блондинки, брюнетки...)
вполне приемлемо, пока не понадобится выделить цвет с максимальным приоритетом

3. продажа недвижимости --поле Метро (комсомольская, курская,....)
вполне приемлемо, пока не понадобится выделить приоритетную станцию

4. что-то газетное --2 поля дата и тип
невозможно выдать отчет по дате, типу

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

На самом деле сделать такой отбор довольно легко.
Вот как это описано в документации

Допустим, требуется просматривать поле «Назначено», одновременно допускающее несколько значений, развернутым таким образом, чтобы каждое значение отображалось в отдельной строке. Чтобы выполнить это, нужно задать свойство Значение, добавив строку «.Значение» к значению «Назначено» в строке Поле, как показано здесь в бланке запроса:

Бланк запроса, отображающий поля «Название» и «Назначено.Значение»

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

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

Вот пример отбора по писателям. Один запрос для Пушкина, второй - для Лермонтова.

ПЕНСИОНЕРКАПЕНСИОНЕРКА3. продажа недвижимости --поле Метро (комсомольская, курская,....)
вполне приемлемо, пока не понадобится выделить приоритетную станцию

я имела в виду
--есть 3 клиента
--одному надо квартиру с приоритетом станций --комсомольская-аэропорт-тургеневская
--второму --каширская, курская, комсомольская
--третьему --курская, комсомольская , белорусская
...
Элементарно. Делаете запрос как в примере и подставляете коды из таблицы станций. Если у Вас есть пример таблицы, можно сделать пример на отбор по станциям

Давайте подобьём итог

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

ПРОТИВ
0. Нарушается основной принцип СУРБД - одно поле - одно значение. Хотя на самом деле используется скрытая таблица
1. Связующая таблица недоступна программно. В неё нельзя добавить вспомогательные поля
2. Усложняется программный отбор по многозначным полям. И вообще, программирование многозначных полей сложнее: добавление, изменение, удаление.
3. При переносе в другую среду MS SQL, Interbase, Oracle необходимо многозначное поле разворачивать в таблицу связности. (правда, это довольно просто, но если их много...) необходимо менять все запросы, в которых задействованы многозначные поля, Дорабатывать пользовательский интерфейс.