Телевизор 

Что такое схема данных. Структура базы даных. Смотреть что такое "Схема базы данных" в других словарях

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

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

Схема как структура базы данных

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

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

Основными объектами графического представления схемы являются таблицы и связи, определяемые внешними ключами.

Видео по теме

Схема как объект базы данных

Есть и другое понятие схемы в теории баз данных.

В Oracle схема привязывается только к одному пользователю (USER) и является логическим набором объектов базы данных. Схема создаётся при создании пользователем первого объекта, и все последующие объекты, созданные этим пользователем, становятся частью этой схемы.

Схема может включать другие объекты, принадлежащие этому пользователю:

  • таблицы,
  • последовательности,
  • хранимые программы,
  • кластеры,
  • связи баз данных,
  • триггеры,
  • библиотеки внешних процедур,
  • индексы,
  • пакеты,
  • хранимые функции и процедуры,
  • синонимы,
  • представления,
  • снимки,
  • объектные таблицы,
  • объектные типы,
  • объектные представления.

Существуют и подобъекты схемы, такие как:

  • столбцы: таблиц и представлений,
  • секции таблиц,
  • ограничения целостности,
  • триггеры,
  • пакетные процедуры и функции и другие элементы, хранимые в пакетах (курсоры, типы и т. п).

Существуют объекты, независимые от схемы:

  • каталоги,
  • профили,
  • роли,
  • сегменты,
  • табличные области,
  • пользователи.

Уровни схемы базы данных

  • Концептуальная схема - карта концепций и их связей

Схемы используются в модели безопасности компонента Database Engine для упрощения взаимоотношений между пользователями и объектами, и, следовательно, схемы имеют очень большое влияние на взаимодействие пользователя с компонентом Database Engine. В этом разделе рассматривается роль схем в безопасности компонента Database Engine. В первом подразделе описывается взаимодействие между схемами и пользователями, а во втором обсуждаются все три инструкции языка Transact-SQL, применяемые для создания и модификации схем.

Разделение пользователей и схем

Схема - это коллекция объектов базы данных, имеющая одного владельца и формирующая одно пространство имен. (Две таблицы в одной и той же схеме не могут иметь одно и то же имя.) Компонент Database Engine поддерживает именованные схемы с использованием понятия принципала (principal). Как уже упоминалось, принципалом может быть индивидуальный принципал и групповой принципал.

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

Отделение пользователей базы данных от схем дает значительные преимущества, такие как:

    один принципал может быть владельцем нескольких схем;

    несколько индивидуальных принципалов могут владеть одной схемой посредством членства в ролях или группах Windows;

    удаление пользователя базы данных не требует переименования объектов, содержащихся в схеме этого пользователя.

Каждая база данных имеет схему по умолчанию, которая используется для определения имен объектов, ссылки на которые делаются без указания их полных уточненных имен. В схеме по умолчанию указывается первая схема, в которой сервер базы данных будет выполнять поиск для разрешения имен объектов. Для настройки и изменения схемы по умолчанию применяется параметр DEFAULT_SCHEMA инструкции CREATE USER или ALTER USER. Если схема по умолчанию DEFAULT_SCHEMA не определена, в качестве схемы по умолчанию пользователю базы данных назначается схема dbo .

Инструкция CREATE SCHEMA

В примере ниже показано создание схемы и ее использование для управления безопасностью базы данных. Прежде чем выполнять этот пример, необходимо создать пользователей базы данных Alex и Vasya, как будет описано в следующей статье (вы можете вернуться к этим примерам позже).

USE SampleDb; GO CREATE SCHEMA poco AUTHORIZATION Vasya GO CREATE TABLE Product (Number CHAR(10) NOT NULL UNIQUE, Name CHAR(20) NULL, Price MONEY NULL); GO CREATE VIEW view_Product AS SELECT Number, Name FROM Product; GO GRANT SELECT TO Alex; DENY UPDATE TO Alex;

В этом примере создается схема poco, содержащая таблицу Product и представление view_Product. Пользователь базы данных Vasya является принципалом уровня базы данных, а также владельцем схемы. (Владелец схемы указывается посредством параметра AUTHORIZATION . Принципал может быть владельцем других схем и не может использовать текущую схему в качестве схемы по умолчанию.)

