COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model"

Transcription

1 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 in the database is viewed as sets of entities and sets of relationships among entities. The primary use of the E-R model is as a design tool for relational databases. 1 The Design Process One (relatively) typical process: 1. the designers meet with prospective database users and domain experts to characterize what data needs to be stored and how that data will be accessed. The result of this step is a set of user requirements, which are expressed via some combination of text and diagrams. 2. the designers choose a data model and translate the user requirements into a conceptual schema in this model. We will use the E-R model at this step as a way to analyze data and relationships among data items. 3. the designers review the database schema to ensure that it supports the functional requirements of the application as a whole - that is, that data can be accessed and updated in the required ways. 4. the conceptual schema is implemented (a) logical design phase: the conceptual schema is mapped to an implementation schema. We will use an algorithm to transform an E-R schema into a relational database schema. (b) physical design phase: file and index structures are chosen for the physical schema of the database In particular, the database schema should avoid: redundancy: repeated information wastes storage and increases opportunities for inconsistency incompleteness: bad design may make information difficult to store. For example, if we eliminate the customer relation by adding name and address attributes to the purchased relation, we have no clean way to store information about customers who have not purchased a flyrod. 2 The Entity-Relationship Model 2.1 Entity Sets An entity is something that exists and can be distinguished from other entities. Examples: customer entities with unique social security numbers account entities with unique account numbers An entity set is a set of entities of the same type. example: all of the account entities for a bank entity sets need not be disjoint. Example: a person entity could be in both the customer and employee entity sets. An attribute is a characteristic or property of an entity. 1

2 example: a customer entity might have attributes such as: customer name, social security number, address,... as all entities in an entity set have the same attributes, entity sets also have attributes - the attributes of the contained entities. The value of the attribute can be different for each entity in the set. The domain of an attribute is the set of possible values for the attribute (the type of the attribute). Examples: the domain of customer name might be strings of some fixed length the domain of social security number might be 9 digit positive integers An entity is represented by (consists of) a value for each of its attributes. entities can be written as a record or tuple (like a row in a table). Example: for a customer entity with attributes custnum, name, and address: 2 Elvis Presley Graceland Note that this representation forces attributes to always be written in the same order. The custnum attribute is added to ensure that customer entities can always be uniquely identified based only on attribute values, as two customers might have the same name and address. entity sets can be written as a group of entities in a box Example: entity sets for an ER database for a fly shop logical schema (entity sets and their attributes): entity set fly entity set flyrod attribute domain stocknum positive integer pattern string[30] size positive integer color {black, olive, natural} inventory positive integer attribute domain stocknum positive integer manufacturer string[30] length positive real (feet) lineweight positive integer inventory positive integer 2

3 entity set customer attribute domain custnum positive integer name string[30] address string[50] instance: fly 5 woolly bugger 10 olive 3 2 gold ribbed hare s ear 14 natural 4 4 woolly bugger 2 black 7 1 dahlberg diver 2 natural 4 customer 1 Tim Wahls Tome Linda Null E258 2 Elvis Presley Graceland flyrod 3 Sage G. Loomis Orvis Figure 1: The entity sets in an instance of the flyshop database Types of attributes: simple vs. composite attributes simple attributes are atomic - they can not be divided into smaller parts composite attributes are attributes that can be subdivided. For example, an address attribute could be divided into house number, street, city, state and zip code. single vs. multivalued attributes single valued attributes have only one value for a particular entity multivalued attributes can have multiple values for the same entity. For example, a customer could have 0, 1 or many telephone numbers. derived attributes which can be calculated from other information in the database. For example, if all of a students grades are stored, then gpa is a derived attribute. Values of derived attributes are typically computed when needed rather than being stored directly. The special value null is used to indicate that the value for an attribute does not exist or is not known. 3

4 2.2 Relationship Sets A relationship is an association among 2 or more entities - for example, the relationship between a customer and a Sage 2-weight flyrod purchased at the fly shop. A relationship set is a set of relationships of the same type. The following diagram shows two relationship sets: purchased, which is a relationship between customers and flyrods requestedby, which is a relationship between customers and flies fly 5 woolly bugger 10 olive 3 2 gold ribbed hare s ear 14 natural 4 4 woolly bugger 2 black 7 1 dahlberg diver 2 natural 4 requestedby customer 1 Tim Wahls Tome Linda Null E258 2 Elvis Presley Graceland flyrod purchased 3 Sage G. Loomis Orvis Figure 2: An instance of an entity-relationship database for the flyshop. A relationship set is a mathematical relation on two or more entity sets. A relationship set R on entity sets E 1,E 2,...,E n for n 2 is a subset of: {(e 1,e 2,...,e n ) e 1 E 1,e 2 E 2,...,e n E n } where (e 1,e 2,...,e n ) is a relationship. The value of {(e 1,e 2,...,e n ) e 1 E 1,e 2 E 2,...,e n E n } is the cartesian product of E 1, E 2,..., E n - the set of all possible relationships between entities in E 1, entities in E 2,..., and entities in E n. Notes: a relationship set is part of the schema of an ER database, while each relationship in the set is part of an instance the way that an entity participates in a relationship is called the role of the entity. Roles are only needed when an entity set participates in the same relationship set multiple times. For example, given an entity set employee, a relationship set manages could be defined that relates each employee to his or her manager (who is also an employee). Roles are needed to clarify which employee is the manager and which is the managee. 4

