Капралов Е.Г., Кошкарев А.В., Тикунов В.С. и др. Геоинформатика

Подождите немного. Документ загружается.

не имеет пространственного характера, хотя некоторая

ее

часть

может быть связана

пространственной природой изучаемого

объекта, например, площадь, периметр.

В качестве атрибутивной информации часто выступает время

(временная форма), которое может отражаться несколькими спо-

собами: указанием временного периода существования объектов,

соотнесением информации

определенными моментами време-

ни,

указанием скорости движения объектов.

Количественные атрибуты создаются

соответствии

номи-

нальными, порядковыми, интервальными

или

пропорциональны-

ми шкалами измерений. Важно знать, какие шкалы измерений

использованы для данных, поскольку

это

определяет характер воз-

можных математических операций

ними.

Как упоминалось ранее, составляющие пространственных дан-

ных кратко называют геометрией

атрибутами.

Представление точенных, линейных

площадных объектов

базе

данных

и на

цифровой карте.

В БД ГИС

картографические источ-

ники

итоговые карты представляются

виде цифровых карт

(см.

2.1.3)

[Геоинформатика,

1999].

Любая

БД

состоит

из

цифровых представлений дискретных

объектов. Содержание карты можно хранить

в БД в

виде цифровой

карты, превратив объекты карты

объекты базы данных. Правда,

всегда нужно помнить

том,

что

многое

из

показанного

на

картах

умозрительно

не

представлено

реальном мире: горизонтали

природе

не

существуют,

вот дома

озера —

это

реальные объек-

ты.

Итак, географические объекты, моделируемые

помощью карты

или

ГИС,

имеют

три

формы представления:

• объект

действительности;

• объект, представленный

базе данных (некоторые авторы вво-

дят

для

таких объектов наименование «предмет»):

• знак, который используется

для

показа объекта (предмета)

на

карте

или на

другом графическом изображении.

Мы будем

во

всех случаях использовать наименование «объект»,

поскольку

о чем

идет речь, обычно понятно

из

контекста.

Предназначенный

для

отражения

в БД или

цифровой карте

объект —

это

явление действительности, последнее

ряду подраз-

деления однотипных явлений

при

выборе «элементарных кирпи-

чиков»

для

информационного моделирования [А. В. Кошкарев,

2000];

например, город можно считать объектом,

при его

подраз-

делении

на

составные части

они уже

будут

не

городами,

райо-

нами, кварталами

и т.п.

Объект

в БД

—

это

цифровое представление всего реального

объекта

или его

части. Способ цифрового представления объекта

зависит

от

назначения

ГИС,

масштаба исследования,

его

задач

других факторов, например, географически город может быть пред-

ставлен

виде точки, если рассматриваемая территория имеет

масштабы материка; если речь идет

базе географических данных

области,

тот же

город может быть представлен ареалом.

Сходные явления, информация

которых хранится

базе дан-

ных, определяются

как

типы объектов

—

любая группа сходных

явлений, которые должны иметь одинаковую форму хранения

представления, например дороги, реки, высоты, растительность;

тем самым обеспечивается основа

для

формирования общего

ат-

рибута явлений. Каждый тип объектов должен быть точно опреде-

лен,

что

помогает выявить перекрывающиеся категории данных

вносит ясность

содержание базы данных.

Основные элементы базы данных.

Для

цифрового представле-

ния типов реальных объектов необходимо выбрать подходящую

форму объектов, являющихся представителями первых (кодами)

в базе пространственных данных.

Их

классификация может быть

основана

на

представлении пространственной размерности

(см.

2.1.2).

Такие объекты хорошо отражают тип пространственной лока-

лизации реальных объектов. Они могут быть объединены

классы,

например множество точек

для

представления множества горо-

дов.

Пространственные типы объектов

БД

могут группироваться

слои,

именуемые также покрытиями или темами. Один слой пред-

ставляет один тип объектов или группу концептуально взаимосвя-

занных типов объектов. Например, слой может включать только

отрезки водотоков,

или же

водотоки, озера, береговую линию

болота. Возможны самые разные варианты системы слоев,

как и

модели данных. Некоторые базы пространственных данных созда-

ются путем объединения всех объектов

один слой.

Одни

те же географические явления можно представить

раз-

ных масштабах

и с

разной точностью. Переход от одного представ-

