Физические модели баз данных реферат

Обновлено: 30.06.2024

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

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

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

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

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

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

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

Рекомендуемые материалы

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

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

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

В устройствах с последовательным доступом для получения доступа к некоторому элементу требуется "перемотать (пройти)" все предшествующие ему элементы информации. На устройствах с последовательным доступом вся память рассматривается как линейная последовательность информационных элементов (см. рис. 9.3).

Рис. 9.2. Файл как линейная последовательность записей

Рис. 9.3. Модель хранения информации на устройстве последовательного доступа

Файлы с постоянной длиной записи, расположенные на устройствах прямого доступа (УПД), являются файлами прямого доступа.

В этих файлах физический адрес расположения нужной записи может быть вычислен по номеру записи (NZ).

Каждая файловая система СУФ — система управления файлами поддерживает некоторую иерархическую файловую структуру, включающую чаще всего неограниченное количество уровней иерархии в представлении внешней памяти (см. рис. 9.4).

Для каждого файла в системе хранится следующая информация:

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

Рис. 9.4. Иерархическая организация файловой структуры хранения

Для файлов с постоянной длиной записи адрес размещения записи с номером K может быть вычислен по формуле:

где ВА — базовый адрес, LZ — длина записи.

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

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

Файлы с переменной длиной записи всегда являются файлами последовательного доступа. Они могут быть организованы двумя способами:

1. Конец записи отличается специальным маркером.

2. В начале каждой записи записывается ее длина.

3. Здесь LZN — длина N-й записи.

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

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

где NZ — номер записи, K — значение ключа, F( ) — функция.

Функция F() при этом должна быть линейной, чтобы обеспечивать однозначное соответствие (см. рис. 9.5).

Рис. 9.5. Пример линейной функции пересчета значения ключа в номер записи

Однако далеко не всегда удается построить взаимно-однозначное соответствие между значениями ключа и номерами записей.

Часто бывает, что значения ключей разбросаны по нескольким диапазонам (см. рис. 9.6).

Рис. 9.6. Допустимые значения ключа

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

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

Поэтому при использовании хэширования как метода доступа необходимо принять два независимых решения:

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

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

Стратегия разрешения коллизий с областью переполнения

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

основную область;
область переполнения.

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

Содержание записей

Ссылка на синонимы

Содержание записей

Ссылка на синонимы

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

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

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

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

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

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

Организация стратегии свободного замещения

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

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

После перемещения "незаконной" записи вновь вносимая запись занимает свое законное место и становится первой записью в новой цепочке синонимов.

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

Если удаляемая запись является первой записью в цепочке синонимов, то после удаления на ее место перемещается следующая (вторая) запись из цепочки синонимов и проводится соответствующая корректировка указателя третьей записи в цепочке синонимов, если таковая существует.

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

Вопросы для самостоятельной работы

1. Сравнить обе стратегии и определить, какая из них будет наиболее перспективной и в каких случаях.

2. Разработать алгоритмы удаления записей для первой и второй стратегий. Показать, как определяются ссылки.

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

При проектировании структур д анн ых для автоматизированных систем

1. Сбор информации об объектах решаемой задачи в рамках одной таблицы

(одного отношения) и последующая декомпозиция ее на несколько

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

2. Формулирование знаний о системе (определение типов исходных данных и

их взаимосвязей) и требований к обработке данных, получение с помощью CASE-

систе-мы (системы автоматизации проектирования и разработки баз данных)

готовой схемы БД или даже готовой прикладной информационной системы.

3. Ст руктурирование информации для использования в информационной

системе в процессе проведения систем ного анализа на основе совокупности

Базы данных— это компьютеризированная система хранения записей, т.е.

компьютеризированная система, основное назначение которой — хранить

информацию, предоставляя пользователям средства ее извлечения и модифика -

ции. К информ ации может относиться все, что заслуживает внимания отдельного

пользователя или организации, использующей систему, иначе г оворя, все

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

На рис. 1 показана весьма упрошенная схема системы баз данных. Здесь

отражено четыре главных компонента системы, а именно: данные, аппаратное

обеспечение, программное обеспечение и пользователи. Каждый из этих

Системы с базами данных существуют как на самых малых компьютерах, так

и на крупнейших мэйнфреймах. Нет необходимости говорить, что

предоставляемые каж дой конкретной системой средства в некоторой мере зависят

от мощности и возможностей базовой машины. В частности, системы на больших

машинах ("большие системы"), в основном, многопользовательские, тогда как

системы на малых машинах ("малые сис темы"), как правило,

однопользовательские. Однопользоват ельская система ( single-user system) — это

система, в которой одновременно к базе данных может по лучить доступ не более

одного пользователя, а многопользовательская систем а ( multi-user system) — это

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

пользователей. Как и в схем е на рис. 1, исходя из соображений общности, мы

обычно будем подразумевать именно второй вид систем, хотя, с точки зрения

пользователей, между этими системами фактически не существует большого

различия. Основная задача большинства многопользовательских систем—

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

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

систем проявляются в их внутренней структуре, и потому практически не видны

К аппаратному обеспечению системы относится следующее.

• Тома вторичной (внешней) памяти (обычно это магнитные диски),

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

ввода-вывода (дисководы и т.п.), контроллеры устройств, каналы ввода-вывода и

• Аппаратный процессор (или процессоры) вместе с основной (первичной)

памятью, предназначенные для поддержки работы программного обеспечения

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

хранятся) и пользователями сист емы располагает ся уровень программного

обеспечения, который можно называть по-разному: менеджер базы данных

(database manager), сервер базы данных (database server) или, что более

привычно, система управления базами данных, СУБД (database management

system — DBM S). Все запросы пользо вателей на доступ к базе данных

обрабатываются СУБД. Все имеющиеся средства до бавления файлов (или

таблиц), выборки и обновления данных в этих файлах или таб лицах также

предоставляет СУБД. Основная задача СУБД — предоставить пользова телю базы

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

обеспечения. ( Пользователь СУБД более отстранен от этих деталей, чем при -

кладной программист, применяющий языковую среду программирования.)

Иными словами, СУБД позволяет конечному пользователю рассматривать базу

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

обеспечением, а также предоставляет в его распоряжение набор операций,

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

Пользователей можно разделить на три большие и отчасти перекрывающиеся

• Первая группа — прикладные программисты , которые отвечают за

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

применимы такие языки, как COBOL, PL/I, C++, Java или какой-нибудь

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

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

• Вторая группа — конечные п ользо ватели , которые работают с системой

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

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

интерактивных приложений, упомянутых выше, или же интерфейс,

интегрированный в про граммное обеспечение самой СУБД. Безусловно,

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

однако эти приложения не создаются пользователями-программистами, а

являются встроенным и в СУБД. Большин ство СУБД включает по крайней мере

одно такое встроенное приложение, а именно — процессор языка запросов,

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

(их часто иначе называют операторами (statement) или командами ( commands)),

например S ELECT или INSERT. Язык SQL — типичный пример языка запросов

Структурой системы называется её расчленение на группы элементов с

указанием связей между ними, неизменное на всё время рассмотрения и дающее

представление о системе в целом. Иначе можно сказать, что структура это

множество элементов и связей м ежду ними, принадлежащее определённому

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

упрощение системы, слишком сложной для рассмотрения целиком.

Архитектура ANSI/SPARC включает три уровня: внутренний, внешний и

концептуальный (рис. 2). В общих чертах они представляют собой следующее.

• Внутренний уро вень (также называемый физическим) наиболее близок к

физическому хранилищу информации, т.е. связан со способ ами сохранения

• Внешний уро вень (также называемый пользовательским логическим)

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

• Концептуальный уровень (также называемый общим логическим или

просто логическим) является "промежуточным" уровнем между двумя первыми.

Если внешний уровень связан с индивидуальными представлениями

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

пользователей. Иначе говоря , может существовать несколько внешних

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

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

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

(Вспомните, что большинство пользователей интересует не вся база данных, а

лишь ее некоторая ограниченная часть.) Также существует единственное

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

Для лучшего понимания этих идей рассмотрим пример, представленный на

рис. 3. Здесь отображено концептуальное представление простой базы данных о

персонале, а также соответствующие ему внутреннее и два внешних

представления (одно — для поль зователя, прим еняющего язык PL/I, а другое —

для пользователя, применяющего язык COBOL). Конечно, этот пример полностью

гипотетичен и мало похож на реальные сис темы, поскольку в нем умышленно

Рис. 3 Пример трех уровней представления базы данных

Рассматриваемый здесь пример нуждается в пояснениях.

 На концептуальном уровне база данных содержит информацию о типе

сущности с именем EMPLOYEE (служащий). Каждый экземпляр

сущности EMPLOYEE включает атрибуты номера служащего

