Сделано в России

Александр Соколов
Компания РДТЕХ
( mailto:ap_sokolov@mail.ru)
(под редакцией М. Р. Когаловского,
mailto:kogalov@cemi.rssi.ru)

О чистоте русского языка и точности терминологии
(часть XV)

• Введение
• Из переписки
    REF
    dangling REF
    dereference REF
    REF constraint
    Rowid REF Constraint
    scope constraint
    SCOPE REF constraint
    scope table
    scoped REF
    unscoped REF
    rescoping
    character
    indextype
    prebuild materialized view
    defining subquery of materialized view
    complex view
    datetime datatype
    block access pattern
    subscripted collection
    index-organized materialized view
    storage table
    member function, member procedure
    favoring
    enterprise directory service

Введение

Данный выпуск колонки посвящен продолжению обсуждению терминологических вопросов, возникших в процессе перевода комплекта документации СУБД Oracle9i, который выполняется компаниями РДТЕХ (www.rdtex.ru) и ITI Ltd. (www.iti.ru).

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

Из переписки

REF

Контекст.
Oracle provides a built-in datatype called REF to encapsulate references to row objects of a specified object type. The only changes you can make to a REF are to replace its contents with a reference to a different object of the same object type or to assign it a null value. See dangling REF, dereference REF, scoped REF, unscoped REF.

Перевод.
"тип данных REF"

Принятое предложение И.Абдуллина ( irek@rdtex.ru).
"встроенный тип данных REF ([объектная] ссылка)"

Комментарий А.Майорова (mayorov@rdtex.ru).
По поводу типа REF в целом. Поскольку в Oracle уже есть ссылки в виде foreign/primary key. Moжет, переводя REF, использовать термин "объектная ссылка"

Общий комментарий Н.Суренской (surenska@rdtex.ru).
Посмотрим документацию, переведенную нами по Oracle8:

"С помощью фразы SCOPE определяется ограничивающая таблица для значений REF." "Значение REF – это ссылка на строку объектной таблицы." "В общем случае, если в таблице есть столбец типа данных REF, каждое ссылочное значение этого столбца может ссылаться на строки различных объектных таблиц. Фраза SCOPE ограничивает область таких ссылок единственной таблицей". (выдержка из SQL Reference, версия 8).

Вроде и раньше все было логично.

Комментарий.
Нужно учитывать, что одна и та же фраза может использоваться по-разному. В заголовках желательно дать краткое, емкое название, чтобы, с одной стороны, все понимали, о чем идет речь, а с другой стороны, заголовок должен быть "красивым". Поэтому фраза "таблица, на которую указывает ограничение SCOPE типа данных REF" – для заголовка не годится.
Многие из обсуждавшихся терминов уже использовались при переводе Oracle8i Почему же мы этим не пользуемся? По-моему, в 9i много работы по обсуждению действительно новых терминов.

Общий комментарий И. Абдуллина.
Я попытался свести воедино все (или еще не все?) встреченные в этом обсуждении термины, естественно, со своими предпочтениями. По-моему, за редким исключением, все участники сошлись в достаточно узкой области.

dangling REF

Контекст .
If the object identified by a REF has become unavailable through either deletion of the object or a change in privileges. See REF.

Предложение переводчика.
"висячий REF", "висячая ссылка"

Новое предложение.
"висячий тип данных REF", "висячая ссылка"

Предложение Натальи Костюкевич (Natalia.Kostioukevitch@iti.ru).
"висячий REF", "висячая ссылка" ("висячий тип данных" звучит, по меньшей мере, странно)

Комментарий А. Майорова.
Перевод висячий тип данных, как мне кажется, абсолютно неверен. Тип данных здесь все тот же – "ссылка" REF. Просто значение этой ссылки стало недействительно, поскольку объект недоступен. "Висячая ссылка" хотя и имеет смысл, но мне кажется слишком жаргонным. Я бы выбрал что-нибудь более формальное – недействительная, устаревшая и т.п. Если конечно, не существует уже устоявшегося термина. Если у кого-нибудь есть под рукой русская литература по С или С++ (или может быть даже по Java), можно проверить там. Термин на самом деле оттуда.

Исправленный перевод.
"висячая (объектная) ссылка"

Комментарий Александра Усачева (usachev@rdtex.ru).
По сути это недействительная ссылка. Оригинал удалили, а копия (псевдоним) осталась и ссылается на недействительный адрес. Предлагаю так и переводить: недействительная ссылка или совсем заумно ссылка на недействительный адрес (объект).

Я не уверен, что правильно будет: "ссылка на удаленный (в смысле ликвидированный) объект.". Хотя, "ссылка на ликвидированный объект" по своей сути звучит очень точно.

Комментарий А. Соколова.
По всем доступным мне словарям по ВТ на профессиональном языке "недействительная" ссылка называется "висячей" или "повисшей". Кроме того, объект необязательно должен быть "ликвидирован" – просто могут быть отменены привилегии доступа к нему. Поэтому предложение перевода остается в силе.

Комментарий Михаила Рувимовича Когаловского.
Нужно заметить, что аналогичный термин существует в Вебе, и для него устоялся перевод "висячая ссылка".

dereference REF

Контекст .
Dereference REFs. Accessing the object referred to by a REF is called dereferencing the REF. Oracle provides the DEREF operator to do this. Dereferencing a dangling REF results in a null object.

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

Новое предложение.
"разыменовать (объектную) ссылку"

Комментарий А. Усачева.
Ссылку нельзя разыименовать, разыименовать можно указатель. Если разговор идет про ссылку, то говорят получение данных по ссылке получение значения переменной по ссылке передать по ссылке, и т.п. Предлагаю переводить: обратиться по ссылке, получить по ссылке. Вообще, по своей сути, ссылка это псевдоним. Если изменяется ссылка, то изменяется и оригинал.

Комментарий А. Соколова.
Желая как-то ограничить нашу оживленную дискуссию, сошлюсь только на словарь ABBY Lingvo: "dereference – разыменовывать (ссылки), снимать косвенность (ссылок)." При этом, в СУБД Oracle ссылки типа REF указывают не на объект, а только на его идентификатор. Поэтому предложение перевода остается в силе.

Принятое предложение И. Абдуллина.
"разыменовать [объектную] ссылку", "выбрать по ссылке"

REF constraint

Контекст .
A REF column by definition references an object in another object type or in a relational table. A REF constraint lets you further describe the relationship between the REF column and the object it references.

Предложение переводчика.
"ограничение REF"

Новое предложение.
"ограничение типа данных REF"

Предложение Н. Костюкевич.
"ограничение REF" (это ограничение не типа, а столбца или атрибута REF)

Исправленный перевод.
"ограничение столбца или атрибута типа данных REF"

Новый исправленный перевод.
"ограничение (объектной) ссылки на область видимости"

Предложение И. Абдуллина.
"ограничение [объектной] ссылки"

Замечание М. Р. Когаловского.
Такой перевод означает фактически, что речь идет об ограничении на конкретное значение типа REF (на ссылку).

Однако же, как справедливо замечает Наталья, на самом деле здесь говорится об ограничении, налагаемом на столбец типа REF. Поэтому нужно как минимум написать “ссылку” во множественном числе.

Принятое предложение.
"ограничение [объектных] ссылок"

Rowid REF Constraint

Контекст .
Specify WITH ROWID to store the rowid along with the REF value in ref_column or ref_attribute.

Предложение переводчика.
"ограничение Rowid REF" (ограничение REF с хранением идентификатора строки)

Новое предложение.
"ограничение ROWID типа данных REF"

Предложение Н. Костюкевич.
"ограничение Rowid для типа данных REF"

Мне не нравятся слова переводчика "ограничение REF с хранением идентификатора строки", потому что это что-то непонятное. Скорее, это ограничение, в соответствии с которым в столбце или атрибуте хранится не только REF, но и ROWID. Это предложение должно быть исправлено.

Предложение А. Майорова.
"ограничение на объектную ссылку с хранением идентификатора строки"
или
"ограничение на объектную ссылку с хранением RowID".

Исправленный перевод.
"ограничение столбца или атрибута типа данных REF с хранением ROWID"

Новый исправленный перевод.
"ограничение (объектной) ссылки на область видимости с хранением ROWID"

Принятое предложение И. Абдуллина с учетом приведенного выше замечания М. Р. Когаловского.
"ограничение [объектных] ссылок с хранением ROWID"

scope constraint

Предложение переводчика.
"ограничение SCOPE REF"

Новое предложение.
"ограничение SCOPE типа данных REF"

Предложение Н. Костюкевич.
"ограничение SCOPE для столбца REF", "ограничение SCOPE для типа данных REF"

Предложение А. Майорова.
"ограничение области действия " или "ограничение области определения"

Исправленный перевод.
"ограничение SCOPE для столбца типа данных REF"

Новый исправленный перевод.
"ограничение ссылки на область видимости"

Принятое предложение И. Абдуллина.
"ограничение области действия"

SCOPE REF constraint

Контекст .
In a table with a REF column, each REF value in the column can conceivably reference a row in a different object table. The SCOPE clause restricts the scope of references to a single table.

Предложение переводчика.
"ограничение SCOPE REF"

Новое предложение.
"ограничение SCOPE типа данных REF"

Предложение А. Майорова.
"ограничение области действия (определения) объектной ссылки "

Исправленный перевод.
"ограничение SCOPE для столбца типа данных REF"

Новый исправленный перевод.
"ограничение (объектной) ссылки на область видимости"

Принятое предложение И. Абдуллина с учетом приведенного выше замечания М. Р. Когаловского.
"ограничение области [действия] ссылок"

scope table

Контекст .
In a table with a REF column, each REF value in the column can conceivably reference a row in a different object table. The SCOPE clause restricts the scope of references to a single table, scope_table.

Предложение переводчика.
"таблица, на которую указывает ограничение SCOPE REF"

Новое предложение.
"таблица, на которую указывает ограничение SCOPE типа данных REF"

С учетом предложения Марка Вольштейна (Mark.Volshtein@iti.ru).
"таблица области ограничения типа данных REF" (таблица, на которую указывает ограничение SCOPE типа данных REF)

Предложение Н. Костюкевич.
"таблица, указанная в ограничении SCOPE для столбца REF"; "таблица, ограничивающая ссылку REF"

Предложение А. Майорова.
"ограничивающая таблица (если ограничивающая таблица объектной ссылки" ....)

Исправленный перевод.
"таблица, указанная в ограничении SCOPE для столбца типа данных REF"

Новый исправленный перевод.
"ограничивающая таблица (объектной) ссылки на область видимости"

Комментарий А. Усачева.
По сути, scope table – это таблица из области видимости (для чего-то). Фразу "The SCOPE clause restricts the scope of references to a single table, scope_table" можно перевести, как "SCOPE – ограничивает область действия ссылки/ (ограничивает область видимости ссылки) единственной таблицей, scope_table".

Комментарий Н. Суренской.
"scope table" – ограничивающая таблица. Термин уже применялся, и как мне кажется, не мешал, поскольку появлялся только при описании объектных возможностей.

Резюме.
"ограничивающая таблица ((объектной) ссылки на область видимости)"

Принятое предложение И. Абдуллина.
"ограничивающая [ссылки] таблица".

Комментарий М. Р. Когаловского.
Еще вариант – "целевая таблица ссылок".

scoped REF

Контекст .
In declaring a column type, collection element, or object type attribute to be a REF, you can constrain it to contain only references to a specified object table. Scoped REFs require less storage space and allow more efficient access than unscoped REFs. See REF.

Предложение переводчика.
"ограниченный REF", "ограниченная ссылка"

Новое предложение.
"ограниченный тип данных REF", "ограниченная ссылка"

Предложение Н. Костюкевич.
"ограниченная ссылка", "ограниченная ссылка REF"

Предложение А. Майорова.
"Ограниченная объектная ссылка". Опять же "ограниченный тип данных REF", кажется не верным, т.к. ограничивается не тип а переменные типа REF.

Исправленный перевод.
"ограниченная [объектная] ссылка"

Комментарий А. Усачева.
По сути (смыслу) – это ссылка с явно заданной (установленной) областью видимости. Соответственно, unscoped REF – это ссылка без явно заданной области видимости. Я думаю, что слово ЯВНО надо использовать обязательно.

Комментарий Н. Суренской.
"ограниченная объектная ссылка", "ограничение SCOPE на значения REF"

Замечание М. Р. Когаловского.
И снова та же проблема – речь не о конкретной ссылке, а о каждой ссылке, содержащейся в рассматриваемом столбце.

Резюме.
"ограниченные [объектные] ссылки"

unscoped REF

Контекст .

See scoped REF.

Предложение переводчика.
"неограниченный REF ", "неограниченная ссылка"

Новое предложение.
"неограниченный тип данных REF", "неограниченная ссылка"

Предложение Н. Костюкевич.
"неограниченная ссылка, неограниченная ссылка REF"

