Документ взят с: www.artdds.ru составитель, редактор – Зубков Александр, ПИЭ-01-1(1) исп. материалы, подготовленные студентами специальности ПИЭ-01 (ФЭиИ ЛГПУ)

Дисциплина «базы данных»

1. Реляционная модель данных. Организация данных и ограничение целостности.

Реляционная модель основывается на математических принципах, вытекающих непосредственно из теории множеств и логики предикатов. Эти принципы впервые были применены в области моделирования данных в конце 60-х гг. доктором Е.Ф. Коддом, в то время работавшим в IBM, а впервые опубликованы — в 1970 г.

Реляционная модель определяет способ представления данных (структуру данных), методы зашиты данных (целостность данных), а также операции, выполняемые с данными (манипулирование данными).

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

Реляционная модель данных характеризуется следующими компонентами:

• информационной конструкцией – отношением с двухуровневой структурой;

• допустимыми операциями – проекцией, выборкой, соединением и некоторыми другими;

• ограничениями – функциональными зависимостями между атрибутами отношения.

Каждому классу объектов P материального мира ставится в соответствие некоторое множество атрибутов, например A1, A2, …, An. Отдельный объект класса P описывается строкой величин (a1, a2, …, an), где ai – значение атрибута Ai.

Строка (a1, a2, …, an) называется кортежем.

Всему классу объектов соответствует множество кортежей, называемое отношением.

Если обозначить отношение, описывающее класс объектов P, также через P, то выражение P(A1, A2, …, An) называется схемой отношения P.

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

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

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

Атрибут – атомарное свойство объекта / поле записи / столбец таблицы данных.

Кардинальность – количество записей (строк) в таблице БД.

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

Суперключ отношения — это множество атрибутов, которые функционально обусловливают все другие атрибуты отношения.

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

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

Основные принципы проектирования БД:

• Достоверность. Проект обязан достоверно представлять спецификацию БД: отношения и атрибуты должны соответствовать реальным требованиям. Мы не вправе ассоциировать с отношением «Актеры» атрибут «Количество цилиндров», хотя последний вполне применим к отношению «Автомобили».

• Отсутствие избыточности. Мы обязаны тщательно следить за тем, чтобы объекты структуры не повторяли друг друга.

• Простота. Включайте в проект только те структурные элементы, без которых совершенно нельзя обойтись.

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

• Использование элементов адекватных типов. Тщательно анализируйте, использовать ли атрибуты или отношения и связи.

Также существуют следующие принципы:

• Все значения данных состоят из простых типов данных. В SQL (и РБД) отсутствуют массивы, указатели, векторы и другие сложные типы данных.

• Все данные в реляционной базе данных изображаются в форме двумерных таблиц.

• После того как данные введены в БД, можно сравнивать значения в различных столбцах (в том числе и для разных таблиц) или объединять строки, в которых найдено совпадение. Это позволяет соотносить между собой строки и производить очень сложные операции обработки над всеми данными, находящимися в базе.

• Строки в реляционной базе данных расположены в произвольном порядке. Он не обязательно соответствует тому порядку, в котором они были занесены или в котором хранятся на диске.

Ошибки (с точки зрения РМД), возникающие чаще всего при проектировании БД:

• ввод информации об одном объекте разными способами или в разных местах;

• ввод одной и той же информации в нескольких местах;

• ввод информации разрозненно, без поддержания общей структуры объекта.

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

6 правил таблиц:

1) Данные в ячейках структурно-неделимы

2) Данные в столбце одного типа

3) Нет дублирующихся столбцов

4) 5) Столбцы и строки находятся в произвольном порядке

6) Столбцы имеют уникальное имя

2. Уровни абстракции. Этапы проектирования АИС.

Под уровнями абстракции понимаются различные уровни представления информации.

Локальное представление пользователя о предметной области. Так как предметная область – это то, что надо автоматизировать, то приходим к потенциальным пользователям АИС и расспрашиваем, чем они занимаются, и что бы они хотели видеть в АИС. Вот их ответы, по идее, и являются локальным представлением.

Информационные потребности абонента: какую информацию должна выдавать АИС.

Инфологическая модель – ER и т.п.

Концептуальная модель использования ИС. Где, кто и как будет ей пользоваться.

Банк данных – совокупность базы данных, базы знаний, всех моделей, файлы и т.п.

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

Схема БД – логическая структура. Надо думать, типа как в Access – Схема данных.

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

