Attributes in Logical Data Models
Attributes describe the entity (a fact) that they are associated with. In other words, rather than stating a fact, they describe it - just like columns in a table. In reports, they are used to group, slice, filter, and reorder facts.
Attributes in a dataset are identified by the following icon:
The following image shows an LDM Modeler dataset comprising four attributes:
Dimensions
A set of related attributes is called a dimension. For example, Address, City, State, and ZIP Code may be related in a dimension called Location. Each attribute in the dimension is a discrete entity, yet they are all related to each other.
A dimension is stored in a dimension table. Dimension tables are typically wide and shallow (they do not have many rows).
Your dimensions should always have consistent definitions and contents. Dimensions that share identical structures are called conformed dimensions. Conformed dimensions are easier to create insightful reporting because of consistency between the data.
For example, the State attribute should not use two-letter abbreviations (CA) along with full state names (California). Queries using this malformed attribute will not be able to match the two versions of the state name.
Whenever possible, share dimensions between fact tables to ensure consistency. Shared dimensions are always conformed.
Attribute Labels and Values
An attribute can have multiple values that you can further define by the use of labels.
The following table shows the relationship of attributes, attribute labels, and attribute values in your logical data model:
| Attribute | Attribute Label | Attribute Values |
|---|---|---|
Department | Full names | Human Resources Research and Development Quality Assurance |
| Shortened names | HR RD QA | |
| Numbers | 1 2 3 |
Attribute Labels
A label is an object that you use to apply additional descriptors to an attribute.
For example, the Person attribute may have the following labels: First Name, Last Name, Social Security #, and others.
When you define an attribute in the LDM Modeler, it is added with a single label, which has the same name as the attribute itself. This label becomes the default label for the attribute and also the loading label (the label that is used when data is loaded to the attribute). Every attribute has at least one label, and you can add more labels to it.
Types of Attribute Labels
Attribute labels can be of the following types:
- Text holds a string of characters. For example, a text attribute label can store city names, product IDs, locations, and so on.
- Hyperlink stores a fully qualified URL, which is automatically translated as an HTML link. Hyperlink labels are used, for example, when you enable drilling from metrics to URL addresses in the KPI dashboards (see Drill to URL from Dashboards).
Data Types of Attribute Labels
Attribute labels can be stored with the following data types:
- Text can hold up to 10,000 characters.
- Integer (INT) can be represented by integer values in the range of min(-2147483648) to max(2147483647). By identifying attributes as numeric data, the GoodData Portal properly sorts them in reports.
- Large Integer (BIGINT) can be represented by integer values in the range of min(-1e+15) to max(1e+15). By identifying attributes as numeric data, the GoodData Portal properly sorts them in reports.
Attribute Values
In the Name attribute, values can be John Dow, Mary Jane and so on. Facebook and Twitter are values of the Sales Channel attribute.
Attribute values can also be numeric. For example, the Table Size attribute can have values 1, 2, 4, and so on.
Numerical data can be both facts and attributes. For example, you can track age both as an attribute (to enable segmentation by age ranges) and as a fact (to use age in computation because attributes cannot be used in computations).
Recommended Practices
- Avoid placing attributes in fact tables. Fact tables should contain facts and foreign keys to attributes stored in other dimensions.
- Create common dimensions that can be reused (shared) when you create additional fact tables. For example, you should have only one dimension table for customer, one for product, one for an employee, and so on. These conformed dimensions ensure uniformity of data in the workspace and enable re-use of the associated contextual information. Name your model objects consistently so that business users understand it because they will interact with them in the workspace that uses your model.