database designing

8/14/2019 DataBase Designing

1/45

Database DesignDatabase Design


2/45

Data ModelData Model

A data model is a collection of high-levelA data model is a collection of high-leveldata description constructs that hide manydata description constructs that hide manylow-level storage details. A DBMS allowslow-level storage details. A DBMS allowsa user to define the data to be stored ina user to define the data to be stored interms of a data model.terms of a data model.Models contain a wide variety of Models contain a wide variety of constructs that help describe a realconstructs that help describe a realapplication scenario.application scenario.


3/45

Data ModelData Model

A database design in terms of a modelA database design in terms of a modelserves as a useful starting point and isserves as a useful starting point and issubsequently translated into a databasesubsequently translated into a databasedesign in terms of the data model thedesign in terms of the data model theDBMS actually supports.DBMS actually supports.


4/45

OVERVIEWOF DATABASEOVERVIEWOF DATABASEDESIGNDESIGN

The database design process can beThe database design process can bedivided into six steps.divided into six steps.

1.1. Requirements AnalysisRequirements Analysis

2.2. Conceptual Database DesignConceptual Database Design3.3. Logical Database DesignLogical Database Design4.4. Schema RefinementSchema Refinement5.5. Physical Database DesignPhysical Database Design6.6. Security DesignSecurity Design

The Entity Relationship model is most relevant toThe Entity Relationship model is most relevant tothe first three steps.the first three steps.


5/45

Requirements AnalysisRequirements Analysis

The very first step in designing a databaseThe very first step in designing a databaseapplication is to understand what data is toapplication is to understand what data is tobe stored in the database, whatbe stored in the database, whatapplications must be built on top of it, andapplications must be built on top of it, andwhat operations are most frequent andwhat operations are most frequent andsubject to performance requirements. Insubject to performance requirements. In

other words, we must find out what theother words, we must find out what theusers want from the database.users want from the database.


6/45

Requirements Analysis (cont.)Requirements Analysis (cont.)

This is usually an informal process that involvesThis is usually an informal process that involvesdiscussions with user groups, a study of thediscussions with user groups, a study of thecurrent operating environment and how it iscurrent operating environment and how it isexpected to change, analysis of any availableexpected to change, analysis of any availabledocumentation on existing applications that aredocumentation on existing applications that areexpected to be replaced or complemented byexpected to be replaced or complemented bythe database, and so on. Several methodologiesthe database, and so on. Several methodologieshave been proposed for organizing andhave been proposed for organizing andpresenting the information gathered in this step,presenting the information gathered in this step,and some automated tools have been developedand some automated tools have been developedto support this process.to support this process.


7/45

Conceptual Database DesignConceptual Database Design

The information gathered in theThe information gathered in therequirements analysis step is used torequirements analysis step is used todevelop a high-level description of thedevelop a high-level description of thedata to be stored in the database, alongdata to be stored in the database, alongwith the constraints that are known to holdwith the constraints that are known to holdover this data. This step is often carriedover this data. This step is often carried

out using theout using the ER model ER model , or a similar high-, or a similar high-level data model, and is discussed in thelevel data model, and is discussed in therest of this Course.rest of this Course.


8/45

Logical Database DesignLogical Database Design

We must choose a DBMS to implement our We must choose a DBMS to implement our database design, and convert the conceptualdatabase design, and convert the conceptualdatabase design into a database schema in thedatabase design into a database schema in the

data model of the chosen DBMS.data model of the chosen DBMS.We will only consider relational DBMSs, andWe will only consider relational DBMSs, andtherefore, the task in the logical design step is totherefore, the task in the logical design step is toconvert an ER schema into a relational databaseconvert an ER schema into a relational databaseschema. The result is a conceptual schema,schema. The result is a conceptual schema,sometimes called the logical schema, in thesometimes called the logical schema, in therelational data model.relational data model.


9/45

Schema RefinementSchema Refinement

The fourth step in database design is toThe fourth step in database design is toanalyze the collection of relations in our analyze the collection of relations in our relational database schema to identifyrelational database schema to identifypotential problems, and to refine it. Inpotential problems, and to refine it. Incontrast to the requirements analysis andcontrast to the requirements analysis andconceptual design steps, which areconceptual design steps, which are

essentially subjective, schema refinementessentially subjective, schema refinementcan be guided by some elegant andcan be guided by some elegant andpowerful theory. (powerful theory. ( NormalizationNormalization ))


10/45

Physical Database DesignPhysical Database Design

In this step we must consider typicalIn this step we must consider typicalexpected workloads that our databaseexpected workloads that our databasemust support and further refine themust support and further refine the

