Rivero L.Encyclopedia of database technologies and applications.2006

In particular, given two elements x and y belonging to

a given data type X, we consider distance functions of type d: D2 → [0,1], such that for each vx, vy D d(vx, vy) returns

the distance of x from y with respect to the feature space D. In what follows we indicate such distance with d(x, y) for any two elements x, y: X. Moreover, given a data type X, we denote with D(X) the set of distance functions defined on X, and with Xd the feature space on which the distance function d is defined.

To evaluate the similarity between the multimedia objects of two different tuples, we introduce a tuple distance function, which summarizes the results produced by the different distance functions applied to the elements of the tuples. In particular, given a relation R(z1:Z1,…,zn:Zn), if x = (x1,…,xn) and y = (y1,…, yn) are two tuples of R, then ϖ(x,

y) = g(d1(x1, y1),…, dn(xn, yn)) measures the distance between x and y, where diD(Zi) and g:[0,1]n→[0,1] is a

suitable monotonically nondecreasing function of its arguments. Notice that if n = 1, then ϖ(x,y) = d1(x, y). Given a set of data types X, we denote with TD(X) the set of tuple distance functions defined on X.

•Definition 1: Let R(z1:Z1,…,zn:Zn), ϖ be a tuple distance function on R, t be a maximum distance thresh-

old, x = (x1,…,xn) and y = (y1,…,yn) be two tuples in R, we say that x is similar within t to y with respect to ϖ, denoted with x w(t) y, if ϖ(x, y) ≤ t.

Now we are ready to introduce the notion of functional dependency for multimedia databases, named type-M functional dependency.

•Definition 2: Let R be a relation with attribute set U, and X, Y U. Xg1(t’) → Yg2(t’’) is a type-M functional dependency (MFD) relation if and only

if for any two tuples t1 and t2 in R that have t1[X] g1(t’) t2[X], then t1[Y] g2(t’’) t2[Y], where g1TD(X) and g2TD(Y), whereas t’ and t’’ Î [0,1] are thresholds.

This means that the features used by g2 on Y depend on the features used by g1 on X; or, alternatively, the values of the features used by g1 on X component imply the range of values for the features used by g2 on Y component.

As an example, if we define a functional dependency between attributes FINGERPRINT and PHOTO of a police database, and use the fingerprint matching function FINGERCODE for comparing digital fingerprints (Maltoni, Maio, Jain, & Prabhakar, 2003), and the similarity technique used by QBIC for comparing photo images, we would write as follows

FINGERPRINTFINGERCODE(t’) → PHOTOQBIC(t’’)

Normalizing Multimedia Databases

This constraint says that for any two tuples t1 and t2 such that t1[FINGERPRINT] is considered similar within the threshold t’ to t2[FINGERPRINT] by the FINGERCODE, then t1[PHOTO] is considered similar within the threshold t’’ to t2[PHOTO] by the QBIC. Given the semantics of the FINGERPRINT attribute, it is expected that the designer fix the value of t’ to zero.

In traditional alphanumeric databases, normal forms are used to derive database schemes that prevent manipulation anomalies (Elmasri & Navathe, 2003). Similar anomalies can arise in a multimedia database. Thus, a multimedia database designer should take all the precautions at database design time to avoid such anomalies. As an example, let us consider the following relation of an art exhibition multimedia database schema, with some associated MFDs on its attributes:

Artist Exhibition #Room Artist Photo Poster Video

mfd1

mfd2 mfd3

It is easy to imagine how the schema of such a relation will yield manipulation anomalies, because it mixes together too many types of information. In fact, if we delete an exhibition from the database, we might lose an artist’s data, such as his or her photo. Moreover, to perform such an operation we need to perform deletion across all the tuples referring to that exhibition, because the relation schema yields duplication of information regarding an exhibition. If we are willing to insert an artist’s picture, without knowing the data of an exhibition, we have to leave some blank attributes, one of which belongs to the primary key. To avoid such anomalies, we should have stored information about exhibitions separately from those of artists.

