Базы данных Oracle - статьи
Универсальный сервер Oracle ®
Я не случайно привел заголовок именно в таком виде: не так давно суд в США потребовал, чтобы все публичные упоминания термина “универсальный сервер” делались именно в таком виде - с обязательным указанием логотипа фирмы-производителя. С этим пожалуй стоит согласиться, ибо вокруг данного термина в последнее время было сломано немало “маркетинговых копий”, и различные фирмы вкладывают в него различный смысл и - если хотите - различные технологические стандарты. Я попробую объяснить, как трактует данный термин корпорация Oracle, затем кратко рассказать, какие элементы “Универсального сервера Oracle” реализованы в версии 7.3, затем совсем уж немного поговорить о том, что нового ждет пользователей в этом плане в Oracle8.
Итак, что подразумевает корпорация Oracle, говоря об универсальном сервере? Речь идет о трех составляющих этого понятия.
Любой масштаб СУБД.
Oracle традиционно славится как поставщик СУБД для крупных инсталляций, однако в связи с этим бытует (и активно поддерживается конкурентами) также и мнение о том, что для небольших систем Oracle слишком тяжеловесен, сложен, дорог и пр. В общем-то это никогда не было правдой, но в особенности в последние несколько лет Oracle прикладывает немало усилий, чтобы по всем параметрам (включая цены) утвердиться в качестве основного поставщика во всех сегментах рынка СУБД, начиная с небольших рабочих групп. С 1994 года помимо уже привычного “сервера масштабы предприятия” поставляются другие его варианты: “сервер для рабочих групп” (Workgroup server) и “персональный Oracle” (Personal Oracle) в двух редакциях - полной и “облегченной” (Personal Oracle Lite). В этих продуктах особый упор сделан на их относительную дешевизну, простоту установки и сопровождения. При этом все варианты сервера Oracle функционально идентичны за исключением некоторых опций (только в нынешней версии Personal Oracle Lite отсутствует часть базовой функциональности: он не поддерживает многопользовательские схемы данных и процедурные расширения SQL).
Любой тип приложений.
Как я уже показывал в предыдущих разделах Oracle7 в одинаковой степени может быть оптимизирован и для OLTP-приложений, и для приложений DSS, причем их вполне можно исполнять одновременно, не беспокоясь о дополнительных блокировках, модах изоляции и прочих темах, способных вызвать головную боль у знакомых с ними на практике специалистов при одном только их упоминании.*
Любой тип данных.
По этой теме поговорим чуть подробнее, тем более, что именно этот вопрос чаще всего муссируется, когда речь идет о том или ином “универсальном сервере”.
В сущности речь идет о расширении стандартного набора типов данных, характерного для РСУБД, а в перспективе о переходе к объектно-реляционной модели СУБД*. В свою очередь эта задача может быть разделена на две:
Oracle развивает свой сервер в обоих направлениях. В версии 7.3 уже поддерживается несколько новых типов данных: неструктурированные тексты, пространственные данные, видеоданные. Собственно говоря, хранить такие данные в БД и осуществлять к ним доступ можно было и раньше: новизна в том, что если раньше этот доступ осуществлялся через самостоятельно работающие серверные процессы, и для работы с ними требовалось использование специального интерфейса на уровне приложений, то теперь данная функциональность интегрирована в “базовый” сервер, так что, к примеру, можно выполнить SQL-запрос типа
SELECT имя, фамилия FROM Кандидаты WHERE Парт_членство NOT IN ('КПРФ', 'ЛДПР') AND CONTAINS ( Обещания,'Снижение налогов & Повышение дотаций’);
Как нетрудно догадаться, в примере используется таблица “Кандидаты”, в которой в одно из полей (BLOB-типа), названное “Обещания”, загружены некие тексты (которые могли иметь в оригинале практически любой известный формат). После загрузки текст индексируется специальным образом, так что даже при очень большом объеме документов контекстный поиск осуществляется быстро. Такая функциональность достигается при включении в сервер Oracle7 контекстной опции (Context Option)*.
Опция для работы с пространственными данными ( Spatial Data Option) фактически вводит тип данных “пространственная точка” и операции над ним в СУБД, позволяя хранить соответствующие данные в таблицах оптимальным образом и на порядок (а порой и на два порядка) ускорять выполнение запросов, содержащих сравнения по метрике (например, “все дома, находящиеся в радиусе 1 км от заданной точки” или “все замеры, в которых комбинированный показатель температура-давление выходит за заданный предел относительно оптимума”).
Что касается видеоданных, то соответствующая им опция - Video Option - единственная, “живущая самостоятельной жизнью” по отношению к серверу РСУБД (но не к БД!). Более того, рекомендуется конфигурация, в которой Video Server запускается на отдельном компьютере от сервера БД. Связано это с тем, что воспроизведение видеофрагментов в реальном времени (особенно по нескольким каналам) - что как раз и обеспечивает Video Server - трудно совместимо на современных массово производимых компьютерах с функционированием сервера СУБД из-за чисто аппаратных ограничений. Тем не менее приложение, работающее с Video Server, может осуществлять поиск видеофрагментов по описательным атрибутам и воспроизведение этих фрагментов - как единую интегрированную операцию.
Относительно Web Option пожалуй не совсем правильно говорить о функциональных расширениях сервера, поскольку в сущности главная задача опции - обеспечение интерфейса с Web Application Server и соответственно через него с пользователями Intranet/Internet* .
Oracle OLAP Option едва ли можно было рассматривать как интегрированную компоненту сервера Oracle (продукты OLAP работают с собственным - многомерным - представлением данных, хранимым отдельно) до недавнего времени, когда с помощью Access Manager появилась возможность устанавливать динамическую связь многомерного куба OLAP с реляционными данными, стирая тем самым грань между MOLAP и ROLAP (для аналитика, работающего с приложениями OLAP стало совершенно незаметно, работает ли он с предварительно сформированным многомерным кубом или с динамическим многомерным представлением реляционных данных).
