При этом проявляется ограниченность реляционной модели данных в следующих аспектах:

· Модель не предоставляет достаточных средств для представления смысла данных. Семантика реальной предметной области должна независимым от модели способом представляться в голове проектировщика. В частности, это относится к упоминавшейся нами проблеме представления ограничений целостности.

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

· Хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не предоставляет каких-либо средств для представления этих зависимостей.

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

2.7 Семантические модели данных

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

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

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

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

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

Основные понятия модели (Сущность-Связи)

Далее мы кратко рассмотрим некоторые черты одной из наиболее популярных семантических моделей данных - модель "Сущность-Связи" (часто ее называют кратко ER-моделью).

На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных.

Основными понятиями ER-модели являются сущность, связь и атрибут.

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

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

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

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

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

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

3.1 Особенности базы данных

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

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

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

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

3.2 Реляционные СУБД

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

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

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

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

MS SQL Server - компактная система, сочетающая мощные и надежные механизмы обработки данных с удобными и понятными инструментами для пользователей. Фундаментальные принципы работы СУБД везде одинаковы и, если пользователь знает, как использовать MS SQL Server, переход на Oracle или Informix не представит больших затруднений. Симметричная мультипроцессорная архитектура MS SQL Server предусматривает использование "родных" сервисов операционной системы Windows NT для управления потоками, памятью, операциями дискового чтения/записи, сетевыми службами, функциями безопасности, а также для поддержки параллельного выполнения потоков на нескольких CPU. Использование потоков Windows NT позволяет MS SQL Server автоматически масштабироваться при работе на многопроцессорных платформах, что исключает необходимость дополнительной конфигурации или программной настройки. Сетевые службы Windows NT обеспечивают MS SQL Server поддержку протоколов TCP/IP, NWLink IPX/SPX, Named Pipes (NetBEUI), Banyan Vines, AppleTalk (ADSP) и DECNet. Многопоточное ядро и интеграция со службами планирования потоков Windows NT обеспечивает высокую производительность MS SQL Server при обработке OLTP- и DSS-запросов, что особенно заметно при одновременной работе нескольких сотен пользователей. В состав MS SQL Server входят графические средства управления и утилиты командной строки. Например SQL Enerprise Manager - это мощный централизованный инструмент полного управления серверами в масштабах предприятия, включая базы данных, их объекты, предупреждения, спланированные во времени задачи, тиражирование и запросы. SQL Executive - локальный административный агент для планирования задач, управления предупреждениями и мониторинга активности MS SQL Server и может быть вызван из SQL Enterprise Manager. С помощью SQL Enterprise Manager также можно определить план необходимых рутинных действий по поддержке базы данных: регулярная проверка целостности, резервное копирование, перестройка индексов и т. д., который впоследствии будет выполняться автоматически.

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

MS SQL Server использует в своей работе сервисы безопасности Windows NT. MS SQL Server обеспечивает многоуровневую проверку привилегий при загрузке на сервер. Сначала идентифицируются права пользователя на установление соединения с выбранным сервером (login name и пароль) и выполнение административных функций: создание устройств и баз данных, назначение прав другим пользователям, изменение параметров настройки сервера и т.д. Максимальными правами обладает системный администратор. На уровне базы данных каждый пользователь, загрузившийся на сервер, может иметь имя пользователя (username) базы и права на доступ к объектам внутри нее. Имеется возможность отобразить нескольких login id на одного пользователя базы данных, а также объединять пользователей в группы для удобства администрирования и назначения сходных привилегий. По отношению к объектам базы данных пользователю могут быть назначены права на выполнение различных операций над ними: чтение, добавление, удаление, изменение, декларативная ссылочная целостность (DRI), выполнение хранимых процедур, а также права на доступ к отдельным полям. Если этого недостаточно, можно прибегнуть к представлениям (views), для которых сказанное остается справедливым. Наконец, можно вообще запретить пользователю непосредственный доступ к данным, оставив за ним лишь права на выполнение хранимых процедур, в которых будет прописан весь сценарий его доступа к базе. Хранимые процедуры могут создаваться с опцией, которая шифрует непосредственный текст процедуры, хранящийся обычно в syscomments. Права на выполнение некоторых команд (создание баз, таблиц, умолчаний, правил, представлений, процедур, резервное копирование баз и журналов транзакций) не являются объектно-специфичными, поэтому они назначаются системным администратором сервера или владельцем (создателем) базы данных при редактировании базы данных. Администрирование пользовательских привилегий обычно ведется в SQL Enterprise Manager, тем не менее, в Transact-SQL имеются хранимые процедуры (sp_addlogin, sp_password, sp_revokelogin, sp_addalias, sp_adduser) и операторы (GRANT, REVOKE), которые позволяют осуществлять действия по созданию пользователей, назначению и отмене прав при выполнении скриптов.

