1

Discussion Focus

Efficient data management typically requires the use of computer database. A database is a

shared, integrated computer structure that stores a collection of:

End-user data – that is the raw facts of interest to the end user.

Metadata, or data about data, through which the end-user data are integrated and

managed.

Metadata describes the data characteristics and the set of relationships that links the data found

within the database. For example the metadata component stores information such as the name of

each data element, the type of values (numeric, dates, or text) stored to each data element, and

whether the data element can be left empty.

A database management system (DBMS) is a collection of programs that manage the database

structure and controls access to the data stored in the database. The DBMS serves as the

intermediary (mediator) between the user and the database. The database structure itself is stored

as a collection of files, and the only way to access the data in those files is through the DBMS.

Figure 1

Figure 1 emphasizes the point that the DBMS presents the end user (or application program) with

a single integrated view of the data in the database.

DBMS advantages:

Share data among multiple applications and users

Many different users’ views of data into a single all-compassing data repository

Improved data access

Minimized data inconsistency - The probability of data inconsistency is greatly reduced in

a properly designed database.

Database design focuses on how the database structure will be used to store and manage end-user

data. Data modeling is the first step in designing a database, refers to the process of creating a

specific data model for a determined problem domain. A data model is relatively simple

representation, usually graphical, of more complex real-world data structures. Data modeling is

iterative, progressive process.

2

Data Model Basic Building Blocks

The basic building blocks of all data models are entities, attributes, relationships, and constraints.

An entity is a person, place, or event about which data will be collected and stored.

An attribute is a characteristic of an entity. For example, a STUDENT entity would be described

by attributes such as student first name, student last name, faculty number, student address.

A relationship describes an association among entities. For example, relation exists between

teachers and classes that can be described as follows: a teacher can teach many classes, but a class

can be taught by only one teacher. Data models use three types of relationships: one-to-one, one-

to-many, and many-to-many. Usually the shortened notations are used: 1:1 or 1..1, 1:M or 1..*,

M:N or *..* (may be seen as M:M or M..M) respectively. The following examples illustrate the

distinctions among them:

One-to-one (1:1 or 1..1) relationship. A professor chairs one department, and a

department can be chaired by only one professor. Therefore the relationship

“PROFESSOR chairs DEPARTAMENT” is labeled 1:1.

One-to-many (1:M or 1..*) relationship: A painter creates many different paintings, but

each painting is painted by only one painter. Thus the painter (the “one”) is related to the

paintings (the “many”). Therefore the relationship “PAINTER paints PAINTING” is

labeled 1:M. Similarly, a customer (the “one”) may generate many invoices, but each

invoice (the “many”) is generated by only a single customer. “The CUSTOMER generates

INVOICES” relationship would also be labeled one-to-many.

Many-to-many (M:N or *..*) relationship: An employee may learn many job skills, and

each job skill can may be learnt by many employees. The relationship “EMPLOYEE

learns SKILL” is labeled as M:M. Similarly a student can take many classes and each

class can be taken by many students. Again M:M relationship “STUDENT takes CLASS”

A constraint is a restriction placed on the data. For example:

An employee minimum salary must be 350lv

A student’s mark must be between 2 and 6.

Each class must have one and only one teacher

Business rules

A business rule is a brief, precise, and unambiguous description of a policy, procedure, or a

principle within a specific organization. For example, the business rule “a teacher can teach many

classes”. From this business rule you could decide that:

Teacher and class are objects of interest for the environment and should be represented by

their respective entities.

There is a ” teach” relationship between teacher and class

But this is not enough to identify the relationship properly. To do that you have to consider that

relationships are bidirectional, that is they go both ways. For example, the business rules “a

teacher can teach many classes” is complemented (completed) by the business rule “a class can be

taught by one and only one teacher”. In this case the relationship is one-to-many (1:M). Teacher is

the “1” side, and class is the “many” side.

Relational model

The characteristics of a relational table are as follows:

A table is perceived as a two – dimensional structure composed of intersecting rows and

columns.

3

Each table row (tuple) represents a single entity occurrence within the entity set.

Each table column represents an attribute (also called a field) and each column has a

distinct name.

Each intersection of row and column represents a single data value.

All values in a column must conform to the same data format.

Each column has a specific range of values known as the attribute domain.

The order of the rows and columns is immaterial to the DBMS.

Each table must have an attribute or a combination of attributes that uniquely identifies

each row - primary key (PK)

For example, the COURSE table in fig.2 might contain a professor’s id that is also contained in

PROFESSOR table. (Figure 2). The tables are linked through the common attribute PROF_ID.

Figure 2

A foreign key is the primary key of one table that has been placed into another to create a

common attribute.

The relationship type (1:1 , 1:M or M:M) is often shown in a relational schema, an example of

which is shown in Figure 3.

Figure 3

4

A relational diagram is a representation of relational database’s entities, the attributes within those

entities and the relationships between those entities.

The entity relationship model

The entity relationship (ER) model or ERM has become a widely accepted standard for data

