Файловые системы

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

Первичными компонентами данных являются знаки (символы) естественного языка или их кодированное представление в виде строки двоичных битов.

Наименьшей семантической поименованной единицей данных является элемент данных: например, № телефона – последовательность цифр, ФИО – последовательность символов.

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

Файл – поименованный набор записей одного типа на внешнем устройстве.

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

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

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

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

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

Как работали раньше: есть задача – пишем программу, которая использует какие-то данные.

Схематично:

· Данные вводятся или формируются во время выполнения программы (однодневка)

· Данные вводятся или записываются в файл

Как происходит обработка:

1. Пользователь формирует запрос на получение необходимых данных

2. Приложение обрабатывает запрос в соответствии со структурой данных

3. ОС, в состав которой входит ФС,

a. находит нужный файл на диске,

b. выбирает требуемый байт или байты,

т.е. формирует запрос в терминах носителя

4. Извлеченные данные поступают в приложение, которое обрабатывает их и передает пользователю.

Недостатки ФИС

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

В качестве примера рассмотрим ситуацию, существующую в Зеленчукской астрофизической лаборатории. В этой лаборатории в горах в районе Нижнего Архыза установлен один из крупнейших в мире зеркальных телескопов (диаметр зеркала - 6 метров). Уникальные природные условия этого района Северного Кавказа позволяют максимально эффективно использовать возможности обсерватории. В самом Зеленчуке имеется крупнейший в России радиотелескоп. Комбинированное использование этих ресурсов в течение многих лет (более 10) позволило астрофизикам накопить уникальную информацию относительно разного рода космических объектов. К сожалению, компьютерные возможности лаборатории в первые годы ее существования были весьма ограничены, и поэтому накапливаемые данные хранились в основном на магнитных лентах. Известно, что любой магнитный носитель стареет, а магнитные ленты еще и пересыхают. В результате основной проблемой группы поддержки информационных ресурсов уже несколько лет является копирование старых магнитных лент на новые носители. Старые ленты часто не читаются, и приходится тратить громадные усилия и средства для их реанимирования.

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

2. Полная зависимость данных от программ. Изменения структуры данных влечет необходимость перепрограммирования всех задач. Например:

· личное дело (сведения о сотруднике) – добавили ИНН, № страхового полиса;

· изменение зарплаты (сотни, твсячи, мтллионы)

· изменение кол-ва цифр в № телефона.

3. Неудобство при хранении данных, обладающих разными структурами.

· Избыточность данных (дублирование). Из одних и тех же данных формируются файлы для разных приложений. Например, приложение, связанное с учетом персонала, и приложение, связанное с обучением персонала компании, могут иметь свои собственные файлы, в которых часть информации одинаковая (ФИО, отдел и т.д.). Другой пример: Экзаменационная ведомость и список на получение стипендии(№ з/к, ФИО, группа, курс).

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

4. Возможная противоречивость информации (ошибки): в одном файле служащий Е3 работает в отделе Д8, в другом – в отделе Д5.

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

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

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

1. Разработка ПО, имеющего единый интерфейс для всех пользователей и способного обеспечить безопасность и целостность данных (Точность, согласованность, достоверность) Þ СУБД.

2. Концепция АБД – для организации централизованного управления.

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

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

· выдавать списки сотрудников по отделам,

· поддерживать возможность перевода сотрудника из одного отдела в другой,

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

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

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

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

Полное имя сотрудника (ИМЯ), номер его удостоверения (НОМЕР), информацию о его соответствии занимаемой должности (для простоты, "да" или "нет") (СТАТ), размер зарплаты (ЗАРП), номер отдела (ОТД_НОМЕР). Поскольку мы хотим ограничиться одним файлом, та же запись должна содержать имя руководителя отдела (ОТД_РУК).

СОТР (ИМЯ, НОМЕР, СТАТ, ЗАРП, ОТД_НОМЕР, ОТД_РУК)

Функции нашей информационной системы требуют, чтобы:

