2.7. Типы данных

Первоначально СУБД применялись преимущественно для решения финансово-экономических задач. При этом, независимо от модели представления, в базах данных использовались следующие основные типы данных:

• числовые. Примеры значений данных: 0.43, 328, 2Е+5;

• символьные (алфавитно-цифровые). Примеры значений данных: "пятница", "строка", "программист";

• даты, задаваемые с помощью специального типа "Дата" или как обычные символьные данные. Примеры значений данных: 1.12.97, 23/2/1999.

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

временные и дата-временные, предназначенные для хранения информации о времени и/или дате. Примеры значений данных: 31.01.85 (дата), 9:10:03 (время), 6.03.1960 12:00 (дата и время);

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

двоичные, предназначенные для хранения графических объектов, аудио- и видеоинформации, пространственной, хронологической и другой специальной информации. Например, в MS Access таким типом является тип данных "Поле объекта OLE", который позволяет хранить в БД графические данные в формате BMP (Bitmap) и автоматически их отображать при работе с БД;

гиперссылки (hyperlinks), предназначенные для хранения ссылок на различные ресурсы (узлы, файлы, документы и т. д.), находящиеся внебазы данных, например в сети Интернет, корпоративной сети интранет или на жестком диске компьютера. Примеры значений данных:

http:\\www.chat.ru,

ftp:\\chance4u.teens.com.

В современных СУБД с различными моделями данных могут использоваться все перечисленные типы данных.

[12, 19, 27 ]

2.8. Выбор моделей данных

Сравнение описанных выше моделей данных показывает, что ни одна из них не является идеальной и универсальной, т.е. ни одна из них не удовлетворяет полностью требованиям, предъявляемым к современным БД.

В связи с этим при разработке конкретных баз данных возникает проблема выбора модели данных и СУБД. Например, если взять лишь два критерия: быстродействие и удобство обновления, то по первому критерию следует предпочесть иерархическую МД, а по второму — реляционную.

На самом деле критериев значительно больше: стоимость, производительность, неизбыточность и т. д.

На выбор влияет и множество факторов: 1) типы элементов данных; 2) интерфейс пользователя; 3) структура и отношения данных; способы манипулирования данными; 4) целостность БД и защита данных; 5) поддержка программная и техническая; 6) коммерческая поддержка; 7) критерии качества (надежность, точность, соответствие промышленным стандартам); 8) возможности роста и развития.

Сюда следует добавить, что не все требования могут быть сформулированы одинаково четко, а одним и тем же требованиям могут соответствовать разные МД.

В силу сложности задачи выбора СУБД ее целесообразно решать в два этапа: выбор МД; выбор СУБД в рамках принятой МД.

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

Названные обстоятельства привели к широкому применению упрощенного варианта решения, в котором используются следующие суждения.

Для баз данных, реализуемых на суперЭВМ, иногда называемых мейнфреймами, самым важным требованием, предъявляемым к БД, является быстродействие. В силу этого предпочтительным является использование иерархической модели данных или ее разновидности — многомерной модели данных. По тем же причинам для хранилищ данных предпочтительна многомерная модель.

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

Объектно-ориентированные модели данных только начинают использовать в СНГ. В настоящее время фактически единственной СУБД такого класса является CACHE.

Объектно-реляционные СУБД используют преимущественно гибридную разновидность.

В этих условиях задача выбора СУБД (для ПК) для построения операционных БД сводится практически к выбору среди реляционных СУБД. Этот выбор в итоге определяется требованиями, предъявляемыми к БД и формулируемыми в техническом задании на разработку базы данных.

Сравнительные характеристики некоторых реляционных СУБД приведены в табл. 2.2.

Таблица 2.2

Сравнительная характеристика некоторых реляционных СУБД

Характеристика	Access	InterBase	FoxPro	Paradox
Предельный объем, Гбайт	1	10
Число полей	255	1000	255	255
Число индексов	32	65536	255	255
Длина поля, знаков	255	32	255	255
Длина строки, кбайт	2	64	64	4
Ссылочная целостность	Да	Нет	Да	Да
Режим клиент— сервер	Нет	Да	Нет	Нет

На окончательный выбор СУБД по-прежнему влияет много неформальных факторов. В связи с этим, по мнению ряда авторов, целесообразно, использовать [1] такую последовательность.

Выбрать СУБД, подходящие по их техническим характеристикам (прежде всего — по объему данных в разрабатываемой базе данных).

Из получившегося набора СУБД следует отобрать:

а)по категории конечного пользователя (непрограммист; имеющий квалификацию в программировании; программист; администратор БД);

б)по развитости (удобству) интерфейса СУБД;

в)по качеству средств разработки БД (гибкость и полнота процедуры создания интерфейса пользователя и реализации алгоритмаприложения, мощности языка программирования);

г)по качеству средств обеспечения целостности и защиты данных;

д)по характеристикам формирования распределенной БД и групповой работе с БД (прежде всего — режима клиент—сервер);

е)по поддержке стандартных интерфейсов связи с БД — через язык SQL и приложение ODBC;

ж)по видам блокировки данных;

к) по имиджу фирмы — разработчика СУБД.

В ряде случаев [1] используют понятие «производительность», т. е. быстродействие БД. Она предполагает оптимизацию процедуры запроса, которая проводится далеко не во всех СУБД.В частности, такая процедура реализована в СУБД FoxPro.

Для выбора по этому параметру необходимы данные испытаний по специальным тестам [1] (ТРС-А, ТРС-В, ТРС-С, TPC-D и ТРС-Е) с вычислением отношения цена/производительность. Производительность оценивается в количестве транзакций в секунду на стандартных операциях обновления (при одинаковых объемах данных). К сожалению, результаты такого тестирования публикуются редко.

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