<<
>>

Варианты выбора распределенной СУБД

Почему используют архитектуру клиент/сервер? В настоящее время для построения систем распределенной обработки данных используются модели сервера БД и сервера приложений, поддерживающие архитектуру клиент/сервер, т.е.
прикладная или системная программа (клиент) выставляет запрос на выполнение SQL-оператора или сервис-приложения. Сервер СУБД обрабатывает этот запрос и возвращает программе результаты выполнения.

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

Сравним для двух технологий число пакетов (кадров), которые передаются между рабочей станцией и сервером при выполнении запроса, описанного в § 12.2.

Предполагается, что таблица Счет имеет сложный индекс (код клиента, тип счета).

1. Предположим, что в программе, написанной на языке СУБД FoxPro выполняется следующий оператор поиска в таблице Счет:

LOCATE FOR код клиента = 1 .AND. тип счета HOMep_C4eTa; /* номер счета*/

/* описать запрос SELECT */

EXEC SQL declare acur cursor for select остаток from счет where HOMep=:s;

/* открыть курсор и выполнить запрос к БД*/

EXEC SQL open acur;

/* получить остаток */

EXEC SQL fetch acur into :d; if (SQLCODE!=SQL_OK) {

/* произошла ошибка, направить в VIEW-буфер сообщение об ошибке */ strcpy(transv->ermsg, «ошибка при чтении остатка и таблицы СЧЕТ»); EXEC SQL close acur;

tpreturn(TPFALL, 0, transb->data, sizeof(struct aud), 0);

}

else{

/* операция поиска выполнена успешно */

EXEC SQL close acur; transv->ocTaTOK=d;

tpreturn(TPSUCCESS, 0, transb->data, sizeof(struct aud), 0);

}

}

Мультиплексирование запросов к базам данных.

Tuxedo System можно рассматривать как своеобразный программный мультиплексор запросов к базам данных.

Принципы обращения клиентов приложения к БД в системах, опирающихся на менеджеры транзакций, совершенно иной, чем в двухзвенных системах «SQL-клиент—SQL-сервер». В последних существует понятие одновременных подключений к БД (concurrent connection). Процесс клиента считается подключенным к СУБД, начиная с момента открытия сеанса с БД (инициируется оператором CONNECT) и заканчивая его закрытием. Операция CONNECT является ресурсоемкой, выполняется медленно и не рекомендуется для частого использования. В течение сеанса СУБД считает клиента активным и вынуждена хранить контекст его подключения даже в том случае, если клиент вообще не направляет запросов СУБД, а выполняет свои внутренние функции или, может быть, ушел пообедать. Схема взаимодействия клиента и сервера БД выглядит следующим образом: клиент и сервер открывают SQL-канал на весь период работы клиента (инициирует открытие канала клиент) и обмениваются по нему SQL-запросами и данными в синхронном режиме. В лицензионном соглашении на использование СУБД под количеством пользователей, от которого зависит стоимость лицензии, подразумевается число одновременных подключений к СУБД клиентских процессов. Возможны вариации (для различных СУБД лицензионное соглашение выглядит по-разному), но суть остается одной.

Совершенно иначе выполняется подключение клиентов в системах с трехзвенной архитектурой. Клиент вообще не обращается к базе данных — 290

он ее «не видит». Клиент обращается с запросами к серверу приложений в одном из допустимых режимов. Взаимодействие клиента и сервера приложений контролирует Tuxedo System/T. Подключение к System/T (начало сеанса) выполняется вызовом tpinit(), терминирование связи (завершение сеанса) производится вызовом tpterm().

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

Клиент приложения подключается к Tuxedo System/T, формирует исходные данные в буфере и вызывает сервис, передавая ему данные в буфере. Сервис, в свою очередь, извлекает данные из буфера и формирует SQL-запрос, который направляется соответствующему менеджеру ресурсов (СУБД). Получив от него данные, сервис размещает их в результирующем буфере и направляет его клиенту. Единственные исполнители прикладных действий — сервисы — не монополизируются каким-либо клиентом, а доступны для общего использования всеми клиентами. При каждом вызове сервиса создается внутренний поток в рамках процесса, содержащего сервис.

