Illustrative Example of Logical Database Creation A small RAQUEL DB is created to illustrate what is involved as regards the logical schemas of a RAQUEL DB. Create a Database or ExampleDB <==Database ExampleDB <==Database[ User-ID ] The first statement assumes a DB with no access control this can be convenient for a single-user DB while the second assumes a DB with access control 1. Where logically possible, as here, RAQUEL allows parameters to be elided; the first statement illustrates the elision. These statements create a DB Schema called ExampleDB. Its creation incorporates the creation of all the system schemas within it, but no optional schemas. Of concern here are those schemas that support the logical relational model. The system schemas are the Logical Schema, Virtual Schema, Source Schema and Sink Schema, which are therefore all created. The optional schemas are the subschemas, and no subschemas are created. (Alternatively the set of subschemas is empty). Create Real Relvars First the DB must be opened so that the driver application (which delivers the RAQUEL statements to the DBMS for execution) can access the contents of the DB. The contents provide the environment and hence the scope for the RAQUEL statements that are executed thereafter. or ExampleDB <==Open ExampleDB <== Open[ User-ID ] depending on whether access permission is required or not. The User-ID parameter cannot be elided if access permission is required. To create real relvars (as opposed to optional subschemas), the Logical Schema must now be opened to provide the environment for this : Logical <==Open or Logical <== Open[ User-ID ] Let two real (or base) relvars, DEPT and EMP, now be created :- 1 The possibilities for access security in RAQUEL are not yet finalised, so there are no further details regarding security controls, passwords, permissions, etc. Page 1 of 10
DEPT <==Attribute[ DeptNo <== Text; Budget <== Number; Area <== { { North } { South } } ] EMP <==Attribute[ EmpNo <== Text; EName <== Text; DeptNo <== Text; Salary <== Number; Tax <== Number ] Notes : 1. The 2 attribute assignments create 2 real relvars by assigning a relational type (= reltype) to a relvar name. The type consists of a set of named attributes together with a data type for each attribute. Relvar DEPT has 3 attributes and EMP has 5 attributes. Both relvars have a relvalue which is an empty set of tuples. Both relvars have a default candidate key which consists of all the attributes in the relvar. 2. For simplicity, straightforward scalar data types are used as attribute types. The attribute Area has a type which consists of the 2 values North and South and which is expressed as a relvalue of 2 tuples of one attribute. (Relvalues are used to express a set of values). Because both values are text values, the type is treated as a subset of the Text scalar data type, with all the scalar operators applicable to Text values being applicable to values of this type. The type has not been given a name and so cannot be referenced by name. The relvars DEPT and EMP are now given the desired candidate keys :- DEPT <==Key[ Primary <== DeptNo ] EMP <==Key[ Primary <== EmpNo ] Notes : 1. Each relvar is only given one candidate key, which in both cases is called Primary. 2. When a relvar is assigned at least one candidate key, any default candidate key is removed as part of the same assignment. A foreign key is now assigned to EMP to ensure that its DeptNo attribute values are always values appearing in DEPT :- ( EMP Project[ DeptNo ] ) <==Integrity[ DeptNoForeignKey ] # Sub= ( DEPT Project[ DeptNo ] ) Notes : Page 2 of 10
1. The expression on the RHS of the <==Integrity assignment # Sub= ( DEPT Project[ DeptNo ] ) is assigned to the unnamed view (a form of pseudovariable) on the LHS EMP Project[ DeptNo ] as an integrity constraint. Every time the value of the unnamed view is to be changed, which will arise whenever a DeptNo attribute value of EMP is entered or amended, then the constraint must first be executed to check whether the change yields a valid result, and the change can only be made if it does. The name of the integrity constraint, DeptNoForeignKey, is given as the parameter of the <==Integrity assignment. 2. In the integrity constraint # Sub= ( DEPT Project[ DeptNo ] ) # represents the unnamed view on the LHS of the assignment, i.e. it represents EMP Project[ DeptNo ] Sub= is the textual representation of the mathematical. Hence the integrity constraint is that the DeptNo values in EMP must be a subset of or equal to the DeptNo values in DEPT. 3. <==Integrity is the standard assignment for assigning any kind of integrity constraint. Using a special assignment for referential integrity constraints has not been found beneficial. Referential integrity has been generalised to an Inclusion Constraint as first defined by E. F. Codd, and it is this kind of constraint which is assigned. The inclusion constraint is expressed as a set comparison between two sets of attributes, neither of which need be a candidate key. As well as Sub=, other set comparisons available are =, Sub meaning, and Super and Super= meaning and respectively. Create A Sink Relvar One or more sink relvars need to be created to receive the answers to queries. Therefore the Logical Schema must be closed (to exit from it) and the Sink Schema opened (to enter it), since the DBMS keeps each category of relvar in its own schema. Logical <==Close Sink <==Open or Sink <== Open[ User-ID ] Let a sink called USER now be created :- USER ==Sink[ /usr/user/userresults ] The sink relvar is bound to a specific file, which in this case is assumed to be a Unix/Linux file whose full name is /usr/user/userresults. The physical entity to which the relvar is bound could in principle be anything suitable. Page 3 of 10
The Sink Schema is now exited :- Sink <==Close The Physical Handling of Data When real relvars are created, such as DEPT and EMP, the physical storage to hold their relvalues is automatically created using the DBMS defaults. (The defaults are the standard ones or revised defaults specified as part of the DBMS installation). No further work is required, unless different physical storage arrangements to the defaults are immediately required. In order to provide Physical Data Independence, whatever initial physical storage arrangements are created, they can be changed at any time thereafter without losing the value(s) of the relevant relvar(s). When sink relvars are created, such as USER, the specification of the physical location and nature of the relvar outside the DB is an integral part of its creation; there are no defaults as they are not meaningful in this situation. The same applies to source relvars. However a sink or source relvar can be re-assigned at a later time to another physical entity if required; in this sense Physical Data Independence is provided. When a DB Schema is created, it may be useful if the driver application that supplies the creation statement to the DBMS immediately follows it with statements to create a suitable sink relvar (perhaps as a default). Adjust the DB for Ease of Use The following Venn diagram shows the all the relvars that have now been created within ExampleDB :- DB Schema ExampleDB Schema Virtual DEPT EMP USER Schema Logical Schema Sink Schema Source Each relvar is held in its appropriate standard schema. To use the DB raises the following concerns : 1. To access the relvars DEPT and EMP, first the schema ExampleDB must be accessed and then the schema Logical. Page 4 of 10
2. The sink relvar USER cannot be used with DEPT and EMP since it is in a different schema, the Sink Schema. (In fact to use USER requires that first the schema ExampleDB be accessed and then the schema Sink). A user can be in only one schema at any point in time. To solve these difficulties, a subschema can be created and the relvars DEPT, EMP and USER copied into it. A driver application can then directly enter that subschema let it be called CompanyDB - which would appear to that application as a complete DB containing DEPT, EMP and USER. Pictured as a Venn diagram, the situation would be :- DB Schema ExampleDB Subschema CompanyDB Schema Virtual DEPT EMP USER Schema Logical Schema Sink Schema Source The Subschema CompanyDB is drawn partly outside the DB Schema ExampleDB to illustrate the fact that it is visible outside ExampleDB. With the statement CompanyDB <==Open or CompanyDB <== Open[ User-ID ] a user can directly enter CompanyDB and use it (assuming the relevant access permissions) and know nothing at all about the existence of ExampleDB and its contents. As CompanyDB includes a sink relvar, queries can be executed that retrieve answers to that sink. The RAQUEL statements to produce the subschema are : 1. Ensure the driver application is at the schema level within the DB Schema ExampleDB. If the application has not yet opened ExampleDB, execute ExampleDB <==Open or ExampleDB <== Open[ User-ID ] If the application is using schema Logical or schema Sink within ExampleDB, execute Logical <==Close or Sink <==Close to raise the application s environment to be that of the schemas that are members of ExampleDB. Page 5 of 10
2. Create the subschema : or as required. CompanyDB <==Subschema CompanyDB <==Subschema[ User-ID ] 3. Copy the required relvars into CompanyDB : CompanyDB <--Copy { { DEPT } { EMP } { USER } } The names of the relvars to be copied into CompanyDB are expressed as a relvalue (of 3 tuples of one attribute) which contains their names. The <--Copy assignment executes at the schema level, so it requires both its left-hand operand and its right-hand operand to be schemas. However a schema comprises a set of members and is construed as a relvalue whose tuples constitute the members of the set. Therefore a relvalue is acceptable as a right-hand operand. DEPT, EMP and USER are not written with speech marks because they are not text values but relvar name values. If any of DEPT, EMP or USER did not exist in the Logical or Sink Schemas, the statement would not execute but return an error message. The DBMS looks in the system schemas to find the relevant relvars to copy into subschema CompanyDB. The relvars are not literally copied into CompanyDB, as this would result in 2 copies of each relvar. Rather the accessibility of the relvars is copied so that each relvar is accessible both from its system relvar and subschema CompanyDB. Alternative statements that could be used would be :- CompanyDB <--Copy Logical CompanyDB <--Copy Sink They would copy the contents of Logical and Sink into CompanyDB, which what is required in this case Note that this approach permits algebra expressions of schema variables to form the RHS operand of the <--Copy assignment. Therefore one could also write :- CompanyDB <--Copy Logical Union Sink Finally, an alternative approach that is simpler is :- 1. Create a DB Schema. In the example it would be ExampleDB. 2. Create a subschema within it. In the example it would be CompanyDB. Page 6 of 10
3. Create all the required relvars within the subschema. These relvars can be of any category. In the example they would be DEPT, EMP and USER. The DBMS automatically makes them all accessible in their respective system schemas, in this case the schemas Logical and Sink, at the time of their creation in the subschema. This approach requires no copying. Subschemas and their relvars are created as required, using the same statements as before, and the DBMS ensures that it keeps track of the overall DB situation by automatically making all relvars accessible in their respective system schemas. However relvars (of any category) that are to appear subsequently in a subschema additional to the original one, need to be copied to the additional subschema(s). They may be copied from the original subschema or the relevant system schema. Using Virtual Relvars (or Views) Let it be decided that, since the company falls naturally into a northern part and a southern part, that it would be useful to have a set of relvars that holds data on just the northern departments and employees, and another set that holds data on just the southern departments and employees. For consistency, the relvars in each set should be virtual relvars (or views) whose values are derived from those of the real relvars DEPT and EMP. For convenience let it also be decided that there be a subschema to hold the northern set of views and another subschema to hold the southern set. Finally let it be decided that, given the usage of the subschemas, it would be useful to have a second sink just to receive the answers to queries on the northern departments and employees, and a third sink just to receive the answers to queries on the southern departments and employees. Assuming the environment is that of the DB Schema ExampleDB, this could be accomplished as follows : 1. Create the subschemas : CompanyNorth <==Subschema CompanySouth <==Subschema 2. Access the CompanyNorth subschema : CompanyNorth <==Open 3. Create 2 appropriate virtual relvars for the northern subschema : DeptsNorth <--View DEPT Restrict[ Area = North ] EmpsNorth <--View EMP Project[ EmpNo, EName, DeptNo ] Join[[ DeptNo ] DeptsNorth Both virtual relvars appear in both the CompanyNorth subschema and in the Virtual schema. The expression defining view DeptsNorth is the restriction Page 7 of 10
of DEPT that returns all the northern departments. The expression defining view EmpsNorth first projects out the relevant attributes from EMP - the nonpayment data is assumed not to be of interest. That result is then left semijoined on DeptNo with the view DeptsNorth to yield just those tuples from it that represent employees from the northern departments. 4. Create a suitable sink relvar for the northern subschema : UsersNorth ==Sink[ /usr/usernorth/results ] The sink relvar UsersNorth appears in both the CompanyNorth subschema and in the Sink schema. 5. Access the CompanySouth subschema : CompanyNorth <==Close CompanySouth <==Open 6. Create 2 appropriate virtual relvars for the southern subschema : DeptsSouth <--View DEPT Restrict[ Area = South ] EmpsSouth <--View EMP Project[ EmpNo, EName, DeptNo ] Join[[ DeptNo ] DeptsSouth The corresponding views are created for southern departments and employees. 7. Create a suitable sink relvar for the southern subschema : UsersSouth ==Sink[ /usr/usersouth/results ] The corresponding sink relvar is created for southern departments and employees. 8. Exit the CompanySouth subschema : CompanySouth <==Close If preferred, the contents of the CompanySouth subschema could have been created first and those of the CompanyNorth subschema second. Suppose that by mistake, all 4 virtual relvars and both sink relvars had been created in the CompanyNorth subschema, leaving the CompanySouth subschema empty. To rectify the problem, views DeptsSouth and EmpsSouth and sink UsersSouth need to be moved out of CompanyNorth into CompanySouth. The problem may be solved as follows : 1. Execute any necessary statements to arrive at the schema level of abstraction within the DB Schema. 2. Move relvars DeptsSouth, EmpsSouth and UsersSouth to subschema CompanySouth : CompanySouth <--Move { { DeptsSouth } { EmpsSouth } { UsersSouth } } Page 8 of 10
The <--Move assignment executes at the schema level just the <--Copy assignment does; but as with <--Copy, a suitable relvalue can be used in lieu of a schema. The DBMS uses the system schemas to move the relevant relvars into subschema CompanySouth from CompanyNorth, leaving the remainder in CompanyNorth. The relvars are not literally moved to CompanySouth. Rather the accessibility of the relvars is changed so that each relvar is accessible from its system relvar and subschema CompanySouth, instead of from its system relvar and subschema CompanyNorth. A Venn diagram of the DB now looks as follows :- Subschema CompanyDB DB Schema ExampleDB Subschema CompanyNorth Schema Virtual UsersNorth DeptsNorth EmpsNorth DEPT EMP USER UsersSouth DeptsSouth EmpsSouth Schema Logical Schema Sink Subschema CompanySouth Schema Source Using RAQUEL Database Schemas The schemas are part of the RAQUEL formal model. Therefore they can be used in any way desired. It is suggested that there are two main kinds of usage. Firstly usage by end-user driver applications, which will typically use subschema(s) containing just those relvars relevant to the application(s); however in a small DB, this could be all the relvars in the DB. Secondly usage by DB Administration Tool driver applications, which will typically use system schemas and the DB Schema; however where a DB Page 9 of 10
contains many relvars, it may be useful to have several subschemas which together partition a system schema. Using Sources and Sinks Sources and sinks are part of the RAQUEL formal model. Therefore they can be used in any way desired. They will typically be used to associate a DB with external data locations, sinks in particular being used to receive the results of DB queries. However if the situation were pushed to the limit, one could envisage a pseudo DB consisting solely of a set of sources and sinks. The relvars of such a pseudo DB would not be under the complete control and management of the DBMS because they are external; but nevertheless within the limits this imposes, a driver application could manipulate the pseudo DB via the DBMS just as if would a proper DB. Page 10 of 10