I'm mostly a system administrator and I don't directly work with databases other than installing them, setting up accounts, granting privileges, and so on. I realized that if The Boss walked up to me and asked, "What is a relational database?" I probably couldn't give a satisfactory answer... I'd maybe mumble something about data being stored and organized by categories which you can query with a special programing language (i.e., SQL).

So could someone give a good "Boss Answer" for what a relational database is? And maybe how its different than just storing data on a file server? Bonus points for clever but accessible analogies and explaining tables, columns, records and fields. I'd define a "Boss Answer" as a quick one (maybe two) paragraph explanation for non-technical folks... mostly your Boss, on those rare occasions they actually ask you what it is you do all day.

  • 2
    Not sure serverfault is the right place for this question, useful though it is. Perhaps DBA.SE or Programmers.SE.
    – Orbling
    Mar 13, 2011 at 0:34
  • 1
    Why would your boss ask such a question and, even more importantly, what does it have to do with system administration? Mar 13, 2011 at 3:35
  • 1
    @John Gardeniers, It may belong here because many 'system admins' are wear a 'database administration' hat, meaning they have a good understanding of how RDBMS work. As for why bosses ask questions they do, who knows, but knowing how to clearly communicate concepts is a good thing IMO.
    – Zoredache
    Mar 13, 2011 at 6:24
  • 1
    @Zoredache, in my job I wear many hats. That doesn't mean they're all on topic for SF. Mar 13, 2011 at 8:02
  • The answers below are very good, but keep in mind that you can have non-relational databases (such as btrieve) and still maintain relationships between the normalised data through proper application logic. Mar 13, 2011 at 9:31

8 Answers 8


A relational database doesn't just store data: it stores relationships between data, and makes it easy (well, easier) to use those relationships. In the early days of relational database terminology, tables were called "relations" because they stored related bits of data (fields, now columns), along with the relationships between that relation and other relations.

Normalization is the act of un-complicating relations: "Make everything as simple as possible, but no simpler." (Alan Perlis) Sometimes "...but no simpler" means we don't store things fully normalized, because "simpler" ends up being more complex. (You can derive the state from the zip code, but why bother?)


A relational database is a method of structuring data so a single fact is stored in a single place. So if John and Jane Doe both work for the same company, you would only store details unique to the company in one place(table). You would store data unique to John and Jane in another place, and you would store both John and Jane's relationship to the company in a third place. In the ideal world this should mean I only have to modify a single field/row if the company fax number changed.

Please understand that not all databases hosted in a RDBMS are properly normalized. Compromizes are made for performance and other reasons.

See the article on database normalization. http://en.wikipedia.org/wiki/Database_normalization


There are two major concepts to distinguish relation database systems. The first is that relations between items are stored. That's the table model of data, explained via the spreadsheet analogy. RDBMSs get more complex than spreadsheets, because its easier and common practice to have many references between tables or worksheets (depending on which side of the analogy you're using).

The second is that RDBMSs implement the idea of a transaction, the ACID properties of

  • atomicity,
  • consistency,
  • isolation, and
  • durability

The relational model allows many complex relationships to be included, queried for, sorted on, grouped by, and so on. The transactional model makes sure that transactions happen completely or not at all, keeping the relationship model consistent and accurate. Well, at least making it possible for correct programming to keep it so.


A relational database is like an Excel Workbook with many many worksheets, and a surrounding software environment to make performance optimizations such as indexing and caching, enforce safe access by many users at the same time, and allow you to efficiently view data that may be spread over many of the different worksheets.


A relational data abase is a tool for storing and retrieving data stored in a relational model.

A relational model of data is built according a small number (depending on which book you read, 4 or 5 rules) which ensure that the data can be accessed in a consistent manner, which allow the correctness of the design to be proven and which allows the database management system (DBMS) to do most of the work in retrieving the data quickly. It also provides tools for formally documenting the structure of the data - implementing a database intrinsically implements most of the documentation.

Most people don't understand why correctness is important - it means that bugs are less likely to be introduced in the development of a solution - and that (e.hg) 2 different programmers working in similar areas are less likely to duplicate effort.

As a seperate entity from the application front end, and with a consistent view of the structure of the data, the use of a database management system allows different tools to be used at the front end for different purposes - so you can make much more use of off-the-shelf components when building a solution.

There are other models other than the relational one for storing data - but no other one (in my experience) comes close in both its simplicity, flexibility and availability of tools for developing and managing your data.


A 100% non technical answer:

A relational database is a place to store data in such a way as to minimize redundancy and allow you to search through it easily.

Suppose a database for a pet store. The store has items, it has customers, and it has sales. If we were to put that in Excel, you could have this for columns:

Customer Name | Customer phone number | Customer address | Item bought | Price | Date

First customer, Mrs Smith, buys cat food:

Customer Name | Customer phone number | Customer address | Item bought | Price | Date
Mrs Smith     | 123-555-1234          | 10 Main St       | Cat food    | $15   | 2011-03-11

And then Mrs Smith would like a cat toy too:

Customer Name | Customer phone number | Customer address | Item bought | Price | Date
Mrs Smith     | 123-555-1234          | 10 Main St       | Cat food    | $15   | 2011-03-11
Mrs Smith     | 123-555-1234          | 10 Main St       | Cat toy     | $1    | 2011-03-11

And she basically comes back every 2 weeks or so and buys the same things. With this method, you duplicate a lot of information, and that can lead to errors. You also can't store an inventory in this, it has to be a whole other Excel sheet, and that one will have to be updated at each sale.

With a database, we could have three separate entities: Customers (with their information), Items (with a description and a price), and Sale (a link between customers and items, with a date and a quantity).


Some good technical answers here. But my boss would understand none of them!

I would start with an extremely simple explanation - 'If you save your data in a file, it appears as one long list. A relational database saves the data more like a map or graph, so different parts of the map link to each other....'

And an example - '.... for example your name links to your address, which in turn might link to your city.'

Followed by the business benefits he cares about - 'The advantage of this is it makes it a lot cheaper to write code to get complicated data out e.g. "find me all people who live in Seattle whose last name is Smith". Also relational databases are very reliable and fast.'

And end it with a credibility statement - 'Relational databases have been around for many years, are very mature pieces of technology. Our particular product is [product name here]'.


My boss is the DBA, but in laymen terms:

Think about two tables in Excel, and the LOOKUP function to reference items in one table to another. Now scale that up by at least a factor of 10.

That's about the computer level of some of the people and work.