Технологии администрирования современных реляционных баз данных

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

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

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

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

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

Объект исследований - технологические средства администрирования реляционных баз данных.

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

Цель данной работы - проанализировать и сравнить различные технологии администрирования современных реляционных баз данных.

Данная работа направлена на решение следующих задач:

1. Проанализировать сущность и назначение администрирования типовых реляционных баз данных (SQL Server).

2. Определить достоинства и недостатки администрирования типовых СУБД по критериям безопасности, комфортности,

3. Сформулировать анализ возможностей технологий администрирования СУБД в области документоведения.

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

Задачи исследования вытекают из поставленной цели:

1. рассмотреть основы процессы администрирования баз данных;

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

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

1. Теоретическая часть. Администрирование баз данных

1.1 Управление данными в базах данных при помощи СУБД

Непосредственное администрирование баз данных происходит при помощи систем управления баз данных (СУБД). Рассмотрим основные функции СУБД:

Управление данными во внешней памяти (на дисках).

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

Управление данными в оперативной памяти с использованием дискового кэша.

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

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

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

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

Поддержка языков БД.

В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (StructuredQueryLanguage).

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

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

Базы данных на ПК развивались по направлению от настольных (desktop), или локальных приложений, когда реально с БД могло работать одно приложение, до систем коллективного доступа к БД. Локальное приложение устанавливалось на единичном ПК; там же располагалась и база данных (БД), с которой работало данное приложение. Однако необходимость коллективной работы с одной и той же БД повлекло за собой перенос БД на сервер. Приложение, работающее с БД, располагалось также на сервере. Менее характерным был другой способ, заключавшийся в хранении приложения, обращавшегося к БД, на конкретном компьютере пользователей («клиентов»). Были выпущены новые версии локальных СУБД, которые позволяли создавать приложения, одновременно работающие с одной БД на файловом сервере. Основной проблемой была явная или неявная обработка транзакций и неизбежно встающая при коллективном доступе проблема обеспечения смысловой и ссылочной целостности БД при одновременном изменении одних и тех же данных. СУБД классифицируются:

По модели данных:

иерархические;

сетевые;

реляционные;

объектно-реляционные;

объектно-ориентированные.

По архитектуре организации хранения данных:

локальные СУБД (все части локальной СУБД размещаются на одном компьютере);

распределенные СУБД (части СУБД могут размещаться на двух и более компьютерах).

По способу доступа к БД:

файл-серверные.

В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. Ядро СУБД располагается на каждом клиентском компьютере. Доступ к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на ЦП сервера, а недостатком - высокая загрузка локальной сети. На данный момент файл-серверные СУБД считаются устаревшими. Примеры: Microsoft Access, Borland Paradox.

Клиент-серверные.

Такие СУБД состоят из клиентской части (которая входит в состав прикладной программы) и сервера. Клиент-серверные СУБД, в отличие от файл-серверных, обеспечивают разграничение доступа между пользователями и мало загружают сеть. Сервер является внешней по отношению к клиенту программой, и по надобности его можно заменить другим. Недостаток клиент-серверных СУБД в самом факте существования сервера (что плохо для локальных программ - в них удобнее встраиваемые СУБД) и больших вычислительных ресурсах, потребляемых сервером. Примеры: Firebird, Interbase, IBM DB2, MS SQL Server, Sybase, Oracle, PostgreSQL, MySQL, ЛИНТЕР.

Встраиваемые.

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

1.2 Особенности администрирования Microsoft SQL Server

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

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

Первое и наиболее очевидное применение расширенных свойств объектов - это, безусловно, документирование. Если администратор создает таблицу в Enterprise Manager и для ее полей дает описание (Description), то описание для каждого поля автоматически превращается в расширенное свойство с именем MS_Description.

В Query Analyzer контекстные меню объектов содержат команду Extended properties. Первый из таких объектов - это сама база данных. Далее следуют расположенные по уровням иерархии сверху вниз объекты:

0 - User, Type;1 - Table, View, Procedure, Function, Default, Rule;2 - Column, Parameter, Index, Constraint, Trigger.

