15. Типы данных sql.

В языке SQL /89 поддерживаются следующие типы данных:

• CHARACTER ( n ) или CHAR ( n ) — символьные строки постоянной длины в п символов. При задании данного типа под каждое значение всегда отво дится п символов, и если реальное значение занимает менее, чем п символов, то СУБД автоматически дополняет недостающие символы пробелами.

• NUMERIC [( n , m )] — точные числа, здесь п — общее количество цифр в числе, m — количество цифр слева от десятичной точки.

• DECIMAL [( n , m )] — точные числа, здесь п — общее количество цифр в числе, m — количество цифр слева от десятичной точки.

• DEC [( n , m )] - то же, что и DECIMAL [( n , m )].

• INTEGER или INT — целые числа.

• SMALLINT — целые числа меньшего диапазона.

Несмотря на то, что в стандарте SQL 1 не определяется точно, что подразумевается под типом INT и SMALLINT (это отдано на откуп реализации), указано только соотношение между этими типами данных, в большинстве реализаций тип данных INTEGER соответствует целым числам, хранимым в четырех байтах, a SMALLINT — соответствует целым числам, хранимым в двух байтах. Вы бор одного из этих типов определяется размером числа.

• FLOAT [( n )] — числа большой точности, хранимые в форме с плавающей точкой. Здесь п — число байтов, резервируемое под хранение одного числа. Диа пазон чисел определяется конкретной реализацией.

• REAL — вещественный тип чисел, который соответствует числам с плавающей точкой, меньшей точности, чем FLOAT.

• DOUBLE PRECISION специфицирует тип данных с определенной в реализации точностью большей, чем определенная в реализации точность для REAL.

В стандарте SQL 92 добавлены следующие типы данных:

• VARCHAR ( n ) — строки символов переменной длины.

• NCHAR ( N ) — строки локализованных символов постоянной длины.

• NCHAR VARYING ( n ) — строки локализованных символов переменной длины.

• BIT ( n ) — строка битов постоянной длины.

• BIT VARYING ( n ) — строка битов переменной длины.

• DATE — календарная дата.

• ТIМЕSТАМР(точность) — дата и время.

• INTERVAL — временной интервал.

Большинство коммерческих СУБД поддерживают еще дополнительные типы данных, которые не специфицированы в стандарте. Так, например, практически все СУБД в том или ином виде поддерживают тип данных для представления не структурированного текста большого объёма. Этот тип аналогичен типу MEMO в настольных СУБД. Называются эти типы поразному, например в ORACLE этот тип называется LONG , в DB 2 - LONG VARCHAR , в SYBASE и MS SQL Server - TEXT.

Однако следует отметить, что специфика реализации отдельных типов данных серьезным образом влияет на результаты запросов к БД. Особенно это касается реализации типов данных DATE и ТШЁЗТАМР. Поэтому при переносе прило жений будьте внимательны, на разных платформах они могут работать по разному, и одной из причин может быть различие в интерпретации типов данных.

16. Системный анализ предметной области.

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

В общем случае существуют два подхода к выбору состава и структуры предметной области:

1. Функциональный подход — он реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая БД. В этом случае мы можем четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.

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

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

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