пятница, 17 апреля 2009 г.

Проектирование базы данных

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

Выделим следующие объекты (таблицы) с их характеристиками (атрибутами), также укажем требования к атрибутам.
Заказчики:
• код заказчика – обязательный атрибут;
• наименование (название организации или фамилия, имя, отчество) – обязательный атрибут;
• город – необязательный атрибут;
• адрес – необязательный атрибут;
• телефон – необязательный атрибут, задается в формате (00000) 00-00-00.
Сотрудники:
• код сотрудника – обязательный атрибут;
• фамилия, имя, отчество – обязательные атрибуты;
• дата рождения – обязательный атрибут, не может быть больше сегодняшней даты и меньше 1900 года;
• домашний адрес – необязательный атрибут, если не указан, то по умолчанию устанавливается значение ‘unknown’;
• телефон – необязательный атрибут, либо задается в формате 00-00-00, либо при его отсутствии по умолчанию указывается ‘no’.
• дата найма – обязательный атрибут, не может быть больше даты сегодняшнего дня и меньше даты рождения, по умолчанию устанавливается сегодняшняя дата;
• стаж – вычисляемое поле, определяется разницей между сегодняшней датой и датой найма.
Заказы:
• номер заказа – обязательный атрибут;
• наименование заказа – обязательный атрибут;
• дата заказа – обязательный атрибут, не может быть больше сегодняшней даты и меньше 1900 года;
• дата выполнения – необязательный атрибут, не может быть меньше даты заказа.

Договоримся о следующих ограничениях (связях):
• заказчик может сделать любое количество заказов;
• каждый заказ сделан только одним заказчиком;
• сотрудник может участвовать в выполнении нескольких заказов.
• в выполнении одного заказа может участвовать несколько сотрудников.
Физическая модель
При переходе от логической модели к физической необходимо обеспечить целостность данных, под которой понимается согласованность и точность информации в базе данных. Поэтому, прежде чем рассмотреть непосредственно создание таблиц БД, рассмотрим средства обеспечения целостности данных.
Обеспечение целостности данных
Существует общие и специфические правила целостности (первые два – общие):
Целостность объектов: требует наличия в каждой таблице первичного ключа, значения которого не должны быть пустыми.
Ссылочная целостность: гарантирует поддержание постоянной связи между первичным ключом и внешним ключом.
Целостность области значений: определяет набор допустимых для поля значений, в том числе и допустимость значений NULL.
Целостность данных может быть обеспечена двумя способами:
1. Декларативным. Критерии, которым должны удовлетворять данные, задаются при определении объекта и являются частью определения базы данных.
Преимущества: Контроль целостности выполняется автоматически SQL-Server.
2. Процедурным. Критерии описываются в пакетах операторов, выполнение которых и определяет целостность данных.
Преимущества: Реализуется как на клиенте, так и на сервере с помощью различных программных средств.

Декларативная целостность реализуется при помощи ограничений, которые являются наиболее рекомендуемыми для обеспечения целостности данных. Различные типы целостности обеспечивается соответствующими ограничениями:
• PRIMARY KEY – определение поля или группы полей в качестве первичного ключа, т.е. позволяет уникально идентифицировать каждую запись таблицы, в этом случае недопустимы повторяющиеся и неопределенные (NULL) значения.
• FOREIGN KEY – определение поля или группы полей в качестве внешнего ключа, т.е. позволяет устанавливать ссылку на первичный ключ другой таблицы, содержащий идентичные данные. Данные в этом поле могут принимать значения, определенные в соответствующем первичном ключе, либо значения NULL.
• UNIQUE – определяет уникальность данных в некотором поле таблицы, причем данное ограничение допускает значения NULL. В одной таблице разрешено применение несколько таких ограничений, поля с таким ограничением могут быть использованы в качестве внешних ключей.
• DEFAULT – указывает значение поля по умолчанию, если значение явно не указано при вставке данных. Для каждого поля можно применить только одно такое ограничение.
• CHECK – накладывает ограничение на значение поля в виде логического выражения, что позволяет определить диапазон допустимых значений поля. Причем данное ограничение позволяет ссылаться на значения других полей.

