Создание баз данных в Delphi

1.Основы работы с базами данных
1.2.Требования к базам данных
1.3.Основные концепции реляционных баз данных
1.4.Шаги проектирования базы данных
2. Создание таблиц с помощью Database Desktop
2.1.Утилита Database Desktop
3. Управление соединением с базой данных (класс TDataBase,объект Session)
3.1.Класс TDataBase
3.2.Объект Session
3.3.Указание сетевого протокола при соединении с БД
4. Управление транзакциями
4.1.SQL.выражения для управления транзакциями
4.2.Управление транзакциями в Delphi
5.Local InterBase
5.1.Некоторые технические характеристики InterBase
5.2.InterBase Interactive SQL
5.3.InterBase Server Manager

Итак, хорошо спроектированная база данных:
• Удовлетворяет всем требованиям пользователей к содержимому базы данных. Перед проектированием базы необходимо провести обширные исследования требований пользователей к функционированию базы данных.
• Гарантирует непротиворечивость и целостность данных. При проектировании таблиц нужно определить их атрибуты и некоторые правила, ограничивающие возможность ввода пользователем неверных значений. Для верификации данных перед непосредственной записью их в таблицу база данных должна осуществлять вызов правил модели данных и тем самым гарантировать сохранение целостности информации.
• Обеспечивает естественное, легкое для восприятия структурирование информации. Качественное построение базы позволяет делать запросы к базе более “прозрачными” и легкими для понимания; следовательно, снижается вероятность внесения некорректных данных и улучшается качество сопровождения базы.
• Удовлетворяет требованиям пользователей к производительности базы данных. При больших объемах информации вопросы сохранения производительности начинают играть главную роль, сразу “высвечивая” все недочеты этапа проектирования.
Следующие пункты представляют основные шаги проектирования базы данных:
• Определить информационные потребности базы данных.
• Проанализировать объекты реального мира, которые необходимо смоделировать в базе данных. Сформировать из этих объектов сущности и характеристики этих сущностей (например, для сущности “деталь” характеристиками могут быть “название”, “цвет”, “вес” и т.п.) и сформировать их список.
• Поставить в соответствие сущностям и характеристикам - таблицы и столбцы (поля) в нотации выбранной Вами СУБД (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle и т.д.).
• Определить атрибуты, которые уникальным образом идентифицируют каждый объект.
• Выработать правила, которые будут устанавливать и поддерживать целостность данных.
• Установить связи между объектами (таблицами и столбцами), провести нормализацию таблиц.
• Спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации.

1. А.Я. Архангельский «Программирование в Delphi 7»
2. Интернет-ресурсы («Королевство Делфи» , Исходники.Ру)

Дисциплина: Информатика, Программирование, Базы данных
Тип работы: Курсовая работа
Бесплатно: Антиплагиат
Объем: 29 страниц
В избранное:

Министерство Образования и Науки Республики Казахстан

1

2 Казахский Экономический Университет имени
Т.Рыскулова

Инженерно-Экономический факультет

Создание баз данных в Delphi

Выполнил: студ. 4 курса, гр. ВТиПО 409

1 Таркинский М.

Алматы 2008
Содержание

1.Основы работы с базами данных
1.2.Требования к базам данных
1.3.Основные концепции реляционных баз данных
1.4.Шаги проектирования базы данных
2. Создание таблиц с помощью Database Desktop
2.1.Утилита Database Desktop
3. Управление соединением с базой данных (класс TDataBase,объект
Session)
3.1.Класс TDataBase
3.2.Объект Session
3.3.Указание сетевого протокола при соединении с БД
4. Управление транзакциями
4.1.SQL-выражения для управления транзакциями
4.2.Управление транзакциями в Delphi
5.Local InterBase
5.1.Некоторые технические характеристики InterBase
5.2.InterBase Interactive SQL
5.3.InterBase Server Manager

