A Review of Database Schemas

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "A Review of Database Schemas"

Transcription

1 A Review of Database Schemas Introduction The purpose of this note is to review the traditional set of schemas used in databases, particularly as regards how the conceptual schemas affect the design of the storage of relations. It is sometimes considered that each base relation must be stored as is, i.e. each logical tuple must be mapped directly to a corresponding physical record. This is not so, and some relational DBMS products already provide some facilities to improve on this. The results of the review lead to a rationalisation of the database schema architecture. Physical Data Independence The contents of a base relation 1 are physically stored. However the whole purpose of physical data independence is that the data can be stored in any desirable way. It does not need to be stored as the physical equivalent of a table. Any file or data structure or combination thereof can be used and manipulated, so long as the stored data appears to the user as the logical abstraction of a relation. Another consequence of physical data independence is that a base relation could be stored in terms of other relations. There are three possibilities :- 1. A relation is fragmented into several smaller relations, and the relational fragments are physically stored instead. 2. A relation is merged with other relations into a bigger relation, which is physically stored instead. 3. Some combination of the above two methods. Whenever one needs the original relation, its contents are created from the contents of the relevant stored relations. The first possible method is well developed for the design of distributed databases. A relation is fragmented horizontally or vertically. Horizontal fragmentation uses restrictions and/or semi-joins to split the original relation into several sets of tuples (i.e. several relations), such that they can be unioned together to re-create the original relation. Vertical fragmentation uses projection to split the original relation into several sets of attributes (i.e. several relations), such that they can be naturally joined together to re-create the original relation. A fragment can itself be fragmented, either horizontally or vertically, so that the fragmentation can be continued recursively till fragments suitable for storage are obtained. There are design rules governing how the fragmentation should be specified, in order to ensure that the original relations can be re-created from the fragments and to ensure the fragments have desirable characteristics; these design rules are not further considered here. 1 All the named relations in a database, whether they be base relations, views or stored relations (as defined later) are actually relational variables, since they permanently exist as relations and their values are allowed to vary during their lifetimes. However traditional terminology is still used here, even though it doesn t always make clear that the relations are variables. Page 1 of 15

2 A variation of the first method is also used for single-site databases by some DBMSs - e.g. Oracle and RdB - in that relations can be split horizontally into sub-relations that are separately stored. However the splitting is not done via algebra or its SQL equivalent, but by syntax which is especially developed as part of the SQL storage control facilities. This is in conformance with the principles of physical data independence, in that it makes the fragmentation a purely storage issue and hides it from the SQL query user. With the second method, relations can be merged together horizontally or vertically. A horizontal merger is derived by unioning together compatible relations, such that the original relations can be re-created via restrictions on the merged result. A vertical merger is derived by a natural join of appropriate relations, such that the original relations can be re-created via projections of the merger. Mergers can themselves be merged together, either horizontally or vertically, so that the merging can be continued recursively till a merger suitable for storage is obtained. Design rules corresponding to the fragmentation rules apply here too. Traditionally larger mergers are not considered so attractive for storage, as in general it is harder to access a desired data item from a larger set of data than it is from a smaller set. Nevertheless vertical mergers can be beneficial. If a query involves joining relations, and if the relation that is the result of the join were to be physically stored instead by means of vertical mergers using the same join properties as in the query, it would remove the need for the physical join operation to answer the query; and joins are potentially time-consuming. Despite this, only the Caché DBMS uses vertical mergers; it stores the tables representing hypercubes as a single joined table. (It also uses a system of coding the data to compress table sizes). Some DBMSs, e.g. Oracle, do allow clustering whereby data from two relations to be joined is stored so that the data of tuples that would be merged in the result is held in the same physical block. This is a halfway house that uses just physical design ideas rather than any logical design ideas. The de-normalisation of some Conceptual schema designs often merges together relations in the original Conceptual schema. The motivation is usually to improve query performance by merging relations that have to be joined together in commonly occurring queries. However de-normalisation can lead to confusion and maintenance problems in the long run because the design of the Conceptual schema no longer reflects the inherent nature and structure of the data in the database. Queries and performance must inevitably be based on the inherent nature and structure of the data, since nothing else makes sense. However, there have been research efforts to store vertical mergers in order to improve performance. For example, Schkolnik and Sorenson have investigated storing denormalised relations as materialised joins in addition to the normalised relations (see [5]). Scholl, Paul, and Schek have investigated storing nested relations that are the logical equivalent of joins (see [6]). Thus it would be helpful if database designers could separate out the logical relations that represent the inherent nature and structure of the data from the logical relations needed to optimise performance, particularly as performance optima can change much more frequently than the inherent nature and structure of the data. Page 2 of 15

3 The author has not come across any instances of the third method, combining both merging and fragmentation, but logically it is possible. If one is alive to the possibility, then opportunities for its use may emerge. (If merging is never formally used, then naturally it cannot be combined with fragmentation). It becomes convenient to distinguish between base relations and stored relations. A stored relation is one whose data contents are physically stored in files such that there is always a direct link between the stored relation and its physical storage, even if the physical storage is changed (possibly radically and/or frequently) to optimise physical performance. A base relation is also one whose data contents are physically stored, but the storage may be direct - i.e. the base relation is also a stored relation - or it may be indirect in that it may be mapped onto other relation(s), possibly recursively, culminating in stored relation(s). Note that from a technical perspective updating an underlying stored relation(s) in order to update a base relation, is in principle no different to updating an underlying base relation(s) in order to update a view. Consider the relations : R1 (A, B, C) R2 (A, D, E) REL (A, B, C, D, E) where A denotes an attribute that is a candidate key. Furthermore, suppose : REL R1 Join[ A ] R2 R1 REL Project[ A, B, C ] R2 REL Project[ A, D, E ] R1 R2 REL Then is it possible to deduce unequivocally that R1 and R2 are two views derived from the base relation REL by projection, or that REL is a stored relation created by a natural join of the two base relations R1 and R2 and used to store their data? The answer is that it is not, because the two cases are logically equivalent. In fact it is generally true that when a relation(s) is derived from another relation(s) via algebraic operations, the derivation or mapping between the two relation(s) is independent of whether a view(s) is being derived from a base relation(s) or a base relation(s) is being derived from a stored relation(s). The differences between the two situations are that : 1. they have different purposes; Page 3 of 15