Таким образом, для систем с трехзвенной архитектурой, работающей под управлением Tuxedo, не существует ограничений на число клиентов. Это и объясняет применение менеджеров транзакций (и Tuxedo в том числе) для систем, характеризуемых сверхбольшим числом клиентов (от сотен до тысяч). Кроме того, в системах с трехзвенной архитектурой резко сокращается число одновременных подключений к СУБД (что существенно уменьшает стоимость лицензии на ее использование). Как уже говорилось, клиенты к СУБД не подключаются. Подключение к СУБД производится процессом сервера приложений (от каждого процесса по одному подключению). Каждый такой процесс одновременно обрабатывает N запросов, поступающих от клиентов. А количество лицензионных подключений к СУБД определяется общим числом процессов (серверов), включенных в приложение, и не зависит от числа обрабатываемых в текущий момент запросов от клиентов. Опубликованные данные свидетельствуют о том, что количество подключений к СУБД в системе с трехзвенной архитектурой по сравнению с традиционной технологией применения СУБД может быть уменьшено в 4—16 раз, а выигрыш в стоимости от приобретения менеджера транзакций и СУБД по сравнению с приобретением только СУБД с лицензией на большее число пользователей может достигать 50 %.

Интероперабельность распределенных СУБД: возможность создания разнородной информационной среды. Шлюзы для доступа к разнородным базам данных.

Как отмечалось, шлюзы обеспечивают возможность приложений, созданных средствами разработки данной СУБД, оперировать над БД в «чужом» формате так, как будто это собственные БД.

На рис. 13.8 представлена схема организации гетерогенной среды с помощью шлюза OmniConnect фирмы Sybase.

Server Server Server

Рис. 13.8. Связь разнородных СУБД с помощью шлюза OmniConnect

OmniConnect хранит информацию о размещении таблиц на том или ином сервере БД. Централизованно хранятся и исполняются глобальные хранимые процедуры. Приложение-клиент может осуществлять транзакции, в которых участвуют таблицы из различных БД, а также выполнять процедуры, которые OmniConnect при работе с СУБД, отличными от Sybase, преобразует к соответствующему диалекту SQL.

На рис. 13.9 приведена схема организации связи разнородных СУБД с помощью шлюза Informix-Enterprise Gateway фирмы Informix.

Шлюз Informix-Enterprise Gateway обеспечивает для инструментальных средств и приложений БД, выполняемых под управлением операционной среды Unix или MS Windows, доступ к информации, хранящейся в БД — более 60 типов (среди которых Oracle, Sybase, Ingres, Adabas, IMS, VSAM, CA-IDMS и др.). Поддерживаемые операционные системы — Unix, MVS, VM, VMS. Доступ реализуется при помощи программных продуктов Enterprise Data Access SQL (EDA/SQL) компании Information Builders. Шлюз позволяет выполнять распределенные соединения таблиц из разнородных БД и импортировать «чужие» данные в БД Informix.

Enterprise Gateway выполняется как процесс сервера СУБД Informix, который конвертирует запросы клиентов Informix в запросы EDA/SQL. Когда от клиентского приложения поступает инструкция SQL или удаленный вызов процедуры, предназначенный для Enterprise Gateway, то он перенаправляется на EDA/SQL Server, который обращается к соответствующим реляционным или нереляционным источникам данных.

Данные, полученные от EDA/SQL Server, Enterprise Gateway возвращает приложению клиента.
Server Server Server

Рис. 13.9. Связь разнородных СУБД с помощью шлюза Informix-Enterprise Gateway

На рис. 13.10 представлена схема организации связи разнородных СУБД на базе шлюзов Oracle Transparent Gateways и Oracle Procedural Gateways.

