Considering Company as a Mini world Problem we need to design the Database. Company Database consists of: Company Info Employee Info Project Info The Formulated Requirements are: The company is organized into departments. Each department has a unique name, a unique number, and a particular employee who manages the department. We keep track of the start date when that employee began managing the department. A department may have several location A department controls a number of projects, each of which has a unique name, a unique number, and a single location We store each employee’s name, Social Security number, address, salary, sex (gender), and birth date. An employee is assigned to one department, but may work on several projects, which are not necessarily controlled by the same department. We keep track of the current number of hours per week that an employee works on each project. We also keep track of the direct supervisor of each employee (who is another employee). We want to keep track of the dependents of each employee for insurance purposes

1. Conceptual Data Modeling
Using
Entities & Relationships

2. High Level Conceptual Data Models
• Conceptual Design is a important phase in designing successful database applications
• Entity Relationship Model is the popular high level conceptual data model
• Object Modelling is also gaining the importance – Unified Modelling Language

3. A Sample Database Application
• Considering Company as a Mini world Problem we need to design the Database.
• Company Database consists of:
 Company Info
 Employee Info
 Project Info
• The Formulated Requirements are:
 The company is organized into departments. Each department has a unique name, a unique number, and a
particular employee who manages the department. We keep track of the start date when that employee
began managing the department. A department may have several location
 A department controls a number of projects, each of which has a unique name, a unique number, and a
single location
 We store each employee’s name, Social Security number, address, salary, sex (gender), and birth date. An
employee is assigned to one department, but may work on several projects, which are not necessarily
controlled by the same department. We keep track of the current number of hours per week that an
employee works on each project. We also keep track of the direct supervisor of each employee (who is
another employee).
 We want to keep track of the dependents of each employee for insurance purposes

4. A Sample Database Application

5. Entity Types, Entity Sets, Attributes &
Keys
• Entities and Attributes
 The basic object that the ER model represents is an Entity – Physical or Conceptual Existence
 Each Entity has Attributes – Particular Properties
 Types of Attributes
 Simple Vs Composite
 Single Vs Multi valued
 Stored Vs Derived
 NULL Values
 Composite Attributes

6. Entity Types, Entity Sets, Attributes &
Keys
• Entity Types, Entity Sets, Keys, and Value Sets
 An entity type defines a collection (or set) of entities that have the same attributes
 The collection of all entities of a particular entity type in the database at any point in
time is called an entity set
• Key Attributes of an Entity Type
 Uniqueness constraint - key attribute
 Weak Entity
• Value Sets of Attribute
• Mathematically, an attribute A of entity set E whose
value set is V can be defined as a function from E to
the power set P(V) of V -- A : E → P(V)
[Entity Set]
Employee
(Name, Age, Salary..)
E1 – [John Smith, 55, 80k]
E2 – [Fred Brown, 50, 60k]
[Entity Set]
Department
(Name, Location, Manager..)
D1 – [Finance, Delhi, John Smith]
D2 – [Sales, Hubballi, Fred Brown]

7. Conceptual Design of COMPANY
Database
 Department, Project, Employee and Dependents – Entity Types

8. Relationship Types, Relationship Sets,
Roles and Structural Constraints
 Relationship Types, Sets, and Instances
 A relationship type R among n entity types E1, E2, ..., En defines a set of associations —or a
relationship set
 Mathematically, the relationship set R is a set of relationship instances ri, where each ri
associates n individual entities (e1,e2,...,en)
 Relationship Degree, Role Names, and Recursive Relationships
 Degree of a Relationship Type
 Binary and Ternary Degree
 The degree of a relationship type is the number of
participating entity type

9. Relationship Types, Relationship Sets,
Roles and Structural Constraints
 Relationship as Attribute
 Role Names and Recursive Relationships
 Cardinality Ratios for Binary Relationships
 Participation Constraints and Existence Dependencies

10. Weak Entity Types
 The Entity Type that doesn’t have any key attribute - Weak Entity
 Strong Entity Type & Identifying Relationship
 A weak entity type normally has a partial key
 Redefining the ER Diagram – Company Database
 MANAGES, a 1:1 relationship type between EMPLOYEE and DEPARTMENT
 WORKS_FOR, a 1:N relationship type between DEPARTMENT and EMPLOYEE. Both
participations are total
 CONTROLS, a 1:N relationship type between DEPARTMENT and PROJECT
 SUPERVISION, a 1:N relationship type between EMPLOYEE
 WORKS_ON, determined to be an M:N relationship type with attribute Hours
 DEPENDENTS_OF, a 1:N relationship type between EMPLOYEE and DEPENDENT

11. ER Diagram

12. Thank You!!!