4 2. different approaches are used to defining views and stored relations, since both are derived from base relations but whereas base relations underlie views, stored relations underlie base relations; 3. stored relations should obey design criteria which views are not constrained to obey. However none of these affect the logical nature of the mappings. Date and McGoveran have a developed a method by which all logically-updateable views may be updated by updating the relations from which the views are derived : see ref. [3]. This method is very general and wide-ranging and so does not have the limitations of conventional ad hoc view updating methods. Consequently the same method can be used for updating base relations whose data is held in stored relations. Ref. [4] explicitly refers to this. In fact Date and McGoveran s method is far more general than the horizontal and vertical partitioning described above. The only constraint is that updates must be logically possible. An example of where an update is impossible, is an attempt to insert a tuple into a view formed by a GroupBy operation where the view includes an attribute formed by aggregation. The insert is impossible since there is no general way to determine which set of tuples, from all the different possible sets of tuples that are logically possible, is the set to be inserted into the underlying relation in order to create the inserted tuple in the view. As the fragmentation and merging methods do not incur this limitation, it does not cause a problem for them. A final bonus from distinguishing between stored and base relations is that a query optimiser that uses algebraic transformations can use these transformations in going from base to stored relations. Thus a greater part of the optimisation process can be done via algebraic transformations. (This was a major motivation for Scholl, Paul, and Schek s work). The extra optimisation opportunity costs nothing since it merely uses the existing algebraic transformation part of the optimiser. Other things being equal, the part of the optimiser that deals with physical storage can now be simplified as the physical storage options can now be simplified without loss of optimisation. Database Schemas The fact that fragment relations and merged relations are not intended to be seen by the users, nor reflect the inherent nature or structure of the data, suggests that they be viewed in terms of another schema. In order to pursue this idea, first consider existing database architectures. The traditional database schema architecture, based on the ANSI/SPARC standard, is the 3-layer one : 1. External (or Sub-) schemas. 2. Conceptual (or Logical) schema. 3. Internal (or Physical) schema. Where fragment relations have been employed in distributed databases, the traditional schema architecture has been expanded (for example, see ref. [1]) to encompass the following : 1. Global External (or Sub-) schemas. 2. Global Conceptual (or Logical) schema. Page 4 of 15

5 3. (Global) Fragmentation schema. 4. (Global) Allocation (or Replication) schema. 5. Local Conceptual (or Logical) schemas. 6. Local Internal (or Physical) schemas. Comparing the traditional and distributed cases, schemas 1 and 2 are the same in both of the cases. The distributed schema 6 is the traditional schema 3 at each node. The distributed schema 5 is the equivalent of the traditional schema 2 at each node. The distributed schemas 3 and 4 are new. The Fragmentation schema is the schema wherein is specified what fragments are to be used to store the data of base relations, and how the base relations relate to their fragments. Thus it is proposed that : the Fragmentation schema become generalised and allow both fragmentation and merging; it is called the Storage schema to reflect the change; it is used by all databases, whether single-site or distributed. Since some large single-site databases may also wish to store multiple copies of some relations, in order to improve resilience and/or query performance, one may as well also keep the Allocation schema as standard for all databases. In which case, there would be several Local Conceptual schemas, one for each separately stored part of the database, where typically each part is stored on a separate storage device. This could help to manage the stored data. Where a single-site database has no multiple copies of relations, the Allocation schema would trivially be a one-to-one mapping of the Storage schema to the one and only Local Conceptual schema; i.e. the Storage schema would be identical to the Local Conceptual schema. Consequently one would expect the DBMS to automatically optimise this situation so that it caused no additional overhead. Even in this situation, if the database is large and complicated, it might make the database easier to manage if there were several Local Conceptual schemas and the Allocation schema mapped different portions of the Storage schema to each Local Conceptual schema. These Local Conceptual schemas would each be a physically coherent portion of the database that was best managed as a whole. From a design point of view, adding the Storage schema provides a pleasing symmetry for the top three schema levels of the database. The central schema of the three, the Conceptual schema, consists of all the base relations in the database. These should be designed to the best possible logical design standards to reflect the inherent structure and characteristics of the data, i.e. be a canonical model of the real-world data. They would be designed using normalisation and without regard to application or performance considerations. The External schemas in the layer above would be derived from it, and each would reflect what was best for the application(s) that it supported. The Storage schema in the layer below would also be derived from it, but would reflect what was most desirable from a performance point of view. It is conjectured that the lack of the Storage schema in the past has encouraged database designers to incorporate the physical design possibilities for each relation in the Conceptual schema, rather than separate out the logical and physical aspects of the relational design. Also that this lack has led to the dilemma of de-normalisation : should Conceptual schema relations be de-normalised for performance or maintained Page 5 of 15

6 as a valid logical design to support the long term maintenance of the database? However the ability to fragment and/or merge relations allows for a lot more possibilities for designing stored relations than merely de-normalising. The introduction of the Storage schema could remove all such impediments to thought. As the horizontal fragmentation storage options of many DBMSs (e.g. Oracle and RdB) indicate, there is a perceived need to create storage fragments. Creating the new schema allows this to be done openly, with the full power of relational algebra, or its SQL equivalent, instead of having to re-invent parts of the algebra/sql under cover of the storage options; and yet by being in a separate schema, it maintains physical data independence, which is so important. It also gives full reign to consider other storage designs that go beyond just simple horizontal fragmentation. It is also possible to surmise that the lack of the Storage schema is in turn due to the lack of a general-purpose view updating mechanism, such as that proposed by Date and McGoveran. It is obvious that a general-purpose Storage schema is infeasible without such a mechanism. Yet hitherto no such mechanism has been implemented in any DBMS. View updating is limited and ad hoc in SQL. In turn this is due to the nature of SQL which either does not implement relational principles fully or implements them anomalously. Were Date and McGoveran s view updating mechanism to be found to be unsound or flawed, then it could not be used for even a pure relational database. Either another mechanism (if this were logically possible) or a workaround would be needed, at least for the algebraic operators involved in horizontal and vertical fragmentation. Otherwise there would still be no support for the separation of the logical and physical design concerns, and for the distributed case no support for the geographical design concerns. Appraisal of the Schemas Consideration of the various schemas reveals that schemas of relations fall into two categories : 1. sets of relations, 2. sets of mappings between relations. Let us consider each category of schemas in turn. Schemas that are Sets of Relations The schemas containing sets of relations are the :- Subschemas, the Conceptual schema, the Storage schema, local Storage schemas. Note that the use of external and internal as schema names has been abandoned for simplicity, as has the use of the adjective Global. These schemas represent a four-layered architecture. Hence they can be portrayed as follows :- Page 6 of 15

7 Subschemas :- Conceptual Schema :- Storage Schema :- Local Storage Schemas :- View relations appear only in Subschemas, although Subschemas may also include base relations. The Conceptual schema contains only base relations. The Storage schema and the Local Storage schemas contain only stored relations, any of which may also be a base relation. It would be possible to have a Subschema that contains all the Conceptual schema s base relations plus some views. (The terminology of subschema here - with its normal meaning of subset of the Conceptual schema - would still be appropriate, as a subset does not have to be a proper subset; it can be equal to the other set. Even the additional views are not holding additional information, merely additionally displaying existing information in more convenient ways). To clarify this architecture, consider a small example that just illustrates the architecture s top three layers. Let V View B Base Relation S Stored relation The following represents a small database :- Subschemas :- V 1 B 1 B 3 V 2 B 2 V 3 Conceptual Schema :- B 1 B 2 B 3 B 4 Storage Schema :- S 1 S 2 S 3 B 3 B 4 Page 7 of 15

