Общность реляционного подхода при проектировании баз данных

Каждому типу модели данных и каждой разновидности модели, поддерживаемой конкретной СУБД, присущи свои специфические особенности. Вместе с тем имеется много общего во всех структурированных моделях данных и принципах проектирования БД в их среде. Все это дает возможность использовать единый методологический подход к проектированию структуры базы данных.

В БД отражается определенная предметная область. Поэтому процесс проектирования БД предусматривает предварительную классификацию объектов предметной области, систематизированное представление информации об объектах и связях между ними. На проектные решения оказывают влияние особенности требуемой обработки данных. Поэтому соответствующая информация должна быть определенным образом представлена и проанализирована на начальных этапах проектирования БД.

Данные о предметной области и особенностях обработки информации в ней фиксируются в инфологической модели (ИЛМ). В такой модели должна быть отображена вся информация, циркулирующая в информационной системе, но это вовсе не означает, что вся она должна храниться в базе данных. В связи с этим одним из первых шагов проектирования является определение состава БД, т.е. перечня тех показателей, которые целесообразно хранить в БД.

При проектировании логической структуры БД осуществляются преобразование исходной инфологической модели в модель данных, поддерживаемую конкретной СУБД, и проверка адекватности полученной даталогической модели (ДЛМ) отображаемой предметной области. Для любой предметной области существует множество вариантов проектных решений ее отображения в даталогической модели. Методика проектирования должна обеспечивать выбор наиболее подходящего проектного решения.

Минимальная логическая единица данных (несмотря на их разные названия) семантически для всех СУБД одинакова и соответствует либо идентификатору объекта, либо свойству объекта или процесса. Связи между сущностями предметной области, отраженные в инфологической модели, могут отображаться в даталогической модели либо посредством совместного расположения соответствующих им информационных элементов, либо путем объявления связи между ними. Связь может передаваться как на внутризаписном, так и на межзаписном уровне. Не все виды связей, существующие в предметной области, могут быть непосредственно отображены в конкретной даталогической модели. Отношения, имеющие место в предметной области и отражаемые в ИЛМ, могут быть переданы не только посредством структуры базы данных, но и программным путем (т.е. всегда существует альтернатива между декларативным и процедурным способом описания явления). Решение о том, какой из способов отображения (структурный/декларативный или программный/процедурный) следует использовать в каждом конкретном случае, будет зависеть от многих факторов, таких, как стабильность отображаемой сущности, объем номенклатуры, особенности СУБД, характер обработки данных и др.

Традиционное деление СУБД по типу модели данных на реляционные, иерархические и сетевые основывается на характере связей между записями. При всей разнице в терминологии можно считать, что основными компонентами любой из этих моделей являются файлы, которые состоят из записей.

В классических иерархических моделях имеется один файл, который является входом в структуру (корень дерева). Остальные файлы связаны друг с другом таким образом, что каждый из них, за исключением корневой вершины, имеет ровно одну исходную вершину («родитель») и любое число подчиненных вершин («детей»). Между записью файла-«родителя» и записями порожденного файла имеется отношение 1:М (как частный случай может быть и отношение 1:1).

В сетевых моделях, если на нее не накладывается никаких ограничений, в принципе любой файл может быть точкой входа в систему, каждый из файлов может быть связан с произвольным числом других файлов, и между записями связанных файлов могут быть любые отношения (1:1, 1:М, М:М). Однако в реальных СУБД на модель накладываются различные ограничения. Так, имеются сетевые СУБД с разнотипными файлами. В них все файлы разделены на два типа: основные и зависимые. В таких СУБД входом в базу данных могут служить только основные файлы, а связываться между собой могут только разнотипные файлы. Во многих сетевых СУБД не поддерживается непосредственно отношение М:М. В таких моделях каждая связь между парой файлов определяется отдельно, и для каждой из них один файл в этой паре объявляется «владельцем», а другой – «членом». Отношение между записью-«владельцем» и записями-«членами» – 1:М. Связи между файлами в иерархических и сетевых моделях определяются при описании структуры базы данных и физически передаются при помощи различных указателей.

