Московский государственный университет печати

Чертовской В.Д.


         

Базы и банки данных

Учебное пособие


Чертовской В.Д.
Базы и банки данных
Начало
Печатный оригинал
Об электронном издании
Оглавление

Введение

Часть 1. ОСНОВНЫЕ ПОЛОЖЕНИЯ

Раздел 1. Основные понятия

1.

Глава 1. Общие сведения

1.1.

Данные, информация, знания

1.2.

Основные понятия и определения

1.3.

Классификация БД и СУБД

1.4.

Состав СУБД и работа БД

2.

Глава 2. Концепция баз данных

2.1.

Требования, предъявляемые к базам данных

2.2.

Концепция построения БД

2.3.

Методология проектирования баз данных

2.4.

Методология использования баз данных

Раздел 2. Теория баз данных

3.

Глава 3. Общая теория

3.1.

Модели представления данных

3.2.

CASE-технология

3.3.

CASE-средства

4.

Глава 4. Теория реляционных баз данных

4.1.

Математические основы теории

4.2.

Построение БД

4.3.

Использование БД

4.3.1.

Запросы к данным

4.3.2.

Синхронизация процессов доступа

Часть 2. Централизованные базы данных

Раздел 3. Реализация бд (модели БД)

5.

Глава 5. Реляционные БД SQL

5.1.

Логическая структура

5.2.

Создание БД

5.3.

Использование БД

5.3.1.

Язык SQL

5.3.2.

Язык QBE

6.

Глава 6. Сетевые БД

6.1.

Логическая структура

6.2.

Программная реализация

6.2.1.

Создание БД (ЯОД)

6.2.2.

Использование БД (ЯМД)

7.

Глава 7. Иерархические БД

7.1.

Логическая структура

7.2.

Программная реализация

7.2.1.

Создание БД (ЯОД)

7.2.2.

Использование БД (ЯМД)

8.

Глава 8. Взаимосвязь МД

8.1.

Сравнительная характеристика моделей данных

8.2.

Преобразование моделей данных

8.3.

Выбор моделей данных

9.

Глава 9. Физическая БД

9.1.

Вопросы программной реализации БД

9.2.

Организация хранения и доступ

9.3.

Доступ к данным и их обновление

Раздел 4. Современные направления развития БД

10.

Глава 10. Автоматизация проектирования

10.1.

Классический подход к проектированию

10.1.1.

Однопользовательский режим

10.1.2.

Многопользовательский режим

10.2.

Современный подход к проектированию

10.3.

Автоматизация проектирования

11.

Глава 11. Объектно-ориентированные базы данных

11.1.

Недостатки реляционных баз данных

11.2.

Состояние развития ООБД

11.3.

Сущность ООБД

11.4.

Недостатки и перспективы развития ООБД

Часть 3. Распределенные базы данных (РБД)

Раздел 5. Основы теории РБД

12.

Глава 12. Общая характеристика РБД

12.1.

Новые требования, предъявляемые к БД

12.2.

Состав и работа РБД

12.3.

Система клиент/сервер

Раздел 6. Основы теории РБД

13.

Глава 13. Создание РБД

13.1.

Обеспечение целостности

13.2.

Фрагментация и локализация

13.3.

Процесс интеграции

13.4.

Преобразование структуры и данных

13.5.

Однородные и неоднородные РБД

14.

Глава 14. Использование РБД

14.1.

Одновременный доступ

14.2.

Защита

14.3.

Восстановление РБД

14.4.

Запросы

Заключение

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

Литература

Указатели
11  именной указатель
360  предметный указатель
163  указатель иллюстраций
25  указатель компаний

Раздел 4. Современные направления развития БД

10.
Глава 10. Автоматизация проектирования

Последовательность этапов проектирования показана на рис. 10.1.Рис. 10.01. Схема этапов проектирования централизованных БД Из него видно, что имеет место два подхода к проектированию База данныхБД:

    1) классический, сформировавшийся в 80-е годы и применяемый до сих пор;

    2) современный, формирование которого началось в 90-е годы и продолжается до настоящего времени.

10.1.
Классический подход к проектированию

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

При проектировании с использованием классического подхода исходили из таких положений.

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

  2. Запрос к БД мог осуществляться регулярно (по регламенту) или по запросу. Запрос предполагал получение любой структуры документов из имеющихся в БД полей данных.

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

В проектировании БД, в соответствии с классической методологией ANSI/SPARC, выделялись следующие этапы (рис. 2.5):Рис. 02.05. Схема этапов проектирования БД анализ требований; концептуальное моделирование; логическое моделирование; физическое моделирование; реализация.

При этом, как показала практика, акцент следует делать на начальные этапы, на которых имеет место наибольшее число трудно исправимых ошибок (табл. 10.1).

Таблица 10.1.

Удельный вес ошибок при разработке БД

Этап Процент
выявленных
ошибок
Стоимость справления ошибок
(по пятибалльной шкале)
Анализ физической реализации и первоначальные разработки 40 5
Детальное проектирование 50 3
Программирование 10 1, 2
Тестирование 1

Обсудим специфику этапов, за исключением выбора МД и конкретной Система управления базы данныхСУБД, рассмотренного в главе 8.

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

Потребности анализируются путем:

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

    2) серии интервью с ЛПР.

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

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

10.1.1.
Однопользовательский режим

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

В классическом подходе в ряде случаев, как отмечалось в главе 2, вместо Модель концептуальнаяконцептуальной и Модель логическаялогической моделей рассматривают инфологическую и даталогическую.

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

Модель даталогическаяДаталогическая модель - модель логического уровня, представляющая собой отображение логических связей безотносительно к их содержанию и среде хранения.

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

Прежде чем описывать технологию ИЛМ, представим структуру этой модели.

ИЛМ должна удовлетворять ряду требований.

  1. Независимость описания ИЛМ от способа ее последующей реализации.

  2. Простота языка описания.

  3. Возможность дальнейшей формализации ИЛМ для конкретных средств реализации.

Не существует предпочтительных методов построения ИЛМ. Рассмотрим один из них - на уровне документов. Документ представляет собой материальный объект, содержащий в зафиксированном виде информацию, оформленную в установленном порядке и имеющую правовое значение.

Количественные и качественные характеристики объектов изменяются за счет реально протекающих процессов производственно-хозяйственной деятельности.

Элементом описания документа является Реквизитреквизит - логически неделимый элемент, соотносимый с определенным свойством объекта.

В состав реквизита включаются:

    1) наименование (тип, класс, значение);

    2) ограничение на представление значения (единица измерения, формат, точность);

    3) специальные свойства (ключ защиты значений, контроль достоверности).

Реквизиты в соответствии с типом и классом значений делятся на Реквизит числовойчисловые, Реквизит текстовыйтекстовые, Реквизит логическийлогические, Реквизит специального назначенияспециального назначения.

Пример 10.1. Пусть предметной областью является производственное подразделение. На основе анализа требований выявлен состав предметной области в виде, показанном в табл. 10.2,

Таблица 10.2.

Состав информационной области (ИнО)

Наименование ИнО

Семантика ИнО

Обозначение ИнО

Минимальный
реквизитный состав

Предметы Готовые изделия, детали, сборочные единицы, комплектующие изделия
PRE 1. Код предмета
2. Наименование
3. Тип
4. Код единицы измерения
5. Дата реализации
Поставщики Предприятия, поставляющие материалы, комплектующие
POS 1. Код поставщика
2. Наименование
Потребители Предприятия, потребляющие готовые изделия
POT
1. Код потребителя
2. Наименование
Группа оборудования
Совокупность единиц оборудования определенного вида
GOB 1. Код группы оборудования
2. Наименование
3. Количество
Трудовые ресурсы
Профессии, необходимые для производства предметов
TRE 1. Код работающих
2. Наименование профессии
3. Количество
Структурные подразделения
Цехи, участки, отделы
STR
1. Код группы оборудования
2. Наименование подразделения
Табельный №
Работающий на предприятии
ТАВ 1. Табельный №
2. Фамилия, и, о
Единица оборудования
Станки, оснастка, инструменты
ЕОВ 1. Инв. №
2. Действующий фонд времени
Поставка Процесс плановой и фактической поставки предметов PSK 1. Код поставки
2. Код предмета
3. Количество плановое
4. Дата поставки
5. Количество фактическое
6. Дата фактическая
Заказ Процесс загрузки и реализации готовой продукции ZAK 1. Код потребителя
2. Код предмета
3. Количество отгруженное
4. Дата отгрузки
Структура предмета Многоуровневый состав, входимость SSN 1. Код предмета принимающего
2. Код предмета входящего
3. Количество (норма)
Технология Совокупность технологических операций по изготовлению предмета THN 1. Код предмета
2. Код подразделения
3. Код группы оборудования
4. Номер операции
5. Код профессии
6. По операционно-трудовые нормативы
Организационная структура Непосредственная подчиненность OST 1. Код подразделения старшего
2. Код подразделения младшего
3. Номер приказа
Единица измерения ... ... EIZ 1. Код единицы измерения
2. Наименование
в графе «Реквизитный состав»которой подчеркнуты реквизиты ключи. Типы связей приведены в табл. 10.3.

Таблица 10.3.

Типы связи в информационной области

Дальнейшей задачей проектирования является устранение избыточности связей и отношений М:М (поскольку современные СУБД такие отношения не реализуют). Иными словами, необходимо построить каноническую форму ИЛМ (рис. 10.2).Рис. 10.02. Каноническая форма ИЛМ

ИЛМ считается представленной в канонической форме, если информационная область правильно структурирована:

    1) сложные связи преобразованы в совокупность простых;

    2) развязаны отношения М:М, участвующие в простых связях;

    3) информационная область упорядочена по уровням иерархии.

Последнее требование обязательно при проектировании АСУ, а не БД.

Связь М:М, как это следует из главы 4, трансформируется в две связи 1:М (или М:1), при этом, если естественной связки нет, вводят искусственную.

Для всех связей М:М данного примера имеются естественные связки. Преобразование идет по такой схеме:

Ее можно записать иначе:

PRE <<–>> POT:PRE <–>> ZAK, ZAK <<–> POT.

Аналогичны записи и для других связей:

PRE <<–>> GOB:PRE <–>> THN, THN <<–> GOB,

POS <<–>> PRE:POS <–>> PSW, PSW <<–> PRE,

PRE <<–>> TRE:PRE <–>> THN, THN <<–> TRE,

PRE <<–>> STR:PRE <–>> THN, THN <<–> STR,

GOB <<–>> TRE:GOB <–>> THN, THN <<–> TRE,

TRE <<–>> STR:TRE <–>> TAB, TAB <<–> STR,

GOB <<–>> STR:GOB <–>> THN, THN <<–> STR.

Результат преобразования представлен на рис. 10.2.Рис. 10.02. Каноническая форма ИЛМ

Процедуру трансформации связей М:М можно легко формально описать и автоматизировать.

Дальнейшая детализация связана с логическими операциями на уровне полей (реквизитов), которые используются и в многопользовательском режиме.

10.1.2.
Многопользовательский режим

В Режим многопользовательскиймногопользовательском режиме - в отличие от Режим однопользовательскийоднопользовательского - возникают две дополнительные проблемы:

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

    2) обеспечение синхронизации процессов обновления в процессе эксплуатации.

Решение второй проблемы определяется возможностями выбранной СУБД, поэтому остановимся подробнее на решении первой проблемы.

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

Сформулируем основные правила объединения.

  1. Устранение синонимов и омонимов.

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

  2. Устранение пересекающихся атрибутов.

Атрибут пересекающийсяПересекающийся атрибут - атрибут, связанный с несколькими ключами:

Их устранение возможно одним из следующих способов.

  1. Замена эквивалентными связями с существующими ключами:

  2. Дублирование атрибута:

  3. Превращение атрибута в ключ:

Покажем построение концептуальной модели (схемы) на примере.

Пример 10.2. В многопользовательском режиме работают пользователи А и Б (рис. 10.3, а)Рис. 10.03. Многопользовательский режим (а), схемы пользователей (б и в) с объектами (документами), отображенными на рис. 10.3, б, вРис. 10.03. Многопользовательский режим (а), схемы пользователей (б и в) соответственно. Обычно в процессе построения концептуальной модели поля могут изменять название, удаляться, добавляться новые поля.

Построим овал-диаграммы (рис. 10.4).

Тогда подсхема пользователя А получает вид, показанный на рис. 10.4, а.Рис. 10.04. а) Подсхема концептуальной модели Отметим, что поле «Заказанное количество» зависит от полей «№ изделия» и «№ заказа».

Аналогично для пользователя Б получается подсхема, указанная на рис. 10.4, б:Рис. 10.04. б) Подсхема концептуальной модели здесь вводятся понятие «Наличное количество» и связи «№ заказа - имя поставщика» и «№ заказа - № изделия».

Тогда результирующая схема будет иметь вид (без учета устраняемых пунктирных связей), представленный на рис. 10.4, в.Рис. 10.04. в) Каноническая схема концептуальной модели Из него видно, что связь «№ заказа - имя поставщика» избыточна как транзитивная. Связь «№ заказа - № изделия»типа М:М устраняется сцепленным ключом «№ заказа + № изделия» и потому также избыточна.

Полученную каноническую схему полезно представить в более удобной форме (рис. 10.5),Рис. 10.05. Схема БД в которой могут быть введены связи, отсутствующие в канонической схеме, но необходимые в будущем.

Приведем процесс по построения реальной БД.

Пример 10.3. Построить БД для библиотеки СПИ МГУП.

А. ПОСТРОЕНИЕ БД.

Анализ требований выполнен на стадии составления приводимого задания, уточнение которого не исключено.

ЗАДАНИЕ

по проектированию базы данных:

курсовая работа «Система работы библиотеки СПИ МГУП»

дисциплины «Базы и банки данных».

Исходные данные.

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

НЕОБХОДИМО РАЗРАБОТАТЬ БАЗУ ДАННЫХ БИБЛИОТЕКИ.

С помощью базы данных необходимо вести учет книг (читатель, АБ) и читателей (АБ).

Учет книг ведется раздельно по учебной литературе - книгам (Автор, Инициалы, Название, Год издания, шифр, Раздел систематического каталога, Количество, Цена единицы; Инвентарный № или № акта поступления (книги регистрации), № акта списания, Принадлежность [МГУП, СПИ]) к методическим изданиям (Автор, Инициалы, Название, Год издания, Количество, Вид пособия [программа, методические указания, курсовая работа, лабораторная работа, практические занятия]; Дата поступления, № акта списания).

Данные после символа (;) нужны АБ и не должны быть доступны читателю.

АБ необходимо также вести учет читателей (преподавателей, сотрудников, студентов) и выдаваемых им книг (Автор, Название, Год издания, Дата выдачи, Срок сдачи).

Читатели делятся на три группы:

  • преподаватели (Фамилия, и.о., Кафедра, Предмет, Телефон, Приказ об увольнении);

  • сотрудники (Фамилия, и.о., Кафедра, Телефон, Приказ об увольнении);

  • студенты (Фамилия, и.о. [в том числе данные об изменении фамилии], Факультет, Курс, Группа, Выпускающая кафедра, Приказ [N, дата] об отчислении).

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

  1. Выдавать упорядоченный список книг данного автора, издательства, года, инвентарного номера (акта).

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

  3. Проводить поиск по шифру систематического каталога.

  4. Выдавать список читателей с их данными и характеристиками взятых книг.

  5. Осуществлять статистическую обработку характеристик читательского контингента.

Предусмотреть защиту целостности - в том числе ссылочную - при заполнении таблиц.

Реализовать фрагмент базы данных на выбранной Система управления базы данныхСУБД, при этом в каждой таблице должно быть не менее 10 записей.

Записать систему команд выполнения перечисленных запросов на языках СУБД и SQL. Предусмотреть защиту данных администрации библиотеки с помощью паролей и разрешений (виды, GRANT на языке SQL).

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

В связи с этим далее целесообразно рассматривать БД как однопользовательскую (для АБ). Данные для пользователя-читателя возможно обеспечить парольной защитой соответствующих полей либо формированием видов (например, на языке СУБД FoxPro или на языке SQL). Схема-перечень полей показана на рис. 10.6.Рис. 10.06. Перечень полей БД 'Библиотека СПИМГУП'

В общем случае все данные возможно разделить на две группы: читатель и книги.

Их отношение:

В данном случае имеется несколько разновидностей читателей и книг. Проанализируем их.

Читатели:

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

Для студентов следует ввести ключ-код и таблица будет иметь вид:

Аналогично создаются таблицы Cтудент + учебные и Cтудент + методические.

Логическая модель. Таблица Студент 1 не находится в ЗНФ:

Преобразуем ее в две таблицы:

Остальные таблицы (файлы) находятся в 3НФ.

На этой же стадии следует обеспечить целостность. Это достигается объявлением соответствующих типов переменных и введением ограничений. Например, поле «факультет» таблицы Студент может иметь только два результата: ПТО и ИДЭиКТ. Если будут введены другие данные, то они не должны быть записаны. Аналогичная ситуация для поля «должность» таблицы Специалист, поля «принадлежность» таблицы Учебные. Должна быть обеспечена ссылочная целостность таблиц Студент и Фамилия + студент: если пытаются уничтожить запись «фамилия» таблицы Студент, то такое уничтожение не должно быть осуществлено, при этом желательна выдача компьютером сообщения об этом факте.

A. Проектирование интерфейса. Исходя из сформулированных ранее требований, предлагается следующий вариант интерфейса.

Для выходных требований 1, 5 задания составить форму отчета. Для остальных пунктов задания - табличную форму, которая может использоваться и для произвольного запроса. Запрос может осуществляться с помощью экранных форм, QBE, SQL. Для обновления данных предусматриваются как экранные формы, так и таблицы. Поскольку предполагается, что пользователь не является профессиональным программистом, следует использовать систему меню. Предлагается вариант, показанный на рис. 10.7.Рис. 10.07. Примеры интерфейса пользователя: а) - меню; б) - отчет Отметим, что независимо от СУБД в работе с БД выделяются процедуры создания и эксплуатации (рис. 10.8).Рис. 10.08. Реализация БД

10.2.
Современный подход к проектированию

Современный подход исходит не от системы документов, как в классическом подходе, а от задач (в терминах АСУ ссылка на источники литературы]), т.е. от приложений, под которые создается БД. Под Приложениеприложением понимается программа или группа программ, предназначенных для выполнения определенных однотипных работ. Изменение парадигмы построения БД связано с тем, что построение База данных универсальнаяуниверсальной БД, как отмечалось в главе 2, себя не оправдало, в то время как «стандартные»алгоритмы широко применяются в Windows-приложениях (текстовые, графические редакторы, БД, электронные таблицы). Расширение сферы применения объектно-ориентированного подхода позволило приспосабливать стандартные приложения к конкретным требованиям, добавляя необходимые стандартные программные модули. Более того, объектно-ориентированное построение стали применять не только к программным приложениям, но и к интерфейсу пользователя (FoxPro 3.0 и более старших версий), и даже к самим БД (Delphi, PowerBuilder). Таким образом, анализ требований имеет другую целенаправленность - построение приложения и данных для него (в виде БД). Остановимся на специфической процедуре выявления алгоритма (построения приложения), в которой можно выделить следующие этапы ссылка на источники литературы.

  1. Определение цели.

  2. Выявление логики приложения (интерфейс пользователя и внутренний код).

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

Пример 10.4. Цель рассмотрения - процесс банковской деятельности. Сам процесс можно представить в виде такой словесной модели. Для обслуживания банком клиенту необходимо предъявить свою кредитную карту, с которой автоматически считывается информация (Пароль, Лимит_денег, Детали_клиента), а карта возвращается клиенту. Далее компьютер предложит клиенту сообщить свой пароль. Если данные пароля, введенные клиентом (после возможного троекратного повторения), не совпадают с данными компьютера, то ПЭВМ отказывается от дальнейшего обслуживания клиента, посылая ему соответствующее уведомление Если пароль введен верно, начинается обслуживание клиента: ему выдается сообщение с просьбой ввести запрос на обслуживание (требуемая сумма денег). После этого ему выдаются наличные деньги, выписка о выполненной банком операции, о выданных деньгах, о его денежном балансе. Аналогичная информация (Данные_по_счету, Протокол_обслуживания, Информация_об_обработанной_документации, Изымаемая денежная_сумма, Данные_об_истории_запросов) после завершения процесса (приложения) остается в компьютере. Словесная модель позволяет построить контекстную диаграмму, показанную на рис. 10.9,Рис. 10.09. Контекстная диаграмма банковской задачи которая может быть предъявлена персоналу банка для уточнения общей схемы и уточнения некоторых деталей. Пусть после уточнения контекстная диаграмма получила детализированный вид, представленный на рис. 10.10,Рис. 10.10. Детализация контекстной диаграммы а диаграмма для процесса 1.3 - на рис. 10.11.Рис. 10.11. Детализация процесса 1.3. Дадим более подробное информационное описание ссылка на источники литературы подпроцессов 1.1 - 1.4.

