К 25-ЛЕТИЮ ОДНОЙ НОВЕЙШЕЙ КОМПЬЮТЕРНОЙ ТЕХНОЛОГИИ

СУБД Oracle разработан (разработана ?) в 1972 году. С этого времени сменились целые поколения вычислительной техники и программного обеспечения, но в рекламных проспектах данный продукт по-прежнему фигурирует как "новейшая технология" хранения и обработки данных.

Рекламировалось бы все это как "проверенная временем, старая добротная СУБД", и ни у кого не возникло бы никаких сомнений. Но новейшая...

Давайте разберемся не торопясь. Не отыщем ли мы в этой "новейшей" технологии устаревших, а то и архаичных элементов?

Наука и реклама

В рекламе Oracle упоминается о реляционной теории, лежащей в основе этой СУБД. Упоминается ненавязчиво, как бы вскользь, как о само-собой разумеющемся. И подобная ненавязчивость в данном случае производит наилучший эффект. Ведь научная теория - это не шумные памперсы и сниккерсы. Это сразу вызывает доверие.

Правда мало кто с ней разбирался. Особенно из тех простых ребят - начальников информационных отделов и руководителей корпораций, для которых предназначена реклама. Именно на таких людей ссылка на научность действует особенно эффективно: они страшно боятся завернуть куда-нибудь не туда. А наука, как известно, гарантирует.

Не буду раскладывать по полочкам все аспекты этой теории: их очень много. Поделюсь лишь общим впечатлением.

Существует некий стереотип восприятия научных текстов. От них средний человек интуитивно ожидает закрученных, не совсем ясных оборотов речи и специфической, как бы научной терминологии. Если он это получает, доверие к тексту в его глазах возрастает. И наоборот.

Если вы просто напишите: "Масло - масляное" - вы не ученый. Если же вместо этого вы ввернете фразу: "Произвольные сочетания жироподобных веществ проявляют свойства, характерные для подавляющего большинства жировых компонентов", - вы на полпути в большую науку.

Поверхностное знакомство с реляционной теорией оставляет впечатление, что ее авторы неплохо поработали в этом плане. Тут и ссылки на математическую теорию множеств, и специфическая терминология в виде "кортежей", "отношений", "свойств", "объектов", "сущностей" и "экземпляров сущностей (?!)". И непростые обороты речи, призванные убедить читателя в изощренной научной эрудиции авторов.

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

Разгадка этого кроссворда наполняет сердца особо пытливых читателей гордостью: "Гляди-ка, какая сложная теория, а мы все поняли: оказывается масло то - масляное!" Менее пытливые, а их большинство, согласны довольствоватся выводами. Но легко ли их отыскать среди 333 (!) положений?

Вообще-то сначала их было 12. Это потом стало 333. Настоящая научная теория. Ньютон позавидует.

Но вот что бросается в глаза: очень уж числа замечательные. Оба числа: и 12, и 333. Кругленькие такие числа, ровненькие.

А как легко они запоминаются! Судите сами: двенадцать месяцев в году, двенадцать святых апостолов, да просто дюжина. Совершенно магическое число 12 - его невозможно не запомнить.

Второе число тоже сразу врезается в память: три по три, трижды три. Его можно перевернуть вверх ногами, все равно останется 333. Его можно читать задом наперед и через зеркало - все равно будет 333! Преклоним головы перед научным подвигом авторов. Сколько бессонных ночей нужно сосать палец, чтобы в точности подогнать свою теорию под эту нехилую цифру!

В настоящей науке, однако, не число законов важно, а их качество: если уж есть закон, то его никак невозможно нарушить. Во всяком случае безнаказанно. Ибо это - закон Природы. Не соласны? Тогда нарушьте, пожалуйста, первый закон Ньютона. Или теорему Пифагора.

Правда, таблицу умножения нарушить можно. Но, опять же, c оглядкой: за это в школе двойки ставят. Зато миллионы пользователей, работая на FoxPro, ежесекундно нарушают что-то из 333 реляционных положений. И, главное, безнаказанно. Непонятно, как им это удается?

Эй, субъект, подай объект !

Самый интересный возраст у вступающего в жизнь человека - от двух до пяти. Кроме всего прочего это еще и возраст величайших открытий. Одно из них - подмена понятий. Представьте, как интересно, как по-новому будет звучать фраза: "Эй, жена, подай расческу, у меня блоха завелась", если назвать жену субъектом, расческу - объектом, а блоху - идеей. Казалось бы, простая замена одних слов на другие, - а каков эффект!

С годами мы начинаем осознавать, что насекомое как-то плохо ассоциируется с идеей, а кое-кого не вполне безопасно называть субъектом. Но что делать, если шеф требует рекламную статью в научном стиле к завтрашнему утру, а новых и действительно полезных мыслей катастрофически не хватает ? Тут поневоле вспомнишь свои детские лингвистические забавы с подменой понятий.

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

