Поле связанных структур

"Поле связанных структур"

1. Введение.

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

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

Уже несколько месяцев, а может и лет, в голове бродила идея, к воплощению которой меня подтолкнули эти две задачи. Сходность представленных задач очевидна. Здесь легко выделяются классы обьектов с определёнными атрибутами. Компьютер, Сотрудник, Подразделение ... - для первой задачи. Клиент, Кабель, Шкаф, Кросс, Панель ... - для второй. Объекты между собой взаимодействуют посредством неких связей. Компъютер -> Сотрудник - компъютер у сотрудника, Сотрудник -> Подразделение - сотрудник в подразделении. В результате связного взаимодействия между объектами, могут появиться новые атрибуты. Описав все объекты и все связи между объектами для каждой конкретной задачи, мы получим некую СВЯЗАННУЮ СТРУКТУРУ. Очевидно, что две рассматриваемые задачи разнятся только количеством Классов, Типами связей, и Атрибутами объектов. А если так, то, возможно построить некую общую модель, для хранения и обработки СВЯЗАННЫХ СТРУКТУР. Безусловно будут и специфические моменты в каждой из представленных задач или в задачах вашего плана, но 80 процентов обработки мы сможем описать универсально.

2. Цель проекта.

Любая программа состоит из данных и алгоритмов по их обработке. Мы определим правила описания Классов, Объектов, Связей, создадим их по этим правилам - это наши данные, и представим программу по вводу, редактированию и визуализации данных СВЯЗАННЫХ СТРУКТУР - это наш алгоритм. Следуя правилам описания, мы получим доступ к данным через интерфейс пользователя, который не будет нуждаться в правке исходного кода при переходе от одной предметной области к другой. Ключевой момент при проектировании новой задачи - определить Объекты, Связи, их Атрибуты, и описать это всё в Базе Данных по определенным ниже правилам. Мы не будем накладывать никаких ограничений на количество и характер связей между объектами. Их будет ровно столько, сколько вы определите как постановщик. Они будут осуществляться между теми объектами, между которыми вы захохоите. Тип связи (1 -> N, M -> N) - любой. Одни и те же связи не обязательно должны присутствовать во всех объектах класса. Мы обеспечим исходный доступ к графу связей с любой вершины - для любого класса.

3. Способ реализации.

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

3.1. Хранение данных в таблицах реляционной структуры БД.

Ядро системы состоит их трех таблиц:

• class - данные о классах объектов и ссылок
• object - объекты
• link - данные о связях между объектами

Это основные таблицы. Если бы мы работали с объектами, которые имели бы только один атрибут, а связи не имели атрибутов вообще, то этих трёх таблиц было-бы достаточно для реализации усечённой задачи. Но, такое бывает редко. А поэтому вся дополнительная информация об атрибутах объектов хранится в таблицах вида:

количество таблиц определяется количеством классов объектов.

Вся дополнительная информация об атрибутах связей хранится в таблицах вида:

количество таблиц определяется количеством классов ссылок имеющих атрибуты.

3.2. Синтаксические правила описаний.

Именование классов объектов (значение поля mnemo таблицы class).

• Наименование классов объектов не должно содержать символа "_" подчеркивания. Данный символ используется как разделитель в наименованиях классов ссылок.

Именование классов ссылок (значения поля mnemo таблицы class).

• Наименование классов ссылок должно начинаться с ключевого слова Link_ за которым, через символ "_" подчеркивания идут наименования связанных классов объектов.

3.3. Описание атрибутов классов.

Поле attrfields таблицы class содержит описание атрибутов класса объектов, или атрибутов класса связей. Значение этого поля предстваляем собой список списков, в терминах языка программирование tcl. Для тех кто не сталкивался с данным языком - ничего страшного в этом нет. В двух словах: в списке значение одного поля заключено в фигурные скобки {}. Если значение состоит из одного слова, для простоты фигурные скобки опускаются. К примеру описание "{1 2 3} {1 2 3}" означает, что данные состоят из двух обьектов, которые состоят из трёх полей.

Attrfields состоит из списка, каждый элемент списка - описание одного атрибута класса. Каждое описание атрибута класса, в свою очередь, также состоит из списка с минимумом в 3 поля и максимумом 5 полей.

3.4. Описание свойств классов.

Поле properties таблицы class содержит описание свойств класса объектов, или атрибутов класса связей. Значение этого поля предстваляем собой список списков, в терминах языка программирование tcl. Для тех кто не сталкивался с данным языком - ничего страшного в этом нет. В двух словах: в списке значение одного поля заключено в фигурные скобки {}. Если значение состоит из одного слова, для простоты фигурные скобки опускаются. К примеру описание "{1 2 3} {1 2 3}" означает, что данные состоят из двух обьектов, которые состоят из трёх полей.

Properties состоит из списка, каждый элемент списка - описание одного свойства класса. Каждое описание свойствакласса, в свою очередь, также состоит из списка с двумя полями. Первое поле - наименование свойства, второе поле - список значений данного свойства. На данный момент обрабатывается только свойство classictree.

3.4.1. Описание свойства класса обьектов - classictree.

Свойство класса объектов classictree описывается двумя значениями, смысл которых описан в таблице

Например:
Если вы хотите что бы класс Division выводился в виде дерева (подразделение, подподразделение, ...), чтобы сотрудники были привязаны только к последнему подподразделению, то необходимо установить значение поля properties в {classictree {1 1}}.

4. Толкование на примере.

Рассмотрим применение данного метода для решения задачи автоматизации учёта пользователей корпоративной сети.

4.1. Определение классов объектов и классов связей.

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

Допустим, что учёту подлежат следующие классы объектов:

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

Данные рассуждения ложатся на представленную ниже блок-схему:

Схема к поясняющему примеру

4.2. Ввод данных в таблицу классов.

Следующий этап - ввод данных в таблицу классов.

          + Ввод данных о классах объектов:
      
              insert into class 
                values(1, 'Building', 'Здание', '', '', \
                       '{name Наименование 30} {address Адрес 64}', '');
        
              Поясню смысл значения последнего поля '{name Наименование 30} {address Адрес 64}':
              Это поле описывает два атрибута класса Building:
                Атрибут name с наименованием для пользовательского интерфейса
              'Наименование' имеет визуальную длину 30 символов.
                Атрибут address с наименованием для пользовательского интерфейса 
              'Адрес' имеет визуальную длину 64 символа.
                Имена name и address - это наименование полей в виде (view) который 
              мы будем создавать в следующем параграфе этой статьи.
          
              insert into class 
                values(2, 'Computer', 'Компьютер', '', '', \
                       '{name Наименование 30} {cpu Процессор 20} {ram Память 10} {os ОС 20}', '');
    
              . . .
      
              По образу и подобию вводим все данные о классах объектов.
    
    
          + Ввод данных о классах связей:
    
              insert into class 
                values(500, 'Link_Building_Computer', 'Компьютер в здании', '', '', \
                       '{floor Этаж 2} {room Комната 3}');
              insert into class 
                values(501, 'Link_Building_NetEquipment', 'Сетевое оборудование в здании', '', '', \
                       '{floor Этаж 2} {room Комната 3}');
    
              . . .
      
               По образу и подобию вводим все данные о классах связей.
    

4.3. Создание таблиц атрибутов.

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

          + Создание таблиц для классов объектов:
                
              create table attr_computer
              (
                object_id   integer unique not null references object(id),
                cpu         char(20),
                ram         char(10),
                os          char(20)
              );            
    
              . . .
                    
              По образу и подобию создаем прочие таблицы.
    

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

          + Создание таблиц для классов ссылок:
    
              create table attrl_building_computer
              (
                link_id   integer unique not null references link(id),
                floor     smallint,
                room      char(5)
              );
    
              . . .
            
              По образу и подобию создаем прочие таблицы.
    

4.3. Создание видов.

Теперь необходимо создать виды(view) для доступа к классам объектов и ссылок. Определим, что наименования видов(view) на классы объектов будут начинаться с v_, а на классы связей с vl_. Суффикс наименования видов(view) берем из названия класса.

          + Создание видов для классов объектов:
    
              create view v_computer as 
                select a.id as id, 
                       a.name as name,
                       b.cpu as cpu, 
                       b.ram as ram, 
                       b.os as os
                  from object a, attr_computer b
                  where a.id = b.object_id and
                        a.class_id = (select id from class where mnemo = 'Computer');
    
              . . .
            
              По образу и подобию создаем прочие виды для классов объектов.
    
    
          + Создание видов для классов ссылок:
    
              create view vl_building_computer as 
                select a.id as id, 
                       a.left_id as building_id,
                       a.right_id as computer_id,
                       b.floor as floor,
                       b.room as room
                  from link a, attrl_building_computer b
                  where a.id = b.link_id and
                        a.class_id = (select id from class where mnemo = 'Link_Building_Computer');
    
              . . .
            
              По образу и подобию создаем прочие виды для классов ссылок.
    

5. Программа Krp.

Программу "Krp" реализующую данную концепцию, можно скачать по адресу: http://doro.poltava.ua/prgfree/krp.html