3.6 Пример построения подробной диаграммы «сущность – связь» для предметной области «Учебный процесс»

 

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

· Специальности (SPECIALITY). Атрибуты – номер, название специальности. Эта сущность необходима, т.к. студент поступает в ВУЗ на специальность, а потом распределяется по группам.

· Группы (GRUP). Атрибуты этой таблицы – номер, название, количество студентов, курс. Эта сущность отводится для хранения сведений о группах. Так как названия групп формируются в зависимости от факультета, кафедры, года поступления и будут многократно встречаться в связях с другими сущностями базы данных, то их целесообразно нумеровать и ссылаться на эти номера. Для этого вводится целочисленный атрибут Grup_ID – это ключевое поле, которое будет наращиваться на единицу при вводе в базу данных нового наименования.

· Студенты (STUDENTS). Эта сущность отводится для хранения сведений о студентах. Атрибуты – номер, фамилия, имя, отчество, дата рождения, адрес, номер группы, студент-староста. Stud_ID (идентификационный номер студента – обычно номер зачетной книжки) выбран в качестве первичного ключа (PK). Использование имени, фамилии и отчества в качестве идентификатора является неудобным решением, поскольку может появиться несколько однофамильцев. Это же правило относится к сочетанию фамилия-имя (отчества может не быть вообще). А учитывая, что идентификаторы студентов будут многократно встречаться в связях с другими сущностями базы данных, то их целесообразно нумеровать и ссылаться на эти номера.

· Кафедры (CHAIR). Атрибуты - номер, название, телефон и адрес. Эта сущность вводится для хранения сведений о кафедрах вуза. Chair_ID – это целочисленное ключевое поле, которое будет наращиваться на единицу при вводе в базу данных нового наименования автоматически.

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

· Предметы (SUBJECT). Атрибуты – номер, название, общее количество часов за семестр, лекционные часы, часы практикумов, лабораторные часы. Эта сущность отводится для хранения сведений о предметах. Атрибут Subj_ID – это ключевое поле, которое и будет идентификатором данной сущности. Атрибут Subj_NAME является текстовым типом данных для отображения названия предмета.

 

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

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

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

Бизнес-правило 1

Каждый студент поступает на одну специальность. На основе первого бизнес-правила мы получаем сегмент ER-модели, представленный на рис.1.2.

Рисунок 1.2 – ER–диаграмма бизнес-правила 1

Бизнес-правило 2

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

На основе Бизнес-правила 2 мы получаем следующий сегмент ER-модели.

Рисунок 1.3 – ER–диаграмма бизнес-правила2

Бизнес-правило 3

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

На основе Бизнес-правила 3 мы получаем следующий сегмент ER-Модели

Рисунок 1.4 – ER–диаграмма бизнес-правила 3

Бизнес-правило 4

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

То есть появляется еще одна таблица «Учебный процесс».

· Учебный процесс (STUDY). Сущность включает атрибуты - номер группы, номер предмета, номер преподавателя, форма обучения, количество часов. Атрибут Grup_ID отображает в формате integer группу, участвующую в учебном процессе. Атрибут Subj_IDотображает в формате integer предмет, относящийся к данной группе. Атрибут Teach_ID – это целочисленное поле, хранящее информацию о преподавателе, ведущем данный предмет. Атрибут Kredit_count – символьное поле, характеризующее форму обучения. Атрибут Total_Hours является целочисленным типом данных для отображения общего количества часов. Атрибут Lection_Hours является целочисленным типом данных для отображения количества лекционных часов. Атрибут Practice_Hoursявляется целочисленным типом данных для отображения количества часов практикума. Атрибут Labor_Hours является целочисленным типом данных для отображения количества лабораторных часов.

На основе Бизнес-правила 4 мы получаем следующий сегмент ER-Модели

 

Рисунок 1.5 – ER–диаграмма бизнес-правила 4

Бизнес-правило 5

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

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

На основе Бизнес-правила 5 мы получаем следующий сегмент ER-Модели

 

Рисунок 1.6 –ER–диаграмма бизнес-правила 5

 

База данных создаётся на основании схемы базы данных. Для преобразования ER–диаграммы в схему БД приведём уточнённую ER–диаграмму, содержащую атрибуты сущностей (рис. 1.6).

 

Рисунок 1.6 – Уточненная ER–диаграмма концептуальной модели учебного процесса

 

3.7 Преобразование концептуальной модели в реляционную модель

 

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

