Основные классификационные признаки СУБД

ИДИВИДУАЛЬНОЕ ЗАДАНИЕ

по дисциплине «Информатика»

на тему: «Общая характеристика систем управления базами данных»

Выполнила: Голосий О. А .

^{(Фамилия И.О.)}

Группа ОП/П01 курс II .

№ зачет. книжки СП069/10 .

Подпись: _______________________________

Преподаватель: к.т.н., доцент C.A. Михальчук

Оценка: ____________Дата: _______________

Подпись: _______________________________

Санкт-Петербург

Система управления базами данных

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

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

Внешний уровень

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

Концептуальный (промежуточный) уровень

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

Внутренний уровень

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

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

Функции СУБД

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

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

- имена, типы и размеры элементов данных;

- имена связей;

- накладываемые на данные ограничения поддержки целостности;

- имена санкционированных пользователей;

- внешняя, концептуальная и внутренняя схемы и отображения между ними;

- статистические данные (частота транзакций, счетчик обращения к объектам базы данных).

Системный каталог позволяет достичь определенных преимуществ:

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

- можно определить смысл данных, что поможет другим пользователям понять их назначение;

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

- благодаря централизованному хранению избыточность и противоречивость описания отдельных элементов данных могут быть легко обнаружены;

- внесенные в базу данных изменения могут быть запротоколированы;

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

- меры обеспечения безопасности могут быть дополнительно усилены;

- появляются новые возможности организации поддержки целостности данных;

- может выполняться аудит сохраняемой информации.

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

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

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

6. Сервисы контроля доступа к данным. СУБД должна иметь механизм, гарантирующий возможность только санкционированного доступа к базе данных. Иногда требуется скрыть некоторые хранимые в базе данных сведения от других пользователей. Напримk 838i87ci 7;р, менеджерам отделений компании можно было бы предоставить всю информацию, связанную с зарплатой сотрудников, но желательно скрыть ее от других пользователей. Кроме того, базу данных следует защитить от любого несанкционированного доступа. Термин безопасность относится к защите базе данных от преднамеренного или случайного несанкционированного доступа.

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

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

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

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

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

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

- программы статистического анализа, позволяющие оценить производительность или степень использования базы данных;

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

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

Компоненты СУБД

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

- процессор запросов. Это основной компонент СУБД, который преобразует запросы в последовательность низкоуровневых инструкций для контроллера базы данных;

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

- препроцессор языка DML. Этот модуль преобразует внедренные в прикладные программы DML - операторы в вызовы стандартных процедур базового языка. Для генерации соответствующего кода препроцессор языка DML должен взаимодействовать с процессором запросов;

- компилятор языка DDL. Компилятор языка DDL преобразует DDL-команды в набор таблиц, содержащих метаданные. Затем эти таблицы сохраняются в системном каталоге, а управляющая информация √ в заголовках файлов с данными;

- контроллер словаря. Контроллер словаря управляет доступом к системному каталогу и обеспечивает работу с ним. Системный каталог доступен большинству компонентов СУБД. В состав контроллера базы данных входят следующие основные программные компоненты:

- контроль прав доступа. Этот модуль проверяет наличие у данного пользователя полномочий для выполнения затребованной операции;

- процессор команд. После проверки полномочий пользователя для выполнения затребованной операции управление передается процессору команд;

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

- оптимизатор запросов. Этот модуль определяет оптимальную стратегию выполнения запросов;

- контроллер транзакций. Этот модуль осуществляет требуемую обработку операций с базой данных. Он управляет относительным порядком выполнения операций, затребованных в отдельных транзакциях;

- планировщик. Этот модуль отвечает за бесконфликтное выполнение параллельных операций с базой данных. Он управляет относительным порядком выполнения операций, затребованных в отдельных транзакциях;

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

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

Основные классификационные признаки СУБД

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

К СУБД относятся следующие основные виды программ:

- Полнофункциональные СУБД (ПФСУБД).═ К ПФСУБД относятся, например, такие пакеты как: Clarion Database Developer, DataBase, Dataplex, dBase IV, Microsoft Access, Microsoft FoxPro и Paradox R:BASE. ПФСУБД имеют развитый интерфейс, позволяющий с помощью команд меню выполнять основные действия с БД: создавать и модифицировать структуры таблиц, вводить данные, формировать запросы, разрабатывать отчеты, выводить их на печать и т. п. Для создания запросов и отчетов не обязательно программирование, а удобно пользоваться языком QBE (Query By Example ≈ формулировки запросов по образцу). Многие ПФСУБД включают средства программирования для профессиональных разработчиков. Некоторые системы имеют в качестве вспомогательных и дополнительные средства проектирования схем БД или CASE-подсистемы. Для обеспечения доступа к другим БД или к данным SQL-серверов полнофункциональные СУБД имеют факультативные модули.

- Серверы БД. Предназначены для организации центров обработки данных в сетях ЭВМ. Серверы БД реализуют функции управления базами данных, запрашиваемые другими (клиентскими) программами обычно с помощью операторов SQL. Примерами серверов БД являются следующие программы: NetWare SQL (Novell), MS SQL Server (Microsoft), InterBase (Borland), SQLBase Server (Gupta), Intelligent Database (Ingress) (см. пример учебника).

