Two main portions of the SAS Query Services model are the business model and the physical model. The business model is the logical layer on top of the physical model describing new data items, filters, prompts, etc. to be used in queries and based upon information in the physical model. The physical model is made up of objects that represent "raw" physical data ... such as relational tables and their columns ... and OLAP cubes and their contained dimensions and hierarchies, etc. The business model is where the user can incorporate their own business rules and logic to allow for creating the types of queries that make sense for their purposes.
So what "physical" means to the SAS Query Services model is that it represents the more basic units of information that are common in the DB industry -- units that represents the raw physical data -- tables, columns, cubes, etc.
Physical resources are essentially metadata objects that represent, or model, information about physical database-oriented objects. The word "resource" is used to represent something external to the business model ... it is a resource that the business model uses that is not really part of the model itself.
A physical resource is a type of resource used by business models to further define usable objects to, in the end, use in a query. For example, one can create a data item in a business model that represents an arbitrarily complex expression referencing columns physical resources. That data item can then be used in a query specification (the BusinessQuery interface).
Physical resources that are usable within the SAS Query Services model are defined in terms of the interfaces in the com.sas.iquery.metadata.physical package. This one set of interfaces is used to interact with the various implementations behind those interfaces.
Note: Extending an existing physical implementation or implementing ones own physical implementation behind these physical interfaces is currently not supported.
There are three sets of concrete objects behind the interfaces describing the physical resources in the com.sas.iquery.metadata.physical package. These implementation classes are either wrappers to repository objects of some sort or are in-memory implementations of the physical resources. The types of physical implementation classes we have are:
When a business model is read into memory from a persistent location, its physical resources that are wrappers to repository objects are "resurrected" -- causing the repository objects to be relocated to populate SAS Query Services's physical wrapper objects. For example, suppose a DataItem named "Total Salary" in an Information Map is defined to be two columns added together SALARY + INCREASE. When the map is brought back into memory from persistent storage, the definition of the data item is read and two OMAColumn objects are created to represent the SALARY and INCREASE columns. Each of these OMAColumn objects wrapper one of JOMA's Column objects, so as part of the reading in the model into memory, the JOMA objects representing the two columns that were used when the model was persisted to storage are located and inserted into these two OMAColumn wrapper objects.
SAS Query Services' models (information maps and the various types of data selections) must be readable and populated from persistent storage even when their resources could not be located when they are read into memory. This is a requirement that must be satisfied, otherwise the models would not be easily changeable -- to allow for replacement of a resources that could not be located. Another reason the model must always be readable and populated when missing resources exist is that if the model was part of a larger model it would impact the larger model if our model could not be populated. An example of this occurs when our data selections are used within reports.
We call a missing resource "unresolved" when it cannot be located when a model is read into memory. For example, suppose the OMS metadata column named INCREASE could not be found when the Information Map above was read into memory -- perhaps because the column was deleted or secured so by another user that disallowed this user to see the column. In that case when the definition of the data item is read into memory, two OMAColumn objects are again created just like when both metadata columns exist ... but the OMAColumn wrapper object associated with the INCREASE column is marked as "unresolved" and has no JOMA column object wrapped inside it. This causes the data item to become "unusable" in queries because its definition consists of an unresolved object -- which has no knowledge of its own except for information on where the object used to be located in the repository the last time the model was saved. When the data item becomes unusable in queries, any existing query that uses the data item now becomes "invalid" because a portion of the query definition is missing -- ultimately caused by the unresolved column.
When any object becomes unusable in a query, not only is that object unusable but any SAS Query Services model object that bases its definition on that object becomes unusable in queries. For example, supposed one had a Filter defined in the information map that is defined to be the (the "Total Salary" data item > 100000). This filter when used in queries causes data to be returned for total salaries that are greater than 100000. Because the data item is unusable in a query because it directly references an unresolved physical resource, the filter is unusable in a query because something it depends on for its definition is unusable.
So two general rules follow from this discussion:
There are other reasons for causing an SAS Query Services model object to become unusable in a query. The main one being that the object is malformed -- either incompletely filled in or that its definition is incompatible with another object. The latter case can happen because we're dealing with separately persistable models. Because one model may have no knowledge of the models that are based upon it, it's possible for someone to change the based-upon (parent) model in such a way to cause the dependent (child) models to become invalid. For example, suppose someone created an information map containing a data item named "transaction date" based upon a column with a date field. Someone else comes along and creates a report containing a query that filters on that "transaction date" ... and asks the query to return data for "transaction date" > June 1, 2002. That report runs, works, and is saved to a repository. Then the guy who created the information map comes in and changes the data item to be a formatted date ... essentially turning it into a character string. Once the information map is saved out with this new definition for the data item, the filter's definition in the report's query becomes unusable because the "transaction date" data item is of type character and cannot be directly compared like date values can. The filter becoming unusable causes the query to become invalid ... something that causes SAS Query Services' data services component to not attempt to run the query when asked to.
So how does one get their hands on these physical objects from the start when no model is created yet using the physical resources? That depends on the type of physical resource one wants.
In many cases one wants to use physical metadata from an OMS repository to base their information maps on. In those cases, SAS Query Services provides helper methods on the IntelligentQueryMetadataServiceInterface class for querying a repository for certain types of physical metadata. For example, suppose you want your information to access data via a SAS Library named OracleLibrary. You can get your hands on that library by using the IntelligentQueryMetadataServiceInterface.getSchemaWithLabel() method.
Note: One cannot use OMS repository objects (JOMA objects) gotten on ones own with IQ. IQ wraps all JOMA objects with its own wrapper objects that are from queries made through IQ methods. No support exists in IQ for creating a wrapper object from a general JOMA object and then using the wrapper object within IQ. The usage is: Use IQ for accumulating the physical metadata necessary from an OMS repository for creating information maps. The start of that accumulation usually starts with calls to the IntelligentQueryMetadataServiceInterface class. Depending on the type of objects returned by the method you call on that interface, one can usually get additional physical metadata objects via getter methods on the objects returned.
One can use a JFS Information Service object within an IQ Model by
todo: