База данных «Нотариальная контора»

     Дата/время  – тип данных для хранения календарных дат и текущего времени.

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

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

     Логический  - тип для хранения логических данных (могут принимать только два значения, например Да или Нет).

     Гиперссылка – специальное поле для хранения адресов URL Web-объектов Интернета. При щелчке на ссылке автоматически происходит запуск броузера и воспроизведение объекта в его окне.

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

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

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

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

1.3 Проектирование баз данных

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

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

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

• 1.4 СУБД MS Access

• 1.4.1 Объекты базы данных
 


     Таблицы – это основные объекты любой  базы данных. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру базы (поля, их типы и свойства).

     Запросы.

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

     Формы.

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


     Отчеты.

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

     Страницы.

     Это специальные объекты баз данных, реализованных в последних версиях  СУБД Microsoft Access (начиная с  Access 2000). Правда, более коректно их называть страницами доступа к данным. Физически это особый объект, выполненный в коде HTML, размещаемый на Web-странице и передаваемый клиенту вместе с ней. Сам по себе этот объект не является базой данной, но содержит компоненты, через которые осуществляется связь переданной Web-страницы с базой данных, остающейся на сервере. Пользуясь этими компонентами, посетитель Web-узла может просматривать записи базы в полях страницы доступа. Таким образом, страницы доступа к данным осуществляют интерфейс между клиентом, сервером и базой данных, размещенной на сервере. Эта база данных не обязательно должна быть базой данных Microsoft Access. Страницы доступа, созданные средствами Microsoft Access, посволяют работать также с базами данных Microsoft SQL Server.

     Макросы и модули.

     Эти категории объектов предназначены  как для автоматизации повторяющихся операций при работе с СУБД, так и для создания новых функций путем программирования. В СУБД Microsoft Access макросы состоят из последовательности внутренних команд СУБД и являются одним из средств автоматизации работы с базой. Модули создаются средствами внешнего языка программирования, в данном случае языка Visual Basic for Applications. Это одно из средств, с помощью которых разработчик базы может заложить в нее нестандартные функциональные возможности, удовлетворить специфическое требование заказчика, повысить быстродействие системы управления, а также уровень ее защищенности.

     1.4.2 Разработка структуры  базы данных

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

     1. Работа начинается с составления  генерального списка полей –  он может насчитывать десятки  и даже сотни позиций.

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

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

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

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

     6. Разработкой схемы данных заканчивается  «бумажный» этап работы над  техническим предложением. Эту схему  можно согласовать с заказчиком, после чего приступать к непосредственному  созданию базы данных.

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

       1.5 Технология ADO. Основы ADO

       Технология Microsoft ActiveX Data Objects обеспечивает универсальный  доступ к источникам данных из приложений БД. Такую возможность предоставляют  функции набора интерфейсов, созданные  на основе общей модели объектов СОМ  и описанные в спецификации OLE DB.

       

       Рис. 1. Технология ADO

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

       Возникает вопрос: каким образом источники  данных смогут выполнить этот запрос? За серверы БД беспокоиться не стоит, обработка запросов SQL — это их основная обязанность. Но как быть с файловыми последовательностями, электронными таблицами, файлами электронной почты и т. д.? Здесь на помощь приходят механизмы ADO и интерфейсы OLE DB. OLE DB представляет собой набор специализированных объектов СОМ, инкапсулирующих стандартные функции обработки данных, и специализированные функции конкретных источников данных и интерфейсов, обеспечивающих передачу данных между объектами.