5 a relationship may have attributes, and so a relationship set can have attributes. For example, relationship set purchased could have a pdate attribute recording the date of purchase. each relationship in a relationship set must be uniquely identifiable from only the participating entities (without using any attributes of the relationship set). For example, if the same customer can purchase the same flyrod model multiple times (which is realistic), the attribute pdate of relationship set purchased must be a multivalued attribute. a relationship set on two entity sets is called a binary relationship set, or a relationship set of degree 2. This is the most common case, but relationship sets of degree 3 and higher are allowed. 3 Constraints Constraints are restrictions on the data stored in a database. The constraints themselves are part of the schema of the database, and dictate whether or not a particular instance is a legal instance of that schema. 3.1 Mapping Cardinalities A mapping cardinality is a data constraint that specifies how many entities an entity can be related to in a relationship set. Example: each customer can purchase as many kinds of flyrods as they want (a constraint on purchased), but the fly shop only tracks the first customer to request each fly pattern (a constraint on requestedby). Mapping cardinalities on binary relationship sets are simplest, although they can also be defined for relationship sets of higher degree. Consider a binary relationship set R on entity sets A and B. There are four possible mapping cardinalities in this case: 1. one to one - an entity in A is related to at most one entity in B, and an entity in B is related to at most one entity in A. a1 a2 a3 b1 b2 b3 b4 2. one to many - an entity in A is related to any number of entities in B, but an entity in B is related to at most one entity in A. a1 a2 a3 b1 b2 b3 b4 b5 Example: if the fly shop stocks flies by customer request only, then relationship set requestedby from customer to fly has one to many mapping cardinality because no one else need request a fly once the shop stocks it. 3. many to one - an entity in A is related to at most one entity in B, but an entity in B is related to any number of entities in A. a1 a2 a3 a4 a5 b1 b2 b3 b4 b5 5

6 4. many to many - an entity in A is related to any number of entities in B, and an entity in B is related to any number of entities in A. a1 a2 a3 a4 a5 b1 b2 b3 b4 b5 Relationship set purchased has many to many mapping cardinality because a customer can buy many different kinds of flyrods, and each kind of flyrod can be purchased by multiple customers. The mapping cardinality of a relationship set depends on the real world relationships it is modeling. 3.2 Keys Issue: distinguishing between entities in an entity set (and relationships in a relationship set). We require that all entities are distinguishable based only on attribute values - no two (different) entities are allowed to have the same values for all attributes. The concept of keys (and associated terminology) is very similar to that of the relational model Entity Sets A superkey is a set of one or more attributes that allow entities to be uniquely identified. All of the following are superkeys for entity set fly: {stocknum} {stocknum, size} {pattern, size, color} {stocknum, pattern, size, color} This list is not comprehensive. A superkey must allow entities (or relationships) to be distinguished across all possible instances. This often requires outside knowledge about what attributes mean. A candidate key is a superkey that has no superkeys as proper subsets. A candidate key is a minimal superkey. Candidate keys for fly: {stocknum} {pattern, size, color} and no others. The primary key is the (one) candidate key chosen (by the database designer or database administrator) as the primary means of uniquely identifying entities. Example: {stocknum} is the most likely primary key for fly. Primary keys should be chosen so that they are unlikely to ever change. Frequently, primary keys are artificially generated (stock numbers, order numbers, social security numbers,...) to ensure that this is the case Relationship Sets Let R be a relationship set on entity sets E 1,E 2,...,E n, and let primary-key(e i ) denote the set of primary key attributes for entity set E i. 6

7 if R has no attributes, then the set of attributes primary-key(e 1 ) primary-key(e 2 )... primary-key(e n ) is sufficient to completely describe any relationship in R if R has attributes a 1,a 2,...,a m, then the set of attributes primary-key(e 1 ) primary-key(e 2 )... primary-key(e n ) {a 1,a 2,...,a m } is sufficient to completely describe any relationship in R In either case, the set of attributes: primary-key(e 1 ) primary-key(e 2 )... primary-key(e n ) forms a superkey for the relationship set. If the primary key attributes from the entity sets do not have unique names, they must be renamed (typically by prefixing the attribute name with the entity set name). If one entity set participates multiple times in the relationship set, then the role name (rather than the entity set name) is used when forming unique attribute names. The primary key of a relationship set depends on the mapping cardinality: 1. one to one mapping cardinality: the primary key of any of the entity sets involved is a candidate key for the relationship set, because any entity (from any entity set) can be involved in at most one relationship. 2. one to many mapping cardinality: the primary key of the relationship set is the primary key of the second entity set (the to many set), because an entity in the second entity set can be involved in at most one relationship. 3. many to one mapping cardinality: the primary key of the relationship set is the primary key of the first entity set (the to many set), because an entity in the first entity set can be involved in at most one relationship. 4. many to many mapping cardinality: the primary key of the relationship set includes the primary keys of all of the entity sets involved. Examples - assuming that the primary keys of entity sets are as follows: entity set primary key customer {custnum} flyrod {stocknum} fly {stocknum} then the primary keys for our relationship sets are: relationship set mapping cardinality primary key purchased many to many {custnum, stocknum} requestedby one to many {stocknum} 3.3 Participation Constraints The participation of an entity set in a relationship set is total if every entity must participate in at least one relationship. Otherwise, the participation of the entity set is partial. Examples: if the fly shop stocks only flies that customers have requested, then the participation of entity set fly in the requestedby relationship set is total. Since a customer is not required to request a fly, the participation of customer in requestedby is partial. the participation of entity sets customer and flyrod in relationship set purchased is partial in both cases. A customer is not required to purchase a flyrod, and some flyrod models may not (yet) have been purchased. 7