Other types of anomalies arise from grouping to many multimedia data in the same multimedia attribute. For instance, the soundtrack of a video might be useful for different queries and multimedia presentations; hence, we need to store the video and its soundtrack as two separated multimedia attributes, together with synchronization information to coordinate their combination. Thus, we need to segment the vicon associated to the video. Synchronization information can be stored as metadata or as special relations, depending on the specific MMDBMS technology used.

In this section we present three normal forms for multimedia databases. They are based on the type-M dependencies defined above. Therefore, their results depend on the distance functions used to derive dependencies and can be used to derive multimedia database schemes without potential manipulation anomalies. More-

Normalizing Multimedia Databases

over, the application of a normal form itself might need a specific manipulation function, such as a segmentation function, to handle a specific media type.

Our first normal form for multimedia attributes (1MNF) regards the granularity of multimedia attributes. We say that a multimedia database schema is in first multimedia normal form (1MNF) if each attribute A has the type of number, string or elementary generalized icon. For instance, image attributes can be decomposed in a certain number of k image components, which will be stored as separated attributes. In this case, the application of the normalization process is based on a specific segmentation function. This normalization process can also be applied to composite multimedia objects to decompose them into elementary generalized icons, which will be stored in separate attributes. For instance, we might have a vicon attribute and want to separate sounds from images. Again, the application of these normal forms requires the availability of specific segmentation function. Moreover, the decomposition of a composite multimedia attribute may require the storing of additional data structures to enable the reconstruction of the original attribute format. In particular, such data structure should store the relations between the different attribute components. As an example, if we store the different components of a segmented image separately then we need to store a data structure containing information such as the relative position of each image segment and possibly some spatial relation with respect to other segments. Such metadata is associated to the multimedia attribute, and the way it is stored depends on the specific type of DMBS used.

We say that a multimedia database schema is in second multimedia normal form (2MNF) if it is in 1MNF and each nonprime attribute A is fully dependent on the primary key. In case there is a partial dependency of A from a subset {ki,…, kj} of key attributes, then the designer can decide to normalize the schema by splitting the

original schema R into two subschemes R1 = R - T and R2 = {ki,…, kj} T, where T = {A} {Bi | Bi R, {ki…kj}s1 → {Bi}s2}. For brevity, in the following we omit the threshold

from the similarity expressions.

As an example, let us analyse the MFDs and the normal forms of the relation schema from the art exhibition multimedia database seen previously. {Artist, Exhibition}→ #Room is a full dependency, but {Artist, Exhibition} → ArtistPhotod1 and {Artist, Exhibition} → {Poster, Video}d2 are partial dependencies because of mfd2 and mfd3, respectively. These MFDs lead to the decomposition of the relation into the following three relations, each of which is in 2MNF.

We say that a multimedia database schema is in third multimedia normal form (3MNF) if it is in 2MNF and N the nonprime attributes are not mutually dependent. Equivalently, we can say that whenever a MFD Xs1 → As2

holds in R, either

a.X is a superkey of R, or

b.A is a prime attribute of R.

As an example, let us consider the following simple multimedia relation:

Opera #Room Num_of_religuaries Map

mfd1 mfd2

The dependency mfd2 violates 3MNF because #Room is not a super key of the relation, and Num_of_Religuaries and Map are not prime attributes. We can normalize the relation schema by decomposing it into the following two 3MNF relation schemas. We construct the first relation by removing the attributes violating 3MNF, namely Num_of_Religuaries and Map, from the original relation, and placing them with #Room into the second relation.

FUTURE TRENDS

Because the multimedia dependencies and multimedia normal forms depend on the tuple distance functions, by imposing additional constraints on tuple distance functions we can introduce more restricted multimedia dependencies and multimedia normal forms. This makes the proposed framework very flexible to accommodate the requirements of different applications. Furthermore, other normal forms can be introduced if we explore more deeply certain application domains, such as e-learning.

In the future, we aim to further explore the theoretical framework and, according to feedback resulting from its application, to more application fields.

CONCLUSION

