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

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

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

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

    Объектом называется элемент информационной системы, данные о котором сохраняются на носителе.

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

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

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

    Запись данных — это совокупность значений связанных элементов данных.

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

    Тип данных характеризует вид хранящихся данных.

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

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

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

Рис. 1.1. Реляционная модель данных

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

    Как видно из рис. 1.1, база данных содержит несколько таблиц, которые определенным образом связаны между собой. Такие связи принято называть отношениями.

Отношение —  связь, установленная между двумя  ключевыми полями (столбцами) двух таблиц.

    Существуют  связи с отношением "один к одному", "один ко многим" и "многие ко многим".

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

    Отношение "один ко многим" является наиболее часто используемым типом связи между таблицами. В отношении "один ко многим" каждой записи в таблице A могут соответствовать несколько записей в таблице B, но запись в таблице B не может иметь более одной соответствующей ей записи в таблице A.

    При отношении "многие ко многим" одной записи в таблице A могут отвечать несколько записей в таблице B, а одной записи в таблице B — несколько записей в таблице A. Этот тип связи возможен только с помощью третьей (связующей) таблицы, первичный ключ которой состоит из двух полей, которые являются внешними ключами таблиц A и B. Отношение "многие ко многим" по сути дела представляет собой два отношения "один ко многим" с третьей таблицей.

    Функции, выполняемые СУБД, сводятся к следующему.

1. Определение структуры БД.
2. Инициализация БД и начальная загрузка данных.
3. Управление ресурсами среды хранения.
4. Обеспечение логической и физической независимости данных.
5. Предоставление доступа пользователю к БД.

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

    1) удовлетворять актуальным информационным потребностям организации;

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

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

    4) легко расширяться при изменении  предметной области;

    5) быть переносимой при изменении программной или аппаратной среды;

    6) обеспечивать доступ к данным, хранящимся в БД, только лицам, обладающим соответствующими полномочиями.

    База  данных в Microsoft Access может включать в себя ряд объектов.

    Объект — это таблица, запрос, форма, отчет, макрос, страница или модуль.

    К объектам относят также такие  структуры, определяемые Microsoft Access, такие, как таблица MSys Indexes и фрагменты из других приложений, например, связанные или внедренные диаграммы, рисунки или таблицы.

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

    Основные  этапы проектирования базы данных в Microsoft Access сводятся к выполнению следующих шагов.

• Определение цели создания базы данных.
• Задание таблиц, которые должна содержать база данных.
• Определение необходимых в таблице полей.
• Задание индивидуального значения каждому полю.
• Определение связей между таблицами.
• Обновление структуры базы данных.
• Добавление данных и создание других объектов базы данных.
• Использование средств анализа в Microsoft Access.

    Дадим краткую характеристику каждому  из этапов.

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

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

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

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

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

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

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

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

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

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

    После ознакомления с основными этапами проектирования базы данных в Access перейдем непосредственно к их реализации. Прежде всего, рассмотрим способы создания БД.

    Таблица 1.1

    Методы  создания таблиц

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

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

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

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

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

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

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

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

    При изменении модели предметной области, повлекшем изменение ключей отношений, в зависимости от характера последних можно различать:

- расширение  состава ключа (добавлением новых  атрибутов, как входящих ранее  в состав отношения, так и  не присутствующих в нем ранее);

- сжатие ключа  (исключение из него атрибутов);

- изменение состава  ключа (фактически, сочетание двух  предыдущих случаев).

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

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

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

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

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

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