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

ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ПРОФЕССИОНАЛЬНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ТУЙМАЗИНСКИЙ ГОСУДАРСТВЕННЫЙ ЮРИДИЧЕСКИЙ КОЛЛЕДЖ

КАФЕДРА КОМПЬЮТЕРНЫХ ТЕХНОЛОГИЙ

Приложение для работы с БД «Фирма по изготовлению

встроенной мебели»

КУРСОВАЯ РАБОТА

Сабитов Дмитрий Олегович

ПКС-307

МДК 02.02

НАУЧНЫЙ РУКОВОДИТЕЛЬ
КУЗНЕЦОВ В.В.
ПРЕПОДАВАТЕЛЬ ПО МДК
02.02

ТУЙМАЗЫ 2020
 СОДЕРЖАНИЕ

ВВЕДЕНИЕ..................................................................................................................3
1. Теоретическая часть.......................................................................................4
1.1. Описание и анализ предметной области. Назначение и стадии
разработки...........................................................................................................4
1.2. Проектирование базы данных. Описание логической структуры.........7
1.3. Инфологическая модель БД входящая в программу.............................12
2. Практическая часть......................................................................................14
2.1. Функциональное назначение. Реализация базы данных в СУБД........14
2.2. Приложение для работы с БД. Входные и выходные данные.............25
Заключение................................................................................................................35
Список источников и литературы........................................................................36
 ВВЕДЕНИЕ

Тема: Приложение для автоматизации фирм по изготовлению

встроенной мебели.
Актуальностью данной темы является то, что сегодня сложно
представить жизнь без компьютерных технологий. К примеру, повсеместная
компьютеризация бухгалтерского учета на предприятиях обусловлена
современными требованиями к достоверности и срокам выдачи информации.
Автоматизация учета участников и их результатов нужна для более быстрой
обработки информации, ведь если проверять всё вручную – уйдет много
времени.
Целью темы является достижение автоматизации по учету фирм
изготовления встроенной мебели путем создания пользовательской оболочки
на Delphi с использованием языка Pascal.
Задачи:
1. Обдумать физическую и логическую модель данных;
2. Создать БД;
3. Обеспечить защиту от утечек из БД;
4. Создать приложение для взаимодействия с БД;
5. Протестировать приложение на ошибки и исправить их
Практическая значимость работы заключается в применении
создаваемой системы на любых фирмах по изготовлению встроенной мебели.
Теоретическая значимость работы заключается в важности
автоматизации фирм изготовления встроенной мебели. Данное программное
средство позволяет улучшить производительность по контролю фирм
изготовления встроенной мебели.

3
 1. Теоретическая часть

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

разработки

База данных — совокупность данных, хранимых в соответствии со

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

