} a Introduction to Database Systems || 81 Table 2: Employee Department Table (Not Normalized) emp_id emp_name emp_address emp_dept Jol aes Delhi DOOL 101 Rick Delhi D002 123 Maggie ‘Agra D890 166 Glenn Chennai D900 166 Glenn Chennai D004 The above table is not normalized. We will see the problems that we face when a table is not normalized. Update anomaly: In the above table we have two rows for employee Rick as he belongs to two departments of the company. If we want to update the address of Rick then we have to update the same in two rows or the data will become inconsistent. If somehow, the correct address gets updated in one department but not in other then as per the database, Rick would be having two different addresses, which is not correct and would lead to inconsistent data. Insert anomaly: Suppose a new employee joins the company, who is under training and currently not assigned to any department then we would not be able to insert the data into the table if emp_dept field doesnt allow nulls. | Delete anomaly: Suppose, if at a point of time the company closes the department D890 then deleting the rows that are having emp_dept as D890 would also delete the information of employee | Maggie since she is assigned only to this department. I To overcome these anomalies we need to normalize the data, In the next section we will discuss about normalization. 3.8.2. Functional Dependency It is a relationship that exists when one attribute uniquely determines another attribute. A Functional dependency is a relationship between attributes. Suppose that given the value of one attribute, we can obtain the value of another attribute. For example, if we know the value of customer account number, we | can obtain customer address, balance etc. So customer address and balance is functionally dependent on | customer account number. In general terms, attribute Y(customer address and balance) is functionally dependent on the attribute X(customer account number), ifthe value of X determines the value of Y. | Functional dependency is represented by an arrow sign (>) that is, X>, where X functionally determines Y. The left-hand side attributes determine the values of attributes on the right-hand side. Attributes on the left side are called Determinants. ‘Types of Functional Dependencies: « Single Valued Functional Dependency: 6 single value functional dependency is when A is the primary key of an entity (eg. SID) and B is some single valued attribute of the entity (eg. Sname). Then, A > B must always hold,82 || Information System Management _ + Fully Functional Dependency(FFD): A functional dependency P > Q is full function,y dependency if removal of any attribute A from P means that the dependency does not holy any more or If AD C,is fully functional dependency, then we cannot remove A or D. ie. Cj, fully functional dependent on AD. Ifwe are able to remove A or D, then it is not full function, dependency For example: {SSN, PNUMBER} > HOURS is a FFD. Hours id depend on both SSN ang PNUMBER, neither one can be removed. + Partial Function Dependency - It is a form of Functional dependency that holds on a set of attributes. Let us assume a relation R with attributes A, B, C, and D. Also, assume that the set of functional dependencies F that hold on R as follows; F={A>B,D>C). From set of attributes F, we can derive the primary key. For R, the key can be (A,D), a composite primary Key. That means, AD > BC, AD can uniquely identify B and C. But, for this case A and Dis not required to identify B or C uniquely. To identify B, attribute A is enough. Likewise, to identify C, attribute D is enough. The functional dependencies AD > B or AD > Care called as, Partial functional dependencies. Trivial Dependency - The dependency of an attribute on a set of attributes is known as Trivial Dependency if the set of attributes includes that attribute. Consider a table with two columns Student_id and Student_Name. {Student_Id, Student_Name} >Student_id is a trivial functional dependency as Student_Id is a subset of {Student_Id, Student_Name}. That makes sense because if we know the values of Student_Id and Student_Name then the value of Student_Id can be uniquely determined, Also, Student_Id > Student_Id & Student_Name > Student_Name are trivial dependencies too. Non-Trivial Dependency - If a functional dependency X>Y holds true where Y is not a subset of X then this dependency is called Non-Trivial Dependency. An employee table with three attributes: emp_id, emp_name, emp_address. ‘The following functional dependencies are non-trivial: emp_id > emp_name (emp_name is not a subset of emp_id) ‘emp_id > emp_address (emp_address is not a subset of emp_id) On the other hand, the following dependencies are trivial: {emp_id, emp_name} >emp_name [emp_name is a subset of femp_id, emp_name}] 3.8.3 Normalization Thisis the process which allowsyou to eliminate redundant data from database. This involves restructeting the tables to fulfil the requirements of Normalization forms. A properly normalized database should have the following characteristics: «+ Scalar values in each fields + Absence of redundancy + Minimal use of null values + Minimal loss of informationIntroduction to Database Systems || 83 Here are the most commonly used normal forms: + First normal form (INF) + Second normal form (2NF) « Third normal form (3NE) First normal form (1NF) As per the rule of first normal form, an attribute (column) of a table cannot hold multiple values. It should hold only atomic values or scalar values. Example: Suppose the following Author_Book_Details table in which AuName and AuPhone Columns are in non-atomic values form, ‘the following Author_Book_Details table is not in INF. Table 3: Author_Book_Details Table (Non Atomic Value) Title AuName | _AuPhone PubName PubPhone | Price Rohit, | 321321111, 0-321-32132-1 ISM Suman, | 3232341234, | SmallHouse | 7140000000 | 340.00 Shyam | 6652356532 Jones, | 1233333333, Smith _| 6542233455 0.123-45678-0 | E-Commerce | Joyce | 6666666666 | AlphaHouse | 9999999999 | 340.00 722-233700-0 | Visual Basic | Roman | 4444444444 | BigHouse_|_1234567890_| 250.00 (0-55-123456-9 | Management Small House | 7140000000 } 220.95 Zero Normal Form Convert non-atomic value table to atomic value table. Table 4: Author_Book_Details Table (Atomic Value) ee Title AuName | AuPhone PubName PubPhone | Price 0-321-32132-1 ISM Rohit | 321321111 | Small House | 7140000000 | 340.00 0-321-32132-1 ISM ‘Suman | 3232341234 | Small House | 7140000000 | 349.00 0-321-32132-1 ISM Shyam | 6652356532 | Small House | 7140000000 | 340.00 0-55-123456-9 | Management | Jones | 1233333333 | Small House | 7140000000 | 220.95 0-55-123456-9 | Management | Smith | 6542233455 | Small House | 7140000000 _| 220.95 0-123-45678-0 | E-Commerce | Joyce | 6666666666 | AlphaHouse | 9999999999 | 340.00 1-22-233700-0 | Visual Basic | Roman | 4444444444 | BigHouse | 1234567890 | 250.00 INF ~ Conversion and Decomposition 1. Place all fields that appear in the repeating group in a new table(s). 2. Designate a primary key for each new table(s) produced, having atomic values. 3, Duplicate in the new table(s) the primary Key ofthe table from which the repeating field was extracted or vice versa.84 || Information System Management The above Author_Book Details Table 4 further decomposed into two atomic value tables, ag following: Table 5: Book Publisher_Details Table ISBN Title PubName PubPhone Price 1-32132-1 ISM ‘Small House 7140000000 340.00 0-55-123456-9 Management ‘Small House: 7140000000 220.95, 0-123-45678-0 E-Commerce Alpha House 9999999999 340.00 1-22-233700-0 Visual Basic Big House 1234567890 250.00 Table 6: ISBN_Author_Details Table ISBN ‘AuName ‘AuPhone 0-321-32132-1 Rohit 321321111 0-321-32132-1 Suman 3232341234 0-321-32132-1 Shyam 6652356532 0-55-123456-9 Jones 1233333333 0-55-123456-9 Smith 6542233455 | 0-123-45678-0 Toyce 6666666666 1-22-233700-0 Roman 4444444444 i Functional Dependencies in INF 7 If one set of attributes in a table determines another set of attributes in the table, then the second set of attributes is said to be functionally dependent on the fist set of attributes or key attribute. FD 1: In Book Price_Details Table below : {ISBN, Title, Price} Functional Dependencies: {ISBN} > {Title} - FD | {ISBN} > {Price} - FD | Title and Price fields are dependent on ISBN(Key attribute) shown below: Table 7: Book _Price_Details Table ISBN Title Price | 0-321-32132-1 ISM 340.00 0-55-123456-9 ‘Management 220.95, 0-123-45678-0 E-Commerce 340.00 1-22-233700-0 Visual Basic 250.00 FD2: In Publisher_Detail Table below: _{PubLD, PubName, PubPhone} Functional Dependencies: {PubID} > {PubPhone} ~ FD {PubID} > {PubName} ~ FD {PubName, PubPhone} > {PubID} ~ FFD | i ea ee iIntroduction to Database Systems || 85 PubName and PubPhone fieldsare dependent on PubID (Key attribute) thisis functional dependency, now in third functional dependency above the composite value of PubName and PubPhone (composite key) constitute PubID, if we remove any one of the field from composite key then value of PubID will not determined as shown below. That's why third functional dependency is known as fully functional dependency. Table 8: Publisher_Details Table PubID PubName PubPhone POOL Small House 7140000000 Po02 Alpha House 9999999999 O03 Big House 1234567890 FD3: In Author_Details Table below: {AulD, AuName, AuPhone} Functional Dependencies: {AulD} > {AuName} - FD {AulD} > {AuPhone} - FD {AuName, AuPhone} > {AulD} - FFD ‘AuName and AuPhone fields are dependent on AulD(Key attribute) this is functional dependency, i now in third functional dependency above the composite value of AuName and AuPhone (composite key) constitute AuID, if we remove any one of the field from composite key then value of AulD will not determined as shown below. That's why third functional dependency is known as fully functional dependency. Table 9: Author_Details Table AuD ‘AuName ‘AuPhone ‘A0OL Rohit 321321111 ‘A002 Suman 3232341234 ‘A003 Shyam 6652356532 ‘A004 Jones 1233333333, | ‘A005 Smith 6542233455 } ‘A006 Joyce 6666666666 | ‘A007 Roman aaa Note : Above three tables - Book_Price_Details, Publisher_Details and Author_Details are in atomic values table and all have key attribute ISBN, PubID and AuID respectively (in INF). That’ why we move towards to 2NF. Second normal form (2NF) Fora table to be in 2NF, there are two requirements 1. ‘The database is in first normal form 2. All non-key attributes inthe table must be functionally dependent on the entire primary key Note: Remember that we are dealing with non-key attributes.86 || Information System Management | Example: Suppose if we create a new table Publication_Details shown below, having fields jn, the table as ISBN, PubID, AUuID, Price, AuPhone is not in 2NF. Table 10; Publication_Details Table ‘Au Price AuPhone 0-321-3213241 A001 340.00 321321111 0-321-32132-1 P001 A002 340.00 3232341234 0-321-32132-1 POOL A003 340.00 6652356532 0-55-123456-9 POOL A004 220.95 1233333333 0-55-123456-9 POOL A005 220.95 6542233455, 0-123-45678-0 P002 A006 340.00 6666666666 1-22-233700-0 P003 A007 250.00 4444444444 Decompose the Publication_Details table > {ISBN, PubID, AulD, Price, AuPhone} into followin small ables, having Key attributes > (ISBN, PubID, AuID}, combined value of key attributes (Composi Key) on which Price field value depend (fully functional dependency), but AuPhone is only depend AuID, which i single field (subset) of composite key known as partial functional dependency, {ISBN, Publd, AulD} > {Price} ~ FFD {AuID} > {AuPhone} - FD Note: After removing partial functional dependency from Publication_Details table because AuPho riot depend on all felds of composite key attributes. AuPhone functionally depends only on Auld, which a subset of a composite key. The decomposed tables are in 2NF. 2NF - Conversion and Decomposition 1, Ifa data item is fully functionally dependent on only a part of the primary key, move that da item and that part of the primary key to a new table, 2. If other data items are functionally dependent on the same part of the key, new table also. : place them in ¢! 3. Make the partial primary key copied from the original t able the primary key for the new tabi Place all items that appear in the repeating group in a n ew table, Now decompose Publication Details Table > {ISBN, PubID, AuID, Price, AuPhone) into t small tables as follows: {ISBN, PubID, AulD, Price} as Publication table and {AuID, AuPhone} as Author table,Introduction to Database Systems || 87 Table 11: Publication Table ISBN’ PublD AulD Price 0-321-32132-1 POOL A001 340.00 0-321-32132-1 POOL A002 340.00 0-321-32132-1 POOL ‘A003 340.00 0-55-123456-9 POOL A004 220.95 0-55-123456-9 POOL ‘A005 220.95 0-123-45678-0 Po02 ‘A006 340.00 1-22-233700-0 O03 ‘A007 250.00 Table 12: Author Table AulD AuPhone A001 321321111 A002 3232341234 A003 (6652356532 A004 1233333333 A005 6542233455 A006 6666666666 A007 444adaadad Now both tables above are in 2NF after removing partial functional dependency. Third Normal form (3NF) ‘This form dictates that all non-key attributes of a table must be functionally dependent on a candidate key i, there can be no interdependencies among non-key attributes. For a table to be in 3NF, there are two requirements: « The table should be second normal form «No non-prime attribute is transitively dependent on the primary key or super key should be removed, (An attribute that is not part of any candidate key is known as non-prime attribute.) Example: Suppose if we create anew table Book_Details shown below, having fields inthe table as ISBN, PubID, PageCount, Price is not in 3NE, Table 13: Book Details Table ISBN |__PubtD | _PogeCount Price 0-321-32132-1 Pool 235 340.00 0-55-123456-9 Pool 198 220.95 0-123-45678-0 O02 250 340.00 1.-22-233700-0 003 210 250.00a 88 || Information System Management a4 Decompose the Book Details table > {ISBN, PubID, PageCount, Price} into following small tables, having Key attributes > {ISBN, PubID}, combined value of key attributes (Composite Key) on which Pagecount feld value depend (Fully functional dependency), but Price is only depend on PageCount, which is transitive functional dependency. Book Details Table is in 2NF, not in 3NF {ISBN, Publd} > {PageCount} - FFD {PageCount} > {Price} - TFD Note: Both Price and PageCount depend on a composite key hence 2NF and Transitively (Title, PublD} > {Price} hence not in 3NE. Remove transitive functional dependency from Book_Details Table. 3NF - Conversion and Decomposition 1. Move all items involved in transitive dependencies to a new entity 2. Identify a primary key for the new entity. 3. Place the primary key for the new entity as a foreign key on the original entity. Now decompose Book_Details Table > {ISBN, PubID, PageCount, Price} into two small tables as follows: {ISBN, PubID, PageCount} as Book_PageCount table and {PubID, PageCount, Price} as Book_ Price table. Table 14: Book PageCount table ISBN PubID PageCount 0-321-32132-1 Pool 235 0-55-123456-9 POOL 198 0-123-45678-0 002, 250 1-22-233700-0 O03 210 Table 15: Book Price table PubID PageCount Price Pool 235 340.00 POOL 198 220.95 POO2 250 340.00 003 210 250,00, 3.9 Decomposition Decomposition is the process of breaking down in parts or elements. It replaces a relation with a collection of smaller relations. It breaks the table into multiple tables in a database. It should always be lossless, because it confirms that the information in the original relation can be accurately reconstructed based on the decomposed relations. If there is no proper decomposition of the relation, then it may lead to problems like loss of information, Following are types of decomposiIntroduction to Database Systems || 89 3.9.1. Lossless Decomposition Decomposition must be lossless. It means that the information should not get lost from the relation that is decomposed. It gives a guarantee that the join will result in the same relation as it was decomposed. For Example - Let’ take’ is the Relational Schema, With instance ‘¢; is decomposed into: E1, E2, E3, ... Ens With instance: el, e2, ¢3, en, If el 04 2 04 3... 04 en, then it is called as ‘Lossless Join Decomposition. In the above example, it means that, if natural joins of all the decomposition give the original relation, then it is said to be lossless join decomposition. Table 16: Employee Department Table Eid Ename Age City Salary Deptid DeptName E001 ABC 29 Pune 20000 Doo Finance E002 PQR 30 Pune 30000 D002 Production E003 LMN 25 Mumbai | 5000 D003 Sales 004 XYZ 4 Mumbai | 4000 Dood Marketing E005 sTU 2 Bangalore | 25000 00s Homan Resource Decompose the above relation into two relations to check whether a decomposition is lossless or lossy. Now, we have decomposed the relation that is Employee and Department, Relation 1: Employee Table Table 17: Employee table Eid Ename Age City, Salary E001 ABC 29 Pune 20000 E002 PQR 30 Pune 30000 E003 LMN, 25 Mumbai 5000 004 XYZ 4 Mumbai 4000 E005 sTU 32 Bangalore 25000 Employee Schema contains (Eid, Ename, Age, ity, Salary). Relation 2: Department Table Table 18: Department Table Deptid Eid DeptName Doo1 E001 Finance D002 £002 Production D003 E003 Sales D004 E004 Marketing DO0S E005 Human Resource90 || Information System Management eptid, Eid, DeptName) So the above decomposition isa, Tations contain one common field that is ‘Eid’ and thereon i, yosed relations. Department Schema contains (Di Join Decomposition, because the two re is possible. Now apply natural join on the decomp Table 19: Employee » Department Eid Ename ‘Age City Salary Deptid DepiName E001 ‘ABC 29 Pune 20000 DOOL Finance E002 PQR 30 Pune 30000 D002 Production E003 LMN 25 ‘Mumbai | 5000 D003 Sales E004 XYZ 24 ‘Mumbai 4000 D004 Marketing | £005 sTU 32 Bangalore | 25000 D005, Haman Resource _| Hence, the decomposition is Lossless Join Decomposition. If the table contains (Eid, Ename, Age, City, Salary) and table contain (Deptid and DeptName), then itis not possible to join the two tables or relations, because there is 0 | common column between them. And it becomes Lossy Join Decomposition. | 3.9.2 Dependency Preservation Dependency is an important constraint on the database. Every dependency must be satisfied by at least one decomposed table. If A > B} holds, then two sets are functional dependent. And, it becomes more tiseful for checking the dependency easily if both sets in a same relation. This decomposition property can only be done by maintaining the functional dependency. In this property, it allows to check the updates without computing the natural join ofthe database structure, 3.9.3 Lack of Data Redundancy Lack of Data Redundancy is also known as a Repetition of Information, ‘The proper deco . tion jhould not suffer from any data redundancy. The careless decomposition may Sane prablea eich the soon the lack of data redundancy property may be achieved by Normalization process,4 Introduction to Entity Relationship Model Learning Outcomes Alter studying this chapter, you shoul beable to understand: Overview of Database Design Entity Relationship Model Enhanced Features Degree Cardinality How to Draw ER Diagram ‘Weak And Strong Entity in ER Diagram, ‘Transform ER Diagram Into Tables Some Examples of ER-Models Viv ey ON Vivi 4.0 Introduction ‘The Entity Relationship ( ER diagram is used to (ER) Diagram is used at t] Tepresent this conceptual desi ceptual design. The ER diagra and the requirement. ‘The dat main experts to ensure that all the «Process i repeated until the end users and designers agree that the E-R diagram m.of the requirement. We can eas he conceptual design stage of the database design. ‘Ip graphical form. The requirement analysis a maga), 2PFessve and easy to understand, ae ine adel Breparesthe ER diagram and is vercs © Fequitements are properly incorporated in the conceptual design. ‘Th {sa fair representatio ly convert an ER diagram toa relational schema,pees Introduction to Entity Relationship Model || 93 4.) Overview of Database Design Database design is connected with application design. The phases of database design below gives you step-by-step flow to design a database. The requirements and the collection analysis phase produce both data requirements and functional requirements. The data requirements are used as a source of database design. The data requirements should be specified in as detailed and complete form as possible. In parallel with specifying the data requirements, it is useful to specify the known functional requirements of the application. These consist of user-defined operations that will be applied to the database (retrievals and updates). The functional requirements are used as. source of application software design. Ofcourse some functions may produce also needs for database design. Note that some phases are database management system independent and some are dependent. The idea is to design first the database without thinking about the actual database system - just to concentrate on the data, REQUIREMENTS COLLECTION AND ‘ANALYSIS. Functional Requirements, Data Requirements, FUNCTIONAL ANALYSIS. (CONCEPTUAL DESIGN Vv High-Level Transaction Specification Conceptual Schema (na high-level data mode!) LOGICAL DESIGN eae dependent _ ~"7|_(OATA MODEL MAPPING) a | DBMS-specific Logical (Conceptual) Schema (in the data model of. If specific DBMS) ‘APPLICATION PROGRAM DESIGN J PHYSICAL DESIGN TRANSACTION _—__ IMPLEMENTATION Internal Schema v Application Programs Figure 4.1 : Phases in Database Design 4.1.1 Database Design Phases Phase 1: Requirement Collection and Analysis ~ purpose is to document the data requirements of the users and functional requirements are the operations that will be applied to the database, including queries and update, The specification will then be used as the basis for the design of the database.fF ) 94 || Information System Management Activities performed in this phase are identification of application areas and peer groves avai “ existing documentation of application areas, e.g. policy documents, forms, reports, i ° chars analysis of current operating environments and the planned use ofthe information, eg, info matin fog, types of transactions, frequency of transaction types and responses to user questionnaires es analysed Phase 2: Conceptual Design ~ has two parallel activities, schema design which et the day requirements of the database resulting from the analysis (phase 1) and produces a aan Schem, in a DBMS-independent high level data model and transaction design which examines t € databacy applications whose requirements were analysed in phase 1 and produces high level specifications fo, these transactions. In Conceptual Schema Design, purpose is to produce a conceptual schema of the database Which expressed by using concepts of the high level data model, not including implementational details (has to be understood by non-technical users) but detailed in terms of the “objects” of the domain in which the database will represent. Another purposes are to create independent of the DBMS to be used (no relational DB), cannot be used directly to implement the database, design is made in terms of a semantic or conceptual data model, the goal is to achieve understanding of database structure, semantics, interrelationships and constraints and most popular data model used is the Entity-Relationship (ER) model. Conceptual design phase need to be expressed in a “language” which offers: + Expressiveness: able to distinguish between different types of data, relationships and constraints, + Simplicity: easy for non-specialist users to understand and use concepts. * Minimality: small number of basic concepts that are distinct and do not overlap. + Diagrammatic representation: for ease of presentation; it should therefore be easy to interpret. + Formality: must represent a formal, unambiguous specification of the data, In Transaction Design, purpose is to produce a design of the transactions, which will run on the database for: 1, Retrieval: retrieve data for display or as part of a report. 2. Update: enter new data or amend existing data. 3. Mixed: more complex applications may do both retrieval and update. t Another purposes of transaction design is the need to be sure to include in the conceptual schema t information required by transactions and relative importance and frequency of use of transactions will influence physical database design. And most important software and data need to be designed. Phase 3: Choosing a DBMS - purpose is to establish which is the best framework for implementing the produced schema such as type of DBMS (relational, network), user and programmer interfaces (CUI or GUI) and types of query languages. Another purpose are to choice made on the basis of technical factors such as the DBMS which has to support the required tasks, economic factors such as software acquisition/maintenance, hardware acquisition, creation/conversion, training of staff and of organisational factors such as platforms supported, availability of vendor services, Phase 4: Logical Design ~ purpose is to transform the generic, DBMS independent conceptual schema in the data model of the chosen DBMS (data model mapping), two stages in this phase first one is system independent mapping where no consideration of any specific characteristics that may apply to| % Introduction to Entity Relationship Model || 95 dhe specific DBMS package and second one tailoring to DBMS where different DBMSs may implement * the same data model in slightly different ways and result is a set of DDL statements in the language of Ning \ the chosen DBMS. Sy ' \ phase 5: Physical Design - purpose is to choose the specific storage structures and access paths for ‘ th \ the database files based on some relevant criteria: Gi ime: ae Ny + Response time: may want to minimise database access time for data items referenced by a \ frequently used transactions, ont + Space utilisation: less frequently used data and queries may be archived. don ae, + Transaction throughput: average number of transactions that can be processed per minute. IS, ny Phase 6: Implementation - purpose is to create the database, compile and execute DDL statements, ‘TMs bey populate the database using manually/automatically (may need to convert data from a previous format), ety, IN implement application programs (transactions) using programs are written with embedded DML Ret Te, ge, statements and operational phase or application program may begin. atin, “Yaya Detcbase Design Process hips Conceptual Design: Once all the requirements have been collected and analyzed, the next step is to ANd cong create a conceptual schema for the database, using a high level conceptual data model. This phase is called conceptual design. The result of this phase is an Entity-Relationship (ER) diagram. It describes how different entities (objects, items) are related to each other. It also describes what attributes (features) rebe easy to; each entity has. It includes the definitions of all the concepts (entities, attributes) of the application area. ‘inte, During or after the conceptual schema design, the basic data model operations can be used to specify the high-level user operations identified during the functional analysis. This also serves to confirm that the A at conceptual schema meets all the undefined functional requirements. Logical Design: ‘The result of the logical design phase (or data model mapping phase) is a set of relation schemas. The ER diagram is the basis for these relation schemas. To create the relation schemas is quite a mechanical operation. There are rules how the ER model is transferred to relation schemas. The relation schemas are the basis for table definitions. In this phase (if not done in previous phase) the h | primary keys and foreign keys are defined. ; re conceptual sehen Normalization: Normalization is the last part of the logical design. The goal of normalization is to Use of transactiony, eliminate redundancy and potential update anomalies. Redundancy means that the same data is saved ed to be designed, more than once in a database. Update anomaly is a consequence of redundancy. If a piece of data is Mework for implementa saved in more than one place, the same data must be updated in more than one place. Normalization is a ad Programmer interie technique by which one Con. ay the rea to reduce the redundancy. Each normalization dice made on the bass: phase adds more relations (tables) into the database. S, economic factors sude Physical Design: The goal of the last phase of database design, physical design, is to implement On, training of staff ali the database. At this phase one must know which database management system (DBMS) is used. For vices, example, different DBMS have different names for data types and have different data types. The SQL MS ind clauses to create the database are written. The indexes, the integrity constraints (rules) and the users’ » independent concep! access rights are defined. Finally the data to test the database is added in. In parallel with these activities, » stages in this phase first! pes application programs are designed. The implementation of the programs can start when the database is Acteristics that may appi"| created and data has been added in.Phase 2: Conceptual Design - has two p requirements ofthe database resulting from the analysis (phase ina DBMS-independent high level data model and transaction design which examin cations whose requirements were analysed in phase 1 and produces high level specifica ships and cons Conceptual design phase need to be expressed in a“languas «+ Expressiveness:ableto distinguish between different types tionships and constrains, users to understand and use concepts. + and do not overlap. ould therefore be easy to interpret ion ofthe data, dealt Tamston Desig, purposes to produce a design ofthe wansactns, which wil un on the 1, Retrieval: retrieve data for display or as part of report 2 Update: enter new data or amend ware and data need to be designed, Phase 3: Choosing a DBMS ~ purp which i the bes framework for impl the produced schema such as type of DBMS (relat the pot type of DBMS (relational, networ 7 user and programmer interfaces ind types of query languages. Another purpose are to choice made onthe basis of port the required task, economic factors such as reation/conversion, training of staff and of. lity of vendor services ators cha pts spore, rl al Design ~ purpose iso tansfm the vanform the generic, DBMS independent conc ca inthe dts del of he chosen DEMS (data od mapping wo Sages i spe faker sem independent mapping whee no consideration of an pci caer the may pts _ ship Model \| 95 a ——— e Pe" cond am )BMSs may implems sim the language of amine 5 PA Deg pur and acess p pe dbs ie aed on ome releva ', Response time: may want to minimise ly used transactions, vont wsed data and queries may be archived transactions that can be processed per minute. pile and execute DDL statements, database access time for data items referenced by se 6implementaon~ pio pul 3p ‘a and operational phase oF aP {12 Datoose Design Process + gaat Design: Once all the fequirements have been collected and analyzed the next step isto roma for the database, using a high level conceptual data model. This phase is “The result of this phase is an Entty-Relationship (ER) diagram. It describes ects, items) are related to each other. It also describes what attributes (features) tudes the definitions of all the concepts (entities, attributes) of the application area. ras he conceptual schema design the basic data model operations can be used to speci the ified during the functional analysis. Tis also serves to confirm that the undefined fanctional requirements jel Design: The result ofthe logical design phase (or data model mapping phase) i st of cnion schemas The ER diagram the Basi or hese ration schemas. To crete the ration schemas ER model is transferred to relation schemas. ‘not done in previous phase) the arial user operations zhema meets ‘he relation sc primary keys a foreign keys are deine. ‘ormalization is the ast part of the logical design. The g which one can mo. more relations (tables) into the database, 1 The goal of the last phase of database design, physical design, the datsbase. At this phase one must Know which database management system (DB. taanple, diferent DBMS have diferent names for dat types and have dierent data pes The SQL lusts to create the database are exes, the integrity constra access rights are defined, Finally th application programs are designed. Th created and data as been added phase addsship Model || 97 puplieate ‘contains thee represented by a rectangle whic i tity Set Set of enites ofthe same type that share hes - seri Relat “empory Relationship Set: St of relationships ofthe same type. R ” spe ane to one, man tO one, oe 10 MAA 3 i . Fc a ona ina relationship Th = st : (pies | inden. ign key is not clusered indoad lationship We can insert a value to a primary key e manual tnsertion even ifthe referencing foreign key 2 feign ky inthe referenced pce Keys or Entity keys: Refers to an tte that uniguely defines an ent in an entity og Se ee Entity keys can be super, candidate or primary. Before you delete a make sure that value imary key value, from foreign key gether define an entity in an entity st attributes (one ot more) Super key: A et Candidate key: A minimal super key, meaning thas the least possible number of attributes to Deletion | in the referencing foreign key column of ing, whether that bea super ky. An entity set may have more than one candidat key referencing table ced primary key ‘able 1: Comparison between Super and Candidate Key (Criteria _[ Super Key ‘Candidate Key Table 3: Symbols Used in ER-Model wee or ast of abt at] per abst ofa supe ey which sai] | PSHBE2L ‘Sjmbol Description [Symbol asic | uniquely denies all atributesin a relations| rer he s canddate ey super key. ‘nein itis not compulsory that all super keys willbe | su candidate keys are super ther | candidate keys cna bey me per | Selecica OF super eye forms the base for] The set of candidate keys form the base a An entity is represented of candidate keys selection of single primary key. Entiy bya rectangle which contains the entty’s Weak Entity poe re comparatively more super keys in a Thea span os anit cm Primary key: A candidate key chosen bythe database designer to uniquely identify the entity set, Foreign key: Identifies the relationship between entities. Pe ET = ie | Carne) |e » a mary Key isa chosen candidate key that Foreign ky in a table refers to the primary tuniguely defines atupleinareation, | key f other table Saal NULL Primary key valu can neverbe NULL. __| Foreign key accepts NULL value, entity Sa ~~ Aad ce Symbol Description 1 of Figure 42 Complete eniy seUtype of Customer with ts atibutes representation 43 Enhanced Features ahacedenity-telationship models, also known a extended enity- relationship mode dtabase diagrams ver represent the reqltements and comp | Features of EER Model «_ EER creates a design more accurate to database schemas. ‘of complex databases = ‘Toss Parteigation A relationship where 1 of objects of diferent of diferent Child entity is exstence- Permanent | | Pan-time Empoyeo Empioyee Temporary Empoyee Figure 4.3 : Supertype and subtypes 432 Inheritance Inhertance is an import Toner the atbutes of For examy over Jevel entities such as Student or Teacher. Name SS Gender Set —] "easher ounber Employee Figure 44: Inheritance of Person entity ANS Figure 48 : ER Diagram showing Generateaton 434 Specialization ination may be seen asthe vers ere Crammer > Co) superclass. [scours] lower lever entities are combined to form a higher level ent ‘seeciaLarion For Example, Accounts genealied term. G ee] ee | Figure 4.7: ER Diagram showing Specialization B= ——, A 7104 ||_njormation Sytem Management ‘able 5: Comparison between Generalization and Specialization (Criteria | Generalization Specialization’ Basic Tr proceeds in bottom-up manner Function on group of entities sus in forming Result | entity from maiipl entities. 2 single entity from a single e 4:35 Category or rian Type (Category represents a single super class or sub class relationship with more than one super class. It can bea total or partial participation, For example Car booking, Car owner can be company. Category (sub lass) > Owner is a sul Bank, and Person. A Category member must exis ids a possession on a Car) or a three super classes > Company, ‘one of ts super classes. Person ‘Bank Company Owner Figure 4.8 Union Type 4.36 Joint dint or overlap) (2) A supertype/subtype relationship where the disjoint rule applies: The disjoint rule indicates thatthe supertype instance may not bea member ofthe two or more subtype. The rule specified with the letter (4) inside the circle i connected between the supertype and it subtypes For example, The supertype is “PERSON” that contains the different possible of subtypes "MALE" and "FEMALE" Here, the, led. Then, the “PERSON” supertype must either “MALE” subtype or “FEMALE” subtype at atime but not both a the same time. or relationship type with Attribute of relationship For example 1, the relationship type order connects e ‘ many to many becuse each chemical can be from several suppliers and exh > iom to Entity Relationship Model |) 105 PERSON |<+—— Suva Dist re Person can be ether ‘male ofa tnt é Somat sae oe wae (rena sues swype2 Figure 49 Disoint Rule [A supertype/subtype relationship where the overlap rule applies: The overlap rule (©) hat the aupertype stance may be a meaber ofthe two or ore subtype T swith the letter the dls connced betwen the sapere For example, The sopriype i “PERSON” that contains the eien pos FEMPLOVEE”, “VOLUNTEER” and "DONER: Tee, te vero ne sped. he “PERSON” supertype must be sbtypes EMPLOYEE" subtype “VOLUNTEER ns sl “BONER subype ta time maybe ala thesane ine ares ane iyisiatp Q—_ a Tere [EMPLOYEE (Rountree > = Figure 4.10 : Overap Rule a ADD OD DEPARTMENT 7 5 QOD OE Dae ial le acleecra ye co eas ves a BES os Professor © Figure 4.12 : Teaching relationship has RoomNo as attribute Ge relationship has attribute RoomiNo, which describes class room no, where For example 3, Workln relationship has two attribute since and status, which defines the entity professor. Profesor ; Worsin : Deopartmont Figure 4.13: Workin relatonship has Since and Status as atribute the relationship works_on bet ies EMPLOYEE and PROJECT has degree ‘and job as attribute, which specifies enter date and job profile of an employee in oval for Figure 4.15: ER Olam of evaluation fr a project by insu of she wie anes" . Aot Model 109 108 || Information System Management A Listormaton System Management led proj_guide which maps pro) the This is shown by enclosing the relationship and the corresponding entity sets in a box and then rarer a single entity, In oad ont the tee pat oe rough employe ofthe bank, then employe Eicentseut> | Rerseio> | paratly Figure 4.18 : ER Diagram of borrower loan from bank's employee with Aggregation | 3 example 2, Customer bo of the bank is related to customer anc 44 Degree “Arcltionship’s degree indicates the number of associated enti Figure 4.17: ER Diagram of borrower loan from bank's employee without Aggregation> a i ‘be driven by th ‘Was_sent 10 ‘car, which can only by Se ‘between employee and company car. (©) Binary relations! is atocates i a Seat [econ }-_—$_—[ oreo] ea (6) Temary relatonstip Figure 4.20 : One-to-one ‘one-to-many (1: M) or Many-to-one (ME: 1): Is where one occurrence in an entity relates to many occurrences in another entity, For example, taking the employee and departmen employee works in one department but a department has many employees. Therefore thes Figure 4.19: Relationship Degrees representation js. one-to-many relationship between department and employee. Similarly, many employees a department. Therefore, there is a manyo-one relationship between enployer snd Table 6: Deore Reatonstip used in ERO rita ere Wrto-one relationship betwen ep ‘egies Name Description 2 See ‘A unary relationship is when both participants in pam [oo eee ; the relationship are the Same entity For == =< Sens> | employee is supervised or works for/by none-o-one Figure 4.21 : Onerommany \ ‘ther employee. An employee may siperse many mony may other employees, |. Many-to-many (M:N): This is where many occurrences in an entity rl = ——- in another entity. For example, an employee may work on several p ‘A binary relationship is when two entities participa ani a project has a team of many employees. Therefor, there ia many: ‘Suaent conse and is the most common relatior ‘For between employee and project. Erample:Student- Course 2s e ons. ee fal Employee Proet naw — A ternary relationship is when three entities participate in the relationship. For Example: Student. Figure 4.22 : Many-to-many Ten] | Course Faculty as thee ene elton, [eal B.ship ymbots used for cardinaity jon [Relatonship Symbot — < Relationship Symbol berelated with only one other ae eet at bt 2e a nem 8 be Ss se“ en ee unl a is a nem ne mw! 2 7 ee ee ee be (one-one OnetoMany Many-o-One Manyo-Many Figure 4 24: Relationship mapping with examples l > 1.6 How to Drow ER Diagram eed of ER Diagram the ER Digs se sf in representing the retinship among i ‘people can understand. Many see i partment may have several ocat mntrols a number of projects, each of : number and. tifes Entities of the given problem. 1, DEPARTMENT (From Ist Pint) 2, PROJECT (From 2nd Poi 3, EMPLOYEE (From 3rd Poi 4. DEPENDENT (From 4th Point) Step 2: lentify the attributes ofthe above entities, 1. DEPARTMENT: Name, Number, Lo 2, PROJECT: Name, Number, Loca 3, EMPLOYEE: SSN, Name, Address, Salary 4, DEPENDENT: i 2, PROJECT: Name Number, Loca : SSN, Name, Address, Salary (Since, Social Security Number willbe Usigus ©