1.Основы работы с базами данных
1.2.Требования к базам данных
Итак, хорошо спроектированная база данных:
• Удовлетворяет всем требованиям пользователей к содержимому базы данных.
Перед проектированием базы необходимо провести обширные исследования
требований пользователей к функционированию базы данных.
• Гарантирует непротиворечивость и целостность данных. При проектировании
таблиц нужно определить их атрибуты и некоторые правила, ограничивающие
возможность ввода пользователем неверных значений. Для верификации
данных перед непосредственной записью их в таблицу база данных должна
осуществлять вызов правил модели данных и тем самым гарантировать
сохранение целостности информации.
• Обеспечивает естественное, легкое для восприятия структурирование
информации. Качественное построение базы позволяет делать запросы к базе
более “прозрачными” и легкими для понимания; следовательно, снижается
вероятность внесения некорректных данных и улучшается качество
сопровождения базы.
• Удовлетворяет требованиям пользователей к производительности базы
данных. При больших объемах информации вопросы сохранения
производительности начинают играть главную роль, сразу “высвечивая” все
недочеты этапа проектирования.
Следующие пункты представляют основные шаги проектирования базы данных:
• Определить информационные потребности базы данных.
• Проанализировать объекты реального мира, которые необходимо
смоделировать в базе данных. Сформировать из этих объектов сущности и
характеристики этих сущностей (например, для сущности “деталь”
характеристиками могут быть “название”, “цвет”, “вес” и т.п.) и
сформировать их список.
• Поставить в соответствие сущностям и характеристикам - таблицы и столбцы
(поля) в нотации выбранной Вами СУБД (Paradox, dBase, FoxPro, Access,
Clipper, InterBase, Sybase, Informix, Oracle и т.д.).
• Определить атрибуты, которые уникальным образом идентифицируют каждый
объект.
• Выработать правила, которые будут устанавливать и поддерживать
целостность данных.
• Установить связи между объектами (таблицами и столбцами), провести
нормализацию таблиц.
• Спланировать вопросы надежности данных и, при необходимости, сохранения
секретности информации.

2 1.3.Основные концепции реляционных баз данных

Прежде чем подробно рассматривать каждый из этих шагов, остановимся на
основных концепциях реляционных баз данных. В реляционной теории одним из
главных является понятие отношения. Математически отношение определяется
следующим образом. Пусть даны n множеств D1,D2,...,Dn. Тогда R есть
отношение над этими множествами, если R есть множество упорядоченных
наборов вида d1,d2,...,dn, где d1 - элемент из D1, d2 - элемент из D2,
..., dn - элемент из Dn. При этом наборы вида d1,d2,...,dn называются
кортежами, а множества D1,D2,...,Dn - доменами. Каждый кортеж состоит из
элементов, выбираемых из своих доменов. Эти элементы называются
атрибутами, а их значения - значениями атрибутов. рис. 0-a представляет
нам графическое изображение отношения с разных точек зрения.

Рис. 0-A: Термины реляционной теории и их соотношение с обработкой

данных

Легко заметить, что отношение является отражением некоторой сущности
реального мира (в данном случае - сущности “деталь”) и с точки зрения
обработки данных представляет собой таблицу. Поскольку в локальных базах
данных каждая таблица размещается в отдельном файле, то с точки зрения
размещения данных для локальных баз данных отношение можно отождествлять с
файлом. Кортеж представляет собой строку в таблице, или, что то же самое,
запись. Атрибут же является столбцом таблицы, или - полем в записи. Домен
же представляется неким обобщенным типом, который может быть источником
для типов полей в записи. Таким образом, следующие тройки терминов
являются эквивалентными:
отношение, таблица, файл (для локальных баз данных)
кортеж, строка, запись
атрибут, столбец, поле.
Реляционная база данных представляет собой совокупность отношений,
содержащих всю необходимую информацию и объединенных различными связями.
Атрибут (или набор атрибутов), который может быть использован для
однозначной идентификации конкретного кортежа (строки, записи), называется
первичным ключом. Первичный ключ не должен иметь дополнительных атрибутов.
Это значит, что если из первичного ключа исключить произвольный атрибут,
оставшихся атрибутов будет недостаточно для однозначной идентификации
отдельных кортежей. Для ускорения доступа по первичному ключу во всех
системах управления базами данных (СУБД) имеется механизм, называемый
индексированием. Грубо говоря, индекс представляет собой инвертированный
древовидный список, указывающий на истинное местоположение записи для
каждого первичного ключа. Естественно, в разных СУБД индексы реализованы
по-разному (в локальных СУБД - как правило, в виде отдельных файлов),
однако, принципы их организации одинаковы.
Возможно индексирование отношения с использованием атрибутов, отличных
от первичного ключа. Данный тип индекса называется вторичным индексом и
применяется в целях уменьшения времени доступа при нахождении данных в
отношении, а также для сортировки. Таким образом, если само отношение не
упорядочено каким-либо образом и в нем могут присутствовать строки,
оставшиеся после удаления некоторых кортежей, то индекс (для локальных
СУБД - индексный файл), напротив, отсортирован.
Для поддержания ссылочной целостности данных во многих СУБД имеется
механизм так называемых внешних ключей. Смысл этого механизма состоит в
том, что некоему атрибуту (или группе атрибутов) одного отношения
назначается ссылка на первичный ключ другого отношения; тем самым
закрепляются связи подчиненности между этими отношениями. При этом
отношение, на первичный ключ которого ссылается внешний ключ другого
отношения, называется master-отношением, или главным отношением; а
отношение, от которого исходит ссылка, называется detail-отношением, или
подчиненным отношением. После назначения такой ссылки СУБД имеет
возможность автоматически отслеживать вопросы “ненарушения“ связей между
отношениями, а именно:
если Вы попытаетесь вставить в подчиненную таблицу запись, для внешнего
ключа которой не существует соответствия в главной таблице (например, там
нет еще записи с таким первичным ключом), СУБД сгенерирует ошибку;
если Вы попытаетесь удалить из главной таблицы запись, на первичный ключ
которой имеется, хотя бы одна ссылка из подчиненной таблицы, СУБД также
сгенерирует ошибку.
если Вы попытаетесь изменить первичный ключ записи главной таблицы, на
которую имеется, хотя бы одна ссылка из подчиненной таблицы, СУБД также
сгенерирует ошибку.

Замечание. Существует два подхода к удалению и изменению записей из
главной таблицы:
Запретить удаление всех записей, а также изменение первичных ключей
главной таблицы, на которые имеются ссылки подчиненной таблицы.
Распространить всякие изменения в первичном ключе главной таблицы на
подчиненную таблицу, а именно:
если в главной таблице удалена запись, то в подчиненной таблице должны
быть удалены все записи, ссылающиеся на удаляемую;
если в главной таблице изменен первичный ключ записи, то в подчиненной
таблице должны быть изменены все внешние ключи записей, ссылающихся на
изменяемую.

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

1.4.Шаги проектирования базы данных

I. Первый шаг состоит в определении информационных потребностей базы
данных. Он включает в себя опрос будущих пользователей для того, чтобы
понять и задокументировать их требования. Следует выяснить следующие
вопросы:
сможет ли новая система объединить существующие приложения или их
необходимо будет кардинально переделывать для совместной работы с новой
системой;
какие данные используются разными приложениями; смогут ли Ваши приложения
совместно использовать какие-либо из этих данных;
кто будет вводить данные в базу и в какой форме; как часто будут
изменяться данные;
достаточно ли будет для Вашей предметной области одной базы или Вам
потребуется несколько баз данных с различными структурами;
какая информация является наиболее чувствительной к скорости ее извлечения
и изменения.
II. Следующий шаг включает в себя анализ объектов реального мира,
которые необходимо смоделировать в базе данных.
Формирование концептуальной модели базы данных включает в себя:
идентификацию функциональной деятельности Вашей предметной области.
Например, если речь идет о деятельности предприятия, то в качестве
функциональной деятельности можно идентифицировать ведение учета
работающих, отгрузку продукции, оформление заказов и т.п.
идентификацию объектов, которые осуществляют эту функциональную
деятельность, и формирование из их операций последовательности событий,
которые помогут Вам идентифицировать все сущности и взаимосвязи между
ними. Например, процесс “ведение учета работающих” идентифицирует такие
сущности как РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ.
идентификацию характеристик этих сущностей. Например, сущность РАБОТНИК
может включать такие характеристики как Идентификатор Работника, Фамилия,
Имя, Отчество, Профессия, Зарплата.
идентификацию взаимосвязей между сущностями. Например, каким образом
сущности РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ взаимодействуют друг с другом?
Работник имеет одну профессию (для простоты!) и значится в одном отделе, в
то время как в одном отделе может находиться много работников.
III. Третий шаг заключается в установлении соответствия между
сущностями и характеристиками предметной области и отношениями и
атрибутами в нотации выбранной СУБД. Поскольку каждая сущность реального
мира обладает некими характеристиками, в совокупности образующими полную
картину ее проявления, можно поставить им в соответствие набор отношений
(таблиц) и их атрибутов (полей).
Перечислив все отношения и их атрибуты, уже на этом этапе можно начать
устранять излишние позиции. Каждый атрибут должен появляться только один
раз; и Вы должны решить, какое отношение будет являться владельцем какого
набора атрибутов.
IV. На четвертом шаге определяются атрибуты, которые уникальным
образом идентифицируют каждый объект. Это необходимо для того, чтобы
система могла получить любую единичную строку таблицы. Вы должны
определить первичный ключ для каждого из отношений. Если нет возможности
идентифицировать кортеж с помощью одного атрибута, то первичный ключ нужно
сделать составным - из нескольких атрибутов. Хорошим примером может быть
первичный ключ в таблице работников, состоящий из фамилии, имени и
отчества. Первичный ключ гарантирует, что в таблице не будет содержаться
двух одинаковых строк. Во многих СУБД имеется возможность помимо
первичного определять еще ряд уникальных ключей. Отличие уникального ключа
от первичного состоит в том, что уникальный ключ не является главным
идентифицирующим фактором записи и на него не может ссылаться внешний
ключ другой таблицы. Его главная задача - гарантировать уникальность
значения поля.
V. Пятый шаг предполагает выработку правил, которые будут
устанавливать и поддерживать целостность данных. Будучи определенными,
такие правила в клиент-серверных СУБД поддерживаются автоматически -
сервером баз данных; в локальных же СУБД их поддержание приходится
возлагать на пользовательское приложение.
Эти правила включают:
определение типа данных
выбор набора символов, соответствующего данной стране
создание полей, опирающихся на домены
установка значений по умолчанию
определение ограничений целостности
определение проверочных условий.
VI. На шестом шаге устанавливаются связи между объектами (таблицами и
столбцами) и производится очень важная операция для исключения
избыточности данных - нормализация таблиц.
Каждый из различных типов связей должен быть смоделирован в базе
данных. Существует несколько типов связей:
связь “один-к-одному”
связь “один-ко-многим”
связь “многие-ко-многим”.
Связь “один-к-одному” представляет собой простейший вид связи данных,
когда первичный ключ таблицы является в то же время внешним ключом,
ссылающимся на первичный ключ другой таблицы. Такую связь бывает удобно
устанавливать тогда, когда невыгодно держать разные по размеру (или по
другим критериям) данные в одной таблице. Например, можно выделить данные
с подробным описанием изделия в отдельную таблицу с установлением связи
“один-к-одному” для того чтобы не занимать оперативную память, если эти
данные используются сравнительно редко.
Связь “один-ко-многим” в большинстве случаев отражает реальную
взаимосвязь сущностей в предметной области. Она реализуется уже описанной
парой “внешний ключ-первичный ключ”, т.е. когда определен внешний ключ,
ссылающийся на первичный ключ другой таблицы. Именно эта связь описывает
широко распространенный механизм классификаторов. Имеется справочная
таблица, содержащая названия, имена и т.п. и некие коды, причем, первичным
ключом является код. В таблице, собирающей информацию - назовем ее
информационной таблицей - определяется внешний ключ, ссылающийся на
первичный ключ классификатора. После этого в нее заносится не название из
классификатора, а код. Такая система становится устойчивой от изменения
названия в классификаторах. Имеются способы быстрой “подмены” в
отображаемой таблице кодов на их названия как на уровне сервера БД (для
клиент-серверных СУБД), так и на уровне пользовательского приложения. Но
об этом - в дальнейших уроках.
Связь “многие-ко-многим” в явном виде в реляционных базах данных не
поддерживается. Однако имеется ряд способов косвенной реализации такой
связи, которые с успехом возмещают ее отсутствие. Один из наиболее
распространенных способов заключается во введении дополнительной таблицы,
строки которой состоят из внешних ключей, ссылающихся на первичные ключи
двух таблиц. Например, имеются две таблицы: КЛИЕНТ и ГРУППА_ИНТЕРЕСОВ.
Один человек может быть включен в различные группы, в то время как группа
может объединять различных людей. Для реализации такой связи “многие-ко-
многим” вводится дополнительная таблица, назовем ее КЛИЕНТЫ_В_ГРУППЕ,
строка которой будет иметь два внешних ключа: один будет ссылаться на
первичный ключ в таблице КЛИЕНТ, а другой - на первичный ключ в таблице
ГРУППА_ИНТЕРЕСОВ. Таким образом в таблицу КЛИЕНТЫ_В_ГРУППЕ можно
записывать любое количество людей и любое количество групп.
Итак, после определения таблиц, полей, индексов и связей между
таблицами следует посмотреть на проектируемую базу данных в целом и
проанализировать ее, используя правила нормализации, с целью устранения
логических ошибок. Важность нормализации состоит в том, что она позволяет
разбить большие отношения, как правило, содержащие большую избыточность
информации, на более мелкие логические единицы, группирующие только
данные, объединенные “по природе”. Таким образом, идея нормализации
заключается в следующем. Каждая таблица в реляционной базе данных
удовлетворяет условию, в соответствии с которым в позиции на
пересечении каждой строки и столбца таблицы всегда находится единственное
значение, и никогда не может быть множества таких значений.
После применения правил нормализации логические группы данных
располагаются не более чем в одной таблице. Это дает следующие
преимущества:
данные легко обновлять или удалять
исключается возможность рассогласования копий данных
уменьшается возможность введения некорректных данных.
Процесс нормализации заключается в приведении таблиц в так называемые
нормальные формы. Существует несколько видов нормальных форм: первая
нормальная форма (1НФ), вторая нормальная форма (2НФ), третья нормальная
форма (3НФ), нормальная форма Бойса-Кодда (НФБК), четвертая нормальная
форма (4НФ), пятая нормальная форма (5НФ). С практической точки зрения,
достаточно трех первых форм - следует учитывать время, необходимое системе
для “соединения” таблиц при отображении их на экране. Поэтому мы
ограничимся изучением процесса приведения отношений к первым трем формам.
Этот процесс включает:
устранение повторяющихся групп (приведение к 1НФ)
удаление частично зависимых атрибутов (приведение к 2НФ)
удаление транзитивно зависимых атрибутов (приведение к 3НФ).