Процесс 1.1 [ПОЛУЧИТЬ ПАРОЛЬ] - прием и проверка пароля клиента. Вход: ВВЕДЕННЫЙ ПАРОЛЬ из потока КЛЮЧЕВЫЕ ДАННЫЕ; ПАРОЛЬ - из хранилища ДАННЫЕ КРЕДИТНОЙ КАРТЫ, показанного на рис. 10.10.Рис. 10.10. Детализация контекстной диаграммы дважды для удобства изображения диаграммы. Выход: поток - СООБЩЕНИЕ о готовности компьютера принять пароль.

Процесс 1.2 [ПОЛУЧИТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ] - прием и проверка запроса клиента на необходимое обслуживание. Вход: поток ЗАПРОС НА ОБСЛУЖИВАНИЕ (элемент потока КЛЮЧЕВЫЕ ДАННЫЕ); поток ЛИМИТ ДЕНЕГ - из хранилища ДАННЫЕ КРЕДИТНОЙ КАРТЫ. Выход: поток СООБЩЕНИЕ о готовности компьютера принять запрос на обслуживание.

Процесс 1.3 [ОБРАБОТАТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ]. Вход: поток ДАННЫЕ ПО СЧЕТУ - из компьютера банка; ДЕТАЛИ КЛИЕНТА - из хранилища. Выход: потоки ВЫПИСКА, ДЕНЬГИ, ПРОТОКОЛ ОБСЛУЖИВАНИЯ. Процесс 1.3 раскладывается на более простые подпроцессы (рис. 10.11)Рис. 10.11. Детализация процесса 1.3.

Процесс 1.3.1 [ОБРАБОТАТЬ ДОКУМЕНТАЦИЮ БАНКА] - осуществляет обработку внутренней банковской документации. Вход: поток ДЕТАЛИ КЛИЕНТА. Выход: ОБРАБОТАННАЯ ДОКУМЕНТАЦИЯ.

Процесс 1.3.2 [РАСПЕЧАТАТЬ БАЛАНС КЛИЕНТА] - выдает справку по истории и балансу счета клиента. Вход: потоки ДЕТАЛИ КЛИЕНТА и ДАННЫЕ ПО БАЛАНСУ. Выход: потоки ВЫПИСКА ПО БАЛАНСУ и ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА.

Процесс 1.3.3 [ПРИГОТОВИТЬ ДЕНЬГИ КЛИЕНТУ] - обеспечивает выдачу наличных денег и информирование компьютера банка об изъятых из банка деньгах. Вход: потоки ДЕНЕЖНАЯ СУММА и ДЕТАЛИ КЛИЕНТА. Выход: потоки ДЕНЬГИ и ДЕНЕЖНАЯ СУММА.

Процесс 1.3.4 [РАСПЕЧАТАТЬ ОПЕРАЦИЮ КЛИЕНТА] - выдает справку по истории счета и уведомление о проведенной операции. Вход: потоки ДАННЫЕ ПО СЧЕТУ и ДЕТАЛИ КЛИЕНТА. Выход: потоки ВЫПИСКА ИЗ ОПЕРАЦИИ и ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА.

Процесс 1.4 [ОБРАБОТАТЬ КРЕДИТНУЮ КАРТУ] - производит считывание информации с кредитной карты. Вход: поток КРЕДИТНАЯ КАРТА. Выход: поток ДАННЫЕ КРЕДИТНОЙ КАРТЫ.

