Разработка и сопровождение баз данных

Архитектура баз данных

 

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

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

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

Физическая архитектура базы данных. База данных SQL Server 2000 хранится в самостоятельном, уникальном для каж­дой БД наборе файлов. Кроме того, журнал транзакций и сами данные обязательно хранятся отдельно. Это повышает отказоустойчивость базы данных в случае сбоев системы. Рассмотрим физическую структуру базы данных более подробно.

Файлы и группы файлов. Для хранения базы данных предназначен набор файлов, персональный для любой базы данных. Каждый файл может принадлежать только одной базе данных. В SQL Server 2000 существует два типа файлов базы данных:

1. Файлы данных (data file). Предназначены для хранения информации, находящейся в таблицах базы данных. Кроме того, в этих файлах также размещены процедуры, ограничения, триггеры, индексы и другая информация;

2. Файлы журнала транзакций (transaction log file). В файлы этого типа SQL Server 2000 записывает информацию о ходе выполнения транзакций. В них размешается информация о состоянии данных перед началом транзакции, о выполняемых изменениях, блокированных ресурсах и другая сопутствующая информация.

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

Файлы данных бывают двух типов:

- Primary File (основной,или главный, файл). Каждая база данных имеет один и только один главный файл. Если база данных включает в себя только один файл данных, то этот файл будет основным. Основной файл предназначен для хранения всех системных таблиц, присутствующих в любой базе данных. В основном файле хранится информация о структуре базы данных, созданных в ней объектах, параметрах дополнительных файлов и файлов журнала тран­закций. По умолчанию основному файлу базы данных присваивается расширение mdf (Master Data File);

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

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

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

- таблицы (tables). Это единственный объект базы данных, предназначенный для хранения пользовательских данных;

- представления (views). Являются виртуальными таблицами (virtual tables), ко­торые отображают данные, хранящиеся в других таблицах. Для пользователя же представления во многом напоминают таблицы;

- индексы (indexes). Объекты этого типа предназначены для повышения про­изводительности работы сервера при поиске нужных данных в таблицах и представлениях, что достигается путем хранения в упорядоченном состоянии данных одного или более столбцов таблицы или представления. Таким обра­зом, индексы не могут существовать сами по себе;

- ключи (keys). Являются одним из типов ограничения целостности. Однако они играют достаточно важную роль в базе данных и поэтому рассматрива­ются как отдельные объекты. Тем не менее реализуются они так же, как и другие ограничения целостности, которые связываются с таблицами;

- умолчания (defaults). Этот тип объектов описывает значения, которые при­сваиваются столбцам таблицы, если при добавлении строки явно не было указано значение для соответствующего столбца;

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

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

- хранимые процедуры (stored procedures). Представляют собой набор команд Transact-SQL, сохраненных специальным образом. Каждая процедура имеет свое имя. По этому имени пользователи могут вызывать процедуру, запуская тем самым на выполнение весь набор команд, представляющих тело проце­дуры;

- триггеры (triggers). Это специальный тип хранимых процедур, автоматически запускаемых сервером при выполнении удаления, вставки или изменения данных в конкретной таблице. Другими словами, триггеры связываются с определенной таблицей и не могут существовать сами по себе;

- определяемые пользователем типы данных (user-defined data types, UDDT). Эти объекты представляют собой типы данных, создаваемые пользователями;

- определяемые пользователем функции (user-defined function). Объекты этого типа представляют собой набор команд Transact-SQL, сохраненных пользова­телем в виде функции.

 

Транзакции и блокировки

 

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

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

Транзакция (transaction) представляет собой набор из од­ной или более команд, обрабатываемых как единое целое, т.е. будет выпол­нен либо весь набор команд, либо не выполнена ни одна из них. Одна транзакция может изменять как отдельную строку таблицы, так и миллионы строк в различных таблицах. Кроме того, с помощью распределенных транзакций (distributed transaction) можно изменять строки в разных базах данных. SQL Server 2000 гарантирует, что данные, к которым обращается транзакция, оста­нутся неизменными на всем протяжении существования транзакции.

