Руководство по работе с базами данных - RukovodstvoRus.ru - инструкции пользования и руководства

О чем данный учебник

Данный учебник представляет собой что-то типа «штампа моей памяти» по языку SQL (DDL, DML), т.е. это информация, которая накопилась по ходу профессиональной деятельности и постоянно хранится в моей голове. Это для меня достаточный минимум, который применяется при работе с базами данных наиболее часто. Если встает необходимость применять более полные конструкции SQL, то я обычно обращаюсь за помощью в библиотеку MSDN расположенную в интернет. На мой взгляд, удержать все в голове очень сложно, да и нет особой необходимости в этом. Но знать основные конструкции очень полезно, т.к. они применимы практически в таком же виде во многих реляционных базах данных, таких как Oracle, MySQL, Firebird. Отличия в основном состоят в типах данных, которые могут отличаться в деталях. Основных конструкций языка SQL не так много, и при постоянной практике они быстро запоминаются. Например, для создания объектов (таблиц, ограничений, индексов и т.п.) достаточно иметь под рукой текстовый редактор среды (IDE) для работы с базой данных, и нет надобности изучать визуальный инструментарий заточенный для работы с конкретным типом баз данных (MS SQL, Oracle, MySQL, Firebird, …). Это удобно и тем, что весь текст находится перед глазами, и не нужно бегать по многочисленным вкладкам для того чтобы создать, например, индекс или ограничение. При постоянной работе с базой данных, создать, изменить, а особенно пересоздать объект при помощи скриптов получается в разы быстрее, чем если это делать в визуальном режиме. Так же в скриптовом режиме (соответственно, при должной аккуратности), проще задавать и контролировать правила наименования объектов (мое субъективное мнение). К тому же скрипты удобно использовать в случае, когда изменения, делаемые в одной базе данных (например, тестовой), необходимо перенести в таком же виде в другую базу (продуктивную).

Язык SQL подразделяется на несколько частей, здесь я рассмотрю 2 наиболее важные его части:

DDL – Data Definition Language (язык описания данных)
DML – Data Manipulation Language (язык манипулирования данными), который содержит следующие конструкции:
- SELECT – выборка данных
- INSERT – вставка новых данных
- UPDATE – обновление данных
- DELETE – удаление данных
- MERGE – слияние данных

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

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

При написании данного учебника использовалась база данных MS SQL Server версии 2014, для выполнения скриптов я использовал MS SQL Server Management Studio (SSMS).

Кратко о MS SQL Server Management Studio (SSMS)

SQL Server Management Studio (SSMS) — утилита для Microsoft SQL Server для конфигурирования, управления и администрирования компонентов базы данных. Данная утилита содержит редактор скриптов (который в основном и будет нами использоваться) и графическую программу, которая работает с объектами и настройками сервера. Главным инструментом SQL Server Management Studio является Object Explorer, который позволяет пользователю просматривать, извлекать объекты сервера, а также управлять ими. Данный текст частично позаимствован с википедии.

Для создания нового редактора скрипта используйте кнопку «New Query/Новый запрос»:

Для смены текущей базы данных можно использовать выпадающий список:

Для выполнения определенной команды (или группы команд) выделите ее и нажмите кнопку «Execute/Выполнить» или же клавишу «F5». Если в редакторе в текущий момент находится только одна команда, или же вам необходимо выполнить все команды, то ничего выделять не нужно.

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

Собственно, это все, что нам необходимо будет знать для выполнения приведенных здесь примеров. Остальное по утилите SSMS несложно изучить самостоятельно.

Немного теории

Реляционная база данных (РБД, или далее в контексте просто БД) представляет из себя совокупность таблиц, связанных между собой. Если говорить грубо, то БД – файл в котором данные хранятся в структурированном виде.

СУБД – Система Управления этими Базами Данных, т.е. это комплекс инструментов для работы с конкретным типом БД (MS SQL, Oracle, MySQL, Firebird, …).

Примечание
Т.к. в жизни, в разговорной речи, мы по большей части говорим: «БД Oracle», или даже просто «Oracle», на самом деле подразумевая «СУБД Oracle», то в контексте данного учебника иногда будет употребляться термин БД. Из контекста, я думаю, будет понятно, о чем именно идет речь.

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

Таблица – это главный объект РБД, все данные РБД хранятся построчно в столбцах таблицы. Строки, записи – тоже синонимы.

Для каждой таблицы, как и ее столбцов задаются наименования, по которым впоследствии к ним идет обращение.
Наименование объекта (имя таблицы, имя столбца, имя индекса и т.п.) в MS SQL может иметь максимальную длину 128 символов.

Для справки – в БД ORACLE наименования объектов могут иметь максимальную длину 30 символов. Поэтому для конкретной БД нужно вырабатывать свои правила для наименования объектов, чтобы уложиться в лимит по количеству символов.

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

DDL и DML — подмножество языка SQL:

Язык DDL служит для создания и модификации структуры БД, т.е. для создания/изменения/удаления таблиц и связей.
Язык DML позволяет осуществлять манипуляции с данными таблиц, т.е. с ее строками. Он позволяет делать выборку данных из таблиц, добавлять новые данные в таблицы, а так же обновлять и удалять существующие данные.

В языке SQL можно использовать 2 вида комментариев (однострочный и многострочный):

-- однострочный комментарий

/*
  многострочный
  комментарий
*/

Собственно, все для теории этого будет достаточно.

DDL – Data Definition Language (язык описания данных)

Для примера рассмотрим таблицу с данными о сотрудниках, в привычном для человека не являющимся программистом виде:

Табельный номер	ФИО	Дата рождения	E-mail	Должность	Отдел
1000	Иванов И.И.	19.02.1955	i.ivanov@test.tt	Директор	Администрация
1001	Петров П.П.	03.12.1983	p.petrov@test.tt	Программист	ИТ
1002	Сидоров С.С.	07.06.1976	s.sidorov@test.tt	Бухгалтер	Бухгалтерия
1003	Андреев А.А.	17.04.1982	a.andreev@test.tt	Старший программист	ИТ

В данном случае столбцы таблицы имеют следующие наименования: Табельный номер, ФИО, Дата рождения, E-mail, Должность, Отдел.

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

Табельный номер – целое число
ФИО – строка
Дата рождения – дата
E-mail – строка
Должность – строка
Отдел – строка

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

Для начала будет достаточно запомнить только следующие основные типы данных используемые в MS SQL:

Значение	Обозначение в MS SQL	Описание
Строка переменной длины	varchar(N) и nvarchar(N)	При помощи числа N, мы можем указать максимально возможную длину строки для соответствующего столбца. Например, если мы хотим сказать, что значение столбца «ФИО» может содержать максимум 30 символов, то необходимо задать ей тип nvarchar(30). Отличие varchar от nvarchar заключается в том, что varchar позволяет хранить строки в формате ASCII, где один символ занимает 1 байт, а nvarchar хранит строки в формате Unicode, где каждый символ занимает 2 байта. Тип varchar стоит использовать только в том случае, если вы на 100% уверены, что в данном поле не потребуется хранить Unicode символы. Например, varchar можно использовать для хранения адресов электронной почты, т.к. они обычно содержат только ASCII символы.
Строка фиксированной длины	char(N) и nchar(N)	От строки переменной длины данный тип отличается тем, что если длина строка меньше N символов, то она всегда дополняется справа до длины N пробелами и сохраняется в БД в таком виде, т.е. в базе данных она занимает ровно N символов (где один символ занимает 1 байт для char и 2 байта для типа nchar). На моей практике данный тип очень редко находит применение, а если и используется, то он используется в основном в формате char(1), т.е. когда поле определяется одним символом.
Целое число	int	Данный тип позволяет нам использовать в столбце только целые числа, как положительные, так и отрицательные. Для справки (сейчас это не так актуально для нас) – диапазон чисел который позволяет тип int от -2 147 483 648 до 2 147 483 647. Обычно это основной тип, который используется для задания идентификаторов.
Вещественное или действительное число	float	Если говорить простым языком, то это числа, в которых может присутствовать десятичная точка (запятая).
Дата	date	Если в столбце необходимо хранить только Дату, которая состоит из трех составляющих: Числа, Месяца и Года. Например, 15.02.2014 (15 февраля 2014 года). Данный тип можно использовать для столбца «Дата приема», «Дата рождения» и т.п., т.е. в тех случаях, когда нам важно зафиксировать только дату, или, когда составляющая времени нам не важна и ее можно отбросить или если она не известна.
Время	time	Данный тип можно использовать, если в столбце необходимо хранить только данные о времени, т.е. Часы, Минуты, Секунды и Миллисекунды. Например, 17:38:31.3231603 Например, ежедневное «Время отправления рейса».
Дата и время	datetime	Данный тип позволяет одновременно сохранить и Дату, и Время. Например, 15.02.2014 17:38:31.323 Для примера это может быть дата и время какого-нибудь события.
Флаг	bit	Данный тип удобно применять для хранения значений вида «Да»/«Нет», где «Да» будет сохраняться как 1, а «Нет» будет сохраняться как 0.

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

