Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Структура данных пользователя в операционных системах и прикладных программах



Оглавление

Введение

Глава 1. Файловая система и учетные записи пользователя

1.1 Хранения данных с точки зрения операционной системы

1.2 Файловая система NTFS

1.3 Учетные записи пользователя

Глава 2. Пользовательские данные в прикладных программах

2.1 XML

2.2 Базы данных

Заключение

Список литературы



Введение

файловый пользовательский прикладной программа

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

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

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

Так же хранение пользовательских данных происходит путем разделения учетных записей. Функция UAC (User Account Control -- контроль учетных записей) -- это новый компонент системы безопасности ОС. Функция UAC позволяет пользователям выполнять стандартные задачи как в качестве пользователей, не являющихся администраторами, которые в ОС называются обычными пользователями, так и в качестве администраторов, при этом нет необходимости переключать пользователей, выходить из системы или использовать функцию "Запуск от имени". Учетная запись обычного пользователя является синонимом учетной записи пользователя в ОС. Учетные записи пользователей, являющихся членами локальной группы "Администраторы", позволяют выполнять большинство приложений в качестве обычного пользователя. Разделяя функции пользователя и администратора и позволяя при этом эффективно работать, функция UAC является важным улучшением, внесенным в ОС.

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

Цель работы: формирование способов контроля пользовательской информации.

Задачи работы:

- Анализ NTFS.

- Анализ учетных записей пользователя.

- анализ XML.

- анализ базы данных.



Глава 1. Файловая система и учетные записи пользователя

1.1 Хранения данных с точки зрения операционной системы

Операционная система хранит данные на диске в формате файловой системы.

Файловая система - порядок, определяющий способ организации, хранения и именования данных на носителях информации в компьютерах, а также в другом электронном оборудовании Файловая система Материал из Википедии -- свободной энциклопедии http://ru.wikipedia.org/wiki/Файловая_система.

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

Файловая система связывает носитель информации с одной стороны и API для доступа к файлам - с другой. Когда прикладная программа обращается к файлу, она не имеет никакого представления о том, каким образом расположена информация в конкретном файле, так же, как и на каком физическом типе носителя (CD, жёстком диске, магнитной ленте, блоке флеш-памяти или другом) он записан. Всё, что знает программа - это имя файла, его размер и атрибуты. Эти данные она получает от драйвера файловой системы. Именно файловая система устанавливает, где и как будет записан файл на физическом носителе (например, жёстком диске).

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

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

На сегодняшний день существует множество разновидностей файловых систем. Операционная система Windows по умолчанию использует NTFS (но предоставляет возможности для подключения других файловых систем), Linux другие (ext3, ext4...) и если Linux.

1.2 Файловая система NTFS

Как и любая другая система, NTFS делит все полезное место на кластеры - блоки данных, используемые единовременно. NTFS поддерживает размеры кластеров от 512 байт до 64 Кбайт, стандартным считается кластер размером 4 Кбайт. Кластер - это минимальный размер памяти, который может быть выделен для хранения одного файла.

Диск NTFS условно делится на две части (рис. 1.). Первые 12,5% диска отводятся под так называемую MFT-зону - пространство, в которое растет метафайл MFT. Запись каких-либо данных в эту область невозможна. MFT-зона всегда держится пустой - это делается для того, чтобы самый главный, служебный файл (MFT) не фрагментировался при своем росте.

Остальные 88% диска представляют собой обычное пространство для хранения файлов.



Рисунок 1. Диск в файловой системе NTFS

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

Каждый элемент системы представляет собой файл - даже служебная информация. Самый главный файл на NTFS называется MFT, или Master File Table - общая таблица файлов. Он и размещается в MFT зоне, представляя собой централизованный каталог всех остальных файлов диска, в том числе и себя самого. MFT поделен на записи фиксированного размера (обычно 1 Кбайт), каждая запись соответствует какому-либо файлу (в общем смысле этого слова). Первые 16 файлов носят служебный характер и недоступны операционной системе - они называются метафайлами, причем самый первый метафайл - сам MFT. Эти первые 16 элементов MFT - единственная часть диска, имеющая фиксированное положение. Интересно, что вторая копия первых трех записей, для надежности - они очень важны - хранится ровно посередине диска. Остальной MFT-файл может располагаться, как и любой другой файл, в произвольных местах диска - восстановить его положение можно с помощью его самого, "зацепившись" за самую основу - за первый элемент MFT.

