Разбиране на изгледите в SQL

От Манодж Дебнат

Таблиците в SQL база данни може да съдържат огромно количество данни, но те не винаги са в полезен формат, за да бъдат лесно използвани. Обемът на данните трябва да се филтрира въз основа на определени критерии за ефективно използване. Поради съображения за сигурност може да искаме да направим публични само определено количество данни, докато останалите може да са достъпни за привилегированите потребители. SQL DML операциите са разширяеми и се използват за филтриране през една или повече таблици, използвайки сложни изрази на заявка. Възползвайки се от идеята, можем да създадем виртуални таблици от постоянни базови таблици, използвайки SQL, които ще съдържат точните данни, от които се нуждаем. Това е причината стандартът SQL:2006 да въведе използването на таблици или изгледи. Дефиницията на изглед или виртуална таблица съществува като обект на схема. Тази статия представя концепцията за изгледи в SQL, как работи и показва как се прилага с някои примери.

Въведение в SQL изгледи

SQL изгледите не са нищо друго освен виртуалните таблици, които се намират в паметта, извлечена от една или повече базови таблици. Виртуалните таблици означават, че кортежите в изгледите нямат физическо съществуване и не се съхраняват в базата данни. Кортежите са като временни данни, създадени като резултат от SQL заявката, която обикновено изтегля филтрирани данни от една или повече базови таблици. В резултат на това има ограничение за типа операция, която може да бъде приложена към таблица за преглед. Например, операцията за актуализиране не може да се приложи към всички типове изгледи, но няма ограничение за прилагане на SQL заявка към нея.

Примерите по-долу са тествани с базата данни MySQL. Започнете със създаване на няколко таблици:

моята_компания база данни:

CREATE DATABASE my_company;

CREATE TABLE Employee(
    empId INT(11) UNSIGNED CHECK (empId > 0),
    empName VARCHAR(20),
    birthDate DATE,
    address TEXT(128),
    gender VARCHAR(1),
    salary DECIMAL(15,2),
    managerId INT(11) UNSIGNED,
    deptId INT(11) UNSIGNED,
    PRIMARY KEY(empId)
);
 
CREATE TABLE Department(
    deptId INT(11) UNSIGNED CHECK (empId > 0),
    deptName VARCHAR(20),
    deptMgrId INT(11) UNSIGNED,
    mgrStartDate DATE,
    PRIMARY KEY(deptId)
);

CREATE TABLE Project(
    projId INT(11) UNSIGNED CHECK (empId > 0),
    projName VARCHAR(20),
    projLocation TEXT(128),
    deptId INT(11) UNSIGNED,
    PRIMARY KEY(projId)
);
 
CREATE TABLE EmpWorksOnProj(
    empId INT(11) UNSIGNED,
    projId INT(11) UNSIGNED,
    hoursWorked DECIMAL(4,2)
);  
 
ALTER TABLE Employee ADD CONSTRAINT fk_emp_mgr FOREIGN KEY(managerId) REFERENCES Employee(empId);
ALTER TABLE Employee ADD CONSTRAINT fk_emp_dept FOREIGN KEY(deptId) REFERENCES Department(deptId);
ALTER TABLE Department ADD CONSTRAINT fk_dept_mgr FOREIGN KEY(deptMgrId) REFERENCES Employee(empId);
ALTER TABLE Project ADD CONSTRAINT fk_proj_dept FOREIGN KEY(deptId) REFERENCES Department(deptId);

Изгледите могат да се разглеждат като референтна таблица и можем да я използваме толкова често, колкото искаме, въпреки че може да не съществува физически. Например, често може да се наложи да се позоваваме на моята_компания база данни и намерете Служител и Проект информация. Имайте предвид, че има много към много отношения между Служител и Проект тъй като един човек може да работи по много проекти и също така един проект има много служители. Следователно, вместо да посочвате обединяването на три таблици:Служител , EmpWorksOnProj и Проект всеки път, когато имаме нужда от информация за съвместна работа и издадем заявка, ние дефинираме изглед, който е посочен като резултат от обединяването между тези таблици. Изгледът формира виртуалната таблица, създадена от резултата от заявката. Предимството е, че заявката сега може да извлича от единична резултатна таблица, вместо да се налага да извлича от три свързани таблици. Колекцията от таблици:Служител , Проект , Отдел и т.н. по този начин формират базовите таблици или дефиниращата таблица на изгледа.

Нека създадем някои изгледи въз основа на схемата, дадена по-горе.

CREATE VIEW V1
AS
SELECT
   empName, projName, hoursWorked
FROM
   Employee, Project, EmpWorksOnProj
WHERE
   Employee.empId=EmpWorksOnProj.empId
AND
   Project.projId=EmpWorksOnProj.projId;
 