Предложение А. Майорова.
Тоже что и в предыдущем пункте – "неограниченная объектная ссылка".

Исправленный перевод с учетом приведенного выше замечания М. Р. Когаловского.
"неограниченные [объектные] ссылки"

rescoping

Контекст .
rescope a column or attribute to a new table

Предложение переводчика.
"изменение ограничения"

Предложение Н. Костюкевич.
"изменение ограничения SCOPE для столбца REF"

Предложение А. Майорова.
"изменение области действия"

Исправленный перевод.
"изменение ограничения SCOPE для столбца типа данных REF"

Новый исправленный перевод.
"изменение ограничения (объектной) ссылки на область видимости"

Комментарий А. Усачева.
RESCOPING – это назначение новой области видимости/ (области применимости)/(области действия) и т.п. Фразу "rescope a column or attribute to a new table". На мой взгляд, можно по-русски сказать, как "Столбцу или атрибуту назначается (устанавливается) новая область видимости в новой таблице".

Комментарий Н. Суренской.
"изменение ограничивающей таблицы", "изменение ограничения SCOPE на значения REF"

Резюме.
Содержимое самой ограничивающей таблицы не изменяется. Поэтому "изменение ограничения (объектной) ссылки на область видимости".

Комментарий И. Абдуллина.
Примечание по поводу scope. В документации Oracle этот термин применяется как-то очень нестрого. Например, в PL/SQL:

"The scope of an identifier is that region of a program unit (block, subprogram, or package) from which you can reference the identifier. An identifier is visible only in the regions from which you can reference the identifier using an unqualified name."

Т.е. область, где объект существует или "виден", ОТКУДА можно к нему обратиться. В этом случае я переводил scope как "область действия".

Здесь же (в связи с REF) речь, скорее, идет об области значений ссылок, т.е. КУДА они могут указывать. Поэтому, мне кажется, "область действия" достаточно нейтрально и лучше подходит и в данном случае.

Предложение И. Абдуллина.
"изменение области действия"

Принятое уточнение М. Р. Когаловского.
Точнее было бы, на мой взгляд, "замена области действия".

character

Вопрос М. Вольштейна.
В глоссарии "character" – это символ. Но в руководстве по PL\SQL такой перевод может привести к двусмысленности (например, в следующем выражении: "Simple symbols consist of one character.")

Может быть, имеет смысл в этой книге переводить "character" как знак?

Комментарий А. Соколова.
Да, раньше мы так и писали:
"Простой символ представляет собой один знак."

Принятое уточнение М. Р. Когаловского.
Ранее в литературе использовался более точный термин "литера".

indextype

Предложение Н. Суренской.
В SQL Reference встречается новый объект БД – indextype ( см. CREATE INDEXTYPE и т .д .). Переводчики переводят это как "Тип indextype". Слишком похоже на "недопереведенный" термин. Мое предложение – переводить как индексный тип (это действительно относится к расширениям индексирования).

Резюме.
Предложение принимается: "тип INDEXTYPE (индексный тип)"

prebuild materialized view

Предложение А . Майорова .
У переводчика в тексте "материализованное представление предварительно созданной таблицы".

Предлагаю переводить как "материализованное представление с предварительной инициализацией".

Комментарий А. Соколова.
Если не будет возражений, внесу в глоссарий.

defining subquery of materialized view

Предложение А. Майорова.
У переводчика: "подзапрос определения материализованного представления"

Предлагаю переставить слова: "определяющий подзапрос ...."

Комментарий А. Соколова.
Если не будет возражений, внесу в глоссарий.

complex view

Контекст .
If the materialized view is complex, the master rollback segment, if specified, is ignored.

Вопрос А. Майорова.
Где-нибудь есть определение "complex view"?

Предложение А. Соколова.
В Advanced Replication :

Specifically, a materialized view is considered complex when the defining query of the materialized view contains:

1. A CONNECT BY clause.
2. An INTERSECT, MINUS, or UNION ALL set operation.
3. In some cases, the DISTINCT or UNIQUE keyword, although it is possible to have the DISTINCT or UNIQUE keyword in the defining query and still have a simple materialized view.
4. An aggregate function.
5. Joins other than those in a subquery.
6. In some cases, a UNION operation. Specifically, a materialized view with a UNION operation is complex if any one of these conditions is true:

• Any query within the UNION is complex. The previous bullet items specify when a query makes a materialized view complex.
• The outermost SELECT list columns do not match for the queries in the UNION.