Две другие инструкции, применяемые для работы с разрешениями для объектов базы данных, GRANT и DENY, подробно рассматриваются позже. В этом примере инструкция GRANT предоставляет инструкции SELECT разрешения для всех создаваемых в схеме объектов, тогда как инструкция DENY запрещает инструкции UPDATE разрешения для всех объектов схемы.

С помощью инструкции CREATE SCHEMA можно создать схему, сформировать содержащиеся в этой схеме таблицы и представления, а также предоставить, запретить или удалить разрешения на защищаемый объект. Как упоминалось ранее, защищаемые объекты - это ресурсы, доступ к которым регулируется системой авторизации SQL Server. Существует три основные области защищаемых объектов: сервер, база данных и схема, которые содержат другие защищаемые объекты, такие как регистрационные имена, пользователи базы данных, таблицы и хранимые процедуры.

Инструкция CREATE SCHEMA является атомарной. Иными словами, если в процессе выполнения этой инструкции происходит ошибка, не выполняется ни одна из содержащихся в ней подынструкций.

Порядок указания создаваемых в инструкции CREATE SCHEMA объектов базы данных может быть произвольным, с одним исключением: представление, которое ссылается на другое представление, должно быть указано после представления, на которое оно ссылается.

Принципалом уровня базы данных может быть пользователь базы данных, роль или роль приложения. (Роли и роли приложения рассматриваются в одной из следующих статей.) Принципал, указанный в предложении AUTHORIZATION инструкции CREATE SCHEMA, является владельцем всех объектов, созданных в этой схеме. Владение содержащихся в схеме объектов можно передавать любому принципалу уровня базы данных посредством инструкции ALTER AUTHORIZATION .

Для исполнения инструкции CREATE SCHEMA пользователь должен обладать правами базы данных CREATE SCHEMA. Кроме этого, для создания объектов, указанных в инструкции CREATE SCHEMA, пользователь должен иметь соответствующие разрешения CREATE.

Инструкция ALTER SCHEMA

Инструкция ALTER SCHEMA перемещает объекты между разными схемами одной и той же базы данных. Инструкция ALTER SCHEMA имеет следующий синтаксис.

Создание схемы данных

После создания структур таблиц БД следует создать схему данных. Предварительно все таблицы БД должны быть закрыты. Создавать или изменять связи между открытыми таблицами нельзя.

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

Рис. 12. Два окна: Схема данных и Добавление таблицы

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

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

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

После выполнения указанных действий откроется окно Изменение связей (рис. 13). При этом в поле Тип отношения автоматически установится значение один-ко-многим.

Рис. 13. Окно Изменение связей

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

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

Обеспечение связной целостности данных означает, что при корректировке базы данных Access обеспечивает для связанных таблиц контроль за соблюдением следующих условий:

q В подчиненную таблицу не может быть добавлена запись с несуществующим в главной таблице значением ключа связи;

q В главной таблице нельзя удалить запись, если не удалены связанные с ней записи в подчиненной таблице;

q Нельзя изменить значение ключа связи в записи главной таблицы, если в подчиненной таблице имеются связанные с ней записи.

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

Установление между двумя таблицами связи типа 1:М или 1:1 и задание для этой связи параметров целостности данных возможно только при следующих условиях:

q Связываемые поля имеют одинаковый тип данных;

q Обе таблицы сохраняются в одной базе данных;

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

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

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

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

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

Образовавшаяся межтабличная связь отображается в окне Схема данных в виде линии, соединяющей два поля разных таблиц. При этом на линии связи у главной таблицы отображается символ - 1 , у подчиненной таблицы символ – бесконечность (¥ ) (рис. 14).

Рис. 14. Схема данных. Связь двух таблиц по ключевому полю Код поставщика.

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

Реляционная база данных, созданная в соответствии с проектом канонической модели данных предметной области, состоит из нормализованных таблиц, связанных одно-многозначными отношениями. В такой базе данных обеспечивается отсутствие дублирования описательных данных, их однократный ввод, поддержание целостности данных средствами системы. Связи между таблицами позволяют выполнить объединение данных различных таблиц, необходимое для решения большинства задач ввода, просмотра и корректировки данных, получения информации по запросам и вывода отчетов.

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