4
пользователей об автоматизируемой предметной области, то есть является
человеко-ориентированной.
Даталогическая модель отражает логические связи между элементами
данных вне зависимости от их содержания и среды хранения. Даталогическое
моделирование предполагает описание, создаваемое по инфологической
модели данных.
Пользователям выделяются подмножества этой логической модели,
называемые внешними моделями, отражающие их представления о
предметной области. Внешняя модель соответствует представлениям,
которые пользователи получают на основе логической модели. Другими
словами, даталогическая модель в основном используется для реализации
требований, выдвинутых конечными пользователями, то есть отражённых в
инфологической концептуальной модели.
Таким образом, даталогическая модель реализуется, как модель
представления данных. Следовательно, перед тем как строить
даталогическую модель, необходимо определить какая модель данных будет
положена в основу базы данных и выбрать соответствующую систему
управления базами данных (СУБД). Различают реляционные, иерархические
и сетевые модели представления данных и соответствующие этим моделям
СУБД.
Физическая модель данных — модель, определяющая размещение
данных на внешних носителях, методы доступа и технику индексирования.
Она так же называется внутренней моделью системы, которая определяет и
оперирует размещением данных и их взаимосвязями на запоминающих
устройствах.
Стадия проекта — одна из частей процесса создания программы,
установленная нормативными документами и заканчивающаяся выпуском
проектной документации, содержащей описание полной, в рамках заданных
требований, модели программы на заданном для данной стадии уровне, или
изготовлением программ. По достижении окончания стадии заказчик имеет
5
возможность рассмотреть состояние проекта и принять решение по
дальнейшему продолжению проектных работ. Например, заказчик может
принять решение о продолжении работ по одному из согласованных
вариантов.
Этап проекта — обычно часть стадии проекта, выделенная по
соображениям единства характера работ и (или) завершающего результата
или специализации исполнителей. Иногда выделяют этапы (фазы), которые
охватывают несколько стадий. Например, этап проектирования программы
включает стадии ЭП и ТП. Описания этапов регламентируют порядок
выполнения отдельных видов работ для достижения стадии. Одни и те же
виды работ могут продолжаться ряд этапов.
Основные этапы разработки программ:
1. Постановка задачи.
Задача формулируется на естественном языке. Определяются цели.
Подготавливается техническое задание на разработку программы.
2. Обоснованный выбор средств разработки (программирования).
Разрабатываются форматы ввода исходных данных и отображения
результатов.
3. Выбор метода решения задачи.
Анализ возможности использования ранее разработанного и
доступного для программиста программного обеспечения.
4. Разработка алгоритма решения задачи.
Декомпозиция задачи на подзадачи. Определение последовательности
решения подзадач. Разработка структуры программы.
5. Обоснование выбора средств программирования.
Выбор языка программирования и системы (среды) программирования.
6.Кодирование средствами выбранного языка программирования.
7. Верификация и проверка корректности.
Аналитическое доказательство правильности программы.
8. Тестирование программы.
6
 Разработка тестов и контрольных примеров. Сопоставление реальных и
ожидаемых результатов.
9. Отладка программы в случае обнаружения ошибок.
Локализация обнаруженных ошибок. Коррекция ошибок. Возврат к
этапу тестирования.
10. Разработка документации.
Текстовое описание программы. Разработка инструкций пользователю
– лицу, применяющему разработанную программу в своей работе. Разработка
инструкций по эксплуатации, содержащих информацию, требующуюся
программистам, ответственным за нормальное функционирование
программы.
11. Опытная эксплуатация.
Уточнение требований заказчика к представлению исходных данных и
результатов работы программы. При необходимости возврат к предыдущим
этапам.
12. Промышленная эксплуатация.
Сопровождение программы. Обработка требований к новым версиям
программы.

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

структуры

Часто при описании логической структуры реляционной БД сразу же

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

