<атрибут, оператор, значение-операнда> или <атрибут, условие, атрибут>

где <условие>-одно из условий сравнения. Результатом работы компаратора является признак ИСТИНА или ЛОЖЬ.

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

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

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

Операнды проще всего размещать во внешней памяти, общей для всех компараторов. Время обращения к общей памяти налагает в этом случае ограничения на число компараторов в фильтре. Если время ввода одной записи 100 не, а время работы компаратора 400 не, то нет смысла иметь более четырех компараторов. Использование СБИС-технологии позволяет обеспечить каждому компаратору достаточную внутреннюю память (порядка 256 байт).

Существует ряд проблем, которые находятся пока за рамками исследований по МВД.

1. Повышение эффективности хранения данных в больших БД часто связывают со сжатием данных, специальным кодированием данных и т. п. Но псевдоассоциативный поиск и фильтрация данных непосредственно в УМП трудно реализуемы, если данные в УМП хранятся в сжатом и закодированном виде. Пока только в единственном проекте DS DBS предпринята попытка решить эту проблему.

2. При разработке МЕД совсем не рассматривается проблема обеспечения интерактивного взаимодействия пользователя с БД посредством графического дисплея. Если терминалы работают под управлением МБД, то сложность ОС МБД существенно возрастает, что может привести к деградации общей производительности МБД. Если терминалы пользователя работают под управлением главной ЭВМ, то растет объем данных, передаваемых от МБД в главную ЭВМ и наоборот.

3. Повышение производительности МВД обычно связывается со скоростью выполнения операций, деревьев запросов, отдельных транзакций и смеси таких транзакций. При этом выдача данных терминальному пользователю начинает осуществляться только после выполнения последней реляционной операции в последовательности операций, соответствующих запросу. Иногда для принятия решения достаточно нескольких кортежей, являющихся результатом этой последовательности (дерева запроса). Увеличение реактивности МБД при выдаче этих нескольких кортежей, удовлетворяющих запросу, часто противоречит увеличению традиционной пропускной способности МВД. Решить эту проблему можно только реализацией в МВД такого режима потоковой обработки отношений, при котором реляционная операция начнет выдавать результирующие кортежи, не ожидая появления целиком сформированных отношений-операндов. Для ряда операций реляционной алгебры сложности 0(n^2) (где n-кардинальность отношений-операндов) реализация такого режима трудно разрешима, например для операции сортировки отношений.

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

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

Наличие указанных проблем в проектировании МВД заставляет некоторых авторов на вопрос «Существует ли идеальная МБД?» ответить следующим образом: «Идеальная МБД, если она существует, должна быть, очевидно, слишком дорогостоящей и слишком сложной, чтобы ее можно было использовать универсально в каждой области применений».

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