Рост производительности персональных вычислительных машин спровоцировал развитие СУБД, как отдельного класса. К середине 60-х годов прошлого века уже существовало большое количество коммерческих СУБД. Интерес к базам данных увеличивался все больше, так что данная сфера нуждалась в стандартизации. Автор комплексной базы данных Integrated Data Store Чарльз Бахман (Charles Bachman) организовал целевую группу DTG (Data Base Task Group) для утверждения особенностей и организации стандартов БД в рамках CODASYL - группы, которая отвечала за стандартизацию языка программирования COBOL. Уже в 1971 году был представлен свод утверждений и замечаний, который был назван Подход CODASYL, и спустя некоторое время появились первые успешные коммерческие продукты, изготовленные с учетом замечаний вышеупомянутой рабочей группы. В 1968 году отметилась и компания IBM, которая представила собственную СУБД под названием IMS. Фактически данный продукт представлял собой компиляцию утилит, которые использовались с системами System/360 на шаттлах Аполлон. Решение было разработано согласно коцпетам CODASYL, но при этом была применена строгая иерархия для структуризации данных. В свою очередь в варианте CODASYL за базис была взята сетевая СУБД. Оба варианта, меж тем, были приняты сообществом позднее как классические варианты организации работы СУБД, а сам Чарльз Бахман в 1973 году получил премию Тьюринга за работу Программист как навигатор. В 1970 году сотрудник компании IBM Эдгар Кодд, работавший в одном из отделений Сан Хосе (США), в котором занимались разработкой систем хранения, написал ряд статей, касающихся навигационных моделей СУБД. Заинтересовавшись вопросом он разработал и изложил несколько инновационных подходов касательно оптимальной организаци систем управления БД. Работа Кодда внесла значительный вклад в развитие СУБД и является действительным основоположником теории реляционных баз данных. Уже 1981 году Э.Ф.Кодд создал реляционную модель данных и применил к ней операции реляционной алгебры.
Первый этап - базы данных на больших ЭВМ . Первый этап развития СУБД связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ и мини-ЭВМ типа PDP11 (фирмы Digital Equipment Corporation - DEC), разных моделях HP (фирмы Hewlett Packard). Базы данных хранились во внешней памяти центральной ЭВМ, пользователями этих баз данных были задачи, запускаемые в основном в пакетном режиме. Интерактивный режим доступа обеспечивался с помощью консольных терминалов, которые не обладали собственными вычислительными ресурсами (процессором, внешней памятью) и служили только устройствами ввода-вывода для центральной ЭВМ.
Второй этап - эпоха персональных компьютеров . Появляется множество программ, предназначенных для работы неподготовленных пользователей. Эти программы просты в использовании и интуитивно понятны: это, прежде всего, различные редакторы текстов, электронные таблицы и другие. Каждый пользователь может автоматизировать многие аспекты деятельности. И, конечно, это сказалось и на работе с базами данных. Появились программы, которые назывались системами управления базами данных и позволяли хранить значительные объемы информации, они имели удобный интерфейс для заполнения данных, встроенные средства для генерации различных отчетов. Эти программы позволяли автоматизировать многие учетные функции, которые раньше велись вручную. Компьютеры стали инструментом для ведения документации и собственных учетных функций. Это все сыграло как положительную, так и отрицательную роль в области развития баз данных.
Третий этап - распределенные базы данных . Хорошо известно, что история развивается по спирали, поэтому после процесса «персонализации» начался обратный процесс - интеграция. Множится количество локальных сетей, все больше информации передастся между компьютерами, остро встает задача согласованности данных, хранящихся и обрабатывающихся в разных местах, но логически друг с другом связанных, возникают задачи, связанные с параллельной обработкой транзакций - последовательностей операций над БД, переводящих ее из одного непротиворечивого состояния в другое непротиворечивое состояние. Успешное решение этих задач приводит к появлению распределенных баз данных, сохраняющих все преимущества настольных СУБД и в то же время позволяющих организовать параллельную обработку информации и поддержку целостности БД.
Четвертый этап - перспективы развития систем управления базами данных . Этот этап характеризуется появлением новой технологии доступа к данным- интранет. Основное отличие этого подхода от технологии клиент-сервер состоит в том, что отпадает необходимость использования специализированного клиентского программного обеспечения. Для работы с удаленной базой данных используется стандартный броузер Internet, например Microsoft InternetExplorer, и для конечного пользователя процесс обращения к данным происходит аналогично использованию Internet. При этом встроенный в загружаемые пользователем HTML-страницы код, написанный обычно на языках Java, Java-script, Perl и других, отслеживает все действия пользователя и транслирует их в низкоуровневые SQL-запросы к базе данных, выполняя, таким образом, ту работу, которой в технологии клиент-сервер занимается клиентская программа.
Основы использования БД
Итак, начнем с самого начала. Что же такое база данных? База данных - организованная в соответствии с определёнными правилами и поддерживаемая в памяти компьютера совокупность данных, характеризующая актуальное состояние некоторой предметной области и используемая для удовлетворения информационных потребностей пользователей (Информация из Википедии)
Таким образом, к БД относятся:
Интерфейс для управления БД, называемый СУБД – Система управления базами данных
Собственно данные, хранящиеся в определенной форме
Существуют различные типы баз данных. Основной признак классификации – принцип хранения данных.
Реляционные
Объектно-ориентированные
Объектные
Объектно-реляционные
Иерархические
Файлы и файловые системы
Важным шагом в развитии именно информационных систем явился переход к использованию централизованных систем управления файлами. С точки зрения прикладной программы, файл - это именованная область внешней памяти, в которую можно записывать и из которой можно считывать данные. Правила именования файлов, способ доступа„к данным, хранящимся в файле, и структура этих данных зависят от конкретной системы управления файлами и, возможно, от типа файла. Система управления файлами берет на себя распределение внешней памяти, отображение имен файлов в соответствующие адреса во внешней памяти и обеспечение доступа к данным.
Конкретные модели файлов, используемые в системе управления файлами, мы рассмотрим далее, когда перейдем к физическим способам организации баз данных, а на этом этапе нам достаточно знать, что пользователи видят файл как линейную последовательность записей и могут выполнить над ним ряд стандартных операций:
создать файл (требуемого типа и размера);
записать в файл на место текущей записи новую, добавить новую запись в конец файла.
В разных файловых системах эти операции могли несколько отличаться, но общий смысл их был именно таким. Главное, что следует отметить, это то, что структура записи файла была известна только программе, которая с ним работала, система управления файлами не знала ее. И поэтому для того, чтобы извлечь некоторую информацию из файла, необходимо было точно знать структуру записи файла с точностью до бита. Каждая программа, работающая с файлом, должна была иметь у себя внутри структуру данных, соответствующую структуре этого файла. Поэтому при изменении структуры файла требовалось изменять структуру программы, а это требовало новой компиляции, то есть процесса перевода программы в исполняемые машинные коды. Такая ситуации характеризовалась как зависимость программ от данных. Для информационных систем характерным является наличие большого числа различных пользователей (программ), каждый из которых имеет свои специфические алгоритмы обработки информации, хранящейся в одних и тех же файлах. Изменение структуры файла, которое было необходимо для одной программы, требовало исправления и перекомпиляции и дополнительной отладки всех остальных программ, работающих с этим же файлом. Это было первым существенным недостатком файловых систем, который явился толчком к созданию новых систем хранения и управления информацией.
Далее, поскольку файловые системы являются общим хранилищем файлов, принадлежащих, вообще говоря, разным пользователям, системы управления файлами должны обеспечивать авторизацию доступа к файлам. В общем виде подход состоит в том, что по отношению к каждому зарегистрированному пользователю данной вычислительной системы для каждого существующего файла указываются действия, которые разрешены или запрещены данному пользователю. В большинстве современных систем управления файлами применяется подход к защите файлов, впервые реализованный в ОС UNIX. В этой ОС каждому зарегистрированному пользователю соответствует пара целочисленных идентификаторов; идентификатор группы, к которой относится этот пользователь, и его собственный идентификатор в группе. При каждом файле хранится полный идентификатор пользователя, который создал этот файл, и фиксируется, какие действия с файлом может производить его создатель, какие действия с файлом доступны для других пользователей той же группы и что могут делать с файлом пользователи других групп. Администрирование режимом доступа к файлу в основном выполняется его создателем-владельцем. Для множества файлов, отражающих информационную модель одной предметной области, такой децентрализованный принцип управления доступом вызывал дополнительные трудности. И отсутствие централизованных методов управления доступом к информации послужило еще одной причиной разработки СУБД.
Следующей причиной стала необходимость обеспечения эффективной параллельной работы многих пользователей с одними и теми же файлами. В общем случае системы управления файлами обеспечивали режим многопользовательского доступа. Если операционная система поддерживает многопользовательский режим, вполне реальна ситуация, когда два или более пользователя одновременно пытаются работать с одним и тем же файлом. Если все пользователи собираются только читать файл, ничего страшного не произойдет. Но если хотя бы один из них будет изменять файл, для корректной работы этих пользователей требуется взаимная синхронизация их действий по отношению к файлу
В системах управления файлами обычно применялся следующий подход. В операции открытия файла (первой и обязательной операции, с которой должен начинаться сеанс работы с файлом) среди прочих параметров указывался режим работы (чтение или изменение). Если к моменту выполнения этой операции некоторым пользовательским процессом PR1 файл был уже открыт другим процессом PR2 в режиме изменения, то в зависимости от особенностей системы процессу PR1 либо сообщалось о невозможности открытия файла, либо он блокировался до тех пор, пока в процессе PR2 не выполнялась операция закрытия файла.
При подобном способе организации одновременная работа нескольких пользователей, связанная с модификацией данных в файле, либо вообще не реализовывалась, либо была очень замедлена.
Эти недостатки послужили тем толчком, который заставил разработчиков информационных систем предложить новый подход к управлению информацией. Этот подход был реализован в рамках новых программных систем, названных впоследствии Системами Управления Базами Данных (СУБД), а сами хранилища информации, которые работали под управлением данных систем, назывались базами или банками данных (БД и БнД).
3 вопрос. Распределённые базы данных (РБД) - совокупность логически взаимосвязанных баз данных, распределённых в компьютерной сети.
Основные принципы
РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:
каждый узел - это полноценная СУБД сама по себе;
узлы взаимодействуют между собой таким образом, что пользователь любого из них может получить доступ к любым данным в сети так, как будто они находятся на его собственном узле.
Каждый узел сам по себе является системой базы данных. Любой пользователь может выполнить операции над данными на своём локальном узле точно так же, как если бы этот узел вовсе не входил в распределённую систему. Распределённую систему баз данных можно рассматривать как партнёрство между отдельными локальными СУБД на отдельных локальных узлах.
Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система.
Фундаментальный принцип имеет следствием определённые дополнительные правила или цели. Таких целей всего двенадцать:
Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.
Отсутствие опоры на центральный узел. Локальная независимость предполагает, что все узлы в распределённой системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса.
Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.
Независимость от расположения. Пользователи не должны знать, где именно данные хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле.
Независимость от фрагментации. Система поддерживает независимость от фрагментации, если данная переменная-отношение может быть разделена на части или фрагменты при организации её физического хранения. В этом случае данные могут храниться в том месте, где они чаще всего используются, что позволяет достичь локализации большинства операций и уменьшения сетевого трафика.
Независимость от репликации. Система поддерживает репликацию данных, если данная хранимая переменная-отношение - или в общем случае данный фрагмент данной хранимой переменной-отношения - может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах.
Обработка распределённых запросов. Суть в том, что для запроса может потребоваться обращение к нескольким узлам. В такой системе может быть много возможных способов пересылки данных, позволяющих выполнить рассматриваемый запрос.
Управление распределёнными транзакциями. Существует 2 главных аспекта управления транзакциями: управление восстановлением и управление параллельностью обработки. Что касается управления восстановлением, то чтобы обеспечить атомарность транзакции в распределённой среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов (агент - процесс, который выполняется для данной транзакции на отдельном узле) или зафиксировало свои результаты, или выполнило откат. Что касается управления параллельностью, то оно в большинстве распределённых систем базируется на механизме блокирования, точно так, как и в нераспределённых системах.
Аппаратная независимость. Желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределённой системы как равноправные партнёры.
Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами.
Независимость от сети. Возможность поддерживать много принципиально различных узлов, отличающихся оборудованием и операционными системами, а также ряд типов различных коммуникационных сетей.
Независимость от типа СУБД. Необходимо, чтобы экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной и той же версии СУБД.
Типы распределённых баз данных
Распределённые базы данных
Мультибазы данных с глобальной схемой. Система мультибаз данных - это распределённая система, которая служит внешним интерфейсом для доступа ко множеству локальных СУБД или структурируется, как глобальный уровень над локальными СУБД.
Федеративные базы данных. В отличие от мультибаз не располагают глобальной схемой, к которой обращаются все приложения. Вместо этого поддерживается локальная схема импорта-экспорта данных. На каждом узле поддерживается частичная глобальная схема, описывающая информацию тех удалённых источников, данные с которых необходимы для функционирования.
Мультибазы с общим языком доступа - распределённые среды управления с технологией «клиент-сервер»
4 вопрос. Проектирование баз данных - это сложный процесс решения целого ряда задач, которые связаны с созданием баз данных.
Основные задачи проектирования СУБД
Обеспечение возможности для корректного получения данных по всем запросам;
Обеспечение хранения в базе данных всей необходимой информации; Сократить избыточность и дублирование данных;
Обеспечить целостность всех данных в БД и исключить их потери;
Главные этапы в проектировании БД;
Инфологическое (Концептуальное) проектирование – это грамотное построение формализованной модели всей предметной области. Подобная модель создается с использованием стандартных языковых средств, чаще всего графических, например ER-диаграмм. Такая модель создается без какой-либо ориентации на конкретную СУБД.
Главные элементы данной модели:
Описание всех объектов предметной области и всех связей между ними;
Описание всех информационных потребностей пользователей, например, описание самых основных запросов к базе данных и т.д.;
Составление полного описания документооборота. Описание всех документов, которые используются в качестве исходных данных для базы данных;
Описание основных алгоритмических зависимостей, возникающих между данными;
Подробное описание ограничений целостности. Сюда входят требования ко всем допустимым значениям данных и к их связям;
Виды проектирования:
Логическое или даталогическое проектирование – заключается в отображении инфологической модели на какую-либо модель данных, которая используется в конкретной СУБД. Для реляционных СУБД характерна даталогическая модель, а именно: набор всех таблиц с указанием основных или ключевых полей и всех связей между этими таблицами. Даталогическое проектирование любой инфологической модели, которая построена в виде ER-диаграмм, представляет построение таблиц по каким-либо определённым формализованным правилам.
Физическое проектирование СУБД – это процесс реализации какой-либо даталогической модели, используя средства конкретной СУБД, а также выбор различных решений, которые связаны с физической средой хранения всех данных.
5 вопрос. Реляционная модель данных (РМД) - логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики как теории множеств и логика первого порядка.
На реляционной модели данных строятся реляционные базы данных.
Реляционная модель данных включает следующие компоненты:
Структурный аспект (составляющая) - данные в базе данных представляют собой набор отношений.
Аспект (составляющая) целостности - отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.
Аспект (составляющая) обработки (манипулирования) - РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).
Кроме того, в состав реляционной модели данных включают теорию нормализации.
Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину «отношение» часто встречается слово таблица. Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, а визуальное представление отношения на бумаге или экране. Некорректное и нестрогое использование термина «таблица» вместо термина «отношение» нередко приводит к недопониманию. Наиболее частая ошибка состоит в рассуждениях о том, что РМД имеет дело с «плоскими», или «двумерными» таблицами, тогда как таковыми могут быть только визуальные представления таблиц. Отношения же являются абстракциями, и не могут быть ни «плоскими», ни «неплоскими».
Для лучшего понимания РМД следует отметить три важных обстоятельства:
модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;
для реляционных баз данных верен информационный принцип: всё информационное наполнение базы данных представлено одним и только одним способом, а именно - явным заданием значений атрибутов в кортежах отношений; в частности, нет никаких указателей (адресов), связывающих одно значение с другим;
наличие реляционной алгебры позволяет реализовать декларативное программирование и декларативное описание ограничений целостности, в дополнение к навигационному (процедурному) программированию и процедурной проверке условий.
Принципы реляционной модели были сформулированы в 1969-1970 годах Э. Ф. Коддом (E. F. Codd). Идеи Кодда были впервые публично изложены в статье «A Relational Model of Data for Large Shared Data Banks», ставшей классической.
Строгое изложение теории реляционных баз данных (реляционной модели данных) в современном понимании можно найти в книге К. Дж. Дейта. «C. J. Date. An Introduction to Database Systems» («Дейт, К. Дж. Введение в системы баз данных»).
Наиболее известными альтернативами реляционной модели являются иерархическая модель, и сетевая модель. Некоторые системы, использующие эти старые архитектуры, используются до сих пор. Кроме того, можно упомянуть об объектно-ориентированной модели, на которой строятся так называемые объектно-ориентированные СУБД, хотя однозначного и общепринятого определения такой модели нет.
6 вопрос. Оператор выбораSELECT.
Команда select (выбор) используется для извлечения данных из таблицы. Эту команду можно использовать для выбора данных как по строкам, так по столбцам из одной или нескольких таблиц.
Запрос это обращение к базе данных с целью получения результирующих данных. Этот процесс также называется нахождением данных. Все SQL запросы выражаются через оператор выбора (select). Этот оператор можно использовать как для выбора записей (строк) из одной или нескольких таблиц, так и для построения проекций (projections), т.е. выбора данных по некоторому подмножеству атрибутов (столбцов) из одной или нескольких таблиц.
SELECT- ключевое слово, которое сообщает СУБД, что эта команда - запрос. Все запросы начинаются этим словом с доследующим пробелом, За ним может следовать способ выборки - с удалением дубликатов (DISTINCT) или без удаления (ALL, подразумевается по умолчанию). Затем следует список перечисленных через запятую столбцов, которые выбираются запросом из таблиц, или символ "*" (звездочка) для выбора всей строки. Любые столбцы, не перечисленные здесь, не будут включены в результирующее отношение, соответствующее выполнению команды. Это, конечно, не значит, что они будут удалены или их информация будет стерта из таблиц, потому что запрос не воздействует на информацию в, таблицах - он только показывает данные.
7 вопрос . Математические функции
В арсенале каждой СУБД обязательно имеется набор встроенных функций для обработки стандартных типов данных. В MySQLдля встроенных функций между именем и открывающей скобкой не должно быть пробелов, иначе будет сообщение об отсутствии подобной функции в БД. В некоторых СУБД, какOracle, если функция не имеет аргументов, то скобки можно опустить.
abs(x) - абсолютное значение;
ceil(x) - наименьшее целое, которое не меньше аргумента;
exp(x) - экспонента;
floor(x) - наибольшее целое, которое не больше аргумента;
ln(x) - натуральный логарифм;
power(x, y) - возводит x в степень y;
round(x [,y]) - округление x до y разрядов справа от десятичной точки. По умолчанию y равно 0;
sign(x) - возвращает -1 для отрицательных значений x и 1 для положительных;
sqrt(x) - квадратный корень;
trunc(x [,y]) - усекает x до у десятичных разрядов. Если у равно 0 (значение по умолчанию), то х усекается до целого числа. Если у меньше 0, от отбрасываются цифры слева от десятичной точки.
Тригонометрические функции работают с радианами:
acos(x) - арккосинус;
asin(x) - арксинус;
atan(x) - арктангенс;
cos(x) - косинус;
sin(x) - синус;
tan(x) - тангенс.
ceil(fraction) – округляет дробное число до ближайшего большего целого числа.
floor(fraction) – округляет дробное число до ближайшего меньшего целого числа.
number_format("number", "decimals", "decimal point", "thousands_sep") – возвращает форматированную версию указанного числа ("number").
pow(number,exponent) – возвращает результат возведения заданного числаnumberв степеньexponent.
rand(min,max) – порождает случайное число из заданного диапазона.
round(fraction) – округляет дробное число до ближайшего целого числа.
sqrt(number) – возвращает квадратный корень заданного числаnumber.
8 вопрос. Преимущества и недостаткиMySQL.
Недостатки MySQL
MySQLдействительно очень быстрый сервер, но для достижения этого разработчикам пришлось пожертвовать некоторыми требованиями к реляционным СУБД.
Нет поддержки внешних (foreign) ключей.
Преимущества MySQL:
наилучшая скорость обработки данных на объеме до 500000 записей;
бесплатные открытые лицензии;
простота использования;
поддержка большинством хостинговых компаний;
возможность использования на различных платформах (Unix,Windows, др.);
9 вопрос. Декомпозиция плоской таблицы.
Смысл декомпозиции заключается в следующем. Плоская таблица (большая таблица, в которой собраны воедино все данные для решения задачи с высокой степенью повторяемости данных) преобразуется в совокупность взаимосвязанных отдельных таблиц.
определяется количество сущностей (объектов), описываемых плоской таблицей.
поля плоской таблицы разделяются между таблицами (объектными отношениями), соответствующими объектам (сущностям);
определяется поле (набор полей), используемых в качестве ключа для связи между отдельными таблицами. Иногда для этой цели могут использоваться специальные таблицы (связные отношения).
ни одно из полей во всех отношениях не должно содержать групп значений. Н
если в некоторых полях данные повторяются слишком часто, можно создать дополнительные таблицы (отношения), играющие роль справочников.
Вышеизложенная последовательность действий – это шаги нормализации – метода организации реляционной базы данных с целью сокращения избыточности.
10 Вопрос .Команды создания баз данных, таблиц и индексов
create database if not exists – Создание базы данных
create table if not exists tovar (ID int unsigned not null auto_increment primary key,
tovar_name char (100) not null ,
tovar_mark char (100) not null,
Cena int not null ,
data_buy date default curdate() ,
family char (100) not null); создание таблицы
создание индекса в столбце au_idтаблицыauthors
create index au_id_ind
ПОЯВЛЕНИЕ СУБД История развития СУБД насчитывает более 30 лет. В 1968 году была введена в эксплуатацию первая промышленная СУБД система IMS фирмы IBM. В 1975 году появился первый стандарт ассоциации по языкам систем обработки данных - Conference of Data System Languages (CODASYL), который определил ряд фундаментальных понятий в теории систем баз данных, которые и до сих пор являются основополагающими для сетевой модели данных. В дальнейшее развитие теории баз данных большой вклад был сделан американским математиком Э. Ф. Коддом, который является создателем реляционной модели данных. В 1981 году Э. Ф. Кодд получил за создание реляционной модели и реляционной алгебры престижную премию Тьюринга Американской ассоциации по вычислительной технике.
ПЕРВЫЙ ЭТАП - БАЗЫ ДАННЫХ НА БОЛЬШИХ ЭВМ Первый этап развития СУБД связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ и мини-ЭВМ типа PDP 11 (фирмы Digital Equipment Corporation - DEC), разных моделях HP (фирмы Hewlett Packard). Базы данных хранились во внешней памяти центральной ЭВМ, пользователями этих баз данных были задачи, запускаемые в основном в пакетном режиме. Интерактивный режим доступа обеспечивался с помощью консольных терминалов, которые не обладали собственными вычислительными ресурсами (процессором, внешней памятью) и служили только устройствами ввода-вывода для центральной ЭВМ.
ОСОБЕННОСТИ ПЕРВОГО ЭТАПА Все СУБД базируются на мощных мультипрограммных операционных системах (MVS, SVM, RTE, OSRV, RSX, UNIX), поэтому в основном поддерживается работа с централизованной базой данных в режиме распределенного доступа. Функции управления распределением ресурсов в основном осуществляются операционной системой (ОС). Поддерживаются языки низкого уровня манипулирования данными, ориентированные на навигационные методы доступа к данным. Значительная роль отводится администрированию данных.
Проводятся серьезные работы по обоснованию и формализации реляционной модели данных, и была создана первая система (System R), реализующая идеологию реляционной модели данных. Проводятся теоретические работы по оптимизации запросов и управлению распределенным доступом к централизованной БД, было введено понятие транзакции. Результаты научных исследований открыто обсуждаются в печати, идет мощный поток общедоступных публикаций, касающихся всех аспектов теории и практики баз данных, и результаты теоретических исследований активно внедряются в коммерческие СУБД.
ВТОРОЙ ЭТАП - ЭПОХА ПЕРСОНАЛЬНЫХ КОМПЬЮТЕРОВ ОСОБЕННОСТИ ВТОРОГО ЭТАПА Все СУБД были рассчитаны на создание БД в основном с монопольным доступом. И это понятно. Компьютер персональный, он не был подсоединен к сети, и база данных на нем создавалась для работы одного пользователя. В редких случаях предполагалась последовательная работа нескольких пользователей, например, сначала оператор, который вводил бухгалтерские документы, а потом главбух, который определял проводки, соответствующие первичным документам. Большинство СУБД имели развитый и удобный пользовательский интерфейс, В большинстве существовал интерактивный режим работы с БД, как в рамках описания БД, так и в рамках проектирования запросов. Кроме того, большинство СУБД предлагали развитый и удобный инструментарии для разработки готовых приложений без программирования. Инструментальная среда состояла из готовых элементов приложения в виде шаблонов экранных форм, отчетов, этикеток (Labels), графических конструкторов запросов, которые достаточно просто могли быть собраны в единый комплекс. Во всех настольных СУБД поддерживался только внешний уровень представления реляционной модели, то есть только внешний табличный вид структур данных.
При наличии высокоуровневых языков манипулирования данными типа реляционной алгебры и SQL в настольных СУБД поддерживались низкоуровневые языки манипулирования данными на уровне отдельных строк таблиц. В настольных СУБД отсутствовали средства поддержки ссылочной и структурной целостности базы данных. Эти функции должны были выполнять приложения, однако скудость средств разработки приложений иногда не позволяла это сделать, и в этом случае эти функции должны были выполняться пользователем, требуя от него дополнительного контроля при вводе и изменении информации, хранящейся в БД. Наличие монопольного режима работы фактически привело к вырождению функций администрирования БД и в связи с этим - к отсутствию инструментальных средств администрирования БД. И, наконец, последняя и в настоящий момент весьма положительная особенность - это сравнительно скромные требования к аппаратному обеспечению со стороны настольных СУБД. Вполне работоспособные приложения, разработанные, например, на Clipper, работали на PC 286.
ТРЕТИЙ ЭТАП - РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ Хорошо известно, что история развивается по спирали, поэтому после процесса «персонализации» начался обратный процесс - интеграция. Множится количество локальных сетей, все больше информации передастся между компьютерами, остро встает задача согласованности данных, хранящихся и обрабатывающихся в разных местах, но логически друг с другом связанных, возникают задачи, связанные с параллельной обработкой транзакций - последовательностей операций над БД, переводящих ее из одного непротиворечивого состояния в другое непротиворечивое состояние. Успешное решение этих задач приводит к появлению распределенных баз данных, сохраняющих все преимущества настольных СУБД и в то же время позволяющих организовать параллельную обработку информации и поддержку целостности БД.
ОСОБЕННОСТИ ТРЕТЬЕГО ЭТАПА Практически все современные СУБД обеспечивают поддержку полной реляционной модели, а именно: структурной целостности - допустимыми являются только данные, представленные в виде отношений реляционной модели; языковой целостности, то есть языков манипулирования данными высокого уровня (в основном SQL); ссылочной целостности - контроля за соблюдением ссылочной целостности в течение всего времени функционирования системы, и гарантий невозможности со стороны СУБД нарушить эти ограничения. Большинство современных СУБД рассчитаны на многоплатформенную архитектуру, то есть они могут работать на компьютерах с разной архитектурой и под разными операционными системами, при этом для пользователей доступ к данным, управляемым СУБД, на разных платформах практически неразличим.
Необходимость поддержки многопользовательской работы с базой данных и возможность децентрализованного храпения данных потребовали развития средств администрирования БД с реализацией общей концепции средств защиты данных. Потребность в новых реализациях вызвала создание серьезных теоретических трудов по оптимизации реализации распределенных БД и работе с распределенными транзакциями и запросами с внедрением полученных результатов в коммерческие СУБД. Для того чтобы не потерять клиентов, которые ранее работали на настольных СУБД, практически все современные СУБД имеют средства подключения клиентских приложений, разработанных с использованием настольных СУБД, и средства экспорта данных из форматов настольных
СУБД ТРЕТЬЕГО ЭТАПА РАЗВИТИЯ К этому этапу можно отнести разработку ряда стандартов в рамках языков описания и манипулирования данными (SQL 89, SQL 92, SQL 99) и технологий по обмену данными между различными СУБД, к которым можно отнести и протокол ODBC (Open Data. Base Connectivity), предложенный фирмой Microsoft. Так же к этому этапу можно отнести начало работ, связанных с концепцией объектноориентированных БД - ООБД. Представителями СУБД, относящимся ко второму этапу, можно считать MS Access 97 и все современные серверы баз данных Огас1 е 7. 3, 0 гас1 е 8. 4, MS SQL 6. 5, MS SQL 7. 0, System 11, Informix, DB 2, SQL Base и другие современные серверы баз данных, которых в настоящий момент насчитывается несколько десятков.
ЧЕТВЕРТЫЙ ЭТАП - ПЕРСПЕКТИВЫ РАЗВИТИЯ СИСТЕМ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ Этот этап характеризуется появлением новой технологии доступа к данным- интранет. Основное отличие этого подхода от технологии клиент-сервер состоит в том, что отпадает необходимость использования специализированного клиентского программного обеспечения. Для работы с удаленной базой данных используется стандартный броузер Internet, например Microsoft Internet. Explorer, и для конечного пользователя процесс обращения к данным происходит аналогично использованию Internet. При этом встроенный в загружаемые пользователем HTML-страницы код, написанный обычно на языках Java, Java-script, Perl и других, отслеживает все действия пользователя и транслирует их в низкоуровневые SQL-запросы к базе данных, выполняя, таким образом, ту работу, которой в технологии клиентсервер занимается клиентская программа.
Удобство данного подхода привело к тому, что он стал использоваться не только для удаленного доступа к базам данных, но и для пользователей локальной сети предприятия. Простые задачи обработки данных, не связанные со сложными алгоритмами, требующими согласованного изменения данных во многих взаимосвязанных объектах, достаточно просто и эффективно могут быть построены по данной архитектуре. В этом случае для подключения нового пользователя к возможности использовать данную задачу не требуется установка дополнительного клиентского программного обеспечения. Однако алгоритмически сложные задачи рекомендуется реализовывать в архитектуре «клиент-сервер» с разработкой специального клиентского программного обеспечения.
ЗАКЛЮЧЕНИЕ У каждого из вышеперечисленных подходов к работе с данными есть свои достоинства и свои недостатки, которые и определяют область применения того или иного метода, и в настоящее время все подходы широко используются.
Историю развития баз данных можно разделить на четыре периода.
1. Период становления – начало 60-х - начало 70-х гг . В этот период появляется сам термин «база данных» и создается несколько первоначальных систем. Основой появления баз данных явилось предложение конца 50-х годов использовать файлы для хранения исходных данных. Основное требование к таким файловым системам – быть совместно используемым хранилищем данных. В последующем стало очевидным, что совместно используемые данные, должны обладать специфическими свойствами, в частности: независимость данных, отсутствие дублирования и противоречивости, контроль прав доступа к данным, эффективная техника доступа к данным, а также многие другие.
Осознание этих фактов, а также появление больших компьютеров с магнитными дисками в качестве носителей данных привело к появлению в середине 60-х гг. первых систем управления базами данных, из которых наиболее развитой оказалась система IMS фирмы IMB, которая поддерживала иерархическую структуру данных. Бахман в 1963 г. разработал первую промышленную систему баз данных IDS. СистемаIDSподдерживала сетевую организацию данных на магнитных носителях.
Ассоциация CODASYL, являющаяся органом, разработавшим язык программирования Кобол, в 1967 г. организовала рабочую группу по базам данных. Эта группа обобщила языковые спецификации систем баз данных и в 1969 и 1971 гг. издала соответствующие отчеты, которые по наименованию рабочей группы (DataBaseTaskGroup) получили названиеDBTG69,DBTG71. Основой избранного Рабочей группой подхода послужила сетевая структура данных и способы навигации по ней, разработанные в системе IDS, однако сетевая модель данных в отчетах DBTG получила существенное развитие и обоснование.
Типичным представителем системы, поддерживающей предложения DBTGCODASYLявилась Integrated Database Management System (IDMS) компании Cullinet Software, Inc., предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем.
В этот же период четко выкристаллизовались два подхода относительно проблемы замкнутости систем баз данных. Системы замкнутого типа характеризуются тем, что они не содержат в своем составе традиционных языков программирования, а имеют непроцедурные языки запросов. Основной целью в данном случае является создание системы, с применением которой мог бы справиться не специалист по программированию К таким системам относились TDMS иUL/1.
Системы с включаемыми языками помимо собственно языков манипулирования базами данных предоставляют также языковые и инструментальные средства разработки приложений, с использованием существующих языков программирования. Этот принцип, в частности, исповедовался DBTG.
В конце данного периода появился термин информационно-управляющая система (MIS). В то время подMISпонималась система баз данных, ориентированная на поиск данных и обеспечивающая возможность работы с удаленного терминала.
Период развития – 70-е годы . Концепция баз данных широко распространяется благодаря повышению характеристик аппаратного обеспечения компьютеров. Идет успешное внедрение систем, поддерживающих иерархическую и сетевую структуры данных.
Все этот период продолжалась работа DBTG CODASYL. Была специфицирована система языков для баз данных CODASYL, которая включила следующие группы языковых спецификаций:
Язык описания данных ЯОД (Data Definition Language - DDL). Представляет собой описание концептуальной схемы в терминах сетевой структуры данных.
Средства базы данных языка Кобол . Представляет собой средства обеспечения интерфейса языка Кобол с базой данных, описанной в DDL. В Кобол включены средства языка манипулирования данными.
Средства базы данных языка Фортран . Представляет собой средства обеспечения интерфейса языка Фортран с базой данных, описанной в DDL. В Кобол включены средства языка манипулирования данными.
Средства конечного пользователя . Определяет интерфейс пользователя случае, когда такой пользователь управляет базой данных, описанной в DDL.
Язык описания хранения данных ЯОХД (Data Stored Definition Language - DSDL). Представляет собой язык, который отображает концептуальную схему, описанную в DDL, во внутреннюю схему.
В 1975 г. появился отчет рабочей группы ANSI/X3/SPARCАмериканского Национального Института Стандартов, который явился значительной вехой в развитии проблематики баз данных. Перед группой была поставлена задача исследовать, в какой мере целесообразно ставить вопрос о стандартизации баз данных и СУБД и что именно может быть подвержено стандартизации. Группа пришла к выводу, что если и ставить вопрос о стандартизации, то только относительно интерфейсов, которые могут существовать между различными компонентами СУБД, сами программные компоненты ни в коем случае подвергаться стандартизации не могут. В связи с этим они направили свои последующие усилия на выявление таких интерфейсов и, в конце концов, пришли к формулировке трехуровневой архитектуре баз данных, которая стала классической и не потеряла свою актуальность до сих пор.
Однако этот период в большей мере характеризуется появлением реляционной модели данных, предложенной в 1970 г. сотрудником института фирмы ИБМ в Сан-Хосе Э.Ф. Коддом, всесторонними исследованиями теоретических и прикладных вопросов этой модели, разработкой экспериментальных реляционных СУБД. Теоретические исследования привели, в конце концов, к созданию формальной теории баз данных, которая до этого носила описательный характер. На протяжении многих лет многие ведущие формы проводили экспериментальные исследования по созданию прототипов реляционных СУБД, повышению их эффективности и функциональности. В конце 70-х гг. появляются первые промышленные реляционные СУБД.
Период зрелости – 80-е годы . Реляционная модель получила полное теоретическое обоснование. Разработаны крупные реляционные СУБД Oracle, Informix, и другие. Промышленные реляционные системы получают широкое распространение во всех сферах человеческой деятельности. Реляционные системы практически вытеснили с мирового рынка ранние СУБД иерархического и сетевого типа.
Дальнейшее развитие реляционных СУБД шло в следующих направлениях:
Удобство применения . Появление персональных компьютеров сделал принципиальным вопрос удобства использования программ, что также относилось и к СУБД. На протяжении всего этого периода интенсивно развивается внешний интерфейс взаимодействия пользователей с базами данных.
Многоплановость . Изначально базы данных разрабатывались для хранения и обработки символьной информации и традиционно использовались в таких сферах, как обработка экономической информации, статистика, банковское дело, системы резервирования, информационные системы различного направления. Появление спроса к базам данных в нетрадиционных сферах их применения, системы автоматизации проектирования, издательское дело и другие, потребовали хранения в базах данных и обработки изображений, звуков, полнотекстовой информации.
Этот период также характеризуется теоретическими и экспериментальными исследованиями в области баз знаний. Разрабатываются многочисленные экспертные системы, использующие базы знаний. В подавляющем большинстве случаев базы знаний разрабатываются на основе реляционных СУБД.
Постреляционный период – с начало 90-х гг . В этот период начались проводиться интенсивные исследования по дедуктивным и объектно-ориентированным базам данных, а также разработка исследовательских прототипов таких систем.
Особое место в развитии проблематики объектно-ориентированных СУБД занимает деятельность группы по управлению объектными базами данных ODMG(ObjectDataManagementGroup), - неприбыльным консорциумом производителей объектных баз данных и других организаций, заинтересованных в выработке стандартов по хранению объектов в базах данных.ODMGбыла создана в 1991 г. В 1993 г. группа выпустила свой первый стандарт –ODMG-93. В 1995 г. был опубликован усовершенствованный вариант этого стандарта.
В связи с развитием Интернет-технологий прикладываются большие усилия по внедрению баз данных в Интернет. Возникают различные подходы по включению СУБД с их базами данных во всемирную паутину, начиная от простейших «публикаций» баз данных в Интернет и заканчивая разработкой web-серверов баз данных, которые в состоянии предоставлять весь спектр услуг пользователям Интернета по использованию баз данных на сервере.
Наконец, интенсивно развиваются исследования и разработки по представлению и манипулированию структурами данных в Интернет.
Базы данных и знаний 9
История развития баз данных представляет собой историю развития систем управления данными во внешней памяти ЭВМ. На первых электронно-вычислительных машинах существовало 2 вида внешних устройств – магнитные ленты и магнитные барабаны. Магнитные ленты обладали достаточно большой емкостью, но основным их недостатком было то, что для чтения информации, находящейся в середине или конце ленты необходимо было прочитать весь предыдущий участок. Магнитные барабаны давали возможность произвольного доступа к памяти, но объем хранимой на них информации был ограничен. В тот момент говорить о какой-либо системе управления данными во внешней памяти не приходилось. Каждая прикладная программа, которой требовалось хранить данные во внешней памяти, сама определяла расположение данных на магнитной ленте или барабане. Функции информационного обмена между оперативной и внешней памятью, именование и структуризацию данных так же выполняла прикладная программа.
История баз данных начинается с появлением магнитных дисков и насчитывает более 30 лет. В 1968 г. была введена в эксплуатацию первая промышленная СУБД – система IMS фирмы IBM; в 1975 г. появился первый стандарт СУБД, разработанный ассоциацией по языкам систем обработки данных – CODASYL (Conference of Data System Language). Этот стандарт определил ряд фундаментальных понятий в теории систем БД, которые до сих пор являются основополагающими для сетевой модели данных. В 1981 году Э.Ф. Кодд создал реляционную модель данных и применил к ней операции реляционной алгебры. В истории баз данных можно выделить следующие этапы:
1. Файлы и файловые системы.
2. Базы данных на больших ЭВМ. Первые СУБД.
3. Эпоха персональных компьютеров. Настольные СУБД.
4. Распределенные базы данных.
Важным шагом в развитии информационных систем явилось создание централизованных систем управления файлами (СУФ) – систем, позволяющих создавать, редактировать, копировать, перемещать файлы. В настоящее время такие системы входят в состав любой операционной системы. Система управления файлами выполняет следующие функции:
· распределение внешней памяти,
· отображение имен файлов в соответствующие адреса во внешней памяти,
· обеспечение доступа к данным.
При этом СУФ не знает конкретной структуры файла, организация работы с записями файла ложится на ту прикладную программу, которая работает с файлом. Кроме того, в СУФ реализован децентрализованный доступ к файлам – все действия, которые конкретный пользователь имеет право производить с конкретным файлом, закодированы и хранятся совместно с файлом. В СУФ так же было невозможно одновременно работать с одним файлом нескольким пользователям.
Первые базы данных на больших ЭВМ (типа IBM 360/370, ЕС ЭВМ, разных моделях Hewlett Packard) появились в 70-х годах прошлого века. БД хранились во внешней памяти центральной ЭВМ. Пользователями БД были задачи, запускаемые, в основном, в пакетном режиме. Интерактивный режим доступа обеспечивался с помощью консольных терминалов, которые не обладали собственными вычислительными ресурсами (процессором, оперативной и внешней памятью) и служили только устройствами ввода-вывода для центральной ЭВМ. Программы доступа к БД писались на обычных языках программирования и запускались, как обычные числовые программы. СУБД этого периода работали с централизованной базой данных в режиме распределенного доступа, при этом функции управления распределением ресурсов выполнялись операционной системой. Кроме того, СУБД поддерживали языки манипулирования данными, администрирование данных. Именно в это время проводятся серьезные работы по обоснованию и формализации реляционной модели данных.
С появлением персональных компьютеров изменились условия использования вычислительной техники в организациях и фирмах: Так как техника стала доступна, компьютеры превратились в удобный инструмент для ведения документации и учетных функций фирм. В это время появляются так называемые настольные СУБД, позволяющие, с одной стороны, хранить в упорядоченном виде большие объемы информации, и, с другой стороны, имеющие удобный интерфейс для заполнения данных и генерации различных отчетов.
Основные отличительные черты этого этапа развития БД следующие:
1. Стандартизация высокоуровневых языков манипулирования данными – разработка и внедрение стандарта SQL92 во все СУБД.
2. Все СУБД были рассчитаны на создание баз данных с монопольным доступом.
3. Большинство СУБД имели развитый и удобный пользовательский интерфейс, но при этом в них отсутствовали средства поддержки ссылочной и структурной целостности данных и средства администрирования баз данных.
4. Скромные требования к аппаратному обеспечения со стороны настольных СУБД.
В отличие от настольных СУБД распределенные СУБД ориентированы на обработку данных, хранящихся в разных местах, но логически связанных друг с другом. Они позволяют организовать параллельную обработку информации и поддержку целостности данных. Особенностями этого этапа развития баз данных являются следующие:
1. Распределенные СУБД поддерживают структурную, языковую и ссылочную целостность баз данных.
2. Большинство СУБД могут работать на компьютерах с разной архитектурой и под разными операционными системами.
3. Все современные распределенные СУБД имеют средства подключения клиентских приложений, разработанных с использованием настольных СУБД и средства экспорта данных из форматов настольных СУБД третьего этапа развития.
4. На этом этапе разработан ряд стандартов языков описания и манипулирования данными (SQL89, SQL92, SQL99) и технологий обмена данными между различными СУБД (протокол ODBC).
5. На этом же этапе начаты работы, связанные с концепцией объектно-ориентированных баз данных. Представителями этого этапа можно считать MS Access 2000, современные серверы баз данных Oracle 7.3, Oracle 8.4, MS SQL 6.5, SQL 7.0, Informix, DB2 и др.