Первые 16 файлов NTFS (метафайлы) носят служебный характер. Каждый из них отвечает за какой-либо аспект работы системы. Преимущество настолько модульного подхода заключается в поразительной гибкости - например, на FAT-е физическое повреждение в самой области FAT фатально для функционирования всего диска, а NTFS может сместить, даже фрагментировать по диску, все свои служебные области, обойдя любые неисправности поверхности - кроме первых 16 элементов MFT.

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

$MFT	сам MFT
$MFTmirr	копия первых 16 записей MFT, размещенная посередине диска
$LogFile	файл поддержки журналирования (см. ниже)
$Volume	служебная информация - метка тома, версия файловой системы, т.д.
$AttrDef	список стандартных атрибутов файлов на томе
$	корневой каталог
$Bitmap	карта свободного места тома
$Boot	загрузочный сектор (если раздел загрузочный)
$Quota	файл, в котором записаны права пользователей на использование дискового пространства (начал работать лишь в NT5)
$Secure	дескрипторы безопасности файловых объектов (права доступа)

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

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

Интересно обстоит дело и с данными файла. Каждый файл на NTFS, имеет несколько абстрактное строение - у него нет как таковых данных, а есть потоки (streams). Один из потоков и носит привычный нам смысл - данные файла. Но большинство атрибутов файла - тоже потоки! Таким образом, получается, что базовая сущность у файла только одна - номер в MFT, а всё остальное опционально. Данная абстракция может использоваться для создания довольно удобных вещей - например, файлу можно "прилепить" еще один поток, записав в него любые данные - например, информацию об авторе и содержании файла. Интересно, что эти дополнительные потоки не видны стандартными средствами: наблюдаемый размер файла - это лишь размер основного потока, который содержит традиционные данные. Можно, к примеру, иметь файл нулевой длинны, при стирании которого освободится 1 Гбайт свободного места - просто потому, что какая-нибудь хитрая программа или технология прилепила к нему дополнительный поток (альтернативные данные) гигабайтового размера. На самом деле в текущий момент потоки практически не используются, так что опасаться подобных ситуаций не следует, хотя гипотетически они возможны. Файл на NTFS - это более глубокое и глобальное понятие, чем можно себе представить просто просматривая каталоги диска. Имя файла может содержать любые символы, включая полый набор национальных алфавитов, так как данные представлены в Unicode - 16-битном представлении, которое дает 65535 разных символов. Максимальная длина имени файла - 255 символов.

Каталог на NTFS представляет собой специфический файл, хранящий ссылки на другие файлы и каталоги, создавая иерархическое строение данных на диске. Файл каталога поделен на блоки, каждый из которых содержит имя файла, базовые атрибуты и ссылку на элемент MFT, который уже предоставляет полную информацию об элементе каталога. Внутренняя структура каталога представляет собой бинарное дерево. Вот что это означает: для поиска файла с данным именем в линейном каталоге, таком, например, как у FAT-а, операционной системе приходится просматривать все элементы каталога, пока она не найдет нужный (рис. 2.). Бинарное же дерево располагает имена файлов таким образом, чтобы поиск файла осуществлялся более быстрым способом - с помощью получения двухзначных ответов на вопросы о положении файла. Вопрос, на который бинарное дерево способно дать ответ, таков: в какой группе, относительно данного элемента, находится искомое имя - выше или ниже? Мы начинаем с такого вопроса к среднему элементу, и каждый ответ сужает зону поиска в среднем в два раза. Файлы, скажем, просто отсортированы по алфавиту, и ответ на вопрос осуществляется очевидным способом - сравнением начальных букв. Область поиска, суженная в два раза, начинает исследоваться аналогичным образом, начиная опять же со среднего элемента.

