Системы управления базами данных

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

Сегодня, наконец, можно сказать, что серверы приложений (Application Server) сформировались как самостоятельный класс программных продуктов. Согласно прогнозу IDC, объем рынка этого ПО, достигнет к 2003 году более чем 2 млрд. долл. Одна из задач серверов приложений — обеспечить совместимость с унаследованными системами, предоставить гибкие средства администрирования и адекватную документацию. Цель этой статьи — посмотреть, как эти и другие, типичные для программного обеспечения данного класса задачи решает Borland Application Server 4.

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

Категория программного обеспечения, называемая «Корпоративные серверы приложений» (enterprise application server - EAS) по традиции считается еще одним элементом ПО промежуточного слоя, известна примерно с середины 90-х. Однако внимательный анализ показывает, что посреднические функции разрослись настолько, что EAS превратился в центральный узел корпоративной информационной системы.

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

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

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

За последние годы произошел бурный рост продаж систем оперативной аналитической обработки данных (OLAP - online analytical processing) и хранилищ данных (Data Warehouse), однако до сих пор неясен вопрос, в чем же привлекательность этих систем?

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

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

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

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

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

По мере того, как механизмы обработки запросов становятся все масштабнее и приобретают федеративный характер, они должны удовлетворять требованиям непредсказуемых и быстро меняющихся сред. В проекте Telegraph мы попытались разработать и реализовать механизм непрерывно адаптирующейся обработки запросов, отвечающий требованиям глобальных систем, массивного параллелизма и нейронных сетей. Чтобы подготовить почву для нашего исследования, мы представляем обзор проделанной раннее работы, касающейся адаптивной обработки запросов, первоочередное внимание уделяя трем характеристикам адаптивности: частоте адаптивности, эффекту адаптивности и диапазону адаптивности. С учетом данных этого обзора мы наметили направления исследования в рамках проекта Telegraph*.

В обработке запросов к базе данных оптимизация многими считается «трудной» частью, будь то реляционные, пост-реляционные, объектно-ориентированные, текстовые, пространственные, временные, федеративные или созданные на основе Web системы баз данных. Исполнение запросов, с другой стороны, рассматривается как простое упражнение по реализации алгоритмов с популярной сейчас возможностью использования процессорной кэш-памяти. Существует, однако, и третья составляющая этой головоломки, а именно, проектирование физической базы данных, т. е., множества подходящих индексов. Цель этой короткой статьи состоит в том, чтобы связать эти три фрагмента вместе и помочь студентам и ученым получить более широкое представление об адаптивной обработке запросов. Вторая цель - представить некоторые противоположные точки зрения по интересным и достойным изучения темам.

Мы продолжаем знакомить читателей с книгой Криса Дейта и Хью Дарвена «Foundation for Object/Relational Databases: The Third Manifesto» (начальные главы книги обсуждались в предыдущем выпуске журнала - прим. ред.). В этот раз мы рассмотрим третью и четвертую главы книги ? «Третий манифест» и «Новая реляционная алгебра». Третья глава читается не очень легко; она написана в очень формальном стиле и не содержит пояснений. Но без этого материала трудно понять следующие, неформальные и дискуссионные главы. Мне самому очень нравится четвертая глава, где вводится новая, минимизированная версия реляционной алгебры. По-моему, создание этой алгебры относится к главным достижениям авторов книги.

Обзор первой части книги

Технология, лежащая в основе распределенной обработки, оболочки и среда языка Java относительно новы и меняются очень быстро. В силу чего необходимо, чтобы современные инструментальные средства разработки приложений быстрее адаптировались к требованиям пользователей. В данной статье рассказывается о том, как эти инструментальные средства можно сделать более гибкими и настраиваемыми. В качестве примера приводится архитектура Business Component Prototyper for IBM SanFrancisco.