EMPLOYEE_NUMBER (длиной шесть символов), номера отдела

DEPARTMENT_NUMBER (длиной четыре символа) и зарплаты

 На внутреннем уровне служащие представлены типом хранимой

записи STORED_EMP, длина которой составляет 20 байт. Запись

STORED_EMP содержит че тыре хранимых поля: шестибайтовый префикс

(возможно, содержащий управляющую информацию, такую как флаги или

указатели) и три поля данных, соот ветствующие трем свойствам

сущности, которая представляет служащего. Кроме того, записи STORED

 Пользователь, применяющий язык PL /I, имеет дело с соответствующим

внешним представлением базы данных. В нем каждый сотрудник

представлен записью на языке PL/I, содержащей два поля (номера отделов

не представляют интереса для данного пользователя, поэтому в

представлении они опущены ). Тип записи определен с помощью обычной

 Аналогично пользователь, прим еняющий язык COBOL, имеет дело с

собственным внешним представлением базы данных, в котором каждый

сотрудник представлен записью на языке COBOL, содержащей, опять ж е,

два поля (в данном случае опущен размер оклада). Тип записи определен с

помощью обычного описания на языке COBOL в соответствии с

Нужно обратить внимание, что в каждом случае соответствующие элементы

данных могут меть различные им ена. Например, к номеру сотрудника

обращаются, как к полю EMPt в представлении для языка PL/I и как к полю

EMPNO в представлении для языка COBOL. Этот же атрибут в концептуальном

представлении имеет имя E MP LOYEE_NUMBER, а во внутреннем представлении

Например, она должна знать, что поле EMPNO в представлении для языка

COBOL образовано из концептуального поля EMPLOYEE NUMBER, которое, в

Такие соответствия, или отображения, явно не показаны на рис. 3.

В данном случае не имеет особого значения, является ли рассматриваемая

Внешний уровень — это индивидуальный уровень пользователя. Как было

сказано главе 1, пользователь может быть прикладным программистом или

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

(Особое место среди пользователей занимает адм инистратор базы данных (АБД).

В отличие от остальных пользователей, АБД интересует также концептуальный и

внутренний уровни. Об этом еще будет говориться в следующих двух разделах.)

 Для прикладного программиста это либо один из распространенных

языков программирования (например, PL/I, C++ или Java), либо

специальный язык рассматриваемой системы. Такие оригинальные языки

называют языками четвертого поколения на том (не вполне

определенном!) основании, что машинный код, язык ассемблера и такие

языки, как PL /I, можно считать языками трех первых "поколений", а

оригинальные языки модернизированы по сравнению с языкам третьего

поколения так же, как языки третьего поколения улучшены по сравнению

 Для конечного пользователя это или специальный язык запросов, или язык

специального назначения, который может быть основан на использовании

форм и меню, разработан специально с учетом требований пол ьзователя и

интерактивно поддерживаться некоторым оперативным приложением.

Для нашего обсуждения важно, что все эти языки включают подъязык

данных, т.е. подмножество операторов всего языка, связанное только с

объектами баз дан ных и операциям и с ними. Иначе говоря, подъязык данных

встроен в базовый язык, который дополнительно обеспечивает различные не

связанные с базами дан ных возможности (такие, как локальные (временные)

переменные, вычислительные операции, логические операции и т.д.). Система

может поддерживать любое количе ство базовых языков и любое количество

подъязыков данных. Однако существует один язык, который поддерживается

практически всеми сегодняшними систем ами. Это язык SQL. Большинство систем

позволяет использовать язык SQL и интерактивно, как самостоятельный язык

запросов, и посредством внедрения его операторов в другие языки

Хотя с точки зрения архитектуры удобно различать подъязык данных и

включающий его базовый язык, на практике они могут быть неразличимы

настолько, насколько это имеет отношение к пользователю. Безусловно, с точки

зрения пользователя пред почтительнее, чтобы они были неразличимы. Е сли они

неразличимы или трудноразли чимы, их называют сильно связанными. Если они

ясно и легко различаются, говорят, что эти языки сл або связ аны. В то время как

некоторые коммерческие. системы (особенно объектные системы) поддерживают

сильную связь, большин ство систем, в частности системы SQL, обычно

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

предоставить пользователю более унифициро ванный набор возможностей, но,

очевидно, они требуют боль ше усилий со стороны системных проектировщиков и

