СКАЧАТЬ РАБОТУ БЕСПЛАТНО - 

Содержание
база данные реляционный проектирование
Введение
1. Аналитическая часть
1.1 Описание предметной области
1.1.1 Объект проектирования
1.1.2 Информационные процессы
1.2 Требование к ИС
2. Проектирование базы данных
2.1 Проектирование информационной модели базы данных
2.2 Построение логической модели базы данных
2.3 Построение физической модели данных
2.4 Создание базы данных
3. Создание приложения для работы с базой данных
Заключение
Список литературы
Приложение

 
Введение

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

СКАЧАТЬ РАБОТУ БЕСПЛАТНО - 

1. Аналитическая часть

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

1.1.1 Объект проектирования

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

1.1.2 Информационные процессы

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

Рис.1 Схема бизнес-процесса мебельного салона

Для регистрации клиентов и их заказов используется "регистрационная книга", а предлагаемая продукция находится в каталогах, которые предоставлены производителями. Разрозненность информации делает работу менеджера долгой и малоэффективной, что влечет за собой увеличение времени, затрачиваемого на регистрацию заказа, а если клиент оформляет второй или последующий заказ, то возникает путаница в "регистрационной книге", где одна фамилия фигурирует много раз, делая последующий поиск трудным занятием. К тому же ручная работа менеджера не прибавляет солидности предприятию, а, наоборот, формирует мнение клиента о салоне, как о несостоятельной организации. Использование же общедоступных решений для ввода и хранения данных, например Microsoft Excel, будет не самым правильным выбором, т.к. отсутствует возможность синхронизировать информацию разного рода, например, клиент-заказ-производитель. Поэтому очевидна потребность "Мебельного салона" в централизованной системе управления информацией, способной облегчить труд сотрудника по учету и регистрации заказов и сократить время обслуживания клиента.

1.2 Требования к ИС

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

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

Разрабатываемая для мебельного салона информационная система должна удовлетворять предъявляемым к ней требованиям:

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

Информационная система должна повысить качество сервиса для клиентов фирмы и позволить менеджеру оперативно регистрировать и согласовывать заказы.

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

2.1 Проектирование информационной модели базы данных

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

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

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

Изучив работу менеджера по учету заказов определим информационные объекты для дальнейшей разработки базы данных:

• клиент;
• заказ;
• товар.

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

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

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

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

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

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

Сущность (Entity) – собирательное понятие, некоторая абстракция реально существующего объекта, процесса или явления рассматриваемого предметной области о котором необходимо хранить информацию.

Определим сущности для нашей модели: клиент, заказ, товар.

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

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

Основные предметно-значимые атрибуты имеющихся сущностей:

• КЛИЕНТ - фамилия, имя, отчество, телефон;
• ЗАКАЗ - дата заказа, дата поставки, информация;
• ТОВАР - наименование, цена, производитель, расчетный счет производителя, контактный телефон производителя.

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

Связь (Relationship) – средство представления отношения между сущностями.

На "Рис. 2" представлены три вида связи: один-к-одному, один-ко-многим, много-ко-многим.

Рис. 2 Виды связей

1. Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой).
2. Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи, например один клиент может сделать много заказов.
3. Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.

Обозначенные на "Рис.3" связи между сущностями показывают, что:

- один клиент может сделать много заказов (один-ко-многим);

- заказ оформляется только на один товар (один-к-одному).

Рис. 3 Концептуальная модель

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

2.2 Проектирование логической модели данных

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

Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных.

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

Отношение – это плоская таблица, состоящая из столбцов и строк.

Атрибут - это поименованный столбец отношения.

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

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

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

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

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

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

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

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

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

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

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

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

• для таблицы КЛИЕНТ – это № клиента;
• для таблицы ЗАКАЗ – это № заказа;
• для таблицы ТОВАР – это № производителя.

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

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

• для таблицы ЗАКАЗ – это № клиента, № товара;
• для таблицы ТОВАР – это № товара;
• для таблицы ПРОИЗВОДИТЕЛЬ – это № производителя.

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

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

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

Рис. 4 Логическая модель

На "рис. 4" связь между таблицами обозначены в виде стрелок с указателями:

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

2.3 Построение физической модели данных

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

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

Database Desktop - это редактор файлов баз данных dBASE и Paradox от фирмы Borland.

