Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.

...

Sv translation
languageen

The facility library contains all facility types, their respective properties and meanings. 

Properties of facility types will be passed on to subordinate ones. That's why it's important to build a library that wisely utilizes this inheritance system.

We'll be talking about some important aspects in form of a best practice that will help you with the management of the facility library.

Inhalt
maxLevel1


Rules for the creation of types, meanings and properties

As general as possible and as specific as necessary

Designing all facility types and their elements as general as possible means that they can fit as many scopes as possible. A type, its properties and meanings should, for example, be build to apply to various facilities. Such a structure enables the usage of a facility type for many facilities and an easy inheritance of properties to subordinate facility types.

However, the facility types and their elements should also be modeled as specific as possible. They should be used in an universal way but still be specific enough to optimally match the requirements of their scope.

Example: The facility type "Room" can be used for various facilities without any special requirements, e.g. offices. However, there also are more specific types such as "Cooling chamber" that suite facilities suit facilities that need additional properties to evaluate data. 

Check the necessity of a new type!

Some facilities require specific properties that are not covered by other types and therefore need their own type. A new type should only be created if that's the case and no other type matches the facility's requirements!

Example: The type "Equipment" has many properties that fit various different devices. That's why it can be used for a lot of facilities. It would only be necessary to create a new type if additional properties are needed that don't fit "Equipment" and its sub-types. For example "Type of coffee beans" for a coffee machine facility. 

Use the inheritance wisely!

Properties are passed down from higher-ranking to subordinate facility types. Like this, general properties can be reused at specialized types. That's why they should properties should be assigned as high as possible. 

Example: The facility type "Electricity meter" requires the property "Meter number". This property is also used by the higher-ranking type "Meter" and all of its other subordinate facility types. However, it would probably make no sense to add this property to "Equipment", because not all of its sub-types would use it. "Meter number" should therefore be used by the type "Meter" so it can reasonably be passed down to its sub-types.

Use meanings to separate data!

If it's necessary to separately aggregate data, you'll also need different meanings.

Example: In most cases, it does make sense to separately evaluate load profiles for gas and electricity. The meaning "Load profile" could of course be used for both, but then it would this would make it impossible to separate the data, especially at higher-ranking facilities. If there is a need for separate aggregation, like in this case, separate meanings should be used. 



Tips for properties

Group up properties reasonably!

A reasonable grouping of properties tidies up the property page of a facility and helps the user to add new properties and assign them correctly. All properties without a group will automatically be grouped up under "General information".

Example: The facility type "Equipment" enables you to add a lot of information about your appliances as properties. All technical data and the dimensions of the device have their own groups.

Simplify the search for facilities! 

If a property is marked as "searchable", its associated facility can be found in QBRX via the search functionglobal filter. Properties should be marked as "searchable" if they are helpful for the search for facilities. However, not every property fits these criteria. Some are too unspecific and a search for them would deliver too many results. The function should therefore only be used for properties whose values are typical for their respective property, like a postal or a telephone number.

Example: Addresses of sites are reasonable, searchable properties, because it could be easier for the user to look for the address of a shop than for its name. The manufacturer of equipment could also be searchable due to the fact, that a search for identically structured devices could be helpful. However, it would not make sense to look for the weight of a device, because such a numeric value is not specific enough and would just deliver too many, incoherent results. 



Tips for a reasonable naming

Choose consistent and clear names!

A definite naming makes it easier for the user to choose the right facility types and its elements and to filter them. Previously set conventions should hold on to to ensure a certain consistency. 

An appropriate agreement should be created beforehand and written down in a documentation.

Avoid acronyms!

Some acronyms are well known and understood by almost everybody, for example "e.g.". However, there are also acronyms that seem to be practical but fail to work in reality due to their unfamiliarity and ambiguity. More problems are cause than solved by them. Not everybody knows the acronym "NTH" for "nice to have". It could also mean "nothing" or "no therapy helpful". 

If in doubt, leave it out! It's always safer to assume that the meaning of an acronym is unknown.