3.3 Разработка программного обеспечения

При реализации программы были выбраны:

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

- объектно-ориентированное программирование как наиболее прогрессивное на данный момент из методик программирования;

- клиент-серверная технология реализации сервера баз данных.

Программирование: Microsoft Visual Studio 2010. Данная среда представляет собой интегрированную среду разработки приложений (IDE - Integrated Development Environment), объединяющая в себе компилятор и визуальные инструменты для разработки Windows-ориентированных приложений. Также, данный инструмент бесплатен, в том числе и для коммерческого использования.

В качестве языка программирования клиентской части приложения был выбран язык C#, являющийся «чистым» объектно-ориентированным языком. C# является достаточно молодым и бурно развивающимся языком, вобравшим в себя лучшие стороны Java и C++, и лишенным некоторых излишних сложностей указанных выше языков.

Запросы к БД осуществляются при помощи структурированного языка запросов SQL, в данном случае его расширением компании Microsoft - Transact - SQL.

3.4 Разработка базы данных

Сервер СУБД - Microsoft SQL Server 2008 Express Edition. Данная СУБД представляет собой настольную (Desktop) версию промышленной СУБД Microsoft SQL Server 2008. Вместе с движком БД, поставляется удобный инструмент, Management Studio Express, в котором реализован функционал по навигации объектов БД, встроенный инструмент составления запросов на языке SQL и т.д.

Программа реализована на платформе Microsoft .Net framework v. 2.0 , под операционную систему Windows XP, Windows 7.

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

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

Определим предварительные сущности предметной области:

Накладная - список накладных. Каждая накладная характеризуется такими атрибутами как номер накладной, дата создания, ФИО заказчика, стоимость услуг, добавочная стоимость, пользователь, автосервис, примечание.

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

Автомобили - список автомобилей. Каждый автомобиль характеризуется такими атрибутами как модель и год выпуска.

Список работ - список работ над автомобилем. Характеризуется такими атрибутами как наименование работы, номером накладной, ценой и исполнителем.

Список неисправностей - список неисправностей в автомобиле. Характеризуется наименованием неисправности, номером накладной.

Автосервис - список автосервисов. Характеризуется названием, адресом и телефоном.

Рабочие - список рабочих в данном автосервисе. Атрибуты рабочих -фамилия, имя , отчество.

Пользователи - список пользователей программы. Атрибуты пользователей - фамилия, имя, отчество, ФИО, роль, пароль.

Роли пользователей - список ролей программы. Атрибуты ролей - название, администратор.

Требования пользователей к базе данных:

программа должна предоставлять пользователю возможность добавления, просмотра, редактирования и удаления накладных, при этом должна быть возможность выбора накладных по одному из следующих параметров:

- просмотр накладных за текущую неделю (диапазон 7 дней);

- просмотр накладных за выбранный пользователем диапазон дат;

- просмотр всех введенных накладных.

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

Программа должна содержать формы-справочники для следующих объектов предметной области:

- Заказчики

- Список дефектов автомобиля

- Список работ по каждой накладной

- Список автосервисов

- Список автомобилей

- Список рабочих

- Список пользователей программы

- Список ролей программы

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

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

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

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

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

