НОВЫЙ КУРС БД 2013

Итак, подведем итог по всем уровням проектирования:

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

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

3. На физическом уровне строится модель данных на конкретной СУБД с указанием типов и раскрытием всех связей.

2.3.4 Проблемы проектирования

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

1 роблема: неправильная трактовка задания.

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

ути решения:

Привлечение специалистов из исследуемой предметной области для более глубокого понимания задачи

Самостоятельное знание или дополнительное изучение предметной области исполнителем

Корректировка и контроль цели задания на всех стадиях проектирования

2 роблема: определение сущностей для логической схемы.

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

ути решения:

Сверка логической схемы с заданием и ее корректировка при необходимости

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

3 роблема: выбор первичных ключей.

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

ути решения:

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

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

4 роблема: ограничения ссылочной целостности.

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

ути решения:

Опытный путь (т.е. минимальное ограничение и надежда на программиста)

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

5 роблема: выбор типов данных.

21

Не менее важной является проблема типов данных и типы данных на различных платформах (имеется ввиду ОС и архитектура процессора) и СУБД. На данной проблеме стоит заострить внимание более подробно: на сегодняшний день существует несколько операционных систем, в каждой из которых применяется своя кодировка для текста, что влечет далеко идущие и трудно отлавливаем ошибки. Например, первичным ключом таблицы «ГРУППА» является код группы записанный с помощью буквенно-символьного кода, естественно он уникален в рамках базы. Пусть база стоит на сервере, на котором стоит Linux и используется кодировка UTF-8, а все клиенты работают под управлением Windows XP и использую кодировку Windows-1258. Может возникнуть такая ситуация, что визуально одинаковые названия групп отличаются в разных кодировках. Такая проблема очень трудно выявляема, поскольку для человека эти группы имеют одинаковое название. Еще одной разновидностью этой проблемы является различная емкость для одних и тех же типов данных в разных СУБД. Или просто неправильный выбор типа данных для хранения какого-либо атрибута. Вообще проблем с типами данных очень много. Как уже было сказано, ошибки такого рода очень трудно выявляемы, и при проектировании на физическом уровне нужно постараться учесть все эти моменты.

ути решения:

Узнать платформу сервера и клиента, на которой будет стоять созданная БД и клиентское приложение (разрядность, ОС, кодировка и иные особенности)

Не использовать специальные типы данных, применимые только к конкретным СУБД

6 роблема: выбор С БД.

На данный момент самыми распространенными являются 2 СУБД – Oracle и MS SQL Server, еще можно выделить Firebird. Среди СУБД применяемыми для web самыми распространенными являются MySQL, SQLLite, PostgreeSQL. Уже на этапе получения задания следует обсудить вопрос выбора СУБД с заказчиком. Если все это будет реализовываться в рамках специфичной СУБД (например MS Access или того хуже в DOS подобной), то следует 5 раз подумать прежде чем браться за реализацию такого проекта.

ути решения:

Узнать платформу сервера и клиента, на которой будет стоять созданная БД и клиентское приложение (разрядность, ОС, кодировка и иные особенности)

Узнать каким образом нужно реализовывать безопасность (встроенными средствами СУБД или же программным образом)

Не использовать специальные функции, процедуры, типы данных и прочие особенности, применимые только к конкретным СУБД (поскольку возникнут трудности при переносе)

Общие проблемы:

роблема: Трудная воспринимаемость er-схемы при количестве сущностей более 10-15. Решение: разбивать на подсхемы и делить создание базы на несколько фрагментов.

роблема: Отсутствие масштабируемости базы данных.

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

роблема: На всех реляционных СУБД скорость выполнения запроса пропорционально зависит от количества строк в таблице и соответственно при большом количестве записей (имеется ввиду 10-ки млн) выполнение запросов происходит очень медленно.

Решение: Использовать индексацию (что не всегда оправдано), разбивать искусственно такие таблицы на 2 и более (искусственная денормализация) или на крайний случай использовать другой тип СУБД.

22

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

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

Нормальная форма – требование, которому должна удовлетворять таблица.

Вклассической теории существует пять нормальных форм. И для того чтобы таблица находилась в N форме необходимо, чтобы она находилась в N-1 форме.

ервая нормальная форма (1NF)

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

Не удовлетворяет требованиям 1NF				Удовлетворяет требованиям 1NF
ID	FIO		ID	FAM	IMYA	OTCH
1	Иванов И.И.		1	Иванов	И	И
2	Петров П.П.		2	Петров	П	П

