МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ

РЕСПУБЛИКИ ДАГЕСТАН

Дагестанский Государственный Технический Университет

Кафедра ВТ

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА К КУРСОВОМУ ПРОЕКТУ

Тема: Программа ведения базы данных торговой фирмы

Проверил:

Асс. Бахмудов А.М.

«____» ______ 2009 г.

Выполнил:

студент Нуралиев Д.И.

специальность ВМКСиС

группа У-731

«___» _______ 2009 г.

Махачкала 2009

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1 ЗАДАНИЕ

2 КРАТКАЯ ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

2.1 Объектно-ориентированная модель

2.2 Реляционная база данных

2.3 Объектно-реляционная модель

2.4 Объектно-ориентированные базы данных

2.5 Стандартные объекты базы данных

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

2.7 Организация связи с базами данных в Delphi

3. ОСНОВНАЯ ЧАСТЬ

3.1 Алгоритм программы

3.2 Описание программы

3.2.1 Создание таблиц

3.2.2 Создание нового источника данных

3.2.3 Создание форм

3.2.4 Создание справочной системы

3.3 Логическая структура программы

4 ОПИСАНИЕ КОНТРОЛЬНОГО ПРИМЕРА

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЕ А Программный продукт

ПРИЛОЖЕНИЕ Б Листинг программ

ВВЕДЕНИЕ

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

обеспечивать получение общих и/или детализированных отчетов по итогам работы;

позволять легко определять тенденции изменения важнейших показателей;

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

выполнять точный и полный анализ данных.

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

Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер». Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще - диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе «открытом подходе», то есть необходимость и возможность использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных. Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических»

СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».

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

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

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

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

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

Данная курсовой проект разработан в Интегрированной Среде Разработки (ИСР или Integrated development environment - IDE) Delphi, занимающая самые передовые позиции в работе с любыми системами управления базами данных.

ЗАДАНИЕ

Вариант-2

Создать программу ведения базы данных торговой фирмы. Программа включает в себя: формирование и корректировку файлов данных; расчет комиссионного вознаграждения сотрудников фирмы. Файл данных о продавце включает его имя и фамилию, табельный номер, дату поступления на работу. Торговая фирма выплачивает продавцам комиссионное вознаграждение в размере 5 %, если товара продано на сумму менее 1000 рублей/день и выше. Продавцы, проработавшие в фирме более 10 лет, получают комиссионные на 1 % выше. Сумма выручки водится с клавиатуры персонального компьютера. Организуйте ввод общих итогов по сумме выручки и сумме комиссионного вознаграждения.

2. КРАТКАЯ ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

2.1 Объектно-ориентированная модель

Управление информацией всегда было основной сферой применения компьютеров и, надо думать, будет играть еще большую роль в будущем. Системы управления базами данных (СУБД, DBMS - Database Management System) на протяжении всего пути развития компьютерной техники совершенствовались, поддерживая все более сложные уровни абстрактных данных, заданных пользователем, и обеспечивая взаимодействие компонентов, распределенных в глобальных сетях и постепенно интегрирующихся с телекоммуникационными системами. Позволив себе рассуждения в стиле Билла Гейтса, предположим, что результатом будет становление систем управления информацией одной из частей повседневной жизни каждого. История развития компьютерной техники - это история непрерывного движения от языка и уровня коммуникации машины к уровню пользователя. Если первые машины требовали от пользователя оформления того, что ему нужно (то есть написания программ), в машинных кодах, то языки программирования четвертого уровня (4GLs) позволяли конечным пользователям, не являющимся профессиональными программистами, получать доступ к информации без детального описания каждого шага, но только с встроенными предопределенными типами данных - например, таблицами. Последним шагом в этом направлении стала объектно-ориентированная технология, радикально изменившая сферу разработки программного обеспечения уже в 1990-х годах. Объектно-ориентированный подход позволяет упаковывать данные и код для их обработки вместе. Таким образом практически снимается ограничение на типы данных, позволяя работать на любом уровне абстракции. Эволюция систем управления информацией шла параллельно этому прогрессу, начиная с низкоуровневых программ, которые, например, напрямую производили операции чтения и записи со всей памятью без ограничения доступа, лентой, цилиндрами и дорожками диска и более высокоуровневыми средствами - файловыми системами, которые оперировали с такими понятиями, как массивы, записи и индексы для повышения производительности. Базы данных в свою очередь начинали с модели записей и индексов (ISAM и др.), приобретая со временем способность восстановления после сбоев, проверки целостности данных и возможности работы нескольких пользователей одновременно. Эти ранние модели данных (CODASYL) относились скорее к уровню машинной ориентации. В дальнейшем реляционные базы данных, пришедшие на смену в 1980_х годах, приобрели механизм запросов, позволяющий пользователю указать требуемое, предоставив СУБД самой оптимальным образом найти результат, используя динамическую индексацию.

