25.Реляционные языки.
Для управления данными в реляционной СУБД используются разнообразные языки. Их можно разбить на 2 категории:
-процедурные – языки, в которых пользователь точно задает системе каким образом манипулировать данными (удаление, добавление, обновление)
-непроцедурные – языки, в которых пользователь определяет требования к данным, т. е. необходимость производить какой-то анализ, обработку используемых данных.
Коддом были предложены в качестве реляционных языков язык реляционной алгебры и реляционного исчисления. Реляционная алгебра – процедурный язык, реляционное исчисление – непроцедурный язык.
Реляционная алгебра определяется следующими операторами: пять основных – выборка, проекция, декартово произведение, объединение, вычитание и три дополнительных – соединение, пересечение, деление. Эти операции делятся на:
-унарные (выборка, проекция)
-бинарные
Реляционные исчисления бывают 2 видов: реляционные исчисления кортежей (Кодд) и реляционные исчисления доменов (Лакруа, Пиро).
26.Подключение бд к sql server.
В большинстве случаев строка подключения выглядит примерно так:
"User ID=sa;Password=;Initial Catalog=myDatabase;Data Source=(local);"
Безопасность соединения. Здесь существуют два варианта, обычный:-
«Data Source=myServerAddress;Initial Catalog=myDataBase;User Id=myUsername;Password=myPassword;»
и так называемый Trusted Connection
«Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;» или другой вариант
«Server=myServerAddress;Database=myDataBase;Trusted_Connection=True;»
При обычном соединении, мы указывает имя пользователя и пароль в строке подключения. Тут могут использоваться имена локальных Windows пользователей (локальные учетные записи), имена пользователей домена AD, или иена пользователей SQL сервера, при условии когда на SQL сервере включены оба типа аутентификации: Windows и SQL. В случае Trusted Connection может использоваться только режим Windows аутентификации SQL сервера. При этом имя пользователя и пароль не указываются в строке подключения. Вместо этого данные о пользователе берутся из текущего контекста безопасности приложения.
27.Связанные запросы.
Если в SQL используются подзапросы, во вложенном запросе можно ссылаться на таблицу, имя которой указано в предложении FROM внешнего запроса. Формируется связанный подзапрос. Например, отыскать всех покупателей, которые сделали заказы 10.03.1990 можно следующим образом:
SELECT *
FROM Customers a
WHERE 10.03.1990 IN (
SELECT odate
FROM Orders b
WHERE a.cnum = b.cnum);
Например, необходимо контролировать корректность связи продавцов с покупателями, выводя строчку, если соответствие не обнаружено:
SELECT *
FROM Orders main
WHERE NOT snum = (
SELECT snum
FROM Customers
WHERE cnum = main.cnum);
28.Этапы обработки запросов.
Можно представить, что обработка поступившего в систему запроса состоит из фаз, изображенных ниже.
На первой фазе запрос, заданный на языке запросов, подвергается лексическому и синтаксическому анализу. При этом вырабатывается его внутреннее представление, отражающее структуру запроса и содержащее информацию, которая характеризует объекты базы данных, упомянутые в запросе (отношения, поля и константы). Информация о хранимых в базе данных объектах выбирается из каталогов базы данных. Внутреннее представление запроса используется и преобразуется на следующих стадиях обработки запроса. Форма внутреннего представления должна быть достаточно удобной для последующих оптимизационных преобразований.
На второй фазе запрос во внутреннем представлении подвергается логической оптимизации. Могут применяться различные преобразования, "улучшающие" начальное представление запроса. Среди преобразований могут быть эквивалентные, после проведения которых получается внутреннее представление, семантически эквивалентное начальному (например, приведение запроса к некоторой канонической форме), Преобразования могут быть и семантическими: получаемое представление не является семантически эквивалентным начальному, но гарантируется, что результат выполнения преобразованного запроса совпадает с результатом запроса в начальной форме при соблюдении ограничений целостности, существующих в базе данных. После выполнения второй фазы обработки запроса его внутреннее представление остается непроцедурным, хотя и является в некотором смысле более эффективным, чем начальное.
Третий этап обработки запроса состоит в выборе на основе информации, которой располагает оптимизатор, набора альтернативных процедурных планов выполнения данного запроса в соответствии с его внутреннем представлением, полученным на второй фазе. Для каждого плана оценивается предполагаемая стоимость выполнения запроса. При оценках используется статистическая информация о состоянии базы данных, доступная оптимизатору. Из полученных альтернативных планов выбирается наиболее дешевый, и его внутреннее представление теперь соответствует обрабатываемому запросу.
На четвертом этапе по внутреннему представлению наиболее оптимального плана выполнения запроса формируется выполняемое представление плана. Выполняемое представление плана может быть программой в машинных кодах, если, как в случае System R, система ориентирована на компиляцию запросов в машинные коды, или быть машинно-независимым, но более удобным для интерпретации, если, как в случае INGRES, система ориентирована на интерпретацию запросов. В нашем случае это непринципиально, поскольку четвертая фаза обработки запроса уже не связана с оптимизацией.
Наконец, на пятом этапе обработки запроса происходит его реальное выполнение. Это либо выполнение соответствующей подпрограммы, либо вызов интерпретатора с передачей ему для интерпретации выполняемого плана.