Бази даних-20210115T104840Z-001 / Реферат на тему _Современные СУБД_ / Using_MySql,_MS_SQL_Server_and_Oracle

Пример 12: запросы на объединение и преобразование столбцов в строки

Чтобы было проще пояснять, перепишем эту часть запроса в упрощённом

виде:

Часть FOR XML PATH (’’), TYPE относится к SELECT и говорит СУБД представить результат выборки как часть XML-документа для пути '' (пустой строки), т.е. — просто в виде обычной строки, хоть пока и выглядящей для СУБД как «некие данные в формате XML».

Промежуточный результат уже выглядит проще:

Метод value (путь, тип_данных) применяется в MS SQL Server для извлечения строкового представления из XML. Не вдаваясь в подробности, скажем, что первый параметр путь, равный . (точка) говорит, что нужно взять текущий элемент XML-документа (у нас «текущим элементом» является наша строка), а параметр тип_данных выставлен в nvarchar (max) как один из самых удобных в MS SQL Server типов для хранения длинных строк.

Результат уже почти готов:

STUFF ({строка с ", " в начале}, 1, 2, '')

Остаётся только избавиться от символов «, » в начале каждого списка авторов. Это и делает функция STUFF, заменяя в строке «{строка с ", " в

начале}»

символы с первого по второй (см. второй и третий параметры функции, равные 1 и

2соответственно) на пустую строку (см. четвёртый параметр функции, равный, '').

Ина этом с MS SQL Server — всё, переходим к Oracle. Здесь реализуется уже третий вариант решения:

Oracle I Решение 2.2.2.a

1SELECT "b name" AS "book",

2UTL RAW.CAST TO NVARCHAR2

3(

10)

11AS "author(s)"

12 FROM "books"

