Синергетическое информационное пространство МУОРБД Текст научной статьи по специальности «Компьютерные и информационные науки»

Безопасность в широком смысле подразумевает выполнение двух функций: аутентификацию и авторизацию. Аутентификация означает выяснение того, кто вы, а авторизация означает определение того, что вы имеете право делать. Zope предоставляет отдельное средство для управления процессом идентификации пользователей и предоставления им доступа к контролируемым операциям. Для определения учетных имен пользователей Zope использует фолдеры acl_users (User Folder).

Когда вы впервые обращаетесь к защищенному ресурсу, Zope просит вас зарегистрироваться и отыскивает ваше учетное имя в пользовательском фолдере. Zope пытается аутентифицировать вас лишь при попытке обращения к защищенному ресурсу. Если вы работаете с публичными ресурсами, Zope будет продолжать считать вас анонимом.

После того, как вы идентифицировали себя, Zope определяет, имеете ли вы доступ к защищенному ресурсу. В этот процесс вовлекаются два промежуточных слоя, расположенных между вами и защищенным ресурсом: роли и права. Пользователи имеют роли, которые описывают, что они могут делать в системе, а объекты Zope имеют права, которые описывают, что можно делать с этими объектами. Режимы безопасности сопоставляют роли с правами. Иными словами, они определяют, кто и что может делать. Таким способом Zope авторизует пользователя для доступа к защищенному ресурсу.

Новая роль вводится на вкладке Security объекта. Роль может использоваться в сайте на том уровне, где она определена, и ниже. Поэтому, если нужна роль, имеющая значение для всего сайта, она определяется в корневом фолдере сайта.

Выводы

Предложенная технология Zope позволила конструировать из объектов сложные порталы, посвященные многообразным темам. Можно легко модернизировать содержание и структуру полученной конструкции. Изменения будут динамически публиковаться во внешних представлениях страниц сайта. Обеспечены разные уровни безопасного доступа к объектам членам сообщества пользователей. Студенты, выполняя курсовую работу, приобретают компетенции разработчика, дизайнера, администратора, посетителя портала.

Литература

1. Неудачин И.Г. Среда Web-публикации объектов для студентов // Объектные системы - 2011:

материалы III Международной научно-практической конференции. / Под общ. ред. П.П.

Олейника. - Ростов-на-Дону, 2011. - с. 62-65.

2. Неудачин И.Г. Инфраструктура программирования в открытых кодах для студентов. //Теория

и практика применения свободного программного обеспечения: сборник трудов участников

Всероссийской молодёжной конференции с элементами научной школы. - Магнитогорск:

МаГУ, 2011. -с. 57-64.

3. Спикльмайр С. и др. Zope. Разработка Web-приложений и управление контентом: Пер. с англ. -

М.: ДМК Пресс, 2003. - 464 с.

4. Единая система программной документации. - М.: Издательство стандартов, 1982. - 128 с.

УДК 004.04

СИНЕРГЕТИЧЕСКОЕ ИНФОРМАЦИОННОЕ ПРОСТРАНСТВО МУОРБД1

Микляев Иван Александрович, к.ф.-м. н., доцент, Филиал «СЕВМАШВТУЗ», Санкт-Петербургский государственный морской технический университет, Россия, Северодвинск,

ivanmia1@rambler.ru

Черткова Ольга Владимировна, старший преподаватель, Филиал «СЕВМАШВТУЗ», Санкт-Петербургский государственный морской технический университет, Россия, Северодвинск,

chertkova-o@,mail.ru

1 Статья рекомендована к опубликованию в журнале "Информационные технологии"

67

Реляционные БД - это мощнейшая и в то же время наипростейшая система для реализации информационного пространства в формальном виде. Использование реляционных баз данных было предложено доктором Коддом в 1970 году [1]. РБД могут быть реализованы даже в бумажном виде: примером тому является нумерация

подразделений в организации (например, в ВУЗе: кафедры, деканаты, на производстве цеха, отделы, которые, впоследствии, обозначаются не наименованием и описанием, а просто номером).

Но важной проблемой, с которой сталкиваются разработчики БД при реляционном представлении данных, является неадекватность отражения предметной области в информации БД [2].