In this paper we have proposed a framework for the normalization for multimedia databases. Our goal here it has been to derive proper design guidelines to be adopted within multimedia software engineering methodologies. The framework is parametric with respect to the distance

functions used for the different media domains, and allows many degrees of normalization, depending on the distance function and the segmentation techniques used to decompose complex multimedia attributes.

REFERENCES

Arndt, T., Cafiero, A., & Guercio, A. (1997). Multimedia languages for teleaction objects. Proceedings of the IEEE Symposium on Visual Languages, VL97, Capri Island, Italy.

Chang, S. K. (1996). Extending visual languages for multimedia. IEEE Multimedia Magazine, 3(3), 18-26.

Chang, S. K., Polese, G., Orefice, S., & Tucci, M. (1994). A methodology and interactive environment for iconic language design. International Journal of Human Computer Studies, 41, 683-716.

Elmasri, R., & Navathe, S. B. (2003). Fundamentals of database systems (4th Ed.). Reading, MA: Addison Wesley.

Flickner, M., Sawhney, H., Niblack, W., Ashley, J., Huang, Q., Dom, B., et al. (1995). Query by image and video content: The QBIC system. IEEE Computer, 28(9), 2332.

Löhr, M., & Rakow, T. C. (1995). Audio support for an object-oriented database-management system. Multimedia Systems, 3(6), 286-297.

Maltoni, D., Maio, D., Jain, A. K., & Prabhakar, S. (2003).

Handbook of fingerprint recognition. New York: Springer Verlag

Narasimhalu, A. D. (1996). Multimedia databases. Multimedia Systems, 4(5), 226-249.

Oomoto, E., & Tanaka, K. (1993). OVID: Design and implementation of a video-object database system. IEEE Transactions on Knowledge and Data Engineering, 5(4), 629-643.

Sacks-Davis, R., Kent, A., Ramamohanarao, K., Thom, J., & Zobel, J. (1995). Atlas: A nested relational database system for text applications. IEEE Transactions on Knowledge and Data Engineering, 7(3), 454-470.

Santini, S., & Gupta, A. (2002). Principles of schema design for multimedia databases. IEEE Transactions on Multimedia, 4(2), 248-259.

Normalizing Multimedia Databases

Santini, S., & Jain, R. (1999). Similarity measures. IEEE Transactions on Pattern Analysis and Machine Intelligence, 21(9), 871-883.

Schaubl, P. (1997). Multimedia Information retrieval: Content-based information retrieval from large text and audio databases. Boston: Kluwer.

Wu, J. K., Narasimhalu, A. D., Mehtre, B. M., Lam, C. P. & Gao, Y. J. (1995). CORE: A content-based retrieval engine for multimedia information system. Multimedia Systems, 3(1), 25-41.

KEY TERMS

Distance Function: A function used to compute the similarity between two multimedia elements. In particular, it returns a number in the range [0, 1], with values close to 0 for similar elements.

Extensible RDBMS: Relational DBMS implementing the concept of universal server. It allows the extension of the DBMS type system by enabling the definition of user defined data types (UDT), and the associated user defined manipulation functions (UDF).

Generalized Icons: Generalized icons are used to describe multimedia objects such as images, sounds, texts, motions, and videos. They are dual objects with a logical part and a physical part.

MMDBMS: DBMSs with enhanced functionalities to efficiently organize, store, and retrieve multimedia objects.

Multimedia Normal Forms: Rules for testing multimedia database schemes in order to prevent possible manipulation anomalies.

Tuple Distance Function: A function used to compute the similarity between two tuples of a relational multimedia database. Similarly to the distance function, this function also returns a number in the range [0, 1], computed by synthesizing the values that the distance function returns when applied on the attributes of the compared tuples.

Type-M Functional Dependency: Let R be a relation with attribute set U, and X, Y U. Xg1(t’) → Yg2(t’’) is a type-M functional dependency (MFD) relation if and only if for any two tuples t1 and t2 in R that have t1[X] g1(t’) t2[X], then t1[Y] g2(t’’) t2[Y], where g1 TD(X) and g2 TD(Y), whereas t’ and t’’ [0, 1] are thresholds.

GiuseppePolese

Università di Salerno, Italy

VincenzoDeufemia

Università di Salerno, Italy

Gennaro Costagliola

Università di Salerno, Italy

GennyTortora

Università di Salerno, Italy

INTRODUCTION

As the development of industrial software applications become more complex, the benefits of developing a comprehensive “blueprint” enabling developers to visualize the scope of a project increase substantially.

One of the key points in the development of most industrial applications is the design of the database. The object-oriented design paradigm enhances database modeling because the object model is expressive, concise, and relatively easy to use. On the other hand, the relational data model offers the advantages of a standard model, having a rigorous theoretical foundation, a mature technology, and the possibility to easily work with declarative languages. The complementary strengths of object and relational models makes it desirable to have them coexist in some form, achieving the best from both their paradigms (Li & Zhao, 2003; Musto et al., 2000 ).

The Object Modeling of Relational Applications (OMAR) methodology uses object-oriented front end modeling and supports the generation of relational database schemes for the designed applications (Musto et al., 2000). It uses inference mechanisms exploiting the data structuring information and the dynamic models produced during the object-oriented modeling phases to infer an appropriate relational data schema and the associated manipulation mechanisms. Thus, a designer still benefits from the advantages offered by the object-ori- ented modeling paradigm, without loosing the above mentioned advantages offered by the relational data model.

In this article, we show how we have used visual language technology to develop OMAR front-end CASE tools. A visual compiler generator, VLCC, has been used to model the syntax of UML diagrams and to generate a syntax driver editor and a compiler for them. Moreover, the inference mechanisms of OMAR have been embedded

within VLCC by means of semantic routines. These are invoked upon the successful parsing of UML diagrams and produce an object/relational source code version of the application under development. We describe such a version of the code by using the PC++ language (Musto et al., 2000), a high level C++ providing abstract mechanisms to manage the communication with RDBMSs.

BACKGROUND

Applications that combine an object-oriented development method with RDBMS-based implementation can benefit from the use of a powerful, flexible, and expressive design paradigm and a standard implementation platform. In this way, application experts can focus on design instead of low-level tasks like tuning a database, just as high-level languages free programmers from repetitive tasks like assigning variables to registers. Any architecture that preserves this separation of concerns must have the ability to hide low-level details from the application expert. One way to do this is to automate mapping rules through an object-model compiler, having an RDBMS as its target architecture. Experts can then focus on the nuances of the application and avoid rediscovering database design principles for each new project. Moreover, the accuracy of the tables no longer depends on the person doing the conversion. One of the most important approaches for mapping object schemes onto RDBMS schemes is presented in Blaha, Premerlani, and Shen (1991). This approach combines the Object Modeling Tool (OMT) with Schemer, a compiler developed at GE Corporate R&D. In particular, Schemer converts the object schemes into SQL code, which can then be used to generate relational tables.

THE DEVELOPMENT PROCESS WITH OMAR

Nowadays, there is still high demand of compatibility between object-oriented development methodologies and traditional DBMS platforms. In fact, in spite of reduced modeling capabilities, traditional RDBMSs offer the advantages of a widely used technology that also allows to easily recruit or train experienced professionals in the field. On the other hand, the object-oriented paradigm has the potential to improve many aspects of the software development process, including a more effective maintenance and reuse of existing applications.

The OMAR methodology supports the development of RDBMS-based applications starting from object-ori- ented specifications or programs. It allows a designer to build large systems by using object-oriented design methodologies and to generate a prototype of the whole relational application with the support of automated tools. The OMAR development life cycle is depicted in Figure 1.

The PC++ programming environment relies upon the PC++ compiler, which extends the C++ language with abstract mechanisms to cope with persistent classes and objects to be stored and manipulated through relational DBMSs. The programmer uses high-level constructs to declare persistent classes and the object-oriented paradigm to interact with the stored data. It will be the compiler responsibility to generate the appropriate C++/SQL code using ODBC calls (Gryphon et al., 2000). The PC++ programming environment can be used as an entry point of the OMAR methodology for developing small relational applications, or it can be used as a back end for large applications modeled through the object-oriented design paradigm of OMAR. The object-oriented design schemes can be translated either in C++/SQL or PC++ code. The