Для выполнения примеров создадим тестовую базу под названием Test.

Простую базу данных (без указания дополнительных параметров) можно создать, выполнив следующую команду:

CREATE DATABASE Test

Удалить базу данных можно командой (стоит быть очень осторожным с данной командой):

DROP DATABASE Test

Для того, чтобы переключиться на нашу базу данных, можно выполнить команду:

USE Test

Или же выберите базу данных Test в выпадающем списке в области меню SSMS. При работе мною чаще используется именно этот способ переключения между базами.

Теперь в нашей БД мы можем создать таблицу используя описания в том виде как они есть, используя пробелы и символы кириллицы:

CREATE TABLE [Сотрудники](
  [Табельный номер] int,
  [ФИО] nvarchar(30),
  [Дата рождения] date,
  [E-mail] nvarchar(30),
  [Должность] nvarchar(30),
  [Отдел] nvarchar(30)
)

В данном случае нам придется заключать имена в квадратные скобки […].

Но в базе данных для большего удобства все наименования объектов лучше задавать на латинице и не использовать в именах пробелы. В MS SQL обычно в данном случае каждое слово начинается с прописной буквы, например, для поля «Табельный номер», мы могли бы задать имя PersonnelNumber. Так же в имени можно использовать цифры, например, PhoneNumber1.

На заметку
В некоторых СУБД более предпочтительным может быть следующий формат наименований «PHONE_NUMBER», например, такой формат часто используется в БД ORACLE. Естественно при задании имя поля желательно чтобы оно не совпадало с ключевыми словами используемые в СУБД.

По этой причине можете забыть о синтаксисе с квадратными скобками и удалить таблицу [Сотрудники]:

DROP TABLE [Сотрудники]

Например, таблицу с сотрудниками можно назвать «Employees», а ее полям можно задать следующие наименования:

ID – Табельный номер (Идентификатор сотрудника)
Name – ФИО
Birthday – Дата рождения
Email – E-mail
Position – Должность
Department – Отдел

Очень часто для наименования поля идентификатора используется слово ID.

Теперь создадим нашу таблицу:

CREATE TABLE Employees(
  ID int,
  Name nvarchar(30),
  Birthday date,
  Email nvarchar(30),
  Position nvarchar(30),
  Department nvarchar(30)
)

Для того, чтобы задать обязательные для заполнения столбцы, можно использовать опцию NOT NULL.

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

-- обновление поля ID
ALTER TABLE Employees ALTER COLUMN ID int NOT NULL

-- обновление поля Name
ALTER TABLE Employees ALTER COLUMN Name nvarchar(30) NOT NULL

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

Чтобы не быть голословным, приведу несколько примеров тех же команд для СУБД ORACLE:
-- создание таблицы
CREATE TABLE Employees(
  ID int, -- в ORACLE тип int - это эквивалент(обертка) для number(38)
  Name nvarchar2(30), -- nvarchar2 в ORACLE эквивалентен nvarchar в MS SQL
  Birthday date,
  Email nvarchar2(30),
  Position nvarchar2(30),
  Department nvarchar2(30)
);

-- обновление полей ID и Name (здесь вместо ALTER COLUMN используется MODIFY(…))
ALTER TABLE Employees MODIFY(ID int NOT NULL,Name nvarchar2(30) NOT NULL);

-- добавление PK (в данном случае конструкция выглядит как и в MS SQL, она будет показана ниже)
ALTER TABLE Employees ADD CONSTRAINT PK_Employees PRIMARY KEY(ID);
Для ORACLE есть отличия в плане реализации типа varchar2, его кодировка зависит настроек БД и текст может сохраняться, например, в кодировке UTF-8. Помимо этого длину поля в ORACLE можно задать как в байтах, так и в символах, для этого используются дополнительные опции BYTE и CHAR, которые указываются после длины поля, например:
NAME varchar2(30 BYTE) -- вместимость поля будет равна 30 байтам
NAME varchar2(30 CHAR) -- вместимость поля будет равна 30 символов
Какая опция будет использоваться по умолчанию BYTE или CHAR, в случае простого указания в ORACLE типа varchar2(30), зависит от настроек БД, так же она иногда может задаваться в настройках IDE. В общем порой можно легко запутаться, поэтому в случае ORACLE, если используется тип varchar2 (а это здесь порой оправдано, например, при использовании кодировки UTF-8) я предпочитаю явно прописывать CHAR (т.к. обычно длину строки удобнее считать именно в символах).

Но в данном случае если в таблице уже есть какие-нибудь данные, то для успешного выполнения команд необходимо, чтобы во всех строках таблицы поля ID и Name были обязательно заполнены. Продемонстрируем это на примере, вставим в таблицу данные в поля ID, Position и Department, это можно сделать следующим скриптом:

INSERT Employees(ID,Position,Department) VALUES
(1000,N'Директор',N'Администрация'),
(1001,N'Программист',N'ИТ'),
(1002,N'Бухгалтер',N'Бухгалтерия'),
(1003,N'Старший программист',N'ИТ')

В данном случае, команда INSERT также выдаст ошибку, т.к. при вставке мы не указали значения обязательного поля Name.
В случае, если бы у нас в первоначальной таблице уже имелись эти данные, то команда «ALTER TABLE Employees ALTER COLUMN ID int NOT NULL» выполнилась бы успешно, а команда «ALTER TABLE Employees ALTER COLUMN Name int NOT NULL» выдала сообщение об ошибке, что в поле Name имеются NULL (не указанные) значения.

Добавим значения для полю Name и снова зальем данные:

INSERT Employees(ID,Position,Department,Name) VALUES
(1000,N'Директор',N'Администрация',N'Иванов И.И.'),
(1001,N'Программист',N'ИТ',N'Петров П.П.'),
(1002,N'Бухгалтер',N'Бухгалтерия',N'Сидоров С.С.'),
(1003,N'Старший программист',N'ИТ',N'Андреев А.А.')

Так же опцию NOT NULL можно использовать непосредственно при создании новой таблицы, т.е. в контексте команды CREATE TABLE.

Сначала удалим таблицу при помощи команды:

DROP TABLE Employees

Теперь создадим таблицу с обязательными для заполнения столбцами ID и Name:

CREATE TABLE Employees(
  ID int NOT NULL,
  Name nvarchar(30) NOT NULL,
  Birthday date,
  Email nvarchar(30),
  Position nvarchar(30),
  Department nvarchar(30)
)

Можно также после имени столбца написать NULL, что будет означать, что в нем будут допустимы NULL-значения (не указанные), но этого делать не обязательно, так как данная характеристика подразумевается по умолчанию.

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

ALTER TABLE Employees ALTER COLUMN Name nvarchar(30) NULL

Или просто:

ALTER TABLE Employees ALTER COLUMN Name nvarchar(30)

Так же данной командой мы можем изменить тип поля на другой совместимый тип, или же изменить его длину. Для примера давайте расширим поле Name до 50 символов:

ALTER TABLE Employees ALTER COLUMN Name nvarchar(50)

Первичный ключ

При создании таблицы желательно, чтобы она имела уникальный столбец или же совокупность столбцов, которая уникальна для каждой ее строки – по данному уникальному значению можно однозначно идентифицировать запись. Такое значение называется первичным ключом таблицы. Для нашей таблицы Employees таким уникальным значением может быть столбец ID (который содержит «Табельный номер сотрудника» — пускай в нашем случае данное значение уникально для каждого сотрудника и не может повторяться).

Создать первичный ключ к уже существующей таблице можно при помощи команды:

ALTER TABLE Employees ADD CONSTRAINT PK_Employees PRIMARY KEY(ID)

Где «PK_Employees» это имя ограничения, отвечающего за первичный ключ. Обычно для наименования первичного ключа используется префикс «PK_» после которого идет имя таблицы.

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

ALTER TABLE имя_таблицы ADD CONSTRAINT имя_ограничения PRIMARY KEY(поле1,поле2,…)

Стоит отметить, что в MS SQL все поля, которые входят в первичный ключ, должны иметь характеристику NOT NULL.

Так же первичный ключ можно определить непосредственно при создании таблицы, т.е. в контексте команды CREATE TABLE. Удалим таблицу:

DROP TABLE Employees

