Copeland, G., Maier, D. Making smalltalk a database system. In Proceedings of the 1984.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....an added touch of go with what s at hand has storage be provided by the file system instead of using a database. The GemStone system [25] introduces a new language, OPAL, to deal with persistence. This can be used as the sole application language, or it can be used in conjunction with Smalltalk [26] or C. The advantage of this approach is that data processing and storage can be tuned to each other. The disadvantage is that a programmer must learn a new language to enjoy the full power of the system. 7 Conclusion We began with the observation that the tension between the goals of ....

G. Copeland and D. Maier. Making Smalltalk a database system. In Proceedings of the ACM/SIGMOD International Conference on the Management of Data, 1984.

.... type system; as a result, a great deal of marshalling code needs to be written in order to convert XML into Java objects and vice versa; this code needs to be written in addition to the marshalling code that is necessary in order to bridge the (long known) impedance mismatch between Java and SQL [10]. Another deficiency of Java is that it is not always appropriate to deal with failures or quality of service requirements in a network centric environment. Furthermore, a great deal of functionality needed in most Web services such as logging, database access, security, authorization, ....

G. Copeland and D. Maier. Making Smalltalk a database system. In Proceedings of the 1984.

....concept and the concept of dynamic molecules combined with the expressiveness of MQL seem approximately equal to these characteristics defining object orientation. In contrast to these models, MAD does not support behavioral object orientation. The early available object oriented database models [7] show (compared to e.g. relational models) some deficiencies in their query capabilities, i.e. setorientation was mostly out of their scope. The database was queried in a navigational manner along the references defined between the database objects (e.g. path expressions in OPAL [33] By now a ....

G. Copeland and D. Maier, Making Smalltalk a Database System, in: Proc. ACM SIGMOD Int. Conf. on Management of Data, Boston, Ma (1984) 316-325.

....XML data at the end of processing. 2. Java Database mismatch: Java objects must be marshalled back and forth through JDBC like interfaces to access and update the RDBMS, the infamous database impedance mismatch that triggered the development of object databases technology in the recent past[CM84] While most people seem to have resigned themselves to using interfaces like ODBC and JDBC, the additional XML Java stuttering step [Lam] might have a good chance to finally turn people s minds. It is not unusual that eighty percent or more of Web applications code is indeed due to data ....

G. Copeland and D. Maier. Making Smalltalk a database system. In Proceedings of the

....e#orts. Although these factors have made RDBMS technology into a multi billion dollar industry [33, 37] there are still several areas where this model can be substantially improved. In particular, it is still fairly di#cult to write applications that use an RDBMS due to the impedance mismatch [8] between the set based relational model and tuple at a time procedural languages used to write applications. Further, these applications do not take the best advantage of global system resources. The clean separation of the system into a relational processor and procedural application code is a ....

George P. Copeland and David Maier. Making smalltalk a database system. In Beatrice Yormark, editor, SIGMOD'84, Proceedings of Annual Meeting, pages 316-- 325, Boston, Massachusetts, 18--21 June 1984. ACM Press.

....were intended to simplify the development of database applications code through a closer integration of database and programming language constructs. Similarly, despite its object orientedness (stemming from C ) it should not be confused with object oriented database languages such as OPAL [Cope84, Maie87] or COP [Andr87] The objective of E is to simplify the development of internal systems software for a DBMS. Layered above the Storage Manager is a collection of access methods that provide associative access to files of storage objects and further support for versioning (if desired) For access ....

....accommodated on a single page, the Storage Manager automatically converts it into a large object, leaving its object header in place of the original small object. We considered the alternative of using purely logical surrogates for OID s rather than physical addresses, as in other recent proposals [Cope84, Ston86b], but efficiency considerations led us to opt for a physical surrogate scheme with logical surrogates, it would always be necessary to access objects via a surrogate index. Figure 2 shows an example of our large object data structure. Conceptually, a large object is an uninterpreted byte ....

[Article contains additional citation context not shown here]

Copeland, G. and D. Maier, "Making Smalltalk a Database System," Proc. of the 1984 SIGMOD Conf., Boston, MA, May 1984.

....mechanism, functions (methods) in Proposition 1.3; hence, it is desirable to have a DBMS which naturally stores such constructs. The next mechanism allows one to construct a data element which can take a value from one of several types. Examples of the utility of this construct are presented in [COPE84]. The last mechanism allows type constructors to be recursively composed to support complex objects which have internal structure such as documents, spatial geometries, etc. Moreover, there is no requirement that the last type constructor applied be the one which forms sets, as is true for second ....

Copeland, G. and Maier, D., "Making Smalltalk a Database System," Proc. 1984 ACM-SIGMOD Conference on Management of Data, Boston, Mass., June 1984.

.... number of new database system research projects have been initiated to address the needs of this emerging class of applications: EXODUS 1 at the University of Wisconsin [Care85a, Care86] PROBE at CCA [Daya85, Mano86] POSTGRES [Ston86b, Ston86c] at Berkeley, GEMSTONE at Servio Logic Corporation [Cope84, Maie86], STARBURST at IBM Almaden Research Center [Schw86] and GENESIS [Bato86] at the University of Texas Austin. Although the goals of these projects are similar, and each uses some of the same mechanisms to provide extensibility, the overall approach of each project is quite different. For example, ....

.... as RIGEL [Rowe79] Pascal R [Schm77] Theseus [Shop79] or PLAIN [Kers81] as these languages were intended to simplify the development of database applications code through a closer integration of database and programming language constructs, or with object oriented query languages such as OPAL [Cope84, Maie86] the objective of E is to simplify the development of internal systems software for a DBMS. Layered above the Storage Object Manager is a collection of access methods that provide associative access to files of storage objects and further support for versioning (if desired) For access ....

[Article contains additional citation context not shown here]

Copeland, G. and D. Maier, "Making Smalltalk a Database System", Proceedings of the 1984 SIGMOD Conference, Boston, MA, May 1984.

....the EXODUS storage system automatically converts it into a large storage object, leaving its object header in place of the original small object 3 . We considered the alternative of using surrogates for OID s rather than physical addresses, as in other recent proposals [Pollack, et al. 1981, Copeland and Maier 1984, Skarra, et al. 1986, Stonebraker and Rowe 1986, Stonebraker 1987] but we rejected this alternative due to what we anticipated would be its high cost with surrogates, it would always be necessary to access objects via a surrogate index. Besides, a surrogate index can be implemented above ....

Copeland, G. and D. Maier, "Making Smalltalk a Database System", Proceedings of the 1984 SIGMOD Conference, Boston, MA, May 1984.

.... object implementations (on any kind of storage system) is the ability to load persistent objects as active main memory objects, using the object model of the application environment (e.g. C , Java, Smalltalk, OMG CORBA, or COM) This minimizes the impedance mismatch between the language and DBMS [11], but creates performance challenges for the database implementation, especially when mapped to an RDBMS rather than a custom storage system. One major performance problem is that application object models are inherently navigational. That is, objects have references or relationships to other ....

Copeland, G. and D. Maier, "Making SmallTalk a Database System," Proc. 1984 ACM SIGMOD Conf., pp. 316-325.

.... Stroustrup] Therefore, many analogies can be drawn between programming concepts and database concepts as surveyed in [Dearle89] Matthes 89] Moreover, some researchers have taken the route to enhance an existing object oriented programming environment to arrive at an object oriented DBMS [Maier 84, Agrawal89] The prime issues to be addressed are support for persistency, concurrency control, recovery, and declarative query formulations. Although many recent DBPL papers [Dearle89, Agrawal89, LeCluse, Matthes 89, Atkinson81] aim at these potential markets, few have taken the requirements ....