Вторая нормальная форма (2NF)

Таблица находится во 2NF, если она в 1NF и любой не ключевой столбец зависит от всего составного ключа. Или если у таблицы несоставной ключ, и она находится в 1NF, то она находится и во 2NF.

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

– студент, группа, предмет, дата сдачи, оценка. Пусть на таблицу наложены такие условия, студент может сдавать не более одного предмета в сутки. Логично предположить, что ключом данной таблицы будет студент, дата сдачи. Поля оценка и предмет зависят, от всего ключа. Т.е. они определяются тем, какой студент, когда сдавал, такой-то предмет на такую-то оценку. А вот атрибут группа зависит как от первичного ключа, так и от атрибута студент, но не от атрибута дата сдачи. Т.е. группа определяется именно студентом и никак не зависит от даты сдачи, таким образом, мы получили нарушение требования 2NF. Для того чтобы его устранить этот недостаток нужно разбить исходную таблицу (говорят провести декомпозицию) на несколько таблиц, по зависимым атрибутам и вынести все зависимые атрибуты в другую таблицу. Т.е. нам нужно разбить нашу таблицу на 2 таблицы по полю студент, так как группа зависит от атрибута студент, и вынести зависимый атрибут, т.е. поле группа в отдельную таблицу -

1 таблица: Студент, группа 2 таблица: Студент, дата сдачи, предмет, оценка

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

Третья нормальная форма (3NF)

Таблица находится в 3NF, если она во 2NF и любой ее не ключевой атрибут не зависит от другого не ключевого атрибута.

Например, пусть у нас есть таблица студент, с полями номер студента, фамилия, имя, отчество, дата, группа и староста. Таблица не имеет составных ключей (ключ здесь – номер студента) и все атрибуты атомарные, следовательно, таблица находится во 2NF. Однако здесь нарушено требование 3NF – фамилия старосты группы (поле староста) определяется только номером группы и не зависит от студента, поэтому одна и та же фамилия старосты будет многократно повторяться у разных студентов. В этом случае наблюдаются затруднения в корректировке фамилии старосты в случае назначения нового старосты, а также неоправданный расход памяти для хранения дублированной информации.

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

23

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

Рисунок 1. Пример декомпозиции структуры информационного объекта

Как видно из рисунка 1, исходная таблица «Студент группы» представляется в виде совокупности правильно структурированных таблиц «Студент» и «Группа», состав столбцов которых тождественен исходной таблице.

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

Четвертая нормальная форма (4NF)

4NF связана с понятием многозначной зависимости и используется там, где есть составные ключи.

Многозначная зависимость – отсутствие зависимости между атрибутами внутри составного ключа.

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

Поставщик	Заказчик	Магазин
X5 Retail Group	ИП Иванов	Пятерочка
X5 Retail Group	ИП Петров	Пятерочка
X5 Retail Group	ИП Петров	Магнит
American Import	ИП Иванов	Пятерочка

Так как поставщики не зависят от магазинов, но зависит от заказчика, на лицо многозначная зависимость. Чтобы добавить новую пару поставщик-заказчик нужно указать магазин, что не является рациональным. Для того чтобы устранить многозначную зависимость нужно провести декомпозицию на 2 таблицы «поставщик, заказчик» и «заказчик, магазин»

Таблица в 4NF если она в 3NF и отсутствует многозначная зависимость атрибутов.

ятая нормальная форма (5NF)

5NF связана с понятием зависимости по соединению и с использованием составных ключей.

Зависимость по соединению – означает, что таблица не может быть декомпозирована без потерь зависимости.

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

Поставщик	Заказчик	Магазин
X5 Retail Group	ИП Иванов	Пятерочка
X5 Retail Group	ИП Петров	Пятерочка
X5 Retail Group	ИП Петров	Магнит
American Import	ИП Иванов	Пятерочка

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

Таблица в 5NF, если она в 4NF и в ней отсутствуют зависимость по соединению.

24

ГЛАВА 3. АСПЕКТ МАНИПУЛЯЦИИ РМД

В процессе рассмотрения аспекта манипуляции РМД мы познакомимся с методами воздействия на данные, хранящиеся в базе данных, а также рассмотрим СУБД. В данной главе мы рассмотрим СУБД MS SQL SERVER 20..п и основные операторы языка TSQL.

3.1 Основные сведения о MS SQL Server