По умолчанию каждая команда Transact-SQL рассматривается как отдельная транзакция. В обычном режиме ни одна команда изменения данных не может быть выполнена вне транзакции, тем самым обеспечивается целостность дан­ных. Имеются определенные требования к выполнению транзакций системой управ­ления базами данных. Эти требования, известные как требования ACID (Atomicity, Consistency, Isolation и Durability), описывают, как должны обра­батываться данные и в каком состоянии они должны находиться после завер­шения транзакции.

Выполнение требования ACID по обработке транзакций распространяется на систему управления базами данных, т.е. пользователь не должен предпри­нимать никаких дополнительных усилий, чтобы соблюсти перечисленные тре­бования. SQL Server 2000, как и многие другие системы, автоматически гаран­тирует выполнение требований ACID, скрывая их от пользователей. Например, чтобы обеспечить соблюдение требования изолированности транзакций, в SQL Server 2000 используются блокировки (locks). Блокировкой (locks) называется временное ограничение, накладываемое систе­мой на использование тех или иных ресурсов.

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

Соблюдение требований ACID берет на себя SQL Server 2000, обеспечивая разработчика надежным механизмом обработки и хра­нения данных. На программиста ложится реализация бизнес-правил, описы­вающих методы взаимодействия и обработки данных. При этом должна быть обеспечена логическая целостность данных. Программист должен разработать верные и быстрые алгоритмы, реализующие бизнес-правила. При этом необхо­димо решить, сколько транзакций будет использоваться и как много команд будет включено в каждую транзакцию. По возможности следует включать в транзакцию как можно меньше команд, чтобы блокировать ресурсы минималь­ное количество времени. Это позволяет повысить производительность системы в целом. Использование больших транзакций, включающих множество команд, приведет к длительному блокированию ресурсов. В результате другие транзак­ции будут ожидать завершения начатой транзакции и разблокирования ресур­сов. В свою очередь, эти транзакции также могут блокировать еще какие-нибудь ресурсы. Если блокированные второй транзакцией ресурсы необходимы для за­вершения первой транзакции, но первая транзакция использует ресурсы, раз­блокирования которых ожидает вторая транзакция, то возникает тупиковая транзакция или, как ее еще называют, мертвая блокировка (deadlock).

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

Распределенные транзакции (distributed transaction) представляют собой совокуп­ность двух или более локальных транзакций, выполняемых одновременно в раз­личных базах данных. Можно сказать, что распределенные транзакции являются своего рода надстройкой над локальными транзакциями. Однако каждая из ло­кальных транзакций выполняется самостоятельно и независимо от существова­ния других транзакций и от того, что она является частью распределенной транзак­ции. Необходимо каким-то образом синхронизировать все действия, выполняемые в каждой из локальных транзакций, и производить централизованную обработку всех данных, полученных из локальных транзакций. В качестве такого централь­ного менеджера в SQL Server 2000 используется компонент MSDTC.

Координатор распределенных транзакций (MSDTC, Microsoft Distributed Transac­tion Coordinator) контролирует всю работу по инициализации, откату и фикси­рованию локальных транзакций. Выполнение распределенных транзакций явля­ется довольно сложным процессом, работу которого обеспечивает множество различных модулей. Сам координатор распределенных транзакций реализован в виде службы операционной системы и может запускаться отдельно от SQL Server 2000. Возможности MSDTC могут использоваться не только SQL Server 2000, но и другими приложениями, в том числе и написанными пользова­телями.

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

Операции установки, снятия и управления блокировками требуют определенного количества системных ресурсов, таких, как процессорное время и оперативная память. При ограниченных ресурсах можно лимитировать количество блокировок, которое разрешено устанавливать в системе. Для этого можно использовать следующую системную хранимую процедуру: sp_configure ‘locks’, num_locks.

Аргумент num_locks определяет максимальное количество блокировок, которое может быть установлено на сервере для всех баз данных. По умолчанию установлено значение 0, что соответствует динамическому управлению максимальным количеством блокировок. Значение num_locks может колебаться в пределах от 5000 до 2 147 483 647.

Для снижения общих затрат сервера на поддержание блокировок могут бы использованы различные методы управления блокированием ресурсов. Teopия управления конкуренцией (Concurrency control theory) предусматривает два метода обеспечения работы пользователей:

1. Оптимистическая конкуренция (Optimistic Concurrency Control). При работе в этом режиме при выполнении операций чтения из транзакции не происходит блокирования используемых ресурсов. При выполнении операции повторного чтения из той же транзакции система проверяет, не были ли изменены данные со времени последнего чтения. Если это произошло, то транзакция откатывается и ее необходимо начать заново. Использование этого режима поведения системы блокирования оправданно в базах данных, мало подверженных изменениям и в которых невелика вероятность того, что произойдет откат транзакции из-за изменения данных.

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

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

 

Работа с базой данных

 

База данных является базовым элементом SQL Server 2000 и своего рода контейнером, в котором располагаются объекты и данные. Любой объект должен принадлежать базе данных. Каждая база данных имеет свою систему безопасно­сти, связанную с системой безопасности SQL Server 2000. Любой пользователь при обращении к серверу работает в контексте какой-то базы данных. Каждой базе данных сопоставлен пользователь, который является ее владельцем (database owner). Этот пользователь имеет имя dbo и ему предоставлены макси­мальные права в базе данных.

Cоздание базы данных возможно средствами Transact-SQL, с помощью Enterprise Manager и мастера создания базы данных Create Database Wizard. Создание базы данных заключается в том, что на уровне операционной системы будет создан набор файлов, который и станет представ­лять базу данных. Напомним, что каждая база данных как минимум состоит из двух файлов – один для данных и один для журнала транзакций. Помимо этих двух файлов, могут быть созданы дополнительные файлы данных и журнала транзакций. Один из файлов данных является первичным (primary) и содержит все системные таблицы базы данных.

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

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

Мы рассмотрим только один способ создания базы данных – с помощью графического интерфейса Enterprise Manager.

С помощью этого инструмента можно не только создавать базы данных, но и управлять ими, а также удалять их. В общем случае исполь­зование Enterprise Manager по сравнению с непосредственным использованием команд Transact-SQL может заметно сократить время, необходимое на создание баз данных. Работа с Enterprise Manager не требует знания синтаксиса команды create database, что является неоспоримым достоинством.

Для управления базами данных SQL Server 2000 используется папка Databases (рис. 12), имеющаяся в каждой инсталляции. Непосредственно в этой папке перечисляется набор баз данных, созданных на сервере. Как видно из рисунка, в папке перечислены не только пользовательские базы данных, но и системные. Однако если не предполагается работать с системными базами данных, а также с системными объектами пользовательских баз данных и наличие их в панели Enterprise Manager только мешает работе, то можно запретить отображение этих объектов. Для этого достаточно открыть окно регистрации сервераRegistered SQL Server Properties (рис. 13) и сбросить флажок Show system databases and system objects. Для открытия окна свойств сервера достаточно в контекстном меню сервера выбрать команду Edit SQL Server Registration Properties.

Создание новой базы данных выполняется с помощью окна Database Properties (рис. 14). Открыть это окно можно разными способами:

- выбрав в контекстном меню папки Databases команду New Database;

- щелкнув правой кнопкой мыши на пустом пространстве правой части и выбрав в открывшемся контекстном меню команду New Database;

- нажав в панели инструментов Enterprise Manager кнопку New Database;

- выбрав в меню Action команду New Database.

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

 

 

Как видно из рисунка, окно Database Properties имеет три вкладки. Рассмотрим поочередно работу с каждой из них. Первая вкладка имеет имя General (см. рис. 14) и предназначена для указания имени базы данных и сопоставления, которое будет использоваться для базы данных. Проводя аналогию с командой Create Database, с помощью вкладки General устанавливаются значения для параметров database_name И COLLATE collation_name.

Остальные элементы управления вкладки General предназначены для предоставления пользователю различной информации о базе данных. На момент создания базы данных этой информации еще не существует, и поэтому указываются зна­чения (Unknown) (неизвестно) и None (нет).

