Несколько запросов IIf в построителе выражений
11/27/2017

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

Следующее выражение показывает, что "Билли хорошо говорит". (Затем он выясняет, девочка он или мальчик, и пишет:) "Ему нравится участвовать в занятиях". "Он всегда отвечает на вопросы".

=[Имя] & "" & [Сила 1].[столбец](3) & Chr(13) & Chr(10) & IIf([Пол]= "Мужчина", "Он") & "" & IIf([Пол]= "Женщина", "Она") & [Сила 2].[столбец](3) & Chr(13) & Chr(10) & IIf([Пол]= "Мужчина", "Он") & IIf([Пол]= "Женщина", "Она") & "" & [Сила 3].[колонка](3)

ОДНАКО у некоторых студентов есть только 2 сильных стороны, и поэтому я хочу создать еще один запрос IIf (если сила равна нулю, то ничего не пишите.) Я пока не могу до конца разобраться в этом, поэтому на данный момент отчет выглядит так:

Салли хорошо говорит.

Она очень внимательна.

Она

Я пытался

=IIF([Сила 3]=[Нет],"",IIF([Пол]="Мужчина", "Он"))

Но это приводит к вышесказанному

Ответы (10)

Cecelia Sawayn
11/27/2017

Похоже, у вас проблемы со структурой данных. Если у ученика может быть несколько сильных сторон, то вам нужна дочерняя таблица. На самом деле у вас должно быть три таблицы для этого. Таблица студентов с демографической информацией о студенте. Таблица сильных сторон с перечнем всех сильных сторон на выбор. И таблица соединений для управления вашими отношениями "многие ко многим": tjxStudentStrengths Идентификатор студента (автоматический номер ПК) StudentID (FK) Strengthid (FK) С такой структурой вам не нужно беспокоиться о нулях.

Помогло 0 людям
Levi Crona Jr.
11/27/2017

Для этого я использую две таблицы. Таблица "Мои ученики" со всей информацией о моих учениках и таблица "Мои сильные стороны" со всеми сильными сторонами. В таблице учащихся есть Сила 1, Сила 2 и Сила 3. Эти поля поиска находятся в таблице прочности. Я не слишком хорошо знаком с таблицами соединений, но, похоже, даже с третьим столом у меня была бы та же проблема. Сильные стороны в таблице представлены в формате 1 - хороший слушатель. 2 хорошо разбирается в грамматике. 3 помогает другим. В этой таблице нет значений "он/она", значение "мужчина/женщина" хранится в таблице "Студент". В отчете я прикрепляю "Он" или "Она" в начале каждой строки. Однако этот он/она остается там, даже когда нет сил. Я предполагаю, что это все равно было бы так, независимо от того, был ли у меня соединительный стол или нет?

Помогло 0 людям
Homer Jast
11/27/2017

Привет, вместо =IIF([Сила 3]=[Полнота],"", IIF([Пол]="Мужчина", "Он")) попробуйте, например, =IIF(Не Полнота([Сила 3]), IIF([Пол]="Мужчина", "Он"))

Помогло 0 людям
Loretta Jakubowski
11/27/2017

> Я не слишком хорошо знаком с таблицами соединений, но похоже, что даже с > третьей таблицей у меня была бы та же проблема. Нет, вы бы этого не сделали, потому что вам не нужно было бы вызывать функцию IIF, чтобы перечислить сильные стороны ученика, только для определения его пола. Отчет будет основан на запросе следующего содержания: ВЫБЕРИТЕ учащихся.Идентификатор студента, ИМЯ И "" И Фамилия В КАЧЕСТВЕ ПОЛНОГО имени, IIF (Пол = "Мужчина", "Он", "Она") В КАЧЕСТВЕ ЛИЧНОГО ИМЕНИ, Сила ОТ (Студенты) ПРИСОЕДИНЯЮТСЯ К СИЛЕ студентов НА студентах.Идентификатор студента = численность студентов.StudentID) ВНУТРЕННИЕ сильные стороны СОЕДИНЕНИЯ НА УРОВНЕ StudentStrengths.StrengthID = Сильные стороны.Strengthid; Отчет будет сгруппирован по идентификатору студента с именами в заголовке группы и силой в разделе подробностей. Для силы используйте несвязанный элемент управления с именем txtStrength или аналогичный, со свойством ControlSource: =[personalpronoun] & " " & [Сила], если вы смещаете элемент управления именем и элемент управления силой следующим образом: [Полное имя] [txtStrength] И выполните следующее в процедуре события формата заголовка группы: MoveLayout = False, тогда первая сила будет напечатана в той же строке, что и имя учащегося.

Помогло 0 людям
Levi Crona Jr.
11/27/2017

Карл - это именно то, что нужно, большое тебе спасибо!!

Помогло 0 людям
Cecelia Sawayn
11/27/2017