Реляционные СУБД состоят из множества объектов, их название и количество могут отличаться в различных СУБД. Мы будем работать с MS SQL Server версии 2000 или выше, поэтому рассмотрим, что собой представляет SQL Server, а также рассмотрим его основные объекты. MS SQL Server - СУБД реляционного типа, в котором применяется язык манипуляции данными Transact-SQL (совместная разработка Microsoft и Sybase). TSQL - расширение языка запросов SQL, созданного на основе стандартов ANSIMSO. На данном этапе я рекомендую читателю установить SQL Server, о том, как это сделать написано в Приложении 3.

3.1.1 История SQL.

Первая версия вышла в 1989 году и имела очень много недостатков (сетевые, платформенные и пр.). В те времена была достаточно острая борьба между разработчиками СУБД, и поэтому Microsoft необходимо было предъявлять очень жесткие требования в выпускаемым СУБД для успешного конкурирования на рынке. Борьба эта продолжалась до 95 года, т.е. до момента выхода Windows 95, получив удобный интерфейс, пользователи лавиной начали разрабатывать графические интерфейсы для работы с базой данных, это был настоящий прорыв Microsoft на рынке СУБД. Однако настоящую славу MS принесла версия 7.0, вышедшая в 1997 году. Затем были 2000, 2005, 2008 и вот сейчас уже вышел 2012 MS SQL Server.

Что же представляет собой SQL Server? СУБД MS SQL Server - это сложная программа, состоящая из множества модулей (справка, службы, агенты, библиотеки и пр.). При установке на ПК в операционной системе появляются новая служба - MS SQL Server. Это «виртуальный сервер» (т.е. процесс ОС), который и обрабатывает запросы идущие от пользователя. Конечно, есть и другие службы, но их мы рассмотрим позже, сейчас главное - понять как работает SQL в общем виде.

3.1.2 Основные объекты MS SQL Server

Рассмотрим основные объекты MS SQL Server:

■Базы данных

■Индексы

■Журналы транзакций

■Сборки

■Таблицы

■Файловые группы

■Отчеты

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

■Диаграммы

■Определяемые пользователем типы данных

■Роли

■Хранимые процедуры

■Пользователи

■Пользовательские функции

■Каталоги полнотекстового поиска

База данных представляет собой объект наиболее высокого уровня, и большая часть всех описанных объектов являются вложенными в базу данных. Непосредственно после установки SQL Server (любой версии) будут доступны 4 базы данных:

1.Master – эта БД отслеживает функционирование всей системы. В ней хранятся имена всех созданных объектов СУБД (БД, таблицы, триггеры и пр.).

2.Model – эта своего рода шаблон на основе которого строятся все БД.

3.MSDB – хранит все задачи пользователей (например запланированное резервное копирование или другие отложенные задачи).

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

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

 Журнал транзакций

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

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

 Индексы

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

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

2)Некластеризованный. Данный вид индекса подразумевает лишь список ключевых слов по которому происходит поиск и физически данные не сортируются. Индексов данного вида можно задавать несколько.

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

 Хранимые процедуры

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

Использование хранимых процедур дает следующие преимущества:

В качестве команды серверу посылается только имя хранимой процедуры (весь код хранимой процедуры храниться на сервере) а не множество строк кода запроса, что

26

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

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

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

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

ользовательские функции

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

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

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

Параметры в функции передаются только по значению (здесь запрещена передача по ссылке By ref)

 Триггеры

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

 Ограничение целостности и правила

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

 Файловые группы

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

 Диаграммы

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

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

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

27

ользователи и роли

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

ользовательские типы данных

Как видно из названия это типы данных определенные пользователем. Начиная с версии 2005, пользователь практически не ограничен в создании типов данных. Он может создавать любые типы данных с применением технологии .NET. Основная опасность в создании собственного типа данных состоит в том, что его определение занимает много ресурсов и поэтому необходимо самостоятельно заботиться о его корректном размещении в памяти, а также возможна избыточность собственных типов. Поэтому необходимо тщательно продумывать структуру типов и их хранение.

 Каталоги полнотекстового поиска

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

3.2Язык TSQL

3.2.1Язык TSQL и типы данных SQL Server

Язык TSQL (Transact Structure Query Language, процедурно расширенный структурированный язык запросов) – диалект языка SQL, который обладает циклами, функциями и прочими возможности процедурных языков программирования. Начиная с версии 2005 TSQL включен в список языков платформы .NET. Рассмотрение языка мы начнем с особенности именования объектов и типов данных языка.

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

Соглашения об именовании объектов

В именах объектов можно использовать пробелы, и даже ключевые слова, при этом правда такие имена нужно помещать в квадратные скобки – [имя объекта]. При именовании объектов можно использовать любой язык (определенный в СУБД SQL), в том числе и русский. Имя объекта может содержать до 128 символов.

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

Использовать только английский язык и цифры

Все имена объектов начинать с букв

Не использовать пробелы (вместо них пользоваться подчеркиванием)

Типы данных

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

28

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

Типы данных для версии 2005 приведены в приложении 1. Использование типов данных мы увидим на протяжении всего курса, а сейчас просто посмотрите приложение 1 и запомните особенности типов данных в этой СУБД, о них речь пойдет ниже. Первой, очень важной особенностью является то, что в SQL отсутствует беззнаковые типы данных, что является существенным минусом, так как увеличивается объем хранимых данных. Еще одной особенностью является то, что все типы данных нужно приводить явно! Используя функцию CONVERT или CAST, о которых речь пойдет позже. Момент явного приведения – это очень важный момент, поскольку при написании программ важно помнить, что компилятор языка не умеет преобразовывать типы самостоятельно. Хотя, на мой взгляд, данных факт дисциплинирует характер разработчика и не допускает вольностей с типами. И здесь же стоит упомянуть о Nullзначениях. Каждый тип данных может принимать Null-значения, и по умолчанию в большинстве случаев принимает именно это значение. Стоит помнить, что Null-значения это лишь специальное обозначение пустоты, оно не равно нулю или пустой строке, а также не нужно забывать, что одно Null-значение не равно другому Null-значению при сравнении. Наверно на этом можно подвести итог, - TSQL является процедурным языком программирования, его типы данных схожи с типами всех высокоуровневых языков программирования, здесь обязательны явные приведения типов и используется тринарная логика с Null значениями. Далее будут рассмотрены основные операторы

иконструкции языка.

3.2.2Операторы TSQL для манипуляции объектами SQL Server.

(CREATE, ALTER, DROP)

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

Оператор CREATE

CREATE тип_объекта [ИМЯ_ОБЪЕКТА]

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

CREATE DATABASE my_database

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

CREATE TABLE [table]

( column1 type1 [(size1)][CONSTRAINT _column-constraint1] [, column2 type2 [(size2)][CONSTRAINT _column-constraint2]

[, ...]][CONSTRAINT table-constraint1 _[,table-constraint2 [, ...]]]);

В этом операторе следует указать имя поля, тип данных для него (тип данных должен поддерживаться данной СУБД), длину (для некоторых типов полей) и, если нужно, серверные ограничения (с применением ключевого слова CONSTRAINT). Например, следующий запрос создает таблицу с именем Simple с четырьмя колонками — LastName, FirstName, EMail и

HomePage:

CREATE TABLE Simple

(

FirstName varchar(50) NOT NULL, LastName varchar(50) NOT NULL, EMail varchar(50),

HomePage varchar(255)

)

29

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

CREATE TABLE Simple

(

PersonID Integer NOT NULL PRIMARY KEY, FirstName varchar(50) NOT NULL,

LastName varchar(50) NOT NULL, EMail varchar(50),

HomePage varchar(255)

)

и указать, что комбинация полей LastName и FirstName должна быть уникальна:

CREATE TABLE Simple

(

PersonID Integer NOT NULL PRIMARY KEY, FirstName varchar(50) NOT NULL,

LastName varchar(50) NOT NULL, EMail varchar(50),

HomePage varchar(255),

CONSTRAINT SimpleConstraint UNIQUE (FirstName, LastName)

)

Оператор ALTER TABLE

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

Первая разновидность этого оператора используется для добавления колонки к таблице, и ее синтаксис имеет вид:

ALTER TABLE table ADD [COLUMN] column datatype [(size)] [CONSTRAINT sinlge-column-constraint]

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

ALTER TABLE Simple ADD Phone varchar(30)

Вторая разновидность оператора ALTER TABLE применяется для добавления серверных ограничений к таблице, а ее синтаксис имеет вид:

ALTER TABLE table ADD CONSTRAINT constraint

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

Третья разновидность предложения ALTER TABLE применяется для удаления поля из таблицы:

ALTER TABLE table DROP [COLUMN] column

Ключевое слово COLUMN использовать не обязательно. Например:

ALTER TABLE Simple DROP Phone

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

TABLE:

ALTER TABLE table DROP CONSTRAINT index

Ниже приведен пример такого запроса:

ALTER TABLE Simple DROP CONSTRAINT PrimaryKey

30