Иллюстрация атрибутов файла

Атрибут	Значение
Защита	Кто и каким образом может получить доступ к файлу
Пароль	Пароль для получения доступа к файлу
Создатель	Идентификатор создателя файла
Владелец	Текущий владелец
Флаг «только для чтения»	0 - для чтения-записи; 1 - только для чтения
Флаг «скрытый»	0 - обычный; 1 - не предназначенный для отображения в перечне файлов
Флаг «системный»	0 - обычный; 1 - системный
Флаг «архивный»	0 - прошедший резервное копирование;
	1 - нуждающийся в резервном копировании
Флаг ASCII-двоичный	0 -ASCII; 1 - двоичный
Флаг произвольного доступа	0 - только последовательный доступ; 1 - произвольный доступ
Флаг «временный»	0 - обычный; 1 - удаляемый по окончании работы процесса
Флаги блокировки	0 - незаблокированный; ненулевое значение - заблокированный
Длина записи	Количество байтов в записи
Позиция ключа	Смещение ключа внутри каждой записи
Длина ключа	Количество байтов в поле ключа
Время создания	Дата и время создания файла
Время последнего доступа	Дата и время последнего доступа к файлу
Время последних изменений	Дата и время внесения в файл последних изменений
Текущий размер	Количество байтов в файле
Максимальный размер	Количество байтов, до которого файл может увеличиваться

Физический уровень ФС имеет дело с физической структурой файлов. Если рассматривать файлы, например, на накопителе на жестких дисках, то:

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

· дескриптор диска содержит информацию о количестве и размере блоков на диске и о свободном пространстве на диске;

· дисковое пространство распределяется единицами фиксированной длины, даже если допускается чтение/запись блоками переменной длины, размер единицы распределения, как правило, все равно фиксирован, например, дорожка. Возможно объединение нескольких смежных блоков в единиц распределения «кластер». Кластеризация может быть как симметричной - с заранее установленным размером кластера, так и асимметричной - с размером кластера, выбираемым для каждого распределения.

Для иллюстрации рассматриваются системные вызовы для работы с файлами.

Create (Создать). Создает файл без данных. Цель вызова состоит в объявлении о появлении нового файла и в установке ряда атрибутов.

Delete (Удалить). Когда файл больше не нужен, его нужно удалить, чтобы освободить дисковое пространство. Именно для этого и предназначен этот системный вызов.

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

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

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

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

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

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

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

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

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

Основная литература

Учебник / Учебное пособие	Раздел	Страницы
Таненбаум Э. Современные операционные системы. 3-е изд. - СПб.: Питер, 2010. - 1120 е.: ил.	3.1-3.5, 3.8 3.3, 3.4, 3.5 4.1.1-4.1.6, 4.2.1-4.2.4, 4.3.4-4.3.7	217-275, 230 – 275 308-316, 320-325, 336-345

Дополнительная литература.

Учебник / Учебное пособие	Раздел	Страницы
1. Джеффри Рихтер. Windows для профессионалов (программирование в Win32 API для Windows NT 3.5 и Windows95)/Пер. с англ. - М.: Издательский отдел «Русская Редакция» 1995. - 720 с.: ил.	Главы 4, 6 Глава 13	75-97, 135-156, 437-494
2. Робачевский А.М. Операционная система UNIX, СПб.: BHV – Санкт-Петербург, 1997. - 528 с., ил.	Глава 2,3	121-144, 206-210, 280-318

Тема 5. Управление данными в СУБД. Концепции и архитектура СУБД. Представление пользователя Организация баз данных

Лекция №5. Концепции и архитектура СУБД

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

· Концепции СУБД.

· Компоненты баз данных: данные, программное обеспечение, оборудование, персонал.

· Цикл жизни базы данных.

· Архитектура СУБД.

· Словарь данных. Языки ЯОД и ЯМД: назначение и функции.

· Индексирование и доступ к данным.

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

· Архитектуры файловый сервер, удаленный доступ, «клиент-сервер», сервер базы данных, сервер приложений;

· Функциональные возможности современных СУБД на примере SQL Server.

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

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

Другими словами это означает, что в рамках СУБД:

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

· содержатся метаданные, описывающие элементы данных и их взаимосвязи;

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

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

· иерархические СУБД (HDBMS), в которых связи между объектами представляются в виде древовидных структур, где связь является строгой иерархией родитель-потомки и указывается с помощью логического адреса;

· сетевые СУБД, в которых связи между объектами представляются с помощью сетевых структур, где связи могут быть определены между произвольными объектами, но также с помощью логических адресов;

· реляционные СУБД (RDBMS), в которых связи между объектами представляются и с помощью табличных структур таким же образом, как и объекты, и при этом ассоциативно ( по значению атрибутов );

· объектно-реляционные СУБД (ОРСУБД), или Object-Relational DBMS (ORDBMS), которые для отображения связей между данными используют и объектный, и реляционный подход.

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

Описание логической организации данных при реализации в реляционной СУБД осуществляется на высокоуровневом декларативном (непроцедурном) языке описания данных (ЯОД), или Data Definition Language (DDL).

Процесс проектирования, реализации и поддержания системы базы данных называется жизненным циклом базы данных.

Классическими этапами проектирования и разработки БД являются:

· сбор сведений о предметной области - анализ потребностей и описание предметной области с использованием "процессного" подхода ("usage perspective") и "непроцессного" подхода ("information structure perspective");

· выбор языка представления модели предметной области для построения модели БД на уровне понятий (концептуальной модели);

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

· построение схемы БД;

· выбор конкретной модели данных и СУБД для реализации БД;

· проектирование логической схемы БД;

· разработка физической структуры БД: "физической" или "внутренней" схемы, "схемы размещения" для распределенной БД;

· разработка технологии и процедур начального создания и заполнения БД;

· разработка технологии и процедур сопровождения БД;

· разработка пользовательских интерфейсов для доступа к БД;

· информационная поддержка, обеспечение метаинформации, контрольные примеры и пр.;

· получение обратной связи от разработчиков прикладных программ и пользователей о полноте и эффективности использования БД;

· тестирование БД, ее развитие.

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