Об Авторе 1 страница

Мартин Грубер — свободный писатель, учитель и консультант из Сан Франциско. В дополнении к написанию и редактированию книг, руководств пользователей и документации, он работает в широком спектре интересов, связаных с компьютерами и компьютерными базами данных.

ВВЕДЕНИЕ В РЕЛЯЦИОННУЮ БАЗУ ДАННЫХ

ВВЕДЕНИЕ

SQL (ОБЫЧНО ПРОИЗНОСИМАЯ КАК "СЭКВЭЛ") символизирует собой Структурированный Язык Запросов. Это — язык который дает вам возможность создавать и работать в реляционных базах данных, которые являются наборами связанной информации, сохраняемой в таблицах.

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

Элегантность и независимость от специфики компьютерных технологий, а также его поддержка лидерами промышленности в области технологии реляционных баз данных, сделало SQL, и вероятно в течение обозримого будущего оставит его, основным стандартным языком. По этой причине, любой кто хочет работать с базами данных 90-х годов должен знать SQL.

Стандарт SQL определяется ANSI (Американским Национальным Институтом Стандартов) и в данное время также принимается ISO (МЕЖДУНАРОДНОЙ ОРГАНИЗАЦИЕЙ ПО СТАНДАРТИЗАЦИИ). Однако, большинство коммерческих программ баз данных расширяют SQL без уведомления ANSI, добавляя разные другие особенности в этот язык, которые, как они считают, будут весьма полезны. Иногда они несколько нарушают стандарт языка, хотя хорошие идеи имеют тенденцию развиваться и вскоре становиться стандартами " рынка " сами по себе в силу полезности своих качеств. В этой книге, мы будем, в основном, следовать стандарту ANSI, но одновременно иногда будет показывать и некоторые наиболее общие отклонения от его стандарта. Вы должны проконсультироваться с документацией вашего пакета программ который вы будете использовать, чтобы знать где в нем этот стандарт видоизменен.

ПРЕЖДЕ, ЧЕМ ВЫ СМОЖЕТЕ ИСПОЛЬЗОВАТЬ SQL, ВЫ должны понять что такое реляционные базы данных. В этой главе мы это объясним и покажем, насколько реляционные базы данных полезны. Мы не будем обсуждать SQL именно здесь, и если вы уже знаете эти понятия довольно хорошо, вы можете просто пропустить эту главу. В любом случае, вы должны рассмотреть три таблицы которые предоставляются и объясняются в конце главы; они станут основой наших примеров в этой книге. Вторая копия этих таблиц находится Приложении E, и мы рекомендуем скопировать их для удобства ссылки к ним.

ЧТО ТАКОЕ — РЕЛЯЦИОННАЯ БАЗА ДАННЫХ?

Реляционная база данных — это тело связанной информации, сохраняемой в двумерных таблицах. Напоминает адресную или телефонную книгу. В книге имеется большое количество входов, каждый из которых соответствует определеной особенности. Для каждой такой особенности, может быть несколько независимых фрагментов данных, например имя, телефонный номер, и адрес. Предположим, что вы должны сформатировать эту адресную книгу в виде таблицы со строками и столбцами. Каждая строка (называемая также записью) будет соответствовать определенной особенности; каждый столбец будет содержать значение для каждого типа данных — имени, телефонного номера, и адреса представляемого в каждой строке. Адресная книга могла бы выглядеть следующим образом:

Имя	Телефон	Адрес
Gerry Farish	[phone]	127 Primrose Ave.,SF
Celia Brock	[phone]	246 #3rd St., Sonoma
Yves Grillet	[phone]	778 Modernas, Barcelona

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

СВЯЗЫВАНИЕ ОДНОЙ ТАБЛИЦЫ С ДРУГОЙ

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

Пациент	Доктор	Страховка	Баланс
Farish	Drume	B.C./B.S.	$272.99
Grillet	Halben	None	$44.76
Brock	Halben	Health,Inc.	$9077.47

