Отражение концептуальной схемы в СУБД-ориентированную среду. При разработке логической схемы (ЛС) БД решаются следующие задачи.
1. Уточняют характеристики атрибутов таблиц (сущностей): присваивают уникальные (в рамках одной таблицы) имена, определяют типы полей (целое число, плавающее число, десятичное число, символьная строка, дата и др.) и возможность хранения пустых значений.
2. Определяют атрибуты, для которых СУБД будет строить дополнительные (вторичные) индексы, выбирают способ генерации уникальных ключей.
3. Выполняется оптимизация логической схемы БД, т.е. иногда несколько таблиц объединяют в одну (если основным критерием является производительность) или, наоборот, одна таблица разделяется на несколько (если основным критерием является сокращение дополнительных проверок в ПП, т.е. автоматизация обеспечения целостности БД).
4. Таблицы ЛС БД распределяются по машинам СРОД, выбирается способ тиражирования данных, а также описываются данные, которые будут тиражироваться (оформляется так называемая подписка).
5. С помощью CASE-средств генерируется программа с описанием ЛС БД.
Типы данных, доступные в SQL. SQL – язык описания и манипулирования данными, используемый практически во всех СУБД, поддерживающих архитектуру клиент/сервер. Существуют стандарты для этого языка (SQL/89 и SQL/92).
При анализе КС БД надо решить, каким типом данных будет представляться тот или иной атрибут. Выбор типа данных влияет на объем БД, скорость поиска, допустимые с этим атрибутом операции и т.д.
Ниже рассматриваются типы данных, используемые в СУБД. Здесь приведены идентификаторы типов, принятые в стандартах SQL/89 и SQL/92. В скобках указаны идентификаторы, используемые в некоторых СУБД.
|
|
INTEGER, SMALLINT – целое и короткое целое. Предназначены для представления счетчиков, каких-либо кодов и т.д. Для хранения значений этого типа используют соответственно 4 и 2 байт памяти. Таким образом, диапазон допустимых значений для INTEGER составляет от -2 147 483 647 до 2 147 483 647, а для SMALLINT от -32 767 до 32 767. Как недостаток следует отметить ограниченный набор значений.
DOUBLE PRECISION (FLOAT), FLOAT (SMALLFLOAT) – типы данных, предназначенные для представления нецелых чисел. Обычно используются для хранения научных, экспериментальных, статистических данных. Внутреннее представление значений состоит из мантиссы и порядка. Объем памяти (число байтов), выделяемый для хранения значений данных, зависит от используемого компьютера, но, как правило, составляет 8 байт для DOUBLE PRECISION и 4 байт для FLOAT. Количество значащих цифр у DOUBLE PRECISION равно шестнадцати десятичным цифрам, а у FLOAT – восьми.
DEZIMAL(p) – тип данных, аналогичный DOUBLE PRECISION, но предназначенный для хранения величин с фиксированным числом значащих цифр. Число значащих цифр (параметр р) находится в пределах от 1 до 32, а диапазон допустимых значений от 10–128 до 10126. По сравнению с DOUBLE PRECISION тип данных DEZIMAL(p) имеет два преимущества:
точность представления можно регулировать;
размер требуемой памяти зависит от точности.
Однако необходимо отметить и недостатки:
операции сортировки и арифметические операции занимают больше времени, чем при использовании DOUBLE PRECISION;
не все языки программирования поддерживают тип данных с фиксированной точностью, поэтому если SQL встроен, например, в языке С, то для преобразования типов требуются специальные функции.
|
|
DEZIMAL(p, n) – тип данных, предназначенный для хранения величин с фиксированным числом значащих цифр до и после запятой. Параметр р задает общее число десятичных цифр, an – их количество после запятой. Таким образом, DEZIMAL(p, n) позволяет хранить числа, в десятичном представлении которых содержится не более 32 цифр. Объем памяти для хранения одного значения составляет (1 + р/2) байт. Этот тип данных имеет те же достоинства и недостатки, что и DEZIMAL(p).
DATE – тип данных, предназначенный для хранения дат. По сути его значение представляет собой число дней, прошедших с 31 декабря 1899 г. Поскольку это значение может быть отрицательным, можно хранить и даты до 1899 г. Выделяемый под него объем памяти составляет 4 байт, поэтому диапазон допустимых значений очень широк – около 58 000 столетий вперед и назад. Форматирование ввода и вывода для переменных DATE может быть указано с помощью внешних переменных.
DATETIME (DATE) – тип данных, предназначенный для хранения моментов времени. DATETIME содержит информацию о годе (YEAR), месяце (MONTH), дне (DAY), часе (HOUR), минуте (MINUTE), секунде (SECOND) и долях секунды (FRACTION). Нужный диапазон значений выбирается индивидуально. Например, если требуется зафиксировать момент времени с точностью до секунды в течение дня, то следует указать тип DATETIME HOUR TO SECOND. Если же интересует информация о каком-либо событии с точностью до минуты, но в произвольном году, то тип данных должен быть описан как DATETIME YEAR TO MINUTE. При указании долей секунды необходимо отмечать точность представления. Так, FRACTION(l) указывает время с точностью до десятых долей, FRACTION(2) – до сотых, a FRACTION(3) – до тысячных. Тип DATETIME позволяет хранить данные более точно, чем DATE, однако требует выделения большего объема памяти и обрабатывается медленнее.
|
|
INTERVAL – тип данных, предназначенный для хранения временных интервалов. Его значение получают, например, путем вычитания одной даты из другой. Как и для DATETIME, здесь следует уточнять диапазон возможных значений.
CHARACTER(n) (CHAR, CHAR(n)) – типы данных, предназначенные для хранения символьных строк фиксированной длины. Параметр n задает длину строки, максимальное значение равно 32 767 (для разных СУБД эта величина может отличаться). Для хранения данных всегда отводится n байт вне зависимости от реальной длины строки.
VARCHAR(m) – тип данных, предназначенный для хранения короткой (до 255) символьной строки переменной длины. Параметр m задает максимальную длину строки, но не более 255 символов. Для значения типа VARCHAR в памяти выделяется столько байт, сколько реально занимает строка.
BYTE (LONG RAW) – тип данных, предназначенный для хранения двоичных объектов произвольного объема. Его можно (и нужно) использовать для хранения исполняемых файлов, оцифрованных картинок, звука и др. Размер типа BYTE может достигать 2 Гбайт.
Во многих СУБД встречаются следующие типы данных (для разных СУБД идентификаторы типов могут отличаться):
SERIAL – тип данных на основе INTEGER. Предназначен для хранения уникального ключа. Только одно поле в таблице может иметь тип SERIAL. Если какое-то поле имеет указанный тип, СУБД автоматически отслеживает, чтобы в таблице не было двух записей с одинаковым значением этого поля. Если в таблицу включается новая запись, то СУБД автоматически генерирует новое уникальное значение этого типа.
MONEY(p, n) – тип данных, предназначенный для хранения денежных величин. В отличие от DEZIMAL(p, n) для него в некоторых языках предусмотрены специальные способы форматирования на основе некоторых внешних по отношению к программе переменных окружения. Это позволяет писать программы, не зависящие от формы представления денежных величин в каждой конкретной стране (например, величина 3 000 000 будет печататься либо как $3,000,000.00, либо как 3.000.000,00 руб.);
TEXT (LONG) – тип данных, предназначенный для хранения символьных строк произвольной переменной длины. По сравнению с VARCHAR для типа TEXT характерны повышенные накладные расходы (повышенный объем памяти для хранения одного значения и менее эффективный поиск), но при этом практически нет ограничений на длину строки (до 2 Гбайт).
Для каждого из перечисленных типов данных существуют свои операции, свои значения, но есть у них и одно общее значение – NULL (не определено). Не следует путать его с нулем, так как нуль – это вполне определенное значение, a NULL подразумевает, что никакого определенного значения в атрибут не записывалось.
Кроме того, во всех приведенных типах данных для разных СУБД их обозначения могут отличаться. Поэтому перед использованием типов данных следует тщательно изучить руководство по конкретной СУБД.
Для манипулирования с БД и ее таблицами обычно используют следующие группы SQL-операторов (DDL-операторы).
1. Создание, открытие, закрытие, удаление БД (именованной совокупности таблиц):
• CREATE DATABASE <имя базы>...
• DATABASE <имя базы>
• CLOSE DATABASE <имя базы>
• DROP DATABASE <имя базы>
2. Создание, удаление таблицы в базе данных:
• CREATE TABLE <имя таблицы> (<имя поля> <тип поля> [NOT NULL],...)
• DROP TABLE <имя таблицы>
3. Добавление новых полей (атрибутов) в таблицу, удаление ненужных полей, модификация типов полей:
• ALTER TABLE <имя таблицы> ADD (<имя поля> <тип поля> [NOT NULL],...) – часто этот оператор используется для присваивания атрибуту (или группе атрибутов) признака первичного ключа
• ALTER TABLE <имя таблицы> DROP (<имя поля>,...)
• ALTER TABLE <имя таблицы> MODIFY (<имя поля> <тип поля> [NOT NULL],...)
Оптимизация логической схемы базы данных. Задача оптимизации ЛС БД связана, в основном, с перераспределением атрибутов ПО по таблицам БД. Рассмотрим ключи таблицы. Ключом таблицы БД называется совокупность атрибутов, которые определяют все другие атрибуты этой таблицы, т.е. не существует двух записей с тем же значением ключа. В примере на рис. 12.1 поле «Код поставщика» не является ключом, так как существуют записи с одним и тем же значением этого поля (например, 01), но с разными значениями поля «Товар» (записи 1, 2). Здесь ключом являются два поля «Код поставщика» и «Товар».
Рис. 12.1. Пример таблицы базы данных
Рис. 12.2. Атрибуты базы данных «Поставщик»
Рис. 12.3. Пример Ек-диаграммы
Рассмотрим случай когда неправильное распределение атрибутов ПО может привести к неправильным результатам поиска.
Предположим, что для магазина разрабатывается БД «Поставщик», которая должна включать атрибуты, показанные на рис. 12.2.
Пусть проектировщик определил ER-диаграмму, представленную на рис. 12.3.
Рис. 12.4. Пример наполнения БД
Рис. 12.5. Результат выполнения запроса SELECT
Предположим также, что в процессе функционирования системы в таблицы этой БД были включены записи (рис. 12.4). Пусть выполняется следующий запрос:
SELECT (что найти) Код поставщика, Адрес поставщика, Товар, Цена за единицу
FROM (из таблиц) Поставщики товаров, Товар и цена
WHERE (при условии) Поставщики товаров.Товар = Товар и цена.Товар
AND Код поставщика = 01;
В результате получим таблицу, представленную на рис. 12.5.
Таким образом, поставщик 01 поставляет один и тот же товар по разной цене. Такая аномалия называется нарушением свойства соединения таблиц без потери информации. Чтобы избежать этой ошибки, следует контролировать соблюдение одного из следующих условий.
1. База данных (вернее схема БД) может состоять только из одной таблицы (рис. 12.6).
Рис. 12.6. Пример базы данных «Поставщик», состоящей из одной таблицы
Рис. 12.7. Пример базы данных «Поставщик» с двумя таблицами
2. Если две таблицы А и В имеют общие атрибуты, то эти атрибуты должны содержать ключ хотя бы одной из таблиц (А или В)(рис. 12.7).
Здесь общий атрибут «Код поставщика» является ключом таблицы Адрес.
3. Таблицы А и В могут и не иметь общих атрибутов. Но в этом случае теряется возможность соединения (связывания) этих таблиц.
Расмотрим случай, когда неправильное построение БД приводит к избыточности, потенциальной противоречивости, к аномалиям включения и удаления данных. Например, БД приведенная на рис. 12.6, имеет следующие недостатки:
1) избыточность. Адрес поставщика повторяется для каждого поставляемого им товара;
2) потенциальная противоречивость (аномалия обновления). Вследствие избыточности при изменении адреса поставщика важно не забыть обновить этот адрес во всех записях, куда он входит;
3) аномалия включения. В базу данных не может быть записан адрес поставщика, если он в настоящее время не поставляет по меньшей мере один товар. Можно, конечно, поместить неопределенное значение (NULL) в поля «Товар» и «Цена за единицу» записи поставщика. Но если он начнет поставлять некоторый товар, важно не забыть удалить запись (кортеж) с неопределенными значениями. Хуже того, поля «Код поставщика» и «Товар» образуют ключ таблицы «Поставщик» (см. рис. 12.6) и поиск кортежей с неопределенными значениями в ключе может быть затруднительным или
невозможным;
4) аномалия удаления. После удаления из базы всех товаров поставщика теряется и его адрес.
Схема базы данных, представленная на рис. 12.7, не имеет указанных недостатков. Это связано с тем, что каждая из таблиц схемы БД находится в третьей нормальной форме.
Можно предложить простой способ построения таблицы в третьей нормальной форме. Таблица будет находиться в третьей нормальной форме, если каждый ее атрибут зависит только от ключа этой таблицы. Если это не так, то следует таким образом декомпозировать таблицу, чтобы для новых таблиц выполнялось приведенное выше свойство.
Для схемы, показанной на рис. 12.6, атрибут «Адрес поставщика» зависит не только от ключа («Код поставщика», «Товар»), но и от атрибута «Код поставщика». Поэтому таблица, приведеная на рис. 12.6, не находится в третьей нормальной форме. После декомпозиции (см. рис. 12.7) каждая из новых таблиц «Адрес» и «Товар» находится в третьей нормальной форме.
Часто для увеличения производительности системы проектировщики отказываются от нормализации той или иной таблицы.
Выбор способа тиражирования данных в распределенной системе. В настоящее время в СРОД поддерживаются два метода автоматической репликации (копирования) данных:
• синхронный (метод двухфазной фиксации);
• асинхронный (метод тиражирования).
Первый метод репликации рассматривается в гл. 13. Рассмотрим способы тиражирования данных, относящихся к асинхронному методу.
На рис. 12.8 приведена общая схема организации тиражирования. В процессе выполнения ПП ведет так называемые логические транзакции. Транзакция начинается командой НТ и завершается командой КТ. При выполнении программы сервер СУБД сохраняет в журнале изменений отметки начала и конца транзакции, а также все изменения, выполненные в БД за этот период. Сервер, где можно модифицировать таблицы БД, называют первичным сервером, а изменяемые данные таблиц – первичными данными. В узле, содержащем первичные данные, для каждой тиражируемой БД запускается специальный компонент: менеджер журнала транзакций (LTM – Log Transfer Manager). Он подключается к серверу СУБД и получает от него уведомления о завершении транзакций. Данные (транзакция) из журнала изменений передаются репликационному серверу, обслуживающему этот узел.
Репликационный сервер (RS) представляет собой отдельную задачу, запускаемую одновременно с сервером СУБД. Он имеет свой входной язык и стандартный для конкретной СУБД сетевой интерфейс. RS просматривает публикации (т.е. описания данных, которые могут копироваться с сервера), подписки на публикации (т.е. описание ссылок других серверов на публикации) и оправляет данные транзакции по месту назначения. Асинхронная репликация принципиально обеспечивает целостность данных, так как:
• объектом обмена данными здесь является логическая единица работы – транзакция, а не просто данные из измененных таблиц;
• все данные тиражируются из одного первичного сервера.
Рис. 12.8. Схема тиражирования данных
Во всех основных распределенных СУБД единицей изменения является запись таблицы. Источником тиражирования выступает транзакционный файл изменений. В СУБД Oracle репликсируемые данные читаются из специального журнала тиражирования. Специальный триггер Oracle срабатывает после обновления таблицы и помещает измененные данные в журнал тиражирования.
Существует несколько способов тиражирования данных, различающихся схемами связей копий.
Тиражирование из первичного (основного) узла (рис. 12.9). Эта схема является основной и она реализована во всех крупных СУБД, поддерживающих распределенную обработку (Oracle, Sybase, DB/2 и др.). В СУБД Informix реализован механизм полного тиражирования данных одного сервера на другой (резервный). Наличие одного (для группы строк таблицы) первичного сервера является принципиально важным, так как позволяет избежать:
• зацикливания при обновлении (копия не может распространять изменения),
• конфликтов при обновлении копии (репликационный сервер первичного сервера распространяет транзакции последовательно, репликационный сервер вторичного сервера принимает и обрабатывает транзакции также последовательно).
Рис. 12.9. Тиражирование из основного узла
Рис. 12.10. Тиражирование из первичного сервера или его резерва
Тиражирование из первичного сервера и его резерва (рис. 12.10). Эта схема реализуется в системах с СУБД Oracle и Ingres. Здесь резервный сервер работает в режиме горячего резервирования: измененные данные тут же пересылаются на резервный сервер. Резервный сервер периодически опрашивает основной сервер по специальному кабелю. Если при очередном опросе основной сервер не отвечает, то резервный сервер считает, что первичный сервер вышел из строя, и начинает работать в качестве основного. Он принимает изменения и тиражирует их на вторичные серверы. Ясно, что основной и резервный серверы должны быть подключены к одной сети. Использование резерва резко повышает надежность всей системы.
Поточная модель (рис. 12.11). Владелец, т.е. узел, который объявляется первичным, может меняться динамически. Эта схема использована в Oracle, ее удобно применять, если основной поток изменений поступает с тех рабочих станций, которые расположены вблизи какого-либо вторичного сервера.
Рис. 12.11. Поточная модель тиражирования
Рис. 12.12. Иерархическая модель тиражирования
Иерархическая модель (рис. 12.12). В предыдущих случаях предполагалось, что между первичным и вторичным сервером существует виртуальный канал связи, т.е. логический канал, включающий несколько физических линий связи, коммутаторов, маршрутизаторов, мостов, шлюзов и т.д. В данной схеме такого виртуального канала связи между первичным и вторичным сервером может и не существовать. Тиражирование может быть реализовано через промежуточный сервер СУБД, для которого предусмотрен виртуальный канал связи с основным сервером.
В заключение следует отметить, что тиражируемые данные не теряются – при выходе из строя вторичного сервера или канала связи транзакции сохраняются в стабильной очереди на основном сервере, а затем передаются на вторичный сервер, когда это становится возможным.
По умолчанию репликационный сервер сохраняет смысл операций. Это значит, что удаление записи из первичной таблицы (выполнение оператора DELETE) приведет к выполнению такого же оператора DELETE на вторичном сервере, хранящем копию таблицы. Выполнение INSERT или UPDATE над первичной таблицей приведет, соответственно, к добавлению или обновлению записи в копии таблицы в результате работы системы репликации, для чего предусмотрен гибкий механизм конфигурирования так называемых функциональных строк (function strings), которые переопределяют любую операцию на макроязыке с подстановкой параметров.
Технологии тиражирования данных имеют следующие преимущества:
• данные всегда расположены там, где они обрабатываются, следовательно, скорость доступа к данным существенно увеличивается;
• передача только операций, изменяющих данные, и к тому же в асинхронном режиме позволяет значительно уменьшить трафик;
• для принимающей БД репликатор исходной БД выступает как процесс, инициированный одним пользователем;
• продолжительный сбой связи не нарушает передачу изменений. Дело в том, что тиражирование предполагает буферизацию потока изменений (транзакций). После восстановления связи передача возобновляется с той транзакции, на которой тиражирование было прервано.
Планирование тиражирования данных. Планирование тиражирования данных связано с проблемой распределения таблиц БД по машинам распределенной системы. При решении этой задачи следует принимать во внимание три фактора:
• как часто одни и те же данные должны использоваться в разных узлах;
• какие данные должны тиражироваться;
• должен ли клиент, подключенный к серверу, где хранится копия таблицы, обновлять эту таблицу.
Расмотрим эти факторы подробнее.
1. Если таблица часто используется в разных узлах и каналы связи между этими узлами достаточно надежны, то рекомендуется организовать тиражирование данных.
Рассмотрим пример. На рис. 11.1 представлена КС БД «БДЗ. Ценные бумаги». Если требуется оперативно принимать решения о купле/продаже ценных бумаг, то таблица «Курс продажи» должна храниться на серверах всех торговых площадок (бирж), где проходят торги, а также на серверах организаций (например, различных паевых фондов), заинтересованных в результатах торгов. Если разные части таблицы, хранящиеся в разных узлах, используются нечасто или каналы связи не совсем надежны, то лучше эти части таблицы хранить в разных узлах и связь между ними поддерживать с помощью удаленных запросов.
Связь между банком и его филиалами можно организовать и электронной почтой, хотя это менее надежно и не так быстро.
2. Второй фактор связан с тем, какие данные должны тиражироваться. Предположим, что на вторичных серверах в городах С.-Петербург и Н. Новгород хранятся две таблицы (рис. 12.13):
Рис. 12.13. Пример подписки на публикации
• «Курс продажи» – это вторичные данные (только для чтения) первичной таблицы «Курс продажи», которая располагается на сервере СУБД 01;
• «Курс продажи в г. С.-Петербург (Н. Новгород)» – это локальные таблицы (для чтения и обновления), которые хранятся на серверах в соответствующих городах.
В ходе торгов данные из таблицы «Курс продажи в г. С.-Петербург (Н. Новгород)» копируются с помощью удаленного запроса UPDATE в основную таблицу «Курс продажи», которая хранится в г. Москве.
Ясно, что при такой схеме хранения таблиц вторичные серверы должны получать данные только о тех торгах с ценными бумагами, которые прошли в других городах. Для этого необходимо организовать подписку сервера 02 на публикации «Код организации» = 01 и «Код организации» = 03. Здесь «Код организации» – это поле ключа таблицы «Курс продажи» (рис. 11.1), а 01 и 03 – коды соответствующих бирж. В этом случае основной сервер 01 будет копировать на сервер СУБД 02 только данные о торгах в Москве и Н. Новгороде. Аналогично можно выполнить подписку сервера 03 на публикации «Код организации» = 01 и «Код организации» = 02.
3. Теперь рассмотрим вопрос, как может быть выполнено обновление копии таблицы клиентом, работающим со вторичным сервером. Приведенная на рис. 12.13 схема обновления данных имеет некоторые недостатки:
• курсы продаж ценных бумаг хранятся на вторичных серверах в разных таблицах, хотя они имеют один и тот же набор атрибутов (этот недостаток не является принципиальным, так как обновление по схеме на рис. 12.13 можно организовать и с одной таблицей на вторичном сервере: просто кортежи котировок из других городов будут заблокированы),
• для выполнения обновления (UPDATE) в таблице «Курс продажи» на основном сервере необходимо для вторичного сервера разработать специальную процедуру удаленного копирования по концу транзакции.
Эти недостатки можно устранить, воспользовавшись механизмом асинхронного вызова процедур. На рис. 12.14 представлен пример обновления данных на двух узлах.
Предположим, что клиенту, подключенному ко вторичному серверу 02, необходимо сделать изменения в таблице «Курс продажи» этого сервера. Напрямую он не может этого сделать, так как на вторичных серверах хранятся копии для чтения. Прежде всего на вторичном сервере необходимо создать пустую хранимую процедуру «Обновление» с параметрами, опубликовать ее и выполнить подписку основного сервера 01 на эту публикацию. На основном сервере необходимо создать процедуру с тем же именем и параметрами, но тело этой процедуры должно включать необходимые команды обновления. Процесс обновления данных выглядит следующим образом. Машина-клиент вызывает процедуру «Обновление» с требуемыми параметрами (код организации, данные для обновления и др.). На вторичном сервере запускается пустая процедура. На сервер 01 по подписке передаются входные параметры этой процедуры и на нем запускается одноименная процедура («Обновление»). Данная процедура выполняет обновления на сервере СУБД 01. Но так как на основном узле для сервера 02 выполнена подписка на изменения, то данные тиражируются на вторичный сервер в таблицу «Курс продажи».
Таким образом, изменения на вторичном сервере реализуются через основной сервер. Конечно, для эффективной работы рассматриваемой схемы обновления требуется высокая производительность и надежность каналов связи, но при этом отпадает необходимость дублирования функций репликационного сервера при создании процедуры обновления на вторичном сервере (см. UPDATE на рис. 12.13).
Рис. 12.14. Пример асинхронного вызова процедуры «Обновление»
Рис. 12.15. Окно Fastpath Table Mappig
Описание логической схемы базы данных с помощью пакета CASE*Dictionary. Продолжим рассмотрение примеров, приведенных в гл. 10 и 11. Запустите CASE*Dictionary (Oracle) и выберите пункт Design/Menu, чтобы начать этап проектирования.
1. В CASE*Dictionary имеются некоторые утилиты этапа проектирования, позволяющие быстро перейти к этапу проектирования от этапа анализа (концептуального проектирования). Выберите пункт Design/Data Design Utilities/Fastpath Table Mapping. На экране появится окно, показанное на рис. 12.15.
При отображении этого окна выводится подсказка для ввода имени приложения (если оно отсутствует). В данном случае следует ввести SECURITES, а записи в поле Entity оставить пустыми. Чтобы все определенные ранее имена сущностей появились в окне, нажмите клавишу [Execute Query]. Перемещая курсор на каждое имя сущности и нажимая клавишу [Commit], можно задать для каждой сущности имя соответствующей таблицы БД. После этого экран будет выглядеть как показано на рис. 12.15 (на нем будут показаны таблицы БД «БДЗ. Ценные бумаги»). После этого можно вернуться в меню Data Design Utilities.
Рис. 12.16. Описания столбцов таблицы
2. После описания таблиц можно определить для них столбцы. Для создания примерного набора столбцов (их можно позднее при необходимости модифицировать), CASE*Dictionary использует информацию об атрибутах и сущностях, т.е. системную информацию в хранилище. Чтобы автоматически создать столбцы таблицы, выберите пункт меню Design/Data Design Utilities/Default Database Design. Ответьте на запрос о выбираемом действии (выберите R, что означает замену), введите имя системы (SECURITES), ее версию (1) и имена таблиц (4-я колонка на рис. 12.15). После этого CASE*Dictionary создает для заданных таблиц столбцы. Чтобы посмотреть новые столбцы таблиц, выберите пункт Design/Database Design/Table Columns/Column Definition. CASE*Dictionary выводит окно Column Definition. Это окно должно быть пустым. Введите имя таблицы, например SEC COU
(курс продажи), и нажмите клавишу [Next Field]. После этого CASE*Dictionary заполняет столбцы информацией о вновь сгенерированных столбцах таблицы. Так как эти определения столбцов являются не реальными, а определениями CASE*Dictionary, то можно отредактировать имена столбцов, типы данных, заданные по умолчанию значения и т.д. (рис. 12.16).
3. Средство CASE*Dictionary автоматически конфигурирует различные ключи таблиц вашей системы, но иногда оно не может идентифицировать на основе заданной информации все необходимые ключи. В таких случаях используется окно, появляющееся после выбора пункта меню Design/Database Design/Table Columns/Table Key Constraints Definition. Например, введите в поле Table Name имя таблицы SEC_COU (курс продажи), клавишей [Next Block] переместите курсор в блок полей Unique Key и клавишами [List] и [Next Block] добавьте составной первичный ключ, включающий в себя столбцы COU_DATE (дата торгов), COU_CODE_ISSUE (код эмиссии ЦБ), COU_CODE_ORG (код организации). Это же окно используется и для просмотра первичных ключей (PRIMARY KEY), внешних ключей (FOREIGN KEY), альтернативных ключей и признаков их уникальности (UNIQUE).
Первичный ключ таблицы – это один или несколько столбцов, однозначно идентифицирующих запись таблицы. Если существует несколько ключей, то один из них проектировщик определяет как первичный. Для первичного ключа СУБД, как правило, автоматически создает индекс.
Внешний ключ – это ключ родительской сущности. Например, столбцы COU_CODE_ISSUE (код эмиссии ЦБ), COU_CODE_ORG (код организации) являются внешними ключами таблицы SEC_COU (курс продажи).
Альтернативный (вторичный) ключ – это столбец или группа столбцов, не совпадающих с первичным ключом и однозначно идентифицирующих запись таблицы. Для альтернативного ключа можно потребовать от СУБД проверки уникальности.
4. CASE*Dictionary позволяет при включении записей в БД автоматически генерировать значения первичных ключей (обычно для числовых значений ключей). Для этого сначала с помощью пункта меню Design/Database Design/Sequence Definition необходимо определить правило формирования последовательности ключей, а затем с помощью окна описания столбцов таблицы (см. рис. 12.16) в колонке Sequence назначить первичному ключу идентификатор этого правила (чтобы посмотреть на рис. 12.16 эту колонку необходимо выполнить горизонтальный скроллинг колонок окна).
Генерация описания логической схемы в нотации конкретной СУБД с помощью пакета Erwin. Продолжим рассмотрение примера, приведенного в гл. 11.
1. Прежде всего необходимо определить СУБД, для которой будет выполняться генерация ЛС. Выберите пункт меню Server/Target Server. В появившемся окне укажите, например, на Oracle, выберите версию 7 и щелкните мышкой на ОК.
2. Нажмите правую клавишу мыши и выберите пункт ORACLE Database Schema. На экране появляется окно ORACLE DATABASE SCHEMA.
Выберите в открывающемся списке Entity, например, сущность «Курс продажи» и в поле ввода Table введите имя соответствующей таблицы, например, SEC_COU. Выберите в блоке Column Name какой-либо атрибут КС (например, «Дата торгов») и в поле ввода Column введите имя столбца таблицы (например, COU_DATE).
Затем в списке ORACLE Datatype выберите тип поля DATE. С помощью кнопки Validation можно определить список допустимых интервалов значений поля столбца и из открывающегося списка Valid выбрать требуемый интервал. Также с помощью кнопки Default и открывающегося списка Default можно установить значение поля по умолчанию.
Выполните указанные действия для всех сущностей и атрибутов КС и нажмите кнопку ОК. Чтобы посмотреть ЛС БД в графическом виде, нажмите 8-ю слева кнопку под строкой основного меню. При повторном нажатии этой кнопки на экране вновь появляется ER-диаграмма.
3. Чтобы сгенерировать ЛС, выберите пункт меню Server/ORACLE Schema Generation. На экране появляется окно ORACLE Schema Generation Report. Вы можете подключиться к Oracle и сгенерировать ЛС (кнопка Generate), вывести программу PL/SQL описания ЛС в файл (кнопка Report) или посмотреть ЛС (кнопка Preview).
Пример генерируемой программы приведен ниже. Там же показано, как с помощью пакета Erwin выполняется описание ограничений целостности БД.
Разработка приложений
Все прикладные программы (приложения) для систем распределенной обработки данных, разрабатываемые в архитектуре клиент/сервер, условно можно разделить на три группы.
1. Приложения, выполняемые под управлением сервера СУБД (хранимые процедуры, триггеры). Как правило, они разрабатываются инструментальными средствами самих СУБД.
2. Приложения, выполняемые на рабочих станциях (станциях-клиентах) и связывающиеся с серверами СУБД по мере необходимости. Существует очень много продуктов, позволяющих разрабатывать приложения подобного типа. Такие средства предлагают как фирмы-разработчики
СУБД, так и независимые компании. Как правило, это инструментальные средства, поддерживающие визуальные языки программирования (4GL).
3. Прикладные программы для серверов приложений (мониторов транзакций). Серверы приложений часто используются как маршрутизаторы запросов к ПП, а также для повышения производительности системы. Поэтому ПП здесь разрабатывают, как правило, на языках низкого уровня (С, C++, COBOL).
Первые две группы приложений рассматриваются ниже, а серверы приложений – в гл. 13.