Ключи sql

Естественный и суррогатный ключ

Как определяют первичный ключ таблицы базы данных? Два рассмотренных нами примера — «Студенты» и «Клиенты банка» — иллюстрируют понятия естественного и суррогатного ключа. В таблице клиентов банка мы определили ключ, состоящий из полей «Номер» и «Серия паспорта», использовав уже имеющиеся столбцы. Такой ключ называется естественным, для его определения мы не производили никаких изменений и дополнений. В случае с отношением «Студенты» ни одно поле или сочетание полей не давали нам уникальности. Это вынудило нас ввести дополнительное поле с кодом учащегося. Такой ключ называется суррогатным, для него мы добавили еще один служебный столбец в таблицу. Этот столбец не несет никакой полезной информации и служит только для идентификации записей.

Что такое внешний ключ

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

Рисунок 1: Первичный и Внешний ключ

Например, предположим, что есть база данных продаж. Имеются таблицы клиентов и продуктов. Таблица customer содержит столбцы customer_id, name, address и contact_no. Первичный ключ таблицы клиента — customer_id. Товар имеет столбцы product_id, name, quality. Первичный ключ таблицы продукта — product_id. Размещение product_id в таблице клиентов создаст связь между двумя таблицами. Product_id в таблице product является первичным ключом, но это внешний ключ в customer_table. Аналогично, можно соединять таблицы в базе данных, используя внешний ключ.

Ограничения первичного ключа

Обычно в таблице есть столбец или сочетание столбцов, содержащих значения, уникально определяющие каждую строку таблицы. Этот столбец, или столбцы, называются первичным ключом (PK) таблицы и обеспечивает целостность сущности таблицы. Ограничения первичного ключа часто определяются в столбце идентификаторов, поскольку гарантируют уникальность данных.

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

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

В таблице возможно наличие только одного ограничения по первичному ключу.
Первичный ключ не может включать больше 16 столбцов, а общая длина ключа не может превышать 900 байт.
Индекс, формируемый ограничением первичного ключа, не может повлечь за собой выход количества индексов в таблице за пределы в 999 некластеризованных индексов и 1 кластеризованный.
Если для ограничения первичного ключа не указано, является ли индекс кластеризованным или некластеризованным, то создается кластеризованный индекс, если таковой отсутствует в таблице.
Все столбцы с ограничением первичного ключа должны быть определены как не допускающие значения NULL. Если допустимость значения NULL не указана, то все столбцы c ограничением первичного ключа устанавливаются как не допускающие значения NULL.
Если первичный ключ определен на столбце определяемого пользователем типа данных CLR, реализация этого типа должна поддерживать двоичную сортировку.

Что особенного в первичном ключе?

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

таблицы (и отношения таблиц) содержат факты об информации вы хотите записать. Эти факты должны быть самодостаточными, осмысленными, легко понятыми и непротиворечивыми. С точки зрения дизайна другие таблицы, добавленные или удаленные из схемы, не должны влиять на рассматриваемую таблицу. Должна быть цель для хранения данных, связанных только с самой информацией. Понимание того, что хранится в таблице, не должны требовать прохождения научно-исследовательского проекта. Ни один факт, хранящийся для одной и той же цели, не должен храниться более одного раза. Ключи вся или часть записываемой информации, которая является уникальной, а первичный ключ-это специально назначенный ключ, который должен быть первичной точкой доступа к таблице (т. е. он должен быть выбран для согласованности и использования данных, а не только для производительности вставки).

в сторону: к сожалению, побочный эффект большинства разрабатываемых баз данных
и разработан программистами приложений (которые я иногда) является
что лучше для приложений или приложений часто
приводы выбор первичного ключа для таблиц. Это приводит к число и
Ключи GUID (поскольку они просты в использовании для фреймворков приложений) и
монолитные конструкции таблиц (по мере того как эти уменьшают число применения
объекты framework, необходимые для представления данных в памяти). Эти
решения по проектированию баз данных, управляемые приложениями, приводят к значительным данным
проблемы согласованности при использовании в масштабе. Каркас приложения
разработанный таким образом, естественно, привести к таблице в то время конструкций.
Создаются «частичные записи» в таблицах и данных, заполненных с течением времени.
Взаимодействие нескольких таблиц избегается или при использовании вызывает несогласованность
данные, когда приложение работает неправильно. Эти конструкции ведут
к данным, которые бессмысленны (или трудно понять), распространение данных
над таблицами (вы должны посмотреть на другие таблицы, чтобы понять
текущая таблица) и дублированные данные.