Объектно-ориентированные СУБД (ООСУБД) стали разрабатываться с середины 80_х годов в основном для поддержки приложений САПР. Сложные структуры данных систем автоматизированного проектирования оказалось очень удобно оформлять в виде объектов, а технические чертежи проще хранить в базе данных, чем в файлах. Это позволяет обойтись без декомпозиции графических структур на элементы и записи их в файлы после завершения работы с чертежом, выполнения обратной операции при внесении любого изменения. Если типичные реляционные базы данных имеют связи глубиной в два уровня, то иерархическая информация чертежей САПР обычно включает порядка десяти уровней, что требует достаточно сложных операций для “сборки” результата. Объектные базы данных хорошо соответствовали подобным задачам, и эволюция многих СУБД началась именно с рынка САПР. Между тем рынок САПР был быстро насыщен, и в начале 90_х годов производители ООСУБД обратили внимание на другие области применения, уже прочно занятые реляционными СУБД. Для этого потребовалось оснастить ООСУБД функциями оперативной обработки транзакций (OLTP), утилитами администратора баз данных (database administrator - DBA), средствами резервного копирования/восстановления и т. д. Работы в данном направлении продолжаются и сегодня, но уже можно сказать, что переход к коммерческим приложениям идет достаточно успешно.

2.2 Реляционные базы данных

В реляционных базах данных (Relational Database System, RDBS) все данные отображаются в двумерных таблицах. База данных, таким образом, это ни что иное, как набор таблиц. RDBS и ориентированные на записи системы организованы на основе стандарта B-Tree или методе доступа, основанном на индексации - Indexed Sequential Access Method (ISAM) и являются стандартными системами, использующимися в большинстве современных программных продуктов. Для обеспечения комбинирования таблиц для определения связей между данными, которые практически полностью отсутствуют в большинстве программных реализаций B-Tree и ISAM, используется языки, подобные SQL (IBM), Quel (Ingres) и RDO (Digital Equipment), причем стандартом отрасли в настоящее время стал язык SQL, поддерживаемый всеми производителями реляционных СУБД. Оригинальная версия SQL - это интерпретируемый язык, предназначенный для выполнения операций над базами данных. Язык SQL был создан в начале 70_х как интерфейс для взаимодействия с базами данных, основанными на новой для того времени реляционной теории. Реальные приложения обычно написаны на других языках, генерирующих код на языке SQL и передающих их в СУБД в виде текста в формате ASCII. Нужно отметить также, что практически все реальные реляционные (и не только реляционные) системы помимо реализации стандарта ANSI SQL, известного сейчас в последней редакции под именем SQL2 (или SQL-92), включают в себя дополнительные расширения, например, поддержка архитектуры клиент-сервер или средства разработки приложений. Строки таблицы составлены из полей, заранее известных базе данных. В большинстве систем нельзя добавлять новые типы данных. Каждая строка в таблице соответствует одной записи. Положение данной строки может изменяться вместе с удалением или вставкой новых строк. Чтобы однозначно определить элемент, ему должны быть сопоставлены поле или набор полей, гарантирующих уникальность элемента внутри таблицы. Такое поле или поля называются первичным ключом (primary key) таблицы и часто являются числами. Если одна таблица содержит первичным ключ другой, это позволяет организовать связь между элементами разных таблиц. Это поле называется внешним ключом (foreign key). Так как все поля одной таблицы должны содержать постоянное число полей заранее определенных типов, приходится создавать дополнительные таблицы, учитывающие индивидуальные особенности элементов, при помощи внешних ключей. Такой подход сильно усложняет создание сколько нибудь сложных взаимосвязей в базе данных. Желающим убедится, что это действительно так и не пожалевшим на это определенный отрезок времени, компания POET Software любезно предоставляет возможность ознакомиться с примером в своей “белой книге” “POET Technical Reference”. База данных рядового предприятия общепита (клиенты - Джордж Буш и Эдди Мэрфи) состоит из четырех таблиц.

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

2.3 Объектно-реляционные методы

Несмотря на рассмотренные в п. 0 недостатки реляционных баз данных, они обладают рядом достоинств:

разделение таблиц разными программами;

развернутый “код возврата” при ошибках;

высокая скорость обработки запросов (команда SELECT языка SQL; результатом выборки является таблица, которая содержит поля, удовлетворяющие заданному критерию);

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

График 2.1. Возможные подходы к объединению объектных и реляционных БД

2.4 Объектно-ориентированные базы данных

“Белыми книгами” с названием, вынесенным в заголовок, с избытком снабдит любая компания, занимающаяся объектными базами данных. Кое-что о преимуществах и недостатках объектно-ориентированных СУБД уже упоминалось выше, подведем в таком случае итог.

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

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

