CC BY
115
8. Салибекян С.М., Халькина С.Б., Тиновицкий К.Д. Объектно-атрибутный подход для семантического анализа естественного языка. // Объектные системы - 2014: материал VI Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2014 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ ЮРГТУ (НПИ), 2014. - C. 80-86
9. Jurij Silk, Borut Robic and Theo Ungerer «Asynchrony in parallel computing: From dataflow to
multithreading» Institut Jozef Stefan, Technical Report CDS-97-4, September 1997.
УДК 004.43:378.09
УСТРОЙСТВО ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ БАЗ ДАННЫХ
Мясникова Нелли Александровна, доцент, Южно-Российский государственный политехнический университет (Новочеркасский политехнический институт) имени М.И. Платова, Россия,
Новочеркасск, mnela@list.ru
Курин Николай Дмитриевич, студент, Южно-Российский государственный политехнический университет (Новочеркасский политехнический институт) имени М.И. Платова, Россия,
Новочеркасск, kurin.kolvan@vandex.ru
Первая информация об объектно-ориентированных базах данных (ООБД) появилась в середине 80-х годов. Возникновение ООБД было обусловлено, в первую очередь, потребностями их практического использования: необходимостью разработки все более сложных информационных прикладных систем, для которых технологии предшествующих систем баз данных были не очень удобны. В наше время ООБД используются практически во всех областях информационных технологий, начиная от операционных систем и заканчивая системами управления различных предприятий.
Главная особенность объектно-ориентированных баз данных в том, что данные внутри таких баз данных моделируются в виде объектов, их атрибутов, методов и классов. ООБД, в основном применяются в случаях, когда требуется высокая производительность при обработке данных, имеющих сложную структуру [4].
В статье представлены устройство и способ создания простейшей ООБД. В качестве предметной области использован магазин игрушек.
Объектно-ориентированные базы данных реализуются в объектно-ориентированных системах управления базами данных (ООСУБД). У этой системы есть некоторые требования, которые необходимо учесть при проектировании. В манифесте ООБД выделены обязательные характеристики, которым должна отвечать любая объектно-ориентированная база данных. Их выбор основан на двух основных критериях: система должна быть объектно-ориентированной и представлять собой базу данных. Основными характеристиками являются [1]:
1. Поддержка индивидуальности объектов.
2. Поддержка инкапсуляции.
3. Поддержка типов и классов.
4. Поддержка наследования типов от классов и их предков.
Рассмотрим подробнее каждую из выделенных характеристик.
Поддержка индивидуальности объектов означает, что каждый объект должен иметь свой уникальный идентификатор, который не должен зависеть от значений атрибутов этого объекта.
Поддержка инкапсуляции достигается за счет того, что пользователь обладает правами доступа только к некоторым методам, реализующим интерфейс, а данные и внутренняя реализация методов сокрыты внутри объектов базы данных.
Поддержка типов и классов. Требуется, чтобы в ООБД поддерживалось хотя бы небольшое различие между типами и классами. Термин «тип» более соответствует понятию абстрактного типа данных. Информация о типе данных может использоваться для проверки
76
выполняемых с переменной операцией на совместимость с ее типом. Класс же является неким шаблоном для создания объектов и предоставляет методы, которые могут применяться к этим объектам.
Поддержка наследования типов от классов и их предков означает, что при наследовании подтип или подкласс должен наследовать атрибуты и методы от всех родительских классов.
Построение базы данных проходит в несколько этапов:
• Изучение предметной области.
• Концептуальное проектирование.
• Логическое проектирование.
• Физическое проектирование.
Рассмотрим подробнее каждый из этапов.
Начиная проектирование объектно-ориентированной базы данных, нужно в первую очередь изучить предметную область, в которой будет выполняться работа БД, учесть основные процессы, требования и пожелания заказчика и будущих пользователей. На этом этапе происходит определение примерного функционала приложения и границ базы данных.
Следующим этапом является концептуальное проектирование БД, иными словами, конструирование модели, не зависящей ни от каких физических особенностей реализации. Это позволяет описать высокоуровневую модель базы данных и схему ее работы, независимо от любых деталей реализации, как, например, язык программирования, тип СУБД, любые вопросы, касающиеся производительности, аппаратной и программных частей.
После того, как концептуальное проектирование было завершено, наступает логическое проектирование БД, то есть конструирование информационной модели на основе конкретно выделенных, существующих типов данных, но без учета специфики СУБД и прочих физических особенностей реализации. Обобщенно, логическое проектирование представляет собой преобразование концептуальной модели в логическую, при этом учитывая тип СУБД (в данной статье - объектная СУБД). В дальнейшем логическая модель послужит основой для физической модели. Логическая модель позволяет разработчику всесторонне изучить поведение БД и конкретных данных, принять некоторые решения относительно выбора средств физической ее реализации.
Заключительным этапом является физическое проектирование. На этом этапе происходит непосредственная реализация базы данных, помещение ее во внешнюю память. Физический проект определяет отношения объектов, структуру файлов, тип индексации, применяемой для быстрого доступа к объектам базы данных. Здесь же обеспечиваются все меры защиты и целостности хранимой информации.
Физическое проектирование требует принятия окончательного решения относительно способов реализации создаваемой базы данных. Из-за этой особенности физическое проектирование производится с учетом всех особенностей используемой СУБД. Зачастую между этапами логического и физического проектирования существует обратная связь. Это объясняется тем, что с учетом всех физических особенностей реализации и решений, принятых на этапе физического проектирования, может потребоваться корректировка и логической схемы.
При построении концептуальной и логических схем очень удобно использовать UML (Unified Modeling Language) - унифицированный язык моделирования. Этот язык был создан специально для визуализации документирования объектно-ориентированных программных систем. Язык позволяет наглядно выделять сущности, их атрибуты и сущностные связи, поддерживает отображение абстрактных классов. Важно отметить, что UML не является языком программирования
Перейдем непосредственно к построению базы данных. При разработке БД в первую очередь необходимо составить концептуальную схему. На Рис. 1 представлены все
77
выделенные сущности и их атрибуты. Для описания продукта (а это главная сущность в любом магазине) была выделена сущность Product. Эта сущность должна иметь следующие атрибуты: название продукта (Name) - представляет собой строковую переменную, цену за единицу товара (Price) и количество товара, которым на данный момент располагает магазин (Count), которые представлены в виде числовых значений. У магазина имеются клиенты -покупатели, для их описания была выделена сущность Client. Данная сущность содержит следующие атрибуты: Name - имя покупателя, представляет собой строковую переменную, Phone - контактный телефон покупателя, представленный числовым значением, и Address -адрес покупателя, представленный строковой переменной. Третьим участником отношений являются поставщики, для их описания была выделена сущность Provider. Эта сущность содержит следующие атрибуты: Name - имя поставщика (название организации), представляет собой строковую переменную, Phone - контактный телефон поставщика, представленный числовым значением, и Address - адрес поставщика, представленный строковой переменной.
Рис. 1- Концептуальная модель
Перед построением логической модели был проведен тщательный анализ концептуальной схемы. Оказалось, что все сущности имеют схожее по своему назначению поле Name, в котором хранится название или имя. В связи с этим был выделен класс NamedObject, который является абстрактным, так как экземпляры данной сущности отсутствуют. Теперь классы Product, Client и Provider наследуются от одного абстрактного класса NamedObject.
Пример реализации наследия классов непосредственно в коде программы:
//Абстрактный класс "Имя Объекта", содержащий имя public abstract class NamedObject {
public string Name { get; set; }
}
//Класс "Клиент", производный от "Имя Объекта" public class Client : NamedObject {
//Некоторая реализация
}
//Класс "Продукт", производный от "Имя Объекта" public class Product : NamedObject {
//Некоторая реализация
}
При переходе к логической схеме (Рис. 2) для характеристики отношений «продукт -покупатель и «поставщик - продукт» были созданы классы Sale и Delivery. Класс Sale характеризует сущность «продажа», и, по сути, объединяет в себе часть класса Product и часть класса Client. Класс Sale имеет следующие атрибуты: Name - наименование продукта, Date - дата продажи, реализована с помощью специальной переменной, хранящей дату и время, Count - количество поставленных товаров, Price - цена за единицу товара. Класс Delivery характеризует сущность «поставка», и, по сути, объединяет в себе часть класса Product и часть класса Provider. Класс Delivery имеет атрибуты, аналогичные классу Sale, но с иначе переопределенными методами. На схеме наглядно видно, что класс Product
78
становится наследуемым от нескольких классов, в частности, поле «Name» наследуется от класса NamedObject, а поля Price и Count отошли в классы Sale и Delivery.
Рис. 2 - Логическая модель
Как видно из рисунков, переход от концептуальной схемы к логической заключается в абстрагировании некоторых классов и характеристике сущностных отношений.
Следующим шагом является реализация базы данных и приложения для работы с ней на целевой платформе с использованием наиболее удобного языка программирования (Рис. 3), чаще всего это либо C#, либо Java. В качестве ООСУБД зачастую используется DB4O, в связи с ее бесплатностью и наличием необходимых библиотек для указанных выше языков [2].
Выберите пункт и нажмите Enter:
1 - Заполнение БД тестовой информацией
2 - Вывод информации из БД
9 - Выход из программы
2
Вывод всей информации:
Список поставок:
Поставщик: СКПЙД Номер телефона: 8-901-672-43-65 Адрес: уп. Вкуснякова д.
49
17.09.2009 9:10:00 Продукт: Конструктор Lego Количество: 1000 Цена: 15
Список продаж клиентам:
Клиент: "Магазин Игрушек Анненко" Номер телефона: 8-968-890-47-78 Адрес: l
п. Суворова д.34
02.02.2010 17:13:00 Клиент: "Магазин Игрушек Анненко" Номер телефона:
8-968-890-47-78 Адрес: уп. Суворова д.34 Продукт: Игрушечная нашинка Количество:
7 Цена: 2
Рис. 3 - Демонстрация работы программы, написанной на языке C# с использованием бесплатной объектно-ориентированной системы управления базами данных DB4O
Подводя итоги, можно отметить, что объектно-ориентированные базы данных очень удобны в реализации информационных структур практически любой компании или предприятия. Главной задачей становится выделение основных сущностей и их атрибутов, а также сущностных отношений, что требует ознакомления с объектной областью применения БД. Также необходимо помнить, что на этапах логического и физического проектирования все решения необходимо согласовывать с заказчиком [3].
Современные объектно-ориентированные языки программирования позволяют с легкостью создавать классы, реализующие сущности, а ООСУБД, как правило, уже
79
включают в себя необходимые библиотеки. При знании определённые правила построения объектно-ориентированных баз данных и следовании указанным советам, построение любой ООБД сводится к последовательному выполнению выделенных этапов, которые обеспечивают успешное завершение создания необходимой базы данных.
Литература
1. Объектно-ориентированная база данных, https://ru.wikipedia.org/wiki/Объектно -ориентированная база данных
2. Введение в объектно-ориентированные базы данных, http://habrahabr.ru/post/56399/
3. Кузнецов С.Д. Объектно-ориентированные базы данных - основные концепции, организация и
управление: краткий обзор, http://citforum.ru/database/articles/art 24.shtml
4. Медников А.Ю., Соловьев А.Ю. Объектно-ориентированные базы данных сегодня или завтра?,
http://www.osp.ru/os/1994/04/178519/
УДК 004.4’6
РАЗРАБОТКА АЛГОРИТМА ФУНКЦИОНИРОВАНИЯ АВТОМАТИЗИРОВАННОГО МОДУЛЯ ИНФОРМИРОВАНИЯ В
РАСПРЕДЕЛЕННОЙ СИСТЕМЕ, НАПРАВЛЕННОЙ НА ПОДДЕРЖАНИЕ БЕРЕЖЛИВОГО ЭНЕРГОПОТРЕБЛЕНИЯ
Болдырев Владислав Вячеславович, магистрант, кафедра «Автоматизации и управление», Комсомольский-на-Амуре государственный технический университет, Россия, Комсомольск-на-
Амуре, Boldurev16@gmail.com
Горькавый Михаил Александрович, канд. тех. наук, доцент, кафедра «Управление
инновационными процессами и проектами», Комсомольский-на-Амуре государственный технический университет, Россия, Комсомольск-на-Амуре, idpo@knastu.ru
В настоящий момент времени реализация потенциала энергосбережения предприятий и организаций в значительной степени определяется эффективностью функционирования персонала, задействованного в СЭМ. Таким образом, повышение мотивации сотрудников и организация оперативной обратной связи по результатам их деятельности является ключевыми в задачах обеспечения бережливого энергопотребления. Ранее в работах авторов [1-4], была, предложена концепция интеллектуальной распределенной системы энергоменеджмента (представляющей собой комплекс из аппаратных и технических средств). Составные части системы будут находиться удаленно друг от друга, что связанно с необходимостью установки измерительных устройств (ИУ) в определенных зонах для сбора и передачи объективных данных на вычислительное устройство, находящееся в доступном для пользователя месте.
Подсистемой предложенного программно-аппаратного комплекса является МИС, позволяющая своевременно предупредить сотрудников о неэффективном использовании электроэнергетических ресурсов и сформировать предложения по устранению ошибок в их использовании. Классификация управляющих воздействий (сигналов) в СЭМ организации на основе объектно-ориентированного подхода, представлена в предыдущей работе авторов [2].
Модуль предполагает интеграцию с мобильными устройствами пользователей, где предустановленна часть программного обеспечения системы (клиент). Все необходимые алгоритмы обработки данных и вычисления производятся на серверах распределенной СЭМ.
Формирование информационных сигналов (визуальных или звуковых) происходит согласно алгоритму, представленному в формате IDEF0 на рисунке 1.
Особенность предложенного алгоритма состоит в последовательности условий, позволяющих классифицировать ошибку, каждая из которых взаимоисключает другую (ветки 7 и 8). Кроме того алгоритм содержит цепочку из условий и операций, направленную
80
