Немного_о_структурировании

[dim <dimsmol@rambler.ru>]

Привет, All!

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

Было бы здорово иметь базу, позволяющую хранить произвольного вида
графы и оптимизирующую выборки по ним, в том числе и многослойные, а
XML использовать только как транспорт и средство представления
конечных выборок, с которыми удобно оперировать человеку. Но я не
уверен, что такое существует в природе. Если кто-нибудь слышал про
нечто подобное, или хотя бы про базы, хранящие информацию в
про-предикативной форме - пожалуйста делитесь информацией!      

Спасибо!

PS Гер, как у вас дела?

Привет! :)

--------------------------------------------------------------------
А теперь, собственно, сабж. ;)

XML имеет древовидную, плоскую структуру. (плоскую - потому что любое
дерево можно нарисовать на плоском листе без пересекающихся
соединительных линий)  

Это означает, что любой элемент не может иметь более одного родителя.

Это не совсем удобно, поскольку, вообще говоря, мы можем иметь более
чем один желаемый способ плоского структурирования данных. 

Например, мы можем разбить проекты тематически, древовидно
структурируя темы. Например, вот так: 

<Темы>
        <Музыка>
                <Фольклер>
                        <Проект1/>
                        ...
                        <ПроектN/>
                </Фольклер>
                <Эстрада>
                        <Проект1_/>
                        ...
                        <ПроектN_/>
                </Эстрада>
        </Музыка>
        <Живопись>
                <Проект1__/>
                ...
                <ПроектN__/>
        </Живопись>
</Темы>

В то же время, мы возможно хотим разбить те же самые проекты
регионально. Вот так: 

<Регионы>
        <Россия>
                <ПроектX/>
                ...
                <ПроектZ/>
        </Россия>
        <Другие-страны>
                <Индия>
                        <ПроектX_/>
                        ...
                        <ПроектZ_/>
                </Индия>
                <Китай>
                        <Провинция1>
                                <ПроектX__/>
                                ...
                                <ПроектZ__/>
                        </Провинция1>
                        <Провинция2>
                                <ПроектX___/>
                                ...
                                <ПроектZ___/>
                        </Провинция2>
                </Китай>
        </Другие-страны>
</Регионы>

Понятно, что две данные схемы невозможно представить в одном
XML-файле, не повторяя дважды описание каждого проекта. 

Но мы можем сделать две отдельные XML-базы, содержащие структуры и
один файл, описывающий проекты. При этом листьями структур будут не
элементы-проекты, а элементы-ссылки на проекты, например, такого вида:

<Ссылка-на-проект ИД-проекта="12345"/>

Где ИД-проекта - идентификатор проекта. Понятно, что каждому проекту
понадобится уникальный идентификатор. 

Подобное разделение позволяет нам ввести что-то вроде слоев
наследования. К сожалению, разделение базы ухудшает производительность
и простоту работы, но с этим придется смириться.  

Базы, задающие структуры будем называть носителями структур. Следующий
вопрос - какая информация должна быть выделена в носитель структуры?
Ведь мы могли поместить определитель темы или региона и в каком-нибудь
свойстве проекта. Например так:   

<Проект Тема="Музыка/Фольклер"/>

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

Замечу, что одно и то же свойство может быть как внешним, так и
внутренним. Например, возьмем мир точечных событий, где каждое событие
обладает моментом, в который оно произошло.  

<Событие Произошло="2 миллиона лет назад"/>

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

<Периоды>
        <Недавно>
                ...
        </Недавно>
        <Давно>
                <Не-очень-давно>
                        ...
                </Не-очень-давно>
                <Давненько>
                        ...
                </Давненько>
                <Очень-давно>
                        ...
                </Очень-давно>
        </Давно>
</Периоды>

То никакая иная структура уже не уживется рядом с ними в одном файле,
также имея листьями события.

То есть в носители структуры выделяются внешние свойства (еще раз
напомню: "внешнее" - понятие чисто условное), имеющие собственную
структуру, листьями которой являются центральные объекты базы. В этом
утверждении свойства "внешние" и "листья - центральные объекты"
идентичны. Пример:    

<Проект>
        <Время-начала>
                <День>
                        10
                </День>
                <Месяц>
                        2
                </Месяц>
                <Год>
                        1938
                </Год>
        </Время-начала>
</Проект>

Свойство Время-начала являет собой структуру, но оно внутреннее по
отношению к проекту. Оно является листом проекта. Проект является (в
некотором роде) его внешним свойством.  

Но характер информации может склонять и к другому структурированию,
например такому: 

<Время-начала>
        <День>
                10
        </День>
        <Месяц>
                2
        </Месяц>
        <Год>
                1938
        </Год>
        <Начавшиеся-проекты>
                <Проект1/>
                ...
                <ПроектN/>
        </Начавшиеся-проекты>
</Время-начала>

Здесь Время-начала является внешним свойством. Проекты являются его
листьями. 

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

Не буду долго распинаться о том, что я назвал выше "центральными
объектами", скажу только, что в мастерятнике их будет три вида -
проекты, инструменты и сообщества. Короче, центральный объект - это
то, что в сущности вы собрались описывать.   
-- 
Всего интересного!
 dim                          mailto:dimsmol@rambler.ru


-------------------------------
Геленджик-2002: впечатления и отчеты - 
http://klein.zen.ru/zen-spirit/gelendzhik-2002/index.htm