Анализ элементов и отношений
Анализ элементов БД и отношений между ними позволяет построить структуру реляционной базы данных на основе идентификации объектов данных и связей между ними (рис. 6.16).
Рис. 6.16 Анализ элементов БД и отношений между ними
Вот что следует выявить при анализе:
элементы (или объекты), составляющие БД;
первичные ключи (или другие идентификаторы каждого элемента/объекта);
элементы данных или атрибуты каждого элемента или объекта. Тип данных должен обеспечивать минимально необходимое пространство для хранения элемента информации — это позволит уместить больше строк на одной странице данных и тем самым уменьшить число операции ввода/вывода;
соотношения между элементами/объектами для создания отношений между первичными и внешними ключами.
Отношения позволяют связать таблицы средствами оператора SQL Join. Например, для связи таблиц Customers и Orders служит поле CustomerID.
Результат анализа — модель «элементы-отношения», которая логически представляет данные и связи между ними и служит основой физической реализации базы данных. Нормализация обычно является составной частью процесса анализа.
Базовый уровень
Выделение и освобождение дескрипторов всех типов.
Обработка операторов прерывания.
Объединение результирующих наборов столбцов.
Обработка входных динамических параметров, включая массивы параметров.
Обработка смещений.
Управление курсорами и их именами.
Предоставление доступа к описанию результирующих наборов.
Выбор информации о каталоге.
Управление источниками данных и соединениями. Получение от драйвера информации о поддержке им различных уровней ODBC.
Подготовка и выполнение операторов SQL.
Обработка пересылки результирующих наборов.
Установка и выбор значения параметра (полностью и по частям).
Получение диагностической информации. Выяснение возможностей драйвера, включая естественную форму операторов SQL.
Завершение и отмена транзакций.
Базы данных индексно-последовательного доступа
Метод индексно-последовательного доступа (Indexed Sequential Access Method, ISAM) — это технология файловых баз данных, на основе которой построены такие СУБД, как FoxPro, Paradox и dBase. При получении информации средствами ISAM единственный ресурс — сами данные; никакие другие серверные компоненты при этом не используются.
Базы данных типа ISAM позволяют определить типы данных и создать на их основе хранилища. Кроме того, методы индексирования ускоряют извлечение и обработку данных. Несколько индексов, упорядочивающих ключи определенным образом, помогут более гибко и эффективно выбирать данные.
Базы данных: принципы построения
Глава 6. Базы данных: принципы построения
Прежде всего
Для изучения занятий этой главы необходимы:
Портфель (Briefcase) Windows 95;
база данных Northwind (Nwind.mdb);
Microsoft Access.
Занятие 1. Реляционные базы данных
Занятие 2. Клиент-серверные системы
Занятие 3. ODBC
Занятие 4. Нормализация базы данных
Занятие 5. Репликация базы данных
Закрепление материала
Диспетчер репликации Microsoft Access
Диспетчер репликации предоставляет интерфейс для преобразования БД, создания дополнительных реплик, просмотра связей между компонентами набора реплик и задания свойств реплик. Он поставляется только в составе редакции Microsoft Office 97 для разработчика (Microsoft Office 97, Developer's Edition). Диспетчер репликации применяют для:
управления набором реплик;
синхронизации данных через Интернет или интрасеть;
поддержки пользователей портативных компьютеров (мобильные пользователи могут депонировать свои реплики на сервере для последующей синхронизации);
создания реплик нескольких БД;
создания расписания синхронизации реплик набора (она будет выполняться в назначенное время без Вашего участия; кроме того, реплики можно синхронизировать в любое время специальной командой);
выбора различных конфигураций синхронизации (например, с рассылкой, приемом или объединением данных);
устранения ошибок.
Достоинства файловых баз данных
Хотя база данных может находится на сервере, сервер необязателен.
Создание БД на локальном компьютере уменьшает сетевой трафик.
Реализация файловой БД гораздо проще, чем системы клиент-сервер, поскольку в этом случае сервер только хранит данные.
Достоинства «интеллектуальных» клиентов
Простота архитектуры, что облегчает разработку и сопровождение системы.
Наличие хорошо известных и достаточно мощных средств разработки (например, Visual Basic 5.0).
Клиент хорошо подходит для хранения текущей информации о состоянии, например первичного ключа записи, которую сейчас просматривает пользователь.
Достоинства «интеллектуальных» серверов
Увеличение производительности: бизнес-логика выполняется в том же адресном пространстве, что и код доступа к базе данных, и, кроме того, тесно интегрирована с механизмом поиска данных SQL Server. Это означает, что данные не нужно перемещать или копировать перед обработкой, а значит, сетевой трафик минимизируется.
На сервере легче обеспечивать целостность данных.
При необходимости бизнес-логика модифицируется централизованно, без изменения клиентов.
Достоинства клиент-серверных баз данных
Клиент-серверная архитектура обладает рядом достоинств, делающих ее оптимальным вариантом для многих приложений управления данными.
Гарантирует надежность, поскольку все действия над данными выполняет сервер БД.
Значительно увеличивает производительность некоторых операций, особенно в случае «тощих» клиентов с медленными процессорами и ограниченной памятью. Например, большой запрос во много раз быстрее выполняется на мощном сервере, чем на клиентской рабочей станции.
Снижает сетевой трафик за счет передачи клиенту только необходимых ему данных.
Обеспечивает отказоустойчивость за счет протоколирования транзакций, интеллектуального резервирования, избыточных дисковых массивов и средств восстановления после сбоев.
Достоинства многоуровневых систем
Разделение компонентов интерфейса, бизнес-правил и хранения данных. Возможность применения интеллектуальных клиентов. Возможность применения сервисов.
Достоинства смешанных систем
Часть бизнес-логики может быть реализована в клиентской части.
Серверный код (например, хранимые процедуры SQL Server) одновременно доступен многим клиентам, что снижает накладные затраты при выполнении однотипных запросов.
Эффективность работы клиентов меньше зависит от сетевого трафика.
Файловые базы данных
Многие популярные системы управления базами данных (СУБД) для персональных компьютеров являются файловыми реляционными БД. Эти базы данных, как правило, размещают на сервере для совместного использования, и поэтому такая архитектура считается файл-серверной.
Ядро файл-серверной БД находится на рабочих станциях пользователей, а файл данных — на сервере (рис. 6.3). Когда клиентскому приложению нужны данные, ядро БД выполняет запрос и затем обращается к сетевому диску за необходимыми данными. Все запрашиваемые сведения из файла БД в этом случае пересылаются с сервера на рабочую станцию, что иногда создает значительную нагрузку на сеть.
Рис. 6.3 Файловая база данных
Физическое решение
На этой стадии проектируются физические компоненты для объектов и сервисов. Структура и дизайн компонентов должны отражать исходные бизнес-объекты и, естественно, сценарии использования. Дополнительные задачи на этой стадии — учет существующей инфраструктуры и технологий для минимизации риска и сокращения цикла разработки.
«Интеллектуальные» клиенты
Это один из самых распространенных методов реализации клиент-серверных приложений (рис. 6.7). «Интеллектуальному» клиенту можно доверить выполнение как бизнес-логики, так и сервисов представления данных.
Рис. 6.7 Бизнес-логика реализована на клиенте
В этом случае функции сервера ограничены поддержкой собственно базы данных. Вся информация обрабатывается локально, что освобождает ресурсы сервера. Многие приложения, разработанные на Visual Basic, являются интеллектуальными клиентами.
«Интеллектуальные» серверы
Перенеся все бизнес-правила на SQL Server, где они реализуются в виде хранимых процедур, Вы создадите «интеллектуальный» сервер (рис. 6.8). Роль сервера в такой клиент-серверной системе много шире простого хранилища файлов, доступных множеству пользователей сети. Интеллект сервера проявляется в способности выполнять команды (SQL-запросы) и возвращать результирующий набор данных.
Рис. 6.8 Бизнес-логика реализована на центральном сервере
В двухуровневой системе с «интеллектуальным» сервером бизнес-логика и сервисы представления развертываются на сервере. В этом случае бизнес-логика обычно реализуется в виде хранимых процедур и триггеров БД, так что основная часть обработки выполняется на сервере, а не на компьютере-клиенте.
Клиент-серверные базы данных
Клиент-серверная архитектура — эффективный и популярный метод создания распределенных приложений. Клиент-серверные БД, как и файловые, хранят данные, но также обеспечивают и дополнительные функциональные возможности (рис. 6.4).
Рис. 6.4 Клиент-серверная база данных
В модели клиент-сервер приложение разделено на две части: клиентскую, предоставляющую информацию пользователю, и серверную, которая хранит, выбирает и обрабатывает данные, а также выполняет основную часть вычислений при обработке запросов клиентов. В клиент-серверной системе в качестве сервера обычно выступает компьютер более мощный, чем рабочие станции-клиенты. Он же, как правило, служит единым хранилищем данных для множества клиентских компьютеров, что облегчает администрирование системы.
Среди типовых примеров клиент-серверных приложений — базы данных общего доступа, удаленные файл-серверы и удаленные серверы печати.
Команды репликации Microsoft Access
В распоряжении пользователя Microsoft Access — целый набор команд для репликации. Средствами подменю Replication меню Tools можно:
создать реплику;
синхронизировать свою реплику с другими копиями набора;
разрешать конфликты синхронизации специальными средствами (Conflict Resolver);
восстановить основную реплику.
> Репликация БД средствами Microsoft Access
В этом упражнении Вы создадите набор реплик средствами Microsoft Access.
Запустите Microsoft Access и создайте новую базу данных MyCorp.mdb.
Сконструируйте таблицу Employees с одним текстовым полем FirstName.
В меню Tools, Replication выберите команду Create Replica.
Щелкните кнопку Yes, чтобы закрыть базу данных и создать основную реплику.
Щелкните кнопку Yes в ответ на запрос о необходимости создания резервной копии.
Щелкните кнопку ОК в ответ на запрос о размещении реплики.
Рассмотрите окно сообщения и щелкните кнопку ОК.
В каждой реплике набора, за исключением основной, можно изменять только данные. Коррективы структуры БД — например, добавление новых таблиц или полей — разрешены только в основной реплике.
Концепция
На концептуальной стадии основное внимание уделяется сценариям использования приложения. Они должны отражать требования пользователей к решению конкретных проблем бизнеса. Здесь определяется бизнес-проблема и вырабатывается подход, отвечающий нуждам и требованиям пользователей.
Логика
На этой стадии на основе сценариев использования проектируются бизнес-объекты и необходимые сервисы. Логическая структура приложения представляет собой основу формальной модели для команды проектировщиков и базу для оценки различных вариантов физического решения.
Метафора «издатель-подписчик»
Издатель публикует и распространяет информацию, а подписчик получает ее. При репликации средствами SQL Server сервера может выполнять несколько функций в любой комбинации:
издатель — управляет источниками БД и хранит сведения, доступные для репликации;
распространитель — принимает и сохраняет изменения и доводит их до подписчиков;
подписчик — принимает коррективы.
Сервер публикаций
Он управляет базой данных публикаций, делает их доступными для репликации и отправляет копии изменений в публикуемых сведениях на сервер распространения.
Microsoft Access
Microsoft Access — это настольная реляционная система управления базами данных. Если файл БД хранится на сетевом сервере, сетевому клиенту предоставляется только сервис хранения данных. Поскольку Microsoft Access использует те же ядро БД (Jet) и формат, что и Microsoft Visual Basic, базы данных, созданные посредством Access, можно использовать так, будто они созданы непосредственно в Visual Basic.
Microsoft SQL Server
Microsoft SQL Server — это масштабируемая высокопроизводительная система управления реляционными базами данных для платформ на базе Windows NT Server. Она разработана с учетом требований к современным распределенным клиент-серверным вычислениям и тесно интегрирована с серверными продуктами семейства Microsoft Office.
Минимальная грамматика SQL
Язык определения данных (Data Definition Language, DDL): CREATE TABLE и DROP TABLE.
Язык манипулирования данными (Data Manipulation Language, DML): простой SELECT, INSERT, UPDATE SEARCHED и DELETE SEARCHED.
Выражения: простые.
Типы данных: CHAR, VARCHAR или LONG VARCHAR
Многоуровневые системы
Многоуровневая система (иногда ее называют трехуровневой) позволяет разделить пользовательский интерфейс, бизнес-правила и базу данных (рис. 6.10).
Рис. 6.10 Пользовательский интерфейс, бизнес-правила и база данных размешены отдельно
В многоуровневой системе бизнес-правила реализуются как отдельные библиотеки (DLL). Их (например, написанные на Visual Basic) можно разместить на сервере. Клиент, библиотеки и база данных составляют распределенные сервисы многоуровневой системы.
Недостатки «интеллектуальных» клиентов
Выполнение бизнес-правил на клиенте иногда увеличивает сетевой трафик из-за необходимости передавать клиенту все данные для принятия решения на основе правил.
Для модификации бизнес-логики необходимо повторное развертывание всех клиентов.
Повышение требований к ресурсам сервера, где выполняются все запросы и манипуляции с данными.
Ограниченный выбор средств разработки: хранимые процедуры, например, создают на языке Transact-SQL. Хотя SQL Server поддерживает вызовы кода, написанного на других языках, этот подход сложен и в общем случае менее эффективен, нежели разработка тех же функций на Transact-SQL.
Недостатки многоуровневых систем
Необходимы сервер и сеть. Увеличивается сетевой трафик.
Недостатки смешанных систем
Бизнес-логика распределена между клиентом и сервером.
Модернизация приложения требует распространения новых версий клиентской части среди широкой аудитории.
Нормализация
Цель нормализации БД - разработка хорошо организованной, оптимизированной и логичной модели базы данных до начала ее физической реализации. Этот подход минимизирует затраты на доводку базы данных на поздних стадиях разработки. Нормализация БД повышает производительность за счет экономии пространства для хранения данных и времени на их обработку.
Определение ODBC
Технология ODBC реализует стандартизованный интерфейс для доступа к разнородным SQL-совместимым базам данных (рис. 6.11). Для программирования доступа к информации в ODBC-совместимых БД применяется язык структурированных запросов (Structured Query Language, SQL).
Рис. 6.11 Подключение клиентского приложения к БД средствами ODBC
Используя ODBC и SQL, приложение может средствами одного кода получить доступ к SQL-совместимым системам управления базами данных (СУБД) разных производителей. ODBC позволяет разработчику создавать и распространять клиент-серверные программы, не зависящие от конкретной СУБД. Для подключения к выбранной пользователем БД достаточно просто добавить соответствующий драйвер базы данных. Эту работу берет на себя диспетчер драйверов ODBC.
Вот в чем причина гибкости ODBC:
приложения не связаны узами фирменного API конкретного поставщика;
операторы SQL включают непосредственно в исходный код или конструируют их на стадии выполнения; кроме того, приложение может игнорировать нижележащие протоколы обмена данными;
данные передают и принимают в удобном для приложения формате.
ODBC соответствует формирующемуся стандарту интерфейса уровня вызова (Call-Level Interface) Международной организации по стандартизации (International Standards Organization, ISO).
Диспетчер драйверов ODBC
Приложение взаимодействует с диспетчером драйверов ODBC через интерфейс ODBC. Диспетчер драйверов — это библиотека динамической загрузки, которая загружает необходимые ODBC-драйверы (рис. 6.12).
Рис. 6.12 Диспетчер драйверов ODBC
Кроме загрузки необходимых драйверов, диспетчер выполняет дополнительные функции:
обрабатывает некоторые инициализационные и информационные вызовы ODBC;
передает вызовы функций ODBC от приложения драйверу;
проверяет ошибки и контролирует состояние;
регистрирует вызовы функций приложениями (дополнительная возможность).
Обычно для доступа к диспетчеру драйверов программа дополняется импортируемой библиотекой диспетчера драйверов (odbc.lib).
Диспетчер драйверов может при необходимости регистрировать в журнале все вызовы функций ODBC приложением (это происходит после проверки наличия ошибок).
В журнал записывается имя каждой свободной от ошибок функции вместе со значениями входных аргументов и именами выходных. Прежде чем передать вызов драйверу, отвечающему за подключение к конкретной БД, диспетчер проверяет аргументы функций и корректность изменения состояния, а также другие условия отсутствия ошибок. Таким образом драйвер БД освобождается от обработки большинства ошибок. Имена источников данных Имя источника данных (Data Source Name, DSN) — это именованный ресурс ODBC, который определяет местонахождение, тип драйвера и другие параметры БД, необходимые для доступа к ней (рис. 6.13). Диспетчер драйверов ODBC использует эту информацию для установления соединения и управления им.
Системные DSN относятся к компьютеру, а не к пользователю. Система или любой пользователь, обладающий соответствующими привилегиями, могут работать с источником данных, заданным системным DSN.
Информация о соединении для файлового DSN хранится в файле, доступном для чтения любому приложению: это облегчает перенос проекта с одного компьютера на другой.
> Создание DSN В этом упражнении Вы создадите DSN для базы данных Northwind, чтобы пользоваться ею в следующих упражнениях этого занятия.
Дважды щелкните значок 32bit ODBC на панели управления Windows. Если Вы работаете с Windows NT 4.0, этот значок называется ODBC.
Откройте вкладку System DSN.
Щелкните кнопку Add.
Выберите Microsoft Access Driver и щелкните Finish.
В поле Data Source Name введите nwind.
Щелкните Select и найдите базу данных Northwind в папке WA\Practice\ nwind.mdb.
Щелкните кнопку OK, чтобы закрыть ODBC Data Source Administrator. Теперь база данных Northwind доступна средствам разработки (например, Visual Basic) и средствам управления Web-узлом (например, Frontpage).
Соответствие требованиям API ODBC
Драйверы ODBC предоставляют программам доступ к разнообразным источникам данных: приложение на стадии выполнения может выяснить, какие возможности и какую грамматику SQL поддерживают данный драйвер и источник данных.
Все драйверы ODBC должны удовлетворять требованиям одного из трех уровней соответствия стандартам API ODBC (рис. 6.14).
Рис. 6.14 Уровни соответствия требованиям API ODBC
Драйверы ODBC должны, как минимум, соответствовать требованиям интерфейса базового уровня. Это основные функции драйвера, которые обычно необходимы приложениям.
Многим приложениям ODBC нужны драйверы, отвечающие требованиям следующего уровня; поэтому если драйвер ориентирован на широкую аудиторию, разработчикам придется реализовать все требования уровня 1, а условия второго можно рассматривать как перечень необязательных дополнений.
Ниже перечислены функции, которые должен реализовать драйвер для соответствия требованиям каждого из уровней.
Основная грамматика SQL
Минимальная грамматика SQL и типы данных.
DDL: ALTER TABLE, CREATE INDEX, DROP INDEX, CREATE VIEW, DROP VIEW, GRANT и REVOKE.
DML: полная поддержка SELECT.
Выражения: вложенные запросы и функции агрегирования.
Типы данных: DECIMAL, NUMERIC, SMALLINT, INTEGER, REAL, FLOAT, DOUBLE PRECISION
Особенности клиента
Пользователям, работающим в сети, часто требуется запускать приложения с сетевого сервера. Клиентские компоненты должны включать средства поддержки локальной информации (в том числе и информацию из локального реестра и локальных файлов) и средства, предоставляющие пользователю доступ к серверным компонентам.
Особенности сервера
В состав серверной части должны входить основные исполняемые файлы, библиотеки и все остальные файлы, необходимые для поддержки доступа пользователей по сети. Кроме того, надо изучить требования к ресурсам сервера и на их основе принять решение относительно аппаратной конфигурации, учитывая тип процессора (например, SQL Server поддерживает процессоры Alpha AXP, MIPS и 32-разрядные процессоры семейства Intel x86) и ресурс памяти (чем больше клиентов, тем больше потребуется ОЗУ для сохранения и увеличения быстродействия).
Переопределение атрибутов
Переопределение атрибутов уменьшает объем данных одного вида. Вот как это сделать:
добавьте производные атрибуты (столбцы) в таблицы БД;
составной ключ, участвующий во множестве отношений, часто лучше заменить производным ключом меньшей сложности. Для этого годятся большие ключи и текстовые поля. Последнее лучше переопределить или дополнить абстрактным полем длиной не более 255 символов.
Этот способ уменьшает размер столбцов таблицы, снижая затраты ресурсов сервера во время запросов и других операций с БД.
Переопределение объектов
Переопределите объекты БД (таблицы), чтобы уменьшить влияния постороннего атрибута (столбца) или строки. Вот несколько вариантов денормализации.
Разделить объект по атрибутам (столбцам) на два, чтобы отделить часто используемые данные.
В этом случае первичный ключ дублируется в каждой новой таблице, однако повышается эффективность параллельного доступа, а таблицы часто становятся более компактными.
Разделить объект на два по строкам.
Этот прием годится для таблиц, содержащих много данных. Им стоит пользоваться и если необходим доступ к строкам по логическим подмножествам (отдел, сегмент рынка, регион и т.п.). Кроме того, любое подмножество большого набора данных, используемое активнее других, — подходящий кандидат на выделение в отдельную таблицу.
Перспектива
Сценарии перспективного использования приложения или системы — основа будущего расширения возможностей приложения. Они отражают мнение пользователей о будущем бизнес-решения и должны быть детализированы настолько, насколько это необходимо для понимания перспективы. Например, конкретное приложение может помимо текущего сценария платежей по чекам включать и перспективный — для расчетов по кредитным карточкам.
Портфельная репликация Microsoft Windows 95
Портфельная репликация Microsoft Windows 95 удобна для портативного компьютера. Просто перетащите файл БД Microsoft Access (MDB) из общей сетевой папки на значок My Briefcase (Портфель) рабочего стола портативного компьютера — в результате БД преобразуется в основную реплику, а в Портфеле будет создана реплика. Теперь отсоединяйте портативный компьютер от сети и спокойно работайте с репликой. Закончив, снова подсоедините его к сети. Чтобы синхронизировать изменения реплики на портативном компьютере с основной репликой (например, на сервере), дважды щелкните значок My Briefcase и выберите в меню Briefcase команду Update All. В ходе преобразования можно создать резервную копию исходного файла БД (с тем же именем, что и исходный файл, но с расширением .bak) в той же папке. Сохраните резервную копию: она пригодится, если для восстановления набора реплик нельзя использовать реплику. > Портфельная репликация базы данных В этом упражнении Вы реплицируете базу данных College.mdb с помощью Портфеля Windows 95.
На рабочем столе Windows 95 дважды щелкните значок My Computer и най дите файл College.mdb.
Щелкнув файл College.mdb правой кнопкой мыши, выберите в появившемся меню команду Properties.
Каков текущий размер базы данных? ответ
Измените размер окна Ch06 так, чтобы видеть рабочий стол Windows 95.
Дважды щелкните любое место рабочего стола, откройте в появившемся меню вложенное меню New и выберите команду Briefcase.
На рабочем столе появится новый значок портфеля.
Перетащите базу данных из Ch06 в портфель.
В ответ на запрос, хотите ли Вы сделать базу данных реплицируемой, щелк ните кнопку Yes.
Щелкните кнопку Yes, чтобы создать резервную копию БД.
В ответ на запрос выберите исходную копию БД в качестве основной репли ки и щелкните кнопку ОК.
В диалоговом окне Welcome to the Windows Briefcase щелкните кнопку Finish.
Дважды щелкните значок My Briefcase, чтобы удостовериться, что копия базы данных помещена в Портфель.
Переключитесь в окно Ch06.
Каков теперь размер базы данных на жестком диске?
ответ
Откройте базу данных и проверьте таблицы. Есть ли какие-нибудь измене ния в структуре таблиц, например новые поля, новые таблицы и т.д.?
ответ
> Изменение основной реплики
Добавьте новое текстовое поле в таблицу Students, назвав его EmailAddress. Получилось ли у Вас это? Почему?
ответ
Закройте эту копию базы данных и откройте копию Replica в Портфеле.
Выберите таблицу Students и щелкните кнопку Open.
Новое поле не появилось, так как базы данных еще не синхронизированы.
Закройте таблицу Students.
В меню Tools, Replication выберите команду Synchronize Now.
Щелкните кнопку OK, чтобы синхронизировать данную реплику с основ ной, а затем щелкните кнопку Yes, чтобы повторно открыть БД.
Попробуйте открыть таблицу Students в режиме конструирования.
Щелкните кнопку Yes в ответ на запрос об открытии таблицы только для чтения.
Поскольку это не основная реплика, вносить изменения в структуру таблицы нельзя. Обратите внимание, что новое поле реплицировано в эту копию БД.
Правила нормализации
В соответствии с правилами проектирования баз данных - правилами нормализации — каждая таблица должна описывать объекты одного типа: людей, места события или вещи. Существуют три формы нормализации базы данных (рис! 6.17), каждая из которых определяет состояние данных в БД.
Рис. 6.17 Нормальные формы
Первая нормальная форма: запрещает повторяющиеся группы или множественные столбцы значений.
Вторая нормальная форма: запрещает неключевому полю зависеть от части составного первичного ключа — разрешена только зависимость от первичного ключа в целом.
Третья нормальная форма: запрещает неключевому полю зависеть от другого неключевого поля.
База данных, спроектированная по правилам нормализации, состоит из большего, чем в ненормализованной, числа компактных простых таблиц, что уменьшает избыточность данных и объем пространства, необходимого для их хранения.
Преимущества клиент-серверных систем
Клиент-серверный подход — модульный, причем серверные программные компоненты компактны и автономны.
Поскольку каждый компонент выполняется в отдельном защищенном процессе пользовательского режима, сбой сервера не повлияет на остальные компоненты операционной системы.
Автономность компонентов делает возможным их выполнение на нескольких процессорах на одном компьютере (симметричная многопроцессорная обработка) или на нескольких компьютерах сети (распределенные вычисления).
Обязанность клиента, как правило, — предоставлять пользовательские сервисы и, прежде всего, пользовательский интерфейс, то есть средства для приема, отображения и редактирования данных, введенных пользователем, которые служат основой для запроса серверу. Кроме того, клиент можно настроить на обработку части данных, чтобы уменьшить нагрузку на ресурсы сервера.
Проектирование клиент-серверной системы
При разработке бизнес-приложения необходимо прежде всего проанализировать постановку задачи, чтобы понять, в каком направлении разрабатывать приложение. Дизайн проекта на всех стадиях разработки должен соответствовать поставленной задаче и требованиям конкретной бизнес-ситуации.
Расширенная грамматика SQL
Минимальная и основная грамматика SQL и типы данных.
DML: внешние соединения, поддержка позиционирования для операторов UPDATE и DELETE, SELECT FOR UPDATE, объединения.
Выражения: скалярные функции, литеральная дата, время и штамп (дата/ время).
Типы данных: BIT, TINYINT, BIGINT, BINARY, VARBINARY, LONG VARBINARY, DATE, TIME, TIMESTAMP.
Пакетные операторы SQL.
Вызовы процедур
Репликация средствами DАО
Интерфейс объектов доступа к данным (Data Access Objects, DAO) предоставляет методы и свойства, позволяющие разработчикам использовать некоторые средства портфельной репликации в программах Visual Basic. Объекты DAO применяются для:
преобразования БД в основную реплику;
создания и распространения дополнительных реплик;
создания и распространения частичных реплик;
синхронизации реплик;
опроса и установки свойств реплицированной БД;
разрешения конфликтов и ошибок.
Применение объектов DAO требует программирования, но зато позволяет построить собственную систему репликации". Есть несколько ситуаций, когда использовать объекты DAO уместно.
Синхронизация реплик при возникновении определенных событий, например, если реплика получает из центра обновленную информацию о ценах на товары.
Распространение реплицированной БД среди пользователей-новичков. Объекты DAO позволят создать упрощенный интерфейс репликации или скрыть выполнение репликации от пользователей.
Создание частичной реплики (например, содержащей только часть данных). Включив в нее лишь некое подмножество данных, Вы уменьшите используемое дисковое пространство и повысите производительность.
Средства Microsoft SQL Server
Репликация — встроенный компонент SQL Server. Он позволяет автоматически выполнять зарегистрированные в соответствующем журнале транзакции, которые связаны с реплицируемыми таблицами (рис. 6.21). Все коррективы асинхронно передаются в таблицы назначения на серверах сети (так называемое распространение транзакций), а процессы в основной базе данных идут своим чередом.
Рис. 6.21 Средства репликации SQL Server
Цели репликации SQL Server таковы:
непрерывное распространение транзакций;
минимизация времени репликации (наименьшее запаздывание транзакции);
максимизация параллельности процессов;
непротиворечивость транзакций.
Средства репликации SQL Server обеспечивают;
репликацию на уровне строки (так называемая горизонтальная синхронизация) и на уровне столбца (вертикальная синхронизация);
репликацию на базе гетерогенных ODBC-совместимых источников данных;
отказоустойчивость.
Чтобы информация была доступна для копирования, необходимо создать публикацию. Репликация SQL Server реализуется на основе метафоры «издатель-подписчик».
это наиболее популярная архитектура баз
Реляционная модель — это наиболее популярная архитектура баз данных. В настоящее время наиболее распространены два типа реляционных БД: файловые и клиент-серверные.
В первых ядро находится на каждой пользовательской рабочей станции, а файл данных — на сервере.
Во второй приложение разделено на две части: клиентскую, предоставляющую информацию пользователю, и серверную, которая хранит, выбирает и обрабатывает данные, а также выполняет основную часть вычислений при обработке запросов клиентов.
сервер позволяет разграничить обязанности сервера
Архитектура клиент- сервер позволяет разграничить обязанности сервера и клиентов, что делает ее одной из самых популярных моделей для систем масштаба предприятия. Клиент-серверное проектирование оптимизированной системы управления базой данных состоит из четырех стадий: концептуальной, логической, физической и перспективной. Реализация клиент-серверной системы управления базой данных может опираться на разные типы распределения обязанностей между клиентом и сервером. Среди них:
«интеллектуальные» клиенты;
«интеллектуальный» сервер;
смешанные системы;
многоуровневые системы.
Технология ODBC реализует типовой интерфейс
Технология ODBC реализует типовой интерфейс для доступа к разнородным SQL-совместимым базам данных. ODBC позволяет разработчику создавать и распространять клиент-серверные приложения, не привязанные к конкретной СУБД. Драйверы баз данных обеспечивают подключение приложений к СУБД. Загрузку драйверов, необходимых приложению-клиенту для доступа к БД, выполняет диспетчер драйверов ODBC. Имя источника данных задает местонахождение, тип драйвера и другие параметры, необходимые драйверу ODBC для доступа к БД. Все драйверы ODBC должны соответствовать требованиям в отношении API и SQL.
После разработки реляционная база данных
После разработки реляционная база данных должна быть нормализована. Оптимальная реляционная БД обычно конструируется на основе анализа элементов и отношений между ними с последующей нормализацией.
Анализ элементов БД и отношений между ними позволяет выработать структуру реляционной базы данных. Цель нормализации базы данных — разработка хорошо организованной, оптимизированной и логичной схемы БД до начала ее физической реализации.
Чрезмерная нормализация БД иногда вызывает избыточную нагрузку на ресурсы сервера при выполнении таких операций, как запросы. Разумная выборочная денормализация позволяет повысить производительность БД благодаря более эффективному использованию ресурсов.
Репликация базы данных позволяет двум
Репликация базы данных позволяет двум или более пользователям одновременно работать с локальной копией базы данных; содержимое исходной БД при этом не меняется. Чтобы отразить в оригинале изменения, сделанные в копиях, нужно периодически выполнять синхронизацию. Средства репликации баз данных включены в состав Microsoft Access и SQL Server.
Сервер подписки
Он хранит копии данных и принимает информацию об изменениях. Публикуемая информация перемещается только в одном направлении — от сервера публикации к серверам подписки, причем сведения могут изменяться только на сервере публикации. Реплицированные данные, копируемые на сервер подписки, следует определить как данные «только для чтения»; у подписчиков не должно быть права менять их.
Сервер распространения
Здесь хранится БД распространения. Сервер распространения принимает коррективы для публикуемых данных, сохраняет их в БД распространения и отправляет соответствующим серверам подписки. Издатель и распространитель могут находиться на одном сервере, но при большой нагрузке их лучше разделить.
Сервисы
Сервис — это набор связанных функций, выполняющих определенные действия и/или предоставляющих информацию на основе взаимодействия с пользователем. Доступ к сервису обеспечивает интерфейс, инкапсулирующий его реализацию.
Сервисная модель — это метод рассмотрения приложения как набора средств или сервисов, которые удовлетворяют запросы клиентов. Моделирование программы в виде набора отдельных сервисов позволяет повторно использовать компоненты, предоставляет доступ к ним другим приложениям и помогает распределять их выполнение между несколькими компьютерами сети.
Синхронизация
Этой операцией можно синхронизировать целые базы данных или отдельные таблицы до того, как начнется репликация изменений данных. Интервал времени синхронизации новых подписчиков определяет администратор. Планирование синхронизации для таблиц или баз данных должно стать первым шагом при инициализации репликации. Сначала надо создать «снимок» схемы таблиц и данных в них, чтобы обеспечить целостность информации. Затем изменения в публикуемых данных можно реплицировать на серверы подписки.
Системы клиент-сервер
Клиент-серверная система управления базой данных может опираться на несколько типов распределения обязанностей между клиентом и сервером:
«интеллектуальные» клиенты;
«интеллектуальный» сервер;
смешанные системы;
многоуровневые системы. Схему реализации выбирают на основе анализа требований к:
сетевому графику;
ресурсам клиента и сервера;
производительности базы данных.
Смешанные системы
В рамках двухуровневой реализации возможны и смешанные варианты, обладающие достоинствами как интеллектуальных серверов, так и интеллектуальных клиентов (рис. 6.9). Например, клиентский компонент смешанного решения, разработанный средствами Visual Basic, может вызывать хранимые процедуры SQL Server.
Рис. 6.9 Смешанные системы: интеллектуальные клиенты и интеллектуальный сервер
Создание отношений
В этом упражнении Вы создадите новую нормализованную базу данных.
Предположим, Вас — администратора БД одного из колледжей — попросили спроектировать базу данных для хранения информации о студентах, преподавателях и читаемых курсах.
> Создание новой базы данных
Создайте новую базу данных, используя Microsoft Access. Назовите ее Col-ledge.mdb и сохраните в папке WA\Practice\Ch06
Создайте таблицы и поля на основе приведенной ниже информации.
| Категория | Имя поля |
Содержимое |
| Информация о студенте
|
First Name |
Имя |
| Last Name |
Фамилия |
|
| Student ID |
Уникальный идентификатор |
|
| Telephone Number |
Номер телефона |
|
| Graduation Date |
Дата получения диплома |
|
| Информация о преподавателе
|
First Name |
Имя |
| Last Name |
Фамилия |
|
| Faculty ID |
Уникальный идентификатор |
|
| Telephone Number |
Номер телефона |
|
| Department |
Факультет |
|
| Date Hired |
Дата приема на работу |
|
| Tenure |
Постоянный сотрудник (Да/Нет) |
|
| Description |
Дополнительные сведения |
|
| Информация о курсе
|
Course ID |
Уникальный идентификатор |
| Location |
Место проведения занятий (номер здания) |
|
| Time |
Время проведения занятий |
|
| Department | Факультет | |
| Faculty Instructor |
Преподаватель |
Сохраните базу данных
> Создание отношений
В меню Tools щелкните команду Relationships.
Добавьте все три таблицы и щелкните кнопку Close.
Перетащите поле Faculty ID таблицы Faculty Information на поле Faculty Instructor таблицы Class Information.
По умолчанию в результате этой операции создается отношение «один ко многим». Это вполне разумно - ведь преподаватель может читать несколько разных курсов.
Щелкните кнопку Create.
Сохраните изменения и закройте Access.
Ссылочная целостность
Ссылочная целостность — это система правил, гарантирующих корректность отношений между записями связанных таблиц и исключающих возможность случайного удаления или изменения части связанных между собой данных. Для каждой строки таблицы с внешним ключом ссылочная целостность удостоверяет наличие соответствующей строки в таблице с первичным ключом. Кроме того, этот механизм предотвращает удаление строки из таблицы с первичным ключом, если она связана с таблицей с внешним ключом; чтобы все-таки выполнить это действие, необходимо сначала удалить отношение между таблицами.
Периодическая проверка ссылочной целостности помогает убедиться, что жизненно важные данные — например, уникальный идентификатор — по мере эволюции базы данных остаются корректными и доступными. Ссылочная целостность также включает операции по изменению соответствующих значений в таблицах, когда внешний ключ одной из них содержит то же значение, что и первичный ключ другой.
Процесс денормализации
Чрезмерная нормализация порождает проблемы: множество связей между таблицами вызывают избыточную нагрузку на ресурсы сервера при выполнении таких операций, как запросы. Выборочная денормализация позволяет более эффективно использовать процессорные ресурсы, что увеличивает производительность. Возможно несколько вариантов денормализации (рис. 6.18).
Рис. 6.18 Варианты денормализации
Стадии разработки
Клиент-серверное проектирование оптимизированной системы управления базой данных состоит из четырех стадий: концептуальной, логической, физической и перспективной (рис. 6.6). Этот путь от простого к сложному позволяет реализовать базу данных, предназначенную для решения конкретной задачи.
Рис. 6.6 Стадии проектирования клиент-серверной базы данных
Структуры данных SQL
Структуры данных SQL предназначены для реляционных баз данных большого размера. При увеличении объема данных БД ISAM менее эффективны, чем SQL, которые могут обрабатывать большие наборы данных и одновременные запросы множества пользователей. Усовершенствованные методы индексирования и механизмы оптимизации запросов делают базы данных SQL оптимальным выбором для отказоустойчивых приложений и процессов, оперирующих с большими объемами информации.
В конфигурации клиент-сервер (например Microsoft SQL Server) и ядро БД, и сами данные находятся на сетевом сервере. Вместо запуска копии ядра БД на каждой рабочей станции, ядро выполняется только на сервере, а рабочая станция просто передает запросы в виде операторов SQL серверу, который выбирает нужные данные и возвращает их клиенту.
Типы сервисов
В типичных бизнес-приложениях возможны сервисы трех категорий.
| Тип сервиса | Размещение | Назначение |
| Пользовательский | Клиент | Представление информации и доступа к функциям приложения, навигация, сохранение целостности и непротиворечивости пользовательского интерфейса |
| Бизнес-сервис | Сервер | Реализация основных стратегий, генерация информации на основе данных и поддержка целостности среды принятия бизнес-решений |
| Сервис данных | Сервер | Структуризация данных, их хранение, извлечение и поддержка целостности |
и представлений БД средствами составных
Соответствие требованиям базового уровня.
Описание схемы таблиц и представлений БД средствами составных имен.
Асинхронное выполнение функций ODBC.
Поддержка перемещаемых курсоров (это позволяет предоставлять дополнительные методы доступа к результирующему набору).
Выбор первичных ключей таблиц.
Поддержка хранимым процедур, включая опрос словаря в отношении хранимых процедур.
Подключение к источнику данных путем интерактивного просмотра доступных серверов.
Поддержка выполнения некоторых операций с БД средствами функций ODBC вместо операторов SQL.
Доступ к содержимому наборов, созданных в результате выполнения пакетов и хранимых процедур.
Примечание В спецификации ODBC 2.0 многие требования уровня I были перемещены на базовый уровень.
Поддержка закладок для обновления, удаления
Соответствие требованиям первого уровня.
Поддержка трехчастных имен таблиц и представлений базы данных.
Описание динамических параметров.
Поддержка входных, выходных и комбинированных параметров и результатов хранимых процедур.
Поддержка закладок для обновления, удаления и поиска данных.
Получение дополнительной информации из словаря.
Поддержка асинхронного выполнения функций ODBC в составе одного оператора.
Поддержка тайм-аута в запросах регистрации и SQL-запросах.
Поддержка изменения уровня изоляции по умолчанию и выполнения транзакций с серийной изоляцией.
Соответствие требованиям SQL ODBC
Стандарт ODBC включает минимальные грамматические требования соответствия базовому уровню языка SQL. Драйверы ODBC, поддерживающие основную и расширенную грамматику SQL, могут выполнять более сложные команды SQL (рис. 6.15).
Рис. 6.15 Уровни соответствия требованиям в отношении грамматики SQL
Все драйверы должны поддерживать минимальную грамматику. Как и в случае API (см. предыдущий раздел), для соответствия одному из уровней по этому параметру необходимо, чтобы драйвер отвечал всем требованиям этого уровня.
Ниже перечислены требования различных уровней соответствия на основе спецификации SQL 92.
Введение избыточности
Если в результате нормализации связей становится слишком много, попробуйте искусственно ввести избыточность на уровне атрибута (столбца) или объекта (таблицы) следующим образом:
добавьте дублирующие атрибуты (столбцы) в объекты (таблицы) базы данных;
добавьте в таблицы БД производные атрибуты — например, агрегаты, максимальные величины и т.д.
Денормализация путем введения избыточных значений исключает излишние затраты, связанные с доступом к дополнительным таблицам.
Реляционные базы данных
Занятие 1. Реляционные базы данных
(Продолжительность занятия 30 минут)
Бизнес-решения почти всегда требуют поддержки баз данных. В настоящее время наиболее распространены два типа реляционных БД: файловые и клиент-серверные. На этом занятии обсуждаются реляционные базы данных, характеристики файловых и клиент-серверных баз данных, а также описываются области применения каждой из этих архитектур.
Изучив материал этого занятия, Вы сможете:
описать структуру реляционной базы данных;
объяснить различия между файловыми и клиент-серверными реляционными базами данных;
подобрать тип реляционной базы данных, подходящей для конкретной ситуации.
Структура реляционной базы данных
Реляционная модель — современный стандарт проектирования баз данных. Информация в ней представлена в виде набора таблиц. Отношения между данными определяются не по методу их физического хранения, а на основе отношений между таблицами.
В такой реляционной базе данных, как Microsoft Access, сведения из нескольких таблиц можно комбинировать в одном запросе, форме или отчете.
Независимо от того, как хранятся данные в файле БД, таблицы всегда представлены в виде набора строк и столбцов, как в электронной таблице (рис. 6.1). В реляционной базе данных строки называются записями, а столбцы — полями.
Рис. 6.1 Структура реляционной базы данных
Запись содержит информацию об одном элементе таблицы: например, в таблице Employees БД Northwind (рис. 6.2) это сведения о конкретном сотруднике. Каждое поле таблицы содержит элемент информации записи. Например, таблица Employees включает поля для идентификатора сотрудника (Employee ID), его фамилии (Last Name), имени (First Name) и других данных.
Рис. 6.2 База данных Northwind
Ключ — это поле или поля таблицы, которые проиндексированы для ускорения доступа к записям. Поле (или поля), значения которого однозначно идентифицируют запись, можно назначить первичным ключом. Например, для таблицы Employees наиболее удачный первичный ключ — поле идентификатора сотрудника (Employee ID), поскольку два сотрудника не могут иметь один и тот же идентификатор. Таблица может содержать и внешние ключи — они применяются для идентификации первичного ключа другой таблицы, связанной с данной.
Например, поле «идентификатор клиента» (Customer ID) таблицы заказов БД Northwind позволяет избежать дублирования информации о клиенте для каждого заказа. В таблице заказов такое поле — внешний ключ: оно ссылается на внешнюю по отношению к ней таблицу клиентов. Соотношение между заказами и клиентами, в терминологии реляционных БД, — это отношение «один ко многим»: каждому заказу соответствует один (и только один) клиент, но один клиент может сделать несколько заказов.
Клиент-серверные системы
Занятие 2. Клиент-серверные системы
(Продолжительность занятия 40 минут)
Файловые реляционные базы данных — это мощные настольные СУБД, включающие ядро и хранилище данных. Однако в условиях сложных бизнес-правил и повышенных требований к вычислительной мощности на первый план выходят клиент-серверные системы. На этом занятии Вы познакомитесь с компонентами клиент-серверных систем.
Изучив материал этого занятия, Вы сможете:
перечислить преимущества клиент-серверных систем;
описать стадии разработки клиент-серверного приложения;
сопоставить различные типы клиент-серверных реализаций;
выбрать клиент-серверную систему, подходящую для конкретной ситуации.
Архитектура клиент-сервер
Архитектура клиент-сервер предъявляет специфические требования как к клиенту, так и к серверу. Программа, удовлетворяющая этим требованиям, может считаться клиент-серверным приложением, выполняющим распределенную обработку данных (рис. 6.5).
Рис. 6.5 Клиент, связывающийся с сервером по сети
Под распределенной обработкой понимается выполнение серверной частью программы запросов клиентской части. Серверная часть приложения обеспечивает хранение данных и их обработку, а клиентская часть передает серверу соответствующие запросы.
ODBC
Занятие 3. ODBC
(Продолжительность занятия 35 минут)
Стандарт открытого доступа к базам данных (Open Database Connectivity, ODBC) — это типовой программный интерфейс для построения приложений управления БД в среде Microsoft Windows. ODBC использует специализированные драйверы баз данных подобно тому, как Windows применяет драйвер определенной модели принтера конкретного производителя. Разработчики могут создавать свои собственные драйверы ODBC или использовать разработанные другими фирмами. При конструировании драйвера необходимо учитывать требования соответствия стандарту ODBC.
Из этого занятия Вы узнаете о ODBC и компонентах Windows, задействованных при реализации ODBC-драйверов.
Изучив материал этого занятия, Вы сможете:
описать назначение ODBC;
объяснить роль диспетчера драйверов ODBC;
создать имя источника данных ODBC;
перечислить уровни соответствия стандарту ODBC-драйверов.
Нормализация базы данных
Занятие 4. Нормализация базы данных
(Продолжительность занятия 25 минут)
После разработки реляционная база данных должна быть нормализована. Это позволяет организовать данные и устранить избыточность. Из занятия Вы узнаете о нормализации базы данных, а также зачем иногда нужно денормализовать базу данных.
Изучив материал этого занятия, Вы сможете:
описать разработку структуры базы данных на основе отношений между элементами;
перечислить правила нормализации;
объяснить, зачем требуется денормализация базы данных;
описать три стратегии денормализации базы данных.
Процесс нормализации
Для разработки оптимальной структуры реляционной БД необходимо проанализировать составляющие ее элементы и отношения между ними, а затем нормализовать БД. Эти процедуры помогают выработать логическую модель данных.
Репликация базы данных
Занятие 5. Репликация базы данных
(Продолжительность занятия 40 минут)
Репликация базы данных обеспечивает одновременную работу нескольких пользователей с идентичными локальными копиями БД. Периодическая синхронизация копий позволяет им обмениваться новыми (или измененными) объектами и данными и, таким образом, своевременно обновлять БД.
Средства репликации доступны для баз данных Microsoft Access и SQL Server. Это занятие посвящено репликации баз данных.
Изучив материал этого занятия, Вы сможете:
объяснить цель репликации базы данных;
реплицировать базу данных средствами Microsoft Access;
описать, как реплицировать базу данных средствами SQL Server.
Средства Microsoft Access
Репликация баз данных Microsoft Access — это копирование БД, при котором две или более копии могут обмениваться коррективами данных и объектов. Этот процесс называется синхронизацией. Копия БД — реплика — содержит общий для всей БД набор таблиц, запросов, форм, отчетов, макросов и модулей, а кроме того, и локальные объекты, существующие только в той реплике, где они были созданы.
Каждая реплика является частью набора реплик, который содержит все копии и оригинал — основную реплику (Design Master) набора (рис. 6.19). Копии из одного набора могут обмениваться обновленными данными или реплицируемыми объектами, однако проект базы данных корректируется только в основной реплике.
Рис. 6.19 Набор реплик БД
Репликация средствами Microsoft Access
Существуют три способа репликации БД—с помощью специальных команд Microsoft Access, Портфеля Windows 95 и диспетчера репликации. Все они снабжены удобным интерфейсом (рис. 6.20). Кроме того, объекты доступа к данным (Data Access Objects, DAO) позволяют реализовать репликацию непосредственно в коде приложения.
Рис. 6.20 Средства репликации баз данных Microsoft Access
