Today we continue our discussion on DBPowder. We briefly reviewed the data models - namely the EER model, the Object model and the relational model. We now see how to use the EER model for simple correspondences and ORM processes. When the developer describes the EER model and the DBPowder generates the corresponding spc object model and the rs relational model, it follows this process:
1) In eer, A surrogate key is added to each entity where primary key may have been omitted.
2) Each table and an attribute in rs is generated with one to one correspondence to an entity and an attribute in EER. The relationship is used to add foreign keys to either side of the tables. Hierarchies are denoted later.
3) For each table, an attribute and a foreign key in rs, a class, attribute and relationship in spc is generated. Each relationship is converted into a bidirectional one by adding an inverse relationship. The cardinality is also added by looking it up in the EER.
The hierarchies were reserved for after step 3 because they are not directly mapped to the rs. Instead three methods are used.
1) Single Relational Inheritance - all of the classes in the a generalization hierarchy are mapped onto one table.
2) Class Relational Inheritance - each class in the hierarchy is mapped one to one into one table.
3) Concrete Class Relational Inheritance - each concrete class in a generalization hierarchy is mapped one to one into one table.
In the example describing user generalization earlier, SR was used.
The reg_date attribute of register entity proves tricky because a user has a many to many relationship to a host, and a SR relationship between persistent classes of User and Host cannot handle this attribute reg_date because reg_date is unidirectional.
For complex correspondences DBPowder introduces ObjectView. The process now continues as :
4) The Object View descriptions are denoted first:
1) specifications of entities and relationships in the EER model use a directed graph.
2) Nodes are grouped within a subgraph of the directed graph by combining the nodes which have a relationships of one-connectivity.
3) class definitions are then generated from the group nodes using structured literal and interface.
1) In eer, A surrogate key is added to each entity where primary key may have been omitted.
2) Each table and an attribute in rs is generated with one to one correspondence to an entity and an attribute in EER. The relationship is used to add foreign keys to either side of the tables. Hierarchies are denoted later.
3) For each table, an attribute and a foreign key in rs, a class, attribute and relationship in spc is generated. Each relationship is converted into a bidirectional one by adding an inverse relationship. The cardinality is also added by looking it up in the EER.
The hierarchies were reserved for after step 3 because they are not directly mapped to the rs. Instead three methods are used.
1) Single Relational Inheritance - all of the classes in the a generalization hierarchy are mapped onto one table.
2) Class Relational Inheritance - each class in the hierarchy is mapped one to one into one table.
3) Concrete Class Relational Inheritance - each concrete class in a generalization hierarchy is mapped one to one into one table.
In the example describing user generalization earlier, SR was used.
The reg_date attribute of register entity proves tricky because a user has a many to many relationship to a host, and a SR relationship between persistent classes of User and Host cannot handle this attribute reg_date because reg_date is unidirectional.
For complex correspondences DBPowder introduces ObjectView. The process now continues as :
4) The Object View descriptions are denoted first:
1) specifications of entities and relationships in the EER model use a directed graph.
2) Nodes are grouped within a subgraph of the directed graph by combining the nodes which have a relationships of one-connectivity.
3) class definitions are then generated from the group nodes using structured literal and interface.
No comments:
Post a Comment