Главная

Рефераты, курсовые

Сочинения
- русские
- белорусские
- английские

- литературные герои
- биографии

Изложения
- русские
- белорусские

Словари
- афоризмы
- геология
- полиграфия
- социология
- философский
- финансовый
- энциклопедия юриста
- юридический

ГДЗ решебники
Рефераты - Афоризмы - Словари
Русские, белорусские и английские сочинения
Русские и белорусские изложения
Отзывы

Информационная система для автоматизации хозяйственно-экономической деятельности строительной компании

Работа из раздела: «Программирование, компьютеры и кибернетика»

/

Оглавление

Введение

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

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

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

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

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

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

1. Проектирование информационной системы

1.1 Сущность информационной системы

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

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

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

1.2 Функциональная спецификация

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

На Главном экране приложения отображается общая информация о компании, ее истории, реквизитах, построенных и строящихся объектах недвижимости. Этот экран в первую очередь предназначается для потенциальных клиентов компании. Также на этом экране имеется кнопка входа в приложения для авторизованных пользователей.

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

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

автоматизация информационная система пользовательский

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

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

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

1.3 Подходы к проектированию ИС

Проблема сложности является главной проблемой, которую приходится решать при создании больших и сложных ИС. Ни один разработчик не в состоянии понять всю систему в целом. На сегодняшний момент существует два подхода к разработке ИС, которые обусловлены разными принципами декомпозиции системы: [3]

· Функционально модульный или структурный - в основу положен принцип функциональной декомпозиции, в котором система описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами

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

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

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

Во второй половине 80х годов появилось методология объектно-ориентированного программирования

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

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

“Объектно-ориентированные системы более открыты и легче поддаются внесению изменений, поскольку их конструкция базируется на устойчивых формах. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований”. [3]

В данном дипломном проекте используется методология объектно-ориентированного подхода для описания бизнес процессов предприятия.

1.4 Унифицированный язык моделирования UML

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

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

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

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

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

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

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

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

Предварительные версии UML начали использоваться в области создания программного обеспечения, а на основании отзывов потребителей производились существенные доработки. Многие корпорации ощутили, что язык UML может оказаться полезным для достижения их стратегических целей. Это привело к возникновению консорциума UML, в который вошли такие компании, как DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments, Rational и другие. В 1997 году консорциум выработал первую версию UML и представил ее на рассмотрение группе OMG (Object Management Group), откликнувшись на ее запрос о подаче предложений по стандартному языку моделирования. [6]

После расширения консорциума вышла версия 1.1 языка UML, которую группа OMG приняла в конце 1997 года. После этого OMG приступила к сопровождению UML и выпустила в 1998 году две его новые версии. Язык UML стал стандартом де-факто в области разработки программного обеспечения. В настоящее время этот язык продолжает активно развиваться

Язык UML предназначен для решения следующих задач:

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

o Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей системы в ООАП (объектно-ориентированный анализ и проектирование) конкретной предметной области.

o Ни одна из конструкций языка UML не должна зависеть от особенностей ее реализации в известных языках программирования.

o Поощрять развитие рынка объектных инструментальных средств.

o Способность совершенствоваться.

o Интегрировать в себя новейшие и наилучшие достижения практики

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

· Диаграмма вариантов или прецедентов использования (use case diagram)

· Диаграмма классов (class diagram)

· Диаграммы поведения (behavior diagrams)

o Диаграмма состояний (statechart diagram)

o Диаграмма деятельности (activity diagram)

· Диаграммы взаимодействия (interaction diagrams)

o Диаграмма последовательности (sequence diagram)

o Диаграмма кооперации (collaboration diagram)

· Диаграммы реализации (implementation diagrams)

o Диаграмма компонентов (component diagram)

o Диаграмма развертывания (deployment diagram)

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

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

1.5 CASE средство Rational Rose

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

CASE-средство Rational Rose со времени своего появления претерпело серьезную эволюцию и превратилось в современное и мощное средство анализа, моделирования и разработки программных систем. Именно в Rational Rose 98/2000 язык UML стал базовой технологией визуализации и разработки программ, что определило популярность и стратегическую перспективность этого инструментария.

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

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

· сокращение время разработки;

· уменьшение ручного труда, увеличение продуктивности;

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

· способность вести большие проекты или группу проектов;

· позволяет быть языком общения между различными разработчиками.

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

1.6 Диаграмма вариантов использования

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

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

· Сформулировать общие требования к функциональному поведению проектируемой системы.

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

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

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

Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим редактором для построения Use Case диаграмм (сценариев). Опишем основные элементы см. таблице 1.1.

Рис 1.1 Диаграмма прецедентов

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

Следует предпочитать небольшие и детализованные варианты использования, поскольку они облегчают составление и реализацию согласованного плана проекта. [3]. Ниже приведена уточненная диаграммы вариантов использования.

Рис.1.2 Диаграмма управляющего

Диаграммы состояний.

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

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

Процессы, происходящие в этот момент, когда объект находится в определенном состоянии, называются действиями (actions).

С состоянием можно связывать следующие данные: деятельность, входное действие, выходное действие и событие.

Деятельность (activity) - это поведение, реализуемое объектом, пока он находится в данном состоянии. Деятельность изображают внутри самого состояния; ее обозначению должно предшествовать слово do (делать) и двоеточие.

Входное действие (entry action) - это поведение, которое выполняется, когда объект переходит в данное состояние. Входное действие также показывают внутри состояния, его обозначению предшествуют слово entry (вход) и двоеточие.

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

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

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

Рис.1.3 Диаграмма состояний 'Объекта строительства'

Диаграмма деятельности

Выделен объект, данные о котором необходимо хранить в базе данных.

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

Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим редактором для построения Activity диаграмм (деятельности).

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

· анализ варианта использования. На этой стадии нас не интересует связь между действиями и объектами, а нужно только понять, какие действия должны иметь место и каковы зависимости в поведении системы. Связывание методов и объектов выполняется позднее с помощью диаграмм взаимодействия;

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

Рис.1.4 Диаграмма активности 'Создание объекта'

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

Диаграммы взаимодействия

Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп объектов. Каждая диаграмма описывает поведение объектов в рамках только одного прецедента. На диаграмме изображаются объекты и те сообщения, которыми они обмениваются между собой. Определяют три типа сообщений:

· информационные (informative) - сообщения, снабжающие объект-получатель информацией для обновления его состояния;

· сообщения - запросы (interrogative) - сообщения, запрашивающие выдачу информации об объекте-получателе;

· императивные (imperative) - сообщения, запрашивающие у объекта-получателя выполнение действия.

Существует два вида диаграмм взаимодействия:

· последовательности (sequence diagrams);

· кооперативные (collaboration diagrams).

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

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

Рис.1.5 Диаграмма последовательности 'Назначение строителя на объект'

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

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

Рис.1.6. Кооперативная диаграмма 'Назначение строителя на объект

Алгоритм работы с системой через WEB-интерфейс

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

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

В Rational Rose включен Add In под названием Web Modeler для проектирования сайтов.

Последовательность действий при создании Web приложения:

ь Подключить Web Modeler при помощи пункта меню Add In - Add In Manager - Web Modeler. В меню Tools появится новый пункт Web Modeler

ь Изменить установки принятые по умолчанию Tools - Options - Notation - Default Language - Web Notation

Используется специальный стереотип позволяющий выделять html-страницы. На основе созданной диаграммы автоматически генерируется связанные html-страницы.

Рис.1.7 Алгоритм работы с программой

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

2.1 Требования, предъявляемые к базе данных

1) Минимальная избыточность. Данные, хранимые в памяти ЭВМ, могут содержать как полезную, так и вредную избыточность. Вредная избыточность всегда имеет место, когда каждый пользователь вынужден создавать для своих приложений отдельный набор данных. Если нескольким пользователям требовались бы одни и те же данные, то они повторялись бы в каждом наборе. Такую избыточность часто называют неконтролируемой, поскольку об её существовании отдельные пользователи могут и не подозревать. К полезной избыточности можно отнести периодические копии данных хранящихся в базе данных. Эта избыточность легко контролируется. Более того, она является необходимой, например, для восстановления данных, разрушенных при случайных сбоях в работе ЭВМ. Таким образом, требование минимальной избыточности следует понимать как устранение вредной (неконтролируемой) и сведение к минимуму полезной (контролируемой) избыточности.

2) Целостность данных. Целостность данных состоит в поддержании правильности данных. Обеспечивается восстановлением данных после разрушения в результате случайных сбоев в работе ЭВМ, а также устранения противоречивости данных, которое заключается в появлении различных экземпляров для одних и тех же атрибутов. Противоречивость может появиться при обновлении избыточных данных в том случае, если обновление будет выполнено только на части данных.

3) Безопасность и секретность. Обеспечивает защиту данных от аппаратных и программных сбоев, от катастрофических и криминальных ситуаций, а также от некомпетентного доступа к ним.

4) Независимость данных. Обеспечивает возможность изменения структуры базы данных без изменения прикладных программ пользователей. Понимается в двух аспектах, а именно, как логическая и физическая независимость.

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

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

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

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

2.2 Нормальные формы

Реляционная база данных, спроектированная в соответствии с концептуальной схемой, может обладать рядом серьёзных недостатков, например, содержать информационную избыточность, и (или) в процессе обработки данных могут возникать различные аномалии. Чтобы устранить эти недостатки, т.е. сделать базу данных 'хорошей', необходимо привести все отношения базы данных в 'сильные' нормальные формы.

В настоящее время известно несколько нормальных форм. Первая нормальная форма (будем обозначать 1НФ), далее - по мере 'усиления' - 2НФ, 3НФ, нормальная форма Бойса-Кодда (НФБК) и 4 НФ. Практика показывает, что приведение БД хотя бы к 3НФ позволяет избежать в большинстве случаев почти всех недостатков.

Первая нормальная форма (1НФ).

Отношение со схемой R и множеством функциональных зависимостей F находится в 1НФ, если любой экземпляр схемы R удовлетворяет следующим условиям:

каждый атрибут схемы R имеет уникальное имя;

элементы кортежей с одним и тем же именем должны быть определены на одном и том же домене;

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

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

в отношении не должно быть повторяющихся кортежей.

Вторая нормальная форма (2 НФ).

Отношение со схемой R и множеством функциональных зависимостей F находится во 2НФ, если оно находится в 1НФ, и каждый неключевой атрибут функционально полно зависит от любого возможного первичного ключа схемы-отношения R.

Однако, схема отношения, находящаяся во 2 НФ, также имеет недостатки. В частности, множество зависимостей, определённое на этой схеме, может содержать транзитивные зависимости, которые могут приводить к нежелательным последствиям (аномалиям удаления).

Третья нормальная форма (3 НФ).

Схема отношений R с множеством функциональных зависимостей F находится в 3НФ, если оно находится во 2 НФ, и каждый неключевой атрибут прямо, а не транзитивно зависит от любого возможного ключа схемы отношения.

Однако, 3НФ также может иметь недостатки, связанные с ключевыми атрибутами. В приведённом примере полученная 3 НФ не вызывает аномалий при обработке данных, так ка в результирующих декомпозиционных подсхемах отсутствуют зависимости ключевых атрибутов от других атрибутов. Если это условие нарушается, то возможны аномалии обработки данных.

Нормальная форма Бойса-Кодда (НФБК).

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

Если отношение находится в НФБК, то оно находится и в третьей нормальной форме, но не наоборот.

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

2.3 Нормализация схем отношений

Для построения реляционной реализации концептуальной схемы БД, которая находилась хотя бы в 3 НФ, можно использовать два способа:

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

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

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

На практике чаще используется метод синтеза, поскольку метод декомпозиции обладает рядом серьёзных недостатков. Отметим основные из них.

Сложность алгоритма выше, чем полиномиальная.

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

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

2.4 Интеграция пользовательских представлений

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

Сущности

Директор

Управляющий

Инвестор

object (объект недвижимости)

X

X

X

investor (инвестор)

X

investing (инвестирвание)

X

X

employee (сотрудник)

X

X

material (материал)

X

delivery (поставка)

X

building (строительство)

X

X

Интегрированное представление пользователей, представленное в виде диаграммы

2.5 Алгоритм синтеза

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

Результатом работы алгоритма является схема автоматизированной системы управления в виде набора декомпозиционных подсхем {R1, R2,., Rp}, удовлетворяющих следующим условиям.

Каждая подсхема Ri с БД должна находится хотя бы в ЗНФ относительно множества функциональных зависимостей F и соответственно G.

Синтезируемая информационная система содержит минимальный набор декомпозиционных подсхем Ri, I == 1,., Р. Это условие защищает информационную систему от избыточности.

Для любого экземпляра r (БД), удовлетворяющего F, выполняется соотношение . Это условие гарантирует выполнимость свойства соединения без потерь информации.

Схема автоматизированной системы управления, удовлетворяющая условиям 1,2 и 3, называется полной схемой автоматизированной системы управления.

Рассмотрим шаги алгоритма.

Шаг 1. Строим расширенное множество F функциональных зависимостей, которое имеет следующую структуру зависимостей:

F = { (XI - > YI) | (XI - >YI) F, YI = XI + XI}. Этот шаг делается с целью построения неизбыточного или условно неизбыточного покрытия F, что позволит в некоторой степени удовлетворить условию 3. Полностью обеспечить условие 3 удастся после введения в рассмотрение понятия эквивалентности функциональных зависимостей на шаге 5.

Шаг 2. Строим неизбыточное покрытие F, исключая из F в любой последовательности лишние зависимости.

Очевидно, это покрытие не является каноническим.

Шаг 3. Если среди функциональных зависимостей из F' нет зависимости, включающей все атрибуты из U, то добавляем к F' тривиальную зависимость U-> Ш.

Шаг 4. Преобразуем полученные нетривиальные зависимости к элементарному виду (без лишних атрибутов в левых частях).

Зависимость XI - >YIявляется элементарной, если не существует таких наборов атрибутов XJ XI, что (Xj - >YI) . Если - существует, то зависимость XI - >YI заменяется зависимостью (XJ - >YI).

Шаг 5. Разбиваем множество полученных зависимостей на классы эквивалентности. Это делается для того, чтобы на следующем шаге оставить в каждом классе одного представителя, тем самым минимизировать количество декомпозиционных подсхем в результирующей БД и полностью удовлетворить условию 3.

Зависимости XI - >YI и XJ - >YJ будем называть эквивалентными, если

, т.е. минимальный ранг имеет зависимость, содержащая все атрибуты из U, а, если ее нет, то - тривиальная зависимость U - > Ш. Всем зависимостям из одного класса эквивалентности назначаем одинаковый ранг. Несравнимым зависимостям ранги назначаем произвольно.

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

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

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

Множество атрибутов:

U = {mNo, mName, mCost, count, oNo, oAddress, oType, oStoreys, oState, eNo, eName, ePost, eState, eSalary, sum, iNo, iName, iPhone}

Множество функциональных зависимостей:

F = {mNo®mName, mNo®mCost, mName®mNo, mName®mCost,

(oNo, mNo) ®count,

oNo®oAddress, oNo®oType, oNo®oStoreys, oNo®eNo, oNo®oState, oNo®oCost

eNo®eName, eNo®ePost, eNo®eState, eSalary

iNo®iName, iNo®iPhone,

(iNo, oNo) ®sum }

Шаг 1. Расширенное множество функциональных зависимостей:

mNo+=mNo, mName, mCost =>mNo® (mName, mCost)

mNo+=…=>mNo®…

(oNo, mNo) +=oNo, mNo, count=> (oNo, mNo) ?®count

oNo+=oNo, oAddress, oType, oStoreys, oState, oCost, eNo =>oNo® (oAddress, oType, oStoreys, eNo,oState, oCost)

oNo+=…=>oNo®…

eNo+=eNo, eName, ePost, eState, eSalary=>eNo® (eName, ePost, eState, eSalary)

eNo+=…=>eNo®…

iNo+=iNo, iName, iPhone=>iNo® (iName, iPhone)

iNo+=…=>iNo®…

(iNo, oNo) +=iNo, oNo, sum=> (iNo, oNo) ®sum

(mNo, oNo, iNo, eNo) +=mNo, mName, mCost, count, sum, oNo, oAddress, oType, oStoreys, iNo, iName, iPhone, eNo, eName, ePost, eState, eSalary, oState, oCost

=> (mNo, oNo, iNo, eNo) ® (mName, mCost, count, sum, oAddress, oType, oStoreys, oState, iName, iPhone, eName, ePost, eState, eSalary, oCost)

F = {mNo® (mName, mCost), mNo®…, (oNo, mNo) ?®count, oNo® (oAddress, oType, oStoreys, eNo, oState, oCost), oNo®…, eNo® (eName, ePost, eState, eSalary), eNo®…, iNo® (iName, iPhone), iNo®…, (iNo, oNo) ®sum, (mNo, oNo, iNo, eNo) ® (mName, mCost, count, sum, oAddress, oType, oStoreys, oState, iName, iPhone, eName, ePost, eState, eSalary) }

Шаг 2. Неизбыточное покрытие

F' = {mNo® (mName, mCost), (oNo, mNo) ?®count, oNo® (oAddress, oType, oStoreys, oState, oCost, eNo), eNo® (eName, ePost, eState, eSalary), iNo® (iName, iPhone), (iNo, oNo) ®sum, (mNo, oNo, iNo, eNo) ® (mName, mCost, count, sum, oAddress, oType, oStoreys, iName, iPhone, eName, ePost, eState, eSalary) }

Шаг 3. Тривиальная зависимость

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

Шаг 4. Элементарный вид зависимостей

Все зависимости элементарные.

Шаг 5. Эквивалентность зависимостей

Эквивалентных зависимостей нет.

Шаг 6. Ранжирование зависимостей

Разбиваем множество полученных зависимостей на классы эквивалентности. Это делается для того, чтобы на следующем шаге оставить в каждом классе одного представителя, тем самым минимизировать количество декомпозиционных подсхем в результирующей БД и полностью удовлетворить условию 3.

Зависимости XI YI и XJ YJ будем называть эквивалентными, если (XI YI) = (XJ YJ).

Ранжируем полученные зависимости по следующему правилу rang (XI YI) > rang (XJ YJ), если (XI YI) (XJ YJ).

Всем зависимостям из одного класса эквивалентности назначаем одинаковый ранг. Несравнимым зависимостям ранги назначаем произвольно.

X ® Y

X И Y

rang

mNo® (mName, mCost)

(oNo, mNo) ?®count

oNo® (oAddress, oType, oStoreys, eNo, oState, oCost)

eNo® (eName, ePost, eState, eSalary)

iNo® (iName, iPhone)

(iNo, oNo) ?®sum

(mNo, oNo, iNo, eNo) ?® (mName, mCost, count, sum, oAddress, oType, oStoreys, iName, iPhone, eName, ePost, eState, eSalary, oCost)

mNo,mName, mCost

oNo, mNo,count

oNo,oAddress, oType, oStoreys, eNo, oState, oCost

eNo,eName, ePost, eState, eSalary

iNo, iName, iPhone

iNo, oNo,sum

mNo, oNo, iNo, eNo, mName, mCost, count, sum, oAddress, oType, oStoreys, iName, iPhone, eName, ePost, eState, eSalary, oCost

5

4

2

3

6

7

1

Шаг 7. Диаграмма ранжированных зависимостей (2 НФ):

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

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

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

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

Шаг 8. Получаем совокупность декомпозиционных подсхем

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

R1 = oNo, oAddress, oType, oStoreys, oState, oCost, eNoс ключом oNo

R2 = eNo, eName, ePost, eState, eSalaryс ключомeNo

R3 = oNo, mNo,countс ключом (oNo, mNo)

R4 = mNo, mName, mCostс ключомmNo

R5 = iNo, iName, iPhoneс ключомiNo

R6 = iNo, oNo, sumс ключом (iNo, oNo)

Rational Rose Data Modeler средство проектирования БД

Авторы Data Modeler прежде всего ориентировались на создание инструмента проектирования физической модели данных. При этом не произошло отказа от UML как от средства моделирования данных, а некоторым образом были смещены акценты: теперь UML предполагается использовать для построения логической модели. По сути, логическая модель - это та же объектная модель, состоящая из объектов - сущностей. Переход от логической модели к физической и наоборот в части моделирования данных обеспечивается Rational Rose автоматически. Для этого введено соответствие элементов моделей.

Таблица 2.1 Соответствие элементов логической и физической модели

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

Физическая модель

Class (Класс)

Table (Таблица)

Operation (Операция)

Constraint (Ограничение)

Attribute (Атрибут)

Column (Колонка)

Package (Пакет)

Scheme (Схема)

Component (Компонент)

Database (База данных)

Association (Ассоциация)

Relationship (Связь)

Нет

Trigger (Тригер)

Нет

Index (Индекс)

Таким образом, концептуально модуль Data Modeler не является заменой UML в некотором его подмножестве, а всего лишь дает приверженцам объектных технологий мощное средство эффективного построения физических схем БД.

Перечень основных возможностей Data Modeler включает в себя:

1. Data Modeler поддерживает большинство возможностей структурных CASE-средств в плане физического моделирования данных;

2. Data Modeler обеспечивает генерацию эффективной физической структуры БД, поддерживающей механизмы обеспечения ссылочной целостности;

3. Data Modeler тесно интегрирован с Rational Rose, а диаграмма Data Model естественным образом вписывается в общую технологию разработки ПО с использованием линейки продуктов фирмы Rational Software Corporation;

4. Можно отказаться от интеграции Rational Rose с другими средствами генерации физических моделей.

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

Создание логической модели

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

Работа Data Modeler основана на известном механизме отображения объектной модели в реляционную. Результатом являются построение диаграммы 'сущность - связь' и последующая генерация описания базы данных на SQL.

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

Рис.2.1 Диаграмма классов

2.8 Создание схемы данных

Из к. з. меню на созданном пакете выполнить команду Data Modeler/Transform to Data Model.

В открывшемся окне в списке Target Database указать DB_0 и закрыть окно кнопкой ОК. В результате в логическом представлении в пакете Schemas появится пакет 'Schema' S_0, в который войдут две таблицы Устройство для чтения карточек и Счет.

Из к. з. меню на пакете 'Schema' S_0 выполнить команду Data Modeler/New/Data Model Diagram. В пакете 'Schema' S_0 появится новая диаграмма NewDiagram (диаграмма 'сущность - связь').

Нанести на нее все классы-таблицы, находящиеся в пакете 'Schema' S_0.

Рис.2.2 Диаграмма 'сущность-связь'

2.9 Выбор средств разработки

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

Для создания баз данных используется архитектура клиент-сервер.

В качестве базы данных используется MySQL 5.0.

В качестве сервера используется Apache2.

Для создания графического интерфейса используются PHP и HTML.

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

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

Выбор и обоснование WEB-сервера

В настоящий момент популярны два web - сервера: 'Web - сервер IIS' компании Microsoft и 'Web - сервер Apache'. Рассмотрим каждый из них.

'Web - сервер IIS' работает в составе операционной системы Windows, и, начиная с версии Windows 2000, поставляется вместе с ОС Windows. Функционал данного сервера вполне достаточен для написания информационной системы, но основной недостаток сервера заключается в том, что он достаточно дорогой. Использование дорогого программного обеспечения для реализации системы в свою очередь повышает себестоимость разрабатываемой информационной системы.

'Web - сервер Apache' работает под управлением как ОС Windows 2000 и старше, так и под ОС Unix. Данный web - сервер имеет множество удобных команд для управления им. Основное достоинство 'Web - сервера Apache' заключается в том, что он бесплатный. Поэтому не будет происходить дополнительного удорожания разрабатываемой информационной системы.

С учетом всего сказанного в представленной разработке в качестве web - сервера будет использоваться 'Web - сервер Apache' версии 2.0. В настоящее время есть и более старшие версии, но на данный момент наиболее стабильным 'Web - сервером Apache' считается версия 2.0.

Выбор и обоснование СУБД

Выбор СУБД будем осуществлять по следующему принципу. Все коды приложения и сама БД располагаются на web - сервере. Поэтому необходимо произвести сравнительный анализ тех СУБД, которые возможно установить на Web - сервер, и с которыми можно работать, используя язык программирования PHP. Из них надо выбрать наиболее подходящую.

СУБД, которые можно установить на web - сервер, это MYSQL, SQLite, Firebird, PostgreSQL. Выбранный для написания системы язык программирования PHP поддерживает работу только с СУБД MYSQL. Это является главной причиной того, что для разрабатываемой информационной системы будем использовать СУБД MYSQL.

В последние годы система управления базами данных MYSQL стала весьма популярной. Наибольшее распространение она получила среди программистов, работающих с Linux и другими продуктами с открытым кодом, но и в коммерческом секторе присутствие MYSQL все более заметно. Причин этому несколько. Прежде всего, MYSQL является быстрой, простой в настройке, использовании и администрировании СУБД. Сама СУБД MYSQL работает во множестве версий UNIX и Windows, а программы, работающие с MYSQL, могут быть написаны на множестве языков. MYSQL особенно интенсивно используется совместно с web - сервером для создания web - сайтов на основе баз данных с динамически формируемым содержимым.

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

Выбор и обоснование языка программирования

Рассмотрим несколько языков программирования, ориентированных на создание Internet приложений. Популярными языками для написания web - приложений являются языки Perl и PHP. Оба этих языка являются Web - ориентированными, но при этом следует учесть, что язык Perl в большей степени ориентирован на задачи по обработке текстов. В его состав входят множество функций для работы с текстом, а также мощные инструменты для составления регулярных выражений.

Язык PHP изначально разрабатывался как язык программирования web - приложений. Основные достоинства языка PHP заключаются в том, что:

код, написанный на языке PHP, выполняется на сервере, и клиенту выдаются только результаты работы функций написанных на PHP;

язык PHP имеет функции для реализации многопользовательской работы клиентов;

существует возможность быстрого взаимодействия с СУБД MYSQL;

язык PHP имеет функции для работы с электронной почтой;

язык PHP генерирует конечные html страницы, которые отправляются в браузер клиента.

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

3. Разработка информационной системы

3.1 Пользовательский режим работы

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

Рис.3.1 Главная страница

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

Рис.3.2 Регистрация инвестора

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

Рис.3.3 Авторизация пользователя в системе

3.2 Режим работы инвестором

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

Рис.3.4 Объекты инвестирования

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

Рис.3.5 Изменение суммы инвестиций

3.3 Режим работы управляющего

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

Рис.3.6 Главная форма управляющего

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

Рис.3.7 Форма управления поставками

3.4 Режим работы директором

Директор обладает наибольшим количеством полномочий в системе. Ему доступна на чтение и редактирование вся информация по объектам, строителям и управляющим. Также он может получить сводную информацию о работе компании с помощью нескольких динамических отчетов.

Рис.3.8 Список строителей

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

Рис.3.9 Форма изменения объекта

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

Рис.3.10. Отчет по инвесторам

Отчет по объект отражает темпы строительства и динамику цен с течением времени.

Рис.3.11. Отчет по объектам

4. Безопасность и санитарно-гигиенические условия труда на рабочем месте пользователя ПЭВМ

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

Санитарные требования по обеспечению нормальных условий труда для операторов персональных компьютеров (ПК) включают требования к персональным электронно-вычислительным машинам (защита от электромагнитных, электростатических полей, эргономические параметры видеодисплэйных терминалов - ВДТ), требования к микроклимату помещений, освещенности, шуму и вибрации. Безопасность и санитарно-гигиенические условия труда на рабочем месте пользователя ПЭВМ определяются требованиями СанПиН 2.2.2/2.4.1340-03 и будут подробнее рассмотрены в следующих пунктах данного раздела.

4.1 Характеристика санитарно-гигиенических условий труда

Таблица 4.1.1 Характеристики помещения

Параметр

Значение

длина

10 м

ширина

7 м

высота

3.5 м

площадь

70 мІ

объем

245 мі

количество работников

7 чел.

объем для каждого работника

35 мі

Микроклимат.

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

Согласно требованиям СанПиН 2.2.2/2.4.1340-03 'Гигиенические требования к видео дисплейным терминалам (ВДТ), персональным электронно-вычислительным машинам и организации работы', нормирование параметров микроклимата в рабочей зоне производится в зависимости от периода года, категории работ по энергозатратам, наличия в помещении источников явного тепла.

Согласно установленным нормам, по энергозатратам вычислительная работа, которая будет проводиться в данном помещении, относится к категории 'легкая физическая' (таблица 4.1.2).

Таблица 4.1.2 Легкая физическая работа

Категория

Энергозатраты

организма

Характеристика работы

1а

До 120 ккал/ч

(до 500,5 кДж/ч)

Проводится сидя и сопровождается незначительным физическим напряжением.

В таблице 4.1.3 приведены оптимальные нормы температуры, относительной влажности и скорости движения воздуха в помещениях для работы с персональным компьютером (ПК) в соответствии СанПиН 2.2.2/2.4.1340-03.

Таблица 4.1.3 Оптимальные нормы для помещений с ВТ и ПК

Период года

Температура, 0С оптимальная

Относительная влажность, % оптимальная, не более

Скорость движения воздуха, м/с оптим., не более доп.

Холодный

22-24

40-60

0,1

Теплый

23-25

40-60

0.1

Для повышения влажности воздуха в помещениях с ВДТ и ПЭВМ следует применять увлажнители воздуха, заправляемые ежедневно дистиллированной или прокипяченной питьевой водой.

Вредные вещества и пыль

Содержание вредных химических веществ в производственных помещениях, работа на ВДТ и ПЭВМ в которых является основной (диспетчерские, операторские, расчетные, кабины и посты управления, залы вычислительной техники и др.), не должно превышать 'Предельно допустимых концентраций загрязняющих веществ в атмосферном воздухе населенных мест' (СанПиН 2.2.2/2.4.1340-03).

Уровень ионизации воздуха

Уровни положительных и отрицательных аэроионов в воздухе помещений с ВДТ и ПЭВМ должны соответствовать нормам, приведенным в таблице 4.1.4 (согласно СанПиН 2.2.2/2.4.1340-03).

Таблица 4.1.4 Уровни ионизации воздуха помещений при работе на ПЭВМ

Уровни аэроионов

Число ионов в 1 см3 воздуха

n+

n-

Минимально необходимые

400

600

Оптимальные

1500-3000

3000-5000

Максимально допустимые

50000

50000

4.2 Вентиляция

Чтобы нормализовать воздушную среду, в производственном помещении должен осуществляться воздухообмен (вентиляция).

По способу перемещения воздуха вентиляция разделяется на:

естественную - осуществляется за счет разности температур воздуха помещения и наружного воздуха или действия ветра;

механическую - спроектированную систему для подачи воздуха.

В помещении, объемом 245 мі, 7 рабочих места. Следовательно, на каждого работающего приходиться 35м3 объема воздуха.

Согласно санитарным нормам проектирования промышленных предприятий СН-245-71 в производственных помещениях с объемом на одного работающего:

менее 20м3 осуществляется подача наружного воздуха в количестве не менее 30м3/ч на каждого работающего;

более 20м3 - не менее 20м3/ч;

более 40м3 и при наличии окон достаточно естественной вентиляции.

Объем воздуха на каждого рабочего в этом помещении составляет 35м3, следовательно, каждому необходимо обеспечить дополнительную подачу наружного воздуха в объеме не менее 20 м3/ч, т.е. для 7 человек необходимо осуществить подачу воздуха на все помещение, не менее 140 м3/ч.

Требования к уровню вибрации

В производственных помещениях, в которых работа с ВДТ и ПЭВМ является основной, вибрация на рабочих местах не должна превышать допустимых норм вибрации.

В таблице 6.1.5 приведены допустимые нормы вибрации на всех рабочих местах с ВДТ и ПЭВМ согласно СанПиН 2.2.2/2.4.1340-03.

Таблица 4.1.5 Допустимые нормы вибрации на всех рабочих местах с ПЭВМ

Среднегеометрические частоты октавных полос, Гц

Допустимые значения

по виброускорению

по виброскорости

м/с2

дБ

м/с

дБ

2

5,3х10

25

4,5х10

79

4

5,3х10

25

2,2х10

67

8

5,3х10

25

2,2х10

67

16

1,0х10

31

1,1х10

67

31,5

2,1х10

37

1,1х10

67

63

4,2х10

43

1,1х10

67

Корректированные значения и их уровни в дБ

9,3х10

30

2,0х10

72

Требования к уровню шума

Шум на уровне 50-60 дБА создает значительную нагрузку на нервную систему человека, оказывая на него психологическое воздействие. Это особенно часто наблюдается у людей, занятых умственной деятельностью. Степень вредности и неприятное воздействие какого-либо шума зависит также от того, насколько он отличается от привычного шума и от индивидуального отношения к нему. Предельно допустимые уровни шума в отдельных октавных полосах на рабочих местах в офисном помещении, установленные в соответствии с требованиями СанПиН 2.2.2/2.4.1340-03 'Гигиенические требования к видео дисплейным терминалам, персональным электронно-вычислительным машинам и организации работы'.

При выполнении основной работы на ПК (соответствует рассматриваемому случаю), во всех помещениях с ПК уровень шума на рабочем месте не должен превышать 50 дБА (согласно СанПиН 2.2.2/2.4.1340-03).

Таблица 4.1.6. Предельно допустимые уровни шума

Рабочие места

Среднегеометрические частоты октавных полос, Гц

Эквивалентные

уровни

звука, дБ А

31,5

63

125

250

500

1000

2000

4000

8000

Уровни звукового давления, дБ

- рабочие места в помещениях программистов ЭВМ

86

71

61

54

49

45

42

40

39

50

Шумящее оборудование (принтеры и т.п.), уровни шума которого превышают нормированные, должно находиться вне помещения с ПК.

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

Дополнительным звукопоглощением служат однотонные занавеси из плотной ткани, гармонирующие с окраской стен и подвешенные в складку на расстоянии 15-20 см от ограждения. Ширина занавеси должна быть в 2 раза больше ширины окна.

Излучения.

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

ПК при работе излучают электромагнитную энергию радиочастот, значит, работники подвержены воздействию электромагнитных полей с ВЧ и УВЧ излучением. Интенсивность ЭМП ВЧ и УВЧ согласно ГОСТ 12.1.006. - 88 'ССБТ Электромагнитные поля радиочастот' на рабочих местах оценивается напряженностью E (В/м) для электрической составляющей и напряженностью Н (А/м) для магнитной составляющей. В целях обеспечения требований, а также защиты от электромагнитных и электростатических полей, допускается применение при экранных фильтров, специальных экранов и других средств индивидуальной защиты, прошедших испытания в аккредитованных лабораториях и имеющих гигиенический сертификат.

Степень воздействия ЭМИ на организм человека зависит от:

частоты колебаний;

значения напряженности электрических и магнитных полей;

размеров облучаемой поверхности тела.

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

Таблица 4.1.7 Допустимые значения параметров неионизирующих электромагнитных излучений

Наименование параметров

Допустимое значение

Напряженность электромагнитного поля на расстоянии 50 см вокруг ВДТ по электрической составляющей должна быть не более:

в диапазоне частот 5 Гц - 2 кГц;

в диапазоне частот 2 - 400 кГц

25 В/м

2,5 В/м

Плотность магнитного потока должна быть не более:

в диапазоне частот 5 Гц - 2 кГц;

в диапазоне частот 2 - 400 кГц.

250 нТл

25 нТл

Поверхностный электростатический потенциал не должен превышать

500 В

Допускаются уровни выше указанных, но не более чем в 2 раза, в случаях, когда время воздействия на персонал не превышает 50 % от продолжительности рабочего дня.

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

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

В случае превышения допустимых значений параметров ЭМИ, следует воспользоваться некоторыми способами защиты от ЭМИ:

Уменьшение мощности источника - уменьшение параметров излучения в самом источнике;

Экранирование источника излучения (рабочего места);

Выделение зоны излучения;

Удаление рабочего места от источника излучения;

Защита временем (от тока промышленной частоты).

При выборе средств защиты следует отдавать предпочтение экранированию источника излучения (согласно СанПиН 2.2.2/2.4.1340-03).

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

Конструкция ВДТ и ПЭВМ должна обеспечивать мощность экспозиционной дозы рентгеновского излучения в любой точке на расстоянии 0,05 м от экрана и корпуса ВДТ при любых положениях регулировочных устройств не должна превышать 7,74х10 А/кг, что соответствует эквивалентной дозе, равной 1,0 мкЗв/час.

Нормы на освещение рабочего места

Помещения с ПК должны иметь естественное и искусственное освещение.

Естественное освещение должно осуществляться через светопроемы, ориентированные преимущественно на север и северо-восток и обеспечивать коэффициент естественной освещенности (КЕО) не ниже 1,2 % в зонах с устойчивым снежным покровом и не ниже 1,5 % на остальной территории. Для внутренней отделки интерьера помещений с ЭВМ должны использоваться диффузно-отражающие материалы с коэффициентом отражения для потолка сП - 0,7 - 0,8; для стен сС - 0,5 - 0,6; для рабочей поверхности сР - 0,3 - 0,5. и

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

Освещенность на поверхности стола в зоне размещения рабочего документа должна быть 300-500 лк.

Допускается установка светильников местного освещения для подсветки документов. Местное освещение не должно создавать бликов на поверхности экрана и увеличивать освещенность экрана не более 300 лк.

Следует ограничивать прямую блескость от источников освещения, при этом яркость освещения поверхностей (окна, светильников и др.), находящихся в поле зрения, должна быть не более 200 кд/мІ.

Следует ограничивать отраженную блескость на рабочих поверхностях (экран, стол, клавиатура и др.) за счет правильного выбора типов светильников и расположения рабочих мест по отношению к источникам естественного и искусственного освещения, при этом яркость бликов на экране ПК не должна превышать 40 кд/мІ и яркость потолка, при применении системы отраженного освещения, не должна превышать 200 кд/мІ.

Следует ограничивать неравномерность распределения яркости в поле зрения пользователя ПК, при этом соотношение яркости между рабочими поверхностями не должно превышать 3: 1 - 5: 1, а между рабочими поверхностями и поверхностями стен и оборудования 10: 1.

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

Для освещения помещений с ПК следует применять светильники серии ЛПО36 с зеркальными решетками, укомплектованные высокочастотными пускорегулирующими аппаратами (ВЧ ПРА). Допускается применять светильники серии ЛПО36 без ВЧ ПРА только в модификации 'Кососвет', а также светильники прямого света П, преимущественно прямого света - Н, преимущественно отраженного света В. применение светильников без рассеивателей и экранирующих решеток не допускается.

Яркость светильников общего освещения в зоне углов излучения от 50 до 90 градусов с вертикалью в продольной и поперечной плоскостях должна составлять не более 200 кдж/мІ, защитный угол светильников должен быть не менее 40 градусов.

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

Коэффициент запаса (Кз) для осветительных установок общего освещения должен приниматься равным 1,4.

Коэффициент пульсации не должен превышать 5%, что должно обеспечиваться применением газоразрядных ламп в светильниках общего и местного освещения с высокочастотными пускорегулирующими аппаратами (ВЧ ПРА) для любых типов светильников.

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

Для обеспечения нормируемых значений освещенности в помещениях использования ВДТ и ПЭВМ следует проводить чистку стекол оконных рам и светильников не реже 2-х раз в год и проводить своевременную замену перегоревших ламп.

4.3 Расчет осветительной установки

Работа с ПК относится к работе IV-а разряда (средней точности, наименьший размер объекта различия от 0,5 до 1мм). В данном помещении - высота потолков 3,5м. Целесообразно применять люминесцентные лампы, так как существуют повышенные требования к цветопередаче и качеству освещения.

В соответствии с нормами освещенности рабочих поверхностей в производственных помещениях (по СНиП 23-05-95), требуемая освещенность для системы одного общего освещения при использовании люминесцентных ламп для проведения работ IV-а разряда составляет 300 лк.

Рассматриваемое помещение относится к помещениям с нормальными условиями среды, для освещения можно использовать светильник типа ЛСП02 (2*80Вт) (прямого света, исполнение пыле - и водо - незащищенное, тип кривой силы света (КСС) - Д).

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

h = Н - hc - hp,

где:

Н - высота помещения, м; hc - расстояние от потолка до светильника, м; hp - высота рабочей поверхности, равная 0,8 м.

h = 3.5 - 0,168 - 0,8 = 2,532 (м)

Расстояние между рядами светильников

, м.

Расстояние между светильниками и стеной

, м.

Расстояние между светильниками

, м

Индекс помещения вычисляется по формуле:

,

где:

L - длина помещения, м;

В - ширина помещения, м;

h - расчетная высота подвеса светильника, м.

С учетом зависимости коэффициента использования светового потока от индекса помещения и характеристики помещения, определяем коэффициент использования светового потока. Он получен для указанных значений типа кривой силы света (Д - косинусная группа) и коэффициентов отражения потолка, стен и пола, равных, соответственно, 0,7; 0,5; 0,1 (помещение относится к чистым). В данном случае индекс помещения равен 1,626, следовательно, коэффициент использования светового потока hи = 0,64.

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

Число светильников в осветительной установке определяется по формуле:

, где:

Ен - нормированная освещенность рабочей поверхности, лк;

S - площадь помещения, м2;

Kз - коэффициент запаса;

Z - коэффициент неравномерности освещения;

n - количество ламп в одном светильнике;

hи - коэффициент использования светового потока в долях единицы;

Ф - световой поток одной лампы, лм.

Коэффициент запаса Kз учитывает возможность уменьшения освещенности в процессе эксплуатации осветительной установки и принимается в данном случае равным 1,4. Коэффициент неравномерности Z для люминесцентных ламп равен 1,1. Световой поток Ф для ЛБ ламп равен 5220 лм и находится из таблиц ГОСТ 6825-74, в зависимости от типа и мощности используемых в светильнике ламп.

Число светильников в осветительной установке:

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

?L ? 0,55*h

В данном случае ?L должно быть не более 1,39м.

Длина светильника L = 1,534м, ширина светильника d = 0,276м.

Примечание. Из конструктивных соображений допускается изменять количество светильников в осветительной установке. При этом фактическое число светильников не должно отличаться от расчетного N не менее - 10% и более +20%.

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

Предлагаемая схема организации освещения в помещении приведена на рисунке

Рис. 6.3.1. Схема размещения светильников

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

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

рабочие места с ВДТ и ПЭВМ по отношению к световым проемам должны располагаться так, чтобы естественный свет падал сбоку, преимущественно слева,

оконные проемы в помещениях использования ВДТ и ПЭВМ должны быть оборудованы регулируемыми устройствами типа: жалюзи, занавесей, внешних козырьков и др.

4.4 Режим труда

Общие требования к организации режима труда и отдыха при работе с ВДТ и ПЭВМ по СанПиН 2.2.2/2.4.1340-03:

1. Режимы труда и отдыха при работе с ПЭВМ и ВДТ должны организовываться в зависимости от вида и категории трудовой деятельности.

2. Виды трудовой деятельности разделяются на 3 группы:

группа А - работа по считыванию информации с экрана ВДТ или ПЭВМ с предварительным запросом;

группа Б - работа по вводу информации;

группа В - творческая работа в режиме диалога с ЭВМ.

При выполнении в течение рабочей смены работ, относящихся к разным видам трудовой деятельности, за основную работу с ПЭВМ и ВДТ следует принимать такую, которая занимает не менее 50% времени в течение рабочей смены или рабочего дня.

3. Для видов трудовой деятельности устанавливается 3 категории тяжести и напряженности работы с ВДТ и ПЭВМ, которые определяются:

· для группы А - по суммарному числу считываемых знаков за рабочую смену, но не более 60 000 знаков за смену;

· для группы Б - по суммарному числу считываемых или вводимых знаков за рабочую смену, но не более 40 000 знаков за смену;

· для группы В - по суммарному времени непосредственной работы с ВДТ и ПЭВМ за рабочую смену, но не более 6 часов за смену.

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

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

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

7. Продолжительность непрерывной работы с ВДТ без регламентированного перерыва не должна превышать 2 часов.

8. При работе с ВДТ и ПЭВМ в ночную смену (с 22 до 6 часов), независимо от категории и вида трудовой деятельности, продолжительность регламентированных перерывов должна увеличиваться на 60 минут.

9. При 8-ми часовой рабочей смене и работе на ВДТ и ПЭВМ регламентированные перерывы следует устанавливать:

· для I категории работ через 2 часа от начала рабочей смены и через 2 часа после обеденного перерыва продолжительностью 15 минут каждый;

· для II категории работ через 2 часа от начала рабочей смены и через 1.5-2.0 часа после обеденного перерыва продолжительностью 15 минут каждый или продолжительностью 10 минут через каждый час работы;

· для III категории работ через 1.5-2.0 часа от начала рабочей смены и через 1.5-2 часа после обеденного перерыва продолжительностью 20 минут каждый или продолжительностью 15 минут через каждый час работы.

10. При 12-ти часовой рабочей смене регламентированные перерывы должны устанавливаться в первые 8 часов работы, аналогично перерывам при 8-ми часовой рабочей смене, а в течение последних 4 часов работы, независимо от категории и вида работ, каждый час продолжительностью 15 минут.

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

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

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

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

4.5 Требования по организации рабочего места

Общие требования по СанПиН 2.2.2/2.4.1340-03 при работе с ВДТ и ПЭВМ:

Рабочие места с ВДТ и ПЭВМ по отношению к световым проемам должны располагаться так, чтобы естественный свет падал сбоку, преимущественно слева.

Схемы размещения рабочих мест с ВДТ и ПЭВМ должны учитывать расстояния между рабочими ами с видеомониторами (в направлении тыла поверхности одного видеомонитора и экрана другого видеомонитора), которое должно быть не менее 2,0 м, а расстояние между боковыми поверхностями видеомониторов - не менее 1,2 м.

Рабочие места с ВДТ и ПЭВМ в залах электронно-вычислительных машин или в помещениях с источниками вредных производственных факторов должны размещаться в изолированных кабинах с организованным воздухообменом.

Оконные проемы в помещениях использования ВДТ и ПЭВМ должны быть оборудованы регулируемыми устройствами типа: жалюзи, занавесей, внешних козырьков и др.

Рабочие места с ВДТ и ПЭВМ при выполнении творческой работы, требующей значительного умственного напряжения или высокой концентрации внимания, следует изолировать друг от друга перегородками высотой 1,5-2,0 м.

Шкафы, сейфы, стеллажи для хранения дисков, дискет, комплектующих деталей, запасных блоков ВДТ и ПЭВМ, инструментов, следует располагать в подсобных помещениях. При отсутствии подсобных помещений допускается размещение шкафов, сейфов и стеллажей в помещениях непосредственного использования ВДТ и ПЭВМ при созаказении требований к площади помещений и требований, изложенных в настоящем разделе.

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

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

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

Экран видеомонитора должен находиться от глаз пользователя на оптимальном расстоянии 600-700 мм, но не ближе 500 мм с учетом размеров алфавитно-цифровых знаков и символов.

В помещениях с ВДТ и ПЭВМ ежедневно должна проводиться влажная уборка.

Помещения с ВДТ и ПЭВМ должны быть оснащены аптечкой первой помощи и углекислотными огнетушителями.

4.6 Электрическая безопасность

Характеристика электрооборудования

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

Электрооборудование насчитывает 7 ПК (350 ВтЧ7) и 6 светильников.

Применяемая электросеть является однофазной, с напряжением 220 В, ток переменный с частотой 50 Гц, с заземленной нейтралью.

Напряжения прикосновения и токи, протекающие через человека, нормируются согласно ГОСТ 12.1.038-88 'ССБТ. Электробезопасность. Предельно допустимые значения напряжений и токов'.

В таблице 4.5.1 приведены допустимые значения напряжений прикосновения и токов при аварийном режиме работы техники, где резистором моделируется сопротивление тела человека R = 850 (Ом). Найдем силу тока в аварийном режиме:

Таблица 4.5.1 Допустимые значения напряжений прикосновения и токов при аварийном режиме работы

Род и

частота тока

Норм.

велич.

Продолжительность воздействия, t, с

0,01-0,08

0,1

0,2

0,4

0,5

0,8

1

>1

Переменный

50 Гц

Uпр, В

Iч, мА

550

650

340

400

160

190

120

140

105125

75

75

60

50

20

6

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

Оценка необходимости применения защитных устройств

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

Защитное заземление - преднамеренное электрическое соединение металлических нетоковедущих частей электрооборудования с землей или ее эквивалентом.

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

Следует иметь в виду, что в соответствии с 'Правилами устройства электроустановок потребителей (ПУЭ)' защитное заземление или зануление электроустановок следует выполнять при напряжении питания 380 В и выше переменного тока и 440 В и выше постоянного тока во всех случаях. При напряжении питания выше 42, но ниже 380 В переменного тока, и выше 110, но ниже 440 В постоянного тока, защитное заземление (зануление) электроустановок выполняется только в помещениях с повышенной опасностью и особо опасных по поражению электрическим током, а также в наружных электроустановках.

Напряжение питания в рабочем помещении не превышает 380В, необходимость в занулении электроустановок отсутствует.

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

Таблица 4.5.2

Климатические условия

Сопротивление изоляции, МОм, при рабочем напряжении цепи кВ

Нормальные

0,1-0,5

20,0

Сопротивление изоляции силовой и осветительной сети напряжением до 1000В на участке между двумя смежными предохранителями или любым проводом и землей должно быть не менее 0.5 МОм.

Пожарная безопасность

Основы противопожарной защиты предприятий определены стандартами ГОСТ 12.1.004-91 'Пожарная безопасность' и ГОСТ 12.1.010-76 'Взрывобезопасность. Общие требования'.

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

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

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

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

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

Таблица 4.5.3 Размещение пожарных извещателей в зависимости от высоты установки

Высота установки

извещателя, м

Максимальная

площадь, контролируемая одним извещателем, м2

Максимальное расстояние, м

между извещателями

от извещателя до стены

Тепловые пожарные извещатели

До 3,5

Более 3,5 до 6

25

20

5

4,5

2,5

2

Дымовые пожарные извещатели

До 3,5

Более 3,5 до 6

85

70

9

8.5

4.5

4

Следовательно, рабочее помещение площадью 70 м2 надо оборудовать 1 дымовым пожарным извещателем или 3 тепловыми пожарными извещателями.

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

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

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

Таблица 4.5.4 Перечень необходимых средств пожаротушения

Наименование помещений, сооружений и установок

Защищаемая площадь, мІ

Углекислотные огнетушители

Пенные, химические, воздушно-пенные и жидкостные огнетушители, шт.

Ящик с песком вместимостью 0,5; 1,0; 3,0 и лопата, шт.

Войлок, кошма или асбест: /1х1,2х1,2х2 м/, шт.

Бочка с водой вместимостью не менее 0,2 м и ведро, шт.

Вычислительные центры, машиносчетные станции, архивы, библиотеки, проектно - конструкторские бюро.

70

2

2

-

2

-

Для защиты помещения при пожаре объемом менее 200м2 с компьютерной техникой необходимо иметь: углекислотные огнетушители ОУ-2, ОУ-5, ОУ-8 (допускается заменять аэрозольными или порошковыми) - 1шт., пенные огнетушители - 1шт., войлок 2х2 м - 1шт.

Выводы

При оценке условий труда, были рассмотрены безопасность и санитарно-гигиенические условия труда на рабочем месте пользователя ПЭВМ:

дана характеристика санитарно-гигиенических условий труда (микроклимата, вредных веществ и пыли, вибраций, шума, излучений и освещенности);

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

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

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

указаны возможные причины и источники возникновения пожара, установлен перечень первичных средств пожаротушения, а также были разработаны инженерно-технические мероприятия по созданию благоприятных условий труда, используя СанПиН 2.2.2/2.4.1340-03.

5. Расчет экономической эффективности проекта

5.1 План маркетинга

Описание характеристик товара/услуги

Сущность информационного товара

Предоставление доступа к программному комплексу и последующая обработка данных.

Описание товара и его применения

Программная часть проекта: база данных реализована на MySQL, интерфейс - на языке программирования PHP.

Отличительные особенности товара

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

Потенциальные возможности в будущем

Расширение возможностей системы с выполнением иных задач. Внедрение программного комплекса на любых предприятиях, либо интегрирование её в качестве составной части (подсистемы) в сайт предприятия.

5.2 Цели, задачи и методы оценки инвестиций

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

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

Для определения указанного показателя предварительно необходимо обратить внимание на основные особенности предполагаемой инвестиционной деятельности, к которым относятся:

возможное получение реальной отдачи (дохода) от вложения инвестиций по истечении ряда лет вложения;

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

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

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

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

Дисконтирование по сложной ставке процента связано с определением дисконтного множителя Vt за каждый год из n-лет вложения по следующей формуле 1.2.1.

Формула 1.2.1

где i - ставка сложных процентов, t = 1,2,., n.

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

Формула 1.2.2

где n1, - продолжительность осуществления инвестиций;

п2 - продолжительность периода отдачи;

Кl - ежегодные инвестиции в периоде l, l =1,2,., п1;

pj - ежегодные инвестиции в периоде j, j = 1, 2,., п2.

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

Формула 1.2.3

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

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

5.3 Выбор и описание разрабатываемого и альтернативного вариантов

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

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

разработка;

производство;

эксплуатация.

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

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

разработка и отладка программного обеспечения;

эксплуатация.

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

В качестве альтернативного варианта рассмотрим проект написания данного программного продукта с помощью технологии ASP.net и языка программирования C#, а также база данных, реализованной на SQL Server 2005.

Исходные данные для расчётов приведены в таблице 5.3.1.

Таблица 5.3.1

Назначение показателей

Условные обозначения

Значения по вариантам

Основной

Альтернативный

Общая продолжительность этапа разработки и отладки, мес.

T

4

4

Общая численность исполнителей в период разработки, чел.

U

2

2

Среднемесячная заработная плата всех исполнителей, р. /мес.

З

40000

70000

Общая продолжительность этапа эксплуатации, лет

Тэ

2

2

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

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

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

Для разрабатываемого в данной дипломной работе программного продукта:

общая продолжительность разработки 4 месяца;

общая продолжительность эксплуатации 2 года.

В итоге, общий период составляет 2 года 4 месяца

На рисунке 1.2.1 представлено графическое изображение последовательности вложений инвестиций по годам расчётного периода:

Рис.1.2.1

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

Учитывая это и используя данные из справочных источников, находим дисконтный множитель. Дисконтный множитель при i = 10% по годам вложений представлен в таблице 5.3.2.

Таблица 5.3.2

Год вложения

1

2

Дисконтный множитель

0.9091

0.8264

5.4 Расчёт вложений на этапе разработки и отладки основного варианта

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

Календарный график выполнения работ представлен в таблице 5.3.3.

Таблица 5.3.3

Наименование этапа

Сроки начала

Сроки окончания

Всего, мес.

1. Определение требований к системе

01.10.08

07.10.08

1/2

2. Определение структуры системы

08.10.08

14.10.08

1/2

3. Написание программного комплекса

15.10.08

14.12.08

2

4. Отладка

15.12.08

21.12.08

1/2

5. Подготовка документации

22.12.08

28.12.08

1/2

Расчёт основной и дополнительной заработной платы на этапе разработки приведен в таблице 1.2.4.

Таблица 5.3.4

Категория персонала

Кол-во чел

Основная зарплата,

тыс. руб.

Доп. Зарплата (14% от ОснЗп)

тыс. руб.

Время занятий мес.

Сумма, тыс. руб.

Старший программист

1

25

3,5

4

114

Программист

1

15

2,8

4

71,2

Для учёта затрат на этапе написания программного комплекса и его отладки необходимо определить себестоимость машино-часа работы ЭВМ. Необходимые формулы приведены в таблице 5.3.5.

Таблица 5.3.5

Формулы для расчёта

Условные обозначения

С = Зо+ Зд + Зсс + Зм + Зээ + За + Зпр

Зо - основная з/п персонала, руб. /час

Зд - доп. з/п персонала, руб. /час

Зсс - отчисления на гос. страх., руб. /час

Зм - затраты на материалы, руб. /час

Зээ - затраты на потр. энергию, руб. /час

За - амортизация выч. средств, руб. /час

Зпр - прочие производ. расходы, руб. /час

Зо = Зосн / (m * 8)

Зосн - основная з/п программиста, руб. /час (см. таб.4)

m - ср. кол-во рабочих дней в месяце m=21

Зд = (Нд /100) * Зо

Нд - процент доп. з/п персонала (14%)

Зсс = (Нсс / 100) * (Зо + Зд)

Нсс - процент отчисления на соц. обеспечение (26%)

Зээ = qj * Nj * S

qj - число j-х технических средств ЭВМ

Nj - потр. мощность j-х технических средств, кВт

S - стоимость кВт/ч электроэнергии (1,85 руб.)

За=а* Sэвм / (100*8*m*12)

a - годовая норма амортизации ЭВМ (20%)

Sэвм - балансовая стоимость ЭВМ (25000 руб.)

Зпр = (Нпр / 100) * (Зо + Зээ + За)

Нпр - процент прочих произв. расходов (50%)

Основная заработная плата: Зо =40000 / (21* 8) = 238 руб. /час. Дополнительная заработная плата: Зд = (14/100) * 238 = 33,3 руб. / час. Отчисления на соцобеспечение: Зсс = (26/100) * (238 + 33,3) = 70,4 руб. / час. Затраты на электроэнергию: Зээ = 2 * 0,3 * 1,85 = 1,1 руб. /час. Амортизация: За = 20 * 25000 * 2/ (100 * 8 * 21 * 12) = 4,9 руб. /час. Прочие производственные расходы: Зпр = 50 / 100 * (238 + 1,1 + 4,9) = 122 руб. /час.

К прочим производственным расходам можно отнести затраты на материалы, лицензионное программное обеспечение и т.д.

Таким образом, себестоимость машино-часа работы ЭВМ составит: С = 238 + 33,3 + 70,4 + 1,1 + 4,9 + 122 = 469,7 руб. /час. Однако, при расчёте себестоимости машино-часа учитывались затраты лишь на ЭВМ, занятой для решения данного вопроса. Кроме этого, необходимо ещё учитывать затраты на ремонт оборудования. Затраты на ремонт составляют 10% от стоимости оборудования, т.е.:

Зр = 10 * Sэвм * 2/ (8 * m * 12 * 100);

Зр = 10 * 30000 * 2/ (8 * 21 * 12 * 100) = 3 руб. /час;

Таким образом, себестоимость машино-часа работы: С = 469,7 + 3 = 472,7 руб. /час. Зная себестоимость машино-часа работы ЭВМ, можно определить затраты на написание программного комплекса и его отладку по формуле:

Знп-о = С * t,

где t = 504 - время написания программного комплекса и его отладки и использование вычислительной машины для подготовки технической документации, час (63 рабочих дня). Получим: Знп-о = 472,7 * 504 = 238,2 тыс. руб. В целом показатели на этапе разработки характеризуются величиной стоимости работы и дисконтным множителем. Величина дисконтного множителя равна 1 (т.к. t = 3 мес. не дисконтируется).

Таким образом, величина затрат на разработку составляет 238,2 тыс. руб.

5.5 Расчёт вложений на этапе разработки и отладки альтернативного варианта

Исходная информация по календарному графику выполнения работ и расчёт отдельных статей калькуляции сведены в таблице 5.3.6.

Таблица 5.3.6

Наименование этапа

Сроки начала

Сроки окончания

Всего, мес.

1. Определение требований к системе

01.10.08

07.10.08

1/4

2. Определение структуры системы

08.10.08

14.10.08

1/4

3. Написание программного комплекса

15.10.08

14.12.08

2

4. Отладка

15.12.08

21.12.08

1/4

5. Подготовка документации

22.12.08

28.12.08

1/4

Расчёт основной и дополнительной заработной платы на этапе разработки приведен в таблице 5.3.7.

Таблица 5.3.7

Категория персонала

Кол-во человек

Основная зарплата

тыс. руб.

Доп. Зарплата (14% от ОснЗп)

тыс. руб.

Время занятий, мес.

Сумма, тыс. руб.

Разработчик

1

35,0

4,9

3

119,7

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

1

25,0

3,5

3

85,5

Для учёта затрат на этапе написания программного комплекса и его отладки определим себестоимость машино-часа работы ЭВМ. Необходимые формулы приведены в таблице 1.2.5.

Основная заработная плата: Зо = 60000 / (21* 8) = 357,1 руб. /час. Дополнительная заработная плата: Зд = (14/100) * 357,1 = 50 руб. /час. Отчисления на соцобеспечение: Зсс = (26/100) * (357,1 + 50) = 105,9 руб. /час. Затраты на электроэнергию: Зээ = 2 * 0,3 * 1,85 = 1,1 руб. /час. Амортизация: За = 20 * 30000 * 2/ (100 * 8 * 21 * 12) = 6 руб. /час. Прочие производственные расходы: Зпр = 50 / 100 * (357,1 + 1,1 + 6) = 182,1 руб. /час. Таким образом, себестоимость машино-часа работы ЭВМ составит: = 357,1 + 50 + 105,9 + 1,1 + 6 + 182,1 = 702,2 руб. /час.

Однако, при расчёте себестоимости машино-часа учитывались затраты лишь на ЭВМ, занятой для решения данного вопроса. А нам необходимо ещё учитывать затраты на ремонт оборудования. Затраты на ремонт составляют 10% от стоимости оборудования, т.е.:

Зр = 10 * Sэвм * 2/ (8 * m * 12 * 100);

Зр = 10 * 30000 * 2/ (8 * 21 * 12 * 100) = 3 руб. /час;

Таким образом, себестоимость машино-часа работы:

С = 702,2 + 3 = 705,2 руб. /час;

Зная себестоимость машино-часа работы ЭВМ, можно определить затраты на написание программного комплекса и его отладку по формуле:

Знп-о = С * t,

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

Знп-о = 705,2 * 504 = 355,4 тыс. руб.

Таким образом, величина затрат на разработку составляет 355,4 тыс. руб.

5.6 Расчёт вложений по годам этапа эксплуатации

Общая продолжительность этапа эксплуатации равна 2 года. Годовые текущие (эксплуатационные) затраты на обработку информации в ИТ-проекте рассчитываются как сумма следующих слагаемых:

Основная и дополнительная зарплата персонала;

Отчисления на социальные отчисления;

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

Расходы на текущий ремонт и содержание технических средств и оборудования (затраты на запчасти и вспомогательные материалы)

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

Расходные материалы (носители информации) и прочие расходы.

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

Общие эксплуатационные издержки потребителя составят:

И = (Зп + Зд + Зс + Зр + За + Зээ) * t,

где t - время эксплуатации (4032 часов); Зп - совокупная основная заработная плата пользователей, руб. /час. Для эксплуатации комплекса потребуется администратор. Поэтому при расчете необходимо учитывать заработную плату администратора - 30000 р.

Тогда, Зп = 30000 / 21/8 = 178,6 руб. /час; Зд - совокупная дополнительная заработная плата пользователей, руб. /час. (14% от основной зарплаты).

Зд = Зп*0,14 = 178,6*0,14 = 25 руб. /час;

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

Зс = 0,26* (Зп + Зд) = 53 руб. /час;

Зр - затраты на ремонт (10% от стоимости оборудования).

Зр = 0,1* 1*30000/ 8/21/ 12 = 1,49 руб. /час;

За - затраты на амортизацию (20% от стоимости оборудования).

Зр = 0,2* 1*30000/ 8/21/ 12 = 2,98 руб. /час;

Зээ - затраты на электроэнергию.

Зээ = 1,85 * 0.3 * 1 = 0,55 руб. /час;

Тогда при основном варианте и альтернативном варианте:

И = (178,6 + 25 + 53 + 1,49 + 2,98 + 0,55) * 4032 = 1 054,8 тыс. руб.

5.7 Итоговые показатели технико-экономической эффективности

Динамика показателей на этапе эксплуатации для основного и альтернативного варианта приведены в таблице 1.2.8

В результате современная величина затрат на этапе эксплуатации составит для основного варианта и альтернативного вариантов: за первый год эксплуатации (0.9091) * 1 054,8 тыс. руб. / 2 = 479,5 тыс. руб.; за второй год эксплуатации (0.8264) * 1 054,8 тыс. руб. / 2 = 435,8 тыс. руб. Показатель итоговой величины затрат: для основного варианта: 238,2 тыс. руб. + 915,3 тыс. руб. = 1 153,3 тыс. руб.; для альтернативного варианта: 355,4 тыс. руб. + 915,3 тыс. руб. = 1 270,7 тыс. руб.

Показатели технико-экономической эффективности разрабатываемого продукта сведены в таблицу 5.3.8.

Таблица 5.3.8

Наименование показателей

Значения показателей по вариантам

Основной

Альтернативный

Технико-эксплуатационные

Рекомендуемый объём ОЗУ, Мбайт

2048

4096

Рекомендуемый тип процессора

AMD Athlon 64 X2

AMD Athlon 64 X2

Язык программирования

PHP

С#

Экономические показатели

Период разработки и отладки, мес.

4

4

Количество исполнителей

2

2

Период эксплуатации, мес.

28

24

Современная величина затрат на разработку и отладку ПП, тыс. руб.

238,2

355,4

Современная величина затрат на эксплуатацию ПП, тыс. руб.

915,3

915,3

Показатель итоговой величины современных затрат, тыс. руб.

1 153,3

1 270,7

Выводы

Сравнение сумм современных затрат по двум возможным вариантам вложения инвестиций показывает, что предпочтительным для финансирования является основной вариант проекта, для осуществления которого при прочих равных условиях требуется меньшая современная сумма затрат. Показатель итоговой величины современных затрат на этапе разработки для этого варианта составляет 238,2 тыс. руб. Это значение меньше показателя итоговой величины современных затрат второго (альтернативного) варианта. Также, следует отметить, что технико-эксплутационные показатели основного варианта лучше, ввиду меньшего затрата ресурсов памяти ЭВМ.

Заключение

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

В рамках модульного проектирования была использована система управления базами данных (СУБД), в основе которой заложена архитектура 'клиент-сервер'. Проектирование велось с использование CASE средства Rational Rose совместно с Data Modeler. После чего спроектированная база данных была успешна перенесена на сервер СУБД MySQL, отличающейся высокой производительностью, и основывающейся на организации удаленного доступа к базам данных. На ее базе был разработан пользовательский интерфейс взаимодействия с системой. Разработка клиентской части велась с использованием языка PHP, работающем на WEB-сервере Apache.

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

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

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

Приложение 1Скрипт создания БД в MYSQL

Структура таблиц

CREATE DATABASE `building` DEFAULT CHARACTER SET cp1251 COLLATE cp1251_general_ci;

USE `building`;

Структура таблицы `building`

-

DROP TABLE IF EXISTS `building`;

CREATE TABLE IF NOT EXISTS `building` (

`eNo` int (11) NOT NULL,

`oNo` int (11) NOT NULL,

KEY `eNo` (`eNo`),

KEY `oNo` (`oNo`)

) ENGINE=InnoDB DEFAULT CHARSET=cp1251;

INSERT INTO `building` (`eNo`, `oNo`) VALUES (16, 18

-

Структура таблицы `client`

-

DROP TABLE IF EXISTS `client`;

CREATE TABLE IF NOT EXISTS `client` (

`iNo` int (11) NOT NULL auto_increment,

`iName` varchar (255) NOT NULL,

`iPost` char (10) NOT NULL,

`iPhone` varchar (255) NOT NULL,

PRIMARY KEY (`iNo`,`iPost`)

) ENGINE=InnoDB DEFAULT CHARSET=cp1251 AUTO_INCREMENT=5;

INSERT INTO `client` (`iNo`, `iName`, `iPost`, `iPhone`) VALUES (1, 'Бизнес-Профит', 'Investor', '233-44-34'

-

Структура таблицы `delivery`

-

DROP TABLE IF EXISTS `delivery`;

CREATE TABLE IF NOT EXISTS `delivery` (

`mNo` int (11) NOT NULL,

`oNo` int (11) NOT NULL,

`count` decimal (8,0) NOT NULL,

KEY `mNo` (`mNo`),

KEY `oNo` (`oNo`)

) ENGINE=InnoDB DEFAULT CHARSET=cp1251;

INSERT INTO `delivery` (`mNo`, `oNo`, `count`) VALUES (10, 18, '10'

-------------------------------------------------------

-

Структура таблицы `employee`

-

DROP TABLE IF EXISTS `employee`;

CREATE TABLE IF NOT EXISTS `employee` (

`eNo` int (11) NOT NULL auto_increment,

`eName` varchar (255) NOT NULL,

`ePost` char (10) NOT NULL default '',

`eState` enum ('free','busy') NOT NULL default 'free',

`eSalary` decimal (8,0) NOT NULL,

PRIMARY KEY (`eNo`,`ePost`)

) ENGINE=InnoDB DEFAULT CHARSET=cp1251 AUTO_INCREMENT=25;

INSERT INTO `employee` (`eNo`, `eName`, `ePost`, `eState`, `eSalary`) VALUES (1, 'Андрей', 'Director', 'busy', '100000'

-------------------------------------------------------

-

Структура таблицы `investing`

-

DROP TABLE IF EXISTS `investing`;

CREATE TABLE IF NOT EXISTS `investing` (

`iNo` int (11) NOT NULL,

`oNo` int (11) NOT NULL,

`sum` decimal (8,0) NOT NULL,

UNIQUE KEY `iNo` (`iNo`,`oNo`),

KEY `oNo` (`oNo`)

) ENGINE=InnoDB DEFAULT CHARSET=cp1251;

INSERT INTO `investing` (`iNo`, `oNo`, `sum`) VALUES (1, 6, '20000')

-------------------------------------------------------

-

Структура таблицы `material`

-

DROP TABLE IF EXISTS `material`;

CREATE TABLE IF NOT EXISTS `material` (

`mNo` int (11) NOT NULL auto_increment,

`mName` varchar (255) NOT NULL,

`mCost` decimal (8,0) NOT NULL,

PRIMARY KEY (`mNo`)

) ENGINE=InnoDB DEFAULT CHARSET=cp1251 AUTO_INCREMENT=12;

INSERT INTO `material` (`mNo`, `mName`, `mCost`) VALUES (3, 'арматура', '1000')

-

Структура таблицы `object`

-

DROP TABLE IF EXISTS `object`;

CREATE TABLE IF NOT EXISTS `object` (

`oNo` int (11) NOT NULL auto_increment,

`oAddress` varchar (255) NOT NULL,

`oFloreys` int (11) NOT NULL,

`oState` enum ('сдан','не сдан') NOT NULL,

`oDate` date NOT NULL,

`oCost` decimal (8,0) NOT NULL,

`eNO` int (11) default NULL,

PRIMARY KEY (`oNo`),

KEY `eNO` (`eNO`)

) ENGINE=InnoDB DEFAULT CHARSET=cp1251 AUTO_INCREMENT=19;

INSERT INTO `object` (`oNo`, `oAddress`, `oFloreys`, `oState`, `oDate`, `oCost`, `eNO`) VALUES (4, 'ул. Белинского', 12, 'сдан', '2005-05-08', '2000',

3)

-------------------------------------------------------

-

Структура таблицы `users`

-

DROP TABLE IF EXISTS `users`;

CREATE TABLE IF NOT EXISTS `users` (

`uNo` int (11) NOT NULL,

`uPost` char (10) NOT NULL,

`uName` varchar (255) NOT NULL,

`uPassword` varchar (255) NOT NULL,

UNIQUE KEY `uNo` (`uNo`,`uPost`)

) ENGINE=InnoDB DEFAULT CHARSET=cp1251;

INSERT INTO `users` (`uNo`, `uPost`, `uName`, `uPassword`) VALUES (1, 'Director', 'bdron', '8fc88460a8f78875f25f7b3249e49a3cce1be97a')

-------------------------------------------------------

Схема данных и обеспечение целостности данных

Ограничения для таблицы `building`

-

ALTER TABLE `building`

ADD CONSTRAINT `building_ibfk_1` FOREIGN KEY (`eNo`) REFERENCES `employee` (`eNo`) ON DELETE CASCADE ON UPDATE CASCADE,

ADD CONSTRAINT `building_ibfk_2` FOREIGN KEY (`oNo`) REFERENCES `object` (`oNo`) ON DELETE CASCADE ON UPDATE CASCADE;

-

Ограничения для таблицы `delivery`

-

ALTER TABLE `delivery`

ADD CONSTRAINT `delivery_ibfk_1` FOREIGN KEY (`mNo`) REFERENCES `material` (`mNo`) ON DELETE CASCADE ON UPDATE CASCADE,

ADD CONSTRAINT `delivery_ibfk_2` FOREIGN KEY (`oNo`) REFERENCES `object` (`oNo`) ON DELETE CASCADE ON UPDATE CASCADE;

-

Ограничения для таблицы `investing`

-

ALTER TABLE `investing`

ADD CONSTRAINT `investing_ibfk_1` FOREIGN KEY (`iNo`) REFERENCES `client` (`iNo`) ON DELETE CASCADE ON UPDATE CASCADE,

ADD CONSTRAINT `investing_ibfk_2` FOREIGN KEY (`oNo`) REFERENCES `object` (`oNo`) ON DELETE CASCADE ON UPDATE CASCADE;

-

Ограничения для таблицы `object`

-

ALTER TABLE `object`

ADD CONSTRAINT `object_ibfk_1` FOREIGN KEY (`eNO`) REFERENCES `employee` (`eNo`) ON UPDATE CASCADE;

Пользовательские представления

Строительство

create view vw_building AS

select `object`. `oAddress` AS `oAddress`

,`object`. `oFloreys` AS `oFloreys`

,`object`. `oState` AS `oState`

,`object`. `oCost` AS `oCost`

,concat (quarter (`object`. `oBeginDate`),' ът. ',year (`object`. `oBeginDate`)) AS `oBeginDate`

,concat (quarter (`object`. `oDate`),' ът. ',year (`object`. `oDate`)) AS `oDate`

from `object` where (`object`. `oState` = 'эх ёфрэ');

Триггеры

удаление пользователя перед удалением клиента

create trigger delete_client before delete on client for each row

begin

delete from users where uNo=OLD. iNo && uPost=OLD. iPost;

end

Хранимые процедуры

добавление сотрудника

create procedure addEmployee (in No int, in Name varchar (255), in Post char (10), in State char (10), in Salary decimal (10,2), in uName tinytext, in uPassword tinytext)

begin

set autocommit = 0;

insert into employee values (No, Name, Post, State, Salary);

if (Post='Director') || (Post = 'Manager') then

insert into users values (last_insert_id (), Post, uName, sha1 (uPassword));

end if;

commit;

set autocommit = 1;

end

добавление клиента

create procedure addClient (in No int, in Name varchar (255), in Post char (10), in Phone varchar (255), in uName varchar (255), in uPassword varchar (255))

begin

set autocommit = 0;

insert into client values (No, Name, Post, Phone);

if (Post='Investor') then

insert into users values (last_insert_id (), Post, uName, sha1 (uPassword));

end if;

commit;

set autocommit = 1;

end

вход в приложение

CREATE PROCEDURE login (in name varchar (255), in password varchar (255), in post char (10))

begin

if (post = 'employee') then

select uNo, uPost

from employee, users

where

uName = name && uPassword = sha1 (password) && uNo = eNo && uPost=ePost;

elseif (post = 'client') then

select uNo, uPost

from client, users

where

uName = name && uPassword = sha1 (password) && uNo = iNo && uPost=iPost;

end if;

end

проверка существования пользователя

create procedure isuser (in Name varchar (255), in Post char (10))

begin

select * from users where uName=Name && uPost = Post;

end

добавление объекта

create procedure addobject (in oNo int, in Address varchar (255), in Floreys int, in oState char (10), in oDate date, in Cost decimal (10,2), in No int)

begin

set autocommit = 0;

insert into object values (oNo, Address, Floreys, oState, curdate (), oDate, Cost, No);

if (No is not null) then

update employee set eState='busy' where eNo = No;

end if;

commit;

set autocommit = 1;

end

изменение состояния объекта

create procedure changeobject (in No int, in Address varchar (255), in Floreys int, in State char (10), in Date date, in Cost decimal (10,2), in empNo int)

begin

set autocommit = 0;

update employee set eState = 'free' where eNo = (select eNo from object where oNo = No);

update object set oAddress=Address, oFloreys=Floreys, oState = State, oDate=Date, oCost=Cost, eNo=empNo where oNo = No;

if (empNo is not null) then

update employee set eState='busy' where eNo = empNo;

end if;

if (State = 'сдан') then

update employee set eState = 'free' where eNo = (select eNo from object where oNo = No);

end if;

if (State = 'сдан') then

update employee set eState = 'free' where eNo in (select eNo from building where oNo = No);

end if;

commit;

set autocommit = 1;

end

удаление объекта

create procedure deleteobject (in No int)

begin

set autocommit=0;

update employee set eState = 'free' where eNo = (select eNo from object where oNo = No);

update employee set eState = 'free' where eNo in (select eNo from building where oNo = No);

delete from object where oNo=No;

commit;

set autocommit=1;

end

изменение данных управляющего

create procedure changemanager (in No int, in Name varchar (255), in Salary decimal (8), in objNo int)

begin

set autocommit = 0;

update object set eNo = null where eNo = No && oState = 'не сдан';

update employee set eName = Name, eSalary = Salary where eNo = No;

if (objNo is not null) then

update object set eNo = No where oNo = objNo;

update employee set eState = 'busy';

end if;

if (objNo is null) then

update employee set eState = 'free' where eNo = No;

end if;

commit;

set autocommit = 1;

end

удаление управляющего

create procedure deleteManager (in No int)

begin

set autocommit=0;

update object set eNo = null where eNo = No;

delete from employee where eNo=No;

delete from users where uNo=No && uPost='Manager';

commit;

set autocommit=1;

end

добавление связи между строителем и объектом строительства

create procedure addBuilding (in oNo int, in eNo int)

begin

set autocommit = 0;

insert into building values (eNo, oNo);

update employee set eState='busy' where employee. eNo=eNo;

commit;

set autocommit = 1;

end

Приложение 2Библиотека функций директора

<? php

class DirectorClass extends ClientClass

{

// вывод меню аккаунта Директора

public function showAccount ()

{

print <<<HERE

<div id='header'>Директор</div>

<a href='? f=showObjects'>объекты</a>

<a href='? f=showManagers'>управляющие</a>

<a href='? f=showReports'>все отчеты</a>

<a href='? f=showExit'>выход</a>

HERE;

}

// вывод всех объетов

public function showObjects ()

{

echo '<div id='header'>Строящиеся объекты</div>';

print <<<HERE

<table style='text-align: center'>

<tr height='30'>

<th>Адрес</th><th>Этажей</th><th>Готовность</th><th>Цена кв. м</th><th>Срок сдачи</th><th>Управляющий</th>

</tr>

HERE;

require ('connect. php');

$sql = 'SELECT oNo, oAddress, oFloreys, oState, oCost, concat (quarter (oDate),' кв. ',year (oDate)) oDate, (select eName from employee where object. eNo = eNo) eName from object where oState='не сдан'';

$result = mysqli_query ($link,$sql);

while ($row = mysqli_fetch_assoc ($result))

{

$oAddress = $row ['oAddress'];

$oFloreys = $row ['oFloreys'];

$oState = $row ['oState'];

$oDate = $row ['oDate'];

$oNo = $row ['oNo'];

$oCost = $row ['oCost'];

$eName = $row ['eName'];

print <<<HERE

<tr>

<td><a href='? f=showChangeObject&id=$oNo'>$oAddress</a></td>

<td>$oFloreys</td>

<td>$oState</td>

<td>$oCost</td>

<td>$oDate</td>

<td>$eName</td>

</tr>

HERE;

}

print <<<HERE

</table>

HERE;

echo '<br>'. '<br>'. '<a href='? f=showAddObject'> [Добавить объект] </a>';

}

// вывод управляющих

public function showManagers ()

{

echo '<div id='header'>Управляющие</div>';

print <<<HERE

<table style='text-align: center'>

<tr height='30'>

<th>Код</th><th>Имя</th><th>Зарплата</th><th>Объект</th>

</tr>

HERE;

require ('connect. php');

$sql = 'SELECT eNo, eName, eSalary, (select oAddress from object where object. eNo = employee. eNo && oState='не сдан') oAddress from employee where ePost='Manager'';

$result = mysqli_query ($link,$sql);

while ($row = mysqli_fetch_assoc ($result))

{

$eNo = $row ['eNo'];

$eName = $row ['eName'];

$eSalary = $row ['eSalary'];

$oAddress = $row ['oAddress'];

print <<<HERE

<tr>

<td>$eNo</td>

<td><a href='? f=showChangeManager&id=$eNo'>$eName</a></td>

<td>$eSalary</td>

<td>$oAddress</td>

</tr>

HERE;

}

print <<<HERE

</table>

HERE;

echo '<br><br><a href='? f=showAddManager'> [Добавить управляющего] </a>';

}

// выход

public function showExit ()

{

unset ($_SESSION ['status']);

unset ($_SESSION ['uName']);

unset ($_SESSION ['uNo']);

showMessage ('Завершение работы', 'Сеанс завершен');

echo '<HTML><HEAD>

<META HTTP-EQUIV='Refresh' CONTENT='2; URL=? '>

</HEAD></HTML>';

}

public function showLogin ()

{

showMessage ('Ошибка', 'Данная опция не доступна');

}

// вывод формы добавления управляющего

public function showAddManager ()

{

echo '<div id='header'>Добавление управляющего</div>';

$f = $_SERVER ['SCRIPT_NAME']. '? f='. $_GET ['f'];

if (isset ($_REQUEST ['uName'])) $uName = $_REQUEST ['uName'];

if (isset ($_REQUEST ['uPassword'])) $uPassword = $_REQUEST ['uPassword'];

if (isset ($_REQUEST ['eName'])) $eName = $_REQUEST ['eName'];

if (isset ($_REQUEST ['eSalary'])) $eSalary = $_REQUEST ['eSalary'];

if (isset ($_REQUEST ['uPassword2'])) $uPassword2 = $_REQUEST ['uPassword2'];

if (isset ($uName) &&! empty ($uPassword) &&! empty ($eName) &&! empty ($eSalary) && ($uPassword==$uPassword2))

addManager ($eName, $eSalary, $uName, $uPassword);

else

print<<<HERE

<form method='post' action=$f>

<table>

<tr>

<td>Имя: </td>

<td><input type='text' name='eName' maxlength='30'></td>

</tr>

<tr>

<td>Зарплата: </td>

<td><input type='text' name='eSalary' maxlength='16'></td>

</tr>

<tr>

<td>Логин: </td>

<td><input type='text' name='uName' maxlength='16'></td>

</tr>

<tr>

<td>Пароль: </td>

<td><input type='password' name='uPassword' maxlength='16'></td>

</tr>

<tr>

<td>Подтвердите пароль: </td>

<td><input type='password' name='uPassword2' maxlength='16'></td>

</tr>

<tr>

<td colspan='2' align='center'><input type='submit' value='Добавить' id='button'></td>

</tr>

</table>

</form>

HERE;

}

// вывод формы добавление объекта

public function showAddObject ()

{

echo '<div id='header'>Добавление объекта</div>';

$f = $_SERVER ['SCRIPT_NAME']. '? f='. $_GET ['f'];

if (isset ($_REQUEST ['oAddress'])) $oAddress = $_REQUEST ['oAddress'];

if (isset ($_REQUEST ['oFloreys'])) $oFloreys = $_REQUEST ['oFloreys'];

if (isset ($_REQUEST ['oCost'])) $oCost = $_REQUEST ['oCost'];

if (isset ($_REQUEST ['oDate'])) $oDate = $_REQUEST ['oDate'];

if (isset ($_REQUEST ['eNo'])) $eNo = $_REQUEST ['eNo'];

if (isset ($oAddress) &&! empty ($oFloreys) &&! empty ($oCost) &&! empty ($oDate))

addObject ($oAddress, $oFloreys, $oCost, $oDate, $eNo);

else

{

print<<<HERE

<form method='post' action=$f>

<table>

<tr>

<td>Адрес: </td>

<td><input type='text' name='oAddress' maxlength='40'></td>

</tr>

<tr>

<td>Число этажей: </td>

<td><input type='text' name='oFloreys' maxlength='16'></td>

</tr>

<tr>

<td>Стоимость кв. м: </td>

<td><input type='text' name='oCost' maxlength='16'></td>

</tr>

<tr>

<td>Время сдачи: </td>

<td><input type='text' name='oDate' maxlength='16'></td>

</tr>

<tr>

<td>Управляющий: </td>

<td><select size='1' name='eNo' >

<option value='' selected='selected'>не указан</option>

HERE;

require ('connect. php');

$sql = 'SELECT eName, eNo from employee where ePost='Manager' && eState='free' ';

$result = mysqli_query ($link,$sql);

while ($row = mysqli_fetch_assoc ($result))

{

$eName = $row ['eName'];

$eNo = $row ['eNo'];

echo '<option value='. $eNo. '>'. $eName. '</option>';

}

print<<<HERE

</select>

</td>

</tr>

<tr>

<td colspan='2' align='center'><input type='submit' value='Добавить' id='button'></td>

</tr>

</table>

</form>

HERE;

}

}

// вывод формы изменения объекта

public function showChangeObject ()

{

echo '<div id='header'>Изменение объекта</div>';

if (isset ($_GET ['id'])) $id = $_GET ['id'];

else

{

showMessage ('Неверный вызов фунцкции','Незадан параметр функции');

return;

}

$f = $_SERVER ['SCRIPT_NAME']. '? f='. $_GET ['f']. '&id='. $id;

if (isset ($_REQUEST ['oAddress'])) $oAddress = $_REQUEST ['oAddress'];

if (isset ($_REQUEST ['oFloreys'])) $oFloreys = $_REQUEST ['oFloreys'];

if (isset ($_REQUEST ['oCost'])) $oCost = $_REQUEST ['oCost'];

if (isset ($_REQUEST ['oDate'])) $oDate = $_REQUEST ['oDate'];

if (isset ($_REQUEST ['oState'])) $oState = $_REQUEST ['oState'];

if (isset ($_REQUEST ['eNo'])) $eNo = $_REQUEST ['eNo'];

if (isset ($oAddress) &&! empty ($oFloreys) &&! empty ($oCost) &&! empty ($oDate))

changeObject ($id, $oAddress, $oFloreys, $oCost, $oState, $oDate, $eNo);

else

{

require ('connect. php');

$sql = 'SELECT oNo, oAddress, oFloreys, oState, oCost, oDate, eNo, (select eName from employee where object. eNo = eNo) eName from object where oNo = '$id' && oState='не сдан'';

$result = mysqli_query ($link,$sql);

if (mysqli_num_rows ($result) == 0) // объекта с таким номером не существует

{

showMessage ('Неверный вызов фунцкции', 'Объекта с таким номером не существует');

return;

}

while ($row = mysqli_fetch_assoc ($result))

{

$oAddress = $row ['oAddress'];

$oFloreys = $row ['oFloreys'];

$oState = $row ['oState'];

$oDate = $row ['oDate'];

$oNo = $row ['oNo'];

$oCost = $row ['oCost'];

$eName = $row ['eName'];

$eNo = $row ['eNo'];

}

$yes = $no = '';

if ($oState == 'сдан') $yes = 'selected = 'selected'';

else $no = 'selected = 'selected'';

print<<<HERE

<form method='post' action=$f>

<table>

<tr>

<td>Адрес: </td>

<td><input type='text' name='oAddress' value='$oAddress' maxlength='40'></td>

</tr>

<tr>

<td>Число этажей: </td>

<td><input type='text' name='oFloreys' value='$oFloreys' maxlength='16'></td>

</tr>

<tr>

<td>Стоимость кв. м: </td>

<td><input type='text' name='oCost' value='$oCost' maxlength='16'></td>

</tr>

<tr>

<td>Время сдачи: </td>

<td><input type='text' name='oDate' value='$oDate' maxlength='16'></td>

</tr>

<tr>

<td>Управляющий: </td>

<td><select size='1' name='eNo'>

<option value='' selected='selected'>не указан</option>

HERE;

if (! empty ($eName))

echo '<option value='. $eNo. ' selected='selected'>'. $eName. '</option>';

require ('connect. php');

$sql = 'SELECT eName, eNo from employee where ePost='Manager' && eState='free' ';

$result = mysqli_query ($link,$sql);

while ($row = mysqli_fetch_assoc ($result))

{

$eName = $row ['eName'];

$eNo = $row ['eNo'];

echo '<option value='. $eNo. '>'. $eName. '</option>';

}

print<<<HERE

</select>

</td>

</tr>

<tr>

<td>Готовность: </td>

<td><select size='1' name='oState'>

<option value='не сдан' $no>не сдан</option>

<option value='сдан' $yes>сдан</option>

</select>

</td>

</tr>

<tr>

<td colspan='2'><a href='? f=showDeleteObject&id=$oNo'> [удалить объект] </a></td>

<tr>

<tr>

<td colspan='2' align='center'><input type='submit' value='Сохранить' id='button'></td>

</tr>

</table>

</form>

HERE;

}

}

// вывод формы удаления объекта

public function showDeleteObject ()

{

echo '<div id='header'>Удаление объекта</div>';

if (isset ($_GET ['id'])) $id = $_GET ['id'];

else

{

showMessage ('Неверный вызов фунцкции','Незадан параметр функции');

return;

}

deleteObject ($id);

}

// вывод формы изменения управляющего

public function showChangeManager ()

{

echo '<div id='header'>Изменение управляющего</div>';

if (isset ($_GET ['id'])) $id = $_GET ['id'];

else

{

showMessage ('Неверный вызов фунцкции','Незадан параметр функции');

return;

}

$f = $_SERVER ['SCRIPT_NAME']. '? f='. $_GET ['f']. '&id='. $id;

if (isset ($_REQUEST ['oNo'])) $oNo = $_REQUEST ['oNo'];

if (isset ($_REQUEST ['eSalary'])) $eSalary = $_REQUEST ['eSalary'];

if (isset ($_REQUEST ['eName'])) $eName = $_REQUEST ['eName'];

if (! empty ($eSalary) &&! empty ($eName))

changeManager ($id, $eName, $eSalary, $oNo);

else

{

require ('connect. php');

$sql = 'SELECT eNo, eName, eSalary, (select oAddress from object where object. eNo='$id' && oState='не сдан') oAddress, (select oNo from object where object. eNo='$id' && oState='не сдан') oNo from employee where ePost = 'Manager' && eNo='$id' ';

$result = mysqli_query ($link,$sql);

if (mysqli_num_rows ($result) == 0) // объекта с таким номером не существует

{

showMessage ('Неверный вызов фунцкции', 'Управляющего с таким номером не существует');

return;

}

while ($row = mysqli_fetch_assoc ($result))

{

$oAddress = $row ['oAddress'];

$eSalary = $row ['eSalary'];

$eName = $row ['eName'];

$eNo = $row ['eNo'];

$oNo = $row ['oNo'];

}

print<<<HERE

<form method='post' action=$f>

<table>

<tr>

<td>Имя: </td>

<td><input type='text' name='eName' value='$eName' maxlength='30'></td>

</tr>

<tr>

<td>Зарплата: </td>

<td><input type='text' name='eSalary' value='$eSalary' maxlength='16'></td>

</tr>

<tr>

<td>Объект: </td>

<td><select size='1' name='oNo'>

<option value='' selected='selected'>не указан</option>

HERE;

if (! empty ($oAddress))

echo '<option value='. $oNo. ' selected='selected'>'. $oAddress. '</option>';

require ('connect. php');

$sql = 'SELECT oNo, oAddress from object where oState='не сдан' && eNo is null ';

$result = mysqli_query ($link,$sql);

while ($row = mysqli_fetch_assoc ($result))

{

$oAddress = $row ['oAddress'];

$oNo = $row ['oNo'];

echo '<option value='. $oNo. '>'. $oAddress. '</option>';

}

print<<<HERE

</select>

</td>

</tr>

<tr>

<td colspan='2'><a href='? f=showDeleteManager&id=$eNo'> [удалить управляющего] </a></td>

<tr>

<tr>

<td colspan='2' align='center'><input type='submit' value='Сохранить' id='button'></td>

</tr>

</table>

</form>

HERE;

}

}

// вывод формы удаления управляющего

public function showDeleteManager ()

{

echo '<div id='header'>Удаление управляющего</div>';

if (isset ($_GET ['id'])) $id = $_GET ['id'];

else

{

showMessage ('Неверный вызов фунцкции','Незадан параметр функции');

return;

}

deleteManager ($id);

}

// вывод формы отчетов

public function showReports ()

{

echo '<div id='header'>Все отчеты</div>';

echo '<br>'. '<br>';

echo '<a href='? f=showReportInvesting'>Отчет по инвестициям</a>'. '<br>'. '<br>';

echo '<a href='? f=showReportInvestor'>Отчет по инвесторам</a>'. '<br>'. '<br>';

echo '<a href='? f=showReportDate'>Отчет по времени сдачи</a>'. '<br>'. '<br>';

echo '<a href='? f=showReportManager'>Отчет по управляющим</a>'. '<br>'. '<br>';

echo '<a href='? f=showReportDelivery'>Отчет по поставкам</a>'. '<br>'. '<br>';

}

// отчет по инвестициям

public function showReportInvesting ()

{

echo '<div id='header'>Отчет по инвестициям</div>';

print<<<HERE

<table>

HERE;

require ('connect. php');

$sql = 'SELECT oNo, oAddress, oFloreys, oState, oCost, concat (quarter (oDate),' кв. ', year (oDate)) oDate from object';

$result = mysqli_query ($link,$sql);

while ($row = mysqli_fetch_assoc ($result))

{

$oAddress = $row ['oAddress'];

$oFloreys = $row ['oFloreys'];

$oState = $row ['oState'];

$oDate = $row ['oDate'];

$oNo = $row ['oNo'];

$oCost = $row ['oCost'];

$summa = 0;

print<<<HERE

<tr>

<th colspan='3' style='font-size: 14px; '>$oAddress, $oFloreys этажей, $oState, Срок сдачи: $oDate, Стоимость кв. м: $oCost</th>

</tr>

<tr align='right'>

<th>Код</th><th>Имя</th><th>Сумма</th>

</tr>

HERE;

require ('connect. php');

$sql2 = 'SELECT client. iNo, client. iName, sum from investing, client where investing. oNo=$oNo && investing. iNo=client. iNo';

$result2 = mysqli_query ($link,$sql2);

while ($row2 = mysqli_fetch_assoc ($result2))

{

$iNo = $row2 ['iNo'];

$iName = $row2 ['iName'];

$sum = $row2 ['sum'];

$summa += $sum;

print<<<HERE

<tr align='right'>

<td>$iNo</td><td>$iName</td><td>$sum</td>

<tr>

HERE;

}

print<<<HERE

<tr align='right'>

<th colspan='3'>Общая сумма инвестиций: $summa</th>

</tr>

<tr>

<td colspan='3'><hr></td>

</tr>

<tr>

<td>&nbsp; </td>

</tr>

HERE;

}

print<<<HERE

</table>

HERE;

}

// отчет по инвесторам

public function showReportInvestor ()

{

echo '<div id='header'>Отчет по инвесторам</div>';

print<<<HERE

<table>

HERE;

require ('connect. php');

$sql = 'SELECT iNo, iName from client where iPost='Investor'';

$result = mysqli_query ($link,$sql);

while ($row = mysqli_fetch_assoc ($result))

{

$iNo = $row ['iNo'];

$iName = $row ['iName'];

$summa = 0;

print<<<HERE

<tr>

<th colspan='5' style='font-size: 14px; '>$iNo, $iName</th>

</tr>

<tr align='right'>

<th>Адрес</th><th>Этажей</th><th>Готовность</th><th>Срок сдачи</th><th>Инвестирование</th>

</tr>

HERE;

require ('connect. php');

$sql2 = 'SELECT oAddress, oFloreys, oState, sum, concat (quarter (oDate),' кв. ', year (oDate)) oDate from object, investing, client where investing. iNo=client. iNo && object. oNo=investing. oNo && client. iNo=$iNo';

$result2 = mysqli_query ($link,$sql2);

while ($row2 = mysqli_fetch_assoc ($result2))

{

$oAddress = $row2 ['oAddress'];

$oFloreys = $row2 ['oFloreys'];

$oState = $row2 ['oState'];

$oDate = $row2 ['oDate'];

$sum = $row2 ['sum'];

$summa += $sum;

print<<<HERE

<tr align='right'>

<td>$oAddress</td><td>$oFloreys</td><td>$oState</td><td>$oDate</td><td>$sum</td>

<tr>

HERE;

}

print<<<HERE

<tr align='right'>

<th colspan='5'>Общая сумма инвестиций: $summa</th>

</tr>

<tr>

<td colspan='5'><hr></td>

</tr>

<tr>

<td>&nbsp; </td>

</tr>

HERE;

}

print<<<HERE

</table>

HERE;

}

// отчет по времени сдачи

public function showReportDate ()

{

echo '<div id='header'>Отчет по времени сдачи</div>';

print<<<HERE

<table>

HERE;

require ('connect. php');

$sql = 'SELECT distinct year (oDate) oDate from object order by oDate';

$result = mysqli_query ($link,$sql);

while ($row = mysqli_fetch_assoc ($result))

{

$oDate = $row ['oDate'];

$summa = 0;

print<<<HERE

<tr>

<th colspan='5' style='font-size: 14px; '>$oDate год</th>

</tr>

<tr align='right'>

<th>Адрес</th><th>Этажей</th><th>Готовность</th><th>Срок сдачи</th><th>Стоимость кв. м</th>

</tr>

HERE;

require ('connect. php');

$sql2 = 'SELECT oAddress, oFloreys, oState, oCost, oDate date, concat (quarter (oDate),' кв. ', year (oDate)) oDate from object where year (oDate) =$oDate';

$result2 = mysqli_query ($link,$sql2);

while ($row2 = mysqli_fetch_assoc ($result2))

{

$oAddress = $row2 ['oAddress'];

$oFloreys = $row2 ['oFloreys'];

$oState = $row2 ['oState'];

$oDate = $row2 ['oDate'];

$oCost = $row2 ['oCost'];

$summa += 1;

print<<<HERE

<tr align='right'>

<td>$oAddress</td><td>$oFloreys</td><td>$oState</td><td>$oDate</td><td>$oCost</td>

<tr>

HERE;

}

print<<<HERE

<tr align='right'>

<th colspan='5'>Количество объектов в этом году: $summa</th>

</tr>

<tr>

<td colspan='5'><hr></td>

</tr>

<tr>

<td>&nbsp; </td>

</tr>

HERE;

}

print<<<HERE

</table>

HERE;

}

// отчет по управляющим

public function showReportManager ()

{

echo '<div id='header'>Отчет по управляющим</div>';

print<<<HERE

<table>

HERE;

require ('connect. php');

$sql = 'SELECT eNo, eName, eSalary from employee where ePost='Manager'';

$result = mysqli_query ($link,$sql);

while ($row = mysqli_fetch_assoc ($result))

{

$eNo = $row ['eNo'];

$eName = $row ['eName'];

$eSalary = $row ['eSalary'];

$summa = 0;

print<<<HERE

<tr>

<th colspan='5' style='font-size: 14px; '>$eNo, $eName, Зарплата: $eSalary</th>

</tr>

<tr align='right'>

<th>Адрес</th><th>Этажей</th><th>Готовность</th><th>Срок сдачи</th><th>Стоимость кв. м</th>

</tr>

HERE;

require ('connect. php');

$sql2 = 'SELECT oAddress, oFloreys, oState, oCost, concat (quarter (oDate),' кв. ', year (oDate)) oDate from object where eNo=$eNo';

$result2 = mysqli_query ($link,$sql2);

while ($row2 = mysqli_fetch_assoc ($result2))

{

$oAddress = $row2 ['oAddress'];

$oFloreys = $row2 ['oFloreys'];

$oState = $row2 ['oState'];

$oDate = $row2 ['oDate'];

$oCost = $row2 ['oCost'];

$summa += 1;

print<<<HERE

<tr align='right'>

<td>$oAddress</td><td>$oFloreys</td><td>$oState</td><td>$oDate</td><td>$oCost</td>

<tr>

HERE;

}

print<<<HERE

<tr align='right'>

<th colspan='5'>Число объектов: $summa</th>

</tr>

<tr>

<td colspan='5'><hr></td>

</tr>

<tr>

<td>&nbsp; </td>

</tr>

HERE;

}

print<<<HERE

</table>

HERE;

}

// отчет по поставкам

public function showReportDelivery ()

{

echo '<div id='header'>Отчет по поставкам</div>';

print<<<HERE

<table>

HERE;

require ('connect. php');

$sql = 'SELECT oNo, oAddress, oFloreys, oState, oCost, concat (quarter (oDate),' кв. ', year (oDate)) oDate from object';

$result = mysqli_query ($link,$sql);

while ($row = mysqli_fetch_assoc ($result))

{

$oAddress = $row ['oAddress'];

$oFloreys = $row ['oFloreys'];

$oState = $row ['oState'];

$oDate = $row ['oDate'];

$oNo = $row ['oNo'];

$oCost = $row ['oCost'];

$summa = 0;

print<<<HERE

<tr>

<th colspan='5' style='font-size: 14px; '>$oAddress, $oFloreys этажей, $oState, Срок сдачи: $oDate, Стоимость кв. м: $oCost</th>

</tr>

<tr align='right'>

<th>Код</th><th>Название</th><th>Стоимость</th><th>Количество</th><th>Сумма</th>

</tr>

HERE;

require ('connect. php');

$sql2 = 'SELECT material. mNo, mName, mCost, count, (mCost*count) sum from material, delivery where delivery. oNo=$oNo && delivery. mNo=material. mNo';

$result2 = mysqli_query ($link,$sql2);

while ($row2 = mysqli_fetch_assoc ($result2))

{

$mNo = $row2 ['mNo'];

$mName = $row2 ['mName'];

$mCost = $row2 ['mCost'];

$count = $row2 ['count'];

$sum = $row2 ['sum'];

$summa += $sum;

print<<<HERE

<tr align='right'>

<td>$mNo</td><td>$mName</td><td>$mCost</td><td>$count</td><td>$sum</td>

<tr>

HERE;

}

print<<<HERE

<tr align='right'>

<th colspan='5'>Общая стоимость поставки: $summa</th>

</tr>

<tr>

<td colspan='5'><hr></td>

</tr>

<tr>

<td>&nbsp; </td>

</tr>

HERE;

}

print<<<HERE

</table>

HERE;

}

}

// -------------------------------------------------------------------------------------------------------------- //

// добавление нового менеджера

function addManager ($eName, $eSalary, $uName, $uPassword)

{

require ('connect. php');

$sql = 'call isuser ('$uName', 'Manager')';

$result = mysqli_query ($link, $sql);

if (mysqli_num_rows ($result) > 0) // пользователь с таким именем уже существует

{

showMessage ('Регистрация в системе', 'Пользователь с таким логином уже существует');

return;

}

require ('connect. php');

$sql = 'call addEmployee (null, '$eName', 'Manager', 'free', '$eSalary', '$uName', '$uPassword')';

$result = mysqli_query ($link, $sql);

if (! $result)

{

showMessage ('Регистрация в системе', 'Невозможно произвести запись в базу данных');

$result = mysqli_errno ($link);

echo $result;

}

else

showMessage ('Регистрация в системе', 'Новый управляющий успешно зарегистрирован');

echo '<HTML><HEAD>

<META HTTP-EQUIV='Refresh' CONTENT='2; URL=? f=showManagers'>

</HEAD></HTML>';

}

// добавление нового объетка

function addObject ($oAddress, $oFloreys, $oCost, $oDate, $eNo)

{

require ('connect. php');

if (empty ($eNo)) $eNo = 'null';

$sql = 'call addobject (null, '$oAddress', '$oFloreys', 'не сдан', '$oDate', '$oCost', $eNo)';

$result = mysqli_query ($link, $sql);

if (! $result)

{

showMessage ('Добавление объекта', 'Невозможно произвести запись в базу данных');

}

else

showMessage ('Добавление объекта', 'Новый объект успешно создан');

echo '<HTML><HEAD>

<META HTTP-EQUIV='Refresh' CONTENT='2; URL=? f=showObjects'>

</HEAD></HTML>';

}

// изменение объекта

function changeObject ($oNo, $oAddress, $oFloreys, $oCost, $oState, $oDate, $eNo)

{

require ('connect. php');

if (empty ($eNo)) $eNo = 'null';

$sql = 'call changeobject ('$oNo', '$oAddress', '$oFloreys', '$oState', '$oDate', '$oCost', $eNo)';

$result = mysqli_query ($link, $sql);

if (! $result)

{

showMessage ('Изменение объекта', 'Невозможно произвести запись в базу данных');

}

else

showMessage ('Изменение объекта', 'Изменение завершено успешно');

echo '<HTML><HEAD>

<META HTTP-EQUIV='Refresh' CONTENT='2; URL=? f=showObjects'>

</HEAD></HTML>';

}

// удаление объекта

function deleteObject ($oNo)

{

require ('connect. php');

$sql = 'call deleteobject ('$oNo')';

$result = mysqli_query ($link, $sql);

if (! $result)

{

showMessage ('Удаление объекта', 'Невозможно произвести запись в базу данных');

}

else

showMessage ('Удаление объекта', 'Объект успешно удален');

echo '<HTML><HEAD>

<META HTTP-EQUIV='Refresh' CONTENT='2; URL=? f=showObjects'>

</HEAD></HTML>';

}

// изменение управляющего

function changeManager ($id, $eName, $eSalary, $oNo)

{

require ('connect. php');

if (empty ($oNo)) $oNo = 'null';

$sql = 'call changemanager ('$id', '$eName', '$eSalary', $oNo)';

$result = mysqli_query ($link, $sql);

if (! $result)

{

showMessage ('Изменение Управляющего', 'Невозможно произвести запись в базу данных');

}

else

{

showMessage ('Изменение Управляющего', 'Изменение завершено успешно');

echo '<HTML><HEAD>

<META HTTP-EQUIV='Refresh' CONTENT='2; URL=? f=showManagers'>

</HEAD></HTML>';

}

}

// удаление управляющего

function deleteManager ($eNo)

{

require ('connect. php');

$sql = 'call deletemanager ('$eNo')';

$result = mysqli_query ($link, $sql);

if (! $result)

{

showMessage ('Удаление управляющего', 'Невозможно произвести запись в базу данных');

}

else

{

showMessage ('Удаление управляющего', 'Управляющий успешно удален');

echo '<HTML><HEAD>

<META HTTP-EQUIV='Refresh' CONTENT='2; URL=? f=showObjects'>

</HEAD></HTML>';

}

}

? >

ref.by 2006—2025
contextus@mail.ru