scholarly journals The Development and Usage of a Relational Database Design Tool for Educational Purposes

10.28945/3199 ◽  
2008 ◽  
Author(s):  
Milos Bogdanovic ◽  
Aleksandar Stanimirovic ◽  
Nikola Davidovic ◽  
Leonid Stoimenov

Most universities where students study informational technologies and computer science have an introductory course dealing with the development and design of databases. These courses often include usage of database design tools. In this paper, the #EER tool is presented, the task of which is to make the process of relational databases design easier for the students and partially automatize it. The tool evolved due to the experience in using similar tools for educational purposes. It enables fast and efficient development of the relational database conceptual model and its automatized compilation into a relational model and further to data definition language (DDL) commands. #EER tool is based on the extended entity-relationship (EER) model for conceptual modeling of relational databases. Modular architecture of the tool, the development of which is based on the usage of the design patterns, along with the benefits that its usage brings, is also presented.

Author(s):  
Morad Hajji ◽  
Mohammed Qbadou ◽  
Khalifa Mansouri

Ontologies are spreading more and more in the field of information technologies as a privileged solution allowing the formalization of knowledge. The theoretical model of ontologies is most promising. They are increasingly ubiquitous given the benefits they present. Despite the proliferation of research proposing approaches dedicated to the design of a database from an ontology, the tools to design a database from an ontology are rare or inaccessible. Thus, in this contribution, we present our approach for the development of an Eclipse Plug-in, in order to automatically generate a conceptual model of a relational database from an ontology. To evaluate the usefulness of our approach, we used our resulting Eclipse Plug-in to automatically generate a conceptual model of a relational database from an ontology, customize it, and automatically generate the corresponding SQL script for Data Definition. The results of this experiment showed that our Plug-in constitutes a concretization of our approach and a means of automatic translation from the ontological model to the relational model.


Author(s):  
Jean-Marc Petit ◽  
Mohand-Saïd Hacid

This chapter revisits conceptual database design and focuses on the so-called “logical database tuning”. We first recall fundamental differences between constructor-oriented models (like extended Entity-Relationship models) and attribute-oriented models (like the relational model). Then, we introduce an integrated algorithm for translating ER-like conceptual database schemas to relational database schemas. To consider the tuning of such logical databases, we highlight two extreme cases: null-free databases and efficient — though non redundant — databases. Finally, we point out how SQL workloads could be used a posteriori as a help for the designers and/or the database administrators to reach a compromise between these extreme cases. While a lot of papers and books have been devoted for many years to database design, we hope that this chapter will clarify the understanding of database designers when implementing their databases and database administrators when maintaining their databases.


Author(s):  
Jaroslav Zendulka

Modeling techniques play an important role in the development of database applications. Well-known entity-relationship modeling and its extensions have become a widely-accepted approach for relational database conceptual design. An object-oriented approach has brought a new view of conceptual modeling. A class as a fundamental concept of the object-oriented approach encapsulates both data and behavior, whereas traditional relational databases are able to store only data. In the early 1990s, the difference between the relational and object-oriented (OO) technologies, which were, and are still used together to build complex software systems, was labeled the object-relational impedance mismatch (Ambler, 2003). The object-oriented approach and the need of new application areas to store complex data have greatly influenced database technology since that time. Besides appearance of object-oriented database systems, which fully implement objectoriented paradigm in a database environment (Catell et al., 2003), traditional relational database management systems become object-relational (Stonebraker & Brown, 1999). The most recent versions of the SQL standard, SQL: 1999 (Melton & Simon (2001) and SQL: 2003 (Eisenberg et al., 2004), introduced object-relational features to the standard and leading database producers have already released packages which incorporate them.


Author(s):  
Peretz Shoval

The objects model (or object oriented [OO] model) is a conceptual-application model that is used to define a database schema representing a certain reality. The model views the world as consisting of objects belonging to classes. The objects of these classes have attributes, behavior (i.e., functions), and various relationships with other objects. The objects model can be presented as a class diagram (also termed OO diagram or objects diagram). Like an entity relationship diagram (ERD), the class diagram has two main goals: 1. To serve as a communication medium between the developers (analysts/ designers) and the users or their representatives. The diagram is created as a result of the interactions between the two parties, during which they discover and define the users’ information needs; the diagram serves like a contract between these two sides which summarizes the users’ needs. 2. To be the basis for further development of the information system (IS). Based on the diagram, it should be possible to design the database schema of the application, and (partially) the functions that it will have to perform. For that, it is necessary to transform the class diagram into an equivalent verbal description—an objects schema. This is done using an object definition language (ODL), similar to data definition language (DDL) in the relational model. In principle, all components of the class diagram are mapped to the objects schema. However, the objects schema includes more details which are not included in the diagram. For example, in the diagram each attribute has a name, and some attributes may have specific constraint definitions (e.g., key, unique); in the objects schema there are more detailed definitions, including the attributes’ domains or data types (e.g., numeric, char., real, etc.) and lengths. Another example, in the class diagram, we only write the names of the classes’ functions, while in the objects schema we specify the parameters of the functions. As aforementioned, there is a great deal of similarity between the OO and ER models and diagrams, since the ER model is one of the sources from which the objects model originated. But there are differences between the two models, which we will review later on. One of these differences is that the ER model is “static,” that is, it only deals with the data structure, while the objects model also includes “behavior,” that is, the functions that operate on the data. The rest of this chapter is dedicated to describing the components of the objects model and the class diagram. The description is organized in four main categories: objects and classes, attributes, relationships, and functions.


Author(s):  
Andreea Sabau

In order to represent spatio-temporal data, many conceptual models have been designed and a part of them have been implemented. This chapter describes an approach of the conceptual modeling of spatio-temporal data, called 3SST. Also, the spatio-temporal conceptual and relational data models obtained by following the proposed phases are presented. The 3SST data model is obtained by following three steps: the construction of an entity-relationship spatio-temporal model, the specification of the domain model and the design of a class diagram which includes the objects characteristic to a spatiotemporal application and other needed elements. The relational model of the 3SST conceptual model is the implementation of the conceptual 3SST data model on a relational database platform. Both models are characterized by generality in representing spatial, temporal and spatio-temporal data. The spatial objects can be represented as points or objects with shape and the evolution of the spatio-temporal objects can be implemented as discrete or continuous in time, on time instants or time intervals. More than that, different types of spatial, temporal, spatio-temporal and event-based queries can be performed on represented data. Therefore, the proposed 3SST relational model can be considered the core of a spatio-temporal data model.


2009 ◽  
pp. 2360-2383
Author(s):  
Guntis Barzdins ◽  
Janis Barzdins ◽  
Karlis Cerans

This chapter introduces the UML profile for OWL as an essential instrument for bridging the gap between the legacy relational databases and OWL ontologies. We address one of the long-standing relational database design problems where initial conceptual model (a semantically clear domain conceptualization ontology) gets “lost” during conversion into the normalized database schema. The problem is that such “loss” makes database inaccessible for direct query by domain experts familiar with the conceptual model only. This problem can be avoided by exporting the database into RDF according to the original conceptual model (OWL ontology) and formulating semantically clear queries in SPARQL over the RDF database. Through a detailed example we show how UML/OWL profile is facilitating this new and promising approach.


Author(s):  
Sriram Mohan ◽  
Arijit Sengupta

The process of conceptual design is independent of the final platform and the medium of implementation, and is usually in a form that is understandable and usable by managers and other personnel who may not be familiar with the low-level implementation details, but have a major influence in the development process. Although a strong design phase is involved in most current application development processes (e.g., Entity Relationship design for relational databases), conceptual design for XML has not been explored significantly in literature or in practice. Most XML design processes start by directly marking up data in XML, and the metadata is typically designed at the time of encoding the documents. In this chapter, the reader is introduced to existing methodologies for modeling XML. A discussion is then presented comparing and contrasting their capabilities and deficiencies, and delineating the future trend in conceptual design for XML applications.


2009 ◽  
pp. 527-549
Author(s):  
Sriram Mohan ◽  
Arijit Sengupta

The process of conceptual design is independent of the final platform and the medium of implementation, and is usually in a form that is understandable and usable by managers and other personnel who may not be familiar with the low-level implementation details, but have a major influence in the development process. Although a strong design phase is involved in most current application development processes (e.g., Entity Relationship design for relational databases), conceptual design for XML has not been explored significantly in literature or in practice. Most XML design processes start by directly marking up data in XML, and the metadata is typically designed at the time of encoding the documents. In this chapter, the reader is introduced to existing methodologies for modeling XML. A discussion is then presented comparing and contrasting their capabilities and deficiencies, and delineating the future trend in conceptual design for XML applications.


Author(s):  
Maria Salete Marcon Gomes Vaz ◽  
Lucélia de Souza

The modeling of database applications involves deciding on how to represent the project in real-world objects. The data modeling process corresponds to a set of conceptual tools to describe data, its relationships, its semantics, and constraints of consistency. This process involves the steps related to the identification of requisites, conceptual modeling of data, conventional modeling, and non-conventional modeling of objects, and its relationships. In the conceptual modeling, where there is no need to specify the methods and data flow, objects and their relationships are defined. In conventional modeling, in the mapping of the conceptual model (Entity/Relationship) to the logical model (Relational) conversion rules are applied. However, there are non-conventional resources with the ability to create and use data types based on a grouping of other data types. The user-defined objects can be defined and used like any other data type. This chapter describes the process of mapping the relational model for the object-relational modeling, using a practical application in agricultural context, but it should be noted that the methodology is applicable to any area of knowledge.


2006 ◽  
Vol 2 (4) ◽  
pp. 177-191 ◽  
Author(s):  
Sikha Bagui

In this paper, we provide detailed mapping rules (a methodology) to convert an ER schema into an object relationship (OR) schema. The mapping rules are presented in a manner that will keep as much of the semantics of the database intact, in order to smoothen the important step of data migration from an ER schema to an OR schema. This OR schema should also serve as a conceptual design tool for object-oriented data models, very much like the ER diagrams are a conceptual design tool for relational databases. Since we are mainly discussing the conversion from an ER model to an OR model, we are limiting the discussion in this paper to the structural aspects of the OR model.


Sign in / Sign up

Export Citation Format

Share Document