Автоматизация оказания услуг проектным специализированным бюро
Проект и реализация на основе клиент-серверных технологий базы данных работ (услуг), выполняемых МГКУПП "Проектное специализированное бюро". Автоматизация расчета стоимости работ. Организация поиска заказа, контроля выполнения и оплаты, отчетности.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 01.02.2017 |
| Размер файла | 2,1 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru
ОГЛАВЛЕНИЕ
- Введение
- 1. Техническое задание
- 1.1 Функциональная модель
- 1.1.1 Контекстная диаграмма и диаграммы детализации процессов
- 1.1.2 Диаграмма дерева узлов
- 1.2 Информационная модель
- 1.2.1 Идентификация сущностей и связей. ER-диаграмма логического уровня
- 1.2.2 ER-диаграмма физического уровня. Ограничения доменов. Ограничения ссылочной целостности. Переопределение триггеров. Индексирование отношений
- 1.2.3. Определение представлений, хранимых процедур серверной компоненты. ER-диаграмма в режиме отображения представлений
- 1.3. Верификация спроектированной логической модели
- 2. Реализация системы
- 2.1. T-SQL-определения регламентированных запросов
- 2.2 T-SQL-определения триггеров
- 2.3. T-SQL-определения хранимых процедур
- 2.4 T-SQL-определения курсоров
- 3. Проектирование системы безопасности. Управление авторизацией, управление ролями, управление разрешениями средствами Transact SQL
- 4. Прокомментированный скрипт создания базы данных
- 5. Результат тестирования информационной системы
- Заключение
- Список использованных литературных источников
- ВВЕДЕНИЕ
- Развитие современных городов и поселков не возможно целенаправленного преобразования среды обитания путем формирования и развития систем расселения, отдельных городских и сельских поселений, их производственной, социальной, транспортной, инженерно-технической инфраструктуры, размещения мест проживания, приложения труда, обслуживания, отдыха населения с учетом охраны природы и историко-культурного наследия.
- Задачами градостроительства в структуре управления городом Могилёвом занимается «Управление архитектуры и градостроительства», в ведомственной подчиненнсти которого находится, в часности, и МГКУПП «Проектное специализированное бюро». Эта организация оказывает различные многочисленные услуги населению и организациям в сфере градостроительства. С ростом города растет и потребность как в количестве, так и в качестве оказываемых услуг, эффективное удовлетворение которой невозможно без атоматизации взаимодействия в организации.
- Целью данного курсового проекта является спроектировать и реализовать на основе клиент/серверных технологий базу данных работ (услуг), выполняемых МГКУПП «Проектное специализированное бюро», автоматизировать расчет стоимости работ, организовать контроль выполнения и оплаты, а также реализовать все необходимые для поиска и работы с заказами запросы и отчеты.
- серверный автоматизация заказ бюро
1. ТЕХНИЧЕСКОЕ ЗАДАНИЕ
1.1 Функциональная модель
1.1.1 Контекстная диаграмма и диаграммы детализации процессов
Первая диаграмма в иерархии диаграмм IDEF0 изображает функционирование в целом. Такие диаграммы называются контекстными. В контекстные диаграммы входит описание цели моделирования, области (описания того, что будет рассматриваться в качестве компонента системы, а что в качестве внешнего воздействия) и точки зрения (позиции, с которой будет строиться модель).
После того как контекст описан, проводится построение следующих диаграмм в иерархии. Каждая последующая диаграмма является более подробным описанием (декомпозицией) одной из работ на диаграмме вышестоящего уровня.
Контекстная диаграмма представляет собой схему организации работы проектного бюро. Входными данными является информация о сотрудниках, заках, заказчиках, строительных объектах, земельных участках, оплате услуг. В ходе функционирования системы создаются базы договоров на услуги бюро, нарушений рекламной деятельности, справочник заказчиков (Рис. 1).
Рисунок 1 - Контекстная диаграмма.
Результатом функционирования являются различные отчеты: о поступивших заказах на услуги, актах выполненных работ, об исполнительской дисциплине, нагрузке на исполнителя, а также списки заказчиков услуг и нарушителей рекламного законодательства.
В дальнейшем диаграмма разбивается на уровни. Первый уровень - это диаграмма (рис. 2), с помощью которой производится детализация основного процесса, находящегося на контекстной диаграмме. Контекстную диаграмму разбиваем на 7 блоков в соответствии с имеющимися в бюро отделами и службами.
Рисунок 2 - декомпозиция процесса “Автоматизация оказание услуг “Проектным специализированным бюро”
Полученные блоки - “Автоматизировать работу директора”, “Автоматизировать работу ведущего специалиста по договорной работе”, “Автоматизировать работу отдела геодезии”, “Автоматизировать работу службы по организации и проведению аукционов”, “Автоматизировать работу отдела индивидуальной застройки”, “Автоматизировать работу архитектурно-планировочного отдела и прочие работы”, “Автоматизировать работу отдела эстетики и рекламы” - также подлежат дальнейшей детализации в соответствии с выполняемыми функциями (рис.3,4,5,6,7,8,9).
Рисунок 3 - декомпозиция процесса “Автоматизировать работу директора”
Рисунок 4 - декомпозиция процесса “Автоматизировать работу ведущего специалиста по договорной работе”,
Рисунок 5 - декомпозиция процесса “Автоматизировать работу отдела геодезии”
Рисунок 6 - декомпозиция процесса “Автоматизировать работу службы по организации и проведению аукционов”
Рисунок 7 - декомпозиция процесса “Автоматизировать работу отдела индивидуальной застройки”,
Рисунок 8 - декомпозиция процесса “Автоматизировать работу архитектурно-планировочного отдела и прочие работы”,
Рисунок 9 - декомпозиция процесса “Автоматизировать работу отдела эстетики и рекламы”
1.1.2 Диаграмма дерева узлов
Диаграмма дерева узлов показывает иерархию процессов в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между процессами. Она имеет вид традиционного иерархического дерева, где верхний узел (прямоугольник) соответствует работе с контекстной диаграммы, а последующие нижние узлы представляют собой дочерние уровни декомпозиции. Можно также создать диаграмму дерева узлов лишь для некоторой части модели.
На диаграмме дерево узлов нижний уровень детализации представляется в виде списка, остальные процессы в виде прямоугольников.
Диаграмма дерева узлов проектируемой базы данных представлена в приложении1 (рисунок 10).
Рисунок 10 - Диаграмма дерева узлов
1.2 Информационная модель
1.2.1 Идентификация сущностей и связей. ER-диаграмма логического уровня
Erwin имеет два уровня представления модели - логический и физический. Логический уровень - это абстрактный взгляд на данные. Объекты модели, представляемые на нем, называются сущностями и атрибутами. Логическая модель данных является универсальной, т.к. не зависит от конкретной СУБД.
Для отображения информационной модели рассматриваемого процесса на логической модели используются следующие сущности:
- «Подразделения» - информация о подразделениях проектного бюро;
- «Отделы» - информация об отделах пороектного бюро. Содержит номер отдела, его название, индетификационный номер в регистре населения (ИНРН) начальника отдела;
- «Должности» - информация о должностях бюро. Исполнение договоров и прочие действия закрепляются именно за должностью для приемственности исполнения вне зависимости от движения сотрудников по организации (приема новых, продвижения по службе и др.). Содержит идентификатор, название должности, ИНРН сотрудника отдела, номер подразделения, номер отдела;
- «Сотрудники» - информация о сотрудниках, работающих в проектном бюро;
- «Услуги» - перечень услуг проектного бюро;
- «Заказчики» - информация о заказчиках услуг бюро, а также нарушителях законодательства о рекламе;
- «Договора» - информация о заключенных с заказчиками договорах на услуги и их состоянии, а также поступающих финансовых средствах и фактически выполненных работах;
- «Шаблоны_договоров» - для хранения информации для подготовки типовых договоров;
- «Нарушения_рекламы» - информация и выявленных нарушениях законодательства о рекламе, предпринятых действиях и их результатах;
- «Нормы_закона» - перечень пунктов законодательства о рекламе;
- «Улицы» - справочник улиц города;
- «Префикс» - вспомогательный справочник для «Улицы»;
- «Районы» - вспомогательный справочник для «Улицы».
Для однозначного определения записей в каждом из отношений выделен первичный ключ.
Внешние ключи для отношений БД:
- в отношениях «Должности» и «Подразделения» - это ключ «номер_подразделения»;
- в отношениях «Должности» и «Отделы» - это ключ «номер_отдела»;
- в отношениях «Должности» и «Сотрудники» - это ключ «in_rn»;
- в отношениях «Отделы» и «Сотрудники» - это ключ «in_rn»;
- в отношениях «Договора» и «Заказчики» - это ключ «id_customer»;
- в отношениях «Договора» и «Должности» - это ключ «id_staff»;
- в отношениях «Договора» и «Отделы» - это ключ «номер_отдела»;
- в отношениях «Договора» и «Услуги» - это ключ «id_servise»;
- в отношениях «Договора» и «Шаблоны_договоров» - это ключ «id_pattern»;
- в отношениях «Нарушения_рекламы» и «Заказчики» - это ключ «id_customer»;
- в отношениях «Нарушения_рекламы» и «Нормы_закона» - это ключ «id_norma»;
- в отношениях «Нарушения_рекламы» и «Улицы» - это ключ «id_street»;
- в отношениях «Улицы» и «Префикс» - это ключ «id_ntu»;
- в отношениях «Улицы» и «Районы» - это ключ «id_admdel».
На логическом уровне проектирования в моделируемой базе данных присутствуют следующие типы связей между описанными сущностями:
· неиденцифицирующие связи;
· связи многие-ко-многим
Связь между сущностями «Должности» и «Подразделения» неидентифицирующая, не разрешающая присутствие нулей, т.к. каждая должность входит в определенное подразделение. Тип связи 1 ко многим, т.к. в одном подразделении содержится несколько должностей.
Связь между сущностями «Должности» и «Отделы» неидентифицирующая, не разрешающая присутствие нулей, т.к. каждая должность закреплена за определенным отделом. Тип связи 1 ко многим, т.к. в одном отделе имеются несколько должностей.
Связь между сущностями «Должности» и «Сотрудники» неидентифицирующая, не разрешающая присутствие нулей, т.к. каждую должность занимает определенный сотрудник. Тип связи 1 ко многим, т.к. любой сотрудник может занимать определенную должность.
Связь между сущностями «Отделы» и «Сотрудники» неидентифицирующая, не разрешающая присутствие нулей, т.к. все отделы управляются руководителем или его заместителем. Тип связи 1 ко многим, т.к. каждый отдел возглавляет определенный сотрудник.
Связь между сущностями «Договора» и «Заказчики» неидентифицирующая, не разрешающая присутствие нулей, т.к. все договора имеют заказчика. Тип связи 1 ко многим, т.к. заказчики могут иметь несколько договоров, а у договора только один заказчик.
Связь между сущностями «Договора» и «Отделы» неидентифицирующая, не разрешающая присутствие нулей, т.к. каждый договор направляется в отдел, оказывающий заказанную услугу.
Связь между сущностями «Договора» и «Должности» неидентифицирующая, не разрешающая присутствие нулей, т.к. для каждого договора руководителем отдела оказывающего услугу назначается ответственный исполнитель.
Связь между сущностями «Договора» и «Услуги» неидентифицирующая, не разрешающая присутствие нулей, т.к. все договора заключаются на оказываемые услуги согласно перечня. Тип связи 1 ко многим, т.к. каждый договор заключается на одну любую услугу из перечня.
Связь между сущностями «Договора» и «Шаблоны_договоров» неидентифицирующая, разрешающая присутствие нулей, т.к. договор может быть офомлен на бумажном носителе любыми средствами, как по предусмотренным системой шаблонам, так и строронним программным обеспечением. Тип связи 1 ко многим, т.к. договор имеет одну любую физическую форму.
Связь между сущностями «Нарушения_рекламы» и «Заказчики» неидентифицирующая, не разрешающая присутствие нулей, т.к. все нарушения имеют нарушителя (потенщиального заказчика). Тип связи 1 ко многим, т.к. заказчики (нарушители) могут иметь несколько нарушений, а у нарушения только один нарушитель.
Связь между сущностями «Нарушения_рекламы» и «Нормы_закона» неидентифицирующая, не разрешающая присутствие нулей, т.к. все нарушения соответствуют определенным в законодательстве и отраженным в справочнике нормам. Тип связи 1 ко многим, т.к. каждому нарушению в соответствует определенная норма. Если рекламная конструкция нарушает несколько норм, то каждое нарушение рассматривается отдельно.
Связь между сущностями «Нарушения_рекламы» и «Улицы» неидентифицирующая, не разрешающая присутствие нулей, т.к. каждое нарушение совершается в определенном городском пространстве, привязанном к адресации с помощью названий улиц и номеров домов. Для привязки достаточно указать одну улицу, на одной улице возможны несколько нарушений.
Связь между сущностями «Улицы» и «Префикс» неидентифицирующая, не разрешающая присутствие нулей, т.к. каждому названию улицы обязательно соответствут один префикс.
Связь между сущностями «Улицы» и «Районы» неидентифицирующая, не разрешающая присутствие нулей, т.к. каждая улица входит в одно из административных деление города и пригорода.
ER-диаграмма логического уровня представлена на рисунке 11.
Рисунок 11 - ER-диаграмма логического уровня
1.2.2 ER-диаграмма физического уровня. Ограничения доменов. Ограничения ссылочной целостности. Переопределение триггеров. Индексирование отношений
Физическая модель данных зависит от конкретной СУБД. В ней содержится информация обо всех объектах БД. Одной и той же логической модели может соответствовать несколько разных физических. В физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах.
Проверим, удовлетворяют ли все имеющиеся отношения соответствующим наборам ограничений.
Первая нормальная форма требует, чтобы значения всех атрибутов отношения были атомарными. При рассмотрении информационной модели было отмечено, что значения атрибутов всех отношений логически разделить на элементы нельзя и, следовательно, они удовлетворяют условию первой нормальной формы. Пример, рассмотрим таблицу «Отделы». Ключевой атрибут в ней - «номер_отдела» не может быть разделен на элементы. Неключевые атрибуты - название, ИНРН начальника отдела, также являются атомарными.
Вторая нормальная форма требует, чтобы отношение находилось в первой нормальной форме, и каждый не ключевой атрибут функционально полно зависел от первичного ключа. И это требование также выполняется в рассматриваемой модели. Пример, рассмотрим таблицу «Отделы». Ключевой атрибут в ней - «номер_отдела». Неключевые атрибуты - название, ИНРН начальника отдела, зависят функционально полно только от первичного ключа.
Для нормализации схем отношений к третьей нормальной форме необходимо чтобы каждый детерминант (любой атрибут, от которого функционально полно зависит некоторый другой атрибут) является возможным ключом. В рассматриваемой модели это условие соблюдается. Пример, рассмотрим таблицу «Отделы». Как было отмечено выше, все неключевые атрибуты функционально полно зависят от первичного ключа, т.е. первичный ключ является детерминантом.
Реализация ссылочной целостности:
· При изменении информации о каком-либо сотруднике из таблицы «Сотрудники» в таблицах «Отделы» и «Должности» информация будет автоматически меняться (каскадное обновление), удалять из таблицы «Сотрудники» разрешено только не используемые записи. Проверку осуществляет специальный триггер;
· При изменении информации об отделе из таблицы «Отделы» в таблицах «Договора» и «Должности» информация будет автоматически меняться (каскадное обновление), удалять из таблицы «Отделы» разрешено только не используемые записи. Проверку осуществляет специальный триггер;
· При изменении информации в «Подразделения» в таблице «Должности» информация будет автоматически изменяться (каскадное обновление), удалять из таблицы «Подразделения» разрешено только не используемые записи. Проверку осуществляет специальный триггер;
· При изменении информации в «Должности» в таблице «Договора» информация будет автоматически изменяться (каскадное обновление), удалять из таблицы «Должности» разрешено только не используемые записи. Проверку осуществляет специальный триггер;
· При изменении информации в «Услуги» в таблице «Договора» информация будет автоматически изменяться (каскадное обновление), удалять из таблицы «Услуги» разрешено только не используемые записи. Проверку осуществляет специальный триггер;
· При изменении информации в «Шаблоны договоров» в таблице «Договора» информация будет автоматически изменяться (каскадное обновление), удалять из таблицы «Шаблоны_договоров» разрешено только не используемые записи. Проверку осуществляет специальный триггер;
· При изменении информации в «Заказчики» в таблице «Договора» информация будет автоматически изменяться (каскадное обновление), удалять из таблицы «Заказчики» разрешено только не используемые записи;
· При изменении информации в «Нормы_закона» в таблице «Нарушения_рекламы» информация будет автоматически изменяться (каскадное обновление), удалять из таблицы «Нормы_закона» разрешено только не используемые записи. Проверку осуществляет специальный триггер;
· При изменении информации в «Улицы» в таблице «Нарушения_рекламы» информация будет автоматически изменяться (каскадное обновление), удалять из таблицы «Улицы» разрешено только не используемые записи. Проверку осуществляет специальный триггер;
· При изменении информации в «Районы» в таблице «Улицы» информация будет автоматически изменяться (каскадное обновление), удалять из таблицы «Районы» разрешено только не используемые записи. Проверку осуществляет специальный триггер;
· При изменении информации в «Префикс» в таблице «Улицы» информация будет автоматически изменяться (каскадное обновление), удалять из таблицы «Префикс» разрешено только не используемые записи. Проверку осуществляет специальный триггер;
Типы данных
1. Для обеспечения уникальности ключевого поля в таблицах «Должности», «Сотрудники», «Услуги», «Заказчики», «Договора», «Шаблоны_договоров», «Нарушения_рекламы, «Нормы_закона», «Улицы», «Префикс», «Районы» ключевым поле этой таблицы id_badrek является автоматическим счетчиком типа int.
2. Во всех таблицах для полей с датой (тип данных - datetime) установлен триггер контроля ввода даты: дата не может быть ранее и позденее одного года от текущей даты.
Типы данных выбирались согласно хранимой информации и представлены на ER-диаграмма физического уровня (рисунок 12).
Рисунок 12 - ER-диаграмма физического уровня
Для приложения были разработаны следующие триггеры:
Договора_trd - копирование удаляемой информации в таблицу «Договора_Deleted» с указанием даты удаления и пользователя, удалившего запись
Договора_triu - фиксация текущей даты и пользователя при изменении таблицы «Договора»
Договора_Даты_triu - контроль корректности введенных дат в таблице «Договора». Разрешено внесение и изменение дат в пределах одного года от текущего дня.
Нарушения_рекламы_trd - копирование удаляемой информации в таблицу «Нарушения_рекламы _Deleted» с указанием даты удаления и пользователя
Нарушения_рекламы_triu - фиксация текущей даты и пользователя при изменении таблицы «Нарушения_рекламы». Разрешено внесение и изменение дат в пределах одного года от текущего дня.
Нарушения_рекламы_Даты_triu - контроль корректности введенных дат в таблице «Нарушения_рекламы»
Отделы_trd - запрет удаления записей таблицы «Отделы»
Подразделения_trd - запрет удаления записей таблицы «Подразделения»
Префикс_trud - запрет удаления и изменения записей таблицы «Префикс»
Улицы_trd - запрет удаления записей таблицы «Улицы»
1.2.3 Определение представлений, хранимых процедур серверной компоненты. ER-диаграмма в режиме отображения представлений
Представление (View) для конечных пользователей выглядит как таблица, но при этом само не содержит данных, а лишь представляет данные, расположенные в таблице. Физически представление реализовано в виде SQL-запроса, на основе которого производится выборка данных из одной или нескольких таблиц или представлений.
Представление может выбирать данные из других представлений, которые, в свою очередь, могут также основываться на представлениях или таблицах. Вложенность представлений не должна превышать 32. Представление часто применяется для ограничения доступа пользователей к конфиденциальным данным в таблице.
Для приложения были разработаны следующие представления:
«Договора_неоплачены» - выборка неоплаченных договоров
«Должности_по_сотруднику» - информация о занимаемой сотрудником должности. Содержит информацию из таблиц «Сотрудники», «Отделы», «Должности»;
«Заказчики_всего_оплачено» - информация о поступивших средствах от заказчика по всем договорам базы;
«Заказчики_текущие» - список заказчиков, договора которых по текущей дате на исполнении. Информацию можно использовать для информационной рассылки о ходе выполнения договора;
«Информация_по_отделам» - название и сведения о руководителях отделов. Содержит информацию из таблиц «Отделы» и «Сотрудники»;
«Карточка_Договора» - содержит полную информация по договорам, а также связанные с договором сведения из таблиц «Должности», «Отделы», «Услуги», «Заказчики»;
«Карточка_Нарушения_рекламы» - содержит полную информация по обнаруженным нарушениям рекламного законодательства, а также связанные сведения из таблиц «Улицы», «Префиксы», «Заказчики»;
«Структура_организации» - информация по структуре организации и сотрудникам. Содержит информацию из таблиц «Должности», «Подразделения», «Отделы», «Сотрудники»;
«Уведомление_осталось» - информация о текущих нарушениях рекламы с указанием оставшегося количество дней до конца срока уведомления. По истечении срока уведомления отправляется предписание, в случае отсутствия действий по устранению нарушения;
«Улицы_районы» - список улиц города с указанием префикса и административного деления. Содержит информацию из таблиц «Префикс», «Улицы», «Районы».
Хранимые процедуры имеют много общего с обычными процедурами. Использование хранимых процедур позволяет значительно повысить скорость разработки приложений.
Для базы данных были разработаны следующие хранимые процедуры:
«CountDogMonth» - для подсчета количества договоров за текущий месяц;
«CustomerCount» - число заказчиков в базе данных;
«SrokDogMonth» - вывод списка просроченных договоров и их исполнителей;
«SrokDogMonth» - сумма по заключенным договорам за текущий месяц;
«Договора_DH1795_1SJOURN_конверт» - процедура для конвертации данных из программы «1С Предпирятие» в таблицу «Договора». Необходима для плавной смены программного продукта с переносом имеющейся информации по заключенным договорам;
«Заказчики_SP1806_конверт» - процедура для конвертации имеющихся данных из программы «1С Предпирятие» в таблицу «Заказчики»;
«Заказчики_УНП_чистка_cur» - удаление повторных записей о заказчиках после конвертации данных из другой программы, где отсутствовал или не соблюдался контроль повторного внесения информации в справочник организаций. В созданной базе уникальность записи о заказчике осуществлена посредством требования уникальности содержания поля «УНП» таблицы «Заказчики»;
«Заказчики_УНП_повтор_cur» - контрольная проверка дублирования информации о заказчиках после конвертации и чистки из программы «1С Предпирятие»;
«Отделы_Прибыль_cur» - информация о полученной прибыли по отделам с подведением итоговой суммы по предприятию;
«Услуги_Рост_cur» - информация о поступлении денежных средств по услугам в процентном сравнении по отношению к предыдущему году;
(UDF)
«BigMoney_cur» - функция с курсором для подсчета прибыли от деятельности отдела;
«ConvDate» - конвертация даты для переноса информации из базы "1С Предприятие";
«ConvPr» - конвертация информации о предоплате из базы "1С Предприятие";
«DateDiffSrok» - подсчет количества дней до окончания срока исполнения договора;
«DateTrue» - определение попадание даты в указанный диапозон от текущей даты;
«MoneyWords» - представление числа (денежной суммы) прописью;
«SumStr» - преобразование числа из цифрого вида в символьное;
«SumStrThree» - формирования строки для трехзначного числа;
«UvedomlenieOut» - контроль срока на исправление нарушения, дается семь дней, иначе направляется предписание. Возвращает колличество дней на исправление.
1.3 Верификация спроектированной логической модели
После разработки информационной модели ее следует связать с функциональной моделью. Такая связь гарантирует завершенность анализа, гарантирует, что есть источники данных (сущности) для всех работ. Связывание моделей способствует согласованности, корректности и завершенности анализа. Стрелки в функциональной модели обозначают некоторую информацию, использующуюся в моделируемой системе. В информационной модели на логическом уровне информация изображается в виде сущностей. Сущности состоят из совокупностей экземпляров сущностей (кортежи отношений). К информационной модели предъявляется требование нормализации, что должно обеспечить компактность и непротиворечивость хранения данных. Информация, которая моделируется одной стрелкой в функциональной модели, может содержаться в нескольких сущностях и атрибутах информационной модели. На функциональной модели могут присутствовать различные стрелки, изображающие одни и те же данные. Информация о таких стрелках находится в одних и тех же сущностях. Следовательно, одной и той же стрелке в функциональной модели могут соответствовать несколько сущностей в информационной модели и, наоборот, одной сущности может соответствовать несколько стрелок.
Работы в функциональной модели могут создавать или изменять данные, которые соответствуют входящим и выходящим стрелкам. Они могут воздействовать как целиком на сущности (создавая и модифицируя экземпляры сущности), так и на отдельные атрибуты сущности.
Таблица 1 - Отчет о верификации модели
|
Arrow Name |
Entity Name |
Attribute Name |
|
|
Акт выполненных работ |
Договора |
акт_подписан |
|
|
дата_договора |
|||
|
номер_договора |
|||
|
сумма_договора |
|||
|
сумма_оплачено |
|||
|
Шаблоны_договоров |
файл |
||
|
шаблон |
|||
|
Готовность аукциона земельных участков |
Договора |
id_auction |
|
|
дата_исполнения |
|||
|
отказ |
|||
|
примечание |
|||
|
Готовность паспорта рекламы |
Договора |
id_pasport |
|
|
дата_исполнения |
|||
|
отказ |
|||
|
примечание |
|||
|
Готовность проектной документации |
Договора |
id_project |
|
|
дата_исполнения |
|||
|
отказ |
|||
|
примечание |
|||
|
Готовность топосъёмки местности |
Договора |
id_topographical |
|
|
дата_исполнения |
|||
|
отказ |
|||
|
примечание |
|||
|
Договор на оказание услуги |
Договора |
дата_договора |
|
|
номер_договора |
|||
|
сумма_договора |
|||
|
Заказчики |
id_street |
||
|
kod |
|||
|
адрес_почта |
|||
|
адрес_электронный |
|||
|
лицензия_ИП |
|||
|
мобильный |
|||
|
наименование_краткое |
|||
|
наименование_полное |
|||
|
ОКПО |
|||
|
основание |
|||
|
офис |
|||
|
руководитель_ип |
|||
|
руководитель_рп |
|||
|
сайт |
|||
|
счет_в_банке |
|||
|
телефон |
|||
|
УНП |
|||
|
Шаблоны_договоров |
файл |
||
|
Заказ услуги |
Договора |
id_contract |
|
|
id_customer |
|||
|
id_pattern |
|||
|
id_service |
|||
|
id_staff |
|||
|
акт_подписан |
|||
|
дата_договора |
|||
|
дата_начала |
|||
|
номер_договора |
|||
|
описание_работ |
|||
|
предоплата_процент |
|||
|
примечание |
|||
|
срок_исполнения |
|||
|
сумма_оплачено |
|||
|
шаблон |
|||
|
Информация о выполненных заказах |
Договора |
номер_договора |
|
|
отказ |
|||
|
примечание |
|||
|
Информация о местности |
Договора |
id_topographical |
|
|
дата_исполнения |
|||
|
отказ |
|||
|
примечание |
|||
|
Информация о спросе и предложениях рынка |
Услуги |
id_service |
|
|
описание |
|||
|
тариф |
|||
|
услуга |
|||
|
Информация о строительных объектах |
Договора |
id_project |
|
|
дата_исполнения |
|||
|
отказ |
|||
|
примечание |
|||
|
Информация об объектах рекламы |
Договора |
id_pasport |
|
|
дата_исполнения |
|||
|
отказ |
|||
|
примечание |
|||
|
Информация об оплате услуг |
Договора |
сумма_оплачено |
|
|
Информация по земельным участкам |
Договора |
id_auction |
|
|
дата_исполнения |
|||
|
отказ |
|||
|
примечание |
|||
|
Информация по нарушениям законодательства о рекламе |
Заказчики |
id_customer |
|
|
id_street |
|||
|
kod |
|||
|
адрес_почта |
|||
|
адрес_электронный |
|||
|
лицензия_ИП |
|||
|
мобильный |
|||
|
наименование_краткое |
|||
|
наименование_полное |
|||
|
ОКПО |
|||
|
основание |
|||
|
офис |
|||
|
руководитель_ип |
|||
|
руководитель_рп |
|||
|
сайт |
|||
|
счет_в_банке |
|||
|
телефон |
|||
|
УНП |
|||
|
Нарушения_рекламы |
id_badrek |
||
|
id_customer |
|||
|
id_street |
|||
|
дата_обнаружения |
|||
|
дом |
|||
|
исправлено |
|||
|
описание |
|||
|
предписание |
|||
|
уведомление |
|||
|
фото |
|||
|
Инфформация о заказчиках |
Заказчики |
id_customer |
|
|
id_street |
|||
|
адрес_почта |
|||
|
адрес_электронный |
|||
|
мобильный |
|||
|
наименование_полное |
|||
|
офис |
|||
|
руководитель_ип |
|||
|
сайт |
|||
|
телефон |
|||
|
Карточка договора |
Договора |
id_contract |
|
|
id_service |
|||
|
id_staff |
|||
|
акт_подписан |
|||
|
дата_договора |
|||
|
номер_договора |
|||
|
отказ |
|||
|
примечание |
|||
|
срок_исполнения |
|||
|
сумма_договора |
|||
|
сумма_оплачено |
|||
|
Заказчики |
наименование_краткое |
||
|
Отделы |
отдел |
||
|
Подразделения |
подразделение |
||
|
Сотрудники |
ФИО |
||
|
Карточка нарушения законодательства о рекламе |
Нарушения_рекламы |
id_badrek |
|
|
id_customer |
|||
|
id_street |
|||
|
дата_обнаружения |
|||
|
дом |
|||
|
исправлено |
|||
|
описание |
|||
|
предписание |
|||
|
уведомление |
|||
|
фото |
|||
|
Отчет о поступивших заказах на услуги |
Договора |
id_contract |
|
|
id_service |
|||
|
акт_подписан |
|||
|
дата_договора |
|||
|
дата_исполнения |
|||
|
дата_начала |
|||
|
номер_договора |
|||
|
номер_отдела |
|||
|
описание_работ |
|||
|
отказ |
|||
|
предоплата_процент |
|||
|
примечание |
|||
|
сумма_договора |
|||
|
сумма_оплачено |
|||
|
Отделы |
отдел |
||
|
Подразделения |
|||
|
Услуги |
описание |
||
|
Отчет по актам выполненных работ |
Договора |
id_contract |
|
|
акт_подписан |
|||
|
дата_договора |
|||
|
номер_договора |
|||
|
сумма_договора |
|||
|
сумма_оплачено |
|||
|
Заказчики |
наименование_краткое |
||
|
Отделы |
отдел |
||
|
Сотрудники |
ФИО |
||
|
Услуги |
описание |
||
|
Отчет по выполнению договоров исполнителями |
Договора |
id_contract |
|
|
id_staff |
|||
|
акт_подписан |
|||
|
дата_договора |
|||
|
дата_исполнения |
|||
|
дата_начала |
|||
|
номер_договора |
|||
|
отказ |
|||
|
примечание |
|||
|
срок_исполнения |
|||
|
сумма_договора |
|||
|
сумма_оплачено |
|||
|
Отделы |
отдел |
||
|
Сотрудники |
ФИО |
||
|
Отчет по договорам |
Договора |
id_contract |
|
|
id_service |
|||
|
id_staff |
|||
|
акт_подписан |
|||
|
дата_договора |
|||
|
номер_договора |
|||
|
отказ |
|||
|
примечание |
|||
|
срок_исполнения |
|||
|
сумма_договора |
|||
|
сумма_оплачено |
|||
|
Отчет по нагрузке на исполнителя |
Договора |
id_contract |
|
|
id_staff |
|||
|
дата_исполнения |
|||
|
дата_начала |
|||
|
срок_исполнения |
|||
|
Сотрудники |
ФИО |
||
|
Смета договора |
Договора |
сумма_договора |
|
|
Список заказчиков для информационной рассылки |
Договора |
id_contract |
|
|
id_customer |
|||
|
акт_подписан |
|||
|
дата_договора |
|||
|
номер_договора |
|||
|
отказ |
|||
|
срок_исполнения |
|||
|
сумма_договора |
|||
|
сумма_оплачено |
|||
|
Заказчики |
адрес_почта |
||
|
адрес_электронный |
|||
|
лицензия_ИП |
|||
|
наименование_краткое |
|||
|
руководитель_ип |
|||
|
телефон |
|||
|
Список нарушителей законодательства о рекламе |
Нарушения_рекламы |
id_badrek |
|
|
id_customer |
|||
|
id_street |
|||
|
дата_обнаружения |
|||
|
дом |
|||
|
исправлено |
|||
|
описание |
|||
|
предписание |
|||
|
уведомление |
|||
|
Требования законодательства РБ |
Услуги |
id_service |
|
|
описание |
|||
|
тариф |
|||
|
услуга |
2. РЕАЛИЗАЦИЯ СИСТЕМЫ
2.1 T-SQL-определения регламентированных запросов
1. В целях контроля поступления денежных средств необходимо проводить выборку неоплаченных договоров.
CREATE VIEW Договора_неоплачены
AS
SELECT Договора.номер_договора, Договора.сумма_договора, Договора.сумма_оплачено,
Заказчики.наименование_краткое
FROM Договора INNER JOIN
Заказчики ON Договора.id_customer=Заказчики.id_customer
WHERE Договора.сумма_оплачено < Договора.сумма_договора
2. После заключения договора назначается исполнитель согласно должностным обязанностям. При внесении информации о договоре в соответствующую карточку исполнителем выбирается должность по соответствующему работнику организации. Закрепление договора за должностью, а не за работником позволяет сохранить приемственность исполнителей конкретного договора.
CREATE VIEW Должности_по_сотруднику
AS
SELECT Должности.id_staff, Сотрудники.ФИО, Отделы.отдел, Должности.Должность
/*Указываем, какие поля, из каких таблиц будут выведены*/
FROM Отделы INNER JOIN
(Сотрудники INNER JOIN
Должности ON Сотрудники.in_rn = Должности.in_rn)
ON Отделы.номер_отдела = Должности.номер_отдела
/*Указываем таблицу, и связанные с ней при помощи оператора INNER JOIN таблицы, из которых выбираются связанные данные. После операнда ON указываем, по каким полям связаны три таблицы*/
3. Для объективной оценки значимости заказчика для организации необходима информация о поступивших средствах от заказчика по всем договорам базы.
CREATE VIEW Заказчики_всего_оплачено
AS
SELECT TOP(100) SUM(Договора.сумма_оплачено) ВСЕГО,
Заказчики.id_customer, Заказчики.наименование_краткое
FROM Договора INNER JOIN Заказчики ON
Договора.id_customer=Заказчики.id_customer
GROUP by Заказчики.id_customer, Заказчики.наименование_краткое
ORDER BY SUM(Договора.сумма_оплачено)
4. Список заказчиков, договора которых по текущей дате на исполнении.
CREATE VIEW Заказчики_текущие
AS
SELECT Договора.номер_договора, Договора.дата_исполнения,
Заказчики.наименование_краткое, Заказчики.адрес_почта
FROM Договора INNER JOIN
Заказчики ON Договора.id_customer=Заказчики.id_customer
WHERE Договора.дата_исполнения IS NULL
5. Информация об отделах с указанием номера, названия отдела и его руководителе. Выборка делается из таблиц «Отделы» и «Сотрудники».
CREATE VIEW Информация_по_отделам
AS
SELECT Отделы.номер_отдела, Отделы.отдел,Сотрудники.ФИО AS начальник
FROM Сотрудники INNER JOIN Отделы ON Сотрудники.in_rn = Отделы.in_rn
6. Полная информация по договору и состоянию его исполнения. Представление делается по всем полям таблицы «Договора», также полям таблиц «Отделы», «Услуги», «Заказчики».
CREATE VIEW Карточка_Договора
AS
SELECT Договора.*, Должности.должность, Отделы.отдел, Услуги.услуга, Заказчики.наименование_полное
FROM Договора INNER JOIN
Должности ON Договора.id_staff = Должности.id_staff INNER JOIN
Отделы ON Договора.номер_отдела = Отделы.номер_отдела INNER JOIN
Услуги ON Договора.id_service = Услуги.id_service INNER JOIN
Заказчики ON Договора.id_customer = Заказчики.id_customer
7. Полная информация по обнаруженным нарушениям рекламного законодательства, а также связанные сведения из таблиц «Улицы», «Префиксы», «Заказчики».
CREATE VIEW Карточка_Нарушения_рекламы
AS
SELECT Нарушения_рекламы.*, Заказчики.наименование_краткое,
Префикс.вид+Улицы.улица+', д.'+Нарушения_рекламы.дом AS Адрес
FROM Нарушения_рекламы INNER JOIN
Заказчики ON Нарушения_рекламы.id_customer=Заказчики.id_customer INNER JOIN
Улицы ON Нарушения_рекламы.id_street=Улицы.id_street INNER JOIN
Префикс ON Улицы.id_ntu=Префикс.id_ntu
8. Информация о сотрудниках в структуре организации. Представление необходимо для вывода группированного по подразделениям и отделам списка сотрудников с указанием занимаемой должности. Выборка делается из таблиц «Должности», «Подразделения», «Отделы» и «Сотрудники».
CREATE VIEW Структура_организации
AS
SELECT Должности.должность, Подразделения.подразделение, Отделы.отдел, Сотрудники.ФИО
FROM Подразделения INNER JOIN
(Отделы INNER JOIN
(Должности INNER JOIN
Сотрудники ON Должности.in_rn = Сотрудники.in_rn)
ON Отделы.номер_отдела = Должности.номер_отдела)
ON Подразделения.номер_подразделения = Должности.номер_подразделения
9. «Уведомление_осталось» - информация о текущих нарушениях рекламы с указанием оставшегося количество дней до конца срока уведомления. По истечении срока уведомления отправляется предписание, в случае отсутствия действий по устранению нарушения;
CREATE VIEW Уведомление_осталось
AS
SELECT Заказчики.наименование_краткое,
Префикс.вид+Улицы.улица+', д.'+Нарушения_рекламы.дом AS адрес,
Нарушения_рекламы.описание,Нарушения_рекламы.уведомление , dbo.UvedomlenieOut(Нарушения_рекламы.уведомление) AS [осталось дней]
FROM Нарушения_рекламы INNER JOIN
Заказчики ON Нарушения_рекламы.id_customer = Заказчики.id_customer INNER JOIN
Улицы ON Нарушения_рекламы.id_street=Улицы.id_street INNER JOIN
Префикс ON Улицы.id_ntu=Префикс.id_ntu
WHERE (Нарушения_рекламы.уведомление IS NOT NULL) AND (Нарушения_рекламы.предписание IS NULL)
10. Информация по улицам города с указанием префикса и административного деления.
CREATE VIEW Улицы_районы
AS
SELECT Улицы.id_street, Префикс.вид, Улицы.улица, Районы.район
FROM Районы INNER JOIN
(Улицы INNER JOIN
Префикс ON Улицы.id_ntu=Префикс.id_ntu)
ON Районы.id_admdel=Улицы.id_admdel
2.2 T-SQL-определения триггеров
1. Договора_trd - тригер для копирование удаляемой информации в таблицу «Договора_Deleted» с указанием даты удаления и пользователя, удалившего запись
INSERT INTO Договора_Deleted (id_contract, номер_договора, дата_договора, срок_исполнения, сумма_договора, сумма_оплачено, акт_подписан, отказ, id_service, id_pattern , id_customer, id_staff, номер_отдела, id_pasport, id_auction, id_topographical, id_project , дата_начала, НДС, предоплата_процент, дата_исполнения, договор_забрали, договор_вернули, акт_оплачен, UpdateDate, UpdatedBy, DeleteDate,DeletedBy)
SELECT id_contract, номер_договора, дата_договора, срок_исполнения, сумма_договора, сумма_оплачено, акт_подписан, отказ, id_service, id_pattern , id_customer, id_staff, номер_отдела, id_pasport, id_auction, id_topographical , id_project , дата_начала, НДС, редоплата_процент, дата_исполнения, договор_забрали, договор_вернули, акт_оплачен, UpdateDate, UpdatedBy, getdate(),SYSTEM_USER
FROM deleted
2. Договора_triu - тригер для фиксации текущей даты и пользователя при изменении в таблице «Договора»
UPDATE c SET UpdateDate = getdate(), UpdatedBy = SYSTEM_USER
FROM inserted i INNER JOIN Договора d ON i.id_contract = d.id_contract
3. Договора_Даты_triu - триггер, который контролирует диапозон вводимой даты (не более года от текущей).
BEGIN
DECLARE @t1 int, @t2 int, @t3 int, @t4 int, @t5 int, @t6 int
Set @t1 = (SELECT COUNT(id_contract) FROM inserted
WHERE (dbo.DateTrue([inserted].[дата_договора])=0))
Set @t2 = (SELECT COUNT(id_contract) FROM inserted
WHERE (dbo.DateTrue([inserted].[дата_начала])=0))
Set @t3 = (SELECT COUNT(id_contract) FROM inserted
WHERE (dbo.DateTrue([inserted].[дата_исполнения])=0))
Set @t4 = (SELECT COUNT(id_contract) FROM inserted
WHERE (dbo.DateTrue([inserted].[договор_забрали])=0))
Set @t5 = (SELECT COUNT(id_contract) FROM inserted
WHERE (dbo.DateTrue([inserted].[договор_вернули])=0))
Set @t6 = (SELECT COUNT(id_contract) FROM inserted
WHERE (dbo.DateTrue([inserted].[акт_оплачен])=0))
IF @t1 > 0 OR @t2 >0 OR @t3 >0 OR @t4 >0 OR @t5 >0 OR @t6 >0
BEGIN
--сообщения о неудаче операции
PRINT 'ДАТА ВНЕ ДИАПОЗОНА!!! Для добавления и изменения даты
разрешено отклонение не более одного года от текущей даты'
--откат (отмен...
Подобные документы
Современные базы данных и систем управления ими. Методы построения их приложений. Разработка СУБД на примере "Бюро находок", обеспечивающей пользователю возможности по пополнению, редактированию, просмотру и анализу базы данных. Реализация БД в MS Access.
курсовая работа [3,4 M], добавлен 19.06.2012Концептуальная модель базы данных "Бюро по трудоустройству". Разработка информационного и программного обеспечения объектов автоматизации. Реализация базы данных в СУБД MsAccess. Запросы к базе данных. Таблицы, отчеты и макросы. Интерфейс пользователя.
курсовая работа [5,2 M], добавлен 30.05.2016Автоматизация расчетов выполнения весенне-полевых работ в сельском хозяйстве средствами Системы управления базы данных. Структура входной и выходной информации. Блок-схема алгоритма решения задачи. Краткое описание программного средства обработки данных.
контрольная работа [58,8 K], добавлен 07.04.2014Использование автоматизированных баз данных в деятельности бюро по найму - способ облегчения деятельности сотрудников и повышения качества обслуживания клиентов. Разработка пользовательского интерфейса главной кнопочной формы информационной системы.
курсовая работа [1,4 M], добавлен 25.04.2019Создание совершенной автоматизированной системы формирования, учета и фиксирования выполнения заявок. Формализация задачи, построение структуры таблиц для хранения информации, схемы их взаимосвязей и описания алгоритмов обработки. Описание алгоритма.
курсовая работа [2,2 M], добавлен 30.06.2014Предметная область оперативного учета и расчета сметных работ. Автоматизация учета поступления и продажи товаров, комплектующих. Создание программного модуля для автоматизации раскроя профилей и заполнения на производстве, группировки информации.
дипломная работа [3,1 M], добавлен 29.08.2014Разработка автоматизированной информационной системы учета заказов на выполнение работ и формированию отчетной документации Бюро технической инвентаризации (БТИ). Системный анализ и схема документооборота. Разработка инфологической модели данных.
дипломная работа [603,9 K], добавлен 29.08.2014Создание автоматизированной системы мониторинга состояния аппаратных средств компьютерных сетей на основе протокола SNMP в среде программирования С++Builder. Описание реляционной базы данных и ее визуальное представление. Разработка диаграммы классов.
отчет по практике [2,2 M], добавлен 05.01.2016Понятие и свойства алгоритма. Способы его описания. Основные виды сортировок. Организация межтабличных связей для автоматического формирования счета, выставляемого клиенту для оплаты выполняемых работ с использованием программы Microsoft Office Excel.
курсовая работа [190,4 K], добавлен 07.07.2013Роль информационных технологий в обществе. Краткая природно-климатическая характеристика территории хозяйства ЗАО "Новорождественское", информационный анализ входной информации. Автоматизация уборочных работ, формирование массивов, запросов и отчетов.
курсовая работа [718,4 K], добавлен 17.11.2012Склад ОАО "Ориенбанк", его специфика и структура. Описание структуры базы данных складского учета для предприятия. Разработка пользовательского интерфейса программы. Инструкция к применению базы данных. Автоматизация операций и учета средств банка.
курсовая работа [4,7 M], добавлен 26.02.2010Реализация в автосервисах информационной справочной системы для организации учета распределения работ и ведения учета их стоимости. Анализ механизма предоставления услуг. Инфологическое и даталогическое проектирование. Выявление сущностей базы данных.
курсовая работа [1020,5 K], добавлен 24.01.2009Разработка инфологической и даталогической моделей. Особенности реализации базы данных оказания платных образовательных услуг в СУБД Visual Foxpro и Interbase. Описание и обоснование набора введенных индексов, правил поддержки ссылочной целостности.
курсовая работа [291,3 K], добавлен 21.05.2013Автоматизация торговли, база данных. Модели представления данных, СУБД Microsoft Access. Инструменты для работы с данными в Access. Назначение проектируемой базы данных для компьютерного магазина. Основные функции, решаемые информационной системой.
курсовая работа [2,9 M], добавлен 15.11.2011Анализ тенденций развития информационных технологий. Назначение и цели применения систем автоматизированного проектирования на основе системного подхода. Методы обеспечения автоматизации выполнения проектных работ на примере ЗАО "ПКП "Теплый дом".
курсовая работа [210,0 K], добавлен 11.09.2010Хранение информации базы данных в таблицах. Полная информация о клиентах, заказах, о кодах и наименованиях услуг, о текущих ценах на услуги и о должностях фотоателье. Основные формы по оформлению заказов. Создание печатных копий из базы данных.
курсовая работа [1,6 M], добавлен 15.12.2010Методика, используемые инструменты и приемы разработки реляционной базы данных и программного обеспечения для автоматизации учета и контроля работ на объектах фирмы, получения оперативной и объективной информации по основным показателям ее деятельности.
курсовая работа [2,5 M], добавлен 10.06.2013Разработка автоматизированной информационной системы для учета и контроля выполнения ремонтных работ, и предоставления услуг по разработке программного обеспечения компании "МегионСофтОйл", разработка алгоритмов приложений программной системы и модулей.
дипломная работа [5,3 M], добавлен 29.06.2012Сетевые информационные технологии, базирующиеся на архитектуре клиент-сервер. Автоматизация продажи билетов на пассажирские поезда. Функциональность базы данных, предоставление создателям информации о предметной области. Интерфейс, программные модули.
курсовая работа [1,8 M], добавлен 20.03.2009Анализ аналогов-ресурсов системы "Бюро регистрации несчастных случаев", критерии выбор задач, подлежащих автоматизации. Проектирование автоматизированного рабочего места сотрудника оперативного учета. Разработка модели базы с использованием CASE-средств.
дипломная работа [7,8 M], добавлен 21.01.2012