Начинът за определяне на SQL заявки в изглед или виртуална таблица е същият като указването на заявки, включващи базови таблици. Можете да използвате SQL SELECT за изгледи, за да получите данните, както следва:

ИЗБЕРЕТЕ * ОТ V1;

Следното създава втори изглед:

CREATE VIEW V2 КАТО ИЗБЕРЕТЕ DeptName, COUNT(*), SUM(заплата) ОТ отдел, Employee WHERE Employee.deptId=Department.deptId ГРУПА BY deptName;

SQL SELECT води до

SELECT * FROM V1;

Имайте предвид, че в изглед V1 имената на атрибути са получени от основната таблица. Във V2 имената на новите атрибути се посочват изрично, като се използва съответствие едно към едно между посочените атрибути на клаузата CREATE VIEW и тези, посочени в клаузата SELECT. Клаузата SELECT с изгледа е решаваща за дефиницията на изгледа.

Предполага се, че информацията, която се вижда, винаги е актуална. Това означава, че винаги трябва да отразява промените, направени в базовите таблици, на които е дефиниран. Това е интересно, тъй като означава, че изгледът всъщност не се материализира в момента на дефинирането му, а по-късно, когато към него е посочена заявка. Системата за управление на базата данни във фонов режим е отговорна за поддържането на изгледа актуален.

АКТУАЛИЗИРАНЕ, ВМЕСВАНЕ и ИЗТРИВАНЕ на изгледи

В SQL, възможно е да се създават обновяеми изгледи, които могат да се използват за промяна на съществуващи данни или вмъкване на нови редове в изгледа, което от своя страна вмъква или променя записа в основната таблица . Изгледът може да се актуализира или не се определя от израза SELECT, дефиниран в дефиницията на изгледа. Няма специална клауза за определяне на изглед, който да може да бъде актуализиран. Обикновено дефиницията на изгледа трябва да е проста и не трябва да съдържа никакви агрегатни функции като SUM, AVG, MAX, MIN, COUNT. Всякакъв вид групиране или клауза DISTINCT или JOIN също прави изгледа неподлежащ на актуализиране. Вижте съответното ръководство за база данни на конкретната RDBMS за това какво прави изгледа неподлежащ на актуализация.

Нека създадем изглед, който може да се актуализира:

CREATE VIEW v3_ch_dept_name
AS
SELECT
   deptId, deptName, deptMgrId, mgrStartDate
FROM
   Department;

Заявката SELECT при изглед:

SELECT * FROM v3_ch_dept_name;

Сега актуализирайте изгледа, като промените името на отдела (deptName).

UPDATE
   v3_ch_dept_name
SET
   deptName = 'Security'
WHERE
   deptId = 5;

Ред може да бъде вмъкнат в изгледа, както следва:

INSERT
   INTO v3_ch_dept_name
VALUES (7,'Logistics',666884444,'1982-07-07');

Също така можем да ИЗтрием ред от изгледа, както следва:

DELETE FROM v3_ch_dept_name WHERE deptId = 7;

В MySQL можете лесно да намерите изгледите в база данни, които могат да се актуализират или не, като използвате следната команда SELECT.

SELECT
   table_name
FROM
   information_schema.views
WHERE
   is_updatable like 'YES'
AND
   table_schema like 'my_company';

ОТПУСКАНЕ на изгледи от базата данни

Изглед винаги може да бъде изхвърлен с DROP VIEW команда.

DROP VIEW V1;

Имайте предвид, че когато изпълним командата drop view, тя премахва дефиницията на изглед. Основните данни, съхранявани в базовите таблици, от които е получен този изглед, остават непроменени. Веднъж изпуснат изглед може да бъде пресъздаден със същото име.

Изявлението ALTER VIEW

Изгледите обикновено не могат да се променят според стандарта SQL:2006, което означава, че изразът ALTER VIEW не работи с изгледи. Въпреки това, има RDBMS като MySQL или SQL Server, които поддържат този вид изявление. Оракулът вярва, че първо трябва да изпусне изгледа, след което да го пресъздаде, вместо да го променя. Следователно функциите, поддържани от изгледите от RDBMS, варират от продукт до продукт.

Заключение

SQL изгледите също са полезен инструмент за достъп до множество типове данни. Сложните заявки могат да се съхраняват в дефиницията на изглед. Това използва повторно използване, защото можем да извикаме изгледа, вместо да пресъздаваме заявките всеки път, когато имаме нужда от тях. Това е удобен начин да представим информация на потребителя, криейки много информация, която не искаме да излагаме на всички. Това е важно и от гледна точка на сигурността. Сложните структури могат да бъдат синтезирани и представени в лесен формат за крайния потребител.

Препратки:

Елмасри, Рамез и Шамкант Б. Нават. Основи на системите за бази данни . Pearson Education.