Независимость от источников данных, как важная составляющая открытости Oracle, реализована двумя наборами продуктов: Oracle Transparent Gateways (прозрачные шлюзы) и Oracle Procedural Gateways (процедурные шлюзы). Прозрачные шлюзы обеспечивают доступ из SQL к БД и файловым системам — DB2, Rdb, ADABAS, IDMS, IMS, SQL/DS, SQL/400, VSAM и плоским файлам. Процедурные шлюзы реализуют интерфейс с мониторами транзакций, операционными системами и внешними приложениями из языка PL/SQL.

ODBC-интерфейс доступа приложений к различным серверам СУБД. Фирма Microsoft разработала специальный интерфейс ODBC (Open DataBase Connectivity), позволяющий Windows-приложениям рабочих станций обращаться к различным СУБД, поддерживающим как модель сервера БД (Oracle, Sybase, Informix и др.), так и модель файлового сервера (dBase, Paradox) (рис. 13.11).

ODBC-интерфейс представляет набор функций для языка С, C++ и Visual Basic для Windows. Связь с СУБД осуществляется с помощью языка SQL (даже с СУБД, поддерживающими модель файлового сервера). С помощью функции SQLConnect приложение может подключиться к различным СУБД. Далее в программе должна быть подготовлена строка с оператором SQL. Функция SQLExecute выполняет этот оператор, обращаясь через ODBC-драйвер к требуемой СУБД. Оператор SQLFetch читает результаты выполнения SQL-предложения в ПП.

Комплексы драйверов ODBC предлагают и независимые разработчики. Этот стандарт обеспечивает эффективные средства доступа к

Рис.

13.10. Связь разнородных СУБД с мониторами транзакций с помощью шлюзов Oracle

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

SQL3 — объектно-реляционное расширение языка SQL. Реляционный подход, используемый в современных СУБД, имеет ряд преимуществ:

• реляционные БД построены на солидном теоретическом основании (теория реляционной алгебры);

• реляционная технология подкреплена стандартами, которые одобрены ISO и ANSI (SQL/89 и SQL/92).

В то же время можно отметить недостатки реляционной технологии.

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

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

3. Реляционная модель не позволяет рассматривать данные послойно, при необходимости отвлекаясь от ненужных деталей (при объектном подходе в поле можно хранить ссылку на запись другой таблицы),

Рис. 13.11. Доступ ХУшс^Б-приложений к различным СУБД

4. В реляционной модели усложнен интерфейс между языком программирования и языком баз данных: С-курсор-БОЬ (при объектном подходе объекты встроены в язык программирования).

Перечисленные ограничения реляционной модели можно преодолеть с помощью объектно-ориентированного подхода. Ниже перечислены основные свойства объектов (не только для СУБД).

1. Инкапсуляция — совокупность данных и операций (методов). Чтобы активизировать объект, необходимо послать сообщение какому-либо его методу.

2. Наследование — возможность создавать из объекта новый объект, который наследует данные и методы своего предшественника. Например, объект Сотрудник (номер, место работы, зарплата) может наследовать данные объекта Человек (пол, возраст, имя).

3. Полиморфизм — различные объекты могут получать одинаковые сообщения, но реагировать на них по-разному, в соответствии с их методами, реагирующими на сообщения. Например, на сообщение «нарисовать» объекты «прямая» и «окружность» отреагируют по-разному.

Некоторые СУБД (например, иш8С)Ь 3.5 фирмы ишБОЬ) уже используют объектно-ориентированную МД, которая является расширением реляционной МД. Такие СУБД часто называют объектно-реляционными. Основой расширения служит примерная равнозначность схемы отношения (таблицы) и класса. Объектно-реляционная модель расширяет реляционную МД следующим образом:

• атрибутом может выступать ссылка на кортеж (запись) другого отношения (таблицы);

• расширение свойств отношений (к атрибутам добавляются методы);

• каждая схема отношения (таблица) расширяется системным атрибутом, значение которого является уникальным идентификатором объекта;

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

• разрешается рекурсивно наследовать свойства класса всем его подклассам. В подкласс можно добавлять дополнительные атрибуты и методы;

• допускается доступ к атрибутам и методам класса только посредством сообщений.

Стандарт для построения объектно-реляционных СУБД определяет расширение языка SQL и называется SQL3. Рассмотрим особенности SQL3 подробнее.

Описание классов (инкапсуляция). Класс соответствует схеме отношения (таблице) реляционной модели. Класс можно описать двумя способами:

1. Описание класса Address:

create type Address (city char(30), state char(2), street char(30), house integer, flat integer);

Объект Addr класса Address создается с помощью следующего оператора: create table Addr of Address;

2. Совмещенное описание класса Person и создание объекта People (экземпляра класса). Класс Person включает и описание методов:

create table People of new type Person

(

/* описание полей */ name char(30),

address Address, /* ссылка на кортеж типа Address */

birthdate date,

/* описание методов (функций) */

age virtual, /* функция age является виртуальной,

т.е. другая функция с тем же именем может быть описана в подклассе */ function age (:р ref(Person)) /* параметр :р есть ссылка (rei)

на кортеж Person */

returns interval day; /* функция возвращает возраст

с точностью до дня */

begin

return current date — :p.birthdate;

end;

Наследование определяется с помощью фразы under. Ниже описан класс Employee, который наследует данные и методы класса Person. При обработке записей Employee используется метод age, описанный в этом подклассе, так как он представлен как виртуальный:

create type Employee under Person

(

/* описание полей */ salary float, job char(20),

manager Employee, /* рекурсивная ссылка на кортеж Employee */ /* описание методов (функций) */

age virtual, /* функция age является виртуальной */

function age (:р ref(Employee)) /* параметр :р есть ссылка

(ref) на кортеж'Employee */

returns interval year; /* функция возвращает возраст с точностью

до года*/

begin

return current date — :p.birthdate;

end;

);

Создание объекта Empl класса Employee:

create table Empl of Employee;

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

На рис. 13.12 представлено описание связей между объектами (таблицами) People, Empl и Addr.

Объектно-реляционный подход значительно расширяет возможности использования поисковых операторов. Рассмотрим два примера.

1. Использование путей и методов в операторе SELECT. Выдать имена сотрудников старше 50 лет, проживающих в Лондоне и имеющих управляющего по имени Джонс:

SELECT e.name

FROM Empl e /* e — это псевдоним объекта Empl */

WHERE e.age>50 AND e.address.city-Лондон1 AND

e.manager.name- Джонс';

Рис. 13.12. Связи между объектами примера

Здесь используют два пути (e.address.city и e.manager.name) для доступа по ссылке к полям других кортежей и метод age. При обращении к методу age система автоматически подставляет в качестве аргумента этой функции ссылку на текущий кортеж Empl.

2. Использование полиморфизма объектов. Выдать возраст всех сотрудников с точностью до года, а остальных лиц, описанных в People, — с точностью до дня:

SELECT p.age

FROM All People p;

Здесь All означает, что просматриваются кортежи класса (People) и подкласса (Empl).

Возможности технологии брокера объектных запросов. Брокер объектных запросов (Object Request Broker — ORB) — это строительные блоки, неоднократно используемые при разработке масштабируемых программных систем. В ORB реализуются методы, позволяющие одним объектам обнаруживать другие и обращаться к ним с запросами по сети, независимо от платформы, на которой исполняется каждый из объектов, и от языков программирования, посредством которых они были созданы.

Консорциум производителей программного обеспечения Object Management Group (OMG) установил некоторые из ключевых стандартов, обеспечивающих возможности взаимодействия объектов. Утвержденная им спецификация CORBA (Comrnon Object Request Broker Architecture) послужила основой для создания такими производителями, как IBM, Sun Microsystems, Hewlett-Packard, lona Technologies и ExperSoft, программных продуктов, благодаря которым корпоративные разработчики могут создавать распределенные объектные системы, включающие в себя и унаследованные приложения.

ORB является одним из пяти основных видов программного обеспечения промежуточного слоя. Остальные четыре: связи с БД (database соп- nectivity), системы распространения сообщений (Message-Oriented Middleware — МОМ), мониторы обработки транзакций (Transaction Processing (ТР) monitor) и системы, основанные на технологии удаленного вызова процедур (Remote Procedure Cali — RPC).

Подобно другим видам программного обеспечения промежуточного слоя, ORB в распределенных вычислительных системах с архитектурой клиент/сервер выполняет ту же роль, что и коммуникации в небоскребе. Обычно программное обеспечение ORB пишется на языке C++ и поддерживает объекты, написанные на C++, Smalltalk и Java.

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

Определения интерфейсов объектов могут быть помещены в репозиторий интерфейсов (Interface Repository), который представляет компоненты интерфейсов для конкретных языков и обеспечивает доступ к объектам в период выполнения.

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

• интерфейс динамического вызова;

• стаб, генерируемый компилятором IDL (Interface Definition Language — язык определения интерфейсов); стаб (stab) — это локальная процедура вызова заданной операции при обращении к ней.

ORB ищет соответствующий код реализации объекта, посылает ему параметры заявки и передает управление (как правило, на другом узле). Реализация объекта принимает параметры заявки через сгенерированный компилятором IDL скелетон (skeleton) и при этом может обращаться к объектному адаптеру (Object Adapter) и ORB. Скелетон — это специфический для каждого интерфейса компонент ORB, служащий для передачи параметров заявок конкретным методам. Когда обработка заявки завершена, выходные значения возвращаются клиенту. Объектный адаптер является основным средством взаимодействия ORB с реализацией объекта.

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

Рис. 13.13. Структура интерфейса брокера объектных запросов

чивающее внутреннее представление объектов и передачу заявок, и набор надстраиваемых компонентов, интерфейсы которых «маскируют» различия в реализации ORB. Клиенты максимально мобильны и должны работать без изменения исходного кода в среде любого ORB, который поддерживает отображение IDL в соответствующий язык программирования. Языковое отображение определяет характерные для IDL типы данных и интерфейсы доступа к объектам средствами соответствующего языка программирования.

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

В настоящее время существует ряд промышленных реализаций ORB, соответствующих стандарту CORBA. Лидером рынка можно считать фирму Iona Technologies, которая продала свое программное обеспечение более чем 10 тыс. клиентов из разных стран мира. Ее ORB Orbix существует в версиях для множества платформ, включая различные редакции Unix, Windows, Macintosh, компьютеры производства Digital Equipment под управлением ОС VMS и всевозможные Web-серверы.

Отличительной особенностью продукта корпорации Visigenic Software является использование интеллектуальных программ-агентов в составе программного обеспечения ORB Visibroker. Эти агенты обнаруживают сбои серверов и автоматически переносят исполнение сервисов на исправные компьютеры в пределах локальной сети, а также выравнивают вычислительную нагрузку.

Корпорация ExperSoft предлагает «нейтральный» в отношении объектной модели и языка программирования ORB PowerBroker Corbaplus for C++ and OLE. Это одна из первых систем, поддерживающих одобренную OMG спецификацию COM/CORBA-взаимодействия. С помощью этой системы приложения, являющиеся OLE-клиентами, могут взаимодействовать с CORBA-объектами.

SunSoft возлагает надежды на Joe. В отличие от других ORB, большинство из которых написано на C++, для создания Joe использовался язык Java. Используя этот продукт, можно организовать взаимодействие Java- компонентов с объектами, основанными на других технологиях, в рамках интрасетей предприятий или по Internet. На рис. 13.14 представлен пример схемы обработки электронных карточек учета рабочего времени на основе объектной среды Joe (Java Object Environment).

Обработка карточки выполняется в такой последовательности (см. рис. 13.14):

1) броузер загружает активный объект Java, служащий внешним интерфейсом, и клиентский компонент Joe;

2) активный объект Java получает от брокера объектных запросов дескрипторы объектов, представляющих сотрудника и карточку учета рабочего времени.

С сервера, на котором находится представляющий сотрудника объект, поступает информация о работнике (через адаптер — объектно-ориентированную СУБД).

Пользователь броузера вводит данные, активный объект Java проверяет допустимость введенных им значений на месте. Корректные данные пе-

Клиент Сервер

Рис. 13.14. Система обработки электронных карточек учета рабочего времени, построенной на основе объектной среды Joe

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

Программное обеспечение Joe основано на технологии NEO и входит как составная часть в интегрированную среду объектно-ориентированной разработки NEOworks. Хотя среда NEOworks способна функционировать только под управлением ОС Solaris корпорации Sun, сам ORB является полностью кроссплатформным.

Программное обеспечение ORBplus 2.0 компании HP создано в первую очередь для обеспечения интеграции между платформами Unix и Windows NT. В нем реализована одновременная «прозрачная» поддержка нескольких транспортных протоколов, прежде всего НОР, описанного спецификацией CORBA, и DCOM корпорации Microsoft.

Различие между производителями ORB определяется также числом поддерживаемых ими языков программирования. Самый широкий выбор предлагает Iona: C++, Smalltalk, Ada95, Java и Visual Basic (на основе OLE). ExperSoft поддерживает C++ и Smalltalk — язык, который предпочитают переходящие к объектному программированию приверженцы языка Cobôl.

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