В РСУБД связи управляются пользователем, создающим внешние ключи. Затем для обнаружения связей динамически во время выполнения система просматривает две (или больше) таблицы, сравнивая внешние ключи до достижения соответствия. Этот процесс, называемый объединением (join), является слабой стороной реляционной технологии. Более двух или трех уровней объединений - сигнал, чтобы искать лучшее решение. В ООСУБД пользователь просто объявляет связь, и СУБД автоматически генерирует методы управления, динамически создавая, удаляя и пересекая связи. Ссылки при этом прямые, нет необходимости в просмотре и сравнении или даже поиске индекса, который может сильно сказаться на производительности. Таким образом, применение объектной модели предпочтительнее для баз данных с большим количеством сложных связей: перекрестных ссылок, ссылок, связывающих несколько объектов с несколькими (many-to-many relationships) двунаправленными ссылками.

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

И, наконец, ООСУБД подходят (опять же без трансляций между объектной и реляционной моделями) для организации распределенных вычислений. Традиционные базы данных (в том числе и реляционные и некоторые объектные) построены вокруг центрального сервера, выполняющего все операции над базой. По существу, эта модель мало отличается от мэйнфреймовой организации 60_х годов с центральной ЭВМ - мэйнфреймом (mainframe), выполняющей все вычисления, и пассивных терминалов. Такая архитектура имеет ряд недостатков, главным из которых является вопрос масштабируемости. В настоящее время рабочие станции (клиенты) имеют вычислительную мощность порядка 30 _ 50 % мощности сервера базы данных, то есть большая часть вычислительных ресурсов распределена среди клиентов. Поэтому все больше приложений, и в первую очередь базы данных и средства принятия решений, работают в распределенных средах, в которых объекты (объектные программные компоненты) распределены по многим рабочим станциям и серверам и где любой пользователь может получить доступ к любому объекту. Благодаря стандартам межкомпонентного взаимодействия (об этом позже) все эти фрагменты кода комбинируются друг с другом независимо от аппаратного, программного обеспечения, операционных систем, сетей, компиляторов, языков программирования, различных средств организации запросов и формирования отчетов и динамически изменяются при манипулировании объектами без потери работоспособности.

2.5 Стандарты объектных баз данных

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

В области объектных СУБД в настоящее время выработаны стандарты для:

объектной модели;

языка описания объектов;

языка организации запросов (Object Query Language - OQL);

“связующего” языка (C++ и, конечно же, Smalltalk);

администрирования;

обмена (импорт/экспорт);

интерфейсов инструментария и др.

Хотя у Microsoft и свое мнение на этот счет, организацией, выработавшей наиболее используемые на сегодня и устоявшиеся стандарты, является консорциум поставщиков ООСУБД ODMG (ООСУБД), которого поддерживают практически все действующие лица отрасли. В сотрудничестве с OMG, ANSI, ISO и другими организациями был создан стандарт ODMG-93. Этот стандарт включает в себя средства для построения законченного приложения, которое будет работать (после перекомпиляции) в любой совместимой с этой спецификацией ООСУБД. В книгу ODMG-93 входят следующие разделы:

Язык определения объектов (Object Definition Language - ODL);

Язык объектных запросов (Object Query Language - OQL);

Связывание с C++;

Связывание со Smalltalk.

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

Всегда, когда возникает потребность манипулировать большими массивами данных, используются базы данных. База данных - это прежде всего набор таблиц, хотя в базу данных могут входит также процедуры и ряд других объектов. Таблицу можно представлять себе как обычную двумерную таблицу с характеристиками (атрибутами) какого-то множества объектов. Таблица имеет имя - идентификатор, по которому на нее можно сослаться. В таблице 2.1 приведен пример фрагмента подобной таблицы с именем РГП «НПЦЗР», содержащей сведения о сотрудниках некоторой организации.

Таблица 2.1 Пример таблицы данных о сотрудниках РГП «НПЦЗР»

Номер	Отдел	Фамилия	Имя	Отчество	Год рождения	Пол	Характеристика	Фото
Num	Dep	Fam	Nam	Par	Year	Sex	Charact	Photo
1	НИР	Романовская	Наталья	Марковна	1965	ж	….	…
2	Бухг.	Аманова	Мария	Узаковна	1975	ж	….	…
3	АиИТ	Мукин	Кадыр	Болатович	1970	м	….	…
4	АиИТ	Алтай	Алмаз	Алтайулы	1984	м	….	…
…	….	….	….	….	….	….	….	…

Столбцы таблицы соответствуют тем или иным характеристикам объектов - полям. Каждое поле характеризуется именем и типом хранящихся данных. Имя поля - это идентификатор, который используется в различных программах для манипуляции данными. Он строится по тем же правилам, как любой идентификатор, т.е. пишется латинскими буквами, состоит из одного слова и т.д. .например, для таблицы 2.1 введем для последующих ссылок имена полей Num, Dep, Fam, Nam, Par, Year, Sex, Charact, Photo.

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

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

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

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

