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

Сиситема управления базами данных обладает следующими возможностями:

1) позволяет определять базу данных, что обычно осуществляется с помощью языка определения данных(DDL – Data Definition Language). Язык DDL предоставляет пользователям средства указания типа данных и их струк­туры, а также средства задания ограничений для информации, хранимой в базе данных;

2) позволяет вставлять, обновлять, удалять и извлекать информацию из базы дан­ных, что обычно осуществляется с помощьюязыка управления данными(DML – Data Manipulation Language). Наличие централизованного хранилища всех данных и их описаний позволяет использовать язык DML как общий инст­румент организации запросов, который иногда называютязыком запросов (query language). Наличие языка запросов позволяет устранить присущие файловым системам ограничения, при которых пользователям приходится иметь дело толь­ко с фиксированным набором запросов или постоянно возрастающим количест­вом программ, что порождает другие, более сложные проблемы управления про­граммным обеспечением. Существует две разновидности языков DML –процедурные (procedural) и непроцедурные (non-procedural) языки, – которые отличаются между со­бой способом извлечения данных. Основное отличие между ними заключа­ется в том, что процедурные языки обычно обрабатывают информацию в базе данных последовательно, запись за записью, а непроцедурные опери­руют сразу целыми наборами записей. Поэтому с помощью процедурных языков DML обычно указывается, как можно получить желаемый резуль­тат, тогда как непроцедурные языки DML используются для описания то­го, что следует получить. Наиболее распространенным типом непроцедур­ного языка является язык структурированных запросов (Structured Query Language – SQL), который в настоящее время определяется специальным стандартом и фактически является обязательным языком для любых ре­ляционных СУБД. (SQL произносится либо по буквам “S-Q-L”, либо как мнемоническое имя “See-Quel”.) Язык SQL будет рассматриваться в юните 2;

3) предоставляет контролируемый доступ к базе данных с помощью перечис­ленных ниже средств:

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

• системы поддержки целостности данных, обеспечивающей непротиворе­чивое состояние хранимых данных;

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

• системы восстановления, позволяющей восстановить базу данных до предыдущего непротиворечивого состояния, нарушенного в результате сбоя аппаратного или программного обеспечения;

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

На рис. 11 показан пример применения базы данных: физическая структура и способ хранения данных в этом слу­чае контролируются с помощью СУБД.

Рис 11. Применение базы данных

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

Преимущества СУБД

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

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

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

4. Поддержка целостности данных. Целостность базы данныхозначает корректность и непротиворечивость хранимых в ней данных. Целостность обычно описывается с помощьюограничений, т.е. правил под­держки непротиворечивости, которые не должны нарушаться в базе данных. Ограниче­ния можно применять к элементам данных внутри одной записи или к связям между за­писями. Например, ограничение целостности может гласить, что зарплата сотрудника не должна превышать 40 000 рублей в год или же что в записи с данными о со­труднике номер отделения, в котором он работает, должен соответствовать реально суще­ствующему отделению компании.

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

6. Применение стандартов. Интеграция позволяет определять и применять необходимые стандарты. На­пример, стандарты отдела и организации, государственные и международные стандар­ты могут регламентировать формат данных при обмене ими между системами, согла­шения об именах, форму представления документации, процедуры обновления и пра­вила доступа.

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

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

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

SELECT *

FROM property_for_rent

WHERE type=’Flat’ AMD rent>400;

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

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

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

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

Недостатки СУБД

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

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

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

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

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

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

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

Физическое проектирование

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

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

Методология физического проектирования баз данных включа­ет четыре основных этапа:

1. Разработка таблиц базы дан­ных и установка необходимых ограничений целостности данных.

2. Выбор схемы хранения данных и определение методов доступа к таблицам базы данных. Как правило, каждая СУБД предоставляет несколько альтернативных вариантов схемы хранения данных. Исключением являются лишь на­стольные СУБД для платформы IBM PC, в которых чаще всего используется фикси­рованная схема хранения информации. С точки зрения пользователя организация внутренней структуры хранения помещенных в таблицы данных должна быть со­вершенно прозрачна – пользователь должен иметь возможность получать доступ к любой таблице и отдельным ее строкам без необходимости указания способа хране­ния этих данных. Это означает, что СУБД должна обеспечивать полную независи­мость физического хранения данных от их логической организации. Только в этом случае внесение изменений в физическую организацию базы данных не окажет ни­какого влияния на работу пользователей. Отображение логической модели данных на структуру их физической организации определяется внутренней схемой базы данных.

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

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

ВВЕДЕНИЕ В РЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ

Реляционные базы данных

Реляционная модель впервые была предложена Э.Ф.Коддом (E.F.Codd) в 1970 году в его основополагающей статье “Реляционная модель данных для больших совместно ис­пользуемых банков данных”. В настоящее время публикацию этой статьи принято считать поворотным пунктом в истории развития систем баз данных. Цели создания реляционной модели формулировались следующим образом:

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

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

• расширение языков управления данными за счет включения операций над множествами.

Хотя интерес к реляционной модели обусловлен несколькими разными причина­ми, все же наиболее значительные исследования были проведены в рамках трех про­ектов с очень разной судьбой. Первый из них разрабатывался в конце 70-х годов в исследовательской лаборатории корпорации IBM в городе Сан-Хосе, штат Калифор­ния, под руководством Астрахана (Astrahan), результатом которого стало создание системы под названием “System R”, являвшейся прототипом истинной реляционной СУБД (РСУБД). Этот проект был задуман с целью получить реальные доказательства прак­тичности использования реляционной модели посредством реализации предусматри­ваемых ею структур данных и операций. Этот проект также зарекомендовал себя как важнейший источник информации о таких проблемах реализации, как управление параллельностью, оптимизация запросов, управление транзакциями, обеспечение безопасности и целостности данных, технология восстановления, учет человеческого фактора и разработка пользовательского интерфейса. Выполнение проекта стимули­ровало публикацию многих научно-исследовательских статей и создание других про­тотипов РСУБД. В частности, работа над проектом System R дала толчок проведению таких важнейших разработок, как создание языка структурированных запросов SQL, который с тех пор приобрел статус формального стандарта ISO (International Organization for Standardization) и в настоящее время явля­ется фактическим отраслевым стандартом языка РСУБД, а также создание различных коммерческих РСУБД, которые впервые появились на рынке в начале 80-х годов (DB2 и SQL/DS корпо­рации IBM, а также ORACLE корпорации ORACLE Corporation).

Вторым проектом, который сыграл заметную роль в разработке реляционной мо­дели данных, был проект INGRES (INteractive GRaphics REtrieval System), работа над которым проводилась в Калифорнийском университете (город Беркли) почти в то же самое время, что и над проектом System R. Проект INGRES включал разработку прототипа РСУБД с концентрацией основного внимания на тех же общих целях, что и проект System R. Эти исследования привели к появлению академической версии INGRES, которая внесла существенный вклад в общее признание реляционной моде­ли данных.

Третьим проектом была система Peterlee Relational Test Vehicle научного центра корпорации IBM, расположенного в городе Петерли, Великобритания (Todd, 1976). Этот проект был более теоретическим, чем проекты System R и INGRES. Его резуль­таты имели очень большое и даже принципиальное значение, особенно в таких об­ластях, как обработка запросов и оптимизация, а также функциональные расшире­ния системы.

Коммерческие системы на основе реляционной модели данных начали появляться в конце 70-х – начале 80-х годов. В настоящее время существует несколько сотен ти­пов различных РСУБД как для мейнфреймов, так и для микрокомпью­теров, хотя многие из них не полностью удовлетворяют точному определению реля­ционной модели данных. Примерами РСУБД для персональных компьютеров являются СУБД Access и FoxPro фирмы Microsoft, Paradox и Visual dBase фирмы Borland, а также R:Base фирмы Microrim.

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

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