7
что меняет общую структуру БД. Вопросы индексирования будут частично
рассмотрены в данном разделе. Внешнее представление (внешняя схема)
данных является совокупностью требований к данным со стороны некоторой
конкретной функции, выполняемой пользователем. Концептуальная схема
является полной совокупностью всех требований к данным, полученной из
пользовательских представлений о реальном мире. Внутренняя схема - это
сама база данных.
1. Стабильность - может ли значение ключа изменяться. Несмотря на
то, что многие современные СУБД не только не запрещают изменять
значение первичного ключа, но и имеют специальные механизмы,
позволяющие автоматически осуществлять изменения связанных записей
(каскадное изменение), не следует злоупотреблять этой возможностью.
Желательно выбирать в качестве первичного ключа атрибуты, которые не
изменяются.
2. Мнемоничность - легкость запоминания. Поскольку в качестве
ключа обычно используются короткие обозначения, то при прочих равных
условиях следует отдавать предпочтение тем из вероятных ключей, которые
легче запомнить.
Если объект является зависимой по идентификации сущностью, то
ключ соответствующего ему отношения будет составным, включающим
идентификатор этого объекта и идентификатор «вышестоящего»
объекта, т.е. идентификатор основного объекта мигрирует в таблицу,
соответствующую зависимому объекту. Если идентификаторов у главного
объекта несколько, то выбирается один из них, а именно тот, который выбран
в качестве первичного ключа основной сущности. Полученный таким
образом составной идентификатор зависимой по идентификации сущности
будет использоваться во всех случаях, когда нужно отображать связь этого
зависимого объекта с другими.
Обычно зависимый по идентификации объект и тот объект, от которого
он зависит, связаны друг с другом отношением 1:М, и может сложиться
8
впечатление, что перенесение ключа просто соответствует отображению этой
связи. Однако это не совсем так. Если сущность не зависима по
идентификации, то связь 1:М можно отображать в структуре БД как путем
переноса ключа связанного объекта в таблицу, соответствующую
подчиненному объекту (т. е. объекту, стоящему со стороны М), так и
другими способами, а ключом таблицы, соответствующей подчиненному
объекту, будет являться только идентификатор самого этого объекта. Для
зависимого по идентификации объекта связь 1:М дополнительно в схеме БД
отображать не надо. Этап физического проектирования заключается в
определении схемы хранения, т.е. физической структуры БД. Схема хранения
зависит от той физической структуры, которую поддерживает выбранная
СУБД. Физическая структура БД, с одной стороны, должна адекватно
отражать логическую структуру БД, а с другой стороны, должна
обеспечивать эффективное размещение данных и быстрый доступ к ним.
Результаты этого этапа документируются в форме схемы хранения на языке
определения данных (DDL, Data Definition Language) выбранной СУБД.
Принятые на этом этапе решения оказывают огромное влияние на
производительность системы.
Одной из важнейших составляющих проекта базы данных является
разработка средств защиты БД. Защита данных имеет два аспекта: защита от
сбоев и защита от несанкционированного доступа. Для защиты от сбоев на
этапе физического проектирования разрабатывается стратегия резервного
копирования.
Для защиты от несанкционированного доступа каждому пользователю
доступ к данным предоставляется только в соответствии с его правами
доступа, набор которых также является составной частью проекта БД.
Каждое реляционное отношение соответствует одной сущности
(объекту ПрО) и в него вносятся все атрибуты этой сущности. Для каждого
отношения определяются первичный ключ и внешние ключи (в соответствии
со схемой БД). В том случае, если базовое отношение не имеет
9
потенциальных ключей, вводится суррогатный первичный ключ, который не
несёт смысловой нагрузки и служит только для идентификации записей.
По сути дела физическое проектирование базы данных подразумевает
конструирование таблиц в СУБД. Для канонической модели не требуется
дополнительных преобразований.
Анализ предметной области позволяет выделить набор данных,
которые должны храниться в проектируемой базе данных и использоваться в
будущем приложении:
1. Артикул
2. Склад
3. Наименование
4. Цена
5. Количество
6. Мебель
7. Заказ
8. Название склада
9. ID склада
10. Адрес
11. Телефон
12. ID заказа
13. Покупатель
14. Дата заказа
15. Дата выполнения
16. ФИО
17. ID покупателя

10
 Рис. 1 Логическая структура БД

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

1.3. Инфологическая модель БД входящая в программу

Инфологическая модель данных. ER-диаграмма - это набор сущностей

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

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

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

Сущность – любой различимый объект (объект, который мы можем

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

13
 2. Практическая часть

2.1. Функциональное назначение. Реализация базы данных в СУБД

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

любой инструмент из множества применяемых для этой цепи
"складируются" сервером в некую сущность - баз} данных. Обычно под
базой данных понимается и сам сервер СУБД, и пользовательская
информация, и даже клиентские программы, которые работают с данными.
Мы будем понимать в этой главе под базой данных совершенно конкретную
вещь - файлы базы данных.
База данных InterBase представляет собой один или несколько файлов,
в которых находится информация обо всем, что связано с этой базой.
Исключение составляет информация о пользователях, поскольку
пользователи определяются на уровне всего сервера и хранятся отдельно, в
системной базе данных ISC4.GDB. Внутри файлов базы данных содержится
вся информация о базе: сами данные, индексы, триггеры, хранимые
процедуры и т. д.
Направление объектно-ориентированных баз данных (ООБД) возникло
сравнительно давно. Однако наиболее активно это направление развивается в
последние годы. С каждым годом увеличивается число публикаций и
реализованных коммерческих и экспериментальных систем. Возникновение
направления ООБД определяется прежде всего потребностями практики:
необходимостью разработки сложных информационных прикладных систем,
для которых технология предшествующих систем БД не была вполне
удовлетворительной. Конечно, ООБД возникли не на пустом месте.
Соответствующий базис обеспечивают как предыдущие работы в области
БД, так и давно развивающиеся направления языков программирования с
абстрактными типами данных и объектно-ориентированных языков
программирования.
14
 Что касается связи с предыдущими работами в области БД, то на наш
