Microsoft SQL Server 2008 R2 Master Data Services in VS .NET

Maker QR Code in VS .NET Microsoft SQL Server 2008 R2 Master Data Services

fter you understand the workflow for adding and modifying the data stored in MDS, you must learn how to manage that data over time For each model within MDS, a historical record of the data can be stored These data snapshots are called versions Each time you create a version of a model, the data for all the entities within the individual model are versioned at the same time Only the data is stored; any changes to the structure of the model affect all versions and can create unintended consequences Version flags are another important component of versioning in MDS By assigning flags to versions, integration with other systems can be better managed

In order to manage data within your organization effectively, you may be required to create versions of the data stored within a model In MDS, the data in all entities within each model is versioned simultaneously A benefit of this design is that you can manage relationships between entities without worrying about time and version A side effect of this design is that entities in different models cannot interact with one another There is often a natural cadence to many data domains This cadence can help define which entities should be managed in the same model For example, in many organizations, the accounting department manages structural changes on a monthly basis As each month ends, everyone in the accounting department goes through standard routines to ensure that the month s books can be closed properly Any entities related to this process accounts, divisions, departments, or other internal business entities that are central to this process should be managed together, versioned in concert with the month-end process In another example, an organization may release products on a quarterly basis All entities central to the product development process would follow this quarterly versioning scheme Other entities may not require a versioning scheme at all Versions provide a number of benefits to the data management process:

Complete model history for a specific point in time MDS model versions can be committed to ensure that an exact record of a model s data can be stored for later review These committed versions can provide a portion of the required audit trail for new, more rigorous compliance requirements

Limited access during sensitive processes When performing certain processes, like validating the entire model or loading large numbers of records, it may be prudent to restrict access to the model by locking it Additional version copies for analysis Additional versions can be created outside of the standard cadence for a variety of purposes These versions can be used to examine new hierarchy configurations or potential acquisitions without affecting the current regular processes

MDS does not version metadata changes Any changes to the model structure affect all open and committed versions If an attribute or entity is deleted, for example, all history for that attribute or entity is lost from all versions forever When you need to maintain historic data, we suggest that you use security permissions to hide attributes or entities instead of deleting them You can also hide attributes by setting the display width to zero or by not adding them to attribute groups When you add an attribute or entity, the model structure is updated in all versions as well You can add the corresponding data to any version of the model; if you add data to a later version, the structure exists in the earlier versions but the data does not

Sometimes users and downstream systems need to be certain that all data has been validated and reviewed Because MDS allows incomplete members to be added to the system and encourages users to manage the data creation and correction workflow from within MDS entities, it may not be reliable for external production systems to use open or locked versions Only committed versions ensure that all members in every entity within the model have passed all business rules successfully Once a version is committed, no additional changes can be made to the data, and the status of the version cannot be changed Figure 9-1 shows the most common version control workflow A few notes about Figure 9-1:

Each time the status changes, if notifications are configured, an e-mail is sent to model administrators For more information about notifications, see 8 You can change a setting in MDS Configuration Manager so that you can copy versions with a status other than Committed, but Figure 9-1 shows the default behavior

You can validate a version at any time Locking the version ensures that users don t make changes after you ve validated, but it s only necessary if you plan to commit the version or otherwise prevent users from making changes