Файлы данных. Вариантов много. Например, в формате xBase (FoxPro, 1Cv7) для каждой таблицы соответствует файл данных *.dbf и индексный *.cdx (где * в данном случае – имя таблицы). Современные тенденции – хранить всю базу в одном файле (Access, 1Cv8). Однако, это справедливо не для всех СУБД, например в MySQL хранение данных определяется типом таблиц, где чаще всего на одну таблицу приходятся три файла (таблицы MyISAM).

Этапы проектирования БД.

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

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

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

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

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

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

Наиболее распространена ER-модель (essence-relation), или модель сущность-связь. Модель является графической: прямоугольники отображают элементы данных, а линии (возможно, со стрелками) указывают связи между ними.

Также бывает объектно-ориентированная модель данных (язык определения объектов – ODL), объектно-реляционная модель (расширение обычной реляционной модели за счет формализации концепций ООП) и модель «полуструктурированных» данных (XML – наиболее характерный представитель).

Итак, модель сущность-связь используется для представления множеств сущностей, связей между ними, а также атрибутов множеств сущностей. Сущность – абстрактный объект определенного вида. Набор однородных сущностей образует множество сущностей. (Так определено в книге, другой вариант – сущность и экземпляр сущности).

Сущность сходна с понятием «объект» в ООП, а множество сущностей – с классом. Тем не менее, ER-модель имеет дело со структурами данных, а не с операциями над данными, поэтому такое понятие, как «методы» отсутствует.

Множеству сущностей отвечает набор атрибутов, являющихся свойствами сущностей множества. Атрибуты представляют собой атомарные значения.

Связи – соединения между двумя или большим числом множеств сущностей.

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

Бинарные связи могут относиться к типам:

• один к одному – соединяет некоторую сущность множества не более с чем одной сущностью другого множества;

• многие к одному – соединяет любую сущность множества, указанного на стороне «многие», не более чем с одной сущностью множества, заданного на противоположной стороне соединения;

• многие ко многим – не ограничивают свойство множественности взаимоотношений соединяемых множеств сущностей.

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

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

Нередки ситуации, когда множество сущностей содержит определенные сущности, которые обладают специальными свойствами, не присущими остальным членам множества. Для их создания применяются подклассы. Для соединения базового класса («полное» множество сущностей) с его подклассами используются связи isa – «есть» (от англ. is a).

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

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

Информационный объект – сущность фрагмента действительности

Связи:

1. Иерархические (владелец-подчинённый)

2. Одноуровневый (брат-сестра)

Признак множественности – это M:N

3. Access. Работа с таблицами. Установление связей между таблицами.

Access – это настольная СУБД, которая входит в пакет MS Office.

Таблица – основной объект хранения информации в реляционной базе данных. Таблица содержит столбцы (поля) и строки (записи, кортежи). Данные таблиц занимают в базе данных физическое пространство (в отличие, скажем, от представлений). Таблица может быть постоянной или временной…

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

• используется ключевое слово DISTINCT

• участвуют записи из таблиц, связанных отношением один ко многим

Поле (столбец) является частью таблицы и совпадает по смыслу с атрибутом в реляционной модели (или даже ER), а потому обладает свойством атомарности (такие «типы данных», как OLE-объект в данном случае рассматривается как «черный ящик», который не разделяется на подобъекты, а поэтому также считается «атомарным» – абстрактно говоря), к тому же, поле в Access должно иметь вполне конкретный тип (в 2003: текстовый, поле MEMO, числовой, дата/время, денежный, логический, поле объекта OLE, гиперссылка).

Тип данных уже представляет собой определенный домен (Error: Reference source not found), к тому же, путем установки свойства "Условие на значение" можно этот самый домен сузить.

Говоря о наименованиях полей, следует отметить, что Access очень лоялен благодаря использованию Unicode в версиях начиная с 2000, единственно, длина наименования поля не должна превышать 64 знака. Но на деле, увлекаться не стоит: при определении связи создается системный индекс, имя которого состоит из имен соединяемых полей, которое, в свою очередь, не должно превышать 64 символа. Так что 64 символа реально оборачиваются где-то в 24-32.

Таблицы можно создавать различными способами.

Во-первых, ее можно импортировать из другой БД: Файл->Внешние данные->Импорт.

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

Самый дурной способ – создание таблицы в режиме ввода данных. Появляется таблица 10х10, мы туда что-то вводим, сохраняем таблицу (и тут же удаляем, потому что результат никуда не годится). Access пытается понять, что мы от него хотели, и, применяя высокоуровневые методы информатики и программирования, создает в этой таблице нужное количество полей (надо полагать, по максимуму введенных) и приблизительно указывает тип. В общем, все равно надо будет в конструкторе до ума доводить.

