Реферат локальные базы данных

метки: Данные, Локальный, Распределенный, Запрос, Declaration, Private, Public, Close

1 РАСПРЕДЕЛЕННЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ И БАЗЫ ДАННЫХ

1.1 Понятие распределенных баз данных

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

Конце 80-х годов появились новые сценарии работы с базами данных, где требовалось обработка больших объемов данных с периферии. Например, в розничной торговле или полиграфическом производстве. Данные могут быть доступны как центральному офису, так и удаленным потребителям в распределенной географически сети.

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

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

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

Распределенные базы данных имеют ряд преимуществ:

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

1 Введение

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

1.1 Основные понятия

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

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

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

База данных. База знаний. Банк данных

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

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

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

1.2 Свойства распределенных баз данных

Определение распределенных баз данных (DDB) предложил Дэйт (C.J. Date).

Он установил 12 свойств или качеств идеальной DDB:

• Локальная автономия (local autonomy)
• Независимость узлов (no reliance on central site)
• Непрерывные операции (continuous operation)
• Прозрачность расположения (location independence)
• Прозрачная фрагментация (fragmentation independence)
• Прозрачное тиражирование (replication independence)
• Обработка распределенных запросов (distributed query processing)
• Обработка распределенных транзакций (distributed transaction processing)
• Независимость от оборудования (hardware independence)
• Независимость от операционных систем (operationg system independence)
• Прозрачность сети (network independence)
• Независимость от баз данных (database independence)

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

В данной работе рассматривается проблема независимости от центрального узла в распределенных базах данных (DDB).

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

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

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

База данных. Понятие базы данных. Виды баз данных. Объекты для ...

... база данных, разные части которой хранятся на различных компьютерах, объединённых в сеть; 4.Централизованная – база данных, хранящихся на одном компьютере; 5.Реляционная – база данных с табличной организацией данных. Одно из основных свойств БД – независимость данных ... значения ключа в отведённые поля подчинённой таблицы и тем самым, задавая ссылку, обеспечиваем связь двух записей – записи в ...

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

Для наглядного примера рассмотрим таблицу «employee» с полями «emp_id», «emp_name» и «phone». Предположим, что эта таблица определена в базе данных на узле в Фениксе и такая же таблица определена в базе данных на узле в Денвере. Обе таблицы содержат информацию о сотрудниках компании. Кроме того, в базе данных на узле в Далласе определена таблица «emp_salary» с полями «emp_id» и «salary».

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

SELECT * FROM employee@phoenix, employee@denver ORDER BY emp_id

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

SELECT * FROM emp_salary@dallas ORDER BY emp_id

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

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

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

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

1.3 Целостность данных

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

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

Исходя из определения Дэйта, можно рассматривать DDB как слабосвязанную сетевую структуру, узлы которой представляют собой локальные базы данных. Локальные базы данных автономны, независимы и самоопределены; доступ к ним обеспечиваются СУБД, в общем случае от различных поставщиков. Связи между узлами — это потоки тиражируемых данных. Топология DDB варьируется в широком диапазоне — возможны варианты иерархии, структур типа «звезда» и т.д. В целом топология DDB определяется географией информационной системы и направленностью потоков тиражирования данных [4].

База данных в СУБД ACCESS

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

В DDB поддержка целостности и согласованности данных, ввиду свойств 1-2, представляет собой сложную проблему. Ее решение — синхронное и согласованное изменение данных в нескольких локальных базах данных, составляющих DDB — достигается применением протокола двухфазной фиксации транзакций. Если DDB однородна — то есть на всех узлах данные хранятся в формате одной базы и на всех узлах функционирует одна и та же СУБД, то используется механизм двухфазной фиксации транзакций данной СУБД. В случае же неоднородности DDB для обеспечения согласованных изменений в нескольких базах данных используют менеджеры распределенных транзакций. Это, однако, возможно, если участники обработки распределенной транзакции — СУБД, функционирующие на узлах системы, поддерживают XA-интерфейс, определенный в спецификации DTP консорциума X/Open. В настоящее время XA-интерфейс имеют СУБД CA-OpenIngres, Informix, Microsoft SQL Server, Oracle, Sybase.

Специальные подходы

В технологии тиражирования данных присутствует возможность асинхронного переноса изменений объектов исходной базы данных в базы, принадлежащие различным узлам распределенной системы. Такая функция выполняется специальным модулем СУБД — сервером тиражирования данных, известным как репликатор. Он встроен в сервер Oracle 7, но для использования тиражирования данных в Oracle 7 требуется дополнительная опция Replication Option [7].

Если в DDB предусмотрено тиражирование данных, то это сразу предъявляет дополнительные жесткие требования к дисциплине поддержки целостности данных на узлах, куда направлены потоки тиражируемых данных. Проблема в том, что изменения в данных инициируются как локально — на данном узле — так и извне, посредством тиражирования. Неизбежно возникают конфликты по изменениям, которые необходимо отслеживать и разрешать [4].

Оптимизатор распределенных запросов

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

Межоперабельность в DDB

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

Передача данных в компьютерных сетях

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

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

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

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

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

Недостатки DR-технологии

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

Прозрачность расположения данных

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

Примером обеспечения прозрачности расположения данных в продукте Oracle является создание ссылок на базы данных (database link).

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

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

Распределенная система управления базами данных System R*

1.4.1 Основная цель проекта System R

Мы ограничимся рассмотрением проблем однородных распределенных СУБД на примере System R*.

Базы данных и управление ими

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

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

Исследование системы управления базами данных System R*

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

Легкость использования системы достигается за счет того, что пользователи System R* (разработчики прикладных программ и конечные пользователи) остаются в среде языка SQL. Возможность использования SQL основывается на обеспечении System R* прозрачности местоположения данных. Система автоматически обнаруживает текущее местоположение упоминаемых в запросе пользователя объектов данных; одна и та же прикладная программа, включающая предложения SQL, может быть выполнена в разных узлах сети. При этом в каждом узле сети на этапе компиляции запроса выбирается наиболее оптимальный план выполнения запроса в соответствии с расположением данных в распределенной системе.

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

1.4.2 Средства повышения эффективности

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

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

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

Нереализованные средства

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

Горизонтальное и вертикальное разделение отношений в SQL

В последние годы в SQL активно развивались конструкции для горизонтального и вертикального разделения отношений. Новый оператор DISTRIBUTE TABLE позволял разбивать отношение на подотношения и отправлять их в указанные узлы для хранения. Оператор DISTRIBUTE TABLE VERTICALLY позволял проецировать отношение на заданные атрибуты и сохранять подотношения в указанных сегментах узлов.

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

Предложение новой конструкции в SQL

Для решения проблемы поддержания копий отношения в нескольких узлах сети было предложено использовать новую конструкцию SQL. Оператор DISTRIBUTE TABLE REPLICATED INTO позволял производить рассылку копий указанного отношения для хранения в именованных сегментах указанных узлов сети, обеспечивая автоматическую поддержку согласованности копий. Однако, помимо существенных проблем поддержания согласованности копий, возникала проблема разумного использования копий, которую должен был учитывать оптимизатор.

Для создания мгновенных снимков состояния баз данных предлагается использовать новую конструкцию SQL: DEFINE SNAPSHOT <snapshot-name> (<attribute-list>) AS <query>, с опцией REFRESHED EVERY <period>. Это позволяет производить выполнение указанного запроса на выборку и сохранять результирующее отношение под указанным именем в локальной базе данных в узле, в котором выполняется предложение.

Мгновенный снимок затем периодически обновляется в соответствии с запомненным запросом. Возможность обновлять мгновенный снимок без ожидания истечения временного интервала реализована через выполнение предложения REFRESH SNAPSHOT <snapshot-name>.

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

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

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

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

Разворачивание данных в System R*

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

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

Напомним прежде всего, что полное имя отношения (базового или представления) в базе данных System R имеет вид имя-пользователя.имя-отношения, где имя-пользователя идентифицирует пользователя — создателя отношения, а имя-отношения — это то имя, которое было указано в предложениях CREATE TABLE или CREATE VIEW. В запросах можно указывать либо это полное имя отношения, либо его локальное имя. Во втором случае при компиляции используются стандартные правила дополнения локального имени до полного с использованием в качестве составляющей имя-пользователя идентификатора пользователя, от имени которого выполняется компиляция.

В System R* используется развитие этого подхода. Системное имя отношения включает четыре компонента: идентификатор пользователя-создателя отношения; идентификатор узла сети, в котором выполнялась операция создания отношения; локальное имя отношения, присвоенное ему при создании; идентификатор узла, в котором отношение располагалось непосредственно после своего создания (напомним, что отношение может перемещаться из одного узла в другой при выполнении операции MIGRATE).

Для определения системных и локальных имен объектов в SQL-запросах используются системные и короткие локальные имена. Локальные имена могут быть интерпретированы как часть системного имени или как синоним системного имени. Для определения синонимов SQL используется оператор DEFINE SYNONYM <relation-name> AS <system-wide-name>, который добавляет информацию о синониме в локальный каталог.

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

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

Процесс компиляции запроса в распределенной системе данных system R* является важным этапом обработки SQL запросов. Он включает в себя оптимизацию процедуры каталогизации и компиляции на различных узлах сети.

Оптимизация процедуры каталогизации

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

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

Процесс компиляции запроса

Процесс компиляции запросов на языке SQL происходит до их реального выполнения. Компиляция запроса может выполняться на стадии прекомпиляции прикладной программы, написанной на традиционном языке программирования, либо в динамике выполнения транзакции при выполнении предложения PREPARE.

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

Общая схема распределенной компиляции

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

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

Развертка

1. Грамматический разбор SQL предложения

1.1 Построение внутреннего представления запроса в форме дерева в главном узле.

1.2 Замена имен объектов в запросе на их системные идентификаторы на основе информации из локального каталога главного узла и удаленных каталогов дополнительных узлов.

2. Генерация глобального плана выполнения запроса

2.1 Учет порядка взаимодействий узлов при реальном выполнении запроса.

2.2 Использование расширения техники оптимизации, применяемой в System R, для выработки глобального плана.

2.3 Отображение глобального плана в преобразованном дереве запроса.

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

3.1 Рассылка соответствующих частей запроса в дополнительные узлы.

4. Завершающая стадия выполнения компиляции в каждом участвующем узле

4.1 Проверка прав пользователя на выполнение соответствующих действий.

4.2 Обработка представлений базы данных.

4.3 Локальная оптимизация обрабатываемой части запроса в соответствии с имеющимися индексами.

4.4 Генерация машинного кода.

5 Управление транзакциями и синхронизация

Выполнение транзакции в распределенной системе управления базами данных System R*, естественно, является распределенным. Транзакция начинается в главном узле при обращении к какой-либо секции ранее подготовленного (на этапе компиляции) модуля доступа. Как и в System R, модуль доступа загружается в виртуальную память задачи, обращение к секции модуля доступа — это вызов подпрограммы. Однако, в отличие от System R, эта подпрограмма, кроме своего локального программного кода и вызовов функций RSS, содержит еще и вызовы удаленных подсекций модуля доступа. Эти вызовы интерпретируются в духе вызовов удаленных процедур. Тем самым выполнение одной транзакции, инициированной в некотором узле сети A влечет, вообще говоря, инициирование транзакций в дополнительных узлах. Основной новой по сравнению с System R проблемой является проблема согласованного завершения распределенной транзакции, чтобы результаты ее выполнения во всех затронутых ею узлах были либо отображены в состояние локальных баз данных, либо полностью отсутствовали.

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

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

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

Как и в System R, согласованность состояния баз данных при параллельном выполнении нескольких транзакций в System R* обеспечивается на основе механизма синхронизационных захватов объектов базы данных при соблюдении двухфазного протокола захватов. Напомним, что это означает разбиение каждой транзакции с точки зрения синхронизации на две фазы — рабочую фазу, на которой захваты только устанавливаются, и фазу завершения, когда все захваты объектов базы данных, произведенные данной транзакцией, снимаются. Синхронизация производится в точности так же, как и в System R: каждая транзакция-участник обращается к локальной базе данных через RSS своего узла. Основной новой проблемой является проблема возможных распределенных тупиков, которые могут возникнуть между несколькими распределенными транзакциями, выполняющимися параллельно. (Тупики между транзакциями — участниками одной распределенной транзакции невозможны, поскольку все участники получают один общий идентификатор транзакции и не конфликтуют по синхронизации).

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

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

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

Этот процесс продолжается до обнаружения тупика.

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

2 ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ НА ПРИМЕРЕ «АРМ КЛАДОВЩИКА»

2.1 Обследование предметной области, выявление запросов пользователей и построение концептуальной информационной модели ПО

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

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

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

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

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

• «Инвентаризационная ведомость»
• «Договор поставки»

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

1.Кто является получателем товара?

2.Какие товары хранятся на складе?

3.Кто работает на складе?

4.Кто поставляет товар?

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

Таблица 1

Атрибуты и их идентификаторы

№	Наименование атрибута	Идентификатор
1	Табельный номер кладовщика	ТН
2	ФИО кладовщика	ФИО
№	Домашний адрес кладовщика	АДРЕС
3	Телефон	ТЕЛ
4	Дата рождения	ДАТА_РОЖ
5	РНН	РНН
6	Стаж	СТАЖ
7	Оклад	ОКЛАД
8	Должность	ДОЛЖ
9	ФИО клиента	КЛИЕНТ
10	Банковский счет клиента	БАНК
11	Адрес клиента	АДР_КЛ
12	Фирма клиента	НАЗ_ФИРМ
13	Номер заказа	НЗ
14	Телефон клиента	ТЕЛ_КЛ
15	Срок поставки товара	СРОК
16	Количество поставки товара	КОЛ_ВО
17	Номенклатурный номер товара	ННТОВ
18	Цена товара отпускная	ЦЕНА_ПОС
19	Наименование товара	НАЗ_ТОВ
20	Стоимость товара	СТОИМ
21	Стоимость без НДС	БЕЗ_НДС

Продолжение таблицы 1

№	Наименование атрибута	Идентификатор
22	Количество товара на складе	КОЛ_ВО_СКЛ
23	Единица измерения товара	ЕД_ИЗМ
24	ТМБ	ТМБ
25	Марка товара	МАРКА
26	ГОСТ	ГОСТ
27	Идентификационный номер поставщика	ИДП
28	ФИО представителя поставщика	ФИО_ПОС
29	Наименование фирмы-поставщика	НАИМ_ФИРМ
30	Телефон поставщика	ТЕЛ_ПОС
31	Адрес поставщика	АДР_ПОС
32	Счет поставщика	СЧЕТ
33	РНН	РС
34	МФО	МФО

На основании необходимых запросов выделим следующие сущности с атрибутами:

• ЗАКАЗ (Номер заказа, ФИО клиента, номер банковского счета, название фирмы, адрес, телефон, номенклатурный номер товара, цена, количество, дата поставки);

• ТОВАР (номенклатурный номер товара, наименование товара, стоимость, стоимость без НДС, количество, единица измерения, ТМБ, марка товара, гост);

• ПОСТАВЩИК (Идентификационный код поставщика, ФИО, наименование фирмы, адрес поставщика, телефон, счет, рнн, мфо );

• КЛАДОВЩИК (табельный номер, ФИО, адрес, телефон, дата рождения, рнн, стаж, оклад, должность);

Проведем анализ связей между сущностями:

• КЛАДОВЩИК, ЗАКАЗ — оформляет;
• связь типа М:М;

• КЛАДОВЩИК, ТОВАР – получает, связь типа М:М;
• ПОСТАЩИК, ТОВАР — поставляет, связь типа М:М;

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

Рис. 7 Концептуальная схема «Склад».

2.2 Этап логического проектирования

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

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

1. ЗАКАЗ (НЗ, Клиент, банк, наз_фирм, адр_кл, тел_кл, ннтов, цена, кол_во, срок);

• Заказ определяется по номеру заказа, поэтому в качестве ключевого выберем атрибут «Номер заказа».

НЗ — [все атрибуты].

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

• ЗАКАЗ (НЗ, Клиент, ннтов, цена, кол_во, срок);

• КЛИЕНТ(Клиент, банк, наз_фирм, адр_кл, тел_кл);

В новом отношении Клиент ключевыми атрибутами являются Клиент и банк, то есть

КЛИЕНТ, БАНК- [все атрибуты].

Других функциональных зависимостей в отношениях нет, оба отношения находятся в 3НФ

2. ТОВАР (ннтов, наз_тов, стоим, без_НДС, кол_во_скл, ед_изм, ТМБ, марка, гост);

• Товары учитываются по номенклатурным номерам, поэтому в качестве ключевого атрибута выберем «ННТОВ» — номенклатурный номер товара.

ННТОВ — [все атрибуты].

Других ФЗ отсутствуют, отношение находится в 3НФ.

3. ПОСТАВЩИК (ИДП, ФИО_пос, наим_фир, адр_пос,тел_пос, счет, рс, мфо );

• Поставщики определяется по идентификационному коду, поэтому в качестве ключевого выберем атрибут «ИДП».

ИДП -[все атрибуты].

Другие ФЗ отсутствуют, отношение находится в 3НФ.

4. КЛАДОВЩИК (тн, ФИО, адрес, тел, дата_рож, рнн, стаж, оклад, долж);

• Кладовщик определяется по табельному номеру, поэтому в качестве ключевого выберем атрибут «ТН».

ТН -[все атрибуты].

Другие ФЗ отсутствуют, отношение находится в 3НФ.

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

Отношение КЛИЕНТ:

Клиент

банк

наз_фирм

адр_кл

тел_кл

Отношение ЗАКАЗ:

НЗ

Клиент

ннтов

цена

кол_во

срок

Отношение ТОВАР:

ннтов

наз_тов

стоим

без_НДС

кол_во_скл

ед_изм

ТМБ

марка

гост

Отношение ПОСТАВЩИК:

ИДП

ФИО_пос

наим_фир

адр_пос

тел_пос

счет

рс

мфо

Отношение КЛАДОВЩИК:

тн

ФИО

адрес

тел

дата_рож

рнн

стаж

оклад

долж

Ключи отношений выделены подчеркиванием.

2.3 Этап машинного проектирования

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

На данном этапе выполняется описание структуры таблиц с указанием имен, типов, размерностей полей, входящих в состав БД.

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

ЗАКЛЮЧЕНИЕ

В данной курсовой работе были рассмотрены аспекты создания распределенных баз данных на примере Systrm R*. Рассмотрена структура распределенных БД, требования к распределенным БД.

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

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

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

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

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

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

ГЛОССАРИЙ

№п/п	Новое понятие	Содержание
1	Распределенная база данных ( Distributed DataBase — DDB)	база данных, включающая фрагменты из нескольких баз данных, которые располагаются на различных узлах сети компьютеров, и, возможно управляются различными СУБД
2	Однородная распределенная база данных	каждая локальная база данных управляется одной и той же СУБД
3	Неоднородная распределенная база данных	локальные базы данных могут относиться даже к разным моделям данных
4	Локальная автономия	управление данными на каждом из узлов распределенной системы выполняется локально
5	Независимость от центрального узла	все узлы равноправны и независимы, а расположенные на них базы являются равноправными поставщиками данных в общее пространство данных
6	Непрерывные операции	возможность непрерывного доступа к данным в рамках DDB вне зависимости от их расположения и вне зависимости от операций, выполняемых на локальных узлах
7	Прозрачность расположения	Пользователь, обращающийся к DDB, ничего не должен знать о реальном, физическом размещении данных в узлах информационной системы.
8	Прозрачная фрагментация	возможность распределенного (то есть на различных узлах) размещения данных, логически представляющих собой единое целое
9	Тиражирование данных	асинхронный процесс переноса изменений объектов исходной базы данных в базы, расположенные на других узлах распределенной системы
№п/п	Новое понятие	Содержание
10	Прозрачность тиражирования	возможность переноса изменений между базами данных средствами, невидимыми пользователю распределенной системы.
11	Обработка распределенных запросов	возможность выполнения операций выборки над распределенной базой данных, сформулированных в рамках обычного запроса на языке SQL.
12	Обработка распределенных транзакций	возможность выполнения операций обновления распределенной базы данных (INSERT, UPDATE, DELETE), не разрушающее целостность и согласованность данных.
13	Независимость от оборудования	качестве узлов распределенной системы могут выступать компьютеры любых моделей и производителей — от мэйнфреймов до «персоналок».
14	Независимость от операционных систем	многообразие операционных систем, управляющих узлами распределенной системы.
15	Прозрачность сети	в распределенной системе возможны любые сетевые протоколы.
16	Независимость от баз данных	распределенной системе могут мирно сосуществовать СУБД различных производителей, и возможны операции поиска и обновления в базах данных различных моделей и форматов.

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

[Электронный ресурс]//URL: https://liarte.ru/kursovaya/lokalnyie-bazyi-dannyih/

1. Бройдо В. Л., Крылова В.С. «Научные основы организации управления и построения АСУ», Высшая школа, Москва, 1990 г.

2. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. М., Финансы и статистика, 1998.

3. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. М., Финансы и статистика, 2000.

4. Дейт К. «Введение в системы управления базами данных», БИНОМ, Москва, 1999 г.

5. Иоффе А. Ф. «Персональные ЭВМ в организационном управлении», Наука, Москва, 1988 г.

6. Информатика и вычислительная техника: пособие для студ. Вузов инж. — педагогич. спец. В. В. Вьюгин, С. В. Кудимов, В. Г. Накрохин и др.; под ред. В. Н. Ларионова. – М.: Высш. Шк. 1992. – 287 с.: ил.

7. Интернет-сайты: : 150223&page=ibp_config, www.ais.khstu.ru, www.libertarium.ru.

8. Ковязин А.Н., С.М. Востриков «Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/Firebird/Yaffil (3-е издание)» — М.: Кудиц-образ, 2005

9. Марин Дж. «Организация баз данных в вычислительных системах», Мир, Москва, 1990г.

10. Немнюгин С.А.– «Delphi»- СПб, Питер – 2000 г.

11. Оптимизация приложений С++Builder в архитектуре клиент/сервер, Наталия Елманова, Центр информационных технологий

(http://www.citforum.ru/programming/cpp/cb_498.shtml

12. Фаронов В.В.– «Delphi 7.0» – изд. «Нолидж» — 2001 г.

13. Фаронов В. В. – «Delphi 7.0» – изд. «Нолидж» — 1999г;

14. Фигурнов В.Э.– «IBM PC для пользователя. Краткий курс» – изд. «ИНФРА-М» — 2000г

15. Чен П.П. Модель “сущность-связь” – шаг к единому представлению данных. СУБД, N3, 1995 г

16. Чертовской В.Д. Базы и банки данных. СПб, БХВ-Петербург – 2005 г.

ПРИЛОЖЕНИЕ 1

Листинг основной программы

unit Umain;

interface

uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, Menus, ImgList;

type

TFmain = class(TForm)

MainMenu1: TMainMenu;

• ImageList1: TImageList;
• N1: TMenuItem;
• N2: TMenuItem;
• N3: TMenuItem;
• N4: TMenuItem;

• N5: TMenuItem;
• N6: TMenuItem;
• N7: TMenuItem;
• N8: TMenuItem;

• N9: TMenuItem;
• N11: TMenuItem;
• N12: TMenuItem;

• N14: TMenuItem;
• N15: TMenuItem;
• N13: TMenuItem;

• N16: TMenuItem;
• procedure N5Click(Sender: TObject);
• procedure N12Click(Sender: TObject);

• procedure N8Click(Sender: TObject);
• procedure N7Click(Sender: TObject);

• procedure N15Click(Sender: TObject);
• procedure N6Click(Sender: TObject);

• procedure N14Click(Sender: TObject);
• procedure N13Click(Sender: TObject);

• procedure N9Click(Sender: TObject);
• procedure N16Click(Sender: TObject);

• procedure N3Click(Sender: TObject);

private { Private declarations }

public { Public declarations }

end;

var

Fmain: TFmain;

implementation

uses UDM, UDobTovar, UTovar, UDobFirm, UFirm, UZakaz, UDobZakaz, UInvVed1, URepIVed, UKlad, Upass, UDogf, UTPoisk, UAbout, USPoisk, UZapr;

Продолжение приложения 1

{$R *.dfm}

procedure TFmain.N5Click(Sender: TObject);

• begin FTovar.Show;
• end;

• procedure TFmain.N12Click(Sender: TObject);
• begin FPass.Close;
• close;
• end;

• procedure TFmain.N8Click(Sender: TObject);
• begin FFirm.Show;
• end;

• procedure TFmain.N7Click(Sender: TObject);
• begin FZakaz.Show;
• end;

• procedure TFmain.N15Click(Sender: TObject);
• begin FInvVed.Show;
• end;

• procedure TFmain.N6Click(Sender: TObject);
• begin FKlad.Show;
• end;

• procedure TFmain.N14Click(Sender: TObject);
• begin fdog.Show;
• end;

• procedure TFmain.N13Click(Sender: TObject);
• begin FTPoisk.Show;
• end;

• procedure TFmain.N9Click(Sender: TObject);
• begin AboutBox.Show;
• end;

• procedure TFmain.N16Click(Sender: TObject);
• begin FSPoisk.Show;
• end;

• procedure TFmain.N3Click(Sender: TObject);
• begin Form1.Show;
• end;

• end.

unit UNewPass;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Продолжение приложения 1

Dialogs, StdCtrls, Buttons, Registry;

type

TFNewPass = class(TForm)

Edit1: TEdit; Edit2: TEdit; Edit3: TEdit; SpeedButton1: TSpeedButton; Label1: TLabel; Label2: TLabel; Label3: TLabel;

• procedure SpeedButton1Click(Sender: TObject);
• procedure FormActivate(Sender: TObject);
• procedure Edit1KeyPress(Sender: TObject;
• var Key: Char);

• procedure Edit2KeyPress(Sender: TObject;
• var Key: Char);

• procedure Edit3KeyPress(Sender: TObject;
• var Key: Char);

private { Private declarations }

public { Public declarations }

end;

• var FNewPass: TFNewPass;

implementation

uses Upass;

• {$R *.dfm}

procedure TFNewPass.SpeedButton1Click(Sender: TObject);

• begin close;
• end;

• procedure TFNewPass.FormActivate(Sender: TObject);
• begin Edit1.Text := »;
• Edit2.Text := »;
• Edit3.Text := »;
• Edit1.Enabled := true;

• Edit1.SetFocus;
• Edit2.Enabled := false;
• Edit3.Enabled := false;
• end;

• procedure TFNewPass.Edit1KeyPress(Sender: TObject;
• var Key: Char);

• begin if (key = #13) and (Edit1.Text = Fpass.LabeledEdit1.Text) then

begin Edit2.Enabled := true; Edit1.Enabled := false; Edit2.SetFocus;

• end;
• end;

• procedure TFNewPass.Edit2KeyPress(Sender: TObject;
• var Key: Char);

• begin if key = #13 then begin Edit3.Enabled := true;
• Edit3.SetFocus;

Продолжение приложения 1

Edit2.Enabled := false; end; end;

• procedure TFNewPass.Edit3KeyPress(Sender: TObject;
• var Key: Char);

• var Reg:TRegistry;
• begin if (key = #13) and (Edit2.Text = Edit3.Text) then begin

Reg := TRegistry.Create; with Reg do begin

RootKey := HKEY_LOCAL_MACHINE;

• OpenKey(‘Software’, True);
• if not KeyExists(‘Cardi’) then CreateKey(‘Cardi’);

• OpenKey(‘Cardi’, True);
• WriteString(‘Log’, Edit3.Text);
• end;
• close;
• end;

• end; end.

unit Upass;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Buttons, StdCtrls, ExtCtrls, Registry;

type

TFPass = class(TForm)

LabeledEdit1: TLabeledEdit; SpeedButton1: TSpeedButton;

• SpeedButton2: TSpeedButton;
• SpeedButton3: TSpeedButton;

• procedure SpeedButton1Click(Sender: TObject);
• procedure FormCreate(Sender: TObject);
• procedure SpeedButton2Click(Sender: TObject);
• procedure SpeedButton3Click(Sender: TObject);

private { Private declarations }

public { Public declarations }

end;

• var FPass: TFPass;
• pass, newpass:string;
• x:byte;

implementation

uses UZast, UNewPass;

• {$R *.dfm}

Продолжение приложения 1

procedure TFPass.SpeedButton1Click(Sender: TObject);

• begin x:= x+1;
• if x<3 then Begin if LabeledEdit1.Text = pass then

begin FZast.Show; Visible:=false; end else begin

LabeledEdit1.SetFocus; MessageDlg(‘Пароль не верен!!! Повторите ввод’, mtInformation,[mbOk],0); end end else

begin MessageDlg(‘Пароль не верен!!! Доступ запрещен!!!’, mtInformation,

[mbOk], 0); Close; end; end;

• procedure TFPass.FormCreate(Sender: TObject);
• var reg:Tregistry;
• begin x:=0;
• LabeledEdit1.Text := »;
• Reg := TRegistry.Create;
• with Reg do

begin RootKey := HKEY_LOCAL_MACHINE; OpenKey(‘Software’, True);

• if not KeyExists(‘Cardi’) then CreateKey(‘Cardi’);
• OpenKey(‘Cardi’, True); if not ValueExists(‘Log’) then begin

newpass := »; WriteString(‘Log’, newpass); end else pass := ReadString(‘Log’); end; end;

• procedure TFPass.SpeedButton2Click(Sender: TObject);
• begin close;
• end;

• procedure TFPass.SpeedButton3Click(Sender: TObject);
• begin FNewPass.Show;
• end;

• end.

unit URepIVed;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, QRCtrls, QuickRpt, ExtCtrls;

Type TFRepIVed = class(TForm)

QuickRep1: TQuickRep; DetailBand1: TQRBand;

• ColumnHeaderBand1: TQRBand;
• TitleBand1: TQRBand;

• QRLabel1: TQRLabel;
• QRLabel2: TQRLabel;

Продолжение приложения 1

QRLabel3: TQRLabel; QRLabel4: TQRLabel;

• QRLabel5: TQRLabel;
• QRLabel6: TQRLabel;

• QRLabel7: TQRLabel;
• QRLabel8: TQRLabel;

• QRLabel9: TQRLabel;
• QRLabel10: TQRLabel;

• QRDBText1: TQRDBText;
• QRDBText2: TQRDBText;

• QRDBText3: TQRDBText;
• QRDBText4: TQRDBText;

• QRDBText5: TQRDBText;
• QRDBText6: TQRDBText;

• QRDBText7: TQRDBText;
• QRDBText8: TQRDBText;

• QRDBText9: TQRDBText;
• SummaryBand1: TQRBand;

• QRLabel11: TQRLabel;
• QRLabel12: TQRLabel;

• QRLabel13: TQRLabel;

Private { Private declarations }

Public { Public declarations }

end;

• var FRepIVed: TFRepIVed;

implementation

uses UDM;

• {$R *.dfm}

end.

unit USPoisk;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Mask,db, DBCtrls, StdCtrls, ExtCtrls, Buttons, ComCtrls;

type

TFSPoisk = class(TForm)

PageControl1: TPageControl; TabSheet1: TTabSheet;

• Label1: TLabel;
• Label2: TLabel;
• Label3: TLabel;

• Label4: TLabel;
• Label5: TLabel;
• Label6: TLabel;

Продолжение приложения 1

Label7: TLabel; Label8: TLabel; SpeedButton2: TSpeedButton;

• SpeedButton4: TSpeedButton;
• LabeledEdit1: TLabeledEdit;

• DBEdit1: TDBEdit;
• DBEdit2: TDBEdit;

• DBEdit3: TDBEdit;
• DBEdit4: TDBEdit;

• DBEdit5: TDBEdit;
• DBEdit6: TDBEdit;

• DBEdit7: TDBEdit;
• DBEdit8: TDBEdit;

• TabSheet2: TTabSheet;
• SpeedButton1: TSpeedButton;

• SpeedButton3: TSpeedButton;
• Label12: TLabel;

• Label13: TLabel;
• Label14: TLabel;

• Label15: TLabel;
• Label16: TLabel;

• DBEdit12: TDBEdit;
• DBEdit13: TDBEdit;

• DBEdit14: TDBEdit;
• DBEdit15: TDBEdit;

• DBEdit16: TDBEdit;
• LabeledEdit2: TLabeledEdit;

• TabSheet3: TTabSheet;
• SpeedButton5: TSpeedButton;

• SpeedButton6: TSpeedButton;
• Label9: TLabel;

• DBEdit9: TDBEdit;
• Label10: TLabel;

• DBEdit10: TDBEdit;
• Label11: TLabel;

• DBEdit11: TDBEdit;
• LabeledEdit3: TLabeledEdit;

• Label17: TLabel;
• DBEdit17: TDBEdit;

• Label18: TLabel;
• DBEdit18: TDBEdit;

• Label19: TLabel;
• DBEdit19: TDBEdit;

• Label20: TLabel;
• DBEdit20: TDBEdit;

• Label21: TLabel;
• DBEdit21: TDBEdit;

• Label22: TLabel;
• DBEdit22: TDBEdit;

• Label23: TLabel;
• DBEdit23: TDBEdit;

• Label24: TLabel;
• DBEdit24: TDBEdit;

• procedure SpeedButton2Click(Sender: TObject);
• procedure SpeedButton6Click(Sender: TObject);
• procedure SpeedButton3Click(Sender: TObject);

Продолжение приложения 1

procedure SpeedButton5Click(Sender: TObject);

• procedure SpeedButton1Click(Sender: TObject);
• procedure SpeedButton4Click(Sender: TObject);

private { Private declarations }

public { Public declarations }

end;

• var FSPoisk: TFSPoisk;

implementation

uses UDM;

• {$R *.dfm}

procedure TFSPoisk.SpeedButton2Click(Sender: TObject);

• begin DM.Tklad.Locate(‘fio’,LabeledEdit1.Text,[lopartialkey]);
• end;

• procedure TFSPoisk.SpeedButton6Click(Sender: TObject);
• begin DM.Tklad.Locate(‘stag’,strtoint(LabeledEdit3.Text),[lopartialkey]);
• end;

• procedure TFSPoisk.SpeedButton3Click(Sender: TObject);
• begin DM.Tklad.Locate(‘dolj’,LabeledEdit2.Text,[lopartialkey]);
• end;

• procedure TFSPoisk.SpeedButton5Click(Sender: TObject);
• begin close;
• end;

• procedure TFSPoisk.SpeedButton1Click(Sender: TObject);
• begin close;
• end;

• procedure TFSPoisk.SpeedButton4Click(Sender: TObject);
• begin close;
• end;

• end.

unit UTovar;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Grids, DBGrids, ImgList, ComCtrls, ToolWin;

Продолжение приложения 1

Type TFTovar = class(TForm)

ToolBar1: TToolBar; TBFirst: TToolButton;

• ToolButton2: TToolButton;
• ToolButton3: TToolButton;

• ToolButton4: TToolButton;
• ToolButton5: TToolButton;

• ToolButton6: TToolButton;
• ToolButton7: TToolButton;

• ImageList1: TImageList;
• DBGrid1: TDBGrid;

• ToolButton1: TToolButton;
• procedure TBFirstClick(Sender: TObject);
• procedure ToolButton2Click(Sender: TObject);
• procedure ToolButton3Click(Sender: TObject);
• procedure ToolButton4Click(Sender: TObject);
• procedure ToolButton5Click(Sender: TObject);
• procedure ToolButton6Click(Sender: TObject);
• procedure ToolButton7Click(Sender: TObject);
• procedure ToolButton1Click(Sender: TObject);

private { Private declarations }

public { Public declarations }

end;

var

FTovar: TFTovar;

implementation

uses UDM, UDobTovar, Umain;

• {$R *.dfm}

procedure TFTovar.TBFirstClick(Sender: TObject);

• begin DM.Ttov.First;
• end;

• procedure TFTovar.ToolButton2Click(Sender: TObject);
• begin DM.Ttov.Prior;
• end;

• procedure TFTovar.ToolButton3Click(Sender: TObject);
• begin DM.Ttov.Next;
• end;

Продолжение приложения 1

procedure TFTovar.ToolButton4Click(Sender: TObject);

• begin DM.Ttov.Last;
• end;

• procedure TFTovar.ToolButton5Click(Sender: TObject);
• begin DM.Ttov.Post;
• end;

• procedure TFTovar.ToolButton6Click(Sender: TObject);
• begin DM.Ttov.Delete;
• end;

• procedure TFTovar.ToolButton7Click(Sender: TObject);
• var n:integer;
• begin DM.Ttov.Last;
• n:=DM.Ttov.FieldByName(‘idn’).Value;

• DM.Ttov.Append;
• DM.Ttov.FieldByName(‘idn’).Value:=n+1;

• FDobTov.Show;
• close;
• end;

• procedure TFTovar.ToolButton1Click(Sender: TObject);
• begin Fmain.Show;
• close;
• end;

• end.

unit UTPoisk;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Buttons, StdCtrls, Mask, db,DBCtrls, ExtCtrls, ComCtrls;

Type TFTPoisk = class(TForm)

PageControl1: TPageControl; TabSheet1: TTabSheet;

• TabSheet2: TTabSheet;
• TabSheet3: TTabSheet;

• TabSheet4: TTabSheet;
• TabSheet5: TTabSheet;

• LabeledEdit1: TLabeledEdit;
• DBEdit1: TDBEdit;

• DBEdit2: TDBEdit;
• DBEdit3: TDBEdit;

• DBEdit4: TDBEdit;
• DBEdit5: TDBEdit;

• DBEdit6: TDBEdit;
• DBEdit7: TDBEdit;

• DBEdit8: TDBEdit;
• Label1: TLabel;
• Label2: TLabel;
• Label3: TLabel;

• Label4: TLabel;
• Label5: TLabel;
• Label6: TLabel;
• Label7: TLabel;

• Label8: TLabel;
• SpeedButton2: TSpeedButton;

Продолжение приложения 1

SpeedButton4: TSpeedButton; SpeedButton1: TSpeedButton;

• SpeedButton3: TSpeedButton;
• DBEdit9: TDBEdit;

• Label9: TLabel;
• DBEdit10: TDBEdit;
• Label10: TLabel;

• DBEdit11: TDBEdit;
• Label11: TLabel;
• DBEdit12: TDBEdit;

• Label12: TLabel;
• Label13: TLabel;
• DBEdit13: TDBEdit;

• Label14: TLabel;
• DBEdit14: TDBEdit;
• Label15: TLabel;

• DBEdit15: TDBEdit;
• DBEdit16: TDBEdit;
• Label16: TLabel;

• LabeledEdit2: TLabeledEdit;
• SpeedButton5: TSpeedButton;

• SpeedButton6: TSpeedButton;
• DBEdit17: TDBEdit;

• Label17: TLabel;
• DBEdit18: TDBEdit;
• Label18: TLabel;

• DBEdit19: TDBEdit;
• Label19: TLabel;
• DBEdit20: TDBEdit;

• Label20: TLabel;
• Label21: TLabel;
• DBEdit21: TDBEdit;

• Label22: TLabel;
• DBEdit22: TDBEdit;
• Label23: TLabel;

• DBEdit23: TDBEdit;
• DBEdit24: TDBEdit;
• Label24: TLabel;

• LabeledEdit3: TLabeledEdit;
• SpeedButton7: TSpeedButton;

• SpeedButton8: TSpeedButton;
• DBEdit25: TDBEdit;

• Label25: TLabel;
• DBEdit26: TDBEdit;
• Label26: TLabel;

• DBEdit27: TDBEdit;
• Label27: TLabel;
• DBEdit28: TDBEdit;

• Label28: TLabel;
• Label29: TLabel;
• DBEdit29: TDBEdit;

• Label30: TLabel;
• DBEdit30: TDBEdit;
• Label31: TLabel;

• DBEdit31: TDBEdit;
• DBEdit32: TDBEdit;
• Label32: TLabel;

• LabeledEdit4: TLabeledEdit;
• SpeedButton9: TSpeedButton;

• SpeedButton10: TSpeedButton;
• DBEdit33: TDBEdit;

• Label33: TLabel;
• DBEdit34: TDBEdit;
• Label34: TLabel;

• DBEdit35: TDBEdit;
• Label35: TLabel;
• DBEdit36: TDBEdit;

• Label36: TLabel;
• Label37: TLabel;
• DBEdit37: TDBEdit;

• Label38: TLabel;
• DBEdit38: TDBEdit;
• Label39: TLabel;

• DBEdit39: TDBEdit;
• DBEdit40: TDBEdit;
• Label40: TLabel;

• LabeledEdit5: TLabeledEdit;

Продолжение приложения 1

procedure SpeedButton2Click(Sender: TObject);

• procedure SpeedButton3Click(Sender: TObject);
• procedure SpeedButton6Click(Sender: TObject);
• procedure SpeedButton8Click(Sender: TObject);
• procedure SpeedButton10Click(Sender: TObject);
• procedure SpeedButton4Click(Sender: TObject);
• procedure SpeedButton1Click(Sender: TObject);
• procedure SpeedButton5Click(Sender: TObject);
• procedure SpeedButton7Click(Sender: TObject);
• procedure SpeedButton9Click(Sender: TObject);

private { Private declarations }

public { Public declarations }

end;

• var FTPoisk: TFTPoisk;

implementation

uses UDM;

• {$R *.dfm}

procedure TFTPoisk.SpeedButton2Click(Sender: TObject);

• begin DM.Ttov.Locate(‘naz_tov’,LabeledEdit1.Text,[lopartialkey]);
• end;

• procedure TFTPoisk.SpeedButton3Click(Sender: TObject);
• begin DM.Ttov.Locate(‘bez_nds’,strtoint(LabeledEdit2.Text),[]);
• end;

• procedure TFTPoisk.SpeedButton6Click(Sender: TObject);
• begin DM.Ttov.Locate(‘tmb’,LabeledEdit3.Text,[lopartialkey]);
• end;

• procedure TFTPoisk.SpeedButton8Click(Sender: TObject);
• begin DM.Ttov.Locate(‘gost’,LabeledEdit4.Text,[lopartialkey]);
• end;

• procedure TFTPoisk.SpeedButton10Click(Sender: TObject);
• begin DM.Ttov.Locate(‘marka’,LabeledEdit5.Text,[lopartialkey]);
• end;

• procedure TFTPoisk.SpeedButton4Click(Sender: TObject);
• begin close;
• end;

Продолжение приложения 1

procedure TFTPoisk.SpeedButton1Click(Sender: TObject);

• begin close;
• end;

• procedure TFTPoisk.SpeedButton5Click(Sender: TObject);
• begin close;
• end;

• procedure TFTPoisk.SpeedButton7Click(Sender: TObject);
• begin close;
• end;

• procedure TFTPoisk.SpeedButton9Click(Sender: TObject);
• begin close;
• end;

• end.

unit UZakaz; interface uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, ImgList, ComCtrls, ToolWin, Grids, DBGrids, ExtCtrls, StdCtrls,

DBCtrls;

Type TFZakaz = class(TForm)

DBGrid1: TDBGrid; ToolBar1: TToolBar; TBFirst: TToolButton;

• ToolButton2: TToolButton;
• ToolButton3: TToolButton;

• ToolButton4: TToolButton;
• ToolButton5: TToolButton;

• ToolButton6: TToolButton;
• ToolButton7: TToolButton;

• ToolButton1: TToolButton;
• ImageList1: TImageList;

• Panel1: TPanel;
• ToolButton8: TToolButton;

• DBText1: TDBText;
• Label1: TLabel;

• DBText2: TDBText;
• DBText3: TDBText;

• DBText4: TDBText;
• DBText5: TDBText;

• DBText6: TDBText;
• DBText7: TDBText;

• DBText8: TDBText;
• DBText9: TDBText;

• DBText10: TDBText;
• Label2: TLabel;
• Label3: TLabel;

• Label4: TLabel;
• Label5: TLabel;
• Label6: TLabel;

• Label7: TLabel;
• Label8: TLabel;
• Label9: TLabel;

• Shape1: TShape;
• Label10: TLabel;
• Shape2: TShape;

Продолжение приложения 1

Label11: TLabel; Shape3: TShape; Label12: TLabel;

• Edit1: TEdit;
• procedure TBFirstClick(Sender: TObject);

• procedure ToolButton2Click(Sender: TObject);
• procedure ToolButton3Click(Sender: TObject);
• procedure ToolButton4Click(Sender: TObject);
• procedure ToolButton5Click(Sender: TObject);
• procedure ToolButton6Click(Sender: TObject);
• procedure ToolButton7Click(Sender: TObject);
• procedure ToolButton1Click(Sender: TObject);
• procedure ToolButton8Click(Sender: TObject);
• procedure FormActivate(Sender: TObject);
• procedure Edit1Change(Sender: TObject);

private { Private declarations }

public { Public declarations }

end;

var

FZakaz: TFZakaz; a:byte;

implementation

uses UDM, Umain, UDobZakaz;

• {$R *.dfm}

procedure TFZakaz.TBFirstClick(Sender: TObject);

• begin DM.Tzakaz.First;
• end;

• procedure TFZakaz.ToolButton2Click(Sender: TObject);
• begin DM.Tzakaz.Prior;
• end;

• procedure TFZakaz.ToolButton3Click(Sender: TObject);
• begin DM.Tzakaz.Next;
• end;

• procedure TFZakaz.ToolButton4Click(Sender: TObject);
• begin DM.Tzakaz.Last;
• end;

• procedure TFZakaz.ToolButton5Click(Sender: TObject);

Продолжение приложения 1

begin DM.Tzakaz.post; end;

• procedure TFZakaz.ToolButton6Click(Sender: TObject);
• begin DM.Tzakaz.Delete;
• end;

• procedure TFZakaz.ToolButton7Click(Sender: TObject);
• var n:integer;
• begin DM.Tzakaz.Last;
• n:=DM.Tzakaz.FieldByName(‘nz’).Value;

• DM.Tzakaz.Append;
• DM.Tzakaz.FieldByName(‘nz’).Value:=n+1;

• FDobZakaz.show;
• end;

• procedure TFZakaz.ToolButton1Click(Sender: TObject);
• begin case a of 0:begin Height:=697;
• Panel1.Height:=201;
• Position:=poScreenCenter;
• a:=1;
• ToolButton1.ImageIndex:=9;

• ToolButton1.hint:=’Закрыть панель поиска’ end;

1: begin DBGrid1.DataSource:= dm.DSZakaz; Height:=486; Panel1.Height:=0;

• Position:=poScreenCenter;
• a:=0;
• ToolButton1.ImageIndex:=8;

• ToolButton1.hint:=’Открыть панель поиска’;
• Edit1.SetFocus;
• end;
• end;

• end;
• procedure TFZakaz.ToolButton8Click(Sender: TObject);
• begin Fmain.Show;
• close;
• end;

• procedure TFZakaz.FormActivate(Sender: TObject);
• begin a:=0;
• end;

• procedure TFZakaz.Edit1Change(Sender: TObject);
• begin dm.QZakaz1.Close;
• dm.QZakaz1.Parameters[0].

Value:=edit1.Text;

• dm.QZakaz1.Open;
• DBGrid1.DataSource:= dm.DSQZakaz1;
• end;
• end.

unit UZapr;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Buttons, ExtCtrls, DBCtrls, Grids, DBGrids;

Type TForm1 = class(TForm)

DBGrid1: TDBGrid; DBNavigator1: TDBNavigator;

Продолжение приложения 1

SpeedButton2: TSpeedButton; SpeedButton4: TSpeedButton;

• procedure SpeedButton4Click(Sender: TObject);
• procedure SpeedButton2Click(Sender: TObject);

private { Private declarations }

public { Public declarations }

end;

• var Form1: TForm1;

implementation

uses UDM;

• {$R *.dfm}

procedure TForm1.SpeedButton4Click(Sender: TObject);

• begin close;
• end;

• procedure TForm1.SpeedButton2Click(Sender: TObject);
• begin DM.QZapros.Close;
• DM.QZapros.Open;
• end;

• end.

unit UDobTovar;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Buttons, ExtCtrls, StdCtrls, DBCtrls, Mask, BDE;

type

TFDobTov = class(TForm)

GroupBox1: TGroupBox; DBEdit3: TDBEdit; DBEdit5: TDBEdit;

• DBEdit7: TDBEdit;
• DBEdit8: TDBEdit;
• DBEdit9: TDBEdit;

• DBEdit1: TDBEdit;
• DBEdit2: TDBEdit;
• Label1: TLabel;

• Label2: TLabel;
• Label3: TLabel;
• Label4: TLabel;

• Edit1: TEdit;
• Label5: TLabel;
• Label6: TLabel;

• Label7: TLabel;
• Label8: TLabel;
• Label9: TLabel;

• DBComboBox1: TDBComboBox;
• Panel1: TPanel;

Продолжение приложения 1

Panel2: TPanel; SpeedButton1: TSpeedButton;

• SpeedButton2: TSpeedButton;
• SpeedButton3: TSpeedButton;

• SpeedButton4: TSpeedButton;
• DBEdit4: TDBEdit;

• procedure SpeedButton1Click(Sender: TObject);
• procedure SpeedButton2Click(Sender: TObject);
• procedure SpeedButton3Click(Sender: TObject);
• procedure SpeedButton4Click(Sender: TObject);
• procedure FormActivate(Sender: TObject);

private { Private declarations }

public { Public declarations }

end;

• var FDobTov: TFDobTov;

implementation

uses UDM, UTovar;

• {$R *.dfm}

procedure TFDobTov.SpeedButton1Click(Sender: TObject);

begin

DBEdit4.Text:=floattostr(strtofloat(DBEdit3.Text)+(strtofloat(Edit1.text)/100)*strtofloat(DBEdit3.Text)); DM.Ttov.post; end;

• procedure TFDobTov.SpeedButton2Click(Sender: TObject);
• begin DM.Ttov.Append;
• end;

• procedure TFDobTov.SpeedButton3Click(Sender: TObject);
• begin DM.Ttov.Cancel;
• FTovar.Show;
• Close;
• end;

• procedure TFDobTov.SpeedButton4Click(Sender: TObject);
• begin FTovar.Show;
• Close;
• end;

• procedure TFDobTov.FormActivate(Sender: TObject);
• var n:integer;
• begin DM.Ttov.Last;
• n:=DM.Ttov.FieldByName(‘idn’).Value;

• DM.Ttov.Append;
• DM.Ttov.FieldByName(‘idn’).Value:=n+1;
• end;

• end.

Продолжение приложения 1

unit UInvVed1;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, Mask, DBCtrls, Buttons;

type

TFInvVed = class(TForm)

ComboBox1: TComboBox; Label1: TLabel; DBEdit1: TDBEdit;

• SpeedButton1: TSpeedButton;
• SpeedButton2: TSpeedButton;

• procedure FormActivate(Sender: TObject);
• procedure ComboBox1Change(Sender: TObject);
• procedure SpeedButton2Click(Sender: TObject);
• procedure SpeedButton1Click(Sender: TObject);

private { Private declarations }

public { Public declarations }

end;

• var FInvVed: TFInvVed;

implementation

uses UDM, URepIVed;

• {$R *.dfm}

procedure TFInvVed.FormActivate(Sender: TObject);

• begin DM.Tklad.First;
• while not DM.Tklad.Eof do begin

ComboBox1.Items.Add(DM.Tklad.FieldValues[‘fio’]); DM.Tklad.next; end; end;

• procedure TFInvVed.ComboBox1Change(Sender: TObject);
• begin DM.Tklad.Locate(‘fio’,ComboBox1.Text,[]);
• end;

• procedure TFInvVed.SpeedButton2Click(Sender: TObject);
• begin close;
• end;

• procedure TFInvVed.SpeedButton1Click(Sender: TObject);
• begin FRepIVed.QRLabel12.Caption:=DBEdit1.Text;

Продолжение приложения 1

FRepIVed.QRLabel13.Caption:=ComboBox1.Text;

• FRepIVed.QuickRep1.Preview;
• end;

• end.

ПРИЛОЖЕНИЕ 2

Образы экранов