8 This shows that some of the base relations appear in Subschemas and the Storage schema as well as (of course) in the Conceptual schema. If these schemas were to be portrayed using a Venn diagram (since they are all sets of relations), they would be shown as :- V 1 V 2 V 3 B 1 B 2 B 3 B 4 S 1 S 2 S 3 This example raises the following question. When a view is created, in what schema is it immediately held? One does not want the inconvenience of having to assign it to a Subschema as part of the view creation operation. The proposal here is that there is a system Subschema (called Views ) to which any view is immediately and automatically assigned. Views can then be moved or copied from there to other Subschemas as and when desired. Still this architecture, because it refers only to relations, omits the actual physical storage structures that hold the relational data, the files, indexes, etc. A Local Physical schema is needed for each Local Storage schema, where the Local Physical schema is the set of all physical objects - files, indexes, etc. - used to actually store the data of the Local Storage schema s relations. Thus another architectural layer, consisting of the Local Physical schemas, should be added on to the bottom of the architecture as follows :- Page 8 of 15

9 Subschemas :- Conceptual Schema :- Storage Schema :- Local Storage Schemas :- Local Physical Schemas :- Note that the above architecture assumes a distributed database, or a centralised database where it is useful to have local schemas for each of a set of storage devices attached to the single computer. In the case of a simple centralised database where the Storage schema is not be divided up between several local Storage schemas, the architecture could be simplified to :- Subschemas :- Conceptual Schema :- Storage Schema :- Physical Schema :- These architectures give rise to some identities that are always true, and which could be useful in managing the database :- Page 9 of 15

10 Dist[ Union ] Set-of-Subschemas-except-Views Diff Conceptual-schema Views-Subschema (N.B. Dist[ Union ] means Distributed Union 2 ). Subschema-X Diff Conceptual-schema Set-of-Views-in-X Conceptual-schema Diff Subschema-X Set-of-Base-Relations-not-in-X Conceptual-schema Diff Storage-schema Set-of-Base-Relations-not-directlystored Storage-schema Diff Conceptual-schema Set-of-all-Storage-only-Relations The schema architecture for a distributed database still only has 5 layers compared to the usual 6. This is because the Allocation schema, which is a set of mappings between relations, is missing. Schemas that are Sets of Mappings Adding the Allocation schema yields the following architecture :- Subschemas :- Conceptual Schema :- Storage Schema :- Allocation Schema :- Local Storage Schemas :- Local Physical Schemas :- 2 These identities assume a mathematical notation. The operators (including the comparators) could be implemented in a relational algebra language, e.g. RAQUEL. Page 10 of 15

11 It is readily seen that besides the Allocation schema, other sets of mappings between the layers of the architecture must exist in order to link adjacent layers, and that the database designer needs to be aware of and use these mappings. Two other mapping schemas are :- 1. the View schema (the mappings that define the views in terms of other relations); 1. the Equivalence schema (the mappings that define base relations in terms of stored relations). They are like the Allocation schema in that they are mappings between relations, but they differ in that they arise automatically from the definitions of views and fragments/mergers, whereas the Allocation schema mappings must be entered manually because their choice is part of the design of the database. Displayed pictorially, a small View schema might look as follows :- V1 V2 B1 B2 B3 Three mappings are used to define two views, because one view is defined in terms of two relations but the other only in terms of one relation. The mappings correspond to the definition of the views. Naturally the actual algebraic definitions of the views, or SQL equivalents, also need to be stored in the schema. Similarly a small Equivalence schema might look like :- B1 B2 B3 S1 S2 S3 Here one base relation is stored in two (fragment) relations, while two other base relations are stored in one (merged) relation. Again the mappings correspond to the definitions, whose algebraic/sql expression needs to be stored. Another set of mappings is from relations to their physical storage arrangements. These are called Local Conversion schemas. Their purpose is to define how each stored relation s data is actually stored in terms of the physical objects. There will need to be a Local Conversion schema to map between each Local Storage schema and each corresponding Local Physical schema. Because Local Conversion schemas do not deal purely with the relational model, they could be handled differently by different DBMSs. In particular, it could be that Local Physical schemas could be derived automatically from Local Conversion schemas. Page 11 of 15

12 Thus there are 4 kinds of mapping schema. If each kind is made a layer of the architecture in the same way that the Allocation schema is, then one ends up with a 9- layer architecture. It can be portrayed as follows :- Subschemas :- View Schema :- Conceptual Schema :- Equivalence Schema :- Storage Schema :- Allocation Schema :- Local Storage Schemas :- Local Conversion Schemas :- Local Physical Schemas :- Again, a simple centralised database could have an architecture that was simplified in the obvious way. Page 12 of 15

13 Although 9 layers may seem excessively complex, note that in reality they are all there anyway. Nothing new has been introduced. The only change is to make explicit what was previously implicit. Together the 9 layers provide a comprehensive conceptual structure for the database so that its designers can better envisage what they need to design, and better monitor the progress of their design; it also supports the amendment of the design of current databases when evolutionary changes need to be made. All 9 components are necessary. However a proper DBMS should be able to automate the production of much of the schemas in ways already indicated, thereby giving the database designer the maximum support with the minimum of effort. A proper DBMS should also provide the tools - via its data dictionary and/or user friendly commands - to help the designer use all the schemas effectively. There are some further identities that are always true, and which could be useful in managing the database :- Dist[ Union ] Set-of-Subschemas-except-Views Dom[ View ] Union Conceptual-schema (N.B. Dom[ View ] is the domain of the View schema mapping). Conceptual-schema Diff Dom[ Equivalence ] Union Storage-schema Set-of-all-Stored-Relations Ran[ Allocation ] Dist[ Union ] Local-Storage-schemas (N.B. Ran[ Allocation ] is the range of the Allocation schema mapping). All the identities take advantage of the fact that the set and mapping schemas conform to the principles of traditional mathematical sets and relations respectively; i.e. a set schema is a set of items (in this case a set of database relations) and a mapping schema is a set of mappings (in this case between database relations). Conclusion The above is an attempt to provide a rational framework in which the study of the design of relational databases could be carried out. It tries to rise above the peculiarities of any individual relational DBMS so that it can provide a basis not only for a range of current relational DBMSs (so that they can be compared and one can easily transfer from working with one to working with another) but also for future developments in relational DBMSs (so that new developments can be evaluated using rational criteria). The framework is based on a rationalisation of the current standard approaches to centralised and distributed databases, and can be used for both. The proposals can be summarised as :- 1. The standard database schema architecture should be expanded to include a Storage schema. This will facilitate the design of the best storage mechanisms while encouraging the Conceptual schema to be a design based purely on the inherent nature and structure of the data. This overcomes the dilemma which many database designers face as to which of these two choices to go for. Page 13 of 15