Figure 1. The OMAR development life cycle

OO Analysis

& Design

PC++ code

OO schemes

C++/SQL code

PC++ Programming

Static OO Architecture

&

Design Schema

PC++ constructs

C++/SQL code

Object Modeling of RDBMS Based Applications

latter can in turn be translated in C++/SQL using the PC++ compiler.

MAPPING CLASS DIAGRAMS ONTO RELATIONAL APPLICATIONS

In the following, we provide algorithms to capture and process the information contained within class diagrams, state diagrams, and other behavior diagrams of an object design schema to derive an appropriate structuring of a relational data schema for the application under development and the associated manipulation code. In particular, the class diagram provides the necessary information to derive the tables to be generated. The remaining diagrams can be exploited to analyze the dynamic behavior of the system, which provides heuristics on how to refine the relational data schema to accommodate the data navigation requirements of transactions, and it is used to derive the manipulation code.

Extracting a Relational Data Schema from the Class Diagram

The rules for extracting a relational data schema from the class diagram of an application are an extension of the rules for mapping Extended Entity Relationship diagrams onto relational data schemes (Elmasri & Navathe, 2003). A sample of these rules is the mapping of Generalization/ Specialization hierarchies.

A generalization/specialization hierarchy can be of different types depending upon two properties: disjunction/overlapping and partial/total (Elmasri & Navathe, 2003). Their combination yields the following four types of hierarchies: (1) disjoint/total, (2) disjoint/partial, (3) overlapping/total, and (4) overlapping/partial. If a generalization/specialization hierarchy of type 2, 3, or 4 has superclass C with attributes {al, a2,..., an} and m subclasses {S1, S2,..., Sm}, then it is mapped by using the following rules:

•Create a table Tc with columns {al,...,an} {OIDc} corresponding to the attributes of class C plus its unique identifier (OID). The latter is used to manage inter-object references and will be a candidate primary key for the table Tc.

•For each subclass Si, 0 < i < m + 1, create a table Ti with columns {attributes of Si} {OIDsi}. Once again, here the OID will be a candidate primary key for the table Ti.

•Create a system table INHERITANCE, if it does not exist. This table will be updated with the insertion of

Object Modeling of RDBMS Based Applications

a new record (superclass-name, subclass-name) for each subclass Si, 0 < i < m + 1 and will be used for reverse engineering purposes.

As for generalization/specialization hierarchies of type 1, these are mapped by generating relational tables only for the subclasses {S1, S2,…, Sm} with columns {attributes of Si} U {OIDsi} U {a1,...,an} corresponding to the attributes of the subclasses, plus their OIDs, plus the attributes of the superclass.

Refining the Application through the Dynamic Constructs of the Object Model

So far we have provided the mapping of static constructs of the object model (constructs of the class diagram) on a relational data schema. The latter needs to be refined in order to satisfy the data navigation requirements of the transactions to be implemented in the application under development. To do this, we use an inference engine that examines the dynamic models developed during the Object Analysis and Design (OOAD) phases of OMAR to infer the characteristics of the transactions. This has the twofold goal to enhance the relational data schema and to generate the structure of the code implementing the transactions. In particular, our engine exploits the functional models and the State Diagrams. The functional models highlight the dependencies between certain data through the functions contained in the Data Flow Diagrams. In fact, we can examine these diagrams to verify whether the functions use intermediate data to relate a pair of data. Thus, we can use Data Flow Diagrams to infer some functional dependencies to be used for normalization purposes. The data flows of a Data Flow Diagram correspond to attribute values of a Class Diagram, whereas the processes correspond to actions or activities of the State Diagram for a class.