modeling. ERM models are normally represented in an entity relationship diagram (ERD),

which uses graphical representations to model database components. A relational diagram is a

visual representation of the relational database’s entities, the attributes within those entities, and

the relationships between those entities. There are different notations for graphical depiction of

the main ER model components. We will use Crow’s Foot Notation.(Figure 4)

Figure 4

The ER model is based on the following components

(entities and relationships):

Entity - represented in the ERD by a rectangle. The

entity name is generally written in capital letters and

in singular form: PAINTER, STUEDENT, and

COURSE. When applying the ERD to the relational

model, an entity is mapped to a relational table.

(Figure 5).

Relationships. Relationships describe associations

among data. The name Crow’s foot is derived from

the three-pronged symbol used to represent the ”many” side of the relationship. The “1” side is

represented by short line segment. Figure 6

Figure 5

Entity Relationship

Diagram

Relational table

5

Figure 6

The M:N Relationship

A many-to-many relationship is not supported directly in the relational environment However,

M:N relationships can be implemented by creating a new entity in 1:M relationship with the

original entities. A typical example is the relationship between STUDENT and CLASS, because

each CLASS can have many students, and each STUDENT may take many CLASSes. The ERM

is shown in Figure 7.

Figure 7

Wrong implementation of M:N relationship is shown in Figure 8.

(1:M): a PROFESSOR may teach many COURSEs; a COURSE is taught by only one PROFESSOR

(M:M): а STUDENT can take many CLASSEs; a CLASS can be taken by many STUDENTs

(1:1): a PROFESSOR can chair only one DEPARTMENT; a DEPARTMENT is chaired by one PROFESSOR

6

Figure 8

To solve the problems inherited in the M:N relationships we create a composite entity (bridge

entity, associative entity) Because such a table is used to link the tables originally in M:N

relationship , the bridge entity includes - as foreign keys – at least the primary keys of the tables

that are to be linked. To define the primary key for the new table there are two options: use the

combination of those foreign keys or create a new one.

Back to STUDENT – CLASS example, a solution could be creating a composite ENROLL table

shown in Figure 9 to link the tables STUDENT and CLASS. Here the primary key is combination

of its foreign keys CLASS_ID and STUD_ID.

7

Figure 9

The revised relationship is shown in Figure 10

Figure 10

8

Problems:

1. Use Figure P1 as your guide. The DealCo relational diagram shows the initial entities and

attributes for the DealCo stores, located in two regions of the country.

Figure P1 The DealCo relational diagram

a. Identify each relationship type and write all of the business rules.

b. Create the basic Crow’s Foot ERD for DealCo.

2. Use Figure P2 as your guide. The Tiny College relational diagram shows the initial entities

and attributes for Tiny College.

Figure P2. The Tiny College Relational Diagram

a. Identify each relationship type and write all of the business rules. b. Create the basic Crow’s Foot ERD for Tiny College.

3. Create a Crow’s Foot ERD to include the following business rules for the ProdCo company:

a. Each sales representative writes many invoices.

b. Each invoice is written by one sales representative.

c. Each sales representative is assigned to one department.

d. Each department has many sales representatives.

e. Each customer can generate many invoices.

f. Each invoice is generated by one customer.

4. Write the business rules that are reflected in the ERD shown in Figure P3. (Note that the ERD

reflects some simplifying assumptions. For example, each book is written by only one author.

Also, remember that the ERD is always read from the “1” to the “M” side, regardless of the

orientation of the ERD components.)

9

Figure P3

5. Create a Crow’s Foot ERD for each of the following descriptions. (Note: The word many

merely mean “more than one” in the database modeling environment.)

a. Each of the MegaCo Corporation’s divisions is composed of many departments. Each of

those departments has many employees assigned to it, but each employee works for only

one department. Each department is managed by one employee, and each of those

managers can manage only one department at a time.

b. During some period of time, a customer can rent many videotapes from the BigVid store.

Each of the BigVid’s videotapes can be rented to many customers during that period of

time.

c. An airliner can be assigned to fly many flights, but each flight is flown by only one

airliner.

6. Suppose you have the ERM shown in Figure P4

How would you convert this model into an ERM that displays only 1:M relationships. Draw the

revise diagram.

7. Use the database shown in Figure P5 to answer the following questions:

a. Identify the primary keys.

b. Identify the foreign keys

10

Figure P5

c. Create the ERM

CASE:

TinyVideo is a small movie rental company with a single store. TinyVideo needs a database

system to track the rental of movies to its members. TinyVideo can own several copies (VIDEO)

of each movie (MOVIE). For example, the store may have 10 copies of the movie ―Twist in the

Wind‖. ―Twist in the Wind‖ would be one MOVIE and each copy would be a VIDEO. A rental

transaction (RENTAL) involves one or more videos being rented to a member (MEMBERSHIP).

A video can be rented many times over its lifetime, therefore, there is a M:N relationship between

RENTAL and VIDEO.

Create the ERM .