1.

2.

3. Limitations of flat file

For all the advantages of a flat file. There are some limitations that a relational database is able to overcome.
Consider flat file database example below
ID

Title

First name

Surname

Address

City

Postcode

Telephone

Mr

Tom

Smith

42 Mill Street

London

WE13GW

010344044

Mrs

Sandra

Jones

10 Low Lane

Hull

HU237HJ

022344033

Mr

John

Jones

10 Low Lane

Hull

HU237HJ

022344033

Issues
1. Potential duplication. With perhaps thousands of records in a file, it can be a very tedious process to spot
duplicated records. Especially if more than one person is maintaining the table.
2. Non-unique records. Notice that Mr & Mrs Jones have identical ID's '2'. There is nothing in a flat file system to
stop this. But it is a very poor idea to have identical ID's in a database.
3. Harder to update. Suppose this table now needs to also store their work details - this will result in multiple records
for each person. Again, this is fine - but suppose Sandra Jones now wanted to be known as 'Sandra Thompson'?
Now multiple records need to be updated.
4. Inherently inefficient. What if an email field needs to be added?. If there are tens of thousands of records, there
may be many people having no email address, but every record in a flat file database has to have the same fields,
whether they are used or not.
5. Harder to change data format. Suppose the telephone numbers now have to have a dash between the area code
and the rest of the number, like this 0223-44033. Adding that extra dash over tens of thousands of records would be a
significant task in a flat file database.
6. Poor at complex queries. Flat files are excellent for simple filtering. For example, show all records where the field
'City' contains Hull. But for anything a bit more complicated, a flat file becomes very difficult to use. For example, find
all records whose post code contains '23'.
7. Almost no security. You can protect a flat file database using a password for opening it. But once it is open, that
person can usually see all fields. This is often not a good thing, for example there may be a confidential field
containing their salary that only some people should be able to see.

Disadvantages
Less security easy to extract information.
Data Inconsistency
Redundancy
Sharing of information is cumbersome task
Slow for huge database
Searching process is time consuming
3.
1.

Databases can handle querying tasks, so you don't have to walk over files manually. Databases can
handle very complicated queries.

2.

Databases can handle indexing tasks, so if tasks like get record with id = x can be VERY fast

3.

Databases can handle multiprocess/multithreaded access.

4.

Databases can handle access from network

5.

Databases can watch for data integrity

6.

Databases can update data easily (see 1) )

7.

Databases are reliable

8.

Databases can handle transactions and concurrent access

9.

Databases + ORMs let you manipulate data in very programmer friendly way.

A database is generally used for storing related, structured data, with well defined data formats, in an efficient
manner for insert, update and/or retrieval (depending on application).
On the other hand, a file system is a more unstructured data store for storing arbitrary, probably unrelated
data. The file system is more general, and databases are built on top of the general data storage services
provided by file systems.
There are also differences in the expected level of service provided by file systems and databases. While
databases must be self consistent at any instant in time (think about banks tracking money!), provide isolated
transactions and durable writes, a file system provides much looser guarantees about consistency, isolation and
durability. The database uses sophisticated algorithms and protocols to implement reliable storage on top of
potentially unreliable file systems. It is these algorithms that make database storage more expensive in terms of
processing and storage costs that make general file systems an attractive option for data that does not require
the extra guarantees provided by a database.
As technology moves forward, though, the lines are blurring, as some file systems pick up features previously
the domain of databases (transactions, advanced queries) and some databases relax the traditional constraints
of consistency, isolation and durability. ZFS and BTRFS might be considered examples of the former, MongoDB
and CouchDB examples of the latter.

A very simple computer system may be able to be supported by a very simple database design that only includes a
single table. However, if the database design needs to be enhanced to support more complex requirements, the single
table design would almost always end up being normalized into multiple tabled linked together through relationships.
This is required to reduce data redundancy and to improve efficiency.
There are 3 types of table relationships:
1. One-to-one relationships
2. One-to-many relationships
3. Many-to-many relationships

One-to-One Relationships
In a one-to-one relationship, each row in one database table is linked to one and only one other row in another table.
In a one-to-one relationship between Table A and Table B, each row in Table A is linked to another row in Table B.
The number of rows in Table A must equal the number of rows in Table B.
It would be apparent that one-to-one relationships are not very useful since the database designer might as well
simply merge both tables into a single table. This is true in general. However, there are some situations in which the
one-to-one relationship may improve performance. For example, if a database table contains a few columns of data
that is frequently used and the remaining columns being infrequently used, the database designer may split the single
table into 2 tables linked through a one-to-one relationship. Such a design would reduce the overhead needed to
retrieve the infrequently used columns whenever query is performed on the contents of the database table.

One-to-Many Relationships
In a one-to-many relationship, each row in the related to table can be related to many rows in the relating table. This
effectively save storage as the related record does not need to be stored multiple times in the relating table.
For example, all the customers belonging to a business is stored in a customer table while all the customer invoices
are stored in an invoice table. Each customer can have many invoices but each invoice can only be generated for a
single customer.

Many-to-Many Relationships

In a many-to-many relationship, one or more rows in a table can be related to 0, 1 or many rows in another table. A
mapping table is required in order to implement such a relationship.
For example, all the customers belonging to a bank is stored in a customer table while all the bank's products are
stored in a product table. Each customer can have many products and each product can be assigned to many
customers.

A relationship works by matching data in key columns usually columns with the same name in both tables. In
most cases, the relationship matches the primary key from one table, which provides a unique identifier for each
row, with an entry in the foreign key in the other table. For example, book sales can be associated with the specific
titles sold by creating a relationship between the title_id column in the titles table (the primary key) and
the title_id column in the sales table (the foreign key).
There are three types of relationships between tables. The type of relationship that is created depends on how the
related columns are defined.

