Системы управления базами данных

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

Московский гуманитарно-экономический институт Тверского филиала

Юридический факультет

Кафедра гражданско-правовых дисциплин

Контрольная работа

по дисциплине «Информационные технологии в юридической деятельности»

на тему: «Системы управления базами данных»

Выполнил: студент 1 курса

Стерлядников А.Ю.

Научный руководитель:

к.ю.н., доцент Кукушкин В.М.

Бологое 2014 г



Содержание

Введение

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

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

3. Распределенные базы данных

Заключения

Литература



Введение

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

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

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

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

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

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

В современных СУБД используется «клиент - сервер», когда БД хранится на сервере, а СУБД имеет клиентскую и серверную части.

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

Цель работы заключается в рассмотрении систем управления базами данных. Достижение цели достигается путем решения ряда задач:

- дать общую характеристику СУБД;

- выделить функциональные возможности СУБД;

- определить классификацию СУБД.

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language - язык структурированных запросов). Так как в состав SQL входят два основных компонента: язык определения данных (DDL) и язык манипулирования данными (DML), SQL позволяет определять схему реляционной БД и манипулировать данными.

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

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

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

- Иерархические

- Сетевые

- Реляционные

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

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

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

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

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

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

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

Следуя спецификации CODASYL, сетевая модель поддерживает DDL (Data Definition Language - язык определения данных) и DML (Data Manipulation Language - язык обработки данных). Это специальные языки, предназначенные для определения структуры базы данных и составления запросов. Несмотря на их наличие программист по-прежнему должен знать структуру базы данных. Голицына О. Системы управления базами данных/сер проф.образование / тв.п/ 2006/ 159 с

В сетевой модели допускаются отношения "многие ко многим", а записи не зависят друг от друга. При удалении записи удаляются и все ее связи, но не сами связанные записи.

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

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

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

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

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

Каждая запись таблицы имеет одинаковую структуру. Например, в таблице, содержащей описания автомобилей, у всех записей будет один и тот же набор полей: производитель, модель, год выпуска, пробег и т.д. Такие таблицы легко изображать в графическом виде Г.И., Самохвалов Э.Н., Чистов В.В. Базы и банки данных и знаний. Учебник для вузов//Под ред. В.Н.Четверикова. - М., 2003. С. 455..

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

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

Реляционные базы данных страдают от различий в реализации языка SQL, хотя это и не проблема реляционной модели. Каждая реляционная СУБД реализует какое-то подмножество стандарта SQL плюс набор уникальных команд, что усложняет задачу программистам, пытающимся перейти от одной СУБД к другой Андон Ф., Резниченко В. Microsoft SQL Server 2000г.-СПб.:Питер; Киев:Издательская группа BHV,2003. Приходится делать нелегкий выбор между максимальной переносимостью и максимальной производительностью. В первом случае нужно придерживаться минимального общего набора команд, поддерживаемых в каждой СУБД. Во втором случае программист просто сосредоточивается на работе в данной конкретной СУБД, используя преимущества ее уникальных команд и функций СУБД Гуде С.В., Ревин С.Б. Информационные системы. Учебное пособие. -М., 2005. С. 386.

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

Преимуществом ООСУБД является упрощенный код. Приложения получают возможность интерпретировать данные в контексте того языка программирования, на котором они написаны. Реляционная база данных возвращает значения всех полей в текстовом виде, а затем они приводятся к локальным типам данных. В ООБД этот этап ликвидирован. Методы манипулирования данными всегда остаются одинаковыми независимо от того, находятся данные на диске или в памяти Г.И., Самохвалов Э.Н., Чистов В.В. Базы и банки данных и знаний. Учебник для вузов//Под ред. В.Н.Четверикова. - М., 2003. С. 459.

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

С помощью ООСУБД решаются две проблемы. Во-первых, сложные информационные структуры выражаются в них лучше, чем в реляционных базах данных, а во вторых, устраняется необходимость транслировать данные из того формата, который поддерживается в СУБД. Например, в реляционной СУБД размерность целых чисел может составлять 11 цифр, а в используемом языке программирования - 16. Программисту придется учитывать эту ситуацию Г.И., Самохвалов Э.Н., Чистов В.В. Базы и банки данных и знаний. Учебник для вузов//Под ред. В.Н.Четверикова. - М., 2003. С. 465.

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

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