14 2. To achieve this, stored relations should be differentiated from base relations. The latter may be stored indirectly via mappings to stored relations, while the former are always stored directly. 3. Date and McGoveran s method for view updating can and should also be applied for the updating of base relations whose data are held indirectly in stored relations. If this method is inadequate, then some logically equivalent means to the same end must be found to achieve the same end. 4. Any reasonable relational DBMS has an optimiser which uses the technique of algebraic transformations as part of its method of its optimisation strategy. Such an optimiser will be able to use the storage definitions of base relations for additional optimisation. Furthermore, it will not require an extension of the optimiser to accomplish this - the extra optimisation comes for free - since the extra optimisation can be done by algebraic transformations. 5. It may be useful to make an Allocation schema a standard part of the database architecture, since centralised databases may also wish to have more than one copy of some data. However this does imply that to avoid being a burden in the simple centralised case, one-to-one mappings should appear as the default, and the DBMS should automatically note one-to-one mappings and not create any overhead for them. 6. It is worthwhile to rationalise the schema architecture, which should be built from two kinds of schema : schemas that are sets of relations and schemas that are sets of mappings between relations. A mapping schema forms a layer of the architecture that appears between two architectural layers formed from sets of relations. The mappings show how the relations above and below in the architecture relate to each other. Together they provide much better support for designing and maintaining the database. 7. A distributed database would have 5 set schemas with 4 mapping schemas sandwiched between them, while a simple centralised database could reduce this to 4 set schemas with 3 mapping schemas. 8. A DBMS should support the database designer by automating as much as possible of schema creation and by providing easy ways to inspect the contents of schemas. It should also be able to exploit a variety of identities between schemas. References [1] Distributed Databases : Principles and Systems. S. Ceri & G. Pelagatti (McGraw-Hill Computer Science Series, 1985). [2] Private communication from Hugh Darwen, [3] An Introduction to Database Systems. C. J. Date (Addison-Wesley, 2000), ch. 9, section 4. [4] An Introduction to Database Systems. C. J. Date (Addison-Wesley, 2000), ch. 23, page 698. (David McGoveran was the original author of this chapter). [5] The Effects of Denormalisation on Database Performance. M. Schkolnik & P.Sorenson (Res. Rep. RJ3082(38128), IBM Research Lab, San Jose, 1981). Page 14 of 15

15 [6] Supporting Flat Relations by a Nested Relational Kernel. M. H. Scholl, H. B. Paul, & H. J. Schek (Proceedings of 13 th VLDB Conference, Brighton, 1987). Page 15 of 15

The Import & Export of Data from a Database

The Import & Export of Data from a Database The Import & Export of Data from a Database Introduction The aim of these notes is to investigate a conceptually simple model for importing and exporting data into and out of an object-relational database,

More information

Schemas Supporting Physical Data Storage

Schemas Supporting Physical Data Storage s Supporting Data Storage 21 st January 2014 (30 th March 2001) s Supporting Physical Data Storage Introduction A RAQUEL DB is made up of a DB, which itself consists of a set of schemas. These schemas

More information

IT2304: Database Systems 1 (DBS 1)

IT2304: Database Systems 1 (DBS 1) : Database Systems 1 (DBS 1) (Compulsory) 1. OUTLINE OF SYLLABUS Topic Minimum number of hours Introduction to DBMS 07 Relational Data Model 03 Data manipulation using Relational Algebra 06 Data manipulation

More information

Denormalisation (But not hacking it)

Denormalisation (But not hacking it) Denormalisation (But not hacking it) Denormalisation: Why, What, and How? Rodgers Oracle Performance Tuning Corrigan/Gurry Ch. 5, p69 Stephen Mc Kearney, 2001. 1 Overview Purpose of normalisation Methods

More information

IT2305 Database Systems I (Compulsory)

IT2305 Database Systems I (Compulsory) Database Systems I (Compulsory) INTRODUCTION This is one of the 4 modules designed for Semester 2 of Bachelor of Information Technology Degree program. CREDITS: 04 LEARNING OUTCOMES On completion of this

More information

Integrating Pattern Mining in Relational Databases

Integrating Pattern Mining in Relational Databases Integrating Pattern Mining in Relational Databases Toon Calders, Bart Goethals, and Adriana Prado University of Antwerp, Belgium {toon.calders, bart.goethals, adriana.prado}@ua.ac.be Abstract. Almost a

More information

Distributed Databases. Concepts. Why distributed databases? Distributed Databases Basic Concepts

Distributed Databases. Concepts. Why distributed databases? Distributed Databases Basic Concepts Distributed Databases Basic Concepts Distributed Databases Concepts. Advantages and disadvantages of distributed databases. Functions and architecture for a DDBMS. Distributed database design. Levels of

More information

2. Basic Relational Data Model

2. Basic Relational Data Model 2. Basic Relational Data Model 2.1 Introduction Basic concepts of information models, their realisation in databases comprising data objects and object relationships, and their management by DBMS s that

More information

2 Associating Facts with Time

2 Associating Facts with Time TEMPORAL DATABASES Richard Thomas Snodgrass A temporal database (see Temporal Database) contains time-varying data. Time is an important aspect of all real-world phenomena. Events occur at specific points

More information

Chapter 6: Physical Database Design and Performance. Database Development Process. Physical Design Process. Physical Database Design

Chapter 6: Physical Database Design and Performance. Database Development Process. Physical Design Process. Physical Database Design Chapter 6: Physical Database Design and Performance Modern Database Management 6 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden Robert C. Nickerson ISYS 464 Spring 2003 Topic 23 Database

More information

B.Com(Computers) II Year DATABASE MANAGEMENT SYSTEM UNIT- V

B.Com(Computers) II Year DATABASE MANAGEMENT SYSTEM UNIT- V B.Com(Computers) II Year DATABASE MANAGEMENT SYSTEM UNIT- V 1 1) What is Distributed Database? A) A database that is distributed among a network of geographically separated locations. A distributed database

More information

Application of XML Tools for Enterprise-Wide RBAC Implementation Tasks

Application of XML Tools for Enterprise-Wide RBAC Implementation Tasks Application of XML Tools for Enterprise-Wide RBAC Implementation Tasks Ramaswamy Chandramouli National Institute of Standards and Technology Gaithersburg, MD 20899,USA 001-301-975-5013 chandramouli@nist.gov

More information

1 File Processing Systems

1 File Processing Systems COMP 378 Database Systems Notes for Chapter 1 of Database System Concepts Introduction A database management system (DBMS) is a collection of data and an integrated set of programs that access that data.

More information

Physical Design in OODBMS

Physical Design in OODBMS 1 Physical Design in OODBMS Dieter Gluche and Marc H. Scholl University of Konstanz Department of Mathematics and Computer Science P.O.Box 5560/D188, D-78434 Konstanz, Germany E-mail: {Dieter.Gluche, Marc.Scholl}@Uni-Konstanz.de

More information

[Refer Slide Time: 05:10]

[Refer Slide Time: 05:10] Principles of Programming Languages Prof: S. Arun Kumar Department of Computer Science and Engineering Indian Institute of Technology Delhi Lecture no 7 Lecture Title: Syntactic Classes Welcome to lecture

More information

Comparing Microsoft SQL Server 2005 Replication and DataXtend Remote Edition for Mobile and Distributed Applications

