Поиск

Полнотекстовый поиск:
Где искать:
везде
только в названии
только в тексте
Выводить:
описание
слова в тексте
только заголовок

Рекомендуем ознакомиться

'Документ'
Задания этой части распределены по разделам: цитология, генетика, эволюционная теория, экология. В каждом из разделов предлагаются задания всех уровне...полностью>>
'Учебно-методический комплекс'
Старков В.Д Петрография. Учебно-методический комплекс. Рабочая программа для студентов, обучающихся по специальности 020306.65 «Экологическая геологи...полностью>>
'Программа'
Курс факультатива немецкого языка рассчитан на школьников 13-14 лет, второй год изучающих немецкий язык в качестве второго иностранного языка. Курс ос...полностью>>
'Литература'
Русский язык (базовый уровень) 10-11 кл. Греков В.Ф., Крючков С.Е., Чешко Л.А., Просвещение, 2012- Программа по русскому языку разработана и утвержден...полностью>>

Главная > Документ

Сохрани ссылку в одной из сетей:
Информация о документе
Дата добавления:
Размер:
Доступные форматы для скачивания:

1

Смотреть полностью

О. Л. Голицына, Т. Л. Партыка, И. И. Попов

СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ

Рекомендовано Министерством образования Российской Федерации

в качестве учебного пособия для студентов учреждений среднего

профессионального образования, обучающихся по группе

специальностей 0600 Экономика и управление

Москва ФОРУМ - ИНФРА-М

2006

УДК 004.2(075.32) ББК 32.973-02я723 Г60

Рецензенты: канд. техн. наук, доцент кафедры «Проектирование АИС»

РЭА им. Г. В. Плеханова Ю. Г, Бачинин; доктор экономических наук, профессор, декан факультета «Информатика»

в НОУ «Московский международный институт эконометрики, информатики, финансов и права» (ММИЭИФП) А. Л. Емельянов

Г60

Голицына О. Л., Партыка Т. Л., Попов И. И.

Системы управления базами данных: Учеб. пособие. — М.: ФОРУМ: ИНФРА-М, 2006. — 432 с: ил. — (Профессиональное образование).

ISBN 5-8199-0251-3 (ФОРУМ) ISBN 5-16-002564-2 (ИНФРА-М)

В учебном пособии рассматриваются основные подходы и направле­ния развития систем баз данных. Анализируются классические машин­но-ориентированные формы представления информации и данных. Рас­сматриваются типовые модели физической и логической организации данных. Исследуется архитектура средств доступа к данным. На примере системы FoxPro (система программирования с элементами СУБД) иллю­стрируются практические аспекты разработки фактографических и доку­ментальных информационных систем. Достаточно подробно описывают­ся возможности SQL как базового языка для профессиональной работы с реляционными базами данных. Необходимое внимание уделяется пробле­мам моделирования и проектирования баз данных.

Для студентов экономических специальностей.

УДК 004.2(075.32) ББК 32.973-02я723

ISBN 5-8199-0251-3 (ФОРУМ) ISBN 5-16-002564-2(ИНФРА-М)

© ©

О. Л. Голицына, Т. Л. Партыка, И. И. Попов, 2006 ИД «ФОРУМ», 2006

Введение

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

  • технический период (приблизительно с 1946 по 1964 г.), в течение которого сложились основные представления о структуре универсальных электронных вычислительных машин (ЭВМ), определилась архитектура и типы устройств; • программный период (с 1954 по 1970 г.), за который выработалась современная классификация программных средств, их структур и взаимосвязей, сложились языки программирования, разработаны компиляторы и принципы процедур ной обработки;

  • информационный период (с 1970 г. по настоящее время) — в центре внимания исследователей и разработчиков оказываются структуры данных, языки описания (ЯОД) и манипулирования (ЯМД) данными, непроцедурные подходы к построению систем обработки информации;

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

  • аппаратурный фактор (технические средства информатизации);

  • программный (программные средства и системы);

  • информационный (собственно информация, т. е. сигналы, сообщения, массивы данных, файлы и базы данных);

  • человеческий фактор (интеллектуальные усилия и человеческий труд, затрачиваемые на решение задач предметной области).

Приходится констатировать, что «локомотивом» здесь явля­ются технические средства — темпы развития ЭВМ поистине фантастичны. Еще в 1984 г. американские газетчики писали:

«В 1953 г. ЭВМ с памятью 64 Кбайт стоила 1 млн. долл., сейчас она стоит менее 1 тыс. долл. Если бы автомобили раз­вивались в течение последних 20 лет теми же темпами, как компьютеры, то сегодня роллс-ройс стоил бы 3,0 долл., прохо­дил миллион миль на галлоне бензина, развивал мощность лайнера «Queen Elisabeth» и 2 автомобиля помещались бы на кончике пера».

Добавим здесь, что сегодняшние темпы еще выше. Напри­мер, если микропроцессор Pentium IV «Northwood» (2002 г.) со­держал 42 млн транзисторов, то Pentium IV «Prescott» (2004 г.) — 125 млн. [17].

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

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

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

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

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

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

Достаточно консервативны и концепции баз данных. Эта консервативность  не только следствие  свойства «долговечности», но и того факта, что базы вторичны по отношению к опи­сываемым ими реальным процессам и объектам, достаточно стабильным и типичным. Кроме того, модели данных строились в значительной степени «по аналогии» с организационными и технологическими структурами — иерархическими, сетевыми, матричными.

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

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

Базы данных — это уже достаточно хорошо проработанная научная дисциплина. Существует множество, в том числе и фундаментальных, работ и учебников (на материал которых ав­торы опирались при подготовке этого учебника и которые убе­дительно рекомендуют тем, кто серьезно интересуется этой про­блематикой), среди них необходимо выделить такие моногра­фии, как «Организация баз данных в вычислительных системах» Дж. Мартина, «Введение в системы баз данных» К. Дейта, «Ал­горитмы и структуры данных» Н. Вирта, «SQL» Дж. Гроффа и П. Вайнберга.

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

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

Третья глава рассматривает систему FoxPro, являющуюся «пограничным продуктом» между СУБД и системами програм­мирования. Описываются типы данных и операторы языка, соз­дание и модификация базы данных, создание и модификация форматов представления данных. Приводится пример использо­вания табличной СУБД FoxPro для построения системы доку­ментального (в том числе полнотекстового) поиска.

Глава 4 посвящена описанию SQL (на примере MS SQL Server 7.0), который является стандартным языком для работы с реляционными базами данных. Возможности использования операторов языка рассматриваются на серии примеров, иллюст­рирующих этапы создания и использования базы данных, описа­ние проектирования которой приведено в гл. 3. Рассматривают­ся транзакции, организация управления доступа пользователей к объектам БД, программирование процессов управления обработ­кой данных (представления, хранимые процедуры, триггеры).

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

Авторы расположили материал в той исторической последовательности, в которой возникали и развивались соответствую­щие средства управления данными и их языковые средства. Это не значит, что читателю обязательно надо сначала прорываться сквозь дебри «сбалансированных деревьев» и «инверсных спи­сков». Он может сразу перейти к рассмотрению на примерах процессов создания и управления данными в различных сре­дах — FoxPro (гл. 3), MS SQL Server (гл. 4), а в случае необходимости — вернуться назад и поинтересоваться, «как оно там на самом деле устроено».

Учебное пособие базируется на материалах, накопленных авторами в процессе практической и исследовательской дея­тельности, а также преподавания в МИФИ, МИСИ, МЭСИ, РГГУ, РЭА им. Г. В. Плеханова, МФПА (Международная фи­нансово-промышленная академия). Авторы выражают благодар­ность коллегам, принявшим участие в обсуждении материала: Н. В. Максимову, А. А. Емельянову, а также студентам РГГУ, МФПА и РЭА им. Г. В. Плеханова за предоставленные иллюст­ративные материалы.

Глава 1

УПРАВЛЕНИЕ ДАННЫМИ

ФАЙЛОВЫЕ СИСТЕМЫ И БАЗЫ ДАННЫХ

Системы управления базами данных (СУБД), являющиеся предметом настоящего учебного пособия, не «висят в воздухе», а прочно встроены в окружение, включающее различные уровни и типы как программных средств, так и информационных процессов и структур.

Понятие «управление данными» (data management) впервые появляется задолго до баз данных (БД) и систем управления базами данных (СУБД) в качестве одной из основных функций операционной системы (ОС) ЭВМ [24].

 

Рис. 1.1. Управление данными в ОС и СУБД

 На рис. 1.1 приводится более или менее полная диаграмма различных траекторий управления данными (стрелки означают выдачу запроса на данные, передача данных осуществляется в обратном направлении).

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

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

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

1.1. Информация, данные и их представление в ЭВМ

Уровни информационных процессов 

Данное понятие характеризует степень связи информационных процессов с предметной областью информационные технологии; информационные системы; информационные ресурсы:

  • автоматизированную информационную технологию   (АИХ,   И Т) определим как целенаправленное и согласованное использование: технических средств информатизации   (аппаратурный   фактор);  

  • программных средств и систем (программный фактор);

  • информационных массивов и баз данных (информационный фактор);

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

  • информационные  системы   (АИС, ИС) определяются как комплексы информационных технологий, ориентированных на процедуры сбора, обработки, хранения, поиска, передачи и отображения информации предметной области;

  • информационные ресурсы (ИР) — комплексы соответствующих информационных систем, рассматриваемые прежде всего на социально-экономических уровнях описания и применения.

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

База данных на уровне информационных технологий [2, 3, 4, 23] представляет собой коллекцию информации, обычно совокупность многих файлов, доступ к которой осуществляется либо через ФС ОС, либо посредством простых СУБД (точнее, систем программирования с элементами СУБД), таких, как Access, Foxpro (см. гл. 3).

На уровне информационных систем [2, 10, 24] БД является компонентой модели предметной области ИС и обычно поддерживается мощной СУБД (Oracle, Adabas, SQL Server, см. гл. 4), автономно реализующей основные операции доступа к данным, размещенным в небольшом количестве файлов ОС, без активной эксплуатации возможности ФС.

На уровне информационных ресурсов [2, 10, 26] БД представляет собой предметно-ориентированную коллекцию информации, содержащую несколько миллионов записей (например, INPADOC — БД по патентным документам, INSPEC — БД по техническим наукам, MEDLINE — по медицине и пр.). В качестве программного обеспечения здесь обычно используются автоматизированные информационно-поисковые системы (АИПС), ориентированные на поиск и представление слабоструктурированной текстовой информации (STAIRS, IRBIS и пр., см. [3, 10, 26]).

Классификация информации

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

Основаниями (признаками) классификации информации могут быть (табл. 1.1):

  • структура данных и форма представления информации;

  • содержание, предметная область применения (получения).

Таблица 1.1. Основные классы информации по структуре, форме и содержанию

 

Основание для классификации

Классы информации

Уровни сложности

Сигнал

Сообщение, документ

Информационный массив

Информацион­ный ресурс

Тип сигнала

Аналоговая (непрерывная)

Цифровая (дискретная)

-

-

Уровни доступа и организации

Данные в регист­ровой памяти ЭВМ

Данные в опера­тивной памяти

Файлы данных на внешних устройствах

Базы данных

Способы кодирования и представления (дан­ные, файлы и БД)

Цифровая (вычис­лительные дан­ные, двоичные)

Символьная (ал­фавитно-цифро­вая, строчная)

Графическая

Мультимедийная

Организация данных (файлы и БД)

Табличная

Текстовая

Графическая (мульти­медиа)

-

Содержание

Биржевая и фи­нансовая

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

Научно-техническая, правовая, медицин­ская

Потребитель­ская, бытовая, развлекательная

Отметим, что разделение информации на табличную (числовую), текстовую и графическую отражает последовательность, в которой эти виды «осваивались» компьютерами. Первоначальные языки программирования (ЯП) были рассчитаны прежде всего на обработку числовой (Fortran, Algol), нежели символьной информации. Раньше появляются и табличные базы данных, так­же преимущественно рассчитанные на обработку числовых таблиц (файлов). Затем осваиваются текстовые файлы (текстовые редакторы) и текстовые БД (автоматизированные информационно-поисковые системы — библиографические и полнотекстовые). Наконец, с существенным повышением быстродействия и емкости памяти компьютеров, на сцену выходят графические и другие мультимедийные файлы (графические, аудио-, видеоредакторы). Говорить о графических (мультимедиа) базах данных и ЛИС пока все же преждевременно.

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

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

Представление символьных данных

Рассмотрим методы дискретного представления информации, или кодирования (которые, заметим, появились задолго до эры вычислительных машин).

Первым широко известным примером является азбука Морзе (табл. 1.2), в которой буквы латиницы (или кириллицы) и цифры кодируются сочетаниями из «точек» и «тире». Воспользуемся данным кодом для иллюстрации основных понятий, связанных с кодированием (не вдаваясь в теорию кодирования).

Таблица 1.2. Фрагменты кода Морзе

Символ входного алфавита

Мнемоническое обозначение по МСС*

Кодовая (знаковая) комбинация

А В С

Y Z

alfa bravo Charlie

yankee zulu

 

*Международный свод сигналов

 

Кодируемые (обозначаемые) элементы входного алфавита обычно называют символами.

Кодирующие (обозначающие) элементы выходного алфавита называются знаками; количество различных знаков в выходном алфавите назовем значностью (-арностью, -ичностью); количество знаков в кодирующей последовательности для одного символа — разрядностью кода; последовательным кодом является такой, в котором знаки следуют один за другим во времени (например, радио- или оптические сигналы либо передача по двум проводам, 2-жильному кабелю), параллельным — тот, в котором знаки передаются одновременно (например, по четырем проводам, 4-жильному кабелю), образуя символ (т. е. символ передается в один прием, в один момент времени). Применительно к азбуке Морзе (AM):

  •  символами являются элементы языкового алфавита (буквы A—Z  или  А—Я)  и  цифровой  алфавит  (здесь —  цифры 0-9);

  •  знаками — «точка» и «тире» (или «+» и «-» либо «1» и «0», короче — два любых разных знака);

  •  поскольку знаков два, AM является двузначным (бинарным, двоичным) кодом, если бы их было 3, то мы имели бы дело с троичным, тернарным, трехзначным кодом;

  • поскольку число знаков в AM колеблется от 1 (буквы «Е», «Т») до 5 (цифры), здесь имеет место код с переменной разрядностью (в AM часто встречающиеся в тексте символы обозначены  более  короткими  кодовыми  комбинациями, нежели редкие символы);

  • так как знаки передаются последовательно (электрические импульсы, звуковые или оптические сигналы разной длины, соответствующие «точкам» и «тире»), AM есть последовательный код.

Первые опыты телеграфной и радиосвязи осуществлялись именно посредством AM, причем приемное устройство записывало импульсы переменной длины в виде «точек» и «тире» на движущуюся телеграфную ленту, однако уже в начале XX в. был осуществлен переход на 5-разрядный (5-битовый) телеграфный код.

В табл. 1.3, 1.4 приводится перечень наиболее известных кодов, некоторые из них использовались первоначально для связи, кодирования данных, а затем для представления информации в ЭВМ:

  • код Бодо — 5-разрядный код, бывший в прошлом европейским  стандартом для телеграфной  связи  (другое  название — IA-1 — international alphabet #1);

  •  М-2 (российское обозначение), или 1А-2 (международное обозначение), — телеграфный код, предложенный Международным консультационным комитетом по телефонии и телеграфии (МККТТ) и заменивший код Бодо (табл. 1.3);

Таблица 1.3. Разрядность некоторых наиболее известных кодов

Код

Разрядность

IA-2 (М-2, МКЮТ-2)

5

Baudot (Бодо)

5

ISO-7 (IA-5, ASCII-7, USASCII, ANSI X3.4)

7

EBCDIC

8

ASCII-8

8

Hollerith (Перфокарты Холлерита)

12

Таблица 1.4. Фрагменты некоторых кодовых таблиц

 

 

Символ

IA-2

Бодо

IS0-7

EBCDIC

ASCII-8

Холлерит

А

03

10

41

С1

А1

900

В

19

06

42

С2

А2

880

С

16

43

СЗ

A3

840

D

09

44

С4

А4

820

а

 

 

61

81

Е1

 

b

 

 

62

82

Е2

 

с

 

 

63

83

ЕЗ

 

d

 

 

64

84

Е4

 

. (точка)

05

842

,(запятая)

ОС

09

242

:(двоеточие)

 

ЗВ

40А

? (вопрос)

10

00

3F

6F

5F

206

  1.  ASCII (American Standard Code for Information Interchange) — стандартный 7-битовый код для передачи данных, поддерживает 128 символов, включающих прописные и строчные символы латиницы, цифры, специальные значки и управляющие символы. Этот код, к которому были добавлены некоторые национальные символы (10 бинарных комбинаций), был принят Международной организацией по стандартизации (ISO) как стандарт ISO-7;

  2. EBCDIC (Expanded Binary Coded Decimal Information Code) — 8-разрядный код, предложенный фирмой IBM для машин серий IBM/360-375 (внутреннее представление данных в памяти), а затем распространившийся и на системы других производителей;

  3. ASCI 1-8 — 8-разрядный код, принятый для внутреннего и внешнего представления данных в вычислительных системах.  Включает стандартную часть (128 символов) и национальную (128 символов).

Соответственно в зависимости от национальной части кодовые таблицы различаются (табл. 1.5); код Холлерита, предложенный для ПК (1913 г.), затем использовавшийся для кодирования информации перед вводом в ЭВМ с перфокарт.

Таблица 1.5. Некоторые кодовые таблицы ACSCII

 

Наименование кодовой страницы (Code Page)

Интерпретация кодовой страницы

Latin-1

Международный стандарт (ISO-8859-1) для интерпретации 2-й половины (128-256) кода ASCII, таблица предназначена для латиницы

Latin-8

Международный стандарт (ISO-8859-8) для иврита

Latin-C

Международный стандарт (ISO-8859) для кириллицы

CP-437

Стандарт IBM для интерпретации 2-й половины (128-256) кода ASCII, таблица предназначена для греческого алфавита

CP-850

Стандарт IBM для восточноевропейских алфавитов

CP-852

Стандарт IBM для греческого алфавита

CP-862

Стандарт IBM для иврита

CP-866

Стандарт IBM для русской кириллицы

Одним из «последних слов» в процессе развития систем символьного кодирования является универсальный код UNICODE (UNIversal CODE) — стандарт 16-азрядного кодирования символов.

Стандарт UNICODE разработан техническим комитетом, в который вошли представители ряда ведущих фирм. Он определяет коды, обеспечивающие идентификацию различных символов: букв, иероглифов, цифр и т. д. Код может использоваться вместо 7—8-битовых, в том числе и ASCII. Поскольку в 16-разрядном UNICODE можно закодировать 65 536 символов вместо 128 в ASCII, то отпадает необходимость в создании модификаций таблиц кодов. Это существенно упрощает обработку тексто­вых файлов, хотя и несколько увеличивает их размеры.

UNICODE охватывает 28 000 букв, знаков, слогов, иероглифов национальных языков мира, 30 000 мест в UNICODE зарезервировано. Использование этого резерва дает возможность пользователям вводить математические или технические символы, а также создавать свои собственные символы.

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

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

Кодирование и обработка чисел

Кроме кодирования символов в ЭВМ очевидное и важное значение имеют кодирование и представление чисел.

Системы счисления. Человек считает предметы десятками, сотнями: десять единиц образуют десяток, десять десятков — сотню, десять сотен — тысячу и т. д. Это — десятичная система счисления, которая не является единственно возможной. Существует, например, двенадцатеричная система (счет идет на дюжины) или римская система счисления.

Наиболее естественный способ представления числа в компьютерной системе заключается в использовании строки битов, называемой двоичным числом — числом в двоичной системе счисления.

Система счисления — способ именования и изображения чисел с помощью символов, имеющих определенные количественные значения. В зависимости от способа изображения чисел системы счисления делятся на непозиционные и позиционные:

    1. В непозиционной системе цифры не меняют своего количественного значения при изменении их расположения в числе;

    2. В позиционной системе счисления количественное значение каждой цифры зависит от ее места (позиции) в числе.

Десятичная система счисления является позиционной, так как значение каждой цифры зависит от ее места (позиции) в числе.

Например:

23 = 2x10 + 3;

32 = 3 х 10 + 2 и 23*32.

Римская система счисления является смешанной, так как значение каждой цифры частично зависит от ее места (позиции) в числе. Так в числах VII, VI, IV цифра V обозначает 5, а I обо­значает 1.

Но, с другой стороны, важно, как цифры расположены относительно друг друга:

VII = 5+1 + 1=7,

VI = 5+ 1 =6,

IV = 5 - 1 = 4.

Основание системы счисления — количество (Р) различных цифр, используемых для изображения числа в позиционной системе счисления.

Значения цифр лежат в пределах от 0 до Р - 1.

В общем случае запись любого числа N в системе счисления с основанием Р будет представлять собой ряд (многочлен) вида

N = am-1 Pm-1 + am-2 Pm-2 +…+ ak Pk…+ a1 P1 + a0 P0 +…+ a-1 P-1 + a-2 P-2 +…+ a-s P.(1.1)

Нижние индексы определяют местоположение цифры в числе (разряд):

         положительные значения индексов — для целой части числа разрядов);

         отрицательные значения — для дробной (s разрядов).

Имея в целой части числа т разрядов, а в дробной — s, мож­но записать Pm+S разных чисел.

Двоичная система счисления имеет основание Р=2 и использует для представления информации две цифры — 0 и 1.

Существуют правила перевода чисел из одной системы счисления в другую, основанные в том числе и на выражении (1.1).

Например, двоичное число 101110,101 равно десятичному числу 46,625:

101110,1012 = 1 25 + 0 24 +1 23 + 1 22 + 1 21 + 0 20 + 1 2-1 + 0 2-2 + 1 2-3 = 46,62510.

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

Таким образом, для перевода числа из позиционной системы счисления с любым основанием в десятичную систему счисления можно воспользоваться выражением (1.1).

Обратный перевод из десятичной системы счисления в систему счисления с другим основанием непосредственно по (1.1) затруднителен, поскольку все арифметические действия, предусмотренные этой формулой, следует выполнять в той системе счисления, в которую число переводится. При переводе смешанного числа следует переводить его целую и дробную части отдельно.

Кроме двоичной и десятичной при работе с компьютером часто используются также двоично-десятичная и шестнадцатеричная системы счисления (табл. 1.6).

Перевод чисел из шестнадцатеричной системы счисления в двоичную весьма прост — он выполняется поразрядно.

Для изображения цифр, больших 9, в шестнадцатеричной системе счисления применяются буквы А =10, В =11, С =12, D= 13, Е= 14, F= 15.

Например, шестнадцатеричное число F17B в двоичной системе выглядит так: 1111000101111011, а в десятичной — 61819.

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

Двоично-десятичная система не экономична с точки зрения реализации технического построения машины   (примерно  на

Таблица 1.6. Перевод цифр из двоичной системы счисления в восьмеричную и десятичную и наоборот

 

Триада

Восьмеричная цифра

Тетрада

Шестнадцатеричная цифра

Десятичное число

Двоично-десятичная запись

000

0

0000

0

0

0000-0000

001

1

0001

1

1

0000-0001

010

2

0010

2

2

0000-0010

011

3

0011

3

3

0000-0011

100

4

0100

4

3

0000-0100

101

5

0101

5

5

0000-0101

110

6

0110

6

6

0000-0110

111

7

0111

7

7

0000-0111

 

 

1000

8

8

0000-1000

 

 

1001

9

9

0000-1001

 

 

1010

А

10

0001-0000

 

 

1011

В

11

0001-0001

 

 

1100

С

12

0001-0010

 

 

1101

D

13

0001-0011

 

 

1110

Е

14

0001-0100

 

 

1111

F

15

0001-0101

20 % увеличивается требуемое оборудование), но очень удобна при подготовке задач и при программировании. В двоично-десятичной системе счисления основанием системы счисления является число 10, но каждая десятичная цифра (0, 1, ..., 9) кодируется двоичными цифрами.

Представление чисел в ЭВМ

В ЭВМ применяются две формы представления чисел:

  • естественная форма, или форма с фиксированной запятой (точкой), — ФЗ (ФТ);

  • нормальная форма, или форма с плавающей запятой (точкой), - ПЗ (ПТ).

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

Например, пусть числа представлены в десятичной системе счисления и имеют пять разрядов в целой части числа (до запятой) и пять в дробной части (после запятой). Числа, записанные в такую разрядную сетку, имеют вид

+00721.35500;

+00000.00328.

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

В памяти ЭВМ числа с фиксированной точкой хранятся в трех форматах:

  •  полуслово — это обычно 16 бит или 2 байта;

  •  слово — 32 бита или 4 байта;

  • двойное слово — 64 бита или 8 байтов.

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

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

  • мантисса;

  • порядок.

При этом абсолютная величина мантиссы должна быть меньше 1, а порядок — целым числом.

Например, приведенные ранее числа в нормальной форме запишутся следующим образом:

+0,721355 х 103;

+0,328 х 10 3.

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

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

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

10,3510 = 0,103510 х 10+2; 0,000072458 = 0,72458 х 8"4; F5C,9Bl6 = 0,F5C9Bl6x 16+3.

В памяти ЭВМ числа с ПТ хранятся в двух форматах:

  •  слово — 32 бита или 4 байта;

  • двойное слово — 64 бита или 8 байт.

Алгебраическое представление двоичных чисел.

Знак числа обычно кодируется двоичной цифрой, при этом:

  •  код 0 означает знак «+» (плюс);

  • код 1 — знак «-» (минус).

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

  • обратный;

  •  дополнительный.

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

Обратный код числа N обозначим [N]обр. Пусть N= я,, а2, а3, ..., ат и а обозначает инверсию а, т. е. если а =1, то а= 0, и наоборот. Тогда

при N > 0, [N]обр = 0, a1,a2,a3, … , am;

при N < 0, [N]обр = 1,a1,a2,a3, …, am;

при N= 0 имеет место неоднозначность [0]обр = 0,00 ... 0 = 1,11...1.

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

Например:

для N =1011, [N]обр = 0,1011;

для N = -1011, [N]обр = 1,0100.

Дополнительный код числа N обозначим [N]mTl.                                                                                 

Пусть, как и выше, обозначает N=a1,a2,a3, …,am  и a    величину, обратную а (инверсию а), т. е. если а = 1, то ã=0, и наоборот. Тогда

 при N ≥ 0, [N] доп = 0, a1, a2, a3, …, am;

 при N ≤ 0, [N] доп = 1, ã1, ã2, ã3, …, ãm+0,00…1.

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

Например:

 Для N = 1011, [N] доп = 0,1011;

Для N = -1100, [N] доп = 1,0100;

Для N = -0000, [N] доп = 10,0000= 0,0000 (1 исчезает)

 Неоднозначности в изображении 0 нет.

Эмпирическое правило: для получения дополнительного кода отрицательного числа необходимо все символы этого числа инвертировать, кроме последней (младшей) единицы и тех нулей, которые за ней следуют.

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

Типы данных — это совокупность соглашений о программно-аппаратурной форме представления и обработки, а также ввода, контроля и вывода элементарных данных.

Структуры данных — способы композиции простых данных в агрегаты и операции над ними.

Форматы файлов — представление информации на уровне взаимодействия операционной системы с прикладными программами.

Типы данных (табл. 1.7). Ранние ЯП, а точнее, системы программирования (СП) — Фортран, Алгол, будучи ориентированными исключительно на вычисления, не поддерживали развитых систем типов и структур данных.

Таблица 1.7. Типы и структуры данных в некоторых системах программирования и управления данными

 

Система- язык программирования, СУБД, ИПС

Данные

Algol

Cobol

PL/1

FoxBase/ Clipper

Adabas/ Natural

Oracle/ SQL

STAIRS, IRBIS, ISIS

 

Целое короткое (2 байта)

-

-

-

-

-

Small-int

-

 

Целое норм. (4 байта)

Integer

Compu­tational

Int

N(x)

N(x)

Int

-

 

Целое длинн. (8 байт)

-

-

Double

-

-

-

-

 

Действительное норм. (4 байта)

Real

Compu­tational

Float

N(x.y)

N(x.y)

Float Real

-

 

Действ, двойное (8 байт)

-

-

-

-

-

Roat Double

-

 

Двоичное

-

-

Binary

-

B(xj

-

-

 

Десятичное упакованное (2 цифры на байт)

-

PIC(9)

Decimal

-

P(x)

-

-

 

Десятичное распакован­ное (1 цифра на байт)

-

PIC(X)

-

N(x)

U(x)

-

-

 

Логическое

Boolean

-

+

Logical

-

-

-

 

Символьное

-

PIC(A)

Char

C(x)

A(x)

Char

+

 

Длинный текстовый или бинарный объект (BLOB)

-

-

-

Memo

-

VarGrafic VarChar

-

 

Дата

-

-

-

Date

-

Date

-

 

Время

-

-

-

-

-

Time

-

 

Массивы

Array

-

Dim

Dimention

VAR(n)

-

-

 

Записи (структуры)

-

+

+

+

+

+

-

 

Множественные (вектор­ные) поля записи

-

-

-

-

MU

-

+

 

Групповые поля записи

-

+

+

-

GR

-

+

 

Повторяющиеся группы в записи

-

-

-

-

PE

-

-

Текстовые поля (пара­графы, предложения, слова)

-

-   .

-

-

-

-

+

 

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

Типы числовых данных Алгола — integer (целое число), real (действительное) — различаются диапазонами изменения, внутренними представлениями и применяемыми командами процессора ЭВМ (соответственно арифметика с фиксированной и плавающей точкой). Нечисловые данные представлены типом boolean — логические, имеющие диапазон значений {true, false}.

Позже появившиеся ЯП (СП) Кобол, ПЛ/1, Паскаль предусматривают новые типы данных:

  • символьные (цифры, буквы, знаки препинания и пр.);

  • числовые символьные для вывода;

  • числовые двоичные для вычислений;

  • числовые десятичные (цифры 0—9) для вывода и вычислений.

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

Уместно привести пример представления числовой информации в различных перечисленных формах. Пусть задано число 13510 = 2078 = 87|16= 1000001112:

  • внутренняя стандартная форма — тип binary — представления для обработки в двоичной арифметике сохраняется (1000001112). Объем — 1 байт, 8 двоичных разрядов;

  • внутренняя форма двоично-десятичного — тип decimal —представления: каждый разряд десятичного числа представляется двоично-десятичной (4 бита) комбинацией. Представление 135 есть 001 011 1012. Объем — 2,5 байта, 12 двоичных разрядов;

  • символьное представление (для вывода)  — тип alphabetic — каждый разряд представляется байтом в соответствии с кодом ASCII.

Представление 135 есть 00110001 00110011 001101012. Объем — 3 байта.

Появление СУБД и СП для разработки ИС приводит к появлению новых типов данных:

Дата и время.

Бинарные (BLOB — Binary Large Object) и текстовые объекты без внутренней структуры (интерпретация возлагается на прикладные программы).

Понятие типа данных ассоциируется также с допустимыми значениями переменной и операциями над ними, например, данные типа время (чч:мм:сс) или дата (гт/мм/дд) предполагают определенные диапазоны значений каждого из разрядов, а также машинные или эмулируемые операции (сложение/вычитание дат и/или моментов времени). Основной причиной «проблемы 2000 года» являлась не столько двухразрядная запись года в базах данных, сколько встроенные в огромное количество программ (часто недокументированных) операции над данными типа date —гт/мм/дд.

Структуры данных. В языке Алгол определены два типа структур — элементарные данные и массивы (векторы, матрицы, тензоры, состоящие из арифметических или логических переменных (рис. 1.2, а, б, в)). Основным нововведением, появившимся первоначально в Коболе (затем ПЛ/1, Паскаль и пр.), являются агрегаты данных (структуры, записи), представляющие собой именованные комплексы переменных разного типа, описывающих некоторый объект или образующих некоторый достаточно сложный документ (рис. 1.2, г).

Термин запись подразумевает наличие множества аналогичных по структуре агрегатов, образующих файл (картотеку), содержащих данные по совокупности однородных объектов, элементы данных образуют поля, среди которых выделяются элементарные и групповые (агрегатные). В языках ПЛ/1, Паскаль появляются массивы записей (рис. 1.2, д).

С появление СУБД и ЛИПС возникают новые разновидности структур:

  • множественные поля данных (рис. 1.2, е);

  • периодические групповые поля (рис. 1.2, ж);

Текстовые объекты (документы), имеющие иерархическую структуру (документ, сегмент, предложение, слово)   — рис. 1.2,

Рис. 1.2. Структуры данных:

а. - одномерный массив (символическое изображение); б — графическое изображение; в — двумерный массив (матрица); г — запись (структура, агрегат данных); д - массив в записи (множественное поле записи); е — массив агрегатов; ж — массив агрегатов в записи (повторяющаяся группа); з — документ библиографической БД IN IS [10]

Рис. 1.2. Структуры данных (окончание)

Некоторые обобщенные представления о структурах данных

Линейные структуры. К линейным структурам относятся массивы и последовательности, таблицы.

Порядок следования (и соответственно выборки) элементов таких структур имеет линейный характер и соответствует порядку расположения элементов в памяти: один за другим без каких-либо промежутков. Адрес элемента соответствует его положению и определяется индексом — порядковым номером элемента в последовательности размещения. К элементу имеется прямой доступ, если известен его индекс.

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

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

Последовательность, так же как и массив, представляет собой совокупность однотипных элементов. Однако число элементов до размещения неизвестно. И, хотя каждая конкретная последовательность имеет конечную длину, до начала обработки (и соответственно размещения) необходимо считать длину последовательности бесконечной. Принципиальность такого предположения выражается в том, что необходимо предусматривать специальную процедуру использования памяти (выделения/освобождения) и, возможно, алгоритм обработки последовательности по частям. Важность рассмотрения такого типа данных обусловлена тем, что именно он превалирует в операциях ввода-вывода с устройствами внешней памяти. Именно последовательный доступ позволяет организовать «потоковые» операции: однородность позволяет рассматривать пересылаемые данные как непрерывный поток. Поток не может быть прерван по контекстно определяемому условию, например, при пересылке текста — по значению кода «перевод строки», и это не заставляет программу анализировать значение каждого очередного элемента. И, кроме того, последовательный доступ — это простота управления памятью и устройством ввода-вывода.

Разновидностями последовательностей являются также не рассматриваемые здесь очереди и стеки, которые отличаются тем, что для них устанавливаются особые схемы добавления (размещения в памяти) новых элементов и их выборки. Для очереди порядок размещения/выборки определяется правилом «первым размещен — первым выбран», для стека — «первым размещен — последним выбран». Кроме того, выборка элемента влечет его удаление из последовательности.

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

Однако с точки зрения размещения элементов таблица может быть представлена как одномерный массив (или, в случае БД, последовательность) с однородными композиционными элементами, каждый из которых представляет собой совокупность разнотипных элементов. Именно это позволяет свести ввод-вывод таких типов структур к последовательным элементарным операциям.

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

Нелинейные структуры.

Примерами нелинейных структур являются списки, деревья и сети.

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

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

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

Таким образом, с точки зрения физической реализации элемент списка должен быть составным, включающим собственно информативные данные, несущие смысловое значение, и дополнительные данные {ссылки), определяющие порядок доступа к информативным элементам.

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

Деревья. Дерево (рис. 1.3) представляет собой иерархию элементов, называемых узлами. На самом верхнем уровне иерархии имеется только один узел — корень. Каждый узел, кроме корня, связан с одним узлом на более высоком уровне, называемым исходным узлом для данного узла. Каждый элемент имеет только один исходный узел. Каждый элемент может быть связан с одним или несколькими элементами на более низком Уровне, которые называются порожденными. Элементы, расположенные в конце ветви, т. е. не имеющие порожденных, называются листьями.

Рис. 1.3. Пример структуры типа дерево

Существует несколько способов представления структуры дерева. Например, дерево может быть определено как иерархия узлов с попарными связями, в которой:

  • самый верхний уровень иерархии имеет один узел, называемый корнем;

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

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

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

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

Выделяют три метода обхода: сверху вниз, слева направо, снизу вверх.

Регулярность обхода дерева может быть связана с упорядоченными деревьями, к которым относятся сбалансированные (рис. 1.4) и двоичные деревья (рис. 1.5).

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

Двоичные деревья — это особая категория сбалансированных древовидных структур, в которой допускается не более двух ветвей для одного узла. На рис. 1.5 показано несбалансированное двоичное дерево.

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

Если бы были показаны оба родителя, то это была бы более сложная структура.

В сетевой структуре любой элемент может быть связан с любым другим элементом. Примеры сетевых структур приведены на рис. 1.6.

Рис. 1.6. Пример сетевых структур

Так же как и в случае древовидных структур, сетевую структуру можно описать с помощью исходных и порожденных элементов. Удобно представлять ее так, чтобы порожденные элементы располагались ниже исходных. При рассмотрении некоторых сетевых структур естественно говорить об уровнях, так же как и в случае древовидных структур.

Во многих сетевых структурах, задающих связи между элементами, представление отношений между исходными и порожденными элементами аналогично представлению отношений в случае дерева: отношение исходный порожденный является сложным (указывается сдвоенными стрелками), а отношение порожденный исходный — простым (указывается одинарными стрелками).

1.2. Управление данными. Файловые системы

Организация данных на машинных носителях (предварительные соображения)

Накопители на магнитных носителях, файлы, циклы обработки.

Накопители данного типа являются основной средой хранения информации в ЭВМ и разделяются на магнитные ленты

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

Файл (набор данных на внешнем носителе) рассматривается как совокупность записей одинаковой структуры, каждая из которых представляет собой набор (агрегат) разнородных данных (в языках программирования PL/1, Pascal, Си за подобными объектами так и закрепилось название структура structure).

Понятие файла появляется впервые в операционной системе OS/360 фирмы IBM, причем в ранних версиях системы «настоящим файлом» считался только перфокарточный массив (file = = картотека), данные на МД и МЛ обозначались как DS (Data Set — набор данных). В последующих ОС (RSX, UNIX, MS-DOS) файлами становятся именованные организованные наборы данных на любых носителях и устройствах, за сохранность и обновляемость которых (а также передачу в прикладные программы/из прикладных программ) и несет ответственность ОС ЭВМ.

В зависимости от типа и назначения файлов и возможностей ОС (методов доступа) файл может передаваться в прикладную программу как целое, или блоками (физическими записями) и логическими записями (строками, словами, символами).

В системе OS/360 основную роль играли два типа файлов:

  • символьные (исходные программы или данные);

  • двоичные (программы в машинных кодах).

В современных системах активно используется значительно большее разнообразие файлов, из которых мы перечислим наиболее типичные (табл. 1.8):

текстовые файлы — обобщенное название для простых и размеченных текстов, ASCII-файлов и других наборов данных символьной информации, которые интерпретируются и обрабатываются текстовыми редакторами, процессорами, анализаторами (Lexicon, Word, TEC, анализаторы SGML, HTML);

текст без разметки (планарный)  —  файл, содержащий только отображаемые (воспроизводимые на всех печатающих устройствах и терминалах) символы кода ASCII, а так

Таблица 1.8. Основные типы файлов, обрабатываемых в ПЭВМ 

Тип, расширение имени

Вид информации, содержащейся в файле

exe, com

Программа, готовая к исполнению

bat

Текстовый командный файл

sys

Системный файл

ovl, ovr

Оверлейный файл

txt, 1st

Текстовый файл в формате DOS

doc

Документ (чаще всего в формате WinWord)

rtf

Размеченный текстовый файл (Rich Text Format)

dot

Файл формата документа (Document Type)

pdf

Формат документа Adobe Acrobat

wri

Документ редактора Write для Windows;

bak, old

Старая копия файла, создаваемая перед его изменением

arj, rar, zip, lzh, arc

Архивные файлы

bas

Текст программы на языке Basic

pas

Текст программы на языке Pascal

с

Текст программы на ЯП Си

bmp, pcx, gif, tif, jpg

Графические файлы

dbf

Файлы базы данных формата DBase, Foxpro, Cliper

xls

Электронные таблицы EXCEL

lib, dll

Файлы библиотек

hip

Файл справки (подсказки, помощи)

mnu

Файл меню

wav, mid, mp3, mod

Звуковые файлы

avi, mov, mpg

Файлы видеоклипов

же простейшие управляющие символы: возврат каретки (cr); перевод строки (lf); символ табуляции (tab), иногда — новая страница (lf);

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

ASCII-файл — содержит только отображаемые коды кодовой  таблицы  ASCII   (латиница  и  служебные  символы), обычно применяется для хранения документов с символьной разметкой (RTF, SGML, HTML);

табличный  файл  —  содержит  форматированные  данные (символьные, численные и  др.), образующие  строки  и столбцы таблиц, создаваемых и обрабатываемых табличными СУБД (FoxPro, Clipper, MS Access) и/или процессорами (SuperCalc, MS Excell и др.);

графический файл — бинарный файл, содержащий графическую информацию. Форматы: tif (Tagged Image File), BMP
(Bit-Mapped Picture), а также ряд других — PCX, pic и т. д.;

мулыпимедиафайлы — бинарные, содержащие оцифрованную аудио- (типы wav или MIDI-Sequencer), видео- (фор­
мат MPEG) или смешанную информацию.

Цикл обработки файла (например, внесение изменений в счета клиентов) включает следующие операции:

открытие файла — занятие устройства, на котором файл размещен (например, МД), создание в ОП управляющего
блока,
в котором записывается справка о состоянии файла и буфера (или набора буферов — буферного пула) для хранения текущей, обрабатываемой записи файла;

организация цикла, управляемого файлом (заканчивается по исчерпании   записей   файла   —   наступлении   состояния EOF — end-of-file), после чего выполняется некоторый оператор, обычно завершения обработки. Цикл должен содержать команду типа read, get (ввод записи), put, write (вывод записи) либо rewrite (обновить запись). Команда read может являться функциональным аналогом заголовка цикла;

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

Адресация, имена, спецификация данных в ОС.

Как уже отмечалось ранее, понятие «управление данными» является характерным не только для ОС, но и для СУБД (систем управления базами данных). В чем же заключается различие?

На уровне ОС осуществляется связь между адресом данных и именем (файла). На уровне СУБД — между содержимым и адресом данных. В эпоху до появления ОС и систем программирования (СП) программист должен был писать программы в непосредственных адресах ЭВМ. Элементом такой программы является команда в абсолютных адресах, например (как это было в очень популярной в свое время двухадресной машине Минск 22/32):

10   00   1234   7653

(«сложить содержимое адреса 12348  с содержимым адреса 76538 и записать по адресу 76538»).

При этом управление данными на внешних носителях состояло в написании команд вида

45 00 1200 0000 47 00 0002 1234

(«на устройстве накопления данных на МЛ перемотать ленту на 128 зон (блоков), затем прочитать две зоны в оперативную память, размещая данные с адреса 12348»).

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

Например, типовая спецификация файла MS-DOS выглядит так:

С:\WIN98_SE\PROGRAMMS\.

Вначале для большинства ОС были установлены ограничения на длину и состав имени файла, во многом аналогичные ограничениям на идентификаторы переменных, принятых в то время в языках программирования:

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

  • имя должно начинаться с буквы;

  • длина имени файла не более 8 символов, длина расширения (типа) не более 3.

В дальнейшем, по мере развития и распространения ОС, эти ограничения во многом стали сниматься:

  • появилось понятие длинного имени файла, включающего ранее запрещенные символы (пробелы и пр.);

  • были разрешены национальные символы в наименованиях файлов (кириллица и пр.).

Накопители на магнитных лентах

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

Магнитные ленты для цифровой записи данных размещаются на бобинах или кассетах (подобно лентам для бытовой аудио или видеозаписи). Однако принципы размещения информации на МЛ в данном случае существенно другие (рис. 1.7):

  • информация размещается на носителе в виде блоков (массивов данных фиксированной или переменной длины);

  • информационные блоки разделены пустыми промежутками (gap), позволяющими считывающему устройству  распознать начало (окончание) блока. Размер промежутка между записями выбирается достаточным для разгона ленты до установленной скорости и остановки ее точно на следующем промежутке. Недостаток промежутков между записями — уменьшение полезного объема МЛ, так как области, отведенные под промежутки, нельзя использовать для хранения данных. Частично указанный недостаток устраняется блокированием, суть которого состоит в объединении нескольких записей в блоки;

  • блоки разделяются на информационные (ИБ — распознаются программами) и служебные(распознаются  устройством — конец файла и конец тома);

Рис. 1.7. Структура данных на магнитных лентах:

J — физическое начало ленты (начальный ракорд); 2 — информационные блоки (ИБ) 1-го файла; 3 — GAP, промежуток между блоками; 4 — конец файла (EOF — end-of-flle), служебный блок, задающий конец 1-го файла; 5 — информационные блоки (ИБ) 2-го файла; 6 — конец 2-го файла; 7— служебный блок, задающий логический конец ленты (EOV — end-of-volume); 8 — физический конец ленты (ракорд)

  • физическое начало и физический конец ленты обычно определяются оптическим или механическим образом (независимо от содержания ленты).

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

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

Типы записей

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

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

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

На логическом уровне выделяют следующие типы (рис. 1.8):

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

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

Организация физической записи для достаточно часто встречающегося случая блокирования логических записей фиксированной или переменной длины представлена на рис. 1.9.

При этом структура представления логической записи переменной длины отличается тем, что байтам содержания — собственно данным, образующим логическую запись, — предшествуют байты значения длины содержания этой логической записи (L на рис. 1.8).

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

Рис. 1.8. Способы организации файлов данных:

а — потоко-ориентированный файл; б — записи фиксированной длины (ФД); в — ФД с блокировкой; г — записи переменной длины (ПД); д — ПД с блокировкой; е — записи неопределенной длины; ЕОВ — конец блока; EOF — конец файла; Lбайт длины записи

Рис. 1.9. Логические и физические записи

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

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

Физические записи на носителе следуют непосредственно друг за другом. При этом выделение отдельной записи может производиться двумя способами, определяемыми технологиями записи данных на носитель:

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

  • второй способ — это размещение байтов следующей записи непосредственно за последним байтом предыдущей записи без каких-либо разделителей. Для этого способа характерна меньшая зависимость от особенностей устройства: оптимизация процессов ввода-вывода, в том числе блокирование записей, переносится в прикладную программу.

Накопители на магнитных дисках.

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

Прежде всего, практически во всех современных компьютерах основными устройствами внешней памяти являются магнитные диски с подвижными головками, и именно они служат для хранения файлов [24, 25, 31]. Магнитные диски представляют собой пакеты магнитных пластин (платтеров), между которыми на одном рычаге двигается пакет магнитных головок. Шаг движения пакета головок является дискретным, и каждому положению пакета головок логически соответствует цилиндр магнитного диска. На каждой поверхности цилиндр «высекает» дорожку, так что каждая поверхность содержит число дорожек, равное числу цилиндров. При разметке магнитного диска (специальном действии, предшествующем использованию диска) каждая дорожка размечается на одно и то же количество блоков таким образом, что в каждый блок можно записать по максимуму одно и то же число байтов. Таким образом, для выполнения обмена с магнитным диском на уровне аппаратуры нужно указать номер цилиндра, номер поверхности, номер блока на соответствующей дорожке и число байтов, которое нужно записать или прочитать от начала этого блока.

Однако эта возможность обмениваться с магнитными дисками порциями, меньшими объема блока, в настоящее время не используется в файловых системах. Это связано с двумя обстоятельствами:

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

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

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

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

Распространены два основных подхода:

  • при первом подходе, применяемом, например, в файловых системах операционных систем RSX и VMS фирмы DEC, пользователи представляют файл как последовательность записей. Каждая запись — это байтовый агрегат постоянного или переменного размера. Записи можно читать или записывать последовательно или позиционировать файл на запись с указанным номером. Некоторые файловые системы позволяют разбивать записи на поля и объявлять некоторые поля ключами записи. В таких файловых системах можно потребовать выборку записи из файла по ее заданному ключу. Естественно, что в этом случае файловая система поддерживает в том же (или другом, служебном) базовом файле дополнительные невидимые пользователю   служебные   структуры   данных.   Распространенные способы организации ключевых файлов основываются на технике  хэширования  и   В-деревьев.   Существуют  также многоключевые способы организации файлов;

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

Файловые системы. Всякая операционная система создает на каждом томе (дискете, диске, пакете дисков, CD-ROM и пр.) совокупность системных данных, которая называется файловой системой (файловой структурой).

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

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

Пример простейшей (абстрактной) таблицы содержания, оглавления тома (диска, пакета дисков), которая в разных ОС имеет различные наименования — Таблица Содержания Тома (VTOC — Volume Table of Content), Таблица Размещения Файлов (FAT — File Allocation Table), Таблица Определения Файлов (FDT — File Definition Table) и т. п., приведена на рис. 1.10.

Рис. 1.10. Простейшая таблица оглавления тома

Она очень похожа на «настоящую» и состоит из четырех областей:

  • область файлов. Это таблица, имеющая обычно ограниченное (в приведенном примере N=6) число строк N (в MS-DOS, например, N- 500, т. е. число файлов не более 500). Количество столбцов М (в примере М - 5) обычно выбирается из тех соображений, чтобы 85—95 % файлов, создаваемых предполагаемыми пользователями, содержало бы не более М блоков, что зависит как от размера блока и типа пользователя, так и от общего уровня развития информационного и программного обеспечения. Первый столбец таблицы в каждой строке {заглавная запись — Title Record) содержит данные о файле, в данном примере — имя файла;

  •  область переполнения — дополнительная таблица аналогичной структуры,  в которую записываются  номера блоков особо длинных файлов (в примере — File 1).

Организация таблицы размещения в форме области файлов и области переполнения, очевидно, позволяет сэкономить на объеме таблицы в целом, не ограничивая в то же время вероятной длины файла;

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

Список сбойных блоков. Это таблица, создаваемая при инициализации (разметке) тома (диска),  пополняемая   программами диагностики (примером которых может являться хорошо известный пользователям NDD  —  Norton   Disk Doctor) и предотвращающая распределение испорченных областей на магнитном носителе под файлы данных.

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

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

Кроме того, где-то должны быть размещены метка тома (имя и тип/объем), количество занятого и свободного пространства и прочая совокупная информация по тому данных.

Перечислим особенности ситуации, зафиксированной на рис. 1.10 в простейшей (искусственной) файловой системе:

  •  File-1  занимает шесть блоков, это число больше максимального, поэтому адрес блока № 6 (23) размещен в таблице переполнения;

  • File 2 занимает два блока, что меньше ограничения, поэтому вся информация сосредоточена в области файлов.

Имеются следующие конфликтные ситуации:

  • File_3 не содержит ни одного блока (следовательно, файл был удален, но заглавная запись сохранилась);

  • File_4 и Pile 1 ссылаются на блок № 3. Это ошибка, поскольку каждый блок должен быть закреплен за единственным файлом;

  • File 1 содержит ссылку на блок № 7, помеченный как сбойный (нечитаемый). Это  приведет  к  невозможности корректно полностью прочитать данный файл — ситуация, знакомая каждому, работавшему с НГМД;

  • в  списке  свободных  блоков  содержатся   номера  блоков № 12 (помеченный как сбойный) и № 13 (распределенный под File_l).

Это очевидные свидетельства начавшегося разрушения файловой системы. Источниками перечисленных конфликтов могут быть сбои, программные ошибки (разработчиков ОС), некорректное завершение ОС или целенаправленная деятельность вирусных или иных злонамеренных программ.

Рассмотренный пример таблицы оглавления относится к случаю так называемой прямой адресации доступа (рис. 1.11). Здесь очевидны следующие особенности:


 

Рис. 1.11. Доступ к данным с прямой адресацией

  • таблица создается при инициализации и, даже будучи пустой, занимает определенный объем;

  • создание файла (даже состоящего из одного байта) приводит к выделению блока и занятию строки таблицы.

Рис. 1.12. Списковая организация доступа к данным (косвенная адресация) (а); комбинированная (мультисписковая) организация доступа (б)

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

Все операционные системы, как правило, поддерживают следующие элементы иерархических файловых систем:

  • обычные файлы, каталоги, специальные байт-ориентированные и блок-ориентированные файлы. Файл является массивом байтов (блоков фиксированной длины). Каталоги обеспечивают связь между именами файлов и собственно файлами. Каждый элемент каталога содержит имя файла и ссылку на конкретный файл. Для именования файлов используются корневой и текущий каталоги.

Внешние устройства (такие, как терминал, принтер) также часто представляются как файлы для упрощения работы с ними.

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

Известны следующие варианты:

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

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

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

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

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

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

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

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

В рамках каждой ОС и ФС существует широкий спектр средств пользователя для управления данными: создание, уничтожение, переименование и т. д. файлов, их групп. Прежде всего, здесь обычно присутствует встроенный командный интерфейс (табл. 1.8), который сопровождается различными графическими или текстовыми интерфейсами.

Таблица 1.8. Команды манипулирования файлами в операционных системах Windows, MS-DOS, UNIX

 

Команда (функция)

Операционная система

Windows, MS-DOS

UNIX

Инициализация диска, создание файловых систем

FDISK,    FORMAT

mkf s

Создание каталогов в ФС

MKDIR

mkdir

Проверка диска, файловой системы

CHKDISK

f chk ,

Проверка или установка файловых атрибутов

ATTRIB

file,chmod

Удаление каталога

RD

rkdir

Копирование файла

COPY

cp

Перемещение файла

MOVE

mv

Переименование файла

REN, RENAME

mv

Удаление файла

DEL, ERASE

rm

Поиск в файле по контексту

FIND

grep, awk

Архивация файла на МД или МЛ

BACKUP   RESTORE

TAR

Распечатка содержимого файла

TYPE   COPY

cat

Сравнение файлов

FC

comm (Common) cmp (Compare) diff (difference)

Вывод имени текущего диска, каталога

PATH

pwd

Просмотр содержания диска, каталога

DIR

li

Интерактивная оболочка PCTools. PCTools являлся первым из известных средств расширения командного языка MS-DOS, предусматривавшим достаточно типовые функции работы с устройствами, файлами, текстами. В дальнейшем был вытеснен программным средством Norton Commander.

Средство PCTools представляет пользователю два основных режима работы:

  1. файловые функции (работа на логическом уровне);

  2. специальные функции (работа на физическом уровне).

Программа PCTools выполняет следующие операции с файлами в меню файловых функций (рис. 1.13): создание и редактирование файла W, удаление файла D, перемещение файла М, переименование файла R, копирование файла на диск или на дискету С, проверка записи файла на диске V, смена атрибута файла А, сортировка по имени, расширению, размеру, времени создания файла S, редактирование файла прямо на диске Е, распечатка файла на принтере Р и др. Для выполнения этих функций следует нажать на клавишу с указанной буквой в данном меню.

Рис. 1.13. Режим работы с файлами PCTools

Программные оболочки семейства Norton Commander. Оболочка Norton Commander столь привлекательна не в последнюю очередь благодаря великолепным высокоскоростным средствам визуализации данных и развитыми средствами электронной почты. Оболочка Norton Commander (и ее аналоги — Windows Commander, Far manager) предоставляет пользователю следующие основные возможности:

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

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

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

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

  • подготовку текстовых файлов;

  • выполнение из ее среды практически всех команд DOS, Windows;запуск программ, для чего используются различные, наиболее удобные для пользователя способы;

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

  • поддержку межкомпьютерной связи через последовательный или параллельный порт (с использованием модуля);

  • поддержку электронной почты через модем по телефонным линиям связи.

К достоинствам рассматриваемой оболочки также относятся:

  • высокая степень интеграции функций;

  • поддержка    иерархической    системы    меню    (вложенных меню) для запуска программ;

  • простота освоения и удобство использования;

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

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

FAR manager — работающая в текстовом режиме программа управления файлами для Windows 95/98/NT/2000/XP с поддержкой длинных имен файлов и широким набором операций над файлами и папками-каталогами (рис. 1.14, 1.15).

FAR позволяет работать с архивами. При этом файлы в архивах обрабатываются аналогично файлам в папках. FAR сам преобразует команды в соответствующие вызовы внешних архиваторов.

Рис. 1.14. FAR manager: панель файлов (а), меню команд (б), панель информации (в)

Рис. 1.15. FAR manager: дерево папок (а) и меню правой панели (б)

FAR также обеспечивает значительное количество сервисных функций.

Проводник систем Windows. Проводник систем Windows предоставляет возможность копирования,  переноса,  уничтожения или переименования файлов (рис. 1.16). Переименование файлов «на месте» производится щелчком мыши на имени файла с последующим введением нового имени. Столь же просто и удобно выполняется работа с сетевыми ресурсами — папками и принтерами, расположенными на других ПК (если они выделены в совместное использование на последних). Другие ПК, которые в данный момент работают в локальной сети, просматриваются точно так же, как и дисковые устройства на собственном ПК. При желании может быть подключен любой из доступных ресурсов на другом ПК в качестве сетевого диска, чтобы в дальнейшем работать с ним как с обычным дисковым устройством.

Рис. 1.16. Проводник Windows 2000 — средство манипулирования файлами

Файловые системы UNIX и Windows NT (2000)

Ранее (см. рис. 1.10) была приведена структура некоторой абстрактной ФС. Рассмотрим теперь в качестве примера структуру и организацию реальных файловых систем некоторых ОС.

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

Каждая ФС, прежде чем стать доступной, должна быть смонтирована. Количество файлов в файловой системе ограничено (65 536 для UNIX версии 7).

Структура файловой системы. Каждая файловая система имеет четыре основные части:

  • загрузочный блок — самый первый блок диска (блок 0), зарезервированный для системной загрузочной программы;

  • суперблок — это первый блок собственно файловой системы (блок 1), он содержит основные данные о ФС и ее размещении на диске, в том числе о списках свободных узлов и блоков;

  • узлы — это последовательность блоков вслед за суперблоком. Каждый узел содержит ссылки на блоки. Имеется ровно один /-узел для каждого каталога или файла в файловой системе;

  • блоки — оставшееся пространство диска занимают блоки, которые содержат либо действительные данные каталогов и файлов (блоки данных), либо ссылки на блоки (косвенные блоки).

Суперблок содержит следующие данные:

  • размер дискового пространства, доступного файловой системе (в блоках);

  • число блоков, зарегистрированных для /-узлов;

  • имя файловой системы;

  • имя тома;

  • время последнего изменения;

  • время последнего копирования (Backup);

  • ссылку на список свободных блоков;

  • ссылку на список свободных /-узлов.

Структура файловой системы представлена на рис. 1.17.

Каждый файл (и каталог) в ФС представлен /-узлом, содержащим указатели на блоки, составляющие файл.

В /-узле содержатся также информация о правах доступа к файлу, число ссылок на файл из каталогов и другие данные.

Каждый /-узел содержит 13 указателей. Первые 10 указателей непосредственно ссылаются на блоки данных файла. Поскольку блок содержит 512 байтов, этого достаточно для обработки файлов до 512 х 10 = 5120 байтов.

Рис. 1.17. Физическая структура файловой системы ОС Unix

Если длина файла больше, чем 5120 байта, используется 11-й указатель /-узла, который ссылается на косвенный блок из 128 ссылок на блоки данных. Использование косвенного блока позволяет увеличить длину файла до величины 512 х (10 + 128) = = 70 656 байт.

Если и этого недостаточно, то используется 12-й указатель /-узла, ссылающийся на дважды косвенный блок (2-косвенный блок), содержащий 128 ссылок на косвенные блоки (рис. 1.17). Тогда максимальный размер файла увеличивается до величины 512 х (10 + 128 + 1282) = 8 459 264 байтов.

Наконец, использование последнего, 13-го указателя на трижды косвенный блок (3-косвенный блок) из 128 ссылок на дважды косвенные блоки дает предельную длину файла в ФС:

512 х (10 + 128 + 1282 + 1283) = 1 082 201 088 байт.

Другие версии системы UNIX могут отличаться количеством ссылок в /-узле, косвенных блоках и размером блока данных.

Когда система загружается, имеется только одна из файловых систем, называемая корневой. В ней находятся все важнейшие каталоги (/dev, /etc, /bin и пр.). Все остальные файловые системы должны быть созданы и смонтированы.

Создание и монтаж файловой системы. Команда mkfs создает новую ФС. Она расположена в каталоге /etc и имеет два параметра:

/etc/mkfs <имя> <размер>

Первый параметр является именем специального файла и указывает устройство, на котором создается ФС. Второй параметр — размер пространства файловой системы в блоках, он используется для определения по некоторым правилам числа блоков после того, как размещены /-узлы.

Файловая система NTFS (Windows NT, 2000, XР). Как и любая ФС, NTFS делит все полезное пространство диска на кластеры — блоки данных, используемые единовременно. NTFS поддерживает различные размеры кластеров — от 512 байт до 64 Кбайт, стандартом считается кластер размером 4 Кбайт.

Диск NTFS условно делится на две части (рис. 1.18). Первые 12 % диска отводятся под так называемую MFT-зону — пространство, в котором размещен метафайл MFT (Master File Table). Запись каких-либо данных в эту область невозможна. MFT-зона всегда держится пустой — это делается для того, чтобы главный служебный файл (MFT) не фрагментировался при своем расширении. Остальные 88 % диска представляют собой пространство для размещения файлов.

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

Рис. 1.18. Структура диска MTFS

Структура MFT. Каждый элемент ФС NTFS представляет собой файл, даже служебная информация. Как уже говорилось,  главный файл NTFS называется MFT или Master File

Table — общая таблица файлов, которая размещается в MFT-зоне и представляет собой централизованный каталог всех остальных файлов диска. MFT поделен на записи фиксированного размера (обычно 1 Кбайт), и каждая запись соответствует какому-либо файлу. Первые 16 файлов носят служебный характер и недоступны операционной системе — они называются мета­файлами, причем самый первый из них — сам MFT. Эти первые 16 элементов MFT — единственная часть диска, имеющая фиксированное положение. Остальная часть MFT-файла может располагаться, как и любой другой файл, в произвольных местах диска — восстановить его положение можно с помощью его самого, используя за основу первый элемент MFT.

Все пространство тома NTFS представляет собой либо файл, либо часть файла. Главная таблица файлов содержит по крайней мере одну запись для каждого файла тома, включая одну запись для самой себя.

Все файлы на томе NTFS идентифицируются номером файла, который определяется позицией файла в MFT. Каждый файл и каталог на томе NTFS определяются набором атрибутов.

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

Загрузочный сектор тома NTFS располагается в начале тома, а его копия — в середине тома. Загрузочный сектор состоит из стандартного блока параметров BIOS, количества секторов в томе, а также начального логического номера кластера основной копии MFT и зеркальной копии MFT.

Каждый атрибут файла NTFS состоит из полей: тип атрибута, длина атрибута, значение атрибута и, возможно, имя атрибута.

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

Размещение файлов.

Небольшие файлы (small). Если файл имеет небольшой размер, он может целиком располагаться внутри одной записи MFT размером 2 Кбайт (рис. 1.19, а). Из-за того что файл может иметь переменное количество атрибутов, а также

Рис. 1.19. Размещение файлов в NTFS:

а— небольшие файлы: Н — заголовок (header); SI — стандартная информация (standard information); FN — имя файла (file name); Data — данные; SD — дескриптор безопасности (security descriptor); б — большие файлы; в — очень большие файлы: ЕА — внешний атрибут (external attribute); г — сверхбольшие файлы из-за переменного размера атрибутов нельзя наверняка утверждать, что файл уместится внутри записи. Однако обычно файлы размером менее 1500 байт помещаются внутри записи MFT.

Большие файлы (large). Если файл не вмещается в одну запись MFT, этот факт отображается в значении атрибута «данные», который содержит признак того, что файл является нерезидентным и находится вне таблицы MFT. В этом случае атрибут «данные» содержит номер кластера для первого кластера каждого фрагмента данных (data run), а также количество непрерывных кластеров в каждом фрагменте (рис. 1.19, б).

Очень большие файлы (huge). Если файл настолько велик, что его атрибут данных не помещается в одной записи, этот атрибут становится нерезидентным, т. е. он размещается в другой записи таблицы MFT, ссылка на которую помещена в исходной записи о файле (рис. 1.19, в). Эта ссылка называется внешним атрибутом (external attribute). Нерезидентный атрибут содержит указатели на фрагменты данных.

Сверхбольшие файлы (extremely huge). Для сверхбольших файлов внешний атрибут может указывать на несколько нерезидентных атрибутов (рис. 1.19, г). Кроме того, внешний атрибут, как и любой другой, может храниться в нерезидентной форме, поэтому в NTFS не может быть атрибутов слишком большой длины, иначе система не сможет их обработать.

Имена файлов. NTFS поддерживает имена файлов длиной до 255 символов. Имена файлов NTFS используют набор символов UNICODE с 16-битовыми символами. NTFS автоматически генерирует поддерживаемое MS-DOS имя для каждого файла. Таким образом, файлы NTFS могут использоваться в сети операционными системами MS-DOS и OS/2.

Поскольку NTFS использует набор символов UNICODE для имен файлов, существует возможность использования некоторых запрещенных в MS-DOS символов. Для генерации короткого имени файла в стиле MS-DOS NTFS удаляет все запрещенные символы, точки (кроме одной), а также любые пробелы из длинного имени файла. Далее имя файла усекается до 6 символов, добавляется тильда (~) и номер. Расширение имени файла усекается до 3 символов.

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

Каталоги. Каждый каталог NTFS представляет собой один вход в таблицу MFT, содержащий список файлов специальной формы, называемый индексом (index). Индексы позволяют сортировать файлы для ускорения поиска, основанного на значении определенного атрибута. В файловых системах FAT и HPFS используется сортировка файлов по имени. NTFS позволяет использовать для сортировки любой атрибут, если он хранится в резидентной форме. Имеется две формы списка файлов.

Небольшие списки файлов (small indexes). Если количество файлов в каталоге невелико, список файлов может быть резидентным в записи в MFT, являющейся каталогом. В этом случае он называется небольшим каталогом (рис. 1.20, а). Небольшой список файлов содержит значения атрибутов файла. По умолчанию это имя файла, а также номер записи MTF, содержащей начальную запись файла.

Большие списки файлов (large index). По мере того как каталог растет, список файлов может потребовать нерезидентной формы хранения. Однако начальная часть списка всегда остается резидентной в корневой записи каталога в таблице MFT (рис. 1.20, б). Имена файлов резидентной части списка файлов являются узлами

Рис. 1.20. Каталоги в NTFS:

а— небольшие каталоги (#### — признак конца списка файлов); б — большие каталоги

В-дерева. Остальные части списка файлов размещаются вне MFT. Для их поиска используется специальный атрибут «размещение списка» (Index Allocation — 1А), представляющий собой набор номеров кластеров, которые указывают на остальные части списка. Одни части списков являются листьями дерева, а другие — промежуточными узлами, т. е. содержат наряду с именами файлов атрибут Index Allocation, указывающий на списки файлов более низких уровней.

1.3. Базы данных и СУБД

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

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

Известен ряд ОС, перешедших эту грань (например, ОС-360 с «индексным доступом к данным», IN-PICK, включающая язык поиска записей файлов по содержанию, UNIX, включающая команды сортировки, коррекции или объединения содержимого текстовых файлов наподобие того, как это осуществляется с таблицами данных в СУБД).

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

Предположим, что мы решили реализовать эту информационную систему на основе файловой системы и пользоваться при этом одним файлом, расширив базовые возможности файловой системы за счет специальной библиотеки функций. Поскольку минимальной информационной единицей в нашем случае является сотрудник, естественно потребовать, чтобы в этом файле содержалась одна запись для каждого сотрудника. Очевидно, что поля таких записей должны содержать полное имя сотрудника (Сотр_Имя), номер его удостоверения (Сотр_Номер), информацию о его соответствии занимаемой должности (Сотр_Статус — для простоты, «да» или «нет»), размер зарплаты (Сот_Зарп), номер отдела (Сотр_Отд_Номер). Поскольку мы хотим ограничиться одним файлом, эта же запись должна содержать имя руководителя отдела (Сотр_Отд_Рук).

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

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

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

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

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

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

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

Наконец, представим, что мы хотим обеспечить параллельную (например, многотерминальную) работу с базой данных сотрудников. Если опираться только на использование файлов, для обеспечения корректности изменений на все время модификации любого из двух файлов доступ других пользователей к этому файлу будет блокирован (вспомните возможности файловых систем для синхронизации параллельного доступа). Таким образом, зачисление на работу Петра Ивановича Сидорова существенно затормозит получение информации о сотруднике Иване Сидоровиче Петрове, даже если они будут работать в разных отделах. Реальные СУБД обеспечивают гораздо более тонкую синхронизацию параллельного доступа к данным.

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

  • приложения, для которых вполне достаточно файлов;

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

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

Структуры баз данных

Рассмотрим вкратце обобщенные логическую и физическую структуры БД.

Логическая структура БД (рис. 1.21) предполагает следующие уровни рассмотрения БД:

  • база данных (database) — включает одну или несколько подбаз (файлов, таблиц, массивов), каждая из которых состоит из агрегатов данных (записей, документов) — record. Запись идентифицируется   внутренним  номером  (ISN   —   internal sequential   number,   ВИЗ   —   внутренний   номер   записи, SDN — sequential document number и пр.);

  • запись (документ) — совокупность разнотипных и разноструктурных данных, описывающих (относящихся к) объект реального мира, элемент предметной области АИС. Запись состоит из полей (field);

  • поле — именованный элементарный или составной фрагмент записи (документа), содержащий информацию об определенном аспекте (аспектах) элемента (элементов) предметной области;

  • элементарные (имеющие фиксированную или ограниченную длину) и не содержащие входящих в них структур данных;

  • составные (групповые) поля, образующиеся как агрегаты элементарных и также имеющие фиксированную и ограниченную длину (реже переменную или неопределенную, что связано с количеством вхождений элемента в агрегат);

Рис. 1.21. Основные элементы логических структур данных в БД: / — поля записей табличных (реляционных) баз данных (ORACLE,  FoxPro, Acesss); 2 — поля записей (документов) постреляционных БД (ADABAS); 3 — поля документов ИПС (STAIRS, Dialog, IRBIS, ISIS); 4 — данные, которые могут быть связаны с полями базы данных

  • текстовые — поля переменной (неопределенной) длины и сложной внутренней структуры (обычно это иерархическая последовательность типа раздел—Подраздел—Предложение—слово);

  • бинарные — данные, интерпретируемые как поля, однако обычно  физически   не   входящие  в  состав  записей  БД. Необходимо отметить, что поля данного типа (BLOB — Binary Large Object) фактически являются данными, до обработки которых эта СУБД еще «не доросла», и потому работа с ними возлагается на пользователя (прикладные программы). В частности, в системах FoxBase и Clipper большие текстовые (так называемые MEMO) поля также не обрабатываются  системой   и  фактически  оказываются   в статусе BLOB;

  • типы данных, определяемые пользователем. Далеко не все современные СУБД поддерживают типы данных, определенные пользователем. Пока только СУБД Ingres включает такой механизм. Эта система предоставляет программисту возможность определять собственные типы данных и операции над ними и использовать их в операторах SQL. Для определения нового типа данных необходимо написать и откомпилировать функции на языке Си, после чего собрать редактором связей некоторые модули Ingres. Отметим, что введение новых типов данных является по сути изменением ядра СУБД. Важно также то, что в Ingres типы данных, определяемые пользователем, могут быть параметризованными.

Определение нового типа данных сводится к указанию его имени, размера и идентификатора в глобальной структуре, описывающей типы данных. Чтобы с новым типом данных можно было использовать функции, которые реализуют стандартные операции (сравнение, преобразование в различные форматы и т. д.), программист должен разработать их самостоятельно (интерфейс функций предопределен). Указатели на эти функции являются элементами глобальной структуры. Как только новый тип данных определен, все операции выполняются над ним, как над данными стандартного типа. Разрешение пользователю создавать собственные типы данных по сути является одним из шагов развития реляционных СУБД в направлении объектно-реляционных систем.

Поля, указанные в заштрихованных прямоугольниках (см. рис. 1.21), относятся к фактографическим ЛИС, остальные — к документальным.

Физическая структура БД в общем случае имеет вид, приведенный на рис. 1.22, и включает следующие компоненты:

файл (файлы) исходных (первичных) данных (текстов, бинарных данных) содержит собственно объекты, подлежащие
поиску, обработке и пр.;

файл (файлы) вторичной (справочной) информации (регистрационные карты, библиографические реестры и пр.) содержит описания исходных элементов (объектов). Важным видом справочных файлов являются классификаторы,


Рис. 1.22. Обобщенная физическая структура данных в БД

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

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

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

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

При любом виде добавления документа/записи для каждого поля осуществляются анализ, обработка и согласованное помещение документа и его фрагментов в соответствующие физические файлы БД.

В конкретных случаях возможна менее полная комплектность приведенной физической схемы:

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

  • в справочно-библиографических БД текстовые данные находятся во вторичном файле, а первичный отсутствует;

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

  • может  отсутствовать  частотный  словарь  или  инверсный список.

Надо отметить также вариативность физической реализации и взаимосвязи лингвистического и информационного обеспечения АИС:

  • словарь данных может физически входить в информационные файлы (первичный или вторичный);

  • классификаторы,   кодификаторы,   тезаурусы   могут   быть оформлены как физическими файлами (файлами ОС), так и входить в состав БД в виде отдельных таблиц (файлов БД, массивов и пр.) на логическом уровне и т. п.

Схема управления данными в СУБД

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

1 — прикладная программа (клиентское приложение) формирует и выдает системе управления базами данных запрос на чтение необходимых данных, содержащихся в базе;

2—3 — СУБД отыскивает описание затребованных данных в структуре описания данных прикладного уровня (внешняя модель);


Рис. 1.23. Схема обработки запроса на выборку данных из БД

 

4—5 — СУБД по глобальному описанию БД (логическая схема) определяет необходимые данные на логическом уровне;

6—7 — СУБД по описанию физической структуры БД (физическая модель) определяет физическую запись (или совокупность записей), которую необходимо считать для выборки данных, затребованных прикладной программой;

8—9 — СУБД через подсистему управления потоками данных выдает операционной системе запрос на чтение хранимой записи;

10—11 — подсистема управления вводом-ввыодом операционной системы осуществляет физическое чтение записи в системный буфер ОС (12);

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

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

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

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

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

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

СУБД обеспечивает:

  • описание и контроль данных;

  • манипулирование данными (запись, поиск, выдачу, изменение содержания);

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

  • защиту от сбоев, поддержку целостности и восстановление;

  • работу с транзакциями и файлами;

  • безопасность данных.

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

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

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

Объектно-ориентированные системы управления базами данных основываются на объектно-ориентированной архитектуре. Они позволяют работать со сложными типами данных, хранимых в виде объектов; отличаются высокой производительностью при обработке транзакций (особенно эффективны при обработке изображений). Их возникновение обусловлено потребностями разработки сложных информационных систем, неудовлетворенных технологиями предшествующих БД. В таких СУБД должны быть решены проблемы поддержки иерархии и наследования типов, управления сложными объектами. Решение этих задач сталкивается с ограничениями: отсутствием общепринятой объектно-ориентированной модели данных, декларативного языка запросов и т. п.

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

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

1. По используемому языку общения:

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

  • открытые, в которых для общения с БД используется язык программирования,   «расширенный»   операторами   языка манипулирования данными (ЯМД). В этом случае необходимо участие квалифицированного программиста.

2. По числу поддерживаемых СУБД уровней моделей данных: одно-, двух-, трехуровневые системы. Теоретически обоснован выбор трехуровневой архитектуры данных, однако на практике СУБД для персональных ЭВМ часто объединяют концептуальный и внутренний уровни представления.

3. По выполняемым функциям:

  • операционные, предполагающие иные виды обработки по получению   информации,   не  хранящейся   в  явном   виде в БД;

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

4. По сфере применения:

  • универсальные, настраиваемые на любую предметную область путем создания соответствующей БД и прикладных программ;

  • проблемно-ориентированные на определенные процедуры обработки данных, присущих конкретной области применения.

В структурном составе СУБД могут быть выделены ядро и среда (рис. 1.24) [14, 32]:

  • ядро СУБД — программный комплекс (модуль или модули), обеспечивающий  непосредственное  выполнение  физических операций над БД (в ранних системах функции ядра выполняли программы методов доступа ОС ЭВМ);

Рис. 1.24. Типичная структура системы управления базами данных

  • среда — совокупность интерфейсных модулей, обеспечивающих связь пользователей с ядром и через него с БД. Среда включает в себя утилиты   администратора БД (АБД) и пользовательские интерфейсы.

Утилиты ЛБД образуют библиотеку программ обслуживания БД в привилегированном режиме (работа пользовательских средств параллельно утилитам не разрешена) и выполняют основные функции, к которым относятся:

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

  • подготовка справок о составе БД, структуре файлов, количестве данных и занимаемом объеме;

  • загрузка   файла   БД   из   последовательного   набора  данных ОС;

  • дозагрузка (расширение существующего файла);

  • модификация БД: расширение или перемещение физических наборов данных, реорганизация;

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

  • выгрузка образа БД (файла таблицы) для сохранения в архивном наборе данных;

  • создание и ведение словаря данных и др.

Средства пользователя. Стандартными средствами этого типа, предоставляемыми фирмой-разработчиком, являются следующие:

  • диалоговые интерфейсы;

  • генераторы отчетов;

  • система конструирования и поддержки интерактивных технологий в информационных системах (ЯП АИС).

Разновидностью СУБД является информационно-поисковая система, обеспечивающая поиск необходимых документов, хранящихся в данной БД [8, 14].

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

Среди АИПС в узком смысле принято выделять:

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

документальные системы с неопределенной или переменной структурой данных или документов, для разработки
которых часто (но не обязательно) применяют оболочки АИПС.

Физическая реализация табличной БД

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

Основные понятия, связанные с подобными БД:

Рис. 1.25. Основные понятия, связанные с отдельным файлом табличной БД

открытый (opened) файл — файл, доступный в данный момент данному приложению. Открытие файла создает в памяти буфер, в который с внешнего накопителя считываются записи. В разные моменты времени могут быть открыты различные множества файлов, количество открытых файлов обычно стараются ограничить, чтобы не расходовать оперативную память;

активный или текущий (current, active) — тот из открытых файлов, который обрабатывается в данный момент времени. Все операции над файлами (добавление записи; удаление записи; редактирование записи) адресуются именно к активному файлу;

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

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

Вид представления записей на экране может быть не только табличным (отчет, запись в строке), но и картотечным (форматированный экран, запись на экране).

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

Занесенную в базу данных информацию можно обрабатывать, а именно осуществлять следующие операции:

  • сортировка по любому столбцу (по возрастанию/убыванию чисел, символьных строк, дат);

  • поиск по любому столбцу с различными условиями (равно, больше, меньше и т. д.);

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

Операции над БД (навигация) осуществляются с помощью следующих команд СУБД (или системы программирования [3,  10]):

  • открыть (закрыть) файл (таблицу);

  • выбрать одну из таблиц как активную (текущую);

  • перейти к определенной (по номеру) записи (строке таблицы);

  • перейти   к   предшествующей   (последующей)  строке  таблицы;

  • перейти в начало (конец) файла (таблицы);

  • найти строку таблицы с определенным сочетанием значений атрибутов;

  • добавить (редактировать, удалить) строку таблицы (запись файла).

Кроме того, в системе команд присутствуют операции администрирования (обслуживания) базы данных:

  • создать файл (таблицу) БД;

  • установить (снять) связь нескольких таблиц по логическим критериям;

  • создать описание отчета (выдача информации на экран по колонкам или печать из одной или нескольких взаимосвязанных таблиц);

  • создать формат экрана (построчная  выдача информации на   экран   из   одной   или   нескольких   взаимосвязанных таблиц);

  • изменить структуру элемента БД (таблицы данных, формата экрана, отчета и пр.).

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

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

Выбор последовательности связывается с достижением одной из следующих целей:

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

  • ускорением или упрощением средств адресации файла (например, средств прямой адресации или хэширования);

  • уменьшением размера используемого индекса и сокращением таким образом времени поиска в нем;

  • сокращением среднего времени доступа за счет размещения в наиболее доступных местах записей, к которым происходит наиболее частое обращение;

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

Можно выделить две «чистые» стратегии определения места (адреса) для размещения записей: последовательное (sequential) и произвольное (random) размещение. В этом смысле алгоритм размещения определяет тип организации файла.

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

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

Методы организации файлов

Рассмотрим наиболее распространенные методы организации файлов, позволяющие оптимизировать доступ к записям (рис. 1.26).

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

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

При параллельной секционной организации существует два вида ожиданий. Запросы должны ожидать позиционирования механизма доступа (операция установки и задержки на вращение), а затем ждать выполнения операции чтения-записи. Время, в течение которого запись читается, значительно меньше


Рис. 1.26. Способы организации файлов

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

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

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

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

Способы адресации и методы доступа к записям

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

В некоторых файлах записи имеют несколько ключей. Запись Закупка может иметь различные Номер_Поставщика и Номер_Покупателя, каждый из которых является ключом.

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

Основную проблему при адресации файла можно сформулировать следующим образом: как по первичному ключу определить местоположение записи с данным ключом? и как надо организовать набор записей, чтобы поиск потребовал как можно меньше затрат ?

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

Существует несколько различных способов адресации и поиска записей, например, на основе упорядочения, различных индексов, преобразования «ключ — адрес». Приведем обзор следующих способов, количественная оценка эффективности которых представлена в [22].

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

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

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

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

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

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

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

Если записи файла упорядочены по ключу, индекс обычно содержит не ссылки на каждую запись, а ссылки на блоки записей, внутри которых можно выполнять поиск или сканирование. Хранение ссылок на блоки записей, а не на отдельные записи в значительной степени уменьшает размер индекса. Причем даже в этом случае индекс часто оказывается слишком большим для поиска, и потому используется индекс индекса.

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

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

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

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

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

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

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

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

Более экономичным является указание на область, в которой размещается группа записей. Эта область называется участком записей (slot, bucket).

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

  • ключ записи преобразуется в квази случайное число, находящееся в диапазоне от 1 до числа участков, используемых для размещения записей;

  • число преобразуется в адрес участка, и, если на участке есть свободное место, логическая запись размещается на нем;

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

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

Из-за вероятностной природы алгоритма в этом способе не удается достичь 100%-ной плотности заполнения памяти, однако для большинства файлов может быть достигнута плотность 80 или 90 %; при этом память для индексов не требуется. Большинство записей можно найти за одно обращение, но для некоторых потребуется второе обращение (при переполнении). Для очень небольшой части записей потребуется третье или четвертое обращение к файлу.

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

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

Схемы размещения данных на внешних носителях

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

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

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

Для работы с индексно-последовательным файлом можно использовать два режима обработки: 1) последовательную обработку, при которой записи обрабатываются в последовательности их размещения на внешнем запоминающем устройстве, и 2) произвольную обработку, при которой записи обрабатываются в произвольной последовательности, не связанной с физической организацией записей на внешнем устройстве.

На рис.  1.27 приведена схема индексно-последовательного файла, в который добавлены три новые записи.

Рис. 1.27. Схема индексно-последовательного файла после добавления записей

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

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

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

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

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

Наличие некоторого объема свободной памяти в каждом управляемом интервале приводит к тому, что большая часть вновь поступающих записей умещается в пределах соответствующих интервалов. Тем не менее неизбежны случаи нехватки распределенной свободной памяти в интервалах для включения новых записей. В таких случаях осуществляется «расщепление» интервала. Предположим, что необходимо включить запись с некоторым значением ключевого поля. В соответствии со значением ключевого поля определяется интервал, в который следует включить запись. Но так как интервал уже полностью заполнен, осуществляется его расщепление: половина его записей пересылается в свободный интервал, входящий в состав той же управляемой области.

Перечислим способы включения в файл новых записей:

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

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

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

Физическое представление иерархических структур

Рассмотрим физическое представление древовидных структур (см. гл. 2, разд. 2.1) на примере обновления дерева с использованием следующих методов:

  • Физически последовательное размещение.

  • Указатели.

  • Цепи и кольца.

На рис. 1.28 и 1.29 представлен пример иерархической структуры до обновления и после него.

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

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

Последовательность элементов на рис. 1.30 иногда называется левосписковой структурой (последовательность типа «сверху вниз — слева направо»).

 

Рис. 1.28. Пример древовидной структуры

Рис. 1.29. Пример древовидной структуры после обновления

Рис. 1.30. Пример реализации древовидной структуры до обновления

Рис. 1.31. Пример реализации древовидной структуры после обновления

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

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

А1(В2(С5С12С6)В1(С12С9)ВЗ(С14С11С7С18))

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

Левосписковые структуры с переполнениями. Включение и удаление элементов могут быть выполнены с помощью метода переполнения или метода распределенной свободной памяти.

На рис. 1.32 и рис. 1.33 представлен пример реализации иерархической структуры до обновления и после него путем использования области переполнения.

Рис. 1.32. Пример реализации древовидной структуры методом переполнения

до обновления

Рис. 1.33. Пример реализации древовидной структуры методом переполнения

после обновления

В этом случае для определения местонахождения записей А, В или С можно использовать индексы.

Использование указателей на  «подобные»  и  «порожденные».

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

  • указатели на порожденные записи;

  • указатели на подобные записи;

  • указатели на исходные записи.

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

Практически эффективные компромиссы могут быть достигнуты путем использования в каждой записи двух указателей каких-либо двух типов (рис. 1.34), а также использования кольцевых структур (рис. 1.35).

Рис. 1.34. Пример реализации древовидной структуры (рис. 1.28) с использованием ссылок «порожденный — подобный» (заштрихованные области означают конец списка)

Рис. 1.35. Пример реализации древовидной структуры с использованием кольцевых ссылок

 

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

Физическое представление сетевых структур

Так же как и в случае древовидных структур, связи в сетевых структурах (см. гл. 2, разд. 2.1) можно представить, используя физически последовательное размещение, указатели, кольца. Рассмотрим простую сетевую структуру (рис. 1.36).

Рис. 1.36. Пример простой сетевой структуры

Физически последовательное размещение. Если древовидные структуры можно представить без избыточности с помощью физически последовательного размещения, для сетевых структур это обычно невозможно. Однако в некоторых случаях может оказаться удобным способом представить один набор связей типа «исходный — порожденный» путем физически последовательного размещения, а для остальных связей использовать другой метод. Например, можно использовать физически последовательное размещение для представления связей А и С (рис. 1.37).

Рис. 1.37. Пример реализации сетевой структуры с последовательным

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

Обычно для представления сетевых структур физически последовательное размещение не применяется.

Использование указателей. Если для реализации сетевых структур используются указатели, то они должны представлять все связи, причем какие-то записи должны называться исходными (например, верхние), а какие-то — порожденными (нижние записи).

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

Однако если какая-нибудь связь между записями относится к типу «многие ко многим», то названные три метода физического представления сетевых структур оказываются непригодными. Более того, если в простых сетевых структурах на предыдущих рисунках для хранения указателей на исходные записи требовались

Рис. 1.38. Пример реализации сетевой структуры с использованием указателей

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

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

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

Контрольные вопросы

  1. В чем различие информационных технологий, систем и ресурсов?

  2. Приведите примеры различных типов, форматов и структур данных.

  3. Назовите основные типы файлов

  4. Перечислите функции файловых систем.

  5. Какова общая организация ФС NTFS?

  6. Охарактеризуйте разновидности размещения файлов в NTFS.

  7. Дайте определение понятия «база данных».

  8. Перечислите преимущества и недостатки использования баз данных.

  9. Определите основные функции и назначение СУБД.

  10. Назовите характерные особенности использования баз данных в ИС.

  11.   Перечислите основные требования, предъявляемые к базам данных.

  12. Проведите сравнительный анализ понятий «физического» и «логического» представлений.

  13. Определите соотношение физической и логической записи.

  14. Проведите сравнительный анализ процессов обработки данных средствами файловой системы и СУБД.

  15. Приведите схему управления данными в СУБД.

  16. В чем заключается страничная организация данных?

  17. Перечислите основные компоненты логической и физической структуры БД.

  18. Дайте определение древовидной структуры.

  19. Определите характерные свойства и отличия линейных и нелинейных структур.

  20.  Проведите сравнительный анализ основных типов нелинейных структур.

  21.  Какие типы указателей можно использовать для реализации иерархической структуры?

  22. Какие типы указателей можно использовать для реализации сетевой структуры с последовательным размещением?

  23. Какие методы организации данных, применяемые для реализации иерархических структур, неэффективны для реализации сетевых?

  24. Приведите примерную структурную схему «страничной» организации хранения данных.

  25. Приведите примерную схему размещения данных с использованием механизма расщепления.

Глава 2

МОДЕЛИ ДАННЫХ

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

Объект имеет различные свойства (например, цвет, вес, имя), которые важны для нас в то время, когда мы обращаемся к объекту (например, выбираем среди множества других) с какой-либо целью его использования.

В задачах обработки информации, и в первую очередь в алгоритмизации и программировании, атрибуты именуют (обозначают) и приписывают им значения.

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

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

Модель предметной области соотносится с реальными объектами и связями так же, как схема маршрутов город-

Рис. 2.1. Атрибутивный способ идентификации

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

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

Рассмотрим примеры структур предметной области или моделей данных.

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

2.1. Иерархическая и сетевая модели данных

Иерархическая БД состоит из упорядоченного набора деревьев, или, более точно, из упорядоченного набора нескольких экземпляров одного типа дерева.

Типичным представителем (наиболее известным и распространенным) является СУБД Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г. До сих пор поддерживает много баз данных, что создает существенные проблемы с переходом как на новые технологии БД, так и на новую технику.

Основные компоненты иерархической модели данных (ИМД)

Организация данных в СУБД иерархического типа определяется в терминах: элемент, агрегат, запись (группа), групповое отношение, база данных.

Атрибут (элемент данных) — наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем.

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

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

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

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

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

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

В ИМД существуют также следующие понятия:

  • брат — узел, имеющий того же родителя, что и другой узел;

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

  • лист — узел, у которого нет отпрысков;

  • обход дерева — процесс обследования по очереди каждого узла дерева в иерархической модели данных и пр.

Операции над данными, определенные в иерархической модели:

  • добавить в базу данных новую запись. Для корневой записи обязательно формирование значения ключа.

  • изменить значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям.

  • удалить некоторую запись и все подчиненные ей записи.

Выбрать:

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

  • выбрать следующую запись (следующая запись извлекается в порядке левостороннего обхода дерева).

В операции выбрать допускается задание условий выборки (например, выбрать сотрудников с окладом более 5 тыс. руб.).

Как видим, все операции изменения применяются только к одной «текущей» записи (которая предварительно выбрана из базы данных). Такой подход к манипулированию данных получил название навигационного.

Ограничения целостности:

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

Пример ИМД

Рассмотрим ИМД на примере предприятия (рис. 2.2): предприятие состоит из отделов, в которых работают сотрудники. В каждом отделе может работать несколько сотрудников, но сотрудник не может работать более чем в одном отделе.

Поэтому для информационной системы управления персоналом необходимо создать групповое отношение, состоящее из родительской записи Отдел (Наименование отдела, Число работников) И дочерней записи Сотрудник (Фамилия, Должность, Оклад). Это отношение показано на рис. 2.2, а (для простоты полагается, что имеются только две дочерние записи).

Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры: заказчик — контракты с ним — сотрудники, задействованные в работе над контрактом. Это дерево будет включать записи Заказчик (Наименование заказчика, Адрес), Контракт (Номер, Дата, Сумма), Исполнитель (Фамилия, Должность, Наименование отдела)  (рис. 2.2, б).

Рис. 2.2. Модель данных предприятия

Из этого примера видны недостатки иерархических БД.

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

Иерархическая модель реализует отношение между исходной и дочерней записями по схеме 1:N, т. е. одной родительской записи может соответствовать любое число дочерних. Допустим теперь, что исполнитель может принимать участие более чем в одном контракте (т. е. возникает связь типа M:N). В этом случае в базу данных необходимо ввести еще одно групповое отношение, в котором Исполнитель будет являться исходной записью, а Контракт — дочерней (рис. 2.2, в). Таким образом, мы опять вынуждены дублировать информацию.

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

Далее, в связи с поли иерархичностью связей объектов в реальном мире в подобных БД необходимо создавать и поддерживать несколько иерархических отношений, что нарушает основную идею модели данных. Рассматриваемая модель характерна рядом так называемых «парадоксов», наиболее очевидным из которых является «парадокс исключения». Удаление из БД некоторого вышестоящего сегмента приводит к автоматическому удалению и всех зависимых (порожденных сегментов).

Преимущества иерархической модели:

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

Использование отношений предок/потомок. СУБД IMS позволяла легко представлять отношения предок/потомок, например: «А является частью В» или «А владеет В».

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

Сетевая модель данных

Иерархические структуры характерны для многих областей, однако во многих случаях отдельная запись требует более одного представления или связана с несколькими другими. В результате получаются обычно более сложные структуры по сравнению с древовидными. Например, генеалогическое дерево может быть представлено в виде древовидной структуры, только если для каждого элемента (личности) будет показан лишь один исходный элемент (родитель). Если бы были показаны оба родителя, то это была бы более сложная структура.

В сетевой структуре любой элемент может быть связан с любым другим элементом. Основные принципы сетевой модели данных были разработаны в середине 60-х гг. XX в., эталонный вариант сетевой модели данных описан в отчетах (1971 г.) Data Base Task Group (DBTG) Комитета по языкам программирования, Conference on Data Systems Languages (CODASYL), — организации, ответственной за определение языка программирования Кобол [32].

Типичным представителем СУБД этого типа является Integrated Database Management System (IDMS) компании Cullinet Software, Inc., предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем.

Основные элементы модели. Сетевая схема состоит из множества записей, которые могут быть владельцами или членами групповых отношений. Связь между записью-владельцем и записью-членом также имеет вид \:N.

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

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

Тип связи определяется для двух типов записи — предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка Р. и типом записи потомка С должны выполняться следующие два условия:

  • каждый экземпляр типа Р является предком только одного экземпляра L;

  • каждый экземпляр С является потомком не более чем одного экземпляра L.

На формирование типов связи не накладываются особые ограничения; возможны, например, следующие ситуации:

  • тип записи потомка в одном типе связи  L1  может быть типом записи предка в другом типе связи L2 (как в иерархии);

  • данный тип записи Р может быть типом записи предка в любом числе типов связи;

  • данный тип записи Р может быть типом записи потомка в любом числе типов связи;

  • может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка; и если L1 и L2 — два типа связи с одним и тем же типом записи предка Р и одним и тем же типом записи потомка С, то правила, по которым образуется родство, в разных связях могут различаться;

  • типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком — в другой;

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

Деревья а и б, показанные на рис. 2.2, заменяются одной сетевой структурой, в которой запись Сотрудник входит в
два групповых отношения;

Для   отображения   типа   M:N  вводится   запись   Сотрудник-Контракт, которая не имеет полей и служит только
для связи записей Контракт И Сотрудник (рис. 2.3). (Отметим, что в этой записи может храниться и полезная информация,  например доля данного сотрудника в общем вознаграждении по данному контракту.)

Каждый экземпляр группового отношения характеризуется следующими признаками:

  • способ упорядочения подчиненных записей:

  1. произвольный;

  2. хронологический (очередь);

  3. обратный хронологический (стек);

  4. сортированный.

Рис. 2.3. Преобразование иерархической модели данных в сетевую

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

  • режим включения подчиненных записей:

  1. автоматический — невозможно занести в БД запись без того, чтобы она была сразу же закреплена за неким владельцем;

  2. ручной — позволяет запомнить в БД подчиненную запись и не включать ее немедленно в экземпляр группового   отношения. Эта операция позже инициируется пользователем);

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

  1. фиксированное. Подчиненная запись жестко связана с записью владельцем, и ее можно исключить из группового отношения, только удалив. При удалении записи владельца  все подчиненные  записи   автоматически  тоже удаляются. В рассмотренном ранее примере фиксированное членство предполагает групповое отношение. Заключает между записями Контракт И Заказчик, ПОСКОЛЬКУ контракт не может существовать без заказчика;

  2. обязательное. Допускается переключение подчиненной записи на другого владельца, но невозможно ее существование без владельца. Для удаления записи-владельца необходимо, чтобы она не имела подчиненных записей с обязательным  членством. Таким отношением связаны записи Сотрудник и Отдел. Если отдел расформировывается, все его сотрудники должны быть либо переведены в другие отделы, либо уволены;

  3. необязательное. Можно исключить запись из группового отношения, но сохранить ее в базе данных, не прикрепляя к другому владельцу. При удалении записи-владельца ее подчиненные записи — необязательные члены сохраняются в базе, не участвуя более в групповом отношении такого типа.  Примером такого группового отношения может служить  Выполняет  между  Сотрудник  И  Контракт, поскольку в организации могут существовать работники, чья деятельность не связана с выполнением каких-либо договорных обязательств перед заказчиками.

Операции над данными

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

Включить   в  Групповое  отношение — связать существующую подчиненную запись с записью-владельцем.

Переключить — связать существующую подчиненную запись с другой записью-владельцем в том же групповом отношении.

Обновить — изменить значение элементов предварительно извлеченной записи.

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

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

Исключить  из  Группового  отношения — разорвать связь между записью-владельцем и записью-членом.

Ограничения целостности.  Как и в иерархической модели, обеспечивается  только  поддержание  целостности  по ссылкам (владелец отношения — член отношения).

На диаграммах, так же как и в случае древовидных структур, сетевую структуру можно описать с помощью исходных и порожденных элементов. Удобно представлять ее так, чтобы порожденные элементы располагались ниже исходных. При рассмотрении некоторых сетевых структур естественно говорить об уровнях, так же как и в случае древовидных структур.

Во многих сетевых структурах, задающих связи между элементами, представление отношений между исходными и порожденными элементами аналогично представлению отношений в случае дерева: отношение исходный — порожденный является сложным (указывается сдвоенными стрелками), а отношение порожденный — исходный — простым (указывается одинарными простыми стрелками).

Рис. 2.4. Пример простой сетевой структуры

На рис. 2.4 показана неоднородная сетевая структура с пятью типами элементов. Ни одна из их соединяющих линий не имеет сдвоенных стрелок в обоих направлениях. Каждое отношение может рассматриваться как отношение «исходный—порожденный». Запись Заказ_на_закупку является порожденной по отношению к записи Изделие и исходной по отношению к записи Партия_товара.

Желательно отличать структуры, в которых представление отношений «порожденный — исходный» является простым или не используется, от структур, в которых представление отношений между какими-то двумя типами данных является сложным в обоих направлениях. Для структур второго типа на одной из линий схемы будут сдвоенные стрелки, указывающие в разные стороны. Этот тип схемы назовем сложной сетевой структурой, а схему, в которой ни на одной из линий нет сдвоенных стрелок в обоих направлениях, — простой сетевой структурой. На рис. 2.4 приведена простая сетевая структура. Она станет сложной, если ввести отношение Заказ_на_закупку - Изделие, когда один заказ может быть сделан сразу на несколько изделий. Для образования сложной сетевой структуры достаточно двух типов элементов. Например, Поставщик может иметь несколько порожденных записей, потому что может поставляться более одного вида изделий. С другой стороны, элемент Изделие может иметь более одного исходного элемента, поскольку это изделие может поставляться различными поставщиками.

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

Некоторые структуры содержат циклы. Циклом считается ситуация, в которой предшественник узла является в то же время его последователем. Отношения «исходный — порожденный» образуют при этом замкнутый контур. Например, завод выпускает различную продукцию. Некоторые изделия производятся на других заводах-субподрядчиках. С одним контрактом может быть связано производство нескольких изделий. Представление этих отношений и образует цикл.

Рис. 2.5. Пример сетевой структуры с петлей

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

Разделение сетевых структур на простые и сложные оправдано потому, что сложные структуры требуют более сложных методов физического представления. Это не всегда является недостатком, поскольку сложную сетевую структуру можно (а в большинстве случаев и следует) преобразовать к простому виду.

Сильные места ранних СУБД иерархического и сетевого типов:

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

  • возможность построения вручную эффективных прикладных систем;

  • возможность экономии памяти за счет разделения подобъектов (в сетевых системах).

Недостатки:

  • слишком сложны в использовании;

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

  • прикладные системы зависят от этой организации;

  • логика приложений перегружена деталями организации доступа к БД.

2.2. Реляционная модель данных

В то время как иерархическая модель в своей основе является формализацией и обобщением пользовательских свойств некоторой конкретной СУБД (системы IMS, фирмы IBM), в случае реляционной модели сначала были разработаны некоторые математические основы, и лишь через 5—10 лет появились первые коммерчески эффективные системы.

Реляционная модель (РМД) предложена сотрудником компании IBM Е. Ф. Коддом в 1970 г. В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.

В реляционной модели достигается гораздо более высокий уровень абстракции данных, чем в иерархической или сетевой. В статье Е. Ф. Кодда утверждалось, что «реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т. е. без потребности введения какой-либо дополнительной структуры для целей машинного представления». Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название «реляционная» происходит от английского relation — «отношение»).

Реляционная модель является удобной и наиболее привычной формой представления данных в виде таблицы (применительно к базам данных понятия «реляционная БД» и «табличная БД» по существу являются синонимами). В отличие от иерархической и сетевой модели такой способ представления:

  • понятен пользователю-непрограммисту;

  • позволяет легко изменять схему —  присоединять новые элементы данных и записи без изменения соответствующих подсхем;

  • обеспечивает  необходимую  гибкость  при  обработке  непредвиденных запросов. К тому же любая сетевая или иерархическая схема может быть представлена двумерными отношениями.

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

Основные элементы РМД

Основными понятиями, с помощью которых определяется реляционная модель, являются следующие: домен, отношение, кортеж, кардинальность, атрибуты, степень, первичный ключ. Соотношение этих понятий иллюстрируется рис. 2.6. Эти понятия представляют специальную терминологию, введенную авторами теоретических основ, однако они имеют и более привычные аналоги, соответствие которых приведено в табл. 2.1.

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

Рис. 2.6. Основные понятия реляционной модели

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

Таблица 2.1. Основные понятия, связанные с РМД 

Домен

Совокупность допустимых значений

Кортеж

Таблица

Кардинальность

Количество строк в таблице

Атрибут

Поле, столбец таблицы

Степень отношения

Количество полей (столбцов)

Первичный ключ

Уникальный идентификатор

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

Остальные ключи, которые можно также использовать в качестве первичных, называются потенциальными или альтернативными ключами.

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

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

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

Модель предъявляет к таблицам следующие требования:

  • данные в ячейках таблицы должны быть структурно неделимыми; данные в одном столбце должны быть одного типа;

  • каждый столбец должен быть уникальным (недопустимо дублирование столбцов);

  • столбцы размещаются в произвольном порядке; строки размещаются в таблице также в произвольном порядке;

  • столбцы имеют уникальные наименования.

В целом концепция реляционной модели определяется следующими двенадцатью правилами Кодда [1]:

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

2. Правило гарантированного доступа. Логический доступ ко всем и каждому элементу данных (атомарному значению) в реляционной базе данных должен обеспечиваться путем использования комбинации имени таблицы, первичного ключа и имени столбца.

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

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

5. Правило исчерпывающего подъязыка данных.  Реляционная система может поддерживать различные языки и режимы взаимодействия с пользователем (например, режим вопросов и ответов). Однако должен существовать по крайней мере один язык, операторы которого можно представить в виде строк символов в соответствии с некоторым четко определенным синтаксисом и который в полной мере поддерживает определение данных; определение представлений; обработку данных (интерактивную и программную); условия целостности; идентификацию прав доступа; границы транзакций (начало, завершение и отмена).

6. Правило обновления представлений. Все представления, которые теоретически можно обновить, должны быть доступны для обновления.

7. Правило добавления, обновления и удаления. Возможность работать с отношением как с одним операндом должна существовать не только при чтении данных, но и при добавлении, обновлении и удалении данных.

8 Правило  независимости  физических данных. Прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться  нетронутыми  при любых изменениях способов хранения данных или методов доступа к ним.

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

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

11. Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.

12. Правило единственности. Если в реляционной системе есть низкоуровневый язык (обрабатывающий одну запись за один раз), то должна отсутствовать возможность использования его для того, чтобы обойти правила и условия целостности, выраженные на реляционном языке высокого уровня (обрабатывающем несколько записей за один раз).

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

Правило 3. Требует, чтобы отсутствующие данные можно было представить с помощью недействительных (пустых) значений (NULL).

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

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

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

Правило 7. Акцентирует внимание на том, что базы данных по своей природе ориентированы на множества. Оно требует, чтобы операции добавления, удаления и обновления можно было выполнять над множествами строк. Это правило предназначено для того, чтобы запретить реализации, в которых поддерживаются только операции над одной строкой.

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

Правило 10. Гласит, что язык базы данных должен поддерживать ограничительные условия, налагаемые на вводимые данные и действия, которые могут быть выполнены над данными.

Правило 11. Гласит, что язык базы данных должен обеспечивать возможность работы с распределенными данными, расположенными на других компьютерных системах.

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

Основы реляционной алгебры.

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

Операции над данными в рамках РМД практически полностью описываются в рамках реляционной алгебры (или исчисления отношений).

Определения. Перейдем к рассмотрению структурной части реляционной модели данных. Прежде всего необходимо дать несколько определений.

Декартово произведение: для заданных конечных множеств D1, D2, …, DN  (не обязательно различных) декартовым (прямым) произведением D1 × D2 ×…× DN называется множество наборов:

{d1, d2, …, dN}, где d1 D1, d2 D2, …, dN DN1

Например, если даны два множества A = {a1, a2, a3} и B= {b1, b2}  их декартово произведение будет иметь вид A= A × B = {{a1, b1}, {a1, b2}, {a2, b1}, {a2, b2}, {a3, b1}, {a3, b2}}.

Отношение: отношением R, определенным на множествах D1, D2, …, DN, называется подмножество декартова произведения  D1 × D2 × … × DN . При этом:

Множества D1, D2, … DN называются доменами отношения;

элементы декартова произведения {d1, d2, …, dN}называются кортежами;

число N определяет степень отношения (N= 1 — унарное, N=2 — бинарное, ..., N-арное).

Количество кортежей называется мощностью отношения. На множестве С из предыдущего примера могут быть определены отношения R1 = {{a1, b2}, {a3,b2}} или R2 = {{a1, b1}, {a2, b1}, {a1, b2}}

Операторы. Реляционная алгебра в том виде, в котором она была определена Э. Ф. Коддом, состоит из двух групп по четыре оператора:

Традиционные операции над множествами   (но модифицированные с учетом того, что их операндами являются отношения, а не произвольные множества): объединение, пересечение, разность и декартово произведение;

Специальные реляционные операции: выборка, проекция, соединение, деление.

Рассмотрим подробнее операции реляционной алгебры.

Объединение возвращает отношение, содержащее все кортежи, которые принадлежат либо одному из двух заданных отношений, либо им обоим (рис. 2.7).

Рис. 2.7. Объединение отношений

Рис. 2.8. Пересечение отношений

Пересечение возвращает отношение, содержащее все кортежи, которые принадлежат одновременно двум заданным отношениям (рис. 2.8).

Разность возвращает отношение, содержащее все кортежи, которые принадлежат первому из двух заданных отношений и не принадлежат второму (рис. 2.9).

Рис. 2.9. Разность отношений

Рис. 2.10. Произведение отношений

Произведение (декартово) возвращает отношение, содержащее все возможные кортежи, которые являются сочетанием двух кортежей, принадлежащих соответственно двум заданным отношениям (рис. 2.10).

Выборка (селекция) возвращает отношение, содержащее все кортежи из заданного отношения, которые удовлетворяют указанным условиям (рис. 2.11).

Рис. 2.11. Выборка (селекция) отношения

Рис. 2.12. Проекция отношения

Проекция возвращает отношение, содержащее все кортежи (подкортежи) заданного отношения, которые остались в этом отношении после исключения из него некоторых атрибутов (рис. 2.12).

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

Рис. 2.13. Соединение отношений

Деление для заданных двух унарных отношений и одного бинарного возвращает отношение, содержащее все кортежи из первого унарного отношения, которые содержатся также в бинарном отношении и соответствуют всем кортежам во втором унарном отношении (рис. 2.14).

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

Рис. 2.14. Деление отношений

Важно, что отношение имеет две части — заголовок и тело. Нестрого говоря, заголовок — это атрибуты, а тело — это кортежи. Заголовок для базового отношения, т. е. значение базовой переменной-отношения, очевидно, вполне конкретен и известен системе, поскольку он задается как часть определения соответствующей базовой переменной отношения. Поскольку результирующее отношение обязательно должно иметь вполне определенный тип, то, если рассматривать свойство реляционной замкнутости более строго, каждая реляционная операция должна быть определена таким образом, чтобы выдавать результат с надлежащим типом отношения (в частности, с соответствующим набором имен атрибутов или заголовком).

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

Рассмотренные восемь операторов Кодда не являются минимальным набором, так как не все из них примитивны, т. е. часть из них можно определить через другие операторы. Действительно, операции соединения, пересечения и деления можно определить через остальные пять. Эти пять операций (выборка, проекция, произведение, объединение и разность) можно рассматривать как примитивные в том смысле, что ни одна из них не выражается через другие. Они образуют минимальный набор, но тем не менее не обязательно единственно возможный. Кроме того, остальные три операции (в особенности операция соединения) на практике используются настолько часто, что, несмотря на то что они не являются примитивными, имеет смысл обеспечить их непосредственную поддержку.

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

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

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

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

  • производные   переменные-отношения, т.е. те данные, которые должны  быть  включены  в  представления  базы данных;

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

  • ограничения защиты, т. е. данные, для которых осуществляется тот или иной тип контроля доступа.

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

Нормализация реляционной БД

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

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

функциональная зависимость по сути является связью типа «многие к одному» между множествами атрибутов (столбцов) рассматриваемого отношения;

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

Нормальные формы

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

Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее атрибуты (столбцы), не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.

Таблица находится в третьей нормальной форме (ЗНФ), если она удовлетворяет определению 2НФ и ни один из ее неключевых атрибутов не связан функциональной зависимостью с любым другим неключевым атрибутом.

Таблица находится в нормальной форме Бойса Кодда (НФБК) тогда и только тогда, когда любая функциональная зависимость между ее атрибутами сводится к полной функциональной зависимости от возможного первичного ключа.

В следующих нормальных формах (4НФ и 5НФ) учитываются не только функциональные, но и многозначные зависимости между атрибутами. Для того чтобы привести определения этих нормальных форм, введем понятие полной декомпозиции таблицы.

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

Далее дадим определения высших нормальных форм.

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

Четвертая нормальная форма (4НФ) является частным случаем 5НФ, когда полная декомпозиция должна быть соединением ровно двух проекций. На практике непросто подобрать реальную таблицу, которая находилась бы в 4НФ, но не была бы в 5НФ.

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

Рассмотрим процедуру приведения таблиц к НФБК.

Такая процедура основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида А -> К, где К — первичный ключ, а А — некоторый атрибут. Принцип «один факт в одном месте» говорит о том, что не должно существовать в рамках таблицы никаких других функциональных зависимостей. Цель нормализации и состоит в удалении этих «лишних» функциональных зависимостей.

Рассмотрим два возможных случая.

Таблица имеет составной первичный ключ вида, скажем, (K1, K2) и включает также атрибут А, который функционально зависит от части этого ключа (например, от К2), но не от полного ключа. В этом случае рекомендуется сформировать другую таблицу, содержащую атрибуты К2 и А (первичный ключ — К2), и удалить атрибут А из первоначальной таблицы.

Таблица имеет первичный (возможный) ключ К, атрибут А1, который не является возможным ключом, но функционально зависит от К, и другой не ключевой атрибут А2, который функционально зависит от А1. Решение здесь по существу то же самое, что и прежде? — формируется другая таблица, содержащая атрибуты AI и А2 с первичным ключом А1, а атрибут А2 удаляется из первоначальной таблицы.

Таким образом, повторяя применение двух рассмотренных правил, для любой заданной таблицы почти во всех реальных практических ситуациях можно получить в конечном счете множество таблиц, которые находятся в НФБК и не содержат каких-либо функциональных зависимостей вида, отличного от А -> К.

2.3. Модель «сущность — связь»

Одним из наиболее популярных средств формализованного представления предметной области является модель «сущность — связь» [31], которая положена в основу значительного количества коммерческих CASE-продуктов, поддерживающих полный цикл разработки систем баз данных или отдельные его стадии.

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

Семантическую основу ER-модели составляют следующие предположения:

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

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

сущности можно классифицировать по типам: каждый экземпляр сущности (представляющий некоторый объект);

может быть отнесен к некоторому классу, или типу, сущностей, каждый экземпляр которого обладает общими для них свойствами и отличающим их от сущностей других классов;

систематизация представления, основанная на классах, в общем случае предполагает иерархическую зависимость типов: сущность типа А является подтипом  сущности В, если каждый экземпляр типа А является экземпляром сущности типа В;

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

Забегая вперед, отметим, что связь между реляционной и ER-моделью может быть установлена «в обе стороны» — от РМД к совокупности сущностей и связей.

Преобразование реляционной БД в сущности и связи

Рис. 2.15. Пример набора записей табличного типа

На рис. 2.16 а, б приведен пример разделения линейных записей исходной таблицы Штатное расписание факультета (рис. 2.15) на связи и собственно данные.

Рис. 2.16. Пример разделения на данные (а) и связи (б) набора записей табличного типа

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

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

  • каждый элемент таблицы — это один элемент данных;

  • таблица не содержит одинаковых строк, т. е. содержащих попарно равных значений элементов данных;

  • столбцы таблицы однородны (так как элементы данных каждого столбца имеют общую природу) и могут быть однозначно идентифицированы именованием.

Компоненты ER-диаграммы

ER-модель, как описание предметной области, должна определить объекты и взаимосвязи между ними, т. е. установить связи следующих двух типов:

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

  • связи между объектами, задающие характер и функциональную природу их взаимозависимости.

Как было отмечено ранее, ER-моделирование предметной области базируется на использовании графических диаграмм как простого (привычного), наглядного и в то же время информативного и многоаспектного способа отображения компонентов проекта. Поэтому изложение основных положений ER-модели будет иллюстрироваться материалом примера ER-диаграммы, приведенной на рис. 2.17.

Сущности. Сущность, с помощью которой моделируется класс однотипных объектов, определяется в [21] как «предмет, который может быть четко идентифицирован». Так же как каждый объект уникально характеризуется набором значений свойств, сущность должна определяться таким набором атрибутов, который позволял бы различать отдельные экземпляры сущности. Каждый экземпляр сущности должен быть отличим от

Рис. 2.17. Пример ER-диаграммы

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

Сущность имеет имя, уникальное в пределах модели. При этом имя сущности — это имя типа, а не некоторого конкретного экземпляра.

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

Свойства. Природа свойства как характер связи свойства с сущностью (объектом) может быть различной. Рассмотрим основные виды свойств.

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

Свойство может быть простым (не подлежащим дальнейшему делению с точки зрения прикладных задач) или составным, если его значение составляется из значений простых свойств. Например, свойство Год рождения является простым, а свойство Адрес — составным, так как включает значения простых свойств Город, Улица, Дом.

В некоторых случаях полезно различать базовые и производные свойства. Например, Поставщик может иметь свойство Общее количество поставляемых деталей, которое вычисляется суммированием количества деталей, поставляемых им по проекту.

Если наличие некоторого свойства для всех экземпляров сущности не является обязательным, то такое свойство называется условным. Например, не все Сотрудники обладают свойством Ученая_степень.

Значения свойств могут быть постоянными — статическими, или динамическими, т. е. меняться со временем. Например, свойство Таб_номер является статическим, а Адрес — динамическим. Свойство может быть неопределенным, если оно является динамическим, но его текущее значение еще не задано.

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

Связи. Кроме связей между объектом и его свойствами, ER-модель отражает связи между объектами разных классов. В [21] связь определяется как «ассоциация, объединяющая несколько сущностей». Эта ассоциация всегда может существовать между разными сущностями или между сущностью и ею же самой (рекурсивная связь).

Как и сущность, связь является типовым понятием, т. е. все экземпляры связываемых сущностей подчиняются   правилам связывания типов. Принципиальность различия типов связей между типами и экземплярами иллюстрируется ER-диаграммами для типов и экземпляров, представленными на рис. 2.18.

Рис. 2.18. Примеры ER-диаграмм для типов и экземпляров сущностей

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

Если каждый экземпляр сущности участвует по крайней мере в одном экземпляре связи, то такое участие этой сущности называется полным (или обязательным); в противном случае — неполным (или необязательным).

Количественный характер участия экземпляров сущностей (один или многие) задается типом связи (или мощностью связи). Возможны следующие типы: «один к одному» (1:1), «один ко многим» (1:М), «многие к одному» (М:1), «многие ко многим» (М:М).

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

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

Отношение «часть — целое» используется для представления составных объектов. Например, Машины состоят из Узлов, Узлы состоят из Деталей. Здесь возможны как отношения «один ко многим», так и «многие ко многим».

Отношение «род — вид» — для представления обобщенных объектов. Например, Сотрудники подразделяются по профессии на Конструкторов, Программистов, Рабочих; Программисты — на Прикладных Программистов И Системных Программистов. Иерархические отношения, и в частности «родовидовые», обычно используются как основа классификации объектов по наборам характеристических признаков. Причем «видовые» объекты наследуют свойства «родовых».

Другой широко используемой разновидностью взаимосвязи является агрегирование — объединение простых объектов в сложный по принципу их принадлежности агрегату или их совместного участия в некотором процессе. Агрегирование, рассматриваемое здесь как более общий случай иерархических отношений, объединяет объекты разной природы с единственным общим свойством «совместное участие». Агрегированные объекты именуются обычно отглагольными существительными, например, Состав: Подразделение состоит из Сотрудников; Поставка: Поставщик  поставляет  Детали.

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

Сущность, на основе которой определяются подтипы, называется супертипом. Подтипы должны образовывать полное множество, т. е. любой экземпляр супертипа должен относиться к некоторому подтипу. Иногда для полноты множества надо определять дополнительный подтип, например Прочие.

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

Тип сущности, его подтипы, подтипы этих подтипов и т. д. образуют иерархию типов сущности, пример которой приведен на рис. 2.19.

Рис. 2.19. Пример иерархии типов сущности

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

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

Сущности. Каждый тип сущности в ER-диаграммах представляется в виде прямоугольника, содержащего имя сущности. В качестве имени обычно используются существительные (или обороты существительного) в единственном числе. Для отражения сущностей слабых типов используются прямоугольники, стороны которых рисуются двойными линиями. Например, в рассматриваемой далее ER-диаграмме, приведенной на рис 2.17, Подчиненный — сущность слабого типа.

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

Имена ключевых свойств подчеркиваются. Например, свойство Таб_номер сущности Сотрудник.

Контур эллипса рисуется двойной линией, если свойство многозначное. Например, свойство Специальность сущности Сотрудник.

Контур эллипса рисуется штриховой линией, если свойство производное. Например, свойство Количество сущности Поставщик.

Эллипс соединяется пунктирной линией, если свойство условное. Например, свойство Ин_язык сущности Сотрудник.

Если свойство составное, то составляющие его свойства отображаются другими эллипсами, соединенными с эллипсом составного. Например, свойство Адрес сущности Сотрудник состоит из простых свойств Город, Улица, Дом.

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

Стороны ромба рисуют двойными линиями, если это связь сущности слабого типа с сущностью, от которой она зависит. Например, связь Подчинение, связывающая сущность слабого типа Подчиненный С сущностью Сотрудник, от которой она зависит.

Участники связи соединены со связью линиями. Двойная линия обозначает полное участие сущности в связи с данной стороны. Например, связь Подчинение со стороны сущности Подчиненный.

Связь может быть модифицирована указанием роли. Например, для рекурсивной связи Состав указаны роли: Деталь со­стоит  из... И Деталь   входит  в  состав... .

Тип связи указывается индексами «1» или «М» над соответствующей линией. Например, связь Руководство имеет тип «один ко многим»: один сотрудник может руководить многими проектами; связь Участие имеет тип «многие ко многим»: один сотрудник может участвовать во многих проектах или в проекте могут участвовать многие сотрудники.

Нормальные формы ER-диаграмм

Как и в реляционных схемах баз данных, в ER-диаграммах вводится понятие нормальных форм, причем их смысл очень близко соответствует смыслу реляционных нормальных форм. Приведем краткие и неформальные определения трех первых нормальных форм.

В первой нормальной форме ER-диаграммы устраняют повторяющиеся атрибуты или группы атрибутов, т. е. производится вьявление неявных сущностей, «замаскированных» под атрибуты.

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

В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности.

На рис. 2.20 представлена ER-диаграмма рис. 2.17 в третьей нормальной форме.

Рис. 2.20. Пример ER-диаграммы в третьей нормальной форме

Логическое проектирование БД

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

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

Рассмотрим по шагам общий подход к построению реляционной базы данных на основе модели, представленной ER-диаграммой.

Получение реляционной схемы из ER-диаграммы

  1. Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы;

  2. Каждый атрибут становится возможным столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, не могут. Если атрибут является множественным, для него строится отдельное отношение;

  3. Компоненты уникального идентификатора сущности превращаются в первичный ключ. Если имеется несколько возможных уникальных  идентификаторов,   выбирается  наиболее используемый. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей;

  4. Связи «многие к одному» и «один к одному» становятся внешними ключами, т. е. создается копия уникального идентификатора с конца связи «один», и соответствующие столбцы составляют внешний ключ;

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

Если в концептуальной схеме присутствуют подтипы, возможны два варианта.

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

Во-втором случае для каждого подтипа создается отдельная таблица и для каждого подтипа первого уровня (для более нижних — представления) супертип воссоздается с помощью представления union (из всех таблиц подтипов выбираются общие столбцы — столбцы супертипа).

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

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

2.4. Пример проектирования реляционной БД

Рассмотрим следующую задачу: пусть необходимо обеспечить сбор и обработку данных по результатам сдачи экзаменов и зачетов студентами факультета. Организация данных должна обеспечивать:

  • выполнение текущего учебного плана;

  • формирование ведомостей по отдельным дисциплинам для групп студентов;

  • формирование листов зачетных книжек студентов; формирование сводной ведомости курса;

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

Построение ER-диаграммы

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

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

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

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

Взаимодействие сущностей реализуется связью Сводная ведомость, т. е. Студент сдает экзамен (зачет) по Дисциплине учебного плана. Мощность связи — «многие ко многим»

(М:М). Для идентификации связи отдельных экземпляров сущностей в этом случае необходимо наличие у связи следующих дополнительных свойств: оценка и дата сдачи экзамена (зачета).

ER-диаграмма рассматриваемой задачи представлена на рис. 2.21.

Построенная ER-диаграмма находится в первой нормальной форме, так как сущности не имеют повторяющихся групп свойств. Однако при рассмотрении свойств сущности Дисциплина учебного плана можно заметить, что свойство Преподаватель зависит только от части ключевых свойств, а именно от свойств Наименование дисциплины И, возможно, Форма отчетности. Следовательно, для того чтобы привести ER-диаграмму ко второй нормальной форме, необходимо выделить свойство Преподаватель в отдельную сущность.

Рис. 2.21. ER-диаграмма рассматриваемой задачи

Новая сущность Преподаватель характеризуется группой основных свойств Фамилия, Имя, Отчество, И группой дополнительных свойств: Кафедра, Должность, Домашний_адрес и Телефон. Так же как и для сущности Студент, для сущности

Преподаватель необходимо ввести дополнительное (ключевое) свойство — идентификационный номер преподавателя.

Взаимодействие новой сущности с сущностью дисциплина учебного плана осуществляется посредством новой связи Читает. Мощность связи — «многие к одному» (М:1), т. е. несколько дисциплин учебного плана может читать один преподаватель.

Рис. 2.22. Нормализованная ER-диаграмма

Измененная ER-диаграмма представлена на рис. 2.22. Новый вариант ER-диаграммы находится в третьей нормальной форме, так как сущности не имеют свойств, зависящих от не ключевых.

Построение реляционной схемы

Следующий этап проектирования — преобразование ER-диаграммы в реляционную схему.

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

Первые шаги преобразования состоят в превращении каждой сущности в отношение (таблицу). Связь типа М:М, которую называют «сущность — связь», тоже превращается в отдельное отношение. Каждое свойство становится атрибутом — столбцом соответствующей таблицы.

После реализации этих шагов получаем реляционную схему, изображенную на рис. 2.23, где представлены таблицы Студенты, Сводная ведомость, Учебный_план и Кадройый_состав, отображающие соответственно сущности Студент, Сводная ведомость, Дисциплина_учебного_плана  и Преподаватель.

Рис. 2.23. Реляционная схема после первого этапа преобразования

Далее необходимо преобразовать связи во внешние ключи. Связь «многие ко многим», реализуемая отношением Сводная_ведомость, должна содержать уникальные идентификаторы сущностей — участников связи. При этом если для однозначной идентификации студента достаточно добавить в таблицу столбец ID_Студент, то однозначная идентификация дисциплины потребует добавления в таблицу столбцов Наименование, Семестр и Форма отчетности. Хранение всей этой информации явно приведет к избыточности данных и их потенциальной противоречивости (например, если при переносе дисциплины на другой семестр обновить только строку таблицы Учебный_план, то содержимое таблицы Сводная_ведомость станет неактуальным).

Для ликвидации избыточности и потенциальной противоречивости данных добавим в таблицу Учебный_план столбец ID_План, содержимое которого будет однозначно идентифицировать каждую строку таблицы. Теперь этот новый столбец станет первичным ключом, и одноименный столбец должен быть добавлен в таблицу Сводная_ведомость.

Связь Читает предполагает добавление в таблицу Учебный_план столбца ID_Преподаватель. Реляционная схема со связями представлена на рис. 2.24.

Рис. 2.24. Реляционная схема со связями

Нормализация таблиц

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

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

Рассмотрим подробнее таблицу Учебный_план, которая содержит перечень дисциплин текущего учебного плана. Первичным ключом таблицы служит столбец ID План, который однозначно характеризует каждую дисциплину учебного плана с точностью до семестра, т. е. для дисциплин, протяженность изучения которых более одного семестра, в таблице будет отведено столько строк, сколько семестров длится изучение дисциплины. Тогда хранение наименований дисциплин в таблице Учебный план становится избыточным: например, если изучение английского языка длится шесть семестров, то наименование «Английский язык» будет повторено в шести записях и есть вероятность сделать шесть различных ошибок при вводе одного и того же наименования.

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

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

  2. Студенты — содержит по одной строке для каждого из студентов;

  3. Учебный план — содержит по одной строке для отдельной дисциплины отдельного семестра;

  4. Дисциплины — содержит по одной строке для наименования дисциплины;

  5. Сводная ведомость — содержит по одной строке для каждого результата сдачи отдельным студентом отдельной дисциплины;

  6. Кадровый состав — содержит по одной строке для каждого из преподавателей.

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

Рис. 2.25. Структура базы данных Сессия: а — общая графическая схема БД; б — характеристики таблиц БД

Таблица «Студенты» 

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

Тип данных

Ограничения

ID_Студент

Целое число

Значение уникально

Фамилия

Строка символов размером 30

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

Имя

Строка символов размером 15

Значение не должно быть

пустым

Отчество

Строка символов размером 20

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

Номер_Группы

Целое число

Значение не должно быть

пустым

Адрес

Строка символов размером 30

 

Телефон

Строка символов размером 8

 

Таблица «Дисциплины»

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

Тип данных

Ограничения

ID_Дисциплина

Целое число

Значение уникально

Наименование

Строка символов размером 20

Значение уникально

Таблица «Кадровый состав» 

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

Тип данных

Ограничения

ID_Преподаватель

Целое число

Значение уникально

Фамилия

Строка символов размером 30

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

Имя

Строка символов размером 15

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

Отчество

Строка символов размером 20

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

Должность

Строка символов размером 20

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

Кафедра

Строка символов размером 3

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

Адрес

Строка символов размером 30

 

Телефон

Строка символов размером 8

 

Таблица «Учебный план» 

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

Тип данных

Ограничения

ID_План

Целое число

Значение уникально

ID_Дисциплина

Целое число

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

Семестр

Целое число

Значение не должно быть пустым и должно находиться в интервале от 1 до 10

Количествочасов

Целое число

 

ID_Преподаватель

Целое число

 

Таблица «Сводная ведомость»

Рис. 2.25. Структура базы данных Сессия (окончание)

Все таблицы базы данных Сессия находятся в третьей нормальной форме:

  • каждый столбец таблицы неделим, и в рамках одной таблицы нет столбцов с одинаковыми по смыслу значениями
    (1НФ);

  • первичные ключи однозначно определяют запись и не избыточны, все поля каждой из таблиц зависят от ее первичного ключа (2НФ);

  • значение любого поля, не входящего в первичный ключ, не зависит от значения другого поля, тоже не входящего в
    первичный ключ (ЗНФ).

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

Исходя из особенностей данных и их функционального назначения, требуется задать способ представления и границы возможных изменений для каждого из столбцов таблиц. При этом необходимо ответить на вопрос, данные каких типов должны храниться в столбцах и какова их максимальная длина (например, если в столбце предполагается хранить процентные значения, то достаточно будет целого типа данных длиной 1 байт, так как диапазон возможных значений от 0 до 255; если для данных столбца выбирается тип «строка символов», то желательно указать максимальный размер данных столбца и т. п.).

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

Следующий важный момент — задание для столбцов значений по умолчанию. Значение по умолчанию впоследствии будет автоматически вводиться в указанный столбец для каждой строки таблицы. Например, в столбец Дата_сдачи таблицы Сводная_ведомость при заполнении очередной строки может автоматически заноситься текущая дата.

На рис. 2.25, б представлены таблицы базы данных Сессия с типами данных столбцов и предлагаемыми ограничениями целостности.

Все примеры использования языка SQL (Structured Query Language), рассматриваемые в гл. 4, будут построены на основе этой учебной базы данных Сессия.

2.5. Хранилища данных

В основе концепции OLAP (On Line Analytical Processing — анализ данных онлайн) лежит принцип многомерного представления данных. В 1993 г. Е. Ф. Кодд рассмотрел недостатки реляционной модели, в первую очередь указав на невозможность «объединять, просматривать и анализировать данные с точки зрения множественности измерений, т. е. самым понятным для корпоративных аналитиков способом», и определил общие требования к системам OLAP, расширяющим функциональность реляционных СУБД и включающим многомерный анализ как одну из своих характеристик.

Аббревиатурой OLAP иногда обозначается не только многомерный взгляд на данные, но и хранение самих данных в многомерной БД. Однако Кодд отмечал, что «реляционные БД были, есть и будут наиболее подходящей технологией для хранения корпоративных данных. Необходимость существует не в новой технологии БД, а, скорее в средствах анализа, дополняющих функции существующих СУБД и достаточно гибких, чтобы предусмотреть и автоматизировать разные виды интеллектуального анализа, присущие OLAP».

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

Использование концепции хранилища данных (ХД) позволяет:

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

  • создавать единую модель данных организации;

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

Для хранилищ данных характерны следующие основные свойства:

ориентация на предметную область — хранилище в первую очередь  отражает  специфику предметной  области,   а   не приложений;

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

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

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

многомерное   концептуальное   представление   (multi-dimen­sional conceptual view) — множественная перспектива, состоящая из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных.

Одновременный анализ по нескольким измерениям определяется как многомерный анализ. Каждое измерение включает направления консолидации данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению. Так, измерение Исполнитель может определяться направлением консолидации, состоящим из уровней обобщения предприятие—подразделение—отдел—служащий. Измерение Время может даже включать два направления консолидации — год—квартал—месяц—день и неделя—день, поскольку счет времени по месяцам и по неделям несовместим. В этом случае становится возможным произвольный выбор желаемого уровня детализации информации по каждому из измерений. Операция спуска (drilling down) соответствует движению от высших ступеней консолидации к низшим; напротив, операция подъема (rolling up) означает движение от низших уровней к высшим (рис. 2.26).

Рис. 2.26. Измерения и направления консолидации данных

Кодд определил 12 свойств, которыми должны обладать системы этого класса (табл. 2.2).

Таблица 2.2. Свойства систем класса ОLAP 

Требование (свойство)

Содержание

1

Многомерное концеп­туальное представле­ние данных

Концептуальное представление модели данных в продукте OLAP должно быть многомерным по своей природе, т. е. позволять аналитикам выпол­нять интуитивные операции «анализа вдоль и поперек», выбора направле­ний консолидации и т. д.

2

Прозрачность (Transparency)

Пользователь не должен знать о том, какие конкретные средства исполь­зуются для хранения и обработки данных, как данные организованы и от­куда берутся

3

Доступность (Accessibility)

Аналитик должен иметь возможность выполнять анализ в рамках общей концептуальной схемы, но при этом данные могут оставаться под управ­лением оставшихся от старого наследства СУБД

4

Устойчивая производи­тельность (Consistent Reporting Performance)

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

5

Клиент-серверная ар­хитектура

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

6

Равноправие измере­ний

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

7

Динамическая обработ­ка разреженных матриц

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

8

Поддержка многополь­зовательского режима

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

9

Неограниченная под­держка кроссмерных операций

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

10

Интуитивное манипули­рование данными

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

11

Гибкий механизм гене­рации отчетов

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

12

Неограниченное коли­чество измерений и уровней агрегации

OLAP-инструмент должен иметь несколько измерений в аналитической модели. Каждое из этих измерений должно допускать практически неог­раниченное количество определенных пользователем уровней агрегации по любому направлению консолидации

Модели данных, используемые для построения хранилищ

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

Многомерный OLAP (MOLAP). В специализированных СУБД, основанных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:

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

  • поликубов   (каждая переменная хранится с собственным набором измерений, и все связанные с этим сложности обработки перекладываются на внутренние механизмы системы).

Использование многомерных БД в системах оперативной аналитической обработки имеет следующие достоинства.

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

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

С другой стороны, имеются существенные ограничения:

  • многомерные СУБД не позволяют работать с большими объемами данных. К тому же за счет денормализации и предварительно выполненной агрегации объем данных в многомерной базе, как правило, соответствует в 2,5—100 раз меньшему объему исходных детализированных данных;

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

Следовательно, использование многомерных СУБД оправдано только при следующих условиях:

  • объем исходных данных для анализа не слишком велик (неболее нескольких гигабайт), т. е. уровень агрегации данных достаточно высок;

  • набор информационных измерений стабилен  (поскольку любое изменение в их структуре почти всегда требует полной перестройки гиперкуба);

  • время ответа системы на нерегламентированные запросы является наиболее критичным параметром;

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

Реляционный OLAP (ROLAP). Непосредственное использование реляционных БД в системах оперативной аналитической обработки имеет следующие достоинства:

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

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

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

Главный недостаток ROLAP по сравнению с многомерными СУБД — меньшая производительность. Для обеспечения производительности, сравнимой с MOLAP, реляционные системы требуют тщательной проработки схемы базы данных и настройки индексов, т. е. больших усилий со стороны администраторов БД. Только при использовании звездообразных схем производительность хорошо настроенных реляционных систем может быть приближена к производительности систем на основе многомерных баз данных.

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

Рис. 2.27. Пример схемы «звезда»

В сложных задачах с многоуровневыми измерениями имеет смысл обратиться к расширениям схемы звезды — схеме созвездия (fact constellation schema) и схеме снежинки (snowflake schema). В этих случаях отдельные таблицы фактов создаются для возможных сочетаний уровней обобщения различных измерений (рис. 2.28). Это позволяет добиться лучшей

Рис. 2.28. Пример схемы «снежинка» (фрагмент для одного измерения)

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

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

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

Возможны гибридные системы (Hybrid OLAP, HOLAP), цель которых — совмещение достоинств и минимиза­ция недостатков, присущих предыдущим классам.

Архитектуры хранилищ данных

Виртуальное хранилище данных. В его основе — репозиторий метаданных, которые описывают источники информации (БД транзакционных систем, внешние файлы и др.), SQL-запросы для их считывания и процедуры обработки и предоставления информации. Непосредственный доступ к последним обеспечивает ПО промежуточного слоя. В этом случае избыточность данных нулевая. Конечные пользователи фактически работают с транзакционными системами напрямую со всеми вытекающими отсюда плюсами (доступ к «живым» данным в реальном времени) и минусами (интенсивный сетевой трафик, снижение производительности OLTP-систем и реальная угроза их работоспособности вследствие неудачных действий пользователей-аналитиков).

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

Глобальное хранилище данных. Все более популярной становится идея совместить концепции хранилища и витрины данных в одной реализации и использовать хранилище данных в качестве единственного источника интегрированных данных для всех витрин данных. Тогда естественной становится такая трехуровневая архитектура системы (рис. 2.30):

  • сфера детализированных данных. Это область действия большинства систем, нацеленных на поиск информации. В большинстве случаев реляционные СУБД отлично справляются с возникающими здесь задачами. Общепризнанным стандартом языка манипулирования реляционными данными является SQL. Информационно-поисковые  системы,  обеспечивающие  интерфейс 

Рис. 2.29. Структура корпоративной информационно-аналитической системы (ИАС)

Рис. 2.30. Архитектура системы многомерного интеллектуального анализа данных

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

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

  • сфера   закономерностей.   Интеллектуальная  обработка производится методами  интеллектуального анализа
    данных
    (ИАД, Data Mining), главными задачами которых являются поиск функциональных и логических закономерностей в накопленной информации, построение моделей и правил,  которые объясняют найденные аномалии  и/или прогнозируют развитие некоторых процессов.

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

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

Процесс загрузки данных обычно подразумевает решение следующих задач:

  • предобработка данных (исключение дубликатов, устранение ошибочных значений,  восстановление пропущенных значений);

  • агрегирование данных (вычисление обобщенных статистических показателей).

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

Контрольные вопросы

  1. Дайте определение понятия предметной области.

  2. Что  является  результатом  абстрагированного  описания  предметной области?

  3. Дайте определение атрибутивного способа идентификации объектов и записей.

  4. Перечислите операции реляционной алгебры.

  5. Дайте определение реляционных операций соединения, пересечения и деления через пять других операций.

  6. Докажите ассоциативность и коммутативность реляционной операции объединения.

  7. Являются ли реляционные операции умножения и деления взаимообратными?

  8. Перечислите основные свойства реляционной структуры данных.

  9. Определите типологию связей.

  10. Определите соотношение понятий «сущность» и «связь».

  11. Проанализируйте соотношение ER-модели и ER-диаграммы.

  12. Как отображается сложный объект в реляционной модели.

  13. Приведите примеры дополнительных функций,  которые могут быть реализованы с помощью таблиц БД Сессия.

  14. Проведите   декомпозицию   отношения   Кадровый   состав,   выделив отношение Штатное  расписание.

  15. Проведите  декомпозицию   отношения   Кадровый  состав,   выделив отношение Структура   факультета.

  16. Какие изменения должны быть внесены в структуру БД Сессия для реализации функции назначения стипендии?

  17. Дайте основные характеристики моделей данных.

  18. В чем заключается сходство и различие моделей данных (МД).

  19. Перечислите преимущества и недостатки различных МД.

  20. Перечислите основные понятия, связанные с табличными БД.

  21. Что такое реляционное исчисление?

  22. Что такое транзакции?

  23. Что такое хранилища данных?

  24. Перечислите основные свойства OLAP-технологий.

  25. В чем различие ROLAP и MOLAP?

Глава 3

FOXPRO — СИСТЕМА УПРАВЛЕНИЯ

БАЗАМИ ДАННЫХ

И ПРОГРАММИРОВАНИЯ

Система управления базами данных (точнее, система программирования с развитыми элементами СУБД) FoxPro предназначена для разработки приложений, являющихся открытыми или замкнутыми документальными или фактографическими информационными системами, и впервые предложена в 1988 г. Предшествующими аналогичными системами являлись dBaseIII/IV и Clipper (1984—1987 гг.). Аналогичность здесь (подразумевает преемственность, основанную на том, что различие команд, форматов и функций не превосходит 10—15 % 'и ранее разработанные приложения не требуют существенных переработок, навыки программирования, полученные на Clipper, имеют силу для FoxPro и т. п. В настоящее время используются FoxPro for Windows и Visual FoxPro (VFP).

3.1. Основные возможности системы

Здесь рассматриваются возможности и свойства подобных систем на примере Visual FoxPro (VFP) — системы, использующей принципы объектно-ориентированного программирования и визуального проектирования приложений. Авторы заранее признаются читателям в том, что будет использовано и проиллюстрировано не более 15—20 % возможностей этого мощного программного продукта. Далее, некоторые из приводимых ниже в примерах команд, функций и типов файлов не являются присущими именно VFP, а поддерживаются системой для обеспечения преемственности и совместимости с более ранними версиями — FoxPro for Windows и FoxPro/DOS. Кроме команд (некоторые из которых приведены в Приложении 2) и функций (см. Приложение 3) VFP поддерживает объекты (object), методы (method) свойства (property) и события (event), описания которых, как и системных переменных (system variable), мы вынуждены опустить.

Основные понятия, связанные с работой в FoxPro

  • файл данных — файл операционной системы (ОС) DOS или Windows, имя которого содержит расширение .dbf, содержащий как описание структуры записей, так и собственно записи с информацией. Представляет собой аналог таблицы (отношения) реляционной БД;

  • запись файла — совокупность связанных данных, состоящая из полей;

  • указатель записи — текущий номер активной записи, доступной для чтения и обновления;

  • текущий файл БД — выбранный для обработки один из открытых файлов;

  • индексный файл (индекс) — файл ОС с расширениями . idx (компактный индекс),   .cdx (составной индекс),  предназначенный для управления порядком обработки файла БД. Одному файлу БД может соответствовать несколько существующих и/или активных индексных файлов;

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

  • формат экрана — файл ОС с расширением . fmt, содержащий описание порядка выдачи данных на экран монитора (чтения данных с экрана);

  • формат отчета — файл ОС с расширением . frm, содержащий описание отчета, выдаваемого на экран или принтер (длина строки, ширина страницы, имена выдаваемых полей, заглавие отчета, имена колонок, печать итогов при прерывании и т. д.);

  • командный (пакетный, программный) файл — файл ОС с расширением . prg, содержащий в каждой строке одну из команд языка FoxPro;

  • команда   —   элемент   языка   манипулирования   данными (близкого к языкам программирования);

  • функция — встроенный оператор, осуществляющий преобразование переменных либо получение справочной информации.

  • Команды и функции языка FoxPro

Для описания конструкций языков здесь и далее (гл. 4 — SQL) будет использована нотация IBM, которая включает следующие конструкции:

< > угловые скобки (или двойные кавычки "") обозначают элементы программы, определяемые пользователем (<идентификатор>, <список   параметров>  «условие»  И пр. В соответствующих местах реальной программы будет находиться идентификатор переменной и т. д.);

[   ]   квадратные  скобки  обозначают  возможное  отсутствие элемента конструкции.  Например,  return    [<выражение>]   — в этой конструкции <выражение>  не обязательно;

фигурные скобки

{<выражение-1>   |   <выражение-2>   |   <выражение-3>}

или означают означают обязательное присутствие одного из «выражений»;

|  вертикальная  черта  разделяет список значений обязательных элементов,  одно  из которых должно быть выбрано;

... — горизонтальное многоточие, следующее после некоторой синтаксической конструкции, обозначает последовательность конструкций той же самой формы, что и предшествующая многоточию конструкция. Например,  {<выражение>   [, <выражение>] . . . } обозначает, что ОДНО илиболее «выражений», разделенных запятыми, может появиться между фигурными скобками.

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

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

создание индекса для текущего файла БД — index ON выражение  TО  файл, ключом доступа является «выражение» (чаще всего имя поля), который записывается в файл.idx;

join, sort создание нового файла путем слияния двух существующих по некоторому критерию или сортировки одного файла;

append from файл — загрузка (импорт) файла БД из файла ОС, подготовленного в формате записей фиксированной длины либо же с указанными в команде разделителями;

copy to файл — выгрузка (экспорт) данных из файла БД в файл ОС (операция, обратная append from).

Команды ввода/редактирования записи (средства интерфейса оператора):

get — ввод отдельного поля, строки или пользовательской переменной;

edit — экранная команда ввода/вывода/исправления записи в текущем файле с использованием некоторого формата, описание которого хранится в файле формата экрана;

browse — экранная команда ввода/исправления записей в текущем файле, при этом используются стандартный формат экрана и режим системного меню;

append — создание пустой записи в конце текущего файла и заполнение ее с применением пользовательского формата экрана;

replace — замещение в текущей записи значений некоторых полей на новые;

update  —  массовое обновление значений записей файла  БД.

Команды вывода данных:

say — выдача на экран или принтер поля, данного или строки;

browse, edit используются также для просмотра данных на экране;

report — выдача поколонного отчета на экран или принтер с использованием файла формата отчета.

Команды навигации в БД (открытие, закрытие файлов, пере­мещение по записям файлов):

use, select — выбор среди нескольких открытых файлов БД текущего;

set  index to, set order to — задание текущего индекса при работе с файлом БД;

go, skip — изменение положения указателя текущей записи путем прямого перехода к записи или путем пропуска
некоторого числа записей;

find, seek .— поиск записи в индексированном файле по ключу и установка указателя на найденную запись;

locate, continue   — поиск записи по сложному критерию без использования индексов путем сканирования полей записей;

set   relation   to — установление связи двух файлов БД так, что при перемещении указателя записи в основном
файле синхронно перемещается указатель в зависимом;

close, clear — закрытие всех или части файлов БД, экранов, отчетов.

Команды управления вычислительным процессом:

do while  условие. . .enddo — описание блока, выполнение которого осуществляется циклически, пока соблюдается логическое «условие»;

loop — переход из некоторой точки блока do   ...   enddo в его начало;

exit — выход из блока do   ...   enddo;

do, return — вызов командного файла и возврат в вызывающую программу;

do   case    . . .    case    . . .   endcase — оператор условного ветвления программ на несколько путей;

if. . .else. . .endif — оператор условного ветвления на две ветви.

Установление режимов и опций:

set   format  to  — открытие файла формата ввода-редактирования текущего файла;

set color to определяет атрибуты цветов экрана.

Язык программирования FoxPro допускает использование также значительного числа функций, как обычных для прикладных языков (min, max, substr, sqrt), так и специфических (recno () — номер текущей записи, reccount () — число записей в текущем файле, eof () — признак конца текущего файла и др.). Основные функции приведены в Приложении 3.

Возможности программирования в FoxPro расширяются тем, что многие из непроцедурных команд обработки и выдачи информации — edit, replace, report, copy и др. — включают в свою структуру конструкции, уточняющие свойства записей файла, на который эти команды распространяются:

КОМАНДА [интервал] While [условие-1] For [условие-2],

[Next n — следующие п записей; где интервал =  Rest   — оставшиеся до конца файла записи; [аи  — все записи.

Здесь: выполнение Команды прекращается, если нарушается <условие-1>;

Команда распространяется  при  этом только на записи, удовлетворяющие <условию-2>.

Разработка приложений в среде FoxPro состоит в создании совокупности взаимосвязанных файлов БД, форматных, индексных, командных, образующих в итоге среду пользователя, АБД, оператора подготовки данных. В Приложении 2 приведен краткий обзор основных команд.

Пример программы

Приведем текст простой диалоговой программы, содержащий наиболее характерные особенности ЯП FoxPro (операторы вводавывода на экран и управления программой).

Возможный диалог с такой программой  может выглядеть следующим образом (рис. 3.1):

Привет! Как Вас зовут?

Гаврик

Доброе утро, Гаврик! Как настроение?

Плохое

У меня тоже плохое, Гаврик!

 

Рис. 3.1. Иллюстрации к простой диалоговой программе:

а — начало внешнего цикла; б — начало внутреннего цикла; в — окончание внутреннего цикла и выход во внешний

Рассмотрим текст такой программы:

* Простая диалоговая программа

set echo off

set talk off

on escape quit &&условие выхода из программы

clear

do while .t. && внешний цикл

name= [         ] && инициализация переменной  (в)

@ 1,10 say [Привет! Как Вас зовут?]

@ 3, 10 get name

read        (a)

if name =[ ] &&требование ввода непустой строки loop

endif

if substr(name,l,l)=[*] &&выход из программы exit

endif

do while .t. && внутренний цикл

nastr=[   ] && инициализация переменной

@ 5,10 say [Доброе утро, ]+rtrim(name)+

[! Как настроение?] @ 7,10 get nastr

read        (б)

if substr(nastr,l,l)=[ ]

loop endif if substr(nastr,l,l)=[*] &&условие выхода из внутр.

&&цикла exit endif @ 9,10 say [У меня тоже ] +rtrim (nastr) +

[, ]+rtrim(name) + [ ! ] enddo enddo * Конец программы

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

on escape — задание действий при нажатии клавиши (в данном случае — прекращение работы программы).

Инициализация переменных name, nastr одновременно задает их тип как строковый и определяет длину.

Программа состоит из двух вложенных циклов do ... enddo, в заголовке которых стоит условие бесконечного повторения (.t.), поэтому должен быть предусмотрен принудительный выход из каждого цикла. Этот выход происходит при условии ввода в строке name или nastr символа «*» (звездочка). С помощью оператора exit осуществляется выход во внешний цикл из внутреннего и из внешнего циклов на окончание работы.

При попытке ввести пустую строку в ответ на запрос программа возвращается в заголовок соответственно внутреннего или внешнего цикла и повторяет запрос на ввод строки (оператор возврата в начало цикла loop). Управление условными переходами осуществляется оператором if  ...  endif.

Операторы say и get осуществляют вывод на экран строки текста и открытие окна для ввода в соответствующих позициях экрана (строка и столбец). Для ограничения строки (литерала) в программе может использоваться как двойная кавычка ("), так и квадратные скобки ([]).

Команда read останавливает программу для ожидания ввода данных в окно на экране и нажатия подтверждения . Команда clear осуществляет очистку экрана монитора.

Конкатенация (сцепление) строк осуществляется оператором «+», а функция rtrim () используется для подавления «хвостовых» пробелов во введенной строке с целью повышения удобочитаемости текста. Функция substr, обычная и для других ЯП, позволяет выделить из строки-операнда подстроку-результат (с указанием длины подстроки и смещения от начала исходной строки).

Из текста программы следует также, что допустимы два типа комментариев — полная строка (начинается с символа *) и частичная строка (начинается с &&).

3.2. Данные и операторы

Типы файлов и их расширения

Расширение следует за именем файла и отделяется от него точкой. Например, datafile.dbf — имя файла базы данных.

Когда файл создан в FoxPro, расширение назначается автоматически (исключение для текстового файла). Если открывается файл, не надо указывать его расширение. Например, с помощью следующей команды открывается файл базы данных с именем datafile.dbf:

use datafile

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

create  datafile.new

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

Основные типы файлов и расширения:

файл данных, файл базы данных (database, dbf) — содержит упорядоченный набор определенных данных. В   FoxPro  различают шесть типов данных:  символьный, цифровой, с плавающей точкой, дата, логический и служебные записи;

индексный файл (index, . idx) — управляет порядком доступа к записям в конкретной базе данных и их обработки.
Индексные файлы FoxPro позволяют изменить порядок, в котором записи базы данных будут появляться на экране,
порядок, в каком они будут напечатаны и т. д., однако фактический порядок данных в базе данных при этом не
изменится;

файл связанных данных, мемо-поля (memo, . fpt) — содержит данные, сохраняемые в мемо-полях, являющихся частью базы данных. Информация из мемо-полей не сохраняется в файле (расширение  .dbf) базы данных, вместо
этого она сохраняется в файле с тем же именем с расширением .fpt;

программный файл (program, .prg) — содержит множество команд (программу), которые решают определенную задачу. Эти файлы могут быть созданы и отредактированы с использованием текстового редактора FoxPro (modify
file, modify  command) или любого другого;

откомпилированная     программа     (compiled      program, f xp) — содержит файл программы, которая откомпилирована FoxPro в сжатую форму для более быстрого выполнения. FoxPro создает эти файлы для уменьшения времени решения этой задачи;

текстовый файл (text,  .txt) — содержит текстовые данные в коде ASCII, созданные с помощью команды copy to delimited. Расширение .txt добавляется автоматически, когда создан файл текстовых данных. Это расширение также могло быть использовано с текстовыми файлами, созданными с помощью текстового редактора FoxPro,
но расширение . txt должно быть определено, когда файл создан с помощью другого редактора. Например, следующая команда создает файл без расширения:

modify file notes

Если  вы хотите создать файл  с расширением   . txt, вы должны выдать команду, аналогичную следующей:

modify file notes.txt

резервная копия файла (file  backup,  .bak) — содержит предыдущую версию текста, программы или файла базы
данных;

формат экрана (.fmt) — содержит описание экрана пользователя, которое определяет форматы, используемые для
ввода, редактирования и просмотра данных;

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

описание метки (label, . lbx) — содержит описание метки. Это описание определяет данные и расположение для
вывода метки, включая ширину поля, ширину и высоту метки, сквозную нумерацию меток, а также расстояние и
число строк между метками;

файл сохранения переменных оперативной памяти (memory variable save,  mem) — позволяет сохранить информацию о переменных, определенных во время сеанса FoxPro (команда save to. . .);

файл описания окна (window   file,   .win) — содержит описание окна, которое было создано с помощью команды save  window

Рабочие области и псевдонимы

FoxPro предоставляет возможность одновременно открыть и работать с 10 файлами базы данных в 10 рабочих областях, которые идентифицируются буквами a—j или номерами 1 — 10.

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

Псевдоним по умолчанию. Если вы открыли базу данных, названную customer .dbf, в рабочей области а с помощью команд:

select a use customer

то файлу данных будет автоматически присвоен псевдоним customer.

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

select customer

delete all for amt due = 0

pack

Назначение псевдонима. Существует возможность назначить псевдоним для рабочей области при открытии базы данных. Если открыть файл базы данных с именем customer.dbf (в рабочей области а) и назначить ему псевдоним people с помощью команды:

select a use customer alias people

то псевдоним people затем может быть использован для ссылки к рабочей области, в которой находится файл базы данных customer.

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

select   a или

select   1

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

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

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

select с select 3 select customer

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

Если вы находитесь в рабочей области с и хотите иметь доступ к полю с именем lastname из файла базы данных customer в рабочей области а, можно использовать следующие виды записи:

customer->lastname a->lastname customer.lastname a.lastname

Если же файл базы данных customer в рабочей области а имеет псевдоним people, можно воспользоваться обращениями

people->lastname a->lastname people.lastname a.lastname

Псевдоним переменной памяти. Некорректно назначать имена переменных идентичными именам полей базы данных (хотя иногда это полезно). Если имя переменной идентично имени поля базы данных, в FoxPro приоритет всегда имеет имя поля базы данных относительно к переменной (имя понимается как ссылка к полю базы данных). Для устранения недоразумений доступ к переменной, имеющей такое же имя, как и поле, осу

ществляется с помощью префикса м-> или м. (м с точкой);

м  ->  lastname mlastname

Типы данных

FoxPro имеет шесть основных типов данных: символьный, цифровой, с плавающей точкой, логический, дата и служебные записи (memo-поля). Каждый раз, создавая поле базы данных (create database), необходимо определить для него один из перечисленных выше типов. Назначенный тип вы можете изменить, модифицируя структуру базы данных (modify database, modify structure). Данные, хранящиеся в переменной памяти, определяют ее тип. Если необходимо изменить тип данных переменной, достаточно сохранить новый тип данных этой переменной. Ниже описаны все типы данных.

Символьный. Может содержать любые буквы, цифры и знаки препинания с клавиатуры плюс некоторые символы псевдографики, иностранный алфавит и специальные символы. Кроме того, символьные данные FoxPro могут содержать любые 8-битовые значения, включая нулевой символ chr(O). Это означает, что двоичные данные могут быть сохранены в символьных строках FoxPro.

Поле базы данных FoxPro может содержать не более 254 символов. Переменная памяти может содержать до 64 Кбайт символов.

Цифровой. Может содержать цифры, десятичную точку и предшествующие знаки «плюс» или «минус». Максимальное значение цифрового поля — 20 разрядов (хотя сохраняются только 16 значащих разрядов). Десятичная точка и знаки «плюс» или «минус» занимают один разряд. Таким образом, цифровое поле может содержать 20 цифр, 19 цифр и десятичную точку, 19 цифр и знаков «плюс» или «минус» или 18 цифр со знаком и десятичной точкой. Цифровые данные удобно использовать почти для всех вычислений.

С плавающей точкой. Может содержать цифры, десятичную точку и предшествующие знаки «плюс» или «минус». Максимальное значение цифрового поля — 20 разрядов. Десятичная точка и знаки «плюс» или «минус» занимают один разряд. Таким образом поле с плавающей точкой может содержать 20 цифр, 19 цифр и десятичную точку, 19 цифр и знаков «плюс» или «минус» или 18 цифр со знаком и десятичной точкой. Данные с плавающей точкой специально предназначены для научных вычислений.

Логические. Может содержать букву т (истина) или F (ложь) для определения, истинно условие или ложно. Также могут быть использованы буквы Y или N, но сохраняются как т и F. Логические данные полезны для записи условий, например, таких, как — платеж просрочен (т), или нет (F).

Дата. Может содержать цифры, которые представляют дату. В базе данных собственно дата всегда имеет поле размером 8 разрядов. Напечатана дата может быть в различных форматах. Например, вы можете задать, что дата должна быть напечатана в американском (mm/dd/yy), итальянском (dd-mm-yy) или ANSI (yy.mm,dd) форматах. Дата также может быть высвечена с четырьмя позициями года (mm/dd/yyyy =  12/06/1992).

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

Кроме того, мемо-поля могут содержать любые 8-битовые значения, включая нулевой символ CHR(O). Это означает, что двоичные данные могут размещаться в мемо-полях FoxPro.

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

Удовлетворяя ограничениям, установленным ранее для символьных переменных, данные мемо-полей могут быть использованы в любом месте, в котором разрешено применение символьных данных. Это означает, что мемо-поля FoxPro, по существу, могут быть представлены и обработаны, как если они были бы символьными полями переменной длины. Кроме того, существует ряд операций, которые могут быть выполнены в мемо-полях произвольной длины.

Поддержка пути

FoxPro позволяет определить множество директорий (отличных от текущих рабочих директорий), в которых осуществляется поиск файлов. Это делается с помощью команд set default и set path:

set  default изменяет имя накопителя по умолчанию на имя, отличное от имени накопителя по умолчанию операционной системы. Это важно помнить, так как, хотя все операции FoxPro выполняются на накопителе, определенном командой Set   default, накопитель по умолчанию операционной системы остается тем же самым;

set   path определяет множество директорий, используемых для поиска файла, если файл не найден в текущей директории. Местоположение директории может быть указано или относительно, или с помощью полностью определенных имен путей, как показано ниже.

Путь считается полностью определенным, если начинается с точки или обратной косой черты, а именно:

set path to \system\data set path to ..\

или если начинается с имени накопителя, например:

set path to c:\system\data

Путь считается относительным по отношению к рабочей директории, если начинается с имени директории, например:

set path to data

Он обрабатывается FoxPro подобно пути, указанному полностью set path to  \data.

Когда FoxPro пытается определить местоположение файла, имя которого определено не полностью, система сначала ищет его в рабочей директории на накопителе по умолчанию, определенном при помощью команды set default. Если поиск не удачен, то затем имена путей используются в порядке их появления в команде set path. Имена путей просто присоединяются к началу имени файла для осуществления поиска. 

Если теперь полностью определенное имя файла не содержит имени накопителя, то предполагается имя накопителя по умолчанию.

Правила поддержки пути, описанные выше, применяются для поиска существующих файлов с одним исключением. Команда dir ищет в рабочей директории на накопителе по умолчанию, если имя пути полностью не определено.

Когда FoxPro создает файл, она также размещает его в рабочей директории на накопителе по умолчанию, если имя файла не содержит имени пути.

Массивы

СУБД FoxPro поддерживает переменные в памяти, представляющие собой одно- и двумерные массивы. Массив — это набор переменных с общим именем. К каждой записи массива, которую часто называют элементом, можно обращаться по индексам ее строки и столбца. Так как массивы хранятся в памяти, к ним можно обращаться и работать с ними с высокой скоростью. Элементы массива могут содержать любой тип данных (символьный, числовой, тип даты или логический тип). При создании массива его элементы инициализируются логическим значением false   (.f.).

Создание массивов. Для создания массивов используются две команды — dimension и declare. Данные команды идентичны по синтаксису и выполняемой ими функции, и их можно свободно чередовать. В командах dimension и declare следует задавать имя массива и его размерность. Некоторые команды и функции СУБД FoxPro могут сохранять результат в массиве. Если заданный массив не существует, то следующие команды и функции автоматически создадут массив: average, acopy( ), append from array, adir ( ), calculate, afields ( ), copy to  array, scatter, select — sql, sum.

Имена массивов могут иметь в длину до 10 символов и включать в себя алфавитные символы, символы подчеркивания и цифры. Имя массива не может начинаться с цифры или содержать встроенные пробелы. Для создания одномерного массива укажите один индекс, который задает число строк в массиве. Для создания двумерного массива укажите пару индексов. Первый индекс обозначает число строк в массиве, второй — число столбцов. Индексы массива всегда начинаются с 1. В следующем примере создаются одномерный массив с именем deptnumber и двумерный массив с именем taxrates с десятью строками и пятью столбцами:

dimension deptnumber10) dimension taxrates(10,5)

С помощью одной команды dimension или declare можно создать несколько массивов. Массивы приведенного выше примера создает команда:

dimension deptnumber(10), taxrates(10,5)

Функции FoxPro для работы с массивами. Для работы с массивами СУБД FoxPro поддерживает множество функций. Перечень этих функций и их использование приведены в табл. 3.1.

Таблица 3.1. Функции для работы с массивами 

Функция

Описание

adel(   )

Удаляет из массива элемент, строку или столбец

adir(   )

Помещает в массив информацию о соответствующих файлах

aelement(   )

По индексу строки и столбца возвращает номер элемента

afields(   )

Помещает в массив информацию о файле базы данных

ains (   )

Включает в массив элемент, строку или столбец

alen(   )

Возвращает число элементов, строк или столбцов в массиве

ascan (   )

Выполняет поиск в массиве в памяти выражения

asort (   )

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

asubscript(   )

Возвращает индексы элемента (строку и столбец) по его номеру

Ссылки на элементы массива. К элементу массива можно обращаться по индексу его строки и столбца или по номеру элемента. Индексы массива представляют собой числа или числовые выражения, которые задают место расположения элемента массива. Первый индекс задает место расположения элемента в строке, второй — место расположения элемента в столбце. Например, индексы 1,1 задают элемент массива, находящийся в первом столбце и первой строке. Индексы 2,5 задают элемент во второй строке и пятом столбце массива. В одномерном массиве номер элемента идентичен его индексу строки. Номер элемента в двумерном массиве определяется подсчетом строк. Предположим, что вы создали следующий массив 3x3: a   b    с

d   e   f g   h    i

Номерами элементов для a, b и с будут 1, 2 и 3. Номерами элементов для d, e и/ будут 4, 5 и 6 и т. д. Имеются две полезные функции для работы с массивами — aelement() и asubscript ():

функция aelement()   возвращает номер элемента по заданным индексам столбца и строки;

функция   asubscript() возвращает индекс строки истолбца по заданному номеру элемента массива.

Присваивание значений элементам массива. Вы можете записать в каждый элемент массива различные значения или присвоить одно значение всем элементам массива. Для присваивания значений элементам массива используются команда store и операция =. Для присваивания значения отдельному элементу массива используются индекс элемента (одномерный массив) или его индексы (двумерный массив). В приведенных ниже примерах буквы A—F присваиваются элементам массивов 2x3 с именем а1рна и beta. Для присваивания элементам массива значений A—F используется команда store и операция =.

dimension             alpha(2,3), beta(2,3)

store       'a'            to alpha(1,1)

store       'b'            to alpha(l,2)

store       'c'            to alpha(1,3)

store       'd'            to alpha(2,l)

store       'e'            to alpha(2,2)

store       'f              to alpha (2,3)

beta(l,l) = 'a' beta(l,2) = 'b' beta(l,3) = 'c' beta(2,l) = 'd' beta(2,2) = 'e' beta(2,3) = 'f' display memory like alpha display memory like beta

Можно также присвоить элементам значения, используя номера элементов:

dimension             gamma(2,3)

store 'a'  to gamma(1)

store 'b'  to gamma(2)

store 'c'  to gamma(3)

store 'd'  to gamma(4)

store 'e'  to gamma (5)

store 'f'   to gamma (6)
display memory likе gamma

Изменение размерности массивов. Объем или размерности массива вы можете изменить, снова используя команды dimension или declare. Можно увеличить или уменьшить объем массива, одномерный массив преобразовать в двумерный, а двумерный свести к одномерному. Если вы увеличите число элементов массива, то содержимое всех элементов исходного массива копируется с соответствии с порядком элементов в массив с измененной размерностью. Дополнительные элементы массива инициализируются логическим значением false (.f.).

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

Передача данных между массивами и файлами базы данных. В СУБД FoxPro имеется несколько команд, которые облегчают передачу данных из файла данных в массив и обратно. Команда scatter пересылает данные в массив из отдельной записи файла данных. Команда copy to array передает в массив данные из последовательности записей, select (SQL) может передавать в массив результат запроса. Данные из массива можно переслать в отдельную запись базы данных с помощью команды gather. Команда append from array добавляет к файлу данных новые записи и заполняет записи данными из массива. Команда insert (SQL) присоединяет к базе данных одну новую запись и заполняет ее данными из массива. Команды scatter и copy to array пересылают данные из базы данных в массив.

Операторы

Операторы, используемые в FoxPro, разделяются на четыре основные категории: логические, арифметические, операторы сравнения и строковые.

Логические операторы (в порядке старшинства):

() — круглые скобки используются для группирования выражений;

. not. — логическое отрицание; .and. — логическое И; .or. — логическое ИЛИ.

Арифметические операторы (в порядке старшинства):

() — круглые скобки используются для группирования выражений;

**, ^ — возведение в степень; *, / — умножение и деление; +, —  — сложение и вычитание;

Операторы сравнения:

< — меньше чем; > — больше чем; = — равно <>; # — не равно; <= — меньше или равно; >= — больше или равно;

$ — сравнение подстроки или сравнение символьной строки (отслеживание пробелов важно, когда включено exact).

Строковые операторы:

+ — сцепление строк (две строки соединяются вместе); — — сцепление строк (отслеживаемые пробелы передвинуты от первой строки до конца второй строки).

Литералы:

" ",' ', [ ] — используются для заключения в ограничительные литералы строковых констант;

[ ] — используются для заключения в ограничительные литералы констант даты.

Диапазон записей

Когда команда производит операции с записями в базе данных, требуется определить, с какими именно записями команда будет работать. Для подобных ситуаций задаются диапазон записей, используя выражение интервала, а также логические операторы for и/или while.

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

all  — команда выполняется для всех записей в файле данных;

next — команда выполняется для области записей, которая начинается с текущей записи и завершается записью
с номером <п>;

next  1 — работает с текущей записью;

record — команда работает с записью файла данных, с физическим номером <п>;

rest — команда работает с областью записей, которая начинается с текущей записи и завершается последней записью в файле.

Выражения for и while. Диапазон действия команды также может быть определен с помощью выражений for <логическое выражение> и/или while  <логическое  выражениеХ

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

Например, команда

use personal

edit for sex = [М] .and. year > 1985

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

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

Например, команда

use personal

edit while year = 1985

должна будет выбрать для редактирования записи, пока год рождения в них равен 1985 г. Как только появится 1987 или 1984 г., работа команды завершится. Очевидно, все это имеет смысл только в том случае, если записи отсортированы по году рождения или включен соответствующий индекс. Кроме того, указатель текущей записи должен быть установлен на первую запись с годом рождения 1985 (например, командой seek 1985).

Оператор интервала и выражения for, while могут быть использованы в одной и той же команде FoxPro. Если заданы оба выражения for и while, то while имеет более высокий приоритет.

Ошибки, возникающие при выполнении

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

cancel — немедленное завершение выполнения программы и возврат к режиму команды диалога;

suspend — приостановка выполнения программы и возврат к режиму команды диалога. Этот вариант полезен, когда осуществляется отладка программы;

resume — осуществляется повторный запуск программы с точки, где она была приостановлена;

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

3.3. Создание и модификация базы данных в программной среде FoxPro

Краткие сведения об интерфейсе FoxPro

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

Строка заголовка самая верхняя строка окна работающей программы (рис. 3.2, /). Она содержит имя активной прикладной программы или полное название (спецификацию) обрабатываемого в данный момент документа (файла).

Строка меню находится под строкой заголовка и включает следующие элементы:

File (Файл);

Edit (Правка);

View (Вид);

Tools (Инструментарий);

Рис. 3.2. Основной экран интерфейса:

/ — строка заголовка и основное меню; 2 — рабочее пространство; 3 — статусная строка; 4 — командное окно; 5 — окно пользователя (команда browse)

Program (Программа);

Window (Окно);

Help (?).

Каждому заголовку меню соответствуют свои меню директив и опций.

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

Рис. 3.3. Рубрики главного меню:

а — работа с таблицами (выбрана команда перехода к последней записи — Go Bottom); б — выбор режима просмотра (переключение на режим Edit — полноэкранный вывод из режима Browse — построчный вывод)

Рабочее пространство. После запуска FoxPro на мониторе появляется окно FoxPro, в котором присутствуют заставка и ряд служебных элементов, составляющих рабочее пространство программы: строка заголовка, строка меню, линейки прокрутки, статусная строка, рабочая зона, окно директив.

Большая зона в центре экрана — это рабочая зона пользователя (рис. 3.2, 2), где он может создавать, редактировать и/или просматривать файлы, документы, программы и т. д.

Линейки прокрутки справа экрана или окна директив служат для перемещения содержимого открытого окна.

Статусная строка, расположенная внизу экрана, содержит информацию об открытом файле (рис. 3.2, 3).

Окно директив (команд или Command) автоматически открывается при включении FoxPro (рис. 3.2, 4). В этом окне пользователь может прямо вводить директивы (команды), т. е. пользоваться командным интерфейсом. Щелчком мыши можно выключить окно директив (левый верхний угол). С помощью меню Window (рис. 3.4, а) также можно выключать директиву Hide (подавить).

Рис. 3.4. Рубрики главного меню:

а — меню Windows (открыть — скрыть окна); б — диалоговое окно меню Edit (задается переход к 3-й строке диалогового сеанса с целью редактирования и повторного запуска команды)

Окна. Каждое окно состоит из строки заголовка (с кнопкой вызова управляющего меню, кнопками распахивания/восстановления окна), рамки окна, линеек прокрутки. Не все окна имеют полный набор перечисленных элементов. Линейка прокрутки показывает, какой фрагмент файла изображен на экране. С помощью мыши можно захватить бегунок прокрутки и отбуксировать его в требуемую позицию.  Концевые манипуляторы линеек прокрутки — кнопки листания (это стрелки) в соответствующем направлении. Окна можно увеличивать или уменьшать с помощью директивы Size (размер). Захватив строку заголовка мышью, можно отбуксировать (Drug & Drop) окно в нужную позицию.

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

Диалоговые окна. Когда функцию невозможно выразить простой директивой, FoxPro вступает в диалог с пользователем. Например, надо сохранить файл. Программа должна знать, на каком накопителе в какой директории под каким именем его сохранить.

Диалог (диалоговое окно) — разновидность окна, для которого не предусмотрены средства манипулирования его размерами (они и не нужны). Диалоговое окно можно перемещать по экрану командой Move (перенести), а можно захватить заголовок диалогового окна мышью и отбуксировать его при нажатой кнопке мыши (рис. 3.4, б).

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

Во многих диалоговых окнах имеются и другие кнопки, которые открывают дополнительные (подчиненные) диалоговые кнопки. В наименованиях таких кнопок присутствует многоточие. Если командные кнопки не содержат многоточия (New или Open), они выполняют конкретное действие, которое и обозначено в названии кнопок.

Селекторные кнопки (radio button) используются в том случае, когда некоторый параметр может иметь одно значение из нескольких возможных.

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

Создание и редактирование БД

Определение структуры файла. Для задания структуры файла используется команда create — создать. При задании такой команды система запросит имя файла. Имя файла используется для обращения к содержимому файла и имеет длину не более 10 символов.

После задания имени файла на экране появляется диалоговое окно для задания структуры файла (рис. 3.5).

Рис. 3.5. Создание нового файла данных

Определение структуры файла осуществляется заполнением приведенных полей. Каждому полю создаваемого файла соответствует одна строка структуры на экране. Структура файла набирается латинским шрифтом. Тип поля задается листанием допустимых в FoxPro полей. Ими могут быть Character, Numeric, Date, Memo, Logical и др.

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

После заполнения одной строки (создания одного поля файла) нажатием клавиши переходят к заданию второго поля файла (второй строки экранной таблицы).

Для контроля соответствия созданного файла проекту пользователя может быть использована команда display  stucture

(рис. 3.6). Здесь на рабочем поле экрана помещается отчет о структуре текущего файла данных.

Рис. 3.6. Просмотр структуры файла командой display stucture

Вставка нового поля. Для того чтобы вставить новое поле файла, следует нажать в области диалогового окна задания структуры файла (рис. 3.5) командную кнопку (вставить).

Удаление поля. Чтобы удалить поле из файла, следует пометить поле и нажать командную кнопку (удалить) того же диалогового окна (рис. 3.5).

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

Создание и просмотр полей типа Memo. Предположим, необходимо ввести в структуру файла новое имя поля prim с типом поля Memo. Курсор подвести на поле Memo. Нажать . В результате получаем экран формата текстового редактора. Ввести текст. — текст записан.

Просмотреть поля типа Memo:

list   fio,   prim

Ввод данных. После определения структуры файла в него можно вводить информацию. Для ввода новых данных в файл применяется команда append. При задании этой команды открывается окно ввода информации. Курсор находится в первом поле. После заполнения первого поля переходим к заполнению последующих (рис. 3.7).

Рис. 3.7. Режим ввода данных (команда append)

Поле типа даты в FoxPro имеет ряд особенностей:

длина поля автоматически задается равной восьми символам;

при  вводе данных в поля автоматически  вводится символ «/» (слэш);

по умолчанию применяется следующий формат поля Date: мм/дд/гг;

поля будут отсортированы верно, несмотря на непривычную нам запись мм/дд/гг;

при вводе даты выполняется автоматическая проверка: запись <13/01/94> система не введет;

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

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

Предусмотрено несколько специальных операторов, которые обрабатывают поля Date и позволяют включать их в логические выражения. Одна из таких функций — dtoc (Date to Character Conversion — преобразование даты в символ). Логическое выражение dtog (имя поля типа Date) переводит поле типа Date в символьное поле (Character).

Ввод данных в поле Memo. Команда append или edit позволяет высветить на экране содержимое поля Memo как слово Memo. Если необходимо просмотреть поле или ввести в него текст, следует переместить курсор в это поле и нажать . В результате формат edit или append изменится на формат текстового редактора. В таком режиме можно печатать текст. После ввода текста подается команда . Текст записывается на диск, а программа возвращается в режим edit или append.

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

Просмотр данных. Просмотреть загруженные данные можно с использованием команды list (рис. 3.8):

list — просмотр всего открытого файла;

list <имя  поля  1,   имя  поля  К> — просмотр 1-ГО И К-го полей;

list record 3 — просмотр отдельной записи.

Рис. 3.8. Выборочный просмотр полей записей файла командой list

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

Конструкция list off позволяет исключить номера записей из листинга.

Команды edit и browse осуществляют просмотр и редактирование записей файла данных.

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

В окне просмотра можно управлять отображением данных на экране, например изменить ширину отдельных полей. Для этого необходимо установить курсор мыши между заголовком поля Name и заголовком поля Year. Эта линия называется разделителем заголовков. При попадании на разделитель заголовков указатель мыши изменяет вид. Нажав кнопку мыши и перемещая курсор, можно установить требуемый размер поля (рис. 3.9).

Рис. 3.9. Просмотр и редактирование файла командой browse: а — до изменения ширины столбцов; б — после изменения

Команда edit позволяет увидеть все поля в одном окне. В этом режиме поля каждой записи располагаются одно под другим (рис. 3.10).

Рис. 3.10. Режим просмотра и редактирования файла по записям командой edit

Просмотр данных с использованием логических выражений.

С этой целью используются команды, содержащие логические выражения: list  for  <имя поля> =   [значение поля]

Например, list  for  sex =   [М]

Кроме операторов сравнения на равенство (=) можно работать с другими логическими операторами: <, >, <=, >=. Значения символьных полей заключаются в кавычки.

FoxPro позволяет просматривать и копировать данные, используя сложные логические выражения с операторами (связками): and, or, not:, list  for year >=  1990   .and.   sex =   [f].

Логические связки имеют три уровня приоритета:

1-й — .not.;

2-й — .and.;

3-й — .or. .

В синтаксисе команд FoxPro связки and, or, not снабжаются с двух сторон точками.

На рис. 3.11 приводятся примеры выборочного просмотра записей файла командой browse (рис 3.11, а) и командой SQL select (рис. 3.11,б). Отметим здесь, что команды языка SQL (см ниже, гл. 4) поддерживаются системой FoxPro в качестве альтернативы аналогичным командам и операторам внутренне­го языка.

Просмотр данных с использованием диалоговых команд. Команда ? может применяться для вывода информации из файла

Рис. 3.11. Просмотр с использованием логических выражений:

а — команда browse; б— команда select   (SQL) данных и оперативной памяти.

Рассмотрим несколько примеров «навигационных команд» и их результатов (рис. 3.12).

Здесь изображены рабочее поле экрана (слева) и окно командных строк (справа). Соответствие команд и отображаемой информации задается стрелками:

команда clear очищает рабочую область экрана;

команда use открывает файл данных prsnll;

командой go top задается переход к первой записи файла (/);

Рис. 3.12. Некоторые операции с файлом данных и наблюдение за ними

с помощью диалоговых команд:

/ — переход в начало файла; 2 — вывод значений функций; 3 — вывод значений полей; 4 — значение функции bof О  (начало файла); 5 — шаг «назад на 1 за­пись»; 6 — переход в конец файла; 7— значение функции eof () (конец файла); 8 — шаг «вперед на 1 запись»

командой ? просматриваются значения функций (2), определяющих номер текущей записи (геспо ()) и общее число
записей в файле (reccount ());

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

функция bof () имеет значение . f.  (false), это говорит о том, что начало файла (Begin Of File) не достигнуто (4);

командой skip делается попытка «шагнуть за начало файла» (5), что приводит к установке bof () в значение . t. (true);

командой go bottom задается переход к первой записи файла (6);

командой ? просматриваются значения функций геспо () и reccount (), а также значения полей текущей записи;

функция eof () имеет значение . f.   (false), это означает, что конец файла (End Of File) не достигнут (7);

командой skip 1 делается попытка «шагнуть за конец файла» (8), что приводит к установке eof ()  в значение  .t. (true).

Хотя это и не совсем по теме, но здесь уместно продемонстрировать и другие возможности диалоговых команд — выполнение в он-лайновом режиме последовательности действий над файлами, записями и переменными оперативной памяти. Рассмотрим пример, иллюстрирующий заодно упомянутую выше особенность FoxPro — возможность изменять тип переменной (рис. 3.13):

А и в определяются как символьные переменные, поскольку в них вводятся строки (/);

с также становится символьной, так как в нее записывается конкатенация строк и литералов (2);

затем переменные распечатываются (3), а также выводится иллюстрация к функции substr (4);

А и в переопределяются как числовые переменные, и с, как их сумма, также принимает числовой тип (5); А, в, с
распечатываются (6);

осуществляются операции умножения, деления, возведения в степень над переменными А и в (7).

Рис. 3.13. Некоторые операции над переменными памяти и наблюдение над ними посредством диалоговых команд:

1 — ввод символьных переменных; 2 — конкатенация переменных и литералов; 3 — распечатка символьных значений; 4 — функция substr; 5 — ввод символьных переменных; 6 — распечатка числовых переменных; 7 — результаты операций над числовыми, переменными

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

Просмотр списка файлов. Чтобы вывести на экран дисплея список всех имеющихся файлов, используют команду dir.На экране появляется список файлов с расширением. Расширение, добавляемое системой, служит для группировки файлов по типам:

. idx — индексный файл;

 .prg — файл команд;

. dbf — файл данных;

. f rt — форматы отчетов;

. bak — резервная копия файла.

Копирование файла. Чтобы скопировать файл, нужно выполнить две операции.

Поместить файл, который нужно скопировать, в рабочую область, используя команду use:

use <имя файла>

Скопировать файл, дав команду сору:

copy to <имя нового файла>

Удаление файла. Удалить файл, который является текущим рабочим файлом, невозможно. Чтобы добиться цели, следует закрыть текущий файл. Все файлы данных можно закрыть по команде use. Имя файла не указано, следовательно, закрывается любой открытый в настоящее время файл. Просмотреть оставшиеся файлы можно по команде dir:

use

delete file <имя файла с расширением>

dir

Копирование структуры файла. Для копирования структуры файла набрать команды:

use  <имя  файла> — открыть исходный файл,

copy  structure  to  <имя нового файла> — скопировать структуру,

use  <имя нового  файла> — перейти к новому файлу,

display structure — просмотр структуры.

Ввести данные.

Добавление записей из другого файла. Вызвать исходный файл. Добавить записи к исходному файлу из другого:

append from <имя второго файла>

Изменение структуры файла

use <имя файла> modify structure

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

Переименование файла

rename <старое имя> то <новое имя>

Удаление записей из файла. Удаление записи осуществляется в два этапа:

запись, предназначенная для удаления, маркируется — логическое удаление (запись при просмотре командами list,
browse помечается *).  Если обнаружена ошибка, запись можно размаркировать;

файл «упаковывается» (команда pack).  В процессе «упаковки» записи физически удаляются из файла. После «упаковки» восстановить их уже нельзя

use <имя файла>

edit — просмотр файла

delete record <№ удаляемой записи>

Маркируются все записи, которые нужно удалить:

recall   record  <№  восстанавливаемой  записи>

edit — просмотр файла pack

В командах delete и recall для маркировки записей можно использовать диапазоны и логические выражения:

go top

delete     all

delete     for <логическое_выражение>

recall      for <логическое выражение>

recall      all

Подсчет записей и данных. В FoxPro включены команды, с помощью которых можно получить количественную информацию о данных, содержащихся в файлах:

  • если нужно найти число записей, удовлетворяющих заданному критерию, то используют команду COUNT:

use <имя файла>

count for <логическое_выражение>

  • команда SUM предназначена для суммирования содержимого конкретного поля. Она может применяться в сочетании с логическими выражениями для получения суммы определенных записей файла:

use <имя файла>

sum <имя поля> for <логическое_выражение>

Вернемся к нашей базе данных Prsnll. На рис. 3.14 приведены результаты этих команд. Здесь команда размещена в ко­мандном окне, количество записей — на статусной строке, результат — в рабочей зоне. Конечно, подсчет суммы годов рождения особей женского пола не более чем шутка (хотя результат может использоваться, например, для определения среднего возраста женщин, представленных в БД). Но это и лишнее напоминание читателю, что машине все равно, что суммировать (поле — числовое) — она не думает. Думать должен программист (или хотя бы пользователь).

Рис. 3.14. Результаты команды count (о), sum (б) и aver (в)

Между прочим, вычисление среднего значения числового поля тоже предусмотрено в FoxPro (рис. 3.14, в).

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

sort on <имя поля> то <имя нового файла>

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

Индексируемый файл по ФИО

001 Иванов
002 Сидоров
003 Петров

Результат

Иванов
Петров
Сидоров

Записывая только порядок записей в индексный файл, мы экономим время и память. Индексирование позволяет для одного файла данных хранить несколько индексных файлов:

index on <имя поля (полей)> то <имя индексного файла>

Удаление дублирующихся записей. В файле могут быть дублирующиеся записи. Для их удаления можно использовать команду set unique on, выполняемую перед индексированием соответствующего файла:

set unique on

index on <имя ключевого атрибута> то <имя индексного файла>

Переход к другому открытому файлу (рабочей области)

select {<номер_рабочей_области> | <псевдоним_файла>}

Команда select обеспечивает выбор одной из десяти доступных рабочих областей для открытия файла базы данных или выбор рабочей области, в которой уже открыт файл БД. Если в рабочей области уже открыт файл, то выбрать рабочую область можно и по ее псевдониму К, где К < 10:

select к

use <имя файла>

Соединение двух таблиц БД команда join. Команда создает новый файл базы данных из двух существующих файлов (рис. 3.15, а). Команда join устанавливает указатель на первую запись активного файла БД и выполняет последовательный просмотр второго файла. При нахождении записи, удовлетворяющей условию, ее содержимое присоединяется к текущей записи активного файла и помещается в выходной файл. Команда join требует предварительной сортировки или индексирования обоих файлов.

Рис. 3.15. Связывание таблиц: а — команда join; б — команда set relation

Синтаксис:

join with <псевдоним файла> to <файл> for условие [fields <список_полей>][for условие]

Команда join создает новый файл данных путем указанных записей и полей из текущего файла и файла данных, обозначенного как <псевдоним_файла>.Комбинированная база данных сохраняется в <файл>. Вы можете ограничить выбор записей из активного файла данных, определив условие for. Если вы не включите список полей (<список_полей>), то будут скопированы все поля из обоих файлов. Определить поля из неактивного файла данных можно, используя конструкцию <файл>-><имя_поля> или <файл>.

select 1 use file 1

select 2 use file_2

select 1

join  with   2   into   file   3

for  filel.field2=file2.   field2

В результирующую таблицу попадут такие записи f ile_l и file_2, которые имеют одинаковые значения поля field2.

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

Формат команды:

set relation to@KOD = [<выражение> 1 into <номер_рабочей_области>1 | <псевдоним_файла>1 -[,<выражение>2 into <номер_рабочей_области>2 |<псевдоним_файла>...]

[in <номер_рабочей_области> | <псевдоним_файла>] [additive]]

Параметры

<выражение>1 задает реляционное выражение, которое устанавливает отношение между основной и зависимой таблицами. В качестве реляционного выражения обычно используется выражение управляющего индекса зависимой
таблицы;

into  <номер_рабочей_области>1 | <псевдоним файла> 1 - задает для зависимой таблицы номер рабочей области
(<номер_рабочей_области>1)  или псевдоним  (<псевдоним_файла>1);

<выражение>2 INTO <номер_рабочей_области>2 | <псевдоним_файла> 2 ... и т. д. — с помощью одной команды set  relation можно построить несколько отношений между одной основной и различными зависимыми
таблицами;

in <номер_рабочей_области> задает рабочую область основной таблицы,  in  <псевдоним_файла> задает псевдоним основной таблицы. Если аргументы опущены, основная таблица должна быть открыта в выбранной в данный
момент рабочей области;

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

Рассмотрим пример:

select 1 use file_l

select 2 use file_2 index field_l

select 3 use file_3 index field_2

select 1

set relation to field_l into 1

field_2 into 2

additive

Здесь текущий файл (file_1) связывается с зависимыми файлами (f ile_2 и f ile_3), после чего записи зависимых файлов «берутся на буксир» и сопровождают записи текущего файла при перемещении. Предполагается, что зависимые файлы индексированы, причем индексные выражения соответствуют полям fieldl и field_2. Тогда в каждый момент времени из зависимых файлов активными будут записи, содержащие значения f ield_l и f ield_2 текущей записи основного файла.

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

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

3.4. Создание и модификация форматов представления данных

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

В ранних версиях (Dbase, FoxBase) экранные формы создавались посредством группирования команд ввода-вывода в текстовый файл, который подключался при открытии файла данных для просмотра или редактирования. Вот пример подобного файла, а на рис. 3.16 приводится его интерпретация VFP:

*             формат экрана - PRSN1T

@            1,15         say         [Студенческий контингент]

@            3,10         say         [Имя]

@            3,17         get          name

@            3,30         say         [Год рождения]

@            3,50         get          Year

@            5,10         say         [Пол]

@            5,15         get          sex

@            5,20         say         [Телефон]

@            5,30         get          phone

@            7,10         say         [Адрес]

@            7,20         get          adress

read

*             Конец формата PRSN1T.

Рис. 3.16. Интерпретация текстового описания экранной формы

В системе VFP представлены два уровня средств управления представлением данных.

 

Рис. 3.17. Окно Tools — выбор генератора простейших экранных форм

Это, вопервых, Form Wizard И Report Wizard, запускаемые из рубрики Tools главного меню и позволяющие начинающему пользователю выбрать из предлагаемого набора некоторые экранные формы или форматы отчета и построить простейшие управляющие файлы (рис. 3.17). Во-вторых, это средства Form Designer и Report Designer, которые вызываются из меню или командами create (modify) screen, create (modify) report.

Генерация экранных форм

На рис. 3.18 представлены различные этапы генерации простых экранных форм:

  • первый шаг — выбор таблиц и полей из таблиц для представления в экранной форме (рис. 3.18, а). Пользователю
    предлагается отобрать необходимые данные и занести их в список;

  • второй шаг — выбор стиля экрана (рис. 3.18, б). Здесь можно выбрать оформление экранной формы из нескольких
    стандартных типов (в частности, различающихся шрифтами, разделителями, типом управляющих кнопок и пр.);

  • третий шаг (рис. 3.18, в). Пользователь задает порядок выдачи данных из файла. Могут быть заданы до трех полей
    сортировки записей;

  • четвертый шаг — завершение работы и сохранение форматного файла (здесь — prsnlf .sсx).

Рис. 3.18. Генератор экранов:

а — выбор полей таблицы; б — выбор стиля формы; в — задание режима сортировки   записей;  г — завершение   работы и сохранение формата (файл prsnlf.sex)

 

Рис. 3.18. Генератор экранов (окончание)

Рис. 3.19. Различные стили формата экрана:

а — standard (текстовые кнопки); б— embossed (графические кнопки); / — пе­реход в начало файла; 2 — переход к предшествующей записи; 3 — переход к следующей записи; 4 — переход к концу файла; 5 — поиск по логическому критерию

Пример управления выходным форматом приводится на рис. 3.19. При просмотре файла могут быть заданы критерии отбора релевантных записей (рис. 3.20).

Полученный на этом этапе экранный формат может быть затем откорректирован и развит средством Form Designer (рис. 3.21).

Рис. 3.20. Подключение режима отбора записей в формате экрана:

а — экран установки критерия отбора (кнопка Find); б — просмотр файла при включенном критерии отбора (Year = 1985)

Рис. 3.21. Командой modify format вызван Form Designer для уточнения формата генерация отчетов

     На рис. 3.22 представлены различные этапы создания простых форматов отчетов:

  • первый шаг — выбор таблиц и полей из таблиц для представления в экранной форме (рис. 3.22, а). Пользователю предлагается отобрать выводимые данные и занести их в список;

Рис. 3.22. Генератор отчетов:

а — шаг выбора полей; б — задание группировки записей и подсчета групповых данных; в — выбор стиля отчета

 

Рис. 3.22. Генератор отчетов (окончание)

  • второй шаг — выбор стиля экрана (рис. 3.22, б). Здесь можно выбрать оформление экранной формы из нескольких
    стандартных типов (в частности, различающихся шрифтами и оформлением колонок и пр.);

  • третий шаг (рис. 3.22, в). Пользователь задает порядок выдачи данных из файла (сортировка и группирование). Мо-

Рис. 3.23. Пример простейшего отчета (стиль — Ledger, записи сгруппированыпо годам рождения)

Рис. 3.24. Командой modify   report вызван Report   Designer для уточнения формата

гут быть заданы до трех  полей  группирования  записей. Здесь же можно потребовать вычисление агрегатных функций по каждой группе (сумма, среднее и пр.). Пример выходного формата отчета приводится на рис. 3.23. Затем полученный на этом этапе экранный формат может быть откорректирован И развит средством Report  Designer (рис. 3.24).

3.5. Использования табличной СУБД FoxPro для документального поиска

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

При этом хотелось бы отметить, что в традиционном понимании выражение «информационная система» (особенно «автоматизированная информационная система» или «автоматизированная информационно-поисковая система — АИПС») обычно ассоциируется с документальными системами  (базами данных);

термин же «база данных», как правило, ассоциируется с факто­графическими, управленческими системами, задачами типа АСУ. Хотя конечно же и те и другие типы систем являются информационными и включают базы данных в свой состав.

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

Таблица 3.2. Сравнительные характеристики основных типов АИС

 

Атрибуты систем

Типы систем

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

Документальные

Модель (структура) предмет­ной области

Структура БД (логическая и физическая)

Содержание БД (структура стан­дартна для разных областей)

Информационная совокупность

База данных (иногда файловая сис­тема ОС)

База данных

Единица информации

Запись (агрегат данных жесткой структуры)

Документ (агрегат данных диф­фузной структуры)

Физическая среда хранения информации

Файловая система ОС

Файловая система или факто­графическая БД

Вывод информации (входной язык)

Пользовательский интерфейс (язык запросов)

Пользовательский интерфейс (информационно-поисковый язык)

Обработка (поиск) информации

ОС или СУБД

СУБД или программная оболоч­ка АИ ПС

Программные средства реали­зации

Табличные СУБД и системы програм­мирования с элементами СУБД -ADABAS, FoxPro, Oracle, MS SQL SERVER

Программные оболочки АИПС -DPS, STAIRS, ISIS, IRBIS

Рассмотрим пример реализации документальной АИС по законодательству Юриус на основе системы программирования СУБД FoxPro.

Интегральный банк юридической информации ЮРИУС/JURIUS (логическая, физическая структура)

ЮРИУС — Юридическая универсальная информационная система — представляет собой совокупность средств и методов поиска текстовой юридической информации и подробно рассматривается здесь, поскольку является первой отечественной системой [10, 25].

Логическая структура. С логической точки зрения входящие в JURIUS БД имеют относительно стандартную структуру и включают две компоненты — регистрационные карты (РК) и полные тексты. РК представляют собой форматированные записи, содержащие относительно стандартный набор библиографических данных, а также ссылку на соответствующий полный текст (рис. 3.25). Полные тексты документов состоят из страниц двух типов:

Рис. 3.25. Логическая структура БД ЮРИУС

  • логических, т. е. структурных единиц текста (пункт, параграф, статья);

  • физических (принудительное разбиение длинного неструктурированного текста на фрагменты одинаковой длины).

Данная структура базы данных позволяет осуществлять по­иск по цепочкам:

Термин — РК — Документ — Страница (интерфейс IX)
или

Термин — Страница —Документ — РК'(интерфейс DC).

Физическая структура БД ЮРИУС (рис. 3.26) является примером реализации документальной системы в среде системы программирования с элементами реляционной СУБД.

Рис. 3.26. Физическая структура БД и использование файлов модулями пользовательского интерфейса

Файл текстовой части БД (szdoc.dbf) один или несколько файлов, в которых содержатся полные тексты актов (см. также рис. 3.34). На логическом уровне образует иерархическую структуру: БД (том), документ, страница (рис. 3.26).

Словарный файл текстовой части (dcfrv.dbf) представляет собой список слов и/или словосочетаний (например, «статья 256», «п. 13», «№ 1400-РП»), извлеченных из текста, сопровождаемых частотами появления в данной БД (см. рис. 3.31, 3.32). Практика выделения словосочетаний при индексировании с целью включения их в словарь и инверсный список является достаточно известной.

Инверсный файл текстовой части (dcind.dbf) — список кодов слов и словосочетаний, сопровождаемых номерами страниц. Словарный и инверсный файл используются для сквозного полнотекстового поиска.

Справочно-поисковые файлы (СПФ) (до 9 различных файлов sf 1. dbf—sf 9 . dbf). Стандартным является файл регистрационных карт нормативных актов (РК), запись которого содержит наименование, дату, номер, вид, ссылки на страницы БД и другие поля, перечень которых может изменяться для конкретной БД (рис. 3.27).

 

Рис. 3.27. Взаимодействие программных компонент ЮРИУС в процессе создания и использования БД

Словарь справочно-поисковых файлов (ixfrv.dbf) содержит значения и коды полей (например, РК) совместно с частотой появления (см. рис. 3.27) и ссылкой на номер файла СПФ.

Инверсный файл СПФ (ixind.dbf) содержит коды слов и словосочетаний. Словарный и инверсный файлы используются для поиска записей СПФ (РК, рубрики указателя и т. д.) с доступом к странице БД.

Файл синонимов (ixtrc) служит для расшифровки кодов или для обеспечения двуязычного поиска в словарных файлах (см. рис. 3.26).

Файл описания СПФ (словарь данных ixddm.dbf — табл. 3.3) содержит данные о полных, сокращенных и внутренних именах полей каждого СПФ, типах данных, разделителях слов, методах обработки числовых кодов и т. д. Используется при поиске через СПФ и при построении словарных и инверсных файлов.

Файлы хранимых запросов (sql—sq9) содержат запросы к СПФ БД, отлаженные и сохраненные пользователем.

Файл заметок (NotaBene) позволяет пользователю дополнить СПФ собственными именованными прямыми ссылками на страницы БД.

Программные средства БД ЮРИУС. Рассмотрим структуру программных средств ИБД ЮРИУС (см. рис. 3.27).

Средства администратора БД и АРМ подготовки данных. Программные средства ЮРИУС позволяют осуществлять выделение тематических фрагментов БД на основе дескрипторного поиска и объединения нескольких фрагментов и БД (нескольких БД) при установке у пользователя.

Функции интерфейса оператора подготовки данных (ОПД) встроены в интерфейс АБД, однако в состав ЮРИУС входит также АРМ ОПД, распространяемый отдельно и предназначенный для децентрализованного использования в пунктах подготовки данных.

АРМ оператора подготовки данных реализует следующие функции:

  • ввод текстов актов и регистрационных карт;

  • поиск РК по названию, дате, номеру;

  • просмотр и корректировка РК и текста акта.


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

Центральный интерфейс АБД обеспечивает функции: .

  • построения словарного и инверсного файлов для СПФ;

  • корректировки (вставку, удаление, редактирование элементов) СПФ с соответствующим обновлением ассоциированных файлов;

  • построение словарного и инверсного файлов для полнотекстового словарного поиска;

  • просмотр словарей, визуальное обнаружение ошибок, исправление словарей и текста; дозагрузку данных в БД;

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

Основные операции при загрузке БД в рамках центрального интерфейса (случай поиска по РК) включают построение на основе файла sfl файлов ixind, ixfrv, управление процессом загрузки  (типом  обработки  полей)  осуществляется с помощью файла ixddm, структура и содержание основных полей которого приведены в табл. 3.3.

Таблица 3.3. Пример словаря данных для регистрационных карт БД по финансовому законодательству (ФЗ)

 

со

 

U-

FLDNM

HDR01

HDR02

MULTI

DESCR

FLENG

LONGF

HINMB

INITV

TERMW

PURGW

RLENG 1

FIDEC

1

TRCOD

00

 

Регистрационные карты нормативных актов

РК

10

+

0

0

10

02

 

 

0

0

 

0

01

N1

Заглавие документа

Загл

40

 

240

3

55

А

 

,:;"()/?!<>

20

0

А

0

02

D1

Дата утверждения

Дата

1

 

8

1

8

 

 

 

8

0

А

0

03

А1

Номер акта

Номер

3

 

23

1

9

 

,*

10

6:

X

0

 

04

V1

Вид документа

Вид

5

 

35

1

2

 

*

20

0

А

0

 

05

01

Орган, утвердив­ший акт

Орган

5

 

44

1

6

А

 

20

0

А

0

 

06

R1

Классификацион­ная рубрика ЭК

Рубрика

10

 

120

1

10

 

 

:"[]()

20

0

А

0

07

К1

Ключевые слова

Ключ. сл.

10

 

160

1

7

А

,.

*

20

0

А

0

08

11

Опубликовано (источник)

Источник

5

 

79

1

18

 

 

20

0

А

0

 

09

S1

Статус документа

Статус

1

 

30

1

1

 

 

 

30

0

А

0

10

Т1

База данных (том)

БД

1

 

2

1

1

 

 

 

2

0

А

0

Локальный интерфейс АБД реализует следующие функции при установке БД на машине пользователя: определение и выбор устанавливаемого фрагмента БД; инсталляция выбранного фрагмента БД; объединение нескольких фрагментов БД (нескольких БД из ЮРИУС).

Интерфейсы конечного пользователя: IX-интерфейс доступа, использующий предъявление пользователю частотных словарей полей РК в форме PullDown-меню (рис. 3.28). Выбранные пользователем значения из словаря комбинируются в логическое выражение запроса. Найденные РК могут просматриваться в полном (рис. 3.30) или сокращенном (рис. 3.29) форматах, затем пользователь может перейти к просмотру полного текста (рис. 3.31). Интерфейс IX обеспечивает

Рис. 3.28. Главное меню (IX). Поиск в частотном словаре (по заголовкам)

Рис. 3.29. После поиска. Найдено четыре документа (сокращенный формат)

Рис. 3.30. Просмотр РК в полном формате

Рис. 3.31. Просмотр полного текста (начало документа)

поиск по значениям полей РК с последующим переходом к соответствующему полному тексту.

После запуска интерфейсной программы на экране терминала появляется заставка системы, а после инициализации — Главное меню.

Структура Главного меню определяется структурой поискового файла, содержащего РК документов, и состоит из следующих строк и компонент (рис. 3.28):

строка горизонтального меню. Перемещение по горизонтальному меню осуществляется с помощью клавиш <^>
и <^>;

Cтроки вертикального меню, зависящие от выбора горизонтальной рубрики. Активизация вертикальной рубрики производится клавишами <Т>, <1> и нажатием ;

строка запроса, строка предупреждений, строка комментария.

Рубрики горизонтального меню разделяются на две группы:

постоянные рубрики — пункты *Команда*,  *3апрос*, *NotaBene*;

переменные рубрики — список поисковых полей регистрационных карт. Этот список определяется составом РК и
может меняться для различных БД из Банка ЮРИУС.

При поиске в словаре по Значению необходимо в экранном окне набрать несколько первых символов отыскиваемого в словаре термина (рис. 3.28). На экране отображается страница словаря, начиная с первого термина, содержащего введенные символы. После формирования запроса необходимо перейти к рубрике Команда и выполнить запрос. Результат поиска (в сокращенном формате одна запись — одна строка экрана) представлен на рис. 3.29. Для перехода к просмотру полного текста (рис. 3.31) необходимо подвести курсор к соответствующей строке (рис. 3.29) или к позиции Текст (рис. 3.30) и нажать .

Интерфейс полнотекстового поиска (DC). Пример главного меню DC-интерфейса приводится на рис. 3.32. Поиск в частотном словаре активизируется рубрикой Значение (рис. 3.32).

Рис. 3.32. Главное меню (DC). Поиск в частотном словаре полных текстов

Рис. 3.33. После поиска. Найдено 12 страниц

Для поиска страниц, содержащих термин запроса, необходимо установить курсор на термин и нажать (рис. 3.33). Переход к полному тексту (рис. 3.34) осуществляется активизацией рубрики Текст Главного меню.

Рис. 3.34. Первая из найденных 12 страниц

В Приложениях 6, 7 содержатся задание на лабораторную работу по исследованию логической и физической структуры БД ЮРИУС и пример отчета о такой работе, из которого ясно, каким образом может осуществляться навигация в БД путем использования диалоговых команд FoxPro.

Контрольные вопросы

  1. Назовите основные типы файлов, образующих физическую структуру БД FoxPro.

  2. Каково назначение индексного файла? Каким образом он может быть создан и активизирован?

  3. Каким образом осуществляется отображение информации из БД?

  4. Перечислите команды навигации в БД.

  5. Каким образом можно перейти к началу файла? В конец файла?

  6. Перечислите команды диалогового ввода-вывода информации.

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

  8. В чем заключается различие операторов if и do  case?

  9. Перечислите основные понятия, характеризующие связь данных в БД.

  10. Что такое экранные формы и каким образом они создаются и редактируются?

  11. Что такое форматы отчетов и как они создаются и редактируются?

  12. Охарактеризуйте логическую и физическую структуру БД ЮРИУС.

Глава 4

ЭЛЕМЕНТЫ И КОНСТРУКЦИИ ЯЗЫКА SQL

 

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

организации данных — SQL позволяет определять и изменять структуру представления данных, а также устанавливать отношения;

обработки данных — SQL позволяет изменять содержимое базы данных: добавлять новые данные, удалять или обновлять уже имеющиеся в ней данные;

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

Таким образом, хотя SQL и не объявляется как полноцен­ный язык программирования (в стандартном SQL89, реализованном в полном объеме для реляционных СУБД, нет оператора проверки условий и ветвления, нет оператора перехода, нет операторов циклов и т. д., однако SQL большинства промышленных СУБД содержит эти и многие другие операторы, позволяющие создавать полноценные процедуры обработки данных), он является подъязыком баз данных, предназначенным для управления базами данных. Несмотря на не совсем точное название, SQL на сегодняшний день является единственным стандартным языком для работы с реляционными базами данных.

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

Официальный стандарт языка SQL был опубликован в 1986 г. Американским институтом национальных стандартов (ANSI) и Международной организацией по стандартам (International Standards Organization — ISO), а в 1992 г. значительно расширен. Стандарт X/OPEN для переносимой среды программирования на основе операционной системы UNIX также включает в себя SQL в качестве языка для доступа к базам данных. Консорциум поставщиков компьютерного оборудования и баз данных (SQL Access Group) определил для SQL стандартный интерфейс вызовов функций, который является основой протокола ODBC компании Microsoft и входит также в стандарт X/OPEN. Эти стандарты дефакто являются официальным одобрением SQL, и именно они ускорили завоевание им рынка.

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

Чтобы заполнить эти пробелы, комитет ANSI продолжил свою работу и создал проект нового, более жесткого стандарта SQL2. В отличие от стандарта 1989 г. проект SQL2 предусматривал возможности, выходящие за рамки таковых, уже существующих в реальных коммерческих продуктах.

Перечислим эти отличия SQL2.

Коды ошибок. В стандарте SQL2 определены стандартные Коды ошибок, которые возвращают операторы SQL при возникновении ошибок.

Типы данных. В стандарте SQL2 упомянуты многие стандартные типы данных (например, символьные строки переменной длины, дата и время, а также денежные единицы), однако отсутствуют «новые» типы данных, такие, как графические и мультимедийные объекты.

Системные таблицы. В стандарте SQL-89 умалчивается о системных таблицах, в которых содержится информация о структуре самой базы данных. Поэтому каждый поставщик создавал собственные системные таблицы. Например, их структура отличается даже в четырех реализациях SQL компании IBM. В SQL2 системные таблицы стандартизированы.

Интерактивный SQL. В стандарте SQL-89 определен только программный SQL, используемый прикладной программой, но не интерактивный SQL. Например, оператор select, предназначенный для выполнения запросов к базе данных в интерактивном режиме, в стандарте отсутствует.

Программный интерфейс. В стандарте SQL2 определен интерфейс встроенного SQL для некоторых языков программирования, но не интерфейс вызова функций.

Динамический SQL. В стандарте SQL-89 не описаны элементы SQL, необходимые для разработки приложений общего назначения, таких, как генераторы отчетов и программы создания и выполнения запросов. Однако эти элементы, известные под названием динамический SQL, имеются почти во всех СУБД и в различных системах значительно различаются. В стандарт SQL2 входит раздел динамического SQL.

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

Последовательность сравнения. Стандарт SQL2 позволяет программе или пользователю указывать требуемую последовательность сортировки результатов запроса.

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

Основными направлениями развития SQL2 (и принятие SQL3) являются:

  1. стандартизация интерфейсов вызова функций;

  2. стандартизация хранимых процедур;

  3. добавление объектно-ориентированных возможностей.

4.1. Основные понятия и компоненты

Инструкции и имена

SQL представлен множеством инструкций, каждая из которых предписывает СУБД выполнить определенное действие: создать таблицу, извлечь данные, добавить в таблицу новые данные и т. п. Инструкция SQL начинается с команды — ключевого слова, описывающего действие, выполняемое инструкцией. Типичными являются команды create (создать), insert (добавить), select (выбрать), delete (удалить). Следом за командой указываются одно или несколько предложений. Предложение описывает данные, с которыми должна работать инструкция, или уточняет действие, выполняемое инструкцией. Предложения в инструкции делятся на обязательные и необязательные. Каждое предложение начинается с ключевого слова, например where (где), from (откуда), into (куда). Многие предложения в качестве параметров содержат имена таблиц или столбцов. Некоторые из них могут содержать дополнительные ключевые слова, константы и выражения.

У каждого объекта в базе данных есть уникальное имя. Имена используются в инструкциях SQL и указывают, над каким объектом базы данных инструкция должна выполнить действие. В соответствии со стандартом ANSI/ISO имена в SQL могут содержать от 1 до 18 символов, начинаться с буквы и не должны включать пробелов или специальных символов пунктуации. В стандарте SQL2 максимальное число символов в имени увеличено до 128. На практике в различных СУБД поддержка именования реализована по разному: в DB2, например, имена пользователей не могут превышать 8 символов, а имена таблиц и столбцов могут быть более длинными. В различных СУБД также существуют и различные подходы к использованию в именах специальных символов.

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

Имя_пользователя. Имя_таблицы

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

Полное имя столбца, в свою очередь, состоит из полного или короткого имени таблицы, которой принадлежит столбец, и короткого имени столбца, разделенных точкой:

Имя пользователя. Имя_таблицы. Имя_столбца

или

Имя_таблицы. Имя столбца

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

Типы данных

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

целые числа (int, small int). В столбцах, имеющих такой тип данных, обычно хранятся данные о количестве и возрасте сотрудников, идентификаторы;

десятичные числа (numeric, decimal). В столбцах данного типа хранятся числа, имеющие дробную часть с фиксированным количеством знаков после запятой, например курсы валют и проценты;

числа с плавающей запятой (real, float). Числа с плавающей запятой представляют больший диапазон действительных значений, чем десятичные числа;

строки символов постоянной длины (char).  В столбцах, имеющих этот тип данных, хранятся имена и фамилии,
географические названия, адреса и т. п.;

строки символов переменной длины (varchar). Столбцы этого типа позволяют хранить символьные строки, длина
которых изменяется в заданном диапазоне;

денежные величины  (money,  smallmoney).  Наличие отдельного типа данных для хранения денежных величин позволяет правильно форматировать их и снабжать признаком валюты перед выводом на экран;

дата и время (datetime, smalldatetime). Поддержка особого типа данных для значений дата/время широко распространена в различных СУБД. Как правило, с этим типом данных связаны особые операции и процедуры обработки;

булевы величины (bit). Столбцы такого типа данных позволяют хранить логические значения True (1) и False (о);

длинный текст (text). Многие СУБД поддерживают хранение в столбцах текстовых строк длиной до 32 Кбайт или
64 Кбайт символов, а в некоторых случаях и больше. Это позволяет хранить в базе данных целые документы;

неструктурированные потоки байтов (binary, varbinary, image). Современные СУБД позволяют хранить и извлекать неструктурированные потоки байтов переменной длины. Такой тип данных обычно используется для хранения
графических и видеоизображений, исполняемых файлов и других неструктурированных данных.

Встроенные функции

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

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

  • математические функции;

  • строковые функции;

  • функции для работы с величинами типа «дата» или «время»;

  • функции конфигурирования;

  • системные функции;

  • функции системы безопасности;

  • функции управления метаданными;

  • статистические функции.

В табл. 4.1 приведены наиболее часто используемые функции первых трех групп.

Таблица 4.1. Основные функции SQL

Функция

Назначение

ABS(число)

Вычисляет абсолютную величину числа

ISNUMERIC(выражение)

Определяет, имеет ли выражение числовой тип данных

SIGN(число)

Определяет знак числа

RAND(целое  число)

Вычисляет случайное число с плавающей запятой в интерва­ле от 0 до 1

ROUND(число,   точность)

Выполняет округление числа с указанной точностью

POWER(число,   степень)

Возводит число в степень

SQRT(число)

Извлекает квадратный корень из числа

SIN(угол)

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

COS(угол)

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

ЕХР(число)

Вычисляет экспоненту числа

LOG(число)

Вычисляет натуральный логарифм числа

LEN(строка)

Вычисляет длину строки в символах

LTRIM(строка)

Удаляет пробелы в начале строки

RTRIM(строка)

Удаляет пробелы в конце строки

LEFT(строка,   количество)

Возвращает указанное количество символов строки, начиная с самого левого символа

RIGHT(строка,   количество)

Возвращает указанное количество символов строки, начиная с самого правого символа

Окончание табл. 4.1

Функция

Назначение

LOWER(строка)

Приводит символы строки к нижнему регистру

UPPER(строка)

Приводит символы строки к верхнему регистру

STR(число)

Выполняет конвертирование числового значения в символь­ный формат

SUBSTRING(строка,   индекс, длина)

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

GETDATE()

Возвращает текущее системное время

ISDATE(строка)

Проверяет строку на соответствие одному из форматов даты и времени

DAY(дата)

Возвращает число указанной даты

MONTH(дата)

Возвращает месяц указанной даты

YEAR(дата)

Возвращает год указанной даты

DATEADD'(тип,   число,   дата)

Прибавляет к дате указанное число единиц заданного типа (год, месяц, день, час и т. п.)

Значения NULL

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

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

Правила обработки значений null в различных инструкциях и предложениях включены в синтаксис языка.

4.2. Ограничения целостности

Первичный ключ таблицы

Всякая таблица обычно содержит один или несколько столбцов, значение или совокупность значений которых уникально идентифицирует каждую строку в таблице. Этот столбец (или столбцы) называется первичным ключом (primary key — Рk) таблицы.

Если в первичный ключ входит более одного столбца, значения в пределах одного столбца могут дублироваться, но любая совокупность значений всех столбцов первичного ключа при этом должна быть уникальна. Например, в таблице Дисциплины один столбец (ID_Дисциплина) определен как первичный ключ (рис. 4.1), а для таблицы Сводная ведомость задан составной первичный ключ — в него входят значения столбцов ID_Студент и ID_Дисциплина.

Рис. 4.1. Первичный ключ таблицы Учебный_план

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

Еще одним назначением первичного ключа является обеспечение ссылочной целостности данных в нескольких таблицах. Естественно, это может быть реализовано только при наличии соответствующих внешних ключей (foreign key — fk) в других (дочерних) таблицах.

Если по столбцу строится первичный ключ, столбцу должен быть приписан атрибут primary key (ограничение целостности на уровне столбца), например, описание столбца id _План для таблицы Учебный_план (рис. 4.1) может выглядеть следующим образом:

ID_Дисциплина  INTEGER NOT NULL PRIMARY KEY

Первичный ключ может быть также построен и с помощью отдельного предложения primary key (ограничение целостности на уровне таблицы) путем включения имени (имен) ключевого столбца (столбцов) в качестве параметров. Например, первичный ключ для таблицы Сводная_ведомость (рис. 4.2) может быть задан следующим образом:

PRIMARY KEY (ID_Дисциплина, ID_Студент)

Рис. 4.2. Первичный ключ таблицы Сводная_ведомость

Внешний ключ таблицы

Внешний ключ строится в дочерней (зависимой) таблице для соединения родительской (главной) и дочерних таблиц БД.

Это ограничение целостности предназначено для организации ссылочной целостности данных. Внешний ключ связывается с потенциальным первичным ключом в другой таблице. Внешний ключ при этом может ссылаться либо на столбец (или столбцы) с ограничением целостности primary key, либо на столбец (столбцы) с ограничением целостности unique.

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

Например, если строка наименования дисциплины удалена из таблицы Дисциплины, а идентификатор этой дисциплины (ID_Дисциплина) используется в таблице Учебный_план, то относительная целостность между этими двумя таблицами будет нарушена — строки таблицы Учебный_план с удаленным идентификатором останутся «осиротевшими». Ограничение foreign key предотвращает возникновение подобных ситуаций — удаление строки первичного ключа не состоится.

Столбцы внешнего ключа (в отличие от столбцов первичного ключа) могут содержать значения типа null, однако при этом проверка на ограничение foreign key будет пропускаться. Задать внешний ключ можно как при создании, так и при изменении таблиц.

Синтаксис определения внешнего ключа следующий:

FOREIGN KEY (<список столбцов внешнего ключа>),

REFERENCES <имя родительской таблицы>

[<список столбцов родительской таблицы>]

[ON DELETE {NO ACTION | CASCADE | SET DEFAULT | SET NULL}]

[ON UPDATE {NO ACTION | CASCADE | SET DEFAULT| SET NULL}]

Список столбцов внешнего ключа определяет столбцы дочерней таблицы, по которым строится внешний ключ.

Имя родительской таблицы определяет таблицу, в которой описан первичный ключ (или столбец с атрибутом unique). На этот ключ (столбец) должен ссылаться внешний ключ дочерней таблицы для обеспечения ссылочной целостности.

Список столбцов родительской таблицы, определяющий ссылочную целостность, необязателен при ссылке на первичный ключ родительской таблицы. При ссылке в родительской таблице на столбец с атрибутом unique этот список лучше привести.

Параметры on delete, on update задают способы изменения подчиненных записей дочерней таблицы при удалении (ON delete) или изменении (on update) поля связи в записи родительской таблицы.

Перечислим эти способы:

no action — запрещает удаление/изменение родительской записи при наличии подчиненных записей в дочерней таблице;

cascade — при удалении записи родительской таблицы (используется совместно с on  delete) происходит удаление всех подчиненных записей в дочерней таблице; при изменении поля связи в записи родительской таблицы (используется совместно с on update) происходит изменение на то же значение поля внешнего ключа у всех подчиненных записей в дочерней таблице;

set  default — в поле внешнего ключа записей дочерней таблицы  заносится  значение  этого поля  по умолчанию,
указанное при определении поля (параметр default);

set null — в поле внешнего ключа записей дочерней таблицы заносится значение null.

Установим связь между таблицами Студенты, Учебный_план и Сводная_ведомость:

ALTER TABLE Сводная_ведомость ADD FOREIGN KEY (ID_План)

REFERENCES Учебный_план

ALTER TABLE Сводная_ведомость ADD FOREIGN KEY (ID_Студент) REFERENCES Студенты

Рис. 4.3. Связь внешнего и первичного ключей

Хотя в рассмотренном примере имена столбцов первичного и внешнего ключей в обеих таблицах совпадают, это не является обязательным. Первичный ключ может быть определен для столбца с одним именем, в то время как столбец, на который наложено ограничение foreign key, может иметь совершенно другое имя. Однако лучше давать таким столбцам идентичные названия, чтобы показать связь между ними (рис. 4.3).

Определение уникального столбца

Ограничение целостности unique предназначено для того, чтобы обеспечить уникальность значений в столбце (или нескольких столбцах). Если столбцу приписан атрибут unique, это означает, что в столбце не могут содержаться два одинаковых значения.

Для ограничения целостности primary key автоматически гарантируется уникальность значений. Однако в каждой таблице можно определить всего один первичный ключ. Если же необходимо дополнительно обеспечить уникальность значений еще в одном или более столбцов помимо первичного ключа, нужно использовать ограничение целостности unique.

Ограничение целостности unique, в отличие от primary key, допускает существование значения null. При этом к значению null также предъявляется требование уникальности, поэтому в столбце с ограничением целостности unique допускается существование лишь единственного значения null.

Таким образом, ограничение unique используется в том случае, когда столбец не входит в состав первичного ключа, но тем не менее его значение должно всегда быть уникальным. Например, для таблицы Дисциплины первичный ключ строится по номеру дисциплины ID_Дисциплина, введенному для сокращения объема первичного ключа и времени поиска по нему (объем ключа по столбцу типа integer много меньше объема ключа по символьному полю). Однако и название дисциплины (столбец Наименование) должно быть уникальным, для чего ему приписан атрибут unique:

CREATE TABLE Дисциплины

(ID_Дисциплина  INTEGER NOT NULL PRIMARY KEY, Наименование  VARCHAR(20) NOT NULL UNIQUE)

Уникальность может быть определена и на уровне таблицы:

CREATE TABLE Дисциплины

(ID_Дисциплина   INTEGER NOT NULL, Наименование  VARCHAR(20) NOT NULL, PRIMARY KEY   (ID_Дисциплина) , UNIQUE (Наименование))

Определение проверочных ограничений

Ограничение целостности check задает диапазон возможных значений для столбца. Например, если в столбце хранится процентное значение, необходимо гарантировать, что оно будет лежать в пределах от 0 до 100. Для этого можно использовать тип данных, допускающий хранение целых значений в диапазоне от 0 до 255, совместно с ограничением целостности CHECK, которое будет обеспечивать соответствующую проверку значений.

Преимуществом ограничения целостности CHECK является возможность определения для одного столбца множества правил контроля значений.

В основе ограничения целостности check лежит проверка логического выражения, которое возвращает значение true (ИСТИНА) либо значение false (ЛОЖЬ). ЕСЛИ возвращается значение true, то ограничение целостности выполняется и операция изменения или вставки данных разрешается. Когда же возвращается значение false, то операция изменения или вставки данных отменяется.

Например, для обеспечения правильности задания значения для столбца Семестр в таблице Учебный_план (оно должно находиться в диапазоне от 1 до 10) можно использовать следующее логическое выражение:

((Семестр  >=   1)   OR   (Семестр  <=   10))

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

Семестр INTEGER NOT NULL CHECK ((Семестр >= 1) OR (Семестр <= 10))

или на уровне таблицы:

CHECK ((Семестр >= 1) OR (Семестр <= 10))

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

Определение значения по умолчанию

При вводе записи (строки) в таблицу каждый столбец должен содержать какое-либо значение. Если значение для столбца не указано, то столбец заполняется значениями null (конечно, если для него разрешено хранение значений null). Однако это нежелательно. Наилучшим решением в подобных ситуациях может быть определение для столбца значений по умолчанию. Например, часто «ноль» определяется как значение по умолчанию для числовых столбцов, а «п/а» (не определено) — как значение по умолчанию для символьных столбцов. Таким образом, определение для столбца значения по умолчанию гарантирует автоматическую подстановку этого значения, если при вставке новых строк значение для столбца не указано.

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

4.3. Создание и модификация таблиц

Создание таблицы (CREATE  TABLE)

Создание таблицы выполняется с помощью команды create table. Обобщенный синтаксис команды следующий:

CREATE   TABLE   имя_таблицы

({<определение_столбца>|<определение_ограничения_таблицы>}

[,...,{<определение  столбца>| <определение_ограничения_таблицы  >}])

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

<имя_таблицы>  —  идентификатор создаваемой таблицы, который в общем случае строится из имени базы данных,
имени владельца таблицы и имени самой таблицы.  При этом комбинация имени таблицы и ее владельца должна быть уникальной в пределах базы данных. Если таблица создается не в текущей базе данных, в ее идентификатор необходимо включить имя базы данных.

<определение_столбца> — задание имени, типа данных и параметров отдельного столбца таблицы. Названия столбцов должны соответствовать правилам для идентификаторов и быть уникальными в пределах таблицы.

<определение  ограничения  таблицы>  —  задание  некоторого ограничения целостности на уровне таблицы.

Описание столбцов. Как видно из синтаксиса команды create table, для каждого столбца указывается предложение <определение_столбца>, с помощью которого и задаются свойства столбца. Предложение имеет следующий синтаксис:

<Имя столбца> <тип_данных>

[<ограничение столбца> ] [,...,<ограничение столбца>]

Рассмотрим назначение и использование параметров:

<имя_столбца> — идентификатор, задающий имя столбца таблицы;

<тип_данных> — задает тип данных столбца. Если при определении столбца явно не указано ограничение на хранения значений null, тo будут использованы свойства типа данных, т. е. если выбранный тип данных позволяет хранить значения null, то и в столбце можно будет хранить значения null. Если же при определении столбца в команде create   table явно будет разрешено или запрещено хранение значений null, to свойства типа данных будут
перекрыты установленным на уровне столбца ограничением. Например, если тип данных позволяет хранить значения null, а на уровне столбца будет установлен запрет, то попытка  вставки  значения   null   в  столбец  закончится ошибкой;

  • <ограничение_столбца> — с помощью этого предложения указываются ограничения, которые будут определены для столбца. Синтаксис предложения следующий:

  • <ограничение  столбца>::=[   CONSTRAINT  <имя  ограничения  >   ] {[   DEFAULT   <выражение>] | [ NULL |   NOT  NULL   ] I     [   PRIMARY   KEY   |    UNIQUE   ] I     [FOREIGN   KEY

REFERENCES   <имя_главной_таблицы>[(<имя_столбца> [,•..,n])]

[ ON DELETE { CASCADE | NO ACTION } ] [ ON UPDATE { CASCADE | NO ACTION } ] ]

|    [CHECK   (<логическое_выражение>)] }

Рассмотрим назначение параметров:

constraint — необязательное ключевое слово, после которого  указывается   название   ограничения   на  значения
столбца (<имя_ограничения>). Имена ограничений должны быть уникальны в пределах базы данных;

default — задает значение по умолчанию для столбца.Это значение будет использовано при вставке строки, если
для столбца явно не указано никакое значение;

null | not  null — ключевые слова, разрешающие (null) или запрещающие (not  null) хранение в столбце значений null. Если для столбца не задано значение по умолчанию, то при вставке строки с неизвестным значением для
столбца будет предприниматься попытка вставки в столбец значения null. Если при этом для столбца указано ограничение NOT null, то попытка вставки строки будет отклонена и пользователь получит соответствующее сообщение об ошибке;

primary key — определение первичного ключа на уровне одного столбца (т. е. первичный ключ будет состоять только из значений одного столбца). Если необходимо сформировать первичный ключ на базе двух и более столбцов, то такое  ограничение  целостности должно быть задано  на уровне таблицы. При этом следует помнить, что для каждой таблицы может быть создан только один первичный ключ;

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

foreign   key    . . .    references  — указание  на то,  что столбец будет служить внешним ключом для таблицы, имя
которой задается с помощью параметра   <имя_главной  таблицы>;

(<имя_столбца>   [, . . . ,п] ) — столбец или список перечисленных через запятую столбцов главной таблицы, входящих в ограничение foreign   key. При этом столбцы, входящие во внешний ключ, могут ссылаться только на
столбцы первичного ключа или столбцы с ограничением unique таблицы;

ON DELETE {CASCADE | NO ACTION} — эти ключевые слова определяют действия, предпринимаемые при удалении строки из главной таблицы. Если указано ключевое слово cascade, то при удалении строки из главной (родительской) таблицы строка в зависимой таблице также будет удалена. При указании ключевого слова no action в подобном случае будет выдана ошибка. Значением по умолчанию является вариант no action;

ON UPDATE {CASCADE | NO ACTION} — Эти ключевые слова определяют действия, предпринимаемые при модификации строки главной таблицы. Если указано ключевое слово cascade, то при модификации строки из главной (родительской) таблицы строка в зависимой таблице также будет модифицирована. При использовании ключевого слова N0 action в подобном случае будет выдана ошибка. Значением по умолчанию является вариант no action;

check — ограничение целостности, инициирующее контроль вводимых в столбец (или столбцы) значений;

<логическое_выражение> — логическое выражение, используемое для ограничения check.

Ограничения на уровне таблицы. Синтаксис команды create Table предусматривает использование предложения <ограничение таблицы>, с помощью которого определяются ограничения целостности на уровне таблицы.

Синтаксис предложения следующий:

<ограничение_таблицы> := [ CONSTRAINT <имя_ограничения>] { [ { PRIMARY KEY | UNIQUE } { (<имя_колонки> [ASC I DESC] [,..., n] )}] | FOREIGN KEY

[ ( <имя колонки>[,..., n ] ) ] REFERENCES <внешняя_таблица> [(<имя_колонки_внешней_таблицы> [, ..., n ] ) ] [ ON DELETE { CASCADE | NO ACTION } ] [ ON UPDATE { CASCADE | NO ACTION } ] | CHECK (логическое выражение> ) }

Назначение параметров совпадает с назначением аналогичных параметров предложения <ограничение_столбца>. Тем не менее в предложении <ограничение_таблицы> имеются некоторые новые параметры:

<имя_колонки> — столбец (или список столбцов), на которые необходимо наложить какие-либо ограничения целостности;

[ASC   |   DESC]  — метод упорядочения данных в индексе. Индекс создается при указании ключевых слов primary
key, unique. При указании значения ASC данные в индексе будут упорядочены по возрастанию, при указании значения DESC — по убыванию. По умолчанию используется значение ASC.

Примеры создания таблиц. В качестве примера рассмотрим инструкции создания таблиц базы данных Сессия: Таблица Студенты состоит из следующих столбцов:

ID_студент — тип данных integer, уникальный ключ;

Фамилия — тип данных char, длина 30;

Имя — тип данных char, длина 15;

Отчество — тип данных CHAR, длина 20;

Номер_группы — тип данных char, длина 6;

Адрес — тип данных char, длина 30;

Телефон — тип данных char, длина 8.

Создание таблицы выполнялось с помощью следующей команды:

CREATE TABLE Студенты

(ID_Студент         INTEGER NOT NULL,

Фамилия              CHAR(30) NOT NULL,

Имя        CHAR(15) NOT NULL,

Отчество              CHAR(20) NOT NULL,

Номер_группы  INTEGER NOT NULL,

Адрес      .             CHAR(30),

Телефон               CHAR(8),

PRIMARY KEY   (ID_Студент) )

На все столбцы таблицы, кроме столбцов Адрес и Телефон, наложены ограничения not null, запрещающие ввод строки при неопределенном значении столбца.

Для создания таблицы Дисциплины была использована команда:

CREATE TABLE Дисциплины
(ID_Дисциплина     INTEGER NOT NULL, Наименование      VARCHAR(40) NOT NULL, PRIMARY KEY(ID_Дисциплина) ,UNIQUE (Наименование))

Таблица содержит два столбца (ID_Дисциплина, Наименование).

На столбцы ID_Дисциплина, Наименование наложены ограничения not null, запрещающие ввод строки при неопределенном значении столбца.

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

Таблица Учебный_план включает в себя следующие столбцы:

ID_план  — тип данных   integer,  столбец уникального ключа;

ID_Дисциплина — тип данных integer;

Семестр — тип данных integer;

Количество_часов — тип данных INTEGER;

ID_Преподаватель — тип данных INTEGER.

Создание таблицы выполнялось с помощью следующей команды:

CREATE TABLE Учебный_план

(ID_План              INTEGER NOT NULL,

ID_Дисциплина  INTEGER NOT NULL,

Семестр                INTEGER NOT NULL,

Количество_часов            INTEGER,

ID_Преподаватель             INTEGER,

PRIMARY KEY   (ID_План),

CHECK  ((Семестр   >=   1)   OR   (Семестр   <=   10)))

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

Таблица Сводная_ведомость состоит из следующих столбцов:

ID_Студент — тип данных integer, столбец уникального ключа;

ID_План  — тип данных  integer,  столбец уникального ключа;

Оценка — тип данных INTEGER;

Дата_сдачи — тип данных DATETIME;

ID_Преподаватель — ТИП данных INTEGER.

Создание таблицы выполнялось с помощью следующей команды:

CREATE TABLE Сводная_ведомость

(ID_Студент         INTEGER NOT NULL,

ID_План               INTEGER NOT NULL,

Оценка  INTEGER NOT NULL,

Дата_сдачи          DATETIME NOT NULL,

PRIMARY KEY   (ID_Студент, ID_Дисциплина),

CHECK  ((Оценка >= 0) OR (Оценка <= 5)))

На все столбцы таблицы наложены ограничения not null, запрещающие ввод строки при неопределенном значении столбца.

Для значений столбца Оценка сформулировано логическое выражение, разрешающее вводить только значения от 0 до 5: 0 — незачет, 1 — зачет, 2 — неудовлетворительно, 3 — удовлетворительно, 4 — хорошо, 5 — отлично.

И наконец, перечислим столбцы таблицы Кадровый_состав:

ID_Преподаватель  — тип данных  INTEGER, уникальный ключ;

Фамилия — тип данных char, длина 30;

Имя — тип данных char, длина 15;

Отчество — тип данных char, длина 20;

Должность — тип данных char, длина 20;

Кафедра — тип данных CHAR, длина 3;

Адрес — тип данных char, длина 30;

Телефон — тип данных CHAR, длина 8.

Создание таблицы выполнялось с помощью следующей команды:

CREATE TABLE Кадровый_состав

(ID_ Преподаватель INTEGER NOT NULL, :

Фамилия              CHAR(30) NOT NULL,

Имя        CHAR(15) NOT NULL,

Отчество              CHAR(20) NOT NULL,

Должность           CHAR(20) NOT NULL,

Кафедра               CHAR(3) NOT NULL,

Адрес    CHAR(30),

Телефон               CHAR(8),

PRIMARY KEY        (ID_Преподаватель))

На все столбцы таблицы, кроме столбцов Адрес и Телефон, наложены ограничения not null, запрещающие ввод строки при неопределенном значении столбца.

Для таблиц Учебный_план и Сводная ведомость должны быть построены внешние ключи, связывающие таблицы базы данных Сессия:

FК_Дисциплина — внешний ключ, связывающий таблицы Учебный_план и Дисциплины по столбцу ID_Дисциплина;

FK Kадровый_состав  —  внешний ключ, связывающий таблицы Учебный_план и Кадровый состав по столбцу
ID_Преподаватель;

FK_Cтудент   —   внешний   ключ,   связывающий   таблицы Сводная_ведомость и Студенты ПО столбцу ID_Студент;

fk_План — внешний ключ, связывающий таблицы Сводная_ведомость и Учебный_план ПО столбцу ID_План.

Добавление внешних ключей в таблицы будет описано при рассмотрении возможностей команды alter table.

Изменение структуры таблицы (ALTER   TABLE)

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

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

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

удалить столбец из таблицы;

изменить значение по умолчанию для какого-либо столбца;

добавить или удалить первичный ключ таблицы;

добавить или удалить внешний ключ таблицы;

добавить или удалить условие уникальности;

добавить или удалить условие на значение.
 

Рассмотрим обобщенный синтаксис команды alter table:

ALTER TABLE <имя_таблицы>

[ALTER COLUMN <имя_столбца> [SET DEFAULT <выражение>]|

[DROP DEFAULT]]

|[ADD <определение_столбца>]

|DROP COLUMN <имя_столбца> [CASCADE]|[RESTRICT]]

|[ADD [<определение первичного ключа>] |

[<определение_внешнего ключа>] |

[<условие_уникальности>] |

[<условие_на_значение>]]|[DROP CONSTRAINT <имя_ограничения> [CASCADE]|[RESTRICT]]

Команда alter table берет на себя все действия по копированию данных во временную таблицу, удалению старой таблицы, созданию вместо нее новой таблицы с нужной структурой и последующим переписыванием в нее данных.

Назначение многих параметров и ключевых слов команды alter table аналогично назначению соответствующих параметров и ключевых слов команды create table (например, синтаксис конструкции <определение_столбца> совпадает с синтаксисом аналогичной конструкции команды create table).

Основные режимы использования команды alter table следующие:

добавление столбца;

удаление столбца;

модификация столбца;

изменение, добавление и удаление ограничений (первичных и внешних ключей, значений по умолчанию).

Добавление столбца. Для добавления нового столбца следует использовать ключевое слово a