Conventional and Non-Conventional Data Modeling

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.

2014 ◽  
Vol 16 (4) ◽  
pp. 313-340 ◽  
Author(s):  
Nikitas N. Karanikolas ◽  
Michael Vassilakopoulos

Purpose – The purpose of this paper is to compare the use of two Object-Relational models against the use of a post-Relational model for a realistic application. Although real-world applications, in most cases, can be adequately modeled by the Entity-Relationship (ER) model, the transformation to the popular Relational model alters the representation of structures common in reality, like multi-valued and composite fields. Alternative database models have been developed to overcome these shortcomings. Design/methodology/approach – Based on the ER model of a medical application, this paper compares the information representation, manipulation and enforcement of integrity constraints through PostgreSQL and Oracle, against the use of a post-Relational model composed of the Conceptual Universal Database Language (CUDL) and the Conceptual Universal Database Language Abstraction Level (CAL). Findings – The CAL/CUDL pair, although more periphrastic for data definition, is simpler for data insertions, does not require the use of procedural code for data updates, produces clearer output for retrieval of attributes, can accomplish retrieval of rows based on conditions that address composite data with declarative statements and supports data validation for relationships between composite data without the need for procedural code. Research limitations/implications – To verify, in practice, the conclusions of the paper, complete implementation of a CAL/CUDL system is needed. Practical implications – The use of the CAL/CUDL pair would advance the productivity of database application development. Originality/value – This paper highlights the properties of realistic database-applications modelling and management that are desirable by developers and shows that these properties are better satisfied by the CAL/CUDL pair.


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.


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.


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.


2016 ◽  
Vol 14 (1) ◽  
pp. 314-320
Author(s):  
Grace O’Farrell ◽  
Chunhui Liu

This paper describes the relational, entity-relationship (ER), and object-based approaches to modeling financial statements; and discusses the strengths, weaknesses, and user adaptability of these models. We believe that the relational, ER, and object-oriented models may not be individually adequate to model the accounting processes in an integrative accounting information system. The increasing amount of disclosures in the footnotes to the financial statements and the complex compliance requirements of the Sarbanes-Oxley Act suggest that the object-relational model may be appropriate to model both the quantitative and qualitative items in the accounting processes. The object-relational model builds on the strengths of the relational, ER, and object-oriented models and mitigates the weaknesses of these models. We develop a set of propositions based on our review of the current literature on the conceptual models.


2011 ◽  
pp. 49-80
Author(s):  
Hans-Peter Kriegel ◽  
Martin Pfeifle ◽  
Marco Potke ◽  
Thomas Seidl ◽  
Jost Enderle

In order to generate efficient execution plans for queries comprising spatial data types and predicates, the database system has to be equipped with appropriate index structures, query processing methods and optimization rules. Although available extensible indexing frameworks provide a gateway for seamless integration of spatial access methods into the standard process of query optimization and execution, they do not facilitate the actual implementation of the spatial access method. An internal enhancement of the database kernel is usually not an option for database developers. The embedding of a custom, block-oriented index structure into concurrency control, recovery services and buffer management would cause extensive implementation efforts and maintenance cost, at the risk of weakening the reliability of the entire system. The server stability can be preserved by delegating index operations to an external process, but this approach induces severe performance bottlenecks due to context switches and inter-process communication. Therefore, we present the paradigm of object-relational spatial access methods that perfectly fits to the common relational data model, and is highly compatible with the extensible indexing frameworks of existing object-relational database systems, allowing the user to define application-specific access methods.


Sign in / Sign up

Export Citation Format

Share Document