Преобразование объектных множеств и атрибутов. Объектное множество с атрибутами может быть преобразовано в реляционную таблицу с именем объектного множества в качестве имени таблицы и атрибутами объектного множества в качестве атрибутов таблицы. Если некоторый набор этих атрибутов может быть использован в качестве ключа таблицы, то он выбирается ключом таблицы. В противном случае в таблицу добавляется атрибут, значения которого будут однозначно определять объекты-элементы исходного объектного множества, и который, таким образом, может служить ключом таблицы. Преобразуем объектные множества ГРУППЫ, КАФЕДРЫ, ПРЕДМЕТЫ в реляционные таблицы с соответствующими названиями.

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

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

N – числовой (numeric);

C – символьный (char);

D – дата (различная стандартная длина для каждой СУБД, поэтому она не указывается).

В полях примечание первичные и внешние ключи также подразумеваются обязательными полями (NOT NULL).

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

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

1. Выбор и открытие шаблона.

2. Перетаскивание и соединение фигур.

3. Добавление текста (данных) в фигуры.

Выбор и открытие шаблона:

1. Откройте программу Visio 2007.

2. В списке Категории шаблонов выберите элемент Программное обеспечение и базы данных.

3. В диалоговом окне ПО и БД в области Готовые шаблоны дважды щелкните элемент Схема модели базы данных.

После открытия шаблона будут открыты необходимые коллекции фигур, которые называются наборами элементов. Наборы элементов, которые открываются с шаблоном Схема модели базы данных, называются Отношение сущности.

 

Рисунок 1.7 – Наборы элементов для работы с моделью базы данных в Visio

Перетащите первую фигуру (сущность, (Entity)) из набора элементов отношение сущности на страницу документа и отпустите кнопку мыши.

Рисунок 1.8 – Создание сущности (таблицы)

Фигуры Visio — это гораздо больше, чем просто изображения или символы.

Задайте свойства базы данных. Для этого щелкните по созданной фигуре (Таблица 1). Соответствующее окно (свойства базы данных, Рисунок 1.9) будет открыто в нижней части экрана.

Рисунок 1.9 – Свойства базы данных

В категории Определение введите физическое имя сущности (Студенты). Затем перейдите в категорию Колонки и введите данные соответствующие этой сущности.

Рисунок 1.10 – Добавление атрибутов таблицы

В результате получается таблица показанная на рисунке 1.11.

Рисунок 1.11 – Результат создания таблицы “Студенты”

Подобным образом необходимо создать все сущности базы данных “учебного процесса”, описанные в пункте 1.7.

После того, как создание всех сущностей завершено, необходимо создать отношения между таблицами. Для этого необходимо перетащить фигуру Отношение из набора элементов Отношение сущности (Рисунок 1.12)

Рисунок 1.12 – Создание отношения

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

Для реализации часть спроектированной модели данных учебного процесса в среде СУБД MS SQL Server 2008 создайте таблицы «Преподаватели», «Кафедры», «Группы» и «Студенты», «Предметы», «Специальности», «Учебный план», «Успеваемость». В лабораторной работе для объектов рассматриваемой базы данных применяются названия на английском языке. Это связано с требованиями используемого программного обеспечения. Поэтому в приведенных ниже примерах база данных называется “Education”. Для создания любого объекта SQL Server существует несколько способов, базирующихся на выполнении определенной команды.

Размещение пользовательских баз может меняться в зависимости от версии SQL и размещения Program Files. Выяснить место расположения пользовательских баз можно из основного окна программы, выбрав из контекстного меню Свойства (Properties) любой базы в списке Databases. Также в окне свойств на вкладке TransactionLog просмотрите место расположения журнала транзакций. Команды резервного копирования и восстановления базы данных тоже выбираются в контекстном меню: строка Все задачи (All Tasks), команды Backup Databases и Restore Databases.

 

Создание базы данных

 

Физически база данных располагается в одном или нескольких файлах операционной системы. В одном файле операционной системы не может содержаться несколько баз данных. В этом файле хранятся такие объекты , как таблицы и индексы. Журнал транзакций – это рабочие области, которые SQL Server применяет для записи информации до и после выполнения транзакции. Эта информация может использоваться для отмены выполненной транзакции или для восстановления базы данных, если возникнет такая необходимость. В MS SQL Server 2008 журналы транзакций хранятся в отдельном файле, а не вместе с таблицами, как было в предыдущих версиях. Для создания базы данных с помощью Transact-SQL используется команда CREATE DATABASE. Полный синтаксис команды приводить не будем, т.к. он занимает несколько страниц.

 

