40631

Автоматизация Финансового учета земельного налога КУМИ РМР

Дипломная

Финансы и кредитные отношения

Отличительные черты свободно распространяемых серверов баз данных. РАЗРАБОТКА БАЗЫ ДАННЫХ MunicipalEstateDB. Инфологическая модель базы данных. Физическая модель базы данных MunicipalEstateDB.

Русский

2013-10-17

13.08 MB

15 чел.

PAGE  74

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

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

«Рязанский государственный университет имени С.А. Есенина»

Физико-математический факультет

Кафедра информатики и вычислительной техники

«Рекомендовано к защите»

    

Заведующий кафедрой,

кандидат физико-математических наук, доцент Шилин А.С.

« »  2013 г.

Выпускная квалификационная работа

АВТОМАТИЗАЦИЯ  Финансового учета земельного налога КУМИ РМР

Выполнил:

Студент 5 курса ФМФ

Специальность 010503 –

«Математическое обеспечение

и администрирование информационных систем»

Кочанов Павел Валерьевич

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

Кандидат физико-математических наук, доцент Антошкин В.А.

Рязань 2013


СОДЕРЖАНИЕ

[1] АВТОМАТИЗАЦИЯ  Финансового учета земельного налога КУМИ РМР

[2]
Введение

[3]
ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ

[4] ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ

[4.1] 1.1. Автоматизированные системы управления
муниципальным имуществом.

[4.2] 1.2. Системы разработки программного обеспечения.
Достоинства и недостатки.

[4.3] 1.3. Отличительные черты свободно распространяемых серверов баз данных.

[5] ГЛАВА 2. РАЗРАБОТКА БАЗЫ ДАННЫХ MunicipalEstateDB

[5.1] 2.1. Инфологическая модель базы данных

[5.2] 2.2. Физическая модель базы данных MunicipalEstateDB

[5.3] 2.3. Раздел  базы данных «Арендаторы»

[5.4] 2.4. Раздел  базы данных «Адреса»

[5.5] 2.5. Раздел базы данных «Доверенное лицо»

[5.6] 2.6. Раздел базы данных «Договоры»

[5.7] 2.7. Раздел базы данных «Арендная плата»

[5.8] 2.8. Таблицы отчетов

[5.9] 2.9. Таблицы «Роли пользователей»

[5.10] 2.10. Таблицы «Виды статистик»

[5.11] 2.11. Таблица «Названия таблиц»

[5.12] 2.12. Создание базы данных

[6] ГЛАВА 3. СИСТЕМА УПРАВЛЕНИЯ БАЗОЙ ДАННЫХ MunicipalEstateDB

[6.1] 3.1. Разработка системы управления базой данных MunicipalEstateDB

[6.2]
3.2. Работа с программой «ФИНАНСОВЫЙ УЧЕТ КУМИ РМР 2012»

[6.3] 3.3. Формирование отчета по договору каждого арендатора

[7]
ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ПРОЕКТА

[8]
Заключение

[9] Список использованной литературы

[10]
Приложение


Введение

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

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

В данной работе предлагается создать средство автоматизации финансового учета земельного налога КУМИ РМР.

Для этого предлагается разработать базу данных и создать систему управления ею.

Для создания этой базы требуется разработать инфологическую и физическую модели базы данных, а для создания системы управления ею требуется разработать программу «Финансовый учет КУМИ РМР», которая позволит управлять базой данных, и, тем самым, вести финансовый учет.


ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ

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

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

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

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

Поэтому целью данной работы является автоматизация процесса формирования финансового учета земельного налога КУМИ РМР.

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

  1.  Разработать базу данных MunicipalEstateDB.
  2.  Создать систему управления базой данных MunicipalEstateDB.

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ

1.1. Автоматизированные системы управления
муниципальным имуществом.

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

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

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

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

Рассмотрим несколько таких систем:

  1.  Земельный офис – программный продукт компании ТОРИНС (Рис. 1.1).

Рис. 1.1. Автоматизированная информационная система "Земельный офис"

Автоматизированная информационная система (АИС) "Земельный офис" предназначена для автоматизации управления земельными участками.

АИС «Земельный офис» состоит из программных модулей:

  •  "Аренда земель"
  •  "План"
  •  "Земельный налог"
  •  "Администратор"

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

Программный модуль "Аренда земель" позволяет:

  •  Вести реестр договоров аренды земельных участков;
  •  Вести реестр арендаторов земельных участков;
  •  Вести реестр земельных участков;
  •  Заключать договор аренды на любое количество земельных участков, с учетом разных ставок арендной платы для частей земельных участков;
  •  Изменять площадь участков или их частей в течение действия договора;
  •  Заключать договоры аренды со множественностью лиц на стороне арендатора;
  •  Осуществлять поиск и фильтрацию записей реестров по любым критериям;
  •  Автоматически, на основании информации базы данных формировать и выводить на печать текст договора, расчет арендной платы, форму ПД-4, лицевой счет по договору, акт сверки платежей, дополнительные соглашения, претензионные письма, исковые заявления и другие документы;
  •  Производить начисления арендной платы на основе универсальной методики автоматического расчета арендной платы;
  •  Учитывать поступающие платежи и автоматически начислять пеню;
  •  Автоматически формировать список и отчет по должникам;
  •  Вводить сальдо на начало договора;
  •  Производить перерасчеты арендной платы или пени по новым ставкам. для отобранных договоров на любой произвольный период;
  •  Вносить сведения о суммах и датах погашения претензий и исков;
  •  Изменять, в случае необходимости, автоматически начисленную годовую или периодическую арендную плату на любую величину вводимую вручную;
  •  Сохранять величины арендной платы, введенные вручную для конкретных периодов, при автоматическом перерасчете;
  •  Рассчитывать и выводить не печать расчет арендной платы за любой период оплаты или любой год;
  •  Индексировать ставки и коэффициенты арендной платы;
  •  Использовать справочник ставок рефинансирования для автоматического начисления пени;
  •  Производить продление или досрочное прекращение договора;
  •  Вводить информацию о банкротстве арендатора;
  •  Производить начисление суммы неосновательного обогащения;
  •  Устанавливать, в случае необходимости, арендую плату или пеню равную нолю на любой период; 
  •  Использовать встроенный генератор отчетов для создания пользователем отчетов произвольной формы;
  •  Использовать визуальный построитель запросов к базе данных с возможностью вывода результатов в таблицы Excel;
  •  Создавать пользовательские маски для ввода кадастровых номеров;
  •  Хранить в базе данных тексты документов, связанных с договором;
  •  Хранить историю состояния договоров и платежей арендной платы по ним;
  •  Создавать отчеты различных типов с использованием шаблонов;
  •  Создавать или менять шаблоны для автоматического формирования документов;
  •  Экспортировать базу данных о договорах для передачи ее в программное обеспечение анализа информации более высокого уровня.

Программный Модуль «План» автоматизированной информационной системы (АИС) «Земельный офис» предназначен для использования графический информации о контурах земельных участков, кадастровых кварталов и других объектов (электронная карта) при поиске, просмотре и анализе данных в модулях «Аренда» и «Собственность» АИС «Земельный офис».

Программный модуль "План" позволяет:

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

Программный модуль "Собственность"

Программа предназначена для ввода, редактирования и вывода информации о земельных участках, субъектах прав, и правах на земельные участки. Основная задача программы - формирование отчетных форм "Сведения о земельных участках, расположенных в пределах муниципального образования" в соответствии с приказом Минфина № 47н от 23.03.2006 г.

Программный модуль "Собственность" позволяет:

  •  Вести базу данных объектов налогообложения по земельному налогу, расположенных в пределах муниципального образования.
  •  Выводить на печать или в электронном виде отчетные формы "Сведения о земельных участках, расположенных в пределах муниципального образования".
  1.  Программное обеспечение ООО "НПЦ "Космос-2"

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

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

АС «УГМИ» и АС УМС автоматизируют выполнение похожих задач, направленных на управление имуществом различных уровней собственности (АС «УГМИ» - государственным имуществом, а также муниципальным имуществом в рамках единого информационного пространства региона, АС УМС - муниципальным имуществом).

В рамках единой базы данных АС «УГМИ», АС УМС позволяют автоматизировать решение следующих задач:

  •  ведение реестров объектов собственности всех типов (земельные участки, движимое, недвижимое имущество, объекты инженерной инфраструктуры и незавершенного строительства, муниципальные и государственные предприятия и учреждения, акции, доли, паи и т.д.) в соответствии с приказом Министерства экономического развития Российской Федерации (Минэкономразвития России) от 30 августа 2011 г. N 424 «Об утверждении Порядка ведения органами местного самоуправления реестров муниципального имущества» и постановлением Правительства Российской Федерации от 16 июля 2007 г. N 447 «О совершенствовании учета федерального имущества» а также подзаконными нормативными и правовыми актами, связанными с ними;
    •  ведение договоров и дополнительных соглашений к ним по управлению и использованию объектов собственности (договоры оперативного управления и хозяйственного ведения, аренды, купли/продажи, приватизации и т.д.);
    •  формирование, контроль и управление финансовой информацией по использованию собственности (расчет планируемой арендной платы, выкупа, начисление арендной платы, платы за выкуп, фактическое использование, начисление пени и процентов за пользование чужими денежными средствами/упущенной выгоды, импорт, распределение по договорам, перераспределение информации по платежам, формирование сальдо и т.д.);
    •  бюджетный учет согласно требованиям инструкций Министерства финансов РФ;
    •  движение объектов всех типов в казне и на балансе;
    •  ведение претензионно-исковой деятельности (подготовка претензий, исковых заявлений в суды, протоколов расчета арендной платы, платы за фактическое использование, пени, процентов за пользование чужими денежными средствами в периоде возникновения задолженности, планирование и контроль деятельности юридического отдела и т.д.);
    •  управление предприятиями-банкротами, реструктуризация задолженности и т.д.;
    •  формирование аналитических, статистических отчетов, в том числе в вышестоящие и контролирующие органы (изменения в реестрах, прогнозы, финансово-аналитическая отчетность, отчетность по бюджетному учету и т.д.);
    •  формирование необходимых печатных форм (проекты приказов, постановлений, тексты договоров, доп. соглашений, выписок из реестра, справок об отсутствии задолженности и.т.д.).

Рис.1.2. Формирование текстов договоров и актов приема передачи

Рис. 1.3. Формирование текстов и иных документов  

Рис. 1.4. Формирование информации об объектах учета  

Рис. 1.5. Финансово-аналитический блок  

Рис. 1.6. Претензионно-исковой блок  

  1.  АВТОМАТИЗИРОВАННАЯ ИНФОРМАЦИОННАЯ СИСТЕМА "ИМУЩЕСТВО"

Разработчик: Центр системных исследований "ИНТЕГРО"

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

