|
Иерархические структуры в реляционных базах данных
Содержание
ВВЕДЕНИЕ 2
ГЛАВА 1 5
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ (СУБД) 5
1.1 Основные положения 5
1.2. Иерархическая и сетевая даталогические модели СУБД 10
ГЛАВА 2 12
СЕТЕВЫЕ СТРУКТУРЫ 12
2.1. Файловая модель 13
ГЛАВА 3 17
РЕЛЯЦИОННЫЕ СТРУКТУРЫ 17
3.1. Реляционные даталогические модели СУБД 19
3.2. Объектно-ориентированные СУБД (ООСУБД) 25
ГЛАВА 4 27
ИЕРАРХИЧЕСКИЕ СТPУКТУPЫ 27
4.1. Иерархические структуры в реляционных базах данных 28
4.2. Вложенные рекурсивные иерархические данные 29
4.3. Отображение данных 29
ГЛАВА 5 32
OLE: ОСНОВНЫЕ СВЕДЕНИЯ 32
5.1. Введение в OLE 32
5.2. Связывания и внедрение объектов 33
5.3. Различие между связыванием и внедрением объектов 35
ГЛАВА 6 37
ДОСТОИНСТВА И НЕДОСТАТКИ ТЕСТОВОЙ СИСТЕМЫ ИЛИ МЕТОДИЧЕСКОЕ
ОБОСНОВАНИЕ АВТОМАТИЗАЦИИ ПРОЦЕССА ОБУЧЕНИЯ 37
5.1. Межпредметные связи и компьютерное обучение 39
ГЛАВА 7 41
РАЗРАБОТКА ТЕСТИРУЮЩЕЙ ПРОГРАММЫ 41
ЗАКЛЮЧЕНИЕ 44
СПИСОК ЛИТЕРАТУРЫ 45
Введение
Основные идеи современной информационной технологии базируются
на концепции баз данных (БД). Согласно данной концепции основой инфор-
мационной технологии являются данные, организованные в БД, адекватно
отражающие реалии действительности в той или иной предметной области и
обеспечивающие пользователя актуальной информацией в соответствующей
предметной области.
В первых трёх главах рассматриваются новые системы управления ба-
зами данных, такие как иерархическая и сетевая даталогические модели, ре-
ляционные даталогические модели, объектно-ориентированные СУБД.
Обычно различают три класса СУБД, обеспечивающих работу иерархиче-
ских, сетевых и реляционных моделей. Однако различия между этими клас-
сами постепенно стираются, причем, видимо, будут появляться другие клас-
сы, что вызывается прежде всего интенсивными работами в области баз зна-
ний (БЗ) и объектно-ориентированной инфотехнологией. Поэтому традици-
онной классификацией пользуются все реже, но мы пока будем придержи-
ваться именно ее, как наиболее устоявшуюся. Каждая из указанных моделей
обладает характеристиками, делающими ее наиболее удобной для конкрет-
ных приложений.
Глава 4 «Иерархические структуры» подробнее описывает положи-
тельные и отрицательные черты иерархической модели. Окружающий мир
переполнен иерархическими данными. Любая группа объектов, в которой
один объект может быть «родителем» для произвольного числа других объ-
ектов, организована в виде иерархического дерева. При работе с иерархиями
используется «семейная» терминология (родители, внуки, предки, потомки),
поскольку семья является самым распространённым примером объектов (в
данном случае – людей), объединённых иерархическими отношениями. В то
же время место объекта в иерархическом дереве - не более чем условное обо-
значение связи с другими объектами. Иерархическая структура всего лишь
помогает сохранить и найти объект.
В пятой главе обзор технологии OLE. С появлением новых более мощ-
ных, компьютеров и средств программирования было создано новое поколе-
ние элементов на базе OLE. Наиболее привлекательным преимуществом OLE
является возможность использования методов других серверов приложений.
Намного удобнее использовать функциональность электронных таблиц, та-
ких как Excel, или текстовых процессоров, таких как Word, вместо того что-
бы разрабатывать аналогичную функциональность в собственном приложе-
нии.
Изначально технология OLE являлась стандартом, обеспечивающим
связывание и встраивание объектов. Когда приложение- сервер OLE- акти-
визируется, это происходит внутри контейнера, расположенного в вашем
приложении. Визуально при активизировании сервера OLE текущие панели
инструментов и меню заменяются панелями инструментов и меню сервера
OLE или сливаются с ними. Кроме того, часть формы становится окном сер-
вера OLE, так как сервер принимает на себя управление областью формы.
Связыванием называют ассоциирование файла объекта OLE с контейнером
OLE. Файл объекта никогда не сохраняется в контейнере, но контейнер OLE
ссылается на файл. Одним из преимуществ связывания объектов является то,
что множество пользователей, серверов OLE и приложений-контейнеров мо-
гут получать доступ к одному документу. При встраивании объектов реаль-
ный объект сохраняется в вашем приложении и другие контейнеры OLE не
имеют доступа к этому объекту. Преимуществом встраивания является хра-
нение данных как части приложения.
Шестая глава посвящена достоинствам и недостаткам тестовой систе-
мы. Одной из форм привлечения преподавателей к использованию компью-
тера являются тестирующие программы, которые позволяют преподавателю
упростить проверку знаний учащихся и в то же время в увлекательной форме
преподносят ученикам знания по той или иной дисциплине.
Целью данной дипломной работы является создание программы по
компьютерному контролю знаний студентов.
Передо мной были поставлены следующие задачи:
– дать обзор современному состоянию теории баз данных, основным
моделям СУБД, применяемым в ПК;
– изучить принципы функционирования и основные возможности
технологии OLE;
– разработать способ отображения реляционных структур данных в
иерархическом виде;
– дополнить стандартный компонент Delphi OLEContainer возможно-
стью сохранения битового изображения на его поверхности.
Система автоматизированного контроля знаний, рассмотренная в главе
6, позволяет автоматизировать проведение контрольных работ по дисципли-
нам. Это удобное добавление к традиционным методам контроля, повышаю-
щее эффективность усвоения предмета студентом. Межпредметные связи и
компьютерное обучение рассмотренные в этой главе представляют собой
общеобразовательные цели информатики, среди них: наведение и усиление
межпредметных связей, способствование восприятию целостной, системной
картины мира, информационных процессов в обществе, природе и познании.
Для разумного и плодотворного использования ВТ необходима общеобразо-
вательная и компьютерная грамотность. Отсюда выявляется межпредметная
связь с основами информатики и ВТ, с математикой, русским языком, лите-
ратурой и английским языком. ВТ для учителя выступает и как предмет, и
как средство обучения, и как инструмент психолого-педагогических исследо-
ваний (тестирования).
В седьмой главе изложены проблемы разработки тестирующей про-
граммы и их решение.
Глава 1
Системы управления базами данных (СУБД)
Основные идеи современной информационной технологии базируются
на концепции баз данных (БД). Согласно данной концепции основой инфор-
мационной технологии являются данные, организованные в БД, адекватно
отражающие реалии действительности в той или иной предметной области и
обеспечивающие пользователя актуальной информацией в соответствующей
предметной области. Первые БД появились уже на заре 1-го поколения ЭВМ
представляя собой отдельные файлы данных или их простые coвокупности.
По мере увеличения объемов и структурной сложности хранимой информа-
ции, а также расширения круга потребителей; информации определилась не-
обходимость создания удобных эффективных систем интеграции хранимых
данных и управления ими. В конце 60-х годов это привело к созданию пер-
вых коммерческих систем управления базами данных (СУБД), поддержи-
вающих opганизацию и ведение БД. Перед обсуждением последующего ма-
териала, нам потребуется ряд основных понятий, используемых в информа-
ционных системах различного назначения.
1.1 Основные положения
База данных (БД) в строгом смысле слова представляет собой совокуп-
ность взаимосвязанных файлов данных определенной организации. БД, как
правило, включает целый ряд файлов, но может состоять и из единственного
файла. Данные, составляющие БД, отражают характеристики объектов и их
отношений в соответствующей прикладной области. Каждый файл, входя-
щий в БД, содержит определенное число записей (изменяемое в процессе
функционирования БД), отражающих ту или иную сторону предметной об-
ласти, на которую ориентирована БД. Как правило, файлы БД содержат
большое число однотипных записей. Записи, в свою очередь, состоят из по-
лей, представляющих определенные типы информации об объектах. Поле яв-
ляется наименьшей информационной единицей, непосредственно доступной
в записи. Если файл_1 БД (рис. 1) содержит п однотипных записей (имеющих
одинаковую структуру полей и их смысловую нагрузку),то j-запись (1br>
файла состоит из фиксированного набора (кортежа полей А1—Ак), каждое из
которых содержит в общем случае различного типа информацию. При нали-
чии БД прикладные программы могут использовать ее информацию (записи
и их поля) для решения конкретных задач в прикладной области, на которую
ориентирована данная БД.
1
Поле А1
Поле А2
…
Поле Ак
…
Поле S1
Поле S2
…
Поле Sd
1
2
Поле А1
Поле А2
…
Поле Ак
…
Поле S1
Поле S2
…
Поле Sd
2
...
…
…
…
…
…
…
…
…
…
…
N
Поле А1
Поле А2
…
Поле Ак
…
Поле S1
Поле S2
…
Поле Sd
p
Файл_1
Файл_М
Рис. 1 Файловая организация баз данных (файлы, записи, поля)
Пользователями БД являются четыре основные категории потребите-
лей ее информации и/или поставщиков информации для нее: (1) конечные
пользователи, (2) программисты и системные аналитики, (3) персонал
поддержки БД в актуальном состоянии и (4) администратор БД. Хорошо
спроектированные системы управления БД (СУБД), используют развитые
графические интерфейсы и поддерживают системы отчетов, отвечающие
специфике пользователей указанных четырех категорий. В этом случае
персонал поддержки БД и конечные пользователи могут легко осваивать и
использовать СУБД для обеспечения своих потребностей без какой-либо
специальной подготовки, т.е. специфика функционирования данных систем
скрыта от пользователя. Более того, хорошо спроектированные СУБД пре-
доставляют опытному пользователю средства для создания собственных БД-
приложений, не требуя от него специальной программистской подготовки.
Конечным пользователям для обеспечения доступа к информации БД пре-
доставляется графический интерфейс, как правило, в виде системы окон с
функциональными меню, позволяющими легко получать необходимую ин-
формацию на экран и/или принтер в виде удобно оформленных отчетов.
Программисты и системные аналитики используют СУБД совер-
шенно в ином качестве, обеспечивая разработку новых БД-приложений, под-
держивая и модифицируя (при необходимости) уже существующие. Для дан-
ной группы пользователей СУБД требуются средства, обеспечивающие ука-
занные функции (создание, откладка, редактирование и т.д.). Пользователи
третьей категории нуждаются в интерфейсе, как правило, графическом для
обеспечения задач поддержания БД в актуальном состоянии. Эти пользова-
тели состоят в штатах подразделений функциональных и/или обработки ин-
формации, обеспечивающих прикладную область, и отвечают за актуальное
состояние соответствующей ей БД (контроль текущего состояния, удаление
устаревшей информации, добавление новой и т.д.). Программисты выпол-
няют своего рода посреднические функции между БД и конечными пользо-
вателями. И если на первых этапах развития БД-технологии они составляли
весьма многочисленную группу пользователей, то в процессе развития СУБД
и, прежде всего, массового использования ПК эта категория сходит на нет.
Особую и ответственную роль выполняет администратор, отвечающий как
за актуальность находящейся в БД информации, так и за корректность функ-
ционирования и использования БД и СУБД.
В случае больших БД может быть достаточно много конечных пользо-
вателей, ряд программистов и несколько администраторов БД; в случае не-
больших БД (что особенно характерно для ПК) все эти функции могут обес-
печиваться одним человеком. Важные функции выполняет администратор
БД, отвечающий за выработку требований к БД, ее проектирование, реализа-
цию, эффективное использование и сопровождение. Необходимость в таком
специалисте вытекает из принципа независимости данных, а также диктуется
важностью БД в деятельности организаций и более крупных объединений —
поставщиков и потребителей информации БД. Администратор БД взаимо-
действует с пользователями в определении требований к базе в процессе вы-
работки требований к системе в целом, пользуется языков описания данных
для определения БД в процессе проектирования системы, взаимодействует с
программистами, которые создают ПС использующее доступ к БД, отвечает
за загрузку БД информацией в процессе реализации системы, контролирует
работоспособность БД, используя соответствующие программные и аппа-
ратные средства, и определяет, когда следует реорганизовывать данные в ба-
зе или начать работы по созданию новой, более совершенной БД. В целом
функции администратора БД сводятся к поддержанию целостности БД, не-
обходимого уровня защиты ее данных и эффективности. Среди его наиболее
важных обязанностей — согласование конфликтующих требований, которое
требуется достаточно часто, ибо БД обслуживает, как правило, целый ряд
различных прикладных процессов.
Как уже отмечалось, БД представляет собой совокупность логически
взаимосвязанных файлов данных определенной организации; для определе-
ния и обращения к такой файловой совокупности используют средства сис-
темы управления БД (СУБД). СУБД представляет собой совокупность лин-
гвистических и программных средств, предназначенных для создания, веде-
ния и совместного использования БД многими пользователями. Тогда как
под системой БД понимается СУБД с наполненной соответствующей ин-
формацией БД, управляемой ее средствами. Это означает, во-первых, что со-
вокупность файлов БД определяется посредством схемы, не зависящей от
программ, которые к ней обращаются, и, во-вторых, что она реализована на
основе ВП прямого доступа. Использование СУБД обеспечивает лучшее
управление данными, более совершенную организацию файлов и более про-
стое обращение к ним по сравнению с обычными способами хранения ин-
формации. Вследствие более совершенных механизмов доступа БД, как пра-
вило, имеют более сложную организацию, чем обычные файлы, объединяя
данные, ранее хранящиеся во многих отдельных файлах. Размер и сложность
не являются определяющими характеристиками БД — наличие СУБД для ПК
и даже в среде ряда пакетов (например, табличных процессоров, интегриро-
ванных и др.) приводит к созданию большого числа относительно простых и
небольших БД, достоинством которых (при наличии соответствующих
СУБД) являются простота определения и доступа к данным. Под банком
данных (БнД) понимается система лингвистических, программных, аппа-
ратных и организационных средств, основанная на БД-технологии и предна-
значенная для централизованного накопления и коллективного использова-
ния данных в той или иной прикладной области. Тогда как система обра-
ботки информации (СОИ) реализует автоматизированный сбор, обработку и
хранение информации, включая соответствующие лингвистические, про-
граммные, аппаратные, организационные средства и обслуживающий их пер-
сонал.
Под целостностью БД понимается актуальное состояние ее данных,
отражающих состояние некоторой реальной прикладной области и подчи-
няющихся правилам непротиворечивости. Под языком БД понимается один
или совокупность языков, обеспечивающих описание данных, манипулиро-
вание с данными. Конкретный язык БД всегда ассоциируется с конкретной
СУБД. СУБД представляет собой средства обработки на языке базы данных,
позволяющие обрабатывать обращения к БД, поступающие от прикладных
программ и/или конечных пользователей, и поддерживать целостность БД.
Таким образом, СУБД имеет свойства, характерные как для компиляторов,
так и для ОС, однако по сравнению с первыми обеспечивается более высокий
уровень абстрагирования, что оказывается очень полезным как для програм-
мистов, так и для конечных пользователей.
1.2. Иерархическая и сетевая даталогические модели СУБД
Каждая БнД содержит и обрабатывает информацию из конкретной приклад-
ной области, представляющей интерес для определенных приложений. Опи-
сание предметной области без акцента на ее последующие БнД-реализации
определяет инфологическую модель предметной области (рис. 2). Инфологи-
ческая модель является исходной для построения даталогической модели БД
и служит промежуточной моделью для специалистов предметной области
(для которой создается БнД) и администратора БД в процессе проектирова-
ния и разработки конкретной БнД.
Рис. 2. Принципиальная организация СОИ на основе БД-технологии
Под даталогической понимается модель, отражающая логические
взаимосвязи между элементами данных безотносительно их содержания и
физической организации. При этом даталогическая модель разрабатывается
с учетом конкретной реализации СУБД, также с учетом специфики конкрет-
ной предметной области на основе ее инфологической модели. Для конкрет-
ной реализации даталогической модели проектируется физическая модель
(рис. 2), oтображающая первую на конкретные программные и аппаратные
средства (ОС, внешняя память, работа с данными на физическом уровне и
т.д.). Наполненная конкретной информацией физическая модель и составляет
собственно БД. Система, обеспечивающая cоответствующее совместное
функционирование указанных компонентов и составляет суть конкретной
СУБД.
Современные СУБД допускают целый ряд классификаций в зависимо-
сти от уровня их рассмотрения (в целом либо по совокупности их функцио-
нальных характеристик): по интерфейсу с пользователем в зависимости от
поддерживаемых моделей, по назначению и режиму функционирования, по
способу обработки информации и т.д. Мы кратко остановимся на моделях
даталогического уровня, который берется за основу большинства современ-
ных классификаций СУБД.
Обычно различают три класса СУБД, обеспечивающих работу иерар-
хических, сетевых и реляционных моделей. Однако различия между этими
классами постепенно стираются, причем, видимо, будут появляться другие
классы, что вызывается прежде всего интенсивными работами в области баз
знаний (БЗ) и объектно-ориентированной инфотехнологией, о которой будет
идти речь ниже. Поэтому традиционной классификацией пользуются все ре-
же, но мы пока будем придерживаться именно ее, как наиболее устоявшуюся.
Каждая из указанных моделей обладает характеристиками, делающими ее
наиболее удобной для конкретных приложений. Одно из основных различий
этих моделей состоит в том, что для иерархических и сетевых СУБД их
структура часто не может быть изменена после ввода данных, тогда как для
реляционных СУБД структура может изменяться в любое время. С другой
стороны, для больших БД, структура которых остается длительное время не-
изменной, и постоянно работающих с ними приложений с интенсивными по-
токами запросов на БД-обслуживание именно иерархические и сетевые
СУБД могут оказаться наиболее эффективными решениями, ибо они могут
обеспечивать более быстрый доступ к информации БД, чем реляционные
СУБД.
Глава 2
Сетевые структуры
Если в отношении между данными порожденный элемент имеет более
одного исходного элемента, то это отношение уже нельзя описать как древо-
видную или иерархическую структуру. Его описывают в виде сетевой струк-
туры. Любая сетевая структура может быть приведена к более простому виду
введением избыточности. «БД постоянно грозит опасность стать громоздки-
ми, застывшими и слишком сложными системами. Новые приложения поро-
ждают новые виды запросов пользователей к базе, что увеличивает набор ло-
гических связей между ее элементами. В итоге многие системы БД оказыва-
ются очень сложными в построении и эксплуатации. Если разработчики не
придумают ясные и простые схемы организации, эти системы будут подобны
паутине» [К.Дейт.].
Сетевая модель более симметрична, чем иерархическая модель. Однако
процедуры (обновления) значительно сложнее проблема состоит в следую-
щем: всегда имеются две стратегии для определения места одного экземпля-
ра записи, первая начинается с "владельца" и просмотра его цепочки для вы-
бора звена, а другая начинается с "подчиненного звена" и просмотра его це-
почки для выбора "владельца". Как пользователь может решить, какую стра-
тегию принять? Выбор и здесь имеет большое значение. Как в иерархиче-
ских, так и сетевых СУБД при описании данных обычно указываются харак-
теристики записей каждого типа, способствующие более эффективному раз-
мещению данных во внешней памяти и более быстрому доступу к ним. К та-
ким характеристикам относятся: размеры полей записи (минимальные, сред-
ние, максимальные), состав ключа, допустимый набор символов, интервалы
значений и т.д.
Иерархические и сетевые базы данных часто называют базами данных
с навигацией. Это название отражает технологию доступа к данным, исполь-
зуемую при написании обрабатывающих программ на языке манипулирова-
ния данными. При этом, очевидно, что доступ к данным по путям, не преду-
смотренным при создании базы данных, может потребовать неразумно
большого времени. Повышая эффективность доступа к данным и сокращая
таким образом время ответа на запрос, принцип навигации вместе с этим по-
вышает и степень зависимости программ и данных. Обрабатывающие про-
граммы оказываются жестко привязанными к текущему состоянию структу-
ры базы данных и должны быть переписаны при ее изменениях. Операции
модификации и удаления данных требует переустановки указателей, а мани-
пулирование данными остается записеориентированным. Кроме того, прин-
цип навигации не позволяет существенно повышать уровень языка манипу-
лирования данными, чтобы сделать его доступным пользователю-
непрограммисту, или даже программисту-непрофессионалу. Для поиска за-
писи-цели в иерархической или сетевой структуре программист должен вна-
чале опеределить путь доступа, а затем просмотреть все записи, лежащие на
этом пути, - шаг за шагом.
Насколько запутанной являются схемы представления иерархических и
сетевых баз данных, настолько и трудоемким является проектирование кон-
кретных прикладных систем на их основе. Как показывает, опыт длительные
сроки разработки прикладных систем нередко приводят к тому, что они по-
стоянно находятся в стадии разработки и доработки.
Указанные и некоторые другие проблемы, с которыми столкнулись
разработчики и пользователи иерархических и сетевых систем послужили
стимулом к созданию реляционной модели данных и реляционных СУБД.
2.1. Файловая модель
Кратко рассмотрим файловую модель, неправомерно относимую до-
вольно часто к СУБД. Файловая модель представляет собой набор файлов
данных определенной структуры, но связь между данными этих файлов от-
сутствует. Естественно, программные средства работы с таким образом орга-
низованной инфобазой могут устанавливать связь между данными ее фай-
лов, но на концептуальном уровне файлы модели являются независимыми.
Системы, обеспечивающие работу с файловыми инфобазами, называют сис-
темами управления файлами (СУФ) и они оказываются весьма эффективны-
ми во многих приложениях. СУФ используются на всех классах ЭВМ, но
особенно они распространены для обработки информации на ПК. При этом
во многих источниках они фигурируют в качестве СУБД. Файловые системы
легко осваиваются, достаточно просты и эффективны в использовании и, как
правило, для работы с ними используются простые языки запросов либо и
вовсе ограничиваются набором программ-утилит. Такие системы обычно
поддерживают работу с небольшим числом файлов, содержащих ограничен-
ное число записей с небольшим количеством полей.
Иерархические модели СУБД имеют древовидную структуру, когда
каждому узлу структуры соответствует один сегмент, представляющий со-
бой поименованный линейный кортеж полей данных. Каждому сегменту
(кроме S1-корневого) соответствует один входной и несколько выходных сег-
ментов (рис. 3а). Каждый сегмент структуры лежит на единственном иерар-
хическом пути, начинающемся от корневого сегмента.
Рис. а)
Рис. б)
Рис. 3. Структура иерархической (а) и сетевой (б) СУБД
Для описания такой логической организации данных ЯОД достаточно
предусматривать для каждого сегмента данных только идентификацию вход-
ного для него сегмента. Так как в иерархической модели каждому входному
сегменту данных соответствует N выходных, то такие модели весьма удобны
для представления отношений типа 1:N в предметной области. Следует от-
метить, что в настоящее время не разрабатываются СУБД, поддерживающие
на концептуальном уровне только иерархические модели. Как правило, ис-
пользующие иерархический подход системы допускают связывание древо-
видных структур между собой и/или установление связей внутри них. Это
приводит к сетевым даталогическим моделям СУБД. К основным недостат-
кам иерархических моделей следует отнести: неэффективность реализации
отношений типа N:N, медленный доступ к сегментам данных нижних уров-
ней иерархии, четкая ориентация на определенные типы запросов и др. В
связи с этими недостатками ранее созданные иерархические СУБД подвер-
гаются существенным модификациям, позволяющим поддерживать более
сложные типы структур и, в первую очередь, сетевые и их модификации.
Сетевая даталогическая модель СУБД во многом подобна иерархической:
если в иерархической модели (рис. 3а) для каждого сегмента записи допуска-
ется только один входной сегмент при N выходных, то в сетевой модели для
сегментов допускается несколько входных сегментов наряду с возможностью
наличия сегментов без входов с точки зрения иерархической структуры. На
рис. 3б представлен простой пример сетевой структуры, полученной на ос-
нове модификации иерархической структуры (рис. 3а). Графическое изобра-
жение структуры связей сегментов такого типа моделей представляет собой
сеть. Сегменты данных в сетевых БД могут иметь множественные связи с
сегментами старшего уровня. При этом направление и характер связи в сете-
вых БД не являются столь очевидными, как в случае иерархических БД. По-
этому имена и направление связей должны идентифицироваться при описа-
нии БД средствами ЯОД.
Таким образом, под сетевой СУБД понимается система, поддержи-
вающая сетевую организацию: любая запись, называемая записью старшего
уровня, может содержать данные, которые относятся к набору других запи-
сей, называемых записями подчиненного уровня. Возможно обращение ко
всем записям в наборе, начиная с записи старшего уровня. Обращение к на-
бору записей реализуется по указателям. В рамках сетевых СУБД легко реа-
лизуются и иерархические даталогические модели. Сетевые СУБД поддер-
живают сложные соотношения между типами данных, что делает их пригод-
ными во многих различных приложениях. Однако пользователи таких СУБД
ограничены связями, определенными для них разработчиками БД-
приложений. Более того, подобно иерархическим сетевые СУБД предпола-
гают разработку БД приложений опытными программистами и системными
аналитиками.
Среди недостатков сетевых СУБД следует особо выделить проблему
обеспечения сохранности информации в БД, решению которой уделяется по-
вышенное внимание при проектировании сетевых БД.
Глава 3
Реляционные структуры
Реляционный подход стал широко известен благодаря первым работам
Е.Кодда, которые появились около 1970г. В течение долгого времени реля-
ционный подход рассматривался как удобный формальный аппарат анализа
баз данных, не имеющий практических перспектив, так как его реализация
требовала слишком больших машинных ресурсов. Только с появлением пер-
сональных ЭВМ реляционные и близкие к ним системы неожиданно стали
распространяться, практически не оставив места другим моделям. Один из
самых естественных способов представления данных для пользователей - это
двумерная таблица. Она привычна для пользователя, понятна и обозрима, ее
легко запомнить. Поскольку любая сетевая структура может быть разложена
в совокупность древовидных структур, то и любое представление данных
может быть сведено к двумерным плоским файлам. Связи между данными
могут быть представлены в форме двумерных таблиц.
Таблица обладает следующими свойствами:
Каждый элемент таблицы представляет собой один элемент данных.
Повторяющиеся группы отсутствуют.
Все столбцы в таблице однородные. Это означает, что элементы столб-
ца имеют одинаковую природу.
Столбцам присвоены уникальные имена.
В таблице нет двух одинаковых строк.
Порядок расположения строк и столбцов в таблице безразличен. Таб-
лица такого рода называется отношением. База данных, построенная с помо-
щью отношений, называется реляционной базой данных.
Чем же принципиально отличаются реляционные модели от сетевых и
иерархических? Вкратце на это можно ответить следующим образом: иерар-
хические и сетевые модели данных - имеют связь по структуре, а реляцион-
ные - имеют связь по значению. Проектирование баз данных традиционно
считалось очень трудной задачей. Реляционная технология значительно уп-
рощает эту задачу в трех различных направлениях:
Разделением логического и физического уровней системы она упроща-
ет процесс отображения "уровня реального мира", в структуру, которую сис-
тема может прямо поддерживать. Поскольку реляционная структура сама по
себе концептуально проста, она позволяет реализовывать небольшие и/или
простые (и поэтому легкие для создания) базы данных, такие как персональ-
ные, сама возможность реализации которых никогда даже бы не рассматри-
валась в старых более сложных системах.
Теория и дисциплина нормализации может помочь, показывая, что
случается, если отношения не структурированы естественным образом.
Реляционная модель данных особенно удобна для использования в ба-
зах данных распределенной архитектуры - она позволяет получать доступ к
любым информационным элементам, хранящимся в узлах сети ЭВМ. Необ-
ходимо обратить особое внимание на высокоуровневый аспект реляционного
подхода, который состоит в множественной обработке записей. Благодаря
этому значительно возрастает потенциал реляционного подхода, который не
может быть достигнут при обработке по одной записи, и прежде всего это ка-
сается оптимизации. У системы управления базами данных появляется воз-
можность влиять на эффективность реализации. В настоящее время на рынке
программно-математического обеспечения для ПЭВМ представлено более
сотни различных СУБД. Они сильно различаются по стоимости, по эффек-
тивности работы, по функциональной мощности, по сложности изучения и
использования.
Наиболее широкое распространение получили СУБД, использующие
реляционную модель данных, теоретической основой которой является логи-
ка предикатов первого порядка и теория отношений. Одной из важнейших
характеристик как с точки зрения разработчика информационно-
управляющих систем, так и их пользователей является быстродействие
СУБД, в силу чего практически все фирмы мира-производители СУБД рабо-
тают над проблемой увеличения реактивности. Большинство известных ком-
мерческих СУБД страдают существенным недостатком : при работе с боль-
шими и сверхбольшими базами данных резко снижается время реакции сис-
темы при выполнении процедур поиска информации. Кроме того, появляю-
щиеся в периодической печати результаты тестирования коммерческих
СУБД не всегда позволяют сделать вывод об эффективности того или иного
программного продукта, поскольку почти всегда оцениваемым по времени
результатом поиска является первая найденная запись, а время ответа на
сложные многоключевые запросы не оценивается, в то время как время по-
иска всех записей, удовлетворяющих некоторому критерию, линейно зависит
от числа записей в базе, от числа записей-целей, от размеров записи, и, сле-
довательно, для больших баз измеряется значительным интервалом времени.
Таким образом проведенный анализ систем управления базами данных,
ориентированных на различные модели данных, позволяет сделать вывод: в
распределенной интегрированной информационной системе возможно ис-
пользование СУБД реляционного типа.
3.1. Реляционные даталогические модели СУБД
СУБД реляционного типа являются наиболее распространенным на
всех классах ЭВМ, а на ПК занимают доминирующее положение. Данная мо-
дель позволяет определять: (1) операции по запоминанию и поиску данных;
(2) ограничения, связанные с обеспечением целостности данных. Для увели-
чения эффективности работы во многих СУБД реляционного типа приняты
ограничения, соответствующие строгой реляционной модели.
Многие реляционные СУБД представляют файлы БД для пользователя
в табличном формате — с записями в качестве строк и их полями в качестве
столбцов. В табличном виде информация воспринимается значительно легче.
Однако в БД на физическом уровне данные хранятся, как правило, в файлах,
содержащих последовательности записей. Основным преимуществом реля-
ционных СУБД является возможность связывания на основе определенных
соотношений файлов БД. Со структурной точки зрения реляционные модели
являются более простыми и однородными, чем иерархические и сетевые. В
реляционной модели каждому объекту предметной области соответствует од-
но или более отношений. При необходимости определить связь между объек-
тами явно, она выражается в виде отношения, в котором в качестве атрибутов
присутствуют идентификаторы взаимосвязанных объектов. В реляционной
модели объекты предметной области и связи между ними представляются
одинаковыми информационными конструкциями, существенно упрощая са-
му модель.
СУБД считается реляционной при выполнении следующих двух усло-
вий, предложенных еще Э. Коддом : (1) поддерживает реляционную струк-
туру данных и (2) реализует по крайней мере операции селекции, проекции и
соединения отношений. В последующем был создан целый ряд реляционных
СУБД, в той или иной мере отвечающих данному определению. Многие
СУБД представляют собой существенные расширения реляционной модели,
другие являются смешанными, поддерживая несколько даталогических мо-
делей.
Суть реляционной СУБД можно пояснить на следующем простом
примере (рис. 4).
Файл авторов публикаций БД
№ п/п
Автор
Адрес
Телефон
Число
публ.
…
…
…
…
6
Купцов
Москва
635-6078
140
7
Бухтяк
Томск
637-2050
140
8
Терпугов
Томск
538-584
250
Файл публикаций РБД
№ п/п
Назв.
Публикации
Тип
публ.
Дата
Объём
в п. л.
6
Основы …
Статья
2.95
2.5
7
Проблема …
Книга
3.97
35
8
Теория …
Статья
6.96
3.8
…
…
…
…
Рис. 4 Простой пример, иллюстрирующий принцип реляционной модели
В некоторой реляционной БД (РБД) имеются два файла авторов и пуб-
ликаций, каждый из которых содержит определенное число записей/ состоя-
щих из фиксированного числа полей (соответственно 4 и 5), представляющих
данные по соответствующим элементам предметной области (рис. 4). Можно
сказать, что определены два отношения (фaйла), имеющие общий элемент
— значения поля № п/п. Операции реляцианной алгебры могут объединять
два типа записей по этому общему элементу. Например, в результате соеди-
нения запись Бухтяк может представится в следующем виде:
Бухтяк ....
т.е. к сведениям об авторе добавляются сведения обо всех его публикациях,
имеющихся в РБД. Связь между записями допускается по нескольким полям,
позволяя образовывать достаточно сложные операции. Поля данных, связы-
вающие вместе две записи, могут быть уникальными для данной пары, но
могут дублироваться и во многих других записях. Они могут повторяться не-
однократно, связывая между собой записи. Аналогичным образом можно
проиллюстрировать выполнение в реляционной модели операций проекции и
селекции.
Реляционная СУБД должна четко отслеживать взаимосвязи записей в
БД во избежание потери или искажения информации. С этой целью СУБД
постоянно пересчитывает число связей для каждой записи БД в прямом и об-
ратном направлениях, что требует существенных временных затрат для
больших БД. Простота и стройность реляционной алгебры делают ее весьма
привлекательной для организации реляционных БД, что мы и видим, прежде
всего, для класса ПК. Однако в действительности реальные данные предмет-
ной области не укладываются в указанную модель (например, отношения мо-
гут содержать повторяющиеся записи и т.д.). Поэтому наряду с сугубо реля-
ционными существуют и другие даталогические модели СУБД и их различ-
ные модификации и сочетания, обеспечивая широкий круг решаемых на их
основе информационных, коммерческих, управленческих, финансовых, вы-
числительных и других типов задач. Из наиболее известных примеров реля-
ционных СУБД можно отметить такие, как: dBase, DB/2, ORACLE, Paradox и
ряд других.
Массовое развитие класса ПК оказало весьма существенное влияние на
развитие инфотехнологии и БД-технологии в частности, привнося элементы
последней в массовую инфотехнологию. Прежде всего, этому способствова-
ло развитие мощной индустрии по созданию разнообразных СУБД для ПК.
Если создание СУБД для ЭВМ общего назначения и (в значительной мере)
мини-ЭВМ занимало длительный промежуток времени и число таких ком-
мерческих СУБД было невелико — практически весь их перечень был на
слуху у специалистов по компьютерной инфотехнологии, то с появлением
класса ПК наряду с мощным развитием для них ПС различного назначения
начали быстро появляться СУБД. При этом БД-технология начала активно
проникать и в ПС другого назначения (электронные таблицы, интегрирован-
ные и статистические пакеты и т.д.). К БД-технологии были приобщены ши-
рокие круги пользователей ПК. Во многих разработках для ПК начали при-
меняться собственные СУБД различных организации и назначения. На наш
взгляд, ряд причин способствовал такому массовому использованию БД-
технологии:
— массовое использование ПК в приложениях, предопределяющих работу с
БД;
— резкое уменьшение цикла разработки ПС из-за персонального характера
работы;
— наличие достаточно развитых системных и инструментальных средств;
— наличие внешней памяти большой емкости на "винчестерах".
Эти и другие причины обеспечили как широкий спрос на СУБД для ПК,
так и хорошие предпосылки для его быстрого удовлетворения. Наряду с
мощными фирмами, специализирующимися на разработке коммерческих
СУБД к разработкам и/или адаптации уже готовых СУБД для ПК приступили
и крупные фирмы, ранее ориентированные в этой области на приложения к
ЭВМ других классов (Oracle, IBM, Relational Technology и др.). Все это спо-
собствовало интенсивному проникновению БД-технологии в массовую ин-
фообработку. С другой стороны, широкое использование ПК в весьма об-
ширном спектре прикладных областей способствовало выдвижению к СУБД
целого ряда актуальных требований и, в первую очередь, по повышению
уровня интерфейсов с пользователем и другими приложениями.
Разработанное в настоящее время большое число различного назначе-
ния СУБД позволяет создавать и эксплуатировать системы БД на всех клас-
сах и типах ЭВМ, поддерживая различные даталогические модели и обеспе-
чивая нужды широкого круга приложений
Средства современных СУБД настолько разнообразны, что способны
удовлетворить потребности самого широкого круга пользователей — от
профессионала в области разработки систем БД различных типа и назначения
до пользователя, не обладающего достаточным уровнем компьютерной гра-
мотности. В первую очередь, это относится к СУБД, созданным для класса
ПК. Эти СУБД характеризуются не только своим количеством, но и функ-
циональным разнообразием: от простых файловых систем до функционально
полных СУБД, в основном реляционного типа. Многие из коммерческих
СУБД поддерживают многопользовательскую работу и работу в сетях ЭВМ,
как локальных, так и глобальных. К средствам, непосредственно относя-
щимся к СУБД, можно отнести и многочисленные средства их окружения:
генераторы и конверторы данных и программ, компиляторы языков про-
граммирования БД-приложений, генераторы создания различного назначения
и уровня интерфейсов с БД в рамках традиционных ЯВУ и т.д.
Такое многообразие инструментальных и прикладных средств по
СУБД позволяет выбирать наиболее адекватные нуждам пользователя, обес-
печивая эффективное использование вычислительных ресурсов и существен-
ное сокращение сроков разработки конкретных БД-технологий. В подав-
ляющем большинстве СУБД для ПК ориентированы на интерактивный ре-
жим работы с пользователем, широко используя удобные и дружелюбные
системы интерфейсов на основе простых и понятных меню. В СУБД, под-
держивающих языки программирования БД-приложений, средства такого
интерфейса избавляют пользователя от необходимости знания синтаксиса
языка для обеспечения требуемых функций. Ряд популярных СУБД преду-
сматривают несколько уровней интерфейса, обеспечивающих работу с ними
различной квалификации пользователей (dBase IV, Paradox, др.). Большое
внимание уделено эффективной системе Help-информации по СУБД, вклю-
чающей электронные краткие обучающие курсы с демонстрацией наиболее
часто используемых приемов работы с конкретным пакетом.
Интенсивное расширение компьютерной инфотехнологии ставит перед
дальнейшим развитием СУБД целый ряд новых требований, во многом свя-
занных с вопросами стандартизации. Это относится не только к СУБД, но и к
ПС других типов. В отношении же СУБД это прежде всего относится к стан-
дартизации эталонной модели управления данными, предусматривающей
четкую классификацию основных вопросов стандартизации СУБД в зависи-
мости от функциональных особенностей и уровня описания данных на раз-
ных стадиях проектирования. Можно предполагать, что последующее разви-
тие СУБД будет ориентироваться на рекомендации международных стандар-
тов относительно языков БД и средств доступа к удаленным БД, а также ин-
терфейсов с системами программирования. Новые интересные аспекты БД-
технологии появляются на основе объектно-ориентированной технологии
программирования и обработки информации.
3.2. Объектно-ориентированные СУБД (ООСУБД)
В настоящем параграфе рассматриваются основные концепции, поня-
тия, черты и характеристики объектно-ориентированных систем управления
БД (ООСУБД) в контексте рассмотренных объектно-ориентированных про-
граммирования и технологии. В последние годы в результате проникновения
идеологии ООП в СУБД интенсивные разработки теоретического и приклад-
ного характера ведутся по созданию различного назначения ООСУБД. Ввиду
не совсем устоявшейся в этом направлении терминологии отметим основные
черты и характеристики, определяющие СУБД как объектно-
ориентированную. При этом по мере необходимости проводятся сопостав-
ления с рассмотренной выше концепцией ООП.
Характеристики ООСУБД подразделяются на три определяющие
группы:
— базовые, определяющие принадлежность СУБД к объектно-
ориентированному классу;
— по выбору, позволяющие улучшать ООСУБД, но не являющиеся базовы-
ми;
— открытости, позволяющие пользователю делать осознанный выбор из
ряда одинаково приемлемых реализаций ООСУБД.
В первую очередь, ООСУБД должна удовлетворять двум критериям:
быть СУБД в ее классическом понимании и быть объектно-ориентированной
системой (ООС), т.е. в определенной степени она должна быть совместимой
с современными объектно-ориентированными ЯВУ. Первый критерий вклю-
чает следующие пять характеристик, присущих классической СУБД: сохран-
ность данных, развитое управление внешней памятью, возможность совме-
щения обработки и поиска данных, поддержка средств восстановления и
возможность быстрого доступа к БД по запросу пользователя. Отмеченные
характеристики в той или иной мере обсуждались выше. Второй критерий
предполагает наличие следующих характеристик, присущих собственно объ-
ектно - ориентированной технологии: понятие сложных объектов, идентич-
ность объектов, инкапсуляция, типы или классы, наследование, настройка
(сочетающаяся с отложенным присвоением), расширяемость и вычислитель-
ная полнота. Характеристики первого критерия хорошо известны пользова-
телям традиционных СУБД (dBase, R-Base, др.)
Сложные объекты строятся из более простых путем применения к
ним конструкторов. В качестве простых используются такие объекты. как:
целые и действительные числа, символы, символьные строки любой длины,
булевы величины и, возможно, другие первичные типы. В качестве конст-
рукторов сложных объектов (объектных конструкторов) могут выступать:
кортежи, множества, списки, массивы, таблицы и др. В качестве минималь-
ного набора объектных конструкторов от ОООСУБД определяются: множе-
ство, кортеж, список или массив. Множество дает естественную возмож-
ность представления определенного набора объектов из имеющейся обшир-
ной совокупности; тогда как кортеж позволяет представлять определенные
свойства объекта. При этом кортежи и множества имеют особое значение,
получив широкое применение в качестве объектных конструкторов в реля-
ционных БД (РБД) Список или массив играют важную роль при установлении
порядка среди элементов множества. Более того, указанные типы объект-
ных конструкторов играют важную роль во многих приложениях (векторно-
матричные задачи, задачи анализа временных рядов и др.).
Объектные конструкторы должны удовлетворять принципу ортого-
нальности: любой конструктор может применяться к любому объекту. На-
пример, конструкторы РБД не обладают данным свойством (так конструктор
множества может применяться только к кортежам, а конструктор корте-
жей — только к первичным типам).
Глава 4
Иерархические стpуктуpы
Дерево представляет собой иерархию элементов, называемую узлами.
На самом верхнем уровне иерархии имеется только один узел - корень. Каж-
дый узел, кроме корня, связан с одним узлом на более высоком уровне, назы-
ваемым исходным узлом для данного узла. Ни один элемент не имеет более
одного исходного. Каждый элемент может быть связан с одним или несколь-
ким элементами на более низком уровне. Они называются порожденными.
Иерархические структуры относительно просто создаются и поддерживают-
ся. Это важно для ряда приложений, однако множество данных по своей при-
роде не связаны в древовидные структуры. Во многих структурах данных од-
на запись требует более одного представления (поэтому приходится разраба-
тывать способы объединения данных, которые по разному представляются
различным пользователям, в одну общую схему БД. В результате получаются
обычно более сложные структуры по сравнению с древовидными. Поэтому
программное обеспечение, сконструированное только для работы с древо-
видными структурами, имеет ограниченное применение и не редко сильно
влияет на возможности увеличения объема и развития БД.
Принципиальным для иерархического представления данных является
то, что каждый экземпляр записи приобретает свой смысл только тогда, ко-
гда он рассматривается в своем контексте; подчиненный экземпляр записи не
может существовать без своего предшественника по иерархии (несиммет-
ричность или асимметрия). Асимметрия - основной недостаток иерархиче-
ского подхода, поскольку она затрудняет работу пользователя. В частности,
пользователь вынужден тратить время и усилия на решение проблем, связан-
ных со спецификой модели и никак не следующих из характера задаваемых
вопросов. Очевидно, что такие проблемы усугубляются по мере увеличения
числа типов записей, представленных в структуре, и по мере роста сложно-
сти иерархии. Кроме того, иерархическая модель обладает еще некоторыми
нежелательными свойствами аномалии, которые ярко проявляются в связи с
выполнением каждой из основных операций запоминания (добавление, уда-
ление, модификация).
Длительный опыт использования иерархических систем показал, что
они весьма эффективны лишь для достаточно простых задач, но они практи-
чески не пригодны для использования в сложных системах с оперативной
обработкой транзакций и распределенной архитектурой. Иерархическая ор-
ганизация не может обеспечить быстродействие, необходимое для работы в
условиях одновременного модифицирования файлов несколькими приклад-
ными подсистемами.
4.1. Иерархические структуры в реляционных базах данных
Окружающий мир переполнен иерархическими данными. В это широ-
кое понятие входят компании, состоящие из дочерних компаний, филиалов,
отделов и рабочих групп; детали из которых собираются узлы, входящие за-
тем в механизмы; специальности, специализации и рабочие навыки; началь-
ники и подчинённые и т. д. Любая группа объектов, в которой один объект
может быть «родителем» для произвольного числа других объектов, органи-
зована в виде иерархического дерева. Очевидным примером может послу-
жить иерархия объектов VCL- класс TEdit представляет частный случай
TСontrol, потому что TСontrol является его предком. С другой стороны, TEdit
можно рассматривать и как потомка TWinControl или TCustomControl, пото-
му что эти классы являются промежуточными уровнями иерархии VCL.
Подобные связи не имеют интуитивного представления в рамках моде-
ли реляционных баз данных. Нередко иерархические связи являются рекур-
сивными (поскольку любая запись может принадлежать любой записи) и
произвольными (любая запись может принадлежать другой записи независи-
мо от того, кому принадлежит последняя). В двумерной таблице даже ото-
бражение иерархического дерева становится непростым делом, не говоря уже
о запросах. Иногда в критерий запроса входит родословная объекта (то есть
его родители, родители его родителей и т д.) или его потомство (сюда вхо-
дят дочерние объекты и всё их потомство).
4.2. Вложенные рекурсивные иерархические данные
Термин «рекурсивные иерархические данные» означает, что базовые и
подчинённые данные находятся в одной таблице: одно не ключевое поле за-
писи содержит ключевое значение другой записи, и это означает, что вторая
запись принадлежит первой. Не ключевое поле называется внешним ключом,
даже если по нему устанавливается связь с другим полем этой же таблицы.
Дочерние, подчинённые записи не знают, является ли их базовая запись под-
чинённой для какой-то другой записи - для них это несущественно. Каждый
уровень обладает своим набором базовых и подчинённых записей, и при
«раскрытии» конкретной подчинённой записи изменяются только конкрет-
ные отображаемые данные.
4.3. Отображение данных
Перемещение вверх и вниз по иерархическому дереву неизбежны, од-
нако вы можете воспользоваться средствами, которые автоматизируют эту
задачу. Подумайте, как пользователи будут работать с данными. Возможно,
их вообще не интересует иерархическая структура данных, но они захотят
искать объект по его предку. Или они будут искать объект по тому имени,
которым он представлен в иерархии, или только среди потомков текущего
объекта. Возможно, им потребуется узнать только идентификатор найденно-
го объекта или же получить список всех его потомков или предков.
В частности, вам придётся решить основной вопрос – что делать, когда
пользователь требует вывести «следующий» объект? Таким объектом может
быть: следующий потомок родителя текущего объекта; первый потомок те-
кущего объекта; следующий родитель, если текущий объект является единст-
венным потомком, или даже первый потомок следующего «родственника»
(sibling). В визуальном интерфейсе интуитивные ожидания пользователя ос-
нованы на положении текущего объекта в иерархии, способе его отображе-
ния и действиях самого пользователя, а не только на логическом протоколе,
определяемом абстрактной структурой данных приложения.
Помимо компонента TDBGrid, очевидным кандидатом для отображе-
ния иерархических данных являются компонент TTreeView. Этот компонент
были создан специально для отображения древовидных структур, а не тради-
ционных линейных списков. Он может занимать довольно большую область
экрана, поэтому не стоит применять его везде, где пользователь должен вы-
брать объект иерархии. Кроме того, при работе с этим компонентом жела-
тельно загружать в память всю структуру. Компонент можно настроить так,
чтобы «ветки» загружались по мере надобности, однако такая гибкость дос-
тигается ценой снижения производительности.
Целостность структуры и циклические ссылки
По иронии судьбы рекурсивная иерархия в одной таблице заметно уп-
рощает обеспечение целостности структуры: одно поле таблицы ссылается
на другое, принадлежащее этой же таблице. При этом защищаются все по-
томки объекта. Если же объединяющие значения находятся в нескольких по-
лях или таблицах, в результате чего становится возможной многоуровневая
группировка или установка сложных связей, обеспечить целостность струк-
туры будет сложнее
Для программы, работающей с иерархией, наибольшую опасность
представляют циклические ссылки. Если объект ссылается на несуществую-
щего родителя, проблему можно заметить и исправить. Но, если родитель
объекта оказывается одновременно и его потомком (если объекты разделены
несколькими промежуточными поколениями, такую ситуацию будет нелегко
обнаружить), программа зацикливается.
Где же выход? Можно проверять каждого «кандидата в предки» и
смотреть, не присутствует ли какие-либо из его предков в текущем «семейст-
ве» (правда, это будет накладно с точки зрения производительности). Кроме
того, в программу можно вставить счётчик-предохранитель, который ини-
циирует исключение после определённого количества циклов поиска. Одно
из преимуществ графических иерархических элементов как раз и заключает-
ся в том, что пользователь просто не сможет создать циклическую ссылку,
так как это противоречит логике работы с элементом.
При работе с иерархиями используется «семейная» терминология (ро-
дители, внуки, предки, потомки), поскольку семья является самым распро-
странённым примером объектов (в данном случае – людей), объединённых
иерархическими отношениями. Этот пример напомнит вам одну простую ис-
тину – хотя вы можете построить систему, предназначенную для обобщённой
обработки рекурсивных иерархий, ценность каждого объекта определяется
той уникальной информацией, которая в нём хранится. В то же время место
объекта в иерархическом дереве - не более чем условное обозначение связи с
другими объектами. Иерархическая структура всего лишь помогает сохра-
нить и найти объект.
Глава 5
OLE: основные сведения
Специфика предметов математики, физики, программирования такова,
что контрольные работы, зачёты, проверочные требуют наличия графиков,
формул, диаграмм. Поэтому возникает проблема отображения данных. Дос-
таточно трудно написать такую универсальную программу, которая справи-
лась бы с этим. С другой стороны, в Windows 95 содержится много про-
грамм, которые позволяют это сделать, например Word.
Существование операционной системы Windows 95 и реализация в ней
очень мощного механизма под названием OLE, позволяет решить эту про-
блему достаточно просто.
5.1. Введение в OLE
Windows поддерживает сложный, но чрезвычайно перспективный ме-
ханизм взаимодействия программ, который называется OLE. Этот механизм
широко используется во многих программных продуктах корпорации Micro-
soft, в том числе в текстовом редакторе Word и таблице Excel. В результате, в
документ, подготовленный, например, с помощью Word, можно внедрить
график, созданный в Excel. Если в процессе работы над документом возник-
нет необходимость в редактировании графика, достаточно дважды щелкнуть
не нем мышью — Windows откроет Excel и передаст таблице данные, позво-
ляющие изменить график средствами программы, его создавшей. После за-
вершения работы Excel измененный график будет переписан в исходный до-
кумент Word.
Последовательное использование OLE смещает акцент в работе поль-
зователя от программы-обработчика информации к конечному документу.
Без OLE пользователь вынужден разрабатывать конечный документ по час-
тям. Например, при подготовке рукописи книги к публикации рисунки могут
изготавливаться с помощью Paint или CorelDraw, в то время как текст — с
помощью Word или WordPerfect, после этого для верстки используется
Ventura Xerox Publisher или PageMaker. В этой технологии обрабатывающие
программы никак не связаны друг с другом и пользователь должен самостоя-
тельно решать проблемы совместимости форматов данных, передаваемых от
одного приложения другому. Применение OLE позволяет рассматривать до-
кумент в виде единого стержня, на который «нанизаны» программы-
обработчики типа Paint или Word. Пользователь полностью освобожден от
необходимости следить за форматами данных и согласовывать их, а переход
от одной программы к другой реализуется двойным щелчком мыши.
5.2. Связывания и внедрение объектов
При использовании OLE отдельные объекты (рисунки, графики, тек-
стовые фрагменты, таблицы) могут быть связаны с документом или внедрены
в него. Если объект связан с документом, в последнем сохраняется лишь ми-
нимально необходимая информация, позволяющая вызвать в нужный момент
программу, с помощью которой был создан объект, например, для его печати
на принтере или редактировании. Если объект внедрен в документ, он под-
вергается переработке клиентом перед вставкой в документ и становится во
многом независимым от «родной» программы. Например, Word может полу-
чить электронную таблицу от Excel, при этом численные данные и формулы
преобразуются в текстовые эквиваленты и в таком виде внедряются в доку-
мент. Однако связь с программой-обработчиком сохраняется и в этом случае,
поэтому пользователь может в любой момент загрузить обрабатывающую
программу для редактирования внедренного объекта.
С объектами или заменяющими их пиктограммами связаны действия,
которые может произвести двойной щелчок мыши. Над объектами определе-
ны два основных действия - отображение и редактирование. При этом над
связанным объектом первичным действием будет отображение, а над вне-
дренным - редактирование. Первичное действие обычно связывается с двой-
ным щелчком мыши на пиктограмме упакованного объекта. Некоторые объ-
екты позволяют выбирать первичное действие, для чего они создают соот-
ветствующие диалоговые окна. Другое объекты допускают только одно дей-
ствие. Например, объект, созданный текстовым редактором и внедренный в
графику, как правило, поддерживает только редактирование, а звуковые дан-
ные после внедрения их в текст поддерживают только отображение (воспро-
изведение).
Технология связывания и внедрения объектов OLE позволяет создать
некоторый объект, например рисунок или звуковой файл, в одном из
Windows-приложений и затем вставить его в другой файл. Этот объект может
быть либо связанным, в этом случае он существует фактически в отдельном
файле, либо внедрённым, и тогда он находится внутри основного файла. Дру-
гими словами, данные, картинки, текст и иные объекты, которые вы создаете
в разных приложениях, могут быть объединены в один составной документ,
который сохраняет связи со всеми исходными приложениями.
Этот составной документ управляется каким-нибудь одним приложе-
нием, например Excel или Word для Windows, а связи обеспечивают пути к
другим приложениям так, чтобы вы могли редактировать свои объекты, ис-
пользуя приложения, в которых они были созданы.
Таким образом, при правильном применении характеристика OLE по-
зволяет вам централизовать всю свою работу в пределах одного домини-
рующего приложения и в одном документе, называемом клиентом. Если вам
понадобятся какие-либо данные, графика или другая информация, которая
находится в других приложениях, вы сможете, оставаясь в своем приложе-
нии-клиенте, присоединять, привязывать их из соответствующих приложе-
ний, называемых в этом случае приложениями - серверами.
Если вам требуется отредактировать текст, данные или графику, соз-
данные в приложении-сервере, то это можно сделать из документа-клиента с
помощью, как правило, двойного щелчка на объекте, подлежащем редакти-
рованию. При этом Windows открывает приложение-сервер и ассоциирован-
ный с ним объект. После внесения редакторской правки вы просто выходите
из приложения-сервера и автоматически возвращаетесь в приложение-клиент
и документ, над которым работаете.
5.3. Различие между связыванием и внедрением объектов
В самом общем смысле, связь понимается как соединение, которое по-
зволяет некоторому документу (клиенту) одного Windows-приложения со-
общаться с другим Windows-приложением (сервером). Термин "клиент" поч-
ти всегда относится к документу, не к приложению. Термин же "сервер" мо-
жет относиться и к приложению и к документу, а также к тому и другому
вместе. Эта терминологическая неопределенность происходит от способа,
которым Windows формирует связи.
Исходный документ — это просто файл, который используется для ко-
пирования данных, текста или графики в буфер переноса, так что появляется
возможность привязывать или внедрять содержимое буфера в другой доку-
мент (клиент). Однако действительная связь, возникающая при этом, пред-
ставляет собой связь между документом-клиентом и приложением-сервером.
Эта связь обеспечивает документу-клиенту возможность знать, каким при-
ложением был создан объект и как запускать это приложение-сервер. Здесь
мы имеем дело с внедрённым объектом.
В некоторых случаях (в частности, для связывания объектов) создают-
ся еще две связи — между документом-клиентом и исходным документом и
между документом-клиентом и объектом в исходном документе, который
был скопирован и приклеен. Исходный документ часто называют докумен-
том-сервером, поскольку он всегда управляется приложением сервером и
обеспечивает данными связанный объект. При существовании этих дополни-
тельных связей изменение данных в исходном объекте автоматически отра-
жается в объекте клиента.
Итак, различие между связанным и внедрённым объектами определя-
ется следующими признаками:
Связанный объект обычно хранит только дескрипторы, которые гово-
рят этому объекту, где найти приложение-сервер, документ-сервер и связан-
ный элемент в документе-сервере (здесь используется слово "элемент" для
обозначения области документа, которая копировалась из исходного доку-
мента в буфер переноса, а слово "объект" — для зоны в документе-клиенте,
которая содержит связанный элемент.) Приложение-сервер затем модернизи-
рует документ-клиент всякий раз, когда изменяется информация в докумен-
те-сервере. В некоторых приложениях документы-клиенты сохраняют также
последнюю связанную информацию при выходе из документа.
Внедрённый объект представляет собой полномасштабную версию
припасенного элемента: он содержит все данные, текст и графику, которые
были приклеены из буфера переноса с целью создания этого объекта. Вне-
дрённый объект содержит также связь с приложением-сервером, которая при
двойном щелчке на объекте в документе-клиенте позволяет запустить при-
ложение-сервер и затем отредактировать этот объект средствами приложе-
ния-сервера.
Глава 6
Достоинства и недостатки тестовой системы или методическое обосно-
вание автоматизации процесса обучения
Одной из форм привлечения преподавателей к использованию компь-
ютера являются тестирующие программы, которые позволяют упростить
проверку знаний учащихся и в то же время в увлекательной форме преподно-
сят ученикам знания по той или иной дисциплине.
Возможны три формы организации тестов, которые условно можно на-
звать «выбери ответ из предлагаемых вариантов», «напиши правильный от-
вет», «найди связь между объектами».
Организация теста по принципу «выбери ответ из предлагаемых вари-
антов» обеспечивает относительно простой диалог с тестируемым и, как
следствие, быстроту прохождения теста, так как не требует от учащегося
особых навыков работы на компьютере. Для выбора ответа достаточно на-
жать на клавиатуре соответствующую клавишу или щёлкнуть мышью на ок-
не, выбрав его среди предложенных. Такая простота выбора ответа не отвле-
кает учащегося от предметной сути поставленного перед ним вопроса. Пре-
имущество такой организации тестирующей программы заключается ещё и в
простом критерии правильности ответа, данного учащимся. Однако такая ор-
ганизация теста имеет и недостаток наличие «скрытой» подсказки на вопрос
– выбирать ответ гораздо легче, чем писать его полностью самостоятельно.
Организация теста по принципу «напиши правильный ответ», предпо-
лагает хорошую начальную подготовку учащегося как пользователя персо-
нального компьютера. Решение технических проблем может отвлечь учаще-
гося от предметной сути работы с программой. Кроме того, предполагается
абсолютная грамотность при выдаче ответа. Таким образом, скорость прохо-
ждения теста во многом зависит от развития навыков работы за компьюте-
ром. Помимо этого, ответ на каждый вопрос теста может иметь различную
степень подробности. Для многих предметов предусмотренных программой
выбор критерия оценки правильности ответа при такой организации теста
очень затруднителен, так как требуется решать такие вопросы, как учитывать
степень развёрнутости ответа, грамотность и т. п.
Из вышеизложенного следует, что для тестирующей программы наи-
более подходит организация по принципу «выбери правильный ответ из
предлагаемых».
Программа должна:
1. Объяснять тестируемому правила работы;
2. Тестировать учащегося и выставлять ему оценку по окончании тестирова-
ния;
3. Допускать завершение тестирования при любом количестве пройденных
вопросов с выставлением оценки по фактическому количеству ответов.
Необходимые для тестирования данные должны быть защищены. Иметь воз-
можность ограничить время проведения теста.
Требования, описанные выше, реализованы в системе TEST. Система
TEST позволяет автоматизировать проведение контрольных срезов, работ,
зачётов по любым дисциплинам. Система состоит из трёх связанных между
собой частей. Первая часть это программа- редактор вопросов, позволяющая
преподавателю создавать индивидуальную базу данных вопросов по своим
дисциплинам. Вторая часть представляет собой тестирующую программу,
предназначенную для студентов. Третья часть предназначена для преподава-
теля, представляет собой статистику прохождения теста, с помощью этой
программы преподаватель может проанализировать результаты прохождения
теста и сделать соответствующие выводы, а также настроить основные пара-
метры теста.
Преподаватель может полностью отказаться от проведения письмен-
ных контрольных работ: оценки, полученные студентами на письменных
контрольных работах, выше оценок, выставляемых системой. Преподаватель
может вносить любые изменения, которые будут храниться в базе данных,
также он может контролировать проведение теста: просматривать данные
студентов, даты проведения, оценки. Результаты теста преподаватель анали-
зирует и подводит итог.
В процессе выполнения контрольной работы универсальность работы
на компьютере позволила студентам не ждать остальных и реализовывать
свои возможности в большей степени. В работах такого характера студенты
самостоятельно занимаются исследовательской деятельностью, что значи-
тельно укрепляет полученные знания. Начиная своё маленькое компьютерное
исследование с простейших экспериментов, студент постепенно обучается
работе с моделями и в дальнейшем способен перейти к более сложным эта-
пам – компьютерному контролю и анализу реального эксперимента. Исклю-
чает возможность коллективных ответов на вопросы. Это удобное добавле-
ние к традиционным методам контроля, повышается эффективность усвое-
ния предмета студентом.
5.1. Межпредметные связи и компьютерное обучение
Одной из наиболее важных общеобразовательных целей информатики
является наведение и усиление межпредметных связей, способствование вос-
приятию целостной, системной картины мира, информационных процессов в
обществе, природе и познании.
Электроника и вычислительная техника (ВТ) становятся компонентами
содержания обучения различным предметам, средствами оптимизации и по-
вышения эффективности научного процесса. Для разумного и плодотворного
использования ВТ необходима общеобразовательная и компьютерная гра-
мотность. Отсюда выявляется межпредметная связь с основами информатики
и ВТ, с математикой, русским языком, литературой и английским языком. ВТ
для учителя выступает и как предмет, и как средство обучения, и как инстру-
мент психолого-педагогических исследований (тестирования). Умение ис-
пользовать ВТ становится одним из профессионально необходимых качеств
учителя, и если рассматривать процесс компьютеризации обучения как одну
из наиболее современных тенденций методики преподавания предметов, то
владение принципами и методикой компьютерного обучения должно стать
современным требованием квалификационной характеристики преподавате-
ля. ВТ находит широкое применение в преподавании не только как средство,
ускоряющее вычисления, но и как средство, моделирующее математически-
ми методами физические процессы и явления, как современное средство на-
глядности в сочетании её абстрактно-логической стороны с предметно-
образной, как средство математической обработки результатов демонстраци-
онного эксперимента и лабораторных работ, контроля и самоконтроля зна-
ний студентов. Компьютерное обучение должно рассматриваться вместе с
другими методами и средствами, как компонент электронного обучения в це-
лом. Вся совокупность компонентов компьютерной грамотности учителя по-
зволяет ему не только использовать компьютерную технику на практике по
предмету, но и формировать и совершенствовать образовательные основы
программирования и знаний ВТ студентов в системе межпредметных связей.
Программы для обработки результатов, которые используют только
вычислительные возможности ЭВМ и носят вспомогательный характер, не
преследуя педагогических целей. Они позволяют использовать статистиче-
ский анализ данных измерений. Внедрение ВТ в учебный процесс должно
носить системно-функциональный характер, который предполагает установ-
ление фундаментальный идей, связывающих в единую систему структурные
элементы каждой науки, и их преобразование в курсах предметов с обяза-
тельным учётом психолого-педагогических возможностей учащихся на дан-
ном этапе обучения.
Глава 7
Разработка тестирующей программы
В моей работе были применены вложенные рекурсивные иерархиче-
ские данные для отображения предметов, тем и вопросов хранящихся в базе
данных. Это означает, что базовые и подчинённые данные хранятся в одной
таблице «Data». С помощью компонента TTreeView удобно организовано
представление в виде иерархического дерева, что соответствует логике ре-
шаемой задачи. Таблица реляционного типа отображает наши данные в виде
иерархии. В таблице первое поле ключевое, в нём название тем-родителей:
«Механика», «Кинематика», «Кинематика материальной точки», «Физика»,
«Зачет по механике». Второе поле является подчиненным для первого: раз-
дел «Кинематика материальной точки» содержит Вопрос 1-4.
Key_Id
Key_Parent
Поле строкового типа
0
15
Механика
2
0
Кинематика
3
0
Динамика
23
2
Кинематика материальной точки
24
23
Вопрос 1
26
23
Вопрос 2
27
23
Вопрос 3
28
23
Вопрос 4
30
30
Физика
31
30
Зачёт по механике
32
31
Вопрос 1
33
31
Вопрос 2
34
31
Вопрос 3
35
31
Вопрос 4
36
31
Вопрос 5
37
31
Вопрос 6
На основе таблицы строится иерархия такого типа.
Также база данных содержит следующие таблицы:
Таблица «Факультет» содержит поле название факультета.
Название
ФИЯ
ФМИ
Таблица «Группа» содержит поле номер группы.
Номер
455
465
475
485
Таблица «Статистика» содержит данные о прохождении теста.
№ п/п
Название темы
Дата
Оценка
1
Кинематика материальной точки
27.03.99
4
2
Электродинамика
12.05.99
3
3
Механика
13.05.99
2
Таблица «Данные студента» - при регистрации данные заносятся в эту
таблицу.
№ п/п
Фамилия
Группа
Факультет
1
Иванов
455
ФМИ
2
Петров
485
ФИЯ
3
Ельцин
465
ФМИ
Таким образом база данных состоит из пяти таблиц.
При решении задачи возникли следующие проблемы:
1. Эффективное хранение информации в базе данных.
Особенность базы в том, что она состоит из полей типа binary, содер-
жащие графические изображения, поэтому при небольшом объёме хранимой
информации размер базы становится слишком большим. Хранение информа-
ции в стандартном формате bmp оказывается крайне неэффективным. Иссле-
довав большинство распространённых графических форматов jpc, gif, tiff, я
пришла к выводу, что наиболее оптимальным с точки зрения сохранения ко-
личества сжатия является формат gif. В этом формате и решено было сохра-
нять изображения в базе данных.
Стандартные компоненты Delphi не позволяют хранить графическую
информацию в базе данных в формате gif, в связи с этим были использованы
продукты компании SkyLine. В своей работе я использовала библиотеку
компонентов Image Lib 30 в составе которой есть компоненты, позволяющие
хранить информацию в базе данных самых различных форматов.
2. Модификация стандартного компонента Delphi OleContainer.
Так как реализация этого компонента не позволяла сохранять изобра-
жения, полученные от программы сервера, был реализован собственный
OleContainer расширением стандартного компонента. Свойство
Bitmap:TBitmap, которое при перерисовке компонента, копирует на свою
канву, канву стандартного компонента OleContainer. Таким образом, с помо-
щью свойства Bitmap, в программе можно использовать изображение OLE-
контейнера, который затем и помещается в базу в формате gif.
Заключение
Итогом написания дипломной работы явилось создание программного
продукта «Системы автоматизированного контроля знаний студентов».
Были решены следующие поставленные передо мной задачи:
– дан обзор современному состоянию теории баз данных, основным
моделям СУБД, применяемым в ПК;
– изучены принципы функционирования и основные возможности
технологии OLE;
– разработан способ отображения реляционных структур данных в
иерархическом виде;
– дополнен стандартный компонент Delphi OLEContainer возможно-
стью сохранения битового изображения на его поверхности.
Программа контроля знаний TEST, которая рассматривалась в 5 главе,
работает под управлением операционной системы Windows 95. Справочная
система позволит легко и быстро научится работать с системой TEST.
Это удобное добавление к традиционным методам контроля, повы-
шающее эффективность усвоения предмета студентом. Система состоит из
трёх связанных между собой частей. Первая часть это программа- редактор
вопросов, позволяющая преподавателю создавать индивидуальную базу дан-
ных вопросов по своим дисциплинам. Вторая часть представляет собой тес-
тирующую программу, предназначенную для студентов. Третья часть пред-
назначена для преподавателя, представляет собой статистику прохождения
теста, настройку параметров, с помощью этой программы преподаватель мо-
жет проанализировать результаты прохождения теста и сделать соответст-
вующие выводы.
Таким образом, эта система может использоваться преподавателями,
вне зависимости от дисциплины и одинаково подходит как для естественно-
научных, так и для гуманитарных предметов.
Список литературы
1. В.В. Аладьев, Ю.Я. Хунт, М.Л. Шишаков. Основы информатики. Учебное
пособие. – Москва. 1999.
2. В.А. Извозчиков, А. Д. Ревунов. Электронно-вычислительная техника на
уроках физики в средней школе. - М.: Просвещение, 1988.
3. А. А Жуков, Л.А Федякина. "Система контроля знаний TSTST".
// Информатика и образование. -1997.- №2.
4. А.А. Ездов. Лабораторные работы по физике с использованием компью-
терной модели. // Информатика и образование. -1996.- №1.
5. М.Г. Ермаков, Л.Е. Андреева. Вопросы разработки тестирующих про-
грамм. // Информатика и образование. –1997.- №3.
6. В. М. Карнаухов. Система контроля знаний. // Информатика и образование.
-1995.- №6.
7. В. М. Казиев. Системно-алгебраический подход к основам информатики. //
Информатика и образование. -1996.- №4.
8. Е.А. Ерёмин. Почему система интересна для образования. // Информатика
и образование. -1997.- №1.
9. П. Дарахвелидзе, Е. Марков. Delphi - среда визуального
программирования. — BHV Санкт-Петербург: 1996.
10. Джон Матчо, Дэвид Р. Фолкнер. Delphi. — Бином М. 1996.
11. Тодд Миллер, Дэвид Пауэл и др. Использование Delphi 3. – Диалектика
Киев. 1997.
12. В.В. Фаронов. Паскаль и Windows. – Москва. 1995.
13. Механизмы Windows 3.1. – Энтроп Москва. 1994.
42
| |
