Distributed Model-Based Diagnosis using Object-Relational Constraint Databases

This work presents a proposal to diagnose distributed systems utilizing model-based diagnosis using distributed databases. In order to improve aspects as versatility, persistence, easy composition and efficiency in the diagnosis process we use an Object Relational Constraint Database (ORCDB). Thereby we define a distributed architecture to store the behaviour of components as constraints in a relational database to diagnose a distributed system. This work proposes an algorithm to detect which components fail when their information is distributed in several databases, and all the information is not available in a global way. It is also offered a proposal to define, in execution time, the allocation of the sensors in a distributed system.Ministerio de Ciencia y Tecnología DPI2003-07146-C02-0

Evaluating relationship implementations performance in object-relational databases

In this work an evaluation of an object-relational schema implementation representing different relationships of an UML class diagram against the relational approach was made. To perform this test we have implemented both object-relational and relational schemas from a UML class diagram in a commercial database leader in the market. The main goal has been to prove the competitiveness of the object-relational technology. The methodology used for this work was to present several schema implementations of association, composition, aggregation and inheritance relationships, propose a set of representative queries to evaluate their behavior, compare the results and make an analysis based on response times. Four alternatives implementations of the schema diagram were made for a composition relationship presented in the proposed UML class diagram. The queries have been executed with no flush to the database buffer pool among runnings to simulate a real situation. In some object-relational queries several built-in functions and operations have been used. As a consequence of this work we are proposing some extensions to the relational schema diagram to add the object-relational alternatives (references, arrays, multisets, etc.) proposed by the SQL:2003 standard.Fil: Golobisky, María Fernanda. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Santa Fe. Instituto de Desarrollo y Diseño. Universidad Tecnológica Nacional. Facultad Regional Santa Fe. Instituto de Desarrollo y Diseño; ArgentinaFil: Vecchietti, Aldo. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Santa Fe. Instituto de Desarrollo y Diseño. Universidad Tecnológica Nacional. Facultad Regional Santa Fe. Instituto de Desarrollo y Diseño; Argentin

UML Class Diagram or Entity Relationship Diagram : An Object Relational Impedance Mismatch

It is now nearly 30 years since Peter Chen’s watershed paper “The Entity-Relationship Model –towards a Unified View of Data”. [1] The entity relationship model and variations and extensions to ithave been taught in colleges and universities for many years. In his original paper Peter Chen looked at converting his new ER model to the then existing data structure diagrams for the Network model. In recent years there has been a tendency to use a Unified Modelling Language (UML) class diagram forconceptual modeling for relational databases, and several popular course text books use UMLnotation to some degree [2] [3]. However Object and Relational technology are based on different paradigms. In the paper we argue that the UML class diagram is more of a logical model (implementation specific). ER Diagrams on theother hand, are at a conceptual level of database design dealing with the main items and their relationships and not with implementation specific detail. UML focuses on OOAD (Object Oriented Analysis and Design) and is navigational and program dependent whereas the relational model is set based and exhibits data independence. The ER model provides a well-established set of mapping rules for mapping to a relational model. In this paper we look specifically at the areas which can cause problems for the novice databasedesigner due to this conceptual mismatch of two different paradigms. Firstly, transferring the mapping of a weak entity from an Entity Relationship model to UML and secondly the representation of structural constraints between objects. We look at the mixture of notations which students mistakenly use when modeling. This is often the result of different notations being used on different courses throughout their degree. Several of the popular text books at the moment use either a variation of ER,UML, or both for teaching database modeling. At the moment if a student picks up a text book they could be faced with either; one of the many ER variations, UML, UML and a variation of ER both covered separately, or UML and ER merged together. We regard this problem as a conceptual impedance mismatch. This problem is documented in [21] who have produced a catalogue of impedance mismatch problems between object-relational and relational paradigms. We regard the problems of using UML class diagrams for relational database design as a conceptual impedance mismatch as the Entity Relationship model does not have the structures in the model to deal with Object Oriented concepts Keywords: EERD, UML Class Diagram, Relational Database Design, Structural Constraints, relational and object database impedance mismatch. The ER model was originally put forward by Chen [1] and subsequently extensions have been added to add further semantics to the original model; mainly the concepts of specialisation, generalisation and aggregation. In this paper we refer to an Entity-Relationship model (ER) as the basic model and an extended or enhanced entity-relationship model (EER) as a model which includes the extra concepts. The ER and EER models are also often used to aid communication between the designer and the user at the requirements analysis stage. In this paper when we use the term “conceptual model” we mean a model that is not implementation specific.ISBN: 978-84-616-3847-5 3594Peer reviewe

Conditions for interoperability

Interoperability for information systems remains a challenge both at the semantic and organisational levels. The original three-level architecture for local databases needs to be replaced by a categorical four-level one based on concepts, constructions, schema types and data together with the mappings between them. Such an architecture provides natural closure as further levels are superfluous even in a global environment. The architecture is traversed by means of the Godement calculus: arrows may be composed at any level as well as across levles. The necessary and sufficient conditions for interoperability are satisfied by composable (formal) diagrams both for intension and extension in categories that are cartesian closed and locally cartesian closed. Methods like partial categories and sketches in schema design can benefit from Freyd’s punctured diagrams to identify precisely type-forcing natural transformations. Closure is better achieved in standard full categories. Global interoperability of extension can be achieved through semantic annotation but only if applied at run time

Relational Foundations For Functorial Data Migration

We study the data transformation capabilities associated with schemas that are presented by directed multi-graphs and path equations. Unlike most approaches which treat graph-based schemas as abbreviations for relational schemas, we treat graph-based schemas as categories. A schema $S$ is a finitely-presented category, and the collection of all $S$-instances forms a category, $S$-inst. A functor $F$ between schemas $S$ and $T$, which can be generated from a visual mapping between graphs, induces three adjoint data migration functors, $\Sigma_F:S$-inst$\to T$-inst, $\Pi_F: S$-inst $\to T$-inst, and $\Delta_F:T$-inst $\to S$-inst. We present an algebraic query language FQL based on these functors, prove that FQL is closed under composition, prove that FQL can be implemented with the select-project-product-union relational algebra (SPCU) extended with a key-generation operation, and prove that SPCU can be implemented with FQL