database design to ensure that it meetsdatabase design to ensure that it meetsdesired performance criteria. This stepdesired performance criteria. This stepmay simply involve building indexes onmay simply involve building indexes onsome tables and clustering some tables,some tables and clustering some tables,or it may involve a substantial redesign of or it may involve a substantial redesign of parts of the database schema obtainedparts of the database schema obtainedfrom the earlier design steps.from the earlier design steps.


11/45

Security DesignSecurity Design

In this step, we identify different user groups andIn this step, we identify different user groups anddifferent roles played by various users (e.g., thedifferent roles played by various users (e.g., thedevelopment team for a product, the customer development team for a product, the customer

support representatives, the product manager).support representatives, the product manager).For each role and user group, we must identifyFor each role and user group, we must identifythe parts of the database that they must be ablethe parts of the database that they must be ableto access and the parts of the database that theyto access and the parts of the database that theyshould not be allowed to access, and take stepsshould not be allowed to access, and take stepsto ensure that they can access only theto ensure that they can access only thenecessary parts.necessary parts.


12/45

Entity Relationship ModelEntity Relationship ModelENTITIES, ATTRIBUTES, ANDENTITIES, ATTRIBUTES, AND

ENTITY SETSENTITY SETS


13/45

EntityEntity

AnAn entity entity is an object in the real world that isis an object in the real world that isdistinguishable from other objects.distinguishable from other objects.

Examples include the following: the Green toy, the toyExamples include the following: the Green toy, the toydepartment, the manager of the toy department, the homedepartment, the manager of the toy department, the homeaddress of the manager of the toy department.address of the manager of the toy department.

It is often useful to identify a collection of similar entities.It is often useful to identify a collection of similar entities.Such a collection is called anSuch a collection is called an entity set.entity set.

Note that entity sets need not be disjoint; the collection of toyNote that entity sets need not be disjoint; the collection of toydepartment employees and the collection of appliancedepartment employees and the collection of appliancedepartment employees may both contain employee Ahmed (whodepartment employees may both contain employee Ahmed (whohappens to work in both departments). We could also define anhappens to work in both departments). We could also define anentity set called Employees that contains both the toy andentity set called Employees that contains both the toy andappliance department employee sets.appliance department employee sets.


14/45

AttributesAttributes

An entity is described using a set of An entity is described using a set of attributesattributes . All entities in a given entity set. All entities in a given entity sethave the same attributes.have the same attributes.

Our choice of attributes reflects the levelOur choice of attributes reflects the levelof detail at which we wish to representof detail at which we wish to representinformation about entities.information about entities.

For example, the Employees entity set could useFor example, the Employees entity set could usename, CNIC number (CNIC), and department( dept)name, CNIC number (CNIC), and department( dept)as attributes. In this case we will store the name,as attributes. In this case we will store the name,CNIC number, and Dept. number for each employee.CNIC number, and Dept. number for each employee.However, we will not store, say, an employee'sHowever, we will not store, say, an employee'saddress (or gender or age).address (or gender or age).


15/45

AttributesAttributes

For each attribute associated with anFor each attribute associated with anentity set, we must identify aentity set, we must identify a domaindomain of of possible values.possible values.


16/45

KeyKey

A key is a minimal set of attributes whoseA key is a minimal set of attributes whosevalues uniquely identify an entity in thevalues uniquely identify an entity in theset. There could be more than oneset. There could be more than onecandidate key; if so, we designate one of candidate key; if so, we designate one of them as the primary key.them as the primary key.


17/45

EXAMPLEEXAMPLE

EMPLOYEE

CNIC NAME DEPT

= ENTITY =ATTRIBUTE


18/45

RELATIONSHIPS ANDRELATIONSHIPS ANDRELATIONSHIP SETSRELATIONSHIP SETS

A relationship is an association among two A relationship is an association among twoor more entitiesor more entities . For example, we may. For example, we mayhave the relationship that Ali works in thehave the relationship that Ali works in thepharmacy department. As with entities, wepharmacy department. As with entities, wemay wish to collect a set of similar may wish to collect a set of similar relationships into a relationship set.relationships into a relationship set.

To avoid confusion, we will assume that attribute names do not repeat acrossentity sets. This is not a real limitation because we can always use the entity set name to resolve ambiguities if the same attribute name is used in morethan one entity set.


19/45


EMPLOYEE

CNIC NAME DEPT

DEPARTMENT

DEPT# NAME

WORK

= Relationship


20/45

RELATIONSHIPS ANDRELATIONSHIPS AND

RELATIONSHIP SETSRELATIONSHIP SETSDegrees of RelationshipDegrees of Relationship


21/45

Degrees of RelationshipDegrees of RelationshipBinary RelationshipBinary Relationship

Such a Relationship in which 2 entitySuch a Relationship in which 2 entityparticipate.participate.

EMPLOYEE

CNIC NAME DEPT

DEPARTMENT

DEPT# NAME

WORK


22/45

Degrees of RelationshipDegrees of RelationshipTernary RelationshipTernary Relationship

Suppose that each department has officesSuppose that each department has officesin several locations and we want to recordin several locations and we want to recordthe locations at which each employeethe locations at which each employeeworks. This relationship is ternary becauseworks. This relationship is ternary becausewe must record an association betweenwe must record an association betweenan employee, a department, and aan employee, a department, and a

locationlocation


23/45

Degrees of RelationshipDegrees of RelationshipTernary RelationshipTernary Relationship

EMPLOYEE

CNIC NAME DEPT

DEPARTMENT

DEPT# NAME

WORK

LocationAddress Telephone


24/45

Degrees of RelationshipDegrees of RelationshipUniary RelationshipUniary Relationship

The entity sets that participate in aThe entity sets that participate in arelationship set need not be distinct;relationship set need not be distinct;sometimes a relationship might involvesometimes a relationship might involvetwo entities in the same entity set.two entities in the same entity set.

EMPLOYEE

Reports to


25/45


A relationship can also have descriptiveA relationship can also have descriptiveattributes. Descriptive attributes are usedattributes. Descriptive attributes are usedto record information about theto record information about therelationship, rather than about any one of relationship, rather than about any one of the participating entities; for example, wethe participating entities; for example, wemay wish to record that ALI works in themay wish to record that ALI works in the

pharmacy department as of January 1991pharmacy department as of January 1991


26/45


EMPLOYEE

CNIC NAME DEPT

DEPARTMENT

DEPT# NAME

WORK

LocationAddress Telephone

since


27/45

Participation ConstraintsParticipation Constraints


28/45

Cardinality constraintsCardinality constraints

There constraints are useful because theyThere constraints are useful because theyallow to maintain theallow to maintain the logical integrity logical integrity of theof thedatabase.database.One-to-One (1:1)One-to-One (1:1)One-to-Many (1:M)One-to-Many (1:M)

Many-to-Many (M:M)Many-to-Many (M:M)


29/45

One-to-OneOne-to-One

Child Mother Has

Child Mother Has1..1


30/45

One-to-ManyOne-to-Many

Child Mother Has1..1

Child Mother Has1..11..M


31/45

Many-to-ManyMany-to-Many

Student Courseregister 0..M0..M


32/45

Weak EntitiesWeak Entities


33/45


A weak entity can be identified uniquelyA weak entity can be identified uniquelyonly by considering some of its attributesonly by considering some of its attributesin conjunction with the primary key of in conjunction with the primary key of another entity, which is called theanother entity, which is called theidentifying owner identify ing owner ..


34/45


The following restrictions must hold:The following restrictions must hold:The owner entity set and the weak entity setThe owner entity set and the weak entity setmust participate in a one-to-many relationshipmust participate in a one-to-many relationship

set (one owner entity is associated with one or set (one owner entity is associated with one or more weak entities, but each weak entity has amore weak entities, but each weak entity has asingle owner). This relationship set is called thesingle owner). This relationship set is called theidentifying relationship set of the weak entity set.identifying relationship set of the weak entity set.The weak entity set must haveThe weak entity set must have total participationtotal p articipation in the identifying relationship set.in the identifying relationship set.


35/45


Total participation:Total participation:The total participation of an entity (type) in aThe total participation of an entity (type) in acertain relationship means that every entitycertain relationship means that every entitythat belongs to the entity type participates inthat belongs to the entity type participates inat least one instance of the relationship.at least one instance of the relationship.Weak entities cannot be identified by their Weak entities cannot be identified by their

own attributes but also require the attributesown attributes but also require the attributesof another entity.of another entity.


36/45

Class HierarchiesClass Hierarchies


37/45


Sometimes it is natural to classify theSometimes it is natural to classify theentities in an entity set into subclasses.entities in an entity set into subclasses.For example, we might want to talk aboutFor example, we might want to talk aboutan Hourly Emps entity set and a Contractan Hourly Emps entity set and a ContractEmps entity set to distinguish the basis onEmps entity set to distinguish the basis onwhich they are paid. We might havewhich they are paid. We might haveattributes hours worked and hourly wageattributes hours worked and hourly wagedefined for Hourly Emps and an attributedefined for Hourly Emps and an attributecontractid defined for Contract Emps.contractid defined for Contract Emps.


38/45


EMPLOYEE

Hourly EmployeeContract Employee