Чаще всего информация предметных областей представляет собой множества и подмножества логически объединённых фактов. В реляционной модели данных - плоская таблица, соответствующая отношению, является инструментом отражения информации. Безусловно, этот инструмент даёт максимальную эффективность оперирования данными, но для этого приходится дезинтегрировать данные, применив нормализацию. Тем самым отбрасываются вариации значений характеристик объектов при взаимодействии с окружающей средой или другими объектами, то есть отбрасываются синергетические свойства этих характеристик, что является той самой неадекватностью. [3]

В идеале модель информационного поля объекта должна предельно приближаться к реальному её содержанию. Но если оглянуться - мир вокруг нас не является плоским. Действительность многомерна, многогранна, многополярна. Даже если свести реальность к узкой предметной области, то для адекватного отражения необходимо провести всесторонний анализ объектов, её составляющих: структурный, пространственный и темпоральный. Потому что большинство объектов из чего-то состоят, где-то находятся и как-то развиваются во времени.[5]

Рассмотрим человека как объект для описания. В государстве и обществе он идентифицируется фамилией, именем, отчеством и датой рождения, с точки зрения медицины обязательно необходимы параметры: группа крови и пол, со стороны трудовой деятельности человек идентифицируется ИНН и номером пенсионного страхования. То есть объект позиционируется в зависимости от того, в какой среде и в каких условиях он рассматривается.

То же самое происходит и с характеристиками объекта. Взаимодействие - синергия с внешним миром - является тем моментом, который придаёт значения характеристикам объектов. Вокруг нас синергетическое пространство - нелинейное, неоднозначное, и синергетические образы объектов в нём носят отпечаток незавершенности и диалога [4].

Например, фамилия человека - синергетическая характеристика, зависящая от обстоятельств, в которых он пребывает. Чаще всего меняют фамилию при регистрации брака - "Петрова" после замужества становится "Ивановой", а при пересечении границы России -"Ivanova". То есть и сам объект, и его свойства не существуют сами по себе, они проявляются только во взаимодействии со средой, в которой рассматриваются.

При прагматическом взгляде может показаться, что синергетические характеристики не так уж и важны и нужны для рядовых пользователей баз данных, чтобы подрывать сложившиеся устои. Но это только на первый взгляд. Наиболее очевидная из синергетические характеристик - положение в пространстве, востребована, как никогда, в системах глобального позиционирования. Создаваемые ими векторные карты представляют собой базу данных, где хранится информация об объектах, их характеристиках с привязкой ко времени, их взаимном месторасположении, географических и других координатах.

Не менее важная синергетическая характеристика - темпоральность (протяжённость объекта во времени) - крайне актуальна для бизнеса. Для любой коммерческой компании необходимо иметь доступ к историческим данным или данным прошедших периодов, которые позволяют анализировать свою работу и корректировать её в направлении оптимизации затрат и спектра деятельности. А классическая реляционная база данных

68

хранит только последнюю версию, сиюминутный отпечаток предметной области, в ней описанной. Отображение синергетического пространства в реляционный кортеж сравнимо с плоской фотографией живого объекта, с сечением плоскостью многомерного тела.

Возвращаясь к банальной фамилии: в реляционной базе предусмотрена основная фамилия и в крайнем случае - девичья. В случаях со сменой фамилии до момента изменения человек по документам должен проходить под старой фамилией, после изменения - под новой. Таким образом, в документах создаваемых за период до изменения человек должен идентифицироваться старой фамилией, а за период после смены - новой. Это доставляет массу проблем и дополнительной работы программистам, при этом пободные случаи редки, и таким образом учёт таких ситуаций экономически малоэффективен для заказчика, но необходим. Более того, "фамилию" может поменять не человек, а организация или учреждение, подобное Северному Арктическому Федеральному Университету (САФУ), изменявшему своё название дважды за время своего существования.

Сравним, как отображаются синергетические атрибуты сущности в РБД и матричной универсальной объектно-реляционной БД (МУОРБД). Наиболее популярная сущность в БД - индивид (рис.1), которая обладает атрибутами - фамилия, имя, отчество и дата рождения. Как реализуется темпоральность этих атрибутов.

Индивид

id: NUMBER |

Birth0а1е_Дата_рождения_: CHARACTER

F атфамилня: VARCHAFLZ (20)

