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

Ю. А. Григорьев, Г. И. Ревунков - Банки данных

.pdf
Скачиваний:
339
Добавлен:
10.02.2015
Размер:
7.54 Mб
Скачать

//. Концептуальное проектирование систем распределенной обработки данны

@СПЕЦ.ПРОЦ. 1.3.1. Анализ котировок ЦБ за последнюю декаду @ВХОД —нет @ВЫХОД — таблица изменения котировок

ВЫПОЛНИТЬ

Описать курсор: найти в базе данных «БДЗ. Ценные бумаги»

 

наименование ЦБ, дату торгов, котировку ЦБ за последнюю декаду

ВЫПОЛНИТЬ

открыть курсор

 

ДЛЯ всех записей курсора

 

ЕСЛИ ЦБ с другим именем

 

 

ВЫПОЛНИТЬ Перейти к следующей строке выходной таблицы,

 

включить в выходную таблицу код эмиссии ЦБ,

 

наименование ЦБ, дату начала декады, котировку

ИНАЧЕ

ЦБ на начало декады (переменная $)

ВЫПОЛНИТЬ 5 = котировка ЦБ — $

 

 

ЕСЛИ 5 > некоторое критическое значение

 

ВЫПОЛНИТЬ

Отметить, что 5 необходимо выводить

 

ИНАЧЕ

красным цветом

 

 

 

ВЫПОЛНИТЬ

Отметить, что 5 необходимо выводить

 

КОНЕЦ ЕСЛИ

синим цветом

 

 

ВЫПОЛНИТЬ Вывести дату торгов и 8 в текущую строку выходной таблицы

КОНЕЦ ЕСЛИ КОНЕЦ ДЛЯ ©КОНЕЦ СПЕЦ.ПРОЦ 1.3.1

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

Таблицы решений. Проектирование спецификаций процессов с помо­ щью таблиц решений заключается в задании матрицы, отражающей множество условий и возможные действия программы или пользователя. В табл. 11.5 при­ веден пример настройки таблицы решений для отображения кода эмиссии ЦБ, наименования ЦБ, даты торгов и котировки ЦБ. Описание, приведенное в табл. 11.5, означает, что после генерации модуля на экране будут отображаться по два атрибута таблиц «Эмиссия ЦБ» и «Курс продажи».

Все атрибуты сущностей являются отображаемыми (поля в колонке Display? установлены в Y). По атрибутам можно выпoл^^ять поиск (поля в колонке Select? установлены в Y). Все указанные в табл. 11.5 атрибуты нельзя включать и модифицировать, а поэтому нельзя и задавать пустые значения. В колонке «Длина» указаны размеры соответствующих полей на экране. Пустая последняя колонка означает, что имя поля на экране совпа­ дает с именем соответствующего атрибута в БД.

200

11.3.Способы описания спецификаций процессов

Та б л и ц а 11.5. Пример настройки таблицы решений

Атрибут сущности

Display?

Insert?

Select?

Update?

Nullify?

Длина

Имя

поля

Сущность «Эмиссия

 

 

 

 

 

 

 

 

 

 

 

 

 

ЦБ»:

 

 

 

 

 

 

 

1. Код эмиссии ЦБ

Y

N

Y

N

N

6

 

2. Наименование ЦБ

Y

N

Y

N

N

20

 

Сущность «Курс

 

 

 

 

 

 

 

продажи»:

 

 

 

 

 

 

 

1. Дата торгов

Y

N

У

N

N

И

 

2. Котировка ЦБ

У

N

У

N

N

10

 

Приведенный выше подход к описанию спецификаций программ ис­ пользуется в Oracle. По таблице решений ORACLE*Generator автоматиче­ ски генерирует текст программы.

Визуальные языки проектирования спецификаций. Такие языки представляют относительно новую оригинальную методику описания про­ цесса. Они базируются на основных идеях структурного программирования и позволяют определять потоки управления с помощью специальных иерар­ хически организованных схем.

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

А

if А

 

case of

 

 

1

А,

В

then

В

 

 

else

С

2

 

С

А2

 

 

п

А„

 

 

 

Последовательная

Условный выбор

case-выбор

обработка

 

 

 

 

while А

do

В

1

for А

do В

Until А

do

В

 

Циклы

 

 

Рис.11.3. Символы FLOW-формы

 

 

201

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

Описать курсор: найти в базе данных "БДЗ. Ценные бумаги" код эмиссии ЦБ, наименование ЦБ, дату торгов, котировку ЦБ за последнюю декаду.

Открыть курсор

for для всех записей курсора

do

If новая ЦБ

then

else

Перейти к следующей строке выходной таблицы, включить в выходную таблицу код эмиссии ЦБ, наименование ЦБ, дату начала декады, котировку ЦБ на начало декады ($)

5 = котировка ЦБ — $

If 5 > критического значения

then

Отметить, что 5

необходимо

 

выводить красным цветом

else

Отметить, что 5

необходимо

 

выводить синим цветом

Вывести дату торгов и 5 в текущую строку выходной таблицы

Рис. 11.4. Пример описания спецификаций на визуальном языке проектирования

Дальнейшее развитие FLOW-формы получили в диаграммах НассиШнейдермана. Эти диаграммы отличаются от FLOW-форм обозначениями символов условного выбора и Case-выбора.

На рис. 11.4 приведен пример описания спецификаций задачи «Ана­ лиз котировок ЦБ и принятие решений об их продаже».

202

11.3. Способы описания спецификаций процессов

Контрольные вопросы

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

2.Опишите последовательность действий при синтезе КС.

3.Приведите пример описания КС средствами CASE*Designer.

4.Перечислите способы описания спецификаций процессов.

5.Приведите пример описания КС с помощью пакета Erwin.

12. ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ СИСТЕМ РАСПРЕДЕЛЕННОЙ ОБРАБОТКИ ДАННЫХ

На этапе логического проектирования систем распределенной обра­ ботки данных (СРОД) выполняется отобраэюение концептуального проекта (см, предыдущий раздел) в СУБД-ориентированную среду. На базе концепту­ альной схемы базы данных разрабатывается логическая схема БД, а специ­ фикации процессов используются для кодирования прикладных программ.

12.1. Разработка логической схемы базы данных

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

1. Уточняют характеристики атрибутов таблиц (сущностей): присваи­ вают уникальные (в рамках одной таблицы) имена, определяют типы полей (целое число, плавающее число, десятичное число, символьная строка, дата

идр.) и возможность хранения пустых значений.

2.Определяют атрибуты, для которых СУБД будет строить дополни­ тельные (вторичные) индексы, выбирают способ генерации уникальных ключей.

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

вПП, т.е. автоматизация обеспечения целостности БД).

4.Таблицы ЛС БД распределяются по машинам СРОД, выбирается способ тиражирования данных, а также описываются данные, которые бу­ дут тиражироваться (оформляется так называемая подписка).

5.С помощью CASE-средств генерируется программа с описани­ ем ЛС БД.

Типы данных, доступные в SQL. SQL — язык описания и манипу­ лирования данными, используемый практически во всех СУБД, поддержи­ вающих архитектуру клиент/сервер. Существуют стандарты для этого языка (SQL/89 и SQL/92).

При анализе КС БД надо решить, каким типом данных будет пред­ ставляться тот или иной атрибут. Выбор типа данных влияет на объем БД, скорость поиска, допустимые с этим атрибутом операции и т.д.

204

12.1. Разработка логической схемы базы данных

Ниже рассматриваются типы данных, используемые в СУБД. Здесь приведены идентификаторы типов, принятые в стандартах SQL/89 и SQL/92. В скобках указаны идентификаторы, используемые в некоторых СУБД.

FNTEGER, 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~^^^ до 10'^^. По сравнению с DOUBLE PRECISION тип данных DEZIMAL(p) имеет два преимущества:

точность представления можно регулировать; размер требуемой памяти зависит от точности. Однако необходимо отметить и недостатки:

операции сортировки и арифметические операции занимают больше времени, чем при использовании DOUBLE PRECISION;

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

DEZIMAL(p, п) — тип данных, предназначенный для хранения вели­ чин с фиксированным числом значащих цифр до и после запятой. Параметр р задает общее число десятичных цифр, an — их количество после запятой. Таким образом, DEZIMAL(p, п) позволяет хранить числа, в десятичном представлении которых содержится не более 32 цифр. Объем памяти для хранения одного значения составляет (1 + р/2) байт. Этот тип данных имеет те же достоинства и недостатки, что и DEZIMAL(p).

DATE — тип данных, предназначенный для хранения дат. По сути его значение представляет собой число дней, прошедших с 31 декабря 1899 г. Поскольку это значение может быть отрицательным, можно хранить и даты до 1899 г. Выделяемый под него объем памяти составляет 4 байт, поэтому

205

12. Логическое проектирование систем распределенной обработки данных

диапазон допустимых значений очень широк — около 58 000 столетий впе­ ред и назад. Форматирование ввода и вывода для переменных DATE может быть указано с помощью внешних переменных.

DATETIME (DATE) — тип данных, предназначенный для хранения моментов времени. DATETIME содержит информацию о годе (YEAR), ме­ сяце (MONTH), дне (DAY), часе (HOUR), минуте (MINUTE), секунде (SECOND) и долях секунды (FRACTION). Нужный диапазон значений вы­ бирается индивидуально. Например, если требуется зафиксировать момент времени с точностью до секунды в течение дня, то следует указать тип DATETIME HOUR ТО SECOND. Если же интересует информация о какомлибо событии с точностью до минуты, но в произвольном году, то тип дан­ ных должен быть описан как DATETIME YEAR ТО MINUTE. При указании долей секунды необходимо отмечать точность представления. Так, FRACTION(l) указывает время с точностью до десятых долей, FRACTI0N(2) — до сотых, а FRACTI0N(3) — до тысячных. Тип DATETIME позволяет хранить данные более точно, чем DATE, однако тре­ бует выделения большего объема памяти и обрабатывается медленнее.

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

CHARACTER(n) (CHAR, CHAR(n)) — типы данных, предназначен­ ные для хранения символьных строк фиксированной длины. Параметр п задает длину строки, максимальное значение равно 32 767 (для разных СУБД эта величина может отличаться). Для хранения данных всегда отво­ дится п байт вне зависимости от реальной длины строки.

VARCHAR(m) — тип данных, предназначенный для хранения корот­ кой (до 255) символьной строки переменной длины. Параметр m задает максимальную длину строки, но не более 255 символов. Для значения типа VARCHAR в памяти выделяется столько байт, сколько реально занимает строка.

BYTE (LONG RAW) — тип данных, предназначенный для хранения двоичных объектов произвольного объема. Его можно (и нужно) использо­ вать для хранения исполняемых файлов, оцифрованных картинок, звука и др. Размер типа BYTE может достигать 2 Гбайт.

Во многих СУБД встречаются следующие типы данных (для разных СУБД идентификаторы типов могут отличаться):

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

206

12.1. Разработка логической схемы базы данных

MONEY(p, п) — тип данных, предназначенный для хранения денеж­ ных величин. В отличие от DEZIMAL(p, п) для него в некоторых языках предусмотрены специальные способы форматирования на основе некото­ рых внешних по отношению к программе переменных окружения. Это по­ зволяет писать программы, не зависящие от формы представления денеж­ ных величин в каждой конкретной стране (например, величина 3 000 000 будет печататься либо как $3,000,000.00, либо как 3.000.000,00 руб.);

TEXT (LONG) — тип данных, предназначенный для хранения сим­ вольных строк произвольной переменной длины. По сравнению с VARCHAR для типа TEXT характерны повышенные накладные расходы (повышенный объем памяти для хранения одного значения и менее эффек­ тивный поиск), но при этом практически нет ограничений на длину строки (до 2 Гбайт).

Для каждого из перечисленных типов данных существуют свои опе­ рации, свои значения, но есть у них и одно общее значение — NULL (не определено). Не следует путать его с нулем, так как нуль — это вполне оп­ ределенное значение, а 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],...)

Оптимизация логической схемы базы данных. Задача оптимизации ЛС БД связана, в основном, с перераспределением атрибутов ПО по таблицам

207

12. Логическое проектирование систем распределенной обработки данных

Код поставщика

Адрес поставщика

Товар

Цена за единицу товара

 

01

г. Москва, ул. X, 100

Карамель

1000

 

01

г. Москва, ул. X, 100

Сахар

4000

j

02

г. Москва, ул. Y, 20

Карамель

1050

 

02

г. Москва, ул. Y, 20

Сахар

4500

 

Рис. 12.1. Пример таблицы базы данных

БД. Рассмотрим ключи таблицы. Ключом таблицы БД называется совокуп­ ность атрибутов, которые определяют все другие атрибуты этой таблицы, т.е. не существует двух записей с тем же значением ключа. В примере на рис. 12.1 поле «Код поставщика» не является ключом, так как существуют записи с одним и тем же значением этого поля (например, 01), но с разными значениями поля «Товар» (записи 1, 2). Здесь ключом являются два поля «Код поставщика» и «Товар».

 

Поставщик

 

 

 

Адрес поставщика

Товар

 

 

Цена за единицу

 

 

 

Рис. 12.2. Атрибуты базы данных «Поставщик»

 

Поставщики товара

 

 

[ Код поставщика

т Адрес поставщика

Товар

1

Товар и цена

 

 

 

Товар

I Цена за единицу

 

 

Рис. 12.3. Пример ER-диаграммы

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

Предположим, что для магазина разрабатывается БД «Поставщик», которая должна включать атрибуты, показанные на рис. 12.2.

Пусть проектировщик определил ER-диаграмму, представленную на рис. 12.3.

208

12.1. Разработка логической схемы базы данных

 

Поставщики товаров

 

 

 

Код поставщика

Адрес поставщика

 

Товар

01

г. Москва, ул. X, 100

Карамель

01

г. Москва, ул. X, 100

Сахар

02

г. Москва, ул. Y, 20

Карамель

02

г. Москва, ул. Y, 20

Сахар

Товар и цена

 

 

 

Товар

Цена за единицу

 

 

Карамель

1000

 

 

Сахар

4000

 

 

Карамель

1050

 

 

Сахар

4500

 

 

 

Рис. 12.4. Пример наполнения БД

 

Код поставщика

Адрес поставщика

Товар

Цена за ед.

01

г. Москва, ул. X, 100

Карамель

1000

01

г. Москва, ул. X, 100

Карамель

1050

01

г. Москва, ул. X, 100

Сахар

4000

01

г. Москва, ул. X, 100

Сахар

4500

Рис. 12.5. Результат выполнения запроса SELECT

Предположим также, что в процессе функционирования системы в таблицы этой БД были включены записи (рис. 12.4).

Пусть выполняется следующий запрос:

SELECT (что найти)

Код поставщика, Адрес поставщика, Товар, Цена за

 

единицу

FROM (из таблиц)

Поставщики товаров. Товар и цена

WHERE (при условии)

Поставщики товаров.Товар = Товар и цена.Товар

 

AND Код поставщика = 01;

В результате получим таблицу, представленную на рис. 12.5.

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

1. База данных (вернее схема БД) может состоять только из одной таблицы (рис. 12.6).

209