It may be desirable to prevent applications from directly accessing some of the information related to employees, such as personal information (e.g., information to be processed in the compensation operation and the value of the employment date attribute). The reasons for this are listed as follows:
- Direct access from an application is not desirable in order to protect confidentiality.
- Example
The value of the salary attribute may be referenced in internal processing of routines such as compensation but should not be directly accessible from the outside.
- Direct access from an application is meaningless.
- Example
If job performance evaluation results are encoded and held as attribute values, accessing these values from an application will be of no use.
- It is necessary to prevent an application from directly altering internal information.
- Example
It is necessary to prevent an application from changing the value of the employment date attribute to a different date.
- Organization of this subsection
- (1) Encapsulation level
In HiRDB, it is possible to specify an encapsulation level during the declaration of abstract data types and routines.
The following three encapsulation levels are available:
- PRIVATE
- Attribute values can be accessed and routines can be used only within the definition of an abstract data type.
- For example, PRIVATE may be specified for the t_employee type attribute employment date.
- When PRIVATE is specified for an attribute, it will not be possible to access this attribute or to use a routine from inside a subtype definition or an application.
- PROTECTED
- Attribute values can be accessed and routines can be used only within the definition of an abstract data type and within the definition of subtypes of that abstract data type.
- For example, PROTECTED may be specified for the t_employee type routine compensation. This will allow t_salesperson (i.e., a subtype of t_employee type) to execute the compensation rate routine in order to calculate compensation rate, without directly referencing the attribute employment date or knowing the processing details of compensation rate (calculation of service years based on the employment date, and calculation of a compensation rate based on this value).
- PUBLIC
- No restrictions are placed, as with PRIVATE or PROTECTED, and attribute values can be accessed and routines can be used from within the definitions of other abstract data types and subtypes, as well as from applications.
- For example, PUBLIC may be specified for the service years routine for which there is no access restriction.
Table 3-8 shows the encapsulation levels and their degrees of accessibility to abstract data type values and routines.
Table 3-8 Encapsulation levels and access types
| Encapsulation level |
Access source |
| Within the definition of an abstract data type |
Within the definition of a subtype abstract data type |
Within the definitions of abstract data types other than those listed on the left |
Applications |
| PUBLIC |
Y |
Y |
Y |
Y |
| PROTECTED |
Y |
Y |
N |
N |
| PRIVATE |
Y |
N |
N |
N |
Y: Can access abstract data type values and can use routines.
N: Cannot access abstract data type values and cannot use routines (an SQL error occurs).
Figure 3-40 shows an example of the relationship between encapsulation levels and access types for abstract data type T.
Figure 3-40 Encapsulation levels and access types
![[Figure]](FIGURE/ZU030350.GIF)
For details about the procedures for designing and creating a table for which an abstract data type is defined, see the HiRDB Version 8 Installation and Design Guide. For details about the procedures for manipulating a table for which an abstract data type is defined, see the HiRDB Version 8 UAP Development Guide.
All Rights Reserved. Copyright (C) 2007, Hitachi, Ltd.
![[Contents]](FIGURE/CONTENT.GIF)
![[Glossary]](FIGURE/GLOSS.GIF)
![[Index]](FIGURE/INDEX.GIF)
![[Back]](FIGURE/FRONT.GIF)
![[Next]](FIGURE/AFTER.GIF)