30. Представления в базах данных

Представление. Динамически сформированный результат одной или нескольких реляционных операций, выполненных над отношениями базы данных с целью получения нового отношения. Представление является виртуальным отношением, которое не всегда реально существует в базе данных, но создается по запросу определенного пользователя в ходе выполнения этого запроса.

С точки зрения пользователя базы данных представление выглядит как реальная таблица данных, содержащая набор поименованных столбцов и строк данных. Но в отличие от реальных таблиц представления не всегда существуют в базе как некоторый набор сохраняемых значений данных. В действительности доступные через представления строки и столбцы данных являются результатом выполнения запроса, заданного при определении представления. СУБД сохраняет определение представления в базе данных. Обнаружив ссылку на представление, СУБД применяет один из ,пвух следующих подходов для формирования представления. При первом подхсде СУБД отыскивает определение представления и преобразуют исходный запрос, лежащий в основе представления, в эквивалентный запрос к таблицам, использованным в определении представления, после чего модифицированный заг рос выполняется. При втором подходе, который называется материализацией представления, готовое представление хранится в базе дан- ных в виде временной таблицы, а его актуальность постоянно поддерживается по мере обновления всех таблиц, лежащих в его основе.

Создание представлений (оператор CREATE VIEW)

Оператор CREATE VIEW имеет следующий формат:

CREATE VIEW ViewName [(newColumnName [, ... ])]

AS subselect [WITH [CASCADED | LOCAL] CHECK OPTION]

Представление определяется с помощью подзапроса subselect, оформленного в виде оператора SELECT языка SQL. Существует необязательная возможность присвоения собственного имени каждому из столбцов представления. Если указывается список имен столбцов, го он должен иметь количество элементов, равное количеству столбцов в результирующей таблице запроса, заданного параметром subselect. Если список имен столбцов опущен, каждый столбец представления будет иметь имя соответствующего столбца результирующей таблицы запроса, заданного параметром subselect. Список имен столбцов должен обязательно задаваться в том случае, эсли в именах столбцов результирующей таблицы имеет место неоднозначность. Подобная ситуация возникает в тех случаях, когда подзапрос включает вычисляемые поля, а конструкция AS с именами столбцов результирующей таблицы не содержит для них имен или же когда результирующая таблица создается с помощью операции соединения и включает столбцы с одинаковыми именами.

Заданный параметром subselect подзапрос принято называть определяющим запросом. Если указана конструкция WITH CHECK OPTION, то гарантируется, что в тех случаях, когда строка данных не удовлетворяет условию, указанному в конструкции WHERE определяющего запроса представления, она не будет добавлена в его базовую таблицу. Следует отметить, что для успешного создания представления необходимо иметь привилегию SELECT для всех упоминаемых в определяющем запросе таблиц, а также привилегию USAGE для всех доменов, используемых в указанных в запросе столбцах. Подробнее речь о привилегиях пойдет ниже. Хотя все представления создаются с помощью одного и того же метода, на практике для различных целей используются разные типы представлений. Назначение представлений различных типов мы продемонстрируем на нескольких конкретных примерах.

Удаление представлений (оператор DROP VIEW)

Представление удаляется из базы данных с помощью оператора DROP VIEW, имеющего следующий формат:

DROP VIEW ViewName [RESTRICT | CASCADE]

При выполнении оператора DROP VIEW определение представления удаляется из базы данных. Например, представление Manager3Staff можно удалить с помощью следующего оператора:

DROP VIEW Manager3Staff;

Если указано ключевое слово CASCADE, при выполнении оператора DROP VIEW будут также удалены все связанные с ним или зависящие от него объекты. Другими словами, будут удалены все объекты, содержащие ссылки на удаляемое представление. Это означает, что такой оператор DROP VIEW удаляет также все представления, которые определены на основе удаляемого представления. Если указывается ключевое слово RESTRICT и существуют любые прочие объекты, зависящие от существования удаляемого представления, выполнение этого оператора блокируется. По умолчанию принимается значение RESTRICT.

31.Жизненный цикл БД.