CREATE DATABASE lab_Study

ON PRIMARY

(NAME = education_data, FILENAME='C:\Data\education_data.mdf', size = 4,

maxsize =25, filegrowth = 1 mb)

LOG ON

(NAME = education_log, FILENAME='C:\Data\education_log.ldf', size = 4, maxsize = 20, filegrowth =1 mb);

 

Внимание: Размещение базы и журнала транзакций - 'С:\…’ - может меняться в зависимости от версии SQL и размещения Program Files.

Здесь:

- education имя создаваемой базы данных.

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

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

Яндекс.Директ

Интернет вчастный домРОСТЕЛЕКОМИнтернет 30-200 Мбит. Цифровое ТВ. Проверьте адрес на сайте РОСТЕЛЕКОМ!

Повышение квалификациипедагогов!Дистанционно. ФГОС. Скидки! Быстро! Лицензия. 2 документа: удостоверение и сертификат!

- LOG ON определяет список файлов на диске, в которых будет храниться журнал транзакций. Если этот параметр не определен, то размер журнала транзакций будет составлять 25% от общего размера файлов данных.

- education_data определяет логическое имя, которое SQL Server будет использовать для обращения к файлу.

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

Для создания таблиц и манипулирования ими внутри базы данных необходимо ввести понятие схемы. Схема представляет собой группу связанных между собой объектов базы данных (например, таблиц и индексов). Обычно схема является собственностью пользователя или приложения. В одной базе данных может храниться несколько схем, принадлежащих разным пользователям и приложениям. Можно представлять себе схему как логически сгруппированные таблицы или логическую базу данных, что постоянно используется при проектировании баз данных больших компаний и OLTP - БД. Схемы полезны тем, что группируют таблицы по владельцам и обеспечивают первый уровень защиты, разрешая пользователю просматривать таблицы, принадлежащие только ему. Если используемая вами РСУБД соответствует стандартам ANSI, то схема БД создается командой:

 

CREATE SCHEMA AUTHORIZATION <creator>;

 

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

CREATE SCHEMA AUTHORIZATION Ruslan;

 

Схемы и пользователи баз данных разделены – пользователи владеют схемами.

Для обращения к объектам, обычно используется двухсоставной идентификатор database_name.object_name (Education.Students).

Если используется схема, то используется трехсоставной идентификатор database_name.shema_name.object_name. В пределах базы данных это имя можно сократить до схема.объект. Т.е., если в базе существуют модули Отдел кадров, Бухгалтерия, Деканат, то таблицы могут быть разнесены по модулям (схемам).

 

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

 

USE lab_Study;

 

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

Создадим две схемы для обучения студентов StudySchema (таблицы Группы, Студенты, Предметы, Учебный план и Успеваемость) и данных деканата DekanatSchema (таблицы Кафедры и Преподаватели):

 

CREATE SCHEMA StudySchema

GO

CREATE SCHEMA DekanatSchema

GO

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

Создание таблиц

 

 

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

Таблицу можно создать с помощью оператора CREATE TABLE языка SQL.

Синтаксис:

( { < column_definition > | < table_constraint > } [ ,...n ]

)

< column_definition > ::=

{ column_name data_type }

[ { DEFAULT constant_expression

| [ IDENTITY [ ( seed , increment ) ]

]

} ]

[ ROWGUIDCOL ]

[ < column_constraint > [ ...n ] ]

< column_constraint > ::=

[ CONSTRAINT constraint_name ]

{ [ NULL | NOT NULL ]

| [ PRIMARY KEY | UNIQUE ]

| REFERENCES ref_table [ ( ref_column ) ]

[ ON DELETE { CASCADE | NO ACTION } ]

[ ON UPDATE { CASCADE | NO ACTION } ]

}

< table_constraint > ::=

[ CONSTRAINT constraint_name ]

{ [ { PRIMARY KEY | UNIQUE }

{ ( column [ ,...n ] ) }

]

| FOREIGN KEY

( column [ ,...n ] )

REFERENCES ref_table [ ( ref_column [ ,...n ] ) ]

[ ON DELETE { CASCADE | NO ACTION } ]

[ ON UPDATE { CASCADE | NO ACTION } ]

}

Замечания