График 2.2. Схема перемещения курсора по индексу

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

Создают базы данных и обрабатывают запросы к ним системы управления базами данных - СУБД. Известно множество СУБД, различающихся своими возможностями или обладающих примерно равными возможностями и конкурирующих друг с другом: Paradox, dBase, Microsoft Access, FoxPro, Oracle, InterBase, SyBase и много других.

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

· Автономные

· Файл-серверные

· Клиент/сервер

· Многоуровневые распределения

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

2.7 Организация связи с базами данных в Delphi

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

Приложение Delphi обращается к базе данных через BDE. В этом случае общение с базами данных соответствует схеме, приведенной на графике 2.3.

Приложение Delphi, когда ему надо связаться с базой данных, обращается к BDE и сообщает обычно псевдоним базы данных и необходимую таблицу в ней. BDE реализован в виде динамически присоединяемых библиотек DLL (IDAPI01.DLL, IDAPI32.DLL).

BDE по псевдониму находит драйвер, подходящий для указанной базы данных. Драйвер - это вспомогательная программа, которая понимает, как общаться с базами данных определенного типа. Если в BDE имеется собственный драйвер соответствующей СУБД, то BDE связывается через него с базой данных и с нужной таблицей в ней, обрабатывает запрос пользователя и возвращает в приложение результаты обработки. BDE поддерживает естественный доступ к таким базам данных, как Microsoft Access, FoxPro, Paradox, dBase и ряд других.

Если собственного драйвера нужной СУБД в BDE нет, то используется драйвер ODBC. ODBC (Open Database Connectivity) - DLL, аналогичная по функциям BDE, но разработанная фирмой Майкрософт. Она храниться в файле ODBC.DLL.

Delphi поддерживает SQL - стандартизованный язык запросов, позволяющий обмениваться данными с SQL-серверами, как SyBase, Microsoft SQL, Oracle, InterBase. Эта возможность используется особенно широко при работе на платформе клиент/сервер и в распределенных приложениях.

График 2.3. Схема связи приложения Delphi с базами данных

3. ОСНОВНАЯ ЧАСТЬ

3.1 Алгоритм программы

Программный продукт реализован в ИСР Delphi 7.0. В качестве источника базы данных использован драйвер Microsoft Access Driver (*.mdb). Следовательно, для создания файлов данных используем программный продукт Microsoft Access 2002.

1. Через команду «Start--All Programs--Microsoft Access » заходим в СУБД и создаем в режиме конструктора 2 таблицы. Сохраняем их под именами Dannie и Saler, задаем ключевые поля, делаем связки и выходим из программы.

2. Через «Источники данных (ODBC)» создаем новый источник данных и сохраняем его под именем «altai».

3. В ИСР «Delphi» вызываем и связываем таблицы, создаем формы, SQL запрос и файл справки на программе Microsoft Help WorkShop.

4. Компилируем и создаем исполняющий файл базы данных.

3.2 Описание программы

3.2.1 Создание таблиц базы данных

3.2.1.1 Создание таблицы Danniе

Так как в качестве источника базы данных используем драйвер Microsoft Access Driver (*.mdb), таблицы создаем в Microsoft Access 2002.

Таблицу Dannie создаем в режиме конструктора (cм. рис. 1).

3.2.2.2 Создание таблицы Saler

Таблицу Saler так же создаем в режиме конструктора. Задаем ключевое поле и связываем его с таблицей Dannie (cм. рис.2).

3.2.2 Создание нового источника данных

Через команду «Пуск--Панель управления--Администрирование--Источник данных» вводим новый источник данных базы данных. Чтобы добавить новый источник данных щелкаем по кнопке «Добавить» (см. рис.3), в результате выйдет новое окно где нужно будет указать путь к базам данных указать имя пользователя «altai» (см. рис.4,5). При нажатии «ОК» в окне источника данных появится пользователь «altai» (см. рис.6). Нажимаем по кнопке «ОК» и выходим из программы.

3.2.3 Создание форм

3.2.3.1Создание формы-заставки.

Открываем в Delphi новое приложение (File--New Application). Назовем ее для определенности FMain

Добавляем в приложение новую форму. Назовем ее Flog. Ее свойство BoderStyle делаем равным bsNone, чтобы в окне не присутствовала полоса заголовка. Вставим на форму рисунки и надписи. Свойство Position следует сделать равным poScreenCenter, чтобы форма появилась на экране. Добавим на форму компонент Timer. Интервал таймера задаем равным 5000. В событие OnClose вставим оператор Action:=CaFree.

Далее сохраняем форму и приложением по названием UMain, Ulog. Напишем в модуле UMain обработчик события формы Onshow , состоящий из одного оператора: Flog.ShowModal (см. рис.7). Листинг формы представлен в листинге 1 (прил. Б).