ления к другому достаточно сложен, например переход

от

мелкого

масштаба

(1:250000) к

крупному

(1:10000).

Поэтому часто встре-

чаются базы данных, содержащие множественные представления

одних

тех

же

явлений.

Это

неэкономно,

но

избежать этого пока

не удается,

ибо

соответствующие методы перехода

еще

недоста-

точно разработаны.

Системы управления базами данных

ГИС.

Как

правило,

ГИС

создаются

на

основе уже существующих систем управления базами

данных (СУБД), приобретение

или

аренда СУБД составляет

ос-

новную часть затрат

на

программное обеспечение системы. СУБД

выполняет множество функций, которые

противном случае сле-

довало бы программировать

ГИС. Различают два пути использо-

вания СУБД

ГИС:

1) выполнение ГИС-процедур полностью через СУБД, тогда

доступ

ко

всем данным осуществляется только через СУБД

и все

данные должны удовлетворять требованиям, заложенным при ее

разработке;

2) некоторые данные (обычно таблицы атрибутов и их отноше-

ний) доступны через СУБД, поскольку они вполне соответствуют

модели, а к некоторым данным (обычно пространственно локали-

зованным) доступ прямой, так как они не удовлетворяют требо-

ваниям модели СУБД.

ГИС добавляет географический аспект к уже существующим

методам поиска и запроса. Сложность и разнообразие представле-

ния данных в ГИС, различимость в представлении позиционной и

атрибутивной составляющей информации, необходимость ее об-

работки в контексте пространственной близости предъявляют свое-

образные и повышенные требования к СУБД по сравнению с тра-

диционной формой их использования.

Функции

СУБД.

Каждую СУБД принято характеризовать спо-

собностью выполнять следующие основные функции [К. Дейт, 1980;

Дж. Ульман,

1983]:

• управление данными во внешней памяти;

• управление буферами оперативной памяти;

• операции над БД;

• обеспечение надежности хранения данных в БД;

• поддержка языка управления БД.

Управление данными во внешней памяти. Эта функция обеспе-

чивает организацию структуры внешней памяти как для хранения

данных, входящих в БД, так и для служебных целей, например,

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

возможности файловых систем, в других работа производится на

уровне функционирования устройств внешней памяти. В любом

случае пользователи СУБД не обязаны знать, какая структура ис-

пользуется или как организованы файлы. Обычно в СУБД создает-

ся собственная система наименования объектов БД.

Управление буферами оперативной памяти. СУБД обычно рабо-

тают с БД значительного размера, существенно большего доступ-

ного объема оперативной памяти. Для того чтобы СУБД не зависе-

ла от скорости работы устройств внешней памяти, используется

организация собственных наборов буферов оперативной памяти с

определенными правилами замены и обновления буферов.

Операции над БД. Последовательность операций над БД, рас-

сматриваемых СУБД как единое целое, называется транзакцией.

При выполнении транзакции СУБД либо фиксирует во внешней

памяти изменения в БД, произведенные этой транзакцией, либо

не производит никаких изменений. Понятие транзакции важно для

сохранения логической целостности БД, особенно в многополь-

зовательских СУБД. Каждая транзакция начинается при целост-

ном состоянии БД и оставляет это состояние целостным после

своего завершения. При эффективном управлении параллельно вы-

полняюшимися транзакциями со стороны СУБД каждый из пользо-

вателей может ощущать себя единственным ее пользователем.

Управление транзакциями в многопользовательской СУБД осу-

ществляется с помощью специальных операций, которые объеди-

няют транзакции одного пользователя в серии (сериализация тран-

закций), при этом суммарный эффект смеси транзакций эквива-

лентен эффекту их последовательного выполнения. Существует

несколько базовых алгоритмов сериализации транзакций, среди

которых наиболее распространены алгоритмы, основанные на син-

хронизационных захватах объектов БД.

Обеспечение надежности хранения данных в БД. Одним из ос-

новных требований к СУБД является надежность хранения данных

во внешней памяти, т.е. СУБД должна обладать способностью вос-

становления последнего согласованного состояния БД после лю-

бого аппаратного или программного сбоя. Возможны два вида ап-

паратных сбоев: «мягкие» сбои, которые приводят к внезапной

остановке работы компьютера (например, аварийное выключение

питания), и «жесткие» сбои, характеризуемые потерей информа-

ции на носителях внешней памяти. Программные сбои — это ава-

рийное завершение работы СУБД или аварийное завершение

пользовательской программы, в результате чего некоторая транз-

акция остается незавершенной. Для восстановления БД нужно рас-

полагать некоторой дополнительной информацией, что требует

избыточности хранения данных. Наиболее распространенным ме-

тодом поддержания такой избыточной информации является ве-

дение журнала изменений БД.

Журнал — это особая часть БД, недоступная пользователям

СУБД и поддерживаемая с особой тщательностью (иногда под-

держиваются две копии журнала, располагаемые на разных физи-

ческих дисках), в которую поступают записи обо всех изменениях

основной части БД. Самая простая процедура обеспечения надеж-

ности восстановления БД — откат транзакции, выполненной

пользователем, для чего все записи от одной транзакции связыва-

ют обратным списком от конца к началу (аналог

Undo).

При «мягком» сбое во внешней памяти основной части БД мо-

гут находиться объекты, модифицированные транзакциями, не

закончившимися к моменту сбоя, и могут отсутствовать объекты,

модифицированные транзакциями, которые к моменту сбоя ус-

пешно завершились (по причине использования буферов опера-

тивной памяти, содержимое которых при «мягком» сбое пропада-

ет).

В таком случае во внешней памяти журнала должны обязатель-

но находиться записи, относящиеся к операциям модификации

обоих видов объектов. Для восстановления БД после жесткого сбоя

используют журнал и архивную копию БД.

Поддержка языков управления БД. Для работы с базами данных

используются специальные языки, называемые языками баз дан-

ных. Первоначально

СУБД поддерживалось несколько специали-

зированных

по

функциям языков.

современных СУБД обычно

поддерживается единый интегрированный язык, содержащий

все

необходимые средства

для

работы

с БД,

начиная

от ее

создания,

обеспечивающий базовый пользовательский интерфейс

базами

данных. Стандартным языком наиболее распространенных

в на-

стоящее время реляционных СУБД является язык

SQL (Structured

Query Language).

Язык

SQL

позволяет определять схему реляцион-

ной

БД и

манипулировать данными.

При

этом именование объек-

тов

БД

(таблиц

и их

столбцов) поддерживается

на

языковом уров-

не

в том

смысле,

что

компилятор языка

SQL

производит преобра-

зование имен объектов

в их

внутренние идентификаторы

на

осно-

вании специально поддерживаемых служебных таблиц-каталогов.

Внутренняя часть СУБД (ядро) вообще

не

работает

именами

таблиц

и их

столбцов.

Язык

SQL

содержит специальные средства определения огра-

ничений целостности

БД,

которые тоже хранятся

специальных

таблицах-каталогах. Обеспечение контроля целостности

БД

произ-

водится

на

языковом уровне. Компилятор

SQL

для операторов

мо-

дификации

БД на

основании имеющихся

в БД

ограничений цело-

стности генерирует соответствующий программный

код.

Специальные операторы языка

SQL

позволяют определять

так

называемые представления

БД,

фактически являющиеся храни-

мыми

в БД

запросами (результатом любого запроса

реляцион-

ной

БД

является таблица)

именованными столбцами.

Для

пользо-

вателя представление является такой

же

таблицей,

как

любая

ба-

зовая таблица, хранимая

в БД, но с

помощью представлений можно

ограничить

или

наоборот расширить «видимость»

БД для

конкрет-

ного пользователя. Поддержание представлений производится так-

же

на

языковом уровне.

Наконец, авторизация доступа

объектам

БД

производится

также

на

основе специального набора операторов

SQL.

Идея

со-

стоит

в том, что для

выполнения операторов

SQL

разного вида

пользователь должен обладать различными правами доступа

к БД.

Пользователь, создавший таблицу

БД,

обладает полным набором

прав

для

работы

этой таблицей,

в том

числе правом разрешения

доступа другим пользователям. Контроль прав доступа поддержи-

вается

на

уровне языка.

Типовая организация

СУБД.

Организация типичной СУБД

состав

ее

компонентов соответствуют рассмотренному набору фун-

кций. СУБД представляет собой

три

взаимосвязанные компонен-

ты:

командный язык

для

выполнения требуемых операций

дан-

ными (ввод, вывод, модификация), интерпретирующую систему

(или компилятор)

для