было сказано, что первичные ключи должны быть как надо. Я бы сказал, что ключи должны быть только такими большими, как необходимый. Следует избегать случайного добавления бессмысленных полей в таблицу. Еще хуже сделать ключ из случайно добавленного бессмысленного поля, особенно когда он уничтожает зависимость соединения от другой таблицы к неосновному ключу. Это разумно только в том случае, если в таблице нет хороших ключей-кандидатов, но это, безусловно, является признаком плохого дизайна схемы при использовании для всех таблиц.

также было сказано, что первичные ключи никогда не должны меняться по мере обновления основного о ключе не может быть и речи. Но update — это то же самое, что delete с последующей вставкой. По этой логике, вы не должны удалять запись из таблицы с одним ключом, а затем добавить другую запись со вторым ключом. Добавление суррогатного первичного ключа не устраняет тот факт, что другой ключ в таблице существует. Обновление непервичного ключа таблицы может уничтожить значение данных, если другие таблицы зависят от этого значения через суррогатный ключ (например, таблица состояния с суррогатный ключ, имеющий описание статуса, измененное с «обработано» на «отменено», определенно повредит данные). Что всегда должно быть вне вопроса уничтожает смысл данных.

SQL CREATE TABLE с PRIMARY KEY CONSTRAINT для большего количества столбцов

В следующем разделе мы обсудим использование SQL PRIMARY KEY CONSTRAINT вместе с оператором CREATE TABLE для двух или более столбцов.

Пример:

В следующем примере создается таблица. Таблица должна содержать ПЕРВИЧНЫЙ КЛЮЧ с комбинацией двух столбцов ‘cust_code’ и ‘cust_city’. Вот имя поля и типы данных:

Имя поля	Тип данных	Размер	НОЛЬ	скованность
cust_code	голец	6	нет	ОСНОВНОЙ КЛЮЧ
CUST_NAME	голец	25	нет
cust_city	голец	25	нет	ОСНОВНОЙ КЛЮЧ
класс	целое число		да
agent_code	голец	6	нет

можно использовать следующий оператор SQL:

Код SQL:

Чтобы увидеть структуру созданной таблицы:

Код SQL:

Выход:

SQL PRIMARY KEY в ALTER TABLE

Чтобы создать ограничение первичного ключа для столбца «ID», когда таблица уже создана, используйте следующий SQL:

MySQL / SQL Server / Oracle / MS Access:

ALTER TABLE Persons
ADD PRIMARY KEY (ID);

Чтобы разрешить именование ограничения первичного ключа и
определить ограничение первичного ключа для нескольких столбцов, используйте следующий синтаксис SQL:

MySQL / SQL Server / Oracle / MS Access:

ALTER TABLE Persons
ADD CONSTRAINT PK_Person PRIMARY KEY (ID,LastName);

Примечание: Если вы используете инструкцию ALTER TABLE для добавления первичного ключа, то столбец(ы) первичного ключа должен(ы) быть
уже объявлено, что они не содержат нулевых значений (при первом создании таблицы).

Типы ограничений в SQL Server

В Microsoft SQL Server реализовано несколько типов ограничений, каждое из которых предназначено для выполнения какой-то конкретной задачи, и сейчас мы с Вами рассмотрим эти типы.

Ограничение NOT NULL

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

С этим ограничением Вы, наверное, уже сталкивалась, и неоднократно работали, так как при создании таблицы, или добавления нового столбца, мы практически всегда указываем возможность принятия столбцом значений NULL, для этого мы пишем NULL или NOT NULL в определении таблицы.

Ограничение PRIMARY KEY

