Mining Model Content (Analysis Services - Data Mining)

The following table lists the different types of nodes that are output in data mining models. Because each algorithm processes information differently, each model generates only a few specific kinds of nodes. If you change the algorithm, the type of nodes may change. Also, if you reprocess the model, the content of each node may change.

The root node of any model always has the unique ID (NODE_UNIQUE_NAME) of 0. All node IDs are assigned automatically by Analysis Services and cannot be modified.

The root node for each model also contains some basic metadata about the model. This metadata includes the Analysis Services database where the model is stored (MODEL_CATALOG), the schema (MODEL_SCHEMA), and the name of the model (MODEL_NAME). However, this information is repeated in all the nodes of the model, so you do not need to query the root node to get this metadata.

In addition to a name used as the unique identifier, each node has a name (NODE_NAME). This name is automatically created by the algorithm for display purposes and cannot be edited.

The caption and description for each node are automatically generated by the algorithm, and serve as labels to help you understand the content of the node. The text generated for each field depends on the model type. In some cases, the name, caption, and description may contain exactly the same string, but in some models, the description may contain additional information. See the topic about the individual model type for details of the implementation.

The relationship between parent and child nodes in a tree structure is determined by the value of the PARENT_UNIQUE_NAME column. This value is stored in the child node and tells you the ID of the parent node. Some examples follow of how this information might be used:

• A PARENT_UNIQUE_NAME that is NULL means that the node is the top node of the model.

• If the value of PARENT_UNIQUE_NAME is 0, the node must be a direct descendant of the top node in the model. This is because the ID of the root node is always 0.

• You can use functions within a Data Mining Extensions (DMX) query to find descendants or parents of a particular node. For more information about using functions in queries, see Querying Data Mining Models (Analysis Services - Data Mining).

Cardinality refers to the number of items in a set. In the context of a processed mining model, cardinality tells you the number of children in a particular node. For example, if a decision tree model has a node for [Yearly Income], and that node has two child nodes, one for the condition [Yearly Income] = High and one for the condition, [Yearly Income] = Low, the value of CHILDREN_CARDINALITY for the [Yearly Income] node would be 2.

Although cardinality is counted in the same way for all models, how you interpret or use the cardinality value differs depending on the model type. For example, in a clustering model, the cardinality of the top node tells you the total number of clusters that were found. In other types of models, cardinality may always have a set value depending on the node type. For more information about how to interpret cardinality, see the topic about the individual model type.

The NODE_DISTRIBUTION column contains a nested table that in many nodes provides important and detailed information about the patterns discovered by the algorithm. The exact statistics provided in this table change depending on the model type, the position of the node in the tree, and whether the predictable attribute is a continuous numeric value or a discrete value; however, they can include the minimum and maximum values of an attribute, weights assigned to values, the number of cases in a node, coefficients used in a regression formula, and statistical measures such as standard deviation and variance. For more information about how to interpret node distribution, see the topic for the specific type of model type that you are working with.

The nested table, NODE_DISTRIBUTION, always contains the following columns. The content of each column varies depending on the model type. For more information about specific model types, see Mining Model Content by Algorithm Type.

• ATTRIBUTE_NAME
  Content varies by algorithm. Can be the name of a column, such as a predictable attribute, a rule, an itemset, or a piece of information internal to the algorithm, such as part of a formula.

  This column can also contain an attribute-value pair.

• ATTRIBUTE_VALUE
  Value of the attribute named in ATTRIBUTE_NAME.

  If the attribute name is a column, then in the most straightforward case, the ATTRIBUTE_VALUE contains one of the discrete values for that column.

  Depending on how the algorithm processes values, the ATTRIBUTE_VALUE can also contain a flag that tells you whether a value exists for the attribute (Existing), or whether the value is null (Missing).

  For example, if your model is set up to find customers who have purchased a particular item at least once, the ATTRIBUTE_NAME column might contain the attribute-value pair that defines the item of interest, such as Model = 'Water bottle', and the ATTRIBUTE_VALUE column would contain only the keyword Existing or Missing.

• SUPPORT
  Count of the cases that have this attribute-value pair, or that contain this itemset or rule.

  In general, for each node, the support value tells you how many cases in the training set are included in the current node. In most model types, support represents an exact count of cases. Support values are useful because you can view the distribution of data within your training cases without having to query the training data. The Analysis Services server also uses these stored values to calculate stored probability versus prior probability, to determine whether inference is strong or weak.

  For example, in a classification tree, the support value indicates the number of cases that have the described combination of attributes.

  In a decision tree, the sum of support at each level of a tree sums to the support of its parent node. For example, if a model containing 1200 cases is divided equally by gender, and then subdivided equally by three values for Income—Low, Medium, and High—the child nodes of node (2), which are nodes (4), (5) and (6), always sum to the same number of cases as node (2).

  Node ID and node attributes	Support count
  (1) Model root	1200
  (2) Gender = Male (3) Gender = Female	600 600
  (4) Gender = Male and Income = High (5) Gender = Male and Income = Medium (6) Gender = Male and Income = Low	200 200 200
  (7) Gender = Female and Income = High (8) Gender = Female and Income = Medium (9) Gender = Female and Income = Low	200 200 200

  For a clustering model, the number for support can be weighted to include the probabilities of belonging to multiple clusters. Multiple cluster membership is the default clustering method. In this scenario, because each case does not necessarily belong to one and only one cluster, support in these models might not add up to 100 percent across all clusters.

