07 Handout 1 PDF
07 Handout 1 PDF
In Figure 1, the file contents are represented conceptually with letters. Each letter could signify a single data
attribute (field), a record, or an entire file. Note also that data element B is present in all user files. This event
is called data redundancy and will cause three (3) types of data management problems: data storage, data
updating, and currency of information. These problems, as well as the fourth problem called task-data
dependency (although not directly related to data redundancy), are elaborately discussed as follows (Hall,
2016):
• Data Storage – Compared to the use of the database, efficient storage of data is not possible in the flat-
file environment. In this type of situation, the organization incurs costs of both multiple collections and
multiple storage procedures. Some commonly used data may be duplicated dozens, hundreds, or even
thousands of times, creating high storage costs.
• Data Updating – In the flat file environment, organizations have a great deal of data stored in master files
and reference files that require periodic updating to reflect operational and economic changes. Any
changes in the records of one (1) department will not be automatically visible in other departments. For
example, a change in a customer’s name or address in the sales department also requires an update in
other customer file users such as the billing department, credit department, and customer care.
• Currency of Information – In contrast to the problem of performing multiple updates is the problem of
failing to update the file of all users affected by a change. If updates are not properly disseminated, some
users may not record the move. They will only perform their duties and make decisions based on outdated
data.
• Task-Data Dependency – Another problem with flat-file management is the user’s inability to obtain
additional information as his/her needs change. The user’s information set is constrained by the data that
s/he possesses and controls.
For example, in Figure 1, if the information needs of User 1 change to include Data N, User 1’s program
will not have access to these data. Although Data N exists in the files of another user, keep in mind the
culture of this environment. Users do not interact as members of a user community; instead, they act
independently. As such, User 1 may be unaware of the presence of Data N elsewhere in the organization.
Because of the difficulty in establishing a mechanism for the formal sharing of data, Data N would need
to be re-created from scratch. This will take time, hinder User 1’s performance, add to data redundancy,
and drive data management costs even higher.
Database Approach
In contrast to the flat-file approach, the database approach pools data into a shared database that is shared
by all the users. Data sharing is the central concept of this approach.
The following shows how the database resolves the problems identified in the flat-file environment (Hall,
2016):
• No data redundancy – Each data element is stored only once, thereby eliminating data redundancy and
reducing storage costs.
• Single update – Because each data element exists only in one (1) place, it requires a single update
procedure. This reduces the time and cost of keeping the database current.
• Current values – A change any user makes to the database yields current data values for all other users.
For example, when User 1 records a customer address change, User 3 has immediate access to this current
information.
• Task data independence – Users have access to the full domain of data available to the firm. As users’
information needs to expand beyond their immediate domain, the new needs can be more easily satisfied,
unlike the flat-file approach. Only the limitations of data available to the firm (entire database), and the
legitimacy of their need to access it, constrain users.
include developing and designing database strategies, monitoring and improving database performance
and capacity, and planning for future expansion requirements. S/He may also plan, coordinate, and
implement security measures to safeguard the database.
• Physical Database – This fourth element of database environment is considered the lowest level of the
database, which serves as a collection of records and files. It translates the logical data model into a set
of standard query language (SQL) statements that define the database.
Some of the rules for translating the logical data model into a physical database are as follows
(eWebArchitecture, Ltd., n.d.):
o Entities become tables,
o Attributes become columns, and
o The relationship is modeled as foreign key.
The following are the steps involved in creating a relational database using a top-down approach (Hall, 2016):
1. Identify the views to be modeled – This includes user interviews and other techniques to determine what
users do and what information they need to support their tasks—for instance, interviewing the
accountant on what specific features they want to see in an accounting database.
2. Normalize data model and add primary keys – According to Datanamic Solutions (n.d.), normalization is a
formal approach that applies a set of rules to associate attributes with entities. It is mainly used to
eliminate redundant data and ensure that all data is logically stored.
Datanamic Solutions (n.d.) discussed that the normalization of data model comprises several steps. These
steps are called normalization rules. Each rule is referred to as a normal form (1NF, 2NF, 3NF). The first
three (3) forms are the most important ones. Each normal form constrains the data more than the
previous normal form. This means that the achievement of the first normal form (1NF) is a prerequisite
for the second normal form (2NF).
The following are the forms in database normalization, including their examples (Datanamic Solutions,
n.d.):
• 0NF (Not Normalized) – The data is not normalized if it contains repeating attributes (see Figure 6). Its
repeating attributes here are ContactName1 and ContactName2.
• 1NF (No Repeating Groups) – In this form, an entity contains no repeating groups and all attributes
must have a unique name. Entities may only consist of two (2) dimensions. A customer has multiple
contacts (contact1, contact2, etc.).
It is a must to create a new entity for the contacts. A data model containing attributes with names like
contact1, contact2, etc. is bad database design. Repeating attributes makes the Data Ness flexible and
difficult to search. Refer to Figure 7 for an example of an entity in its first normal form (1NF).
• 2NF (Eliminate Redundant Data) – An entity is in the second normal form (2NF) if it has achieved the
first normal form (1NF) and if all of its attributes depend on the complete primary key. An entity with
a primary key consisting of only one (1) attribute is in the second normal form.
In Figure 8, the key is CustID + ContactID. If the ContactID attribute has been removed, the Customer
entity will depend on the new primary key, CustID. A new entity CustomerContact is created for the
relationship between Customer and Contact.
Source: https://www.datanamic.com/support/database-normalization.html
• 3NF (Eliminate Transitive Data Dependency) – An entity is in the third normal form (3NF) if it is in the
second normal form and all of its attributes are not transitively dependent on the complete primary
key. A transitive dependency exists when a non-prime attribute depends on other non-prime
attributes rather than depending upon the prime attributes or primary key. In other words, the third
normal form means that no attribute within an entity is dependent on a non-prime attribute that, in
turn, depends on the primary key
3. Construct the physical database – This involves creating the physical tables and populating them with
data. This is an involved step that must be carefully planned and executed.
4. Prepare the user views – The normalized tables should be rich enough to support the views of all users of
the system being modeled. The query function of a relational DBMS allows the system designer to create
user views from tables easily.
References
Datanamic Solutions. (n.d.). Database Normalization. Retrieved on July 24, 2019, from
https://www.datanamic.com/support/database-normalization.html
eWebArchitecture, Ltd. (n.d.). Physical Database Design. Retrieved on July 24, 2019, from
http://ewebarchitecture.com/web-databases/physical-database-design
Hall, J. A. (2016). Accounting information system (9th Ed.). Taguig City: Cengage Learning Asia Pte Ltd.
Pahi, N. (n.d.). Concepts of database design [Web log post]. Retrieved on July 24, 2019, from
https://blog.oureducation.in/database-design/
Tutorialspoint. (2019). Distributed DBMS - database environment. Retrieved on July 25, 2019, from
https://www.tutorialspoint.com/distributed_dbms/distributed_dbms_database_environments