3.2.3.2 Создание формы-FMain.

Выполняем команду «File--New--Form». Сохраняем ее под названием “UMain”. Из страницы Additional вставляем на форму компоненты Image (Image_natitul), из страницы Standart закидываем компоненту Button (Button_new, Button_preview, Button_help, Button_exit). Свойству Caption компоненты кнопки задаем: «Ввод данных о продавце», «Сведения о продаже», «Помощь», «Выход» соответственно. Свойству Color формы FMain задаем значение clCream (см. рис. 8 ). Листинг формы представлен в листинге 2 (прил. Б).

3.2.3.3 Создание формы компонентов данных Form_component

Выполняем команду «File--New--Form». Сохраняем ее под названием “UComponent”. Из страницы «BDE» на форму закидываем компоненту «Table». Из страницы «DataAccess» компоненту «DataSource (DB)». В свойстве «DataSet» компоненты Datasource указываем Table1. В свойстве таблицы Table1 Database name указываем базу данных altai, a в Table Name имя saler. Сохраняем таблицу под именем table_saler. Автоматически в свойстве «DataSet» компоненты Datasource появляется надпись table_saler. В свойстве name задаем имя источника данных saler.

Такие же действия выполняем над таблицей Dannie, присвоив в свойствах таблицы Name имя Table_dannie (см.рис.9).

Для создания запроса из страницы BDE на форму закидываем компоненту SQL. Из страницы «DataAccess» компоненту «DataSource (DB)». В свойстве «DataSet» компоненты Datasource указываем Query1. В свойстве компоненты SQL Database name указываем базу данных altai, в свойстве SQL наживаем на три кнопочки и окне пишем запрос (см.рис.10). В свойстве Name Query1 присваиваем Query_data.

Выделив форму компонентов, в окне TreeView появятся все компоненты используемые в форме. Перетаскивая их всех в вкладку диаграммы юнита UComponent создаем диаграмму модуля данных (см. рис.11). Листинг формы представлен в листинге 3 (прил. Б)

3.2.3.4 Создание формы Form_dannieprod

Выполняем команду «File--New--Form». Сохраняем ее под названием “Udannieprod”.Открываем форму Form_component, выбираем таблицу

Table_saler. Щелкаем правой мышкой по таблице выбираем пункт меню Fields Editor. Выбираем нужные поля (Id_saler, Tabel_no, FIO, Stazh) и закидываем на нашу создаваемую форму. Свойство Table_saler Active присваиваем true.

Из страницы DataControls закидываем на форму компоненту DBGrid. В инспекторе объектов этого компонента выбираем свойство DataSource и присваиваем Form_component.saler, данные будем черпать из таблицы Table_saler. Из страницы DataControls закидываем на форму компоненту DBNavigator и связываем ее с Form_component.saler.

Из страницы Additional закидываем компоненту BitBtn, свойству Caption присваиваем Обновить (рис.12). Листинг формы представлен в листинге 4 (прил. Б).

3.2.3.5 Создание формы Form_prodaja

Выполняем команду «File--New--Form». Сохраняем ее под названием “Uprodaja”. Закидываем на форму со страницы Additional компоненту Image. В свойстве Picture выбираем подходящий рисунок. Из страницы Standart закидываем на форму компоненты Label (всего 3 шт. ). Из страницы Win32 перекидываем компоненту DateTimePicker. Из страницы DateControls закидываем компоненту DBLookupCombobox. В свойстве DataSource указываем Form_component.dannie, в свойстве DataField - Id_saler, в свойстве ListSource - Form_component.saler и на Listfield - Fio. Из таблицы Dannie закидываем на форму поле Paida.

Из страницы DataControls закидываем на форму компоненту DBGrid. В инспекторе объектов этого компонента выбираем свойство DataSource и присваиваем Form_component.query, данные будем черпать из запроса Query_dannie. Из страницы DataControls закидываем на форму компоненту DBNavigator и связываем ее с Form_component.dannie.

На форму закидываем 4 кнопки для обновления, расчета, закрытия формы и перехода на предыдущую форму, а также 2 поля Edit для вывода суммы выручки и комиссионного расчета (рис. 13). Листинг формы представлен в листинге 5 (прил.Б).

3.2.4 Создание справки

Для создания справочной системы в первую очередь создаем *.rtf файл предназначенный специально для справочной системы. Далее с помощью программы Microsoft Help WorkShop Pro преобразовываем файл *.rtf на файл *.hlp (рис. 14, 15, 16).

3.3 Логическая структура программы

Листинг 1. Листинг формы заставки FLog

1) модуль с именем Ulog;

2) открытый интерфейс модуля

3-5) список подключаемых модулей

6-16) объявления класса формы

7) объявление класса формы FLog

8) объявление Image_citycenter, рисунок citycenter

9) объявление Label_titul, надпись `Разработка информационной системы'

10) объявление Label_titul2, надпись `торгового Центра'

11) объявление Label_loading, надпись `Loading'

12) объявление Timer_log, таймер

13) объявление процедуры FormKeyDown

14) объявление процедуры FormMouseDown

15) объявление процедуры Timer_logTimer

16) объявление процедуры FormClose

17-18) закрытый раздел класса

19-20) открытый раздел класса

21) конец

22-23) объявления формы как объект класса ТFLog

24) реализация модуля

25-26) использование модуля Umain;

27) процедура FormKeyDown

28) начало процедуры

29) форма закрывается при нажатии пользователем любой клавиши

30) конец процедуры FormKeyDown

31) процедуры FormMouseDown

32) начало процедуры

33) форма закрывается при нажатии пользователем любой кнопки мыши

34) конец процедуры

35) процедура Timer_logTimer

36) начало процедуры

37) Задаем интервал времени равным 5000. При истечении времени форма закрывается

38) конец процедуры

39) процедура FormClose

40) начало процедуры

41) уничтожение объекта формы и освобождение занимаемой формой памяти

42) конец процедуры

43) конец модуля.

Листинг 2. Листинг главной формы приложения Fmain

1) модуль с именем Umain;

2) открытый интерфейс модуля

3-5) список подключаемых модулей

6-18) объявления класса формы

7) объявление класса формы ТFmain

8) объявление Image_natitul, вставляем рисунок

9) объявление Button_new, кнопка с надписью `Ввод данных о продавце'

10) объявление Button_preview, кнопка с надписью `Сведения о продаже'

11) объявление Button_help, кнопка с надписью `Помощь'

12) объявление Button_exit, кнопка с надписью `Выход'

13) объявление процедуры FormShow

14) объявление процедуры Button_exitClick

15) объявление процедуры Button_newClick

16) объявление процедуры Button_previewClick

17) объявление процедуры Button_helpClick

18) объявление процедуры FormDestroy

19-20) закрытый раздел класса

21-22) открытый раздел класса

23) конец

24-25) описание переменных, классов

26) реализация модуля

27) использование модулей Ulog, Ucomponent, Udannieprod, Uprodaja;

29) процедура обработчика события OnShow FormShow

30) начало процедуры

31) Событие OnShow наступает перед тем, как форма становится видимой. Поэтому в момент выполнения указанного оператора она еще не видна. Оператор открывает форму Flog как модальную, передает ей управление и дальнейшее выполнение программы в модуле FMain останавливается до тех пор, пока модальная форма не будет закрыта. После закрытия модальной формы выполнение формы продолжится, и главная форма станет видимой.

32) конец процедуры FormShow

33) процедура Button_exit Click выполнения кнопки Button_exit

34) начало процедуры

35) при нажатии на кнопку форма закрывается

36) конец процедуры Button_exit Click

37) процедура выполнения кнопки Button_new -Button_newClick

38) начало процедуры

39) при нажатии кнопки открывается форма form_danieprod

40) конец процедуры Button_newClick

41) процедура выполнения кнопки Button_preview - Button_previewClick

42) начало процедуры

43) при нажатии на кнопку открывается форма form_prodaja

44) конец процедуры Button_previewClick

45) процедура выполнения кнопки Button_help - Button_helpClick

46) начало процедуры

47) при нажатии на кнопку, открываем окно справки

48) конец процедуры Button_helpClick

49) процедура FormDestroy

50) начало процедуры

51) Данная процедура вызывает HelpCommand вместе с WINHELP command, HELP_QUIT для выхода из WINHELP1, когда приложение нужно закрыть.

52) конец процедуры FormDestroy

53) конец модуля Umain

Листинг 3. Листинг форм компонентов данных Fcomponent

1) Модель с именем Ucomponent;

2) открытый интерфейс модуля

3-5) список подключаемых модулей

7) объявление класса формы TForm_component

8) объявление таблицы Table_saler

9) объявление источника данных (DataSource) saler

10) объявление источника данных (DataSource) dannie

11) объявление источника данных (DataSource) query

12) объявление строки Fio таблицы Table_saler

13) объявление запроса Query_data

14) объявление строки целого типа Tabel_no таблицы Table_saler

15) объявление строки целого типа Stazh таблицы Table_saler

16) объявление строки id_saler инкрементирующего (+) типа таблицы Table_saler

17) объявление таблицы Table_dannie

18) объявление строки представляющий денежные величины Paida таблицы Table_dannie

19) объявление строки FIO запроса Query_data

20) объявление строки целого типа Tabel_no запроса Query_data

21) объявление строки целого типа Stazh запроса Query_data

22) объявление строки представляющие собой даты Date запроса Query_data

23) объявление строки вещественного типа Paida запроса Query_data

24) объявление строки вещественного типа Komisson_voznagr запроса Query_data

25) объявление строки id_dannie инкрементирующего (+) типа таблицы Table_dannie

26) объявление строки представляющие собой даты Date таблицы Table

27) объявление строки целого типа id_saler таблицы Table_dannie

29-30) закрытый раздел класса

31-32) открытый раздел класса

33) конец

34-35) описание типов, форм

36) реализация модуля

37-38) Использование моделей Umain, Uprodaja, Udannieprod;

39) конец описания

40) конец модуля

Листинг 4. Листинг формы ввода информации о продавце Fdannieprod

1) модуль с именем Udannieprod;

2) открытый интерфейс модуля

3-5) список подключаемых модулей

6-7) объявление класса формы Tform_danieprod

8) объявление Label_fio, надпись `fio'

9) объявление DBEdit_fio, место куда пишем новые фамилии, берем и записываем в базу данных

10) объявление Label_idsaler, надпись `id_saler'

11) объявление DBEdit_idsaler, Edit, где присваиваются коды продавцов, берем и записываем в базу данных

12) объявление Label_stash, надпись `stazh'

13) объявление DBEdit_stash, Edit где указывается стаж работы продавцов, работаем с базой данных

16) объявление DBNavigator_saler

17) объявление DBGrid1, таблица где указываются сведения

18) объявление Image1, рисунок

19) объявление Image2, рисунок на верхней стороне

20) объявление Label_titul, надпись `ввод данных о продавце'

21) объявление BitBtn_obnovit, кнопка с рисунком `Обновить'

22) объявление процедуры FormActivate

23) объявление процедуры BitBtn_obnovit

24-25) закрытый раздел классов

26-27) открытый раздел классов

28) конец

29) описание типов, форм

31)число I целого типа

32) реализация модуля

33-34) Использование модулей Umain, Ucomponent, Uprodaja;

35) процедура BitBtn_obnovitClick, выполняется при нажатии кнопки BitBtn_obnovit

36) начало процедуры

37) Таблицу о продавцах берем из формы компонентов. Для начала таблицу Table_saler объявляем закрытой

38) таблицу Table_saler объявляем открытой

39) конец процедуры BitBtn_obnovitClick

40) процедура FormActivate

41) начало процедуры

42) I:=0;

43) конец процедуры

44) конец модуля

Листинг 5. Листинг формы FProdaja

1) модуль с именем Uprodaja;

2) открытый интерфейс модуля

3-6) список подключаемых модулей

8) объявление класса формы TForm_prodaja

9) объявление Label_datasaler, надпись `Выберите дату работы продавца'

10) объявление Label_surnamesaler, надпись `Укажите фамилию продавца'

11) объявление Label_paida, надпись `Укажите сумму выручки'

12) объявление DBGrid1, таблица с данными

13) объявление DBNavigator1

14) объявление DBEdit_date

15) объявление DBEdit2

16) объявление DateTimePicker1, выбор даты продажи

17) объявление Timer1

18) объявление DBLookupComboBox1, выбор фамилии продавцов, работаем с базой данных

19) объявление Button1, кнопка выполняющая обновление записей в таблице

20) объявление Button2, кнопка выполняющая расчет выручки и комиссионных

21) объявление Edit_jalpi, Edit куда программа выводит сумму выручки

22) объявление Edit_komis, Edit куда программа выодит сумму комиссионых

23) объявление Image1, рисунок на верхней стороне формы

24) объявление Label_titul, надпись `Сведения о продаже'

25) объявление Label1, надпись `Сумма выручки'

26) объявление Label2, надпись `Cумма комиссионных'

27) объявление кнопки BitBtn_close, кнопки для закрытия

28) объявление кнопки BitBtn_forward, кнопки для возврата на предыдущую форму

29) процедура Timer1Timer

30) процедура FormActivate

31) процедура Button1Click

32) процедура Button2Click

33) процедура BitBtn_closeClick

34) процедура BitBtn_forwardClick

35-36) закрытый раздел класса

37-38) открытый раздел класса

39) конец

40-43) описание типов, форм

41) Form_prodaja: класса TForm_prodaja;

42) i:целое число

43) сумма прибыли и сумма комиссионных вещественные типы

44) реализация модуля

45-46) использование модулей Ucomponent, Umain, Udannieprod;

47) процедура TForm_prodaja.Timer1Timer

48)начало процедуры

49) наращиваем i

50) для i берем значения 1 и 2. Если i=3 но I присваиваем 1.

51) если i =1, то

52) начало

53) время или день, указанный в DateTimePicker1.Date превращаем в строковый тип, и записываем в DBEdit_date

54) конец цикла

55) конец процедуры Timer1Timer

56) процедура активации формы в группе проектов FormActivate

57) начало процедуры

58) i начинаем с 0

59) конец процедуры FormActivate

