Зачем нужны базы данных

SQLite

Провозгласившая себя самой распространенной СУБД в мире, SQLite зародилась в 2000 году и используется Apple, , Microsoft и . Каждый релиз тщательно тестируется. Разработчики SQLite предоставляют пользователям списки ошибок, а также хронологию изменений кода каждой версии.

Достоинства

• Нет отдельного серверного процесса;
• Формат файла – кросс-платформенный;
• Транзакции соответствуют требованиям ACID;
• Доступна профессиональная поддержка.

Недостатки

Не рекомендуется для:

• клиент-серверных приложений;
• крупномасштабных сайтов;
• больших наборов данных;
• программ с высокой степенью многопоточности.

Проектирование баз данных

Проектирование — самая трудная задача при работе с данными. Оно заключается не только в том, чтобы создать таблицу, указав наименование столбцов и тип данных. Это гораздо более сложный процесс, требующий специализированных знаний и умений. Говоря о типах баз данных в столбцах, подразумевается, например, способ их записи, который бывает символьный (строковый), числовой, календарный, NULL.

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

Современные технологии

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

Взаимодействие двух частей начинается после формирования запроса пользователя к базе. Клиентская секция направляет интерпелляцию к серверу, который выполняет команду. Результат обработки отправляется на персональное устройство клиента. Если управление исключает вариант клиент-сервер, то снижается производительность получения информации. Это происходит из-за необходимости копирования файла на личную ЭВМ с последующей обработкой.

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

Используется технология SQL — язык для создания запросов в структурированной форме. Модель применяется для обработки основных информативных сведений, которые содержатся в базах других приложений. Данные обрабатываются как на персональном устройстве, так и в базах основного сервера.

Теперь про базы

Получается, что БД — это совокупность данных, представленных определённым образом (в нашем случае — таблицей), и набор инструментов для манипулирования ими.

Данные могут быть сгруппированы не только в таблицы, но и в коллекции. У каждой базы есть свой инструмент для создания таблиц/коллекций, добавления, удаления или изменения данных, а также для составления выборки. В статье мы рассмотрим базы, которые состоят из таблиц, а инструментом манипулирования данными будет язык SQL.

Таблицы между собой могут объединяться в схемы — в одной базе данных их может быть несколько, а может и не быть деления на схемы вообще. Это зависит от БД.

Вернёмся к определению из Википедии и вспомним про слово «реляционные». Реляционные (от англ. relation — отношения) — это базы данных, таблицы которых могут выстраиваться в различных отношениях. Возьмём предыдущий пример и добавим в него тех самых «отношений». Создадим таблицу «Производитель», а ту, что в примере, обозначим как «Каталог».

Таблица «Производитель»:

Теперь таблицу «Каталог» можно оформить в другом виде:

Получилось так, что у таблиц «Каталог» и «Прозводитель» появились отношения. Значения из столбца «Каталог» ссылаются на строки из таблицы «Производитель». Добавлением отношения мы решили нескольких проблем:

1. Избавились от избыточных данных. Каталог стал занимать меньше места. Вместо хранения целой строки мы используем только номер строки из таблицы «Производитель». 
2. Снизили вероятность ошибиться. При смене названия производителя нам достаточно отредактировать строку в таблице «Производитель», «Каталог» останется без изменений. 

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

Мультимодельность

Термин «многовариантное хранение» вошел в обиход в 2011 году. Осознание проблем подхода и поиск решения заняли несколько лет, и к 2015 году устами аналитиков Gartner ответ был сформулирован:

• Из «Market Guide for NoSQL DBMSs — 2015»:
• Из «Magic Quadrant for ODBMS — 2016»:

Похоже, что в этот раз аналитики Gartner с прогнозом не ошиблись. Если зайти на страницу с основным рейтингом СУБД на DB-Engines, можно увидеть, что большая часть его лидеров позиционирует себя именно как мультимодельные СУБД. То же можно увидеть и на странице с любым частным рейтингом.

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

СУБД	Изначальная модель	Дополнительные модели
Oracle	Реляционная	Графовая, документная
MS SQL	Реляционная	Графовая, документная
PostgreSQL	Реляционная	Графовая*, документная
MarkLogic	Документная	Графовая, реляционная
MongoDB	Документная	Ключ-значение, графовая*
DataStax	Wide-column	Документная, графовая
Redis	Ключ-значение	Документная, графовая*
ArangoDB	—	Графовая, документная
OrientDB	—	Графовая, документная
Azure CosmosDB	—	Графовая, документная, реляционная

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

