Поиск и отношения Microsoft Access

Я разрабатываю информационную систему на основе Microsoft Access 2013. Одним из требований клиента было упростить процесс ввода данных с помощью выпадающего списка с доступными значениями.

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

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

Microsoft Access имеет встроенный мастер поиска, который позволяет пользователю связать поле таблицы с определенным полем из другой таблицы, например. чтобы связать cityID из tblVoyage с tblCities/cityID с помощью мастера поиска и позволить пользователю выбрать город из поля со списком, а не путем ввода идентификатора определенного города в поле.

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

Я хочу:

  1. Чтобы понять, когда именно я должен использовать мастер поиска Access и когда определить связь между таблицами.
  2. Как правильно свести к минимуму количество раз, когда пользователю приходится вводить данные, а не выбирать нужный элемент из поля со списком.

relational-database database-design ms-access lookup-tables
person Mike B.    schedule 04.05.2013    source источник

Ответы (1)


arrow_upward
8
arrow_downward

Общее мнение здесь, по-видимому, заключается в том, что следует избегать полей поиска. На самом деле это просто короткий путь к «правильной» таблице поиска, и они скрывают то, что на самом деле происходит на уровне таблицы. Например, предположим, что у вас есть поле поиска для [Размер] со значениями «Маленький», «Средний» и «Большой». Когда вы смотрите на таблицу, вы видите слова, но велика вероятность, что таблица действительно содержит числа, такие как 1, 2 и 3. Вы переходите к

UPDATE tblName SET Size="Large"

и запрос терпит неудачу, потому что это то, что вам действительно нужно сделать, это

UPDATE tblName SET Size=3

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

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

Редактировать

Мастер поля со списком проведет вас через процесс привязки поля со списком к его источнику записи (таблице поиска) и привязки его значения к полю в таблице данных. Например, предположим, что вы уже настроили таблицу поиска для [Агентов].

ID  AgentName
--  ---------
 1  Gord     
 2  Angie

...и таблица данных для [Accounts]

ID  agentID  AccountName
--  -------  -----------

Вы создаете новую форму с таблицей [Accounts] в качестве ее Record Source. Когда вы добавляете поле со списком в форму, должен запуститься мастер и спросить вас: «Как вы хотите, чтобы ваше поле со списком получало свои значения?». Вы выбираете «Я хочу, чтобы поле со списком получало значения из другой таблицы или запроса».

cbw1.png

На следующем шаге вы выбираете таблицу [Агенты]:

cbw2.png

Затем вы сообщаете мастеру, что хотите отобразить [имя_агента]:

cbw3.png

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

cbw4.png

Наконец, вы можете выбрать, что произойдет со значением флажка. Здесь вы «привязываете» его к полю [agentID] в таблице [Accounts]:

cbw5.png

Обратите внимание, что поле со списком будет отображать [agentName] для выбора пользователем, но его .Value будет числовым [Agents].[ID], и это то, что будет сохранено в [Accounts].[agentID].

person Gord Thompson    schedule 04.05.2013
comment
Не могли бы вы уточнить: «Вы все еще можете спроектировать свои формы так, чтобы поле со списком заполнялось таблицей поиска и привязывалось к полю в основной таблице»? Как именно я могу это сделать? Это жестко закодировано в VBA или есть какой-то мастер или что-то в этом роде? - person Mike B.; 05.05.2013
comment
@Mike Да, мастер Combo Box Wizard проведет вас через этот процесс. Я обновил свой ответ, чтобы проиллюстрировать. - person Gord Thompson; 05.05.2013
comment
@Gord Thompson Это хорошо работает для отношений «1 ко многим», но в отношениях «многие ко многим», скажем, проектов и отделов - это кажется действительно невозможным с элементами управления доступом. Отмеченный список [DepartmentNames], который заполняет промежуточную таблицу projID, DepID, Assigned, Status, является головным убором. Если у вас есть идеи по этому поводу, я открыт. - person Ken; 03.03.2016