Логическое проектирование базы данных
Сущности «Показатели», «Тип значения», «Пользователи», «Тип периода» и «Формы» объединены через сущность «Значение». Сущность «Единица значения» связана с сущностью «показатели», а сущность «Организация» связана с сущностью «пользователи». Таким образом, сущность «Значение» связана с другими сущностями отношением «многие-к-одному». В настоящее время вся работа в компании проделывается вручную… Читать ещё >
Логическое проектирование базы данных (реферат, курсовая, диплом, контрольная)
программный реляционный атрибут логический В данной курсовой работе была разработана база данных по автоматизации работы (сбору, обработке заявок на проделывание ремонтных работ) вымышленной строительной компании «О!Краско!».
В настоящее время вся работа в компании проделывается вручную и вся информация хранится на бумаге. Это явные недостатки и чтобы эти недостатки устранить была разработана база данных, в которой будет храниться информация о заказах, договорах, сметах, сотрудниках, поставщиках, инструменте, а также создаваться отчеты.
В данной работе представлен вариант автоматизации работы компании таким образом, чтобы можно было автоматизировать ряд процессов работы компании.
1. Анализ предметной области.
В данной курсовой работе предметную область составляет автоматизация рабочих процессов строительной компании. Автоматизация рабочих процессов, представлена в приведенной ниже схеме1 моделью BPwin (см. в приложении 1).
Рисунок 1.1 Схема функциональной модели База данных, разрабатываемая в рамках данной курсовой работы, представляет собой упрощенную модель предметной области «автоматизация рабочих процессов» и включает информацию о, заказах, поставщиках, сотрудниках, сметах, договорах и об имеющимся инструменте.
2. Концептуальное проектирование.
2.1 Перечень сущностей.
Для создания базы данных должны быть выделены следующие сущности:
1. Заказы.
2. Договор.
3. Смета.
4. Поставщики.
5. Сотрудники.
6. Инструмент.
2.2 Перечень атрибутов.
Для каждой сущности должен быть список атрибутов.
Таблица 2.1. Атрибуты.
Сущности. | Атрибуты. | Типы. | Размер | Ограничение. | |
Заказы. | Код заказа. | Числовой. | Длинное целое. | ||
ФИО заказчика. | Текстовый. | ||||
Адрес. | Текстовый. | Длинное целое. | |||
Код сметы. | Числовой. | Длинное целое. | |||
Договор | Код договора. | Числовой. | Длинное целое. | ||
ФИО. | Тестовый. | ||||
Дата заключения. | Дата/время. | ||||
Смета. | Код сметы. | Числовой. | Длинное целое. | ||
Код договора. | Числовой. | Длинное целое. | |||
Код заказа. | Числовой. | Длинное целое. | |||
Код поставщика. | Числовой. | Длинное целое. | |||
Код ответственного сотрудника. | Числовой. | Длинное целое. | |||
Наименование работ. | Текстовый. | ||||
Ед_измерения. | Текстовый. | ||||
Цена за ед_измерения. | Числовой. | Длинное целое. | |||
Сумма. | Числовой. | Длинное целое. | |||
Поставщики. | Код поставщика. | Числовой. | Длинное целое. | ||
Наименование организации. | Текстовый. | ||||
Адрес. | Текстовый. | ||||
Сотрудники. | Код сотрудника. | Числовой. | Длинное целое. | ||
ФИО. | Текстовый. | ||||
Дата рождения. | Дата/время. | ||||
Стаж. | Числовой. | Длинное целое. | |||
Адрес. | Текстовый. | ||||
Должность. | Текстовый. | ||||
Инструмент. | Код инстумента. | Числовой. | Длинное целое. | ||
Наименование. | Текстовый. | ||||
Количество. | Числовой. | Длинное целое. | |||
3. Логическое проектирование.
3.1 Модель «сущность-связь».
Управляющая компания рассылает дочерним организациям формы для заполнения, в которых имеются: показатели и единица их измерения, тип значения и тип периода.
Данная модель представлена на схеме 3.1 ниже.
Схема 3.1 Информационная модель.
3.2 Классификация связей.
Сущности «Показатели», «Тип значения», «Пользователи», «Тип периода» и «Формы» объединены через сущность «Значение». Сущность «Единица значения» связана с сущностью «показатели», а сущность «Организация» связана с сущностью «пользователи». Таким образом, сущность «Значение» связана с другими сущностями отношением «многие-к-одному».
4. Реляционная модель БД.
4.1 Функциональные зависимости между атрибутами..
Сущность «Значение» ссылается на сущности «Пользователи», «Формы», «Тип периода», «Тип значения» и «Показатели» (см. схему в разделе 3.1.). Таким образом, сущность «Значение» содержит пять внешних не идентифицирующих ключа.
4.2 Выбор ключей.
В качестве первичного ключа сущностей «Организация», «Тип значения» и «Тип периода» может быть выбран атрибут «Наименование». Но удобнее ввести искусственный атрибут (числовой код), который является более коротким.
Таким же образом в качестве первичного ключа сущности «Пользователи» удобнее ввести искусственный числовой атрибут вместо сочетания атрибутов «Фамилия», «Имя» и «Отчество».
Для сущностей «Показатели», «Значения», «Формы» и «Единицы измерения» также удобнее использовать искусственный числовой код вместо атрибута «Наименование».
4.3 Нормализация отношений.
Схема, приведенная в разделе 3.1., отвечает 1НФ т.к. данные представлены в виде двумерных таблиц с выделенными ключевыми атрибутами.
Схема также отвечает 2НФ, потому что каждый атрибут, не являющийся первичным, полностью зависит от этого первичного ключа.
Схема отвечает 3НФ, т.к. она отвечает всем требованиям 2НФ и ни один из не ключевых атрибутов не зависит от других не ключевых атрибутов.
5. Даталогическое проектирование.
5.1 Состав таблиц БД.
База данных содержит восемь таблиц: «Значения», «Показатели», «Формы», «Пользователи», «Организации», «Тип значения», «Тип периода» и «Единица измерения».
Рисунок 5.1 Структура таблицы «Значения».
Рисунок 5.2 Структура таблицы «Показатели».
Рисунок 5.3Структура таблицы «Формы».
Рисунок 5.4 Структура таблицы «Пользователи».
Рисунок 5.5 Структура таблицы «Организация».
Рисунок 5.6 Структура таблицы «тип значения».
Рисунок 5.7 Структура таблицы «Значения».
Рисунок 5.8 Структура таблицы «Единица измерения».
5.2 Средства поддержания целостности.
Связи таблиц базы данных представлены на схеме 5.1 данных ниже.
Схема 5.1 Связи таблиц базы данных Для всех связей, представленных на схеме, включено обеспечение целостности данных, и каскадное удаление связанных записей. Данные настройки позволяют избежать удаления записей из родительских таблиц, если в дочерней таблице («Значение») есть ссылки на эту запись.
6. Запросы к базе данных.
В базе данных реализовано десять запросов (см. рисунке 6.1).
Рисунок 6.1 Запросы.
Примерами простого запроса являются запросы «наименование организации».
Рисунок 6.2 Простой запрос в режиме конструктора.
Рисунок 6.3 Простой запрос в режиме SQL.
Примерами запросов с условием являются запросы «поиск пользователя на первую букву фамилии», «Поиск по дате создания», «Поиск пользователей по какой-либо организации».
Рисунок 6.4 Запрос c условием в режиме конструктора.
Рисунок 6.5 Запрос с условием в режиме SQL.
Примером запроса из связанных таблиц является запрос «оперативный план на 2 квартал».
Рисунок 6.6 Запрос из связанных таблиц в режиме конструктора.
Рисунок 6.7 Запрос из связанных таблиц в режиме SQL.
Примером запроса с использованием оператора соединения является запрос «сцепление ФИО».
Рисунок 6.8 Запрос с оператором сцепления в режиме конструктора.
Рисунок 6.9 Запрос с оператором сцепления в режиме SQL.
Остальные запросы формируются таким же образом.
7. Разработка механизмов защиты от несанкционированного доступа.
Работать с базой данных будут четыре группы: одни будут вводить информацию («Operator1»), а трое других — только просматривать («Operator2», «Operator3» и «Operator4»).
«Operator1» — Экономисты УК;
«Operator2» — Сотрудники ДООО;
«Operator3» — Руководство УК;
«Operator4» — Плановый отдел УК.
Разрешения будут присваиваться не отдельным пользователям, а группам пользователей.
Рисунок 7.1 Разрешение Operator 1 на доступ к базе данных.
Рисунок 7.2 Разрешение Operator 1 на доступ к таблицам.
Рисунок 7.3 Разрешение Operator 1 на доступ к запросам.
Рисунок 7.4 Разрешение Operator 1 на доступ к формам.
Рисунок 7.5 Разрешение Operator 2 на доступ к базе данных.
Рисунок 7.6 Разрешение Operator 2 на доступ к таблицам.
Рисунок 7.7 Разрешение Operator 2 на доступ к запросам.
Рисунок 7.8 Разрешение Operator 2 на доступ к отчетам.
Рисунок 7.9 Разрешение Operator 3 на доступ к базе данных.
Рисунок 7.10 Разрешение Operator 3 на доступ к таблицам.
Рисунок 7.11 Разрешение Operator 3 на доступ к запросам.
Рисунок 7.12 Разрешение Operator 3 на доступ к отчетам.
Рисунок 7.13 Разрешение Operator 4 на доступ к базе данных.
Рисунок 7.14 Разрешение Operator 4 на доступ к таблицам.
Рисунок 7.15 Разрешение Operator 1 на доступ к запросам.
Рисунок 7.16 Разрешение Operator 4 на доступ к формам.
Рисунок 7.17 Разрешение Operator 4 на доступ к отчетам.
8. Требования к техническому обеспечению.
Требования к вычислительной машине: ОС/Windows/XP Professional/ IE 5.1 и выше, процессор Х86 Famile 6 Model 15 Stepping 2 GenuineIntl ~1599МГц, версия BIOS American Megatrends Inc. 0602, 08.05.2007, 2 ГБ физической памяти, 1,96 ГБ виртуальной памяти. Установленный полный пакет Microsoft Office (Access 2003).
9. Инструкция по использованию БД.
9.1 Запуск программы.
Открыть проводник Windows, найти базу данных «Курсовой проект. mdb», установить не нее курсор мыши и щелкнуть левой кнопкой. На экране появится главная форма программы.
Рисунок 9.1 Главная кнопочная форма.
9.2 Экранные формы.
Рисунок 9.2 Экранная форма таблиц.
Рисунок 9.3 Экранная форма форм.
Рисунок 9.2 Экранная форма запросов.
Рисунок 9.2 Экранная форма отчетов.
Заключение.
В настоящее время предприятие не может обойтись без компьютера, который значительно облегчает его организацию, позволяет механизировать решение задач различного характера, которые ранее решались вручную. Тем более что сейчас прогрессирует развитие различных технологий, компьютерных, сетевых, и так далее. Все большее количество задач, стоящих перед человеком, решается при помощи ЭВМ. Это необходимо, т. к. круг объектов сферы человеческой деятельности постоянно растет, с другой стороны, вычислительные характеристики ЭВМ тоже постоянно совершенствуются. Создавая базу данных для Открытого Акционерного Общества «Башэнерго», было приобретены практические навыки обследования предметной области, концептуального, логического и физического проектирования базы данных, освоила средства поддержания целостности базы данных, запросов. А также изучены и освоены принципы, приемы разработки, формализации предметной области в виде функциональной (BPwin) модели, информационной модели ERwin для построения АСУ.
Также в данном проекте представлен вариант работы сборки и обработки технико-экономических показателей таким образом, чтобы можно было автоматизировать обработку показателей.
В процессе работы над курсовым проектом приобретены практические навыки создания базы данных в СУБД Microsoft Access с момента обследования предметной области и до настройки параметров запуска.
Библиографический список.
1. Горелов А., Ахаян Р., МакашариповС. Эффективная работа с СУБД — СПб.: Питер, 2000. — 704 с.
2. Виллет, Кроудер Microsoft Office 2000 Библия пользоователя.: Пер. с англ.-М.: Издательский дом «Вильямс», 2001. — 1026 с.
3. Марков А. С., Лисовский К. Ю. Базы данных.
Введение
в теорию и методологию: Учебник. — М.: Финансы и статистика, 2004. — 512 с.
4. Информатика: Учебник / Под ред. проф. Макаровой Н. В. — М.: Финансы и статистика, 2000. -768 с.
5. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных. Учебник для ВУЗов / Под ред. проф. А. Д. Хомоненко. — СПб.: КОРОНА-принт, 2000. — 416 с.
6. Черемных С. В. и др. Моделирование и анализ систем. IDEF-технологии: практикум / С. В. Черемных, И. О. Семенов, В. С. Ручкин. — М.: Финансы и статистика, 2005. — 192 с.
7. Карпова Т. С. Базы данных. Модели, разработка, реализация. — СПб.: Питер, 2002. 304 с.
8. Малыхина М. П. Базы данных: основы, проектирование, использование. — СПб.: БХВ — Петербург, 2004. — 512 с.
9. Практикум по информатике / А. А. Землянский, Г. А. Кретова, Ю. Р. Стратонович, Е. А. Яшкова; Под ред. А. А. Землянского. — М.: КолосС, 2003. — 384 с.