Министерство образования и науки Российской Федерации
Государственное образовательное учреждение высшего профессионального образования
«Рыбинская государственная авиационная технологическая академия имени »
Информационное обеспечение, базы данных
Составил: д. т.н.
Рыбинск
2010
Содержание
Введение. 5
1 Информационное обеспечение. 7
1. Потребности информационных систем.. 10
2. Организация баз данных. 15
2.1. Предметная область. 15
2.2. Типовая организация и функции СУБД. 17
2.2.1. Непосредственное управление данными во внешней памяти. 18
2.2.2. Управление буферами оперативной памяти. 18
2.2.3. Управление транзакциями. 19
2.2.4. Журнализация. 20
2.2.5. Поддержка языков БД.. 22
2.3. Типовая организация современной СУБД. 23
3. Модели данных. 25
3.1. Системы управления файлами. 25
3.2. Иерархические СУБД. 26
3.3. Сетевые базы данных. 29
3.4. Реляционная модель данных. 30
3.4.1. Таблицы.. 31
3.4.2. Первичные ключи. 33
3.4.3. Отношения предок/потомок. 35
3.4.4. Двенадцать правил Кодда. 37
3.5. Постреляционная модель данных. 40
3.6. Многомерная модель. 42
4. Вопросы физической организации баз данных. 47
4.1. Хранение отношений. 49
4.2. Индексы.. 51
4.3. B-деревья. 52
4.4. Хеширование. 55
4.5. Журнальная информация. 56
4.6. Служебная информация. 57
5. Распределенные БД.. 57
5.1. Разновидности распределенных систем. 58
5.2. Распределенная система управления System R*. 58
5.3. Именование объектов и распределенный каталог 62
5.4. Распределенная компиляция запросов. 64
5.5. Управление транзакциями и синхронизация. 65
5.6. Интегрированные системы и мульти - базы данных. 68
6. Архитектура клиент-сервер. 69
7. Структурированный язык запросов SQL.. 71
8. Проектирование реляционных баз данных. 75
8.1. Проектирование реляционных баз данных с использованием нормализации 76
8.1.1. Вторая нормальная форма. 78
8.1.2. Третья нормальная форма. 80
8.1.3. Нормальная форма Бойса-Кодда. 81
8.1.4. Четвертая нормальная форма. 83
8.1.5. Пятая нормальная форма. 85
8.1.6. Семантическое моделирование данных, ER-диаграммы.. 86
8.2. Семантические модели данных. 87
8.2.1. Модель Entity-Relationship (Сущность-Связи) 88
8.2.2. Нормальные формы ER-схем. 90
8.2.3. Более сложные элементы ER-модели. 90
8.2.4. Получение реляционной схемы из ER-схемы.. 91
8.2.5. Альтернативные модели сущностей. 94
9. Системы управления базами данных следующего поколения. 94
9.1. Ориентация на расширенную реляционную модель. 95
9.2. Абстрактные типы данных. 97
9.3. Генерация СУБД, ориентированных на приложения. 98
9.4. Оптимизация запросов, управляемая правилами. 100
9.5. Историческая информация и временные запросы.. 102
10. Объектно-ориентированные СУБД.. 103
10.1. Связь объектно-ориентированных СУБД с общими понятиями объектно-ориентированного подхода. 104
10.2. Объектно-ориентированные модели данных. 107
10.3. Языки объектно-ориентированных баз данных. 111
10.4. Языки запросов объектно-ориентированных баз данных. 114
10.5. Примеры объектно-ориентированных СУБД. 118
10.5.1. Проект ORION.. 118
10.5.2. Проект O2. 120
11. СУБД, основанные на правилах. 121
11.1. Экстенсиональная и интенсиональная части БД. 122
11.2. Активные базы данных. 122
11.3. Дедуктивные базы данных. 124
12. Литература. 125
Введение
Информационное обеспечение является не только важным, но и необходимым фактором для создания и функционирования эффективной системы качества на любом предприятии. Многие не без оснований связывают его с возможностями использования современной вычислительной техники. Она позволяет проводить подробное и единообразное документирование всех процессов, проводимых в рамках функционирования предприятия. Кроме того, она позволяет оперативно получать и обрабатывать информацию, связанную с изменением законодательства, запросов потребителя, требований общества и т. п.
С самого начала развития вычислительной техники образовались два основных направления ее использования. Первое направление – применение вычислительной техники для выполнения численных расчетов, которые слишком долго или вообще невозможно производить вручную. Становление этого направления способствовало интенсификации методов численного решения сложных математических задач, развитию класса языков программирования, ориентированных на удобную запись численных алгоритмов, становлению обратной связи с разработчиками новых архитектур ЭВМ. Второе направление, которое непосредственно связано с функционированием системы качества, это использование средств вычислительной техники в автоматических или автоматизированных информационных системах. В самом широком смысле информационная система представляет собой программный комплекс, функции которого состоят в поддержке надежного хранения информации в памяти компьютера, выполнении специфических для данного приложения преобразований информации и/или вычислений, предоставлении пользователям удобного и легко осваиваемого интерфейса. Обычно объемы информации, с которыми приходится иметь дело таким системам, достаточно велики, а сама информация имеет достаточно сложную структуру. Классическими примерами информационных систем являются банковские системы, системы резервирования авиационных или железнодорожных билетов, мест в гостиницах и т. д. На самом деле, второе направление возникло несколько позже первого. Это связано с тем, что на заре вычислительной техники компьютеры обладали ограниченными возможностями в части памяти. Понятно, что можно говорить о надежном и долговременном хранении информации только при наличии запоминающих устройств, сохраняющих информацию после выключения электрического питания. Оперативная память этим свойством обычно не обладает. В начале использовались два вида устройств внешней памяти: магнитные ленты и барабаны. При этом емкость магнитных лент была достаточно велика, но по своей физической природе они обеспечивали последовательный доступ к данным. Магнитные же барабаны (они больше всего похожи на современные магнитные диски с фиксированными головками) давали возможность произвольного доступа к данными, но были ограниченного размера. Легко видеть, что указанные ограничения не очень существенны для чисто численных расчетов. Даже если программа должна обработать (или произвести) большой объем информации, при программировании можно продумать расположение этой информации во внешней памяти, чтобы программа работала как можно быстрее. С другой стороны, для информационных систем, в которых потребность в текущих данных определяется пользователем, наличие только магнитных лент и барабанов неудовлетворительно. Представьте себе покупателя билета, который стоя у кассы должен дождаться полной перемотки магнитной ленты. Одним из естественных требований к таким системам является средняя быстрота выполнения операций.
Считается, что именно требования к вычислительной технике со стороны нечисленных приложений вызвали появление съемных магнитных дисков с подвижными головками, что явилось революцией в истории вычислительной техники. Эти устройства внешней памяти обладали существенно большей емкостью, чем магнитные барабаны, обеспечивали удовлетворительную скорость доступа к данным в режиме произвольной выборки, а возможность смены дискового пакета на устройстве позволяла иметь практически неограниченный архив данных.
С появлением магнитных дисков началась история систем управления данными во внешней памяти. До этого каждая прикладная программа, которой требовалось хранить данные во внешней памяти, сама определяла расположение каждой порции данных на магнитной ленте или барабане и выполняла обмены между оперативной и внешней памятью с помощью программно-аппаратных средств низкого уровня (машинных команд или вызовов соответствующих программ операционной системы). Такой режим работы не позволяет или очень затрудняет поддержание на одном внешнем носителе нескольких архивов долговременно хранимой информации. Кроме того, каждой прикладной программе приходилось решать проблемы именования частей данных и структуризации данных во внешней памяти. Одним из направлений функционирования информационных систем является хранение и обработка информации в виде баз данных.
1 Информационное обеспечение
Функционирование системы менеджмента качества любого предприятия представляет собой совокупность процессов информационного взаимодействия различных подразделений в рамках определенной деятельности. Поэтому значение информации в системе менеджмента качества трудно переоценить. Это и многочисленная документация: распорядительные документы, отчетная документация, статистическая документация, технологическая документация и т. д. Для реализации информационного взаимодействия требуются определенные средства. Средства и методы удовлетворения информационных потребностей организации называются информационным обеспечением. Информационное обеспечение включает в себя три основные составляющие:
- технические средства;
- информационный персонал;
- методы управления информацией.
К техническим средствам относится вся «аппаратная» часть управления информацией. Распространенным заблуждением является мнение, что к техническим средствам относится только вычислительная техника. Проблема информационного обеспечения возникла задолго до её появления. Таким образом, бумага и карандаш также относятся к техническим средствам информационного обеспечения (без которых, кстати, не обойтись и на самом современном предприятии). Компьютеры являются лишь наиболее предпочтительной формой технической поддержки информационных процессов. Таким образом, неполный перечень технических средств информационного обеспечения включает в себя аппаратное обеспечение вычислительной техники, программное обеспечение вычислительной техники, электронные средства связи, множительную технику, носители информации, включая твердые (бумагу) и т. д.
Информационный персонал – это работники, обеспечивающие поддержку информационных процессов, включающих в себя также и процесс взаимодействия между потребителем информации и техническими средствами. Современные тенденции в развитии информационных систем направлены на уменьшение доли информационных работников в информационных процессах. Полностью устранить такой элемент, как информационный персонал невозможно. Всегда будут необходимы программисты, электроники, системные администраторы, архивариусы, документоведы, которые обеспечивают функционирование системы информации предприятия. Необходимо устранение процессов, где информационный работник выступает посредником между техническими средствами и потребителями информации. Такие процессы существенно снижают эффективность удовлетворения информационных потребностей. Вот типичный пример. Допустим, вам необходима информация о содержании требований стандартов ИСО относительно проведения внутренних проверок. Вы должны объяснить вашу задачу оператору, который, вообще говоря, не является специалистом в области систем менеджмента качества и не сразу понимает, что вам нужно. После того, как задача становится ему понятна, он должен перевести ваш запрос на язык, «понятный» техническим средствам. По окончании такого перевода задача выполняется (чаще всего значительно быстрее, чем формулируется), и результат её выполнения сообщается оператору опять же на языке технических средств. Поскольку вы не являетесь специалистом в области средств управления информацией, оператор должен преобразовать результат в форму, понятную для менеджера систем качества, а это опять же достаточно продолжительный процесс. В результате время удовлетворения информационных запросов значительно увеличивается (иногда в несколько раз!). Кроме того, многократный перевод задачи с одной терминологии на другую увеличивает вероятность совершения ошибки в процессе такого перевода, а значит и информационный запрос будет не удовлетворен Современные исследования направлены на решение этой проблемы с двух сторон. С одной стороны ведутся разработки все более и более совершенных средств общения с ЭВМ на естественном (человеческом) языке. Это не только формулировка задания в командах, написанных на человеческом языке (языки программирования высокого уровня), но и разработка «дружественного» интуитивного интерфейса, когда человек, впервые в жизни севший за компьютер, опираясь только на свою интуицию, а также подсказки системы смог бы в принципе решать самостоятельно хотя бы несложные задачи. Мало этого, в настоящее время ведется и достаточно успешно разработка систем, обеспечивающих принятие компьютером голосовых команд. С другой стороны, упрощение способов работы с ЭВМ позволяет обучить навыкам такой работы значительное количество работников, не являющих специалистами в информационной сфере. Все эти мероприятия и обеспечивают уменьшения доли информационного персонала, которая в идеале (в процессе взаимодействия между техническими средствами и потребителем) должна быть сведена к нулю.
Методы управления информацией – это вся методология, обеспечивающая организацию хранения информации, построение информационных запросов, защиту информации, её обработку. Все технические средства без методов управления информацией – это просто куча материи. Для того, чтобы хранить информацию мало иметь какой-нибудь носитель. Он сам по себе мертв. Необходимо ещё так разместить данные на нем, чтобы потом иметь возможность не просто достать их, но и эффективно обрабатывать, решая различные информационные задачи. Кстати, обработка информации также требует применения определенной методологии. Образно говоря, можно представить технические средства в виде набора деревьев, гвоздей, топоров, молотков и т. д., а методы – это то, что позволяет с использованием приведенных выше предметов построить дом.
Организация работы с информацией подразделения предприятия
Эффективность работы любого подразделения на любом предприятии в значительной степени зависит от того, насколько правильно организованы информационные процессы. Поэтому при создании новых подразделений, а также при разработке мероприятий по улучшению деятельности существующих необходимо уделять особое внимание правильному определению информационных процессов.
Построение структуры информации подразделения необходимо начинать с разработки плана внедрения (или модификации) информационных процессов. При его разработке необходимо прежде всего провести анализ всех процессов подразделения на предмет того, какая информация, необходима для их обеспечения. Затем разрабатывается проект информационной системы подразделения, который должен включать в себя следующие моменты.
1. Распределение информации на ту, которая будет храниться и обрабатываться вручную, обрабатываемую электронными техническими средствами и информацию, которая подлежит комбинированной обработке. При этом необходимо стремиться к тому, чтобы возможно большее количество информации обрабатывалось автоматически. Кроме того, необходимо учитывать и возможности информационного взаимодействия с другими подразделениями организации – в какой форме они могут принимать и выдавать информацию.
2. Определение технических средств для хранения и обработки всех типов (п.1) информации.
3. Разработка проекта баз данных.
4. Разработка проекта средств представления и обработки информации.
5. Разработка проекта средств защиты информации.
6. Определение необходимых ресурсов (материальных, технических, людских и пр.) для реализации информационной системы.
7. Разработка календарного плана внедрения системы.
По окончании разработки проекта информационной системы разрабатывается план проверки эффективности функционирования разработанной информационной системы.
Следующим этапом организации управления информацией является реализация разработанных ранее проектов. Ввод в эксплуатацию каждого нового процесса должен сопровождаться контролем выполнения положений плана, а также эффективности запланированных мероприятий.
Впоследствии информационные процессы должны быть объектом процесса непрерывного улучшения.
1. Потребности информационных систем
Однако ситуация коренным образом отличается для упоминавшихся в начале лекции информационных систем. Эти системы главным образом ориентированы на хранение, выбор и модификацию постоянно существующей информации. Структура информации зачастую очень сложна, и хотя структуры данных различны в разных информационных системах, между ними часто бывает много общего. На начальном этапе использования вычислительной техники для управления информацией проблемы структуризации данных решались индивидуально в каждой информационной системе. Производились необходимые надстройки над файловыми системами (библиотеки программ), подобно тому, как это делается в компиляторах, редакторах и т. д. Но поскольку информационные системы требуют сложных структур данных, эти индивидуальные дополнительные средства управления данными являлись существенной частью информационных систем и практически повторялись от одной системы к другой. Стремление выделить и обобщить общую часть информационных систем, ответственную за управление сложно структурированными данными, явилось, на наш взгляд, первой побудительной причиной создания СУБД. Очень скоро стало понятно, что невозможно обойтись общей библиотекой программ, реализующей над стандартной базовой файловой системой более сложные методы хранения данных. Покажем это на примере. Предположим, что мы хотим реализовать простую информационную систему, поддерживающую учет сотрудников некоторой организации. Система должна выполнять следующие действия: выдавать списки сотрудников по отделам, поддерживать возможность перевода сотрудника из одного отдела в другой, приема на работу новых сотрудников и увольнения работающих. Для каждого отдела должна поддерживаться возможность получения имени руководителя этого отдела, общей численности отдела, общей суммы выплаченной в последний раз зарплаты и т. д. Для каждого сотрудника должна поддерживаться возможность выдачи номера удостоверения по полному имени сотрудника, выдачи полного имени по номеру удостоверения, получения информации о текущем соответствии занимаемой должности сотрудника и о размере его зарплаты. Предположим, что мы решили основывать эту информационную систему на файловой системе и пользоваться при этом одним файлом, расширив базовые возможности файловой системы за счет специальной библиотеки функций. Поскольку минимальной информационной единицей в нашем случае является сотрудник, естественно потребовать, чтобы в этом файле содержалась одна запись для каждого сотрудника. Какие поля должна содержать такая запись? Полное имя сотрудника (СОТР_ИМЯ), номер его удостоверения (СОТР_НОМЕР), информацию о его соответствии занимаемой должности (для простоты, "да" или "нет") (СОТР_СТАТ), размер зарплаты (СОТР_ЗАРП), номер отдела (СОТР_ОТД_НОМЕР). Поскольку мы хотим ограничиться одним файлом, та же запись должна содержать имя руководителя отдела (СОТР_ОТД_РУК). Функции нашей информационной системы требуют, чтобы обеспечивалась возможность многоключевого доступа к этому файлу по уникальным ключам (недублируемым в разных записях) СОТР_ИМЯ и СОТР_НОМЕР. Кроме того, должна обеспечиваться возможность выбора всех записей с общим значением СОТР_ОТД_НОМЕР, то есть доступ по неуникальному ключу. Для того, чтобы получить численность отдела или общий размер зарплаты, каждый раз при выполнении такой функции информационная система должна будет выбрать все записи о сотрудниках отдела и посчитать соответствующие общие значения. Таким образом, даже для такой простой системы ее реализация на базе файлов, во-первых, требует создания достаточно сложной надстройки для многоключевого доступа к файлам, и, во-вторых, вызывает требование существенной избыточности хранения (для каждого сотрудника одного отдела повторяется имя руководителя) и выполнение массовой выборки и вычислений для получения суммарной информации об отделах. Кроме того, если в ходе эксплуатации системы нам захочется, например, выдавать списки сотрудников, получающих заданную зарплату, то придется либо полностью просматривать файл, либо реструктуризировать его, объявляя ключевым поле СОТР_ЗАРП. Первое, что приходит на ум, – это поддерживать два многоключевых файла: СОТРУДНИКИ и ОТДЕЛЫ. Первый файл должен содержать поля СОТР_ИМЯ, СОТР_НОМЕР, СОТР_СТАТ, СОТР_ЗАРП и СОТР_ОТД_НОМЕР, а второй файл – ОТД_НОМЕР, ОТД_РУК, ОТД_СОТР_ЗАРП (общее число сотрудников в отделе) и ОТД_РАЗМЕР (общий размер зарплаты). Большинство неудобств, перечисленных в предыдущем абзаце, будут преодолены. Каждый из файлов будет содержать только не дублируемую информацию, необходимости в динамических вычислениях суммарной информации не возникает. Но заметим, что при таком переходе наша информационная система должна обладать некоторыми новыми особенностями, сближающими ее с СУБД. Прежде всего, система должна теперь знать, что она работает с двумя информационно связанными файлами. Это шаг в сторону схемы базы данных. Должна знать структуру и смысл каждого поля (например, что СОТР_ОТД_НОМЕР в файле СОТРУДНИКИ и ОТД_НОМЕР в файле ОТДЕЛЫ означают одно и то же), понимать, что в ряде случаев изменение информации в одном файле должно автоматически вызывать модификацию во втором файле, чтобы их общее содержимое было согласованным. Например, если на работу принимается новый сотрудник, то необходимо добавить запись в файл СОТРУДНИКИ, а также соответствующим образом изменить поля ОТД_ЗАРП и ОТД_РАЗМЕР в записи файла ОТДЕЛЫ, описывающей отдел этого сотрудника. Понятие согласованности данных является ключевым понятием баз данных. Фактически, если информационная система (даже такая простая, как в нашем примере) поддерживает согласованное хранение информации в нескольких файлах, можно говорить о том, что она поддерживает базу данных. Если же некоторая вспомогательная система управления данными позволяет работать с несколькими файлами, обеспечивая их согласованность, можно назвать ее системой управления базами данных. Уже только требование поддержания согласованности данных в нескольких файлах не позволяет обойтись библиотекой функций: такая система должна иметь некоторые собственные данные (метаданные) и даже знания, определяющие целостность данных. Но это еще не все, что обычно требуют от СУБД. Во-первых, даже в нашем примере неудобно реализовывать такие запросы как "выдать общую численность отдела, в котором работает Петр Иванович Сидоров". Было бы гораздо проще, если бы СУБД позволяла сформулировать такой запрос на близком пользователям языке. Такие языки называются языками запросов к базам данных. Например, на языке SQL наш запрос можно было бы выразить в форме:
SELECT ОТД_РАЗМЕР
FROM СОТРУДНИКИ, ОТДЕЛЫ
WHERE СОТР_ИМЯ = "ПЕТР ИВАНОВИЧ СИДОРОВ"
AND СОТР_ОТД_НОМЕР = ОТД_НОМЕР
Таким образом, при формулировании запроса СУБД позволит не задумываться о том, как будет выполняться этот запрос. Среди ее метаданных будет содержаться информация о том, что поле СОТР_ИМЯ является ключевым для файла СОТРУДНИКИ, а ОТД_НОМЕР – для файла ОТДЕЛЫ, и система сама воспользуется этим. Если же возникнет потребность в получении списка сотрудников, не соответствующих занимаемой должности, то достаточно предъявить системе запрос
SELECT СОТР_ИМЯ, СОТР_НОМЕР
FROM СОТРУДНИКИ
WHERE СОТР_СТАТ = "НЕТ",
и система сама выполнит необходимый полный просмотр файла СОТРУДНИКИ, поскольку поле СОТР_СТАТ не является ключевым. Далее, представьте себе, что в нашей первоначальной реализации информационной системы, основанной на использовании библиотек расширенных методов доступа к файлам, обрабатывается операция регистрации нового сотрудника. Следуя требованиям согласованного изменения файлов, информационная система вставила новую запись в файл СОТРУДНИКИ и собиралась модифицировать запись файла ОТДЕЛЫ, но именно в этот момент произошло аварийное выключение питания. Очевидно, что после перезапуска системы ее база данных будет находиться в рассогласованном состоянии. Потребуется выяснить это (а для этого нужно явно проверить соответствие информации в файлах СОТРУДНИКИ и ОТДЕЛЫ) и привести информацию в согласованное состояние. Настоящие СУБД берут такую работу на себя. Прикладная система не обязана заботиться о корректности состояния базы данных. Наконец, представим себе, что мы хотим обеспечить параллельную (например, многотерминальную) работу с базой данных сотрудников. Если опираться только на использование файлов, то для обеспечения корректности на все время модификации любого из двух файлов доступ других пользователей к этому файлу будет блокирован (вспомните возможности файловых систем для синхронизации параллельного доступа). Таким образом, зачисление на работу Петра Ивановича Сидорова существенно затормозит получение информации о сотруднике Иване Сидоровиче Петрове, даже если они будут работать в разных отделах. Настоящие СУБД обеспечивают гораздо более тонкую синхронизацию параллельного доступа к данным. Таким образом, СУБД решают множество проблем, которые затруднительно или вообще невозможно решить при использовании файловых систем. При этом существуют приложения, для которых вполне достаточно файлов. Имеются приложения, для которых необходимо решать, какой уровень работы с данными во внешней памяти им требуется, и приложения, для которых нужны базы данных.
2. Организация баз данных
2.1. Предметная область
Любые объекты в окружающем мире наделены совокупностью знаний о них. Так, например, мы знаем о человеке, как его зовут, когда он родился, сколько у него детей, и кто его дети, кличка любимой собаки, семейное положение, болезни, образование, привычки, домашний адрес, место работы, черты характера и т. п. Когда в качестве объекта выступает какая-либо организация или технологический процесс, то им соответствует свой специфический и тоже бесконечный набор атрибутов знания (информации). Этот набор знаний постоянно увеличивается, он не связан с какой-либо областью их приложения, а содержит все то, что известно об объекте – предмете исследования. Такая совокупность знаний об объекте окружающего мира и составляет предметную область объекта. Однако, для обработки информации об объекте полный охват его предметной области не только не требуется, но даже и вреден. Более того, даже не просто вреден, а невозможен. Поскольку предметная область содержит бесконечное множество знаний об объекте, то их определение, фиксация и обработка потребует бесконечного объема ресурсов: бумаги, чернил, памяти машины, человеко-часов работы оператора и т. п. При организации информационного обеспечения любого процесса необходимо, прежде всего, выделить из предметной области необходимый минимум знаний. Таких знаний должно быть как можно меньше, ибо каждый новый атрибут – это дополнительные затраты ресурсов, нарастающие при этом отнюдь не линейно. С другой стороны, этих знаний должно быть достаточно, для того чтобы удовлетворять информационные потребности процесса. Таким образом из предметной области необходимо изъять:
– знания не используемые для информационного обеспечения конкретного процесса (например, информация о любимой собаке работника);
– знания, которые могут быть получены путем логических либо математических операций из других (например, если есть информация о дате рождения человека, то нет необходимости выделять его возраст, поскольку он может быть получен исходя из текущей даты и даты рождения).
Оставшийся минимум атрибутов предметной области, помещенный на определенный носитель называется базой данных. Вид базы данных определяется выбранным исходя из возможностей организации и спецификой объекта носителем. Наиболее общее подразделение баз данных на ручные и машинные.
Ручная база данных – это база данных, выполненная без применения средств вычислительной техники, организованная и обрабатываемая целиком и полностью человеком. Домашняя фонотека – типичный пример ручной базы данных, хотя информация представлена на электронных носителях – магнитных кассетах.
Машинная база данных – система, в которой организация хранения и обработки информации производится с использованием компьютеров. Особенно эффективными показали себя такие базы данных для хранения и обработки текстовой и числовой информации. Современные системы управления базами данных (СУБД) позволяют хранить информацию в любом формате, поддерживаемом приложениями операционной системы, и обрабатывать ее средствами этих приложений. В машинной базе данных, например, можно хранить информацию о структуре и содержании стандартов ИСО 9000, фотографии работников организации, технологическую и конструкторскую документацию, разработанную средствами любых систем автоматического проектирования, программы для станков с ЧПУ, рекламные видеоролики об организации и т. д.
Одной из открытых на сегодняшний день проблем является передача информации между ручными и машинными базами. Единственным способом такого взаимодействия является схема машинная база данных – человек – ручная база данных. В результате информация обрабатывается иногда даже хуже, чем при использовании любой из них в отдельности. Решение проблемы многие видят в постепенном отмирании ручных баз данных и полном переходе на машинные.
Машинные базы данных действительно несоизмеримо более эффективно удовлетворяют информационные потребности, однако для их использования необходимо соблюдать определенные правила взаимодействия с искусственным интеллектом. Значительная часть этих правил связана с тем, чтобы обеспечить «понимание» компьютером человека и наоборот. Русский человек испытывает определенные затруднения в общении с японцем. Но ведь и японцы и русские относятся к одному и тому же виду Homo Sapiens. И японец и русский в принципе мыслят одинаково – символьными образами – «чанками». Компьютер же по своей сути существо чуждое человеку – он мыслит кодами. Процесс его «мышления» заключается в формальном выполнении фиксированного набора команд, представленных средствами двоичной логики. Само содержание таких команд крайне сложно для понимания человеком, особенно не связанным профессионально с вычислительной техникой. Поэтому необходимо иметь средства обеспечивающие «перевод» запросов с человеческого языка на машинный, а результатов их обработки – обратно на язык понятный оператору (пусть даже и английский). Одним из аспектов такого перевода является представление предметных областей на машинных носителях – перевод информации, представленной чанками – в двоичный код.
Работы по созданию универсальных средств представления знаний ведутся едва ли не сначала 60-х годов. В результате появились, так называемые, модели данных, представляющие собой упрощенные способы отображения знаний об объекте и использующие определенные принципы организации данных. На базе таких моделей данных были разработаны программные системы обработки информации – системы управления базами данных или СУБД. Интересная деталь: практически все известные на сегодняшний день модели данных (кроме объектных) были разработаны почти одновременно (с 1967 по 1971 годы). Однако на том или ином историческом этапе рынок СУБД захватывался одной максимум двумя моделями данных. На сегодняшний день имеются системы, реализующие все известные модели данных. Причем реляционная модель является самой универсальной, поскольку позволяет реализовывать любые схемы данных и структуры.
2.2. Типовая организация и функции СУБД
Как было показано в первой лекции, традиционных возможностей файловых систем оказывается недостаточно для построения даже простых информационных систем. Мы выявили несколько потребностей, которые не покрываются возможностями систем управления файлами: поддержание логически согласованного набора файлов; обеспечение языка манипулирования данными; восстановление информации после разного рода сбоев; реально параллельная работа нескольких пользователей. Можно считать, что если прикладная информационная система опирается на некоторую систему управления данными, обладающую этими свойствами, то эта система управления данными является системой управления базами данных (СУБД).
2.2.1. Непосредственное управление данными во внешней памяти
Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным в некоторых случаях (обычно для этого используются индексы). В некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других работа производится вплоть до уровня устройств внешней памяти. Но подчеркнем, что в развитых СУБД пользователи в любом случае не обязаны знать, использует ли СУБД файловую систему, и если использует, то каким образом организованы файлы. В частности, СУБД поддерживает собственную систему именования объектов БД.
2.2.2. Управление буферами оперативной памяти
СУБД обычно работают с БД значительного размера; по крайней мере, этот размер обычно существенно больше доступного объема оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. При этом даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов. Заметим, что существует отдельное направление СУБД, которое ориентировано на постоянное присутствие в оперативной памяти всей БД. Это направление основывается на предположении, что в будущем объем оперативной памяти компьютеров будет настолько велик, что позволит не беспокоиться о буферизации. Пока эти работы находятся в стадии исследований.
2.2.3. Управление транзакциями
Транзакция – это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Если вспомнить наш пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ, то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД. То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать себя единственным пользователем СУБД (на самом деле, это несколько идеализированное представление, поскольку в некоторых случаях пользователи многопользовательских СУБД могут ощутить присутствие своих коллег). С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций. Под сериализаций параллельно выполняющихся транзакций понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций - это такой план, который приводит к сериализации транзакций. Понятно, что если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с однопользовательским режимом). Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов БД. При использовании любого алгоритма сериализации возможны ситуации конфликтов между двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания сериализации необходимо выполнить откат (ликвидировать все изменения, произведенные в БД) одной или более транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе транзакций других пользователей.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 |
