Способы представления базы данных

Различные представления о данных в базах данных. Основные этапы проектирования баз данных

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

4.1. Различные представления о данных в базах данных

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

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

Как уже отмечалось, для создания базы данных и работы с ней используется система управления базами данных. Каждая конкретная СУБД поддерживает определенный вид данных (форматов записей и отношений), называемый моделью данных СУБД .

Следующий этап разработки базы данных предполагает выбор представления концептуальной модели с помощью модели данных конкретной СУБД . Полученное таким образом представление концептуальной модели называется логической моделью БД. Или другими словами, логическая модель – это концептуальная схема, специфицированная в языке конкретной СУБД. Логическая модель представляет данные и элементы данных вне зависимости от их содержания и среды хранения. Далее разработчик системы средствами СУБД отображает полученную логическую модель БД в память ЭВМ и определяет методы доступа. Полученное представление данных в памяти ЭВМ называется внутренним представлением или структурой хранения. Прикладные программы работают с логической моделью, причем каждому пользователю представляется подмножество этой логической модели (подсхема), отражающее его представление о предметной области . Каждая прикладная программа «видит» и обрабатывает только те данные, которые необходимы именно ей.

Соответствующее «видение» данных прикладными программами (пользователями) представляет собой внешние представления. Взаимосвязь вышеуказанных моделей изображена на рис. 4.2.

На данной схеме выделены три различных уровня описания данных (внешний, концептуальный, внутренний). Эти уровни формируют так называемую трехуровневую архитектуру ANSI / SPARC , предложенную в 1975 г. Комитетом планирования стандартов и норм SPARC (Standards Planning and Requirements Committee) Национального института стандартизации США (American National Standards Institute – ANSI ). Основная цель этой архитектуры состоит в отделении пользовательского представления о данных в базе данных от их физического представления. Использование таких представлений о данных позволяет обеспечить выполнение основного требования к БД – независимости программ и данных. При изменении прикладных программ может измениться соответствующее внешнее представление , но логическая модель данных не изменяется и, соответственно, не будут изменяться другие прикладные программы. При изменении внутреннего представления (структур хранения) логическая модель не изменяется, соответственно, не изменяются прикладные программы.

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

Соответствующие представления позволяют описать «видение» базы данных разными лицами, работающими с ней:

Источник

Представления

Применимо к: SQL Server (все поддерживаемые версии) База данных SQL Azure Управляемый экземпляр SQL Azure Azure Synapse Analytics Параллельное хранилище данных

Представление — это виртуальная таблица, содержимое которой определяется запросом. Как и таблица, представление состоит из ряда именованных столбцов и строк данных. Пока представление не будет проиндексировано, оно не существует в базе данных как хранимая совокупность значений. Строки и столбцы данных извлекаются из таблиц, указанных в определяющем представление запросе и динамически создаваемых при обращениях к представлению.

Представление выполняет функцию фильтра базовых таблиц, на которые оно ссылается. Определяющий представление запрос может быть инициирован в одной или нескольких таблицах или в других представлениях текущей или других баз данных. Кроме того, для определения представлений с данными из нескольких разнородных источников можно использовать распределенные запросы. Это полезно, например, если нужно объединить структурированные подобным образом данные, относящиеся к разным серверам, каждый из которых хранит данные конкретного отдела организации.

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

Типы представлений

Кроме основных определяемых пользователем представлений, выполняющих стандартные роли, в SQL Server предусмотрены следующие типы представлений, которые соответствуют специальным назначениям в базе данных.

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

Секционированные представления
Секционированным называется представление, соединяющее горизонтально секционированные данные набора таблиц-элементов, находящихся на одном или нескольких серверах. При этом данные выглядят так, как будто находятся в одной таблице. Представление, соединяющее таблицы-элементы одного экземпляра SQL Server , называется локальным секционированным представлением.

Системные представления
Системные представления предоставляют доступ к метаданным каталога. Системные представления можно использовать для получения сведений об экземпляре SQL Server или объектах, определенных в экземпляре. Например, получить сведения об определяемых пользователем базах данных, доступных в экземпляре, можно через представление каталога sys.databases. Дополнительные сведения см. в разделе Системные представления (Transact-SQL).

Общие задачи работы с представлениями

В следующей таблице приведены ссылки на общие задачи, связанные с созданием или изменением представления.

