Domains and Data Spaces

You can configure SPD Server to meet different data requirements. If you need different types of domain space, you can define domains in the libnames.parm parameter 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 tablespaces. 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 tablespace. 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 tablespaces devoted to production reporting. In this situation, permanent tablespace should be accessible to a specific group (such as analysts) of regular SPD Server users.

You can use the libnames.parm parameter 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 tablespace, use the DATAPATH=, INDEXPATH=, and OWNER= options to specify unique, appropriately sized disk areas for data tables and index tables. The OWNER= options configures ownership and access. You must ensure that the paths specified for a domain have access to sufficient disk space.

You can grant user access to permanent tablespaces by using individual user account access privileges, or by establishing an ACL group of approved users through the owner of the domain. Permanent tablespace is created 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. 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 users can configure semi-permanent tablespace. However, administrators should allocate semi-permanent spaces using the libnames.parm parameter 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 tablespace. The life span of temporary tablespaces begin and end with the user's SPD Server sessions.

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

Any report might require temporary tablespace for intermediate calculation tables. SPD Server users can configure temporary tablespace by setting the TEMP=YES LIBNAME option in the LIBNAME statement that connects their SAS session to the server. All tables in temporary tablespace are lost at the end of the SPD Server user session, when temporary tablespace is automatically deleted.