Список основных объектов СУБД

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

Управление базой данных — это система, которая состоит из следующих основных пунктов:

• управление информацией во внешней памяти;
• управление буферами оперативной памяти;
• управление транзакциями, то есть группой действий, направленных на выполнение одной операции;
• протоколирование;
• управление языковой системой базы данных.

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

Мультимодельные СУБД на основе документной модели

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

Итак, пусть коллекция содержит набор XML-документов следующего вида (хранить JSON-документы MarkLogic тоже позволяет):

Реляционная модель в MarkLogic

Реляционное представление коллекции документов можно создать с помощью шаблона отображения (содержимым элементов в примере ниже может быть произвольный XPath):

К созданному представлению можно адресовать SQL-запрос (например, через ODBC):

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

Графовая модель в MarkLogic

С поддержкой графовой (RDF) модели все обстоит примерно так же. Опять-таки с помощью шаблона отображения можно создать RDF-представление коллекции документов из примера выше:

К полученному RDF-графу можно адресовать SPARQL-запрос:

В отличие от реляционной, графовую модель MarkLogic поддерживает еще двумя другими способами:

1. СУБД может быть полноценным отдельным хранилищем RDF-данных (триплеты в нем будут называться в противоположность описанным выше extracted).
2. RDF в специальной сериализации может быть попросту вставлен в XML- или JSON-документы (и триплеты тогда будут называться unmanaged). Вероятно, это такая альтернатива механизмам и пр.

Хорошее представление о том, как «на самом деле» все устроено в MarkLogic, дает Optic API, в этом смысле оно низкоуровневое, хотя назначение его скорее обратное — попробовать абстрагироваться от используемой модели данных, обеспечить согласованную работу с данными в различных моделях, транзакционность и пр.

Как хранится информация в БД

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

• База данных;
• Таблица;
• Запись.

База данных

База данных — это высокоуровневное понятие, которое означает объединение совокупности данных, хранимых для выполнения одной цели.
Если мы делаем современный сайт, то все его данные будут храниться внутри одной базы данных. Для сайта онлайн-дневника наблюдений за погодой тоже понадобится создать отдельную базу данных.

Таблица

По отношению к базе данных таблица является вложенным объеком. То есть одна БД может содержать в себе множество таблиц.
Аналогией из реального мира может быть шкаф (база данных) внутри которого лежит множество коробок (таблиц).
Таблицы нужны для хранения данных одного типа, например, списка городов, пользователей сайта, или библиотечного каталога.
Таблицу можно представить как обычный лист в Excel-таблице, то есть совокупность строк и столбцов.
Наверняка каждый хоть раз имел дело с электронными таблицами (MS Excel).
Заполняя такую таблицу, пользователь определяет столбцы, у каждого из которых есть заголовок. В строках хранится информация.
В БД точно также: создавая новую таблицу, необходимо описать, из каких столбцов она состоит, и дать им имена.

Запись

Запись — это строка электронной таблицы.
Это неделимая сущность, которая хранится в таблице. Когда мы сохраняем данные веб-формы с сайта, то на самом деле добавляем новую запись в какую-то из таблиц базы данных. Запись состоит из полей (столбцов) и их значений. Но значения не могут быть какими угодно.
Определяя столбец, программист должен указать тип данных, который будет храниться в этом столбце: текстовый, числовой, логический, файловый и т.д. Это нужно для того, чтобы в будущем в базу не были записаны данные неверного типа.

Соберем всё вместе, чтобы понять, как будет выглядеть ведение дневника погоды при участии базы данных.

1. Создадим для сайта новую БД и дадим ей название «weather_diary».
2. Создадим в БД новую таблицу с именем «weather_log» и определим там следующие столбцы:
   • Город (тип: текст);
   • День (тип: дата);
   • Температура (тип: число);
   • Облачность (тип: число; от 0 (нет облачности) до 4 (полная облачность));
   • Были ли осадки (тип: истина или ложь);
   • Комментарий (тип: текст).
3. При сохранении формы будем добавлять в таблицу weather_log новую запись, и заполнять в ней все поля информацией из полей формы.

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

Реляционная база данных

Английское слово „relation“ можно перевести как связь, отношение.
А определение «реляционные базы данных» означает, что таблицы в этой БД могут вступать в отношения и находиться в связи между собой.
Что это за связи?
Например, одна таблица может ссылаться на другую таблицу. Это часто требуется, чтобы сократить объём и избежать дублирования информации.
В сценарии с дневником погоды пользователь вводит название своего города. Это название сохраняется вместе с погодными данными.
Но можно поступить иначе:

1. Создать новую таблицу с именем „cities“.
2. Все города в России известны, поэтому их все можно добавить в одну таблицу.
3. Переделать форму, изменив поле ввода города с текстового на поле типа «select», чтобы пользователь не вписывал город, а выбирал его из списка.
4. При сохранении погодной записи, в поле для города поставить ссылку на соответствующую запись из таблицы городов.

Так мы решим сразу две задачи:

• Сократим объём хранимой информации, так как погодные записи больше не будут содержать название города;
• Избежим дублирования: все пользователи будут выбирать один из заранее определённых городов, что исключит опечатки.

Связи между таблицами в БД бывают разных видов.
В примере выше использовалась связь типа «один-ко-многим», так как одному городу может соответствовать множество погодных записей, но не наоборот!
Бывают связи и других типов: «один-к-одному» и «многие-ко-многим», но они используются значительно реже.

InnoDB

Данный тип таблиц обеспечивает высокую производительность и устойчивое хранение данных в таблицах объемом вплоть до 1 Тбайт и нагрузкой на 
сервер до 800 вставок/обновлений в секунду.Особенности таблиц типа InnoDB:

• Таблицы не создаются в базах данных, и для каждой из таблиц не выделяется отдельный файл данных. Исключение – файл определения с расширением frm, который создается по умолчанию. Все таблицы хранятся в едином табличном пространстве, поэтому имена таблиц должны быть уникальными.
• Хранение данных в едином табличном пространстве позволяет снять ограничение на объем таблиц, так как файл с таблицами может быть разбит не несколько частей и распределен по нескольким дискам или даже хостам.
• Данный тип таблиц поддерживает автоматическое восстановление после сбоев.
• Обеспечивается поддержка транзакций.
• Единственный тип таблиц, поддерживающий внешние ключи и каскадное удаление.
• Выполняется блокировка на уровне отдельных записей.
• Расширенная поддержка кодировок.
• Рушатся при достижении объема в несколько гигабайт, однако заметно уступают в скорости и не поддерживают полнотекстовый поиск.

Создаем базу данных

Управление базами данных как объектами

Будем считать, что наша небольшая экскурсия по запросам и командам SQL со стороны «торгового зала» завершена. Заглянем теперь в его «служебные помещения» и познакомимся с тем, как создается сама база данных. Эта часть языка SQL не столь стандартизирована и сильно отличается в различных реализациях. Поэтому в дальнейших примерах я буду придерживаться синтаксиса, принятого в самой популярной на веб-серверах системе — MySQL.

MySQL — продукт шведской компании MySQL AB. Ее основатели — Дэвид Аксмарк, Аллан Ларсон и Майкл Видениус (последний больше известен по прозвищу — Монти). По одной из версий, первая часть названия продукта (My) — не что иное, как англизированная запись имени дочери М. Видениуса. Однако точно за происхождение названия сегодня не могут поручиться даже отцы-создатели. Существует версия, по которой «my» — это префикс, с которого начинались названия рабочих каталогов на их компьютерах.

Из всех команд чаще всего нам будут нужны три: CREATE (создать), ALTER (изменить) и DROP (уничтожить).

Чтобы создать новую базу данных с названием, ну скажем, OUR_SHOP, следует выполнить команду:

Еще лучше сразу при ее создании установить нужную кодировку (ведь по умолчанию в MySQL используется latin1). В итоге команда будет выглядеть так.

Если вы забыли сделать это сразу, не беда. Для того и существуют команды по изменению:

Когда, наигравшись вдоволь с пробной базой данных, вы захотите ее уничтожить, воспользуйтесь командой:

Управление таблицами

Чтобы создать таблицу GOODS, на которой мы отрабатывали манипуляции с данными, потребуется составить команду примерно такого вида:

Разберем эту команду подробнее. Тип INT устанавливается для столбцов с целочисленными данными, тип VARCHAR(100) обеспечивает хранение строк с длиной не более 100 символов, DECIMAL(10,2) соответствует действительным числам с не более чем десятью знаками и точностью в два знака после запятой.

Столбец ID объявлен первичным ключом (PRIMARY KEY).

Ключевое слово AUTO_INCREMENT означает, что при добавлении новых строк с неуказанным значением ID оно будет автоматически заполняться следующим значением. Это удобно, поскольку обычно нет нужды вручную указывать значения первичных ключей, а за тем, чтобы они были уникальными, пусть лучше следит база данных.