Создание схемы данных

Создание схемы данных начинается с выполнения команды Схема данных (Relationships) в группе Отношения (Relationships) на вкладке ленты Работа с базами данных (Database Tools). В результате выполнения этой команды открывается окно схемы данных и диалоговое окно Добавление таблицы (Show Table), в котором осуществляется выбор таблиц, включаемых в схему (см. рис. 3.48). Диалоговое окно Добавление таблицы откроется автоматически, если в базе данных еще не определена ни одна связь. Если окно не открылось, на ленте Работа со связями | Конструктор (Relationship Tools | Design) в группе Связи (Relationships) нажмите кнопку Отобразить таблицу (Show Table).

Включение таблиц в схему данных

В окне Добавление таблицы (Show Table) (рис. 3.48) отображены все таблицы и запросы, содержащиеся в базе данных. Выберем вкладку Таблицы (Tables) и с помощью кнопки Добавить (Add) разместим в окне Схема данных (Relationships) все ранее созданные таблицы базы данных Поставка товаров, отображенные в окне Добавление таблицы (Show Table). Затем нажмем кнопку Закрыть (Close). В результате в окне Схема данных (Relationships) таблицы базы будут представлены окнами со списками своих полей и выделенными жирным шрифтом ключами (см. рис. 3.52).

Создание связей между таблицами схемы данных

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

Создание связей по простому ключу

Установим связь между таблицами ПОКУПАТЕЛЬ и ДОГОВОР, которые находятся в отношении «один-ко-многим». Устанавливая связи между парой таблиц, находящихся в отношении типа 1: M, выделим в главной таблице ПОКУПАТЕЛЬ ключевое поле КОД_ПОК, по которому устанавливается связь. Далее при нажатой кнопке мыши перетащим его в соответствующее поле подчиненной таблицы ДОГОВОР.

Поскольку поле связи является уникальным ключом в главной таблице связи, а в подчиненной таблице связи не является ключевым, схема данных в Access выявляет отношение «один-ко-многим» между записями этих таблиц. Значение «один-ко-многим» (One-To-Many) отобразится в окне Изменение связей (Edit Relationships) в строке Тип отношения (Relationship Type) (рис. 3.49).

ЗАМЕЧАНИЕ
Если поле связи является уникальным ключом в обеих связываемых таблицах, схема данных в Access выявляет отношение «один-к-одному «. Если для связи таблиц вместо ключевого поля главной таблицы используется некоторый уникальный индекс, система также констатирует отношение таблиц как 1: М или 1: 1.

Определение связей по составному ключу

Определим связи между таблицами НАКЛАДНАЯ ОТГРУЗКА, которые связаны по составному ключу НОМ_НАКЛ + КОД_СК. Для этого в главной таблице НАКЛАДНАЯ выделим оба этих поля, нажав клавишу , и перетащим их в подчиненную таблицу ОТГРУЗКА.

В окне Изменение связей (Edit Relationships) (рис. 3.50) для каждого поля составного ключа главной таблицы НАКЛАДНАЯ, названной Таблица/запрос (Table/Query), выберем соответствующее поле подчиненной таблицы ОТГРУЗКА, названной Связанная таблица/запрос (Related Table/Query).

Каскадное обновление и удаление связанных записей

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

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

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

Установить в окне Изменение связей (Edit Relationships) (см. рис. 3.49) флажки каскадное обновление связанных полей (Cascade Update Related Fields) и каскадное удаление связанных записей (Cascade Delete Related Records) можно только после задания параметра обеспечения целостности данных.

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

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

Вот основное, что мы хотели рассказать на тему «Схема данных в Access».

Время от времени я заглядываю на Toster.ru и иногда даже отвечаю там на вопросы. Чаще всего люди спрашивают две вещи — как стать программистом и как правильно спроектировать схему базы данных. Мне лично кажется очень странным, что так много людей задают последний вопрос. Мне почему-то всегда казалось, что это такая простая вещь, которую умеют вообще все. Но, раз так много людей интересуются, здесь я постараюсь дать достаточно развернутый и в то же время краткий ответ.

