WHAT ARE DATABASES – PART 1
July 3, 2006
WHAT ARE DATABASES?
Databases are programs that are built to store and manage information. You can think of a database as a virtual filing cabinet – with extra bells and whistles.
Types of databases:
There are several types of databases used today. The most common being:
1. Relational databases.
2. Object databases.
3. Flat file databases.
You can think of each type of database as a different way (conceptual and practical) to store and manage information.
Each type of database has its advantages and disadvantages. That said, by far, the most popular database type is the ‘relational database’. That’s why we concentrate on them here.
WHAT ARE ‘RELATIONAL’ DATABASES?
As I hinted at above, each database type has a different concept on how data/information should be stored and organized.
A relational database stores (and organizes) its data/information by creating relationships between different pieces of information (stored in virtual containers) that are … uh, related to each other.
To illustrate the point: if you had a brother, your mother would be the ‘key’ that forms the relationship between you and your brother.
With this analogy in mind, we can say that a relational database stores and tracks data by establishing relationships by using ‘keys’ (in this case, your mother) that are consistent between two pieces of information – you both have the same mother.
Popular relational databases include:
· MySQL (often used with PHP because it’s free)
· Oracle
· Microsoft SQL Server
WHAT ARE VIRTUAL CONTAINERS?
We all know that it’s much easier to store and find stuff/things (in your home) if you put the stuff into boxes and then label the boxes … much better than just leaving all your junk on the floor.
Though naturally a messy bunch, nerds have picked up on that fact, and realized that computer information should also be stored in boxes (virtual containers) that are labeled. In a relational database, we call these ‘boxes’: tables.
In a nutshell: the virtual containers in relational databases are called ‘tables’ and information is stored in tables.
MORE ABOUT TABLES
Database tables are virtual containers designed to hold and organize data. In many ways they look like spreadsheets where database tables have both rows and columns.
The difference between a spreadsheet (like Excel,) and a relational database table, is that the spreadsheet is designed (has built in capability) to manipulate data for the purposes of presentation – creating charts and reports etc.
Where on the flip side, a database table is designed (has built in tools/capability) to organize and maintain information and it can hold much, much more information than a spreadsheet.
So yes, you can store information in a spreadsheet, but it lacks many capabilities (and capacity) that you would find in a database.
We will learn more about the makeup of a table (purpose of the rows and columns) when we actually build one.
THE ‘RELATIONSHIPS’ IN RELATIONAL DATABASES
As I mentioned above, a relational database stores information in tables (the virtual containers) and then creates relationships/connections between the tables (and thus the data that is stored in the tables.)
This system/method of storing information (by creating relationships,) is efficient because of a few reasons; the most important being is that this style of storing information (in tables that are related to each other,) helps to prevent information from being duplicated needlessly.
A FUNDAMENTAL PRINCIPLE OF DATABASE DESIGN
One of the fundamental rules in database theory/design, is that information should not be duplicated:
… if you have multiple copies of the same information floating around, it takes up more disk space and can easily become a nightmare to organize.
By storing information in different tables, and linking that information to each other (that are related,) you avoid duplicating information. This will become clear when we actually build our first database … I know (that for now,) many of you are probably unclear about a few things … have faith, it will come!
Part 2 coming out soon …
Thanks,
Stefan Mischook
