System
[This is prerelease documentation and is subject to change in future releases. Blank topics are included as placeholders.]
This topic describes the extents, data types, relationships, and constraints that support features of many different model schemas in the code name “Oslo” repository. For more information about the “Oslo” repository, see Repository Overview
System Overview
The System module defines a base set of storage extents for commonly occurring data and a set of common types. The extents and types defined in the System module are domain-neutral and can be used as part of the definition of many other modules. The extents define storage that is intended to be used as is, while the types define common characteristics—collections of fields and/or references to other types, and constraints—that can be included by reference in other type or extent definitions. These basic types are widely used throughout code name “Oslo” in almost every one of the System-Provided Models. The use of System types in all Microsoft code name “M” models results in the consistent application of common design patterns. It also results in “M” definitions that are more concise, more readable, and more reliable.
Note
Note that the basic types in the System module assist with creating models that comply with modeling patterns and best practices for “M” and the “Oslo” repository. Other types and extents use the System types as a part of their own definitions. You can see one result of this characteristic when you compile the “M” models and load them into the “Oslo” repository database. The fields and constraints of the basic types become properties of the types or extents that use them. There are no separate tables that store instances of these basic types alone.
The basic types are as follows:
Item. The Item type describes key characteristics common to most “Oslo” repository content, including a reference to a Folder (see below) and an auto-numbered numeric identifier.
DerivedItem and RootItem. The types DerivedItem and RootItem are used when mapping an entity generalization hierarchy in a problem domain to a vertically partitioned hierarchy of extents. With this pattern, an entity (instance) is partitioned across a root extent and one or more other extents, one for each level in the hierarchy. The type RootItem extends Item and introduces an ExtentName field that that holds the name of the leaf, or most concrete, extent in which an entity is stored. RootItem is included in the definition of the extent created for the root of the generalization hierarchy. The type DerivedItem is included in the definition of each of the extents in the hierarchy beneath the root extent, and provides a numeric identifier and Folder reference. When this pattern is used, extents that include DerivedItem must additionally declare a membership constraint between the Id field in the extent and the Id of its immediate parent extent in the hierarchy. Applications that use storage based on this pattern are responsible for partitioning data correctly across the extents and ensuring that the correct extent name is populated in the root extent for each stored instance.
Describable. The Describable type is used to add descriptive information to any type or extent.
Nameable and Named. These types are used to introduce a Name field to a type or extent. The Nameable type defines an optional field, while Named defines a mandatory field.
The basic extents are:
- Documents, DocumentParts, and DocumentSourceLocations. These extents define storage for digital content, such as files stored in the “Oslo” repository. The Documents extent stores the actual document content in binary form or, if the content is not held in the Document field, holds a URL for the document as well as the MIME type of the document. The DocumentParts extent holds references to sections or parts of simple text documents using first and last line number references. DocumentSourceLocations holds a reference to the location from which a specific document was loaded into the “Oslo” repository. (For more information about formats for the source location, see Naming a File or Directory.)
The Item, RootItem, and DerivedItem types provide an example of how the basic System types assist with following modeling patterns in “M” and the “Oslo” repository. First, each type that derives from these types obtains an identifier named Id. The consistent use of this identifier name decreases the complexity for tools exploring the “Oslo” repository database as well as users creating queries that join multiple tables or views on this identifier field. These basic types also introduce a Folder field. A Folder is a key organizational concept in the “Oslo” repository and a key part of its infrastructure. While folders are not currently modeled explicitly in the System module, a standard FoldersTable table is created during the “Oslo” repository installation. Folders are used to partition content (instances) in the “Oslo” repository. It is reasonable to think of “Oslo” repository content being stored “in” a Folder. Because they are used to secure access to sets of instances, folders are also a key element of the “Oslo” repository security model. Because of this, it is highly recommended that all extents introduced through models derive from Item, RootItem, or DerivedItem and thus acquire a Folder field (which results in a foreign key column to the [Item].[FoldersTable] table). As an alternative, an extent can explicitly introduce a mandatory Integer32 field called Folder which is treated in the same manner during “M” compilation and SQL generation. Additionally, Item, RootItem, or DerivedItem define a default folder Id value of 100, which is used if instances are created without an explicit folder Id value. Folder 100 is the identifier for a default Applications Folder in the “Oslo” repository database. A cascade delete option is defined on these foreign key constraints so that deleting a folder also deletes all of that folder’s associated content. For more information about “Oslo” repository Folders, see "Oslo" Repository Architecture. For more information about how to comply with “Oslo” repository Folder database design patterns, see "Oslo" Repository Folder Design Patterns.