Создадим физическую модель наших данных в формате таблиц Paradox:

Рис. 5 Физическая модель

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

Таблица meb_client.dbf для размещения данных о клиентах салона.

Таблица meb_zacaz.dbf для размещения данных о заказах салона.

Таблица meb_proizvod.dbf для размещения данных о производителях, чей товар представлен в салоне.

2.4 Создание базы данных

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

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

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

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

Создадим каталог на диске Е: и назовем его "meb_salon", далее при помощи BDE Administrator создадим одноименный псевдоним и укажем ему путь "E:\meb_salon ".

Далее перейдем к созданию таблиц нашей БД. Для этого откроем компонент Delphi - Database Desktop (DBD) и для удобства дальнейшей работы в главном меню File выберем Working directory и выберем рабочим псевдонимом "meb_salon", с которым DBD будет работать по умолчанию.

Создадим четыре таблицы:

1. meb_client.dbf (клиенты);
2. meb_zacaz.dbf (заказы);
3. meb_meb.dbf (товар);
4. meb_proizv.dbf (производители)

и заполним их, как описано выше.

Всем полям назначим атрибут Required (требование обязательного существования значения на момент его запоминания в БД), кроме поля N_zac, поскольку это поле имеет тип Autoincrement т.е. автоматическое заполнение при запоминании новой записи.

Далее нам необходимо определить ссылочную целостность таблиц и задать вид каскадных воздействий (отражение изменений одной записи на связанных записях в других таблицах). Для этого откроем таблицу meb_zacaz (заказы) и в режиме изменения структуры таблицы (Table \ Restructure) в списке свойств (Table Properties) выберем элемент Refrential Integrity. Затем, нажав кнопку Define, создадим ссылочную целостность.

Рис.6 Создание ссылочной целостности для поля N_cli.

Выбрав поле N_cli в списке, расположенном слева, определим его, как внешний ключ к родительской таблице meb_client справа. В поле Update rule поставим флажок у надписи Cascade (каскадное изменение и удаление подчиненных записей). То же самое проделаем с полем N_meb, присвоив ему родительскую таблицу meb_meb, далее определим ссылки у таблицы meb_meb в относительно таблицы meb_proizv по полю N_pro. Всем ссылочным определениям присвоим имена и сохраним. При создании ссылочной целостности в таблицах с внешними ключами автоматически создаются индексы по их неявному определению:

• meb_zacaz – N_cli, N_meb;
• meb_meb – N_pro.

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

3. Создание приложения для работы с базой данных

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

Запустим Delphi и создадим главную форму нашего приложения Form1. Далее перейдем к инспектору объектов и в свойстве Caption введем "Мебельный салон. Учет заказов", тем самым присвоив нашей форме заголовок.

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

• В левой части разместим элемент PageConrol1 и добавим к нему два окна TabSheet1 и TabSheet2. Две получившиеся вкладки переименуем в инспекторе объектов и присвоим им имена "Добавить новый заказ" и "Клиенты".
• На правой половине разместим элементы Panel1 и Panel2, разделив тем самым ее на две части. В верхней ее половине на Panel1 далее реализуем просмотр информации, а в нижней Panel2 будут располагаться элементы для ввода новых данных о товаре и производителе.

Рис.7 Дерево объектов после размещения элементов

Разметив окно будущей программы, перейдем к созданию основных элементов. Начнем со страницы PageControl1 / "Клиенты". Открыв вкладку BDE, выберем и разместим четыре компонента Table и один Query:

• Table1;
• Table2;
• Table3;
• Table4;
• Query1.

Для связи компонентов Table с имеющейся базой данных meb_salon перейдем в инспектор объектов и выберем у свойства DatabaseName в выпадающем списке ранее созданный псевдоним "meb_salon". Далее в свойстве TableName определим для каждого компонента свою таблицу:

• meb_client.db для Table1;
• meb_zacaz.db для Table2;
• meb_meb.db для Table3;
• meb_proizvod.db для Table4,

а поскольку нам необходимо реализовать поиск клиентов, то

• meb.client.db для Query1.

Для отображения данных добавим из вкладки Управление данными четыре компонента DBGrid:

• DBGrid1;
• DBGrid2;
• DBGrid3;
• DBGrid4.

Для соединения компонентов Table и Query c элементами для отображения DBGrid добавим, перейдя на вкладку Доступ к данным, пять компонентов DataSourse:

• DataSourse1;
• DataSourse2;
• DataSourse3;
• DataSourse4;
• DataSourse5.

Установим связь элементов DataSourse c компонентами Table и Query, присвоив в свойстве DataSet первого соответствующие значения:

• Table1 для DataSourse1;
• Query1 для DataSourse2;
• Table2 для DataSourse3;
• Table3 для DataSourse4;
• Table4 для DataSourse5.

Далее соединим элементы отображения DBGrid с нужными нам DataSourse:

• DataSourse1для DBGrid1;
• DataSourse3для DBGrid2;
• DataSourse4для DBGrid3;
• DataSourse5для DBGrid4.

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

Для отображения заказов выбранного клиента обеспечим связь отвечающего за это компонента Table2 с таблицей Table1:

• в свойстве MasterSourse введем значение DataSourse1;
• открыв свойство MasterFields, создадим объединенное поле N_cli у таблиц meb_client и meb_zacaz;
• открыв свойство IndexName, выберем имя индекса N_cli.

Для отображения приобретенного клиентом товара обеспечим связь отвечающего за это компонента Table3 с таблицей Table2:

• в свойстве MasterSourse введем значение DataSourse3;
• открыв свойство MasterFields, создадим объединенное поле N_meb у таблиц meb_zacaz и meb_meb;
• открыв свойство IndexFieldName, выберем имя индекса N_meb.

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

• в свойстве MasterSourse введем значение DataSourse4;
• открыв свойство MasterFields, создадим объединенное поле N_pro у таблиц meb_meb и meb_proizvod;
• открыв свойство IndexFieldName, выберем имя индекса N_pro.

После этого поставим свойство Active компонентов Table в значение True, активизировав тем самым соединение с базой данных.

Организовав таким образом связи, мы получим отображение отдельной информации по выбранному клиенту. Для удобства навигации в списке клиентов, отображаемом в DBGrid, установим из вкладки Управление данными компонент DBNavigator1 и присвоим его свойству DataSourse значение DataSourse1. Помимо навигатора добавим быстрый переход к нужному номеру клиента при помощи двух процедур SetKey, GotoKey и индексированного поля N_cli. Для этого установим элемент для ввода номера клиента Edit (назовем его Edit_Go) и, создав кнопку Button (назовем ее Go_N_cli), напишем процедуру обработки ее нажатия:

procedure TForm1.Go_N_cliClick(Sender: TObject);

begin

Table1.SetKey;

Table1.FieldByName('N_cli').AsString := Edit_Go.Text;

Table1.GotoKey;

end;

Рис.8 Фрагмент формы с полем ввода № клиента и кнопкой запуска

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

Из вкладки Управление данными выберем компонент RadioGroup и установим его. Далее в инспекторе объектов в свойстве Items создадим три переключателя: Фамилии, Имени, Отчеству. Сделаем переключатель поиска по фамилии выбранным по умолчанию, установив в свойстве ItemIndex значение 0 (так как нумерация начинается с 0). Поле для ввода искомых данных создадим при помощи компонента Edit (назвав его Edit_searsh). Далее напишем для этого компонента процедуру обрабатывающую событие OnChange:

procedure TForm1.Edit_searshChange(Sender: TObject);

var

strField:string; // создадим переменную для подстановки

begin

// выбираем поля поиска

case RadioGroup1.ItemIndex of

0: strField:='Fam';

1: strField:='Imya';

2: strField:='Otch';

end;

// выполняем поиск

Query1.Close;

Query1.SQL.Clear; // ' LIKE "%'+Edit_searh.Text+'%"' – ищем фрагмент текста

Query1.SQL.Add('Select * from meb_client where '+strField+' LIKE "'+Edit_searsh.Text+'%"');

Query1.Open;

Query1.FieldByName('Fam').DisplayLabel:='Фамилия';

Query1.FieldByName('Name').DisplayLabel:='Имя';

Query1.FieldByName('Otch').DisplayLabel:='Отчество';

end;

Для переключения DBGrid1 и остальных с ним связанных компонентов в режим поиска и обратно в режим просмотра создадим две кнопки Button: OnSearsh, OffSearsh.

Напишем для них процедуры обработки OnClick:

procedure TForm1.OnSearshClick(Sender: TObject); // включение режима поиска

begin

DBGrid1.DataSource:=DataSource2;

end;

procedure TForm1.OffSearshClick(Sender: TObject); // включение режима просмотра

begin

DBGrid1.DataSource:=DataSource1;

end;

Рис. 9 Фрагмент формы с компонентами управления поиском

Следующим шагом в разработке приложения реализуем вывод отчетов по клиентам салона. Для этого добавим к форме три компонента из вкладки Rave:

• RvProject1;
• RvSystem1;
• RvDataSetConnection1.

1. Присвоим свойству DataSet у RvDataSetConnection1значение Table. Далее вызвав контекстное меню нажатием правой кнопкой на RvProject запустим визуальный дизайнер отчетов Rave Visual Designer.
2. Потом выбираем Project / New Data Object из главного меню для выбора диалога Data Connections. Выбераем Direct Data View и затем Next. Убедившись, что выбран нужный элемент в списке Active Data Connections нажмимаем кнопку OK.
3. Перейдя в дерево проекта (Locate the Project Tree - дерево в левой части визуального дизайнера) открываем Data View Dictionary и выбераем новый просмотр данных, DataView1, который только что мы создали. А дальше при помощи дизайнера создадим отчет "Рис.10".

Рис.10 Разработка отчета в Rave Visual Designer

Рис. 11 Разработанный отчет

4. Сформированный отчет сохраним в каталоге с разрабатываемым приложением и укажем путь в свойствах RvProject1

Рис. 12 Инспектор объектов RvProject1

Свойству Engine присвоим RvSystem.

5. Добавим на форму две кнопки Button1 и Button2. Напишем процедуры для Button1- вывод на просмотр и для Button2 – вывод на печать.

procedure TForm1.Button1Click(Sender: TObject); // вывод на просмотр

begin

RvSystem1.DefaultDest:=rdPreview;

RvProject1.Execute;

end;

procedure TForm1.Button2Click(Sender: TObject); // вывод на печать

begin

RvSystem1.DefaultDest:=rdPrinter;

RvProject1.Execute;

end;

На этом закончим разработку части приложения находящейся на странице Клиенты компонента PageControl1.

Рис. 13 Интерфейс приложения на странице Клиенты компонента PageControl1

Далее перейдем к странице Добавить новый заказ компонента PageControl1. Здесь необходимо реализовать ввод данных о новых заказах. Для этого добавим на форму 10 элементов Edit и кнопку Button (назовем ее Registration). Каждому элементу Edit для удобства напишем в свойстве Name имя, например Edit отвечающий за ввод номера клиента назовем Edit_N_cli и т.д.

Для ввода данных напишем процедуру обработки события OnClick для кнопки Registration:

procedure TForm1.RegistrationClick(Sender: TObject);

begin

Table1.Append;

Table1.FieldByName('N_cli').AsString := Edit_N_cli.Text;

Table1.FieldByName('Fam').AsString := Edit_Fam.Text;

Table1.FieldByName('Name').AsString := Edit_Name.Text;

Table1.FieldByName('Otch').AsString := Edit_Otch.Text;

Table1.FieldByName('Tel').AsString := Edit_Tel.Text;

Table1.Post;

// добавляем данные в элемент Table1 связанный с таблицей meb_client

Table5.Append;

Table5.FieldByName('N_cli').AsString := Edit_N_cli.Text;

Table5.FieldByName('N_pro').AsString := Edit_N_pro.Text;

Table5.FieldByName('N_meb').AsString := Edit_N_meb.Text;

Table5.FieldByName('Dat_zac').AsString := Edit_Dat_zac.Text;

Table5.FieldByName('Dat_post').AsString := Edit_Dat_post.Text;

Table5.FieldByName('Dop_info').AsString := Edit_Dop_info.Text;

Table5.Post;

// добавляем данные в элемент Table5 связанный с таблицей meb_zacaz

end;

Рис. 14 Интерфейс на странице Добавить новый заказ компонента PageControl1

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

• DBGrid6;
• Table5;
• Table6;
• Table7;
• DataSourse6;
• DataSourse7;
• DataSourse8;