Как было сказано выше, ядром современных информационных систем являются базы данных – специально организованные информационные массивы, накопление и обработка которых, по сути, являются центральной задачей функционирования информационных систем.
На этапе разработки ИС (см.п.п. 2.1) созданию «работающих» баз данных предшествует концептуальное проектирование информационной модели предметной области ИС и структур данных.
Проектирование структуры БД осуществляет системный аналитик – специалист, владеющий методами структурного анализа, разбирающийся в технологии программирования и возможностях современных языков программирования.
Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, системный аналитик сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных (рис. 2.4).
Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. Этой средой может быть память человека, а не компьютер. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.
Остальные модели, представленные на рисунке 2.4, являются компьютеро-ориентированными.
Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных. Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое программистом (администратором базы данных) по инфологической модели, называют даталогической моделью данных.
На физическом уровне структура баз данных – это структура файлов данных и вспомогательных файлов. Структура файла в реляционной модели – это имя, тип поля, его длина и точность (для числовых полей). 
|
Таким образом, рассматривают три уровня описания базы данных, на каждом из которых ее структура изображается по-разному.
Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. Администратор базы данных может при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. Можно подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.
3.5. Основные понятия и принципы построения реляционных баз данных
По популярности реляционные СУБД сегодня — вне конкуренции, хотя реляционные системы далеко не сразу получили широкое распространение. Основные теоретические результаты в этой области были получены еще в 70-х годах 20-го столетия, и тогда же появились первые прототипы реляционных СУБД, тем не менее долгое время считалось невозможным добиться эффективной реализации таких систем. Однако отмеченные выше преимущества и постепенное накопление методов и алгоритмов организации реляционных баз данных и управления ими привели к тому, что уже в середине 80-х годов реляционные системы практически вытеснили с мирового рынка ранние СУБД.
Реляционная база данных – это совокупность отношений, содержащих всю информацию, которая должна храниться в БД. Пользователи могут воспринимать такую базу данных как совокупность таблиц. При этом:
1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.
2. Строки имеют фиксированное число полей (столбцов) и значений (множественные поля и повторяющиеся группы недопустимы). Иначе говоря, в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или ничего.
3. Строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку такой таблицы.
4. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных (даты, фамилии, целые числа или денежные суммы).
5. Полное информационное содержание базы данных представляется в виде явных значений данных и такой метод представления является единственным. В частности, не существует каких-либо специальных "связей" или указателей, соединяющих одну таблицу с другой.
6. При выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке безотносительно к их информационному содержанию. Этому способствует наличие имен таблиц и их столбцов, а также возможность выделения любой их строки или любого набора строк с указанными признаками
Предложив реляционную модель данных, Э.Кодд создал и инструмент для удобной работы с отношениями – реляционную алгебру. Каждая операция этой алгебры использует одну или несколько таблиц (отношений) в качестве ее операндов и продуцирует в результате новую таблицу, т.е. позволяет "разрезать" или "склеивать" таблицы
Реляционной считается такая база данных, в которой все данные представлены для пользователя в виде прямоугольных таблиц значений данных, и все операции над базой данных сводятся к манипуляциям с таблицами. Таблица состоит из строк и столбцов и имеет имя, уникальное внутри базы данных. Таблица отражает тип объекта реального мира (сущность), а каждая ее строка — конкретный объект.
Так, таблица Рейс (см. рисунок 3.5) содержит сведения обо всех рейсах, совершенных судами судоходной компании, а ее строки являются наборами значений атрибутов конкретных рейсов. Каждый столбец таблицы — это совокупность значений конкретного атрибута объекта. Так, столбец Название судна представляет собой множество значений "Повенец", "Андижан", "Славия". В столбце Количество груза содержатся целые неотрицательные числа. Значения в столбце Фрахтовая ставка — вещественные числа, равные величине фрахтовой ставки в долларах США..
Эти значения выбираются из множества всех возможных значений атрибута объекта, которое называется доменом (domain). Так, значения в столбце Название суна выбираются из множества имен всех судов компании — Андижан, Повенец и Славия. Следовательно, в столбце Название судна принципиально невозможно появление значения, которого нет в соответствующем домене, например, "Славянск" или "Пула".
 |
|
|
РЕЙС
 
| Порт отправления | Порт назначения | Кол-во груза | Фрахт. ставка |
| ||||
| Ильичевск | Генуя |   Повенец
| |||||||
| Генуя | Одесса | Повенец | |||||||
| Ильичевск | Пула |   Андижан
| |||||||
| Одесса | Стамбул | Славия | |||||||
| Стамбул | Ильичевск | Славия |
|
Рисунок 3.5 - Основные понятия базы данных.
Каждый столбец (поле) имеет имя, которое обычно записывается в верхней части таблицы. Оно должно быть уникальным в таблице, однако различные таблицы могут иметь столбцы с одинаковыми именами. Любая таблица должна иметь, по крайней мере, один столбец; столбцы расположены в таблице в соответствии с порядком следования их имен при ее создании.
В отличие от столбцов, строки не имеют имен; порядок их следования в таблице не определен, а количество логически не ограничено.
Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции — среди них не существует "первой", "второй", "последней". Любая таблица имеет один или несколько столбцов, значения в которых однозначно идентифицируют каждую ее строку. Такой столбец (или комбинация столбцов) называется первичным ключом (primary key). В таблице Рейс первичный ключ — это столбец Номер рейса. В нашем примере каждый рейс имеет единственный номер, по которому из таблицы Рейс извлекается необходимая информация. Следовательно, в этой таблице первичный ключ — это столбец Номер рейса. В этом столбце значения не могут дублироваться — в таблице Рейс не должно быть строк, имеющих одно и то же значение в столбце Номер рейса. Если таблица удовлетворяет этому требованию, она называется отношением (relation).
Взаимосвязь таблиц является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами (foreign key). Рассмотрим пример, в котором база данных хранит информацию о рядовых служащих (таблица Сотрудник) и руководителях (таблица Руководитель) в некоторой организации. Первичный ключ таблицы Руководител ь — столбец Номер (например, табельный номер). Столбец Фамилия не может выполнять роль первичного ключа, так как в одной организации могут работать два руководителя с одинаковыми фамилиями. Любой служащий подчинен единственному руководителю, что должно быть отражено в базе данных. Таблица Сотрудник содержит столбец Номер руководителя, и значения в этом столбце выбираются из столбца Номер таблицы Руководитель. Столбец Номер Руководителя является внешним ключом в таблице Сотрудник.
 |
СОТРУДНИК
| № | Фамилия | Номер руководителя | Должность |
| Иванов |  1150
| М.н.с. | |
| Петров | С.н.с. | ||
| Сидоров | М.н.с. | ||
| Кротов | Вед.инж. | ||
| Куркин | Ст.инж. |
| |||||
 | |||||
 | |||||
РУКОВОДИТЕЛЬ
| № | Фамилия | Отдел | Телефон |
| Васильев | 11 Л | 1-13 | |
| Васечкин | 24 Л | 1-26 | |
| Василенко | 12 И | 1-80 |
Рисунок 3.6 - Взаимосвязь таблиц базы данных.
