Access 2010 наизнанку

Question

Я недавно приобрел эту книгу в Microsoft Press. В настоящее время у меня установлен Office Enterprise 2007 (включая Access), и я твердо решил преобразовать свое приложение Informix-SQL в Access 2010. Однако у меня нет опыта работы с VBA, макросами и некоторыми другими функциями, необходимыми моему приложению. Для меня это будет новый учебный процесс, но я должен модернизировать свое 20-летнее приложение на основе символов и воспользоваться новыми функциями. Я начал определять свои таблицы и столбцы, но не отношения. С INFORMIX я присоединяю последовательный (автоинкрементный) столбец к столбцу INT в другой таблице. Теперь, когда я отображаю основную строку клиентов, я хотел бы автоматически отображать все транзакции, связанные с этим клиентом, в форме и иметь возможность добавлять, обновлять, запрашивать, удалять в обеих таблицах. Можно ли это сделать с помощью A'10?

РЕДАКТИРОВАТЬ: ОК, это то, что я сделал до сих пор, определенные таблицы и отношения:

есть еще несколько таблиц проверки для проверки, но это основные таблицы. Поэтому, если сейчас я создам форму и укажу CLIENTES (таблица клиентов), LOTES (таблица лотов), ARTICULOS (таблица элементов) и TRANSACCIONES (таблица транзакций), она создаст таблицу CLIENT в качестве главной формы и другие дочерние таблицы в качестве подчиненных. на одном экране?

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

Я также хочу убедиться, что у каждой строки в каждой таблице один и тот же store_ID (идентификатор компании), когда пользователи работают в определенной компании, так как эта система будет работать в нескольких компаниях и будет иметь консолидированные отчеты и т. Д.

Answer 1

Этот тип настройки может быть выполнен в любой версии доступа, начиная с 1992 года.

Способ, которым вы моделируете эти классические отношения «один ко многим» в доступе, состоит в том, чтобы основать родительскую форму на родительской таблице (примечаниеЯ сказал «таблица параметров», а не запрос - я собираюсь повторить это еще раз: вам не нужен запрос, объединяющий данные для вас).Затем вы создаете так называемую форму продолжения на основе дочерней таблицы.Теперь у вас есть две формы, и вы можете просто перетащить + отпустить форму для дочерней таблицы в вышеприведенную родительскую форму, и все готово.

Фактически, если вы правильно спроектировали и настроили отношения вокно отношений, затем, если вы используете мастер для создания формы, он на самом деле создаст и автоматически вставит под форму для вас.

Итак, есть несколько интересных вопросов о вышеупомянутом процессе, которые вы должны знатьКак я указывал выше, вам вообще не нужно создавать какие-либо SQL-запросы.Вам не нужно писать sql для объединения данных.Access сделает все это за вас, и сделает это без какого-либо кода.

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

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

Форма выглядит следующим образом:

На этом этапе форма будет работать без написания кода.

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

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

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

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

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

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

Answer 2

К сожалению, Stack Overflow отлично подходит для того, чтобы задать вопрос и получить ответ.Тем не менее, серьезный вопрос Q + A, основанный на предыдущем вопросе, мы обнаруживаем, что StackOverflow ДЕЙСТВИТЕЛЬНО ломается.Я сделаю это, и при всем уважении к большому переполнению стека, я бы хотел предложить вам попробовать систему, основанную на форуме, а не так.Perahps Utter access или даже форум для разработчиков по доступу здесь:

http://social.msdn.microsoft.com/Forums/en-US/accessdev

В любом случае, давайте посмотрим, что мы можем придумать.Я также должен отметить, что дизайн вашей таблицы и то, как соотнести эти таблицы, на самом деле не вопрос доступа, а просто вопрос проектирования базы данных.То, как это должно быть изложено, будет таким же для MySql, Oracle, FoxPro или фактически для ЛЮБОЙ системы реляционных баз данных, которая была у нас за последние 20 с лишним лет в нашей отрасли.Таким образом, на самом деле это не вопрос доступа, когда вы спрашиваете, как настроить базу данных.

Хорошо, давайте посмотрим.Выше у вас есть таблица LOTES, привязанная к клиентам.Если вы собираетесь присоединить (связать) таблицу LOTS к клиенту, то вам не нужен store_id в таблицах LOTES, поскольку таблица является дочерней по отношению к этой записи клиента.В любое время вы можете подняться к родительской таблице, чтобы получить эту информацию, вам не нужно повторять ее в дочерних таблицах.Таким образом, запись клиента, к которой вы, таким образом, относитесь, уже имеет идентификатор магазина, и вы сможете получить значение этого идентификатора магазина в любое время, поскольку это отношение (то есть вся идея реляционной базы данных, у вас нетповторять данные снова и снова).

И, как у вас сейчас, тот же совет относится к двум дочерним таблицам для LOTES.Опять же, им не нужен идентификатор магазина, поскольку, как вы описали выше, они уже прикреплены к таблице LOTES, которая, в свою очередь, прикреплена к таблице клиентов, где находится идентификатор магазина.Таким образом, в вашем текущем дизайне ВСЕ дочерние таблицы ниже клиента могут и должны, и должны были бы удалить store_id.

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

Таким образом, вы должны иметь STORES-> LOTES

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

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

Если вы действительно хотитеу клиентов должно быть более одного магазина, тогда вам понадобится таблица с именем tblCustomerStores.Вы прикрепите эту таблицу к клиентам как дочернюю таблицу, и эта таблица будет иметь store_id.Затем вы можете прикрепить все транзакции клиентов и т. Д. К этой таблице дочернего магазина.И эта таблица Магазина клиентов может даже включать, возможно, тип оплаты и предпочтения доставки (если они варьируются, например, от магазина к магазину).

Итак, вы начинаете с Клиентов-> Магазины клиентов-> Транзакции ->

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

И, не ясно, прикреплены ли Статьи к конкретной транзакции или нет?Если они есть, то статьи, таким образом, будут дочерними для транзакций.

Я думаю о

Клиенты-> Покупатели-> Статьи-> Лоты

И вы хотитеПокупатели магазинов-> Tranascation А вы хотите Покупатели магазинов-> Статьи

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