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

• Введение
• 1.1 Сущность информационной системы
• 1.2 Функциональная спецификация
• 1.3 Подходы к проектированию ИС
• 1.4 Унифицированный язык моделирования UML
• 1.5 CASE средство Rational Rose
• 1.6 Диаграмма вариантов использования
• 2. Проектирование базы данных
• 2.1 Требования, предъявляемые к базе данных
• 2.2 Нормальные формы
• 2.3 Нормализация схем отношений
• 2.4 Интеграция пользовательских представлений
• 2.5 Алгоритм синтеза
• 2.8 Создание схемы данных
• 2.9 Выбор средств разработки
• 3. Разработка информационной системы
• 3.1 Пользовательский режим работы
• 3.2 Режим работы инвестором
• 3.3 Режим работы управляющего
• 3.4 Режим работы директором
• 4. Безопасность и санитарно-гигиенические условия труда на рабочем месте пользователя ПЭВМ
• 4.1 Характеристика санитарно-гигиенических условий труда
• 4.2 Вентиляция
• 4.3 Расчет осветительной установки
• 4.4 Режим труда
• 4.5 Требования по организации рабочего места
• 4.6 Электрическая безопасность
• Выводы
• 5. Расчет экономической эффективности проекта
• 5.1 План маркетинга
• 5.2 Цели, задачи и методы оценки инвестиций
• 5.3 Выбор и описание разрабатываемого и альтернативного вариантов
• 5.4 Расчёт вложений на этапе разработки и отладки основного варианта
• 5.5 Расчёт вложений на этапе разработки и отладки альтернативного варианта
• 5.6 Расчёт вложений по годам этапа эксплуатации
• 5.7 Итоговые показатели технико-экономической эффективности
• Выводы
• Заключение
• Приложение 1Скрипт создания БД в MYSQL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В настоящее время унифицированный язык моделирования UML является визуальным языком моделирования, который позволяет системным архитекторам представить свое видение системы в стандартной и легкой для понимания форме. Кроме того, 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 Диаграмма прецедентов Диаграммы прецедентов или вариантов использования являются необходимым средством на стадии формирования требований к программному обеспечению. Каждый вариант использования — это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию.

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

Рис. 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 Интеграция пользовательских представлений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимость X_I — >Y_Iявляется элементарной, если не существует таких наборов атрибутов X_J X_I, что (X_j — >Y_I). Если — существует, то зависимость X_I — >Y_I заменяется зависимостью (X_J — >Y_I).

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

Зависимости X_I — >Y_I и X_J — >Y_J будем называть эквивалентными, если

т. е. минимальный ранг имеет зависимость, содержащая все атрибуты из 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.

Зависимости X_I Y_I и X_J Y_J будем называть эквивалентными, если (X_I Y_I) = (X_J Y_J).

Ранжируем полученные зависимости по следующему правилу rang (X_I Y_I) > rang (X_J Y_J), если (X_I Y_I) (X_J Y_J).

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

Шаг 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 Соответствие элементов логической и физической модели

Таким образом, концептуально модуль 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) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.