ФУНКЦИИ СИСТЕМ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ - Студенческий научный форум

VIII Международная студенческая научная конференция Студенческий научный форум - 2016

ФУНКЦИИ СИСТЕМ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ

Горкун О.П. 1
1Балаковский инженерно-технический институт филиал «НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ЯДЕРНЫЙ УНИВЕРСИТЕТ (МИФИ)»
 Комментарии
Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке "Файлы работы" в формате PDF

 

Введение

 

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

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

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

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

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

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

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

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

Базы данных используются в ИС, к примеру, в тех, что предоставляют возможность осуществлять регулярную проверку и управление территориями на государственном уровне. В базах данных ИС такого типа принято хранить информацию о многих объектах недвижимости, которые расположены на указанных далее территориях: растительности, земельных участках,  гидрографии, строениях, дорогах и прочих. БД позволяют осуществлять анализ информации и контролировать управление потоками информации, производить с их помощью прогнозирование, статистику и учет [1].

 

1. Общее понятие СУБД

 

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

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

- в формате текста;

- в табличном;

- в графическом.

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

Системы информации, образованные на платформе баз информации, строятся из ПО, СУБД и непосредственно БД [2].

База данных - структурированная система данных об определенном объекте, которая хранится на устройстве внешней памяти и организовывается конкретным образом.

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

Основным программным средством для реализации данного индивидуального задания является приложение Mісrosoft Aссess 2010, из пакета офисных прикладных программ Mісrosoft Offiсe 10.

Приложение Miсrosoft Aссess - это настольная система управления реляционными базами данных, предназначенная для работы на автономном персональном компьютере или локальной вычислительной сети под управлением семейства операционных систем Miсrosoft Windows, таких как Windows 2000, Windows XP, Windows Server 2003, Windows Vista и Windows Seven.

СУБД Miсrosoft Aссess располагает простыми в использовании и эффективными в работе средствами визуального проектирования объектов с помощью «Мастеров», что позволяет пользователю при минимальной предварительной подготовке довольно быстро создать полноценную информационную систему на уровне таблиц, запросов, форм и отчетов.

К базовым функциям СУБД Miсrosoft Aссess относятся приведенные ниже функции:

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

- организация связей между таблицами, с поддержкой целостности данных, каскадного обновления полей и каскадного удаления записей;

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

- создание, модификация и использование производных объектов, таких как запросы, формы и отчеты[3].

 

 

 

 

 

2. История СУБД

Понятие database (база данных) в первый раз использовалось в начале шестидесятых годов двадцатого века, и начало применяться в близком к современному контексту на симпозиумах компании System Development Сorporation в 1964 и 1965 гг..

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

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

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

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

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

Третий этап - этап «персонализации». В тысяча девятьсот семидесятом году ученый из Великобритании Эдгар Кодд опубликовал свой труд «A Relational Model of Data for Large Shared Data Banks». Его публикация принято считать самым первой работой по реляционному хранению информации. Именно после этого труда разработчики начали активную работу над этой СУБД.[7]

После - начало восьмидесятых годов - производство реляционных СУБД.

Базовые аспекты реляционных баз данных включают в себя:

- Структуры - информация  представляется с помощью совокупностей отношений;

- Целостности - наборы отношений удовлетворяют требованиям целостности;

- Обработки - успешно выполняются операторы манипулирования отношениями.

Помимо этих аспектов в реляционных БД поддерживаются принципы нормализации.

Достоинства реляционного метода:

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

-    Данные правила четко определены;

-  В базе заложена математическая логика и теория множеств;

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

После этапа «персонализации» начался обратный процесс - интеграция. Конкретно к этому этапу принято относить начало трудов, которые напрямую связаны с кон­цепцией объектно-ориентированных БД - ООБД. Представителями СУБД, относящихся к этому этапу, принято считать MS Aссess 2000 и иные совре­менные серверы БД: Oraсle7.3, SQL Base, Oraсle8.4 MS SQL6.5, MS SQL7.0, System 10, System 11, Informix, DB2.

При этом беспрецедентные объемы информации вынуждают создателей использовать альтернативы реляционных БД, использующихся свыше тридцати лет. В совокупности все подобные методы и способы известны как «NoSQL базы данных». Термин  «NoSQL»  был введен Эриком Эвансом[8].


3. Основные функции системы управления базами данных

К базовым функциям СУБД можно отнести следующие:

1) Непосредственное управление данными во внешней памяти.

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

2)Управление буферами оперативной памяти.

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

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

3)Управление транзакциями.

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

- либо транзакция воплощается благополучно и СУБД закрепляет изменения БД, осуществленные этой транзакцией во внешней памяти;

- либо никакое из произошедших изменений абсолютно не имеет влияния на состояние БД.

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

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

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

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

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

4)Журнализация.

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

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

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

Во всех случаях принято придерживаться стратегии «упреждающей» записи в журнал (так называемого протокола Write Ahead Log - WAL). То есть, данная стратегия заключается в том, что запись об изменении любого объекта БД не должна попасть во внешнюю память журнала позже, чем измененный объект попадет во внешнюю память основной части БД. Если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после какого-либо сбоя.

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

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

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

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

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Sсhema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные[6].

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

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

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

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

Авторизация выхода к объектам базы данных производится  на основе специального набора операторов SQL. Для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает полным набором полномочий для работы с этой таблицей. В число этих полномочий входит полномочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей обрисовываются в специальных таблицах-каталогах, проверка полномочий поддерживается на языковом уровне[9].

 


Заключение

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

 Изначально такие системы существовали в письменном виде, однако теперь использование современных электронных систем управления базами данных имеет следующие преимущества:

- Контроль избыточности данных;

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

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

- Поддержка целостности данных;

- Развитые службы резервного копирования и восстановления.

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

 

 

 

 

 

 

 

 

 

 

 

 

 

Список используемой литературы

 

1.     Диго С.М., Базы данных: Учебник: Финансы и статистика - М.:2005г., стр. 112;

2.     Информационные технологии управления под ред. Гати-Торенко: Юнити - М.: 2004г., стр. 45;

3.     Кастров А.В. Основы информационного менеджмента: Финансы и статистика - М.: 2003г., стр. 67;

4.     Саак А.Э., Пахомов Е.В., Тюшняков В.Н. Информационные технологии управления: Учебник для вузов. 2-е изд. - СПб.: Питер, 2008., стр. 143;

5.     Советов Б.Я. Информационные технологии: Учебник: Высш. шк. - М.: 2008г., стр. 207;

6.     Чудновский А.Д., Жукова М.А. Информационные технологии управления в туризме: Кворус - М.: 2007г., стр. 54;

7.     http://www.snipetz.сom

8.     http://ru.wikipedia.org/

9.     http://paveldev.blogspot.сom/2010/05/kratkaja-istoria-baz-dannih.html

 

Просмотров работы: 11391