Методы и алгоритмы проектирования реляционной базы данных и реализация операций реляционной алгебры в условиях АСУП

• Автор: Якимчук, Павел Сергеевич
• Шифр специальности: 05.13.06
• Научная степень: Кандидатская
• Год защиты: 1983
• Место защиты: Харьков
• Количество страниц: 228 c. : ил

СОДЕРЖАНИЕ
Введение.4.

1. Анализ систем и постановка задачи

1.1. Трехуровневая концепция и обощенная схема СУЩ

1.2. Модели данных.

1.3. Проблема автоматизации проектирования схемы базы данных.

1.4. Проблема эффективной реализации реляционных запросов

1.5. Выводы
2. Методы и алгоритмы проектирования лгической и физической схемы реляционной базы данных с помощью ЭВМ

2.1. Выбор физической организации базы данных рассматриваемого класса задач

2.2. структура и е свойства

2.3. Алгоритм.
2.4. Пример работы алгоритма
2.5. Выводы.
3. Методы реализации операций реляционной алгебры Кодца в однородных вычислительных системах.
3.1. Некоторые предпосылки.
3.2. Операции реляционной алгебры и некоторые замечания о методах их реализации
3.3. Общее описание летода.
3.4. Декомпозиция задачи на этапы.
3.5. Метод выполнения реляционных операций в однопроцессорной системе. .
3.6. Оценка эффективности предложенного метода.
3.7. Методы выполнения реляционных запросов в многопроцессорных системах.
3.8. Выводы,
4. Реализация
4.1. Общее описание системы.
4.2. Основные потоки данных в системе.Трехконтурный принцип.
4.3. Конструирование базы данных
4.4. Язык манипулирования данными.
4.5. Реализация методов манипулирования данными
в СУРЭЗ.6
4.6. Форматный вывод.
Заключение и рекомеццации.
Литература


Шестиугольниками на схеме обозначены функции, выполняемые человеком; прямоугольники обозначают функции обработки данных; стрелки указывают потоки данных, описаний или контрольной информации и, наконец, заштрихованные полоски обозначают интерфейсы, содержание которых обсуждается ниже. Интерфейсы пронумерованы цифрами в кружочках. Цунктиром показаны те блоки, которые обычно не относят к СУЩ, штрихцунктиром - те блоки, которые иногда относят к СУЩ, а иногда нет. Эти функции представляют собой внешнее использование данных и взаимодействуют с системой через интнрфейс . Здесь выделено два уровня пользователей: проблемный программист и пользоза-тель-непрограммист. Проблемный программист пишет программы на обычном языке программирования (интерфейс ). Это может быть, например, КОБОЛ или пц. Терши "пользователь-непрограммист" используется для обозначения того, что такой пользователь не обязан писать программу в обычном понимании этого слова. Он взаимодействует с системой через интерфейс , который может быть специальным языком запросов или приказов, обычно близким к естественному языку. Подсисте? Систем-| і Запро-: І Соста- і Спра- і . Р?а. ГУРП ! Ция ! J Ір. Рис. Обобщенная схема системы обработки данник. Обычно этим цутем осуществляется техническое обслуживание или изменение системы. Следует подчеркнуть, чгсгвсего лишь функции и их не цужно отождествлять с индивидуумами. Один и тот же человек может выполнять несколько функций и наоборот, несколько человек могут выполнять одну и туже функцию. Нельзя утверждать, что существует только один администратор предприятия и один администратор прикладник. Может существовать несколько внешних схем и несколько прикладных подсистем, использующих одну и ту же внешнюю схему. Каждый администратор несет ответственность за детальное и точное обеспечение системы необходимыми данными, правильное использование этих данных. Администратор предприятия с его решающим мнением обеспечивает структуру логической схемы (интерфейс I). Это следует подчеркнуть, по-видимому, многократно, так как этот момент наиболее часто пропускается теми, кто занимается разработкой и внедрением СУЩ. Логическая схема должна быть определена, введена в ЭВМ, а затем проверена на корректность и напечатана машиной в удобочитаемой форме на вполне определенном стандартном языке (интерфейс 2). Это осуществляется процессором логической схемы. Администратор предприятия определяет логическую схему и утверждает её. Логическая схема содержит определения данных и их характеристики. Эти данные не могут быть представлены на физическом уровне в базе данных до тех пор, пока они не будут определены в логической схеме. Здесь же определяются круг пользователей, которые могут иметь доступ к конкретным частям базы данных, то есть обеспечивается секретность и защита от случайного разрушения. Администратор базы данных отвечает за определение внутренней (физической) схемы (интерфейс 3). Эта схема содержит описание используемой стратегии запоминания. Хранятся ли данные в виде списка, иерархического дерева или инвертированных файлов - все это определяется физической схемой. Физическая схема должна быть согласована с логической схемой. Проверку такого согласования осуществляет процессор физической схемы через интерфейс 6. В пределах этих требований по согласованию администратор базы данных может свободно изменять вцутренюго схещу с целью оптимизации работы СУЩ, не прерывая её нормальной эксплуатации. К сожалению эти возможности в реальных СУЩ сильно ограничены именно вследствие отсутствия чётко выраженной логической схемы и её процессора. Учитывая, что размеры баз данных в современных АСУ очэнь велики, требование удобной и быстрой реорганизации баз данных в настоящее время является одним из основных. Педрос/в. Улогической схемы в явном виде, поскольку она в значительной мере решает эту проблему. Роль третьего администратора (прикладника) состоит в том, чтобы обеспечивать многочисленные внешние схемы, которые определяются запросами от пёьзователей. Кавдая внешняя схема охватывает только часть базы данных, относящуюся к определенной прикладной области. Опыт показал, что для каждой достаточно крупной подсистемы АСУП необходим свой администратор, который обеспечивает соответств-вующие схемы для этой подсистемы.