8 4 Entity-Relationship Diagrams The logical schema of an E-R database can be represented graphically by an E-R diagram as follows: entity sets are represented by rectangles attributes are represented by ovals relationship sets are represented by diamonds lines link attributes to entity and relationship sets, and entity sets to relationship sets. multivalued attributes are represented by double ovals derived attributes (attributes whose value can be computed from other attributes) are represented by dashed ovals weak entity sets (more later) are represented by double rectangles Constraints are represented in E-R diagrams as follows: mapping cardinalities: a directed link (arrow) represents a to one relationship an undirected link represents a to many relationship participation constraints: a double line represents total participation a single line represents partial participation stocknum pattern size color inventory custnum name address manufacturer stocknum length lineweight inventory fly customer flyrod pdate requestedby purchased Figure 3: Entity-relationship diagram for the flyshop DBMS Note that primary key attributes of the entity sets are underlined. 8

9 Composite attributes are represented by attributes with attributes. For example: street number city ssn name address state zip person Figure 4: Composite attributes Roles are indicated by labeling the line between the entity set and the relationship set with the role name: dad ssn name address mom father person mother child child Figure 5: Using roles to clarify a relationship between an entity set and itself Mapping cardinalities can also be indicated by labeling the line between an entity set and a relationship set with l..h, where l is the smallest number of relationships that an entity can be involved in and h is the largest. can be used as the upper bound to indicate no limit a lower bound of 1 specifies that the participation of the entity set is total if the upper bound on both sides of a relationship set is one, then the relationship set is one to one Examples: father dad ssn name address mom 0.. * 0.. * person child child mother Figure 6: Alternate notation for mapping cardinalities Note that 0..1 is on the to many side of the relationship (the opposite side from where the arrowhead would go). 9

10 stocknum pattern size color inventory custnum name address manufacturer stocknum length lineweight inventory fly customer flyrod * 0.. * pdate 0.. * requestedby purchased Figure 7: Another example of the alternate notation for mapping cardinalities E-R diagrams are often used for designing other kinds of databases (especially relational databases) and for modeling software systems. 5 Design Issues use of entity sets vs. attributes example: addresses how to decide: do we need to store extra information associated only with addresses? can entities be related to multiple addresses? use of entity sets vs. relationship sets example: an online shopping cart if the shopping cart is represented as a relationship set, then each item placed in the cart must be represented by a separate relationship. This forces attributes of the shopping cart (date, transaction number,...) to be stored once for every item placed in the cart. it the shopping cart is represented as an entity set, then the cart can be involved in multiple relationships with items purchased with no redundant information stored. example: the purchase of a flyrod in the flyshop. Since each purchase involves one customer and one flyrod, this is best represented as a relationship set. binary vs. n-ary relationship sets an n-ary relationship relationship set can always be represented by several binary relationship sets example: a ternary (3-ary) relationship set parents storing the parents of each child could be represented by two binary relationship sets mother and father. how to decide: must all entities involved in the relationship be known in order to have valid information to store? For example, if we have information about only one parent, we must use a null value in the parents relationship set. placement of relationship set attributes Issue: can attributes of a relationship set be moved to one of the participating entity sets? if the mapping cardinality of the relationship set is one to one, one to many, or many to one, then the attributes can be moved to the entity set on the to many side (or either side in the one to one case) of the relationship set 10

11 example: if requestedby had a requestdate attribute, this attribute could be moved to entity set fly with no loss of information if the participation of the entity set in the relationship set is not total, then null values would have to be used for the values of those attributes in some cases if the mapping cardinality of the relationship set is many to many, then any attributes of the relationship set can not be moved to either participating entity set. For example, purchased has many to many mapping cardinality, which means that each customer can purchase multiple flyrods and each flyrod model can be purchased by multiple customers. Hence, attribute pdate can not be moved to either of these entity sets without losing information. 6 Weak Entity Sets A weak entity set is an entity set that does not have sufficient attributes to form a primary key. An entity set that does have a primary key is called a strong entity set. For example, consider shopping carts used by an online store. If the only attributes stored for shopping cards are the time, date and the amount (value of items in the cart), then two distinct shopping carts could have the same values on all attributes. Since all attributes together do not form a superkey, entity set scart does not have sufficient attributes to form a primary key. One solution to this problem is to add a synthetic attribute (such as a transaction number) to serve as the primary key. This works, but is not always necessary or desirable. A weak entity set must always be associated with another entity set (the identifying or owner entity set), and every entity in the weak entity set must be associated with exactly one entity in the identifying entity set. The weak entity set is said to be existence dependent on the identifying entity set. For example, the scart entity set could be owned by a customer entity set, which means that two shopping carts that seem to be identical could be identified by which customer they belong to. The relationship between the weak entity set and the identifying entity set is called the identifying relationship. Participation of the weak entity set in the identifying relationship must be total, and the identifying relationship is many to one (or possibly one to one) from the weak entity set to the identifying entity set. Given these possible mapping cardinalities, an identifying relationship is not allowed to have attributes - they can always be moved to the weak entity set. A discriminator is a set of attributes of a weak entity set that allow two weak entities belonging to the same strong entity to be distinguished. For example, if one customer can not have two different shopping carts at the same time, then the time and date attributes form a discriminator for scart. The primary key of a weak entity set is constructed by combining the primary key of the identifying entity set with the discriminator of the weak entity set. For example, if the primary key of customer is custnum, then the primary key of scart is {custnum, tdate, ttime}, where tdate and ttime are the date and time attributes of scart. In an E-R diagram: a weak entity set is indicated by a double rectangle an identifying relationship is indicated by a double diamond discriminator attributes are underlined with a dashed line custnum name address tdate ttime amount qty stocknum description customer has scart holds inventory Figure 8: E-R Diagram for an Online Store (with a Weak Entity Set) 11