The State Diagram for a class shows the dynamic behavior of the class. The examination of the State Diagrams can help detect classes that are not significant enough to have a table associated in the underlying relational database schema. For instance, this happens when a class is associated to a State Diagram with states that do not have a Data Flow representation, meaning that they only perform elementary operations. Thus, if the class had previously been associated to a table, the inference engine tries to eliminate such a table. To do this, it examines the complexity of the class structure in the Class Diagram and verifies whether the name of the class appears as a Data Store item in one of the Data Flow diagrams associated to a related class.

Makepersistent(CLASSNAME)

←

class(CLASSNAME, LIST OF ATTRIBUTES),

DataStore(CLASSNAME).

It makes the class CLASSNAME persistent if it is indicated as transient, but it appears as a data store in a Data Flow Diagram.

SuperPrimaryKey(LIST OF ATTRIBUTES, TABLENAME)

←

ATTRIBUTES,TABLENAMEID), ExistsTable(TABLENAME).

LIST OF ATTRIBUTES is a Primary Key for the table TABLENAME if there exists a function capable of selecting the class instances to be stored in the table TABLENAME by using the attributes in LIST OF ATTRIBUTES.

Mapping the Object Schema of a Bank

ATM Network

The OMAR methodology has been developed and experimented based upon the models used in the OMT methodology (Blaha et al., 1991) and later extended to the UML languages. We describe the application of the OMAR methodology for the example given in Blaha et al. (1991). It regards the development of a software system to support a computerized banking network including both human cashiers and automatic teller machines (ATMs) to be shared by a consortium of banks. The class diagram developed during the object-oriented analysis of this problem is given in Figure 2.

In this example, the classes that are indicated as persistent are: Card-Authorization, Cash-Card, Customer, Account, and Bank. Parts of the State Diagrams for the classes ATM, Consortium, and Bank are shown in Figures 3(a), 3(b), and 4(a). A Sequence Diagram for the Bank ATM networks is shown in Figure 4(b). A portion of the relational data schema produced by the application of the mapping rules on the ATM class diagram is shown in Figure 5.

At this point, the inference engine uses the dynamic models to refine the schema. For instance, from the State Diagrams of the classes ATM, Consortium, and Bank, given in Figures 3(a), 3(b), and 4(a), the engine detects the message exchanges between ATM and Bank going through Consortium. The latter has elementary actions only, that is, actions with no Data Flow Diagram associated. Moreover, from what said above, this class has been translated into a table because it is transient, but it

is related to the persistent class Bank. Thus, the engine tries to eliminate this table, also because the associated class Consortium has a reduced structure. The sequence diagram reveals the functional dependence of all the attributes of the class Cash Card on the combination of attributes bank-code and card-code. Thus, the pair (bankcode, card-code) can be a Primary Key for the table associated to the class Cash Card.

OMAR PROGRAMMING WITH PC++

The transition from modeling to programming in OMAR is seamless. In other words, in both cases, the developer uses the object-oriented paradigm and exploits automated support for the generation of the final relational application.

BANK

Primary key: cashierID

REMOTE-TRANSACTION

Attribute-name Domain

remote-transactionID ID date-time date card-authorizationID ID

Primary key: remote-transactionID

Foreign key: card-authorizationID

EMPLOYS

Primary key: (bankID,employeecode)

Foreign keys: bankID, cashierID, employeecode

PC++ is a C++ with added mechanisms for the management of object persistency onto relational DBMSs. Programming relational applications with PC++ is made simpler because the programmer can model persistent classes directly by using the DBClass declaration provided by PC++. The latter will be responsible for compiling these constructs, generating the equivalent C++ code, including the low level SQL instructions to handle the communication with the RDBMS. In particular, PC++ generates modules for communicating with an ODBC server.

Similar environments are POET (Poet Software, 1993) and Persistence (Persistence Software, 1993). As opposed to PC++, POET is not open to different RDBMS platforms, whereas Persistence realizes open RDBMS connectivity by using different techniques like the manipulation of the class constructors.

Persistency in PC++

