Умные данные унифицируют процессы и данные в системе баз данных
Имеется несколько идей, которые надлежит исследовать под рубрикой превращения логики приложений в полноценного обитателя будущих систем баз данных. Во-первых, возможной моделью для описания приложения мог бы служить поток работ бизнес-правил. Такие системы потоков работ сейчас доступны от многих поставщиков в качестве каркасов уровня приложений. Кажется возможным собрать диаграммы потоков работ в набор триггеров и сторожей базы данных, которые выполняются внутри системы активных баз данных. Выполнение насыщенных данными потоков работ внутри системы баз данных происходит существенно быстрее, чем вне системы. Однако для поддержки потоков работ требуется возможность системы масштабироваться до наличия тысяч триггеров. Для увеличения масштаба триггерных систем на три порядка требуются значительные исследования и эксперименты.
Масштабируемая триггерная система обладает дополнительными достоинствами, поскольку имеются приложения, нуждающиеся в большом числе обычных триггеров на элементах данных. Например, пользователи систем фондовой биржи могут пожелать получать оповещение при удовлетворении конкретного условия, такого как достижение пороговой цены конкретной акции. Масштабируемая триггерная система могла бы поддерживать приложения, в которых на данных определены миллионы триггеров. Конечно, такая реализация триггеров должна работать в системе без совместных ресурсов или даже в федеративной системе. Эффективная поддержка больших наборов распределенных триггеров является открытым вопросом.
Второй аспект касается логики в традиционном смысле процедур в данном языке программирования. Популярным подходом к выражению такой логики является использование компонентов, и такие компоненты следует поддерживать внутри системы баз данных. К сожалению, еще не существует Эсперанто компонентного программирования. Могут стать популярными и CORBA, и OLE, и Enterprise Java Beans (EJB), и Jini. Поддержка нескольких (несовместимых) компонентных моделей внутри объектно-реляционной системы баз данных кажется устрашающей задачей.
Тем не менее, сообщество баз данных должно помочь развить эти модели для поддержки типов и процедур, хорошо интегрируемых с системой баз данных.
Третий аспект относится к методологиям визуального программирования. Многие проектировщики данных используют диаграммный подход для спецификации данных и проектирования приложения. Эти мощные средства могут как моделировать, так и автоматически генерировать приложение. Если компоненты будут находиться внутри системы баз данных, то такие методологии должны развиваться для работы с объектно-реляционными системами баз данных. Интересной и трудной задачей является создание визуального средства проектирования, в котором бы принимались во внимание все аспекты системного проектирования.
Последний аспект этого направления связан с языками программирования, поддерживающими долговременное хранение данных (persistent programming languages). Имеется много приложений, в которых SQL является доминирующим механизмом доступа к базам данных. Однако меньшую часть приложений (или компонентов приложений) следует специфицировать на языках программирования, поддерживающих долговременное хранение данных. Открытой проблемой является эффективная поддержка в одной и той же системе и SQL, и программ, написанных на таких языках, особенно если среда подвержена частым обновлениям.
