RDBMS_Day2 - RDBMS-Day2 Logical Database design...

Info iconThis preview shows pages 1–9. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: RDBMS-Day2 Logical Database design Normalization ER/CORP/CRS/DB07/003 Version No: 2.0 2 Copyright 2004, Infosys Technologies Ltd Recap of Day1 session RDBMS handles data in the form of relations, tuples and fields Keys identify tuples uniquely ER modeling is a diagrammatic representation of the conceptual design of a database ER diagrams consist of entity types, relationship types and attributes Since day 2 is a continuation of day1 content, this recap is done here to maintain the continuity Logical database design Converting ER diagrams to relational schema Logical database design Process of converting the conceptual model into an equivalent representation in the implementation model (relational/hierarchical/network etc.) We will focus on the relational model Relational database design Convert ER model into relational schema (a specification of the table definitions and their foreign key links) There are well defined rules for this conversion ER/CORP/CRS/DB07/003 Version No: 2.0 4 Copyright 2004, Infosys Technologies Ltd Converting Strong entity types Each entity type becomes a table Each single-valued attribute becomes a column Derived attributes are ignored Composite attributes are represented by components Multi-valued attributes are represented by a separate table The key attribute of the entiry type becomes the primary key of the table ER/CORP/CRS/DB07/003 Version No: 2.0 5 Copyright 2004, Infosys Technologies Ltd Entity example Here address is a composite attribute Years of service is a derived attribute (can be calculated from date of joining and current date) Skill set is a multi-valued attribute The relational Schema Employee ( E#, Name, Door_No, Street, City, Pincode , Date_Of_Joining) Emp_Skillset ( E#, Skillset ) As per the rules: Derived attributes are ignored Composite attributes are represented by components Multi-valued attributes are represented by a separate table ER/CORP/CRS/DB07/003 Version No: 2.0 6 Copyright 2004, Infosys Technologies Ltd Entity Example (Contd) Skills EmpCode FK SkillSet SkillSet DateofJoining EmpName EmpCode PK Employee Table ER/CORP/CRS/DB07/003 Version No: 2.0 7 Copyright 2004, Infosys Technologies Ltd Converting weak entity types Weak entity types are converted into a table of their own, with the primary key of the strong entity acting as a foreign key in the table This foreign key along with the key of the weak entity form the composite primary key of this table The Relational Schema Employee ( E# ,.) Dependant ( Employee, Dependant_ID , Name, Address) Here dependant is a weak entity. Dependant doesnt mean anything to the problem without the information on for which employee the person is a dependant. ER/CORP/CRS/DB07/003 Version No: 2.0 8 Copyright 2004, Infosys Technologies Ltd Converting weak entity types (Contd) Address Name Dependent_ID PK EmpCode PK /FK Dependent SkillSet DateofJoining EmpName EmpCode PK Employee Table ER/CORP/CRS/DB07/003...
View Full Document

Page1 / 65

RDBMS_Day2 - RDBMS-Day2 Logical Database design...

This preview shows document pages 1 - 9. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online