7.1.1 Initial Data Import
As mentioned in section 5.3.3.3 on page 66, the Joomla! generator model pro-vides a way to import the initial data of the modeled application; the Initial Data property of the Joomla! generator model. This is specied in section 5.3.3.4 on page 72. In the following, we discuss the design of the approach used to import the data.
The initial data of the application must be provided in a specic way in order to be interpreted and imported properly by the code generator. Although, the initial data must be provided during customization of the Joomla! generator model and before the code generation, we recommend to run the code generator before dening the initial data. This issue is discussed in more details in the user guide (see section A.7.1 on page 164). Here, we discuss the rationale behind the design of this feature.
From the discussion with Peytz & Co, a common method and format for im-porting the initial data of the application could not be nd. According to Peytz
& Co, the data provided from clients comes in various forms and formats which must be manipulated in one way or another before it can be used in development.
The approach we have chosen is a simple approach (with regards to implemen-tation) but nevertheless very strict. Due to time-limitation of this thesis, we have implemented this approach. The ideal solution, however, will be a sort of graphical user interface that provides means for importing data in dierent formats, e.g. SQL, CSV, EXCEL, etc. and facilitates features for mapping the data to classes in the data model.
The import of initial data of the application is considered a major feature of Welipse, since the data (real life data) during prototyping is crucial for the development of web application, cf. Peytz & Co. This feature is an obvious future work item.
(a) Objects (b) Tables
Figure 7.3: An example of the foreign key association pattern.
As mentioned by Keller (1997) [Kel97], object-oriented programming and the relational model are two dierent paradigms of programming. In order to store objects in relational databases, concepts of object-oriented programming must be mapped to relational table structures. These concepts are, cf. [Kel97]: aggre-gation, inheritance and polymorphism, associations between classes, and data types.
In the following, we only present the dierent patterns for mapping associations between classes to relational tables. For a more thorough exposition of all the patterns for mapping the dierent concepts of object-oriented programming to relational tables, the read is referred to [Kel97].
7.2.1 Associations of 0 : n Multiplicity
Consider the data model in the running example (see gure 2.6 on page 11). In gure 7.3a an excerpt from this model, namely the Squad and Player classes and the association between these classes, are shown. For the sake of simplicity the attributes of both classes have been omitted.
In order to map the scenario presented in Fig. 7.3a to relational tables, two tables are created, e.g. SquadTable for the Squad class and PlayerTable for the Player class. The association between the two classes are represented by a foreign key in the PlayerTable. To this end, a primary key is added to SquadTable. This mapping is depicted in Fig. 7.3b where the plus (+) symbol represents a primary key and the foreign key is represented by a hash (#) symbol.
Furthermore, this gure represents the relationship between the two tables (or entities) which in this case is a 0 : n relationship between the squad and the
player tables. This, however, should not be added to the table schema, but since we follow the notation in [Kel97], this is added here anyway.
The mapping in Fig. 7.3 on the facing page is an example of a foreign key as-sociation pattern, cf. [Kel97, pp. 21-22]. The general structure of this mapping is depicted in Fig. 7.4. This pattern maps an association of multiplicity 0 :n between two classes to relational tables. Notice that this pattern is also used in the case of 1 : 1or0 : 1multiplicities; these are special cases in the 0 :n mul-tiplicity. Furthermore, the association in Fig. 7.4 also represents a composition (like the one in Fig. 7.3a on the facing page).
Figure 7.4: The general structure of the foreign key association pattern.
7.2.2 Associations of m : n Multiplicity
In Fig. 7.5a on the next page an excerpt of the data model in the running example is shown. In this gure, the Squad and Role classes and the bidirectional association between them are presented. Like previous section, we will map this scenario to relational tables. In this case, similar to the case with foreign key association pattern, a table for each of the classes is created, e.g. SquadTable for the Squad class and RoleTable for the Role class. The association, in this scenario, is represented by a new table having two foreign keys. To this end, a primary key is added to the SquadTable and RoleTable. This mapping is depicted in Fig. 7.5b on the following page.
The mapping in gure 7.5 on the next page is an example of a association table pattern, cf. [Kel97, pp. 23-24]. The general structure of this mapping is depicted in Fig. 7.6 on the following page. This pattern maps am:nassociation between two classes to relational tables.
(a) Objects
(b) Tables
Figure 7.5: An example of the association table pattern.
Figure 7.6: The general structure of the association table pattern.
7.2.2.1 Mapping Other Concepts
As mentioned above, the concepts of object-oriented paradigm that must be mapped to relational tables are aggregation, inheritance and polymorphism, as-sociations between classes, and data types. Above, we presented two patterns for mapping associations to relational tables. Mapping of the remaining con-cepts, e.g. inheritance which is more interesting, is not covered here, since these concepts are not supported in the data model, e.g. inheritance. However, in the case of data types, as also mentioned in section 5.3.3.3 on page 66, they are simply mapped based on the type of the class attribute, e.g. the data type int (or more precisely EInt) is mapped to integer (or more precisely the INT data type in MySQL).
Extending Welipse with more patterns that address mapping of concepts men-tioned above is yet another future work item.