PRIMARY KEY – ограничение первичного ключа. Первичный ключ – это столбец или комбинация столбцов, значения которых гарантируют уникальность каждой строки, что дает нам возможность идентифицировать каждую строку в таблице по данному ключу.

PRIMARY KEY должен быть практически в каждой таблице, и он должен быть у нее один. Обычно первичный ключ создают для столбца, который выполняет роль счетчика (IDENTITY), и он не может содержать значения NULL. Создав ограничение PRIMARY KEY, Вы можете не беспокоиться о том, что в Вашей таблице вдруг окажется две записи с одинаковым идентификатором.

Ограничение FOREIGN KEY

FOREIGN KEY – это ограничение внешнего ключа. Ограничение FOREIGN KEY предназначено для установления связи между данными в таблицах. Иными словами, если в таблице есть ключ (столбец, обычно идентификатор), который есть и в другой таблице, то эти таблицы должны быть связаны с помощью ограничения FOREIGN KEY. Таким образом, с помощью данного ограничения мы выстраиваем связь между таблицами в базе данных.

Ограничение FOREIGN KEY обеспечивает ссылочную целостность, оно позволяет исключить ситуации, когда, например, у Вас в одной таблице есть записи, которые ссылаются на отсутствующие записи в другой таблицы, т.е. этих записей нет, в итоге получаются некорректные данные.

Ограничение UNIQUE

UNIQUE – это ограничение, которое обеспечивает уникальность значений в столбце или комбинации столбцов. UNIQUE позволяет исключить повторяющиеся значения в столбце. В отличие от PRIMARY KEY, для таблицы можно задать несколько ограничений UNIQUE, и столбец, для которого определено данное ограничение, может содержать значение NULL (но, как Вы понимаете, такое значение может быть только одно в этом столбце). В случае если столбцы в таблице были определены без ограничения UNIQUE при создании таблицы, то для того чтобы добавить этого ограничения, в соответствующем столбце не должно быть повторяющихся значений.

Ограничение CHECK

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

К одному столбцу в таблице мы можем применять несколько проверочных ограничений. Создать проверочное ограничение UNIQUE можно с любым логическим выражением, которое возвращает значение TRUE или FALSE.

Ограничение DEFAULT

DEFAULT – это значение по умолчанию. Мы уже говорили о том, что значение NULL — это не очень хорошо, поэтому еще одним способом избавления от данного значения, является возможность задать для столбца значение по умолчанию, которое будет сохранено, если при вводе данных мы не указали никакого значения. Например, если в столбец с ценой товара не указать цену, когда мы будет добавлять новый товар, то SQL сервер автоматически добавит значение по умолчанию, которое мы укажем при определении этого ограничения, к примеру, 0.

4 ответа

Лучший ответ

Подумайте об этом, как подскажите, «КЛЮЧ». Таким образом, ключ будет содержать все указанные столбцы. В вашем случае вы можете иметь несколько строк с тем же «ID» и несколькими строками с тем же «ModelID» , но никогда не должно быть двух строк, которые имеют одинаковый «ID» и «ModelID» .

Итак, в этом случае он не говорит, что идентификатор столбца должен быть уникальным, и он не говорит, что «ModelID» должен быть уникальным, но только комбинация.

18 май 2010, в 05:45
Поделиться

Ваша система не разрешает несколько первичных ключей — она создает ключ на основе двух столбцов

18 май 2010, в 03:28
Поделиться

Вы делаете 1 первичный ключ. Но этот ключ представляет собой комбинацию из двух значений.

Это не так. Но в вашем случае это выглядит неправильно.

У вас, похоже, есть первичный ключ с именем и внешний ключ с именем . Вероятно, вы должны иметь индекс в и ограничение первичного ключа на

18 май 2010, в 04:45
Поделиться

У вас может быть один первичный ключ (поэтому он называется первичным ключом)

Вы можете иметь несколько ключей , если хотите.

18 май 2010, в 03:49
Поделиться

Ещё вопросы

1Персонажи для персонажей PHP
Предварительный просмотр загружен в jquery
1Angular 4+ Создание полукруглого навигационного меню, модульного и глобального CSS
1php Не удалось прослушать 172.0.0.1:8080 (причина: не удается назначить запрошенный адрес)
1Заставить preg_match_all прекратить захват новой строки?
Кнопка загрузки не отвечает на ng-disabled в angularjs
Как найти позицию div, пока он оживляет
2Как я могу запросить дисковые квоты NTFS в C #?
Передайте ‘this’ с помощью обработчика событий bind click в другую функцию
1Как получить элементы заказа из идентификатора заказа? (OpenCart 2.0)
1Поддерживает ли Android API Apache POI
1Как получить поля формы в одном массиве в PHP
Медиа-запросы не будут работать
1ссылка на метод экземпляра. не найдено подходящего метода для
1Интеграция Trigger 2 Spring на другом сервере, но с одной папкой для опроса файлов
1PHP: отображать разделенный запятыми список с помощью <a href=»> тегов привязки
1Symfony: как назначить данные для шаблона в наследующем контроллере?
1ckeditor не может получить доступ к корневому каталогу IE9
окно просмотра iphone перетаскивается вверх и вниз
Как определить идентификатор устройства из SERVICE_CONTROL_DEVICEEVENT
отключить кнопку угловой если $ неверно
Странные медиа-запросы — не применяются
Кнопка «Скрыть / показать изображения» JS
Указатель C ++ на нестатическую функцию-член с использованием шаблонов
1Блокировка воздушного шара в просмотре карты?
1Выйдите из выполнения в пользовательском классе контроллера в CodeIgniter, чтобы остановить рендеринг представлений
1Асинхронная функция JS ждет вечно
Перегрузка оператора распределения
Определение функции распределения
Ширина сайта по HTML-коду
2ASP.NET Core MVC с Identity 2 и EntityFramework 6 (Oracle)
Как обрабатывать соединения AWS-RDS в моем приложении?
Перебор общей коллекции с использованием jquery или javascript
1Нажатие меню не работает на мобильных Chrome и Safari
Используйте AngularJS $ http.get для многократного запроса массива JSON при прокрутке
2Вызов макроса VBA от EPPlus
Временные пути для разработчика мобильных сайтов
Как сериализовать только измененные атрибуты формы в JSON
1Прямая связь между PHP-скриптом и клиентом (Windows или Android)
1Создание растрового изображения вида
1Как получить доступ к файлам из приложения в Android
1Цезиевая ручка просмотра анимации воспроизведения / паузы
Динамически изменить ng-if в пользовательской директиве
3Как найти текст в richtextbox в обратном направлении?
Лучшие практики для хранения онлайн-журнала времени в MySQL
Как я могу выбрать связанные элементы в одной таблице в одном запросе SQL
В JQuery Validation используются разные div для разных элементов ввода для ошибок и несколько классов ошибок
1Чтение ASCII-файла в Python (numpy-array?)
Как остановить отправку формы в обработчике событий?
1Создание объектов со случайными входами

SQL CREATE TABLE с основным ограничением

SQL PRIMARY KEY CONSTRAINT является комбинацией ограничения NOT NULL и ограничения UNIQUE. Это ограничение гарантирует, что конкретный столбец или комбинация из двух или более столбцов для таблицы имеют уникальную идентификацию, которая помогает легче и быстрее найти конкретную запись в таблице.

Пример :

В следующем примере создается таблица. Вот имя поля и типы данных:

Имя поля	Тип данных	Размер	Десятичные знаки	НОЛЬ	скованность
agent_code	голец	6		нет	ОСНОВНОЙ КЛЮЧ
имя агента	голец	40		нет
рабочая область	голец	35		да
комиссия	десятичный	10	2	да
номер телефона	голец	17		да

можно использовать следующий оператор SQL:

Код SQL:

Чтобы увидеть структуру созданной таблицы:

Код SQL:

Выход :

Составной первичный ключ с JPA и гибернацией

Чтобы сопоставить это сопоставление таблиц базы данных, нам нужно сначала изолировать составной ключ в :

