Illustrative Example of Logical Database Creation

Transcription

1 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 includes the creation of all the system schemas within it, i.e. the schemas that support the relational model which are the Logical Schema, the Virtual Schema, the View mapping Schema, and an empty set of Subschemas and those that support physical data storage on the local computer. Create Real Relvars First the DB must be opened so that the user application 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. The contents of ExampleDB are the standard set of schemas. Therefore to create real relvars (as opposed to a schema), the Logical Schema must now be opened to provide the scope for this : Logical <==Open or Logical <== Open[ User-ID ] Let two real (or base) relvars, DEPT and EMP, now be created :- DEPT <==Attribute[ DeptNo <== Text; Budget <== Number; Area <== { { North } { South } } ] 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 7

2 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 : 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. Page 2 of 7

3 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. Making the DB Easier to Use The following Venn diagram shows the relvars within the relational set schemas of ExampleDB :- DB Schema ExampleDB DEPT EMP Schema Logical Schema Virtual Thus to use the DB requires accessing the schemas ExampleDB and then Logical in order to access the relvars DEPT and EMP. To avoid the inconvenience of this, a Subschema could be created and the relvars DEPT and EMP copied into it. A user application can then enter that Subschema let it be called CompanyDB - directly; it would appear as a complete DB to that application. Pictured as a Venn diagram, the situation would be :- Page 3 of 7

4 DB Schema ExampleDB Subschema CompanyDB DEPT EMP Schema Logical Schema Virtual 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. The RAQUEL statements to produce the Subschema are : 1. Ensure the user 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 within ExampleDB, execute Logical <==Close to raise the application s level of abstraction to be that of the schemas that are members of ExampleDB. 2. Create the Subschema : or as required. CompanyDB <==Subschema CompanyDB <==Subschema[ User-ID ] 3. Copy the required relvars into CompanyDB : CompanyDB <--Copy { { DEPT } { EMP } } The names of the relvars to be copied into CompanyDB are expressed as a relvalue (of 2 tuples of one attribute) which contains their names. DEPT and EMP are not written with speech marks because they are not text values but relvar name values. By default, the DBMS looks in the Logical and Virtual Page 4 of 7

5 Schemas to find the relvars DEPT and EMP so that the correct information can be copied into Subschema CompanyDB. If either DEPT or EMP had not existed in the Logical or Virtual Schemas, the statement would not execute but return an error message. An alternative statement that could be used would be : CompanyDB <--Copy Logical This would copy the contents of Logical into CompanyDB, which what is required in this case N.B. An advantage of this approach to copying is that it permits the writing of relational algebra expressions that exploit meta data about schemas in order to generate a value for the RHS operand of the <--Copy assignment. The Physical Storage of Data When the relvars DEPT and EMP are created, the physical storage to hold their relvalues is automatically created using the DBMS defaults. The defaults are the standard ones or revised defaults specified for the DBMS installation. No further work is required, unless it is desired to tune the relvars physical storage or create quite different physical storage arrangements for them. Using Virtual Relvars 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 one Subschema holding data on the northern departments and employees and a second on the southern departments and employees. Given a user application in the ExampleDB environment (i.e. is at the schema level within the ExampleDB), the statements to achieve this are as follows : 1. Create the Subschemas : CompanyNorth <==Subschema CompanySouth <==Subschema 2. Create 2 virtual relvars, one for the northern departments and one for the southern : DeptsNorth <--View DEPT Restrict[ Area = North ] DeptsSouth <--View DEPT Restrict[ Area = South ] Both virtual relvars are created in the Virtual schema. 3. Create 2 virtual relvars, one for the northern employees and one for the southern, but each containing only the non-payment data (which is assumed to be of interest only to the company head office) : EmpsNorth <--View EMP Project[ EmpNo, EName, DeptNo ] Join[[ DeptNo ] DeptsNorth Page 5 of 7

6 EmpsSouth <--View EMP Project[ EmpNo, EName, DeptNo ] Join[[ DeptNo ] DeptsSouth Both virtual relvars are created in the Virtual schema. The expressions defining the views first project out the relevant attributes from EMP; the result is then left semi-joined on DeptNo with an operand containing the northern or southern departments. as required. The result of a left semi-join contains only tuples from the left-hand operand that match the tuples of the right-hand operand (which in this case is itself a virtual relvar). 4. Copy the relevant virtual relvars into the relevant Subschemas : CompanyNorth <--Copy { { DeptsNorth } { EmpsNorth } } CompanySouth <--Copy { { DeptsSouth } { EmpsSouth } } Note that if preferred, step 1 could have been carried out after steps 2 and 3 and before step 4. Suppose that by mistake, the following copy statement had been executed instead of step 4 : CompanyNorth <--Copy Virtual This would have copied all 4 virtual relvars into the CompanyNorth schema. To rectify the problem, relvars CompanySouth and EmpsSouth need to be moved out of Subschema CompanyNorth into Subschema CompanySouth. However the <--Move and <--Copy assignments only accept schema names as their LHS operands and schema values as their RHS operands; a relvalue of relvar names is accepted as a schema value because a schema can be construed as a set of relvar names, where the set is expressed as a one-attribute relation. The problem may be solved by executing the following sequence of statements : 1. Move from the ExampleDB environment to the CompanyNorth environment (i.e. to the relvar level within CompanyNorth ) : CompanyNorth <==Open 2. Move relvars CompanySouth and EmpsSouth to CompanySouth : CompanySouth <--Move { { DeptsSouth } { EmpsSouth } } 3. Move back to the ExampleDB environment : CompanyNorth <==Close This closes the current level of abstraction leaving the user application at the higher ExampleDB level of abstraction. A Venn diagram of the all the relational model set schemas in the DB now looks as follows :- Page 6 of 7

7 Subschema CompanyDB Subschema CompanyNorth Subschema CompanySouth DEPT DeptsNorth DeptsSouth EMP EmpsNorth EmpsSouth Schema Logical DB Schema ExampleDB Schema Virtual Using RAQUEL Database Schemas The schemas are part of the RAQUEL formal model. Therefore they can be used in any way desired. However it is suggested that there are two main kinds of usage. Firstly usage by end-user applications. Such usage typically requires access to just those relvars relevant to the application. (In a small DB, this could be all the relvars in the DB). Secondly usage by DB Administrator applications, which typically involves the entire DB. In the above example, the schemas likely to be of interest an end-user application would be : Subschema CompanyNorth for applications requiring (non-payment) data about the northern part of the company. Subschema CompanySouth for applications requiring (non-payment) data about the southern part of the company. Subschema CompanyDB for applications requiring data about the entire company. The schemas likely to be of interest to a DB Administrator application would be : DB Schema ExampleDB in order to manage the complete DB. Subschema CompanyDB in order to easily see all the relvars in the DB. Page 7 of 7