Страничная организация данных

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

Приведем примерную логическую схему «страничной» организации хранения данных.

При распределении дискового пространства рассматривается следующая схема структуризации пространства в зависимости от типов данных:

Экстент — это непрерывная область дисковой памяти, включающая несколько страниц фиксированной длины. Новый экстент создается после заполнения предыдущего и связывается с ним ссылкой, которая располагается на последней странице экстента, либо в специальной карте размещения. Учет свободных страниц ведется внутри экстента.

Каждый экстент используется для хранения одного из нескольких типов страниц: страницы данных, страницы индексов, страницы blob-объектов. То есть данные на одной странице являются однородными страница, например, может хранить только данные или только индексы.

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

Все страницы данных имеют одинаковую структуру, включающую:

• заголовок страницы, содержащий номер страницы, номера предыдущей и следующей страниц, сведения о свободном пространстве на странице;

• содержание — строки данных, каждая из которых имеет уникальный идентификатор в рамках всей базы данных, который состоит из номера страницы и номера строки на странице;

• дескрипторы строк, задающие смещение строки на странице и длину строки, что позволяет при переупорядочении строк на страницах не производить физического перемещения строк, так как все манипуляции производятся с дескрипторами.

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

22. Модели распределения данные по физическим носителям?

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

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

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

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

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

по доступу к множеству.

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

Главное отличие между сцеплением и расщеплением заключается в размещении смежных данных.

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

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

23. Модели многоуровневой архитектуры систем баз данных?

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

Опубликованный в 1975 году отчет ANSI/ХЗ/SPARCзафиксировал не только широкое признание концепций многоуровневой архитектуры систем баз данных, но и необходимость явного выделения специального концептуального уровня представления базы данных, единого для всех ее приложений и независимого от них. Кроме этого уровня предусматривались еще два уровня: внутренний уровень, который должен обеспечивать поддержку представления хранимой базы данных, и внешний, поддерживающий представления базы данных «с точки зрения» приложений. На каждом архитектурном уровне предполагалось использование той или иной модели данных. Кроме того, на внешнем уровне таких моделей может быть несколько. Модели, а также схемы, специфицируемые на их основе, называются соответственно внешней, концептуальной и внутренней.

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

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

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

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

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

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

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

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

Представленная трехуровневая архитектура позволяет обеспечить независимость хранимых данных от использующих их программ. Хранимые данные могут быть переписаны на другие носители или их физическая структура может быть реорганизована, в том числе дополнена полями для новых приложений, но это повлечет лишь изменение физической и, возможно, даталогической модели данных. Главное, такие изменения физической и даталогической моделей не будут замечены существующими пользователями системы так же, как не будут замечены и вновь подключаемые пользователи. Кроме того, независимость данных обеспечивает возможность создания новых приложений для решения новых задач без разрушения существующих.

В процессе развития теории систем баз данных термин «модель данных» имел разное содержание. Для более глубокого понимания существа отдельных понятий рассмотрим некоторые особенности использования этого понятия в контексте эволюции баз данных, представленные в [11].

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

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

Начиная с середины 70-х гг. под влиянием предложенной в тот период концепции абстрактных типов само понятие типа данных в языках программирования стало трансформироваться таким образом, что в него стали вкладывать не только структурные свойства, но и элементы поведения.

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

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

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

Хотя, строго говоря, здесь речь идет лишь о двух моделях. Действительно, многомерные модели, коммерческие реализации которых появились в начале 90-х гг. для поддержки технологий ОЕАР,не основаны на каких-либо радикально новых идеях. Они представляют собой некоторое расширение активно исследовавшейся в 70 — 80-х гг. модели универсальных отношений новыми операционными возможностями, обеспечивающими, в частности, необходимые для OLAPфункции агрегирования данных. Таким образом, многомерные модели представляют собой особую разновидность реляционной модели.

Многомерные модели — это «полноправные» модели данных. Так же, как и другие модели, они используются для описания базы данных, определяя тем самым соответствующее ее природе представление данных, и предоставляют средства манипулирования данными. И в этом смысле они ничем не отличаются по своей функциональности от прочих моделей данных. В сегодняшних массовых реляционных технологиях многомерные модели ассоциируются с внешним уровнем архитектуры систем баз данных. Именно этим определяется их направленность на конечного пользователя. Нужно заметить, что обеспечение комфортных условий для работы конечного пользователя было также основной целью разработки модели универсального отношения.

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

Документальные системы и интеграция моделей. Приведенные выше положения разрабатывались и действительно широко используются для баз данных хорошо структурированной информации. Однако уже сегодня одной из важнейших проблем становится обеспечение интеграции неоднородных информационных ресурсов, и в частности слабоструктурированных данных. Необходимость ее решения связывается со стремлением к полноценной интеграции систем баз данных в среду Web-технологий. При этом уже не достаточно простого обеспечения доступа к базе данных традиционным способом «из-под» HTML-форм. Нужна интеграция на модельном уровне. И не просто синтаксическая интеграция. В этом случае проблема семантической интероперабельности информационных ресурсов сводится к задаче разработки средств и технологий, предусматривающих явную спецификацию метаданных для ресурсов слабоструктурированных данных на основе традиционных технологий моделирования из области баз данных. Именно на достижение этой цели направлены интенсивные разработки WWW-консорциумом языка XMLи его инфраструктуры, объектной модели документов и других средств, которые, как можно ожидать, скоро станут основой технологий управления информационными ресурсами. Это направление связано с другой глобальной проблемой — организацией распределенных неоднородных информационных систем на основе построения депозитариев метаданных, обеспечивающих возможность семантического отождествления ресурсов и, таким образом, возможность их целенаправленного повторного использования.

