DOCSLIB.ORG

The Integrated Data Model: a Database Perspective

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Integrated Data Model: a Database Perspective The Integrated Data Model: A Database Perspective David Beech and J. Samuel Feldman Computer Research Center, Hewlett-Packard Company Palo Alto, California 94394, USA Abstract fundamental to each discipline. Database systems are explicit about this, but in fact The integrated Data Model integrates every programming language and every artificial concepts from three information disciplines: intelligence system also embodies a data model. database systems, artificial intelligence, and We propose that a single data model can combine programming languages. Key concepts are the best aspects of all three disciplines and those of abstract type (allowing multiple remove many of the shortcomings of each. implementations), object (possibly having multiple types), and relation (definable by 1 .l Storing New and Different Types of Data logical formulas). This paper provides a brief overview of the model from a database Current database systems each support their perspective. own static set of built-in datatypes. Although work is continuing on extending the implementations of these systems so that 1. INTRODUCTION “unformatted” data may be stored, such measures are essentially patches. The Integrated Data Model (IDM) provides a more general and flexible foundation for the One important consequence of our application of manipulation of information than models recent programming language ideas to databases underlying traditional database management is that new datatypes can be defined as needed, systems. The facilities provided by the model and values of these types may be stored in the can be employed not only for database queries, database in the same way as other kinds of e updates, and report generation, but also for data. This is accomplished in our design by managing the arbitrary data structures used by our treatment of datatypes as abstract objects, systems programs and application programs. which provides a formal framework for defining Moreover, because this occurs in a database and using new types dynamically. Another way setting, the ability to share this information of looking at this capability is that programs concurrently with other users and to distribute may use the same kinds of data structures for information among different sites is provided in persistent data as for temporary data. the same way as for the more conventional kinds of data routinely stored in databases. 1.2 Natural User Interfaces IDM takes data abstraction as the fundamental The intent of the design is to provide a model underlying idea, and draws together some that corresponds naturally to the way we concepts previously employed for database perceive information, while still providing systems, artificial intelligence applications, and sufficient power and allowing for efficient programming languages. A data model is access. We accomplish this partially with a form of entity-relationship model [Childs 88; Abrial 74; Chen 761. Models of this genre are increasingly being employed for user interfaces and database design tools [Dahl & Bubenko 82; Olle et d. 82; Wong t Kuo 821, because of their suitability for representing the user’s conceptual model. Attempts to extend the relational model to introduce an entity concept seem awkward [Codd 791. (We have in fact designed an English-like database manipulation language for our model as one example of a natural user interface.) 302 2. OBJECTS AND TYPES l Everything in an IDM database is an object. The central, pervasive concept in IDM is that of the object. Everything in an IDM database is l Each object is an instance of one or more an object; even the database is itself an object. types. The simple data abstraction idea is extended in two significant ways: l Each type defines the operations that are available for its instances. l An object may have more than one type. l The only action available in IDM is to l An object may gain and lose types invoke an operation on an object. dynamically. We must now clarify the meaning of “type”. 3. RELATIONS Each type groups together objects that behave similarly. One might define types such as Relations, like databases, types, and Employee, Account, Document, or Image, for operations, are objects-each relation is an example. Every object is said to be an instance instance of the predefined type Relation. In of one or more such types. many object-oriented models, information is carried in the attributes, properties, or As in a programming language with data components of objects. In our model all such abstraction, the type provides a set of information is regarded as associating one object operations that define the way instances of that to another, and is expressed by relations. For type may be manipulated. Since an object may example, one might define a relation between have more than one type, corresponding to the employees and their addresses; or between different roles it may be viewed as playing, it employees and their departments; or between may be manipulated via the operations of several documents, their creators, and their creation types. dates (these types are termed the domains of the relation). As an example, suppose that Jones is a person, an employee and a pilot. If Jones later becomes The association of a particular employee with a a manager, the type “manager” can be added as particular department is represented by a shown. relationship. The relation represents the concept of department membership, by defining Jones Jones the relationships that are valid at any given ------------ ------------ moment. 1 person j ! person 1 I__________! ;---------- 3.1 Manipulation of Relations / employee j ’ employee I ----------I !---------- The type Relation provides operations to find, / pilot / I pilot insert, update, or delete specific relationships. ---_-------- ---------- For example, a relation can be queried to find I manager 1 all the employees in a given department, or, --------e-m- since relations in our model are inherently symmetrical, the department of a given Each type provides a separate set of operations employee. that can be invoked on Jones. For example, among the operations defined by the Person type It is sometimes more natural to carry out these might be GetAddress and SetAddress, the manipulations as operations on the instances of Employee type GetManager and SetManager, and the domains. For example, one might want to the Pilot type GetLicenseNumber. Each type ask a particular employee object what its added to an object supplies specific additional department is. This is easily accomplished by capabilities, by providing additional operations. providing operations on Employees such as “GetDepartment”, “SetDepartment”, etc., which Types are full-fledged objects. Certain types simply access the proper relation (compare with are predefined by the model; other types can be the functional data model [Shipman 811). defined by users. The latter is accomplished by creating a Type object and binding operations to 3.2 Generality of Relations it; the operations are written (in one of several programming languages) as functions which take Objects such as paragraphs, images, and parameters and return a single result. documents can be arbitrarily complex structures Operations are treated as objects also. (the operations defined by their respective types define the legal interfaces for manipulating To summarize our concept of an object: them). Since there is no restriction on which types constitute the domains of a relation, such objects may be related by the same mechanism 303 described for simpler objects such as employees, approach in the design of these features- departments, and addresses. Thus, one could although, of course, they will be expressed in create relations to express the correspondence terms of operations provided by predefined between paragraphs and images, between artists types. and the images they have created, or between employees and the voice messages sent to them. REFERENCES 4. OTHER IMPORTANT FEATURES [Abrial 741 Abrial, J.R. Data Semantics. In Our model supports multiple implementations of [Klimbie 741, l-59. the same type. For example, one might define a HashTable type with several alternative [Cattell 831 Cattell, R.G.G. Design and implementations; users of a particular hash table Implementation of a Relationship-Entity-Datum object need not know which kind of hash table it Data Model. Xerox Palo Alto Research is, only that it responds to the same interface. Center, Computer Science Laboratory CSL-83-4 (1983). Relations may be derived-instead of storing the actual relationships, they are computed as [Chan et al. 821 Chan, A.; Danberg, S.; needed. Because relations are objects with a Fox, S.; Lin, W.; Nori, A.; and Ries, D. specific fixed interface, users of the relation do Storage and Access Structures to Support a not need to distinguish between derived and Semantic Data Model, Proc. 8th Int. Conf. stored relations-at least when making on Very Large Data Bases (1982 September), retrievals. The view update problem may be 122-130. addressed within the framework of the model by taking advantage of multiple implementations to [Chen 761 Chen, P.P.-s. The Entity- provide special update procedures. Relationship Model-Toward a Unified View of Data. ACM Trans. on Database Syst. 1: 1 As in other similar models, types may be (1976 March), 9-36. arranged into a hierarchy (actually a lattice, since a type may have more than one parent). [Childs 681 Childs, 0. L. Description of a If Employee is a subtype of Person, for Set-Theoretic Data Structure. Proc. FJCC . example, creation of an employee object will 1968, 557. North Holland. automatically include the Person type. The type lattice facilitates compile-time operation name [Codd 791 Codd, E.F. Extending the resolution; for example, a reference to Database Relational Model to Capture More “GetName” on an employee can be bound at Meaning. ACM Trans. on Database Syst. compile time to the “GetName” operation defined 4:4 (1979 December), 397-434. by type Person. [Dahl & Bubenko 821 Dahl, R.; and Bubenko, J.
Load more

Recommended publications
  • Arcgis Marine Data Model Reference
    ArcGIS Marine Data Model Reference ArcGIS Marine Data Model (June 2003) This document provides an Dawn J. Wright, Oregon State U. overview of the ArcGIS Marine Patrick N. Halpin, Duke U. Data Model. This model focuses on Michael Blongewicz, DHI important features of the ocean realm, both natural and manmade, Steve Grisé, ESRI Redlands with a view towards the many Joe Breman, ESRI Redlands applications of marine GIS data. ArcGIS Data Models TABLE OF CONTENTS Acknowledgements ................................................................................................................... 4 Introduction ............................................................................................................................... 5 Why a Marine Data Model?.................................................................................................... 6 Intended Audience and Scope of the Model............................................................................ 8 The Process of Building a Data Model ..................................................................................... 10 Final Data Model Content, Purpose and Use........................................................................ 14 Data Model Description ........................................................................................................... 16 Overview ............................................................................................................................. 16 Conceptual Framework....................................................................................................
    [Show full text]
  • Data Model Standards and Guidelines, Registration Policies And
    Data Model Standards and Guidelines, Registration Policies and Procedures Version 3.2 ● 6/02/2017 Data Model Standards and Guidelines, Registration Policies and Procedures Document Version Control Document Version Control VERSION D ATE AUTHOR DESCRIPTION DRAFT 03/28/07 Venkatesh Kadadasu Baseline Draft Document 0.1 05/04/2007 Venkatesh Kadadasu Sections 1.1, 1.2, 1.3, 1.4 revised 0.2 05/07/2007 Venkatesh Kadadasu Sections 1.4, 2.0, 2.2, 2.2.1, 3.1, 3.2, 3.2.1, 3.2.2 revised 0.3 05/24/07 Venkatesh Kadadasu Incorporated feedback from Uli 0.4 5/31/2007 Venkatesh Kadadasu Incorporated Steve’s feedback: Section 1.5 Issues -Change Decide to Decision Section 2.2.5 Coordinate with Kumar and Lisa to determine the class words used by XML community, and identify them in the document. (This was discussed previously.) Data Standardization - We have discussed on several occasions the cross-walk table between tabular naming standards and XML. When did it get dropped? Section 2.3.2 Conceptual data model level of detail: changed (S) No foreign key attributes may be entered in the conceptual data model. To (S) No attributes may be entered in the conceptual data model. 0.5 6/4/2007 Steve Horn Move last paragraph of Section 2.0 to section 2.1.4 Data Standardization Added definitions of key terms 0.6 6/5/2007 Ulrike Nasshan Section 2.2.5 Coordinate with Kumar and Lisa to determine the class words used by XML community, and identify them in the document.
    [Show full text]
  • A Model-To-Model Transformation of a Generic Relational Database Schema Into a Form Type Data Model
    Proceedings of the Federated Conference on Computer Science DOI: 10.15439/2016F408 and Information Systems pp. 1577–1580 ACSIS, Vol. 8. ISSN 2300-5963 A Model-to-Model Transformation of a Generic Relational Database Schema into a Form Type Data Model Sonja Ristić, Slavica Kordić, Milan Čeliković, Vladimir Dimitrieski, Ivan Luković University of Novi Sad, Faculty of Technical Sciences, Trg D. Obradovića 6, 21000 Novi Sad, Serbia Email: {sdristic, slavica, milancel, dimitrieski, ivan}@uns.ac.rs ฀ engineering and review different database meta-models Abstract—An important phase of a data-oriented software (MM) that are used in the database reengineering process system reengineering is a database reengineering process and, applied in IIS*Studio. In [5] we propose an MD approach to in particular, its subprocess – a database reverse engineering data structure conceptualization phase of database reverse process. In this paper we present one of the model-to-model engineering process that is conducted through a chain of transformations from a chain of transformations aimed at transformation of a generic relational database schema into a M2M transformations. In this paper we present the final step form type data model. The transformation is a step of the data of the conceptualization phasethe M2M transformation of structure conceptualization phase of a model-driven database a generic relational database schema into a form type model. reverse engineering process that is implemented in IIS*Studio The form type concept and the IIS*Studio architecture are development environment. given in Section 2. Classifications of form types and relation schemes are described in Section 3. The transformation of a I.
    [Show full text]
  • Using Telelogic DOORS and Microsoft Visio to Model and Visualize Complex Business Processes
    Using Telelogic DOORS and Microsoft Visio to Model and Visualize Complex Business Processes “The Business Driven Application Lifecycle” Bob Sherman Procter & Gamble Pharmaceuticals [email protected] Michael Sutherland Galactic Solutions Group, LLC [email protected] Prepared for the Telelogic 2005 User Group Conference, Americas & Asia/Pacific http://www.telelogic.com/news/usergroup/us2005/index.cfm 24 October 2005 Abstract: The fact that most Information Technology (IT) projects fail as a result of requirements management problems is common knowledge. What is not commonly recognized is that the widely haled “use case” and Object Oriented Analysis and Design (OOAD) phenomenon have resulted in little (if any) abatement of IT project failures. In fact, ten years after the advent of these methods, every major IT industry research group remains aligned on the fact that these projects are still failing at an alarming rate (less than a 30% success rate). Ironically, the popularity of use case and OOAD (e.g. UML) methods may be doing more harm than good by diverting our attention away from addressing the real root cause of IT project failures (when you have a new hammer, everything looks like a nail). This paper asserts that, the real root cause of IT project failures centers around the failure to map requirements to an accurate, precise, comprehensive, optimized business model. This argument will be supported by a using a brief recap of the history of use case and OOAD methods to identify differences between the problems these methods were intended to address and the challenges of today’s IT projects.
    [Show full text]
  • Principles of the Concept-Oriented Data Model Alexandr Savinov
    Principles of the Concept-Oriented Data Model Alexandr Savinov Institute of Mathematics and Computer Science Academy of Sciences of Moldova Academiei 5, MD-2028 Chisinau, Moldova Fraunhofer Institute for Autonomous Intelligent System Schloss Birlinghoven, 53754 Sankt Augustin, Germany http://www.conceptoriented.com [email protected] Principles of the Concept-Oriented Data Model Alexandr Savinov Institute of Mathematics and Computer Science, Academy of Sciences of Moldova Academiei 5, MD-2028 Chisinau, Moldova Fraunhofer Institute for Autonomous Intelligent System Schloss Birlinghoven, 53754 Sankt Augustin, Germany http://www.conceptoriented.com [email protected] In the paper a new approach to data representation and manipulation is described, which is called the concept-oriented data model (CODM). It is supposed that items represent data units, which are stored in concepts. A concept is a combination of superconcepts, which determine the concept’s dimensionality or properties. An item is a combination of superitems taken by one from all the superconcepts. An item stores a combination of references to its superitems. The references implement inclusion relation or attribute- value relation among items. A concept-oriented database is defined by its concept structure called syntax or schema and its item structure called semantics. The model defines formal transformations of syntax and semantics including the canonical semantics where all concepts are merged and the data semantics is represented by one set of items. The concept-oriented data model treats relations as subconcepts where items are instances of the relations. Multi-valued attributes are defined via subconcepts as a view on the database semantics rather than as a built-in mechanism.
    [Show full text]
  • Metamodeling the Enhanced Entity-Relationship Model
    Metamodeling the Enhanced Entity-Relationship Model Robson N. Fidalgo1, Edson Alves1, Sergio España2, Jaelson Castro1, Oscar Pastor2 1 Center for Informatics, Federal University of Pernambuco, Recife(PE), Brazil {rdnf, eas4, jbc}@cin.ufpe.br 2 Centro de Investigación ProS, Universitat Politècnica de València, València, España {sergio.espana,opastor}@pros.upv.es Abstract. A metamodel provides an abstract syntax to distinguish between valid and invalid models. That is, a metamodel is as useful for a modeling language as a grammar is for a programming language. In this context, although the Enhanced Entity-Relationship (EER) Model is the ”de facto” standard modeling language for database conceptual design, to the best of our knowledge, there are only two proposals of EER metamodels, which do not provide a full support to Chen’s notation. Furthermore, neither a discussion about the engineering used for specifying these metamodels is presented nor a comparative analysis among them is made. With the aim at overcoming these drawbacks, we show a detailed and practical view of how to formalize the EER Model by means of a metamodel that (i) covers all elements of the Chen’s notation, (ii) defines well-formedness rules needed for creating syntactically correct EER schemas, and (iii) can be used as a starting point to create Computer Aided Software Engineering (CASE) tools for EER modeling, interchange metadata among these tools, perform automatic SQL/DDL code generation, and/or extend (or reuse part of) the EER Model. In order to show the feasibility, expressiveness, and usefulness of our metamodel (named EERMM), we have developed a CASE tool (named EERCASE), which has been tested with a practical example that covers all EER constructors, confirming that our metamodel is feasible, useful, more expressive than related ones and correctly defined.
    [Show full text]
  • The Importance of Data Models in Enterprise Metadata Management
    THE IMPORTANCE OF DATA MODELS IN ENTERPRISE METADATA MANAGEMENT October 19, 2017 © 2016 ASG Technologies Group, Inc. All rights reserved HAPPINESS IS… SOURCE: 10/18/2017 TODAY SHOW – “THE BLUE ZONE OF HAPPINESS” – DAN BUETTNER • 3 Close Friends • Get a Dog • Good Light • Get Religion • Get Married…. Stay Married • Volunteer • “Money will buy you Happiness… well, it’s more about Financial Security” • “Our Data Models are now incorporated within our corporate metadata repository” © 2016 ASG Technologies Group, Inc. All rights reserved 3 POINTS TO REMEMBER SOURCE: 10/19/2017 DAMA NYC – NOONTIME SPEAKER SLOT – MIKE WANYO – ASG TECHNOLOGIES 1. Happiness is individually sought and achievable © 2016 ASG Technologies Group, Inc. All rights reserved 3 POINTS TO REMEMBER SOURCE: 10/19/2017 DAMA NYC – NOONTIME SPEAKER SLOT – MIKE WANYO – ASG TECHNOLOGIES 1. Happiness is individually sought and achievable 2. Data Models can in be incorporated into your corporate metadata repository © 2016 ASG Technologies Group, Inc. All rights reserved 3 POINTS TO REMEMBER SOURCE: 10/19/2017 DAMA NYC – NOONTIME SPEAKER SLOT – MIKE WANYO – ASG TECHNOLOGIES 1. Happiness is individually sought and achievable 2. Data Models can in be incorporated into your corporate metadata repository 3. ASG Technologies can provide an overall solution with services to accomplish #2 above and more for your company. © 2016 ASG Technologies Group, Inc. All rights reserved AGENDA Data model imports to the metadata collection View and search capabilities Traceability of physical and logical
    [Show full text]
  • Towards the Universal Spatial Data Model Based Indexing and Its Implementation in Mysql
    Towards the universal spatial data model based indexing and its implementation in MySQL Evangelos Katsikaros Kongens Lyngby 2012 IMM-M.Sc.-2012-97 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone +45 45253351, Fax +45 45882673 [email protected] www.imm.dtu.dk IMM-M.Sc.: ISSN XXXX-XXXX Summary This thesis deals with spatial indexing and models that are able to abstract the variety of existing spatial index solutions. This research involves a thorough presentation of existing dynamic spatial indexes based on R-trees, investigating abstraction models and implementing such a model in MySQL. To that end, the relevant theory is presented. A thorough study is performed on the recent and seminal works on spatial index trees and we describe their basic properties and the way search, deletion and insertion are performed on them. During this effort, we encountered details that baffled us, did not make the understanding the core concepts smooth or we thought that could be a source of confusion. We took great care in explaining in depth these details so that the current study can be a useful guide for a number of them. A selection of these models were later implemented in MySQL. We investigated the way spatial indexing is currently engineered in MySQL and we reveal how search, deletion and insertion are performed. This paves the path to the un- derstanding of our intervention and additions to MySQL's codebase. All of the code produced throughout this research was included in a patch against the RDBMS MariaDB.
    [Show full text]
  • Enterprise Data Modeling Using the Entity-Relationship Model
    Database Systems Session 3 – Main Theme Enterprise Data Modeling Using The Entity/Relationship Model Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences Presentation material partially based on textbook slides Fundamentals of Database Systems (6th Edition) by Ramez Elmasri and Shamkant Navathe Slides copyright © 2011 1 Agenda 11 SessionSession OverviewOverview 22 EnterpriseEnterprise DataData ModelingModeling UsingUsing thethe ERER ModelModel 33 UsingUsing thethe EnhancedEnhanced Entity-RelationshipEntity-Relationship ModelModel 44 CaseCase StudyStudy 55 SummarySummary andand ConclusionConclusion 2 Session Agenda Session Overview Enterprise Data Modeling Using the ER Model Using the Extended ER Model Case Study Summary & Conclusion 3 What is the class about? Course description and syllabus: » http://www.nyu.edu/classes/jcf/CSCI-GA.2433-001 » http://cs.nyu.edu/courses/fall11/CSCI-GA.2433-001/ Textbooks: » Fundamentals of Database Systems (6th Edition) Ramez Elmasri and Shamkant Navathe Addition Wesley ISBN-10: 0-1360-8620-9, ISBN-13: 978-0136086208 6th Edition (04/10) 4 Icons / Metaphors Information Common Realization Knowledge/Competency Pattern Governance Alignment Solution Approach 55 Agenda 11 SessionSession OverviewOverview 22 EnterpriseEnterprise DataData ModelingModeling UsingUsing thethe ERER ModelModel 33 UsingUsing thethe EnhancedEnhanced Entity-RelationshipEntity-Relationship ModelModel 44 CaseCase StudyStudy 55 SummarySummary andand ConclusionConclusion
    [Show full text]
  • HANDLE - a Generic Metadata Model for Data Lakes
    HANDLE - A Generic Metadata Model for Data Lakes Rebecca Eichler, Corinna Giebler, Christoph Gr¨oger, Holger Schwarz, and Bernhard Mitschang In: Big Data Analytics and Knowledge Discovery (DaWaK) 2020 BIBTEX: @inproceedingsfeichler2020handle, title=fHANDLE-A Generic Metadata Model for Data Lakesg, author=fEichler, Rebecca and Giebler, Corinna and Gr{\"o\}ger,Christoph and Schwarz, Holger and Mitschang, Bernhardg, booktitle=fInternational Conference on Big Data Analytics and Knowledge Discovery (DaWaK) 2020g, pages=f73{88g, year=f2020g, organization=fSpringerg, doi=f10.1007/978-3-030-59065-9 7g g c by Springer Nature This is the author's version of the work. The final authenticated version is avail- able online at: https://doi.org/10.1007/978-3-030-59065-9 7 HANDLE - A Generic Metadata Model for Data Lakes Rebecca Eichler1, Corinna Giebler1, Christoph Gr¨oger2, Holger Schwarz1, and Bernhard Mitschang1 1 University of Stuttgart, Universit¨atsstraße38, 70569 Stuttgart, Germany [email protected] 2 Robert Bosch GmbH, Borsigstraße 4, 70469 Stuttgart, Germany [email protected] Abstract The substantial increase in generated data induced the de- velopment of new concepts such as the data lake. A data lake is a large storage repository designed to enable flexible extraction of the data's value. A key aspect of exploiting data value in data lakes is the collec- tion and management of metadata. To store and handle the metadata, a generic metadata model is required that can reflect metadata of any potential metadata management use case, e.g., data versioning or data lineage. However, an evaluation of existent metadata models yields that none so far are sufficiently generic.
    [Show full text]
  • Gis Data Models
    GIS DATA MODELS CONCEPTUAL MODEL OF SPATIAL INFORMATION 1. Introduction GIS does not store a map in any conventional sense, nor it stores a particular image or view of geographic area. Instead, a GIS stores the data from which we can draw a desired view to suit a particular purpose known as geographic data. There are two types of data in GIS; spatial data and non-spatial data (Attribute data). Non-spatial data include information about the features. For example, name of roads, schools, forests etc., population or census data for the region concerned etc. Non-spatial or attribute data is that qualifies the spatial data. It describes some aspects of the spatial data, not specified by its geometry alone. A geographical information system essentially integrates the above two types of data and allows user to derive new data for planning. Spatial models are important in that way in which information is represented affects the type of analysis that can be performed and the type of graphic display that can be performed and the type of analysis that can be obtained. In GIS systems there is a major distinction between what are usually referred to as vector GIS and raster GIS. These two approaches to spatial data processing, often to be found in the same GIS package, reflect two different methods of spatial modeling: the former focusing on discrete objects that are to be described, and the latter concerned primarily with recording what is to be found at a predetermined set of locations that may be grid cells or points.
    [Show full text]
  • XV. the Entity-Relationship Model
    Information Systems Analysis and Design csc340 XV. The Entity-Relationship Model The Entity-Relationship Model Entities, Relationships and Attributes Cardinalities, Identifiers and Generalization Documentation of E-R Diagrams and Business Rules 2002 John Mylopoulos The Entity-Relationship Model -- 1 Information Systems Analysis and Design csc340 The Entity Relationship Model The Entity-Relationship (ER) model is a conceptual data model, capable of describing the data requirements for a new information system in a direct and easy to understand graphical notation. Data requirements are described in terms of a conceptualconceptual (or, ER) schema. ER schemata are comparable to class diagrams. 2002 John Mylopoulos The Entity-Relationship Model -- 2 Information Systems Analysis and Design csc340 The Constructs of the E-R Model AND/XOR 2002 John Mylopoulos The Entity-Relationship Model -- 3 Information Systems Analysis and Design csc340 Entities These represent classes of objects (facts, things, people,...) that have properties in common and an autonomous existence. City, Department, Employee, Purchase and Sale are examples of entities for a commercial organization. An instance of an entity is an object in the class represented by the entity. Stockholm, Helsinki, are examples of instances of the entity City, and the employees Peterson and Johanson are examples of instances of the Employee entity. The E-R model is very different from the relational model in which it is not possible to represent an object without knowing its properties (an employee is represented by a tuple containing the name, surname, age, and other attributes.) 2002 John Mylopoulos The Entity-Relationship Model -- 4 Information Systems Analysis and Design csc340 Examples of Entities 2002 John Mylopoulos The Entity-Relationship Model -- 5 Information Systems Analysis and Design csc340 Relationships They represent logical links between two or more entities.
    [Show full text]