As data sets grow in an enterprise environment, database tables can become seas of vertically partitioned data that are related to the model – the table or tables – to which the rows of data belong. Although vertical partitioning creates data that is easily categorized by structure, it doesn’t easily categorize data by any other category that makes sense to you or your organization unless that category is represented by a SQL table or tables. Even if the tables in your organization do reflect some internal organization you currently have, creating new categorizations in the future would potentially require an entirely new database design.

The “Oslo” repository folder pattern allows to you to identify specific groups of data for any purpose by adding a Folder field to an extent that can be associated with any data taxonomy that you want or that you have already. (In SQL terminology, using the folder pattern implements horizontal partitioning – the categorization of data across tables and views.) The folder pattern supports many features that file system folders do – their categorized contents can be secured, versioned, and so on – hence the pattern name.

Using the folder pattern to partition data horizontally for robust organizational labeling also enables support for the following code name “Oslo” repository features:

• Applying security to a specific folder. This supports the ability to prevent specific rows from being altered or read, or included in any replication scheme if the data should not be replicated.
  
  
• Versioning your data. You can create new folders for newer versions of an application and copy older data into them, enabling newer applications and older applications to continue to operate.
  
  

Using folders to organize your data across models is a logical thing to do for your data taxonomy, whether you need any “Oslo” repository features or not. For example, the common language runtime (CLR) domain stores metadata about .NET assemblies. Because the CLR domain models use the folder pattern you specify new folders for each specific version of a .NET assembly that you load into the “Oslo” repository. You can then use “Quadrant” to view only those types from one version of the assembly -- even if you have the data from tens or hundreds of versions. This example makes no use of any “Oslo” repository features except for the ability to label one set of data differently from another to make the viewing of that data easier.

The folder pattern, however, becomes much more powerful when it is used to support “Oslo” repository security, versioning, globalization, and data management features based on the folder and id patterns. An organization might classify “Oslo” repository data for security and manageability reasons, for example. To do so, it might:

1. Develop a folder hierarchy that represents how it thinks about the data that is stored in the “Oslo” repository. For example, data about version 2.0 of the Paystub application might be in the folder /Finance/Reporting/PayStub/2.0.
   
   
2. Assign folder permissions to accounts and domain groups. For example, the operations staff responsible for the finance department’s reporting applications might be given read-write permissions on the folder /Finance/Reporting and the PayStub service account might be given read permissions on /Finance/Reporting/PayStub/2.0.
   
   

The folder pattern makes versioning data and applications logical, because you can deploy new data and the applications that use them in-place. For example, an organization that chooses to use the /Finance/Reporting/PayStub/1.0 folder hierarchy can deploy a new version of the application by creating a new subfolder of /Finance/Reporting/PayStub/2.0. In this case, the old version of the application can continue to run against the folder /Finance/Reporting/PayStub/1.0 while the new version can target the folder /Finance/Reporting/PayStub/2.0. Once the deployment of the new PayStub application version was complete, the old version’s folder can be either left in-place for reference purposes or removed. Patches to the 2.0 version of the application can happen in place.

In the current version of “Oslo” modeling technologies, you can use the –t:Repository switch in M.exe as you could in previous versions. However, that switch creates matching SQL views for each table and calls the AddStandardPatterns Procedure (Repository.Item) for all extents. This global approach quickly creates a database that supports best practices but does not allow you to control exactly which tables or views are created or to which the “Oslo” repository patterns are applied. For more information about the repository features that the AddStandardPatterns procedure enables, see Using the AddStandardPatterns Stored Procedure.

To use the current release to create tables and views explicitly and control which repository features are enabled on a model-by-model basis from “M” (an important feature of this release), the following procedure is one way to do it:

1. Creating Models that use the Folder and Id Patterns in “M”

   1. Create an extent in “M” using the HasFolderAndAutoId mixin type in the type or an extent directly, and the name of the extent must have “Table” at the end of the name.

      Note:
      In this release, the “Table” suffix is required if you want to call the AddFolderForeignKey Procedure (Repository.Item), which creates a foreign-key relationship to the FoldersTable Table (Repository.Item), supporting such features as cascade delete. If you do not need to call AddFolderForeignKey, there are no naming constraints.

   2. Create a function (which projects to a SQL Server view) of the extent where the name is identical to that of the extent but without the “Table” suffix. (This view does not yet have any security features applied.)

   3. Create an instance of the extent, and specifying the Folder field is assigned the value PathsFolder(“CustomFolderNameHere”), where CustomFolderNameHere is the name of the folder with which the data is to be associated.

      Note:
      The PathsFolder reference results in the invocation of the PathsFolder Function (Repository.Item), which returns the folder id for the folder string.

      The following code example shows a simple “M” example of the preceding steps.

      module Oslo.Documentation.Microsoft{
          
          import System;
          import Repository.Item;
          
          type Person : HasFolderAndAutoId
          {
              Name : Text;
              Summary : Text;
          };
          
          PeopleTable : Person*{
              John { Name => "John", Summary => "This is a description for John.", Folder => PathsFolder("Applications/Oslo Sample Code"), },
              Frida { Name => "Frida", Summary => "This is a description for Frida.", Folder => PathsFolder("Applications/Oslo Sample Code"), },
              Charles { Name => "Charles", Summary => "This is a description for Charles.", Folder => PathsFolder("Applications/Oslo Sample Code"), }
          };
      
          People() {
              from p in PeopleTable select p;
          }
      }

2. Projecting the Models and Data into the “Repository”

   1. At the command prompt, call mx createFolder “CustomFolderNameHere” (where CustomFolderNameHere is the name of the folder) to add the targeted custom folder to the “Oslo” repository. With the preceding sample code, the command is mx createFolder "Applications/Oslo Sample Code".

      Note:
      In the current release, you cannot create multiple subfolders in one use of the createFolder option. You must instead issue one command for each subfolder you create.

   2. Create a .sql file in which AddFolderForeignKey Procedure (Repository.Item) is called for the target module and target view name (called a basename). An example using the preceding .m file is:

      use Repository
      execute [Repository.Item].[AddFolderForeignKey] N'Oslo.Documentation.Microsoft', N'People'; 
      go

   3. Compile the file to an image, referencing Repository.mx (for the HasFolderAndAutoId mixin) and with the –postSql:filename.sql file name to embed the call to AddForeignFolderKey into the image file to add support for cascade delete. For example, a possible command string using the preceding code and .sql file is (note the lack of a –t:Repository switch):

      m People.m –r:Repository.mx –postSql:AddForeignFolderKey.sql

   4. Install the image using Mx.exe and the –d: switch to specify the “Oslo” repository instance. For example, a possible command string using the image created by the preceding step is:

      mx install People.mx –d:Repository -f

      Where the –f switch forces the installation to drop earlier iterations of the same domain and models.

3. Viewing Folders and Data in “Quadrant”

   1. The following graphic shows the John entity inside the Applications/Oslo Sample Code folder in the “Quadrant” Repository Explorer on top, and the way the same information appears in a Tree Master/Detail view workpad, on bottom.

      

   2. The following graphic shows the same information as the preceding graphic, but located through the Catalog folder, by finding the Oslo.Documentation.Microsoft domain and highlighting the People extent underneath.

      

To be submitted.