Comparing Microsoft SQL Server 2005 Replication and DataXtend Remote Edition for Mobile and Distributed Applications Comparing Microsoft SQL Server 2005 Replication and DataXtend Remote Edition for Mobile and Distributed Applications White Paper Table of Contents Overview...3 Replication Types Supported...3 Set-up &

More information

www.gr8ambitionz.com

www.gr8ambitionz.com Data Base Management Systems (DBMS) Study Material (Objective Type questions with Answers) Shared by Akhil Arora Powered by www. your A to Z competitive exam guide Database Objective type questions Q.1

More information

Physical Database Design and Tuning

Physical Database Design and Tuning Chapter 20 Physical Database Design and Tuning Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1. Physical Database Design in Relational Databases (1) Factors that Influence

More information

Objectives. Distributed Databases and Client/Server Architecture. Distributed Database. Data Fragmentation

Objectives. Distributed Databases and Client/Server Architecture. Distributed Database. Data Fragmentation Objectives Distributed Databases and Client/Server Architecture IT354 @ Peter Lo 2005 1 Understand the advantages and disadvantages of distributed databases Know the design issues involved in distributed

More information

3. Relational Model and Relational Algebra

3. Relational Model and Relational Algebra ECS-165A WQ 11 36 3. Relational Model and Relational Algebra Contents Fundamental Concepts of the Relational Model Integrity Constraints Translation ER schema Relational Database Schema Relational Algebra

More information

Database design theory, Part I

Database design theory, Part I Database design theory, Part I Functional dependencies Introduction As we saw in the last segment, designing a good database is a non trivial matter. The E/R model gives a useful rapid prototyping tool,

More information

Chapter 5 More SQL: Complex Queries, Triggers, Views, and Schema Modification

Chapter 5 More SQL: Complex Queries, Triggers, Views, and Schema Modification Chapter 5 More SQL: Complex Queries, Triggers, Views, and Schema Modification Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 5 Outline More Complex SQL Retrieval Queries

More information

1. Physical Database Design in Relational Databases (1)

1. Physical Database Design in Relational Databases (1) Chapter 20 Physical Database Design and Tuning Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1. Physical Database Design in Relational Databases (1) Factors that Influence

More information

1. INTRODUCTION TO RDBMS

1. INTRODUCTION TO RDBMS Oracle For Beginners Page: 1 1. INTRODUCTION TO RDBMS What is DBMS? Data Models Relational database management system (RDBMS) Relational Algebra Structured query language (SQL) What Is DBMS? Data is one

More information

C# Cname Ccity.. P1# Date1 Qnt1 P2# Date2 P9# Date9 1 Codd London.. 1 21.01 20 2 23.01 2 Martin Paris.. 1 26.10 25 3 Deen London.. 2 29.

C# Cname Ccity.. P1# Date1 Qnt1 P2# Date2 P9# Date9 1 Codd London.. 1 21.01 20 2 23.01 2 Martin Paris.. 1 26.10 25 3 Deen London.. 2 29. 4. Normalisation 4.1 Introduction Suppose we are now given the task of designing and creating a database. How do we produce a good design? What relations should we have in the database? What attributes

More information

COMHAIRLE NÁISIÚNTA NA NATIONAL COUNCIL FOR VOCATIONAL AWARDS PILOT. Consultative Draft Module Descriptor. Relational Database

COMHAIRLE NÁISIÚNTA NA NATIONAL COUNCIL FOR VOCATIONAL AWARDS PILOT. Consultative Draft Module Descriptor. Relational Database COMHAIRLE NÁISIÚNTA NA gcáilíochtaí GAIRMOIDEACHAIS NATIONAL COUNCIL FOR VOCATIONAL AWARDS PILOT Consultative Draft Module Descriptor Relational Database Level 3 C30147 December 1998 1 Title Relational

More information

chapater 7 : Distributed Database Management Systems

chapater 7 : Distributed Database Management Systems chapater 7 : Distributed Database Management Systems Distributed Database Management System When an organization is geographically dispersed, it may choose to store its databases on a central database

More information

14 Databases. Source: Foundations of Computer Science Cengage Learning. Objectives After studying this chapter, the student should be able to:

14 Databases. Source: Foundations of Computer Science Cengage Learning. Objectives After studying this chapter, the student should be able to: 14 Databases 14.1 Source: Foundations of Computer Science Cengage Learning Objectives After studying this chapter, the student should be able to: Define a database and a database management system (DBMS)

More information

H4 DATABASE DEVELOPMENT SOLUTIONS & MARKING SCHEME JUNE 2013

H4 DATABASE DEVELOPMENT SOLUTIONS & MARKING SCHEME JUNE 2013 H4 DATABASE DEVELOPMENT SOLUTIONS & MARKING SCHEME JUNE 2013 PART A. Answer A1. Explain the term metadata in the context of a data dictionary and how a database management system makes use of it. Data

More information

Principles of Distributed Database Systems

Principles of Distributed Database Systems M. Tamer Özsu Patrick Valduriez Principles of Distributed Database Systems Third Edition

More information

KNOWLEDGE FACTORING USING NORMALIZATION THEORY

KNOWLEDGE FACTORING USING NORMALIZATION THEORY KNOWLEDGE FACTORING USING NORMALIZATION THEORY J. VANTHIENEN M. SNOECK Katholieke Universiteit Leuven Department of Applied Economic Sciences Dekenstraat 2, 3000 Leuven (Belgium) tel. (+32) 16 28 58 09

More information

Database Management. Chapter Objectives

Database Management. Chapter Objectives 3 Database Management Chapter Objectives When actually using a database, administrative processes maintaining data integrity and security, recovery from failures, etc. are required. A database management

More information

Oracle Database 12c: Introduction to SQL Ed 1.1

Oracle Database 12c: Introduction to SQL Ed 1.1 Oracle University Contact Us: 1.800.529.0165 Oracle Database 12c: Introduction to SQL Ed 1.1 Duration: 5 Days What you will learn This Oracle Database: Introduction to SQL training helps you write subqueries,

More information

THE BCS PROFESSIONAL EXAMINATION Diploma. October 2004 EXAMINERS REPORT. Database Systems

THE BCS PROFESSIONAL EXAMINATION Diploma. October 2004 EXAMINERS REPORT. Database Systems THE BCS PROFESSIONAL EXAMINATION Diploma October 2004 EXAMINERS REPORT Database Systems Question 1 1. a) In your own words, briefly describe why a relational database design must be normalised prior to

More information

Oracle SQL. Course Summary. Duration. Objectives

Oracle SQL. Course Summary. Duration. Objectives Oracle SQL Course Summary Identify the major structural components of the Oracle Database 11g Create reports of aggregated data Write SELECT statements that include queries Retrieve row and column data

More information

Fundamentals of Database Systems, 4 th Edition By Ramez Elmasri and Shamkant Navathe. Table of Contents. A. Short Table of Contents

Fundamentals of Database Systems, 4 th Edition By Ramez Elmasri and Shamkant Navathe. Table of Contents. A. Short Table of Contents Fundamentals of Database Systems, 4 th Edition By Ramez Elmasri and Shamkant Navathe Table of Contents A. Short Table of Contents (This Includes part and chapter titles only) PART 1: INTRODUCTION AND CONCEPTUAL

