Разработка локальной реляционной базы данных "Отдел кадров"
Основные тенденции развития методов физической организации данных. Пространство памяти и размещение хранимых данных. Организация связей между хранимыми записями. Функциональные зависимости между атрибутами. Средства поддержания целостности базы данных.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | курсовая работа |
Язык | русский |
Дата добавления | 18.11.2015 |
Размер файла | 1,7 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
ФГАОУ ВПО «СЕВЕРО-КАВКАЗСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»
ИНСТИТУТ информационных технологий и телекоммуникаций
КАФЕДРА информационных систем и технологий
КУРСОВОЙ ПРОЕКТ
по дисциплине
«Управление данными»
на тему:
«Разработка локальной реляционной базы данных «Отдел кадров»»
Выполнила:
Журбина Юлия Олеговна
студентка 3 курса
группы ИСТ-б-о-122
направления 230400.62 информационные системы и технологии
очной формы обучения
Ставрополь, 2014 г.
Содержание
Введение
1. Тенденции развития методов физической организации данных.
1.1 Механизмы среды хранения и архитектура СУБД
1.2 Пространство памяти и размещение хранимых данных.
1.3 Структура хранимых данных
1.4 Виды адресации хранимых записей.
1.5 Организация связей между хранимыми записями.
Вывод.
2. Обследование предметной области.
3. Концептуальное проектирование
3.1 Перечень сущностей.
3.2 Перечень атрибутов.
4. Инфологическое проектирование.
4.1 Модель «сущность-связь»
4.2 Классификация связей.
5. Реляционная модель БД.
5.1 Функциональные зависимости между атрибутами
5.2 Выбор ключей.
5.3 Нормализация отношений.
6. Даталогическая модель БД.
6.1 Состав таблиц БД
6.2 Средства поддержания целостности.
7. Запросы
8. Разработка механизмов защиты данных от несанкционированного доступа.
9. Требования к техническому обеспечению.
10. Инструкция по пользованию БД.
10.1 Вызов программы.
10.2 Экранные формы.
10.3 Описание отчетов.
11. Заключение
12. Список литературы.
Введение
База данных - набор структурированной информации, созданной на машинном носителе средствами систем управления базами данных(СУБД), в которых хранится большие объемы информации и программных модулей, осуществляющих управление данными, их выборку, сортировку и другие подобные действия. Любая таблица с данными состоит из набора однотипных записей, расположенных друг за другом. Они представляют собой строки таблицы, которые можно добавлять, удалять или изменять. Однотипные поля разных записей образуют столбец таблицы.
Создаются БД различными способами: путем ручного кодирования, с помощью визуальных средств мастеров и генераторов, а так же программированием с помощью специальных средств (Delphi, clipper).
Язык SQL-формальный непроцедурный язык программирования, применяемый для создания, модификации и управления данными в произвольной реляционной базе данных, управляемой соответствующей системой управления базами данных (СУБД). SQL основывается на исчислении кортежей.
Изначально SQL был основным способом работы пользователя с базой данных и позволял выполнять следующий набор операций:
· создание в базе данных новой таблицы;
· добавление в таблицу новых записей;
· изменение записей;
· удаление записей;
· выборка записей из одной или нескольких таблиц (в соответствии с заданным условием);
· изменение структур таблиц.
Со временем SQL усложнился -- обогатился новыми конструкциями, обеспечил возможность описания и управления новыми хранимыми объектами (например, индексы, представления, триггеры и хранимые процедуры) -- и стал приобретать черты, свойственные языкам программирования.
При всех своих изменениях SQL остаётся единственным механизмом связи между прикладным программным обеспечением и базой данных. В то же время современные СУБД, а также информационные системы, использующие СУБД, предоставляют пользователю развитые средства визуального построения запросов.
Каждое предложение SQL -- это либо запрос данных из базы, либо обращение к базе данных, которое приводит к изменению данных в базе. В соответствии с тем, какие изменения происходят в базе данных, различают следующие типы запросов:
· запросы на создание или изменение в базе данных новых или существующих объектов (при этом в запросе описывается тип и структура создаваемого или изменяемого объекта);
· запросы на получение данных;
· запросы на добавление новых данных (записей);
· запросы на удаление данных;
· обращения к СУБД.
Основным объектом хранения реляционной базы данных является таблица, поэтому все SQL-запросы -- это операции над таблицами. В соответствии с этим, запросы делятся на:
· запросы, оперирующие самими таблицами (создание и изменение таблиц);
· запросы, оперирующие с отдельными записями (или строками таблиц) или наборами записей.
Каждая таблица описывается в виде перечисления своих полей (столбцов таблицы) с указанием
· типа хранимых в каждом поле значений;
· связей между таблицами (задание первичных и вторичных ключей);
· информации, необходимой для построения индексов.
Запросы первого типа в свою очередь делятся на запросы, предназначенные для создания в базе данных новых таблиц, и на запросы, предназначенные для изменения уже существующих таблиц. Запросы второго типа оперируют со строками, и их можно разделить на запросы следующего вида:
· вставка новой строки;
· изменение значений полей строки или набора строк;
· удаление строки или набора строк.
Самый главный вид запроса - это запрос, возвращающий (пользователю) некоторый набор строк, с которым можно осуществить одну из трёх операций:
· просмотреть полученный набор;
· изменить все записи набора;
· удалить все записи набора.
Таким образом, использование SQL сводится, по сути, к формированию всевозможных выборок строк и совершению операций над всеми записями, входящими в набор.
В данной работе была создана локальная реляционная база данных для некоторого отдела кадров с разным контингентом сотрудников. Использовать ее могут все сотрудники каждого подразделения.
1. Тенденции развития методов физической организации данных
1.1 Механизмы среды хранения и архитектура СУБД
Механизмы среды хранения БД служат для управления двумя группами ресурсов - ресурсами хранимых данных и ресурсами пространства памяти. В задачу этого механизма входит отображение структуры хранимых данных в пространство памяти, позволяющее эффективно использовать память и определить место размещения данных при запоминании и при поиске данных.
В большинстве случаев в качестве единицы хранения принимается хранимая запись.
Механизмы среды хранения выполняют следующие операции:
1. При запоминании нового объекта:
· определение места размещения нового объекта "физической" БД в пространстве памяти;
· выделение необходимого ресурса памяти;
· запоминание этого объекта;
· формирование связей с другими объектами.
2. При поиске объекта:
· поиск места размещения объекта в пространстве памяти по заданным атрибутам или "адресу";
· выборка объектов для обработки.
3. При удалении объекта:
· удаление объекта с освобождением памяти (физическое удаление) или без освобождения (логическое удаление);
· разрушение связей с другими объектами.
В реляционных СУБД формирование связей осуществляется на логическом уровне (т.е. по значениям атрибутов), а в иерархических и сетевых СУБД - на физическом уровне (по адресам записей).
Все операции выполняются по запросам механизмов концептуального уровня СУБД. На этом уровне никаких операций непосредственного обновления пользовательских данных или преобразований представления хранимых данных не происходит, это задача более высоких архитектурных уровней. Управление памятью выполняется операционной системой по запросам СУБД или непосредственно самой СУБД.
Несмотря на декларируемую независимость архитектурных уровней, для достижения более высокой производительности на уровне организации среды хранения часто приходится учитывать специфику концептуальной модели. Аналогично, организация файловой системы не может не оказывать влияния на среду хранения.
1.2 Пространство памяти и размещение хранимых данных
Ресурсам пространства памяти соответствуют объекты внешней памяти ЭВМ, управляемые средствами операционной системы или СУБД.
Для обеспечения естественной структуризации хранимых данных, более эффективного управления ресурсами и/или для технологического удобства всё пространство памяти БД обычно разделяется на части. Области памяти используются для размещения хранимых записей одного или нескольких типов и разбиваются на пронумерованные страницы фиксированного размера. В большинстве систем обработку данных на уровне страниц ведёт операционная система (ОС), а обработку записей внутри страницы обеспечивает только СУБД.
Страницы представляются в среде ОС блоками внешней памяти, кластерами или секторами, доступ к которым осуществляется за одно обращение. В системах, которые позволяют управлять размером страницы, приходится искать компромисс между производительностью системы и требуемым объёмом оперативной памяти.
Страница имеет заголовок, содержащий служебную информацию, вслед за которым располагаются собственно данные. На странице размещается, как правило, несколько записей, и есть свободный участок для размещения новых записей. Если запись не помещается на одной странице, она разбивается на фрагменты, которые хранятся на разных страницах и имеют ссылки друг на друга.
Существуют различные механизмы, позволяющие решать проблемы, которые возникают при модификации данных в БД. Рассмотрим их.
Удаление записей может быть логическим или физическим. В первом случае запись помечается как удаленная, но фактически она остаётся на прежнем месте. Фактическое удаление этой записи будет произведено либо при реорганизации БД, либо специальной сервисной программой, инициируемой администратором БД.
При физическом удалении ранее занятый участок освобождается и становится доступным для повторного использования. Система автоматически управляет свободным пространством памяти на страницах. Как правило, это обеспечивается либо ведением списков свободных участков, либо динамической реорганизацией страниц.
При динамической реорганизации страниц записи БД плотно размещаются вслед за заголовком страницы, а после них расположен свободный участок (рис. 1.1,а). Смещение начала свободного участка хранится в заголовке страницы. При удалении записи оставшиеся записи переписываются подряд в начало страницы, и изменяется смещение начала свободного участка.
Рис. 1.1. - Управление свободным пространством памяти на страницах.
Если система ведёт список свободных участков, то возможны разные варианты. Ссылка на первый свободный участок на странице может храниться в заголовке страницы, и каждый свободный участок хранит ссылку на следующий (или признак конца списка) (рис. 1.1,б). Каждый освобождаемый участок включается в список свободных участков на странице.
Другой способ заключается в поддержке списков участков в виде отдельных структур (рис. 1.1,в). Список ведется как стек, очередь или упорядоченный список. В последнем случае упорядочение осуществляется по размеру свободного участка, что позволяет при размещении новой записи выбирать для неё наиболее подходящий по размеру участок.
Для учёта свободных участков в СУБД могут поддерживаться инвентарные страницы. Они создаются для области (или группы страниц) и содержат информацию о свободных участках в этой области. Это существенно ускоряет поиск свободного пространства для размещения новых записей.
При запоминании новой записи система через инвентарные страницы ищет свободный участок, достаточный для размещения этой записи. (Обычно выбирается первый подходящий, размер которого не меньше требуемого.) Если выбранный участок больше, чем запись, то остаток оформляется в виде свободного участка. (При динамической реорганизации страниц запись просто записывается вслед за последней на данной странице.) После этого система корректирует содержимое инвентарных страниц (если они есть).
При изменении записи, имеющей фиксированный формат, она просто перезаписывается на прежнее место. Если же запись имеет плавающий формат, возможны ситуации, когда запись не помещается на прежнее место. Тогда процедуры корректировки приводят либо к реорганизации страницы, либо к перемещению записи на другой участок памяти, что, в свою очередь, приведёт к обновлению нескольких страниц.
Использование списков свободных участков ведёт к фрагментации пространства памяти. Для того чтобы уменьшить фрагментацию, в подобных системах предусмотрены процедуры, которые периодически проводят слияние смежных свободных участков в один.
Структура и представление хранимых данных, их размещение в пространстве памяти и используемые методы доступа определяются схемой хранения. Схема хранения оперирует в терминах типов объектов.
1.3 Структура хранимых данных
база данные целостность память
Единицей хранения данных в БД является хранимая запись. Она может представлять как полную запись концептуального уровня, так и некоторую её часть. Если запись разбивается на части, то её фрагменты представляются экземплярами хранимых записей каких-либо типов. Все части записи связываются указателями (ссылками) или размещаются по специальному закону так, чтобы механизмы междууровневого отображения могли опознать все компоненты и осуществить сборку полной записи концептуальной БД по запросу механизмов концептуального уровня.
Хранимые записи одного типа состоят из фиксированной совокупности полей и могут иметь формат фиксированной или переменной длины.
Записи переменной длины возникают, если допускается использование повторяющихся групп полей (агрегатов) с переменным числом повторов или полей переменной длины. Работа с хранимыми записями переменной длины существенно усложняет управление пространством памяти, но может быть продиктована желанием уменьшить объём требуемой памяти или характером модели данных концептуального уровня. В последнем случае для повышения производительности системы записи могут разбиваться на фрагменты фиксированной длины, возможно, различных типов.
Хранимая запись состоит из двух частей:
1. Служебная часть. Используется для идентификации записи, задания её типа, хранения признака логического удаления, для кодирования значений элементов записи, для установления структурных ассоциаций между записями. Никакие пользовательские программы не имеют доступа к служебной части хранимой записи.
2. Информационная часть. Содержит значения элементов данных.
Элементы хранимой записи могут иметь фиксированную или переменную длину. При этом обычно элементы фиксированной длины хранятся в начале записи и размещаются в памяти с заранее определённых позиций, а за ними размещаются элементы переменной длины. Хранение элементов переменной длины осуществляется одним из двух способов: размещение через разделитель или хранение размера элемента данных. Наличие полей переменной длины позволяет не хранить незначащие символы и тем существенно снижает затраты памяти на хранение данных; но при этом увеличивается время на извлечение элементов записи.
Каждой записи БД система присваивает внутренний идентификатор, называемый (по стандарту CODASYL) ключом базы данных (КБД). Значение КБД формируется системой при размещении записи и содержит информацию, позволяющую однозначно определить место размещения записи (её адрес). В качестве КБД может выступать, например, последовательный номер записи в файле или совокупность адреса страницы и смещения от начала страницы.
Конкретные составляющие КБД зависят от операционной системы и от СУБД, точнее, от вида используемой адресации и от структуризации памяти, принятой в данной СУБД.
1.4 Виды адресации хранимых записей
Рассмотрим два вида адресации: прямую и косвенную.
Прямая адресация предусматривает указание непосредственного местоположения записи в пространстве памяти. Простейший вариант адресации используется в том случае, если в памяти хранится один вид записи фиксированной длины. Тогда в качестве адреса записи может использоваться её порядковый номер. (Прямая адресация используется, например, в системах ADABAS и dBaseIII PLUS).
Прямая адресация не позволяет перемещать записи в памяти без изменения ключа базы данных. Такие изменения привели бы к необходимости коррекции различных указателей на записи в среде хранения, что было бы чрезвычайно трудоемкой процедурой. В связи с отсутствием возможности перемещения при этом возникает явление фрагментации, т.е. появление разрозненных незаполненных участков памяти.
Указанные недостатки можно преодолеть, используя косвенную адресацию. Существует множество способов косвенной адресации. Один из них состоит в том, что часть адресного пространства страницы выделяется под индекс страницы (рис. 1.2). Число статей (слотов) в нем одинаково для всех страниц. Ключом БД по-прежнему служит номер этой записи в области. С помощью простых арифметических действий можно получить по номеру записи номер нужной страницы и номер требуемого слота в индексе этой страницы. Найденный слот укажет местоположение записи на этой странице, где N, n - это соответственно номер страницы памяти и номер слота на этой странице, в котором хранится адрес записи (смещение от начала страницы).
Рис.1.2. Косвенная адресация с использованием индексов.
При перемещении записи она остаётся на той же странице, и слот по-прежнему указывает на неё (меняется его содержимое, но не сам слот). Если запись не вмещается на страницу, она помещается на специально отведённые в данной области страницы переполнения, и соответствующий слот продолжает указывать место её размещения.
Этот подход позволяет перемещать записи на странице, исключать фрагментацию, возвращать освободившееся пространство для повторного использования. При этом приложения БД остаются нечувствительными к таким операциям. Таким образом, косвенная адресация входит в группу методов, обеспечивающих физическую независимость данных.
Также с адресацией связана другая функция среды хранения - поддержка связей между хранимыми записями.
1.5 Организация связей между хранимыми записями
Для сетевой и иерархической моделей данных эти связи поддерживаются на физическом уровне. Способы представления связей определяются схемой хранения и чаще всего основаны на использовании указателей или на размещении данных в смежных областях памяти.
В сетевых и иерархических БД ассоциации между данными поддерживаются групповыми отношениями. Наиболее распространённый способ поддержания групповых отношений - создание цепного списка. Для этого запись-владелец в служебной части содержит адресную ссылку (ключ базы данных) на первую подчиненную запись, а каждая подчиненная запись содержит ссылку на следующую (рис. 1.3,б). Последняя подчиненная запись содержит либо признак конца списка (разомкнутый список), либо ссылку на владельца (замкнутый список).
Ссылки могут быть однонаправленными (только на следующую запись) или двунаправленными (на следующую и на предыдущую записи). В последнем случае запись владелец кроме ссылки на начало списка подчинённых записей также содержит ссылку на последнюю подчиненную запись (рис.1.3,в).
Двунаправленный список удобен при удалении записи. Для корректности удаления подчиненной записи нужно, чтобы предыдущая запись содержала ссылку на последующую запись (по отношению к удаленной). Например, при удалении записи В2 (рис. 1.3,в) запись В1 должна ссылаться на запись В3. Имея ссылку на предыдущую запись, можно сразу выполнить шаг назад и изменить значение ссылки у записи В1, не проходя заново по всему списку.
Рис. 1.3. Реализация групповых отношений (а):
б) замкнутый цепной список; в) двунаправленный цепной список.
Кроме ссылок внутри списка подчинённые записи могут содержать ссылку на запись-владельца. В сетевой модели данных обработку можно начать с любой записи, и наличие ссылки на владельца обеспечивает быстрое передвижение вверх по групповым отношениям.
Дополнительные ссылки увеличивают эффективность выполнения отдельных операций, но требуют соответствующих затрат внешней памяти и время на установление и разрыв связей.
Вывод.
Эффективность использования любых методов доступа зависит от распределения данных в запрашиваемых таблицах, от стратегии работы оптимизатора СУБД и от возможностей диалекта SQL. Поэтому приведенные рекомендации носят достаточно общий характер -- все определяется конкретной ситуацией. Решения, принимаемые на этапах физического проектирования и настройки, чаще всего представляют собой компромисс между достижением требуемых характеристик, которые часто противоречат друг другу. За выигрыш в скорости обработки запросов, которую дает индекс, приходится платить дополнительными ресурсами памяти на его размещение и процессорным временем для его поддержки в актуальном состоянии. К сожалению, трудно привести конкретные оценки: многое зависит от конфигурации сервера, настройки ОС и СУБД и т.п.
Рассмотренный перечень методов доступа не является полным. Описаны лишь распространенные технологии, которые можно назвать традиционными. Например, за кадром остались возможности современных СУБД, связанные с реализацией расширяемой системы типов данных. Сюда относят технологии расширителей (Extender) IBM, DataBlade (Informix) и картриджей (Oracle). Тем не менее, перечисленный арсенал средств достаточно богат сам по себе. Адекватное представление об этих средствах позволяет сделать проектируемые базы данных и их приложения менее зависимыми от конкретной СУБД.
2. Обследование предметной области
Разработка справочника отделов, сотрудников, должностей и отпусков началась с изучения возможных структур компаний и составления на бумаге моделей, в которых устанавливались обязательные характеристики с учётом структуры.
Каждое подразделение является самоуправляемым центром прибыли, полностью ответственным за собственные издержки и рентабельность. В штатном расписании каждого подразделения присутствуют должности директора, заместителя директора, а также специалистов, непосредственно оказывающих услуги клиентам. В некоторых подразделениях имеются внутренние должности. Сотрудники занимаются различной деятельностью в интересах всей компании.
Для справочников были выделены следующие объекты информации:
Таблица 1- «Должности»:
Код_должности |
Каждой должности присваивается свой индивидуальный номер, по которому можно легко найти необходимое наименование. |
|
Название_должности |
Наименование. |
|
Оклад |
В рублях за 4 рабочие недели. |
Таблица 2- «Задание»:
Код_задания |
Уникальный номер должности. Присваивается с учётом отдела и должности. |
|
Название_отдела |
На предприятии 7 отделом. Наименования присваиваются соответственно. |
|
Код_отдела |
Уникальный код каждого отдела. |
|
Вложение |
Текстовый файл, в котором содержится описание задания и должностных обязанностей каждого сотрудника. |
Таблица 3- «Отдел»
Код_отдела |
Уникальный код каждого отдела. |
|
Название_отдела |
На предприятии 7 отделом. Наименования присваиваются соответственно. |
Таблица 4-«Отпуск»
Номер |
Число, присваивающееся каждому сотруднику и обновляющееся каждые 6 месяцев. |
|
Номер_сотрудника |
Индивидуальный номер сотрудника. |
|
ФИО |
В соответствии с документом, удостоверяющим личность. |
|
Начало_отпуска |
Дата начала отпуска. |
|
Конец_отпуска |
Дата конца отпуска. |
|
Оплачиваемый |
За счет предприятия/за личный счет. |
Таблица 5 - «Сотрудники»
Номер_сотрудника |
Индивидуальный номер сотрудника. |
|
ФИО |
В соответствии с документом, удостоверяющим личность. |
|
Стаж_работы |
От 3х лет. |
|
Адрес |
В соответствии с документом, удостоверяющим личность. |
|
Телефон |
Мобильный/городской. |
|
Дата_рождения |
В соответствии с документом, удостоверяющим личность. |
|
Код_задания |
Уникальный номер должности. Присваивается с учётом отдела и должности. |
|
Код_должности |
Каждой должности присваивается свой индивидуальный номер, по которому можно легко найти необходимое наименование. |
3. Концептуальное проектирование
В этом разделе производится выбор информационных объектов.
Выходная информация на печать:
- ведомость сотрудников заданного отдела: ФИО сотрудника, должность, адрес, телефон, стаж, оклад;
- сводная ведомость по отделам: название отдела, начальник отдела, должность, количество сотрудников.
Выходная информация на экран:
- для заданного номера: ФИО, год рождения, должность, задание, отдел;
- данные всех сотрудников седьмого отдела;
- данные всех сотрудников, имеющих трудовой стаж более 15 лет.
3.1 Перечень сущностей
· Должность
· Отдел
· Отпуск
· Задание
· Сотрудники
3.2 Перечень атрибутов
Должность:
· Код_должности
· Название должности
· Оклад
Отдел:
· Код отдела
· Название отдела
Отпуск:
· Номер
· Номер сотрудника
· Фамилия
· Имя
· Отчество
· Начало отпуска
· Конец отпуска
· Оплачиваемый
Задание:
· Код задания
· Название отдела
· Код отдела
· Вложения
Сотрудники:
· Номер сотрудника
· Фамилия
· Имя
· Отчество
· Дата рождения
· Стаж работы в организации
· Телефон
· Код задания
· Код должности
4. Инфологическое проектирование
4.1 Модель «сущность-связь»
В этом разделе приводится ER-диаграмма (диаграмма «сущность -связь») разработанной модели. В ходе работы созданные таблицы были связаны по ключам, как показано на рисунке 4.1. Номер сотрудника ( отпуск-сотрудники), код должности (должность-сотрудники), код задания (здание-сотрудники), код отдела (отдел-задание).
Рис. 4.1- Связь таблиц
4.2 Классификация связей
Существует три типа связей между таблицами. Тип создаваемой связи зависит от того, как определены связанные столбцы.
· Связи «один ко многим»
· Связи «многие ко многим»
· Связи «один к одному»
Связь «один ко многим» самая распространенная. В этом типе связей у строки таблицы А может быть несколько совпадающих строк таблицы Б, но каждой строке таблицы Б может соответствовать только одна строка из А. Например, между таблицами publishers и titles установлена связь «один ко многим»: каждый издатель публикует много книг, но каждая книга публикуется только у одного издателя.
Используется связь «один ко многим», если только у одного из связанных столбцов есть ограничение первичного ключа или уникальности.
Столбец, являющийся первичным ключом в связи «один ко многим», отмечается символом ключа. Столбец, являющийся внешним ключом в связи «один ко многим», отмечается символом бесконечности.
В связи «многие ко многим» строке таблицы А может сопоставляться несколько строк таблицы Б, и наоборот. Такие связи создаются определением третьей таблицы, которая называется таблицей соединения, чей первичный ключ состоит из внешних ключей А и Б. Например, между таблицами authors и titles связь «многие ко многим» определена через связи «один ко многим» каждой из этих таблиц с таблицей titleauthors. Первичный ключ таблицы titleauthors представляет собой сочетание столбца au_id (первичный ключ таблицы authors) и столбца title_id (первичный ключ таблицы titles).
В связи «многие к одному» строке таблицы А может сопоставляться только одна строка таблицы Б, и наоборот. Связь «один к одному» создается, если для обоих связанных ключей определены ограничения первичного ключа или уникальности.
Последний тип связи обычно не используется, так как большую часть связанных таким образом данных можно хранить в одной таблице. Связь «один к одному» можно использовать для:
· Разделения таблицы со многими столбцами.
· Изоляции части таблицы из соображений безопасности.
· Хранения кратковременных данных, которые можно легко удалить вместе со всей таблицей.
· Хранения данных, которые относятся только к части основной таблицы.
Столбец, являющийся первичным ключом в связи «один к одному», отмечается символом ключа. Столбец, являющийся внешним ключом, также отмечается символом ключа
В данной работе реализована связь «многие ко многим».
5. Реляционная модель БД
5.1 Функциональные зависимости между атрибутами
Говорят, что атрибут В функционально зависим от атрибута А реляционной таблицы, если значение А однозначно определяет значение В. Любые две строки, имеющие одинаковое значение атрибута А, будут также иметь одинаковые значения атрибута В. Также говорят, что А функционально определяет В. Эта зависимость выражается как
А -> В
Если В функционально зависит от А, то состояние таблицы определяет функцию В от А. Это не обязательно функция в том смысле, что существует некоторая формула или выражение, позволяющие вычислить значение В на основании значения А. Вместо этого, функциональная зависимость определяется строками таблицы. Чтобы найти значение атрибута В для некоторого значения а атрибута А, необходимо выполнить следующие действия.
1. Найти строку таблицы, в которой значение атрибута А равно а.
2. Возвратить значение атрибута В этой строки.
Если состояние таблицы изменится, то функция, определяющая значение В на основании А, также может измениться.
5.2 Выбор ключей
В каждой таблице базы данных должно существовать поле или набор полей, которые однозначно идентифицируют каждую запись, хранящуюся в таблице. Такие поля называют первичными ключами. У каждой, созданной в ходе работы, таблицы имеется первичный ключ, который, относительно других таблиц является внешним ключом. Для таблицы «должности» первичным ключом является поле «код должности», для таблицы «отдел» - «код отдела», «задание» - «код задания», «отпуск» - «номер» и для таблицы «сотрудники» - «номер сотрудника».
Для первичных ключей введен запрет неопределенных значений.
5.3 Нормализация отношений
Процесс преобразования отношений базы данных к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма базы данных.
Созданная в процессе курсовой работы база данных подходит под первую нормальную форму, т.е. атрибуты отношений атомарны.
Так же, отсутствуют транзитивные функциональные зависимости не ключевых атрибутов от ключевых(3нф), не содержатся нетривиальные многозначных зависимостей(4нф) и каждая нетривиальная зависимость соединения в ней определяется потенциальным ключом (ключами) этого отношения(5нф).
6. Даталогическая модель БД
6.1 Состав таблиц БД
В этом разделе приводится состав таблиц БД. Для каждого поля таблицы был указан размер поля (в количестве символов), тип данных. Описание состава таблиц приведено в следующих таблицах:
Таблица 6 - состав таблицы «должность»
Наименование атрибутов |
Тип полей |
Размер полей |
Допустимостьнеопределенных значений |
|
Код должности |
Числовой |
NOT NULL |
||
Название должности |
Текстовый |
70 |
||
Оклад |
Денежный |
NOT NULL |
Таблица 7 - состав таблицы «Отдел»
Код отдела |
Числовой |
NOT NULL |
||
Название отдела |
Текстовый |
16 |
Таблица 8 - состав таблицы «задание»
Код задания |
Числовой |
NOT NULL |
||
Название отдела |
Текстовый |
100 |
||
Код отдела |
Числовой |
NOT NULL |
||
Вложения |
Вложения |
- |
- |
Таблица 9 - состав таблицы «Отпуск»
Номер |
Числовой |
NOT NULL |
||
Номер сотрудника |
Числовой |
NOT NULL |
||
Фамилия |
Текстовый |
15 |
||
Имя |
Текстовый |
15 |
||
Начало отпуска |
Дата/время |
- |
- |
|
Конец отпуска |
Дата/время |
- |
- |
|
Оплачиваемый |
Логический |
- |
- |
Таблица 10 - состав таблицы «Сотрудники»
Фамилия |
Текстовый |
15 |
||
Имя |
Текстовый |
15 |
||
Адрес |
Текстовый |
70 |
||
Дата рождения |
Дата/время |
- |
||
Стаж работы в организации |
Числовой |
- |
NOT NULL |
|
Телефон |
Числовой |
- |
NOT NULL |
|
Код задания |
Числовой |
- |
NOT NULL |
|
Код должности |
Числовой |
- |
NOT NULL |
6.2 Средства поддержания целостности
Ссылочная целостность - это ограничение базы данных, гарантирующее, что ссылки между данными являются действительно правомерными и неповрежденными.
В MS-Access команды SQL для определения ссылочной целостности поддерживаются только частично, но средство графического связывания является более сильным. С помощью графического интерфейса можно определить ссылочную целостность.
При создании инфологической модели, можно было увидеть, что целостность по ссылкам присутствует. Значит, база данных работает корректно. Так же установлен каскадный метод обновления данных для каждой связи между таблицами.
7. Запросы
Термины SQL
Каждое предложение SQL состоит из терминов, которые можно сравнить с частями речи. В приведенной ниже таблице указаны типы терминов SQL.
Таблица 11- термины SQL:
Термин SQL |
Определение |
|
идентификатор |
Имя, используемое для идентификации объекта базы данных, например имя поля. |
|
оператор |
Ключевое слово, которое представляет действие или изменяет его. |
|
константа |
Значение, которое не изменяется, например число или NULL. |
|
выражение |
Сочетание идентификаторов, операторов, констант и функций, предназначенное для вычисления одного значения. |
Каждое предложение SQL -- это либо запрос данных из базы, либо обращение к базе данных, которое приводит к изменению данных в базе. В соответствии с тем, какие изменения происходят в базе данных, различают следующие типы запросов:
· запросы на создание или изменение в базе данных новых или существующих объектов (при этом в запросе описывается тип и структура создаваемого или изменяемого объекта);
· запросы на получение данных;
· запросы на добавление новых данных (записей);
· запросы на удаление данных;
· обращения к СУБД.
Основным объектом хранения реляционной базы данных является таблица, поэтому все SQL-запросы -- это операции над таблицами. В соответствии с этим, запросы делятся на:
· запросы, оперирующие самими таблицами (создание и изменение таблиц);
· запросы, оперирующие с отдельными записями (или строками таблиц) или наборами записей.
Каждая таблица описывается в виде перечисления своих полей (столбцов таблицы) с указанием
· типа хранимых в каждом поле значений;
· связей между таблицами (задание первичных и вторичных ключей);
· информации, необходимой для построения индексов.
Запросы первого типа в свою очередь делятся на запросы, предназначенные для создания в базе данных новых таблиц, и на запросы, предназначенные для изменения уже существующих таблиц. Запросы второго типа оперируют со строками, и их можно разделить на запросы следующего вида:
· вставка новой строки;
· изменение значений полей строки или набора строк;
· удаление строки или набора строк.
Самый главный вид запроса -- это запрос, возвращающий (пользователю) некоторый набор строк, с которым можно осуществить одну из трёх операций:
· просмотреть полученный набор;
· изменить все записи набора;
· удалить все записи набора.
Таким образом использование SQL сводится, по сути, к формированию всевозможных выборок строк и совершению операций над всеми записями, входящими в набор.
В ходе работы было создано 10 запросов. Так же, составлен коррелированный запрос, в результате которого мы увидим фамилии сотрудников, работающих на должности «специалист по кадрам» в шестом отделе.
Первый запрос показывает нам фамилии сотрудников, на должности «директор» с оплачиваемым отпуском. На языке SQL это выглядит следующим образом:
SELECT Отпуск.номер, Отпуск.[Номер сотрудника], Отпуск.Фамилия, Отпуск.Имя, Отпуск.оплачиваемый, Должность.[Название должности]
FROM (Должность INNER JOIN Сотрудники ON Должность.[Код должности] = Сотрудники.[Код должности]) INNER JOIN Отпуск ON Сотрудники.[Номер сотрудника] = Отпуск.[Номер сотрудника]
WHERE (((Должность.[Название должности])="директор по персоналу"));
Результат выполнения запроса:
Рис.7.1- Результат выполнения запроса.
Второй запрос помогает нам увидеть соответствие Фамилий и Должностей.
SELECT Сотрудники.[Номер сотрудника], Сотрудники.Фамилия, Сотрудники.Имя, Сотрудники.Отчество, Сотрудники.[Дата рождения], Сотрудники.[Стаж работы в организации], Должность.[Код должности], Должность.[Название должности], Должность.Оклад
FROM Должность INNER JOIN Сотрудники ON Должность.[Код должности] = Сотрудники.[Код должности];
Рис.7.2 - Выполнение запроса.
Следующий запрос показывает задания для сотрудников четвертого отдела:
SELECT Сотрудники.[Номер сотрудника], Сотрудники.Фамилия, Сотрудники.[Код задания], Сотрудники.[Код должности], Отдел.[Название отдела], задание.[Код отдела], задание.текст
FROM (Отдел INNER JOIN задание ON Отдел.[Код отдела] = задание.[Код отдела]) INNER JOIN Сотрудники ON задание.[Код задания] = Сотрудники.[Код задания]
WHERE (((Отдел.[Название отдела])="Четвертый"));
Рис.7.3 - Выполнение запроса.
Запрос, который показывает нам фамилии, которые начинаются с буквы «с» выглядит так:
SELECT Сотрудники.[Номер сотрудника], Сотрудники.Фамилия, Сотрудники.Имя, Сотрудники.Отчество, Сотрудники.[Код должности], Должность.[Название должности]
FROM Должность INNER JOIN Сотрудники ON Должность.[Код должности] = Сотрудники.[Код должности]
WHERE (((Сотрудники.Фамилия) Like 'С*'));
Рис.7.4 - Выполнение запроса.
Еще один запрос позволяет увидеть фамилии сотрудников из седьмого отдела, у которых оплачиваемый отпуск в промежутке с 29 мая 2015г по 25 августа 2015г.
SELECT Сотрудники.[Номер сотрудника], Сотрудники.Фамилия, Сотрудники.Имя, Сотрудники.[Стаж работы в организации], Сотрудники.Адрес, Сотрудники.Телефон, Отдел.[Название отдела] AS [Отдел_Название отдела], Должность.[Код должности] AS [Должность_Код должности], Должность.[Название должности], Отпуск.[Начало отпуска], Отпуск.[Конец отпуска], Отпуск.оплачиваемый
FROM ((Отдел INNER JOIN задание ON Отдел.[Код отдела] = задание.[Код отдела]) INNER JOIN (Должность INNER JOIN Сотрудники ON Должность.[Код должности] = Сотрудники.[Код должности]) ON задание.[Код задания] = Сотрудники.[Код задания]) INNER JOIN Отпуск ON Сотрудники.[Номер сотрудника] = Отпуск.[Номер сотрудника]
WHERE (((Отдел.[Название отдела])="Седьмой") AND ((Отпуск.[Начало отпуска]) Between #5/29/2015# And #8/25/2015#));
Рис.7.5а- Выполнение запроса;
Рис.7.5б - Выполнение запроса.
Чтобы найти только специалистов по кадрам, создала следующий запрос:
SELECT Сотрудники.[Номер сотрудника], Сотрудники.Фамилия, Сотрудники.Имя, Сотрудники.Отчество, Должность.[Код должности], Должность.[Название должности]
FROM Должность INNER JOIN Сотрудники ON Должность.[Код должности] = Сотрудники.[Код должности]
WHERE (((Должность.[Название должности])="специалист по кадрам"));
Рис.7.6 -Выполнение запроса.
Выполнение данного запроса позволяет найти сотрудников из второго и седьмого отделов со стажем работы в организации больше 20 лет:
SELECT Сотрудники.[Номер сотрудника], Сотрудники.Фамилия, Сотрудники.Имя, Сотрудники.[Стаж работы в организации], Сотрудники.Телефон, задание.[Название отдела]
FROM задание INNER JOIN Сотрудники ON задание.[Код задания] = Сотрудники.[Код задания]
WHERE (((Сотрудники.[Стаж работы в организации])>20) AND ((задание.[Название отдела])="Второй")) OR (((Сотрудники.[Стаж работы в организации])>20) AND ((задание.[Название отдела])="Седьмой"));
Рис.7.7- Выполнение запроса.
Если необходимо найти сотрудников, у которых оклад 20000р, 35000р или 40000р, имеется запрос такого типа:
SELECT Сотрудники.[Номер сотрудника], Сотрудники.Фамилия, Сотрудники.[Стаж работы в организации], Должность.Оклад
FROM Должность INNER JOIN Сотрудники ON Должность.[Код должности] = Сотрудники.[Код должности]
WHERE (((Должность.Оклад)=20000 Or (Должность.Оклад)=40000 Or (Должность.Оклад)=35000));
Рис.7.8 - Выполнение запроса.
8. Разработка механизмов защиты данных от несанкционированного доступа
Access 2010 обеспечивает защиту на уровне пользователей только для баз данных с форматами файлов Access 2003 и более ранних версий (MDB- и MDE-файлы). При открытии базы данных, созданной в более ранней версии Access и имеющей защиту на уровне пользователей, в Access 2010 параметры безопасности будут продолжать работать. В частности, пользователям потребуется вводить пароль для работы с базой данных.
Кроме того, можно запускать и использовать различные средства безопасности, которые предоставлялись в Access 2003 и более ранних версиях, например мастер защиты на уровне пользователей и различные диалоговые окна для настройки разрешений пользователей и групп. Помните, что эти средства доступны только при открытии MDB- и MDE-файлов. Если преобразовать файлы в формат Access 2010, все имеющиеся функции защиты на уровне пользователей будут утрачены.
Чтобы защитить базу данных паролем в MS-Access необходимо открыть ее «монопольно»:
Рис.8.1 - Монопольное открытие бд.
А затем установить пароль. Тогда, при каждом следующем открытии базы данных будет высвечиваться окно для ввода пароля:
Рис.8.2- БД, защищенная паролем.
Снимается пароль аналогичным способом.
9. Требования к техническому обеспечению
Для работы базы данных необходим персональный компьютер со следующими характеристиками: процессор Intel Pentium с тактовой частотой 800 МГц и выше, оперативная память - не менее 64 Мбайт, свободное дисковое пространство - не менее 500 Мбайт, монитор типа Super VGA (число цветов - 256) с диагональю не менее 15?. Программное обеспечение: операционная система WINDOWS 2000/XP и выше, Microsoft Office 2003 (с компонентами Access и Excel) и выше, Microsoft Framework 3.5 и выше.
10. Инструкция по пользованию БД
10.1 Вызов программы
Программа представляет собой базу данных, созданную в Microsoft Access 2010, запускаемый в любой операционной системе семейства Windows. Чтобы просмотреть текст программы или запустить её на выполнение - надо скопировать с носителя папку с проектом на жёсткий диск компьютера. Чтобы просмотреть текст программы, шаблоны диалоговых окон и др., то следует открыть файл с расширением .accdb, являющийся файлом проекта.
10.2 Экранные формы
Аccess предоставляет широкие возможности по конструированию графического интерфейса пользователя для работы с БД. Формы являются важнейшим инструментом, позволяющим осуществить первоначальную загрузку записей в таблицы, выполнить их просмотр и редактирование. При этом работа пользователя с БД выполняется в привычном для него виде -- в виде документа.
При наличии схемы данных формы помогают выполнить корректный ввод данных в систему взаимосвязанных таблиц. При этом реализуется важнейший аспект технологии работы с БД -- однократный ввод данных.
Для конструирования форм необходимо предварительно выполнить определенную последовательность действий по разработке СУБД:
· сконструировать таблицы БД;
· определить связи между таблицами и создать схему данных;
· определить эскиз экранной формы и состав размещаемых на ней объектов.
Конструирование форм обычно выполняют в режиме Мастера с последующей доработкой вручную в режиме конструктора. Мастер позволяет быстро разработать заготовку формы с необходимыми полями и связями, однако, он создает только типовые конструкции, вид которых может не устраивать пользователя. Переход в режим конструктора позволяет устранить недостатки оформления.
В курсовом проекте имеется 5 разных форм. Первая ленточного вида отражает содержимое таблицы «Должность»:
Рис.10.1- Форма «Должность».
Вторая другого вида. Для каждого задания выделена отдельная страница:
Рис. 10.3 - Форма «Задание».
Форма по таблице «Отдел»:
Рис. 10.4 - Форма «Отдел».
Форма по таблице «отпуск»:
Рис. 10.5 - Форма «отпуск».
Форма по таблице «Сотрудники»:
Рис. 10.6 - Форма по таблице «Сотрудники»
10.3 Описание отчетов
Отчет - это форматированное представление данных, которое выводится на экран, в печать или файл. Они позволяют извлечь из базы нужные сведения и представить их в виде, удобном для восприятия, а также предоставляют широкие возможности для обобщения и анализа данных.
При печати таблиц и запросов информация выдается практически в том виде, в котором хранится. Часто возникает необходимость представить данные в виде отчетов, которые имеют традиционный вид и легко читаются. Подробный отчет включает всю информацию из таблицы или запроса, но содержит заголовки и разбит на страницы с указанием верхних и нижних колонтитулов.
Отчет в данной курсовой работе представляет нам распределение должностей на 2014 год.
Рис.10.2 - Отчет.
11. Заключение
В ходе выполнения курсового проекта была создана база данных, позволяющая автоматизировать работу отдела кадров, с возможностью добавления, удаления, сохранения, редактирования таблицы.
База данных может быть использована для деятельности новой компании. Для более серьезных компаний необходимо создавать более сложные программные комплексы на основе клиент-серверной архитектуры.
В рамках курсового проекта были выполнены следующие задачи:
- изучение возможностей интегрированной среды разработки Microsoft Access 2010;
- получение практических навыков по использованию языка SQL;
- получение навыков нормализации и сохранения целостности данных;
Разработанный программный продукт удовлетворяет всем требованиям, выявленным в результате исследования предметной области и задач, стоящих перед специалистами, работающими в отделе кадров. Приложение является полнофункциональной базой данных с возможностью безопасной вставки, модификации и удаления записей, а также обладает разделением прав пользователей и интуитивно понятным интерфейсом.
Цель данного курсового проекта, анализ современных средств управления данными и приобретение практических навыков обследования предметной области, концептуального, логического и физического проектирования базы данных, освоение средств поддержания целостности БД, запросов, была выполнена.
12. Список литературы
1. https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0
2. http://sumk.ulstu.ru/docs/mszki/Zavgorodnii/11.7.html
3. http://www.sql-tutorial.ru/
4. Microsoft SQL Server 2008 T-SQL Fundamentals, Itzik Ben-Gan, 2008
5. Методические указания
6. Лекционный материал
7. Изучаем SQL, Автор: Алан Бьюли, Издательство: Символ-Плюс, 2007
8. МЕТОДЫ ФИЗИЧЕСКОЙ ОРГАНИЗАЦИИ ДАННЫХ, ПОДДЕРЖИВАЕМЫЕ СУЩЕСТВУЮЩИМИ СИСТЕМАМИ УПРАВЛЕНИЯ ДАННЫХ, ДРОЖДИН В. В., ВОЛОДИН А. М., Журнал «Известия Пензенского государственного педагогического университета им. В.Г. Белинского» Выпуск№ 12 / 2008.
9. http://www.swsys.ru/index.php?page=article&id=1469
Размещено на Allbest.ru
Подобные документы
Общее описание входных и выходных документов и сообщений. Список ограничений. Проектирование реляционной базы данных. Функциональные зависимости между атрибутами сущностей. Выборка информации и разработка представлений для отображения результатов.
курсовая работа [93,2 K], добавлен 21.06.2011Перечень используемых сущностей и атрибутов. Классификация и типы связей, их функциональные особенности. Реляционная модель базы данных, ее структура и разработка. Функциональные зависимости между атрибутами, требования к программному обеспечению.
курсовая работа [4,0 M], добавлен 26.05.2015Проектирование реляционной базы данных. Входная и выходная информация. Функциональные зависимости между атрибутами. Разработка представлений для отображения результатов выборки. Разработка механизмов управления данными в базе при помощи триггеров.
курсовая работа [1,6 M], добавлен 22.06.2011Логическое проектирование базы данных по автоматизации деятельности строительной компании. Классификация связей. Реляционная модель базы данных. Функциональные зависимости между атрибутами. Выбор ключей. Нормализация отношений. Запросы к базе данных.
курсовая работа [1,2 M], добавлен 26.05.2015Анализ предметной области с использованием моделей методологии ARIS и разработка ER-диаграммы. Описание входной и выходной информации для проектирования реляционной базы данных. Разработка управляющих запросов и связей между ними с помощью языка SQL.
курсовая работа [975,2 K], добавлен 30.01.2014Сущности и функциональные зависимости базы данных. Атрибуты и связи. Таблицы базы данных. Построение ER-диаграммы. Организация ввода и корректировки данных. Реляционная схема базы данных. Реализация запросов, получение отчетов. Защита базы данных.
курсовая работа [2,4 M], добавлен 06.02.2016Создание таблиц базы данных с помощью MS Access "Страны Азии". Форма базы данных и запросы к выборкам данных. Модификация структуры таблиц, создания связей между главными таблицами, редактирование данных и проектирование форм для реальной базы данных.
контрольная работа [723,9 K], добавлен 25.11.2012Построение информационной модели наиболее высокого уровня абстракции. Вид и содержание концептуальной модели базы данных. Установление связей между типами сущностей. Спецификация всех объектов, входящих в модель. Средства обеспечения целостности данных.
курсовая работа [2,6 M], добавлен 12.12.2011Сущность и характеристика типов моделей данных: иерархическая, сетевая и реляционная. Базовые понятия реляционной модели данных. Атрибуты, схема отношения базы данных. Условия целостности данных. Связи между таблицами. Общие представления о модели данных.
курсовая работа [36,1 K], добавлен 29.01.2011Создание реляционной базы данных "Деканат ВУЗа", средствами СУБД MS SQL Server 2000. Разработка клиентского приложения с удобным пользовательским интерфейсом (сопровождающегося меню и справочной системой). Описание связей между таблицами базы данных.
курсовая работа [3,0 M], добавлен 06.12.2014