БД Access - перекрёстная зависимость

[Ник Ример]

Доброго времени суток!
Занимаюсь в факультативное время программированием под началом Delphi XE2 базы данных Access 2010 для нужд предприятия.
С самим делфи знаком достаточно давно, на любительском уровне, без изысков. Но вот практика написания баз данных у меня впервые. Первые шаги были пройдены довольно успешно, программа удаётся вполне сносная, но вот на каком моменте застрял.. сейчас объясню по-порядку, буду объяснять долго, зато, надеюсь, это сократит потом время на лишние объяснения.

Есть база данных с двумя таблицами Comp и Feed.
Имею ADOConnection1, и две пары: TCompData (TADOTable), DSCompData (TDataSource) и соответственно TFeedData, DSFeedData. Сюда загружены таблицы, всё это замечательно отображается в DBGrid'ах.

Таблица Comp считается главной. Там находится информация, как в общем называется продукция (Конфеты), Цвет (красный, синий и т.п.), какой тип упаковки (Коробка, Конверт, Пакет и т.п.) и Примечания.
Таблица Feed содержит вторичную информацию по ПОЗИЦИЯМ конфет на складе. Там есть информация, где лежит, сколько штук.

Одной записи Comp соответствовать может таким образом несколько записей таблицы Feed.

Пример:

Таблица Comp:
1 строка:
Конфеты | красные | коробка | <пусто>
2 строка:
Конфеты | синие | пакет | для Иванова
3 строка:
Конфеты | зелёные | коробка | остатки

Таблица Feed:
Для 1 строки:
Ящик №1 | 5000 штук
Для 2 строки:
Шкаф в цеху | 15000 штук
Для 3 строки:
Лоток №5 | 100 штук
Лоток №10 | 50 штук

Первая таблица прекрасно фильтруется, например, на запросе "красные" мы увидим в первой таблице только строку 1 и во второй таблице все её позиции (ящик №1).

Но!
Понадобилось ввести отчёты (это я сделаю c помощью FastReports). А именно отчёт дефицита. Т.е. нужно получить список всех ПОЗИЦИЙ, где количество (вот этих "штук") меньше заданного числа. Технически сам фильтр не сложен, я задавал фильтр по второй таблице, он всё отсеивал.
Но! если я даю фильтр, например, меньше или равно 100, то я увижу только строки типа:
Лоток номер 5 | 100 штук
Лоток номер 10 | 50 штук

Но я получаю только вторичную информацию! Т.е. при этом мне не известно, что это за конфеты! Синие, фиолетовые или серо-буро козявчатые. При клике на строки я не получаю зависимые от них строки из первой таблице, где бы я видел, какие это конфеты, т.к. зависимость-то обратная!
Пробовал, например, менять KeyFields и MasterFields местами (т.е. создать как бы наоборот зависимость первой таблицы от второй), но меня послали очень далеко..

В общем наконец-то добрались до сути моего вопроса.
Мне надо получить одну таблицу! Не две таблицы с зависимостью, что щёлкаешь на отфильтрованную позицию и видишь строку с названием, а единую таблицу.
Как бы мне устроить такой фильтр, чтобы я получил какую-то единую таблицу, где бы я видел все отсортированные позиции, где количество меньше заданного, но при этом ещё и (например, в отдельной колонке) название конфет (из первой таблицы), соответствующее данной позиции? Ведь это всё надо выдать потом на печать..

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

Любую дополнительную информацию готов предоставить.
Надеюсь на вразумительные ответы по существу. Спасибо!

[_SERGEYX_]

Что значит "даю фильтр"?
Непонятно по каким полям связаны таблицы. Допустим они связаны по полю NUM.
Запрос будет выглядеть примерно так:

select Comp.*, Feed.* from Comp, Feed where
comp.NUM = Feed.NUM and
Feed.Kolichestvo <=100

Разумеется, для правильной работы тип поля "Kolichestvo" должен быть числовым

[Ник Ример]

Что значит "даю фильтр"?

Значит фильтрую TFeedData.

есть такой обработчик события

procedure TDM1.TFeedDataFilterRecord(DataSet: TDataSet; var Accept: Boolean);
begin
      Accept:=(DataSet['Количество'] <= Form3.EqualSpin.Value)
end;

где-то дальше по тексту:

with TFeedData do begin
    Filtered:=false;
    Filtered:=true;
end;

Непонятно по каким полям связаны таблицы.

У таблицы comp есть поле КОД, ключевое, инкрементное. Его Visible, конечно, false, эта информация нужна только для связи таблиц.
Таблица Feed имеет поле НОМЕР, числовое. Тоже невидимое для пользователя.
Эти поля между собой связаны. У TFeedData: MasterSource='DSCompData'; MasterFields='КОД'; IndexFieldNames='НОМЕР';