One-to-Many Relationship

Many-to-Many Relationships

One-to-One Relationships

One-to-Many Relationships
A one-to-many relationship is the most common type of relationship. In this type of relationship, a row in table A
can have many matching rows in table B, but a row in table B can have only one matching row in table A. For
example, the publishers and titles tables have a one-to-many relationship: each publisher produces many titles, but
each title comes from only one publisher.
Make a one-to-many relationship if only one of the related columns is a primary key or has a unique constraint.
The primary key side of a one-to-many relationship is denoted by a key symbol. The foreign key side of a
relationship is denoted by an infinity symbol.

Many-to-Many Relationships
In a many-to-many relationship, a row in table A can have many matching rows in table B, and vice versa. You
create such a relationship by defining a third table, called a junction table, whose primary key consists of the
foreign keys from both table A and table B. For example, the authors table and the titles table have a many-to-many
relationship that is defined by a one-to-many relationship from each of these tables to the titleauthors table. The
primary key of the titleauthors table is the combination of the au_id column (the authors table's primary key) and
the title_id column (the titles table's primary key).

One-to-One Relationships
In a one-to-one relationship, a row in table A can have no more than one matching row in table B, and vice versa. A
one-to-one relationship is created if both of the related columns are primary keys or have unique constraints.
This type of relationship is not common because most information related in this way would be all in one table. You
might use a one-to-one relationship to:

Divide a table with many columns.

Isolate part of a table for security reasons.

Store data that is short-lived and could be easily deleted by simply deleting the table.

Store information that applies only to a subset of the main table.

The primary key side of a one-to-one relationship is denoted by a key symbol. The foreign key side is also denoted
by a key symbol.

19Distinguish between a database lockout and a deadlock.ANS:To achieve data

currency, simultaneous access to individual data elements or records by multiple
usersneeds to be prevented. The solution to this problem is a database lockout,
which is a software controlthat prevents multiple simultaneous accesses to data. A
deadlock occurs when multiple users seekingaccess to the same set of records
lockout each other. As a result, the transactions of all users assume await state until
the locks are removed. A deadlock is a permanent condition that must be resolved
byspecial software that analyzes each deadlock condition to determine the best
solution.

20Replicated databases create considerable data redundancy, which is in conflict

with thedatabase concept. Explain the justification of this approach.ANS:The
primary justification for a replicated database is to support read-only queries in
situationsinvolving a high degree of data sharing, but no primary user exists. With
data replicated at every site,data access for query purposes is ensured, and
lockouts and delays due to network traffic areminimized. A potential problem arises,
however, when replicated databases need to be updated bytransactions. Since each
site processes only local transactions, the common data attributes that
arereplicated at each site will be updated by different transactions and thus, at any
point in time, will haveuniquely different values. System designers need to employ

currency control techniques to ensure thattransactions processed at different

locations are accurately reflected in all the databases copies
17Give three examples that illustrate how cardinality reflects an organizations
underlying business rules.ANS:1)When an organization decides to purchases the
same items of inventory from different suppliers,the cardinality between the
Supplier and Inventory tables is M:M.2)When a the company purchases all items of
a certain type from only one supplier, the cardinalitybetween Supplier and Inventory
tables is 1:M respectively.3)A policy that a separate receiving report is prepared for
the receipt of goods specified on a singlepurchase order will result in a 1:1
cardinality between the receiving report and purchase ordertables. If, however,
multiple purchase orders are combined on a single receiving report then
thecardinality between these tables will be 1: M respectively.
16Discuss the accounting implications of the update, insertion, and deletion
anomalies associated with improperly normalised tables.
The insertion and update anomalies would create record keeping and operational
problems for the firm. However, flawed databases design that prevents the insertion
of records, or requires the user to perform excessive updates, would attract
attention quickly. The presence of the deletion anomaly is less conspicuous, but
potentially more serious from an accounting perspective. Because the deletion
anomaly may go undetected, the user may be unaware of the loss of important data
until it is too late. This anomaly can result in the unintentional loss of critical
accounting records and the destruction of the audit trail.
12DISCUSSION QUESTION
How does a database lockout contribute to financial data integrity?
A database lockout prevents multiple users from accessing the same table
simultaneously and making changes to data values while they are temporarily
inconsistent. Lockouts force changes to be made sequentially to ensure data
accuracy
13DISCUSSION QUESTION
How does concurrency control contribute to financial data integrity?
Database concurrency controls ensure the completeness and accuracy of a
distributed database at remote sites where the same beginning data balances are
updated by different transactions. This is accomplished by serializing and timestamping transactions. Depending on the need for data currency, the time-stamped
data will be reconciled and posted to all distributed databases.
14.Explain how to link tables in (1:1) association. Why may this be different in a
(1:0,1) association?ANS:Where a true 1:1 association exists between tables, either
(or both) primary keys may be embedded asforeign keys in the related table. On the

other hand, when the lower cardinality value is zero (1:0,1) amore efficient table
structure can be achieved by placing the one-side (1:) tables primary key in
thezero-or-one (:0,1) table as a foreign key. Assume that a company has 1000
employees but only 100 ofthem are sales staff. Assume also that each sales person
is assigned a company car. Therefore, everyoccurrence in the Employee entity is
associated with either zero or one occurrence in the Company Carentity. If we
assigned the Company Car (:0,1) side primary to the Employee (:1) table as a
foreign keythen most of the foreign will have null (blank) values. While this
approach would work, it could causesome technical problems during table searches.
Correctly applying the key-assignment rule solves thisproblem because all Company
Car records will have an employee assigned and no null values will oc-cur