@Embeddable
public class EmployeeId implements Serializable {

    @Column(name = "company_id")
    private Long companyId;

    @Column(name = "employee_number")
    private Long employeeNumber;

    public EmployeeId() {
    }

    public EmployeeId(Long companyId, Long employeeId) {
        this.companyId = companyId;
        this.employeeNumber = employeeId;
    }

    public Long getCompanyId() {
        return companyId;
    }

    public Long getEmployeeNumber() {
        return employeeNumber;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof EmployeeId)) return false;
        EmployeeId that = (EmployeeId) o;
        return Objects.equals(getCompanyId(), that.getCompanyId()) &&
                Objects.equals(getEmployeeNumber(), that.getEmployeeNumber());
    }

    @Override
    public int hashCode() {
        return Objects.hash(getCompanyId(), getEmployeeNumber());
    }
}

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

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

Отображение выглядит следующим образом:

@Entity(name = "Employee")
@Table(name = "employee")
public class Employee {

    @EmbeddedId
    private EmployeeId id;

    private String name;

    public EmployeeId getId() {
        return id;
    }

    public void setId(EmployeeId id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

используется для указания гибернации, что сущность использует составной ключ.

Отображение также довольно простое:

@Entity(name = "Phone")
@Table(name = "phone")
public class Phone {

    @Id
    @Column(name = "`number`")
    private String number;

    @ManyToOne
    @JoinColumns({
        @JoinColumn(
            name = "company_id",
            referencedColumnName = "company_id"),
        @JoinColumn(
            name = "employee_number",
            referencedColumnName = "employee_number")
    })
    private Employee employee;

    public Employee getEmployee() {
        return employee;
    }

    public void setEmployee(Employee employee) {
        this.employee = employee;
    }

    public String getNumber() {
        return number;
    }

    public void setNumber(String number) {
        this.number = number;
    }
}

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

Что такое первичный ключ

Столбец первичного ключа в таблице помогает идентифицировать каждую строку или запись в таблице. Содержит уникальные значения. Столбец первичного ключа не может иметь значения Null. Таблица может иметь один первичный ключ. В таблице Student, student_id является первичным ключом. В таблице Patient_Details, Patient_id является первичным ключом. Для первичного ключа необязательно иметь одно поле. Это также может быть комбинация нескольких полей. Когда первичный ключ состоит из нескольких полей, он называется составным ключом. Например, первичный ключ таблицы Student может быть комбинацией student_id и name.

Как правильно создать составные первичные ключи-MYSQL

вот грубое упрощение интенсивной установки, с которой я работаю. table_1 и table_2 оба имеют автоинкрементные суррогатные первичные ключи в качестве идентификатора. info — Это таблица, которая содержит сведения о table_1 и table_2 .

я пытаюсь решить, если я должен сделать первичный ключ info композит идентификаторов из table_1 и table_2 . Если бы я сделал это, какой из них имеет наибольший смысл?( в этом примере я объединение ID 11209 с ID 437)

INT(9) 11209437 (я могу себе представить, почему это плохо) VARCHAR (10) 11209-437 DECIMAL (10,4) 11209.437

было бы хорошо использовать это в качестве первичного ключа на MySQL MYISAM DB?

8 ответов:

Я бы использовал составной (многоколоночный) ключ.

таким образом, вы можете иметь t1id и t2ID в качестве внешних ключей, указывающих на их соответствующие таблицы.

Я бы не сделал первичный ключ таблицы «info» составным из двух значений из других таблиц.

другие могут лучше сформулировать причины, но кажется неправильным иметь столбец, который действительно состоит из двух частей информации. Что, если вы хотите сортировать по ID из второй таблицы по какой-то причине? Что делать, если вы хотите подсчитать количество раз, когда значение из любой таблицы присутствует?

Я бы всегда держал их как два разных столбца. Вы могли бы используйте ключ primay с двумя столбцами в mysql . Первичный ключ(id_a, id_b). но я предпочитаю использовать уникальный индекс с двумя столбцами и иметь поле первичного ключа с автоматическим приращением.

синтаксис CONSTRAINT constraint_name PRIMARY KEY(col1,col2,col3) например:

CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)

приведенный выше пример будет работать, если вы не написали его во время создания таблицы, например:

чтобы добавить это ограничение в существующую таблицу необходимо выполнить следующий синтаксис

составные первичные ключи, что вы хотите, где вы хотите создать связь «многие ко многим» с таблицей фактов. Например, у вас может быть пакет аренды для отдыха, который включает в себя ряд свойств. С другой стороны, недвижимость также может быть доступна как часть ряда пакетов аренды, либо самостоятельно, либо с другими свойствами. В этом случае устанавливается связь между свойством и пакетом аренды с помощью таблицы фактов свойства / пакета. Этот связь между свойством и пакетом будет уникальной, вы только когда-либо присоединитесь с помощью property_id с таблицей свойств и/или package_id с таблицей пакетов. Каждая связь уникальна, и ключ auto_increment является избыточным, поскольку он не будет отображаться ни в одной другой таблице. Следовательно, определение составного ключа является ответом.

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

например, каждый штат США имеет набор уникальных округов конгресса. Хотя многие государства могут индивидуально иметь CD-5, в любом из 50 государств никогда не будет более одного CD-5, и наоборот. Таким образом, создание поля счетчика для Массачусетский CD-5 был бы излишним.

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

поэтому, хотя я не отвечаю на исходный вопрос, я, конечно, ценю прямой ответ Адама.

предположим, что вы уже создали таблицы вы можете использовать этот запрос, чтобы сделать составной первичный ключ

йУРПМШЪПЧБОЙЕ

рЕТЧЙЮОЩК ЛМАЮ Ч ФБВМЙГЕ СЧМСЕФУС ВБЪПЧЩН ХОЙЛБМШОЩН ЙДЕОФЙЖЙЛБФПТПН ДМС ЪБРЙУЕК. ъОБЮЕОЙЕ РЕТЧЙЮОПЗП ЛМАЮБ ЙУРПМШЪХЕФУС ЧЕЪДЕ, ЗДЕ ОХЦОП ХЛБЪБФШ ОБ ЛПОЛТЕФОХА ЪБРЙУШ. оБ ЙУРПМШЪПЧБОЙЙ РЕТЧЙЮОЩИ ЛМАЮЕК ПУОПЧБОБ ПТЗБОЙЪБГЙС УЧСЪЕК НЕЦДХ ФБВМЙГБНЙ ТЕМСГЙПООПК вд. юФПВЩ ПТЗБОЙЪПЧБФШ НЕЦДХ ДЧХНС ФБВМЙГБНЙ УЧСЪШ ФЙРБ «ПДЙО Л ПДОПНХ» ЙМЙ «ПДЙО ЛП НОПЗЙН» Ч ПДОХ ЙЪ УЧСЪЩЧБЕНЩИ ФБВМЙГ ДПВБЧМСАФ РПМЕ (РПМС), УПДЕТЦБЭЕЕ(ЙЕ) ЪОБЮЕОЙЕ РЕТЧЙЮОПЗП ЛМАЮБ ЪБРЙУЙ Ч УЧСЪБООПК ФБВМЙГЕ (ФБЛПЕ РПМЕ ОБЪЩЧБАФ ЧОЕЫОЙН ЛМАЮПН). дМС ПТЗБОЙЪБГЙЙ УЧСЪЙ ФЙРБ «НОПЗЙЕ ЛП НОПЗЙН» УПЪДБАФ ПФДЕМШОХА ФБВМЙГХ (ФБЛ ОБЪЩЧБЕНХА «ФБВМЙГХ УЧСЪЙ» ЙМЙ «ФБВМЙГХ БУУПГЙБГЙЙ»), ЛБЦДБС ЪБРЙУШ ЛПФПТПК УПДЕТЦЙФ РЕТЧЙЮОЩЕ ЛМАЮЙ ДЧХИ УЧСЪБООЩИ ЪБРЙУЕК Ч ТБЪОЩИ ФБВМЙГБИ.