Хранение информации объектных и необъектных сущностей
При выборе прототипов объектов для хранения информации одним из типичных вопросов, возникающих при неочевидных случаях, является выбор между объектными и необъектными данными. Например, между регистром сведений и справочником.
К объектным данным относятся данные справочников, документов, планов видов характеристик, планов счетов, планов видов расчета, бизнес-процессов, задач, планов обмена.
К необъектным данным относятся данные регистров сведений, регистров накопления, регистров бухгалтерии, регистров расчета, перерасчетов, последовательностей и констант.
В рамках текущей темы ограничимся лишь вопросами выбора этих данных для различных задач хранения информации.
Для принятия решения рекомендуется обращать внимание на природу данных предметной области. Если они обладают некоей «самостью», несмотря на смену значений отдельных свойств этого объекта, то предпочтение следует отдавать определению этих данных как объектных.
Например, сотрудник может сменить фамилию, имя, паспорт, цвет глаз и т. д., однако при этом он останется все тем же сотрудником. Таким образом, мы рассмотрели типичный пример идентификации сотрудников предприятия как данных объектных и подлежащих учету посредством справочника.
Однако следует учитывать, что выбор вида объекта конфигурации не должен производиться для каждой сущности отдельно. Необходимо анализировать наличие и остальных сущностей в комплексе всей прикладной задачи. Причем желательно не только на текущий момент, но и с учетом развития задачи в будущем.
|
|
|
Например, состав сотрудников предприятия целесообразно хранить посредством объекта конфигурации Справочник
Однако если взглянуть на проблему шире, может оказаться, что на самом деле тут смешиваются две сущности:
·«Физические лица» как отражение реальных людей, с которыми предстоит иметь дело в рамках решения;
·«Сотрудники подразделений предприятия», причем один и тот же человек может быть сотрудником нескольких подразделений предприятия, выполняя в них различные задачи (должности, круг обязанностей и проч.).
Причем вторая сущность как объект нигде не фигурирует, просто нужно помнить «кто есть кто». Тогда хранение сотрудников подразделений может быть реализовано посредством регистра сведений
Выбор каждого из вариантов хранения информации определяется тем, какую сущность предметной области будет отражать тот или иной объект. При этом разработчикам рекомендуется также и имя объекта определять так, чтобы оно максимально отражало описываемую сущность. Это позволит впоследствии обеспечить правильное восприятие и использование объекта.
|
|
|
Хранение иерархической информации
Иерархическими принято считать структуры, у которых четко прослеживаются отношения «один ко многим». Например, «один руководитель – много подчиненных»
Рис. . Пример одноуровневой иерархии
Кроме того, уровней иерархии может быть больше одного: «один руководитель, в подчинении которого находятся руководители подразделений, в подчинении которых находятся подчиненные» – пример трехуровневой иерархической структуры (рис. 1.22). Ну а в общем случае уровней может быть значительно больше.
Для «экономного» хранения информации об иерархичности хранимых данных достаточно, если каждый из нижестоящих элементов будет помнить ссылку на непосредственно стоящий над ним элемент.
Таким образом, информацию об иерархии можно хранить не только в виде схем, но и в виде таблиц. Например, информация о вышеприведенной схеме может храниться так, как показано в табл. 1.1.
Таблица 1.1. Пример хранения иерархической информации
| Сотрудник | Руководитель |
| Директор | |
| Руководитель отдела закупок | Директор |
| Менеджер по закупкам | Руководитель отдела закупок |
| Товаровед | Руководитель отдела закупок |
| Руководитель отдела продаж | Директор |
| Менеджер по продажам | Руководитель отдела продаж |
| Продавец | Руководитель отдела продаж |
| Секретарь | Директор |
Каждая строка таблицы содержит информацию по одной персоне. Для каждой строки таблицы упоминание некоей персоны в поле Руководитель означает, что данный сотрудник непосредственно подчинен именно этому руководителю (а в информации по этому руководителю будет указано, кому он, в свою очередь, подчинен). В строке, отражающей информацию по директору, поле Руководительпустое. Это значит, что в данной схеме у директора нет руководителей. Еще говорят «директор находится на корневом уровне иерархии».
|
|
|
Данный прием применяется при хранении иерархической информации объектов прикладной области на уровне объектов базы данных системы «1С:Предприятие». То есть «нижестоящие» элементы должны помнить ссылку на «вышестоящие» элементы иерархии.
Однако это не значит, что разработчик в каждом отдельно взятом случае должен «доводить» выполнение этого приема до уровня таблиц базы данных. В типовых ситуациях эту работу берет на себя сама платформа. Разберем, что же это за ситуации.
При разработке бизнес-решений разработчику чаще всего приходится иметь дело с иерархическими структурами при организации хранения условно-постоянной информации (справочники, планы видов характеристик), реже – при работе с регистрацией событий.
|
|
|
В отношении хранения условно-постоянной информации учтены следующие ситуации:
·иерархия объектных данных одной сущности ;
·иерархия объектных данных разных сущностей ;
·хранение иерархии необъектных данных внутри объекта;
·хранение иерархии необъектных данных вне объекта .
В остальных же случаях или для реализации ситуаций иерархии событий разработчик всегда может реализовать свою иерархическую схему посредством добавления реквизита к «подчиненным» объектам, значением которого должна являться ссылка на объект-владелец.
Дата добавления: 2019-02-22; просмотров: 316; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!