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

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

Автор: Якимчук, Павел Сергеевич

Шифр специальности: 05.13.06

Научная степень: Кандидатская

Год защиты: 1983

Место защиты: Харьков

Количество страниц: 228 c. ил

Артикул: 4032028

Автор: Якимчук, Павел Сергеевич

Стоимость: 250 руб.

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

СОДЕРЖАНИЕ
Введение.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. В пределах этих требований по согласованию администратор базы данных может свободно изменять вцутренюго схещу с целью оптимизации работы СУЩ, не прерывая её нормальной эксплуатации. К сожалению эти возможности в реальных СУЩ сильно ограничены именно вследствие отсутствия чётко выраженной логической схемы и её процессора. Учитывая, что размеры баз данных в современных АСУ очэнь велики, требование удобной и быстрой реорганизации баз данных в настоящее время является одним из основных. Педрос/в. Улогической схемы в явном виде, поскольку она в значительной мере решает эту проблему. Роль третьего администратора (прикладника) состоит в том, чтобы обеспечивать многочисленные внешние схемы, которые определяются запросами от пёьзователей. Кавдая внешняя схема охватывает только часть базы данных, относящуюся к определенной прикладной области. Опыт показал, что для каждой достаточно крупной подсистемы АСУП необходим свой администратор, который обеспечивает соответств-вующие схемы для этой подсистемы.

Рекомендуемые диссертации данного раздела

28.06.2016

+ 100 бесплатных диссертаций

Дорогие друзья, в раздел "Бесплатные диссертации" добавлено 100 новых диссертаций. Желаем новых научных ...

15.02.2015

Добавлено 41611 диссертаций РГБ

В каталог сайта http://new-disser.ru добавлено новые диссертации РГБ 2013-2014 года. Желаем новых научных ...


Все новости

Время генерации: 0.225, запросов: 244