7. Clauses that do not comply with the requirements detailed in "Restrictions for Materialized Views with Subqueries" on page 3-26.

See Also:

• Oracle9i Data Warehousing Guide for more information about materialized views with aggregate functions and complex materialized views,
• Oracle9i SQL Reference for more information about the CONNECT BY clause, set operations, the DISTINCT keyword, and aggregate functions.

Я бы не стал называть их "сложными", а "комплексными".

Комментарий И. Абдуллина.
В самом первом курсе по SQL мы переводили complex view (с похожими свойствами, что ты привел) как "сложное представление", в противовес "простому".

Именно через такие представления тогда нельзя было изменять базовые таблицы, на которых они основаны (а через "простые" – можно). Естественно, это относилось к обычным, а не к материализованным представлениям.

Лично я не возражаю против "комплексных материализованных представлений".

datetime datatype

Предложение М. Вольштейна.
По-моему, "datetime datatype" не стоит переводить как "тип DATE", поскольку это целая группа типов, включающая не только тип DATE, но и другие типы (TIMESTAMP, TIMESTAMP WITH TIME ZONE and TIMESTAMP WITH LOCAL TIME ZONE). Может, привести перевод этого термина в соответствие с переводами аналогичных терминов (напр, "datetime value" – "значение типа даты-времени")

Комментарий А. Соколова.
"datetime datatype" – "тип даты -времени ". Я внес это предложение в глоссарий.

Комментарий Александра Пересыпкина (aperesypkin@mail.ru ).
Я так и переводил в книге по PL/SQL: "тип даты-времени", "переменная типа даты-времени" и т.д.

block access pattern

Контекст .
The amount of caching depends on factors that the optimizer cannot predict, such as the load on the system and the block access patterns of different users. (Database Reference; Initialization Parameters)

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

Комментарий А. Соколова.
По моему, здесь говорится о "профиле (характере) доступа различных пользователей к блокам".

Принятое приложение И. Абдуллина.
"профиль поблочного доступа"

Комментарий Андрея Криушина (kriushin@rdtex.ru).
Согласен с комментарием А. Соколова. Уточнение – речь идет о различиях в поведении серверного процесса при реализации путей доступа к данным в планах выполнения (access path) – TABLE FULL SCAN/INDEX FAST FULL SCAN или TABLE BY ROWID (обычно следствие INDEX UNIQUE/RANGE SCAN). В первом случае блоки зачитываются "порциями" из db_file_multiblock_read_count блоков и помещаются в конец списка LRU (являются кандидатами на вытеснение из кеша), в последнем – в начало списка LRU.

В данном Контексте имеет смысл не конкретизировать указанные детали (они должны быть известны пользователю из других источников, например "Tuning").

Рекомендуемые варианты – "способ/характер/профиль доступа различных пользователей к блокам".

НИ В КОЕМ СЛУЧАЕ не использовать "поблочный" – обычно подразумевается TABLE BY ROWID, в отличие от "многоблочный" – FULL SCAN.

Комментарий Н. Суренской.
Может быть, сказать попроще и понятнее – "способ доступа к блокам", "метод доступа к блокам". "Профиль доступа" – звучит непривычно, непонятно, о чем речь, возникают ненужные ассоциации с профилем пользователя.

Комментарий А. Криушина.

Поддерживаю Наташу – попроще надо. В конце концов это НЕ ТЕРМИН, а оборот речи.

Комментарий А. Соколова.
Здесь говорится не о способах или методах доступа отдельных транзакций к блокам данных, а об общей совокупности временных характеристик всех составляющих транзакций, а именно о "профиле доступа различных пользователей к блокам". Если Ирек не будет возражать, я вставлю это определение в глоссарий.

Резюме И.Абдуллина и А.Соколова.
"профиль доступа [различных пользователей] к блокам"

subscripted collection

Контекст .
The SQL statement can reference more than one collection. However, the PL/SQL engine bulk-binds only subscripted collections. (PL/SQL User’s Guide and Reference)

Предложение переводчика.
"коллекция с индексами (индексированная коллекция)"

Принятое предложение И. Абдуллина.
В приведенном Контексте (оператор FORALL), мне кажется, предпочтительнее вариант: "обращения к элементам коллекций" (с использованием индекса оператора FORALL).

Замечание М. Р. Когаловского.
А почему не просто "индексированная коллекция"?

Комментарий А. Соколова.
Это понятно из следующего Контекста:

"Remember, the PL/SQL engine bulk-binds only subscripted collections. So, in the following example, it does not bulk-bind the collection sals, which is passed to thefunction median (Следует помнить , что машина PL/SQL выполняет массовое связывание только коллекций , к элементам которых есть обращение в операторе SQL. Например, в следующем примере не происходит массового связывания коллекции sals, передаваемой функции median):

FORALL i IN 1..20
INSERT INTO emp2 VALUES (enums(i), names(i), median(sals), ...);

index-organized materialized view

Контекст .
The ORGANIZATION INDEX clause lets you create an index-organized materialized view. In such a materialized view, data rows are stored in an index defined on the primary key of the materialized view.

Предложение переводчика.
"материализованное представление в форме индекса"

Предложение А.Соколова.
У нас как-то устоялся перевод термина "index-organized table"как "индекс-таблица", почему бы нам не пойти таким же путем и не переводить термин "index-organized materialized view" как "материализованный индекс-представление". Если не будет серьезных возражений от наших гуру, я так и сделаю.

Комментарий И.Абдуллина.
Мне кажется, что "материализованное индекс-представление" выглядит и звучит вполне нормально.

Комментарий М.Р.Когаловского.
На мой взгляд, Предложение переводчика в точности отражает существо понятия, судя по приведенному Контексту. И этот перевод понимается однозначно без каких-либо комментариев.

В то же время, Ваш вариант не обладает такой ясностью. "Индекс-представление" – это уже некая условность.

Из двух предложенных вариантов я бы отдал предпочтение варианту переводчика.

К тому же, вероятно, это понятие встречается не слишком часто.

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

Мнение А.Бачина.
Согласен с вариантами:

• индекс-таблица
• материализованное индекс-представление

Термин " материализованное представление в форме индекса" – слишком громоздок, а его "избыточная" точность может повлечь за собой желание уточнить понятия "представление", "материализованное" и, уж конечно, "индекс".

Какой индекс? Глобальный, локальный, префиксированный или нет? Битовый или B*tree и т.д.

Кроме того, прошу поправить, если ошибаюсь, "материализованное индекс-представление" – это все-таки индекс-таблица, а не представление в форме индекса.

Резюме.
Мне кажется, что материализованные индексы-представления строятся по образу и подобию индекс-таблиц, просто механизмы работы с ними несколько отличаются.

• "индекс-таблица"
• "материализованное индекс-представление"

storage table

Контекст .
Use the name of the storage table specified in the nested_table_col_properties to make the modification.

Предложение переводчика.
В этом Контексте – "главная таблица".

Комментарий А. Соколова.
В этом Контексте – таблица хранения (вложенной таблицы). Есть еще "parent table".

Принятое предложение М.Р.Когаловского.
Я бы использовал термин "хранимая таблица".

member function, member procedure

Контекст .
First, member function reciprocal()is called, then member procedure normalize() is called. (PL/SQL User’s Guide and Reference)

Предложение переводчика.
"функция-член", "процедура-член"

Комментарий А.Соколова
В предыдущем переводе данной книги использовались термины "метод-функция" и "метод-процедура". Предлагаю такими их и оставить.

Комментарий И.Абдуллина.
Я поддерживаю "метод-функция" и "метод-процедура".

Резюме.
Данное предложение принято.

Комментарий А.Майорова.
Поддерживая Александра, хочу заметить, что в абсолютном большинстве случаев, если по Контексту особого значения тип метода (функция или процедура) не имеет, то лучше употреблять просто "метод". То же самое и по отношению к "constructor function", не знаю уж зачем Oracle акцентирует на этом внимание, но, как мне кажется общеупотребимый термин – просто "constructor", соответственно, я бы в переводе всюду использовал "конструктор" без всяких функций.

favoring

Контекст .
OPTIMIZER_INDEX_CACHING lets you adjust the behavior of cost-based optimization to favor nested loops joins and IN-list iterators. (Database Reference; Initialization Parameters)

Предложение переводчика.
"ранжирование по предпочтению"

Принятое приложение И. Абдуллина.
Варианты: "отдавая предпочтение", "в пользу".

enterprise directory service

Предложение переводчика .
"сервис каталогов предприятия"

Новое принятое предложение А. Майорова.
"корпоративная служба каталогов"

Продолжение следует.