., FUNDAMENTALS OF
`FourthEdition DATABASE SYSTEMS
`
`Enfish, LLC; IPR2014-00574
`Exhibit 2234
`Page 1 of 4
`
`

`

`FUNDAMENTALS OF
`Fourth Edition DATABASE SYSTEMS
`
`Ramez Elmasri
`Department of Computer Science Engineering
`University of Texas at Arlington
`
`Shamkant B. N avathe
`College of Computing
`Georgia Institute of Technology
`
`••.~"-
`
`. .
`
`Boston San Francisco New York
`London Toronto Sydney Tokyo Singapore Madrid
`Mexico City Munich Paris Cape Town Hong Kong Montreal
`
`Enfish, LLC; IPR2014-00574
`Exhibit 2234
`Page 2 of 4
`
`

`

`Sponsoring Editor:
`Project Editor:
`Senior Production Supervisor:
`Production Services:
`Cover Designer:
`Marketing Manager:
`Senior Marketing Coordinator:
`Print Buyer:
`
`Cover image © 2003 Digital Vision
`
`Maite Suarez-Rivas
`Katherine Harutunian
`Juliet Silveri
`Argosy Publishing
`Beth Anderson
`Nathan Schultz
`Lesly Hershman
`Caroline Fell
`
`Access the latest information about Addison-Wesley titles from our World Wide Web site:
`http://www.aw.com/cs
`
`Figure 12.14 is a logical data model diagram definition in Rational Rose®. Figure 12.15 is a graphi(cid:173)
`cal data model diagram in Rational Rose'", Figure 12.17 is the company database class diagram
`drawn in Rational Rose®. IBM® has acquired Rational Rose®.
`
`Many of the designations used by manufacturers and sellers to distinguish their products are claimed
`as trademarks. Where those designations appear in this book, and Addison-Wesley was aware of a
`trademark claim, the designations have been printed in initial caps or all caps.
`
`The programs and applications presented in this book have been included for their instructional
`value. They have been tested with care, but are not guaranteed for any particular purpose. The pub(cid:173)
`lisher does not offer any warranties or representations, nor does it accept any liabilities with respect
`to the programs or applications.
`
`Library of Congress Cataloging-in-Publication Data
`
`Elmasri, Ramez.
`Fundamentals of database systems / Ramez Elmasri, Shamkant B.
`Navathe.--4th ed.
`p. cm.
`Includes bibliographical references and index.
`ISBN 0-321-12226-7
`I. Database management. 1. Navathe, Sham. II. Title.
`
`QA 76.9.03E57 2003
`005.74--dc21
`
`ISBN 0-321-12226-7
`
`2003057734
`
`For information on obtaining permission for the use of material from this work, please submit a writ(cid:173)
`ten request to Pearson Education, Inc., Rights and Contracts Department, 75 Arlington St., Suite
`300, Boston, MA 02116 or fax your request to 617-848-7047.
`
`Copyright © 2004 by Pearson Education, Inc.
`
`All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or
`transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or other(cid:173)
`wise, without the prior written permission of the publisher. Printed in the United States of America.
`
`1 2 3 4 5 6 7 8 9 lO-HT-06050403
`
`Enfish, LLC; IPR2014-00574
`Exhibit 2234
`Page 3 of 4
`
`

`

`644 I Chapter 20 Concepts for Object Databases
`
`20.2.1 Object Identity
`An 00 database system provides a unique identity to each independent object stored in the
`database. This unique identity is typically implemented via a unique, system-generated object
`identifier, or DID. The value of an OID is not visible to the external user, but it is used
`internally by the system to identify each object uniquely and to create and manage inter(cid:173)
`object references. The OlD can be assigned to program variables of the appropriate type
`when needed.
`The main property required of an OID is that it be immutable; that is, the OlD value
`of a particular object should not change. This preserves the identity of the real-world
`object being represented. Hence, an 00 database system must have some mechanism for
`generating OIDs and preserving the immutability property. It is also desirable that each
`OID be used only once; that is, even if an object is removed from the database, its OID
`should not be assigned to another object. These two properties imply that the OID
`should not depend on any attribute values of the object, since the value of an attribute
`may be changed or corrected. It is also generally considered inappropriate to base the
`OID on the physical address of the object in storage, since the physical address can
`change after a physical reorganization of the database. However, some systems do use the
`physical address as OID to increase the efficiency of object retrieval. If the physical
`address of the object changes, an indirect pointer can be placed at the former address,
`which gives the new physical location of the object. It is more common to use long
`integers as OIDs and then to use some form of hash table to map the OID value to the
`current physical address of the object in storage.
`Some early 00 data models required that everything-from a simple value to a
`complex object-be represented as an object; hence, every basic value, such as an integer,
`string, or Boolean value, has an OID. This allows two basic values to have different OIDs,
`which can be useful in some cases. For example, the integer value 50 can be used sometimes
`to mean a weight in kilograms and at other times to mean the age of a person. Then, two
`basic objects with distinct OIDs could be created, but both objects would represent the
`integer value 50. Although useful as a theoretical model, this is not very practical, since it
`may lead to the generation of too many OIDs. Hence, most 00 database systems allow for
`the representation of both objects and values. Every object must have an immutable OID,
`whereas a value has no OIDand just stands for itself. Hence, a value is typically stored within
`an object and cannot be referenced from other objects. In some systems, complex structured
`values can also be created without having a corresponding OID if needed.
`
`20.2.2 Object Structure
`In 00 databases, the state (current value) of a complex object may be constructed from
`other objects (or other values) by using certain type constructors. One formal way of rep(cid:173)
`resenting such objects is to view each object as a triple (i, c, v), where i is a unique object
`identifier (the OlD), c is a type constructor12 (that is, an indication of how the object state is
`
`12. This is different from the constructor operation that is used in c++ and other OOPLs to create
`new objects.
`
`Enfish, LLC; IPR2014-00574
`Exhibit 2234
`Page 4 of 4
`
`