A UML Profile for Developing Databases that Conform to The Third Manifesto
Authors: Erki Eessaar, Mattias Männil, Erki Ehtla
| Download | System Requirements | License | Installation | Creating and Checking Models | |||||
| Stereotypes | Controversy | An Example | Tutorial D Code Generator | Limitations |
This extension is intended for the old version of StarUML - StarUML 5.0
The Third Manifesto (TTM) describes the relational data model and tries to avoid the problems that are associated with SQL. The Third Manifesto is presented in the book:
Date, C. J., Darwen, H. (2006). Databases, Types, and The Relational Model, 3rd edition. Addison-Wesley.
TTM uses generic concepts variable, value, type, and operator to define the relational data model. According to TTM each database is a set of relational variables (relvars). Users of a database perform operations (by using operators) to assign new values (relations) to these variables and to derive new values based on the values of relvars.
The profile allows developers to create Type Design Diagrams (TDD) to specify types (data types) that can be used as the types of components of possible representations of scalar types, types of attributes, and types of parameters of operators. The profile allows developers to create Relvar Design Diagrams (RDD) to specify relational variables, integrity constraints that constrain the values of the relational variables, and operators. The diagrams are based on the UML class diagram. In addition, the profile has an associated script that allows developers to check the correctness of TTDs and RDDs in terms of the rules of the relational data model.
The profile is created based on the specification in the paper:
Eessaar, E. A UML Profile for Developing Databases that Conform to The Third Manifesto. In: Innovations in Computing Sciences and Software Engineering: International Conference on Systems, Computing Sciences and Software Engineering (SCSS 09).
Eds. T. Sobh, K. Elleithy. Springer Netherlands. ISBN: 978-90-481-9111-6, pp. 69-74 (2010) [SpringerLink]
In addition to the profile, there is a code generator that is able to generate statements in Tutorial D database language based on the models that are created by using the profile. The results of generating statements have been tested in relational database management system Rel (1.0.0). However, the generated statements can also be used in other database management systems that support Tutorial D language.
Download
- Version 1.0.1 (15 KB)
- Example model that is created by using the profile and Tutorial D code that is generated based on the model (10 KB)
System Requirements
- StarUML v.5.0
License
The profile is open-source and licenced under GNU General Public Licence (GPL) to encourage extension and collaboration.Installation
To install the module one has to unpack it and put the folder ttm-profile to the folder of StarUML modules.
The folder must contain subfolders.
To install the code generator one has to put the folder Tutorial D to the folder of StarUML generator templates.
Creating and Checking Models
To start the work one has to create a new project based on The Third Manifesto Approach.
By default the project will be created with one TDD and RDD. One can select model elements from the palette that is on the left.
To add a new diagram one has to select a diagram type from the Model Explorer and select Add Diagram.
Let us assume that we have created a RDD.
At any moment it is possible to check the correctness of the model. To do that one has to select Tools => TTM constraints.
The system displays results in Message window. Based on this information one can improve the model.
If we check the model again, then the system reports that it is now correct (no errors) in terms of the rules, the checking of which is implemented in the model checking script.
During the creation of TDDs and RDDs one has to register tagged values that correspond to the tag definitions in the profile. For instance, in case of an operation with stereotype <<Candidate key>> one has to register a comma-separated list of names of the attributes that belong to the key.
Firstly, one has to select the operation from Model Explorer and select Model => Tagged values.
After that one has to register the tagged value.
If one wants to see tagged values on the diagram, then he/she must select a class on the diagram and select Format => Show properties.
The resulting diagram shows tagged values that are directly or indirectly are associated with the selected class.
Stereotypes
For each stereotype, we name the diagram (TDD or RDD) that must be used to specify the corresponding model elements. For each stereotype, we also present tag definitions, the corresponding values of which one has to register during the creation of a new model. All the tag definitions must have at most one corresponding value in case of a correct model.Stereotypes of Class
- User-defined scalar type (TDD)
- init - Defines each possible representation in terms of the value being selected (how it is possible to find possible repesentations of a value based on other possible representations of the value). It must be defined if a type has more than one possible representation.
- Tuple type (TDD)
- Relation type (TDD)
- Base relvar (RDD)
- init_relational_expression - An expression denoting a relation. It specifies the initial value of the base relvar and must have the same type as the relvar.
- Snapshot (RDD)
- relational_expression - An expression denoting a relation.
- now_and_then - Specifies when the snapshot is refreshed.
- Virtual relvar (RDD)
- relational_expression - An expression denoting a relation.
- Set of constraints (RDD)
- Set of operators (RDD)
Stereotypes of Attribute
- Component (TDD) - Attribute in User-defined scalar type.
- name_of_possrep - Name of a possible representation of a scalar type, a part of which is the component.
Stereotypes of Operation
- User-defined read-only operator (RDD) - Operation in Set of operators.
- User-defined update operator (RDD) - Operation in Set of operators.
- subject_to_update - A comma-separated list of names of parameters that are subject to update. The order of the names in the list is unimportant.
- Candidate key (RDD) - Operation in Base relvar, Virtual relvar, Snapshot.
- attributes_in_key - A comma-separated list of names of attributes that belong to the key. The order of the names in the list is unimportant.
- Foreign key (RDD) - Operation in Base relvar, Virtual relvar, Snapshot.
- attributes_in_key - A comma-separated list of names of attributes that belong to the key. The order of the names in the list is unimportant.
- referenced_relvar - The name of a relvar that is the referenced (parent) relvar in the context of the foreign key constraint.
- attributes_in_referenced_relvar_key - A comma-separated list of names of attributes of the referenced relvar R that form a candidate key of R. The order of the names in the list must correspond to the order of attributes in the list attributes_in_key.
- on_delete - Specifies compensating action. Possible values: {NO ACTION, CASCADE, SET DEFAULT}
- on_update - Specifies compensating action. Possible values: {NO ACTION, CASCADE, SET DEFAULT}
- Type constraint (TDD) - Operation in User-defined scalar type.
- boolean_expression - An expression denoting a truth value (TRUE or FALSE).
- name_of_possrep - Name of a possrep, the part of which is the current type constraint.
- Relvar constraint (RDD) - Operation in Set of constraints.
- boolean_expression - An expression denoting a truth value (TRUE or FALSE).
- Database constraint (RDD) - Operation in Set of constraints.
- boolean_expression - An expression denoting a truth value (TRUE or FALSE).
Controversy
UML forces us to represent some TTM constructs in a way that is not consistent with the principles of TTM.- One has to represent relation types as stereotyped classes. It may give a wrong idea that TTM supports the creation relation types for the later usage. Actually it is not the case and TTM does not support the creation of relation types for the later usage. If one wants to use a relation type, then he/she must invoke the relation type generator operator that returns a specific relation type. We used such representation to facilitate the use of relation types as types of components, attributes, and parameters. If one defines a relation type, then the type must have name RELATION{H}, where H is a heading.
- One has to represent tuple types as stereotyped classes. It may give a wrong idea that TTM supports the creation tuple types for the later usage. Actually it is not the case and TTM does not support the creation of tuple types for the later usage. If one wants to use a tuple type, then he/she must invoke the tuple type generator operator that returns a specific tuple type. We used such representation to facilitate the use of tuple types as types of components, attributes, and parameters. If one defines a tuple type, then the type must have name TUPLE{H}, where H is a heading.
- One has to represent user-defined read-only operators and update operators as operations of a class that has stereotype Set of operators. TTM does not describe Set of operators as an explicit construct, for the creation of which one has to use a separate database language statement. We had to use such representation to avoid mixing of type descriptions or relvar descriptions with the descriptions of operators. However, such construct might actually be useful in models because it allows to manage complexity by creating different sets of related operators.
- One has to represent relvar constraints and database constraints as as operations of a class that has stereotype Set of constraints. TTM does not describe Set of constraints as an explicit construct, for the creation of which one has to use a separate database language statement. We had to use such representation to reduce mixing relvar descriptions with the descriptions of integrity constraints. However, such construct might actually be useful in models because it allows to manage complexity by creating different sets of related constraints.
- Exception to the previous point - the profile allows users to represent candidate key constraints and foreign key constraints (that are also relvar or database constraints) as operations of classes that represent relational variables. We made such decision, because this kind of constraints are important special cases. However, one could also choose to represent candidate key and foreign key constraints as operators that have stereotype Relvar constraint or Database constraint.
We repeat, that it is just the question of representation of the specification. For instance, if there is a code generation program, then it should take into account the previous points and generate correct database language statements based on this kind of specification.
The specification that is created by using this profile may contain redundancy and developers must be very careful to avoid inconsistencies.
- Each relation type has a set of attributes. This information is repeated in the name of a relation type.
- Each tuple type has a set of attributes. This information is repeated in the name of a tuple type.
- Each virtual relvar has a set of attributes. It is also possible to find the attributes by evaluating relational expression that is associated with a virtual relvar.
- Each snapshot has a set of attributes. It is also possible to find the attributes by evaluating relational expression that is associated with a snapshot.
An Example
Here you can see an example of Type Design Diagram.
Here you can see an example of Relvar Design Diagram.
Tutorial D Code Generator
In addition to the profile, there is a code generator that is able to generate statements in Tutorial D database language based on the models that are created by using the profile. The results of generating statements have been tested in relational database management system Rel (1.0.0). However, the generated statements can also be used in other database management systems that support Tutorial D language.
Before starting the generation it is advisable to run the program for checking the model and to improve the model, if necessary. To start the generation of Tutorial D database language statements one has to select Tools=>StarUML Generator ...
Next, one has to activate Tutorial D code template and click on the button Next.
Next, one has to determine the folder and click on the button Next. The system will put generated files to the selected folder. The system generates two files - tutorial_d_commands.txt that contains statements for creating database objects (relvars, constraints, etc.) and tutorial_d_drop_commands.txt that contains statements for removing the database objects.
To start the generation, one has to click on the button Generate.
The result is following. One has to open the previously specified folder to see the generated files.
In this case the file tutorial_d_commands.txt has the following content.
/*Creation time: Sun Aug 22 13:57:26 2010
Generator version: 1.0*/
/*Scalar types*/
TYPE Point
POSSREP cartesian {X RATIONAL, Y RATIONAL}
POSSREP polar {R RATIONAL, THETA RATIONAL}
INIT cartesian (R := SQRT(X * X + Y * Y), THETA := ATAN(Y / X)) polar (X := R * COS(THETA), Y := R * SIN(THETA));
TYPE AddressType
POSSREP address {street CHAR, number INTEGER, city CHAR, state CHAR CONSTRAINT number>=0};
/*Relational base variables*/
VAR Student
BASE RELATION {id_person INTEGER, reserves RELATION {id_computer INTEGER, status CHAR}}
KEY {id_person};
VAR Person
BASE RELATION {id_person INTEGER, name CHAR, e_mail CHAR, address AddressType}
INIT (RELATION {TUPLE{id_person 1, name 'John', e_mail 'John.Smith@gmail.com', address address("Pikk", 1, "Tallinn","Estonia")}})
KEY {id_person}
KEY {e_mail};
VAR Teacher
BASE RELATION {id_person INTEGER, reserves RELATION {id_c_room INTEGER, building CHAR, campus CHAR}, telephone TUPLE {telephone1 CHAR, telephone2 CHAR}}
KEY {id_person};
/*Virtual relational variables*/
VAR Person_student VIRTUAL (Person JOIN Student)
KEY {id_person}
KEY {e_mail};
VAR Person_teacher VIRTUAL (Person JOIN Teacher)
KEY {id_person}
KEY {e_mail};
/*Foreign key constraints*/
CONSTRAINT fk_student_person IS_EMPTY (Student {id_person} NOT MATCHING Person {id_person});
CONSTRAINT fk_teacher_person IS_EMPTY (Teacher {id_person} NOT MATCHING Person {id_person});
/*Other relvar and database constraints*/
CONSTRAINT Student_at_most_100_reserves IS_EMPTY(SUMMARIZE Student UNGROUP (reserves) BY{id_person} ADD (Count() AS card) WHERE NOT (card<=1));
CONSTRAINT Teacher_at_most_100_reserves IS_EMPTY(SUMMARIZE Teacher UNGROUP (reserves) BY{id_person} ADD (Count() AS card) WHERE NOT (card<=100));
CONSTRAINT More_students Count(Student)>=Count(Teacher);
/*User-defined read-only operators*/
OPERATOR find_person (id INTEGER) RETURNS RELATION {name CHAR};
RETURN (Person WHERE id_person=id){name};
END OPERATOR;
/*User-defined update operators
The code for implementing update operators cannot be executed in Rel 1.0.0
because UPDATES parameter modifier is not implemented yet.
An example of update operator in Rel 1.0.0:
OPERATOR delete_student (id INTEGER) UPDATES {};
DELETE Student WHERE id_person=id;
END OPERATOR;
Student is the name of a relational variable.
*/
OPERATOR delete_student (S RELATION {id_person INTEGER, reserves RELATION {id_computer INTEGER, status CHAR}}, id INTEGER) UPDATES {S};
DELETE S WHERE id_person=id;
END OPERATOR;
In this case the file tutorial_d_drop_commands.txt has the following content.
/*Creation time: Sun Aug 22 13:57:26 2010
Generator version: 1.0*/
/*User-defined update operators*/
DROP OPERATOR delete_student (RELATION {id_person INTEGER, name CHAR, e_mail CHAR, address AddressType}, INTEGER);
/*User-defined read-only operators*/
DROP OPERATOR find_person (INTEGER);
/*Other relvar and database constraints*/
DROP CONSTRAINT More_students;
DROP CONSTRAINT Teacher_at_most_100_reserves;
DROP CONSTRAINT Student_at_most_100_reserves;
/*Foreign key constraints*/
DROP CONSTRAINT fk_teacher_person;
DROP CONSTRAINT fk_student_person;
/*Virtual relational variables*/
DROP VAR Person_teacher;
DROP VAR Person_student;
/*Relational base variables*/
DROP VAR Teacher;
DROP VAR Person;
DROP VAR Student;
/*Scalar types*/
DROP TYPE AddressType;
DROP TYPE Point;
It is possible to execute these commands in Rel database management system.
Limitations
- The diagrams do not provide different visual representations (in addition to stereotype labels) for different types of model elements.
- The script for checking correctness of models does not parse and check correctness of tagged values. Hence, it is possible that a model contains mistakes but the checking script does not discover that. For instance, it is possible that the value that corresponds to the tag definition relational_expression is actually not a relational expression. One can discover such mistakes by generating Tutorial D code and executing it. In this case it is possible to improve the model and generate a new version of code.
- The code generator does not consider dependencies between different database objects and hence it is possible that one cannot execute generated statements in the same order as in the file.
- The code generator does not modify identifiers to make them correct according to the dialect of Tutorial D provided by Rel. The reason is that users can write relational expressions to the model and these expressions can contain identifiers. However, the generator program does not parse these expressions and hence it could happen that identifiers in the relational expressions and identifiers of relvars will be different.
- The profile does not support the use of subtyping and inheritance to specify new types. The book "Date, C. J., Darwen, H. (2006). Databases, Types, and The Relational Model, 3rd edition. Addison-Wesley." actually specifies the inheritance model for that purpose.
- The tool does not address normalization and the principle of orthogonal design - if one wants to redesign relvars in terms of these principles, then he/she has to redraw diagrams but the system does not assist him/her in any way.
- Rel 1.0.0 does not yet implement UPDATES parameter modifier. Hence, one cannot execute the generated statements for creating UPDATE operators without modification.
- Rel 1.0.0 does not support snapshots. Hence, the code generation system does not generate statements for creating and removing snapshots and foreign key constraints for snapshots.