Источник

Представление (базы данных)

Представление (англ. view , более созвучное не стандартное название — «вид», в сленге программистов часто используется в качестве заимствования из английского — «вьюха», «вьюшка») — виртуальная (логическая) таблица, представляющая собой поименованный запрос (алиас к запросу), который будет подставлен как подзапрос при использовании представления.

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

Содержание

Способ создания и содержимое представлений

Типичным способом создания представлений для СУБД, поддерживающих язык запросов SQL, является связывание представления с определённым SQL-запросом. Соответственно, содержимое представления — это результат выполнения этого запроса, а возможности построения представления ограничиваются только степенью сложности диалекта SQL, поддерживаемого конкретной СУБД. Так, для типичных СУБД, таких как PostgreSQL, Interbase, Firebird, Microsoft SQL Server, Oracle, представление может содержать:

• подмножество записей из таблицы БД, отвечающее определённым условиям (например, при наличии одной таблицы «Люди» можно создать два представления «Мужчины» и «Женщины», в каждом из которых будут записи только о людях соответствующего пола);
• подмножество столбцов таблицы БД, требуемое программой (например, из реальной таблицы «Сотрудники» представление может содержать по каждому сотруднику только ФИО и табельный номер);
• результат обработки данных таблицы определёнными операциями (например, представление может содержать все данные реальной таблицы, но с приведением строк в верхний регистр и обрезанными начальными и концевыми пробелами);
• результат объединения (join) нескольких таблиц (например, при наличии таблиц «Люди», «Адреса», «Улицы», «Фирмы и организации» возможно построение представления, которое будет выглядеть как таблица, для каждого человека содержащее его личные данные, адрес места жительства, название организации, где он работает, и адрес этой организации);
• результат слияния нескольких таблиц с одинаковыми именами и типами полей, когда в представлении попадают все записи каждой из сливаемых таблиц (возможно, с исключением дублирования);
• результат группировки записей в таблице (например, при наличии таблицы «расходы» с записями по каждому платежу можно построить представление, содержащее средства, израсходованные на каждую отдельную статью расходов);
• практически любую комбинацию вышеперечисленных возможностей.

Использование

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

Использование представлений не даёт каких-то совершенно новых возможностей в работе с БД, но может быть очень удобно.

• Представления скрывают от прикладной программы сложность запросов и саму структуру таблиц БД. Когда прикладной программе требуется таблица с определённым набором данных, она делает простейший запрос из подготовленного представления. При этом даже если для получения этих данных требуется чрезвычайно сложный запрос, сама программа этого запроса не содержит.
• Использование представлений позволяет отделить прикладную схему представления данных от схемы хранения. С точки зрения прикладной программы структура данных соответствует тем представлениям, из которых программа эти данные извлекает. В действительности данные могут храниться совершенно иным образом, достаточно лишь создать представления, отвечающие потребностям программы. Разделение позволяет независимо модифицировать прикладную программу и схему хранения данных: как при изменении структуры физических таблиц, так и при изменении программы достаточно изменить представления соответствующим образом. Изменение программы не затрагивает физические таблицы, а изменение физической структуры таблиц не требует корректировки программы.
• С помощью представлений обеспечивается ещё один уровень защиты данных. Пользователю могут предоставляться права только на представление, благодаря чему он не будет иметь доступа к данным, находящимся в тех же таблицах, но не предназначенных для него.
• Поскольку SQL-запрос, выбирающий данные представления, зафиксирован на момент его создания, СУБД получает возможность применить к этому запросу оптимизацию или предварительную компиляцию, что положительно сказывается на скорости обращения к представлению, по сравнению с прямым выполнением того же запроса из прикладной программы.

Специфические типы представлений

Некоторые СУБД имеют расширенные представления для данных, доступных только для чтения. Так, СУБД Oracle реализует концепцию «материализованных представлений» — представлений, содержащих предварительно выбранные невиртуальные наборы данных, совместно используемых в распределённых БД. Эти данные извлекаются из различных удалённых источников (с разных серверов распределённой СУБД). Целостность данных в материализованных представлениях поддерживается за счёт периодических синхронизаций или с использованием триггеров. Аналогичный механизм предусмотрен в Microsoft SQL Server версии 2000.

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

Источник