Не стоит, однако думать, что в традиционных системах (FAT) всё так запущено: во-первых, поддержание списка файлов в виде бинарного дерева довольно трудоемко, а во-вторых - даже FAT в исполнении современной системы использует сходную оптимизацию поиска.



Рисунок 2. Поиск файла в файловых системах NTFS и FAT

Какую информацию можно получить, прочитав файл каталога? Ровно то, что выдает команда dir. Для выполнения простейшей навигации по диску не нужно лазить в MFT за каждым файлом, надо лишь читать самую общую информацию о файлах из файлов каталогов. Главный каталог диска - корневой - ничем не отличается об обычных каталогов, кроме специальной ссылки на него из начала метафайла MFT.

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

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

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

1.3 Учетные записи пользователя

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

С точки зрения системы, имя пользователя является ответом на вопрос: «Кто вы?». А значит, главное требование, связанное с именами пользователей -- они должны быть уникальными. Другими словами, имя каждого пользователя должно отличаться имён всех остальных пользователей данной системы.

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

Если имя пользователя даёт ответ на вопрос: «Кто вы?», пароль -- ответ на неизбежно следующее за этим требованием: «Докажите это!»

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

1. Секретность пароля

2. Устойчивость пароля к угадыванию

3. Устойчивость пароль к атаке перебором

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

Системный администратор может сам назначать пароли всем пользователям.

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

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

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

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

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



Глава 2. Пользовательские данные в прикладных программах

2.1 XML

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

Современные форматы сложных текстовых документов (docx, odt), например, представляют собой архив, в котором в определенных папках лежат файлы xml определенного формата. Рассмотрим формат подробнее.

XML (англ. eXtensible Markup Language - расширяемый язык разметки; произносится [экс-эм-эмл]) - рекомендованный Консорциумом Всемирной паутины язык разметки, фактически представляющий собой свод общих синтаксических правил. XML - текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML). XML является упрощённым подмножеством языка SGML XML Материал из Википедии -- свободной энциклопедии 4. http://ru.wikipedia.org/wiki/Xml.

Стандарт XML и родственных технологий (XSD, SOAP, XHTML…) пишется некоммерческой организацией w3c.

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

Тэг - элемент языка разметки гипертекста. В XML тег является элементом документа, а текст, содержащийся между начальным и конечным тегом - содержанием элемента. Название тэга заключается в треугольные скобки: <p>Параграф</p>. Здесь «<p>» - открывающий тэг, «</p>» - закрывающий, «Параграф» - содержимое. XML не допускает перекрывающихся элементов.

Кроме содержания у элемента могут быть атрибуты - пары имя-значение, добавляемые в открывающий тег после названия элемента. Значения атрибутов всегда заключаются в кавычки (одинарные или двойные), одно и то же имя атрибута не может встречаться дважды в одном элементе. Не рекомендуется использовать разные типы кавычек для значений атрибутов одного тега. Имена элементов, как и имена атрибутов, не могут содержать пробелы, но могут быть на любом языке, поддерживаемом кодировкой XML-документа. Имя может начинаться с подчёркивания, буквы или двоеточия. Остальными символами имени могут быть те же символы, цифры, дефис, точка.

Пример XML-документа [4]:

<?xml version="1.0" encoding="UTF-8"?>

<recipe name="хлеб" preptime="5" cooktime="180">

<title>Простой хлеб</title>

<composition>

<ingredient amount="3" unit="стакан">Мука</ingredient>

<ingredient amount="0.25" unit="грамм">Дрожжи</ingredient>

<ingredient amount="1.5" unit="стакан">Тёплая вода</ingredient>

<ingredient amount="1" unit="чайная ложка">Соль</ingredient>

</composition>

<instructions>

<step>Смешать все ингредиенты и тщательно замесить.</step>

<step>Закрыть тканью и оставить на один час в тёплом помещении.</step>

