Позвольте нам использовать пример нашей адресной книги, чтобы начать обсуждение базы данных, которая может реально использоваться в деловой ситуации. Предположим, что персонажи в нашей первой таблице (адресной книги) — это пациенты больницы. В другой таблице, мы могли бы запомнить дополнительную информацию об этих пациентах. Столбцы второй таблицы могли бы быть помечены как Пациент, Доктор, Страховка, и Баланс.
| Пациент
| Доктор
| Страховка
| Баланс
|
| Farish
| Drume
| B.C./B.S.
| $272.99
|
| Grillet
| Halben
| None
| $44.76
|
| Brock
| Halben
| Health,Inc.
| $9077.47
|
Много мощных функций можно выполнить, извлекая информацию из этих таблиц согласно указанным параметрам, особенно когда эти параметры включают в себя фрагменты информации, связанные в различных таблицах друг с другом. Например, возьмем докторов. Предположим, доктор Halben захотел получить номера телефонов всех своих пациентов. Чтобы извлечь эту информацию, он мог бы связать таблицу с номерами телефонов пациентов (по адресной книге) с таблицей, которая бы указывала, какой из пациентов — его. Хотя, в этом простом примере, он мог бы держать это в голове и сразу получать номера телефонов пациентов Grillet и Brock, эти таблицы могут быть слишком большими и слишком сложными. Программы реляционной базы данных разрабатывались для того, чтобы обрабатывать большие и сложные совокупности данных такого типа, что, очевидно, является более универсальным методом в деловом мире. Даже, если бы база данных больницы содержала сотни или тысячи имен — как это, вероятно, и бывает на практике — одна команда SQL могла бы выдать доктору Halben информацию, в которой он нуждался почти немедленно.