При выборе имени базы данных, которое должно быть введено в поле Name, следует придерживаться тех же правил, которые используются при непосредст­венной работе с командой Create Database. Сопоставление, которое будет иметь база данных, выбирается с помощью раскрывающегося списка Collation name. По умолчанию список содержит значение (Server default), что предписы­вает применять для базы данных то же сопоставление, которое было указано на уровне сервера при установке SQL Server 2000. Однако можно выбрать и любое другое сопоставление.

Перейдем к рассмотрению вкладки Data Files (рис. 15), предназначенной для определения файлов данных, из которых будет состоять создаваемая база данных

В верхней части вкладки Data Files расположена таблица Database files, с помощью которой собственно и определяются файлы базы данных. В столбце File Name указывается логическое имя файла. В столбце же Location задается полный путь и имя файла опе­рационной системы. Отметим, что указанный в столбце Location файл не должен существовать на момент создания базы данных. Путь и имя файла могут быть введены вручную или выбраны с помощью окна Locate Database File, открыть которое можно с помощью кнопки, расположенной в левой части столбца Location.

В столбце Initial size (MB) находится первоначальный размер, который файл будет иметь непосредственно после создания базы данных. Если отсутствует какой-либо суффикс, то подразумевается, что значение указано в мегабайтах.

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

Помимо сведений, указываемых в таблице Database files, файлы базы данных имеют дополнительные свойства, такие, как максимальный размер и шаг при­роста. Управление этими свойствами осуществляется с помощью группы эле­ментов управления File properties, расположенной в нижней части вкладки Data Files.

Вкладка Transaction Log (рис. 16) предназначена для управления файлами журнала транзакций. Как видно из рисунка, эта вкладкав значительной степени напомина­ет вкладкуData Files. Единственное различие между ними состоит в том, что при определении файлов журнала транзакций нельзя работать с группами файлов.

 

После того как все файлы базы данных будут определены, а также указано имя базы данных и сопоставление, остается только нажать кнопку ОК и Enterprise Manager приступит к непосредственному созданию базы данных. Для этого он сгенерирует код команды create database на основе введенных поль­зователем значений и выполнит его. Рассмотрение создания базы дан­ных средствами Enterprise Manager можно считать оконченным.

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

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

 

Работа с таблицами

 

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

Вначале таблицы необходимо создать. Во время этой операции пользователь определяет имя таблицы, имена столбцов, тип хранимых в них данных, значения по умолчанию, возможность хранения неопреде­ленных значений, первичный и внешний ключи и некоторые другие свойства. Создание таблиц в SQL Server 2000 возможно либо с помощью графического интерфейса Enterprise Manager, либо с помощью команд Transact-SQL. К сожа­лению, мастера создания таблиц в SQL Server 2000 нет.

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

При создании таблиц пользователь может для столбцов, помимо задания базовых свойств, таких, как имя, тип данных, размер и точность, указать ограничения целостности. Ограничения целостности (constraints) – это механизм контроля значений, которые могут храниться в полях строки. В SQL Server 2000 поддерживаются сле­дующие ограничения целостности:

- Check – с помощью логических условий налагает ограничение на значения, которые могут храниться в столбце;

- Null – задает возможность хранения неопределенных значений;

- Default – определяет значение по умолчанию;

- Unique – гарантирует уникальность значений в столбце;

- Primary Key – определяет первичный ключ;

- Foreign Key – определяет внешний ключ;

- No Action – предписывает не выполнять в зависимой таблице никаких дей­ствий при удалении или обновлении строк в главной таблице;

- Cascade – в данном случае будет осуществляться каскадное изменение значений в зависимой таблице при внесении изменений в главную таблицу.

Одной из основополагающих характеристик столбца является тип данных (data type). Тип данных определяет диапазон значений, которые можно будет хранить в столбце. Для столбцов могут применяться не все типы данных, поддерживаемые Transact-SQL. В частности, для таблиц не могут быть выбраны типы данных cursor и table. Они служат только для рабо­ты с локальными переменными, функциями, процедурами и т.д. В свою оче­редь, для локальных переменных нельзя использовать некоторые типы данных, успешно поддерживаемые столбцами таблиц. К этим типам данных относятся timestamp, text, ntext и image. Полный список типов данных, применимых для столбцов, будет приведен ниже.

