- •Шехтман в. Е.
- •1. Базы данных и модели данных
- •1.1. Введение.
- •1.2. Файлы операционной системы
- •1.3. Пример базы данных.
- •1.4. Иерархическая модель данных
- •1.5. Сетевая модель данных
- •1.6. Инвертированные списки.
- •2. Введение в реляционную модель данных.
- •1.7. Реляционная модель данных
- •3. Реляционная алгебра
- •3.1. Теоретико-множественные операции.
- •3.2. Специальные операции ra
- •4. Нормализация данных
- •4.1. Полная декомпозиция.
- •Магазин товар ндс
- •Товар ндс
- •Магазин ндс
- •Товар ндс
- •Магазин товар ндс
- •4.2. Проблема дублирования данных.
- •1 Глобус 33-33-33
- •2 Глобус 33-33-33
- •4 Океан 77-77-77
- •4.3. Висячие записи.
- •Поставщик Тел
- •4.4. Проблемы, возникающие из-за неудачной структуры данных.
- •4.5. Пятая нормальная форма (5нф).
- •4.6. Функциональная зависимость.
- •4.7. Связь между фз и полной декомпозицией отношения.
- •4.8. Первая нормальная форма (1нф).
- •4.9. Вторая нормальная форма (2нф).
- •4.10. Третья нормальная форма (3нф).
- •4.11. Нормальная форма Бойса-Кодда (нфбк).
- •4.12. Многозначная зависимость.
- •4.13. Четвертая нормальная форма (4нф).
- •4.14. Пример нормализации.
- •4.15. Резюме. Нормальные формы.
- •5. Инфологическое моделирование.
- •5.1. Сущность и набор сущностей
- •5.2. Связи между сущностями.
- •5.3. Рекурсивная связь. Роли.
- •5.4. Множественные связи.
- •5.5. Суперсущности и производные сущности
- •5.6. Слабые наборы сущностей
- •5.7. Борьба с избыточнотью
- •5.8. Преобразование инфологической модели в физическую модель.
- •5.9. Пример инфологического моделирования.
- •6. Язык sql
- •6.1. История sql.
- •6.2. Структура sql.
- •6.3. Язык запросов
- •6.4. Простые запросы на выборку данных.
- •6.5. Агрегатные (групповые) функции.
- •6.6. Вложенные запросы
- •6.7. Внешние объединения
- •6.8. Изменение данных
- •Insert into r1 (o, fio, d) values (5, ‘Иванов’, ’бд’)
- •7. Представления.
- •8. Определение схемы базы данных и ограничений целостности
- •9. Транзакции
- •9.1. Свойства транзакций
- •9.2. Надежное хранение данных
- •9.3. Параллельное выполнение транзакций
- •9.3.1. Коллизия “пропавшие изменения” - lost update problem
- •9.3.2. Коллизия “промежуточные данные” - dirty read
- •9.3.3. Коллизия “Несогласованные данные” - unrepeatable read, inconsistent analysis
- •9.3.4. Коллизия “фантом” - phantom
- •9.4. Уровни изолированности
- •9.5. Тупики
- •10. Ограничение прав доступа в целях обеспечения безопасности
- •11. Физическая организация баз данных
- •11.1. Организация размещения данных.
- •11.2. Организация индексов
- •11.2.1. Поиск в бд.
- •11.2.2. Плотный индекс (индексно-прямые файлы).
- •11.2.3. Неплотный индекс (индексно-последовательные файлы).
- •11.2.4. Сбалансированные деревья.
- •11.2.5. Инвертированные списки.
- •12. Архитектура субд. Методы оптимизации запросов.
- •Логические преобразования запросов.
- •Преобразования запросов с изменением порядка реляционных операций.
- •13. Аналитические системы.
- •Анализ данных.
- •Хранилища данных
- •Типы ошибок
- •Способы реализации olap.
- •Требования к средствам реализации систем оперативной и аналитической обработки данных
- •Многомерная модель данных.
- •Разработка данных
- •14. Загружаемые процедуры.
- •In pr double precision)
- •If eof then leave Cl end if;
- •Insert into providers(code, name)
- •Values (nr.Codec, ‘*** новый поставщик ***’);
- •15.4. Модель сервера приложений (трёхзвенная архитектура, “тонкий клиент”)
- •Список литературы
- •15. Модели совместного доступа к бд
- •15.1. Файл-серверная модель.
- •15.2. Модель клиент-сервер с бизнес-логикой на клиенте.
- •15.3. Модель клиент-сервер с бизнес-логикой на сервере субд (хранимые процедуры и триггеры) и частично на клиенте.
6.1. История sql.
Первый международный стандарт языка SQL был принят в 1989 г. Иногда его называют стандартом SQL ANSI/ISO. Большинство коммерческих СУБД поддерживают его полностью. Однако развитие информационных технологий потребовали от языка SQL многочисленных усовершенствований этого стандарта. В 1992 году был принят второй стандарт языка. В 1999 г. был принят новый стандарт, который ознаменовал появление в языке качественно новых свойств, а не просто улучшений и усовершентсвований.
Каждый из упомянутых стандартов является весьма объемным документом. Для чего нужны эти стандарты языка и, в частности, нужны ли они разработчикам? На этот вопрос можно дать следующий ответ.
В серьезных разработках стандарт игнорировать нельзя по следующим причинам. Разработка любой информационной системы, ориентированной на технологию баз данных, является трудоемким процессом. Следует отдавать себе отчет, что нельзя разработать сколько-нибудь серьезную систему за несколько дней. Поэтому, учитывая стремительность развития вычислительной техники, систем телекоммуникаций и программного обеспечения, можно ожидать, что имеется риск того, что проект устареет еще до внедрения. Нельзя забывать и то, что сама предметная область, моделируемая и описываемая с помощью баз данных и программных приложений, тоже изменяется. Поэтому проект достаточно крупной информационной системы обязательно должен быть рассчитан на расширяемость и переносимость на новые платформы. Это и обеспечивает стандарт.
Большинство поставщиков аппаратуры и программного обеспечения поддерживают стандарты, так как это выгодно их пользователям. Однако многие поставщики стремятся улучшить свой продут введением дополнительных возможностей, не предусмотренных стандартом.
Поэтому перед разработчиком программного обеспечения информационных систем, использующих технологию баз данных, встает дилемма: ориентироваться на те усовершенствования стандартных возможностей, которые предлагает конкретный поставщик СУБД, либо стремиться к следованию стандарту. При выборе второго пути можно достичь большей защищенности и ценности разрабатываемого продукта (и следовательно своего труда), так как система становится более переносимосимой. Это означает, что при изменившихся условиях или при появлении новой СУБД, система, при разработке которой ориентировались на стандарт, может быть использована с меньшим количеством доработок и изменений (почти никогда не обходится совсем без них), чем та, которая была разработана с ориентацией на конкретные особенности платформы. Правда, отказ от использования некоторых улучшений, предлагаемых конкретным поставщиком, может стоить дорого: например, обусловить пониженное быстродействие системы.
6.2. Структура sql.
Приведем основные разделы и операторы SQL.
1. DDL (язык определения данных, data definition language).
CREATE TABLE |
Создает таблицу указанной структуры |
DROP TABLE |
Уничтожает таблицу |
ALTER TABLE |
Изменяет структуру или ОЦ |
CREATE VIEW |
Создает виртуальную таблицу, соотв. SQL-запросу |
ALTER VIEW |
Изменяет представление |
DROP VIEW |
Уничтожает представление |
CREATE INDEX |
Создает индекс для обеспечения быстрого доступа по атрибутам, входящим в индекс |
DROP INDEX |
Уничтожает индекс |
2. DML (язык модификации данных, data manipulation language)
DELETE |
Удаляет строки по условию |
INSERT |
Вставляет строку |
UPDATE |
Изменяет значения столбцов в строках по условию |
3. DQL (язык запросов на выборку данных, data query language)
SELECT |
Заменяет ВСЕ операторы реляционной алгебры! Формирует результирующее отношение. |
4. Transactions (управление транзакциями)
COMMIT |
Завершить взаимосвязанную обработку информации. |
ROLLBACK |
Отменить изменения, проведенные в ходе выполнения транзакции. |
SAVEPOINT |
Сохранить промежуточное состояние БД для возможности отката |
5. Adm (администрирование)
ALTER DATABASE |
|
ALTER DBAREA |
|
ALTER PASSWORD |
|
CREATE DATABASE |
|
CREATE DBAREA |
|
DROP DATABASE |
|
DROP DBAREA |
|
GRANT |
|
REVOKE |
|
6. PSM – язык загружаемых процедур.
7. ProSQL (язык программирования навигационных запросов; встраиваемый SQL)
DECLARE |
Определяет имя и связанный с ним запрос – виртуальный набор данных (курсор) |
OPEN |
Формирует виртуальный набор |
FETCH |
Считывает очередную строку |
CLOSE |
Прекращает доступ к курсору |
PREPARE |
Формирует план выполнения |
EXECUTE |
Выполняет |
В коммерческих СУБД набор операторов шире, в частности имеется так называемый раздел PSM (язык хранимых модулей, persistence storage modules), на котором программируются особые объекты СУБД, такие как хранимые процедуры и триггеры. Разговор о них впереди.
Типы данных (SQL89)
CHARACTER(n) CHAR(n) |
|
NUMERIC[(n,m)] |
|
DECIMAL[(n,m)] DEC[(n,m)] |
|
INTEGER INT |
|
SMALLINT |
|
FLOAT[(n)] |
|
REAL |
|
DOUBLE PRECISION |
|
SLQ92
VARCHAR(n) |
|
NCHAR(n) |
|
NCHAR VARYING(n) |
|
BIT(n) |
|
BIT VARYING(n) |
|
DATE |
|
TIMESTAMP |
|
INTERVAL |
|
Коммерческие СУБД – MEMO (LONG, TEXT, BLOB), MONEY (CURRENCY), …
При выполнении сравнений (фильтрация) – константы:
для числовых типов
последовательность цифр с знаком числа и десятичной точкой: +512, -11.23, 38;
с плавающей точкой мантисса и порядок: 3.75E-5, 0.000123E11
строковые константы в одинарных кавычках ‘Новокузнецк’
дата, время, интервал – в виде строковой константы: Сентябрь 11, 2001, 11-Сен-2001
USER
Выражения с +-*/
Встроенные функции
BIT_LENGTH – битов в строке
CAST( значение AS тип данных)
CHAR_LENGTH – длина строки символов
CURRENT_DATE
CURRENT_TIME
CURRENT_TIMESTAMP
LOWER
OCTED_LENGTH – байтов в строке
POSITION( строка IN строка)
SUBSTRING(строка FROM индекс FOR длина)
TRIM(BOTH символ FROM строка)
TRIM(LEADING символ FROM строка)
TRIM(TRAILING символ FROM строка)
UPPER