обработки команд

перевода

их на

язык

машины, интерфейс пользователя

для

формирования запросов

БД (выборки нужных данных).

Логически в реляционной СУБД можно выделить:

• внутреннюю часть — ядро СУБД (часто его называют

Data

Base

Engine);

• компилятор языка БД (обычно SQL);

• подсистему поддержки времени выполнения;

• набор утилит.

В некоторых системах эти части выделяются явно, в других —

нет, но логически такое разделение можно провести во всех СУБД.

Ядро СУБД отвечает за управление: данными во внешней па-

мяти, буферами оперативной памяти, транзакциями, а также за

ведение журнала. Компоненты ядра

—•

это соответственно менед-

жер данных, менеджер буферов, менеджер транзакций и менед-

жер журнала. Для обеспечения корректной работы СУБД все эти

компоненты должны взаимодействовать по тщательно организо-

ванным протоколам. Ядро СУБД является основной резидентной

частью СУБД, а в архитектуре «клиент-сервер» — основной со-

ставляющей серверной части системы.

Основной функцией компилятора языка БД является перевод

операторов языка БД в некоторую выполняемую программу. Ре-

зультатом компиляции является выполняемая программа, пред-

ставляемая в некоторых системах в машинных кодах, но более ча-

сто во внутреннем машинно-независимом коде.

В отдельные утилиты БД обычно выделяют такие процедуры,

которые слишком накладно выполнять с использованием языка

БД, например загрузка и выгрузка БД, сбор статистики, глобаль-

ная проверка целостности БД и т.д. Утилиты программируются с

использованием интерфейса ядра СУБД.

К числу достоинств реляционного подхода можно отнести:

• наличие небольшого набора приемов для простого абстракт-

ного представления объектов большинства распространенных об-

ластей применения БД с интуитивно понятными и достаточно

точными формальными определениями;

• наличие простого математического аппарата, опирающегося

на теорию множеств и математическую логику, обеспечивающего

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

• возможность манипулирования данными без необходимости

знания конкретной физической организации баз данных во внеш-

ней памяти.

Отмеченные преимущества и постепенное накопление мето-

дов и алгоритмов организации реляционных баз данных и управ-

ления ими привели к тому, что в середине 80-х годов XX в. реля-

ционные системы практически вытеснили с мирового рынка ран-

ние СУБД.

К недостаткам реляционных СУБД относятся некоторая огра-

ниченность (как следствие простоты) их использования при слож-

ных структурах данных, в том числе пространственно-определен-

ных данных разных моделей, а также невозможность адекватного

отражения семантики предметной области. .*

Базовые понятия реляционных баз данных. В преобладающем

большинстве ГИС используются реляционные базы данных, под-

держиваемые такими СУБД, как

dBase,

INFO, ORACLE,

INFORMIX и т. п. Такие БД позволяют разработчикам ГИС разде-

лить проблему управления пространственными данными на две

части: как представлять геометрию объектов и топологию простран-

ственных объектов (вектор или растр) и как работать с атрибута-

ми этих объектов. Для этого пригодны реляционные СУБД, управ-*

ляемые ими модели данных иногда называют геореляционными

моделями. Основные их преимущества таковы:

• нет необходимости хранить атрибуты с пространственными

данными, но они всегда могут содержаться где-нибудь в системе

или поставляться, например, по сети;

• атрибуты могут быть изменены или удалены без изменения

пространственной БД;

• коммерческие реляционные СУБД стандартны и могут управ-

ляться стандартными запросами;

• хранение атрибутивных данных в реляционных БД не проти-

воречит основным принципам слоев в ГИС;

• атрибуты могут быть привязаны к пространственным едини-

цам и представлены разными способами.

Основными понятиями реляционных баз данных являются: тип

данных, домен, атрибут, кортеж, первичный ключ и отношение.

Понятие тип данных полностью адекватно понятию типа дан-

ных в языках программирования. Обычно в реляционных БД до-

пускается хранение символьных, числовых данных, битовых строк,

специализированных числовых данных (таких, как «деньги»), а так-

же специальных данных — дата, время, временной интервал. Раз-

вивается подход к расширению возможностей реляционных сис-

тем абстрактными типами данных.

Понятие домен имеет некоторые аналогии с подтипами в не-

которых языках программирования. В самом общем виде домен