Много мощных функций можно выполнить извлекая информацию из этих таблиц согласно указанным параметрам, особенно когда эти параметры включают в себя фрагменты информации свзанные в различных таблицах друг с другом. Например, возьмем — докторов. Предположим доктор Halben захотел получить номера телефонов всех своих пациентов. Чтобы извлечь эту информацию, он мог бы связать таблицу с номерами телефонов пациентов (по адресной книге) с таблицей которая бы указывала, какой из пациентов — его. Хотя, в этом простом примере, он мог бы держать это в голове и сразу получать номера телефонов пациентов Grillet и Brock, эти таблицы могут быть слишком большими и слишком сложными. Программы реляционной базы данных разрабатывались для того чтобы обрабатывать большие и сложные совокупности данных такого типа, что очевидно является более универсальным методом в деловом мире. Даже если бы база данных больницы содержала сотни или тысячи имен — как это вероятно и бывает на практике — одна команда SQL могла бы выдать доктору Halben информацию в которой он нуждался почти немедленно.

ПОРЯДОК СТРОК ПРОИЗВОЛЕН

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

Рассмотрим вторую таблицу. Иногда Вам необходимо видеть эту информацию упорядоченной в алфавитном порядке по именам, иногда в возрастающем или убывающем порядке, а иногда сгруппированной по отношению к какому-нибудь доктору. Наложение порядка набора в строках будет сталкиваться со способностью заказчика изменять его, поэтому строки всегда рассматриваются как неупорядоченные. По этой причине, вы не можете просто сказать: " Мы хотим посмотреть пятую строку таблицы. " Пренебрегая порядком в котором данные вводились или любым другим критерием, мы определим, не ту строку, хотя она и будет пятой. Строки таблицы которые рассматриваются, не будут в какой-либо определенной последовательности.

ИДЕНТИФИКАЦИЯ СТРОК (ПЕРВИЧНЫЕ КЛЮЧИ)

По этим и другим причинам, вы должны иметь столбец в вашей таблице который бы уникально идентифицировал каждую строку. Обычно, этот столбец содержит номер — например, номер пациента назначаемый каждому пациенту. Конечно, вы могли бы использовать имя пациентов, но возможно что имеется несколько Mary Smiths; и в этом случае, вы не будете иметь другого способа чтобы отличить этих пациентов друг от друга. Вот почему номера так необходимы. Такой уникальный столбец (или уникальная группа столбцов), используемый чтобы идентифицировать каждую строку и храненить все строки отдельно, называются — первичными ключами таблицы. Первичные ключи таблицы важный элемент в структуре базы данных. Они — основа вашей системы записи в файл; и когда вы хотите найти определенную строку в таблице, вы ссылаетесь к этому первичному ключу. Кроме того, первичные ключи гарантируют, что ваши данные имеют определенную целостность. Если первичный ключ правильно используется и поддерживается, вы будете знать что нет пустых строк таблицы и что каждая строка отличается от любой другой строки. Мы будем обсуждать ключи и далее когда поговорим относительно справочной целостности в Главе 19.

СТОЛБЦЫ ИМЕНУЮТСЯ И НУМЕРУЮТСЯ

В отличие от строк, столбцы таблицы (также называемые полями) упорядочиваются и именуются. Таким образом, в нашей таблице адресной книги, возможно указать на "адрес столбца" или на "столбец 3". Конечно, это означает что каждый столбец данной таблицы должен иметь уникальное имя чтобы избежать неоднозначности. Лучше всего если эти имена указывают на содержание поля. В типовых таблицах этой книги, мы будем использовать такие сокращения для имени столбца, как cname для имени заказчика, и odate для даты порядка. Мы также дадим каждой таблице личный числовой номер столбца в качестве первичного ключа. Следующий раздел будет объяснять эти таблицы и их ключи более подробно.

ТИПОВАЯ БАЗА ДАННЫХ

Таблицы 1.1, 1.2, и 1.3 составляют реляционную базу данных которая является минимально достаточной чтобы легко ее отслеживать, и достаточно полной, чтобы иллюстрировать главные понятия и практику использования SQL. Эти таблицы напечатаны в этой главе а также в Приложении E. Так как они будут использоваться для иллюстрирования различных особенностей SQL по всей этой книге, мы рекомендуем чтобы вы скопировали их, для удобства ссылки к ним.

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

Таблица 1.1: Продавцы

SNUM	SNAME	CITY	COMM
1001	Peel	London	.12
1002	Serres	San Jose	.13
1004	Motika	London	.11
1007	Rifkin	Barcelona	.15
1003	Axelrod	New York	.10

Таблица 1.2: Заказчики

CNUM	CNAME	CITY	RATING	SNUM
2001	Hoffman	London	100	1001
2002	Giovanni	Rome	200	1003
2003	Liu	SanJose	200	1002
2004	Grass	Berlin	300	1002
2006	Clemens	London	100	1001
2008	Cisneros	SanJose	300	1007
2007	Pereira	Rome	100	1004

Таблица 1.3: Порядки

ONUM	AMT	ODATE	CNUM	SNUM
3001	18.69	10/03/1990	2008	1007
3003	767.19	10/03/1990	2001	1001
3002	1900.10	10/03/1990	2007	1004
3005	5160.45	10/03/1990	2003	1002
3006	1098.16	10/03/1990	2008	1007
3009	1713.23	10/04/1990	2002	1003
3007	75.75	10/04/1990	2004	1002
3008	4723.00	10/05/1990	2006	1001
3010	1309.95	10/06/1990	2004	1002
3011	9891.88	10/06/1990	2006	1001

Например, поле snum в таблице Заказчиков указывает, какому продавцу назначен данный заказчик. Номер поля snum связан с таблицей Продавцов, которая дает информацию об этих продавцах. Очевидно, что продавец которому назначены заказчики должен уже существовать — то есть, значение snum из таблицы Заказчиков должно также быть представлено в таблице Продавцов. Если это так, то говорят, что "система находится в состоянии справочной целостности". Этот вывод будет более полно и формально объяснен в Главе 19.

ПРИМЕЧАНИЕ: Эти три представленых таблицы в тексте имеют русские имена — Продавцов, Заказчиков и Порядков, и далее будут упоминаться именно под этими именами. Имена любых других применяемых в книге таблиц будут написаны по английски чтобы отличать их от наших базовых таблиц этой базы данных. Кроме того в целях однозначности, имена заказчиков, продавцов, Системных Каталогов а также полей в тексте, также будут даны на латыни.

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

Здесь показаны столбцы Таблицы 1.1

ПОЛЕ	СОДЕРЖАНИЕ
snum	уникальный номер, назначенный каждому продавцу ("номер служащего")
sname	имя продавца
city	расположение продавца (город)
comm	комиссионные продавцов в десятичной форме

Таблица 1.2 содержит следующие столбцы:

ПОЛЕ	СОДЕРЖАНИЕ
cnum	Уникальный номер назначенный каждому заказчику
cname	Имя заказчика
city	Расположение заказчика (город)
rating	Код, указывающий уровень предпочтения данного заказчика перед другими. Более высокий номер указывают на большее предпочтение (рейтинг).
snum	Номер продавца, назначенного этому заказчику (из таблицы Продавцов)

И имеются столбцы в Таблице 1.3:

ПОЛЕ	СОДЕРЖАНИЕ
onum	уникальный номер данный каждому приобретению
amt	значение суммы приобретений
odate	дата приобретения
cnum	номер заказчика делающего приобретение (из таблицы Заказчиков)
snum	номер продавца продающего приобретение (из таблицы Продавцов)

РЕЗЮМЕ

Теперь вы знаете что такое реляционная база данных, понятие, которое звучит сложнее чем есть на самом деле. Вы также изучили некоторые фундаментальные принципы относительно того, как сделаны таблицы — как работают строки и столбцы, как первичные ключи отличают строки друга друга, и как столбцы могут ссылаться к значениям в других столбцах. Вы поняли что запись это синоним строки, и что поле это синоним столбца. Оба термина встречаются в обсуждении SQL, и мы будем использовать их в равной степени в этой книге.

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

Теперь вы готовы к углублению в SQL самостоятельно. Следующая глава даст вам быстрый просмотр языка, и даст вам информацию, которая поможет Вам ссылаться к уже пройденным местам.

РАБОТА С SQL

1. Какое поле таблицы Заказчиков является первичным ключом?

2. Что является столбцом 4 из таблицы Заказчиков?

3. Как по другому называется строка? Столбец?

4. Почему вы не можете запрашивать для просмотра первые пять строк таблицы?

(См. Приложение A для ответов.)

SQL: ОБЗОР

ЭТА ГЛАВА ПОЗАКОМИТ ВАС СО СТРУКТУРОЙ SQL языка, а также с определенными общими выводами, такими как тип данных, которые эти поля могут содержать, и некоторые области неоднозначностей, которые существуют в SQL. Она предназначена обеспечить связь с более конкретной информацией в последующих главах. Вы не должны запоминать каждую подробность, упомянутую в этой главе. Краткий обзор представлен здесь в одной удобно размещеной области, многие подробности которой вы можете иметь чтобы в последствии ссылаться к ним по мере овладения языком. Мы поместили все это в начало книги чтобы ориентировать вас на мир SQL без упрощенного подхода к его проблемам и в то же время дать вам привычные в будущем места для ссылки к ним когда у Вас появятся вопросы. Этот материал может стать более понятным когда мы перейдем к описанию конкретных команд SQL, начинающихся с Главы 3.

КАК РАБОТАЕТ SQL?

SQL — это язык, ориентированный специально на реляционные базы данных. Он устраняет много работы, которую вы должны были бы сделать если бы вы использовали универсальный язык программирования, напрмер C. Чтобы сформировать реляционную базу данных на C, вам необходимо было бы начать с самого начала. Вы должны были бы определить объект, называемый таблицей, которая могла бы расти, чтобы иметь любое число строк, а затем создавать постепенно процедуры для помещения значений в нее и извлечения из них. Если бы вы захотели найти некоторые определенные строки, вам необходимо было бы выполнить по шагам процедуру, подобную следующей:

1. Рассмотрите строку таблицы.

2. Выполните проверку — является ли эта строка одной из строк, которые вам нужны.

3. Если это так, сохраните ее где-нибудь, пока вся таблица не будет проверена.

4. Проверьте, имеются ли другие строки в таблице.

5. Если имеются, возвратитесь на шаг 1.

6. Если строк больше нет, вывести все значения, сохраненные в шаге 3.

(Конечно, это не фактический набор C команд, а только логика шагов, которые должны были бы быть включены в реальную программу.)

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

ЧТО ДЕЛАЕТ ANSI?

Как мы уже рассказывали в Введении, стандарт SQL определяется с помощью кода ANSI (Американский Национальный Институт Стандартов). SQL не изобретался ANSI. Это по существу изобретение IBM. Но другие компании подхватили SQL сразу же, по крайней мере одна компания (Oracle) отбила у IBM право на рыночную продажу SQL продуктов.

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

ИНТЕРАКТИВНЫЙ И ВЛОЖЕННЫЙ SQL

Имеются два SQL: Интерактивный и Вложенный. Большей частью, обе формы работают одинаково, но используются различно.

Интерактивный SQL используется для функционирования непосредственно в базе данных, чтобы производить вывод для использования его заказчиком. В этой форме SQL, когда вы введете команду, она сейчас же выполнится и вы сможете увидеть вывод (если он вообще получится) — немедленно.

Вложенный SQL состоит из команд SQL, помещенных внутри программ, которые обычно написаны на некотором другом языке (типа КОБОЛА или Паскаля). Это делает эти программы более мощными и эффективным. Однако, допуская эти языки, приходится иметь дело с структурой SQL и стилем управления данных который требует некоторых расширений к интерактивному SQL. Передача SQL команд во вложенный SQL является выдаваемой (" passed off ") для переменных или параметров используемых программой в которую они были вложены.

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

СУБПОДРАЗДЕЛЕНИЯ SQL

И в интерактивной, и во вложенной формах SQL, имеются многочисленные части, или субподразделения. Так как вы вероятно столкнетесь с этой терминологией при чтении SQL, мы дадим некоторые пояснения. К сожалению, эти термины не используются повсеместно во всех реализациях. Они подчеркиваются ANSI и полезны на концептуальном уровне, но большинство SQL программ практически не обрабатывают их отдельно, так что они по существу становятся функциональными категориями команд SQL.

DDL (Язык Определения Данных) — так называемый Язык Описания Схемы в ANSI, состоит из команд, которые создают объекты (таблицы, индексы, просмотры, и так далее) в базе данных.

DML (Язык Манипулирования Данными) — это набор команд, которые определяют, какие значения представлены в таблицах в любой момент времени.

DCD (Язык Управления Данными) состоит из средств, которые определяют, разрешить ли пользователю выполнять определенные действия или нет.

Они являются составными частями DDL в ANSI. Не забывайте эти имена. Это не различные языки, а разделы команд SQL сгруппированных по их функциям.

РАЗЛИЧНЫЕ ТИПЫ ДАННЫХ

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

В SQL это делается с помощью назначения каждому полю типа данных, который указывает на тип, значения которое это поле может содержать. Все значения в данном поле должны иметь одинаковый тип. В таблице Заказчиков, например, cname и city — содержат строки текста для оценки, snum, и cnum — это уже номера. По этой причине, вы не можете ввести значение Highest (Наивысший) или значение None (Никакой) в поле rating, которое имеет числовой тип данных. Это ограничение удачно, так как оно налагает некоторую структурность на ваши данные. Вы часто будете сравнивать некоторые или все значения в данном поле, поэтому вы можете выполнять действие только на определенных строках а не на всех. Вы не могли бы сделать этого если бы значения полей имели смешанный тип данных.

К сожалению, определение этих типов данных является основной областью, в которой большинство коммерческих программ баз данных и официальный стандарт SQL не всегда совпадают. ANSI SQL стандарт распознает только текст и тип номера, в то время как большинство коммерческих программ используют другие специальные типы. Такие как, DATA (ДАТА) и TIME (ВРЕМЯ) — фактически почти стандартные типы (хотя точный формат их меняется). Некоторые пакеты также поддерживают такие типы, какнапример MONEY (ДЕНЬГИ) и BINARY (ДВОИЧНЫЕ). (MONEY — это специальная система исчисления, используемая компьютерами. Вся информация в компьютере передается двоичными числами и затем преобразовываются в другие системы, что бы мы могли легко использовать их и понимать.)

ANSI определяет несколько различных типов значений чисел, различия между которыми довольно тонки и иногда их путают. Разрешенные ANSI типы данных перечислены в Приложении B.

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

Два типа чисел ANSI, INTEGER (ЦЕЛОЕ ЧИСЛО) и DECIMAL (ДЕСЯТИЧНОЕ ЧИСЛО) (которые можно сокращать как INT и DEC, соответственно), будут адекватны для наших целей, также как и для целей большинства практических деловых прикладных программ. Естественно, что тип ЦЕЛОЕ можно представить как ДЕСЯТИЧНОЕ ЧИСЛО, которое не содержит никаких цифр справа от десятичной точки.

Тип для текста — CHAR (или СИМВОЛ), который относится к строке текста. Поле типа CHAR имеет определенную длину, которая определяется максимальным числом символов которые могут быть введены в это поле. Больше всего реализаций также имеют нестандартный тип называемый VARCHAR (ПЕРЕМЕННОЕ ЧИСЛО СИМВОЛОВ), который является текстовой строкой которая может иметь любую длину до определенного реализацией максимума (обычно 254 символа). CHARACTER и VARCHAR значения включаются в одиночные кавычки как "текст". Различие между CHAR и VARCHAR в том, что CHAR должен резервировать достаточное количество памяти для максимальной длины строки, а VARCHAR распределяет память так, как это необходимо.

Символьные типы состоят из всех печатных символов, включая числа. Однако, номер 1 не то же что символ "1". Символ "1" — только другой печатный фрагмент текста, не определяемый системой как наличие числового значения 1. Например 1 + 1 = 2, но "1" + "1" не равняется "2". Символьные значения сохраняются в компьютере как двоичные значения, но показываются пользователю как печатный текст. Преобразование следует за форматом определяемым системой которую вы используете. Этот формат преобразования будет одним из двух стандартных типов (возможно с расширениями), используемых в компьютерных системах: в ASCII коде (используемом во всех персональных и малых компьютерах) и EBCDIC коде (Расширенном Двоично-Десятичном Коде Обмена Информации) (используемом в больших компьютерах). Определенные операции, такие как упорядочивание в алфавитном порядке значений поля, будет изменяться вместе с форматом. Применение этих двух форматов будет обсуждаться в Главе 4.

Дата добавления: 2015-08-13