60) процедура выполняемая при нажатии кнопки Button1 - Button1Click

61) начало процедуры

62) при нажатии кнопки, запрос в компоненте форм Query_data закрыта

63) далее доступ открывается

64) конец процедуры Button1Click

65) процедура выполняемая при нажатии кнопки Button2 - Button2Click

66) начало процедуры

67) сумме выручки присваиваем 0

68) сумме комиссионных присваиваем 0

69) все действия выолняем (подсчет выручки и комиссионных) до тех пор, пока записи в Query_data не закончены

70) начало процедуры

71) вычисляем сумму выручки. Предыдущая сумма выручки (в первый раз она равна 0) + поле 'paida' в запросе (таблице) Query_data. Все это представляем в типе вещественный

72) вычисляем сумму комиссионных. Предыдущая сумма комиссионного (в первый раз она равна 0) + поле 'komisson_voznagr' в запросе (таблице) Query_data. Все это представляем в типе вещественный

74) конец процедуры Button2Click

75) В поле ввода Edit_jalpi присваиваем значения sum_paida преобразовав их в строковый тип

76) В поле ввода Edit_ komis присваиваем значения sum_komis преобразовав их в строковый тип

77) конец

78) процедура выполняемая при нажатии кнопки BitBtn_close - BitBtn_closeClick

79) начало процедуры

80) при нажатии этой кнопки, форма закрывается

81) конец процедуры BitBtn_closeClick

82) процедура выполняемая при нажатии кнопки BitBtn_forward - BitBtn_forwardClick

83) начало процедуры

84) при нажатии на кнопку форма fmain=видимая

85) форма form_prodaja=невидимая

86) конец процедуры BitBtn_forwardClick

87) конец модуля Uprodaja

4. ОПИСАНИЕ КОНТРОЛЬНОГО ПРИМЕРА

Прежде чем приступать к работе с приложением, необходимо создать нового пользователя источника данных и назвать его `altai'. После того, как источник данных создан, запускаем приложение database.exe. В результате появляется окно «Главная форма» (рис.8 ).

Щелкаем по кнопке «Ввод данных о продавце». Открывается окно «Ввод данных о продавце» (рис.12 ). В таблице представлены все зарегистрированные продавцы и работающие в текущее время. Для добавления нового продавца щелкаем по значку «+» (рис.12). Все поля очищаются и мы вводим значения для каждого поля соответственно. После ввода щелкаем по значку «». Введенные данные будут занесены в таблицу. Если будет нужда в редактировании данных, то следует указать курсором на поле требуемое изменения, щелкнуть по значку «» и изменять данные. А если удаления, то придется указать удаляемое поле в таблице, щелкнуть значком «» и щелкнуть по кнопке «Да». При нажатии на кнопку «Обновить» данные упорядочиваются по внесенным изменениям.

Вернемся обратно на главную форму и кликнем на кнопке «Сведения о продаже». В результате откроется окно расчета (рис. 13). Для внесения данных, щелкаем по значку «+». Далее указываем дату продажи, выбираем ФИО продавца, и указываем через ввод сумму выручки. После ввода щелкаем по значку «» и кнопке «Обновить». Введенные данные моментально будут внесены в таблицу. При нажатии на кнопку «Обновить» система просчитывает сумму комиссионных. Если сумма выручки меньше 1000 рублей, то комиссионные не считаются, а если больше 1000 рублей 5% комиссионных со суммы выручки обеспечены. Продавцы со стажем более 10 лет имеют особый приоритет. При выручке больше 1000 рублей, им обеспечено 6 % комиссионных. Щелкнув по кнопке «Расчет» мы получаем общую сумму выручки и комиссионного вознаграждения (рис. 13). Для возврата на форму «Ввод данных о продавце» нажмем на кнопку «Назад», в результате выйдет окно (рис. 12). Но мы щелкнем по кнопке «Выход», для выхода из формы.

Вернемся на «Главную форму» (рис.8). Теперь для получения справки и помощи щелкнем по кнопке «Помощь». В результате откроется окно (рис.15). В окне справки щелкнув по ссылке «Перейти к содержанию» откроется следующее окно справки (рис.16). Для выхода нажмем на кнопку «».

Вернемся на «Главную форму» (рис.8). Для выхода их приложения кликнем по кнопке «Выход».

ЗАКЛЮЧЕНИЕ

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

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

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

В настоящий момент ощущается настоятельная потребность в интеграции ООСУБД с существующими инструментальными средствами. Разработчики уже сегодня могли бы продуктивно использовать версии Visual Basic, Power Builder, Forte или Delphi, поддерживающие ООСУБД. Большинство продуктов для создания приложений в той или иной мере являются объектно-ориентированными, но работают по-прежнему с реляционными БД. Специалисты считают, что партнерство производителей ООСУБД и средств программирования способно привести к появлению столь необходимого инструментария.

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