Процесс проектирования, реализации и  поддержания системы базы данных называется жизненным циклом базы данных (ЖЦБД). Процедура создания системы называется жизненным циклом системы (ЖЦС).

            Понимание и правильный подход к ЖЦБД очень важен и требует детального рассмотрения, так как в его основе лежит подход, ориентированный на данные. Элементы данных более стабильны, чем выполняемые функции системы. Создание правильной структуры данных требует сложного анализа классов единиц данных и отношений между ними. Если построить логичную схему базы данных, то в дальнейшем можно создать любое количество функциональных систем, использующих эту схему. Функционально-ориентированный подход можно применять лишь для создания временных систем, которые рассчитаны на недолгое время функционирования.

            ЖЦБД состоит из следующих этапов:

            1. Предварительное планирование – планирование БД, выполняемое в процессе разработки стратегического плана БД. В процессе планирования собирается следующая информация:

   какие прикладные программы используются, и какие функции они выполняют;

   какие файлы связаны с каждым из этих приложений;

   какие новые приложения и файлы находятся в процессе работы.

            Данная информация помогает определить, как используется информация приложений, определить будущие требования к системе БД.

            Информация этого этапа документируется в виде обобщенной модели данных.

            2. Проверка осуществимости. Здесь определяется технологическая, операционная и экономическая осуществимость плана создания БД, т. е.:

   технологическая осуществимость – есть ли технология для реализации запланированной БД?

   операционная осуществимость – есть ли средства и эксперты, необходимые для успешного осуществления плана создания БД?

   экономическая целесообразность – можно ли определить выводы? Окупится ли запланированная система? Можно ли оценить издержки и выгоду?

            3. Определение требований включает выбор целей БД, выяснение информационных требований к системе и требований к оборудованию и программному обеспечению. Таким образом, на данном этапе сбора данных и определения требований создаётся общая информационная модель, выражающаяся в следующих задачах:

   Определяются цели системы путём анализа информационных потребностей. Здесь также обязательно указывается, какую именно БД следует создавать (распределённую, целостную) и какие коммуникационные средства необходимы. Выходной документ – комментарий, описывающий цели системы.

   Определение пользовательских требований: документация в виде обобщённой информации (комментарии, отчёты, опросы, анкеты и т. д.); фиксация функций системы и определение прикладных систем, которые будут выполнять эти требования. Данные представляются в виде соответствующих документов.

   Определение общих требований к оборудованию и программному обеспечению, связанных с поддержанием желаемого уровня быстродействия. (Выяснение количества пользователей системы, числа входных сообщений в день, количество распечаток). Данная информация используется для выбора типов компьютеров и СУБД, объёма дисков, количества принтеров. Данные этого этапа излагаются в отчёте, содержащем примерные конфигурации оборудования и программного обеспечения.

   Разработка плана поэтапного создания системы, включающий выбор исходных приложений.

            4. Концептуальное проектирование – создание концептуальной схемы БД. Спецификации разрабатываются в той степени, которая необходима для перехода к реализации.

            Основным выходным документом является единая инфологическая модель (или схема БД на концептуальном уровне). При разработке данной модели используются информация и функции, которые должна выполнить система, определённые на этапе сбора и определения требований к системе. На данном этапе желательно также определить: 1) правила для данных; 2) правила для процессов; 3) правила для интерфейса.

            5. Реализация – процесс превращения концептуальной модели в функциональную БД. Он включает в себя следующие этапы.

            1) Выбор и приобретение необходимой СУБД.

            2) Преобразование концептуальной (инфологической) модели БД в логическую и физическую модель данных:

   на основе инфологической модели данных строится схема данных для конкретной СУБД, при необходимости реализуется денормализация БД с целью ускорения обработки запросов во всех критичных по времени приложениях;

   определяются, какие прикладные процессы необходимо реализовать в схеме данных как хранимые процедуры;

   реализовать ограничения, предназначенные для обеспечения целостности данных и реализации правил для данных;

   спроектировать и сгенерировать триггеры для реализации всех централизованно определённых правил для данных и правил целостности данных, которые не могут быть заданы как ограничения;

   разработать стратегию индексирования и кластеризации; выполнить оценку размеров всех таблиц, кластеров и индексов;

   определить уровни доступа пользователей, разработать и внедрить правила обеспечения безопасности и аудита. Создать роли и синонимы для обеспечения многопользовательского доступа с согласованными уровнями полномочий доступа.

   разработать сетевую топологию БД и механизм бесшовного доступа к удалённым данным (реплицированная или распределённая БД).

            3) Построение словаря данных, который определяет хранение определений структуры данных БД. Словарь данных также содержит информацию о полномочиях доступа, правилах защиты данных и контроля данных.

            4) Заполнение базы данных.

            5) Создание прикладных программ, контроль управления.

            6) Обучение пользователей.

6. Оценка и усовершенствование схемы БД. Включает опрос пользователей с целью выяснения функциональных неучтенных потребностей. При необходимости вносятся изменения, добавление новых программ и элементов данных по мере изменения и расширения потребностей.

            Таким образом, ЖЦБД включает в себя:

   Изучение предметной области и представление соответствующей документации (1-3).

   Построение инфологической модели (4).

   Реализация (5).

   Оценка работы и поддержка БД (6).