12 7 Inheritance In the E-R model, one entity set can inherit the attributes and relationships of another entity set. An inheritance relationship is indicated in an E-R diagram using a triangle labeled with ISA. name ssn dob street number city state zip person has address ISA customer employee credit salary dept Entity sets customer and employee inherit: the attributes ssn, name and dob {ssn} as the primary key the has relationship with address entities Figure 9: E-R Diagram for Inheritance The entity set inherited from(person in this example) is called a higher level entity set, while the inheriting entity sets (customer and employee) are called lower level entity sets. Several kinds of constraints can be placed on inheritance relationships: disjoint or overlapping whether or not a higher level entity can belong to multiple lower level entity sets a disjointness constraint is indicated in an E-R diagram by writing disjoint next to the ISA relationship (triangle) overlapping is the default total or partial specialization whether or not every higher level entity must belong to a lower level entity set total specialization is indicated in an E-R diagram by drawing a double line from the higher level entity set to the ISA relationship partial is the default So in the example E-R diagram above, a person is allowed to be both a customer and an employee, and every person must be either a customer or an employee (or both). 8 Reducing Entity-Relationship Schemas to Relational Schemas Idea: represent the data and relationships in an E-R database as a collection of relations. 12

13 8.1 Reducing Entity Sets to Relations The table corresponding to a strong entity set has a column for each attribute of the entity set and a row for each entity in the entity set. The table has the same name and primary key as the entity set. Example: the table for entity set fly (from Figure 1). stocknum pattern size color inventory 5 woolly bugger 10 olive 3 2 gold-ribbed hare s ear 14 natural 4 4 woolly bugger 2 black 7 1 Dahlberg Diver 2 natural 4 Table 1: fly Does the order of rows matter? For a weak entity set, the table has one column for each attribute of the entity set, and an additional column for each primary key attribute of the identifying entity set. The primary key is the union of the primary key of the identifying entity set and the discriminator of the weak entity set. For example, the table for the scart weak entity set (Figure 8) has columns custnum, ttime, tdate and amount, and primary key {custnum, ttime, tdate}. 8.2 Reducing Relationship Sets to Tables The table for a relationship set will have a column for each attribute of the primary key of each entity set involved in the relationship, and one for each attribute of the relationship set. These attributes are renamed if necessary to avoid name clashes. The table will have one row for each relationship, and will have the same name and primary key as the relationship set. Example: relationship set requestedby (from Figure 2) becomes: custnum stocknum Table 2: requestedby with {stocknum} as the primary key. The primary keys of the entity sets involved in the relationship become foreign keys in the table for the relationship set. For the requestedby table above, {custnum} is a foreign key referencing the customer table (derived from the customer entity set), and {stocknum} is a foreign key referencing the fly table. The identifying relationship set for a weak entity set is not reduced to a table. Since the table for a weak entity set includes the primary key of the identifying entity set, including a table for the identifying relationship is redundant. For example, the table for the weak entity set scart (Figure 8) has columns for custnum, ttime, tdate and amount. The table for the identifying relationship set has would have columns for custnum, ttime and tdate, and so all data contained in this table would already be contained in the table for scart. The table for an identifying relationship is guaranteed to be redundant because identifying relationships are not allowed to have attributes. Additionally, participation of the weak entity set in the identifying relationship must be total, so the table for the weak entity set will never contain null values for the primary key attributes of the identifying entity set. Because identifying relationships must be many to one (or one to one), information about one weak entity is never repeated in the table for the weak entity set. In general, the table for a relationship set can be combined with the table for an entity set whenever: the relationship set is many to one 13

14 the participation of the entity set on the to many side of the relationship is total The attributes of the relationship set itself and the primary key attributes of the entity set on the to one side of the relationship are added as columns in the table for the entity set on the to many side of the relationship. For example, the table for relationship set requestedby could be eliminated by adding a custnum column to table fly (to store the customer number of the customer requesting the fly). Since each fly is requested by exactly one customer: information about a fly never has to be repeated in order to store that multiple customers have requested the fly the column for custnum will never contain null values 8.3 Complex Attributes Composite attributes are handled by flattening them into simple attributes. For example, the table generated from entity set person in Figure 4 would have columns ssn, name, number, street, city, state and zip. Unlike other attribute types, a multivalued attribute is converted to a table. This table has one column for the attribute itself, and additional columns for the primary key attributes of the entity or relationship set that it belongs to. For example, the following entity set employee: ssn name employee dept salary dependents would be reduced to two tables: a table named employee with columns ssn, name, dept and salary a table named (for example) dependents with columns ssn and dependent With these tables, any number of dependents can be stored for any employee, and no null values are needed if an employee has no dependents. If all attributes of the entity or relationship set other than the multivalued attribute are primary key attributes, then only the table constructed from the multivalued attribute is needed. For example, relationship set purchased (from Figure 2) becomes: custnum stocknum pdate 1 3 9/4/ /3/ /8/ /2/ /1/1995 Table 3: purchased In general, all attributes of the table derived from a multivalued attribute are needed to form a primary key. Can you argue that this is true for the employee and purchased tables we have just derived? Additionally, the primary key attributes of the original entity or relationship set become foreign keys referencing the tables derived from those sets. 14

15 8.4 Inheritance Tables for entity sets constructed using inheritance are reduced to tables as follows: 1. construct a table for the higher level entity set as usual 2. for each lower level entity set, construct a table with columns for each attribute of the lower level entity set, and for the primary key attributes of the higher level entity set. For example, the tables for entity sets person, customer and employee in Figure 9 would have the following columns: person: ssn, name, dob customer: ssn, credit employee: ssn, salary, dept Note that {ssn} is the primary key for each of these tables, and that {ssn} in both customer and employee is a foreign key referencing person. If the inheritance relationship is disjoint and complete (i.e. there is no overlap in the lower level entity sets and every higher level entity is also a lower level entity), then another possibility is as follows: no table is created for the higher level entity set each lower level entity set is reduced to a table as usual, except that the attributes of the higher level entity set are added as columns The primary key of each of the tables derived from lower level entity sets is the primary key of the higher level entity set. If the inheritance relationship were not complete, then some entities could not be stored with this representation. If the inheritance relationship were not disjoint, then this representation would have some redundancy. 15