разработчиков, которые, вероятно, рассчитывают на сохранение статус-кво.

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

по крайней мере двух подчиненных языков — языка определения данных (data

definition language — DDL), который поддерживает определения или объявления

объектов базы данных, и языка обработки да нных (data manipulation language —

DML), который поддерживает операции с такими объектами или их обработку.

Например, рассмотрим пользователя языка PL/I (см. рис. 3). Подъязык данных

этого пользователя включает определенные средства языка PL/I, применяемые

 Язык определения данных включает некоторые описательные структуры

языка PL/I, необходимые для объявления объектов базы данных. Это сам

оператор DECLARE (DCL), определенные типы данных языка PL/I, а также

возможные специальные дополнения для языка PL/I , предназначенные для

поддержки новых объектов, которые не поддерживаются существующей

Язык обработки данных состоит из тех выполняемых операторов языка PL/

I, которые передают информацию в базу данных и из нее; опять же,

Отдельного пользователя интересу ет лишь некоторая часть всей базы

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

чем-то абстрактным по сравнению с выбранным способом физического хранения

данных. В соответствии с терминологией ANSI/SPARC представление отдельного

пользователя называется внешним представлением. Таким образом, внешнее

представление— это содержимое базы данных, каким его видит определенный

пользователь (т.е. для каждого пользователя знешнее представление и есть та

база данных, с которой он работает). Например, пользователь из отдела кадров

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

плюс набор записей с информацией о служащих и ничего не знать о записях с

информацией о материалах и их поставщиках, с которыми рабо тают пользователи

В общем случае внешнее представление состоит из некоторого множества

экземпляров каждого из м ногих типов внешних записей (которые вовсе не

обязательно должны совпадать с хранимыми записями). Предоставляемый в

распоряжение пользователя подъязык данных всегда определяется в терминах

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

осуществляет выборку экземпляров внешних, а не хранимых записей.

Каждое внешнее представление определяется посредством внешн е й схемы,

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

вующих в этом внешнем представлении (см. рис. 3). Внешняя схема записывает ся

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