24. Стадия проектирования и объект моделирования?

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

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

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

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

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

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

Характер взаимосвязей проявляется и в процессе проектирования системы баз данных. Модель предметной области скорее ассоциируется с неформальным уровнем семантического моделирования, а модель базы данных — с формализованным уровнем системы. В идеале целью семантического моделирования является формирование систематического основания для хорошо формализованного процесса проектирования базы данных. Здесь необходимо вспомнить следующие требования, предъявляемые кбазам данных, и, в частности, к способам описания данных:

1) описания должны быть понятны пользователю, не проектировавшему базу;

2) однажды принятые способы представления данных должны допускать присоединение новых элементов данных без изменения существующих схем данных и прикладных программ;

3) СУБД должны позволять эффективно обрабатывать произвольные запросы к базе данных.

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

Забегая несколько вперед, рассмотрим взаимосвязь двух известных методов семантического моделирования инфологического уровня — ER-диаграммы и метода нормализации, воспринимаемых зачастую как альтернативные. На самом деле нормализация с помощью хорошо формализованных методов обеспечивает декомпозицию исходных отношений большой размерности к возможно большему набору отношений, но меньшей размерности. Эти методы не зависят от особенностей предметной области, но вследствие этого и не позволяют определить исходное отношение. Для этого удобнее использовать методики, подобные ER-диаграммам — для них свойственны подходы технологии нисходящего проектирования, которые дают представление «в целом», но именно поэтому не позволяют провести полноценное проектирование базы. То есть, можно сказать, что метод нормализации и ER-диаграммы по существу являются взаимодополняющими.

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

Рассмотрим основные стадии процесса моделирования, представленные на рис. 5.1.

25. Системный анализ предметной области?

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

Главная идея процесса такого согласования состоит в том, что его надо начинать с анализа самых главных характеристик предметной области, рассматривая самые главные содержательные аспекты. И проводить его не «мысленно» и не «на словах», а на явно изложенных описаниях объектов предметной области, позволяющих видеть все существенные взаимосвязи. Однако следует отметить, что попытки использования привычных нотаций формальных моделей на этом этапе приводят к более низкому уровню представления предметной области, чем это необходимо для общего понимания.

В общем случае существуют два подхода к определению состава и структуры предметной области.

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

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

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

В [29] была предложена простая, но концептуально мощная схема, показывающая различные уровни представления архитектуры ИС, различные виды ее «обеспечения», а также их основные взаимосвязи. На рис. 5.2 показана таблица, представленная в [7], аналогичная схеме Захмана. Три столбца обозначают три раздела обеспечения системы: информационный, функциональный и коммуникационный.

 

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

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

Позднее появилось развитие такой «плоской» модели. В [28] рассматривалась схема, представленная на рис. 5.3, включающая три новых столбца, в которых отражаются еще три раздела: побудительные причины действий системы, события и графики выполнения действий, а также «действующие лица» — люди и организационные структуры.

В результате появилось шесть разделов, которые содержат «ответы на вопросы: почему выполняются действия, когда выполняются

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

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

Цель системного анализа предметной области как этапа проектирования — выделить предметную область как систему объектов и их взаимосвязей, определив при этом функционально-информационные требования к их последующему представлению в виде системы взаимосвязанных данных.

Главным результатом этапа системного анализа является определение парадигмы информационной модели: требования к средствам представления системы определяются на основании анализа уровня структурированности информации и характера восприятия ее семантики пользователем.

Например, выбор атрибутивной формы представления объектов предметной области приведет, соответственно, к выбору парадигмы фактографических баз данных, а вербальной — к необходимости выбора документальных БД.

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

26. Модели и технологии инфологического проектирования реляционных БД (инфологическое проектирование и семантическая модель, модель «Сущность- связь», ER- диаграмм, нормальные формы ER- диаграмм)?

Как отмечалось ранее, представляется вполне очевидным начинать создание базы данных с определения самих данных; выполняя проектирование базы данных в терминах отношений на основе механизма нормализации.

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

• реляционная модель не предоставляет достаточных средств для фиксации смысла данных, т. е. семантика предметной области не фиксируется непосредственно в отношениях;

• для многих приложений трудно моделировать предметную область на основе плоских таблиц;

• хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не имеет средств представления этих зависимостей;

• несмотря на то, что процесс проектирования начинается с выделения некоторых существенных для приложения объектов предметной области и выявления связей между этими сущностями, реляционная модель данных не предлагает какого-либо аппарата для различения сущностей и связей в базе данных.

На практике семантическое моделирование обычно производится на первой стадии проектирования. Полученный результат — концептуальная схема базы данных — затем вручную или автоматически преобразуется к реляционной схеме.