Ведь главная цель научно-рекламных изданий - так заморочить голову простым ребятам, так запудрить им мозги и навешать лапши, чтобы выглядеть в их глазах серьезным ученым человеком. Главное, убедить их КУПИТЬ товар.

О, великий Карнеги! Все как Ты учил. Люди предпочитают клубнику со сливками, рыбы - червяков, а администраторы хорошо идут на псевдонаучную галиматью.

Язык SQL как воплощение реляционной теории

В качестве средства общения с СУБД Oracle использует язык SQL (Structured Query Language) - язык структурированных запросов. Его можно назвать практическим воплощением реляционной теории баз данных. Он позволяет корректно делать с данными то, что согласуется с теорией и исключает действия, которые могли бы привести к неправильному с точки зрения теории результату.

Так может быть и не стоит пытаться делать того, чего не позволяет реляционная теория, а стало быть и SQL?

Например, устанавливать двойные связи между таблицами. Допустим, вы проектируете систему учета перемещений товаров между подразделениями. Для этого создаете две таблицы: картотеку подразделений (Код подразделения, Наименование) и таблицу учета перемещений (Код подразделения-источника, Код подразделения-приемника, Наименование товара, Дата, Количество, Сумма, ...).

Совершенно очевидно, что таблица учета перемещений по условию задания связана с картотекой подразделений ДВУМЯ полями. Но попробуйте выразить эти связи с помощью языка SQL: - не получится. И таких очевидных, жизненных примеров - пруд пруди. Вот почему так ценятся знатоки "новейших" СУБД: они умудряются решать жизненно важные задачи неприспособленными средствами!

Можно долго и безуспешно спорить, кто виноват: то ли реляционная теория не охватывает самых очевидных жизненных реалий, то ли язык SQL не реализует всех аспектов теории (а их 333!), то ли разработчики СУБД не смогли подобрать и предоставить пользователям эффективные средства доступа. Но факт остается фактом: самые очевидные и естественные методы доступа к данным оказались недоступны пользователям "новейших" SQL серверов.

Прежде всего отсутствуют методы прямого доступа, реализованные в более современных (по времени создания и изначальной ориентации на персональные компьютеры) "настольных" СУБД (dBase, Clarion, Clipper, FoxPro). Эти методы оперируют понятием текущей строки и обеспечивают мгновенный доступ к следующей и предыдущей строкам таблицы в любой доступной сортировке. Именно методами прямого доступа обеспечивается постраничный просмотр на экране содержимого интересующей нас таблицы (листование). Именно метод прямого доступа создает основу современного экранного интерфейса.

Но в момент создания СУБД Oracle не существовало понятия экранного интерфейса, как не просматривались и технические средства для его реализации. А при ориентации на телетайпный стиль реализовать режим прямого доступа было вроде как и ни к чему. Ведь направляя телетайпный запрос к СУБД, мы, как правило, ожидаем получить сводный результат, то есть отчет, оформленный в виде таблицы с колонками и итогами, а не отдельную строку одной из таблиц. Вот почему в 1970 году в синтаксис языка SQL не были заложены команды прямого доступа к данным. А услужливая реляционная теория тут же "научно" подтвердила необходимость этого ограничения.

Как же выходят из положения наряженные в цветные графические оболочки "новейшие" SQL ориентированные системы обработки данных? В это трудно поверить, но никак они не выходят. Чтобы отобразить на экране 20 строк, они запрашивают у СУБД все строки, удовлетворяющие некоему условию. Может быть 100, а может быть 100 тысяч, включая, разумеется, и нужные 20. Для буферизации и хранения этой прорвы информации требуется оперативная и дисковая память. Чем больше - тем лучше. Вот почему "новейшие" технологии так прожорливы.

Прямой доступ: а это не опасно?

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

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

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

Представьте себе, что вы вычитали первую строку, затем ваш коллега с соседней рабочей станции модифицировал обе строки и после этого вы читаете вторую строку. Сложение сумм в первой и второй строках на вашем экране покажет вам, что сумма сделки изменилась. Но ведь этого НИКОГДА не было в реальной базе!

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

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

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

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

Как же поступают программисты, чтобы их программа не продала два билета на одно место? И те, кто знает реляционную теорию, и те кто ее не знает, и те, кто использует Oracle, и те, кто пишет программы на Clipper, посупают совершенно одинаково: они блокируют на короткое время модификацию базы со стороны остальных пользователей, убеждаются в наличии свободных мест, выписывают билеты (либо отвечают отказом), после чего снимают блокировку. И никаких математических теорий. Никаких множеств и пересечений, никаких объектов с их таинственными свойствами, никаких сущностей и экземпляров оных. Все решается на уровне здравого смысла.

