Domains and Data Spaces

You can configure SPD Server to meet different data requirements. If you need different types of SPD Server domain space, you 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 types of data space that the user needs. The following figure shows the 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 5-year sales data table organized by division and company is an example of an SPD Server structure that is most suitable for permanently allocated space on the enterprise computers. If you have this type of table, large quantities of production, inventory, or sales data can be updated on a day-to-day, or even shift-to-shift, basis. These data repositories require permanent, secure processing space that can be accessed only by a select group of users. When you allocate permanent space for the data, you ensure that disk space that is required for combining and manipulating 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 (although not as critical as the production, inventory, or sales data) should also use permanently defined data spaces that are separate from the permanent table spaces devoted to production reporting. In this situation, permanent table space should be accessible to a specific group (such as analysts) of regular SPD Server users.

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

You can grant user access to permanent table spaces by using individual user account access privileges, or by establishing an ACL group of approved users through the owner of the domain. LIBNAME domain statements create permanent table space by default.

Organizations often have short-term data mining projects that rely on production, inventory, or sales data. Sometimes the organization changes how the data is processed, or augments the production, inventory, or sales data with additional information. These projects should be conducted in a test data space, isolated from the permanent space that is dedicated to critical production, inventory, or sales data. This design lets development trials be conducted without the risk of corrupting mission-critical data.

For example, the test data space that is used for a month-long development project could be considered a semi-permanent space; you need to grant access to an area where data can safely exist, isolated from production, sales, or inventory data, for a period of time that is longer than a single SPD Server user session. The test environment should persist long enough for works-in-progress to mature to production-quality, 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.

SPD Server administrators and SPD Server users can configure semi-permanent table space. However, administrators should 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 requests might be as important as standard reports, but ad hoc reporting has different data space needs. Ad hoc reports usually have a lower frequency of repetition and a broader query scope than standard daily reporting does. Ad hoc reports are usually suitable for temporary table space. The life span of temporary table spaces begin and end with the user's SPD Server sessions.

You can use temporary table space 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 a query. Intermediate SPD Server tables and calculation metadata are usually deleted when the job terminates.

Any report might require temporary table space for intermediate calculation tables. SPD Server users can configure temporary table space with the LIBNAME domain statements that they submit during an SPD Server session. To create temporary table space, users specify the optional TEMP=YES option when they issue the LIBNAME domain statement in the SPD Server job code. All tables in temporary table space are lost at the end of the SPD Server user session, when temporary table space is automatically deleted.