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

Содержание

• Введение
• 1. Предпроектное исследование
• 1.1 Методология проектирования информационных систем
• 1.2 Задачи обработки данных
• 1.3 Описание предметной области и атрибутов
• 1.4 Унифицированный язык моделирования UML
• 1.5 Использование унифицированного языка моделирования (UML) и Sybase PowerDesigner
• 1.6 Описание UML диаграмм в Sybase PowerDesigner
• 1.7 Построение модели в Sybase PowerDesigner
• 1.8 Построение диаграмм
• 1.8.1 Use case diagram (диаграмма вариантов использования)
• 1.8.2 Sequence diagram (диаграммы последовательностей действий)
• 2. Проектирование базы данных
• 2.1 Требования к информационной системе
• 2.2 Процесс проектирования базы данных
• 2.3 Нормализация отношений
• 2.3.1 Алгоритм синтеза
• 2.3.2 Нормализация схемы данных методом синтеза
• 2.4 Реализация базы данных
• 2.4.1 Проектирование физической модели в Sybase PowerDesigner
• 2.4.2 Разработка процедур и триггеров на стороне сервера с помощью pgAdmin III
• 2.4.3 Обеспечение безопасности доступа к данным на стороне сервера
• 3. Разработка клиентского программного обеспечения
• 3.1 Проектирование интерфейса в среде Microsoft Expression Blend
• 3.2 Разработка функциональной части клиентского приложения
• 3.2.1 Обработка событий формы, создание новых окон
• 3.2.2 Связывание данных (DataBinding)
• 3.2.3 Провайдер баз данных PostgreSQL Npgsql 2.0.8
• 3.3 Разработка клиентского приложения для интернет-сайта
• 3.4 Осуществление механизма удаленного доступа к базе данных
• 4. Расчёт эффективности инвестиций на разработку и отладку программного продукта
• 4.1 Цели, задачи и методы оценки эффективности инвестиций
• 4.2 Выбор и описание разрабатываемого и альтернативного вариантов программного продукта
• 4.3 Расчет вложений по годам этапа разработки
• 4.4 Расчёт вложений по годам этапа эксплуатации
• 5. Безопасность и санитарно-гигиенические условия труда на рабочем месте пользователя ПЭВМ
• 5.1 Микроклимат производственного помещения
• 5.2 Воздухообмен и наличие вентиляции
• 5.3 Ионизация воздуха
• 5.4 Требования к уровню шума и вибрации
• 5.5 Электромагнитное излучение
• 5.6 Освещение рабочего места пользователя ЭВМ
• 5.7 Режим труда
• 5.8 Электрическая безопасность
• 5.9 Оценка необходимости применения защитных устройств
• 5.10 Пожарная безопасность
• Выводы
• Заключение
• Список использованной литературы

Введение

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

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

PostgreSQL на сегодняшний день является одной из самых распространённых систем управления базами данных (СУБД) с открытым исходным кодом и распространяемых свободно. Это связано с тем, что PostgreSQL обладает:

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

· высокими показателями надёжности, производительности;

· расширяемостью. [1]

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

Прежде чем приступить к реализации программного продукта, необходимо четко определить назначение каждого компонента и выбрать метод реализации каждой из его функций. Функциональные аспекты компонентов проектируемой информационной системы (ИС) удобно представлять в виде диаграмм использования UML (унифицированный язык моделирования) и физических моделей данных UML. При разработке данного дипломного проекта использовался UML и Sybase PowerDesigner - мощное CASE - средство.

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

Данный программный продукт решает следующие задачи:

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

- дает возможность установки напоминаний о встречах/событиях по Email или SMS;

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

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

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

Данная пояснительная записка содержит следующие главы:

Глава 1 посвящена предпроектному исследованию: описана предметная область, с помощью унифицированного языка моделирования UML и Sybase PowerDesigner описана функциональная модель;

В главе 2 «Проектирование базы данных» «Проектирование автоматизированной системы управления» сформулированы требования к системе, проведена нормализация схемы отношений, описан поряжок построения физической модели, описаны подходы к обеспечению безопасности на уровне сервера от несанкционированного доступа, способы создания ролей входа;

В главе 3 «Разработка клиентского программного обеспечения» рассказывается о проектировании графического пользовательского интерфейса, о реагировании приложения на события, о привязке данных, о подключении и работе с базой данных из программного кода и об осуществлении механизма удаленного доступа;

В главе 4 приводится экономическое обоснование выгодности инвестиций в данный проект;

В главе 5 приводятся расчеты нормальных условий труда в соответствии с СанПиН.

• информационный система программа личный планирование

1. Предпроектное исследование

1.1 Методология проектирования информационных систем

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

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

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

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

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

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

o Критерии качества альтернативных решений на каждом этапе и методики их расчетов.

o Информационные требования в качестве исходных данных для проектирования, как в целом, так и на каждом этапе.

o Средства описания исходных данных и результатов каждого этапа проектирования.

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

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

· Анализ и описание функций системы средствами UML.

· Проработка требования к БД.

· Проектирование БД.

· Реализация автоматизированной системы управления.

1.2 Задачи обработки данных

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

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

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

· удобный и понятный интерфейс;

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

· возможность добавления данных, их корректировки и удаления;

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

1.3 Описание предметной области и атрибутов

В качестве предметной области создаваемой БД были даны:

· программа-органайзер

· Сущностями в ней являются:

· Пользователь;

· Заметка;

· Задача;

· Встреча/событие;

· Контакт;

· Группы.

Атрибутами сущностей в данной БД таковы:

1. Идентификационный номер пользователя,

2. Уникальное имя пользователя,

3. Пароль пользователя,

4. Номер для СМС сообщений пользователя,

5. Email адрес пользователя,

6. Дата создания заметки,

7. Заголовок заметки,

8. Текст заметки,

9. Принадлежность заметки к группе (группам),

10. Дата/время создания задачи,

11. Название задачи,

12. Текст задачи,

13. Комментарии к задаче,

14. Уровень приоритетности задачи,

15. Дата/время начала задачи,

16. Дата/время окончания задачи,

17. Принадлежность задачи к группе (группам),

18. Флаг напоминания о задаче,

19. Дата/время напоминания о задаче,

20. Способ напоминания о задаче,

21. Дата/время создания события,

22. Имя события,

23. Текст события,

24. Место события,

25. Комментарии к событию,

26. Приоритетность события,

27. Дата/время начала события,

28. Дата/время окончания события,

29. Участники события,

30. Принадлежность события к группе (группам),

31. Флаг напоминания о событии,

32. Дата/время напоминания о событии,

33. Способ напоминания о событии,

34. Идентификационный номер контакта,

35. Имя контакта,

36. Отчество контакта,

37. Фамилия контакта,

38. Ник контакта,

39. Место работы контакта,

40. Должность контакта,

41. Email контакта 1,

42. Email контакта 2,

43. Сайт контакта 1,

44. Сайт контакта 2,

45. ICQ контакта,

46. Skype контакта,

47. Jabber контакта,

48. LJ контакта,

49. Мобильный телефон контакта 1,

50. Мобильный телефон контакта 2,

51. Мобильный телефон контакта 3,

52. Рабочий телефон контакта,

53. Домашний телефон контакта,

54. Факс контакта,

55. Домашний адрес контакта,

56. Рабочий адрес контакта,

57. Комментарии к контакту,

58. Фото контакта,

59. Идентификационный номер группы,

60. Имя группы,

61. Цвет группы.

Предполагаемые Пользователи данной БД:

· Пользователь (аутентификация с помощью пары Логин/Пароль, контроль доступа к данным на клиентском уровне и уровне сервера).

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

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

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

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

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

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

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

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

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

Авторами UML являются Гради Буч (Grady Booch), Джеймс Румбах (James Rumbaugh) и Айвар Якобсон (Ivar Jacobson). Известные как «три товарища», в 80-х - начале 90-х годов они работали в разных организациях и независимо друг от друга продумывали методологии объектно-ориентированного анализа и проектирования, которые имели явные преимущества перед всеми остальными известными методами. В середине 90-х годов они стали заимствовать идеи друг у друга и поэтому решили объединить свои усилия.

В 1994 году Румбаха пригласили в компанию Rational Software Corporation, где в это же время уже работал Буч. Через год к ним присоединился Якобсон.

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

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

1.5 Использование унифицированного языка моделирования (UML) и Sybase PowerDesigner

Унифицированный язык моделирования (UML, Unified Modeling Language) является преемником методов объектно-ориентированного анализа и проектирования, которые появились в конце 80-х и начале 90-х годов, а с 1997 года является стандартом OMG в области визуального объектно-ориентированного моделирования и широко используется на практике, будучи реализован в рамках многих CASE-средств.

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

1.6 Описание UML диаграмм в Sybase PowerDesigner

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

· Use case diagram (диаграммы прецедентов);

· Deployment diagram (диаграммы топологии);

· Statechart diagram (диаграммы состояний);

· Activity diagram (диаграммы активности);

· Interaction diagram (диаграммы взаимодействия);

· Sequence diagram (диаграммы последовательностей действий);

· Collaboration diagram (диаграммы сотрудничества);

· Class diagram (диаграммы классов);

· Component diagram (диаграммы компонент).

Use case diagram (диаграммы прецедентов)

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

Каждая такая диаграмма или, как ее обычно называют, каждый Use case - это описание сценария поведения, которому следуют действующие лица (Actors).

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

Deployment diagram (диаграммы топологии)

Этот вид диаграмм предназначен для анализа аппаратной части системы, а не программ. В прямом переводе с английского Deployment означает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм.

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

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

State Maсhine diagram (диаграммы состояний)

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

Statechart diagram (диаграмма состояний)

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

Activity diagram (диаграммы активности)

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

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

Interaction diagram (диаграммы взаимодействия)

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

Sequence diagram (диаграммы последовательностей действий)

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

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

Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений. Для того чтобы окинуть взглядом все взаимосвязи объектов, служит Collaboration diagram.

Collaboration diagram (диаграммы сотрудничества)

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

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

Class diagram (диаграммы классов)

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

Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на котором отображаются объекты системы. Sybase PowerDesigner позволяет создавать классы при помощи данного типа диаграмм в различных нотациях. Component diagram (диаграммы компонентов).

Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей.

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

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

1.7 Построение модели в Sybase PowerDesigner

Целью данного этапа является проведение анализа бизнес-процессов заказчика и на основе данного анализа построение модели автоматизированной системы управления (АСУ). Для этого необходимо произвести анализ требований пользователя к продукту. Также необходимо провести анализ роли пользователя (Actor) в системе и т.д. Задача это не простая и требует значительных аналитических усилий и опыта. Результатом этой работы должно быть четкое понимание роли пользователя, процесса и список объектов (сущностей), участвующих в этом процессе. Все это и должно найти отражение в диаграммах Sybase PowerDesigner. Кроме того, необходимо с помощью анализа запросов среднего целевого пользователя составить список требований к ИС.

Используем следующий подход: используем Use case diagram для отображения списка операций, которые должна выполнять наша система; иначе говоря, это требования к системе. Каждый Use case - это некоторый процесс (последовательность действий), поэтому мы должны использовать Sequence diagram для его детализации. На этой диаграмме мы отображаем объекты из предметной области (объекты, участвующие в бизнес-процессе); таким образом, мы получаем экземпляры некоторых классов и их взаимодействие. Sequence diagram отображает сам процесс.

1.8 Построение диаграмм

1.8.1 Use case diagram (диаграмма вариантов использования)

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

1.8.2 Sequence diagram (диаграммы последовательностей действий)

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

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



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

2.1 Требования к информационной системе

Цель работы: спроектировать и реализовать базу данных (БД) в СУБД PostgreSQL.

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

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

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

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

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

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

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

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

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

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

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

2.2 Процесс проектирования базы данных

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

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

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

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

Иерархическая модель данных представляется в виде иерархии - “леса” независимых деревьев. Деревья реализуют связи, не сложнее 1:М. Это значит, что каждый исходный узел дерева может иметь несколько порожденных узлов, а каждый порожденный узел - только один исходный. Поскольку иерархия является частным случаем сети, можно легко показать, что сетевая модель может быть сведена к иерархической введением избыточности в данные.

Реляционная модель описывает данные в виде одного или нескольких отношений или таблиц.

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

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

Легко видеть, что каждая строка таблицы реализует связь 1:1. Все строки одной таблицы или всей БД могут реализовать все возможные типы связей.

Основной недостаток реляционной модели данных связывается с низкой производительностью реляционной СУБД. Но разработка современных СУБД таких как, ORACLE, InterBase, PostgreSQL, MySQL и др. позволило преодолеть и этот недостаток.

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

Перечислим достоинства и недостатки каждой модели данных:

Достоинства:

реляционной модели данных:

ћ простота и доступность для понимания;

ћ представление, как информации, так и связей единым образом в виде таблиц-отношений;

ћ симметричная реализация симметричных запросов;

ћ эффективная реализация алгоритмов обработки данных;

ћ мощный математический аппарат поддержки (реляционная алгебра и реляционное исчисление);

иерархической модели данных:

ћ дерево отражает естественные связи в реальных данных;

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

сетевой модели данных:

ћ сеть отражает естественные связи в реальном мире;

ћ почти симметричная реализация симметричных запросов;

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

Недостатки:

реляционной модели данных:

ћ трудности при реализации иерархий, например, повторяющихся групп (используются специальные приемы);

ћ необходимость организации данных с использованием сильных нормальных форм, хотя бы третьей нормальной формы;

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

иерархической модели данных:

ћ несимметричная реализация симметричных запросов;

ћ трудности при реализации операций обработки данных (значительный объем анализируемых данных, потенциальная противоречивость данных и пр.);

сетевой модели данных:

ћ сложность связей;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Декомпозиция может порождать схемы со “скрытыми” транзитивными зависимостями.

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

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

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

Исходными данными для работы алгоритма синтеза являются множество атрибутов 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-> O.

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

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

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

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

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

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

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

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

2.3.2 Нормализация схемы данных методом синтеза

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

Предметная область:

ћ программа-органайзер;

Сущности:

ћ Пользователь;

ћ Заметка;

ћ Задача;

ћ Встреча/событие;

ћ Контакт;

ћ Группы.

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

A. UserID,

B. UserInfo

C. NoteDate,

D. NoteInfo

E. TaskCrDate,

F. TaskInfo

G. EventCrDate,

H. EventInfo

I. ContactID,

J. ContactInfo

K. GroupNames

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

U = {A,B,C,D,E,F,G,H,I,J,K}

F = {A -> B,K ; A,C -> D ; A,E -> F ; A,G -> H ; A,I -> J}

Шаг 1: Построим расширенное множество

A+=ABK

AC+=ACDBK

AE+=AEFBK

AG+=AGHBK

AI+ =AIJBK

= {A -> BK ; AC -> DBK ; AE -> FBK ; AG -> HBK ; AI -> JBK}

Шаг 2: - условно не избыточное расширенное множество.

= {A -> BK ; AC -> DBK ; AE -> FBK ; AG -> HBK ; AI -> JBK}

Шаг 3: = { A -> BK ; AC -> DBK ; AE -> FBK ; AG -> HBK ; AI -> JBK, U>}



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

Шаг 5: Проранжируем полученные зависимости.

Таблица 2.1

X>Y	XY	rang
A -> BK	ABK	6
AC -> DBK	ACDBK	5
AE -> FBK	AEFBK	4
AG -> HBK	AGHBK	3
AI -> JBK	AIJBK	2
U>	ABCDEFGHIJK	1

Шаг 6: Построим ранжированную диаграмму зависимостей, она изображена на рисунке 2.1:

Рис 2.1 Ранжированная диаграмма зависимостей

Шаг 7: Выполним транзитивную редукцию зависимостей, результат изображен на рисунке2.2:

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

Шаг 8: Определим декомпозиционные подсхемы и их первичные ключи.

R1 = ACEGI, с ключом К1 = ACEGIR5 = ACD, с ключом К5 = AC

R2 = AIJ, с ключом К2 = AIR6 = ABK, с ключом К6 = A

R3 = AGH, с ключом К3 = AG

R4 = AEF, с ключом К4 = AE

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

Так как на шаге 3 была добавлена зависимость U>, необходимо проверить свойство соединения без потерь, без подсхемы R1 = ACEGI.

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

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

R1 = {ACEGI}, с ключом ACEGI

R2 = {AIJ}, с ключом AI

R3 = {AGH}, с ключом AG

R4 = {AEF}, с ключом AE

R5 = {ACD}, с ключом AC

R6 = {ABK}, с ключом A

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

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

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

-Простота алгоритма и легкость автоматизации.

-Возможность получения концептуальной схемы автоматизированной системы управления в НФБК.

2.4 Реализация базы данных

2.4.1 Проектирование физической модели в Sybase PowerDesigner

Sybase PowerDesigner предоставляет пользователю удобный функционал для создание физических моделей данных. На основание созданной физической модели среда Sybase PowerDesigner генерирует SQL-запрос, адаптированной для выбранной СУБД. Основные компоненты физической модели:

ћ Таблица (Table) - содержит описание всех полей проектируемой таблицы;

ћ Связь (Reference) - описывает связи по полям между таблицами;

ћ Процедуры (Procedure) - содержит описание процедур для работы с будущей БД или являются напоминанием программисту о необходимости разработать процедуру, если работа над проектированием БД и её непосредственной реализацией ведётся двумя разными специалистами. [6]

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

В приложении 3 приведен полученный программно SQL-запрос на создание базы данных.

2.4.2 Разработка процедур и триггеров на стороне сервера с помощью pgAdmin III

pgAdmin III - является основным средством для разработки и администрирования баз данных PostgreSQL. В данном проекте вся работа по созданию таблиц и связей базы данных была проведена с помощью пакета Sybase PowerDesigner и дополнительная разработка в этом направлении не потребовалась. Разработка хранимых процедур и тригеров велась с помощью pgAdmin III на языке PL/pgSQL.

Язык PL/pgSQL (Procedural Language/PostGres Structured Query Language) -- процедурное расширение языка SQL, используемое в СУБД PostgreSQL. Этот язык предназначен для написания функций, триггеров и правил и обладает следующими особенностями:

· добавляет управляющие конструкции к стандарту SQL;

· допускает сложные вычисления;

· может использовать все объекты баз данных, определенные пользователем;

· прост в использовании.

Также PL/pgSQL обладает рядом преимуществ перед SQL, это связанно с тем, что возможно выполнять сложную обработку данных с минимальным трафиком от клиента к серверу, что, в рамках данного дипломного проекта, является неоспоримым преимуществом, так как все действия пользователя связанны с посылкой запросов к серверу. Объясняется эта особенность следующим: SQL используется в PostgreSQL и других реляционных БД как основной язык для создания запросов. Он переносим и прост, как для изучения, так и для использования. Однако слабое его место -- в том, что каждая конструкция языка выполняется сервером отдельно. Это значит, что клиентское приложение должно отправлять каждый запрос серверу, получить его результат, определенным образом согласно логике приложения обработать его, посылать следующий запрос и так далее.

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

Программный код, разработанный на PL/pgSQL, легко читаем и для не специалиста в области PostgreSQL, что также является достоинством языка. Это связанно с тем, что любая программная конструкция (функция, триггер или правило), написанная на PL/pgSQL, имеет блочную компоновку и выглядит вот так:

[ <<метка>> ]

[ DECLARE

объявления переменных ]

BEGIN

тело программы

END [ метка ]; [5]

Разработка программного кода в среде pgAdmin III удобна для разработчика благодаря встроенному редактору с подсветкой синтаксиса.

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

· PL/Perl;

· plPHP;

· PL/Python;

· C;

· C++;

· Java (через модуль PL/Java);

· И некоторых других, менее популярных языках.

В качестве примера функции разработанной на языке PL\PgSQL приведена функция аутентификации пользователя в системе. Работа с ней осуществляется следующим образом: клиентское приложения, после заполнения пользователем полей «Логин» и «Пароль» на форме аутентификации и подтверждения пользователем ввода, отсылает на сервер запрос: SELECT "Login_user"(`Введенный логин','MD5 Hash взятый от введенного пароля'); , после чего сервер возвращает клиентскому приложению : -1 - если такой пары в системе не зарегистрировано, уникальный идентификатор пользователя - если пара обнаружена.

-- Function: "Login_user"(character varying, character varying)

CREATE OR REPLACE FUNCTION "Login_user"(character varying, character varying)

RETURNS integer AS

$BODY$DECLARE

logi ALIAS FOR $1;

passw ALIAS FOR $2;

collision users%ROWTYPE;

BEGIN

SELECT INTO collision * FROM users WHERE (logi = accountname)AND(passw = pass);

IF collision IS NULL THEN

RETURN -1;

END IF;

RETURN collision.uid;

END;$BODY$

LANGUAGE 'plpgsql' VOLATILE

SECURITY DEFINER

COST 100;

ALTER FUNCTION "Login_user"(character varying, character varying) OWNER TO postgres;

GRANT EXECUTE ON FUNCTION "Login_user"(character varying, character varying) TO public;

GRANT EXECUTE ON FUNCTION "Login_user"(character varying, character varying) TO postgres;

2.4.3 Обеспечение безопасности доступа к данным на стороне сервера

PostgreSQL позволяет регистрировать не оговоренное спецификацией число пользователей.[5] В связи с этим было бы не рационально создавать для каждого пользователя системы новую учетную запись на сервере. Возникает следующая проблема: поскольку имеет место обмен данным в незашифрованном виде по открытым каналам связи, злоумышленники могут перехватить сообщения, идущие от клиентского приложения к серверу базы данных и получить идентификаторы доступа к базе данных. В данном дипломном проекте реализовано следующее решение: по каналам связи никогда не передаются данные о учетной записи администратора базы данных, эта информация держится в секрете и известна лишь ограниченному кругу лиц. Пользователи, с помощью клиентского приложения, подключаются к базе данных через ограниченные учётные записи, у которых нет доступа к созданию/чтению/модификации/удалению таблиц/записей/функций/триггеров/пользователей. Эти учетные записи имеют доступ лишь к разработанным администратором базы данных функциям, то есть могут взаимодействовать с базой данных лишь заранее определённым образом. [6]