Attributes, which define the different facets of the context, are the basic elements of a data governance strategy. This article explains the notion of attribute and how it works in the DataGalaxy platform.
To learn how to create and delete attributes, see Manage Attributes.
What is an attribute?
One of DataGalaxy's missions is to make the different data profiles (analysts, developers, architects, business users, producers, consumers…) collaborate around a shared vision of the different facets of the data. This involves managing different types of heterogeneous information, and attribute management addresses this need. Attributes are fields that, once grouped into categories, make it possible to build an object's identity card, the object card (see "The object card and the screens").
The objective of attributes is to contextualize as much as possible the different facets of an object and thus to enrich its knowledge.
To support the data governance approach (corporate vision), attributes are created at the client space level. This means they are common to all workspaces that depend on this client space.
It is important to ask yourself a few questions before you start creating dozens of attributes:
- What proportion of users is concerned by the information carried by the attribute?
- Which attributes are critical for your use case and need to be curated?
- Is the meaning of the attribute explicit? For example, what does the attribute "frequency" mean? Is it the update frequency? The data deletion frequency?
- Does this attribute not already exist, or does it largely overlap with another attribute? It is advisable to converge terms as much as possible so as not to end up with several interchangeable fields, which would be a source of confusion.
- Are the values proposed in the attribute list complete? Some types of attributes contain lists of values: the list must be rich enough for everyone to find their way, but not so rich that people get lost.
- Which language should be used? The platform is available in French and English, but the values set on attributes can be in any language. Which one should prevail? Should the attribute be created in both languages?
- Are there attributes specific to a domain, department or project? Should management be delegated?
How does it work?
The diagram below summarizes how attributes are structured in DataGalaxy.
Attributes are structured into two main families.
System attributes
To ensure a quick start, DataGalaxy offers and maintains a number of attributes, known as system attributes. They are available "by default" and cannot be modified by users. You can identify them by the cloud icon next to their name.
Some system attributes let you view data from source tools, for example the number of records in a table or the source query of a data set. The information returned depends on the source tools; you will find the details in the articles of the technologies concerned.
Custom attributes
These are the attributes created and managed by the administrators of the client space. They are usable by all workspaces of the client space.
Two types of attributes can be proposed in each family.
Common attributes
They are usable for all objects on the platform, regardless of the module the object belongs to. Examples: the object's description, the DCP classification, the person responsible…
Module attributes
They are specific attributes that are exclusively usable for a subset of platform objects:
- Attributes specific to Glossary objects
- Attributes specific to Data Sources (databases, file stores…)
- Attributes specific to Structures (table, file…)
- Attributes specific to Fields (column…)
- Attributes specific to Uses
- Attributes specific to processing objects
What does an attribute consist of?
All attributes, regardless of their type or format, share a common definition base:
- Attribute label
- Description of the attribute
- Attribute format (text, date, tag…)
- The Recommended option, which lets you calculate the completion rate of the object
- The default value (optional)
Which attribute formats are supported?
| Format | Description | Comment |
|---|---|---|
| Boolean | The attribute is a Yes/No field. | Examples: "Contains personal data: yes or no", "Is personal data: yes or no". |
| Date | The date attribute is in dd/mm/yyyy format. | All information in date format. |
| Formatted text | Rich text attribute with formatting tools. | Use it for attributes that need a long description or advanced formatting of the content. |
| Hyperlink | Lets you insert a link to external references. | For example, in a GDPR project, the hyperlink field can link to the CNIL's Privacy Impact Assessment tool. |
| Number | A field in Number format. | It can be an integer or a decimal number. |
| Value list | Single-choice value list. | |
| Text | Plain text field. | Attributes of this type are limited to 512 characters. |
| Tag | Classification attribute. Each tag created has a color that makes it easy to identify the group an object tagged with it belongs to. | Example of classification: Marketing, Sales, Finance, HR. |
| Multi-value list | Multiple-choice field. | A multi-value list works like tags. |
| Users | Multiple-choice field with the users of the client space as the value list. | |
| Person | Multiple-choice field with the users of the client space as the value list. | Typically used to define an attribute identifying stakeholders and external actors. |
| Hierarchy | Field with a hierarchical multiple-choice value list. | |
| Time series | Field that lets you follow the evolution of a value over time. | Example: a quality indicator. |