2. Пользовательский тип данных
Пользовательский тип данных отличается от всех базовых типов тем, что он не был изначально вшит в систему управления базами данных, он не был описан как тип данных по умолчанию. Этот тип может создать для себя любой пользователь и программист баз данных в соответствии с собственными запросами и требованиями.
Таким образом, пользовательский тип данных – это подтип некоторого базового типа, т. е. это базовый тип с некоторыми ограничениями множества допустимых значений.
В записи на псевдокоде, пользовательский тип данных создается с помощью следующего стандартного оператора:
Create subtype имя подтипа
Type имя базового типа
As ограничение подтипа;
Итак, в первой строчке мы должны указать имя нашего нового, пользовательского типа данных, во второй – какой из имеющихся базовых типов данных мы взяли за образец, создавая собственный, и, наконец, в третьей – те ограничения, которые нам необходимо добавить в уже имеющиеся ограничения множества значений базового типа данных – образца. Ограничения подтипа записываются как условие, зависящее от имени определяемого подтипа.
Чтобы лучше понять принцип действия оператора Create, рассмотрим следующий пример. Пусть нам необходимо создать свой специализированный тип данных, допустим, для работы на почте. Это будет тип для работы с данными вида чисел почтового индекса. От обычных десятичных шестизначных чисел наши числа будут отличаться тем, что они могут быть только положительными. Запишем оператор, для создания нужного нам подтипа:
Create subtype Почтовый индекс
Type decimal (6, 0)
As Почтовый индекс > 0.
Почему мы взяли именно decimal (6, 0)? Вспоминая обычный вид индекса, мы видим, что такие числа должны состоять из шести целых чисел от нуля до девяти. Именно поэтому мы и взяли в качестве базового типа данных – десятичный тип.
Любопытно заметить, что в общем случае условие, накладываемое на базовый тип данных, т. е. ограничение подтипа, может содержать логические связки not, and, or и вообще быть выражением любой произвольной сложности. Определенные таким образом пользовательские подтипы данных могут беспрепятственно использоваться наряду с другими базовыми типами данных и в программном коде, и при определении типов данных в столбцах таблицы, т. е. базовые типы данных и пользовательские при работе с ними совершенно равноправны. В визуальной среде разработки они появляются в списках допустимых типов вместе с другими базовыми типами данных.
Вероятность того, что нам при проектировании новой собственной базы данных может понадобиться недокументированный (пользовательский) тип данных, достаточно велика. Ведь по умолчанию в систему управления базами данных вшиты только самые общие типы данных, пригодные соответственно для решения самых общих задач. При составлении предметных баз данных без проектирования собственных типов данных обойтись практически невозможно. Но, что любопытно, с равной вероятностью нам может понадобиться и удалить созданный нами подтип, чтобы не загромождать и не усложнять код. Для этого в системах управления базами данных обычно встроен специальный оператор drop, что и означает «удалить». Общий вид этот оператор удаления ненужных пользовательских типов имеет следующий:
Drop subtype имя пользовательского типа;
Пользовательские типы данных, как правило, рекомендуется вводить для подтипов достаточно общего назначения.
3. Значения по умолчанию
Системы управления базами данных могут иметь возможность создания любых произвольных значений по умолчанию или, как их еще называют, умолчаний. Эта операция в любой среде программирования имеет достаточно большой вес, ведь практически в любой задаче может возникнуть необходимость введения констант, неизменяемых значений по умолчанию.
Для создания умолчания в системах управления базами данных используется уже знакомая нам по прохождению пользовательского типа данных функция Create. Только в случае создания значения по умолчанию используется также дополнительное ключевое слово default, которое и означает «умолчание». Другими словами, чтобы создать в имеющейся базе данных значение по умолчанию, необходимо использовать следующий оператор:
Create default имя умолчания
As константное выражение;
Понятно, что на месте константного значения при применении этого оператора нужно написать значение или выражение, которое мы хотим сделать значением или выражением по умолчанию. И, разумеется, надо решить, под каким именем нам будет удобно его использовать в нашей базе данных, и записать это имя в первую строчку оператора.
Необходимо заметить, что в данном конкретном случае этот оператор Create отвечает синтаксису языка Transact-SQL, встроенному в систему Microsoft SQL Server.
Итак, что мы получили? Мы вывели, что умолчание представляет собой именованную константу, сохраняемую в базах данных, как и ее объект. В визуальной среде разработки умолчания появляются в списке выделенных значений по умолчанию.
Приведем пример создания умолчания. Пусть для правильной работы нашей базы данных необходимо, чтобы в ней функционировало значение со смыслом неограниченного срока действия чего-либо. Тогда нужно ввести в список значений этой базы данных значение по умолчанию, отвечающему данному требованию. Это может быть необходимо хотя бы потому, что каждый раз при встрече в тексте кода с этим довольно громоздким выражением будет крайне неудобно выписывать его заново. Именно поэтому воспользуемся означенным выше оператором Create для создания умолчания, со смыслом неограниченного срока действия чего-либо.
Create default «срок не ограничен»
As ‘9999-12-31 23: 59:59’
Здесь также был использован синтаксис языка Transact-SQL, согласно которому значения констант типа «дата – время» (в данном случае, ‘9999-12-31 23: 59:59’) записываются как строки символов определенного направления. Интерпретация строк символов как значений типа «дата – время» определяется контекстом использования этих строк. Например, в нашем конкретном случае, сначала в константной строчке записано предельное значение года, а потом времени.
Однако при всей своей полезности умолчания, как и пользовательский тип данных, иногда тоже могут требовать того, чтобы их удалили. В системы управления базами данных обычно есть специальный встроенный предикат, аналогичный оператору, удаляющему ненужный более пользовательский тип данных. Это предикат Drop и сам оператор выглядят следующим образом:
Drop default имя умолчания;
4. Виртуальные атрибуты
Все атрибуты в системах управления базами данных делятся (по абсолютной аналогии с отношениями) на базовые и виртуальные. Так называемые базовые атрибуты – это хранимые атрибуты, которые необходимо использовать не один раз, а следовательно, целесообразно сохранить. А, в свою очередь, виртуальные атрибуты – это не хранимые, а вычисляемые атрибуты. Что это значит? Это значит, что значения так называемых виртуальных атрибутов реально не хранятся, а вычисляются через базовые атрибуты на ходу посредством задаваемых формул. При этом домены вычисляемых виртуальных атрибутов определяются автоматически.
Приведем пример таблицы, задающей отношение, в которой два атрибута – обычные, базовые, а третий атрибут – виртуальный. Он будет вычисляться по специально введенной формуле.
ключевым атрибутом является атрибут «№ зачетной книжки», потому что у различных студентов не может быть одинакового номера зачетной книжки, т. е. для этого атрибута выполняется ограничение уникальности.
Интересно, что в схеме любого отношения могут встретиться самые разные ключи. Перечислим основные виды ключей:
1) простой ключ – это ключ, состоящий из одного и не более атрибута.
Например, в экзаменационной ведомости по конкретному предмету простым ключом является номер зачетки, потому что по нему можно однозначно идентифицировать любого студента;
2) составной ключ – это ключ, состоящий из двух и более атрибутов. Например, составным ключом в списке учебных аудиторий являются номер корпуса и номер аудитории. Ведь каким-то одним из этих атрибутов однозначно определить каждую аудиторию не представляется возможным, а их совокупностью, т. е. составным ключом, это сделать довольно легко;
3) суперключ – это любое надмножество любого ключа. Следовательно, сама схема отношения заведомо является суперключом. Из этого можно сделать вывод, что любое отношение теоретически имеет, как минимум, один ключ, а может иметь их и несколько. Однако объявление суперключа вместо обычного ключа логически недопустимо, так как связано с ослаблением автоматически контролируемого ограничения уникальности. Ведь супер ключ хоть и обладает свойством уникальности, но не обладает свойством неизбыточности;
4) первичный ключ – это просто ключ, который при задании базового отношения был объявлен первым. Важно, что допустимо объявление одного и только одного первичного ключа. Кроме того, атрибуты первичного ключа ни в коем случае не могут принимать Null-значений.
При создании базового отношения в записи на псевдокоде первичный ключ обозначается primary key и в скобках указывается имя атрибута, который и является этим ключом;
5) кандидатные ключи – это все остальные ключи, объявленные после первичного ключа.
В чем заключаются основные отличия кандидатных ключей от ключей первичных? Во-первых, кандидатных ключей может быть несколько, тогда как первичный ключ, как было сказано выше, может быть только один. И, во-вторых, если атрибуты первичного ключа не могут принимать Null-значений, то на атрибуты кандидатных ключей это условие не накладывается.
На псевдокоде при задании базового отношения кандидатные ключи объявляются при помощи слов candidate key и в скобках рядом, как и в случае объявления первичного ключа, указывается имя атрибута, который и является данным кандидатным ключом;