Name_HMH_: VARCEAR2(20)

SNатеотч еств o_: VARCHAR2(20)

Рис. 1 - Erwin диаграмма сущности Индивид

КОД ИНДИЕ дата рождения

1 15.08.1974

2 13.05.1974

3 11.06.1974

4 17.08.1995

5 01.03.1996

6 14.03.1979

7 05.05.1996

8 12.08.1974

9 01.05.1972

10 20.12.1972

КОД ИНДИВ! ФАМИЛИЯ Дата с Дата по

1 ПОПОВА 15.06.1974 15.06.1992

1 КОТОВИКОВА 16.06.1992 17.04.2011

1 АНКУНДИНОВА 18.04.2011

2 ТЮХТЯЕВА 13.05.1974 08.09.1995

2 СИРИКОВА 09.09.1995

3 ГЛАДЫШЕВА 11.06.1974

4 ГОЛУБЕВ 17.08.1995

5 КАРДАШ 01.03.1996

6 КУЗНЕЦОВА 14.03.1979 23.07.1974

6 ЛАРИОНОВА 24.07.1974

7 КУЗНЕЦОВА 05.05.1996

8 ИВАНОВА 12.08.1974 18.06.1999

В ПЕТРОВА 19.06.1999

9 ЛАРИОНОВ 01.05.1972

10 РАБИНОВИЧ 20.12.1972 07.02.1992

10 ИВАНОВ 08.02.1992

код I ОТЧЕСТВО индивида Дата с Дата по

1 ВИКТОРОНА 15.06.1974

2 ВЛАДИСЛАВОВНА 13.05.1974

3 ИВАНОВНА 11.06.1974

4 ПЕТРОВИЧ 17.08.1995

5 АНАТОЛЬЕВНА 01.03.1996

6 АРСЕНЬЕВНА 14.03.1979

7 АЛЕКСЕЕВНА 05.05.1996

8 ВЛАДИМИРОВНА 12.08.1974

9 ВЯЧЕСЛАВОВИЧ 01.05.1972

10 САМУИЛОВИЧ 20.12.1972 07.02.1992

10 ИВАНОВИЧ 08.02.1992

КОД индиви ИМЯ да Дата с Дата по

1 АННА 15.06.1974

2 ЕЛЕНА 13.05.1974

3 ОЛЬГА 11.06.1974

4 МАКСИМ 17.08.1995

5 АЛЁНА 01.03.1996

6 ВАЛЕНТИ 14.03.1979

7 АНАСТАС 05.05.1996

8 ОЛЬГА 12.08.1974

9 ЮРИЙ 01.05.1972

10 ЯКОВ 20.12.1972 07.02.1992

10 ИВАН 08.02.1992

Рис. 2 - Схема представления сущности Индивид в РБД с учётом синергетичености характеристик

Синергетический атрибут имеет несколько значений. Для того, чтобы уложить это многообразие в жёсткие кортежи реляционной модели, необходимо создать дополнительную сущность, соответствующую атрибуту, - таблицу для значений атрибута и организовать

69

связь. То есть к сущности Индивид добавляется ещё три: Фамилия, Имя, Отчество, соединённые связью один ко многим (рис.2).

Последствиями являются и разрастание объёма БД, и снижение эффективности обработки данных, и, в конечном счёте, снижение качества удовлетворения информационных потребностей пользователей.

МУОРБД располагает несравненно большей гибкостью и возможностями. Единица информации в МУОРБД обладает древовидным строением, поэтому синергетичность характеристик-атрибутов естественным образом вписывается в эту нелинейную структуру, сохраняется адекватность отражения информации, появляется комфортная для пользователя возможность заносить сведения как обычное предложение.

В системе представления данных (СПД) МУОРБД традиционный реляционный кортеж расширен на два измерения, которые и позволяют формировать многострочные единицы информации. К традиционному 3-мерному пространству реляционных СПД (таблица (отношение) - столбец (атрибут, поле) - строка (кортеж)) добавлено измерение - БД (1-ый индекс) и измерение элементов кортежа (5-ый индекс). Таким образом, измерения в МУОРБД представляют собой:

1. БД

2. Таблица

3. Строка

4. Группа (многострочная единица информации)

5. Элемент группы (атомарная единица информации)