NOT NULL означает запрет на пустые значения в столбце, иными словами, гарантирует обязательность заполнения.

Команда DEFAULT задает значение по умолчанию — то, которое будет записываться в базу при добавлении новой строки, если не указано иное. В нашем случае она обеспечивает автоматическое объявление товара штучным (код = 1) в случае, если при добавлении новых строк не будет указан другой код.

Признак UNIQUE обеспечивает уникальность значений в колонке (в нашем случае — уникальность названий товаров).

Если в будущем вы захотите перенастроить объявленные командой CREATE столбцы таблицы, сделать это можно командой ALTER. Например, таблицу GOODS можно нарастить строчной колонкой REMARK (подкоманда ADD):

Поработав с ней немного и убедившись, что 50 символов для примечания явно недостаточно, увеличиваем максимальный размер строки до 250 (блок CHANGE):

Так как имя столбца мы не изменяли (новое совпадает со старым), то его просто повторяем в этой команде (как бы меняем само на себя).

И наконец, убедившись через какое-то время, что без примечания в товарном справочнике вполне можно обойтись, мы удаляем ставшую ненужной колонку (блок DROP):

Удалить таблицу целиком можно командой DROP:

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

Настройка и работа в Management Studio

1. Найдите Management Studio в меню «ПУСК» и запустите.
2. В открывшемся окне соединения с сервером выберите:
   В поле тип сервиса – Ядро СУБД
   В поле имя сервера – имя сервера, которое вы указали при установке
   Проверка подлинности – Проверка подлинности Windows
3. Нажмите кнопку «соединить».

Management Studio подключится к SQL Server и откроется основное окно программы:

Настоятельно рекомендуем изучить элемент программы под названием обозреватель объектов. Он позволяет работать с всеми структурными элементами баз данных на сервере через интерфейс похожий на проводник Windows.

Создать новый запрос можно если кликнуть на кнопке «Создать запрос». Запрос будет создан для текущей таблицы, которая указана в выпадающем списке сверху, в данный момент master.

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

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

 

Вот и все. Остальному можно научиться самостоятельно в процессе работы. 

Виды СУБД

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

По поддержке баз данных различных моделей данных СУБД различаются на:

• Иерархические;
• Сетевые;
• Реляционные;
• Объектно-ориентированные;
• Объектно-реляционные.

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

Сетевые отличаются от иерархических тем. Что каждый потомок в них может иметь несколько предков (множественное наследование).

Реляционные – безусловный лидер среди СУБД (93% всего рынка). Основаны на поддержке реляционных БД, то есть наборов таблиц и их отношений с возможность изменения обеих.

Объектно-ориентированные (ООСУБД) управляют абстрактными объектами, которые наделены свойствами и наделены методами для выполнения действий.

Объектно-реляционные (ОРСУБД) – реляционные СУБД, поддерживающие обьекты свойства и методы из объектно-ориентированной СУБД.

По способу доступа к БД:

• Файл серверные.
• Клиент-серверные;
• Встраиваемые.

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

По степени распределённой данных:

• Локальные: клиент и сервер – один компьютер;
• Распределенные – клиент и сервер разные компьютеры.

вступление

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

Супер ключ ⊇ ключевые кандидаты, из них выбирается первичный ключ

Различают ключевые термины
в реляционных базах данных.

Супер ключ (иногда также называемый верхним ключом)

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

Ключевой кандидат (также называемый кандидатным ключом или альтернативным ключом )

Минимальное подмножество атрибутов суперключа, которое позволяет идентифицировать кортеж (ключевые кандидаты ⊆ суперключ).

Первичный ключ

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

Формальное определение

Пусть дана некоторая реляционная схема R (каркас таблицы, т.е. все столбцы). Подмножество S атрибутов (столбцов) схемы R называется ключом, если:

Уникальность

R не может содержать два разных кортежа, в которых значения S одинаковы. Цель состоит в том, чтобы гарантировать, что никакое (возможное) выражение R не может содержать два разных кортежа, для которых значения S одинаковы: технически не законное, возможное заполнение таблицы может привести к появлению двух (технически разных) строк, ведущих к то же ключевое значение.

Определение

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

Минимализм

Так что ключ также является ключевым кандидатом, ни одно реальное подмножество S не должно уже удовлетворять условию уникальности.

Примеры

Литература (а)

