the entity-relationship diagramer diagram • entity relationship (er) diagram – a detailed,...
Post on 21-Apr-2020
21 Views
Preview:
TRANSCRIPT
The Entity-Relationship Diagram
Overview of Database Design
• Conceptual design: (ER Model is used at this stage.) – What are the entities and relationships in the
enterprise?– What information about these entities and relationships – What information about these entities and relationships
should we store in the database?– What are the integrity constraints or business rules that
hold? – A database “schema” in the ER Model can be
represented pictorially (ER diagrams).– We can map an ER diagram into a relational schema.
ER Diagram
• Entity Relationship (ER) Diagram
– A detailed, logical representation of the entities,
associations and data elements for an organization or
business
– An entity-relationship (ER) diagram is a specialized graphic
that illustrates the interrelationships between entities in a
database.
Framework for E/R
• The E/R model allows us to sketch database schema
designs
• Design is a serious business.
• The “boss” knows they want a database, but they
4
• The “boss” knows they want a database, but they
don’t know what they want in it.
• Sketching the key components is an efficient way to
develop a working database.
Main constructors of ER
– Data entities
– Relationships– Relationships
– Attributes
ER Model Basics
• Entity: Real-world object distinguishable from other objects. An entity is described (in DB) using a set of attributes.DB) using a set of attributes.
• An entity is shown in a rectangle.
• Entity Set: A collection of similar entities. E.g., all employees. – All entities in an entity set have the same set of
attributes. (Until we consider ISA hierarchies, anyway!)
Entities
• Examples of entities:– Person: EMPLOYEE, STUDENT, PATIENT
– Place: STORE, WAREHOUSE
– Object: MACHINE, PRODUCT, CAR
– Event: SALE,REGISTRATION, RENEWAL
– Concept: ACCOUNT, COURSE– Concept: ACCOUNT, COURSE
• Guidelines for naming and defining entity types:– An entity type name is a singular noun
– An entity type should be descriptive and specific
– An entity name should be concise
– Event entity types should be named for the result of the event, not the
activity or process of the event.
An entity’s name should be:• Unique in the entire organization; furthermore, try to avoid similar
names for different entities, such as PROJECT and P ROJECTION.
Choose a non-confusing name for both.
PROJECT PROJECTION
If different terms are used to define the same thin g underdifferent departments synonyms can be defined. For example,some departments may call it a CUSTOMER while other s maycall a CLIENT.
Finally one has to be chosen in database but when s peaking toFinally one has to be chosen in database but when s peaking todifferent people we must choose their terms.
Instances of entitiesIf you are not certain whether something is an enti ty or not, itmay help to ask yourself the question,
“What are the instances (examples) of this entity?”
To make sure your list includes real entities,
Here are some other ways:
Validate Entities
Is its name a noun? Not all nouns represent entitie s, but all entity names should be nouns.
To make sure your list includes real entities,
Here are some other ways:
Validate Entities
Does this entity have any attributes?
For example, if you think you have an entity named STUDENT, do you need to store facts about students?
Name, Student Number, Address, Birth Date .... YES, IT IS AN ENTITY.
To make sure your list includes real entities,
Here are some other ways:
Validate Entities
If you think you have an entity called CUSTOMER NAM E, ask the same question: Does it have any facts, attributes t o store? The country of origin, number of wovels, meaning of the name ....
Are these really important facts to store in your d atabase?
NOT! Then CUSTOMER NAME is not an entity.
Summary
• An entity is a thing of significance about which information needs to be stored; a class or category of thing; a named thing.
• When considering whether something is an entity or not, it helps to ask yourself the question, “What would some instances of this entity be?”
• An entity’s name should be unique in the entire organization and familiar to all.
• Once you have identified an entity and named it, you should diagram it; the diagram pictorially represents entities, the vital business relationships between them and the attributes to describe them.
• An attribute is any detail that serves to qualify, identify, classify, quantify, or express the state of an entity.
Logical DB Design: ER to Relational
• Entity sets to tables:
CREATE TABLE Employees (ssn CHAR(11),name CHAR(20),lot INTEGER,
ssnname
lotlot INTEGER,PRIMARY KEY (ssn))
Employees
Attributes
• An attribute is a property or characteristic for an entity
or a relationship type.
• It is shown in an oval.
• Example of entity types and associated attributes:
STUDENT: Student_ID, Student_Name,
Home_Address, Phone_Number, Major
Guidelines for naming attributes
– An attribute name is a noun.
– An attribute name should be unique
– To make an attribute name unique and clear, each – To make an attribute name unique and clear, each
attribute name should follow a standard format
– Similar attributes of different entity types should
use similar but distinguishing names.
Simple and Composite attributes
• A simple(atomic) attribute is an attribute composed
of a single component with an independent
existence.
• can not be further subdivided into smaller
components.
• A composite attribute, sometimes called a group
attribute, is an attribute composed of multiple
components, each with an independent existence.
• The names chosen for composite attributes should
be descriptive and general
Composite Attribute
Single-valued and Multi-valued attribute
• Single-valued attribute that holds a single value for each occurrence of an entity type.
• Multi-valued attribute that holds multiple values for each occurrence of an entity type.
• Multi-valued attributes are mapped by using additional • Multi-valued attributes are mapped by using additional relation schema. For each multi-valued attribute A, create a new relation R.
• This relation will include attribute corresponding to A plus the primary key K of the entity type or relationship type that has A as attribute. Combination of A and K becomes primary key of R.
Example: multivalued attribute
Multivalued attribute… an employee
may have more than one skill.
Derived attributes
• An attribute that represents a value that is derivable
from the value of a related attribute or set of
attributes, not necessarily in the same entity type.
• The values are held by some attributes may be
derived.
• The oval representing a derived attribute is drawn
with a dash line
Candidate Keys
• Some tables contain more than one column (or combination of columns –composite key) that can act as a primary key. These columns all possess the uniqueness property of a primary key. Here, the uniqueness property of a primary key. Here, also, null values are not allowed. These columns are called candidate keys. However, only one is designated as the primary key
• All candidate keys which are not chosen as "primary key" are Alternate keys.
Primary Key
• A primary key is used to uniquely identify each row in a table.
• this key does not allow null values and also does not allow duplicate values.not allow duplicate values.
• Primary keys can be specified either when the table is created (using CREATE TABLE) or by changing the existing table structure (using ALTER TABLE).
Example
• CREATE TABLE Student
(SID integer,
Last_Name varchar(30), Last_Name varchar(30),
First_Name varchar(30),
PRIMARY KEY (SID));
Foreign Key
• A foreign key is a field (or fields) that points to
the primary key of another table. The purpose
of the foreign key is to ensure referential
integrity of the data. In other words, only integrity of the data. In other words, only
values that are supposed to appear in the
database are permitted.
Example
• create table Enroll (Student_SID integer,
Courses_CID char(10),
Foreign Key(Student_SID) references
Student(SID),Student(SID),
Foreign Key(Courses_CID)references
Courses(CID)
);
Entity Type Key
• Every (regular) entity type has at least one key
• The entity type key is defined in a similar way as the relation
schema key
• To denote the primary key, underlining is used
• If a key has more than one attribute, it should be represented • If a key has more than one attribute, it should be represented
as a composite attribute
• e.g.Course
CourId
Subject
CourNoPNameNoOfpts
Relationships
Relationship: Association among two or more entities
Relationship Set: Collection of similar relationships.
Author Book
Relationship name:
writes
An author writes one or more books
A book can be written by one or more authors.
Guidelines for naming relationship
– Explain any restrictions on participation in the relationship
– Explain extent of the history that is kept in the relationship
– Explain whether an entity instance involved in a – Explain whether an entity instance involved in a relationship instance can transfer participation to another relationship instance
– Graphically, a relationship is represented by a diamond shaped box connecting associated entity types
ER Model Basics
lot
dname
budgetdid
sincename
Works_In DepartmentsEmployees
ssn
CREATE TABLE Works_In(ssn CHAR(11),did INTEGER,since DATE,PRIMARY KEY (ssn, did),FOREIGN KEY (ssn) REFERENCES Employees,
FOREIGN KEY (did) REFERENCES Departments)
Attributes on relationships
Sometimes it is useful to attach attributes to
a relationship
• to represent a certain characteristic or • to represent a certain characteristic or
property of that relationship
Degree of Relationships
• Degree: number of entity types that participate in a relationship
• Three cases
– Unary: between two instances of one entity type
– Binary: between the instances of two entity types
– Ternary: among the instances of three entity types
– Quaternary: among the instances of three entity types– Quaternary: among the instances of three entity types
Recursive Relationships
• A relationship may be defined between entities of the same entity set
• Associations between entities of the same set are called recursiveare called recursive
• Every entity in a relationship has a role
• In the case of a recursive relationship, the roles should be shown explicitly
Example :Unary
Example: Ternary
Example-Quaternary
Cardinality and Connectivity
• Relationships can be classified as either
• one – to – one
• one – to – many
• many – to –manyConnectivity
• many – to –one
• Cardinality : minimum and maximum number of
instances of Entity B that can (or must be) associated
with each instance of entity A.
Connectivity
• Chen Model
– 1 to represent one.
– M to represent many
• Crow’s Foot
1
M
• Crow’s Foot
many
One
One or many
Mandatory one , means (1,1)
Cardinality Ratio
• The cardinality ratio of R is an expression of the form
R E2E1
b2 b1
• The cardinality ratio of R is an expression of the form
b1 :b2
where b1 is the maximal number of E2 instances that may be associated with an E1 instance, b2 is the maximal number of E1 instances that may be associated with an E2 instance, and b∈{1, N }
Cardinality Limits
Mapping Cardinalities
One to one One to many
Note: Some elements in A and B may not be mapped to any elements in the other set
Mapping Cardinalities
Many to one Many to many
Note: Some elements in A and B may not be mapped to any elements in the other set
Crow’s foot modell
ManMan WomanWoman
One-to-one (1:1)
One-to-many (1:n)
CustomerCustomer OrderOrder
CourseCourse SubjectSubject
Many-to-many (n:m)
NOTE: Every many to many relationship consists of two one to
many relationships working in opposite directions
Participation Constraint
• The participation constraint specifies whether existence of an entity
depends on its association with another entity
• A participation constraint can be:
– Total when it models existence dependence,
– Partial
• Graphic representation ( | partial, || total)• Graphic representation ( | partial, || total)
• Mind that participation constraint is placed on that side of the relationship
where the considered entity belongs
Manages SchoolHeadOfSchool1 1
HOS
total partial
Question for you
• Cardinality ratio and participation constraint are together
called structural constraint
• Cardinality ratio can be either 1 : 1, 1 : N, or M : N
• participation constraint can be either total or partial
• How many different structural constraints are there:• How many different structural constraints are there:
– 2
– 4
– 8
– 12
Participation: Full/Partial
• It is likely that on any campus, not all students will drive an automobile
• To show that every automobile is driven by a student, but not every
student drives an automobile, we will enhance our model of ER diagrams
by putting a double line between the relationship diamond and the
AUTOMOBILE entity to indicate that every automobile is driven by oneAUTOMOBILE entity to indicate that every automobile is driven by one
student. Put another way, every automobile in the database participates
in the relationship.
• From the student side, we leave the line between the STUDENT entity and
the relationship as a single line to indicate that not every student drives an
automobile. Some students will not participate in the drive relationship
because they do not drive a car on campus. The single/double lines are
called participation constraints.
Relationships of the Degree > 2
CourseStudent SPL
LecturerLecturer
Instances of the SPL relationship type are triples (s, c, l ). The structuralconstraints are determined by considering associations between:• a (s, c ) pair and a l to determine cardinality ratio next to Lecturer, andbetween a l and a (s, c ) pair to determine the participation constraint of the Lecturer
• the same applies to a (s, l ) pair and a c for a Course instance, and a •(l, c ) pair and a s for a Student instance
Relationships of the Degree > 2
CourseStudent SPL
Lecturer
1
N N
Lecturer
Suppose each Course c is taught by only one lecturer l and each lecturer teaches at least one Course. Then:• each (s, c ) pair is associated with exactly one l, so the cardinalityratio next to Lecturer will be 1, and the Lecturer has a total participation constraint,
• it is natural to expect that each (l, c ) pair is associated with zero or morethan one students, and
• each (s, l ) pair with zero or more than one Course
top related