<!-- <step>Почитать вчерашнюю газету.</step> - это сомнительный шаг... -->

<step>Замесить ещё раз, положить на противень и поставить в духовку.</step>

</instructions>

</recipe>

Спецификация требует, чтобы процессоры XML обязательно поддерживали Юникод-кодировки UTF-8 и UTF-16 (UTF-32 не обязателен). Признаются допустимыми, поддерживаются и широко используются (но не обязательны) другие кодировки, основанные на стандарте ISO/IEC 8859, также допустимы другие кодировки, например, русские Windows-1251, KOI-8. Все же обычно в названии тэгов используются только латинские буквы, в этом случае UTF-8 является более удобной кодировкой - объём будет меньше, чем при UTF-16; декодирование может быть выполнено как для всего документа, так и для конкретных атрибутов и текстов; весь документ не содержит запрещённых символов при попытке разбора с неправильной кодировкой.

Важнейшее и обязательное синтаксическое требование заключается в том, что документ имеет один и только один корневой элемент (root element). Это значит, что текст и другие данные всего документа должны быть расположены между единственным начальным корневым тегом и соответствующим ему конечным тегом.

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

<foo></foo>

<foo />

<foo/>

В XML определены два метода записи специальных символов: ссылка на сущность и ссылка по номеру символа.

Сущностью (англ. entity) в XML называются именованные данные, обычно текстовые, в частности, спецсимволы. Ссылка на сущность (англ. entity references) указывается в том месте, где должна быть сущность и состоит из амперсанда (&), имени сущности и точки с запятой (;).

В XML есть несколько предопределённых сущностей, таких как lt (ссылаться на неё можно написав &lt;) для левой угловой скобки и amp (ссылка - &amp;) для амперсанда. Возможно также определять собственные сущности. Помимо записи с помощью сущностей отдельных символов, их можно использовать для записи часто встречающихся текстовых блоков Кен Хендерсон Microsoft SQL Server: структура и реализация. Профессиональное руководство. - Вильямс, 2005..

Ниже приведён пример использования предопределённой сущности для избежания использования знака амперсанда в названии:

<company-name>AT&amp;T</company-name>

