В настоящее время компьютеры широко используются во многих сферах человеческой деятельности. Ни одно учреждение не может выполнять свою работу без использования компьютеров, которые успешно заменяют рутинную работу, выполнявшуюся ранее вручную, повышая эффективность любого учреждения.
Сфера услуг в настоящее время является одним из важных секторов национальной экономики, призванных удовлетворить индивидуальные потребности и потребности населения страны в различных видах услуг. Сфера услуг как сфера экономической деятельности — это совокупность организаций, целью которых является оказание различных платных услуг по индивидуальным заказам населения. Таким образом, сфера услуг решает важнейшие социально-экономические проблемы и ее значение в жизни общества постоянно возрастает. Одним из видов таких услуг являются услуги автосервиса.
В предлагаемой программе реализована справочно-информационная система, предназначенная для организации учета распределения работы по отделам и сотрудникам, а также ведется учет стоимости выполненных работ. Приложение позволяет вводить, редактировать и просматривать содержимое базы данных, а также отвечать на запросы пользователей и создавать серию отчетов.
Данная информационная система может применяться в автосервисах. Она легка в обращении, позволяет хранить большое количество сведений в одной базе данных, экономит рабочее время за счет автоматизации некоторых процессов таких как, учет стоимости работ, а также учет распределения работ по отделам. Поэтому ожидается, что предлагаемая программа значительно упростит работу автосервисов.
Анализ предметной области
Предметная область – учет работ отделов автосервиса.
Процесс оказания автосервисных услуг состоит из трех взаимосвязанных элементов:
- прием заказов на услуги от населения;
- выполнение заказов;
- реализация услуг.
Получение заказов от населения — это начальный этап процесса оказания услуги. Он включает определение состава услуги. При этом на данной стадии выполняется ряд операций технологического характера, которые в значительной степени влияют на весь дальнейший процесс производства (например: выявление дефектов автотранспорта подлежащего ремонту).
Следующим этапом оказания услуг является непосредственное производство, организация которого во многом определяется характером оказываемых услуг.
Заключительная стадия процесса оказания автосервисных услуг – реализация заказов, т.е. доведение услуг до потребителя. Одной из особенностей, присущих предприятиям сферы обслуживания, является то обстоятельство, что они имеют непосредственный контакт с потребителем при оказании услуг, т.е. в процессе своей деятельности осуществляют не только производственные, но и торговые функции.
Разработка бизнес-плана реализации проекта оказания услуг по ...
... оценку намеченным мероприятиям. Целью настоящей курсовой работы является разработка бизнес-плана реализации проекта оказания услуг по грузоперевозкам населению ООО «Нужные люди». Предмет курсовой работы: услуги грузоперевозки. Объект курсовой работы ООО «Нужные люди». Задачи курсовой работы: изучить организационно-экономическую характеристику ...
Взаимоотношения предприятий автосервиса, оказывающих платные услуги, и заказчиков в процессе их обслуживания, регулируются правилами предоставления услуг, которые определяют порядок приема и оформления заказов, исполнения заказов, расчетов с заказчиками, а также имущественную ответственность как предприятия, так и заказчика.
Заказы на платные услуги оформляются как специальными первичными документами, так и путем выдачи жетонов, талонов, кассовых чеков, расписок и т.д.
На предприятиях автосервиса используются следующие формы документов строгой отчетности:
- БО-1 – квитанция – оформляется на все виды ремонта, требующего расхода материалов;
- БО-9 — инкассо-кассовый аппарат — выдается для срочного и мелкого ремонта, проводимого в присутствии заказчика.
В процессе эксплуатации автомобиля могут выявиться конструктивные и производственные недостатки (дефекты), приводящие к изменению технического состояния деталей, узлов, агрегатов, вследствие чего происходит их естественный износ.
Различают механический, абразивный, коррозийный и усталостный износ.
Механический износ происходит из-за дробления или скалывания частиц с поверхности деталей, что вызывает изменение массы и размеров детали.
Абразивный износ является результатом царапания или резания более твердых частиц одной из сопрягаемых частей, частиц, попадающих из воздуха или захваченных смазкой.
Коррозийный износ является следствием воздействия агрессивной среды (кислот, щелочей, кислорода) на поверхность деталей.
Усталостный износ вызывается множественными переменными нагрузками.
Большинство транспортных средств одновременно подвержены разным видам износа.
Отклонение технического состояния автомобиля (прицепа) и его агрегатов от установленных норм называется неисправностью. Нарушение работоспособности транспортного средства, повлекшее прекращение процесса перевозки, называется поломкой.
Для обеспечения бесперебойной работы автомобильного транспорта необходимо не только повседневное наблюдение за его состоянием в процессе эксплуатации (смазка, осмотр и т.п.), но и периодическое проведение ремонта. Неравномерный износ отдельных узлов и деталей, составляющих ту или иную конструкцию автомобильного транспорта, потребовал разработки специальной системы профилактического обслуживания. Система технического обслуживания автомобильного транспорта является плановой и профилактической, и все мероприятия, предусмотренные для каждой услуги, должны выполняться в полном объеме. Эта система способствует постоянному поддержанию автомобилей и прицепов в работоспособном виде, уменьшению интенсивности износа деталей, предупреждению отказов и неисправностей, снижению расхода топлива и смазочных материалов, повышению надежности и безопасности эксплуатации и увеличению пробега автомобилей до ремонта.
Работы по ремонту, смазке, наполнению, регулировке, электрике, сбору и мойке, выполняемые в сроки, предусмотренные техническим обслуживанием, позволяют нам гарантировать нормальные условия эксплуатации для всех систем и механизмов автомобиля.
Работа автотранспортного предприятия
... выполняющая обслуживание, ремонт и хранение подвижного состава. Целью данной курсовой работы является рассчитать ... капитального ремонта-нормативы -трудоемкости применительно к условиям эксплуатации и оснащенности АТП. 3.1 Корректировка пробегов по условиям эксплуатации Пробег до капитального ремонта: ... осуществляется на основании заявок, разрабатываемых предприятиями-заказчиками. Исходными данными при ...
Техническое обслуживание — профилактическое мероприятие, которое в обязательном порядке проводится в плановом порядке после определенного пробега или наработки подвижного состава. Периодичность технического обслуживания устанавливается исходя из фактически пройденных километров с учетом условий эксплуатации. Для каждой категории условий эксплуатации наибольшая периодичность технического обслуживания принята для легковых автомобилей, затем автобусов и грузовиков.
Ремонт подвижного состава автомобильного транспорта предназначен для регламентированного восстановления и поддержания работоспособности автомобилей и прицепов, устранения поломок и неисправностей, возникших в процессе эксплуатации или выявленных при техническом обслуживании. Ремонтные работы выполняют как по потребности (после появления соответствующего отказа или неисправности), так и по плану через определенный пробег или время работы подвижного состава.
Существует два вида ремонта: капитальный и текущий. Последний, в свою очередь, делится на средний, малый, и текущее (межремонтное) обслуживание. Капитальный ремонт, как правило, проводится в специализированных, текущих ремонтных предприятиях — на автотранспортных предприятиях или на СТО.
Капитальный ремонт включает в себя осмотр и диагностику, сборку, регулировку, слесарь, слесарь, медь, жесть, обои, электрика, ремонт шин, покраску и другие работы. Ремонтные работы могут проводиться как на отдельных узлах, агрегатах, так и на подвижном составе в целом. При капитальном ремонте агрегат полностью разбирается, выявляются дефекты, отдельные детали восстанавливаются или заменяются, затем собираются, настраиваются и тестируются. Если капитальному ремонту подвергается весь автомобиль, то он также полностью разбирается, все детали неисправны, восстанавливаются и заменяются, собираются, а узлы и агрегаты регулируются и проверяются.
Текущим считается ремонт, при котором агрегат разбирается только частично и восстанавливаются и заменяются только те детали, продолжительность которых равна межремонтному периоду. Текущий ремонт обычно выполняется без снятия агрегата с фундамента. При этом средний текущий ремонт отличается от мелкого только объемом ремонтных работ. Текущее (межремонтное) обслуживание сводится к повседневному наблюдению за состоянием оборудования и устранению мелких неисправностей.
Счета ремонта транспортных средств следует вести по его типам: капитальный и текущий, с разделением на средний, малый ремонт и капитальный ремонт.
Разработанная информационная система должна позволять вести базу данных по подразделениям, видам оказываемых услуг, сотрудникам, а также обеспечивать интерактивные средства ввода, редактирования, поиска информации и вывода отчетов.
Входными данными должны быть:
- по заявкам – номер, дата заявки, контрагент, сумма авансового платежа, вид оказываемых услуг;
- по контрагентам – сведения о контрагенте, предоставляемая скидка;
- по отделам – код отдела, наименование;
- по дисциплинам – код дисциплины, наименование, преподаватель, принадлежность к кафедре;
- по видам работ – наименование работы, работник, выполняемый данный вид ремонта;
Выходными данными должны быть:
База данных «Грузоперевозки»
... и быстро принять заказ. 2. Оказание качественной работы по перевозки груза. 3. Загрузка и разгрузка. В данной курсовой работе рассматривается задачи, выполняемые диспетчерами компании грузоперевозок. Данная ... заказа Вносить изменения связанные с заказом Такое представление повышает удобство использование базы данных, в данном случае ввод информации сведется к выбору необходимых сведений из списка, ...
- сформированный счет, за оказанный ремонт;
- начисленная заработная плата сотрудников.
Инфологическое проектирование
В автоматизированных информационных системах отражение дисциплинарной области представлено многоуровневыми моделями данных, одной из которых является информационная модель. Он показывает часть реального мира, называемую предметной областью. Для описания изучаемой предметной области используются искусственные формализованные языковые средства. В этом отношении информационная модель означает описание дисциплинарной области, созданное с использованием определенных лингвистических инструментов, которые не зависят от программного обеспечения, используемого в будущем.
Ядром инфологической модели является описание объектов предметной области и связей между ними (сущность — связь).
Для описания инфологической модели используют как языки аналитического(описательного) типа, так и графические средства. Графические инструменты более наглядны и понятны. Для построения модели данных используется удобный инструмент – ERWin. ERwin — средство разработки структуры базы данных (БД).
Как правило, разработка модели базы данных состоит из двух этапов: составление логической модели и создание на ее основе физической модели. ERwin полностью поддерживает такой процесс, он имеет два представления модели: логическое (logical) и физическое (physical).
Таким образом, разработчик может строить логическую модель базы данных, не задумываясь над деталями физической реализации, т.е. уделяя основное внимание требованиям к информации и бизнес-процессам, которые будет поддерживать будущая база данных.
При проектировании структуры новой базы данных определяют сущности (объекты, явления) предметной области, которые должны найти свое отражение в базе данных. Цель инфологического этапа проектирования состоит в получении семантических (концептуальных) моделей, отражающих предметную область и информационные потребности пользователей. В качестве инструмента для построения семантических моделей данных на этапе инфологического проектирования является неформальная модель «Сущность-Связь» (ER-модель — Entity-Relationship).
Моделирование предметной области основано на использовании графических диаграмм, включающих небольшое количество разнородных компонентов.
Основными понятиями ER-модели являются сущность, связь и атрибут.
Сущность (объект) — это реальный или представляемый объект предметной области, информация о котором должна сохраняться и быть доступна. Различают такие понятия, как тип сущности и экземпляр сущности. Понятие типа сущности относится к набору однородных объектов, событий, личностей, которые действуют как единое целое. Экземпляр сущности относится к конкретной вещи в наборе. В диаграммах ER-модели сущность представляется в виде прямоугольника (в нотации Баркера), содержащего имя сущности.
Атрибут — это именованная характеристика объекта, которая определяет его свойства и принимает значения из набора значений. Каждый атрибут обеспечивается именем, уникальным в пределах сущности.
Атрибуты можно классифицировать по одному из трех различных типов: описательный, ориентировочный, вспомогательный. Описательные атрибуты представляют собой факты, присущие каждому экземпляру объекта. Атрибуты указания используются для наименования или обозначения экземпляров объекта. Вспомогательные атрибуты используются для связывания экземпляра одной сущности с экземпляром другой. Атрибуты подчиняются строго определенным правилам.
Набор из одного или нескольких атрибутов, значения которых однозначно идентифицируют каждый экземпляр объекта, называется идентификатором. Каждый экземпляр сущности должен иметь хотя бы один идентификатор. Если имеется несколько идентификаторов, один из них выбирается как привилегированный.
Связь (Relationship) — это поименованная графически изображаемая ассоциация, устанавливаемая между сущностями и представляющая собой абстракцию набора отношений, которые систематически возникают между различными видами предметов в реальном мире. Большинство отношений относятся к бинарной категории и возникают между двумя объектами.
Среди бинарных связей существуют три фундаментальных вида связи: один-к-одному (1: 1), один-ко-многим (1: M), многие-ко-многим (M: M).
Связь один-к-одному (1: 1) существует, когда один экземпляр одной сущности связан с единственным экземпляром другой сущности. Связь один-ко-многим (1: M) имеет место, когда один экземпляр одной сущности связан с одним или более экземпляром другой сущности и каждый экземпляр второй сущности связан только с одним экземпляром первой сущности. Связь многие-ко-многим (М: N) существует, когда один экземпляр одной сущности связан с одним или более экземпляром другой сущности и каждый экземпляр второй сущности связан с одним или более экземпляром первой сущности.
Условные отношения, в отличие от безусловных, могут содержать экземпляры сущностей, которые не участвуют в связи. Если связь условная с обеих сторон, она называется биусловной.
Все связи требуют описания. Описание должно обеспечивать:
- идентификатор связи;
- формулировку имен связи с точки зрения каждой участвующей сущности;
- вид связи (множественность и условность);
- формулировку того, как связь была формализована.
Цель формализации отношения — позволить экземпляру одного объекта быть связанным с экземпляром другого. Формализация связи выполняется путем вставки вспомогательных атрибутов в соответствующие сущности модели.
Все сущности относятся к одному из четырех классов:
- стержневые;
- ассоциативные;
- характеристические;
- обозначающие.
Стержневая сущность (стержень) представляет собой независимую сущность.
Ассоциативная сущность (ассоциация) — это сущность, формализующая связь вида 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 символов, обязательное |
|
Ремонт |
Текстовый |
длина 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
// Автоматическое определение имени файла БД и пути к нему
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 г.
