Entity-relationship

model
Lecture №2. ER diagrams
Attendance
Use this form to confirm your presence at a lecture
Database life cycle
Database - a part of an information system that has its own life cycle:

1. Planning (creation of a database and its integration into the existing

infrastructure: cost, tech. properties, methods of collecting information,
etc.).
2. Requirements analysis (load: number of users, data volumes,
information protection, reliability, etc.).
3. Designing (formalization of ideas and transformation
unstructured/semistructured data in structured (with data type and
available operations).

3
Stages of database design
1. Conceptual (graphic models of the type "entity-relationship"). Purpose:
to get a list of entities with relationships.
2. Logical - transformation of a conceptual model into a datological one,
for example, relational or documentary, as well as normalization of the
data scheme in order to avoid unprofitable redundancy.
3. Physical - optimization of storage on physical media.

4
Database testing
Database testing is:

● checking the compliance of the developed database structure with the

real subject area and specifications,
● control relationships between tables,
● assessing system performance and its ability to scale as needed.

Testing takes place both directly by potential users of the database and with
the help of special software that evaluates the various characteristics of the
database server.

5
Database operation
Database operation includes:

● monitoring the performance of user requests,

● keeping and analysis of operation logs of various subsystems related to
the DBMS,
● control of information security of the database, in particular, prevention
of unauthorized access to it,
● management of information storage on appropriate media and periodic
performance of database redundancy.

6
Model "Entity-Relationship»
Goal: formalization of ideas = structuring of data.

Not always - an appendage to relational databases. Describes structures, not

data.

Method of construction: interview with an expert in the subject area.

Benefits: simplicity and possibility of automatic conversion into the scheme of

a real database

Components of ER-models:

- Entities [strong, weak] [id-dependent, id-independent], subtypes

[exclusive, inclusive].
- Attributes (key and non-key (atomic, derivative, composite, ambiguous).
- Relationships (unary =recursive, binary, N-arn, cardinality and affiliation
classes). 7
Entity
Entity, which describes the real or imaginary object class of subject area.
Sometimes the entity is actually several entities (table "Class schedule",
sometimes - attribute ("Faculty") .Depends on the context of the database.

For example, student, book, computer, order, etc.

An instance of the entity there is a specific representative of the class of

objects, for example, a student "Dmitrenko", a book "C ++", a computer
"Model M1", an order "N321", etc. Graphically, the entity is denoted by a
rectangle:

8
Types of entities
Strong entity - independent or parent entity (has its own list of attributes
including the key).

Weak entity- can not exist without another (parent). For example, a building
room cannot exist outside the building(is that always the case?)

Weak entity id-dependent if the weak entity key includes the parent key,
otherwise id-independent. Example:
Building (bid, kname), room(bid, rid, rnumber) - id-dependent - stronger
control!
Building (bid, kname), room (bid, rid, rnumber) - id-independent; 9
Dependent entities are subtypes
Example:
Student (sid, sname)
Bachelor (sid, b_speciality), Master(sid, m_speciality) --- subtypes
Exclusive subtype: only one of the subtypes (make a pointer field in the
parent), fig. left
Inclusive subtype: one or more of the subtypes, Fig. right.

10
Attributes
An attribute that defines a certain characteristic of the entity. For example, in
entity, the Student attributes are "record book number", "surname", "date of
birth" and so on. Graphically, the attribute is denoted as an oval:

In some specific cases, different types of attributes are used:

Key attribute, which is designed to uniquely identify a particular instance of

an entity.

11
Key attribute
For example, "Student's record number", or "VIN-number of the car". It should
be noted that any entity must have a key attribute or, in the case of a
composite key, key attributes. Graphically denoted as a regular attribute with
an underlined name:

Appointment - unique entity instance identification: the value of this attribute

cannot be repeated. For example Car (VIN), Student (ZK)

12
Derived attribute
Derived attribute, which is designed to display the characteristics of the
entity, whose value depends on another attribute, for example, the "discounted
price" of the product is calculated taking into account the "base price" and
"discount". In other words -functional attribute.

It should be noted that storing derived attributes in databases is impractical in

most cases, as it saves redundant information. Graphically displayed as
follows:

13
Composite attribute
Composite attribute determines complex characteristics entity, which also
consists of a group of other attributes. An example of a composite attribute is
an address consisting of a city, a cheekbone, a house number and an
apartment number. Graphically denoted as follows:

14
Multivalued attribute
Multivalued attribute displays the characteristics they may have several
values ​at once for example, a person may have multiple email addresses or
phone numbers. This attribute is denoted as follows:

15
Relationship
Relationship between entities determines the degree of their relationship.

The most common type of relationship is binary that connects the two
entities. A relationship is denoted as a diamond that connects two entities
with lines and, like entities, can have its own attributes.

For example, the "sold" relationship between the Seller and Buyer entities
may have the "Date of Sale" and "Product Name" attributes. This is graphically
illustrated by the following figure:

16
Unary (recursive relationship)
Unary relationship occurs when an entity instance refers to another entity
instance - trees (Product category “Computer” - “Components” - “HDD” or
HTML-page <body><p><h1></h1></p> </body> or the student communicates
with the student.

17
Ternary relationship
Ternary relationship combines three entities. Example,User for everyone
application has its own unique profile (application specific data).

18
Four-array relationship ("star" scheme)
"Star" - one of the most common schemes:

19
Cardinality of relationships
The cardinality of relationships is an important quantitative characteristic of
the ratio of instances of entities. There are the following types of
relationships:

1:1 - to each other

1:N - one to many

N:M - many to many

It is necessary to minimize cardinality, but to consider specificity of a task:

For example, marriage of a man and a woman 1: 1 or M: N? Teacher class 1: 1,

1: N orM: N? Worker-Department?Hint: will the database accumulate data
20
over time? Is the database considered one-time? Parallel events? Consistent?
Graphic notation (1)
Graphically, the cardinality of the relationships is indicated by a special sign
near the end of the line:

21
Graphic notation (2)
In this case, in the case when the relationship is not required, the symbol "0"
is set, otherwise - "1". Such special signs must be placed on both sides of the
line as in the example (User->has->Profile):

This scheme should be read as follows: "each user of the site has one profile
and each profile on the site corresponds to exactly one user."

22
Graphic notation (3)
The following example illustrates the relationship one to many (Building-
>has->Classrooms):

The educational building must contain one or more classrooms, and one
classroom is located in one and only one building.

23
Graphic notation (3)
An example of the use of the relationship "many to many" (N: M) is illustrated
in the following figure (Sport team->participates->Competitions):

In the figure: one sports team participates in several competitions and several
teams participate in one competition.

24
Conversion of ER-diagrams into DB
scheme.
1. Strong and (1)
weak entities with attributes are transformed as are, including
attributes.
2. relationships:
- 1:1 (required)

* UserID in Profile:

Not null

and Unique

(only 1).
25
Conversion of ER-diagrams into DB
scheme. (2)
relationships:
- 1: 1 (both optional) Worker->has->Locker

26
Conversion of ER-diagrams into DB
scheme. (3)
relationships:
- 1:1 (both optional) Worker->has->Locker

27
Conversion of ER-diagrams into DB
scheme. (4)
relationships:
- 1: N (both required) Student->belongs to->Group

28
Conversion of ER-diagrams into DB
scheme. (5)
relationships:
- 1: N (optional) Student->belongs to->Group

29
Conversion of ER-diagrams into DB
scheme. (6)
relationships:
- 1: N (optional or both optional) Student->visits->Zoo

30
Conversion of ER-diagrams into DB
scheme.(7)
relationships:
- M:N (all types) Student->visits->Cinema

31
Conversion of ER-diagrams into DB
scheme.(8)
relationships:
- Unary

32
Conversion of ER-diagrams into DB
scheme.(9)
relationships:
- N-arnie User->has->Profile, Application

33