Менее дурной, но все равно дурной – это мастер: запускаем мастер, и он предлагает некоторые типовые таблицы с типовыми полями. Из всего этого многообразия собираем нашу таблицу; на следующем шаге задаем имя таблицы и способ определения ключа (ключ должен определить Access или пользователь). 3-й шаг – определение связей. Надо выделить существующую таблицу, с которой нужно создать связь, нажать на кнопку "Связи" и выбрать, как таблицы должны быть связаны (или не должны, как ни странно). Ого! На четвертом шаге предлагается даже создать форму для этой таблицы! Другие варианты – изменить структуру таблицы и внести данные непосредственно в таблицу.

И самый профессиональный способ – это в конструкторе.

Что собой представляет конструктор: в верхней части – таблица: имя поля, тип данных и описание. В нижней части слева расположена панель свойств текущего поля, а справа – информационная панель. Здесь все по порядку: ввод имени поля – выбор типа – ввод описания (если требуется).

Рассмотрим свойства полей (набор этих свойств зависит от типа данных).

Размер:

• в символах для строк;

• подтипы: байт, целое, длинное целое, одинарное с плавающей точкой, двойное с плавающей точкой, код репликации, действительное для числового типа;

• подтипы: действительное или код репликации для счетчика.

• для остальных – не применяется.

Объем, занимаемый в памяти числовыми типами данных полей:

Подтип	Диапазон	Знаков после запятой	Занимаемый размер
Байт	Числа 0 … 255	0	1 байт
Действительное	-1028-1 … 1028-1	28	12 байт
Целое	-32768 … 32767	0	2 байта
Длинное целое	-231 … 231-1	0	4 байта
Одинарное	±1.4×10-45 … ±3.4×1038	7	4 байта
Двойное	±4.94×10-324 … ±1.798×10308	15	8 байт
Код репликации	наш родимый GUID		16 байт

За счет использования Unicode, для строк – по 2 байта на символ. Правда, существует сжатие Unicode… Его суть в том, что если в 1-м байте у символа – 0, то такой символ хранится одним байтом (например, английские буквы).

Формат.

Похоже, что применяется ко всем типам, кроме OLE-объекта (к которому почти вообще ничего не применяется). Наиболее целесообразное использование – с числовым типом данных. Тогда можно выбрать следующие форматы: Основной, Денежный, Евро, Фиксированный, С разделителями разрядов, Процентный, Экспоненциальный. Денежный формат включает разделители разрядов и использует системные "валютные" настройки. Фиксированный формат всегда выводит заданное количество знаков после запятой. Экспоненциальный выводит большие числа в формате "с Е": 3.1415Е+23. В оригинале, кстати, этот формат называется Scientific – научный. Разумеется, можно создать свой собственный формат (как это делать – см. help, сдается мне, для экзамена это уже будет перебор).

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

Маска ввода предназначена для формирования шаблона ввода дат и регламентированных строк. Для интересующихся: специальные символы для масок (перевод документации).

0 – Цифра (от 0 до 9, ввод обязателен, знаки + или – не допускаются).

9 – Цифра или пробел (ввод необязателен, но знаки не допускаются).

# – Цифра или пробел (ввод не обязателен, пробелы отображаются при вводе, а при сохранении уничтожаются; знаки + и - допускаются).

L – Буква (A - Z, ввод обязателен).

? – Буква (A - Z, ввод необязателен).

A – Буква или цифра (ввод обязателен).

a – Буква или цифра (ввод не обязателен).

& – Любой символ (в т.ч. пробел), ввод обязателен

C – Любой символ, ввод необязателен.

. , : ; - / – Десятичная точка, разделители разрядов, даты и времени (конкретные символы обусловлены региональными настройками).

< – Указывает, что все символы должны быть переконвертированы в малые

> – Указывает, что все символы должны быть переконвертированы в БОЛЬШИЕ

! – Указывает написание справа налево (вместо слева направо)

\ – Указывает, что следующий символ должен отобразиться "как есть" (например, \A отображается просто как A. Напоминаем, что А – это спецсимвол, означающий букву).

Подпись – как отображать название столбца (и текст надписей в форме). Если подпись не указана, тогда везде отображается имя поля. Аналог "Синонима" в 1С.

Значение по умолчанию – значение, автоматически добавляемое в поле для новой записи.

Условие на значение – логическое выражение, накладывающее ограничение на значения, которые вводятся в данное поле. Внимание: данное выражение – аналог обычного логического выражения без указания левого оператора, – его роль исполняет само поле.