взгляд наиболее сильное влияние на работы в области ООБД оказывают
проработки реляционных СУБД и следующее хронолигически за ними
семейство БД, в которых поддерживается управление сложными
объектами. Кроме того, исключительное влияние на идеи и концепции ООБД
и, как кажется, всего объектно-ориентированного подхода оказал подход к
семантическому моделированию данных (например, хотя общее число
публикаций по семантическому моделированию поистине безгранично).
Достаточное влияние оказывают также развивающиеся параллельно с ООБД
направления дедуктивных и активных БД .
Среди языков и систем программирования наибольшее первичное
влияние на ООБД оказал Smalltalk. Этот язык сам по себе не является
полностью поинерским, хотя в нем была введена новая терминология,
являющаяся теперь наиболее распространенной в объектно-ориентированном
программировании. На самом деле, Smalltalk основан на ряде ранее
выдвинутых концепций. Хороший обзор идей и подходов объектно-
ориентированного программирования.
Большое число работ не означает, что все проблемы ООБД полностью
решены. Как отмечается в Манифесте группы ведущих ученых,
занимающихся ООБД, современная ситуация с ООБД напоминает ситуацию
с реляционными системами середины 1970-х. При наличии большого
количества экспериментальных проектов (и даже коммерческих систем)
отсутствует общепринятая объектно-ориентированная модель данных, и не
потому, что нет ни одной разработанной полной модели, а по причине
отсутствия общего согласия о принятии какой-либо модели. На самом деле,
имеются и более конкретные проблемы, связанные с разработкой
декларативных языков запросов, выполнением и оптимизацией запросов,
формулированием и поддержанием ограничений целостности,
синхронизацией доступа и управлением транзакциями и т.д.
15
 Тематика ООБД очень широка, объем настоящего обзора не позволяет
рассмотреть все вопросы. Тем не менее, мы постараемся в систематической
манере проанализировать наиболее важные аспекты ООБД (критерии отбора
тем и источников полностью субъективны). Обзор построен по следующему
плану: Первый раздел - настоящее введение. Во втором разделе
излагаются основные понятия объектно-ориентированного подхода и их
специфическое преломление в контексте ООБД. В третьем разделе
рассматриваются основные понятия объектно-ориентированного
моделирования данных. Четвертый раздел посвящен языкам
программирования и языкам запросов ООБД. В пятом разделе кратко
обозреваются характерные представители объектно-ориентированных СУБД
- ORION и O2. Шестой раздел посвящается проблематике выполнения и
оптимизации запросов к ООБД. В седьмом разделе рассматриваются вопросы
синхронизации доступа и управления транзакциями в ООБД. Восьмой раздел
касается связи ООБД и дедуктивных и активных БД. Наконец, девятый
раздел - краткое заключение.
База данных InterBase для среднего проекта представляет собой один
файл, так как ограничение в 32 Гбайта на размер одного файла базы данных
позволяет держать все данные в одном файле (версии ниже InterBase 6.5,
Firebird 1.0 и Yaffil 1.0 имеют ограничение в 2-4 Гбайт, в зависимости от ОС).
32 гигабайт вполне хватает для хранения информации приложения баз
данных среднего размера. Но при необходимости можно разбить базу данных
на несколько файлов. Известны базы данных InterBase размером в сотни
гигабайт.Обсуждение многоверсионности может превратиться в целую
монографию. Подход, предлагаемый InterBase, до сих пор остается
уникальным, несмотря на свой солидный возраст. Поскольку эта тема
слишком велика, отмечу лишь, что технология "безблокировочного чтения"
на основе многоверсионного ядра позволяет обеспечить согласованность
данных и быстрое восстановление при сбоях. Это возможно благодаря тому,
что исчезает необходимость в хранении и поддержании журнальных файлов.
16
Кстати, при активном блокировочном доступе их размер может составлять до
10% от размера всех баз данных.
Говоря о MGA, вспомним, что для реализации систем поддержки
принятия решений (DSS-Decision Support Systems) и анализа данных в
режиме реального времени (OLAP), необходимо обеспечивать
непротиворечивость данных для достаточно длительных (по сравнению с
операциями добавления данных) транзакций на фоне обновления БД. Именно
в таких сложных задачах InterBase и проявил себя особенно хорошо: на
Бостонской бирже, в проекте Magnavox в вооруженных силах США и т. п. Во
многом из-за таких возможностей ограничение на ввоз InterBase в бывший
СССР было снято одним из последних.
Использование MGA обеспечивает и такие положительные "побочные"
эффекты, как возможность резервного архивирования данных (backup) без
останова сервера и отключения пользователей. Не это ли действительно
работа "24 часа в день, 7 дней в неделю и 365 дней в году"? Особенно на
фоне быстрого восстановления БД без вмешательства администратора баз
данных.
Технология MGA не остановилась в развитии. Одним из важных
расширений, введенных в последней версии InterBase 4.2, является
возможность изменения метаданных без останова сервера, т. н. применение
многоверсионности не только к данным, но и метаданным.
Запускаем InterBase. Для начала нужно подключиться к нашему
локальному серверу. Для этого два раза кликаем по «Local server».
Так же подключиться к локальному серверу можно нажав правой
кнопкой мыши по «Local server» и выбрал «Login». Для корректной работы
Interbase рекомендуется запускть от имени администратора. Для запуска
InterBase от имени администратора кликните по приложению InterBase
правой кнопкой мыши и выберите «Запуск от имени администратора»

17
 Рис. 4 Запуск от имени администратора

Рис. 5 Подключение к локальному серверу

18
 Вводим логин и пароль. Стандартный логин: SYSDBA, пароль:
masterkey. Жмем «Login».

Рис. 6 Ввод логина и пароля

Создаем новую БД в InterBase. Для этого жмем на «Databases» и

выбираем «Create Database»:

Рис. 7 Создание БД

Назовем новую БД «CURS1»:

19
 Рис. 8 Создание БД

Создадим 5 таблиц в СУБД InterBase. Для этого нужно кликнуть на

«Interactive SQL», ввести запросы на языке SQL(в нашем случаем создание
трех таблиц) и нажать на кнопку «Execute Query»

20
 Рис. 9 Расположение «Execute Query»

Рис. 10 Расположение «Interactive SQL»

21
 При нажатии на «Interactive SQL» появится окно, в котром вы можете
писать запросы на языке SQL. В нашем случае мы будем создавать нужные
нам таблицы.

Рис. 11 Расположение «Execute Query»

Таблица «Дом»:

22
 Рис. 12 SQL-запрос для таблицы «Дом»

Таблица «Квартиры»:

Рис. 13 SQL-запрос для таблицы «Квартиры»

Рис. 14 SQL-запрос для таблицы «Сделка»

23
Рис. 15 SQL-запрос для таблицы «Сотрудник»

Рис. 16 SQL-запрос для таблицы «Владелец»

24
 2.2. Приложение для работы с БД. Входные и выходные данные

Создаем новый проект в Delphi. На главной форме будут находиться

кнопки наших таблиц, выборок и отчетов.

Рис. 15 Главная форма

Код для кнопок «Таблицы», «Выборки», «Отчеты» и «Выход»:

Рис. 16 Код при нажатии на кнопки

25
Создадим новые формы для таблиц.

Рис. 17 Таблица “Дом”

Рис. 18 Таблица “Квартиры”

Рис. 19 Таблица “Сделки”

26
 Рис. 20 Таблица “Сотрудники”

Рис. 21 Таблица “Сотрудники”

Создаем форму «Выборки». Заполняем форму, помещаем на нее

Ibtable, ibdatabase, ibquery, datasource, dbgrid, buttons

27
 Рис. 22 Форма “Запросы”

Создаем форму «Отчеты». Располагаем на ней 7 кнопок.

Рис. 26 Форма «Отчеты»

Теперь создадим сам отчет в QReports. Разместим на форме компонент
QuickRep. Для свойства Bands установим HasColumnHeader и HasDetail в
True. В HasColumnHeader расположим четыре QRLabel с Caption(Фамилия,
Номер абонента, Адрес, район, задолженность). В HasDetail расположим
четыре QRDBText, свойство DataSet и DataField укажем из нужного нам

