Типы данных. Любые данные, используемые в программировании, соответствуют определенным типам

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

Реляционная модель требует, чтобы типы используемых данных были простыми.

Простые, или атомарные, типы данных не обладают внутренней структурой. Данные такого типа называют скалярами. К простым типам данных относятся следующие типы:

· Логический

· Строковый

· Численный

Различные языки программирования могут расширять и уточнять этот список, добавляя такие типы как:

· Целый

· Вещественный

· Дата

· Время

· Денежный

· Перечислимый

· Интервальный

· И т. д.…

Пример. Личные данные в таблице СТУДЕНТ обычно представляются набором атрибутов, включающих, в частности, такие три как ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, а не единый ФИО. К такому решению разработчики приходят, принимая во внимание возможные запросы к БД, например, найти всех Татьян (к Татьяниному дню). Кроме того, у студента может измениться фамилия или отчество.

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

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

Замечание

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

Именно так в некоторых пост-реляционных (объектно-реляционных) СУБД реализована работа со сколь угодно сложными типами данных, создаваемых пользователями.

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

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

· Домен имеет уникальное имя (в пределах базы данных)

· Домен определен на некотором простом типе данных или на другом домене

· Домен может иметь некоторое логическое условие, позволяющее описать подмножество данных, допустимых для данного домена

· Домен несет определенную смысловую нагрузку

Пример 1. Поле ИМЯ таблицы СТУДЕНТ (атрибут ИМЯ отношения СТУДЕНТ) – простейший пример домена.

Пример 2. Домен , имеющий смысл " возраст сотрудника" можно описать как следующее подмножество множества натуральных чисел:

Если тип данных можно считать множеством всех возможных значений данного типа, то домен напоминает подмножество в этом множестве.

Отличие домена от понятия подмножества состоит именно в том, что домен отражает семантику (смысл), определенную предметной областью. Может быть несколько доменов, совпадающих как подмножества, но несущие различный смысл.

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

Замечания

1 Понятие домена помогает правильно моделировать предметную область.

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

Пример. Домен " Фамилия сотрудника" может содержать любую последовательность символов, кроме цифр, служебных символов, не должна начинаться с мягкого знака. Но ограничения на строку подобную «Йййййзззззвр» задать невозможно. Трудности такого рода возникают потому, что смысл реальных явлений далеко не всегда можно формально описать. Единственный выход из подобной ситуации - положиться на разум сотрудника, вводящего фамилии в БД.