· обеспечивалась возможность многоключевого доступа к этому файлу по уникальным ключам (недублируемым в разных записях) ИМЯ и НОМЕР.

· Кроме того, должна обеспечиваться возможность выбора всех записей с общем значением ОТД_НОМЕР, то есть доступ по неуникальному ключу.

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

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

· во-первых, требует создания достаточно сложной надстройки для многоключевого доступа к файлам,

· во-вторых, вызывает требование существенной избыточности хранения (для каждого сотрудника одного отдела повторяется имя руководителя,)

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

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

Первое, что приходит на ум, - это поддерживать два многоключевых файла: СОТРУДНИКИ и ОТДЕЛЫ. Первый файл должен содержать поля СОТР(ИМЯ, НОМЕР, СТАТ, ЗАРП, ОТД_НОМЕР), а второй –

ОТД (ОТД_НОМЕР, ОТД_РУК, ОТД_ЗАРП, ОТД_РАЗМЕР), где

ОТД_ЗАРП (общий размер зарплаты) и ОТД_РАЗМЕР (общее число сотрудников в отделе).

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

Прежде всего, система должна теперь знать, что она работает с двумя информационно связанными файлами (это шаг в сторону схемы базы данных), должна знать структуру и смысл каждого поля (например, что ОТД_НОМЕР в файле СОТРУДНИКИ и ОТД_НОМЕР в файле ОТДЕЛЫ означают одно и то же), а также понимать, что в ряде случаев изменение информации в одном файле должно автоматически вызывать модификацию во втором файле, чтобы их общее содержимое было согласованным. Например, если на работу принимается новый сотрудник, то необходимо добавить запись в файл СОТРУДНИКИ, а также соответствующим образом изменить поля ОТД_ЗАРП и ОТД_РАЗМЕР в записи файла ОТДЕЛЫ, описывающей отдел этого сотрудника.

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

Но это еще не все, что обычно требуют от СУБД. Во-первых, даже в нашем примере неудобно реализовывать такие запросы как "выдать общую численность отдела, в котором работает Петр Иванович Сидоров".

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

SELECT ОТД_РАЗМЕР

FROM СОТРУДНИКИ, ОТДЕЛЫ

WHERE ИМЯ = "ПЕТР ИВАНОВИЧ СИДОРОВ"

AND ОТД_НОМЕР = ОТД_НОМЕР

Таким образом, при формулировании запроса СУБД позволит не задумываться о том, как будет выполняться этот запрос. Среди ее метаданных будет содержаться информация о том, что поле ИМЯ является ключевым для файла СОТРУДНИКИ, а ОТД_НОМЕР - для файла ОТДЕЛЫ, и система сама воспользуется этим. Если же возникнет потребность в получении списка сотрудников, не соответствующих занимаемой должности, то достаточно предъявить системе запрос

SELECT ИМЯ, НОМЕР

FROM СОТРУДНИКИ

WHERE СТАТ = "НЕТ",

и система сама выполнит необходимый полный просмотр файла СОТРУДНИКИ, поскольку поле СТАТ не является ключевым (не надо реструктизировать).

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

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

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

Приложения 2 типов:

· Написанные пользователем – профессиональным прикладным программистом (на алгоритмическом языке или языке СУБД);

· Поставляемые разработчиком – инструментальные средства.

СУБД – промежуточное звено, которое хранит информацию о структуре данных.

Обработка запроса:

1. пользователь вводит запрос на доступ к определенным данным. Например, вычислить среднее значение суммы сделок по заказам от такого-то числа. Это может быть программ на алгоритмическом языке или запрос на SQL).

2. СУБД перехватывает и анализирует его:

· Просматривает БД,

· Выбирает с диска каждую запись, удовлетворяющую заданным условиям,

· Вычисляет среднее значение.

3. отображает результаты на экран или передает приложению.

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

Преимущества СУБД, связанные с централизованным управлением.

1. Сокращение избыточности.

2. Возможность устранения противоречивости (следствие 1). Если какой-либо факт представлен одной записью, то противоречий нет.

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

