CC BY
98
2. Бельчусов А.А., Степанов А.В. Повышение эффективности обучения программированию в школе и вузе / Материалы V Всероссийской научно-практической конференции «Проблемы информатизации образования: региональный аспект», Чебоксары, 25-27 апреля 2007 г. — Чебоксары, 2007., с.27-33.
3. Ведяева Е.С., Ведяева С.Ю. Возможности языков программирования Visual Basic при обучении алгоритмизации и программированию / Информационные технологии в образовании. XVIII Международная конференция-выставка: Сборник трудов участников конференции. Ч. VI. — М.: МИФИ, 2008., с.19-20.
4. Онищенко В.А. Проблемы контроля знаний в компьютерном учебнике по языкам программирования / Материалы V Всероссийской научно-практической конференции «Проблемы информатизации образования: региональный аспект», Чебоксары, 25-27 апреля 2007 г. - Чебоксары, 2007., с. 241-245.
5. Свердлов С.З. Маленький большой язык Оберон // PC Week / RE №35 (109), 9/9/1997.
6. Колташев А.А., Чистяков Н.В., Попков А.И., Кучер Н.П., Ткачев Ф.В. Система ИТ-образования с точки зрения российских национальных интересов и научно-образовательных традиций / Материалы семинара "Информатика образования" в рамках VI Международной ("Ершовской") конференции "Перспективы систем информатики", 27-29 июня 2006, Академгородок, Новосибирск.
7. Потопахин В.В. Современное программирование с нуля! - М.: ДМК Пресс, 2010.
8. Кушниренко А.Г., Лебедев Г.В. Программирование для математиков: Учеб. Пособие для вузов - М.: Наука, Гл. ред. Физ.-мат. Лит., 1988. - 384 с.
9. А.Г. Кушниренко, В.Г. Лебедев. 12 лекций о том, для чего нужен школьный курс информатики и как его преподавать. Методическое пособие. - М.: Лаборатория Базовых Знаний, 2000. - 464 с.
10. Лаптев В.В., Толасова В.В., Тырнава А. Об унификации агрегатных типов данных при обучении программированию / Вестник Астраханского государственного технического университета. Научный журнал, №4(39) / 2007. - Астрахань: Изд-во АГТУ, 2007 г., с.216-221
11. Страуструп Б. Дизайн и эволюция С++: Пер. с англ.- М.: ДМК Пресс; СПб.: Питер, 2006.
УДК 004. 65
ВЫБОР СУБД ДЛЯ ПОСТРОЕНИЯ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ
СИСТЕМ
Барбара Анна Дмитриевна, преподаватель, Кузбасский государственный технический университет филиал в г. Междуреченске, Россия, Междуреченск, barbara ad@mail.ru
В последние годы наблюдается бурный рост информатизации производства. Все чаще приходится сталкиваться со сбором, обработкой и анализом больших объемов информации. Чем больше объем, тем затруднительнее ее обработка. Для обеспечения хранения, эффективной обработки информации и доступа к ней используются корпоративные информационные системы (КИС). Внедрение КИС позволяет повысить эффективность управления предприятием. КИС должны удовлетворять ряду требований:
• быть простыми в использовании;
• эффективными по функциональности;
• гибкими в решении задач организационного и технологического управления предприятием.
Центральное и важное место в информационных системах (ИС) различного класса и назначения занимают базы данных, на которые возложены функции хранения, интеграции и обработки информационных ресурсов организации. От эффективности и качества их построения во многом зависит эффективность разрабатываемых ИС. Совершенно справедливо встает вопрос о выборе системы управления базами данных (СУБД).
Если ранее использовались базы, характеризуемые достаточно простой моделью данных, - как правило, экономические и административные базы данных, то в настоящее время используются приложения, использующие большие объемы данных сложной
110
структуры, такие как СППР, мультимедиа-системы, САПР и CASE. Для таких систем нужны модели данных, которые естественным образом выражают структуру объектов и их отношения. Также обязательны поддержка собственных типов данных и операции над ними. Причем определяются новые типы данных посредством существующих в системе типов (расширяемость).
В настоящее время все больше аргументов в пользу объектно-ориентированных баз данных (ООБД). Их популярность обуславливается рядом важных отличий и преимуществ, которые предоставляют ООБД в сравнение с реляционными БД. Вот некоторые из них:
1. возможность разбить систему на совокупность независимых сущностей - объектов и провести их строгую независимую спецификацию;
2. простота эволюции системы за счет использования таких элементов объектного подхода, как наследование и полиморфизм;
3. возможность объектного моделирования системы, позволяющее проследить поведение реальных сущностей предметной области уже на ранних стадиях разработки;
4. поддержка сложных типов данных.
Это не означает, что ООБД не имеют недостатков и ограничений, к основным минусам ООБД относят отсутствие развитых средств выборки и анализа данных и единой методологии проектирования. Поэтому чаще всего для проектирования КИС выбираются гибридные БД, которые поддерживают как реляционные, так и объектные механизмы работы. Так как каждая отдельно взятая модель данных имеет как свои достоинства, так и недостатки, их совместное использование в рамках гибридной БД позволяет преумножить преимущества, одновременно компенсируя недостатки каждой модели.
Реляционная модель данных может рассматриваться как подмножество объектноориентированной, что накладывает серьезные ограничения на использование современных реализаций РСУБД при построении ООИС. Среди наиболее существенных ограничений реляционного подхода можно отметить:
• невозможность использования одинакового объектно-ориентированного подхода при разработке баз данных и приложений, их использующих;
• возникает несоответствие модели данных приложения и СУБД. Преобразование объектов в кортежи связанных таблиц и наоборот может потребовать значительных усилий, в результате теряются преимущества объектного подхода.
• невозможность определения новых типов данных с использованием предоставляемых системой или ранее определенных типов;
Реляционные модели не позволяют определять пользовательские типы данных или, используя существующие, определять данные сложных типов. Реляционная модель данных не допускает естественного представления данных со сложной (иерархической) структурой, поскольку в ее рамках возможно моделирование лишь с помощью плоских отношений (таблиц). Все отношения принадлежат одному уровню, многие значимые связи между данными могут потеряться.
• отсутствие механизмов наследования и инкапсуляции;
Реляционная модель не реализует способность порождать один класс объектов из другого, чтобы производный класс сохранял все свойства и методы своего «родителя», кроме того, обладающего рядом дополнительных свойств и методов. Инкапсуляция дает возможность трактовать объект как своеобразный «черный ящик». В ООСУБД независимо от уровня сложности, определенный класс того или иного объекта имеет определенное число общедоступных свойств и методов. Приложению не обязательно знать, как объект устроен и действует изнутри. Оно взаимодействует только со свойствами и методами объекта.
• невозможность связывать с данными операции их обработки.
Как и в объектно-ориентированном программировании, каждый объект в объектной БД содержит данные и соответствующую модель поведения. Это принципиально отличный от реляционных БД принцип, поскольку в них данные независимы от методов.
111
При проектировании КИС необходимо решить следующие задачи:
• обеспечить единое информационное пространство;
• использовать единый принцип описания и управления бизнес-процессами;
• обеспечить единый принцип доступа пользователей к корпоративной информации и функциональным приложениям;
• создание единой системы поддержки принятия решений (СППР);
• разработка единой системы ключевых показателей, описывающих деятельность предприятия.
Решение вышеизложенных задач особенно актуально для предприятия или компании, имеющей в своем составе ряд дочерних или подчиненных предприятий, каждое из которых имеет свою сложившуюся информационную инфраструктуру.
Рассмотрим, как тип выбранной БД проявляется на различных этапах цикла разработки
ИС.
На начальном этапе проектирования ИС выявляются требования к структурам БД, определяется состав хранимой информации и ее структура. Производится моделирование предметных областей пользователей, проводится системный анализ и структуризация информации. Чем лучше данные соответствуют модели, тем схема проще и эффективнее.
Для создания баз простой структуры хорошо подходит реляционная модель, но такие модели неэффективны при работе с данными новых типов и сложной структуры. Для таких баз подойдут объектные модели. В ООБД сущности представляются как объекты данных. Значения атрибутов описывают их состояние, а операции применимые к данным, определяются методами.
Чем же привлекательнее такой подход при проектировании БД? Дело в том, что в ООБД объекты помещаются в базу «целиком» вместе с методами, а не «разбиваются» на отдельные элементы для помещения в реляционные таблицы. Это упрощает доступ к данным и положительно сказывается на производительности [1].
ООБД эффективно применять для сложных предметных областей, к которым можно отнести распределенные вычислительные системы, САПР, мультимедиа и обработку изображений (образцы подписей, фото сотрудников в базе отдела кадров, конструкторская документация, аудио- и видеоинформация), системы имитационного моделирования, системы управления производством, АРМ и др. Данные такого типа имеются в любой КИС (с учетом направления деятельности предприятия, отрасли промышленности и других особенностей). Современных реализации РСУБД ограничивают расширяемость модели данных. Такие данные сложно моделировать при помощи имеющихся в реляционной модели абстракций [2].
Даже если сложный объект удается «поместить» в реляционную базу, его данные распределяются по многим таблицам. Чтобы запросы могли работать эффективно, администраторы должны нормализовать таблицы, а это не всегда легко. Поэтому базами данных, которые состоят из большого числа таблиц, труднее управлять, и они могут работать медленнее, поскольку механизм баз данных должен справиться со сложным процессом фильтрации данных из каждой таблицы.
На следующем этапе осуществляется проектирование логических структур БД. Какому подходу отдать предпочтение?
В корпоративных информационных системах используется большое число информационных элементов, поэтому логические структуры ввиду многочисленных многозначных зависимостей между данными могут состоять из десятков и сотен таблиц, что делает реляционные базы плохо обозримыми и управляемыми. Также за счет разбиения объектов теряется семантика, а это усложняет сопровождение и модернизацию системы. Существенные ограничение на использование реляционных СУБД накладывает отсутствие возможности определять свои типы данных. Реляционная модель не позволяет также определить набор операций, связанных с данными определенного типа, что часто является естественным требованием при моделировании данных со сложной структурой.
112
ООБД обеспечивают более естественный переход от концептуальной структуры БД к логической. В отличие от реляционных БД в ООБД не происходит декомпозиции объектов, выделенных на этапе моделирования, они представляются в том же виде. ООБД определяют возможность создания и использования данных сложных типов. При этом для создания нового типа необходимо унаследовать характеристики любого имеющегося типа, наиболее подходящего по своему поведению и состоянию, расширить недостающие операции и атрибуты и переопределить уже имеющиеся. Полученные объектно-ориентированные структуры обладают высокой степенью модульности, что позволяет вносить в них изменения наиболее простым способом. При этом изменения влияют на один класс (или связанную подсистему классов) и могут эффективно управляться и проверяться.
Каждая из рассмотренных технологий имеет свои преимущества и недостатки, какой подход выбрать - зависит от поставленных задач. Если на предприятии оперируют сложными типами данных, занимающими большой объем, целесообразнее использовать объектно-ориентированный подход или подумать о выборе объектных надстроек. Если данные простого типа, вероятнее нужно принять решение в пользу современных реализаций РСУБД.
Кроме того, производители ОСУБД, в том числе фирмы Versant и Objectivity, предлагают продукты, которые связывают объектные БД и существующие реляционные. Такие БД, получившие название гибридных, расширяют реляционные БД и обеспечивают поддержку объектов, которые воспринимаются как данные особого типа.
В любом случае сначала нужно взвесить все «за» и «против» для каждого подхода. Думаю, что еще достаточно длительное время предпочтения будут в пользу реляционных технологий, хотя объектно-ориентированные СУБД уже сейчас играют весьма значительную роль во многих сферах и эта роль становится все более заметной.
Литература
1. Андреев А. М., Березкин Д. В. Выбор СУБД для построения информационных систем корпоративного уровня на основе объектной парадигмы. НПЦ “ИНТЕЛТЕК ПЛЮС” http://www.inteltec.ru/publish/articles/objtech/4kx4 9.shtml
2. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. М.: Бином, 1998. - 560с.
УДК 681.3
ПРОЦЕСС ПРОЕКТИРОВАНИЯ СИСТЕМЫ УПРАВЛЕНИЯ СВЯЗЬЮ КАК ВЕРОЯТНОСТНАЯ МНОГОФАЗНАЯ СИСТЕМА
Тебекин Юрий Борисович, ст. преподаватель, Воронежский институт правительственной связи (филиал Академии федеральной службы охраны Российской Федерации), tebekin.67@mail.ru Авсеева Ольга Владимировна, к.т.н., доцент, Воронежская государственная технологическая академия, Россия, Воронеж, olga-avseeva@mail.ru Кравец Олег Яковлевич, д.т.н., проф., Воронежский государственный технический университет,
csit@bk.ru
Процесс проектирования системы управления связью, как и любой другой сложный процесс, состоящий из многих стадий и этапов, выполняемых различными подразделениями фирмы, должен быть тщательно скоординирован и увязан во времени.
График процесса проектирования должен отражать существенные в отношении достижения конечных целей работы (этапы, фазы и т.д.), а также учитывать возможные состояния комплекса соответствующих работ, сроки их выполнения, возможные нарушения этих сроков и последствия нарушений.
113