Я предполагаю, что SQL вы знаете. То есть, объяснять, что такое таблицы, строки, индексы, первичные ключи и ссылочная целостность, не требуется. Если это не так, боюсь, я вынужден отправить вас к соответствующей литературе. Благо, ее сейчас очень много.

Рисуем диаграмму

Допустим, требуется спроектировать схему базы данных, в которой хранится информация о музыкальных исполнителях, альбомах и песнях. На начальном этапе, когда у нас еще совсем ничего нет, удобно начать с рисования диаграммы будущей схемы. Можно начать с наброска ручкой на листе бумаги, можно сразу взять специализированный редактор. Их сейчас очень много , все они устроены довольно похожим образом. При подготовке этой заметки я воспользовался DbSchema . Это платная программа, но мне кажется, что она стоит своих денег. К тому же, в нормальных компаниях обычно оплачивают стоимость софта, необходимого для работы. Триал у DbSchema, если что, составляет две недели.

Нарисовать следюущую диаграмму заняло у меня порядко десяти минут:

Если раньше вам не доводилось работать с такими диаграммами, не пугайтесь, тут все просто. Прямоугольнички — это таблицы, строки в прямоугольничках — имена столбцов, стрелочками обозначаются внешние ключи, а ключиками — первичные ключи. При желании тут можно разглядеть даже индексы, типы столбцов и обязательность их заполнения (null / not null), но для нас сейчас это не так важно.

Генерируем SQL и скармливаем его СУБД

Нетрудно заметить, что данная диаграмма легко отображается в код для создания схемы базы данных на языке SQL. В DbSchema сгенерировать SQL можно, сказав Schema → Generate Schema and Data Script. Затем полученный скрипт можно скормить используемой вами СУБД:

cat music.sql | psql -hlocalhost test_database test_user

Я использовал PostgreSQL. Информацию о том, как установить эту СУБД, вы найдете в этой заметке .

Итак, чем же я руководствовался при проектировании схемы?

Нормальные формы

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

Грубо говоря, таблица находится в первой нормальной форме (1НФ), если на пересечении любой строки и любого столбца в таблице находится ровно одно значение. В современных РСУБД это условие всегда выполняется. Даже если СУБД поддерживает множества или массивы, на пересечении строки и столбца хранится ровно одно значение типа множество или массив. Но в таблице (user varchar(100), phone integer) не может быть строки alex - 1234, 5678 . В 1НФ может быть только две сроки — alex - 1234 и alex - 5678 .

Вторая нормальная форма (2НФ) означает, что таблица находится в первой нормальной форме, и каждый неключевой атрибут неприводимо зависит от значения первичного ключа. Неприводимость означает следующее. Если первичный ключ состоит из одного атрибута, то любая функциональная зависимость от него неприводима. Если первичный ключ является составным, то в таблице не может быть атрибута, значение которого однозначно определяется значением подмножества атрибутов первичного ключа.

Таблица находится в третьей нормальной форме, если она находится в 2НФ и ни один неключевой атрибут не находится в транзитивной функциональной зависимости от первичного ключа. Например, рассмотрим таблицу (employee varchar(100) primary key, department varchar(100), department_phone integer) . Очевидно, что она находится в 2НФ. Но телефон отдела находится в транзитивной функциональной зависимости от имени сотрудника, так как сотрудник однозначно задает отдел, а отдел однозначно задает телефон отдела. Для приведения таблицы в 3НФ нужно разбить ее на две таблицы — employee - department и departmnet - phone .

Легко видеть, что нормализация уменьшает избыточность базы данных и препятствует внесению случайных ошибок. Например, если оставить таблицу из последнего примера в 2НФ, то можно по ошибке прописать одному и тому же отделу разные телефоны. Или рассмотрим компанию с пятью отделами и 1000 сотрудниками. Если у отдела поменялся номер телефона, то для его обновления в базе данных в случае 2НФ потребуется просканировать 1000 строк, а в случае с 3НФ только пять.