Сообщение об ошибке (в сочетании с условием на значение) – это сообщение, которое появится при нарушении условия на значение.

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

Пустые строки (для строковых типов) – разрешать ли хранение пустых строк "", что, заметьте, не есть NULL. Лучше, конечно, не разрешать.

Индексированное поле – выбор из трех режимов:

1. Нет.

2. Да (допускаются совпадения).

3. Да (совпадения не допускаются).

Индекс ускоряет поиск и сортировку в данном поле, но замедляет обновление

Про связи

Вспоминаем модель сущность – связь, и там у нас были связи: 1 к 1, 1 ко многим и многие ко многим. "Хорошая" новость: много ко многим в Access (да и в любой РБД) "в лоб" сделать не получится. Для этого надо сделать промежуточную таблицу, куда включить два поля для связи с таблицами отношения "многие ко многим". Для одного ко многим надо там, где "много", добавить поле связи соответствующего внешнему ключу на стороне "один". А так как этот самый внешний ключ обычно является счетчиком, то в этом случае поле связи должно быть числовым.

Связи определяются в окне схемы данных (Сервис->Схема данных). На бланке размещаются таблицы. Связь удобнее всего создать перетаскиванием:

• 1 к 1: ключ "главной" таблицы (счетчик) на ключ "зависимой" таблицы (числовое поле)

• 1 ко многим: ключ таблицы "один" на поле связи таблицы "много" (или в обратную).

• много ко многим – через промежуточную таблицу, то есть два раза 1 ко многим, где "много" будет у связующей таблицы.

Появится диалоговое окно "Изменение связей". Убедимся, что используются правильные поля для связи. Еще в этом окне есть три волшебных флажка:

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

• Каскадное обновление связанных записей. При изменении значения ключа на стороне "один" зависимые поля обновляются автоматически. Не принципиально, если используется счетчик (все равно его менять нельзя).

• Каскадное удаление связанных записей. Удалили группу – студенты этой группы удалились автоматически.

Помимо контроля ссылочной целостности связи в схеме данных нужны для того, чтобы при создании запросов таблицы объединялись автоматически (иначе – декартово произведение).

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

Нажимаем на кнопку "Объединение" и выбираем из трех вариантов (процитирую):

• "Объединение только тех записей, в которых связанные поля обеих таблиц совпадает". Это значение по умолчанию и соответствует словам INNER JOIN.

• "Объединение ВСЕХ записей из <Таблицы1> и только тех записей из <Таблицы2>, в которых связанные поля совпадают". Это есть ни что иное, как LEFT JOIN.

• "Объединение ВСЕХ записей из <Таблицы2> и только тех записей из <Таблицы1>, в которых связанные поля совпадают". RIGHT JOIN.

Разумеется, в запросах все связи, определенные в схеме данных, можно переиначить для нужд конкретного запроса. Внешние соединения (LEFT и RIGHT) наиболее вероятно придется использовать для связей 1 к 1.

NULL-значение "придумано" для того, чтобы представить единым образом "неизвестные значения" для любых типов данных. Действительно, так как при вводе данных в столбец или их изменении СУБД запрещает ввод значений не соответствующих описанию данных этого столбца, то, например, нельзя использовать пробел для отсутствующего значения числа. Нельзя для этих целей использовать и ноль: нет месяца или дня недели равного нулю, да и для чисел ноль не может рассматриваться как неизвестное значение в одном месте и как известное – в другом. При выводе же NULL-значения на экран или печатающее устройство его код воспроизводится каким-либо специально заданным символом или набором символов: например, пробелом (если его нельзя перепутать с текстовым значением пробела) или сочетанием -0-.

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

4-7. Синтаксис оператора SELECT. Использование условий поиска для отбора строк в операторе SELECT. Сортировка результатов запроса в операторе SELECT. Простые запросы SELECT и правила их выполнения.

Оператор SELECT имеет следующую структуру:

Полный синтаксис (MySQL):

SELECT [STRAIGHT_JOIN]

[SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]

[SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS] [HIGH_PRIORITY]

[DISTINCT | DISTINCTROW | ALL]

выражение_выборки,...

[INTO {OUTFILE | DUMPFILE} ‘имя_файла‘ опции_экспорта]

[FROM таблица

[WHERE фраза]

[GROUP BY {беззнаковое_целое | имя_столбца | формула} [ASC | DESC], ...]

[HAVING фраза]

[ORDER BY {беззнаковое_целое | имя_столбца | формула } [ASC | DESC], ...]

[LIMIT [смещение,] строки | строки OFFSET смещение]

[PROCEDURE имя_процедуры (аргументы)]

[FOR UPDATE | LOCK IN SHARE MODE]]

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