Chapter 2: Entity-Relationship Model. Entity Sets. " Example: specific person, company, event, plant

Chapter 2: Entity-Relationship Model. Entity Sets.  Example: specific person, company, event, plant Chapter 2: Entity-Relationship Model! Entity Sets! Relationship Sets! Design Issues! Mapping Constraints! Keys! E-R Diagram! Extended E-R Features! Design of an E-R Database Schema! Reduction of an E-R

More information

Chapter 2: Entity-Relationship Model. E-R R Diagrams

Chapter 2: Entity-Relationship Model. E-R R Diagrams Chapter 2: Entity-Relationship Model What s the use of the E-R model? Entity Sets Relationship Sets Design Issues Mapping Constraints Keys E-R Diagram Extended E-R Features Design of an E-R Database Schema

More information

2. Conceptual Modeling using the Entity-Relationship Model

2. 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 information

Lesson 8: Introduction to Databases E-R Data Modeling

Lesson 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 information

Chapter 2: Entity-Relationship Model

Chapter 2: Entity-Relationship Model Chapter 2: Entity-Relationship Model Entity Sets Relationship Sets Design Issues Mapping Constraints Keys E R Diagram Extended E-R Features Design of an E-R Database Schema Reduction of an E-R Schema to

More information

Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model

Chapter 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 information

Database Design Overview. Conceptual Design ER Model. Entities and Entity Sets. Entity Set Representation. Keys

Database 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 information

