База данных ‘Страховая компания’
СОДЕРЖАНИЕ
СПИСОК
ИСПОЛЬЗОВАННЫХ СОКРАЩЕНИЙ
ВВЕДЕНИЕ
1.
ОБЗОР ИНФОРМАЦИОННЫХ СИСТЕМ В СТРАХОВАНИИ
.1
Описание предметной области
.2
Роль и основные принципы страхования
.3
Применение информационных систем в страховании
.4
Основные понятия БД
.5
Состав и функции СУБД
.6
Свойство полей БД
.7
Объекты Access
.
ФУНКЦИОНАЛЬНАЯ ОСОБЕННОСТЬ НАЦИОНАЛЬНОЙ СТРАХОВОЙ ГРУППЫ
.1
Анализ страховой компании
.2
Моделирование условной практической ситуации
.2.1
Заключение договора
.2.2
Страховой случай
.
РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ В СТРАХОВОЙ ДЕЯТЕЛЬНОСТИ
.1
Назначение и функции программной системы
.2
Создание таблиц
.3
Связывание таблиц
.4
Запросы
.5
Формы
.6
Отчеты
ЗАКЛЮЧЕНИЕ
СПИСОК
ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
ПРИЛОЖЕНИЯ
СПИСОК ИСПОЛЬЗОВАННЫХ СОКРАЩЕНИЙ
БД — база данных;
ИНН — индивидуальный номер налогоплательщика;
КАСКО — комплексное автомобильное страхование,
кроме ответственности;
ЭВМ — электронно-вычислительная машина;
АРМ — автоматизированное рабочее место;
ПЭВМ — персональная электронно-вычислительная
машина;
СУБД — система управления с базами данных;
РСУБД —
ЯОД — язык описания данных;
ЯМД — язык манипулирование данных;
СПО — средства подготовки отчетов;
СОАО «НСГ» — страховое открытое акционерное
общество «Национальная Страховая Группа»;
ВСС — всероссийский союз страхования.
ВВЕДЕНИЕ
В России страхование, как и вся экономическая
система, находится в состоянии реформирования. Страхование — это развивающаяся
отрасль, опирающаяся на огромный, практически неосвоенный рынок, имеющий в
России большое будущее. Основанием для такого прогноза является то, что во
многих развитых странах мира страховые компании по своей мощности и размерам
концентрируемого в них капитала стоят наравне с банками и являются важной
отраслью финансового сектора экономики.
Роль страхования в современной экономике
обусловлена выполняемой страхованием функцией финансового стабилизатора
развития экономики, который, с одной стороны, позволяет субъектам экономики
компенсировать ущербы, наступающие вследствие неизбежных случайных событий, а с
другой стороны, накапливать финансовые ресурсы для инвестиций в народное
хозяйство.
Актуальность выбранной темы определяется тем,
что в условиях рыночной экономики залогом стабильного развития страховой
компании служат её надежная клиентская база и финансовая устойчивость, т. е.
базовые условия, при которых возможно эффективное развитие продажи страховых
услуг. Именно поэтому проблема совершенствования современной методической базы
для обеспечения деятельности менеджмента страховой компании; оперирующего в сфере
рисковых видов страхования, в области формирования клиентской базы страховой
компании является наиболее актуальной для российского страхования на данном
этапе его развития.
Цель дипломной работы — рассмотреть работу
страховой компании, разработать и внедрить клиентскую базу в страховую
деятельность агентов СОАО «Национальная Страховая Группа», а также изучить
программу Microsoft Access 2007.
Объектом исследования является система
управления и среда деятельности страховщика, развивающего свой бизнес на рынке
рисковых видов страхования в специфичных условиях российской рыночной
экономики.
Предмет исследования представляет собой принципы
и методы формирования и управления клиентской базой и повышения устойчивости
страховой компании.
Поставленная перед нами цель открыла следующие
задачи:
Исследовать роль и принципы страхования;
Определить преимущества использования
информационных систем в страховании;
Изучить основные понятия базы данных, состав и
функции систем управления базами данных;
Рассмотреть основные объекты Access;
Проанализировать деятельность страховой компании
СОАО «Национальная Страховая Группа»;
Смоделировать практическую ситуацию;
Спроектировать базу данных.
Работа начинается с раскрытия сущности отношений
клиента и страховой компании и понятия о системе формирования и устойчивости
клиентской базы страховой компании. Далее в Главе 1 анализируются понятия
предметной области управления страховой компании, рассматриваются роль и
основные принципы страхования, описываются преимущества использования
информационных систем в страховании, приведены основные понятия базы данных,
состав и функции систем управления базами данных, а также основные объекты MS
Access 2007.
Во 2 главе проанализирована деятельность
страховой компании СОАО «Национальная Страховая Группа», рассмотрены и решены
практические ситуации.
В 3 главе рассказывается о создании базы данных
«НСГ» и ее реализация этой базы данных в страховой деятельности.
В заключении подведены итоги исследования,
сделаны выводы и обобщения.
1. ОБЗОР ИНФОРМАЦИОННЫХ
СИСТЕМ В СТРАХОВАНИИ
.1 Описание
предметной области
Областью применения БД является сфера
страхования. Согласно действующему законодательству, страхование представляет
собой отношения по защите имущественных интересов физических и юридических лиц
при наступлении определенных событий (страховых случаев) за счет денежных
фондов, формируемых из уплачиваемых ими страховых взносов (страховых премий).
Такое определение страхования позволяет сделать вывод, что страхование — это
отношения, в которых участвуют как минимум две стороны. В страховых отношениях
может участвовать и большее число сторон, если это оговаривается в договоре
страхования. Страхование выступает как совокупность особых замкнутых
перераспределительных отношений между его участниками по поводу формирования за
счет денежных взносов целевого страхового фонда, предназначенного для
возмещения возможного чрезвычайного и иного ущерба предприятиям и организациям
или для оказания денежной помощи гражданам.
В рамках данного дипломного проекта, была
использована сетевая база данных «Страховая компания». Для автоматизации,
наглядности и простоты управления рабочим процессом все данные отображаются на
формах. Сотрудник, т.е. агент страховой компании, имеет возможность просмотра
информации о клиентах, которая уже содержится в базе данных, а также
возможность ее редактирования, обновления и удаления ненужных записей. Также
имеется краткая информация о сотрудниках организации, на тот случай если
понадобится быстрый поиск ИНН, телефона или адреса сотрудника. В
спроектированной БД хранится вся информация о заключенных договорах, страховых
случаях, видах страхования.
1.2 Роль и основные принципы страхования
Страхование — система экономических отношений,
предназначенная для преодоления и возмещения разного рода потерь, ущерба в
результате непредвиденных случайностей. Оно представляет всем хозяйствующим
субъектам и членам общества гарантии в возмещении ущерба, полученного в
результате несчастных случаев, причиненного стихийным бедствием, вызванным непредвиденными
обстоятельствами в деятельности предприятий, фирм, банков.
Многовековой опыт страхования убедительно
доказал, что оно является мощным фактором положительного воздействия на
экономику. Именно страхование повышает инвестиционный потенциал и дает возможность
увеличить состояние и богатство нации (рис.1). Поэтому налаживание непрерывного
и бесперебойного производственного процесса, поддержание стабильности и
устойчивости экономического развития, повышение уровня жизни населения требуют
формирования системы страховой защиты.
Рисунок 1. Страхование, как способ обеспечения
будущего
Страховая компания — определенная общественная
форма функционирования страхового фонда, представляющая собой обособленную
структуру, осуществляющую заключение договоров страхования и их обслуживание.
Страховой компании свойственны
технико-организационное единство и экономическая обособленность ее ресурсов, их
самостоятельный полный оборот. Страховая компания функционирует в экономической
системе в качестве самостоятельного хозяйствующего субъекта и «встроена» в
определенную систему производственных отношений. Экономически обособленные
страховые компании строят свои отношения с другими страховщиками на основе
перестрахования и соцстрахования.
Новая роль страховых компаний заключается в том,
что они все больше выполняют функции специализированных кредитных институтов —
занимаются кредитованием определенных сфер и отраслей хозяйственной
деятельности. Страховые компании занимают ведущие после коммерческих банков
позиции по величине активов и по возможности применения их в качестве ссудного
капитала. Характер аккумулируемых ими ресурсов позволяет использовать их для
долгосрочных производственных капиталовложений через рынок ценных бумаг. Такими
возможностями банки, опирающиеся на сравнительно краткосрочно привлекаемые
средства, не располагают. Поэтому страховые компании могут занять ведущее
положение на рынке капиталов.
Страховые компании подразделяются на ряд типов.
·Акционерные страховые общества, т. е. формы
организации страховых фондов на основе централизации денежных средств
посредством продажи акций.
·Перестраховочные компании, осуществляющие
вторичное страхование наиболее крупных и опасных рисков.
·Общества взаимного страхования, предусматривающие
организацию страхового фонда на основе централизации средств посредством
паевого участия его членов, создание, как правило, союзов средних и крупных
собственников (домовладельцев, собственников гостиниц и т. д.).
·Государственная страховая компания
публично-правовая форма организации страхового фонда, основанная государством.
·Негосударственный пенсионный фонд — особая
форма организации личного страхования, гарантирующая рентные выплаты
страхователям по достижении ими пенсионного возраста. В странах с развитой
экономикой пенсионные фонды являются не только источником существенных
инвестиций, но и неотъемлемым элементом системы «встроенных стабилизаторов»,
сглаживающих влияние экономических циклов на социальную сферу.
Страховой рынок — это особая
социально-экономическая среда, определенная сфера экономических отношений, где
объектом купли-продажи выступает страховая защита, формируются спрос и
предложение на нее (рис. 2).
Рисунок 2. Схема страхового рынка
Страховой рынок тесно связан со всеми звеньями
процесса воспроизводства. Будучи составной частью экономики, страховой рынок
отражает состояние и уровень развития производительных сил общества и в то же
время активно влияет на развитие экономики. Страховые рынки подразделяются по
отраслевому признаку, по масштабам — на национальный, региональный и
международный.
1.3 Функции и роль страхования как экономической
категории
В странах с развитой рыночной экономикой
страхование играет важную и многоплановую роль. Можно выделить четыре функции
страхования: функцию возмещения убытков, социальную, инвестиционную и
предупредительную.
Через механизм страхования возмещается
значительная доля убытков, возникших вследствие пожаров, стихийных бедствий,
техногенных катастроф и других случайных событий неблагоприятного характера.
Тем самым страхование выполняет функцию возмещения убытков.
Получаемое от страховых компаний возмещение
обычно направляется на восстановление (а при использовании дополнительных
средств страхователей — и на модернизацию) утраченных и поврежденных
материальных ценностей, что, в конечном счете, способствует экономическому
росту.
Страхование широко используется для решения
социальных проблем общества, т. е. оно выполняет социальную функцию. Данная
роль страхования проявляется в нескольких аспектах. Прежде всего, страховые
организации оказывают большую помощь застрахованным при утрате трудоспособности
и наступлении инвалидности в результате несчастных случаев и заболеваний.
Страховые компании финансируют лечение и реабилитацию потерпевших, компенсируют
последним утраченные доходы. В случае смерти застрахованного его близким
выплачиваются средства, которые позволяют не снижать достигнутый уровень жизни.
Выплаты гражданам возмещения за утраченное или поврежденное имущество также
способствуют сохранению достигнутого ими уровня материального достатка. Тем
самым страхование исполняет роль стабилизатора уровня жизни граждан.
В последние годы существенно возрастает роль
страхования в пенсионном обеспечении. Сокращение рождаемости и рост
продолжительности жизни в развитых странах привели к уменьшению численности
работающего населения и увеличению числа пенсионеров. Многие страны испытывают
трудности при реализации государственных пенсионных программ, построенных на распределительном
принципе. Государственные расходы на пенсионное обеспечение и так слишком
велики, и дальнейший их рост просто невозможен. В создавшейся ситуации договоры
пенсионного страхования, заключаемые за счет средств граждан или их
работодателей, с одной стороны, повышают уровень жизни пенсионеров, а с другой
— снижают финансовую нагрузку на государство.
Далее, страхование способствует реализации
сберегательных потребностей населения. Многие крупные расходы (например,
связанные с приобретением жилья, автомобиля, затратами на образование) граждане
не могут осуществить за счет своих текущих доходов, поэтому они нуждаются в
накоплении денежных средств. Одним из способов организации таких накоплений
является заключение договоров страхования жизни. Кроме того, страховые
организации являются работодателями, решая проблему безработицы. В странах с
развитым страховым рынком в страховании занято до 1% трудоспособного населения.
С помощью страхования мобилизуются накопления
для развития национальной экономики. Тем самым страхование выполняет
инвестиционную функцию. Общеизвестно, что страны, которые смогли больше
накопить, имеют тенденцию к более быстрому экономическому росту. В отличие от
коммерческих банков, которые специализируются на привлечении средств на короткий
период, страховые организации (особенно компании по страхованию жизни)
располагают полученными в виде страховых взносов средствами в течение
длительного времени (10 и более лет). В связи с этим в экономически развитых
странах страховые компании являются крупнейшими инвесторами. Стабильный приток
денежных средств, долгосрочность обязательств страховых организаций сделали их
идеальным источником «длинных денег» для бизнеса и правительства.
С помощью страхования обеспечивается снижение
вероятности наступления различных неблагоприятных событий, и уменьшаются убытки
от проявления таких событий, тем самым страхование выполняет предупредительную
функцию. Данная функция страхования проявляется в двух аспектах.
Во-первых, часть получаемых взносов по договорам
страхования страховые организации направляют на формирование специальных
резервов предупредительных мероприятий. Средства из этих резервов используются
для финансирования мер, направленных на предотвращение аварий, пожаров,
стихийных явлений природы, несчастных случаев, болезней.
Во-вторых, предупредительная функция страхования
проявляется в том, что страховые организации требуют от своих клиентов, чтобы
они сами осуществляли определенные меры, направленные на снижение вероятности
наступления событий, от которых заключаются договоры страхования.
Применение информационных систем в сфере
страхования
Страхование является одним из самых
информационно насыщенных и информационно зависимых видов бизнеса.
Развитие в нашей стране рыночных отношений,
включение в мировые интеграционные процессы заставляет уже сегодня приближаться
к требованиям мировых стандартов. Возрастают требования к объективной оценке
финансового положения предприятий, координации стратегий, что направлено на
снижение финансовых рисков и получение конкурентных преимуществ.
Это обусловливает необходимость внедрения в
процесс страхования автоматизированных информационных технологий.
Внедрение информационных технологий в процесс
планирования и управления деятельностью страховых компаний предусматривает не
только обработку больших и взаимосвязанных массивов данных, но может
использоваться также для их анализа и обоснований вариантов управленческих
решений. При этом важную роль играют учет разнообразных сведений о секторах
экономики, регионе, фирме и других хозяйствующих субъектах, а также учет
финансовых, трудовых и материальных ресурсов.
Объемы информации, высокие требования к точности
и достоверности, необходимость эффективного анализа финансового состояния
клиентуры и страховой фирмы — вот основные причины, предопределяющие
автоматизацию страхового бизнеса.
С внедрением вычислительной техники в страховую
деятельность страховые задачи стали обрабатываться с использованием всего
многообразия технических средств, например, калькулятор для расчета страховой премии
по КАСКО (рис.3).
Рисунок 3. Калькулятор КАСКО
Автоматизация задач страхового дела зависит в
первую очередь от изменения форм взаимодействия машины и пользователя. На
начальных этапах применения ЭВМ преимущественно решались задачи, формирующие
сводные данные о результатах деятельности страховой организации за отчетный
период. ЭВМ использовались в режиме пакетной обработки, что вызывало задержку в
принятии решений и исключало работу страховщиков с клиентами в реальном
масштабе времени.
Положение изменилось в настоящее время, когда
значительная часть работающих в страховых компаниях компьютеров представляет
собой один из типов распределенных вычислительных систем. Распределенные
системы в страховой деятельности строятся на базе АРМ специалиста, соединенных
каналами связи в вычислительные сети многопроцессорных компьютеров и
многомашинных вычислительных комплексов.
Автоматизированные рабочие места оснащены
персональными компьютерами и прикладными программами, предназначенными для
реализации отдельных функций (расчет заработной платы, учет страховых полисов)
или блоков функций, например бухгалтерских операций, инвестиций и т.п. Все АРМ
подсоединены к единой технологической платформе, работающей на базе более
мощного сервера. При такой схеме электронной обработки информации организуется
многопользовательская работа с разными или одними и теми же программами и
наборами данных. Это позволяет избежать избыточности и противоречивости данных,
а также их потери и искажения. Практикуется ввод данных и одной службой
пользователей из числа сотрудников компании по паролю, т.е. имеющих
соответствующие полномочия для работы с этими данными. Такие возможности в
настоящее время предоставляют автоматизированные информационные технологии страховой
деятельности достаточно широко.
Появление подобных систем, реализующих задачи в
области финансово-кредитной деятельности, объясняется, в первую очередь, тем,
что эти системы потенциально имеют лучшее соотношение
«производительность/стоимость». Технический прогресс привел к появлению дешевых
и мощных ПЭВМ и высокоскоростных средств связи. Страховым компаниям стало
выгодно покупать несколько компьютеров среднего класса и связывать их в сеть,
что обеспечивает быстрое техническое оснащение вновь создаваемых в рыночных
условиях страховых компаний.
Широкое использование распределенных
вычислительных систем в страховом деле предопределили характер самих прикладных
задач и организацию их решения. Сотрудники, отделы, филиалы страховой компании,
отдельные потребители информации (агенты, брокеры), как правило, рассредоточены
по некоторой территории. Эти пользователи достаточно автономно решают свои
задачи, поэтому заинтересованы в использовании собственных вычислительных
ресурсов. Однако решаемые ими задачи тесно взаимосвязаны, поэтому их
вычислительные средства должны быть объединены в единую систему. Адекватным
решением в такой ситуации является лишь использование вычислительных сетей
(локальных, открытых, глобальных).
Очевидное преимущество распределенных систем —
принципиально более высокая надежность, необходимая избыточность информации.
Надежность здесь понимается, как способность
системы выполнять свои функции при отказах отдельных элементов аппаратуры и
неполной доступности данных. Основой повышенной надежности распределенных
систем является обоснованная избыточность информации.
Избыточность хранимых данных страховой компании
проявляется, например, в том, что в распределенных базах некоторые наборы
данных могут дублироваться на запоминающих устройствах нескольких серверов, так
что при отказе одного из них данные все равно остаются доступными.
Для филиалов страховой компании кроме надежности
и избыточности, распределенные системы дают возможность совместного
использования информационных, программных и технических ресурсов, обеспечивают
средства связи с другими филиалами, а также гибкость распределения работ по
всей системе.
Применение распределенных систем порождает
необходимость решения ряда проблем, которые связаны, прежде всего, с
организацией эффективного взаимодействия отдельных их частей.
Во-первых, это сложности, обусловленные
программным обеспечением: выбор операционной системы, языков программирования и
прикладных программ; обучение сотрудников страховой компании работе в
распределенной среде; определение и разграничение функций пользователей.
Во-вторых, проблемы, вытекающие из соединения
компьютеров в сеть: предусматриваются средства зашиты от потери сообщений,
например из-за перегрузки сети; требуются связанные с большими затратами
специальные меры по повышению пропускной способности, защите информации.
В-третьих, это вопросы обеспечения коммерческой
тайны, которые гораздо сложнее решаются в системе, допускающей работу ряда
пользователей одновременно. В некоторых случаях, когда для страховой компании
безопасность отдельных видов страхования особенно важна, приходится
отказываться от включения ПЭВМ и АРМ специалиста в распределенную
информационно-вычислительную систему компании.
Использование вычислительных сетей в страховой
деятельности в то же время приводит к повышению эффективности работы за счет
сокращения сроков обработки информации, увеличения аналитических возможностей,
что выражается, прежде всего, в увеличении прибыли компании. Именно благодаря
внедрению автоматизированных информационных систем и технологий в страховое
дело обеспечивается повышение конкурентоспособности страховых услуг,
увеличивается доля компании на страховом рынке.
Рассмотрим более детально, какие новые
возможности получает страховая компания, строящая свою работу в условиях вычислительной
сети.
Прежде всего, использование сети приводит к
улучшению коммуникаций, т.е. к улучшению процесса обмена информацией и
взаимодействия между сотрудниками компании, а также ее клиентами. Сеть
позволяет сотрудникам, находящимся в различных офисах, работать на единой
технологической платформе, с общей информационной базой и взаимодействовать как
с файл-сервером, так и с другими узлами сети.
Получая легкий и более полный доступ к
информации, сотрудники принимают обоснованные решения за счет высокой степени
ее достоверности и оперативности, наличие сети уменьшает потребность страховой
компании в других формах передачи информации, таких, как телефон или обычная
почта. Таким образом достигается не только обоснованность выводов, повышение
точности, достоверности результатов, но и уменьшение временных, трудовых и
стоимостных затрат на принятие решений, улучшается обслуживание клиентов
страховых компаний.
Не менее важным является возможность лучшего
использования дорогостоящих ресурсов, таких, как серверы ПЭВМ большой мощности,
цветные принтеры, модемы, оптические диски, которые создают неограниченные
возможности специалисту для аналитической работы. Пользователь вычислительной
сети — работник страховой компании — работает за своим компьютером и не придает
значения тому, что он пользуется данными мощного компьютера-сервера,
находящегося нередко за сотни километров от его АРМ, а отправляет почту через
модем, подключенный к коммуникационному серверу, общему для нескольких
подразделений компаний или даже включающему обслуживание предприятия. У
пользователя создается иллюзия, что эти ресурсы подключены непосредственно к
его компьютеру, так как для их использования от него требуется совсем немного
дополнительных усилий.
Наконец, сети предоставляют страховой компании
свободу в выборе мест территориального расположения ее филиалов, т. е.
позволяют компаниям располагать не только филиалы, но и рабочие места
страховщиков и специалистов там, где они наиболее эффективны для выполнения
страховых операций. Здесь немаловажное значение имеет и широкое использование
страховщиками переносных (мобильных) компьютеров.
Основные понятия базы данных
База данных — это организованная структура,
предназначенная для хранения информации. В современных базах данных хранятся не
только данные, но и информация.
С понятием базы данных тесно связано понятие
системы управления базой данных. Это комплекс программных средств,
предназначенных для создания структуры новой базы, наполнение ее содержимым,
редактирование содержимого и визуализации информации. Под визуализацией
информации базы понимается отбор отображаемых данных в соответствии с заданным
критерием, их упорядочение, оформление и последующая выдача на устройства
вывода или передачи по каналам связи.
В мире существует множество систем управления
базами данных. Несмотря на то, что они могут по-разному работать с разными
объектами и предоставляют пользователю различные функции и средства,
большинство СУБД опираются на единый устоявшийся комплекс основных понятий.
Например, СУБД Microsoft Access, входящая в пакет Microsoft Office (рис.4).
Рисунок 4. Microsoft Office Access 2007
Можно определить базу данных как физическое
пространство (место на внешнем носителе компьютера), на котором в строго
определенном порядке записываются и хранятся конкретные значения реквизитов
(данные) первичных информационных форм, относящиеся к одному роду объектов
учета. Здесь особо следует подчеркнуть однородность каждой базы данных,
например, для накопления информации об автотранспорте, похищенных вещах и т.п.
В базе данных хранятся данные, предназначенные
для совместного использования. Здесь особо выделяется возможность совместного
использования информации хранящейся в базе данных многими пользователями
одновременно. Многопользовательский режим доступа к данным, хранящимся в базе,
может быть организован различными способами:
использование в сети файл-серверов, на которых
физически хранятся вся база данных. При такой организации каждый пользователь
работает с базой данных так, как будто она размещена на собственном компьютере.
Недостатком такой организации многопользовательской БД является большая
нагрузка на каналы связи т. к. при обслуживании запроса порции данных
считываются с диска центрального компьютера (файл-сервера) небольшими порциями
и передаются на рабочее место, где происходит их обработка;
технология клиент-сервер, при которой вся
обработка информации, все транзакции, задаваемые пользователями, выполняется
самим сервером, а на рабочие станции передаются только результаты. К пропускной
способности каналов связи в этом случае предъявляются значительно меньшие
требования, однако центральный компьютер, обслуживающий базу данных, должен
быть значительно мощнее, чем в первом варианте. При этом, рабочие станции могут
быть бездисковыми терминалами;
распределенная структура, когда части
(фрагменты) одной базы данных физически находятся на различных серверах сети.
По такому принципу строятся глобальные информационные системы типа Internet.
Для создания и обслуживания таких систем
используется специализированное программное обеспечение — системы управления
базами данных СУБД.
К основным функциям СУБД любого типа можно
отнести:
создание (конструирование) базы данных путем
описания структуры хранимой информации и взаимосвязей между ее частями;
занесение, хранение и удаление информации из
базы данных — т.е. поддержание БД в актуальном состоянии;
обслуживание выборок и запросов пользователей.
Различные СУБД позволяют создавать и обслуживать
базы данных различной структуры: иерархические, сетевые и т.д. Наибольшее
распространение получили так называемые реляционные БД. Реляционные базы данных
представляют собой набор связанных таблиц и ничего кроме них. Термин
«реляционная» указывает на то, что между таблицами базы данных могут быть установлены
различные отношения. РСУБД составляют один из крупных сегментов рынка баз
данных: они включают все от систем клиент-сервер до настольных систем.
Как отмечалось выше, реляционная модель БД
рассматривает все данные как группы таблиц или отношений, которые содержат
фиксированные количества рядов и столбцов. Иными словами многие объекты,
используемые в реляционной базе данных, аналогичны объектам электронных таблиц.
Рассмотрим основные термины и определения связанные с РСУБД.
Поле — базовый элемент любой базы данных, не
обязательно реляционной. Поля это элементарный информационный объект базы
данных. В данном случае, «элементарный», означает, что поле не может быть
разбито на более мелкие порции информации. Каждое поле в таблице должно иметь
уникальное имя, удовлетворяющее соглашениям об именах объектов в Access. Оно
является комбинацией из букв, цифр, пробелов и специальных символов, за
исключением точки, восклицательного знака, надстрочного знака и квадратных
скобок. Имя не может начинаться с пробела и содержать управляющие символы с
кодами ASCII от 00 до 31. Максимальная длина имени — 64 символа.
В Access допускается использование девяти типов
данных. Раскрывающийся список возможных типов данных вызывается нажатием кнопки
списка при выборе типа данных каждого поля:
Текстовый — тип данных по умолчанию. Текст или
цифры, не участвующие в расчетах. Число символов в поле не должно превышать
255. Максимальное число символов, которое можно ввести в поле, задается в
свойстве Размер поля. Пустые символы в неиспользуемой части поля не
сохраняются.
Поле MEMO Длительный текст, например, некоторое
описание или примечание. Максимальная длина — 65 535 символов.
Числовой. Числовые данные, используемые в
математических вычислениях. Конкретные варианты числового типа и их длина
задаются в свойстве Размер поля. Поле может иметь размер 1, 2, 4 или 8 байт (16
байт- только если для свойства Размер поля задано значение Код репликации). Для
проведения денежных расчетов определен другой тип данных — Денежный.
Денежный. Денежные значения и числовые данные,
используемые в расчетах, проводящихся с точностью до 15 знаков в целой и до 4
знаков — в дробной части. Длина поля 8 байт. При обработке числовых значений из
денежных полей выполняются вычисления с фиксированной точкой (более быстрые,
чем вычисления для полей с плавающей точкой). Кроме того, при вычислениях
предотвращается округление. Учитывая эти обстоятельства, применительно к полям,
в которых планируется хранить числовые значения с указанной точностью,
рекомендуется использовать денежный тип данных.
Дата/время. Значения даты или времени,
относящиеся к годам с 100 по 9999 включительно Длина поля 8 байт
Счетчик. Тип данных поля, в которое для каждой
новой записи автоматически вводятся уникальные последовательно возрастающие (на
1) целые числа или случайные числа. Значения этого поля нельзя изменить или
удалить. Длина поля: 4 байта для длинного целого, для кода репликации — 16
байт. По умолчанию в поле вводятся последовательные значения. В таблице не
может быть более одного поля этого типа. Используется для определения
уникального ключа таблицы
Логический. Логические данные, которые могут
иметь одно из двух возможных значений: Да/Нет, Истина/Ложь, Вкл./Выкл. Длина
поля 1 бит.
Поле объекта OLE. Объект (например, электронная
таблица Microsoft Excel, документ Microsoft Word, рисунок, звукозаписи или
другие данные и двоичном формате), связанный или внедренный и таблицу Access.
Длина поля — не более 1 Гбайт (ограничивается объемом диска).
Гиперссылка. Адрес гиперссылки, включающий путь
к файлу на жестком диске в локальной сети (в формате UNC) или адрес страницы в
Internet или Intranet (URL). Кроме того, адрес может включать текст, выводимый
в поле или в элементе управления, дополнительный адрес — расположение внутри
файла или страницы, подсказку — текст, отображаемый в виде всплывающей
подсказки. Если щелкнуть мышью на поле гиперссылки, Access выполнит переход на
соответствующий объект, документ, Web-страницу или другое место назначения.
Длина каждой из частей гиперссылки — не более 2048 знаков. Для полей типа OLE,
MEMO и Гиперссылка не допускается сортировка и индексирование.
Мастер подстановок. Выбор этого типа данных
запускает мастера подстановок. Мастер строит для поля список значений на основе
полей из другой таблицы. Значения в такое поле будут вводиться из списка.
Соответственно, фактически тип данных поля определяется типом данных поля
списка. Возможно также определение поля со списком постоянных значений.
Запись — набор данных специфицирующих некоторый
объект. Например, в БД автотранспортных средств каждая запись содержит сведения
о транспортном средстве (госномер, марку, год выпуска, № кузова и т.п.). Каждая
запись БД содержит уникальный набор информации — в нашем примере, каждая запись
представляет данные о конкретном транспортном средстве. В РСУБД записи не
хранятся в каком либо порядке набора. Иными словами в концепции РСУБД вообще не
существует номера записи, как в системах другого типа.
Таблица — это набор полей. Данные, содержащиеся
в таблице, хранятся в виде записей. Каждая таблица базы данных представляет
некоторый тип хранящихся в ней объектов. В БД может быть любое количество
таблиц, между которыми могут быть установлены различные отношения. Тот факт,
что таблица представляет только один тип объекта, отнюдь не является недостатком.
Наоборот, это один из ключей к созданию эффективной базы данных.
Ключевое поле — это поле, которое используется
для связи между двумя и более таблицами. Ключи — это поля, которые являются
общими для связываемых таблиц. При этом значение этих полей в связанных
таблицах дублируется. Ключи могут быть первичными, внешними или составными.
Позже мы рассмотрим эти типы ключей.
Отношение — это связь, устанавливаемая между
двумя и более таблицами посредством ключевого поля. Принципиально возможны три
типа отношений: один-к-одному, один-к-многим и многие-к-многим.
Соединение — виртуальная таблица, создаваемая,
когда пользователь запрашивает информацию из различных таблиц связанных
отношением. Ключевые поля в этом случае используются для поиска соответствующих
записей в различных таблицах, из которых формируется соединение.
Первичный ключ — уникально идентифицирует каждую
запись в таблице и не имеет повторяющихся значений. Выбор поля в качестве
первичного ключа — одно из важнейших решений принимаемых при проектировании БД.
Если запись в таблице не может быть однозначно
идентифицирована каким-либо одним полем, то можно использовать составной ключ —
группу полей. Составные ключи используются значительно реже первичных.
Внешний ключ — это поле (или группа полей) одной
таблицы, для которого имеется дублированное значение в другой, связанной
таблице. В отличие от первичных ключей, внешние ключи зачастую многократно
повторяются при установлении отношения один-к-многим.
Состав и функции систем управления базами данных
База данных предполагает наличие комплекса
программных средств, обслуживающих эту базу данных и позволяющих использовать
содержащуюся в ней информацию. Такие комплексы программ называют СУБД.
СУБД — это программная система, поддерживающая
наполнение и манипулирование данными, представляющими интерес для пользователей
при решении прикладных задач. Иными словами, СУБД является интерфейсом между
базой данных и прикладными задачами.
Ниже перечислены основные функции СУБД.
. Определение данных — определить, какая именно
информация будет храниться в базе данных, задать свойства данных, их тип
(например, число цифр или символов), а также указать, как эти данные связаны
между собой. В некоторых случаях есть возможность задавать форматы и критерии
проверки данных.
. Обработка данных — данные могут обрабатываться
самыми различными способами. Можно выбирать любые поля, фильтровать и
сортировать данные. Можно объединять данные с другой, связанной с ними,
информацией и вычислять итоговые значения.
. Управление данными — можно указать, кому
разрешено знакомиться с данными, корректировать их или добавлять новую
информацию. Можно также определять правила коллективного доступа.
Входящие в состав современных СУБД средства
совместно выполняют следующие функции:
• описание данных, их структуры (обычно описание
данных и их структуры происходит при инициировании новой базы данных или
добавлении к существующей базе новых разделов (отношений); описание данных
необходимо для контроля корректности использования данных, для поддержания целостности
базы данных);
• первичный ввод, пополнение информации в базе
данных;
• удаление устаревшей информации из базы данных;
• корректировку данных для поддержания их
актуальности;
• упорядочение (сортировку) данных по некоторым
признакам;
• поиск информации по некоторым признакам (для
описания запросов имеется специальный язык запросов, он обеспечивает также
интерфейс между базой данных и прикладными программами пользователей, позволяет
этим программам использовать базы данных);
• подготовку и генерацию отчетов (средства
подготовки отчетов позволяют создавать и распечатывать сводки по заданным
формам на основе информации базы данных);
• защиту информации и разграничение доступа
пользователей к ней (некоторые разделы базы данных могут быть закрыты для
пользователя совсем, открыты только для чтения или открыты для изменения; кроме
того, при многопользовательском режиме работы с базой данных необходимо, чтобы
изменения вносились корректно; для сохранения целостности данных служит
механизм трансакций при манипулировании данными — выполнение манипуляций
небольшими пакетами, результаты каждого из которых в случае возникновения
некорректности операций “откатываются” и данные возвращаются к исходному
состоянию);
• резервное сохранение и восстановление базы
данных, которое позволяет восстановить утраченную при сбоях и авариях
аппаратуры информацию базы данных, а также накопить статистику работы
пользователей с базой данных;
• поддержку интерфейса с пользователями, который
обеспечивается средствами ведения диалога (по мере развития и совершенствования
СУБД этот интерфейс становится все более дружественным; дружественность
существующих средств интерфейса предполагает
• наличие развитой системы помощи (подсказки), к
которой в любой момент может обратиться пользователь, не прерывая сеанса работы
с компьютером и базой данных;
• защиту от необдуманных действий,
предупреждающую пользователя и предотвращающую потерю информации в случае
поспешных или ошибочных команд;
• наличие нескольких вариантов выполнения одних
и тех же действий, из которых пользователь может выбрать наиболее удобные для
себя, соответствующие его подготовке, квалификации, привычкам;
• тщательно продуманную систему ведения
человеко-машинного диалога, отображение информации на дисплее, использование
клавиш клавиатуры). В настоящее время выделяют пять уровней проблематики систем
управления базами данных:
• реляционные базы данных, 1970 — 90 гг.;
• объектно-ориентированные базы данных, 1980 —
90 гг.;
• интеллектуальные базы данных, 1985 — 90 гг.;
• распределенные базы данных, начало 1990 гг.;
• базы данных мультимедиа и виртуальной
реальности настоящего времени.
Архитектурно СУБД состоит из двух основных
компонентов; языка описания данных (ЯОД), позволяющего создать схему описания
данных в базе, и языка манипулирования данными (ЯМД), выполняющего операции с
базой данных (наполнение, обновление, удаление, выборку информации). Данные
языки могут быть реализованы в виде тренажеров или интерпретаторов. Помимо ЯОД
и ЯМД к СУБД следует отнести средства (или языки) подготовки отчетов (СПО),
позволяющие подготовить сводки (отчеты) на основе информации, найденной в базе
данных, по заданным формам.
Язык описания данных (ЯОД) — это язык высокого
уровня декларативного (непроцедурного) типа, предназначенный для
формализованного описания типов данных, их структур и взаимосвязей. Исходные
тексты описания данных на этом языке после трансляции отображаются в
управляющие таблицы, задающие размещение в памяти ЭВМ и связи между собой
рассматриваемых данных. В соответствии с этими описаниями СУБД находит в базе
требуемые данные, правильно преобразует их и передает, например, в прикладную
программу пользователя, которой они потребовались. При записи данных в базу
СУБД по этим описаниям определяет место в памяти ЭВМ, куда их требуется поместить,
преобразует к заданному виду и устанавливает необходимые связи.
Язык манипулирования данными (или язык запросов)
представляет собой систему команд, например, следующего типа:
• произвести выборку данного, значение которого
удовлетворяет заданным условиям;
• произвести выборку всех данных определенного
типа, значения которых удовлетворяют заданным условиям;
• найти в базе позицию данного и поместить туда
новое значение (или удалить данное) и т.д.
Широкое распространение имеют СУБД для
персональных компьютеров типа DBASE (DBASE III, IV, FoxPro, Paradox), Clipper,
Clarion. Эти СУБД ориентированы на однопользовательский режим работы с базой
данных и имеют очень ограниченные возможности. Языки подобных СУБД представляют
собой сочетание команд выборки, организации диалога, генерации отчетов. В связи
с развитием компьютерных сетей, в которых персональные компьютеры выступают в
качестве развитых (интеллектуальных) терминалов, новые версии СУБД все в
большей степени включают в себя возможности описанного ниже языка
манипулирования данными SQL.
В последнее время стали среди СУБД популярными
ACCESS (входит в состав MS Office), Lotus, Oracle.
Свойства полей базы данных
Поля базы данных не просто определяют структуру
базы — они еще определяют групповые свойства данных, записываемых в ячейки,
принадлежащие каждому из полей. Ниже перечислены основные свойства полей таблиц
баз данных на примере СУБД Microsoft Access.
Имя поля — определяет, как следует обращаться к
данным этого поля при автоматических операциях с базой (по умолчанию имена
полей используются в качестве заголовков столбцов таблиц).
Тип поля — определяет тип данных, которые могут
содержаться в данном поле (рис.5).
Рисунок 5. Типы данных полей
Размер поля — определяет предельную длину (в
символах) данных, которые могут размещаться в данном поле. Для поля с типом
данных Текстовый задается размер от 1 до 255 знаком (по умолчанию — 50 знаков).
Для поля с типом данных Счетчик можно задать:
Длинное целое- 4 байта:
Код репликации- 16 байт.
Для поля с типом данных Числовой можно задать:
Байт (для целых чисел от 0 до 255, длина поля 1
байт);
Целое (для целых чисел от -32 768 до +32 767,
занимает 2 байта);
Длинное целое (для целых чисел от -2 147 483 648
до +2 147 483 647, занимает 4 байта);
Дробные с плавающей точкой 4 байта (для чисел от
-3,4хЮ38 до +3,4х1038 с точностью до 7 знаков);
Дробные с плавающей точкой 8 байт (для чисел от
-1,797хЮ308 до +1,797хЮ308 с точностью до 15 знаков);
Действительное (для целых чисел от -1038-1 до
1038-1 при работе с проектами, которые хранятся в файлах типа1 ADP, и от
-1028-1 до 1028-1 — для файлов типа MDB, с точностью до 28 знаков, занимает 12
байт);
Код репликации. Глобальный уникальный
идентификатор, занимает 16 байт. Поля такого типа используются Access для
создания системных уникальных идентификаторов реплик, наборов реплик, таблиц,
записей и других объектов при репликации баз данных.
Рекомендуется задавать минимально допустимый
размер поля, который понадобится для сохраняемых значений, т. к. сохранение
таких полей требует меньше памяти, и обработка данных меньшего размера выполняется
быстрее.
Формат поля — определяет способ форматирования
данных в ячейках, принадлежащих полю. В Access определены встроенные
стандартные форматы отображения для полей с типами данных Числовой, Дата/время,
Логический и Денежный. Ряд этих форматов совпадает с настройкой национальных
форматов, определяемых в окне Язык и стандарты панели управления Microsoft
Windows. Пользователь может создать собственный формат для всех типов данных,
кроме OLE, с помощью символов форматирования.
Для указания конкретного формата отображения
необходимо выбрать и в раскрывающемся списке одно из значений свойства Формат
поля. Формат поля используется для отображения данных в режиме таблицы, а также
применяется в форме или отчете при отображении этих нолей.
Маска ввода — определяет форму, в которой
вводятся данные а поле (средство автоматизации ввода данных).
Подпись — определяет заголовок столбца таблицы
для данного поля (если подпись не указана, то в качестве заголовка столбца
используется свойство Имя поля).
Значение по умолчанию — то значение, которое
вводится в ячейки поля автоматически (средство автоматизации ввода данных). Это
свойство используется только при создании новой записи. Изменение значения
свойства не влияет на существующие записи. Максимальная длина значения свойства
составляет 255 знаков. Данное свойство не определенно для полей с типом данных
Счетчик или Поле объекта OLE.
Условие на значение — ограничение, используемое
для проверки правильности ввода данных (средство автоматизации ввода, которое
используется, как правило, для данных, имеющих числовой тип, денежный тип или
тип даты).
Сообщение об ошибке — текстовое сообщение,
которое выдается автоматически при попытке ввода в поле ошибочных данных.
Обязательное поле — свойство, определяющее
обязательность заполнения данного поля при наполнении базы.
Пустые строки — свойство, разрешающее ввод
пустых строковых данных (от свойства Обязательное поле отличается тем, что
относится не ко всем типам данных, а лишь к некоторым, например к текстовым).
Индексированное поле — если поле обладает этим
свойством, все операции, связанные с поиском или сортировкой записей по
значению, хранящемуся в данном поле, существенно ускоряются. Кроме того, для
индексированных полей можно сделать так, что значение в записях будут
проверяться по этому полю на наличие повторов, что позволяет автоматически
исключить дублирование данных.
Поскольку в разных полях могут содержаться
данные разного типа, то и свойства у полей могут различаться в зависимости от
типа данных. Так, например, список вышеуказанных свойств полей относится в
основном к полям текстового типа. Поля других типов могут иметь или не иметь
эти свойства, но могут добавлять к ним и свои. Например, для данных,
представляющих действительные числа, важным свойством является количество
знаков после десятичной запятой. С другой стороны, для полей, используемых для
хранения рисунков, звукозаписей, видео клипов и других объектов OLE,
большинство вышеуказанных свойств не имеют смысла.
2. ПРАКТИЧЕСКАЯ
ЧАСТЬ
2.1 Анализ страховой компании
Национальная Страховая Группа — одна из ведущих
российских страховых компаний, создана в апреле 1994 года. Компания динамично
развивается, находясь сегодня в первой пятерке крупнейших страховщиков России.
Клиентами Национальной Страховой Группы являются более 2000 организаций
различных форм собственности, и около 150 000 физических лиц.
СОАО «НСГ» реализует 59 залицензированных видов
страхования, в том числе жизни и здоровья граждан, имущества физических и
юридических лиц, различных видов ответственности (в том числе ОСАГО),
коммерческих рисков. Специалистами НСГ разработаны более 50 отличающихся
новизной и перспективами специальных проектов и программ по различным видам страхования.
Среди них программы муниципального страхования жилых и нежилых помещений,
страхования ответственности предприятий источников повышенной опасности,
гидросооружений, грузоперевозок, комбинированного страхования
строительно-монтажных работ.
С 1997 года компания является членом
Всероссийского Союза Страховщиков (ВСС) и Московской Торгово-Промышленной
Палаты, а в 1999 году первой из российских страховых компаний Национальная
Страховая Группа стала членом Международной Торговой Палаты (IСС). С 2000 года
НСГ — член Президиума ВСС, а в 2001 году НСГ стала учредителем и членом
Московской Ассоциации Страховщиков (МАС). С 2002 года НСГ — член Российского
Союза Автостраховщиков.
В 2004 году Национальная Страховая Группа стала
Лауреатом Российской общественной премии в области страхования «Золотая
саламандра». Единственного в своем роде знака качества страховых услуг на
российском страховом рынке в номинации «Личный вклад в развитие страхования»
удостоен Президент НСГ Ю.Н.Решетняк.
В 2005 году СОАО «Национальная Страховая Группа»
удостоена премии «Финансовая элита России» в номинации «За стабильно высокое
качество обслуживания клиентов»
В 2006 году СОАО «Национальная Страховая Группа»
удостоена премии «Финансовая элита России» в номинации «За высокое качество обслуживания».
В 1998 году для повышения эффективности продаж
страховых продуктов компания «НСГ» начала построение мощной региональной сети.
В связи с этим был создан Отдел по страхованию жизни. Этот проект получил
широкое развитие в регионах и в настоящее время охватывает более 1200 городов и
населенных пунктов России.
С 2000 года появились программы долгосрочного
смешанного страхования жизни. В этом же году отдел по страхованию жизни был
переименован в Дирекцию по страхованию жизни.
В 2007 году в связи с исполнением Федерального
закона о специализации страховщиков Дирекция была преобразована в юридическое
лицо — ООО «НСГ Страхование жизни».
Компания «НСГ Страхование жизни» осуществляет
свою деятельность на основании лицензии ФССНС № 387077 от 26.05.2006г.
Уставной капитал 68 000 000 рублей.
Страховые сборы, включая переведенный портфель
из «НСГ» — 453 000 000 рублей.
В 2007 году ООО «НСГ Страхование жизни»
заключила около 19 000 договоров.
Существенную долю 55% в портфели сборов компании
составляет страхование имущества (страхование имущества юридических и
физических лиц технических рисков). Доля ДМС увеличилась до 15%, ОСАГО до 14%,
КАКСКО составило 12%, 3% страхование ответственности и самую малую часть
составляет страхование несчастных случаев (рис. 6, 7, 8).
Рисунок 6. Динамика рынка
страхования, млрд. руб.
Рисунок 7. Структура портфеля СОАО
«Национальная Страховая Группа» 2011 г.
Рисунок 8. Структура портфеля СОАО
«Национальная Страховая Группа» 2010 г.
В стратегических планах компании
«НСГ Страхование жизни» — расширение бизнеса во всех регионах России, создание
новых интересных программ для клиентов, повышение конкурентоспособности за счет
совершенствования страховых продуктов, повышения уровня качества обслуживания,
усовершенствование системы обучения консультантов и, как следствие, увеличение
клиентской базы компании.
Клиенты «НСГ Страхование жизни»
получают страховую защиту международной корпорации, имеющей наивысший рейтинг
надежности. Нашим партнером по перестрахованию является швейцарская компания
«Swiss Re». Заключенные договоры перестрахования обеспечивают наивысшую
финансовую устойчивость компании «НСГ Страхование жизни».
.2 Моделирование условной
практической ситуации
2.2.1 Заключение договора
страхования
Одинцов Вячеслав Юрьевич 25.10.1975
года рождения, проживающий по адресу Кемеровская область, город Новокузнецк,
ул. Строителей, 31-10, заключил договор страхования от несчастных случаев и
болезней 11.04.2012г. сроком на один год, периодом страхования — круглосуточно
и на сумму 100 000 руб. с ООО «НСГ страхование жизнь», находящаяся по адресу
город Новокузнецк, ул. Хитарова, 30. Вячеслав Юрьевич работает менеджером в
магазине «Адмирал», он застраховался на получение страховых выплат на случай
временной или постоянной нетрудоспособности в результате несчастного случая и
на случай смерти. Заполнить заявление и полис, а также отобразить сделку в базе
данных.
Одинцов Вячеслав Юрьевич решил
заключить договор страхования жизни от несчастных случаев и болезней со
страховой компанией «НСГ Страхование жизни». Для заключения договора
страхования страхователь обращается к страховщику с письменным заявлением. В
заявлении указываются основные данные о страхователе, о застрахованном лице и
выгодоприобритателе; страховые риски, от которых застраховывается лицо;
условия, по которым определяется размер страховых выплат; территория действия
договора, период страхования и срок действия договора; указывается
дополнительная информация о застрахованном лице и заполняется медицинская
анкета.
Так как Вячеслав Юрьевич в заявлении
в графе страховые риски указал: временная нетрудоспособность в результате
несчастного случая с выплатой по «Таблице размеров страховых выплат №1»,
постоянная нетрудоспособность в результате несчастного случая с выплатами в размерах:
I группа — 80%, II группа — 60% и III группа — 40%, а так же смерть в
результате несчастного случая, определяем страховую премию по этим рискам.
Страховая премия рассчитывается по
формуле:
P = S * T, (1)
Где P — премия по риску; — страховая
сумма;- итоговый тариф по риску.
Тариф по риску рассчитывается по
формуле:
T = Tб * k, (2)
Где T — итоговый тариф по риску;б —
базовый тариф по риску;- коэффициенты.
Страховая премия по риску «Временная
нетрудоспособность» согласно «Таблице размеров страховых выплат №1» мужчина в
возрасте от 26 до 45 и относящийся к I классу профессионального риска
тарифицируется по коэффициенту — 0,4% (базовый тариф).
Рассчитываем итоговый тариф —
перемножаем базовый тариф, коэффициент, зависящий от срока страхования и
коэффициент территориального действия страхового покрытия:
0,4 * 1 * 1 = 0,4.
000,00 руб. * 0,4 % = 400,00 руб.
Страховая премия по риску
«Постоянная нетрудоспособность» согласно «Таблице размеров страховых выплат
№3»:
100 000,00 руб. * 0,13 % = 130,00
руб.
Страховая премия по риску «Смерть»
согласно «Таблице размеров страховых выплат №4»:
100 000,00 руб. * 0,18 % = 180,00
руб.
Общая страховая премия:
,00 руб. + 130,00 руб. + 180,00 руб.
= 710,00 руб.
2.2.2 Страховой случай
.06.2012 года застрахованный в ООО
«НСГ Страхование жизни» Одинцов Вячеслав Юрьевич получил травму — перелом
малоберцовой кости левой ноги (рис. 9). Эта травма была получена в результате
несчастного случая — на работе на ногу упала коробка с товаром. Он пробыл на
больничном 42 дня. Следует определить сумму страхового возмещения.
Для определения страхового
возмещения следует воспользоваться Условиями страхования от несчастных случаев
и болезней ( ), в которых указаны характер повреждения и размер страховой
выплаты в процентах от страховой суммы. В нашем случае: при переломе
малоберцовой кости размер страховой выплаты составляет 5% от страховой суммы.
000 руб. * 5% = 5 000 руб.
Рисунок 9. Скелет ноги
3. РЕАЛИЗАЦИЯ
ИНФОРМАЦИОННОЙ СИСТЕМЫ В СТРАХОВОЙ ДЕЯТЕЛЬНОСТИ
информационный
страхование таблица база
3.1 Назначение и
функции программной системы
Разработанная база данных «Страховая
компания» предназначена для хранения и дополнения данных о клиентах страховой
компаний и может найти свое применение в страховых компаниях.
Основной функцией является хранение
данных и простота поиска данных о клиентах.
Основные объекты:
Клиенты;
Договор;
Агент;
Виды страхования;
Страховой случай.
Создание таблиц
Для создания таблицы в новой базе
данных нажимаем вкладку Создание и выбираем Конструктор таблиц. В открывшейся
таблице заполняем поля и типы данных.
Первая таблица — «Клиент». Заполняем
таблицу: первое поле — «id клиента», тип данных — Счетчик. Это поле является
ключевым — для этого нажимаем вкладку Конструктор — Ключевое поле. Второе поле
— «Наименование», тип данных является текстовым. Третье — «Адрес», тип данных —
текстовый. Четвертое — «Телефон», тип данных — числовой. Пятое поле — «ИНН»,
тип данных — числовой (рис 7). Переходим в режим таблицы, сохраняем ее и даем
имя. Заполняем таблицу, используя данные «Росгосстрах» (рис 8). Аналогично
выполняем следующие таблицы, так же берем данные со страховой компании «НСГ».
Рисунок 7. Таблица «Клиент» в режиме
Конструктор
Рисунок 8. Заполненная таблица
«Клиент»
Вторая таблица — «Агент». Первое
поле таблицы — «id агента», тип данных — счетчик. Это поле является ключевым.
Второе поле — «id вида страхования», тип данных — числовой. Третье поле —
«ФИО», тип данных — текстовый. Четвертое — «Дата приема на работу», тип данных
— дата/время. Пятое поле — «Адрес», тип данных — текстовый. Шестое — «Серия и
номер паспорта», тип данных — числовой (рис. 9). Заполняем данную таблицу (рис.
10).
Рисунок 9. Таблица «Агент» в режиме
Конструктор
Рисунок 10. Заполненная таблица
«Агент»
Таблица «Вид страхования». Первое
поле является ключевым и называется «id вида страхования», тип данных —
счетчик. Второе поле «Наименование», тип данных — текстовый (рис. 11).Заполняем
данную таблицу (рис. 12).
Рисунок 11. Таблица «Вид
страхования» в режиме Конструктор
Рисунок 12. Заполненная таблица «Вид
страхования»
Таблица «Страховой случай». Первое
поле «id страхового случая», тип данных — счетчик, это поле является ключевым.
Второе поле «id вида страхования», тип данных — числовой. Третье поле
«наименование», тип данных — текстовый. Четвертое поле «Стоимость в год», тип
данных является денежный (рис. 13). Заполняем данную таблицу (рис. 14).
Рисунок 13. Таблица «Страховой
случай» в режиме Конструктор
Рисунок 14. Заполненная таблица
«Страховой случай»
И последняя наша таблица «Договор».
Первое поле в этой таблице тоже является ключевым «id договора», тип данных —
счетчик. Второе поле -«id агента», тип данных — числовой. Третье поле «id
клиента», тип данных — числовой. Четвертое поле «id страхового случая», тип
данных является числовой. Пятое поле — «Дата заключения», тип данных —
дата/время. Шестое — «Срок (лет)», тип данных — числовой (рис. 15). Заполняем данную
таблицу (рис. 16).
Рисунок 15. Таблица «Договор» в
режиме Конструктор
Рисунок 16. Заполненная таблица
«Договор»
Связывания таблиц2007 позволяет
построить реляционные базы данных и отдельные таблицы, которые могут быть
связаны между собой.
Между двумя сущностями, например, А
и В возможны четыре вида связей.
Первый тип — связь один-к-одному: в
каждый момент времени, каждому экземпляру сущности А соответствует 1 или 0
экземпляров сущности В.
Второй тип — связь один-ко-многим:
одному экземпляру сущности А соответствует 0, 1 или несколько экземпляров
сущности В.
Так как между двумя сущностями
возможны связи в обоих направлениях, то существует еще два типа связи —
многие-к-одному и многие-ко-многим. Но в нашей работе мы их использовать не
будем.
Создаем схему данных (вкладка Работа
с базами данных/Схема данных). Добавляем таблицы с помощью выделения и нажатия
на кнопку Добавить. Включив все таблицы в схему данных, закрываем окно
Добавление таблицы.
Для установления связей между парой
таблиц в окне Схема данных мы выделяем уникальное ключевое поле, по которому
устанавливается связь («id агента» в таблице «Договор»), и при нажатой кнопки
мыши протаскиваем курсор в соответствующее поле в таблице «Агент».
В появившимся окне Изменение связей
отмечаем галочкой операции «Объединение целостности данных», «Каскадное
обновление связанных полей» и «Каскадное удаление связанных полей» (рис. 17),
после чего нажимаем кнопку Создать. Аналогично создаем связи с таблицами
«Договор» и «Клиент», «Страховой случай», а так же между таблицами «Виды
страхования» и «Страховой случай» (рис. 18).
Сохраняем внесенные изменения.
Рисунок 17. Установка связи таблиц
Рисунок 18. Схема данных
Запросы
Запросы позволяют выбирать данные из
одной или нескольких связанных таблиц. Результатом выполнения запросов является
результирующая таблица, которая на ряду с другими таблицами может быть
использована при обработке данных. С помощью запросов можно также обновлять,
удалять или добавлять данные в таблицы. Основным значением запросов является
отбор данных по критериям поиска.
Для того чтобы создать запрос «11 и
19» на Панели инструментов выбираем вкладку Создание. Здесь выбираем
Конструктор запросов и открывшемся окне выбираем таблицы, нужные нам для
запроса — «Страховой случай» и «Клиент». В поля заносим «id страхового случая»,
«Наименование клиента « и «Наименование страхового случая».
В условиях отбора столбца «id
страхового случая» пишем номера страховых случаев Смерть и Медицинские расходы,
т.е. 11 и 19, и смотрим получившийся запрос (рис. 19).
Рисунок 19. Запрос «11 и 19»
Аналогично выполняем запрос
«Агенты». Добавляем таблицы «Агенты», «Договор», «Клиенты». В поля заносим «ФИО
агента», «Дата заключения договора», «Наименование клиента» и «Телефон
клиента». В условиях отбора столбца «ФИО агента» пишем фамилии двух страховых
агентов — Галлямова и Нехорошева, в строке Сортировка того же столбца ставим
«по возрастанию». Смотрим получившийся запрос (рис. 20) .
Рисунок 20. Запрос «Агенты»
Формы
Форма — оболочка таблицы или
запроса, обеспечивающая пользователю удобный интерфейс. Использование форм в
большинстве случаев облегчает ввод, редактирование и просмотр данных,
хранящихся в таблице или получаемых с помощью запросов.
Работа с данными в режиме таблицы
имеет существенный недостаток: если полей слишком много, они не умещаются на
экране и приходиться прибегать к различным манипуляциям, чтобы оптимизировать
представление: например, убирать некоторые столбцы, менять их положение.
После создания базы данных (и,
возможно, одной или более страниц) мы можем создать формы для просмотра данных
в более удобном виде. Форма может служить средством защиты базы данных от
неквалифицированных пользователей, а также ширмы, заслоняющей от любопытных
глаз конфиденциальную информацию.
Любая форма строится на основе
Access — таблицы или запросы. Имена полей извлекаются из спецификации таблицы,
а поля в форме можно расположить по своему усмотрению. На основе одной таблицы
можно построить несколько форм.
Существует несколько разновидностей
автоформ:
Форма — создание формы для ввода
данных по одной записи за раз.
Раздельная форма — создание
разделенной формы, в верхней части, в которой отображается таблица, а в нижней
— форма для ввода данных в запись, выделенную в таблице.
Несколько элементов — создание
формы, в которой записи отображаются в виде таблицы, при этом каждая запись
занимает отдельную строку.
Форму «Клиент» мы сделали следующим
образом: на Панели инструментов выбираем вкладку Формы/Другие формы/Мастер
форм. В появившемся окне выбираем таблицу «Клиенты» выбираем все поля из списка
доступных полей, нажимаем Далее. Выбираем внешний вид формы (ленточный), далее
выбираем стиль нашей формы, снова нажимаем Далее и задаем название формы и
Готово.
Для того чтобы в форме можно было
вызывать другие формы таблиц, создаем соответствующие кнопки управления в
основной части формы. На вкладке Конструктор на панели инструментов Элементы
управления нажимаем инструмент «Кнопка». После переноса кнопки курсором мыши в
нужное место формы (в правой части формы) и вычерчивания ее рамки запускается
Мастер создания кнопок. В окне мастера нужно выбрать действия, которое будет
выполнятся при нажатии кнопки. В группе «Категория» выбираем «Работа с формой»,
а в группе «Обработка записей» выбираем «Добавить запись» (рис. 21).
Рисунок 21. Создание кнопки
Нажимаем кнопку Далее. Выбираем имя
таблицы, которая будет нажимать данная кнопка, нажимаем Далее. Следующий шаг
подтвердить «Открыть форму и показать все записи». На кнопке размещаем текст,
соответствующий названию таблицы, открываемой кнопкой. На следующем шаге
повторяем название таблицы для имени кнопки, нажимаем Готово. Аналогично
создаем формы для всех таблиц: «Агенты», «Вид страхования», «Страховой случай»
и «Договор» (рис. 22).
Рисунок 22. Форма «Клиент»
В «Договоре» операцию с кнопками
производим немного по-другому. Мы добавляем к тем же кнопкам еще, и «Открыть
форму» (рис. 23) — их должно быть четыре, т.к. форма «Договор» является
центровой (рис. 24).
Рисунок 23. Создание кнопки
Рисунок 24. Форма «Договор»
Теперь создадим Главную кнопочную
форму «Росгосстрах», она будет содержать таблицы «Агент», «Клиент», «Договор»,
«Вид страхования» и «Страховой случай». Для этого на вкладке Работа с базами данных
выбираем команду Диспетчер кнопочных форм. На появившийся о том, что не удается
найти кнопочную форму, отвечаем Да. В появившимся окне нажимаем кнопку Создать,
даем имя нашей форме — «Росгосстрах» (рис. 25).
Рисунок 25. Диспетчер кнопочных форм
После создания новой формы нажимаем
кнопку Изменить. Следующим нашим шагом будет создание новых элементов формы —
Клиент, Договор, Агент, Страховой случай, Виды страхования, Выход (рис. 26).
Рисунок 26. Элементы кнопочной формы
При создании элемента «Клиент» мы
заполнили графу текст, определили команду и форму, которую этот элемент
открывает (рис. 27).
Рисунок 27. Заполнение элемента
«Клиент»
Тем же способом создаем оставшиеся
элементы. Заполнение элемента «Договор» показано на рис. 28.
Рисунок 28. Заполнение элемента
«Договор»
Элемент «Агенты» (рис. 29):
Рисунок 29. Заполнение элемента
«Агенты»
Те же действия проделываем и с
другими элементами (рис. 30, 31, 32):
Рисунок 30. Заполнение элемента
«Страховой случай»
Рисунок 31. Заполнение элемента
«Виды страхования»
Рисунок 32. Заполнение элемента
«Выход»
И получаем главную кнопочную форму
«Национальная Страховая Группа Страхование жизни» (рис. 33).
Рисунок 33.Готовая кнопочная форма
«Национальная Страховая Группа Страхование жизни»
Отчеты
Отчеты предназначены для
формирования выходных документов и вывода их на печать. По своим свойствам и
структуре отчеты во многом подобны формам. Основное их отличие заключается в
том, что в отчете отображаются все данные и в них предусмотрена возможность
группировать данные по различным критериям. Отчеты в отличие от форм могут
содержать специальные элементы оформления, характерные для печати документов:
колонтитулы, номера страниц и т.д.
Отчеты, так же как и формы, можно
создавать с помощью конструктора или мастера отчетов. Используется также
автоматическое создание отчетов.
Последовательность действий при
формировании отчета с помощью мастера такая же, как и при создании формы.
Дополнительными являются два шага: добавления уровня группировок и задания
требуемого порядка сортировки. Добавления уровня группировки позволяет выводить
записи, объединенные по выбранным полям.
По каждой из групп при необходимости
можно подводить итоги. Для получения итоговых значений по числовым полям
необходимо после добавления уровня группировки в диалоговом в диалоговом окне
создание отчетов щелкнуть на кнопке итоги, после чего для соответствующего
числового поля выбрать требуемые функции. При выборе функции суммы для
какого-либо поля Access не только подсчитает автоматически подсчитает сумму
значений для каждой группы, но и подведет итоги по всем записям выбранного
поля. Программа предусматривает вывод как данных (записей) и итогов, так и
только итогов. Если не задан уровень группировки, то кнопка «Итоги» становится
недоступной.
Процесс создания отчетов «Договор» и
«Страховой случай».
На вкладке Создание в панели
инструментов Отчеты выбираем Мастер отчетов. В диалоговом окне Создание отчетов
выбираем поле «ФИО» таблицы «Агент», «Наименование» в таблице «Клиент» и поля
«Дата заключения», «Срок (лет)» в таблице «Договор». Нажимаем Далее.
На следующем шаге выбираем вид
представления данных «Договор» (рис. 34).
Рисунок 34. Создание отчета
«Договор»
Сортировку выбираем по фамилии
агента, макет оставляем табличным, а ориентацию — книжной. Выбираем стиль и
называем отчет «Договор». Через режим макета корректируем размеры полей отчета,
сохраняем изменения в отчете (рис. 35).
Рисунок 35. Отчет «Договор»
Аналогично создаем отчет «Страховой
случай» — поля: «id страхового случая», «ФИО клиента» и «Наименование
страхового случая» (рис. 36).
Рисунок 36. Отчет «Страховой случай»
ЗАКЛЮЧЕНИЕ
Страховые компании — это финансовые
посредники, которые специализируются на предоставлении страховых услуг. Их
деятельность состоит в формировании на основании договоров с юридическими и
физическими лицами (через продажу страховых полисов) специальных денежных
фондов, из которых осуществляются выплаты страхователям денежных средств в
обусловленных размерах в случае наступления определенных событий (страховых
случаев).
Практически любая современная
организация нуждается в базе данных, удовлетворяющей те или иные потребности по
хранению, управлению и администрированию данных.
База данных — совокупность
структурированных и взаимосвязанных данных и методов, обеспечивающих
добавление, выборку и отображение данных. MS Access позволяет управлять всеми
сведениями из одного файла база данных. В рамках этого файла используются
следующие объекты:
Таблицы для сохранения данных;
Запросы для поиска и извлечение
только требуемых данных;
Формы для просмотра, добавления и
изменения данных в таблицах;
Отчеты для анализа и печати данных в
определенном формате.
Удачная разработка базы данных
обеспечивает простоту ее поддержания.
Разработанная в данном дипломном
проекте база данных позволяет эффекктивно работать с базой данных, запрашивать
информацию о клиентах по различным критериям, предоставлять отчетность по
данным запросам в виде удобно читаемых выходных форм.
Работа с этой базой данных позволяет
сократить время на поиск и обработку информации, является незаменимым атрибутом
современного страхового агента.
В ходе проделанной работы, нами были
созданы: пять таблиц, два запроса, пять форм и два отчета.Access, обладая всеми
чертами классической СУБД, предоставляет и дополнительные возможности. Access —
это не только мощная, гибкая и простая в использовании СУБД, но и система для
разработки работающих с базами данных приложений. С помощью Access можно
создать приложения работающее в среде Windows и полностью соответствующее
потребностям по управлению данными. Используя запросы, есть возможность
выбирать и обрабатывать хранящуюся в таблицах информацию. Можно создавать формы
для ввода, просмотра и обновления данных, а также использовать Access для
создания как простых, так и сложных отчетов. Формы и отчеты «наследуют»
свойства базовой таблицы или запроса, так что в большинстве случаев необходимо
указывать форматы, условия на значения и некоторые другие характеристики данных
только один раз. К числу наиболее мощных средств Access относятся средства
разработки объектов — Мастера, которые можно использовать для создания таблиц,
запросов, различных типов форм и отчетов, просто выбрав с помощью мыши нужные
опции.
С помощью Access также легко
импортировать данные из текстовых файлов документов текстовых процессов и
электронных таблиц (и экспортировать данные в них).Access имеет множество
областей применения: на малом предприятии, корпорации и даже в сфере домашнего
применения.
В данной курсовой работе была
спроектирована информационная система «Страховая компания».
В процессе создания информационной
системы были успешно решены задачи, поставленные в начале работы. Так были
разработаны бланки двух входных и одного выходного документов, заявленных в
задании; создана и проработана структура экономических показателей,
используемых в базе данных «Страховая компания»; спроектирована модель «сущность-связь»;
создана структура реляционной базы данных; полученные таблицы реализованы в
СУБД; составлена программа работы локальной базы данных; а также с помощью
средств реляционной алгебры и языка SQL проведена реализация запросов,
заявленных в рамках курсовой работы.
Полученная база данных позволяет без
специальных знаний обращаться к информации, отраженной в таблицах, добавлять,
изменять, удалять и просматривать все имеющиеся и вводимые данные.
Удобный и понятный интерфейс,
располагающий такими элементами, как таблицы, списки, кнопки и др. позволяет
быстро проанализировать информацию по введенному запросу, и предлагает
наглядное представление результатов.
Разработанная база данных может быть
применена для систематизации информации, хранимой в страховых компаниях, и
автоматизации процесса пользования этой информацией.
В свете широкого использования
IT-технологий, представленная курсовая работа является актуальной и отвечает
предъявленным к ней требованиям. Проект разработан и написан на языке
программирования высокого уровня Borland Delphi 7.0 с использованием языка SQL.
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
Российская
Федерация. Законы. Гражданский кодекс Российской Федерации [Текст]:[федер.
закон принят Гос. Думой 21 октября 1994 г.: по состоянию на 15 октября 2009
г.]. — [части 1-ая, 2-ая, 3-ая, 4-ая]-Н.: Сибирское университетское
издательство, 2009 — 704 с.
Бабаев
Ю.А. База данных. Шаг за шагом [Текст]: учебное пособие. — М.: Издательский
центр «Радуга», 2009. 456-607 с.
Бондарева
Г.А., Сахарова Е.В., Королькова Л.Н. Информатика [Текст]: методические
указания. — Ставрополь: СТИС, 2006. 289 с.
Волков
Б.С. База данных [Текст]: учебное пособие. — М.: Издательский центр «Академия»,
2010. 28-32 с.
Гаврилова
А.Н. База данных Access [Текст]: учебное пособие. — М.: Издательский центр
«Винтаж», 2010. 192-200 с.
Корчевской,
Л.И. Страхование от А до Я [Текст]: Под ред. Л.И. Корчевской К.Е. Турбиной.
-М.: 2005г.-360с.
Кузин
А.В. Информатика [Текст]: учебное пособие. — М.: Издательский центр «Академия»,
2005. 5-14 с.
Маренков,
Н.Л. Страховое дело [Текст]: учебное пособие для вузов / Маренков Н.Л.,
Косаренко Н.Н.; под ред. Н.Л. Маренкова — М.: Издательский центр «Феникс»,
2004. — 256с.
Могилев
А.В. Практикум по информатике [Текст]: учебное пособие. — М.: Издательский центр
«Виртуоз», 2008. 132-147 с.
Рейтман,
Л. И. Страховое дело [Текст]: Учебник / ред. Л.И.Рейтмана. — М. 2002г. — 285с.
Симонович
С.В., Евсеев Г.А., Алексеев А.Г. Специальная информатика [Текст]: учебное
пособие. — М.: Издательский центр «Аст-пресс», 2000. 148-152 с.
Приложение 1
СТРАХОВОЕ ОТКРЫТОЕ АКЦИОНЕРНОЕ ОБЩЕСТВО
«Национальная страховая группа»
Заявление
на страхование от несчастных случаев и болезней
Сведения, изложенные в настоящем заявлении,
имеют существенное значение для определения степени риска наступления
страхового случая. Если на какой-либо вопрос не получен ответ, заявление
считается не заполненным.
|
1. |
||||||||||||||||||
|
Ф.И.О. |
Одинцов |
|||||||||||||||||
|
Дата |
25.10.1975 |
Телефон: |
231987 |
|||||||||||||||
|
Паспорт |
серия: |
3 |
2 |
0 |
7 |
№ |
4 |
4 |
2 |
4 |
6 |
0 |
выдан: |
|||||
|
Адрес |
г. |
|||||||||||||||||
|
2. |
||||||||||||||||||
|
Ф.И.О. |
Одинцов |
|||||||||||||||||
|
Дата |
25.10.1975 |
Телефон: |
231987 |
|||||||||||||||
|
Адрес |
г. |
|||||||||||||||||
|
Место |
ООО |
|||||||||||||||||
|
Должность |
Менеджер |
|||||||||||||||||
|
Суммарный |
120 |
|||||||||||||||||
|
3.Выгодоприобретатель |
||||||||||||||||||
|
Ф.И.О., |
||||||||||||||||||
|
4. |
||||||||||||||||||
|
Единая |
||||||||||||||||||
|
СТРАХОВЫЕ |
СТРАХОВЫЕ |
Страховая |
||||||||||||||||
|
1. |
Начиная |
|||||||||||||||||
|
По |
400 |
|||||||||||||||||
|
2.Постоянная |
I |
130 |
||||||||||||||||
|
I |
||||||||||||||||||
|
I |
||||||||||||||||||
|
3. |
100% |
180 |
||||||||||||||||
|
4. |
Начиная |
|||||||||||||||||
|
5. |
весь |
|||||||||||||||||
|
6. |
круглосуточно, |
|||||||||||||||||
|
7.ОСОБЫЕ |
||||||||||||||||||
|
8. |
с |
|||||||||||||||||
* Уплата страховой премии (взноса) и выплата
страховой суммы, установленных в иностранной валюте, производятся в рублях по
курсу ЦБ РФ: при уплате страховой премии (взноса)- на день его уплаты, при
выплате страховой суммы — на день наступления страхового случая (если иной курс
валютной единицы или иная дата его определения не оговорены законом или
соглашением сторон).
9. ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ О ЗАСТРАХОВАННОМ
ЛИЦЕ:
|
1. |
ð Да ð Нет |
||
|
2. |
ð Да ð Нет |
||
|
3. |
ð Да ð Нет |
||
|
4. |
ð Да ð Нет |
||
|
5. |
ð Да ð Нет |
||
|
6. |
ð Да ð Нет |
||
|
МЕДИЦИНСКАЯ |
|||
|
Рост |
Вес |
Изменялся |
ð Даð Нет |
|
Пожалуйста, |
Общеврачебная |
||
|
07. |
ð Да ð Нет |
||
|
Болели |
|||
|
08. |
ð Да ð Нет |
||
|
09. |
ð Да ð Нет |
||
|
10. |
ð Да ð Нет |
||
|
11. |
ð Да ð Нет |
||
|
12. |
ð Да ð Нет |
||
|
13. |
ð Да ð Нет |
||
|
14. |
ð Да ð Нет |
||
|
15. |
ð Да ð Нет |
||
|
16. |
ð Да ð Нет |
||
|
17. |
ð Да ð Нет |
||
|
18. |
ð Да ð Нет |
||
|
19. |
ð Да ð Нет |
||
|
20. |
ð Да ð Нет |
||
|
21. |
ð Да ð Нет |
||
|
22. |
ð Да ð Нет |
||
|
23. |
ð Да ð Нет |
||
|
24. |
ð Да ð Нет |
||
|
25. |
ð Да ð Нет |
||
|
26. |
ð Да ð Нет |
||
|
27. |
ð Да ð Нет |
||
|
28. |
|||
|
29. |
|||
|
ИСТОРИЯ |
|||
|
30. |
ð Да ð Нет |
||
ПРИЛОЖЕНИЕ № 1 к АНКЕТЕ
|
Если |
|
|
№ |
ПОДРОБНЫЕ |
Я, _____________________________
заявляю, что предоставленные в настоящем
заявлении сведения правдивы и соответствуют действительности и понимаю, что они
могут иметь решающее значение при заключении договора страхования и при
осуществлении страховых выплат,
разрешаю любому врачу или лечебному учреждению,
имеющих какую-либо информацию о состоянии моего здоровья, сообщить эту
информацию в СОАО «НСГ»,
предоставляю СОАО «НСГ» право произвести
индивидуальную оценку риска, и в случае необходимости, предложить мне: изменить
условия страхования; пройти медицинское обследование или предоставить
дополнительную информацию,
обязуюсь сообщать в СОАО «НСГ» обо всех
существенных изменениях, связанных с моим здоровьем, родом деятельности,
увлечениях и других факторах, способных повлиять на степень риска (см.
Медицинскую анкету).
|
Страхователь: |
(фамилия, |
« |
*Настоящее Заявление является неотъемлемой
частью Договора страхования.
Приложение 2
Приложение 3
Условия страхования от несчастных случаев и
болезней
Объектом страхования являются не противоречащие
законодательству имущественные интересы Застрахованного или Страхователя,
связанные с жизнью, здоровьем, трудоспособностью Застрахованного лица.
Страхователь — дееспособное физическое лицо или
юридическое лицо любой формы собственности, заключившее Договор со Страховщиком
в соответствии с Условиями страхования от несчастных случаев и болезней (далее
Условия страхования) и уплачивающее страховую премию (страховые взносы) по
Договору. Страхователь — физическое лицо может также являться Застрахованным
лицом по Договору.
Застрахованное лицо (Застрахованный) —
физическое лицо в возрасте от 1 года до 75 лет, в отношении которого
Страхователь и Страховщик заключили Договор на случай причинения вреда жизни
или здоровью Застрахованного, на случай его смерти или наступления в его жизни
иного предусмотренного Договором события (страхового случая).
Выгодоприобретатель — это физическое или
юридическое лицо, которому принадлежит право на получение страховой выплаты, с
согласия Застрахованного лица.
Если Договором не предусмотрено иное (только при
условии, что о ниженазванном состоянии здоровья данного лица Страховщик был
письменно уведомлен страхователем до заключения Договора (при получении
заявления на страхование) -Договор страхования не заключается в пользу:
инвалидов I и II группы, инвалидов детства;
больных СПИДом, зараженных вирусом
иммунодефицита человека;
лиц, состоящих на учете в наркологическом,
онкологическом, психоневрологическом диспансерах;
лиц, которым установлен диагноз
сердечно-сосудистого, онкологического или иного угрожающего жизни заболевания
(диабет и т.п.), или лиц, имеющих симптомы такого заболевания на момент
заключения Договора, при обязанности Страховщика по условиям страхования
произвести страховую выплату в связи с болезнью;
лиц, признанных безвестно отсутствующими;
лиц, в отношении которых в связи с совершением
ими преступления судом назначены принудительные меры медицинского характера,
даже если к моменту заключения Договора страхования эти меры были изменены или
их применение было прекращено;
лиц, отбывающих наказание за совершение
преступлений в виде ограничения свободы, ареста, содержания в
дисциплинарно-воинской части;
Если в последствии будет установлено, что
Договор страхования был заключен в отношении таких лиц в связи с сообщением
ложных сведений, то такой Договор может быть признан недействительным.
Договором страхования, заключенным на Условиях
страхования, может предусматриваться в страховании от перечисленных страховых
рисков:
временная нетрудоспособность (временное
нарушение здоровья), начавшаяся в течение срока страхования, госпитализация,
наступившая в течение срока страхования в результате:
травмы, явившиеся вследствие несчастного случая
или неправильных медицинских манипуляций;
случайного острого отравления ядовитыми
растениями, химическими веществами и ядами биологического происхождения
(включая токсин, вызывающий заболевание ботулизмом), лекарствами,
недоброкачественными пищевыми продуктами, за исключением пищевой
токсикоинфекции (сальмонеллез, дизентерия и др.);
заболевание клещевым, послепрививочным
энцефалитом (энцефаломиелитом), полиомиелитом, гематогенным остеомиелитом;
патологических родов или внематочной
беременности, приведших к удалению органов (матки, обеих труб, яичников) —
только при периоде страхования 24 часа в сутки, произошедших в течение срока
страхования;
.2 постоянная нетрудоспособность, смерть,
наступившие в период действия Договора страхования либо до истечения времени со
дня событий, перечисленных ниже, равного сроку страхования, но не менее трех и
не более двенадцати месяцев в результате:
болезни;
травмы, явившейся следствием несчастного случая
или неправильных медицинских манипуляций;
случайного острого отравления ядовитыми
растениями, химическими веществами и ядами биологического происхождения
(включая токсин, вызывающий заболевание ботулизмом), лекарствами,
недоброкачественными пищевыми продуктами, за исключением пищевой
токсикоинфекции (сальмонеллез, дизентерия и др.);
заболевание клещевым, послепрививочным
энцефалитом (энцефаломиелитом), полиомиелитом, гематогенным остеомиелитом;
патологических родов или внематочной
беременности, приведших к удалению органов (матки, обеих труб, яичников) —
только при периоде страхования 24 часа в сутки, произошедших в течение срока
страхования, а также скоропостижная смерть, наступившая в период действия
Договора страхования от удушения вследствие случайного попадания в дыхательные
пути инородного тела, утопления, анафилактического шока, переохлаждения —
гипотермии (за исключением заболеваний сопровождающихся воздействием холода) или
перегревания — гипертермии;
По условиям Договора страхования выплата может
производиться:
.1 при наступлении временной нетрудоспособности
(временного нарушения здоровья), в процентах от страховой суммы по «Таблице
размеров страховых выплат №1», либо в размере 0,2% от страховой суммы за каждый
день временной нетрудоспособности (временного нарушения здоровья), но не более
50% от страховой суммы, установленной по Договору конкретному Застрахованному
лицу;
.2 при наступлении постоянной нетрудоспособности
(постоянного нарушения здоровья) с установлением Застрахованному инвалидности:
I группы — 100%, 80%, II группы — 80%, 60%, III группы — 60%, 40%, категории
«ребенок-инвалид» — 100%, 80% от страховой суммы;
.3 в случае смерти — 100% от страховой суммы;
.4 при наступлении госпитализации — за каждый
полный день пребывания в стационаре в размере 0,2% от страховой суммы и
производится Страховщиком в независимости от того, закончится период
госпитализации до или после окончания срока страхования, но в сумме не более
чем за 90 календарных дней по всем случаям госпитализации, связанным с
наступлением одной травмы.
В том случае, если при заключении Договора
страхования Застрахованному лицу установлена единая для всех включенных в
Договор страховых случаев страховая сумма, страховые выплаты по Договору
страхования, независимо от их количества и причин, не могут превышать 100%
страховой суммы, установленной Застрахованному лицу по этому Договору.
Если при заключении Договора страхования
страховые суммы, установленные Застрахованному лицу отдельно по каждому из
страховых случаев, страховые выплаты по Договору страхования Застрахованному
лицу в связи со страховыми случаями независимо от их количества, не могут
превышать 100% страховой суммы, установленной Застрахованному лицу для каждого
страхового случая этого Договора.
Если Договором не предусмотрено иное, не
является страховыми случаями события, происшедшие вследствие:
умышленных действий или бездействия
Застрахованного лица, Страхователя или лица, которое в соответствии с настоящим
Договором является Выгодоприобретателем/Наследником, а также иного лица,
действующего по их поручению, направленных на наступление страхового случая;
совершение Застрахованным уголовного
преступления, находящегося в прямой причинной связи со страховым случаем;
алкогольного отравления Застрахованного,
наркотического или токсического отравления в результате потребления им
наркотических, сильнодействующих и психотропных веществ без предписания врача
(или по предписанию врача, но с нарушением указанной им дозировки);
управление Застрахованным транспортным средством
без права на управление транспортным средством данной категории или передачи
Застрахованным управление транспортным средством лицу, не имевшему право на
управление транспортным средством данной категории.
Получения Застрахованным лицом травмы вследствие
нахождения его в состоянии алкогольного, наркотического или токсического
опьянения, управления Застрахованным транспортным средством в состоянии
алкогольного, наркотического или токсического опьянения или передачи
Застрахованным управление транспортным средством лицу, находившемуся в
состоянии алкогольного, наркотического или токсического опьянения;
самоубийство (попытки самоубийства)
Застрахованного, если на момент самоубийства Договор действовал менее двух лет,
за исключением доведением до этого другими лицами путем угроз, жестокого
обращения или систематического унижения человеческого достоинства;
воздействие ядерного взрыва, радиации или
радиационного заражения, террористического акта, военных действий, гражданских
волнений, забастовок, мятежей, бунтов, восстаний, реквизиции имущества,
введение чрезвычайного или особого положения по распоряжению военных или
гражданских властей и других обстоятельств, признанных форс-мажорными по
соглашению сторон Договором либо судом;
умышленного пребывания Застрахованного лица в
обстановке необычно высокой опасности, за исключением случаев, когда
необходимость этого была связана с попыткой спасения жизни людей.
Договор страхования заключается на срок один год,
если иное особо не оговорено.
Договором страхования могут быть предусмотрены
следующие периоды страхования:
на 24 часа;
при исполнении служебных обязанностей;
при исполнении служебных обязанностей, включая
время в пути на работу и с работы;
в быту;
на время нахождения Застрахованного в дошкольном
или учебном заведении (для Застрахованных лиц в возрасте от года до 18 лет, а
также учащихся дневных отделений высших и средних специальных учебных
заведений);
на время тренировок и соревнований;
иного периода страхования по договоренности
сторон.
Территория действия Договора — Российская
Федерация, если иное особо не оговорено в Договоре.
Размеры страховых сумм устанавливаются в
Договоре страхования по соглашению его сторон по пакету рисков или по отдельным
рискам, указанных в Страховом полисе.
Договором в зависимости от Варианта страхования
может предусматриваться уплата страховой премии — единовременно при заключении
Договора либо в рассрочку — регулярными ежегодными, полугодичными,
ежеквартальными или ежемесячными платежами (страховыми взносами) до окончания,
предусмотренного Договором срока их уплаты.
При наступлении страхового случая — Страхователь
(Выгодоприобретатель) обязан доставить Страховщику письменное заявление о
страховой выплате в течение тридцати дней.
.1. При заявлении Страховщику требования о
страховой выплате в связи со страховыми случаями: «Временная нетрудоспособность
(временное нарушение здоровья)», «Постоянная нетрудоспособность (постоянное
нарушение здоровья)», «Госпитализация» — Выгодоприобретатель (Застрахованное
лицо или Страхователь) обязан предоставить:
.1.1. письменное заявление со ссылкой на номер
Договора (Полиса), с подробным описанием обстоятельств, повлекших за собой
наступление страхового случая, и с указанием полных банковских реквизитов при
безналичной форме страховой выплаты (название банка, ИНН, КПП, БИК, расчетный
счет, лицевой счет получателя), копию Договора страхования (страхового Полиса),
документ, удостоверяющий личность получателя страховой выплаты;
.1.2. оригинал выписки из истории болезни
Застрахованного;
.1.3. копии закрытых листков нетрудоспособности,
заверенные отделом кадров Застрахованного;
.1.4. акт о несчастном случае на производстве
(форма Н-1), если страховой случай связан с несчастным случаем во время
исполнения Застрахованным служебных обязанностей, а также Акт расследования
тяжелого несчастного случая на производстве (при наличии);
.1.5. оригинал справки соответствующего органа
МВД, если страховой случай или обстоятельства его наступления зафиксированы
органом МВД в соответствии с действующим законодательством;
.1.6. оригинал свидетельства (справки) ГМСЭК об
установлении Застрахованному группы инвалидности (для Застрахованных в возрасте
до 18-ти лет — оригинал справки, выданной отделом социального обеспечения по
месту жительства родителей, опекуна, попечителя), если требование о страховой
выплате связано с установлением Застрахованному группы инвалидности;
.1.7. копию амбулаторной карты, карты
стационарного больного.
.2. При заявлении Страховщику требования о страховой
выплате в связи со страховым случаем — «Смерть» Выгодоприобретатель (или другое
лицо, указанное в Договоре) предоставляет Страховщику кроме документов,
указанных в п. 17.1. Условий страхования:
.2.1. оригинал свидетельства о смерти
Застрахованного или его нотариально заверенную копию;
.2.2. оригинал медицинского заключения о причине
смерти;
.2.3. акт о несчастном случае на производстве
(форме Н-1) и акт расследования смертельного несчастного случая, если
наступление смерти связано с несчастным случаем во время исполнения
Застрахованным служебных обязанностей;
.2.4. оригинал справки соответствующего органа
МВД, если наступление смерти или ее обстоятельства зафиксированы органом МВД в
соответствии с действующим законодательством;
.2.5. распоряжение Страхователя о назначении
Выгодоприобретателя на случай смерти Застрахованного, оформленное письменной
форме, с согласия Застрахованного или свидетельство о праве на наследство,
выданное нотариусом.
.3. При подаче заявления о страховой выплате
представитель Страхователя (Выгодоприобретателя) обязан предъявить выданную и
оформленную в установленном порядке доверенность, уполномочивающую его
действовать от имени Страхователя (Выгодоприобретателя).
.4. Решение о страховой выплате принимает
Страховщик, руководствуясь «Правилами», на основании документов,
предоставленных заявителем. При необходимости Страховщик запрашивает сведения,
связанные с несчастным случаем, у правоохранительных органов, медицинских
учреждений и других предприятий и организаций, располагающих необходимой
информацией. Страховщик вправе отсрочить принятие решения о страховой выплате
до выяснения обстоятельств наступления страхового случая, до получения
заключения медицинского учреждения (эксперта), назначенного Страховщиком для
выяснения состояния здоровья Застрахованного после наступления страхового
случая, а также для выяснения состояния здоровья Застрахованного на дату начала
страхования.
. Страхователь вправе:
.1. с письменного согласия Застрахованного
назначить Выгодоприобретателя на случай смерти Застрахованного, а также с
согласия Застрахованного заменить такого Выгодоприобретателя другим лицом до
наступления смерти Застрахованного;
.2. в любое время, письменно уведомив
Страховщика, отказаться от Договора страхования, если к моменту отказа возможность
наступления страхового случая не отпала по обстоятельствам иным, чем страховой
случай;
.3. проверять соблюдения Страховщиком условия
Договора;
.4. получать любые разъяснения по Договору;
. Страхователь обязан:
.1. уплачивать страховые взносы в размере и в
сроки, которые установлены Договором;
.2. в случаи смерти или инвалидности
Застрахованного письменно известить об этом Страховщика в течение 30-ти дней со
дня, когда у страхователя появилась возможность сообщить о случившимся. Данная
обязанность может быть исполнена Выгодоприобретателем;
.3. сообщить Страховщику достоверную информацию
о Застрахованном по требованию Страховщика, а также предоставлять Страховщику
или его представителю свободный доступ к информации, имеющей отношение к
страховому случаю;
.4.сообщить Страховщикуо всех известных ему
факторов существвенного увеличения степени страхового риска, в том числе
намерениях Застрахованного заняться или о начале его занятий опасными видами
спорта и отдыха;
.5. письменно уведомлять Страховщика обо всех
Договорах страхования Застрахованного лица от несчастного случая с другим
Страховщиком;
.6. приподачи заявления о страховой выплате
предъявить страховщику все документы, предусмотренные «Правилами» и Договором
страхования;
. Страховщик вправе:
.1. проверять сообщаемую Страхователем,
Застрахованным, Выгодоприобретателем информацию, а также выполнения ими условий
Договора и Условий страхования;
.2. требовать внесения изменений в Договор, в
том числе увеличения размера страховых взносов или снижения страховых сумм для
приведения их в соответствие изменившейся степени страхового риска, если в
течение срока страхования появляются факторы существенного увеличения степени
страхового риска;
.3. в случае смерти или инвалидности
Застрахованного, если при заключении Договора Страховщику была предоставлена
заведомо ложная информация о Застрахованном, применить последствия
предусмотренные статьей 944 Гражданского Кодекса Российской Федерации;
.4. отстрочить принятие решения о страховой
выплате или приостановить осуществления страховой выплаты если по факту
страхового случая в соответствие с действующим законодательством назначенная
дополнительная проверка, возбуждено уголовное дело или начат судебный процесс —
до окончания проверки, расследование или судебного разбирательства, или если у
Страховщика имеются обоснованные сомнения в праве Выгодоприобретателя на
получение страховой выплаты — до тех пор пока Выгодоприобретатель не представит
страховщику необходимые доказательства;
.5. взымать дополнительные страховые взносы при
изменение условий Договора, оформление дополнительных соглашений Договору и
т.п. в соответствии с установленными Страховщиком тарифами;
.6. требовать от Выгодоприобретателя выполнение
обязанностей по Договору страхования, включая обязанности, лежащие на
Страхователе, но невыполненные им, при предъявлении Выгодоприобретателем
требования о страховой выплате;
.7. потребовать признания Договора страхования
недействителен по основанием, предусмотренным законодательством Российской
Федерации;
.8. при наступлении события, имеющего признаки
страхового случая самостоятельно выяснять его причины и обстоятельства,
запрашиваю у любых физических и юридических лиц и получая иными законами
способами необходимую информации и документы;
.9. прирешение вопроса о страховой выплате
потребовать независимой медицинской комиссии;
.10. отказать в страховой выплате в случаи
предусмотренных Условиями страхования;
.11. потребовать от Страхователя
«Выгодоприобретателя» полного или частичного возврата страховой выплаты по
основаниям, придусмотренным Условиями страхования.
. Страховщик обязан:
.1. вернуть Страхователю сумму первого
страхового взноса при досрочным прекращении Договора по инициативе Страхователя
в течение первых 30 дней с даты уплаты данного взноса при условии отсутствии
страховых случаев этот период;
.2. соблюдать конфиденциальность в отношении
исполнения Договора и полученной информации о Страхователи, Застрахованном,
Выгодоприобретателя, о состоянии их здоровья, а так же об имущественном
положении этих лиц, за исключением случаев, предусмотренных законодательством
Российской Федерации;
.3. при наступлении страхового случая произвести
страховую выплату в размере, в сроки и способом, предусмотренными условиями
страхования и Договора страхования;
.4. в письменной форме уведомить Страхователя
(Выгодоприобретателя) об отказе в страховой выплате с указанием основания.
. Застрахованный (или иное лицо с согласия
Страховщика) обязана исполнить какое-либо из обязанностей Страхователя по
Договору в случае смерти Страхователя (физического лица). Застрахованный (или
иное лицо с согласия Страхователя и Страховщика) имеет право исполнить
какие-либо из обязанностей Страхователя по Договору в случае намерения
Страхователя расторгнуть Договор.
Исполнение застрахованным или иным лицом части
обязанностей Страхователя по Договору, не освобождает Страхователя или иное
лицо, принявшего на себя права и обязанности Страхователя по договору, от
исполнения других обязанностей по Договору.
. Застрахованный обязан:
.1. сообщить страховщику обо всех известных ему
факторов существенного увеличения степени страхового риска в течение 30 дней с
даты появления данных факторов;
.2. информировать Страховщика о намерениях
заняться или начале занятий опасными видами спорта и отдыха;
.3. в случаи обнаружения у него ВИЧ-инфекции или
СПИДа сообщить об этом страховщику в течение 30 дней с даты обнаружения данной
инфекции или заболевания.
. При неисполнение
или ненадлежащем исполнении сторонами условий Договора возникающие споры
разрешаются путем переговоров сторон, а в случае невозможности достичь согласия
— в порядке, предусмотренном законодательством Российской Федерации.
Содержание:
ВВЕДЕНИЕ
Современные информационные системы для хранения своих данных в качестве основы используют реляционные базы данных. Технологии и основные концепции данных имеют тенденцию к тому, чтобы складываться постепенно.
Достаточно широкое использование основных баз данных относительно различных категорий пользователей приводит к созданию интерфейсов, которые требуют минимум времени для освоения основных средств управления системой, а с другой стороны оказывают воздействие на построение достаточно мощных и гибких систем управления базами данных (СУБД), которые имеют развитые средства защиты данных от преднамеренного или случайного уничтожения. В последние годы появились новые средства для автоматизации разработок, которые позволяют создавать пользователям базы данных, в том числе и тем, которые не владеют основами теории БД.
Предметная область исследований курсовой работы (КР) – процесс управления продажами в страховой компании. В компании происходит страховое обслуживание клиентов на разных этапах и необходимо организовать учетную деятельность отдела продаж в компании.
Целью работы является разработка программы учета работы отдела продаж страховой компании.
В связи с этим для систематического и непрерывного учета выполненных работ по обслуживанию клиентов в отделе продаж необходимо разработать информационную систему.
Практическая ценность такой системы заключается в том, что она позволяет автоматизировать ручной труд как администратора, так и офис-сотрудника по составлению необходимой документации, по контролю выполняемых работ и оформлению соответствующей документации.
При современных темпах развития рыночных отношений данная разработка приобретает большую актуальность по той причине, что возможность создания и ведения базы данных учета, контроля и распределения различных заявок позволяет организации более эффективно работать с документацией, а также находить и использовать необходимые для развития деятельности контакты.
Задачи, которые должны быть решены для достижения цели:
- анализ процессов документооборота внутри страховой компании и выявление проблем;
- постановка задачи;
- анализ существующих программных средств для ведения учета выполненных работ;
- моделирование системы;
- выбор средств реализации;
- инфологическое и физическое проектирование базы данных;
- проектирование и разработка приложения.
Объектом исследования является отдел продаж страховой компании.
Предмет исследования – автоматизация процесса управления продажами в страховой компании.
Метод исследования – изучение текущего состояния бизнес-процессов в технологии работы по обслуживанию клиентов внутри компании, изучение литературы в области информационных технологий, CASE-систем и языков программирования.
Структура работы – работа состоит из введения, глав, заключения, списка использованной литературы и приложения.
Информационной базой написания работы выступают методические указания, учебные пособия, интернет-источники, данные финансовой отчётности страховой компании.
АНАЛИТИЧЕСКАЯ ЧАСТЬ
Описание предметной области. Постановка задачи
Представим общую информацию о компании:
Группа «АльфаСтрахование» является одной из крупнейших российских частных страховых компаний, имеющей универсальный портфель услуг, которая включает комплексные программы защиты интересов бизнеса и страховые продукты для частных лиц. По лицензии, организация предлагает более ста продуктов, в частности, продукты по страхованию жизни граждан.
В 2017 г. проведено исследования аналитическим центром Национального Рейтингового Агентства и Индустриальным страховым брокером, по результатам которого «АльфаСтрахование» получило высокую оценку надежности.
В состав компании входит «Альфа-Центр Здоровья» —медицинские центры, запущенные компанией в 2009 г., предоставляют медицинские услуги населению 12 городов России.
Группа «АльфаСтрахование» объединяет ОАО «АльфаСтрахование», ООО «АльфаСтрахование-Жизнь», ООО «АльфаСтрахование-ОМС», ОАО «СМК «Югория-Мед» и ООО «Медицина АльфаСтрахования».
По лицензии, компании АО «Альфа-Страхование» предлагают страховые продукты, в частности, страхование жизни и страхование от несчастного случая.
В общей структуре страхового портфеля Группы «АльфаСтрахование» без ОМС по итогам 2016 г. наибольшую долю занимает страхование жизни (32,7%), каско (14,5%), ОСАГО (14,4%) и добровольное медицинское страхование (9,7%). Собственные средства Группы «АльфаСтрахование» составляют более 11,8 млрд. руб [2].
При построении организационной модели компании необходимо выделить все единицы персонала, задействованного в страховой компании и установить между ними связи подчинения. Организационная модель представлена на рисунке1.
Рисунок 1. Организационная модель страховой компании
Таким образом, при дальнейшем проектировании информационной системы необходимо учитывать линейность организационной структуры компании. Это означает, что каждая единица персонала в одно время подчиняется только одному вышестоящему лицу. Очевидной положительной стороной такой организационной структуры является отсутствие противоречивости указаний вышестоящих органов, как бывает при функциональных и матричных организационных структурах, когда один человек может подчиняться одновременно нескольким начальникам.
Система должна предоставлять интерфейс для ввода, просмотра и редактирования всех необходимых данных любого справочника. Данные должны предоставляться в виде таблицы с указанием их основных полей. Программа должна обеспечить отображение элементов всех справочников в виде списков с возможностью добавления, редактирования, удаления записей, наложения фильтра по значению в текущей ячейке таблицы, сортировки по одной из колонок, поиска значения в текущей колонке, с возможностью настройки списка отображаемых столбцов и порядка их следования. Необходимо предусмотреть возможность объединения записей справочника в группы, объединяющие записи по смысловому или функциональному назначению. В этом случае в левой части списка должно отображаться дерево групп, а в списке должны отображаться записи только этой группы, при этом режим отображения списка по группам или без групп должен настраиваться [1].
Исходными документами для разрабатываемой системы служат:
- Перечень документов;
- Список предлагаемых услуг;
- Список проданных услуг;
- Договора страхования и перестрахования.
Эти же типы документов присутствуют в информационной системе.
Информация выше вносится в информационную систему, на основании чего формируются следующие отчеты, являющиеся выходными данными:
- Работы по сотруднику;
- Выполненные операции;
- Отчет по выполненным заказам;
- Отчет по клиентам.
Функциональные возможности системы можно разделить на три основные части:
- Ведение списков и справочников;
- Построение структуры оборудования;
- Учет выполненных операций.
Функция ведения списков и справочников является рутинной, но необходимой работой. Основная идея ведения справочников – максимально исключить ручной ввод данных, записывая данные в таблицы и предоставляя пользователю возможность выбирать эти данные в виде выпадающих списков или специальных форм выбора. Кроме убыстрения ввода данная функция позволит исключить ошибки и неоднозначности при вводе данных [3]. Второстепенные справочники выступают в основном в качестве реквизитов при заполнении основных справочников и документов по выполнению операций. Это такие справочники как:
- Клиенты;
- Отделы;
- Услуги;
- Заказы;
- Сотрудники компании;
- Подразделения компании;
- Должности сотрудников предприятия;
- Статусы операций, выполняемых с клиентами.
В страховой компании основными каналами продаж являются штатные сотрудники и агенты (рис.2).
Рисунок 2. Основные каналы продаж страховой компании
Процесс продажи страхового полиса АО «АльфаСтрахование» в соответствии со следующей структурной схемой (рис. 3):
Рисунок 3. Структурная схема процесса продажи страхового полиса
Базовым документом для заключения договора страхования является заявление страхователя (клиента).
Все операции продажи полиса выполняются вручную или с помощью автоматизированного рабочего место (АРМ) агента, после чего отчеты по заключенным договорам передаются операторам ПК для ввода в КИС СК для обеспечения автоматизированного учета.
Из всего комплекса задач, решаемых в страховой компании, мною будет исследоваться работа отдела продаж. Отдел состоит из нескольких сотрудников. Один обрабатывает заказы. В обязанности остальных сотрудников входит непосредственное обслуживание клиентов, внесение данных в базу данных, оформление договоров [5].
Входными данными по работе с клиентами являются:
- справочная информация о клиенте;
- предлагаемые услуги;
- бланки договоров;
- список сотрудников;
- список отделов страховой компании.
Выходными информационными потоками в данном процессе являются:
- обработанные заявления на страхование;
- оформленные договора;
- информация об обслуженных клиентах
- клиентская база данных;
- потребности клиента.
Выбор средств/методологии проектирования. Выбор СУБД
После определения объектов и установления связей между ними, переходят к этапу «Выбор инструментальных средств разработки БД». Этот этап является одним из важнейших моментов в разработке проекта БД, так как он принципиальным образом влияет на весь процесс проектирования БД и реализацию информационной системы. Теоретически при выборе СУБД нужно принимать во внимание десятки факторов. Но практически разработчики руководствуются лишь собственной интуицией и несколькими наиболее важными критериями, к которым, в частности, относятся:
- тип модели данных, которую поддерживает данная СУБД, её адекватность потребностям рассматриваемой предметной области;
- характеристики производительности системы;
- запас функциональных возможностей для дальнейшего развития системы;
- степень оснащённости системы инструментарием для персонала администрирования данными;
- удобство и надежность СУБД в эксплуатации;
- стоимость СУБД и дополнительного программного обеспечения.
На сегодняшний день одной из самых популярных настольных СУБД является MS Access. Это связано с тем, что Access обладает очень широким диапазоном средств для ввода, анализа и представления данных. Эти средства являются не только простыми и удобными, но и высокопродуктивными, что обеспечивает высокую скорость разработки приложений.
В данной работе в качестве инструмента разработки БД была использована СУБД MS Acсess, т.к. одним из основных критериев выбора СУБД является модель данных (используется для представления данных), а MS Acсess поддерживает реляционную модель данных.
Реляционная модель данных представляется в виде двухмерной таблицы, информационными единицами которой являются поля, домены и кортежи. Для описания информационных объектов предназначается соответствующий язык описания информационных документов [6, 7].
Кроме того, СУБД MS Access была выбрана исходя из следующих функциональных возможностей:
- в ней обеспечивается эффективная обработка больших объёмов информации;
- – обеспечивает доступ ко всем типам данных;
- имеется возможность одновременного использования нескольких таблиц БД;
- несмотря на то, что Access является мощной и сложной системой, его использование не сложно для непрофессиональных пользователей;
- лёгкость создания таблиц при помощи одного из трёх режимов: с помощью конструктора, с помощью мастера и путём ввода данных;
- простота создания связей между таблицами, с помощью «Редактора связей»;
- возможность создания форм с помощью конструктора и мастера форм;
- наличие встроенного механизма проверки целостности данных;
- СУБД Access позволяет создавать различные отчёты на основе данных из таблиц и других объектов БД.
Проектирование логической структуры базы данных
Система предназначена для обработки данных о видах страховок, их стоимости, о совершенных сделках, о клиентах, о сроках действия страховки.
Выходная информация – отчёты по запросу менеджера, прайс-лист по видам страховки, бланк страхования, информацию о клиентах и т.д. (табл.1).
В составе информационного обеспечения рассматриваемого комплекса задач выделены следующие классификаторы:
- классификатор клиентов;
- классификатор видов страховок;
- классификатор агентов;
- классификатор страхований.
Таблица 1
Словарь данных
|
Имя |
Описание |
|
Заказы клиентов |
Информация о заказе от клиента, начальные и конечный сроки страхования. |
|
Информация о страховании |
Клиент, агент, объект страховки, вид страховки, цена страховки, даты начала и завершения страхования. |
|
Информация о клиенте |
Финансовая информация о клиенте. |
|
Договора |
Перечень договоров, требующихся для оформления страхования. |
|
Договор |
Договор, отправленный на подписание клиенту. |
|
Персонал |
Персонал страховой компании. |
|
Цена страхования |
Количество денег, которое клиент должен заплатить за страхование. |
|
Оформленный договор |
Договор готовый к отправлению клиенту на подписание. |
|
Вид страхования |
Вид страхования, т.е. страхование жизни, страхование от несчастных случаев и так далее. |
Сводные характеристики классификаторов представлены в табл.2.
Таблица 2
Сводные характеристики классификаторов
|
Наименование классификатора |
Значность кода |
Система кодирования |
Система классифика-ции |
Вид классифика-тора |
|
Клиент |
7 |
порядковая |
Иерархическая |
Общесистемный |
|
Вид страховки |
3 |
разрядная |
Иерархическая |
Локальный |
|
Агент |
4 |
порядковая |
Иерархическая |
Локальный |
|
Страхование |
6 |
разрядная |
Иерархическая |
Локальный |
- Для классификатора клиента. Используется общесистемная система кодирования. Классификатор является порядковым и состоит из семи знаков. Структурная формула классификатора клиента:
Ф1 = [ХХХХХХХ];
- Для классификатора вида страхования используется разрядная система кодирования. Классификатор является локальным и состоит из трех знаков. Структурная формула классификатора вида страхования:
Ф2 = [ХХХ];
- Для классификатора агентов используется порядковая система кодирования. Классификатор является локальным и состоит из четырех знаков. Структурная формула классификатора агентов:
Ф3 = [ХХХХ];
- Для классификатора страхований используется порядковая система кодирования. Классификатор является локальным и состоит из шести знаков. Структурная формула классификатора страхований:
Ф4 = [ХХХХХХ];
Приведём инфологическую схему предметной области сведений информационной системы, предназначенной для обработки данных о видах страховок, их стоимости, о совершенных сделках, о клиентах, о сроках действия страховки (рис.4).
Рисунок 4. Инфологическая схема предметной области
В рассматриваемой АИС используем информационные объекты БД (таблицы):
Клиенты (Код клиента, ФИО, адрес проживания, телефон);
Агенты (Код агента, ФИО агента, название предприятия, адрес, телефон);
Объекты страховки (Код объекта страховки, название объекта страховки);
Виды страховок (Код вида страховки, Название вида страховки);
Страхование (Код страхования, Клиент, агент, объект страховки, вид страховки, срок страховки, цена страховки, дата начала страхования, дата завершения страхования).
Ниже задана логическая схема предметной области (рис.5):
Рисунок 5. Логическая схема предметной области
ER-модель данных— это графический язык, предназначенный для описания объектов и отношений.
IDEFlX-диаграммы используются CASE-средствами, AllFusion ERwin Data Modeler 7.
Модель «сущность-связь» или ER-модель опубликована американским исследователем в области баз данных Питером Ченом в1976 году. С тех пор она расширялась и модифицировалась как самим Ченом, так и многими другими исследователями. В различных вариантах она вошла в состав многих CASE-средств поддержки проектирования информационных систем.
Базовыми понятиями ER-модели являются сущность, атрибут, идентификатор и связь.
Ниже приведена графическая схема ER-модели данных, построенной для реляционной базы данных (БД) в анализируемой АИС (рис.6).
Рисунок 6. Графическая схема ER-модели «Страховая деятельность в отделе продаж»
Модель включает схемы таблиц, с перечислением их полей, и изображением связей между таблицами, с обозначениями типа этих связей.
Проектирование физической структуры базы данных
Выходные документы и сообщения:
- Отчет Агенты
- Отчет Клиенты
- Отчет Объекты страховки
- Отчет Отчет по продажам страхования.
В программном приложении MS Access разработана структура и схема данных БД.
В режиме Конструктора созданы следующие таблицы (рис. 7):
Рисунок 7.1 Таблицы в режиме Конструктора
В программном приложении MS Access разработаны формы как объекты баз данных для каждой из таблиц БД ( рис.8).
Рисунок 8. Формы
Далее в схеме данных созданы связи между таблицами (рис. 9):
Рисунок 9. Схема данных со связями между таблицами
В программном приложении MS Access разработан запрос с параметрами диалога как объект БД., Запрос выполнен в режиме конструктора (рис.10) и в режиме таблицы (рис.11Рисунок 10. Запрос с параметром (введите объект страховки)).
Рисунок 10. Запрос с параметром (введите объект страховки)
Рисунок 11. Результат запроса с параметром
В программном приложении MS Access разработан перекрестный запрос как объект БД. Запрос выполнен в режиме конструктора (Рисунок 12 – Запрос перекрёстный в режиме Конструктора12) и в режиме таблицы (Рисунок 13 – Перекрестный запрос Агент_Объект_Количество13).
Рисунок 12 – Запрос перекрёстный в режиме Конструктора
Рисунок 13 – Перекрестный запрос Агент_Объект_Количество
В программном приложении MS Access разработался запрос с вычислением как объект БД. Запрос выполнен в режиме конструктора (Рисунок 14 – Запрос с вычисляемым полем в режиме Конструктора14) и в режиме таблицы (Рисунок 15 – Запрос Срок страховки15). Вычислен срок страховки по формуле: Срок страховки: CInt(([Страхование]![Дата завершения страхования]-[Страхование]![Дата начала страхования])/365*12+0,5).
Рисунок 14 – Запрос с вычисляемым полем в режиме Конструктора
Рисунок 15 – Запрос Срок страховки
В программном приложении MS Access разработан запрос на удаление записей как объект БД. Запрос выполнен в режиме конструктора (Рисунок 16 – Запрос на удаление Вида страховки16).
Рисунок 16 – Запрос на удаление Вида страховки
В программном приложении MS Access разработан запрос на создание новой таблицы с вычисляемыми полями как объект БД. Запрос выполнен в режиме конструктора (Рисунок 17 – Запрос на создание новой таблицы17). Вычислена новая цена страхования (увеличение цены на 10%) по формуле Новая цена: [Страхование]![Цена страховки]*1,1
Рисунок 17 – Запрос на создание новой таблицы
Создана база данных для обработки данных по страхованию населения. Созданы таблицы, связанные между собой. По записям таблиц созданы следующие объекты базы данных: запросы, формы, отчеты.
ПРАКТИЧЕСКАЯ ЧАСТЬ
Инструкция по работе с базой данных
Для открытия файла базы данных необходимо:
- Выбираем место сохранения базы данных С:Мои документы;
- Файл базы данных MS Access 2016 — «БД.accdb».;
- Щелкаем мышкой по файлу два раза.
Откроется база данных MS Access 2010 «БД», с автозапуском главной кнопочной формой.
Разработка интерфейса и реализация проекта
В программном приложении MS Access разработана кнопочная форма-меню для работы с БД (Рисунок 18. 18), охватывающая все созданные объекты базы данных анализируемой АИС (таблицы, формы, запросы, отчеты).
Рисунок 18. Главная кнопочная форма-меню БД «Управление продажами в страховой компании»
Создана главная кнопочная форма-меню, на которой размещены кнопки на открытие всех созданных объектов. Главная кнопочная форма открывается при запуске базы данных.
В базе данных для вывода на печать созданы следующие отчеты (рис.19-22).
Рисунок 19. Отчет Агенты
Рисунок 20. Отчет Клиенты
Рисунок 21. Отчет Объекты страховки
Рисунок 22. Отчет по продажам
Оценка экономической эффективности проекта
Расчет был произведен по отраслевому стандарту ГОСТ 4.071.030.
Чтобы рассчитать показатели экономической эффективности, необходимо сравнить данные по затратам до внедрения информационной системы анализа деятельности предприятия и после внедрения. Эмпирически выявлено, что до внедрения ИС на складе работало 9 человек в год (3 менеджера по складской логистике, 6 начальников смены).
С использованием ИС возможно оперативно управлять складскими операциями, что повышает производительность персонала. Сравнительная характеристика показателей трудоемкости до и после внедрения информационной системы представлены в таблице 3.
Таблица 3
Показатели трудоемкости операции до и после внедрения информационной системы
|
№ п/п |
Показатели |
Расчёт |
Значение до внедрения |
Значение после внедрения |
|
1 |
Менеджер по складской логистике |
Эмпирически |
3 |
2 |
|
2 |
Начальник смены |
Эмпирически |
6 |
2 |
Составим смету затрат на оплату труда работников (Таблицы , 5).
Таблица 4
Смета затрат на оплату труда работников до внедрения информационной системы
|
№ |
Должность |
Оклад на 1 человека, руб |
Количество человек |
Общая сумма, с учетом трудозатрат, руб. в год |
|
1 |
Менеджер по складской логистике |
40000 |
3 |
1 440 000 |
|
2 |
Начальник смены |
45000 |
6 |
3 240 000 |
|
Итого |
4 680 000 |
Рассчитаем отчисления в фонды до и после внедрения ИС:
До внедрения: 4 680 000 * (0,22+0,029+0,051) = 1 404 000 руб.;
После внедрения: 1 560 000 * (0,22+0,029+0,051) = 468 000 руб.
Таблица 5
Смета затрат на оплату труда работников после внедрения информационной системы
|
№ |
Должность |
Оклад на 1 человека, руб |
Количество человек |
Общая сумма, с учетом трудозатрат, руб. в год |
|
1 |
Менеджер по складской логистике |
40000 |
1 |
480 000 |
|
2 |
Начальник смены |
45000 |
2 |
1 080 000 |
|
Итого |
1 560 000 |
Рассчитаем амортизацию техники и мебели на человека. В данной компании из техники представлены 1 компьютер и принтер для менеджера по складской логистике, 2 планшета для начальников смены. Из мебели стол и стул для менеджера. Амортизация после внедрения изображена в таблице 6.
Таким образом, после внедрения ИС амортизация в год составляет: (366,65+ 50 + 97,2 + 199,861+ 721,67) * 12 = 17 224,572 руб.
Таблица 6
Затраты на амортизацию после внедрения
|
Наимено-вание |
Модель |
Кол-во |
Цена, руб. |
Срок служ-бы, мес. |
Общая стоимость |
Аморти-зация за мес., руб. |
|
Компьютер |
Моноблок Lenovo ideacentre 310-20IAP |
1 |
21 999 |
60 |
21 999 |
366,65 |
|
Стол |
Стол компьютерный |
1 |
3000 |
60 |
3000 |
50 |
|
Стул |
Кресло офисное |
1 |
3 500 |
36 |
3 500 |
97,2 |
|
МФУ |
МФУ лазерное Ricoh SP 325SFNw |
1 |
14 390 |
72 |
14 390 |
199,861 |
|
Планшет |
10.1″ Планшет Acer Iconia One 10 [B3-A32] 16 Гб , LTE черный |
2 |
12 990 |
36 |
25 980 |
721,67 |
Рассчитаем потребляемую электроэнергию до и после внедрения ИС [8].
Рабочее помещение освещают 2 лампочек мощностью 100 Вт/час, в день используется: 2*100*8 = 1600 Вт.
Компьютер мощностью 450 Вт/час, в день используется: 450*8 = 3600 Вт
Один принтер мощностью 150 Вт/час, в день: 150*4 = 600 Вт
Два планшета: 50Вт * 16 * 2 = 1600 Вт
Потребляемая за день до внедрения ИС электроэнергия составит: 450*8*3 + 150*4 + 1600 = 13000 Вт или 13 кВт
Потребляемая за день после внедрения ИС электроэнергия составит: 1600 + 3600 + 600 + 1600 = 7400 Вт или 7,4 кВт
Следовательно, до внедрения ИС потреблялось: 13*22*12 = 3432 кВт, а после внедрения ИС – 7,4 * 22 * 12 = 1 953,6 кВт.
При тарифе для предприятия 3,37 руб за кВт затраты предприятия на электроэнергию до внедрения ИС ставят: 3432*3,37 = 11565,84 руб., а после внедрения ИС – 1 953,6 * 3,37 = 6 583,632 руб.
Прочие затраты до внедрения ИС составляют 4000 руб., а после внедрения – 2000 руб.
Сопровождением информационной системы анализа деятельности предприятия будут заниматься один специалист технической поддержки с окладом 25 000 руб. Стоимость сопровождения ИС на весь период составить 25 000*12 = 300000 руб.
Сравнительная характеристика затрат до и после внедрения информационной системы представлены в таблице 7.
Годовая экономия рассчитывается следующим образом:
годовая экономия = затраты до внедрения – затраты после внедрения.
Таким образом, годовая экономия составит:
6 318 063,6 — 2 373 808,204 = 3 944 255,396 руб.
Таблица 7
Сравнительная характеристика затрат до и после внедрения информационной системы
|
Наименование величины затрат |
Величина затрат до внедрения (руб.) |
Величина затрат после внедрения (руб.) |
|
Заработная плата |
4 680 000 |
1 560 000 |
|
Отчисления в фонды |
1 404 000 |
468 000 |
|
Амортизация техники и мебели |
20897,76 |
17 224,572 |
|
Электроэнергия |
115565,84 |
6 583,632 |
|
Материалы |
93 600 |
20 000 |
|
Прочие затраты |
4000 |
2000 |
|
Затраты на сопровождение базы данных |
— |
300000 |
|
Всего |
6 318 063,6 |
2 373 808,204 |
Коэффициент эффективности равен отношению годовой экономии к затратам после внедрения и на разработку.
Плановый коэффициент эффективности составляет:
3 944 255,396 / (10364297,72 + 2 373 808,204) руб. = 0,31
Коэффициент эффективности с учетом фактических затрат на разработку составляет:
3 944 255,396 / (10364297,72 + 2 373 808,204) руб. = 0,31
Срок окупаемости представляет собой отношение капитальных затрат на разработку и внедрение АСУ к годовой экономии (к годовому приросту прибыли).
Плановый срок окупаемости составляет:
10364297,72 / 3 944 255,396 руб. = 2,63 лет. 2,63 * 12 = 31.56 мес,
т.е. внедряемая информационная система окупит себя за 2 год и 8 месяцев.
Срок окупаемости с учетом фактических затрат на разработку составляет: 10364297,72 / 3 944 255,396 руб. = 2,63
График окупаемости строится на основании плановых затрат на разработку и сопровождение информационной системы анализа деятельности предприятия (рис.23) [4].
Рисунок 23. График окупаемости информационной системы управления отделом продаж страховой компании
ЗАКЛЮЧЕНИЕ
Развитие информационных технологий в современных тенденциях кардинально изменяет их роль в экономическом развитии организаций. Отдел ІТ-технологий переходит из роли глубокого сопровождения в статус партнера, предоставляющего качественно новые направления для ведения бизнеса и реализующего конкурентные преимущества на рынке. Это приводит к тому, что, во-первых, развитие информационных технологий в организациях должно тесно развиваться в целом со всей компанией; во-вторых, кардинально изменяется подходы к оценке эффективности функционирования IТ-отдела.
Оценка эффективности и значимости информационных технологий связана в первую очередь с характеристиками отдельных функциональных компонент (производительность сетевого оборудования, эффективность использования всего нового оборудования и т.п.).
В результате проведенной работы была выполнена задача: создание информационной системы отдела продаж страховой компании. Было выполнено проектирование и создание базы данных.
Спроектирована АИС управления продажами страховой компанией: описаны технологии, методы и требования к проектированию, приведены информационные модели бизнес-процессов, схемы технологического процесса сбора, передачи, обработки и выдачи информации в реализации бизнес-задачи и нарисованы схемы потоков данных.
Спроектированная база данных является средством достижения высокого уровня автоматизации в компании. Вследствие ее внедрения повышается производительность труда, снижается время, затрачиваемое на поиск нужной информации, сотрудники освобождаются от ряда продолжительных операций по вычислению и созданию информационных отчетов.
СПИСОК ЛИТЕРАТУРЫ
- Боковой Ю. Особенности методологии проектирования информационных систем для малого и среднего бизнеса. М.: Изд. дом «Университет», 2016. – 145 с.
- Макарова Н.В., Волков В.Б. Информатика: Учебник для вузов. – СПб.: Питер, 2011. – 576 с.: ил.
- Макарова, Н.В. Информатика. : Учебник для вузов / Н. В. Макарова, В. Б. Волков. – СПб. : Питер, 2011. – 576 с.
- Парахина, В.Н. Стратегический менеджмент: учебник/ В.Н.Парахина, Л.С. Максименко, С.В. Панасенко.- М.: КНОРУС, 2006. — 496 с.Пирогов В. Информационные системы и базы данных: организация и проектирование. СПб.: БХВ, 2015. – 341 с.
- Романова Т.Г., Романова Т.В., Белоусова А.Г. Финансовый анализ — Схемы и таблицы: учеб. пособие, 2010 – 63 с.
- Рудикова Л.В. Базы данных. Разработка приложений. СПб.: БХВ-Петербург, 2012. – 496 с.: ил.
- Рыбальченко М. Архитектура информационных систем. М.: Эксмо, 2016. – 221 с.
- Теория информационных процессов и систем. : Учеб. пособие. / Б.Я. Советов, В.А. Дубенецкий, В.В. Цехановский [и др.] ; под ред. Б.Я. Советова. — М. : Издат. центр «Академия», 2010. — 432 с.
- Нотариальные действия(Понятие и виды нотариальных действий)
- Оценка рыночной стоимости объекта интеллектуальной собственности: Применяемые стандарты
- Оценка стоимости права собственности на обыкновенные акции, представленные в виде бездокументарных именных ценных бумаг в количестве 290861 штук Акционерного общества «Ярославский комбинат технических тканей «Красный Перекоп» (Описание объекта оценки)
- «Формы международных расчетов и перспективы их изменения» (Формы международных расчетов и способы их осуществления)
- Оценка качества товаров (Теоретические основы оценки качества товаров)
- Коммерческая деятельность розничного торгового предприятия и ее совершенствование (на примере ТЦ «Час Пик» магазин VTM г. Москва)
- «Бухгалтерский баланс организации и порядок его составления» (Понятие и состав статей бухгалтерского баланса)
- «Учет труда и заработной платы» (Нормативно-правовое регулирование учета труда и заработной платы на предприятии)
- Формирование ассортимента товаров на предприятиях торговли (на примере торгового предприятия) (Сущность и виды ассортимента)
- Организационные структуры (Общая характеристика организационных структур)
- Управления Каналами сбыта в системе товародвижения реально существующей организации (Теоретические основы эффективной организации сбытовой деятельности предприятия)
- Системный подход к менеджменту (Основные характеристики системного подхода к менеджменту )
База данных Access Страховая компания
Вариант 1. Страховая компания
Описание предметной области
Вы работаете в страховой компании. Вашей задачей является отслеживание финансовой деятельности компании.
Компания имеет различные филиалы по всей стране. Каждый филиал характеризуется названием, адресом и телефоном. Деятельность компании организована следующим образом: к Вам обращаются различные лица с целью заключения договора о страховании.
В зависимости от принимаемых на страхование объектов и страхуемых рисков, договор заключается по определенному виду страхования (например, страхование автотранспорта от угона, страхование домашнего имущества, добровольное медицинское страхование). При заключении договора Вы фиксируете дату заключения, страховую сумму, вид страхования, тарифную ставку и филиал, в котором заключался договор.
Нужно учесть, что договоры заключают страховые агенты. Помимо информации об агентах (фамилия, имя, отчество, адрес, телефон), нужно еще хранить информацию о филиале, в котором работают агенты.
Кроме того, нужно иметь возможность рассчитывать заработную плату агентам. Заработная плата составляет некоторый процент от страхового платежа (страховой платеж — это страховая сумма, умноженная на тарифную ставку). Процент зависит от вида страхования, по которому заключен договор.
Пояснительной записки WORD нет!
Цель практических заданий – приобретение навыков анализа предметной области, проектирования базы данных, ее физической реализации в СУБД Access.
Результат выполнения работы представляется в виде файла БД Access, который должен содержать:
• структуру спроектированных таблиц,
• схему данных со связями между таблицами,
• примеры форм, обеспечивающих интерфейс пользователя,
• запросы (в режиме Конструктора и на языке SQL),
• отчеты (в режиме отчета и в режиме Конструктора),
• главную кнопочную форму.
Таблица «Филиалы» — База данных Access «Страховая компания»
Таблица «Договор» — База данных Access Страховая компания
Форма «Филиалы» — База данных Access Страховая компания
Форма «Вид страхования» — База данных Access Страховая компания
Запрос «Кол-во сотрудников по филиалам» — База данных Access Страховая компания
Отчет «Заработная плата» — База данных Access «Страховая компания»
Отчет по филиалу — База данных Access «Страховая компания»
Главная кнопочная форма — База данных Access «Страховая компания»
Готовая база данных Access «Страховая компания» доступна для скачивания по ссылке ниже.
Скачать базу данных (БД) MS Access; база данных access; бд access; субд access; базы данных access; access пример; программирование access; готовая база данных; создание база данных; база данных СУБД; access курсовая; база данных пример; программа access; access описание; access реферат; access запросы; access примеры; скачать бд access; объекты access; бд в access; скачать субд access; база данных ms access; субд access реферат; субд ms access; преимущества access; базу данных; скачать базу данных на access; базы данных; реляционная база данных; системы управления базами данных; курсовая база данных; скачать базу данных; база данных access скачать; базы данных access; страховка; скачать
Introduction
We will create an entity-relationship diagram for an Auto Insurance company to keep the policy information and you can see the data dictionary of this E-R diagram in Figure 2, which tells the purpose of each column. This is just a sample. If you want to use it in the real world, you need to customize it, in another words, you need to add more tables like archiving the old data if customer renews the policy, etc.
Every application needs a normalized database and it should be designed before writing a code and developing UI. This gives a better picture of the application. Normalized database is one of the most challenging tasks in software development. If database is denormalized or could not support the future enhancement, then you need to re-build your project from scratch which is costly. These days, developers want to use ORM tools so database should be normalized.
Let’s talk about our example. We would like to create a database for a small Auto insurance company what information we need to save in our database for example, Policy coverage, Policy holder’s address, name, SSN, vehicle information, bill, payment, traffic violation records. These are some of the data that we need to store. Let’s create a Policy table to save these data. It’s not a good practice to keep all of these information in a single table. These information should be kept in a different table so that we could reduce the data redundancy. Here, we don’t want to keep the billing and vehicle information in the same table. Billing information should be kept in one table and vehicle should be kept in another table.
Whenever we design the database, we talk about the Normalization. It is the process of organizing the data to reduce the redundancy.
1st Form of Normalization
We remove the repeating group of columns in the separate table. Therefore, we will keep the Vehicle in Vehicle table and Billing information in Bill table. Each record should have a unique identify column so we will create Primary Key column in every table.
2nd Form of Normalization
We remove the repeating set of records into the separate table and make join between the parent and child table. Here, we will make the Join between Policy and Bill table.
So, we will create a different table to make our database as a Normalized database. Below is the list of tables:
List of Tables
Policy: This table holds the general information about the policy likePolicyNumber,EffectiveDate,PolicyExpireDate, etc.Vehicle: This table keeps the information about the insured vehicle. There could more than one vehicle under a policy so all vehicles will go under this table. There is One-To-Many relationship between Policy and Vehicle table.Driver: There could be more than one driver under a policy. Each drives Name, Date of Birth, SSN, Driver licence number will store under this table. There is One-To-Many relationship betweenPolicyandDrivertable.Vehicle_Driver: There is Many-To-Many relationship betweenDriverandVehicleand this is the bridge table forVehicleandDrivertable.DriverAddress: This table holds the driver’s mailing and garage address, that’s why there is One-To-Many relationship betweenDriverandDriverAddresstable.TrafficViolationCode: This table holds the Traffic Violation Code. There is Zero-To-Many relationship between this table andDriver_TrafficViolation_Record. Similarly there is Zero-To-Many relationship betweenDriverandDriver_TrafficViolation_Record. We have zero to many instead of One-To-Many because some drivers have never violated the traffic rule.Driver_TrafficViolation_Record: There is Many-To-Many relationship betweenDriverandTrafficViolationCodetable and this table acts as bridge table between them.Bill: There could be more than one bill for a policy so we will have One-To-Many relationship betweenPolicyandBilltable.PaymentDetail: There is One-To-Many relationship between theBillandPaymentDetailtable.Customercould make multiple payment transactions or one.Coverage: There are different type of coverage in the Auto Insurance like Liability, Collision, Comprehensive, Rental, Medical Payment, Towing, Mechanical Break Down. Some of them apply only to policy, some only to vehicle and some of them to both.IsPolciyCoverageandIsVehicleCoveragetell, is it applicable toVehicleorPolicyand if it is applicable to both, then these twoboolcolumns will havetruevalue.CoverageNamecolumn holds the title of coverage like «Property Damage Liability 100000/300000» or «Property Damage Liability 25000/50000» andCoverageGroupholds information about which coverage this record belong to like «Medical Payment» or «Bodily injury and Property Damage Liability Coverage» or «Uninsured Motorist Coverage».Policy_Coverage: There is Many-To-Many relationship betweenCoverageandPolicytable and this is bridge table between themVehicle_Coverage: There is Many-To-Many relationship betweenCoverageandVehicletable and this is bridge table between them.PolicyEditLog: This table keeps the log information ifcustomerupdates thepolicyinformation like remove vehicle or add driver, etc.
Figure 1 is the E-R Diagram of Policy Database
)
Figure 1
Figure 2 Below is the Data Dictionary of Above ER diagram
Figure 2
This member has not yet provided a Biography. Assume it’s interesting and varied, and probably something to do with programming.
Презентация, доклад Разработка базы данных для страховой компании
Вы можете изучить и скачать доклад-презентацию на
тему Разработка базы данных для страховой компании.
Презентация на заданную тему содержит 13 слайдов. Для просмотра воспользуйтесь
проигрывателем,
если материал оказался полезным для Вас — поделитесь им с друзьями с
помощью социальных кнопок и добавьте наш сайт презентаций в закладки!
Слайды и текст этой презентации
Слайд 1
Описание слайда:
Курсовая работа
Проектирование и реализация базы данных “Страховая компания”
Выполнил : Злодеев Э.М.
Слайд 2
Описание слайда:
Цели курсовой работы
Разработать базу данных для страховой компании , которая будет хранить информацию :
О страховых агентах
О клиентах
О договорах
И выполнять задачи по
Расчету заработной платы страховым агентам компании
Слайд 3
Описание слайда:
Диаграмма базы данных
Слайд 4
Описание слайда:
Создание базы данных
Слайд 5
Описание слайда:
Создание таблиц
Слайд 6
Описание слайда:
Заполнение базы данных
Слайд 7
Описание слайда:
Создание индекса
Код
Слайд 8
Слайд 9
Описание слайда:
Запросы в базе данных
Слайд 10
Описание слайда:
Представления
Слайд 11
Описание слайда:
Хранимые процедуры
Слайд 12
Описание слайда:
Обеспечение безопасности
Processadmin. SQL Server является многозадачной средой. Это значит, что программа может выполнять несколько процессов одновременно. Например, SQL Server может породить один процесс для записи в кеш и другой процесс для считывания из кеша. Член группы processadmin может завершить (или прервать)процесс. Это еще одна хорошая роль для помощника администратора баз данных и разработчиков. Разработчикам в первую очередь необходимо прерывать процессы, инициализированные некорректным запросом или хранимой процедурой.
Dbcreator. Эти пользователи могут создавать и изменять базы данных. Такая роль подходит как помощнику администратора баз данных, так и разработчикам (которых следует предупредить о недопустимости создания ненужных баз данных, попусту занимающих место на сервере).
Diskadmin.Эти пользователи управляют файлами на диске. Они выполняют такие задачи, как зеркальное копирование баз данных и добавление новых устройств резервного копирования. Членами этой группы должны быть помощники администратора баз данных.
public. Назначение этой группы заключается в выдаче пользователям базы данных набора разрешений по умолчанию. Все пользователи базы данных автоматически объединяются в эту группу и не могут быть удалены.
db_owner. Члены этой роли могут выполнять все операции, выполняемые членами других ролей, а также некоторые административные функции
Слайд 13
Описание слайда:
Заключение
В ходе выполнения курсового проекта:
Мною была создана база данных для страховой компании , которая позволяет вести
Страховая компания
Вы работаете в страховой компании. Вашей задачей является отслеживание ее финансовой деятельности.
Компания имеет различные филиалы по всей стране. Каждый филиал характеризуется названием, адресом и телефоном. Деятельность компании организована следующим образом: к вам обращаются различные лица с целью заключения договора о страховании. В зависимости от принимаемых на страхование объектов и страхуемых рисков договор заключается по определенному виду страхования (например, страхование автотранспорта от угона, страхование домашнего имущества, добровольное медицинское страхование). При заключении договора вы фиксируете дату заключения, страховую сумму, вид страхования, тарифную ставку и филиал, в котором заключался договор.
Расширение постановки задачи
Нужно учесть, что договоры заключают страховые агенты. Помимо информации об агентах (фамилия, имя, отчество, адрес, телефон), нужно еще хранить филиал, в котором работают агенты. Кроме того, исходя из базы данных, нужно иметь возможность рассчитывать заработную плату агентам. Заработная плата составляет некоторый процент от страхового платежа (страховой платеж – это страховая сумма, умноженная на тарифную ставку). Процент зависит от вида страхования, по которому заключен договор.
Внести в структуру таблиц изменения, учитывающие эти факты, и изменить существующие запросы. Добавить новые запросы.
Мне не ясно какая связь между ДОГОВОР и ВИД СТРАХОВКИ
СОДЕРЖАНИЕ
Введение 3
Аннотация 4
Обследование предметной области 5
Концептуальное проектирование 8
Инфологическое проектирование БД 10
3.1. Модель «сущность-связь» 10
3.2. Классификация связей 12
Реляционная модель БД 14
4.1. Функциональные зависимости между атрибутами 15
4.2. Выбор ключей 17
4.3. Определение отношений между таблицами 20
4.4. Нормализация отношений 20
Даталогическое проектирование БД 22
5.1. Состав таблиц БД 22
5.2. Средства поддержания целостности 24
Запросы к БД 29
Разработка механизмов защиты данных от несанкционированного доступа 30
Требования к техническому обеспечению 33
Инструкция по использованию БД 34
9.1. Вызов программы 34
9.2. Экранные формы 35
9.3. Описание отчетов 37
Заключение 39
Список литературы 40
Приложения 41
ВВЕДЕНИЕ
В настоящие время в связи с развитием компьютерной техники появилась возможность автоматизировать многие процессы, также увеличился объем обрабатываемой информации. И возникла объективная необходимость автоматизировать систему учета и регистрации для медицинских страховых компаний.
Для автоматизации обработки данных в начале 70-х годов были предложены программы, специально предназначенные для управления данными – системы управления базами данных (СУБД).
Что такое базы данных?
В самом общем смысле база данных — это набор записей и файлов, организованных специальным образом. В компьютере, например, можно хранить фамилии и адреса друзей или клиентов. Один из типов баз данных — это документы, набранные с помощью текстовых редакторов и сгруппированные по темам. Другой тип — файлы электронных таблиц, объединяемые в группы по характеру их использования.
Первые модели данных.
С ростом популярности СУБД в 70-80-х годах появилось множество различных моделей данных. У каждой из них имелись свои достоинства и недостатки, которые сыграли ключевую роль в развитии реляционной модели данных, появившейся во многом благодаря стремлению упростить и упорядочить первые модели данных.
В зависимости от способа установления связей между данными с компьютерно–ориентированным описанием на языке конкретной СУБД, разрабатывались различные модели логической организации данных: иерархическая, сетевая и реляционная.
Использование баз данных и информационных систем становится неотъемлемой составляющей деловой деятельности современного человека и функционирования преуспевающих организаций. В связи с этим большую актуальность приобретает освоение принципов построения и эффективного применения соответствующих технологий и программных продуктов: систем управления базами данных, CASE-систем автоматизации проектирования, средств администрирования и защиты баз данных и других.
От правильного набора инструментальных средств создания информационных систем, определения подходящей модели данных, обоснования рациональной схемы построения баз данных, организация запросов к хранимым данным и ряда других моментов во многом зависят эффективность функционирования разрабатываемых систем. Все это требует осознанного применения теоретических положений и инструментальных средств разработки баз данных и информационных систем.
Целью данного курсового проекта является создание автоматизированной системы »Медицинская страховая компания» для данной компании.
Для этого необходимо создать базу данных, содержащую сведения о пациентах, регистрирующихся в медицинской страховой компании.
СУБД Microsoft Visual Fox Pro 6.0 представляет собой инструмент, позволяющий реализовать поставленную цель.
Достижение цели осуществляется посредством комплекса задач:
? проектирование и создание таблиц для хранения данных;
? ввод данных;
? разработка других элементов базы, предназначенных для просмотра, редактирования и вывода информации.
Также курсовой проект содержит требования к техническому обеспечению и инструкцию по использованию БД.
АННОТАЦИЯ
В ходе выполнения курсового проекта была создана база данных «Медицинская страховая компания» в современной системе управления базами данных – Microsoft Visual FoxPro 6.0. В базу входит ряд таблиц с данными, полученными при обследовании предметной области. Созданная база должна существенно облегчить, а также автоматизировать работу системы в данной компании.
Проектирование базы данных осуществлялось методом нормальных форм, который является классическим методом проектирования реляционных баз данных.
1. ОБСЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
Основанием для проектирования базы данных «Медицинская страховая компания» послужило задание Северо-Кавказского Государственного Технического университета (филиал в городе Кисловодске).
Управление процессом страхования включает в себя множество серьёзных задач. Разработка базы данных «Медицинская страховая компания» должна обеспечить решение следующих проблем:
Visual Fox Pro – представляет собой СУБД реляционного типа с развитыми средствами созданиями БД, организации запросов к ним, построения приложений с использованием визуального, объектно-ориентированного программирования. СУБД Visual Fox Pro может работать в среде Windows XP и Windows 2000.
Visual Fox Pro 6 совместима с более ранними версиями Fox Pro. Поэтому приложения, разработанные в более ранних версиях, могут быть адаптированы с ее помощью в среду Windows XP. Visual Fox Pro обладает высокой скоростью в обслуживании баз данных. Используемый стандарт SQL- запроса для выборки данных Visual Fox Pro позволяет работать с базами данных таких СУБД как Access, dBase и т.д., с серверами БД – Microsoft SQL Server.
2. КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ
Сущность (essence) – сущность объект любой природы, данные о котором хранятся в базе данных. Данные о сущности хранятся в отношении. Отношение является важнейшим понятием в реляционной модели данных и представляет собой двумерную таблицу, содержащую некоторые данные. Атрибуты представляют собой свойства, характеризующие сущность. В структуре таблицы каждый атрибут именуется и ему соответствуют заголовки некоторого столбца таблицы.
Сущность 1 – pacient;
Атрибуты:
? Код;
? Фио;
? Год_рожд;
? Адрес;
? Ном_полиса;
? Код_страх_ком.
Сущность 2 – poliklinika;
Атрибуты:
? Код;
? Название.
Сущность 3 – registracia;
Атрибуты:
? Код_пац;
? Кол_пол_ки;
? Код_заб;
? Фио_врача;
? Спец_врача;
? Дата_начала;
? Дата_окон;
? Дата_перв;
? Кол_пос;
? Кол_дом;
? Проф_осм;
? Плата.
Сущность 4 – strah_kompania;
Атрибуты:
? Код;
? Название;
? Доп_инф.
Сущность 5 – zabolevanie.
Атрибуты:
? Код;
? Название.
Обоснованием выбора данных сущностей являются исходные данные к проекту, которые были разбиты на отдельные части (таблицы) по принципу соответствия.
Выходная информация на экран:
-списки пациентов с указанным кодом заболевания по всем поликлиникам;
-суммарное количество посещений на дому для заданной поликлиники.
3. ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
3.1. Модель «Сущность-связь»
Наиболее часто формализация представлений о предметной области осуществляется в рамках модели «сущности-связи» («объекты-связи»). На данном этапе проектирования используется метод «сущность – связь», который называют также методом «ER-диаграмм» (“Essence” – сущность, “Relation” – связь). Этот метод основан на использовании диаграмм, называемых соответственно диаграммами ER-экземпляров и диаграммами ER-типа.
Основными понятиями метода сущность – связь являются следующие:
v сущность;
v атрибут сущности;
v ключ сущности;
v связь между сущностями;
v степень связи;
v класс принадлежности экземпляров сущности;
v диаграммы ER-экземпляров;
v диаграммы ER-типа.
Под информационным объектом понимается некоторая сущность фрагмента действительности, например: организация, документ, сотрудник, место, событие и т. д. Сущность представляет собой объект, информация о котором хранится в базе данных. Экземпляры сущности отличаются от друг друга и однозначно идентифицируются. Названием сущности являются имена существительные. Каждый тип объектов идентифицируется присущим ему набором атрибутов.
Атрибут ((от лат. attribuo – приписываю) – свойство или вещь, неотделимые от предмета) представляет собой логически неделимый элемент структуры информации, характеризующийся множеством атомарных значений. Это понятие аналогично понятию «атрибут» в отношении. Экземпляр объекта характеризуется совокупностью конкретных значений атрибутов данного типа объекта. Один или некоторая группа атрибутов объекта данного типа могут исполнять роль ключевого атрибута (ключа сущности).
Ключ сущности – это атрибут или набор атрибутов, идентифицирующих экземпляр сущности.
Связь двух или более сущностей – это зависимость между атрибутами этих сущностей. Оно обозначается глаголом. Причём связи бывают двух типов:
O иерархические;
O одноуровневые.
Для повышения наглядности и удобства проектирования используются графические средства представления сущности, экземпляров сущности и связей между ними.
рис 1. ER-диаграмма
3.2. Классификация связей
В реальных базах данных информация размещается в нескольких таблицах. Таблицы при этом связаны семантикой информации. В реляционных СУБД для указания связей таблиц производят операцию их связывания. Это повышает достоверность хранимой в базе информации, т. к. СУБД контролирует целостность данных, вводимых в базу в соответствии с установленными связями.
Установление связей облегчает доступ к данным при выполнении операций: поиск, просмотр, редактирование, выработка и подготовка отчета, т.к. обеспечивается обращение к любым полям связанных таблиц.
Между таблицами могут устанавливаться:
— бинарные связи;
— тернарные связи;
— n-арные связи.
При связывании двух таблиц выделяют основную и подчиненную таблицы (родительскую и дочернюю). Логическое связывание таблиц производится с помощью ключа связей. Поля основной таблицы могут быть простыми и ключевыми. Поля связей дополнительной таблицы чаще всего ключевые. В зависимости от того, как определены поля связи основной и дополнительной таблиц (как относятся ключевые поля с полями связи), устанавливаются виды связей:
u 1:1 (один к одному);
u 1:М (один ко многим);
u М:1 (многие к одному);
u М:М (многие ко многим).
Связь вида 1:1 образуется, если все поля связи родительской и дочерней таблиц являются ключевыми. Поскольку значения в ключевых полях двух таблиц не повторяются, обеспечивается взаимно-однозначное соответствие записей из этих таблиц. Сами таблицы, по сути, здесь становятся равноправными.
Связь вида 1:М имеет место в случае, когда одной записи родительской таблицы соответствует несколько записей дочерней таблицы.
Связь М:1 имеет место в случае, когда одной ил нескольким записям основной таблицы ставится в соответствие одна запись дополнительной таблицы.
Связь М:М возникает в случаях, когда нескольким записям основной таблицы соответствует несколько записей дополнительной таблицы.
Аналогично связи 1:1, связь М:М не устанавливает подчиненность таблиц. На практике в связь обычно вовлечены несколько таблиц. При этом одна таблица может иметь различные виды связи с несколькими таблицами, образуя иерархию или «дерево связей».
4. РЕЛЯЦИОННАЯ МОДЕЛЬ БАЗЫ ДАННЫХ
В реляционных базах данных (Relational Database System, RDBS) все данные отображаются в двумерных таблицах. База данных, таким образом, это ни что иное, как набор таблиц. RDBS и ориентированные на записи системы организованы на основе стандарта B-Tree или методе доступа, основанном на индексации – Indexed Sequential Access Method (ISAM) и являются стандартными системами, использующимися в большинстве современных программных продуктов. Для обеспечения комбинирования таблиц для определения связей между данными, которые практически полностью отсутствуют в большинстве программных реализаций B-Tree и ISAM, используется языки, подобные SQL (IBM), Quel (Ingres) и RDO (Digital Equipment), причем стандартом отрасли в настоящее время стал язык SQL, поддерживаемый всеми производителями реляционных СУБД.
Оригинальная версия SQL – это интерпретируемый язык, предназначенный для выполнения операций над базами данных. Язык SQL был создан в начале 70?х как интерфейс для взаимодействия с базами данных, основанными на новой для того времени реляционной теории. Реальные приложения обычно написаны на других языках, генерирующих код на языке SQL и передающих их в СУБД в виде текста в формате ASCII. Нужно отметить также, что практически все реальные реляционные (и не только реляционные) системы помимо реализации стандарта ANSI SQL, известного сейчас в последней редакции под именем SQL2 (или SQL-92), включают в себя дополнительные расширения, например, поддержка архитектуры клиент-сервер или средства разработки приложений.
Строки таблицы составлены из полей, заранее известных базе данных. В большинстве систем нельзя добавлять новые типы данных. Каждая строка в таблице соответствует одной записи. Положение данной строки может изменяться вместе с удалением или вставкой новых строк.
Чтобы однозначно определить элемент, ему должны быть сопоставлены поле или набор полей, гарантирующих уникальность элемента внутри таблицы. Такое поле или поля называются первичным ключом (primary key) таблицы и часто являются числами. Если одна таблица содержит первичным ключ другой, это позволяет организовать связь между элементами разных таблиц. Это поле называется внешним ключом (foreign key).
Так как все поля одной таблицы должны содержать постоянное число полей заранее определенных типов, приходится создавать дополнительные таблицы, учитывающие индивидуальные особенности элементов, при помощи внешних ключей. Такой подход сильно усложняет создание сколько-нибудь сложных взаимосвязей в базе данных.
Еще один крупный недостаток реляционных баз данных – это высокая трудоемкость манипулирования информацией и изменения связей.
4.1 Функциональные зависимости между атрибутами
Таблица 1 – Функциональные зависимости между атрибутами сущности
«pacient».
Наименование атрибута
Функциональные зависимости
Код;
Фио;
Год_рожд;
Адрес;
Ном_полиса;
Код_страх_ком.
Таблица 2 – Функциональные зависимости между атрибутами сущности
«poliklinika».
Наименование атрибута
Функциональные зависимости
Код
Название
Таблица 3– Функциональные зависимости между атрибутами сущности
«registracia»
Наименование атрибута
Функциональные зависимости
Код_пац;
Кол_пол_ки;
Код_заб;
Фио_врача;
Спец_врача;
Дата_начала;
Дата_окон;
Дата_перв;
Кол_пос;
Кол_дом;
Проф_осм;
Плата.
Таблица 4 – Функциональные зависимости между атрибутами сущности
«strah_kompania»
Наименование атрибута
Функциональные зависимости
Код;
Название;
Доп_инф.
Таблица 5 – Функциональные зависимости между атрибутами сущности
«zabolevanie»
Наименование атрибута
Функциональные зависимости
Код;
Название.
4.2 Выбор ключей
Первичный ключ используется в Visual Fox Pro при определении отношений между таблицами и условий целостности данных.
Первичным ключом (ключом отношения, ключевым атрибутом) называется атрибут отношения, однозначно идентифицирующих каждый из его кортежей. Например, в отношении zabolevanie (Код, Название) ключевым является атрибут «Код». Ключ может быть составным (сложным), т.е. состоять из нескольких атрибутов.
Каждое отношение обязательно имеет комбинацию атрибутов, которая может служить ключом. Её существование гарантируется тем, что отношение это множество, которое не содержит одинаковых элементов – кортежей. Т.е. в отношении нет повторяющихся кортежей, а это значит, что по крайней мере вся совокупность атрибутов обладает свойством однозначной идентификации кортежей отношения. Во многих СУБД допускается создавать отношения, не определяя ключи.
Возможны случаи, когда отношение имеет несколько комбинаций атрибутов, каждая из которых однозначно определяет все кортежи отношения. Все эти комбинации атрибутов являются возможными ключами отношения. Любой из возможных ключей может быть выбран как первичный.
Ключи обычно используют для достижения следующих целей:
1) исключение дублирование значений в ключевых атрибутах (остальные атрибуты в расчет не принимаются);
2) упорядочения кортежей. Возможно упорядочение по возрастанию или убыванию значений всех ключевых атрибутов, а также смешанное упорядочение (оп одним — возрастание, а по другим – убывание);
3) ускорение работы к кортежам отношения;
4) организация связанных таблиц.
Реляционная модель накладывает на внешние ключи ограничение для обеспечения целостности данных, называемое ссылочной целостностью. Это означает, что каждому значению внешнего ключа должны соответствовать строки в связываемых отношениях.
Поскольку не всякой таблицы можно поставить в соответствие отношение, приведём условия, выполнение которых позволяет таблицу считать отношением.
1) Все строки таблицы должны быть уникальны, т.е. не может быть строк с одинаковыми первичными ключами.
2) Имена столбцов таблицы должны быть различны, а значения их простыми, т.е. недопустима группа значений в одном столбце одной строки.
3) Все строки одной таблицы должны иметь одну структуру, соответствующую именам и типам столбцов.
4) Порядок размещения строк в таблице может быть произвольным.
Наиболее часто таблиц с отношением размещается в отдельном файле.
В некоторых СУБД одна отдельная таблица (отношение) считается базой данных. В других СУБД база данных может содержать несколько таблиц.
Таблица данных обычно хранится на магнитном диске отдельном файле операционной системы, поэтому по её именованию могут существовать ограничения. Имена полей хранятся внутри таблиц. Правила их формирования определяются СУБД, которые, как правило, на длину полей и используемый алфавит серьёзных ограничений не накладывают.
Если задаваемое таблицей отношение имеет ключ, то считается, что таблица тоже имеет ключ и её называют ключевой или таблицей с ключевыми полями.
У большинства СУБД файл таблицы включает управляющую часть (описание типов полей, имена полей другая информация) и область размещения записей.
Файл таблицы включает управляющую часть (описание типов полей, имена полей и другая информация) и область размещения записей.
К отношениям можно применять систему операций позволяющих получать одни отношения из других.
Первичному ключу родительской сущности, обычно соответствует несколько записей дочерней или подчиненной.
Разработанная база данных «Медицинская страховая компания» состоит из 5 таблиц, 4 из них обладают первичными ключами:
1. pacient; 2. strah_kompania;
3. poliklinika; 4. zabolevanie;
5. registracia.
4.3. Определение отношений между таблицами
В Visual FoxPro можно устанавливать постоянные отношения между таблицами. При определении отношений одна таблица является родительской, а другая дочерней. Для родительской таблицы должен быть определен первичный ключ или ключ-кандидат, а для дочерней — индекс для связи с родительской таблицей.
4.4. Нормализация отношений.
Нормализация – это приведение, к лучшей форме относительно включения, удаление и модификации.
Процесс проектирования баз данных с использованием метода нормальных форм является итерационным и заключается в последовательном переводе отношений из первой нормальной формы в нормальные формы более высокого порядка по определенным правилам. Каждая следующая нормальная форма ограничивает определенный тип функциональных зависимостей, устраняет соответствующие аномалии при выполнении операций над отношениями базы данных и сохраняет свойства предшествующих нормальных форм.
Для определения структуры каждой таблицы необходимо выполнить анализ функциональных зависимостей, т. е. выяснить какие поля зависят от других полей, а затем поля с одинаковой зависимостью организовать в отдельную таблицу. Таким образом, в одну и туже таблицу не нужно включать поля, являющиеся произвольными от других полей. В результате количество необходимых таблиц определяется числом функциональных зависимостей. Формально нормализация данных обеспечена, если набор таблиц удовлетворяет первым трем правилам, которые называются нормальными формами.
Первая нормальная форма требует отсутствия повторяющихся полей в первичном ключе. Вторая – чтобы каждый столбец таблицы зависел от своего первичного ключа. Третья – чтобы все непервичные поля зависели только от первичных.
В данном случае рациональные варианты группировки атрибутов удовлетворяют требованиям нормальных форм.
Выбранные ключи отличаются минимальной избыточностью. Не возникает никаких трудностей при выполнении операций включение, удаление и модификации.
Перестройка набора отношений при выделении новых типов минимальна. Разброс времени ответа на запросы к БД небольшой.
Нормализованы отношения, исключены функциональные транзитивные зависимости. Проверено соответствие отношений требованиям третьей нормальной формы.
5. ДАТАЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
5.1. Состав таблиц базы данных
В этом разделе приводится состав таблиц базы данных «Трудоустройство». Для каждого поля таблицы указан размер поля (в количестве символов), тип. Для первичных ключей введен запрет неопределенных значений. Для остальных полей возможность запрета неопределенных значений определяется семантикой предметной области.
Таб.6 Состав таблицы «pacient»
Наименование атрибутов
Тип полей
Размер полей
Допустимость неопределенных значений
Код;
Фио;
Год_рожд;
Адрес;
Ном_полиса;
Код_страх_ком.
integer
character
integer
character
character
integer
4
30
4
30
10
4
NOT NULL
NOT NULL
Таб.7 Состав таблицы «poliklinika»
Наименование атрибутов
Тип полей
Размер полей
Допустимость неопределенных значений
Код
Название
integer
character
4
30
NOT NULL
Таб. 8 Состав таблицы «registracia»
Наименование атрибутов
Тип полей
Размер полей
Допустимость неопределенных значений
Код_пац;
Кол_пол_ки;
Код_заб;
Фио_врача;
Спец_врача;
Дата_начала;
Дата_окон;
Дата_перв;
Кол_пос;
Кол_дом;
Проф_осм;
Плата.
integer
integer
integer
character
character
date
date
date
integer
integer
character
character
4
4
4
30
10
8
8
8
4
4
20
10
NOT NULL
NOT NULL
NOT NULL
Таб.9 Состав таблицы «strah_kompania».
Наименование атрибутов
Тип полей
Размер полей
Допустимость неопределенных значений
Код;
Название;
Доп_инф.
integer
character
character
4
30
30
NOT NULL
Таб.10 Состав таблицы «zabolevanie»
Наименование атрибутов
Тип полей
Размер полей
Допустимость неопределенных значений
Код;
Название.
integer
character
4
20
NOT NULL
5.2.Средства поддержания целостности
Обеспечение целостности базы данных означает выполнение ряда ограничений, соблюдение которых необходимо для поддержания непротиворечивости хранимых данных. Среди ограничений целостности можно выделить ограничения диапазонов значений атрибутов отношений и структурные ограничения на кортежи отношений.
Первый тип ограничений предполагает контроль значений атрибутов отношений.
Структурные отношения фиксируют два требования целостности, которые должны поддерживаться реляционными СУБД: требование целостности сущностей и целостности ссылок. Каждому экземпляру сущности, представленному в отношении, соответствует только один его кортеж. Первое требование состоит в том, что любой кортеж отношения должен быть отличим от любого другого кортежа этого отношения, иными словами, любое отношение должно обладать первичным ключом.
Формулировка второго требования тесно связана с понятием внешнего ключа. Требование целостности по ссылкам состоит в том, что для каждого значения внешнего ключа родительской таблицы должна найтись строка в дочерней таблице с таким же значением первичного ключа.
В Visual Fox Pro поддержка ссылочной целостности выполняется с помощью одноименного Построителя. Чтобы открыть Построитель ссылочной целостности, достаточно выполнить следующее:
v Открыть БД с таблицами, для которых необходимо установить ссылочную целостность;
v В контекстном меню Конструктора БД задать команду Referential Integrity (ссылочная целостность), что и приведет к открытию окна Построитель ссылочной целостности данных.
В окне Построителя перечислены все постоянные связи между таблицами БД Подписка. Информация по каждой связи размещена в отдельной строке. Первые два столбца содержат имена родительских и дочерних таблиц. Следующие три столбца содержат правила поддержания ссылочной целостности в случае редактирования, удаления и добавления записей соответственно. Изначально все правила содержат Ignore, но они определяются для каждой связи и каждой из трех перечисленных операций. Последние два столбца содержат индексы (теги) родительской и дочерней таблиц, по которым осуществляется связь.
В диалоговом окне Построителя ссылочной целостности коррективам могут быть подвергнуты только столбцы с правилами. Задача состоит в том, чтобы для каждой связи определить правила поддержания ссылочной целостности при выполнении каждой из трех возможных операций с данными этих таблиц.
Таблица 12.Средства поддержания целостности по ссылкам при модификации
Наименование
Описание
Cascade
При изменении первичного ключа или ключа-кандидата в родительской таблице автоматически осуществляется каскадное изменение всех соответствующих значений в дочерней таблице.
Restrict
Не позволяет изменять значения полей первичного ключа или ключа-кандидата в родительской таблице, если в дочерней таблице имеется хотя бы одна запись, содержащая ссылку на изменяемую запись.
Ignore
Позволяет изменять значения полей первичного ключа или ключа-кандидата в родительской таблице независимо от существования связанных записей в дочерней таблице. Целостность данных при этом не поддерживается
При удалении записи из родительской таблицы возможны следующие варианты действий:
Таблица 13.Средства поддержания целостности по ссылкам при удалении
Наименование
Описание
Cascade
При удалении первичного ключа или ключа-кандидата в родительской таблице автоматически осуществляется каскадное удаление всех соответствующих значений в дочерней таблице.
Restrict
Не позволяет удалять значения полей первичного ключа или ключа-кандидата в родительской таблице, если в дочерней таблице имеется хотя бы одна запись, содержащая ссылку на изменяемую запись. При попытке удаления возникает ошибка, которую можно обработать программно.
Ignore
Позволяет удалять значения полей первичного ключа или ключа-кандидата в родительской таблице независимо от существования связанных записей в дочерней таблице. Целостность данных при этом не поддерживается.
При добавлении новой записи в дочернюю таблицу или редактировании в ней существующей записи.
Таблица 14. Средства поддержания целостности по ссылкам при вводе
Наименование
Описание
Restrict
Не позволяет вводить запись, если значение индексного выражения дочерней таблицы не соответствует одной из записей родительской таблицы.
Ignore
При вводе данных в дочернюю таблицу не анализируется значение индексного выражения. Целостность данных при этом не поддерживается.
В данном курсовом проекте ссылочная целостность формировалось следующим образом:
1.Изменение значений ключевых полей родительских таблиц. Таблица trudoustraivaemiy является дочерней по отношению к таблицам organizaciya, sotrudnik_buro, nacionalnost, obrazovanie. Соответствующие поля являются ключевыми. При необходимости такие изменения нужны в родительских таблицах. В этом случае они синхронно (каскадно) изменяются в дочерних таблицах.
2.Удаление записей в родительских таблицах. Запретим удаление записей в родительских таблицах, имеющих в дочерних таблицах записи с совпадающими значениями внешних ключевых полей.
3.Изменение (добавление) записей в дочерней таблице. Запретим ввод записей в дочерней таблице, не соответствующее одной из записей в родительской таблице.
Рис 2. Таблица «Средства поддержания целостности»
6. ЗАПРОСЫ К БАЗЕ ДАННЫХ
Выборка информации из базы данных может осуществляться:
O с помощью команды SELECT SQL языка Visual FoxPro, которая является аналогом соответствующей команды SQL;
O с помощью мастера запросов и
O с помощью конструктора запроса.
1. Команда SELECT имеет множество возможностей (опций). Ее упрощенное представление имеет вид:
SELECT Список выбираемых полей
FROM СписокТаблиц – источник данных [INTO ИмяТаблицы получателя данных]
[WHERE УсловиеВыборки]
[GROUP BY УсловиеГруппировки]
[ORDER BY УсловиеУпорядочивания вводимых данных]
Квадратные скобки указывают на необязательность опции.
2. Конструктор запроса позволяет:
? выбирать данные из одной или нескольких таблиц, используя сложные критерии;
? устанавливать временные связи между таблицами;
? выбирать поля и записи таблиц с требуемыми данными;
? выполнять вычисления с использованием выбранных данных.
Работа с Конструктором запроса сводится к заполнению форм запроса. Результатом запроса всегда является таблица, которая может быть сохранена в массиве или созданной новой таблице, отражена на экране или оформлена в виде отчета. Данные, содержащиеся в результирующей таблице, могут быть представлены в виде графика или гистограммы.
Запросы представлены в приложении.
7. РАЗРАБОТКА МЕХАНИЗМОВ ЗАЩИТЫ ДАННЫХ ОТ НЕСАНКЦИОНИРОВАННОГО ДОСТУПА
Для успешного функционирования информационной системы, использующей базу данных, недостаточно выбора СУБД и сервера БД. На начале запуска информационной системы и в процессе ее эксплуатации необходимо выполнять настройку и различные функции администрирования. Важнейшими задачами администрирования являются защита информации и разграничения доступа пользователей. К числу других немаловажных задач настройки и администрирования также относятся следующие:
· Выбор способа размещения файлов на диске;
· Определение требуемого объема дисковой памяти;
· Резервное копирование.
Проблему защиты информации в БД целесообразно рассматривать совместно с проблемой защиты вычислительной системы. Знания принципов построения системы защиты и возможностей, предоставляемых различными компонентами вычислительной системы, позволяет оценить уязвимость ИС и грамотно организовать в ней защиту конфиденциальной информации.
Под информацией понимается любой вид накапливаемых, хранимых и обрабатываемых данных. Частным случаем информации является совокупность программ обеспечивающих различную обработку данных.
Целью защиты информационно – программного обеспечения является обеспечение безопасности хранимой и обрабатываемой информации, а также используемых программных средств.
Исходя из возможных угроз безопасности можно выделить 3 основные задачи защиты:
1. Защита информации от хищения.
Подразумевает предотвращение физического хищения устройств и носителей хранения информации, несанкционированного получения информации (копирования, подсмотра) и несанкционированного распространения программ.
2.Защита информации от потери..
Подразумевает поддерживание целостности и корректности информации, что означает обеспечение физической, логической и семантической целостности информации. Информация в системе может быть потеряна как из-за несанкционированного доступа в систему пользователей, программ (в том числе и компьютерных вирусов), некорректных действий пользователей и их программ, обслуживающего персонала, так и в случаях сбоев и отказов.
3. Защита от сбоев и отказов.
Аппаратно — программного обеспечения ВС является одним из необходимых условий нормального функционирования системы. Если ВС является ненадежной, информация в ней часто искажается и иногда утрачивается. Основная нагрузка на обеспечение хорошей защиты от сбоев и отказов в системе ложится на системные программно – аппаратные компоненты: процессор, основную память, запоминающие устройства, устройства ввода — вывода и другие устройства, а также программы операционной системы. При недостаточно надежных системных средствах защиту от сбоев следует предусматривать в прикладных программах.
Метод и средства защиты.
Существующие методы защиты можно разделить на четыре основных класса:
? Физические;
? Аппаратные;
? Программные;
? Организационные.
Правом доступа к базе данных «Медицинская страховая компания» обладают работники, имеющие квалификационные навыки в сфере создания и обработки информации баз данных Visual Fox Pro.
Visual Fox Pro является надежным программным обеспечением, имеющим все необходимые данные для защиты БД. Под надежностью понимается способность точно и своевременно выполнять возложенные на него функции. Степень надежности ПО определяется качеством и уровнем автоматизации и процессом разработки, а также организацией его сопровождения.
8. Требования к техническому
обеспечению
Требования к системе:
? система должна быть доступна обычному пользователю.
? она должна иметь простой, удобный интерфейс, не требующий знания языков программирования.
? проста в использовании, не требует высокой квалификации пользователя.
? система надежна и безопасна в работе.
Требования к видам обеспечения:
ОС Windows (98, 2000, XP)
Microsoft Office (97, 2000, XP)
Visual Fox Pro(6.0,7.0)
Общие требования к системе:
Процессор: Intel 880286
ОЗУ: 16Mb и более
VIDEO адаптер: EGA VGA
Монитор: цветной
Клавиатура: обычная
Компилятор: Visual Fox Pro
Свободное место на жестком диске 7.3 Mb
9. Инструкция по использованию БД
9.1. Вызов программы
Загрузка Microsoft Visual FoxPro
Произвести загрузку Microsoft Visual FoxPro можно тремя способами.
I способ — через главное меню Windows.
Для этого:
1) нажать кнопку пуск, расположенную в строке задач;
2) в появившемся контекстном меню выбрать команду программы и подтвердить свой выбор нажатием на левую кнопку манипулятора-мыши;
3) в открывшемся меню программы выбрать папку Microsoft Visual FoxPro;
4) в подменю этой папки выбрать команду Microsoft Visual FoxPro и выполнить щелчок левой кнопкой мыши.
II способ — через папку, создаваемую при установке.
Для этого:
1) активизировать диск, на который была установлена программа Microsoft Visual FoxPro;
2) открыть папку Microsoft Visual FoxPro;
3) выполнить двойной щелчок по пиктограмме, характеризующей Microsoft Visual FoxPro.
III способ — через ярлык программы.
Для этого подвести указатель мыши к ярлыку программы Microsoft Visual FoxPro и выполнить двойной щелчок левой кнопкой мыши.
После загрузки Visual FoxPro на экран выводится приглашение для работы. При выборе команды Close this screen приглашение закрывается и осуществляется вход в главное окно Visual FoxPro.
9.2 Экранные формы
Формы в Visual FoxPro используются для вывода и просмотра таблиц в окне формы. Они позволяют ограничить объем информации на экране и представить её в более наглядном виде.
В Visual FoxPro существуют два способа отображения содержимого таблицы: в виде таблицы и в виде экранной формы. Формы являются мощным и гибким средством представления информации.
В Visual FoxPro для создания формы можно воспользоваться:
u автоформой (AutoForm Wizard), который создает форму для одной таблицы с расположенными по умолчанию полями;
u мастером форм (Form Wizard), который позволяет достаточно быстро создать форму для одной или двух связанных таблиц. При этом можно задать отображаемые в форме поля, стиль их отображения и тип кнопок управления;
u построителем (Builder). Он позволяет создавать объекты формы с определенными свойствами;
u конструктором форм (Form Designer), в котором можно самостоятельно разрабатывать собственные формы с заданными свойствами для просмотра, ввода и редактирования данных.
Наиболее простым способом создания формы для одной таблицы является автоформа. При использовании данного способа на создание экранной формы уходит всего несколько секунд. Достаточно в конструкторе проекта установить указатель мыши на таблицу, для которой создается форму, и нажать на пиктограмму Autoform Wizard, расположенную в стандартной панели инструментов. Запускается мастер по созданию автоформы. Через несколько секунд на экране появится готовая форма.
Если созданная форма не полностью устраивает, достаточно нажать пиктограмму Modify Form на стандартной панели инструментов для перехода в режим конструктора форм.
Форму можно достаточно просто создать также с помощью соответствующего мастера. В полной мере все достоинства данного метода можно оценить при разработке форм для связанных таблиц.
Экранная форма, созданная с помощью мастера, предназначена для просмотра и модификации данных таблиц Visual Fox Pro. Эта форма содержит ряд кнопок для выбора режима просмотра, редактирования, печати данных.
Экранные формы представлены в приложении.
9.3 Описание отчётов
Под отчетом в Visual FoxPro понимается форматированное представление данных, выводимое на экран, принтер или в файл.
Прежде чем приступить к созданию отчета, необходимо знать ответы на следующие вопросы: «С какой целью создается отчет?», «Какая информация и из каких таблиц должна быть представлена в отчете?», «Отчет какого вида предполагается создать (табличный, в свободной форме или наклейки)?», «Предполагается ли группировка данных?»
Четкие ответы на данные вопросы существенно облегчат работу при создании отчета.
При создании отчета можно воспользоваться стандартными средствами, ускоряющими процесс создания отчета, или разработать для отчета специальный формат с помощью конструктора отчетов. Конструктор отчетов позволяет создавать отчеты как в табличном виде, так и в свободной форме.
Табличный отчет представляет собой напечатанную таблицу, в которой данные упорядочены по столбцам и строкам. Каждый из столбцов отчета содержит поле исходной таблицы или вычисляемое поле, а строка представляет собой запись. Табличный отчет позволяет напечатать данные из таблиц в наиболее простом и естественном виде. Табулированное представление данных в отчете имеет свои недостатки: в некоторых случаях поля исходной таблицы должны располагаться в специально отведенных для этого местах отчета. Очевидно, что табличный отчет не пригоден для этих целей.
Отчеты в свободной форме позволяют устранить ограничения, свойственные табличным отчетам. Для получения отчета в свободной форме можно воспользоваться стандартной формой отчета, автоматически создаваемой Visual FoxPro для каждой таблицы. В таком отчете поля исходной таблицы расположены вертикально. Конструктор отчетов позволяет разработать специальный формат отчета, в котором поля исходной таблицы будут расположены в требуемых местах отчета.
Для создания отчетов в Visual FoxPro можно использовать:
O «мастер» отчетов (Report Wizard), позволяющий быстро создать отчет, выбрав параметры сортировки и группировки данных, стиль отображения данных и их расположение;
O стандартный отчет (Quick Report), позволяющий создавать стандартный отчет, в котором поля отчета расположены определенным образом, предлагаемым программой;
O конструктор отчета, в котором можно разработать собственный отчет.
Отчеты представлены в приложении.
Заключение
Цель курсового проектирования – приобретение практических навыков обследования предметной области «Медицинской страховой компании», концептуального, логического и физического проектирования базы данных, освоение средств поддержания целостности базы данных, запросов.
В ходе работы над курсовым проектом были решены следующие поставленные задачи:
— обеспечение быстрого поиска по нужным данным;
— предоставление достоверных данных;
— повышение уровня квалификации сотрудников (с обновлением новых приложений).
Тема курсового проекта была дана мне руководителем курсового проекта из списка, утвержденного на заседании кафедры. Тема была согласована с руководителем проекта и утверждена заведующим кафедрой.
Были описаны практически все необходимые функции, которыми должна обладать база данных «Медицинская страховая компания», из них были реализованы наиболее актуальные и важные функции:
? обеспечение быстрого поиска информации по пациентам;
? предоставление достоверных данных;
? уменьшение затрат времени на получение и обработку информации;
? предоставление возможности работы с лучшими видами баз данных.
В ходе выполнения курсового проекта были приобретены устойчивые навыки программирования на языке Visual Fox Pro, изучены некоторые функции стандартной библиотеки языка. Полученные знания могут быть использованы при разработке более серьезных коммерческих проектов.
Список литературы
1.Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных. Учебник для ВУЗов / под ред. проф. А. Д. Хомоненко // СПб.: КОРОНАпринт, 2000.- 416 с.
2. Корнеев В.В. и др. Базы данных. Интеллектуальная обработка информации//М.: Нолидж, 2000.- 352 с.
3. Базиян Менахем. Использование Visual FoxPro 6 // М.-Санкт-Петербург-Киев, 1999.- 928 стр.
4. Каратыгин С.А., Тихонов А.Ф., Тихонова Л.Н. Visual FoxPro 6.0 // М.: Бином, 1999. -784С.
5. Ханcен Г., Ханcен Д. Базы данных. Разработка и управление / М.: Бином, 1999. -704 с.
6. Баженова И.Ю. Visual FoxPro 5.0//М.: Диалог МИФИ,1997. – 320 с.
7. Глушаков С.В., Ломотько Д.В. Базы данных. Учебный курс // Харьков : Фолио; Ростов н/Д : Феникс. Киев : Абрис, 2000. – 504 с.
8. Мусина Т.В., Пушенко В.А. Visual FoxPro 7.0. Учебный курс – К., ВЕК+, К.:Bookstar, М.: КОРОНА принт, 2003. – 400с.
ПРИЛОЖЕНИЯ
ПРИЛОЖЕНИЕ 1
ЭКРАННЫЕ ФОРМЫ
ПРИЛОЖЕНИЕ 2
ЗАПРОСЫ
Рис. 7. Запрос 1.
ПРИЛОЖЕНИЕ 3
ОТЧЁТЫ
Рис. 8. Отчёт 1.
Рис. 9. Отчёт 2.