Производители не оставляют пожелания покупателей без внимания: HP, например, запустила в разработку дополнительный комплект инструментальных средств для ORBplus под названием Wizards. Он может использоваться непосредственно в интегрированной среде разработки Microsoft Developer Studio и обеспечивает автоматическую генерацию программного кода на C++, необходимого для работы с CORBA-приложениями и сервисами.

Спецификация CORBA описывает 13 различных сервисов, однако большинство производителей ORB поддерживают только два из них — службу именования и службу событий.

Большинство производителей реализуют в своих продуктах и некоторые дополнительные сервисы, важнейшие из которых — служба обработки транзакций и служба обеспечения безопасности. Впрочем, и сами идеологи из OMG признают, что большей части разработчиков приложений полный спектр сервисов не нужен.

ORB не является самостоятельным продуктом. Он может существовать только в окружении поддерживающих его платформ, специализированных сервисов, интерфейсов и средств разработки. Корпорации Sun и IBM объявили о намерении встроить программное обеспечение ORB в свои операционные системы, что сделает доступ к этой технологии фактически бесплатным.

<< | >>
Источник: Григорьев Ю.А., Ревунков Г.И.. Банки данных. 2002

Еще по теме Варианты выбора распределенной СУБД:

  1. Выбор линейного мышления - это выбор прожить жизнь в танце частиц.
  2. Выбор есть. Он существует всегда. Сознание - это выбор.
  3. ДИАПАЗОН РАСПРЕДЕЛЕНИЯ
  4. 4.3. Анализ двумерных распределений
  5. 4.2. Анализ одномерных распределений
  6. Закон нормального распределения
  7. Закон нормального распределения
  8. 4. Распределение прибыли и убытков простого товарищества
  9. § 7. Право на участие в распределении прибыли (п. 2254-2257)
  10. 8.1.2. Распределение ролей между интервьюером и интервьюируемыми
  11. Статья 123. Распределение прибыли и убытков полного общества
  12. Статья 1139. Распределение прибыли
  13. 8.1.2. Распределение ролей между интервьюером и интервьюируемыми
  14. § 3. Распределение внешнеполитических полномочий между высшими органами государственной власти и управления
  15. Вариант 3.
  16. Вариант 1.
  17. Вариант 2.
  18. Варианты
  19. Второй вариант.
  20. Варианты определений