Nearly all modern software applications, from the simplest website user account system to the most complex, enterprise-level, completely-integrated infrastructure, utilize some sort of backend data storage and business logic that interacts with the backend. The ubiquitous nature of this backend/business dichotomy makes sense as the need to both store and manipulate data can be traced as far back as the Turing Machine in Computer Science. The most commonly used technologies for these two aspects are Relational Database Management Systems (RDBMS) for backend and Object-Oriented Programming (OOP) for business logic. However, these two methodologies are not immediately compatible and the inherent differences between data represented in RDBMS and data represented in OOP are not trivial. Taking a .NET developer’s perspective, this report aims to explore the RDBMS/OO dichotomy and its inherent issues. Schema management theory and algebra are discussed to gain better perspective of the domain and a survey of existing solutions for the .NET environment is explored. Additionally, methods outside the mainstream are discussed. The advantages and disadvantages of each are weighed and presented to the reader to help aid in design implementations in the future. / text

The current popular, distributed, n-tiered, object-oriented application architecture pro- vokes many design debates. Designs of such applications are often divided into logical layer (or tiers) - usually user interface, business logic and domain object (or data) layer, each with their own design issues. In particular, the latter contains data that needs to be stored and retrieved from permanent storage. Decisions need to be made as to the most appropriate way of doing this - the choices are usually whether to use an object database, to communicate directly with a relational database, or to use object-relational mapping (ORM) tools to allow objects to be translated to and from their relational form. Most often, depending on the perceived profile of the application, software architects make these decisions using rules of thumb derived from particular experience or the design patterns literature. Although helpful, these rules are often highly context-dependent and are of- ten misapplied. Research into the nature and magnitude of 'design forces' in this area has resulted in a series of benchmarks, intended to allow architects to understand more clearly the implications of design decisions concerning persistence. This study provides some results to help guide the architect's decisions. The study investigated and focused on the <i.performance of object persistence and com- pared ORM tools to object databases. ORM tools provide an extra layer between the business logic layer and the data layer. This study began with the hypothesis that this extra layer and mapping that happens at that point, slows down the performance of object persistence. The aim was to investigate the influence of this extra layer against the use of object databases that remove the need for this extra mapping layer. The study also investigated the impact of certain optimisation techniques on performance. A benchmark was used to compare ORM tools to object databases. The benchmark provided criteria that were used to compare them with each other. The particular benchmark chosen for this study was OO7, widely used to comprehensively test object persistence performance. Part of the study was to investigate the OO7 benchmark in greater detail to get a clearer understanding of the OO7 benchmark code and inside workings thereof. Included in this study was a comparison of the performance of an open source object database, db4o, against a proprietary object database, Versant. These representatives of object databases were compared against one another as well as against Hibernate, a popular open source representative of the ORM stable. It is important to note that these applications were initially used in their default modes (out of the box). Later some optimisation techniques were incorporated into the study, based on feedback obtained from the application developers. There is a common perception that an extra layer as introduced by Hibernate nega- tively impacts on performance. This study showed that such a layer has minimal impact on the performance. With the use of caching and other optimisation techniques, Hibernate compared well against object databases. Versant, a proprietary object database, was faster than Hibernate and the db4o open source object database. Copyright / Dissertation (MSc)--University of Pretoria, 2010. / Computer Science / unrestricted

Die Arbeit untersucht die Realisierungsmöglichkeiten der Potenziale des objektorientierten Paradigmas im Bereich der Management Support Systems (MSS). Die Untersuchung konzentriert sich dabei auf die grundlegende Datenhaltungskomponente, das Data Warehouse (DWH) respektive Object Warehouse. Dazu wird im ersten Teil zunächst nach einer ausführlichen Analyse der Begriffslandschaft im Bereich der Management Support Systems und einer geeigneten Neudefinition und Einordnung des Data Warehouse auf den Entwicklungspfad des Data Warehouse eingegangen, bei welchem insbesondere die Anforderungen und Zielsetzungen des Data-Warehouse-Konzeptes herausgearbeitet werden. Darauf aufbauend wird ein generelles, systemunabhängiges Data-Warehouse-Konzept entwickelt und gegenüber den in der Literatur und Praxis vorherrschenden, konventionellen Konzepten bewertet. Basierend auf einer umfassenden Klassifizierung und Analyse des objektorientierten Paradigmas und seiner MSS- und DWH-spezifischen Verbesserungspotenziale erfolgt anschließend die Konzeption für ein Object Warehouse. Angesichts der erheblichen Anzahl bezüglich Konzepten und Zielsetzungen sehr unterschiedlicher Objekt-Paradigmata, muss die gleichwohl notwendige Paradigmen-Diskussion und Integration teilweise beschränkt auf den Teilaspekt der Objectbase Management Systems (OBMS) erfolgen, speziell auf solche, die die geforderten semantischen Modellierungsmöglichkeiten des Objekt-Paradigmas für den Reconciled Object Layer des Data Warehouse unterstützen. Im zweiten Teil der Arbeit werden die in konkreten Projekten gewonnenen Erkenntnisse bezüglich der Umsetzung des Object-Warehouse-Konzeptes in der Praxis vorgestellt und einer kritischen Würdigung unterzogen. Dabei werden erhebliche Diskrepanzen bezüglich der Umsetzung methodischer Konzeptionen in realen Software-Werkzeugen expliziert, was eine umfassende Umsetzung des Object-Warehouse-Konzeptes zur Zeit noch erheblich einschränkt.