New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here

Design Computation

by: Sid Streich

Design Computation COA 8672

Sid Streich

GPA 3.79

Charles Eastman

Almost Ready


These notes were just uploaded, and will be ready to view shortly.

Purchase these notes here, or revisit this page.

Either way, we'll remind you when they're ready :)

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

Charles Eastman
Class Notes
25 ?




Popular in Course

Popular in Architectural Engineering

This 0 page Class Notes was uploaded by Sid Streich on Monday November 2, 2015. The Class Notes belongs to COA 8672 at Georgia Institute of Technology - Main Campus taught by Charles Eastman in Fall. Since its upload, it has received 13 views. For similar materials see /class/233847/coa-8672-georgia-institute-of-technology-main-campus in Architectural Engineering at Georgia Institute of Technology - Main Campus.

Popular in Architectural Engineering


Reviews for Design Computation


Report this Material


What is Karma?


Karma is the currency of StudySoup.

You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!

Date Created: 11/02/15
Geometric and Solid Modeling How to create shapes in a computer model building form display building form on a screen How to draw Can the computer compute shapes how Seminar in Design Computing Geometric and Solid Modeling How to represent shape Lines in 2D vertices vector and bounds X45rY451 Line2540545451 Slope point on slopebounds Line45 25451 40625406492 X25 Y406 Line44425406492 X45 Y451 Z212 Line2540512 4545112 Origin X y slope yz slope bounds Line754500 45 25451 X25 406 406451 406l12 102545 Z10 Seminar in Design Computing Geometric and Solid Modeling How to represent shape Lines in 2D and 3D vector and bounds Cx 446 Cy 236 R56 a1 952 a23421 are t up 1152 an 31 mi ny ytz 79139 3 Bezier Seminar in Design Computing elliptic y2x3axb Geometric and How to represe Solid Modeling ntshape Lines in 2D and 3D vector and bounds Surfaces surface and boundary theta rauius 39 s thetaIZPl 11 phifPl Seminar in Design Computing l VA lt V x Parameters in xyz space and in uv space Normal to the surface Geometric and Solid Modeling How to represent shape Lines in 2D and 3D vector and bounds Surfaces and faces y Plane eq D Ax By 02 The ectors V b 39 a 39axy by 39ayv b2 39az C a n m CX 39aXv quotayv CZ 39az Z X The cross product of n x m corresponds to the normal to the plane A n2m3 n3mz where B n3m139 n1ms a a a a C x y 2 MW n2 m1 b bx by b2 C 0x Cy 02 Find D by inserting any of the 3 vertices D Aax Bay Caz Seminar in Design Computing Geometric and Solid Modeling How to represent shape Lines in 2D and 3D vector and bounds Surfaces surface and boundary Solid primitives and booleans Synthavision Seminar in Design Computing Geometric and Solid Modeling How to represent shape Lines in 2D and 3D vector and bounds Surfaces surface and boundary Solid primitives and booleans Synthavision Enumeration vs boundaries Seminar in Design Computing Geometric and Solid Modeling What is a solid shape and how to represent it Does a set of points define a shape Seminar in Q Q g i AL 4 q J Ef e gdn Lieui Auimaiiun Ugiiuns labia Mm Mnduw Help 5 11 q IE 3 a n a is e w 5 a Design Computing Geometric and Solid Modeling What is a solid shape and how to represent it Does a set of edges of surfaces define a shape Seminar in Design Computing Geometric and Solid Modeling What is a solid shape and how to represent it 7 I l l D095 3 set 0f surfaces de ne a A solid shape is a connected set of shape faces Clearly orientable partitioing space into an quotinsidequot and quotoutsidequot Seminar In Design Computing Geometric and Solid Modeling What is a legal solid shape Every face edge must join another face no dangling edges Seminar in Klein BOt G Design Computing Geometric and Solid Modeling What is a legal solid shape If face edges are given a consistent direction then every edge consists of 2 edges going in the opposite direction Mobius Band Seminar in Design Computing Geometric and Solid Modeling Interactive Design in 3D A representation that was general enough to depict any shape Editing operations that would allow shapes to be modified limitlessly The Fathers of Solid Modeling 1973 Ian Braid Bruce Baumgal t ACIS Parasolids Seminar in Design Computing Lecture Notes in Computer Science Edited by G 3008 and J Hartmanis 492 D Sriram R Logcher S Fukuda Eds ComputerAided Cooperative Product Development MITJSME Workshop MIT Cambridge USA November 2021 1989 Proceedings V 4 SpringerVerlag I Berlin Heidelberg New York London Paris Tokyo Hong Kong Barcelona Budapest TRANSACTION MANAGEMENT IN DESIGN DATABASES Charles M Eastman Graduate School of Architecture and Urban Planning University of California Los Angeles Ali Kutay Formative Technologies Inc Pittsburgh Pennsyle Abstract Databases are being increasing applied to support design and engineering implemented on a backend le server and supporting shared access A fundamental di erence between traditional database management and design database management is that for most of the design process integrity is partial A management scheme called entity state transaction management is proposed that deals witt both the partial ordering or transactions and concurrency control over shared information resources The techniques for automatic management of integrity are described in the light of the following problems coordinating iterated partial analyses of an engineen39ng system propagation of design decisions in one subsystem to other subsystem and concurrent design operations within a single subsystem The implications of entity state management for engineering database schema de nition are also explored 1 Introduction Integrating the engineering design process with computer technology has been a long term goal and an important research area It is increasingly common for engineers and designers to work at graphical workstations connected by a network to a shared database Controlled from the local environment will be design tools such as schematic design tools detailed part and assembly modeling tools analysis and other application programs The comprehensive model of the artifact being designed will reside in the design database most probably on a backend file server providing database support Design databases like most databases are implemented for the purpose of integrating multiple applications on a common environment One of the m 39 features of this integration is to maintain consistency and integrity within the mogxerl data Developing data abstractions has been the major effort in general database researcht while operation abstractions have received considerable attention only recently The transaction concept is one that is closely related to operation abstractions The transaction concept suggests that instead of allowing arbitrary operations on a database these operations must be structured into sets of actions such that when each set is executed the integrity of the database is maintained in this way a database has complete integrity during all periods between transactions Losses of integrity are temporary and limited to the duration of transactions upon the database The transaction concept has led to development of different techniques to control concurrent operations on a database These concepts fit well with most database applications where data is to be maintained in a correct state ie an integral one for all operations A design is a specification for a product with adequate information for its fabrication Designing that is the de nition of this speci cation typically involves both the development of a speci cation and its incremental evaluation So as to assure that the resulting product achieves various objectives and intentions integrity of the database then involves both the completeness of the specification for fabrication and achievement of the objectives and intentions In design integrity does not exist within the design model until design is almost complete Most operations have the effect of adding to or modifying the database integrity Given this de nition of design it is apparent that a consistent database state where all integrity constraints are satisfied can only be reached towards the end of the design Thus for most of the lifetime of a design database a database state possesses only partial integrity In order to clearly convey this point we develop an example engineering design application Consider the layout of a piping system in a building or chemical plant The objective of such a layout is to rst de ne a piping system that connects some functional elements eg a boiler or a heat exchanger and later to define automatically the sizes of each pipe member and joint so that they satisfy global ow space and sizing criteria Piping systems are usually represented as a graph See Figure 1 Nodes depict the points where uid is supplied source nodes or points where fluid must be pr0vided service nodes or where pipes join connection or intermediate nodes Edges connect pairs of nodes and correspond to pipes At this point the example consists of three transaction classes 1 a pipe sizing program that based on flow rates and pressure defines the diameter of each of the pipes in the network Obviously flow is only possible if all nodes are connected 2 a transaction that is used in piping layout that locates a service node and defines its ew requirements or a source or connection node 1 another transaction used for piping layout that locates a pipe by placing it between two existing nodes When used iteratively it provides connectivity across the graph between a service node and a supply node Notice that in these example transaction classes the standard integrity requirement of a transaction is violated In 1 full integrity does not exist Indeed the purpose of this transaction class is to m to the databases integrity by correctly assigning pipe diameters Correspondingly only partial integrity is required to invoke a transaction of this class eg that nodes are located and connected After a transaction of class 1 has been executed if a transaction of class 2 is called it invalidates the integrity of the database regarding the connectivity of the piping system Any results of transactions of class 1 are invalidated But after an instance of transaction class 2 a pipe sizing transaction cannot be called directly because the connectivity condition which it requires is not satisfied A transaction of class 3 if applied to the new node may connect it to the rest of the piping graph so that complete connectivity is achieved allowing the sizing transaction can be meaningfully reapplied It is evident from this example design that the work on transactions to date has incorporated very restrictive assumptions regarding integrity before during and after transactions 1 prior to invocation of a transaction all the integrity conditions that apply to entities to be accessed must be satisfied gs during a transaction g integrity conditions that apply to a set of entities called a transaction entity set TBS are potentially violated after a transaction all the integrity conditions that apply to its entities again are satisfied Lo The practices of human designers suggest that these assumptions are not necessary Indeed in design databases they cannot possibly be satis ed Specifically assumptions 1 and 3 cannot hold because of the incomplete integrity that exists for most of the life of a design database Full integrity need not apply to the TES of a transaction but only a specified set of integrity conditions Similarly the previous example shows that the result of a transaction is not full integrity but the alteration of specific integrity conditions In the example cited transaction 1 and 3 add integrity while in 2 integrity is subtracted within the scope of the DB being considered In the next section we define a revised de nition of transaction as well as other concepts leading to entityState transaction management 3 In the succeeding sections an example application of the scheme is show for single and multiple disciplinary design The example demonstrates the use of entitystate transaction management and outlines its information requirements 2 Transactions in Design Databases In order to provide a revised form to transactions in design databases the following definitions are given A database consists of data units called entities The entities of a database form a distinct set E e en Each transaction performs its processes on a TES which is a subset of E A TES has two parts a readset elR and a writeset eW The integrity conditions to be satis ed within a database are denoted as constraints Here we say a constraint is added to the database if the database satisfies the constraint else it is not part of the database Also note for later that each constraint can be accessed by the entities it refers to With this information a design transaction can be de ned as A collection of actions on a database that reads entity set eR and potentially writes into entity set eW The integrity of the design is defined by a set of constraints cu c c Prior to invocation the actions require that the set of integrity constraints 6quot be satis ed on the entities eR and eW During the transaction the integrity constraint set c quot on eR and eW may be violated After successful completion of the transaction integrity conditions on the eW may have been changed These are denoted by the sets c c39 where c A are the integrity constraints added by the transaction and c39A are those that are eliminated The three phases of a transaction before during and after and the corresponding constraint sets delimit 1 the scope of integrity required to start a transaction 2 the scope of integrity violations during a transaction and 3 the effect of the completion of a transaction after it is committed The revised definition of transaction manages the moment bytnornent integrity of each entity within the database using the concept called entity state SJ which describes the degree of integrity an entity satis es and can be represented by a set of integrity constraints in the database A database state then can be de ned as DS U 5 These definitions suggest that in a design database a transaction should incorporate entities together with related integrity constraints A destgn transaction then takes the form of T lelR i6W CW 6 id We refer to such a description as a Immactiort class Thus a transaction in a design database is an instance of a class This definition prow39des control of the scope of integrity as well as consistency when there are many active transactions in a database By defining transactions in this way the effect of any transaction on database integrity is fully specified This prmn39des several new capabilities Transactions have the potential to check if needed preconditions integrity conditions on entities hold Also rather than managing clashes on an entitybyentity basis concurrency management can determine if two potentially concurrent transactions on a single entity can execute at the same time without violating the necessary integrity conditions relied upon by the other 21 Concurrency Control Concurrency control is the task of avoiding inconsistent updates in a database when several concurrent transactions share entities Each transaction usually controlled by constraints and database states as in business databases maintains the consistency of a database when it is executed alone Thus a serial ordering of a set of transactions maintains consistency too But when transactions are executed concurrently the ordering of their constituent actions may not be serial but interleaved Most techniques developed for concurrency control are based on determining a serializable ordering such that the nal results of the execution of a set of transactions would be equivalent to a serial execution 1 The most accepted mechanism for concurrency control called the locking approach 4 is based on this model On the other hand in 6 it is shown that serialization is the optimal model only when minimum information is available for concurrency control The revised de nition of transaction incorporates integrity constraints as an integral pan and proposes a different concurrency control mechanism based on the entity state information 3 3 Design Examples Serwcz Nod mturmedlals Cnnnuetion we use Figure l Piping System In this section we provide design examples and the corresponding integrity constraints and transaction structures for two engineering subsystems The first example is the piping subsystem introduced earlier which is a common part in many engineering projects such as ship design process plant design building design etc The second example is a structural subsystem which is used to support the piping subsystem First each subsystem is considered separately and then they are integrated to demonstrate various interactions between these two subsystems The examples are similar to the ones given in 2 3 Entity state transaction management is applied to both of these subsystems in the follom39ng sections Note that we have simplified these subsystems and made some assumptions to remain in the context of transaction management 31 A Piping Subsystem Consider a simplified piping network For a complete design of this network we assume that the following set of transaction classes is necessary 1 A transaction class T that defines piping system topology It supports the definitions of source service connection and intermediate nodes and the edges that connect them 2 A ow generation transaction class T2 which calculates and assigns the maximum ow to each edge 3 A pipe sizing transaction class T3 that de nes each edge in the piping network as a pipe and assigns parameters such as diameter material etc according to the ow and edge information 4 A detail fitting design transaction class T that defines all ttings and computes the finished lengths of pipe elements 3 A cost analysis transaction class Tr that estimates the cost of plplng and the fittings Each of these transactions are macro transactions and can be represented as a combination of lower level transactions For example the first transaction that defines the piping network can be described by lower level transactions that define node locations modify node locations merge nodes define edges delete edges etc Gray 5 and Moss 7 discuss the problems associated with nested transactions Since such a structure is not dealt with in this paper for simplicity we consider them as members actions of the transaction class T1 See 3 for examples based on lowlevel transacrions The integrity constraints for the piping subsystem also can be identi ed These constraints are also combinations or union of lower level constraints For the example problem constraints are Li 39 quotpipe topology definedquot it quotpipe ows definedquot cJ quotpipe size parameters definedquot c quotpipe fittings and finished lengths definedquot ct quotpiping subsystem cost estimated Given the transaction descriptions and the integrity constraints the transaction classes for the piping subsystem can be formally defined as Tl nodes edgesRI nodes edgeslw c quot C 03quot Tz nodes edges owlR nodes edges tlowW cfla CIVDt Clv CVA Tr nodes edges owR pipesW c c39quot 3 Ct l EHquot T pipes ow fittingis39 pipes fittingsW c cg CH 63quot kt Cs39 T5 pipes fittingsR piping costW cf of cg c lla Cs39D Cs quot These class descriptions provide examples to the application of transactions in a design database context The readsets marked with quotquotquot indicate that some of the entities in their TES are conditional For example if T is applied to null database state it would not have any readset But if it is applied after T is executed it modifies the existing piping topology and therefore would include a readset Similarly ttings may or may not exist when transaction T is executed TI has no before conditions The transaction graph and database states for the piping system are shown in Figure 2 I P T DS0 null DS cf 0 Dsl 31 32 D8 Cf 0539 DS 939 0339 DS 6 Figure 2 Transaction Graph for Piping Subsystem 32 A Structural Subsystem In a similar way transaction classes for the structural subsystem which are used to pr0vide structural soundness to the piping system can be defined Again these are macro transactions ie compositions of lower level transactions 1 A transaction class To that defines the frame topology for the structural subsystem by identifying the locations of nodes and edges and centerlines 2 A transaction class T7 that defines the section modulus for individual members by identifying the moment and shear forces for the members 4 A member selection and sizing transaction class T3 that defines the member sizes A detailing transaction class T that provides joint designs A transaction class Tm that estimates the cost of the structural subsystem The integrity constraints for this subsystem can be defined 15 quotframe topology de ned quotmomentshears definedquot quotmember sizes definedquot quotjoints definedquot quotstructural cost estimatedquot Then for this subsystem the formal definition of transaction classes are Tquot nodes edgeis nodes edgeslw l8 cg lief all l edges nodeis edges nodes moment shearlw lCJ 6quot CV l Cg39ll l edges nodes moment shearlR memberle cf Cs Ct39l CVA members Jointis39 pipes jointslw 53 all ilCa l CWA memberis structural costW CQ H cwll Cm W V D80 2 DU D85 Cf Cs DS c5 cv39 DSo CC Ctr D57 Crol can Dsm cits Figure 3 Transaction Graph for Structural Subsystem Again the readsets marked with indicate that some entities in them are conditional For example if T is applied for the first time its readset would not contain joints but during an iteration it would include them Notice that in both examples if an earlier transaction is applied again after later ones it invalidates the later ones 33 Integration of Subsystems Integration of the two subsystems described in section 31 and 32 provides a common system that supports more complete management of design development Integration is necessary if the piping subsystem requires structural support Interaction between the two subsystems can be identified at the follong levels 1 between the piping network topology and the structural frame topology in terms of providing shared nodes to transfer loads between pipe parameters of piping subsystem and members selected for structural subsystem with regard to possible spatial con icts 3 use of the static and dynamic loads generated from the piping subsystem in the structural subsystem between piping fitting geometry and structural jotnts deSign With regard to possible spiitial con icts In order to incorporate these interactions the definitions of some transactions must be modified These are T ledges nodesR edges nodes moment shezirlw ci39l c3 CU C o WV Ti ledges nodes moments shearR menihersW cl CV39HE it d Cs39 Co39quot Ts nodes edges nodes edges C ic cl iuq39L imHA Ts requires that pipe sizes zind fittings must be defined to determine their loads on the structure T defines this transaction in one of several ways open to different policies It treats pipe topology as given and requires structures to route around them should con icts occur These revisions define the interdependeiieies between the piping Lind structural systems as shown in Figure 4 D80 DS2 DS DS DS DS r T M r W t 1quot xi r 39 Dsi tquot 0534 nay quotosq uost I I V J AK Transier gt SualIul DDOHOI Con icts Ean icts Loans v Dal LybsS yinhsiatnf f V LALL null 63 C2 DSo Ci CC uni Ln icy c3 DS c39 c3 ch C339v C4 DSK c1 Cn vcul CH cg D5o CH Cm 3995 D519 Cindi Figure 4 Integration of the piping and structural subsystems into an integrated model 4 Transaction Management for Engineering Design A transaction management scheme for a design database must support two important functions Integrity Management Concurrency Control The scheme for these functions can be developed as two separate capabilities or as a single combined one We first describe these functions in detail according to the revised transaction definition then define separate and joint schemes 41 Integrity Management An important advantage that the revised transaction definition introduces in the context of design databases is that it allows partial integrity With partial integrity the specific integrity conditions required of a transaction can be specified Consider the transactions defined for the piping subsystem When a transaction instance of class T1 is executed it updates the database such that integrity constraints denOted as 9 hold for the entities in its TES Simultaneously integrity constraints ch 0 c are violated due to the effects of the same transactions In the context of business databases such a situation indicates an inconsistent database state transformation and results in the rejection abort of the transaction But for design databases these are the required effects of TV Furthermore consider a request from a transaction instance of T3 Assume that the flows for the pipes in the TES of this transaction are not yet defined That is c does not hold for the entities If T is allowed to execute it would result in failure of the transaction due to insuf cient data These features of a transaction in a design database can be formalized by the following rules about integrity management 1 If the required cB conditions for a transaction class do not hold at any point in time no transactions of this class are allowed to execute 2 It is the task of a transaction to satisfy a set of integrity constraints 6quot so that other transactions which require them as ca are allowed to execute 3 A transaction may also violate a set of constraints c39A to indicate that other transactions should be invoked to satisfy them These rules suggest that integrity conditions defining partially consistent database states also define a partial ordering of transactions dictated by the constraints This ordering is in the form of precedence ordering with iteration The only possible ordering of transactions for the piping subsystem is shown in Figure 2 4 Transaction Management Implementation Scheme At this point the functions of integrity management and concurrency control can be integrated to form a transaction management scheme which responds to both functions In this way it provides more generality and resolves the problems arising from integrity maintenance and concurrency control The proposed method includes three phases of information exchange between a transaction and database These phases correspond to the integrity states of the entities of a transaction Each entity and its state information is denoted by the doublet ltesgt where e contains the entity name and the current value of the entity 5 contains the subset of all constraints cl c2 cu that refer to entity e Each design application would consist of a preprocessor for executing the before phase and a post processor for processing the after phase Each would have coded the constraint flags characterizing the conditions expected and resulting from the application that apply to each entity retrieved In the first phase a transaction which requires permission to execute checks whether its entities have been put into the proper state by preceding transactions Successfully initiated transactions communicate to each other through a traruacrion log The function of the transaction log is to identify current entity states ie status of the constraints for entities that are in the TES of transactions running at a given time Given the integrity constraint rules and the three phasestate communication the entitystate transaction management scheme is described as follows 1 When a new transaction is issued check its cB conditions for ltesgtl where ltesgt5 is the global fully committed database version If not all cB are satisfied reject the transaction id Check the transactions cE conditions for each ltesgtI where ltesgt represents the current status of the relevant constraints on entities in the transaction log ltesgt1 is the current information in the log registered for each currently active running transaction If all cE are not satisfied reject the transaction 3 If there is readset cR in the transaction then read ltesgt doublet for each entity in the TES to local ltesgtc That is ltesgtc lt ltesgt where ltesgtc is the local copy and ltesgt is the global database version Note that this can be either an assignment or a message followed by an assignment 4 Update all cB to cD in ltesgt so that a new transaction which conflicts with the current transaction will be rejected For this register the transaction into the log ltesgtI lt cD The log entry has the effect of communicating the transaction to concurrent transactions in the system This step is the end of the before phase and indicates an initiating transaction 3 Execute the actions of the transaction 6 Search the log for all transactions that have joint entities and whose lc 3 conditions could be affected by the current transaction s cA conditions after the current transaction commits Send messages to such concurrent transactions for negotiating an abort The criteria for negotiation can be precedence relations between the transactions This is the final step of the during phase 7 If not aborted then upgrade all cD to cquot in all ltesgtl This step indicates the end of after phase 8 Transmit ltesgtl to the database by ltesgtl lt ltesgtl to denote termination of this transaction in the transaction log Search the log for all previous transactions whose c conditions could be affected by the current transaction Flag these for review This step is the end of commit 9 Database should pass on the new values to those transactions in the log that share entities with the committed transaction The proposed scheme supports applicationlevel consistency rather than serial consistency available in traditional database systems and as a result there is a certain cost associated with it 3 The cost of this scheme is due to 1 Defining the relevant states of an entity is terms of CH fell lcl and adding these states to a transaction class 2 Preanalysrs of a transaction Instance using c 3 Communication between a running transaction and the log for updating constraints 4 Communication between concurrent transactions to check the status of joint entities before committing The cost assoctated with this technique seems unavoidable since the integrity and consistency of an engineering database must be maintained either manually or automatically Up to now alternative management schemes integrating both integrity maintenance and concurrency control have not existed However management of integrity is a major effort in engineering design and a common cause of failures 43 Application of Transaction Management Scheme In the combined database that incorporates both piping and structural subsystems and managed by entitystate transaction management the communication provided by database management is ery helpful Suppose that the structural engineer has defined the structural topology using T and is about the analyze the elements to determine their moment and shear using T This transaction will not run in the integrated formulation until the piping topology T flow To parameters Ti and fittings Tl have been correctly defined Similarly suppose after the structural sizing the mechanical engineer finds that the layout of the piping must be altered for example because some new mechanical equipment has been added to the design Both the T2 and T piping transactions and the TV structural transaction must be rerun These results wall occur naturally as a result of entity state transaction management Because each of the transactions in this example have been defined to correspond closely to current forms of engineering application software they each operate on all pipes or gm structural members and no sharing of structural elements across multiple concurrent structural analysis is allowed The method described here can be extended to partial analysis with the addition of nested transactions Any iteration of an early application reverts all entities to an earlier state The following example shows how communication between transactions work Suppose a T transaction is currently active It leaves in the local log a record indicating its existence and its cD constraints Later a T transaction is iterated it was run and committed once earlier and thus c is set At the time of its re initiation its preconditions are satis ed and it begins If it terminates with an abort it has no effect But if it completes before T then prior to committing it searches the log and identifies that its ch state con icts with a current transaction s CV This indicates a possible change in values of the entities referenced in T7 Based on Step 6 of the management scheme the iterated version of T3 would communicate its proposed change to T7 where it is expected that the two designers would review the effects prior to the commit of T and mutually agree on the form of the change If T was iterated and completed after T7 was committed then T would invalidate C Step 8 would ag T7 as possibly invalidated and needing review Each transaction only invalidates its immediate successor It is the responsibility of step 8 of the transaction management scheme to flag successor transactions or chains of successors As policies several variations of 8 could be applied All possibly invalidated transactions could be identi ed earlier in step 6 and negotiated before the commit in order to evaluate the cost of the change Also one update change may propagate a review to a succeeding transaction and the succeeding transactions could propagate to others in a cascaded chain The complete chain could be flagged to be reviewed if desired Such policies could vary during design so that early in design changes would not be preevaluated or chains of changes propagated while late in design they both would be 5 Conclusion Database systems that support engineering design are complex in nature and require special techniques to model both data and operations The scheme developed for transaction management and applied to design examples in this paper explicitly deals with the management of operations It also presents implications for the database schema design The doublet ltesgt which provides state de nitions for database entities implies the integrated definition of entities together with their possible states The transaction class de nition on the other hand incorporates the operations with this doublet This representation is consistent and supportive of objectoriented database systems where a class encapsulates entities with the routines that manipulate them Thus it can be concluded that the scope and the domain of a transaction class define the level of abstraction it applies to Entity state management is not a constraint propagation scheme that can determine if changes must be made to specific variables in some other entities It is a transacnon management scheme that provides integrity communication between diverse serial and concurrent applications It does Suggest however how constraint management might be developed in such application areas In this paper it is shown that the application of the revised transaction definition provides generality and exibility for the management of design DFOJCCIS It not only allows partial integrity at database states but exemplifies hOW integrity is added or eliminated by transactions in a database It leads to a scheme where it is possible to represent and manage precedence ordering iteration concurrency control amount of integrity satisfied for possible transactions in a design project Note This paper is an adaptation of quotTransaction Management in Engineering Databasesquot by A Kutay and C Eastman Proceedings 0f1983 SIGMOD Conference ACM pp 7380 Acknowledgement This work was partially supported by a National Science Foundation grant number DDM8915665 References 1 Bernstein PA Shipman DW Wong WS Formal aspects of serializability in database Concurrency control IEEE Trans Software Eng SE53 May 1979 2 Eastman CM Database Facilities for Engineering Design Proc IEEE 6910 October 1981


Buy Material

Are you sure you want to buy this material for

25 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


You're already Subscribed!

Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'

Why people love StudySoup

Bentley McCaw University of Florida

"I was shooting for a perfect 4.0 GPA this semester. Having StudySoup as a study aid was critical to helping me achieve my goal...and I nailed it!"

Anthony Lee UC Santa Barbara

"I bought an awesome study guide, which helped me get an A in my Math 34B class this quarter!"

Steve Martinelli UC Los Angeles

"There's no way I would have passed my Organic Chemistry class this semester without the notes and study guides I got from StudySoup."

Parker Thompson 500 Startups

"It's a great way for students to improve their educational experience and it seemed like a product that everybody wants, so all the people participating are winning."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.