In der Facility-Bibliothek sind alle Facility-Typen, dazu gehörige Eigenschaften und Meanings hinterlegt. Damit das System der Facility

-Bibliothek funktioniert, welches vor allem von intelligenten Vererbungen innerhalb der Eigenschaften, die an Facility-Typen profitiert, hinterlegt sind, werden in der Hierarchie nach unten hin vererbt. Deshalb ist es wichtig, dass die Bibliothek effizient verwaltet wirdso aufzubauen, dass diese Vererbung sinnvoll genutzt werden kann. 

Deshalb In diesem Artikel besprechen wir in diesem Artikel in Form eines Best-Practice die wichtigsten Aspekte, die bei der Verwaltung der Facility-Bibliothek zu beachten sind. 

Regeln zum Anlegen von Typen, Meanings und Eigenschaften

So allgemein wie möglich und so spezifisch wie nötig

Alle Facility-Typen und ihre Elemente so allgemein wie möglich zu gestalten, bedeutet, dass sie für so viele Anwendungsfälle wie möglich einsetzbar sind. Das heißt, dass zum Beispiel ein Typ so gestaltet sein muss, dass seine dazugehörigen Properties und Meanings auf so viele Facilities wie möglich übertragbar sind. Durch einen solchen Aufbau kann der Facility-Typ für viele Facilities genutzt werden und gleichzeitig problemlos Eigenschaften an zahlreiche untergeordnete Facility-Typen vererben. 

Die Facility-Typen und ihre Elemente sollten dennoch so spezifisch wie nötig beschrieben werden! Sie sollten zwar universell einsetzbar, aber trotzdem so spezifisch gestaltet sein, dass sie optimal zu ihrem Anwendungsbereich passen.

Beispiel: Beim Einrichten einer Facility für ein Büro ist es möglich, den Typen Der Typ "Raum" zu verwenden, da dieser ist so allgemein gestaltet istgehalten, dass er zu allen Räumen ohne spezielle Anforderungen passt. Ein Facility für einen Kühlraum bringt jedoch unter Umständen besondere Anforderungen mit sich, weshalb es notwendig ist, einen spezifischeren Typen zu verwendenfür eine Vielzahl an Facilities verwendet werden kann, die keine besonderen Anforderungen haben, wie zum Beispiel Büros. Es gibt jedoch auch spezifischere Raum-Typen wie "Kühlraum", die für Facilities geeignet sind, die spezielle Eigenschaften für die Auswertung ihrer Daten benötigen. 

Kontrolliere, ob ein neuer Typ wirklich notwendig ist!

Einige Facilities sind so spezifisch, dass es notwendig ist, einen eigenen Typen für sie anzulegen, weil sie Einstellungen Eigenschaften benötigen, die so nicht durch andere Typen abgedeckt werden. Ist dies nicht der Fall, sollte kein neuer Facility-Typ angelegt werden! 

Beispiel: Soll eine Kaffeemaschine als Facility angelegt werden, ist es durchaus möglich, dass alle dafür notwendigen Eigenschaften wie "Hersteller"  oder "Garantie bis" bereits am Am Typen "Equipment" hinterlegt sind. Daher kann dieser Facility-Typ für die Kaffeemaschine benutzt werden. Wird eine neue Eigenschaft benötigt, wie zum sind zahlreiche Eigenschaften hinterlegt, die auf eine Vielzahl an unterschiedlichen Geräten passen. Deshalb kann dieser Typ für viele Geräte verwendet werden. Es wäre erst dann nötig, einen neuen Typen anzulegen, wenn zusätzliche Eigenschaften an einer Facility benötigt werden, die noch nicht an "Equipment" hinterlegt sind und nicht zu "Equipment" oder dessen untergeordneten Typen passen. Zum Beispiel "Sorte der Kaffeebohnen" , kann ein neuer Typ angelegt werden.bei einer Facility für eine Kaffeemaschine. 

Nutze die Vererbung weise!

Eigenschaften werden immer von übergeordneten an untergeordnete Facility-Typen vererbt. So können allgemeine Eigenschaften an speziellen Typen wiederverwendet werden. Deshalb sollten Sie sie so weit oben wie möglich in der Hierarchie eingesetzt werden. 

Beispiel: Beim Facility-Typen "Elektrozähler" wird die Eigenschaft "Geeicht bisZählernummer" benötigt. Diese Eigenschaft findet aber auch am übergeordneten Typen "Zähler" und all seinen anderen untergeordneten Facility-Typen Verwendung. Es ergibt jedoch keinen wenig Sinn, die Eigenschaft beim Typen "Equipment" zu verwenden, da sie nicht für alle dort untergeordneten Typen giltsinnvoll ist. "Geeicht bisZählernummer" sollte demzufolge beim höchstmöglichen Typen "Zähler" angebracht werden, da es sinnvoll auf alle untergeordneten Typen vererbt werden kann. 

Nutze Meanings um Daten zu separieren!

Wenn es notwendig ist, Daten separiert voneinander zu aggregieren, werden auch separate getrennte Meanings benötigt. 

Beispiel: In den meisten Fällen ist es notwendig, die Lastgänge vom Erdgas und der Elektrizität getrennt voneinander auszuwerten. Natürlich könnte man für beides das Meaning "Lastgang" benutzen, aber dann wäre es nicht möglich, die Daten auch in übergeordneten Facilities voneinander zu unterscheiden. Da ein Bedarf daran besteht, die Lastgänge getrennt voneinander zu betrachten, ist es auch sinnvoll, separate Meanings anzulegen.

Hinweise zu Eigenschaften 

Gruppiere Eigenschaften sinnvoll!

Eine sinnvolle Gruppierung von Eigenschaften macht die Eigenschaftenseite Eigenschaftsseite an Facilities übersichtlicher, hilft dem Nutzer dabei, diese einzutragen und erleichtert die Zuordnung. das Verständnis. Alle Eigenschaften, die keiner Gruppe zugeordnet werden, werden automatisch der Gruppe "Allgemeine Angaben" zugeordnet.

Beispiel: Beim Facility-Typen "Equipment" können zahlreiche Angaben zu den Ausrüstungsgegenständen als Eigenschaft hinterlegt werden. Allgemeine Angaben wie der Hersteller oder die Inventar Nummer werden in einer Gruppe zusammengefasst, ebenso wie alle technischen Technischen Daten und die Abmessungen des Geräts . Das macht es für den Nutzer übersichtlicher und hilft ihm dabei, Daten zu finden und zuzuordnen.haben jeweils eine eigene Gruppe. 

Vereinfache die Facility-Suche!

Ist eine Eigenschaft als "searchable" markiert, kann deren zugehörige Facility in QBRX über die Suche gefunden werden. Eigenschaften sollten als "searchable" markiert werden, wenn sie dabei helfen, Facilities zu finden. Es sollte jedoch nicht jede Eigenschaft markiert werden, da sonst unnötig viele Suchergebnisse geliefert werden. Die Funktion sollte auch nur bei Eigenschaften verwendet werden, deren Wert eindeutig von anderen unterscheidbar isttypisch für eine bestimmte Eigenschaft ist, wie zum Beispiel eine Postleitzahl oder Telefonnummer.

Beispiel: Adressen von Standorten sind sinnvolle, suchbare Eigenschaften, da der Nutzer manchmal eher die Adresse eines Ladens zur Verfügung hat, statt dessen Nummer. Auch der Hersteller von Ausrüstungsteilen ist eine Eigenschaft, nach der zum Beispiel gesucht werden kann, um baugleiche Geräte zu finden. Es wäre jedoch nicht sinnvoll, das Gewicht eines Objektes als "searchable" zu markieren, da eine Zahl als Wert ein solcher Zahlenwert nicht eindeutig genug ist und zu viele, zusammenhanglose Ergebnisse liefern könnte. 

Tipps zur Benennung

Namen konsistent und eindeutig wählen!

Eine eindeutige Benennung erleichtert es dem Nutzer, den richtigen Facility-Typen und dessen Elemente auszuwählen und danach zu filtern. Dabei sollte man sich an vorher festgelegte Konventionen haltengehalten werden, um eine gewisse Konsistenz zu gewährleisten.

Damit diese eindeutig und konsistent benannt werden, Es sollte vorher eine dementsprechende Einigung getroffen werden, die in einer Dokumentation festgehalten wird. 

Abkürzungen vermeiden!

Es gibt Abkürzungen, die allgemein bekannt sind und von jedem verstanden werden, wie zum Beispiel "z.B.". Es gibt allerdings auch Abkürzungen, die zwar praktisch erscheinen, aber aufgrund ihrer Unbekanntheit oder Doppeldeutigkeit mehr Probleme verursachen als lösen. Nicht jeder kennt die Abkürzung "NTH" für "nice to have". Stattdessen könnte sie auch als "Nothing" oder "No Therapy Helpful" gedeutet werden. 

Im Zweifelsfall sollte immer davon ausgegangen werden, dass die Bedeutung einer Abkürzung nicht bekannt ist!

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

Properties of the facility library and the inheritance of types works best if types will be passed on to subordinate ones. That's why it's efficiently build and managed.important to build a library that wisely utilizes this inheritance system.

WeThat's why 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.

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. This mans that a type and 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 lots of 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 a facility that should represent an office, because it is designed to match all rooms various facilities without any special requirements, e.g. However, a facility for a cooling chamber might come with certain specifications that require a more specialized type.

offices. However, there also are more specific types such as "Cooling chamber" that suit facilities that need additional properties to evaluate data. 

Check the necessity of a new type!

Some facilities are so require specific that they need their own type, because they require settings that 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: A new facility for a coffee machine needs properties like "Manufacture" and "Warranty until" that are covered by the The type "Equipment" . So this type could easily has many properties that fit various different devices. That's why it can be used for a coffee machinelot of facilities. It would only be necessary to create a new type if a special property is needed, e.g. 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 on down from higher-ranking to subordinate facilitiesfacility types. Like this, general properties can be reused at specialized types. That's why they should properties should be used assigned as high as possible. 

Example: The facility type "Electricity meter" requires the property "Calibrated untilMeter number". This property is also used by the higher-ranking type "Meter" and all of its other subordinate facility types. However, it would not probably make no sense to add this property to "Equipment", because not all of its sub-types would use it. "Calibrated untilMeter number" should therefore be used by the highest possible 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 separate 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-ranked 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. General information like the manufacturer ir the inventory number are grouped up, just like all technical data and the dimensions of the device. . 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 global 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.