определяется заданием некоторого базового типа данных, к кото-

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

выражения, применяемого к элементу типа данных. Если вычис-

ление этого логического выражения дает результат «истина», то

элемент данных является элементом домена. Наиболее правильное

интуитивное понимание домена — допустимое множество значе-

ний определенного типа. Данные считаются сравнимыми только в

том случае, когда они относятся к одному домену.

Отношение — это именованное множество пар {имя атрибута,

имя домена (или

типа)}.

Если все атрибуты одного отношения оп-

ределены на разных доменах, целесообразно использовать для наи-

менования атрибутов имена соответствующих доменов.

Кортеж, соответствующий данной схеме отношения, — это на-

бор именованных значений заданного типа.

Обычным представлением отношения является таблица, в за-

головке которой указывают наименование отношения, а в стро-

ках — кортежи; в этом случае имена атрибутов именуют столбцы

таблицы. Поэтому когда говорят «столбец таблицы», имеют в виду

«атрибут отношения». Такой терминологии придерживаются в боль-

шинстве коммерческих реляционных СУБД.

Реляционная модель данных. Модель данных с точки зрения СУБД

описывает некоторый набор родовых понятий и признаков, кото-

рыми должны обладать сама СУБД и управляемые ею базы дан-

ных, если они основываются на этой модели. Наличие модели дан-

ных позволяет сравнивать конкретные реализации, используя один

общий язык.

Реляционная модель состоит из трех частей, описывающих раз-

ные аспекты реляционного подхода: структурной, манипуляцион-

ной и целостной.

В структурной части модели фиксируется, что единственной

структурой данных, используемой в реляционных БД, является

нормализованное отношение — некоторый определенный набор

ограничений, свойственный этому отношению. Нормализация свя-

зана с поиском наиболее простой структуры для данного множе-

ства данных и имеет дело с зависимостью между атрибутами; она

позволяет избежать потери общей информации при удалении или

вводе записей. Существует несколько формальных типов нормали-

зации (более пяти).

Манипуляционная часть модели определяет механизм манипу-

лирования реляционными БД — реляционная алгебра и реляци-

онное исчисление, базирующиеся на теории множеств и логиче-

ском аппарате исчисления отношений.

В целостной части реляционной модели данных фиксируются

два базовых требования целостности: целостности сущностей и

целостности по ссылкам. Объекту, или сущности, реального мира

в реляционных БД соответствуют записи (кортежи) отношений, и

требование целостности состоит в сохранении отличий разных за-

писей этого отношения; говорят, что любое отношение должно

обладать ПСРРИЧНЫМ КЛЮЧОМ»

Второе требование более сложно. Сущности реального мира

представляются в реляционной БД в виде записей нескольких от-

ношений. Для связи отношений используется атрибут, который

служит внешним ключом. Отношение, в котором определен вне-

шний ключ, ссылается на соответствующее отношение, в котором

такой же атрибут является первичным ключом. Требование целос-

тности по ссылкам состоит в том, что для каждого значения внеш-

него ключа должна найтись запись с таким же значением первич-

ного ключа в отношении, на которое указывает ссылка, либо зна-

4 Геоинформатика

чение внешнего ключа должно быть неопределенным (т. е.

ни на

что

не

указывать).

Выполнение таких требований чрезвычайно важно

при

моди-

фикации отношений

или

удалении записей. Поддержке целостно-

сти

при

удалении кортежа служат: запрет

на

удаление кортежа,

на

который существуют ссылки; автоматическая замена значения

внешнего ключа

на

неопределенное

во

всех ссылающихся корте-

жах; автоматическое удаление всех ссылающихся кортежей.

Реляционные СУБД обладают рядом особенностей, влияющих

на организацию внешней памяти.

наиболее важным особеннос-

тям можно отнести следующие:

• наличие двух уровней системы: уровня непосредственного

управления данными

во

внешней памяти

языкового уровня

(на-

пример, уровня, реализующего язык SQL); тогда подсистема ниж-

него уровня должна поддерживать

во

внешней памяти набор базо-

вых структур, конкретная интерпретация которых входит

число

функций подсистемы верхнего уровня;

• информация, связанная

наименованием объектов базы дан-

ных

и их

конкретными свойствами (например, структура ключа-

индекса), поддерживается подсистемой языкового уровня;

• регулярность структур данных

во