> Для этого я использую две таблицы. Таблица моих учеников со всей информацией о > моих учениках и таблица моих сильных сторон со всеми сильными сторонами. > > > > В таблице студентов есть Сила 1, Сила 2 и Сила 3. Эти > поля поиска в таблице прочности. > > > > Я не слишком хорошо знаком с таблицами соединений, но похоже, что даже с > третьей таблицей у меня была бы та же проблема. > > > > Однако этот он/она остается там, даже когда нет силы. Я предполагаю, что это > все равно было бы так, независимо от того, был ли у меня соединительный стол или нет? Всякий раз, когда у вас есть поля с числами, такими как Сила 1, 2 и т.д., У вас есть повторяющаяся группа. Это нарушает правила нормализации. Ваша таблица сильных сторон должна быть таблицей соединений. Как мы с Кеном и рекомендуем. У вас не возникнет такой же проблемы, так как вы будете объединять местоимение только там, где существует запись силы. Вы также не ограничились бы тремя сильными сторонами. Хотя решение Karl действительно работает для вас, оно не устраняет основные проблемы с дизайном вашей базы данных, которые могут вызвать дальнейшие проблемы в будущем.

Помогло 0 людям
Levi Crona Jr.
11/27/2017

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

Помогло 0 людям
Homer Jast
11/27/2017

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

Помогло 0 людям
Cecelia Sawayn
11/27/2017

Привет, Карл, Просто чтобы убедиться, я не критиковал, просто объяснял.

Помогло 0 людям
Loretta Jakubowski
11/27/2017

> Это имеет абсолютный смысл с точки зрения дизайна и простоты базы данных. Это больше, чем вопрос простоты или элегантности дизайна. Реляционная модель базы данных регулируется определенными правилами и принципами, которые призваны гарантировать, насколько это возможно, что базы данных будут надежными и эффективными и не будут открыты для аномалий обновления, приводящих к появлению противоречивой информации в базе данных из-за избыточности. Процесс нормализации направлен на устранение избыточности в базе данных с помощью набора нормальных "форм", первая из которых формально определена следующим образом: Первая нормальная форма: relvar находится в 1NF тогда и только тогда, когда в каждом допустимом значении этого relvar каждый кортеж содержит ровно одно значение для каждого атрибута. Грубо говоря, на языке реляционной модели relvar (переменная отношения) приравнивается к таблице, кортеж - к строке (записи), а атрибут - к столбцу (полю). В вашем случае у вас есть до трех значений для силы атрибута благодаря наличию трех отдельных столбцов, поэтому таблица не нормирована до 1NF. То же самое относится и к нескольким значениям, хранящимся в одном столбце строки, например, в виде списка значений, разделенных запятыми, что также нарушает другое правило, Правило гарантированного доступа: каждый элемент данных (атомарное значение) в реляционной базе данных гарантированно логически доступен, если использовать комбинацию имени таблицы, значения первичного ключа и имени столбца. Это был номер 2 в наборе правил, который Кодд, впервые представивший реляционную модель базы данных примерно в 1970 году во время работы в IBM, выпустил в 1985 году в ответ на то, что он считал растущим отходом от принципов модели. То, что у вас есть, - это бинарный (двусторонний) тип отношений "многие ко многим" между учащимися и сильными сторонами. Такой тип отношений моделируется третьей таблицей, которая преобразует тип отношений "многие ко многим" в два типа отношений "один ко многим" (иногда в разговорной речи их называют таблицей "соединение"). Возможно, вам захочется взглянуть на DatabaseBasics.zip в папке "мои общедоступные базы данных" по адресу: https://onedrive.live.com/?cid=44CC60D7FEA42912&id=44CC60D7FEA42912!169 [https://onedrive.live.com/?cid=44CC60D7FEA42912&id=44CC60D7FEA42912 !169] Обратите внимание, что если вы используете более раннюю версию Access, вы можете обнаружить, что цвет некоторых объектов формы, таких как кнопки, отображается неправильно, и вам потребуется соответствующим образом изменить дизайн формы. Если у вас возникли трудности с открытием ссылки, скопируйте ссылку (примечание, а не местоположение ссылки) и вставьте ее в адресную строку вашего браузера. Этот небольшой демонстрационный файл, как следует из его названия, представляет собой простое введение в проектирование реляционных баз данных в Access и, среди прочего, объясняет различные типы отношений и то, как они используются для моделирования той части реального мира, с которой связана база данных. Реляционная база данных на самом деле является просто моделью реальности с точки зрения ее типов сущностей и отношений между ними. В Relationships.zip файл в той же папке OneDrive продвигает ситуацию немного дальше, иллюстрируя, как строятся отношения во всей модели для формирования общего набора таблиц и типов отношений, составляющих базу данных. Та же папка OneDrive также содержит Normalization.zip файл, который объясняет каждую нормальную форму (до 5NF) в простых терминах или, по крайней мере, как можно проще, но не более того. На данный момент не слишком заботьтесь о высших нормальных формах; сосредоточьтесь на том, чтобы получить четкое представление о первых трех нормальных формах. Это не значит, что высшие нормальные формы неважны, но их не так легко обойти, как первые три, и большинство таблиц, нормализованных до 3NF, будут нормализованы до высших нормальных форм уже, без необходимости что-либо с ними делать.

Помогло 0 людям

Похожие вопросы

873

Просмотров

1

Ответов

872

Просмотров

1

Ответов