Каждая база данных имеет свой собственный набор таблиц, посмотреть который средствами Enterprise Manager можно с помощью папки Tables.

Создание таблицы выполняется с помощью окна New Table (рис. 17), для открытия которого достаточно в контекстном меню папки Tables выбрать команду New Table.

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

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

- Column Name. В этой колонке задается имя, которое будет иметь столбец. При выборе имени следует придерживаться стандартных правил именования объектов базы данных. Разрешается применение ограничителей. Имя стол должно быть уникально в пределах таблицы;

- Data Type. Элемент этой колонки представляет собой раскрывающийся список, с помощью которого необходимо выбрать тип данных, назначаемый столбцу;

-Length. Указывается размер типа данных, выбранного для столбца. Некоторые типы данных (char, nvarchar, binary и др.) позволяют изменять значение в этой колонке, тем самым предоставляя возможность управлять количеством памяти, выделяемой для столбца. Другие же типыданных всегда имеют один и тот же размер (например, int, datetime и т.д.), и для них изменять значения в колонкеLength нельзя;

-Allow Nulls. Установка флажка в этой колонке разрешает хранение значений null. Отметим, однако, что если столбец входит в первичный ключ, то хранение значений null для него разрешить нельзя.

С помощью верхней части можно также определить первичный ключ таблиц. Для этого достаточно выделить один или более столбцов, из которых должен состоять первичный ключ, щелкнуть правой кнопкой мыши и в открывшимся контекстном меню выбрать команду Set Primary Key. После этого слева от каждого столбца, включенного в первичный ключ, будет отображаться символ ключ. На рисунке 17 первичным ключом является столбец id.

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

-Description. Это текстовое поле предназначено для ввода краткого описания столбца, которое не используется системой;

- Default Value. Значение, которое будет присваиваться столбцу по умолчанию;

- Precision. В этом поле указывается максимальное количество цифр, в том числе после запятой, которое можно хранить в столбце. Доступно только для нецелочисленных типов данных с фиксированной точностью, также называемыми десятичными (decimal). К этим типам данных относятся numeric и decimal. Для нецелочисленных (или приблизительных) типов данных с фиксированной точностью, также называемых приблизительными (approximately), таких, как real и float, значение в этом поле (24 и 53 соответственно) доступно только для чтения. Аналогичная ситуация и с целочисленными типами данных (tinyint, smallint, int и bigint);

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

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

1. Identity Seed. В этом поле указывается начальное значение, которое будет использовано для автоматического генерирования значений для столбца-счетчика;

2. Identity Increment. С помощью этого поля можно указать величину, на кото­рую станет увеличиваться значение в столбце-счетчике при вставке новой строки;

3. Is RowGuid. Этот раскрывающийся список, доступный только для типа дан­ных uniqueidentifier, содержит всего два значения – Yes и No. При выбо­ре первого из них столбец конфигурируется в качестве уникального глобаль­ного идентификатора строки, что соответствует указанию ключевого слова rowguidcol при описании столбца в команде create table. Автоматически в поле Default Value подставляется значение newid (). Таким образом, при до­бавлении в таблицу новой строки в соответствующий столбец будет автома­тически помешаться уникальное значение. Только один стол­бец в таблице может быть сконфигурирован как уникальный глобальный идентификатор строки. Тем не менее можно создавать множество столбцов с типом данных uniqueidentifier и значением по умолчанию newid ();

-Formula. В данном поле можно ввести формулу, с помощью которой будет формироваться значение столбца. Таким образом, соответствующий столбец будет являться вычисляемым столбцом (computed columns). Формула может включать ссылки на столбцы, функции, а также константы, которые связы­ваются в одно выражение с помощью различных операторов. Для вычисляе­мых столбцов, помимо формулы, разрешается указывать только имя столбца. Все остальные параметры, такие, как тип данных, значение по умолчанию, возможность хранения значений null, описание и другие, блокируются;

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

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

На этом работу по созданию таблиц можно закончить.

Удаление таблицы производится выбором команды Delete в контекстном меню таблицы. Для изменения сконфигурированной таблицы используется команда Design Table в том же контекстном меню.