внешней памяти, поскольку

основным объектом реляционной модели данных является плос-

кая таблица;

•

для

выполнения операторов языкового уровня

над

одним

или

несколькими отношениями

во

внешней памяти поддерживаются

дополнительные «управляющие» структуры

—

индексы;

•

для

выполнения требования надежного хранения

баз

данных

поддерживается избыточность хранения данных

во

внешней памяти.

Следует подчеркнуть,

что как бы ни

были организованы

ин-

дексы

конкретной СУБД,

их

основное назначение состоит

обес-

печении эффективного прямого доступа

кортежу отношения

по

ключу. Обычно индекс определяется для одного отношения,

клю-

чом является значение атрибута (возможно, составного). Органи-

зация индексов

больших

БД

представляет сложную проблему.

Все

более популярным подходом

организации индексов является

использование техники хэширования. Общей идеей методов хэши-

рования является применение

значению ключа некоторой фун-

кции свертки (хэш-функции), вырабатывающей значение мень-

шего размера. Свертка значения ключа затем применяется

для до-

ступа

записи.

самом простом случае свертка ключа использует-

ся

как

адрес

таблице, содержащей ключи

записи.

Язык реляционных

баз

данных

SQL.

Функции

основные воз-

можности. Язык для взаимодействия

с БД

—

SQL (Structered Query

Language)

— появился

середине 70-х годов XX в.

настоящее вре-

мя распространена

его

версия

SQL/92.

Язык ориентирован глав-

ным образом

на

удобную

понятную пользователям формулиров-

ку запросов

реляционной

БД и

содержит, помимо операторов

формулирования запросов

манипулирования

БД,

средства

для

определения схемы

БД,

ограничений целостности, структуры

БД

физического уровня, авторизации доступа

отношениям

и их

по-

лям, позиций сохранения транзакции

откатов. Двумя фундамен-

тальными языками запросов

реляционным

БД

являются языки

реляционной алгебры

реляционного исчисления. Самый общий

вид запроса

на

языке SQL представляет теоретико-множественное

алгебраическое выражение, составленное

из

элементарных запро-

сов.

В настоящее время

SQL

реализован практически

во

всех ком-

мерческих реляционных СУБД,

все

фирмы провозглашают соот-

ветствие своей реализации стандарту SQL,

и на

самом деле реали-

зованные диалекты SQL очень близки. Особенностью большинства

современных коммерческих СУБД, затрудняющей анализ суще-

ствующих диалектов SQL, является отсутствие полного описания

языка.

В языке

SQL

поддерживаются следующие типы данных:

CHARACTER,

NUMERIC, DECIMAL,

INTEGER,

SMALLINT,

FLOAT, REAL, DOUBLE

PRECISION.

К первому типу относится

CHARACTER.

Спецификатор типа

имеет

ввд

CHARACTER

(length),

где

length

задает длину строк

данного типа.

SQL/89

нет

строк переменного размера, хотя

во

многих реализациях они допускаются. Литеральные строки симво-

лов изображаются

виде «последовательности символов» (напри-

мер,

«example»).

Представителями второго типа являются NUMERIC, DECIMAL

(или

DEC),

INTEGER

(или INT) и

SMALLINT.

Спецификатор

типа NUMERIC имеет ввд NUMERIC

([precision],

[scale]).

Специ-

фицируются точные числа, представляемые

точностью

precision

масштабе

scale.

Здесь

далее, если

не

указан масштаб,

то он

полагается равным

0, а

если

не

указана точность,

то ее

значение

по умолчанию определяется

реализации.

Спецификатор типа DECIMAL (или DEC) имеет вид NUMERIC

([precision],

[scale]).

Специфицируются точные числа, представлен-

ные

масштабе

scale с

точностью, равной

или

большей значения

precision.

INTEGER

специфицирует тип данных точных чисел

масшта-

бе

0 с

определяемой

реализации точностью. SMALLINT специ-

фицирует тип данных точных чисел

масштабе

0 с

определяемой

в реализации точностью,

не

большей,

чем

точность чисел типа

INTEGER.

К третьему типу относятся FLOAT, REAL, DOUBLE

PRECISION.

Несмотря

на

то, что правила встраивания SQL

программы

на

языке

Си не

определены

SQL/89,

большинстве реализаций,

поддерживающих такое встраивание, имеется следующее соответст-