G. Copeland and D. Maier `Making Smalltalk a Database system', ACM SIGMODRecords, Vol 8, 1984.

.... and software management, require the capability to create and access multiple versions of an object [8, 23, 30, 51] Object versions are also important for historical databases, such as those used in accounting, legal, and financial applications, that must access the past states of the database [19, 44]. Support for active databases, such as those used in computer integrated manufacturing, power distribution network management, and air traffic control, requires the capability to attach with objects conditions and actions that are triggered when the conditions are satisfied [21, 50] Finally, the ....

....identities that allows persistent database objects to have an existence independent of their values. Some extensible database projects, such as 2 [12, 17, 39, 44, 45, 48] also have similar goals. O is in the same spirit as the work done in designing database programming languages, such as [7, 10, 19, 37, 43, 46, 47, 49, 52]; it strives to be the single language for data definition, data manipulation and general computation to avoid the problems arising out of impedance mismatch [19] O also shares the concerns of the persistent programming languages, such as [6, 16, 38, 40 42] persistence is a property of ....

[Article contains additional citation context not shown here]

G. Copeland and D. Maier, "Making Smalltalk a Database System", Proceedings of the 1984 ACM SIGMOD Intl. Conf. on Management of Data, Boston, Massachusetts, June 1984, 316-325.

....share that information among multiple cooperating users. Environments that can successfully integrate features from programming languages and databases will enable us to build and maintain such applications more easily. Successful integration has been described as overcoming the impedance mismatch [Copeland and Maier, 1984] between programming language data models and database data models. Traditional database systems require users to cast their problems first in one model and then the other. Applications programmers would benefit enormously from being able to manipulate persistent data (data that outlive the ....

George Copeland and David Maier. Making Smalltalk a database system. In Proceedings of the ACM SIGMOD International Conference on Management of Data (Boston, MA, June 1984), vol. 14, no.2 of ACM SIGMOD Record, ACM, pp. 316--325.

....into modules that is at once comprehensible and suitable for a team of programmers is the primary goal of program modeling. If the modules follow the natural decomposition of the problem, the program should be easier to understand. Such a program model is said to reduce the impedance mismatch [CM84] between an application domain and the program design. A program that is easy to understand is easier to maintain, debug, and modify due to changing requirements. Program modeling is therefore not only critical to the early phases of software development, but also the later phases. Developing a ....

George Copeland and David Maier. Making Smalltalk a Database System. SIGMOD Record, 14(2), 1984.

....the nineties, O O seems to be the most promising technology for the development of large, complex programs. It offers three important characteristics: 1. Accurate program modeling. Programs are very similar to the application area from which they are derived. This minimizes the impedance mismatch [CM84] between how an application designer describes the problems that need to be solved and the programmer who implements some solution for the application. 2. Reuse of program fragments. By modeling programs as encapsulated objects it is conceivable that an object defined for one application can be ....

George Copeland and David Maier. Making Smalltalk a Database System. SIGMOD Record, 14(2), 1984.

....operators, defined for all object types. We leave out from our scope the ability to define operators specific to an object type and will therefore not discuss works in that direction (models based on abstract data types, like GALILEO [Albano 86] for instance, or on programming languages [Copeland 84] or POSTGRES like extensions [Stonebraker 86] Traditional data models fail to respond to such new requirements. For instance, the structural constraints inherent to the classical relational model [Codd 70] normalization rules, and in particular the first normal form) force the designer to ....

G. COPELAND, D. MAIER: "Making Smalltalk a database system", in Proc. ACM SIGMOD International Conference on the Management of Data, Boston, Mass., 1984

No context found.

Copeland, G., Maier, D. Making smalltalk a database system. In Proceedings of the 1984.

No context found.

G. Copeland and D. Maier. Making Smalltalk a Database System. In Proc. ACM/SIGMOD International Conference on the Management of Data, 1984, 1984.

No context found.

G. Copeland and D. Maier. Making Smalltalk a database system. In Proceedings of the 1984 ACM SIGMOD International Conference on Management of Data, pages 316--325. ACM, 1984.

No context found.

G. Copeland and D. Maier, "Making Smalltalk a Database System," Proceedings of ACM SIGMOD Conference, pp. 316-325, (June 1984).

No context found.

G. Copeland and D. Maier. Making Smalltalk a database system. In Proceedings of the ACM/SIGMOD International Conference on the Management of Data, 1984.

No context found.

G. Copeland and D. Maier. Making Smalltalk a Database System. In Proceedings International Conference on Management of Data, pages 316--325, Boston, MA, 1984. 41

No context found.

G. Copeland and D. Maier. Making Smalltalk a database system. In Proceedings of the ACM/SIGMOD International Conference on the Management of Data, 1984.

No context found.

G. Copeland and D. Maier, `Making Smalltalk a database system', Proceedings of the 1984 ACM SIGMOD Intl. Conf. on Management of Data, Boston, Massachusetts, June 1984, pp. 316--325.

No context found.

G. P. Copeland and D. Maier. Making Smalltalk a database system. In Proceedings of ACM-SIGMOD

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC