Основные компоненты системы баз данных
Система БД включает два основных компонента: собственно базу данных и систему управления базами данных – СУБД (рис. 1.6). Большинство СОД включают также программы обработки данных (прикладное программное обеспечение, ППО), которые обращаются к дан-ным через СУБД.
Рис.1.6. Компоненты системы баз данных
В соответствии с рис. 1.6 СУБД обеспечивает выполнение двух групп функций:
предоставление доступа к базе данных прикладному программному обеспечению (или квалифицированным пользователям);
управление хранением и обработкой данных в БД.
Таким образом, обращение к базе данных возможно только через СУБД.
БД предназначена для хранения данных информационной системы. Пользователи обращаются к базе данных обычно не напрямую через средства СУБД, а с помощью внешнего интерфейса – приложения, входящего в состав АИС. Если пользователей можно разделить на группы по характеру решаемых задач, то приложений может быть несколько (по количеству задач или групп пользователей). Например, для библиотеки можно выделить три группы пользователей: читатели, которым нужно осуществлять поиск книг по различным признакам; сотрудники, выдающие и принимающие у читателей книги (библиотекари) и сотрудники отдела комплектации, осуществляющие приём новых книг и списание старых.
Развитие концепции БД: от файловых систем к распределенным базам данных
Формами организации информации являются файлы данных, персональные БД, интегрированные БД, базы пространственных данных для использования в ГИС, распределенные БД.
Эволюцию развития БД - от файлов данных до многомерных БД можно представить в виде следующих этапов:
60-е годы – первые массивы данных на перфокартах;
70-е годы – массивы данных на магнитных лентах;
80-е годы – банки данных, иерархические и сетевые БД;
90-е годы – реляционные БД (сети ЭВМ);
21 век – доступ к БД через web-интерфейс, многомерные БД.
Файловые системы. Недостатком их является недостаточные возможности управления данными, большие затраты труда программистов, дублирование разработок.
БД это множество взаимосвязанных единиц данных, которые могут обрабатываться одной или несколькими прикладными системами. Преимуществами БД являются:
наличие метаданных,
поддержка целостности БД (все изменения в различных таблицах производятся в соответствии с установленными правилами);
одновременный доступ к данным нескольких пользователей;
ориентированные на пользователя запросы и отчеты;
представление сложных структур информации, когда объектом хранения являются не только данные, но описания структур данных;
сокращение дублирования информации;
независимость прикладных программ от изменений описаний данных и наоборот;
сокращение затрат на обслуживание БД;
возможности создания интегрированных баз данных;
множество пользователей и прикладных программных приложений;
индексация по основным ключам путем автоматической рубрикации;
возможности поиска данных по любому логическому выражению (для нескольких атрибутов), полнотекстовый поиск (с учетом близости слов), комбинированный (по словам и атрибутам);
экспорт – импорт данных в другие СУБД, ASCII и XML файлы, HTML, PDF, rtf-документы.
Краткая характеристика современных систем управления базами данных
СУБД – это программно-технологический комплекс, интегрирующий аппаратные средства, БД на технических носителях, программное обеспечение управления данными в самом широком смысле этого термина (операции выборки, линейных преобразований БД и др.), а также программируемую логику и набор процедур.
Понятия схемы и подсхемы, логический и физический уровни представления данных
Принципиально важное свойство СУБД заключается в том, что она позволяет различать и поддерживать два независимых взгляда на базу данных - взгляд пользователя, часто называемый логическим представлением данных, и "взгляд" системы, называемый физическим представлением данных, который характеризует организацию хранимых данных. Пользователя не интересуют при его работе с базой данных байты и биты, представляющие данные в среде хранения, их размещение в памяти, указатели, поддерживающие связи между различными структурными компонентами хранимых данных, выбранные методы доступа. В то же время, все эти факторы важны для выполнения функций управления данными самой СУБД. Поддержка двух независимых представлений базы данных фактически сводится к тому, что задача формирования из хранимых данных такого представления данных, которое отражает взгляд пользователя, возлагается на СУБД.
Логическое представление – на уровне проектирования, сам проект. А физическое представление – это то, что мы потом реализуем. Схема – коллекция объектов БД, содержащих таблицы, индексы, кластеры, представления, снимки – журналы репликации, последовательности, синонимы, пакеты. При проектировании больших БД выделяются подсхемы. Объекты схемы – это абстракция (логическая структура) составляющих базы данных. База данных разделяется на одно или более логических частей, называемых табличными пространствами. Табличные пространства используются для логической группировки данных между собой. Сегментирование групп по табличным пространствам упрощает администрирование этих групп. Каждое табличное пространство состоит из одного или более файлов данных. Используя несколько файлов данных для одного табличного пространства, можно распределить их по разным дискам, увеличив тем самым скорость ввода–вывода и, соответственно, производительность системы. Таким образом, БД состоит из табличных пространств, которые, в свою очередь, состоят из файлов данных. А файлы данных могут быть разбросаны по нескольким физическим дискам. Под физической структурой БД, в данном случае, подразумевается то, какие таблицы должны предоставлять нужную нам информацию и какие поля (атрибуты) должны в них входить. При проектировании физической структуры БД мы должны учитывать необходимость полноты представления данных и стремиться к исключению избыточности данных. Данные должны быть не противоречивы и представлены таким образом, чтобы все необходимые манипуляции с ними были просты и максимально эффективны. Выявив все сущности, информация о которых должна быть представлена в БД, и описав связи между ними, мы имеем логическую структуру БД.
Модели данных
Подробнее в лекции 5.
Основными моделями данных являются иерархическая, сетевая, реляционная, постреляционная, многомерная модели данных или комбинация этих моделей. Модель данных представляет собой множество структур данных, ограничений целостности и операций манипулирования данными [1,2,4]. С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними.
Описание (модель) предметной области, выполненное без ориентации на используемые в дальнейшем программные и технические средства, называется концептуальной (инфологической) моделью предметной области. Концептуальная модель предметной области указывает, какая информация будет содержаться и обрабатываться в проектируемой системе, не касаясь вопросов, как это будет реализовано. Структура данных, описывающая предметную область на инфологическом уровне, является проблемно-ориентированной и системно-независимой, то есть независимой от конкретной СУБД, ОС и аппаратного обеспечения.
Иерархическая модель данных стала применяться в шестидесятых годах, строится по принципу иерархии типов объектов, т. е. один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии,— подчиненными. Иерархическая модель данных организует данные в виде иерархической древовидной структуры. Эта структура строится из узлов и ветвей. Узел представляет собой совокупность атрибутов данных, описывающих некоторый объект. Наивысший узел в иерархической древовидной структуре называется корнем. Зависимые узлы располагаются на более низких уровнях дерева. Зависимые узлы могут добавляться как в вертикальном, так и в горизонтальном направлении без всяких ограничений. Связи (соединения) между узлами уникальны, Поэтому иерархическая модель данных обеспечивает только линейные пути доступа к данным и между главными и подчиненными типами объекта устанавливается линейная взаимосвязь “один ко многим». Каждый экземпляр корневого узла образует начало записи логической БД, т.е. иерархическая БД состоит из нескольких деревьев. Примером такой модели данных является описание комплектующих автомобиля (ручки, окна, болты, др.), рис.5. Примером иерархической СУБД является СУБД «Ока».
Достоинствами иерархической модели является то, что они наиболее полно отражают семантику предметной области; имеют развитые низкоуровневые средства управления данными во внешней памяти; позволяют построить эффективные прикладные системы. Иерархическая модель более естественно для человека отражает семантику предметной области. Поэтому она проста в понимании и использовании. Схема БД не декларируется явным образом и может изменяться в процессе развития и эксплуатации информационной системы.
Недостатки иерархической модели это громоздкие структуры данных при сложных БД и, как правило, - хранение избыточных данных; доступ к БД производится на уровне записей, между которыми поддерживаются явные связи, следствиями этого являются низкоуровневый навигационный стиль программирования и сложность использования таких систем непрограммистами; отсутствует физическая и логическая независимость данных, необходимы знания об их физической организации; пользователю приходится выполнять оптимизацию доступа к БД без поддержки системы.
Рисунок 5 - Фрагмент иерархической модели данных
В сетевой модели данных (рис.6), которая начала применяться в начале восьмидесятых годов, понятия главного и подчиненных объектов несколько расширены. Любой объект может быть и главным, и подчиненным (в сетевой модели главный объект обозначается термином «владелец набора», а подчиненный — термином «член набора»). Один и тот же объект может одновременно, выступать и в роли владельца, и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей. БД состоит из нескольких областей. Область содержит записи. В свою очередь запись состоит из полей, а набор, который объединяет записи, может размещаться в одной или нескольких областях. Достоинство сетевой модели это простота реализации часто встречающихся в реальном мире взаимосвязей, закладываемых в БД. Основной недостаток сетевой модели состоит в сложности управления данными, в т.ч и возможная потеря независимости данных при реорганизации БД. Сетевая модель использовалась в СУБД СЕТОР.
Рисунок 6 - Фрагмент сетевой БД
Реляционная модель была предложена в семидесятых годах, но получила широкое распространение только в середине восьмидесятых годов. В реляционной модели данных (рис.7) объекты и взаимосвязи между ними представляются с помощью таблиц. Взаимосвязи рассматриваются в качестве объектов (таблиц связей). Каждая таблица представляет один объект. В терминологии реляционной модели таблица называется отношением. Каждый столбец в таблице является атрибутом. Объекты (сущности) предметной области отображаются двумерной таблицей с заголовками, состоящими из имени и типа сущности. Строки такой таблицы представляют собой перечень атрибутов сущности. Назначается один или несколько атрибутов первичным ключом для поиска информации. Значения в столбце выделяются из домена, т.е. домен суть множество значений, которые может принимать некоторый атрибут. Для каждого атрибута всех таблиц фиксирован тип и длина данных. Соединение данных из разных таблиц обеспечивается операторами языка SQL.
Первичный ключ – это столбец, значения которого во всех строках разные. Он может объединять несколько столбцов. В некоторых СУБД первичный ключ может задаваться системой (ACCESS, Oracle). Связь реализуется при помощи внешнего ключа (это столбец таблицы, значения которого совпадают со значениями первичного ключа другой таблицы). Важным моментом является также использование значения NULL в таблицах реляционной БД. NULL – это отсутствующее значение информации в поле. Это поле обрабатывается особым образом.
Рисунок 7 – Фрагмент
реляционной БД
Реляционными СУБД являются DB2, Oracle, Paradox, Access, MySQL и др.
Достоинствами реляционной модели является простой и мощный математический аппарат, опирающийся на теорию множеств и математическую логику и обеспечивающий теоретический базис организации БД; обеспечение физической и логической независимости данных. Единственной конструкцией данных в реляционной модели является отношения (связи) между данными (на основании значений данных, а не физических указателей, как в ранних системах). Следствием этого является ненавигационный доступ к данным (отношения трактуются как операнды и результаты операции, а не обрабатываются поэлементно). Простота структуры данных и управления ими облегчает работу пользователей (как программистов, так и непрограммистов).
Недостатками реляционной модели являются минимальные возможности описания семантики предметной области. Рядовые реляционные системы работают медленнее систем, базирующихся на сетевой или иерархической модели данных. Рассмотрим эту модель более подробно.
Объектно-ориентированные БД (ООБД). В объектно-ориентированной модели данных любая сущность реального мира представляется — объектом. С объектом ассоциируется состояние и поведение. Состояние объекта определяется значениями его свойств — атрибутов. Значениями свойства могут являться примитивные значения (такие, как строки или целые числа) и не примитивные объекты. Не примитивный объект, в свою очередь, состоит из набора свойств, которые можно определять в терминах других объектов. Поведение объекта определяется с помощью методов, которые оперируют над состоянием объекта. У каждого объекта имеется определяемый системой уникальный идентификатор. Объекты, обладающие одними и теми же свойствами и поведением, группируются в классы. Объект может быть экземпляром одного или нескольких классов. Классы организуются в иерархии классов. Подкласс наследует свойства и методы суперкласса; кроме того, подклассы могут обладать индивидуальными свойствами и методами. В некоторых системах у класса может быть более одного суперкласса (множественное наследование), тогда как в других системах число суперклассов ограничено одним (одиночное наследование).
Системы ООБД позволяют пользователям определять абстракции; облегчают проектирование некоторых связей; устраняют потребность в определяемых пользователями ключах; поддерживают новый набор предикатов сравнения; в некоторых случаях устраняют потребность в соединениях; в некоторых ситуациях обеспечивают более высокую производительность, чем системы, основанные на реляционной модели; обеспечивают поддержку версий.
Современные ООБД дают пользователю возможность создания нового класса с атрибутами и методами, иметь классы, наследующие атрибуты и методы от суперклассов, создавать экземпляры класса, каждый из которых обладает уникальным объектным идентификатором, извлекать эти экземпляры по одному или группами, а также загружать и выполнять методы. ООБД позволяют определять объекты как совокупности других объектов, причем для совокупностей допускается несколько уровней вложенности. Свойства тоже могут иметь сложную структуру и определяться с помощью конструктора коллекций. Более того, они могут иметь в качестве значений не примитивные объекты, что дает возможность формировать глубоко вложенные объектные структуры. Многозначные свойства используются в объектно-ориентированных моделях данных для выражения сложных структур данных. В реляционной модели это достигается с помощью дополнительных отношений и соединений.
В модели ООБД имеется понятие идентификаторов объектов, автоматически генерируемых системой и гарантированно уникальных для каждого объекта. Это обстоятельство в сочетании с тем, что в модели ООБД устраняется потребность в определяемых пользователями ключах, дает объектно-ориентированным БД и другие преимущества.
В объектно-ориентированных БД отсутствуют средства оптимизации запросов; стандартной алгебры запросов; поддержки представлений; поддержки динамических изменений определений классов; имеются проблемы с безопасностью; ограничения с поддержкой целостности; ограниченные возможности настройки производительности; недостаточная поддержка сложных объектов; ограниченная интеграция с существующими объектно-ориентированными системами программирования; ограниченный выигрыш в производительности.
Эта модель используются в СУБД Oracle, Informix, PostgreSQL.
Многомерная модель, рис.8. Моделью данных является многомерный куб, где на измерениях определены некоторые иерархии, а в клетках этого куба находятся числовые значения. Операции извлечения данных из такого куба описываются в терминах поворотов, срезов, и иерархического "схлопывания" измерений с агрегированием значений (суммирование, взятие среднего и др.). Эта схема хорошо ложится на табличную организацию данных. Наиболее известный программный продукт этого класса - это Oracle Express Server.
Рисунок
8 – Схема перехода от реляционной модели
к многомерной
Пользователя редко интересуют все потенциально возможные комбинации значений измерений. Для этого используются срезы, отображения страниц, вращение, нарезка на кубики, агрегация, детализация.
Постреляционная модель - это качественное и количественное расширение реляционной модели. Если в реляционных моделях используется первая нормальная форма, то в постреляционных моделях данные описываются не первой нормальной формой, не требуется определять для поля специфический тип и длину. Благодаря этому, можно задать таблицу, в которую вложены другие таблицы. Если всю информацию свести в одну большую таблицу, такая таблица неизбежно будет содержать пустые клетки или избыточные данные, при использовании нескольких таблиц потребуется выполнять весьма ресурсоемкую операцию соединения, снижая тем самым эффективность работы СУБД.
6. Языки описания баз данных
Язык описания данных (ЯОД) – это язык, предназначенный для задания схемы базы данных. С его помощью описываются типы данных, подлежащих хранению в базе или выборке из нее, их структура и связи между собой. Исходные тексты, написанные на этом языке, после трансляции отображаются в управляющие таблицы и другую информацию, необходимую для работы СУБД с данными. В соответствии с полученным описанием СУБД может найти в базе требуемые данные, правильно преобразовать их и передать, например в прикладную программу, которой они потребовались. При записи данных в базу СУБД определяет место в памяти ЭВМ, куда их требуется поместить, преобразует к заданному виду, устанавливает необходимые связи.
Во всех СУБД имеются средства описания данных. В настоящее время в большинстве СУБД эти средства включаются в язык SQL. В некоторых СУБД язык описания данных существует отдельно. Например, в ГУ «ВНИИГМИ-МЦД» на основе концепций и предложений КОДАСИЛ (Ассоциация по языкам систем обработки данных) [3] разработан и применяется уже почти 35 лет Язык описания гидрометеорологических данных (ЯОД).
Совокупность гидрометеорологических данных имеет естественную иерархическую структуру, соответствующую ее разбиению на систему вложенных групп по значениям пространственных и временных ключей. На нижнем уровне этой иерархии расположены совокупности данных, соответствующие однократной реализации программы наблюдений в некотором пункте и в некоторый момент (срок) или интервал (например, сутки, месяц) времени. Группы также имеют иерархическую структуру, которая соответствует дальнейшей классификации данных по пространственно-временным ключам, внутренним для программы наблюдений, а также по именам параметров или группам имен. Так как на верхних уровнях классификация идет только по значениям ключей (в группы выделяются совокупности данных с фиксированными значениями некоторого ключа), верхняя часть дерева является однородной - все поддеревья, исходящие из узлов одного уровня, имеют идентичную структуру. На нижних уровнях за счет классификации по именам дерево может быть не однородным и достаточно сложным. Одну и ту же совокупность данных можно представить различными иерархическими структурами. Например, средствами этого языка можно описать данные, как в виде плоских таблиц, так и иерархических структур данных. Структурными единицами записи в ЯОД являются:
- Элементы - наименьшие неделимые единицы данных;
- Группы - совокупность нескольких элементов или других (внутренних) групп.
Имеются следующие типы групп:
GRE - простая неповторяющаяся группа элементов;
GRP - повторяющаяся группа с индексами и с фиксированным числом экземпляров;
GRV - повторяющаяся группа с одним индексом и с переменным числом экземпляров;
GRK - повторяющаяся группа с ключами и с переменным числом экземпляров;
GRR - неповторяющаяся группа, состоящая из переменного числа элементов из некоторого полного списка элементов, причем имя элемента идентифицируются ссылками на этот список.
Элементы бывают следующих типов:
KEY - ключ записи или группы;
IND - индекс записи или группы;
MRC - вид записи;
MIT - основной элемент;
CHA - характеристика основного элемента;
CNT - счетчик экземпляров группы GRK, GRV;
LNG - длина экземпляра записи, группы GRK, GRR;
REF - ссылка на список элементов группы GRR.
Язык выполняет три основных функции:
служит стандартом хранения данных на сменных носителях в Государственном фонде данных по гидрометеорологии. Использование ЯОД как средства конструирования и описания форматов данных позволяет достичь единства в собрании разнообразных данных весьма большого объема, что очень важно как при обслуживании пользователей, так и долговременном (бессрочном) хранении. При появлении новых технических носителей данные в форматах ЯОД переписываются на новые носители с меньшими затратами труда;
используется в качестве средства обмена данными. Наличие формализованного описания структуры данных позволяет достичь большего взаимопонимания между участниками обмена и избежать различных недоразумений. Хранение отдельного файла с описанием данных позволяет пользователям заранее ознакомиться с обменными структурами данных.
является входным языком системы управления данными АИСОРИ, которая имеет разнообразные средства работы с данными в форматах ЯОД для различных пользователей - разработчиков БД, прикладных программистов и конечных пользователей.
Языки манипулирования данными, концепции и возможности языка SQL
Для манипулирования данными созданы специальные языки, позволяющие реализовать все операции реляционной алгебры. Среди них наиболее распространенным является язык SQL (Structured Query Language – структурированный язык запросов) [2]. Язык SQL ориентирован на реляционные БД. Это язык высокого уровня, позволяющий с помощью единственного запроса соединять несколько таблиц в одну временную таблицу, вырезать требуемые строки и столбцы, т.е. выполнять операции селекции и проекции данных. Язык запросов SQL в стандарте ANSI 92 имеет множество расширений к этому стандарту. Не все СУБД поддерживают этот стандарт в полном объеме.
Команды SQL бывают интерактивными и вложенными. Интерактивный SQL используется для функционирования непосредственно в БД. Вложенный SQL состоит из команд SQL, помещённых внутри программ, которые обычно написаны на алгоритмических языках (типа Си, ПАСКАЛЬ, Java, др.). Это делает такие программы более мощными и эффективными.
Интерактивный и вложенный SQL имеют разделы:
DDL (Язык Определения Данных) - так называемый Язык Описания Схемы в ANSI - состоит из команд, которые создают объекты (таблицы, индексы, просмотры и так далее) в БД.
DML (Язык Манипулирования Данными) это набор команд, которые определяют, какие значения представлены в таблицах в любой момент времени.
DCD (Язык Управления Данными) состоит из средств, которые определяют, разрешить ли пользователю выполнять определённые действия или нет.
Определение типов данных является основной областью, в которой большинство коммерческих программ БД и официальный стандарт SQL не всегда совпадают. ANSI SQL-стандарт распознаёт только форматы типа text и number, в то время как большинство коммерческих программ используют и специальные типы, такие как DATA и TIME.
Поле типа CHAR имеет длину, определяемую максимальным числом символов, которые могут быть введены в это поле. Большая часть СУБД также имеют нестандартный тип, называемый VARCHAR, который является текстовой строкой и может иметь любую длину до определённого реализацией максимума (обычно 254 символа). Значения CHARACTER и VARCHAR включаются в одиночные кавычки как 'текст'. Различие между CHAR и VARCHAR в том, что CHAR должен резервировать достаточное количество памяти для максимальной длины строки, а VARCHAR распределяет память по мере необходимости. Символьные типы состоят из всех печатных символов, включая числа. Символьные значения сохраняются в компьютере как двоичные значения, но показываются пользователю как печатный текст. Преобразование выполняется по формату, определяемому СУБД. Команды состоят из одной или более логических частей, называемых предложениями. Предложения состоят из ключевых слов и аргументов. Например, предложения, "FROM Salespeope" и "WHERE city = ‘London’ ". Аргументы завершают или изменяют значение предложения. В примерах выше, Salespeople - аргумент, а FROM - ключевое слово. Аналогично " city = ‘London’ " - аргумент предложения WHERE.
Объекты это структуры БД, которым даны имена и которые сохраняются в памяти. Сюда относятся базовые таблицы, представления и индексы.
Квадратные скобки ( [ ] ) указывают части, которые могут не использоваться, а многоточия (...) указывают, что всё предшествующее может повторяться любое число раз.