PC++ uses the technique of data manipulation language (DML) binding to provide type-orthogonal persistency (Bertino, 1991). The PC++ programmers can choose the classes and the instances that they want to make persistent. They use a new key word, namely, dbclass to declare persistent classes. PC++ accomplishes the translation from the object to the relational model by extending persistent classes with a new data member, OID, and with new methods to handle the communication with the RDBMS through ODBC, for example, a new method Store() to enable the storage of class instances. Every class is extended to provide persistency also for the instances of classes related to a persistent class, for instance, through a part-of or inheritance relation.

Mapping Object Schemes onto PC++ Programs

Some rules for translating the static diagrams of the object schema are given below. Also here, the inference engine refines the products of translation by using the information contained within the dynamic models of the objectoriented schema.

1.For each transient class, generate a PC++ class with same name, attributes, and methods. In this case, the syntax is equivalent to that of a C++ class.

2.For each persistent class, generate a PC++ dbclass with same name, attributes, and methods.

3.For each generalization/specialization relation, insert the name of the superclass in the inheritance chain of the subclass.

4.For each binary bidirectional relation, insert a macro

Association(class-name, multiplicity) within the private methods of the classes involved in the relation. Class-name is the name of the other class involved in the relation, whereas multiplicity is the cardinality of the relation. The PC++ compiler will use the friend mechanism to prevent update anomalies.

5.For each qualified bidirectional association relation, insert a macro Association(class-name, multeplicity, association-name) within the private methods of the classes involved in the relation. In addition to normal relations, here there is the additional argument association-name indicating the name of the relation. Moreover, an additional macro

Make-Class(relation-name, identifier1, identifier2, qualifier) is generated where relation-name is the

name of the qualified relation, identifier1 and identifier2 are the instance identifiers of the two classes involved in the relation, and qualifier is the qualifier attribute. The macro Make-Class causes the PC++ compiler to create the table relation-name with

fields identifier1, identifier2, qualifier, and the pair (identifier1, qualifier) as the primary key. The attribute qualifier is also inserted as a data member of the qualified class.

USING VISUAL LANGUAGE GENERATORS TO CONSTRUCT OMAR FRONT-END CASE TOOLS

VLCC is a grammar-based system that can support the implementation of graphical objects, syntax, and semantics of many types of visual languages (Costagliola et al.,

Object Modeling of RDBMS Based Applications

1997). VLCC uses the extended positional grammar model as its underlying grammar formalism (Costagliola & Polese, 2000). In this section, we show how the VLCC system has been used for generating OMAR front-end CASE tools.

The VLCC system architecture includes two main modules: the Grammar Editor and the Visual Programming Environment Generator. The first is a parametric system that can be configured to create and manipulate graphical components in a given visual language class and provides the language designer with editors to define specific visual grammars. The latter inputs the grammar specifications produced by Grammar Editor and generates an integrated visual programming environment containing a compiler and a visual editor for the defined visual language.

We used VLCC for the automatic generation of the visual programming environment for the UML visual notations. We began constructing a grammar for the Class Specification language (Booch, Jacobson & Rumbaugh, 1999; OMG, 2003). The Class Specification language describes the objects, the classes, the types, and the relationships that are in a class diagram. In this language, conceptual aspects and software interfaces are considered, whereas implementation aspects are considered into another part of the UML language, the Implementation Class Diagram Language. Class Specification is composed of “Class Identification” and “Class Diagram Specification”. Class Identification specifies any system class and any system type. Class Diagram Specification conceptually specifies the existing relationships between classes and the class classifications. Therefore, we have implemented the grammar for Class Specification that includes three grammars, one for Class Identification, one for Class Diagram Specification, and one comprehending the preceding grammars.

The grammar formalism underlying VLCC allows a more flexible utilization of UML, since it gives the possibility to customize the visual notation and the rules for mapping the UML diagrams to lower level models.

The semantic routines to generate PC++ code from UML diagrams are inserted within YACC-like files (Johnson, 1978) generated by VLCC. An example of semantic routines included within the Class Specification language is the following:

classg →…..

→CLA

