Модели данных

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

Можно выделить следующие уровни такого моделирования: внешний, концептуальный, физический.

Естественно, что проект базы данных надо начинать с анализа пред­метной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых база данныхсоздается). Пред-метная область - это часть реального мира, данныео которой мы хотим отразить (например, это может быть бухгалтерия какого-либо предпри­ятия, отдел кадров, банк, магазин и т.д.).

Предметная область обычно бесконечна и содержит как существенно важные понятия и данные, так и малозначащие или вообще не имеющие значения. В качестве примеров понятий предметной области можно на­звать такие, как «сотрудник», «отдел», «зарплата». Типичные примеры взаимосвязей между понятиями - «сотрудник числится только в одном отделе», «сотрудник получает зарплату». Примеры ограничений: «возраст сотрудника не менее 16 и не более 60 лет». Если в качестве предметной области выбран учет товаров на складе, то понятия «накладная» и «счет-фактура» будут существенно важными для БД, а то, что сотрудница, при­нимающая накладные, имеет двоих детей, не имеет значения для учета товаров (хотя с точки зрения отдела кадров эта информация может быть весьма существенной). Таким образом, важность данных зависит от вы­бора предметной области.

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

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

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

Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. В конце концов этой средой может быть и память человека, а не только ЭВМ. Поэтому мифо­логическая модель не должна изменяться до тех пор, пока какие-то из­менения в реальном мире не потребуют соответствующих корректировок (чтобы модель продолжала адекватно отражать предметную область).

В качестве средств реализации инфологической модели могут вы­ступать семантические сети и текстовые описания предметной области, но опыт показывает, что такие способы ее представления крайне неэф­фективны. Гораздо более информативными и полезными для разработки баз данных являются описания предметной области, выполненные при помощи графических средств. Из наиболее известных можно назвать методику структурного анализа SADT, диаграммы потоков данных Гей-на-Сарсона, методику объектно-ориентированного анализа UML и др. Наиболее популярными оказались различные варианты диаграмм (Entity-Relationship, диаграммы «сущность-связь»). ER-диаграммы можно в дальнейшем (на концептуальном уровне) преобразовать как в реляци­онную модель данных, так и в модели данных для иерархических или сетевых СУБД, или в постреляционную модель.

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

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

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

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

Допустимая организация данных определяет разнообразие и количе­ство типов объектов, включенных в модель, ограничения на структуру данных.

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

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

Среди дат алогических моделей выделяют две группы - докумен­тальные и фактографические. Документальные модели используются для описания слабо структурированной информации, такой как тексты на естественном языке, словари в программах перевода и т.п. Среди фактографических моделей наибольшее распространение получили основанные на теоретике-графовом (иерархические и сетевые) и на тео­ретико-множественном представлении данных (реляционные).

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

Сетевые модели также создавались для малоресурсных ЭВМ. Это достаточно сложные структуры, состоящие из так называемых «наборов» - поименованных двухуровневых деревьев. Наборы соединяются с по­мощью записей-связок, образуя цепочки и иные структуры. Типичные операции в сетевой модели: найти следующую записьданного типа и сделать ее текущей; извлечь запись в буфер прикладной программы для обработки; запомнить запись из буфера в базе.

При разработке сетевых моделей было выдумано множество «малень­ких хитростей», позволяющих увеличить производительность СУБД, но существенно их усложняющих.

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

Наибольшее распространение получили реляционные модели данных, которые базируются на теоретико-множественном понятии «отношение». Такая модель позволяет строить БД, которые воспринимаются пользова­телем как набор таблиц.

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

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

Решения, принятые на каждом из перечисленных этапов, неизбежно будут сказываться на всех последующих; поэтому требуется особенно ответственный подход на ранних стадиях моделирования баз данных.