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

9.1. Основные понятия

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

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

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

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

Объекты [Код об, Объект],

Работы [Код раб, Работа],

Организации [Код орг, Организация, Индекс, Город, Адрес, Телефон, Факс, Эл почта]

и собственно таблицу для учета затрат

Затраты [Код затр, Затрата, Код об, Код раб, Код орг, Дата, Стоимость].

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

Ключевые поля служат также для связывания таблиц. Например, таблица Затраты может содержать множество записей, в которых указан код одной и той же организации-подрядчика. Предположим, одна и та же организация проектировала и строила мост, подъездную дорогу, трансформаторную подстанцию и, возможно, другие объекты. При обработке записей таблицы Затраты может потребоваться факс этой организации – его легко найти в таблице Организации, которая должна содержать единственную запись с требуемым нам кодом организации в поле Код орг. Связь между этими таблицами называется связью «один ко многим» (1  ): ссылка на одну запись в таблице Организации содержится во многих записях таблицы Затраты. Если бы мы ввели еще одну таблицу – Банковские реквизиты, в которой для каждой организации-подрядчика указали бы ее код, название банка, номера счетов и другие данные, используемые при оформлении платежей, то связь между этой таблицей и таблицей Организации была бы связью «один к одному» (1  1), т.к. в этих таблицах есть только по одной записи с одним и тем же значением ключевого поля Код орг. В некоторых ситуациях ключ может состоять из двух-трех полей и тогда он называется составным. Например, подразделение может идентифицироваться номером цеха и номером бригады в данном цехе, точка геофизических измерений может идентифицироваться номером профиля и номером точки на этом профиле и т.п.

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

Итак, в нашем примере база данных охватывает несколько взаимосвязанных таблиц «объекты-свойства». Такие базы данных называются реляционными. Это понятие (relation – отношение) было введено известным американским специалистом в области систем управления базами данных И.Ф.Коддом. В 1994 г. отмечалась 25 годовщина с того момента, как И.Ф.Кодд (тогда научный сотрудник корпорации IBM) предложил реляционную модель. Тем не менее первая коммерческая реляционная СУБД, названная Oracle [14], появилась только в 1979 г. Она была разработана небольшой компанией Silicon Valley. Сегодня это Oracle Corporation – крупнейший в мире поставщик реляционных СУБД и сопутствующих программных продуктов. Первой СУБД клиент/сервер стал выпущенный в 1985 г. Oracle 5. В настоящее время широкое распространение получили более поздние реляционные СУБД, созданные корпорациями Oracle, Sybase, Microsoft и некоторыми другими. Современные ведущие реляционные СУБД сочетают реляционную модель данных с технологией клиент/сервер и с объектно-ориентированным подходом к созданию программных средств. На ЭВМ третьего поколения имели место многочисленные попытки применения иерархических и сетевых СУБД. Они оказались слишком сложными для восприятия пользователями и, кроме того, в них были ограничены или полностью отсутствовали возможности динамического изменения структуры баз данных. Последнее ограничение в некоторой степени присуще и реляционным СУБД, но все-таки с помощью языка SQL (см. подраздел 9.4) и другими методами здесь не так уж трудно изменить состав записей в таблице или создать новую таблицу и связать ее с имеющимися в рамках действующей СУБД.

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

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