Понятие данных
Скачать 1.56 Mb.
|
История: В 1982 г. Американский национальный институт стандартов (ANSI) начал работу над стандартом языка реляционных баз данных. В 1983 г. к этой работе подключился Международный комитет по стандартизации (ISO). Совместными усилиями в 1987 г. был выпущен исходный вариант стандарта языка SQL, вызвавший волну критических замечаний. В 1992 г. была выпущена первая, существенно пересмотренная версия стандарта ISO, которую иногда называют SQL2 или SQL-92. В 1999 г. Был выпущен стандарт SQL-1999 (SQL-3); объединяет реляционные и объектно-ориентированные свойства: хранение данных – на основе реляционной модели данных, их представление и обработка – с использованием объектно-ориентированных возможностей. • Язык SQL имеет два основных компонента: • язык DDL (Data Definition Language), предназначенный для определения структуры базы данных; • язык DML (Data Manipulation Language), предназначенный для выборки и обновления данных. Язык SQL (точнее, его подмножество DML) является примером языка с трансформирующей ориентацией – языка, предназначенного для работы с таблицами с целью преобразования входных данных к требуемому виду. Это не процедурный язык, поэтому в нем необходимо указывать, какая информация должна быть получена, а не как ее можно получить. Иначе говоря, язык SQL не требует указания методов доступа к данным. 15. Средства языка SQL как языка манипулирования данными. Предложения INSERT, DELETE, UPDATE. SQL (Structured Query Language) – язык, ориентированный на отображение; описывается отображение известного атрибута или множества атрибутов в искомый атрибут или множество атрибутов. Первая коммерческая СУБД – ORACLE (конец 70-х г.г.) Язык SQL имеет два основных компонента: • язык DDL (Data Definition Language), предназначенный для определения структуры базы данных; • язык DML (Data Manipulation Language), предназначенный для выборки и обновления данных. Язык SQL (точнее, его подмножество DML) является примером языка с трансформирующей ориентацией – языка, предназначенного для работы с таблицами с целью преобразования входных данных к требуемому виду. Это не процедурный язык, поэтому в нем необходимо указывать, какая информация должна быть получена, а не как ее можно получить. Иначе говоря, язык SQL не требует указания методов доступа к данным. Предложения SQL: INSERT INTO имя таблицы (колонка1, …) { Values (значение1, …) Запрос } DELETE FROM имя таблицы WHERE условие отбора строк UPDATE имя таблицы SET колонка1 = выражение, … WHERE условие отбора строк 16. Средства языка SQL как языка манипулирования данными. Формирование запросов. Предложение SELECT. Все запросы на получение практически любого количества данных из одной или нескольких таблиц выполняются с помощью единственного предложения SELECT. В общем случае результатом реализации предложения SELECT является другая таблица. К этой новой (рабочей) таблице может быть снова применена операция SELECT и т.д., т.е. такие операции могут быть вложены друг в друга. Представляет исторический интерес тот факт, что именно возможность включения одного предложения SELECT внутрь другого послужила мотиацией использования прилагательного "структуризированный" в названии языка SQL. Предложение SELECT может использоваться как: • самостоятельная команда на получение и вывод строк таблицы, сформированной из столбцов и строк одной или нескольких таблиц (представлений); • элемент WHERE- или HAVING-условия (сокращенный вариант предложения, называемый "вложенный запрос"); • фраза выбора в командах CREAT VIEW, DECLARE CURSOR или INSERT; • средство присвоения глобальным переменным значений из строк сформированной таблицы (INTO-фраза). Предложение SELECT (выбрать) имеет следующий формат: SELECT(выбрать) данные из указанных столбцов и (если необходимо) выполнить перед выводом их преобразование в соответствии с указанными выражениями и (или) функциями FROM(из) перечисленных таблиц, в которых расположены эти столбцы WHERE(где) строки из указанных таблиц должны удовлетворять указанному перечню условий отбора строк GROUP BY(группируя по) указанному перечню столбцов с тем, чтобы получить для каждой группы единственное агрегированное значение, используя во фразе SELECT SQL функции SUM (сумма), COUNT (количество), MIN (минимальное значение), MAX (максимальное значение) или AVG (среднее значение) HAVING(имея) в результате лишь те группы, которые удовлетворяют указанному перечню условий отбора групп Подзапрос имеет формат SELECT [ DISTINCT]{ * | элемент_SELECT [,элемент_SELECT] ...} FROM {базовая_таблица | представление} [псевдоним] [,{базовая_таблица | представление} [псевдоним]] ... [WHERE фраза] [GROUP BY фраза [HAVING фраза]]; Синтаксис выражений имеет вид ( {[ [+] | - ] {значение | функция_СУБД} [ + | - | * | ** ]}... ) а синтаксис 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 ( подзапрос ) Нетрадиционные условия отбора: BETWEEN (между), LIKE (похоже на), IN (принадлежит), IS NULL (не определено) и EXISTS (существует). В условиях могут употребляться логические операции: NOT, AND, OR. Синтаксис фразы GROUP BY имеет вид GROUP BY [таблица.]столбец [,[таблица.]столбец] ... [HAVING фраза] GROUP BY инициирует перекомпоновку формируемой таблицы по группам, каждая из которых имеет одинаковое значение в столбцах, включенных в перечень GROUP BY. Далее к этим группам применяются агрегирующие функции, указанные во фразе SELECT. С помощью фразы HAVING, синтаксис которой: HAVING _условие [[AND|OR][NOT] HAVING_условие]... можно исключить из результата группы, не удовлетворяющие заданным условиям. 17. Разработка приложений: структура интерактивного приложения, архитектура клиент-сервер. Понятие и свойства транзакции. Прикладной компонент SQL. Клиент-сервер – это модель взаимодействия компьютеров в сети Сервер – компьютер (или программный продукт), управляющий тем или иным ресурсом Клиент – компьютер (или программный продукт), желающий воспользоваться тем или иным ресурсом Система СУБД состоит из двух частей: сервера базы данных и клиента (или внешний интерфейс) Функции информационной системы • функции ввода и отображения данных, • прикладные функции, характерные для данной предметной области, • фундаментальные функции организации хранения информации и управления информационными ресурсами, • служебные функции, играющие роль связок между функциями первых трех групп. Транзакция – логическая единица работы, которая лежит в основе проблемы параллелизма. Главная задача управления параллелизмом: • Или все изменения, сделанные транзакцией, фиксируются и делаются постоянными (успешное завершение транзакции) • Или транзакция никак не влияет на состояние базы данных (ошибки при выполнении, откат) Транзакция имеет начало (явное или нет, пр. - когда программа присоединяется к БД) и конец (commit – подтверждение, успех; rollback - откат). Транзакция – логическая единица работы, удовлетворяющая свойствам АСИД: • Атомарность (А) – в транзакции выполняется все или ничего; не может выполниться частично • Согласованность (С) – транзакция переводит БД из одного согласованного состояния в другое • Изолированность (И) – каждая транзакция выполняется независимо от других • Долговременность (Д) – если изменения состояния БД, сделанные транзакцией, зафиксированы, они будут сохранены, даже если потом произойдет сбой. 18. Разработка приложений: понятие триггера, назначение и использование триггеров. Триггер – особый вид хранимой процедуры; связан c конкретной таблицей и с конкретным предложением SQL – INSERT, DELETE или UPDATE. Триггер срабатывает каждый раз, когда выполняется соответствующее предложение для связанной с триггером таблицы. У триггеров не может быть ни параметров, ни возвращаемых значений. Создание триггера: CREATE TRIGGER имя_триггера ON имя_таблицы FOR | AFTER | INSTEAD OF предложение_SQL AS тело_триггера DECLARE @идентификатор тип_данных, … Имена переменных в Transact SQL обязательно начинаются символом @, что позволяет отличить их от имен объектов (таблиц, колонок, …) базы данных. В предложении DECLARE используются такие же типы данных, как и в предложении SQL CREATE TABLE. Пример: DECLARE @a int, @nm varchar(50), @dt smalldatetime Имена глобальных переменных Transact SQL, значения которых автоматически устанавливаются сервером базы данных, начинаются символами @@, например, @@identity. Присваивание значений переменным можно выполнить двумя способами: SET @идентификатор = выражение Здесь в записи выражений могут быть использованы другие переменные Transact SQL, константы, подзапросы, возвращающие единственное значение, знаки операций; имена объектов базы данных могут быть использованы только в подзапросах. Примеры: а)SET @dt = getdate() SET @a = (SELECT count(*) FROM Goods) б) SELECT @идр1 = врж1, @идр2 = врж2, … FROM … Такая форма присваивания может быть использована только в том случае, если запрос, представленный предложением SELECT, возвращает гарантированно не более одной строки. Примеры: SELECT @a = count(*) FROM Goods SELECT @a = ParentID, @nm = CatName FROM Category WHERE CatID = 1 Условное предложение: IF условное_выражение предложение1 ELSE предложение2 Если нужно включить несколько предложений, они оформляются в виде блока с помощью операторных скобок BEGIN … END. Если триггер предназначен для проверки некоторого условия и, в случае нарушения этого условия, требуется вывести соответствующее диагностическое сообщение, следует использовать специальную функцию: raiserror('текст_сообщения', код_серьезности, уровень [, аргумент1, …]) В тексте сообщения могут быть указаны специальные спецификации формата, в виде: %буква, например, %d (целые значения), %s (символьная строка); в этом случае для каждой спецификации формата должен быть указан соответствующий аргумент. Код серьезности ошибки задается в виде: от 1 до 10 – предупреждение (warnings), от 11 до 16 – ошибка (errors), от 17 до 25 – серьезная ошибка (severe errors). Уровень ошибки выбирается программистом из диапазона от 1 до 127. 19. Проектирование реляционных баз данных: возникающие проблемы, основные цели проектирования. Понятие функциональной зависимости. Влияние функциональных зависимостей на отношения. Определение ключа. Применительно к реляционным базам данных это сводится к решению следующих вопросов: • какие отношения включать в состав базы данных, • сколько отношений включить в состав базы данных. Цели проектирования РБД: 1. Понизить избыточность данных 2. Повысить надежность и достоверность данных (т.е. устранить некоторые аномалии) a. Аномалия обновления – ошибки из-за дублирования информации b. Аномалия включения – никакая часть первичного ключа не может быть пустой c. Аномалия удаления – возможна потеря информации Стратегия – обследование системы. Взаимодействие пользователями, обеспечение полного понимания требований. По завершении обследования определяется вероятный технический подход и приблизительный расчет затрат. на этом этапе четко указывается, какие элементы не будут реализованы в рамках данного проекта. Анализ – подробное исследование бизнес-процессов. Проектирование – это процесс, в котором на основе входных данных анализа представляется модель сущностей с атрибутами и отношениями. Реализация – создаются и тестируются программные модули, определенные при проектировании. После реализации переходят к тестированию, а затем к эксплуатации. Главное требование, которое предъявляется на этапе проектирования, заключается в гарантированном поддержании целостного состояния базы данных, т.е. поддерживаются ограничения целостности. Реляционная модель данных поддерживает следующие внутренние ограничения: • категорная целостность –ключ уникально идентифицирует каждый кортеж отношения, т.е. никакой ключевой атрибут не может быть пустым; • ссылочная целостность – значение внешнего ключа дочернего отношения должно быть равно одному из текущих значений первичного ключа родительского отношения. Явные ограничения, в свою очередь, можно разбить на две группы: • семантические зависимости – зависимости между атрибутами отношения, определяемые предметной областью, например: сумма бюджетов всех отделов не должна превышать бюджет предприятия; • функциональные зависимости –ограничения на значения одних атрибутов в зависимости от значений других атрибутов, например: во всех кортежах, где встречается один и тот же номер товара, название и цена товара также должны быть одними и теми же. Функциональная зависимость представляет собой один из возможных типов зависимостей между атрибутами отношения. R(A1A2…An) – схема отношения U = {A1, A2, …, An} – универсальное множество атрибутов X ⊆ U и Y ⊆ U – некоторые подмножества множества атрибутов схемы R Говорят, что Y функционально зависит от X (или X функционально определяет Y: f : X Y ) тогда и только тогда, когда для любой допустимой реализации отношения r(R) каждое значение множества атрибутов X связано в точности с одним значением множества атрибутов Y. Здесь X – детерминант, а Y – зависимость. Семантические зависимости могут быть удовлетворены только за счет использования специальных средств – триггеров и хранимых процедур, что требует от разработчика базы данных серьезных усилий на этапе разработки приложения. С другой стороны, знание функциональных зависимостей может привести к такому проектированию базы данных, что эти ограничения будут удовлетворяться без дополнительных усилий на этапе разработки. Определение ключа: Если R – схема отношения с атрибутами A1, A2, …, An и множеством функциональных зависимостей F, X ⊆ U – некоторое подмножество атрибутов {A1, A2, …, An}, то X называется ключом R, если: • функциональная зависимость X A1A2…An ∈ F+, • ни для какого собственного подмножества Y ⊂ X функциональная зависимость Y A1A2…An ∉ F+ И немного понятной теории из другого источника о ключах: В чистой реляционной теории баз данных это единственный способ сослаться на строку. Ключи бывают разные - потенциальные, первичные, альтенативные, внешние, индексные, хеш-ключи, ключи сортировки, вторичные ключи, ключи шифрование и расшифровки и т.д. Потенциальные ключи. Потенциальным ключом будем называть такую комбинацию столбцов, которая обладает следующими свойствами: • УникальностьюВ таблице нет двух разных строк с одиноковыми значениями в нашем потенциальном ключе. • Неизбыточностью.Нельзя убрать один из столбцом из ключа, так, чтобы он не потерял уникльности. Первичные ключи. В реляционной модели данных один из потенциальных ключей отношения, выбранный в качестве основного ключа (или ключа по умолчанию). Если в отношении имеется единственный потенциальный ключ, он является и первичным ключом. Если потенциальных ключей несколько, один из них выбирается в качестве первичного, а другие называют «альтернативными». С точки зрения теории все потенциальные ключи отношения эквивалентны, то есть обладают одинаковыми свойствами уникальности и минимальности. Однако в качестве первичного обычно выбирается тот из потенциальных ключей, который наиболее удобен для тех или иных практических целей, например для создания внешних ключей в других отношениях либо для создания кластерногоиндекса. Поэтому в качестве первичного ключа, как правило, выбирают тот, который имеет наименьший размер (физического хранения) и/или включает наименьшее количество атрибутов. Если первичный ключ состоит из единственного атрибута, его называют простым ключом. Если первичный ключ состоит из двух и более атрибутов, его называют составным ключом. Вне́шний ключ. Неформально выражаясь, внешний ключ представляет собой подмножество атрибутов некоторой переменной отношения R2, значения которых должны совпадать со значениями некоторогопотенциального ключа некоторой переменной отношения R1. Формальное определение. Пусть R1 и R2 — две переменные отношения, не обязательно различные. Внешним ключом FK в R2 является подмножество атрибутов переменной R2 такое, что выполняются следующие требования: 1. В переменной отношения R1 имеется потенциальный ключ CK такой, что FK и CK совпадают с точностью до переименования атрибутов (то есть переименованием некоторого подмножества атрибутов FK можно получить такое подмножество атрибутов FK’, что FK’ и CK совпадают как по именами, так и по типам атрибутов). 2. В любой момент времени каждое значение FK в текущем значении R2 идентично значению CK в некотором кортеже в текущем значении R1. Иными словами, в каждый момент времени множество всех значений FK в R2 является (нестрогим) подмножеством значений CK в R1. 20. Правила вывода функциональных зависимостей. Функциональная зависимость представляет собой один из возможных типов зависимостей между атрибутами отношения. R(A1A2…An) – схема отношения U = {A1, A2, …, An} – универсальное множество атрибутов X ⊆ U и Y ⊆ U – некоторые подмножества множества атрибутов схемы R Говорят, что Y функционально зависит от X (или X функционально определяет Y: f : X Y ) тогда и только тогда, когда для любой допустимой реализации отношения r(R) каждое значение множества атрибутов X связано в точности с одним значением множества атрибутов Y. Здесь X – детерминант, а Y – зависимость. Обозначения: R(A1A2…An) – схема отношения U = {A1, A2, …An} – универсальное множество атрибутов X ⊆ U, Y ⊆ U, Z ⊆ U, W ⊆ U – некоторые подмножества атрибутов из U XY – объединение атрибутов: X ∪ Y ≡ XY Правила вывода: |