Download Lab 1 File - Personal page

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.
1
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, oneto-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.
2







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
3
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
Entity Relationship
Diagram
Relational table
Figure 5
4
(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
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.
5
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.
6
Figure 9
The revised relationship is shown in Figure 10
Figure 10
7
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.)
8
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
9
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 .
10