· Аргументы и ограничения рассматриваются в справке оператора CREATE TABLE;

· Определения столбца: при создании таблицы необходимо указать, по крайней мере, одно определение столбца.

 

Правила допустимости нулевого значения в рамках определения таблицы: допустимость нулевого значения столбца определяет, будет ли нулевое значение (NULL) принято в столбец как данные. NULL — это не ноль и не пробел. Это значит, что запись не была сделана или что было добавлено явное значение NULL, что обычно обозначает, что значение либо не известно, либо не применимо.

 

Виды ограничений ссылочной целостности

Ограничения ключей

 

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

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

 

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

Ограничение PRIMARY KEY определяет один или несколько столбцов таблицы, которые образуют ключевое поле. Ключевое поле уникальным образом определяет строку таблицы и обеспечивает объектную целостность таблицы.

Первичный ключ - домен или несколько доменов таблицы, однозначно характеризующие запись согласно третьей нормальной форме Бойесса-Кода. Объявляется при помощи служебных слов PRIMARY KEY( < FIELD1 > [,<FIELDN >]), где < FIELD > - имя поля или имена полей, перечисленные через запятую. Первичный ключ также может быть задан при создании домена таблицы. Например:

ID INTEGER NOT NULL PRIMARY KEY,

....

);

 

или (рекомендуемый вариант, с указанием имени CONSTRAINT)

CREATE TABLE MY_TABLE(

ID INTEGER NOT NULL,

....

CONSTRAINT PK_MY_TABLE PRIMARY KEY (ID),

);

 

У таблицы может быть только один первичный ключ.

Первичный ключ также можно создать командойALTER TABLE

Внешний ключ

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

Ограничение FOREIGN KEY имеет параметр CASCADE, с помощью которого можно распространять любое изменение значения столбца, определяющего ограничение UNIQUE или PRIMARY KEY, в любые значения внешнего ключа, ссылающиеся на это значение. Такое действие называется каскадной ссылочной целостностью.

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

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

Пример:(рекомендуемый вариант, с указанием имени constraint)

СREATE TABLE MY_TABLE(

...,

CID INTEGER NOT NULL,

...,

CONSTRAINT FK_MY_TABLE_TABLE2 FOREIGN KEY (CID) REFERENCES TABLE2(ID))

КонструкцияREFERENCES <имя_мастер_таблицы> [<имя_поля>] используется дляограничения ссылочной целостности и определяет, что данный столбец является внешним ключом и указывает на ключ какой мастер_таблицы (родительской таблицы) он будет ссылаться.

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

Уникальный ключ

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

Другие ограничения

 

Ограничение DEFAULT вводит значение в столбец, если оно не указано в инструкции INSERT. Обеспечивают доменную целостность данных.

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

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

Правила допустимости нулевого значения в рамках определения таблицы: допустимость нулевого значения столбца определяет, будет ли нулевое значение (NULL) принято в столбец как данные. NULL — это не ноль и не пробел. Это значит, что запись не была сделана или что было добавлено явное значение NULL, что обычно обозначает, что значение либо не известно, либо не применимо.

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

· Числа - для хранения числовых переменных (int, tinyint, smallint, bigint, numeric, decimal, money, smallmoney, float, real).

· Даты - для хранения даты и времени (date, time datetime, smalldatetime).

· Символы- для хранения символьных данных (char, nchar, varchar, nvarchar).

· Двоичные - для хранения бинарных данных (binary, varbinary, bit).

· Большеобъемные - типы данных для хранения больших бинарных данных (text, ntext, image).

· Специальные - указатели (cursor), 16-байтовое шестнадцатиричное число, которое используется для GUID (uniqueidentifier), штамп изменения строки (timestamp), версия строки (rowversion), таблицы (table).

Типы данных определяют тип информации (символы, числа или даты), которые могут содержаться в столбце, а также способ хранения этих данных. Сервер SQL Server 2008 предоставляет большой набор определенных системных типов данных, объединенных по категориям.

Замечания.

· Для использования русских символов (не ASCII кодировки) используются типы данных с приставкой "n" (nchar, nvarchar, ntext), которые кодируют символы двумя байтами. Иначе говоря, для работы с Unicode используются типы данных с "n".

· Для данных переменной длины используются типы данных с приставкой "var". Типы данных без приставки "var" имеют фиксированную длину области памяти, неиспользованная часть которой заполняется пробелами или нулями.