Проектирование базы данных – один из наиболее ответственных этапов создания любой информационной системы. Качество выполнения этого этапа определяет качество функционирования и живучесть системы в целом. Если абстрагироваться от деталей предметной области, то можно сказать, что в основе любой системы с базами данных лежат четыре операции: поиск, ввод, удаление, корректировка данных. Грамотно спроектированная база данных обеспечивает их наилучшее выполнение при соблюдении дополнительных ограничений, таких, как требования безопасности, аппаратные ресурсы, возможности персонала, режимы работы и др.
В проект базы данных закладывается некоторая модель предметной области. Поэтому первым этапом работ является предпроектное обследование объекта информатизации, построение инфологической (информационно-логической) модели предметной области. Именно эта модель служит основой технических решений по проектированию базы данных. Моделирование данных – это процесс описания информационных структур и бизнес-правил для определения потребностей информационной системы.
На входе процесса проектирования общие требования (цели системы, данные), требования к обработке (объем данных, необходимые операции с данными, частота их выполнения), характеристики СУБД (чаще всего ограничения), характеристики платформы (ОС, комплекс технических средств).
В соответствии с концепцией, опубликованной в 1975 г. в отчете рабочей группы по базам данных ANSI/X3/SPARC (Комитета по планированию стандартов Американского национального института стандартов), выделяются три уровня представления (моделирования) при проектировании базы данных: внешний, концептуальный и внутренний (рис. 2.1). Наряду с термином «модель» часто используется также термин «схема».
| Пользователь 1 |
| Пользователь N |
| Концептуальное |
| представление |
| Внутреннее |
| представление |
| Внешнее представление |
Рис. 2.1. Подход ANSI/SPARC
Внешняя модель отображает взгляды на данные конкретных пользователей. При разработке внешней модели определяются основные информационные объекты, их атрибуты, устанавливаются связи между объектами и их характер (один к одному, один ко многим, многие к одному, многие ко многим). В системе может одновременно поддерживаться несколько внешних схем для различных групп пользователей и/или приложений. Следует отметить, что итоговое внешнее представление, полученное в результате проектирования базы данных, может не совпадать и, как правило, не совпадает с внешним представлением, которое было выработано на этапе постановки задачи. На вид итогового представления влияют результаты и концептуального, и внутреннего проектирования. Поэтому некоторые специалисты называют исходную внешнюю модель инфологической, а итоговую – внешней.
Концептуальная модель служит для поддержки единого взгляда на базу данных, общего для всех приложений и в этом смысле независимого от них. На этапе создания концептуальной модели выявляются и устраняются противоречия во взглядах на данные различных пользователей и приложений, устанавливаются общие для всех правила и приемы работы с данными. Именно в среду концептуального уровня при проектировании базы данных отображается концептуальная модель предметной области. В соответствии с подходом ANSI/X3/SPARC концептуальная модель данных не зависит от среды и механизма реализации, от типа выбранной СУБД. Тем не менее, ограничения СУБД в части типов данных, возможностей представления связей между данными могут наложить отпечаток на концептуальную схему. Поэтому в ряде случаев выполняют так называемое проектирование реализации, т.е. концептуальное проектирование с учетом целевой СУБД.
Внутренняя модель данных отображает концептуальную схему в соответствии с требованиями целевой СУБД и платформы. Прежде всего решаются вопросы отображения типов данных концептуальной модели в типы данных СУБД. Также возможно влияние проектировщика на распределение дискового пространства, размер блока записей, организацию указателей и т.д. Объем работы при создании внутреннего представления определяется возможностями, предоставляемыми целевой СУБД. Так, в большой степени ориентированная на пользователя, хотя и продвинутого, СУБД Access требует минимального учета особенностей СУБД. Внутреннее проектирование заключается только в описании структуры данных на языке описания данных СУБД. В более сложных СУБД производится настройка стратегии приращения дискового пространства при росте базы данных, очистки системных журналов, размещения данных при вводе новых записей и корректировке существующих и т.д.
Механизмы СУБД, поддерживающие внутренний уровень архитектуры, служат для поддержки представления базы данных в среде хранения. Это – единственный уровень информационной архитектуры, где база данных в материализованном виде. Поэтому внутреннюю модель (схему) называют также схемой хранения. В отличие от схемы хранения, концептуальная и внешние схемы являются виртуальными. Составляющие их данные материализуются только при обращении к ним.
Очевидно, что в предлагаемой архитектурной модели необходимо поддерживать соответствие между представлениями базы данных на смежных уровнях архитектуры системы базы данных. В модели ANSI/X3/SPARC для этой цели служат механизмы междууровневого отображения данных "внешний – концептуальный" и "концептуальный – внутренний". Именно эти механизмы обеспечивают абстракцию данных в системе, определяют достижимую в системе степень независимости данных.
На этапе проектирования необходим учет всех этапов жизненного цикла системы с базой данных. Можно выделить 2 фазы (этапа): анализа и проектирования; реализации и функционирования.
На этапе анализа и проектирования выполняется:
· формулирование и анализ требований (учитываются общие информационные требования и требования к обработке);
· концептуальное проектирование (без учета СУБД);
· проектирование реализации (наложение на концептуальную схему возможностей представления данных конкретной СУБД);
· физическое проектирование.
На этапе реализации и функционирования выполняется:
· заполнение базы данными, эксплуатация базу данных;
· анализ функционирования и поддержка (резервное копирование, реорганизация с целью повышения операционных характеристик без изменения схемы данных);
· модификация и адаптация.
Обращает на себя внимание, что, в отличие от большинства объектов материального мира, жизненный цикл системы с базой данных не содержит фазу вывода из эксплуатации, уничтожения. В современном мире информация имеет огромную ценность. Даже устаревшие данные зачастую не уничтожаются, т.к. позволяют выявить тенденции, являются объектами анализа. Информационная система и ее база данных со временем модернизируется, видоизменяется на основе накопленного опыта и требований времени. Поэтому важность качественного проектирования базы данных несомненна.
ОСНОВНЫЕ МОДЕЛИ ДАННЫХ
Модель данных можно определить как интеллектуальное средство, позволяющее организовать интерпретацию данных в соответствии с заданными требованиями. Поэтому для отображения всего многообразия окружающего нас мира и всего многообразия требований можно предложить бесконечное множество моделей.
Все моделей можно разделить на две большие группы: инфологические (информационно-логические) и даталогические.
Инфологические модели служат для описания предметной формы, дают методику формализации предметной области, используются на этапе информационного анализа, постановки задачи. Рассмотрение этих моделей выходит за рамки настоящей работы.
Даталогические модели ориентированы на обработку данных, поддерживаются действующими СУБД. К основным классическим даталогическим моделям относятся иерархическая, сетевая и реляционная. Модели различаются, в основном, способом представления связей между объектами. Иерархическая и сетевая модели основаны на теории графов, связи программируются с помощью указателей (списковые структуры). В реляционной модели объекты и связи между ними представляются в виде плоских двумерных таблиц. Доказано, что реляционная модель является более общей, иерархические и сетевые структуры сводимы к реляционным.
3.1. Иерархическая модель данных
В основе модели лежат древовидные структуры. Основной тип связи – «один ко многим». Каждый элемент графа называется узлом, самый верхний узел – корень, узлы нижнего уровня, не имеющие порожденных, – листья. Каждый узел, за исключением корня, имеет родительский узел, который непосредственно связан с рассматриваемым и расположен на уровень выше. Множество деревьев называется лесом. На граф иерархической модели накладываются ограничения – ни один элемент не может иметь более одного исходного. Иерархическая модель контекстно зависима. Можно включить данные, если определен (существует) исходный элемент. При удалении элемента удаляются все порожденные им элементы. Иерархическая модель является навигационной. Принят канонический метод обхода дерева: сверху вниз, слева направо (рис. 3.1.). Это позволяет в некоторой степени прогнозировать скорость обработки данных. Очевидно, что выборка данных, расположенных левее и на уровне, более бликом к корню дерева, выполняется быстрее.
Иерархическую модель отличает легкость и эффективность реализации, естественность, простота понимания и использования. Обеспечивается определенный уровень независимости данных. Например, можно добавлять в модель новые типы данных, размещая их правее существующих. Слева наращивать модель нельзя, т.к. можно нарушить работоспособность приложений, использующих операцию получения следующего элемента данных, расположенного на более низком уровне по отношению к исходному.
Рис. 3.1. Канонический алгоритм обхода дерева
К недостаткам иерархической модели можно отнести затрудненность реализации связи «многие ко многим» (требуются специальные технические решения, выходящие за рамки модели), возникновение проблемы удаления и включения данных из-за строгой иерархической упорядоченности. Например, при удалении некоторого узла, удаляется все поддерево, выходящее из этого узла.
3.2. Сетевая модель данных
Сеть образуется двумя типами данных, различающихся в программе пользователя: вершинами и дугами. В отличие от дерева вершина может иметь произвольное количество входных и выходных дуг. Дерево – частный случай сети. В сетевой модели можно непосредственно организовать связь «многие к одному» и «многие ко многим». По сравнению с иерархической моделью расширено понятие главного и подчиненного объекта. Аналогично иерархической модели, при работе с данными осуществляется обход сети. Но канонического алгоритма обхода нет, т.к. сеть имеет произвольную конфигурацию.
Большое внимание к сетевой модели возникло после публикации работ DBTG CODASYL (DBTG – Data Base Task Group, CODASYL – Conference on Data System Languages). В одном из отчетов этой неформальной организации была предложена спецификация, на основе которой по настоящее время создаются все СУБД, поддерживающие сетевую модель данных.
Основными компонентами сетевой модели являются – записи (узлы графа) и наборы (дуги). Графически все это представляется с помощью диаграмм Бахмана (рис. 3.2). Записи – прямоугольники, наборы – стрелки. Аналогично иерархической модели различают тип и экземпляр записи. Описание происходит на уровне типов. Поиск ведется на уровне экземпляров. Стрелка определяет тип набора. По сути, это имя связи, установленной между данными. Тип записи, откуда выходит стрелка – владелец набора, тип записи, куда входит стрелка – член набора. Одни и те же типы данных могут участвовать в произвольном количестве связей, т.е. междудвумя типами записей может быть произвольное количество наборов. Запись может быть владельцем одного набора и членом другого.
Рис. 3.2. Диаграмма Бахмана
На уровне экземпляров связь реализуется закольцованной цепью (рис. 3.3). Для реализации на уровне экземпляров в сетевой модели должно поддерживаться правило уникальности владения – экземпляр члена может иметь только одного владельца (рис. 3.4).
Рис. 3.3. Реализация на уровне экземпляров
Рис. 3.4. Правило уникальности владения
Кроме операций с узлами сети (найти, изменить, создать) имеются операции с дугами (присоединить запись к набору, отсоединить запись от набора).
Сетевую модель данных отличает наличие успешно действующих СУБД, естественность реализации связи «многие ко многим», гибкость, возможность построения структуры данных любой сложности, эффективность реализации. Однако эта модель является самой сложной с точки зрения проектирования базы данных и программирования приложений.
3.3. Реляционная модель данных
Среди множества существующих моделей данных наибольшую популярность и развитие получила реляционная модель. Она отличается строгим математическим обоснованием, которое позволило, с одной стороны, подвести научный базис под языки манипулирования данными, с другой стороны получить строгую, научно обоснованную методологию проектирования корректных баз данных. Реляционная модель данных была предложена Э. Коддом в публикациях 1970 г. и 1979 г. Подавляющее большинство современных СУБД поддерживает именно эту модель данных.
База данных в реляционной модели представляется совокупностью плоских двумерных таблиц. Эти таблицы имеют следующие свойства:
1. Каждый элемент таблицы – один элемент данных;
2. Все столбцы таблицы однородны, т.е. все элементы столбца имеют одинаковую природу;
3. Столбцы однозначно именуются;
4. В таблице нет двух одинаковых строк;
5. Строки и столбцы могут просматриваться в любом порядке.
Соблюдение всех свойств, за исключением свойства 4, обеспечивает по умолчанию любая реляционная СУБД. Свойство 4 направлено на то, чтобы все строки таблицы были различимы. Однако на практике возможны случаи одинаковых строк. Поэтому СУБД соблюдение этого свойства не контролируют. При необходимости его соблюдение обеспечивается соответствующим проектированием структуры таблицы. Проектирование таблиц с данным свойством будет рассмотрено ниже.
Таблица в реляционной модели называется отношением (relation). Можно дать два определения отношения.
1. Пусть дана совокупность множеств 
, не обязательно различных. Отношение R, определенное на этих n множествах, есть множество упорядоченных кортежей 
, что 
. Множество 
– домены отношения R, n – степень отношения R (число столбцов таблицы). Количество кортежей (строк) – мощность (кардинальное число) отношения R.
2. R – подмножество декартова произведения доменов 
.
Использование понятия подмножества во втором определении связано с тем, что не все кортежи, порождаемые операцией декартова произведения, имеют смысл для данного отношения.
Различают понятие домена и атрибута. Атрибут – подмножество значений домена, имеющее смысл для данной предметной области. Например, домен ВИД ТРАНСПОРТА может содержать значения, соответствующие любым видам транспорта, которые применялись где-либо когда-либо. Атрибут, возможно, с тем же именем, будет содержать виды транспорта, использующиеся на предприятии для доставки продукции, если отношение относится к службе доставки. Если отношение относится к подсистеме учета командировочных расходов, такой атрибут будет содержать виды транспорта, использующиеся для поездок в командировки.
Отношения записывается в виде схемы отношения:
R(A 1 A 2 … A n ),
где R – имя отношения (имя таблицы);
A i – имена атрибутов.
Домены и соответствующие им атрибуты могут быть простыми и составными.
Простой домен – атомарный (неделимый), сложный или составной домен – иерархическая структура внутри таблицы (рис. 3.5).
Рис. 3.5. Простой и составной домен
На начальном этапе проектирования при постановке задачи таблицы вида рис. 3.5 допускаются.