Большим недостатком объектно-ориентированных баз данных является их тесная связь с применяемым языком программирования. К данным, хранящимся в реляционной СУБД, могут обращаться любые приложения, тогда как, к примеру, Java-объект, помещенный в ООСУБД, будет представлять интерес лишь для приложений, написанных на Java Дунаев С. Доступ к базам данных и техника работы в сети. Практические приемы современного программирования. - М., 2005. С. 543..

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

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

Следующим важнейшим классифицирующим признаком СУБД является степень распределённости. Здесь можно выделить локальные и распределённые СУБД.

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

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

3. Распределенные базы данных

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

Решение проблемы сетевого взаимодействия клиента и сервера с помощью коммуникационного сервера является необходимым (но не достаточным) условием поддержки распределенных баз данных. Неразрешенными пока остаются следующие задачи: управление именами в распределенной среде; оптимизация распределенных запросов; управление распределенными транзакциями.

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

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

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

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

Первое достигается использованием шлюзов, второе - использованием интерфейса ODBC.

До сих пор мы рассматривали однородные базы данных, то есть БД в формате конкретной СУБД. В то же время СУБД может осуществлять доступ к БД в другом формате. Это делается с помощью шлюза. Например, СУБД Ingres получает доступ к базе данных в формате СУБД Rdb через специальный шлюз. Если СУБД Альфа осуществляет доступ к базе данных в формате Бета (или просто к базе данных Бета), то говорят, что Альфа имеет шлюз в Бета Дунаев С. Доступ к базам данных и техника работы в сети. Практические приемы современного программирования. - М., 2005. С. 634..

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

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

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

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

Тиражирование данных - это асинхронный перенос изменений объектов исходной базы данных (source database) в БД, принадлежащие различным узлам распределенной системы. Функции тиражирования данных выполняет специальный модуль СУБД - сервер тиражирования данных, называемый репликатором (replicator). Его задача - поддержка идентичности данных в принимающих базах данных (target database) данным в исходной БД. В качестве базиса для тиражирования выступает транзакция к БД. В то же время возможен перенос изменений группами транзакций, периодически или в некоторый момент времени, что дает возможность исследовать состояние принимающей БД на определенный момент времени .

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

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

Просуммируем очевидные преимущества технологии тиражирования данных.

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

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

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

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

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

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

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

управление программный информация



Заключения

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

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

Главной функцией СУБД является эффективное хранение и предоставление данных в интересах конкретных прикладных задач.

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

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

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

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

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

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

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

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

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

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

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

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



Литература

1. Андон Ф., Резниченко В. Microsoft SQL Server 2000г. - СПб.: Питер; Киев: Издательская группа BHV,2003.

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

3. Дунаев С. Доступ к базам данных и техника работы в сети. Практические приемы современного программирования. - М., 2005. С. 638.

4. Гришков В.И. Исследование возможностей объектного представления данных в прикладных системах // Труды СПИИРАН. Вып.1, т.3. 2003.

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

6. Роб П., Коронел К. Системы баз данных: проектирование, реализация и управление. - 5-е изд., перераб. и доп. - СПб.: БХВ-Петербург, 2004. - 1040 с.

7. Самохвалов Э.Н., Чистов В.В. Базы и банки данных и знаний. Учебник для вузов//Под ред. В.Н. Четверикова. - М., 2003. С. 455

8. Голицына О. Сист. Упр. базами данных/сер проф. Образ. / тв.п/ 2006/ 432с

9. Дейв Энсор, Йен Стивенсон. Oracle - 8: Рекомендации разработчикам. - Киев: Изд. Гр. BHV. - 2005г. - 125 с.

10. Дюбуа П. применение MySQL и Perl в Web-приложениях. - Москва: Издательский дом "Вильямс", 2002. - 480 с.

11. Кириллов В.В. Основы проектирования реляционных баз данных. СПб.: ИТМО, 2006г.-280с.

12. Конноли Т., Бегг Л., Страчан А. Базы данных. Проектир., реализация и сопровождение. Теория и практика. - 2-е изд.- Вильямс, 2004г.-380с.

13. Кузнецов С.Д. Введение в СУБД//Сист. управления базами данных. 2001.

14. Фаронов В.В., Шумаков П.В. Руководство разработчика баз данных. - М.: Нолидж, 2000. С. 461.

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

...