Системный анализ и анализ требований к базе данных. Концептуальная и инфологическая модель предметной области. Типы атрибутов в логической модели базы. Физическая модель проектируемой базы данных в методологии IDEF1X. Требования к пользователям системы.
При низкой оригинальности работы "Разработка базы данных информационной экономической системы для автоматизации расчета отчислений в пенсионный фонд", Вы можете повысить уникальность этой работы до 80-100%
Объектом автоматизации является деятельность сотрудников бухгалтерии, а также процесс расчета отчислений в пенсионный фонд. Основное требование к базе данных «Расчет отчислений в пенсионный фонд» заключаются в автоматизации деятельности сотрудников бухгалтерии предприятия по расчету отчислений в пенсионный фонд. Сотрудникам для работы с базой данных «Расчет отчислений в пенсионный фонд» необходимо иметь навыки работы на ПК, иметь опыт работы в системах управления базами данных, а именно Microsoft Visual FOXPRO версии 9.0. 4.3 Требования к техническим средствам: технические средства должны включать рабочие станции с характеристиками не ниже: - процессор Intel Pentium IV 2,4 GHZ и выше; На начальном этапе проектирования базы данных проводился системный анализ и анализ требований к базе данных.
План
Содержание
Введение
1. Системный анализ и анализ требований к базе данных
2. Концептуальная (инфологическая) модель предметной области
3. ERD-диаграмма
4. Физическая модель проектируемой базы данных в методологии IDEF1X
5. Создание форм, запросов и отчетов в среде СУБД Visual FOXPRO 9.0
Список литературы
Введение
Современная жизнь немыслима без эффективного управления и информационные технологии во многом этому способствуют. Это касается и системы хранения, обработки информации, от которых во многом зависит эффективность работы любого предприятия. В наше время люди понимают, что информация - это деньги. Ее потеря или несвоевременность ее получения может дорого стоить. Именно этим можно объяснить стремительное развитие систем управления базами данных.
Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland DBASE, Borland Paradox, Microsoft Visual FOXPRO, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер». Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологии, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще - диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения, на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется [1].
Задачей курсового проекта является разработка базы данных информационных систем для автоматизации расчета выплат в пенсионный фонд.
Необходимо провести системный анализ и анализ требований к базе данных, определить входную и выходную информацию, создать логическую и физическую модели БД. После этого нужно создать базу данных в программном продукте Microsoft Visual FOXPRO 9.0, создать формы, запросы и отчеты.
1. Системный анализ и анализ требований к базе данных
Основным документом, определяющим, порядок расчета и уплаты страховых взносов в фонды социального, медицинского и пенсионного страхования, а также порядок предоставления отчетности является Федеральный закон от 24.07.2009 N 212-ФЗ "О страховых взносах в Пенсионный фонд Российской Федерации, Фонд социального страхования Российской Федерации, Федеральный фонд обязательного медицинского страхования и территориальные фонды обязательного медицинского страхования". 2010-2014 годы являются переходными и для отдельных категорий налогоплательщиков в это период применяются пониженные тарифы страховых взносов.
Пенсионные взносы делятся на страховую и накопительную части трудовой пенсии. Для лиц 1966 года и старше взносы начисляются только в страховую часть в размере 26% от общего дохода. Для лиц 1967 года и моложе процентная ставка страховой части составляет 20% от общего дохода, накопительной части - 6%. Расчет взносов производится с доходов каждого сотрудника и потом эти рассчитанные взносы суммируются и уплачиваются сразу за всех работников по установленным реквизитам. Расчет в течение года ведется нарастающим итогом. Указанные выше процентные ставки перестают взиматься, когда облагаемый взносами доход сотрудника за год превышает определенный лимит. В 2011 году данный лимит составляет 463 000 рублей. В 2010 году он составлял 415 000 рублей[4].
С целью автоматизации процессов деятельности сотрудников бухгалтерии необходимо разработать базу данных информационной системы расчета отчислений в пенсионный фонд.
Для начала автоматизации необходимо определить входящие и выходящие данные.
Выходной информацией, представляемой в виде отчетных документов, является, ежемесячные отчеты об отчислениях в страховую и накопительную части трудовой пенсии.
Для регистрации сотрудника предприятия необходимо ввести следующую входящую информацию: - номер сотрудника;
- фамилию;
- имя;
- отчество;
- дату рождения;
- должность;
- код негосударственного пенсионного фонда (далее НПФ).
Для регистрации информации о НПФ необходимой входной информацией будет: - код НПФ;
- название;
- адрес.
Для регистрации информации о доходах сотрудников предприятия необходимой входной информацией будет: - код дохода;
- номер сотрудника;
- месяц;
- доход за месяц.
Для регистрации данных об отчислениях в страховую часть трудовой пенсии необходимой входной информацией будет: - код дохода;
- процентная ставка.
Для регистрации данных об отчислениях в накопительную часть трудовой пенсии необходимой входной информацией будет: - код дохода;
- процентная ставка.
2. Концептуальная (инфологическая) модель предметной области
Одним из основных этапов проектирования базы данных является разработка инфологической модели предметной области.
Предметная область - это целенаправленная первичная трансформация картины внешнего мира в некоторую умозрительную картину, определенная часть которой фиксируется в информационной системе в качестве алгоритмической модели фрагмента действительности, связями между именами, понятиями и определенными реалиями внешнего мира, не зависящей от характеристик самой системы или базы, но и круга ее пользователей.
Концептуальная модель предметной области строится первой. Предварительная концептуальная модель строится еще на предпроектной стадии и затем уточняется на более поздних стадиях проектирования баз данных.
Центральным компонентом концептуальной модели является объект. Объекты могут быть реальными и абстрактными. Каждый объект имеет определенный набор свойств, для объектов одного класса набор этих свойств одинаковый, а их значения могут различаться.
Правила, которым должна удовлетворять концептуальная модель: -модель должна давать полное представление о предметной области;
-должны быть перечислены все необходимые для реализации задачи сущности и их атрибуты соответственно;
-имена сущностей должны быть уникальны;
-имена атрибутов в пределах одной сущности должны быть уникальны;
-однозначность трактовки модели;
-в каждой сущности должна быть выделена идентифицирующая совокупность атрибутов;
-модель должна быть гибкой, т.е. при возникновении новых задач расширяться без существенных изменений существующей модели.
Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).
Сущность - представление (абстракция) реально существующего объекта, процесса или явления. Наименование сущности должно быть уникально во всей модели.
Тип сущности - определяет набор однородных объектов.
Атрибут - свойство сущности (объекта). Его имя должно быть уникально в рамках одной сущности.
Идентифицирующий атрибут (ключ) - атрибут (несколько атрибутов), значение которого определяет уникальность экземпляра сущности.
В ниже приведенных таблицах представлено описание сущностей и их атрибутов.
Таблица 1- Атрибуты сущности «Сотрудники»
№ атрибута Название атрибута Описание атрибута
1 Номер сотрудника* Порядковый номер сотрудника, присвоенный при его регистрации. Является ключевым полем.
2 Фамилия Указывается фамилия сотрудника.
3 Имя Указывается имя сотрудника.
4 Отчество Указывается отчество сотрудника.
5 Дата рождения Указывается дата рождения сотрудника.
6 Должность Указывается должность, занимаемая сотрудником.
7 Код НПФ Указывается код НПФ.
Таблица 2- Атрибуты сущности «НПФ»
№ атрибута Название атрибута Описание атрибута
1 Код НПФ* Порядковый номер НПФ, присвоенный при его регистрации. Является ключевым полем.
2 Название Указывается название НПФ.
3 Адрес Указывается фактический адрес НПФ.
Таблица 3- Атрибуты сущности «Доходы»
№ атрибута Название атрибута Описание атрибута
1 Номер сотрудника Указывается номер сотрудника.
2 Месяц Указывается номер месяца.
3 Доход за месяц Указывается доход сотрудника за месяц.
4 Код процентной ставки Указывается код процентной ставки.
Таблица 4- Атрибуты сущности «Страховая часть»
№ атрибута Название атрибута Описание атрибута
1 Код процентной ставки* Порядковый номер процентной ставки, присвоенный при его регистрации. Является ключевым полем.
Связь позволяет моделировать отношения между объектами предметной области. Наименование связи должно быть уникально во всей модели.
Существует 4 типа связей: 1. «Один-к-одному» - любому экземпляру сущности А соответствует только один экземпляр сущности В, и наоборот.
2. «Один-ко-многим» - любому экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности В, но любому экземпляру сущности В соответствует только один экземпляр сущности А.
3. «Многие-к-одному» - любому экземпляру сущности А соответствует только один экземпляр сущности В, но любому экземпляру сущности В соответствует 0, 1 или несколько экземпляров сущности А.
4. «Многие-ко-многим» - любому экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности В, и любому экземпляру сущности В соответствует 0, 1 или несколько экземпляров сущности А.
Тип связи между объектами базы данных «Расчет отчислений в пенсионный фонд» выбран «один-ко-многим».
В физической модели каждой сущности будет соответствовать таблица базы данных, а каждому атрибуту - поле таблицы. Имена таблиц и полей лучше задавать с использованием латинских букв и достаточно короткими для удобства использования при программировании и для совместимости с системами, не использующими кириллицу[1]. Состав данных и связи в концептуальной и физической моделях показаны в таблице 6 и таблице 7.
Таблица 6- Состав базы данных информационной системы
№ п/п Сущности концептуальной модели Таблицы физической модели
Название Информация
1 Сотрудники “sotrudniki” Информация о сотрудниках предприятия
2 НПФ “npf” Информация о НПФ
3 Доходы “dohod” Информация о доходах сотрудников предприятия
4 Страховая часть “strahov” Процентные ставки страховой части трудовой пенсии
5 Накопительная часть “nakopit” Процентные ставки накопительной части трудовой пенсии
Таблица 7 - Связи между объектами базы данных информационной системы
ERD-диаграмма (Entity Relational Diagram) - реляционная диаграмма сущности, основанная на нотации, используемой ERWIN.
Диаграммы "сущность-связь" (ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).
Разработка ERD включает следующие этапы: идентификация сущностей, их атрибутов, а также первичных и альтернативных ключей;
идентификация отношений между сущностями и указаний типов отношений;
разрешение неспецифических отношений (отношений n*m).
В ERD-диаграмме наименования атрибутов объекта приведены внутри прямоугольника, а наименование объекта снаружи. Имена принято выражать существительными в единственном числе, взаимосвязи - при помощи пунктирных линий, соединяющими две сущности с точкой на одном конце (много) и пустым ромбом на другом (один) и глаголом, располагаемым над линией.
ERWIN обеспечивает только поддержку нормализации, но не содержит в себе алгоритмов, автоматически преобразующих модель данных из одной формы в другую. В ERWIN есть поддержка первой нормальной формы.
Для приведения базы данных в первую нормальную форму необходимо, чтобы все его атрибуты простые, т.е. неделимые.
Для приведения базы данных во вторую нормальную форму необходимо, чтобы отношение находились в первой нормальной форме, и каждый не ключевой атрибут функционально полно зависел от составного ключа.
Для приведения базы данных к третьей нормальной форме необходимо обеспечить отсутствие транзитивных зависимостей не ключевых атрибутов.
В модели каждая сущность или атрибут идентифицируется с помощью имени. В ERWIN поддерживает корректность имен следующим образом: • отмечает повторное использование имени сущности и атрибута;
• не позволяет внести в сущность более одного внешнего ключа;
• запрещает присвоение неуникальных имен атрибутов внутри одной модели, соблюдая правило «в одном месте - один факт».
При создании сущности необходимо выделить группу атрибутов, которые потенциально могут стать первичным ключом (потенциальные ключи), затем произвести отбор атрибутов для включения в состав первичного ключа, следуя следующим рекомендациям: ? первичный ключ должен быть подобран таким образом, чтобы по значениям атрибутов, в него включенных, можно было точно идентифицировать экземпляр сущности;
? никакой из атрибутов первичного ключа не должен иметь нулевое значение;
? значения атрибутов первичного ключа не должны меняться. Если значение изменилось, значит, это уже другой экземпляр сущности.
При создании концептуальной модели были определены сущности и атрибуты сущностей. Из этих данных составлена логическая модель базы данных, которая представлена на рисунке 1.
Рисунок 1- Логическая модель базы данных «Расчет отчислений в пенсионный фонд»
При построении логической модели необходимо прописывать типы атрибутов. Все присвоенные типы приведены в таблице 8.
Таблица 8- Типы атрибутов в логической модели базы данных.
№ п/п Атрибут Тип атрибута
1 Номер сотрудника Number
2 Фамилия String
3 Имя String
4 Отчество String
5 Дата рождения Date time
6 Должность String
7 Код НПФ Number
8 Название String
9 Адрес String
10 Код процентной ставки Number
11 Месяц Number
12 Доход за месяц Number
13 Процентная ставка Number
4. Физическая модель проектируемой базы данных в методологии IDEF1X
Методология IDEF1X - один из подходов к семантическому моделированию данных, основанный на концепции "сущность-связь" (Entity-Relationship). Это инструмент для анализа информационной структуры систем различной природы. Информационная модель, построенная с помощью IDEF1X-методологии, отображает логическую структуру информации об объектах системы.
Стандарт IDEF1X описывает способы изображения двух типов сущностей - независимой и зависимой, и связей - идентифицирующих и неидентифицирующих.
Сущность в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности.
Сущность является независимой, если каждый ее экземпляр может быть однозначно идентифицирован без определения его связей с другими сущностями.
Сущность называется зависимой, если однозначная идентификация ее экземпляра зависит от его связей с другими сущностями.
Если сущность является зависимой, то связь ее с родительской сущностью называется идентифицирующей, в противном случае - неидентифицирующей.
Связи в IDEF1X представляют собой ссылки, соединения и ассоциации между сущностями. Связи это суть глаголы, которые показывают, как соотносятся сущности между собой.
Первичный ключ - это набор атрибутов, выбранных для идентификации уникальных экземпляров сущности.
Создание концептуальной модели выполняется в CASE-средстве методологии IDEF1X с помощью ERWIN.
ERWIN - средство разработки структуры базы данных. Он облегчает проектирование баз данных. Для этого достаточно создать графическую ERD модель удовлетворяющую всем требованиям к данным и ввести правила для создания логической модели, которая отображает все элементы, атрибуты, отношения и группировки.
ERWIN поддерживает автоматическую генерацию физической модели данных для конкретной СУБД. При этом логическая модель трансформируется в физическую: сущности становятся таблицами, атрибуты становятся столбцами, а ключи становятся индексами.
Таблица 8 - Взаимосвязь логической и физической модели базы данных
Логическая модель Физическая модель
Сущность Таблица
Атрибут Столбец
Логический тип (текст, число, дата) Физический тип (конкретный тип, зависящий от выбранной СУБД)
Первичный ключ Первичный ключ, индекс PK
Внешний ключ Внешний ключ, индекс FK
Альтернативный ключ AK - индекс - уникальный, непервичный индекс
Правило бизнес - логики Триггер или сохраненная процедура
Взаимосвязи Взаимосвязи, определяемые использованием FK-атрибутов
На рисунке 2 представлена физическая модель базы данных «Расчет отчислений в пенсионный фонд»
Рисунок 2 - Физическая модель базы данных «Расчет отчислений в пенсионный фонд»
5. Создание форм, запросов и отчетов в среде СУБД Visual FOXPRO 9.0
Для базы данных «Расчет отчислений в пенсионный фонд» на первом этапе было построено и заполнено данными 5 таблиц: - «Сотрудники» (в соответствии с рисунком 3,4);
Далее была организованна связь между всеми таблицами базы данных по ключевым полям (в соответствии с рисунком 13).
Рисунок 13- Таблицы и связи между ними в базе данных «Расчет отчислений в пенсионный фонд»
Для более удобного просмотра информации, редактировании личных данных, регистрации и удаления из базы данных сотрудников была разработана экранная форма под названием «Сотрудники», в соответствии с рисунком 14.
Рисунок 14 - Экранная форма «Сотрудники»
Для выборки необходимой информации были созданы 2 запроса: 1. Запрос, рассчитывающий отчисления в страховую часть трудовой пенсии (в соответствии с рисунком 15, 16).
Рисунок 15- Формирование запроса, рассчитывающего отчисления в страховую часть трудовой пенсии
Рисунок 16- Результат запроса, рассчитывающего отчисления в страховую часть трудовой пенсии
2. Запрос, рассчитывающий отчисления в накопительную часть трудовой пенсии (в соответствии с рисунком 17, 18).
Рисунок 17- Формирование запроса, рассчитывающего отчисления в накопительную часть трудовой пенсии
Рисунок 18- Результат запроса, рассчитывающего отчисления в накопительную часть трудовой пенсии
По данным базы данных формируется следующие 6 отчетов: - отчет «Отчисления в накопительную часть пенсии за январь»
(приложение А);
- отчет «Отчисления в накопительную часть пенсии за февраль»
(приложение Б);
- отчет «Отчисления в накопительную часть пенсии за март» (приложение В);
- отчет «Отчисления в страховую часть пенсии за январь» (приложение Г);
-отчет «Отчисления в страховую часть пенсии за февраль» (приложение Д);
- отчет «Отчисления в страховую часть пенсии за март» (приложение Е).
Заключение
В современном обществе организациям становится невозможным равноценно конкурировать без внедрения в их работу современных информационных технологий. Информационные технологии позволяют автоматизировать, т.е. упростить, а соответственно и ускорить работу сотрудников предприятия. Так же автоматизация работ приводит к минимуму совершаемых ошибок. Этот факт очень важен для предприятий, ведь ошибка для них означает не только потерю времени на ее исправление, но и зачастую уменьшение прибыли. В данном курсовом проекте была разработана база данных «Расчет отчислений в пенсионный фонд» с использованием СУБД Visual FOXPRO 9.0.
При построении базы данных были рассмотрены следующие задачи: - анализ предметной области, функционирования базы данных;
- проведение системного анализа и анализа требований к создаваемой базе данных;
- построение инфологической модели предметной области с помощью Case-средства Erwin;
- построение ERD-диаграммы;
- построение физической модели базы данных в методологии IDEF1X;
- заполнение таблиц базы необходимыми данными;
- создание формы, для более наглядного и удобного редактирования данных;
- формирование и выполнение запросов;
- создание отчетов.
Список использованных источников
1. Мусина, Т.В. Visual FOXPRO 8.0. Учебный курс - К.: ВЕК , СПБ.: КОРОНА принт, К.: НТИ, 2004 г. - 464 с.
2. Хомоненко, А.Д., Цыганков, В.М., Мальцев, М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. проф. А.Д. Хомоненко. - 5-е изд., доп. и перераб. - СПБ.: КОРОНА принт, 2006 г. - 736 с.
3. Прохоров, А.А. Методическое пособие по курсовому проектированию. Проектирование баз данных экономических информационных систем. Пермь: «Пермская ГСХА», 2011 г. - 32 с.
4. Федеральный закон от 24.07.2009 N 212-ФЗ "О страховых взносах в Пенсионный фонд Российской Федерации, Фонд социального страхования Российской Федерации, Федеральный фонд обязательного медицинского страхования и территориальные фонды обязательного медицинского страхования".
5. ГОСТ 7.32-2001 СИБИД. Отчет о научно-исследовательской работе. Структура и правила оформления. - Введ. 2002-07-01. - М: Изд-во стандартов, 2001 г. -22с.
6. ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на АС. Техническое задание на создание АС. - Введ. 1990-01-01.-М: Изд-во стандартов, 1990 г. - 14с.
7. ГОСТ 7.1-2003. Библиографическая запись. Библиографическое описание. Общие требования и правила составления. - Введ. 2004-07-01. - М: Изд-во стандартов, 2003 г. - 17с.
Размещено на
Вы можете ЗАГРУЗИТЬ и ПОВЫСИТЬ уникальность своей работы
