1 Logical Database Design and the Relational Model (Significant Concepts) Learning Objectives This topic is intended to introduce the Logical Database Design and the Relational Model. At the end of the topic it is desired from the reader to be able to: Concisely define each of the following key terms: Key or Primary Key Surrogate Primary Key Second Normal Form Foreign Key Recursive Foreign Key Partial Functional Null Values Normalization Dependency Entity Integrity Rule Normal Form Third Normal Form Referential Integrity Functional Dependency Transitive Dependency Constraint Determinant Synonyms, Homonym Well-Structured Relation Candidate Key and Alias Database Anomalies First Normal Form Enterprise Key List five properties of relations. State two essential properties of a candidate key. Give a concise definition of each of the following: first normal form, second normal form, and third normal form. Briefly describe four problems that may arise when merging relations. Transform an E-R (or EER) diagram into a logically equivalent set of relations. Create relational tables that incorporate entity integrity and referential integrity constraints. Use normalization to decompose a relation with anomalies into well-structured relations. 1. Introduction Logical Database Design is the process of transforming the conceptual data model into a logical data model. The logical data model is consistent and compatible with a specific type of database technology. Conceptual data modeling is about understanding the organization getting the right requirements. While Logical database design is about creating stable database structures correctly expressing the requirements in a technical language. The objective of logical database design is to translate the conceptual design (which represents an organization s requirements for data) into a logical database design that can be implemented by using a chosen database management system. The resulting databases must meet the user needs for data sharing, flexibility, and ease of access. An experienced database designer often will do logical database design in parallel with conceptual data modeling if he knows the type of database technology that will be used. Although there are other data models, we have two reasons for emphasizing the relational data model. First, this model is the one most commonly used in contemporary database applications. Second, some of the principles of logical database design for the relational model apply to the other logical models as well. The Relational Data Model is a form of logical data model, and as such it is different from the conceptual data models. The E-R data model is not a relational data model, and an E-R model may not obey the rules for a well-structured relational data model, called normalization. The E-R model was developed for other purposes like understanding data requirements and business rules about the data not structuring the data for sound database processing, which is the goal of logical database design.
2 The process of transforming an Entity Relational model into the relational model is supported by Many CASE tools today at the technical level; however, it is important that you understand the underlying principles and procedures. Normalization is the process of designing well-structured relations. It is an important component of logical design for the relational model. 2. The Relational Data Model The Relational Data Model was first introduced in 1970 by E. F. Codd. In the beginning some early research projects were launched to prove the feasibility of the relational model and to develop prototype systems. Commercial RDBMS products started to appear about Today RDBMSs have become the dominant technology for database management, and there are literally hundreds of RDBMS products for computers ranging from smartphones and personal computers to mainframes. Basic Definitions The relational data model represents data in the form of tables or Relations. The Model is based on mathematical theory and therefore has a solid theoretical foundation. It consists of the following three components: Data Structure: Data are organized in the form of tables, with rows and columns. Data Manipulation: Powerful operations (using the SQL language) are used to manipulate data stored in the relations. Data Integrity: The model includes mechanisms to specify business rules that maintain the integrity of data when they are manipulated. Relational Data Structure A Relation is a named, two-dimensional table of data. An Attribute is a named column of a relation. We can express the structure of a relation by using its name followed (in parentheses) by the names of the attributes in that relation. Each relation (or table) consists of a set of named columns and an arbitrary number of unnamed rows (records). Each row of a relation corresponds to a record that contains data (attribute) values for a single entity. Addition or Deletion or records (rows) does not change the relation. In fact, we could delete all of the rows of a relation without losing its structure. Relational Keys We must be able to store and retrieve a row of data in a relation, based on the data values stored in that row. To achieve this goal, every relation must have a primary key. A Primary Key is an attribute or a combination of attributes that uniquely identifies each row in a relation. We designate a primary key by underlining the attribute name(s). The concept of a primary key is related to the term identifier. The same attribute or a collection of attributes indicated as an entity s identifier in an E-R diagram may be the same attributes that compose the primary key for the relation representing that entity. Associative entities do not have to have an identifier, and the (partial) identifier of a weak entity forms only part of a weak entity s primary key. There may be several attributes of an entity that may serve as the associated relation s primary key. A Composite Key is a primary key that consists of more than one attribute. For example, the primary key for a relation DEPENDENT would likely consist of the combination EmpID and DependentName.
3 Often we need to represent the relationship between two tables or relations. This is accomplished through the use of foreign keys. A Foreign Key is an attribute (possibly composite) in a relation that serves as the primary key of another relation. Properties Of Relations Relations have following properties that distinguish them from non-relational tables. a) Each relation (or table) in a database has a unique name. b) There can be only one value associated with each attribute on a specific row of a table; no multivalued attributes are allowed in a relation. Alternatively it can be said that an entry at the intersection of each row and column is Atomic (Or Single Valued). c) Each row is unique; no two rows in a relation can be identical. d) Each attribute (or column) within a table has a unique name. e) The sequence of columns (left to right) is insignificant. The order of the columns in a relation can be changed without changing the meaning or use of the relation. f) The sequence of rows (top to bottom) is insignificant. As with columns, the order of the rows of a relation may be changed or stored in any sequence. Database Schema A relational database may consist of any number of relations. The structure of the database is described through the use of a Schema, which is a description of the overall logical structure of the database. There are two common methods for expressing a schema: a) Short text statements, in which each relation is named and the names of its attributes follow in parentheses. b) A graphical representation, in which each relation is represented by a rectangle containing the attributes for the relation. Text statements have the advantage of simplicity. However, a graphical representation provides a better means of expressing referential integrity constraints. A schema for four relations at Pine Valley Furniture Company It is a good idea to create an instance of your relational schema with sample data for four reasons: a) The sample data allow you to test your assumptions regarding the design. b) The sample data provide a convenient way to check the accuracy of your design. c) The sample data help improve communications with users in discussing your design. d) You can use the sample data to develop prototype applications and to test queries. Integrity Constraints The relational data model has several types of constraints or rules to ensure the database integrity. These constraints control the acceptable data values and actions on the data. They also facilitates the DBMS to maintain accuracy and integrity of the data in the database. The major types of integrity constraints are Domain Constraints, Entity Integrity, and Referential Integrity.
4 a) Domain Constraints A domain is the set of values that may be assigned to an attribute. All of the values that appear in a column of a relation must be from the same domain. A domain definition usually consists of the following components: domain name, meaning, data type, size (or length), and allowable values or allowable range (if applicable). b) Entity Integrity The entity integrity rule is designed to ensure that every relation has a primary key and that the data values for that primary key are all valid. In particular, it guarantees that every primary key attribute is non-null. In some cases, a particular attribute cannot be assigned a data value. There are two situations in which this is likely to occur: Either there is no applicable data value or the applicable data value is not known when values are assigned. The relational data model allows us to assign a null value to an attribute in the just described situations. A Null is a value that may be assigned to an attribute when no other value applies or when the applicable value is unknown. In reality, a null is not a value but rather it indicates the absence of a value. For example, it is not the same as a numeric zero or a string of blanks. The inclusion of nulls in the relational model is somewhat controversial, because it sometimes leads to anomalous results (Date, 2003). Entity integrity rule states that No primary key attribute (or component of a primary key attribute) may be null. c) Referential Integrity In the relational data model, associations between tables are defined through the use of foreign keys. A Referential Integrity Constraint is a rule that maintains consistency among the rows of two relations. The rule states that if there is a foreign key in one relation, either each foreign key value must match a primary key value in another relation or the foreign key value must be null. A referential integrity constraint must be defined for each of these arrows in the schema. If the relationship is optional, then the foreign key could be null. Whether a foreign key can be null must be specified as a property of the foreign key attribute when the database is defined. Actually, whether a foreign key can be null is more complex to model on an E-R diagram and to determine than we have shown so far. For example, what happens to Referential Data if we choose to delete a Primary Key. Three choices are possible: a) Delete the associated Records b) Prohibit deletion of the Primary Key until all Referential Data are first deleted c) Place a null value in the foreign key and keep the Referential Data. In practice, organizational rules and various regulations regarding data retention determine what data can be deleted and when, and they therefore govern the choice between various deletion options. Well-Structured Relations A well-structured relation contains minimal redundancy and allows users to insert, modify, and delete the rows in a table without errors or inconsistencies. Redundancies in a table may result in errors or inconsistencies (called anomalies) when a user attempts to update the data in the table. Anomaly is an error or inconsistency that may result when a user attempts to update a table that contains redundant data. The three types of anomalies are insertion, deletion, and modification anomalies. a) Insertion anomaly A relation has insertion anomaly if does not allow insertion of some of the attributes of a relation unless the values for some specific or all attributes are provided.
5 A Relation having a Composite Primary Key does not allow insertion of any other attribute unless all parts of the composite key are inserted. A composite key having combination of Emp_ID and Course_Title requires that the user must supply values for both Emp_ID and Course_Title to insert any other attribute of a record. b) Deletion anomaly A relation has the deletion anomaly if the deletion operation on it causes deletion of some required attributes. For example deletion of a record from the Employee table may cause deletion of the department information. c) Modification anomaly A relation has the modification anomaly if the modification or update operation results in inconsistency in some other records in the relation. 3. Transforming EER Diagrams Into Relations The logical design transforms the E-R (and EER) diagrams that were developed during conceptual design into relational database schemas. The inputs to this process are the Entity-Relationship (and Enhanced E-R) diagrams while the outputs are the relational schemas. Transforming the EER diagrams into relations is a straightforward process with a well-defined set of rules. Database designer can use the CASE tools to perform many of the conversion steps. Nevertheless it is required to have understanding of the conversion process because of the following reasons: a) CASE tools often cannot model more complex data relationships such as ternary relationships and supertype/subtype relationships. In these situations, you may have to perform the steps manually. b) There are sometimes legitimate alternatives where you will need to choose a particular solution. c) You must be prepared to perform a quality check on the results obtained with a CASE tool. d) Understanding the transformation process helps you understand why conceptual data modeling (modeling the real-world domain). Mapping the Regular Entities Regular Entities are entities that have an independent existence and generally represent real-world objects, such as persons and products. Each regular entity type in an E-R diagram is transformed into a relation. Regular entity types are represented by rectangles with a single line. The name given to the relation is generally the same as the entity type. Each simple attribute of the entity type becomes an attribute of the relation. The identifier of the entity type becomes the primary key of the corresponding relation. Mapping the Composite Attributes: When a regular entity type has a Composite Attribute, we split it into its simple components and include the each component separately in the relation. Mapping the Multivalued Attribute When the regular entity type contains a Multivalued Attribute, two new relations (rather than one) are created. The first relation contains all of the attributes of the entity type except the multivalued attribute. The second relation contains two attributes that form the primary key of the second relation. The first of these attributes is the primary key from the first relation, which becomes a foreign key in the second relation. If an entity type contains multiple multivalued attributes, each of them will be converted to a separate relation. Mapping the Weak Entities The weak entity type does not have an independent existence but exists only through an identifying relationship with another entity type called the owner. Weak entities are identified by a rectangle with a double line.
6 A weak entity type does not have a complete identifier but must have an attribute called a partial identifier that permits distinguishing the various occurrences of the weak entity for each owner entity instance. For each weak entity type, create a new relation and include all of the simple attributes (or simple components of composite attributes) as attributes of this relation. Then include the primary key of the identifying relation as a foreign key attribute in this new relation. The primary key of the new relation is the combination of this primary key of the identifying and the partial identifier of the weak entity type. An alternative approach to simplify the primary key of the DEPENDENT relation is use of the surrogate key. Surrogate Primary Key It is a serial number or other system assigned primary key for a relation. A surrogate key is usually created to simplify the key structures. It is recommended to create a surrogate key when any of the following conditions hold: There is a composite primary key. The natural primary key (i.e., the key used in the organization and identified in conceptual data modeling as the identifier) is inefficient (e.g., it may be very long ) The natural primary key is recycled (i.e., the key is reused or repeated periodically) Whenever a surrogate key is created, the natural key is always kept as non-key data in the same relation because the natural key has organizational meaning. In fact, surrogate keys mean nothing to the end users, so they are usually never displayed; rather, the natural keys are shown to the user as the primary keys and used as identifiers in searches. Map Binary Relationships The procedure for representing relationships depends on both the degree of the relationships (unary, binary, or ternary) and the cardinalities of the relationships. To map a Binary: One to Many (1:M) relationship: First create a relation for each of the two entity types participating in the relationship. Next, include the primary key attribute(s) of the entity on the one-side of the relationship as a foreign key in the relation that is on the many-side of the relationship. (The primary key migrates to the many side.) To map a Binary: Many to Many (M:N) relationship: Suppose that there is a binary many-to-many (M: N) relationship between two entity types, A and B. Create a new relation, C. Include as foreign key attributes in C the primary key for each of the two participating entity types. These attributes together become the primary key of C. Any non-key attributes that are associated with the relationship are included in the relation C. To map a Binary: One to One (1:1) relationship: First create a relation for each of the two entity types participating in the relationship. Second, the primary key of one of the relations is included as a foreign key in the other relation. In a 1:1 relationship, the association in one direction is nearly always an optional one, whereas the association in the other direction is mandatory one. Include in the relation on the optional side of the relationship the foreign key of the entity type that has the mandatory participation in the 1:1 relationship. This approach will prevent the need to store null values in the foreign key attribute. It is also recommended to use the Primary key of the relation having more durable records, as the foreign key in the other relation.
7 Map Associative Entities (also called Gerunds) The Associative Entities are formed from many-to-many relationships between other entity types. In ER-Diagram these entities are represented by a rectangle with rounded corners. Mapping the associative entity involves essentially the same steps as mapping an M:N relationship. First, create three relations: one for each of the two participating entity types and a third relation (associative relation) for the associative entity. Second step then depends on whether on the E-R diagram an identifier was assigned to the associative entity. o If an identifier was not assigned, the default primary key for the associative relation consists of the two primary key attributes from the other two relations. These attributes are then foreign keys that reference the other two relations. o If an identifier was assigned, the primary key for this relation is the identifier assigned on the E-R diagram (rather than the default key). The primary keys for the two participating entity types are then included as foreign keys in the associative relation Map Unary Relationships A unary relationship as a relationship between the instances of a single entity type. Unary relationships are also called Recursive Relationships. The two most important cases of unary relationships are one-to-many and many-to-many relationships. Mapping the Unary One-To-Many Relationships A relation is created to map the entity type in the unary relationship. Then a foreign key attribute is added to the same relation; this attribute references the primary key values in the same relation. (This foreign key must have the same domain as the primary key.) This type of a foreign key is called a Recursive Foreign Key. Unary Many-To-Many Relationships With this type of relationship, two relations are created: one to represent the entity type in the relationship and an associative relation to represent the M: N relationship itself. The primary key of the associative relation consists of two attributes. These attributes (which need not have the same name) both take their values from the primary key of the other relation. Any non-key attribute of the relationship is included in the associative relation. Map Ternary (and N-Ary) Relationships A ternary relationship is a relationship among three entity types. It is recommended to convert a ternary relationship to an associative entity to represent participation constraints more accurately. To map an associative entity type that links three regular entity types: We create a new associative relation. The default primary key of this relation consists of the three primary key attributes for the participating entity types. (In some cases, additional attributes are required to form a unique primary key.) These attributes then act in the role of foreign keys that reference the individual primary keys of the participating entity types. Any attributes of the associative entity type become attributes of the new relation. Map Supertype/Subtype Relationships The relational data model does not directly support supertype/subtype relationships. So various strategies are used to represent these relationships. A commonly used strategy is following: e) Create a separate relation for the supertype and for each of its subtypes.
8 f) Assign to the relation created for the supertype the attributes that are common to all members of the supertype, including the primary key. g) Assign to the relation for each subtype the primary key of the supertype and only those attributes that are unique to that subtype. h) Assign one (or more) attributes of the supertype to function as the subtype discriminator. 4. Introduction to Normalization Normalization is the process of successively reducing relations with anomalies to produce smaller, wellstructured relations. Normalization is a formal process for deciding which attributes should be grouped together in a relation so that all the database anomalies are removed. The Normalization is a state of a relation that requires that certain rules regarding relationships between attributes (or functional dependencies) are satisfied. We need formal definitions of such relations, together with a process for designing them. Two Major Occasions during the overall database development process to benefit from the normalization: a) During logical database design you should use normalization concepts as a quality check for the relations that are obtained from mapping E-R diagrams.
9 b) When reverse-engineering older systems many of the tables and user views for older systems are redundant and subject to the anomalies. Goals of the Database Normalization a) Minimize data redundancy, thereby avoiding anomalies and saving storage space b) Simplify the enforcement of referential integrity constraints c) Make it easier to maintain data (insert, update, and delete) d) Provide a better design that is an improved representation of the real world and a stronger basis for future growth Normalization makes no assumptions about how data will be used in displays, queries, or reports. It is based on what we will call normal forms and functional dependencies, defines rules of the business, not data usage. Further, remember that data are normalized by the end of logical database design. Thus, normalization places no constraints on how data can or should be physically stored or, therefore, on processing performance. Normalization is a logical data modeling technique used to ensure that data are well structured from an organization-wide view. Steps in Normalization Normalization can be accomplished and understood in stages (Normal forms). A normal form is a state of a relation that requires that certain rules regarding relationships between attributes (or functional dependencies) are satisfied. 1. First Normal Form (1NF) A relation is in First Normal Form if: It does not contain the repeating groups of attributes in it. 2. Second Normal Form (2NF) A relation is in Second Normal Form if: It is in First Normal Form AND Any partial functional dependencies have been removed (i.e., non-key attributes are identified by the whole primary key). 3. Third Normal Form (3NF) A relation is in Third normal form if: It is in Second Normal Form AND Any transitive dependencies have been removed (i.e. non-key attributes are identified by only the primary key). 4. Boyce-Codd Normal Form (BCNF) A relation R, is in Boyce-Codd Normal Form if: It is in Third Normal Form AND For every FD X Y in the Relation R, X is a Super Key. 5. Fourth Normal Form (4NF) A relation R, is in Fourth Normal Form if: It is in Boyce-Codd Normal Form (BCNF) AND Any Multivalued Dependencies have been removed. 6. Fifth Normal Form (5NF) A relation R, is in Boyce-Codd Normal Form (BCNF) if: It is in Third Normal Form AND There is no Projection Join-dependency (PJD) in it.
10 Functional Dependencies and Keys Up to the Boyce-Codd normal form, normalization is based on the analysis of functional dependencies. A functional dependency is a constraint between two attributes or two sets of attributes. For any relation R, attribute B is functionally dependent on attribute A if, for every valid instance of A, that value of A uniquely determines the value of B. The functional dependency of B on A is represented by an arrow: A B. A functional dependency is not a mathematical dependency: B cannot be computed from A. Rather, if you know the value of A, there can be only one value for B. An attribute may be functionally dependent on a combination of two (or more) attributes rather than on a single attribute. For example: EmpID, Course_Title Date_Completed The functional dependency in this statement implies that the date of a course completion is determined by the identity of the employee and the title of the course. Typical examples of functional dependencies are the following: CNIC_No. Name, Address, Birthdate A person s name, address, and birth date are functionally dependent on that person s Social Security number (in other words, there can be only one Name, one Address, and one Birthdate for each SSN). VIN Make, Model, Color The make, model, and color of a vehicle are functionally dependent on the vehicle identification number (there can be only one value of Make, Model, and Color associated with each VIN). ISBN Title, FirstAuthorName, Publisher The title of a book, the name of the first author, and the publisher are functionally dependent on the book s international standard book number (ISBN).
11 Determinants The attribute on the left side of the arrow in a functional dependency is called a determinant. SSN, VIN, and ISBN are determinants (respectively) in the preceding three examples. In the EMP COURSE relation, the combination of EmpID and CourseTitle is a determinant. Candidate Keys A candidate key is an attribute, or combination of attributes, that uniquely identifies a row in a relation. A candidate key must satisfy the following properties, which are a subset of the six properties of a relation previously listed: 1. Unique Identification: For every row, the value of the key must uniquely identify that row. This property implies that each non-key attribute is functionally dependent on that key. 2. Non Redundant: No attribute in the key can be deleted without destroying the property of unique identification. A candidate key is always a determinant, whereas a determinant may or may not be a candidate key. A candidate key is a determinant that uniquely identifies the remaining (non-key) attributes in a relation. A determinant may be a candidate key, part of a composite candidate key, or a non-key attribute. 5. Achieving the Normalization Forms We are required to take multiple steps to achieve the various normal forms. Convert to First Normal Form (1NF) A relation is in first normal form (1NF) if it satisfies the following two constraints: 1. The relation has a Primary Key, which uniquely identifies each row in the relation. 2. There are No Repeating Groups in the relation. So, there is a single fact at the intersection of each row and column of the table. Remember that removal of the repeating groups does not ensure a well-structured relation. So the relation in 1NF may have Insertion, Deletion and the Update anomalies. Anomalies in First Normal Form (1NF) 1) Insertion Anomaly A relation has Insertion Anomaly If it is not possible to insert some attributes of a record in it without providing the some other attributes of the record. OR If insertion of some of the attributes of the relation requires us to insert repeatedly, some other attributes of the same record. This leads to data replication and potential data entry errors. 2) Deletion Anomaly A relation has Deletion Anomaly If it is not possible to delete some attributes of a record in it without Losing some other attributes of the record, those are required. 3) Update Anomaly A relation has Update Anomaly If update in a single record ( or row ) causes update in some other rows of the relation. Convert to Second Normal Form A relation is in second normal form (2NF) if it is in first normal form and contains no partial functional dependencies. A partial functional dependency exists when a non-key attribute is functionally dependent on part (but not all) of the primary key. To convert a relation with partial dependencies to second normal form, the following steps are required:
12 1. Create a new relation for each primary key attribute (or combination of attributes) that is a determinant in a partial dependency. That attribute is the primary key in the new relation. 2. Move the non-key attributes that are dependent on this primary key attribute (or attributes) from the old relation to the new relation. Removal of the partial dependencies results in the formation of multiple new relations: Remember that a relation that is in first normal form will be in second normal form if any one of the following conditions applies: 1. The primary key consists of only one attribute (it is not composite). By definition, there cannot be a partial dependency in such a relation. 2. No non-key attributes exist in the relation (thus all of the attributes in the relation are components of the primary key). There are no functional dependencies in such a relation. 3. Every non-key attribute is functionally dependent on the full set of primary key attributes. Convert to Third Normal Form A relation is in third normal form (3NF) if it is in second normal form and no transitive dependencies exist. A Transitive Dependency in a relation is a functional dependency between the primary key and one or more nonkey attributes that are dependent on the primary key via another non-key attribute. Transitive dependencies create unnecessary redundancy that may lead to the database anomalies. Removing Transitive Dependencies Three-step procedure to remove transitive dependencies from a relation: 1. For each non-key attribute (or set of attributes) that is a determinant in a relation, create a new relation. That attribute (or set of attributes) becomes the primary key of the new relation. 2. Move all of the attributes that are functionally dependent on the primary key of the new relation from the old to the new relation. 3. Leave the attribute that serves as a primary key in the new relation in the old relation to serve as a foreign key that allows you to associate the two relations. 6. Merging Relations We transform EER diagrams into relations when we take the results of a top-down analysis of data requirements and begin to structure them for implementation in a database. We apply the normalization rules (third or higher normal form) on the relations to get a database having the well-structured relations. As part of the logical design process, normalized relations may have been created from a number of separate EER diagrams and (possibly) other user views (i.e., there may be bottom-up or parallel database development activities for different areas of the organization as well as top-down ones). The three-schema architecture for databases encourages the simultaneous use of both top-down and bottom-up database development processes. In reality, most medium to large organizations have many reasonably independent systems development activities that at some point need to come together to create a shared database. The result is that some of the relations generated from these various processes may be redundant; that is, they may refer to the same entities. In such cases, we should merge those relations to remove the redundancy. This section describes merging relations (also called view integration). Reasons of merging the relations: 1) Sometime more than one teams (sub-teams) work on a single large project; when the output of their Logical Database Design comes together, there is often a need to the merge relations.
13 2) Integrating existing databases with new information requirements often leads to the need to integrate different relations or views. 3) New data requirements may arise during the life cycle, so there is a need to merge any new relations with what has already been developed. View Integration Problems While merging or integrating relations a database analyst must understand the meaning of the data and must be prepared to resolve any problems that may arise in that process. Some of the problems that arise in view integration are: A) Synonyms, B) Homonyms C) Transitive Dependencies D) Supertype/ Subtype Relationships Synonyms In some situations, two (or more) attributes may have different names but the same meaning (e.g., when they describe the same characteristic of an entity). Such attributes are called synonyms. For example, Employee_ID and Employee_No may be synonyms. When merging the relations that contain synonyms, you should obtain agreement (if possible) from users on a single, standardized name for the attribute and eliminate any other synonyms. Another alternative is to choose a third name to replace the synonyms. When there are synonyms, there is a need to allow some database users to refer to the same data by different names. Users may need to use familiar names that are consistent with terminology in their part of the organization. An Alias is an alternative name used for an attribute. Many DBMS allow the definition of an alias that may be used interchangeably with the primary attribute label. Homonyms An attribute name that may have more than one meaning is called a homonym. For example, the term account might refer to a bank s checking account, savings account, loan account, or other type of account (and therefore account refers to different data, depending on how it is used). Transitive Dependencies When two 3NF relations are merged to form a single relation, transitive dependencies may result. The analyst should create 3NF relations by removing the transitive dependency. Supertype/Subtype Relationships These relationships may be hidden in relations or the user views. The database analyst should recognize and preserve the Super type / Sub type relationship while merging the relations. Enterprise Key A primary key that is unique across the whole database not just within the relation or table to which it applies, is called an Enterprise Key. This criterion makes a primary key more like what in object oriented databases is called an object identifier. With this recommendation, the primary key of a relation becomes a value internal to the database system and has no business meaning. One of the main motivations for using an enterprise key is database evolve-ability, in which the existing relations are merged with the new relations after the database is created.
Chapter 5: Logical Database Design and the Relational Model Part 1: into Relations Modern Database Management 6 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden Robert C. Nickerson ISYS
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
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
Data Model ing Essentials Third Edition Graeme C. Simsion and Graham C. Witt MORGAN KAUFMANN PUBLISHERS AN IMPRINT OF ELSEVIER AMSTERDAM BOSTON LONDON NEW YORK OXFORD PARIS SAN DIEGO SAN FRANCISCO SINGAPORE
Title: ENHANCEMENT OF ERD Research by: Student Name : Wafa Ali Edrees Student Id : 201130061 Collage Of Computer Science and Information System Level : 5 Teacher : Arshia Arjumand Banu 1 ENHANCEMENT OF
GROUP 2 PRACTICE EXAMPLES FOR THE REVIEW QUIZ: Review Quiz will contain very similar question as below. Some questions may even be repeated. The order of the questions are random and are not in order of
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
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
Constraints in ER Models CS 317, Fall 2007 Types of Constraints Keys are attributes or sets of attributes that uniquely identify an entity within its entity set. Single-value constraints require that a
: 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
Entity-Relationship Model Database Modeling (Part 1) A conceptual data model, which is a representation of the structure of a database that is independent of the software that will be used to implement
Concepts of Database Management, Fifth Edition Chapter 6: Database Design 2: Design Methodology Objectives Discuss the general process and goals of database design Define user views and explain their function
DATABASE MANAGEMENT SYSTEMS Question Bank: UNIT 1 1. Define Database? 2. What is a DBMS? 3. What is the need for database systems? 4. Define tupule? 5. What are the responsibilities of DBA? 6. Define schema?
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)
Data Modeling Windows Enterprise Support Database Services provides the following documentation about relational database design, the relational database model, and relational database software. Introduction
How do we design the database for an application? Entity-Relationship Model Dr. McNamara CSCI 371 Databases Fall 2006 1. Conceptual Design: Analyze the problem. Identify the entities, relationships, and
Tore Risch Uppsala University, Sweden UDBL Basic Database Concepts What is a database? A database is a collection of related data stored in a computer managed by a DBMS. What is a DBMS, Database Management
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
DATABASE SYSTEMS DESIGN IMPLEMENTATION AND MANAGEMENT INTERNATIONAL EDITION ROB CORONEL CROCKETT Chapter 7 Normalisation 1 (Rob, Coronel & Crockett 978184480731) In this chapter, you will learn: What normalization
ETEC 2601 Database Systems Chapter 5: Data Modeling With The Entity-Relationship Model Copyright 2004-2010 J. B. Gallaher The Data Model The design of a database Is the way the user conceives the information
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
Component 4: Introduction to Information and Computer Science Unit 6: Databases and SQL Lecture 2 This material was developed by Oregon Health & Science University, funded by the Department of Health and
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
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
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
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/
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
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:
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
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,
Logical Database Design (Part 2) CS 122: Database Systems Second Semester, 2012-2013 Transforming Associative Entities If an identifier is not assigned, the default primary key for the association relation
HNDIT 1105 Database Management Systems Lesson 02: Database Design Process & ER Diagrams By S. Sabraz Nawaz M.Sc. In IS (SLIIT), PGD in IS (SLIIT), BBA (Hons.) Spl. in IS (SEUSL), MIEEE, MAIS Senior Lecturer
Database Design and the Entity-Relationship Model Computer Science 460/660 Boston University Fall 2013 David G. Sullivan, Ph.D. Database Design In database design, we determine: which data fields to include
DATABASE NORMALIZATION Normalization: process of efficiently organizing data in the DB. RELATIONS (attributes grouped together) Accurate representation of data, relationships and constraints. Goal: - Eliminate
Chapter 7. Database Planning, Design and Administration Last few decades have seen proliferation of software applications, many requiring constant maintenance involving: correcting faults, implementing
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
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
in Database Design Marek Rychly firstname.lastname@example.org Strathmore University, @ilabafrica & Brno University of Technology, Faculty of Information Technology Advanced Databases and Enterprise Systems 14
ISM 318: Database Systems Dr. Hamid R. Nemati Department of Information Systems Operations Management Bryan School of Business Economics Objectives Underst the basics of data databases Underst characteristics
Microsoft Office Access Database design basics Applies to: Microsoft Office Access 2007 A properly designed database provides you with access to up-to-date, accurate information. Because a correct design
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
Chapter 10 Practical Database Design Methodology and Use of UML Diagrams Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 10 Outline The Role of Information Systems in
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?
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
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
Lecture 12: Entity Relationship Modelling The Entity-Relationship Model Entities Relationships Attributes Constraining the instances Cardinalities Identifiers Generalization 2004-5 Steve Easterbrook. This
http://en.wikipedia.org/wiki/database_normalization Database normalization is the process of organizing the fields and tables of a relational database to minimize redundancy. Normalization usually involves
UNIT-1 Ques 1. Define dbms and file management system? Ans- Database management system (DBMS) is a collection of interrelated data and a set of programs to access those data. Some of the very well known
INRODUCION C HAPER 4 Relational Databases Questions to be addressed in this chapter: How are s different than file-based legacy systems? Why are s important and what is their advantage? What is the difference
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
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
Chapter 6 Database Tables & Normalization Objectives: to learn What normalization is and what role it plays in the database design process About the normal forms 1NF, 2NF, 3NF, BCNF, and 4NF How normal
Introduction to Computing Lectured by: Dr. Pham Tran Vu email@example.com Databases The Hierarchy of Data Keys and Attributes The Traditional Approach To Data Management Database A collection of
Jagannath Institute of Management Sciences Lajpat Nagar BCA Sem III DBMS BCA III RD SEMESTER DBMS NOTES UNIT WISE UNIT 1 Objectives At the end of this chapter the reader will be able to: Distinguish between
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
Tutorial on Relational Database Design Introduction Relational database was proposed by Edgar Codd (of IBM Research) around 1969. It has since become the dominant database model for commercial applications
Conceptual Design: Entity Relationship Models Craig Van Slyke, University of Central Florida firstname.lastname@example.org John Day, Ohio University Objectives Define terms related to entity relationship modeling,
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
Module 5: Normalization of database tables Normalization is a process for evaluating and correcting table structures to minimize data redundancies, thereby reducing the likelihood of data anomalies. The
Course Notes on From Entity-Relationship Schemas to Relational Schemas The chapter deals with practical database design: the construction of a relational schema from an E-R schema this stage of database
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,
database systems formal definitions of the relational data model  s. yurttaοs 1 1 the relational data model The relational model of data was introduced by E.F. Codd (1970). 1.1 relational model concepts
Functional Dependency and Normalization for Relational Databases Introduction: Relational database design ultimately produces a set of relations. The implicit goals of the design activity are: information
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,
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
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:
Topic 5.1: Database Tables and Normalization What is Normalization? Normalization is a process for evaluating and correcting table structures to minimize data redundancies, thereby helping to eliminate
ETEC 430 Database Systems Chapter 2: Entity-Relationship Data Modeling: Tools and Techniques Copyright 2004 J. B. Gallaher ANSI/SPARC Three Schema Model External Schema User view = how the users view the
Database design 1 The Database Design Process: Before you build the tables and other objects that will make up your system, it is important to take time to design it. A good design is the keystone to creating
Chapter 10 Functional Dependencies and Normalization for Relational Databases Copyright 2004 Pearson Education, Inc. Chapter Outline 1 Informal Design Guidelines for Relational Databases 1.1Semantics of
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
Introduction It should be a requirement of the job that business analysts document process AND data requirements Process create, read, update and delete data they manipulate data. Process that aren t manipulating
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
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
Applied Databases Handout 2. Database Design. 5 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. CREATE TABLE Hikers
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
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
TIM 50 - Business Information Systems Lecture 15 UC Santa Cruz March 1, 2015 The Database Approach to Data Management Database: Collection of related files containing records on people, places, or things.
Process Databases - Entity-Relationship Modelling Ramakrishnan & Gehrke identify six main steps in designing a database Requirements Analysis Conceptual Design Logical Design Schema Refinement Physical
Normalization CIS 3730 Designing and Managing Data J.G. Zheng Fall 2010 1 Overview What is normalization? What are the normal forms? How to normalize relations? 2 Two Basic Ways To Design Tables Bottom-up:
IV. The (Extended) Entity-Relationship Model The Extended Entity-Relationship (EER) Model Entities, Relationships and Attributes Cardinalities, Identifiers and Generalization Documentation of EER Diagrams
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
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
Files What s it all about? Information being stored about anything important to the business/individual keeping the files. The simple concepts used in the operation of manual files are often a good guide
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