Что такое даталогическая модель

Даталогическая модель данных

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

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

Модели, основанные на языках разметки документов, связаны прежде всего со стандартным общим языком разметки — SGML (Standart Generalised Markup Language), который был утвержден ISO в качестве стандарта еще в 80-х годах.

Этот язык предназначен для создания других языков разметки, он определяет допустимый набор тегов (ссылок), их атрибуты и внутреннюю структуру документа. Контроль за правильностью использования тегов осуществляется при помощи специального набора правил, называемых DTD-описаниями, которые используются программой клиента при разборе документа. Для каждого класса документов определяется свой набор правил, описывающих грамматику соответствующего языка разметки. С помощью SGML можно описывать структурированные данные, организовывать информацию, содержащуюся в документах, представлять эту информацию в некотором стандартизованном формате. Но ввиду некоторой своей сложности SGML использовался в основном для описания синтаксиса других языков (наиболее известным из которых является HTML), и немногие приложения работали с SGML-документами напрямую.

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

Однако HTML сегодня уже не удовлетворяет в полной мере требованиям, предъявляемым современными разработчиками к языкам подобного рода. И ему на смену был предложен новый язык гипертекстовой разметки, мощный, гибкий и, одновременно с этим, удобный язык XML. В чем же заключаются его достоинства?

XML (Extensible Markup Language) — это язык разметки, описывающий целый класс объектов данных, называемых XML-документами. Он используется в качестве средства для описания грамматики других языков и контроля за правильностью составления документов. То есть сам по себе XML не содержит никаких тегов, предназначенных для разметки, он просто определяет порядок их создания.

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

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

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

1.4. Последовательность создания информационной модели данных

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

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

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

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

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

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

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

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

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

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

Источник

Проектирование реляционных БД на основе принципов нормализации

Даталогическое проектирование

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

Корректной назовем схему БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений.

Процесс разработки корректной схемы реляционной БД называется логическим проектированием БД.

Проектирование схемы БД может быть выполнено двумя путями:

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

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

В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

Основные свойства нормальных форм:

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

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

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

Приведем ряд основных определений.

,

что читается следующим образом:

В общем случае в отношении может быть несколько возможных ключей.

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

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

Взаимно-независимые атрибуты — это такие атрибуты, которые не зависят функционально один от другого.

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

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

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

Для приведения отношения «Расписание» к первой нормальной форме необходимо дополнить каждую строку фамилией преподавателя.

Источник

Данные и ЭВМ

Вы будете перенаправлены на Автор24

Уровни описания данных

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

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

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

Инфологическая модель данных

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

Готовые работы на аналогичную тему

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

Даталогическая модель данных

Даталогическая модель для примера 1 будет выглядеть, как показано на следующем рисунке:

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

Физическая модель данных

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

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

Источник

Даталогичсекие модели данных

ВЛАДИМИРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Имени Александра Григорьевича и Николая Григорьевича Столетовых

КАФЕДРА БИЗНЕС-ИНФОРМАТИКИ И ЭКОНОМИКИ

по дисциплине «Базы данных»

Диаграмма Бахмана

Выполнил:

Принял:

Владимир 2016

План

1. Даталогические модели

2. Физические модели

II. Инфологические модели

III. Модель Бахмана

Введение

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

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

Система управления базами данных (СУБД) — совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.

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

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

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

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

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

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

Одним из способов представления формализованного описания предметной области информационной системы в рамках модели «объекты-связи» является использование техники специальных диаграмм, которая была предложена известным американским специалистом в области баз данных Ч. Бахманом.

Целью моего реферата является изучение диаграммы Бахмана.

1. Рассмотреть инфологические модели в целом

2. Конкретно перейти к диаграмме Бахмана

3. Выделить ее положительные и отрицательные сторон

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

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

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

Тем не менее, длительное время термин «модель данных» использовался без формального определения. Одним из первых специалистов, который достаточно формально определил это понятие, был Э. Кодд. В статье «Модели данных в управлении базами данных» он определил модель данных как комбинацию трёх компонентов:

· коллекции типов объектов данных, образующих базовые строительные блоки для любой базы данных, соответствующей модели;

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

· коллекции операций, применимых к таким экземплярам объектов для выборки и других целей

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

Даталогичсекие модели данных

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

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

Документальные модели

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

Ориентированные на формат документа

Модели, ориентированные на формат документа, основаны на языках разметки документов и связаны прежде всего со стандартным общим языком разметки – SGML, который был утвержден ISO в качестве стандарта еще в 80-х годах.

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

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

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

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

Фактографические модели

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

К фактографическим моделям относятся: иерархические, сетевые, реляционные, объектно-ориентированные модели.

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

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

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

1. Иерархическая модель

Иерархическая модель данных является наиболее простой среди всех даталогических моделей. Исторически она появилась первой среди всех даталогических моделей. Типичным представителем иерархической модели данных является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 году. До сих пор поддерживается много баз данных, что создает существенные проблемы с переходом, как на новую технологию баз данных, так и на новую технику.

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

Иерархия проста и естественна в отображении взаимосвязи между классами объектов.

Стандарт сетевой модели впервые был определен в 1975 году организациейCODASYL(ConferenceofDataSystemLanguages), которая определила базовые понятия модели и формальный язык описания. Еще одним типичным представителем является Integrated Database Management System (IDMS) компании Cullinet Software, Inc. (1972 г.), предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем.

Базовыми объектами модели являются:

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

— объекты, обладающие внутренней структурой и однозначно идентифицируемые уникальным внутрисистемным ключом;

— классы, являющиеся по сути типами объектов;

— операции над объектами одного или разных типов, называемые «методами»;

— наследуемость внешних свойств объектов на основе соотношения «класс-подкласс».

К достоинствам объектно-ориентированной модели обычно относят:

— возможность для пользователя системы определять свои сколь угодно сложные типы данных (используя имеющийся синтаксис и свойства наследуемости и инкапсуляции);

— наличие наследуемости свойств объектов;

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

К недостаткам объектно-ориентированной модели можно отнести:

— отсутствие строгих определений; разное понимание терминов и различия в терминологии;

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

Физические модели данных

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

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

Модели, основанные на файловых структурах

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

Модели, основанные на странично-сегментной организации

Для каждого сегмента поддерживается таблица страниц.

Номер записи в таблице страниц соответствует номеру виртуальной страницы. Размер записи колеблется от системы к системе, но чаще всего он составляет 32 бита. Из этой записи в таблице страниц находится номер кадра для данной виртуальной страницы, затем прибавляется смещение и формируется физический адрес. Помимо этого запись в таблице страниц содержит информацию об атрибутах страницы. Это биты присутствия и защиты (например, 0 – read/write, 1 – read only. ). Также могут быть указаны: бит модификации, который устанавливается, если содержимое страницы модифицировано, и позволяет контролировать необходимость перезаписи страницы на диск; бит ссылки, который помогает выделить малоиспользуемые страницы; бит, разрешающий кэширование, и другие управляющие биты. Адреса страниц на диске не являются частью таблицы страниц.

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

Источник