В АИС «ИМУЩЕСТВО» (разработчик ЦСИ «Интегро», г. Уфа для ведения реестра каждого вида объекта учета, представлена своя подсистема, которая ведет не только учет объектов муниципального имущества, но и формирует единое информационное поле для всех подсистем. В каждой предметной области заполняются свои характеристики объектов учета, которые могут становиться доступными для других подразделений в пределах их компетенции. Эти объекты учета отображаются на единой картографической основе.

Автоматизированная информационная система "Имущество" предназначена для автоматизации деятельности по учету и управлению муниципальным имуществом. В системе реализованы следующие возможности:

  •  Ведение реестра муниципального имущества [1].
  •  Контроль договорных отношений, возникающих относительно муниципального имущества.
  •  Учет и контроль поступления средств по договорам аренды.
  •  Контроль движения имущества, возникновения и прекращения различных правовых отношений.
  •  Регистрация работы юридических служб, связанной с договорными отношениями на муниципальное имущество.
  •  Автоматизированное создание договоров, актов,счетов и прочих сопутствующих документов.
  •  Визуализация расположения объектов муниципальной собственности в МГИС, их пересечение с зонами деловой активности города и использование этих данных для оптимизации расчета арендной платы.

Преимущества системы:

  •  Архитектура системы: «клиент-сервер» без ограничения числа рабочих мест;
  •  Использование тонкого web-клиента Internet Explorer;
  •  Единообразный вид экранных форм;
  •  Гибкость системы за счет использования технологии Инмета;
  •  Протоколирование всех действий пользователей в системе;
  •  Возможность связи любых реестровых объектов с пространственными объектами ГИС;

Структура АИС «ИМУЩЕСТВО»

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

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

Контроль включения и исключения объектов из реестра муниципальной собственности.

Формирование имущественных комплексов, передаваемых в оперативное управление или хозяйственное ведение.

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

Подсистема «Аренда» предназначена для учета и контроля всех этапов работы с договорами аренды муниципального имущества.

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

Подсистема «Администрирование» осуществляет предоставление доступа пользователям системы в соответствии с определенными для них правами и контроль выполняемых пользователями действий.

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

  •  Карта учета для КУМИ
  •  Карта учета для организации.

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

Подсистема «Приватизация» служит для учета процессов приводящих к изменению вида собственности на объекты учета.

Подсистема «Документооборот» предназначена для учета документов, используемых при работе с объектами учета:

Учет входящих и исходящих писем и документов;

«Привязка» документов к реестровым объектам и договорам;

Подготовка основных отчетов и статистики по работе отделов и конкретных сотрудников;

Хранение электронных копий документов.

Учет работы юридических служб.

Рис. 1.7. АИС «ИМУЩЕСТВО»

1.2. Системы разработки программного обеспечения.
Достоинства и недостатки.

Рассмотрим несколько систем:

  •  Eclipse
  •  Visual basic
  •  Delphi

Рис. 1.8. Язык Eclipse

Eclipse — свободный Фреймворк для разработки модульных кросс-платформенных приложений.

Изначально проект разрабатывался в IBM как корпоративный стандарт IDE для разработки на разных языках под платформы IBM. Потом проект был переименован в Eclipse и предоставлен для дальнейшего развития сообществу.

Eclipse в первую очередь полноценная Java IDE, нацеленная на групповую разработку, снабжённая средствами для работы с системами контроля версий (поддержка CVS входит в поставку Eclipse, активно развиваются несколько вариантов SVN модулей, существует поддержка VSS и других). В силу бесплатности во многих организациях Eclipse — корпоративный стандарт для разработки приложений.

Второе назначение Eclipse — служить платформой для разработки новых расширений (чем и завоевал популярность — любой разработчик может расширить Eclipse своими модулями). Таковыми стали C/C++ Development Tools (CDT), разрабатываемые инженерами QNX совместно с IBM, COBOL, FORTRAN, PHP средства от различных разработчиков. Множество расширений дополняет Eclipse менеджерами для работы с базами данных, серверами приложений и др. С версии 3.0 Eclipse стал не монолитной IDE, поддерживающей расширения, а набором расширений. В основе лежат фреймворк OSGi и SWT/JFace, на основе которых разработан следующий слой — платформа для разработки полноценных клиентских приложений RCP (Rich Client Platform — (англ. rich-client applications). Платформа RCP служит основой для RCP-приложений, таких как Azareus и File Arranger. Следующий слой — платформа Eclipse, представляющая собой набор расширений RCP — редакторы, панели, перспективы, модуль CVS и модуль Java Development Tools (JDT). Eclipse написана на Java, потому является платформо-независимым продуктом, за исключением библиотеки SWT, которая разрабатывается для всех распространённых платформ. Библиотека SWT используется вместо «медленного» Swing и полностью зависит от нижележащей платформы (операционной системы), что обеспечивает быстроту и натуральный внешний вид пользовательского интерфейса. Основой Eclipse является платформа расширенного клиента (RCP — от англ. rich client platform). Её составляют следующие компоненты:

  •  Ядро платформы (загрузка Eclipse, запуск модулей);
  •  OSGi (стандартная среда поставки комплектов);
  •  SWT (портируемый инструментарий виджетов);
  •  JFace (файловые буферы, работа с текстом, текстовые редакторы);
  •  Рабочая среда Eclipse (панели, редакторы, проекции, мастеры).

GUI в Eclipse написан с использованием инструментария SWT. Последний, в отличие от Swing (который лишь эмулирует отдельные графические элементы используемой платформы), действительно использует графические компоненты данной системы. Пользовательский интерфейс Eclipse также зависит от промежуточного слоя GUI, называемого JFace, который упрощает построение пользовательского интерфейса, базирующегося на SWT. Гибкость Eclipse обеспечивается за счёт подключаемых модулей, благодаря чему возможна разработка не только на Java, но и на других языках, таких как C/C++, Perl, Ruby, Python, PHP, ErLang и прочие.

Рис. 1.9. Интерфейс языка Eclipse

Visual Basic

В 1991г. фирмой Microsoft был разработан и выпущен Visual Basic. Microsoft Visual Basic — средство разработки программного обеспечения, разрабатываемое корпорацией Microsoft и включающее язык программирования и среду разработки. Язык Visual Basic унаследовал дух, стиль и отчасти синтаксис своего предка — языка Бейсик, у которого есть немало диалектов. В то же время Visual Basic сочетает в себе процедуры и элементы объектно-ориентированных и компонентно-ориентированных языков программирования. Среда разработки VB включает инструменты для визуального конструирования пользовательского интерфейса.

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

Первое признание серьёзными разработчиками Visual Basic получил после выхода версии 3 — VB3. Окончательное признание как полноценного средства программирования для Windows — при выходе версии 5 — VB5. Версию VB6, входящую в состав Microsoft Visual Studio 6. 0, стала по-настоящему зрелым и функционально богатым продуктом.

Поддержка операционных систем только семейства Windows (Исключение — VB1 for DOS). Отсутствие механизма наследования объектов. Существующие в языке наследование, позволяет наследовать только интерфейсы объектов, а не их самих. Таким образом, в унаследованном классе должны быть явно переписаны все функции базового класса. Также в унаследованном классе невозможно добавление каких-либо методов, присущих только даннному классу, то есть если абстрактный базовый класс содержит только два метода, то и производный класс содержит только два метода, не более и не менее того. Требует установленных DLL для работы программы.

Delphi

Простота, скорость и эффективность Delphi объясняют ее популярность. Delphi имеет один из самых быстрых компиляторов, порождающий, тем не менее, весьма и весьма неплохой объектный код. Есть и другие достоинства: простота изучения Object Pascal; облегчающие жизнь нововведения - вроде свойств (properties); программы, написанные на Delphi, не требуется снабжать дополнительными библиотеками (в отличие от связки C++/MFC). В самом деле, VCL предоставляет удобный, легко расширяемый объектно-ориентированный интерфейс к Windows, что ни в коей мере не мешает программисту опускаться в самые глубины Windows API.

Создателям оригинальных компонентов это приходится делать довольно часто, в отличие от "просто программистов". Как было сказано выше, модель программирования в Delphi - компонентная, что позволяет пользоваться компонентами, написанными другими разработчиками, даже не имея их исходного кода и уж подавно не изучая его. В Интернете есть огромное количество компонентов, значительная часть которых распространяется бесплатно. Применение компонентной модели приводит к тому, что довольно многое в поведении объектов программировать не нужно вообще, и многое, на что в других средах ушли бы недели, можно сделать за часы или даже минуты. Оно и понятно - это ведь RAD-среда. К достоинствам можно отнести очень быстрый браузер классов и мгновенный вывод подсказки автозавершения кода (code completion). Если кратко - может все.

Delphi – не просто язык. Это чрезвычайно мощная и удобная интегрированная среда (IDE), заслуживающая самых высоких похвал. Ни один компилятор C++, включая Visual C++, не предоставляет нам столь дружественной, интуитивно понятной, простой в использовании и вместе с тем столь многофункциональной оболочки как Delphi. Что бы не говорили ребята из Microsoft о том, что своим Visual Studio они предоставляют пользователю средства быстрой разработки приложений с графическим интерфейсом, ничего лучше Delphi в плане скорости и удобства, по-моему, просто не существует. Исходя из этих соображений многие программисты отдают предпочтение Delphi.

Да, Delphi - не просто язык! Это своя система! Система в системе!

Object Pascal, лежащий в основе Delphi, обогащен множеством типов и классов, позволяющих полноценно использовать возможности программирования под Windows. Практически все, что можно создать с помощью C++, реализуемо и на Object Pascal, причем, благодаря простоте и лучшей структурированности Паскаля, программа получается более четкой, удобной для восприятия, и, что самое главное, более надежной, чем написанная на C++. Отдельно следует сказать о базах данных. В Delphi введены мощные средства поддержки работы с данными, позволяющие очень просто создавать приложения, связанные с базами данных. В этой области Delphi, пожалуй, вообще не имеет конкурентов. Учитывая то, что работа с базами данных является одной из основных задач программиста, последнее еще более укрепляет положение Delphi как превосходного средства разработки программного обеспечения. Поскольку Delphi является самым простым и удобным среди всех мощных пакетов,  там, где потребуется высокая надежность, - в приложениях для бизнеса и деловой сферы – Delphi просто незаменим.

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

Наряду с коммерческими системами в мире SQL-ориентированных СУБД существуют и развиваются системы, разрабатываемые и распространяемые на основе подхода «открытых исходных текстов» (open source). Среди них наиболее известны MySQL2, PostgreSQL3 и Firebird4. В этих системах интересны не только способы их разработки, технические особенности и области применения, но также и то, что в их развитии и совершенствовании активно участвуют, в том числе, и российские разработчики.  В этом разделе приводится общая характеристика систем, рассматриваются различия в их организации и способах разработки. Обсуждается, в каких областях эти системы могут конкурировать с коммерческими системами, и указываются основные проблемы, которые предстоит решить для обеспечения надежной жизнеспособности SQL-ориентированных СУБД с открытыми кодами.

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

В начале 2008 г. компания MySQL AB была приобретена компанией Sun Microsystems. Sum Microsystems заявляет, что новая СУБД MySQL корпорации Sun Microsystems является ключевым компонентом популярных программных комплексов для создания приложений Web 2.0.

Текущим выпуском системы является MySQL Enterprise Server 5.1. Версия 5.4 появилась в тестовой бета-версии в апреле 2009 г., в середине 2009 г. В виде тестовой альфа-версии появилась версия 6.0. По сравнению с предыдущей версией 5.0, вышедшей в октябре 2005 г., в MySQL 5.1 появился ряд новых возможностей, которые компания MySQL AB относит к областям хранилищ данных и интеллектуального анализа данных; средств обеспечения высокой доступности данных; упрощенного управления и средств обеспечения высокой производительности. 

В области хранилищ данных и интеллектуального анализа данных основным нововведением является средство горизонтального разделения таблиц и индексов (по диапазону значений, с хэшированием и т.д.). Разделение таблиц возможно для всех подсистем хранения данных, используемых в MySQL: MyISAM, Archive, InnoDB и т.д. Кроме того, к этой области относится новый подключаемый модуль, поддерживающий полнотекстовый поиск, и поддержка XPath для работы с XML-данными с возможностью выбора и модификации узлов XML-документов на стороне сервера баз данных. 

Для повышения уровня доступности данных наряду с механизмом репликации на основе операторов SQL, существовавшим в MySQL 5.0, в MySQL 5.1 обеспечивается средство репликации таблиц на уровне строк. В MySQL Cluster появилась поддержка данных, сохраняемых в дисковой памяти, и также обеспечивается возможность асинхронной репликации данных из одного кластера в другой. 

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

В MySQL 6.0 планируется реализовать новую подсистему управления данными Falcom, обеспечивающая полную поддержку транзакций со свойствами ACID. Эта подсистема не предназначена для замены транзакционной подсистемы управления данными InnoDB, но, по мнению разработчиков, в ряде случаев будет работать более эффективно. Кроме того, в MySQL 6.0 должны обеспечиваться поддержка неблокирующих вариантов операций, изменяющих схему таблиц, а также ожидается ряд нововведений в оптимизаторе запросов SQL. 

 СУБД PostgreSQL. Под названием PostgreSQL система существует с 1996 года. Это название отражает связь PostgreSQL с оригинальным проектом Postgres и внедрением в систему поддержки языка SQL. Управление проектом осуществляет небольшая группа инициативных пользователей и разработчиков, называемая PGDG (PostgreSQL Global Development Group).
В начале февраля 2008 г. была выпущена СУБД PostgreSQL 8.3, в работе над которой принимали участие десятки разработчиков из 18 стран. В течение 15 месяцев разработки и тестирования были обработаны и успешно внедрены более 280 пакетов изменений исходного кода.

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

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

Наиболее существенным изменением PostgreSQL, затрагивающим интересы разработчиков приложений, является миграция модуля полнотекстового поиска tsearch2 в ядро системы. Другое заметное изменение – поддержка XML. Появился специальный тип данных xml, встроенный в ядро. В соответствии со стандартом SQL:2003 реализован набор функций для преобразования реляционных данных в XML – функции публикации SQL/XML. Для ускорения выполнения запроса к XML-данным возможно использование функциональных индексов и GIN-индексов, а также использования полнотекстового поиска для XML-данных.

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

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

  •  подключения к внешним источникам данных SQL/MED (Management of External Data);
  •  доступ только к индексам при некоторых выборках;
  •  анонимные блоки на любом доступном языке хранимых процедур;
  •  отложенные ограничения уникальности;
  •  более удобный синтаксис для секционированных таблиц;
  •  горячий резерв;
  •  планы запросов в виде JSON и XML;
  •  триггеры, срабатывающие при обновлении определённых колонок таблицы.

Продукты на основе исходных текстов PostgreSQL производит не только сообщество PostgreSQL под управлением PGDG, но и коммерческие компании, наиболее известной среди которых является EnterpriseDB Corporation5. Эта компания выпускает свободно доступный продукт Postgres Plus и совместимую с Oracle коммерческую систему Postgres Plus Advanced Server. Наиболее интересным и совершенно новым для мира PostgresSQL является интегрированный с Postgres Plus продукт GridSQL, в котором реализуется архитектура распределенных баз данных без общих ресурсов между узлами. 

СУБД Firebird. Как говорится на официальном сайте проекта6, «Firebird – это коммерчески независимый проект программистов сообщества C/C++, технических консультантов и спонсоров, разрабатывающих и совершенствующих мультиплатформенную реляционную СУБД, основанную на исходных кодах, которые были переданы в свободное использование 25 июля 2000 г. компанией Inprise Corp. (Borland Software Corp)». Речь идет про исходные тексты СУБД InterBase 6.0. 

Коммерческую линию развития этой системы продолжались фирмой Borland. В апреле 2008 г. после двухлетней работы команды разработчиков, значительную часть которой составляют российские специалисты, была выпущена версия Firebird 2.1. В сентябре 2009 выпущена версия 2.1.3. В этой версии улучшены средства администрирования баз данных, повышена производительность системы и введена поддержка ряда новых средств языка SQL.

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

На уровне SQL появилась возможность определения триггеров, условием срабатывания которых являются подключение к базе данных, начало, фиксация и откат транзакции и т.д. Появилась возможность использования глобальных временных таблиц и общих табличных выражений, которые, в частности, можно использовать для формулировки рекурсивных запросов. Введена конструкция UPDATE OR INSERT, срабатывающая как UPDATE, если условию оператора соответствует хотя бы одна строка целевой таблицы, и как INSERT в противном случае. Наконец, поддерживается оператор MERGE, позволяющий слить две таблицы. Следует заметить, что не все введенные средства SQL присутствуют в стандарте языка. 

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

Выпуск Firebird 2.5, тестовая версия которой (Firebird 2.5 RC 1) появилась в декабре 2009 г., разработчики рассматривают как важный шаг на пути к СУБД Firebird 3.0, которая будет представлять собой параллельный масштабируемый сервер с универсальной архитектурой, ориентированной на симметричные мультипроцессоры.

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

ГЛАВА 2. РАЗРАБОТКА БАЗЫ ДАННЫХ MunicipalEstateDB

2.1. Инфологическая модель базы данных

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

Рис. 2.1. Содержимое файла финансового учета КУМИ РМР

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

Разделим этот файл  на несколько частей.

Первая часть. ФИО и почтовый адрес – фамилия, имя и отчество арендатора, и соответственно почтовый адрес (рис. 2.2).

Рис. 2.2. ФИО и почтовый адрес

Вторая часть – номер и дата заключения договора (рис. 2.3).

Рис. 2.3. Номер и дата заключения договора

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

Рис. 2.4. Информация о земельных участках

Четвертая часть – цель предоставления земельного участка. Она содержит данные о назначении земель (рис. 2.5).

Рис. 2.5. Цель предоставления земельного участка

Пятая часть – это арендная плата. Она включает в себя: базовый размер арендной платы, общая задолженность, № платежного поручения, ну и сам платеж за каждый год (рис. 2.6).

Рис. 2.6. Арендная плата

2.2. Физическая модель базы данных MunicipalEstateDB

База данных MunicipalEstateDB, разработанная в программе MicroOLAP Database Designer for MySQL [15], представлена на рисунке 2.7.

Рис. 2.7. Физическая модель базы данных MunicipalEstateDB

Для более удобного представления, данную модель рассмотрим в виде следующих частей:

  1.  Адреса. В этой части содержатся данные о регионах, городах и поселениях.
  2.  Арендаторы. В этой части содержатся данные об арендаторах: физических лицах,  организациях.
  3.  Доверенное лицо. Здесь содержится информация о доверенных лицах.
  4.  Договоры. В этой части содержатся данные о договорах клиентов.
  5.  Арендная плата. Эта часть включает в себя информацию о платежах клиентов.

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

2.3. Раздел  базы данных «Арендаторы»

Раздел базы данных «Арендаторы» состоит из 10 таблиц (рис. 2.8):

Рис. 2.8. Физическая модель базы данных «арендаторах»

  1.  Customer – содержит информацию об арендаторах и является связующей.
  2.  Organization – содержит список организаций.
  3.  FirstName – содержит информацию об имени арендатора.
  4.  MiddleName – содержит информацию об отчестве арендатора.
  5.  Position – содержит информацию о должности арендатора.
  6.  PassportAuthority – содержит информацию о паспортных данных.
  7.  PassportBirthPlace – место рождения.
  8.  Sity –список адресов.
  9.  Street –названия улиц.
  10.   Bank –названия банков.

Сущность Customer имеет следующие атрибуты (рис. 2.9):

Рис. 2.9. Атрибуты сущности  Customer

  1.  CustomerID-идентификатор арендатора (первичный ключ).
  2.  OrganizationID-идентификатор организации (внешний ключ).
  3.  FirstNameID-идентификатор имени арендатора (внешний ключ).
  4.  LastName-фамилия арендатора.
  5.  MiddleNameID-идентификатор отчества арендатора (внешний ключ).
  6.  PositionID- идентификатор должности арендатора (внешний ключ).
  7.  Birthday-дата рождения арендатора.
  8.  PassportSeries-серия паспорта арендатора.
  9.  PassportNumber-номер паспорта арендатора.
  10.  PassportAuthorityID- идентификатор того кем выдан паспорт (внешний ключ)
  11.  PassportDateOfIssue-дата выдачи паспорта арендатора.
  12.  PassportCode-код подразделения  паспорта арендатора.
  13.  PassportBirthPlaceID- идентификатор места рождения (внешний ключ).
  14.  IndexA-индекс адреса арендатора.
  15.  SityID-идентификатор названия адреса (внешний ключ).
  16.  StreetID-идентификатор названия улицы(внешний ключ).
  17.  Home-номер дома.
  18.  Building-корпус здания.
  19.  Flat-номер квартиры.
  20.  WorkTelephon-рабочий телефон.
  21.  HomeTelephon-домашний телефон.
  22.  MobileTelephon-мобильный телефон.
  23.  Kind
  24.  PayAccount
  25.  CorAccount
  26.  BIK- бик арендатора (юридического лица).
  27.  BankID-идентификатор названия банка.
  28.  INN-инн арендатора (юридического лица).
  29.  KPP- кпп арендатора (юридического лица).

Сущность FirstName имеет следующие атрибуты (рис. 2.10):

Рис. 2.10. Атрибуты сущности  FirstName

  1.  FirstNameID – идентификатор фамилии (первичный ключ).
  2.  SexID – идентификатор пола (внешний ключ)
  3.  Name – имя.

Сущность Sex имеет следующие атрибуты (рис. 2.11):

Рис. 2.11. Атрибуты сущности Sex

  1.  SexID – идентификатор пола (первичный ключ).
  2.  FullName – сокращенное название пола.
  3.  Name – название пола.

Сущность MiddleName имеет следующие атрибуты (рис. 2.12):

Рис. 2.12. Атрибуты сущности MiddleName

  1.  MiddleNameID – идентификатор отчества (первичный ключ).
  2.  Name – отчество.
  3.  SexID – идентификатор пола (внешний ключ).

Сущность Organization имеет следующие атрибуты (рис. 2.13):

Рис. 2.13. Атрибуты сущности Organization

  1.  OrganizationID – идентификатор организации (первичный ключ).
  2.  OrganizationKindID – идентификатор названия вида организации (внешний ключ).
  3.  FullName – полное название организации.
  4.  Name – название организации.
  5.  IndexA –индекс организации.
  6.  SityID – идентификатор адреса (внешний ключ).
  7.  StreetID – идентификатор названия улицы (внешний ключ).
  8.  Home – номер дома.
  9.  Building – название корпуса.
  10.  Flat – номер квартиры.

Сущность OrganizationKind имеет следующие атрибуты (рис. 2.14):

Рис. 2.14. Атрибуты сущности OrganizationKind

  1.  OrganizationKind-идентификатор названия вида организации(первичный ключ).
  2.  FullName-полное название вида организации.
  3.  Name-название вида организации.

Сущность Position имеет следующие атрибуты (рис. 2.15):

Рис. 2.15. Атрибуты сущности Position

  1.  PositionID- идентификатор названия должности арендатора (первичный ключ).
  2.  Name-название должности.

Сущность PassportAuthority имеет следующие атрибуты (рис. 2.16):

Рис. 2.16. Атрибуты сущности PassportAuthority

  1.  PassportAuthorityID-идентификатор названия органа выдачи паспорта (первичный ключ).
  2.  Name-название органа.

Сущность Bank имеет следующие атрибуты (рис. 2.17):

Рис. 2.17. Атрибуты сущности Bank

  1.  BankID-идентификатор названия банка(первичный ключ).
  2.  Name-название банка.

2.4. Раздел  базы данных «Адреса»

Раздел базы данных «Адреса» состоит из 6 таблиц (рис. 2.18):

  1.  Region – содержит перечень регионов.
  2.  Province – содержит перечень областей, районов.
  3.  Sity – содержит перечень адресов.
  4.  SityKind – название вида населённого пункта.
  5.  SityShortName – сокращенное название населенного пункта. 
  6.  Street – список названий улиц.

Так же, с подробным описанием рассмотрим каждую из данных сущностей.

Рис. 2.18. Физическая модель раздела базы данных «Адреса»

Сущность Region имеет следующие атрибуты (рис. 2.19):

Рис. 2.19. Атрибуты сущности  Region

  1.  RegionID – идентификатор названия региона (первичный ключ).
  2.  Name – название региона.
  3.  Code – номер региона.
  4.  ShortName – сокращенное название.

Сущность Province имеет следующие атрибуты (рис. 2.20):

Рис. 2.20. Атрибуты сущности  DisciplineUnion

  1.  ProvinceID – идентификатор названия области (первичный ключ).
  2.  RegionID – идентификатор названия региона (внешний ключ).
  3.  Name – название области.

Сущность Sity имеет следующие атрибуты (рис. 2.21):

Рис. 2.21. Атрибуты сущности  Sity

  1.  SityID – идентификатор населенного пункта (первичный ключ).
  2.  ProvinceID – идентификатор области (внешний ключ).
  3.  Name – название населенного пункта.
  4.  SityShortNameID – идентификатор сокращенного названия населенного пункта (внешний ключ).
  5.  SityKindID-идентификатор вида населенного пункта (внешний ключ).

Сущность SityKind имеет следующие атрибуты (рис. 2.22):

Рис. 2.22. Атрибуты сущности  SityKind

  1.  SityKindID – идентификатор вида населенного пункта (первичный ключ).
  2.  Name – название вида населенного пункта.

Сущность SityShortName имеет следующие атрибуты (рис. 2.23):

Рис. 2.23. Атрибуты сущности  SityShortName

  1.  SityShortNameID – идентификатор сокращенного названия вида    населенного пункта (первичный ключ).
  2.  Name – полное название вида населенного пункта.
  3.  ShortName – сокращенное название населенного пункта.

Сущность Street имеет следующие атрибуты (рис. 2.24):

Рис. 2.24. Атрибуты сущности  Street

  1.  StreetID – идентификатор названия улицы (первичный ключ).
  2.  Name – название улицы.

2.5. Раздел базы данных «Доверенное лицо»

В данном разделе представлена следующая физическая модель «Доверенное лицо», которая состоит из 2 таблиц (рис. 2.25):

Рис. 2.25. Физическая модель базы данных «Доверенное лицо»

  1.  NotaryCustomer – содержит информацию об доверенных лицах и является связующей.
  2.  FirstName – содержит информацию об имени доверенного лица.
  3.  MiddleName – содержит информацию об отчестве доверенного лица.
  4.  PassportAuthority – содержит информацию о паспортных данных.
  5.  PassportBirthPlace – место рождения.
  6.  Sity – информация об адресе.
  7.  Street – название улицы.

Сущность NotaryCustomer имеет следующие атрибуты (рис. 2.26):

Рис. 2.26. Атрибуты сущности  NotaryCustomer

  1.  NotaryCustomerID – идентификатор арендатора (первичный ключ).
  2.  FirstNameID – идентификатор имени арендатора (внешний ключ).
  3.  LastName-фамилия арендатора.
  4.  MiddleNameID-идентификатор отчества арендатора (внешний ключ).
  5.  Birthday-дата рождения арендатора.
  6.  PassportSeries-серия паспорта арендатора.
  7.  PassportNumber-номер паспорта арендатора.
  8.  PassportAuthorityID- идентификатор органа выдачи паспорта (внешний ключ).
  9.  PassportDateOfIssue-дата выдачи паспорта арендатора.
  10.  PassportCode-код подразделения  паспорта арендатора.
  11.  PassportBirthPlaceID- идентификатор места рождения (внешний ключ).
  12.  IndexA-индекс адреса арендатора.
  13.  SityID-идентификатор названия адреса (внешний ключ).
  14.  StreetID-идентификатор названия улицы(внешний ключ).
  15.  Home-номер дома.
  16.  Building-корпус здания.
  17.  Flat-номер квартиры.
  18.  WorkTelephon-рабочий телефон.
  19.  HomeTelephon-домашний телефон.
  20.  MobileTelephon-мобильный телефон.

2.6. Раздел базы данных «Договоры»

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

Рис. 2.27. Физическая модель базы данных «Договоры»

  1.  Contract – содержит информацию договорах.
  2.  NotaryCustomer – содержит информацию о доверенных лицах.
  3.  Customer – содержит информацию об арендаторах.
  4.  SteadPurpose назначения земель.
  5.  ContractEndReason причина расторжения договора.
  6.  Notary нотариус.
  7.  Settlement  
  8.  NotaryAddress- адрес нотарисуса.
  9.  PaymentKind – вид оплаты.
  10.  ContractFullEndReason – причина завершения договора.
  11.  Street-название улицы.
  12.  SteadCategory – категория земель.
  13.  SteadAddress – местоположения земель.
  14.  CurrentNumber-текущий номер.
  15.  Years – года.

Сущность Contract имеет следующие атрибуты (рис. 2.28):

Рис. 2.28. Атрибуты сущности Contract

  1.  ContractID – идентификатор номера договора (первичный ключ).
  2.  CustomerID – идентификатор названия клиента (внешний ключ) .
  3.  CoCustomerID – идентификатор вида клиента (внешний ключ).
  4.  CustomerAID – идентификатор клиента (внешний ключ).
  5.  Number – номер договора.
  6.  BeginDate – дата начала договора.
  7.  Period – период договора.
  8.  EndDate –дата окончания договора.
  9.  Prolongation – пролонгация.
  10.  ResolutionNumber –номер постановления.
  11.  ResolutionDate –дата постановления.
  12.  RealDate
  13.  Visible – состояние договора: видимость.
  14.  Active – состояние договора: активность.
  15.  ContractEndReasonID –идентификатор причины расторжения договора (внешний ключ).
  16.  PaymentKindID – идентификатор вида оплаты (внешний ключ).
  17.  SettlementID
  18.  Area – площадь участка.
  19.  Cadaster – кадастровый номер.
  20.  SteadCategoryID – идентификатор категории земель (внешний ключ).
  21.  SteadPurposeID – назначения земель (внешний ключ).
  22.  SteadAddressID – местоположение земельного участка (внешний ключ).
  23.  Landmark – ориентиры.
  24.  StreetID – идентификатор названия улицы.
  25.  Home – номер дома.
  26.  Building – номер здания.
  27.  Flat – номер квартиры.
  28.  Share – доля.
  29.  FullEndDate 
  30.  ContractFullEndReasonID – идентификатор причины завершения договора.
  31.  Comment –комментарии.
  32.  Color – цвет.
  33.  ToPay – к оплате.
  34.  ToFullPay – арендная плата.
  35.  NotaryCustomerID –идентификатор доверенного лица (внешний ключ).
  36.  NotaryID – идентификатор  нотариуса.
  37.  NotaryNumber –номер доверенности.
  38.  NotaryDate – дата доверенности.
  39.  Encumbrance –обременения.
  40.  Limitation – ограничения.
  41.  ContractBeforeInsert – триггер, предназначенный для

Тело триггера:

Рис. 2.29. Описание триггера ContractBeforeInsert

Сущность PaymentKind имеет следующие атрибуты (рис. 2.30):

Рис. 2.30. Атрибуты сущности PaymentKind

  1.  PaymentKindID – идентификатор вида оплаты (первичный ключ).
  2.  FullName – полное название вида оплаты.
  3.  Name – название вида оплаты.

Сущность SteadPurpose имеет следующие атрибуты (рис. 2.31):

Рис. 2.31. Атрибуты сущности SteadPurpose

  1.  SteadPurposeID – идентификатор названия назначения земель (первичный ключ).
  2.  FullName – полное название назначения земель.
  3.  Name – краткое название назначения земель.

Сущность ContractFullEndReason  имеет следующие атрибуты (рис. 2.32):

Рис. 2.32. Атрибуты сущности ContractFullEndReason  

  1.  ContractFullEndReasonID – идентификатор причины завершения договора (первичный ключ).
  2.  Name – название причины завершения договора.

Сущность ContractFullEndReason  имеет следующие атрибуты (рис. 2.33):

Рис. 2.33. Атрибуты сущности ContractEndReason  

  1.  ContractEndReasonID – идентификатор причины расторжения договора (первичный ключ).
    1.  Name – название причины расторжения договора.

Сущность Notary имеет следующие атрибуты (рис. 2.34):

Рис. 2.34. Атрибуты сущности Notary

  1.  NotaryID – идентификатор ФИО нотариуса (первичный ключ).
  2.  Name – ФИО нотариуса.
  3.  NotaryAddressID – идентификатор наименования адреса нотариуса (внешний ключ).

Сущность NotaryAddress имеет следующие атрибуты (рис. 2.35):

Рис. 2.35. Атрибуты сущности NotaryAddress

  1.  NotaryAddressID – идентификатор названия адреса нотариуса (первичный ключ).
  2.  Name – наименование адреса.

Сущность SteadCategory имеет следующие атрибуты (рис. 2.36):

Рис. 2.36. Атрибуты сущности SteadCategory

  1.  SteadCategoryID – идентификатор названия категории земель (первичный ключ).
  2.  FullName – полное название категории земель.
  3.  Name – краткое название категории земель.

Сущность SteadAddress имеет следующие атрибуты (рис. 2.37):

Рис. 2.37. Атрибуты сущности SteadAddress

  1.  SteadAddressID – идентификатор названия местоположения земельного

участка (первичный ключ).

  1.  Name – название местоположения участка.
  2.  ShortName – краткое название местоположения участка.
  3.  Cadaster – кадастровый номер.

Сущность CurrentNumber имеет следующие атрибуты (рис. 2.38):

Рис. 2.38. Атрибуты сущности CurrentNumber

  1.  YearID – идентификатор наименования текущего номера договора (первичный ключ)
  2.  Number – текущий номер.

Сущность Years имеет следующие атрибуты (рис. 2.39):

Рис. 2.39. Атрибуты сущности Years

  1.  YearID – идентификатор наименования года (первичный ключ).

Сущность Settlement имеет следующие атрибуты (рис. 2.40):

Рис. 2.40. Атрибуты сущности Settlement

  1.  SettlementID – идентификатор названия (первичный ключ).
  2.  ProvinceID –
  3.  Name –
  4.  Code

2.7. Раздел базы данных «Арендная плата»

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

Рис. 2.41. Физическая модель базы данных «Арендная плата»

  1.  Payment – содержит информацию о платежах физических и юридических лиц.
  2.  PaymentDept
  3.  TaxCost данные о налоговой стоимости.
  4.  Contract – содержит информацию о договорах.
  5.  Years – года.
  6.  CurrentNumber – информация о текущем номере.

Сущность Payment имеет следующие атрибуты (рис. 2.42):

Рис. 2.42. Атрибуты сущности «Payment»

  1.  PaymentID – идентификатор
  2.  YearID – идентификатор
  3.  ContractID – идентификатор
  4.  First – первый квартал.
  5.  FirstNumber –
  6.  FirstDate – дата первого квартала.
  7.  Second – 2 квартал.
  8.  SecondNumber –
  9.  SecondDate – дата второго квартала.
  10.  Third – 3 квартал.
  11.  ThirdNumber –
  12.  ThirdDate – дата третьего квартала.
  13.  Fourth – 4 квартал.
  14.  FourthNumber –
  15.  FourthDate – дата четвертого квартала.
  16.  Comment – комментарии.

Сущность PaymentDept имеет следующие атрибуты (рис. 2.43):

Рис. 2.43. Атрибуты сущности «PaymentDept»

  1.  ContractID – идентификатор наименования номера договора (первичный ключ).
  2.  YearID – идентификатор наименования года (первичный ключ).
  3.  Dept –

Сущность TaxCost имеет следующие атрибуты (рис. 2.44):

Рис. 2.44. Атрибуты сущности «TaxCost»

  1.  ContractID – идентификатор наименования номера договора (первичный ключ).
  2.  YearID – идентификатор наименования года (первичный ключ).
  3.  Cost – стоимость.
  4.  UnionCost – удельная стоимость.
  5.  TaxRate – налоговая ставка.
  6.  Rate – коэффициент.
  7.  Rate2 – коэффициент 2.

2.8. Таблицы отчетов 

Таблицы отчетов предназначен для хранения в базе данных готовых формуляров отчетов, и они состоят из 2 сущностей (рис. 2.45):

  1.  Reports – содержит информацию для формирования отчета.
  2.  ReportGroup – формирует группы отчетов.

Рис. 2.45. Таблицы отчетов

Сущность Reports имеет следующие атрибуты (рис. 2.46):

Рис. 2.46. Атрибуты сущности Reports

  1.  ReportID – идентификатор отчета.
  2.  ReportGroupID – идентификатор группы отчетов.
  3.  Name – название отчета.
  4.  Author – автор отчета.
  5.  Description – описание отчета.
  6.  CreateDate – дата создания отчета.
  7.  LastChange – дата последнего изменения отчета.
  8.  VersionRelease – номер версии отчета.
  9.  VersionBuild – подномер версии отчета.
  10.  Report – файл отчета.

Сущность ReportGroup имеет следующие атрибуты (рис. 2.47):

Рис. 2.47. Атрибуты сущности ReportGroup

  1.  ReportGroupID – идентификатор группы отчетов.
  2.  ReportGroupName – название группы отчетов.

2.9. Таблицы «Роли пользователей»

Раздел «Роли пользователей» предназначен для хранения стандартных режимов доступа к базе данных (рис. 2.48) и состоит из двух таблиц:

  1.  Roles – роли пользователей.
  2.  RoleNames – название роли.

Рис. 2.48. Таблицы «Роли пользователей»

Сущность Roles имеет следующие атрибуты (рис. 2.49):

Рис. 2.49. Атрибуты сущности Roles

  1.  RoleID – идентификатор роли.
  2.  RoleNameID – идентификатор названия роли.
  3.  RoleSQL-запрос определяющий режим доступа к базе данных.

Сущность RoleNames имеет следующие атрибуты (рис. 2.50):


Рис. 2.50. Атрибуты сущности RoleNames

  1.  RoleNameID – идентификатор названия роли.
  2.  RoleName – название роли.

2.10. Таблицы «Виды статистик»

Раздел «Виды статистик» предназначен для хранения стандартных SQL-запросов, обеспечивающих выборку необходимых статистических данных (рис. 2.51) для формирования статистических отчетов. Он состоить из двух таблиц:

  1.  StatisticKinds – виды статистик.
  2.  StatisticGroups – название групп статистик.

Рис. 2.51. Таблицы «Виды статистик»

Сущность StatisticKinds имеет следующие атрибуты (рис. 2.52):

Рис. 2.52. Атрибуты сущности StatisticKinds

  1.  StatisticKindID – идентификатор вида статистики
  2.  StatisticGroupID – идентификатор группы статистики.
  3.  StatisticKindName – название вида статистики.
  4.  StatisticKindSQL – SQL-запрос, определяющий статистику.

Сущность StatisticGroups имеет следующие атрибуты (рис. 2.53):

Рис. 2.53. Атрибуты сущности StatisticGroups

  1.  StatisticGroupID – идентификатор группы статистики.
  2.  StatisticGroupName – название группы статистик.

2.11. Таблица «Названия таблиц»

Данная таблица предназначена для переименования таблиц на русский язык и состоит из одной сущности TableName (рис. 2.54).

Рис. 2.54. Таблица «Названия таблиц»

2.12. Создание базы данных

С помощью программы MicroOLAP Database Designer for MySQL был создан SQL-скрипт для создания базы данных (рис. 2.55).

Рис. 2.55. SQL-скрипт для создания базы данных

Рис. 2.56. SQL-скрипт базы данных MunicipalEstateDB

Этот скрипт (рис. 2.56) был выполнен на сервере cs.rsu.edu.ru с помощью программы phpMyAdmin (рис. 2.57) [16].

Рис. 2.57. Вход в программу phpMyAdmin

Он был помещен на закладку выполнения SQL-запросов (рис. 2.58) , и после его выполнения была создана база данных MunicipalEstateDB на сервере MySQL (рис. 2.58).

Рис. 2.58. Выполнение SQL-запроса

Рис. 2.59. Созданная база данных MunicipalEstateDB

Для доступа к этой базе данных был создан пользователь p.kochanov (рис. 2.60), для которого был задан пароль и разрешен доступ с любого компьютера в сети.

Рис. 2.60. Создание нового пользователя

С помощью программы phpMyAdmin для этого пользователя были установлены привилегии доступа к базе данных MunicipalEstateDB (рис. 2.48).

Рис. 2.48. Установка привилегий уровня базы данных MunicipalEstateDB

Так как пользователь должен не только выбирать, создавать, редактировать и удалять данные, но и осуществлять операции по администрированию базы данных [17], ему были установлены дополнительные права (рис. 2.49).

Рис. 2.49. Установленные привилегии на базу MunicipalEstateDB для пользователя p.kochanov

ГЛАВА 3. СИСТЕМА УПРАВЛЕНИЯ БАЗОЙ ДАННЫХ MunicipalEstateDB

3.1. Разработка системы управления базой данных MunicipalEstateDB

Для управления базой данных была разработана программа «ФИНАНСОВЫЙ УЧЕТ КУМИ РМР» в среде Embarcadero RAD Studio XE (рис. 3.1).

Рис. 3.1. Интерфейс главной формы программы

Она представляет собой трехзвенную систему, включающую сервер баз данных, сервер приложений и «тонкий» клиент [18].

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

Каждый модуль данных имеет однотипную структуру, представленную на рисунке 3.2.

Рис. 3.2. Интерфейс модуля данных

В каждом модуле предусмотрены следующее элементы:

  1.  YearConnection – для подключения к базе данных.
  2.  YearDataSet – для доступа к таблицам базы данных.
  3.  LocalConnection – для соединения с тонким клиентом.
  4.  DataSetProvider – для передачи данных между сервером и клиентом.
  5.  Year – для хранения локальных данных.
  6.  YearDS – для отображения локальных данных.
  7.  YearGVR – для представления локальных данных.
  8.  YearER – для подстановки локальных данных в другие клиенты.
  9.  cxPropertiesStore – для хранения пользовательских настроек отображения данных.

Компонент YearConnection предназначен для подключения к базе данных MunicipalEstateDB, расположенной на сервере MySQL. Для этого устанавливаются необходимые параметры подключения в инспекторе объекта: имя сервера, имя базы данных, порт, имя пользователя и пароль (рис. 3.3).

Рис. 3.3. Свойства компонента YearConnection

Компонент DataSet [19] предназначен для получения данных из базы данных MunicipalEstateDB с помощью SQL-запросов (рис. 3.4).

Рис. 3.4. Свойства компонента YearDataSet

В нем существует редактор, который позволяет написать запросы для выбора данных (рис. 3.5), вставки данных (рис. 3.6), редактирования данных (рис. 3.7) и удаления данных (рис. 3.8) [20].

Рис. 3.5. SQL-запрос для выбора данных

Рис. 3.6. SQL-запрос для вставки данных

Рис. 3.7. SQL-запрос для редактирования данных

Рис. 3.8. SQL-запрос для удаления данных

Для организации тонкого клиента предусмотрен компонент LocalConnection (рис. 3.9), который обеспечивает передачу данных от компонента YearDataSet компоненту Year и наоборот, используя провайдер DataSetProvider (рис. 3.10).

Рис. 3.9. Свойства компонента LocalConnection

Рис. 3.10. Свойства компонента DataSetProvider

Компонент Year предназначен для хранения локальной копии данных, полученной из базы данных MunicipalEstateDB с помощью компонента DataSetProvider (рис. 3.11).

Рис. 3.11. Свойства компонента Year

Для отображения этих данных используется источник данных YearDS (рис. 3.12), который связан с локальной копией данных, хранящейся в компоненте Year.

Рис. 3.12. Свойства компонента YearDS

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

Рис. 3.13. Свойства компонента YearGVR

Рис. 3.14. Отображение компонента YearGridView

Отображаемые данные на форме могут использоваться в качестве подстановочных для других наборов данных. Для этого предусмотрен компонент YearER (рис. 3.15).

Рис. 3.15. Репозиторий редактора подстановок

Для хранения пользовательских настроек отображения данных используется компонент PropertiesStore (рис. 3.16).

Рис. 3.16. Свойства компонента PropertiesStore

Аналогичным образом, разработаны все остальные элементы программы.


3.2. Работа с программой «ФИНАНСОВЫЙ УЧЕТ КУМИ РМР 2012»

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

Рис. 3.42. Окно входа в программу

После указания пароля и имени пользователя открывается главное окно программы (рис. 3.43).

Рис. 3.43. Главное окно программы
На закладке «Настройка» необходимо указать адрес сервер лицензий и MySQL сервера базы данных, выбрав команду «Параметры» (рис. 3.44).

Рис. 3.44. Настройка подключения к серверу MySQL

Для тестирования подключения можно нажать на кнопку «Тест подключения». Если подключение произошло удачно, то выводится соответствующее сообщение (рис. 3.45). В противном случае, либо сервер лицензий не позволяет осуществить доступ к программе, либо не правильно указано имя или пароль пользователя (рис. 3.46).

 

Рис. 3.45. Удачное подключение к серверу MySQL

Рис. 3.46. Неудачное подключение к серверу MySQL

После удачного подключения можно редактировать данные в программе «ФИНАНСОВЫЙ УЧЕТ КУМИ РМР 2012».

  1.  Раздел «Адреса». В этом разделе присутствует возможность редактирования названий регионов, городов, районов, улиц, населенных пунктов и их видов:

Рис. 3.47. Окно программы «Адреса»

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

Рис. 3.48. Окно программы «Арендаторы»

  1.  Доверенное лицо, где задается имя, отчество и пол. Номер доверенности и дата доверенности  (рис. 3.49).

Рис. 3.49. Окно программы «Доверенное лицо»

  1.  Земельные участки. Здесь задается информация о категории земель, назначении земельного участка и его местоположении (рис. 3.50).

Рис. 3.50. Окно программы «Земельные участки»

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

Рис. 3.51. Окно программы «Физические лица»

Рис. 3.52. Окно программы «Юридические лица»

Рис. 3.53. Окно программы «Причины расторжения»

Рис. 3.54. Окно программы «Причины завершения договора»

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

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

Рис. 3.55. Окно программы «Платежи»

В таблице «Способы платежей» (рис. 3.56). мы добавляем дату платежа (к примеру до 15 числа).

Рис. 3.56. Окно программы «Способы платежей» (рис. 3.56).

  1.  Вкладка «Редактирование» (рис. 3.57) позволяет изменять и сохранять рабочую область программы.

Рис. 3.57. Окно программы «Редактирование»

3.3. Формирование отчета по договору каждого арендатора

Для печати данных о каждом арендаторе необходимо сформировать отчет. Для этого предложено использовать стандартный генератор отчетов компании Fast Report. Структурная схема этого генератора представлена на рисунке. 3.63.

Рис. 3.63. Структурная схема генератора отчетов Fast Report

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

Формирование данных для генератора отчетов

Для отображения данных в отчете необходимо их сначала подготовить в том виде, в котором они должны быть распечатаны, т.е. внести необходимые данные в программу (рис. 3.64). (рис. 3.65) [22].

Рис. 3.67. Представление информации о договорах арендаторов.

Для предоставления данных генератору отчетов FastReport в среде Embarcadero RAD Studio XE был создан модуль данных и сформирован набор полей для источника FastReportDataset [23]

Рис. 3.69. Модуль данных для генератора отчетов FastReport

Используя этот модуль данных, программа «Финансовый учет КУМИ РМР» получает возможность передавать данные о договоре арендатора из окна формы генератору отчетов через компонент TReport.

Создание шаблона отчета

Для создания шаблона отчета используется специальный мастер отчетов, который отображается при нажатии одноименной кнопки программы на панели быстрого доступа или на закладке «Отчеты» (рис. 3.70).

Рис. 3.70. Структурная схема генератора отчетов Fast Report

Он состоит из:

  1.  Заголовка отчета, в котором формируется договор аренды земельного участка с кадастровым номером.
  2.  Заголовка, в котором задается предмет договора.
  3.  Заголовка, в котором задается информация об арендной плате
  4.  Заголовка, который содержит данные о правах и обязанностях арендодателя.
  5.  Заголовка, в котором выводятся данные  о правах и обязанностях арендатора.
  6.  Заголовка отчета, в котором упоминается об ответственности сторон.
  7.  Заголовка отчета, в котором содержатся обстоятельства непреодолимой силы.
  8.  Заголовка, где содержатся заключительные положения.
  9.  Заголовка, где выводится информация об юридических адресах, банковских реквизитах и подписях сторон.
  10.  Подзаголовка Передаточный акт и расчет арендной платы.

Отображение и печать отчета

Для отображения отчета необходимо нажать на кнопке «Отчет» на панели быстрого доступа или на закладке «Отчеты». В этом случае, будет отображен автоматически сформированный для печати отчет ядром генератора отчетов компании Fast Report (рис. 3.71).

Рис. 3.71. Сформированный отчет для печати

Это отчет полностью совпадает по форме и содержанию с учебной карточкой преподавателя (рис. 3.64) и его можно отправить на печать, экспортировать в разные форматы или отправить по электронной почте [24].


ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ПРОЕКТА

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

План выполнения работы

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

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

Число рабочих календарных дней за этот период составило 113 дней (в связи с тем, что время работы над проектом с 01 сентября 2012 года по 22 декабря 2012 года), с учетом преддипломной практики. Распределение сроков выполнения работ по этапам создания проекта приведено в таблице №4.

Таблица №4

Распределение сроков выполнения работ по этапам создания проекта

№№

п/п

Стадии

разработки

Проводимые работы

Продолжительность,

рабочие дни

1

Техническое задание

Составление и утверждение технического задания

7

3

Предварительный выбор методов решения задачи

12

4

Эскизный

проект

Разработка общего описания алгоритма решения задачи

10

Подбор теоретического материала

17

5

Технический проект

Разработка базы данных

11

6

Рабочий

проект

Разработка и тестирование программы

26

7

Разработка компонентов и модулей программы

21

8

Оформление пояснительной записки

Оформление и подведение итогов в заключении

9

Итого:

113

Составление сметы затрат на работу

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

В соответствии с НК РФ смета расходов включает следующие элементы затрат:

  •  Материальные расходы;
  •  Расходы на оплату труда;
  •  Начисление амортизации;
  •  Прочие расходы.

Материальные расходы можно разделить на следующие части:

  •  Расходы на материалы;
  •  Расходы на электроэнергию, потребляемую ПК;
  •  Расходы на доступ в сети Интернет;
  •  Расходы на оплату труда с начислениями (ЕСН, СОС);
  •  Амортизация ПК и программных средств;
  •  Прочие основные расходы.

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


Таблица №5

Калькуляция расходов на материалы

Расходы на материалы

Сумма в рублях

Бумага для принтера

190,00

Лазерный диск CD-RW

30,00

Заправка картриджа для принтера

300,00

Итого:

520,00

Расходы на электроэнергию вычисляются как произведение стоимости затраченной электроэнергии в час на затраченное количество времени. Потребляемая мощность компьютера примерно 400 Вт. За время работы над проектом (Вр) компьютер используется: Вр = 588 ч. Стоимость 1 кВт/час равна 2,73 руб. В целом затраты на электроэнергию при разработке (Зэн) составят:

Зэн = 588 * 2,73 * 0,4 = 642,096 руб.

Расходы на доступ к сети Интернет определяются исходя из времени работы и абонентской платы. Абонентская плата безлимитного доступа к сети Интернет составляет 300 руб./мес. На разработку, согласно распределению сроков выполнения работ, выделено 113 дней, а среднее количество дней в месяце равно 21. Таким образом, затраты на доступ к сети Интернет (Зи) составляют:

Зи = 300 * 113 / 21 = 1620 руб.

Итого материальные расходы (Змат) составляют:

Змат = 520 + 642,096 + 1620= 2782,096 руб.

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

ЗПосн = О * ТЕ / КД,

где О – месячный оклад;

ТЕ – трудоемкость выполняемых работ;

Кд – количество рабочих дней в месяце, принимается равным 21.

Исходя из данной формулы, основные расходы на оплату составят:

ЗПосн = 6000 * 113 / 21 = 32400 руб.

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

ЗПотч = ЗПосн * Ксс,

где Ксс – коэффициент отчислений на социальное страхование, куда входят:

  •  0,28 – в пенсионный фонд;
  •  0,04 – в фонд социального страхования;
  •  0,036 – в фонд медицинского страхования;
  •  0,015 – страхование от несчастных случаев.

Таким образом, суммарно коэффициент отчислений на социальное страхование составляет: Ксс = 0,371. Тогда расходы на социальные отчисления составляют:

ЗПотч = 32400 * 0,371 = 11988 руб.

В этом случае общие затраты фонда оплаты труда (Фзп) составит:

Фзп = 32400+ 11988= 44388 руб.

Под амортизацией понимается постоянный перенос стоимости основных фондов на стоимость выпускаемой продукции с целью накопления средств на покупку нового оборудования. В данном случае основной фонд – ПК стоимостью 12900  руб. со сроком полезного использования 3 года, использующийся в течение 113 дней. Среднее количество рабочих дней в году равно 252 дням. Тогда амортизирующие отчисления составляют:

Апк = 12900 * 113 / (252 * 3) = 1928,17руб.

В стоимость компьютера также входит все требуемое программное обеспечение и операционная система.

Таким образом, общие основные затраты (Зосн) составляют:

Зосн = Змат + Фзп + Апк = 2782,096 + 44388+ 1928,17= 49098,3 руб.


К прочим расходам (З
пр) относятся расходы, которые невозможно прямо включить в себестоимость данной работы. В данной работе накладные расходы приняты в размере 3% от основных затрат:

Зпр = 49098,3 * 0,03 = 1472,95 руб.

Итого общие затраты на разработку (З) составляют:

З = 49098,3 + 1472,95 = 50571,25 руб.

Все необходимые расходы сведены в таблицу №6.

Таблица №6

Смета затрат на разработку

Элементы затрат

Сумма, руб.

Удельный вес, %

Материальные расходы

2782,096

5,5

Расходы на оплату труда

44388

87,7

Начисление амортизации

1928,17

3,8

Прочие расходы

1472,95

3

Итого:

50571,25

100

Расчет цены НИР

Проектная цена исследования (Цнир) рассчитывается следующим образом:

Цнир = Ссм * Кпр * (1 + НДС),

где Ссм – сметная стоимость разработки;

Кпр – коэффициент прибыли, в данной работе принят равным 1,2;

НДС – налог на добавленную стоимость, равен 0,18.

Тогда проектная цена исследования составляет:

Цнир = 50571,25* 1,2 * (1 + 0,18) = 71608,89 руб.


Заключение

Итогом данной работы является достижение цели и реализация задач. То есть для автоматизации процесса формирования финансового учета земельного налога КУМИ РМР была создана база данных MunicipalEstateDB и система управления этой базой данных.

Для создания этой базы были разработаны инфологическая и физическая модели и создан SQL-скрипт с помощью программы MicroOLAP Database Designer for MySQL, который был выполнен на сервере cs.rsu.edu.ru с помощью программы phpMyAdmin, и помещен на закладку выполнения SQL-запросов. После его выполнения и была создана база данных MunicipalEstateDB на сервере MySQL.

Для создания системы управления базой данных MunicipalEstateDB были разработаны программа «ФИНАНСОВЫЙ УЧЕТ КУМИ РМР», сервер лицензий системы управления, который предназначен для ограничения доступа к этой программе. Он состоит из двух элементов: службы сервера, которая проверяет - имеет ли пользователь доступ к программе или нет и менеджера сервера, который управляет сервером лицензий. Далее, для сервера лицензий был создан инсталляционный пакет с помощью программы InstallShield для установки на компьютере пользователя.

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

После всего этого можно приступать к работе с программой «ФИНАНСОВЫЙ УЧЕТ КУМИ РМР», то есть запустить её, указать имя и пароль для доступа к базе данных, в появившемся главном окне программы в параметрах настройки указать адрес сервера лицензий и MySQL сервера базы данных, затем протестировав, настроить подключение к данному серверу. Это позволяет изменять, редактировать, вносить и удалять данные.

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

Список использованной литературы

  1.  http://www.gis.su/products/product/show/154.htm – Комплексная система ведение имущественного кадастра города или крупной организации.
  2.  http://www.cosmos2.ru/Programs/Developer/cosmosdev – Программное обеспечение ООО "НПЦ "Космос-2".
  3.  Матросов А. В. и др. MS Office ХР: разработка приложений. – СПб.: БХВ-Петербург, 2003. – 944 с.
  4.  Гарбер Г. Основы программирования на VB и VBA в Excel 2007. –М.: Солон-пресс, 2008. – 199 с.
  5.  Уокенбах Д. Профессиональное программирование на VBA в Excel 2002. – М.: Диалектика, 2003. – 784 с.
  6.  Корняков В.Н. Программирование документов и приложений MS Office в Delphi. –СПб.: БХВ-Петербург, 2005. – 496 с.
  7.  Михеев Р. VBA и программирование в MS Office для пользователей. – СПб.: БХВ-Петербург, 2006. – 384 с.
  8.  Гарнаев А. Самоучитель VBA. – СПб.: БХВ-Петербург, 2005. – 512с.
  9.  Фленов Ф. Библия Delphi. – СПб.: БХВ-Петербург, 2008. – 880 с.
  10.  Хомоненко А., Гофман В., Мещеряков Е., Никифоров В. Delphi 7. Наиболее полное руководство. – СПб.: БХВ-Петербург, 2006. – 1216 с.
  11.  Архангельский А.Я. 100 компонентов общего назначения библиотеки Delphi 5. –М.: Бином, 2004. – 272с.
  12.  Информатика и программирование. Шаг за шагом [Электронный ресурс] / кафедра информационных технологий курганского государственного университета. – Режим доступа: http://it.kgsu.ru, свободный. – Загл. с экрана. – Яз. руск.
  13.  MySQL.RU: Одобрено лучшими российскими программистами [Электронный ресурс] / MySql. – Режим доступа: http://www.mysql.ru, свободный. – Загл. с экрана. – Яз. руск.
  14.  MySQL. The world's most popular open source database [Электронный ресурс] / MySql. – Режим доступа: http://www.mysql.com, свободный. – Загл. с экрана. – Яз. англ.
  15.  Поль Дюбуа. MySQL.–М: Вильямс, 2001. – 832 с.
  16.  Архангельский А.Я. Delphi 2006. Справочное пособие. Язык Delphi, классы, функции Win32 и .NET. – М.: Бином-Пресс, 2006. – 1152 с.
  17.  Дейт К. Введение в системы баз данных.; –М.: Издательский дом «Вильямс», 2000. – 848 с.
  18.  Карпова Т.С. Базы данных: модели, разработка, реализация – СПб.: Питер, 2001. – 304 с.
  19.  Культин Н. Б. Основы программирования в Delphi. –СПб.: БХВ-Петербург, 2009. – 640 с.
  20.  Аткинсон Л. MySQL. Библиотека профессионала.– М.: Издательский дом «Вильямс», 2002.  624 с.
  21.  Стивенс Р. Delphi. Готовые алгоритмы. –М: ДМК-Пресс, 2001. – 384 с.
  22.  Фараонов В.В. Delphi: Программирование на языке высокого уровня: Учебник для вузов. –СПб.: Питер, 2004. – 640с.


Приложение

SQL-запрос для создания базы данных MunicipalEstateDB

-- MyDAC version: 5.90.0.60

-- MySQL server version: 5.1.53-community-log

-- MySQL client version: 4.1.3 Direct

-- Script date 11.01.2013 4:23:15

-- ----------------------------------------------------------------------

-- Server: localhost

-- Database: MunicipalEstateDB

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;

/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;

/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;

/*!40101 SET NAMES cp1251 */;

/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;

/*!50018 SET @DISABLE_TRIGER=1 */;

--

-- Database MunicipalEstateDB structure

--

USE mysql;

DROP DATABASE IF EXISTS MunicipalEstateDB;

CREATE DATABASE MunicipalEstateDB;

USE MunicipalEstateDB;

--

-- Table structure for table  ControlKind

--

DROP TABLE IF EXISTS ControlKind;

CREATE TABLE `ControlKind` (

 `ControlKindID` int(11) NOT NULL AUTO_INCREMENT,

 `GroupID` int(11) NOT NULL DEFAULT '0',

 `Name` varchar(50) DEFAULT NULL,

 `DisciplineUnionID` int(11) NOT NULL DEFAULT '0',

 PRIMARY KEY (`ControlKindID`),

 KEY `Ref_18` (`GroupID`),

 KEY `Ref_13` (`DisciplineUnionID`),

 CONSTRAINT `Ref_13` FOREIGN KEY (`DisciplineUnionID`) REFERENCES `disciplineunion` (`DisciplineUnionID`) ON DELETE NO ACTION ON UPDATE NO ACTION,

 CONSTRAINT `Ref_18` FOREIGN KEY (`GroupID`) REFERENCES `groups` (`GroupID`) ON DELETE NO ACTION ON UPDATE NO ACTION

) ENGINE=InnoDB AUTO_INCREMENT=94 DEFAULT CHARSET=cp1251;

--

-- Table structure for table  Direction

--

DROP TABLE IF EXISTS Direction;

CREATE TABLE `Direction` (

 `DirectionID` int(11) NOT NULL AUTO_INCREMENT,

 `FacultetID` int(11) NOT NULL DEFAULT '0',

 `Name` varchar(50) DEFAULT NULL,

 PRIMARY KEY (`DirectionID`),

 KEY `Ref_01` (`FacultetID`),

 CONSTRAINT `Ref_01` FOREIGN KEY (`FacultetID`) REFERENCES `facultet` (`FacultetID`) ON DELETE CASCADE ON UPDATE NO ACTION

) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=cp1251;

--

-- Table structure for table  Discipline

--

DROP TABLE IF EXISTS Discipline;

CREATE TABLE `Discipline` (

 `DisciplineID` int(11) NOT NULL AUTO_INCREMENT,

 `Name` varchar(150) DEFAULT NULL,

 PRIMARY KEY (`DisciplineID`)

) ENGINE=InnoDB AUTO_INCREMENT=69 DEFAULT CHARSET=cp1251;

--

-- Table structure for table  DisciplineUnion

--

DROP TABLE IF EXISTS DisciplineUnion;

CREATE TABLE `DisciplineUnion` (

 `DisciplineUnionID` int(11) NOT NULL AUTO_INCREMENT,

 `DirectionID` int(11) NOT NULL DEFAULT '0',

 `DisciplineID` int(11) NOT NULL DEFAULT '0',

 PRIMARY KEY (`DisciplineUnionID`),

 KEY `Ref_11` (`DirectionID`),

 KEY `Ref_12` (`DisciplineID`),

 CONSTRAINT `Ref_11` FOREIGN KEY (`DirectionID`) REFERENCES `direction` (`DirectionID`) ON DELETE NO ACTION ON UPDATE NO ACTION,

 CONSTRAINT `Ref_12` FOREIGN KEY (`DisciplineID`) REFERENCES `discipline` (`DisciplineID`) ON DELETE NO ACTION ON UPDATE NO ACTION

) ENGINE=InnoDB AUTO_INCREMENT=89 DEFAULT CHARSET=cp1251;

--

-- Table structure for table  Employment

--

DROP TABLE IF EXISTS Employment;

CREATE TABLE `Employment` (

 `EmploymentID` int(11) NOT NULL AUTO_INCREMENT,

 `FullName` varchar(100) DEFAULT NULL,

 `Name` varchar(50) DEFAULT NULL,

 PRIMARY KEY (`EmploymentID`)

) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=cp1251;

--

-- Table structure for table  Facultet

--

DROP TABLE IF EXISTS Facultet;

CREATE TABLE `Facultet` (

 `FacultetID` int(11) NOT NULL AUTO_INCREMENT,

 `Name` varchar(50) DEFAULT NULL,

 PRIMARY KEY (`FacultetID`)

) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=cp1251;

--

-- Table structure for table  FirstName

--

DROP TABLE IF EXISTS FirstName;

CREATE TABLE `FirstName` (

 `FirstNameID` int(11) NOT NULL AUTO_INCREMENT,

 `SexID` int(11) NOT NULL DEFAULT '0',

 `Name` varchar(50) DEFAULT NULL,

 PRIMARY KEY (`FirstNameID`),

 KEY `Ref_04` (`SexID`),

 CONSTRAINT `Ref_04` FOREIGN KEY (`SexID`) REFERENCES `sex` (`SexID`) ON DELETE CASCADE ON UPDATE NO ACTION

) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=cp1251;

--

-- Table structure for table  FormTeaching

--

DROP TABLE IF EXISTS FormTeaching;

CREATE TABLE `FormTeaching` (

 `FormTeachingID` int(11) NOT NULL AUTO_INCREMENT,

 `Name` varchar(50) COLLATE cp1251_general_cs DEFAULT NULL,

 PRIMARY KEY (`FormTeachingID`)

) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=cp1251 COLLATE=cp1251_general_cs;

--

-- Table structure for table  Groups

--

DROP TABLE IF EXISTS Groups;

CREATE TABLE `Groups` (

 `GroupID` int(11) NOT NULL AUTO_INCREMENT,

 `Cource` int(11) DEFAULT NULL,

 `Semester` int(11) DEFAULT NULL,

 `CountGroup` int(11) DEFAULT NULL,

 `CountStudents` int(11) DEFAULT NULL,

 `FormTeachingID` int(11) NOT NULL DEFAULT '0',

 `YearID` int(4) NOT NULL DEFAULT '0',

 PRIMARY KEY (`GroupID`),

 KEY `Ref_24` (`FormTeachingID`),

 KEY `Ref_25` (`YearID`),

 CONSTRAINT `Ref_24` FOREIGN KEY (`FormTeachingID`) REFERENCES `formteaching` (`FormTeachingID`) ON DELETE NO ACTION ON UPDATE NO ACTION,

 CONSTRAINT `Ref_25` FOREIGN KEY (`YearID`) REFERENCES `years` (`YearID`) ON DELETE NO ACTION ON UPDATE NO ACTION

) ENGINE=InnoDB AUTO_INCREMENT=38 DEFAULT CHARSET=cp1251;

--

-- Table structure for table  Loading

--

DROP TABLE IF EXISTS Loading;

CREATE TABLE `Loading` (

 `LoadingID` int(11) NOT NULL AUTO_INCREMENT,

 `Hours` decimal(10,2) DEFAULT NULL,

 `LoadingKindID` int(11) NOT NULL DEFAULT '0',

 `ControlKindID` int(11) NOT NULL DEFAULT '0',

 `TeacherID` int(11) NOT NULL DEFAULT '0',

 PRIMARY KEY (`LoadingID`),

 KEY `Ref_17` (`LoadingKindID`),

 KEY `Ref_21` (`ControlKindID`),

 KEY `Ref_22` (`TeacherID`),

 CONSTRAINT `Ref_17` FOREIGN KEY (`LoadingKindID`) REFERENCES `Loadingkind` (`LoadingKindID`) ON DELETE NO ACTION ON UPDATE NO ACTION,

 CONSTRAINT `Ref_21` FOREIGN KEY (`ControlKindID`) REFERENCES `controlkind` (`ControlKindID`) ON DELETE NO ACTION ON UPDATE NO ACTION,

 CONSTRAINT `Ref_22` FOREIGN KEY (`TeacherID`) REFERENCES `teacher` (`TeacherID`) ON DELETE NO ACTION ON UPDATE NO ACTION

) ENGINE=InnoDB AUTO_INCREMENT=20 DEFAULT CHARSET=cp1251;

--

-- Table structure for table  LoadingKind

--

DROP TABLE IF EXISTS LoadingKind;

CREATE TABLE `LoadingKind` (

 `LoadingKindID` int(11) NOT NULL AUTO_INCREMENT,

 `FullName` varchar(50) DEFAULT NULL,

 PRIMARY KEY (`LoadingKindID`)

) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=cp1251;

--

-- Table structure for table  MiddleName

--

DROP TABLE IF EXISTS MiddleName;

CREATE TABLE `MiddleName` (

 `MiddleNameID` int(11) NOT NULL AUTO_INCREMENT,

 `Name` varchar(50) DEFAULT NULL,

 `SexID` int(11) NOT NULL DEFAULT '0',

 PRIMARY KEY (`MiddleNameID`),

 KEY `Ref_05` (`SexID`),

 CONSTRAINT `Ref_05` FOREIGN KEY (`SexID`) REFERENCES `sex` (`SexID`) ON DELETE CASCADE ON UPDATE NO ACTION

) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=cp1251;

--

-- Table structure for table  ReportGroup

--

DROP TABLE IF EXISTS ReportGroup;

CREATE TABLE `ReportGroup` (

 `ReportGroupID` int(11) unsigned NOT NULL AUTO_INCREMENT,

 `ReportGroupName` varchar(255) DEFAULT NULL,

 PRIMARY KEY (`ReportGroupID`)

) ENGINE=InnoDB DEFAULT CHARSET=cp1251;

--

-- Table structure for table  Reports

--

DROP TABLE IF EXISTS Reports;

CREATE TABLE `Reports` (

 `ReportID` int(11) unsigned NOT NULL AUTO_INCREMENT,

 `ReportGroupID` int(11) unsigned NOT NULL DEFAULT '0',

 `Name` varchar(255) DEFAULT NULL,

 `Author` varchar(100) DEFAULT NULL,

 `Description` text,

 `CreateDate` datetime DEFAULT NULL,

 `LastChange` datetime DEFAULT NULL,

 `VersionRelease` varchar(50) DEFAULT NULL,

 `VersionBuild` varchar(50) DEFAULT NULL,

 `Report` blob,

 PRIMARY KEY (`ReportID`),

 KEY `Ref_35` (`ReportGroupID`),

 CONSTRAINT `Ref_35` FOREIGN KEY (`ReportGroupID`) REFERENCES `reportgroup` (`ReportGroupID`) ON DELETE NO ACTION ON UPDATE NO ACTION

) ENGINE=InnoDB DEFAULT CHARSET=cp1251;

--

-- Table structure for table  RoleNames

--

DROP TABLE IF EXISTS RoleNames;

CREATE TABLE `RoleNames` (

 `RoleNameID` int(11) unsigned NOT NULL AUTO_INCREMENT,

 `RoleName` varchar(50) DEFAULT NULL,

 PRIMARY KEY (`RoleNameID`)

) ENGINE=InnoDB DEFAULT CHARSET=cp1251;

--

-- Table structure for table  Roles

--

DROP TABLE IF EXISTS Roles;

CREATE TABLE `Roles` (

 `RoleID` int(11) unsigned NOT NULL AUTO_INCREMENT,

 `RoleNameID` int(11) unsigned NOT NULL DEFAULT '0',

 `Role` varchar(255) DEFAULT NULL,

 PRIMARY KEY (`RoleID`),

 KEY `Ref_34` (`RoleNameID`),

 CONSTRAINT `Ref_34` FOREIGN KEY (`RoleNameID`) REFERENCES `rolenames` (`RoleNameID`) ON DELETE NO ACTION ON UPDATE NO ACTION

) ENGINE=InnoDB DEFAULT CHARSET=cp1251;

--

-- Table structure for table  Sex

--

DROP TABLE IF EXISTS Sex;

CREATE TABLE `Sex` (

 `SexID` int(11) NOT NULL AUTO_INCREMENT,

 `FullName` varchar(10) DEFAULT NULL,

 `Name` varchar(1) DEFAULT NULL,

 PRIMARY KEY (`SexID`)

) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=cp1251;

--

-- Table structure for table  StatisticGroups

--

DROP TABLE IF EXISTS StatisticGroups;

CREATE TABLE `StatisticGroups` (

 `StatisticGroupID` int(11) unsigned NOT NULL AUTO_INCREMENT,

 `StatisticGroupName` varchar(50) DEFAULT NULL,

 PRIMARY KEY (`StatisticGroupID`)

) ENGINE=InnoDB DEFAULT CHARSET=cp1251;

--

-- Table structure for table  StatisticKinds

--

DROP TABLE IF EXISTS StatisticKinds;

CREATE TABLE `StatisticKinds` (

 `StatisticKindID` int(11) unsigned NOT NULL AUTO_INCREMENT,

 `StatisticGroupID` int(11) unsigned NOT NULL DEFAULT '0',

 `StatisticKindName` varchar(50) DEFAULT NULL,

 `StatisticKindSQL` text,

 PRIMARY KEY (`StatisticKindID`),

 KEY `Ref_36` (`StatisticGroupID`),

 CONSTRAINT `Ref_36` FOREIGN KEY (`StatisticGroupID`) REFERENCES `statisticgroups` (`StatisticGroupID`) ON DELETE NO ACTION ON UPDATE NO ACTION

) ENGINE=InnoDB DEFAULT CHARSET=cp1251;

--

-- Table structure for table  TableName

--

DROP TABLE IF EXISTS TableName;

CREATE TABLE `TableName` (

 `TableNameEng` varchar(50) NOT NULL,

 `TableNameRu` varchar(50) DEFAULT NULL,

 PRIMARY KEY (`TableNameEng`)

) ENGINE=InnoDB DEFAULT CHARSET=cp1251;

--

-- Table structure for table  Teacher

--

DROP TABLE IF EXISTS Teacher;

CREATE TABLE `Teacher` (

 `TeacherID` int(11) NOT NULL AUTO_INCREMENT,

 `LastName` varchar(50) DEFAULT NULL,

 `FirstNameID` int(11) NOT NULL DEFAULT '0',

 `MiddleNameID` int(11) NOT NULL DEFAULT '0',

 `EmploymentID` int(11) NOT NULL DEFAULT '0',

 PRIMARY KEY (`TeacherID`),

 KEY `Ref_40` (`FirstNameID`),

 KEY `Ref_41` (`MiddleNameID`),

 KEY `Ref_44` (`EmploymentID`),

 CONSTRAINT `Ref_40` FOREIGN KEY (`FirstNameID`) REFERENCES `firstname` (`FirstNameID`) ON DELETE NO ACTION ON UPDATE NO ACTION,

 CONSTRAINT `Ref_41` FOREIGN KEY (`MiddleNameID`) REFERENCES `middlename` (`MiddleNameID`) ON DELETE NO ACTION ON UPDATE NO ACTION,

 CONSTRAINT `Ref_44` FOREIGN KEY (`EmploymentID`) REFERENCES `employment` (`EmploymentID`) ON DELETE NO ACTION ON UPDATE NO ACTION

) ENGINE=InnoDB AUTO_INCREMENT=13 DEFAULT CHARSET=cp1251;

--

-- Table structure for table  Years

--

DROP TABLE IF EXISTS Years;

CREATE TABLE `Years` (

 `YearID` int(4) NOT NULL AUTO_INCREMENT,

 `Name` varchar(9) DEFAULT NULL,

 PRIMARY KEY (`YearID`)

) ENGINE=InnoDB AUTO_INCREMENT=2014 DEFAULT CHARSET=cp1251;

/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;

/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;

/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;

/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

/*!50018 SET @DISABLE_TRIGER=NULL */;


SQL
-запрос для создания просмотра

CREATE VIEW MunicipalEstate AS SELECT (SELECT Loading.Hours

       FROM

         Loading

       WHERE

         Loading.TeacherID = teacher.TeacherID

         AND Loading.LoadingKindID = 1

         AND Loading.ControlKindID = controlkind.ControlKindID

       LIMIT

         1) AS Hours1

    , (SELECT Loading.Hours

       FROM

         Loading

       WHERE

         Loading.TeacherID = Teacher.TeacherID

         AND Loading.LoadingKindID = 2

         AND Loading.ControlKindID = ControlKind.ControlKindID

       LIMIT

         1) AS Hours2

    , (SELECT Loading.Hours

       FROM

         Loading

       WHERE

         Loading.TeacherID = Teacher.TeacherID

         AND Loading.LoadingKindID = 3

         AND Loading.ControlKindID = ControlKind.ControlKindID

       LIMIT

         1) AS Hours3

    , (SELECT Loading.Hours

       FROM

         Loading

       WHERE

         Loading.TeacherID = Teacher.TeacherID

         AND Loading.LoadingKindID = 4

         AND Loading.ControlKindID = ControlKind.ControlKindID

       LIMIT

         1) AS Hours4

    , (SELECT Loading.Hours

       FROM

         Loading

       WHERE

         Loading.TeacherID = Teacher.TeacherID

         AND Loading.LoadingKindID = 5

         AND Loading.ControlKindID = ControlKind.ControlKindID

       LIMIT

         1) AS Hours5

    , (SELECT Loading.Hours

       FROM

         Loading

       WHERE

         Loading.TeacherID = Teacher.TeacherID

         AND Loading.LoadingKindID = 6

         AND Loading.ControlKindID = ControlKind.ControlKindID

       LIMIT

         1) AS Hours6

    , (SELECT Loading.Hours

       FROM

         Loading

       WHERE

         Loading.TeacherID = Teacher.TeacherID

         AND Loading.LoadingKindID = 7

         AND Loading.ControlKindID = ControlKind.ControlKindID

       LIMIT

         1) AS Hours7

    , (SELECT Loading.Hours

       FROM

         Loading

       WHERE

         Loading.TeacherID = Teacher.TeacherID

         AND Loading.LoadingKindID = 8

         AND Loading.ControlKindID = ControlKind.ControlKindID

       LIMIT

         1) AS Hours8

    , (SELECT Loading.Hours

       FROM

         Loading

       WHERE

         Loading.TeacherID = Teacher.TeacherID

         AND Loading.LoadingKindID = 9

         AND Loading.ControlKindID = ControlKind.ControlKindID

       LIMIT

         1) AS Hours9

    , (SELECT Loading.Hours

       FROM

         Loading

       WHERE

         Loading.TeacherID = Teacher.TeacherID

         AND Loading.LoadingKindID = 10

         AND Loading.ControlKindID = ControlKind.ControlKindID

       LIMIT

         1) AS Hours10

    , (SELECT Loading.Hours

       FROM

         Loading

       WHERE

         Loading.TeacherID = Teacher.TeacherID

         AND Loading.LoadingKindID = 11

         AND Loading.ControlKindID = ControlKind.ControlKindID

       LIMIT

         1) AS Hours11

    , (SELECT Loading.Hours

       FROM

         Loading

       WHERE

         Loading.TeacherID = Teacher.TeacherID

         AND Loading.LoadingKindID = 12

         AND Loading.ControlKindID = ControlKind.ControlKindID

       LIMIT

         1) AS Hours12

    , (SELECT Loading.Hours

       FROM

         Loading

       WHERE

         Loading.TeacherID = Teacher.TeacherID

         AND Loading.LoadingKindID = 13

         AND Loading.ControlKindID = ControlKind.ControlKindID

       LIMIT

         1) AS Hours13

    , Years.YearID

    , Loading.LoadingID

    , Loading.TeacherID

    , Loading.ControlKindID

FROM

 Loading

INNER JOIN ControlKind

ON Loading.ControlKindID = ControlKind.ControlKindID

INNER JOIN Groups

ON ControlKind.GroupID = Groups.GroupID

INNER JOIN Years

ON Groups.YearID = Years.YearID

INNER JOIN Teacher

ON Loading.TeacherID = Teacher.TeacherID

GROUP BY

 Loading.ControlKindID

, Loading.TeacherID

, Years.YearID

 


 

А также другие работы, которые могут Вас заинтересовать

37947. Определение коэффициента Пуассона воздуха методом адиабати 445 KB
  1 Определение коэффициента Пуассона воздуха методом адиабатического расширения: Методические указания к лабораторной работе № 16 по курсу общей физики Уфимск. В работе определяется коэффициент Пуассона воздуха методом адиабатического расширения основанным на измерении давления газа в сосуде после последовательно происходящих процессов его адиабатического расширения и изохорного нагревания.8] Список литературы ЛАБОРАТОРНАЯ РАБОТА № 16 ОПРЕДЕЛЕНИЕ КОЭФФИЦИЕНТА ПУАССОНА ВОЗДУХА МЕТОДОМ АДИАБАТИЧЕСКОГО РАСШИРЕНИЯ 1. Цель работы Определение...
37948. ЭКСПЕРИМЕНТАЛЬНАЯ ПРОВЕРКА УРАВНЕНИЯ СОСТОЯНИЯ И ЗАКОНОВ ИДЕАЛЬНОГО ГАЗА 146.5 KB
  1 Экспериментальная проверка уравнения состояния и законов идеального газа: Методические указания к лабораторной работе № 17 по курсу общей физики Уфимск. В работе изучается взаимосвязь параметров задающих состояние идеального газа и закономерности их изменения. Контрольные вопросы [7] Список литературы ЛАБОРАТОРНАЯ РАБОТА № 17 ЭКСПЕРИМЕНТАЛЬНАЯ ПРОВЕРКА УРАВНЕНИЯ СОСТОЯНИЯ И ЗАКОНОВ ИДЕАЛЬНОГО ГАЗА 1.
37949. Определение коэффициента Пуассона воздуха акустическим методом 128 KB
  Обратимся к молярным теплоемкостям идеального газа при постоянном объеме и при постоянном давлении. Внутренняя энергия идеального газа – это энергия теплового движения молекул и атомов в молекулах. Следовательно средняя энергия теплового движения молекулы идеального газа равна 2. Внутренняя энергия  молей газа равна 2.
37950. Определение коэффициента вязкости воздуха и кинематических характеристик теплового движения его молекул 888 KB
  1 Определение коэффициента вязкости воздуха и кинематических характеристик теплового движения его молекул: Методические указания к лабораторной работе №23 по курсу общей физики Уфимск. В работе на основе исследования одного из явления переноса внутреннего трения определяютcя коэффициент вязкости воздуха а также средняя длина свободного пробега и эффективный диаметр его молекул. Осипов ЛАБОРАТОРНАЯ РАБОТА № 23 ОПРЕДЕЛЕНИЕ КОЭФФИЦИЕНТА ВЯЗКОСТИ ВОЗДУХА И КИНЕМАТИЧЕСКИХ ХАРАКТЕРИСТИК ТЕПЛОВОГО ДВИЖЕНИЯ ЕГО МОЛЕКУЛ 1.2 Определение средней длины...
37951. ИЗУЧЕНИЕ ГАЗОВЫХ ЗАКОНОВ И ОПРЕДЕЛЕНИЕ КОЭФФИЦИЕНТА ПУАССОНА ГАЗА МЕТОДОМ КЛЕМАНА – ДЕЗОРМА 157.5 KB
  Теплоемкость и коэффициент Пуассона газа.14 лабораторная работа № 24 ИЗУЧЕНИЕ ГАЗОВЫХ ЗАКОНОВ И ОПРЕДЕЛЕНИЕ КОЭФФИЦИЕНТА ПУАССОНА ГАЗА МЕТОДОМ КЛЕМАНА – ДЕЗОРМА Цель работы Изучение различных процессов изменения состояния газа и определение коэффициента Пуассона воздуха. Теплоемкость и коэффициент Пуассона газа Удельной теплоемкостью вещества называется величина равная количеству теплоты которую надо передать единице массы этого вещества для увеличения его температуры на 1К а молярной теплоемкостью – количество теплоты которое...
37952. ОПРЕДЕЛЕНИЕ КОЭФФИЦИЕНТОВ ТЕПЛОПРОВОДНОСТИ МЕТАЛЛОВ 2.23 MB
  13 ЛАБОРАТОРНАЯ РАБОТА № 25 ОПРЕДЕЛЕНИЕ КОЭФФИЦИЕНТОВ ТЕПЛОПРОВОДНОСТИ МЕТАЛЛОВ Цель работы Изучение явления теплопроводности и определение коэффициентов теплопроводности чистых металлов и сплавов. Если в неравномерно нагретых жидкостях и газах тепловая энергия передается преимущественно за счет конвекции при которой происходит перемещение вещества между областями с различной температурой то в твердых телах тепло переносится только за счет теплопроводности. Распространение тепловой энергии путем теплопроводности обусловлено хаотическим...
37953. ИЗУЧЕНИЕ ВЗИМОСВЯЗИ ПАРМЕТРОВ СОСТОЯНИЯ ИДЕАЛЬНОГО ГАЗА И ГАЗОВЫХ ЗАКОНОВ 150.5 KB
  Экспериментальная проверка уравнения состояния идеального газа.13 лабораторная работа № 29 ИЗУЧЕНИЕ ВЗИМОСВЯЗИ ПАРМЕТРОВ СОСТОЯНИЯ ИДЕАЛЬНОГО ГАЗА И ГАЗОВЫХ ЗАКОНОВ Цель работы 1. Изучение взаимосвязи макропараметров определяющих состояние идеального газа. Экспериментальная проверка уравнения состояния идеального газа.
37954. Исследование электростатического поля и изображение его при помощи силовых линий и поверхностей равного потенциала 867.5 KB
  Исследование электростатического поля Цель работы Экспериментальное исследование электростатического поля и изображение его при помощи силовых линий и поверхностей равного потенциала. Напряженностью электрического поля называют силу действующую на единичный положительный пробный заряд. Если электрическое поле создается системой зарядов то напряженность поля в данной точке определяется по принципу суперпозиции...
37955. ИЗУЧЕНИЕ ЗАКОНОВ ПОСТОЯННОГО ТОКА 1.19 MB
  Электрическим током называют упорядоченное движение зарядов. Эти заряды называют носителями тока. Линия тока есть математическая линия, направление касательной которой в каждой точке совпадает с направлением скорости носителей тока. За положительное направление тока принято считать направление скорости положительно заряженных частиц.