Best Practices for Designing Models - Revision history

Ollvihe: /* Usability in dashboarding */

2022-03-31T09:35:06Z

Usability in dashboarding

← Older revision		Revision as of 09:35, 31 March 2022
Line 15:		Line 15:
	* When new data is loaded into the model, it will become progressively slower to use. If the oldest data in the model is not shown by dashboards, it's recommended to remove it from the model at the same time when new data is loaded. The old data may be stored to an archive model, if it's still needed in some situations.		* When new data is loaded into the model, it will become progressively slower to use. If the oldest data in the model is not shown by dashboards, it's recommended to remove it from the model at the same time when new data is loaded. The old data may be stored to an archive model, if it's still needed in some situations.

	== Usability in dashboarding ==		== Usability for dashboarding ==
	* Use concise names for event types, as shorter names are easier to read by users and they also provide slightly better performance. This is also valid for case and event attributes values. For the readability, it's also better that if there are names that are close to each other, the differences would be in the beginning of the name rather than in the end, as the ending may be cropped out if there is lack of screen space.		* Use concise names for event types, as shorter names are easier to read by users and they also provide slightly better performance. This is also valid for case and event attributes values. For the readability, it's also better that if there are names that are close to each other, the differences would be in the beginning of the name rather than in the end, as the ending may be cropped out if there is lack of screen space.
	* Use the model description to document any relevant details regarding the model for other users. For example, meaning of the event types and case/event attributes is definitely not obvious for other users but also perhaps not for the author itself after some time. The model description field can be found in the [[QPR_ProcessAnalyzer_Project_Workspace#Editing_Model_Settings\|Model Properties dialog]].		* Use the model description to document any relevant details regarding the model for other users. For example, meaning of the event types and case/event attributes is definitely not obvious for other users but also perhaps not for the author itself after some time. The model description field can be found in the [[QPR_ProcessAnalyzer_Project_Workspace#Editing_Model_Settings\|Model Properties dialog]].
	* When data is sorted their data types are important, for example numerical data is sorted by the number values, where as strings are sorted alphabetically. The difference is, for example when sorting numbers 9 and 10 ascending, the 9 is before 10, but if data is stored as strings, the "10" is before "9". If strings need to be in specific order, this needs to be taken into account when formatting data. For example the string values can be prefixed with an order number. The previous example with 9 and 10 can be worked around by storing string values "09" and "10".		* When data is sorted their data types are important, for example numerical data is sorted by the number values, where as strings are sorted alphabetically. The difference is, for example when sorting numbers 9 and 10 ascending, the 9 is before 10, but if data is stored as strings, the "10" is before "9". If strings need to be in specific order, this needs to be taken into account when formatting data. For example the string values can be prefixed with an order number. The previous example with 9 and 10 can be worked around by storing string values "09" and "10".

Ollvihe: /* Usability in dashboarding */

2022-03-31T09:34:46Z

Usability in dashboarding

← Older revision		Revision as of 09:34, 31 March 2022
Line 18:		Line 18:
	* Use concise names for event types, as shorter names are easier to read by users and they also provide slightly better performance. This is also valid for case and event attributes values. For the readability, it's also better that if there are names that are close to each other, the differences would be in the beginning of the name rather than in the end, as the ending may be cropped out if there is lack of screen space.		* Use concise names for event types, as shorter names are easier to read by users and they also provide slightly better performance. This is also valid for case and event attributes values. For the readability, it's also better that if there are names that are close to each other, the differences would be in the beginning of the name rather than in the end, as the ending may be cropped out if there is lack of screen space.
	* Use the model description to document any relevant details regarding the model for other users. For example, meaning of the event types and case/event attributes is definitely not obvious for other users but also perhaps not for the author itself after some time. The model description field can be found in the [[QPR_ProcessAnalyzer_Project_Workspace#Editing_Model_Settings\|Model Properties dialog]].		* Use the model description to document any relevant details regarding the model for other users. For example, meaning of the event types and case/event attributes is definitely not obvious for other users but also perhaps not for the author itself after some time. The model description field can be found in the [[QPR_ProcessAnalyzer_Project_Workspace#Editing_Model_Settings\|Model Properties dialog]].
	* When data is sorted, their types ~~matter, i.e.~~, numerical ~~values are~~ sorted by ~~their~~ values, where as strings are sorted alphabetically. ~~There~~ is ~~a difference~~, for example when sorting numbers 9 and 10 ascending the 9 ~~in first~~, but if ~~they are~~ stored as strings, the "10" is ~~first~~. ~~So if string values~~ need to be in specific order ~~other than alphabetical~~, this needs to be taken into account ~~in the naming~~. For ~~textual values,~~ the values can be prefixed with an order number. The previous example with 9 and 10 can be worked around by storing string values "09" and "10".		* When data is sorted their data types are important, for example numerical data is sorted by the number values, where as strings are sorted alphabetically. The difference is, for example when sorting numbers 9 and 10 ascending, the 9 is before 10, but if data is stored as strings, the "10" is before "9". If strings need to be in specific order, this needs to be taken into account when formatting data. For example the string values can be prefixed with an order number. The previous example with 9 and 10 can be worked around by storing string values "09" and "10".

Ollvihe: /* Performance improvements */

2022-03-30T23:37:20Z

Performance improvements

← Older revision		Revision as of 23:37, 30 March 2022
Line 9:		Line 9:
	* All datatypes support ''null'' values to mark missing or not existing value. The null value can be used to mark anything – its meaning is just a matter of decision. For not existing numerical values, using null is better than zero, as nulls are ignored in calculations (such as in average). Note that strings can also contain the empty string value, which is different than the null value. In addition, booleans can actually contain three values: true, false and null.		* All datatypes support ''null'' values to mark missing or not existing value. The null value can be used to mark anything – its meaning is just a matter of decision. For not existing numerical values, using null is better than zero, as nulls are ignored in calculations (such as in average). Note that strings can also contain the empty string value, which is different than the null value. In addition, booleans can actually contain three values: true, false and null.

	== Performance ~~improvements~~ ==		== Performance optimization ==
	* Include to the model only those case and event attributes that are used in the dashboards, because loading the model is slower and it uses more memory, when there are more attributes. For advanced analysis, such as finding root causes and clustering, more attributes maybe useful, but not for dashboards using only the specified attributes. The calculation performance itself doesn't deteriorate, even though the number of attributes increase.		* Include to the model only those case and event attributes that are used in the dashboards, because loading the model is slower and it uses more memory, when there are more attributes. For advanced analysis, such as finding root causes and clustering, more attributes maybe useful, but not for dashboards using only the specified attributes. The calculation performance itself doesn't deteriorate, even though the number of attributes increase.
	* Include only those event types to models, that are needed by the dashboards and analyses. The more there are events, the more model loading takes, the more model uses memory, and the more calculations take. Event types can be excluded using filters, improving the measure calculation performance similar to corresponding smaller model, but on the other hand calculating the the filter take time.		* Include only those event types to models, that are needed by the dashboards and analyses. The more there are events, the more model loading takes, the more model uses memory, and the more calculations take. Event types can be excluded using filters, improving the measure calculation performance similar to corresponding smaller model, but on the other hand calculating the the filter take time.

Ollvihe: /* Performance */

2022-03-30T23:36:54Z

Performance

← Older revision		Revision as of 23:36, 30 March 2022
Line 9:		Line 9:
	* All datatypes support ''null'' values to mark missing or not existing value. The null value can be used to mark anything – its meaning is just a matter of decision. For not existing numerical values, using null is better than zero, as nulls are ignored in calculations (such as in average). Note that strings can also contain the empty string value, which is different than the null value. In addition, booleans can actually contain three values: true, false and null.		* All datatypes support ''null'' values to mark missing or not existing value. The null value can be used to mark anything – its meaning is just a matter of decision. For not existing numerical values, using null is better than zero, as nulls are ignored in calculations (such as in average). Note that strings can also contain the empty string value, which is different than the null value. In addition, booleans can actually contain three values: true, false and null.

	== Performance ==		== Performance improvements ==
	* Include to the model only those case and event attributes that are used in the dashboards, because loading the model is slower and it uses more memory, when there are more attributes. For advanced analysis, such as finding root causes and clustering, more attributes maybe useful, but not for dashboards using only the specified attributes. The calculation performance itself doesn't deteriorate, even though the number of attributes increase.		* Include to the model only those case and event attributes that are used in the dashboards, because loading the model is slower and it uses more memory, when there are more attributes. For advanced analysis, such as finding root causes and clustering, more attributes maybe useful, but not for dashboards using only the specified attributes. The calculation performance itself doesn't deteriorate, even though the number of attributes increase.
	* Include only those event types to models, that are needed by the dashboards and analyses. The more there are events, the more model loading takes, the more model uses memory, and the more calculations take. Event types can be excluded using filters, improving the measure calculation performance similar to corresponding smaller model, but on the other hand calculating the the filter take time.		* Include only those event types to models, that are needed by the dashboards and analyses. The more there are events, the more model loading takes, the more model uses memory, and the more calculations take. Event types can be excluded using filters, improving the measure calculation performance similar to corresponding smaller model, but on the other hand calculating the the filter take time.

Ollvihe: /* Usability */

2022-03-30T23:36:33Z

Usability

← Older revision		Revision as of 23:36, 30 March 2022
Line 15:		Line 15:
	* When new data is loaded into the model, it will become progressively slower to use. If the oldest data in the model is not shown by dashboards, it's recommended to remove it from the model at the same time when new data is loaded. The old data may be stored to an archive model, if it's still needed in some situations.		* When new data is loaded into the model, it will become progressively slower to use. If the oldest data in the model is not shown by dashboards, it's recommended to remove it from the model at the same time when new data is loaded. The old data may be stored to an archive model, if it's still needed in some situations.

	== Usability ==		== Usability in dashboarding ==
	* Use concise names for event types, as shorter names are easier to read by users and they also provide slightly better performance. This is also valid for case and event attributes values. For the readability, it's also better that if there are names that are close to each other, the differences would be in the beginning of the name rather than in the end, as the ending may be cropped out if there is lack of screen space.		* Use concise names for event types, as shorter names are easier to read by users and they also provide slightly better performance. This is also valid for case and event attributes values. For the readability, it's also better that if there are names that are close to each other, the differences would be in the beginning of the name rather than in the end, as the ending may be cropped out if there is lack of screen space.
	* Use the model description to document any relevant details regarding the model for other users. For example, meaning of the event types and case/event attributes is definitely not obvious for other users but also perhaps not for the author itself after some time. The model description field can be found in the [[QPR_ProcessAnalyzer_Project_Workspace#Editing_Model_Settings\|Model Properties dialog]].		* Use the model description to document any relevant details regarding the model for other users. For example, meaning of the event types and case/event attributes is definitely not obvious for other users but also perhaps not for the author itself after some time. The model description field can be found in the [[QPR_ProcessAnalyzer_Project_Workspace#Editing_Model_Settings\|Model Properties dialog]].
	* When data is sorted, their types matter, i.e., numerical values are sorted by their values, where as strings are sorted alphabetically. There is a difference, for example when sorting numbers 9 and 10 ascending the 9 in first, but if they are stored as strings, the "10" is first. So if string values need to be in specific order other than alphabetical, this needs to be taken into account in the naming. For textual values, the values can be prefixed with an order number. The previous example with 9 and 10 can be worked around by storing string values "09" and "10".		* When data is sorted, their types matter, i.e., numerical values are sorted by their values, where as strings are sorted alphabetically. There is a difference, for example when sorting numbers 9 and 10 ascending the 9 in first, but if they are stored as strings, the "10" is first. So if string values need to be in specific order other than alphabetical, this needs to be taken into account in the naming. For textual values, the values can be prefixed with an order number. The previous example with 9 and 10 can be worked around by storing string values "09" and "10".

Ollvihe: /* Column data types */

2022-03-30T23:36:04Z

Column data types

← Older revision		Revision as of 23:36, 30 March 2022
Line 1:		Line 1:
	This page describes common best practices for designing a suitable structure for a process mining model, and how to configure the model settings. Best practices how to write ETL scripts that actually create and update models, are described separately.		This page describes common best practices for designing a suitable structure for a process mining model, and how to configure the model settings. Best practices how to write ETL scripts that actually create and update models, are described separately.

	== ~~Column~~ data types ==		== Datatable column data types ==
	* Always use the most suitable [[Importing Data to Datatable from CSV File#Data types\|datatypes]] for datatable columns, as the datatypes have remarkable performance impacts and they also affects how data can be used in the analysis. Datatable column datatypes will also be the case and event attribute datatypes in the model. As a general rule, avoid the ''string'' datatype when other datatypes can be be used. Here are some guidelines:		* Always use the most suitable [[Importing Data to Datatable from CSV File#Data types\|datatypes]] for datatable columns, as the datatypes have remarkable performance impacts and they also affects how data can be used in the analysis. Datatable column datatypes will also be the case and event attribute datatypes in the model. As a general rule, avoid the ''string'' datatype when other datatypes can be be used. Here are some guidelines:
	** If there are only two possible values, ''boolean'' is the best datatype. The values in boolean are called ''true'' and ''false'' which can be mapped into a textual presentation in charts. Thus, it's not needed to use string datatype to get desired textual presentations in dashboards.		** If there are only two possible values, ''boolean'' is the best datatype. The values in boolean are called ''true'' and ''false'' which can be mapped into a textual presentation in charts. Thus, it's not needed to use string datatype to get desired textual presentations in dashboards.

Ollvihe at 23:33, 28 March 2022

2022-03-28T23:33:05Z

Ollvihe at 23:25, 28 March 2022

2022-03-28T23:25:13Z

← Older revision		Revision as of 23:25, 28 March 2022
Line 8:		Line 8:
	** If the data contains a numerical score (such as number between 1 and 5), integer is better than string.		** If the data contains a numerical score (such as number between 1 and 5), integer is better than string.
	* All datatypes support ''null'' values to mark missing or not existing value. The null value can be used to mark anything – its meaning is just a matter of decision. For not existing numerical values, using null is better than zero, as nulls are ignored in calculations (such as in average). Note that strings can also contain the empty string value, which is different than the null value. In addition, booleans can actually contain three values: true, false and null.		* All datatypes support ''null'' values to mark missing or not existing value. The null value can be used to mark anything – its meaning is just a matter of decision. For not existing numerical values, using null is better than zero, as nulls are ignored in calculations (such as in average). Note that strings can also contain the empty string value, which is different than the null value. In addition, booleans can actually contain three values: true, false and null.
	* Include to the model only those case and event attributes that are ~~needed by~~ the dashboards, because loading model is slower, when there are more attributes. For advanced analysis, such as finding root causes and clustering, more attributes maybe useful, but not for dashboards using only ~~specific~~ attributes.		* Include to the model only those case and event attributes that are used in the dashboards, because loading the model is slower and it uses more memory, when there are more attributes. For advanced analysis, such as finding root causes and clustering, more attributes maybe useful, but not for dashboards using only the specified attributes. The calculation performance itself doesn't deteriorate, even though the number of attributes increase.
	* Include only those event types to models, that are needed by the dashboards. The more there are events, the more calculations take.		* Include only those event types to models, that are needed by the dashboards and analyses. The more there are events, the more model loading takes, the more model uses memory, and the more calculations take. Event types can be excluded using filters, improving the measure calculation performance similar to corresponding smaller model, but on the other hand calculating the the filter take time.
	* For large models, the [[Automatic_Model_Loading_on_Server_Startup\|Load Model on Startup]] setting may be ~~needed~~, so that the initial opening of dashboard ~~isn~~'t too ~~slow~~, ~~when~~ the model is already available in the memory. On the other hand, loading many models automatically ~~into memory~~, consume more memory, so models that are not used regularly, should not be loaded automatically into memory.		* For large models, the [[Automatic_Model_Loading_on_Server_Startup\|Load Model on Startup]] setting may be useful, so that the initial opening of a dashboard doesn't take too long, as with the setting the model is already available in the memory. On the other hand, pre-loading many models automatically, consume more memory, so models that are not used regularly, should not be loaded automatically into memory.

	== Usability ==		== Usability ==

Ollvihe at 23:15, 28 March 2022

2022-03-28T23:15:50Z

← Older revision		Revision as of 23:15, 28 March 2022
Line 1:		Line 1:
	This page ~~describe~~ common best practices ~~what kind of~~ process mining ~~models to create~~ and how to ~~set~~ model ~~level~~ settings. Best practices how to write ETL scripts that actually create and update ~~the~~ models, are described separately.		This page describes common best practices for designing a suitable structure for a process mining model, and how to configure the model settings. Best practices how to write ETL scripts that actually create and update models, are described separately.

	== Performance ==		== Performance ==
	* ~~Use~~ the most suitable datatypes for datatable columns. ~~Avoid~~ string datatype when other datatypes can be be used:		* Always use the most suitable [[Importing Data to Datatable from CSV File#Data types\|datatypes]] for datatable columns, as the datatypes have remarkable performance impacts and they also affects how data can be used in the analysis. Datatable column datatypes will also be the case and event attribute datatypes in the model. As a general rule, avoid the ''string'' datatype when other datatypes can be be used. Here are some guidelines:
	** If there are only two possible values, ''boolean'' is the best datatype. ~~In booleans, the~~ true and false ~~values~~ can be mapped into a textual presentation in charts, so it's not needed to use string datatype to get desired textual presentations.		** If there are only two possible values, ''boolean'' is the best datatype. The values in boolean are called ''true'' and ''false'' which can be mapped into a textual presentation in charts. Thus, it's not needed to use string datatype to get desired textual presentations in dashboards.
	** If there is numerical data that ~~cannot~~ contain decimals or precision with decimals is not required, ''integer'' ~~should~~ be ~~used~~.		** If there is numerical data that doesn't contain decimals or precision with decimals is not required, ''integer'' is the best datatype.
			** For timestamps, the string datatype will definitely not work, so make sure to use ''date'' type and the conversion from a textual value during the import interprets the data correctly. Even though it's not about a precise timestamp, but the precision is for example a day, the date datatype is still be best.
	** If the data contains a numerical score (such as number between 1 and 5), integer is better than string.		** If the data contains a numerical score (such as number between 1 and 5), integer is better than string.
	* All datatypes support ''null'' values to mark missing or ~~some other kind of special~~ value. The null value can be used to mark anything~~, as it's~~ just a matter of decision. In numerical values, using null is better than zero, as nulls ~~can~~ are ignored in calculations (such as average). ~~Strings~~ can also contain empty string value, which is different than the null value. ~~Note also that~~ booleans can actually contain three values: true, false and null.		* All datatypes support ''null'' values to mark missing or not existing value. The null value can be used to mark anything – its meaning is just a matter of decision. For not existing numerical values, using null is better than zero, as nulls are ignored in calculations (such as in average). Note that strings can also contain the empty string value, which is different than the null value. In addition, booleans can actually contain three values: true, false and null.
	* Include to the model only those case and event attributes that are needed by the dashboards, because loading model is slower, when there are more attributes. For advanced analysis, such as finding root causes and clustering, more attributes maybe useful, but not for dashboards using only specific attributes.		* Include to the model only those case and event attributes that are needed by the dashboards, because loading model is slower, when there are more attributes. For advanced analysis, such as finding root causes and clustering, more attributes maybe useful, but not for dashboards using only specific attributes.
	* Include only those event types to models, that are needed by the dashboards. The more there are events, the more calculations take.		* Include only those event types to models, that are needed by the dashboards. The more there are events, the more calculations take.

Ollvihe: Ollvihe moved page Best Practices for Creating Models to Best Practices for Designing Models without leaving a redirect

2022-03-28T22:56:50Z

Ollvihe moved page Best Practices for Creating Models to Best Practices for Designing Models without leaving a redirect

← Older revision	Revision as of 22:56, 28 March 2022
(No difference)

← Older revision		Revision as of 23:33, 28 March 2022
Line 1:		Line 1:
	This page describes common best practices for designing a suitable structure for a process mining model, and how to configure the model settings. Best practices how to write ETL scripts that actually create and update models, are described separately.		This page describes common best practices for designing a suitable structure for a process mining model, and how to configure the model settings. Best practices how to write ETL scripts that actually create and update models, are described separately.

	== ~~Performance~~ ==		== Column data types ==
	* Always use the most suitable [[Importing Data to Datatable from CSV File#Data types\|datatypes]] for datatable columns, as the datatypes have remarkable performance impacts and they also affects how data can be used in the analysis. Datatable column datatypes will also be the case and event attribute datatypes in the model. As a general rule, avoid the ''string'' datatype when other datatypes can be be used. Here are some guidelines:		* Always use the most suitable [[Importing Data to Datatable from CSV File#Data types\|datatypes]] for datatable columns, as the datatypes have remarkable performance impacts and they also affects how data can be used in the analysis. Datatable column datatypes will also be the case and event attribute datatypes in the model. As a general rule, avoid the ''string'' datatype when other datatypes can be be used. Here are some guidelines:
	** If there are only two possible values, ''boolean'' is the best datatype. The values in boolean are called ''true'' and ''false'' which can be mapped into a textual presentation in charts. Thus, it's not needed to use string datatype to get desired textual presentations in dashboards.		** If there are only two possible values, ''boolean'' is the best datatype. The values in boolean are called ''true'' and ''false'' which can be mapped into a textual presentation in charts. Thus, it's not needed to use string datatype to get desired textual presentations in dashboards.
Line 8:		Line 8:
	** If the data contains a numerical score (such as number between 1 and 5), integer is better than string.		** If the data contains a numerical score (such as number between 1 and 5), integer is better than string.
	* All datatypes support ''null'' values to mark missing or not existing value. The null value can be used to mark anything – its meaning is just a matter of decision. For not existing numerical values, using null is better than zero, as nulls are ignored in calculations (such as in average). Note that strings can also contain the empty string value, which is different than the null value. In addition, booleans can actually contain three values: true, false and null.		* All datatypes support ''null'' values to mark missing or not existing value. The null value can be used to mark anything – its meaning is just a matter of decision. For not existing numerical values, using null is better than zero, as nulls are ignored in calculations (such as in average). Note that strings can also contain the empty string value, which is different than the null value. In addition, booleans can actually contain three values: true, false and null.

			== Performance ==
	* Include to the model only those case and event attributes that are used in the dashboards, because loading the model is slower and it uses more memory, when there are more attributes. For advanced analysis, such as finding root causes and clustering, more attributes maybe useful, but not for dashboards using only the specified attributes. The calculation performance itself doesn't deteriorate, even though the number of attributes increase.		* Include to the model only those case and event attributes that are used in the dashboards, because loading the model is slower and it uses more memory, when there are more attributes. For advanced analysis, such as finding root causes and clustering, more attributes maybe useful, but not for dashboards using only the specified attributes. The calculation performance itself doesn't deteriorate, even though the number of attributes increase.
	* Include only those event types to models, that are needed by the dashboards and analyses. The more there are events, the more model loading takes, the more model uses memory, and the more calculations take. Event types can be excluded using filters, improving the measure calculation performance similar to corresponding smaller model, but on the other hand calculating the the filter take time.		* Include only those event types to models, that are needed by the dashboards and analyses. The more there are events, the more model loading takes, the more model uses memory, and the more calculations take. Event types can be excluded using filters, improving the measure calculation performance similar to corresponding smaller model, but on the other hand calculating the the filter take time.
	* For large models, the [[Automatic_Model_Loading_on_Server_Startup\|Load Model on Startup]] setting may be useful, so that the initial opening of a dashboard doesn't take too long, as with the setting the model is already available in the memory. On the other hand, pre-loading many models automatically, consume more memory, so models that are not used regularly, should not be loaded automatically into memory.		* For large models, the [[Automatic_Model_Loading_on_Server_Startup\|Load Model on Startup]] setting may be useful, so that the initial opening of a dashboard doesn't take too long, as with the setting the model is already available in the memory. On the other hand, pre-loading many models automatically, consume more memory, so models that are not used regularly, should not be loaded automatically into memory.
			* When new data is loaded into the model, it will become progressively slower to use. If the oldest data in the model is not shown by dashboards, it's recommended to remove it from the model at the same time when new data is loaded. The old data may be stored to an archive model, if it's still needed in some situations.

	== Usability ==		== Usability ==
	* Use concise names for event types, as shorter are easier to read ~~in the UI~~ and they also provide slightly better performance. This is also valid for case and event attributes values. It's also better ~~for readability,~~ that if there are names that are close to each other, the differences would be in the beginning of the name rather than in the end, as the ~~end~~ may be cropped out if there is lack of space.		* Use concise names for event types, as shorter names are easier to read by users and they also provide slightly better performance. This is also valid for case and event attributes values. For the readability, it's also better that if there are names that are close to each other, the differences would be in the beginning of the name rather than in the end, as the ending may be cropped out if there is lack of screen space.
	* Use the model description to document any relevant details regarding the model for other users. For example, ~~the~~ meaning of the event types and case/event attributes. The model description field can be found in the [[QPR_ProcessAnalyzer_Project_Workspace#Editing_Model_Settings\|Model Properties dialog]].		* Use the model description to document any relevant details regarding the model for other users. For example, meaning of the event types and case/event attributes is definitely not obvious for other users but also perhaps not for the author itself after some time. The model description field can be found in the [[QPR_ProcessAnalyzer_Project_Workspace#Editing_Model_Settings\|Model Properties dialog]].
	* When data is sorted, their types matter, i.e., numerical values are sorted by their values, where as strings are sorted alphabetically. There is a difference, for example when sorting numbers 9 and 10 ascending the 9 in first, but if they are stored as strings, the "10" is first. So if string values need to be in specific order other than alphabetical, this needs to be taken into account in the naming. For textual values, the values can be prefixed with an order number. The previous example with 9 and 10 can be worked around by storing string values "09" and "10".		* When data is sorted, their types matter, i.e., numerical values are sorted by their values, where as strings are sorted alphabetically. There is a difference, for example when sorting numbers 9 and 10 ascending the 9 in first, but if they are stored as strings, the "10" is first. So if string values need to be in specific order other than alphabetical, this needs to be taken into account in the naming. For textual values, the values can be prefixed with an order number. The previous example with 9 and 10 can be worked around by storing string values "09" and "10".