Today  we wrap your discussion on DBPowder. We saw the ORM framework and it's processes. We saw the flexibility  for both simple and complex correspondences. We saw the use of Active record for data wrapper and data classes. When the developer describes the eer model, the relation classes and ObjectView are generated. In this case the process kicks off by mapping tables to entities with a one to one  mapping. The attributes of the conceptual model become attributes of the table and the entities. Then the relationships are established and their cardinality is specified. With the help of this information from the conceptual model we can then add the biderctional attributes to tables and classes. Sometimes it is easier to ease the relationship into a new entity and this is one of the flexibility offered by DBPowder in its code generation. For examples a user table having many different users  registering different hosts has many registration dates that cannot be attributes in the user or hosts table . Next we add hierarchy information and this is possible in one of three different ways.
The complex correspondences are described using the ObjectView where a graph based object is used to generate the cpc equivalences in complex correspondences with rs. This ObjectView takes application logic into account as well. A pivot entity is chosen which is the starting point,  connectivity for the edges are established along with that of the relationship and cardinality set. The nodes and edges for a hierarchy are defined along with a direction from parent entity to child entity. Then the nodes within the subgraph of the directed graph which have one-connectivity are combined to form a group.  Class definitions are generated from the grouped node.
The code generator generates the source code for the relational schema with the relational tables so far and their corresponding simple persistent classes for the simple correspondences. It also generates the source code for the complex persistent classes with the eer and the specific object views. With the help of ActiveRecords, we move away from many to many correspondences between persistent classes and tables to one to one correspondences between ActiveRecords and tables.

#codingexercise

GetAllNumberRangeProductSeventhRootPowerTen(Double [] A)


{




if (A == null) return 0;




Return A.AllNumberRangeProductSeventhRootPowerTen();



}

Today we continue our discussion on DB powder. Using DBPowder and ObjectView, developers can come up with a number of persistent classes along with each part of the application logic. In this case, a table might be used by more than one persistent class. There are many to many correspondences among persistent classes and tables and the persistent classes hold the values. Now if there are persistent objects in the same session, and they hold the same attribute value, in the same tuple, they cannot recognize each other that the attribute value is the same.  To solve this issue, DBPowder leverages ActiveRecord. The data wrapper classes and the data classes access tables using ActiveRecords. Because values of data wrappers are held in ActiveRecords and each of the data wrapper is the wrapper class of the Active Records,values in data wrapper can have a single correspondence with those in the tables. As a result, each persistent class can recognize each other that the attribute value is the same.
We now look at a Prototype system of DBPowder and a production use. The first version of the prototype system for DBPowder was implemented in JavaSE in  2006. In this paper, EER model and ObjectView support were added. The prototype included a description language, DBPowder-mdl and has a parser and code generator to interpret DBPowder-mdl and generate source code.  The prototype also generates simple web pages for create, retrieve, update and delete operations. DBPowder-mdl, the parser and the GEN were refined in this paper.
The set of web applications and the DBPowder system was applied in production for the security administration task and refined. The same set of applications were deployed to another site where the number of users in two sites were 130.

Today we continue the discussion on DB-Powder  description language - the DBPowder mdl.  The goal of this language is to allow developers to describe the conceptual model. As we have seen in the previous posts, that DBPowder uses a process to generate code and tables with this model. The description style of DBPowder-mdl is either EER-style or Object-View style. The EER style primitives are Entity E, Attribute A and linked-entity L.  The primitives are described in hierarchical structure.  Primary keys can be omitted because DBPowder assigns surrogate keys.
To extend the hierarchical structure into a graph, E and L can be described more than once. We saw that generalization hierarchies are supported by  Single Relation (SR), Class Relation Inheritance (CR), and Concrete Class Relation Inheritance (CCR).
The Object-View style primitives are the pivot-entity PE and the member-entity ME.
The code generation generates the source code using the EER model or the Object View. Developers add application codes using the generated class and built-in session class. The code generator represents the EER, Object View and the ORM processes and this helps to generate the relational schema and persistent classes. The latter include data wrapper class, logic class and a session class. A sample usage of the application codes involves developers to hold the values in the data wrappers using the getter/setter methods and then presist the values into session classes using CRUD methods such as insert, find, update delete etc. This is achieved because the data classes are using ActiveRecords and the data wrapper has correspondence with tables via the ActiveRecords.
#codingexercise



GetAllNumberRangeSumSeventhRootPowerTen(Double [] A)



{



if (A == null) return 0;



Return A.AllNumberRangeSumSeventhRootPowerTen();


}

