Domains and Data Spaces

SPD Server is a tool that can be configured to meet different organizational data requirements. When an organization needs different types of SPD Server domain space, administrators can use domain declarations in the libnames.parm file to configure spaces that balance processing speed, space, and growth needs with data security requirements. Typically, SPD Server users use most or all of the types of table spaces. The type of queries and reports that the user makes can indicate the type (or types) of data space that the user needs. There are three basic types of domain space.

In SPD Server, large production, inventory, and sales data storage areas work best using permanent table space. A rolling five-year sales data table by division and company is an example of an SPD Server structure that is best suited to permanently allocated space on the enterprise computers. Organizations can rely on large quantities of production, inventory, or sales data that is updated on a day-to-day, or even shift-to-shift basis. These data repositories require permanent, secure processing space that only can be accessed by a select group of key users. Allocating permanent space for the data ensures that sufficient disk space required for the combination and manipulation of large amounts of data from multiple large warehouse tables is always available.

For example, an organization might call such a tightly controlled, permanently defined area the "production" data space. Data analysts in organizations typically manipulate production-type data to produce smaller, more focused reports. Analyst reports often benchmark specific areas of performance or interest. Regular analyst reports are frequently distributed across the organization. The distributed analyst reports, while not as critical as the production, inventory, or sales data, should also use permanently defined data spaces that are separate from the permanent production reporting table spaces. In such instances, permanent table space should be accessible to the specific group (such as analysts) of regular SPD Server users.

The SPD Server administrator can use the libnames.parm file to configure paths that map to an area of reserved disk space on a host computer, creating a safe place for permanent tables with limited user access. To reserve permanent table space, the LIBNAME domain statement in the libnames.parm file should use the optional DATAPATH=, INDEXPATH=, and OWNER= statements to specify unique, appropriately sized disk areas for data tables and index tables. The OWNER= statement configures ownership and access. It is up to the SPD Server administrator to ensure that the paths named in domain declarations have access to sufficient disk space.

User access to permanent table spaces can be established via individual user account access privileges, or by establishing, through the owner of the domain, an ACL group of approved users. LIBNAME domain statements will create permanent table space by default.

Organizations often have short-term data mining projects that rely on production, inventory, or sales data, but modify the way the data is processed, or augment the production, inventory, or sales data in some manner with additional information. Those projects should be conducted in a test data space, safely isolated from the permanent space that is dedicated to critical production, inventory, or sales data. This design allows development trials to be conducted without risk of corrupting mission-critical data.

For example, the test data space used for a month-long development project could be considered a semi-permanent space; it requires the SPD Server administrator to grant access to an area where data can safely exist, isolated from production, sales, or inventory data, for a specific period of time longer than a single SPD Server user session. The "test" environment should persist long enough for works-in-progress to mature to production-quality (if so destined), but after the project is completed, the data, metadata, and work tables that are associated with the development phase should be cleaned up and deleted from the test environment.

Semi-permanent table space can be configured by an SPD Server administrator or by SPD Server users. It is recommended that administrators allocate semi-permanent spaces using the libnames.parm file.

Managers in an organization often ask analysts to query data warehouses for various types of information. Such ad hoc information requests might be as important as standard production, inventory, or sales reports, but ad hoc reporting has different data space needs. Ad hoc reports tends to have a lower frequency of repetition and broader query scope than standard daily production, inventory, or sales reporting. Ad hoc reports are usually best suited to temporary table space. The life spans of temporary table spaces begin and end with the user's SPD Server sessions.

Temporary table space is used for more than ad hoc user reporting. Even data warehouse queries and reports that use permanent table space use intermediate tables and calculation metadata to process queries. For example, the SPD Server SQL optimization process requires significant temporary table space while it heuristically finds the most efficient SQL strategy to resolve the query. Intermediate SPD Server tables and calculation metadata are normally deleted when the job terminates.

Any of the report types listed previously can require temporary table space for intermediate calculation tables. Temporary table space can be configured by normal SPD Server users via LIBNAME domain statements submitted during an SPD Server session. The key to creating temporary table spaces is to use the optional TEMP=YES specification when the LIBNAME domain statement is issued in submitted SPD Server job code. All tables residing in temporary table space are lost at the end of the SPD Server user session, when temporary table space is automatically deleted.