А затем создадим ее, используя следующий синтаксис:

CREATE TABLE Employees(
  ID int NOT NULL,
  Name nvarchar(30) NOT NULL,
  Birthday date,
  Email nvarchar(30),
  Position nvarchar(30),
  Department nvarchar(30),
  CONSTRAINT PK_Employees PRIMARY KEY(ID) -- описываем PK после всех полей, как ограничение
)

После создания зальем в таблицу данные:

INSERT Employees(ID,Position,Department,Name) VALUES
(1000,N'Директор',N'Администрация',N'Иванов И.И.'),
(1001,N'Программист',N'ИТ',N'Петров П.П.'),
(1002,N'Бухгалтер',N'Бухгалтерия',N'Сидоров С.С.'),
(1003,N'Старший программист',N'ИТ',N'Андреев А.А.')

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

CREATE TABLE Employees(
  ID int NOT NULL CONSTRAINT PK_Employees PRIMARY KEY, -- указываем как характеристику поля
  Name nvarchar(30) NOT NULL,
  Birthday date,
  Email nvarchar(30),
  Position nvarchar(30),
  Department nvarchar(30)
)

На самом деле имя ограничения можно и не задавать, в этом случае ему будет присвоено системное имя (наподобие «PK__Employee__3214EC278DA42077»):

CREATE TABLE Employees(
  ID int NOT NULL,
  Name nvarchar(30) NOT NULL,
  Birthday date,
  Email nvarchar(30),
  Position nvarchar(30),
  Department nvarchar(30),
  PRIMARY KEY(ID)
)

Или:

CREATE TABLE Employees(
  ID int NOT NULL PRIMARY KEY,
  Name nvarchar(30) NOT NULL,
  Birthday date,
  Email nvarchar(30),
  Position nvarchar(30),
  Department nvarchar(30)
)

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

ALTER TABLE Employees DROP CONSTRAINT PK_Employees