Согласно  терминологии ADO, любой источник данных (база данных, электронная таблица, файл) называется хранилищем данных, с которым при помощи провайдера данных взаимодействует приложение. Минимальный набор компонентов приложения может включать объект соединения, объект набора данных, объект процессора запросов. Объекты OLE DB создаются и функционируют так же, как и другие объекты СОМ. Каждому объекту соответствует идентификатор класса CLSID, хранящийся в системном реестре. Для создания объекта используется метод CoCreateinstance и соответствующая фабрика класса. Объекту соответствует набор интерфейсов, к методам которых можно обращаться после создания объекта.

       В результате приложение обращается не прямо к источнику данных, а  к объекту OLE DB, который "умеет" представить данные (например, из файла электронной почты) в виде таблицы БД или результата выполнения запроса SQL.

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

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

       Так как технология ADO основана на стандартных  интерфейсах СОМ, которые являются системным механизмом Windows, это сокращает  общий объем работающего программного кода и позволяет распространять приложения БД без вспомогательных программ и библиотек.  
 
 
 
 
 
 
 
 


Глава 2. Практическая часть

       2.1 Описание предметной  области

       2.2 Разработка структуры  базы данных

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

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

       Таблицы:

       Клиенты (код клиента ,код адресса, название, вид деятельности, телефон)

       Услуги ( Код услуги, название , описание, скидки)

       Сделки (Код сделки, код услуги, код клиента, сумма , комиссионные, описание)

       Адрес (Код адреса, город, улица,дом) 


       На  основе вышеописанной предметной области  разработаем структуру базы данных в MS Access.

       Таблица1. Клиенты

Имя поля	Код клиента
Тип данных	Счетчик
Размер  поля	Длинное целое
Число десятичных знаков	Авто
Обязательное поле	Да
Индексированное поле	Да (Совпадения не допускаются)
Имя поля	Код адреса
Тип данных	Числовой
Размер  поля	50
Обязательное  поле	да
Индексированное поле	да
Имя поля	Вид деятельности
Тип  данных	Текстовый
Размер  поля	100
Обязательное  поле	Да
Индексированное поле	Нет
Имя поля	Номер телефона
Тип  данных	Числовой
Размер  поля	Длинное целое
Обязательное  поле	Да
Индексированное поле	Нет
Имя поля	Название
Тип  данных	Текстовый
Размер  поля	100
Обязательное  поле	Да
Индексированное поле	Нет

 


       Таблица 2. Услуги

Имя поля	Код услуги
Тип данных	Счетчик
Размер  поля	Длинное целое
Число десятичных знаков	Авто
Обязательное  поле	Да
Индексированное поле	Да(Совпадения не допускаются)
Имя поля	Название услуги
Тип данных	Текстовый
Размер  поля	Длинное целое
Обязательное  поле	Да
Индексированное поле	Нет
Имя поля	Описание  услуги
Тип данных	Текстовый
Размер  поля	Длинное целое
Обязательное  поле	да
Индексированное поле	нет
Имя поля	Скидка
Тип данных	Числовой
Размер  поля	50
Обязательное поле	Нет
Индексированное поле	Нет

 
 
 


       Таблица3. Сделки

Имя поля	Код Сделки
Тип данных	Числовой
Размер  поля	Длинное целое
Число десятичных знаков	Авто
Значение  по умолчанию	0
Обязательное  поле	Да
Индексированное поле	Да (Совпадения не допускаются)
Имя поля	Код услуги
Тип данных	Числовой
Размер  поля	Длинное целое
Число десятичных знаков	Авто
Значение  по умолчанию	0
Обязательное  поле	Да
Имя поля	Код клиента
Тип данных	Числовой
Размер  поля	Длинное целое
Число десятичных знаков	Авто
Значение  по умолчанию	0
Обязательное  поле	да
Индексированное поле	Да (Допускаются  совпадения)
Имя поля	Описание
Тип данных	Текстовый
Размер  поля	50
Обязательное  поле	Да
Индексированное поле	Нет
Имя поля	Сумма
Тип данных	Денежный
Размер  поля	50
Обязательное  поле	да
Индексированное поле	нет
Имя поля	Комиссионные
Тип данных	Денежный
Размер  поля	50
Обязательное  поле	да
Индексированное поле	нет

       Таблица 4: Адрес

Имя поля	Код Адреса
Тип данных	Счетчик
Размер  поля	Длинное целое
Число десятичных знаков	Авто
Значение  по умолчанию	0
Обязательное  поле	Да
Имя поля	Улица
Тип данных	Текстовый
Размер  поля	Длинное целое
Число десятичных знаков	Авто
Значение  по умолчанию	0
Обязательное  поле	Да
Имя поля	Дом
Тип данных	числовой
Размер  поля	Длинное целое
Число десятичных знаков	Авто
Значение  по умолчанию	0
Обязательное  поле	Да
Имя поля	Город
Тип данных	Текстовый
Размер  поля	Длинное целое
Число десятичных знаков	Авто
Значение  по умолчанию	0
Обязательное  поле	Да

 


       Схема 1. Схема данных

 

       2.3 Инфологическая модель  данных

       Предметная  область – часть реального  мира отражённая в базу данных. Объединяя  частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных. Цель инфологического моделирования – обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком. Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).

       Сущность – любой реальный или не реальный различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.

       Атрибут – поименованная характеристика сущности. Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: Красный, Синий, Банановый, Белая ночь и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута. Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Например, для автомобильного завода цвет – это только атрибут продукта производства, а для лакокрасочной фабрики цвет – тип сущности.

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

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

       Заключение 


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

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


Список  использованной литературы

   1.Н. Н. Гринченко, Е. В. Гусев, Н. П. Макаров «Проектирование баз данных. СУБД Microsoft Access. Учебное пособие Access», Горячая Линия – Телеком, 2004 г.

    2.  Фаронов В. В. «Delphi, язык и среда программирования. Специальные вопросы и полезные советы», 1-е издание, 2006 год, 464 стр.

      3.Фаронов В.В. «Программирование баз данных в Delphi 7», Питер, 2006

       4.Дейт К., "Введение в системы баз данных", Москва, 'Hаука', 1980 г.

      5.www.sources.ru 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 


       Приложение

       Исходный код программы

       unit Unit1; 


       interface 


       uses

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

         Dialogs, Menus, StdCtrls; 


       type

         TForm1 = class(TForm)

           MainMenu1: TMainMenu;

           N1: TMenuItem;

           N2: TMenuItem;

           N5: TMenuItem;

           N6: TMenuItem;

           N7: TMenuItem;

           N9: TMenuItem;

           N10: TMenuItem;

           Label1: TLabel;

           Label2: TLabel;

           N11: TMenuItem;

           N12: TMenuItem;

           N13: TMenuItem;

           N3: TMenuItem;

           N4: TMenuItem;

           N8: TMenuItem;

           procedure N2Click(Sender: TObject);

           procedure N3Click(Sender: TObject);

           procedure N8Click(Sender: TObject);

           procedure N4Click(Sender: TObject);

           procedure N9Click(Sender: TObject);

           procedure N10Click(Sender: TObject);

           procedure N5Click(Sender: TObject);

           procedure N12Click(Sender: TObject);

           procedure N13Click(Sender: TObject);

         private

           { Private declarations }

         public

           { Public declarations }

         end; 


       var

         Form1: TForm1; 


       implementation 


       uses Unit2, Unit3, Unit4, Unit5, Unit7, Unit8, Unit6, Unit9, Unit14; 


       {$R *.dfm} 


       procedure TForm1.N2Click(Sender: TObject);

       begin

       Form3.Show;

       end; 


       procedure TForm1.N3Click(Sender: TObject);

       begin

       Close;

       end; 


       procedure TForm1.N8Click(Sender: TObject);

       var j:string;

       begin

       j:=InputBox('Введите название города','','');

       DataSvazka.Gorod.Close;

       DataSvazka.Gorod.SQL.Clear;

       DataSvazka.Gorod.SQL.Add('SELECT адресс.город, Клиенты.Название, Клиенты.[Номер телефона]');

       DataSvazka.Gorod.SQL.Add('FROM адресс INNER JOIN Клиенты ON адресс.Код_адресса = Клиенты.Код_адреса');

       DataSvazka.Gorod.SQL.Add('where (адресс.город Like "%'+j+'%")');

       DataSvazka.Gorod.Open;

       Form14.QuickRep1.Preview;

       end; 


       procedure TForm1.N4Click(Sender: TObject);

       begin

          Form5.Show;

       end; 


       procedure TForm1.N9Click(Sender: TObject);

       var i:string;

       begin

          i:=InputBox('Введите название фирмы клиента','','');

       DataSvazka.infaklient.Close;

       DataSvazka.infaklient.SQL.Clear;

       DataSvazka.infaklient.SQL.Add('SELECT Клиенты.Название, Сделки.Описание, Сделки.Сумма');

       DataSvazka.infaklient.SQL.Add('FROM Клиенты INNER JOIN Сделки ON Клиенты.Код_клиента = Сделки.Код_клиента');

       DataSvazka.infaklient.SQL.Add('where (Клиенты.Название Like "%'+i+'%")');

       DataSvazka.infaklient.Open;

       Form7.QuickRep1.Preview;

       end; 


       procedure TForm1.N10Click(Sender: TObject);

       begin

        DataSvazka.InfaSdelki.Close;

       DataSvazka.InfaSdelki.SQL.Clear;

       DataSvazka.InfaSdelki.SQL.Add('SELECT Сделки.[Код_сделки], Сделки.[Описание], Сделки.Сумма, Сделки.Комиссионые, Клиенты.Название');

       DataSvazka.InfaSdelki.SQL.Add('FROM  Клиенты INNER JOIN Сделки ON Клиенты.[Код_клиента] = Сделки.[Код_клиента]');

       DataSvazka.InfaSdelki.Open;

       Form8.QuickRep1.Preview;

       end; 


       procedure TForm1.N5Click(Sender: TObject);

       begin

       Form6.Show;

       end; 


       procedure TForm1.N12Click(Sender: TObject);

       begin

         datasvazka.sdelki.Active:=False;

       datasvazka.sdelki.Active:=True;

       datasvazka.uslugi.Active:=False;

       datasvazka.uslugi.Active:=True;

       datasvazka.client.Active:=False;

       datasvazka.client.Active:=True;

       datasvazka.adress.Active:=false;

        datasvazka.adress.Active:=True;

       form4.showmodal; 


       end; 


       procedure TForm1.N13Click(Sender: TObject);

       begin

       form9.DBEdit1.Text:='';

       form9.DBEdit2.Text:='';

       form9.DBEdit3.Text:='';

       form9.DBEdit4.Text:='';

       form9.DBEdit5.Text:='';

       form9.DBEdit6.Text:='';

       form9.DBEdit7.Text:='';

       form9.DBEdit8.Text:='';

       form9.DBEdit9.Text:='';

       form9.DBEdit1.Enabled:=false;

       form9.DBEdit2.Enabled:=false;

       form9.DBEdit3.Enabled:=false;

       form9.DBEdit4.Enabled:=false;

       form9.DBEdit5.Enabled:=false;

       form9.DBEdit6.Enabled:=false;

       form9.DBEdit7.Enabled:=false;

       form9.DBEdit8.Enabled:=false;

       form9.DBEdit9.Enabled:=false;

       form9.DBLookupComboBox1.Enabled:=false;form9.DBLookupComboBox2.Enabled:=false;

        form9.DBLookupComboBox3.Enabled:=false;

        form9.Button2.Enabled:=false;

        form9.Button3.Enabled:=false;

        form9.Button5.Enabled:=false;

        form9.Button6.Enabled:=false;

        form9.Button7.Enabled:=false; 


       form9.showmodal;

       end;

       end.

       

       Рис. 2. Интерфейс программы