У самой базы данных уровня нет. Если в параметрах процедур, работающих с расширенными свойствами, уровни не указаны, то свойство принадлежит базе. Например, операторы

Use MyDB

exec sp_addextendedproperty N'Property1', N'test'

добавят к базе MyDB свойство Property1 со значением test.

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

Все расширенные свойства объектов базы хранятся в системной таблице Sysproperties. Для поиска объектов по расширенным свойствам и их значениям очень удобно использовать Query Analyzer. Нужно выбрать из меню Tools команду Object Search и заполнить соответствующие поля.

1.3 Аудит хранимых процедур

Механизм расширенных свойств можно использовать для аудита вызова хранимых процедур, т. е. для получения сведений о том, кто вызвал хранимую процедуру, когда и с какими параметрами. Можно также в значении расширенного свойства процедуры запоминать порядковый номер ее вызова. Для этого нужно создать расширенные свойства для процедуры или пользователя, например, в Query Analyzer, а текст процедуры дополнить вызовом обновления соответствующих расширенных свойств. Информацию, связанную с аудитом, можно получать с помощью SQL Profiler. Преимущество использования расширенных свойств в том, что эта информация становится принадлежностью самого объекта и хранится в нем самом. Хотя такой механизм не заменяет возможностей SQL Profiler. Расширенные свойства параметров хранимой процедуры могут содержать значения данных параметров и дату использования. Все это относится только к процедурам, написанным самостоятельно, даже когда процедура хранится в базе Master и ее имя начинается с sp_. Тексты системных хранимых процедур для редактирования недоступны, поэтому изнутри нельзя управлять их расширенными свойствами, хотя создавать эти свойства внешними средствами можно.

1.4 Сравнительные характеристики технологий администрирования типовых СУБД в области документоведения

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

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

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

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

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

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

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

На сегодняшний день промышленность в области документоведения нуждается в квалифицированных специалистах по Oracle. Все больше людей, заинтересованных в смене работы, рассматривают технологии Oracle как огромную и потенциально выгодную сферу деятельности. Потому как эта СУБД является расширенной в области администрирования.

Во времена Oracle V4 администратор БД зачастую оставался лишь разработчиком. Единственным способом резервирования данных было копирование всего программного обеспечения БД Oracle и файлов данных. Выход Oracle V5 и появление SQL*net ознаменовали собой развитие нового подхода клиент-сервер. Кроме того, в Oracle V5 были включены дополнительные средства настойки, такие как explain plan, средства аудита и тому подобное. В помощь администратору БД предоставлялся ряд дополнительных функций, призванных облегчить его работу. Начиная с Oracle V6, стало происходить разделение администраторов по специализациям. Корпорация Oracle выпустила целый пакет приложений; внедрила параллельный сервер; размеры баз данных можно было уже смело охарактеризовать, как очень большие; по этим причинам системой становилось все труднее управлять, что еще более усугублялось наличием ошибок и разрушением данных. Кроме того, в Oracle V6 впервые были введены триггеры и язык PL/SQL, а заинтересованной общественности представлен механизм репликации. Сложность же пакета Oracle V7 достигла небывалых до той поры высот, воплотив понятие целостности ссылочных данных или отношения первичный/внешний ключ на уровне БД. Это позволило упростить написание приложений, однако добавило лишней работы администраторам БД. Oracle V8, в свою очередь, познакомил всех с разбиением таблиц и индексов, и массой новых средств индексации. Oracle8i стал еще выше благодаря поддержке файловой системы Интернет, Java-триггеров и т. д.

Можно сделать выводы, что наиболее часто используемой СУБД является Microsoft Access, с которой работают различные пользователи для решения незначительных задач. После нее идет Microsoft SQL Server, с которой работают малые и средние организации, так как она по характеристикам простая и комфортная в пользовании. В отличии от этих баз данных, СУБД Oracle используют крупные корпорации и предприятия, в которых необходимо многофункциональные возможности в системе управления базами данных.

1.5 Резервное копирование БД

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

