0% found this document useful (0 votes)
77 views6 pages

07 Handout 1 PDF

The document summarizes the differences between the flat-file and database approaches to data management. Some key issues with the flat-file approach include data redundancy, difficulty updating and maintaining consistent data across files, and constraints on users' access to related data from other files. A database centralizes data to resolve these issues by allowing single updates, reducing redundancy, and making all data accessible to users. The elements of a database environment include users, the database management system, database administrators, and the physical database. Relational databases store data in tables with rows and columns to make it easy to locate and access values and run queries across multiple tables. Designing relational databases uses a top-down approach starting with entity-relationship models and

Uploaded by

Rhea Mae Abenia
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
77 views6 pages

07 Handout 1 PDF

The document summarizes the differences between the flat-file and database approaches to data management. Some key issues with the flat-file approach include data redundancy, difficulty updating and maintaining consistent data across files, and constraints on users' access to related data from other files. A database centralizes data to resolve these issues by allowing single updates, reducing redundancy, and making all data accessible to users. The elements of a database environment include users, the database management system, database administrators, and the physical database. Relational databases store data in tables with rows and columns to make it easy to locate and access values and run queries across multiple tables. Designing relational databases uses a top-down approach starting with entity-relationship models and

Uploaded by

Rhea Mae Abenia
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

BM2013

Database Management Systems


Flat-File vs. Database Approach
Flat-File Approach
The flat file approach is most often associated with so-called legacy systems. The flat-file model describes an
environment in which individual data files are unrelated to other data. End users in this environment own
their data files rather than share them with other users.
Under this approach, data processing is by standalone applications rather than integrated systems. When
multiple users need the same data for different purposes, they must obtain separate data sets structured to
their specific needs.

Figure 1. Flat-File Data Management

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.

07 Handout 1 *Property of STI


[email protected] Page 1 of 6
BM2013

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.

Elements of the Database Environment


Database Management System (DBMS) is a system software for creating and managing databases. It provides
users and programmers with a systematic way to create, retrieve, update, and manage data. It mainly serves
as an interface between the database and end-users or application programs, ensuring that data is
consistently organized and remains easily accessible.
The database environment is composed of four (4) primary elements (Hall, 2016):
• Users – They are the first element of a database environment. These are the people who know the
application and its interfaces. According to Hall (2016), users access the database in two (2) ways. The first
is via user application programs that systems professionals prepare. These programs send data access
requests (calls) to the DBMS, which validates the requests and retrieves the data for processing. The
second method of database access is via direct query. The DBMS has a built-in query facility that allows
authorized users to process data independent of professional programmers. The query facility provides a
friendly environment for integrating and retrieving data to produce individual reports.
• Database Management System – It is considered the second element of a database environment. This
provides a controlled environment to assist (or prevent) user access to the database and to manage the
data resource efficiently.
• Database Administrator (DBA) – This third element is responsible for the installation, configuration,
upgrade, administration, monitoring, and maintenance of databases in an organization. The DBA’s roles

07 Handout 1 *Property of STI


[email protected] Page 2 of 6
BM2013

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 Relational Database Model


A relational database management system (RDBMS) refers to a database that stores data in a structured
format using rows and columns. This makes it easy to locate and access specific values within the database. It
is “relational” because the values within each table are related to each other. The relational structure makes
it possible to run queries across multiple tables at once.
(For the basic terminologies used in relational model, refer to 01 Laboratory Exercise 1 in your Intermediate
Accounting 2 course.)
Top-Down Approach to Designing Relational Databases
This approach commences with the development of data models that contain a high level of abstraction. Then
the successive top-down refinement is applied to identify lower-level entities, relationships, and associated
attributes. The entity-relationship model is an example of top-down approach and is more suitable for design
of complex databases (Pahi, n.d.).

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.

07 Handout 1 *Property of STI


[email protected] Page 3 of 6
BM2013

Figure 6. Not Normalized Customer Data


Source: https://www.datanamic.com/support/database-normalization.html

• 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).

Figure 7. Example of Data in First Normal Form


Source: https://www.datanamic.com/support/database-normalization.html

• 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.

Figure 8. Example of Data in Second Normal Form

07 Handout 1 *Property of STI


[email protected] Page 4 of 6
BM2013

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

In Figure 9, attribute AccountManagerRoom is transitive dependent on attribute AccountManager. A


new entity, AccountManager, must be created so that attribute AccountManagerRoom can be
removed from the Customer entity. The Customer entity is now in the third normal form (3NF).

Figure 9. Example of Data in Third Normal Form


Source: https://www.datanamic.com/support/database-normalization.html

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.

07 Handout 1 *Property of STI


[email protected] Page 5 of 6
BM2013

Databases in a Distributed Environment


Distributed databases can be classified into homogeneous and heterogeneous databases having further
divisions (Tutorialspoint, 2019).
Homogeneous Distributed Databases
In a homogeneous distributed database, all the sites use identical DBMS and operating systems. Its properties
are as follows (Tutorialspoint, 2019):
• The sites use very similar software.
• The sites use identical DBMS or DBMS from the same vendor.
• Each site is aware of all other sites and cooperates with other sites to process user requests.
• The database is accessed through a single interface as if it is a single database.
Types of Homogeneous Distributed Database
There are two (2) types of homogeneous distributed database (Tutorialspoint, 2019):
• Autonomous – Each database is independent and functions on its own. It is integrated by a controlling
application and uses message passing to share data updates.
• Non-autonomous – Data is distributed across the homogeneous nodes, and a central or master DBMS
coordinates data updates across the sites.
Heterogeneous Distributed Databases
In a heterogeneous distributed database, different sites have different operating systems, DBMS products,
and data models. Its properties are as follows (Tutorialspoint, 2019):
• Different sites use dissimilar schemas and software.
• The system may be composed of a variety of DBMSs, such as relational, network, hierarchical, or
object-oriented.
• Query processing is complex due to dissimilar schemas.
• Transaction processing is complex due to dissimilar software.
• A site may not be aware of other sites, and so there is limited co-operation in processing user requests.
Types of Heterogeneous Distributed Databases
There are two (2) types of heterogeneous distributed databases (Tutorialspoint, 2019):
• Federated – Heterogeneous database systems are independent and integrated so that they function
as a single database system.
• Un-federated – Database systems employ a central coordinating module through which the databases
are accessed.

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

07 Handout 1 *Property of STI


[email protected] Page 6 of 6

You might also like