6. Элемент единицы кортежа

^МУБД: Индивид

Анализ Статистика Сервис ВЫХОД

Таблица

Индивид

Данные таблицы | Иерархия]

г Фильтр

Фамилия Имя Отчество Дата рождения

ПопоБаЖатовикова/АнкуцдиноБа |4нна Викторовна |15.06.1974

Сирикова/Т кшяева Елена Владиславовна 13.05.1974

Гладышева Ольга Ивановна 11.06.1972

Голубев Максим Петрович 17.08.1995

Кардаш Алёна Анатольевна 01.03.1996

Ларионова/Кузнецова Валентина Арсеньевна 14.031979

Кузнецова Анастасия Алексеевна 05.05.1996

Петрова/Иванова Ольга Владимировна 12.08.1974

Ларионов Юрий Вячеславович 01.05.1972

Присняк Илья Петрович 20.121972

Характеристики ПОЛНЫЙ Фильтр |

Дерево

Параметры

ПоповаЖотовиковаУАнкуншноваУАннаУВикторовнаЛ Б.

Групг № _в_г Параметр Значение Дата с Дата по |

|1 1 Фамилия Попова 08.06.1333 1

1 2 Фамилия Котовикова 09.06.1993 17.04.2011

1 3 Фамилия Анкундинова 18.04.2011

2 1 Имя Анна

3 1 Отчество Викторовна

4 1 Дата рождения 1506.1974

Рис 3. Представления сущности Индивид в МУОРБД

Особенностью является, то, что элементы кортежа не просто пронумерованы, а объединены друг с другом в смысловые группы. То есть четвёртый индекс - не номер элемента в кортеже, а номер группы, к которой относится элемент. В 6-м измерении МУОРБД находится статический массив размерностью пять, состоящий из стандартной реляционной пары - наименование атрибута и его значение (например: «фамилия» -«Иванова»), которая дополнена временными границами жизни информации («фамилия» -«Иванова» - с 1980 года до 2000 года) - и номер родительского элемента в группе, для организации древовидной структуры (рис 3).

Известно, что СУБД РБД самого последнего поколения декларируют поддержку темпоральности базы данных, но какой ценой достигнута это востребованное у клиентов свойство - разработчики умалчивают. В МУОРБД это свойство прозрачно и органично реализуется благодаря её матричной структуре.

70

Язык SQL запросов весьма непросто работает с данными, привязанными к промежуткам времени. При решении связанных с ними задач элементарные запросы превращаются в неоправданно громоздкие конструкции. Проведём сравнительный анализ структуры SQL запросов к МУОРБД и к реляционной базе данных, на примере базы Раradox. SQL запрос к Раradox о выборке информации из таблицы Individ имеет вид:

Select Individ.id ind, Fam.Fam, Name.Name, SName.SName from Individ

Тот же запрос, привязанный к временным рамкам (выборка информации актуальной к дате 15.08.1999 ):

Fam.Fam, Name.Name, SName.SName

Select Individ.id ind, from Individ

left join Fam on Fam.id ind=Individ.id ind and (Fam.DateWith<'15.08.1999' and

(Fam.DateTo>'15.08.1999' or (Fam.DateTo is null))) left join Name on Name.id ind=Individ.id ind and

(Name.DateWith<'15.08.1999' and (Name.DateTo>'15.08.1999' or (Name.DateTo is null)))

left join SName on SName.id ind=Individ.id ind and

(SName.DateWith<'15.08.1999' and (SName.DateTo>'15.08.1999' or (SName.DateTo is null)))

К МУОРБД аналогичный запрос имеет вид:

Select * from Individ on Date='15.08.1999'

Аналогичная картина и по другим видам запросов:

К Paradox:

Insert into Individ (id ind,BirthDay) values (3 , ' 12.10.1987')

insert into Fam (id ind, Fam,DateWith,TimeWith, Dateto,Timeto) values ( 3 ,'Иванов',' ',' ',' ',' ')

insert into Name (id ind, name,DateWith,TimeWith, Dateto,Timeto) values ( 3 , 'Иван' ,' ',' ',' ',' ')

insert into SName (id ind,sname,DateWith,TimeWith, Dateto,Timeto) values ( 3 , 'Иванович' ,' ',' ',' ',' ')