Такое подробное описание приложения позволяет сразу сформировать:

    1) алгоритм приложения;

    2) входные (экранные) формы БД - по входным характеристикам процессов (подпроцессов) приложения;

    3) выходные отчеты и формы - по выходным данным процессов.

Вариант алгоритма для данного приложения представлен на рис. 10.12,Рис. 10.12. Алгоритм управления для банковской задачи: А - пароль верен а интерфейс пользователя - на рис. 10.13.Рис. 10.13. Интерфейс пользователя банковского процесса (задачи) Одновременно входные данные являются основой для построения БД. Общая схема совокупности полей и единственного файла БД примера 10.4 показана в табл. 10.4.

Таблица 10.4.

Файл БД банковской задачи

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

10.3.
Автоматизация проектирования

Анализ требований выполняется в обычном ручном режиме, а автоматизация начинается с создания концептуальной модели. Описанную в предыдущем параграфе процедуру построения диаграмм потоков данных (DFD) Гейна-Сарсона возможно реализовать непосредственно на экране в СУБД Oracle ссылка на источники литературы. Для этого используются такие описанные в главе 3 средства, как CASE*Dictionary, CASE*Designer, CASE*Generator. Основная тяжесть проектирования лежит на CASE*Designer: он позволяет к тому же автоматически строить 3НФ и даже 4НФ, что дает возможность оперативно сконструировать алгоритм приложения, интерфейс пользователя, поля БД. В CASE*Designer имеются алгоритмы автоматического преобразования DF-диаграмм в структурные карты (для отображения схем программ). Карта Джексона для банковского процесса показана на рис. 10.14. По результатам работы CASE*Designer средство CASE*Generator генерирует программный код. К достоинствам этого высокоавтоматизированного метода следует отнести:

    1) многовариантное проектирование;

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

    3) автоматизация и резкое повышение скорости процесса проектирования: разработчикам к тому же остается больше времени на творческие процедуры, а рутинные выполняет компьютер.

Автоматизация такой трудоемкой процедуры, как кодогенерирование, прошла следующие этапы развития.

  1. Компиляторы, редакторы, отладчики, упрощающие отладку программ.

  2. Интегрированная среда разработчика IDEIntegrated Designer Environment (IDE), характерная для языков программирования третьего поколения. Generation Language - 3GL) типа Pascal. Такая среда существенно упрощает программную реализацию БД.

  3. Среда Workshop, разработанная фирмой BorlandBorland, послужившая как бы трамплином для следующих, более эффективных средств отладки.

  4. Визуальные языки четвертого поколения (4GL) Visual Basic, Visual C, Pascal 7.0, получивший за рубежом название OBJECT PASCAL.

  5. Система быстрого создания приложения (Rapid Application Design - RAD) в виде приложений PowerBuilder, Delphi, получивших широкое распространение ссылка на источники литературы.

В связи с этим дадим основные характеристики ссылка на источники литературы Delphi (разработка фирмы Borland).

  1. Компилятор Delphi обрабатывает 800 000 строк кода в минуту, что составляет 80 процентов возможностей самых быстродействующих С-программ.

  2. Применяется объектно-ориентированный подход с языком Object Pascal , использованием компонентов языка Visual Basic.

  3. Используется среда RAD.

  4. Ядро управления Delphi - утилита DBC, доступ к любым «внешним»данным осуществляется через программный продукт ODBC или интерфейс IDAPI (в том числе и к удаленным системам клиент/сервер). С помощью Delpi, равно как и других подобных программных продуктов, создание интерфейса пользователя БД осуществляется в автоматическом режиме без написания программистом хотя бы одного символа кода. В полуавтоматическом режиме создаются приложение и БД. Для Delphi характерны открытость и расширяемость. Примерно такими же характеристиками обладает другой программный продукт - PowerBuilder ссылка на источники литературы.

Следующим шагом в развитии автоматизации кодогенерации считаются язык JAVA и технология мини-приложений Artifical Intelligence (AI). К последней следует отнести, например, систему отладки на языке Prolog 4.0 и более высоких версий.

© Центр дистанционного образования МГУП