COP 4710: Database Systems (Day 4) Page 1 Mark Llewellyn COP 4710: Database Systems Spring 2004 Introduction to Data Modeling BÀI 3&4, 2 ngày School of Electrical Engineering and Computer Science University of Central Florida Instructor : Mark Llewellyn markl@cs.ucf.edu CC1 211, 823-2790 http://www.cs.ucf.edu/courses/cop4710/spr2004 COP 4710: Database Systems (Day 4) Page 2 Mark Llewellyn • A data model is an integrated collection of concepts for describing and manipulating data, relationships between data, and constraints on the data in an organization. • A model is a representation of “real world” objects and events, and their associations. It is an abstraction that concentrates on the essential, inherent aspects of an organization and ignores accidental properties. • A data model must provide the basic concepts and notations that will allow database designers and end-users unambiguously and accurately to communicate their understanding of the organizational data. Data Models COP 4710: Database Systems (Day 4) Page 3 Mark Llewellyn • A data model can be thought of as comprising three components: 1. A structural part, consisting of a set of rules according to which databases can be constructed. 2. A manipulative part, defining the types of operations that are allowed on the data (this includes operations that are used for updating or retrieving data from the database and for changing the structure of the database). 3. Possibly a set of integrity rules, which ensures that the data is accurate. Data Models (cont.) COP 4710: Database Systems (Day 4) Page 4 Mark Llewellyn • Looking at the three level architecture, we can identify three different, related data models. 1. An external data model to represent each user’s view of the organization. 2. A conceptual data model to represent the logical (or community view) that is DBMS independent. 3. An internal data model to represent the conceptual schema in such a way that it can be understood by the DBMS. Data Models (cont.) COP 4710: Database Systems (Day 4) Page 5 Mark Llewellyn • There have been many different data models which have been theorized, utilized, developed, and implemented over the years. They fall into three broad categories: object-based, record- based, and physical. • There are three principle record-based models: the relational data model, the network data model, and the hierarchical data model. Our focus will be on the relational data model in this course. Data Models (cont.) COP 4710: Database Systems (Day 4) Page 6 Mark Llewellyn • Semantic data models attempt to capture the “meaning” of a database. Practically, they provide an approach for conceptual data modeling. • Over the years there have been several different semantic data models that have been proposed. • By far the most common is the entity-relationship data model, most often referred to as simply the E-R data model. • The E-R model is often used as a form of communication between database designers and the end users during the developmental stages of a database. Introduction to Data Modeling COP 4710: Database Systems (Day 4) Page 7 Mark Llewellyn • The E-R model contains an extensive set of modeling tools, some of which we will not be concerned with as our primary objective is to give you some insight into conceptual database design and not learning all of the ins and outs of the E-R model. • Another conceptual modeling which is becoming more common is the Object Definition Language (ODL) which is an object-oriented approach to database design that is emerging as a standard for object-oriented database systems. Introduction to Data Modeling (cont.) COP 4710: Database Systems (Day 4) Page 8 Mark Llewellyn • The database design process can be divided into six basic steps. Semantic data models are most relevant to only the first three of these steps. 1. Requirements Analysis: The first step in designing a database application is to understand what data is to be stored in the database, what applications must be built on top of it, and what operations are most frequent and subject to performance requirements. Often this is an informal process involving discussions with user groups and studying the current environment. Examining existing applications expected to be replaced or complemented by the database system. Introduction to Data Modeling (cont.) COP 4710: Database Systems (Day 4) Page 9 Mark Llewellyn 2. Conceptual Database Design: The information gathered in the requirements analysis step is used to develop a high- level description of the data to be stored in the database, along with the constraints that are known to hold on this data. 3. Logical Database Design: A DBMS must be selected to implement the database and to convert the conceptual database design into a database schema within the data model of the chosen DBMS. Introduction to Data Modeling (cont.) COP 4710: Database Systems (Day 4) Page 10 Mark Llewellyn 4. Schema Refinement: In this step the schemas developed in step 3 above are analyzed for potential problems. It is in this step that the database is normalized. Normalization of a database is based upon some elegant and powerful mathematical theory. We will discuss normalization later in the term. 5. Physical Database Design: At this stage in the design of a database, potential workloads and access patterns are simulated to identify potential weaknesses in the conceptual database. This will often cause the creation of additional indices and/or clustering relations. In critical situations, the entire conceptual model will need restructuring. Introduction to Data Modeling (cont.) [...]... COP 47 10: Database Systems (Day 4) Page 28 Mark Llewellyn Mapping Cardinality: 1:1 from A to B a11 b1 a2 b2 a3 b3 a4 b4 A COP 47 10: Database Systems (Day 4) B Page 29 Mark Llewellyn Mapping Cardinality: · 1:M from A to B b1 a11 b2 a2 b3 a3 b4 a4 b5 A COP 47 10: Database Systems (Day 4) B Page 30 Mark Llewellyn Mapping Cardinality: · M:1 from A to B b1 a11 a2 b2 a3 b3 a4 b4 a5 b5 A COP 47 10: Database Systems. .. R 2 E4 R (min,max) E2 Structural constraint: (min,max) on the participation of an entity in a relationship COP 47 10: Database Systems (Day 4) Page 18 Mark Llewellyn Example E-R Diagram (ERD) customer-street customer-name customer-city amount customer-id customer-id customer COP 47 10: Database Systems (Day 4) borrower Page 19 loan Mark Llewellyn Another Example ERD street-name middle-name street-num... middle-name street-num first-name apartment-num last-name customer-name street customer-id address customer phone-num city state zipcode age date-of-birth COP 47 10: Database Systems (Day 4) Page 20 Mark Llewellyn Attributes in the E-R Model • As used in the E-R model, an attribute can be characterized by the following attribute types: • Simple or Composite: A simple attribute contains no subparts while a composite... Systems (Day 4) B Page 31 Mark Llewellyn Mapping Cardinality: · M:M from A to B b1 a11 b2 a2 b3 a3 b4 a4 b5 A COP 47 10: Database Systems (Day 4) B Page 32 Mark Llewellyn • Participation Constraints in the E-R Model The participation of an entity set E in a relationship set R is said to be total if every entity in E participates in at least one relationship in R If only some of the entities in E participate... of pairs, one for each attribute of the entity set • A database contains a collection of entity sets COP 47 10: Database Systems (Day 4) Page 14 Mark Llewellyn E-R Model Notation entity set E weak entity set E R relationship identifying relationship R for a weak entity set att primary key COP 47 10: Database Systems (Day 4) a a a R R Page 15 attribute multi-valued attribute derived... form for M:M cardinality from E1 to E2 R COP 47 10: Database Systems (Day 4) Page 16 Mark Llewellyn E-R Model Notation (cont.) ISA (specialization or generalization)(partial participation) ISA Disjoint ISA (specialization or generalization) ISA disjoint ISA Total generalization COP 47 10: Database Systems (Day 4) Page 17 Mark Llewellyn E-R Model Notation (cont.) E3 Aggregation: box drawn around relationship... could not do with a simple attribute COP 47 10: Database Systems (Day 4) Page 21 Mark Llewellyn Attributes in the E-R Model (cont.) • Single-valued or Multi-valued: A single-valued attribute may have at most one value at any particular time instance A multiple-valued attribute may have several different values at any particular time instance – For example, consider a particular course at UCF At any given... which the database is made operational (although it may be through a simulation) and further refinements are made as the system is “tweaked” to provide the expected environment • The illustration on the following page summarizes the main phases of database design COP 47 10: Database Systems (Day 4) Page 11 Mark Llewellyn Introduction to Data Modeling (cont.) COP 47 10: Database Systems (Day 4) Page 12... called access-date to indicate the most recent date that a customer accessed their account • COP 47 10: Database Systems (Day 4) Page 26 Mark Llewellyn Constraints in the E-R Model • As we have mentioned earlier, a the values contained within a given database often have constraints placed upon them to ensure that they accurately model the real world enterprise captured in the database • The E-R model has... the borrowers relationship Therefore, the participation of the customer entity set in the borrower relationship is partial COP 47 10: Database Systems (Day 4) Page 33 Mark Llewellyn Keys of an Entity Set • We must have some mechanism for specifying how entities within a given entity set are distinguished • Conceptually, individual entities are distinct; from a database perspective, however, the differences . customer-id customer-name street apartment-num phone-num date-of-birth age first-name middle-name last-name address city state zipcode street-name street-num. COP 47 10: Database Systems (Day 4) Page 1 Mark Llewellyn COP 47 10: Database Systems Spring 20 04 Introduction to Data Modeling BÀI 3& amp ;4, 2 ngày