ISBN	автор	Заголовок книги	…
0001	Ганс	В.	…
0002	Лутц	W.	…
0003	Питер	W.	…
0004	Питер	Икс	…
0005	Ральф	Y	…
…	…	…	…

Заказчик (б)

Фамилия	день рождения	место жительства	…
Хайнц Хоффманн	01.08.1966	Север, BBS	…
Альф Аппель	08.11.1957	Mömlingen	…
Себастьян Саншайн	04.08.1979	Гамбург	…
Клаус Клебер	15.04.1970	Франкфурт	…
Барбара Бахманн	17.10.1940	Кирхгайм	…
…	…	…	…

IsBossOf (c)

прямой руководитель (ID)	Сотрудник (ID)
002	104
030	512
115	519
234	993
234	670
…	…

а

Здесь ключ — это единственный атрибут. ISBN очень подходит для этого, потому что нет двух книг с одинаковым ISBN. Книги вполне могут иметь одно и то же название или принадлежать одному автору. Примечание: ISBN ( международный стандартный номер книги ) показан здесь только символически как серийный номер, ISBN на самом деле более сложен.

б

Здесь в качестве ключа используется комбинация двух атрибутов. Разработчик базы данных предполагает, что в один и тот же день нет клиентов с одинаковыми именами и днями рождения. Если в этом примере есть клиенты с одинаковым именем и день рождения в один и тот же день, то часть выбранных здесь атрибутов не может использоваться в качестве ключа.

c

Здесь только все атрибуты отношения рассматриваются как ключи. Персональный номер показывает, какой сотрудник компании является начальником какого другого сотрудника. Примечание. Записи данных этого отношения содержат только однозначные слева кортежи (1: n), потому что по техническим причинам и причинам, связанным с содержанием, у сотрудников обычно есть только один непосредственный руководитель. В принципе, конечно, кортежи отношений, которые являются типами отношений, могут содержать все возможные n: m назначений.

Система управления базами данных (СУБД)

Система управления базами данных (сокращенно СУБД) – это программное обеспечение для создания и работы с базами данных.

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

Реляционные СУБД и язык SQL

Реляционные и объектно-реляционные СУБД являются одними из самых распространенных систем. Они представляют собой таблицы, в которых каждый столбец (он называется «field» или «поле») упорядочен и имеет определенное уникальное название. Последовательность строк (их называют «records» или «записи») определяется последовательностью ввода информации в таблицу. При этом обрабатывание столбцов и строк может происходить в любом порядке. Таблицы с данными связаны между собой специальными отношениями, благодаря чему с данными из разных таблиц можно работать – к примеру, объединять их при помощи одного запроса.

Для управления реляционными базами данных применяется особый язык программирования – SQL. Сокращение расшифровывается как «Structured query language», в переводе на русский – «язык структурированных запросов».

Команды, которые используются в SQL, делятся на:

• манипулирующие данными,
• определяющие данные,
• управляющие данными.

Схема работы с базой данных выглядит следующим образом:

Другие модели баз данных (ООСУБД)

В последнее время на рынке СУБД появились продукты, представленные объектными и объектно-ориентированной моделью данных, такие как Gem Stone и Versant ОСУБД. Также производятся исследования в области многомерных и логических моделей данных.

Особенности объектно-ориентированных систем управления базами данных (ООСУБД):

• При интеграции возможностей базы данных с объектно-ориентированным языком программирования получается объектно-ориентированная СУБД.
• ООСУБД представляет данные как объекты одного или нескольких языков программирования.
• Такая система должна отвечать двум критериям: являться СУБД и должна быть объектно-ориентированной. То есть должна насколько это возможно соответствовать современным объектно-ориентированным языкам программирования. Первый критерий подразумевает: длительное хранение данных, управление вторичным хранилищем, параллельный доступ к данным, возможность восстановления, а также поддержку нерегламентированных запросов. Второй критерий подразумевает: сложные объекты, идентичность объектов, инкапсуляцию, типы или классы, механизм наследования, переопределение в сочетании с динамическим связыванием, расширяемость и вычислительную полноту.
• ООСУБД дают возможность моделирования данных в виде объектов.

А также поддержку классов объектов и наследование свойств и методов классов подклассами и их объектами.

На данный момент не существует общепринятого стандарта ООСУБД. Считается, что подобные модели данных находится на ранней стадии развития.

Примеры ООСУБД:

• D Gemstone;
• IRS;
• ORION;
• ONTOS.

Применение ООСУБД:

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