- •Історія розвитку сбд.
- •Традиційні файлові системи. Переваги і недоліки.
- •Системи з використанням баз даних. Компоненти сбд. Переваги і недоліки.
- •5_ Системи керування базами даних. Компоненти. Функції.
- •Компоненты сбд
- •1. Зберігання, вилучення і обновлення даних
- •2. Каталог, який доступний кінцевим користувачам
- •3. Управління транзакціями
- •6_ Поняття бд. Об’єкти і зв’язки. Властивості.
- •Розподіл обов’язків в сбд. Ад і абд.
- •7_ Архітектура сбд ansi/sparc. Три рівні. Відображення. Трехуровневая архитектура ansi-sparc
- •3.5 Концептуальный уровень
- •3.6 Внутренний уровень
- •3.7 Отображения
- •3.8 Доступ к данным в трехуровневой архитектуре
- •12_ Архітектура сбд ansi/sparc. Мови баз даних. Ddl. Dml. 4gl.
- •Языки баз данных.
- •Процедурний
- •Непроцедурний
- •13_ Архітектура клієнт-сервер. Розподілена обробка. Архитектура многопользовательских субд
- •Субд в архитектуре "клиент-сервер" Лекция 19. Архитектура "клиент-сервер"
- •19.1. Открытые системы
- •19.2. Клиенты и серверы локальных сетей
- •19.3. Системная архитектура "клиент-сервер"
- •19.4. Серверы баз данных
- •19.4.1. Принципы взаимодействия между клиентскими и серверными частями
- •19.4.2. Преимущества протоколов удаленного вызова процедур
- •19.4.3. Типичное разделение функций между клиентами и серверами
- •19.4.4. Требования к аппаратным возможностям и базовому программному обеспечению клиентов и серверов
- •14_ Ранні підходи в реалізації бд. Бд на інвертованих списках. Ієрархічні та мереживі бд. Модель инвертированных списков
- •Реляційна бд. Властивості реляційних бд.
- •Реляційна модель. Домени. Оператори.
- •2. Реляционная модель данных
- •2.1. Понятие модели данных
- •Реляційна модель. Відношення. Типи відношень.
- •Реляційна модель. Класифікація обмежень цілісності.
- •Реляційна модель. Потенційні ключі.
- •Реляційне числення. Числення доменів. (самостійно)
- •5.2.3. Реляционное исчисление доменов
- •Мова sql. Запит на оновлення. Використання співвіднесених запитів в запитах на оновлення.
- •Мова sql. Запит на знищення. Використання підзапитів в запитах на знищення.
- •Мова sql. Запит на додавання. Додавання результатів запиту.
- •Мова sql. Об’єднання таблиць. Використання пропозиції union.
- •Мова sql. Використання пропозицій any, all, some.
- •Мова sql. Використання пропозиції exists.
- •Мова sql. Співвіднесений запит на вибірку.
- •Мова sql. Запит на вибірку із підзапитом.
- •Мова sql. Запит на вибірку до кількох таблиць. З’єднання таблиць. Типи з’єднань.
- •Мова sql. Запит на вибірку. Агрегатні функції
- •Історія розвитку
Мова sql. Запит на вибірку із підзапитом.
С помощью SQL вы можете вкладывать запросы внутрь друга друга. Обычно, внутренний запрос генерирует значение которое проверяется в предикате внешнего запроса, определяющего верно оно или нет.
Чтобы оценить внешний (основной) запрос, SQL сначала должен оценить внутренний запрос (или подзапрос) внутри предложения WHERE. Он делает это так как и должен делать запрос, имеющий единственную цель. Основной запрос затем выполняется как обычно с вышеупомянутыми результатами. Конечно же, подзапрос должен выбрать один и только один столбец, а тип данных этого столбца должен совпадать с тем значением, с которым он будет сравниваться в предикате.
При использовании подзапросов в предикатах основанных на реляционных операторах, вы должны убедиться, что использовали подзапрос, который будет выдавать одну и только одну строку вывода. Если вы используете подзапрос, который не выводит никаких значений вообще, команда не потерпит неудачи, но основной запрос не выведет никаких значений. Подзапросы которые не производят никакого вывода (или нулевой вывод) вынуждают рассматривать предикат ни как верный, ни как неверный, а как неизвестный. Однако, неизвестный предикат имеет тот же самый эффект что и неверный: никакие строки не выбираются основным запросом.
Если наш подзапрос возвратит более одного значения, это будет указывать на ошибку в наших данных - хорошая вещь для знающих об этом.
Вы должны обратить внимание что предикаты, включающие подзапросы, используют выражение
< скалярная форма > < оператор > < подзапрос >, а не
< подзапрос > < оператор > < скалярное выражение > или,
< подзапрос > < оператор > < подзапрос >.
Один тип функций, который автоматически может производить одиночное значение для любого числа строк, конечно же, — агрегатная функция. Любой запрос, использующий одиночную функцию агрегата без предложения GROUP BY будет выбирать одиночное значение для использования в основном предикате.
Имейте ввиду, что сгруппированные агрегатные функции, которые являются агрегатными функциями, определенными в терминах предложения GROUP BY, могут производить многочисленные значения. Они, следовательно, не позволительны в подзапросах такого характера. Даже если GROUP BY и HAVING используются таким способом, что только одна группа выводится с помощью подзапроса, команда будет отклонена в принципе. Вы должны использовать одиночную агрегатную функцию с предложением WHERE, что устранит нежелательные группы.
Вы можете использовать подзапросы, которые производят любое число строк если вы используете специальный оператор IN (операторы BETWEEN, LIKE, и IS NULL не могут использоваться с подзапросами). Как вы помните, IN определяет набор значений, одно из которых должно совпадать с другим термином уравнения предиката в порядке, чтобы предикат был верным. Когда вы используете IN с подзапросом, SQL просто формирует этот набор из вывода подзапроса.
В принципе, если вы знаете что подзапрос должен(по логике) вывести только одно значение, вы должны использовать =. IN является подходящим, если запрос может ограниченно производить одно или более значений, независимо от того ожидаете вы их или нет.