Databases Model the Real World. The Entity- Relationship Model. Conceptual Design. Steps in Database Design. ER Model Basics. ER Model Basics (Contd.

Databases 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 information

Foundations of Information Management

Foundations of Information Management Foundations of Information Management - WS 2012/13 - Juniorprofessor Alexander Markowetz Bonn Aachen International Center for Information Technology (B-IT) Data & Databases Data: Simple information Database:

More information

Conceptual Design Using the Entity-Relationship (ER) Model

Conceptual 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 information

THE ENTITY- RELATIONSHIP (ER) MODEL CHAPTER 7 (6/E) CHAPTER 3 (5/E)

THE ENTITY- RELATIONSHIP (ER) MODEL CHAPTER 7 (6/E) CHAPTER 3 (5/E) THE ENTITY- RELATIONSHIP (ER) MODEL CHAPTER 7 (6/E) CHAPTER 3 (5/E) 2 LECTURE OUTLINE Using High-Level, Conceptual Data Models for Database Design Entity-Relationship (ER) model Popular high-level conceptual

More information

Lecture 6. SQL, Logical DB Design

Lecture 6. SQL, Logical DB Design Lecture 6 SQL, Logical DB Design Relational Query Languages A major strength of the relational model: supports simple, powerful querying of data. Queries can be written intuitively, and the DBMS is responsible

More information

The Relational Model. Ramakrishnan&Gehrke, Chapter 3 CS4320 1

The 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 information

Outline. Data Modeling. Conceptual Design. ER Model Basics: Entities. ER Model Basics: Relationships. Ternary Relationships. Yanlei Diao UMass Amherst

Outline. 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 information

Chapter 3. Data Modeling Using the Entity-Relationship (ER) Model

Chapter 3. Data Modeling Using the Entity-Relationship (ER) Model Chapter 3 Data Modeling Using the Entity-Relationship (ER) Model Chapter Outline Overview of Database Design Process Example Database Application (COMPANY) ER Model Concepts Entities and Attributes Entity

More information

CSC 742 Database Management Systems

CSC 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 information

Lecture 12: Entity Relationship Modelling

Lecture 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 information

Unit 2.1. Data Analysis 1 - V2.0 1. Data Analysis 1. Dr Gordon Russell, Copyright @ Napier University

Unit 2.1. Data Analysis 1 - V2.0 1. Data Analysis 1. Dr Gordon Russell, Copyright @ Napier University Data Analysis 1 Unit 2.1 Data Analysis 1 - V2.0 1 Entity Relationship Modelling Overview Database Analysis Life Cycle Components of an Entity Relationship Diagram What is a relationship? Entities, attributes,

More information

Entity-Relationship Model

Entity-Relationship Model UNIT -2 Entity-Relationship Model Introduction to ER Model ER model is represents real world situations using concepts, which are commonly used by people. It allows defining a representation of the real

More information

Data Analysis 1. SET08104 Database Systems. Copyright @ Napier University

Data Analysis 1. SET08104 Database Systems. Copyright @ Napier University Data Analysis 1 SET08104 Database Systems Copyright @ Napier University Entity Relationship Modelling Overview Database Analysis Life Cycle Components of an Entity Relationship Diagram What is a relationship?

More information

Database Design. Database Design I: The Entity-Relationship Model. Entity Type (con t) Chapter 4. Entity: an object that is involved in the enterprise

Database Design. Database Design I: The Entity-Relationship Model. Entity Type (con t) Chapter 4. Entity: an object that is involved in the enterprise Database Design Database Design I: The Entity-Relationship Model Chapter 4 Goal: specification of database schema Methodology: Use E-R R model to get a high-level graphical view of essential components

More information

Entity-Relationship Model. Purpose of E/R Model. Entity Sets

Entity-Relationship Model. Purpose of E/R Model. Entity Sets Entity-Relationship Model Diagrams Class hierarchies Weak entity sets 1 Purpose of E/R Model The E/R model allows us to sketch the design of a database informally. Designs are pictures called entityrelationship

More information

ER modelling, Weak Entities, Class Hierarchies, Aggregation

ER modelling, Weak Entities, Class Hierarchies, Aggregation CS344 Database Management Systems ER modelling, Weak Entities, Class Hierarchies, Aggregation Aug 2 nd - Lecture Notes (Summary) Submitted by - N. Vishnu Teja Saurabh Saxena 09010125 09010145 (Most the

More information

DATABASE DESIGN. - Developing database and information systems is performed using a development lifecycle, which consists of a series of steps.

DATABASE DESIGN. - Developing database and information systems is performed using a development lifecycle, which consists of a series of steps. DATABASE DESIGN - The ability to design databases and associated applications is critical to the success of the modern enterprise. - Database design requires understanding both the operational and business

More information

The Relational Model. Why Study the Relational Model? Relational Database: Definitions. Chapter 3

The 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 information

Bridge from Entity Relationship modeling to creating SQL databases, tables, & relations

Bridge 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 information

Data 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 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 information

www.gr8ambitionz.com

www.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 information

Database Management Systems

Database Management Systems Database Management Systems Database Design (1) 1 Topics Information Systems Life Cycle Data Base Design Logical Design Physical Design Entity Relationship (ER) Model Entity Relationship Attributes Cardinality

More information

not necessarily strictly sequential feedback loops exist, i.e. may need to revisit earlier stages during a later stage

not necessarily strictly sequential feedback loops exist, i.e. may need to revisit earlier stages during a later stage Database Design Process there are six stages in the design of a database: 1. requirement analysis 2. conceptual database design 3. choice of the DBMS 4. data model mapping 5. physical design 6. implementation

More information

Exercise 1: Relational Model

Exercise 1: Relational Model Exercise 1: Relational Model 1. Consider the relational database of next relational schema with 3 relations. What are the best possible primary keys in each relation? employ(person_name, street, city)

More information

7.1 The Information system

7.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 information

Modern Systems Analysis and Design

Modern 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 information

There are five fields or columns, with names and types as shown above.

There are five fields or columns, with names and types as shown above. 3 THE RELATIONAL MODEL Exercise 3.1 Define the following terms: relation schema, relational database schema, domain, attribute, attribute domain, relation instance, relation cardinality, andrelation degree.

More information

The Entity-Relationship Model

The Entity-Relationship Model The Entity-Relationship Model Chapter 2 Slides modified by Rasmus Pagh for Database Systems, Fall 2006 IT University of Copenhagen Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Today

More information

The E-R èentity-relationshipè data model views the real world as a set of basic objects èentitiesè and

The E-R èentity-relationshipè data model views the real world as a set of basic objects èentitiesè and CMPT-354-Han-95.3 Lecture Notes September 20, 1995 Chapter 2 The Entity-Relationship Model The E-R èentity-relationshipè data model views the real world as a set of basic objects èentitiesè and relationships

More information

Review: Participation Constraints

Review: Participation Constraints Review: Participation Constraints Does every department have a manager? If so, this is a participation constraint: the participation of Departments in Manages is said to be total (vs. partial). Every did

More information

2. Basic Relational Data Model

2. Basic Relational Data Model 2. Basic Relational Data Model 2.1 Introduction Basic concepts of information models, their realisation in databases comprising data objects and object relationships, and their management by DBMS s that

More information

Foundations of Information Management

Foundations of Information Management Foundations of Information Management - WS 2009/10 Juniorprofessor Alexander Markowetz Bonn Aachen International Center for Information Technology (B-IT) Alexander Markowetz Born 1976 in Brussels, Belgium

More information

The Entity-Relationship Model

The 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 information

Data Modeling Basics

Data 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 information

The Entity-Relationship Model

The Entity-Relationship Model The Entity-Relationship Model Overview of Database Design Requirements analysis Conceptual design data model Logical design Schema refinement: Normalization Physical tuning Conceptual Design Entities Conceptual

More information

CS 4604: Introduc0on to Database Management Systems. B. Aditya Prakash Lecture #5: En-ty/Rela-onal Models- - - Part 1

CS 4604: Introduc0on to Database Management Systems. B. Aditya Prakash Lecture #5: En-ty/Rela-onal Models- - - Part 1 CS 4604: Introduc0on to Database Management Systems B. Aditya Prakash Lecture #5: En-ty/Rela-onal Models- - - Part 1 Announcements- - - Project Goal: design a database system applica-on with a web front-

More information

Databases and BigData

Databases 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 information

XV. The Entity-Relationship Model

XV. The Entity-Relationship Model 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 The

More information

IT2305 Database Systems I (Compulsory)

IT2305 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 information

A brief overview of developing a conceptual data model as the first step in creating a relational database.

A 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 information

BİL 354 Veritabanı Sistemleri. Entity-Relationship Model

BİL 354 Veritabanı Sistemleri. Entity-Relationship Model BİL 354 Veritabanı Sistemleri Entity-Relationship Model Steps in building a DB application Pick application domain Conceptual design How can I describe that data? What data do I need for my application

More information

We know how to query a database using SQL. A set of tables and their schemas are given Data are properly loaded

We know how to query a database using SQL. A set of tables and their schemas are given Data are properly loaded E-R Diagram Database Development We know how to query a database using SQL A set of tables and their schemas are given Data are properly loaded But, how can we develop appropriate tables and their schema

More information

Database Design Process

Database Design Process Database Design Process Entity-Relationship Model From Chapter 5, Kroenke book Requirements analysis Conceptual design data model Logical design Schema refinement: Normalization Physical tuning Problem:

More information

Information Systems 2. 1. Modelling Information Systems I: Databases

Information 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 information

Database Design Process

Database Design Process Entity-Relationship Model Chapter 3, Part 1 Database Design Process Requirements analysis Conceptual design data model Logical design Schema refinement: Normalization Physical tuning 1 Problem: University

More information

IV. The (Extended) Entity-Relationship Model

IV. The (Extended) Entity-Relationship Model IV. The (Extended) Entity-Relationship Model The Extended Entity-Relationship (EER) Model Entities, Relationships and Attributes Cardinalities, Identifiers and Generalization Documentation of EER Diagrams

More information

Entity Relationship Diagram

Entity Relationship Diagram Yufei Tao Department of Computer Science and Engineering Chinese University of Hong Kong A primary goal of database design is to decide what tables to create. Usually, there are two principles: 1 Capture

More information

Data Modeling: Part 1. Entity Relationship (ER) Model

Data Modeling: Part 1. Entity Relationship (ER) Model Data Modeling: Part 1 Entity Relationship (ER) Model MBA 8473 1 Cognitive Objectives (Module 2) 32. Explain the three-step process of data-driven information system (IS) development 33. Examine the purpose

More information

IT2304: Database Systems 1 (DBS 1)

IT2304: 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 information

Database Fundamentals: 1

Database Fundamentals: 1 Database Fundamentals Robert J. Robbins Johns Hopkins University rrobbins@gdb.org Database Fundamentals: 1 What is a Database? General: A database is any collection of related data. Restrictive: A database

More information

Chapter 10. Functional Dependencies and Normalization for Relational Databases

Chapter 10. Functional Dependencies and Normalization for Relational Databases Chapter 10 Functional Dependencies and Normalization for Relational Databases Chapter Outline 1 Informal Design Guidelines for Relational Databases 1.1Semantics of the Relation Attributes 1.2 Redundant

More information

Database Design. Marta Jakubowska-Sobczak IT/ADC based on slides prepared by Paula Figueiredo, IT/DB

Database 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 information

Concepts of Database Management Seventh Edition. Chapter 6 Database Design 2: Design Method

Concepts of Database Management Seventh Edition. Chapter 6 Database Design 2: Design Method Concepts of Database Management Seventh Edition Chapter 6 Database Design 2: Design Method Objectives Discuss the general process and goals of database design Define user views and explain their function

More information

Relational model. Relational model - practice. Relational Database Definitions 9/27/11. Relational model. Relational Database: Terminology

Relational 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 information

Database Design Methodology

Database Design Methodology Topic 7 Database Design Methodology LEARNING OUTCOMES When you have completed this Topic you should be able to: 1. Discuss the purpose of a design methodology. 2. Explain three main phases of design methodology.

More information

three Entity-Relationship Modeling chapter OVERVIEW CHAPTER

three Entity-Relationship Modeling chapter OVERVIEW CHAPTER three Entity-Relationship Modeling CHAPTER chapter OVERVIEW 3.1 Introduction 3.2 The Entity-Relationship Model 3.3 Entity 3.4 Attributes 3.5 Relationships 3.6 Degree of a Relationship 3.7 Cardinality of

More information

The Relational Model. Why Study the Relational Model?

The 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 information

2. Supports eæcient access to very large amounts

2. Supports eæcient access to very large amounts What is a Database Management System? 1. Manages very large amounts of data. 2. Supports ecient access to very large amounts of data. 3. Supports concurrent access to v.l.a.d. 4. Supports secure, atomic

More information

Winter 2003 1. Winter 2003 2

Winter 2003 1. Winter 2003 2 M Today s Lecture Database design through ER diagrams Creating and modifying relations, specifying integrity constraints using SQL Translate ER diagrams to relations A little on views Winter 2003 1 ai

More information

Converting E-R Diagrams to Relational Model. Winter 2006-2007 Lecture 17

Converting E-R Diagrams to Relational Model. Winter 2006-2007 Lecture 17 Converting E-R Diagrams to Relational Model Winter 2006-2007 Lecture 17 E-R Diagrams Need to convert E-R model diagrams to an implementation schema Easy to map E-R diagrams to relational model, and then

More information

The Relational Data Model: Structure

The Relational Data Model: Structure The Relational Data Model: Structure 1 Overview By far the most likely data model in which you ll implement a database application today. Of historical interest: the relational model is not the first implementation

More information

SQL DDL. DBS Database Systems Designing Relational Databases. Inclusion Constraints. Key Constraints

SQL DDL. DBS Database Systems Designing Relational Databases. Inclusion Constraints. Key Constraints DBS Database Systems Designing Relational Databases Peter Buneman 12 October 2010 SQL DDL In its simplest use, SQL s Data Definition Language (DDL) provides a name and a type for each column of a table.

More information

Database Design. Goal: specification of database schema Methodology: E-R Model is viewed as a set of

Database Design. Goal: specification of database schema Methodology: E-R Model is viewed as a set of Database Design Goal: specification of database schema Methodology: Use E-R model to get a high-level graphical view of essential components of the model and how they are related Convert E-R diagram to

More information

Designing Databases. Introduction

Designing 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 information

Requirement 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 Requirement Analysis & Conceptual Database Design Problem analysis Entity Relationship notation Integrity constraints Generalization Introduction: Lifecycle Requirement analysis -> Text Conceptual Design

More information

Normalization in OODB Design

Normalization 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 information

Chapter 1: Introduction. Database Management System (DBMS) University Database Example

Chapter 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 information

LOGICAL DATABASE DESIGN

LOGICAL 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 information

Database Systems. Session 2 Main Theme. Relational Data. & Relational Database Constraints Dr. Jean-Claude Franchitti

Database Systems. Session 2 Main Theme. Relational Data. & Relational Database Constraints Dr. Jean-Claude Franchitti Database Systems Session 2 Main Theme Relational Data Model & Relational Database Constraints Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical

More information

Theory of Relational Database Design and Normalization

Theory of Relational Database Design and Normalization Theory of Relational Database Design and Normalization (Based on Chapter 14 and some part of Chapter 15 in Fundamentals of Database Systems by Elmasri and Navathe, Ed. 3) 1 Informal Design Guidelines for

More information

CMPT 354 Database Systems. Simon Fraser University Summer 2016. Instructor: Oliver Schulte

CMPT 354 Database Systems. Simon Fraser University Summer 2016. Instructor: Oliver Schulte CMPT 354 Database Systems Simon Fraser University Summer 2016 Instructor: Oliver Schulte Assignment 1: Entity-Relationship Modeling. The Relational Model. MS SQL Server. Instructions: Check the instructions

More information

1 Class Diagrams and Entity Relationship Diagrams (ERD)

1 Class Diagrams and Entity Relationship Diagrams (ERD) 1 Class Diagrams and Entity Relationship Diagrams (ERD) Class diagrams and ERDs both model the structure of a system. Class diagrams represent the dynamic aspects of a system: both the structural and behavioural

More information

3. Relational Model and Relational Algebra

3. Relational Model and Relational Algebra ECS-165A WQ 11 36 3. Relational Model and Relational Algebra Contents Fundamental Concepts of the Relational Model Integrity Constraints Translation ER schema Relational Database Schema Relational Algebra

More information

Fundamentals of Database Design

Fundamentals 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 information

EECS 647: Introduction to Database Systems

EECS 647: Introduction to Database Systems EECS 647: Introduction to Database Systems Instructor: Luke Huan Spring 2013 Administrative Take home background survey is due this coming Friday The grader of this course is Ms. Xiaoli Li and her email

More information

Fundamentals of Database System

Fundamentals 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 information

Relational Schema Design

Relational Schema Design Relational Schema Design Using ER Methodology to Design Relational Database Schemas The Development Process Collect requirements. Analyze the requirements. Conceptually design the data (e.g., draw an ER

More information

Database Design Process. Databases - Entity-Relationship Modelling. Requirements Analysis. Database Design

Database Design Process. Databases - Entity-Relationship Modelling. Requirements Analysis. Database Design Process Databases - Entity-Relationship Modelling Ramakrishnan & Gehrke identify six main steps in designing a database Requirements Analysis Conceptual Design Logical Design Schema Refinement Physical

More information

Database Design. Adrienne Watt. Port Moody

Database Design. Adrienne Watt. Port Moody Database Design Database Design Adrienne Watt Port Moody Except for third party materials and otherwise stated, content on this site is made available under a Creative Commons Attribution 2.5 Canada License.

More information

Database Design Methodology

Database Design Methodology Database Design Methodology Three phases Database Design Methodology Logical database Physical database Constructing a model of the information used in an enterprise on a specific data model but independent

More information

The Relational Model. Why Study the Relational Model? Relational Database: Definitions

The 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 information

Lecture Notes INFORMATION RESOURCES

Lecture 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 information

About the Tutorial. Audience. Prerequisites. Copyright & Disclaimer

About the Tutorial. Audience. Prerequisites. Copyright & Disclaimer About the Tutorial Database Management System or DBMS in short refers to the technology of storing and retrieving users data with utmost efficiency along with appropriate security measures. DBMS allows

More information

Database IST400/600. Jian Qin. A collection of data? A computer system? Everything you collected for your group project?

Database IST400/600. Jian Qin. A collection of data? A computer system? Everything you collected for your group project? Relational Databases IST400/600 Jian Qin Database A collection of data? Everything you collected for your group project? A computer system? File? Spreadsheet? Information system? Date s criteria: Integration

More information

14 Databases. Source: Foundations of Computer Science Cengage Learning. Objectives After studying this chapter, the student should be able to:

14 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 information

Conceptual Design: Entity Relationship Models. Objectives. Overview

Conceptual Design: Entity Relationship Models. Objectives. Overview Conceptual Design: Entity Relationship Models Craig Van Slyke, University of Central Florida cvanslyke@bus.ucf.edu John Day, Ohio University Objectives Define terms related to entity relationship modeling,

More information

BCA. Database Management System

BCA. 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 information

AS LEVEL Computer Application Databases

AS 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 information

DataBase Management Systems Lecture Notes

DataBase Management Systems Lecture Notes 1 SHRI VISHNU ENGINEERING COLLEGE FOR WOMEN::BHIMAVARAM DEPARTMENT OF INFORMATION TECHNOLOGY DataBase Management Systems Lecture Notes UNIT-1 Data: It is a collection of information. The facts that can

More information

DBMS Questions. 3.) For which two constraints are indexes created when the constraint is added?

DBMS Questions. 3.) For which two constraints are indexes created when the constraint is added? DBMS Questions 1.) Which type of file is part of the Oracle database? A.) B.) C.) D.) Control file Password file Parameter files Archived log files 2.) Which statements are use to UNLOCK the user? A.)

More information

DATABASE INTRODUCTION

DATABASE INTRODUCTION Introduction The history of database system research is one of exceptional productivity and startling economic impact. We have learnt that from the days of file-based systems there are better ways to handle

More information

CS 377 Database Systems. Database Design Theory and Normalization. Li Xiong Department of Mathematics and Computer Science Emory University

CS 377 Database Systems. Database Design Theory and Normalization. Li Xiong Department of Mathematics and Computer Science Emory University CS 377 Database Systems Database Design Theory and Normalization Li Xiong Department of Mathematics and Computer Science Emory University 1 Relational database design So far Conceptual database design

More information

1 File Processing Systems

1 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 information