2. Создание таблиц с помощью Database Desktop
На данном разделе мы изучим, как создавать таблицы базы данных с
помощью утилиты Database Desktop, входящей в поставку Delphi. Хотя для
создания таблиц можно использовать различные средства (SQL - компонент
TQuery и WISQL, компонент TTable), применение этой утилиты позволяет
создавать таблицы в интерактивном режиме и сразу же просмотреть их
содержимое - и все это для большого числа форматов. Это особенно удобно
для локальных баз данных, в частности Paradox и dBase.

4 2.1.Утилита Database Desktop

Database Desktop - это утилита, во многом похожая на Paradox, которая
поставляется вместе с Delphi для интерактивной работы с таблицами
различных форматов локальных баз данных - Paradox и dBase, а также SQL-
серверных баз данных InterBase, Oracle, Informix, Sybase (с использованием
SQL Links). Исполняемый файл утилиты называется DBD.EXE, расположен он,
как правило, в директории, называемом DBD (при установке по умолчанию).
Для запуска Database Desktop просто дважды щелкните по ее иконке.

Рис. 1: Выпадающий список в диалоговом окне Table Type позволяет выбрать
тип создаваемой таблицы

После старта Database Desktop выберите команду меню FileNewTable для
создания новой таблицы. Перед Вами появится диалоговое окно выбора типа
таблицы, как показано на рис.1. Вы можете выбрать любой формат из
предложенного, включая различные версии одного и того же формата.
После выбора типа таблицы Database Desktop представит Вам диалоговое
окно, специфичное для каждого формата, в котором Вы сможете определить
поля таблицы и их тип, как показано на рис.2.

Рис. 2: Database Desktop позволяет задать имена и типы полей в таблице

Имя поля в таблице формата Paradox представляет собой строку,
написание которой подчиняется следующим правилам:
Имя должно быть не длиннее 25 символов.
Имя не должно начинаться с пробела, однако может содержать пробелы.
Однако, если Вы предполагаете в будущем переносить базу данных в другие
форматы, разумнее будет избегать включения пробелов в название поля.
Фактически, в целях переносимости лучше ограничиться девятью символами в
названии поля, не включая в него пробелы.
Имя не должно содержать квадратные, круглые или фигурные скобки [], () или
{}, тире, а также комбинацию символов “тире” и “больше” (-).
Имя не должно быть только символом #, хотя этот символ может
присутствовать в имени среди других символов. Хотя Paradox поддерживает
точку (.) в названии поля, лучше ее избегать, поскольку точка
зарезервирована в Delphi для других целей.
Имя поля в таблице формата dBase представляет собой строку, написание
которой подчиняется правилам, отличным от Paradox:
Имя должно быть не длиннее 10 символов.
Пробелы в имени недопустимы.
Таким образом, Вы видите, что имена полей в формате dBase подчиняются
гораздо более строгим правилам, нежели таковые в формате Paradox. Однако,
мы еще раз хотим подчеркнуть, что если перед Вами когда-либо встанут
вопросы совместимости, то лучше сразу закладывать эту совместимость -
давать полям имена, подчиняющиеся более строгим правилам.
Укажем еще правила, которым подчиняется написание имен полей в формате
InterBase.
Имя должно быть не длиннее 31 символа.
Имя должно начинаться с букв A-Z, a-z.
Имя поля может содержать буквы (A-Z, a-z), цифры, знак $ и символ
подчеркивания (_).
Пробелы в имени недопустимы.
Для имен таблиц запрещается использовать зарезервированные слова
InterBase.
Следующий (после выбора имени поля) шаг состоит в задании типа поля.
Типы полей очень сильно различаются друг от друга, в зависимости от
формата таблицы. Для получения списка типов полей перейдите к столбцу
“Type”, а затем нажмите пробел или щелкните правой кнопкой мышки. Приведем
списки типов полей, характерные для форматов Paradox, dBase и InterBase.
Итак, поля таблиц формата Paradox могут иметь следующий тип (для ввода
типа поля можно набрать только подчеркнутые буквы или цифры):

Табл. A: Типы полей формата Paradox

Alpha строка длиной 1-255 байт, содержащая любые
печатаемые символы
Number числовое поле длиной 8 байт, значение которого
может быть положительным и отрицательным. Диапазон
чисел - от 10-308 до 10308 с 15 значащими цифрами
$ (Money) числовое поле, значение которого может быть
положительным и отрицательным. По умолчанию,
является форматированным для отображения
десятичной точки и денежного знака
Short числовое поле длиной 2 байта, которое может
содержать только целые числа в диапазоне от -32768
до 32767
Long Integer числовое поле длиной 4 байта, которое может
содержать целые числа в диапазоне от -2147483648
до 2147483648
# (BCD) числовое поле, содержащее данные в формате BCD
(Binary Coded Decimal). Скорость вычислений
немного меньше, чем в других числовых форматах,
однако точность - гораздо выше. Может иметь 0-32
цифр после десятичной точки
Date поле даты длиной 4 байта, которое может содержать
дату от 1 января 9999 г. до нашей эры - до 31
декабря 9999 г. нашей эры. Корректно обрабатывает
високосные года и имеет встроенный механизм
проверки правильности даты
Time поле времени длиной 4 байта, содержит время в
миллисекундах от полуночи и ограничено 24 часами
@ (Timestamp) обобщенное поле даты длиной 8 байт - содержит и
дату и время
Memo поле для хранения символов, суммарная длина
которых более 255 байт. Может иметь любую длину.
При этом размер, указываемый при создании таблицы,
означает количество символов, сохраняемых в
таблице (1-240) - остальные символы сохраняются в
отдельном файле с расширением .MB
Formatted Memo поле, аналогичное Memo, с добавлением возможности
задавать шрифт текста. Также может иметь любую
длину. При этом размер, указываемый при создании
таблицы, означает количество символов, сохраняемых
в таблице (0-240) - остальные символы сохраняются
в отдельном файле с расширением .MB. Однако,
Delphi в стандартной поставке не обладает
возможностью работать с полями типа Formatted Memo
Graphic поле, содержащее графическую информацию. Может
иметь любую длину. Смысл размера - такой же, как и
в Formatted Memo. Database Desktop “умеет”
создавать поля типа Graphic, однако наполнять их
можно только в приложении
OLE поле, содержащее OLE-данные (Object Linking and
Embedding) - образы, звук, видео, документы -
которые для своей обработки вызывают создавшее их
приложение. Может иметь любую длину. Смысл размера
- такой же, как и в Formatted Memo. Database
Desktop “умеет” создавать поля типа OLE, однако
наполнять их можно только в приложении. Delphi
“напрямую” не умеет работать с OLE-полями, но это
легко обходится путем использования потоков
Logical поле длиной 1 байт, которое может содержать только
два значения - T (true, истина) или F (false,
ложь). Допускаются строчные и прописные буквы
+ (Autoincrement) поле длиной 4 байта, содержащее нередактируемое
(read-only) значение типа long integer. Значение
этого поля автоматически увеличивается (начиная с
1) с шагом 1 - это очень удобно для создания
уникального идентификатора записи (физический
номер записи не может служить ее идентификатором,
поскольку в Парадоксе таковой отсутствует. В
InterBase также отсутствуют физические номера
записей, но отсутствует и поле Autoincrement. Его
с успехом заменяет встроенная функция Gen_id,
которую удобней всего применять в триггерах)
Binary поле, содержащее любую двоичную информацию. Может
иметь любую длину. При этом размер, указываемый
при создании таблицы, означает количество
символов, сохраняемых в таблице (0-240) -
остальные символы сохраняются в отдельном файле с
расширением .MB. Это полнейший аналог поля BLOb в
InterBase
Bytes строка цифр длиной 1-255 байт, содержащая любые
данные