Сокращенный синтаксис (Ansi SQL):

SELECT [[ALL] | DISTINCT] { * | элемент_SELECT[, элемент_SELECT] ...}

FROM {базовая_таблица | представление} [псевдоним]

[,{базовая_таблица | представление} [псевдоним]] ...

[WHERE фраза]

[GROUP BY фраза [HAVING фраза]];

Фраза SELECT

Элемент_SELECT - это одна из следующих конструкций:

[таблица.]* | значение | SQL_функция | системная_переменная

где значение – это:

[таблица.]столбец | (выражение) | константа | переменная

Синтаксис выражений имеет вид:

( {[ [+] | - ] {значение | функция_СУБД} [ + | - | * | ** ]}... )

а синтаксис SQL_функций – одна из следующих конструкций:

{SUM|AVG|MIN|MAX|COUNT} ( [[ALL]|DISTINCT][таблица.]столбец )

{SUM|AVG|MIN|MAX|COUNT} ( [ALL] выражение )

COUNT(*)

Фраза WHERE включает набор условий для отбора строк:

WHERE [NOT] WHERE_условие [[AND|OR][NOT] WHERE_условие]...

где WHERE_условие – одна из следующих конструкций:

значение { = | <> | < | <= | > | >= } { значение | ( подзапрос ) }

значение_1 [NOT] BETWEEN значение_2 AND значение_3

значение [NOT] IN { ( константа [,константа]... ) | ( подзапрос ) }

значение IS [NOT] NULL

[таблица.]столбец [NOT] LIKE 'строка_символов' [ESCAPE 'символ']

EXISTS ( подзапрос )

Кроме традиционных операторов сравнения (= | <> | < | <= | > | >=) в WHERE фразе используются условия BETWEEN (между), LIKE (похоже на), IN (принадлежит), IS NULL (не определено) и EXISTS (существует), которые могут предваряться оператором NOT (не). Критерий отбора строк формируется из одного или нескольких условий, соединенных логическими операторами:

AND – когда должны удовлетворяться оба разделяемых с помощью AND условия;

OR – когда должно удовлетворяться одно из разделяемых с помощью OR условий;

AND NOT – когда должно удовлетворяться первое условие и не должно второе;

OR NOT – когда или должно удовлетворяться первое условие или не должно – второе,

причем существует приоритет AND над OR (сначала выполняются все операции AND и только после этого операции OR).

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

Синтаксис фразы GROUP BY имеет вид:

GROUP BY [таблица.]столбец [,[таблица.]столбец] ... [HAVING фраза]

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

С помощью фразы HAVING (синтаксис которой почти не отличается от синтаксиса фразы WHERE)

HAVING [NOT] HAVING_условие [[AND|OR][NOT] HAVING_условие]...

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

значение { = | <> | < | <= | > | >= } { значение | ( подзапрос )

| SQL_функция }

{значение_1 | SQL_функция_1} [NOT] BETWEEN

{значение_2 | SQL_функция_2} AND {значение_3 | SQL_функция_3}

{значение | SQL_функция} [NOT] IN { ( константа [,константа]... )

| ( подзапрос ) }

{значение | SQL_функция} IS [NOT] NULL

[таблица.]столбец [NOT] LIKE 'строка_символов' [ESCAPE 'символ']

EXISTS ( подзапрос )

Подводя итог под синтаксисом оператора SELECT:

SELECT

(выбрать) данные из указанных столбцов и (если необходимо) выполнить перед выводом их преобразование в соответствии с указанными выражениями и (или) функциями

FROM

(из) перечисленных таблиц, в которых расположены эти столбцы

WHERE

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

GROUP BY

(группируя по) указанному перечню столбцов с тем, чтобы получить для каждой группы единственное агрегированное значение, используя во фразе SELECT SQL-функции SUM (сумма), COUNT (количество), MIN (минимальное значение), MAX (максимальное значение) или AVG (среднее значение)

HAVING

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

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

Выборка вычисляемых значений: из синтаксиса фразы SELECT видно, что в ней может содержаться не только перечень столбцов таблицы или символ *, но и выражения. Например:

SELECT Продукт, ((Белки + Углев) * 4.1 + Жиры * 9.3)

FROM Продукты;

Фраза SELECT может включать не только выражения, но и отдельные числовые или текстовые константы. Следует отметить, что текстовые константы должны заключаться в апострофы:

SELECT Продукт, 'Калорий =', ((Белки+Углев)*4.1+Жиры *9.3)

FROM Продукты;