What is a Relational Database?
Folks starting out with Relational Databases often get confused. I always get confused when I start something new so I know how you feel. Here is a simple explanation from Edgar Codd -who invented Relational Databases, The Wheel, Electricity and Hamburgers back in 1969. He actually only invented one of these things - can you guess which?
Its core idea is to describe a database as a collection of predicates over a finite set of predicate variables, describing constraints on the possible values and combinations of values. The content of the database at any given time is a finite (logical) model of the database, i.e. a set of relations, one per predicate variable, such that all predicates are satisfied. A request for information from the database (a database query) is also a predicate.
Got that? No, I don't understand a word of it either!
The Relational Database
A Relational Database is way of storing data in a Master/Detail form. When I say Master /Detail I don't mean that one set of data is necessarily more important than the other.
At its most simplest a Relational Database can be seen as a set of one to many relationships. Each one of these relationships is joined together by Keys (more late in the course)
For example ONE Mother may have MANY Children - A Child may have only ONE Mother:
This is a diagrammatic representation of a Relationship. Notice how one end has 3 'legs' this can be called a crows foot and it signifies that this end of the relationship is the 'many' end.
This type of diagram can be called an Entity Model, A Relationship Model, and Entity Relationship Diagram (ERD) etc.....
NEVER try and design a Database without doing one of these first. You will probably go through many different versions so have a lot of pencils or invest in some software ( I like OmniGraffle ).
The relationship line may be dotted - signifying that the relationship is not mandatory. In this example that would mean that Children records could exist independently without Mothers - oh that's sad!
Mother and Children here would be created as Tables in our Database
Obviously real world Databases would be a lot more complicated than this. Let's draw an Entity Model for - Children who have mothers going to schools with books they bought from bookshops in certain towns.
So to explain this:
Mothers have MANY Children, Children have only ONE Mother
A School has MANY Children, Children only got to ONE School
Towns have MANY Schools, A School can only be in ONE Town
Towns have MANY Bookshops, A Particular Bookshop can only be in ONE Town>
Bookshops have MANY Books, A Particular Book can only be in ONE Bookshop
Children own MANY Books, A Particular Book can only be owned by ONE Child
*MANY can be one or more
*Each Object in the Diagram represents a Table in a Database
*The Database is the complete collection of all these objects
Once you understand the concept of relationships and Entity Models you are on your way to becoming a Relational Database designer.
There will be more detail on Databases, Relationships, Resolving Many To Many, Self Referential Links and heaps more exciting stuff later in the course.
Before you carry on make sure you understand the above Entity Model.