
- •1)Теоретико-множественные операции реляционной алгебры. Привести примеры на каждую.
- •2)Специальные операции реляционной алгебры. Привести примеры на каждую.
- •X devideby y
- •3)Операторы определения данных в языке sql. Пример на каждый оператор.
- •4)Операторы манипулирования данными в языке sql. Пример на каждый оператор.
- •5)Применение агрегатных функций в операторе выбора select. Привести примеры.
- •6)Использование подзапросов языке sql. Привести примеры.
- •7)Внешние объединения в языке sql. Привести примеры.
- •8)Понятие функциональной и транзитивной зависимости. Аксиомы Армстронга.
- •9)Понятие транзакции и свойства транзакций.
- •10)Первая и вторая нормальные формы. Привести примеры.
- •11)3-Я нормальная форма. Приведение отношения из 2-о
- •13)Декларативные ограничения целостности. Привести пример на каждый вид.
- •Ограничения целостности, задаваемые на уровне доменов (при поддержке доменной структуры).
- •Ограничения целостности, задаваемые на уровне отношения.
- •Ограничения целостности базы данных
- •14)Представления. Виды представлений. Обновляемые представления. Примеры.
- •15)Триггеры. Привести примеры.
- •16)Критерии успеха программного продукта.
- •17)Организационная структура компании: Функциональная структура и Матричная организация.
- •18)Состав и роли проектной команды.
- •19)Жизненный цикл проекта. Фазы и продукты.
- •20)Концепция проекта.
- •21)Планирование проекта.
- •22)Базовое расписание проекта.
- •23)Управление проектом, направленное на снижение рисков.
- •24)Оценка трудоемкости и сроков разработки по.
- •1. Метод функциональных точек
- •2. Cocomo
- •3. Метод pert
14)Представления. Виды представлений. Обновляемые представления. Примеры.
Представление или виртуальная таблица - это таблица, которой физически нет в БД, но которая существует в представлении пользователя о логической структуре БД. Т.е. это поименованный запрос на выборку данных из одной или нескольких таблиц, определение которых сохранено в словаре БД.
Оператор определения представления имеет следующий вид:
<создание представления>::= CREATE VIEW <имя представления>
[ (<список столбцов>)] AS <SQL-запрос>
При необходимости в представлении можно задать новое имя для каждого столбца виртуальной таблицы. При этом надо помнить, что если указывается список столбцов, то он должен содержать ровно столько столбцов, сколько содержит их SQL-запрос.
Если список имен столбцов в представлении не задан, то каждый столбец представления получает имя соответствующего столбца запроса.
Виды представлений:
Горизонтальное (применяется для уменьшения объема реальных таблиц в обработке и уменьшения доступа пользователей);
Этот вид представления широко применяется для уменьшения объема реальных таблиц в обработке и ограничения доступа пользователей к закрытой для них информации. Так, например, правилом хорошего тона считается, что руководитель подразделения в некоторой фирме может видеть оклады и результаты работы только своих сотрудников, в этом случае для него создается горизонтальное представление, в которое загружены строки общей таблицы сотрудников, работающих в его подразделении.
Например, у нас есть таблица "Сотрудник" ( EMPLOYEE ) с полями "Табельный номер" ( T_NUM ), "ФИО" ( NAME ), "должность"(POSITION ), "оклад"( SALARY ), "надбав-ка"( PREMIUM ), "отдел" ( DEPARTMENT ).
Для приложения, с которым работает начальник отдела продаж, будет создано представление
CREATE VIEW SAL_DEPT
AS
SELECT *
FROM EMPLOYEE
WHERE DEPARTMENT= "Отдел продаж"
Вертикальное;
Этот вид представления практически соответствует выполнению операции проектирования некоторого отношения на ряд столбцов. Он используется в основном для скрытия информации, которая не должна быть доступна в конкретной внешней модели.
Например, для работника табельной службы, который учитывает присутствие сотрудников на работе, информация об окладе и надбавке должна быть закрыта. Для него можно создать следующее вертикальное представление:
CREATE VIEW TABEL
AS
SELECT T_NUM,NAME, POSITION, DEPARTMENT
FROM EMPLOYEE
Сгруппированное (создаются запросы с группировкой);
Эти представления содержат запросы, которые имеют группировку. Сгруппированные представления всегда должны содержать список столбцов. Они могут использовать агрегированные функции в качестве результирующих столбцов, а в дальнейшем это представление может использоваться как виртуальная таблица, например, в других запросах.
Создадим представление, которое определяет суммарный фонд заработной платы и надбавок по каждому подразделению с указанием количества сотрудников, минимальной, максимальной и средней зарплаты и надбавки по подразделению. Такой запрос позволяет сравнить заработную плату и надбавки прямо по всем подразделениям, и он может быть очень эффективно использован администрацией при проведении сравнительного анализа подразделений фирмы.
CREATE VIEW RATE
DEPARTMENT, COUNT(*), SUM(SALARY), SUM(PREMIUM), MAX(SALARY), MIN(SALARY),
AVERAGE (SALARY), MAX(PREMIUM), MIN(PREMIUM), AVERAGE (PREMIUM)
AS
SELECT DEPARTMENT, COUNT(*), SUM(SALARY), SUM(PREMIUM), MAX(SALARY),
MIN(SALARY), AVERAGE (SALARY), MAX(PREMIUM), MIN(PREMIUM),
AVERAGE (PREMIUM)
FROM EMPLOYEE
GROUP BY DEPARTMENT
Объединенные представления (виртуальные таблицы с соединениями. С такими таблицами используется опция проверки WITH CHECK OPTION. Любая вставка или обновление будет проверяться на соотв. опред. вирт. табл.)
Часто представления базируются на многотабличных запросах. Такое использование позволяет упростить разработку пользовательского интерфейса, сохранив при этом корректность схемы базы данных. Для примера снова обратимся к базе данных "Библиотека" и создадим представление, которое содержит список читателей-должников с указанием книг, которые у них на руках, и указанных в базе сроков сдачи этих книг. Такое представление может понадобиться для административного приложения, которое разрабатывается для директора библиотеки или его заместителя, они должны принимать административные меры для наказания нарушителей и возврата книг в библиотеку.
CREATE VIEW DEBTORS
ISBN,TITLE, NUM_READER,NAME,ADRES,HOME_PHON, WORK_PHON,DATA_OUT
AS
SELECT ISBN,TITLE,NUM_READER,NAME,ADRES,HOME_PHON, WORK_PHON,DATA_OUT
FROM BOOKS,EXEMPLAR,READERS
WHERE BOOKS.ISBN = EXEMPLAR.ISBN AND
EXEMPLAR.NUM_READER = READERS.NUM_READER AND
EXEMPLAR.PRESENT = FALSE AND
EXEMPLAR.DATA_OUT < GetDate()
Обновляемость представлений
Обновляемыми являются представления, полученные из единственной базовой таблицы простым исключением некоторых ее строк и (или) столбцов.
Безусловно обновляемыми являются представления, полученные из единственной базовой таблицы простым исключением некоторых ее строк и (или) столбцов, обычно называемые "представление-подмножество строк и столбцов". Таким является представление Мясные_блюда, полученное из базовой таблицы Блюда исключением из нее столбца Труд и строк, не содержащих значение 'Мясо' в столбце Основа. Работая с ним, можно:
вставить (операция INSERT) новую строку, например, строку (34, 'Шашлык', 'Г', 150), фактически вставляя соответствующую строку (34, 'Шашлык', 'Г', 150, NULL) в лежащую в основе базовую таблицу Блюда;
удалить (операция DELETE) существующую строку из представления, например строку (13, 'Бастурма', 'Г', 300), фактически удаляя соответствующую строку (13, 'Бастурма', 'Г', 300, 5) из таблицы Блюда;
обновить (операция UPDATE) какое-либо поле в существующей строке, например увеличить массу порции Бефстроганова с 210 до 250 граммов, фактически осуществляя то же самое изменение в соответствующем поле таблицы Блюда.
Однако если бы представление Мясные_блюда имело вместо столбца Выход столбец Вых_труд, полученный путем суммирования значений столбцов Выход и Труд таблицы Блюда, то указанные выше операции INSERT и UPDATE были бы отвергнуты системой. Действительно, как распределить вводимое значение столбца Вых_труд (153 или 254) между значениями столбцов Выход и Труд базовой таблицы Блюда? Была бы отвергнута и операция удаления масла из состава бастурмы, если бы ее попытались выполнить путем удаления строки ('Бастурма', 'Масло', 5) в представлении Горячие_мясные_блюда. Встает множество вопросов: надо ли удалять из базовой таблицы Блюда строку, содержащую значение 'Бастурма' в столбце Блюдо?; надо ли удалять из базовой таблицы Продукты строку, содержащую значение 'Масло' в столбце Продукт?; надо ли удалять из базовой таблицы Состав все строки, содержащие значение 5 в столбце Вес?. Последний вопрос возник потому, что при конструировании представления Горячие_мяс-ные_блюда в него не была включена информация о связях между лежащими в его основе базовыми таблицами Блюда, Состав и Продукты, и у системы нет прямых путей для поиска той единственной строки таблицы Состав, которая должна быть удалена.
Таким образом, некоторые представления по своей природе обновляемы, в то время как другие таковыми не являются. Здесь следует обратить внимание на слова "по своей природе". Дело заключается не просто в том, что некоторая СУБД не способна поддерживать определенные обновления, в то время как другие СУБД могут это делать. Никакая СУБД не может непротиворечивым образом поддерживать без дополнительной помощи обновление такого представления как Горячие_мясные_блюда. "Без дополнительной помощи" означает здесь "без помощи какого-либо человека - пользователя".
Как было указано выше, к теоретически обновляемым представ-лениям относятся представления-подмножества строк и столбцов. Однако существуют некоторые представления, которые не являются представлениями-подмножествами строк и столбцов, но также теоретически обновляемы. Хотя известно, что такие есть и можно привести их примеры, но невозможно дать их формального определения. Неверным является такое формальное определение некоторых авторов - "нельзя обновлять соединение". Во-первых, в некоторых соединениях с успехом выполняется операция UPDATE, а, во-вторых, как было показано выше, не обновляемы и некоторые представления, не являющиеся соединениями. Кроме того, не все СУБД поддерживают обновление любых теоретически обновляемых представлений. Поэтому пользователь должен сам оценивать возможность использования операций DELETE, INSERT или UPDATE в созданном им представлении.