4. Возможность общего доступа к данным из различных приложений.

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

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

a. Защищены от хищения, искажения и других форм разрушения,

b. Восстанавливаемыми в результате различных сбоев,

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

7. Возможность обеспечения целостности данных (точность и непротиворечивость). Например:

a. противоречие между 2 записями Е3®Д8, Е3®Д3;

b. неправильная информация Е3®Д8, а Д8 не сущемтвует;

c. сотрудник работает 400 часов вместо 40

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

9. Возможность независимости данных от приложений (иммунитет приложений к изменениям в структуре хранения и в методах доступа к ним) – основное преимущество. Это связано с тем, что форма физического хранения отличается от их логического представления. Логическое представление – как данные видит программист (например, баланс заказчика – в десятичном формате). Физическое – как данные хранятся (в двоичном виде в упакованном формате).

БД – неотъемлемая часть любой ИС. Тип используемой БД определяется масштабом ИС. В зависимости от масштаба различают 3 группы ИС:

Малые (одиночные)	Групповые	Корпоративные
Как правило, используются на автономном компьютере. ИС содержит несколько простых приложений, связанных общей информацией. Сеть не используется. Приложения создаются с помощью локальных СУБД: FoxPro, Access, Clipper, Paradox, dBase, Clarion.	Ориентированы на коллективное использование информации всеми членами рабочей группы. Чаще всего строятся на базе локальной ВС. При разработке приложений используются серверы БД (SQL - серверы): SQL – сервер, Oracle, DB2, InterBase, Sybase, MS SQL – сервер.	Развитие систем для рабочих групп. Ориентированы на крупные компании. Могут поддерживать территориально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Характерна архитектура «клиент – сервер» со специализацией серверов или же многоуровневая архитектура. Используются, в основном, те же серверы БД, что и для групповых.

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

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

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

Сервер – компьютер, подключенный к сети и обеспечивающий её пользователей определенными услугами (источник ресурсов сети; может осуществлять хранение данных, управление БД, удаленную обработку заданий, их печать и т.д.). Мощные многопользовательские ПК в ВС. Выделяются для обработки запросов от всех пользователей сети.

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

Классификация по способу организации

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

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

Традиционным методом организации информационных систем является двухзвенная архитектура "клиент-сервер.

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

Помимо хранения централизованной БД сервер БД должен обеспечивать выполнение основного объёма обработки данных. На сервере – сама БД + СУБД; обработка и хранение. Запрос на данные, которые выдает клиент (РС), порождает:

· Поиск и извлечение данных на сервере, т.е. ядро БД на сервере обрабатывает запрос и просматривает БД, которая расположена там же; (Запрос на вычисление средней стоимости заказов передается по сети на сервер БД, ядро БД на сервере просматривает БД и вычисляет среднее значение);

· Извлеченные данные (не файлы) или результаты передаются клиенту (вычисленное среднее значение отображается на экране).

· Спецификой данной архитектуры является использование языка запросов SQL.

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

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

Чтобы понять ограничения различных архитектур ИС, выделим типовые функциональные компоненты:

Обозначение	Наименование	Характеристика
PS	Presentation Services (средства представления)	Обеспечиваются устройствами, принимающими ввод от пользователя и отображающими то, что сообщает ему компонент логики представления, с использованием соответствующей программной поддержки
PL	Presentation Logic (логика представления)	Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя при выборе команды меню, нажатии кнопки или выборе элемента из списка
BL	Business or Application Logic (прикладная логика)	Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение
DL	Data Logic (логика управления данными)	Операции с БД (SQL- операторы), которые нужно выполнить для реализации прикладной логики управления данными
DS	Data Services (операции с базами данных)	Действия СУБД, вызываемые для выполнения логики управления данными, такие как манипулирование данными, определение данных, фиксация или откат транзакций и т.д СУБД обычно компилирует SQL - предложения
FS	File Services (файловые операции)	Дисковые операции чтения и записи для данных СУБД. Обычно – функции ОС

Дата добавления: 2014-01-11