Автомобили (порядковый номер - потенциальный ключ, модель, год выпуска.

Список работ (порядковый номер - потенциальный ключ, наименование работы, номером накладной - потенциальный ключ, цена, исполнитель - потенциальный ключ.)

Список неисправностей (порядковый номер - потенциальный ключ, наименование неисправности, номером накладной - потенциальный ключ.)

Автосервис (порядковый номер - потенциальный ключ, название, адрес, телефон.)

Рабочие (порядковый номер - потенциальный ключ, фамилия, имя, отчество)

Пользователи (порядковый номер - потенциальный ключ, фамилия, имя, отчество, ФИО, роль - потенциальный ключ, пароль.

Роли пользователей (порядковый номер - потенциальный ключ, название, логическое поле администратор.)

Определим основные связи концептуальной модели.

Заказ (Заказчик - Накладная) - показывает, по какому заказчику создана накладная. Бинарная связь - один ко многим, так как один заказчик может заказать ремонт своего автомобиля несколько раз.

Размещено на http://www.allbest.ru/

Создает (Пользователь - Накладная) - показывает, какой пользователь создает накладную. Бинарная связь - один ко многим, так как каждая пользователь может создать несколько накладных, а каждый накладная относится только к одному пользователю

Размещено на http://www.allbest.ru/

Принадлежит (Автосервис - Накладная) - показывает, какому автосервису принадлежит накладная. Бинарная связь - один ко многим, так как каждый автосервис может иметь несколько накладных, а каждый накладная относится только к одному автосервису.

Размещено на http://www.allbest.ru/

Производит (Рабочий - Список работ) - показывает, какому рабочему соответствует перечень работ. Бинарная связь - один ко многим, так как каждый рабочий может производить несколько списков работ, а каждый список работ относится только к одному рабочему.

Размещено на http://www.allbest.ru/

Соответствует (Роль - Пользователь) - показывает, какому роле соответствует пользователь программы. Бинарная связь - один ко многим, так как каждый роли может соответствовать несколько пользователей, а каждый пользователь относится только к одной роли.

Размещено на http://www.allbest.ru/

Принадлежит (Марка автомобиля -Заказчик) - показывает, какой автомобиль принадлежит заказчику. Бинарная связь - один ко многим, так как каждый автомобиль может принадлежать нескольким заказчикам, а каждый заказчик относится только к одному автомобилю.

Размещено на http://www.allbest.ru/

Содержит (Накладная - Список неисправностей) - показывает, какой накладной соответствует список неисправностей.

Размещено на http://www.allbest.ru/

Включает (Список неисправностей - Список работ) - показывает, на основании какого списка работ формируется накладная.

Размещено на http://www.allbest.ru/

Диаграмма ER-типов логической модели имеет следующий вид.

Размещено на http://www.allbest.ru/

Рисунок 3.1

Схема БД Учет оборудования для сильных сущностей.

Таблица 3.1

Сущность	Имя отношения	Атриибут	Имя атрибута	Тип	Обяза-тельный	Формат	Условие	ПтК	ВК
Заказчик	Customer	Код заказчика	CustomerId	Сч	да	Целое		+
		Фамилия	Surname	Т	нет	Дл 50
		Имя	Firstname	Т	нет	Дл 50
		Отчество	Secondname	Т	нет	Дл 50
		Адрес	Address	Т	нет	Дл 50
		До.м тел	PhoneHome	Т	нет	Дл 20
		Раб. тел	PhoneWork	Т	нет	Дл 20
		Моб. тел	PhoneMob	Т	нет	Дл 20
		Код автомобиля	CarId	Сч	да	Целое			+
		Гос номер	GosNumber	Т	нет	Дл 15
Накладная	Bill	Код накладной	BillId	Сч	да	Целое		+
		Номер	Number	Ч	да	Дл 4
		Дата создания	Date	Д	да	Дл 8
		Код заказчика	CustomerId	Сч	да	Целое			+
		Стоимость	ServicesCost	Ч	нет	Дл 8
		Добавочная стоимость	AddCost	Ч	нет	Дл 8
		Примечание	Description	Т	нет	Дл 1024
		Код автосервиса	AutoServiceId	Сч	да	Целое			+
		Код пользователя	UserId	Сч	да	Целое			+
Авто-мобиль	Car	Код автомобиля	CarId	Сч	да	Целое		+
		Модель	Model	Т	да	Дл 50
		Год выпуска	ModelYear	Т	нет	Дл 50
Список работ	WorkList	Код работ	WorkListId	Сч	да	Целое		+
		Название работ	WorkName	Т	нет	Дл 200
		Код накладной	BillId	Сч	да	Целое			+
		Цена	Price	Т	нет	Дл 50
		Код рабочего	WorkerId	Сч	да	Целое			+
Список неисправ-ностей	DefectList	Код неисправности	DefectListId	Сч	да	Целое		+
		Название	DefectName	Т	да	Дл 200
		Код накладной	BillId	Сч	да	Целое			+
Автосервис	AutoSevice	Код автосервиса	AutoServiceId	Сч	да	Целое		+
		Название	Name	Т	да	Дл 50
		Адрес	Address	Т	да	Дл 50
		Телефон	Phone	Т	нет	Дл 50
Пользователь	User	Код пользователя	UserId	Сч	да	Целое		+
		Фамилия	SurName	Т	да	Дл 50
		Имя	FirstName	Т	да	Дл 50
		Отчество	Secondname	Т	да	Дл 50
		ФИО	FIO	Т	да	Дл 50
		Код роли	UserRoleId	Сч	да	Целое			+
Роли	UserRole	Код роли	UserRoleId	Сч	да	Целое		+
		Название	Name	Т	да	Дл 50
		Администратор	IsAdmin	Л	да	да/нет
Рабо-чий	Worker	Код рабочего	WorkerId	Сч	да	Целое		+
		Фамилия	Surname	Т	да	Дл 50
		Имя	Firstname	Т	да	Дл 50
		Отчество	Secondname	Т	да	Дл 50

Целостность сущностей.

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

Ссылочная целостность.

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

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

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

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

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

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

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

Схема связей БД.

Рисунок 3.2.

4. Руководство по настройке и эксплуатации программного обеспечения

4.1 Настройка системы

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

<имя б.д.>.mdf

<имя б.д.>.ldf , принесенных и скопированных на сервер с любого поддерживаемого техникой носителя).

Синтаксис процедуры выглядит следующим образом:

sp_attach_db <имя б.д.> , `e:\ <имя б.д.>.mdf ' , `e:\ <имя б.д.>.ldf '

Далее запускается процедура:

sp_dboption <имя б.д.> offline, false

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

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

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

4.2 Работа с программой

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

Через главную форму мы имеем доступ ко всем справочникам (через главное меню «Справочники»), в которых можно добавлять, удалять или редактировать все данные.

Рисунок 4.1.

С помощью нажатия соответствующих галочек на главной форме можно выбрать определенный режим вывода накладных:

- накладные за текущую неделю;

- через диапазон дат;

- все накладные сразу.

Вариант вывода накладных с указанием диапазона дат представлен на рисунке 4.2.

Рисунок 4.2

Если необходимо просмотреть подробную информацию по той или иной накладной, добавить или отредактировать данные текущего окна, то это можно сделать, нажав соответственно кнопки “Добавить”, “Редактировать”, при этом появится форма добавления/ редактирования накладной, представленная на рисунке 4.3.



Рисунок 4.3.

Вызов пункта меню «Справочники» - «Заказчики» откроет форму «Справочник заказчиков», изображенную на рисунке 4.4.



Рисунок 4.4.

Для добавления/редактирования данных этого справочника имеются соответствующие кнопки, нажатие которых открывает окно следующего вида:

Форма добавление/редактирование данных (рисунок 4.5.).



Вызов пункта меню «Справочники» - «Работы» откроет форму «Список работ», изображенную на рисунке 4.6.



Рисунок 4.6.

Для добавления/редактирования данных этого справочника имеются соответствующие кнопки, нажатие которых открывает окно следующего вида:

Форма добавление/редактирование данных (рисунок 4.7.).

Рисунок 4.7.

Вызов пункта меню «Справочники» - «Пользователи» откроет форму «Справочник пользователей», изображенную на рисунке 5.8.

Рисунок 5.8.

Для добавления/редактирования данных этого справочника имеются соответствующие кнопки, нажатие которых открывает окно следующего вида:

Форма добавление/редактирование данных (рисунок 5.9.).



Рисунок 5.9.

Вызов пункта меню «Справочники» - «Автомобили» откроет форму «Справочник автомобилей», изображенную на рисунке 5.10.

Рисунок 5.10.

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

5. Тестирование программы

Если программа запускается впервые, то она предупреждает, что нужно для начала установить связь с сервером (рисунок 5.1.).

Рисунок 5.1.

После этого сообщения мы видим окно, в котором должны указать имя сервера и рабочую базу, с которой мы будем работать (рисунок 5.2.).

Рисунок 5.2.

После того, как мы ввели все данные, сообщение покажет нам, что мы подключились к базе или нет (рисунок 5.3.).



Рисунок 5.3.

После этого нам необходимо авторизоваться в программе, т.е. выбрать из списка свою фамилию и ввести пароль (рисунок 5.4.).

Рисунок 5.4.

В случае некорректного ввода данных система выдает сообщение следующего вида:

Рисунок 5.5.

Для предотвращения ввода неверных данных в программе есть обработчики ошибок, некоторые из них приведены ниже:

Рисунок 5.6.

Рисунок 5.7.

В этом случае программа предлагает повторить ввод.

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

6. Организационно - экономический раздел

6.1 Расчет трудоемкости этапов проектирования

Совокупность работ по внедрению новых и совершенствованию ранее освоенных конструкций и технологических процессов называется технической подготовкой производства. Она состоит из двух частей: конструкторской и технологической.

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

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

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

Составление и согласование технического задания - постановка задачи, определение структуры входных и выходных данных;

Разработка эскизного проекта - уточнение работ, связанных с постановкой задачи, а также разработка структурной схемы;

1. Разработка технического проекта - разработка программной модели;

2. Разработка рабочего проекта - обработка результатов проектирования.

Расчет трудоемкости каждого этапа производится согласно методическим указаниям по организационно-экономической части дипломного проекта.

1 Этап. Составление и согласование технического задания

Объем работ по составлению и согласованию технического задания эквивалентен разработке 8 листов формата А4. Трудоемкость одного листа формата А4 с учетом сложности и новизны равна 11.6 час.

1. Изучение литературы и аналогичных работ, а также составление технического задания - 7 листов формата А4:

T1 = 11.6 * 7 = 81.2 час.

Исполнители:

Постановщик - 81.2 час.

2. Согласование технического задания равно по объему 1 листу формата А4:

час.

Исполнители:

Инженер-программист - 11.6 час.

Продолжительность 1 этапа - 11.6 дня

2 Этап. Разработка эскизного проекта

Для разработки эскизного проекта требуется выполнить объем работ на 13 листах формата А4. На этапе эскизного проектирования при определении трудоемкости вводится коэффициент 0.7:

1. Разработка ER-модели - 5 листов формата А4:

T3 = 11.6 * 5 * 0.7 = 40.6 час.

Исполнители:

Инженер - программист - 40,6 час.

2. Разработка базы данных - 8 листов формата А4:

T4 = 11.6 * 8 * 0.7 = 64.96 час.

Исполнители:

Инженер-программист - 64.96 час.

Продолжительность 2 этапа - 13.2 дней

3 Этап. Разработка технического проекта

Разработка технического проекта включает в себя этапы:

1. Подготовка данных для экспортирования на ЭВМ - 1 лист формата А4

T5 = 11.6 час.

Исполнители:

Инженер- программист - 11.6 час.

2. Диагностика системы осуществляется с помощью MS SQL7. Диагностикой системы занимается инженер-программист, который выполняет эту работу в течение 8 недель (т. е. 40 рабочих дней по 8 часов каждый).

Продолжительность выполнения работ:

T6 = tc*Nд,

tc - продолжительность рабочего дня;

Nд - количество рабочих дней;

T6 = 40*8 = 320 часов.

Продолжительность 3 этапа - 41.5 дней

4 Этап. Разработка программного обеспечения

1. Проектирование пользовательского интерфейса - 8 листов формата А4:

T7 = 11.6 * 8 = 92.8 час.

Исполнители:

Инженер-программист - 92.8 час.

2. Настройка на рабочих станциях - 4 листа формата А4:

T8 = 11.6 * 4 = 46.4 час.

Исполнители:

Инженер-программист - 46.4 час.

Продолжительность 4 этапа - 17.4 дня

Таблица 6.1.

Этапы проектирования и виды работ

Наимено-вание этапа	Исполнитель	Трудоем-кость, час.	Тарифная ставка, руб./час	Сумма по этапам, руб.	Продолжи-тельность этапа, дни
1.Техническое задание	Постановщик	81.2	78,7	7121,24	11.6
	Инженер - программист	11.6	105	1218
2.Эскизный проект	Инженер - программист	40,6	105	4263	13.2
	Инженер - программист	64,96	105	6820,8
3.Технический проект	Инженер - программист	320	105	33600	41.5
	Инженер - программист	11.6	105	1218
4.Рабочий проект	Инженер - программист	92,8	105	9744	17.4
	Инженер - программист	46,4	105	4872
Итого:	68860,04	83.7

Таблица 6.2.

Затраты по каждой категории.

№ п/п	Должность	Затраты, руб.
1	Главный инженер	7121,24
2	Инженер программист	61738,8

На рис.7.1 показана продолжительность разработки модели в виде линейного графика:



Рисунок 6.1. Линейный график продолжительности разработки модели.

Рисунок 6.2. Ленточный график продолжительности разработки модели

Исходные данные представлены в табл. 6.1

6.2 Расчет плановой себестоимости разработки

Целью планирования себестоимости разработки является экономически обоснованное определение затрат на её выполнение. Определение затрат производится путем составления калькуляции плановой себестоимости. Она составляется по следующим статьям:

- материалы и покупные комплектующие изделия;

- основная заработная плата;

- дополнительная заработная плата;

- отчисления на социальное страхование;

- накладные расходы.

6.2.1 Расчет затрат по статье «Материалы и покупные комплектующие изделия»

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

Таблица 6.3

Затраты на приобретение расходных материалов

Вид материалов	Количество	Цена за ед., руб.	Итого расходов, руб.
Диски	2 шт.	15	30,00
Бумага	1 пачка	165	165,00
Ватман	7 листов	45	315,00
Картридж для принтера	1 шт.	1200	1200,00
Итого	1710,00

Исходя из трудоемкости проекта, определяем затраченное машинное время равное 600 часов.

Для определения затрат на оборудование необходимо учитывать две статьи расходов:

· Амортизационные отчисления:

,

где - первоначальная стоимость оборудования,

- время использования оборудования,

- норма амортизации,

- годовой действительный фонд времени оборудования.

Таблица 6.4.

Стоимость оборудования и суммы амортизационных отчислений

Наименование оборудования	Стоимо-сть, руб.	Время исполь-зования, год	Норма аморти-зации, %	Сумма аморти-зации, руб/год	Итого расходов, руб
IBM PC Celeron 2G	24300	0.3	20	4374	1458
Итого	1458

· Расчет затрат на электроэнергию:

Расход электроэнергии определяется, исходя из установленной мощности оборудования, его времени работы и стоимости киловатт-часа электроэнергии. В данный момент стоимость киловатт-часа электроэнергии составляет 4 руб. 18 коп.

Таблица 6.5.

Расчет затрат на электроэнергию

Наименование оборудования	Потребляемая мощность, кВт/час	Время использования, час	Расходы на электроэнергию, руб
IBM PC Celeron 2G	0.09	600	225,72
Итого	225,72

Итого, затраты на эксплуатацию оборудования и его амортизацию составили:

Зэкс = 1458 + 225,72 = 1683,72 руб.

Расчет основной заработной платы.

На статью «Основная заработная плата» относятся затраты по оплате труда научных сотрудников, ИТР, копировщиков, лаборантов и рабочих. Исходными данными для расчета является трудоемкость отдельных видов работ по категориям работающих.

Основная заработная плата исполнителей на проектирование модели составила:

ЗПосн = 68860,04 руб. (табл.5.1.)

Расчет дополнительной заработной платы.

На статью «Дополнительная заработная плата» относятся выплаты, предусмотренные законодательством за не проработанное (не явочное) время: оплата очередных и дополнительных отпусков, оплата времени, связанного с выполнением государственных и общественных обязанностей и другое. Размер дополнительной заработной платы определяется в процентах (10%) от основной заработной платы:

ЗПдоп = 0,1* ЗПосн = 6886 руб.

Отчисления на социальные нужды.

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

Отч = (ЗПосн + ЗПдоп)*0.3 = 22723,81 руб.

Накладные расходы.

В статью «Накладные расходы» включают расходы на управление и хозяйственное обслуживание, которые в равной степени относятся ко всем выполняемым разработкам. Величина накладных расходов определяется в размере 150% от основной заработной платы работников, участвующих в выполнении разработки:

НР = ЗПосн * 1.5 = 103290,06 руб.

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

Таблица 7.6.

Калькуляция плановой себестоимости

№ п/п	Наименование статьи	Расходы, руб
1	Расходные материалы	1710,00
2	Основная заработная плата	68860,04
3	Дополнительная заработная плата	6886,00
4	Отчисления на социальные нужды	16664,13
5	Расходы на оборудование	1683,72
6	Накладные расходы	103290,06
Итого:	199093,95

6.3 Определение экономической эффективности

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

К показателям эффективности относятся

- рентабельность

- срок окупаемости вложений

- прибыль.

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

Экономия рабочего времени

Таблица 6.7

Численность персонала СТО.

Мастерская	Численность, чел.
Механическая	2
Покрасочная	2
Шиномонтаж	2
Стекольная	2

До внедрения системы автоматизации проведенный хронометраж при определенных операциях имел следующие результаты.

Таблица 6.8.

Хронометраж операций до внедрения

Мастерская	Операция	Время выполнения
Механическая	Прием нового клиента: Опрос Запись неисправностей	27 мин 20 мин 7 минут
Покрасочная	Прием нового клиента: Осмотр Расчет расхода краски Запись	39 мин 25 мин 10 мин 4 мин
Шиномонтаж	Прием нового клиента: Осмотр Запись	6 мин 3 мин 3 мин
Стекольная	Прием нового клиента: Осмотр Запись	6 мин 3 мин 3 мин
Электрики	Прием нового клиента: Осмотр Запись	10 мин 5 мин 5 мин

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

Таблица 7.9.

Хронометраж операций после внедрения

Мастерская	Операция	Время выполнения
Приемка автомобиля	Постановка автомобиля в очередь на ремонт: Опрос Осмотр Запись Расчет	31 мин 15 мин 5 мин 6 мин 5 мин
Механическая	Прием автомобиля на пост	5 мин
Покрасочная	Прием автомобиля на пост	5 мин
Шиномонтаж	Прием автомобиля на пост	5 мин
Стекольная	Прием автомобиля на пост	5 мин
Электрики	Прием автомобиля на пост	5 мин

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

Для проведения данного анализа была выбрана одна из самых распространенных операций - ремонт проколотого колеса.

В таблице 6.10 приведены данные хронометража по операциям.

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

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

Из этого следует экономия заработной платы исполнителей. При дальнейших расчетах и анализе других участков была получена суммарная экономия рабочего времени, которая составила 36,54% в день, то есть более трети рабочего дня, приблизительно 2 часа 54 минуты.

Из этого следует экономия заработной платы исполнителей.

Затраты на заработную плату инженера механика:

а) затраты по статье «основная заработная плата»:

Зосн. = t*T;

Т - тарифная ставка.

Тарифная ставка инженера механика составляет 84 руб./час.

Зосн. = 176*84 = 14784 руб.;

б) затраты по статье «дополнительная заработная плата» составляют 10% от основной:

Здоп. = 0.1*Зосн.;

Здоп. = 0.1*14784 = 1478,4 руб.;

в) затраты по статье “Отчисления от ЗП” (отчисления на социальное страхование) составляет 30% от суммы основной и дополнительной заработной платы:

Зот. = 0.3*(Зосн. + Здоп.);

Зот. = 0.03*(14784 + 1478,4) = 0.3*16262,4= 4878,72 руб.;

Общие затраты:

Зобщ.1 = Зосн. + Здоп. + Зот.;

Зобщ.1 = 14784 + 1478,4 + 4878,72 = 21141,12 руб..

Затраты на заработную плату техника:

а) затраты по статье основная заработная плата:

Зосн. = t*T;

Т - тарифная ставка.

Тарифная ставка техника составляет 65 руб./час.

Зосн. = 176*65 = 11440 руб.;

б) затраты по статье дополнительная заработная плата составляют 10% от основной:

Здоп. = 0.1*Зосн.;

Здоп. = 0.1*11440 = 1144 руб.;

в) затраты по статье “Отчисления от ЗП” (отчисления на социальное страхование) составляет 30% от суммы основной и дополнительной заработной платы:

Зот. = 0.3*(Зосн. + Здоп.);

Зот. = 0.3*(11440 + 1144) = 0.3*12584= 3775,2 руб.;

Общие затраты:

З'общ. = Зосн. + Здоп. + Зот.;

З'общ. = 11440+1144 + 3775,2 = 16359,2 руб..

Так как все сотрудники кроме инженера механика занимают ставку техника то сумму увеличиваем в 7 раз.

Зобщ.2 = З'общ.*2;

Зобщ.2 = 16359,2*2 = 32718,4 руб..

Таким образом общие затраты на зарплату работников сервиса при 8 часовом рабочем дне составят:

Зобщ. = Зобщ.1 + Зобщ.2;

Зобщ. = 21141,12 + 32718,4 = 53859,52 руб.

По полученным данным строится таблица 7.11.

Таблица 7.11.

Расчет месячного фонда оплаты труда в одной мастерской

Должность	Кол-во	Отработано, час.	Тарифная ставка, руб.	ОЗП, руб.	ДЗП, руб.	ОтЗП, руб.	Сумма, руб.
Инженер механик	1	176	84	14874	1487,4	4878,72	21141,12
Техник	2	176	65	11440	1144	3775,2	32718,4
Итого: 53859,52

ОЗП - основная заработная плата;

