Scribd
Upload
146 views3 pages

U5T1 - Mapping EER To ODB Schema

The document outlines the steps for mapping an Enhanced Entity-Relationship (EER) schema to an Object Database Management System (ODBMS) schema. It details the creation of ODL classes for EER entities, the handling of relationships, and the inclusion of operations and constraints. Additionally, it addresses the mapping of weak entities, categories, and n-ary relationships, providing a comprehensive guide for database design based on EER principles.

Uploaded by

joyalprincess
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
146 views3 pages

U5T1 - Mapping EER To ODB Schema

The document outlines the steps for mapping an Enhanced Entity-Relationship (EER) schema to an Object Database Management System (ODBMS) schema. It details the creation of ODL classes for EER entities, the handling of relationships, and the inclusion of operations and constraints. Additionally, it addresses the mapping of weak entities, categories, and n-ary relationships, providing a comprehensive guide for database design based on EER principles.

Uploaded by

joyalprincess
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 3

Mapping EER to ODB schema

It is relatively straight forward to design the type declarations of object classes for an

ODBMS from an EER schema that contains neither categories nor n-ary relation

Step 1

 Create an ODL class for each EER entity type or subclass.

 The type of the ODL class should include all the attributes of the EER class. Multi valued
attributes are typically declared by using the set, bag, or list constructors.

 If the values of the multi valued attribute for an object should be ordered, the list constructor is
chosen; if duplicates are allowed, the bag constructor should be chosen; otherwise, the set
constructor is chosen.

 Composite attributes are mapped into a tuple constructor (by using a struct declaration in ODL).

 Declare an extent for each class, and specify any key attributes as keys of the extent.(This is
possible only if an extent facility and key constraint declarations are available in the ODBMS.)

Step 2

 Add relationship properties or reference attributes for each binary relationship into the ODL
classes that participate in the relationship. These may be created in one or both directions.

 If a binary relationship is represented by references in both directions, declare the references to


be relationship properties that are inverses of one another, if such a facility exists.

 If a binary relationship is represented by a reference in only one direction, declare the reference
to be an attribute in the referencing class whose type is the referenced class name.

 Depending on the cardinality ratio of the binary relationship, the relationship properties or
reference attributes may be single-valued or collection types.

 They will be single valued for binary relationships in the 1:1 or N:1 direction; they are collection
types (set valued or list-valued) for relationships in the 1: N or M: N direction. An alternative
way to map binary M: N relationships is discussed in step 7.

 If relationship attributes exist, a tuple constructor (struct) can be used to create a structure of
the form < reference, relationship attributes >, which may be included instead of the reference
attribute.

 However, this does not allow the use of the inverse constraint. Additionally, if this choice is
represented in both directions, the attribute values will be represented twice, creating
redundancy.
 This implicitly uses a tuple constructor at the top level of the type declaration, but in general,
the tuple constructor is not explicitly shown in the ODL class declarations.

 Further analysis of the application domain is needed to decide which constructor to use because
this information is not available from the EER schema.

 The ODL standard provides for the explicit definition of inverse relationships. Some ODBMS
products may not provide this support; in such cases, programmers must maintain every
relationship explicitly by coding the methods that update the objects appropriately. The decision
whether to use set or list is not available from the EER schema and must be determine

Object and Object-Relational Databases

Step 3

 Include appropriate operations for each class. These are not available from the EER schema and
must be added to the database design by referring to the original requirements.

 A constructor method should include program code that checks any constraints that must hold
when a new object is created. A destructor method should check any constraints that may be
violated when an object is deleted. Other methods should include any further constraint checks
that are relevant.

Step 4

 An ODL class that corresponds to a subclass in the EER schema inherits (via extends) the type
and methods of its super class in the ODL schema.

 Its specific (nonintegrated) attributes, relationship references, and operations are specified, as
discussed in steps 1, 2, and 3.

Step 5

 Weak entity types can be mapped in the same way as regular entity types. An alternative
mapping is possible for weak entity types that do not participate in any relationships except
their identifying relationship; these can be mapped as though they were composite multi valued
attributes of the owner entity type, by using the set < struct < ... >> or list < struct < ... >>
constructors.

 The attributes of the weak entity are included in the struct < ... > construct, which corresponds
to a tuple constructor.

 Attributes are mapped as discussed in steps 1 and 2.


Step 6

 Categories (union types) in an EER schema are difficult to map to ODL.

 It is possible to create a mapping similar to the EER-to-relational mapping by declaring a class to


represent the category and defining 1:1 relationship between the category and each of its super
classes. Another option is to use a union type, if it is available.

Step 7

 An n-any relationship with degree n > 2 can be mapped into a separate class, with appropriate
references to each participating class. These references are based on mapping a 1: N
relationship from each class that represents a participating entity type to the class that
represents the n-any relationship. An M:Nbinary relationship, especially if it contains
relationship attributes, may also use this mapping option, if desired

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy