ПЛАНИРОВАНИЕ
РАЗВИТИЯ
АВТОМАТИЗИРОВАННЫХ
СИСТЕМ
ДЖ. МАРТИН

	STRATEGIC
		DATA-PLANNING
METHODOLOGIES
JAMES MARTIN
PRENTICE-HALL, INC
Englewood Cliffs, New Jersey 07632

ДЖ. МАРТИН
ПЛАНИРОВАНИЕ
РАЗВИТИЯ
АВТОМАТИЗИРОВАННЫХ
СИСТЕМ
Перевод с английского С. М. КРУГОВОЙ
Под редакцией В. М. САВИНКОВА
МОСКВА, „ФИНАНСЫ И СТАТИСТИКА", 1984

ББК 32.973
М29
/М&У
м
2405000000—092
010(01)—84
КБ-46-10-83
t	© 1982 by James Martin
© Перевод на русский язык, предисловие, «Финансы и статистика», 1984

ПРЕДИСЛОВИЕ К РУССКОМУ ИЗДАНИЮ
Совершенствование управления производственными объединениями
(предприятиями) и организациями и повышение на этой основе эффек¬
тивности общественного производства наряду с научно-техническим про¬
грессом — непременное условие поступательного развития социалисти¬
ческой экономики. В этом процессе огромная роль всегда принадлежа¬
ла информации — данным, используемым в плановых расчетах и в эко¬
номическом анализе, в бухгалтерском учете и материально-техническом
снабжении, управлении перевозками и т. п.
За последние 15 лет в нашей стране были созданы многочисленные
автоматизированные системы (АС), в которых потоки данных целена¬
правленно распределяются и обрабатываются на ЭВМ. Достижения в
области программирования позволили по-новому организовать данные в
АС: интегрированные информационные базы АС сегодня организованы
на ЭВМ в виде баз данных (БД). Системы управления базами данных
(СУБД), насчитывающие в своем составе сотни тысяч команд, поддер¬
живают целостность и независимость данных, защищают данные от не¬
санкционированного доступа, обеспечивают неизбыточность их в БД, а
также эффективный доступ к ним различных пользователей.
Организация БД, их создание и ведение, особенно в крупных АС,—
процесс сложный, требующий соответствующей квалификации как спе¬
циалистов, непосредственно проектирующих базы данных, так и адми¬
нистративно-управленческого персонала предприятий и учреждений,
обслуживаемых автоматизированными системами с базами данных.
Именно для этой категории читателей в первую очередь предназначена
книга известного американского автора Дж. Мартина «Планирование
развития автоматизированных систем». Переводом ее издательство «Фи¬
нансы и статистика» продолжает серию публикаций, помогающих совет¬
скому читателю познакомиться с зарубежным опытом создания и вне¬
дрения АС с базами данных.
Дж. Мартин — крупный специалист в области вычислительных и
коммуникационных систем, в последние годы возглавляющий фирму по
проектированию баз данных (Database Design Inc.). Им написано око¬
ло 30 книг по системам баз данных, передаче данных и т. п. * Дж. Мар¬
тин — один из первых за рубежом осознал огромное значение информа¬
ционных ресурсов и новой информационной технологии для построения
компьютеризованных предприятий, основывающейся на современных си¬
стемах данных. Планирование информационных ресурсов, которому по¬
священа предлагаемая книга, рассматривается как важнейшая компо¬
нента информационной технологии.
• В нашей стране издан перевод следующих работ Дж. Мартина: «Сети связи и
ЭВМ» (М.: Связь, ч. 1, 1974; ч. 2, 1975), «Системный анализ передачи данных» (М.: Мир,
т. 1, 1975; т. 2, 1975), «Программировав^ для вычислительных систем реального вре¬
мени» (М.: Наука, 1975), «Организация баз данных в вычислительных системах» (М.:
Мир, 1980), «Телесвязь и ЭВМ» (М,: Машиностроение, 1981).

Однако данную книгу не следует расценивать как рецептурный
справочник по планированию АС ‘или БД. Это, скорее, обобщение соб¬
ственного опыта автора книги по организации и проектированию баз
данных в различных системах с применением методики ИБМ.
Почему же вопросы стратегического планирования данных домини¬
руют в книге Дж. Мартина? Прежде всего потому, что внедрение элек¬
тронной обработки данных (ЭОД) с базами данных требует больших
затрат со сроком окупаемости за рубежом 3—4 года. Отсюда неизбеж¬
ны пошаговая разработка больших систем и первоочередное внедрение
систем с быстродостигаемыми наглядными результатами. В связи с этим
необходимы четкое планирование и интеграция данных в базы данных,
обеспечивающие их применение на последующих этапах развития АС.
Затем следует отметить, что типы используемых в АС организаций
данных слабо изменяются. Автор не без оснований утверждает, что на
предприятии типы объектов, включаемых в БД, не меняются за время
существования производства (выпуска определенной номенклатуры из¬
делий). Это означает, что приложения во всех функциональных обла¬
стях (в одной системе насчитывается от 10 до 30 функциональных обла¬
стей со 100—300 объектами в каждой области) нуждаются в детальном
планировании, поскольку анализ объектов-действий может привести к
реорганизации процедур управления, т. е. к возможной реорганизации
предприятия.
И наконец, правильная организация баз данных ускоряет разработ¬
ку приложений. Дж. Мартин вводит четкую классификацию баз дан¬
ных, среды данных и систем, проверенную им на практике. Согласно
этой классификации базы данных (или, более широко, классы данных)
разделены на прикладные, соотнесенные с вычислительными приложе¬
ниями, и предметные, соотнесенные с предметами предприятия или орга¬
низации (например, одна предметная БД продукции на предприятии, а
не различные БД инвентарного учета, поступления заказов, контроля ка¬
чества и т. п.).
Система ЭОД корпорации насчитывает от 20 до 60 предметных баз
данных. А поскоЛьку эти базы могут обслуживать множество приложе¬
ний, именно предметные БД ускоряют разработку приложений. Разде¬
ление данных на предметные БД невозможно без централизованного
планирования сверху вниз.
Именно на изложенных принципах базируется система организаци¬
онного планирования (BSP), разработанная корпорацией ИБМ и уста¬
навливающая необходимое взаимодействие между административно¬
управленческим персоналом компьютеризуемого предприятия (особенно
его первым руководителем) и администратором баз данных. Методика
BSP была предложена корпорацией ИБМ в середине 1970-х годов и
получила широкое признание специалистов.
Наряду с методикой стратегического планирования баз данных в
различных системах в книге затронут ряд других важных вопросов.
В частности, подробно рассмотрена и доведена до методики оценки
движения данных при распределенном и централизованном хранении
проблема распределенных данных.
Хотелось бы обратить внимание читателя и еще на одну цель, кото¬
рую преследовал автор в своей книге. Последовательно излагая методо¬
логию планирования создания компьютеризованного, или «безбумажно¬
го»*, предприятия, Дж Мартин подчеркивал, что системы с видеотер-
* Идея «безбумажной технологии» была впервые выдвинута и разработана ака¬
демиком В. М. Глушковым.
6

миналами и базами данных только дублируют существовавшую ранее
организацию работы. Однако есть все основания полагать, что базы
данных и экраны терминалов делают возможными более совершенные
формы организации работы. Думается, в недалеком будущем «безбу¬
мажное» предприятие будет так же походить на современное, как сегод¬
няшний автомобиль на первые экипажи с двигателем.
Книга Дж. Мартина охватывает широкий круг проблем, связанных
с деятельностью административно-управленческого персонала и админи¬
страторов баз данных при создании автоматизированных систем. Автор
неспроста упоминает о негативных результатах создания первых систем
за рубежом, проекты которых были понятны только разработчикам.
Эти времена, как показано в книге, уходят в прошлое, и сегодня совет¬
ского читателя уже не может удивить главный бухгалтер фирмы, прово¬
дящий нормализацию отношений до 3-й нормальной формы.
Проектирование баз данных АС не может быть успешно осуществ¬
лено без общего планирования «сверху вниз» и детального проектирова¬
ния «снизу вверх». Согласованность двух подходов, в свою очередь, не
может быть достигнута без соответствующей методики, общие контуры
которой представлены в книге Дж. Мартина. Определяющим фактором
этой методики выступает не индивидуальное мастерство администратора
баз данных, а не менее успешные действия большого коллектива специа¬
листов, включая первого руководителя организации, ибо только при их
участии возможно совершенствование управления предприятиями и ор¬
ганизациями на объективной основе анализа функций предприятия и
данных.
Заметное отставание теории АС от практических потребностей раз¬
работчиков, особенно в отношении БД, конечно, не перекрывается по¬
пулярно написанной работой Дж. Мартина. Но то, что книга может
способствовать дальнейшему развитию автоматизированных систем и,
следовательно, совершенствованию управления производственными
объединениями и организациями, не вызывает сомнений. Она, безуслов¬
но, будет полезна широкому кругу проектировщиков АС, администра¬
тивно-управленческому персоналу и научным работникам.
В. М. Савинков

ПРЕДИСЛОВИЕ
В 1970-е годы стала очевидной огромная ценность для корпораций
и других организаций хранящейся в ЭВМ информации. Вместе с тем
стало ясно, что эти информационные ресурсы требуют централизованного
планирования. Для такого планирования нужна формальная и опираю¬
щаяся на применение вычислительной техники методология, примыкаю¬
щая к проектированию баз данных.
Многие сознавали значение планирования информационных ресур¬
сов, но мало кто знал, как приступить к его осуществлению. Некоторые
фирмы-консультанты подчеркивали важность планирования, но не име¬
ли разработанной методологии, которая приводила бы к проектирова¬
нию всех необходимых ресурсов. В настоящей книге описываются мето¬
дологии, уже использованные для достижения этой цели, и обсуждается
опыт их применения.
Эту книгу я писал одновременно с книгой [1], поэтому и читать их
целесообразно вместе, так как знакомство с одной из них облегчит по¬
нимание другой. Однако данную работу можно читать и отдельно.
В тексте цитируются высказывания людей, обладающих различным
опытом работы в этой области. Одни высказывания взяты из записан¬
ных на пленку интервью Джеймса Мартина в фирме Deltak, другие —
из интервью с руководителями и разработчиками баз данных. Некото¬
рые цитаты взяты из памяток корпораций. Цитаты выбирались таким
образом, чтобы со страниц книги прозвучал «голос опыта». В некоторых
случаях — это горький опыт, поэтому имена людей и корпораций не на¬
зываются.
Я хочу поблагодарить сотрудников корпорации DDI (Database
Design Inc. Ann Arbor, Mich.), основателем и председателем которой
я являюсь и которая специализируется в данной области, за ознакомле¬
ние с рукописью и за многочисленные полезные предложения. Особенно
творчески к работе подошли Кен Уинтер и Джон Хоуп.
Хочу выразить также признательность персоналу фирмы Infocom
Australia, в частности Клайву Финкельстайну и Адриану Тидсвеллу, за
предоставленную мне возможность познакомиться с их богатым опытом
в применении стратегического планирования данных.
Джеймс Мартин

НЕОБХОДИМОСТЬ УЧАСТИЯ
РУКОВОДИТЕЛЕЙ ПРЕДПРИЯТИЙ
В ПЛАНИРОВАНИИ
НЕОБХОДИМОСТЬ ПЛАНИРОВАНИЯ
НА ВЫСШЕМ УРОВНЕ
Немыслимо строить большой военный корабль, не имея общего пла¬
на всего корабля. Когда составлен общий план, отдельные группы могут
приступать к работе над деталями.
Информационную технологию организации освоить ненамного проще,
чем построить военный корабль, однако в большинстве организаций это
осуществляется без общего достаточно детализированного плана, кото¬
рый обеспечил бы согласование компонентов.
Главный конструктор корабля, естественно, не может дать деталь¬
ных проектов размещения оружия, электронных или других систем. Та¬
кие проекты должны разрабатываться отдельно различными группами
людей. Но представьте, что получилось бы, если бы группы создавали
свои подсистемы без какой-либо координации сверху.
Мир электронной обработки данных (ЭОД) полон вдохновенных
проектировщиков подсистем, проектировщиков, которые хотят быть
предоставленными самим себе. Их число быстро растет по мере бурного
развития мини-ЭВМ, приобретения опыта конечными пользователями и
широкого распространения программных средств, «дружелюбных» по
отношению к пользователю. Во многих случаях проектировщики выпол¬
няют отличную работу. Однако типы используемых ими данных в значи¬
тельной мере совпадают, и это часто не распознается. Подсистемы долж¬
ны соединяться, что часто невозможно без их преобразований. Преоб¬
разование, когда необходимость в нем становится очевидной, бывает
слишком дорогостоящим, поэтому несовместимые системы продолжают
существовать, что затрудняет или делает невозможным интегрирование
данных, которые требуются руководству.
В конце 1960-х годов появилась идея о создании полностью инте
грированной базы данных (БД) организации. Она оказалась практиче¬
ски недостижимой. Задача построения единой системы базы данных для
организации невероятно сложна и совершенно не по силам для любой
группы проектантов. Даже если такую систему можно было бы спроек¬
тировать, рабочие характеристики машин не позволили бы осуществить
это на деле. Исключение составляют небольшие организации.
В хорошем проекте системы нет излишней усложненности. Инфор¬
мационные системы больших организаций следует собирать из дискрет¬
ных модулей. Каждый модуль должен быть достаточно простым, чтобы
его можно было эффективно спроектировать, чтобы проектирующая
группа полностью его понимала, чтобы стоимость его ведения была низ-
9

кой и для его разработки были применимы современные методы (такие,
как использование в базах данных языков высокого уровня). Эти моду¬
ли должны согласовываться, что окажется невозможным без централи¬
зованного планирования.
Большая часть информации в распределенных системах и в мини¬
ЭВМ используется людьми, находящимися в местах, удаленных от ми¬
ни-ЭВМ (в других частях организаций). Данные одной подсистемы тре¬
буются также другим подсистемам. И все же во многих организациях
проектировщик каждой подсистемы создает свои собственные данные.
Чтобы собрать все данные воедино, организации необходимо пла¬
нирование на высшем уровне и наличие соответствующих средств про¬
ектирования.
СОЧЕТАНИЕ ЦЕНТРАЛИЗОВАННОГО ПЛАНИРОВАНИЯ
И МЕСТНОГО ПРОЕКТИРОВАНИЯ
Планирование баз данных в масштабе организаций (предприятий)
жизненно необходимо, а проектирование интегрированной базы данных
в таком масштабе невыполнимо. Требуются централизованное проекти¬
рование отдельных подсистем при максимальном поощрении инициати¬
вы на местах по созданию таких подсистем и методология планирова¬
ния на высшем уровне ресурсов данных, которыми'эти подсистемы поль¬
зуются — как в построении линейного корабля.
Чтобы построить компьютеризованное предприятие, необходимо
осуществлять централизованное планирование данных и иметь местный
проект систем во многих различных сферах пользователей. Местные про¬
екты по возможности должны развиваться в рамках, установленных
централизованным планированием. Эти рамки должны быть детально
продуманы.
Компьютеризованная методология требуется как для централизо¬
ванного планирования информационных ресурсов, так и для детального
проекта базы данных. Эти две методологии должны быть совместимы¬
ми, чтобы одна «питала» другую. Централизованное планирование мо¬
жет осуществляться с различной степенью детализации. Для начала
может быть представлена приблизительная сводка о необходимых ре¬
сурсах. Чем больше в ней подробностей, тем она полезнее.
НЕПРОТИВОРЕЧИВОСТЬ ИНФОРМАЦИИ
Основная цель централизованного планирования—добиться не¬
противоречивости информации. Противоречивость информации обуслов- '
лена историческим развитием применения ЭВМ, обычно протекающего
без общего планирования. Данные могут быть противоречивыми по сле¬
дующим компонентам:
1.	Определение поля. Различные части организации не выработали
соглашение об определениях и значениях полей.
2.	Структура поля. Одно и то же поле в различных местах имеет
различную структуру (неодинаковую длину, двоичное или десятичное
отображение, различную структуру кода и т. п.).
3.	Структура записи. Записи с одинаковым ключом имеют различ¬
ную структуру в разных местах.
4.	Время обновления. Данные в разных подсистемах могут обраба¬
тываться ежемесячно, еженедельно, ежедневно или в режиме диалога,
в результате чего разные копии данных будут иметь разные значения.
Руководители часто получают противоречивые данные.
Ю

5.	Противоречивость правил обновления. Логика обработки и обнов¬
ления разных копий данных может быть различной.
Опасность появления противоречивых данных возрастает в связи с
тем, что ЭВМ становятся дешевле и получают все большее распростра¬
нение, так что многие подразделения могут иметь свои собственные вы¬
числительные машины. Распределенная обработка и небольшие ЭВМ
конечного пользования резко усиливают необходимость в стратегическом
планировании информационных ресурсов в масштабе предприятия (ор¬
ганизации).
Противоречивые данные в отдельных файлах или системах могут
препятствовать или затруднять интегрирование данных, которое необхо¬
димо для получения информации, требующейся для руководства.
РАЗДЕЛЕННЫЕ ПРОЕКТЫ
Проектировщики подсистемы и даже конечные пользователи часто
считают, что если проект данных спускается им кем-либо другим, то они
лишаются творческой свободы. Однако те вычислительные установки, где
функции базы данных обеспечены хорошим руководством, на практике
продемонстрировали обратное. Проектировщики процедур получают
стабильные структуры данных и средства, с помощью которых они могут
быстро извлекать данные в различных формах. Простота и скорость
создания новых процедур на высокоуровневых языках в системах баз
данных обеспечивают гораздо большую творческую свободу в изобрете¬
нии и изменении процедур. При отсутствии хорошего руководства базой
данных возможность изменить системы все более теряется в проблемах,
связанных с обслуживанием и с несовместимостью данных.
Модели данных, которые являются следствием хорошего админи¬
стрирования данными, служат тем краеугольным камнем, на основании
которого небольшие группы людей, а чаще всего один человек, могут
быстро создавать новые процедуры. Стратегическое планирование дан¬
ных позволяет отдельным проектам развиваться самостоятельно. Каж¬
дый проект может быть в определенной степени логически связанным и
отделенным от других проектов. Эти разделенные проекты могут быть
небольшими и легкими для реализации. Тем не менее они являются ин¬
тегрированными за счет того, что пользуются централизованно опреде¬
ленными данными.
ВАВИЛОНСКАЯ БАШНЯ
Языки и программное обеспечение, предназначенные для создания
экономически оправданных приложений ЭОД, все более совершенству¬
ются, и этот процесс будет продолжаться. Сейчас непроцедурные языки
и другие средства позволяют осуществлять многие приложения без про¬
граммирования в обычном понятии, а в некоторых случаях — силами
. конечных пользователей. Читатель должен представлять себе «компью¬
теризованное» предприятие недалекого будущего, в котором множество
людей создает и налаживает электронные процедуры. В их распоряже¬
нии имеется программное обеспечение, «дружелюбное» по отношению к
пользователям, которое позволяет им выполнять свою работу быстро.
Дешевые ЭВМ находят все большее распространение, и почти на каждом
столе в организациях установлен термйнал. Вопрос к руководителям
предприятия и ЭОД: как вы контролируете такую ситуацию? Важней¬
ший аспект контроля -*- координация используемых данных. Ее отсутст¬
вие приводит к эффекту Вавилонской башни.
п

Обработка данных на предприятии без координирующего планирова¬
ния данных подобна работе системы телефонной связи без общего теле¬
фонного справочника.
Если каждый, кто создает процедуры ЭОД, будет изобретать свои
собственные данные и сам проектировать и определять их, то получае¬
мый в результате хаос дорого обойдется. Многие системы придется позд¬
нее заменять или совсем исключать из пользования. Руководители не
смогут получать данные, необходимые им для осуществления контроля
на высшем уровне или для принятия решений. Многие усовершенствова¬
ния как в области процедур, так и в области руководства, которые дол¬
жны быть обусловлены работой базы данных с терминальной сетью,
окажутся невозможными.
УЧАСТИЕ ВЫСШЕГО РУКОВОДСТВА В ПЛАНИРОВАНИИ
Во многих случаях отдел ЭОД становился инициатором попыток
наладить планирование данных в масштабах организации. Часто эти
попытки были не слишком успешными по двум причинам. Во-первых,
руководители ЭОД не обладали достаточной властью, чтобы заставить
всех придерживаться одинаковых определений и представлений данных.
Во-вторых (хотя иногда считают по-другому), профессионалы в области
ЭОД не полностью понимают все процессы в организации.
Поэтому в процесс информационного планирования желательно во¬
влекать главных руководителей предприятий.
В справочном руководстве ИБМ [2, гл. 6] по системе организацион¬
ного планирования (BSP) в отношении определения требуемых систем
баз данных говорится: «Анализ BSP не следует начинать до тех пор,
пока к нему не будут привлечены высшее административное лицо и не¬
которые другие представители руководства. Этот анализ должен отра¬
жать их точку зрения на автоматизируемый процесс, и успех организа¬
ции зависит от того, как хорошо они смогут передать разработчикам
свое понимание этого процесса и его потребности в информации. Боль¬
шая часть входной информации будет поступать прямо или косвенно
от этих руководителей».
Интервьюер:
Вы были свидетелем создания базы данных в вашей организации на про¬
тяжении восьми лет. Какова, по вашему мнению, единственная, наиболее важ¬
ная составляющая успеха?
Руководитель ЭОД:
Высшее административное руководство. Руководители предприятия долж¬
ны понимать, что происходит и как это влияет на будущее организации. Если
не будет наверху никого, кто собирал бы все разрозненные части вместе, каж¬
дый будет нестись в своем собственном направлении. С таким же успехом
можно иметь оркестр, в котором каждый играет разную симфонию.
Причин для вовлечения руководителей предприятия в планирова¬
ние базы данных много. Они перечисляются в вставке 1.1.
Вставка 1.1. Причины, по которым участие руководителем
предприятия в планировании необходимо для успеха базы данных
•	Информация является крайне важным ресурсом организации. Она вли¬
яет на производительность, рентабельность и на принятие стратегических реше¬
ний. Любой важный вид ресурса требует централизованного планирования.
12

•	Там, где техническая группа планировала информационные ресурсы
организации, она обычно была не в состоянии предусмотреть перспективные на¬
мерения руководителей или понять общие потребности в информации.
•	Лучшие планы проектировщиков баз данных разбивались о скалы
внутренней политики организации. Планы баз данных имеют тенденцию созда¬
вать внутренние проблемы, часто достаточно серьезные, и против этих планов
выступают различные подразделения.
Указанные проблемы часто можно разрешить только тогда, когда главное
руководство дает понять, что оно верит в то, что база данных — это перспек¬
тивный путь и своей подписью на плане информационных систем организации
кладет конец всем разногласиям.
•	Некоторые методологии централизованного планирования данных обна¬
руживают отклонения, излишние затраты и неэффективность в общих методах
работы организации. Во многих случаях централизованный анализ данных при¬
водил к реорганизации процедур и к не зависящей от ЭОД перестройке орга¬
низации.
•	Исключительно важной для развития ЭОД является эффективность
работы.
Избыточные нескоординированные прикладные разработки и излишняя
деятельность приводят к ужасающей трате ресурсов. Для уменьшения этих из¬
держек необходимо создание иерархической информационной архитектуры пред¬
приятия.
•	Чтобы установить приоритет работ в области ЭОД, необходима фор¬
мально построенная картина обработки информации по всему предприятию.
•	Следует выделить затраты для разработки базы данных независимо от
прикладных разработок.
*	Нужно планировать предметные базы данных и информационные си¬
стемы, а не отдельные файлы или прикладные базы данных. Для этого надо
научиться смотреть на систему в целом (сверху).
•	Необходима «оркестровка», чтобы усилия разных групп стыковались.
Многочисленные несовместимые фрагменты баз данных служат источником из¬
лишних расходов, связанных с их преобразованием, и не позволяют руководи¬
телям получать требуемую информацию.
•	Для достижения соглашения об определениях элементов данных нужна
стандартизация. Необходимы внутренние стандарты для того, чтобы можно
было воспользоваться общим словарем и общим средством моделирования.
•	Инфраструктура распределенных систем должна планироваться. Отдель¬
ные системы баз данных должны быть связаны общей сетью.
•	Методологии, описываемые в последующих главах, требуют участия ру¬
ководства и персонала отделов-пользователей, работающих под общим управ¬
лением сверху. ‘
Мы изучили несколько случаев, когда централизованное планирова¬
ние осуществлялось при участии высшего руководства и без него. Раз¬
личие гораздо разительнее, чем обычно считают. Планирование, выпол¬
ненное без участия главных руководителей, выходит за рамки ЭОД. Как
бы хороши ни были специалисты ЭОД в качестве аналитиков, они обыч¬
но не обладают тем деловым опытом, который требуется для понимания
тонкостей информационных потребностей. Когда они создают общий
план, как бы он ни был искусно задуман, он часто не принимается адми¬
нистрацией и становится предметом жестоких споров.
Администратор базы данных:
Когда три года назад был принят план, мы не обратились к руководите¬
лям предприятия, потому что чувствовали, что в то время они не были к этому
вполне готовы, поскольку идея эта была совсем новая и очень их озаботила бы.
Интервьюер:
С точки зрения сегодняшнего опыта, как вы думаете, было ли это ошиб¬
кой, что вы в самом начале не обратились к высшему руководству?
Администратор базы данных:
Это была катастрофа! Мы интуитивно чувствовали, что план был пра¬
вильный, но больше он не казался таковым никому. Весь замысел оказался
кошмаром.
13

Основной результат привлечения руководства — это твердая адми¬
нистративная поддержка систем данных, которые будут постепенно раз¬
виваться. Тогда вероятнее успех детального моделирования данных, ко¬
торое правильно представит организацию, будет использоваться, найдет
поддержку и понимание.
Второй результат более тонкий, но в некоторых случаях он был
очень мощным — это последствия для организации от свежего взгляда
на саму себя. Такой самоанализ, четко выраженный и не сопровождае¬
мый причитаниями о том, как предприятие «должно» вести дело, часто
служит средством, ведущим к перестройке организации, которое
эффективнее целой армии консультантов, требующей «смены караула».
ОТСУТСТВИЕ ВЗАИМОПОНИМАНИЯ
Во многих организациях между руководителями ЭОД и высшим
руководством отсутствует взаимопонимание. Это объясняется рядом при¬
чин: употребление жаргона ЭОД, непонимание руководством технологии
ЭОД и страх перед ней, невыполнение службой ЭОД своих ранних обе¬
щаний (особенно относительно информационных систем для высшего
руководства) и неспособность высшего руководства понять необходи¬
мость своего участия в проектировании ЭОД. Очень часто руководители
считают администратора данных специалистом, который обитает «в не¬
драх земли».
Консультант в области ЭОД:
Я помню, как администратор базы данных, который прежде был старшим
аналитиком, пришел к управляющему информационной системой и сказал:
«Я хочу понять потребности предприятия, чтобы учесть их при планировании».
Директор ему ответил: «Это не ваше дело». Эта компания и сегодня использует
базу данных в стиле «приложение-за-приложением», хотя она семь лет назад вы¬
ступала за идею создания базы данных в масштабах организации.
Интервьюер:
Была ли у вас возможность реальной связи с высшей администрацией для
объяснения проблем выбора?
Руководитель ЭОД:
Нет.
Интервьюер:
Что по вашему мнению сделало бы это возможным?
Руководитель ЭОД:
Для этого нужно, чтобы то, о чем вы говорите, было обосновано приме¬
рами из жизни, с которыми их можно связать жесткими количественными отно¬
шениями. Так, опыт освоения продукции дает вам основание пойти к руковод¬
ству и сказать: «Хорошо, посмотрите теперь. Вот, где мы были, и вот, куда мы
идем. На основании этого опыта можно сделать некоторые реальные прогнозы.
Я могу представить некоторые ощутимые результаты, благодаря чему мы мо¬
жем двигаться вперед в этом направлении». Я думаю, что если вы можете это
сделать, то вам выделят ресурсы.
Интервьюер:
Но это займет гораздо больше времени, потому что вам придется потратить
года три на приобретение некоторого опыта, прежде чем вы сможете пойти
к высшему руководству.
Руководитель ЭОД:
Так и было, у нас ушло на это два-три года.
14

Для организации, в которой опыт работы с базой данных невелик
или совсем отсутствует, не слишком хороший выход ждать три года,
набираясь опыта, чтобы обратиться к высшему руководству. Централи¬
зованное планирование (сверху вниз) требуется с самого начала, и как
часть этого процесса руководству должны быть названы реальные сро¬
ки получения ожидаемых результатов.
Если между отделом ЭОД и руководством отсутствует связь, некото¬
рые действия могут помочь наладить ее. Можно:
•	Пригласить консультирующую фирму, специализирующуюся в
области стратегического планирования баз данных.
•	Показать высшему руководству фильмы на эту тему, например,
снятые в фирме Deltak. Иногда это делается во время обеда или отдыха.
Тщательно продуманные пояснения должны связать фильмы с конкрет¬
ными обстоятельствами на данном предприятии.
•	Попросить руководителей прочитать эту книгу.
•	Организовать посещение руководителями краткого семинара, по¬
священного данному предмету (например, семинары, которые ведет ав¬
тор для руководителей предприятий).
•	Провести короткий, но емкий семинар для руководителей в самой
организации. Он обычно имеет большой эффект, если его проводит при¬
глашенный ведущий специалист, обладающий авторитетом.
•	Подчеркнуть для руководителей тот факт, что изменения в корпо¬
рации или организации часто происходят в результате изучения приме¬
нения данных, проводимого сверху вниз (см. гл. 9).
Вероятно, руководителей могут совершенно оттолкнуть технические
разговоры о структурах данных. Вероятно, они будут скептически на¬
строены по отношению к туманным обещаниям улучшить снабжение ру¬
ководства информацией.
Однако и здесь имеются определенные аспекты, способные привлечь
их внимание. .
Большой интерес администрация проявляет к решениям, касающим¬
ся того, как следует управлять предприятием:
•	К изменениям организационных процедур, структурным измене¬
ниям или реорганизации предприятия обычно приводят методологии
анализа объектов, рассматриваемые в гл. 7 и 8.
•	Большинство административных работников осознают, что в не¬
которых областях они хотели бы получать лучшую информацию. Иног¬
да у них нет возможности высказать это и заставить себя выслушать.
•	Руководителей часто заботит производительность конторских ра¬
бот. В большинстве организаций деньги растрачиваются напрасно из-за
избыточных процедур. Подробное графическое изображение видов дея¬
тельности, где используются аналогичные данные, может помочь устра¬
нить отклонения в организационных методах.
•	Большинство руководителей осознают те проблемы, которые свя¬
заны с сегодняшними операциями ЭОД. Этой теме посвящена работа
[2], где излагаются вопросы, связанные с системой организационного
планирования (BSP) в корпорации ИБМ (см. также гл. 6 настоящей
книги).
•	Быстрота реагирования систем ЭОД или скорость разработки
новых приложений иногда вырастают в проблему. Руководители не мо¬
гут получить новых отчетов тогда, когда они этого хотят. В одном из
больших банков в Нью-Йорке автору сообщили, что у них имеется се¬
милетний запас невыполненных заявок. Тщательное планирование баз
данных и их реализация должны резко повысить быстроту реагирова¬
ния систем ЭОД и скорость генерирования новых отчетов.
15

Чтобы сохранить конкурентоспособность, руководители пред¬
приятий должны в ближайшем будущем построить в высшей степени
компьютеризованные предприятия. Основой для этого служит анализ
данных в масштабах всего предприятия.
ПРОИЗВОДИТЕЛЬНОСТЬ ЭОД
Производительность ЭОД является предметом заботы во многих
организациях. Еще большее значение этот вопрос приобретает в связи
с удешевлением ЭВМ. Стоимость ЭВМ часто гораздо меньше размера
оплаты программистов и аналитиков. Стоимость компьютера резко па¬
дает, а заработная плата программистов и аналитиков растет. Высшее
руководство часто выражает проблемы производительности ЭОД в
сроках, необходимых для разработки новых требуемых приложений.
Многие авторитеты предлагают решить вопрос повышения произво¬
дительности ЭОД с помощью структурного программирования и струк¬
турного анализа. Это мало чему поможет. Тем не менее основные при¬
чины низкой производительности ЭОД скрытые и их не устранит приме¬
нение структурных вариантов тех же самых процедур. Причины кроют¬
ся в следующем:
•	Кажущееся тривиальным изменение вызывает цепную реакцию
модификаций программ. По мере развития систем эти цепочки измене¬
ний удлиняются и непредусмотренные последствия одного изменения
становятся все более тяжелыми. Руководители ЭОД с нежеланием при¬
ступают к реализации этих изменений и иногда говорят, что их нельзя
осуществить. Это послужило одной из основных причин создания систем
управления базами данных. Для полного решения проблемы требуются
централизованное планирование предметных баз данных, искусный про¬
ект логической базы данных и использование языков баз данных очень
высокого уровня.
•	Одни и те же данные в разных файлах представлены так, что их
нельзя совместить. Это серьезно препятствует преобразованию данных
или их ассоциированию в той степени, в какой это нужно для удовле¬
творения многих требований руководства.
•	В различных отделах организации имеется много разных вариан¬
тов одних и тех же бумажных отчетов. Для каждого отчета требуются
свои прикладные программы и их ведение. Если эти процедуры перепла¬
нировать, то можно было бы использовать для них одинаковые програм¬
мы. Чтобы осознать это и принять решение, необходим централизован¬
ный анализ требований к базе данных.
•	Для сегодняшних программ характерна избыточная логика, и
многие программисты пишут одинаковые подпрограммы.
•	Отнимающее много времени кодирование данных следует сокра¬
тить или исключить за счет применения словарей данных. Это позволит
уменьшить количество ошибок, связанных с данными в программах.
•	Большинство современных экономических программ пишут на та¬
ких языках, как Кобол или ПЛ/1. Скорость написания программ на
типичных ВЦ, составляет от 7 до 40 строк кода * в день. Высокоуровне¬
вые языки баз данных позволяют разрабатывать многие (но не все) при¬
ложения гораздо быстрее. Одна строка кода на таком языке часто
эквивалентна 10—40 операторам на Коболе.
* Предполагается независимость -производительности программистов от уровня
алгоритмического языка. — Прим&ч^рвд^ц^^	‘
16

•	Языки, доступные конечным пользователям, позволяют им делать
свои собственные запросы и генерировать свои собственные отчеты и
графики при условии доступности соответствующих средств баз данных.
•	Если соответствующие базы данных уже существуют, медленные
и трудоемкие процедуры системного анализа можно для одних типов
транзакций исключить, а для других — ускорить. Относительно быстрые
действия с базой данных обеспечиваются структурными спецификация¬
ми запросов на английском языке или на алгоритмических языках чет¬
вертого поколения (таких, как MANTIS, NOMAD, FOCUS, RAMIS, NA¬
TURAL, IDEAL и т. д.).
Целью хорошего стратегического планирования баз данных долж¬
но быть разрешение этих проблем и достижение максимальной произ¬
водительности ЭОД в будущем.
ПОЛИТИКА В ОРГАНИЗАЦИИ
Переход к работе с базой данных коллективного пользования часто
доставляет беспокойство конечным пользователям или настраивает их
враждебно. Пользователю иногда приходится говорить, что данными,
которые он считал своими собственными, теперь надо будет делиться с
другими или получать их из базы данных, которую ведут другие. Этот
пользователь может отнестись к внедрению базы данных, как к втор¬
жению на его собственную, тщательно защищаемую территорию.
В гл. 9 мы подчеркиваем, что реорганизация процедур или пере¬
стройка предприятия часто должна проходить синхронно с внедрением
базы данных, а для этого требуется участие высшего руководства.
Часто, когда базы данных пускаются в эксплуатацию, руководство
или пользователи начинают получать информацию из других источников.
Это может огорчать давно работающих служащих, которые обычно со¬
общали эту информацию.
Администратор данных:
У нас работал один бухгалтер, который решительно не позволял мне вникать
в то, что обеспечивали его системы. Он считал, что вполне может удовлетворить
учетными данными своих пользователей. Это была его прерогатива поставлять
данные именно своим образом, что давало ему особое положение, которое он
боялся потерять. Он до сих пор вне себя от одной мысли, что пользователь
может подойти к терминалу и получить доступ к той информации, которую
раньше предоставлял он сам.
Во многих организациях внутренние противоречия не оставили кам¬
ня на камне от попытки внедрить базу данных. Во всей короткой истории
развития баз данных основной причиной провалов служили проблемы,
связанные с людьми, а не с техникой.
Между ситуацией, когда служба ЭОД пытается внедрить базу дан¬
ных по собственной инициативе, и ситуацией, при которой высшее руко¬
водство понимает, одобряет и явно поддерживает переход к использо¬
ванию базы данных, огромная разница. Если руководители говорят:
«Мы должны построить компьютеризованное предприятие с базой дан¬
ных.и хотим, чтобы все это понимали и помогали насколько могут» —
то одно это уже огромное дело. *
Подчеркивание нежелательности разрушительных тенденций по от¬
ношению к базам данных дол>род£^555в|||иймяг^ иначе та-

кая политика, если ее не искоренить, в последующем сможет возобла¬
дать.
Программист:
Как только внедрение базы данных стало реальным, руководство само¬
устранилось, пустило дело на самотек. И, как часто случается, дело пошло под
откос.
ОТДАЧА БАЗЫ ДАННЫХ
Другая причина необходимости привлечения высшего руководства
к планированию — утверждение сметных расходов на разработку базы
данных. Разработка базы данных для предприятия требует немалых за¬
трат. Окупаемость их долгосрочная, и затраты не ограничиваются пер¬
выми приложениями или пользователями.
Администратор базы данных:
Когда мы обсуждали план с конечными пользователями, они обычно реа¬
гировали так: «Вот это да! Это обойдется нам так дорого!».
Нам задавали вопрос: «Кто будет за это платить?». Конечные пользовате¬
ли считают, что у них уже есть работающая система, и они не хотят платить
за то, чтобы переписывать ее под лозунгом базы данных.
Интервьюер:
Что же, забота о том, кто платит, служит основным тормозом при перехо¬
де от файловых систем к базе данных?
Администратор базы данных:
Раньше они платили столько же или даже больше за файловые системы.
Но они знали, за что платят.
Когда дело касается баз данных, особенно на начальной стадии, они дума¬
ют, что платят за систему, которая не является целиком их собственностью.
Интервьюер:
Так как же, по вашему, правильно подойти к решению этой проблемы?
Администратор базы данных:
Мы должны выходить к руководству, имея систему с лучшей отдачей, а
также с наброском требуемого бюджета для исследования и начала работ. Мы
должны представлять наши обязательства полностью и показывать руководству
общую картину. На деле это означает показ архитектуры информационной си¬
стемы. Это то, что мы сейчас пытаемся делать.
Руководству был представлен план с подробным указанием расходов и
набросками того, что мы хотим реализовать в ближайшие два-три года.
Мы не хотим, чтобы руководство догадывалось о требуемых расходах.
Я полагаю, что это время уже ушло в прошлое; мы никогда не определяли всех
расходов на АИС.
Все затраты мы оправдываем сокращением излишне высокой стоимости
ведения систем и ускорением прикладных разработок.
Если организация ориентируется на долгосрочное планирование,
она будет готова принять план разработки базы данных, рассчитанный
на 3—4 года. Если же она ориентируется на краткосрочное планирова¬
ние и пытается выжать максимальную прибыль от ежегодных поставок,
то проект многолетних разработок не встретит хорошего приема.
Окупаемость вложений на разработку ЭОД достигается за 3—4-лет¬
ний период.
18

Одна из корпораций, имеющая самый большой в мире прирост пре¬
доставляемых услуг ЭВМ, получает сотни миллионов долларов в год
за установку приложений для заказчиков с минимальными непосредст¬
венными затратами. С этой целью корпорация избегает применять тех¬
нологию баз данных. Однако стоимость ведения этих приложений воз¬
росла и теперь до 80% ресурсов персонала работает в этой области.
Минимизация краткосрочных затрат на ЭОД приводит к высокой стои¬
мости обслуживания в дальнейшем и препятствует разработке баз дан¬
ных, которые позволили бы быстро и недорого реализовать приложения.
Руководитель ЭОД:
Проблема заключается в том, что администрация корпорации должна
обеспечить прибыль сегодня. И основные затраты на базу данных должны идти
из сегодняшних прибылей.
Интервьюер:
Вы видите решение этой проблемы?
Руководитель ЭОД:
Мы должны обучать высшее руководство. Тогда оно осознает необходи¬
мость расходовать небольшую часть средств сегодня с тем, чтобы получить их
максимальный возврат завтра. И если бы правительство согласилось рассматри¬
вать затраты на базы данных или на любые другие крупные информационные
системы как капитальные, мы смогли бы считать их в корпорации как любые
другие основные капитальные вложения.
Расходы на базу данных относятся к тому виду затрат, которые
следует отнести к капитальному строительству. Как и оборудование, ба¬
за данных будет служить многие годы. Если проектировщикам удастся
создать стабильные структуры данных на основе моделей данных [1] и
средств автоматизированного проектирования [3], срок службы базы
данных составит не менее 10 лет, а вероятно и более. База данных про¬
служит дольше, чем большая часть производственного оборудования.
Относить эту стоимость на счет только сегодняшних пользователей не¬
разумно, особенно если учесть, что на разработку приложений, исполь¬
зующих базу данных полностью, уйдет несколько лет.
ВЫБОР БЫСТРО ОКУПАЮЩИХСЯ ПРОЕКТОВ
После этого можно сказать, что существуют возможности получить
быструю отдачу от баз данных в некоторых приложениях. Создавая цен¬
трализованный план, желательно найти такие системы, с помощью ко¬
торых можно продемонстрировать результаты. Часто это системы, ис¬
пользующие языки баз данных высокого уровня [4], которые позволяют
очень быстро и гибко достигать результатов.
Администратор базы данных:
Наш опыт показывает, что руководство должно почувствовать немедлен¬
ную отдачу. Так что возможность что-то выдать (и фактическая выдача) очень
важна. Обязательства не должны быть слишком претенциозными, чтобы они не
показались относящимися к области мистики.

ПРИОРИТЕТ РЕАЛИЗАЦИИ
Важная часть стратегического планирования — определение приори¬
тета реализаций. Нужно выработать такую общую структуру требуемых
систем на предприятии, чтобы можно было рационально определить
приоритет их разработки. Первыми следует разрабатывать те системы,
которые решают насущные вопросы, дают быструю отдачу или которые
можно быстро и легко реализовать.
Можно реализовать множество систем, обладающих такими харак¬
теристиками, если они будут служить «кирпичиками» в общем плане
предприятия.
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ
Методологии создания систем обработки данных быстро изменяют¬
ся. Термин «технология» применительно к современным методологиям
показывает, что они основаны на формальных дисциплинах с точными,
хорошо продуманными методами, а не изобретаемыми по ходу дела и
часто некорректными, как это происходит в современном программиро¬
вании.
Термин технология программирования относится к набору дисцип¬
лин, который необходим для спецификации проектирования и написания
математического обеспечения ЭВМ. Термин информационная технология
относится к набору взаимосвязанных дисциплин, которые требуются для
построения компьютеризованного предприятия, основывающегося на со¬
временных системах баз данных. Основа информационной технологии —
данные, которые помещаются в память и ведутся вычислительными ма¬
шинами, а также информация, извлекаемая из этих данных. Основа тех¬
нологии программирования—логическое представление компьютеризо¬
ванных процессов.
Методы технологии программирования были формализованы в
1970-х годах. Они включают структурное программирование, структур¬
ное проектирование и структурный анализ, а также средства их под¬
держки. Эти методы необходимы для создания сложного программного
обеспечения со сложной логикой. Однако в большинстве случаев проекты
обработки данных можно сделать относительно простыми за счет приме¬
нения соответствующих методов баз данных, но создать правильные
базы данных и средства для их эффективного использования трудно.
Методы 70-х годов редко были достаточно хорошими, и многие инфор¬
мационные системы не отвечали потребностям организаций.
Сегодня некоторые корпорации обладают отличными информацион¬
ными системами. Информационная технология формализует методы их
создания. Она включает различные схемы и приемы, заимствованные из
технологии программирования.
Основная предпосылка информационной технологии заключается
в том, что в центре современной обработки данных находятся данные.
Это показано на рис. 1.1. Данные хранятся и ведутся с помощью различ¬
ных видов программного обеспечения систем данных. Процессы, пока¬
занные на рис. 1.1 слева, создают и модифицируют данные. Данные
должны отыскиваться и вводиться при осуществлении соответствующего
контроля. Они будут периодически обновляться. Процессы справа на
рис. 1.1 используют эти данные в таких повседневных документах, как
счета, квитанции, накладные, рабочие наряды. Административные или
профессиональные служащие обращаются к системе в поисках нужной
информации. Они составляют сводки или проводят анализ данных, со-
20

ставляют таблицы и отчеты, задают вопросы типа «что если?» и исполь¬
зуют данные при принятии решений. Ревизоры проверяют данные и
пытаются удостовериться в том, что они были правильно применены.
Данные на рис. 1.1 могут представлять множество систем данных.
Сами данные могут храниться различным образом, они часто бывают
распределенными, часто обновляются и используются с помощью тер¬
миналов.
Вторая основная предпосылка информационной технологии заклю¬
чается в том, что типы используемых на предприятии данных не очень
изменяются. Объект—это нечто, о чем мы храним данные: например,
заказчики, запасные части, служащие или станки. Типы объектов не из¬
меняются на протяжении срока существования производства, за исклю¬
чением случайных (редких) добавлений новых типов объектов. Типы
Рис. 1.1. Современная обработка данных состоит в ос¬
новном из действий, которые создают и модифицируют
данные при соответствующем контроле точности, и из
процессов, которые используют, анализируют, суммиру¬
ют данные и манипулируют ими или печатают доку¬
менты на основании этих данных
атрибутов, которые мы храним для этих объектов, также изменяются
редко. Значения данных меняются постоянно, как данные на информа¬
ционном табло в аэропорту, но структура этих данных изменяется не
намного, если с самого начала они были хорошо спроектированы.
Имея определенный набор типов элементов данных, мы можем най¬
ти оптимальный способ их логического представления. Это задача адми¬
нистратора данных. Для создания устойчивых моделей данных админи¬
стратор данных применяет формальные методы (которые были автома¬
тизированы [3]). Эти модели, если они хорошо спроектированы, изме¬
няются мало, и в информационной технологии становятся краеугольным
камнем, на котором строится большинство компьютеризованных про¬
цедур.
Хотя данные относительно стабильны, процедуры, для которых ис¬
пользуются эти данные, изменяются быстро и часто. Желательно, чтобы
системные аналитики и конечные пользователи могли часто их изме¬
нять. Нам нужна максимальная гибкость в улучшении административ¬
ных процедур и приспособлении их к быстро меняющимся требованиям
руководства. Каждое производство динамично меняется, а точка зрения
руководства на то, как вести его, меняется еще быстрее.
Итак, процедуры изменяются (или должны изменяться) быстро;
программы, процессы, сети и аппаратура ЭВМ изменяются; но основные
типы данных относительно стабильны.
21

Фундамент данных будет жизнеспособным, только если данные пра¬
вильно идентифицированы и структурированы, так чтобы ими можно бы¬
ло пользоваться с достаточной гибкостью. Это не простая задача. Мно¬
гие из ранних попыток создать информационные системы в масштабах
организации провалились. Сегодняшние попытки успешно осуществля¬
ются там, где Применяется соответствующая методология.
Из-за того, что основные типы данных стабильны, в то время как
процедуры имеют тенденцию изменяться, методы, ориентированные на
данные, если их правильно применять, имеют успех там, где методы,
ориентированные на процедуры, оказались нежизнеспособными. Многие
Эти блоки должны
оставаться отно'
сит ель но стабиль¬
ными, 8 то Время
как процедуры,
приложения, гене¬
рируемые отчеты,
распределение
и физическая
реализация
изменяются
Применяются часто аналитиками или
конечными пользователями без
участия программистов
Рис. 1.2. Информационная технология. Современные методологии для
руководителей ЭОД. В этой книге рассматриваются два нижних бло¬
ка, служащих фундаментом
процедурно-ориентированные методы привели к системам, которые мед¬
ленно реализуются и которые трудно изменять. Информационная техно¬
логия стремится к быстрому удовлетворению меняющихся потребностей
руководства в информации.
Когда необходимая инфраструктура данных определена, можно по¬
лучать результаты быстро, пользуясь высокоуровневыми языками баз
данных и генераторами приложений [4].
На рис. 1.2 показан ряд шагов, отражающих наилучшие, по нашему
мнению, методы построения системы обработки данных. В настоящей
книге описываются только два нижних блока, остальные блоки рассмо¬
трены в других книгах автора.
Нижний блок представляет создание модели предприятия, что об¬
суждается в гл. 2. На рис. 2.4 показан пример такой модели. Модель
предприятия должна отражать не только его текущую деятельность, но
и будущую, когда ее можно предвидеть. При построении модели следует
изучить источники информации, нужные руководству, хотя в текущий
момент и нет в них необходимости.
22

Второй блок на рис. 1.2 —это стратегический план данных. Два
нижних блока вместе служат фундаментом компьютеризованной органи¬
зации и составляют предмет предлагаемой книги. Они помогают гаран¬
тировать, что вместо множества фрагментов с несовместимыми данными
будет построен интегрированный набор систем данных и что построен¬
ные системы будут отвечать истинным требованиям руководства. Эти
два блока предоставляют руководству самого высшего уровня план дей¬
ствия, в соответствии с которым надо направлять разработку информа¬
ционных ресурсов.
Третий блок связан с построением стабильных детальных моделей
данных. Над этой задачей могут работать различные команды, имею¬
щие дело с различными группами объектов или предметных баз данных,
как определялось на шаге 2. Этот шаг описан в работе [1]. На этом
этапе требуется глубокий анализ данных и хорошие методы администри¬
рования данными.
Три нижних блока на рис. 1.2 образуют тот фундамент, на котором
будет строиться основная обработка данных в будущем. Как только они
будут построены целиком или частично, желательно как можно быстрее
начать разрабатывать вычислительные процедуры, чтобы можно было
создавать и использовать данные, как это показано на рис. 1.1.
Языки четвертого поколения [4] позволяют подготавливать проце¬
дуры для ЭВМ гораздо быстрее, чем языки третьего поколения, такие,
как Кобол или ПЛ/1. Некоторые языки четвертого поколения — непро¬
цедурные; другими словами, они не являются языками программирова¬
ния, которые шаг за шагом показывают, как достичь результата. Вместо
этого они наглядно показывают, какой результат требуется, а система
определяет, как этого результата добиться. Блоки 11 и 12 на рис. 1.2
представляют применение непроцедурных языков.
Другие языки четвертого поколения — процедурные [4]. Это языки
программирования очень высокого уровня, они позволяют создавать про¬
цедуры, укладывающиеся в гораздо меньшее число строк кода, чем при
использовании Кобола или ПЛ/1—иногда это одна десятая или еще
меньшая часть строк кода. С этими языками обычно намного легче ра¬
ботать, чем с Коболом или ПЛ/1, но они не обязательно могут охватить
все приложения предприятия.
Оба типа языков четвертого поколения настолько легки в употребле¬
нии, что пользователи или аналитики создают приложения очень быстро.
Это жизненно необходимое улучшение процесса ЭОД при условии, что
пользователи не изобретают сври собственные структуры данных. Во
многих же случаях именно так пользователи и поступают, обрадовав¬
шись обретенной свободе и независимости от программирующей органи¬
зации ЭОД. Там, где данными (не персональными) пользуются коллек¬
тивно, применение языков четвертого поколения должно сочетаться с
моделями данных, как показано блоками 9 и 10 на рис. 1.2.
Чтобы писать процедуры, применяющие данные БД, нужен метод
схематизации для представления действий, которые создают, выбирают,
обновляют или исключают данные. Эти схемы действий [5] записыва¬
ются таким образом, чтобы их можно было преобразовывать непосред¬
ственно в «скелеты кода» процедурных языков четвертого поколения или
в структурные спецификации на английском языке для программ, со¬
ставляемых на языках третьего поколения [5]. Это является основой
блока 4 на рис. 1.2.
Для часто запрашиваемых приложений очень вйжен анализ того,
как используются данные (блок 5). Он подводит к решениям относи¬
тельно распределения данных (блок 6) и физической организации базы

данных (блок 7). Для приложений с небольшим объемом транзакций
детальный анализ использования данных не является необходимым при
наличии соответствующих систем управления данными. Эти системы
могут совершенно отличаться от классических систем управления база¬
ми данных (КОДАСИЛ, IMS, DL/1, TOTAL и т. п.).
Вычислительная среда на рис. 1.2 резко отличается от старых мето¬
дов системного анализа. Автоматизированные методы позволяют намно¬
го повысить производительность, связанную с применением ЭВМ в орга¬
низациях. Эта среда позволяет строить системы, которые могут быстро
реагировать на потребности управленческого персонала в вычислитель¬
ных работах и в информации. Такие методы могут намного сократить
стоимость ЭОД. Они отражают главное изменение в управлении ЭОД.
Добавление другого слоя к обычным моделям баз данных, называе¬
мого интеллектуальной базой данных *, может еще больше повысить
эффект использования баз данных и ускорить разработку приложений.
В интеллектуальной модели данных содержатся логика и правила, кото¬
рые обычно выполняются при обращении к данным.
ДОМ НА ПЕСКЕ
Невероятно соблазнительно строить системы данных без блоков —
фундамента, показанного на рис. 1.2. Еще более соблазнительным это
будет, когда программное обеспечение систем данных станет гораздо
мощнее и «дружелюбнее» к пользователю.
Большинство данных на предприятии должно переходить из одного
отдела в другой. Некоторые данные надо собирать в ряде функциональ¬
ных областей, чтобы получить информацию, необходимую для принятия
решения или для управления. Не так уж много данных, проектировать
которые мы можем позволить без координации и произвольно местным
энтузиастам, желающим, чтобы их оставили в покое.
Стратегическое планирование, если его проводить эффективно с
помощью апробированной методологии, стоит не так уж много по срав¬
нению с теми скрытыми расходами, которые несут в себе хаотические
данные. Затраты на него одноразовые. Осуществление такого планиро¬
вания не ограничивает свободы разработчиков на местах. Как только
соответствующие системы данных будут задействованы, они намного
расширят свободу изменения процедур в организации.
Построение современной обработки данных без фундаментальных
блоков, приведенных на рис. 1.2, подобно построению дома на песке. Ра¬
но или поздно это приведет к беде, и дом надо будет перестраивать.
Отсутствие такого краеугольного камня, как планирование данных,—
одна из причин того, что такая большая часть деятельности, связанной
с обработкой данных, неуклонно погружается в болото ведения систем
обработки данных [6]. Работы по ведению систем обработки данных,
вызванные отсутствием планирования, обходятся несравнимо дороже,
чем планирование. Тем не менее для планирования нужны более точные
методологии, такие, как описанные в гл. 7 и 8.
* Базы данных с такими свойствами получили в настоящее время название баз
знаний. — Примеч. ред.

ГЛАВА 2
РАЗРАБОТКА МОДЕЛИ ПРЕДПРИЯТИЯ
(ОРГАНИЗАЦИИ)
ВВЕДЕНИЕ
Первым шагом на пути централизованного планирования является
создание схемы или модели рассматриваемого предприятия (организа¬
ции). В производственных корпорациях она называется экономической
моделью. Несмотря на то, что эта методология применяется в организа¬
циях, которые не являются «производственными», например, в прави¬
тельственных учреждениях, больницах и университетах, мы будем назы¬
вать ее моделью предприятия, а все такие организации будем называть
предприятиями. Модель предприятия показывает все функции, необходи¬
мые для работы этого предприятия.
Модели предприятий отличаются степенью детализации. Некоторые
модели показывают не только функциональные области и процессы, но
также подробные виды деятельности, осуществляемой в каждом процес¬
се. Некоторые методологии планирования информации относятся только
к функциональным областям и процессам, другие — к функциональ¬
ным областям, процессам и деятельности. Наилучшие результаты дают,
как правило, более подробные методы. И как мы увидим, для их при¬
менения необходимы ЭВМ, поскольку такие методы требуют слишком
много детальных данных, которые невозможно обработать вручную.
Когда модель предприятия будет отражать потребности в данных,
мы фактически получим ориентированную на данные версию модели
предприятия. Ее можно будет разделить на базы данных, требующие
реализации.
ФУНКЦИОНАЛЬНЫЕ ОБЛАСТИ
К функциональным относятся основные области деятельности в ор¬
ганизации, такие, как проектно-конструкторские работы, сбыт, произ¬
водство, научные исследования и поставки. Одна промышленная компа¬
ния отнесла к числу своих функциональных областей следующие:
планирование выпуска и сбыта продукции,
финансы,
планирование номенклатуры изделий,
потребности в материалах,
производственное планирование,
управление производством,
сбыт,
поставки,
бухгалтерский учет,
кадры.
25

В книгах по организации управления производством функциональ¬
ным областям в корпорациях уделяется много внимания.
Первым этапом планирования информационных ресурсов является
составление функциональной схемы. Она показывает перспективу рабо¬
ты всей корпорации.
Базы данных рассчитаны на длительное обслуживание корпорации,
поэтому функциональная схема должна включать планирование всех
предусматриваемых будущих операций.
Необходимо решить, какую часть корпорации затронет централизо¬
ванное планирование—всю корпорацию, одно подразделение или одну
фабрику. В большой корпорации планирование может осуществляться
по подразделениям или функциональным областям поочередно. Опыт,
полученный на первом этапе планирования, может быть использован на
последующих этапах.
Руководящий орган аппарата управления должен проверить пол¬
ноту списка функциональных областей корпорации и определить объем
исследований.
ПРОЦЕССЫ
Каждая функциональная область включает определенный ряд про¬
цессов. На рис. 2.1 показаны типичные функциональные области и про¬
цессы. Всего приводится 37 процессов. В большинстве корпораций их
больше. Крупные корпорации могут иметь около 30 функций и от 150 до
300 процессов.
Определение функциональных областей и процессов должно быть
независимым от текущей схемы организации. Организация может изме¬
няться, но при этом осуществлять те же функции и процессы. Некоторые
корпорации каждые два года подвергаются перестройке, которая прохо¬
дит не безболезненно. Определение функций и процессов должно отра¬
жать функциональную основу того, как корпорация работает, независи¬
мо от ее текущей организационной схемы (часто обманчивой). В неко¬
торых организациях необходимо проводить тщательное обследование
с целью выяснения, насколько логичны выполняемые функции и про¬
цессы. .
Процессам даются названия, ориентированные на действия, такие,
как, например, на рис. 2.2.
Много систем ЭОД и приложений создаются для удовлетворения
информационных потребностей какого-либо конкретного подразделения
или организационного объекта, а также для получения выходных отче¬
тов, требующихся для какого-либо конкретного руководителя. Они ста¬
новятся ненужными при реорганизации корпорации или смене руководя¬
щего состава. Так должно быть и с процессами, определенными при
централизованном планировании. Эти процессы представляют основные
виды деятельности и области принятия решений, не зависящие ни от ка¬
кой подотчетной иерархии или конкретных обязанностей руководителя.
Процессам можно давать простые определения. Например, управле¬
ние запасами можно определять как «процесс контролирования приема
и выдачи сырья, деталей и комплектующих изделий со складов и отчет¬
ности за работу склада». Такую работу может выполнять отдельное
подразделение или этот процесс может относиться к работе нескольких
подразделений. Склады могут быть разделены или объединены, но про¬
цесс идет.
Продукция и службы, создаваемые организацией, а также службы,
необходимые для их поддержки, имеют четырехстадийный жизненный
2G

ФУНКЦИОНАЛЬНЫЕ ОБЛАСТИ
ПРОЦЕССЫ
Планирование выпуска и сбыта продук¬
ции
Анализ рынка
Пересмотр объема выпуска продукта
Прогноз сбыта
Финансы
Финансовое планирование
Капитальные вложения
Руководство фондами
Планирование номенклатуры изделий
Проектирование изделия
Ценообразование
Поддержание технических характери¬
стик изделия
Потребности в материалах
Потребности в материалах
Закупочная деятельность
Получение материалов
Управление запасами
Контроль качества
Производственное планирование
Планирование производственных мощно¬
стей
Определение режима работы предприя¬
тия
Схема размещения рабочей силы
Управление производством
Управление материалами
Упорядочение по типоразмерам
Машинные операции
Сбыт
Территориальное размещение
Продажа
Управление сбытом
Связи с заказчиком
Поставки
Управление запасами готовой продукции
Обслуживание заказов
Упаковка
Отправка
Бухгалтерский учет
Кредиторы и дебиторы
Движение денежной наличности
Фонд заработной платы
Производственный учет
Разработка плана и смет
Анализ прибылей
Кадры
Планирование численности работающих
Комплектование штата
Компенсационная политика
Рис. 2.1. Функциональные области и процессы. Крупная корпорация обычно имеет от
10 . о 30 функциональных областей и от 100 до 300 процессов

цикл: планирование, приобретение, изготовление и реализация. На
рис. 2.2 показаны некоторые типы процессов на каждой стадии этого
цикла. Прослеживание всех стадий жизненного цикла каждого типа
продукции, службы или ресурса помогает иногда идентифицировать
сами процессы. Это можно проделать с деньгами, персоналом, сырьем,
деталями, готовой продукцией, оборудованием, постройками, станками,
арматурой и т. д.
Идентифицированные процессы можно разнести по исполнителям в
организации. Это показано на рис. 2.3. Такую матрицу можно использо-
Суммарные
банные
планирооания
Приобрете¬
ние
данные ,
транзакции
Данные .
транзакции
Обслужива¬
ние
Планирова -
ние
Потребности
Проектирование
Измерение
контроль
Бухгалтерский
учет
Изучение
возможностей
рынка
Прогнозирована е
Планирование
производственных
модностей
Оценка
Реализаций
Поставка
складирование
Продажа
Комплектование
Управление
Доставка
штата
запасами
Содержание
Обслуживание
заказов
Реализация
Ведение
Отправка грузов
Создание
Маршрутизация
Управление парком
транспортных
средств
изготовление
модификация
Разработка
Проек тно •
коне труп торс кие
работы
произ воде твен ное
календарное
планирование
контроль
качества
упаковка
Ремонт
Счета кредиторов
Изъятие из
обращения
Ликвидация
оборудования
Отходы
Испытания
Рис. 2.2. Четырехстадийный жизненный цикл продукции, служб и ре¬
сурсов
вать для определения тех лиц, которых надо опросить об этих процессах.
Подобные опросы помогут исключить вероятность пропуска каких-либо
процессов. Важно понять, что формальная организационная схема пред¬
приятия обычно не так уж хорошо представляет функции и процессы.
Процессы, в которые вовлечены некоторые лица, часто отличаются от
тех процессов, что представлены в организационной схеме.
Консультант по стратегическому планированию:
В компании существует подробный перечень функций и обязанностей.
Беда в том, что они не выполняются. Очень трудно прийти к соглашению о том,
у кого какие обязанности и какие данные кому принадлежат.
Группа стратегического планирования должна попытаться иденти¬
фицировать все процессы в корпорации или подразделении, которыми она
занимается. В списке процессов не должно быть дублирования. Не сле¬
дует искусственно объединять процессы для сокращения их числа.
В большой организации часто насчитывается 100 или более процессов.
Мы выступаем за то, чтобы методы планирования, связанные с обработ¬
кой этих процессов, применялись на ЭВМ. Весь план должен поддавать¬
ся машинной обработке.
28

to
о
/ Основное ответственное и
принимающее решение л и ио
Частичное участие 6
процессе
\/ Основной участник
/х процесса
Рис. 2.3. Функциональные области и процессы предприятия, наложенные на существующую организацион¬
ную структуру [2]

Ответственный за планирование в корпорации:
Все происходящие здесь процессы по большей части плохо определены.
Они возникали и развивались в течение времени как попытки реагирования на
изменяющиеся условия. Функции часто совпадают, и организационные структу¬
ры, предназначенные для более простой операции, уже не подходят. Поэтому
при переходе к интегрированной информационной системе мы скоро осознали,
что нам надо проанализировать производство, его процессы и всю работу, а так¬
же определить связи между функциями и степень зависимости между ними.
В создании модели предприятия существенной является помощь ру¬
ководящего состава и конечных пользователей. Только они знают, как в
действительности работает предприятие. То же справедливо и в отноше¬
нии более подробной идентификации объектов данных, которые требу¬
ются для работы предприятия.
Ответственный за планирование в корпорации:
Сначала, даже несмотря на предполагаемое привлечение пользователей к
работе, мы ожидали, что аналитики смогут сделать больше. Но это оказалось
не так, потому что аналитики знали суть производства недостаточно подробно,
чтобы определить объекты для модели. Вскоре стало ясно, что пользователи
должны играть гораздо большую роль, чем мы сначала предусматривали.
ДЕЙСТВИЯ
В каждом процессе на предприятии выполняется ряд действий. На¬
пример, на рис. 2.1 одним из процессов является закупочная деятель¬
ность. В этом процессе надо выполнить следующие действия:
•	Подготовить требования на закупку.
•	Выбрать поставщиков.
•	Подготовить закупочные заказы.
•	Довести до конца поставки элементов закупочных заказов.
•	Обработать исключения.
•	Подготовить информацию для счетов кредиторов.
•	Записать данные о работе поставщиков.
• Проанализировать работу поставщиков.
В каждом процессе на предприятии обычно выполняется от 5 до
30 действий. В небольшой корпорации может быть несколько сот дей¬
ствий, а в. большой — несколько тысяч.
Это разделение между процессами и 'действиями носит несколько
искусственный характер. Лучше разбивать функциональные области на
функции, каждую функцию — на функции более низкого уровня и так
далее, пока не придем к базовым действиям. На рис. 2.4 приведен при¬
мер такого иерархического деления функций. Функцию самого низкого
уровня можно назвать действием и его описание должно начинаться с
глагола, обозначающего выполняемую операцию.	*
В большинстве корпораций никогда не составляют схему действий.
Когда же их перечисляют и соотносят с необходимыми для них данны¬
ми, то обычно становится ясно, что имеет место дублирование. Каждое
подразделение в корпорации стремится расширить свои действия,
не зная об аналогичных действиях других служб. Каждое подраз¬
деление стремится создавать свои собственные формы отчетов. Это не
имеет особого значения, если отчеты обрабатываются вручную. Однако
если они обрабатываются на ЭВМ, то увеличение числа форм отдельно
30

проектируемых отчетов пагубно, так как намного повышает стоимость
программирования и ведения. Процедуры в компьютеризованной корпо¬
рации должны отличаться от процедур в корпорациях, где бумажная
КОРПОРАЦИИ
ИЛИ
ПОДРАЗДЕЛЕНИИ
ФУНКЦИОНАЛЬНЫЕ
ОБЛАСТИ
ОРГАНИЗАЦИЙ
Функции
Производственный у отдел.
t
^Планирование^

Анализ рынка.

"Проанализировать заказчиков
Определить стоимость помпон
материалы.

Закупки
Подготовить требование на закупку
Информация о поставщиках
Записать данные о работе поставщиков
Проанализировать работу поставщиков
выбрать поставщика
Подготовить заказы но закупку
"AodpoToSuTiTJ^^
Записать данные о роботе поставщиков
'Лроаналйзй^
Получение
Складирование
Определение потребностей
Прогнозировать спрос._________
контролировать уровни, запасов

Проверить' запас
тение
Принять груз.

Осуществить контроль качества
Записать показатели качества
Сформулиробать статистику насест ба
Поместить изделие на склад.
Записать получение^ изделия^
		Уй<оррёктщ^ 'запас. '
Отправка
Собрать заказы
Упаковать заказы
Отгрузить заказы
Записать отгрузку
Скорректировать запас
Рис. 2.4. Схема предприятия: корпорации или подразделения, функцио¬
нальные области и функции. Функцию самого низкого уровня иногда
называют действием. Его название должно начинаться с глагола. Для
каждого действия проектируется процедура (не обязательно с исполь¬
зованием ЭВМ)
отчетность обрабатывается вручную. Большинство этих процедур долж¬
но быть оперативным, с контролем избыточности данных и минималь¬
ным разнообразием прикладных программ. Поступление данных на тер¬
минал исключает необходимость создания многочисленных отпечатан¬
ных через копирку копий форм, расходящихся по различным участ-
31

кам. Информация немедленно становится доступной, и процедуры сле¬
дует изменять, чтобы можно было этим воспользоваться.
Когда в целях стратегического планирования составляют перечень
действий и необходимых для них данных, дублирование следует сводить
к минимуму. Дублирование действий обнаруживается с помощью схем
отображения данных на действия. Часто эти схемы предлагают пути ре¬
организации действий.
Таким образом, централизованное планирование переходит из сфе¬
ры ЭОД в сферу управления предприятием и заставляет задуматься о
его реорганизации.
СХЕМЫ ПРЕДПРИЯТИЙ
Следует иметь схему, показывающую функции и действия предприя¬
тия. Эта схема бывает большой, так как действий сотни, а иногда и
больше тысячи. Она будет дополняться и изменяться на всем про¬
тяжении исследования вопроса, поэтому ее лучше вести на ЭВМ. При¬
мер такой схемы показан на рис. 2.4.
Эту схему можно разбить на меньшие, показывающие, например,
корпорацию и ее функциональные службы или подразделения одной
функциональной службы. Формат этой схемы тот же, что и у схемы,
приведенной в следующей главе для представления объектов и их ассо¬
циаций. Для составления и ведения обеих схем, а также для логических
моделей баз данных можно пользоваться одним и тем же программным
обеспечением.
ХАРАКТЕРИСТИКИ МОДЕЛИ ПРЕДПРИЯТИЯ
Необходимо, чтобы модель предприятия обладала следующими свой¬
ствами:
Полнота. Модель должна представлять полный список функцио¬
нальных служб, функций и действий, составляющих данное предприятие.
Адекватность. Модель должна способствовать пониманию всего, что
касается предприятия. Функции или действия, определенные на каждом
уровне анализа, должны представляться естественными и правильными
для руководителей данного уровня.
Постоянство. Необходимо, чтобы модель оставалась обоснованной и
действенной до тех пор, пока сохраняется назначение предприятия. Не¬
которые учреждения периодически реорганизуются. У некоторых перио¬
дически меняется руководство. Но, несмотря на это, должны выполнять¬
ся те же самые функции. Модель должна быть способной «пережить»
реорганизации и не зависеть от того, где находятся данные — в файлах,
базах данных или на бумаге.
ПЛАНИРОВАНИЕ С ВЫСОКОЙ СТЕПЕНЬЮ РАЗРЕШЕНИЯ
Методологии стратегического планирования, которые будут обсуж¬
даться в последующих главах, различаются по степени разрешения. Ме¬
тодологии с более высокой степенью разрешения приводят к лучшим
планам баз данных, но им требуются средства электронной обработки
данных. Кроме того, как мы покажем в гл. 9, стратегическое планирова¬
ние с высокой степенью разрешения может вскрыть аномалии и избы¬
точность в организационной структуре, часто настолько большие, что за
этим следует реорганизация корпорации.
32

Централизованное планирование с более низкой степенью разреше¬
ния «работает» на уровне организационных процессов и предметных баз
данных, планирование же с высокой степенью разрешения — на уровне
организационных действий и объектов данных.
Можно сначала разработать план с меньшим разрешением, а затем
уже, вдаваясь в подробности, разработать план с более высокой степенью
разрешения. Опыт показывает, что наибольшие преимущества дает план,
составленный с более высокой степенью разрешения (см. гл. 7 и 8), так
что мы рекомендуем сократить время, затрачиваемое на приближенное
планирование.
ДРУГИЕ СЛУЧАИ ИСПОЛЬЗОВАНИЯ МОДЕЛИ ПРЕДПРИЯТИЯ
Модель предприятия в настоящей книге рассматривается в связи с
планированием баз данных и систем данных. Но она представляет цен¬
ность и для других видов планирования. Например, когда обсуждается
реорганизация предприятия, желательно иметь схему его деятельности.
Модель может помочь в планировании распространения средств автома¬
тизации конторской деятельности, а также при составлении списка про¬
фессий.
ГРУППИРОВКА ФУНКЦИЙ
Иерархическое разбиение функций, показанное на рис. 2.4, следует
остановить при получении функции, которая реализуется как физиче¬
ская процедура — специфицированная процедура, выполняемая на ЭВМ,
процедура без применения ЭВМ или диалог с терминала, который зара¬
нее не определишь.
Перечисленные функции будут функциями самого низкого уровня, и
мы назовем их действиями. Эти действия можно соотнести с объектами
на схеме объектов.
Для устранения избыточности модель действий и объектов можно
реорганизовать: избыточные объекты объединить, а избыточные дейст¬
вия слить; затем можно сгруппировать логические действия в функцио¬
нально связанные соединения, которые в основном образуют автоном¬
ные группы. Такую логическую группировку функций мы называем ло¬
гическом функциональной областью. Логические функциональные обла¬
сти образуют основу информационных систем, пользующихся одними и
теми же данными.
Логические функциональные области, полученные таким образом,
часто отличаются от коммерческих функциональных областей, которые
существуют фактически (и которые представлены на рис. 2.4). Коммер¬
ческие функциональные области сложились в результате исторических,
практически целесообразных, политических и организационных сообра¬
жений, имевших место в прошлом, и часто они представляют не самую
лучшую базу для информационных систем.
Процесс моделирования предприятия нередко вскрывает избыточ¬
ность и аномалии в его организации, о которых высшее руководство да¬
же не подозревает. Описанные здесь мероприятия по стратегическому
планированию часто приводили не только к реорганизации ЭОД, но и
к реорганизации самих предприятий (корпораций). Этот вопрос обсуж¬
дается в гл. 9. .
33

Руководитель планирования в корпорации:
Одно из основных наблюдений, которые я вынес в результате применения
данной методологии, заключается в том, что, даже если не происходит физиче¬
ской реализации проекта, моделирование организации — стоящее дело. Это ста¬
новится очевидным по мере реализации проекта и выражается в том, что все
больше людей, занятых в данной операции, начинают лучше понимать суть
дела, и в том, что предприятие может измениться организационно, чтобы макси¬
мально соответствовать своему назначению.
СТРАТЕГИЧЕСКОЕ ОРГАНИЗАЦИОННОЕ ПЛАНИРОВАНИЕ
Мы рассматриваем только стратегическое планирование данных, не
касаясь вопросов организационного планирования. Литература, посвя¬
щенная проблемам организационного планирования, обширна. И хотя мы
не обсуждаем эти проблемы, отметим, что организационное планирова¬
ние влияет или должно влиять на информационные потребности пред¬
приятия. Оно может повлиять на создание модели предприятия, и следу¬
ет обсудить, если это практически оправданно, как предприятие может
изменяться в будущем и какие перед ним могут встать задачи, отличные
от уже существующих.
Некоторые плановики изучают цель и назначение организации и
разбивают их на выполнимые задачи. Дракер [7] считает, что определе¬
ние цели и назначения вынуждает руководство ответить на три сущест¬
венно важных ‘вопроса: Что представляет собой наше производство
(торговля и т. п.)? Каким оно будет? Каким оно должно быть? Эти во¬
просы можно раздробить, исследуя продукцию, рынки, службы сбыта и
внешние связи организации.
«Из определения своей цели и назначения деловое предприятие
должно прийти к задачам в ряде ключевых областей; оно должно сба¬
лансировать эти задачи относительно друг друга и относительно конку¬
рирующих требований сегодняшнего дня и дня завтрашнего» [7].
Задачи должны быть измеримыми, и нужны схемы отчетов, гаран¬
тирующие выполнение этих измерений соответствующими исполнителя¬
ми. Задачи высшего уровня следует разбивать на задачи подразделений.
Чтобы гарантировать их выполнение, задачи нужно четко определить и
перевести на человеческий язык в виде мотивированных инструкций.
КРИТИЧЕСКИЕ ФАКТОРЫ УСПЕХА
В некоторых корпорациях с большим успехом применялся подход,
пропагандируемый Рокартом [8]. Этот подход базируется на том, что
руководитель определяет те факторы, которые он считает наиболее жиз¬
ненно важными для успеха своей организации. Рокарт называет их кри¬
тическими факторами успеха. Определение критических факторов успе¬
ха является ценным методом руководства независимо от того, исполь¬
зуется ли административная информационная система. Впервые этот
вопрос был поднят в литературе Дж. Р. Дэниелом [10], который впо¬
следствии стал директором-распорядителем фирмы McKinsey & Со.
В большинстве корпораций число факторов, существенно важных
для успеха организации, невелико. Высшему руководству следует задать
такой вопрос: «В работе вашей организации есть небольшое количество
аспектов, имеющих первостепенное значение для успешной работы пред¬
приятия. Можете ли вы назвать наиболее решающие факторы успеха?».
34

Президент корпорации обычно находит такой вопрос интересным и
относящимся к делу и, обдумав его, дает хороший ответ.
Дж, Р. Дэниел (директор-распорядитель фирмы McKinsey & Со.):
В большинстве областей промышленности успех дела обычно определяют
от трех до шести факторов, эти ключевые задачи должны решаться чрезвычай¬
но продуманно для того, чтобы компания имела успех [10].
В коммерческом предприятии критические факторы успеха относят¬
ся к тем аспектам делопроизводства, которые обеспечивают конкуренто¬
способность предприятия. В разных типах коммерческих предприятий
эти факторы различны. Они разные и в различное время. Внешняя сре¬
да может изменять критические факторы успеха. Например, нефтяной
кризис изменил эти факторы для автомобильной промышленности. По
мере роста небольшой корпорации необходимо «переключать скорости»
и выделять критические факторы успеха.
Разные руководители могут считать разные факторы критическими
для успеха. Администраторы отличаются по стилю управления и по
своим представлениям относительно перспектив. При смене высшего ру¬
ководства часто приходится изменять административную информацион¬
ную систему.
Приведем некоторые примерные списки критических факторов ус¬
пеха:
Автомобильная промышленность:
Экономия топлива
Оформление внешнего вида
Эффективная организация торговли
Жесткий контроль за стоимостью изготовления
Фирма по производству программного обеспечения:
Новизна продукта
Качество рекламной литературы и литературы для пользователя
Широкий международный сбыт и обслуживание
Простота использования продукта
Корпорация по производству расфасованных пищевых продуктов:
Эффективность рекламы
Хорошее распределение
Новизна продукта
Компания, организующая семинары:
Привлечение лучших докладчиков
Определение тем
Количество адресатов для рассылки информационных материалов
Компания по изготовлению микроэлектроники:
Умение привлекать и удерживать на работе лучших конструкторов
Правительственная поддержка научных исследований
Поддержка торговых посредников
Определение новых потребностей рынка
Компания по страхованию жизни:
Подготовка управляющего персонала
Эффективность рекламы
Производительность конторских операций
Формулировки цели и назначения предприятия часто отличаются от
критических факторов успеха. Первое представляет собой перспективное
развитие корпорации или конечную точку, которой она должна достичь.
Цель может быть сформулирована как «30%-ный годичный рост», «уве¬
личение рыночных акций на 40%», «отличное медицинское обслужива¬
ние» (в больнице) и т. д. Критические факторы успеха относятся к про-
35

ведению текущих операций и* к ключевым областям, в которых надо
достичь наивысших показателей. Эти показатели необходимы для си¬
стемы административного управления. Для успеха организации их нуж¬
но тщательно измерять и держать под административным контролем.
Таким образом, критические факторы успеха должны служить основой
для административной системы управления. Очевидно, определенные
критические факторы успеха являются общими для промышленной об¬
ласти. Это справедливо для большинства факторов из приведенных вы¬
ше списков.
Другие факторы изменяются в зависимости от положения корпора¬
ции в отрасли промышленности. Это может быть новая корпорация, пы¬
тающаяся утвердиться в уже устоявшейся промышленной отрасли.
В этом случае критическим фактором успеха будет создание продукции,
которая воспринимается заказчиками как превышающая по качеству ту,
которая выпускается существующими предприятиями. Это может зави¬
сеть от нахождения дефицита в существующих ассортиментах изделий
или от создания изделий повышенной ценности.
Могут возникать и новые критические факторы успеха. Например,
сливаются две корпорации, и на какое-то время критическим фактором
становится интеграция ассортиментов выпускаемых ими продуктов и тор¬
говых агентов. Или может возникнуть такая проблема: основной про¬
дукт снят с производства в результате конкуренции или из-за того, что
программное обеспечение заслужило плохую репутацию. В таких слу¬
чаях критическим фактором становится выход из этой ситуации.
Иногда появление новых критических факторов успеха вызывается
внешними причинами, такими, как нефтяной кризис, локальные войны,
закрывающие доступ к источникам стратегического сырья, новый кон¬
тракт или последствия нового законодательства.
Часто выбор критических факторов успеха, сделанный главным ру¬
ководящим лицом, не соответствует тому, который сделал бы проекти¬
ровщик информационной системы. Для примера приведем список фак¬
торов, составленный президентом одной из крупнейших нефтяных ком¬
паний [8]:
1)	осуществление организационной децентрализации для расшире¬
ния ассортимента, которое обеспечит более широкую базу на будущие
десятилетия, когда поставки нефти сократятся;
2)	ликвидность (для облегчения приобретений);
3)	отношения с правительством;
4)	репутация в обществе;
5)	успех в новых начинаниях.
ПЕРИОДИЧЕСКИЙ ПЕРЕСМОТР ФАКТОРОВ РУКОВОДЯЩИМ ОРГАНОМ
Изучение критических факторов успеха в Слоановской Школе уп¬
равления [8] показало, что они меняются со временем, со сменой руко¬
водителя и бывают разными для схожих организаций в одной и той же
отрасли промышленности. Поэтому желательно, чтобы эти факторы пе¬
риодически пересматривались высшим руководящим органом или прав¬
лением, например, ежеквартально. Это очень поможет административ¬
ному управлению. Ответственное лицо или группа людей должны перио¬
дически проверять, какие факторы являются наиболее критическими
для успеха и что нужно сделать, чтобы оптимизировать их. Достижение
целей с помощью критических факторов успеха должно быть связано с
вознаграждением или с другим видом поощрения исполнителей.
36

ТИПЫ ИЗМЕРЕНИЙ
Традиционные бухгалтерские системы крайне редко дают те нужные
данные о критических факторах успеха, которые определены высшим
руководством. Иногда производственные системы учета предоставляют
полезные данные, но часто при анализе критических факторов успеха
раскрывается необходимость совершенствования производственного -
учета.
Существенная часть требуемых данных не может поставляться как
побочный продукт обычной обработки данных. Их надо собирать спе¬
циально из других источников. Затем их можно хранить в существую¬
щих вычислительных системах. Некоторые необходимые данные посту¬
пают из внешних источников.
Для многих критических факторов успеха требуются данные из мно¬
жества логических файлов, которые могут быть широко разбросаны:
например, сравнительная прибыльность всех продуктов, предлагаемый
коэффициент прибыльности как показатель прибыльности аналогичных
работ, оценки риска в контрактах за счет изучения опыта аналогичных
ситуаций с заказчиком. Для таких показателей нужны системы баз дан¬
ных и языки систем баз данных высокого уровня, которые могут мани¬
пулировать данными.
Небольшая часть критических факторов успеха требует субъектив¬
ной оценки, их нелегко определить количественно. Высшая администра¬
ция к этому привыкла и уделяет много времени вынесению субъективных
суждений и оценок. Часто можно найти и объективные показатели, но
над этим приходится подумать.
В некоторых случаях размышления о том, как измерять критиче¬
ский фактор успеха, приводят к нескольким различным видам измере¬
ний. Например, одной организации понадобилось измерить свою техно~
логическую репутацию у заказчиков [8]. Было разработано несколько
возможных показателей. Простым численным показателем служило от¬
ношение заявок к полученным заказам. Но на этот показатель влияли
другие факторы, такие, как активность торговых агентов. Индивидуаль¬
ные интервью оказались более расплывчатыми показателями. Для
измерения одного фактора использовали несколько показателей. Было
решено начать административный опрос заказчиков, так как этот фак¬
тор был крайне критичен.
В той же организации критическим фактором успеха считалось
моральное состояние научных работников и инженеров, занимающих
ведущие должности, так как осознавалось значение этих лиц для компа¬
нии. Измерение этого фактора включало такие численные показатели,
как текучесть, невыходы на работу, опоздания, а также впечатления от
неофициальных бесед руководителей со служащими. Иногда прибегают
и к официальным беседам.
Некоторые критические факторы успеха выявили необходимость
создавать новые, часто небольшие, информационные системы. В настоя¬
щее время их можно быстро создать с помощью непроцедурных языков
систем баз данных и легко модифицировать.
СООБЩЕНИЯ О КРИТИЧЕСКИХ ФАКТОРАХ УСПЕХА
Процесс создания административной информационной системы
подобного типа может начаться с разговора руководителя или проекти¬
ровщика ЭОД с главным административным должностным лицом, ко¬
торого просят определить критические факторы успеха так, как он их
37

себе представляет. По опыту Рокарта время, необходимое для обдумы¬
вания ответа, составляет от трех до шести часов.
Затем необходимо разработать средства измерения этих факторов.
Для измерения некоторых факторов существуют только расплывчатые
показатели; однако, как правило, можно найти какой-либо способ по¬
лучения численных показателей. Иногда требуется широкое обсуждение
того, как эти факторы измерять. Бывает так, что данных слишком мно¬
го, и разговор идет о том, как эти данные суммировать.
Затем нужно разработать средства сообщения о результатах. На¬
сколько обобщенной должна быть информация или какова должна быть
степень ее детализации? Существуют мощные и точные средства пред¬
ставления любого сложного набора фактов, подчеркивающие наиболее
важные аспекты данных. Хороший лектор ищет такие средства в схемах,
которыми он пользуется. То же самое делает автор учебника. Создатель
административной информационной системы должен быть искушен в
проектировании наилучших средств представления информации.
КРИТИЧЕСКИЕ ФАКТОРЫ УСПЕХА ДЛЯ РУКОВОДИТЕЛЕЙ
БОЛЕЕ НИЗКОГО УРОВНЯ
Рокарт и его сотрудники добились значительного успеха в проекти¬
ровании информационных систем для высшего административного пер¬
сонала. Это примечательно потому, что большинство других информаци¬
онных систем не отвечало требованиям главного руководителя.
Метод критического фактора успеха полезен также для руководите¬
лей более низкого уровня (т. е. руководства, к которому сходятся отчеты
о множестве функций). Этот метод помогает таким руководителям ре¬
шать, на чем следует заострять внимание. Он обеспечивает их показа¬
телями и системой непрерывного контроля. Независимо от ЭОД, это
ценный метод управления. Ни одному руководителю не стоит жалеть
времени на обдумывание критических факторов успеха.
Когда отчеты о критических факторах успеха используются на мно¬
гих уровнях управления, ими или информационными системами можно
часто пользоваться коллективно. Можно установить порядок коммуни¬
кации и отчетности, а также построить схему критических факторов ус¬
пеха на различных уровнях. Это способствует общему пониманию требо¬
ваний руководства.
ВКЛЮЧЕНИЕ В ПЛАНИРОВАНИЕ ДАННЫХ
Для измерения и контроля достижения целей, анализа задач руко¬
водством и анализа критических факторов успеха как часть стратегиче¬
ского планирования данных должны составляться отчеты. Они должны
включаться в качестве действий в такую подробную схему предприятия,
как на рис. 2.4. Данные из отчетов следует включать в схемы объектов
или схемы объектов-действий, которые мы рассмотрим позднее.
Для анализа критических факторов успеха и анализа задач руко¬
водством необходимо непрерывное участие в работе высшего управлен¬
ческого персонала. Такой анализ, если его тщательно производить, обыч¬
но изменяет постановку задач, мотивировки и компенсацию. Он очень
полезен как для небольших, так и для крупных корпораций. Сами фак¬
торы должны периодически пересматриваться на уровне руководящего
органа.
38

ГЛАВА 3
ОРГАНИЗАЦИЯ
ЦЕНТРАЛИЗОВАННОГО ПЛАНИРОВАНИЯ
ВВЕДЕНИЕ
В последующих главах мы описываем ряд методов, применяемых
для стратегического планирования данных, а именно:
1)	неформальное планирование предметных баз данных;
2)	отображение предметных баз данных на системы;
3)	планирование коммерческих систем ИБМ;
4)	анализ объектов и группировка;
5)	матрицы объектов-действий;
6)	анализ сходства объектов.
Можно применять не один метод, а несколько. Методы могут ис¬
пользоваться как вспомогательные и для проверки друг друга. В гл. 13
рекомендуется процедура проведения стратегического планирования,
которая объединяет методы, используя их наилучшие свойства.
ОРГАНИЗАЦИЯ АНАЛИЗА
Для проведения анализа стратегического планирования нужна со¬
ответствующая организация. Прежде всего необходимо, чтобы работник
ясно представлял себе данную методологию и обладал опытом ее при¬
менения. Когда методология создается по ходу работы, много времени
теряется зря, результаты бывают неудовлетворительными, что, естест¬
венно, отражается на репутации специалистов. Часто в организации нет
людей с опытом применения стратегического планирования данных.
В этом случае требуется помощь приглашенного консультанта, который
должен предложить формальную, опробованную методологию из числа
тех, что описываются в последующих главах, и предпочтительно, чтобы
они опирались на использование ЭВМ.
Управляющий делами фирмы:
Я почувствовал настоятельную необходимость пригласить консультанта,
так как слишком часто свой персонал склонен смотреть на некоторые процессы
с точки зрения того, как они выполнялись ранее или как они выполняются сей¬
час, а не так, как им хотелось бы видеть их в будущем. Консультант, не имею¬
щий шор в виде прошлого опыта компании, способен преодолеть эту проблему.
Не следует целиком передавать планирование консультантам, руко¬
водителем группы планирования должен быть служащий корпорации, и
он должен иметь возможность обновлять план в соответствии с текущи-
39

Руководители отделов
О ьюнечнык пользователей
Рис. <?./. Группа-ядро, состоящая из четы¬
рех человек, под твердым руководством
осуществляет централизованное планирова¬
ние. Для этого ей необходима связь с ру¬
ководителями отделов конечных пользова¬
телей, прошедших соответствующее обу¬
чение
ми событиями после его первоначального составления и принятия. Он
должен научиться применять данную методологию. Мы будем называть
руководителя планировочными работами планировщиком информацион¬
ных ресурсов.
Планирование должно осуществляться небольшой группой-ядром с
твердым руководством. Этой группе потребуется большая помощь со
стороны пользователей в корпорации. Нужно выбрать ответственных
представителей от подразделений
пользователей. Некоторыми из
них должны быть руководители
отделов. Форма их участия в ра¬
боте при разных методологиях
различна. Иногда руководителей
отделов пользователей просто
опрашивают, иногда пользовате¬
лей обучают, как выдавать инфор¬
мацию о своей деятельности. Мы
будем называть этих участников
работы пользователями-аналити¬
ками. На рис. 3.1 показана основ¬
ная группа-ядро и связь с ней ру¬
ководителей отделов конечных
пользователей.
В одной корпорации среднего
размера централизованное плани¬
рование очень эффективно было
выполнено группой, состоящей из
руководителя службы ЭОД, глав¬
ного системного аналитика, фи¬
нансового директора, главного
бухгалтера, директора-распоря¬
дителя и администратора, ответственного за обслуживание заказчиков.
Эту группу обучал и направлял приглашенный консультант.
Когда к работе привлекаются руководители подразделений или ко¬
нечные пользователи, необходимо умение представлять им концепции
на нетехническом языке.
Директор по планированию в корпорации:
Проводились предварительные встречи с руководителями подразделений и
пользователями, чтобы познакомить их с концепцией, а затем консультантом
был проведен семинар, в ходе которого аудитория познакомилась с методоло¬
гией. Этот семинар не имел успеха главным образом потому, что был принят
слишком технический и сложный для данной аудитории подход. Тем не менее,
когда мы стали проводить рабочие семинары с регулярным привлечением поль¬
зователей, проект набрал силу и получил признание. Был определен командный
пункт и назначен координатор. Кроме того, для проекта были выделены два
коммерческих аналитика, чтобы помогать пользователям разбираться в методи¬
ке на формальных семинарах.
ПЛАНИРОВЩИК ИНФОРМАЦИОННЫХ РЕСУРСОВ
Во главе централизованного планирования (сверху вниз) должен
стоять один человек. В некоторых организациях планированием ресур¬
сов данных занимается комитет. Комитет желателен для обзора и об¬
ратной связи, но, как и в администрировании данными, за общий проект
должен отвечать один обладающий властью компетентный человек, имею-
40

щий в своем распоряжении нужные средства и методы. В некоторых слу¬
чаях он несет ответственность только за планирование ресурсов данных,
в других —у него более широкие полномочия по планированию информа¬
ционных систем. Высшее руководство должно прислушиваться к мнению
планировщика информационных ресурсов и ставить свою подпись на его
ПЛАНИРОВАНИЕ
СВЕРХУ ВНИЗ
Планировщик
информационных
ресурсов
^Группа-ядра
по планирооа-
книю данных)
Централизованный
план для файлов
и ваз данных
корпорации
Аналитики- пользователи
ПРОЕКТИРОВАНИЕ
СНИЗУ, ВВЕРХ
администраторы
данных
^комитеты^
конечных поль
^■зователейМ
канонические
модели специфицирован
ных ваз данных [/]
Рис. 3.2. Необходимо, чтобы централизованное планирование, осуществ¬
ляемое планировщиком информационной системы и группой планиро¬
вания данных корпораций, направляло работу по моделированию дан¬
ных, проводимую администраторами данных. Моделирование данных с
применением ЭВМ должно служить целостным дополнением к центра¬
лизованному планированию так, чтобы один процесс дополнял и прове¬
рял другой [3]
планах.’ Там, где этого нет, план часто вызывает острые разногласия и
никогда полностью не реализуется.
На рис. 3.2 показана связь между планированием сверху вниз, осу¬
ществляемым планировщиком информационных ресурсов (как бы он
ни назывался), и детальным планированием снизу вверх, осуществляе¬
мым администратором (администраторами) данных. Планировщику
сверху вниз открыта перспектива всей корпорации, и он решает, какие
базы данных или другие ресурсы данных нужны корпорации. Админн-
41

стратор данных проводит анализ и синтез данных для каждой создавае¬
мой базы данных. Эти вопросы обсуждаются в работе [1]. В обоих слу¬
чаях требуется помощь конечных пользователей, но в разных аспектах.
Планировщику информационных ресурсов нужна помощь от каждой
функциональной области, но не на слишком подробном уровне. Админи¬
стратору данных необходимо, чтобы комитеты пользователей подробно
рассматривали каждую предметную базу данных по очереди с целью
сделать их как можно стабильнее. ‘
Как планировщику информационных ресурсов, так и администрато¬
ру данных требуются вычислительные средства. Существует слишком
много примеров планов и проектов баз данных, выполненных вручную,
которые сделаны грубо, расплывчато, так что их трудно модифициро¬
вать, и которые вследствие этого не отражают реальных потребностей.
Проектировщики, не имеющие вычислительных средств, ищут возможно¬
сти сокращать, там, где на разработку деталей уходит слишком много
времени. Они сопротивляются внесению необходимых изменений в со¬
ставляемые схемы из-за того, что это крайне трудно делать вручную.
Вычислительные средства планирования сверху вниз должны быть
совместимы со средствами проектирования снизу вверх, дополнять и
проверять друг друга. Проекты и тех и других при необходимости дол¬
жны поддаваться обновлению. Много информации для проектирования
снизу вверх будет поступать в качестве побочного продукта в результа¬
те работы над проектом сверху вниз. Ее можно будет подавать в инстру¬
ментарий проектирования, готовый для синтеза снизу вверх.
ВРЕМЕННАЯ ШКАЛА
Планирование сверху вниз должно завершиться за шесть месяцев.
В тех случаях, которые изучались при написании данной книги, боль¬
шинство работ было закончено за шесть месяцев, но только тогда, ког¬
да были определены четкое направление ii твердая методология. При
отсутствии твердой методологии или твердого руководства процессом
попытки осуществления планирования сверху вниз могли длиться гораз¬
до дольше и иногда дискредитировать себя. Из-за непрерывного давле¬
ния, связанного с разработками новых приложений, планирование свер¬
ху вниз следует осуществлять быстро и решительно.
Часто через шесть месяцев оказывается, что работы «завершены на
90% ». Остальные 10% приходятся на неопределенность в отношении эта¬
па, на котором следует остановиться. Однако важно, чтобы полученные
результаты были используемыми после шести месяцев работы, даже если
какие-либо тонкости остаются неясными.
Если детальное моделирование базы данных и процесс проектиро¬
вания откладываются до момента завершения плана сверху вниз и са¬
мо моделирование данных занимает длительное время, запаздывание в
целом может быть настолько велико, что повредит задачам быстрой
разработки приложений.
Некоторые из описанных в этой книге методов позволяют получить
лишь грубый план. Забегая вперед, отметим, что на создание схемы,
приведенной на рис. 4.3, уходит всего несколько недель. Она не совер¬
шенна, но обеспечивает довольно хорошее представление, позволяю¬
щее разбить усилия, направленные на моделирование данных, на от¬
дельные выполнимые проекты.
Там, где это осуществлялось с помощью хороших средств и четко
определенной методологии, планирование с высокой степенью разре¬
шения, такое, как описано в гл. 8, было завершено за шесть месяцев
42

(в небольших корпорациях — за более короткий срок). Конечные резуль¬
таты планирования с высокой степенью разрешения намного превосхо¬
дят результаты планирования с низкой степенью разрешения. Некото¬
рые попытки такого планирования были напрасной тратой времени, так
как они не обеспечивали достаточного руководства для детальной реа¬
лизации.
Иногда стараются решить слишком много вопросов при планирова¬
нии сверху вниз. Это может привести к тому, что составление общего
плана не завершится в разумных пределах времени. Группе планирова¬
ния сверху вниз не следует нормализовывать записи или спорить об
определениях атрибутов. Когда это происходит, процесс застревает в об¬
суждении подробностей.
РАЗРАБОТКА МОДЕЛИ ПРЕДПРИЯТИЯ
Первый шаг— это разработка модели предприятия. Она может
происходить в три этапа, каждый из которых будет повышать уровень
детализации, а именно:
1)	разработка модели, показывающей функциональные области
предприятия;
2)	расширение модели с включением процессов;
3)	расширение модели с включением действий.
Во всех описываемых далее методологиях используются функцио¬
нальные области и процессы. Действия используются не всегда. В этом
случае третий этап опускается.
Первый этап — идентификация функциональных областей в корпо¬
рации— может проходить быстро. К этой работе должны быть привле¬
чены руководители подразделений или группа руководителей, которые
знают корпорацию в целом. Следует обсудить, как могут измениться
функции корпорации в будущем или как они должны измениться.
'			/

Интервьюер:
Считаете ли вы, что число предметных баз данных или типы предметных
баз данных изменятся очень сильно?	'
Ответственный за планирование:
Я думаю, что их может быть больше, хотя бы потому, что мы предпола¬
гаем стать чем-то большим, чем банк.
Интервьюер:	•
Другими словами, меняются основные функции?
Ответственный за планирование:
Да.
Следует задать такие вопросы:
•	■Каковы перспективные задачи предприятия?
•	Какие изменения планируются или являются вероятными?
•	Охватывает ли созданная функциональная модель эти задачи и
будущие изменения?
Функциональную модель можно представить в виде блок-схемы,
каждый блок которой соответствует одной из главных функциональных
областей предприятия. Стрелки между блоками могут показывать под¬
чиненность или жизненный цикл продуктов, служб или ресурсов. У раз¬
личных типов организаций различные’пути представления своей функ¬
циональной модели.
43

ГРАНИЦЫ АНАЛИЗА
Когда функции предприятия схематизированы, надо решить вопрос
об объеме или границах централизованного плана.
В небольшом или довольно цельном предприятии анализ должен
охватить всю организацию. В организации, состоящей из множества
объединений, он может охватывать объединения поочередно. В одной
гигантской аэрокосмической корпорации первыми были исследованы
космическое и ракетное подразделения, чрезвычайно сложные по со¬
ставу.
Если объем планирования сверху вниз слишком велик и охватывает
отдельные организации, то может оказаться затруднительным осу¬
ществление контроля и получение результатов вовремя, чтобы это мог¬
ло повлиять на разработку базы данных. С другой стороны, если объем
слишком мал, преимущества планирования сверху вниз будут частично
потеряны. Если информационные ресурсы влекут за собой сложное вза¬
имодействие нескольких подразделений, исследование сверху вниз,
ограничившееся только одним из подразделений, может не дать адек¬
ватного основания для построения требуемых информационных систем.
Широта стратегического планирования должна отражать стиль ру¬
ководства корпорации. В некоторых корпорациях подразделения дейст¬
вительно разделены и автономны, в других — нет. Управление одинако¬
выми по размеру фирмами в одной и той же области промышленности
часто строится совершенно по-разному. Например, в одной крупной
страховой компании есть три отделения с самостоятельным управлением
и раздельной обработкой данных. Для каждого такого отделения пла¬
нирование сверху вниз можно проводить отдельно. Другая корпорация
имеет централизованное управление, и план сверху вниз там должен ох¬
ватывать все подразделения.
Чтобы решить проблему границ плана сверху вниз, следует задать
такой вопрос: могут ли структуры данных, проектируемые для исследуе¬
мой области, использоваться в другой области или зависеть от нее? Если
ответ положительный, то эта другая область должна быть охвачена
планом. В ином случае границы плана не следует делать излишне ши¬
рокими.
ОПРЕДЕЛЕНИЕ ПРОЦЕССОВ
Когда модель функциональных областей предприятия составлена,
можно рассмотреть каждую функциональную область и определить про¬
цессы, используемые в ней. Результаты такого анализа составляют три
.первых уровня в схеме предприятия, представленной на рис. 2.4.
Идентификацию процессов лучше поручать представителям каж¬
дой функциональной области. Чтобы показать им, что требуется сде¬
лать, можно нарисовать предполагаемый ряд процессов. Такой предва¬
рительный список затем обсуждается и уточняется представителями
функциональных областей, пока не будет определен согласованный на¬
бор процессов.
Когда процессы рассмотрены для каждой функциональной области
отдельно, их можно сгруппировать в том виде, какой представлен на
рис. 2.4 (но пока без действий). Иногда на этой стадии выявляются
отклонения и противоречия. Такие межфункциональные расхождения
разрешают на совместной встрече представителей соответствующих об¬
ластей. Затем вся схема может быть представлена на рассмотрение выс¬
Ш °^' Р УКОВОДС ^в у.
44

В некоторых корпорациях выполнение уже описанных этапов заня¬
ло около месяца. Рассматриваемые в последующих главах методологии
значительно отличаются друг от друга, но все они строятся на фунда¬
менте функциональных областей и процессов.
СТЕПЕНЬ РАЗРЕШЕНИЯ
Как мы уже говорили, планирование сверху вниз может быть вы¬
полнено укрупненно или детализированно. В укрупненной версии описы¬
ваются функциональные области и процессы, но не действия (или са¬
мые глубинные элементы рис. 2.4). В них описываются, скорее, предмет¬
ные базы данных, чем объекты, из которых эти базы данных состоят.
Таким образом, мы имеем уровни разрешения планирования сверху
вниз, показанные на рис. 3.3.
—^^Операции
Данные	*—
Низкая степень
разрешения:
процессы
Высокая степень
разрешения:
действия
Низкая степень разрешения:
предметные базы данных
Высокая степень разрешения:
объекты
Гл. 4 и 5
Гл. 7
Гл. 8
Рис. 3.3. Планирование сверху вниз можно выполнить с низкой или высокой степенью
разрешения как в отношении данных, так и в отношении операций. В следующих гла¬
вах описываются методологии, обладающие различной степенью разрешения
В гл. 4 и 5 описывается грубое планирование с предметными база¬
ми данных и процессами. В гл. 7 описано более тонкое планирование с
объектами (предметами, данные о которых мы храним) и процессами.
В гл. 8 рассматривается еще более тонкое планирование с объектами и
действиями. Объекты обсуждаются в гл. 7, а действия — в гл. 8.
В большинстве изученных случаев время, затраченное на планиро¬
вание с более высокой степенью разрешения ненамного превышало вре¬
мя, затраченное на грубое планирование, если, конечно, при этом при¬
менялись вычислительные средства и оказывалась соответствующая
помощь со стороны пользователей. Более тонкое планирование служит
гораздо лучшим руководством для проектирования и внедрения систем
баз данных. Тем не менее важно, чтобы планирование сверху вниз оста¬
валось обзорным, выполнялось довольно быстро и не задерживалось на
деталях определения атрибутов данных и моделирования. Детальное
моделирование данных является важным процессом, но оно осуществ¬
ляется позже и обычно по частям.
ОПРЕДЕЛЕНИЕ ОБЪЕКТОВ И ДЕЙСТВИИ
Как только достигается согласие в определении функций и процес¬
сов, можно обращаться к отделу или группе, выполняющим каждый из
процессов, с целью определения объектов, данные о которых хранятся,
а возможно также и действий, с которыми ассоциируется каждый объ¬
ект. Затем группа-ядро планирования составляет более подробную
модель.
Хороший способ организовать работу — научить заинтересованных
конечных пользователей в различных областях предприятия идентифи¬
цировать действия и объекты. Вместе с пользователями над определе¬
нием действий могут продолжать работать аналитики, определявшие
процессы на предыдущем этапе.
45

По мере составления модели предприятия, представленной на
рис. 2.4, часть ее, относящуюся к каждой функциональной области,
можно для проверки отдавать в эту область.
ФИЛИАЛЫ КОРПОРАЦИЙ
Некоторые корпорации имеют множество филиалов. Если это неод¬
нородные предприятия, они могут иметь совершенно различную струк¬
туру. Если это отделения (например, иностранные филиалы), они могут
быть аналогичны по структуре. Желательно, когда это практически осу¬
ществимо, чтобы базы данных филиалов были хотя бы частично совме¬
стимыми с базами данных в основной корпорации.
Когда методология стратегического проектирования применяется
впервые, она обычно осуществляется сначала в одной корпорации, под¬
разделении или предприятии. Группа, реализующая эту методологию,
должна познакомиться с ней, приобрести опыт, а затем ее легко рас¬
пространить на другие части организации, что должно проводиться в
соответствии с указаниями высшего руководства. Иногда филиалы или
предприятия крупной корпорации могут воспользоваться теми же типами
предметных баз данных, охватывающими аналогичные объекты.
Администрация должна следить за общей разработкой приложений.
В какой степени приложение, разработанное в одном месте, может быть
использовано в других местах? Ответить на этот вопрос может помочь
изучение составленных сверху вниз планов баз данных, если они разра¬
ботаны достаточно детально.
Руководитель ЭОД:
Во многих странах ведутся международные операции. Они моделируются
по отечественному образцу, но все имеют свои особенности. Мы пришли к вы¬
воду, что анализ объектов, выполненный у нас в стране, и супергруппы можно
в основном переносить за границу, если мы согласны с тем, что необходимо
какое-то время для преодоления локальных затруднений. На уровне детального
моделирования эти трудности гораздо серьезнее, поэтому в каждой стране соз¬
дается своя модель. Однако идентичный метод документирования и построения
моделей позволяет главной конторе определить, где общая разработка прило¬
жений может оказаться полезной и реальной.
АНАЛИЗ
В разных методологиях создаются разные общие схемы. Примеры
таких схем приведены на рис. 2.4, 4.3, 5.6, 6.6 и 7.9. Необходимо, чтобы
участники и руководители различных функциональных областей тща¬
тельно их анализировали, причем не только в той области, к которой
каждый имеет непосредственное отношение. Это должен быть критиче¬
ский анализ с изложением мнений и замечаний.
Нужно, чтобы каждый проанализировал все функциональные обла¬
сти схемы, а затем занялся бы разработкой деталей в тех областях, с
которыми он знаком. Один человек не может разбираться во всех дета¬
лях каждой функциональной области.
Этот предварительный процесс анализа схемы и ее усовершенство¬
вания является критическим. Схему не следует «замораживать» прежде¬
временно. Она должна быть достаточно точной, чтобы ею можно было
руководствоваться в процессе детального проектирования системы и
базы данных. Вполне вероятно, что она будет уточняться неоднократно
и поэтому ее следует компьютеризовать.
46

ПРЕДМЕТНЫЕ БАЗЫ ДАННЫХ
ВВЕДЕНИЕ
Оглядываясь назад, на историю развития баз данных, мы видим два
подхода: прикладные базы данных и предметные. Совершенно ясно,
какой из них в конечном счете привел к наилучшим результатам, это —
предметные базы данных.
Предметные базы данных соотносятся, скорее, с предметами орга¬
низации, а не с обычными вычислительными приложениями. Например,
должна быть база данных продукта, а не отдельные базы данных инвен¬
тарного учета, поступления заказов и контроля качества, которые отно¬
сятся к этому продукту. Тогда для многих приложений смогут пользо¬
ваться одной и той же базой данных.
Обработку данных в целом можно рассматривать как последова¬
тельность изменений, производимых с данными. Мгновенный снимок
системы или организации покажет только структуру данных. Процесс
технически заключается в последовательности изменений данных, вклю¬
чая данные, находящиеся в рабочей памяти, а также входные-выходные
данные.
Проектирование стабильной, хорошо документированной и в основ¬
ном неизбыточной структуры данных в конечном счете обеспечивает
более простую и ясную форму обработки данных, чем вложение отдель¬
но проектируемых данных в сотни процессов. Еще больше упрощает
обработку данных применение непосредственно к структурам данных
контроля целостности и решающи«х таблиц, чтобы эти данные были при¬
годны для множества процессов.
Одной из задач планирования сверху вниз должно быть определе¬
ние требуемых предметных баз данных. Типичными предметами, для
которых строятся базы данных, являются:
продукты,
заказчики,
детали,
поставщики,
заказы,
счета,
персонал,
документы,
технические описания.
Некоторые приложения пользуются не одной базой данных. Про¬
граммы вызывают многие отдельные базы данных. Например:
47

ВЫПИСКА
СЧЕТОВ-ФАКТУР
СЧЕТА КРЕДИТОРОВ
приобретение:
УПРАВЛЕНИЕ
ЗАПАСАМИ
ПРЕДМЕТНЫЕ БАЗЫ ДАННЫХ
•	Продукт bi
•	Заказчики
•	Детали
•	Поставщики
•	Заказы
•	Счета
•	Персонал
•	Документы
•	технические описании
ПРЕДМЕТНЫЕ БАЗЫ ДАННЫХ
•	Продукты
•	Заказчики
•	Детали
•	Поставщики
•	Заказы
•	Счета
•	Персонал
•	Документы
•	Технические описание
ПРЕИМУЩЕСТВА ПРЕДМЕТНЫХ БАЗ ДАННЫХ
Целью проектирования предметной базы данных является ускоре¬
ние разработки приложений. Данные, которыми пользуются программи¬
сты, должны уже существовать в предметных базах данных. Разделы
данных в программе или описание данных должны генерироваться ав¬
томатически. Во многих случаях следует использовать не языки про-
Число предметных ваз данных
граммирования типа Кобол, а генерато¬
ры отчетов, языки запросов или средства
разработки приложений высокого уровня.
По мере внедрения все большего чис¬
ла предметных баз данных скорость раз¬
работки приложений в хорошо налажен¬
ных вычислительных центрах возрастает,
о чем свидетельствует рис. 4.1. Когда
возникают новые приложения, данные
уже существуют, хотя, возможно, к ним
Рис. 4.1. По мере роста числа предметных баз дан¬
ных резко возрастает число приложений. Можно
быстрее создавать новые приложения, так как
уже имеются данные и программное обеспечение
для манипулирования ими. Кривая на рисунке
взята для корпорации, имеющей пятилетний опыт
разработки предметных баз данных
будут добавляться поля атрибутов. Разработку новых приложений
часто можно осуществлять очень быстро с помощью языков систем баз
данных высокого уровня, генераторов отчетов и генераторов приложе¬
ний [4].
Администратор базы данных:
Когда я посмотрел на развитие группировок предметных баз данных, я
поразился, как одни и те же данные использовались для многих процессов.
Управление денежными операциями, когда мы их вводили, было новой потреб¬
ностью, но для него использовались в большей степени те данные, которые уже
существовали в банковском деле многие годы. Представив их в виде базы дан¬
ных и обеспечив доступ к ним, мы смогли обслуживать наши группы, занимаю¬
щиеся банковскими операциями с широкой клиентурой, корпоративными бан¬
ковскими делами и международными банковскими операциями.
48

Планирование сверху вниз должно разбить всю громаду данных
предприятия на управляемые единицы — предметные базы данных.
Одна или несколько предметных баз данных могут быть взяты под
контроль одним из руководителей. Для детального поочередного моде¬
лирования предметных баз данных можно применять методы и средства
анализа данных [1].
Предметные базы данных следует проектировать так, чтобы они
были как можно стабильнее. Они обеспечивают долгосрочную стабиль¬
ность информационных ресурсов предприятия. «Стабильность» не озна¬
чает, что они никогда не изменяются, под ней подразумевается, что
большинство изменений будет носить такой характер, что их можно
осуществлять без вынужденного переписывания старых приложений.
Логические структуры, создаваемые в результате такого процесса, не
зависят от их физической реализации на современных аппаратных сред¬
ствах и от программного обеспечения. В то время как технология будет
меняться, логические структуры предметных баз данных останутся жиз¬
неспособными.
ВЫБОР ПРЕДМЕТНЫХ БАЗ ДАННЫХ
Предметные базы данных называют классами данных. В большин¬
стве установок их содержимое выбиралось без применения какой-либо
формальной методологии. Записи, относящиеся к заказчикам, находят¬
ся в базе данных заказчиков; записи, относящиеся к продуктам, нахо¬
дятся в базе данных продуктов, и т. д. Звучит это просто, но застав¬
ляет задуматься о том, какие предметные базы данных должны сущест¬
вовать и какие данные к ним относятся. Должны ли заказы покупателя
находиться в базе данных поставщика, а может быть, в базе данных
материалов? В гл. 7 и 8 мы рассмотрим два более формальных метода
объединения объектов в логические базы данных. Получаемые в резуль¬
тате группы называются супергруппами объектов, и они выполняют ту
же функцию, что и предметные базы данных, описываемые в этой главе.
Относительно простая корпорация может иметь до 20 предметных баз
данных, а сложная — 60.
Для выявления предметных баз данных планирующая группа дол¬
жна рассматривать их с двух точек зрения и проводить перекрестную
проверку результатов.
Сначала перечислим основные элементы (изделия, фирмы и т. п.),
с которыми корпорация имеет дело:
детали,
оборудование,
материал,
постройки,
поставщик,
классовая наличность
агрегаты,
счета,
незавершенное производство,
держатели акций,
’	продукция,
персонал
заказчики,
и т. д.
торговые агенты,
Для каждого из этих элементов списка могут существовать базо¬
вые записи, записи запасов, транзакции, суммарные или статистические
данные и данные планирования или проектирования. Эти типы данных
могут включать каждый элемент. Их можно обдумать и записать в виде
последовательности жизненного цикла, показанной на рис. 2.2.:
планирование — приобретение — обслуживание — реализация
49

Так, для материалов:
Материалы: планирование материалов, списки материалов, стоимость, заказы на при¬
обретение, запасы, расходы, статистика употребления.
Это выполняется для каждого основного изделия или фирмы и данные
группируются в классы связанных данных.
Второй подход—взять список процессов (рис. 2.1) и записать, ка¬
кой класс данных используется как вход и выход в каждом процессе.
Такой список классов данных сверяют с приведенным здесь списком и
получают объединенную группировку классов данных.
ПЕРСПЕКТИВА НА ВЫСОКОМ УРОВНЕ
Чтобы определять, какие базы данных нужны организации, необ¬
ходимо знать перспективу развития корпорации. При таком централи¬
зованном планировании следует учитывать не только предметные базы
данных, но и уже существующие, а также новые файлы и автономные
базы данных, предназначенные для определенных приложений. Это
является частью планирования сверху вниз или стратегического плани¬
рования. Детальное проектирование и моделирование элементов данных
и записей, что составляют предметную базу данных (или для другого
случая — прикладную базу данных), представляет собой проектирова¬
ние снизу вверх, которое подробно описано в работе [1].
Многие корпорации обнаружили, что база данных, реализованная
для одного процесса, может обслуживать и другой процесс или другую
область в организации. Такие открытия не должны быть случайными.
Они должны планироваться. Если они не планируются, то часто их и не
бывает, так как различные области стремятся к обособлению, оберега¬
ют свои собственные данные и избегают всего, «что не изобретено
здесь».
Администратор базы данных:
База данных профиля заказчиков была внедрена сначала для внутренне¬
го применения в отделе операций. Вдруг ее оценили за предоставляемую инфор¬
мацию в коммерческом отделе и отделе розничной торговли.
Аналогично, когда мы реализовали базу данных текущих счетов для конт¬
роля и регулирования денежных операций в головной конторе, мы обнаружили,
что ее структура может также служить для всей сети филиалов.
Если предметные базы данных создаются быстро, кривая на рис. 4.1
может резко подниматься, особенно при наличии современных высоко¬
уровневых языков систем баз данных [4]. По мере роста кривой разра¬
боткой приложений как бы движет база данных, а не потребность в
обычном системном анализе.
ПЛАН БАЗЫ ДАННЫХ БАНКА
В одном из крупных банков план составлялся с учетом включения
баз данных, показанных на рис. 4.2. При наличии 21 базы данных теоре¬
тически можно производить почти всю обработку данных в этой орга¬
низации.
50

Схема, приведенная на рис. 4.3, отображает базы данных для основ¬
ных банковских процессов. Предполагалось, что это главный план раз¬
работки баз данных. Слева перечисляются процессы, относящиеся к
прохождению продукта, обработке транзакций и простым запросам. Они
представляют собой довольно простые случаи применения баз данных.
Справа показаны, скорее, информациок*
Предметные
базы данных
Сводка активов и пассивов
Чеки, дебет и кредит
Депозитные сертификаты
Коммерческий кредит
Неуплаченная сумма кредитов
Профиль клиента
Депозиты до востребования
Д^^Ф^бухгалтерСКОг^У^
индивидуальньш заем
Срочные депозит bi
Финансы денежного рынка
Управление кадрами
Сохранный учет
Траст

Поддержка систем
Бюджетный контроль
Производственный учет
Службы калькуляции ■
Графики

Сервис
ные системы, а не производственные.
Они требуют более сложного обслужи¬
вания со стороны баз данных. Как толь¬
ко базы данных будут разработаны и по¬
явятся соответствующие языки запросов,
возникнут новые типы запросов и гене¬
рирования отчетов. Некоторые из них бу¬
дут иметь большое значение для общего
руководства банков.
Данные слева выбираются с помощью
первичных ключей, справа — большую
часть времени с помощью вторичных клю¬
чей.
Эта схема представляет собой карти¬
ну необходимых для эффективного управ¬
ления организацией данных сверху вниз.
Крестиками показано, какие банковские
процессы и действия, влияющие на выне¬
сение решений, используют те или иные
базы данных.
До выполнения планирования, пред¬
ставленного на рис. 4.3, банк реализовал
одну базу данных, включающую инфор¬
мацию о клиентах — фамилии, адреса и
Рис. 4.2. При наличии 21 базы данных можно бы¬
ло бы выполнять большую часть обработки дан¬
ных в крупном банке. На рис. 4.3 показан центра¬
лизованный план, отображающий эти базы дан¬
ных на случаи их перспективного использования
профессии. Как только обнаружили, что эта база данных оказалась по¬
лезной для приложений из многих областей, было решено рассмотреть,
какие другие базы данных могли бы широко использоваться в орга¬
низации.
Интервьюер:
Для составления такой схемы нужно было очень хорошо знать, как рабо¬
тает весь банк. Была ли у вас группа людей, которая квалифицированно разби¬
ралась в каждой операции, производимой банком?
Администратор базы данных банка:
Схему составлял один человек. Он обладал достаточными познаниями в
области банковского дела, пользовался справочником банковского служащего и
беседовал со многими людьми. Эту схему надо было выверить. В нее были
включены все банковские процессы. Таким образом, этот специалист идентифи¬
цировал деловые процессы, происходящие в банке, и то, как эти процессы «об¬
ращаются» с одинаковыми типами данных. Затем он взглянул с точки зрения
операций на следующую размерность, которая составляла одно из средств под¬
держки принятия решений.
51

Во время написания баз данных заштрихованные участки на
рис. 4.2 уже были реализованы и рассматривались как кандидаты на
внедрение. Реализация некоторых других ожидалась, а остальные, как,
например, производственный учет, могли остаться набором отдельных
физических файлов.
Желательно по возможности «нарезать» план большой базы данных
на отдельные куски, так их легче реализовывать. На рис. 4.2 база дан¬
ных траста отделена от других. Ее использование как бы составляет
отдельное занятие внутри банка. Фактически законодательство не до¬
пускает, чтобы в основной части банка видели, чем занимается траст,
и наоборот.
Во многих корпорациях предметные базы данных со временем на¬
шли использование в других прикладных областях, помимо тех, для ко¬
торых они первоначально предназначались. Например, банковская си¬
стема США в 70-х годах ощутила потребность в службе контроля и
регулирования денежных операций. Необходимость в этой службе воз¬
никает в результате того, что крупные корпоративные клиенты имеют
много счетов: текущие счета, счета процентов, срочные депозитные счета
и счета основного капитала. Клиент имеет разные адреса и счета в раз¬
ных отделениях банка. Составление отчетов для клиентов, в которых
эти счета суммируются и где говорится, какая кассовая наличность
имеется в целом и какая будет в будущем, является важным видом об¬
служивания. Банку эта информация о его клиентах также нужна. Это
составляет приложение службы контроля и регулирования денежных
операций.
Администратор базы данных банка:
Контроль и регулирование денежных операций является средством опера¬
тивного представления сложной картины, отражающей положение клиента. Мы
пользуемся им, чтобы принимать решения в отношении кредитования клиента и
определять время, когда в определенных обстоятельствах надо производить кли¬
ринговый расчет. В то же время это критическая сторона обслуживания нашего
клиента. Мы можем сообщать информацию, позволяющую ему контролировать
свой портфель наличных денег. Для некоторых корпораций это стало очень
важным.
Для контроля и регулирования денежных операций используются
следующие базы данных, указанные на рис. 4.2, — чеки, дебет и кредит;
коммерческий кредит; профиль клиента и депозиты до востребования.
Администратор базы данных банка:
Процесс контроля и регулирования денежных операций развивался стабиль¬
но. Оказалось, что больше и больше отделов банка проявляли заинтересован¬
ность в нем и у них возникали новые требования с прикладной точки зрения.
Начальная реализация заняла несколько месяцев. Мы смогли внедрить базу
данных депозиты до востребования через шесть месяцев с небольшим, а ком¬
мерческий кредит за шесть месяцев. По мере развития возможностей системы
контроля и регулирования денежных операций мы смогли продемонстрировать
ее связи с общим кредитом и счетами до востребования. Они были реализованы
за гораздо более короткий срок, чем при обычной файловой системе.
52

до»#* охлодоОдр
ndidTdddTTr/Hpddnn^
	jadpo/ны*
нынатлш^^
ипПоонаино*
pop^oto родаоац
л/Мжгзуо лп^доннод мымоолоонл я^ад^
ncdodduo модоямод шннэдлоэьало мадощ
_^ ^;^^
олойодо сэр pondi ng ар dпаз* ад
godaonp anHDgdodddu^
онэо* эд р/Ррdadол р^нноролиаЬн^
рог ос Элинор э/онла^;
9 Л о*з и
оспру
*о*пг,со*ос до 13*0 Охопи f яд
влнжонсон огоняиоппаид
/Qi3*ao^ апннаП1^нд
О
^
/ w/vgndu ) 1 анероид
7>пЯоР7элнл*ро"1^
gddomgap оланэ
алнодораолоод op лпсоиэу
sogjaocfj
ja*fi п/яннэдлэродспоои
Щш?^^^
(91О*ПрНП0
bniOOhfi
	нпиоинон^ гнпрнох
лгонЛд о^ э/дндиодада^
/QioxndOnidaa aiQHincoua^
Dido* UDQOiapw
niq^HPhdUOdQQ
giQNMah аиоадоэч
inpad* п^ааадо^росод пхоапплонолду
		дюонп^пдрач
				a j
зОсгоО л дооодол ппнодонао он
нлп а гл он л о а пн ол нарноноаУйо*
аллоом
%
X
3
5
		ялоокплнпдран
пнпэро а/ян*оОр
	ZZIJ^!^
(п/яннаьаиоадоан) эоаир
~^лна* аи^адо зон знал о woody
iqpdda annddaxodg
_	gMo^1№P_Jw^^
апндн/poMj
эпнодорбоодо л n^go^ojo*
Tddddiw drwal/gdd^
dn Л/ ^>4 j /ял о и и tog diqHqudTnHk/ouoy
^1эойорад^ьой^э^
19дигбио annHadi^nd

Продолжение рис. 4.3

В некоторых банках данные, необходимые для контроля и регули¬
рования денежных операций, уже имелись в нескольких ранее сущест¬
вовавших базах данных. В других банках желание наладить управле¬
ние денежными операциями послужило стимулом для развития техноло¬
гии баз данных, а базы данных, созданные для этого, оказались полез¬
ными для целой сети отделений банка. В одном банке была внедрена
оперативная система для проверки счетов филиалов, пользующаяся ба¬
зой данных контроля и регулирования денежных операций. Аналогич¬
ным образом база данных профиля клиента, предназначаемая для обслу¬
живания отдела внутренних операций, стала позднее неоценимой для
предоставления информации отделам организации, занимающимся ком¬
мерцией и розничной торговлей, а также для идентификации взаимоза¬
висимости счетов при контроле и регулировании денежных операций.
Когда происходят непредусмотренные превращения, возникают про¬
блемы, связанные с преобразованием баз данных, и другие растущие
затруднения. Назначение такой схемы, как на рис. 4.3, — предусмотреть
области, в которых предметные базы данных будут или должны исполь¬
зоваться. Затем в процессе автоматического моделирования данных мо¬
гут быть учтены потребности этих областей. Важно, чтобы в создании
и уточнении такого плана, как рис. 4.3, принимали участие руководите¬
ли отделов. Результат этого плана будет сказываться по мере его реали¬
зации на управлении организацией.
Администратор базы данных: .
Необходимо, чтобы в создании плана принимали участие административные
руководители организации.
Интервьюер:
Руководители какого типа?
Администратор базы данных:
Несомненно те, кто участвует в операционных процессах направления. Кро¬
ме того, существует настоятельная необходимость в участии людей, занятых кор¬
поративным планированием и вовлеченных в процесс контроля и регулирования
актива и пассива компании. В конечном счете наибольшая польза от информа¬
ционных служб скажется на планировании, анализе, определении продукта, оп¬
ределении рынка и в фактическом обосновании принятия решений.
Во множестве случаев бизнес развивается и захватывает новые об¬
ласти. Важно, чтобы руководители, которые могут это предусмотреть,
привлекались к планированию развития информационных ресурсов
сверху вниз.
Интервьюер относительно схемы, приведенной на рис. 4.3:
Считаете ли вы, что действительно определили те предметные базы данных,
которые вам необходимы для управления работой большого банка?
Администратор базы данных, принимавший участие в разработке схемы,
приведенной на рис. 4.3:
Так как эта банковская холдинг-компания занимается вопросами своего
будущего развития, вероятно, возникнут другие группы баз данных. Некоторые
из них могут быть распределенными.
Интервьюер:
Это фактически означает, что вы хотите, чтобы комитет, организованный
на высшем уровне, пересматривал схему, модернизируя ее я принимая решения
о распределенном использовании.
Администратор базы данных:	• *
Да, это важно. И существенно необходимо, чтобы в данном процессе при¬
нимала участие дирекция.
55

СОПРОТИВЛЕНИЕ ПЛАНУ
Такой план, как на рис. 4.3, почти обязательно вызовет сопротивле¬
ние, если только не будет очевидной поддержка его высшим руковод¬
ством. Если такая поддержка не будет оказана с самого начала, план
неизбежно вызовет столкновения и споры, и, вероятно, будет осуществ¬
лена та часть его, которая окажется недостаточной для перехода от
обычного системного анализа к информационной технологии.
Интервьюер:
Оглядываясь на свой трехлетний опыт использования этого плана, какой
совет вы бы дали тем, кто начинает создавать план баз данных сверху вниз?
Администратор базы данных:
Для осуществления задуманного действительно необходима поддержка
высшего руководства. В начале этой работы мы столкнулись с большим сопро¬
тивлением как изнутри, в отделе ЭОД, так и извне.
Сопротивление отдела ЭОД было вызвано тем, что ранее, особенно при ис¬
пользовании систем, ориентированных на магнитные ленты, он осуществлял пол¬
ный контроль над любыми разработанными им приложениями.
Сопротивление извне, в отделах пользователей, было вызвано желанием
обладать исключительным правом на свои собственные данные. Пользователи
считали, что базы данных отберут у них эти права.
Интервьюер:
Итак, вы говорите, что надо представить подробный план высшему руко¬
водству и получить его поддержку?
Администратор базы данных:
Более того. Получите поддержку до того, как план создан. Привлеките ру¬
ководство к созданию плана. Убедитесь, что оно понимает план, верит в него
и заявляет об этом громко и ясно, чтобы руководители низшего уровня не вы¬
ступали против плана.
ЧЕТЫРЕ КЛАССА СРЕДЫ ДАННЫХ
Существует четыре класса среды автоматизированных данных.
Важно четко их различать. Вставка 4.1 суммирует эти четыре класса
среды. Они влияют на управление на предприятии на всех уровнях,
включая высшее руководство. Чтобы добиться эффективных результа¬
тов, корпорация должна иметь солидный фундамент в виде данных III
и IV классов. Однако данные будут всепроникающими и успешными,
только если их поддержит высшее руководство.
СРЕДА I КЛАССА: ФАЙЛЫ
Средой I класса являются файлы. Отдельный файл предназнача¬
ется для каждого приложения или для большинства из них. Часто пря¬
мой результат структурного анализа заключается в том, что данные
вкладываются в функцию. Это создает серьезные проблемы в ведении
данных и делает использование их менее гибким. Среда баз данных
«пытается разрешить» эти проблемы путем отделения данных от при¬
ложений, чтобы добиться их независимости. В вставке 4.2 приводятся
проблемы, типичные для старых, признанных файловых установок. Эти
проблемы можно разрешить с помощью хорошего программного обес¬
печения баз данных в сочетании с умным проектом и управлением (что
часто отсутствует) [1].
56

Вставка 4.1. Четыре класса среды данных
Среда 1 класса: файлы
Система управления базой данных не используется. Отдельные файлы дан¬
ных применяются для большинства приложений, проектируемых аналитиками и
программистами, когда создается приложение.
Примеры программного обеспечения:	■
VSAM, BDAM, RMS.
Характеристики
Простые. Относительно легко реализовать. Число файлов быстро возрастает
при высоком уровне дублирования, что приводит к большим издержкам ведения
файлов.
Кажущиеся тривиальными изменения в приложениях вызывают цепную
реакцию других изменений, поэтому каждое изменение становится медленным,
дорогим и вызывает сопротивление.
Среда П класса: прикладные базы данных
Система управления базой данных используется, но не в той степени раз¬
деленного режима, которая присуща среде III класса. Отдельные базы данных
предназначаются для отдельных приложений.
Примеры программного обеспечения:
TOTAL, IMS, IDMS, IDS.
Характеристики
Легче реализуются, чем среда III класса. Число баз данных быстро растет,
приводя к высокому уровню дублирования, как и в файловой среде. Стоимость
ведения высокая.
Иногда дороже, чем среда I класса. Не достигаются основные преимущест¬
ва работы баз данных. е
Среда HI класса: предметные базы данных
Создаются базы данных, которые в основном не зависят от специфических
приложений. Данные проектируются и хранятся независимо от той функции,
для которой они используются. Данные для таких предметов предприятия, как
клиенты, продукты или кадры, ассоциируются и представляются в базах данных
коллективного пользования.
Примеры программного обеспечения:
IMS, IDMS, IDS, ADABAS.
Характеристики
Требуются тщательный анализ данных и моделирование, занимающие мно¬
го времени. Гораздо меньшая стоимость ведения.
Приводит в результате (но не мгновенно) к более быстрой разработке при¬
ложений и непосредственному взаимодействию пользователя с базами данных.
Требует изменения в традиционных методах системного анализа и в общем
управлении ЭОД.
При отсутствии хорошего управления может перейти в среду II класса (или
иногда I класса).
Среда IV класса: информационно-поисковые системы ■
Базы данных организуются для поиска и быстрой выборки информации,
а не для объемистых производственных прогонов. Используется программное
обеспечение, опирающееся на инвертированные файлы, инвертированные списки
или методы поиска по вторичному ключу. Новые поля могут добавляться дина¬
мично в любое время. Хорошие средства для запросов конечных пользователей
и для ’генерирования отчетов. В большинстве случаев применения вычислитель¬
ных средств, ориентированных на пользователя, используются базы данных
IV класса.	•
Примеры программного обеспечения:
IBM STAIRS, ICL CAFS, реляционные базы данных NOMAD, MAPPER,
SQL, QBE и различные языки четвертого поколения.	.
Характеристики
Часто легко реализовать.
Более гибкие и больше поддаются динамическим изменениям, чем тради¬
ционные системы баз данных.
Часто сосуществуют со средой III класса.
-	.	_		 м		 		 Н	. — -	__	-	_._	.._	' ■
57

СРЕДА II КЛАССА: ПРИКЛАДНЫЕ БАЗЫ ДАННЫХ
Среда II класса — это прикладные базы данных, а не предметные.
Системные аналитики стремятся к созданию для каждого нового при¬
ложения отдельной базы данных, как они делали с файловыми систе¬
мами. В результате применения систем управления базами данных не¬
зависимость данных в некоторой степени существует, но дублирование
их возрастает так же, как в файловых системах, и создает многие из
проблем, перечисленных в вставке 4.2.
Вставка 4.2. Проблемы, типичные для старых, признанных,
файловых вычислительных центров
•	Большая часть специалистов ЭОД занята ведением данных.
•	Высокая стоимость и небольшая скорость разработки новых систем.
•	Неспособность быстро реагировать на необходимые изменения.
•	Неспособность выдавать специальную информацию руководству.
•	Несообразное определение аналогичных элементов данных в разных при¬
ложениях.
•	Постоянно ухудшающееся развитие отдельных файлов.
•	Возрастание несовместимых значений избыточных данных.
•	Чем больше число программ, тем сложнее их преобразование при изме¬
нении данных, отсюда все большее нежелание реагировать на просьбы конечных
пользователей о внесении таких изменений.
•	Трудности в ведении учета и контроля данных.
•	Стоимость дублирования памяти.
•	Стоимость повторного ввода данных.
•	Отсутствие общего управления ресурсом данных.
Иногда говорят, что система управления используется, скорее, как
метод доступа к файлам, а не как истинная система баз данных.
СРЕДА III КЛАССА: ПРЕДМЕТНЫЕ БА31й ДАННЫХ
Средой III класса являются предметные базы данных. Когда соз¬
дан ряд таких баз данных, он представляет собой ресурс данных, о
котором мы говорили: «данные, независимые от конкретных прило¬
жений».
Типы представляемых^ данных меняются не очень часто, а функции,
которые ими пользуются, — часто. Поэтому не имеет смысла вклады¬
вать данные в функции, как это делается в среде I класса.
При использовании предметных, а не прикладных баз данных об¬
щее число баз данных бывает гораздо меньшим. В корпорации созда¬
ется большое множество приложений при небольшом числе операцион¬
ных предметов. Если файлы проектируются для конкретных приложе¬
ний, число этих файлов растет почти так же быстро, как и число прило¬
жений, в результате сильно увеличивается избыточность данных, прису¬
щая сегодня типичным библиотекам на лентах и дисках. Число ориен¬
тированных на приложения баз данных также может быстро возрастать.
Однако при использовании предметных баз данных число приложений
растет гораздо быстрее, чем число баз данных.
При внедрении многих баз данных стали создавать среду III клас¬
са и столкнулись с затруднениями. Появляется новое приложение и по
какой-либо причине для него создается новая база данных, а существу¬
ющие предметные базы данных не используются.
Создавать прикладные базы проще и легче, чем выполнить общий
проект, необходимый для предметных баз данных. Однако с течением
лет установки, где это практикуется, будут иметь почти столько же от¬
дельных баз данных, сколько у них было бы файлов, если бы они не
58

пользовались системой управления базами данных. В этом случае пер¬
спективные преимущества баз данных не используются. В таких ситуа¬
циях применение системы управления базами данных не снизит в долж¬
ной мере стоимость ведения программ.
Слишком часто попытки создать среду III класса сводятся к созда¬
нию среды II класса. Это может быть результатом плохого управления
или неудовлетворительного проекта предметных баз данных.
Иногда конечные пользователи или аналитики хотят иметь свою
собственную базу данных из-за тщеславия, местных соображений или
потому что это легче. Руководство же недостаточно настаивает на прин¬
ципах среды III класса или, возможно, не понимает их значения.
Иногда аналитику требуется новая картина данных, которую он не
может вывести на основании существующих баз данных. Тогда созда¬
ется новая база данных. Это случается еще и еще раз, пока баз данных
не становится слишком много. Причиной такой ситуации обычно явля¬
ется в первую очередь неадекватный проект. Сегодня хороший проект
могут обеспечить средства автоматизированного проектирования баз
данных [3] в совокупности с адекватным осуществлением функции
администрирования данных [1].
СРЕДА IV КЛАССА: ИНФОРМАЦИОННО-ПОИСКОВЫЕ СИСТЕМЫ
Системы данных этого класса предназначаются для мгновенной
выборки информации, систем поддержки принятия решений и автомати¬
зации конторских работ, а не для предварительно специфицированных
вычислительных или объемных производственных прогонов. Новые поля
можно добавлять динамически. Программное обеспечение использует
инвертированные списки или другие методы поиска данных. Имеются
хорошие языки конечных пользователей. Иногда с помощью этих язы¬
ков можно гибко создавать свои собственные логические файлы данных.
Большинству пользователей необходимы базы данных IV класса:
например, для реляционной системы NCSS используется язык NOMAD,
SQL или QUERY-BY-EXAMPLE — для ИБМ, MAPPER—для системы
«Юнивак» (см. [4]).
Информационно-поисковые системы часто отделяют от производст¬
венных систем баз данных, которые составляют ежедневные отчеты или
выполняют рутинную обработку данных. Их часто легче устанавливать
и легче вести. В них используется различное программное обеспечение.
Язык конечного пользователя, предназначенный для обращения к базе
данных, часто тесно связан со структурами данных. Некоторое програм¬
мное обеспечение может применяться в среде III или IV класса или в
обеих одновременно, но тогда одна из них не обеспечит наивысшей эф¬
фективности.
В информационно-поисковой системе часто содержится некоторое
количество данных, имеющихся и в соответствующей производственной
системе. Почему они должны разделяться? В первую очередь в интере¬
сах эффективности. Данные в информационной системе должны быть
организованы не так, как в обычной производственной системе, выпол¬
няющей большой объем вычислительных работ. Часто в ней содержится
только подмножество данных. Информационная система была бы крайне
неэффективна, если бы в ней содержался весь объем данных, хранимых
в производственной системе, в котором она должна была бы осуществ¬
лять поиски. С другой стороны, на рутинных процессах могли бы отрица¬
тельно сказываться многочисленные запросы конечных пользователей,
которые выполняют поисковые операции.
59

ГЛАВА 5
ОБЪЕДИНЕНИЕ ПРЕДМЕТНЫХ БАЗ ДАННЫХ
В СИСТЕМЫ
ВВЕДЕНИЕ
На рис. 4.3 показан ряд предметных баз данных и множество про¬
цессов. Эти предметные базы данных необходимо объединить в реализу¬
емые системы или подсистемы.
К решению этого вопроса можно подойти на макроуровне, начав с
классов данных или предметных баз данных. Полнее его можно решить
на уровне объектов, изучая группирование объектов в отдельные систе¬
мы (у каждого объекта имеется семейство элементов данных, которые
с ним ассоциируются).
Часто решения об отдельных системах принимаются на высшем
уровне до того, как выполнен достаточно тщательный анализ по иден¬
тификации всех объектов. Лучше работать на уровне объектов, если это
возможно; в ином случае можно воспользоваться классами данных или
предметными базами данных.
ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ АРХИТЕКТУРЫ
Следующие рисунки иллюстрируют подход, аналогичный системе
организационного планирования в соответствии с методикой ИБМ
(BSP; см. гл. 6).
На рис. 5.1 приводится список функций и процессов корпорации.
(Для наглядности список процессов дан в сокращенном и упрощенном
виде.) Функции перечисляются в порядке жизненного цикла продукта:
сначала планирование, затем финансирование, анализ рынка и т. д. до
тех пор, пока продукт не будет отправлен, а получение заказчиком не
будет подтверждено бухгалтерской отчетностью. Функция управления
кадрами не связана непосредственно с жизненным циклом продукта, и
она приводится в списке последней.
На рис. 5.2 список процессов отображается на список предлагае¬
мых предметных баз данных корпорации (которыми могут быть супер¬
группы объектов, выводимые в гл. 7). Рис. 5.2 (в отличие от рис. 4.3)
показывает, какие процессы создают данные. Буква С в матрице обо¬
значает, что процесс создает данные в конкретной предметной базе дан¬
ных. Буква U показывает, что он использует данные.
В каждой предметной базе данных имеются данные, созданные, по
крайней мере, одним процессом. Если они создаются более чем одним
процессом, проектировщику следует подумать, не стоит ли их разделить
на несколько баз данных. Например, база данных планирование на
рис. 5.2 создается как процессом прогнозирование сбыта, так и процес¬
сом финансовое планирование. Возможно, ее следует разделить на два
класса данных. С другой стороны, база данных номенклатура создается
60

ФУНКЦИОНАЛЬНЫЕ ОБЛАСТИ
ПРОЦЕССЫ
Планирование выпуска и сбыта продук¬
ции
Анализ рынка
Пересмотр объема выпуска продукта
Прогноз сбыта
Финансы
Финансовое планирование
Капитальные вложения
Руководство фондами
Планирование номенклатуры изделий
Проектирование изделия
Ценообразование
Поддержание технических характери¬
стик изделия
Потребности в материалах
Потребности в материалах
Закупочная деятельность
Получение материалов
Управление запасами
Контроль качества
Производственное планирование
Планирование производственных мощно¬
стей
Определение режима работы предприя¬
тия
Схема размещения рабочей силы
Управление производством
Управление материалами
Упорядочение по типоразмерам
Машинные операции
Сбыт
Территориальное размещение
Продажа
Управление сбытом
Поставки
Связи с заказчиком
Управление запасами готовой продукции
Обслуживание заказов
Упаковка
Отправка
Бухгалтерский учет
Кредиторы и дебиторы
Движение денежной наличности
Фонд заработной платы
Производственный учет
Разработка плана и смет
Анализ прибылей
Кадры
Планирование численности работающих
Комплектование штата
Компенсационная политика
Рис. 5.1. Функции и процессы. Крупная корпорация обычно имеет от 10 до 30 функ¬
ций и от 100 до 300 процессов. (Аналогично рис. 2.1.)
61

Предметные
базы
данных
Процессы
ц 1 h Ом h i М i !ЩЛ11
s 1 § 1 o^q^ 111 л I s ^^^liiii §
Диализ рынка
Пересмотр объема вы¬
пуска продукта
Прогнозирование сбыта
(РинансоВое планиро¬
вание
Капитальные “ложе -
ния
Управление фондами
Проектирование продукта
Ценообразование про¬
дукта
поддержание специфи¬
кации продукта
Потреби беги д матери¬
алах
Закупочная деятельность
Получение материала
управление запасами
контроль качестВа
Планирование производ¬
ственных мощностей
Планирование режима
работы предприятия
размещение рабочего
потока
Управление материально-
техническим снабжением
упорядочение по типо¬
размерам
Машинные операции
Территориальное раз¬
мещение
Продажа
Управление
сбытом
Связи с заказчиком
Управление запасами
гбтовой продукции
Обслуживание заказов
упаковка
Отправка
Кредиторы и дебиторы
Движение денежной
наличности
Фонд заработной платы
Производственный учет
Разработка плана и
смет
Анализ прибылей
Планирование числен¬
ности работающих
Комплектование
штата
компенсационная поли¬
тика
и	и и и	• и
и	и
и с	и и с	и
и	и	с
и С	и
и и
и	с с с
и	и	с
и с с
и	с и и и
с с	и	и
и и и	и	и
с	и
с
и	и с и и
и с и	и	и
с	си
и	и	и	и
и	с	и	и
и	с
с	и	и
с с
и	и
и	и и
с	и	и
и	с	и
и	и
и	и
и	и	и
и	и и	и и	и	и и
с и и
и	с	с	и
си	и и	и	и
и и	и
и	с с
и и
и	и и
Рис. 5.2
как процессом проектирование продукта, так и процессом ведение спе¬
цификаций продукта. Эти процессы могут создавать одинаковые типы
данных.
Следующий шаг в этой методологии — изменить последовательность
предметных баз данных, как на рис. 5.3. Предметная база данных, кото¬
рая создается первым процессом, передвигается налево. Затем налево
передвигается база данных, создаваемая вторым процессом (если она
62

\ Предметные
X базы
^данных
Процессы X.
*8 §	Э	5
1 S 1 |И. Bin i st’ э s S
1ьЪИВЧ1л Ч^§Р lshiih
i Л 5 ^^5 8 s g S о ^^5^*B S t <&a 2 £ eg £ g
Янализ рынка
Пересмотр объема Вы¬
пуска продукта
Прогнозирование сбыта
Финансовое лланиро-
бание
Капитальные Вложе¬
ния
Управление фондами
Проектирование продукта
ценообразование про-
лоддержанце специфи¬
каций продукта
Потребности В матери-
Закупочная деятельность
Получение материала
Управление запасами
Контроль качества
Планирование производ¬
ственных мощностей
Планирование режима
работы предприятия
Размещение рабочего
потока
Управление материально-
техническим снабжением
Упорядочение по типо-
размерам
Машинные операции
территориальное раз¬
мещение
Продажа
УораВление
сбытом
Связи с заказчиком
Управление запасами
готоВои продукции
Обслуживание заказов
упаковка
Отправка
Кредиторы и дебиторе/
Движение денежной
ноличности
Фонд заработной платы
Производственный учет
Разработка плана и
смёт
Пнапиз прибылей
Планирование числен¬
ности работающих
Комплектование
штага
компенсационная поли¬
тика
и	и	u( и и
и	и
с с и	и и и
Си	и
и и с
и и
и	С С С
и	С	и
и	с	С
и	и	и с и
и	и	с	с
и	и	и	и	и
С и
с
и и	С	и и
и	и с и и
и	с с
и	и и	и
и	и	и	с
и	с
Сии
с с
и	и
*	и	и	и
и	и	с
и	и	С
и	и
и	и
и	и	и
и и	и	и	и и и и
с и и
и	и	с с
и С и	ми	и
и	и	и
и	С с
и и
и	и и
Рис. 5.3
имеется). Эта операция продолжается для всех предметных баз данных.
В полученной в результате матрице, приведенной на рис. 5.3, все С рас¬
положены по диагонали, слева направо сверху вниз.
Теперь процессы и данные можно объединять в системные обла¬
сти, заключая группировки в прямоугольники, как показано на рис. 5.4.
Выбор этих прямоугольников несколько-произволен, при этом нужно
63

ПРЕДМЕТНЫЕ
\ БАЗЫ
ЖДАННЫХ
ПРОЦЕССЫ
Анализ рынка
Пересмотр объема вы¬
пуска продукта
Прогнозирование сбыта
Финансовое планиро¬
вание ,
Капитальные вложе¬
ния
Управление фондами
Проектирование продукта
Ценообразование про-
оикта
Поддержание специфи¬
кации прооунта
Потребности в матери¬
алах
Закупочная деятельность
Получение материала
Управление запасами
Контроль качества .
стоеннык мощностей
Планирование режима
работы предприятия
Размещение рабочего
потопа
Управление материально¬
техническим снабжением
упорядочение по типо¬
размерам
Машинные операции
Территориальное раз¬
мещение
Продажа
Управление
сбытом
СВязи с заказчиком
Управление запасами
готовой продукции
обслуживание заказов
Упаковка
Отпрабка
кредиторы и дебиторы
движение денежной
наличности
Фонд заработной платы
Производственный учет
Разработка плана и
смет
Анализ прибылей
Планирование числен¬
ности работающих
Комплектование
штата
компенсационная по¬
литика '
Рис. 5.4
иметь в виду, что следующий этап — это моделирование данных для
прямоугольника с помощью методов, рассматриваемых в [1]. Эти прямо¬
угольники представляют собой группы логических информационных
подсистем, отвечающих за создание и ведение различных классов
данных.
Когда использование. (U) выпадает из какого-либо прямоугольника,
это обозначает, что из одной подсистемы в другую должен идти поток
64

^3
^«ts
N * Й
g o^S
Диализ рынка
Пересмотр объема Вы¬
пуска продукта
Прогнозирование сбыта
Финансовое планиро¬
вание ,
капитальнее Вложе¬
ния
Управление фондами
Проектирование продукта
Ценообразование про-
^оЗдержание специри •
нации продукта
Потребности В матери -
ал ах
Закупочная деятельность
Получение материала
Управление запасами
Контроль качества
Планирование производ¬
ственных. мощностей
Планирование режима
работы предприятия
Размещение рабочего
Я а
ление материально¬
техническим снабжением
: упорядочение по тупо-
I размерам
машинные операции
Территориальное раз¬
мещение
продажа
Управление
сбытом
Связи с заказчиком
Управление запасами
готовой продукции
Обслуживание заказов
упаковка
Отправка
кредиторы и дебиторы
Движение денежной
наличности
Фонд заработной платы
Производственный учет
Разработка плана и
сырт
Анализ прибылей
Планирование числен¬
ности работающих
Комплектование
штата
компенсационная по¬
литика
U
и
С С
С и
и и
и
и
Рис. 5.5
данных. Иллюстрацией служит рис. 5.5. Процесс размещение рабочего
потока использует данные продукта, но данные продукта создаются
второй подсистемой на схеме, а процесс размещение рабочего потока на¬
ходится в четвертой подсистеме. Поэтому стрелка на рис. 5.5 показыва¬
ет, что поток данных идет из второй подсистемы в третью.
На рис. 5.6 приводятся все такие потоки данных. На рис. 5.7 С и U
65

ПРЕДМЕТНЫЕ
ч БАЗЫ
\ДйННЫХ
Анализ рынка
Пересмотр объема Асм
пуска продукта
Прогнозирование сбыта
Финансовое планиро -
оание
Капитальные сложе¬
ний
Управление амидами
Проектирование продукта
Ценообразование про-
Юержание специи]
нации продукта
Потребности в матери-
Закупочная деятельность
Получение материала
Управление запасами
контроль качества
Планирование производ¬
ственных мощностей
Планирование режима
работа предприятия
Размещение рабочего
Упрощение материально-
техническим снабжением
Упорядочение по типо¬
размерам
Машинное операции
Терри ториальное раз •
мешение
Продажа
Управление
еды том
Связи с заказчиком
Управление запасами
готовой продукции
Обслуживание заказа#
Упаковка
Отправка
Кредиторы и дебиторов
Движение денежной
наличности
Фонд заработной платы
Производственный учет
Разработка плана и
смет
Анализ прибылей
Планирование числен¬
ности работающих
комплектование
штата
Компенсационная ПО*
лицина
Рис. 5.6
сняты, а информационным подсистемам даются названия. Стрелки, по¬
казывающие потоки данных между этими подсистемами, объединяются.
РУТИННАЯ И НЕРУТИННАЯ ОБРАБОТКА
Желательно различать рутинные и нерутинные системы. В системах
рутинной обработки выполняются предсказуемые операции: обычная
обработка заказов, счетов, заявлений о выплате страховых возмещений
66

ПРЕДМЕТНЫЕ
БАЗЫ
ДАННЫХ
a
£
«4
h
X 5
Изготовление
ПРОЦЕССЫ
I 111.
^ ? si
Анализ рынка
пересмотр объема
Выпуска продукта
Прогнозирование сбыта
Финансовое
планирование
капитальные
вложении „
управление фондами
Проектирование продукта
Ценообразование продукта
поддержание специфи¬
кации продукта
Потребности S материалах
Закупочная деятельность
Получение материала
Управление запасами
Контроль качества
Планирований производи
ст венных мощностей
Планирование'режима
рамты предприятия
Размещение рабочего
Управление материально¬
техническим снабжением
Упорядочение по
типоразмерам
Машинные операции
7№№a"ime
Продажа
управление сбытом
Связи с заказчиком
Управление запасами
еотмой продукции
Обслуживание заказов
Упаковка
Отправка
кредиторы и дебиторы
движение денежной
наличности
Фонд заработной платы
Производственный учет
Разработка плана и смет
Анализ прибылей
Планирование числен-
носта^ раортающих
Комплектование
штата
компенсационная
jwouruKa
'05спу^<
живоние
-^тер-.
<скии
Рис. 5.7
и т. д., а также простые запросы. Часто объем выполняемых в них дей¬
ствий велик. Нерутинные системы бывают разных типов. Для проекти¬
ровщиков баз данных особенно важны информационные системы, в ко¬
торых пользователь ищет информацию, формулирует непредусмотрен¬
ные запросы или делает предусмотренный запросы, требующие операций
с вторичными ключами. Другие типы нерутинных систем — системы ис¬
следования операций , н системы поддержки принятия решений. На
67

рис. 5.7 не проводится различий между этими типами систем. Мы можем
видоизменить рисунок с учетом различий.
ЧЕТЫРЕ ТИПА СИСТЕМ
Охарактеризуем эти типы систем следующим образом:
1.	Системы рутинной обработки
•	Предопределенные задачи, решающие правила и потоки транзакций.
•Часто выполняется большой объем работ.
•Масса обычной обработки данных.
•	Основные преимущества: эффективность операций, быстрое обра¬
щение, быстрые ответы на простые запросы, сокращение количества то варов,
экономия штата.
•	Основная проблема проектирования: эффективность массовых
операций.
•Выигрывает обычно при использовании баз данных Ш класса,.
2.	Информационные системы
*	Отвечают на неструктурированные, непредусмотренные запросы или на
запросы, требующие операций с вторичными ключами.
•Генерируют отчеты.
•	Основное преимущество: лучшая информация для тех, кто принимает
решения.
•	Основные проблемы проектирования: мощный язык конечного
пользователя; эффективность операции управления.
♦Выигрывает в случае применения баз данных IV класса.
3.	Система поддержки принятия решений
•Неструктурное применение, не полностью предусмотренное.
• Не автоматизируют принятие решений, но помогают исполнителю,
принимающему решение.
•Могут выполнять значительный объем вычислений.
•Основное преимущество: лучшие решения.
•Пользователь может вести свою собственную базу данных.
•Может воспользоваться базой данных III или IV класса.
4.	Система исследования операций или специальных вычислений
•	Обеспечивает решения для определенных классов проблем, которые
обычно хорошо структурированы.
•	Основное преимущество: новые методологии для решения сложных
задач.
•Может использовать файлы, извлеченные из базы данных.
Среди пользователей растет тенденция иметь свои собственные вы¬
числительные машины и вести информационные системы и системы под¬
держки принятия решений на разных машинах. Исследование операций часто
выполняется на большой централизованной ЭВМ, поскольку при этом
необходима большая основная память или возможность «перемалывать
числа». При планировании информационных ресурсов организации
желательно учитывать, какие данные могут потребоваться для ин¬
формационных систем и систем поддержки принятия решений.
РУТИННЫЕ И НЕРУТИННЫЕ СИСТЕМЫ
Некоторые из процессов, перечисленных на рис. 5.7, являются за¬
груженными, требующими большого объёма рутинной обработки тран¬
закций. Отделение их от баз данных информационной системы или
системы поддержки принятия решений часто оправдывает себя. Организа-

Потребности 6 „отв’
риал
Зану, пая деятель¬
ность
Получение материала
Управление запасами
контроль качества
Планирование ремиза
работ предприятия
Размещение рабочего
по тона
Управление материально
техническим снабжением
.Упорядочение по типо¬
размерам
машинные операции
Продажа
Управление сбытом
Управление запасами
готовой продукции
Обслуживание заказов
Улановна
Отправка
Кредиторы и дебиторы
Движение денежной
наличности	,
Фонд заработной
плоты	.
Производственный
учет
ПРИОБРЕТЕНИЕ
U
и
и
и
и
и
и
и
и
и
и
и
и
и
U
С
и
с
с
и
и
и
с
и
с
и с и
и
ИЗГОТОВЛЕНИЕ
с
с
и
и
и
и
и
с
с
и
и
СБЫТ
с с
и
и
с
с
и
и
и и
и
и
и
ОБСЛУЖИ ‘
ВАННЕ
ЗАКАЗОВ
и
и
и
с
и
и
с
с
бухгалтерский учет
Рис. 5.8. Вариант рис. 5.6, показывающий только сильно загруженные процессы
ция данных и методы доступа в загруженных системах тщательным об¬
разом согласуются с большим объемом рутинного использования в них
данных. В информационных системах и системах поддержки принятия
решений данные имеют гораздо более гибкую организацию, выборка
бывает небольшого объема, а методы доступа проектируются для поис¬
ка данных или для удобства применения мощных языков конечного
пользователя. Рис. 5.8 представляет собой вариант рис. 5.6, показываю¬
щий только загруженные процессы. Рис. 5.9 показывает, каким процес-
69

,\ ПРЕДМЕТНЫЕ
&	05
ВЯЗЫ
^к Данных
. ПРОЦЕССЫ
5	х Д g ^	5 S ^g S	Q«§
I	§	х	к	3?^
III Ш1 g 5 И 1 ^is^ % $»s 1 § SS
Диализ рынка
Пересмотр объема
выпуска продукта
Прогнозирование сбыта
Финансовое
планирование
капитальные
вложений
. Управление зондами
Проектирование продукта
ценообразование продукта
Поддержание специри -
нации прооинта
Потребности о материалах
■ Закупочная деятельность
Получение материала
Управление запасами
контроль качества
Планирование производ¬
ственных мощностей
Планирование режима
работы предприятия
Размещение рабочего
потока
Управление материально¬
техническим снабжением
Упорядочение по
типоразмерам
. машинные операции
Территориальное
размещение
Продажа
Управление еды том
Связи с заказчиком
Управление запасами
готовой продукции
Обслуживание заказов
Упаковка
Отправка
Кредиторы и дебиторы
Движение денежной
наличности
Фонд заработной платы
Производственный учет
Разработка плана и смет
Анализ прибылей
Планирование числен¬
ности работающих
Комплектование
штата
Компенсационная
политика
Информационная система
Информационная система
>Ппанира^	Система	поддержки принятия
Звание W	решения
8?оо83оо8	Система	поииержки принятия
88880888	решения
88888888	Информационная система
88888888^	Система	поддержки принятия
<22222222	р	решения
^ЯЯ888888^	Специальные вычисления
^^пТ^ит^	Система поддержки принятия
ние продукта>	решения
w^W2	Рутинная обработка данных
&$$$^	Рутинная обработка данных
Рутинная обработка данных
Приобретение,	рутинная обработка данных
Рутинная обработка данных
Рутинная обработка данных
Рутинная обработка данных Й$$$388888
Рутинная обработка данных
Рутинная обработка данных ?О>л888888<
3	Г	„	Изготовление,
Рутинная обработка данных	500^888$
Рутинная обработка данных	хххх^^
Рутинная обработка данных

Информационная система
Рутинная обработка данных	ыбыъъм
Рутинная обработка донных	<ю<хх^
Информационная система	QWW

Рутинная обработка данных	$спщ
Рутинная обработка данных	уние^
Рутинная обработка данных	^зо^
Рутинная обработка данных	Ж*Ж
Рутинная обработка	данных	Ж$$
рутинная обработка	данных	<вухд
Рутинная обработка	данных	^гр'^
Рутинная обработка	данных	^учел^
Система поддержки принятия решения	Х88^
Информационная система
Информационная система	В$$$8$
Рутинная обработка данных	Модры*
Система поддержки принятия	решения	*лбб&>
Рис. 5.9. Вариант рис. 5.7, показывающий рутинную ЭОД, информационные системы
и системы поддержки принятия решений
сам требуется каждая из четырех типов систем данных: рутинная обра¬
ботка, информационные системы, система поддержки принятия решений
и система специальных вычислений.
Рис. 5.10 основан на рис. 5.7, 5.8 и 5.9, он показывает подсистемы,
поддерживающие в первую очередь рутинные процессы (заштрихован¬
ные прямоугольники), и подсистемы, поддерживающие отдельные ин-
70

ПРЕДМЕТНЫЕ БАЗЫ ДАННЫХ
новизна ДАННЫХ
ПРОЦЕССЫ
Пересмотр объема
выпуска продукта
Капитальные Сложения
Управление рандами
ЛланироВа/iue числен¬
ности работающих
Комплектование
штата
Кредиторы и дебиторы
движение денежной
наличности
Фонд заработной платы
Производственный учет
Анализ прибылей'
Поддержание хпеии -
фикации проаукта
Потребности в материалах
Закупочная деятельность
Получение материала
Управление запасами
Контроль качества
Планирование производ¬
ственных мощностей
Планирование режима
роботы предприятия
Размещение рабочего
потока
Управление материально¬
техническим снабжением
Упорядочение по
типоразмером
Машинные операции
Территориальное
размещение
Продажа
Управление сбытом
Связи с заказчиком
Управление запасами
готодои продукции
Обслуживание заказа!
Упаковка
Отправка
L
с
U
L
L
М
М
Н
Н
С
С
м
н
н
н
м
L
М
М
Н
н
н
с
я
н
с
И
н
н
н
Рис. 5.10
формационные системы и системы поддержки принятия решений (круж¬
ки). Стрелками показаны потоки данных между рутинными подсисте¬
мами. Информация для других подсистем передается из ответвлений
этих потоков. Ею обычно являются суммарные данные. Подсистемы
информационные и поддержки принятия решений не обновляют данные
в других базах данных.
Такой метод разделения данных на Подсистемы не представляет со¬
бой точного алгоритма; он требует человеческого суждения. Если в ка¬
кой-либо подсистеме имеются независимые функции или независимое
71

использование данных, ее следует разделить. Например, операции тра¬
ста в примере с банком из гл. 4 были в основном независимыми, и их
выделили в отдельную подсистему. По возможности желательно разби¬
вать большие сложные системы на подсистемы, чтобы каждую подси¬
стему легче было реализовать одной группе разработчиков.
ПЛАНИРОВАНИЕ ДЛЯ ЧЕТЫРЕХ КЛАССОВ ДАННЫХ
Многие матрицы и схемы, применяемые в планирований сверху
вниз, отражают базы данных только III класса. Например, это верно
для рис. 4.3 и 5.6. На рис. 5.10 показана также среда IV класса.
Опыт работы с установками баз данных подсказывает желатель¬
ность отражения каждого из четырех классов среды.
Для некоторых данных все еще существуют достаточные основания
планировать файлы (среда I класса). Это могут быть существующие
файлы, преобразование которых слишком дорого; файлы могут плани¬
роваться и вследствие того, что слишком велики издержки работы баз
данных.	.
Некоторые области приложений сильно отличаются по данным, и
поэтому они могут пользоваться разделенными базами данных II клас¬
са, хотя эти приложения должны часто брать определения данных из
словаря коллективного пользования и процесса моделирования.
Базы данных IV класса (информационные системы) могут быть
также отдельными, что обусловлено:
•	характеристиками машины,
•	устранением проблем планирования задания,
•	возможностями для пользователей манипулировать собственными
данными, не влияя на производственную систему,
•	простотой реализации.
Во многих корпорациях уже существует множество систем, которые
часто пользуются файлами или базами данных II класса. Многие фай¬
лы и базы данных II класса невозможно быстро преобразовать. Их сле¬
дует включать в общий план.
РАСПРЕДЕЛЕНИЕ ДАННЫХ
Кроме четырех классов среды данных централизованный план (свер¬
ху вниз) должен учитывать распределение данных. К схемам на рис. 4.3,
5.6 или 5.10 следует добавить новые признаки, показывающие, какие
данные где находятся, и имеют ли данные, располагающиеся в разных
местах, одинаковую структуру. При таком планировании учитываются
соображения, рассмотренные в гл. 10—12.
ОБЪЕМЫ ДЕЯТЕЛЬНОСТИ И ПРИМЕНЯЕМОСТЬ ДАННЫХ
Матрицы, отображающие предметные базы данных на процессы,
могут включать показатели, обозначающие объем деятельности и при¬
меняемость данных. На рис. 5.10 показатель объема деятельности ука¬
зывает, какие процессы являются загруженными и требуют, чтобы
структура базы данных для них выбиралась с учетом эффективности
использования машины. Признаки применяемости данных показывают,
какие данные должны находиться в оперативной памяти, какие долж¬
ны вводиться дискретно, какие можно вводить в пакетном режиме, а
также цикл обновления данных — ежедневный или более длительный.
Признаки применяемости помогают спроектировать отношения с систе-
72

мами, не являющимися базами данных, и показывают, какие периоди¬
ческие циклы можно использовать для того, чтобы заполнить пробел
между существующими файловыми системами и системами баз данных
в интегрированной архитектуре.
ПРИОРИТЕТ РЕАЛИЗАЦИЙ СИСТЕМ
При наличии 100 или более процессов схемы, отображающие про¬
цессы на данные, становятся сложными. Они представляют набор си¬
стем, на реализацию которых уйдут годы. За какие системы нужно
браться сначала?
Интервьюер:
Этот план такой широкомасштабный, как вы выделяете из него то, что
хотите сделать в первую очередь?
Администратор базы данных:
Говоря откровенно, вначале выбор определялся приложениями и пользова¬
телем. Например, возникла настоятельная необходимость в системах контроля
и регулирования денежными операциями в корпорации. Мы воспользовались
этим как возможностью создания базы данных.
Позднее выбор уже не определялся пользователем, поскольку существо¬
вали базы данных и для нас были доступны данные, позволяющие реализовать
те дополнительные приложения, что требовались пользователям.
Интервьюер:
Итак, вы говорите, что вначале все определялось запросами пользователей,
желающих получить новые приложения, но затем, когда был построен ряд
предметных баз данных, можете ли вы проектировать приложения таким обра¬
зом, что определяющим фактором будет база данных?
Администратор базы данных:
Да, это верно. Конечный результат таков, что мы получаем все больше и
больше запросов и отвечаем на них гораздо быстрее. Я свидетель тому, как в
нескольких случаях приложения были реализованы в течение нескольких не¬
дель, потому что база данных уже существовала.
Первыми следует реализовывать те базы данных, которые отвеча¬
ют насущным потребностям. Описываемая в гл. 6 методология помогает
определить эти потребности или то, что высшее руководство считает
первоочередным.
Однако в некоторых случаях первоочередная потребность в одной
из систем не может быть удовлетворена до тех пор, пока не будут ра¬
ботать другие системы. Например; руководство может решить, что самой
необходимой является система финансового планирования. Но такая
система должна черпать информацию из других систем и ее невозможно
создать полностью до тех пор, пока эти другие системы не будут су¬
ществовать.
Чтобы показать, какие системы являются необходимыми предпо¬
сылками для других систем, можно построить матрицу. На рис. 5.11 при¬
ведена такая матрица для систем, представленных на рис. 5.10. Обычно
на практике разработка систем не укладывается в рамки, показанные
последовательностью этих предпосылок. Система финансового планиро¬
вания может считаться руководством самой необходимой. Но предпо¬
сылкой для нее является система планирования. К сожалению, предпо¬
сылками для планирования являются Уакие системы, как бухгалтерский
учет, материалы и сбыт, а система бухгалтерского учета зависит от лю¬
бой системы рутинной обработки данных. Кроме того, такая схема, как
73

на рис. 5.11, часто показывает, что подсистема А является предпосыл¬
кой для подсистемы В, а В — для А, что представляется тупиковой
ситуацией. Частично это объясняется тем, что матрица, приведенная на
рис. 5.11, дает слишком укрупненную картину. Более подробную кар¬
тину можно получить на основании предметных баз данных, а еще более
подробную— на основании объектов. Какой процесс создает каждую
предметную базу данных? И какие другие предметные базы данных не¬
обходимы для этого?
Системы, необходимая для создания других систем
1
1
t
§
«ъ
см
D
1
Я)
^^
ь
'J ^
MS
X
Планирование
[x^
кодры
“	— (
бухгалтерский у не г
ма терна лы
Lj
Изготовление
Сбыт
Обслуживание заказов
[x^
kZ—\
^ 5 $
у 5
^ ^ ^
?
Qj QJ 5
Финансовое
планирование
Анализ рынка и прогно¬
зирование сбыта
i
f—

проектирование
продукта
1
ценообразование	■
продухтр

[/
бюджетное
планирование

[x^
компенсационная
политика

Рис. 5.11. Схема, выведенная на основании рис. 5.10 и показывающая,
какие системы нужны для создания других систем. Обычно это очень
приближенная картина
Часто желательно разработать важную подсистему до того, как
будут существовать предметные базы данных — предпосылки. Для этого
нужно извлечь данные из ранее созданных систем, реализованных до
планирования баз данных. Формат этих данных нередко следует преоб¬
разовывать перед тем, как переводить их в систему базы данных. Этот
и другие виды преобразований — существенная часть планирования реа¬
лизаций, что обсуждается в гл. 25 работы [1].
Установление приоритетов в разработке архитектуры информацион¬
ной системы, как на рис. 5.10, является очень важным, оно должно со¬
ставлять часть общего планирования. В противном случае решающим
станет давление со стороны приложений, часто нарушающее весь план.
Ранние реализации почти всегда требуется преобразовывать. Давление
со стороны приложений и запросы пользователей необходимо понимать
и тщательно взвешивать. Путь к этому указывает методология, описы¬
ваемая в главе 6.

ГЛАВА 6
СИСТЕМА ОРГАНИЗАЦИОННОГО
ПЛАНИРОВАНИЯ
(МЕТОДИКА ИБМ)
ВВЕДЕНИЕ
Опыт работы, описанный в гл. 4, хотя он и является хорошей иллю¬
страцией централизованного планирования, страдал из-за отсутствия
участия в планировании высшего руководства. Методология, которую
мы описываем в данной главе, должна заинтересовать административ¬
ных работников высшего уровня. Называется она система организаци¬
онного планирования (BSP). Эта методология была предложена корпо¬
рацией ИБМ в середине 1970-х годов и ею воспользовались несколько
сотен клиентов ИБМ. Один из ее вариантов применяли некоторые фир¬
мы, консультирующие руководящий состав предприятий.
Часто между руководителями ЭОД и высшим руководством отсут¬
ствует взаимопонимание. Это наносит ущерб делу. В некоторых органи¬
зациях методология BSP оказалась эффективным средством для дости¬
жения взаимопонимания в процессе выяснения требующихся типов баз
данных. Основная польза от этой системы, скорее, в установлении свя¬
зей с высшим руководством, чем в планировании баз данных.
BSP описывается как «структурный подход, помогающий предприя¬
тию определить план создания информационных систем, удовлетворяю¬
щих его ближайшие и перспективные информационные потребности»
[2]. Эта методология основывается на той точке зрения, что информа¬
ция является ресурсом и должна планироваться в масштабах всего
предприятия независимо от того, что она используется на различных
ЭВМ и в ряде отделов (подразделений предприятия). Информационные
потребности часто остаются теми же, в то время как само предприятие
реорганизуется. Поэтому архитектура информации должна проектиро¬
ваться независимо от текущей структуры предприятия. Реализация этой
архитектуры отразит текущую структуру предприятия и его проблемы.
Они скажутся на выборе тех модулей архитектуры, которые надо будет
осуществить в первую очередь. Информационные потребности не явля¬
ются статическими, и план информационных ресурсов надо будет об¬
новлять непрерывно по мере развития предприятия.
ЗАДАЧИ BSP
Основная цель BSP—обеспечить план развития информационной
системы, который поддерживает ближайшие и перспективные информа¬
ционные потребности предприятия и является частью плана его разви¬
тия. BSP имеет и другие задачи [2]:
75

1)	обеспечить формальный, объективный метод для руководства,
помогающий определить приоритет разработок информационных систем
независимо от каких-либо местнических интересов;
2)	обеспечить разработку долгосрочных систем, экономя капитало¬
вложения, так как эти системы базируются на процессах предприятия,
на которые организационные изменения обычно не влияют;
3)	обеспечить такое управление ресурсами обработки данных, кото¬
рое служит наиболее эффективному решению задач предприятия;
4)	содействовать повышению уверенности руководителей в том, что
будут созданы информационные системы с высокой отдачей;
5)	улучшить взаимоотношения между отделом информационных си¬
стем и пользователями за счет обеспечения систем, отвечающих требо¬
ваниям и приоритетам пользователей;
6)	определить данные как ресурс организации (корпорации), кото¬
рый следует планировать и контролировать, чтобы им мог эффективно
пользоваться каждый.
Корпорация ИБМ перечисляет преимущества BSP в следующем по¬
рядке:
Для руководителей высшего уровня
•	оценка эффективности текущих информационных систем;
•	определенный логический подход, помогающий решить проблемы
административного управления с перспективной точки зрения;
•	определение будущих потребностей в информационных системах
на основании влияний и приоритетов, связанных с организацией дела;
•	плановый метод, позволяющий быстро получать отдачу от затрат
компании на информационные системы;
•	информационные системы, относительно независимые от организа¬
ционной структуры;
•	уверенность в том, что существует направление развития инфор¬
мационных систем и соответствующее внимание к ним со стороны руко¬
водства, способствующие реализации предлагаемых систем.
Для руководителей среднего звена
•	определенный логический подход, помогающий решать задачи
административного и операционного управления;
•	непротиворечивые данные для коллективного использования;
•	участие высшего руководства, определяющее организационные
цели и направление, а также согласованную очередность разработки
систем;
•	системы, ориентированные на руководителей и пользователей, а
не на обработку данных.
Для руководителей информационных систем
•	связь с высшим руководством и его информированность;
•	согласованный приоритет систем;
•	лучшая база для перспективного планирования ресурсов обработ¬
ки данных и финансирования;
•	более обученный и опытный в планировании обработки данных
персонал, отвечающий потребностям предприятия.
С точки зрения корпорации ИБМ применение этой методологии мо
жет привести к тому, что во всей организации будет использован общий
подход к базам данных и, следовательно, будет продано больше аппа¬
ратного и программного обеспечения ИБМ. Отсюда стремление торго¬
вых агентов ИБМ лучше понять своих клиентов, что обычно приводит к
большим возможностям сбыта продукции. Это способствует предотвра¬
щению неконтролируемого распространения мини-ЭВМ среди конечных
пользователей.
76

ЦЕНТРАЛИЗОВАННЫЙ ПОДХОД
В BSP для определения требуемых информационных подсистем ис¬
пользуется анализ, осуществляемый сверху вниз. Проектирование и
реализацию этих подсистем рекомендуется выполнять снизу вверх. Ин¬
формационные подсистемы соответствуют общей информационной ар¬
хитектуре корпорации.
Идентифицированные подсистемы будут с течением времени реали¬
зовываться в виде «строительных блоков». BSP устанавливает приори¬
теты, указывая, какие подсистемы строятся в первую очередь. Важно,
чтобы эти строительные блоки хорошо стыковались друг с другом, а это
вряд ли произойдет, если проектирование всей информационной архи¬
тектуры корпорации не будет выполнено централизованно — структур¬
ным методом.
Строительные блоки (системы или подсистемы), которые идентифи¬
цирует BSP, являются хранилищами или пунктами управления для оп¬
ределенных классов данных. Когда эти классы данных реализуются
(обычно с помощью технологии баз данных), они обеспечивают данные
для определенного набора процессов предприятия, как показано на
рис. 6.1. "
Отдельные проекты ЭОД обычно относятся к одной функциональ¬
ной области предприятия. Общая информационная архитектура гаран¬
тирует, что при реализации отдельных проектов не будет серьезного
противоречия в данных, избыточности или дублирования функций. Цен¬
трализованный план покажет также приоритет реализаций.
ШАГИ АНАЛИЗА, ПРОВОДИМОГО МЕТОДОМ BSP
На рис. 6.2 показан весь процесс анализа, проводимого методом
BSP. Анализ должен начинаться с получения поддержки со стороны
дирекции и с привлечения другого административного персонала. Он
призван отражать их точку зрения на предприятие и не должен начи¬
наться без участия руководства. Большая часть входной информации
поступит прямо или косвенно от этих руководителей.
Одобрение результатов анализа обяжет компанию соблюдать в те¬
чение нескольких лет информационную архитектуру и определенное на¬
правление в использовании своих ресурсов ЭОД. Поэтому высшее руко¬
водство с самого начала должно осознавать весь диапазон задач прово¬
димого анализа.
ОПРЕДЕЛЕНИЕ ПРОЦЕССОВ ПРЕДПРИЯТИЯ
На шаге 4 анализа, проводимого методом BSP (см. рис. 6.2), закла¬
дывается фундамент для большей части анализа: создается список
функций и процессов предприятия, таких, как на рис. 2.1, и дается крат¬
кое описание каждого процесса. Этот список процессов служит основой
для матрицы (см. рис. 6.1), которая о/ображает процессы на классы
данных, а также для последующих бесед с руководителями и анализа
существующих проблем.
77

\ ПРЕДМЕТНЫЕ
'\5ДЗЫ ДР ИНЫХ
ПРОЦЕССЫ
5 § ^ < * § I
* * ^i 11^^ 1 ^ ^ ^
> t 2 ^ ^ ^J s х § < ^ г ^ ч ^^ ё* * 2* | *
^^ ^ ^^ з^з ^^^^^ ^^<5^? а
Анализ рынка
Пересмотр объема
выпоена продукта
Прогнозирование
сбыта
Финанс обое планиро ■
воние
Ха пи тольные вложе -
ния
Управление фондами
дроен тирование про -
дун та
ценообразование про-
вук га
Поддержание^ специ -
(ринации продукта
потребности о мате ри -
V6*
Закупочная деятель¬
ность
Получение матери -
Управление запасами
Хон троль качества
Планирование производ¬
ственных мощностей
Планирование режима
работы предприятия
Размещение рабочего
потока
Управление материаль¬
но- техническим снабжение
Упорядочение по типа-
размерам
Машинные операции
Территориальное раз¬
мещение
Продажа
Управление сбытом
Связи с заказчиком
Управление запасами
готовой продукции
Обслуживание занозов
Упаковка
Отправка
Хредиторы и дебиторы
Движение денежной
наличности
Фонд заработной
платыа	_
Про из боде таенный
учет
разработка плана
и смет
Анализ прибылей
Планирование числен¬
ности оавстающих
комплектование
штата
компенсаци он на я
политика
и	и и	и	и
и	и	1
и с	и и	с	и
и	и	с
и С	U
и и
и	с с с
ио	с	•
и с с
и	С	и и и ■
СО	U U I
и и и	и и ■
с	и	1
с	!
и	и с и и	!
и	с	о	и и	j
0	си	;
и	сии
и си	J
и	с
Сии	'
с с
и	и
и	и и
С	и	и
и	с	и	j
и	и
и	и	и
ииииииии
с и и
и	с	с	и
си	и и	и	и
и и	U
и	с с
и и
и	и и
Рис. 6.1 (то же, что рис. 5.2)
ОПРЕДЕЛЕНИЕ КЛАССОВ ДАННЫХ
На шаге 5 анализа определяются классы данных, которые исполь¬
зуются в матрице, приведенной на рис. 6.1. Класс данных — это объеди¬
нение данных в логически связанные категории. Выбор классов данных,
если в этом возникнет необходимость, может быть уточнен на последу¬
ющих этапах. Матрица на рис. 6.1 создана. Классы данных соотнесены с
78

Рис. 6.2. Итоги анализа, проводимого методом BSP
существующими файлами (или базами .данных), чтобы можно было про¬
ложить путь перехода от сегодняшних систем к информационной архи¬
тектуре, получаемой в результате применения BSP.
79

АНАЛИЗ СУЩЕСТВУЮЩИХ ДЕЛОВЫХ И СИСТЕМНЫХ СВЯЗЕЙ
На предприятии обычно имеются действующие системы обработки
данных, которые используют данные не так, как показано на рис. 6.1.
На шаге 6 анализа, приведенного на рис. 6.2, отображается, как су¬
ществующие и планируемые системы ЭОД используются на предприя-
СИСТЕМЫ
ЭОД
СИСТЕМЫ
ЭОД
СИСТЕМЫ
ЗОД
руюводители
в
ОРГАНИЗАЦИИ
ПРОЦЕССЫ ПРЕДПРИЯТИЯ
Эта матрица показы¬
вает основные обязан¬
ности руководителей,
большую степень Во¬
влеченности и мень -
шую степень Вовле¬
ченности
Эта матрица показы¬
вает, какие сущест¬
вующие или плановые
системы ЭОД кем из
руководителей исполь¬
зуются
ПРОЦЕССЫ ПРЕДПРИЯТИЯ
Эта матрица показы¬
вает, как существую¬
щие или плановые
системы ЭОД соотно¬
сятся с процессами
предприятия
ФАЙЛЫ ДАННЫХ
Эта матрица показы¬
вает, какие Файлы
данных используются
плановыми или су¬
ществующими систе¬
мами
Рис. 6.3. Шаг 6 анализа, проводимого методом BSP, отоб¬
ражает структуру предприятия и использование им суще¬
ствующих систем с помощью четырех типов матриц, кото¬
рые изображены на рис. 6.4—6.7
тии. Выполняется это с помощью четырех матриц, схематически изобра¬
женных на рис. 6.3 и подробно показанных на рис. 6.4—6.7.
Назначение этих матриц — уточнить, как в текущий момент обра¬
ботка данных поддерживает делопроизводство. Они помогают опреде¬
лить пустоты и избыточность в ЭОД, а также ответственность руково¬
дителей. В частности, первые две матрицы на рис. 6.3 (подробнее — на
рис. 6.4 и 6.5) служат иллюстрацией тому, как административный пер¬
сонал использует текущие и планируемые системы и как они соотносятся
с процессами, определенными на рис. 6.1. Они помогают группе разра¬
ботчиков определить требования руководства к информационной под¬
держке.
80

ЪлраЯт
соеост
ПРОЦЕСС
ОРГАНИЗАЦИЯ
Основное ответственное и
принимающее решение лицо
директор
по планированию
'Х^ Основной участник процесса / Частичное участие в процессе
Юрист отделения
Директор по надран
Рис. 6.4. Функции и процессы предприятия (такие, как слева на рис. 6.1) отображаются
па существующие организационные структуры [2]
Президент
Вйцё^лрёзйдёнт
по финансам
Финансист- нон трал ер
Вице-президент по сбыту
-Управляющий контролем
заказов
Коммерческий директор
по электронике
Коммерческий директор
ло энергетике
Вйцёнтрёзйдёнт по лроёктнд-
конструкторским работам
вйц&Глрёзйдёнт
ню производству

Директор по производст¬
венным операциям
Директор Яо производств
венному планированию
-управляющий хозяйствен-
ной службой
Управляющий контролем
материалов^
-Румовддйтёлй ла материаль¬
но-техническому снабжению

БЕСЕДЫ С РУКОВОДИТЕЛЯ^
Стержнем анализа BSP являются беседы с руководителями, прово¬
димые с целью выяснения их отношения к перспективам предприятия,
потребностей в информации и стоящих перед ними задач. Проведение
\ ОРГАНИЗАЦИЯ
СИСТЕМЫ
•В
а
i
i
г
1
t
в
1
и'
1
в
*
I
^к
is
1
«и
ц
*1
А» ?
р
вв
1
•^ Аз
11
^ $
Аз Ш
в§
is
ч
!
В
к
&
SB
II
11
h
к
1
gt
8s
1
1
h
I*
P
Bi
^
II
Й
Ct
01
i
в
в
I
1
Аоступленив заказа
клиента
с/р
с/р
с/р
с/р
С/р
с/р
с/р
С/р
контроль за движением
за на зоо клиента о
С
С
С
с
С
С
С
С
c
c
Выписывание счетов
С
с
Технологический контроль
р
Залась/ готовой продукции
С
с
с
С
с
С
С
С
C
Список материалов
с
с
С
С
c
Запасы частей
с
с
С
с
с
с
с
контроль за движением
заказов на приобретение
с/р
с/р
с/р
с/р
с/р
с/р
с/р
Маршрутизация
с
С
С
С
Цеховый контроль
с
С
с
c
Планирование производст¬
венных мощностей
Р
р
р
Р
р
p
p
Гроссбух
р
р
Затраты
0
С
Издержки производства
с/р
с/р
с/р
с/р
с/р
с/р
с/р
с/р
c/p
c/p
c/p
Отчет а прибылях и.
убытках
С
С
С
Счета дебиторов
c
Счета кредиторов
С
С
С
p
'Счет капитала
С
с
С
c
Анализ сбыта
С
С
С
С
c
Платежная ведомость
с
С-текущая,	р-плановая^	с/р-текущая и плановая
Рис. 6.5. Существующие (или плановые) системы отображаются на организа¬
ционную структуру. В верхней части этой матрицы и слева в матрице на рис. 6.4
указано должностное положение руководителей. Следовательно, эти две матри¬
цы служат основой (частично) для бесед BSP с руководителями
таких бесед отражает шаг 7 на рис. 6.2. Эти беседы уточняют информа¬
цию, представленную матрицами на рис. 6.3. Они позволяют понять ра¬
боту предприятия, что необходимо для планирования информационных
систем.
К беседам обычно привлекаются руководители рангом ниже гене¬
рального директора: финансовый директор, лица, ответственные за про¬
изводственное планирование, материально-техническое снабжение, сбыт.
Они несут ответственность за те основные функции, что приведены в
82

'\^ПРОЦССС
система	\
Маркетинг
Коммерческие
операции
/Троентно-
хон струн-
горские
райо гы
Производство
Управление
материалами
управление
средства -
ми Рроиз-
оовстаа
админист¬
рирование
Финансы
Людские
ресурсы
Руководство
Оз
з
X
о
^
о
о.
X
X
03
ё
QJ
33
X
£
С)
□
гэ
X
X
OJ
Q
<ъ
X
X
<Ь
^
?3|
X
X
X
X
X
X
х
а
Сз <ъ
5х
^
хх
^
§
X
X
X
X
S'
33
Оз
х
X
§1
ХС1
5
1
сз*
i^
^
XX
9
t
13
33
^
i^
Я:
х
33
X
Q
<<1
СЗ
§
X
я
£
В
h
sg
J*
*1
it
0)
1
0
Sc
33
33
X
О
&
X
X
X
3i
X
3
х
3
X
0)
X
х
1
сз
X
3
X
^
33
1
X
X
X
зь
X
X
х
3
X
X
33
X
X
3
i
Qj
33
X
ЛЬ
X
X)
0Q
X
1
X
X
‘33
33
х>
^
X
^
X
33
X
£
QJ
*5
1
0)
33
<иХ
ыз
сл
XX
хх
*х
^
Эх
^5
о>
gg
З<3
^Х
хх
XX
1
1
си
1
X
£5
*$
11
в
X
^
Хх
3^
^х
«и
33
j
л
V
I
X
33
3“
X
X
Qj
X
§
X
X
X
х<и
55
хх
г>х
^2
$5
сиХ
3^
хс
<*)
!
*5
X
X
X
3
хг
S
X
X
X
§
§
X
а
к
£
X
X
ос
33
XX
<их
3^
ссх
X X
хх
Поступление заказа
клиента
с/Р
с/р
с/р
с/р
с/р
с/р
контроль за движение»
заказов клиентов
с
С
с
с
с
Выписывание счетов
С
С
Технологи четкий
контроль
р
Запасы готовой
продукции
с
с
с
с
с
Список материалов
с
с
с
с
с
Заласы частей
с
с
с
7&н троль за движением
заказов на приобретение
с/р
С/р
С/р
с/р
Маршрутизация
с
с
с
с
Цеховый контроль
с
с
с
Планирование производ¬
ственных мощностей
р
р
Гроссбух
р
р
Затраты
С
с
Издержки производства
—
—
С/р
С/р
С/р
С/р
(Течет о прибылях и
убытках

с
с
с
с
С
Счета дебиторов


с
Счета кредиторов
с
с
С
Счет капитала
с
с
С
С
1

Анализ сбыта
1
С
с
1
; Платежная ведомость
1 . ,
с
0
с
1
С-текущая, Р-планова^ с/р-текущая и плановая
Рис. 6.6. Процессы предприятия отображаются на существующие системы

верхней части рис. 6.4. Обычно таких бесед бывает около 20, хотя их
число зависит от размера и потребностей предприятия.
Как правило, администратор, оказывающий поддержку анализу,
помогает составить список опрашиваемых руководителей. Некоторых
пз них следует проинтервьюировать из тактических соображений, так
ФАЙЛ
\ ДАННЫХ
\
\
СИСТЕМА	\
к
§
X
сз
СГ>
о
Сз
*
сз
со
па
* (X
х
X
со
3
i
X
X
1
X
X
Q
к
х:
g
X
*аХ
^
s^
t>x
и
и ос
£5
3
X
X
X
па
1
‘X
i
X
X
<13
X
§
х
X
(X
X
^
1
*9
Q
X
х
X
<х
X
а
х
X.
X
X
X
X
&
ОС
х
КП
х
X
^
а-
<х
X
X
а
Зе
1
03
X
3
3
х
X
х
X
Г)
Хч
а
Поступление заноза
клиента
контрола за движением
■ заказов клиентов
1
. Выписывание счетов
Технологический контроль
Зала Со/ готовой продукции
Список материалов
Запасы частей
контроль га движением га-
юзов на приобретение
Маршру тиоация
• Цеховый нон троль
Планирование производ¬
ственных мощностей
Гроссбух
Затраты
1
издержки производства
Отчет о прибылях и
убытках
Счета дебиторов
Счета кредиторов
Счет капитала
Анализ сбыта
Платежная Ведомость
Рис. 6.7. Группе, проводящей BSP, необходимо понять, какие данные сущест¬
вуют в текущий момент и какие системы какими данными пользуются. Матрица,
подобная этой, относится как к существующим базам данных, так и к файлам
как не включив их в список опрашиваемых, можно вызвать у них не¬
довольство и оппозицию к выводам, полученным в результате анализа.
С руководителями высшего ранга следует беседовать в последнюю
очередь, поскольку по мере приобретения опыта совершенствуется мето¬
дика опроса и в беседе с руководителями могут быть разрешены сомне¬
ния, возникшие в процессе ранее проведенных опросов.
В беседах преследуют следующие цели:
1)	уточнить матрицы и собранные данные;
2)	определить необходимую для руководителей информацию и оце¬
нить ее;
3)	определить приоритет потребностей для будущих приложений;
84

4)	определить текущие задачи;
5)	добиться поддержки и участия руководства.
Матрицы часто имеют вид настенных схем, и их можно показать
опрашиваемым в начале интервью, чтобы они их уточнили. В частности
следует согласовывать (или модифицировать) список и описания про¬
цессов предприятия.
Для интервью типичны следующие вопросы:
1.	Каковы ваши обязанности? Отличаются ли они от тех, которые
приведены в организационной схеме?
2.	Каковы ваши основные функциональные задачи?
3.	С какими тремя серьезнейшими проблемами (ие только в теку¬
щий момент, но и в недавнем прошлом) вам пришлось столкнуться при
выполнении этих задач?
4.	Что не позволило вам их разрешить?
5.	Что требуется для их разрешения?
6.	Каково будет значение получения лучшей информации в этих об¬
ластях (в сэкономленных человеко-часах, денежных средствах, больших
возможностях и т. д.)?
7.	В каких других областях можно добиться самых крупных дости¬
жений при наличии лучшей информационной поддержки?
8.	Каково будет значение этих улучшений?
9.	Каковы могут быть убытки от неточной или несвоевременной ин¬
формации?
10.	Какую самую полезную информацию вы получаете? (Наилуч¬
шие аспекты текущих систем следует сохранить.)
11.	Чего бы вам хотелось добиться больше всего?
12.	Как бы вы определили свою текущую информационную под¬
держку относительно каждого из следующих пунктов:
типы информации,
своевременность,
точность,
адекватность,
стоимость,
логичность,
простота использования или ясность представления?
13.	Как вы сами оцениваете свою деятельность?
14.	Как вы оцениваете своих подчиненных?
15.	Какие другие виды оценок вы предполагаете осуществлять?
16.	Какие виды решений вы предполагаете принимать? Какие вычис¬
лительные средства могут помочь вам в принятии решений?
17.	Какие основные изменения ожидаются в вашей области в буду¬
щем году? В последующие два, четыре или шесть лет?
18.	Чего вы ожидаете и какие результаты хотели бы вы получить
в процессе данного анализа?
19.	Есть ли у вас какие-либо дополнительные замечания? (Этим
обычно хорошо закончить интервью.)
По возможности ответы на вопросы следует определять количест¬
венно, выражать в виде величин или раз/швать на такие элементы, ко¬
торые можно квантифицировать.
85

ОБРАБОТКА ИНТЕРВЬЮ
Теперь результаты бесед нужно суммировать структурно. Это вы¬
полняется так, как показано на рис. 6.8.
Каждая проблема или точка зрения, которую стоит записать, пред¬
ставляется в записи следующим образом:
Проблема
(или точка
зрения)
Решение
Оценка
Потребности
в информа¬
ционной
системе
Процессы
предприятия,
на которые
оказывается
влияние
Процесс пред¬
приятия, в кото¬
ром возникла
проблема
Н следующим этолам
ллонироВония
информационной
архитектуры
Рис. 6.8. Обработка данных, получаемых в результате бесед с руково¬
дителями
На рис. 6.9 представлены анализ и обработка результатов беседы
с одним из руководителей.
В некоторых случаях руководителю говорят о кажущихся пробле¬
мах, которые могут иногда оказаться реальными. Следует проанализиро¬
вать причины, их вызвавшие, и их последствия, по возможности кван¬
тифицированные. Предполагаемые проблемы, в отличие от установлен¬
ных, не заносятся в список, но если они считаются важными, их можно
поднять до уровня установленных, проведя дополнительное интервью.
Каждому опрошенному руководителю представляется для подтвержде¬
ния такой сводный лист, как на рис. 6.9.
86

Опрашиваемый: X. Р. Циммер, вицепрезидент по производству
Член группы планирования: Мел Лксарбен
Дата: август 24, 1978
Основная проблема
Решение проблемы
Оценка
Потреб¬
ности в
информа¬
ционных
системах
Затраги¬
ваемый
процесс
Причин¬
ный
процесс
Отсутствие эффек¬
тивного планиро¬
вания производст¬
ва отрицательно
сказывается на
рентабельности
Механизиро¬
ванное плани¬
рование произ¬
водства
Поднять при¬
быль; улучшить
отношения с
клиентами;
улучшить об¬
служивание
поставок
Плани¬
рование
произ¬
водства
Произ¬
водство
Произ¬
водство
Повышение отчет¬
ности совета ди¬
ректоров; потреб¬
ность в финансо¬
вой и администра¬
тивной ревизии
Лучшая ин¬
формация
Повысить роль
приглашенных
директоров
Система
стоимо¬
сти
Финансы
Финансы
Отсутствие воз¬
можности задать
вопрос: «А что ес¬
ли?» по калькуля¬
ционным ведомо¬
стям
Возможность
механизирован¬
ного оператив¬
ного ведения
калькуляцион¬
ных ведомостей
Поднять при¬
быль; улуч¬
шить отношения
с клиентами
Система
стоимо¬
сти
Финансы
Админи¬
стриро¬
вание
Невозможность
рассмотреть доста¬
точное число аль¬
тернатив в плани¬
ровании
Финансовое мо¬
делирование
(возможность
задать вопрос:
«А что если?»)
Поднять при-
быль; сократить
потери; улуч¬
шить рост
Модели¬
рование
плани¬
рования
Финан-
сы/ру-
ковод-
стзо
Управ¬
ление
Отсутствие воз¬
можности опреде¬
лять и выдвигать
квалифицирован¬
ных сотрудников
Более полная
информация о
кадрах
Удерживать на
работе хоро¬
ших сотрудни¬
ков; улучшать
моральный кли¬
мат
Система
учета
квали¬
фикации
Штат
Штат
Недостаток опыта
в области сбыта
отрицательно ска¬
зывается на росте
и прибылях
Большая осве¬
домленность в
области сбыта
и больше лю¬
ден, имеющих
опыт в этой об¬
ласти
Удовлетворять
требования
клиентов
Сбыт
Штат
Отсутствие воз¬
можности эффек¬
тивно перемешать
людей; низкая
производитель-
ность, длительное
обучение
Описание ра¬
бот, выполня¬
емых в каждой
области
Правильно ру¬
ководить людь¬
ми; повысить
качество работ;
повысить про¬
изводительность
Статус
заказа
Штат
Торго¬
вые опе¬
рации
87

Продолжение
Основная
проблема
Решение
проблемы
Оценка
Потреб¬
ности в
информа¬
ционных
системах
Затраги¬
ваемый
процесс
Причин¬
ный
процесс
Плохие отношения
с клиентами; поте¬
ря прибылей, из¬
лишние запасы
Лучший анализ
продажи и пла¬
нирования про¬
изводства; бо¬
лее полные от¬
четы о покупа¬
телях
Улучшить отно¬
шения с клиен¬
тами
Статус
заказа
Сбыт
•
Торго¬
вые one-
.рации
Плохие отношения
с клиентами; поте¬
ря прибылей, из¬
лишние запасы
Лучший анализ
продажи- и пла¬
нирования про¬
изводства; бо¬
лее полные от¬
четы о покупа¬
телях
Улучшить отно¬
шения с клиен¬
тами
Плани¬
рование
произ¬
водства
Сбыт
Произ¬
водство
Плохие отношения
с клиентами; поте¬
ря прибылей, из¬
лишние запасы
Лучший анализ
продажи и пла¬
нирования про¬
изводства; бо¬
лее полные от¬
четы о покупа¬
телях
Улучшить отно¬
шения с кли¬
ентами
Анализ
продажи
Сбыт
Сбыт
Небольшие, более
частые заказы;
слишком критиче¬
ское время подго¬
товки; более высо¬
кая стоимость об¬
работки заказов
Анализ тенден¬
ций заказов /
стоимости
Лучше контро¬
лировать стои¬
мость
Анализ
террито¬
рии сбы¬
та
Торго¬
вые опе¬
рации
Торго¬
вые опе¬
рации
Рис. 6.9. Типичный анализ и обработка результатов бесед с руководителями. Элементы
заполнения таких карт сортируются по причинному процессу (первый столбец) [2]
Теперь перечисленные проблемы и точки зрения можно разделить
на три категории:
1.	Проблемы, которые не затрагивают ЭОД или информационные
системы. Их передают ответственному лицу, поддерживающему анализ.
2.	Проблемы, связанные с существующими информационными систе¬
мами.
3.	Проблемы, связанные с возможными в будущем информационны¬
ми системами.
Чтобы подготовиться к следующим шагам анализа, проблемы сор¬
тируют по процессам предприятия (процессы перечислены слева на
рис. 6.1). В большинстве случаев такую сортировку выполняют вручную
с помощью ножниц и клея или прибегнув к услугам терпеливой маши¬
нистки.
88

ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ АРХИТЕКТУРЫ
Имея список процессов и классов информации, определяем инфор¬
мационную архитектуру, начиная с составления матрицы, такой, как на
рис. 6.1, и выполняем все этапы, представленные на рис. 5.2—5.7. Чтобы
прояснить допустимые последовательности разработки, можно составить
матрицу предпосылок, см. шаг 9 на рис. 6.2; на шаге 10 определяются
приоритеты в реализации архитектурных частей.
ОПРЕДЕЛЕНИЕ ПРИОРИТЕТОВ В РЕАЛИЗАЦИИ АРХИТЕКТУРЫ
На осуществление всей информационной архитектуры уйдут годы.
Необходимо решить, что делать в первую очередь, и наметить в общем
последовательность этапов реализации.
Желательно, чтобы компонентами архитектуры, осуществляемыми
в первую очередь, были те, которые помогают решить насущные про¬
блемы и отдача от которых будет быстрой. Реализацию следует прово
днть на основе постепенных затрат, причем различные группы одновре¬
менно должны выполнять множество проектов. В выборе первых под¬
систем для реализации необходимо прежде всего руководствоваться
результатами анализа бесед с руководителями.
Методология BSP рекомендует подразделять критерии выбора при
оритетов на четыре категории:
1.	Потенциальные преимущества
осязаемые,
неосязаемые,
прибыль на инвестированный капитал (некоторые из них требуют
ценностных оценок суждения).
2.	Организационное влияние
число затрагиваемых организаций и люден,
качественный эффект,
влияние на достижение целей.
3.	Вероятный успех
степень приемлемости,
вероятность полного осуществления,
предпосылки,
длительность реализации,
риск,
имеющиеся ресурсы.
4.	Требования
оценка существующих систем,
связи с существующими системами,
запросы.
В отношении каждой из этих категорий предлагается ранжировать
подсистемы, предназначаемые для возможной реализации, по шкале or
1 до 10. Тогда руководство сможет решать, на что направлять средства
и таланты разработчиков.
Поскольку с информацией следует обращаться как с деловым ре
сурсом, проекты информационных систем должны оцениваться руково¬
дителями таким же образом, как и деловые проекты. Следует опреде¬
лять прибыль на инвестированный канита !, кадровые ресурсы и воз¬
можный риск, как и при любом начинании Это осуществимо, если в
анализе организации принимают участие руководители достаточно вы¬
сокого уровня.
89

ПЕРЕСМОТР УПРАВЛЕНИЯ ИНФОРМАЦИОННЫМИ СИСТЕМАМИ
Шаг 11 на рис. 6.2 представлен параллельно шагам 9 и 10, но он
может следовать и за ними, если этого требует проект архитектуры.
В целях лучшей реализации информационной архитектуры иногда
необходимо изменить управление информационными системами, напри¬
мер, улучшить администрирование данными и моделирование данных.
Осуществление информационной архитектуры — процесс длитель¬
ный. Может потребоваться преобразование многих существующих си¬
стем, их исключение или сохранение с созданием «моста», соединяюще¬
го их с новой архитектурой, что отражено в работе [1, гл. 25]. За годы
реализации архитектуры предприятие претерпевает изменения. Анализ
BSP — это одноразовое мероприятие, и требуется план непрерывного
пересмотра с целью улучшения создаваемой архитектуры.
Процессы управления информационными системами уточняют и из¬
меняют с изменением как технологической, так и деловой стратегии. Не¬
обходимы средства для непрерывного планирования, измерения и кон¬
тролирования ресурсов информационных систем.
После проведения анализа методом BSP особенно важно решить,
кто персонально или какая группа людей будет нести ответственность
за непрерывное планирование информационного ресурса по окончании
BSP.

ГЛАВА 7
АНАЛИЗ ОБЪЕКТОВ НА ПРЕДПРИЯТИИ
ВВЕДЕНИЕ
Большое значение методологии BSP заключается в том, что она по¬
могает вовлечь в работу высшее руководство. Анализ, проведенный
методом BSP, дает общую картину ЭОД и позволяет установить прио¬
ритеты. Однако для проектирования баз данных он не служит большим
подспорьем, поскольку не позволяет получить представления об их со¬
держимом.
Главный руководитель ЭОД:
Мы затратили 180 000 долларов на анализ методом BSP. Все поздравля¬
ли друг друга, отмечая, какой это хороший анализ, но, честно говоря, я не
знаю, что делать с его результатами. Он ничего не говорит мне о том, как при¬
ступить к проектированию тех баз данных, которые, как мы уже знаем, нам
нужны.
Классы данных BSP, или предметные базы данных, рассмотренные
в гл. 4, выбираются несколько произвольно. Основная цель планирова¬
ния сверху вниз — ликвидировать избыточность, а также несоответствие
данных, а вместе с этим и дублирование прикладного программирова¬
ния и ведения, на что затрачиваются огромные ресурсы ЭОД. Предмет¬
ные базы данных, или классы данных, являются слишком крупными ка¬
тегориями для осуществления такой задачи.
В компании ИБМ метод BSP применялся для планирования систем.
Результат оказался не вполне удовлетворительным. Вот как комменти¬
рует это пользователь из корпорации ИБМ [11]: «Обнаружились два
главных недостатка: 1) потребовался длительный процесс открытий,
причем результаты зависели от умения и изобретательности людей, про¬
водивших анализ; 2) связь с реальными базами данных и системами
была неадекватная, затрудняющая общение с персоналом ЭОД и пре¬
пятствующая разработке специфического плана информационных
систем».
В настоящей главе рассматриваются вопросы, связанные с получе¬
нием более детальной картины сверху вниз, а также с анализом и схе¬
матизацией объектов предприятия. На уровне объектов становится воз¬
можным определение нежелательной избыточности. На этом уровне
можно выяснить, что составляет предметную базу данных и границы си¬
стем, пользующихся ими. Схема, приведенная на рис. 5.6, не обрисовы¬
вает точные границы систем.
91

Консультант по стратегическому планированию:
Анализ BSP выявил для нас 25 систем. Однако эти системы не были оп¬
ределены или разработаны до такого уровня, когда они имели бы четкие гра¬
ницы. Не было определенных границ и соответствующих показателен.
Первой из этих систем была финансовая. Анализ определил приоритет этой
системы как I.1 Работа над ней продолжалась три года, и казалось, что невоз¬
можно положить конец росту этой системы. У нее не было четких границ. К ней
непрерывно добавлялись новые области данных.
Как мы уже говорили, к централизованному планированию можно
подходить на нескольких уровнях
уровень предметных баз данных,
Рис. 7.1. Три уровня подхода к центра
. На рис. 7.1 показаны три уровня:
описанный в предыдущих главах,
уровень объектов, описанный в на¬
стоящей главе, и уровень объектов
и действий, описываемый в следую¬
щей главе.
Для практической реализации
баз данных объекты необходимо
группировать. Такой процесс груп¬
пировки дает по существу предмет¬
ные базы данных. Затем эти пред¬
метные базы данных можно исполь¬
зовать в системной схеме более вы¬
сокого уровня. Иллюстрацией этому
служит рис. 7.1.
В тех случаях, которые изучал
автор, планирование сверху вниз на
уровне объектов заняло не больше
времени, чем анализ типа BSP (что
может показаться удивительным).
В руководстве по BSP говорится,
лизованному планированию	что сам анализ можно завершить
недель за восемь (включая подго¬
товку). В большинстве случаев на него уходило гораздо больше време¬
ни. Обычно — шесть месяцев. Одной крупной аэрокосмической кор¬
порации понадобилось два года, чтобы выполнить анализ BSP в одном
подразделении. После чего пришли к выводу, что его результаты не при¬
годные в качестве централизованного руководства, и анализ продол¬
жался на уровне объектов, на что потребовалось шесть месяцев.
ОБЪЕКТЫ ПРЕДПРИЯТИЯ
Анализ объектов представляет собой попытку централизованно
(сверху вниз) определить объекты предприятия. Объект — это то, о чем
мы храним данные. Объект может быть осязаемым: служащий, деталь,
заказчик, станок, контора. Он может быть неосязаемым: название рабо¬
ты, структурное подразделение, результаты деятельности которого изме¬
ряются полученной прибылью, ассоциация, финансовое ассигнование,
приобретение, оценка или заявление о выплате страхового возмещения.
Объекты рассматриваются в вставке 7.1.
На среднем по размерам предприятии обычно насчитывается не¬
сколько сотен объектов. В крупной корпорации, например, если она за¬
нята одноплановым производством, объектов не намного больше, чем
в мелкой. Некоторые крупные корпорации заняты многоплановым про-
92

изводством, например корпорация сталелитейная и нефтедобывающая
одновременно. В таких корпорациях объектов будет больше. Набор
объектов с течением времени меняется незначительно, если только пред¬
приятие не переходит к совершенно иному типу деятельности.
Атрибуты, относящиеся к объекту, которые мы храним, помещают¬
ся в записи. В крупной корпорации нередко бывает много тысяч типов
записей. Если, однако, провести подробный анализ (сверху вниз), то
можно обнаружить, что достаточно иметь только сотни типов записей.
Дублирование обусловлено отсутствием централизованного планиро¬
вания.
Дублирование приводит к большему, чем необходимо, объему при¬
кладного программирования, сложному ведению, трудностям в получе¬
нии итоговой информации для руководства, а также к недостаткам в
управлении предприятием. Руководители предприятия часто ощущают
недостатки в управлении острее, чем руководители ЭОД, но они не зна¬
ют, что предпринять.
Вставка 7.1. Объекты
Объект — это нечто (реальное или абстрактное), данные о чем мы храним.
Примеры объектов: КЛИЕНТ, ДЕТАЛЬ, СЛУЖАЩИЙ, СЧЕТ-ФАКТУРА,
СТАНОК, ТОРГОВЫЙ АГЕНТ, ОТДЕЛЕНИЕ, РЕКЛАМА ТВ, СКЛАД,
СКЛАДСКОЙ БУНКЕР, НАРЯД-ЗАКАЗ, ОТЧЕТ О СМЕНЕ, СПЕЦИФИКА¬
ЦИЯ ИЗДЕЛИЯ, СЧЕТ В ГРОССБУХЕ, ОПЛАТА, ВЫРУЧКА, ДЕБИТОР,
КРЕДИТОР, ЗАПИСЬ АНАЛИЗА ДЕБИТОРОВ.
Именем объекта должно быть существительное, за которым иногда следу¬
ет слово-определитель. Можно представить, что объект как бы обладает свой¬
ствами существительного.
У объекта имеются различные атрибуты, которые мы хотели бы записать,
такие, как цвет, денежная стоимость, процентная утилизация или имя.
Термин объект—это сокращение, обозначающее тип объекта или экземп¬
ляр объекта. Аналогичным образом, термин запись используется для обозначе¬
ния типа записи или экземпляра записи; то же относится к элементу данных,
атрибуту и другим словам, описывающим данные.
Тип объекта — это именуемый класс объектов, которые имеют один н тот
же набор типов атрибутов. Например, СЛУЖАЩИЙ является типом объекта.
Экземпляром объекта является одна специфическая реализация типа объ¬
екта. Например, Б. ДЖ. УОТКИНС — это экземпляр типа объекта СЛУЖАЩИЙ.
В этой книге, когда мы говорим объект, мы имеем в виду тип объекта, ког¬
да говорим запись, имеем в виду тип записи, и т. д. Обычно значение сокра¬
щенного термина понятно.
Для каждого типа объекта у нас имеется не менее одного типа записи.
Иногда ее называют записью объекта. Запись СЛУЖАЩИЙ, например, является
записью объекта, содержащей данные об объекте СЛУЖАЩИЙ.
Нередко для хранения данных об одном типе объекта Требуется более од¬
ного типа записи, что вызывается нормализацией данных (процесс разбиения
данных на отдельные записи, каждая из которых имеет четкую структуру [1]).
У объекта обычно имеется элемент данных, который однозначно его иден¬
тифицирует. Например, НОМЕР СЛУЖАЩЕГО является однозначным иденти¬
фикатором объекта СЛУЖАЩИЙ. Этот элемент данных используется в качест¬
ве первичного ключа записи объекта.
'Когда с одним объектом связано множество записей, такой однозначный
идентификатор состоит из нескольких первичных ключей, соединенных вместе
(конкатенированных). Например, в качестве первичного ключа у записи ДЕЛО
СЛУЖАЩЕГО служат два элемента данных: НОМЕР СЛУЖАЩЕГО и
ДАТА. ‘
В некоторых записях содержится информация о связи между объектами.
Например, ПОСТАВЩИК и ДЕТАЛЬ являются типами объектов. Их однознач¬
ные идентификаторы — ПОСТАВЩИК # и ДЕТАЛЬ #. Для хранения подроб¬
ностей, относящихся к детали, поставляемой поставщиком, например ее стои¬
мость и доставка, используется запись с этими двумя первичными ключами.
Их иногда называют данными пересечения. ’У записи ПОСТАВЩИК-ДЕТАЛЬ
93

имеются два первичных ключа, однозначно идентифицирующих ее, — ПОСТАВ¬
ЩИК # и ДЕТАЛЬ #. Такую запись можно назвать записью объекта пересе¬
чения.
Карта объектов показывает запись объектов, включая имеющие более од¬
ного первичного ключа, и ассоциации между записями объектов. Она не пока¬
зывает элементы данных в этих записях, потому что носит обзорный характер
и должна составляться относительно быстро. Элементы данных определяются
позднее с помощью детального моделирования данных. Карта объектов приво¬
дится на рис. 7.9.
ИДЕНТИФИКАЦИЯ ОБЪЕКТОВ
Идентификация объектов на предприятии часто выполняется анали¬
тиками-пользователями, которые разбираются в производстве. Их нуж¬
но обучить распознавать объекты.
Иногда планировщики просили пользователей идентифицировать
что-либо, менее определенное, чем объект. Например, они говорили:
«Идентифицируйте информационные группы, с которыми вы работаете».
Приведенное здесь определение объекта является точным и его легко
понять. Необходимо, чтобы аналитики-пользователи идентифицировали
объекты и ассоциативные связи между ними. Расплывчатая формули¬
ровка «информационные группы» для этого не годится.
Разные аналитики-пользователи часто определяют один и тот же
объект, давая ему различные названия: например, «КЛИЕНТ» и «ЗА¬
КАЗЧИК». Координирующий аналитик, профессионал в области ЭОД,
имеющий опыт работы с базами данных, должен вылавливать эти сино¬
нимы с помощью своей группы планировщиков. Каждый объект должен
называться одним именем. Это иногда вызывает затруднения, так как
пользователи в различных областях желают сохранить свои собственные
названия («КЛИЕНТ» и «ЗАКАЗЧИК»). Нередко приходится прибегать
к помощи словаря синонимов, чтобы соотнести названия, даваемые поль¬
зователями, с выбранным для модели объекта именем.
Когда соглашение об объектах достигнуто и объекты-дубликаты ис¬
ключаются, подробные описания объектов можно хранить в словаре.
УЧАСТИЕ ВЫСШЕГО РУКОВОДСТВА В АНАЛИЗЕ ОБЪЕКТОВ
На основании опыта проведения анализа объектов на многих пред¬
приятиях можно утверждать, что участие высших руководящих работни¬
ков (не из области ЭОД) требуется здесь так же, как и в других видах
централизованного планирования. Качество результатов в огромной сте¬
пени связано со степенью участия в анализе высшего руководства.
Участие руководства в анализе объектов является необходимым в
основном потому, что при этом создается возможность контроля за вы¬
бором объектов, которые используются для информационных систем
предприятия. В большинстве корпораций используемые данные никог¬
да не отображались тщательным образом. Когда такое отображение вы¬
полняется впервые, обнаруживаются всевозможные отклонения, которые
следует устранить. Побочным результатом такого анализа, о чем будет
говориться в гл. 8, часто бывает перестройка предприятия, что является
заботой высшей администрации.
Как правило, непрактично строить полную модель данных всей кор¬
порации сразу (исключение составляют небольшие организации). Ана¬
лиз объектов служит более простой цели.
94

Моделирование дан¬
ных связано с функцио¬
нальными зависимостя¬
ми, что описывается в ра¬
боте [1, гл. 7]. Функцио¬
нальные зависимости ана¬
лизируются с целью по-
лучения
оптимальных
структур данных в треть¬
ей нормальной форме [I].
С помощью анализа
объектов
определяют
объекты в организации и
стараются исключить из¬
быточность в них. Таким
образом можно
нать, что клиент
чик — это один
объект. Между
ми существуют
распоз-
и заказ-
и тот же
объекта-
ассоциа-
Рис. 7.2. Карта объектов для локального участка
тивные связи. Например,
в одном филиале работает
много торговых агентов; у одного торгового
агента имеется много заказчиков. В соответствии с этим составляют
такие схемы, как на рис. 7.2.
АССОЦИАТИВНЫЕ СВЯЗИ МЕЖДУ ОБЪЕКТАМИ
Представляя ассоциации между объектами, мы проводим связую¬
щие линии нескольких типов. С объектом А может ассоциироваться
один объект В. Это называется ассоциацией (связью) один к одному.
Когда с объектом А могут ассоциироваться многие экземпляры объек¬
та В, то это называется связью один к многим. Чтобы показать ассоциа¬
ции между объектами, на карте объектов проводим линии между бло¬
ками объектов.
Ассоциация один к одному представляется стрелкой с одной голов¬
кой. Так,
в
означает, что для одного экземпляра объекта А будет существовать
всегда один и только один экземпляр объекта В.
Связь одного к многим представляется стрелкой с двумя головками.
Так, .
в
fl
означает, что для одного экземпляра объекта В может существовать
много экземпляров объекта А.
Можно показать связь А с В и связь В с А на одной и той же линии:
я		 в

Примером служит:
Филиал
Торговый
агент
Это означает, что в филиале может быть более одного торгового агента.
Торговый же агент ассоциируется только с одним филиалом.
Нуль, помещенный на линии связи, означает, что у этой связи мо¬
жет быть нуль объектов. Так,
с 		—е*- о
означает, что с одним экземпляром объекта С может ассоциироваться
один или нуль экземпляров объекта D.
Теперь читателю нужно посмотреть на рис. 7.2 и убедиться в том,
что он понимает значения показанных связей.
ПРОДУКТ/.МАТЕРИАЛ на рис. 7.2 является конкатенированным
объектом, означающим, что данные будут ассоциироваться со специфи¬
ческим ЛААТЕРИАЛОМ, используемым в специфическом ПРОДУКТЕ,
и что эти данные нельзя в достаточной мере идентифицировать с помо¬
щью только одного ПРОДУКТА или одного МАТЕРИАЛА. Он может,
например, показывать количество данного материала, используемое в
данном продукте.
Некоторые связи являются взаимно исключающими. Если А состоит
в связи или с В, или с С, но не с обоими, мы рисуем:
Поперечная линия, соединяющая две связи, показывает, что они явля¬
ются взаимно исключающими. Например,
Некоторые связи являются взаимно сопряженными. Другими слова¬
ми, если А связано с В, то Л должно быта также связано с С. Это по¬
казано с помощью двойных поперечных линий, соединяющих ассо¬
циации:
96

Например,
Замечания о других обозначениях
В моделировании данных иногда используют два других обозначения.
Одно из них — «вороний след» — обозначает связь один к многим)
Филиал
у Торговый
n агент
другое — небольшая поперечная черта — обозначает связь один к одному:
Филиал
Торговый
агент
В обоих случаях для ассоциации «один» используется линия без всякой
отметки (как линия связи от ТОРГОВОГО АГЕНТА к ФИЛИАЛУ).
Для детального моделирования данных единственным и наиболее важным
входом служит функциональная зависимость [1]. Эти же обозначения не могут
показывать функциональную зависимость. Кроме того, нам иногда требуется
линия без всякой отметки, показывающая, что мы еще не знаем этой зависимо¬
сти или что она не имеет значения. Поэтому мы не рекомендуем использовать
эти обозначения. Нотация, приведенная в данной книге, хорошо зарекомендо¬
вала себя на практике как для схематизации объектов, так и для детального
моделирования данных.
КАРТЫ ОБЪЕКТОВ И МОДЕЛИ ДАННЫХ
Будем называть схемы, подобные рис. 7.2, картами объектов. Слово
«карта» выбрано с той целью, чтобы отличать эту схему от «модели»
данных. Модель данных построена с гораздо большей точностью и отно¬
сится к данным в третьей нормальной форме с последующей тщатель¬
ной идентификацией первичных ключей. Некоторые из них могут быть
сложными конкатенированными ключами [1].
Модель данных получают в результате синтеза представлений ко¬
нечных пользователей, объединенного с анализом стабильности, выпол¬
ненным по результатам, которые приведены в работе [1, вставка 13.1 и
гл. 12]. Карта объектов — это просто свод объектов предприятия, в ней
часто отсутствуют наиболее сложные конкатенированные ключи.
Полное моделирование данных занимает гораздо больше времени,
чем определение объектов предприятия. Этот процесс слишком длитель¬
ный, чтобы он мог сохранять к себе интерес со стороны высшего руко¬
водства. А этот интерес необходимо поддерживать в ходе анализа объ¬
ектов, отражающего действительные информационные потребности кор¬
порации.
97

Обычный поверхностный подход к проекту базы данных заключа¬
ется в идентификации объектов, данные о которых следует хранить, и
записи тех атрибутов, которые будут с ними связаны. В некоторых слу¬
чаях каждый список атрибутов дается в третьей нормальной форме.
Такой подход «срабатывает» в учебных условиях, но он не дает хороших
результатов в реальных условиях корпорации или правительственного
учреждения. Процесс кропотливого моделирования данных не имеет
никакой адекватной сокращенной замены.
У нас была возможность сравнить в некоторых случаях структуры
данных, спроектированные с помощью облегченного подхода в виде кар¬
тирования объектов и с помощью канонического синтеза. Результаты
были различные. Для хорошего проекта базы данных требуется как
анализ объектов, рассматриваемый в настоящей главе, так и моделиро¬
вание данных, описанное в томе 1 работы [1]. Эти два подхода допол¬
няют и проверяют друг друга.
ПЛАНИРОВАНИЕ СВЕРХУ ВНИЗ И ПРОЕКТИРОВАНИЕ
СНИЗУ ВВЕРХ
Планирование сверху вниз часто отличается от проектирования
снизу вверх. Планирование сверху вниз представляет собой набор про¬
цессов, которые описываются в этой книге. Они показаны слева на
рис. 7.3. Проектирование снизу вверх является процессом детального
моделирования данных, который приводит к физическому проекту базы
данных и созданию процедур. На рис. 7.3 оно показано справа.
Схема
систем
Модель предприятия
Анализ Определение Анализ Анализ
BSP Ю№*1К ^ичесних управления
баз барных факторов ла целям
успеха /
г
Анализ '
объектов
Анализ
групп
объектов
марта
разделенных
объектов
Физический
проект
базы данных
Анализ
распределения
пр едприятия ^^^ |||
марта
объектов
Анализ ис¬
пользования'
данных
модель
данных
корта логического
доступа
Группы объектов или
предметные базы
данных
Структурные
программы
Скелет
кода
Схемы
действий
1
Манони чес ний
син тез
Предо табле-
ния поль -
зобателей
1 $
5»
1 ^
1 &
Анализ Ш
представ-rd
лений [/а
польза- Kd
вотелей [/а
Группа каждого
объекта
Рис. 7.3. Планирование сверху вниз и проектирование снизу вверх
Во многих организациях выполняется планирование информации
сверху вниз в той или иной форме. Называют его по-разному. Часто оно
осуществляется недостаточно детально и поэтому не может служить ру¬
ководством к следующему шагу проектирования базы данных.
Планирование сверху вниз и проектирование снизу вверх не следу¬
ет считать отдельными и несовместимыми процессами. Проектирование
98

снизу вверх служит продолжением планирования сверху вниз. Модель
данных — это то же самое, что карта объектов, только выполнена она
более детально. От этапов более детализированного анализа идет об¬
ратная связь, которая заставляет вносить уточнения в общую картину,
полученную с помощью анализа, проведенного сверху вниз.
Это аналогично тому, как пишут учебник. Автор знает цель и назна¬
чение учебника, а также ряд задач. В соответствии с этим он должен
сначала составить оглавление и наметить приблизительное содержание
каждой главы. Затем он пишет каждую главу по очереди. По мере ра¬
боты какие-либо подробности заставляют его изменять оглавление и
краткое содержание глав.
Насколько подробным должно быть оглавление и краткое содержа¬
ние? Авторы могут спорить по этому вопросу. Но книга получится луч¬
ше, если планирование было выполнено более тщательно. То же верно
и для планирования сверху вниз баз данных. Оно должно быть выпол¬
нено тщательно, но не настолько подробно, чтобы сдерживать разра¬
ботку ЭОД.
Составление оглавления или создание карты объектов должно вы¬
полняться быстро. Не следует идентифицировать объекты слишком уж
точно. Не следует окончательно определять их ключи и конкатенирован¬
ные ключи. К этим деталям приходят позднее, при моделировании
данных. Подробное моделирование данных приводит к изменениям в
карте объектов. Чтобы подчеркнуть быстроту представления общей кар¬
тины для первоначально картируемых объектов, можно употребить
термин приближенно определенный объект.
ОБЪЕМ АНАЛИЗА
В начале анализа объектов необходимо определить, в каком объеме
должна исследоваться организация. Если корпорация небольшая, то она
должна изучаться целиком. Если это корпорация — гигант, то надо ис¬
следовать ее по частям.
Требование к простоте анализа объектов диктуется желанием рас¬
смотреть как можно больший участок, чтобы выявить общность объек¬
тов как можно в более широком диапазоне.
Аналитик объектов:
Важно было раскрыть всю интеграцию по вертикали. Эта компания сама
добывает глину, изготовляет кирпичи, делает оконные рамы, выращивает лес,
пилит древесину, сушит лесоматериалы, проектирует и строит здания в соответ¬
ствии с требованиями клиентов. Всего в компании выявлено около 500 объек¬
тов. Анализ занял почти пять месяцев.
ИЗБЫТОЧНАЯ ОБРАБОТКА
Мы подчеркивали, что в среде файлов или в среде баз данных
II класса, где многие аналитики создают свои собственные данные, про¬
исходит их дублирование. То, что большой объем дублируемого при¬
кладного кода также существует в большинстве корпораций, менее явно.
Использование баз данных не всегда исключает дублирование приклад¬
ного кода или дублирование обработки. Не общающиеся между собой
аналитики часто специфицируют дублируемые случаи использования
одной и той же базы данных.
99

В одной небольшой текстильной компании обнаружили существова¬
ние девяти отдельных транзакций для получения товаров. Каждая тран¬
закция по существу выполняла один и тот же набор операций, которые
приводили к записи приема материалов. В этой компании товар получа¬
ли в ряде отдельных мест. Для каждого из них в разное время были
разработаны документы, для обработки которых создавались приклад¬
ные программы. Таким образом, было разработано девять различных
комплектов прикладных программ, а хватило бы одного. Каждый комп¬
лект повышал стоимость ведения программ.
Эти девять отдельных транзакций казались несколько различными,
но когда данные на документах были изучены, оказалось, что они, по
существу, одинаковые. Не было никакой необходимости в девяти разных
наборах объектов. Это выявилось в результате анализа объектов кор¬
порации.
Дублирование функций часто происходит по мере роста и развития
компаний. На это расходуется значительный объем ресурсов ЭОД. Од¬
ной из задач анализа объектов должно быть как можно более полное
исключение ненужного дублирования в обработке данных.
Мы уже говорили, что в большинстве корпораций данные превра¬
тились в беспорядочную кашу, которая приводит в ужас при проведении
их координированного анализа. Логика, однако, тоже бывает путаной,
со многими ненужными дублированиями. Отдельные системные анали¬
тики (часто пользующиеся структурным анализом) создают свои собст¬
венные процессы, не осознавая, что дублируют работу друг друга.
Консультант, выполняющий анализ объектов:
Каждый отдел решает свою собственную конкретную задачу, обычно не
заглядывая в другие отделы и не спрашивая: «Привет, у вас тоже такая проб¬
лема?» В результате мы обнаружили, например, функцию получения товаров в
отделе вязки, в отделе упаковки, на складе сырья и т. д. Они все получали
сырье или полуфабрикаты.
Теперь, когда мы смотрим на это через призму анализа объектов, мы ви¬
дим, что сырье является самостоятельным объектом, присущим всем этим от¬
делам. Нам нужен один набор прикладных программ, а не девять.
Администратор данных:
Прессовка пластмассы — непрерывный процесс. Ему сопутствует набор
объектов. Область вязки на фоне этого процесса кажется совершенно иной, но
в действительности это тоже непрерывный процесс, и мы пришли к выводу,
что для него можно использовать те же объекты. С другой стороны, шитье
одежды можно представить с помощью списка материалов, так что этот про¬
цесс совершенно иной. Все производство мы вместили в эти два широких потока.
Система бухгалтерского учета является общей для обоих потоков.
Для всей фабрики нам потребовалось всего ПО объектов. Говорили, что
было 1000 элементов данных.
УЧАСТИЕ РУКОВОДСТВА
Когда к анализу объектов привлекаются руководители, это застав¬
ляет их задуматься, какие объекты необходимы для работы организа¬
ции. Какие объекты требуются для того, чтобы давать им нужную ин¬
формацию?
100

Администратор данных:
Участие в определении данных заставило руководителей в области склади¬
рования задуматься, действительно ли им требовался контроль за складскими
бункерами. Нужна ли была им запись о продукте или запасе, в которой просто
говорилось, что в запасе имеется такое-то число единиц, или они действительно
были заинтересованы в том, чтобы знать местоположение этого запаса на скла¬
де? Это заставило руководителей-пользователей произвести оценку требуемых
данных и значения уровня их детализации для управления ходом работ. Они
вынуждены были всерьез задуматься о преимуществах такого уровня детали¬
зации и о том, действительно ли важно для них вести доскональный контроль
за данными. Например, одежда состоит из ряда компонентов, а каждый компо¬
нент изготавливается из определенного материала. Им пришлось подумать на¬
счет списка материалов для одежды. Нужно ли им было определять каждый
компонент в этом списке или они могли довольствоваться более приближенным
подходом и сказать, что на это изделие идет определенное общее количество
материала каждого типа?
Профессионалам в области ЭОД обычно трудно формулировать
такие вопросы. Только руководство знает, как в действительности функ¬
ционирует корпорация и как можно совершенствовать ее работу.
Когда высшее руководство готово принять участие в анализе, по
крайней мере уделяя этому хотя бы часть своего времени, то часто меж¬
ду ним и работниками ЭОД устанавливается взаимопонимание. Анализ
объектов становится для них общим делом, и никакой технической тер¬
минологии не требуется. Руководителей (не из области ЭОД) следует
научить различать объекты, тогда они смогут идентифицировать их в
своих областях, а умение проводить нормализацию первого уровня по¬
может им понять, что представляют собой объекты.
Люди, далекие от ЭОД и потому не имеющие шор в виде традици¬
онного мышления относительно электронной обработки данных, иногда
распознают те случаи, когда традиционное представление о физической
организации данных ограничивает творческие процессы профессионалов
в области ЭОД. С другой стороны, специалистов не из области ЭОД
ограничивают их рассуждения в терминах существующих систем. Край¬
не необходимо направлять их мысли в творческое русло. Они должны
распознавать фундаментальную общность объектов — распознавать,
когда один документ является по сути таким же, как другой.
Аналитик объектов:
Полное картирование объектов оказалось легче, чем представлялось. Так
обычно и случается, если в решении задачи участвуют достаточно квалифициро¬
ванные руководители — не специалисты в области ЭОД. У нас было занято толь¬
ко три руководителя, но они досконально знали организацию. Двое из них
были бухгалтерами, что имело огромное значение. В сторону быстро отметалось
много мусора, в котором администратор-непрофессионал мог бы увязнуть.
Желательно дать волю проявлениям деловой интуиции руководите¬
лей не из области ЭОД. Анализ объектов предоставляет им возмож¬
ность взглянуть на работу своей организации по-новому и подумать над
тем, как улучшить ее. Деловая интуиция таких ^руководителей часто
способствует проведению более глубокого анализа объектов, чем это
сделали бы только специалисты.
101

Аналитик объектов — специалист в области ЭОД:
Руководители отделов пользователей интуитивно понимали, что служащий
также может быть поставщиком или держателем собственного капитала. Я вос¬
ставал против этого в проекте, считая, что это не должно иметь место. Чепуха!
Именно так работает эта организация.
Интуиция руководителей отделов конечных пользователей в сочетании с
дисциплиной в применении метода анализа дают хорошие результаты.
АНАЛИТИК-ПОЛЬЗОВАТЕЛЬ
Участник анализа, не специалист в области ЭОД, фактически ста¬
новится, по крайней мере на какое-то время, аналитиком нового типа.
В некоторых корпорациях его называют аналитиком-пользователем.
Такому аналитику не нужно знать технологию вычислительного дела.
Его учат идентифицировать и картировать объекты данных на своем
предприятии. Иногда его обучают нормализовывать данные. Его выби¬
рают благодаря тому, что он прекрасно знает работу предприятия. Ча¬
сто он обладает большим деловым опытом или опытом работы в каче¬
стве бухгалтера.
Аналитика-пользователя должны беспокоить вопросы улучшения
работы предприятия, упрощения бумажной отчетности и связанных с
этим прикладных программ. Что общего между разными подразделения¬
ми или разными заводами? Какая информация нужна для управления
предприятием? Как можно им управлять лучше? Какие проблемы стоят
в настоящее время? Иногда при наилучшем проведении анализа объек¬
тов весь проект приводился в действие пользователем, а не специали¬
стами в области ЭОД, причем служба ЭОД действовала как сильный
катализатор. Пользователи привносят логическое понимание деловой
активности.
Пользователей можно обучить на курсах за несколько дней. На
курсах не следует употреблять технический жаргон, рекомендуется под¬
черкивать, зачем нужен анализ объектов и как он послужит на благо
предприятия. Если пользователей обучают нормализации, то в процес¬
се обучения следует подчеркнуть, почему это требуется. В некоторых
случаях недостаточное внимание, уделенное разъяснению этого почему,
оставило пользователей в недоумении и не вызвало у них энтузиазма по
отношению к анализу. Обычно бывает оправданным возвращение поль¬
зователей к дальнейшему обучению после того, как они приобретут не¬
дельный или двухнедельный опыт работы с этим методом.
Заведующий планированием в корпорации:
Вначале саму идею определенно приходилось «продавать» пользователям
н в большой степени это удавалось сделать как за счет участия пользовате¬
лей, так и за счет демонстрации привлечения к работе высшего руководства.
Вскоре, благодаря частым встречам, посвященным функциональному анализу,
пользователи познакомились с функциональными областями, находящимися вне
их контроля. Стала намечаться некоторая форма взаимопонимания, которая спо¬
собствовала более глубокому пониманию всей работы корпорации со стороны
тех людей, которые были этим заняты.
102

СХЕМЫ-«ПУГДЛЛ»
Такие карты объектов, как на рис. 7.2, можно рисовать от руки,
когда объектов 20 или 30. Обычно их число растет, и построение схемы
приходится автоматизировать.
Некоторые проектировщики создают вручную слишком большие
карты, которые нельзя быстро перерисовать, а попытки модифицировать
их приводят к все увеличивающемуся хаосу. Претерпевшая много видо¬
изменений карта, наконец, перерисовывается вручную и ее считают об¬
разцом искусства— триумфальным достижением, но посмейте только
вновь ее изменить!
Автора приводили в ужас некоторые такие карты, хранящиеся у
администраторов данных. Нет никакого сомнения в том, что эти карты
препятствуют прогрессу и усовершенствованию структуры данных. Ад¬
министраторы данных ни за что не позволяют конечным пользователям
вносить в них поправки. Я предлагаю называть такие карты «пугалами»
(карты в виде жестянки с червями).
Многие создатели таких карт гордятся своими творениями, выпол¬
ненными в стиле рококо, и вешают их на стену.
СТРУКТУРНЫЕ КАРТЫ ОБЪЕКТОВ
На рис. 7.4 показана карта объектов, состоящая из 16 элементов.
Ее структура типа «спагетти» затрудняет работу с ней. На реальных
картах нередко бывает до нескольких сотен элементов. Карты быстро
становятся слишком большими, чтобы их можно было рисовать и ви¬
доизменять вручную. Схе¬
му объектов следует ри¬
совать более четким,
структурным образом. На¬
до, чтобы ее можно было
рисовать и видоизменять
с помощью ЭВМ. Для
этого выполняется следу¬
ющая процедура.
Сначала исключаются
любые избыточные ассо¬
циации (по крайней мере
Рис. 7.4. Карты объектов следует рисовать более
структурным образом, чем эта, чтобы после вне¬
сения изменений ЭВМ могла их перерисовать. На
приведенной карте только 16 объектов, а в дей¬
ствительности их нередко несколько сотен, и они
подвержены частым изменениям
в целях перерисовки кар¬
ты; их можно восстано¬
вить на перерисованной
карте).
Определенные объек-
ты на карте являются
корневыми. Корневой объект — это такой объект, от которого не от¬
ходит ни одной одноглавой стрелки. Общепринято рисовать корневую
запись, сегмент или объект наверху схемы базы данных. Мы будем
называть корневой объект объектом глубиной 1. Тогда объект глуби¬
ной 2 можно определить как объект, от которого отходит одноглавая
стрелка к объекту глубиной 1.
Объект глубиной 3 определяется как объект, одноглавая стрелка от
которого указывает на объект глубиной 2, но не на объект глубиной 1.
Объект глубиной К (А>1) можно определить как объект, одногла¬
вая стрелка от которого указывает на объект глубиной (У — 1), но ни
одна одноглавая стрелка от которого не идет к объекту меньшей глу¬
бины.
103

Рис. 7.5 показывает номера глубин объектов, показанных на
рис. 7.4.
Затем объекты глубиной 1 выносятся влево на схеме. Объекты глу¬
биной 2 смещаются на одну единицу расстояния. Объекты глубиной ^
смещаются на расстояние (^ — 1) единиц. Объект глубиной N (^>l)
строится под объектом
глубиной (А—1), на ко¬
торый он указывает. Объ¬
екты, размещенные под
одним объектом глубиной
1, образуют группу.
Стрелки, которые охваты¬
вают эти группы, следует
чертить слева на схеме
подальше от групп, как
показано на рис. 7.6, ко-
Рис. 7.5.
каждого
Цифры показывают глубину
узла на рис. 7.4
торый является
мененным рис. 7.4.
Видоизменение
видоиз-
такой
схемы, как на рис. 7.4, на¬
чинается с идентифика¬
ции объектов глубиной 1
(от них не отходят одноглавые стрелки). Затем можно отметить объек¬
ты глубиной 2, затем — объекты глубиной 3 и т. д. до тех пор, пока всем
объектам не будет присвоен номер глубины. Под каждым корневым объ-
ектом рисуются группы, а потом добавляются связи, охватывающие их.
Иногда у некорневого объекта есть выбор «родителя». Так, на
рис. 7.5 объект Л является объектом глубиной 2. Его можно поместить
под тремя объектами глубиной 1: В, 6 или L. Аналогичным образом Н
есть объект глубиной 3, который можно поместить внизу под любым из
двух объектов глубиной 2 — Y или К. Что лучше выбрать? Лучше всего
выбрать самую сильную ассоциацию или наиболее часто используемую
связь. Допустим, что ассоциация А-<-<—► В сильнее, чем А-»-*	► G
или А ■< +—^L. Тогда А рисуют под В. Аналогично, если J ^—^Н
сильнее или чаще используется, чем К*	►►//, то Н рисуют под / как
на рис. 7.6.
То же относится к циклу
где самую слабую связь следует временно разорвать в целях построения
схемы. На рис. 7.6 подразумевается, что наиболее слабым звеном явля¬
ется С 	► N.
Если сила связей неизвестна или они одинаковы, делается произ¬
вольный выбор, чтобы можно было нарисовать схему, которую затем
можно легко перерисовывать автоматически.
104

ОБЪЕДИНЕНИЕ ОБЪЕКТОВ В СУПЕРГРУППЫ
Подобно карте объектов систему баз данных, которую она пред¬
ставляет, следует разбивать на части для того, чтобы их легко можно
было реализовать. Такими частями являются предметные базы данных
или классы данных, о них мы говорили ранее. Будем пользоваться для
их обозначения термином супергруппа объектов.
Назовем иерархические группировки на рис. 7.6 группами объектов.
На рисунке показано четыре группы объектов. Группировка более высо-
ного уровня, супергруппа
групп объектов. Супер¬
группа — это такой на¬
бор объектов, который ре¬
ализуется в одной пред¬
данных. Она
предметом
моделирова-
, что пол¬
метной базе ,
становится
детального
ния данных,
робно описано в работе
[1,гл. 7].
Объекты можно объе¬
динять в супергруппы на
основании частоты ис¬
пользования ассоциатив¬
ных связей между объек¬
тами. Связи внутри су¬
пергруппы должны ис¬
пользоваться часто, а ме¬
жду отдельными супер¬
группами — редко. Для
этого связи между объек¬
тами при выполнении ана¬
лиза объектов помечают.
Их можно помечать в со¬
ответствии с пятью кате¬
гориями, перечисленными
в вставке 7.2. В ней пред¬
ставлено также колеба¬
ние от очень сильных ас¬
социаций или весьма ча¬
сто используемых связей
до очень слабых ассоциа-
объектов, может содержать одну или более
Рис. 7.6. Рисунок 7.4, перерисованный структур¬
ным образом, показывает четыре группы объек¬
тов
ций или крайне редко используемых связей.
Связи категории 1 доказывают, что охватываемые ими объекты оп¬
ределенно должны находиться в разных супергруппах.
Связи категории 5 указывают, что охватываемые'ими объекты дол¬
жны определенно находиться в одной и той же супергруппе.
105

Вставка 7.2. Пять категорий связей на картах объектов
I.	Очень слабая ассоциация; должны находиться в отдельных супергруппах.
2.	Довольно слабая ассоциация или редко используемая; возможное на¬
хождение в разных супергруппах.
3.	Средняя; по поводу ее нет определенного мнения.
4.	Довольно сильная ассоциация или часто используемая; возможное на¬
хождение в одной и той же супергруппе.
5.	Очень сильная ассоциация; должны находиться в одной и той же су¬
пергруппе.
Такая простая градация может послужить основой для разбиения
громоздкой карты на поддающиеся контролю карты или для объедине¬
ния объектов в супергруппы. Объединение объектов в супергруппы воз¬
можно выполнить с помощью вычислительного алгоритма.
Рис. 7.7 повторяет рис. 7.4, но теперь связи размечены по категори¬
ям. Рис. 7.8 повторяет рис. 7.6, разделенный на супергруппы объектов на
основании категорий ассоциаций.
Связи категории!, обозначенные пунктиром, указывают на то, что
объекты не должны находиться в одной и той же предметной базе дан¬
ных. Одна из них, идущая
Рис. 7.7. Перерисованный рис. 7.4, показывающий
связи с отметкой категории их ассоциации. Пунктир¬
ные линии от /1 к L. от М к G и от С к F имеют ка¬
тегорию I, обозначающую, что они должны охваты¬
вать различные супергруппы объектов
от С к F, находится в се¬
редине группы объектов
на рис. 7.6. Это заставля¬
ет разделить группу на
две. На рис. 7.8 группы
объединяются в три от¬
дельные супергруппы.
Категории связей по¬
зволяют решать, к какой
группе принадлежит объ¬
ект, когда есть возмож¬
ность выбора. Например,
на рис. 7.8 объект А вы¬
черчен под В, а не под G
или L. Так же определя¬
ем, что слабым звеном в
цикле С. D и -V будет
С —- N.
Внутри группы элементы с одинаковой глубиной рисуют выше, т. е.
ближе к «родителю», если их связь с ним сильнее. Так, А на рис. 7.8 на¬
ходится над J.
Можно было бы составить более подробную схему, точнее показы¬
вающую объем использования связей, что требуется при выполнении
детального проекта базы данных, но на этой стадии анализа такая клас¬
сификация вполне достаточна, чтобы разбить карту объектов на супер¬
группы.
106

Рис. 7.8. Рисунок 7.6, разделенный на супергруппы
объектов на основании категорий связей, показан¬
ных на рис. 7.7. На этой схеме категории отмечены
Разбиение карты объ¬
ектов на предметные ба¬
зы данных, вероятно, не
следует выполнять цели¬
ком на .основе алгорит¬
ма. Любая предметная
база данных должна быть
такого размера и содер¬
жания, чтобы админи¬
стратор данных мог осу¬
ществить ее детальное
проектирование за при¬
емлемый отрезок време¬
ни. Детальное проекти¬
рование должно учиты¬
вать, что некоторые дан¬
ные находятся в сущест¬
вующих файлах или ба¬
зах данных II класса, ко¬
торые нелегко будет пре¬
образовать. Приведенные
категории связей можно
использовать для выра¬
жения интуитивного же¬
лания группировать объ¬
екты в реализуемые базы
данных.
Применение связей ка¬
тегории I вынуждает ал¬
горитм ЭВМ разбивать
определенные объекты на
разные супергруппы, а связей категории 5 — объединять определенные
объекты в одну супергруппу. Иногда эти действия служат причиной
разбиения группы. Супергруппы, охватываемые связью категории 2, по
возможности лучше рисовать смежными, как на рис. 7.8.
ПРИМЕР
На рис. 7.9 показана карта объектов производственной корпорации.
Она довольно мала с точки зрения обработки данных корпорации и
содержит 95 объектов. В крупной комплексной производственной корпо¬
рации их может быть в 10 раз больше.
Структурная схема помогает увидеть, какие объекты связаны друг
с другом. Для упрощения чертежа иерархические связи внутри групп
объектов не показаны. Эта карта достаточна мала и ее можно разделить
на супергруппы вручную. Но так как весьма вероятно, что это будет про¬
делываться неоднократно, хорошо бы, чтобы такую карту перерисовы¬
вала машина.
На рис. 7.10 показано разбиение объектов рис. 7.9 на супергруппы.
Эти супергруппы могут затем послужить основой *для составления ма¬
трицы системного планирования, подобной представленным на рис. 4.3
и рис. 5.6.
107

| Заказчик
О тдел заказчика
Закупки заказчика
Поощрительная субсидия
Заказ заказчика
-►>1 Прохождение заказа |
Счет-фактура заказчика \
[прохождение счет-фактуры заказчика ]
[Упаковочный длани^
[-•^^Злмш	с^ет-рок гули заказчика
-»| коммерческая реклама по те
[ Географическая территория сОыта\

| коммерческий директор ]
			^ представитель отдела сбыта"]

[Плановое задание по реализации пробега
| Характеристика продукта
Оформление продукта
Экспортная категория j
Прогнозирование пооизводство
\ Склад
] Поставщик
Экономия материала
Получение материала
Улучшение оформления
Уласе продукта

котировка
Лицензионный плате* за продукт
Экспортные цены
Продукт
Список готовой продукции
Описание продукта

Анализ готового продукта
Местоположение /продукта/ на вкладе
Местоположение (материала) на складе
J Сырье
■ - <»| Продукт/материал
Слисок сырья
Заменитель материала
Анализ использования материи ла-сырь я
материал} поставщик
Заказ поставщика
Элемент прохождения заказа поставщика
но5ый_ элемент. прохождения списка, заказов
Извещение об отгрузке	|

		 Элемент прохождения извещения об отгрузке
[Характеристика поставщика ]
Рис. 7.9. Карта объектов производственной корпора
Карта построена с помощью автоматизированного
рое обозначает связи одноглавой и двуглавой
108

| "Оформлений Ттпййо |
	—| Процесс ста^а
^ Т^зкдстбённ^ "план. \
:=^Е^ёД^ёрацйя^^ |
		"^Другой Зарйойт. 'мёрацшТгр^^
	*>|^gw партий |
| Машина лрёссо&ш пластмассы
|Дюцюа|» работы лрёсуобоййм 'машины^
::====^ММеюимкомаря0_т^
^^^~~~~~ТОт^^^смей^Ййойберсйй^^^
Отчет, смен^ (печать)
Ттёёт смену ''тсс^йа^
Лицу л» "мастмог ^й и стержень
'■^\Стцйфй^^ия мдстмйсёоЗого йл^лйй
—{ Таблицу ЪёёёВ 1
^^мйтльм^ешмхг^^
|fw^»w^« I
[частнмГсш^^^
~. ^[лёрйо^частй^^	|
[Запись л^Зо^й	|
Ц НОссобая бёф^ййа]
■--~^2^[дёгал^
»| Оплата йалийнымй \
- ^Деталь оллать/ ~йалйчйымй
^ кредитор |
"оллать?	~
^ЬёолоЗотГЯо^^
Анализ йрёЗитрроЗ	~
Дебитор |

Тип, "пакулми.	~
МголоЗак Зонумейга. ЗеЗитом
'Анализ ^Зитрра
	> Суперфонд служащего	.
г—*1 Лоофёмй	|
\_±=1^£одробност^^

Гйзмёнёнй^3платы_2_ I

	^CHudMumHiodi^^	'
ДётальЙйматьГлеё^^
	СЙйЗёа сл&ащемй I
г-——'*'{банюЗм^^
1	^ЗтайЗартна/ГУй^^
Щ
-—^Зпйсаниё^сёйЗоц^йш^й^
цин с валовым годовым доходом 40 млн. долларов,
средства проектирования Data Designer [3], кото-
стрелками, а не черточками и «вороньими следами»
109

| ’Заказчик. |		 заказчик
	О^Д Д7Щ|/Ж |

Jwyw заказчика ~
Поощрительная субсидия
Закам заказчик	.
		Й^^прохождёнйё^закам. |
——	>|?»/г-догу^ 'заказчика. |

| Прохождёнйё Тчётайрактурй. заказчика |
[УЛйЙодОЧНЫйЩ^	■

._±~~^~^Л1юхождёнйе^/лойобоч^^
'•^коммёрчёсная^рёклама^пдтв^	сбои
—>| Тазетнай ~рёнлома. |
\гёоёраайё^
| ’коммерческий директор
		'	^{Представитель ’ртдёмГсбытд. |
\плайовоё задание реализаций 'п^дуктц |
[характерйстйка. продукта. |	продукт
~у==Е=ЩОформ^^
Улучй/ёнйё арормлёййя
класс р^дцкта.

I датировка.
[Ййцёнзис^^
{Экспортная ’категория
\зксподтныё_	[
| Ррогнозйрованйё ’лррйзводсгва. |
Jx| Проект	|

—Список Тотовой лрадуйцйй
иблйсанйё^лродцн^
: ~ '~7~~S| Анализ готового"лродййта
| ’Склад.	]		 склад
^===^~Ймёстололожёмйёд^
	 	 —► местоположение [материала], на. складе.
f| FbjpbC	|

■——••[лродйкту^

	^^^Заменйтёл^^
		~£ёлйёок ’сырья I
Заменителе материала.

Анализ использования материола^сырья
Экономия, материала.
		•^{Полрчёнйё ’материала.
■ Ч ^осгад^йй 	 пос тдвщик
	» Матёрйал/лостадщйк
Заказ, поставщика.

Элемент, прохождения, заказа поставщика
	Новый, элемент^ прохождения, списка заказов
{извещение об. ’отгрузке |
	^Зпёмёнт^пддхржденйя. ’извещения ’обдтгрдзн^
[хдройгёёйстйксГ^
[Оформлёнйё^^ 		 производство
СТОНОН
		*^П^^сд ’станка.
Рис. 7.10. Карта объектов рис. 7.9 разделена на супергруппы,
ренными
110

.	> и g vj a
•lowjoed ‘xhhhbv иивсвд HwnHiawvadu boibaohbio awdoio»
^аггйгоййй/ййй'^йп^
^ёзгаЯмй/Яй^^

\1>гзГпр>*лйэорогМд^^
| дгдЯн&Лйй драпай ТяТоййб ^о^У
oea)vD>^o jMg jsnHp*(idQfi7t^
/и оиьО9Пнанаы£и
Ии1г.иЖМЭ
л ■	। ■» ।
ЙйЯпрЙЯ)^^
ёмшйоай р-
рга^р^йр 'дйоФРдйЙЗ ^
	qodoingaff сгшон^
"оййТтдад^о^ш
~	лйрЯйой ил]
(fotngsir
ш HUHSdJiiftijyna
[оЙШЛДМЬПм^^
^^Р’
{^^JwjpHMWoiFJfffi
[пЫШо^
n*£Qga?u wwty|
Тйлдээоаз ошйавл дол^^
[ЙёпёЗйёйёгюоЗЗрм^^
^Jw?wi7MJ~m9gOWOi№
VJjwwiwidii)^^
~~(vnodagHwJ7ifi^^
~2fijo*7aoiH/~JiH~0tiido>/-CD^^
ш/йпон 'поыьо^5Яй_ /цу^ 9пй55пиэо0

WWH13WU	[jojjiwij^^
(“л^^

^tfTjjfigodirjrrTtoadSijcrji^^

ПОМЕЧЕННЫЕ АССОЦИАЦИИ
Некоторые разработчики карт объектов помечают связи на карте,
чтобы показать их значение. Это проиллюстрировано картой на рис. 7.11,
составленной для одной телефонной компании.
Рис. 7.11. Карта объектов с помеченными ассоциациями
Помеченные связи делают схему яснее. Иногда метки необходимы,
потому что две или более связей соединяют одни и те же блоки или по¬
тому что значение ассоциации неопределенное. Однако обычно значе¬
ние связей ясно само по себе и многие карты объектов хорошо выпол¬
нили свое назначение без помеченных связей. Так что метить связи не¬
обязательно.
112

Сейчас разрабатываются новые формы представлений моделей дан¬
ных, где значение связи кодируется с тем, чтобы оно было понятно ЭВМ.
Это можно использовать в усовершенствованных языках, применяемых
в базах данных.
ПРЕДСТАВЛЕНИЕ КАРТЫ С ПОМОЩЬЮ ЭВМ
Карты объектов можно рисовать вручную для десятков объектов.
Когда объектов сотни, карту трудно нарисовать, а тем более вести и
модифицировать без помощи графических устройств ЭВМ. Даже если
она выполнена с помощью таких графических устройств, от большой
карты мало проку, разве что только она послужит администратору дан¬
ных, который повесит ее на стене, для того, чтобы произвести впечат¬
ление.
Графические устройства ЭВМ крайне полезны для выделения карт
подмножеств, которые пользователи или аналитики могут применить
для создания логических карт доступа и для проектирования процедур
баз данных [5] и которые проектировщики применяют для изучения ча¬
стоты и объема использования приложениями транзакций.
Затем полная карта объектов должна храниться в форме, доступ¬
ной для ЭВМ, чтобы ее можно было удобно обновлять и манипулиро¬
вать ею. На основании этой карты графическими устройствами долж¬
ны создаваться небольшие карты подмножеств объектов, когда у адми¬
нистратора данных, конечных пользователей или системных аналитиков
' возникнет необходимость изучать их, обсуждать и перерисовывать по
ним карты доступа.
Карта объектов должна «давать пищу» процессу более детального
. моделирования данных (см. рис. 7.3). Если мы хотим иметь хорошие вы¬
числительные средства для проектирования и управления средой баз
данных, нужно хранить гораздо больше данных о данных. Данные о
данных называются метаданными. Необходимо помещать все эти мета¬
данные в базу данных— базу данных о базе данных.

ГЛАВА 8
АНАЛИЗ ОБЪЕКТОВ-ДЕЙСТВИЙ
ВВЕДЕНИЕ
В гл. 7 планирование данных рассматривалось с использованием
объектов, а не действий. В настоящей главе мы обсуждаем отображение
объектов на действия. Это позволяет получить более подробную и точ¬
ную карту, показывающую, где предприятие использует данные, а так¬
же более формально объединять объекты в предметные базы данных.
ДЕЙСТВИЯ И ОБЪЕКТЫ
На рис. 2.4 приведена модель предприятия, включающая действия.
Как мы уже говорили, типичное предприятие может иметь от 10 до
30 функциональных областей и от 100 до 300 процессов. При грубом
планировании эти функциональные области и процессы отображаются
на предметные базы данных. При более детальном планировании функ¬
ции разлагают на действия, которые отображаются на объекты.
БАЗА ДАННЫХ ОБЪЕКТОВ-ДЕЙСТВИЙ
Конечные пользователи, участвующие в планировании (см. рис. 3.1),
должны идентифицировать действия и объекты. Таким образом, они де¬
лают больше того, что описано в гл. 7, но, как показывает опыт, с не
намного большими затратами времени. Это вполне осуществимо, когда
участие людей организовано (см. рис. 3.1).
Карта объектов и действий не зависит от структуры отделов и под¬
разделений. Структуру можно изменить, не изменяя карты объектов-дей¬
ствий. Целью картирования объектов-действий является создание устой¬
чивого представления предприятия, которое остается действительным
при любых реорганизациях, касающихся людей.
Для более детального планирования требуются автоматизированные
средства. Функциональное разложение и карта объектов должны хра¬
ниться в небольшой базе данных, тогда данные можно будет изучать
многими способами, например с помощью печати инвертированной таб¬
лицы, показывающей функции и действия, ассоциируемые с каждым
объектом.
База данных может показывать также, какими отделами выполня¬
ется каждое действие и географическое размещение каждого действия.
Тогда с ее помощью можно получить ответы на такие вопросы: «Какие
отделы пользуются объектами X?» или «В каких местах .выполняется
конкретное действие»?
Как и прежде, объекты следует группировать в супергруппы или
предметные базы данных. Когда это выполнено, можно автоматически
создавать такие схемы, как показано на рис. 4.3 и 5.6. Возможно полу¬
чение более подробных листингов с ЭВМ, показывающих, какие объек¬
ты где используются, чем те, которые приводятся в гл. 4 и 5.
1 14

ФУНКЦИОНАЛЬНОЕ РАЗЛОЖЕНИЕ
Функция — это задача, которая должна выполняться на предприя¬
тии. Каждую функцию можно разбивать на функции более низкого
уровня до тех пор, пока не будет получено элементарное действие. Эле¬
ментарное действие — это действие, которое становится процедурой на
ЭВМ (или выполняется вручную).
Приобретение
Информаций Й1^ [Отменить
покупку
заказ
Создать Информации
треоооание поставщика
Выбрать
поставщика
исключи - информацию
тельных для счетов
хслучаеоу уредитороду
(проследи^ (Обработ^\ fiСоздав}
за дос-,
годной
Рис. 8.1. Функциональное разбиение
На самом высшем уровне предприятие рассматривается как одна
функция. Его можно разбить на подразделения, а подразделение — на
выполняемые им задачи (см. рис. 2.4). Назовем каждый блок на рис. 2.4
функцией. Блоки самого нижнего уровня на «дереве» (которые начина¬
ются с глагола) являются действиями.
Рис. 8.1 показывает функциональное разложение. Каждая функция
разбивается на функции-компоненты до тех пор, пока не получится
действие, которое может стать дискретной процедурой. Некоторые дей¬
ствия становятся предопределенными вычислительными процедурами
(такие, как СОЗДАТЬ ЗАКАЗЫ НА ПОКУПКУ); другие являются не-
предопределенными действиями пользователя, вводимыми с терминала
(такие, как ПРОАНАЛИЗИРОВАТЬ ДЕЙСТВИЯ ПОСТАВЩИКА).
Эти функции, включая функции самого низкого уровня, являются логи¬
ческими. Они не указывают, как будет физически выполняться задача.
Процедура — физическая, она определяет, как будет выполняться зада¬
ча. Схемы функционального разложения, подобные рис. 8.1, применяют¬
ся для общего планирования. Для проектирования определенных дейст¬
вий используются более подробные схемы (такие., как карты обращения
к базе данных и схемы действий [1]).
115

О ГРАФИЧЕСКОМ ПРЕДСТАВЛЕНИИ ИЕРАРХИЙ
В большинстве книг иерархические (древовидные) структуры рису¬
ют вертикально, как на рис. 8.2, с корнем наверху. На практике часто
лучше рисовать их горизонтально, причем корень помещать слева, как
на рис. 8.2, потому что в реальных ситуациях (в отличие от рисунков в
учебниках) на одном иерархическом уровне могут располагаться много
элементов — слишком много, чтобы их можно было уместить на одной
странице. Рисовать такой уровень по горизонтали становится неудобно,
а по вертикали, как на рис. 8.2, не составляет проблемы.
Для обновления и показа нашей функциональной информации, а
также для модели данных и их перекрестных ссылок нам требуются
ЭВМ. Рис. 8.2 легко обновлять и перерисовывать с помощью ЭВМ.
Материалы
Приобретение
Создать требование	*
Информация поставщика
Записать данные о характеристике поставщика	*
Проанализировать характеристику поставщика	*
Выбрать поставщика	*
Создать заказ на покупку	*
Отменить заказ	*
Проследить за доставкой	♦
Обработка исключительных случаев
Создать специальный заказ	♦
Непоставка поставщика
Закупить заказ	*
Создать новый заказ	♦
Создать информацию для счетов кредиторов	*
Получение
Рис. 8.2. Та же схема, что приведена на рис. 8.1, но каждый уровень рас¬
полагается по вертикали так, чтобы уровни, состоящие из множества эле¬
ментов, умещались на странице. С такой схемой можно легко обращаться
и обновлять ее с помощью машинных распечаток. Звездочками отмечают¬
ся основные действия (самые нижние вершины «дерева»)
ЭЛЕМЕНТАРНЫЕ ДЕЙСТВИЯ
Как аналитик узнает, что он уже разбил функции на действия?
Чтобы описать назначение элементарного действия, обычно достаточно
одного предложения. Если на это уходит более одного предложения,
действие, вероятно, нужно проанализировать еще раз.
Когда вы спрашиваете сотрудника на предприятии, что он делает,
в его ответе обычно будет названо элементарное действие. Например,
«Я готовлю заказ на приобретение» или «Я расплачиваюсь с поставщи¬
ком». Подобное предложение требуется для описания каждого элемен¬
тарного действия. Обычно не говорят: «планирование материала» — это
слишком высокий уровень; или «проставление даты на заказ на приоб¬
ретение» — это слишком низкий уровень.
Элементарное действие автоматизируется сразу как единая про¬
цедура. Если функция включает более одной процедуры или автомати¬
зируется в несколько этапов, значит проделан недостаточный анализ.
Элементарное действие соответствует процедуре, которая, будучи ав¬
томатизированной, станет пользоваться базой данных. Когда она будет
реализована, ее можно будет вычертить при помощи схемы действий
базы данных [1 ].
116

Когда описанные выше характеристики используются для иденти¬
фикации элементарного действия, не стоит долго рассуждать о том, что
является элементарным действием или в каком месте анализа следует
остановиться. Чувство «естественного» важнее, чем механическое соблю¬
дение правил. Если дальнейшее разбиение функции обещает дать ин¬
тересные результаты, разбейте ее; если нет, не делайте этого.
Анализ никогда не следует считать завершенным на 100% и оконча¬
тельным. Всегда останутся какие-то необнаруженные действия или позд¬
нее будут добавлены новые. Модель впоследствии можно усовершенст¬
вовать.
Когда функцию разбивают на функции более низкого уровня, сле¬
дует быть уверенным, что они являются достаточными и что каждая из
них необходима для достижения общей цели независимо от того, какая
реорганизация или автоматизация будет иметь место. Моделировщики
должны быть уверены в том, что их модель объектов-действий пережи¬
вает организационные изменения, а это произойдет, только если дейст¬
вия будут необходимыми и достаточными. Вероятно, обнаружится, что
некоторые выполняемые в данное время действия излишни. Часто слу¬
чается, что анализ объектов-действий приводит к реорганизации про¬
цедур или перестройке отделов или административных структур.
СВОЙСТВА КОГЕРЕНТНЫХ ДЕЙСТВИЙ
Проработав некоторое время над анализом действий, д-р Кен Уин¬
тер суммировал те качества, которые должны быть присущи хорошо
сформированным действиям [13].
1.	Когерентное действие приводит к четко определяемому результату. Его
назначение — выдать этот результат. Таким результатом может быть выпускае¬
мый на рынок продукт, часть продукта, идея, решение, торговая сделка, - ряд
альтернатив, чек для оплаты, перспектива и т. д. Определение назначения / ре¬
зультата действия должно укладываться в одно простое предложение. Плохо
сформированное действие совсем не дает определяемого результата или приво¬
дит к ряду не связанных между собой результатов.
2.	Когерентное действие имеет четкие границы. Всегда можно с уверен¬
ностью сказать, кто над ним работает, а кто — нет. Со временем можно будет
определять те моменты, когда начинается и когда заканчивается работа над
действием. Переходы между когерентными действиями хорошо заметны. Неко¬
герентные действия накладываются друг на друга или сливаются, и невозможно
определить, когда и где они происходят.
3.	Когерентное действие выполняется как одно целое. Оно осуществляется
одним человеком или четко определенной группой людей, которые работают все
вместе над получением результата. Ответственность руководителя за выполне¬
ние этого действия также четко определена и возлагается на одного человека
или на группу людей. Нечетко определенное действие может выполняться не¬
четко определенной группой людей, т. е. не будет ясно, кто его выполняет. Его
может осуществлять и хорошо определенная группа людей, в работе которых
есть нечто общее, но которые не работают как единая команда — они не сооб¬
щаются друг с другом и не кооперируют свои усилия с целью достижения ре¬
зультата этого действия, возможно, потому, что они рассеяны по всему пред¬
приятию таким образом, что никогда не встречаются друг с другом.
4.	Начавшись, когерентное действие выполняется автономно, оно протека¬
ет в основном вне зависимости от других действий. Если предполагаемому дей¬
ствию во время его выполнения требуется активное взаимодействие с другим
предполагаемым действием, посмотрите, не стоит ли объединить их в единое
действие. Это можно выразить иначе: взаимодействия внутри той группы, что
выполняет когерентное действие, бывает насыщенней, чем взаимодействие между
группами, работающими над разными действиями.
Для формирования модели действий эти пункты не являются абсо¬
лютными требованиями, они выведены эвристическим путем.
117

СХЕМАТИЗАЦИЯ ОБЪЕКТОВ-ДЕЙСТВИЙ
Каждое действие связано с различными объектами. Число исполь¬
зуемых типичным действием объектов достигает семи. Если действие
пользуется больше чем семью объектами, рекомендуется разбивать его
на карте предприятия на большее число действий. Предполагается, что
действие будет выполняться служащим эффективно. Психологи проде¬
монстрировали, что большинство людей испытывают затруднение, если
им приходится одновременно общаться с более чем семью элементами
или концепциями, так как восприимчивость их кратковременной памяти
близка к семи элементам [6]. Деятельность человека должна быть
связана не более чем с семью объектами, и лучше, если с меньшим
числом.
Руководители отделов конечных пользователей, участвующие в про¬
цессе планирования данных должны схематизировать функции и дейст¬
вия в своей области и отображать их на объекты, которыми они пользу¬
ются. Если не ясно, какие для функции требуются объекты, значит функ¬
циональное разложение проделано недостаточно глубоко.
Группа-ядро, представленная на рис. 3.1, строит общую схему объ¬
ектов, как это описывалось в предыдущей главе, а также соотносит ее
с моделью предприятия и его действиями.
Вполне вероятно, что ни карта объектов, ни функциональное раз¬
ложение не будут полными. С течением времени их следует обновлять
с помощью ЭВМ. Вначале требуется лишь наскоро составленный обзор
и могут использоваться грубые объекты. Детальное моделирование дан¬
ных и проектирование процедур займут гораздо больше времени. После
осуществления такой детализации можно обновлять схему функциональ¬
ного разложения, карту объектов и базу данных их соотнесения.
Для функционального разложения, схематизации объектов и моде¬
лирования данных требуются автоматизированные средства. Эти схемы
слишком велики и запутаны, чтобы их можно было вести вручную. Мы
были свидетелями выполнения большой, неряшливой и недостаточной
работы и нежелания изменять карты в тех случаях, когда применяются
ручные методы. Отсутствие автоматизации служило основной причиной
некомпетентного администрирования данными.
РЕОРГАНИЗАЦИЯ ПРЕДПРИЯТИЯ
Там, где в анализе действий принимает участие администрация,
часто поднимается вопрос, какими должны быть действия. Может ока¬
заться, что некоторые выполняемые действия являются излишними или
ненужными, другие действия разбросаны в неуправляемом порядке по
всему предприятию. На основании модели можно сделать выбор аль¬
тернативных действий.
Анализ объектов-действий приводит к пересмотру процедур. Он ча¬
сто ведет также к реорганизации подразделений, к созданию админи¬
стративного аналитического комитета. Естествен вопрос, задаваемый
группой проведения анализа: «Какой вы хотите видеть структуру пред¬
приятия?». Необходим непрекращающийся поиск путей использования
баз данных и терминалов для улучшения процедур и структур пред¬
приятия.
Для высшего руководства нередко бывает неожиданностью увидеть,
какими данными пользуются различные отделы или подразделения: не¬
редко вскрываются факты о корпорации, о которых оно не ведало. Ча¬
сто выявляется необходимость в организационных изменениях или пере¬
стройке корпорации, эти вопросы мы обсудим в гл. 9.
118

Консультант по вопросам анализа объектов:
У комитета, руководящего деятельностью ЭОД, открылись глаза на то,
где используются определенные виды данных. Высшее руководство не в состоя¬
нии близко соприкасаться с каждой областью, а картина использования данных
попросту никогда ранее не раскрывалась.
Руководитель проекта работает в основном автономно. Он несет ответст¬
венность за большую часть того, что осуществляется по программе, оцениваемой
во много миллионов долларов. Он определяет, что ему требуется для получения
конечного результата. Ему выделяется бюджет и его оставляют вести дело.
Анализ показывает, что многие проекты включают то же самое, что содер¬
жится в других, и никто не осознает это, так как отчеты идут разным руководи¬
телям в разных областях действий.
Аналитик объектов:
Предприятие имело всего восемь автономных подразделений, каждое из
которых неистово соперничало с другими, все они боролись не на жизнь, а на
смерть, чтобы стать первыми.
Анализ данных показал, что большинство подразделений представляли со¬
бой одно и то же. 60% операций в каждом подразделении были одинаковыми.
Но у них работали разные группы программистов, которые никогда не об¬
щались.
Стало очевидным, что предприятие нуждается в существенной перестрой¬
ке. Теперь это осуществилось. Вместо восьми подразделений осталось три.
АНАЛИЗ СХОДСТВА
Когда объекты ото¬
бражены на действия, воз¬
можен иной метод их
группировки в предмет¬
ные базы данных. Можно
вычислить такую матри¬
цу, как на рис. 8.3, кото¬
рая показывает сходство
каждого объекта с дру¬
гим.
Допустим, что мы име¬
ем два объекта — Е\ и
Е2. Если эти два объекта
никогда не используются
для одного и того же дей¬
ствия, их сходство будет
пулевым. Если два объек¬
та всегда используются
вместе для каждого дей¬
ствия, их сходство будет
равным I. Многие объек¬
ты используются вместе
только для некоторых
действий.
Рис. 8.3. Матрица, показывающая вычислен¬
ное сходство различных объектов. Ею можно
воспользоваться для группировки объектов в
предметные базы данных
ЭВМ может исследовать каждое действие и рассчитать:
1)	(Е|) —число действий, пользующихся объектом Е^,
2)	{Е\ Ео) — число действий, пользующихся обоими объектами.
Е^кЕ,.
119

С помощью этих величин можно определить коэффициент сходства
для этих двух объектов. Один из способов определения коэффициентов
сходства следующий:
р а(Е1( EJ
сходство к Е, =	1——.
0(^1)	’
Коэффициент сходства можно поместить в матрицу, аналогичную пока¬
занной на рис. 8.3.
Если два объекта обладают большим сходством, они должны нахо¬
диться в одной и той же предметной базе данных. Если их сходство рав¬
но нулю, то они определенно не должны находиться в одной и той же
базе данных. Где же находится разделяющая черта?
ЭВМ способна группировать объекты на основании их коэффици¬
ентов сходства. Если она помещает объекты с коэффициентом сходства,
равным 0, в одну и ту же группировку, значит будет всего одна группи¬
ровка. Если она помещает объекты с коэффициентом сходству, равным
1, в одну и ту же группировку, группировок может быть столько же,
сколько объектов. В ЭВМ можно предусмотреть, чтобы она устанавли¬
вала коэффициенты сходства таким образом, чтобы получить 20, 30
группировок или столько, сколько решит проектировщик. Эти группи¬
ровки затем служат как предметные базы данных.
Коэффициент сходства не учитывает объема употребления каждого
действия. Но можно рассчитывать его иначе, с учетом объема употреб¬
ления действия. Этот метод дал хорошие результаты на практике, поз¬
волив автоматически группировать объекты в предметные базы данных.
АЛГОРИТМ ГРУППИРОВКИ
Допустим, мы хотим сгруппировать объекты на рис. 8.3 в базы дан¬
ных. Пары объектов сортируются по величине сходства, и мы начинаем
с самых больших значений. Пары объектов с самым большим сходством
образуют ядра группировок, так:
Ei, Е4 (сходство=0,92),
Ен, Ев (сходство=0,90),	'
Еб, Е7 (сходство=0,88),
Е10, Е12 (сходство=0,87).
Постепенно мы добираемся до такой пары объектов, в которой один
из объектов уже находится в одной из группировок. Следующая пара
объектов, с которой мы встречаемся, такова:
Е2, Е8 (сходство=0,85).
Е8 уже распределен в ядро группировки Еи, Е8. Должны ли мы подсое¬
динить Е2 к этой группировке? Чтобы определить это, нам надо рассчи¬
тать взвешенное сходство Е2 с группой Еп, Е8:
(сходство £г к Еп) х а (^ц) + (сходство Е2 к Е8)Ха(£8)
а(Еи) + а(Е8)	’
Допустим, что объект Еп используется тремя действиями, а объект
Е8 — 48 действиями. Тогда сложное сходство Е2 с группой Ец, Е8 будет
следующим:
0,34X34-0,85X48 n со
Эта величина больше, чем оставшаяся на рис. 8.3 величина сходства,
так что формируется группировка Е2, Ец, Е8.
120

После этого, когда мы встретим новые объекты со сходством с £2,
£ц или Е8, мы будем вычислять их сложное сходство с группой Е2, £н,
£8. Таким образом, группировки объектов с большим сходством посте¬
пенно растут.
Следующим наибольшим сходством на рис. 8.3 будет сходство Е7 с
£4 (сходство=0,76). Однако оба эти объекта, Е7 и Е^, уже распределе¬
ны по группам. Следует ли эти группы объединить?
Чтобы определить это, мы рассчитываем сложное взвешенное сход¬
ство Е7 с существующей группировкой £|, £4 и с объединенной группи¬
ровкой £1, £4, £б. Допустим, что величины этих сходств будут 0,55 и
0,37 соответственно. Они меньше следующей по списку величины сход¬
ства £8 с £ю (сходство=0,74). Поэтому сначала берутся за него. Каж¬
дое решение о группировке выносится в соответствии с порядком вели¬
чин сходства.
Некоторые объекты в конце последовательности сходства могут об¬
ладать малым сходством по отношению к любым другим объектам. Их
можно реализовать в виде систем файлов или простых изолированных
баз данных. Проектировщику следует пересмотреть все оставшиеся
объекты с небольшим сходством, чтобы проверить, не принадлежат ли
они к какой-либо из уже существующих баз данных.
КОРРЕКТИРОВКА ВРУЧНУЮ
При разработке любого подобного алгоритма группировки объек¬
тов может потребоваться корректирующее вмешательство человека, по¬
скольку алгоритм может объединять объекты, которые должны быть
разделены по таким соображениям, как надежность, защита одного типа
данных, когда другой тип связан с каким-либо отказом, при проекти¬
ровании распределенных систем (этот вопрос рассматривается позднее),
по юридическим соображениям и т. д.
Иногда причиной определенной группировки становится желание
сохранить существующий файл или системы баз данных. Иногда группи¬
ровка корректируется для того, чтобы детальное моделирование пред¬
метной базы данных могла выполнять одна группа людей.
Пользователь может пропускать алгоритм несколько раз, устанав¬
ливая различные пороги сходства или задавая определенную разбивку
данных. Для каждой получаемой в результате предметной базы данных
можно рисовать карту объектов, такую, как на рис. 7.10, чтобы ее изу¬
чить позднее.
Группирование в результате анализа сходства послужит проверкой
группирования, получаемого в результате присваивания весов ассоциа¬
тивным связям, рассмотренным в гл. 7. Матрицу коэффициентов сходст¬
ва можно применять для проверки обоснованности образования супер¬
групп, показанных на рис. 7.8 и 7.10.
Сами коэффициенты сходства служат как весовые обозначения ас¬
социаций, заменяя субъективные категории, приведенные на рис. 7.7.
Ими можно воспользоваться для разбиения карты объектов на супер¬
группы, как на рис. 7.8.
Группа планирования и представители различных областей долж¬
ны проанализировать конечные результаты и откорректировать их, если
потребуется. Затем предметные базы данных, полученные в результате
группировки объектов, можно использовать для планирования систем,
как это описано в гл. 4.
121

ОБНОВЛЯЕМЫЙ ЦЕНТРАЛИЗОВАННЫЙ ПЛАН
Планирование сверху вниз не должно быть событием, которое про¬
исходит однажды и никогда не повторяется. А это — чаще всего судьба
анализа, проведенного методом BSP. На крупных предприятиях анализ
методом BSP иногда считают слишком болезненным мероприятием, что¬
бы его часто повторять.
Однако большинство предприятий претерпевает изменения. Поэто¬
му необходима такая методология планирования сверху вниз, которая
шла бы вровень с этими изменениями и которую можно было бы обнов¬
лять. Методологии, описанные в данной и предыдущей главах, могут
применяться в совокупности с анализом методом BSP и улучшать его.
Как отмечается в гл. 9, анализ объектов на предприятии обычно
вскрывает такие аномалии, которые требуют устранений. Их можно выя¬
вить также с помощью бесед по методу BSP.

РЕОРГАНИЗАЦИЯ ПРЕДПРИЯТИЯ
ВВЕДЕНИЕ
На многих предприятиях функциональный анализ проводится на ос¬
новании существующих процедур. Гораздо полезнее рассматривать про¬
цедуры организации с точки зрения того, какими они должны быть, а
не являются. Технология баз данных дает возможность существенно из¬
менить процедуры, а также ее источники информации.
Первые автомобили называли «безлошадными экипажами» и они
действительно по форме напоминали экипаж без лошади. Гораздо позд-
нсестали понимать, что машина может иметь другую форму. Аналогич¬
но первое радио назвали «беспроволочным телеграфом», не осознавая,
что радиовещание ничем не будет напоминать работу телеграфа. Сегод¬
ня мы говорим о «безбумажной конторе» и «безбумажном предприятии»,
но мы строим системы с видеоэкранами и базами данных, которые дуб¬
лируют существовавшую ранее организацию работы. Со временем воз¬
растет понимание, что базы данных и видеоэкраны делают возможными
различные и лучшие формы организации работы.
ФУНКЦИОНАЛЬНЫЙ АНАЛИЗ
Анализ объектов или объектов-действий часто приводит к пересмо¬
тру функций и методов на предприятии. Иногда такой подход называ¬
ют функциональным анализом.
Функциональный анализ призван изучать назначение и задачи пред¬
приятия. Задачи общего характера можно разбить на задачи, предна¬
значенные для каждого уровня и для каждого отдела предприятия.
И здесь правомочны три вопроса: Как можно измерять эти задачи? Ка¬
кие данные требуются для их измерения? Как нужно принимать решения
на каждом уровне, чтобы наилучшим образом разрешить указанные за¬
дачи?
Участие в этом толковых руководителей отделов пользователей, го¬
товых к творческому осмыслению требований к данным, часто приводит
к возникновению сомнений в отношении существующих процедур, что
выходит за пределы компетентности службы ЭОД.
Консультант по вопросам анализа объектов:
Функциональные руководители заявили, что они не могут найти время,
чтобы принять участие в анализе объектов, поэтому они предоставили в мое
распоряжение своих старших клерков. Весьма высокий по чину клерк, который
упивался титулом «поставщик», научился отображать данные и нормализо¬
вать их. . •
Однажды он попросил меня, чтобы я встретился с ним и с руководителем
по планированию, так как он хотел сообщить нам что-то важное. Он вошел
к руководителю по планированию и сказал: «Наше совещание OPAS несостоя¬
тельное!»
123

A OPAS — это святая святых в этой компании. Каждый понедельник ут¬
ром в главной конторе собирается «совет старейшин» — старшие функциональ¬
ные административные руководители, которые решают, что где на трех заводах
должно происходить, в каких пропорциях, с каким приоритетом и каким ре¬
зультатом.
Старшему клерку удалось понять, что продукция из цеха холодной обра¬
ботки идет в распиловочный цех, а затем — к следующему процессу, и так да¬
лее, а решения OPAS, принимаемые в начале этой цепочки, «закручивают» экс¬
портные заказы, находящиеся примерно на 13-м этапе ее.
Клерк «прижал» руководителя по планированию, а тот не был даже готов
его слушать. Однако клерк развернул аргументацию и поймал в эту сеть руко¬
водителя. Холодок вопросов «Почему?» дошел до совещания OPAS. Вопросы
касались предложений главной конторы, с одной стороны, и стимулов — с дру¬
гой, а также влияния экспортных заказов на планирование.
Все это случилось потому, что старший клерк увидел в своей реляционной
карте нечто странное. Когда он проследил, откуда это берется, то оказалось, что
ничего подобного там быть не должно.
Теперь этот старший клерк больше не досаждает функциональному адми¬
нистратору — его повысили в должности впервые за 20 лет. Он уже не «постав¬
щик», а старший планировщик производства^ что эффективно содействовало
устранению «угрозы» с его стороны.
Консультант по вопросам стратегического планирования:
Запланировано определенное число почтовых отправлений в год. За эти
почтовые отправления идет настоящая борьба. Приходит к руководству сотруд¬
ник книжного отдела с планом рекламы и говорит: «Если вы позволите нам это
осуществить, мы заработаем столько-то миллионов долларов для вас». Сотруд¬
ник музыкального отдела заявляет: «Нам надо воспользоваться этими почтовы¬
ми отправлениями и вот что мы сможем тогда сделать».
Это соперничество проверяется с помощью имеющихся файлов. В них содер¬
жатся сведения о 50 млн заказчиков. Сотрудники постоянно теребят эти файлы,
извлекая, скажем, информацию о 10 000 заказчиков для пробного отправления
им рекламы на книгу о животных, выходящую в следующем году, или на что-
нибудь еще.
До проведения анализа данных корпорации каждая отдельная область уп¬
равляла своими собственными действиями. Анализ, однако, показывает, что для
каждой области требуется один и тот же вид объекта. Ясно, что корпорации
следует подумать о реорганизации всего подхода к делу.
ИЗМЕНЕНИЕ ОРГАНИЗАЦИИ
Высшее руководство должно считать анализ объектов не просто
средством отображения существующей организации в структуру дан¬
ных. Анализ должен подвести руководство к вопросу о том, как надо
изменить организацию или как она может измениться под воздействием
внешних обстоятельств.
Надо заставить аналитиков-пользователей мыслить творчески. Им
легче идти по проторенной дорожке документирования сложившегося
бумажного потока, чем определять насущные потребности бизнеса. Се¬
годняшние документы не должны быть для них шорами. Аналитикам-
пользователям необходимо задуматься над тем, какие данные важны
для нас и что нам может потребоваться в будущем.
Размышления о будущем важны для того, чтобы сделать базы дан¬
ных как можно более жизнестойкими. Пользователям труднее настроить¬
ся в этом направлении. В анализе необходимо участие высшего руково¬
дящего звена, ему известны текущие проблемы и у него есть некоторые
идеи относительно тех действий, которые следует предпринять, чтобы
разрешить эти проблемы.
124

В тех случаях, когда анализ объектов следовал за анализом мето¬
дом BSP, матрица, представленная на рис. 6.9, служила основой для
определения требуемых улучшений в информационных системах. Какие
еще данные, помимо хранящихся сейчас, нужно хранить и в каком виде
они должны представляться руководству?
Почему административные работники не пользуются своей автома¬
тизированной системой кадров? Почему они переманивают людей друг
у друга, а не сверяются с системой? Почему мы всегда отстаем от гра¬
фика при выполнении больших специальных технологических заданий.
Возглавляющий анализ объектов:
Когда мы только принялись за анализ объектов, мы думали, что это метод
изучения существующих процедур. Шаг за шагом мы обнаружили, что он го¬
раздо шире.
Сначала мы выявили тот факт, что существующие процедуры устрашающе
дублируют друг друга. Каждый человек в службе рационализации управления
на предприятии изобретал свои собственные бумажки. В результате вместо од¬
ной автоматизированной формы, которой было бы достаточно, существовало
множество различных форм бумажной документации. К сожалению, в каждом
подразделении был свой собственный структурный аналитик, который воплощал
в жизнь в различных программах на Коболе методы, дублирующие друг друга.
Все вместе они вылились в кошмар.
Далее мы обнаружили нечто большее, чем просто дублируемые бумажные
работы. Процедуры и сам поток работы имели аномалии, иногда баснословно
дорогостоящие. За последние 20 лет число процедур выросло, как грибы за
ночь. В некоторых случаях у руководства возникало неопределенное ощущение
существования таких отклонений, но оно видело только деревья, а не лес.
Прошли месяцы, пока мы осмелились признать, что сама структура руко¬
водства была неправильной. Требовалась основательная реорганизация подраз¬
делений и отделов, чтобы обеспечить жесткий контроль и высокую администра¬
тивную продуктивность. Только функциональный анализ всей организации помог
прийти к такому пониманию.
Результаты анализа объектов часто бывают неожиданными для
высшего руководства, а также для комитета, руководящего службой
ЭОД.
Руководитель анализа:
Подразделение усовершенствования систем является, по существу, научно¬
исследовательским. Когда оно доводит дело до уровня исследования операций,
предполагается, что его передают далее другому подразделению для реализации.
Не так давно подразделение усовершенствования систем само реализовывало их.
Руководство не осознавало, что происходит, считая, что это другой проект.
Специалисты отдела усовершенствования систем налаживали производственные
линии, выполняли инженерные чертежи и все остальное, что необходимо для про¬
изводства. Вдруг руководство, глядя на матрицу данных, спросило: «Почему
сотрудникам отдела усовершенствования систем требуются данные инженерных
исследований? Должны ли они этим заниматься? Стоит задуматься!»
Руководителям высшего звена начали перераспределять ответственность,
говоря: «Нет. Вам не надо этого делать. Вы лучше передавайте это другому
отделу». '
УЧАСТИЕ В ПЛАНИРОВАНИИ ВЫСШЕГО РУКОВОДСТВА
Мы уже подчеркивали необходимость участия высшего руководства
в планировании данных сверху вниз. Если существует вероятность, что
планирование может повлечь за собой структурные- изменения, новые
процедуры или реорганизацию предприятия, интерес руководителей к
нему, очевидно, повысится.
125

В большинстве случаев администрация проявляет слабое желание
участвовать в автоматизации существующих процедур. Однако, если
возникает угроза в виде организационных изменений или обещания но¬
вых источников информации, она обычно хочет знать, как идут дела, и
хочет иметь возможность влиять на них. К чему, как правило, высшее
руководство проявляет активный интерес, так это к возможности прини¬
мать решения относительно того, как должно работать предприятие.
В таком свете можно представить анализ объектов.
Консультант по вопросам анализа объектов:
Сегодня директор-распорядитель говорил о том, что будет по-иному соби¬
рать отчетные данные о работе цеха. Это его конек в последнее время. Когда
мы привлекли его к участию в планировании структуры данных, он мог только
думать о том, какое влияние это окажет на проектирование транзакций. Теперь
у него есть средства для выражения необходимых, по его мнению, изменений.
Он чувствует удовлетворение, делая это.
Поддержка руководством такого функционального анализа необхо¬
дима в той же степени, что и для анализа методом BSP. Но в отличие
от BSP целью здесь является создание карты объектов для всего пред¬
приятия или его части. Идентифицированными объектами являются те,
что позволяют добиться наилучшего управления и оценки поставленных
задач.
Консультант по вопросам анализа объектов:
За несколько лет была проанализирована деятельность ряда различных
компаний. Отделы ЭОД выполняют адскую работу. В основном в каждой из
этих компаний требования бывают общего типа, но каждая компания хотела
иметь свои собственные системы. У каждой была своя собственная система за¬
казов, различные типы порядковых номеров заказов, различные складские но¬
мера... Метод анализа объектов — это возможность для руководителей отделов
пользователей увидеть, какие проблемы они создают себе тем, что не рационали¬
зируют системы.
Анализ объектов будет более плодотворным, если с самого начала
понимают вероятность того, что он вызовет изменение процедур в корпо¬
рации. Если это осознают, высшее руководство проявит больший инте¬
рес к анализу. Иначе будут выделяться люди для его проведения, и
иными будут процедуры отчетности.
ОСНАЩЕНИЕ АНАЛИЗА КАДРАМИ
Анализ лучше всего организовать таким образом, чтобы образова¬
лось небольшое ядро из занятых им постоянно в течение всего процесса
его проведения должностных лиц и множество людей, выделяемых из
областей пользователей, принимали в нем временное участие. Ядро за¬
дает направление, координирует вход, создает схемы и представляет
результаты. Оно должно состоять из отличных специалистов и его не
следует делать слишком большим. Идеален состав из четырех человек,
обладающих высокой квалификацией. Большие комитеты редко создают
хорошие проекты.
126

Консультант по вопросам стратегического планирования:
BSP-комнтеты были слишком велики. Требовалось много людей, чтобы
проводить беседы и записывать их результаты. Эти люди собирались и выска¬
зывали блестящие идеи. При участии более шести человек это может продол¬
жаться бесконечно. Со стороны руководства не было определенного заявления
о направлении анализа. Чтобы переварить информацию и установить направле¬
ние, требуется небольшая группа высококвалифицированных специалистов.
Группа-ядро не должна состоять целиком из специалистов в обла¬
сти ЭОД. Идеальный состав: два специалиста в области ЭОД с опытом
работы с базами данных и два человека — не специалисты по ЭОД, но
обладающие большим опытом работы и широкими познаниями относи¬
тельно деятельности предприятия. Специалисты в области ЭОД задают
тон в методологии, они знают те программные средства, которыми необ¬
ходимо пользоваться. Другие специалисты помогают привлекать к ана¬
лизу некоторых пользователей. Главой группы часто назначается адми¬
нистратор данных (стратег данных).
Некоторые виды анализа объектов выполнялись гораздо большей
группой-ядром. В одной крупной сталелитейной фирме в анализе посто¬
янно участвовало II человек не из отдела ЭОД. Когда запросили столь¬
ко людей, не было никакой надежды, что выделят для этого лиц из ру¬
ководящего состава. Никакая корпорация не может позволить, чтобы
такое число руководителей оставило свои прямые обязанности. Все
11 человек были служащими.
Лучше кратковременное, но тщательно спланированное участие в
анализе высшего руководства. Время его участия должно быть согласо¬
вано до начала анализа. Эффективной является такая организация ана¬
лиза, когда в процессе его проведения через определенные интервалы
назначаются короткие встречи с высшим руководством часа на два.
К каждой встрече следует тщательно готовиться.
Кроме группы-ядра, которая проводит беседы с руководителями, за¬
нимающими ключевые посты, в анализе должны принимать участие
аналитики из числа пользователей, выделяемые для этой работы на ко¬
роткий срок, например один день в неделю. Каждый аналитик работает
в тех областях, которые он хорошо знает. Число требуемых аналитиков
зависит от размера предприятия. В одной большой аэрокосмической
корпорации над анализом данных для одного из подразделений работа¬
ло 40 аналитиков. Для небольших корпораций достаточно трех-четырех
аналитиков.
Аналитиками должны быть хорошие специалисты, а не такие, от
которых рады избавиться и которые не делают ничего полезного в орга¬
низации. Руководитель группы проведения анализа должен заявить ад¬
министрации, что если аналитиком будет человек, время которого не це¬
нят, то это не тот специалист, который необходим. Однако высококва¬
лифицированных специалистов не дадут больше чем на один день в не¬
делю.
Иногда такими аналитиками-пользователями бывают лица, занима¬
ющие весьма солидный пост, которые принимают активное участие в
проекте.
127

Руководитель проекта:
К анализу объектов мы привлекли финансового директора. Его возраст
был близок к пенсионному, и он хотел продолжать эту деятельность после ухо¬
да на пенсию. В группу, занимающуюся проектом, входил главный бухгалтер и
директор-распорядитель. Руководителя отдела сбыта привлекали к работе время
от времени, когда дело касалось его области.
Бухгалтер быстро освоил анализ, имеющий системный характер, понятный
ему. На первых этапах определения данных именно он вел запись всех данных.
У нас была разработана форма, в которой перечислялись атрибуты, описываю¬
щие каждый объект. Сначала мы не пытались их нормализовать, но бухгалтер
проявил энтузиазм и быстро обучился нормализации.
ЦЕНТРАЛЬНАЯ КООРДИНАЦИЯ
г
Аналитики-пользователи, работающие каждый в своей области, ото¬
бражают процессы, действия и объекты, которые они идентифицируют.
Центральная группа просматривает такой перечень и включает его в
общую картину корпорации. Дублирование бывает большое. Централь¬
ная группа исключает дублируемые объекты, сокращая список объектов
до приемлемого размера.
Названия, которые аналитики дают объектам, часто не соответст¬
вуют названиям, принимаемым центральной группой. Окончательное
решение по наименованию объектов может принимать администратор
данных. Аналитикам можно разрешить придерживаться своих названий,
по крайней мере, на какое-то время. Соответствие названий отразит
словарь, в котором будет помещен список объектов. Такой словарь не¬
обходим, так как один и тог же объект разные аналитики часто называ¬
ют по-разному.
Карта объектов создается постепенно, по мере поступления данных
от аналитиков-пользователей. Когда происходят крупные изменения (об¬
новления), ее следует перерисовывать автоматически. Для ясности при
перерисовке следует делить объекты на группы и супергруппы. Оконча¬
тельное определение супергрупп происходит после завершения проекта
и выполнения анализа сходства, а для объединения их в предметные ба¬
зы данных пользуются различными субъективными и прагматическими
соображениями.
ОБУЧЕНИЕ АНАЛИТИКОВ-ПОЛЬЗОВАТЕЛЕЙ
Обучение аналитиков-пользователей имеет особенно важное значе¬
ние для успешного проведения анализа. На вопрос «Что бы вы сделали
иначе, если бы вам пришлось еще раз выполнять такой анализ?» руко¬
водители групп проведения анализа непременно отвечают, что необхо¬
димо лучше организовывать предварительное обучение аналитиков-
пользователей.
Чтобы аналитики смогли полностью понять, как надо идентифици¬
ровать процессы, действия и объекты, нужно решить множество приме¬
ров и учебных задач. Процессы в каждой области часто определяются
до того, как начинается работа, и до того, как аналитики пройдут курс
обучения.
В одних организациях аналитикам читают курс по нормализации
данных, в других — нет. В некоторых организациях объясняются только
основы нормализации, а в некоторых—третья нормальная форма (но
не четвертая). Обучение нормализации помогает аналитикам лучше по¬
нять, что же такое объект, но это не является строго необходимым для
проведения анализа объектов.
128

Руководитель группы:
Мы прочитали для всех участников проекта краткий курс по основам нор¬
мализации. Для большинства из них не составило труда обучиться этому. Глав¬
ный бухгалтер быстро научился получать третью нормальную форму и с удо¬
вольствием это делал.
Не было необходимости в том, чтобы аналитики-пользователи нормализо-
вывали данные. Мы могли это быстро сделать за них. Но весь смысл заключался
в том, что они стали понимать, зачем нужны нормализованные данные. Иногда
они находили на наших системных картах объекты, которые не были полностью
нормализованы. Это вошло в привычку.
Интервьюер:
Сколько времени понадобилось вам для обучения пользователей?
Руководитель ЭОД:
Это зависело от самих пользователей. Как только они понимали идею
процесса, действий и объектов, они могли идти и заниматься этим целую веч¬
ность. Одни схватывали все на лету. С другими было труднее. Один человек
через шесть месяцев работы в составе группы заявил: «Я все-такп не понимаю,
что такое объект?» Другие становились специалистами за неделю.
Интервьюер:
Удивительно, что кто-то за шесть месяцев не смог этого понять. Что это
был за пользователь?
Руководитель ЭОД:
Профсоюзный деятель. Он имел дело с ЭВМ в течение нескольких лет.
В колледже не учился. У него были хорошие знания в области функционального
применения вычислительных машин. Оказывал большую помощь в определении
потребностей других пользователей и в переговорах со службой ЭОД. Но он
просто не был способен к абстрактному мышлению. Мы могли бы отчислить его
раньше, в процессе проверки обучающихся. Но он был очень полезным членом
группы.
Важно понимать, что некоторые очень ценные специалисты испыты¬
вают большое затруднение в усвоении абстрактных понятий. Чтобы про¬
верить, полностью ли слушатели понимают предмет, необходима тща¬
тельная проверка во время курса их обучения. Тех людей, которым не
доступны абстрактные представления, обычно не следует привлекать к
работе в качестве аналитиков-пользователей.
В некоторых случаях возникает другая проблема. Среди пользова¬
телей есть люди, считающие, что они владеют лучшими способами ана¬
лиза данных предприятия.
Консультант по вопросам стратегического планирования:
В одной компании с высоким уровнем технологии производства проектиро¬
вание систем было ее коньком: прототипы, испытательные стенды, испытания
и т. д. Одна из проблем, с которой мы столкнулись, это самозванные эксперты.
Их было множество, большинство из них — инженеры или бывшие инженеры.
Они мгновенно становились «знатоками» в вопросах определения объектов, баз
данных, систем, путей проведения анализа. В конце концов мы были вынужде¬
ны «щелкнуть кнутом» и сказать, чтобы они подчинялись правилам нашей мето¬
дологии. Не надо навязывать свою философию всей группе.
Когда руководители высшего уровня впервые привлекаются к ана¬
лизу, их вклад часто касается в первую очередь насущных проблем и
их, капризов. Необходимо перейти от этой фазы к более глубокому пони¬
манию перспективы развития и функционирования предприятия. К тому
времени, когда будут внедрены сложные системы, перед 'дирекцией
будут стоять другие проблемы.
129

Консультант по вопросам анализа данных:
Сначала администрация проявляет заботу в основном о существующих «горя¬
чих точках». Надо перейти от этого к более фундаментальным положениям.
Каковы основные элементы организации? О чем просят руководители? Почему?
Что побуждает их к этому? О чем они должны просить при наличии поставлен¬
ных перед ними задач? Объекты, получаемые в результате этих вопросов, 'за¬
метно отличаются от тех объектов, которые вы получили сначала. Когда проис¬
ходит такое изменение, вы осознаете, что пройден второй этап анализа.
Интервьюер:
Как вы это распознаете?
Консультант по вопросам анализа данных:
Можно же отличить потребности момента и нечто более постоянное, отно¬
сящееся к перспективам.
Попытка выработать у руководства умение взглянуть на будущее
использование данных может привести к базам данных, принципиально
отличным от тех, которые возникли бы при исследовании текущих про¬
блем.
ДВОЙСТВЕННОСТЬ МЕТОДА ПРОЕКТИРОВАНИЯ
Администратор данных:
Мы не смогли бы осуществить это, только синтезируя представления поль¬
зователей. Мы просто не знали, как пользователи будут применять эти данные.
Это заставило нас обратиться к фундаментальному анализу объектов.
В некоторых случаях мы делали предположения об использовании данных,
основываясь на одной области, и когда мы шли к руководителю другой области,
он говорил: «Черт возьми! Я совсем не так веду свой отдел».
Мы действительно выполняли канонический синтез, потому что его можно
осуществить автоматизированным способом. Он служил проверкой анализа объ¬
ектов. Мы считаем, что нужно проделать все три формы анализа: анализ объ¬
ектов, анализ представлений пользователей и анализ транзакций. Каждый из
них служит проверкой для других.
Для каждого предприятия требуется проектирование сверху вниз и
снизу вверх. Проектирование сверху вниз должно быть связано в боль¬
шей степени с производительностью — устранением дублирующих друг
друга прикладных программ и дублирования в их ведении, реорганиза¬
цией процедур и структур предприятия в целях повышения их эффек¬
тивности. При проектировании снизу вверх следует руководствоваться
соображениями, связанными со стабильностью, проектированием треть¬
ей (и четвертой) нормальной формы, языками конечных пользователей,
сокращением стоимости ведения, гибкостью и быстротой разработок бу¬
дущих приложений.
Схематизация объектов сверху вниз и моделирование данных снизу
вверх проверяют друг друга. Для них должны применяться одни и те же
средства проектирования, чтобы данные, собранные во время анализа
объектов, или идентифицированные в это время атрибуты сохранялись
для фазы моделирования данных.

ГЛАВА 10
ПЛАНИРОВАНИЕ РАСПРЕДЕЛЕНИЯ ДАННЫХ
ВВЕДЕНИЕ
По мере уменьшения стоимости вычислительных машин и запоми¬
нающих устройств все более распространенной становится распределен¬
ная обработка данных, а с нею — и распределение данных. Когда дан¬
ные хранятся во многих местах на относительно дешевых машинах, не¬
обходимость в проектировании и контроле сверху вниз еще большая,
чем при наличии централизованных систем баз данных. При отсутствии
проектирования сверху вниз или если оно не подкрепляется участием
руководства, возрастает вероятность того, что каждый системный ана¬
литик или каждая группа пользователей будут создавать свой собствен¬
ный проект данных. В некоторых корпорациях распределенная обра¬
ботка и распространение мини-ЭВМ послужили причиной хаотического
представления данных.
Преимущества малых ЭВМ и распределенных данных многочислен¬
ны и помимо низкой стоимости аппаратуры. Желательно использовать
эти преимущества, избегая вреда, наносимого несовместимостью дан¬
ных. Для этого требуются распределение функции администрирования
данными и строгий контроль со стороны руководства за выполнением
централизованного плана развития данных.
В некоторых случаях руководители отделов пользователей усилен¬
но стремятся иметь собственные мини-компьютеры с системами,
спроектированными так, как они хотят.
Руководитель отдела конечных пользователей:
Лично я бы метал громы и молнии, если бы узнал, что группа обработки
данных действительно собирается строить систему для меня. Так было раньше.
Мне не нравится, что, когда вы уже выстроили систему в уме и убедились,
что задуманное возможно, вдруг вновь начинается эта болтовня о том, почему,
дескать, нельзя это осуществить эффективно на нашем собственном мини¬
компьютере.
По мере усовершенствования мини-ЭВМ и их программного обеспе¬
чения все желательнее становится, чтобы у пользователей были свои
собственные ЭВМ и базы данных.
ОСНОВАНИЯ ДЛЯ РАСПРЕДЕЛЕНИЯ ДАННЫХ
Если позволяет стоимость технологии, данные имеет смысл хранить
там, где они используются. Неоднократно доказывалось, что когда отде¬
лы-пользователи рассматривают файлы данных как «свои данные» и
131

полностью отвечают за их ввод и точность, целостность данных улуч¬
шается. Во ‘многих вычислительных центрах ввод и хранение данных
стали функцией, полностью контролируемой отделом-пользователем, а
не функцией центрального отдела ЭОД. И в этих случаях точность дан¬
ных намного возросла. •
Некоторым определенным данным присущи свойства, которые
естественно приводят к распределению, а другим данным присущи свой¬
ства, которые естественно приводят к централизации. Эти свойства пере¬
числяются в вставках 10.1 и 10.2.
Основное свойство, приводящее к распределению, заключается в
том, что данные используются на одном периферийном участке и редко
или никогда не используются в других местах. Большая часть информа¬
ции, имеющейся в филиале конторы, например адреса клиентов, не ис¬
пользуется нигде, кроме этого филиала. Однако другая информация,
генерируемая в филиале, требуется в другом месте, например заказы
клиентов, нужные заводам-изготовителям, показатели сбыта, требую¬
щиеся для центрального снабжения, или цифры полиса страховой ком¬
пании, необходимые для расчетов страховки в головной конторе.
Вставка 10.1. Свойства, присущие некоторым данным,
которые приводят к распределению
1.	Данные используются на одном периферийном участке и редко или
никогда не используются на других. Передача таких данных для хранения мо¬
жет быть неоправданно сложной и дорогой.
2.	Точность, секретность и надежность данных являются предметом мест¬
ной заботы.
3.	Файлы являются простыми и используются одним или несколькими при¬
ложениями. Следовательно, применение программного обеспечения баз данных
не даст никаких преимуществ.
4.	Частота обновлений слишком высока для единой централизованной си¬
стемы хранения данных.
5.	Поиск или манипулирование с периферийными файлами осуществляется
на языке конечных пользователей, который неявно приводит к инвертирован¬
ному списку или операциям с вторичным ключом. Слишком большое число опе¬
раций такого типа может вызвать трудности в работе центральной системы.
Такие файлы лучше размещать в периферийной системе, где конечные пользо¬
ватели будут отвечать за их использование и нести все расходы.
Вставка 10.2. Свойства, присущие данным,
которые приводят к централизации
I.	Данные используются централизованными приложениями, такими, как
расчет заработной платы в корпорации, снабжение или общий учет.
2.	Пользователям во всех областях требуется доступ к одним и тем же
данным и притом к их текущей (на последнюю минуту) версии. Эти данные
часто обновляются. Во избежание затруднений, связанных с синхронизацией в
реальном времени многочисленных копий, имеющих высокий уровень обновле¬
ния, данные можно централизовывать.
3.	Пользователи определенных данных перемещаются с места на место, и
дешевле централизовать эти данные, чем создавать переключаемую сеть данных.
4.	Данные будут искать как одно целое. Они составляют часть информаци¬
онной системы, дающей ответы на спонтанные запросы пользователей, на многие
из которых-можно ответить, только исследовав множество записей. Поиск дан¬
ных, которые географически разбросаны, занимает чрезвычайно много времени.
Чтобы программное и аппаратурное обеспечение гарантировали эффективный
поиск, надо, чтобы данные находились в одном месте. Можно воспользоваться
вторичными индексами, программы индексации применимы только к таким дан¬
ным, которые находятся в одной системе памяти.
132

5.	Структуры данных проектируются таким образом, чтобы служить мно¬
жеству приложений и использоваться с программным обеспечением баз данных,
гарантируя получение преимуществ, которые рассматриваются в работе [1].
Из соображений эффективности и из-за сложности это программное обеспечение
работает сегодня с централизованными, а не с географически разнесенными
данными.
6.	Данные должны быть хорошо защищены. Процедуры защиты могут быть
дорогостоящими, требующими, вероятно, тщательно охраняемого, надежного
хранилища и жесткого контроля над уполномоченными пользователями. Данные
легче охранять, если они находятся в одном месте, а не разбросаны (причем
резервные копии будут находиться в другом месте, вне этой системы).
Защита от катастрофы нередко служит доводом в пользу дублированных
систем, а не в пользу единой централизованной памяти.
7.	Данные слишком массивны для того, чтобы их размещать на недорогих
внешних устройствах памяти. Экономичнее хранить их в емкой центральной
памяти.
8.	Для осуществления контроля за системами иногда сохраняют такие
подробные сведения, как, например, какие транзакции обновляли определенные
данные. Иногда дешевле и надежнее помещать их в большом централизован¬
ном устройстве архивной памяти.
Простота файлов и их использование только одним или нескольки¬
ми приложениями также естественно приводят к распределению. В этих
случаях нет необходимости в сложных операциях с базами данных.
Другая причина хранения определенного объема данных в отделе
пользователей заключается в том, что пользователи ищут их или приме¬
няют в виде «информационной системы». Для этого могут требоваться
вторичные индексы, инвертированные файлы или структуры данных,
которые отличаются от тех, что используются в центральной машине.
Время поиска таких данных в ответ на запросы пользователей может
быть значительным и поэтому поиск лучше осуществлять на собствен¬
ных мини-ЭВМ у пользователей. Тогда запросы не будут создавать труд¬
ностей в работе центральной машины, а планирование работы централь¬
ной машины не будет мешать пользователям обращаться к своим соб¬
ственным данным. Отдел-пользователь будет отвечать за время, затра¬
чиваемое им на поиски в информационной системе.
Много можно сказать в пользу того, чтобы информационные систе¬
мы перестали ограничивать конечного пользователя рамками ориента¬
ции на производство и предоставили ему возможность свободного ис¬
пользования данных по своему усмотрению.
ОСНОВАНИЯ ДЛЯ ЦЕНТРАЛИЗАЦИИ ДАННЫХ
В вставке 10.2 перечисляются свойства данных, которые естествен¬
но приводят их к централизации.
,Во многих системах имеются данные обоих типов: естественно цен¬
трализованные и естественно распределенные. Большая часть информа¬
ции, находящейся в филиале конторы, например адреса клиентов, не
нужна нигде, кроме этого филиала. Другая же информация, получаемая
в этом филиале, требуется централизованным информационным или уп¬
равляющим системам, таким, как снабжение или производственное уп¬
равление.
Централизации способствует и такой признак данных, как их по¬
стоянное обновление и обращение к ним со стороны многочисленных
пользователей, находящихся в географически разбросанных местах.
Этим пользователям нужна картина данных в целом на текущий мо¬
мент, а данные модифицируются пользователями, находящимися в раз¬
ных местах. Поэтому в одном месте хранится одна копия данных. Это
133

относится к системам резервирования мест на авиалиниях, в гостиницах,
при аренде автомашин. Так работают и с системами управления запаса¬
ми, военными системами раннего предупреждения, системами проверки
кредитоспособности и т. д.
Данные, в отношении которых делается множество запросов, можно
распределять, если только они редко обновляются, если допускается,
чтобы данные, выдаваемые в ответ на запросы, имели давность в не¬
сколько часов, или если обновления поступают только из одного источ¬
ника. В международном информационном обслуживании можно иметь
копии данных во многих местах. Если на них часто ссылаются, это со¬
кратит стоимость их передачи. Эти данные редко обновляются из цен¬
трального источника. Система фондовой биржи, выдающая текущие
курсы акций или другую информацию, может пользоваться множеством
копий одних и тех же данных. Здесь обновления совершаются часто, но
поступают они из одного источника.
Если пользователь всегда применяет терминалы, расположенные в
одном и том же месте, можно хранить интересующие его данные в этом
месте. Если пользователи перемещаются территориально, то данные ли¬
бо следует хранить централизованно, либо применять средства пере¬
ключения, чтобы соединять этих пользователей с системой, в которой
хранятся интересующие их данные. В банке, имеющем много филиалов,
записи о клиентах можно хранить в том филиале, в котором содержатся
их счета. Однако большое преимущество банковской автоматизации за¬
ключается в том, что клиенты могут пользоваться любым из филиалов.
Поэтому во многих банковских системах с распределенным интеллектом
имеется централизованное устройство памяти для хранения записей о
клиентах. Транзакции клиентов можно хранить локально и передавать
в центр через определенные промежутки времени. Возможно, централи¬
зованно будут храниться только балансы и ограничения счетов, так как
этого достаточно для обслуживания большинства требований клиентов,
когда они обращаются в филиал банка, а не в свое отделение. Весьма
вероятно, что только небольшая доля всех посещений клиентом банка
приходится не на его отделение, а на другие, поэтому при необходимо¬
сти механизм переключения может направить транзакции, осуществля¬
емые не в своем отделении, на ЭВМ, находящуюся в отделении клиента.
В одной и той же системе часто сосуществуют различные виды ис¬
пользования данных, поэтому некоторые данные в одной и той же си¬
стеме могут быть централизованными, а некоторые децентрализован¬
ными.
В системе резервирования мест на авиалиниях большинство сооб¬
щений (часто 90%) касается информации о рейсах и наличии мест.
Такая информация составляет небольшую часть всех данных и ее легко
хранить в местах нахождения терминалов. Другие данные, в частности
записи о бронировании мест пассажирами, занимают гораздо больший
объем. Все сведения о бронировании мест на определенный рейс пойдут
в один пункт, туда, где контролируется этот рейс. Этим пунктом может
быть центральная ЭВМ, но это необязательно; разные рейсы могут
контролироваться ЭВМ, распределенными по тем участкам, где осуществ¬
ляется большинство резервирований на эти рейсы (особенно на между¬
народных авиалиниях). ЭВМ, контролирующая рейс, посылает сообще¬
ния на терминальные ЭВМ, когда уровень резервирования на этот рейс
приближается к критическому. Она постоянно дает последние сведения
терминальным ЭВМ о наличии мест. Такой вид работы обеспечивает
различные преимущества по сравнению с полностью централизованной
системой: низкую стоимость телекоммуникаций, меньшее время реаги-
134

рования и большую надежность. Интересно отметить, что такая работа
близка к тому, как работали авиалинии до введения сегодняшних цен¬
трализованных систем резервирования.
В вставке 10.2 перечисляются и другие свойства данных, способст¬
вующие их централизации. Одним из них является объем. Данные зани¬
мают достаточно большой объем и можно воспользоваться экономичны¬
ми большими устройствами памяти. Другое свойство — защищенность.
Определенные данные требуют надежной защиты. Обычно они состав¬
ляют небольшую часть всех данных предприятия. Процедуры их защиты
могут включать создание несгораемых бомбоубежищ, недоступных для
вторжения, в которых могут размещаться устройства памяти, обращение
к которым будет осуществляться по коаксиальному кабелю. В этом убе¬
жище будет находиться охрана и лицо, ответственное за жесткий про¬
граммный контроль за доступом к данным [14]. У предприятия может
быть более одного надежного хранилища. Защита от катастрофы часто
служит доводом в пользу дублированных систем.
Сильным аргументом в пользу централизации является то, что дан¬
ные будут искать как единое целое. Чтобы ответить на определенные ти¬
пы вопросов пользователей, могут потребоваться операции с вторичны¬
ми ключами (индексами). Организация данных может быть частью
информационной системы, которая должна отвечать на спонтанные за¬
просы пользователей, на многие из которых можно ответить, только
изучив множество записей. Для такого типа операций существует от¬
личное программное обеспечение, но оно требует, чтобы данные нахо¬
дились в одной машине. Поиск или операции с вторичными ключами
над географически разбросанными данными занимают очень много вре¬
мени и бывают неэффективными. Для улучшения работы информацион¬
ных систем создаются аппаратурные средства, способствующие ассоциа¬
тивным операциям или операциям с вторичными ключами. Для этого
опять же потребуется, чтобы данные находились в одной машине. Эта
машина может быть центральной или периферийной, как у небольших
функциональных информационных систем.
Если требуется поиск или операции с вторичными ключами только
над небольшой частью данных, то их часто передают из распределенных
систем в специализированные информационные системы.
МНОГОКРАТНЫЕ КОПИИ ДАННЫХ
Стоимость малых запоминающих устройств падает гораздо быстрее,
чем стоимость передачи данных. Это склоняет чашу весов в пользу рас¬
пределения данных. Как мы увидим в гл. 12, когда машины дешевы,
делать многократные копии становится экономичнее, даже если данные
обновляются довольно часто, при условии, конечно, что существуют
соответствующие механизмы программного обеспечения и контроля.
На заре развития систем управления базами данных главным аргу¬
ментом в пользу баз данных было исключение избыточных копий дан¬
ных. Некоторые авторитеты (но не автор) определяли базу данных как
неизбыточный набор данных. В определенных обстоятельствах избыточ¬
ность имеет свои экономические преимущества при условии, что сущест¬
вуют программные средства контроля за обновлением копий и обеспе¬
чения их целостности. Когда имеются избыточные копии, их структура
должна выводиться из одной и той же неизбыточной логической модели
данных.
В вставке 10.3 перечисляются основания для создания множества
распределенных копий одних и тех же данных.
135

Наличие многократных копий данных при отсутствии хорошего про¬
граммного обеспечения распределенных баз данных может создавать
проблемы, связанные с целостностью и синхронизацией данных. В неко¬
торых вычислительных центрах недостатки такого программного обеспе¬
чения возместили за счет установки контрольных механизмов, создан¬
ных заказчиком.
Другие проблемы, связанные с распределенными данными, перечис¬
лены в вставке 10.4. Их следует учитывать при планировании распреде¬
ленных систем.
ШЕСТЬ ФОРМ РАСПРЕДЕЛЕННЫХ ДАННЫХ
Распределенные данные могут существовать в шести различных
формах:
1)	копируемые данные;
2)	подмножество данных;
3)	реорганизованные данные;
4)	секционированные данные;
5)	данные с отдельной схемой;
6)	несовместимые данные.
Вставка 10.3. Основания для многократного распределения копий данных
Система может проектироваться с более чем одной копией одних и тех же
данных, помещенных в разных местах, при наличии следующих причин:
1.	Стоимость передачи
Создание копий может быть дешевле передачи данных на большие рас¬
стояния.
2.	Время реагирования
Доступ к данным, расположенным тут же, а не на расстоянии, может зна¬
чительно сократить время реагирования.
3.	Доступность
Обращение к локально размещенным данным или к их копиям может зна¬
чительно повысить доступность данных.
4.	Зашита
В случае разрушения одной копии данных можно воспользоваться двумя
или более их копиями. (Термин «выживаемость» употребляется в военных си¬
стемах для обозначения того, что данные все еше доступны после разрушения
множества их копий.)
5.	Организация данных
Одни и те же данные в разных машинах могут быть организованы по-раз¬
ному, например, в производственной системе и в информационной системе.
6.	Стоимость преобразования
Старые файлы могут сохраняться после внедрения баз данных или рас¬
пределенных систем из-за высокой стоимости и значительного времени преоб¬
разования их программ для работы с новыми структурами данных. Когда дан¬
ные относятся к определенным классам, возникают проблемы, связанные с конт¬
ролированием целостности многократных копий.
Вставка 10.4. Проблемы, связанные с распределенными данными
В связи с .распределением данных могут возникать различные проблемы,
они разрешимы, но таковы, что часто лучше избегать неограниченного распре¬
деления и копирования данных.
1.	Помехи между двумя обновляющими транзакциями
Две транзакции могут обновлять один и тот же элемент данных на ди¬
станционном устройстве памяти и мешать друг другу, давая неточные данные.
Воспрепятствовать этому могут соответствующие замки или протоколы.
136

2.	Противоречивые считывания	,
Когда имеется более чем одна копия данных, а иногда и одна копия рас- I
пределенных данных, при чтении данных можно получить противоречивую ин- I
формацию. Считанные данные могут быть недействительными в связи с пробле- 5
мами синхронизации. Это также можно предотвратить с помощью соответству¬
ющих замков или протоколов.
3.	«Мертвые объятия»
Блокировка распределенных данных с целью предотвращения помех в свя¬
зи с обновлением может привести к тупиковым ситуациям, если не будут ис¬
пользоваться соответствующие (довольно сложные) протоколы.
4.	Протокольные перегрузки
Могут возникать чрезмерные перегрузки, особенно при использовании мно¬
гократных копий, связанные с протоколами, предотвращающими недействитель¬
ные обновления, противоречивые считывания и ситуации с «мертвыми объятия¬
ми», если эти протоколы не будут тщательно продуманы.
5.	Восстановление
Следует контролировать восстановление после отказа, чтобы обновления не
были случайно потеряны или не обрабатывались дважды.
6.	Восстановление многократных копий
После отказа множество копий данных могут находиться в разных состо¬
яниях. Их нужно свести снова к одному и тому же состоянию - но это бывает
сложно осуществить во время обработки транзакций в реальном времени.
7.	Различное представление данных
Из-за отсутствия администрирования данных или строгого контроля со
стороны руководства одни и те же данные н разных местах представлены по- I
разному.	j
8.	Ревизование
В некоторых распределенных системах трудно выявить, кто что сделал с
данными. Для проведения ревизования требуется соответствующий проект.
9.	Защита и обеспечение секретности
В распределенных системах контроль защиты и обеспечения секретности !
иногда бывает слабый и его нужно включать в базовый проект	I
1.	Копируемые данные
Копирование данных связано с хранением идентичных копий одних
и тех же данных в различных местах. Основной причиной для копиро¬
вания служит тот факт, что при дублируемом хранении отпадает необ¬
ходимость передачи данных между системами и что первое дешевле вто¬
рого. Такая организация оправдана только в том случае, если частота
обращений к данным гораздо меньше частоты обновлений. Копируемые
данные в большинстве своем являются неизменяемыми (или редко из¬
меняемыми, потому что практически нет полностью статичных данных).
В качестве примера приведем такую систему обслуживания населе¬
ния, как система почтовой службы Великобритании Prestel (система
viewdata [15]). Она позволяет получать данные на экране домашнего
телевизора, соединенного телефонными линиями с системой. Множество
копий одних и тех же данных хранятся в относительно небольших ло¬
кальных системах. Эти данные обновляются из центральной системы.
Другим примером служит международная корпорация, использующая
данные, запросы на которые делаются во многих странах. Хранить ко¬
пии данных в разных странах дешевле, чем обрабатывать запросы в
международной сети данных.
Копирование данных становится все более привлекательным с эко¬
номической точки зрения, потому что стоимость небольших запоминаю¬
щих устройств снижается быстрее стоимости телекоммуникаций.
2.	Подмножество данных
На периферийных ЭВМ часто хранятся данные, являющиеся под¬
множеством данных, которые находятся в большей ЭВМ. Это делают
по двум основным причинам. Первая: данные используются часто на
этом периферийном участке, вторая: данные создаются на этом участке.
137

В ходе*операции ввода данных данные часто передаются с панели
в локальную ЭВМ, Там они проверяются. Над пакетом данных осущест¬
вляются контроль точности и ревизия, затем этот пакет передается в
удаленную базу данных.
Подмножество данных представляет собой один из видов копируе¬
мых данных. Мы выделяем его потому, что оно обычно не имеет полной
схемы или полного набора ключей «родительских» данных.
Обычно в машине более высокого уровня хранится главная копия
данных. Когда в машине более низкого уровня в данные вносится изме¬
нение, оно должно передаваться в машину высшего уровня — иногда
мгновенно, иногда позднее, в цикле обновления.
В других системах в машинах низкого уровня могут храниться не¬
которые данные, находящиеся в машине высшего уровня, а также свои
собственные данные, которые никогда не передаются наверх. Например,
в машинах низкого уровня могут храниться адреса заказчиков и общие
сведения о них. Эти громоздкие данные никогда не требуются системе
более высокого уровня. Однако в этой системе могут храниться номера
заказчиков, фамилии, кредитная информация и детали заказов. Они
также хранятся в машинах более низкого уровня, но любые их модифи¬
кации должны передаваться наверх.
Слишком часто из-за отсутствия скоординированного планирования
данные в машине более низкого уровня бывают несовместимыми с дан¬
ными, находящимися в машине более высокого уровня. Это затрудняет
обмен данными между машинами. Если данные являются обмениваемы¬
ми, они требуют трудоемких преобразований.
3.	Реорганизованные данные
В работе [1] мы подчеркивали, что базы данных IV класса требуют
иной организации данных, чем базы данных II или III класса. В инфор¬
мационной системе или системе поддержки решений обычно содержится
некоторая часть тех же данных, что и в рутинной производственной си¬
стеме, но они реорганизованы посредством инвертированных списков,
вторичных индексов или других механизмов, облегчающих выборку ин¬
формации с использованием множественных вторичных ключей.
Все данные, находящиеся в системе IV класса, могут быть отобраны
из баз данных (или файлов), размещенных в других машинах (или да¬
же в той же самой машине), но эти данные суммированы, отредактиро¬
ваны и реорганизованы. Чтобы эта работа была выполнена удовлетво¬
рительно, оба типа баз данных должны иметь одинаковое представление
полей; они должны выводиться на основании одной и той же модели
данных и словарного представления.
4.	Секционированные данные
Секционирование данных подразумевает, что одна и та же схема
применяется в двух или более машинах, но в каждой машине хранятся
различные данные. В каждой машине помещены разные записи (раз¬
ные первичные ключи), но они имеют одинаковую структуру.
Это общепринятая и ценная форма распределения. В системе райо¬
на А хранятся данные района А, в системе района В — данные района В
и т. д. Своя ЭВМ может быть установлена в каждом филиале организа¬
ции, в каждом магазине розничной торговли, на каждом складе или в
других подобных местах. Все они пользуются одними и теми же про¬
граммами. Большинство транзакций возникает и обрабатывается там,
где находятся их данные. Для некоторых могут потребоваться данные из
другого места, и тогда их или передают к месту размещения данных, или
данные передаются к ним.
5.	Данные с отдельной схемой
138

Что касается данных с отдельной схемой, то это означает, что в
различных ЭВМ содержатся разные данные и разные программы, и их
обычно устанавливают разные группы людей. Например, в одной систе¬
ме могут содержаться производственные данные, в другой — закупочные
данные, в третьей — данные общего бухгалтерского учета и т. д.
Хотя их схемы различны, эти отдельные системы данных должны
быть частью общего централизованного плана, иначе возникнут нежела¬
тельные несоответствия и избыточность. Одна из ЭВМ часто может
быть вынуждена посылать транзакции в другую или запрашивать у нее
данные. Производственная система, которая может быть размещена на
фабрике, создает требования на закупку и передает их в закупочную
систему. Обе эти системы могут генерировать данные, которые должны
передаваться в систему общего бухгалтерского учета.
6.	Несовместимые данные
Иногда данные, находящиеся в отдельных системах, не имеют ниче¬
го общего в смысле проектирования или планирования. Пользователь
же может обращаться к множеству отдельно разработанных систем
с одного терминала через сеть ЭВМ. Он должен отдельно изучить дан¬
ные каждой ЭВМ, способы обращения к ним и их использования.
Нередко такие системы создаются для различных целей, как, напри¬
мер, многочисленные системы (ARPANET, EURONET и другие), до¬
ступные через сети коммутации пакетов. Иногда они существуют в пре¬
делах одной корпорации и являются несовместимыми из-за отсутствия
централизованного планирования.
СИНХРОННЫЕ И НЕСИНХРОННЫЕ ДАННЫЕ
Одинаковые распределенные данные первых трех форм — копируе¬
мые, подмножества и реорганизованные — могут существовать на двух
или более машинах. В этом случае для проектирования важен вопрос:
синхронизированы ли многочисленные копии данных? Другими словами,
когда значение атрибута изменяется в одной из копий, изменяется ли
оно мгновенно в других копиях?
Контрольные механизмы синхронизации двух или более копий дан¬
ных являются сложными, потому что аппаратурные отказы или переда¬
чи могут происходить в любой момент. Одна из копий может выпасть
из синхронизации, возможно, на несколько часов. В то время, когда де¬
лаются попытки восстановить синхронизацию, обновление данных не
прекращается и могут происходить другие отказы аппаратуры или пе¬
редачи. В некоторых базах данных программное обеспечение все же
осуществляет синхронизацию множественных копий данных в безот¬
казном режиме, но в большей части этого не делается.
В большинстве случаев нет необходимости поддерживать сиюминут¬
ную синхронизацию между удаленными друг от друга копиями данных.
Синхронизация одной копии может запаздывать на час или на день.
Только одна копия обновляется в режиме диалога. Такие обновления
передаются дискретно другим копиям, а для проверки того, что пакет
передан и применен без потери обновлений или случайного дублирования
обновлений, применяются контрольные механизмы.
Деление копий данных на синхронные и несинхронные дает, по сути,
девять типов распределенных данных:
•	копируемые данные (синхронные),
•	копируемые данные (несинхронные),
•	подмножество данных (синхронное),
•	подмножество данных (несинхронное),
139

•	реорганизованные данные (синхронные),
•	реорганизованные данные (несинхронные),
•	секционированные данные,
•	данные с отдельной схемой,
•	несовместимые данные.
Все они суммированы в вставке 10.5.
Вставка 10.5. Распределенные данные могут
существовать в шести различных формах
1.	КОПИРУЕМЫЕ ДАННЫЕ
Многочисленные копии
одних и тех же денных
хранятся 6разных пестах,
потону что это дешевле
их передачи. Обновление
многочисленных копий
тщательно контролируется
7.	подмножество данных
Подмножества данных,
совместимые с исходной
базой данных, хранятся
отдельно для в бода
данных, Выборки или
местной обработки
3.	РЕОРГАНИЗОВАННЫЕ ДАННЫЕ
Данные в информационной
системе или системе
поддержки принятия решений
извлекаются из данных,
находящихся В рутинной
производственной системе
4.	СЕКЦИОНИРОВАННЫЕ
ДАННЫЕ
На разных участках
используется одинаковая
структура данных, но не
одинаковые данные
<о» Общий бухгал-
L^J терский учет
5.	ДАННЫЕ С ОТДЕЛЬНОЙ
СХЕМОЙ
На разных участках
используются различные
структуры данных,
образующие интегрированную
систему
мКаГимЬ Приобретение
6. НЕСОВМЕСТИМЫЕ
ДАННЫЕ
Независимые системы ЭВМ,
установленные разными
руководителями или
данные подразделений,
спроектированные без
координации
Данные	pi Лоборатор-
хорпороции я U	к	х	IJ на я си стена
гггтДттг^	<	r^Wr^l
улобнай 38*^
Сеть Ь
Л	С ««о. Библиотек -
Дачные корпо- О	^ LJ ноя система
рации 8 mJ^j/ <—, Ч ХгтЧл.
Эти категории данных потребуется различать на некотором этапе
плакирования распределенных систем. Есть, конечно, еще одна допол¬
нительная категория. Данные могут не быть распределенными. Раз¬
бросанные терминалы или ЭВМ могут осуществлять доступ к единой
централизованной базе данных.
140

ЛОГИЧЕСКОЕ, А НЕ ГЕОГРАФИЧЕСКОЕ ПЛАНИРОВАНИЕ
Описанные в предыдущих главах карты, составленные при централи¬
зованном планировании, не показывают географического распределения
данных. Обычно желательно создавать стратегический план данных,
который не учитывает их распределения, по крайней мере вначале. Это
вызвано тем, что факторы, рассматриваемые при решении о том, рас¬
пределять ли данные или как их распределять, сложные, и некоторые
из них изменяются со временем, как, например, наличие сети, стоимость
малых ЭВМ и запоминающих устройств, стоимость передачи данных,
программное обеспечение распределенных баз данных и расположение
рабочих помещений. Стратегический план данных реализуется долго, и
за это время параметры распределения могут значительно измениться.
Стратегическое планирование должно сначала создавать логические,
а не географические карты данных.
С другой стороны, на раннем этапе можно решить, что завод или
подразделение будет иметь свою собственную ЭВМ. Для этого целесо¬
образно стратегическое планирование, потому что проблемы, возникаю¬
щие в процессе его, легче поддаются решению, чем проблемы, связанные
со всей корпорацией. Недостаток централизованного планирования, про¬
водимого для отдельных частей предприятия, заключается в том, что
хотя оно и проще, но не раскрывает избыточных и общих проблем, а так¬
же отклонений по всей корпорации. Довольно часто филиалы и отделе¬
ния корпорации, в каждом из которых есть своя ЭВМ, могут пользовать¬
ся одними и теми же схемами баз данных и одинаковыми программами.
Решение о том, какой объем организации будет охвачен контролем стра¬
тегии централизованного планирования, крайне важное и его следует
принимать с самого начала. В пределах этого объема все данные долж¬
ны быть схематизированы; вначале без схематизации распределения.
Тем не менее информацию о распределении удобно собирать в то же
время, когда собирается другая информация.
МАТРИЦЫ РАСПРЕДЕЛЕНИЯ
Процессы в организации происходят в разных местах. Матрицы, ко¬
торые приводились в предыдущих главах, можно расширить, чтобы они
показывали также географическое размещение процессов.
На многих участках протекают идентичные процессы. Например, в
каждом филиале должны выполняться одинаковые задачи. Поэтому
филиалы можно представить в матрицах одной линией. Заводы чаще
будут перечисляться отдельно, потому что их административное управ¬
ление обычно различается. Их процессы и требуемые для них базы
данных отличаются в деталях. На любом заводе может существовать
производственная база данных, но каждая будет иметь свою структуру.
Процессы в организациях, рассмотренные в предшествующих главах,
можно отобразить на фоне тех географических участков, где они проис¬
ходят. Рис. 10.1 иллюстрирует это. Такая схема может показывать, кто
несет главную ответственность за процесс, кто принимает в нем основное
участие, а кто небольшое.
Целесообразно выверять карты процессов путем бесед с ответствен¬
ными за их выполнение руководителями. Рис. 6.4 представляет собой
карту BSP, на которой показано, кто из руководителей в каких процес¬
сах участвует. Можно начертить аналогичную матрицу, показывающую,
с какими участками связаны различные руководители, такая матрица
поможет определить, как участки выполняют разные процессы.
141

о
н
ПРОЦЕСС	J
х	5
<	О	X
<	со	о	g	*	®
5	3	2	Л	га	X
£	£	Z	ex	X	го
X	X	X	q	х	^	X
О.	О.	£	о	S	х
Ю	Ю	Ю	зе	>х	^
ГО	ГО	ГО	Q	cq	X	с-
в	•$	е	^	о.	о	и
Анализ рынка
X
х
Пересмотр объема выпуска продукта
X
X
Прогнозирование сбыта
X
х
Финансовое планирование
X
Капитальное вложение
X
Управление фондами
X
Проектирование продукта
/
/
/
/
X
Ценообразование продукта
X
Поддержание спецификации продукта
/
1'
/
Потребности в материалах
X
X
X
Закупочная деятельность
X
X
X
Получение материала
X
X
х|
Управление заказами
X
X
X
/
Контроль качества
X
х
X
Планирование производственных мощно¬
стей
х
X
X
/
Планирование режима работы предприя¬
тия
X
X
X
Размещение рабочего потока
X
X
X
Управление материально-техническим
снабжением
х
X
X
Упорядочение по типоразмерам
X
X
X
Машинные операции
X
х
X
Территориальное размещение
X
X
Продажа
X
X
Административное управление сбытом
х
X
Связи с заказчиком
X
х
Управление запасами готовой продукции
X
Обслуживание заказов
X
X
Упаковка
X
Отправка
X
Кредиторы и дебиторы
X
Х|
X
X
Движение денежной наличности
X
X
X
/
/
/
X
Фонд заработной платы
X
X
X
/
/
/
X
Ключ:
X —интенсивное
участие;
/—слабое участие
142

Продолжение
Производственный учет
х
х
X
х
Разработка плана и смет
X
X
Анализ прибылей
X
х
Планирование численности работающих
х
X
х
Комплектование штата
/
/
/ / /
/ X
Компенсационная политика
/
/
X
Рис. 10.1. Участки, связанные с протеканием каждого процесса
Аналогичным образом, когда будут разработаны предметные базы
данных или супергруппы объектов, их можно отобразить на те участки,
где они используются, как это выполнено на рис. 10.2. Для верхней ча¬
сти рис. 10.2 не имеет значения, распределены ли данные. Это сложная
проблема, и обсуждается она в последующих двух главах. Когда реше¬
ние принимается, матрица заполняется, как это сделано в нижней части
рис. 10.2, где показаны типы распределения данных: подмножество, ко¬
пия, секция и т. п. Когда имеют дело с копиями, подмножествами или
реорганизованными данными, обычно хранят главную копию данных.
На рис. 10.2 она показана буквой М.
Для отображения процессов, предметных баз данных и участков,
использующих их, требуется трехмерная матрица, как на рис. 10.3. Она
является расширением рис. 5.6. Аналогичным образом размерность, обо¬
значающую участки, можно добавить и к другим последующим картам,
приведенным в гл. 5. Теперь рис. 10.3 можно разбить на отдельные ма¬
трицы для каждого участка, показывающие системы на каждом из них.
как на рис. 5.10.

Ж
Ключ: U — используют,
С — создают н используют.
На этой схеме показано, какие участки какими предметными базами данных пользуются. Однако в схеме не говорится о том как эти
данные должны распределяться. Позднее, когда будут проанализированы параметры, влияющие на распределение на этой схеме следующим
образом можно показать, распределяются ли данные и какого типа распределение:	'	' 7
е
to
5
Со
П
5
СП
1 £
0
СО
2
1
о
X
Со
X
о
X
о
to
ж
1 -
t
ГС
X
2£
О
X
о
to
X
X
X
с
Планирование
с
с
с
о
Бюджет
с
с
о
Финансовая
с
с
Продукт
с
о
о
Проектирование
продукта
п
п
Номенклатура
п
Список
материалов
п
о
п
Открытые
требования
о
п
ст
Поставивп;
о
Поставки
л
Запас
материалов
Г)
п
Загрузка
машины
п
о
Незавершенное
производство
п
п
о
Средства
о
о
Цеховая
маршрутизация
Заказчик
с
с
с
о
*
с
Сбыт
Территория сбыта
с
п
Запас готовой
продукции

Заказы
с
с
г
с
с
г
Q
Платежи
п
Ст
1Ьдгржки
о
п
о
о
Служащим
Г)
о
о
п
Оклады
ПРЕДМЕТНЫЕ БАЗЫ ДАННЫХ

ПРЕДМЕТНЫЕ БАЗЫ ДАННЫХ
УЧАСТКИ
О
X
03
с
ч
2
ю
о
е
о
С
S
X
о
о ^
л
л
ф
о
0
о Е
X
О X
3 й
£ г
О н
£
о
С
о
2
аз
S.
ф
S
X
го
3
го
S
га
го
го
СП
о
о
X о
3
Ф m
га
га
2 °
X X
га
%
ф
и
га
га
го ^
3 £
о л
га s
га
га
го
СП
3
ю
га
га
О
га га
Си h
о
9 5
ГО
га с
3
го
го
СП
ф
2
Е
*
Си
Ф
>s
s
3
га
>
п(
га
X
о
Главная контора
м
М
м
м
м
м
V
м
т
т
м
М
м
р
р
Склад
м
R
р
р
Районная контора
т
т
R
м
м
т
р
р
Контора отделения
Р
р
р
R
т
р
р
Фабрика А
т
т
S
S
р
V
V
S
р
р
V
V
V
V
R
т
Т
v 1
р
р
Фабрика В
'Г
I
1
R
т
т
V
р
р
Фабрика С
т
т
R
1
1
т
т
1
V
р
р
Ключ: М — главные данные: уникальные на одном участке,
V — вариант: на разных участках разные версии схем,
Р — секционированные данные: схемы одинаковые, значения разные,
R — копируемые данные: идентичные данные на разных участках,
Sподмножества данных,
RG — реорганизованные данные,
Т — телеобработка: данные хранятся на этом участке.
Рис. 10.2. Предметные базы данных на каждом участке

ors 'эи<1
EH MEM ‘EMLOEhX ОЛОГЖЕЯ BLT HldEM ЭПНЧЬ'ЭГЮ EH НКЭХЭ ИЭТЛрО dUHOngEEJ '£'01 'MJ
WX^ud IQC09 H9H13hid3dU
О мп/ ими
У Oh нОпЪоОмиыо^
oi oim
ОЛморО! M1OU*Oh
Ynho/oiogoa пюрччзи
-inn апмороопноии
ni/fiqgnau tnuDh^
11ыо n
DhDOb ohiogodr^o
oiihMigijgop^ody
nohiogodos
nioo^hnudh
nWHlHip ЗПН1*Пру
•	ng ip n /9doi npid*
cngaluiQ
OMpOMOufi
рармос
9пмодп^п^эди
лпппЛроач подо! и г
n*ooouos дпмаодоРи^
*о*пыо*о1 j nexgj
*	oi ng о зльюдоаор
опаздоОд
jn*o>ni*iao
loxirDnOeinddi^
ашым 1/9ьнптсц
-	Oimt 01 9nn9nOQ9 Пор
Н1гн9*донр
ляп - id* inhvgafon
Ом 0101/
auxogod irwtni*tpn
ипщпл>дж1ь fiiopdd
o*n*id зпмодоопыяи
nilKMXV* 1’9/410/^
■ snodo дпкодослноои
ogioihD* 9ood 140x
n*oj0oos jnvitgodofi
Deonduo* train ft ми
91J0
- ^//1i 4	*0** Ou fix £
Y 000001/D*
П1304010/1
oi.xhpodu гпПомп
пПзиО 1П*Ри(фрр(
oi мпроа
Шч од or оор <1041
omnpoO
i.ohogod п/ *1000
л*ороФ inhiogodux
апча^оад ^tioinuox
1Пыодо0пчО1го
idbqjuoh^
Oiiigo зпнвдтсохиои
oixdpodu омэfiung
о*идо Oio^iddu
Oddi9d с пион^
1ЧЗЗЗЩЩ
$
9 *
n л n
МММ
D/Jffini/Pu
V Oh^Q.n hew* 1U*0h
вл Dim
dn*DQ01HdlfUH0#
intn&oiogaf лзооина/
■ОПП 1П hODodnuDuy
niungnau snuoh^f
11*0 /7
dhdw DHiogodtoq
DWnIQi ^QO^tnody
nohiogalos
п/Юыьпиоч
ПО4*1Ы0д 0040*000
! 9 OOI
■ngap n /woinpad^
D^godUlQ
o*go*oufi
got oxoi
апнодп^Аиодо
xBqmu noooi or
nuDJDuot inuiugodun
*омпл conns j nsugj
мoutgo рпнаидоОир
VVDQOdU
anv&wtfd
ooHwonooinddai
ХПЬоааиО 04ННТТПЮН
*009*100
-WU to mHMM0toP
*1ПН0ждЬ*0.
my и-id* an two aw
0*0100
aaihogod дпнатзюол
^nUndupadu itioooo
сып^а дпнороолноии
пампа* i^agigoog
Vm/ апнодоапноии
pgijgnox wo di мн •
п*оооиое эпшдвйиь
oyondiiD* anndhfhrtu
91101/
■9f1J6ap ^^^J^^
- lid* g nigoHQioiou
Din про Ob nnhonna
-nniuj in^o^aiQMu
DIMnpodu
inHDQOSDdpoOHrtl
'DiHApodu
' annxjgodrnxia]u
п*о0хоф inxiifgtx^fi
MHi*oq a^rpinuox
enuogod
Л Л Л
OindpOdu OhOfut^g
оыэчдо d/o*jadt0
DHHtdd ini/D^
О DHndg^
& oxndgo^
и o^ndgo^
ипПэиедю
Ddo 140^
vdoiHO^
dDNNOna^
0W*J
duoihqh
UDHgDUJ
mhhvV nsvs эннинузаи
1433 WQSU

ГЛАВА 11
РАСПРЕДЕЛЕНИЕ ДАННЫХ:
КАЧЕСТВЕННЫЙ АНАЛИЗ
ВВЕДЕНИЕ
При проектировании распределенной обработки данных необходимо
решить, где должны пропускаться различные прикладные программы.
В настоящей главе рассматривается качественный подход к решению
этого вопроса, а в гл. 12 — количественный.
ЛОГИЧЕСКИЕ УЗЛЫ КОНЕЧНЫХ ПОЛЬЗОВАТЕЛЕЙ
Проектировщик может начать свою работу с определения логиче¬
ских узлов конечных пользователей. Для этого составляется список ка¬
тегорий конечных пользователей и мест их размещения. Например:
•	персонал склада, Бриджпорт,
•	персонал склада, Лос-Анджелес,
•	конторские служащие, Нью-Йорк,
•	конторские служащие, Чикаго,
•	конторские служащие, Лос-Анджелес.
Приложения обычно можно рассматривать по группам, тесно свя¬
занным, чтобы к ним применять одни и те же аргументы. Такие группы
приложений образуют процессы, о которых мы говорили в предыдущих
главах. Процессы следует выбирать таким образом, чтобы они были на¬
столько автономными, насколько это разумно для использования не¬
больших групп типов записей и для как можно меньшего взаимодейст¬
вия с другими процессами, особенно теми, что выполняются в ином, уда¬
ленном месте.
Для каждой категории конечных пользователей перечислим процес¬
сы, которые им необходимы. Так:
Персонал склада, Бриджпорт
•	получение,
•	контроль за складами материала,
•	контроль за складами продукции,
•	отправка.
Это дает ряд логических узлов приложений. Некоторые из этих уз¬
лов могут не ассоциироваться с человеком: например, контроль пара¬
метров в автоматизированном процессе.
Для каждого логического узла конечных пользователей может ис¬
пользоваться централизованная обработка или обработка на месте
расположения конечного пользователя.
147

ТАБЛИЦЫ ФАКТОРОВ
Решение о централизации или распределении прикладных программ
для какого-либо процесса зависит от множества факторов. Метод проек¬
тирования, впервые примененный в Слоановской школе управления,
MIT [16], для каждого процесса предполагает использовать таблицу,
в которой перечисляются все «за» и «против» централизации. Аргументы
в пользу централизации или децентрализации разработки и функциони¬
рования систем различны, иные они также и для административного уп¬
равления. Об этом свидетельствуют столбцы таблицы, приведенные на
рис. 11.1, отображающие разные аспекты этих аргументов. Строки таб¬
лицы показывают факторы, учитывающиеся при выборе централизации
или децентрализации.
Для любого процесса существует вероятность наличия противоречи¬
вых факторов. Таблица факторов позволяет сразу увидеть их. Разные
организации могут по-разному выбирать те факторы, которые они счи¬
тают нужными. На рис. 11.2 и 11.3 приводятся два примера.
На рис. 11.2 представлен банк, имеющий много отделений. Таблица
факторов составлена для принятия решения о том, как автоматизиро¬
вать обработку проверочных счетов клиентов. Буквами, набранными
полужирным шрифтом, отмечены те факторы, которые считались доми¬
нирующими. Одним из наиболее главных факторов признали возмож¬
ность для клиента обращаться в любое отделение банка, расположенное
в любом месте, и получать требуемый вид обслуживания. Этот фактор
является весомым аргументом в пользу централизованной базы данных,
содержащей информацию о счетах клиентов. Важность осуществления
контроля и ревизии также была аргументом в пользу централизации, но
имеющим меньший вес. Другие факторы на рис. 11.2 свидетельствуют
в пользу децентрализованных данных и децентрализованной обработки.
Особенно важными были требования к высокой степени доступности и
надежной защите от катастроф. Для обеспечения доступности системы
в любое время требуется, чтобы память располагалась в местах разме¬
щения пользователей и не зависела от линий телефонной связи, но что¬
бы в случае локального повреждения существовала резервная телефон¬
ная связь с центральной системой. Фактор защиты от катастрофы при¬
водит к тому, чтобы не иметь единого централизованного средства.
Требование высокой точности на входе диктует необходимость ре¬
дактирования и проверки на вводе с периферийных устройств. Большая
сеть с быстрым реагированием требует периферийной «интеллектуаль¬
ности» для передачи данных.
Этот байк спроектировал систему со смешанной централизацией
и децентрализацией. Зашита от катастрофы требует, чтобы было два
центра, а не один. Обработка транзакций производилась периферийно,
но в случае отказа могла осуществляться централизованно. Проектиров¬
щикам хотелось бы хранить достаточно информации о каждом клиенте,
чтобы можно было выполнить его основные требования в любом отде¬
лении банка. Память периферийных ЭВМ была не очень большой, поэ¬
тому решили держать в ней минимально необходимую информацию
о каждом клиенте из данного географического района в каждом отделе¬
нии, находящемся в данном районе. Если же клиент зайдет в какое-ли¬
бо отделение, находящееся за пределами этого района, его будет обслу¬
живать центральная система. Когда он находится в своем районе, его
запросы могут выполняться, даже если центральная система недоступ¬
на. Небольшое число запросов поступает также из других районов.
48

Ключ: С — весомое основание для
централизации,
с — слабое основание для
централизации,
D — весомое основание для
децентрализации,
d — слабое основание для де¬
централизации,
DC — кооперирование между
центральной и локальной
группами.
Разработка систем
Работа систем
A
a
G
^
8
S
X
К
CO
a
X
X X
< n
a
о
&
X
E
Ф
О
X
и
о
Ф
я
О. Ф
б X
к
X
X
ф
О
X
с
о
ю
CQ
К
X
X
ф
о
R
X
о.
Е
W
О
О
СО
О.
со
<0
а.
ф
X
X
со
0
О
О.
h
°- 5
1 к
2 *
О co
^ ffl
<0 0
= 2
” о
CQ u
ф
X
X
co
ca
о
a
X
X
«О
4
Ф
d
X
tf
О
X
CQ
CO
X
5
co
d
xo
О
Ф
X
X
Ф
31
d X
c *
О £
CO >
5
CO
0
X
3
X
X
CO
4
co
СП
CO
IQ
Требуются данные, которые хранятся
DC
централизованно
Большинство данных можно хранить
c
c
локально
d
D
D
D
Требуется управление базой данных
(в противопоставление файлам)
Данные интегрированы с другими
данными, которые хранятся в других
DC
c
местах
DC
c
DC
С
Генерируются данные, необходимые
для центрального руководства
DC
DC
с
Приложение простое
Приложение требует большого опыта
d
d
d
d
d
d
работы с ЭВМ
Приложение требует больших знаний
С
c
местных проблем
D
d
d
Приложение изменяется редко
Приложение изменяется часто под
с
c
влиянием локальных факторов
Приложение изменяется часто под
D
D
D
влиянием нелокальных факторов
Приложение уникальное на одном
С
C
C
c
участке
Приложение дублируется на многих
D
D
D
D
участках
С
С
C
C
Приложение влияет на центральное
управление организацией
Локальные подсистемы в высшей сте¬
с
DC
DC
c
с
пени аналогичны
с
c
c
Локальные подсистемы отличаются по
структуре
Приложение размещается вдали от
d
d
d
d
центра ЭОД
Приложение размещается в другой
d
d
d
d
d
d
d
d
с
стране, а не там, где находится центр
ЭОД
D
D
D
D
D
D
D
D
D
D
Важна быстрота реагирования
D
D
D
D
n
Важна высокая степень доступности
а
и
D
Существует большое число неосуще¬
ГК
я
Я
ствленных приложений
и
а
u
a
a
Приложение уже осуществлено в
p
r
p
централизованном порядке
Ъ
V
Приложение по характеру предпри¬
нимательское
D
D
D
d
d
d
d
d
Приложение крайне чувствительное и
ГК
гч
n
критическое для подсистемы
D
D
D
D
D
Активное участие руководства подси¬
стемой
D
D
D
D
Необходимо сделать руководство
подсистемой ответственным за прило¬
жение
D
D
D
D
D
D
D
D
Сохранность приложения существен¬
*
p
но важна для всей организации
c
c
Q
149

Продолжение
Периодически требуется большая па¬
мять или большой ЦП
Местный персонал в целом квалифи¬
цированный
Местный персонал имеет хороший
опыт работы с ЭВМ
Местный персонал неквалифициро¬
ванный
Надежная и откликающаяся на за¬
просы центральная группа
Центральная группа перегружена ра¬
ботой или не откликающаяся на за¬
просы
d
D
С
С
D
d
D
С
С
D
d
D
С
С
D
D
С
с
d
d
С
d
С
С
d
d
С
С
Рис. 11.1. Таблица факторов для проектирования распределения [16)
Разработка систем
Работа систем
•
А
С
Рь
а
о
я
■
А
К
X X
5“
о
А
X
X
я
X
с
о
Q
X
и
о
я
к
и
Н U
я я
Аал
н я
О А
к
к
X
о
о
S
А
С
О.
О
ю
CQ
■
X
и
о
к;
X
с
с*
X
я
А
СП
я
А
и
а
X
X
я
ч
0)
X
я
о
о
а.
X
U
о
С
С X
-— X
31
АО
я о
= 2
” о
со ?
V
X
я
х
о
А
Я
X
я
Kt
о
А
X
К
о
и
CQ
Я
X
я
А
S
<6
X
X
о
X
X
о
5
С
о
я
А
5
я
е
И
Л
X
X
я
*
я
я
я
СО
Данные о счетах клиента могут по¬
требоваться в любом отделении
Аналогичное приложение во многих
отделениях банка
Отделения в высшей степени схожи
Приложения не требуют больших
знаний местных проблем
Приложение изменяется редко
Некоторые отделения расположены
далеко друг от друга
Требуется довольно быстрое реагиро¬
вание
Система должна быть доступна в лю¬
бое время
Желательна работа автономных тер¬
миналов
Для работы с терминалом надо обу¬
чить много операторов
Очень важна возможность произво¬
дить ревизию
С
С
с
С
с
с
с
С
с
с
с
С
с
с
d
D
d
d
d
D
d
d
c
D
d
d
С
d
D
d
d
с
С
С
с
С
Надежная защита от катастрофы
крайне важна
Требуется большая точность (уточне¬
ние / проверка входа)
Местные группы не имеют опыта ра¬
боты в области ЭОД
Центральная группа ЭОД надежная
и отвечающая на запросы
с
с
с
с
с
с
с
с
D
D
d
D
d
с
с
Рис. 11.2. Таблица факторов применительно к транзакциям клиентов в банке, имею¬
щем много отделений. Элементы, выделенные полужирным шрифтом, считались опре¬
деляющими
150

Разработка систем
Работа систем
ГРУППА ПРИЛОЖЕНИЙ
Критическое приложение для
подсистемы
d
D
Требуется высокая степень до¬
ступности для приложения по
операционному контролю
d
Необходим большой опыт рабо¬
ты в области ЭОД
с
Сложная обработка
с
Требуется приспосабливаемость
к быстрому изменению
d
Интегрирование с другими фай¬
лами и группами приложений
С
С
Периодически требуется боль¬
шая память
С
ПОДСИСТЕМА
Специализированная задача
d
Быстро изменяющаяся среда
d
Имеется талантливый руководи¬
тель
d
Опытные люди в отделе ЭОД
подсистемы
(1
d
СРЕДА
Недавно централизованная орга¬
низация
С
С
Недавно централизованная
ЭОД
с
с
Надежная и отзывчивая группа
ЭОД	'
С
С
Рис. 11.3. Таблица факторов применительно к расчету кредитной задолженности кли¬
ента. Элементы, выделенные полужирным шрифтом, считались определяющими [16]
Все факторы на рис. 11.2 говорили в пользу разработки приложений
группой центрального отдела ЭОД, и это было осуществлено. На
рис. 11.3 приводится таблица факторов, использованная в другой орга¬
низации для разработки кредитной системы заказчика [16]. Факторы,
считавшиеся доминирующими, отмечены буквами, набранными полу¬
жирным шрифтом, это:
•	критическое приложение для групп пользователей, запрашиваю¬
щих его,
•	интеграция с другими файлами и группами приложений,
•	большой объем памяти, требующийся время от времени,
•	надежная и чуткая к запросам группа ЭОД.
Первый из этих факторов служил доводом в пользу децентрализа¬
ции из-за тех вкладов, которые вносили отделения в успех системы. Три
других фактора говорили в пользу централизации. Приложение в боль¬
шой степени опиралось на существующую базу данных заказчиков и в
нем использовался сложный алгоритм расчета. Дублирование базы дан¬
ных на децентрализованных мини-ЭВМ обошлось бы дорого.
151

В результате предпочтительной оказалась централизованная систе¬
ма с централизованной разработкой. Доминирующей причиной послужи¬
ла отличная репутация специалистов из группы центрального отдела
ЭОД. В отделениях верили в то, что их прежний опыт работы с этой
группой не подведет и на этот раз.
Там, где группам пользователей удавалось вырвать управление из
рук центрального отдела ЭОД, доминирующим фактором часто служили
неотзывчивость специалистов в области ЭОД, плохое обслуживание, пе¬
регруженное расписание или недостаточная доступность центральных
средств.
Окончательный выбор системы часто зависит не от одного процесса,
а от многих. Решение может приниматься на основании ряда таблиц
факторов, подобных приведенным на рис. 11.2 или 11.3. В некоторых
случаях эти таблицы показывают, что определенные процессы следует
пропускать на отдельных ЭВМ, иногда соединенных в сеть, иногда ав¬
тономных. Например, банковская система, представленная на рис. 11.2,
решила пропускать несколько приложений, таких, как обработка дорож¬
ных чеков на небольших отдельных ЭВМ.
ИССЛЕДОВАНИЕ НА КОНКРЕТНОМ ПРИМЕРЕ
Рис. 11.4—11.11 относятся к конкретному примеру — двум реально
существующим производственным корпорациям. Для наглядности их
анализ значительно упрощен.
На рис. 11.4 показан ряд прикладных процессов, используемых в уп¬
равлении производственной корпорацией. В этой корпорации применя¬
ется в основном централизованная пакетная обработка с «немыми» тер¬
миналами, установленными в торговых конторах и некоторых других мес¬
тах. Сейчас в корпорации хотят повысить уровень автоматизации, чтобы
добиться лучшей эффективности сбыта и производства, а также сокра¬
тить штат. Рассматривается возможность осуществления распределен¬
ной обработки данных.
Корпорация имеет три фабрики, много торговых контор, научно-ис¬
следовательскую лабораторию, которая обслуживает всю организацию
и главную контору. Традиционно она делилась на шесть функциональ¬
ных областей. На рис. 11.5 показаны процессы в каждой области. Доку¬
менты, которыми обмениваются эти функциональные области, определе¬
ны формально (независимо от того, записи ли это с ЭВМ или документы,
составленные вручную).
Некоторые приложения выполняются непрерывно, оперативно, дру¬
гие — ежедневно в пакетном режиме, третьи выполняются реже, как по¬
казано на рис. 11.4. В корпорации хотят, чтобы большее число опера¬
ций выполнялось оперативно, хотят повысить гибкость и улучшить реак¬
цию отдела ЭОД, повысить точность данных и обеспечить более эффек¬
тивные источники информации для руководства.
Между корпорацией и внешним миром осуществляется передача дан¬
ных, как показано на рис. 11.6. Большое число передач данных проис¬
ходит внутри корпорации между отдельными приложениями, как пока¬
зывает рис. 11.7. Желательно применение распределенной обработки,
чтобы она ослабляла, а не усугубляла сложность положения, наглядно
представленного на рис. 11.7.
152

Поступление
заказов .
(непрерывно)
Фактурирование
(ежеанеВно)
Справки
о продаже
(непрерывно) Счета
дебиторов
(ежедневно)
обработка
специальных
заказов
(периодически)
Позаказная
калькуляция
себестоимости
(когда требуется)
Расчет
заработной
платы _
(еженедельно)
Гроссбух
и бюджетный
Производственный
^ежемесячно)
Планирование
производства
по специальным
заказам
(когда требуете^
Общие
проентно-
HDH£rPy*T°Pc*iJg
(когда требуйся)
Разработка
спецификаций
на новый
продукт
Приобретение
Исчисление
издержек
на Рабочую
Еженедельно)
Фабричные
планы
и контроль _
(ежемесячно)
Контроль
качества
отгона, tnauo^ul
(непрерывно)
Пла
производства
(непрерывно)
те
Администрирование
(периодически)
Счета
кредиторов
(ежедневно)
Цехобыи
контроль
(непрерывно)
^а^ани^^30^
(непрерывно)
Прогнозирование
(ежемесячно)
Составление
сметы
(ежемесячно
Планирование
валовых
Наладочный	потребностей
контроль	(ежедневно)
(периодически)
Сетевое .
планирование
потребностей
(ежедневно)
«чеки г
о ди чесни)
Запасы ,
(непрерывно)
Рис. 11.4. Процессы,
порацией. Как
используемые в управлении
производственной кор-
применить к ним распределенную обработку?
/поступление Фактурирование
заказов 3
{Справки о I Сбыт
^ продаже

\ / Счета
/	дебиторов
/ Позаказная
I калькуляция
\ । себестоимости
Общие х
проектно-
конструкторс
кие работы
/ / Расчет
. /заработной
I I платы
I Гроссбух и.
\ бюджетный
\учет
специальных '1 1 Планиро^шрсш/^^^
J '^специальным спецификации
/заказам на новый
—	Х^ 7 продукт
| Контроль.
Т качества
I
Произволе твен- " ~- ^
ный учет Исчисление"^
		издержек на''
бухгалтерия J рабочую сил^
~	Фабричные
Счета а планы и
у кредиторов контроль /
/V Ядминистриро - \
/ оание ।
I Прогнозирование*-]
фланирование^ /
\ Составление !
'.сметы 7
/	' X
б Приобретение'^
Планирование
Валовых
I потребностей
\ Наладочный
1 контроль
j /Отгрузка р^х^
/</	Планирование'\
производства \
I ^Производство^ [
[цеховый Диспетчериза-!
/онтооль ^ цця заданий /
f Получение ^ \
^" Склады и снабжение "J
сетевое ,
планирование
потребностей
Запасы
Рис. 11.5. Традиционная организация функциональных подразделений
\Ы

Некоторые из процессов на рис. 11.7 тесно связаны друг с другом и
пользуются одними и теми же данными. Например, выписка счетов, сче¬
та кредиторов, счета дебиторов, валовое и сетевое планирование потреб¬
ностей (деталей и материалов), а также цеховый контроль и диспетче¬
ризация заданий. Тесно связанные процессы, пользующиеся одними
и теми же данными, должны быть частью одной подсистемы, чтобы пе¬
редача данных между подсистемами была минимальной.
Уведомления
Запросы | Заказы счета-фактуры
и	। Оплаты .1
заказчиков Т
—	Н	1	1

Запросы о расценках
Ответы
Поступление Фактурирование
заказов *
Справки о
продаже
Позаказнал
калькуляций
себестоимости
ораторов
Обработка
специальных
заказов
общие
проектно¬
конструкторские
работы
Расчет „
заработной
платы
Планирование
производства по
специальным
заказам
Разработка .
спецификации
на новый
продукт
Производственный
учет
Гроссбух и,
бюджетный
учет
Нс шсление
издержек на
рабочую силу
Отгрузка
Приобретение
Фабричные
планы и
контроль
Контроль
качества
Планирование
производства
Администрирование j
„	Цеховый
Счета	контроль4
кредиторов
Диспетчеризаций
Заданий
Прогнозирование
Составление
сметы
Наладочный
контроль
? панирование
аловых _
валовых _
потребностей
Получение
Проверни
расчета .
заработной
платы
Заказы на I Оплаты
приобретение j,
Сетевое в
планирование
потребностей
Запасы
4
Уведомления
Упаковочные
листы
X Получение
Т товаров
Отправка
товаров
Рис. 11.6. Передача данных между процессами, приведенными на
рис. 11.4, и внешним миром
Таблицы факторов можно было бы использовать для каждого из
процессов, показанных на рис. 11.4, чтобы определить предпочтительное
размещение: 1) его обработки, 2) данных, которыми он пользуется,
3) разработки приложений.
РАЗМЕЩЕНИЕ ВЫЧИСЛИТЕЛЬНЫХ МАШИН
В конторах отделений применяются небольшие ЭВМ для обработки
простых действий: поступления заказа, выписки счетов, обработки сче¬
тов кредиторов и простых коммерческих запросов. Для этих функций
создана относительно небольшая и простая база данных. Более слож¬
ные запросы оперативно отправляются через терминалы в системы глав¬
ной конторы или фабрик.
154

расчет
заработной
платы
Гроссбух
и бюджетный
учет
Справки
о продаже]\
Прогнозиро¬
вание
\ 1 т
Счета
у дебиторов
Позаказная
калькуляции
себестоимости
^^^эоказод^^ 2^Фин тури родание
Планиро-
бание, ‘—^~
производстиа
Отерузка
Приобретете
W
_J^ Запасы
Составление
сметы
Общие проектно-
конструкторские
роботы
Получение
Контроль
качества
Производ- “и^-^
ственныи учет исчислен#
издержек на
рабочую силу
заказам
обработка'^'
специальный
заказов’ '
по специал
Фабричные
планы и
контроль
\ администрирование
счета
редитороб
Рис. 11.7. Внутренняя
Разработка „
^. спецификаций
на новый
продукт
Планирование
„производства
/ I
7 I
1
цехобый^ ^.'^Диспетчеризация
контроль / заданий
\ Планирование \
>^ валовых
наладочный у^лотреДнос тей
контроль у ,
\ Сетевое .
планирование
потребностей
передача данных между процессами, приведенными
на рис. 11.4. При распределенной обработке следует выбрать такую конфи*
гурацию, чтобы число передач между отдельными ЭВМ было небольшим.
Для этого процессы необходимо правильно сгруппировать
КОНТОРЫ ОТДЕЛЕНИЙ
Приобретение
ОДНА ИССЛЕДОВАТЕЛЬСКАЯ
ЛА60РАТ0РИЯ
Отгрузка
Планирование
Получение
Заласы
Счета
кредиторов
Позаказ¬
ная каль¬
^еаказо^8 Фактурирование
Справки
о продаже
Счета
. дебиторов
Обработка
специальных
заказов
Расчет , Производст-
заработнои венный учет
платы
Гроссбух
и бюджетный
учет
Админис трирование
Прогнозирование
Составление
сметы
ОДМ Г плен Л Л КОН ТОРД
Рис. 11.8. Размещение
куляция
себестои¬
мости
Планирова¬
ние- произ¬
водства по
специальным
заказам
Исчисление
издержек
на рабочую силу
Фабричные
планы
и контроль
Цеховый
контроль
потребностей
наладочный Сетевое
контроль планирование
потребностей
ТРИ ФАБРИКИ
Общие проектно-
конструкторские
работы
Разработка
спецификаций
на црвый
продукт
контроль
качества
Планирование
производства
Диспетчериза¬
ция заданий
пользователей процессами, показанными на
рис. 11.4
155

Лаборатории
нм гора от воле нм
/Поступление
заказов
| [Файлы,
Файлы
контроль 1
качества J
{
кадры
база данных
специально'
га заказа^
ТСнтурирО^
Мние
Позаказной
нальнул* - ।
-— ци* себе- I
стоимости I
। Разработка
| спецификаций
1на новый
продукт
S Общие лроенгне\
' конструкторе**'
работы |
к План ирода-1
ние произ¬
водства по
специальным
заказам
[Расчет за¬
работной
I платы
I Гроссбух
Отгрузка
Файлы
база данных
Получение j
Ндминистриробание
Запасы
Фойлы
отделение
Произ
нал база
кредиторов
база данных
заказчика
база данных
запасов
ИНЫХ
поставщик
Справки
уО продаже
Прогнози¬
рование
Составление сметы
Обработке^ \
специальг i
них заказов/
аоричные
планы и
контроль
Плану
ние Mi_
потребностей
Наладочный
контроль &тгвое
планирование
потребностей
Планирование^
т делопроизводство |
Цеховый
конт-
ронз
Главная контора
Фабрика
Рис. 11.9. Области, показанные на схеме, и области внутри областей —
это отдельные ЭВМ. Все они взаимосвязаны. Чтобы контролировать
эту сложную ситуацию, точно определяются и поддерживаются отно¬
сительно простые интерфейсы между этими ЭВМ. Ключ к успеху за¬
ключается в скоординированном проекте данных (как баз данных, так
и файлов)
Рис. 11,10. Конфигурация процессоров, показанных на рис. 11.9
156

Иногда конечные пользователи тесно связанных приложений на¬
ходятся в разных местах. Например, отгрузка и выписка счетов разме¬
щаются в разных местах, как показано на рис. 11.8. Так же обстоит
дело с приобретением (закупочной деятельностью) и счетами дебиторов.
Это может быть аргументом в пользу выполнения одного из приложений
в месте, удаленном от расположения конеч¬
ного пользователя. Может быть, лучше вы¬
полнять приложения в разных местах, близ¬
ких к конечным пользователям, но обра¬
щаясь к одним и тем же данным. Например,
отгрузку можно выполнять на фабричной
ЭВМ с помощью базы данных фабрики, а
выписку счетов можно осуществлять в кон¬
торе отделения вместе со счетами кредито¬
ров, потому что это отделение контролирует
оба приложения.
Закупочная деятельность всегда выпол¬
няется группой главной конторы, которая
досконально знает поставщиков и может
получать большие скидки за счет массовых
закупок. Решение о том, что и когда приоб¬
Рис. 11.11. Тенденция
систем к росту до тех
пор, пока цена сложно¬
сти не становится слиш¬
ком высокой
ретать, поступает с фабрик после сетевого
планирования потребностей. Счета дебито¬
ров ведутся на фабриках, ио они тесно свя¬
заны с закупочной деятельностью. Данные,
используемые приложениями на фабрике,
в головной конторе и в отделениях, тесно связаны между собой и требу¬
ют координируемого планирования.
На рис. 11.8 показана единственная группа приложений, которая не
связана ни с какой другой. Ее назвали общие проектно-конструкторские
работы. Это набор приложений. Их инженеры ведут для своих собст¬
венных нужд. Они хотят пропускать их на установленной в лаборатории
ЭВМ во избежание проблем, связанных с разделением времени дистан¬
ционной ЭВМ, установленной в головной конторе.
Цеховый контроль и диспетчеризация заданий играют важную роль
в поминутном контролировании производственных операций на фабри¬
ках. Во избежание проблем, связанных с планированием времени боль¬
шой ЭВМ, или отказов, вызванных программным обеспечением, эти два
приложения пропускаются на отдельной небольшой ЭВМ с резервиро¬
ванием в главной фабричной ЭВМ. Они пользуются файлами, а не база¬
ми данных, но эти файлы тесно связаны с производственной базой дан¬
ных.
Приложение фабричные планы и контроль пропускается экспертной
группой конечных пользователей, которые подготавливают ежемесячные
бюджеты и планы для фабрики. Это сложный вид деятельности, оказы¬
вающей значительное влияние на эффективность и прибыльность рабо¬
ты фабрики. Экспертная группа конечных пользователей обычно рабо¬
тает сверхурочно, чтобы закончить составление планов и бюджетов до
начала месяца. На одной из фабрик эта группа интенсивно применяла
вычислительные средства, пропуская модули, моделируя и производя
детальные расчеты типа «А что если?». Фабричная база данных для этой
группы оказалась не столь полезной, ей нужны были собственные фай¬
лы, созданные на основе этой базы данных, которые она могла бы сво¬
бодно модифицировать в случае надобности. Группе выделили неболь¬
шую ЭВМ, оперативно соединенную с системой базы данных фабрики.
157

Она могла читать, но не изменять базу данных и создавать свои собст¬
венные файлы на основании этой базы данных. Затем файлы можно бы¬
ло видоизменять для проведения вычислений типа «А что если?*. Такая
форма работы имела успех, потому что высококвалифицированная груп¬
па пользователей разрабатывала свою собственную форму вычислений.
Это отличный пример системы поддержки решений. Руководство глав¬
ной конторы попыталось внедрить подобные методы планирования на
двух других фабриках.
В главной конторе была также группа квалифицированных пользо¬
вателей, «делающих все по-своему*, с приложением прогнозирование.
Отдел прогнозирования опробовал много различных моделей и мето¬
дов, пока не пришел к выводу, что очень ценными для создания интер¬
фейса между программами прогнозирования и руководством оказались
графические средства. На графических терминалах руководители-поль¬
зователи могли проследить, какие допущения сделаны при прогнозиро¬
вании, как видоизменяются результирующие кривые и цифры при моди¬
фикации этих допущений. Для этого отделу прогнозирования потребо¬
валась своя ЭВМ с быстро реагирующими графическими устройствами.
Он пользовался своими собственными файлами, некоторые из них были
получены из базы данных бухгалтерского учета.
На рис. 11.9 показан окончательный набор ЭВМ, файлов и баз дан¬
ных. Это вертикальная конфигурация вычислительных машин, за ис¬
ключением лабораторной системы. Она перерисована на рис. 11.10.
ГДЕ ПРОЕКТИРОВАТЬ
Системы в отделениях являются копиями и поэтому их надо разра¬
батывать централизованно. Лабораторные системы уникальны и долж¬
ны разрабатываться соответствующим инженерным составом с по¬
мощью программистов. Отдел ЭОД главной конторы разрабатывает
все приложения для этой конторы, за исключением прогнозирования.
Для большинства этих приложений нужен набор баз данных главной
конторы.
Прогнозирование выполняется группой квалифицированных специа¬
листов, и все большую роль в этом процессе начинают играть ЭВМ.
Группа создает свои собственные программы и файлы, пользуясь по воз¬
можности структурами данных корпораций, а также усиленно разраба¬
тывает методы использования графических устройств.
На каждой фабрике есть своя группа ЭОД. Все фабрики разные
и одинаковыми приложениями могут пользоваться только в ограничен¬
ной степени. Приложениями коллективного пользования являются
счета дебиторов, начисление заработной платы и отгрузка. Они идентич¬
ны на всех трех фабриках, поэтому разрабатываются централизованно
для внедрения фабричными группами ЭОД. Система обработки фабрич¬
ных данных по большей части сложная, подвержена изменениям и тре¬
бует глубокого понимания местных проблем, поэтому ее лучше разра¬
батывать фабричным группам. Базы данных кадров каждой фабрики
имеют одинаковую структуру. Другие базы данных моделируются от¬
дельно на каждой фабрике.
Организация группы ЭОД продиктована необходимостью понимания
сложных ситуаций, связанных с конечными пользователями. Группы, со¬
ставляющие проекты, имеют дело с наборами приложений и работают
в тесной связи с пользователями. Одним из таких наборов приложений
является валовое и сетевое планирование потребностей в деталях и ма-
156

териалах. Другим — планирование производства, цеховый контроль и
диспетчеризация заданий. Приложения, связанные со специальными за¬
казами, образуют особый набор, но здесь обработка специального за¬
каза является приложением филиала конторы.
Фабричные планы и контроль представляют собой наиболее слож¬
ную из всех групп приложений из-за их прямого влияния на рентабель¬
ность. На одной из фабрик, как уже говорилось, за разработку этого
Позаказная
Общие проект-
но-конструктор¬
ские работы
Поступление Фактурирование себестоимости паборатории^
заказов
Расчет за¬
работной
пл а ты St
рабочую силу
контроль
качества
ОтделзОД
г^авнойкоиторы ^^ блайд
Отгрузка
рования и
бюджетный
учет
отдел эод
трабрики
контроля
Приобретение
фабричные,
планы и /
контроль.
нас
управление
Администри
рование
Счета л /\ /
кредиторов рпаннпование
валовых
потребностей
дтдёл 'прбгно
зироданин
Прогнозироба
Сетевое
Наладочный
контроль
Составление
сметы
Рис. 11.12. Ответственность за проектирование и разработку прило¬
жений
приложения взялись конечные пользователи. Попытка оказалась весь¬
ма успешной, и головная контора постаралась осуществить то же самое
на других фабриках.
Рис. 11.12 показывает распределение ответственности за проектиро¬
вание и разработку приложений.
РЕЗЮМЕ
Конфигурация процессоров на рис. 11.10 исключает излишние слож¬
ности, показанные в верхней части кривых на рис. 11.11. В ней учтены
многие уже обсуждавшиеся преимущества распределения, а также те
преимущества централизации, которые стоит сохранить. Некоторые бо¬
лее сложные приложения разрабатываются квалифицированными ав¬
тономными группами конечных пользователей при участии программи¬
стов. Централизованная обработка осуществляется, когда это имеет
смысл. Ключом к успеху является хороший проект файлов данных и баз
данных, а также координация структур данных по всей корпорации.
Методологию составления таблиц факторов для решения о'том, ка¬
кие процессы и данные будут распределенными, можно использовать
вместе с такими схемами, получаемыми при централизованном плани¬
ровании данных, как на рис. 4.3, 5.6 и 7.10.
159

Можно определить местонахождение объектов и супергрупп, а так*
же какие данные используются — копируемые, подмножества или сек¬
ционируемые. Критические характеристики применения данных можно
отметить в матрице, отображающей классы данных на участки, где ими
пользуются или обновляют. Это выполнено на рис. 11.13 и 11.14.
Предметные
базы ванны*
и файлы
Размещение
§*
е5
Главная
контора
Лабораторий
Фабрика 1
§
а
1«а»»
РНГЮТИВН
сгапгасягад
S3
гагогогагогоииичгаа
тсйтнппйпя
DrararaErafnciracEici
иимтлотсииза
нмсннпнпинмв
!Х(чгаЯ'ыЛсюп1СиС]С]
<3
?§
О) 2?
Фабрика 2
Фабрика 3
конторы всех
отделений
доягаотгап!
ннннннн
C1S1 СЛИЧИЛИ
111
гага
oral
п
го
гаягаягагаииаитч]
ГЧЧЩЫНННЛИЯПЯ
СВИЯСВОИИШНС]
га
л
га
КЛЮЧ:
Объем считываний Объем обновлений
Время реагировании
при чтении;
Q- Быстрое
м~ Среднее
3-Медленное ,
(по возможности)
OEil
ЭС
СО
Смчность,
		обновлении:
1- Мгновенная
Критические критические
значения значение
Считывания обновлении
S-Пр возможности
л (б тот же день)
О-ночью
L-более редкая
н-высокое
м-Среднее
L - низкое
Рис. 11,13. Характеристики применения данных, которые помогают
определить типы распределения
Объем считывания и объем обновления влияют на решение о воз¬
можности копирования данных. Данные можно копировать, если они об¬
новляются редко или если обновления посылаются дискретно, например
ночью. Данные, которые часто считываются на многих участках и редко
изменяются, являются кандидатами на копирование. В рассмотренном
выше примере в конторе каждого отделения часто требуются данные
о продукте, но они не обновляются там. Эти данные не слишком объем¬
ные, поэтому их копии имеются в базе данных каждого отделения.
Требования к быстроте реагирования говорят в пользу распределе¬
ния данных туда, где они используются.
160

Предметные базы
данных и файлы
Размещение
3
о._
£5
^2
щ о
LQ
О
А
О
о X
х ЕГ
S Л
< Я
О *
►— та
L- г)
та
та
^5
из я
О
£ °
° о
* 5
о ^
х гс
с 5
ГС
h
X
М
О
о.
Е
ч
из
та
X
X
та
ГС
*
та
та
tl
lQ
га
Ж
X
3
А
ГС
О
С
Е
^
сх
и
ь га
^ ь
ГС Ф
и ST
X >»
ю о
щ 5
X
о
X
о
Си
ск
3 Z
«2
О а
О
и
О
X
Л
ч
га
X
^
Е ГС
о та
га
^ *
А
О
Р.
d
ГС
X
=(
из
А
О
X
ГС К
п
с о
о.
3 *-
ч £
83 2
га *
е г
X
О)
А
О
«3
л г4
£^
° к
Е х
3
гг
£2
е
ф
2
л
о
QJ
и
А
О
О
га
Е
га
та
С(
из
X с
о «
X О.
Ь
Ф х
О х
ри
3 5
е 5
“ КГ
^С
= о.
г с
Е *
^ X
«Е
fl
Главная контора
м
м
м
D
м
м
Лаборатория
Фабрика 1
V
р
D
V
D
V
Фабрика 2
V
р
D
V
D
V
Фабрика 3
V
р
D
V
D
V
Конторы всех отделений
м
S
S
R
Ключ: М — главные данные: уникальные в одном месте,
V—вариант: разные версии схемы в разных местах,
Р — секционированные данные: одна и та же схема, различные значения.
R — копируемые данные: идентичные данные на различных участках,
D — выводимые данные: реорганизованные.
Обозначения, набранные обычным шрифтом, — базы данных,
обозначения, набранные полужирным шрифтом, — файлы.
Рис. 11.14. Размещение данных и типы распределения

РАСПРЕДЕЛЕНИЕ ДАННЫХ:
КОЛИЧЕСТВЕННЫЙ АНАЛИЗ
ВВЕДЕНИЕ
В гл. 11 обсуждался качественный подход к проектированию рас¬
пределенных приложений. В этой главе рассмотрим количественный
подход. Количественный подход полезен, но следует подчеркнуть, что
важные факторы, влияющие на решение о том, как распределять дан¬
ные, не являются численными. Проектирование распределенных систем
нельзя полностью свести к алгоритму.
Количественный подход пытается так расположить места обработки
и хранения данных, чтобы сообщение и взаимодействие между этими
узлами не были интенсивными.
ЦЕЛЬ
При хорошем распределении данные и программы располагаются
в виде кластеров таким образом, что каждый кластер обладает высоким
уровнем автономии, и взаимозависимость между ними низкая.
Процедура кластеризации может осуществляться на уровне предмет¬
ной базы данных или на уровне объектов. Очень хорошо работать на
уровне объектов, но такой уровень детализации обычно требует, чтобы
процедура была автоматизированной. Анализ объектов, описанный в
гл. 8, идентифицирует действия и отображает их на объекты. Когда это
сделано, можно записать место, где происходит каждое действие.
Если бы машины были очень дешевыми, то на первый взгляд ка¬
залось бы, что лучше помещать данные и программы в том же месте, где
протекает деятельность пользователей. К сожалению, многие данные
находятся в коллективном пользовании при разных действиях, проте¬
кающих в разных местах. Если эти данные копировать, чтобы их мож¬
но было хранить в местах расположения пользователей, то изменения
в них надо посылать в каждое из этих мест.
Если данные обновляются действиями, происходящими в разных
местах, и обновления должны быть сиюминутными, легче иметь одну
копию данных. Обновлять множество копий в соответствии с текущими
изменениями сложно, это повышает число передаваемых сообщений и
требует замысловатых процедур восстановления в случае многих вероят¬
ных типов отказов. Наличие одной копии уменьшает взаимозависимость
между кластерами данных.
О различных формах распределения мы можем судить по объему
сообщений между узлами, которые при этом возникают. Рассмотрим,
например, систему с терминалами, установленными на А участках.
162

Пользователи на этих участках генерируют транзакции, одни из кото¬
рых пользуются данными, а другие изменяют их. Допустим, что проис¬
ходит
А „действий в час, которые пользуются данными,
Ас действий в час, которые изменяют данные.
Допустим, что эти действия равномерно распределены между ^ уча¬
стками.
Определим единицу движения как сообщение, которое передается
на узел размещения данных, и ответ на это сообщение. Допустим, что
данные централизованы в одном из узлов размещения пользователей.
Тогда сумма единиц движения в час составит:
централизованное — (А + А)
^—1
Если данные децентрализованы (т. е. хранятся на всех участках раз¬
мещения пользователей), то действия, которые пользуются данными, не
генерируют движение, а действия, которые изменяют данные, генери¬
руют ^ — 1 единиц движения каждое:
^децентрализованное ^с (^ О*
Распределение данных приводит к меньшему движению, чем цент¬
рализация данных, если
(^ц+А)^1->4^-1),
т. е. если
4^- >■
Когда существуют два участка пользователей, данные лучше распреде¬
лять, если
Когда участков пользователей 100, данные лучше распределять, если
-^->99.
Допустим, что на каждые десять случаев использования данных вно¬
сится одно изменение:
-^-=10.
Тогда переходной точкой между централизацией и децентрализацией
будет 11 участков пользователей. Другими словами, централизацию
следует осуществлять, если участков будет более 11.
Ситуация станет иной, если изменения можно вносить в данные с не¬
которым запаздыванием. Допустим, изменение в данные можно вносить
не более чем через D часов после того, как оно сделано. Через каждые
D часов можно посылать сообщение на каждый участок, где размеща¬
ются данные, с изменениями, которые произошли с момента последнего
обновления, или с указанием, что изменений не было. Когда» данные
централизованы в одном из узлов пользователей, для этого потребуется
(V—1)D единиц движения в час. При децентрализованных данных, но
163

с обновлениями, передаваемыми из центрального участка, потребуется
2(N—1)D единиц движения в час:
т	_д (^-П д. л^—1
7 централизованное 71 u j^ ' D '
т	_ 2(^-1)
■* децентрализованное — р
Точка равновесия будет при
Если D=2 часам, а пользователи генерируют 500 ссылок на данные в
час, то распределение оправдывается, если участков меньше чем
2x500=1000. Точка равновесия сильно склоняется в пользу распреде¬
ленных, копируемых данных.
ДРУГИЕ СЛОЖНОСТИ
К сожалению, проектирование систем — не настолько уж простое
дело. Существует множество спорных положений. Какова операционная
стоимость установок пользователя? Понадобится ли другим типам тран¬
закций производить поиск по всему набору данных или получать сум¬
марную информацию по ним? Каковы проблемы программного обеспе¬
чения, когда ведется множество копий одних и тех же данных? Могут ли
иметь место различные виды отказов; как происходит восстановление
после отказа? А что если во время операции по восстановлению прои¬
зойдет другой отказ? Какой тип сетевой структуры требуется?
Тем не менее приведенные выше расчеты убедительно свидетельст¬
вуют о том, что с продолжением снижения стоимости машин в основном
будут использоваться в высшей степени распределенные копируемые
данные. На раннем этапе развития технологии баз данных считалось,
что база данных будет иметь дело с недублируемыми данными. Но при¬
веденные расчеты показывают, что когда аппаратура становится деше¬
вой, есть смысл широко дублировать данные в распределенных систе¬
мах. Необходима разработка такого программного управления базами
данных, которое позволило бы легко обращаться с распределенными
копируемыми данными, не создавая проблем, связанных с целост¬
ностью.
Сами по себе расчеты движения не дают ответов на вопрос, следует
ли использовать распределенную конфигурацию. Однако они помогают
увидеть, как должны распределяться данные между существующими
ЭВМ.
Возьмем относительно простой пример. И завод, и управление (кон¬
тора) имеют систему ЭВМ. Между ними протекает определенный ряд
процессов. Планировались предметные базы данных, как описано в
гл. 4, или супергруппы объектов, как показано в гл. 7. Некоторые из
данных требуются процессам, происходящим и на заводе, и в управле¬
нии. Где следует размещать эти данные?
Одно решение — так разместить данные, чтобы свести к минимуму
движение. Если к базе данных чаще обращаются с завода, то они по¬
мещаются там. Если нет, то данные размещают в конторе.
На рис. 12.1 показана матрица участков и предметных баз данных.
164

Предметные базы
Ванных отображены
на участии и про¬
цессы. Цисрры обо-
значают объем дви-
женин о сотнях
транзакций В день
ПРЕДМЕТНЫЕ БАЗЫ ДАННЫХ
^3
*4
^5
УЧАСТОК 1
Процесс Р,
Процесс Рг
Процесс Р3
510
17
42
4
301
210
УЧАСТОК 2
Процесс Pi
Процесс Р^
319
1
105
УЧАСТОК з
Процесс q
Процесс Pg
Процесс Р6
Процесс Р7
217
38
110
405
УЧАСТОК 4
Процесс Р,
Процесс Р2
Процесс Рв
63
219
72
609
36
Базы данных раз¬
мещают 6 местах с
наиВысшим объемом
дбижения. Цифры,
не заключенные о
прямоугольники,
обозначают объем
передаваемого
движения
ПРЕДМЕТНЫЕ БАЗЫ ДАННЫХ
о.
Вч
В? Из О5
УЧАСТОК 1
Процесс р,
Процесс Р2
Процесс Р3
501
42
17	301
210
УЧАСТОК 2
Процесс я.
Процесс Рч
319
105
участок 3
Процесс Pi
Процесс Pg
Процесс Pg
Процесс р7
217
110
405
38
УЧАСТОК 4
Процесс Ру
Процесс Рг
Процесс Рв
63
219	609
72 Зб|
Те же базы данных,
что и Выше, но с
дублирующими
базами данных
В) и В; для
уменьшения передач
ПРЕДМЕТНЫЕ БАЗЫ ДАННЫХ
Bi
Вч
^2 ^3 Д5
УЧАСТОК 1
Процесс Pi
Процесс Рг.
Процесс Р3
501
42
17
301
210]
УЧАСТОК 2
Процесс Р,
Процесс Рч
319
105
1
УЧАСТОК 3
Процесс Pi
Процесс Р5
процесс Pg
процесс р7
217
110
405
38
УЧАСТОК 4
Процесс Pi
Процесс Р2
Процесс Р&
63
219	609
72 36]
Рис. 12.1
Цифры в матрице обозначают единицы движения для каждой базы дан¬
ных от каждого участка. Можно добавлять движение для каждой базы
данных из каждого участка. Базу данных можно поместить на участок с
самым интенсивным движением, как показано во второй части рис. 12.1.
Цифры, не помещенные в прямоугольники, обозначают движение меж-
165

ду узлами. Ёго можно сократить за счет уместного дублирования дан¬
ных (копии, подмножества или реорганизованные данные). Основными
кандидатами на дублирование являются данные, цифры движения для
которых в столбцах в сумме составляют самые большие числа. В треть¬
ей части рис. 12.1 показаны дублируемые базы данных Д1 и Д5. Необ¬
ходимо рассчитать число единиц движения, нужного для поддержания
обновления дублируемых данных. Оно зависит от требуемой новизны
данных.
7.	Приложений, отображенные
на используемые ими
структуры данных.
Требуется некоторая
группировка.	ПРИЛОЖЕНИЯ
приложении и
структур ванных
ПРЕДМЕТНЫЕ БАЗЫ ДОННЫХ
2.	Поиложения и стриктуры
данных сгруппированы
в матрицы 2*2 для
минимизации „
движения между ПРИЛОЖЕНИЯ
кластерами
ПРЕДМЕТНЫЕ БАЗЫ ДАННЫХ
3.	Приложения и структуры
данных сгруппированы
в матрицы 3*3 для
^^^ ПРИЛОЖЕН
кластерами
Рис.
ПРЕДМЕТНЫЕ БАЗЫ ДОННЫХ
ПРОГРАММЫ И ДАННЫЕ ВМЕСТЕ
Обычно желательно, чтобы программы и используемые ими данные
находились в одном месте. Для программы, размещенной на одном
участке, обращение к данным, размещенным на другом участке, пред¬
ставляет значительную перегрузку. К сожалению, программе часто тре¬
буются данные, находящиеся более чем в одной предметной базе дан¬
ных, а к одной предметной базе данных обращается множество про¬
грамм. Поэтому желательно так кластеризовать программы и данные,
чтобы минимизировать движение между узлами. Это проиллюстриро¬
вано на рис. 12.2. В первой части рисунка показан набор программ и баз
данных, к которым они обращаются. Цифры в этой матрице обознача¬
ют объем движения. Вычислительные алгоритмы могут группировать
программы и базы данных в кластеры размером 2x2, 3x3. Размер мо¬
жет быть и любой другой. Это показано на рис. 12.2. Цифры, не за¬
ключенные в прямоугольники, показывают движение между кластера¬
ми. Движение в целом между кластерами обычно уменьшается с увели¬
чением кластеров. Минимальное движение между кластерами достига¬
ется только при существовании одного кластера.
166

Проекты, которые минимизируют движение между программами и
используемыми ими данными, имеют тенденцию к централизации. Проек¬
ты, которые минимизируют движение между участками размещения
пользователей и участками размещения данных, имеют тенденцию к рас¬
пределению.
ПРОЦЕДУРА ПЛАНИРОВАНИЯ РАСПРЕДЕЛЕННЫХ ДАННЫХ
На рис. 12.3 предлагается процедура планирования распределенных
данных. Она начинается со стратегического плана, логически отобра¬
жающего предметные базы данных на процессы или действия (т. е. без
учета физического размещения данных).
На шаге 2 участки размещения пользователей перечисляются вместе
с процессами, используемыми на этих участках. Проектировщик отоб¬
ражает участки пользователей и процессы на предметные базы данных,
как показано на рис. 12.4, который представляет собой расширение
рис. 4.3 или 5.6.
Шаг 3 определяет объем транзакций между участками размещения
процессов и-данными и указывает, являются транзакции диалоговыми
или пакетными.
I.	Разработать матрицу процессов / предметных баз данных,, как на рис. 4.3
и 5.6.
2.	Разбить процессы по участкам пользователей, как на рис. 12.4.
3.	Определить объемы движения между участками размещения процессов
и базами данных.
4.	Изучить возможные стратегии размещения данных (с помощью вставок
10.1-10.5 и рис. 11.1).
	►б. Перестроить матрицу, как показано на рис. 12.5, чтобы показать предла¬
гаемое распределение данных.
	►б. Начертить географическую матрицу структуры данных.
7.	Изучить практические ограничения размещения структур данных (встав¬
		ка 12.1), |
8.	Определить, какие транзакции и прикладные программы должны ис¬
пользоваться.	'
9.	Классифицировать программы (рис. 12.7).
10.	Проанализировать распределение программ.
11.	Поправить / структуры данных, если возможны усовершенствования.
Рис. 12.3. Процедура планирования распределения данных
На шаге 4 определяется, какие данные должны быть копиями, под¬
множествами, реорганизованными, секционированными или иметь от¬
дельную схему. Определяется также, какие данные на каких участках
должны использоваться. Для этого можно применить методологию,
описанную в гл. 11. Можно перечислить файлы, а также базы данных:
фактически данные I, II, III и IV классов. Стратегии и руководство к
распределению данных даются в вставках 10.1 —10.5 и на рис. 11.1.
Вероятно, на этой стадии особенно важно учесть существующие
файлы и базы данных.
На шаге 5 составляется схема, такая, как на рис. 12.5; она дополня¬
ет рис. 12.4 показом географического размещения данных и типов рас¬
пределения. На рис. 12.5 приводятся оценки объемов транзакций и ука¬
зывается, диалоговые они или пакетные. Транзакции, помещенные вне
прямоугольников, связаны с передачей. Данные можно пересылать или
разделять в целях минимизации объемов передачи. В процессах, напри¬
мер в управлении производством в реальном времени; следует избегать
диалоговых передач. Если процесс управления производством отказы-
167

вает на протяжении нескольких часов, рабочих можно отправлять до¬
мой. В этом случае ЭВМ и данные для производственного контроля
должны находиться на том заводе, где они используются.
Как и по другим аспектам стратегического планирования данных,
схему, подобную той, что на рис. 12.5, можно начертить в укрупненном
или детализированном виде. Когда планирование приближается к фи¬
зическому проекту, более критическими становятся вопросы распреде¬
ления и тогда следует представить более детальный проект на уровне
действий и объектов. Однако его можно выполнить отдельно для каждо¬
го участка.
Предметные базы данных
Процессы и участки
к:
к
я
□•
О
О
я
(X
X
£
X
3
Л
о
С
X
X
00
О
С
X
*
о.
о
^
СП
X
о
о.
С
X
СП
X
X
и
оз о
X о.
о
о
о
= £
5 *
х о
я к
>х
О
«
X
о >.
2 <
с о
я о.
00 С
X
X
X
я
я
X
я
00
3
я
я
X
я
00
Главная контора
Затраты на изделия
Планирование производства
Счета кредиторов
и
и
и
и
с
и
и
и
и
Фабрика А
Отчетность о рабочей силе
Машинное планирование
Приобретение
Производственный контроль
С
с
с
с
с
с
и
с
и
С
и
Фабрика В
Отчетность о рабочей силе
Машинное планирование
Приобретение
Производственный контроль
с
с
с
с
с
с
и
с
и
С
и
Склады
Склад продукции
Обслуживание заказов
Отгрузка
с
и
и
и
и
12 отделений
Управление сбытом
Обслуживание заказов
Связи с заказчиками
и
и
и
с
с
Рис. 12.4. Расширение матрицы процессов / баз данных с показанным размещением
СТРУКТУРЫ ДАННЫХ
По мере детализации распределения матрицы могут отражать
структуры данных, а не предметные базы данных. Основная часть ма¬
триц показывает структуры данных, которые уже существуют.
Структурой данных может быть файл или база данных. И то и дру¬
гое бывает оперативным или автономным. Периферийные машины мо¬
гут пользоваться файлами, а не базами данных, потому что они доволь¬
но малы для того, чтобы использовать систему управления базами
данных.
168

X.	Предметные базы
данных и файлы
Процессы
и участки
Главная контора
Фабрика А
Фабрика В
Отделение
ф *^-
X о
X д
£ °
о го
с О
5
X ?
я X
К X
у °
С Ж
X
<0
8
а
ф
2 х
X си
2 Я
Ой СП
аз
О
X
о
о
*^х
О ф
С I
•к
о
аз
2 ®
2 a
X
о >»
а п
с о
Го Q.
on с
ха»
н
” со
со ^
ф
X
СО
о
X
о
3
со
со
X
аз
СП
к
ф ^
О ф
х ®
* 5
® 2
3 о
го а
Го X
с х
X
х
-3
X X
£ Я
я д
го о
ь а
° ж
° X
С о
ф
3
X
X
_ я
2 я
® си
^ X
"I
О X
2г
ф
3
S
ь я
X А
° S
Ei
55
= 2
5 °?
э гх
я ® *
® ь и
2 °
2««
ГО о
X о. х
. и
°3о
Я X
- « ф
5 я к
3 я °
х го
годе
ь о о
О nt X
X
ф —
О ф
~ 3
х х
х ;
® 2
3 о
Д CU
ГО X
я
С я
• ф
S3
ix
го
• X д
X о
Д си
го х
р
С Д’
ф
3
X
X
_ Я
2 «
5 О
X си
W X
11
о ®
ю *
2г
X
Е
О
X
^*
X ф>
О *
д^
С си
л
к Ф
Is?
Си J
2 я х
5
2'2’5
£ го О
X р. х
о
Си^
= и Ж
* ф *
XXй
2 х <с
ь го О
О д х
ф
3
я
* л
^ &
ci
o'
д
5S
Го Я
ГО Ef
£ О
СП ^
о
X
я
н
о
Е
3*0
со А
го и
X °
го ^
м *
Главная контора
Затраты на изделия
Планирование производ¬
ства
Счета кредиторов
ИОВ 10В
15В 21	21	151
180В	180В	180В
Фабрика А
Отчетность о рабочей силе
Машинное планирование
Приобретение
Производственный конт¬
роль
50В
10В
2В
50!
51	5!	51
101 101
101	10!
Фабрика В
Отчетность о рабочей силе
Машинное планирование
Приобретение
Производственный конт¬
роль
50В
1 0В
2В
501
51	51	51
10! 101
101	101
Склады
Склад продукции
Обслуживание заказов
Отгрузка
25В
60В
60В 60В 60В
12 отделений
Управление сбытом
Обслуживание заказов
Св^зи с заказчиками
31
21
21
151
1101. 1101
201
Ключ: 1 — диалоговое использование;
В — пакетное использование.
Рис. 12.5. Логические данные рис. 12.4 разбиты на различные типы распределенных по различным участкам данных. Данные размещены таким образом,
v чтобы минимизировать движение или потенциальные вредные взаимодействия между участками

Если используется база данных, структура данных часто объеди¬
няет множество записей, соединенных такими связями, которые приме¬
няются в СУБД. В базе данных КОДАСИЛ может содержаться не¬
сколько взаимосвязанных наборов. В базе данных DL/I (язык структу¬
рирования данных для системы IMS фирмы ИБМ) может находиться
несколько физических баз данных, связанных между собой посредством
указателей на логического «ребенка» и логического «родителя». В боль¬
шой системе баз данных обычно содержится множество отдельных баз
данных таких типов, другими словами, множество наборов взаимосвя¬
занных данных, причем эти наборы между собой никак не связаны.
Физический сеемент Г” 1 I Физическая сВязь
Виртуальный сеемент 	[ *" Лоеическая сВязь
Физическая Ваза Ванных
Рис. 12.6. Типичная большая база данных DL/I, состоящая из
12 физических баз данных. В системе одной базы данных име¬
ется много таких отдельных баз данных. Они могут составлять
одну структуру данных. На основании ее можно вывести мень¬
шую структуру данных
В некоторых корпорациях набор взаимосвязанных данных называют
банком данных. Например, этот термин иногда употребляется по отно¬
шению к группе взаимосвязанных физических баз данных в HMS. Но
обычно не принято пользоваться этим термином, так что мы будем упо¬
треблять термин структура данных. '
Структура данных может быть очень простой и очень сложной.
В первом случае она представлена одним типом элемента данных (по¬
лем). В другом — структурой взаимосвязанных баз данных, такой, как
на рис. 12.6. На рис. 12.6 представлена типичная для IMS сложная
структура базы данных.
170

Типичный пример хорошего использования баз данных представляет
завод, на котором находят применение 45 физических баз данных IMS.
Они сгруппированы в 17 структур данных. В 8 из 17 содержится более
одной физической базы данных, а в 9 — только одна физическая база
данных. В наиболее сложной структуре данных находится 10 взаимо¬
связанных физических баз данных, две из которых очень малы. Другие
типы программного обеспечения баз данных варьируются по сложности
в такой же степени. Например, если бы приведенный выше пример был
реализован с помощью баз данных КОДАСИЛ, он мог бы иметь множе¬
ство взаимосвязанных наборов, составляющих те же 17 структур данных.
Проектировщик должен решить, какие структуры следует сделать
базой данных, а какие — файлом. Решение зависит от многих факторов:
размера машин, изготовителя, отношения проектировщика к методам
баз данных, от его мнения о преимуществах и дополнительных расходах
на СУБД. В частности, оно будет связано с тем, какие файлы, базы
данных и прикладные программы уже существуют и должны включать¬
ся в проект.
Имеются различные практические ограничения выбора структуры
данных. Некоторые из них приводятся в вставке 12.1. Некоторые маши¬
ны, особенно периферийные, а также программное обеспечение на¬
кладывают ограничения на размер записей, размер файлов и на ис¬
пользование систем управления базами данных. На проект влияет так¬
же необходимость обеспечения адекватной сохранности, целостности
данных и процедур восстановления.
ГЕОГРАФИЧЕСКАЯ МАТРИЦА СТРУКТУРЫ ДАННЫХ
На шаге 6 составляется географическая матрица структуры данных,
являющаяся расширением рис. 12.5. Она может быть большой и зани¬
мать несколько страниц. Она может часто изменяться, и ее удобнее
вести с помощью ЭВМ. Хотя мы употребляем слово «географическая»,
отдельные структуры данных могут располагаться довольно близ¬
ко друг от друга, возможно, даже в одном здании.
Изучение практических ограничений размещения данных (шаг 7)
включает восстановление, надежность и рестарт, и оно может привести
к уточнению постулируемой матрицы физической структуры данных.
МАТРИЦА ПРОГРАММ/СТРУКТУР ДАННЫХ
Следующим шагом является изучение прикладных программ. В один
процесс может быть вовлечено множество транзакций, обрабатывать ко¬
торые будут разные прикладные программы. Проектировщик (шаг 8)
определяет, какие используются транзакции и какие для них требуются
прикладные программы.
вставка 12.1. Возможные ограничения выбора структуры данных
или размещения структур данных
•	Используемая ЭВМ не имеет системы управления базами данных.
•	Используемая система управления базами данных имеет ограничения в
отношении допускаемой структуры данных.
•	Данные уже структурированы для прежних приложений и их преобра¬
зование обойдется слишком дорого.
•	Емкость памяти у периферийной или небольшой ЭВМ . ограничена.
•	Периферийная ЭВМ имеет ограниченную емкость буферной памяти (на¬
пример, не может обращаться с записями длиной более 240 байт).
6*
171

•	У периферийной машины ограниченное число буферных запоминающих
устройств (например, только шесть буферов). Это значит, что приложения, ко¬
торые пользуются или, возможно, сравнивают данные из многих файлов, ста¬
нут неэффективными и сложными в смысле программирования.
•	Надежность размещения периферийной ЭВМ ограничена.
•	Надо планировать механизмы управления целостностью данных.
•	Во время отказа машины должно быть обеспечено восстановление.
•	Данные должны быть восстановимы в случае потери.
•	Процедуры рестарта должны проектироваться таким образом, чтобы об¬
новления данных не терялись и не обрабатывались дважды.
Затем можно построить матрицу, показывающую, какой структурой
данных пользуется каждая программа. Иногда она аналогична геогра¬
фической матрице структуры данных. Иногда она сильно от нее отличает¬
ся, потому что один процесс использует несколько транзакций и множе¬
ство программ, и некоторые программы могут размещаться не в том ге¬
ографическом узле, в котором находится обслуживаемый ими процесс.
При полностью централизованной телеобработке большинство приклад¬
ных программ географически удалены от узлов размещения конечных
пользователей, имеющих терминалы.
КЛАССЫ ПРОГРАММ
Чтобы исследовать эффект распределения приложений, разделим
прикладные программы на четыре класса, как показано на рис. 12.7.
Программы класса 0 находятся в том же месте, что и процессы, которые
они обслуживают, и данные, которыми они пользуются. Программы
класса 1 находятся в другом месте, а не там, где обслуживаемый про¬
цесс, но в том же самом месте, где помещаются все используемые ими
данные. Программы класса 2 находятся в том же месте, где процесс, но
некоторые или все данные помещаются в другом месте. В отдельных
случаях встречаются программы класса 3, которые удалены как от про¬
цесса, так и от некоторых данных. Они могут быть аналогичны про¬
граммам класса 2, отделенным от своего процесса, чтобы быть ближе к
своим данным, но не йсе данные находятся в одном и том же месте.
Узел приложений
Структура данных
Программа класса 0
На том же участке
На том же участке
Программа класса 1
На другом участке
Частично или целиком
на другом участке
Программа класса 2
На том же участке
Программа класса 3
На другом участке
Рис. 12.7. Четыре класса прикладных программ, составленные на основании распреде¬
ления
172

Самые желательные из этих программ — программы класса 0, а
класса 3 следует по возможности избегать. Класс 1 присущ централизо¬
ванным системам. Чтобы избежать взаимодействий между модулями,
матрицу географической структуры данных следует построить таким об¬
разом, чтобы число программ класса 0 было максимальным, чтобы про¬
граммы класса 3 отсутствовали, а программ класса 2 было как можно
меньше. .
ПРОЦЕССЫ
прикладные
ПРОГРАММЫ
Базы
данных
[2,43]
■[1.2,3] =
[ '.4.5,6]
[2,3. 7]
[2.8,9]
[’0. "]
[2, 7, 12,13]
[ 13. /4, /5, /6,17]
[18, /9. 20]
[21]—
[2.7.12,22]
[23]-
[2,7,12,24.25]
[25,26.27]
[2.25,26]
[2.7,12]
[27]
[28.29,30]
[2.731]
Рис. 12.8. Типичная большая система баз данных, обслуживающая мно¬
жество участков. Заштрихованным прямоугольником обозначена струк¬
тура, объединяющая множество наборов или физических баз данных,
по сложности аналогичных показанным на рис. 12.6. Как их следует
распределить?
[2,7,361
[2.37]'
[38.38]
[40. 41]
[42]
Проектировщик может составить таблицу, показывающую число про¬
грамм каждого класса. Программы, не принадлежащие' к классу О,
следует сделать программами класса 0 за счет передачи данных или
дублирования соответствующих структур данных.
173

Следующие показатели говорят в пользу дублирования данных:
•	большой объем транзакций,
•	небольшой объем данных,
•	редкое обновление данных,
•	простые обновления, так что легко избежать проблем, связанных
с целостностью и рестартом,
•	структура дублируемых данных простая (хотя она может извле¬
каться из сложной базы данных),
•	сложности с передачей данных (в менее развитых странах).
Проектировщик может рассчитать стоимость дублирования (стои¬
мость памяти) и стоимость недублирования (стоимость передачи). '
Проектировщика заботит не только количество программ, а также
частота их использования и объем движения в результате взаимодейст¬
вий. Он может обратить свое внимание на те программы, которые не
принадлежат к классу 0, и рассчитать средний объем связанного с ними
движения данных в день.
Изменение конфигурации структур данных может значительно со¬
кратить объем движения, особенно когда карта приложений усложнена.
РАЗДЕЛЕНИЕ СУЩЕСТВУЮЩЕЙ БАЗЫ ДАННЫХ
На многих предприятиях имеется большая централизованная база
данных, которая могла бы выиграть в результате распределения.
В этом случае существует вероятность, что документирование структур
данных будет хорошим. Группа проектирования может постулировать
перемещение некоторых структур данных и проанализировать резуль¬
таты.
Выходы программ-утилит СУБД дают программы, структуры
данных, типы транзакций и иногда объем транзакций. На основании
этого можно нарисовать карту прикладных программ нераспределенной
системы, а затем преобразовать ее в карту для распределенной системы.
На рис. 12.8 показана типичная по сложности система базы данных
предприятия, которая может стать кандидатом для распределения.
В результате такого анализа распределение в принципе нередко
представляется привлекательным. К сожалению, для его осуществления
часто требуются большие усилия, связанные с преобразованием и пере¬
программированием, поэтому руководители отделов ЭОД обычно от¬
казываются от него. В будущем технология распределения наберет си¬
лу, и было бы желательно, чтобы программное обеспечение баз данных
и периферийных ЭВМ облегчало бы это распределение, когда анализ
выявит целесообразность его осуществления.
Пока мы ждем лучшего программного обеспечения, следует поощ¬
рять попытки сегодняшних администраторов баз данных проектировать
свои структуры данных, имея в виду возможность будущего распреде¬
ления. Они могут анализировать и настраивать постулируемые распре¬
деленные структуры данных, как описано в этой главе, а затем остано¬
виться на такой версии структур, которая устраивает выбранную ими
СУБД.
174

РЕКОМЕНДУЕМЫЕ ПРОЦЕДУРЫ
СТРАТЕГИЧЕСКОГО ПЛАНИРОВАНИЯ
КОРОТКО О ПРОЦЕДУРЕ
Вставка 13.1 рекомендует процедуру для централизованного плани¬
рования данных. В ней отражен опыт работы с рядом методологий.
У каждой методологии есть свои положительные и отрицательные ас¬
пекты. В вставке 13.1 объединены положительные аспекты различных
методологий, помогающие добиться того, что, по мнению автора, явля¬
ется наилучшим результатом.
ДЕТАЛЬНЫЙ ПОДХОД
Настоятельно рекомендуется не приближенный, а более детальный
подход с анализом объектов или анализом объектов-действий. Он слу¬
жит целям создания индивидуальных детальных проектов, которые син¬
тезируют требуемые базы данных. Для такого детального подхода нуж¬
но компьютеризованное средство, которое должно быть совместимым со
средством моделирования, применяемым для синтеза баз данных.
Один язвительный практик однажды сказал автору: «Средство авто¬
матизации проектирования — громадное подспорье. Два средства авто¬
матизации проектирования — катастрофа!» Он имел в виду несовмести¬
мые средства, которые «не питают» друг друга и в основе которых мо¬
гут лежать разные подходы.
ОБНОВЛЯЕМЫЕ СХЕМЫ
Методология должна помогать получать схемы функций и действий
предприятия, а также данных, необходимых для их поддержки. Нужны
как суммарные, так и подробные схемы. Методология должна позволять
строить эти схемы постепенно. После их завершения они должны под¬
даваться обновлению с помощью ЭВМ.
Построение схем является итеративным процессом. На различных
стадиях этого процесса следует применять критерии проверки возмож¬
ности усовершенствования этих схем. Требуется ряд перекрестных про¬
верок. Эта операция будет считаться завершенной после того, как все пе¬
рекрестные проверки применены и пользователи и руководство на всех
уровнях выверили эти схемы.
175

Вставка 13.1. Рекомендуемая процедура стратегического централизованного
планирования систем данных
1.	• Получить поддержку со стороны высшего руководства.
2.	• Выбрать методологию для использования и подкрепить ее.
3.	• Определить функциональные области организации (предприятия).
•	Нарисовать схему корпораций, подразделений и функциональных обла¬
стей (глубины I и 2, см. рис. 2.4).
•	Рассмотреть их вместе с представителями руководства.
•	Определить объем анализа.
•	Подготовить график анализа и показатели.
•	Получить «добро».
4.	• Разработать примеры функций, действий и объектов.
•	Определить состав группы для проведения анализа (рекомендуются: два
сотрудника из отдела ЭОД, включая специалиста по базам данных, и два со¬
трудника из отдела пользователей, хорошо знакомых со всем предприятием).
Во главе этой группы должен стоять, полновластный руководитель — «велико¬
душный диктатор».
•	Связаться с руководителями функциональных областей.
•	Выбрать аналитиков среди пользователей.
•	Обучить аналитиков-пользователей.
5.	• Разбить каждую функциональную область на области процессов, ко¬
торые могут изучаться отдельными группами пользователей, добавив глубину 3
к схеме 2.4.
•	Дать определение каждой области процесса.
•	Рассмотреть области процессов вместе с аналитиками-пользователями.
•	«Подчистить» список процессов и еще раз выверить его вместе с аналити¬
ками-пользователями.
•	Построить матрицу, показывающую ответственных за каждую область
процесса (см. рис. 6.4).
6.	• Распределить области процессов среди различных аналитиков-пользо¬
вателей для анализа.
7.	• Разбить каждую область процесса на функции и действия.
•	Определить, какие объекты требуются для каждой области процесса.
•	Определить, какие объекты могут понадобиться предприятию в будущем.
•	Дать названия объектам.
•	Построить поэтапно карту объектов, такую, как на рис. 7.9, описываю¬
щую данные, которые необходимы для работы предприятия вне зависимости от
соображений, связанных с текущими процессами, действиями, структурой пред¬
приятия или географией.
•	Определить принадлежность каждой связи на рис. 7.9 к одной из пяти
категорий, описанных в вставке 7.1.
•	Использовать алгоритм, описанный в гл. 7, для подразделения карты
объектов на группы и супергруппы.
•	Изменить разбиение на супергруппы, если это необходимо для создания
соответствующих предметных баз данных (см. рис. 7.8 и 7.10).
•	Дать каждой супергруппе название.
8.	(Желательно).
•	Отобразить действия на объекты.
•	Использовать алгоритм анализа сходства для кластеризации объектов
на основании тех действий, которые они поддерживают (см. гл. 8).
•	Определить супергруппы объектов и сравнить их с теми супергруппами,
которые были разработаны по карте объектов.
•	Если необходимо, перестроить разбивку на супергруппы в карте объ¬
ектов.
9.	• Отобразить супергруппы на процессы, как на рис. 5.2.
•	Доработать это отображение, как на рис. 5.3—5.7.
•	Сформировать логические функциональные области из кластеров функ¬
ций, которые послужат основой для создания отдельных систем.
•	Определить системы рутинной обработки с большим объемом загрузки,
как на рис. 5.8.
•	Определить требования к информационной системе и системе поддержки
принятия решений, как на рис. 5.9 и 5.10.
10.	• Отобразить существующие системы ЭОД, как показано на рис. 6.6
и 6.7.
•	Определить, как планируемые системы баз данных соотносятся со ста¬
рыми системами.
•	Составить план преобразования и график (см. [1]).
176

•	Запланировать «мосты» между старыми системами и новыми (см.
[1, рис. 25.1]).
11.	• Наметить кандидатуры среди руководителей для проведения бесед.
•	Составить список вопросов для бесед.
•	Провести беседы с целью уточнения схе^ы предметных баз данных,
отображенных на процессы.
•	Определить, учтены ли настоящие и будущие потребности в информации
в той мере, какая возможна на этой стадии.
•	Определить проблемы, связанные с ЭОД и познакомиться с точкой
зрения руководителей. Схематизировать их так, как показано на рис. 6.9.
•	Проанализировать беседы, чтобы определить, нуждается ли архитектура
систем в изменении.
•	Проанализировать беседы с целью установления приоритета реализаций.
12.	• Составить схему участков размещения каждого процесса (см.
рис. 10.1).
•	Отобразить эти участки на предметные базы данных (см. рис. 10.2).
•	Рассмотреть аргументы «за» и «против» распределения, пользуясь схе¬
мой факторов (см. рис. 10.1, 10.2 и 10.3).
•	Использовать процедуру планирования распределения данных, представ¬
ленную на рис. 12.3.
•	Схематизировать предполагаемое распределение данных, показывая
шесть типов распределения (см. рис. 10.3).
13.	• Передать аналитикам-пользователям отчеты по предметным базам
данных, информационным системам и распределению.
•	Дополнить отчеты или схемы, если это необходимо.
•	Представить те же отчеты высшему руководству.
14.	• Установить приоритет реализаций.
•	Установить график и ответственность за реализацию.
•	Определить средства проектирования снизу вверх, согласующиеся со
средствами планирования сверху вниз.
15.	• Определить ответственных за постоянное обновление централизован¬
ных планов.
16.	• Подготовить и представить итоговый отчет.
АНАЛИТИКИ-ПОЛЬЗОВАТЕЛИ
Методология должна опираться на опыт аналитиков-пользователей,
которые понимают тонкости функционирования предприятия и его по¬
требности.
Особенно важно уделять внимание продуманному обучению аналити¬
ков-пользователей. Это обучение должно быть построено четко и до¬
ступно, с применением простых схем. Пользователям надо разъяснять,
почему применяется нормализация или другие методы. Их надо побу¬
дить к участию в анализе.
Получаемые схемы позволяют руководителям проанализировать ор¬
ганизационную структуру предприятия. Схему функций или процессов
можно отобразить на организационную схему. Такое сравнение может
показать, четко ли распределены по функциям ответственность и конт¬
роль со стороны руководства, имеет ли место избыточность или дублиро¬
вание и правильно ли распределены ответственность и контроль в геогра¬
фическом плане. Чтобы воспользоваться преимуществами технологии баз
данных и сетей, структуру предприятия можно с успехом изменить. Бу¬
мажные операции, как правило, нуждаются з уточнении и изменении в
целях повышения производительности труда как административных ра¬
ботников, так и специалистов в области ЭОД.
ГРАФИК
На рис. 13.1 приводится временной график анализа стратегического
планирования с применением процедуры, описанной в вставке 13.1.
Разделы, указанные в ней, представлены цифрами, обведенными круж¬
ками.
177

Анализ объектов в ряде случаев длился шесть месяцев. Для этого
нужно, чтобы в средних по размеру или крупных организациях на раз¬
ных участках одновременно работало много групп аналитиков-пользова¬
телей (см. разделы 5, 6 и 7 на рис. 13.1 и в вставке 13.1). Результаты
их работы координируются центральной группой, которая направляет
и контролирует всю деятельность целиком.
*1
ftoUCTUnurb
и анализу®—
Подготовка
и обучение
I
<ь
i
Распределить области Аналитики-пользобатели ^
процессов среди	^.работают о различных g
аналитиков Ф областях параллельна с
§
О
Разработать оунниис-
нальное разделение
и нарту объектов для
различных областей
3
£
I
I
Отобразить ТёЗстдйя
на объекты..
Анализ охобстба
В крупной организации
может занять больше
бремени
g
Ч-	I
оТооразить системы. &
Запланировать &
преобразование g
_ беседы с ‘руно'¬
® Водителями 1
5»
S
'51
!
5
Ю	15
Время (недели)
Анализл
распрям <3^ „^„„н
Произвести окончательны»
изменения. Установить приоритеты
Написать ТРПШШШльный отчет
I 1	1 I I 1-1	L_J
20
25
Рис. 13.1. График проведения стратегического планирования в средней
по размерам корпорации (цифры в кружках обозначают разделы из
вставки 13.1)
Чтобы работа аналитиков-пользователей шла параллельно, необ¬
ходимо их обучать. Достаточно трехдневного курса обучения, если оно
хорошо спланировано. Нужно организовать тщательный разбор приме¬
ров и давать хорошую мотивировку каждому предпринимаемому шагу.
Примерно через неделю полезно посвятить обучению еще один день.
Можно проверить при этом первые результаты работы аналитика за эту
неделю и ответить на его вопросы.
БЕСЕДЫ С ВЫСШИМ РУКОВОДСТВОМ
Беседы, проводимые с руководством методом BSP, полезны, но сами
по себе они не дают достаточной информации для составления хороше¬
го централизованного плана. На рис. 13.1 показано, что участие высше¬
го руководства существенно важно вначале — шаги 1 и 3.
Проведение подробных бесед методом BSP оставляют до того мо¬
мента, когда основная работа аналитиков-пользователей будет завер¬
ив

шена — шаг 11. Цель проведения таких бесед — верификация, анализ
текущих проблем, которые могут внести поправки в карту объектов, за¬
боты, связанные с определением приоритетов реализации систем, даль¬
нейшее развитие систем поддержки принятия решений и выяснение то¬
чек зрения на возможные изменения организации в будущем, которые
могут вызвать добавления или модификацию схемы.
Когда беседы с руководством проходят после завершения работы
аналитиков-пользователей, они проводятся с позиции силы. К этому
времени группа, проводившая анализ, знает организацию и ее пробле¬
мы и может искать более глубокий подход к делу. На этапах до шага
11 часто высказываются точки зрения по поводу перестройки ЭОД или
всей организации. Эти точки зрения можно обсудить с высшим руковод¬
ством. х
Хотя основные беседы с руководством проводятся на шаге 11, зна¬
чительная помощь от руководителей может быть получена раньше, на
этапе, когда аналитики-пользователи высказывают свои соображения.
На шагах 8—15 по мере получения дополнительной обратной свя¬
зи возможны модификация карт объектов, объединения в супергруппы
и изменения карты супергрупп-процессов.
НЕПРЕРЫВНОЕ ВЕДЕНИЕ ДАННЫХ
После завершения анализа его результаты необходимо непрерывно
обновлять, что обусловлено реализацией систем, большей концептуаль¬
ной ясностью, изменением технологии и развитием самой организации.
Необходимо, чтобы планировщик информационных ресурсов отвечал за
ведение плана и обеспечивал его использование отдельными реализа¬
циями, проводимыми снизу вверх.
По мере синтеза баз данных результаты необходимо сверять с пла¬
ном. Карта объектов, отражающая по мере возможностей будущие по¬
требности в информации, помогает создавать стабильные модели баз
данных. Она должна развиваться, чтобы учитывать первичные ключи
моделей данных. Таким образом централизованное планирование, от¬
раженное на карте объектов, будет связано с проектированием снизу
вверх, отраженным в канонической модели данных.
ИНТЕГРИРОВАННЫЙ НАБОР МЕТОДОЛОГИЙ
Планирование, рекомендуемое в этой главе, должно быть первым
этапом в применении интегрированного набора методологий построе¬
ния систем данных. Оно представлено на верхней части рис. 13.2. Следу¬
ющие этапы, приведенные на рис. 13.2, подробно обсуждаются в рабо¬
тах [1], [4].
Чем тщательнее выполнено проектирование на первых этапах, тем
удовлетворительнее будут выполняться следующие этапы. Можно будет
быстро проектировать процедуры, создавать в некоторых случаях при¬
ложения без программистов [4], извлекать данные из отдельных участ¬
ков для обеспечения ими руководства. Стоимость ведения данных будет
гораздо меньшей [6].
Когда стратегическое планирование данных и более детальное моде¬
лирование данных проводятся впервые, существует много систем, кото¬
рые не соответствуют моделям. Действительно, некоторые системы со¬
здаются до того, как завершается моделирование, из-за настоятельной
179

необходимости их ранней реализации. Такие системы требуют постепен¬
ной переделки. Большинство систем, построенных без основательного
Рис. 13.2. Методологии для управления информационными процессами
(схема, предложенная Джоном Хоупом)
проекта данных, нуждается в переделке примерно каждые восемь лет.
При переделке применяются модели данных, согласованные со словаря¬
ми-справочниками данных. Таким образом закладывается краеугольный
камень компьютеризованного предприятия.
180

ТОЛКОВЫЙ СЛОВАРЬ ТЕРМИНОВ
ПРИМЕЧАНИЕ А. ТИПЫ И ЭКЗЕМПЛЯРЫ
Слова, описывающие данные, могут относиться либо к типу данных, либо к эк¬
земпляру (или реализации). Так, у нас имеется:
Тип объекта
Тип атрибута
Тип элемента данных
Тип поля
Тип ассоциации
Тип связи
Тип записи
Экземпляр (или реализация) объекта
Экземпляр (или реализация) атрибута
Экземпляр (или реализация) элемента данных
Экземпляр (или реализация) поля
Экземпляр (или реализация) ассоциации
Экземпляр (или реализация) связи
Экземпляр (или реализация) записи
Тип ссылается на категорию представления данных, вне зависимости от времени
или значения. Экземпляр (или реализация) ссылается на конкретный пример этого
типа данных. Экземпляры заданного типа данных различаются по значениям. Чтобы
полностью описать какой-либо экземпляр, надо дать информацию, характеризующую
его тип и значения, которые определяют этот конкретный экземпляр.
Информационное табло в аэропорту предназначено для показа таких типов дан¬
ных, как номер рейса, пункт назначения, время вылета и место выхода на посадку.
Когда мы смотрим на табло, мы видим значения (экземпляры) этих типов данных.
Модель данных состоит исключительно из информации о типах. Логическое
проектирование базы данных представляет собой процесс нахождения и определения
типов объектов, атрибутов, записей, ассоциаций и т. д. Экземпляры создаются только
тогда, когда база данных работает (как и в случае с информационным табло).
О данных часто говорят небрежно, не уточняя, что подразумевается — тип или
экземпляр. Так, мы говорим «запись», «объект» или «атрибут».
«Запись» — это сокращенное обозначение, которое может подразумевать или
«тип записи», или «экземпляр записи». Она может обозначать запись служащих (тип)
или запись о Джоне Джонсе (экземпляр). Такое сокращение помогает избегать запу¬
танных описаний, но его не следует употреблять, если из контекста не ясно, относится
ли оно к типам или экземплярам данных.
ПРИМЕЧАНИЕ Б
Слова и словосочетания в словаре, выделенные полужирным шрифтом, определя¬
ются в другом месте в этом же словаре.
Автоматическая навигация (Automatic navigation). Возможность вместо поочеред¬
ной выборки записей применять операции реляционной алгебры высокого уровня, ко;
торые выполняются автоматически при использовании базы данных.
Агрегат данных, определение КОДАСИЛ (Data aggregate, CODASYL definition).
Поименованная совокупность элементов данных в записи. Агрегаты данных бывают
двух типов: векторы и повторяющиеся группы. Вектор — это одномерный, укороченный
набор элементов данных, имеющих идентичные характеристики. Повторяющаяся груп¬
па — это набор данных, который может повторяться в реализации произвольное число
раз. Этот набор может состоять из элементов данных, векторов и повторяющихся
групп.
Администратор базы данных (Data-base administrator).Должностное лицо (группа
лиц), имеющее полное представление об одной или более базах данных, контролирую¬
щий проектирование и использование этих баз данных. Лучше иметь в составе группы
администратора данных и проектировщика базы данных, который проектирует физиче¬
ские аспекты базы данных.
181

Администратор данных (Data administrator). Должностное лицо, имеющее полное
представление о данных в организации. Администратор данных отвечает за проектиро¬
вание модели данных и за достижение согласования в определениях данных, которые
даются в словаре данных.
Адрес (Address). Идентификация местоположения хранящихся данных (число,
имя, метка).
Адресация (Addressing). Способ размещения данных в памяти и последующей их
выборки с использованием ключа данных.
Алгоритм (Algorithm). Процедура вычисления.
Алгоритм LFU (LFU Algorithm). Алгоритм замещения, в котором новые запоми¬
наемые данные замещают наиболее редко используемые элементы данных.
Алгоритм LRU (LRU Algorithm). Алгоритм замещения, в котором новые запоми¬
наемые данные замещают наиболее давно использовавшиеся элементы данных.
Альтернативная дорожка (Alternate track). Дорожка, автоматически заменяющая
поврежденную дорожку на диске или другом запоминающем устройстве.
Ассемблирование (Assemble). Преобразование подпрограммы, закодированной в
отличном от машинного языке (языке символического кодирования) в команды реаль¬
ного машинного языка. Выполнение некоторых или всех следующих функций: 1) транс¬
ляция символических кодов операций в машинные коды; 2) распределение памяти
в объеме не меньшем, чем требуется для последовательности команд; 3) вычисление аб¬
солютных или перемещаемых адресов на основании символических; 4) включение биб¬
лиотечных подпрограмм; -5) генерация последовательностей символических команд пу¬
тем указания конкретных'параметров в макрокомандах.
Ассоциативная память (Associative storage (memory)). Память, в которой адреса¬
ция осуществляется на основе содержания, а не местоположения данных, что способст¬
вует быстрому поиску данных, имеющих определенное содержание. (В обычной памяти
адресация связана с физическим расположением данных.)
Ассоциация (Association). Отношение между двумя объектами, представленное
в модели данных. В модели данных ассоциация представлена в виде линии, соединяю¬
щей два прямоугольника, обозначающие объекты. Эта линия называется связью. Объект
А может ассоциироваться с объектом В двояко:
один к одному (А-^В);
один к многим (А	>-*В).
Обратная ассоциация объекта В с объектом А также бывает двоякая. Если может
быть так, что ни одно из значений объекта В не ассоциируется с объектом А, на линии
связи перед головкой стрелки рисуют нуль (А— @-*В)Мы говорим об ассоциациях меж¬
ду объектами, элементами данных, нормализованными записями и иногда ненормализо¬
ванными записями. «Ассоциация» — сокращение, обозначающее либо «тип ассоциации»,
либо «экземпляр ассоциации» (см. примечание А). Типу ассоциации может быть дано •
имя, указывающее на характер ассоциации, которую он определяет. Обычно этого не
делают, так как большинство ассоциаций не изменяет своего значения.
Атрибут (Attribute). Элемент данных, содержащий часть информации об объекте.
Записи состоят из атрибутов, относящихся к данному объекту. Термин атрибут является
сокращением, означающим или тип атрибута, или значение атрибута (см. примечание
А). Все атрибуты заданного типа имеют одинаковый формат, интерпретацию и диапазон
значений. Экземпляр записи имеет свое собственное (необязательно уникальное) зна¬
чение этого атрибута.
База данных (Data base). 1. Совокупность взаимосвязанных данных, используемых
одним или несколькими приложениями и хранящихся с (минимальной) регулируемой
избыточностью. Данные запоминаются таким образом, чтобы они не зависели от про¬
грамм. Для добавления новых данных, модификации и выборки существующих данных
применяется общий управляющий метод. О системе говорят, что она содержит набор баз
данных, если они не пересекаются по структуре. 2. Определение КОДАСИЛ: база дан¬
ных состоит из всех экземпляров записей, экземпляров наборов и областей, которые
контролируются конкретной схемой. Если ЭВМ имеет множество баз данных, то для
каждой из них должна быть своя схема. Кроме того, считается, что содержимое различ¬
ных баз данных не пересекается.
Банк данных (Data bank). Совокупность оперативно-доступных данных. Термин
база данных точнее термина банк данных. База данных подразумевает формальные
методы управления базами данных. Банк данных относится к любой совокупности дан¬
ных, будь они в форме файлов, баз данных или информационно-поисковых систем.
Библиотека (Library). 1. Помещение, в которой хранятся тома (ленты и пакеты
дисков). 2. Организованный набор программ, исходных операторов или объектных мо¬
дулей, который содержится в памяти прямого доступа, доступной для операционной
системы.
182

Буфер (Buffer). Область памяти, в которой данные хранятся временно, пока их
получают, передают, читают или записывают. Буфер часто используют для компенсиро¬
вания различных скоростей или для синхронизации устройств. Буферы применяют в тер¬
минальных и периферийных устройствах, устройствах памяти и в центральном процес¬
соре.
Ведение файла (Maintenance of a file). Периодическая реорганизация файла для
обеспечения лучшего размещения добавляемых или исключаемых элементов данных.
Виртуальная память (Virtual memory). Память, которая представляется програм¬
мам большей, чем она есть, благодаря тому, что данные или программа при необходимо¬
сти быстро перемещаются из вторичной памяти в основную или обратно.
Виртуальный (Virtual). Концептуальный или кажущийся, а не реально существую¬
щий. Прилагательное, которое обозначает, что данные, структуры или аппаратура пред¬
ставляются прикладному программисту или пользователю не такими, какие они есть на
самом деле, причем это преобразование осуществляется программным путем.
Виртуальный последовательный метод доступа (VSAM). Независимый от тома
индексно-последовательный метод доступа, разработанный ИБМ.
Внешняя схема (External Schema). Представление пользователя или программиста
о данных. Синоним подсхемы.
Внутренняя схема* (Internal schema). Физическая структура данных.
Возможный ключ (Candidate key). Ключ, который однозначно идентифицирует
экземпляры нормализованной записи заданного типа. Этот ключ должен обладать двумя
свойствами: 1) ключи каждого экземпляра записи должны иметь разные значения, что¬
бы по значению ключа можно было бы найти один экземпляр; 2) ни один атрибут из
ключа нельзя выбросить, не нарушив при этом первое свойство. На пузырьковой схеме
возможный ключ представлен в виде пузырька, от которого отходят одна или более
стрелок с одной головкой.
Время доступа (Access time). Время, прошедшее с момента выдачи команды обра¬
щения к данным, до момента, когда эти данные готовы для выполнения действия.
Время ожидания (Latency). Время, за которое участок на вращающейся поверх¬
ности достигает головки чтения / записи. Для общей синхронизации используется сред¬
нее время ожидания, т. е. время одного полуоборота поверхности.
Время установки (Seek time). Время, затрачиваемое на выполнение операции
установка.
Встроенные указатели (Embedded pointers). Указатели в записях данных, а не в
справочнике.
Вторичная память (Secondary storage). Устройства памяти, не образующие состав¬
ную часть ЭВМ, но связанные с ней и управляемые ею (например, диски, магнитные
ленты и т. д.).
Вторичный индекс (Secondary index). Индекс, состоящий из вторичных, а не пер¬
вичных ключей.
Вторичный ключ (Secondary key). Ключ, который идентифицирует экземпляр за¬
писи неоднозначно, т. е одно и то же значение ключа может иметься более чем у одно¬
го экземпляра записи. Ключ, который содержит значение атрибута (элемента данных),
отличное от того, что содержится в однозначном идентификаторе. Вторичные ключи при¬
меняются для поиска в файле или извлечения его подмножеств, например «все инже¬
неры» или «все служащие, живущие в Бостоне».
Выборка по нескольким ключам (Multiple-key retrieval). Выборка, требующая вы¬
полнения поиска данных по значениям нескольких ключевых полей (все или некоторые
из этих ключей являются вторичными).
Готовность (Availability). Мера надежности системы, показывающая интервал
времени, когда функция выполняется как намечено.
Время, в течение которого функция выполняется как намечено
Готовность = ——		— 	———
Общее время, в течение которого функция должна быть выполнена
Данные пересечения (Intersection data). Данные, которые ассоциируются с пересе¬
чением двух или более объектов или типов записей, но при ассоциации только с одним
из них они не имеют значения.
Двоичный поиск (Binary search). Метод поиска в упорядоченной таблице или
файле. В процедуре происходит выбор верхней или нижней половины ра’зделенного уча¬
* Внутренняя схема дает обобщенное представление о базе данных, применяется
при ее проектировании средствами СУБД. — Примеч. ред.	’
183

стка на основании определения его срединного значения. Выбранная часть затем анало-
гичным образом также делится пополам, и так далее до тех пор, пока не будет найден
искомый элемент.
Дата истечения срока хранения (Purge date). Дата, начиная с которой область па¬
мяти может быть доступна для перезаписи. Использование этой даты вместе с меткой
файла означает, что до истечения установленного срока хранения данные файла будут
защищены.
Действие (Action). То, что выполняется в результате одной команды программы
при обращении к базе данных. Простое действие — это команда, которая создает, чи¬
тает, обновляет или исключает экземпляр одной записи. Сложное действие — это
команда, которая затрагивает множество экземпляров записей, потому что она осуще¬
ствляет сортировку, поиск, объединение, проекцию или другие операции реляционной
алгебры.
Деятельность (Activity). Функция самого низкого уровня в функциональной схе¬
ме. Деятельность — логическое описание функций, осуществляемых организацией по¬
средством процедуры (которая может выполняться на ЭВМ).
Диалог (Dialogue). Общий термин для обозначения заранее планируемого взаимо¬
действия человека с машиной. Термин подразумевает использование формальных язы¬
ков, языков обращения к базам данных и бесчисленные неформальные диалоговые об¬
мены, многие из которых проектируются только для одного конкретного приложения.
Динамическое распределение памяти (Dynamic storage allocation). Выделение
объема памяти для процедуры на основании непосредственного или фактического за¬
проса памяти этой процедурой, а не на основании предварительного или прогнозируе¬
мого запроса.
Домен (Domain). Совокупность элементов данных (полей) одного и того же типа
в отношении (плоский файл).
Дорожка (Track). Круговая поверхность для хранения данных, описываемая го¬
ловкой чтения / записи на магнитном барабане, диске или другом вращающемся
устройстве.
Доступ (Access). Операция поиска, Чтения данных или записи их на запоминаю¬
щее устройство.
Древовидная структура (Tree structure). Иерархия групп данных, в которой:
1) на самом верхнем уровне имеется только одна группа, называемая корнем; 2) все
группы, за исключением корня, связаны с одной и только одной группой, расположен¬
ной на более высоком уровне. Простой файл «главный — детальный» представляет собой
двухуровневое дерево. Называется также иерархической структурой.
Древовидный индекс (Tree index). Индекс в виде древовидной структуры.
DL/1. Язык данных фирмы ИБМ для описания логических и физических структур
данных.
Записать '(Write). Записать информацию на устройство памяти.
Запись (Record). 1. Группа взаимосвязанных элементов данных, рассматриваемая
прикладной программой как одно целое. 2. Определение КОДАСИЛ: именуемый набор,
состоящий из нуля, одного или более элементов данных или агрегатов данных. В базе
данных может находиться произвольное число экземпляров каждого типа записи, опре¬
деленного в схеме для этой базы данных. Например, для каждого служащего будет
один экземпляр записи типа ЗАРАБОТНАЯ ПЛАТА-ЗАПИСЬ. Различие между факти¬
ческими экземплярами записи и типом записи немаловажное. 3. Терминология DL/1
ИБМ: запись логической базы данных состоит из поименованной иерархической струк¬
туры (дерева) связанных сегментов. Могут существовать один или более типов сегмен¬
тов различной длины и формата.
Запись-заголовок, или паспортная запись (Header record or header table). Запись,
содержащая общую, постоянную или идентифицирующую информацию для группы сле¬
дующих за ней записей.
Запись объекта (Entity record). Запись, содержащая атрибуты, относящиеся к дан¬
ному объекту.
Запоминающее устройство с прямым доступом (Direct-access storage device
(DASD)). Запоминающее устройство, допускающее прямое обращение к данным, кото¬
рое исключает необходимость в просмотре такого последовательного файла, как лента.
Диск является запоминающим устройством с прямым доступом.
ЗУПД (DASD). Запоминающее устройство прямого доступа.

Значение атрибута (Attribute value). Число, строка литер или другой элемент ин¬
формации, присвоенный данному атрибуту данного экземпляра записи в данное время.
Имя, формат, интерпретация и диапазон приемлемых значений атрибута определяются
его типом. В пределах этих ограничений значения атрибута могут изменяться во време¬
ни и от одного экземпляра записи к другому. Для обозначения значения атрибута мо¬
жет употребляться более короткий термин «атрибут», но только в тех случаях, когда
контекст позволяет отличить его от типа атрибута. Вместо значений атрибуты могут
иметь нули, которые означают следующее: 1) значение еще неизвестно (но это воз¬
можно); 2) значение неприменимо (тип объекта никогда не будет иметь значение для
данного атрибута).
Идентификатор объекта (Entity identifier). Ключ, который однозначно идентифи¬
цирует объект.
Иерархическая память (Storage hierarchy). Устройства памяти, образующие систе¬
му, в которой некоторые устройства характеризуются высоким быстродействием, но ма-
■ лой емкостью, а другие имеют большую емкость, но малое быстродействие. При необхо¬
димости блоки данных перемещаются с уровней, характеризующихся малым быстродей¬
ствием и большой емкостью, на уровни, имеющие высокое быстродействие, но малую
емкость.
Иерархический файл (Hierarchical file). Файл древовидной структуры, в котором
одни записи подчиняются другим. Устройства памяти, образующие в соединении под¬
систему памяти, в которой одни устройства быстрые, но небольшие, а другие большие,
ио медленные.
Изменчивый файл (Volatile file). Файл, характеризуемый высокой степенью добав¬
лений и удалений записей.
Индекс (Index). Таблица для определения местоположения записи.	.
Набор последовательных индексов (Sequence set index). Самый нижний уровень
в индексе, имеющем структуру дерева. Элементы на этом уровне расположены последо¬
вательно. Поиск и другие операции могут выполняться по индексу, построенному по
принципу следования; такие операции названы операциями, основанными на принципе
следования.
Индексная точка (Index point). Аппаратурная отметка на днеке или барабане, ис¬
пользуемая в целях синхронизации.
ISAM. Индексно-последовательный метод доступа.
Индексно-последовательная память (Index-sequential storage). Структура файла,
в котором записи расположены в порядке возрастания значений ключа. Индексы, пока¬
зывающие самое большое значение ключа в цилиндре, дорожке или участке памяти
и т. д., используются для избирательной выборки записей.
Индексные цепи (Index chains). Цепи внутри индекса.
Инвертированный файл (Inverted file). Файл, структура которого позволяет быст¬
ро отыскать заранее не специфицированную информацию. Для ключей записей, доступ
к которым осуществляется в соответствии со значениями определенных полей, ведутся
независимые списки или индексы.
Интеллектуальная модель данных (Intelligent data model). В обычной (неинтеллек¬
туальной) модели данных содержится описание нормализованных записей и ассоциаций.
Однако этим данным присущи свойства, относящиеся к разделенной логике, механизмам
контроля и ограничениям, которые мы закладываем в программы, пользующиеся обыч¬
ной (неинтеллектуальной) базой данных. Интеллектуальная модель данных представ¬
ляет разделенную логику, механизмы контроля и ограничения, которые следует приме¬
нять при обращении к данным независимо от конкретного приложения. Разделенная ло¬
гика, механизмы контроля и ограничения могут быть связаны с самими записями или
с ассоциациями внутри записей.
Интеллектуальная база данных (Intelligent data base). База данных, которая со¬
держит как логику связей данных, так и совместимые с логическим представлением
данные и которая автоматически вызывает эту логику при обращении к данным. Логика,
ограничения и механизмы контроля, связанные с использованием данных, представлены
в иителлектуальной модели данных.
185

Интерпретирующая программа (Interpretive routine). Программа, которая трансли¬
рует команды, написанные в псевдокоде, и тут же выполняет их, в отличие от компиля¬
тора, который транслирует псевдокод и генерирует программу на машинном языке, ко¬
торая выполняется позднее.
Информационная система (Information system). В отличие от системы оперативной
обработки информационная система обозначает систему, в которой использование хра¬
нимых данных довольно произвольно и заранее полностью не определено.
Канал (Channel), Подсистема ввода данных в ЭВМ и вывода из нее. Например,
данные из внешних запоминающих устройств передаются в ЭВМ через канал.
Каноническая модель (Canonical model). Модель данных, представляющая прису¬
щую им структуру и, следовательно, независимая от отдельных применений, а также
от механизмов программного и аппаратурного представления и применения данных.
Это минимальная неизбыточная модель конкретного набора элементов данных. В кано¬
нической модели отсутствуют избыточные элементы данных или избыточные ассоциа¬
ции. Каноническая модель должна правильно представлять все функциональные зависи¬
мости между элементами данных в модели. Когда это выполняется, в модели содер¬
жатся группировки элементов, заданных в третьей нормальной форме.
Канонический синтез (Canonical synthesis). Формальный процесс объединения от¬
дельных логических структур данных в каноническую модель. Рекомендуемый метод
проектирования логических баз данных, который можно автоматизировать.
Карта объектов (Entity chart). Схема, показывающая объекты или записи объек¬
тов и ассоциации между ними.
Каталог (Catalogue). Оглавление всех файлов, доступных для вычислительной
машины.
Ключ (Key). Элемент данных или комбинация элементов данных, используемые
для идентификации или определения местоположения экземпляра записи (или другой
группы данных).
Ключ поисковый (Search key). Синоним вторичного ключа.
Код Хаффмана (Huffman code). Код сжатия данных, в котором часто употребляе¬
мые символы кодируются меньшим числом битов, чем те, которые используются редко.
КОДАСИЛ (CODASYL). Ассоциация по языкам систем обработки данных. Орга¬
низация, разработавшая язык программирования Кобол. В настоящее время ею создан
ряд независимых от изготовителя и от приложения языков, служащих основой для уп¬
равления базами данных.
Кольцевая структура (Ring structure). Организация данных в виде цепочек, в ко¬
торых конец цепочки указывает на ее начало, образуя тем самым кольцо.
Компилятор (Compiler). Программа ЭВМ, которая помимо выполнения функций
ассемблера обладает следующими характеристиками: 1) она пользуется информацией об
общей логической структуре программы с целью повышения эффективности получаемой
машинной программы; 2) ее язык совпадает с реальным видом машинного языка, но
ориентирован на решение задач или представление их в виде операторов процедур;
3) для каждой символической команды обычно генерируется более одной машинной
команды.
Контрольная сумма (Hash total). Сумма значений определенного поля в файле,
получаемая в контрольных целях, чтобы ни один элемент не был потерян или непопра¬
вимо изменен. Сама по себе эта сумма значения не имеет.
Концептуальная модель (Conceptual model). Общая логическая структура базы
данных. В концептуальной модели часто содержатся типы данных, еще не реализован¬
ные в физических базах данных. Эта модель дает формальное представление о данных,
необходимых для управления организацией, несмотря на то, что в этой организации
только определенные системы согласуются с моделью. Некоторые организации термину
концептуальная модель предпочитают термин логическая модель, поскольку слово «кон¬
цептуальная» как бы означает, что модель может никогда не быть реализована.
Концептуальная схема (Conceptual schema). Этот термин означает то же самое,
что и концептуальная модель. Слово схема часто относится к логическому представле¬
нию данных, которым пользуется определенный класс систем управления базами дан¬
ных (например, КОДАСИЛ). Слово модель рекомендуется применять для не зависимых
от математического обеспечения структур данных, а схема—для структур, связанных
с конкретным классом программного обеспечения.
186

Корень (Root), Исходный узел древовидной структуры. Данные, находящиеся на
дереве, можно найти, начиная поиск с корня.
Кортеж (Tuple). Группа взаимосвязанных полей данных. N взаимосвязанных по¬
лей называются JV-кортежем.
Косвенная адресация (Indirect addressing). Любой метод спецификации или опре¬
деления местоположения ячейки памяти, в котором ключ (сам по себе или посредством
вычислений) не задает адреса. Например, нахождение адреса с помощью индексов.
Коэффициент активности (Activity ratio). Часть записей в файле или наборе дан¬
ных, которая вовлекается в деятельность (обновляется или проверяется) за определен¬
ный период времени или за время определенного прогона.
Коэффициент попаданий (Hit rate). Число записей в файле, обращение к которым
ожидается за время прогона. Выражается обычно в процентном отношении:
число входных транзакций Х100% .
число записей в файле
Логическая база данных (Logical data base). База данных в представлении поль¬
зователей; ее структура может отличаться от структуры физической базы данных.
В языке Data Language/1 ИБМ логическая база данных — это совокупность сегмен¬
тов, состоящая из одной или более физических баз данных, которая получена с помо¬
щью связующих указателей.
Логический (Logical). Прилагательное, описывающее организацию данных, аппа¬
ратуры или системы в представлении прикладной программы, программиста или поль¬
зователя; это представление может отличаться от реальной (физической) структуры.
Логический файл (Logical file). Файл в представлении прикладной программы; он
может иметь совершенно иную форму по сравнению с той, в которой он хранится на
запоминающем устройстве.
L-представление (L View). Представление пользователя. Синоним подсхемы.
Макрокоманда (Macroinstruction). Одна строка кода исходной программы, кото¬
рая генерирует процедуру, а не одну команду.
Машинно-независимый (Machine-independent). Прилагательное, обозначающее, что
процедура или программа задумана, организована или ориентирована безотносительно
к системе. При употреблении этого прилагательного обычно подразумевается, что про¬
цедура или программа ориентирована или организована с учетом логического характера
проблемы или обработки, а не с учетом характеристик машины, используемой для ее
решения.
Метаданные (Metadata). Данные о данных, т. е. информация о данных, которые
хранятся в словарях данных, моделях данных, схемах, и их машинное представление.
Метка (Label). Набор символов для идентификации или описания элемента дан¬
ных, записи, сообщения или файла. Иногда может совпадать с адресом в памяти.
Метод доступа (Access method). Метод организации обмена данными между вы¬
числительной машиной и ее периферийными устройствами: например, последовательный
доступ, прямой доступ, виртуальный последовательный метод доступа (VSAM), иерар¬
хический индексно-последовательный метод доступа (HISAM), доступ посредством вто¬
ричных индексов или такие реляционные виды доступа, как соединения, проекции или
другие операции реляционной алгебры.
Механизм доступа (Access mechanism). Механизм перемещения одной или более
головок чтения/записи в положение, при котором будут прочитаны или записаны не¬
которые данные.
Миграция (Migration). Часто используемые элементы данных пересылаются в те
области памяти, где их можно быстрее выбирать; редко используемые элементы данных
пересылаются в те области, где выборка осуществляется медленнее и где, возможно,
она дешевле.
Модель данных (Data model). Логическая структура данных, которая представляет
присущие этим данным свойства, не зависимые от программного и аппаратурного обеспе¬
чения или от соображений, связанных с работой машины. Эта модель показывает эле¬
менты данных, объединенные в записи третьей нормальной формы, и ассоциации между
187

этими записями.* Термину «модель» может быть противопоставлен термин «схема».
Схема также логически представляет данные, но она обычно связана с типом программ¬
ного представления, например КОДАСИЛ, иерархического или реляционного. Термин
«модель» рекомендуется применять для представлений данных, независимых от того,
какой класс программного обеспечения применяется для реализации. Программное обес¬
печение может меняться, но модель остается основным описанием данных.
Модуль (Module). Аппаратурный раздел памяти, содержащий один том, например
пакет дисков.
Мультисписковая организация (Multilist organization). Цепочная организация
файла, в которой цепи делятся на фрагменты, каждый из которых индексируется для
обеспечения более быстрого поиска.
Набор (определение КОДАСИЛ) (Set (CODASYL definition)). Набор — это по¬
именованная совокупность типов записей. Он задает характеристики произвольного
числа экземпляров набора. Каждый тип набора, определенный в схеме, должен иметь
один тип записи, описанный как его ВЛАДЕЛЕЦ, и один или более типов записей,
описанные как его ЧЛЕНЫ. Каждый экземпляр набора должен содержать один экземп¬
ляр записи-владельца и может содержать произвольное число экземпляров каждого
типа записей-членов.
Набор данных (Data set). Поименованная совокупность логически связанных эле¬
ментов данных, расположенных заданным образом, и описываемая управляющей инфор¬
мацией, к которой система программирования имеет доступ.
Набор сингулярный (Set,*singular). Набор КОДАСИЛ, не имеющий владельца;
владельцем объявляется «СИСТЕМА». Сингулярный набор используется для организа¬
ции простых неиерархических файлов, таких, как файл записей заказчиков.
Независимость данных логическая (Data independence, logical). Возможность изме¬
нения общей логической структуры базы данных (схемы) без изменения представления
прикладной программы о данных.
Независимость данных физическая (Data independence, physical). Возможность из¬
менения физической структуры данных без изменения логической структуры.
Независимость от устройства (Independence, device). Свойства организации дан¬
ных быть независимой от устройства размещения данных.
Непервичный атрибут (Nonprime attribute). Атрибут, который не является частью
первичного ключа нормализованной записи. Атрибуты, являющиеся частью первичного
ключа, называются первичными атрибутами.
Нормализация (Normalization). Разложение сложных структур данных на более
простые и устойчивые структуры данных в соответствии с набором правил зависимости.
Третья нормальная форма обычно достаточна, чтобы структура данных была устойчи¬
вой.
Нормализованная запись (Normalized record). Множество атрибутов, представляю¬
щих некоторые или все характеристики какого-либо объекта или пересечения объектов
Один объект представляется одной или более записями в третьей нормальной форме,
а пересечение двух или более объектов (если у этого пересечения имеются непервичные
атрибуты) представляется одной нормализованной записью. Каждая нормализованная
запись имеет первичный ключ. «Запись» может служить кратким обозначением «норма¬
лизованной записи» в контекстах, где невозможно спутать это употребление с другим
употреблением «записи» (например, логические или физические записи в IMS). Более
того, термин «нормализованная запись» кратко обозначает либо тип нормализованной
записи, либо экземпляр нормализованной записи.
Нормальная форма первая (Normal form, first). Данные в виде плоского файла,
без каких-либо повторяющихся групп.
Нормальная форма вторая (Normal form, second). Отношение R задано во второй
нормальной форме, если оно находится в первой нормальной форме и каждый непер¬
вичный атрибут R полностью функционально зависит от любого возможного ключа R
(определение Е. Ф. Кодда).
Нормальная форма третья (Normal form, third). Отношение R задано в третьей
нормально* форме, если оно находится во второй нормальной форме и каждый непер¬
вичный атрибут R нетранзитивно зависит от любого возможного ключа R (определение
Е. Ф. Кодда). Запись, сегмент или кортеж, который нормализован (т. е. не содержит
повторяющихся групп) и в котором каждый непервнчный элемент данных находится
188

в нетранзитивной и полной функциональной зависимости от любого возможного ключа.
Иными словами, для идентификации каждого элемента данных в кортеже требуется
весь первичный ключ или возможный ключ и ни один элемент данных не идентифици¬
руется таким элементом данных, который не находится в первичном ключе или воз¬
можном ключе.
Область (КО ДАС ИЛ) (Area (CODASYL)). Поименованная часть адресуемого
объема памяти в базе данных, в котором могут содержаться экземпляры записи и набо¬
ров или части наборов различных типов. Области могут открываться процессом с режи¬
мом использования, который позволяет или не позволяет параллельным процессам
открывать ту же область. Область может быть объявлена в схеме как временная, что
позволяет выделять каждому процессу, открывающему эту область, разные экземпляры
временной области. По завершении процесса этот участок памяти снова становится
доступным для использования.
Объект (Entity). Человек, место, вещь или концепция, которые обладают пред¬
ставляющими интерес характеристиками. Объект — это то, о чем мы храним данные.
Примеры объектов: ЗАКАЗЧИК, ДЕТАЛЬ, СЛУЖАЩИЙ, СЧЕТ-ФАКТУРА, СТАНОК,
ПРОДАВЕЦ, ОТДЕЛЕНИЕ, СКЛАД, СКЛАДСКОЙ БУНКЕР, ЗАКАЗ, ПРОДУКТ,
СПЕЦИФИКАЦИЯ ПРОДУКТА, СЧЕТ В ГРОССБУХЕ, ПЛАТА, ЗАДОЛЖНИК,
ЗАПИСЬ АНАЛИЗА ЗАДОЛЖЕННОСТИ. Объект обладает различными атрибутами,
которые надо записать: ЦВЕТ, РАЗМЕР, ДЕНЕЖНАЯ СТОИМОСТЬ, ПРОЦЕНТНАЯ
УТИЛИЗАЦИЯ и ИМЯ. Для каждого типа объекта существует не менее одного типа
записи. Иногда для хранения данных об одном типе объекта используется несколько
типов записей (по причине нормализации). Тип объекта имеет один тип элементов дан¬
ных или группу типов элементов данных, которые однозначно идентифицируют его.
Объект — это сокращение, обозначающее тип объекта или экземпляр объекта (см. при¬
мечание А).
Объединение в блоки (Blocking). Объединение двух или более физических запи¬
сей, обеспечивающее их чтение или запись с помощью одной машинной команды.
Оглавление тома (Volume table of contents (VTOC)). Ассоциированная с томом
таблица, описывающая каждый файл или набор данных, находящийся в этом томе.
Оперативно-доступная память (On-line storage). Запоминающие устройства, в ча¬
стности носители памяти, содержащиеся в них, которые непосредственно управляются
вычислительной системой, а не работают в автономном режиме или не находятся в биб¬
лиотеке томов.
Операционная система (Operating system). Программное обеспечение, которое по¬
зволяет ЭВМ контролировать свои собственные операции, автоматически вызывая прог¬
раммы, подпрограммы, компиляторы или данные, когда они требуются для непрерывной
обработки различного типа заданий.
Описание логической базы данных (Logical data-base description).Схема. Описание
структуры всей базы данных в том виде, в каком она представляется пользователям.
Используется в системах управления базами данных.
Описательные данные (Indicative data). Идентифицирующие или описывающие
данные, например в файле запасов — номер изделия, описание, размер партии. Во вре¬
мя обработки описательные данные обычно не изменяются регулярно и часто (как,
например, бухгалтерский баланс).
Отношение (Relation). Плоский файл. Двумерный массив элементов данных. Файл
в нормализованном виде.
Отношение ассоциации или запись ассоциации (Association relation or association
record). Отношение или запись, содержащие информацию об ассоциации. Иногда в па¬
мять помещают имя ассоциации. Наиболее совершенные формы модели данных (на¬
пример, интеллектуальная модель данных) хранят информацию о значении ассоциации
или правилах, которые применяются при использовании ассоциации.
Отношение связи или запись связи (Link relation or Link record). Отношение или
запись, содержащие информацию о связи. См. отношение ассоциации. ,
Отображение (Mapping). Определение способа ассоциации записей друг с другом.
Память с последовательным доступом (Serial-access storage). Память, в которой
записи должны читаться последовательно одна за другой (например, магнитная лента).
189

Память с произвольным доступом (Random-access storage). Память, в которой
время, необходимое для получения информации, не зависит от расположения считанной
перед этим информации. К этому строгому определению следует добавить, что понятие
«произвольный» обычно имеет относительный смысл. Так, доступ к памяти на магнитном
барабане не является произвольным по сравнению с доступом к основной памяти на
магнитных сердечниках, но будет относительно произвольным по сравнению с доступом
к файлам, хранящимся на магнитных лентах. (
Параллельная организация данных (Parallel data organization). Организация дан¬
ных, позволяющая производить поиск, чтение или запись данных множеству механизмов
доступа одновременно.
Перемещение (Staging). Блоки данных перемещаются с одного устройства памяти
на другое с более быстрым временем выборки до того, как они требуются, или во время
возникновения необходимости в них.
Перемещение по требованию (Demand staging). Блоки данных перемещаются с од¬
ного запоминающего устройства на другое, имеющее меньшее время доступа (возмож¬
но, и в основную память). Перемещение выполняется по требованию программ, если
в быстродействующей памяти эти блоки отсутствуют. Ср. с упреждающим перемеще*
ннем.
Перемещение упреждающее (Anticipatory staging). Блоки данных перемещаются
с одного запоминающего устройства на другое, имеющее меньшее время доступа, зара¬
нее до запроса их программами. Ср. с перемещением по требованию, при котором блоки
данных перемещаются тогда, когда их запрашивают программы.
Переполнение (Overflow). Условие, при котором запись (или сегмент) не может
размещаться по своему собственному адресу, т. е. адресу памяти, который был логи¬
чески выделен ей при загрузке. Она может храниться в специальной области перепол¬
нения или по собственному адресу других записей.
Пересечение объектов (Intersection of entities). Некоторые характеристики, пред»
ставленные в атрибутах, принадлежат не отдельным экземплярам объекта, а специфи¬
ческим комбинациям двух или более экземпляров объекта. В таких случаях требуется
отдельная группа данных, называемая данными пересечения, Пересечение представлено
в логической модели данных типом нормализованной записи, первичный ключ которой
является конкатенацией ключей, идентифицирующих затрагиваемые объекты, а другие
атрибуты которой представляют характеристики, принадлежащие их взаимодействию.
Обычно пересечение относится к объектам разных типов (например, ПОСТАВЩИК и
ДЕТАЛЬ). Реже оно относится к объектам одного типа (например, БЛОК и БЛОК,
когда продукт или блок содержит много других блоков).
Первичный атрибут (Prime attribute). Атрибут, который составляет весь первич¬
ный ключ записи или его часть. Другие атрибуты называются непервичными.
Первичный ключ (Primary key). Ключ, который используется для однозначной
идентификации экземпляра записи (или другой группы данных).
Плоский файл (Flat file). Двумерный массив элементов данных.
Подмодель (Submodel). Представление пользователя или программиста о данных.
Подсхема (Subschema). Синоним внешней схемы.
Поиск (Search). Просмотр последовательности элементов с целью нахождения эле¬
мента, имеющего нужное свойство или свойства.
Поле (Field). См. элемент данных.
Порядковая обработка (Sequential processing). Выборка записей в возрастающей
последовательности по ключу; следующая выбираемая запись будет иметь следующий
по значению (более высокий) ключ независимо от ее физического размещения в файле.
Последовательная обработка (Serial processing). Выборка записей в их физиче¬
ской последовательности. Следующей выбираемой записью будет запись, расположен¬
ная в следующей физической позиции/ячейке поля.
Прогрессирующее переполнение (Progressive overflow). Метод размещения запи¬
сей переполнения в файл с произвольной организацией, не требующей применения ука¬
зателей. Запись переполнения размещается на ближайшем свободном месте и выби¬
рается посредством прямого последовательного поиска, начинающегося с адреса основ¬
ной записи.
190

Прозрачные данные (Transparent data). Сложность структуры данных скрывается
от программистов или пользователей (делается прозрачной для них) с помощью про¬
граммного обеспечения.
Произвольный доступ (Random access). Получение данных непосредственно из
любой ячейки памяти независимо от ее позиции относительно ранее выбранной инфор¬
мации. Называется также прямым доступом.
Прямой доступ (Direct access). Выборка или размещение данных в памяти посред¬
ством ссылки на их расположение в томе, а не путем соотнесения их с ранее выбран¬
ными или записанными в память данными. Механизм доступа непосредственно направ¬
ляется к нужным данным, что обычно требуется при оперативном использовании
данных.
Рабочая память (Working storage). Часть памяти, обычно основной памяти ЭВМ,
резервируемая для размещения временных результатов операций.
Разбиение секции (Cellular splitting). Метод обращения с записями, доставляе¬
мыми в файл. Записи организуются в секцию, а секция при заполнении разбивается на
две.
Раздел данных (Кобол) (Data division (COBOL)). Раздел программы на Коболе,
который состоит из статей, используемых для определения типов и характеристик дан¬
ных, предназначенных для обработки объектной программой.
Рандомизация (Randomization). Устаревшее слово для обозначения хеширования.
Распределенное свободное пространство (Distributed free space). Незаполненные
промежутки в расположении данных, позволяющие включать туда новые данные.
Реальное время (Real time). 1. Время, соотносящееся с фактическим временем
протекания физического процесса. 2. Применительно к режиму обработки данных озна¬
чает, что выполнение вычислений происходит во время фактического протекания физи¬
ческого процесса, так что результаты вычислений могут быть использованы для управ¬
ления этим процессом. 3. Применительно к приложениям означает, что ответ на вход¬
ной сигнал дается довольно скоро, так что он может влиять на последующий входной
сигнал, например при ведении диалога с терминалов в оперативных системах.
Реляционная алгебра (Relational algebra). Язык, включающий ряд операторов
для манипулирования отношениями, например ПРОЕКЦИЯ, СОЕДИНЕНИЕ и ПОИСК.
Реляционная база данных (Relational data base). База данных, состоящая из от¬
ношений (определенных выше), система управления которой обладает способностью
перестраивать элементы данных с целью образования различных отношений, обеспечи¬
вая тем самым большую гибкость в использовании данных. Если система управления
базой данных не обеспечивает функции реляционной алгебры или эквивалентные функ¬
ции, термин реляционная база данных лучше не употреблять.
Исчисление отношений (Relational calculus). Язык для описания результатов, ко¬
торые пользователь желает получить от реляционной базы данных.
Рестарт с контрольной точки (Checkpoint/restart). Возобновление выполнения
программы после отказа или прерывания не с начала, а с какой-либо точки. Контроль¬
ные точки могут размещаться по всей прикладной программе через определенные ин¬
тервалы. В этих точках помещаются записи, обеспечивающие информацией о состоянии
программы, достаточной для возобновления выполнения программы с этой точки.
Связь (Link). Ассоциация или отношение между объектами или записями (см.
ассоциация). Связь в схеме объектов или в модели данных вычерчивается как линия,
соединяющая объекты или записи. Слово связь нагляднее, чем ассоциация или отноше¬
ние, и поэтому оно иногда предпочтительнее. В некоторых случаях слово связь отно¬
сится к отношению связи или записи связи. Следует различать типы связи и экземпляры
связи (см. примечание А). Это важно, когда экземпляры атрибута, ассоциируемые со
связью, могут изменяться, что возможно в интеллектуальной базе данных.
Сегмент (Segment). Именуемая часть данных фиксированного формата, содержа¬
щая один'или более элементов данных. Сегмент представляет собой базисную часть
данных, передаваемую прикладным программам и получаемую от них, при использова¬
нии языка Data Language/l ИБМ (определение фирмы ИБМ). .
Сектор (Sector). Наименьшая адресуемая часть памяти в некоторых дисковых и
барабанных устройствах памяти.
Секционные цепи (Cellular chains). Цепи, которые не могут выходить за пределы
секции.

Секционный мультисписок (Cellular multilist). Такая форма мультисписковой ор¬
ганизации, в которой цепи не могут выходить за пределы секции.
Секция (Cell). Смежные участки памяти, которые при адресации или в схеме
поиска в файле имеют одно групповое название. Секция может не выходит^ за механи¬
ческие границы запоминающего устройства, например, секцией может служить дорожка
или цилиндр.
Сетевая структура (Plex structure/Network structure). Отношение между записями
(или другими группами данных), в котором для порожденной записи может существо¬
вать более одной исходной записи.
Сжатие ключа (Key compression). Способ уменьшения числа битов в ключах;
используется для экономии памяти, занимаемой индексами.
Система оперативного доступа (On-line). Система, в которой входные данные по¬
ступают в ЭВМ непосредственно с места их возникновения и (или) в которой выходные
данные передаются непосредственно туда, где они используются. При этом исключа¬
ются такие промежуточные этапы, как перфорирование данных, запись на ленту, за¬
грузка дисков или автономная печать.
Система управления базами данных (Data-base management system). Совокупность
программного обеспечения, необходимого для пользования базой данных и представля¬
ющего пользователям и программистам множество различных представлений данных.
Скорость обмена данных (Transfer rate) .Скорость передачи данных между устрой¬
ством памяти прямого доступа и центральным процессором (выражается обычно в ты¬
сячах символов в секунду или тысячах байтов в секунду).
Словарь данных (Data dictionary). Каталог всех типов данных, содержащий их
имена и структуры, а также информацию об использовании данных. В усовершенство¬
ванных словарях данных имеется справочная функция, поддерживающая перекрестные
ссылки между компонентами данных.
Собственный адрес (Home address). 1. Адрес физической ячейки памяти (напри¬
мер, участок), куда логически размещается запись данных (в отличие от адреса пере¬
полнения). 2. Поле,'содержащее физический адрес дорожки, который записывается
в начале дорожки.
Сортировка (Sort). Упорядочение файла по заданному ключу.
Список (List). Упорядоченный набор элементов данных. Цепь.
Справочник (Directory). Таблица, показывающая отношения между элементами
данных. Иногда это таблица (индекс), указывающая адреса данных.
Страничная организация (Paging). Метод организации памяти в виртуальных си¬
стемах, создающий представление о наличии большей памяти, чем она реально сущест¬
вует, за счет передачи по требованию блоков (страниц) данных или программ в эту
память из внешней памяти.
Страничное прерывание (Page fault). Прерывание программы, когда страница,
к которой делается обращение, отсутствует в основной памяти и должна быть считана
в нее.
Схема (Schema). 1. Карта всей логической структуры базы данных, (ср. с моделью
данных). 2. Определение КОДАСИЛ: схема состоит из статей на ЯОД и является пол¬
ным описанием всех областей экземпляров наборов, записей и соответствующих элемен¬
тов данных и агрегатов данных в том виде, в каком они существуют в базе данных.
Схема действий (Action diagram). Схематический метод представления использо¬
вания базы данных программами, спецификации ими действий и контролирования соот¬
ветствующей структуры. В хорошем проекте схема действий соотносится с моделью
данных, в которой все записи нормализованы.
Сцеплять (Concatenate). Сцепленный набор данных представляет собой совокуп¬
ность логически связанных наборов данных, сцепленный ключ состоит из нескольких
полей.
Таблица (Table). Совокупность данных, в которой можно быстро отыскать нуж¬
ный элемент, так как каждый элемент в ней однозначно идентифицируется или с помо¬
щью метки, или его относительным положением.
192

Терабитовая память (Terabit storage). Память, которая может содержать 1012 би¬
тов данных.
Тип (Туре). См. примечание А.
Том (Volume). Сменные магнитные ленты, диски и кассеты называются томами.
Этот термин применим также к несменным дискам или другим носителям памяти. Том
определяется как часть единого устройства носителя памяти, которая доступна одному
механизму чтения записи. Существуют, однако, некоторые устройства, в которых том
выбирается с помощью двух или более механизмов чтения/записи.
Транзакция (Transaction). Входная запись, относящаяся к существующему файлу.
Входная запись описывает некоторое «событие», которое вызовет генерацию нового
файла, изменение записи или удаление существующей.
Указатель (Pointer). Адрес записи (нли других групп данных), содержащийся в
другой записи, чтобы программа могла обратиться к первой записи, после того как вы¬
берет вторую запись. Адрес может быть абсолютным, относительным или символиче¬
ским, и соответственно указатель может называться абсолютным, относительным или
символическим.
Уплотнение (Compaction). Метод сокращения количества битов в данных без раз¬
рушения их информационного содержания.
Управление данными (Data management). Собирательный термин для описания
функций системы, которая обеспечивает создание и доступ к хранимым данным, соблю¬
дение соглашений о хранимых данных и регулирует использование устройств ввода-
вывода.
Установка (Seek). Установка в заданное положение механизма доступа в устрой¬
стве памяти прямого доступа.
Участок (Bucket). Область памяти, которая может содержать более одной физиче¬
ской записи и адресуется как единое целое при определенных методах адресации.
Файл (File). Множество аналогично построенных записей.
Физическая запись (Physical record). Совокупность битов, которые физически хра¬
нятся на носителе памяти и которые читаются или записываются с помощью одной
машинной команды ввода-вывода.
Физическая база данных (Physical data base). База данных в том виде, в каком
она хранится на носителях памяти, включая указатели или другие средства связей. Из
одной или более физических баз данных можно получить множество логических баз
данных.
Физический (Physical). Прилагательное, которое в отличие от логического отно¬
сится к форме, в которой данные или системы реально существуют. Программное обес¬
печение часто преобразует данные из той формы, в которой они физически хранятся,
в форму, в которой их воспринимает пользователь или программист.
Функциональная зависимость (Functional dependence). Атрибут В отношения R
функционально зависит от атрибута А1 в R, если в отношении R в любой момент вре¬
мени с каждым значением А ассоциируется не более одного значения В (эквивалентно
тому, если мы скажем, что А идентифицирует В). Говорят, что атрибут или совокуп¬
ность атрибутов В отношения R находится в полной функциональной зависимости от
другой совокупности атрибутов А в отношении R, если В функционально зависит от
целого А, а не от какого-либо подмножества А.
Функциональная схема (Function chart). Схема, показывающая логические опера¬
ции, выполняемые в организации. Эти операции обычно выстраивают в иерархическом
порядке. Функция, находящаяся на самом низком уровне этой иерархии, называется
деятельностью и служит основой для проектирования физических процедур.
Функциональное разложение (Functionaldecomposition). Разложение операций ор¬
ганизации по принципу иерархии функций, которые представлены в функциональной
схеме.
Хеширование (Hashing). Метод прямого доступа, когда ключ преобразуется в
псевдослучайное число, на основе которого получают требуемый адрес.
Цепь (Chain). Организация данных, в которой записи или другие элементы дан¬
ных связываются друг с другом при помощи указателей.
Цепь, просматриваемая с пропусками (Skip-searched chain). Цепь, имеющая указа¬
тели, которые позволяют производить поиск в ней с пропусками, просматривая не каж¬
дое звено в цепи.
193

Цилиндр (Cylinder). Область памяти, записи в которой можно читать без измене¬
ния позиций механизма доступа. Возникновение этого термина связано с дисковыми
файлами, где цилиндр представлял собой совокупность дорожек, по одной на каждой
поверхности диска, так что головки чтения/записи одновременно располагались над
всеми этими дорожками.
Циркулярный файл (Circular file). Организация файла с высокой степенью изме¬
нений, при которой новые добавляемые записи помещаются на место наиболее старых
записей.
Чувствительность (Sensitivity). Программист может использовать только опреде¬
ленную часть данных в логической базе данных. Считается, что его программа чувстви¬
тельна к этим данным.
Эвристический (Heuristic). Метод получения решений задач,относящийся к мето¬
дам проб и ошибок.
Экземпляр (Instance). См. примечание А.
Экстент (Extent). Непрерывная область в пространстве хранимых данных.
Элемент данных (Data item). Наименьшая единица данных, имеющая смысл при
описании информации; наименьшая поименованная единица данных. Синоним поля.
Энергозависимая память (Volatile storage). Память, содержимое которой теряется
при выключении питания. Твердотельная память (БИС) является энергозависимой,
а магнитная память —нет.
Язык манипулирования данными (Data manipulation language). Язык, которым
пользуется программист для организации обмена данными между программой и базой
данных. Это не полный язык, он опирается на включающий язык программирования,
который обеспечивает ему процедурные возможности для манипулирования данными.
Язык описания данных (Data description language). Язык для описания данных
(в некоторых видах программного обеспечения — для описания логических, но не фи¬
зических данных; в других — для того и другого).
Язык описания схемы (Schema language). Язык описания логической базы данных.
Язык управления размещением на внешних носителях (Device/media control
language). Язык для спецификации физического размещения и организации данных.

ЛИТЕРАТУРА
1.	Martin J. Managing the Data-Base Environment. 2 vols., Technical Report № 11,
Savant Institute, 2 New Street, Carnforth, Lancashire, England, 1980.
2.	Business Systems Planning. Information Systems Planning Guide. 2nd ed., IBM
Corp., White Plains, N. Y., 1978.
3.	Например, Data Designer. Database Design Inc., Ann Arbor, Mich.
4.	Martin J. Application Development without Programmers. Prentice-Hall, Inc.
Englewood Cliffs, N. Y., 1981.
5.	Martin J. and Finkelstein C. Information Engineering, a report in two
volumes from the Savant Institute. 2 New Street, Carnforth, Lancashire, England,
1982.
6.	Martin J. and McClure C. Maintenance of Computer Software, a report from
the Savant Institute. 2 New Street, Carnforth, Lancashire, England, 1982.
7.	Drucker P. Management. Harper & Row, Publishers, N. Y„ 1964.
8.	Rock art J. F. A New Approach to Defining the Chief Executive's Information
Needs. Center for Information Systems Research, Alfred P. Sloan School of Manage¬
ment, M. I. T., Report CISR N 37, WP N 1008—78.
9.	Rude J. Interview with William Dougherty, President, North Carolina National
Bank Corporation, M. I. S. Quarterly, vol. I, № 1, March 1977.
10.	Daniel J. R. Management Information Crisis. Harvard Business Review, Sept.—
Oct. 1961.
II.	Williams B. D. IBM Corp. An experiment in business information systems. Paper
presented at the Guide and Share Applications Development Symposium, Monterey,
Calif., 1979. Share Inc. and Guide International Corp., N. Y., 1979.	'
12.	Miller G. A. The magical number seven, plus or minus two: Some limits to our
capacity for processing information. Psychological Review, vol. 63, p. 81—97, 1956.
13.	Working Paper by Ken Winter and Rik Belew, Database Design Inc., Ann
Arbor, Mich., 1981.
14.	Martin J. Privacy, Accuracy and Security in Computer Systems, Prentice-Hall,
Inc., Englewood Cliffs, N. J„ 1974.
15.	Martin J. Viewdata and the Information Society. Prentice-Hall, Inc., Englewood
Cliffs, N. J., 1982.
16.	Rockart J. F., Bullen С. V. and LevantorJ. L. Centralization vs. Decent¬
ralization of Information Systems: A Preliminary Model for Decision School of Ma¬
nagement, M. I. T., Cambridge, Mass., 1976.
i<W

ОГЛАВЛЕНИЕ
Предисловие	к	русскому	изданию .	5
Предисловие		 8
Глава	1.	Необходимость участия руководителей предприятий	в	планировании	9
Глава	2.	Разработка модели предприятия (организации)	25
Глава	3.	Организация централизованного планирования	39
Глава	4.	Предметные базы данных	47
Глава	5.	Объединение предметных баз данных в системы	60
Глава	6.	Система организационного планирования (методика	ИБМ)	...	75
Глава	7.	Анализ объектов на предприятии	91
Глава	8.	Анализ объектов-действий	 44
Глава	9.	Реорганизация предприятия	123
Глава	10.	Планирование распределения данных	131
Глава	11.	Распределение данных: качественный анализ	.147
Глава	12.	Распределение данных: количественный анализ	162
Глава	13. Рекомендуемые процедуры стратегического планирования	.	.175
Толковый словарь	терминов 	 181
Литература		194
196

Дж. Мартин
М29 Планирование развития автоматизированных систем / Пер. с
англ.; Предисл. В. М. Савинкова. — М.: Финансы и статисти¬
ка, 1984. — 196 с., ил.
В nep.: 1 р. 30 к. 12 000 экз.
В книге известного американского ученого с современных позиций рассматри¬
вается содержание процесса перспективного планирования создания и развития
автоматизированных систем. Обосновывается необходимость организации информа¬
ционного обеспечения системы в виде баз данных. Подчеркивается, что планирова-
. иие автоматизированных систем должно быть постоянной функцией предприятия.
Для работников административно-управленческого аппарата и специалистов в.
области обработки данных на ЭВМ,
2405000000—092
010(01)-84
КБ-46-10-83
ББК 32.973
6Ф7.3

Джеймс Мартин
ПЛАНИРОВАНИЕ РАЗВИТИЯ
АВТОМАТИЗИРОВАННЫХ СИСТЕМ
Книга одобрена на заседании секции редсовета по элект¬
ронной обработке данных в экономике 11,03.83
Зав. редакцией А. В. Павлюков
Редактор Е. В. Крестьянинова
Мл. редактор И. В. Щербакова
Техн, редакторы Л. Г. Челышева,
Р. Н. Феоктистова
Корректоры Г. А. Башарина, Т. Г. Кочеткова
Худож. редактор О. Н. Поленова
Переплет художника А. К. Малкина
ИБ № 1576
Сдано в набор 21.02.84. Подписано в печать 8.06.84.
Формат 70X100’/i6- Бум. офсет. № 2. Гарнитура
«Литературная». Печать офсетная. Усл. п. л. 16,25
Усл. кр.-отт. 16,25. Уч.-изд. л. 15,43. Тираж 12 000 экз.
Заказ 62 Цена 1 р. 30 к.
Издательство «Финансы и статистика»,
101000, Москва, ул. Чернышевского, 7
Московская типография № 4 Союзполиграфпрома
при Государственном комитете СССР
по делам издательств, полиграфии и книжной торговли.
129041, Москва, Б. Переяславская, 46