28
списка.

рис. 27. Отчет «Дата окончания и сумма за работу»

рис. 28. Отчет «Должность рабочего»

29
30
 рис. 28. Отчет «Стоимость ремонта»

рис. 29. Отчет «Дата рождения и номер владельца»

рис. 30. Отчет «Номер дома и улица»

31
рис. 31. Отчет «Дата прихода сотрудника»

рис. 32. Отчет «Сумма и улица»

32
 Создаем DataModule. File -> New -> DataModule.

рис. 31. DataModule

Настроем DataModule:
IBDatabase1.DefaultTransaction=IBTransaction1, IBTransaction1.Default =
IBDatabase1,
IBDatabase1.Connected = true; IBTransaction1.Active = true;
IBQuery1.Database = IBDatabase1; IBQuery1.CachedUpdates = true;
IBQuery1.UpdateObject = IBUpdateSQL1;
DataSource1.DataSet = IBQuery1;
DBGrid1.DataSource = DataSource1; DBNavigator1.DataSource =
DataSource1;
IBTable1.Database=IBDatabase1; IBTable1.TableName = Dom;
IBTable1.CachedUpdates = true; DataSource2.DataSet = IBTable1;

33
 DBGrid2.DataSource = DataSource2; DBNavigator2.DataSource =
DataSource2;
Клиентская часть InterBase допускает выполнение любых действий
только в контексте транзакции. Поэтому если вы смогли получить доступ к
данным без явного вызова IBTransaction.StartTransaction, то значит где то в
недрах IBX этот вызов произошел автоматически. Такое поведение крайне не
рекомендуется использовать. Для корректной работы приложений с базой
данных желательно управлять транзакциями вручную, то есть явно вызывать
методы StartTransaction, Commit и Rollback компонента TIBTransaction.
Преимуществом размещения компонентов доступа к данным в модуле
данных является то, что изменение значения любого свойства проявится
сразу же во всех обычных модулях, к которым подключен этот модуль
данных. Кроме этого, все обработчики событий этих компонентов, т. е. вся
логика работы с данными приложения, собраны в одном месте, что тоже
весьма удобно.
Компонент доступа к данным является основой приложения баз
данных. На основе выбранной таблицы БД он создает набор данных и
позволяет эффективно управлять им..
Создадим форму для кнопки справка:

рис. 31. Справка

Для создания структуры (модели, диаграммы) данных, с которой
работает приложение, можно воспользоваться возможностями,
34
предоставляемыми страницей Diagram Редактора кода. Любой элемент из
иерархического дерева компонентов модуля данных можно перенести на
страницу диаграммы и задать связи между ними.
Нажмите на IBDataSet правую кнопку, выберите DataSet Editor.
Появится диалоговое окно. Базовая информация (имя таблицы, столбцы), уже
получена из Select SQL. В диалоге нужно указать столбцы первичного ключа
(key fields) и обновляемые столбцы (update fields). Как правило, столбцы
первичного ключа не обновляются, поэтому их исключают из Update Fields.
Теперь можно нажать Generate SQL. Появится диалоговое окно с
переключателями 4-х запросов, сгенерированными автоматически.
RefreshSQL – как было сказано выше, для считывания (перечитывания)
одной записи (текущей в гриде, например).
InsertSQL – для вставки записи. Если столбцы первичного ключа не
указаны в Update Fields, то они не попадут и в сгенерированный оператор
SQL. То есть, нужно отредактировать этот запрос, добавив столбцы
первичного ключа в оператор Insert (если только столбцы первичного ключа
не заполняются на сервере, что делается редко, и также делает невозможным
перечитывание этих данных после вставки).
DeleteSQL – для удаления текущей записи. Условия отбора в where
должны совпадать с RefreshSQL.
UpdateSQL – для обновления текущей записи. Если столбцы
первичного ключа не исключены из Update Fields, то они будут упомянуты в
update set field =:field, и соответственно могут обновляться. Изменение
значений столбцов первичных ключей – нехорошая операция, поэтому даже
если на самом деле эти столбцы не меняются, их упоминание надо убрать из
set данного оператора (но разумеется, оставить в where).