CNIC Name Dept

Hourly Wage

Contract ID

ISAHourly Rate


39/45

SUPER CLASS & SUB CLASSSUPER CLASS & SUB CLASS

Employees is specialized into subclasses.Employees is specialized into subclasses.Specialization is the process of identifyingSpecialization is the process of identifyingsubsets of an entity set (subsets of an entity set ( the super classthe super class ))that share some distinguishingthat share some distinguishingcharacteristic. Typically the super class ischaracteristic. Typically the super class isdefined first, the subclasses are defineddefined first, the subclasses are defined

next, and subclass-specific attributes andnext, and subclass-specific attributes andrelationship sets are then added.relationship sets are then added.


40/45

GeneralizationGeneralization

Hourly Emps and Contract Emps areHourly Emps and Contract Emps are generalized generalized bybyEmployees. As another example, two entity setsEmployees. As another example, two entity setsMotorboats and Cars may be generalized into an entityMotorboats and Cars may be generalized into an entityset Motor Vehicles. Generalization consists of identifyingset Motor Vehicles. Generalization consists of identifying

some common characteristics of a collection of entitysome common characteristics of a collection of entitysets and creating a new entity set that contains entitiessets and creating a new entity set that contains entitiespossessing these common characteristics.possessing these common characteristics.Typically the subclasses are defined first, the super Typically the subclasses are defined first, the super

class is defined next, and any relationship sets thatclass is defined next, and any relationship sets that

involve the super class are then defined.involve the super class are then defined.


41/45

Constraints with respect to ISAConstraints with respect to ISAhierarchieshierarchies

We can specify two kinds of constraints with respect toWe can specify two kinds of constraints with respect toISA hierarchies, namely, overlap and coveringISA hierarchies, namely, overlap and coveringconstraints.constraints.Overlap constraints determine whether two subclassesOverlap constraints determine whether two subclasses

are allowed to contain the same entity.are allowed to contain the same entity.For example, can ALI be both an Hourly Emps entity andFor example, can ALI be both an Hourly Emps entity anda Contract Emps entity? Intuitively, no. Can he be both aa Contract Emps entity? Intuitively, no. Can he be both aContract Emps entity and a Senior Emps entity?Contract Emps entity and a Senior Emps entity?Intuitively, yes. We denote this by writing Contract EmpsIntuitively, yes. We denote this by writing Contract EmpsOVERLAPSOVERLAPS Senior Emps. In the absence of such aSenior Emps. In the absence of such astatement, we assume by default that entity sets arestatement, we assume by default that entity sets areconstrained to have no overlap.constrained to have no overlap.


42/45

Covering constraintsCovering constraints

Covering constraints determine whether the entities inCovering constraints determine whether the entities inthe subclasses collectively include all entities in thethe subclasses collectively include all entities in thesuper class. For example, does every Employees entitysuper class. For example, does every Employees entityhave to belong to one of its subclasses? Intuitively, no.have to belong to one of its subclasses? Intuitively, no.

Does every Motor Vehicles entity have to be either aDoes every Motor Vehicles entity have to be either aMotorboats entity or a Cars entity? Intuitively, yes; aMotorboats entity or a Cars entity? Intuitively, yes; acharacteristic property of generalization hierarchies ischaracteristic property of generalization hierarchies isthat every instance of a super class is an instance of athat every instance of a super class is an instance of asubclass. We denote this by writing `subclass. We denote this by writing ` Motorboats ANDMotorboats AND

Cars COVER Motor VehiclesCars COVER Motor Vehicles ..In the absence of such a statement, we assume byIn the absence of such a statement, we assume bydefault that there is no covering constraint; we can havedefault that there is no covering constraint; we can havemotor vehicles that are not motorboats or cars.motor vehicles that are not motorboats or cars.


43/45

Reading TaskReading TaskAggregationAggregation


44/45

CONCEPTUAL DATABASECONCEPTUAL DATABASEDESIGN WITHDESIGN WITH

THE ER MODELTHE ER MODEL


45/45

CONCEPTUAL DATABASECONCEPTUAL DATABASEDESIGNDESIGN

Developing an ER diagram presents severalDeveloping an ER diagram presents severalchoices, including the following:choices, including the following:Should a concept be modeled as an entity or anShould a concept be modeled as an entity or anattribute?attribute?Should a concept be modeled as an entity or aShould a concept be modeled as an entity or arelationship?relationship?What are the relationship sets and their What are the relationship sets and their

participating entity sets? Should we use binaryparticipating entity sets? Should we use binaryor ternary relationships?or ternary relationships?Should we use aggregation?Should we use aggregation?

database designing

Documents