More information

MS-40074: Microsoft SQL Server 2014 for Oracle DBAs

MS-40074: Microsoft SQL Server 2014 for Oracle DBAs MS-40074: Microsoft SQL Server 2014 for Oracle DBAs Description This four-day instructor-led course provides students with the knowledge and skills to capitalize on their skills and experience as an Oracle

More information

Introduction to Databases

Introduction to Databases Page 1 of 5 Introduction to Databases An introductory example What is a database? Why do we need Database Management Systems? The three levels of data abstraction What is a Database Management System?

More information

ICOM 6005 Database Management Systems Design. Dr. Manuel Rodríguez Martínez Electrical and Computer Engineering Department Lecture 2 August 23, 2001

ICOM 6005 Database Management Systems Design. Dr. Manuel Rodríguez Martínez Electrical and Computer Engineering Department Lecture 2 August 23, 2001 ICOM 6005 Database Management Systems Design Dr. Manuel Rodríguez Martínez Electrical and Computer Engineering Department Lecture 2 August 23, 2001 Readings Read Chapter 1 of text book ICOM 6005 Dr. Manuel

More information

BCA. Database Management System

BCA. Database Management System BCA IV Sem Database Management System Multiple choice questions 1. A Database Management System (DBMS) is A. Collection of interrelated data B. Collection of programs to access data C. Collection of data

More information

The core theory of relational databases. Bibliography

The core theory of relational databases. Bibliography The core theory of relational databases Slide 1 La meilleure pratique... c est une bonne théorie Bibliography M.Levene, G.Loizou, Guided Tour of Relational Databases and Beyond, Springer, 625 pages,1999.

More information

DBMS Questions. 3.) For which two constraints are indexes created when the constraint is added?

DBMS Questions. 3.) For which two constraints are indexes created when the constraint is added? DBMS Questions 1.) Which type of file is part of the Oracle database? A.) B.) C.) D.) Control file Password file Parameter files Archived log files 2.) Which statements are use to UNLOCK the user? A.)

More information

Microsoft SQL Server for Oracle DBAs Course 40045; 4 Days, Instructor-led

Microsoft SQL Server for Oracle DBAs Course 40045; 4 Days, Instructor-led Microsoft SQL Server for Oracle DBAs Course 40045; 4 Days, Instructor-led Course Description This four-day instructor-led course provides students with the knowledge and skills to capitalize on their skills

More information

ISM 318: Database Systems. Objectives. Database. Dr. Hamid R. Nemati

ISM 318: Database Systems. Objectives. Database. Dr. Hamid R. Nemati ISM 318: Database Systems Dr. Hamid R. Nemati Department of Information Systems Operations Management Bryan School of Business Economics Objectives Underst the basics of data databases Underst characteristics

More information

Oracle Database 10g: Introduction to SQL

Oracle Database 10g: Introduction to SQL Oracle University Contact Us: 1.800.529.0165 Oracle Database 10g: Introduction to SQL Duration: 5 Days What you will learn This course offers students an introduction to Oracle Database 10g database technology.

More information

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

Relational model. Relational model - practice. Relational Database Definitions 9/27/11. Relational model. Relational Database: Terminology

Relational model. Relational model - practice. Relational Database Definitions 9/27/11. Relational model. Relational Database: Terminology COS 597A: Principles of Database and Information Systems elational model elational model A formal (mathematical) model to represent objects (data/information), relationships between objects Constraints

More information

Distributed Databases

Distributed Databases Distributed Databases Chapter 1: Introduction Johann Gamper Syllabus Data Independence and Distributed Data Processing Definition of Distributed databases Promises of Distributed Databases Technical Problems

More information

Databases. DSIC. Academic Year 2010-2011

Databases. DSIC. Academic Year 2010-2011 Databases DSIC. Academic Year 2010-2011 1 Lecturer José Hernández-Orallo Office 236, 2nd floor DSIC. Email: jorallo@dsic.upv.es http://www.dsic.upv.es/~jorallo/docent/bda/bdaeng.html Attention hours On

More information

B.Com(Computers) II Year RELATIONAL DATABASE MANAGEMENT SYSTEM Unit- I

B.Com(Computers) II Year RELATIONAL DATABASE MANAGEMENT SYSTEM Unit- I B.Com(Computers) II Year RELATIONAL DATABASE MANAGEMENT SYSTEM Unit- I 1 1. What is Data? A. Data is a collection of raw information. 2. What is Information? A. Information is a collection of processed

More information

How to Choose Between Hadoop, NoSQL and RDBMS

How to Choose Between Hadoop, NoSQL and RDBMS How to Choose Between Hadoop, NoSQL and RDBMS Keywords: Jean-Pierre Dijcks Oracle Redwood City, CA, USA Big Data, Hadoop, NoSQL Database, Relational Database, SQL, Security, Performance Introduction A

More information

Distributed Database Management Systems

Distributed Database Management Systems Distributed Database Management Systems (Distributed, Multi-database, Parallel, Networked and Replicated DBMSs) Terms of reference: Distributed Database: A logically interrelated collection of shared data

More information

White Paper. Optimizing the Performance Of MySQL Cluster

White Paper. Optimizing the Performance Of MySQL Cluster White Paper Optimizing the Performance Of MySQL Cluster Table of Contents Introduction and Background Information... 2 Optimal Applications for MySQL Cluster... 3 Identifying the Performance Issues.....

More information

BUSINESS RULES AND GAP ANALYSIS

BUSINESS RULES AND GAP ANALYSIS Leading the Evolution WHITE PAPER BUSINESS RULES AND GAP ANALYSIS Discovery and management of business rules avoids business disruptions WHITE PAPER BUSINESS RULES AND GAP ANALYSIS Business Situation More

More information

Oracle Database 11g SQL

Oracle Database 11g SQL AO3 - Version: 2 19 June 2016 Oracle Database 11g SQL Oracle Database 11g SQL AO3 - Version: 2 3 days Course Description: This course provides the essential SQL skills that allow developers to write queries

More information

Basic Concepts of Database Systems

Basic Concepts of Database Systems CS2501 Topic 1: Basic Concepts 1.1 Basic Concepts of Database Systems Example Uses of Database Systems - account maintenance & access in banking - lending library systems - airline reservation systems

More information

DBMS / Business Intelligence, SQL Server

DBMS / Business Intelligence, SQL Server DBMS / Business Intelligence, SQL Server Orsys, with 30 years of experience, is providing high quality, independant State of the Art seminars and hands-on courses corresponding to the needs of IT professionals.

More information

æ A collection of interrelated and persistent data èusually referred to as the database èdbèè.

æ A collection of interrelated and persistent data èusually referred to as the database èdbèè. CMPT-354-Han-95.3 Lecture Notes September 10, 1995 Chapter 1 Introduction 1.0 Database Management Systems 1. A database management system èdbmsè, or simply a database system èdbsè, consists of æ A collection