delete from SName on where id ind=3 delete from Name on where id ind=3 delete from Fam on where id ind=3 delete from Individ on where id ind=3

К МУОРБД

Insert into Individ on (Fam, Name, SName, BirthDay) values('Иванов','Иван','Иванович',' 12.10.1987')

DateWith(' ',' ',' ',' ') --не обязательно

DateTo( ' ',' ',' ',' ') --не обязательно

delete from Individ on where id=3

Запросы update к обоим базам эквивалентны.

Выводы

Проблема удалённости информационного пространства в реляционных базах данных от реального представления установлена и решается давно. Ещё в 90-е годы прошлого столетия, с распространением в компьютерном мире объектно-ориентированного подхода, были предложены решения и для баз данных. Но оперирование динамически изменяющейся информацией в статическом отображении базы данных привело к противоречивости, значительному усложнению и в итоге малой эффективности [2,6,7].

Принципиально новый подход в структурировании информационного пространства МУОРБД на базе многомерной матрицы позволяет надеяться авторам, что это и есть решение данной проблемы [8,9].

71

Литература

1. E.F. Codd. A Relational Model of Data for Large Shared Data Banks. Communications of the ACM,

Volume 13, Number 6, June, 1970.

Перевод на русский язык: Е.Ф. Кодд. Реляционная модель данных для больших совместно используемых банков данных.

2. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management — 3-е изд. — М.: Вильямс, 2003.

3. Аршинов В.И. Событие и смысл в синергетическом измерении. В кн:.Событие и смысл. Синергетический опыт языка (под ред. Киященко Л.П.,ТищенкоП.Д.) М.:ИФ РАН 1999. С. 11 37.

4. Аршинов В.И. Синерегетика как феномен постнеклассической науки. М.:ИФРАН 1999.

5. 5. А.Е.Васильев Развитие логических моделей данных.

6. С.Д. Кузнецов, М.Н. Гринев Ландшафт области управления данными: аналитический обзор. Институт системного программирования РАН

7. С.Д. Кузнецов Объектно-реляционные базы данных: прошедший этап или недооцененные возможности? Труды Института системного программирования, т. 13, часть 2, М., ИСП РАН, 2007,стр. 115-140.

8. Микляев И.А., Матричная универсальная объектно-реляционная база данных, Материалы I Международной научно-практической конференции «Объектные системы - 2010», Россия, Ростов-на-Дону, 10-12 мая 2010г, стр. 34-39.

9. Микляев И.А., Свидетельство ОФЕРНиО №15405 (Объединённого фонда электронных ресурсов «Наука и образование») "Универсальный тип данных баз данных", 2010.

УДК 004.652.5

ORM КАК АНТИПАТТЕРН

Шитов Николай Андреевич, бакалавр информационных технологий, магистрант 1 курса, Ивановский государственный химико-технологический университет, Россия, Иваново,

niko 1989@inbox.ru

Галиаскаров Эдуард Геннадьевич, к.х.н., доцент, Ивановский государственный химикотехнологический университет, Россия, Иваново, galiaskarov@isuct.ru

Введение

Проблема хранения информации была издавна известна человечеству, и за всю историю было найдено множество решений для хранения информации в том или ином виде, пока в 50-х годах прошлого века проблема не вышла на новый уровень - уровень компьютерных технологий. В качестве решения были предложены новые средства хранения данных - базы данных [1], которые в 70-х годах пришли в своем развитии к самому популярному в наше время виду баз данных (БД) - реляционным. Однако появление и последующее развитие объектных средств проектирования и разработки потребовало от разработчиков СУБД адекватной реакции. В результате появилось несколько направлений развития БД:

• создание объектных и объектно-ориентированных БД,

• создание объектных надстроек над реляционными БД (объектно-реляционные БД),

• а также разработка методов объектно-реляционного отображения (ORM).

Рассмотрим последнее направление более подробно.

ORM (англ. Object-relational mapping, рус. Объектно-реляционное отображение) — технология программирования, которая связывает базы данных с концепциями объектноориентированных языков программирования, создавая «виртуальную объектную базу данных» [2]. Потребность в этой технологии, как уже говорилось выше, может возникнуть в случае применения объектного подхода при написании приложения и использовании при

72