Но такой краткий синтаксис, без указания имен ограничений, удобно применять при создании временных таблиц БД (имя временной таблицы начинается с # или ##), которые после использования будут удалены.

Подытожим

На данный момент мы рассмотрели следующие команды:

CREATE TABLE имя_таблицы (перечисление полей и их типов, ограничений) – служит для создания новой таблицы в текущей БД;
DROP TABLE имя_таблицы – служит для удаления таблицы из текущей БД;
ALTER TABLE имя_таблицы ALTER COLUMN имя_столбца … – служит для обновления типа столбца или для изменения его настроек (например для задания характеристики NULL или NOT NULL);
ALTER TABLE имя_таблицы ADD CONSTRAINT имя_ограничения PRIMARY KEY(поле1, поле2,…) – добавление первичного ключа к уже существующей таблице;
ALTER TABLE имя_таблицы DROP CONSTRAINT имя_ограничения – удаление ограничения из таблицы.

Немного про временные таблицы

Вырезка из MSDN. В MS SQL Server существует два вида временных таблиц: локальные (#) и глобальные (##). Локальные временные таблицы видны только их создателям до завершения сеанса соединения с экземпляром SQL Server, как только они впервые созданы. Локальные временные таблицы автоматически удаляются после отключения пользователя от экземпляра SQL Server. Глобальные временные таблицы видны всем пользователям в течение любых сеансов соединения после создания этих таблиц и удаляются, когда все пользователи, ссылающиеся на эти таблицы, отключаются от экземпляра SQL Server.

Временные таблицы создаются в системной базе tempdb, т.е. создавая их мы не засоряем основную базу, в остальном же временные таблицы полностью идентичны обычным таблицам, их так же можно удалить при помощи команды DROP TABLE. Чаще используются локальные (#) временные таблицы.

Для создания временной таблицы можно использовать команду CREATE TABLE:

CREATE TABLE #Temp(
  ID int,
  Name nvarchar(30)
)

Так как временная таблица в MS SQL аналогична обычной таблице, ее соответственно так же можно удалить самому командой DROP TABLE:

DROP TABLE #Temp

Так же временную таблицу (как собственно и обычную таблицу) можно создать и сразу заполнить данными возвращаемые запросом используя синтаксис SELECT … INTO:

SELECT ID,Name
INTO #Temp
FROM Employees

На заметку
В разных СУБД реализация временных таблиц может отличаться. Например, в СУБД ORACLE и Firebird структура временных таблиц должна быть определена заранее командой CREATE GLOBAL TEMPORARY TABLE с указанием специфики хранения в ней данных, дальше уже пользователь видит ее среди основных таблиц и работает с ней как с обычной таблицей.

Нормализация БД – дробление на подтаблицы (справочники) и определение связей

Наша текущая таблица Employees имеет недостаток в том, что в полях Position и Department пользователь может ввести любой текст, что в первую очередь чревато ошибками, так как он у одного сотрудника может указать в качестве отдела просто «ИТ», а у второго сотрудника, например, ввести «ИТ-отдел», у третьего «IT». В итоге будет непонятно, что имел ввиду пользователь, т.е. являются ли данные сотрудники работниками одного отдела, или же пользователь описался и это 3 разных отдела? А тем более, в этом случае, мы не сможем правильно сгруппировать данные для какого-то отчета, где, может требоваться показать количество сотрудников в разрезе каждого отдела.

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

Третий недостаток – сложность обновления данных полей, в случае если изменится название какой-то должности, например, если потребуется переименовать должность «Программист», на «Младший программист». В данном случае нам придется вносить изменения в каждую строчку таблицы, у которой Должность равняется «Программист».

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

Давайте создадим 2 таблицы справочники «Должности» и «Отделы», первую назовем Positions, а вторую соответственно Departments:

CREATE TABLE Positions(
  ID int IDENTITY(1,1) NOT NULL CONSTRAINT PK_Positions PRIMARY KEY,
  Name nvarchar(30) NOT NULL
)

CREATE TABLE Departments(
  ID int IDENTITY(1,1) NOT NULL CONSTRAINT PK_Departments PRIMARY KEY,
  Name nvarchar(30) NOT NULL
)

Заметим, что здесь мы использовали новую опцию IDENTITY, которая говорит о том, что данные в столбце ID будут нумероваться автоматически, начиная с 1, с шагом 1, т.е. при добавлении новых записей им последовательно будут присваиваться значения 1, 2, 3, и т.д. Такие поля обычно называют автоинкрементными. В таблице может быть определено только одно поле со свойством IDENTITY и обычно, но необязательно, такое поле является первичным ключом для данной таблицы.

На заметку
В разных СУБД реализация полей со счетчиком может делаться по своему. В MySQL, например, такое поле определяется при помощи опции AUTO_INCREMENT. В ORACLE и Firebird раньше данную функциональность можно было съэмулировать при помощи использования последовательностей (SEQUENCE). Но насколько я знаю в ORACLE сейчас добавили опцию GENERATED AS IDENTITY.

Давайте заполним эти таблицы автоматически, на основании текущих данных записанных в полях Position и Department таблицы Employees:

-- заполняем поле Name таблицы Positions, уникальными значениями из поля Position таблицы Employees
INSERT Positions(Name)
SELECT DISTINCT Position
FROM Employees
WHERE Position IS NOT NULL -- отбрасываем записи у которых позиция не указана

То же самое проделаем для таблицы Departments:

INSERT Departments(Name)
SELECT DISTINCT Department
FROM Employees
WHERE Department IS NOT NULL

Если теперь мы откроем таблицы Positions и Departments, то увидим пронумерованный набор значений по полю ID:

SELECT * FROM Positions

ID	Name
1	Бухгалтер
2	Директор
3	Программист
4	Старший программист

SELECT * FROM Departments

ID	Name
1	Администрация
2	Бухгалтерия
3	ИТ

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

-- добавляем поле для ID должности
ALTER TABLE Employees ADD PositionID int
-- добавляем поле для ID отдела
ALTER TABLE Employees ADD DepartmentID int

Тип ссылочных полей должен быть каким же, как и в справочниках, в данном случае это int.

Так же добавить в таблицу сразу несколько полей можно одной командой, перечислив поля через запятую:

ALTER TABLE Employees ADD PositionID int, DepartmentID int

Теперь пропишем ссылки (ссылочные ограничения — FOREIGN KEY) для этих полей, для того чтобы пользователь не имел возможности записать в данные поля, значения, отсутствующие среди значений ID находящихся в справочниках.

ALTER TABLE Employees ADD CONSTRAINT FK_Employees_PositionID
FOREIGN KEY(PositionID) REFERENCES Positions(ID)

И то же самое сделаем для второго поля:

ALTER TABLE Employees ADD CONSTRAINT FK_Employees_DepartmentID
FOREIGN KEY(DepartmentID) REFERENCES Departments(ID)

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

Имя ссылочного ограничения, обычно является составным, оно состоит из префикса «FK_», затем идет имя таблицы и после знака подчеркивания идет имя поля, которое ссылается на идентификатор таблицы-справочника.

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

Так же в некоторых случаях ссылку можно организовать по нескольким полям:

ALTER TABLE таблица ADD CONSTRAINT имя_ограничения
FOREIGN KEY(поле1,поле2,…) REFERENCES таблица_справочник(поле1,поле2,…)

В данном случае в таблице «таблица_справочник» первичный ключ представлен комбинацией из нескольких полей (поле1, поле2,…).

Собственно, теперь обновим поля PositionID и DepartmentID значениями ID из справочников. Воспользуемся для этой цели DML командой UPDATE:

UPDATE e
SET
  PositionID=(SELECT ID FROM Positions WHERE Name=e.Position),
  DepartmentID=(SELECT ID FROM Departments WHERE Name=e.Department)
FROM Employees e

Посмотрим, что получилось, выполнив запрос:

SELECT * FROM Employees

ID	Name	Birthday	Email	Position	Department	PositionID	DepartmentID
1000	Иванов И.И.	NULL	NULL	Директор	Администрация	2	1
1001	Петров П.П.	NULL	NULL	Программист	ИТ	3	3
1002	Сидоров С.С.	NULL	NULL	Бухгалтер	Бухгалтерия	1	2
1003	Андреев А.А.	NULL	NULL	Старший программист	ИТ	4	3

Всё, поля PositionID и DepartmentID заполнены соответствующие должностям и отделам идентификаторами надобности в полях Position и Department в таблице Employees теперь нет, можно удалить эти поля:

ALTER TABLE Employees DROP COLUMN Position,Department

Теперь таблица у нас приобрела следующий вид:

SELECT * FROM Employees

ID	Name	Birthday	Email	PositionID	DepartmentID
1000	Иванов И.И.	NULL	NULL	2	1
1001	Петров П.П.	NULL	NULL	3	3
1002	Сидоров С.С.	NULL	NULL	1	2
1003	Андреев А.А.	NULL	NULL	4	3

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

SELECT e.ID,e.Name,p.Name PositionName,d.Name DepartmentName
FROM Employees e
LEFT JOIN Departments d ON d.ID=e.DepartmentID
LEFT JOIN Positions p ON p.ID=e.PositionID

ID	Name	PositionName	DepartmentName
1000	Иванов И.И.	Директор	Администрация
1001	Петров П.П.	Программист	ИТ
1002	Сидоров С.С.	Бухгалтер	Бухгалтерия
1003	Андреев А.А.	Старший программист	ИТ

В инспекторе объектов мы можем увидеть все объекты, созданные для в данной таблицы. Отсюда же можно производить разные манипуляции с данными объектами – например, переименовывать или удалять объекты.

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

ALTER TABLE Employees ADD ManagerID int

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

Теперь создадим FOREIGN KEY на таблицу Employees:

ALTER TABLE Employees ADD CONSTRAINT FK_Employees_ManagerID
FOREIGN KEY (ManagerID) REFERENCES Employees(ID)

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

В результате мы должны увидеть следующую картину (таблица Employees связана с таблицами Positions и Depertments, а так же ссылается сама на себя):

Напоследок стоит сказать, что ссылочные ключи могут включать дополнительные опции ON DELETE CASCADE и ON UPDATE CASCADE, которые говорят о том, как вести себя при удалении или обновлении записи, на которую есть ссылки в таблице-справочнике. Если эти опции не указаны, то мы не можем изменить ID в таблице справочнике у той записи, на которую есть ссылки из другой таблицы, так же мы не сможем удалить такую запись из справочника, пока не удалим все строки, ссылающиеся на эту запись или, же обновим в этих строках ссылки на другое значение.

Для примера пересоздадим таблицу с указанием опции ON DELETE CASCADE для FK_Employees_DepartmentID:

DROP TABLE Employees

CREATE TABLE Employees(
  ID int NOT NULL,
  Name nvarchar(30),
  Birthday date,
  Email nvarchar(30),
  PositionID int,
  DepartmentID int,
  ManagerID int,
CONSTRAINT PK_Employees PRIMARY KEY (ID),
CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY(DepartmentID) REFERENCES Departments(ID)
ON DELETE CASCADE,
CONSTRAINT FK_Employees_PositionID FOREIGN KEY(PositionID) REFERENCES Positions(ID),
CONSTRAINT FK_Employees_ManagerID FOREIGN KEY (ManagerID) REFERENCES Employees(ID)
)

INSERT Employees (ID,Name,Birthday,PositionID,DepartmentID,ManagerID)VALUES
(1000,N'Иванов И.И.','19550219',2,1,NULL),
(1001,N'Петров П.П.','19831203',3,3,1003),
(1002,N'Сидоров С.С.','19760607',1,2,1000),
(1003,N'Андреев А.А.','19820417',4,3,1000)

Удалим отдел с идентификатором 3 из таблицы Departments:

DELETE Departments WHERE ID=3

Посмотрим на данные таблицы Employees:

SELECT * FROM Employees

ID	Name	Birthday	Email	PositionID	DepartmentID	ManagerID
1000	Иванов И.И.	1955-02-19	NULL	2	1	NULL
1002	Сидоров С.С.	1976-06-07	NULL	1	2	1000

Как видим, данные по отделу 3 из таблицы Employees так же удалились.

Опция ON UPDATE CASCADE ведет себя аналогично, но действует она при обновлении значения ID в справочнике. Например, если мы поменяем ID должности в справочнике должностей, то в этом случае будет производиться обновление DepartmentID в таблице Employees на новое значение ID которое мы задали в справочнике. Но в данном случае это продемонстрировать просто не получится, т.к. у колонки ID в таблице Departments стоит опция IDENTITY, которая не позволит нам выполнить следующий запрос (сменить идентификатор отдела 3 на 30):

UPDATE Departments
SET
  ID=30
WHERE ID=3

Главное понять суть этих 2-х опций ON DELETE CASCADE и ON UPDATE CASCADE. Я применяю эти опции очень в редких случаях и рекомендую хорошо подумать, прежде чем указывать их в ссылочном ограничении, т.к. при нечаянном удалении записи из таблицы справочника это может привести к большим проблемам и создать цепную реакцию.

Восстановим отдел 3:

-- даем разрешение на добавление/изменение IDENTITY значения
SET IDENTITY_INSERT Departments ON

INSERT Departments(ID,Name) VALUES(3,N'ИТ')

-- запрещаем добавление/изменение IDENTITY значения
SET IDENTITY_INSERT Departments OFF

Полностью очистим таблицу Employees при помощи команды TRUNCATE TABLE:

TRUNCATE TABLE Employees

И снова перезальем в нее данные используя предыдущую команду INSERT:

INSERT Employees (ID,Name,Birthday,PositionID,DepartmentID,ManagerID)VALUES
(1000,N'Иванов И.И.','19550219',2,1,NULL),
(1001,N'Петров П.П.','19831203',3,3,1003),
(1002,N'Сидоров С.С.','19760607',1,2,1000),
(1003,N'Андреев А.А.','19820417',4,3,1000)

Подытожим

На данным момент к нашим знаниям добавилось еще несколько команд DDL:

Добавление свойства IDENTITY к полю – позволяет сделать это поле автоматически заполняемым (полем-счетчиком) для таблицы;
ALTER TABLE имя_таблицы ADD перечень_полей_с_характеристиками – позволяет добавить новые поля в таблицу;
ALTER TABLE имя_таблицы DROP COLUMN перечень_полей – позволяет удалить поля из таблицы;
ALTER TABLE имя_таблицы ADD CONSTRAINT имя_ограничения FOREIGN KEY(поля) REFERENCES таблица_справочник(поля) – позволяет определить связь между таблицей и таблицей справочником.

Прочие ограничения – UNIQUE, DEFAULT, CHECK

При помощи ограничения UNIQUE можно сказать что значения для каждой строки в данном поле или в наборе полей должно быть уникальным. В случае таблицы Employees, такое ограничение мы можем наложить на поле Email. Только предварительно заполним Email значениями, если они еще не определены:

UPDATE Employees SET Email='i.ivanov@test.tt' WHERE ID=1000
UPDATE Employees SET Email='p.petrov@test.tt' WHERE ID=1001
UPDATE Employees SET Email='s.sidorov@test.tt' WHERE ID=1002
UPDATE Employees SET Email='a.andreev@test.tt' WHERE ID=1003

А теперь можно наложить на это поле ограничение-уникальности:

ALTER TABLE Employees ADD CONSTRAINT UQ_Employees_Email UNIQUE(Email)

Теперь пользователь не сможет внести один и тот же E-Mail у нескольких сотрудников.

Ограничение уникальности обычно именуется следующим образом – сначала идет префикс «UQ_», далее название таблицы и после знака подчеркивания идет имя поля, на которое накладывается данное ограничение.

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

ALTER TABLE имя_таблицы ADD CONSTRAINT имя_ограничения UNIQUE(поле1,поле2,…)

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

Давайте добавим в таблицу Employees новое поле «Дата приема» и назовем его HireDate и скажем что значение по умолчанию у данного поля будет текущая дата:

ALTER TABLE Employees ADD HireDate date NOT NULL DEFAULT SYSDATETIME()

Или если столбец HireDate уже существует, то можно использовать следующий синтаксис:

ALTER TABLE Employees ADD DEFAULT SYSDATETIME() FOR HireDate

Здесь я не указал имя ограничения, т.к. в случае DEFAULT у меня сложилось мнение, что это не столь критично. Но если делать по-хорошему, то, думаю, не нужно лениться и стоит задать нормальное имя. Делается это следующим образом:

ALTER TABLE Employees ADD CONSTRAINT DF_Employees_HireDate DEFAULT SYSDATETIME() FOR HireDate

Та как данного столбца раньше не было, то при его добавлении в каждую запись в поле HireDate будет вставлено текущее значение даты.

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

INSERT Employees(ID,Name,Email)VALUES(1004,N'Сергеев С.С.','s.sergeev@test.tt')

Посмотрим, что получилось:

SELECT * FROM Employees

ID	Name	Birthday	Email	PositionID	DepartmentID	ManagerID	HireDate
1000	Иванов И.И.	1955-02-19	i.ivanov@test.tt	2	1	NULL	2015-04-08
1001	Петров П.П.	1983-12-03	p.petrov@test.tt	3	4	1003	2015-04-08
1002	Сидоров С.С.	1976-06-07	s.sidorov@test.tt	1	2	1000	2015-04-08
1003	Андреев А.А.	1982-04-17	a.andreev@test.tt	4	3	1000	2015-04-08
1004	Сергеев С.С.	NULL	s.sergeev@test.tt	NULL	NULL	NULL	2015-04-08

Проверочное ограничение CHECK используется в том случае, когда необходимо осуществить проверку вставляемых в поле значений. Например, наложим данное ограничение на поле табельный номер, которое у нас является идентификатором сотрудника (ID). При помощи данного ограничения скажем, что табельные номера должны иметь значение от 1000 до 1999:

ALTER TABLE Employees ADD CONSTRAINT CK_Employees_ID CHECK(ID BETWEEN 1000 AND 1999)

Ограничение обычно именуется так же, сначала идет префикс «CK_», затем имя таблицы и имя поля, на которое наложено это ограничение.

Попробуем вставить недопустимую запись для проверки, что ограничение работает (мы должны получить соответствующую ошибку):

INSERT Employees(ID,Email) VALUES(2000,'test@test.tt')

А теперь изменим вставляемое значение на 1500 и убедимся, что запись вставится:

INSERT Employees(ID,Email) VALUES(1500,'test@test.tt')

Можно так же создать ограничения UNIQUE и CHECK без указания имени:

ALTER TABLE Employees ADD UNIQUE(Email)
ALTER TABLE Employees ADD CHECK(ID BETWEEN 1000 AND 1999)

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

При хорошем наименовании много информации об ограничении можно узнать непосредственно по его имени.

И, соответственно, все эти ограничения можно создать сразу же при создании таблицы, если ее еще нет. Удалим таблицу:

DROP TABLE Employees

И пересоздадим ее со всеми созданными ограничениями одной командой CREATE TABLE:

CREATE TABLE Employees(
  ID int NOT NULL,
  Name nvarchar(30),
  Birthday date,
  Email nvarchar(30),
  PositionID int,
  DepartmentID int,
  HireDate date NOT NULL DEFAULT SYSDATETIME(), -- для DEFAULT я сделаю исключение
CONSTRAINT PK_Employees PRIMARY KEY (ID),
CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY(DepartmentID) REFERENCES Departments(ID),
CONSTRAINT FK_Employees_PositionID FOREIGN KEY(PositionID) REFERENCES Positions(ID),
CONSTRAINT UQ_Employees_Email UNIQUE (Email),
CONSTRAINT CK_Employees_ID CHECK (ID BETWEEN 1000 AND 1999)
)

Напоследок вставим в таблицу наших сотрудников:

INSERT Employees (ID,Name,Birthday,Email,PositionID,DepartmentID)VALUES
(1000,N'Иванов И.И.','19550219','i.ivanov@test.tt',2,1),
(1001,N'Петров П.П.','19831203','p.petrov@test.tt',3,3),
(1002,N'Сидоров С.С.','19760607','s.sidorov@test.tt',1,2),
(1003,N'Андреев А.А.','19820417','a.andreev@test.tt',4,3)

Немного про индексы, создаваемые при создании ограничений PRIMARY KEY и UNIQUE

Как можно увидеть на скриншоте выше, при создании ограничений PRIMARY KEY и UNIQUE автоматически создались индексы с такими же названиями (PK_Employees и UQ_Employees_Email). По умолчанию индекс для первичного ключа создается как CLUSTERED, а для всех остальных индексов как NONCLUSTERED. Стоит сказать, что понятие кластерного индекса есть не во всех СУБД. Таблица может иметь только один кластерный (CLUSTERED) индекс. CLUSTERED – означает, что записи таблицы будут сортироваться по этому индексу, так же можно сказать, что этот индекс имеет непосредственный доступ ко всем данным таблицы. Это так сказать главный индекс таблицы. Если сказать еще грубее, то это индекс, прикрученный к таблице. Кластерный индекс – это очень мощное средство, которое может помочь при оптимизации запросов, пока просто запомним это. Если мы хотим сказать, чтобы кластерный индекс использовался не в первичном ключе, а для другого индекса, то при создании первичного ключа мы должны указать опцию NONCLUSTERED:

ALTER TABLE имя_таблицы ADD CONSTRAINT имя_ограничения
PRIMARY KEY NONCLUSTERED(поле1,поле2,…)

Для примера сделаем индекс ограничения PK_Employees некластерным, а индекс ограничения UQ_Employees_Email кластерным. Первым делом удалим данные ограничения:

ALTER TABLE Employees DROP CONSTRAINT PK_Employees
ALTER TABLE Employees DROP CONSTRAINT UQ_Employees_Email

А теперь создадим их с опциями CLUSTERED и NONCLUSTERED:

ALTER TABLE Employees ADD CONSTRAINT PK_Employees PRIMARY KEY NONCLUSTERED (ID)
ALTER TABLE Employees ADD CONSTRAINT UQ_Employees_Email UNIQUE CLUSTERED (Email)

Теперь, выполнив выборку из таблицы Employees, мы увидим, что записи отсортировались по кластерному индексу UQ_Employees_Email:

SELECT * FROM Employees

ID	Name	Birthday	Email	PositionID	DepartmentID	HireDate
1003	Андреев А.А.	1982-04-17	a.andreev@test.tt	4	3	2015-04-08
1000	Иванов И.И.	1955-02-19	i.ivanov@test.tt	2	1	2015-04-08
1001	Петров П.П.	1983-12-03	p.petrov@test.tt	3	3	2015-04-08
1002	Сидоров С.С.	1976-06-07	s.sidorov@test.tt	1	2	2015-04-08

До этого, когда кластерным индексом был индекс PK_Employees, записи по умолчанию сортировались по полю ID.

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

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

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

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

Подытожим

На данном этапе мы познакомились со всеми видами ограничений, в их самом простом виде, которые создаются командой вида «ALTER TABLE имя_таблицы ADD CONSTRAINT имя_ограничения …»:

PRIMARY KEY – первичный ключ;
FOREIGN KEY – настройка связей и контроль ссылочной целостности данных;
UNIQUE – позволяет создать уникальность;
CHECK – позволяет осуществлять корректность введенных данных;
DEFAULT – позволяет задать значение по умолчанию;
Так же стоит отметить, что все ограничения можно удалить, используя команду «ALTER TABLE имя_таблицы DROP CONSTRAINT имя_ограничения».

Так же мы частично затронули тему индексов и разобрали понятие кластерный (CLUSTERED) и некластерный (NONCLUSTERED) индекс.

Создание самостоятельных индексов

Под самостоятельностью здесь имеются в виду индексы, которые создаются не для ограничения PRIMARY KEY или UNIQUE.

Индексы по полю или полям можно создавать следующей командой:

CREATE INDEX IDX_Employees_Name ON Employees(Name)

Так же здесь можно указать опции CLUSTERED, NONCLUSTERED, UNIQUE, а так же можно указать направление сортировки каждого отдельного поля ASC (по умолчанию) или DESC:

CREATE UNIQUE NONCLUSTERED INDEX UQ_Employees_EmailDesc ON Employees(Email DESC)

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

Удалить индекс можно следующей командой:

DROP INDEX IDX_Employees_Name ON Employees

Простые индексы так же, как и ограничения, можно создать в контексте команды CREATE TABLE.

Для примера снова удалим таблицу:

DROP TABLE Employees

И пересоздадим ее со всеми созданными ограничениями и индексами одной командой CREATE TABLE:

CREATE TABLE Employees(
  ID int NOT NULL,
  Name nvarchar(30),
  Birthday date,
  Email nvarchar(30),
  PositionID int,
  DepartmentID int,
  HireDate date NOT NULL CONSTRAINT DF_Employees_HireDate DEFAULT SYSDATETIME(),
  ManagerID int,
CONSTRAINT PK_Employees PRIMARY KEY (ID),
CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY(DepartmentID) REFERENCES Departments(ID),
CONSTRAINT FK_Employees_PositionID FOREIGN KEY(PositionID) REFERENCES Positions(ID),
CONSTRAINT FK_Employees_ManagerID FOREIGN KEY (ManagerID) REFERENCES Employees(ID),
CONSTRAINT UQ_Employees_Email UNIQUE(Email),
CONSTRAINT CK_Employees_ID CHECK(ID BETWEEN 1000 AND 1999),
INDEX IDX_Employees_Name(Name)
)

Напоследок вставим в таблицу наших сотрудников:

INSERT Employees (ID,Name,Birthday,Email,PositionID,DepartmentID,ManagerID)VALUES
(1000,N'Иванов И.И.','19550219','i.ivanov@test.tt',2,1,NULL),
(1001,N'Петров П.П.','19831203','p.petrov@test.tt',3,3,1003),
(1002,N'Сидоров С.С.','19760607','s.sidorov@test.tt',1,2,1000),
(1003,N'Андреев А.А.','19820417','a.andreev@test.tt',4,3,1000)

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

Вырезка из MSDN. Общий синтаксис команды для создания индексов
CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX index_name 
    ON <object> ( column [ ASC | DESC ] [ ,...n ] ) 
    [ INCLUDE ( column_name [ ,...n ] ) ]

Подытожим

Индексы могут повысить скорость выборки данных (SELECT), но индексы уменьшают скорость модификации данных таблицы, т.к. после каждой модификации системе будет необходимо перестроить все индексы для конкретной таблицы.

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

Заключение по DDL

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

Главное — понять суть, а остальное дело практики.

Удачи вам в освоении этого замечательного языка под названием SQL.

Часть вторая — habrahabr.ru/post/255523

Источник

Установка

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

Первый шаг – установить SQL

Мы будем использовать PostgreSQL (Postgres) – достаточно распространенный SQL диалект. Для этого откроем страницу загрузки, выберем операционную систему (в моем случае Windows), и запустим установку. Если вы установите пароль для вашей базы данных, постарайтесь сразу не забыть его, он нам дальше понадобится. Поскольку наша база будет локальной, можете использовать простой пароль, например: admin.

Следующий шаг – установка pgAdmin

pgAdmin – это графический интерфейс пользователя (GUI – graphical user interface), который упрощает взаимодействие с базой данных PostgreSQL. Перейдите на страницу загрузки, выберите вашу операционную систему и следуйте указаниям (в статье используется Postgres 14 и pgAdmin 4 v6.3.).

После установки обоих компонентов открываем pgAdmin и нажимаем Add new server. На этом шаге установится соединение с существующим сервером, именно поэтому необходимо сначала установить Postgres. Я назвал свой сервер home и использовал пароль, указанный при установке.

Теперь всё готово к созданию таблиц. Давайте создадим набор таблиц, которые моделируют школу. Нам необходимы таблицы: ученики, классы, оценки. При создании модели данных необходимо учитывать, что в одном классе может быть много учеников, а у ученика может быть много оценок (такое отношение называется «один ко многим»).

Мы можем создать таблицы напрямую в pgAdmin, но вместо этого мы напишем код, который можно будет использовать в дальнейшем, например, для пересоздания таблиц. Для создания запроса, который создаст наши таблицы, нажимаем правой кнопкой мыши на postgres (пункт расположен в меню слева home → Databases (1) → postgres и далее выбираем Query Tool.

Начнем с создания таблицы классов (classrooms). Таблица будет простой: она будет содержать идентификатор id и имя учителя – teacher. Напишите следующий код в окне запроса (query tool) и запустите (run или F5).

        DROP TABLE IF EXISTS classrooms CASCADE;

CREATE TABLE classrooms (
    id INT PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
    teacher VARCHAR(100)
);

В первой строке фрагмент DROP TABLE IF EXISTS classrooms удалит таблицу classrooms, если она уже существует. Важно учитывать, что Postgres, не позволит нам удалить таблицу, если она имеет связи с другими таблицами, поэтому, чтобы обойти это ограничение (constraint) в конце строки добавлен оператор CASCADE. CASCADE – автоматически удалит или изменит строки из зависимой таблицы, при внесении изменений в главную. В нашем случае нет ничего страшного в удалении таблицы, поскольку, если мы на это пошли, значит мы будем пересоздавать всё с нуля, и остальные таблицы тоже удалятся.

Добавление DROP TABLE IF EXISTS перед CREATE TABLE позволит нам систематизировать схему нашей базы данных и создать скрипты, которые будут очень удобны, если мы захотим внести изменения – например, добавить таблицу, изменить тип данных поля и т. д. Для этого нам просто нужно будет внести изменения в уже готовый скрипт и перезапустить его.

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

Также вы могли обратить внимание на четвертую строчку. Здесь мы определили, что колонка id является первичным ключом (primary key), что означает следующее: в каждой записи в таблице это поле должно быть заполнено и каждое значение должно быть уникальным. Чтобы не пришлось постоянно держать в голове, какое значение id уже было использовано, а какое – нет, мы написали GENERATED ALWAYS AS IDENTITY, этот приём является альтернативой синтаксису последовательности (CREATE SEQUENCE). В результате при добавлении записей в эту таблицу нам нужно будет просто добавить имя учителя.

И в пятой строке мы определили, что поле teacher имеет тип данных VARCHAR (строка) с максимальной длиной 100 символов. Если в будущем нам понадобится добавить в таблицу учителя с более длинным именем, нам придется либо использовать инициалы, либо изменять таблицу (alter table).

Теперь давайте создадим таблицу учеников (students). Новая таблица будет содержать: уникальный идентификатор (id), имя ученика (name), и внешний ключ (foreign key), который будет указывать (references) на таблицу классов.

        DROP TABLE IF EXISTS students CASCADE;

CREATE TABLE students (
    id INT PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
    name VARCHAR(100),
    classroom_id INT,
    CONSTRAINT fk_classrooms
        FOREIGN KEY(classroom_id)
        REFERENCES classrooms(id)
);

И снова мы перед созданием новой таблицы удаляем старую, если она существует, добавляем поле id, которое автоматически увеличивает своё значение и имя с типом данных VARCHAR (строка) и максимальной длиной 100 символов. Также в эту таблицу мы добавили колонку с идентификатором класса (classroom_id), и с седьмой по девятую строку установили, что ее значение указывает на колонку id в таблице классов (classrooms).

Мы определили, что classroom_id является внешним ключом. Это означает, что мы задали правила, по которым данные будут записываться в таблицу учеников (students). То есть Postgres на данном этапе не позволит нам вставить строку с данными в таблицу учеников (students), в которой указан идентификатор класса (classroom_id), не существующий в таблице classrooms. Например: у нас в таблице классов 10 записей (id с 1 до 10), система не даст нам вставить данные в таблицу учеников, у которых указан идентификатор класса 11 и больше.

Невозможно вставить данные, поскольку в таблице классов нет записи с id = 1

        INSERT INTO students
    (name, classroom_id)
VALUES
    ('Matt', 1);

/*
ERROR: insert or update on table "students" violates foreign
    key constraint "fk_classrooms"
DETAIL: Key (classroom_id)=(1) is not present in table
    "classrooms".
SQL state: 23503
*/

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

        INSERT INTO classrooms
    (teacher)
VALUES
    ('Mary'),
    ('Jonah');

SELECT * FROM classrooms;

/*
 id | teacher
 -- | -------
  1 | Mary
  2 | Jonah
*/

Прекрасно! Теперь у нас есть записи в таблице классов, и мы можем добавить данные в таблицу учеников, а также установить нужные связи (с таблицей классов).

        INSERT INTO students
    (name, classroom_id)
 VALUES
    ('Adam', 1),
    ('Betty', 1),
    ('Caroline', 2);

SELECT * FROM students;

/*
 id | name     | classroom_id
 -- | -------- | ------------
  1 | Adam     |            1
  2 | Betty    |            1
  3 | Caroline |            2
*/

Но что же случится, если у нас появится новый ученик, которому ещё не назначили класс? Неужели нам придется ждать, пока станет известно в каком он классе, и только после этого добавить его запись в базу данных?

Конечно же, нет. Мы установили внешний ключ, и он будет блокировать запись, поскольку ссылка на несуществующий id класса невозможна, но мы можем в качестве идентификатора класса (classroom_id) передать null. Это можно сделать двумя способами: указанием null при записи значений, либо просто передачей только имени.

        -- явно определим значение NULL
INSERT INTO students
    (name, classroom_id)
VALUES
    ('Dina', NULL);

-- неявно определим значение NULL
INSERT INTO students
    (name)
VALUES
    ('Evan');

SELECT * FROM students;

/*
 id | name     | classroom_id
 -- | -------- | ------------
  1 | Adam     |            1
  2 | Betty    |            1
  3 | Caroline |            2
  4 | Dina     |       [null]
  5 | Evan     |       [null]
*/

И наконец, давайте заполним таблицу успеваемости. Этот параметр, как правило, формируется из нескольких составляющих – домашние задания, участие в проектах, посещаемость и экзамены. Мы будем использовать две таблицы. Таблица заданий (assignments), как понятно из названия, будет содержать данные о самих заданиях, и таблица оценок (grades), в которой мы будем хранить данные о том, как ученик выполнил эти задания.

        DROP TABLE IF EXISTS assignments CASCADE;
DROP TABLE IF EXISTS grades CASCADE;

CREATE TABLE assignments (
    id INT PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
    category VARCHAR(20),
    name VARCHAR(200),
    due_date DATE,
    weight FLOAT
);

CREATE TABLE grades (
    id INT PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
    assignment_id INT,
    score INT,
    student_id INT,
    CONSTRAINT fk_assignments
        FOREIGN KEY(assignment_id)
        REFERENCES assignments(id),
    CONSTRAINT fk_students
        FOREIGN KEY(student_id)
        REFERENCES students(id)
);

Вместо того чтобы вставлять данные вручную, давайте загрузим их с помощью CSV-файла. Вы можете скачать файл из этого репозитория или создать его самостоятельно. Имейте в виду, чтобы разрешить pgAdmin доступ к данным, вам может понадобиться расширить права доступа к папке (в моем случае – это папка db_data).

        COPY assignments(category, name, due_date, weight)
FROM 'C:/Users/mgsosna/Desktop/db_data/assignments.csv'
DELIMITER ','
CSV HEADER;
/*
COPY 5
Query returned successfully in 118 msec.
*/

COPY grades(assignment_id, score, student_id)
FROM 'C:/Users/mgsosna/Desktop/db_data/grades.csv'
DELIMITER ','
CSV HEADER;
/*
COPY 25
Query returned successfully in 64 msec.
*/

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

        SELECT
    c.teacher,
    a.category,
    ROUND(AVG(g.score), 1) AS avg_score
FROM
    students AS s
INNER JOIN classrooms AS c
    ON c.id = s.classroom_id
INNER JOIN grades AS g
    ON s.id = g.student_id
INNER JOIN assignments AS a
    ON a.id = g.assignment_id
GROUP BY
    1,
    2
ORDER BY
    3 DESC;

/*
 teacher | category  | avg_score
 ------- | --------- | ---------
 Jonah   |  project  |     100.0
 Jonah   |  homework |      94.0
 Jonah   |  exam     |      92.5
 Mary    |  homework |      78.3
 Mary    |  exam     |      76.0
 Mary    |  project  |      69.5
*/

Отлично! Мы установили, настроили и наполнили базу данных.

***

Итак, в этой статье мы научились:

создавать базу данных;
создавать таблицы;
наполнять таблицы данными;
устанавливать связи между таблицами;

Теперь у нас всё готово, чтобы пробовать более сложные возможности SQL. Мы начнем с возможностей синтаксиса, которые, вероятно, вам еще не знакомы и которые откроют перед вами новые границы в написании SQL-запросов. Также мы разберем некоторый виды соединений таблиц (JOIN) и способы организации запросов в тех случаях, когда они занимают десятки или даже сотни строк.

В следующей части мы разберем:

виды фильтраций в запросах;
запросы с условиями типа if-else;
новые виды соединений таблиц;
функции для работы с массивами;

Материалы по теме

🐘 8 лучших GUI клиентов PostgreSQL в 2021 году
🐍🐬 Python и MySQL: практическое введение
🐍🗄️ Управление данными с помощью Python, SQLite и SQLAlchemy

Источник

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

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

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

В этой статье

Некоторые термины, связанные с базами данных
Что такое правильная структура базы данных?
Процесс проектирования
Определение назначения базы данных
Поиск и упорядочение необходимых сведений
Распределение данных по таблицам
Преобразование элементов данных в столбцы
Задание первичных ключей
Создание связей между таблицами
Усовершенствование структуры
Применение правил нормализации

Некоторые термины, связанные с базами данных

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

Каждую строку правильнее называть записью, а каждый столбец — полем. Запись — это эффективный и согласованный способ объединения сведений о чем-либо. Поле — это отдельный элемент сведений (элементы такого типа есть в каждой записи). Например, в таблице «Товары» каждая строка или запись может содержать сведения об одном товаре. Каждые столбец или поле содержат сведения определенного типа об этом товаре, например название или цену.

К началу страницы

Что такое правильная структура базы данных?

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

Правильная структура базы данных подразумевает:

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

К началу страницы

Процесс проектирования

Процесс проектирования включает следующие этапы:

Определение назначения базы данных

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

Соберите сведения всех типов, которые потребуется внести в базу данных, например названия товаров и номера заказов.
Разделение данных по таблицам

Разделите элементы данных по основным темам или группам, например «Товары» и «Заказы». Затем для каждой темы создается таблица.
Преобразование элементов данных в столбцы

Решите, какие сведения будут храниться в каждой таблице. Каждый элемент становится полем и отображается в виде столбца в таблице. Например, таблица «Сотрудники» может содержать такие поля, как «Фамилия» и «Дата найма».
Задание первичных ключей

Выберите первичный ключ для каждой таблицы. Первичный ключ — это столбец, однозначно определяющий каждую строку. Примеры: «Код товара» и «Код заказа».
Настройка связей между таблицами

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

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

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

К началу страницы

Определение назначения базы данных

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

К началу страницы

Поиск и упорядочение необходимых сведений

Чтобы найти и упорядоступить необходимую информацию, начните с имеющихся сведений. Например, вы можете записать заказы на покупку в записи книги или сохранить сведения о клиентах в бумажных формах в картотеке. Соберите эти документы и соберите в списке каждый тип показанной информации (например, каждое поле, заполненное в форме). Если у вас еще нет форм, представьте, что вам нужно создать форму для записи сведений о клиенте. Какие сведения нужно поместить в форму? Какие поля заливки нужно создать? Определите и перечислить каждый из этих элементов. Предположим, что в настоящее время список клиентов находится на индексных карточках. Изучив эти карточки, вы можете показать, что каждая карточка содержит имя клиента, адрес, город, штат, почтовый индекс и номер телефона. Каждый из этих элементов представляет потенциальный столбец в таблице.

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

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

Продумывая структуру предполагаемых отчетов и почтовых рассылок, вы определите те элементы, которые нужно включить в базу данных. Предположим, вы даете клиентам возможность подписаться на периодическую рассылку обновлений (или отказаться от нее) и хотите распечатать список тех, кто подписался. Для записи этих сведений вы добавляете в таблицу клиентов столбец «Отправка почты». В этом поле для каждого клиента можно выбрать значение «Да» или «Нет».

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

Имеет смысл создать прототип каждого отчета или выходного списка и продумайте, какие элементы потребуется создать для этого отчета. Например, при проверке письма на бланке могут возникнуть некоторые моменты. Если вы хотите включить правильное приветствие, например строку «Г-н», «Г-жа» или «Ms», которая начинает приветствие, необходимо создать элемент приветствия. Кроме того, письма обычно начинаются с буквы «Уважаемый г-н Климов», а не «Уважаемый. Г-н Сильвстер Климов». Это позволяет сохранить фамилию отдельно от имени.

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

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

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

К началу страницы

Распределение данных по таблицам

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

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

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

В этом случае каждая строка содержит сведения о товаре и его поставщике. Так как у одного поставщика может быть несколько товаров, имя и адрес поставщика должны повторяться несколько раз. Это пустая трата места на диске. Гораздо лучше записать сведения о поставщике только один раз в отдельной таблице «Поставщики» и связать ее с таблицей «Товары».

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

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

Наконец, предположим, что у вас есть только один товар, поставляемый компанией Coho Winery, и вы хотите удалить этот товар, но сохранить имя и адрес поставщика. Как удалить запись о товаре, не потеряв сведений о поставщике? Это невозможно. Поскольку каждая запись содержит сведения и о товаре, и о поставщике, вы не можете удалить их по отдельности. Чтобы разделить эти сведения, необходимо сделать из одной таблицы две: одну — для сведений о товаре, другую —для сведений о поставщике. Тогда удаление записи о товаре не приведет к удалению записи о поставщике.

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

К началу страницы

Преобразование элементов данных в столбцы

Чтобы определить столбцы таблицы, решите, какие сведения по теме таблицы вам нужно отслеживать. Например, в таблицу клиентов можно включить столбцы «Имя», «Адрес», «Город, область, почтовый индекс», «Отправка почты», «Обращение» и «Адрес электронной почты». Набор столбцов одинаков для всех записей в таблице, поэтому для каждой записи можно хранить одни и те же сведения. Например, столбец «Адрес» содержит адреса клиентов. Каждая запись содержит сведения только об одном клиенте, а поле адреса — его адрес.

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

Вам также нужно определить, какого рода данные будут храниться в базе данных: отечественные или международные. Например, если вы планируете хранить в базе данных международные адреса, лучше использовать столбец «Регион», а не «Страна», потому что в таком столбце можно указывать области внутри своей страны и регионы других стран. Точно так же в поле «Почтовый индекс» можно будет хранить почтовые индексы разных стран.

В списке ниже приведены некоторые советы по определению столбцов.

Не включайте вычисляемые данные

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

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

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

К началу страницы

Задание первичных ключей

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

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

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

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

Часто в качестве первичного ключа используется произвольное уникальное число. Например, каждому заказу можно назначить уникальный номер. Целью номера заказа является определение заказа. После того как оно будет назначено, оно никогда не изменится.

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

1. Столбец с типом данных «Счетчик» — отличный первичный ключ. Коды товаров никогда не совпадают.

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

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

К началу страницы

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

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

1. Эта форма содержит данные из таблиц клиентов,

2. сотрудников,

3. заказов,

4. товаров

5. и сведений о заказах.

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

К началу страницы

Создание связи «один ко многим»

Рассмотрим пример таблиц «Поставщики» и «Товары» в базе данных «Заказы на товары». Поставщик может поставлять любое количество товаров. Следуют, что у любого поставщика, представленного в таблице «Поставщики», может быть много товаров, представленных в таблице «Товары». Поэтому связь между таблицами «Поставщики» и «Товары» является связью «один-к-многим».

Чтобы создать связь «один ко многим» в структуре базы данных, добавьте первичный ключ на стороне «один» в таблицу на стороне «многие» в виде дополнительного столбца или столбцов. Например, в данном случае вы добавляете столбец «Код поставщика» из таблицы «Поставщики» в таблицу «Товары». Затем Access сможет с помощью кода поставщика в таблице «Товары» найти поставщика для каждого товара.

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

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

К началу страницы

Создание связи «многие ко многим»

Рассмотрим связь между таблицами «Товары» и «Заказы».

Отдельный заказ может включать несколько товаров. С другой стороны, один товар может входить в несколько заказов. Таким образом, для каждой записи в таблице «Заказы» может существовать несколько записей в таблицы «Товары». Для каждой записи в таблице «Товары» может быть несколько записей в таблице «Заказы». Этот тип связи называется отношением «многие-к-многим», так как для любого товара может быть множество заказов. и для любого заказа может быть множество продуктов. Обратите внимание на то, что для обнаружения связей «многие-к-многим» между таблицами важно учитывать обе стороны связи.

Связь между темами двух таблиц (заказов и товаров) относится к типу «многие ко многим». Это проблема. Представьте, что произойдет, если для создания связи между двумя таблицами вы попытаетесь добавить поле «Код товара» в таблицу «Заказы». Чтобы заказ мог включать несколько товаров, вам потребуется несколько записей для каждого заказа в таблице «Заказы». В этом случае сведения о заказе придется повторять в каждой строке заказа, что может привести к неэффективности структуры таблицы и потере точности данных. Та же проблема возникает при создании поля «Код заказа» в таблице «Товары» — для каждого товара в таблице потребуется несколько записей. Как решить эту проблему?

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

Каждая запись в таблице «Сведения о заказах» представляет собой отдельный элемент строки заказа. Первичный ключ этой таблицы состоит из двух полей — внешних ключей таблиц «Заказы» и «Товары». Использовать только поле «Код заказа» в качестве первичного ключа для этой таблицы нельзя, поскольку в одном заказе может быть несколько элементов строки. Код заказа повторяется для каждого элемента строки, так что это поле не содержит уникальные значения. Использовать только поле «Код товара» также нельзя, поскольку один товар может входить в разные заказы. Но вместе эти два поля всегда обеспечивают уникальное значение для каждой записи.

В базе данных продаж товаров между таблицами «Заказы» и «Товары» нет прямой связи. Но они связаны опосредованно через таблицу «Сведения о заказах». Связь «многие ко многим» между заказами и товарами представлена в базе данных двумя связями «один ко многим».

Связь «один ко многим» между таблицами «Заказы» и «Сведения о заказах». В каждом заказе может быть несколько элементов строк, но каждый элемент строки связан только с одним заказом.
Связь «один ко многим» между таблицами «Товары» и «Сведения о заказах». Каждый товар может быть связан с несколькими элементами строк, но каждый элемент строки связан только с одним товаром.

В таблице «Сведения о заказах» можно определить все продукты по определенному заказу. Вы также можете определить все заказы для определенного товара.

После создания таблицы «Сведения о заказах» список таблиц и полей может выглядеть так:

К началу страницы

Создание связи «один к одному»

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

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

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

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

К началу страницы

Усовершенствование структуры

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

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

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

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

Усовершенствование таблицы «Товары»

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

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

Лучше выделить категории в качестве отдельной темы для отслеживания в базе данных и создать для них отдельную таблицу с собственным первичным ключом. Затем первичный ключ таблицы «Категории» можно добавить в таблицу «Товары» в качестве внешнего ключа.

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

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

Код товара
Название
Код товара1
Название1
Код товара2
Название2
Код товара3
Название3

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

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

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

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

К началу страницы

Применение правил нормализации

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

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

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

Первая нормальная форма

Согласно первой нормальной форме на пересечении строки и столбца в таблице должно находиться одно значение, а не список значений. Например, у вас не может быть поля «Цена» с несколькими ценами. Если представить каждое пересечение строки и столбца как ячейку, эта ячейка должна содержать лишь одно значение.

Вторая нормальная форма

Согласно второй нормальной форме каждый столбец, не являющийся ключевым, должен зависеть от всего ключевого столбца, а не от его части. Это правило применяется, если первичный ключ состоит из нескольких столбцов. Допустим, ваша таблица содержит следующие столбцы, причем столбцы «Код заказа» и «Код товара» образуют первичный ключ:

Код заказа (первичный ключ)
Код товара (первичный ключ)
Название товара

Эта структура не соответствует второй нормальной форме, поскольку название товара зависит от кода товара, но не зависит от кода заказа, то есть этот столбец зависит не от всего первичного ключа. Из этой таблицы нужно удалить столбец «Название товара». Он относится к другой таблице («Товары»).

Третья нормальная форма

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

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

Код товара (первичный ключ)
Название
Рекомендуемая розничная цена
Скидка

Предположим, что скидка зависит от рекомендуемой розничной цены. В этом случае таблица не соответствует третьей нормальной форме, поскольку столбец «Скидка», не являющийся ключевым, зависит от столбца «Рекомендуемая розничная цена», который тоже не является ключевым. Независимость столбцов друг от друга означает, что изменение любого неключевого столбца не должно влиять на другие столбцы. Если вы измените значение в поле «Рекомендуемая розничная цена», соответствующим образом изменится и значение скидки, тем самым нарушая правило. В данном случае столбец «Скидка» следует перенести в другую таблицу, в которой столбец «Рекомендуемая розничная цена» является ключевым.

К началу страницы

Источник