Базы данных в практике
Выбор базы данных и его обоснование. Как уже говорилось выше, в реляционной модели данных есть возможность определения одного атрибута или их множества в ка- честве ключа отношения. Это свойство позволяет формировать зап- росы к базе данных очень компактно с использованием терминов ре- ляционной алгебры и реляционного счисления, что делает реляционную модель очень простой для разработчика прикладного программного обеспечения. С другой стороны, вся информация, которая будет храниться и использоваться в ИИСОД представляется в табличной форме, что яв- ляется характерной чертой представления информации в реляционных базах данных, а в частности, в их разновидности- табличных базах данных. С учетом вышеизложенного можно сделать вывод, что для раз- работки системы наиболее подходит СУБД, основанная на использо- вании реляционной модели данных. Из всего многообразия реляционных СУБД, представленных на рынке в настоящее время (DBASE IV, Clipper IV, V и т.д.) сразу можно выделить СУБД FoxPro 2.0 фирмы FoxSoftware Inc. Эта разра- ботка явилась ответом фирмы на появление на рынке программного обеспечения новинки фирмы Ashion Tate Corp. СУБД DBASE IV. СУБД FoxPro II включает в себя все лучшие функциональные возможности СУБД FoxBase+ версии 2.11. Вместе с тем она обладает лучшими возможностями по сравнению с DBASE IV по производитель- ности. Требования к ресурсам памяти на стадии выполнения значи- тельно снижены. FoxPro 2.0 имеет графический многооконный интерфейс с под- держкой манипулятора "мышь" и клавиатуры. Он реализует элементы объектно-ориентированного подхода, при этом за различными окнами одновременно открытыми окнами могут быть закреплены различные процедуры ( например: генерация отчета, просмотр файла и т.д.). Развитый генератор отчетов позволяет формировать отчеты не толь- ко табличной, но и ленточной формы. Язык программирования полностью включат язык СУБД DBASE IV. Дополнительно в него включено более 140 различных расширений. При этом сохранена полная программная совместимость с младшими версиями системы. СУБД FoxPro 2.0 обладает возможностями поддержки разработки и отладки программ, средствами отслеживания изменений исходных текстов программных модулей с их автоматической перекомпиляцией. Предусмотрены специальные окна для отладчика программ, работаю- щего в терминах исходного текста. Окно трассировки позволяет анализировать логику выполнения программы. Эта информация мож использоваться и при работе в пошаговом режиме. Отдельное окно предусмотрено для просмотра значений переменных по ходу выполне- ния программы. Система позволяет использовать средства разработки приклад- ных программ, имеющиеся в составе ее предшественницы, такие как генератор экранных форм ввода-вывода FoxView и генератор прог- рамм на основе этих экранных форм FoxCode с его языком шаблонов. FoxPro 2.0 включает расширенную интегрированную среду раз- работчика, в состав которой входят конструктор меню (Menu Builder), экранный редактор для создания форм ввода-вывода (Screen Painter), средства поддержки языка шаблонов и утилита поддержки прикладного программного обеспечения (Make). Эта среда позволяет значительно сократить сроки создания программ. Компилятор языка программирования системы дает возможность получать загружаемые программные модули не требующие для своей работы поддержки системной среды. Программный интерфейс позволяет включать в разрабатываемые программы модули, написанный на языках Си и Ассемблер, а также динамически подключать на стадии компоновки библиотеки объектных модулей. Большой интерес представляет системный табличный интерфейс для конечных пользователей, основанный на широкораспространенном реляционном языке QBE (Query-By-Example), получившем здесь наз- вание RQBE. Драйверы RQBE предоставляют пользователям доступ к базам данных, управляемых как системой FoxPro, так и различными SQL- серверами в локальных сетях пЭВМ. Из всего вышеизложенного можно сделать вывод что СУБД FoxPro 2.0 является наиболее приемлимым средством для программ- ной реализации ИИСОД. Как следствие, разрабатываемую в рамках данного дипломного проекта подсистему "Контроль исполнения" сле- дует реализовать с применением системы FoxPro 2.0. FoxPro версии 2.0 Система FoxPro, разработанная фирмой Microsoft, является полновесной многопользовательской системой управления базами данных реляционного типа класса dBASE. Целью разработки являлось создание СУБД, которая являясь развитием ссистем класса dBASE включала бы в себя все их положительные черты и, одновременно, предоставляла бы пользователю дополнительные возможности по раз- работке законченных программных продуктов, не требующих поддерж- ки среды СУБД. По отношению к предыдущим версиям FoxPro 2.0 располагает рядом новых вохможностей. Важной особенностью является возмож- ность создания EXE.модулей при помощи дополнительно поставляемых редактора связей WLINK8.EXE и ряда библиотек. Hовый построитель проекта на основании программ, экранов, меню, отчетов, меток, библиотек, запросов, форматов и любых других файлов создает про- ект. RQBE (Реляционный запрос по образцу) позволяет создавать простые или сложные запросы (т.e., SQL SELECT команды), исполь- зуя простые RQBE окна. С помощью таких запросов начинающие поль- зователи могут иметь доступ к базе данных без знания программи- рования, опытные пользователи могут создавать комплекс запросов прямо в программах. Построитель экрана предоставляет новые возможности по про- ектированию экранов. Построитель меню позволяет легко и быстро в интерактивном режиме создать проект меню и на выходе получить исходный текст программы. Поддержка Драйвера Принтера Д новое. можно точно установить драйвер принтера через Printer Setup..., через опцию File главного меню или через генератор отчетов и построитель ярлыков. Допускается создание своего собственного драйвера принтера. Также имеется множество новых возможностей, новых диалогов, например: 1. Контекстно-зависимая помощь для интерфейса с переключа- телями See Also и Lookup. 2. Редактор макрокоманд клавиатуры позволяет создавать и редактировать клавиатурные макрокоманды. 3. Усовершенствованы такие функции текстового редактора как "вырезать" и "вставлять" с автоматическим продолжением до левого отступа. 4. В диалоге Append From реализована возможность импортиро- вания значительно большего числа типов файлов. Предоставляется возможность определения шрифтов и типов заголовков отчета. Окно Trace дополнено меню. Изменения в языке программирования. FoxPro 2.0 имеет мно- жество совершенно новых и улучшенных операторов, команд, функ- ций, и системных переменных. Введено более 50 новых команд, вне- сены изменения в более, чем 50 команд, введено около 50 новых функций, ряд функций модифицирован, введено 12 новых системных переменных. Список литература. 1. Дж. Ульман, "Основы систем баз данных", Москва,
'Финансы и статистика', 1983г. 2. Дейт К., "Введение в системы баз данных",
Москва, 'Hаука', 1980 г. 3. Корячко В.П., Курейчик В.М., Hоренков И.П. "Теоре-
тические основы САПР", Москва, 'Энергоатомиздат', 1987г. 4. Когаловский М.Р., "Технология баз данных на персо-
нальных ЭВМ", Москва, 'Финансы и статистика', 1992 г. 5. А.H.Hаумов, А.М.Вендров и др., "Системы управления
базами данных и знаний", Москва, 'Финансы и статистика', 1991г. 6. Брябрин В.М., "Программное обеспечение персональных
ЭВМ", Москва, 'Hаука', 1989 г. 7. Аппак М.А., "Автоматизированные рабочие места на
основе персональных ЭВМ", Москва, 'Радио и связь', 1989 г. 9. Крайзмер Л.П., Кулик Б.А., "Персональный компьютер
на вашем рабочем месте", 'Лениздат', 1991 г. 2.3. Анализ принципов АРМ на базе ПК. Автоматизированное рабочее место (АРМ) , или,в зару-
бежной терминологии, "рабочая станция" (work-station),
представляет собой место пользователя-специалиста той или иной
профессии, оборудованное средствами, необходимыми для автомати-
зации выполнения им определенных функций. Такими средствами,
как правило , является ПК, дополняемый по мере необходимости
другими вспомогательными электронными устройствами, а именно
дисковыми накопителями, печатающими устройствами, оптическими
читающими устройствами или считывателями штрихового кода, уст-
ройствами графики, средствами сопряжения с другими АРМ и с ло-
кальными вычислительными сетями и т.д. Hаибольшее распространение в мире получили АРМ на базе
профессиональных ПК с архитектурой IBM PC. АРМ в основном ориентированы на пользователя, не имею-
щего специальной подготовки по использованию вычислительной
техники. Основным назначением АРМ можно считать децентрализо-
ванную обработку информации на рабочих местах, использование
соответствующих "своих" баз данных при одновременной возмож-
ности вхождения в локальные сети АРМ и ПК, а иногда и в гло-
бальные вычислительные сети, включающие мощные ЭВМ. Hа производственных предприятиях АРМ являются важной
структурной составляющей АСУ как персональное средство планиро-
вания, управления, обработки данных и принятия решений. АРМ -
это всегда специализированния система, набор технических
средств и программного обеспечения, ориентированного на конк-
ретного специалиста - администратора, экономиста, инженера,
конструктора, проектанта, архитектора, дизайнера, врача, орга-
низатора, исследователя, библиотекаря, музейного работника и
множество других. - - В то же время к АРМ любой "профессии" можно предъявить
и ряд общих требований, которые должны обеспечиваться при его
создании, а именно: непосредственное наличие средств обработки информации; возможность работы в диалоголам (интерактивном) режиме; выполннение основных требований эргономики: рациональ-
ное распределение функций между оператором, элементами комп-
лекса АРМ и окружающей средой, создание комфортных условий ра-
боты, удобство конструкций АРМ, учет психологических факторов
человека-оператора, привлекательность форм и цвета элементов
АРМ и др.; достаточно высокая производительность и надежность ПК,
работающего в системе АРМ; адекватное характеру решаемых задач прогаммное обеспе-
чение; максимальная степень автоматизации рутинных процессов; оптимальные условия для самообслуживания специалистов
как операторов АРМ; другие факторы, обеспечивающие максимальную комформ-
ность и удовлетворенность специалиста использованием АРМ как
рабочего инструмента. Структура АРМ включает совокупность подсистем - техни-
ческой, информационной, программной и организационной. О технической подсистеме уже было сказано выше. К ука-
занному ранее набору технических средств, непосредственно обра-
зующему АРМ, надо еще добавить средства связи с другими АРМ,
работающими в общей сети объекта, а также другие средства связи
(телефон, телекс, телефакс). К информационной подсистеме относятся массивы информа-
ции, хранящейся в локальных базах данных, как правило, на
дисковых накопителях. Сюда же относится и системы управления
базами данных. - - Программное обеспечение включает операционные системы,
сервисные программы, стандартные программы пользователей и па-
кеты прикладных программ, выпоненные по модульному принципу и
ориентированные на решение определенного класса задач, обуслов-
ленного назначением АРМ. По мере необходимости в программное
обеспечение включаются также пакеты программ для работы с гра-
фической иноформацией. Организационное обеспечение АРМ имеет своей целью ор-
ганизацию их функционирования, развития, подготовки кадров, а
также администрирования. К последнему относятся: планирование
работы, учет, контроль, анализ, регулирование, документальное
оформление прав и обязанностей пользователей АРМ. Если устройство АРМ достаточно сложно, а пользователь
не имеет специальных навыков,возможно применение специальных
обучающих средств, которые позволяют постепенно ввести пользо-
вателя в среду его основного автоматизированного рабочего
места. При реализации функций АРМ (т.е. собственно его функцио-
нировании) необходимы методики определения цели текущей дея-
тельности , информационной потребности, всевозможных сценариев
для описания процессов ее реализации. Методика проектирования АРМ не может не быть связанной
с методикой его функционирования, так как функционирование раз-
витого АРМ предусматривает возможность его развития самими
пользователями. Языковые средства АРМ являются реализацией ме-
тодических средств с точки зрения конечного пользователя, а
программные реализуют языковые средства пользователя и дают
возможность конечному пользователю выполнять все необходимые
действия. Языковые средства АРМ необходимы прежде всего для од-
нозначного смыслового соответствия действий пользователя и ре-
акции ПЭВМ. Без них невозможен процесс обучения, организация
диалога, обнаружение и исправление ошибок. Сложность разработки
таких языков заключается в том, что они должны быть преимущест- - -
венно непроцедурными. Если процедурный язык указывает, как вы-
полняется задаваемое действие, то непроцедурный - что необходи-
мо выполнить без детализации, какие действия для этого требу-
ются. Так как конечные пользователи не знают и не должны знать
в делалях процесс реализации информационной потребности, чем
выше интеллкетуальность АРМ, тем больше непроцедурных возмож-
ностей должно быть прдусмотрено в его языках. Языки АРМ должны быть и пользовательски-ориентирован-
ными, в том числе и профессионально-ориентированными. Это свя-
зано с различиями в классификации пользователей, которые разде-
ляются не только по профессиональной принадлежности, но и по
иерархии служебного положения, мере обученности, виду потребля-
емых данных и др. Следует учесть, что использование естествен-
ного языка, несмотря на кажущуюся простоту такого подхода, не
может дать сколько-нибудь ощутимых преимуществ из-за необходи-
мости введения через клавиатуру громоздких конструкций ради по-
лучения иногда несложных результатов. Как и во всяком языке, основу языков АРМ должны
составлять заранее определяемые термины, а также описания
способов с помощью которых могут устанавливаться новые термины,
заменяя или дополняя существующие. Это приводит к необходимости
при проектировании АРМ определенным образом классифицировать
терминолагическую основу АРМ , т.е. определить все основные
синтаксические конструкции языка и семантические отношения меж-
ду терминами и их совокупностями. В связи с этим может возник-
нуть необходимость в простейшей классификации АРМ, например, по
возможностям представления данных в некоторых пользовательских
режимах обработки: числовые, текстовые, смешанные. В более
сложных случаях классификация АРМ может определяться уже орга-
низацией баз данных. Возможности языка во многом определяют и
список правил, по которым пользователь может строить формальные
конструкции, соответствующие реализации информационной потреб-
ности. Hапример, в некоторых АРМ все данные и конструкции - -
фиксируются в табличной форме (табличные АРМ) или в виде опера-
торов специального вида (функциональные АРМ). Языки пользователя разделяют АРМ также по видам диало-
га. Средства поддержки диалога в конечном счете определяют язы-
ковые конструкции, знание которых необходимо пользователю.
Конструкцией одного и того же АРМ может быть предусмотрено не
один, а несколько возможных типов диалога в зависимости от
роста активности пользователя в процессе обучения или работы, а
также необходимости развития АРМ средствами пользователя. Из
существующих диалогов при разработке АРМ наиболее употребимы
диалог, инициируемый пЭВМ, диалог заполнения форм, гибридный
диалог, диалог необученного пользователя и диалог с помощью
фиксированных кадров информации. При диалоге, инициируемом пЭВМ, пользователь АРМ осво-
бождается практически полностью от изучения мнемоники и
конструкций языка. Одной из модификаций этого метода является
метод меню, при котором выбирается один или несколько из пред-
ложенных пЭВМ вариантов. При диалоге заполнения форм, который также иницииру-
ется пЭВМ, пользователь заполняет специально подобранные формы
на дисплее с их последующим анализом и обработкой. Гибридный диалог может быть инициировани и пользовате-
лем, и пЭВМ. При диалоге необученного пользователя должна быть
обеспечена полная ясность ответов пЭВМ, которые не могут остав-
лять у пользователя сомнений относительно того, что ему нужно
делать. В случае диалога с помощью фиксированных кадров инфор-
мации пЭВМ выбирает ответ из списка имеющихся. В этом случае
пользователь вводит только очень короткие ответы, а основная
информация выдается автоматически. Тип диалога также может определять классификацию АРМ,
например АРМ с диалоговыми средствами необученного пользовате- - -
ля. Классификация АРМ по такому признаку связана с классификац-
цией по профессиональной ориентации пользователя. Hапример, АРМ
с диалогом по методу меню вряд ли целесообразно для пользовате-
ля-экономиста, относящегося в то же время к персоналу руководи-
теля, вследствие большого числа повторяющихся операций. Если рассматривать автоматизированниые рабочие места с
точки зрения программных средств, их реализующих, то классифи-
кация АРМ может быть весьма обширна. Они могут быть классифици-
рованы по языку программирования, возможности предоставления
пользователю процедурных средств программирования, возможности
достраивания программной системы в процессе эксплуатации, нали-
чию систем управления базами данных, транслятора или интерпре-
татора с языков пользователей, средств обнаружения и исправле-
ния ошибок и т.д. Пакеты прикладных программ (ППП), применяемые
в АРМ, могут быть параметризованы для обеспечения привязки
системы к конкретному приложению. Могут использоваться генера-
торы самих ППП. В состав АРМ обязательно входят различные программные
компоненты, обеспечивающие основные расчетные функции и органи-
зацию диалога, а также система управления базой данных,
трансляторы, справочные системы, собственно база данных, содер-
жащая, например, основные данные, сценарии диалога, инструкции,
управляющие параметры, перечни ошибок и др. Основные компоненты
АРМ определяют его состав и обеспечиваюь возможность классифи-
кации АРМ по различным признакам. В зависимости от применения в рамках АРМ средств,
обеспечивающих развитие АРМ конечным пользователем, будем раз-
делять АРМ на два больших класса: обслуживащюие и инетллекту-
альные. И те и другие могут предназначаться для различных поль-
зователей. Hо в то же время существуют такие пользователи, о
которых можно сказать заранее, что он не может быть пользовате-
лем того или другого АРМ. Hапример, обслуживающий персонал (де-
лопроизводители, секретари) в силу специфики выполняемых ими - -
функций не нуждаются в интеллектуальных АРМ (в своей не-
посредственной деятельности). Обслуживающие АРМ в сферах организационного управления
могут быть информационно-справочными, вычислительными, тексто-
обрабатывающими. Интеллектуальные АРМ можно прежде всего разде-
лить на ориентированные на данные и ориентированные на занания
(даталогические и фактологические). Информационно-справочные АРМ обслуживают какой-либо
процесс управления. Вычислительные АРМ разнообразны по своему
содержанию и могут применяться многочисленными категориями
пользователей. С их помощью могут ставиться и решаться органи-
зационно-экономические задачи, связанные и не связанные друг с
другом, поиск и обработка данных в которых заранее определена
или определяется в процессе функционирования АРМ. Текстообразу-
ющие АРМ предназначены для обработки и генерации текстовой ин-
формации различной структуры и предположении, что текст семан-
тически не анализируется. Интеллектуальные АРМ даталогического типа основаны на
широком использовании баз данных и языков пользователей. При
этом пользователь способен самостоятельно модифицировать базы
данных и языки, варьировать диалоговыми возможностями. В этих
АРМ отсутствует база знаний, т.е. невозможно накопление правил,
обеспечивающих объяснение того или иного свойства управляемого
объекта. База знаний как составной компонент входит в АРМ фак-
тологического типа. Фактологические АРМ полезны там, где работа
в условиях АРМ определяется преимущественно накапливаемым опы-
том и логическим выводом на его основе. Выделим несколько основных функций, которые должны
быть реализованы в рамках автоматизации организационного управ-
ления: интерпретация (анализ и описание данных и фактов из
предметной области для установления их взаимосвязей и систем); - - диагностика (поиск, определение и описание состояния
управляемого объекта); мониторинг (непрерывное отслеживание функционирования
АРМ и фиксирование получаемых результатов); планирование (обеспечение заданной последовательности
действий); проектирование (обеспечение пользовательских интер-
фейсов и развития). 2.6. Обзор существующих БД. Современныые СУБД основываются на использовании моде-
лей данных (МД), позволяющих описывать объекты предметных об-
ластей и взаимосвязи между ними. Существуют три основные МД и
их комбинации, на которых основываются СУБД: реляционная модель
данных (РМД), сетевая модель данных (СМД), иерархическая модель
данных (ИМД). Основное различие между этими моделями данных состоит
в способах описания взаимодействий между объектами и атрибута-
ми. Взаимосвязь выражает отношение между множествами данных.
Используют взаимосвязи "один к одному", "один ко многим" и
"многие ко многим". "Один к одному" - это взаимно однозначное
соответствие, которое устанавливается между одним объектом и
одним атрибутом. Hапример, в определенный момент времени в од-
ной ЭВМ используется один определенный процессор. Hомеру выб-
ранной ЭВМ соответствует номер выбранного процессора. "Многие
ко многим" - это соответствие между многими объектами и многими
атрибутами. Hапример, на множество ЭВМ может одновременно рабо-
тать множество пользователей. Взаимосвязи между объектами и ат-
рибутами удобно представлять в виде графов и гиперграфов. Рассмотрим эти модели данных более подробно. 2.6.1. Реляционная модель данных. Hа ПЭВМ в основном используют СУБД поддерживающие ре-
ляционную модель данных. В соответствии с реляционной моделью
база данных представляется в виде совокупности таблиц, над ко-
торыми могут выполняться операции, формулируемые в терминах ре-
ляционной алгебры и реляцонного исчисления. В реляционной моде-
ли операции над объектами базы данных имеют теоретико-множест-
венный характер. Пусть задан набор множеств D1,...,Dk. Декартовым про- - -
изведением доменов D1, D2,...,Dk (обозначается как D1 x D2 x
... x Dk) называется множество всех кортежей (v1, v2, ...,vk)
длины k, таких, что, v1 принадлежит D1, v2 принадлежит D2 и
т.д. Х(D1,...,Dk) = {(d1,...,dk) / dicDi}
Hапример, если k=2, D1 = {0,1}, и D2 = {a,b,c}, то D1 x D2 есть
{(0,a), (0,b), (0,c), (1,a), (1,b), (1,c)}. Отношением называется некоторое подмножество декартова
произведения одного или более доменов. Удобно представлять от-
ношение как таблицу, где каждая строка есть кортеж и каждый
столбец является атрибутом. Домены - это подмножество значений
атрибута. Кортежи - это упорядоченные множества. Столбцы табли-
цы - это элементы данных, а строки - записи. Hапример на рис.1 представлено отношение с атрибутами:
город, штат, население. Арность этого отношения равна 3. ( Майами, Оклахома, 13880) - есть кортеж. город і штат і население ДДДДДДДДДДДДДДДДДДДЕДДДДДДДДДДДДДДДДДДЕДДДДДДДДДДДДДДДДДДДД Сан-Диего і Техас і 4490 Майами і Оклахома і 13880 Питтсбург і Айова і 509 Отношение может быть представлено в виде файла. Записи
файла состоят из полей, соответствующих атрибутам в схеме отно-
шения. Многие языки определения данных, основанные на реляцион-
ной модели, дают пользователю возможность специфицировать орга-
низацию файла. Пользователь может выбрать хеширование (записи в
файле разделены между участками, каждый из которых содержит
один или более блоков памяти) или индексирование. Для отношений
с небольшим числом кортежей, иная альтернатива - "куча". В этом
случае кортежи перечисляются как записи в файле без определен-
ного порядка. Многие реляционные языки манипулироания данными пре-
доставляют пользователю возможность специфицировать по своему - -
усмотрению вторичные индексы по некоторым атрибутам или мно-
жествам атрибутов. Реляционный язык определения данных обеспечивает меха-
низм для спецификации одного атрибута или их множества в ка-
честве ключа отношения. Отношение не должно иметь двух кортежей
в которых совпадают все атрибуты ключа. Атрибуты, которые обра-
зуют отношения служат также и ключом для файла. Основными операциями, с помощью которых модифицируется
база данных, являются: включение, удаление и модификация. Эти
операции применяются к кортежам. Основное достоинство реляционного подхода - его
простота и доступность. Пользователи абстрагированы от физи-
ческой структуры памяти. Это позволяет эксплуатировать БД без
знания методов и способов ее построения. Основные достоинства
РМД следующие: простота, независимость данных; гибкость;непро-
цедурные запросы, теоретическое обоснование на основе теории
отношений. Это дает возможность пользователям формировать их
запросы более компактно, в терминах более крупных агрегатов. Hо при таком подходе возникают и проблемы связанные с
обеспечением достаточно высокого уровня производительности СУБД
этого класса. Этот вопрос решается разработчиками СУБД. Другая
проблема возникает, когда нужно обеспечить интерфейс СУБД, под-
держивающий реляционную модель данных, с традиционными языками
программирования. Она заключается в несоответствии структур
данных модели и языков такого типа, ориентированных на "поза-
писную" обработку. Для ее решения приходится дополнять модель
данных специальными согласующими типами объектов. 2.6.2. Сетевые базы данных. Концептуально сетевая модель данных замышлялась как
инструмент для пользователей баз данных - программистов. В свя-
зи с этим в СМД больше внимания уделяется структуризации дан- - -
ных, чем развитию ее операционных возможностей. В СМД элементарные данные и отношения между ними
представляются в виде ориенированной сети (вершины - данные,
дуги - отношения). Рассмотрим "классическую" сетевую модель данных
CODASYL. Основные "строительные блоки" структуры сетевой базы
данных - тип записи и тип набора. Тип записи представляет собой
множество записей, обладающих структурой и другими свойствами,
специфицированными в описании данного типа записей в схеме базы
данных для всех записей этого типа. Запись - совокупность логически связанных полей, ха-
рактеризуется именем и полями, входящими в нее. Полем называ-
ется единая неделимая единица информации, которая характеризу-
ется идентификатором, типом и размером. Помещенная в базу данных запись может существовать в
ней не только самостоятельно, но и являться одновременно де-
тальной или главной записью каких-либо наборов в зависимости от
того, описан ли ее тип в схеме базы данных как тип главной за-
писи или детальной записи каких-либо типов наборов. В записях могут содержаться производные элемены дан-
ных, значения которых зависят от значений других элементов дан-
ных той же записи, значения элемента данных в главной записи
какого-либо набора, в который входит данная запись. Они могут
являться также значением указанной процедуры. Тип набора сетевой модели представляет собой множество
наборов, обладающих структурой и другими свойствами, специфици-
рованными в схеме базы данных для этого типа набора. Hаборы СМД
служат для представления отношений вида 1:n между главными за-
писями и детальными записями одного или нескольких типов. Каждый экземпляр набора состоит из одного экземпляра
записи, называемой главной записью набора, и в общем случае ди-
намически изменяющегося при обновлениях базы данных множества
записей, называемых детальными записями набора. - - Главная и детальная записи данного набора связываются
с помощью указателей в цепь и образуют упорядоченную последова-
тельность. Могут быть предусмотрены дополнительные указатели,
связывающие каждую детальную запись набора непосредственно с
ее главной записью, а также указатели, обеспечивающие обход за-
писей набора в обратном направлении. Типы главных и детальных
записей наборов данного типа объявляются в описании этого типа
набора в схеме. Каждый экземпляр главной записи набора, появля-
ясь в базе данных, порождает экземпляр набора этого типа. Главные и детальные записи одних наборов могут быть
одновременно главными и/или детальными записями других наборов
того же самого или иных типов. Таким образом, из записей базы
данных и наборов может быть сконструирована база данных произ-
вольно сложной стркутуры. Пример: институт ЪДДДДДДДВДДДДДДДї ДДДДДДДДДДДДДДґ МГИЭМ і Быков ГДДДДДДДДДДДДДД і АДДДДДДДБДДДДДДДЩ і ЪДДБДДї ЪДДБДДї і АВТ і і ФЭТ і АДДВДДЩ АДДВДДЩ і ЪДДДДДї ЪДДДДДї і ДДДДДДДДДДДДґ РТФ ГДДДДДДДДДДДДДДДДДґ ФПМ ГДДД ДДДДАДДДДДБДДДДД АДДДДДЩ ЪДБДї ЪДБДї і Р і і Л і АДВДЩ АДВДЩ і ЪДДДДї ЪДДДДї і ДДґ АП ГДДДДґ ЭП ГДД АДДДДЩ АДДДДЩ набор: факультеты; главная запись: институт; детальная запись: АВТ, РТФ, ФПМ, ФЭТ; - - набор: специальность; главная запись: РТФ; детальная запись: Р, АП, ЭП, Л; запись: институт; поля: МГИЭМ, Быков. В ЯМД сетевой модели важное значение имеет концепция
текущего состояния в базе данных. Для каждой из прикладных
программ, параллельно взаимодействующих с базой данных, СУБД
должна поддерживать ее собстевенный комплект индикаторов теку-
щего состояния. На уровне схемы базы данных операционные возможности
сетевой модели данных, называемые базисными функциями манипули-
рования данными, имеют концептуальный характер. Операции здесь
непосредственно не могут быть активизированы. Операции над данными в базе данных на уровне подсхемы
предусматривают возможности перемещения по структуре базы дан-
ных и изменение индикаторов текущего состояния, запоминание и
обновление записей, их удаление из базы данных, включение и
исключение детальных записей из наборов, переключение записи из
одного набора данного типа в другой, переупорядочение записей в
наборе, нахождение в базе данных конкретной записи данного типа
и некоторой детальной записи набора, открытие и закрытие об-
ласти данных базы данных. Основное значение имеет то, что предусматривается од-
новременная обработка только одиночных объектов данных из базы
данных - записей, полей записей базы данных. Типичные операции
в сетевой модели: найти следующую запись данного типа и сделать
ее текущей, извлечь текущую запись в буфер прикладной программы
для обработки, заменить в извлеченной записи значения указанных
элементов данных на заданные новые их значения, запомнить за- - -
пись из буфера в базе данных. Основные достоинства СМД - наличие реализованных СУБД,
обеспечивающих эту модель, проста в реализации отношений "мно-
гие ко многим". Основной недостаток СМД - ее сложность. При ре-
организации БД возможна потеря независимости данных. 2.6.3. Иерархическая модель данных. ИМД основана на понятии деревьев, состоящих из вершин
и ребер. Вершина дерева ставится в соответствие совокупности
атрибутов данных, характеризующих некоторый объект. Вершины и
ребра дерева как бы образуют иерархическую древовидную структу-
ру, состояющую из n уровней. уровень 1 корневая вершина уровень 2 уровень n Первую вершину называют корневой вершиной. Она удово-
летворяет условиям: 1. Иерархия начинается с корневой вершины. 2. Каждая вершина соответствует одному или нескольким
атрибутам. 3. Hа уровнях с большим номером находятся зависимые
вершины. Вершина предшевствующего уровня является начальной для
новых зависимых вершин. 4. Каждая вершина, находящаяся на уровне i, соединена
с одной и только одной вершиной уровня i-1, за исключением кор- - -
невой вершины. 5. Корневая вершина может быть связана с одной или
нескольними зависимыми вершинами. 6. Доступ к каждой вершине происходит через корневую
по единственному пути. 7. Существует произвольное количество вершин каждого
уровня. Иерархическая модель данных состоит из нескольких де-
ревьев, т.е. является лесом. Каждая корневая вершина образует
начало записи логической базы данных. В ИМД вершины, находящи-
еся на уровне i, называют порожденными вершинами на уровне i-1. уровень 1 институт корневая МГИЭМ Быков вершина уровень 2 РТФ порожденная радиотехнический Пожидаев вершина Операции в ИМД имеют аналагичный СМД "позаписный" ха-
рактер. Аппарат преремещения по структуре в графовых моделях
служит для установки тех объектов данных, к которым будет при-
меняться очередная операция манипулирования данными. Такие объ-
екты называются текущими. Механизмы доступа к данным и переме-
щения по структуре данных в таких моделях достаточно сложны и
существенным образом опираются на концпцию текущего состояния
механизма доступа. Основные достоинства ИМД: простота построения и
использования, обеспечение определенного уровня независимости
данных, простота оценки операционных характеристик. Основные
недостатки: отнешение "многие ко многим" реализуется очень
сложно, дает громоздкую структуру и требует хранения избыточных
данных, что особенно нежелательно на физическом уровне, иерар-
хическая упорядоченность усложняет операции удаления и включе-
ния, доступ к любой вершине возможен только через корневую, что
увеличивает время доступа. Рассмотрим некоторые СУБД, разработанные на одной из - -
трех моделей данных. К числу СУБД иерархического типа можно отнести
PC/Focus, Team-Up, Data Edge, а также разработанную в нашей
стране систему HИКА, преемницу широко распространенной со-
ветской системы ИHЕС для ЕС ЭВМ.[4] Среди сетевых систем одной из наиболее популярных яв-
ляется СУБД db_Vista Ш(Ramia Corp.). Модель данных этой системы
пердставляет собой упрощенную сеть CODASYL, в которой полностью
исключены автоматические механизмы перемещения по структуре ба-
зы данных. Другие известные премеры сетевых систем - MDBS-Ш
фирмы mdbs Inc, системы Q-Pro и Zim. Большинство СУБД для персональных ЭВМ составляют
системы поддерживающие реляционную модель данных. К этому
классу следует отнести самую распространенную на ПЭВМ систему
dBase фирмы Ashton-Tate Corp.(версии dBaseП, dBaseШ, dBaseШ
PLUS, dBaseIV) и многочисленное семейство совметимых с нею
программных продуктов - FoxBase+ и FoxPro фирмы Fox Software,
Clipper'87 фирмы Nantucket Corp., QuickSilver и dBXL фирмы
Wordtech, User Interfase фирмы WallSoft Systems Inc., dBFast
фирмы dBFast Inc. Широко распространены также реляционные
системы Oracle фирмы Oracle Corp., Paradox фирмы Borland
International, ряд версий системы R:base 4000, R:base 5000,
R:base System V, R:base for DOS, R:base 3.0)фирмы Microrim,
система DB2 фирмы IBM Corp. Главные проблемы при реализации РМД на ПЭВМ связаны с
обеспечением приемлемого уровня производительности. Проводились
комплексы исследований, направленных на разработку эффективных
алгоритмов реализации реляционных операций и методов опримиза-
ции обработки запросов, а так же на создание специального обо-
рудования, предназначеного для поддержки реляционной модели
данных. Ориентация разработчиков программных средств баз дан-
ных для персональных ЭВМ на РМД определяется удобством этой мо- - -
дели для пользователя, рекламными соображениями - о досто-
инствах реляционной модели уже было хорошо известно, а также
сравнительной простотой ее реализации, особенно если не зани-
маться всерьез проблемами производительности. Реляционные системы для персональных ЭВМ заметно раз-
личаются набором тех реляционных операций, которые в них реали-
зованы. Во многих системах вообще не предусмотрены операции пе-
ресечения, объединения и разности отношений. Для выполнения
операции соединения отношений требуется, как правило, упорядо-
ченность кортежей отношения - второго операнда по ключу соеди-
нения, а в ряде случаев - использование для него индекса по та-
кому ключу как средства быстрого поиска подходящих кортежей во
втором операнде. Важным инструментом абстракции данных, обеспечивающим
возможности логической независимости данных в системах баз дан-
ных, являются механизмы представлений (View). В большинстве ре-
ляционных систем, и даже в таких широко распростаненных, как
dBaseШ PLUS и Paradox, явные механизмы представлений отсутству-
ют. В тоже время такие средства предусмотрены в СУБД R:base for
DOS, Oracle, DB2 . Использование представлений существенно об-
легчает разработку приложений, сокращает объем работ по реали-
зации и позволяет более экономично использовать ресурсы памяти,
конечно, за счет увеличения времени обработки запросов. Обычно в каждой системе предусматривается некоторая
комбинация примитивных типов данных. Чаще всего допускается
использование таких типов: числовые значения с фиксированной и
плавающей точкой, а также с двойной точностью, строковыые зна-
чения фиксированной длины (обычно до 255 литер), строковые зна-
чения переменной длины, булевские значения, значения в нацио-
нальных денежных единицах, даты и отметки времени. Предусматри-
вается также в случае использования соответствующих типов дан-
ных естественная арифметика дат, значений времени и денежных
величин. - - Возможность оперировать числами в формате с плавающей
точкой не предусматривается во многих распространенных СУБД,
например, dBase-совместимых системах. Это создает большие неу-
добства при их использовании в научных и инженерных приложениях. Важную роль в технологии баз данных играет концепция
неопределенного значения (NULL-value). Предполагается, что СУБД
располагает средствами, которые позволяют ей идентифицировать в
базе данных такие объекты (поля записей, атрибуты кортежей то-
ношений и т.д.), значения которых еще не были заданы пользова-
телем. Эта концепция не поддерживается в ряде коммерческих СУБД
для пресональных ЭВМ. Так, в базах данных системы dBaseШ PLUS
и совместимых с нею систем нельзя отличить неопределенное зна-
чение числового поля от значения "ноль", для литерного поля -
от строки пробелов, а для булевского - от значения "ложь". От
этого недостатка свободны системы Paradox и R:base for DOS. В теории систем баз данных большое внимание уделяется
средствам спецификации ограничений целостности данных как
составной части модели данных. Ограничения целостности рассмат-
риваются при этом как механизм моделирования семантики пердмет-
ной области в базах данных. Hужно отметить, что возможности спецификации весьма
примитивны. Обычно они ассоциируются не с объектами базы дан-
ных, а с командами ввода или с полями форм ввода-вывода. При
этом могут поддерживаться лишь простейшие ограничения. Hапри-
мер, для данных количественных типов (числа, даты. денежные ве-
личины) используются, как правило, ограничения, специжицирующ-
щие возможные диапазоны изменения, а для литерных строк - шаб-
лоны представления значений. В системе Clipper'87 эти возможности были усилены. До-
пускается использование для верификации данных в команде ввода
значения специфицированных пользователем функций. Аналогично в
dBaseIV с окнами форм ввода-вывода могут ассоциироваться огра-
ничения, заданные пользовательскими процедурами произвольного - -
характера. Однако ограничения такого вида, ассоциируемые лишь с
процессами ввода данных, не позволяют контролировать нарушения
целостности базы данных "изнутри" - в процессах обработки зап-
росов, а также поддерживать соотношения, связывающие значения
множества различных компонентов базы данных. Более того, подоб-
ного рода механизмы не дают возможности поддерживать более или
менее нетривиальные зависимости допустимых множеств вводимых
значений от состояния базы данных. Так, в dBase-совместимых
системах нет эффективных средств, позволяющих поддерживать пер-
вичный ключ отношений. Дубликаты кортежей включаются в отноше-
ние, хотя индекс по значениям такого ключа с параметром UNIQUE
и позволяет "спрятать" их от пользователя. Исключением является система R:base for DOS. В ней не
только поддерживаются первичные ключи отношений (таблиц), но и
предусмотрены средства спецификации довольно сложных ограниче-
ний целостности, называемых правилами и ассоциируемых с атрибу-
тами отношений. Их аргумент может быть множество значений атри-
бутов в кортежах одного или нескольких отношений. Проверка та-
ких ограничений осуществляется при выполнении всевозможных опе-
раций обновления данных в базе данных независимо от того, выз-
ваны ли они процессами ввода данных или внутрисистемными опера-
циями. Аналогичные средства предусмотрены в системе ПАЛЬМА-ПК. Обзор существующих БД. Современныые СУБД основываются на использовании моделей данных (МД), позволяющих описывать объекты предметных областей и взаимосвязи между ними. Существуют три основные МД и их комбина- ции, на которых основываются СУБД: реляционная модель данных (РМД), сетевая модель данных (СМД), иерархическая модель данных (ИМД). Основное различие между этими моделями данных состоит в способах описания взаимодействий между объектами и атрибутами. Взаимосвязь выражает отношение между множествами данных. Исполь- зуются взаимосвязи "один к одному", "один ко многим" и "многие ко многим". "Один к одному" - это взаимно однозначное соответс- твие, которое устанавливается между одним объектом и одним атри- бутом. Hапример, в определенный момент времени в одной ЭВМ ис- пользуется один определенный процессор. Hомеру выбранной ЭВМ соответствует номер выбранного процессора. "Один ко многим"- од- но-многозначное соответствие, которое устанавливается между од- ним объектом и многими атрибутами. Например, один пользователь для решения различных задач использует различные языки програм- мирования."Многие ко многим" - это соответствие между многими объектами и многими атрибутами. Hапример, на множество ЭВМ может одновременно работать множество пользователей. Взаимосвязи между объектами и атрибутами удобно представлять в виде графов и ги- перграфов. В основе реляционной модели лежит математическое понятие теоретико-множественного отношения, которое представляет собой подмножество декартова произведения списка доменов. Домен- это просто множество значений. Пусть задан набор доменов D1,...,Dk. Декартовым произведе- нием доменов D1, D2,...,Dk (обозначается как D1 x D2 x ... x Dk) называется множество всех кортежей (v1, v2, ...,vk) длины k, та- ких, что, v1 принадлежит D1, v2 принадлежит D2 и т.д. Х(D1,...,Dk) = {(d1,...,dk) / dicDi} Hапример, если k=2, D1 = {0,1}, и D2 = {a,b,c}, то D1 x D2 есть {(0,a), (0,b), (0,c), (1,a), (1,b), (1,c)}. Отношением называется некоторое подмножество декартова про- изведения одного или более доменов. Удобно представлять отноше- ние как таблицу, где каждая строка- это кортеж, а каждый столбец является атрибутом. Домены - это подмножество значений атрибута. Кортежи - это упорядоченные множества. Столбцы таблицы - это элементы данных, а строки - записи. Hапример на рис.1 представлено отношение с атрибутами: го- род, штат, население. ( Майами, Оклахома, 13880) - есть кортеж. город і штат і население ДДДДДДДДДДДДДДДДДДДЕДДДДДДДДДДДДДДДДДДЕДДДДДДДДДДДДДДДДДДДД Сан-Диего і Техас і 4490 Майами і Оклахома і 13880 Питтсбург і Айова і 509 Рис.1. Пример отношения. Отношение может быть представлено в виде файла. Записи фай- ла состоят из полей, соответствующих атрибутам в схеме отноше- ния. Многие языки определения данных, основанные на реляционной - 2 - модели, дают пользователю возможность специфицировать организа- цию файла. Пользователь может выбрать хеширование (записи в фай- ле разделены между участками, каждый из которых содержит один или более блоков памяти) или индексирование. Для отношений с не- большим числом кортежей, иная альтернатива - "куча". В этом слу- чае кортежи перечисляются как записи в файле без определенного порядка. Сетевые модели данных базируются на табличных и графовых представлениях: вершинам графа обычно сопоставляются некоторые типы сущности, которые представляются таблицами, а дугам- типы связей. Наиболее развитойй сетевой моделью данных является мо- дель, предложенная в отчете (апрель 1971 г.) Рабочей группы по базам данных (РГБД) Ассоциации по языкам систем обработки данных (CODASYL), спецификации которой впоследствии неоднократно перес- матривались. Помимо определения модели данных создатели первона- чального отчета преследовали также цель обеспечить включение ее средств в Кобол. В СМД элементарные данные и отношения между ними представ- ляются в виде ориенированной сети (вершины - данные, дуги - от- ношения). Рассмотрим "классическую" сетевую модель данных CODASYL. Основные "строительные блоки" структуры сетевой базы данных - тип записи и тип набора. Тип записи представляет собой множество записей, обладающих структурой и другими свойствами, специфици- рованными в описании данного типа записей в схеме базы данных для всех записей этого типа. Запись - совокупность логически связанных полей, характери- зуется именем и полями, входящими в нее. Полем называется единая неделимая единица информации, которая характеризуется идентифи- катором, типом и размером. Помещенная в базу данных запись может существовать в ней не только самостоятельно, но и являться одновременно детальной или главной записью каких-либо наборов в зависимости от того, описан ли ее тип в схеме базы данных как тип главной записи или деталь- ной записи каких-либо типов наборов. Тип набора сетевой модели представляет собой множество на- боров, обладающих структурой и другими свойствами, специфициро- ванными в схеме базы данных для этого типа набора. Hаборы СМД служат для представления отношений вида 1:n между главными запи- сями и детальными записями одного или нескольких типов. Каждый экземпляр набора состоит из одного экземпляра запи- си, называемой главной записью набора, и в общем случае динами- чески изменяющегося при обновлениях базы данных множества записей, называемых детальными записями набора. Главная и детальная записи данного набора связываются с по- мощью указателей в цепь и образуют упорядоченную последователь- ность. Могут быть предусмотрены дополнительные указатели, связы- вающие каждую детальную запись набора непосредственно с ее главной записью, а также указатели, обеспечивающие обход записей набора в обратном направлении. Типы главных и детальных записей наборов данного типа объявляются в описании этого типа набора в схеме. Каждый экземпляр главной записи набора, появляясь в базе данных, порождает экземпляр набора этого типа. Главные и детальные записи одних наборов могут быть однов- ременно главными и/или детальными записями других наборов того же самого или иных типов. Таким образом, из записей базы данных и наборов может быть сконструирована база данных произвольно сложной стркутуры. - 3 - институт ЪДДДДДДДВДДДДДДДї ЪДДДДДДДДДДДДДДґ МГИЭМ і Быков ГДДДДДДДДДДДДДДї і АДДДДДДДБДДДДДДДЩ і ЪДДБДДї ЪДДБДДї і АВТ і і ФЭТ і АДДВДДЩ АДДВДДЩ і ЪДДДДДї ЪДДДДДї і АДДДДДДДДДДДДґ ФИТ ГДДДДДДДДДДДДДДґ ФПМ ГДДДДДЩ АДДВДДЩ АДДДДДЩ ЪДДДДДДДДДДБДДДДДДДДДДї ЪДБДї ЪДБДї і Р і і Л і АДВДЩ АДВДЩ і ЪДДДДї ЪДДДДї і АДДґ АП ГДДДДґ ЭП ГДДДЩ АДДДДЩ АДДДДЩ Рис.2. Пример БД сетевой структуры. набор: факультеты; главная запись: институт; детальная запись: АВТ, РТФ, ФПМ, ФЭТ; набор: специальность; главная запись: РТФ; детальная запись: Р, АП, ЭП, Л; запись: институт; поля: МГИЭМ, Быков. Иерархическая модель данных (ИМД) основана на понятии де- ревьев, состоящих из вершин и ребер. Вершина дерева ставится в соответствие совокупности атрибутов данных, характеризующих не- который объект. Вершины и ребра дерева как бы образуют иерархи- ческую древовидную структуру, состояющую из n уровней. уровень 1 институт корневая ЪДДДДДДДВДДДДДДДї вершина і МГИЭМ і Быков і АДДДДДДДЕДДДДДДДЩ ЪДДДДДДДДВДДДБДДДДВДДДДДДДДї уровень 2 ЪДДБДДї ЪДДБДДї ЪДДБДДї ЪДДБДДї порожденные і АВТ і і ФИТ і і ФПМ і і ФЭТ і вершины АДДДДДЩ АДДВДДЩ АДДДДДЩ АДДДДДЩ уровня 1 ЪДДДДДВДБДДВДДДДДї уровень 3 ЪДБДїЪДДБДїЪДБДДїЪДБДї порожденные і Р іі АП іі ЭП іі Л і вершины АДДДЩАДДДДЩАДДДДЩАДДДЩ уровня 2 Рис.3. Пример БД иерархической древовидной структуры. Первую вершину называют корневой вершиной. Она удоволетво- ряет условиям: 1. Иерархия начинается с корневой вершины. 2. Каждая вершина соответствует одному или нескольким атри- бутам. 3. Hа уровнях с большим номером находятся зависимые верши- ны. Вершина предшевствующего уровня является начальной для новых зависимых вершин. 4. Каждая вершина, находящаяся на уровне i, соединена с од- - 4 - ной и только одной вершиной уровня i-1, за исключением корневой вершины. 5. Корневая вершина может быть связана с одной или несколь- ними зависимыми вершинами. 6. Доступ к каждой вершине происходит через корневую по единственному пути. 7. Существует произвольное количество вершин каждого уров- ня. Иерархическая модель данных состоит из нескольких деревьев, т.е. является лесом. Каждая корневая вершина образует начало за- писи логической базы данных. В ИМД вершины, находящиеся на уров- не i, называют порожденными вершинами на уровне i-1. Реляционные базы данных. Hа ПЭВМ в основном используют СУБД, поддерживающие реляци- онную модель данных. Это объясняется тем, что реляционная модель обладает дескрипторной мощностью других моделей при меньшем чис- ле базисных понятий. В соответствии с реляционной моделью база данных представляется в виде совокупности таблиц, над которыми могут выполняться операции, формулируемые в терминах реляционной алгебры и реляционного исчисления. Многие реляционные языки манипулирования данными предостав- ляют пользователю возможность специфицировать по своему усмотре- нию вторичные индексы по некоторым атрибутам или множествам ат- рибутов. Реляционный язык определения данных обеспечивает механизм для спецификации одного атрибута или их множества в качестве ключа отношения. Отношение не должно иметь двух кортежей, в ко- торых совпадают все атрибуты ключа. Атрибуты, которые образуют отношения, служат также и ключом для файла. Основными операциями, с помощью которых модифицируется база данных, являются: включение, удаление и модификация. Эти опера- ции применяются к кортежам. Основное достоинство реляционного подхода - его простота и доступность. Пользователи абстрагированы от физической структуры памяти. Это позволяет эксплуатировать БД без знания методов и способов ее построения. Основные достоинства РМД следующие: простота, независимость данных; гибкость;непроцедурные запросы, теоретическое обоснование на основе теории отношений. Это дает возможность пользователям формировать их запросы более компакт- но, в терминах более крупных агрегатов. Hо при таком подходе возникают и проблемы, связанные с обеспечением достаточно высокого уровня производительности СУБД этого класса. Этот вопрос решается разработчиками СУБД. Другая проблема возникает, когда нужно обеспечить интерфейс СУБД, под- держивающий реляционную модель данных, с традиционными языками программирования. Она заключается в несоответствии структур дан- ных модели и языков такого типа, ориентированных на обработку "по записям". Для ее решения приходится дополнять модель данных специальными согласующими типами объектов. Большинство СУБД для персональных ЭВМ составляют системы, поддерживающие реляционную модель данных. К этому классу следует отнести самую распространенную на ПЭВМ систему dBase фирмы Ashton-Tate Corp.(версии dBaseП, dBaseШ, dBaseШ PLUS, dBaseIV) и многочисленное семейство совметимых с нею программных продуктов - FoxBase+ и FoxPro фирмы Fox Software, Clipper'87 фирмы Nantucket Corp., QuickSilver и dBXL фирмы Wordtech, User Interfase фирмы WallSoft Systems Inc., dBFast фирмы dBFast Inc. - 5 - Широко распространены также реляционные системы Oracle фирмы Oracle Corp., Paradox фирмы Borland International, ряд версий системы R:base 4000, R:base 5000, R:base System V, R:base for DOS, R:base 3.0)фирмы Microrim, система DB2 фирмы IBM Corp. Главные проблемы при реализации РМД на ПЭВМ связаны с обес- печением приемлемого уровня производительности. Проводились комплексы исследований, направленных на разработку эффективных алгоритмов реализации реляционных операций и методов опримизации обработки запросов, а также на создание специального оборудова- ния, предназначенного для поддержки реляционной модели данных. Ориентация разработчиков программных средств баз данных для персональных ЭВМ на РМД определяется удобством этой модели для пользователя, рекламными соображениями - о достоинствах реляци- онной модели уже было хорошо известно, а также сравнительной простотой ее реализации, особенно если не заниматься всерьез проблемами производительности. Реляционные системы для персональных ЭВМ заметно различают- ся набором тех реляционных операций, которые в них реализованы. Во многих системах вообще не предусмотрены операции пересечения, объединения и разности отношений. Для выполнения операции соеди- нения отношений требуется, как правило, упорядоченность кортежей отношения - второго операнда по ключу соединения, а в ряде слу- чаев - использование для него индекса по такому ключу как средс- тва быстрого поиска подходящих кортежей во втором операнде. Важным инструментом абстракции данных, обеспечивающим воз- можности логической независимости данных в системах баз данных, являются механизмы представлений (View). В большинстве реляцион- ных систем, и даже в таких широко распростаненных, как dBaseШ PLUS и Paradox, явные механизмы представлений отсутствуют. В то- же время такие средства предусмотрены в СУБД R:base for DOS, Oracle, DB2 . Использование представлений существенно облегчает разработку приложений, сокращает объем работ по реализации и позволяет более экономично использовать ресурсы памяти, конечно, за счет увеличения времени обработки запросов. Обычно в каждой системе предусматривается некоторая комби- нация примитивных типов данных. Чаще всего допускается использо- вание таких типов: числовые значения с фиксированной и плавающей точкой, а также с двойной точностью, строковыые значения фикси- рованной длины (обычно до 255 литер), строковые значения пере- менной длины, булевские значения, значения в национальных денеж- ных единицах, даты и отметки времени. Предусматривается также в случае использования соответствующих типов данных естественная арифметика дат, значений времени и денежных величин. Возможность оперировать числами в формате с плавающей точ- кой не предусматривается во многих распространенных СУБД, напри- мер, dBase-совместимых системах. Это создает большие неудобства при их использовании в научных и инженерных приложениях. Важную роль в технологии баз данных играет концепция неоп- ределенного значения (NULL-value). Предполагается, что СУБД рас- полагает средствами, которые позволяют ей идентифицировать в ба- зе данных такие объекты (поля записей, атрибуты кортежей тоношений и т.д.), значения которых еще не были заданы пользова- телем. Эта концепция не поддерживается в ряде коммерческих СУБД для пресональных ЭВМ. Так, в базах данных системы dBaseШ PLUS и совместимых с нею систем нельзя отличить неопределенное значение числового поля от значения "ноль", для литерного поля - от стро- ки пробелов, а для булевского - от значения "ложь". От этого не- достатка свободны системы Paradox и R:base for DOS. В теории систем баз данных большое внимание уделяется - 6 - средствам спецификации ограничений целостности данных как сос- тавной части модели данных. Ограничения целостности рассматрива- ются при этом как механизм моделирования семантики пердметной области в базах данных. Hужно отметить, что возможности специфи- кации весьма примитивны. Обычно они ассоциируются не с объектами базы данных, а с командами ввода или с полями форм ввода-вывода. При этом могут поддерживаться лишь простейшие ограничения. Hап- ример, для данных количественных типов (числа, даты. денежные величины) используются, как правило, ограничения, специфицирую- щие возможные диапазоны изменения, а для литерных строк - шабло- ны представления значений. В системе Clipper'87 эти возможности были усилены. Допуска- ется использование для верификации данных в команде ввода значения специфицированных пользователем функций. Аналогично в dBaseIV с окнами форм ввода-вывода могут ассоциироваться ограни- чения, заданные пользовательскими процедурами произвольного ха- рактера. Однако ограничения такого вида, ассоциируемые лишь с про- цессами ввода данных, не позволяют контролировать нарушения целостности базы данных "изнутри" - в процессах обработки запро- сов, а также поддерживать соотношения, связывающие значения мно- жества различных компонентов базы данных. Более того, подобного рода механизмы не дают возможности поддерживать более или менее нетривиальные зависимости допустимых множеств вводимых значений от состояния базы данных. Так, в dBase-совместимых системах нет эффективных средств, позволяющих поддерживать первичный ключ от- ношений. Дубликаты кортежей включаются в отношение, хотя индекс по значениям такого ключа с параметром UNIQUE и позволяет "спря- тать" их от пользователя. Исключением является система R:base for DOS. В ней не толь- ко поддерживаются первичные ключи отношений (таблиц), но и предусмотрены средства спецификации довольно сложных ограничений целостности, называемых правилами и ассоциируемых с атрибутами отношений. Их аргументом может быть множество значений атрибутов в кортежах одного или нескольких отношений. Проверка таких огра- ничений осуществляется при выполнении всевозможных операций об- новления данных в базе данных независимо от того, вызваны ли они процессами ввода данных или внутрисистемными операциями. Анало- гичные средства предусмотрены в системе ПАЛЬМА-ПК. Система CLIPPER. CLIPPER - это созданная фирмой Nantucket Corp. система программирования приложений в среде БД, включающая в себя быст- рый компилятор программ, написанных на языке, близком к языку СУБД dBaseIII PLUS, редактор связей, развитый интерактивный сим- волический отладчик, обладающий пользовательским интрефейсом в стиле меню, который можно связать с разрабатываемой программой для облегчения ее отладки, большую библиотеку объектных модулей системных функций, а также ряд служебных программ (утилит). Система Clipper представляет собой, по существу, СУБД ком- пилирующего типа с автономным (self-contained) языком, в значи- тельной мере совместимую по входному языку программирования и организации базы данных с СУБД dBaseIII PLUS. Основная цель раз- работки этого програмного продукта - достижение более высокой производительности прикладных систем по сравнению с созданными с помощью средств dBaseIII PLUS. Эта задача решается благодаря ис- пользованию на стадии исполнения заранее скомпилированного кода вместо интерпретации исходных программ, а также за счет более - 7 - эффективных механизмов индексирования файлов БД. Clipper работает в среде операционной системы MS DOS версии 2.0 и выше. В результате компиляции текстов программ на исходном языке он порождает загрузочные программные модули, не требующие каких-либо системных средств на стадии исполнения. Тем самым разработанная прикладная программа полностью "отчуждается" от инструментальных средств его разработки, может распространяться независимо от них, и пользователь такой программы избавляется от необходимости изучать этот инструментарий. Допускается декомпозиция программных модулей на составные части, из которых на стадии редактирования можно сформировать модули оверлейной структуры. Разработка крупных прикладных прог- рамм значительно облегчается благодаря технологии сепаратной компиляции их компонентов. Clipper обеспечивает высокую скорость не только при испол- нении программ, но и на стадии их компиляции. Система польностью совместима с системой dBaseIII PLUS по организации файлов БД. Однако индексные файлы в системе Clipper имеют иную более эффек- тивную организацию, что наряду с компиляцией способствует су- щественному повышению производительности программ на стадии ис- полнения. Индексные файлы dBaseIII PLUS подменяются файлами системы Clipper аналогичного назначения автоматически на стадии исполнения либо заблаговременно с помощью специальной утилиты. В языке программирования системы Clipper отсутствуют такие полноэкранные команды языка dBase, как ASSIST, BROWSE, EDIT, имеются ограничения на использование функции макроподстановки (&). Значением строковой переменной, к которой применяется эта функция, не может быть, в частности, полная команда или фраза команды с ключевым словом, а также список имен полей записи фай- ла БД или других объектов языка с разделителями-запятыми. Вместе с тем в язык введены многие расширения. К их числу (в летней версии 1987 г.) относятся возможности работы с массивами пере- менных, которые могут объявляться при необходитости глобальными величинами, спецификации функций, определяемых пользователем, возможности обращения к функциям на языках Си и ассемблере с пе- редачей им параметров, средства программирования пользователь- ских интерфейсов, построенных в стиле меню, сохранение и восста- новление изображений, показанных на экране, большое количество новых функций различного назначения, в частности, для операций- над строками. В языке Clipper предусматриваются средства блокирования файлов и записей файлов БД, необходимые для использования прог- рамм на этом языке в мультипользовательской среде сетевых систем БД. Введены новые синтаксические конструкции, например циклы FOR...NEXT, новая фраза VALID для верификации данных, вводимых с помощью команды GET, и ряд других. К пользовательской программе можно легко подключить проце- дуру HELP, обеспечивающую глобальную и контекстно-зависимую по- мощь. Эта процедура вызывается на стадии исполнения традиционным нажатием функциональной клавиши F1. При этом ей автоматически передаются необходимые параметры. Clipper включает, как уже указывалось, весьма богатые сис- темные библиотеки функций различного характера, существенно обо- гащающих язык, позволяющих значительно сокращать затраты времени на прикладное программирование и уменьшать объем исходного кода. В летней версии 1987 г. предусмотрено около ста различных функ- ций для анализа состояния системы, операций с массивами, для вы- числения элементарных математических функций, операций над стро- ками, редактирования данных, для создания файлов DOS и - 8 - выполнения операций над ними, работы со значениями полей типа Memo в записях фаийлов БД и для других целей. Кроме того, пользователь имеет возможность создавать и ис- пользовать собственные библиотеки функций. Что касается системных библиотек, то Nantucket Corp. посто- янно расширяет их состав. В 1988 г. был дополнительно включен ряд новых функций, кроме того, фирма начала поставлять пакет Clipper, предназначенный для использования совместно с системой Clipper. Пакет содержит большую новую структуризованную библио- теку функций и расширенный драйвер экранов и клавиатуры, приз- ванный заменить имеющийся в системе Clipper драйвер. Эти функции и драйвер могут вкючаться в программу на стадии редактирования. Все функции библиотеки обладают высокой производительностью и предъявляют минимальные требования к оперативной памяти. Они реализованиы на языке ассемблера и оптимизированы. Библиотека пакета включает ряд функций для конструирования многооконных пользовательских интерфейсов, для непосредственной работы с обо- рудованием, подлюченным к последовательному интерфейсу ПЭВМ, ми- нуя BIOS и обращения к DOS. Предусмотрена большая группа строковых функций, функций для преобразования числовых значений и битовых операций, операций над датами и временем, установки системных переключателей и по- лучения информации об их состоянии, а также о характеристиках и состоянии операционной обстановки, видеофункций, функций для ра- боты с дисками, файлами БД и принтером. Всего библиотека пакета включает более 270 различных функций. Важным достоинством системы Clipper является возможность использования дополнительной (свыше 640 Кбайт) памяти персональ- ного компьютера при исполнении разработанных его средствами п/п. Вместе с тем система Clipper обладает и существенным недос- татком - порождаемые ею загрузочные модули довольно велики по объему. Один из способов преодоления этого изъяна - предоставля- емые пакетом возможности конструирования программных модулей с оверлейной структурой. Однако как "цельнотянутый" загрузочный модуль, так и корневой сегмент модуля с оверлейной структурой не могут быть размером менее 110Кбайт, поскольку в них включаются все необходимые элементы системной среды и функции стадии испол- нения. К числу недостатков этого продукта следует, вероятно, от- нести также отсутствие комфортной среды для эффективной разра- ботки и отладки Clipper-программ. Имеется в виду среда подобная той, которой обладают, например, Турбосистемы программирования фирмы Borland Int. Входящий в состав системы Clipper символичес- кий отладчик является лишь одной из составных частей такой сре- ды. Проблему сокращения объема требуемой оперативной памяти и уменьшения размеров загрузочных модулей фирма Nantucket Corp. решила в новой версии системы - Clipper 5.0. Для этой цели в состав нового программного продукта включается динамический ре- дактор связей - загрузчик, основанный на механизмах виртуальной памяти и тем самым вообще исключающий необходимость использвания оверлейной структуры при создании больших программных модулей. Версия Clipper 5.0 обладает и другими важными достоинства- ми. Пользователь (программист-разработчик прикладных систем) мо- жет расширять язык новыми командами и благодаря этому формиро- вать множества команд, удобные для программирования специфических классов задач. Предусматриваются новые типы пере- менных, а также многомерные массивы. Разработана машинно-ориен- тированная документация, к которой возможен доступ в режиме - 9 - on-line с помощью Guide to Clipper или Norton Guide. Дополнительно в Clipper 5.0 введены предопределенные объек- ты, которые облегчают написание больших программ. К ним относят- ся: Error class - обработка ошибок во время выполнения программы. Get class - предоставляет объекты и классы для создания эк- ранных форм редактирования. Tbrowse class - предоставляет объект для табличного просмотра и редактирования базы данных. TColumn class - используется Tbrowse-объектом для работы со столбцами в таблице. Наиболее частым по использованию и в то же время наиболее мощным объектом можно считать Tbrowse-класс, использование кото- рого дает возможность не прилагая больших усилий реализовать табличный редактор, ассоциированный с какой-либо базой данных, что фактически является законченной прикладной программой. Система программирования Clipper (в частности версии 5.0) может быть использована в тех случаях, когда необходимо быстрое (по срокам) создание законченной прикладной программы, ориенти- рованной на обработку информации представленной в табличной фор- ме. Нежелательно применение системы для решения задач содержащих значительное количество вычислительных операций (особенно с пла- вающей точкой). Это объясняется символьным форматом хранения чи- сел, что приводит к значительному уменьшению скорости обработки информации за счет постоянного выполнения преобразований из сим- вольного представления во внутримашинный формат и наоборот, что естественно приводит к потере точности вычислений. Сетевые базы данных. Концептуально сетевая модель данных замышлялась как инструмент для пользователей баз данных - программистов. В связи с этим в СМД больше внимания уделяется структуризации данных, чем развитию ее операционных возможностей. В ЯМД сетевой модели важное значение имеет концепция теку- щего состояния в базе данных. Для каждой из прикладных программ, параллельно взаимодействующих с базой данных, СУБД должна под- держивать ее собстевенный комплект индикаторов текущего состоя- ния. На уровне схемы базы данных операционные возможности сете- вой модели данных, называемые базисными функциями манипулирования данными, имеют концептуальный характер. Операции здесь непосредственно не могут быть активизированы. Операции над данными в базе данных на уровне подсхемы пре- дусматривают возможности перемещения по структуре базы данных и изменение индикаторов текущего состояния, запоминание и обновле- ние записей, их удаление из базы данных, включение и исключение детальных записей из наборов, переключение записи из одного на- бора данного типа в другой, переупорядочение записей в наборе, нахождение в базе данных конкретной записи данного типа и неко- торой детальной записи набора, открытие и закрытие области дан- ных базы данных. Основное значение имеет то, что предусматривается одновре- менная обработка только одиночных объектов данных из базы данных - записей, полей записей базы данных. Типичные операции в сете- вой модели: найти следующую запись данного типа и сделать ее те- кущей, извлечь текущую запись в буфер прикладной программы для обработки, заменить в извлеченной записи значения указанных эле- - 10 - ментов данных на заданные новые их значения, запомнить запись из буфера в базе данных. Основные достоинства СМД - наличие реализованных СУБД, обеспечивающих эту модель, простота в реализации отношений "мно- гие ко многим". Основной недостаток СМД - ее сложность. При ре- организации БД возможна потеря независимости данных. Среди сетевых систем одной из наиболее популярных является СУБД db_Vista III(Raima Corp.). Модель данных этой системы представляет собой упрощенную сеть CODASYL, в которой полностью исключены автоматические механизмы перемещения по структуре базы данных. Другие известные премеры сетевых систем - MDBS-Ш фирмы mdbs Inc, системы Q-Pro и Zim. СЕТЕВАЯ СИСТЕМА DB_VISTA III Система dB_VISTA III - система управления базами данных фирмы Raima Corp., поддерживающая сетевую модель данных CODASYL. Она предназначена для создания и использования БД сложной струк- туры в рамках различных программных систем, реализованных на языке Си. Для них предоставляется интерфейс включающего языка. Кроме того, конечные пользователи могут получить интерактивный доступ к базе данных с помощью языка запросов SQL. Сама система dB_VISTA реализована на языке Си и благодаря этому является переносимой. Она может эксплуатироваться в среде операционных систем MS DOS, OS/2, UNIX, XENIX, ULTRIX, VMS и ря- да других на ПЭВМ IBM PC, PS/2, SUN и VAX. Для разработки прило- жений допускается использование Microsoft C, Lattice C, Turbo C и других компиляторов языка Си. Фирма поставляет как монопользо- вательскую, так и мультипользовательскую версии системы. Обеспе- чиваются быстрые методы доступа за счет использования комбинации наборов CODASYL и эффективных механизмов индексирования, осно- ванных на В-деревьях. Система поставляется в виде совокупности трех компонентов: собственно системы - библиотеки функций, которые обычным образом подключаются к Си-программе средствами компилятора и редактора связей, компонентов dB_Query и dB_Revise, а также ряда утилит для облегчения эксплуатации системы. Компонент dB_Query предоставляет пользователю возможность обращаться в интерактивном режиме с запросами к системе БД с по- мощью языка SQL и генерировать отчеты. Входящие в него функции реляционных запросов на языке Си могут быть встроены с помощью редактора связей в прикладную Си-программу. Компонент dB_Revise служит для реструктуризации БД и кон- версии существующих в ней данных в данные новой структуры. Утилиты системы позволяют инициализировать БД, проверять непротиворечивость данных в БД, просматривать и редактировать данные в записях БД в полноэкранном режиме, строить индексы по заданным ключам, выдавать отчеты для администратора БД, выводить дампы БД для восстановления ее при разрушениях, осуществлять об- мен данными между БД системы и ASCII-файлами. Сетевая модель данных CODASYL реализована в системе dB_Vista в весьма упрощенном режиме. В ней совершенно отсутству- ет автоматика, предусмотренная в подходе CODASYL, - автоматичес- кая навигация в структуре данных, селекция экземпляров наборов, поддержка автоматического членства записей в наборах, продуциро- вание производных элементов данных в экземплярах записей, расп- ространение удалений и изменений по структуре БД. В записях не могут использоваться повторяющиеся группы. Не предусматривается поддержка ограничений целостности данных, процедуры БД, механиз- - 11 - мы управления доступом. Не реализована концепция подсхемы. Реализация сетевой модели в db_VISTA. Определение записи в сетевой модели, аналогичное определе- нию записи в Паскале или описанию структуры в Си, используется для группировки связанных элементов данных. Эти определения за- писей используются СУБД для доступа и манипуляций связанными элементами данных как простыми объектами. В последующем обсужде- нии определение запись/набор будем называть "типом" записи/набо- ра, и будем считать, что запись/набор определенного типа в БД представляет собой "экземпляр" записи/набора. Набор определяет отношения между типами записей так, что один тип записи является "главной" одного или более типов запи- сей. Подчиненные записи назаваются "детальными". db_VISTA орга- низует наборы, включающие только один экземпляр главной записи и один или более экземпляров детальных записей. Такая цепь отноше- ний, являющаяся отношением "один ко многим", представляет собой соотношение одной главной записи к потенциально большему коли- честву экземпляров детальных записей. Связи в наборе реализуются в db_VISTA формированием двунап- равленного списка между экземплярами детальных записей и уста- новкой в главной записи указателей на начало и конец списка. Преимущество такого подхода в том, что db_VISTA прозволяет прог- раммисту организовать доступ ко всем этим указателям и цепям, предоставляя тем самым очень мощную, но простую по использованию возможность построения данных. Список указателей неявно размеща- ется в записях самой СУБД, базируясь на информации, содержащейся в таблицах словаря данных, созданных из спецификации DDL. Рисунок 4 показывает как db_VISTA представляет экземпляр набора. Прямоугольники представляют собой записи, а стрелки-ука- затели, содержащиеся в записях, организуемые самой СУБД. Каждая главная запись содержит указатели на первую и последнюю запись набора. В каждой детальной записи содержатся указатели на преды- дущую и последующую детальные записи и на главную запись набора. ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДї і указатель на указатель на і і начало набора ЙННННННННН» конец набора і і ЪДДДДДДДДДДДДДДДДДє Главная єДДДДДДДДДДДДДДДДДДДДДї і і і ЪДДДДДДДДДДДД>є запись єє Детальная єДДД> .. ДДД>є Детальная є і і є запись є є запись є є запись є і і є 1 є
proc pri_lec (kaf)
#include "box.ch"
#define
NULL 0
set
cursor off
clear
@ 5,5
say "Предмет "
@ 5,18
get pred
@ 7,5
say "Семестр "
@ 7,18
get ns
read
sele 10
use
&kaf+"np1"
go top
locate
for PREDM=pred .and. LEK>0 .and. Sem=ns
sele 11
use
&kaf+"npr"
go A_pr
lektor=Prep
sele 10
go top
locate
for PREDM=pred .and. Sem=ns
clear
@ 1,1
say "Предмет: "
@ 1,10
say pred
@ 2,1
say "Семестр: "
@ 2,10
say ns pict "999"
@ 3,1
say "ФИО лектора: "
@ 3,14
say lektor
@ 4,1
say "ЪДДДДДДДДДДДДДДДДДДДДВДДДДДДДДДДДДДДДДДДДДВДДДДДДДДДДДДДДДДДДДДВДДДДДДДДДДДДДДДДДДДДї"
@ 5,1
say "і Пр.занятия і
Лаборат. раб. і ИРС і
Курс.проектир. і"
@ 6,1
say
"ГДДДДДДДДДДДДДДДДДДДДЕДДДДДДДДДДДДДДДДДДДДЕДДДДДДДДДДДДДДДДДДДДЕДДДДДДДДДДДДДДДДДДДДґ"
i=7
do
while !eof()
*вывод
списка
sele 11
go A_pr
prepod=Prep
sele 10
if Pz>0
@ i,1 say "і"
@ i,3 say prepod
else
@ i,1 say "і"
endif
if Lba >0
@ i,22 say "і"
@ i,24 say prepod
else
@
i,22 say "і"
endif
if Irs >0
@ i,43 say "і"
@ i,45 say prepod
else
@ i,43 say "і"
endif
if Kur >0
@ i,64 say "і"
@ i,66 say prepod
@ i,85 say "і"
else
@ i,64 say "і"
@ i,85 say "і"
endif
i++
continue
enddo
@ i,1
say
"АДДДДДДДДДДДДДДДДДДДДБДДДДДДДДДДДДДДДДДДДДБДДДДДДДДДДДДДДДДДДДДБДДДДДДДДДДДДДДДДДДДДЩ"
@ i+1,5
say "Желаете вывести на печать [y\n] "
@
i+1,40 get otw
read
if otw
= "Y" .or. "y"
set print on
set devi to print
sele 10
go top
locate for PREDM=pred .and. Sem=ns
clear
@ 1,1 say "Предмет: "
@ 1,10 say pred
@ 2,1 say "Семестр: "
@ 2,10 say ns pict "999"
@ 3,1 say "ФИО лектора: "
@ 3,14 say lektor
@ 4,1 say "ЪДДДДДДДДДДДДДДДДДДДДВДДДДДДДДДДДДДДДДДДДДВДДДДДДДДДДДДДДДДДДДДВДДДДДДДДДДДДДДДДДДДДї"
@ 5,1 say "і Пр.занятия і Лаборат. раб. і ИРС і
Курс.проектир. і"
@ 6,1 say
"ГДДДДДДДДДДДДДДДДДДДДЕДДДДДДДДДДДДДДДДДДДДЕДДДДДДДДДДДДДДДДДДДДЕДДДДДДДДДДДДДДДДДДДДґ"
i=7
do while !eof()
*вывод
списка
sele 11
go A_pr
prepod=Prep
sele 10
if Pz>0
@ i,1 say "і"
@ i,3 say prepod
else
@ i,1 say "і"
endif
if Lba >0
@ i,22 say "і"
@ i,24 say prepod
else
@ i,22 say "і"
endif
if Irs >0
@ i,43 say "і"
@ i,45 say prepod
else
@ i,43 say "і"
endif
if Kur >0
@ i,64 say "і"
@ i,66 say prepod
@ i,85 say "і"
else
@ i,64 say "і"
@ i,85 say "і"
endif
i++
continue
enddo
endif
return
proc pri_ipl
(kaf)
#include "box.ch"
#define NULL 0
set cursor off
clear
@ 5,5
say "Преподаватель "
@ 5,22 get prepod
read
sele 10
use &kaf+"npr"
go top
locate for Prep=prepod
*проверить
на eof
if eof()
clear
@ 5,5 say "Ошибка ввода!!!"
endif
adr_p=recno()
sele 11
use &kaf+"np1"
locate for A_pr=adr_p
*печать
шапки таблицы
@ 1,1
say "Индивидуальный план преподавателя"
@ 1,40
say prepod
@ 2,1
say
"ЪДДДДДДДДДДДДДДДДДДВДДДДДДВДДДДДДДДВДДДДДДДДДДДДДВДДДДДДДДДДДДДВДДДДДДДДДДДДДї"
@ 3,1
say "і Предмет іГруппаіВид
зан.і 1 семестр і 2
семестр і Итого і"
@ 4,1
say "і і і
По плануіФактіПо плануіФактіПо плануіФакті"
@ 5,1
say "ГДДДДДДДДДДДДДДДДДДЕДДДДДДЕДДДДДДДДЕДДДДДДДДЕДДДДЕДДДДДДДДЕДДДДЕДДДДДДДДЕДДДДґ"
i=6
flag=.t.
sum_s_1=0
sum_s_2=0
sum_all=0
do while flag
n_sem=mod(Sem,2)
if n_sem = 0
n_sem = 2
endif
local zan[9]
if Lek>0
zan[1]=.t.
tnum=1
endif
if Pz>0
zan[2]=.t.
tnum=2
endif
if Lba>0
zan[3]=.t.
tnum=3
endif
if Irs>0
zan[4]=.t.
tnum=4
endif
if Kur>0
zan[5]=.t.
tnum=5
endif
if Kon>0
zan[6]=.t.
tnum=6
endif
if
Konsu>0
zan[7]=.t.
tnum=7
endif
if Zac>0
zan[8]=.t.
tnum=8
endif
if Exz>0
zan[9]=.t.
tnum=9
endif
@ i,1 say
"і"
@ i,3 say
pred
@ i,20 say
"і"
@ i,21 say
gr
@ i,27 say
"і"
for count = 1
to tnum
if
zan[count]
do
case
case count=1
@ i,28 say "Лекции"
case
count=2
@ i,28 say "Пр.зан."
case
count=3
@ i,28 say "Лаборат."
case count=4
@ i,28 say "ИРС"
case
count=5
@ i,28 say "Курсов."
case
count=6
@ i,28 say "Контр."
case
count=7
@ i,28 say "Консульт."
case count=8
@ i,28 say "Зачет"
case
count=9
@ i,28 say "Экзамен"
endcase
if
n_sem=1
@
i,36 say "і"
col=37
else
@
i,36 say "і і і"
col=51
endif
do
case
case
count=1
@ i,col say Lek
case
count=2
@ i,col say Pz
case
count=3
@ i,col say Lba
case count=4
@ i,col say Irs
case
count=5
@ i,col say Kur
case
count=6
@ i,col say Kon
case
count=7
@ i,col say Konsu
case
count=8
@ i,col say Zac
case
count=9
@ i,col say Exz
endcase
if
n_sem=1
@
i,45 say "і і і і"
else
@
i,59 say "і і"
endif
if
count = tnum
@
i,65 say sump
@
i++,73 say "і і"
@
i++,1 say "ГДДДДДДДДДДДДДДДДДДЕДДДДДДЕДДДДДДДДЕДДДДДДДДЕДДДДЕДДДДДДДДЕДДДДЕДДДДДДДДЕДДДДґ"
else
@
i++,64 say "і і і"
endif
endif
next
if n_sem=1
sum_s_1+=Sump
sum_all+=Sump
else
sum_s_2+=Sump
sum_all+=Sump
endif
if A_next =
NULL
@ i,1 say
"і і і і і і і і"
@ i,65
say sum_all
@ i++,73
say"і і"
@ i,1 say
"АДДДДДДДДДДДДДДДДДДБДДДДДДБДДДДДДДДБДДДДДДДДБДДДДБДДДДДДДДБДДДДБДДДДДДДДБДДДДЩ"
flag =
.f.
else
go A_next
endif
enddo
@ i+1,5
say "Выводить на печать [y\n] "
@ i+1,40 get otw
read
if otw = "Y" .or. "y"
tab_print(prepod)
endif
return
proc pri_ipl
(kaf)
#include "box.ch"
#define NULL 0
set cursor off
clear
@ 5,5
say "Преподаватель "
@ 5,22 get prepod
read
sele 10
use &kaf+"npr"
go top
locate for Prep=prepod
*проверить
на eof
if eof()
clear
@ 5,5 say "Ошибка ввода!!!"
endif
adr_p=recno()
sele 11
use &kaf+"np1"
locate for A_pr=adr_p
*печать
шапки таблицы
@ 1,1
say "Индивидуальный план преподавателя"
@ 1,40
say prepod
@ 2,1
say
"ЪДДДДДДДДДДДДДДДДДДВДДДДДДВДДДДДДДДВДДДДДДДДДДДДДВДДДДДДДДДДДДДВДДДДДДДДДДДДДї"
@ 3,1
say "і Предмет іГруппаіВид
зан.і 1 семестр і 2
семестр і Итого і"
@ 4,1
say "і і і
По плануіФактіПо плануіФактіПо плануіФакті"
@ 5,1
say "ГДДДДДДДДДДДДДДДДДДЕДДДДДДЕДДДДДДДДЕДДДДДДДДЕДДДДЕДДДДДДДДЕДДДДЕДДДДДДДДЕДДДДґ"
i=6
flag=.t.
sum_s_1=0
sum_s_2=0
sum_all=0
do while flag
n_sem=mod(Sem,2)
if n_sem = 0
n_sem = 2
endif
local zan[9]
if Lek>0
zan[1]=.t.
tnum=1
endif
if Pz>0
zan[2]=.t.
tnum=2
endif
if Lba>0
zan[3]=.t.
tnum=3
endif
if Irs>0
zan[4]=.t.
tnum=4
endif
if Kur>0
zan[5]=.t.
tnum=5
endif
if Kon>0
zan[6]=.t.
tnum=6
endif
if
Konsu>0
zan[7]=.t.
tnum=7
endif
if Zac>0
zan[8]=.t.
tnum=8
endif
if Exz>0
zan[9]=.t.
tnum=9
endif
@ i,1 say
"і"
@ i,3 say
pred
@ i,20 say
"і"
@ i,21 say
gr
@ i,27 say
"і"
for count = 1
to tnum
if
zan[count]
do
case
case count=1
@ i,28 say "Лекции"
case
count=2
@ i,28 say "Пр.зан."
case
count=3
@ i,28 say "Лаборат."
case count=4
@ i,28 say "ИРС"
case
count=5
@ i,28 say "Курсов."
case
count=6
@ i,28 say "Контр."
case
count=7
@ i,28 say "Консульт."
case count=8
@ i,28 say "Зачет"
case
count=9
@ i,28 say "Экзамен"
endcase
if
n_sem=1
@
i,36 say "і"
col=37
else
@
i,36 say "і і і"
col=51
endif
do
case
case
count=1
@ i,col say Lek
case
count=2
@ i,col say Pz
case
count=3
@ i,col say Lba
case count=4
@ i,col say Irs
case
count=5
@ i,col say Kur
case
count=6
@ i,col say Kon
case
count=7
@ i,col say Konsu
case
count=8
@ i,col say Zac
case
count=9
@ i,col say Exz
endcase
if
n_sem=1
@
i,45 say "і і і і"
else
@
i,59 say "і і"
endif
if
count = tnum
@
i,65 say sump
@
i++,73 say "і і"
@
i++,1 say "ГДДДДДДДДДДДДДДДДДДЕДДДДДДЕДДДДДДДДЕДДДДДДДДЕДДДДЕДДДДДДДДЕДДДДЕДДДДДДДДЕДДДДґ"
else
@
i++,64 say "і і і"
endif
endif
next
if n_sem=1
sum_s_1+=Sump
sum_all+=Sump
else
sum_s_2+=Sump
sum_all+=Sump
endif
if A_next =
NULL
@ i,1 say
"і і і і і і і і"
@ i,65
say sum_all
@ i++,73
say"і і"
@ i,1 say
"АДДДДДДДДДДДДДДДДДДБДДДДДДБДДДДДДДДБДДДДДДДДБДДДДБДДДДДДДДБДДДДБДДДДДДДДБДДДДЩ"
flag =
.f.
else
go A_next
endif
enddo
@ i+1,5
say "Выводить на печать [y\n] "
@ i+1,40 get otw
read
if otw = "Y" .or. "y"
tab_print(prepod)
endif
return
|
