TG1 E4 R - Ontolan Data Models

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 7

Name: Rodney B. Ontolan Jr.

___________________________________
Classcode: CS211N________________ Class Description: Information Management
Time: 11:00 PM__________________ Date: Feb 12 2024___________________

Laboratory No. 4 Data Models and Business Rules

Objectives:
1. To determine the different data models
2. To determine how business rules are applied in a data analysis
3. To determine the basic building blocks of a data model

Background

A data model is a relatively simple representation of data structures. It is usually


represented by a graph. Its logic is based on concepts, white its implementation is called the
“database management system”. The process of modeling the data is an iterative, progressive
process. As the understanding of the problem domain increases, so does the level of the details of
the data model

Building Blocks of a Data Model

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

1. Entity – is a collection of objects that are distinguishable from other objects by a set of
attributes, e.g., customer, account, student, etc.
2. Attribute– is the characteristics or properties of an entity, e.g., city, balance, surname
3. Relationship– is an association among entities. It could be a one-to-one, one-to-many, or
many-to-many relationship
4. Constraints– is the restriction placed on the data, e.g., Voter’s age must be greater than
seventeen-year-old.

Different Data Models

1. Hierarchical Model
The entities and relationships between entities in this model are managed with the
help of a tree-like structure. The tree has a root and a related child.

Example:
The entities shown in Figure 3.1 are related with the following relationships:
 Each Zone contains many Regions (1 Zone – many Regions)
 Each Region contains many Areas (1 Region – many Areas)
 Each Area contains many Salesman (1 Area – many Salesman)
 Each Salesman sells many Items, and each Item is sold by many Salesman (1
Salesman – many Items and many Items – 1 Item)

Figure 3.1 Hierarchical Model


2. Network Model
The network model represents data using the link between records. The parent
record is called the Owner Record and the child record is called Member Record. This
model allows the child record to have multiple parents.

Figure 3.2 Network Model


3. Relational Model
The relational model was introduced in 1970 by E.F. Codd. In this model, data are
represented in a tabular form which is called, relation (table), and they are associated with
relationships. Each entity occurrence is known as a tuple (a record) and the characteristic
of an entity is called an attribute.
Figure 3.3 Relational Model
4. Entity-Relationship Model
This data model was developed to facilitate database design by allowing the
specification of an enterprise schema that represents the overall logical structure of the
database. It contains the entities, the relationship between entities, and the attributes.

Figure 3.4.a Entity-Relationship Model


Figure 3.4.b shows the different relationship types in Chen and Crow’s Foot
notations.
Figure 3.4.b Relationship Type
5. Object-Oriented Model.
A class represents the object-oriented data model. It has data and methods which
represent the attributes and behavior of the object.

Figure 3.5 Object Oriented Data Model


Laboratory Activity:

Open your Microsoft Visio application and do the following problems. Save your file in
jpeg format and upload it to your eLearning account or computer laboratory account. Rename it
as E3_yourlastname_modeltype.jpg.
1. Consider the entities given below and draw their relational, object-oriented, and entity
relationship models.
2. Identify and explain the relationships between entities.
Batch table has a one-to-many relationship with Class table. The (batch) on the class
table, which serves as the main key for the Batch, is also used as a foreign key in the
Class table. This relationship exists because a batch represents a specific time period
when particular classes were conducted at a school. Class has another one-to-many
relationship with Student. The (class_id), which is the main key for Class, along with the
batch (foreign key from Batch), serves as the foreign key in the Student table. Lastly,
there is a one-to-many relationship involving Faculty, Class and Subject within the Teach
table. Teach holds information about faculty members and their assigned subjects and
class. Given a faculty member’s assignment, various combinations of subject can occur.
3. Does the database design avoid any data anomalies? Explain.
The database design minimizes the chances of data anomalies by using multiple tables for
each entity that store specific data. These tables have one-to-many relationships with
each other. This is a good practice to keep data in separate tables to prevent data
anomalies. For example, to avoid deletion anomaly, some data from the deleted records
in the main table will remain in their own tables. To avoid update anomaly, you only
need to update the data from the other tables once, instead of multiple times in the main
table. To avoid insertion anomaly, you can insert a new record that is not complete yet,
and fill in the missing data in the other tables later.

4. Write the business rules between entities.


A batch consists of several classes, and each class belongs to only one batch. Each class
is attended by many students, and each student is enrolled in only one class. Faculty can
teach multiple times according to the teach plan. Only one faculty can be assigned to a
single teach plan. A subject can have multiple records in teach plan, but each teach plan
can only have one subject. A class is subjected to many teach. One teach plan is to be
signed to one class.

Reference:
[1] S. Naik, Concepts of Database Management System, New Delhi, India: Pearson, 2014.
[2] P. Rob and C. Coronel, Database Systems: Design, Implementation, and Management,
Eight Edition, 8th Edition ed., Course Technology, 2009.
[3] R. Elmasri and S. B. Navathe, Fundamentals of Database Systems, 7th Edition, Pearson
Higher Education, 2016.
[4] G. Powell, Beginning Database Design, Indiana: Wiley Publishing, Inc., 2006.

You might also like