Создание таблиц
Таблица базы данных может быть создана либо средствами Transact-SQL, либо с помощью специальных интерфейсных средств. Так же, как и для создания базы данных, рассмотрим сначала синтаксис создания таблиц на T-SQL.
Создание новой таблицы в базе данных командой CREATE TABLE:

CREATE TABLE имя_таблицы
( имя_поля тип-данных
[ { [ DEFAULT выражение ] | [ IDENTITY [ (начальное_значение, шаг) ] ] } ]
[ ROWGUIDCOL ]
[ { NULL | NOT NULL } ]
[ CONSTRAINT [ имя_ограничения ]
{ CHEСK (логическое_выражение)
| PRIMARY KEY (имя_поля [, …n])
| UNIQUE (имя_поля [, …n])
| FOREIGN KEY REFERENCES имя_ссылочной_таблицы (ссылочное_поле)
[ ON UPDATE { NO ACTION | CASCADE } ]
[ ON DELETE { NO ACTION | CASCADE } ] } ]
[ ,…n ]
[ , имя_вычисляемого_поля AS выражение ] )
[ ON { файловая_группа | DEFAULT } ]
[ TEXTIMAGE_ON { файловая_группа | DEFAULT } ]

Имена полей должны быть уникальны в пределах одной таблицы и удовлетворять правилам именования объектов базы данных.
DEFAULT – значение по умолчанию (см. выше, в списке ограничений).
IDENTITY – предписывает осуществлять заполнение поля автоматически, для этого указывается начальное значение и шаг приращения. При этом значения поля не могут быть изменены, как и не допустимы значения NULL. В таблице может быть только одно поле с таким ограничением, имеющее либо целый, либо десятичный тип данных.
ROWGUIDCOL – указывает, что это поле будет использовано для хранения глобального идентификационного номера (GUID). В этом случае для поля должен быть обязательно определен тип Uniqueidentifier, а функция NewID() определенная в ограничении DEFAULT позволит сгенерировать новое значение уникального идентификатора.
NULL | NOT NULL – разрешает или запрещает соответственно использование в данном поле неопределенных значений.
CONSTRAINT – с этого ключевого слова должно начинаться наложение ограничения на поле. После CONSTRAINT указывается имя ограничения, если оно явно не указывается, то генерируется системой автоматически и является при этом неосмысленным. Поэтому лучше самим давать ограничениям осмысленные имена. Далее указывается необходимый тип ограничения (они описаны выше, в списке ограничений). В процессе определения поля на него может быть наложено только одно ограничение. Если требуется установить несколько разных типов ограничений, необходимо определять их в процессе изменения структуры таблицы (см. далее).
FOREIGN KEY – определение внешнего ключа (см. выше), после REFERENCES указывается имя и поле таблицы, на которую идет ссылка. ON UPDATE и ON DELETE – задание правил внешнего ключа при обновлении и удалении объекта ссылки. При этом NO ACTION – отмена (задается по умолчанию), CASCADE – каскадирование.
имя_вычисляемого_поля AS выражение – эта конструкция позволяет создавать вычисляемые (виртуальные) поля, значения которых вычисляются с использованием функций, констант и других полей таблицы. На хранение значений таких полей не требуется физической памяти.
ON – это ключевое слово указывает файловую группу, в которой будет располагаться таблица. Если данное значение не указано, то таблица располагается в файловой группе определенной по умолчанию. Для полей типа text и image может быть также указана другая файловая группа.


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

CREATE TABLE Students
(StudentID int
IDENTITY (1,1)
CONSTRAINT prkStudentID PRIMARY KEY,
LastName char(20) NULL,
FirstName char(20) NULL,
BirthDate datetime NULL
CONSTRAINT bdChek CHECK (BirthDate)

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