Поля таблиц формата dBase могут иметь следующий тип (для ввода типа
поля можно набрать только подчеркнутые буквы или цифры):

Табл. B: Типы полей формата dBase

Character (alpha) строка длиной 1-254 байт, содержащая любые
печатаемые символы
Float (numeric) числовое поле размером 1-20 байт в формате с
плавающей точкой, значение которого может быть
положительным и отрицательным. Может содержать
очень большие величины, однако следует иметь в
виду постоянные ошибки округления при работе с
полем такого типа. Число цифр после десятичной
точки (параметр Dec в DBD) должно быть по крайней
мере на 2 меньше, чем размер всего поля, поскольку
в общий размер включаются сама десятичная точка и
знак
Number (BCD) числовое поле размером 1-20 байт, содержащее
данные в формате BCD (Binary Coded Decimal).
Скорость вычислений немного меньше, чем в других
числовых форматах, однако точность - гораздо выше.
Число цифр после десятичной точки (параметр Dec в
DBD) также должно быть по крайней мере на 2
меньше, чем размер всего поля, поскольку в общий
размер включаются сама десятичная точка и знак
Date поле даты длиной 8 байт. По умолчанию,
используется формат короткой даты
(ShortDateFormat)
Logical поле длиной 1 байт, которое может содержать только
значения “истина” или “ложь” - T,t,Y,y (true,
истина) или F,f,N,n (false, ложь). Допускаются
строчные и прописные буквы. Таким образом, в
отличие от Парадокса, допускаются буквы “Y” и “N”
(сокращение от Yes и No)
Memo поле для хранения символов, суммарная длина
которых более 255 байт. Может иметь любую длину.
Это поле хранится в отдельном файле. Database
Desktop не имеет возможности вставлять данные в
поле типа Memo
OLE поле, содержащее OLE-данные (Object Linking and
Embedding) - образы, звук, видео, документы -
которые для своей обработки вызывают создавшее их
приложение. Может иметь любую длину. Это поле
также сохраняется в отдельном файле. Database
Desktop “умеет” создавать поля типа OLE, однако
наполнять их можно только в приложении. Delphi
“напрямую” не умеет работать с OLE-полями, но это
легко обходится путем использования потоков
Binary поле, содержащее любую двоичную информацию. Может
иметь любую длину. Данное поле сохраняется в
отдельном файле с расширением .DBT. Это полнейший
аналог поля BLOb в InterBase

Поля таблиц формата InterBase могут иметь следующий тип:

Табл. C: Типы полей формата InterBase

SHORT числовое поле длиной 2 байта, которое может
содержать только целые числа в диапазоне от -32768
до 32767
LONG числовое поле длиной 4 байта, которое может
содержать целые числа в диапазоне от -2147483648
до 2147483648
FLOAT числовое поле длиной 4 байта, значение которого
может быть положительным и отрицательным. Диапазон
чисел - от 3.4*10-38 до 3.4*1038 с 7 значащими
цифрами
DOUBLE числовое поле длиной 8 байт (длина зависит от
платформы), значение которого может быть
положительным и отрицательным. Диапазон чисел - от
1.7*10-308 до 1.7*10308 с 15 значащими цифрами
CHAR строка символов фиксированной длины (0-32767
байт), содержащая любые печатаемые символы. Число
символов зависит от Character Set, установленного
в InterBase для данного поля или для всей базы
данных (например, для ... продолжение

Вы можете абсолютно на бесплатной основе полностью просмотреть эту работу через наше приложение.