При желании иметь актуальную резервную копию БД, возникает желание использовать конфигурацию дисков RAID, которая обеспечивает создание зеркала с целью защиты данных, но это не панацея. Массивы RAID являются только первой ступенью в деле обеспечения защиты данных от потери. В зависимости от конфигурации массива RAID, один или даже несколько жестких дисков должны выйти из строя, прежде чем произойдет безвозвратная потеря данных. Кроме того, использование дисков «горячей» замены и горячего резерва может быть использовано для того, чтобы сервер продолжал работать без отключения даже в случае выхода из строя жесткого диска. Ключевая вещь, которую вы должен понимать АБД, это то, что массивы RAID могут защитить данные в случае выхода из строя жестких дисков. А что произойдет, если будет ЧП (пожар, потоп, ограбление и т.д.)? Файлы базы данных окажутся, повреждены в результате ошибки программного обеспечения или аппаратного сбоя? Ну и наконец, что будет, если пользователь (или сам АБД) удалит по ошибки данные, которые вдруг потребуются в дальнейшем? Конфигурация RAID не сможет помочь в этих случаях.

Самое главное - администратор может всегда заменить сервер, но данные этого сервера восстановить чрезвычайно трудно, иногда просто невозможно.

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

Сервер SQL поддерживает три вида резервного копирования: полное (Full), разностное или дифференциальное (Differential) и копирование журнала (Log). В дополнение к трем основным видам резервного копирования, которые работают со всей базой данных в целом, есть также несколько дополнительных типов резервного копирования, которые используются для копирования одного файла или группы файлов.

Полное резервное копирование (Full) - создает полную резервную копию всех экстентов базы данных. Если АБД будет восстанавливать базу данных, используя для этого полную резервную копию, потребуется только самый последний созданный им экземпляр. Однако, полное резервное копирование - самый медленный тип резервного копирования.

Дифференциальное резервное копирование (Differential) - создает резервную копию только тех экстентов, которые были изменены с момента последнего полного копирования. Если АБД будет восстанавливать базу данных, используя дифференциальную резервную копию, ему потребуется последняя полная резервная копия и последняя созданная им дифференциальная резервная копия. Дифференциальное резервное копирование осуществляется гораздо быстрее, но требует больше времени на восстановление, так как требует применение, как полной резервной копии, так и дифференциальной резервной копии.

Резервная копия журнала - создает резервную копию журнала транзакций с момента последней полной резервной копии или предыдущей копии журнала транзакций. АБД потребуется (или не потребуется) создавать резервные копии журнала транзакций в зависимости от используемой им модели восстановления. Если он будет восстанавливать базу данных, используя полное резервное копирование и копирование журнала транзакций, для восстановления ему потребуется последняя полная резервная копия и все (по порядку) резервные копии журнала транзакций.

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

Сервер SQL может выполнять резервное копирование в файл, расположенный на жестком диске, на сетевом диске, на устройстве с магнитной лентой.

Все изменения, сделанные в базе данных, обязательно фиксируются в журнале транзакций. В случае аварии (такой, как отключение электроэнергии или «синий» экран) журнал транзакций может быть использован для восстановления изменений базы данных. Кроме того, контрольные точки используются для записи всех страниц оперативной памяти на жесткий диск, тем самым уменьшая время, необходимое для восстановления базы данных. Итак, если в контрольной точке все страницы с данными записываются на жесткий диск, зачем нам необходимо хранить информацию о транзакциях? Отвечая на этот вопрос, нам придется говорить о моделях восстановления.

Каждая база данных, запущенная на сервере SQL может придерживаться одной из трех моделей восстановления: Полной (Full), Регистрации пакетных операций (Bulk_Logged) и Простой (Simple).

Модель полного восстановления предоставляет наибольшее число возможностей в случае повреждения данных. Если все транзакции заносятся в журнал, и используется режим полного восстановления, транзакции сохраняются в журнале до тех пор, пока не будет создана их резервная копия. Как только будет осуществлено резервное копирование базы данных, дисковое пространство, использовавшееся для хранения информации о транзакциях, становится свободным и затем может быть использовано для ведения журнала новых транзакций. Так как все транзакции вносятся в резервную копию, полное резервное копирование делает возможным восстановление базы данных в «заданной точке времени», используя только те транзакции, которые имели место до этого момента времени. Например, мы можем провести восстановление, используя полную резервную копию, а затем восстановить все копии журнала транзакций до определенного момента, прежде чем какие-то важные данные были удалены.

Если модель полного восстановления отслеживает все изменения, сделанные в базе данных, и позволяет нам восстанавливать все транзакции к любому моменту времени, то возникает вопрос - почему бы всегда не использовать эту модель? Так как все операторы должны при этом фиксироваться полностью, на выходе может получиться достаточно «тяжелый» файл журнала. Кроме того, такие команды как BULK INSERT будут замедлять работу сервера, так как все выполняемые ими изменения должны вноситься в журнал.

Модель регистрации пакетных операций (bulk_logged) достаточно похожа на модель полного восстановления с некоторые добавлениями и преимуществами. Как и в полной модели восстановления, в модели регистрации пакетных операций также фиксируются все операторы UPDATE, DELETE и INSERT. Однако, для определенных команд, в данной модели фиксируется лишь то, что операция имела место. Это верно для таких команд как BULK INSERT, bcp, CREATE INDEX, SELECT INTO, WRITETEXT и UPDATETEXT. Модель регистрации пакетных операций похожа на модель полного восстановления тем, что не использует повторно (не перезаписывает) пространство журнала до тех пор, пока не будет произведено резервное копирование всех транзакций.

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

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

Простая модель восстановления. В отличие от полной и модели регистрации пакетных операций, простая модель восстановления не использует резервное копирование журнала транзакций. В данной модели журналы транзакций часто усекаются (усечение - это процесс удаления старых транзакций из журнала) автоматически. Модель простого восстановления может использовать полное и разностное резервное копирование.

база данные администрирование документоведение

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

2.1 Анализ предметной области

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

СОТРУДНИКИ: табномер; ФИО; должность; оклад; надбавка; взнос1; взнос2;

КАЛЕНДАРЬ РАБОЧЕГО ВРЕМЕНИ: код_мес; месяц; раб_дни;

ТАБЕЛЬ: таб_ном; код_мес; дни;

Основными пользователями данной системы будут бухгалтерия и отдел кадров. Запросы должны быть строго регламентированы. Можно выделить следующие типы запросов:

расчет заработной платы;

запрос сведений о зарплате работников;

запрос о сотрудниках, отработавших весь месяц;

Рассмотрим также примерный отчет, сформированный на основе запросов:

расчет заработной платы.

2.2 Формирование общих требований к системе

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

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

1. Независимость данных на логическом и физическом уровнях.

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

3. Ограничение доступа и защита данных от несанкционированного доступа.

4. Корректировка, удаление и добавление данных.

5. Обеспечение минимальной избыточности информации.

6. Адаптируемость к изменяющимся потребностям пользователей.

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

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

Входной информацией в данной задаче будет являться:

сведения о сотрудниках;

сведения об окладе сотрудника;

сведения о надбавке;

сведения о взносах;

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

Выходной информацией в данной задаче будет являться:

платежная ведомость:

сведения о сотрудниках данного предприятия;

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

2.3 Построение концептуальной модели предметной области

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

На основании исследования предметной области и требований заказчика построим концептуальную модель базы данных (рис. 1).

Рис. 1. Концептуальная модель базы данных

Определены следующие типы реальных отношений:

1. 1:М (один-ко-многим) - при которых каждому экземпляру первого объекта соответствует множество экземпляров второго объекта, а каждому экземпляру второго объекта соответствует один экземпляр первого объекта. Пример данного отношения:

СОТРУДНИК

МЕСЯЦ

ВЕДОМОСТЬ

ДОЛЖНОСТЬ

2.4 Построение логической структуры базы данных

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

Информационно-логическая модель приведена к каноническому виду, и объекты расположены в ней по уровням. На нулевом уровне располагаются объекты не подчиненные никаким другим объектам, обычно называются справочники. На 1 уровне подчиненные 0 уровню и т.д. Такое размещение объектов дает представление об иерархической подчиненности, делает модель более наглядной и облегчает понимание зависимостей 1:М.

Для определения уровня объектов на графе ИЛМ можно, условно удалив объекты нулевого уровня, найти объекты первого уровня. К объектам этого уровня следует отнести объекты, не подчиненные теперь никаким другим объектам. Аналогично определяются объекты каждого следующего уровня. При большом количестве объектов в ИЛМ аналогичные действия, выполняются на матрице смежности модели.

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

Данные организованы в таблицы: СОТРУДНИКИ, КАЛЕНДАРЬ РАБОЧЕГО ВРЕМЕНИ И ТАБЕЛЬ.

Таблица СОТРУДНИКИ содержит необходимые сведения о каждом сотруднике: табельный номер, ФИО, должность, оклад, процент надбавки и различные взносы.

Таблица КАЛЕНДАРЬ РАБОЧЕГО ВРЕМЕНИ содержит сведения: код месяца, наименование месяца и рабочие дни.

Таблица ТАБЕЛЬ содержит информации о количестве отработанных дней сотрудником: табельный номер, код месяца и количество отработанных дней.

Информационно-логическая модель может быть представлена в графическом виде (рис. 2).

Рис. 2. Информационно-логическая модель предметной области

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

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

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

СОТРУДНИКИ: табномер, ФИО, должность, оклад, надбавка, взнос1, взнос2.

КАЛЕНДАРЬ РАБОЧЕГО ВРЕМЕНИ: код_мес, месяц, раб_дни.

ТАБЕЛЬ: таб_ном, код_мес, дни.

Реляционный подход к проектированию информационно-логической модели (ИЛМ) базируется на понятии нормализации. Теория нормализаии основана на том, что определенные наборы таблиц (отношений) в наилучшей степени отражают свойства предметной области и в то же время обнаруживают лучшие качества по отношению к другим наборам таблиц в процессе манипулирования. В таблицах данной задачи:

содержаться только простые, далее неделимые данные, т. е. таблицы находятся в первой нормальной форме;

выполняется условие функционально-полной зависимости не ключевых атрибутов от ключа - находятся во второй нормальной форме;

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

Связи между атрибутами реализуются объединением атрибутов в таблицу. Связи между объектами в реляционной базе не хранятся, а образуются в процессе манипулирования.

2.5 Представление физической модели

Представление физической модели в MS Access:

Таблица 1. Календарь рабочего времени

Поле	Тип поля	Размер поля	Формат поля
Код_мес*	Счетчик	Длинное целое
Месяц	Текстовый	20
Раб_дни	Числовой	Целое

Поля, отмеченные знаком «*» - ключевые.

Таблица 2. Сотрудники

Поле	Тип данных	Размер поля	Формат поля
Табномер*	Числовой	Целое
ФИО	Текстовый	50
Должность	Текстовый	50
Оклад	Денежный		С разделителями разрядов
Надбавка	Числовой	Двойное с плавающей точкой	Фиксированный
Взнос1	Числовой	Двойное с плавающей точкой	Фиксированный
Взнос2	Числовой	Двойное с плавающей точкой	Фиксированный

Таблица 3. Табель

Поле	Тип данных	Размер поля	Формат поля
Таб_ном	Числовой	Целое
Код_мес	Числовой	Длинное целое
Дни	Числовой	Целое

2.6 Создание базы данных

2.6.1 Установление связей между таблицами

Между таблицами установим связи типа «один-ко-многим».

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

Рис. 3. Диалоговое окно Изменение связей

После этого окно Схема данных примет вид (рис. 4)



Рис. 4. Расположение таблиц в окне схемы данных

2.6.2 Заполнение таблиц данными

Таблицы содержат следующие данные (рис. 5), (рис. 6), (рис. 7)

Рис. 5. Таблица Табель

Рис. 6. Таблица Календарь рабочего времени

Рис. 7. Таблица Сотрудники

2.6.3 Создание запросов

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

SELECT Табель.Таб_ном, Сотрудники.ФИО, [Календарь рабочего времени].Месяц, Табель.Дни

FROM [Календарь рабочего времени] INNER JOIN (Сотрудники INNER JOIN Табель ON Сотрудники.Табномер = Табель.Таб_ном) ON [Календарь рабочего времени].Код_мес = Табель.Код_мес

WHERE (((Табель.Дни)=17));

При выполнении запроса получим сведения о сотрудниках отработавших 17 дней (рис. 8)

Рис. 8. Запрос Полный месяц

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

SELECT [Календарь рабочего времени].Месяц, Табель.Таб_ном, Сотрудники.ФИО, Сотрудники.Должность, Сотрудники.Оклад, [Сотрудники]![Оклад]/[Календарь рабочего времени]![Раб_дни]*[Табель]![Дни] AS Начислено, [Начислено]*[Сотрудники]![Надбавка] AS Надбавка, [Начислено]+[Надбавка] AS [Всего начислено], [Всего начислено]*[Сотрудники]![Взнос1] AS Взнос1, [Всего начислено]*[Сотрудники]![Взнос2] AS Взнос2, [Взнос1]+[Взнос2] AS [Всего удержано], [Всего начислено]-[Всего удержано] AS [К выдаче]

FROM Сотрудники INNER JOIN ([Календарь рабочего времени] INNER JOIN Табель ON [Календарь рабочего времени].Код_мес = Табель.Код_мес) ON Сотрудники.Табномер = Табель.Таб_ном;

Запрос будет иметь вид (рис. 9)

Рис. 9. Запрос Расчет

Требуется получить сведения о сотруднике по его ФИО.

В режиме SQL запрос будет иметь вид:

SELECTСотрудники.Табномер, Сотрудники.ФИО, Сотрудники.Должность, Сотрудники.Оклад

FROM Сотрудники INNER JOIN Табель ON Сотрудники.Табномер = Табель.Таб_ном

WHERE (((Сотрудники.ФИО) Like [Введите ФИО сотрудника] & «*»));

При выполнении, запрос потребует ввода ФИО сотрудника или начальных букв в следующем окне (рис. 10):

Рис. 10. Запрос Сведения о сотруднике по ФИО

2.7 Создание форм

Перейдем на вкладку Формы главного окна базы данных и выберем Создание формы с помощью мастера.

Создадим форму для вывода запроса Расчет. В диалоговом окне Новая форма выберем в качестве источника данных запрос Расчет, режим создания формы - Автоформа: в столбец. Сохраним форму под именем Расчет. Для выполнения и просмотра запроса откроем форму (рис. 11).

Рис. 11. Форма Расчет

Создадим формы для вывода таблиц «Сотрудники», «Табель», «Календарь рабочего времени».

Откроем вкладку Формы, кнопка Создать. Создадим форму для заполнения таблицы Календарь. В диалоговом окне Новая форма выберем в качестве источника данных таблицу Календарь, режим создания формы - Автоформа: в столбец. Сохраним форму под именем Календарь.

Форма будет иметь вид (рис. 12).

Рис. 12. Форма Календарь

Аналогичным образом создадим форму Сотрудники в режиме Автоформа: ленточная и форму Табель в режиме Автоформа: в столбец.

2.8 Создание отчета

Откроем вкладку Отчеты, кнопка Создать, режим Мастеротчетов, источник данных: запрос Расчет. Выбираем поля из запроса Расчет: Месяц, ФИО, Всего_начислено, Всего_удержано, К выдаче. Далее. Группировка по полю Месяц. Далее. Сортировка по полю ФИО, Итоги: Sum по полям Всего_начислено, Всего удержано, К выдаче. Показать данные и итоги. Далее. Макет-Структура1, ориентация альбомная. Далее. Зададим имя отчета Платежная ведомость. Отчет примет вид (рис. 13).



Рис. 13. Отчет Расчет

Заключение

В современном мире базы данных просто необходимы, исходя из количества информации, с которым приходится иметь дело. Итак, использование концепции баз данных позволяет:

- повысить надежность, целостность и сохранность данных;

- сохранить затраты интеллектуального труда;

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

- обеспечить независимость прикладных программ от данных (изменений их описаний и способов хранения);

- обеспечить достоверность данных;

- обеспечить требуемую скорость доступа к данным;

- стандартизовать данные в пределах одной предметной области;

- автоматизировать реорганизацию данных;

- обеспечить защиту от искажения и уничтожения данных;

- сократить дублирование информации за счет структурирования данных;

- обеспечить обработку незапланированных запросов к хранимой информации;

- создать предпосылки для создания распределенной обработки данных.

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

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

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

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

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

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

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

Список используемых источников

1. Ржеуцкая, С.Ю. Базы данных. Язык SQL. - Вологда: ВоГТУ, 2010.- 159 с.

2. Проектирование реляционных баз данных: Метод.указания к курсовому проектированию по курсу "Базы данных" / Сост.: Карпова И.П. - М.: МИЭМ, 2010. - 32 с.

3. Бураков П.В., Петров В.Ю. Введение в системы баз данных. Учебное пособие.- СПб.:СПбГУ ИТМО, 2010 г. - 129 с.

4. Информационные технологии в бухгалтерском учете и аудите: Учебное пособие/ Под ред. С.М. Бычковой. - М.: ТК «Велби»: Изд-во «Проспект», 2009. - 216 с.

5. . Голицина, О.Л. Базы данных: Учебное пособие. - М.: Форум-Инфра, 2008.- 352 с.

6. Ревунков Г.И., Самохвалов Э.Н., Чистов В.В. Базы и банки данных и знаний. Учебник для вузов. - М.: Высш. шк. 2009.- 392 с.

7. Фред Ролланд Основные концепции баз данных. - М.: Вильямс, 2008.- 256 с.

8. Гуде, С.В., Ревин С.Б. Информационные системы. Учебное пособие. - М., 2009.- 147 с.

9. Кузнецов, С.Д. Базы данных. - М.: Академия, 2012.- 496 с.

10. Когаловский, М.Р. Энциклопедия технологий баз данных. - М.: Финансы и статистика, 2009.- 800 с.

11. Крейг С. Маллинс, Администрирование баз данных. Полное справочное руководство по методам и процедурам. - М.: КУДИЦ-Образ, 2008.- 752 с.

12. Кузин, А.В. Базы данных. - М.: Академия, 2010.- 320 с.

13. Григорьев, Ю.А. Банки данных: Учебник для вузов. - М.: МГТУ им.Баумана, 2007.- 320 с.

14. Трудовой кодекс РФ от 30.12.2001 №146 - ФЗ (ред. от 09.05.2005)

15. Кошелев, В. Е. Access 2007. Эффективное использование. - М.: Бином-Пресс, 2009. - 590 с.

16. Маркин, А. В. Построение запросов и программирование на SQL. - М.: Диалог-МИФИ, 2008.- 320 с.

17. Полякова, Л.Н. Основы SQL. - М.: Интернет-университет информационных технологий, 2008.-224 с.

18. Кузнецов, С.Д. Базы данных. Модели и языки. - М.: Бином-Пресс, 2008.- 496 с.

19. Хомоненко, А.Д. Базы данных. - СПб.: Корона-Век, 2010.-736 с.

20. Пирогов, Ю.В. Информационные системы и базы данных. Организация и проектирование. - СПб.: БХВ-Петербург, 209.-528 с.

21. Кумскова, И.А. Базы данных. - М.: КноРус, 2011.- 488 с.

22. Полубояров, В.В Использование MS SQL Server 2008 Analysis Services. - Новосибирск: НГТУ, 2010. - 488 с.

23. Билл Карвин, Программирование баз данных SQL. Типичные ошибки и их устранение. - М.: Рид Медиа, 2012. - 336 с.

24. К. Дж. Дейт, SQL и реляционная теория. Как грамотно писать код на SQL. - СПб.: Символ-Плюс, 2010. - 474 с.

25. Одиночкина, С.В. Разработка баз данных в Microsoft Access 2010. - СПб.: НИУ ИТМО, 2012. - 81 с.

Размещено на Allbest.ru

...