ЗАКЛЮЧЕНИЕ

35
 При выполнении данной курсовой работы была полностью
проанализирован предметная область, создана логическая и физическая
модель базы данных, диаграммы, создано приложения для автоматизации
учета фирм по изготовлению встроенной мебели в среде разработки Delphi с
использованием языка Pascal. Была проведена работа по обеспечению
защиты базы данных от утечек, нормализации БД, приведение БД к
нормальной форме.
Были получены практические знания программирования в среде
разработки Delphi, закреплен материал относительно баз данных, изучены
новые подходы к созданию приложений.
При разработки базы данных так же были получены теоретические и
практические знания по СУБД InterBase.
В результате исследования и проведения работы были выявлены
следующие достоинства приложения для автоматизации учета фирм
изготовления встроенной мебели:
1. Простой и понятный интерфейс;
2. Совместимость практически с любой версией Windows;
3. Крайне минимальные системные и аппаратные требования;
4. Широкая область применения;
5. Защищенная БД;
6. Большая скорость работы приложения.

36
 Список источников и литературы

1. Архангельский, А.Я. Программирование в Delphi 7; М.: Бином, 2003.

- 291 c.
2. Архангельский, А.Я. Программирование в Delphi. Учебник по
классическим версиям Delphi (+ дискета); М.: Бином, 2006. - 636 c.
3. Бобровский, С. Delphi 5 Учебный курс; СПб: Питер, 2000. - 640 c.
4. Бобровский, Сергей Delphi 7. Учебный курс; СПб: Питер, 2008. - 736
c.
5. Карпова, Т.С. Базы данных. Модели, разработка, реализация; СПб:
Питер, 2001. - 304 c.
6. Культин, Никита Основы программирования в Delphi 7; СПб: БХВ,
2003. - 608 c.
7. Шумаков, П.В. Delphi 3 и разработка приложений баз данных; М.:
Нолидж, 1998. - 704 c.
8. Дарахвелидзе, П.Г.; Марков, Е.П. Delphi 2005 для Win32 наиболее
полное руководство; БХВ-Петербург, 2005. - 740 c.
9. Калверт, Ч. Базы данных в Delphi 4; Киев: ДиаСофт, 1999. - 464 c.
10. Мидоу, Ч. Анализ информационных систем; Прогресс, 1977. - 400 c.
11. Сван, Том Секреты 32-разрядного программирования в Delphi (+
дискета); К.: Диалектика, 1997. - 480 c.
12. Емельянов, Н.Е. Введение в СУБД ИНЕС / Н.Е. Емельянов. - М.:
Наука, 2012. - 256 c.
13. Информационные технологии. Основы работы с реляционной БД
Oracle. - М.: McGraw-Hill, 2002. - 200 c.
14. Мюллер, Р.Дж. Базы данных и UML. Проектирование / Р.Дж.
Мюллер. - М.: ЛОРИ, 2002. - 420 c.
15. Ульман, Дж. Основы систем баз данных / Дж. Ульман. - М.:
Финансы и статистика, 2017. - 292 c.

37
 Приложение

unit Unit1;

interface

uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, jpeg, ExtCtrls;

type
TForm1 = class(TForm)
Button1: TButton;
Button2: TButton;
Button3: TButton;
Button4: TButton;
Button5: TButton;
Button6: TButton;
Button7: TButton;
Button8: TButton;
Button9: TButton;
Image1: TImage;
Image2: TImage;
procedure Button1Click(Sender: TObject);
procedure Button2Click(Sender: TObject);
procedure Button3Click(Sender: TObject);
procedure Button4Click(Sender: TObject);
procedure Button5Click(Sender: TObject);
procedure Button6Click(Sender: TObject);
procedure Button7Click(Sender: TObject);
procedure Button8Click(Sender: TObject);
procedure Button9Click(Sender: TObject);
procedure FormCreate(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;

var
Form1: TForm1;

38
implementation

uses Unit2, Unit4, Unit5, Unit6, Unit7, Unit8, Unit9, Unit22;

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);

begin
Form2.show;
end;

procedure TForm1.Button2Click(Sender: TObject);

begin
Form4.show;
end;

