Поиск - требуемая запись
Cтраница 1
Поиск требуемой записи осуществляется путем проверки равенства искомого ключа очередному. [2]
Поиск требуемой записи и установка указателя текущей записи производится так же, как и в случае подкоманды FIND, с тем отличием, что в случае подкоманды LOCATE при поиске просматривается вся запись ( с учетом установленной зоны просмотра), а не только ее начало. [3]
НАЙТИ - с помощью этой операции осуществляется поиск требуемой записи и считывание ее в поле ввода - вывода ПП. Условие выборки требуемой записи задается отдельным выражением, выступающим в качестве параметра операции. Возможны следующие варианты выражений: первую, последнюю, следующую, предыдущую запись; по ссылке; по значению ключа в каталоге; через первую, последнюю, следующую, предыдущую запись каталога к соответствующей записи множества; по значению ключа ( или выражению для ключа) каталога к соответствующей записи множества. [4]
I Iponecc продвижения по логически связанным данным в иерархической п сетевой бичах данных с целью поиска требуемой записи. Маршрут задается пользователем либо определяется алгоритмами, встроенными в СУБД. [5]
Предусматриваются функции для позиционирования указателя текущей записи таблицы по различным критериям. Операции поиска требуемых записей могут производиться с использованием индексов. Обеспечивается их автоматическая оптимизация. [6]
Перед выполнением оператора ЧИТАТЬ для файла с произвольным доступом данное ФАКТИЧЕСКИЙ КЛЮЧ ( при прямой организации файла) или НОМИНАЛЬНЫЙ КЛЮЧ ( при индексной или относительной организации файла) должно быть установлено на нужное значение. При прямой организации файла поиск требуемой записи производится только на дорожке, задаваемой значением данного ФАКТИЧЕСКИЙ КЛЮЧ. [7]
После этого достается следующая катушка ( том), на которой располагается файл. Варианты CLOSE UNIT и CLOSE REEL используются для ускорения поиска требуемой записи в файле, располагаемом на нескольких катушках или томах, когда становится очевидным, что этой записи нет на текущей катушке или томе. [8]
Этот вариант применим только для входных и входных-выходных файлов на магнитных дисках. Если эта фраза не указана, при выполнении оператора ЧИТАТЬ поиск требуемой записи производится только на указанной дорожке. Если запись на дорожке не найдена, выполняется повелительный оператор, указанный во фразе ПРИ ОШИБКЕ КЛЮЧА оператора ЧИТАТЬ или ОБНОВИТЬ. [9]
Такое ограничение не безобидно, так как при этом исключается возможность автоматической поддержки связей между компонентами хранимой базы данных и ограничений целостности, а также автоматический выбор оптимального пути доступа к требуемым данным. Система не может самостоятельно установить, целесообразно ли использовать механизмы индексирования при выполнении заданной операции поиска требуемой записи в файле базы данных и существует ли вообще какой-либо индекс для данного файла. Хотя связанные с этим заботы пользователя не слишком обременительны в простых приложениях, сложные случаи доставляют много хлопот. [10]
Операнд RECORD предназначен для извлечения вычисляемой записи по ключу хеширования, первичной записи - по значению поля-адреса и вторичной записи - по цепи поиска. Последняя возможность требует комментария. При описании вторичной записи одна из цепей, где эта запись является детальной, объявлена цепью поиска. Если эта цепь сортированная, то для извлечения детальной записи оператором RETRY RECORD достаточно инициировать соответствующую цепь и задать значение ключа сортировки искомой записи. Такая возможность освобождает программиста от написания процедуры просмотра цепи в поисках требуемой записи. [11]
Для реализации доступа к записи по методу вычисления адреса по значению первичного поискового ключа ( CALC-ключа) на каждой странице области организуются два специальных CALC-указателя. Эти указатели рассматриваются как запись - владелец экземпляра системного CALC-набора. При этом каждой странице соответствует свой экземпляр CALC-набора. При помещении записи в БД, на основании значения первичного ключа записи формируется по методу хеширования номер страницы области, затем запись размещается на этой странице и включается в CALC-набор, владелец которого находится также на этой странице. Если на странице не хватает места, то запись размещается на другой странице, однако включается в тот экземпляр CALC-набора, который находится на странице, определенной хешированием по значению ключа. При поиске записи по значению CALC-ключа СУБД с помощью хеширования определяет экземпляр CALC-набора, а затем в нем последовательным просмотром членов выполняет поиск требуемой записи. [12]
Страницы: 1