There are many things you can use references for. One of those things is building hierarchical data structures. This is what we will be talking about in this episode.
So, what the hierarchy is? Hierarchy is when a bunch of data items are in one-to-many relationships with each other so that they form a kind of tree-like structure.
Every data item in a hierarchy can have any number of children and one (and only one) parent.
Parents do not remember who their children are, meaning they do not store the children references list or something. Instead, each child remembers its parent - stores its reference.
Are there any hierarchies in our application already? Of course. Let's take the Brands and Products catalogs relationships. Each Product belongs to a single Brand. Let's ask the Platform to find all references to the Coca-Cola brand, and here we go: tree-like structure, single parent, many kids - textbook example.
This hierarchy is built using a regular attribute of a reference type. Very flexible, but requires some maintenance in terms of referential integrity, as you might remember from the last episode. Besides that, the Platform supports a number of standard hierarchies, each of which is aimed at one specific task. All of these built-in hierarchies support automatic referential integrity maintenance, so it makes them even easier to work with.
These built-in hierarchies are the internal data object hierarchy, the ownership hierarchy, the folder-item hierarchy and the item-item hierarchy.
Let's start with the first one: the internal data object hierarchy.
We use this type of hierarchy to store additional tabular information inside of a data object. Here is a textbook example of this approach: Sales documents storing the list of products sold. Each document can have any number of records in this table, and each record of the table belongs to a single document.
To implement this kind of hierarchy, we use tabular sections. Every catalog and every document can have as many of them as it needs. The thing about tabular sections is that they live inside of the data object. Well, physically, they live in different tables in the database, of course. But the Platform treats them as if they were an integral part of the object they belong to. And any object for the Platform is an atomic, indivisible entity. The Platform reads and writes each object as a whole.
So there is no way, for example, of somehow inserting a new product into this Sales document.
We need to read the entire document first, then add a new line, and then write the entire document back to the infobase.
Another effect of the object's atomicity is that we cannot refer to any part of it from another object. Including any of these records. They are not objects, and they don't have a unique Ref attribute. So, we can refer only to the object as a whole.
This atomicity thing really narrows down what we can use this type of hierarchy for. Mostly, we use it for the lists inside of the documents. Sometimes we might use it to store some additional tabular information in catalog objects, but this doesn't work out all the time. For example, there is no way we can use it for Brands - Products pair, because if Products is not a separate catalog, but a tabular section inside of the Brands catalog, we cannot refer to the Products anymore.
OK, next one: the ownership hierarchy.
Catalogs can be owned by other catalogs. When one catalog owns another one, it means that the subordinate catalog's items make no sense without the owner item.
A good example of this type of relationship is a Company - Agreement pair. Let's say, I want to keep track of my contractual obligations to my product suppliers. And, more importantly, keep track of their obligations to me.
So, I'm going to create the Companies catalog first. I'm going to use the Description standard attribute to store the company name; I also need to know the business number and two addresses - the official and the physical ones.
Now I'm going to create the Agreements catalog and here is the thing. I need each agreement to belong to one specific company, right? So I could add a Company attribute and make it point at the Companies catalog like this. But the Agreement doesn't make much sense without the Company it was signed with. So, I'll need to write some code to make sure there are no Agreements without Companies, and when the Company is deleted, all its Agreements get deleted along with it.
It's all doable, no problem, but I'd rather add a Company catalog as an Owner of the Agreement catalog just like this. What happens at this moment is that another standard attribute called Owner appears here in the list.
Note that it looks like you can choose as many owners as you want, but that's not the case. First of all, you cannot choose the same catalog and you will get this error message if you try. Second of all, you can choose any number of other catalogs, but it won't mean that one agreement can have many owners. There is only one Owner standard attribute. And it can have the only value. But the value can be of any of these types. So, what it does, it makes the Owner attribute a composite-type one, that's it.
Let's add the rest of Agreement attributes and see how it works. I'm going to use a standard Code attribute to store the agreement number. I also need to remember the agreement date and its full text.
Now I'm adding these two catalogs to the Lists subsystem, and here they are in the application.
Now I'm going to add my primary food supplier - the Infinity Foods company. And, as you can see, the Company form already has the Agreements link in it. So, I'm clicking it and creating our Master Agreement. OK. Now, if I go to the Agreements and open the one I just created, I'll see the Infinite Foods company in its Owner field. If I try to create a new agreement without specifying the company, I'll get the error message like this one. So, I'm selecting the company, and now I have two agreements belonging to the same owner. If I go and delete the owner, both agreements will be deleted automatically.
So, this is how the Ownership hierarchy works.
Now, to Folder-Item hierarchy.
We use this hierarchy type to group catalog items into folders. This one is pretty straightforward and lives right inside the Catalog itself.
If I select this check box, another couple of standard attributes will appear in this list: Parent and IsFolder. The first one is to point from child to parent and the second one is to tell folders from items.
You can limit the depth of the hierarchy if you want. And this is what our Products catalog now looks like.
We have the Create group button right here, so let's click it and create the Pops group and the Diet Pops subgroup inside of it.
We can drag and drop items into groups like this, or specify a group in the item form like this. And, or course, if we delete the group, all its items will be deleted too.
It's not mandatory for an item to be inside of a group, so there might be these orphan items that live here on the top level.
And the last one - the Item-Item hierarchy. We use this one when children compose the parent, or, if you look at it from the parent's perspective, the parent consists of all its children.
The classic example of this type of hierarchy is an organizational structure. The Company consists of Departments; each Department consists of Divisions, etc. All items have the same type (they all are organizational units), but they put one into another like Russian dolls.
In our application, we could use this type of hierarchy to divide Agreement into smaller pieces: supplemental agreements, addendums, protocols and that kind of things. All of them are agreements, so they have to live in the same catalog. But some of them, as lawyers say, "are executed pursuant to" others. Which in normal-people English means that they are integral parts of others, so they form the Item-Item hierarchy.
This is also done right here on the Hierarchy tab. So, I'm selecting this check box and saying that I want the Items hierarchy without the limit on the number of levels. Let's see what it will look like.
I'm recreating my Infinity Foods supplier, and now I can create a tree-like structure of my agreements with it.
So, these were the hierarchical data structures in 1C:Enterprise. In the next episode we'll talk about Code, Number, and Autonumbering.