Compartir a través de


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.

See Also

Concepts

Basic Data Modeling Patterns

Other Resources

"M" Types Overview