Полный список предопределённых сущностей состоит из &amp; (&), &lt; (<), &gt; (>), &apos; (') и &quot; (") - последние две полезны для записи разделителей внутри значений атрибутов.

Иногда бывает необходимо определить неразрывный пробел, который очень часто используется в HTML и обозначается как &nbsp;. В XML такой предопределённой сущности нет, его записывают &#160;, а использование &nbsp; вызывает ошибку. Отсутствие этой весьма распространённой сущности у множества программистов зачастую вызывает удивление и это создаёт некоторые трудности при миграции своих HTML-разработок в XML.

Ссылка по номеру символа (англ. numeric character reference) выглядит как ссылка на сущность, но вместо имени сущности указывается символ # и число (в десятичной или шестнадцатеричной записи), являющееся номером символа в кодовой таблице Юникод.

Существуют и другие правила, касающиеся составления корректного XML-документа.

Стандартом определены два уровня правильности документа XML:

Правильно построенный (well-formed). Правильно построенный документ соответствует всем общим правилам синтаксиса XML, применимым к любому XML-документу. И если, например, начальный тег не имеет соответствующего ему конечного тега, то это неправильно построенный документ XML. Документ, который неправильно построен, не может считаться документом XML; XML-процессор (парсер) не должен обрабатывать его обычным образом и обязан классифицировать ситуацию как фатальная ошибка.

Валидный (valid). Такой документ дополнительно соответствует некоторым семантическим правилам. Это более строгая дополнительная проверка корректности документа на соответствие заранее определённым, но уже внешним правилам, в целях минимизации количества ошибок, например, структуры и состава данного, конкретного документа или семейства документов. Эти правила могут быть разработаны как самим пользователем, так и сторонними разработчиками, например, разработчиками словарей или стандартов обмена данными. Обычно такие правила хранятся в специальных файлах - схемах (XSD), где подробным образом описана структура документа, все допустимые названия элементов, атрибутов и т.п. Если документ содержит не определённое заранее в схемах название элемента, то XML-документ считается недействительным; проверяющий XML-процессор (валидатор) при проверке на соответствие правилам и схемам обязан сообщить об ошибке.

2.2 Базы данных

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

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

В базе MS SQL Server значение даты/времени хранится как 2 целых числа (каждое по 4 байта). Первое составляет количество дней с 1-го января 1900 года, 2-е - кол-во миллисекунд, прошедшее с полуночи.

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

Базы данных SQL Server содержат файлы трех типов:

1. Первичные файлы данных.

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

2. Вторичные файлы данных.

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

3. Файлы журналов.

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

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

Файлы SQL Server имеют два имени:

logical_file_name - имя, используемое для ссылки на физический файл во всех инструкциях Transact-SQL. Логическое имя файла должно соответствовать правилам для идентификаторов SQL Server и быть уникальным среди логических имен файлов в соответствующей базе данных.

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

Изначально можно указать максимальный размер каждого файла. Если максимальный размер файла не указан, файлы SQL Server могут автоматически увеличиваться в размерах, превосходя первоначально заданные показатели, пока не займет все доступное место на диске. При определении файла пользователь может указывать требуемый шаг роста. Каждый раз при заполнении файла его размер увеличивается на указанный шаг роста. Если в файловой группе имеется несколько файлов, их автоматический рост начинается лишь по заполнении всех файлов. Затем файлы увеличиваются в размерах по кольцевому списку. Эта функция особенно полезна в случаях, когда SQL Server используется в качестве базы данных, внедренной в приложение, где пользователь не имеет удобного доступа к системному администратору. По мере необходимости пользователь может предоставить файлам возможность увеличиваться в размерах автоматически, тем самым снимая с администратора часть забот по наблюдению за свободным пространством базы данных и по распределению дополнительного пространства вручную.

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

Основной единицей хранилища данных и обмена информацией между внешней и оперативной памятью в SQL Server является страница. Место на диске, предоставляемое для размещения файла данных (MDF- или NDF-файл) в базе данных, логически разделяется на страницы с непрерывным перечислением от 0 до n. Дисковые операции ввода-вывода выполняются на уровне страницы. А именно, SQL Server считывает или записывает целые страницы данных. В SQL Server размер страницы составляет 8 КБ. Это значит, что в одном мегабайте базы данных SQL Server содержится 128 страниц. Каждая страница начинается с 96-байтового заголовка, который используется для хранения системных данных о странице. Эти данные включают номер страницы, тип страницы, объем свободного места на странице и идентификатор единицы распределения объекта, которому принадлежит страница. В файлах данных базы данных SQL Server используется 8 типов страниц (данные с типами данных небольших размеров, данные с типами данных больших размеров, записи индекса, сведения о размещении экстентов, сведения о размещении страниц и доступном на них свободном месте и т. д.).

Экстент - это коллекция, состоящая из восьми физически непрерывных страниц или 64 Кб; они используются для эффективного управления страницами. Все страницы хранятся в экстентах. Таким образом, в одном мегабайте базы данных SQL Server содержится 16 экстентов.

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

Первая страница каждого файла (страница с номером 0) - это страница заголовка файла; она содержит сведения об атрибутах данного файла. Страницы с номерами 1, 2, 3 будут описаны ниже.

Таблицы и индексы хранятся в виде коллекции страниц размером 8 КБ.

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

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

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

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

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

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

SQL Server использует два типа карт для записи сведений об использовании экстентов:

Глобальная карта распределения (GAM)

На GAM-страницах записано, какие экстенты были задействованы. В каждой карте GAM содержится сведения об использовании 64 000 экстентов или о размещении почти 4 ГБ данных. В карте GAM приходится по одному биту на каждый экстент в покрываемом им интервале. Если бит равен 1, то экстент свободен; если бит равен 0, то экстент задействован.

Общая глобальная карта распределения (SGAM)

На SGAM-страницах записано, какие экстенты в текущий момент используются в качестве смешанных экстентов и имеют как минимум одну неиспользуемую страницу. В каждой карте SGAM содержится сведения об использовании 64 000 экстентов или о размещении почти 4 ГБ данных. В карте SGAM приходится по одному биту на каждый экстент в покрываемом им интервале. Если бит равен 1, то экстент используется как смешанный экстент и имеет свободную страницу. Если бит равен 0, то экстент не используется как смешанный экстент, или он является смешанным экстентом, но все его страницы используются.

Это дает простые алгоритмы управления экстентами страниц. Для использования для хранения объекта однородного экстента компонент СУБД Database Engine производит на карте GAM поиск бита 1 и заменяет его на бит 0. Для поиска смешанного экстента со свободными страницами компонент Database Engine производит поиск на карте SGAM бита 1. Для размещения смешанного экстента компонент Database Engine производит на карте GAM поиск бита 1 и заменяет его на бит 0, а затем устанавливает значение соответствующего бита на карте SGAM равным 1. Для освобождения экстента компонент Database Engine устанавливает бит GAM равным 1, а соответствующий бит SGAM равным 0. Внутренние алгоритмы, которые на самом деле используются компонентом Database Engine, более сложны, чем это описано в данном подразделе, так как компонент Database Engine распространяет данные в базе данных равномерно. Однако даже настоящие алгоритмы упрощаются из-за того, что отпадает необходимость управления цепочками сведений о размещении экстентов.

На страницы PFS (Page Free Space) записывается состояние размещения каждой страницы, информация о том, была ли отдельная страница использована или нет, а также количество свободного места на каждой странице. В PFS на каждую страницу приходится по одному байту, хранящему информацию о том, была ли страница использована или нет, а если была - то пустая она, или ее заполнение находится в промежутке от 1 до 50 процентов, от 51 до 80 процентов, от 81 до 95 процентов или от 96 до 100 процентов.

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

PFS-страница является первой страницей после страницы заголовка файла в файле данных (страница номер 1). Потом следует GAM-страница (страница номер 2), а затем SGAM-страница (страница номер 3). После первой PFS-страницы находится PFS-страница размером примерно 8 000 страниц. После первой GAM-страницы на странице 2 находится другая GAM-страница с 64 000 экстентов и другая SGAM-страница с 64 000 экстентов находится после первой SGAM-страницы на странице номер 3.



Заключение

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

Несмотря на то что доступ к метафайлам весьма затруднен все таки возможно получение информации из них. Наиболее ценными метафайлами являются: $Boot и $Quota.

Метафайл $Boot содержит код загрузки (bootstrap code) и сведения о геометрии диска. Структура boot-сектора определяется архитектурными особенностями конкретной файловой системы, тем самым в случае воздействия на метафайл $Boot есть вероятность изменения информации которая в нем хранится, что в свою очередь отразится на корректности загрузки операционной системы или привести к полному отказу загрузки операционной системы.

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

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

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

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

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



Список литературы

1. Джон Савилл Microsoft Windows XP/2000. Вопросы и ответы. - Вильямс. 2004.

2. Карпова Т. С. Базы данных: модели реализация - СПб: Питер, 2001.

3. Кен Хендерсон Microsoft SQL Server: структура и реализация. Профессиональное руководство. - Вильямс, 2005.

4. Хелен Кастер Основы Windows NT и NTFS 1996.

5. Хомоненко. А.Д. Базы данных: Учебник для высших учебных заведений. - СПб: КОРОНА принт, 2000.

6. Хоторн Роб «Разработка баз данных, Micrososoft SQL Server 2000». - Вильямс, 2001.

7. Файловая система Материал из Википедии -- свободной энциклопедии http://ru.wikipedia.org/wiki/Файловая_система.

8. XML Материал из Википедии -- свободной энциклопедии http://ru.wikipedia.org/wiki/Xml.

Размещено на Allbest.ru

...