Типы данных

Поскольку в статье “БД и СУБД” 2 понятие данных определено не строго, договоримся об используемой терминологии (отметим, упомянутая статья, в свою очередь, ссылается на словарь школьной информатики А.П. Ершова). От данных мы будем требовать, чтобы они были атомарными, т.е. неделимыми. Любая совокупность таких неделимых данных уже является структурой. Разумеется, здесь также приходится договариваться о том, когда остановиться в желании и возможности что-то “поделить”. Например, строку можно поделить на символы, в этом смысле строка, безусловно, является структурой данных. Но если договориться не делить строку на символы, то можно считать ее атомарной. Соответствующие термины неразрывно связаны с важнейшим понятием “тип данных”.

Когда говорят о свойствах сущности (объекта) (см. “Реляционные БД” 2), явно или неявно имеют в виду, что каждое конкретное свойство (в таблице — поле записи) принимает значения из некоторого множества. Указанное множество и называется типом данных.

В программировании часто употребляют термины “простой” и “сложный” (“составной”) типы данных. В указанном выше смысле типы данных бывают только простыми, а сложные типы — уже структуры данных. Хотя это лишь вопрос терминологии, применительно к реляционным базам данных удобно придерживаться описанной системы понятий (в случае объектно-реляционных баз данных — см. статью “БД и СУБД” 2 — ситуация иная, но их мы здесь не рассматриваем). Подробнее о типах и структурах данных можно прочитать в соответствующих статьях (см. “Типы данных”, “Структуры данных” 2). В частности, в указанных статьях акцентируется внимание на том, что тип определяет и множество операций, которые можно выполнять над данными.

Все реляционные СУБД поддерживают данные следующих основных типов:

· числовые;

· строковые;

· логические;

· даты.

Приведенный список не является исчерпывающим. Как правило, СУБД также имеют типы для хранения больших текстовых и двоичных данных, специальные “денежные” типы и т.д. На следующем рисунке — снимке экрана конструктора таблиц Microsoft Access — показаны типы, поддерживаемые этой системой.

Отметим также, что, как правило, типы могут снабжаться модификаторами, уточняющими соответствующее множество данных (диапазон значений). Например, в Microsoft Access данные числового типа могут быть просто “целыми”, “длинными целыми”, “вещественными” и т.д. — см. рисунок.

Границу между типом и типом с модификатором удобнее проводить в рамках конкретной СУБД. Обычно считают, что данные, для описания которых используется одно ключевое слово на языке SQL, принадлежат одному типу, а те, которые описываются разными словами, — разным (см. пункт “Язык описания данных”).

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

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

· Определение имени таблицы. Если таблица является представлением некоторой сущности, то имя обычно соответствует названию сущности. Имена таблиц связей, как правило, образуют из названий связываемых сущностей.

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

· Определение первичного ключа. Несмотря на то, что реляционная модель требует наличия в каждой таблице первичного ключа, большинство СУБД позволяют не определять ключ в таблице. Этого, разумеется, следует избегать. К чести СУБД они практически всегда стараются “наставить разработчика на путь истинный” (см., например, рисунок).

· Определение (при необходимости) индексированных полей.

После конструирования таблиц необходимо установить связи между ними. В Microsoft Access для этого имеется специальное средство — “Схема данных”. На схеме очень удобно “рисовать” связи между таблицами, перетаскивая и накладывая друг на друга связанные поля. В большинстве случаев Access способен определить тип устанавливаемой связи. Например, если первичный ключ одной таблицы связывается с полем другой, не являющимся первичным ключом, то легко понять — и Access понимает, — что речь идет о связи “один ко многим”.

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