| M.P. Atkinson and P. Bunemann. Types and persistence in database programming languages. ACM Computing Surveys, 19(2), June 1987. |
....objects could be implemented with the CLOS metaobject protocol. The first and second CLOS Users and Implementors Workshops of 1988 and 1989 are good sources for information on a wide spectrum of CLOS aspects. 6. 2 Persistence Related Work A broad survey of language persistence can be found in [16]. An earlier paper about PCLOS [2] also provides a long list of references. In this paper we will limit ourselves to pointing out some research reports that specifically exemplify different techniques for introducing persistence into programming languages. The main techniques are full integration ....
Malcolm P. Atkinson and O. Peter Buneman. Types and persistence in database programming languages. Computing Surveys, 19(2):105--189, June 1987.
....term for mechanisms that allow application data from a program execution space to somehow survive the execution of the program, so that in a later execution it can be used again. There are many schemes that can be used for supporting persistence. For a complete survey, the reader is referred to [3]. The most sophisticated and desired form of persistence is the orthogonal persistence [4] It is the provision of persistence for all data irrespective of their type. In a programming language providing orthogonal persistence, persistent data is created and used in the same way as non persistent ....
Atkinson, M. P.; Buneman, O. P.: "Types and Persistence in Database Programming Languages". ACM Computing Surveys 19(2), pp. 105 -- 190, June 1987.
....[9] From integrated database programming languages hke PS Algol [2] Napier88 (see Chapter 1.1. 3) Amber [4] and P Quest, mentioned before, Tycoon inherits the orthogonahty of elementary kernel concepts for persistence abstraction, type complete data struc turing, and iteration abstraction [1, 24]. Motivated by an analysis of the conceptual and technological foundations of ex isting database languages (see Chapter 1.4.2) the Tycoon system pursues the idea of a strictly reduced kernel language supporting naming, binding and typing of pre defined semantic objects (variables, functions, ....
M.P. Atkinson and P. Bunemann. Types and persistence in database program- ming languages. ACM Computing Surveys, 19(2), June 1987.
....It leads to the following module initialization sequence: initEnv=bnd O phoneE=init En vO phone=linkEn v. linkPhone(init En v) mainE=phoneEn vU main=linkEn v. linkMain(phoneE) 3. 3 The Potential of Persistent Objects This section demonstrates how the concept of orthogonal persistence [AB87] as found in DBPL extends the potential for interoperability along two new dimensions: sharing over time and sharing between multiple users. DBPL introduces the notion of a persistent module (database module) to define per sistent location bindings in a strongly typed programming environment. ....
M.P. Atkinson and P. Bunemann. Types and Persistence in Database Programming Languages. ACM Computing Surveys, 19(2), June 1987.
....(alternate) can be tried (if a recovery block scheme [2] is used to tolerate software design faults) The former approach is often referred to as checkpointing. The features which are used for data saving and restoring in the latter are often called state restoration features. Data persistence [3, 4] relies on saving values of data from a program execution space so that they can be used in a later execution: that is the values persist from one execution to another. There are many possible schemes for supporting persistence; for a complete survey, the reader is referred to [5] In our ....
Atkinson, M. P.; Buneman, O. P.: "Types and Persistence in Database Programming Languages". ACM Computing Surveys 19(2), pp. 105 -- 190, June 1987.
....of data intensive applications by contributions on two levels. At the language level, they provide flexible naming, typing and binding mechanisms between all computational entities relevant for a data intensive application based on an integrated model for persistent (bulk) data, code and threads [AB87, MS94] At the system level, they provide a matching integrated system technology (like tagged object representations, iteration abstractions over multiple bulk types, garbage collection, persistent abstract machines, portable code representations) that overcomes several severe mismatches of ....
M.P. Atkinson and P. Bunemann. Types and persistence in database programming languages. ACM Computing Surveys, 19(2), June 1987.
....1 Bulk Data: A Language and System Problem There is no doubt that bulk types are of central importance in data intensive application programming. Accordingly, the design and implementation of bulk types is a key topic in DB and DBPL research and development [Sch78, ADG 89, ABW 90, HS89, AB87] Irrespective of the particular kind of bulk data structures present in a given database programming environment (e.g. lists, sets, relations in traditional DBPLs; class extents in object oriented databases; base predicates in deductive databases or extensionally defined functions in functional ....
M.P. Atkinson and P. Bunemann. Types and Persistence in Database Programming Languages. ACM Computing Surveys, 19(2), June 1987.
.... set, and list) and operators to represent and manipulate complex objects [5, 29] using the abstract data type concept exploited in programming languages [36, 7, 30] using object oriented paradigms [26, 15, 3] and bringing persistency and a data managing capabilityinto programming languages [4, 6, 19]. A notable feature of these newer approaches is that they enable explicit and natural representation of logical relationships among complex objects, more than conventional approaches suchas the hierarchical, network, and relational data models. Many of the newer approaches support a concept of ....
M. P.Atkinson and P. Buneman. Types and persistence in database programming languages. ACM Computing Surveys, 19(2), Jun 1987.
....loss of information. This problem is known as impedance mismatch [Atk78] Its avoidance is an essential motivation for the development of database programming languages (DBPLs) which attempt to integrate features from programming languages and databases. Early work on DBPLs has been surveyed [AB87] Essentially two different approaches have been employed : ffl the programming language approach which extends programming languages with database features; and ffl the database approach which extends database systems with programming language features. 1.1.1 Programming Language Approach ....
....and parameter passing, have been integrated into an existing database system. Moreover, the notion of symmetric procedures demonstrates that fundamental concepts in databases and programming languages can be unified. Database systems have been criticized for lack of expressive power in [AB87] While maintaining the simplicity of the language, procedures allow users to build new complex operations using simple ones. Moreover, procedures can be used as fundamental tools to integrate other programming concepts to Relix. For example, procedures have been used to define event handlers in ....
M. P. Atkinson and O. P. Buneman. Types and persistence in database programming languages. ACM Surveys, 19(2):106--190, June 1987.
....###ffi ae #j [15] U[ i , ##:L### =K#;Qae ## HL OE 7L ahffi ### 8# #) # t ### # ,#j . ###, K#;Qae ## HL OE 7L ah## =K#;Qae ## loimU[ K# # . #)ffi ###j =K#;Qae ## 2 :#### ffi ae ffi CG##9L HL OE ### i OE 3 ### # ## ffi ### ae # ffi ###,# # i OE i #j UW ### # j [4]. U[ i ae # f, K#;Qae ## loimU[5 # .#)## =K#;Qae ## HL OE 7L ahffi ## f VZ## ### # ### i # #j [7] ### #####9L)### =K#;Qae ## 2 :#### km4 im, HL OE 7L ah9L #) ffi ae # ffi ### # ### loimU[ K# # .#)# ae ###,#(persistence) ae ###9L 4 UW # UW, ffi #### =K#;Qae ## lo imU[5 # ....
....9Mim 4 ## # SQL i 4GL, U[5 # ###ae # )KL ah(Graphical User Interface) ###### ### #j . ### .#)### ###ae ffi #####2L ahXZ#### j ### #j ### ae #ae,# #j . U[ i #:Lim ###### ### ah XZ#### 2 # j f # )ae # # )KL ahffi ####ah) #ae ### # ffi ###ffi # #CK# #j [4]. # ffi ### loimU[5 )### 3 lm 6# HL OE 7L ah(Embedded Database Language) #)### #2Lm#j . ###, ffi #### #### ( # .#)im m# loimU[ K# #9L HL OE 7L ah### # ) #### # # # #m# # 9L) ae,#ae,# #, HL OE 7L ah9L j #) #m# df ### # #j . CG, ###ae ### fj j ## # 2M # ###) #### ffi ae UW ....
[Article contains additional citation context not shown here]
Malclm P. Atkinson and O. Petter Buneman. "Types and Persistence in Database Programming Languages". ACM Computing Surveys, 19(2):105-- 190, June 1987.
....data types such as at relations, a language that supports orthogonal persistence can serve as an appropriate medium for future database systems which are to integrate complex database objects and various advanced features of programming languages including those of objectoriented paradigm. See [6] for a survey in this eld. The necessary techniques to realize orthogonal persistence in a typed programming language have been established during the research and experimentation of persistent programming languages, most notably PS algol [5] The approaches so far proposed [4, 3, 19, 8, 2, 23, ....
M.P. Atkinson and O.P. Buneman. Types and persistence in database programming languages. ACM Computing Surveys, 1987.
....(4) An array of db type objects. An object that is to be persistent is required to be of a db type. However, a db type object can be either persistent or non persistent. Note that any type definable in C may be analogously defined as a db type. Furthermore, since persistence is orthogonal [Atki87] over db types, one could program exclusively in db types and achieve the effect of strict orthogonality if so desired. 6 Db types were introduced in E so that the compiler can always distinguish between objects that can only reside in memory and those that generally reside on disk (but may also ....
Atkinson, M., and Buneman, O.P., "Types and Persistence in Database Programming Languages," ACM Comp. Surveys, 19, 2, June 1987.
....of the TM model [HU] As we will show in this paper, when inputs are streams with dynamic binding, interactive computing devices can be more expressive than TMs. 2.2. Persistent Turing Machines Persistence of state typifies computing devices as diverse as software objects and intelligent agents [AB, RN]. In this section, we extend Turing Machines by introducing persistence. It is interesting to note that Turing foresaw interactive Turing Machines in his seminal paper [Tu] where he made a distinction between automatic machines, now known as TMs, and choice machines, which allow choices by an ....
....e, BC, BCD, BCD, n From this example, it is easy to see how any abstract data type can be implemented as a PTM. Other examples of interactive behaviors that can be expressed by PTMs include single user databases, holding a dialogue, driving home from work [We1] and playing two person games [Ab]. 2.4 PTM interaction streams The interaction of PTMs with their environment can be described by interaction streams, which interleave PTM s inputs and outputs: Interaction (I O) streams have the form (i 1 ,o 1 ) i 2 ,o 2 ) where i s are input tokens generated by the environment ....
Malcolm Atkinson, Peter Buneman, Types and Persistence in Database Programming Languages, ACM Computing Surveys 19:2, 1987.
....from naturals to naturals, choice machines were not an appropriate model to use, and they have not been considered since. 4 Dina Q Goldin 2. 2 Persistent Turing Machines (PTMs) Persistence of state typifies computation as diverse as databases, object oriented systems, and intelligent agents [AB,ZM,RN]. In this section, we extend TMs by introducing persistence. In the next section, this is coupled with an extension of computational semantics from string to stream based, to result in a model for sequential interactive computation [WG1] Definition 2.2. A Persistent Turing Machine (PTM) is a ....
Malcolm Atkinson, Peter Buneman. Types and Persistence in Database Programming Languages, ACM Computing Surveys 19:2, 1987
....time or has be stored back to disk. The type based approach seems to be reasonable from an implementation point of view, since only instances of specific types are confronted with additional overhead in terms of increased runtime and space. On the other hand as Atkinson and Buneman pointed out[2] it is very inconvenient from a software engineering point of view to distinguish artificially between persistent and non persistent types, which are otherwise identical. We postpone therefore the type based approach and concentrate on orthogonal persistence[2] instead, allowing any arbitrary ....
....Atkinson and Buneman pointed out[2] it is very inconvenient from a software engineering point of view to distinguish artificially between persistent and non persistent types, which are otherwise identical. We postpone therefore the type based approach and concentrate on orthogonal persistence[2] instead, allowing any arbitrary value to be potentially persistent. 3.1 Reachability vs. Location In an reachability based approach, all persistent data is potentially scattered over the whole address space of a running process (Fig. 1) Any time such Code Static Data Heap Stack Figure 1: ....
M. P. Atkinson and O. P. Buneman. Types and Persistence in Database Programming Languages. IEEE Software, 18(8), Aug. 1992.
....parents fbob,patg] These object speci cations are well typed with respect to the class de nitions in Examples 9, 10, 12, and 14. 4.3 Databases A database in ROL2 consists of two parts: a schema and an instance. Example 17 Consider a manufacturing company s parts database based on the one in [4], where it is proposed as a task to test database programming languages. Schema abstract class part [name )string] 21 class basepart isa part [ cost )integer(0. 1000) class compart isa part [ madefrom ) subpart )part, qty )integer(1. 100) baseparts( fbasepartg f baseparts( hBi ....
M. P. Atkinson and O. P. Buneman. Types and Persistence in Database Programming Languages. ACM Computing Surveys, 19(2):105-190, 1987.
....Also, the use of rollbacks to support hypothetical database access may cause unacceptable delays in the concurrency system, complicate the transaction protocols, and degrade the performance of the system. The development of Heraclitus[Alg,C] was greatly influenced by other research on DBPLs [AB87] and in particular by DBPLs that combine the relational model with an imperative programming language, such as PASCAL R [Sch77] 3 The Language of Heraclitus[Alg,C] The foundation of the Heraclitus paradigm is the notion of delta values, often simply termed deltas; each of these is a function ....
M. Atkinson and P. Buneman. Types and persistence in database programming languages. ACM Computing Surveys, 19(2):105--190, June 1987.
....classes. Similarly, the Stoneman report [Buxton 80] identified the need for similar facilities in IPSEs. Efforts to resolve the problem have led to research in the related technologies of object oriented database (OODBs) systems [Beech 87, Smith 87] and persistent programming languages [Atkinson 87] These efforts are being led by the database and programming language communities respectively and represent a convergence of the philosophies which have historically separated the two communities. Unfortunately, there exists neither a definitive version of the object model, or a standard ....
....languages with a mechanism for the preservation of data between program executions in which the programmer is relieved of the need to explicitly read write data to from files or a database. The essential features required by persistent programming languages have been identified by Atkinson [Atkinson 87] and are as follows. Persistence: High level programming languages provide types and constructs such as pointers, arrays, etc. which permit the construction and manipulation of complex data structures. However, such data structures are permitted only to exist during the execution time of a ....
[Article contains additional citation context not shown here]
Atkinson, M.P., Buneman, O.P.: 'Types and Persistence in Database Programming Languages', ACM Computing Surveys, 19 (2), pp 105 - 190, June 1987.
....semantics is possible in relational database systems, it requires varying amounts of programmer intervention. Programming languages do not typically support either relation or relationship constructors directly. This shortcoming, in part, led to the development of database programming languages [5], which provide some form of relation and relationship constructor, but these types are not always fully integrated into the languages for example, some are not type complete [50, 43, 45] In addition, the models of relations and relationships that are provided usually have the same restrictions ....
....and generality to determine the extent to which associative accesses can be optimized in the presence of type and computational completeness. 5. 3 Persistence Pleiades defines persistence to be a property of instances, and this property is orthogonal to other properties of the instance [5]. Orthogonality means that the interfaces to persistent objects are identical to those of non persistent objects [61] so that, for example, queries and concurrency control can occur over both persistent and transient objects. Applications can dynamically select objects that should become ....
M. P. Atkinson and O.P. Buneman. Types and Persistence in Database Programming Languages. ACM Computing Surveys, 19(2):105--190, Jun 1987.
.... Introduction New developments, both in the database field and in the programming languages field, have led to the design of new database management systems [Ba88] Ki89] Deux90] These systems have the following characteristics: a complex object model [LR89a] a persistent programming language [AB87], and an object management system [VBD89] Object management systems have to fulfill the following requirements: i) efficient management of large amount of (large) objects; ii) object sharing and versioning; iii) and usual database functionality such as transaction management, concurrency ....
M. Atkinson, P. Buneman, "Types and Persistence in Database Programming Languages." ACM Computing Surveys, June 1987.
....3 2 THE MODEL In this section, we present the model by examples. The model is that used in IQL [5] extended with (i) methods and (ii) list types. The language is discussed in the next section. 2. 1 Classes and Relations In the present paper, we use as running example, the Bill of Materials [7]. Example 2.1 A portion of the schema is given by: class part : equal basepart compositepart and [name : string] class basepart : isa part and [price : num; mass : num] class cheapbasepart : isa basepart; class compositepart : isa part and [assemblycost : num; massincrement : num] ....
M. Atkinson and P. Buneman. Types and Persistence in Database Programming Languages. ACM Computing Surveys, June 1987.
No context found.
M.P. Atkinson and P. Bunemann. Types and persistence in database programming languages. ACM Computing Surveys, 19(2), June 1987.
No context found.
M.P. Atkinson and O.P. Buneman. Types and persistence in database programming languages. ACM Computing Surveys, 1987.
No context found.
Atkinson, M.P. and Buneman, O.P. Types and Persistence in Database Programming Languages. ACM Computing Surveys 19, 2 (June 1987), 105-190.
No context found.
ATKINSON,M.P.AND BUNEMAN, O. P. 1987. Types and persistence in database programming languages. ACM Comput. Surv. 19, 2 (June).
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