Автоматизированная информационная система страхового агента

       Частное образовательное учреждение среднего профессионального образования

       «КРАСНОДАРСКИЙ  ТЕХНИКУМ УПРАВЛЕНИЯ, ИНФОРМАТИЗАЦИИ И  СЕРВИСА» 
 
 
 
 
 

       Курсовая  работа по дисциплине «Технология разработки программных продуктов»

       специальности «Программное обеспечение ВЧ и АС»

  Автоматизированная  информационная система страхового агента 
 

выполнил

Студент группы ПО 4.1

Сорокин Алексей

Научный руководитель:

Рожкова Вера Григорьевна 
 
 

       Краснодар 2011г

Оглавление 
 
 
 
 
 
 

Введение

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

     Основные функции СУБД – это  описание структуры базы данных, обработка данных и управление  данными.

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

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

    Разрабатываемая БД должна реализовывать:

        • сортировку по различным  полям,

        • поиск по введенному значению,

        • создание отчетов.

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

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

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

1.Тенденции развития СУБД

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

В толковом словаре по вычислительной технике, приводится такое определение системы управления базами данных (database management system): "приложение, обеспечивающее создание, хранение, обновление и поиск информации в базе данных, а также управление безопасностью и целостностью данных". В целом это толкование было верно и 30 лет назад, но все же содержательная часть СУБД сейчас совсем иная, чем в те далекие времена (отметим, что в определении уже отсутствует дополнительная фраза, которая использовалась для уточнения понятия еще восемь лет назад, — "программная оболочка, находящаяся между базой данных и пользователем").

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

В этой ситуации стоит обратить внимание на изменение  содержания "платформа Microsoft". Традиционно  под этим термином подразумевалась операционная система, Windows. Однако применительно к серверной платформе все чаще мы встречаем связку Windows Server + SQL Server. Более того, представляется вполне реальным, что с выходом в начале следующего года новой версии Microsoft SQL Server (рабочее название Yukon) мы столкнемся с ситуацией, когда все остальные продукты Microsoft будут уже писаться не под Windows, а под Yukon. Хотя существуют и будут существовать настольные базы данных: как ни странно, но Microsoft Access, судя по тому, как его представляет Microsoft  — это тоже СУБД.

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

2.Новые области применения баз данных

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

*   документографические и документальные применяются во всех базах органов власти и управления

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

*   базы данных по экономической и конъюнктурной информации (статистическая, кредитно-финансовая, внешнеторговая)

*   фактографические базы социальных данных, включающие  сведения  о населении и о социальной среде

*   базы данных транспортных систем

*   справочные данные для населения и учреждений (энциклопедии и справочники, расписания самолетов и поездов, адреса и телефоны граждан и организаций)

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

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

*   фактографические базы данных в области культуры и искусства

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

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

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

2.1.Электронная коммерция

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

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

Система электронной  коммерции должна иметь высоконадежные средства распределенной аутентификации и перевода денежных сумм.

2.2.Информационная система здравоохранения

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

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

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

3.Электронные  публикации

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

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

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

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

4. Коллективное  проектирование

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

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

Коллективное  проектирование требует новых форм управления совместным доступом к базам данных и механизмов разделения информации.

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

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

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

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

1. Представление  предметной области в том виде, как она реально существует;

2. Как ее  воспринимает человек (имеется  в виду проектировщик базы  данных);

3. Как она  может быть описана с помощью  символов.

То есть говорят, что мы имеем дело с реальностью, описанием (представлением) реальности и с данными, которые отражают это представление.

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

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

2. Исходя  из целей проектирования программной  системы;

3. На основании  представления о том, какое место БД и работающие с ней приложения займут в структуре эксплуатирующей ее организации;

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

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

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

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

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

В агентство  страхования могут обращаться разные клиенты, как физические лица, так и юридические. Соответственно документы, подаваемые для составления заявки от разных клиентов, будут различными. В соответствии с законодательством РФ, основными документами для проведения операций по продаже – покупки и страхованию имущества  для физического лица являются паспорт и карточка физического лица – платящего налоги (ИНН). Паспорт удостоверяет личность клиента, а наличие идентификационного кода позволяет гарантировать уплату налогов от проведённых операций государству. Для юридических лиц законодательство предусматривает также два основных вида документов. Это "Свидетельство о регистрации" и номер банковского счёта.

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

1. Номер  по порядку;

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

3.  Код  клиента (уникальный код клиента, в котором отображён порядковый номер клиента, его тип, а также номер заявки);

4. Фамилия  и инициалы клиента;

5. Адрес,  по которому проживает клиент;

6. Серия  и номер паспорта;

7. Идентификационный  код (ИНН);

8. Телефон  клиента.

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

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

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

4.Постановка задачи

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

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

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

1. Клиент  физическое лицо;

2. Клиент  юридическое лицо;

3. Недвижимость (объект продажи-покупки); 
 
 
 
 

5.Инфологическая модель

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

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

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

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

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

6.ER-модель

   Реляционный  подход основан на представлении  информации в виде двумерных  таблиц (отношений), построенных по  следующим правилам:

            1. Записи    в    отношении    могут    иметь    только    одиночные    значения;

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

               столбца находится только одно  значение.

            2. Все записи в одном столбце  имеют один и тот же тип. Например, один

               столбец может содержать фамилии  абонентов, а другой — их  лицевые счета. Каждый

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

               носят название  атрибутов  сущности.  Каждый атрибут имеет свой домен,  который

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

            3. В отношении не может быть  двух одинаковых строк, и порядок  следования

               строк несущественен. Строки называются кортежами.

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

7.Обоснование выбора СУБД

На сегодняшний  день известно более двух десятков форматов данных настольных СУБД, наиболее популярными следует признать dBase, Paradox, FoxPro и Access.

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