ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ
УХТИНСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ
УНИВЕРСИТЕТ
КАФЕДРА ИСТ
КУРСОВОЙ ПРОЕКТ
Дисциплина: «Управление данными»
Тема:
Разработка проекта базы данных для АИС «Учет Проектов »
Выполнил
студент группы ИСТ-03
Степанченко В.Е
Проверил
доцент кафедры ИСТ
Николаева Н. А.
Ухта
2008
Содержание:
Введение
Глава 1.Описание предметной области
Глава 2. Описание средства моделирования
Глава 3. Методология концептуального проектирования баз данных
Построение концептуальной модели
Диаграмма «сущность-связь»
Нотация диаграммы «сущность-связь»
Спецификация сущностей
Глава 4. Построение логической модели
Глава 5. Формирование запросов
Заключение
Список литературы
Приложение 2
Приложение 1
ВВЕДЕНИЕ
В качестве темы для своего курсового проекта я выбрала разработку проекта базы данных для сопроводителей бухгалтерской программы Смета.
На троих работающих сопроводителей распределены 64 организации. Существует проблема создания плана посещения организаций на месяц, вследствие того что, план корректируется из-за поступления внеплановых заявок от обслуживаемых организаций. Нормировать график работы и учесть все организации, которые нужно посетить за текущий месяц, довольно сложно. Наличие возможности оперативного контроля за посещением организаций является одним из условий, способствующих эффективной деятельности организации.
Основными задачами создания плана посещения являются:
· своевременное посещение организации;
· удобство планирования маршрута в соответствии с планом посещения;
· учет актов выполненных работ.
На данный момент в нашей компании сложилась такая ситуация в которой сотрудники вынуждены нерационально использовать свое рабочее время из-за не правильно скоординированных действий. Это обосновывается тем что имеют место случаи когда несколько сотрудников в один момент времени приходят в одну и ту же организацию. Между сотрудниками нет четкой координации действий. Что наносит урон имиджу компании. Из-за не рационально распределенного времени многим сотрудникам приходится работать сверхурочно.
Изучив предметную область, я сделала вывод, что данная проблема актуальнадля сотрудников этой организации. Использование компьютерного планирования в решении этой проблемы значительно уменьшит расход рабочего времени на составление плана, и упростит контроль за посещением организаций.
Из выше описанной проблемы я делаю вывод, что необходимо создать базу данных, в которой будет храниться, обрабатываться вся необходимая информацию для пользователей БД. Цель данного курсового проекта заключается в разработке модели базы данных для процесса планирования плана работы в данной организации.
Для того чтобы прийти к цели я проделала работу следующего содержания:
Описала предметную область.
Далее я описала CASE-средства которое я выбрала для концептуального проектирования баз данных.
Также я дала описание методики логического проектирования базы данных и построила логическую модель и выявила отношения и ключи.
После построения логической модели базы данных я описала основные запросы к проектируемой базе данных.
Описание предметной области
После изучения предметной области я выделила следующие задачи: автоматизировать процесс планирования рабочего времени, осуществить контроль поступления актов выполненных работ.
Модель проектировалась с точки зрения сопроводителя. Организация занимается сопровождением бухгалтерской программы Смета. Работу по сопровождению выполняют так называемые Сопроводители.
Работа Сопроводителя состоит в том, что: сопроводители должны обслужить за текущий месяц все организации заключившие договор с фирмой. В свою очередь за правильно выполненную работу организация должна подписать акт о проделанной работе и передать его сопроводителю. В акте должен отображаться вид работы, дата, название организации и имя сопроводителя.
Работа может выполняться несколько дней. Акт подписывается при завершении работ. Акт предоставляется в фирму Сопроводителем.
Сопровождение осуществляется как согласно плану, так и по заявке предприятия.
План составляется в начале месяца. При составлении плана учитывается индивидуальный график работы Сопроводителя.
Сопроводитель может выполнять несколько видов работ по сопровождению, например: установку пакета обновлений и консультацию по модулю.
В течение месяца одну и ту же фирму могут обслуживать несколько Сопроводителей.
Глава 2. Описание средства моделирования
Инструменты для разработки, моделирования и анализа получили название CASE-средств (Computer-Aided Software Engineering). Понятие CASE-средства охватывает самые различные инструменты, которые служат для компьютерного анализа и моделирования. Одним из них является MicrosoftVisio - мощное средство моделирования и документирования бизнес процессов.
Microsoft
Visio
Microsoft Visioиспользуется для построения схем и диаграмм различного типа, а также наглядного представления бизнес-процессов. Ориентированный на широкий круг пользователей, Visio помогает оптимизировать работу организации, исключить ненужные операции, повысить гибкость и эффективность деятельности.
Также Visio предлагает:
- Инструментарий для построения технических и бизнес-диаграмм, позволяющих наглядно представлять имеющиеся концепции, данные и системы, а также создавать проекты новых систем. В состав Visio Professional входит набор бизнес-диаграмм, имеющийся в Visio Standard.
- Возможность выполнения более сложных задач, лучшее понимание и увеличение производительности для достижения успеха в бизнесе.
- Интеграция бизнес-процессов и систем путем извлечения данных из диаграмм Visio и их импорта в приложения в формате Microsoft Access, Microsoft Excel, Microsoft Word, Microsoft SQL Server™, XML и другие.
- Включение Visio в мощные программные продукты на базе Microsoft .NET для удовлетворения конкретных нужд бизнеса.
- Внедрение элементов управления графикой Visio в бизнес-приложения, созданные на базе .NET или операционной системы Microsoft Windows.
Построение концептуальной модели
Методология концептуального проектирования баз данных
Построение концептуальной модели это в первую очередь структурированный подход, предусматривающий использование специализированных процедур, технических приемов, инструментов, документации и нацеленный на поддержку и упрощения процесса проектирования.
Концептуальное проектирование – создание концептуального представления базы данных, включающее определение типов важнейших сущностей и существующих между ними связей.
Каждая концептуальная модель состоит из следующих компонентов: типы сущностей, типы связей, атрибуты и домены атрибутов, потенциальные ключи, первичные ключи.
Концептуальная модель данных дополняется документацией, создаваемой в процессе разработки этой модели. На этапе концептуального проектирования должно быть выполнено следующее:
Определение типов сущностей
Целью определения типов сущностей является определение основных типов сущностей, присутствующих в представлении данного пользователя о предметной области приложения.
Сущность – это класс объектов, наделённых общими свойствами в рамках данной задачи. Имя сущности уникально в пределах проекта. Имя сущности – существительное в единственном числе. Сущность должна иметь ключ.
Определение типов связей
Целью определения типов связей является определение важнейших типов связей, существующих между сущностями, выделенными на предыдущем этапе.
Связь– ассоциация между сущностями, включающая по одной сущности из каждого участвующего в связи типа сущности. Связь именуется с помощью глагола неопределенной формы несовершенного вида. Имя связи неуникально в рамках проекта.
Определение атрибутов и связывание их с типами сущностей и связей
Целью определения атрибутов является связывание атрибутов с соответствующими типами сущностей или связей.
Атрибут – это именованная характеристика экземпляра сущности. Наименование атрибута должно быть выражено существительным в единственном числе, допускается использование характеризующих прилагательных
Определение атрибутов, являющихся первичными ключами
Целью определения первичных ключей является определение всех ключей для каждого типа сущности и, если таких ключей окажется несколько, выбор среди них первичного ключа.
Потенциальным ключом называется атрибут или минимальный набор атрибутов заданной сущности, позволяющий уникальным образом идентифицировать каждый ее экземпляр.
Для некоторых сущностей возможно наличие нескольких потенциальных ключей. В этом случае среди них нужно выбрать один ключ, который будет называться первичным ключом. Все остальные потенциальные ключи будут называться альтернативными ключами.
При выборе первичного ключа среди нескольких потенциальных руководствуемся приведёнными ниже рекомендациями:
1) минимальным набором атрибутов
2)Использование того потенциального ключа, вероятность изменения значений которого минимальна
3)Выбор того потенциального ключа, который имеет минимальную вероятность потери уникальности значений в будущем
4)Использование потенциального ключа, значения которого имеют минимальную длину (в случае текстовых атрибутов);
5)Выбор потенциального ключа, с которым будет проще всего работать
Диаграммы
«сущность-связь» (
ERD
)
Одним из наиболее известных и получивших широкое распространение методов семантического моделирования является построение модели «сущность-связь». Этот подход строится на использовании модели «сущность-связь», предложенной Ченом в 1976 году и с тех пор неоднократно усовершенствовавшейся как самим Ченом, так и многими другими исследователями. Была предложена не только сама ER-модель как таковая, но и соответствующая ей технология построения диаграмм, получивших название «ER-диаграммы» (ERD). Диаграммы «сущность-связь» предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношения с другими объектами (связей). Эти диаграммные техники используются, прежде всего, для проектирования реляционных баз данных.
Нотация диаграммы «сущность-связь».
| Название объекта
|
Описание
|
Изображение
|
| Сущность | 1.Название сущности пишется внутри прямоугольника; 2.Под прямоугольником сущности всегда указывается ключ, который подчеркивается; 3.После последнего ключевого атрибута ставится запятая и многоточие |
|
| Сущность с обязательным классом принадлежности | На обязательный класс принадлежности сущности ( модальность должен)
указывает квадратик, расположенный вокруг точки на линии связи. |
|
| Сущность с необязательным классом принадлежности | На необязательный класс принадлежности сущности (модальность может)
указывает отсутствие квадратика, расположенного вокруг точки на линии связи. |
|
| Связь | Связь между сущностями изображается при помощи ромба, внутри которого пишется название связи | |
| Степень связи | - один к одному - один ко многим - многие ко многим |
1:1 1:n n:n |
Спецификация сущностей.
Организация
| №
|
Параметр | Описание |
| 1 | Имя | Организация |
| 2 | Множественное число | Организации |
| 3 | Синонимы | Название компании, Фирма |
| 4 | Описание | ID организации, Название организации, Адрес |
| 5 | Уникальный идентификатор (ключ) | ID организации |
| 6 | Связи | Организация предоставляет заявку, план сопровождения составляется по организациям, организация подписывает акт. |
Атрибуты сущности :
- ID организации;
- Название организации;
- Адрес;
- Заявка;
- План сопровождения;
- Акт.
Заявка
| № | Параметр | Описание |
| 1 | Имя | Заявка |
| 2 | Множественное число | Заявки |
| 3 | Синонимы | Заявка |
| 4 | Описание | ID Заявки, IDорганизации, Дата и время поступления, текст заявки. |
| 5 | Уникальный идентификатор (ключ) | ID Заявки |
| 6 | Связи | Заявка поступает от организации, на заявку оформляется акт по заявке. |
Атрибуты сущности :
- ID Заявки;
- ID организации;
- Дата и время поступления;
- Текст заявки;
- Организация;
- Акт по заявке.
План сопровождения
| № | Параметр | Описание |
| 1 | Имя | План сопровождения |
| 2 | Множественное число | Планы сопровождения |
| 3 | Синонимы | График посещения |
| 4 | Описание | IDсопроводителя, ID организации, Месяц. |
| 5 | Уникальный идентификатор (ключ) | ID сопроводителя, ID организации, Месяц. |
| 6 | Связи | План сопровождения создается по организациям, Сопроводитель создает план сопровождения. |
Атрибуты сущности :
- ID сопроводителя;
- ID организации;
- Месяц;
- Организация;
- Сопроводитель.
Работа
| № | Параметр | Описание |
| 1 | Имя | Работа |
| 2 | Множественное число | Работы |
| 3 | Синонимы | Трудовая деятельность |
| 4 | Описание | IDакта, ID работы, ID вида работы, ID модуля, Дата начала, дата окончания. |
| 5 | Уникальный идентификатор (ключ) | ID акта, ID работы. |
| 6 | Связи | Работа может подразделяться на несколько видов, работа может выполняться на определенном модуле, по окончании работы оформляется акт. |
- ID акта;
- ID работы;
- ID вида работы;
- ID модуля;
- Дата начала;
- Дата окончания;
- Вид работы;
- Модуль;
- Акт.
Вид работы
| № | Параметр | Описание |
| 1 | Имя | Вид работы |
| 2 | Множественное число | Виды работы |
| 3 | Синонимы | Вид работы |
| 4 | Описание | ID вида работы, Наименование вида работы |
| 5 | Уникальный идентификатор (ключ) | ID вида работы |
| 6 | Связи | Работа делится на несколько видов работы. |
Атрибуты сущности :
- ID вида работы;
- Наименование вида работы;
- Работа.
Модуль
| № | Параметр | Описание |
| 1 | Имя | Модуль |
| 2 | Множественное число | Модули |
| 3 | Синонимы | Модуль |
| 4 | Описание | ID модуля, наименование модуля. |
| 5 | Уникальный идентификатор (ключ) | ID модуля |
| 6 | Связи | Работа может выполняться на нескольких модулях. |
Атрибуты сущности :
- ID модуля;
- Наименование модуля;
- Работа.
Сопроводитель
| № | Параметр | Описание |
| 1 | Имя | Сопроводитель |
| 2 | Множественное число | Сопроводители |
| 3 | Синонимы | Работник |
| 4 | Описание | ID сопроводителя, имя сопроводителя. |
| 5 | Уникальный идентификатор (ключ) | ID сопроводителя |
| 6 | Связи | Сопроводитель подписывает акт, и составляет план сопровождения. |
Атрибуты сущности :
- ID сопроводителя;
- Имя сопроводителя;
- Акт;
- План сопровождения.
Акт
| № | Параметр | Описание |
| 1 | Имя | Акт |
| 2 | Множественное число | Акты |
| 3 | Синонимы | Акт |
| 4 | Описание | ID сопроводителя, ID акта, ID организации, Дата оформления. |
| 5 | Уникальный идентификатор (ключ) | ID сопроводителя, ID акта. |
| 6 | Связи | Сопроводитель подписывает акт, иногда акт оформляется по заявке, акт подписывает организация, по выполнению работы подписывается акт. |
Атрибуты сущности :
- ID сопроводителя;
- ID акта;
- ID организации;
- Дата оформления;
- Акт;
- План сопровождения;
- Работа;
- Акт по заявке;
- Сопроводитель;
- Организация.
Акт по заявке
| № | Параметр | Описание |
| 1 | Имя | Акт по заявке |
| 2 | Множественное число | Акты по заявкам |
| 3 | Синонимы | нет |
| 4 | Описание | ID акта, ID заявки. |
| 5 | Уникальный идентификатор (ключ) | ID акта. |
| 6 | Связи | Если организация оставляет заявку тогда акт оформляется по заявке. |
- ID акта;
- ID заявки;
- Заявка;
- Акт.
Данные сущности, связи между ними и характеризующие их атрибуты представлены в Приложении 1
.
Глава 4. Построение логической модели.
Методология логического проектирования.
Логическое проектирование баз данных – это процесс конструирования общей информационной модели предприятия на основе отдельных моделей данных пользователей, которая является независимой от особенностей реально используемой СУБД и других физических условий. Построение логической модели данных осуществляется на основе концептуальной модели данных, отражающей представление отдельного пользователя о предметной области приложения, и включает в себя проверку полученной модели с помощью методов нормализации. Доработка концептуальной модели проводится с целью удаления из них всех элементов, затрудняющих реализацию данной модели в среде реляционных СУБД. В результате выполнения этих действий структура концептуальной модели данных будет изменена таким образом, чтобы полностью отвечать требованиям, выдвигаемым реляционной моделью организации баз данных.
При переходе от концептуальной модели к логической осуществляются следующие действия:
Проверка на дублирование сущностей и удаление выявленных дубликатов;
Рассматриваются возможность введения в модель слабых сущностей;
Все связи n:m заменяются на 1:n, что подразумевает введение слабой сущности, с которой устанавливаются связи между ней и ранее связанными n:m сущностями.
Слабая сущность вводится также при наличии связи 1:n и при модальности «может» со стороны дочерней сущности, так как первичный ключ не должен содержать NULL. В ключ слабой сущности могут входить ключи сильных сущностей и дополнительные сущности. Удаляются избыточные связи. Удаляются все вычисляемые атрибуты.
В случае, когда какой-либо вычисляемый атрибут, помещаемый в БД, необходимо сравнивать программным путем на его соответствие текущему состоянию БД, удаление данного атрибута не обязательно.
На уровне логического проектирования определяются все первичные и внешние ключи.
Глава 5.
Формирование запросов.
Формирование запросов осуществляется с помощью операторов реляционной алгебры. Реляционная алгебра – это математический аппарат, базируемый на традиционных теоретико-множественных операциях и дополненный специфическими операциями над отношениями.
Запрос №1
Вывести список всех актов которые были подписаны одним Сопроводителем.
Запрос №
2
Вывести список всех работ на определенную дату.
Запрос №
3
Вывести организации по которым нет актов работ.
Запрос №
4
Сколько организаций посетил каждый сопроводитель?
Запрос №
5
Организации которые делали заявку в текущий период?
Запрос №
6
Сколько организаций за текущий месяц прошел определенный сопроводитель.
Заключение
В процессе работы над курсовым проектом была разработана реляционная модель базы данных для данного процесса.
1. В результате изучения предметной области были выделены основные сущности, такие как Организация, Заявка, План сопровождения, Работа, Вид работы, Модуль, Сопроводитель, Акт, Акт по заявке, связи между ними и атрибуты сущностей, которые затем подверглись документированию.
2. С помощью CASE-средства MicrosoftVisio была построена концептуальная модель, которая дала возможность наглядно отобразить все выделенные сущности, их атрибуты и связи между ними.
3. С помощью CASE–средства Computer Associates ERwin была построена логическая модель базы данных. Это позволило провести генерацию отношений и установить все ключи, которые обеспечивают ссылочную целостность БД.
4. С помощью операторов реляционной алгебры были составлены запросы, что позволило проверить корректность создаваемой базы данных.
Список литературы
1. Николаева Н.А. Базы и банки знаний. Контрольные работы: Учебное пособие/Н.А.Николаева:-Ухта:УГТУ, 2003.
2. Коннолли Томас, Бегг Каролин, Страчан Анна. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2001. – 1120 с.: ил. – Парал. тит. англ.
3. Григорьев Ю.А., Ревунков Г.И. Банки данных: Учеб. для вузов. – М.: Изд-во МГТУ им. Н.Э. Баумана, 2002.- 320 с.