2 George Feuerlicht and Jaroslav Pokorný and Karel Richta
|
|
- Claude Joseph
- 8 years ago
- Views:
Transcription
1 Object-Relational Database Design: Can Your Application Benefit from SQL:2003? George Feuerlicht 1 and Jaroslav Pokorný 2 and Karel Richta 3 1 University of Technology, Sydney, Australia, jiri@it.uts.edu.au 2 Charles University of Prague, Prague, Czech Republic, jaroslav.pokorny@mff.cuni.cz 3 Czech Technical University of Prague, Czech Republic, richta@fel.cvut.cz Abstract. Traditional database design methods based on information engineering principles and data normalization do not fully apply to SQL:2003 object-relational databases. New design methodologies and tools are needed to support complex data constructs used in today s software engineering practice. There are application domains such as spatial, geographical information systems and multimedia applications where the use of object-relational features is mandatory. There are also many other application types that are good candidates for objectrelational features, but are frequently implemented using purely relational design as designers hesitate to face the challenges of object-relational design. It can be argued that the use of object-relational features is limited in practice by the lack of design methodologies that can guide database designers in making informed decisions about design choices that involve comparisons of relational and object-relational solutions. In this paper we discuss objectrelational design guidelines and illustrate using an example that the object-relational implementation can provide significant benefits simplifying the resulting data structures and the implementation of database queries. 1. Introduction The early research and development of object-oriented databases at the beginning of 90s was followed by the emergence of object-relational database approach that builds on the relational database model extending it with object-oriented features. An extensive effort by the database industry and researchers over a period of more than six years resulted in the specification of the SQL:1999 language standard (ISO/IEC 1999) that became the blueprint for the implementation of Object-Relational Database Management Systems (ORDBMS). SQL:1999 and the more recent SQL:2003 (ISO/IEC 2003) provide support for a comprehensive range of features that enable the implementation of complex data types and relationships that characterize modern database applications. However, the availability of such features does not automatically result in an improved design and a more efficient database implementation. Traditional database design methods based on data engineering principles that in-
2 2 George Feuerlicht and Jaroslav Pokorný and Karel Richta volve data normalization do not fully apply to object-relational databases. New design methodologies and tools are needed to support complex data constructs used in today s software engineering practice. ORDBMS must also address the problem of efficient storage and management of complex objects (Zhu et al. 2006) and XML data (Mlýnková and Pokorný 2005). The first attempts to propose methodologies for object-relational databases followed soon after the standardization of objectrelational extensions in SQL:1999, e.g., (Marcos et al. 2001; Rahayu and Taniar 2002; Marcos et al. 2004; Pardede et al. 2004). Notwithstanding such efforts, there are still no widely accepted methodologies for ORDB (Object-Relational Database) design. In some cases the design guidelines rely on proprietary extensions to the SQL standard available in specific ORDBMS products. Furthermore, enhancements included in SQL:2003 have not been systematically incorporated in such approaches. Currently available modelling and design tools vary in notation and constructs they support, but generally use entity types and their hierarchies and various forms of relationships, and have only limited support for SQL:2003. This holds true not only for entity-relational modelling tools, but also for UML-based tools that support object-oriented modelling. The richness of the object-relational data model (when compared to the relational model), and the repertoire of various constructs makes logical database design highly challenging as the number of design options for a given conceptual model dramatically increases. This makes it difficult to develop a methodology that designers can follow in order to map a conceptual schema (either object-oriented or entity-relationship) to an objectrelational database, and at the same time maximizing the effectiveness and efficiency of the design. Design of relational databases follows a structured methodology applying a set of well-defined transformations of the conceptual schema into normalized relations (3NF tables). Using the object-relational design, additional properties of the conceptual schema, such as its graph structure need to be considered. Furthermore, objectrelational design must take into account application requirements, as they impact on the choice of the most appropriate database structures. Consequently, the designer must understand how the data is going to be used by applications including the details of principal queries. In most standard business applications that use simple data structures (e.g. purchase order processing, customer relationship management, etc.) the use of object-relational features introduces unnecessary complexities into the design. In such cases purely relational design may represent the best solution. There are other application domains such as spatial, GIS (Geographical Information Systems) and multimedia applications where the use of object-relational extensions to represent application objects is mandatory. But, importantly, there are many other types of database applications that are good candidates for object-relational features, but are frequently implemented as relational databases because of the lack of suitable design methodologies that can assist with the evaluation of different design strategies. It can be argued that the use of object-relational features in SQL:2003 is limited in practice by the lack of design methodologies that can guide database designers in making informed decisions about design choices that involve comparisons of relational and object-relational solutions. In this paper we show that object-relational features can provide significant benefits simplifying the resulting data structures and
3 Object-Relational Database Design: Can Your Application Benefit from SQL:2003? 3 the implementation of database queries. In section 2 we discuss the available literature dealing with the topic of object-relational database design. In section 3 we overview the main conceptual constructs used in object-relational models and design tools, and in section 4 we describe the corresponding SQL:2003 object-relational features. In section 5 we introduce the transformation rules for mapping conceptual models to object-relational schemas and discuss their application using an illustrative example. In the concluding section (section 6) we briefly summarize the main contributions of this paper and identify the need for further research in this area. 2. Related work Approaches to object-relational design can be classified into two main categories: 1) General approaches based on the constructs of conceptual models 2) Domainspecific approaches based on data types used in specific domain applications, e.g. spatial data, XML data, scientific data, etc. 2.1 General approaches Marcos et al. (2001) and (2004) consider a methodological approach for ORDB design using UML extensions. In the latter paper Marcos et al. present guidelines for object-relational database design assuming that the conceptual schema is represented in UML and that the target language is SQL:1999. Paper by (Urban et al. 2003) illustrates how UML diagrams can be used to study mappings to different types of database systems, including ORDBSs based on the SQL:1999 standard. Some methodologies are specific to commercial products (e.g. Oracle), and incorporate vendor specific features that are inconsistent with the SQL standards, see, for example (de Haan 2005). Another important area of research concerns the representation of complex objects. For example, (Pardede et al. 2004) consider aggregation constructs and its representation in Oracle 9i. They propose two methods based on proprietary constructs, so called index clustering and nested tables. 2.2 Domain-specific Approaches Mapping spatial data models into object-relational database schemas has been the subject of extensive research interest. For example, the book by (Parent et al. 2006) is devoted to conceptual modelling of spatial and spatio-temporal databases based of the MADS (Modelling of Application Data with Spatio-temporal features) conceptual model. Authors discuss a structural dimension of MADS in the context of object-relational databases, and SQL:2003. They developed a prototype that translates MADS conceptual models into corresponding database schemas for the Oracle and GIS-oriented systems ArcView, and MapInfo systems. The combination of XML and spatial features can be encoded in the Geography Markup Language (GML). Zhu et al. (2006) propose an approach to map GML schema to object-relational database schema based on SQL:1999 and store non-spatial and spatial data from GML documents in object-relational spatial database. The mapping rules from GML schema to
4 4 George Feuerlicht and Jaroslav Pokorný and Karel Richta object-relational schema are established so that the structure and semantic constraints of the source GML schema can be preserved in the target object-relational schema. Cohen et al. (2006) consider object-relational representation of the Weather Research and Forecasting (WRF) Model. The main problem the authors attempt to address is how to represent multidimensional variables. ORDB approach offers a more effective solution than the Star or Snowflake schemas transformed into 1NF relations used in data warehousing applications. Authors use mainly ORACLE s built-in array types (collections) Variable Arrays (Varrays) and Nested Tables. 3. Conceptual Model Constructs In this section we review the conceptual constructs used in database modelling and comment on their limitations in the context of ORDB design. Based on the traditional entity-relationship-attribute approaches, the constructs of conceptual models include: entity types (E), relationship types (R), attributes (A), weak entity types, and ISA hierarchies. The original Chen s approach to ERA (Entity-Relationship- Attribute) modelling includes n-ary relationships with arbitrary cardinalities, but the cardinality is typically restricted in commercial tools, e.g. (Oracle Designer 2000) to binary relationships with cardinalities 1:N. ISA hierarchies are analogous to class hierarchies in UML. Perhaps, the most significant restriction in conceptual modelling concerns attribute structures. Although there is a natural use for multivalued and composite attributes, most theoretical ERA approaches and practical tools support only simple (atomic) attributes, leading to direct transformation of conceptual structures to 1NF relations. Neglecting rather exotic conceptual constructs such as exclusive relationship types (Oracle 2000), we further consider aggregation and composition. Aggregation and composition are not usually supported in ERA modelling tools, but in UML they are treated as first-class constructs. An aggregation is a partof relationship, in which a composite object (a whole) consists of other component objects (parts). Shareable and existence-independent parts can be represented. We can differentiate between simple aggregations (Marcos et al. 2001), and aggregation hierarchies with several levels of aggregation. A composition is special kind of aggregation in which parts are existentially-dependent on the whole. Consequently, deletions result in removal of all dependent parts. More recently, conceptual models were extended to support XML data, e.g. (Nečaský 2007). The notion of hierarchy is essential to modelling XML data. XML hierarchy can be based on general relationships between entities of two different entity types or modelled specifically using aggregation and composition. The root of the hierarchy can be identified using a graph analysis of the conceptual schema and the hierarchy and then transformed into XML Schema or directly into types and tables of the object-relational data model. Complex data types that can be represented using the object-relational model include geometric complex types, (e.g. line, circle, polygon etc.) used in spatial databases (Zhu et al. 2006).
5 Object-Relational Database Design: Can Your Application Benefit from SQL:2003? Illustrative Example To illustrate some of the key features of the object-relational model, consider, for example an Online Movie Database (OMDB) that maintains information about movies, actors, directors, and other movie related information. Users can browse this information on the OMDB website and purchase products (i.e. movie videos, DVDs, books, CDs, and other movie related merchandise). The movie information includes the movie title, director, the official movie website, genre, studio, short synopsis, and the cast (i.e. actors and the roles they play in the movie). Each movie has up to 5 external editorial reviews, and unlimited number of user reviews entered by users online. OMDB website offers products for sale including movie videos and DVDs. Information about videos and DVDs includes title, rating, list price, release date, and other relevant information. This situation can be modelled using a UML Class Diagram shown in Fig. 1. We return to the OMDB model in section 5 where we discuss the design options for transforming the conceptual model into SQL:2003 objectrelational database implementation. class OMDB «container» people - id: OID director_type «container» movies - id: OID «container» products - id: OID director {ordered} {ordered} {ordered} «metaclass» Person_type - country: string(20) - dob: date - name: string(100) - sex: char(1) movie_type - genre: string(20) - studio: string(20) - synopsis: string(500) - title: string(100) - website: string(40) movie_ref «metaclass» product_type playwriter_type - availability: string(50) - list_price: money - our_price: money - production_company: string(30) - rating: string(10) - release_date: date - runtime: integer(3) 1 playwriter_ref ext_review movie_ref actor_type cast_type - casting_order: integer(2) - role: string(50) external_review_type - review_source: string(50) - review_url: string(50) user_review video_type actor_ref - format: string(10) dvd_type - acpect_ratio: string(10) - dvd_encoding: string(10) - number_of_disos: integer(1) * «container» castings {ordered} - id: OID user_review_type - review_date: date - review_text: string(4000) - reviewer: string(30) - score: integer(1) Fig. 1: Conceptual Model of OMDB database 4. SQL:2003 Object-Relational Model In this paper we focus on object-relational databases whose type system is consistent with the SQL standard (i.e. SQL:2003 and its predecessor SQL:1999). The SQL:2003 model is a superset of the original relational model and a relation (table) remains the main data structure, potentially with a sub-structure that may involve complex objects. Objects in the SQL:2003 object-relational model are implemented using user defined types (UDTs). UDTs are either row types or structured types that can include methods specifications and are analogous to Abstract Data Types
6 6 George Feuerlicht and Jaroslav Pokorný and Karel Richta (ADTs) in object-oriented databases. With a row type in a table column we can model composite attributes. Structured types can be used to type tables and columns. An object in SQL:2003 is a row of a typed table that includes an OID (Object Identifier). SQL:2003 includes constructors for two special user-defined collection types: ARRAY and MULTISET that are used to implement multivalued attributes. Collection types and row types allow the representation of multivalued and composite attributes, respectively, providing a mechanism for implementing de-normalized tables. The SQL:2003 standard further extends the data structures introduced in the standard SQL:1999 to provide more flexibility for implementation of multivalued attributes, changing array and multiset semantics in a number of significant ways. Arrays can be declared without specifying the cardinality, in which case the (maximum) cardinality is vendor-defined (potentially unbounded), and in SQL:2003 array nesting is unrestricted. Similarly, MULTISETs do not require specification of the maximum cardinality. The MULTISET construct in SQL:2003 allows differentiation between a NULL value and an empty set. Deleting the last element of a multivalued attribute in a table results in an empty set, as opposed to a NULL value. SQL:2003 defines advanced multiset support that includes comparison and set operators. There are three new aggregate functions: to create a multiset from the value of the argument in each row of a group (COLLECT), to create a multiset union of a multiset value in all rows of a group (FUSION), and to create the multiset intersection of a multiset value in all rows of a group (INTERSECTION). 5. Object-Relational Database Design Following the description of the object-relational modelling constructs (in section 3) and the SQL:2003 object-relational model in section 4, we now consider objectrelational database design describing the design choices available when transforming a conceptual model into a set of target SQL:2003 objects. SQL:2003 provides a rich environment for the implementation of database applications and presents the designer with a number of important decisions that include the choice between relational features and object-relational extensions. As the SQL:2003 model subsumes the relational model (i.e. SQL:1999 and SQL:2003 are supersets of SQL:1992), the designer can choose to implement the database as a purely relational database with untyped tables. Alternatively, the designer may decide to define all tables as typed tables and follow the object-relational approach. It is also possible to mix relational and object-relational features typing only selected tables. The designer needs to make decisions about using primary and foreign keys to implement relationships, or using OIDs and REFs (references) for typed tables. Implementation of relationship also present a number of choices; for example, aggregation and composition can be implemented using separate tables, or alternatively using SQL:2003 multisets. Such design decisions are of key importance and must be based on clear design principles and guidelines, as once implemented the database cannot not be readily re-structured to accommodate alternative design strategies. In the following section (5.1) we review the transformation rules for mapping conceptual constructs into SQL:2003 database structures. In section 5.2 we then
7 Object-Relational Database Design: Can Your Application Benefit from SQL:2003? 7 discuss (using the OMDB example introduced in section 3) the various design choices and the basis for making decisions about using object-relational features available in SQL: Transformation Rules for Mapping into SQL:2003 The transformation of a conceptual model into relational and object-relational database structures (i.e. typed or untyped tables) has been extensively investigated. Table 1 shows a typical set of mapping rules giving the correspondence between conceptual constructs and SQL:2003 database structures for both entity types and relationships. Conceptual construct SQL:2003 Type level Instance level Entity type Structured type typed table Attribute Multivalued Composed Calculated Relationship Column type ARRAY/MULTISET ROW/Structured type in column Trigger/Method 1:1 REF/REF 2 typed tables 1:N REF/[ARRAY MULTISET] 2 typed tables N:M ARRAY /[ARRAY MULTISET] 2 typed tables Aggregation REF/[ARRAY MULTISET] 2 typed tables Composition REF/[ARRAY MULTISET] 2 typed tables Generalization type hierarchy table hierarchy Hierarchy Based on composition Table 1. SQL:2003 Transformation Mapping Rules A number of options exist for implementing aggregation and composition using SQL:2003 structures and these have been described in the literature. For example, the authors of (Rahayu and Taniar 2002) present a classical relational solution with tables for the whole and the parts, and an additional, aggregate table. The rows of the aggregate table are of the form (whole_id, part_id, part_type). Using this approach referential integrity between aggregate and parts tables is not expressible using the declarative SQL statements. The cardinality of the relationship between the whole and the aggregate is 1:N, and between the part and the aggregate tables 1:1 or 1:N. The cardinality of the relationship between a part and the aggregate tables for a composition is 1:1. In addition to decisions about aggregate structures discussed above, the implementation of SQL:2003 style databases involves decisions about identifiers. Here we differentiate between two basic approaches: object-oriented, and valuebased. The former uses identifiers implied by structured types with relationships represented via references (REF types), or via SQL:2003 multisets. Attributes of
8 8 George Feuerlicht and Jaroslav Pokorný and Karel Richta relationships can be added to multiset elements, so that for example arrays of rows, possibly with additional structures can be used into an arbitrary depth. A further design decision involves implementing relationships as bi-directional or unidirectional (the expressivity of both options is the same). Further options include representing relationships by a multiset of primary key values added to a row representing an entity. Ordering of arrays can be relevant for storing XML hierarchies where ordering of child elements is of importance. We have applied the transformation rules in Table 1 to the OMDB conceptual model shown in Fig. 1 and produced the following type definition: create type external_review_type as object (...); create type external_review_array as varray(5) of external_review_type; create type user_review_type as object (...); create type user_review_table as table of user_review_type; create type person_type as object(...)not final; create type director_type under person_type (...); create type actor_type under person_type (...); create type playwriter_type under person_type (...); create type movie_type as object (...); create type product_type as object(...)not final; create type dvd_type under product_type (...); create type video_type under product_type (...); create type cast_type as object (...); We show abbreviated versions of the type definitions and do not show the corresponding typed tables. In the following sections we discuss the design guidelines used in transforming the OMDB conceptual model. 5.2 Design Guidelines As noted earlier, implementation of the SQL:2003 style databases using the transformation rules in Table 1 involves design decisions about which object-relational feature to use and how it should be deployed. Similar to design of relational databases such design decisions must be based on solid guidelines and universal principles that include the minimization of redundancy, maximizing reuse, and at the same time ensuring good query performance. Also importantly, the complexity of the design must be minimized as complex data structures lead to complexity of database applications and corresponding increase in the development and maintenance effort Data Normalization The question of minimizing data redundancy when using composite and nested database structures deserves attention. Normal forms provide a set of guiding principles for relational database design that lead to the minimization of data redundancy. It can be argued that normalization is relevant to object-relational database design, although with some important caveats. For example the use of non-atomic attributes, e.g. address type column that includes STREET, SUBURB, and POSTCODE, vio-
9 Object-Relational Database Design: Can Your Application Benefit from SQL:2003? 9 lates 1NF, but in general does not lead to redundant data, but using a collection (e.g. VARRAY) to implement a repeated attribute such as phone numbers (e.g. HOME PHONE, WORK PHONE, MOBILE PHONE, etc.) leads to complex retrieval logic, and should be avoided altogether. The use of SQL:2003 collections should be reserved for the implementation of composition and aggregation; in such cases collections represent a separate data structure (although embedded in the parent table) and do not result in redundant data. Similarly, using OIDs avoids partial dependencies between key and non-key attributes (i.e. violation of 2NF), but attribute interdependencies between non-key attributes can still exist and lead to data redundancy, violating 3NF and causing update anomalies OIDs vs Keys OIDs and REFs are generally used to implement complex relationships, and they are particularly useful for implementing multiple-level relationships, used for example in integrated circuit design, or component assemblies in manufacturing applications. The main advantage of using OIDs and REFs is the ability to navigate complex relationships without the need for relational joins, thus significantly reducing the number of database reads required to retrieve a composite object. OIDs and REFs typically incur additional storage and processing requirements that can be reduced by scoping references to a particular table. OIDs are also useful in situations where natural (attribute-based) identifiers are not available. We use OIDs throughout the OMDB database, for example for the person, movie and product object types. This leads to simplification and improved clarity of queries. For example, the following query requirement: List the cast for the movie The Godfather (in order of importance) showing actors and the roles they play. results in a relatively simple query: SELECT C.ACTOR_REF.NAME, C.CAST_ROLE FROM CASTINGS C WHERE C.MOVIE_REF.TITLE = 'THE GODFATHER' ORDER BY C.CASTING_ORDER; Column vs Row Types The SQL:2003 model allows the implementation of database objects as column or row types. Only row types have OIDs and should be used if referencing via REFs is required. Column objects (types) cannot be referenced directly and must be accessed via dot notation, e.g. employee.address.postcode (i.e. the corresponding row must be located first and then the column object accessed). Row types provide a comprehensive support for object features, including inheritance and method overriding. In the OMDB example we use typed tables throughout, and take advantage of subtyping and inheritance available for typed tables. The implementation of the PERSON type and all its subtypes (i.e. ACTOR_TYPE, DIRECTOR_TYPE, and PLAYWRITER_TYPE) is a single typed table PEOPLE OF PERSON_TYPE. This design results in a simple solution for query requirements such as:
10 10 George Feuerlicht and Jaroslav Pokorný and Karel Richta Are there any movies in which the director is also one of the actors/actresses? The following query takes advantage of referencing and of the fact that both actors and directors have the same supertypes (i.e. PERSON_TYPE). SELECT C.MOVIE_REF.TITLE, C.MOVIE_REF.DIRECTOR_REF.NAME, C.ROLE FROM CASTINGS C WHERE C.ACTOR_REF = C.MOVIE_REF.DIRECTOR_REF; Implementing Composition and Aggregation As discussed above a number of distinct options exist for the implementation of composition and aggregation in SQL:2003. The general rule for using collections to implement compositions and aggregation is that each detail object must belong to a single master object, and that the detail objects have no meaning out of the context of the master object (e.g. book and book chapters). Additional decisions involve choosing the type of collection most suitable for a specific design scenario, e.g. a choice between VARRAYs and NESTED TABLEs using the Oracle implementation. VARRAYs are more efficient if the collection is manipulated as a single unit using special array functions. NESTED TABLES, on the other hand provide more options for access to individual records using SQL queries that take advantage of the database optimizer, but have increased storage requirements (nested tables include a 16bytes system generated NESTED_TABLE_ID that points to the parent row). OMDB uses VARRAYs to implement the external reviews and NESTED TABLEs to implement the user reviews. Both review types are a form of aggregation, as the individual review records have no meaning outside of the particular movie record. The decision to use VARRAYs for external reviews and NESTED TABLEs for user reviews is based on the consideration of the likely large number of user review records, and the benefits of using SQL queries rather than array processing methods. We have avoided using collections for the implementation of CASTINGS type as a separate table give more flexibility and allows the use of the full power of SQL (including subqueries). The following example illustrates the point: For all movies list the leading actress, i.e. the first billed actress (in the order of credits). SELECT C.MOVIE_REF.TITLE, C.MOVIE_REF.GENRE, C.MOVIE_REF.DIRECTOR_REF.NAME, C.ACTOR_REF.NAME FROM CASTINGS C WHERE C.CASTING_ORDER = ( SELECT MIN(CASTING_ORDER) FROM CASTINGS WHERE ACTOR_REF.SEX = 'F' AND MOVIE_REF = C.MOVIE_REF); Generalization, Inheritance and Reuse SQL:2003 supports the notion of sub-types and super-types using user-defined types, including single inheritance and method overriding. This gives a number of design options for implementing super-type/sub-type combinations. The standard relational transformation leads to separate (un-typed) tables with each subtype transformed into
11 Object-Relational Database Design: Can Your Application Benefit from SQL:2003? 11 a corresponding table; alternatively the entire super-type/sub-type combination is transformed into a single relational supertype table. Object-relational transformation follows the same pattern, but supports inheritance and method overriding. For example, the following function AGE is defined for the supertype PERSON and inherited by all its subtypes: CREATE TYPE BODY PERSON_TYPE IS MEMBER FUNCTION AGE(DOB DATE) RETURN INTEGER IS... END; The function can then be used to give the age of the director of the movie SUNSHINE. SELECT M.TITLE,M.DIRECTOR_REF.NAME,AGE(M.DIRECTOR_REF.DOB) FROM MOVIES M WHERE M.TITLE = 'SUNSHINE'; Method overriding can be used to set discount levels for different types of products: CREATE TYPE BODY dvd_type AS OVERRIDING MEMBER FUNCTION SPECIAL_PRICE... END; CREATE TYPE BODY video_type AS OVERRIDING MEMBER FUNCTION SPECIAL_PRICE... END; 6. Conclusions The effective use of SQL:2003 object-relational features requires understanding of the design tradeoffs associated with alternative design strategies. In the absence of guidelines for object-relational database design practitioners tend to avoid using object-relational features altogether, missing out on the potential benefits that this approach provides. The main contribution of this paper is to show that objectrelational design can provide an elegant and an effective solution even for application types that are not normally regarded as candidates for object-relational implementation. We have illustrated using examples how object-relational features can be deployed in such database applications, discussing the design tradeoffs involved in adopting specific object-relational features such as collections, OIDs and REFs. Further work is needed to provide a fully comprehensive design methodology for object-relational databases that can serve as the basis for object-relational design tools. The inclusion of XML support in SQL:2003 creates another area of research interest and demand for design methodologies and tools. The availability of MUL- TISETs and ARRAY constructs in SQL:2003 makes ORDBMS systems suited for the management of hierarchically structured XML data, but numerous design options exist that need to be evaluated in the context of specific application requirements. Detailed discussion of XML design issues is out of the scope of this paper and will the subject of further publications.
12 12 George Feuerlicht and Jaroslav Pokorný and Karel Richta 7. Acknowledgments This research has been partially supported by the National Program of Research, Information Society Project No. 1ET , and also by Ministry of Education of Czech Republic under research program MSM and also by the grant of GACR No. GA201/06/0756. References Cohen, S., Hurley, P., Schulz, K.W., Barth, W.L. & Benton, B. (2006) ACM SIGMOD Record, Vol. 35, No 2 pp de Haan, L. (2005): Mastering Oracle SQL and SQL*Plus. APress. Geography Markup Language (GML) Implementation Specification Version 3.0. (2004) Available at ISO/IEC 9075:1999 (1999): Information Technology, Database Languages, SQL. Part 2: Foundations. ISO/IEC 9075:2003 (2003): Information Technology, Database Languages, SQL. Part 2: Foundations. Marcos, E., Vela, B., Cavero, M. (2004): A methodological approach for object-relational database design using UML. Informatik - Forschung und Entwicklung, Vol. 18, Num. 3-4 / April, 2004, Springer Berlin / Heidelberg, pp Marcos, E., Vela, B., Cavero, M., Cáceras (2001): Aggregation and Composition in Object- Relational Database Design. In: Proc. of ADBIS 2001, Res. Communications, A. Caplinskas, J. Eder (Eds.): pp Melton, J., Simon, A.R. (2001): SQL: Understanding Relational Language Components. Morgan Kaufmann, 2nd edition. Mlýnková, I., Pokorný, J. (2005): XML in the World of (Object-)Relational Database Systems. In: Information Systems Development Advances in Theory, Practice, and Education Vasilecas, O.; Caplinskas, A.; Wojtkowski, G.; Wojtkowski, W.; Zupancic, J.; Wrycza, S. (Eds.), Springer Science+Business Media, Inc., 2005, pp Nečaský M. (2007): XSEM - A Conceptual Model for XML. In Proc. Fourth Asia-Pacific Conference on Conceptual Modelling (APCCM2007), Ballarat, Australia. CRPIT, 67. Roddick, J. F. and Annika, H., Eds., ACS ORACLE (2000): Oracle Designer 6i: Systems Modeling. Volume 1 - Instructor Guide. Pardede, E., Rahayu, W., Taniar, D. (2004): Mapping Methods and Query for Aggregation and Association in Object-Relational Database using Collection. In: Proc. of the International Conference on Information Technology: Coding and Computing (ITCC 04), IEEE, 2004, pp Parent, Ch., Spaccapietra, S. & Zimányi, E. (2006) Conceptual Modeling for Traditional and Spatio-Temporal Applications The MADS Approach, Springer Berlin Heidelberg. Rahayu, W., Taniar, D. (2002): Preserving Aggregation in Object-Relational DBMS. In: Proc. of ADVIS 2002, T. Yakho (Ed.), LNCS 2457, pp Urban S.D. & Dietrich, S.W. (2003) Using UML Class Diagrams for a Comparative Analysis of Relational, Object-Oriented, and Object-Relational Database Mappings. In: Proc. of SIGCSE 03, February 19-23, 2003, Reno, Nevada, USA, pp Zhu, F., Zhou, J., Guan, J. and Zhou, S. (2006) Storing and Querying GML in Object- Relational Databases. In: Proc. of ACM-GIS 06, November 10 11, 2006, Arlington, Virginia, USA, ACM, pp
How To Write A Diagram
Data Model ing Essentials Third Edition Graeme C. Simsion and Graham C. Witt MORGAN KAUFMANN PUBLISHERS AN IMPRINT OF ELSEVIER AMSTERDAM BOSTON LONDON NEW YORK OXFORD PARIS SAN DIEGO SAN FRANCISCO SINGAPORE
More information14 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 informationAggregation and Composition in Object - Relational Database Design
Aggregation and Composition in Object - Relational Database Design E. Marcos, B. Vela, J. M. Cavero, P. Cáceres Kybele Research Group Rey Juan Carlos University Madrid (Spain) {cuca, b.vela, j.m.cavero,
More informationOBJECT ORIENTED EXTENSIONS TO SQL
OBJECT ORIENTED EXTENSIONS TO SQL Thomas B. Gendreau Computer Science Department University Wisconsin La Crosse La Crosse, WI 54601 gendreau@cs.uwlax.edu Abstract Object oriented technology is influencing
More informationData Modeling Basics
Information Technology Standard Commonwealth of Pennsylvania Governor's Office of Administration/Office for Information Technology STD Number: STD-INF003B STD Title: Data Modeling Basics Issued by: Deputy
More informationSchema Evolution in SQL-99 and Commercial (Object-)Relational DBMS
Schema Evolution in SQL-99 and Commercial (Object-)Relational DBMS Can Türker Swiss Federal Institute of Technology (ETH) Zurich Institute of Information Systems, ETH Zentrum CH 8092 Zurich, Switzerland
More informationIT2304: 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 informationIT2305 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 informationModern Systems Analysis and Design
Modern Systems Analysis and Design Prof. David Gadish Structuring System Data Requirements Learning Objectives Concisely define each of the following key data modeling terms: entity type, attribute, multivalued
More informationA brief overview of developing a conceptual data model as the first step in creating a relational database.
Data Modeling Windows Enterprise Support Database Services provides the following documentation about relational database design, the relational database model, and relational database software. Introduction
More informationChapter 1: Introduction. Database Management System (DBMS) University Database Example
This image cannot currently be displayed. Chapter 1: Introduction Database System Concepts, 6 th Ed. See www.db-book.com for conditions on re-use Database Management System (DBMS) DBMS contains information
More informationUSING OBJECT-RELATIONAL DATABASE TECHNOLOGY TO SOLVE PROBLEMS IN DATABASE DEVELOPMENT
USING OBJECT-RELATIONAL DATABASE TECHNOLOGY TO SOLVE PROBLEMS IN DATABASE DEVELOPMENT Ming Wang, California State University, ming.wang@calstatela.edu ABSTRACT The emergence of object-relational database
More informationLesson 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 informationDatabase Design. Marta Jakubowska-Sobczak IT/ADC based on slides prepared by Paula Figueiredo, IT/DB
Marta Jakubowska-Sobczak IT/ADC based on slides prepared by Paula Figueiredo, IT/DB Outline Database concepts Conceptual Design Logical Design Communicating with the RDBMS 2 Some concepts Database: an
More informationNormalization in OODB Design
Normalization in OODB Design Byung S. Lee Graduate Programs in Software University of St. Thomas St. Paul, Minnesota bslee@stthomas.edu Abstract When we design an object-oriented database schema, we need
More informationMapping UML Class Diagrams into Object-Relational Schemas
M.F. Golobisky, A. Vecchietti/Proc. of Argentine Symposium on Software Engineering (2005) 65-79 65 Mapping UML Class Diagrams into Object-Relational Schemas María Fernanda Golobisky and Aldo Vecchietti
More informationPart VI. Object-relational Data Models
Part VI Overview Object-relational Database Models Concepts of Object-relational Database Models Object-relational Features in Oracle10g Object-relational Database Models Object-relational Database Models
More informationOBJECTS AND DATABASES. CS121: Introduction to Relational Database Systems Fall 2015 Lecture 21
OBJECTS AND DATABASES CS121: Introduction to Relational Database Systems Fall 2015 Lecture 21 Relational Model and 1NF 2 Relational model specifies that all attribute domains must be atomic A database
More informationRelational 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 informationChapter 7 Data Modeling Using the Entity- Relationship (ER) Model
Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 7 Outline Using High-Level Conceptual Data Models for
More informationLecture Notes INFORMATION RESOURCES
Vilnius Gediminas Technical University Jelena Mamčenko Lecture Notes on INFORMATION RESOURCES Part I Introduction to Dta Modeling and MSAccess Code FMITB02004 Course title Information Resourses Course
More informationCOMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model
COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model The entity-relationship (E-R) model is a a data model in which information stored
More informationRequirement Analysis & Conceptual Database Design. Problem analysis Entity Relationship notation Integrity constraints Generalization
Requirement Analysis & Conceptual Database Design Problem analysis Entity Relationship notation Integrity constraints Generalization Introduction: Lifecycle Requirement analysis -> Text Conceptual Design
More informationDatabase Modelling in UML
Database Modelling in UML By Geoffrey Sparks, sparks@sparxsystems.com.au : http://www.sparxsystems.com.au Originally published in Methods & Tools e-newsletter : http://www.martinig.ch/mt/index.html Introduction
More informationNormalization. Functional Dependence. Normalization. Normalization. GIS Applications. Spring 2011
Normalization Normalization Normalization is a foundation for relational database design Systematic approach to efficiently organize data in a database GIS Applications Spring 2011 Objectives Minimize
More informationDatabase Design Overview. Conceptual Design ER Model. Entities and Entity Sets. Entity Set Representation. Keys
Database Design Overview Conceptual Design. The Entity-Relationship (ER) Model CS430/630 Lecture 12 Conceptual design The Entity-Relationship (ER) Model, UML High-level, close to human thinking Semantic
More informationHow To Improve Performance In A Database
Some issues on Conceptual Modeling and NoSQL/Big Data Tok Wang Ling National University of Singapore 1 Database Models File system - field, record, fixed length record Hierarchical Model (IMS) - fixed
More informationA COMPARISON OF OBJECT-RELATIONAL AND RELATIONAL DATABASES A Thesis Presented to the Faculty of California Polytechnic State University San Luis Obispo In Partial Fulfillment of the Requirements for the
More informationThe process of database development. Logical model: relational DBMS. Relation
The process of database development Reality (Universe of Discourse) Relational Databases and SQL Basic Concepts The 3rd normal form Structured Query Language (SQL) Conceptual model (e.g. Entity-Relationship
More informationFundamentals of Database Design
Fundamentals of Database Design Zornitsa Zaharieva CERN Data Management Section - Controls Group Accelerators and Beams Department /AB-CO-DM/ 23-FEB-2005 Contents : Introduction to Databases : Main Database
More informationLecture 12: Entity Relationship Modelling
Lecture 12: Entity Relationship Modelling The Entity-Relationship Model Entities Relationships Attributes Constraining the instances Cardinalities Identifiers Generalization 2004-5 Steve Easterbrook. This
More informationOverview RDBMS-ORDBMS- OODBMS
Overview RDBMS-ORDBMS- OODBMS 1 Database Models Transition Hierarchical Data Model Network Data Model Relational Data Model ER Data Model Semantic Data Model Object-Relational DM Object-Oriented DM 2 Main
More informationDemystified CONTENTS Acknowledgments xvii Introduction xix CHAPTER 1 Database Fundamentals CHAPTER 2 Exploring Relational Database Components
Acknowledgments xvii Introduction xix CHAPTER 1 Database Fundamentals 1 Properties of a Database 1 The Database Management System (DBMS) 2 Layers of Data Abstraction 3 Physical Data Independence 5 Logical
More informationChapter 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 informationDATABASE MANAGEMENT SYSTEMS. Question Bank:
DATABASE MANAGEMENT SYSTEMS Question Bank: UNIT 1 1. Define Database? 2. What is a DBMS? 3. What is the need for database systems? 4. Define tupule? 5. What are the responsibilities of DBA? 6. Define schema?
More informationIMPLEMENTING SPATIAL DATA WAREHOUSE HIERARCHIES IN OBJECT-RELATIONAL DBMSs
IMPLEMENTING SPATIAL DATA WAREHOUSE HIERARCHIES IN OBJECT-RELATIONAL DBMSs Elzbieta Malinowski and Esteban Zimányi Computer & Decision Engineering Department, Université Libre de Bruxelles 50 av.f.d.roosevelt,
More informationLogical Schema Design: The Relational Data Model
Logical Schema Design: The Relational Data Model Basics of the Relational Model From Conceptual to Logical Schema Logical Schema Design Select data model Hierarchical data model: hierarchies of record
More informationUSING UML FOR OBJECT-RELATIONAL DATABASE SYSTEMS DEVELOPMENT: A FRAMEWORK
USING UML FOR OBJECT-RELATIONAL DATABASE SYSTEMS DEVELOPMENT: A FRAMEWORK Ming Wang, California State University, ming.wang@calstatela.edu ABSTRACT Data model of object-relational databases (ORDBs) is
More informationConceptual Design Using the Entity-Relationship (ER) Model
Conceptual Design Using the Entity-Relationship (ER) Model Module 5, Lectures 1 and 2 Database Management Systems, R. Ramakrishnan 1 Overview of Database Design Conceptual design: (ER Model is used at
More informationCSE 132A. Database Systems Principles
CSE 132A Database Systems Principles Prof. Victor Vianu 1 Data Management An evolving, expanding field: Classical stand-alone databases (Oracle, DB2, SQL Server) Computer science is becoming data-centric:
More informationData Modeling. Database Systems: The Complete Book Ch. 4.1-4.5, 7.1-7.4
Data Modeling Database Systems: The Complete Book Ch. 4.1-4.5, 7.1-7.4 Data Modeling Schema: The structure of the data Structured Data: Relational, XML-DTD, etc Unstructured Data: CSV, JSON But where does
More informationNormal Form vs. Non-First Normal Form
Normal Form vs. Non-First Normal Form Kristian Torp Department of Computer Science Aalborg Univeristy www.cs.aau.dk/ torp torp@cs.aau.dk September 1, 2009 daisy.aau.dk Kristian Torp (Aalborg University)
More informationHandling Unstructured Data Type in DB2 and Oracle
Alexander P. Pons, Hassan Aljifri Handling Unstructured Data Type in DB2 and Oracle Alexander P. Pons Computer Information Systems, University of Miami, 421 Jenkins Building, Coral Gables, FL 33146 Phone:
More informationThe Relational Model. Ramakrishnan&Gehrke, Chapter 3 CS4320 1
The Relational Model Ramakrishnan&Gehrke, Chapter 3 CS4320 1 Why Study the Relational Model? Most widely used model. Vendors: IBM, Informix, Microsoft, Oracle, Sybase, etc. Legacy systems in older models
More informationDatabases and BigData
Eduardo Cunha de Almeida eduardo.almeida@uni.lu Outline of the course Introduction Database Systems (E. Almeida) Distributed Hash Tables and P2P (C. Cassagnes) NewSQL (D. Kim and J. Meira) NoSQL (D. Kim)
More information2. Conceptual Modeling using the Entity-Relationship Model
ECS-165A WQ 11 15 Contents 2. Conceptual Modeling using the Entity-Relationship Model Basic concepts: entities and entity types, attributes and keys, relationships and relationship types Entity-Relationship
More informationSQL:2003 Has Been Published
SQL:2003 Has Been Published Andrew Eisenberg IBM, Westford, MA 01886 andrew.eisenberg@us.ibm.com Jim Melton Oracle Corp., Sandy, UT 84093 jim.melton@acm.org Krishna Kulkarni IBM, San Jose, CA 94151 krishnak@us.ibm.com
More informationBridge 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 informationCSC 742 Database Management Systems
CSC 742 Database Management Systems Topic #4: Data Modeling Spring 2002 CSC 742: DBMS by Dr. Peng Ning 1 Phases of Database Design Requirement Collection/Analysis Functional Requirements Functional Analysis
More informationDatabase System Concepts
s Design Chapter 1: Introduction Departamento de Engenharia Informática Instituto Superior Técnico 1 st Semester 2008/2009 Slides (fortemente) baseados nos slides oficiais do livro c Silberschatz, Korth
More informationDatabase Auditing Design on Historical Data
ISBN 978-952-5726-09-1 (Print) Proceedings of the Second International Symposium on Networking and Network Security (ISNNS 10) Jinggangshan, P. R. China, 2-4, April. 2010, pp. 275-281 Database Auditing
More informationChapter 9: Object-Based Databases
Chapter 9: Object-Based Databases Database System Concepts See www.db-book.com for conditions on re-use Database System Concepts Chapter 9: Object-Based Databases Complex Data Types and Object Orientation
More informationA MEDIATION LAYER FOR HETEROGENEOUS XML SCHEMAS
A MEDIATION LAYER FOR HETEROGENEOUS XML SCHEMAS Abdelsalam Almarimi 1, Jaroslav Pokorny 2 Abstract This paper describes an approach for mediation of heterogeneous XML schemas. Such an approach is proposed
More informationOracle8i Spatial: Experiences with Extensible Databases
Oracle8i Spatial: Experiences with Extensible Databases Siva Ravada and Jayant Sharma Spatial Products Division Oracle Corporation One Oracle Drive Nashua NH-03062 {sravada,jsharma}@us.oracle.com 1 Introduction
More informationAS LEVEL Computer Application Databases
AS LEVEL Computer Application Databases YLLSS In the syllabus, we have Applications of databases in society Students should be aware of the uses and applications of databases in everyday life (e.g. the
More informationwww.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 informationThe Relational Model. Why Study the Relational Model? Relational Database: Definitions. Chapter 3
The Relational Model Chapter 3 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Why Study the Relational Model? Most widely used model. Vendors: IBM, Informix, Microsoft, Oracle, Sybase,
More informationThe Relational Model. Why Study the Relational Model? Relational Database: Definitions
The Relational Model Database Management Systems, R. Ramakrishnan and J. Gehrke 1 Why Study the Relational Model? Most widely used model. Vendors: IBM, Microsoft, Oracle, Sybase, etc. Legacy systems in
More informationData Warehouse Snowflake Design and Performance Considerations in Business Analytics
Journal of Advances in Information Technology Vol. 6, No. 4, November 2015 Data Warehouse Snowflake Design and Performance Considerations in Business Analytics Jiangping Wang and Janet L. Kourik Walker
More informationChapter 5: Logical Database Design and the Relational Model Part 2: Normalization. Introduction to Normalization. Normal Forms.
Chapter 5: Logical Database Design and the Relational Model Part 2: Normalization Modern Database Management 6 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden Robert C. Nickerson ISYS
More informationOutline. Data Modeling. Conceptual Design. ER Model Basics: Entities. ER Model Basics: Relationships. Ternary Relationships. Yanlei Diao UMass Amherst
Outline Data Modeling Yanlei Diao UMass Amherst v Conceptual Design: ER Model v Relational Model v Logical Design: from ER to Relational Slides Courtesy of R. Ramakrishnan and J. Gehrke 1 2 Conceptual
More informationDatabase Design Patterns. Winter 2006-2007 Lecture 24
Database Design Patterns Winter 2006-2007 Lecture 24 Trees and Hierarchies Many schemas need to represent trees or hierarchies of some sort Common way of representing trees: An adjacency list model Each
More informationINTEROPERABILITY IN DATA WAREHOUSES
INTEROPERABILITY IN DATA WAREHOUSES Riccardo Torlone Roma Tre University http://torlone.dia.uniroma3.it/ SYNONYMS Data warehouse integration DEFINITION The term refers to the ability of combining the content
More informationContents RELATIONAL DATABASES
Preface xvii Chapter 1 Introduction 1.1 Database-System Applications 1 1.2 Purpose of Database Systems 3 1.3 View of Data 5 1.4 Database Languages 9 1.5 Relational Databases 11 1.6 Database Design 14 1.7
More informationSQL 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 informationLightweight Data Integration using the WebComposition Data Grid Service
Lightweight Data Integration using the WebComposition Data Grid Service Ralph Sommermeier 1, Andreas Heil 2, Martin Gaedke 1 1 Chemnitz University of Technology, Faculty of Computer Science, Distributed
More informationIntroduction to normalization. Introduction to normalization
Introduction to normalization Lecture 4 Instructor Anna Sidorova Agenda Presentation Review of relational models, in class exersise Introduction to normalization In-class exercises Discussion of HW2 1
More information5.5 Copyright 2011 Pearson Education, Inc. publishing as Prentice Hall. Figure 5-2
Class Announcements TIM 50 - Business Information Systems Lecture 15 Database Assignment 2 posted Due Tuesday 5/26 UC Santa Cruz May 19, 2015 Database: Collection of related files containing records on
More informationA Tool for Generating Relational Database Schema from EER Diagram
A Tool for Generating Relational Schema from EER Diagram Lisa Simasatitkul and Taratip Suwannasart Abstract design is an important activity in software development. EER diagram is one of diagrams, which
More informationRelational Databases
Relational Databases Jan Chomicki University at Buffalo Jan Chomicki () Relational databases 1 / 18 Relational data model Domain domain: predefined set of atomic values: integers, strings,... every attribute
More informationDesigning Databases. Introduction
Designing Databases C Introduction Businesses rely on databases for accurate, up-to-date information. Without access to mission critical data, most businesses are unable to perform their normal daily functions,
More information1 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 informationChapter 8 The Enhanced Entity- Relationship (EER) Model
Chapter 8 The Enhanced Entity- Relationship (EER) Model Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 8 Outline Subclasses, Superclasses, and Inheritance Specialization
More informationInstant SQL Programming
Instant SQL Programming Joe Celko Wrox Press Ltd. INSTANT Table of Contents Introduction 1 What Can SQL Do for Me? 2 Who Should Use This Book? 2 How To Use This Book 3 What You Should Know 3 Conventions
More informationAn Introduction to Relational Database Management System
History The concept of relational databases was first described by Edgar Frank Codd (almost exclusively referenced as E. F. Codd in technical literature) in the IBM research report RJ599, dated August
More informationCS352 Lecture - Object-Based Databases
CS352 Lecture - Object-Based Databases Objectives: Last revised 10/7/08 1. To elucidate fundamental differences between OO and the relational model 2. To introduce the idea of adding persistence to an
More informationBCA. 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 informationFundamentals of Database System
Fundamentals of Database System Chapter 4 Normalization Fundamentals of Database Systems (Chapter 4) Page 1 Introduction To Normalization In general, the goal of a relational database design is to generate
More information7.1 The Information system
Chapter 7. Database Planning, Design and Administration Last few decades have seen proliferation of software applications, many requiring constant maintenance involving: correcting faults, implementing
More informationChapter 5. SQL: Queries, Constraints, Triggers
Chapter 5 SQL: Queries, Constraints, Triggers 1 Overview: aspects of SQL DML: Data Management Language. Pose queries (Ch. 5) and insert, delete, modify rows (Ch. 3) DDL: Data Definition Language. Creation,
More informationADVANCED DATA STRUCTURES FOR SURFACE STORAGE
1Department of Mathematics, Univerzitni Karel, Faculty 22, JANECKA1, 323 of 00, Applied Pilsen, Michal, Sciences, Czech KARA2 Republic University of West Bohemia, ADVANCED DATA STRUCTURES FOR SURFACE STORAGE
More informationThe Entity-Relationship Model
The Entity-Relationship Model 221 After completing this chapter, you should be able to explain the three phases of database design, Why are multiple phases useful? evaluate the significance of the Entity-Relationship
More informationIntroduction to Computing. Lectured by: Dr. Pham Tran Vu t.v.pham@cse.hcmut.edu.vn
Introduction to Computing Lectured by: Dr. Pham Tran Vu t.v.pham@cse.hcmut.edu.vn Databases The Hierarchy of Data Keys and Attributes The Traditional Approach To Data Management Database A collection of
More informationSEMANTIC-BASED AUTHORING OF TECHNICAL DOCUMENTATION
SEMANTIC-BASED AUTHORING OF TECHNICAL DOCUMENTATION R Setchi, Cardiff University, UK, Setchi@cf.ac.uk N Lagos, Cardiff University, UK, LagosN@cf.ac.uk ABSTRACT Authoring of technical documentation is a
More informationDatabases Model the Real World. The Entity- Relationship Model. Conceptual Design. Steps in Database Design. ER Model Basics. ER Model Basics (Contd.
The Entity- Relationship Model R &G - Chapter 2 A relationship, I think, is like a shark, you know? It has to constantly move forward or it dies. And I think what we got on our hands is a dead shark. Woody
More informationData Hierarchy. Traditional File based Approach. Hierarchy of Data for a Computer-Based File
Management Information Systems Data and Knowledge Management Dr. Shankar Sundaresan (Adapted from Introduction to IS, Rainer and Turban) LEARNING OBJECTIVES Recognize the importance of data, issues involved
More informationRelational Database Concepts
Relational Database Concepts IBM Information Management Cloud Computing Center of Competence IBM Canada Labs 1 2011 IBM Corporation Agenda Overview Information and Data Models The relational model Entity-Relationship
More informationLOGICAL DATABASE DESIGN
MODULE 8 LOGICAL DATABASE DESIGN OBJECTIVE QUESTIONS There are 4 alternative answers to each question. One of them is correct. Pick the correct answer. Do not guess. A key is given at the end of the module
More informationDBMS / 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 informationPart 7: Object Oriented Databases
Part 7: Object Oriented Databases Junping Sun Database Systems 7-1 Database Model: Object Oriented Database Systems Data Model = Schema + Constraints + Relationships (Operations) A logical organization
More informationInformation Systems 2. 1. Modelling Information Systems I: Databases
Information Systems 2 Information Systems 2 1. Modelling Information Systems I: Databases Lars Schmidt-Thieme Information Systems and Machine Learning Lab (ISMLL) Institute for Business Economics and Information
More informationObject-Oriented & Object-Relational DBMS. Example App: Asset Management. An Asset Management Scenario. Object-Relational Databases
Object-Oriented & Object-Relational DBMS R & G (& H) Chapter 23 You know my methods, Watson. Apply them. -- A.Conan Doyle, The Memoirs of Sherlock Holmes Motivation Relational model (70 s): clean and simple
More informationThe Relational Model. Why Study the Relational Model?
The Relational Model Chapter 3 Instructor: Vladimir Zadorozhny vladimir@sis.pitt.edu Information Science Program School of Information Sciences, University of Pittsburgh 1 Why Study the Relational Model?
More informationRelational 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 informationAlejandro Vaisman Esteban Zimanyi. Data. Warehouse. Systems. Design and Implementation. ^ Springer
Alejandro Vaisman Esteban Zimanyi Data Warehouse Systems Design and Implementation ^ Springer Contents Part I Fundamental Concepts 1 Introduction 3 1.1 A Historical Overview of Data Warehousing 4 1.2 Spatial
More informationDesigning a Database Schema
Week 10: Database Design Database Design From an ER Schema to a Relational One Restructuring an ER schema Performance Analysis Analysis of Redundancies, Removing Generalizations Translation into a Relational
More informationObject Relational Database Mapping. Alex Boughton Spring 2011
+ Object Relational Database Mapping Alex Boughton Spring 2011 + Presentation Overview Overview of database management systems What is ORDM Comparison of ORDM with other DBMSs Motivation for ORDM Quick
More informationCSE 233. Database System Overview
CSE 233 Database System Overview 1 Data Management An evolving, expanding field: Classical stand-alone databases (Oracle, DB2, SQL Server) Computer science is becoming data-centric: web knowledge harvesting,
More informationGeodatabase Programming with SQL
DevSummit DC February 11, 2015 Washington, DC Geodatabase Programming with SQL Craig Gillgrass Assumptions Basic knowledge of SQL and relational databases Basic knowledge of the Geodatabase We ll hold
More information