SQL: напрасные надежды

С исторической точки зрения SQL представляет собой человеко- машинный язык, который разрабатывался для непосредственного общения человека с компьютером. Замысливалось, что каждый бухгалтер, финансист, менеджер, имея у себя в оффисе простой терминал, мог сам связаться с СУБД Oracle и, задавая последовательно ряд предложений на языке SQL, выяснить для себя все интересующие его вопросы.

В 70-е годы на интеллектуальные человеко-машинные системы общения возлагались достаточно большие надежды. Разрабатывались высокоуровневые языки обработки информации, такие, как Prolog, Lisp и даже проектировались экзотические процессоры для их поддержки. В течение нескольких лет язык SQL преподавался в американских ВУЗах.

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

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

Эта же программа-посредник получает ответы от СУБД в виде грубо оформленных текстовых таблиц и представляет их на экране в более привлекательном для человека виде. Язык SQL, специально спроектированный под человека, изначально предназначенный для непосредственного (то есть без посредников) общения человека с компьютером, вынужденно используется теперь для общения между собой двух программ-посредников: СУБД и пользовательского приложения.

Но программам вовсе не обязательно общаться между собой на человекоориентированном языке. Им гораздо легче общаться на языке машинных структур. Гораздо легче. Ибо со стороны пользовательской программы отпадает необходимость кодировать действия оператора на чуждом для машины языке SQL, а со стороны СУБД отпадает необходимость транслировать эти запросы в пригодный для исполнения вид. Вот и превратился едва ли не главный элемент "новейшей" СУБД, - язык запросов SQL, - в ненужную, бесполезную шестеренку, в лишнее передаточное звено, от которого нет никакой пользы, кроме дополнительного трения всего механизма.

Беззаветные поклонники Oracle тут же возразят, что язык SQL играет кроме всего прочего роль стандарта, что под этот стандарт написаны многие "новейшие" программы, что этот стандарт обеспечивает переносимость, а вышеизложенное - это мелочи, на которые не стоит обращать внимание.

Но если посмотреть непредвзято, то становится видно, что SQL как стандарт - это лишь благое пожелание. Сколько SQL-ориентированных СУБД, столько и диалектов языка SQL. Настоящее вавилонское столпотворение.

А насчет переносимости... Попробуйте перенести сколь нибудь развитую прикладную систему с Informix на Oracle или наоборот. Попробуйте их просто извлечь в чистом виде из родного окружения... Если бы это было действительно просто, не нужны были бы никакие двойные посредники в виде программ типа ODBC.

SQL: взаимодействие с программным окружением

Строго говоря, прикладные системы и не пишутся на чистом SQL. Для этих целей каждая фирма разрабатывает свои собственные языки программирования и свои ни с чем не совместимые системы визуального проектирования. Для Microsoft - это Visual Basic и Visual C в сочетании с Access, для Oracle - это PL-SQL и Designer-2000. Имеется и масса прграммных продуктов иных фирм: Delphy (Borland), Power Builder (Sybase), и т. д. И все они имеют свои собственные языки внутреннего программирования. Язык SQL используется лишь как средство общения с СУБД.

Программисту при этом приходится использовать сразу два языка: внутренний, процедурно ориентированный язык обработки и визуализации данных, например Pascal или Visual C и декларативный, непроцедурный язык запрсов SQL.

Это все равно, что смешать кислое с пресным. Попробуйте, например, передать параметры процедуры языка Pro/C фирмы Oracle (язык C с SQL препроцессором) в SQL запрос типа "Select". Действие для программиста архинужное. Собственно, на этом строится все современное программирование: исходные данные (параметры) меняются, а программа остается неизменной.

Но с декларативным языком SQL ничего у вас не получится. Здесь все наоборот: если хочешь изменить результат - измени программу (запрос). Это значит, что нужно умудриться программным путем "влезть" в исходный текст запроса и изменить некоторые слова. Но реально даже эти сложные программные манипуляции не дадут результата.

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

SQL: экономичность и удобство

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

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

Хотя и без этой оговорки трудно признать SQL простым и интуитивно понятным языком. Если вы программируете на Clipper или Foxpro, если вы знакомы с языком C или Pascal, если вы владеете хотя бы языком Basic, вспомните, трудно ли вам получить текущую дату или время?

Десятилетия практики программирования приучили нас к мысли, что получение даты не может, не должно быть сложной операцией. В каждом языке есть переменная или процедура с очевидным именем date() (или что-то в этом роде), которая отвечает на данный вопрос. Просто напишите ее имя в нужном месте программы, и все!

Только не в SQL. Вот что нужно знать и уметь, чтобы получить текущую дату с помощью этого языка. Привожу соответствующую выдержку из документации фирмы Oracle.

"... SYSDATE - это псевдостолбец, содержащий текущую дату и время. Вы можете использовать SYSDATE как любой другой столбец. Например, можно выдать текущую дату путем указания поля SYSDATE в предложении SELECT. Удобно для такого запроса взять вспомогательную таблицу с именем DUAL. Эта таблица принадлежит пользователю с именем SYS (системному администратору) и доступна всем пользователям на чтение. Она содержит только один столбец, DUMMY, и одну строку со значением "X". Таблица DUAL удобна для задания в запросах, когда вы хотите получить единичное значение, не связанное с таблицами БД, например значение константы, псевдостолбца или арифметического выражения, не содержащего имен столбцов таблиц БД.

Чтобы получить текущую дату, выполните:

 SELECT SYSDATE
 FROM SYS.DUAL ;

Вы также можете выбрать столбец SYSDATE из таблицы EMP, но в этом случае вы получите 14 одинаковых значений - по одному в каждой строке этой таблицы. Именно поэтому в подобных случаях предпочтительнее использовать таблицу DUAL.

Как говориться, надо бы проще, да некуда. Ну кто может самостоятельно догадаться, или просто предположить, что дату следует извлекать из некоей вспомогательной таблицы с именем DUAL, содержащей один столбец DUMMY и одну строку со значением "X" ?

Я - пасс. А вам не слабо?

Встроенная кластерная подсистема

В момент проектирования СУБД Oracle даже наиболее развитые операционные системы, такие как DOS, OS фирмы IBM имели недостаточно совершенную файловую подсистему. Программистам приходилось самим заботиться о размещении на диске отдельных участков файла, страховаться от переполнения дисковой памяти, от перекрытия ее участков и выполнять массу иных системных и организационных операций. Oracle избавил своих пользователей от этих нудных забот. Информационные файлы СУБД имеют внутреннюю кластерную организацию, а ядро СУБД полностью взяло на себя размещение информации, избавив программистов от необходимости знать и учитывать в своих программах физическую организацию данных на магнитном носителе. Это был большой, можно сказать, революционный шаг вперед.

Но это было в 1972 году. С тех далеких времен многое изменилось. Разработчики операционных систем быстро сориентировались и все последующие ОС стали оснащать исключительно гибкими и совершенными файловыми подсистемами, построенными по кластерному принципу. Уже через год, в 1973 году появилась одна из первых удачных кластерных операционных систем - ОС UNIX. Именно она в настоящее время доминирует в качестве системной платформы для СУБД Oracle.

Сейчас нет нужды создавать и встраивать в СУБД собственные системы размещения блоков данных на машинных носителях, - это бесспорная прерогатива операционных систем. И, отдавая дань уважения первопроходцам, все же следует признать, что оставшаяся с тех давних пор встроенная в СУБД Oracle собственная кластерная система в настоящее время смахивает на пятое колесо у телеги.

Один на всех и все на одного

При работе с СУБД Oracle предполагается, что все таблицы, даже явно временные, локальные, нужные только конкретному программисту для решения конкретной задачи в конкретный момент времени и не нужные более никому и никогда, создаются, хранятся и обрабатываются на сервере. Данная черта характеризует программное обеспечение как архаичное.

Дело в том, что во времена рождения Oracle (1972 г.) локальных средств обработки данных в виде персональных компьютеров не было и не предвиделось. Из технических средств общения с компьютером существовали телетайпы, в лучшем случае электронные терминалы. Они лишь отображали результаты обработки, но сами хранить и обрабатывать данные не могли. Возможностью обработки данных обладал центральный компьютер - по современной терминологии сервер, на котором было установлено программное обеспечение ядра Oracle, то есть СУБД. Разработчики совершенно логично для своего времени возложили обработку всех данных на сервер и СУБД, ибо в те далекие годы просто не существовало другой возможности.

Но сейчас такая возможность есть. И с современной точки зрения непонятно, почему всю работу по хранению и доступу к данным следует поручать СУБД, расходуя при этом разделяемые, общие, а потому дефицитные ресурсы процессора и оперативной памяти сервера, в то время как громадные ресурсы современной рабочей станции будут простаивать. Ресурсы, сравнимые с сервером, между прочим...

Заключение

В рекламе любого своего продукта всегда пиши - новейший. И не смущайся, если кто-то разглядит в нем пятое колесо или лишние шестеренки, да еще укажет на древние истоки их происхождения. С умным видом поясни, что де диалектическая спираль - это вам не хвост собачий, это понимать надо. Она делает круговые обороты и теперь новое - это старое, а старое - это новейшее! Все понятно? Нет? Проваливай...