procedure TForm1.Button3Click(Sender: TObject);

begin
Form5.show;
end;

procedure TForm1.Button4Click(Sender: TObject);

begin
Form6.show;
end;

procedure TForm1.Button5Click(Sender: TObject);

begin
Form7.show;
end;

procedure TForm1.Button6Click(Sender: TObject);

begin
Form8.show;
end;

procedure TForm1.Button7Click(Sender: TObject);

begin
Form9.show;
end;

39
 procedure TForm1.Button8Click(Sender: TObject);
begin
Form22.show;
end;

procedure TForm1.Button9Click(Sender: TObject);

begin
Close;
end;

procedure TForm1.FormCreate(Sender: TObject);

begin

end;

end.
unit Unit2;

interface

uses

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

Dialogs, ExtCtrls, DBCtrls, Grids, DBGrids, StdCtrls;

type

TForm2 = class(TForm)

DBGrid1: TDBGrid;

DBNavigator1: TDBNavigator;

Button1: TButton;

Button2: TButton;

Button3: TButton;

procedure Button1Click(Sender: TObject);

procedure Button2Click(Sender: TObject);

procedure Button3Click(Sender: TObject);

private

40
 { Private declarations }

public

{ Public declarations }

end;

var

Form2: TForm2;

implementation

uses Unit1, Unit3, Unit17;

{$R *.dfm}

procedure TForm2.Button1Click(Sender: TObject);

begin

DataModule3.IBTable1.Insert;

Form17.show;

end;

procedure TForm2.Button2Click(Sender: TObject);

begin

DataModule3.IBTable1.Edit;

Form17.Show;

end;

procedure TForm2.Button3Click(Sender: TObject);

begin

DataModule3.IBTable1.Delete;

end;

41
end. unit Unit4;

interface

uses

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

Dialogs, QRCtrls, QuickRpt, ExtCtrls, DBCtrls, Grids, DBGrids, StdCtrls;

type

TForm4 = class(TForm)

DBGrid1: TDBGrid;

DBNavigator1: TDBNavigator;

Button1: TButton;

Button2: TButton;

Button3: TButton;

procedure Button1Click(Sender: TObject);

procedure Button2Click(Sender: TObject);

procedure Button3Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form4: TForm4;

implementation

uses Unit1, Unit2, Unit3, Unit18;

42
{$R *.dfm}

procedure TForm4.Button1Click(Sender: TObject);

begin

DataModule3.IBTable2.Insert;

Form18.show;

end;

procedure TForm4.Button2Click(Sender: TObject);

begin

DataModule3.IBTable2.Edit;

Form18.Show;

end;

procedure TForm4.Button3Click(Sender: TObject);

begin

DataModule3.IBTable2.Delete;

end;

end.

unit Unit18;

interface

uses

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

Dialogs, StdCtrls, Mask, DBCtrls;

type

TForm18 = class(TForm)

Label1: TLabel;

43
 Label2: TLabel;

Label3: TLabel;

Label4: TLabel;

Label5: TLabel;

Label6: TLabel;

Label7: TLabel;

DBEdit1: TDBEdit;

DBEdit2: TDBEdit;

DBEdit3: TDBEdit;

DBEdit4: TDBEdit;

DBEdit5: TDBEdit;

DBEdit6: TDBEdit;

DBEdit7: TDBEdit;

Button1: TButton;

Button2: TButton;

Button3: TButton;

procedure Button1Click(Sender: TObject);

procedure Button2Click(Sender: TObject);

procedure Button3Click(Sender: TObject);

procedure FormCreate(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form18: TForm18;

implementation

44
uses Unit1, Unit10, Unit11, Unit12, Unit13, Unit14, Unit15, Unit16, Unit17,

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

{$R *.dfm}

procedure TForm18.Button1Click(Sender: TObject);

begin

if DataModule3.IBTable1.Modified then

begin

end;

end;

procedure TForm18.Button2Click(Sender: TObject);

begin

DataModule3.IBTable2.Cancel;

Form18.Close;

end;

procedure TForm18.Button3Click(Sender: TObject);

begin

Close;

end;

procedure TForm18.FormCreate(Sender: TObject);

begin

end;

end.

45