Como você incorpora conhecimento prévio ou experiência de domínio em seu projeto de modelo hierárquico?

As per my experience domain knowledge plays very important role in terms of defining the hierarchies and taxonomies. You can not define your categories , sub-catagories and lowest level of granular details if you dont know the product structure etc. In most of the cases similar domains follow similar terminologies or taxonomies. I can relate it with Asset management in any utility or oil and gas company.

things that are needed to be known are, if the knowledge is a class, an attribute, and instance of a class, or an instance of an attribute. Classes and attributes can be further classified. But these top level systems, metadata of metadata (The meta-model), should be shallow. Instances of classes or attributes could be metadata. These are metadata built following the meta-model. The relationships between classes can also be defined at the meta-model level, with instances of these at the metadata level. All classes, attributes and relationships can be hierarchical. There are special tools and languages where classes, attributes and relationship can have hierarchical definitions. Be careful not to deep on the any hierarchy.

The first step in creating a hierarchy is to determine the level of granularity that best suits your data and your goal. Depending on the complexity of your data, you may need to establish multiple levels of hierarchy. For example, if you're working with product data, you might have a high-level category hierarchy, such as electronics, clothing, and books, and then further subcategories within each of those. It's important to choose the level of hierarchy that aligns with your understanding of the data and the problem you're trying to solve. By doing so, you can effectively organize and analyze your data to gain valuable insights.

In my SAP BW experience we always have reports with certain dimensions are added with hierarchical representation. Many clients still have materials , product , customer hierarchies. Plant specific materials are also added for better reporting showing granular data at plant level. In inventory or sales reports it is important to have correct hierarchical presentation. Parent and child key relationships are maintained at transactional level which later can be loaded to datawarehouse in the hierarchy and hierarchy text tables. Data is stored at multiple hierarchy levels in tables so summarization of keyfigures can be achieved and can be visualized at different granularity levels.

There are many ways or options to model your parent child relationships if its very simple relation then do not complicate it if its complex relationship then try to create the parent for every child that way it would be very simple to manage. Ex. for root asset you many have 0 parent and for child asset you may have some parent identifier associated with it.

A parent can have a parent. A parent may have children. Children can be the parent of a child. It is very easy to define this using UML and relational data modelling with an inheritance fashion or ownership of the primary key (The primary key can also be inherited). Now, there are other cases where parent and children are not clearly defined or not even defined. A parent can be just an external rule (Ex. Two nodes that are related to one another through a relationship node). Some tools provide relationships between nodes (Ex. A governance tool that holds business terms), hierarchies are defined using the hierarchy relationship. Hierarchies are subjective. Not everything is a hierarchy. Many things are. It depends on perspective.

The next step is to define the parent-child relationships between the nodes in your hierarchy. This involves specifying which node is the parent of which node, and determining how many children a node can have. These relationships capture the logical or semantic connections between the data elements and the rules that govern the hierarchy. For example, if we're modeling employees, we would establish parent-child relationships to indicate who is the manager of whom, and the maximum number of direct reports a manager can have. It's important to consider your prior knowledge and domain expertise when defining these relationships. By doing so, we can accurately represent the structure of the data and effectively analyze it.

attributes can be relationships from a parent node to a child node that is of a certain type (Ex. Person -> First Name -> String, where First Name is the relationship!). The relationship starts from the parent (The entity node). This kind of stuff is true in an ontology using RDF/RDFS. The target nodes for the relationship hold the data - Hopefully, they hold one single value. Attributes, in general, are characteristics or descriptors about the parent node - There can be many. You can say this is also a hierarchy. One has to pay attention what an attribute defines, its specific purpose and the context (The context is the universe of the parent node). A person does not have an account number, but may have a birth date or a first name.

It's important to define the properties or parameters for the node attributes it could be some type of flag or dimension associated with it.

The third step is to assign node attributes to each node in the hierarchy. These attributes describe the characteristics or features of the data elements and the outcomes or objectives you're interested in. For example, if we're modeling customers, we might assign attributes such as demographic information, purchase history, and loyalty status to each customer node. These attributes should align with your prior knowledge and domain expertise, as well as the specific problem you're trying to solve. By assigning relevant attributes, we can gain a deeper understanding of the data and make more informed decisions.

The advantage of your domain expertise or prior knowledge is that you can evaluate how the data modeling is designed to handle all change could happen on domain. So you can validate if the hierarchical model is a good options or not; if it is a good option, to refine in what elements; like parent-child relationship, assign node attributes of table or define the hierarchy level will use; require on the data model to reflect the reality of domain.

Validation of the hierarchy is very important and also it should be verified by the business and take their feedback before releasing it. I think the hierarchy is the backbone for any data project.

When handling complex relationships and cardinalities, consider the implications of performance and scalability. For instance, while normalization reduces redundancy, it can also increase the complexity of queries, especially in a highly relational model. In cases where performance is critical, like in an online shopping system, you might need to selectively denormalize parts of the database or use caching strategies to optimize query performance. Additionally, think about the use of modern database technologies like NoSQL for handling large volumes of unstructured or semi-structured data that might not fit neatly into a traditional relational model.

Below are some of the best practises to be considered. Consistent naming convention Business usability Non-Functional aspect of hierarchy. Usability in reports and multiple places etc.

Incorporating prior knowledge or domain expertise is a critical aspect of ensuring the model's relevance and effectiveness. By combining data-driven insights with domain knowledge, you create a more robust model that accurately represents the underlying structure and semantics of the data. Regular collaboration with experts, validation processes, and iterative refinement contribute to the ongoing success of the hierarchical model. 1.Consider incorporating business rules that govern the relationships and attributes of the data 2.Refine the model to changing data patterns and evolving business requirements 3.Anticipate future changes and scalability requirements