"Мгновенное" виртуальное предприятие
"Мгновенное виртуальное предприятие" (Instant Virtual Enterprise, IVE) – это группа компаний, которая обычно не функционирует как организационная единица, а объединяется для того, чтобы отреагировать на заказ клиента или запросить предложения. Характерным примером среды, требующей кооперации типа IVE является автоматизированное интегрированное производство (Computer Integrated Manufacturing, CIM). Среда CIM включает многие специализированные отделы и подсистемы. С технологической стороны в нее входят автоматизированное проектирование, производство и контроль качества. В то же время, управленческая часть включает планирование производства, управление производством, а также управление ресурсами. Перечисленные специализированные подсистемы относятся к разным организациям, каждая из них располагает собственными пользовательским интерфейсом, моделью данных, специализированными операциями и организацией среды хранения.
Во многих бизнес-областях для компаний, входящих в IVE, необходимо будет обмениваться и на кооперативных началах управлять большими объемами данных. Маловероятно, что информационные системы будут интегрироваться друг с другом в то время, когда принимается решение относительно сотрудничества в продажах или в заявке на торгах. Даже в внутри одной компании с автоматизированным интегрированным производством будет существовать много разнородных баз данных. Тем не менее, совместное использование данных и обмен данными между организациями-участниками, а также координация этой информации, являются крайне необходимыми.
Далее мы приведем пример сценария для мгновенного виртуального предприятия с автоматизированным интегрированным производством (CIM IVE). Затем примеры из этого сценария будут использованы для иллюстрации тех областей, где применение функциональных возможностей баз данных требуется по отношению к таким данным, которые в настоящее время не обязательно находятся под контролем СУБД.
Итак, пусть компания A строит нефтяной трубопровод и нуждается для этого проекта в 600 вентилях большого диаметра.
Она запрашивает заявки для торгов, выпуская запрос предложений (Request For Proposal, RFP), специфицирующий размеры, механизм соединения, рабочие температуры, диапазоны давления, требования по устойчивости от коррозии и т.д. Компания инженерного профиля Q имеет намерение создать некоторое IVE для ответа на данный запрос предложений. Инженеры в Q используют Internet для поиска компаний, уже разработавших конструкцию такого рода вентилей, которая может быть использована. Оказывается, компания R имеет намерение лицензировать такую разработку.
Компания Q планирует самостоятельно выполнить работы по модификации предлагаемой конструкции, но будет контактировать с компанией S в части выполнения технологического анализа модифицированной конструкции и трансформации технической документации в производственный план. Компания T берет на себя фактический выпуск изделий, но намерена заключить контракт с компанией U на изготовление пресс-форм и отливку.
Наконец, компании V и W также собираются кооперироваться: компания V предоставит услуги по конвертированию файлов технической документации в формате того пакета системы автоматизации проектирования (Computer Aided Design, CAD), который используется компанией R, в формат системы CAD, которую планирует использовать компания Q. В свою очередь, компания W предоставит документацию и услуги по архивированию для таких документов, как инструкция и руководства по эксплуатации.
Теперь мы приведем пример тех видов возможностей баз данных, которые при этом требуются как на этапе подготовки совместной заявки, так и при выполнении контракта (если будет выигран тендер).
Когда компания Q искала существующие разработки вентилей, она выполняла запрос. Ряд аспектов этого запроса порождает весьма интересные проблемы: некоторые его части основаны на близком, а не на точном соответствии. Запрос касается разработок многих компаний, которые предположительно имеются во многих различных репозитариях. Кроме того, сведения о разработке компании R могут храниться не в среде какой-либо СУБД, а в индивидуальных файлах, для которых может не иметься аналога схемы базы данных.
Поиск по сходству требует усложненного индексирования, основанного на многих дескрипторах и векторах свойств большой размерности. Уже этот аспект проблемы побуждает к размышлению. Кроме того, интересный момент здесь заключается в том, что мы должны обеспечивать запрос и поддержку индексирования на внешних объектах. Какую бы усложненную поддержку индекса мы не изобрели, должны отслеживаться изменения внешних объектов, и индекс должен согласовываться с ними.
Чтобы компания S могла оценить стоимость технологического анализа и производственных планов, ей необходимо видеть первоначальную техническую документацию, но в форме, которая совместима с ее инструментальными средствами. Таким образом, при подготовке совместной заявки возникает потребность в услугах по трансляции данных, предоставляемых компанией V. Однако для этого требуется знать формат проектных файлов компании R. Возможно, эти файлы представлены в каком-либо самоописываемом обменном формате, но возможно также и то, что должна быть добавлена какая-либо дескриптивная информация.
Часто для описания и для обмена данными продуктов CIM используются такие стандарты, как STEP/EXPRESS4. Однако для того, чтобы дать возможность компании R ограничить выдаваемую информацию некоторым подмножеством схемы, выделенным по принципу "служебной необходимости", должны обеспечиваться некоторые дополнительные механизмы. Едва ли можно себе представить, что компания R будет готова сообщить все детали своей разработки только для целей подготовки совместной заявки.
Если IVE, руководимое компанией Q, выигрывает тендер, возникает потребность в координации и управлении конфигурацией, поскольку первоначальная разработка должна быть сначала модифицирована для того, чтобы она удовлетворяла спецификациям, а затем должна подвергнуться дальнейшей модификации на основе анализа, проведенного компанией S, и обратной связи по результатам работы компаний T и U, связанной с оценкой возможностей производства. Множество зависимостей между данными в различных компаниях IVE должно координироваться (например, должна иметься координация между объектами в различных подсистемах).
Должны моделироваться и поддерживаться связи и ограничения целостности (по ссылкам), не требуя при этом, однако, создания традиционной глобальной базы данных.
Изменения какого-либо объекта в одной подсистеме требуют изменений в одном или более связанных с ним объектах в других подсистемах. Изменения во внешних системах должны отслеживаться и потенциально распространяться на другие системы. Если, например, компания U изменяет шпиндель вентиля, связанная с ним документация вентиля должна быть изменена компанией W. Доступ к сведениям о шпинделе в компании U может быть ограничен до тех пор, пока документация не будет обновлена компанией W. И снова компания U экспортирует информацию только в соответствии с принципом "служебной необъодимости" (т.е. только информацию, необходимую для указанного обновления документации).
Предположим теперь, что компания Q решает заменить шпиндель t, поставляемый компанией T, шпинделем t' другой компании T', поскольку t'
в некотором смысле эквивалентен, но стоит дешевле. Это изменение может стать причиной изменений в конструкциях всех типов вентилей, где использовался t, что приводит в результате к конфликту между маркетинговым решением компании Q и конструкторской деятельностью компании S. Поддержка деятельности по разрешению таких конфликтов имеет важнейшее значение для IVE.
Например, в указанном случае должно быть принято решение определить, действительно ли конструкции всех типов вентилей должны измениться, и t' должен использоваться вместо t, либо некоторые конструкции вентилей могут не подвергнуться изменениям, что приводит к необходимости повторных переговоров с компанией T. Отслеживание релевантных изменений и выявление конфликтов – это функциональная возможность систем баз данных, которую следует здесь использовать.
В то время как IVE функционирует, имеется также потребность в обеспечении безопасности и контроля доступа к информации. Возможен, например, такой случай, когда компании R и T являются конкурентами, и поэтому R готова позволить компаниям Q и S видеть первоначальную конструкцию, но не хочет предоставлять к ней доступ для компании T.
Наконец, компания A нуждается в гарантиях, что информация относительно конструкции и производства вентилей будет доступна даже после расформирования IVE. Поэтому возникает потребность в архивировании информации, которая, возможно, является независимой от какой-либо из входящих в IVE компаний. Такой архив является базой данных.
