Введение
В настоящее время ЭВМ широко применяется во многих отраслях деятельности человека. Ни одно учреждение не может обойтись в своей работе без применения компьютеров, которые с успехом заменяют рутинную работу, выполнявшуюся ранее в ручную, повышая эффективность работы любого учреждения.
Сфера услуг в настоящее время является одной из важных отраслей народного хозяйства призванной удовлетворять индивидуальные запросы и потребности населения страны в различных видах услуг. Сфера услуг как отрасль экономической деятельности представляет собой совокупность организаций, цель которых – оказание разнообразных платных услуг по индивидуальным заказам населения. Таким образом, сфера услуг решает важнейшие социально-экономические задачи и ее значение в жизни общества неуклонно возрастает. Одним из видов таких услуг являются услуги автосервиса.
Предлагаемая программа реализует информационную справочную систему, предназначенную для организации учета распределения работ по отделам и работникам, а также ведет учет стоимости произведенных работ. Приложение позволяет производить ввод, редактирование и просмотр содержимого баз данных, а также отвечать на запросы пользователя и составлять разнообразные отчеты.
Данная информационная система может применяться в автосервисах. Она легка в обращении, позволяет хранить большое количество сведений в одной базе данных, экономит рабочее время за счет автоматизации некоторых процессов таких как, учет стоимости работ, а также учет распределения работ по отделам. Поэтому предлагаемая программа должна существенно упростить работу автосервисов.
Анализ предметной области
Предметная область – учет работ отделов автосервиса.
Процесс оказания автосервисных услуг состоит из трех взаимосвязанных элементов:
прием заказов на услуги от населения;
выполнение заказов;
реализация услуг.
Прием заказов от населения – это начальная стадия процесса оказания услуги. Он включает определение состава услуги. При этом на данной стадии выполняется ряд операций технологического характера, которые в значительной степени влияют на весь дальнейший процесс производства (например: выявление дефектов автотранспорта подлежащего ремонту).
Следующая стадия оказания услуг – непосредственное производство, организация которого в значительной степени определяется характером выполняемых услуг.
Заключительная стадия процесса оказания автосервисных услуг – реализация заказов, т.е. доведение услуг до потребителя. Одной из особенностей, присущих предприятиям сферы обслуживания, является то обстоятельство, что они имеют непосредственный контакт с потребителем при оказании услуг, т.е. в процессе своей деятельности осуществляют не только производственные, но и торговые функции.
Взаимоотношения предприятий автосервиса, оказывающих платные услуги, и заказчиков в процессе их обслуживания, регулируются правилами предоставления услуг, которые определяют порядок приема и оформления заказов, исполнения заказов, расчетов с заказчиками, а также имущественную ответственность как предприятия, так и заказчика.
Заказы на платные услуги оформляются как специальными первичными документами, так и путем выдачи жетонов, талонов, кассовых чеков, расписок и т.д.
На предприятиях автосервиса используются следующие формы документов строгой отчетности:
БО-1 – квитанция – оформляется на все виды ремонта, требующего расхода материалов;
БО-9 – кассовая ведомость приема выручки – оформляется на срочный и мелкий ремонт, выполняемый в присутствии заказчика.
В процессе эксплуатации автомобиля могут выявиться конструктивные и производственные недостатки (дефекты), приводящие к изменению технического состояния деталей, узлов, агрегатов, вследствие чего происходит их естественный износ.
Различают механический, абразивный, коррозийный и усталостный износ.
Механический износ происходит вследствие сминания или выкрашивания частиц с поверхности деталей, что вызывает изменение массы и размера детали.
Абразивный износ – это результат царапающего или режущего воздействия более твердых частиц одной из сопряженных деталей, частиц внесенных воздухом или попавших вместе со смазкой.
Коррозийный износ является следствием воздействия агрессивной среды (кислот, щелочей, кислорода) на поверхность деталей.
Усталостный износ вызывается воздействием многократных переменных нагрузок.
Большинство деталей автомобильного транспорта подвергаются одновременному износу нескольких видов.
Отклонение технического состояния автомобиля (прицепа) и его агрегатов от установленных норм называется неисправностью. Нарушение работоспособности автомобиля, приведшее к прекращению транспортного процесса, называется отказом.
Для обеспечения бесперебойной работы автомобильного транспорта необходимо не только повседневное наблюдение за его состоянием в процессе эксплуатации (смазка, осмотр и т.п.), но и периодическое проведение ремонта. Неравномерность снашивания отдельных узлов и деталей, входящих в состав того или иного объекта автомобильного транспорта, потребовала разработки специальной системы планово-предупредительного ремонта. Система технического обслуживания автомобильного транспорта является планово-предупредительной, и все работы, предусмотренные для каждого обслуживания, являются обязательными к выполнению в полном объеме. Эта система способствует постоянному поддержанию автомобилей и прицепов в работоспособном виде, уменьшению интенсивности износа деталей, предупреждению отказов и неисправностей, снижению расхода топлива и смазочных материалов, повышению надежности и безопасности эксплуатации и увеличению пробега автомобилей до ремонта.
Крепежные, смазочные, заправочные, регулировочные, электротехнические и уборочно-моечные работы, проводимые в предусмотренные техническим обслуживанием сроки, позволяют обеспечить нормальные условия работы всех систем и механизмов автомобиля.
Техническое обслуживание является профилактическим мероприятием, проводимым принудительно в плановом порядке через определенные пробеги или время работы подвижного состава. Периодичность технического обслуживания устанавливается по фактически выполненному пробегу в километрах с учетом условий эксплуатации. Для каждой категории условий эксплуатации наибольшая периодичность технического обслуживания принята для легковых автомобилей, затем – автобусов и грузовых автомобилей.
Ремонт подвижного состава автомобильного транспорта предназначен для регламентированного восстановления и поддержания работоспособности автомобилей и прицепов, устранения отказов и неисправностей, возникших в работе или выявленных при техническом обслуживании. Ремонтные работы выполняют как по потребности (после появления соответствующего отказа или неисправности), так и по плану через определенный пробег или время работы подвижного состава.
Существует два вида ремонта: капитальный и текущий. Последний, в свою очередь, делится на средний, малый, и текущее (межремонтное) обслуживание. Капитальный ремонт, как правило, выполняют на специализированных ремонтных предприятиях, текущий – на автотранспортных предприятиях или на станциях технического обслуживания.
Капитальный ремонт включает контрольно-диагностические, сборочные, регулировочные, слесарные, механические, медницкие, жестяницкие, обойные, электротехнические, шинoремонтные, малярные и другие работы. Ремонтные работы могут выполняться по определенным агрегатам узлам, а также по подвижному составу в целом. При капитальном ремонте агрегат полностью разбирают, выявляют дефекты, восстанавливают или заменяют отдельные детали, затем собирают, регулируют и испытывают. Если капитальному ремонту подлежит весь автомобиль, то его тоже полностью разбирают, все детали дефектуют, восстанавливают и заменяют, собирают, а узлы и агрегаты регулируют и испытывают.
Текущим ремонтом считается такой, при котором агрегат разбирается лишь частично, а восстанавливаются и заменяются только те части, срок службы которых равен межремонтному периоду. Текущий ремонт обычно осуществляется без снятия агрегата с фундамента. При этом средний текущий ремонт отличается от малого лишь объемом ремонтных работ. Текущее (межремонтное) обслуживание сводится к повседневному наблюдению за состоянием оборудования и устранению мелких неисправностей.
Учет ремонта транспортных средств следует вести по его видам: капитальный и текущий с разделением на средний, малый и межремонтное обслуживание.
Разработанная информационная система должна давать возможность ведения базы данных по отделам, видам оказанных слуг, сотрудникам, а также обеспечивать диалоговые средства ввода, редактирования, поиска информации и вывода отчетов.
Входными данными должны быть:
— по заявкам – номер, дата заявки, контрагент, сумма авансового платежа, вид оказываемых услуг;
— по контрагентам – сведения о контрагенте, предоставляемая скидка;
— по отделам – код отдела, наименование;
— по дисциплинам – код дисциплины, наименование, преподаватель, принадлежность к кафедре;
— по видам работ – наименование работы, работник, выполняемый данный вид ремонта;
Выходными данными должны быть:
— сформированный счет, за оказанный ремонт;
— начисленная заработная плата сотрудников.
Инфологическое проектирование
В автоматизированных информационных системах отражение предметной области представлено моделями данных нескольких уровней, одной из которых является инфологическая модель. В ней отображается какая-то часть реального мира, называемая предметной областью. Для того, чтобы описать исследуемую предметную область используют искусственные формализованные языковые средства. В связи с этим под инфологической моделью понимают описание предметной области, выполненное с использованием специальных языковых средств, не зависящих от используемых в дальнейшем программных средств.
Ядром инфологической модели является описание объектов предметной области и связей между ними (сущность — связь). Для описания инфологической модели используют как языки аналитического(описательного) типа, так и графические средства. Графические средства являются более наглядными и простыми для восприятия. Для построения модели данных используется удобный инструмент – ERWin. ERwin — средство разработки структуры базы данных (БД). Обычно разработка модели базы данных состоит из двух этапов: составление логической модели и создание на ее основе физической модели. ERwin полностью поддерживает такой процесс, он имеет два представления модели: логическое (logical) и физическое (physical). Таким образом, разработчик может строить логическую модель базы данных, не задумываясь над деталями физической реализации, т.е. уделяя основное внимание требованиям к информации и бизнес-процессам, которые будет поддерживать будущая база данных.
При проектировании структуры новой базы данных определяют сущности (объекты, явления) предметной области, которые должны найти свое отражение в базе данных. Цель инфологического этапа проектирования состоит в получении семантических (концептуальных) моделей, отражающих предметную область и информационные потребности пользователей. В качестве инструмента для построения семантических моделей данных на этапе инфологического проектирования является неформальная модель «Сущность-Связь» (ER-модель — Entity-Relationship). Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов.
Основными понятиями ER-модели являются сущность, связь и атрибут.
Сущность (объект) — это реальный или представляемый объект предметной области, информация о котором должна сохраняться и быть доступна. Различают такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных предметов, событий, личностей, выступающих как единое целое. Экземпляр сущности относится к конкретной вещи в наборе. В диаграммах ER-модели сущность представляется в виде прямоугольника (в нотации Баркера), содержащего имя сущности.
Атрибут — поименованная характеристика сущности, определяющая его свойства и принимающая значения из некоторого множества значений. Каждый атрибут обеспечивается именем, уникальным в пределах сущности.
Атрибуты могут классифицироваться по принадлежности к одному из трех различных типов: описательные, указывающие, вспомогательные. Описательные атрибуты представляют факты, внутренне присущие каждому экземпляру сущности. Указывающие атрибуты используются для присвоения имени или обозначения экземплярам сущности. Вспомогательные атрибуты используются для связи экземпляра одной сущности с экземпляром другого. Атрибуты подчиняются строго определенным правилам.
Множество из одного или нескольких атрибутов, значения которых однозначно определяют каждый экземпляр сущности, называются идентификатором. Каждый экземпляр сущности должен иметь хотя бы один идентификатор. Если идентификаторов несколько, один из них выбирается как привилегированный.
Связь (Relationship) — это поименованная графически изображаемая ассоциация, устанавливаемая между сущностями и представляющая собой абстракцию набора отношений, которые систематически возникают между различными видами предметов в реальном мире. Большинство связей относятся к категории бинарных и имеют место между двумя сущностями.
Среди бинарных связей существуют три фундаментальных вида связи: один-к-одному (1: 1), один-ко-многим (1: M), многие-ко-многим (M: M). Связь один-к-одному (1: 1) существует, когда один экземпляр одной сущности связан с единственным экземпляром другой сущности. Связь один-ко-многим (1: M) имеет место, когда один экземпляр одной сущности связан с одним или более экземпляром другой сущности и каждый экземпляр второй сущности связан только с одним экземпляром первой сущности. Связь многие-ко-многим (М: N) существует, когда один экземпляр одной сущности связан с одним или более экземпляром другой сущности и каждый экземпляр второй сущности связан с одним или более экземпляром первой сущности.
В условных связях в отличие от безусловных могут существовать экземпляры сущности, которые в связи не принимают участия. Если связь условная с обеих сторон, она называется биусловной.
Все связи требуют описания. Описание должно обеспечивать:
идентификатор связи;
формулировку имен связи с точки зрения каждой участвующей сущности;
вид связи (множественность и условность);
формулировку того, как связь была формализована.
Цель формализации связи состоит в том, чтобы позволить установить связь экземпляра одной сущности с экземпляром другого. Формализация связи выполняется размещением вспомогательных атрибутов в соответствующих сущностях модели. --PAGE_BREAK--
Все сущности относятся к одному из четырех классов:
стержневые;
ассоциативные;
характеристические;
обозначающие.
Стержневая сущность (стержень) представляет собой независимую сущность.
Ассоциативная сущность (ассоциация) — это сущность, формализующая связь вида M: N между двумя или более сущностями или связь вида 1: 1 между экземплярами сущностей.
Характеристическая сущность (характеристика) представляет собой сущность, формализующую связь вида 1: M или 1: 1. Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности.
Обозначающая сущность (обозначение) — это сущность, также формализующая связь вида 1: M или 1: 1 между двумя сущностями, но отличающаяся от характеристики тем, что не зависит от обозначаемой сущности.
К числу более сложных элементов ER-модели относятся подтипы и супертипы сущностей. Сущность может быть расщеплена на два или более взаимно исключающих подтипа, каждый из которых имеет общие атрибуты и/или связи. Эти общие атрибуты и/или связи явно определяются один раз на более высоком уровне. В подтипах могут определяться собственные атрибуты и/или связи. Сущность, на основе которой определяются подтипы, называется супертипом. Подтипы должны образовывать полное множество, т.е. любой экземпляр супертипа должен относиться к некоторому подтипу. Аналогично языкам объектно-ориентированного программирования вводится возможность наследования типа сущности исходя из одного или нескольких супертипов. Как правило, каждому объекту в базе данных соответствует таблица, а его атрибутам – поля этой таблицы.
В результате анализа были выделены 8 объектов, которые описывают данную предметную область. Это:
Сущность “Заявки”. Она включает в себя основные сведения о заявках.
Сущность “Контрагенты”. Она включает в себя сведения о клиентах.
— Сущность “Отделы”, которая включает в себя сведения о всех отделах.
— Сущность “Простой Ремонт”. Она содержит сведения о простом ремонте. Простой ремонт-ремонт или замена какой-либо одной запчасти
— Сущность “Работники” содержит сведения о работках и его принадлежность к отделу.
— Сущность “Ремонт Узлов” содержит сведения о возможных ремонтируемых узлах, стоимость ремонта.
-Сущность “Сложный Ремонт” содержит заявку на сложный ремонт и сведения о ремонтируемом узле.
— Сущность “Состав Ремонта”. Она содержит сведения о виде ремонта, ремонтируемом узле и работнике, выполняющем данный вид работ.
Между объектами предметной области существуют связи, которые должны быть отражены в виде связей между объектами инфологической модели. Графически связь обозначается линией, соединяющей связываемые объекты. Связь снабжается алфавитно-цифровым идентификатором. В каждом направлении связи можно выделить главный объект, от которого идет связь, и подчиненный.
Различают идентифицирующую связь и не идентифицирующую связь. При установлении не идентифицирующей связи дочерняя сущность остается независимой. Экземпляр сущности родителя может существовать безотносительно к какому-либо экземпляру дочерней сущности.
В данной разработке все объекты связаны идентифицирующей связью.
/>
Выявление сущностей базы данных
Ссылочная целостность для всех связей одинакова: любые операции с дочерней сущностью никак не повлияют на родительскую. При удалении или обновлении родительской сущности – дочерние сущности удаляются или обновляются каскадом. При добавлении новой записи в родительские сущности реакция отсутствует.
Кроме того, при проектировании базы данных была проведена нормализация отношений до третьей нормальной формы, т.е. были устранены не ключевые столбцы, не зависящие от ключа.
Таким образом, все не ключевые атрибуты функционально полно зависят от ключа и отсутствуют транзитивные зависимости. Но имеется зависимость части составного ключа от не ключевого атрибута.
/>
ER-диаграмма логического уровня
/>
ER-диаграмма логического уровня
Даталогическое проектирование
Даталогическое проектирование заключается в проектировании логической структуры БД, Таким образом, главное отличие даталогической модели от инфологической состоит в том, что инфологическая модель хранит в себе всю информацию о предметной области, необходимую и достаточную для проектирования базы данных, но она не привязана к определенной СУБД. Даталогическая модель может не отражать в явном виде все сущности, зафиксированные в инфологической модели, но она должна быть непременно привязана к СУБД, на которой разрабатывается база данных. При проектировании даталогической модели данных должно быть обеспечено однозначное соответствие между конструкциями языка описания данных и графическими обозначениями информационных единиц и связей между ними. Спроектировать логическую структуру базы данных означает определить все информационные единицы и связи между ними, задать их имена. Таким образом даталогическое проектирование сводится к следующим этапам:
1. Определение таблиц
2. Определение полей таблиц
3. Определение типов данных в соответствии с выбранной СУБД
4. Определение длины каждого поля таблиц
5. Определение обязательности каждого поля
6. Определение индексации каждого поля
Особое внимание при построении модели уделяют целостности и отсутствию избыточности данных. Избыточность — это многократное повторение одних и тех же данных). Если в БД имеется несколько описаний одного и того же объекта, то все экземпляры этих описаний, кроме одного будут избыточными. При анализе схемы данных было выявлено отсутствие избыточности данных.
Целостность — это непротиворечивость одних данных другим. Целостность зависит от степени избыточности данных. Например, если в БД имеется несколько описаний одного преподавателя, то при изменении принадлежности данного преподавателя к кафедре в одном описании нарушается целостность данных. Однако, даже при не избыточности данных может возникнуть нарушение целостности. Пусть из БД удаляются сведения о некотором преподавателе. Теперь ссылки на этого преподавателя в зарегистрированных до удаления преподаваемых предметах в преподаваемых группах будут неправильными и также квалифицируются как нарушение целостности. Кроме целостности и не избыточности при проектировании БД учитывают возможность быстрого выполнения запросов к БД и оптимального использования ресурсов, а также разграничение доступа для разных групп пользователей.
Для построения БД могут использоваться три модели: иерархическая, сетевая, реляционная. Все эти модели отличаются в основном способами представления связей сущностей.
При проектировании данной базы данных была использована реляционная модель. Основной структурой хранения является отношение – таблица со следующими свойствами:
Каждый столбец содержит информацию одного типа.
Ячейки – поля – таблицы не содержат агрегатов (структур или массивов) данных.
Таблицы не содержат одинаковых строк.
Порядок строк и столбцов не имеет значения. Все операции используют содержательную сторону данных, а не их расположение внутри таблицы.
Для описания связей вводятся первичные ключи, позволяющие указывать ровно одну строку (кортеж) таблицы. Значение ключа используется для ссылки в других таблицах, что и является отображением связей данных. Поскольку первичный ключ играет ведущую роль в описании связей и поиске данных, размер ключа стараются сделать минимальным для оптимизации поиска. Это приводит к использованию номеров или кодов в качестве первичных ключей.
На основании даталогического проектирования в Access были созданы 8 таблиц, которые описаны в таблицах 1-11.
Таблица 1 – Описание полей таблицы Отдел
Имя поля
Тип данных
Свойства поля
ремонт
текстовый
длина 50 символов, ключевое
отдел
текстовый
длина 50 символов, обязательное
Таблица 2 – Описание полей таблицы Сложный Ремонт
Имя поля
Тип данных
Свойства поля
Ремонт
Текстовый
длина 50 символов, ключевое
Заявка
Текстовый
длина 50 символов, обязательное
Таблица 3 – Описание полей таблицы Заявка
Имя поля
Тип данных
Свойства поля
Номер
числовой
Длинное целое, первичный ключ
Дата
Дата\время
Краткий формат времени
Контрагент
Текстовый
Длина 50 символов, обязательное
Срок
Числовой
Длинное целое
Аванс
Денежный
Денежный
Таблица 4 – Описание полей таблицы Состав Ремонта
Имя поля
Тип данных
Свойства поля
Ремонт
Текстовый
длина 50 символов, ключевое
Ремонтируемый узел
Текстовый
длина 50 символов, обязательное
Работник
Текстовый
длина 50 символов, обязательное
Таблица 5 – Описание полей таблицы Простой Ремонт
Имя поля
Тип данных
Свойства поля
Заявка
Текстовый
длина 50 символов, обязательное
Ремонт продолжение
--PAGE_BREAK--
Текстовый
длина 50 символов, ключевое
Работник
Текстовый
длина 50 символов, обязательное
Таблица 6 – Описание полей таблицы Контрагенты
Имя поля
Тип данных
Свойства поля
Фамилия
Текстовый
длина 50 символов, обязательное
Скидка
числовой
Длинное целое
Таблица 7 – Описание полей таблицы Работники
Имя поля
Тип данных
Свойства поля
Ремонт
Текстовый
длина 50 символов, ключевое
Отдел
Текстовый
длина 50 символов, обязательное
Работник
Текстовый
длина 50 символов, обязательное
Таблица 8 – Описание полей таблицы Ремонт Узла
Имя поля
Тип данных
Свойства поля
Ремонт
Текстовый
длина 50 символов, ключевое
Узел
Текстовый
длина 50 символов, обязательное
Цена
Числовой
Длинное целое
Срок
Числовой
Длинное целое
/>
Схема данных
Классическая технология проектирования реляционных баз данных связана с теорией нормализации, основанной на анализе функциональных зависимостей между атрибутами отношений. Понятие функциональной зависимости является фундаментальным в теории нормализации реляционных баз данных. Функциональные зависимости определяют устойчивые отношения между объектами и их свойствами в рассматриваемой предметной области. Именно поэтому процесс поддержки функциональных зависимостей, характерных для данной предметной области, является базовым для процесса проектирования.
Процесс проектирования с использованием декомпозиции представляет собой процесс последовательной нормализации схем отношений, при этом каждая последующая итерация соответствует нормальной форме более высокого уровня и обладает лучшими свойствами по сравнению с предыдущей.
Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений.
В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:
— первая нормальная форма (1NF);
— вторая нормальная форма (2NF);
— третья нормальная форма (3NF);
— нормальная форма Бойса — Кодда (BCNF);
— четвертая нормальная форма (4NF);
— пятая нормальная форма, или форма проекции-соединения (5NF или PJNF).
Была проведена нормализация базы данных до 3 НФ.
Для функциональных зависимостей как фундаментальной основы проекта БД были проведены исследования, позволяющие избежать избыточного их представления.
Множество всех возможных функциональных зависимостей, выводимое из заданного набора исходных функциональных зависимостей, называется его замыканием.
Отношение находится в первой нормальной форме тогда и только тогда, когда на пересечении каждого столбца и каждой строки находятся только элементарные значения атрибутов. Как видно из таблиц 1-8, каждый атрибут сущностей является элементарным и неделимым.
Отношение находится во второй нормальной форме тогда и только тогда, когда оно находится в первой нормальной форме и не содержит неполных функциональных зависимостей не первичных атрибутов от атрибутов первичного ключа. Сущности проектируемой БД находятся в 1НФ и не содержат неполных зависимостей от не первичных атрибутов.
Отношение находится в третьей нормальной форме тогда и только тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей.
2. Разработка клиентской программы на Delphi для взаимодействия с базой данных Access
Разработка любой программы включает в себя несколько этапов. Для начала необходимо определиться – какая функциональность нм необходима и, соответственно, какая структура программного обеспечения сможет это реализовать. Затем, нам необходимо выбрать способ взаимодействия с данными (это основная функция нашей программы) и создать необходимые для этого инструменты. На последнем этапе мы должны обеспечить реализацию пользовательского интерфейса в нашей программе и реализовать вспомогательные функции.
2.1. Разработка структуры программного обеспечения
Согласно поставленного задания, наша программа должна:
Подключаться к базе данных Access (с возможностью выбора файла данных);
Предоставлять возможность просмотра таблиц (включая возможность сортировки);
Обеспечивать возможность редактирования информации в таблицах;
Показывать информацию о программе.
Исходя из приведенной функциональности, наша программа должна иметь следующие элементы: основная форма, модуль данных, вторичные формы (просмотр, редактирование, сортировка для всех таблиц базы данных), параметры программы, диалог для выбора файла данных и форма с информацией о программе.
Для большей универсальности имеет смысл всю специфику вынести в модуль данных, а для работы с таблицами сделать одну общую универсальную форму. Для этого мы будем использовать ряд возможностей, которые нам предоставляет система программирования Delphi. А структура нашей программы будет выглядеть, как приведенная на рис 1.1.
Рисунок 1.1. – Структура программы.
Как видно из приведенного рисунка, самым “функционально нагруженным” у нас является модуль даны. Основная форма ничего не знает о базе данных и о реализации форм просмотра/редактирования таблиц. Все что должна знать Основная форма программы, так это какие действия предусмотрены для реализации необходимой нам функциональности. Мы это обеспечиваем с помощью класса TActionList. Именно в экземпляре этого класса мы храним весь список действий со всеми необходимыми атрибутами (подпись, пиктограмма, строка-подсказка и, собственно, метод реализующий это действие). Такой подход предоставляет нам возможность реализовать несколько разных вариантов основной формы, не затрагивая архитектуру и функциональность всей программы (см. рис.1.2. и рис 1.3).
/>
Рисунок 1.2. — Основная форма программы при использовании ToolBar и MainMenu
/>
Рисунок 1.3. — Основная форма программы при использованииBitBtn и MainMenu
2.2. Организация доступа к базе данных
1.2.1. Разработка и реализация информационных потоков
Для подключения к базе данных Access наиболее простым и универсальным способом является технология ADO. Об особенностях реализации этого подхода мы поговорим позже, а сейчас рассмотрим какие информационные потоки необходимо реализовать в нашем проекте (рис.1.4).
Рисунок 1.4. – Схематическое изображение информационных потоков.
Как видно из приведенного рисунка, в нашем случае используется достаточно простая схема: для работы с каждой таблицей нам необходимо использовать один поток передач данных. Причем, используются одинаковые, по сути, инструменты. А исходя из того, что в каждый отдельный момент времени нам не может понадобиться больше, чем одна форма сразу, то для упрощения программы мы можем воспользоваться следующим подходом – создать универсальную форму для работы со всеми таблицами, а необходимые параметры выбирать при обращении к каждой конкретной таблице.
1.2.2. Подключение к базе данных по технологии ADO
Для доступа к базе данных мы используем ADOConnection. В отличие от других способов доступа к БД в нашем случае для подключения нет возможности использовать привычные свойства DataBaseName и AliasName. При использовании технологии ADO вместо этих свойств используются строки соединения (connection string) и все параметры соединения отображаются и настраиваются именно в них. Существует два основных способа настройки строки соединения – вручную и в специальном диалоговом окне. При собственноручной настройке легко ошибиться в параметрах. И поэтому, большинство разработчиков идет по пути использования редактора строки соединения. Единственный, на наш взгляд, недостаток такого подхода – это привязка к конкретному пути к файлу базы данных. Чтобы избежать недостатков обоих подходов мы пошли по среднему варианту – для первого подключения к базе данных при разработке программы в инспекторе объектов мы использовали редактор строки соединения. И получили правильную строку. Затем, проанализировав ее содержимое, мы увидели в какой части строки хранится информация об имени и пути к файлу базы данных. Теперь, используя элементарные операции для работы со строковым типом данных в Delphi мы можем заменять эту часть строки соединения на любой другой нужный нам файл данных. Это выполняется у нас двумя способами. Первый – автоматически при запуске программы определяется текущий каталог и первое подключение осуществляется к файлу базы данных, который находится в том же каталоге, где и наша программа. Имя файла базы данных (за исключением его расширения) должно совпадать с именем программы. Реализация этого приведена на листинге 1.1. А второй способ – это возможность пользователя нашей программы подключиться к необходимому ему файлу (разумеется, структура базы данных должна совпадать) путем использования диалога выбора файла в форме настройки параметров. (см. рис.1.5, 1.6)
Листинг 1.1. – Фрагмент программы, реализующий автоподключение к БД
procedure TForm5. BitBtn1Click(Sender: TObject);
begin
// Переподключение к БД с заданной строкой подключения
dm. ADOConnection1. Close;
dm. ADOConnection1. ConnectionString: =edit1. Text+edit2. Text+ edit3. Text;
end;
procedure TForm5. FormActivate(Sender: TObject);
begin
// АвтоматическоеопределениеименифайлаБДипутикнему продолжение
--PAGE_BREAK--
Edit2. Text: = ChangeFileExt(application. ExeName,'. mdb');
BitBtn1Click(Sender);
end;
/>
Рисунок 1.5. — Форма ввода параметров
/>
Рисунок 1.6. — Диалог выбора файла базы данных
1.2.3. Разработка универсальной формы для просмотра/редактирования таблиц базы данных
Используя компонент ADOTable мы получаем доступ к любой таблице базы данных. Если не указывать имя таблицы при разработке программы, а динамически его подставлять уже при работе, то в форме автоматически будет открываться нужная нам программа. Для этого необходимо соблюдать несколько правил:
Не создавать полей в компоненте ADOTable на этой форме.
Не создавать столбцов в компоненте DBGrid, который подключен через DataSource к ADOTable на этой форме.
Использовать корректные, понятные для пользователя имена полей при разработке базы данных.
Записывать название таблицы в заголовке формы при ее открытии.
Для обеспечения возможности работы в режиме просмотра мы должны только установить свойство ReadOnly компонента ADOTable в состояние True. С учетом всего вышесказанного, вызов универсальной формы должен осуществляться так, как на Листинге 1.2:
Листинг 1.2. – Фрагмент модуля данных, осуществляющий вызов формы для просмотра/редактирования таблиц базы данных.
procedure Tdm. ShowSlovar (aname: string; RO: boolean=true);
var
f: TForm4;
begin
// Метод реализующий вызов формы просмотра/редактирования таблиц
// aname — имя таблицы
// RO – режим доступа
f: =TForm4. Create(self);
f. ADOT. TableName: =aname;
f. Caption: =aname;
if RO then
begin
f. ADOT. ReadOnly: =RO;
f. Caption: =f. Caption+' (толькочтение) ';
end;
f. ShowModal;
f. Free;
end;
Для реализации возможности сортировки мы используем локальные индексы. Это продемонстрировано на Листинге 1.3.
Листинг 1.3. – Фрагмент программы для сортировки таблиц
procedure TForm3. DBGrid1TitleClick(Column: TColumn);
var i: integer;
begin // Сортировка
// Убираем расскраску стобцов
for i: =0 to DBGrid1. Columns. Count-1 do
begin
DBGrid1. Columns. Items [i]. Color: =clwhite;
end;
Column. Color: =clLime;
if ADOT. IndexFieldNames=Column. Field. FieldName
then
begin
// Если была прямая сортировка, устанавливаем обратную
Column. Color: =clLime;
ADOT. IndexFieldNames: =Column. Field. FieldName+' DESC'
end
else
begin
// Если не было сортировки по этому полю (или обратная)
// устанавливаем прямую сортировку
Column. Color: =clAqua;
ADOT. IndexFieldNames: =Column. Field. FieldName;
end;
end;
В результате мы получили форму, пример использования которой приведен на рис.1.7.
/>
Рисунок 1.7. – Внешний вид универсальной формы при работе с таблицей РемонтУзлов в режиме просмотра.
Заключение
В данной работе была спроектирована и реализована информационная — справочная система «Автосервис», обеспечивающая:
ввод, редактирование и просмотр данных;
ответы на запросы пользователя;
поиск необходимой информации;
формирование отчетов.
Освоены навыки проектирования баз данных методом ER-диаграмм.
Реализация системы проводилась с использованием инструментального средства разработки приложения Microsoft Access2003/XP и языка программирования Object Pascal.
При написании программы основное внимание было уделено удобству работы пользователя с программой и построению дружественного интерфейса.
Результаты тестирования показали, что программа работает верно во всех предполагаемых ситуациях.
Список литературы
1. Хохлачев Е.Н. «Теоретические основы создания и применения АСУ», Москва, Министерство обороны, 1987г.
2. Абчук В.А., Лифшиц А.Л., Федулов А.А., Куштина Э.И. «Автоматизация управления», Москва «Радио и связь», 1984г.
3. Мамиконов А. Г. «Проектирование АСУ» (учебник для вузов), Москва «Высшая школа».
4. Ахаян Р., Горев А., Макашарипов С. «Эффективная работа с СУБД», Санкт-Петербург, 1997г.
5. Гончаров A. "Access 2000 в примерах" Санкт-Петербург, 1997г.
6. Фленов М.Е. Библия Delphi. -2-e изд., БВХ-Петербург, 2008 г.