More information

PartJoin: An Efficient Storage and Query Execution for Data Warehouses

PartJoin: An Efficient Storage and Query Execution for Data Warehouses PartJoin: An Efficient Storage and Query Execution for Data Warehouses Ladjel Bellatreche 1, Michel Schneider 2, Mukesh Mohania 3, and Bharat Bhargava 4 1 IMERIR, Perpignan, FRANCE ladjel@imerir.com 2

More information

Bridge from Entity Relationship modeling to creating SQL databases, tables, & relations

Bridge from Entity Relationship modeling to creating SQL databases, tables, & relations 1 Topics for this week: 1. Good Design 2. Functional Dependencies 3. Normalization Readings for this week: 1. E&N, Ch. 10.1-10.6; 12.2 2. Quickstart, Ch. 3 3. Complete the tutorial at http://sqlcourse2.com/

More information

Dataset Preparation and Indexing for Data Mining Analysis Using Horizontal Aggregations

Dataset Preparation and Indexing for Data Mining Analysis Using Horizontal Aggregations Dataset Preparation and Indexing for Data Mining Analysis Using Horizontal Aggregations Binomol George, Ambily Balaram Abstract To analyze data efficiently, data mining systems are widely using datasets

More information

Chapter 2. Data Model. Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel

Chapter 2. Data Model. Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel Chapter 2 Data Model Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel 1 In this chapter, you will learn: Why data models are important About the basic data-modeling

More information

Distributed Databases. Fábio Porto LBD winter 2004/2005

Distributed Databases. Fábio Porto LBD winter 2004/2005 Distributed Databases LBD winter 2004/2005 1 Agenda Introduction Architecture Distributed database design Query processing on distributed database Data Integration 2 Outline Introduction to DDBMS Architecture

More information

Distributed Databases in a Nutshell

Distributed Databases in a Nutshell Distributed Databases in a Nutshell Marc Pouly Marc.Pouly@unifr.ch Department of Informatics University of Fribourg, Switzerland Priciples of Distributed Database Systems M. T. Özsu, P. Valduriez Prentice

More information

PeopleTools Tables: The Application Repository in the Database

PeopleTools Tables: The Application Repository in the Database PeopleTools Tables: The Application Repository in the Database by David Kurtz, Go-Faster Consultancy Ltd. Since their takeover of PeopleSoft, Oracle has announced project Fusion, an initiative for a new

More information

3. Mathematical Induction

3. Mathematical Induction 3. MATHEMATICAL INDUCTION 83 3. Mathematical Induction 3.1. First Principle of Mathematical Induction. Let P (n) be a predicate with domain of discourse (over) the natural numbers N = {0, 1,,...}. If (1)

More information

Relational Database: Additional Operations on Relations; SQL

Relational Database: Additional Operations on Relations; SQL Relational Database: Additional Operations on Relations; SQL Greg Plaxton Theory in Programming Practice, Fall 2005 Department of Computer Science University of Texas at Austin Overview The course packet

More information

Structure of Presentation. The Role of Programming in Informatics Curricula. Concepts of Informatics 2. Concepts of Informatics 1

Structure of Presentation. The Role of Programming in Informatics Curricula. Concepts of Informatics 2. Concepts of Informatics 1 The Role of Programming in Informatics Curricula A. J. Cowling Department of Computer Science University of Sheffield Structure of Presentation Introduction The problem, and the key concepts. Dimensions

More information

BUSINESS RULES AS PART OF INFORMATION SYSTEMS LIFE CYCLE: POSSIBLE SCENARIOS Kestutis Kapocius 1,2,3, Gintautas Garsva 1,2,4

BUSINESS RULES AS PART OF INFORMATION SYSTEMS LIFE CYCLE: POSSIBLE SCENARIOS Kestutis Kapocius 1,2,3, Gintautas Garsva 1,2,4 International Conference 20th EURO Mini Conference Continuous Optimization and Knowledge-Based Technologies (EurOPT-2008) May 20 23, 2008, Neringa, LITHUANIA ISBN 978-9955-28-283-9 L. Sakalauskas, G.W.

More information

Performance Tuning for the Teradata Database

Performance Tuning for the Teradata Database Performance Tuning for the Teradata Database Matthew W Froemsdorf Teradata Partner Engineering and Technical Consulting - i - Document Changes Rev. Date Section Comment 1.0 2010-10-26 All Initial document

More information

Files. Files. Files. Files. Files. File Organisation. What s it all about? What s in a file?

Files. Files. Files. Files. Files. File Organisation. What s it all about? What s in a file? Files What s it all about? Information being stored about anything important to the business/individual keeping the files. The simple concepts used in the operation of manual files are often a good guide

More information

Chapter 2 Database System Concepts and Architecture

Chapter 2 Database System Concepts and Architecture Chapter 2 Database System Concepts and Architecture Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 2 Outline Data Models, Schemas, and Instances Three-Schema Architecture

More information

SAMPLE FINAL EXAMINATION SPRING SESSION 2015

SAMPLE FINAL EXAMINATION SPRING SESSION 2015 SAMPLE FINAL EXAMINATION SPRING SESSION 2015 School of Computing, Engineering and Mathematics Student family name: Student given name/s: Student ID number: Course: Unit Name (In Full): Database Design

More information

Advanced Database Group Project - Distributed Database with SQL Server

Advanced Database Group Project - Distributed Database with SQL Server Advanced Database Group Project - Distributed Database with SQL Server Hung Chang, Qingyi Zhu Erasmus Mundus IT4BI 1. Introduction 1.1 Motivation Distributed database is vague for us. How to differentiate

More information

SQL Server. 1. What is RDBMS?

SQL Server. 1. What is RDBMS? SQL Server 1. What is RDBMS? Relational Data Base Management Systems (RDBMS) are database management systems that maintain data records and indices in tables. Relationships may be created and maintained

More information

Course: CSC 222 Database Design and Management I (3 credits Compulsory)

Course: CSC 222 Database Design and Management I (3 credits Compulsory) Course: CSC 222 Database Design and Management I (3 credits Compulsory) Course Duration: Three hours per week for 15weeks with practical class (45 hours) As taught in 2010/2011 session Lecturer: Oladele,

More information

THE IMPACT OF INHERITANCE ON SECURITY IN OBJECT-ORIENTED DATABASE SYSTEMS

THE IMPACT OF INHERITANCE ON SECURITY IN OBJECT-ORIENTED DATABASE SYSTEMS THE IMPACT OF INHERITANCE ON SECURITY IN OBJECT-ORIENTED DATABASE SYSTEMS David L. Spooner Computer Science Department Rensselaer Polytechnic Institute Troy, New York 12180 The object-oriented programming

More information

PARAMETRIC MODELING. David Rosen. December 1997. By carefully laying-out datums and geometry, then constraining them with dimensions and constraints,