Реляционная модель данных характеризуется: информационной конструкцией; допустимыми операциями (выборкой, соединением и др.); ограничениями (функциональными зависимостями между атрибутами). В реляционной модели используется своеобразная терминология, но это не меняет сущности модели. Часто даже в рамках одной модели в разных СУБД используется разная терминология. Так, на логическом уровне элемент чаще всего называют атрибутом; кроме того, для него используются термины «колонка», «столбец», «поле». Совокупность атрибутов образует строку (синонимичные термины – «ряд», «запись», «кортеж»). Совокупность строк образует отношение («таблица», «файл базы данных»). Понятие базы данных как множества отношений поддерживается далеко не всеми реляционными СУБД (т.е. при создании БД описываются отдельные отношения (файлы), а для всей базы данных как самостоятельной информационной единицы никакого описания не предусмотрено). Реализационная база данных может быть описана как (рис. 4.4):

S (rel) = < A, R, Dom, Rel, V (s)>,

где A – множество имен переменных; R – множество имен отношений; Dom – вхождение атрибутов в домены; Rel – вхождение атрибутов в отношения; V (s) – множество ограничений.

Рис. 4.4. Основные понятия реляционного подхода

Описание процесса обработки отношений может быть выполнено двумя способами: указанием перечня операций, выполнение которых приводит к требуемому результату (процедурный подход); описанием требуемых свойств (декларативный подход). Множество операций и отношений образуют реляционную алгебру.

Связи между файлами в реляционной модели в явном виде могут не описываться. Они устанавливаются динамически в момент обработки данных по равенству значений соответствующих полей. В сетевых и иерархических моделях структура записи может быть любой. В реляционных моделях структура записи должна быть линейной.

Каждое отношение по определению имеет ключ, т.е. атрибут (простой ключ) или совокупность атрибутов (составной ключ), однозначно идентифицирующих кортеж. В некоторых случаях в отношении может быть несколько возможных ключей. К сожалению, далеко не все реляционные СУБД поддерживают концепцию ключа, так как в этом случае многие проблемы (в частности, обеспечение проверки на уникальность ключа и соблюдение некоторых других ограничений целостности) возлагаются на пользователя. Вне зависимости от того, требует ли СУБД явного указания ключей при описании отношений или нет, проектировщик базы данных должен понимать, что является ключом каждого отношения. При наличии нескольких вероятных ключей один из них выбирается и описывается как первичный ключ.

Атрибут или группа атрибутов, которая в рассматриваемом отношении не является ключом, а в другом отношении ключом является, называется внешним ключом.

Если какая-то таблица содержит внешний ключ, то она: а) логически связана с таблицей, содержащей соответствующий первичный ключ; б) эта связь имеет характер «один-ко-многим» (таблица, содержащая внешний ключ, находится на стороне «много» в этой связи).

По сути понятия «родитель»-«ребенок» в иерархических моделях, файл-«владелец»-файл-«член» в сетевых моделях и связь «ключ»-«внешний ключ» в реляционных моделях передают одно и то же явление – наличие связи 1:М между записями соответствующих файлов.

В реляционных СУБД часто используется понятие «взгляд» (view). Он представляет собой виртуальную таблицу, полученную в результате логического соединения нескольких связанных по значениям общих столбцов таблиц и, возможно, включающую некоторое подмножество из всей совокупности строк, отобранное по заданному условию. Это понятие расширяет традиционное для банков данных понятие «подсхема».

Понимание различий и общности моделей разных классов позволяет использовать общий подход при проектировании структуры баз данных, осуществлять преобразование одних моделей в другие, использовать средства, в частности языковые, предназначенные для работы с одним классом моделей, при работе с другим.