B.

INTRODUCTION TO DATABASE

B.1. Historical Roots of Database: Files and File Systems

Manual file system: traditionally composed of a collection of file folders, each properly
tagged and kept in a filing cabinet.

As long as data collection was small, the manual system served its role as a data
repository.

However, as organizations grew, keeping track of data in a manual file system became
more difficult.
Finding data - time consuming
Report generation – slow

Key Terminologies
• Data - raw facts (Ex. Letter A, number 5, or some symbol)
• Field - characteristic of entity; column
• Record - set of logically related fields; row
• File - set of logically related records; table
• Database - set of logically related files

B.2. File System Data Management

As the number of files in the system expands, system administration becomes more
difficult. Each file must have its own file management system, composed of programs
that allow the user to:
● Create the file structure

● Add data to the file

● Delete data from the file

● Modify the data in the file

● List the file contents

Modifications are likely to produce errors (bugs), and additional time can be spent
finding the errors in a debugging process.

B.3. Structural and Data Dependence

• Structural dependence
- a change in any file’s structure (ex. addition or deletion of a field) requires
modification of all programs using that file
• Data dependence
- A change in any file’s data characteristics (ex. changing the data characteristic
from integer to decimal) requires changes in all programs that access the file
B.4. Field Definitions and Naming Conventions

Field Definition
Data structures are meant to last much longer than application code. Anyone that has
worked on a long running system can attest to that.

Well defined data structures and table layouts will outlive any application code.

It's not uncommon to see an application completely rewritten without any changes done
to its database schema.

A good (flexible) record definition anticipates reporting requirements by breaking up

fields into their components.

Example:
Student Name: Last Name, First Name, Middle Name
Student Address: Street, Municipality, Province

Selecting proper field names is very important

Make sure that the field names are reasonably descriptive.

By simply looking at the field names, we are able to determine to which files the fields
belong to and what information the fields contain

Example:
Stud_Lastname than Lastname
Length of the field name – short but specific

Add a field for primary key (unique key that holds a certain record)

Naming Convention
Database models require that objects be named. While several facets of naming an
object deserve consideration, in this article we’ll focus on the most important one:
defining a convention and sticking to it.

Planning a Naming Convention: Table Elements

Naming all the obvious database elements such as:
● Tables

● Views
● Columns
● Keys – including the primary key, alternate keys, and foreign keys
 ● Schemas

But don’t leave out the less-visible items:

● Tablespaces

● Constraints
● References
● Indexes
● Stored procedures
● Triggers
● Sequences
● Variables

Consider all the decisions that are involved.

● The case of the name. You can choose between:
o UPPERCASE names
o lowercase names
o camelCase names – the name starts with a lowercase letter, but new
words start with an uppercase letter
o PascalCaseNames (also known as upper camel) – similar to camelCase,
but the name starts with an uppercase letter, as do all additional words

● How to separate words in names:

o you can separate them by case (starting each new word with an
uppercase letter)
o you can separate them with an underscore (like_this)
o you can separate them with spaces, though that is very uncommon

● Whether to use singular or plural names

Database Naming Conventions Best Practices

1. Consistency is always the best policy.
One of the most popular pieces of advice is to equip columns with unique names in a
database. The thought process seems good on paper: the unique name gives you a
natural reference point so that you can find any specific column at any specific time.
The only problem is that unique names eventually become difficult to find. A good
practice is to just name columns that are based on their function. If your column is for a
description, then just called it “Description.”
2. Every table should have its own row identifier.
If tables are joined against multiple columns for a single entity, then trying to enforce
any database constraints becomes a migraine in the waiting if the parent row has a
compound key. Many databases don’t even support foreign key constraints, making
them virtually impossible for data access from an end user standpoint. If you give each
table its own row identifier, you’ll be able to clean up the programming while making the
naming conventions a whole lot easier to understand.

3. Plural or singular names don’t really matter.

This all comes down to personal preferences and how people think. Some people need
to have plurality for the name to make sense. Others see having plural names as the
waste of a character. What matters more is that whatever process you use for naming, it
needs to remain the same and be readable in the format that you choose. Some people
like to put multiple word names into one word with capital letters separating the word.
Others prefer to use dots, while still others like to use an underscore to make the entire
process easy to read and understand.

4. Prefix names make sense when you include them as an indication of the object
type involved.
If you have multiple modules that all have similar tables that must be organized, then
allowing for a table prefix to distinguish between the different subjects will help
everything make a lot more sense. It’s important, however, to make sure that if you use
abbreviations for these different modules that the abbreviations make sense. If you’re
abbreviating a security module, using “ITY” might make sense to you since its the last
three letters of the word, but the average person is going to look at that like you’re
writing in a foreign language.

5. Never allow the database to put in the constraint names automatically.

If you allow the automatic constraint names, then you’ll find that they add a random
number at the end of it. This especially a problem if you have a production database
that is outside of your office. You’ll wind up with two databases that have two different
constraint names and merging them together into a cohesive unit is virtually impossible.
You don’t really want numbers in your name in the first place, so don’t get into the lazy
habit of not typing in a name. You’ll pay for it later on – guaranteed.

6. Use plain old English whenever possible.

Having a number of abbreviations might make sense to you, but HAZENPLB isn’t going
to make a lot of sense to other administrators who come across your work. People
shouldn’t feel like they need to have a decryption ring with them to decipher what you
meant. The reason for these names is because there used to be an 8 letter requirement
in naming. That is long gone, so if you need to have a field that involves customer zip
codes, you can literally name it CustomerZipCode.
7. Spaces are just bad news.
Anything is better than a space in an object name. Some platforms allow spaces to be
included in a name, but they can cause a massive programming headache later on
down the road – especially when it comes time to migrate data.

8. Follow the rule of pillar data.

Field names that are date specific will quickly become outdated and useless. Instead of
assigning a year, just assign a name that makes sense for the field. If you’re keeping
track of zip codes, to use the example above, don’t say CustomerZipCode2014. Just
keep it plain and simple and you’ll have a better overall experience.

9. Avoid being redundant so you can avoid being redundant.

It can be easy to get into the habit of naming items based on certain prefixes that are
needed and names that are being used. The only problem is that this can often create a
redundancy within your name that can make it difficult to access later on. If you need a
zip code report object, then calling it rptZipCodeReport will just make people shake their
heads when they see it.

B.5. Errors in Database

1. Data Redundancy - same data are stored in the same location

2. Data inconsistency - exists when different and conflicting versions of the same data
appeared in different places (changing the data in a certain field)
3. Data anomalies (abnormality)
• Modification anomalies
• Insertion anomalies
• Deletion anomalies

Insertion anomaly: If a tuple is inserted in referencing relation and referencing attribute

value is not present in referenced attribute, it will not allow inserting in referencing
relation. For Example, If we try to insert a record in STUDENT_COURSE with
STUD_NO =7, it will not allow.

Deletion and Updation anomaly: If a tuple is deleted or updated from referenced

relation and referenced attribute value is used by referencing attribute in referencing
relation, it will not allow deleting the tuple from referenced relation. For Example, If we
try to delete a record from STUDENT with STUD_NO =1, it will not allow. To avoid this,
following can be used in query:
● ON DELETE/UPDATE SET NULL: If a tuple is deleted or updated from referenced
relation and referenced attribute value is used by referencing attribute in
referencing relation, it will delete/update the tuple from referenced relation and set
the value of referenced attribute to NULL.
● ON DELETE/UPDATE CASCADE: If a tuple is deleted or updated from referenced
relation and referenced attribute value is used by referencing attribute in
referencing relation, it will delete/update the tuple from referenced relation and
referencing relation as well.