{ * syntactic attributes valutation * if (flag_list==0){

list=MakeList();

node=MakeNode(““,””); Persistent(node, $1→GetTxtDirect(1));

Mlist=ParseMemberString($1→GetTxtDirect(2), out);

Node=MemberListInsert(node, Mlist); List=TailInsert(list, node);

Object Modeling of RDBMS Based Applications

flag_list=1;

}

else

{node=SearchClass(ClassName($1’!GetTxtDirect(1)), list); if (node==NULL){

node=MakeNode(“”,“”); Persistent(node, $1→GetTxtDirect(1));

Mlist=ParseMemberString($1→GetTxtDirect(2), out);

Node=MemberListInsert(node,Mlist);

List=TailInsert(list,node);

}

}

};

With this semantic routine, the C++ SearchClass (ClassName($1→GetTxtDirect(1))), list) function checks if it already exists a node for class-name class. If it does not exist, then it is created by the C++ MakeNode() function. This list node contains information about class name, the persistency, and class members. This check is necessary to avoid that the same information is stored more times because of the tokens reinstate technique in visual grammars.

If a designer provides quantitative data together with diagrams, the generated CASE tools provide automatic support for workload computation and performance analysis of the modeled database. It is also capable of generating access tables, which it uses to contrast alternative design schemes and to choose the one guaranteeing best performances.

FUTURE TRENDS

Several issues deserve further investigation. The OMAR inference engine is being extended to include fuzzy mapping rules. In particular, we are defining criteria for better refining the relational data scheme.

Moreover, we plan to extend the OMAR methodology to generate extended RDBMS schemes for multimedia applications (Polese, Tortora & Pannella, 2000). In particular, we use to construct customized versions of UML diagrams to model multimedia classes. Successively, these classes can be better described by using specific multimedia models such as Petri Nets.

CONCLUSION

We have presented the methodology OMAR to design applications with the object-oriented paradigm and to implement them on a relational DBMS through the support of automatic tools. We have used visual language technology to develop prototype front-end CASE tools supporting the OMAR modeling paradigm.

The combination of the object and relational para-

digms allows companies to perform an easier migration to O the object-oriented design and programming paradigms

and to make them coexist with the standard reliable relational paradigm.

The visual language technology is used to develop prototype front-end CASE tools supporting the OMAR modeling paradigm. In particular, VLCC is used as a compiler for the graphical notations of the UML language. The inference mechanisms of OMAR are embedded within the generated CASE tools by means of YACC semantic routines.

REFERENCES

Bertino, E. (1991, October-December). Object-oriented database management systems: Concepts and issues.

IEEE Computer, 24(4), 33-47.

Blaha, M., Eddy, F., Lorensen, W., Premerlani, W., & Rumbaugh, J. (1991). Object-oriented modeling and design. Prentice Hall International.

Blaha, M., Premerlani, W., & Shen, H. (1994). Converting OO models into RDBMS schema. IEEE Software, 11(3), (pp. 28-39).

Booch, G., Jacobson, I., & Rumbaugh, J. (1999). The unified modeling language reference manual. AddisonWesley.

Costagliola, G., De Lucia, A., Orefice, S., & Tortora, G. (1997). A parsing methodology for the implementation of visual systems. IEEE Transactions on Software Engineering, 23(12), 777-799.

Costagliola, G., Deufemia, V., & Polese, G. (2004). A framework for modeling and implementing visual notations with applications to software engineering. ACM Transactions on Software Engineering and Methodology, 13(4), 431-487.

Elmasri, R., & Navathe, S.B. (2003). Fundamentals of database systems (4th ed.). Addison-Wesley.

Gryphon, R., Charpentier, L., Oelschlaiger, J., Shoemaker, A., Cross, J., & Lilley, A.W. (2000). Using ODBC: Special edition. Addison-Wesley.

Johnson, S.C. (1978). YACC: Yet another compiler compiler. Murray Hills, NJ: Bell Laboratories.

Li, L., & Zhao, X. (2003). UML specification of relational database. Journal of Object Technology, 2(5), 87-100.