Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Базы Данных - Сибилев, 2007

.pdf
Скачиваний:
290
Добавлен:
11.05.2015
Размер:
1.93 Mб
Скачать

31

Описания этих структур (метаданные) можно представить экземпля-

рами структур такого же типа. Можно даже сказать, сколько таких струк-

тур необходимо для хранения информации о логических структурах дан-

ных пользователей, и как должны быть устроены эти структуры. Оказыва-

ется, можно обойтись двумя: одна — для описаний таблиц в целом, а вто-

рая — для описаний свойств столбцов.

TABLE{TabName, Columns, Rows, File,…};

COLUMN{ColName, TabName, Type, Length,…};

Описание таблицы ТОВАР могло бы состоять из одной записи в таб-

лице TABLE:

 

 

 

ТОВАР

4 7000

Goods

и, скажем, четырёх записей в таблице COLUMN:

штрих-код

ТОВАР

String

20

наименование

ТОВАР

String

60

ед.измерения

ТОВАР

String

5

цена

ТОВАР

Float

 

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

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

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

сать прикладные программы, содержащие только ссылки логического уровня;

во-вторых, программа-сервер сможет использовать эти описания при обработке запросов ПП – клиентов.

Поясним, как это могло бы выглядеть (см. рис. 3.2). Пусть приклад-

ной программе понадобились наименование и цена товара с кодом ‘1234’.

Она обращается к серверу с запросом на некоем языке:

ВЫБРАТЬ наименование, цена ИЗ ТОВАР ГДЕ штрих-код=’1234’;

32

Получив запрос, сервер выполняет его анализ. Прежде всего, он вы-

ясняет, что ПП требует данные из таблицы ТОВАР. Он сканирует таблицу

TABLE и находит в ней следующую строку:

ТОВАР 4 7000 GOODS

Здесь он находит информацию о том, что упомянутая в запросе таб-

лица хранится в файле GOODS и загружает этот файл в свой рабочий бу-

фер. В буфере он структурирует загруженные физические записи и создаёт логические. Для этого нужно

— выбрать все строки таблицы COLUMN, содержащие значение

ТОВАР в поле TabName.

— основываясь на содержимом этих строк, восстановить описание структуры таблицы ТОВАР.

Теперь осталось просканировать буфер и найти строку таблицы

ТОВАР, содержащую указанное значение поля штрих-код, а затем счи-

тать из неё значения полей наименование и цена, и отправить их в рабо-

чий буфер программы-клиента.

Такова идея. В её реализации масса деталей, о которых мы пока не говорим.

Важный момент.

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

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

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

конкретного предприятия. Её можно настроить на конкретное предпри-

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

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

3.2 Дополнительные задачи программы-сервера

Итак, главная задача программы-сервера — обеспечить прикладным программам доступ к данным на логическом уровне. Это снимает проблему зависимости прикладных программ от данных. Однако, помимо этой зада-

33

чи, на сервер можно возложить и другие, не менее важные. Я их перечис-

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

1. Контроль согласованности (целостности) данных при выполне-

нии операций обновления данных — добавления/удаления записей, изме-

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

2. Управление многопользовательским доступом к данным. Набор записей предприятия доступен всем прикладным программам. Нередко одни и те же данные требуются одновременно нескольким ПП. Если неко-

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

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

3. Защита данных от несанкционированного доступа. Операцион-

ные системы вообще не имели таких механизмов в конце 60-х — начале

70-х годов прошлого века. А проблема имелась. Любой достаточно квали-

фицированный и злонамеренный человек мог забраться в любой файл дан-

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

4. Защита данных от разрушений вследствие аварий. Под разруше-

ниями данных понимается нарушение целостности, утрата фрагмента дан-

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

нуться катастрофой для владельца данных.

5. Поддержка среды разработки прикладных программ и обслужи-

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

34

служивающим информационную систему было бы удобно иметь такие средства.

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

ными.

Во первой половине 60-х годов прошлого века в США начались раз-

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

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

живающие все перечисленные функции (Oracle, MS SQL Server, Ingress,…)

и СУБД с ограниченным набором функций (MySQL). Существуют ком-

мерческие продукты такого типа и свободно распространяемые. Сущест-

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

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

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

3.3 Классификация СБД

СБД

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Типы хранимой

информации

 

 

 

 

 

 

Организация доступа

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Фактографи-

 

 

Докумен-

 

Мульти-

 

 

 

 

 

Локальный

 

 

Распределённый

 

 

 

 

ческие

 

 

тальные

 

 

медиа

 

 

 

 

 

доступ

 

 

 

доступ

 

 

Тип обработки данных

 

 

Число пользователей

 

Локализация

данных

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Оперативная

 

 

 

Оперативный

 

 

 

Одно-

 

 

Много-

 

 

 

Централизо-

 

 

 

Распреде-

обработка

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

пользова-

 

пользова-

 

 

 

 

ванное

 

 

 

лённое

 

 

 

анализ данных

 

 

 

 

 

 

 

 

 

 

 

транзакций

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

тельские

 

тельские

 

 

 

хранение

 

 

 

хранение

 

 

 

 

(OLAP)

 

 

 

 

 

 

 

 

 

 

(OLTP)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис. 3.3 Классы систем с базами данных.

35

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

3.4 Основные понятия и термины

3.4.1 Предметная область

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

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

ния об объектах и отношениях объектов, попадающих в сферу деятельно-

сти.

База данных больницы содержит записи о врачах, отделениях, паци-

ентах, палатах, размещении больных в палатах,…

База данных банка — это записи о клиентах, их счетах, выданных им кредитах, операциях по счетам,…