Today we continue the discussion  on DBPowder. We noted earlier the process involved in the code generation, specifically given a conceptual model, how to map relational and object model. When EER is modeled using a directed graph, the starting entity is called the pivot entity. Connectivity on the edge is defined along with that of the corresponding relationship.Hierarchy is represented by directional edges from parent entity to child entity. When representing relationship, if there are attributes to the relationship, then they belong to the connected node to which the connectivity is many.If there are more than one path from the starting point to E, E has to fill all the conditions that correspond to the incoming edges. If this is not preferable, ObjectView can reduce the number of incoming edges by introducing another corresponded node and modifying one of the paths to use this node.  When grouping of nodes within a sub-graph, we form with those where the connectivity of the corresponding relationship is one. ObjectView arranges the class definitions generated from the grouped node  using the keywords structured, literal and interface. The structured literal is defined as a fixed number of  literals and the interface is defined as the abstract behavior of an object type. A structured literal can be used as a user defined literal. The interface is independent of the directed graph and applied to the group node.Multiple interfaces are possible for a grouped node in which case all the operations definitions are defined in the corresponding class.
In the example we took earlier with users and hosts, the application logic has to start from the user and hence the pivot entity is chosen. the node register and host are grouped.  The generated classes are user oriented. It's also possible to use host as pivot entity, in which case the sub-classes of the user are not required.
By using different ObjectView pivot entity, we can form the attributes from the grouped node. A practical generation of source code and their structure would involve code generation that corresponds to active records that has attribute values, setters/getters methods for data classes, and persistent classes for the wrappers of the data wrapper classes. Together with the active record and the logic classes, data persistence can proceed with the application codes defined by the developer and the call persistence methods on the session class that translate to SQL DDL. Developers of .Net framework can quickly associate these pieces of generated code to the templates defined from say the EDM.

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.

Today we will continue our discussion on DBPowder. We will look into the conceptual model introduced by this framework. This paper proposes the following data models:
1) Object Model : This object is based on the subset of ODMG 3.0 standard, with some Java-based extensions. An object is called persistent  if all property values are saved into the storage in order they may be retrieved later. Let us take an example with a class User that has an attribute user_name and has a relationship register to another class Register. The Register class also has a relationship user to the class User. Therefore the two classes have a bidirectional relationship. The cardinality is 1:n  A class AdmUser is a sub class of the class User and the class User has a superclass of AdmUser and a class GuestUser
2) RelationalModel: The relational model has a table user and an attribute user_name and primary key user_id. A table register has a foreign key user_id to the table user.
3) EER model in DBPowder : The EER model describes the primitives such as attributes, entity, relationship, connectivity etc. The notations used are : e defines a fact,  e has one or more attributes A1, A2 .. An. Entity E comprises of  a set of facts | the entire attributes. Relationships are expressed as connectivity which represents cardinality.The relationship among three or more entities is described by another entity E' and connecting E' to each of the entities E1, E2, E3.
In the example taken earlier an entity user p has an attribute user_name q and a relationship r to an entity register. r has a connectivity 1:n. For entity user, the occurrence of entity register  is mandatory , a constraint represented by s. The entities of user, adm_user and guest_user form a hierarchy with user as the base. Thus the EER can be used to generate both the relational tables as well as the simple correspondences. 

Today we continue reading the paper on DBPowder. We brought up the mention that Hibernate allows multiple complex correspondence with HBM files. Using Hibernate Annotations which is a supplemental tool, the developer can describe classes with annotations but they too don't improve the Hibernate.
ADO.Net entity model is another popular method which has a conceptual schema description language, a store schema description language and a mapping specification language - all represented in xml. As part of MSL, Melnik proposed a method with bidirectional views which describe a set of constraints between a group of tables and persistent classes. The compiler compiles the constraints to generate the query views and update views for complex correspondences.
Msquare-ORMsquare is another method bur it requires a relational schema and persistent classes in advancey
A relational view extends the original table but views and persistent classes  still need to be described to utilize ORM moreover when data manipulations are performed on the views, they may not be properly reflected on the original table. Also views have to be unfolded to original tables with complex queries causing poorer performance. For object oriented software design, uml is popular.
In this paper, while the authors adopted an EER model to clarify the issues, a design in the EER model can be easily converted into that by the UML Class diagram. This enables simple to complex correspondence comparison because simple uses EER and complex uses ObjectView, in addition to EER.
#codingexercise


GetOddNumberRangePowerTenthRootPowerTwenty(Double [] A)


{


if (A == null) return 0;


Return A.OddNumberPowerTenthRootPowerTwenty();


}