Published on

conceptual design part 1

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Introduction to database management system Database : data is stored in digital form. CONCEPTUAL DESIGN USING ER( ENTITY RELATIONSHIP) MODEL Fundamentals component of today database is tables. Why do we need ER modeling ? Database is embedded in information application UOD DATABASE REQUIREMENTS FUNCTIONAL REQUIREMENT REQUIRMENTS/COLLECTON AND ANALYSIS
  2. 2.  UOD : (universe of discourse) The portion of the real world relevant to the database is sometimes referred to as the universe of discourse or as the database mini world.  Requirements and collection and then analysis: in this we basically do requirement analysis and finding the types of entity and their rules and relations with other entity. That gives two types of requirements.  1. database requirement : we can say its data requirement. It is handled by the DBMS. DBMS is called as engine. We need layering around this engine and this layering is called as information application like a car which surrounds the engine.  2. functional requirement: this helps in the design of the application.  Theses are the DBMS independent process means that it does not depend whether we are using the oracle database or IBM database type or MYSQL database or whatever database we are using we have to understand UOD and come out with the conceptual schema.  Database requirement → conceptual design → conceptual schema  Functional requirement → functional analysis → high level transaction specification
  3. 3.  The above design is the DBMS dependent process because the physical organization of data in ORACLE and IBM may be different. That means they have different access mechanism. This physical organization of data is called internal schema.  Even the transaction will also be affected by the physical organization of the data.  Thus we programmer must know the physical organization of the data. Physical design Conceptual schema Internal schema High level Transaction specification Application program design Transaction implementation software
  4. 4. Conceptual schema  It is the outcome of the high level conceptual design of the database. For this we have to understand the UOD that is what can kind of data should be taken in the UOD. Example of banking, in this there are accounts, customer or account holders and there can some form of the monetary transaction. All these represent some form of the data. Thus we will identify the relationship among the customer or accounts entity etc. thus it includes the description of entity types. There can certain constraint which can be imposed by the system( bank balance cannot be < 500) or the UOD ( like two trains have the arrival time same at the same plateform number).  There is no implementation detail mentioned. We are not worried about how this conceptual schema will implement.  The main behind conceptual design is ease of understanding. Thus the end user ( non technical users) must understand the conceptual schema.  Example of COMPANY database  Department : name , Did, ….  Department is the entity and name , Did are the attributes of the entity department.
  5. 5. Standard notation of representing entity and attributes  An entity represents an object of the real world that has the independent existence. The independent existence means that the entity is independent of every other entity in the system.  An entity has attributes – properties that describe it.  Kinds of attributes :  a. Simple attributes : it is the single attribute which defines its own characterstics. Example like age attribute. No further decomposition can be possible.  b. Composite attributes : it is made up of two or more simple attributes of composite attributes. Example name consist of first name and middle name and last name. Department depart_name dept_id Manager
  6. 6.  Single value attribute : A single valued attribute is one that holds a single value for a single entity. Example: roll_number, name etc.  Multivalued attribute : Multivalued attribute is one that holds multiple values for a single entity. Example: degree behold by a person (MS, PhD).  How multivalued attribute different from the composite attribute ?  Ans : a composite attribute is made of sub attributes like name is made up of first , middle and last name and all of them need not be the same type that is all of them do not have the same value at the same time whereas the multivalued attribute say color of the peacock have different values of color at the same.  Stored attribute : the attribute which just stored in the database. Example , datofbirth, we just give the date of birth to the system and stored in the system.  Derived attribute: the attribute whose value can be inferred from the value of the other attribute. Example age is the derived attribute , given the date of birth minus today dates gives the age of the attribute.  Null attributes : attributes that do not have applicable values are said to have null values. A null value is different from 0 , missing value or unknown.
  7. 7. Entity types and Entity sets  An entity type defines a collection of different entities having the same type. Example “department” of the company. A company consist of different departments. But all of them have the same number of attributes or same attribute structure. Thus entity type is a collection of all the different departments of the company.  Any specific collection of entities of a particular type is called an entity set. For example the entity set employee (all employees of a bank) and the entity set customer (all customers of the bank).  An entity type describes the schema of the entity set.  Key attribute: the attribute which uniquely identifies the entity in the entity set.  Composite key : a collection of the attributes define the key, the set is called as composite key.  A composite key should be minimal. No subset of the composite key should be minimal.  Weak entity type: the entity type foe which we cannot define the key attributes. For this type of entity, all the tuples have to totally participate in the relationship.
  8. 8. Domain of attributes  Domain of attributes basically defines the space in which the values of the specific attribute lies. Example age can be lie between 1 to 70 or 80 but can never be negative.  If the composite attribute have the value d1 , d2, …. then its domain id d1xd2x.... that is cartsisan product of the domains of individual attributes.  Relationship types relate two or more entity types and defines the relationship set. Any given depiction of a relationship type is called as relation ship instance.  A relationship type of R defines the set of an association among the entity types.  Degree of relationship type : the number of the participating entity types in the relationship type. There can be unary , ternary and binary relationship type.
  9. 9.  Constraint on the relationship type: constraint which limit the possible combination of entities that can participate in the relationship type.  Two types of the constraint on the relationship type: cardinality ratio: N:1 , this means that the department can have any number of the employees but the employee can only work for one department. Participation constraint: M:N if every project has to be associated with a department, then the “existence” of an instance of project entity type depends on the existence of an instance of the handle relationship types. Total participation is represented by double line. Employee DepartmentWorks for Departme nt Projecthandles
  10. 10. Attribute of the relationship type  Budget neither belongs to the department nor project. It just specifies the budget of each of the project with respect to specific department. Relationship attribute can be moved to one of the entity types. Departme nt Projecthandles Budget Departme nt Projecthandles Budget
  11. 11. Identifying relationships  Insurance record is a “weak entity set” which has no existence without its association with the employee entity. The relationship insurance details is an identifying relationship instance. The key of the employee will defines the insurance record entity type. Not all the total participation relationship type represents and identifying relationships. Example project and department Employee Insurance record Insurance details PAN