PARAMETRIC MODELING. David Rosen. December 1997. By carefully laying-out datums and geometry, then constraining them with dimensions and constraints, 1 of 5 11/18/2004 6:24 PM PARAMETRIC MODELING David Rosen December 1997 The term parametric modeling denotes the use of parameters to control the dimensions and shape of CAD models. Think of a rubber CAD

More information

Data Integration and Exchange. L. Libkin 1 Data Integration and Exchange

Data Integration and Exchange. L. Libkin 1 Data Integration and Exchange Data Integration and Exchange L. Libkin 1 Data Integration and Exchange Traditional approach to databases A single large repository of data. Database administrator in charge of access to data. Users interact

More information

low-level storage structures e.g. partitions underpinning the warehouse logical table structures

low-level storage structures e.g. partitions underpinning the warehouse logical table structures DATA WAREHOUSE PHYSICAL DESIGN The physical design of a data warehouse specifies the: low-level storage structures e.g. partitions underpinning the warehouse logical table structures low-level structures

More information

A Comparison of Approaches to Large-Scale Data Analysis

A Comparison of Approaches to Large-Scale Data Analysis A Comparison of Approaches to Large-Scale Data Analysis Sam Madden MIT CSAIL with Andrew Pavlo, Erik Paulson, Alexander Rasin, Daniel Abadi, David DeWitt, and Michael Stonebraker In SIGMOD 2009 MapReduce

More information

The World Wide Web as a Distributed Object System

The World Wide Web as a Distributed Object System The World Wide Web as a Distributed Object System Travis Olds School of Computer Science The University of Adelaide SA, 5005, Australia trav@cs.adelaide.edu.au Abstract This paper considers the idea of

More information

Once the schema has been designed, it can be implemented in the RDBMS.

Once the schema has been designed, it can be implemented in the RDBMS. 2. Creating a database Designing the database schema... 1 Representing Classes, Attributes and Objects... 2 Data types... 5 Additional constraints... 6 Choosing the right fields... 7 Implementing a table

More information

An Overview of Distributed Databases

An Overview of Distributed Databases International Journal of Information and Computation Technology. ISSN 0974-2239 Volume 4, Number 2 (2014), pp. 207-214 International Research Publications House http://www. irphouse.com /ijict.htm An Overview

More information

Automating Rich Internet Application Development for Enterprise Web 2.0 and SOA

Automating Rich Internet Application Development for Enterprise Web 2.0 and SOA Automating Rich Internet Application Development for Enterprise Web 2.0 and SOA Enterprise Web 2.0 >>> FAST White Paper November 2006 Abstract Modern Rich Internet Applications for SOA have to cope with

More information

Automated Teller Machine (ATM), Host Processor, Distributed Database Management System, Fragments. 1. INTRODUCTION

Automated Teller Machine (ATM), Host Processor, Distributed Database Management System, Fragments. 1. INTRODUCTION DESIGNING AN ATM NETWORK BASED ON DISTRIBUTED DATABASE SYSTEMS Md. Rahat Hossain*, Abdullah Azfar *, Golam Shagadul Amin Talukder**,, S M Faisal*, Abdullah Al Hasib* ABSTRACT Automated teller machines

More information

Relational Database Basics Review

Relational Database Basics Review Relational Database Basics Review IT 4153 Advanced Database J.G. Zheng Spring 2012 Overview Database approach Database system Relational model Database development 2 File Processing Approaches Based on

More information

Base One's Rich Client Architecture

Base One's Rich Client Architecture Base One's Rich Client Architecture Base One provides a unique approach for developing Internet-enabled applications, combining both efficiency and ease of programming through its "Rich Client" architecture.

More information

Mapping between Levels in the Metamodel Architecture

Mapping between Levels in the Metamodel Architecture Mapping between Levels in the Metamodel Architecture José Álvarez, Andy Evans 2, Paul Sammut 2 Dpto. de Lenguajes y Ciencias de la Computación, University Málaga, Málaga, 2907, Spain alvarezp@lcc.uma.es

More information

EMBL-EBI. Database Replication - Distribution

EMBL-EBI. Database Replication - Distribution Database Replication - Distribution Relational public databases EBI s mission to provide freely accessible information on the public domain Data formats and technologies, should not contradict to this

More information

Chapter 1: Introduction

Chapter 1: Introduction Chapter 1: Introduction Database System Concepts, 5th Ed. See www.db book.com for conditions on re use Chapter 1: Introduction Purpose of Database Systems View of Data Database Languages Relational Databases

More information

Data. Data and database. Aniel Nieves-González. Fall 2015

Data. Data and database. Aniel Nieves-González. Fall 2015 Data and database Aniel Nieves-González Fall 2015 Data I In the context of information systems, the following definitions are important: 1 Data refers simply to raw facts, i.e., facts obtained by measuring

More information

Managing Variability in Software Architectures 1 Felix Bachmann*

Managing Variability in Software Architectures 1 Felix Bachmann* Managing Variability in Software Architectures Felix Bachmann* Carnegie Bosch Institute Carnegie Mellon University Pittsburgh, Pa 523, USA fb@sei.cmu.edu Len Bass Software Engineering Institute Carnegie

More information

Lesson 8: Introduction to Databases E-R Data Modeling

Lesson 8: Introduction to Databases E-R Data Modeling Lesson 8: Introduction to Databases E-R Data Modeling Contents Introduction to Databases Abstraction, Schemas, and Views Data Models Database Management System (DBMS) Components Entity Relationship Data

More information

Chapter 23. Database Security. Security Issues. Database Security

Chapter 23. Database Security. Security Issues. Database Security Chapter 23 Database Security Security Issues Legal and ethical issues Policy issues System-related issues The need to identify multiple security levels 2 Database Security A DBMS typically includes a database

More information

Databases What the Specification Says

Databases What the Specification Says Databases What the Specification Says Describe flat files and relational databases, explaining the differences between them; Design a simple relational database to the third normal form (3NF), using entityrelationship

More information

Document Production: Visual or Logical?

Document Production: Visual or Logical? Document Production: Visual or Logical? Leslie Lamport 24 February 1987 The Choice Document production systems convert the user s input his keystrokes and mouse clicks into a printed document. There are

More information

Database Schema Management

Database Schema Management Whitemarsh Information Systems Corporation 2008 Althea Lane Bowie, Maryland 20716 Tele: 301-249-1142 Email: Whitemarsh@wiscorp.com Web: www.wiscorp.com Table of Contents 1. Objective...1 2. Topics Covered...2

More information

SECURITY MODELS FOR OBJECT-ORIENTED DATA BASES

SECURITY MODELS FOR OBJECT-ORIENTED DATA BASES 82-10-44 DATA SECURITY MANAGEMENT SECURITY MODELS FOR OBJECT-ORIENTED DATA BASES James Cannady INSIDE: BASICS OF DATA BASE SECURITY; Discretionary vs. Mandatory Access Control Policies; Securing a RDBMS

More information

A Design Technique: Data Integration Modeling

A Design Technique: Data Integration Modeling C H A P T E R 3 A Design Technique: Integration ing This chapter focuses on a new design technique for the analysis and design of data integration processes. This technique uses a graphical process modeling

More information