данных пользователя. (Поэтому язык определения данных иногда называют

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

ке можно определить как шестисим вольное поле с номером работника, плюс поле

из пяти десятичных цифр, предназначенное для его зарплаты, и т.д. Кроме того,

может потребоваться определить отображен ие между внешней и исходной

Рис. 4 Детальная схема архитектуры системы баз данных

Концептуальное представление — это представление всей информации

базы данных в несколько более абстрактной форме (как и в случае внешнего

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

концептуальное представление существенно отличается от представления данных

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

представление — это представление данных такими, какими они являются на

самом деле, а не такими, какими их вынужден видеть пользователь в рамках,

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

Концептуальное представление состоит из некоторого множества

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

Например, оно может состоять из набора экземпляров записей, содержащих

информацию об отделах, набора экземпляров записей, содержащих инф ор мацию

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

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

Физическая модель строится на основе логической с учетом ограничений, накладываемых возможностями выбранной СУБД (в данном случае - MS SQL Server 2012).

Имена

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

Типы данных

Для каждого атрибута необходимо определить тип данных его значений (табл. 2.2).

Связи

Приведенные три варианта физической модели различаются способами реализации наследования:

- миграция первичного ключа и неключевых атрибутов в иерархии от потомков к предку (рис. 2.11);

- миграция первичного ключа и неключевых атрибутов в иерархии от предка к потомкам (рис. 2.12);

- замена иерархии наследования идентифицирующими связями (рис. 2.13).

Рис. 2.11. Физическая модель базы данных: реализация наследования через миграцию потомков в предка

Рис. 2.12. Физическая модель базы данных: реализация наследования через миграцию предка в потомков

Рис. 2.13. Физическая модель базы данных: реализация наследования через замену иерархии идентифицирующими связями

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

Контрольные вопросы

1. Дайте определение реляционной модели базы данных.

2. Какие ограничения целостности поддерживаются на уровне реляционной модели?

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

4. Что такое первичный ключ нормализованного отношения? Определите свойства первичного ключа.

5. Как реализуются связи между сущностями в реляционной модели?

6. Что такое логическая модель базы данных?

7. Что такое физическая модель базы данных?

9. Какие отношения допустимы в нотации IDEF1X?

10. Каким образом определяется степень связи в нотации IDEF1X?

11. Какие отношения между сущностями отсутствуют в физической модели базы данных в нотации IDEF1X?

12. Как реализуется отображение ассоциативных связей из концептуальной модели ПО в реляционную модель БД?

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

16. Какие варианты реализации наследования на уровне физической модели базы данных существуют?

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

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

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

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

2. БАЗЫ ДАННЫХ И СИСТЕМЫ УПРАВЛЕНИЯ ИМИ

2.1. Базы данных

Цель любой информационной системы – обработка данных об объектах реального мира. Основные идеи современной информационной технологии базируются на концепции баз данных (БД).

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

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

Первые БД появились уже на заре 1-го поколен ия ЭВМ представляя собой отдельные файлы данных или их простые coвокупности.

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

Структурирование - это введение соглашений о способах представления данных.

Неструктурированными называют данные, записанные, например, в текстовом файле.

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

2.1. Структурные элементы базы данных

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

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

имя, например. Фамилия, Имя, Отчество, Дата рождения;
тип, например, символьный, числовой, календарный;
длина, например, 15 байт, причем будет определяться максимально возможным количеством символов;
точность для числовых данных, например два десятичных знака для отображения дробной части числа.

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

Файл (таблица) - совокупность экземпляров записей одной структуры.

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

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

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

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

Первые СУБД, поддерживающие opганизацию и ведение БД, появились в конце 60-х годов.

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

3. МОДЕЛИ ДАННЫХ И ИХ ВИДЫ

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

Модель данных - совокупность структур данных и операций их обработки.

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

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

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

4. ИЕРАРХИЧЕСКАЯ МОДЕЛЬ ДАННЫХ

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

К основным понятиям иерархической структуры относятся: уровень, элемент (узел), связь.

Узел - это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину (корень дерева), не подчиненную никакой другой вершине и находящуюся на самом верхнем (первом) уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т.д. уровнях. Количество деревьев в базе данных определяется числом корневых записей.

К каждой записи базы данных существует только один (иерархический) путь от корневой записи.

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

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

База данных (БД) — именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области,

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

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

Краткие характеристики персонального компьютера и программного обеспечения, использованных для выполнения и оформления данной работы: процессор: Intel 3,3 Ггц / оперативная память -2 Гб/ HDD – 500 Гб/ видеокарта – ATI HD5770 1024Мб/ DVD +/- RW / клавиатура / мышь/ ОС Windows Vista / Microsoft Office 2010: Word, Excel/.

II. Теоретическая часть

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

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

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

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

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

Рис 1.1. Система с базой данных

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

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

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

Таким образом, СУБД обеспечивает следующие возможности:

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

Система с базой данных состоит из следующих компонентов.

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

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

Таким образом, систему с базой данных можно представить в виде последовательности уровней (рис. 1.2).

Рис. 1.2. Уровни системы с базой данных

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

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

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

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

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

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

Представление данных - это отображение данных в базе данных (на концептуальном уровне), которое необходимо конкретному приложению. Одно и то же множество объектов базы данных может отображаться в различные представления. Описание соответствия между представлением и множеством объектов базы данных называется его определением. Все определения представлений хранятся в словаре данных и становятся полноправными объектами базы данных. Это дает возможность нескольким приложениям использовать одно и то же представление. Множество всех определений представлений образуют так называемый внешний уровень базы данных — интерфейс между базой данных и ее пользователями. Если концептуальная схема базы данных модифицируется, то все определения представлений, затронутых этой модификацией, необходимо будет переписать так, чтобы представление осталось для своих пользователей неизменным даже в том случае, если оно теперь основывается на совершенно иной части логической базы данных. Таким образом, приложения отстраняются от модификации базы данных на логическом уровне. Это называется логической независимостью данных.

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

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

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

Рис. 1.3. Уровни СУБД

2.2. Типы баз данных

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

Иерархические базы данных:

В 1968 году компания IBM предложила своим клиентам систему управления информацией (IMS). В IMS база данных была концептуально представлена в виде иерархии. Записи были организованы в наборы, которые связывались друг с другом связями.

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

Сетевые базы данных:

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

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

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

Реляционная модель базы данных была впервые предложена Коддом в 1970 году. Она существенно отличалась от описанных ранее моделей и в 80-х получила всеобщее признание как наиболее согласованная и удобная модель разработки СУБД.

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

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

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

Объектно-ориентированные базы данных:

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

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

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

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

2.3. Вывод

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

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

III. Практическая часть

3.1. Содержание задачи

Рассмотрим задачу. Вариант 5.

Читайте также: