Часть 1. Теория и практика реализации идеи СУБД
Глава 1. Введение
Пятнадцать лет назад, ранним утром 14 августа 1968 года, группа взволнованных людей на заводе Rockwell в Дауни, штат Калифорния, наблюдали, как слова «IMS ready» были напечатаны мастер-терминалом 2740. Оператор ввел команду «start region». IMS/360 была готова впервые пойти в эксплуатацию. Практически мгновенно с производственного этажа начал приходить поток транзакций, так как рабочие начали вводить запросы и заносить информацию о заказах для проекта Аполлон. Спустя два часа, я повернулся к Хью Хоскинсу и сказал, что система будет работать стабильно, и мы можем, наконец, позавтракать. Если я правильно помню, Хью отправил меня одного. Он хотел остаться и понаблюдать подольше.
Эти воспоминания о том, как начиналась история IMS, основаны, по большей части, на материале, который я подготовил для презентации, которую провел в IBM Санта Тереза в мае 1982. В тот момент у меня было ощущение, что меня пригласили в Ватикан читать лекцию о Христианстве. И если IBM Санта Тереза можно назвать Римом IMS, то тогда в 1968 я был в ее Вифлееме, на заводе компании Rockwell International. Там я принимал участие в ранних стадиях разработки системы и могу гордиться тем, что управлял ее первой эксплуатационной установкой.
С тех самых пор моя жизнь была тесно связана с IMS, управлением ее программной и аппаратной частью, сетевой связью и распределенной обработкой, разработкой приложений и администрированием базы данных. В течение следующих 15 лет IBM развивал и продавал IMS, а я работал над тем, чтобы она соответствовала требованиям клиентов. Это означало работу в трех крупнейших компаниях, использующих систему, консультирование пяти других серьезных заказчиков, членство в нескольких организациях пользователей IMS, а также проведение презентаций в ряде технических и специализированных учебных заведений.
Широко известно, что IMS представляет собой незапланированный результат связи IBM и Rockwell International. В 1961 году Rockwell был выбран в качестве исполнителя заказа Аполлон, считающегося крупнейшим инженерным проектом за всю историю человечества, создавшим необходимость автоматизированного контроля используемых данных.
Отдельным требованием была возможность автоматизированного создания списка деталей, необходимых для сборки сложного конечного продукта, так как в космическом корабле Аполлон было около 2 миллионов компонентов.
Глава 2. История ранних систем
В тот момент не существовало технологий, удовлетворявших таким требованиям, поэтому была создана система, основанная на магнитных лентах, включавшая сложный поисковый механизм, использующий накопители на магнитных сердечниках для непрямой адресации. Система была работоспособна, но крайне неэффективна. Одни файл занимал 18 катушек ленты, при этом доступ к отдельным его частям запрашивался крайне редко. Около 60% файла представляли собой избыточное повторение порядковых номеров деталей, частей, следовавших затем при сборке, и т.д. Время доступа было крайне велико, к тому же, пакетная обработка данных означала, что файл практически никогда не был актуальным.
Было решено, что следующим шагом будет создание системы прямого доступа к файлам. Новый метод должен был быть легким для понимания программистами с минимальным опытом работы с прямым доступом. Он так же должен был быть приспособлен для представления иерархических структур файлов, так как при этом можно будет использовать существующие механизмы файловой системы для поддержания актуальности. В то же время, такой метод должен был слабо зависеть от аппаратной архитектуры и языков программирования.
Написанное в результате программное обеспечение получило название GUAM (Generalized Update Access method) и стало предшественником языка работы с базами данных Data Language One (DL/1). GUAM использовался для внедрения DOES (Disk-Oriented Engineering System) на заводе 1965 года, работавшей на платформах IBM 7010 и 1301.
Параллельно с DOES, Rockwell разработал два приложения для проекта Аполлон для дистанционной обработки: программу подготовки инженерной документации и систему управления логистикой и хранением (EDICT и LIMS).
EDICT был разработан для отслеживания чертежей и инженерных спецификаций. Работа над Аполлоном велась по всему миру, так что запросы к этим документам могли поступать отовсюду. EDICT работал на процессоре IBM 1460, использовал систему синтезации голоса (7770 Audio Response) и дисковые устройства хранения 1301 и 1311. Несколько устройств контроля 1026 обрабатывали ввод с 20 терминалов 1050. LIMS использовала практически такую же систему, за исключением устройства синтезации голоса и позволяла обновлять и запрашивать в режиме реального времени состояние важных компонент проекта Аполлон.
Монитор удаленной обработки, поддерживавший EDICT и LIMS, известный как RATS (Remote Access Terminal System), разрабатывался совместно Rockwell и IBM в 1964-1965 годах. Эта универсальная система опрашивала терминалы, расшифровывала сообщения и вызывала нужные программы. Прерывания не поддерживались, сообщения обрабатывались по одному. Таким образом, RATS был предшественником IMS DC (прим.ред.: монитор транзакций IMS TM или, если по современному, runtime, сервер приложений).
В результате появился новый тип избыточности: половина данных в записи DOES совпадала с записью EDICT, а 99% записей EDICT существовали в базе DOES. Тем не менее, слияние двух файлов потребовало бы работы обеих систем. Такова была ситуация, когда свет увиделаSystem/360. Было решено использовать возможности новой системы для разработки программного обеспечения, обладающего всеми сильными сторонами GUAM и RATS, при этом имеющего возможность параллельной обработки сообщений, внешнего определения структуры файла, защиты конфиденциальных данных, улучшенного поиска, чтения и записи, работы с несколькими устройствами и т.д. Таким образом были созданы предпосылки для IMS.
Глава 3. Совместная работа IBM и Rockwell
Доктор Роберт Р. Браун, ответственный за обработку данных в Rockwell, организовал совместный проект с IBM для работы над новым продуктом, получившем сначала название ICS (Information Control System). Позже, проект был переименован в IMS, так как IBM обнаружил, что права на название ICS уже заняты. Доктор Ури Берман из IBM и Боб Патрик, старший консультант, разработали большую часть оригинальной архитектуры и спецификаций. Эд Моррис из IBM был назначен главой проекта. Пит Хилл из IBM и Пит Нордайк из Rockwell совместно были назначены руководителями по разработке. Хилл принял управление проектом 1 января 1968 и вел его в течение всей разработки. Разработчиками ключевых компонент были: DL/I – Ден Гилберт, Пит Нордайк, Мэри Николс (Rockwell), Ури Берман, Сид Корнелис (IBM); OSAM – Ли Мидор (Rockwell); планировщик — Дон Лундберг, Томас Ворк (IBM); системные макросы — Крейг Франклин (Rockwell); удаленная обработка — Лес Премо (Rockwell), Карл Чемберлен, Говард Келлер (IBM); поддержка синтезации голоса — Бил Эрвин (IBM); документация — Джон Калверт (IBM).
Ядро системы проектировалось на протяжении 1966-1967 годов, разработка и отладка заняли 1967-1968 года и велись на машине S360/50 с 512 Кб оперативной памяти. Работа велась в Дауни, штат Калифорния, на территории космического завода Rockwell. Параллельно с разработкой IMS, Rockwell производил бета-тестирование OS/MVT, чтобы иметь операционною систему с поддержкой нескольких контрольных регионов, что было одним из требований IMS DC. В течение 1966-1967 годов я помогал разрабатывать управление, процедуры и операционную среду, необходимую для запуска OS/360 и миграции более сотни приложений с платформы 7010 на S/360.
Моя связь с IMS началась весной 1967 года. Боб Браун должен был выступить с презентацией на конференции Международной Федерации Обществ по Обработке Информации (IFIPS) в Риме, посвященной ICS, и попросил меня подготовить речь. Результатом моего исследования стал документ, в котором впервые был представлен всесторонний обзор целей, философии, архитектуры и структурной организации IMS. Боб был доволен, его выступление имело большой успех. Через некоторое время после возвращения из Рима, доктор Браун перевел меня в проект.
Мое официальное задание было необычным: я должен был работать над интерфейсом IMS – функционированием терминалов, руководствами пользователей, их обучением и тренировкой. Помимо этого, у меня было второе, неявное задание: доктор Браун был крайне встревожен отставанием проекта IMS от запланированных сроков и боялся выхода его из-под контроля. Приближались пилотируемые полеты Аполлона, до высадки на Луну оставалось всего полтора года. Оказалось, что моим настоящим заданием было определить состояние проекта и рекомендовать действия, необходимые для эксплуатационного внедрения IMS.
Однако выводы, которые я сообщил Брауну, обнадеживающими не были. Никто на заводе не придерживался единого плана внедрения, команда Rockwell не докладывала своему руководству, важная информация о состоянии проекта ему не раскрывалась. Проект, как и боялся Браун, вышел из-под контроля. Члены команды не чувствовали ограничений по времени, да и принадлежности к нечто большему – проекту Аполлон. Много усилий тратилось на разработку дополнений к IMS, например, на язык сетевых запросов, которые не требовались проекту Аполлон, но велись за счет его бюджета. Команда IBM занималась улучшением функций, первая версия которых была закончена за месяц до этого, и подходила проекту Аполлон без дальнейших улучшений. Я не понимал причин возникновения подобной ситуации до разделения проектов в 1968.
На тот момент не существовало единой методики тестирования IMS, и в случае сбоев никто не предпринимал действий по устранению их причин. Проектная команда смотрела с высока на разработчиков приложений, которые пытались настроить три основные системы для работы с IMS. Проект поглощал ресурсы при этом не переставал проваливать тесты и уничтожать базы данных. Разработчики приложений, которым нужна была помощь, ее не получали.
Глава 4. Необходимость радикальных действий
Браун хотел узнать, какие действия, по моему мнению, стоило бы предпринять. Мои рекомендации были радикальными. Так как интересы наших компаний разошлись, совместная работа с IBM над проектом должна была быть остановлена. IBM нужен был продаваемый продукт, а Rockwell – полет на Луну. Работа над архитектурой IMS должна была быть заморожена, а усилия Rockwell - сконцентрированы на работоспособности системы, управлении проектом, тестировании и поддержке приложений. Некоторым ведущим инженерам проекта, в свою очередь, стоило изменить свое отношение.
Доктор Браун спросил меня, когда, в таком случае, IMS будет готова к эксплуатации. По моим представлениям, это должно было произойти 15 июля 1968, за год до предполагаемой высадки на Луну.
Я уверен, что мои советы не были главной причиной того, что произошло дальше, так как многие наблюдали за проектом, да и у самого доктора Брауна были подобные подозрения. Иначе он не отправил бы меня наблюдать за процессом. Как бы то ни было, совместный проект был остановлен, IBM перенес свои разработки в Лос-Анджелес, а работы над архитектурой IMS были заморожены. Команде Rockwell было дано задание сконцентрироваться на внедрении системы.
Я начал тестировать систему, команду за командой, модуль за модулем, транзакцию за транзакцией, функцию за функцией, и каждый раз, когда я сталкивался с проблемой, я присваивал ей порядковый номер. Мной был организован комитет по решению таких проблем. Встречался комитет почти ежедневно для классификации неполадок, определения приоритетов, назначения ответственных за решение. IBM был членом комитета и получал копии документов по каждой проблеме. При работе мы были в постоянном телефонном контакте с командой IBM в Лос-Анджелесе.
Я разработал план по внедрению, чтобы можно было быстрее отслеживать прогресс. Совместно с Джо Энн Стортсем я собрал аудиторию с мастер-терминалами, где обучал первых операторов IMS, а так же разработал первое руководство для них. В углу машинного зала, я расставил передатчики, модемы, наборные диски и коммутационные панели так, что получился центр сетевого контроля со вторым мастер-терминалом.
В марте 1968 стали видны изменения, но неожиданно глава разработки Rockwell и большинство участников проекта Rockwell IMS массово уволились из компании. Доктор Браун спросил, стоит ли закрывать проект и сообщать руководителям Аполлона плохие новости. Я считал, что не стоит, так как костяк хороших, преданных специалистов оставался, и они делали задачу выполнимой. Браун попросил уточнить сроки, и я перенес дату на месяц вперед, на 15 августа 1968. Из офиса доктора Брауна я вышел главой проекта IMS. За следующие 4 месяца мы устранили более 200 системных неполадок и полностью переписали средство восстановления базы данных. В середине августа IMS вышла в эксплуатацию на S/360 65 с 512 Кб оперативной памяти и с тех пор не прерывала свою работу.
Джин Брольт и Хэнк Эпштейн, при поддержке Эла Барнетта, Боба Уитакера и Дика Даффи управляли первой группой приложений IMS. Группой разработчиков управляли Джим Лайтфут и Эд Дункан. Ключевыми программистами были Род Шаханян, Дэн Уэллер, Дэйв Джонсон, Кэрол Рорк, Джордж Фут и Рой Грей. Внедрение было пошаговым, с постепенным увеличением сложности.
Всего в 1968-1969 гг. было внедрено 8 приложений, первым из которых в августе 1968 года был POLAR (система отчетности о местонахождении промышленных заказов), использовавший несложные базы данных, терминалы 2740 и простые транзакции. Для статистики отмечу, что к 1969 году система использовала 130 терминалов и 110 шин связи, занимала 4 системы хранения 2314 для 30 баз данных, распределенных по 32 блокам дисков, генерировала от 17 000 до 20 000 транзакций в день и поддерживала 260 видов транзакций, работала 20 часов в сутки со средним временем ответа 2-5 секунд.
Часть 2. Технические особенности и архитектура IMS
Глава 5. Особенности архитектуры IMS
Из маркетинговых соображений, компания IBM настояла на том, чтобы IMS работала на машинах с 256 Кб оперативной памяти. Это условие стало определяющим в архитектуре IMS, и повлияло на все: от выбора реализуемых функций до размеров модулей, алгоритмов обработки очередей, ограничений блока управления и техник программирования. Если в современном мире, где объемы оперативной памяти исчисляются гигабайтами (прим.ред.: напоминаю, речь идет о 80-90х годах), вам это кажется странным, то учтите, что в то время, когда велась разработка IMS, использовалась дорогая память на магнитных сердечниках. Технологии виртуализации памяти еще не было, и 256 Кб было весьма большим объемом.
IMS разрабатывалась как расширение, а не часть операционной системы OS/360. Причиной этого, как мне кажется, было то, что IMS создавалась как программа второго типа (Type II) группой промышленной разработки IBM (Manufacturing Inductry Development group), а OS/360 была программой первого типа (Type I), созданной в «святая святых» IBM – в подразделении обработки данных (Data Processing Division). Взаимодействие с интерфейсом OS/360 было проще организовать, чем сотрудничество двух крупных подразделений внутри IBM. К тому же, ОС была столь же нова и мало испытана, как IMS, и наверняка разработчики считали, что им хватит работы и без внедрения IMS в OS/360. Как бы там ни было, IMS была надстроена над OS, и пребывает там до сих пор, занимаясь своими транзакциями, очередями, сохранениями, восстановлением, прерываниями и граничными событиями.
Почему именно иерархические базы данных были выбраны для DL/I? Я помню споры, которые велись в Rockwell на эту тему. В них участвовали сторонники сетевого подхода, используемого в Bachman и GE, а также метода файловой инверсии, применяемого в некоторых проектах библиотечной автоматизации. Но места на дисках тогда было немного, а требования проекта Аполлон были высоки. Иерархические структуры экономили место на диске, чем и привлекли к себе сторонников. К тому же, Rockwell и Caterpillar требовались приложения по автоматической обработке деталей и материалов, то есть решающие задачи, к которым лучше всего подходит иерархическая архитектура. Наконец ранее упомянутая программа GUAM, которая была предшественницей DL/I, использовала иерархическую модель.
Некоторые участники проекта, включая меня, разделяли мнение, что в основе IMS должен лежать словарь данных, и доступ должен контролироваться единым устройством. К моему глубокому сожалению, это предложение не было принято из-за ограничений по времени и оперативной памяти.
Глава 6. Обеспечение целостности данных
Разработчики сразу договорились, что данные в IMS не должны быть утеряны, испорчены, или раскрыты, а также что система должна быть устойчива к некорректным данным, приложениям, и действиям операторов. Мне кажется, такие требования были необходимы, чтобы соблюсти условия безопасности и целостности в проекте Аполлон. Приведу для примера несколько случаев из жизни.
Автоматический откат прерванных транзакций
При тестировании ранних версий IMS, мы продемонстрировали ситуацию, в которой аварийная остановка IMS или приложения приводила к повреждению данных. В этом случае система требовала восстановление без возврата до перезагрузки. С точки зрения пользователя, ситуация была неприемлемой, но именно так была устроена IMS на тот момент.
Дон Хайд из IBM был обеспокоен такой ситуацией. Он предложил пересмотреть схему перезагрузок и контрольных точек, чтобы реализовать автоматический возврат частично выполненных транзакций и установку для них новых сроков выполнения. Мне показалось, что требуемый объем работ крайне велик, и я поделился своими опасениями. Дон уверил меня, что проблем не возникнет. Как правило, такие утверждения приводили меня в ужас, но я знал, что Дон – человек слова. Все исправления были разработаны им в рекордные сроки, и позволили IMS без проблем пройти регрессионное тестирование, обеспечивая улучшенную целостность. Несмотря на то, что я чуть не запретил их внедрение, я считаю, что именно эти улучшения сыграли главную роль в подготовке IMS к эксплуатации.
Восстановление данных
Тестирование утилит IMS показало, что первая версия алгоритмов восстановления была крайне ненадежной. В ее основе лежало восстановление последней записанной на ленту версии и повтор последовательности транзакций до момента сбоя. Совместно с Мэри Николс, я разработал новый метод восстановления базы данных. Дон Хайд разработал алгоритм хранения обновлений базы до записи на ленту для своего механизма перезагрузки, мы же расширили его код, чтобы включить в него хранение обновлений после логов. Наша технология восстановления осуществляла пакетное слияние ленточной копии базы с последующими обновлениями и возвращала восстановленную, реорганизованную базу. Такой механизм увеличивал надежность восстановления, на порядок уменьшал требуемое для него время, и не требовал IMS быть онлайн. Позже IBM внедрила похожий алгоритм во вторую версию IMS/360.
Контроль качества
Наша техника отслеживания кода приложений оказалась бесценным компонентом системы. Мы разработали широкий набор тестовых приложений, вариантов использования, утилит и наборов данных (прим.ред.: некоторые из этих приложений, например, APOL1, APOL13, до сих пор используются для тестирования некоторых компонент). Как только ошибке удавалось проскочить, мы добавляли в наш арсенал тест, который замечал бы ее. Наша позиция основывалась на постулате, что ничего из того, что передал нам IBM нельзя признать надежным, пока мы это не протестировали. Как только мы находили опасный или нерабочий участок, мы атаковали IBM и требовали от них лучшего тестирования приложений перед релизом.
Сразу хочу пояснить, что я очень уважаю IBM, и как организацию, и как группу необычайно талантливых и преданных своему делу специалистов. Многие работники IBM, с которыми я работал над IMS, стали моими друзьями на всю жизнь. Ни до, ни после моего сотрудничества с разработчиками IMS не встречал я команды столь талантливой и сплоченной. Они были лучшими.
Проблема была в том, что IMS был первым, или одним из первых, крупных программных продуктов, поставляемых IBM. К тому же, IMS требовала от пользователей новых техник ведения бизнеса, и покупатели фактически ставили благополучие своих компаний на надежность и доступность системы IMS DB/DC. Я не верю, что разработчики с самого начала поняли проистекающие из этого требования к качеству продукта. Со временем в IBM была открыта программа контроля качества IMS, унаследовавшая нашу философию и методы, и вскоре IMS стала одним из самых надежных программных продуктов на рынке.
Часть 3. Группы пользователей IMS и пути развития IT
Глава 7. Причины успеха IMS
По моим подсчетам, IMS приносит хорошую выгоду IBM. Если прибавить к этому доход от продажи и аренды сопутствующего ПО, терминалов и контроллеров, модемов и устройств связи, устройств хранения и мейнфреймов, то получится, что IMS – один из самых успешных программных продуктов, и вот почему.
Успех не был очевиден с самого начала, как минимум, некоторым людям. Когда Rockwell обсуждал окончание совместного проекта с IBM, Rockwell отказался ото всех прав на продукт в обмен на:
- Упоминание на внутренней части обложки руководств;
- Отчисление от лицензионных доходов;
- 10 бесплатных руководств для первых трех релизов IMS.
Те, кто работал на Rockwell IMS, считали, что IBM заключил самую выгодную сделку со времен покупки Голландцами Манхеттена. Успеху IMS способствовали несколько важных факторов:
IMS работает. Гибкость и возможности языка DL/I позволяли решить проблемы с базами данных в самых больших и сложных организациях. Поддержка целостности данных так надежна, что эти организации доверили IMS свои главные финансовые, маркетинговые и производственные данные. Архитектура связи IMS достаточно надежна и обладает возможностью для перевода всего предприятия в работу по сети, что обеспечило потенциал роста на будущее.
Совместимость с S/360. Ключевым фактором успеха IMS стала совместимость с S/360 и OS/360.
Вклад SHARE/GUIDE. Проект SHARE/IMS будет более подробно описан дальше, так как я лично принимал в нем участие. При этом я нисколько не хочу уменьшить важность вклада GUIDE.
Управление проектом. Инженерный подход к управлению проектом IMS позволил получить в итоге надежный и технически совершенный продукт.
Привлечение пользователей к разработке. Смешанная среда разработки IMS предполагала открытый и свободный обмен информацией между разработчиками и пользователем, невозможный при разработке продукта за «железными дверями». IMS была построена непосредственно на месте внедрения совместными усилиями конечного пользователя и специалистов из IBM. Она заполнила свою нишу на рынке именно тогда, когда нужны была больше всего.
Поддержка вендором. Поддержка IBM, постоянные улучшения продукта и постоянная совместимость снизу-вверх позволили пользователям относиться к IMS как к долговременному вложению.
Особенности восстановления и поддержки целостности. Целостность данных и всей системы, а так же алгоритм ее восстановления качественно превосходили все аналоги.
Пит Хилл. Харизма, способности как руководителя, энергетика и преданность своему делу этого человека были бесценным вкладом в успех IMS.
В 1969 г. IBM пригласил меня на летнюю конференцию в Бостоне SHARE, для обсуждения возможности организации совместной группы SHARE/GUIDE, состоящей из пользователей бета-версии IMS. Первую встречу спонсировал комитет по базам данных Проекта Управления Данными под председательством Джима Фрая. В результате сформировался подкомитет IMS, руководимый одним из титанов системы – Джоан Хейнонен из TRW. Ее лидерские качества, смелость и уверенное руководство способствовали росту SHARE/IMS из подкомитета, состоящего всего из 6 человек в Бостоне, до современного полноценного подразделения с сотней членов, десятками проектов и собственными комитетами и подкомитетами.
Совместная работа SHARE и GUIDE не принесла ожидаемых результатов, хоть сами эти проекты хотели объединиться, но слияния не произошло. Вместо этого, каждой группе IMS пришлось идти своим путем, а я решил остаться с SHARE/IMS, основателями которого были Джоан Хейнонен, Клиффорд Пасли из Caterpillar Tractor, Дэниэл Брукс из LTV, Ричард Льюис из Первого Национального Банка Чикаго, Рональд МакДауэлл из Chevrolet и я.
Джоан успешно построила весьма необычные отношения с IBM: она убедила компанию подписать документ о неразглашении со всеми участниками, что дало возможность проводить за закрытыми дверями сессии между пользователями бета-версии IMS и разработчиками, которых возглавлял Пит Хилл. Так практика прямого общения между пользователями и разработчиками IMS стала традицией, благодаря чему существуют современные возможности и гибкость IMS (прим. ред. - речь идет о IMS QPP, сессии, где выделенной группе пользователей дают доступ к новой версии системы до официального релиза).
Джоан Хейнонен ввела закрытые сессии в первые три дня конференции SHARE. Открытые встречи, круглые столы и презентации пользователей были запланированы на последующие дни и такая схема принесла свои плоды. Многие решения, примененные потом в IMS/360 Version 2 и IMS/VS, были выработаны на встречах SHARE/IMS и представлены IBM. Много усилий приложил к этому Джерри Крал из Первого национального Банка Чикаго. В настоящий момент, закрытые сессии являются стандартной практикой SHARE и GUIDE.
Однако, идея закрытых сессий пришлась не по нраву многим ветеранам SHARE, которым нравилось бродить по конференциям, не производя ничего полезного. Один раздраженный посетитель, которого Джоан не пустила на одну из закрытых сессий, пожаловался руководству SHARE на то, что подкомитет IMS стал «секретным обществом под руководством дракона, не подпускающего никого». Этот комментарий мгновенно стал притчей во языцех, Джоан стала известна как «женщина-дракон», а символом IMS стал зеленый дракон, охватывающий глобус.
Другим ценным результатом работы SHARE/IMS стало издание листовок IMS со статьями членов проекта, первая из которых была написана Дэном Бруксом. Они рассылались всем сотрудникам проекта. Лью Бетардс из Федерального Резервного Банка Канзас Сити привнес большой вклад тем, что взял на себя работу по изданию и рассылке.
Однако после первого издания, энтузиазм немного увял, последующие несколько изданий были легковесными, и я решил исправить ситуацию. По правде говоря, IMS в том виде, в котором она поставлялась IBM, по-прежнему требовала доработок, которые мы в Rockwell произвели, так что я решил описать их в листовках, чтобы помочь другим пользователям. Статьи охватывали широкий спектр: от устранения неполадок и модификаций кода, до правил эксплуатации, настройки параметров и методик анализа. Результаты были замечательными – Том Шредер из United Technologies представил несколько не менее важных статей, за ним последовали другие пользователи. IMS сдвинулась с мертвой точки. Листовки SHARE/IMS стали необходимыми для любой технической библиотеки IMS. Мне кажется, что без них большинство пользователей перешли бы на другие продукты.
Одним из самых мудрых действий Управляющего Комитета было решение избегать длительного пребывания в должности. Чтобы дать шанс сотрудникам, недавно влившимся в компанию, получить опыт управления SHARE/IMS, его основатели создали «Гериатрический Комитет» и сделали себя его почетными членами. Этот статус разрешал им присутствовать на открытых совещаниях с IBM и при необходимости давать советы, но передавал основное руководство в руки новых талантливых сотрудников, среди которых были Том Шредер из United Technologies, Хью Хоскинс из Rockwell, Гэри Полетт из MacAuto, Кейти Стэнли из John Deere, Боб Охала из Motorola, Джерри Крал и Майк Соулакис из Mellon Bank.
О SHARE/IMS стоит рассказать еще кое-что. Джоан Хейнонен, никогда не сдававшаяся ни перед какими людьми, была вынуждена уйти из информационных технологий из-за болезни спины. Когда ей пришлось уйти из SHARE/IMS, проект возглавил Билл Питфиш из Caterpillar Tractor. Если Джоан состояла из льда и пламени, Билл был человеком эффективного спокойствия. Он принес профессиональное управление в организацию именно в тот момент, когда она в нем нуждалась. Ведь как IMS перестал быть малым продуктом, так и проект SHARE/IMS больше не был малой частью SHARE. Билл формализовал отношения с IBM, так как и продукт, и команда разработчиков, и SHARE/IMS качественно развивались. Он поддерживал эту связь, пока зеленый дракон IMS охватывал глобус, и вскоре SHARE/IMS стал самым большим подразделением организации SHARE.
Глава 8. IMS сегодня
Прим.ред.: материал быть написан в середине 80-х годов
Первоначальными целями IMS было вывести корпоративные данные в сеть, устранить избыточность, обеспечить целостность, точность и актуальность, а так же вовремя предоставить информацию, необходимую для управленческих решений. Такова была идея базы данных, интегрированной в среду предприятия, когда данные считаются таким же корпоративным ресурсом, как наличные, инвентарь или, например, сырье. Если бы меня спросили, сумели ли мы реализовать эту концепцию, и насколько успешной была интеграция базы данных, мне пришлось бы ответить, что не слишком. Большинство компаний внедрили несколько сетевых систем в тех областях, где транзакции были автоматизированы. Такие базы хранят информацию только на уровне данных, и проблема заключается в том, что эти данные не несут большой пользы для управленческих решений, принимаемых на тактическом и стратегическом уровне. Чтобы получить полезную информацию, содержимое таких баз нужно обобщать, агрегировать и комбинировать с данными из других источников, после чего эту информацию нужно сравнивать с предыдущими результатами для выявления тенденций. Она также должна быть экстраполирована и проанализирована на предмет различных изменений в ситуации, а наша современная технология базы недостаточно для этого подходит.
Некоторые компании внедрили тактические сетевые системы второго и третьего уровня для управления департаментами, территориями, конвейерными линиями и т.д., но крайне мало компаний используют базы данных для принятия стратегических управленческих решений, а многие даже нанимают не настоящих администраторов баз данных, а просто техническую службу для реорганизаций, восстановления и установки обновлений. Базы являются просто данными в сети, принадлежащими одному приложению и находящимися под управлением разработчика этого приложения. Немного усилий прикладывается для устранения избыточности, редко ведутся словари данных.
Все администраторы баз данных, администраторы данных, управляющие информационными ресурсами, как бы ни называлась их работа, которых я встречал, вне зависимости от того, использовали ли они IMS или другую СУБД, были расстроены и разочарованы такой ситуацией. Их отделы были недоукомплектованы, недофинансированы и недооценены.
Глава 9. Причины разочарований в роли СУБД на предприятии
Статьи в университетских сборниках, технических изданиях и финансовой прессе изобилуют материалами об интегрированных базах данных, так что у стороннего наблюдателя может сложиться впечатление, что в этом поле идет бурная деятельность. Однако на самом деле полезного происходит мало, и мне кажется, что я знаю в чем причина. С точки зрения управленцев, возможные выгоды ниже предполагаемых затрат, так как большую сумму надо заплатить сразу, а выгоды будут, по большому счету, неосязаемые. Я и другие носители идеи интегрированной базы должны лучше продавать наш продукт и представлять его финансовые выгоды. Менеджеров также пугает огромное время, которое занимает внедрение, так как им хочется иметь детальную информацию здесь и сейчас, а не через пять лет. Идею интегрированной базы тяжело продвигать политически и организационного, потому что внедрение такой базы требует интенсивного взаимодействия с другими компаниями и совместных затрат. Как правило, глава проекта базы данных - новичок в команде управленцев, разговаривающий на непонятном языке и, судя по его словам, планирующий за одну ночь изменить устоявшийся порядок, по которому компания проработала уже несколько лет. Другая проблема происходит из самой технологии, так как существующие методы моделирования и проектирования базы недостаточно проработаны и крайне сложны. Все эти трудности только обостряют чувство разочарования в рядах специалистов по базам данных.
Традиционный взгляд разработчиков приложений не включает переход на новые средства разработки и не позволяет им уйти от сложившейся технологии языка COBOL. Базы данных, компиляторы, обработчики запросов и генераторы отчетов уже готовы, но сообщество слишком медленно их использует. Даже после внедрения новой технологии ведения базы многие приложения продолжают ее использовать просто как сетевое хранилище из-за того, что стандарты приложений несовместимы с базой. Существуют десятки приложений, которые отлично работают, но не поддерживают стандарты имен и форматы записей баз данных, а так же десятки и сотни приложений могут быть приспособлены для работы с базами данных, но ожидают финансирования и усилий программистов. Пока что идея интегрированной базы данных остается мечтой.
Мне кажется, что идея интегрированной базы данных в чистом виде не совместима с идеями современными технологиями, и нас пора перестать убеждать себя в обратном. Однако существует альтернативный подход, который может сработать, это идея так называемой отделенной базы данных, которую, правда, борцы за «чистоту базы данных» назовут ересью.
Глава 10. Идея несвязанной базы данных (decoupled database)
В этой концепции фирма рассматривается не как монолит, а, скорее, как набор отдельных, связанных между собой функций, таких как производство, проектирование, управление финансами, персоналом и т. В теории, каждая из этих функций представляет собой мини-бизнес, а связи между ними прямолинейны, предсказуемы, немногочисленны и легче контролируемы, если нежели внутри функций.
Каждая из подобных функций рассматривается как семейство приложений, имеющих общую базу. Следовательно, может быть представлена база персонала, финансов, выпускаемой продукции и т.п. Планирование бизнеса и информационное моделирование теперь происходит на более высоком уровне в соответствии со стратегией и потребностями компании. Отдельные информационные модели могут быть соединены вместе, позволяя компании временно перейти к схеме интегрированной базы данных.
Эта технология позволяет последовательно увеличивать число внедряемых функций, баз данных и приложений, а также обеспечивает изоляцию данных внутри одной области и позволяет хранить данные независимыми блоками. Такая корпоративная модель не выглядит столь же чистой, как классическая, хотя и является более реалистичной. Контроль над избыточностью данных в различных областях требует особого внимания. Например, данные о номере детали могут храниться как в базе продукции, так и в базе проектирования. В итоге за гибкость разработки нужно заплатить небольшую цену в виде дополнительного места для хранения и усложненного контроля целостности. Количество логических связей между семействами приложений должно быть минимальным и реализовываться на уровне вызовов СУБД, а не в физических связях DL/I.
Закупать следует не отдельные приложения, а семейства, содержащие предустановленную базу IMS и поставляемые одним вендором (например, MSA или UCC). Но есть одна загвоздка – самые популярные семейства с базой IMS являются переписанными системами пакетной обработки, которое просто используют IMS DC как терминал, а IMS DB как способ доступа к диску. Такие системы плохо подходят для интегрированной базы, поскольку их форматы данных описаны не в базе, а в приложениях, что усложняет доступ к этим данным из других приложений, например, из генератора отчетов, если вендор не прилагает документацию о формате данных.
Связь с неконвертированными файлами должна быть построена как связь с базой данных, с использованием методов доступа GSAM или SHISAM. Так же можно использовать временный модуль симуляции, который будет отслеживать вызовы приложением базы данных, переводить их в запросы к файлу, и возвращать данные так, как делала бы это база. Когда все файлы будут конвертированы, симуляцию можно будет убрать и работать только с базой данных.
Вначале следует внедрять приложения на оперативном уровне. После этого можно извлекать тактическую и стратегическую информацию из оперативных баз данных и предоставлять ее руководству в реляционном или другом доступном для человека формате. Это позволит обрабатывать ее интерактивными запросами, генераторами отчетов или просто отображать на ПК, что будет одной из важных функций информационных центров.
Огромный массив ленточных хранилищ может принести пользу еще до его перевода в базу данных. Конвертируя файлы в VSAM и используя интерфейс IMS, важные файлы с лент могут быть перенесены в простую временную базу, например, через SHISAM, для каждого запуска пакетного задания. Эта несложная технология позволит представить администратора базы данных как героя дня, что в свою очередь приблизит тот час, когда интегрированная база данных станет реальностью. |
