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

Введение

 

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

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

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

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

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

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

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

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

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

 

 

1. Основные понятия БД и СУБД

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

Фиксация данных традиционно происходит через конкретные средства общения - естественного языка или изображений, на конкретном носителе: камне или  бумаге. Учитывая тот факт, что естественный язык обладает достаточной гибкостью, данные и их интерпретация (семантика) фиксируются совместно. Например, рассмотрим утверждение "Стоимость билета на электричку 147". Здесь "147" –  данное, а "Стоимость билета на электричку" – его семантика.

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

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

Существуют как минимум две  исторические причины, способствующие тому, что активное использование  ЭВМ способствовало тому, что произошло  разделение данных и интерпретации:

- ЭВМ не имело достаточных  возможностей, чтобы обрабатывать  тексты на естественном языке  - основном языке интерпретации  данных;

- высокая стоимость памяти ЭВМ. 

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

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

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

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

Архитектура СУБД

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

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

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

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

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

понятные всем людям, работающим над  проектированием базы данных. Такое  описание называется инфологической моделью  данных (см. Рисунок 1).

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

 

Рисунок 1 Уровни моделей данных

 

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

Осуществление доступа происходит при помощи конкретной СУБД, поэтому  описание моделей должно происходить  на языке описания данных этой СУБД².

Это описание создается АБД по инфологической модели данных и называется даталогической моделью данных.

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

Модели данных

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

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

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

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

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

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

2. Реляционный подход

 

Еще в конце 60-х годов стали  появляться работы, в которых обсуждались  возможности применения различных  табличных даталогических моделей данных. Особый интерес вызвала статья сотрудника фирмы IBM д-ра Э.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), в которой впервые был применен термин "реляционная модель данных".

Так как Э. Кодд по образованию был  математиком, он предложил для обработки  данных использовать аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Ему удалось  показать, что любое представление  данных сводится к совокупности двумерных  таблиц особого вида, известного в  математике как отношение – relation (англ.) [6,7].