Defining Types for Reusable Data Definitions
[This content is no longer valid. For the latest information on "M", "Quadrant", SQL Server Modeling Services, and the Repository, see the Model Citizen blog.]
Types in Microsoft code name “M” provide a convenient way to define reusable data patterns. You use types to add additional fields and constraints to one or more extents. For more information about extents, see Using Extents to Define Entities.
Differences Between Types and Extents
Like an extent, a type contains fields. However, a type does not imply any physical storage. Unlike an extent, you cannot store values in a type. Instead, types define a data pattern that you can incorporate into other extents.
Using Types
The following example declares a type named HasId
with a single field named Id
.
type HasId
{
Id : Integer64;
}
This example assumes that there may be many extents with a field named Id
. Instead of repeating that field in each extent, those extents can simply combine the fields in this type with their own field definitions. The following example shows how the PhoneNumbers
extent uses the HasId
type.
module Contact
{
type HasId
{
Id : Integer64;
}
PhoneNumbers :
{(
HasId &
{
Work : Text;
Home : Text?;
Mobile : Text?;
}
)*};
}
Note
Note that when you are using SQL Server Modeling Services, you can use the system-provided type, HasAutoId, instead of defining your own type as is done in this example.
In the previous example, the HasId
type is joined to the other fields of the PhoneNumbers
extent using the & operator. This is the same as if the Id
field were directly defined in the extent. The & operator defines the extent as a union of the type definition and the extent definition.
The benefit of using types is in their reuse and management. Consider a scenario where multiple extents in the Contact
module used the HasId
type. If a new requirement specifies that the Id
field should be changed to InternalId
, this change can be performed by changing only the field name in the type. The benefits of this become even more obvious with more complex data patterns that contain several fields. In these cases, the individual extents are more concise and have fewer errors than if the data pattern were repeated manually in each extent.
For more technical details about types, see "M" Types Overview.