Не совсем понятно, куда попробовать ваш код. Я так понимаю, это SQL-запрос.. Так как я с ними пока не очень-то знаком то скажи, пожалуйста, что будет за результат твоей операции?

[Скандербег]

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

Эта "единая" таблица собирается с помощью SQL запросов, синтаксис и действия которых, хочешь-не-хочешь, а изучать придется.
А все это "безобразие" укладывается в понятие реляционная база данных. Кстати, в представленной описанием БД, нет дополнительных таблиц, хранящих разные цвета и тип упаковки. Это, прошу прощения, считается невежеством. В главной таблице Comp должны хранится не названия цветов и типов упаковки, а ссылки на строки (их номера) из доп. таблиц, где эти понятия определены.
Рекомендую посидеть в "библиотеке". Здесь в форуме есть отличная подборка литературы по разработке БД.

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

[Ник Ример]

я ещё раз уточню, что сам связываюсь с БД первый раз, поэтому первый блин комом (надеюсь, второй будет экзешником). Хотелось бы понимать, как так не две таблицы, когда я конкретно две в акцессе создавал?
Я так понимаю, вы предлагаете, чтобы таблица была одна, единая, а все данные на отображение пользователю предоставлялись по эскуэл-запросам? Это хороший вариант, надо будет его рассмотреть, хотя и придётся переписывать половину программы.. надо учиться на своих ошибках.
Если сможете посоветовать что-то конкретное - я был бы признателен. Читаю в метро, пока еду на работу или обратно, на программирование само времени очень мало, если поможете, чтобы я не тратил его ещё на поиски из великого множества книг.. но это если не сложно, а то ещё скажете, ваще обленились.

[Скандербег]

...вы предлагаете, чтобы таблица была одна, единая,...

Совсем наоборот. Современные реляционные СУБД (коей является и МС Аксесс) предполагают, что в "главной" таблице не хранятся в явном виде информация о повторяющихся данных. А хранятся только ссылки на строки, которые находятся в других таблицах, где эти данные записаны в единственном уникальном экземпляре.
Вот и в вашем примере такая зависимость (иначе ссылка, реляция) тоже существует.
Таблица Comp:
1 строка:
Конфеты | красные | коробка | <пусто>

Таблица Feed:
Для 1 строки:
Ящик №1 | 5000 штук

Здесь, если рассматривать реальные структуры таблиц, то слова "1 строка" в таблице Comp - это уникальный номер ее строки (поле должно быть типа "Счетчик").

Если, к примеру, имя поля, которое содержит уникальные значения строк в таблице Comp называется ID (назовите как угодно, Код, допустим), а в первой строке этой таблицы поле ID имеет значение 1, то в таблице Feed, поле, которое должно ссылаться на строку из т. Comp тоже должно иметь значение 1. Это и есть ссылка (реляция) одной таблицы на другую, а в конечном итоге, зависимости между таблицами.
Тогда для примера таблицы будут выглядеть так:

Таблица Comp:
ID | наименов |  цвет   | вид уп  
 1 | Конфеты  | красные | коробка

Таблица Feed:
ID | ID_Comp | место    | колич
  1|        1| Ящик №1  | 5000
  2|        1| Лоток №5 | 100

В поле ID_Comp таблицы Feed записаны номера строк из таблицы Comp (назовем это ссылкой).

Поля Продукция, Цвет и ВидУпаковки в главной таблице тоже не должны содержать явную информацию о имени продукции, цвете и упаковке, а только ссылки на другие таблицы (т.е. номера строк в других таблицах). В таблице Цвет, например, нужно будет указать все возможные цвета, каждый со своим уникальным номером для дальнейшего применения в главной таблице. И таблица Виды упаковок тоже должна выглядеть похожим образом, только с перечислением возможных видов упаковок.
В главной же таблице мы не будем записывать явно "Красный" или "Зеленый", а укажем только номер строки из таблицы Цвета.
Тогда главная таблица вообще может не иметь явных данных, а выглядеть так:
Таблица Comp:
1| 2| 3 |5

Что касается SQL запросов, то при показанной структуре таблиц БД, они обладают всеми средствами чтобы объединять данные из таких "разрозненных", но логически связанных таблиц, чтобы получать информацию в нужном на определенный момент составе. Для показа на форме клиента или в каких-либо отчетах.

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

Чтобы не загромождать форум, в общем-то бесполезными для всех постами, напишите на мыло san-46<пес>yandex.ru.