База данных меломана — записи об альбомах, исполнителях, произ-

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

бителя музыки.

Всё это — сведения о части реального мира, представляющей инте-

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

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

(ПО) базы данных.

3.4.2 Понятие базы данных в информатике

База данных действительно полезна для владельца, если она

36

— содержит всю необходимую с точки зрения владельца информа-

цию о предметной области и

— обеспечивает возможность упорядочивать информацию по раз-

личным признакам и быстро извлекать выборку с произвольным сочета-

нием признаков.

Для того чтобы это было возможно, данные (независимо от способов хранения!) структурируют, выделяют поисковые признаки и создают не-

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

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

Например, в отделе кадров предприятия хранятся личные карточки сотрудников. Бланк карточки — это структура (тип записи), отражающая представление инспектора отдела кадров об абстрактном сотруднике. Поля бланка — это свойства сотрудника, которыми инспектор ОК должен инте-

ресоваться в силу своих служебных обязанностей. Заполненный бланк, со-

держащий сведения о сотруднике Иванове, — это и есть сотрудник Иванов в представлении инспектора ОК.

Карточка содержит простые поля, такие как Фамилия, Имя, Отче-

ство. Она содержит также поля-структуры. Например, Занимаемые должности{дата, _приказа, должность, отдел}.

В этой подструктуре поле №_приказа имеет смысл ссылки на хра-

нящийся в ОК документ (запись), обосновывающий перемещение сотруд-

ника, а поле отдел – смысл ссылки на запись о подразделении предпри-

ятия, в котором работал(ет) сотрудник.

Итак, база данных отражает представления владельца о предметной области, является её моделью. Она выделяет те аспекты ПО, которые инте-

ресуют владельца.

37

В предметной области происходят события, изменяющие её состоя-

ние. Появляются новые экземпляры объектов и отношений, исчезают су-

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

Эти события отражаются на состоянии базы данных. Создаются или уда-

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

Таким образом, БД – это динамическая модель. Её состояние в каж-

дый момент времени отражает текущее состояние ПО.

3.4.3 Определение термина «база данных»

До сих пор мы довольствовались интуитивным пониманием термина

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

Компьютерная БД отличается от любого другого набора записей тем,

что наряду с данными пользователей содержит своё собственное описа-

ние. В информатике принято следующее определение термина:

База данных (БД) — это самодокументированная интегрированная совокупность записей.

Самодокументированность означает, что вместе с данными пользо-

вателей в БД содержится описание её собственной структуры.

Это описание называется метаданными. Метаданные сохраняются в специальном разделе БД. Он называется каталогом данных или, что то же самое, словарём данных. Самодокументированность — важнейшее свойст-

во БД. Все сведения о ресурсах данных можно получить из словаря дан-

ных. Не нужно изучать определения данных по какой-то внешней доку-

ментации и воспроизводить их в прикладных программах. Кроме того, ес-

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

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

38

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

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

Интегрированность означает, что БД наряду с записями пользовате-

лей содержит сведения о связях записей.

Обычно связи записей представляют индексами. Индекс – это слу-

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

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

Кроме индексов многие современные системы сохраняют в БД ме-

таданные приложений. Это определения структур форм ввода данных и отчётов и т.п.

Иерархия элементов и структур данных в БД схематически пред-

ставлена ниже на рис. 3.4.

Биты → Байты → Поля → Записи → Файлы

+

Метаданные

+

Индексы → База данных

+

Метаданные

приложений

Рис. 3.4. Иерархия элементов и структур данных в БД

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

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

разделений. Однако, в отличие от ФСОД, все эти БД подчинены единому управлению.

3.4.4 Система управления базами данных (СУБД)

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

вателей к данным осуществляется в СБД централизованно с помощью

39

специальных программных средств — системы управления базами дан-

ных.

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

3.5 Система баз данных (СБД)

3.5.1 Компоненты СБД

База данных и СУБД образуют ядро системы баз данных (СБД). По-

мимо БД и СУБД в систему включаются

аппаратура,

приложения,

документация и

пользователи.

Система баз данных — это человеко-машинная система, предна-

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

СБД является центральным хранилищем информации предприятия и,

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

давая для каждого из них иллюзию индивидуальной работы.

Схематически компоненты СБД представлены на рис. 3.5. Обсудим этот рисунок.

 

 

40

 

 

 

 

СУБД

Прикладные

 

 

 

программисты

 

 

Подсистема проектирования

 

 

БД

Я

(Языковые средства)

Приложения

 

 

д

Языки определения данных

 

 

 

 

Данные

р

Языки манипулирования данными

 

 

конечных

Языки программирования

 

 

о

Докумен

АБД

пользователей

 

 

 

тация

 

Метаданные

 

Подсистема обработки

 

 

Индексы

С Процессор форм

Приложения

 

У

Процессор запросов

 

 

 

 

 

Метаданные

 

Генератор отчётов

 

 

Б Процедурные средства обработки

 

 

приложений

 

 

 

Д

 

Конечные

 

 

 

 

пользователи

 

Техническая платформа

 

 

Рис. 3.5 Компоненты СБД

3.5.2 Пользователи СБД

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

Конечные пользователи (КП) – работники предприятия, исполь-

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

КП не имеет специальных знаний и навыков в области компьютерных тех-

нологий обработки данных.

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

набор служебных обязанностей (функций).

Как правило, КП не имеет прямого доступа к БД организации. Это ограничение обусловлено, прежде всего, требованиями безопасности дан-

ных. Для каждого КП создаётся прикладная программа (приложение), под-

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

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