• PROBABILITY
  Indicates the probability for this specific node within the entire model.

  Generally, probability represents support for this particular value, divided by the total count of cases within the node (NODE_SUPPORT).

  However, probability is adjusted slightly to eliminate bias caused by missing values in the data.

  For example, if the current values for [Total Children] are 'One' and 'Two', you want to avoid creating a model that predicts that it is impossible to have no children, or to have three children. To ensure that missing values are improbable, but not impossible, the algorithm always adds 1 to the count of actual values for any attribute.

  Example:

  Probability of [Total Children = One] = [Count of cases where Total Children = One] + 1/[Count of all cases] + 3

  Probability of [Total Children = Two]= [Count of cases where Total Children = Two] +1/[Count of all cases] +3

  Note

  The adjustment of 3 is calculated by adding 1 to the total number of existing values, n.

  After adjustment, the probabilities for all values still add up to 1. The probability for the value with no data (in this example, [Total Children = 'Zero', 'Three', or some other value]), starts at a very low non-zero level, and rises slowly as more cases are added.

• VARIANCE
  Indicates the variance of the values within the node. By definition, variance is always 0 for discrete values. If the model supports continuous values, variance is computed as σ (sigma), using the denominator n, or the number of cases in the node.

  There are two definitions in general use to represent standard deviation (StDev). One method for calculating standard deviation takes into account bias, and another method computes standard deviation without using bias. In general, Microsoft data mining algorithms do not use bias when computing standard deviation.

  The value that appears in the NODE_DISTRIBUTION table is the actual value for all discrete and discretized attributes, and the mean for continuous values.

• VALUE_TYPE
  Indicates the data type of the value or an attribute, and the usage of the value. Certain value types apply only to certain model types:

  VALUE_TYPE ID	Value Label	Value Type Name
  1	Missing	Indicates that the case data did not contain a value for this attribute. The Missing state is calculated separately from attributes that have values.
  2	Existing	Indicates that the case data contains a value for this attribute.
  3	Continuous	Indicates that the value of the attribute is a continuous numeric value and therefore can be represented by a mean, together with variance and standard deviation.
  4	Discrete	Indicates a value, either numeric or text, that is treated as discrete. Note   Discrete values can also be missing; however, they are handled differently when making calculations. For information, see Missing Values (Analysis Services - Data Mining).
  5	Discretized	Indicates that the attribute contains numeric values that have been discretized. The value will be a formatted string that describes the discretization buckets.
  6	Existing	Indicates that the attribute has continuous numeric values and that values have been supplied in the data, vs. values that are missing or inferred.
  7	Coefficient	Indicates a numeric value that represents a coefficient. A coefficient is a value that is applied when calculating the value of the dependent variable. For example, if your model creates a regression formula that predicts income based on age, the coefficient is used in the formula that relates age to income.
  8	Score gain	Indicates a numeric value that represents score gain for an attribute.
  9	Statistics	Indicates a numeric value that represents a statistic for a regressor.
  10	Node unique name	Indicates that the value should not be handled not as numeric or string, but as the unique identifier of another content node in a model. For example, in a neural network model, the IDs provide pointers from nodes in the output layer to nodes in the hidden layer, and from nodes in the hidden layer to nodes in the input layer.
  11	Intercept	Indicates a numeric value that represents the intercept in a regression formula.
  12	Periodicity	Indicates that the value denotes a periodic structure in a model. Applies only to time series models that contain an ARIMA model. Note The Microsoft Time Series algorithm automatically detects periodic structures based on the training data. As a result, the periodicities in the final model may include periodicity values that you did not provide as a parameter when creating the model.
  13	Autoregressive order	Indicates that the value represents the number of autoregressive series. Applies to time series models that use the ARIMA algorithm.
  14	Moving average order	Represents a value that represents the number of moving averages in a series. Applies to time series models that use the ARIMA algorithm.
  15	Difference order	Indicates that the value represents a value that indicates how many times the series is differentiated. Applies to time series models that use the ARIMA algorithm.
  16	Boolean	Represents a Boolean type.
  17	Other	Represents a custom value defined by the algorithm.
  18	Prerendered string	Represents a custom value that the algorithm renders as a string. No formatting was applied by the object model.

  The value types are derived from the ADMOMD.NET enumeration. For more information, see MiningValueType.

The meaning of the node score differs depending on the model type, and can be specific to the node type as well. For information about how NODE_SCORE is calculated for each model and node type, see Mining Model Content by Algorithm Type.

The mining model schema rowset includes the columns NODE_PROBABILITY and MARGINAL_PROBABILITY for all model types. These columns contain values only in nodes where a probability value is meaningful. For example, the root node of a model never contains a probability score.

In those nodes that do provide probability scores, the node probability and marginal probabilities represent different calculations.

• Marginal probability is the probability of reaching the node from its parent.

• Node probability is the probability of reaching the node from the root.

• Node probability is always less than or equal to marginal probability.

For example, if the population of all customers in a decision tree is split equally by gender (and no values are missing), the probability of the child nodes should be .5. However, suppose that each of the nodes for gender is divided equally by income levels—High, Medium, and Low. In this case the MARGINAL_PROBABILITY score for each child node should always be .33 but the NODE_PROBABILTY value will be the product of all probabilities leading to that node and thus always less than the MARGINAL_PROBABILITY value.

The mining model schema rowset also includes the columns NODE_RULE and MARGINAL_RULE for all model types. These columns contain XML fragments that can be used to serialize a model, or to represent some part of the model structure. These columns may be blank for some nodes, if a value would be meaningless.

Two kinds of XML rules are provided, similar to the two kinds of probability values. The XML fragment in MARGINAL_RULE defines the attribute and value for the current node, whereas the XML fragment in NODE_RULE describes the path to the current node from the model root.

Back to Top