Abstract A Language Abstraction Layer for Relational DBMS

A Language Abstraction Layer for Relational DBMSNigel StangerDepartment of Information Science, University of Otago,Dunedin, New ZealandAbstractCurrent database definition techniques tend to be either purely language-based or purely graphical. There is little or no integration between the two. This places artificial limits on the environment that developers must work in; ideally, they should be able to switch paradigms as the need arises. This lack of integration also causes problems with database reengineering. This paper describes an architecture for a relational abstraction layer, which isolates the front-end “dialect” used from the underlying relational implementa-tion. This allows tighter integration between different database definition techniques.1. IntroductionThere are numerous software tools available for use with database design and definition. The two most common generic products are graphical CASE tools and SQL. Both are equally effective at what they do, but usually work in isolation from each other. A perfect example of this is a CASE tool that generates SQL code from an entity-relationship diagram (ERD) and associated data dictionary. Generally, the code is generated after the diagram is completed, and it is usually not a simple task to reengineer the generated code back into a diagram. This problem is further exacerbated if the ERD has been altered in the meantime.Many CASE tools have reasonable reverse engineering capabilities (for example, Sybase’s Deft), but more often than not, information is lost in the process of converting back to an ERD.Graphical tools were developed as a more intuitive method of defining databases than a purely language-based approach. During the last decade, much research has been done on visual environments for database design, definition and manipulation; for example, the SUPER environment [1, 2] and the GOOD environment [3]. It is argued here, however, that such purely graphical approaches suffer from the same problem as the purely language-based approach. That is, by enforcing a “one size fits all” approach, we artificially limit our capabilities.What is needed is a more general method of database definition, which is independent of the paradigm used.Ideally, a developer would be able to choose the paradigm that best suits the situation; for example, they might prefer to use SQL. A different developer working on the same project might prefer to use ERDs. In such a case, they would want to simply “flip a switch” within the development environ-ment and change from one representation (SQL) to the other (ER diagram), without losing any information. Such a mechanism would require some form of intermediate representation which is independent of the way it is to be viewed. In other words, the environment that the end-user sees is really just a front end to the real environment.What we propose is an architecture for implementing a language abstraction layer for relational DBMS. This architecture will consist of the following: a collection of front end “dialects”, including such things as SQL and ERDs; the abstraction layer itself; and a collection of plug-in modules for communicating with different DBMSs.2. Basis for the architectureThe architecture is based on a combination of two separate developments. One is the Open Scripting Architecture (OSA), developed by Apple Computer as part of the OpenDoc initiative [4, 5]. The other is a hypothetical language called D, developed by Chris Date and Hugh Darwen as part of their Third Manifesto [6].The Open Scripting ArchitectureThe OSA is an open architecture developed by Apple Computer which allows end-users to script applications which adhere to the architecture [7]. In that respect it is very similar to the shell scripting languages used under Unix. The OSA is currently only available on the Macintosh platform, but it is being ported to Windows and Unix as a fundamental part of the OpenDoc working environment.An OSA-compliant scripting language is characterised by the following: a central abstraction layer, or scripting component; an optional collection of language dialects such as English, French or C-like; and an optional collection of plug-in modules (scripting additions) for defining additional language capabilities. Extra functionality may also be added to the language by installing OSA-aware applications.3. The architectureWhat is proposed here is an abstraction layer similar to that used in the OSA, based around a language equivalent in capability to the D language. Let us call this language L ,although “language” is possibly not the correct term — as already stated, the language itself may have no direct textual representation. Rather, what end-users see as the “language”would actually be implemented as a dialect on top of the abstraction layer.The direct result of this abstraction layer is that database designers will be able to choose their favourite dialect for database definition, or indeed, switch between dialects on the fly. This allows the developer to choose the environment that best suits the way they work and think, without disad-vantaging those who work in different ways.The intention is that this architecture will be implemented directly on top of the existing OSA as a completely distinct language environment. More precisely, L will be implemented as an OSA scripting component, albeit a slightly unorthodox one, as it will not be used as a true “scripting language” in the OSA sense. Front ends such as ER diagramming and SQL will be implemented as dialects of this component. Specific DBMS functionality will be incorporated via plug-in modules which describe the capabilities and “vocabulary” of the target DBMS. The back end will consist of some sort of communications link to the target DBMS.The initial implementation will target a subset of data definition and manipulation functions for at least three dialects: E-R diagrams, SQL and a D -like dialect. The target DBMS will be Oracle 7.1 running on a DEC 3000 Model 400 under OSF/1. The only complete OSA implementation at the time of writing is on the Macintosh, so this will be the target platform for the front end. The abstraction layer will communicate directly with Oracle using the Oracle Call Interface (OCI) over a client-server link. It is unclear at present as to whether the L scripting component will be able to open a direct client-server link to Oracle; it may be neces-sary to develop a special-purpose application which receives Apple events from the L scripting component and converts them into appropriate OCI calls.Figure 2 shows the structure of the architecture; compare this with the OSA structure shown in Figure 1.4. ConclusionCurrent methods of database definition tend to favour either a purely language-based approach, or a purely graphi-cal approach — there is a lack of integration between the two. What is needed is a paradigm-independent method of defining a database. In other words, an abstraction layer between the selected front end and the target DBMS isnecessary.yerL);Apple, AppleScript, Macintosh, MacOS and OpenDoc are registered trademarks of Apple Computer, Inc.DEC is a trademark of Digital Equipment Corporation. Oracle is a trademark of Oracle Corporation.OSF/1 is a registered trademark of Open Software Foundation, Inc.Unix is a registered trademark of Unix System Laboratories, Inc., a wholly owned subsidiary of Novell, Inc. References[1] A. Auddino, E. Amiel, Y. Dennebouy, Y. Dupont, E.Fontana, S. Spaccapietra, and Z. Tari, “Database Visual Environments Based on Advanced Data Models,” 1992.<ftp://lbdsun.epfl.ch/pub/avi92.ps.Z>[2] A. Auddino, Y. Dennebouy, Y. Dupont, E. Fontana, S.Spaccapietra, and Z. Tari, “SUPER — Visual Interaction with an Object-based ER Model,” 1992.<ftp://lbdsun.epfl.ch/pub/er92.ps.Z>[3]M. Gyssens, J. Paredaens, J. Van den Bussche, and D. VanGucht, “A Graph-Oriented Object Database Model,”University of Antwerp (UIA), Technical Report 92-35, 1992.[4]Apple Computer, “OpenDoc™ for Macintosh: An Overviewfor Developers,” Apple Computer, Inc., Cupertino, California, White Paper December 1994.[5]K. Piersol, “A Close-Up of OpenDoc,” BYTE, vol. 19, pp.183–188, 1994.[6] C. J. Date, “The Third Manifesto,” in Relational DatabaseWritings 1991–1994, C. J. Date, Ed. Reading, Massachusetts: Addison-Wesley, 1995, pp. 309–336.[7]W. R. Cook and W. H. Harris, “The Open ScriptingArchitecture,” Apple Computer, Inc. 1994.<:80/sdm7g/Projects/Python /OSA/OSA.ps.gz>[8] E. M. Berdahl, “Better Apple Event Coding ThroughObjects,” develop, The Apple Technical Journal, vol. 12, pp.58–83, 1992.[9]R. Clark, “Apple Event Objects and You,” develop, the AppleTechnical Journal, vol. 10, pp. 8–32, 1992.[10]H. Darwen and C. J. Date, “Introducing the Third Manifesto,”Database Programming & Design, pp. 25–35, 1995.。