13JOIN "m2m books authors" USING ("b id"

14JOIN "authors" USING("a id"

15GROUP BY "b id",

ВOracle решение получается проще, чем в MS SQL Server, т.к. здесь (начиная

сверсии 11 gR2 поддерживается функция LISTAGG, выполняющая практически то

же самое, что и GROUP_CONCAT в MySQL. Таким образом, строки 4-8 запроса отвечают за «разворачивание в строку части столбца».

Вызовы метода UTL_RAW.CAST_TO_RAW в строках 6-7 и метода UTL_RAW.CAST_TO_NVARCHAR2 в строке 2 нужны для того, чтобы сначала представить текстовые данные в формате, который обрабатывается без

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 80/545

Пример 12: запросы на объединение и преобразование столбцов в строки

интерпретации значений байтов, а затем вернуть обработанные данные из этого формата в тек

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 81/545

Пример 12: запросы на объединение и преобразование столбцов в строки

стовый вид. Без этого преобразования информация об авторах превращается в нечитаемый набор спецсимволов.

В остальном поведение Oracle при решении этой задачи вполне эквивалентно поведению MySQL.

'IT Решение 2.2.2 .b{71}.

Решение 2.2.2.b

1SELECT 'b name'

2AS 'book',

3GROUP CONCAT(DISTINCT 'a name' ORDER BY 'a name' SEPARATOR ', ')

4AS 'author(s)',

5GROUP CONCAT(DISTINCT 'g name' ORDER BY 'g name' SEPARATOR ', ')

6AS 'genre(s)'

7 FROM 'books'

8JOIN 'm2m books authors' USING('b id')

9JOIN 'authors' USING('a id')

10JOIN 'm2m books genres' USING('b id')

11JOIN 'genres' USING('g id')

12GROUP BY 'b id'

13ORDER BY 'b name'

Решение 2.2.2.b для MySQL лишь чуть-чуть сложнее решения 2.2.2.а: здесь появился ещё один вызов GROUP_CONCAT (строки 5-6), и в обоих вызовах GROUP_CONCAT появилось ключевое слово DISTINCT, чтобы избежать дублирова-

ния информации об авторах и жанрах, которое появляется объективным образом в процессе выполнения объединения:

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 82/545

Пример 12: запросы на объединение и преобразование столбцов в строки

Данное решение для MS SQL Server тоже строится на основе решения 2.2.2. a{72} и отличается чуть большим количеством JOIN в общем табличном выражении (добавились строки 11-14), а также (по тем же причинам, что и в MySQL) добавлением DISTINCT в строках 18 и 25. Блоки строк 18-24 и 25-31 отличаются только именем выбираемого поля (в первом случае — a_name, во втором — g_name).

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 83/545

Пример 12: запросы на объединение и преобразование столбцов в строки

Здесь подзапрос в строках 13-30 представляет собой решение 2.2.2.a{72}, в котором в SELECT добавлено поле b_id, чтобы оно было доступно для дальнейших операций JOIN и GROUP BY. Если переписать запрос с учётом этой информации, получается:

Oracle I Решение 2.2.2.b

1SELECT "book", "author(s)"

2UTL RAW.CAST TO NVARCHAR2

3(

10)

11AS "genre(s)"

12FROM {данные из решения 222a + поле b id}

13JOIN "m2m books genres" USING ("b id"

14JOIN "genres" USING("g id"

15GROUP BY "b id",

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 84/545

Пример 12: запросы на объединение и преобразование столбцов в строки

Здесь мы применяем такой двухуровневый подход потому, что не существует простого и производительного способа устранить дублирование данных в функции LISTAGG. Некуда применить DISTINCT и нет никаких специальных встроенных ме-

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

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

Почему не работает одноуровневое решение (когда мы пытаемся сразу в одном SELECT получить набор авторов и набор жанров)? Итак, у нас есть данные:

Попытка сразу получить в виде строки список авторов и жанров выглядит так:

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

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 85/545

Пример 12: запросы на объединение и преобразование столбцов в строки

Результат выполнения первой группировки и построчного объединения:

На втором шаге набор данных о каждой книге и её авторах уже позволяет проводить группировку сразу по двум полям — book и author(s), т.к. списки авторов уже подготовлены, и никакая информация о них не будет потеряна:

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 86/545

Пример 12: запросы на объединение и преобразование столбцов в строки

Задание 2.2.2.TSK.A: показать все книги с их жанрами (дублирование названий книг не допускается).

Задание 2.2.2.TSK.B: показать всех авторов со всеми написанными ими книгами и всеми жанрами, в которых они работали (дублирование имён авторов, названий книг и жанров не допускается).

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 87/545

Пример 13: запросы на объединение и подзапросы с условием IN

2.2.3.Пример 13: запросы на объединение и подзапросы с условием

IN

Очень часто запросы на объединение можно преобразовать в запросы с подзапросом и ключевым словом IN (обратное преобразование тоже возможно). Рассмотрим несколько типичных примеров:

Задача 2.2.3.a{83}: показать список читателей, когда-либо бравших в библиотеке книги (использовать JOIN).

Задача 2.2.3.b{84}: показать список читателей, когда-либо бравших в библиотеке книги (не использовать JOIN).

Задача 2.2.3.c{86}: показать список читателей, никогда не бравших в библиотеке книги (использовать JOIN).

Задача 2.2.3. d{87}: показать список читателей, никогда не бравших в библиотеке книги (не использовать JOIN).

Легко заметить, что пары задач 2.2.3.а-2.2.3.Ь и 2.2.3.c-2.2.3.d как раз являются предпосылкой к использованию преобразования JOIN в IN.

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 88/545

Пример 13: запросы на объединение и подзапросы с условием IN

Решение 2.2.3.a{83}.

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

Но у DISTINCT есть и опасность. Представьте, что мы решили не извле-

кать идентификатор читателя, ограничившись его именем (приведём пример только для MySQL, т.к. в MS SQL Server и Oracle ситуация совершенно идентична):

MySQL Решение 2.2.3.a (демонстрация потенциальной проблемы)

1SELECT ... DISTINCT ................. 'sTname'

2FROM 'subscribers' JOIN 'subscriptions'

3ON 's id' = 'sb subscriber'

4

Запрос вернул следующие данные:

s_name

Иванов И.И. Сидоров С.С.

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 89/545