- Клиенты БД. В роли клиентских программ для серверов БД в общем случае могут использоваться различные программы: ПФСУБД, электронные таблицы, текстовые процессоры, программы электронной почты и т. д. При этом элементы пары клиент ≈ сервер могут принадлежать одному или разным производителям программного обеспечения. В случае, когда клиентская и серверная части выполнены одной фирмой, естественно ожидать, что распределение функций между ними выполнено рационально. В остальных случаях обычно преследуется цель обеспечения доступа к данным любой ценой. Примером такого соединения является случай, когда одна из полнофункциональных СУБД играет роль сервера, а вторая СУБД (другого производителя) ≈ роль клиента. Так, для сервера БД SQL Server (Microsoft) в роли клиентских (фронтальных) программ могут выступать многие СУБД, такие как: dBASE IV, Blyth Software, Paradox, DataBase, Focus, 1-2-3, MDBS III, Revelation и др.

- Средства разработки программ работы с БД. Используются для создания пользовательских приложений по работе с БД, серверов БД и их отдельных компонентов, клиентских программ. К средствам разработки программ для работы с БД относятся системы программирования (Clipper, Delphi, Power Builder (Borland), Visual Basic (Microsoft) и пр.); библиотеки программ для различных языков программирования; пакеты автоматизации разработок (SILVERRUN (Computer Advisers Inc.), S-Designor (SDP и Powersoft), ERwin (LogicWorks), Rational Rose и пр.).

- Дополнительные средства. Используются для управления данными и организации обслуживания БД (например, мониторы транзакций).

Классификация СУБД по характеру использования.

- Персональные СУБД обеспечивают возможность создания персональных БД и недорогих приложений, работающих с ними. Персональные СУБД или разработанные с их помощью приложения зачастую могут выступать в роли клиентской части многопользовательской СУБД. К персональным СУБД, например, относятся Visual FoxPro, Paradox, Clipper, dBase, Access и др.

- Многопользовательские СУБД включают в себя сервер БД и клиентскую часть и, как правило, могут работать в неоднородной вычислительной среде (с разными типами ЭВМ и операционными системами). К многопользовательским СУБД относятся, например, СУБД Oracle и Informix.

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

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

- позволяет определять базу данных с помощью языка определения данных (DDL);

- позволяет вставлять, обновлять, удалять и извлекать информацию из базы данных с помощью языка управления данными (DML);

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

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

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

Наиболее известные модели данных:

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

- сетевая. Под сетевой моделью данных понимается модель, состоящая из записей, элементов данных и связей типа один ко многим (1:M), установленных между записями. При этом связи типа многие ко многим (M:N) и рекурсивные связи поддерживаются с помощью декомпозиции;

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

Внутренний язык СУБД

Внутренний язык СУБД для работы с данными состоит из двух частей: языка определения данных (Data Definition Language - DDL) и языка управления данными (Data Manipulation Language - DML). Язык DDL используется для определения схемы базы данных, а язык DML - для чтения и обновления данных, хранимых в базе. Эти языки называются подъязыками данных, поскольку в них отсутствуют конструкции для выполнения всех вычислительных операций, обычно используемых в языках программирования высокого уровня. Во многих СУБД предусмотрена возможность внедрения операторов подъязыка данных в программы, написанные на языках программирования высокого уровня (COBOL, Fortran, Pascal, C, Ada). В этом случае язык высокого уровня принято называть базовым языком (host language).

Язык DDL

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

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

Язык DML - это язык, содержащий набор операторов для поддержки основных операций манипулирования содержащимися в базе данными.

К операциям управления данными относятся следующие:

- вставка в базу данных новых сведений;

- модификация сведений, хранимых в базе данных;

- извлечение сведений, содержащихся в базе данных;

- удаление сведений из базы данных.

Таким образом, одна из основных функций СУБД заключается в поддержке языка манипулирования данными, с помощью которого пользователь может задавать выражения для выполнения перечисленных выше операций с данными. Понятие манипулирования данными примk 838i87ci 7;нимо как к внешнему и концептуальному уровням, так и к внутреннему уровню. Однако на внутреннем уровне для этого необходимо определить очень сложные процедуры низкого уровня, которые позволяют выполнять доступ к данным весьма эффективно. На более высоких уровнях, наоборот, акцент переносится в сторону большей простоты использования и основные усилия направляются на обеспечение эффективного взаимодействия пользователя с системой. Языки DML отличаются базовыми конструкциями извлечения данных. Следует различать два типа языков DML: процедурный и непроцедурный. Основное отличие между ними заключается в том, что процедурные языки указывают то, как можно получить результат оператора языка DML, тогда как непроцедурные языки описывают то, какой результат будет получен. Как правило, в процедурных языках записи рассматриваются по отдельности, тогда как непроцедурные языки оперируют с наборами записей.

Процедурный язык DML

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

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

Непроцедурный язык DML

Непроцедурный язык DML - это язык, который позволяет указать лишь то, какие данные требуются, но не то, как их следует извлекать.

Непроцедурные языки DML позволяют определить весь набор требуемых данных с помощью одного оператора извлечения или обновления. С помощью непроцедурных языков DML пользователь указывает, какие данные ему нужны, не определяя способ их получения. СУБД транслирует выражение на языке DML в процедуру (набор процедур), которая обеспечивает манипулирование набором данных. Такой подход освобождает пользователя от необходимости знать детали внутренней реализации структур данных и особенности алгоритмов, используемых для извлечения и возможного преобразования данных. В результате работа пользователя получает определенную степень независимости от данных. Непроцедурные языки часто также называют декларативными языками. Реляционные СУБД обычно включают поддержку непроцедурных языков манипулирования данными - язык структурированных запросов SQL (Structured Query Language) или язык запросов по образцу QBE (Query by Example). Непроцедурные языки обычно проще в понимании и использовании, т. к. большая часть работы при этом выполняется СУБД, а не пользователем. Часть непроцедурного языка DML, которая отвечает за извлечение данных, называется языком запросов. Язык запросов можно определить как высокоуровневый узкоспециализированный язык, предназначенный для удовлетворения различных требований по выборке информации из базы данных.