ДЗП - дополнительная заработная плата;

ОтЗП - отчисления на социальное страхование;

Общая годовая экономия будет составлять:

Эг = Эт + Эр;

Эг - годовая экономия;

Эт - экономия топлива;

Эр - экономия в заработной плате обслуживающего персонала;

Годовая экономия рабочего времени одного сотрудника после применения автоматизированной системы составит порядка 29 дней соответственно общая годовая экономия составит.

Эг = 53859,52 руб.

Примерный срок окупаемости:

О = Зг/Эр;

О - срок окупаемости;

О = 53859,52/199093,95 = 0,27г; 0.27*365 = 99 дней.

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

7. Мероприятия по экологии и охране жизнедеятельности

Введение

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

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

Правила и нормы труда конкретизируют мероприятия, направленные на выполнение основных законоположений по охране труда. Важное место среди правил и норм отводится системе стандартов безопасности труда (ССБТ), представляющей собой комплекс взаимосвязанных стандартов, направленных на обеспечение безопасности труда. ССБТ устанавливает:

общие требования и нормы по видам опасных и вредных производственных факторов;

общие требования безопасности к производственному оборудованию и процессам;

требования к средствам защиты работающих;

методы оценки безопасности труда.

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

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

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

создать безопасные условия для работы сотрудников;

своевременно производить мероприятия по технике безопасности;

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

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