CC BY
43
• сетевых диаграмм;
• простых схем электрических цепей;
• и многого другого...
Отличительно чертой Dia от других свободно распространяемых программ в том, что возможности ее легко расширить путем введения новых символов, которые определяются в специальных XML-файлах с использованием тегов, которые формализованы на языке графической разметки SVG. Диаграммы сохраняются в XML-формате или могут быть экспортированы в EPS- или SVG-форматы.
Dia работает под управление Linux в среде Gnome, что позволяет обеспечить работу в полностью свободной среде, доступной всем пользователям независимо от их уровня технических навыков или языка, на котором они говорят. Существует также возможность использования Dia под ОС Windows. При этом Dia требует библиотеки gtk+ и glib.
Интерфейс Dia максимально подходит под концепцию приложений Gnome и в частности похож на Gimp. Рабочая область и все элементы организованы в виде отдельных окон, что может содержать трудности для пользователей Windows.
Dia - система с открытым кодом и является абсолютно бесплатной. Пользователь имеет возможность работы как сразу с исполняемым файлом, так и может вносить свои изменения в исходный код и распространять его.
Изменения рыночной среды оказывают существенное влияние на бизнес компании, а следовательно, на ее бизнес-процессы. Осуществляя регулярный мониторинг основных показателей, например, входящих заказов, производственных издержек и прибыли, организации способны оперативно реагировать на проблемы, вызывающие снижение их эффективности. Встроенные в операционные процессы КПР позволяют сотрудникам на ранних стадиях принимать необходимые контрмеры. В конечном итоге это обеспечивает совершенствование и поддержание эффективности всех бизнес-процессов компании. ARIS -это мощный инструмент, однако, как и любой инструмент он имеет ограниченную область применения. Даже в данной области эффективность его применения зависит от соотношения планируемой выгоды и затрат на внедрение и сопровождение ARIS. Если соотношение не в пользу применения ARIS, то, возможно, имеет смысл использовать менее тяжеловесные и более дешевые инструменты. [4]
Для этого идеально подходит бесплатная и простая в установке и обращении программа Dia.
Литература
1. Рамбо Д., Буч Г. UML. Специальный справочник, - М.: Питер, 2002, - 656 с.
2. Моделирование бизнес-процессов - Электрон. дан. - Режим доступа: http://eup.ru/Documents/2003-08-11/1DF32.asp
3. Шеер А.-В. Бизнес-процессы. Основные понятия. Теория. Методы. Изд. 2-е, переработанное и дополненное. Пер. с англ. / Под ред. Каменновой М.С., Громова А.И. - М.: Весть-МетаТехнология, 1999, - 153 с.
УДК 004
ОСНОВНЫЕ ПРОБЛЕМЫ РЕАЛИЗАЦИИ ОБЪЕКТНЫХ СУБД В РОССИИ
Рудакова Анна Александровна, преподаватель, Кузбасский Государственный Технический Университет филиал, Россия, Междуреченск, anaruda@rambler.ru
Всем известно, что сегодня подавляющее большинство систем хранения данных в России строится на базе реляционных СУБД. За 35 лет существования этой технологии уже успело вырасти целое поколение архитекторов и разработчиков, которые не только были
17
обучены, но и настолько привыкли к особенностям существующих реляционных решений, что просто не допускают и мысли об использовании чего-то иного.
Историю объектно-ориентированного подхода к хранению данных нельзя рассматривать без контекста развития объектно-ориентированного программирования в целом. Ведь разработка, а также реальное применение на практике первых объектных языков программирования, таких, например, как Object Lisp и особенно Smalltalk, привели исследователей к пониманию того факта, что реляционные СУБД никак не вяжутся с объектной парадигмой, предлагаемой этими языками. Первые идеи о необходимости реализации именно объектного хранения данных высказывались в научном сообществе уже в конце 70-х годов, однако в практическое применение они вылились только к началу 80-х, когда стартовали первые исследовательские проекты в этом направлении.
Разработка и выход первых объектных СУБД сопровождались активными дискуссиями в научном сообществе. И если вначале 80-х ученый мир в основном знакомился с этой технологией, то ко второй половине этого десятилетия в нем воцарилась настоящая эйфория. Казалось, что еще чуть-чуть и волна новых объектно-ориентированных решений сметет с рынка только вошедшие в силу реляционные СУБД.
Но к началу 90-х вспыхнувшая в научных кругах эйфория стала постепенно затихать. Оказалось, что для объектных СУБД очень трудно построить такое же простое и полное теоретическое обоснование, которое нашел Кодд для реляционной модели. К тому же, многие практические реализации объектных СУБД были слишком узко специализированы и ориентировались на постепенно вытесняемый язык Smalltalk, вместо активно развивающегося C++, а компании, вложившие средства в разработку систем на базе реляционных СУБД, просто не желали переучивать людей и переходить на новые технологии. Начались попытки каким-то образом связать объектный подход с реляционным, обеспечив пользователям возможность плавного перехода от одного к другому.
Любые данные, будь то объектные или реляционные, можно преобразовывать из одной формы в другую по определенному набору правил и хранить как в объектных, так и в реляционных базах данных. Гораздо большее влияние на выбор архитекторов и разработчиков стали оказывать такие факторы, как поддержка мультипотоковости и мультипроцессорности, механизмы резервирования и защиты, средства бэкапирования и восстановления после сбоев, развитый инструментарий разработчика и средства обработки запросов. Т.е. сама внутренняя архитектура используемой СУБД вообще перестала быть определяющей.
Хоть РСУБД сейчас и навешиваются объектными и процедурными возможностями, концепции остаются каждая сама по себе.
В объектной концепции каждый объект - это свой мир со своим поведением. В реляционной всё изначально строго упорядочено. Это позволяет не заниматься программированием процесса последовательных операций, а манипулировать именно данными. Причем сервер сам, зная структуру данных и статистику их распределения, выбирает, как ему с данными работать. Любой элемент процедурности (например, UDF) уже вносит тормоза - сервер не знает, что вернёт функция, пока не выполнит её.
Да, конечно в каких-то случаях удобно использовать UDF. Но когда большие объёмы данных надо обрабатывать за небольшое время - приходится как-то обходиться без них. Наверное, кое-где, можно было бы использовать некоторые элементы ООП. Но только там где скорость не важна.
Граница, где применение объектных СУБД становится выгоднее, чем использование традиционных реляционных решений слишком расплывчата и зависит не только от предполагаемого быстродействия системы, но и от таких вещей как: требуемое время разработки, требуемая надежность, предполагаемый срок эксплуатации, частота внесения изменений и доработок, режимы работы системы, которые будут наиболее востребованы в процессе ее эксплуатации. В целом все зависит от специфики задачи и всех особенностей эксплуатации системы, рассматриваемых сообща.
18
Существуют задачи, которые будучи изначально решены на базе классических ООСУБД (например, Versant FastObjects) будут на порядок быстрее любых решений с реляционными системами.
К таким задачам относятся практически все случаи со сложной организацией и большим многообразием хранимых и обрабатываемых данных. Например, если нужно манипулировать сетями из тысяч разнотипных объектов или сами эти объекты могут быть очень сложным образом связаны.
Никто не утверждает, что реляционные системы в данном случае неприменимы - очень даже применимы и вполне функциональны. Тем не менее, с помощью ООСУБД обрабатывать и осуществлять поиск по сложноструктурированным данным оказывается значительно быстрее и удобнее:
1. Представьте себе хотя бы достаточно разветвленную иерархическую структуру однотипных объектов, в которой нужно найти элемент, удовлетворяющий заданному критерию и расположенный в строго определенной ветви дерева. Т.е., есть условие на атрибуты этого объекта и есть условие на его предка, причем число промежуточных звеньев между предком и искомым объектом заранее не известно. В рамках типовой реляционной СУБД решение есть, но оно будет гораздо медленнее.
2. Есть сеть связанных разнотипных объектов. Нужно добавить один элемент в эту сеть, полностью сохранив целостность хранимых данных. В таком случае при использовании реляционных СУБД нам придется вносить данные сразу во множество таблиц (информация о новом объекте и его связях), что будет сопровождаться многократными проверками для обеспечения целостности данных. В случае объектных СУБД такие проверки пройдут быстрее. Такая же ситуация будет и при необходимости поиска объекта в такой сети и т.п.
Практика использования ООСУБД показывает, что они приживаются в таких сферах, как: управление телекоммуникационными сетями (хранение и всей информации о структуре и параметрах элементов сетей), биоинформатика (информация о сложных молекулярных цепочках и т.п.), системы прогнозирования и принятия решений (сложноструктурированная входная информация и варианты развития событий), промышленная автоматизация (управление сложными производственными линиями и цепочками).
Однако, чтобы ООСУБД была более успешной и в других сферах деятельности нужно решить несколько задач:
1. Она должна быть не медленнее РСУБД в задачах, где РСУБД традиционно сильны.( Если в процессе эксплуатации системы необходимо часто формировать отчеты (т.е. это преобладающий режим), при генерации которых происходит линейный перебор больших массивов, то быстродействие РСУБД будет выше. Если же в основном имеет место конкурентный доступ (чтение и изменение) большого количества пользователей к различным хранимым в системе информационным сущностям (здесь важно понять именно то, что среднестатистический пользователь обычно работает именно со своим кусочком информации, лежащей в большой общей базе), то объектные СУБД лучше реляционных, т.к. обеспечивают блокировку на уровне объектов, а не таблиц).
2. Пользователи должны получить возможность максимально "мягкого" перевода своих старых систем на рельсы ООСУБД. Компании, эксплуатирующие у себя РСУБД долгие годы не готовы выбросить все свои наработки и инвестиции просто в угоду новых технологий. Да и переучивать своих сотрудников, тоже мало кому хочется, тем более в рамках мирового кризиса.
3. ООСУБД должна предоставлять удобные средства разработки приложений и логической организации структур данных. Но это не значит, что она должна всего лишь обслуживать потребности ООП программистов. ООП программирование не является синонимом «объектности» в широком смысле этого слова.
19
4. Специалистов по этим продуктам в России мало, хотя они и достаточно просты в изучении (особенно FastObjects) и опираются на промышленные стандарты (JDO, OQL), и любой ОО-программист может освоить работу с ними очень быстро.
5. Подавляющее большинство существующих сегодня , в частности в России, бизнесзадач реализуется именно в рамках реляционной модели, тем более, что эти модели уже отлажены за десятки лет. Просто в России почему-то решили, что реляционные системы - лучший выбор для всех случаев, что в корне неверно (примеров использования ООСУБД крупнейшими западными компаниями множество). Любое универсальное решение эффективно только на самых распространенных типовых задачах, в тех же сферах, где требования выходят за среднестатистические рамки универсальные решения могут стать просто золотыми и при этом низкоэффективными.
6. И самое главное, успех продукта зависит не только от технической стороны вопроса (есть еще маркетинговая и т.п.).
Литература
1. Грин Джо и др. Oracle 8/8i Server. Энциклопедия пользователя: Пер. с англ./Джо Грин и др. -К.: Издательство "ДиаСофт", 2000. - 576 c.
2. Эбби Майкл, Кори Майкл, Абрамсон Йен Oracle9i: Первое знакомство - М.: Издательство "Лори", 2003. -517 c.
3. Prise Jason Oracle Database 10g SQL - McGraw-Hill/Osborne: 2004.
УДК 004(075.8)
ГЕНЕРАЛИТИКА - НАУКА XXI ВЕКА
Кувырков Петр Петрович, к.т.н., доц., Кафедра «Автоматизация и управление», Пензенская государственная технологическая академия, Россия, Пенза, 644056@mail.ru
Наличие проблем информационной совместимости, являющихся следствием высокоразвитой специализации, породившей огромное количество информации, методов, технологий и средств их реализации, определило актуальность и перспективность разработки единого, генерализованного, подхода к их решению.
В настоящее время из-за высокоразвитой специализации не имеется даже четкого, простого, единого определения понятия информации, что отрицательно влияет на решение актуальных проблем информатики и её приложений по созданию совершенных мер информации, методов ее представления, кодирования, сжатия, интеграции, повышения скорости передачи, увеличения информационной емкости запоминающих устройств и защищенности от несанкционированного доступа.
Кроме этого, недостаточность уровня развитости подтверждается также и тем, что большинство информационных процессов, технологий и средств их реализации обеспечивают в большинстве случаев только сбор, передачу, хранение, обработку информации. Однако, в действительности же имеются информационные процессы и технологии, которые обладают большей общностью, универсальностью, более высоким интеллектуальным уровнем развитости, обеспечивающим повышение эффективности сжатия, интеграции, совместимости информации, её коммуникаций при обобщении, или генерализации, определяя потребность дальнейшего развития и совершенствования теоретических основ информатики и информационной техники.
Разработка интеграционных основ информационной совместимости определяет большие перспективы дальнейшего развития и совершенствования образования, науки, техники и технологий, в первую очередь, в области информатики и её приложений, для проектирования информационной техники, автоматизированных систем управления,
20
