fix(guide): simplify directory structure

guide/russian/computer-science/databases/acid/index.md

@@ -0,0 +1,30 @@
+---
+title: ACID
+localeTitle: ACID
+---
+## ACID
+
+В области информатики ACID (Atomicity, Consistency, Isolation, Durability) представляет собой набор свойств для модификаций базы данных. Они помогают гарантировать действительность транзакции, даже с ошибками или сбоями.
+
+**Транзакция** представляет собой любую последовательность операций с базой данных, которая удовлетворяет свойствам ACID и может рассматриваться как одна логическая операция над данными. Примером может служить перевод средств с одного банковского счета на другой. Это связано с несколькими изменениями, такими как дебетование одной учетной записи и другое кредитование, но считается одной транзакцией.
+
+### валентность
+
+Это означает, что сложная транзакция либо полностью обрабатывается, либо вообще не обрабатывается. Если одна часть транзакции выходит из строя, вся транзакция не завершается, и база данных не изменяется. Таким образом, если произошел сбой, сбой питания или ошибка, база данных не заканчивается в состоянии, когда выполняются только части транзакции.
+
+### консистенция
+
+Это означает, что данные будут согласованными. Любые данные, введенные в базу данных, должны быть действительными и разрешены на основе любых ограничений, которые вы указали. Он гарантирует, что любая транзакция изменяет базу данных из одного действительного состояния в другое действительное состояние.
+
+### изоляция
+
+Это означает, что если две транзакции выполняются одновременно, одна транзакция не может читать данные из транзакции, которая еще не завершена. Каждая транзакция будет видеть базу данных, как если бы транзакции выполнялись последовательно. Если одной транзакции необходимо прочитать данные, которые другая пишет, она должна дождаться завершения другой транзакции. Последствия неполной транзакции не повлияют на другую транзакцию.
+
+### долговечность
+
+Это означает, что после завершения транзакции он останется таким же, даже в случае потери мощности или других ошибок. Он гарантирует, что все изменения записываются на энергонезависимый носитель данных (например, на жесткий диск), и он записывает завершенную транзакцию.
+
+### Дополнительная информация:
+
+*   Статья ACID: [Википедия](https://en.wikipedia.org/wiki/ACID)
+*   Обзор видео: [YouTube](https://www.youtube.com/watch?v=LSB4eceRsw8)

guide/russian/computer-science/databases/column-databases/index.md

@@ -0,0 +1,11 @@
+---
+title: Column Databases
+localeTitle: Базы данных столбцов
+---
+## Базы данных столбцов
+
+Базы данных, ориентированные на столбцы, предназначены для эффективного возврата данных для ограниченного числа столбцов. Он делает это, сохраняя все значения столбца вместе. База данных, ориентированная на столбцы, будет превосходить операции чтения в ограниченном количестве столбцов, однако операция записи будет дорогостоящей по сравнению с базами данных, ориентированными на строки.
+
+#### Дополнительная информация:
+
+Для получения дополнительной информации перейдите на страницу Википедии в [СУБД, ориентированную](https://en.wikipedia.org/wiki/Column-oriented_DBMS) на [столбцы](https://en.wikipedia.org/wiki/Column-oriented_DBMS) .

guide/russian/computer-science/databases/document-store-databases/index.md

@@ -0,0 +1,24 @@
+---
+title: Document Store Databases
+localeTitle: Базы данных в хранилищах документов
+---
+## Базы данных в хранилищах документов
+
+База данных хранилища документов считается еще одним типом базы данных NoSQL, которая очень похожа на базу данных ключевых значений. Запись в хранилище документов представляет собой один структурированный документ, который может отличаться от всех других документов в базе данных. В отличие от реляционной базы данных, в базе данных нет отображения объектов в другую таблицу. Вместо этого мы можем взять весь объект и записать его непосредственно в базу данных хранилища документов.
+
+Например, у нас может быть следующий объект внутри нашего кода.
+
+```json
+{ 
+    "name": "freeCodeCamp", 
+    "job": "contributor" 
+ } 
+```
+
+Весь этот объект может быть записан непосредственно в базу данных хранилища документов без дальнейшего разбора.
+
+#### Дополнительная информация:
+
+[MongoDB](https://www.mongodb.com/document-databases)
+
+[Elasticsearch](https://www.elastic.co/)

guide/russian/computer-science/databases/fault-tolerance/index.md

@@ -0,0 +1,18 @@
+---
+title: Fault Tolerance
+localeTitle: Отказоустойчивость
+---
+## Отказоустойчивость
+
+Отказоустойчивость - это свойство, позволяющее системе продолжать свою предполагаемую операцию, возможно, на более низком уровне, а не полностью отказываться, когда какая-то часть системы выходит из строя.
+
+**База данных** является отказоустойчивой, когда она может получить доступ к вторичному осколку, когда основное недоступно.
+
+Это достигается за счет:
+
+*   Репликация базы данных
+*   Поиск и устранение неисправностей
+
+База данных, которая поддерживает несколько копий всех данных в разных физических узлах, расположенных в независимых физических подсистемах, таких как серверные стойки и сетевые маршрутизаторы, имеет более высокую вероятность продолжения работы, когда первичная копия данных недоступна из-за ее способности читать данные из нескольких повторений.
+
+В крупномасштабных системах распределения становится все более важным иметь надежные системы обнаружения сбоев, которые могут идентифицировать отказоустойчивые накопители и предоставлять отказоустойчивые блоки, чтобы максимизировать время безотказной работы.

guide/russian/computer-science/databases/graph-databases/index.md

@@ -0,0 +1,11 @@
+---
+title: Graph Databases
+localeTitle: Графические базы данных
+---
+## Графические базы данных
+
+База данных графов представляет собой базу данных, которая использует структуры графов для семантических запросов с узлами, ребрами и свойствами для представления и хранения данных. Ключевой концепцией системы является график (или край или связь), который непосредственно связывает элементы данных в хранилище. Эти отношения позволяют напрямую связывать данные в хранилище и во многих случаях извлекать одну операцию.
+
+#### Дополнительная информация:
+
+*   [Графические базы данных](https://en.wikipedia.org/wiki/Graph_database)

guide/russian/computer-science/databases/index.md

@@ -0,0 +1,11 @@
+---
+title: Databases
+localeTitle: Базы данных
+---
+## Базы данных
+
+Это заглушка. [Помогите нашему сообществу расширить его](https://github.com/freecodecamp/guides/tree/master/src/pages/computer-science/databases/index.md) .
+
+[Это руководство по быстрому стилю поможет вам принять ваш запрос на тягу](https://github.com/freecodecamp/guides/blob/master/README.md) .
+
+#### Дополнительная информация:

guide/russian/computer-science/databases/indexes/index.md

@@ -0,0 +1,21 @@
+---
+title: Indexes
+localeTitle: Индексы
+---
+## Индексы
+
+**Индекс базы данных** - это структура данных, которая повышает эффективность извлечения данных в таблице базы данных. Таблица базы данных может иметь более одного индекса и индекс может быть создан в одном или нескольких столбцах таблицы базы данных.
+
+### Как работают индексы?
+
+Теперь представьте, что вы находитесь в библиотеке, где книги не расположены в заранее определенном порядке. Если вам было поручено найти книгу, вам нужно пройти полку по полке, чтобы найти ее. Это может быть хорошо, когда есть только несколько полки книг, но процесс занимает много времени, если это многоэтажная библиотека.
+
+С другой стороны, предположим, что книги теперь упорядочены по фамилии автора. Учитывая, что вы знаете фамилию автора для книги, которую ищете, например «Carnegie», вы можете искать полки для «C», а затем искать в пределах определенной полки. Вы спасли себя от прохождения каждой отдельной полки.
+
+### Компромисс
+
+Как описано выше, **индекс** представляет собой структуру данных, поэтому он занимает пространство для хранения. Чем больше индексов определено, тем больше места для хранения используется для поддержания структуры данных. Другая стоимость предоставляется в виде дополнительных обновлений (или записей), чтобы обновлять индексы. Когда новые записи добавляются в таблицу с индексом, для обновления структуры данных индекса требуется дополнительная запись.
+
+#### Дополнительная информация:
+
+[Индекс базы данных](https://en.wikipedia.org/wiki/Database_index)

guide/russian/computer-science/databases/key-value-databases/index.md

@@ -0,0 +1,54 @@
+---
+title: Key Value Databases
+localeTitle: Базы данных ключевых значений
+---
+## Базы данных ключевых значений
+
+База данных с ключом или хранилище ключей - это тип базы данных [NoSQL, в](https://en.wikipedia.org/wiki/NoSQL) которой используется хранилище ключей / значений. Это означает, что данные, хранящиеся в базе данных, представляют собой набор пар ключ-значение.
+
+Такая структура данных используется на многих языках программирования. Пары ключевых значений обычно называются ассоциативными массивами, словарями или хэшем. Например, рассмотрите словарь телефонных номеров:
+
+| ключ | стоимость | | ------------ | ------------- | | Рик | 1234555 | | Морти | 7754321 | | Лето | 5512377 |
+
+### Ключ
+
+`key` в паре ключ-значение должен быть уникальным. Наличие уникального идентификатора позволит вам получить доступ к значению, связанному с данным ключом.
+
+Теоретически ключ может быть любым, что вы хотите. Ключ может быть строкой, двоичной последовательностью, изображением и другими. Однако некоторые базы данных могут налагать ограничения на тип ключей, которые можно использовать.
+
+Вот несколько рекомендаций:
+
+*   Ключи должны следовать конвенции, чтобы иметь согласованность. Ключи в словаре телефонных номеров всегда должны быть именами, а не комбинацией имен, адресов электронной почты и номеров.
+*   Ключи не должны быть слишком длинными, или у вас могут быть проблемы с производительностью.
+*   Ключи не должны быть слишком короткими, или у вас могут быть проблемы с читабельностью.
+
+### Значение
+
+`value` в хранилище значений ключей может быть любым, что вы хотите. Сюда входят строки, цифры, код, изображение, список или даже другая пара ключей. Некоторые базы данных позволяют ограничить тип данных, которые можно сохранить.
+
+### Случаи применения
+
+Базы данных с ключом можно использовать для нескольких сценариев. Вот список наиболее распространенных приложений:
+
+*   Телекоммуникационные каталоги.
+*   Профили пользователей и информация о сеансе.
+*   Содержимое корзины.
+*   Сведения о продукте или отзывы.
+*   Таблицы пересылки Интернет-протокола (IP).
+*   Состояние или конфигурация службы.
+
+### Примеры
+
+Вот несколько примеров баз данных, в которых используется подход «ключ-значение»:
+
+*   [Redis](https://redis.io)
+*   [База данных Oracle NoSQL](https://www.oracle.com/database/nosql/index.html)
+*   [Cassandra](http://cassandra.apache.org) (гибрид между ключевыми и ориентированными на столбцы базами данных)
+*   [Волдеморт](http://www.project-voldemort.com/voldemort/)
+*   [Consul KV store](https://www.consul.io/intro/getting-started/kv.html) (инструмент с собственным хранилищем ключей)
+
+#### Дополнительная информация:
+
+*   Базы данных по ключевым словам в [Википедии](https://en.wikipedia.org/wiki/Key-value_database)
+
+База данных Key-Value - простая база данных, которая использует карту или словарь в качестве базовой модели данных, где каждый ключ связан с одним и только одним значением в коллекции и является наиболее гибким типом базы данных NoSQL.

guide/russian/computer-science/databases/non-relational-databases/index.md

@@ -0,0 +1,28 @@
+---
+title: Non-Relational-Databases
+localeTitle: Нереляционную-Базы данных
+---
+## Когда использовать
+
+Если вы имеете дело с феноменально огромным количеством данных, это может быть слишком утомительным, и вероятность ошибки (в виде ошибки несоответствия ОРМ) возрастает. В этой ситуации вам может потребоваться рассмотреть возможность использования нереляционной базы данных. Нереляционная база данных просто хранит данные без явных и структурированных механизмов для связывания данных из разных таблиц (или кодов) друг с другом. Если ваша модель данных оказывается очень сложной, или если вам приходится де-нормализовать схему базы данных, то не реляционные базы данных могут быть лучшим способом.
+
+Другие причины выбора нереляционной базы данных:
+
+*   Необходимость хранить сериализованные массивы в объектах JSON
+*   Хранение записей в той же коллекции, которая имеет разные поля или атрибуты
+*   Нахождение себя в нормализации вашей схемы или кодирования базы данных по проблемам производительности и горизонтальной масштабируемости
+*   Проблемы легко предопределяют вашу схему из-за характера вашей модели данных
+
+## Недостатки
+
+В нереляционных базах данных не существует объединений, как в реляционных базах данных. Это означает, что вам необходимо выполнить несколько запросов и вручную объединить данные в свой код, и это может стать очень уродливым, очень быстрым.
+
+## Примеры баз данных
+
+*   MongoDB
+*   NoSQL
+
+## Рекомендации
+
+*   (Https://www.pluralsight.com/blog/software-development/relational-non-relational-databases)
+*   (Https://en.wikipedia.org/wiki/NoSQL)

guide/russian/computer-science/databases/normal-form/index.md

@@ -0,0 +1,68 @@
+---
+title: Normal Form
+localeTitle: Нормальная форма
+---
+## Нормальная форма
+
+Нормализация была впервые введена как часть реляционной модели. Это процесс организации таблиц данных и столбцов таким образом, который уменьшает избыточность и повышает целостность. Это можно сделать через:
+
+*   Синтез: создает нормализованный дизайн базы данных на основе известного набора зависимостей.
+*   декомпозиция: принимает существующий (недостаточно нормированный) проект базы данных и улучшает его на основе известного набора зависимостей
+
+Существуют три обычные нормальные формы (1-й, 2-й и 3-й) плюс довольно продвинутая форма, называемая BCNF. Они прогрессивные: в orther, чтобы претендовать на 3-ей нормальную форму, схема базы данных должна удовлетворять правилам 2-й нормальной формы и т. Д. Для 1-й нормальной формы.
+
+*   **1-я нормальная форма** : информация хранится в таблице, каждый столбец содержит атомные значения, и не повторяются группы столбцов. Это :
+
+1.  Устраняет повторяющиеся группы в отдельных таблицах.
+2.  Создает отдельную таблицу для каждого набора связанных данных.
+3.  Определяет каждый набор связанных данных с помощью первичного ключа
+
+##### пример
+
+Конструкция, которая нарушает 1-ю нормальную форму, столбец «телефон» не содержит атомных значений
+
+| идентификатор клиента | Имя Фамилия | Телефон | | ------------- | ------------ | ----------- | ---------- ---------------------------- | | 123 | Pooja | Сингх | 555-861-2025, 192-122-1111 | | 789 | Джон | Доу | 555-808-9633 | | 456 | Сан | Чжан | (555) 403-1659 Ext. 53; 182-929-2929 |
+
+Одним из решений было бы иметь дополнительный столбец для каждого номера телефона. Но тогда это будет повторять концептуально тот же атрибут (номер телефона). Более того, добавление дополнительного номера телефона потребует реорганизации таблицы, добавив больше столбца. Это определенно не практично.
+
+Другим решением является наличие отдельной таблицы для клиента ассоциации <-> Телефон: это соответствует 1-й нормальной форме, и по мере необходимости может быть столько строк на одного клиента.
+
+| идентификатор клиента | Имя Фамилия | | ------------- | ------------ | ----------- | | 123 | Pooja | Сингх | | 789 | Джон | Доу | | 456 | Сан | Чжан |
+
+| идентификатор клиента | Телефон | | ------------- | ------------------------ | | 123 | 555-861-2025 | | 123 | 192-122-1111 | | 789 | 555-808-9633 | | 456 | (555) 403-1659 Ext. 53 | | 456 | 182-929-2929 |
+
+*   **2-я нормальная форма** : таблица находится в первой нормальной форме, и все неявные столбцы зависят от первичного ключа таблицы. Это сужает цель таблицы.
+
+##### пример
+
+Дизайн, который нарушает 2-ю нормальную форму. Полное имя модели является первичным ключом, есть другие ключи-кандидаты, такие как {производитель, модель}. Столбец «Страна-производитель» зависит от столбца без ключа (Производитель).
+
+| Производитель | Модель | Полное имя модели | Страна производителя | | --------------------- | -------------- | ------------ ---------- | ---------------------- | | Форте | X-Prime | Forte X-Prime | Италия | | Форте | Ультрачеловек | Forte Ultracan | Италия | | Dent-o-Fresh | EZbrush | Dent-o-Fresh EZbrush | США | | Кобаяси | ST-60 | Кобаяши ST-60 | Япония | | Хох | Зубная мастерская | Hoch Toothmaster | Германия | | Хох | X-Prime | Hoch X-Prime | Германия |
+
+Нормализованный дизайн должен состоять в том, чтобы разбить на две таблицы:
+
+| Производитель | Страна производителя | | --------------------- | ---------------------- | | Форте | Италия | | Dent-o-Fresh | США | | Кобаяси | Япония | | Хох | Германия |
+
+| Производитель | Модель | Полное имя модели | | --------------------- | -------------- | ------------ ---------- | | Форте | X-Prime | Forte X-Prime | | Форте | Ультрачеловек | Forte Ultracan | | Dent-o-Fresh | EZbrush | Dent-o-Fresh EZbrush | | Кобаяси | ST-60 | Кобаяши ST-60 | | Хох | Зубная мастерская | Hoch Toothmaster | | Хох | X-Prime | Hoch X-Prime |
+
+*   **3-я нормальная форма** : таблица находится во второй нормальной форме, и все ее столбцы транзитивно не зависят от первичного ключа. Говорят, что столбец зависит от другого столбца, если он может быть получен из него, например, возраст может быть получен из дня рождения. Транзитивность означает, что эта зависимость может включать другие столбцы. например, если мы рассмотрим три столбца `PersonID BodyMassIndex IsOverweight` , столбец «IsOverweight» транзитивно зависит от «personID» через «BodyMassIndex».
+
+##### пример
+
+Дизайн, который нарушает 3-ей нормальную форму. {Турнир, год} является первичным ключом для таблицы, и из-за этого транзитно зависит столбец «Дата рождения победителя».
+
+| Турнир | Год | Победитель | Победитель Дата рождения | | ---------------------- | ------------- | ------------ ---- | ---------------------- | | Индиана Invitational | 1998 | Аль Фредриксон | 21 июля 1975 года | | Кливленд Open | 1999 | Боб Альберсон | 28 сентября 1968 года | | Де-Мойн Мастерс | 1999 | Аль Фредриксон | 21 июля 1975 года | | Индиана Invitational | 1999 | Чип Мастерсон | 14 марта 1977 |
+
+Дизайн, соответствующий 3-й нормальной форме, будет:
+
+| Турнир | Год | Победитель |  
+| ---------------------- | ------------- | ------------ ---- | | Индиана Invitational | 1998 | Аль Фредриксон | | Кливленд Open | 1999 | Боб Альберсон | | Де-Мойн Мастерс | 1999 | Аль Фредриксон | | Индиана Invitational | 1999 | Чип Мастерсон |
+
+| Победитель | Дата рождения | | ---------------- | ------------------- | | Чип Мастерсон | 14 марта 1977 | | Аль Фредриксон | 21 июля 1975 года | | Боб Альберсон | 28 сентября 1968 года |
+
+#### Дополнительная информация:
+
+*   нормализация базы данных по [википедии](https://en.wikipedia.org/wiki/Database_normalization)
+*   первая нормальная форма на [википедии](https://en.wikipedia.org/wiki/First_normal_form)
+*   вторая нормальная форма на [википедии](https://en.wikipedia.org/wiki/Second_normal_form)
+*   третья нормальная форма в [википедии](https://en.wikipedia.org/wiki/Third_normal_form)

guide/russian/computer-science/databases/relational-databases/index.md

@@ -0,0 +1,51 @@
+---
+title: Relational Databases
+localeTitle: Реляционные базы данных
+---
+Поскольку база данных является способом хранения данных, реляционные базы данных являются моделью для хранения данных. Данные организованы в таблицы, также известные как отношения. Таблицы содержат запись для каждого экземпляра данных, известную как записи или кортежи. Уникальные идентификаторы идентифицируют каждую запись, чтобы описать ее через базу данных.
+
+## таблицы
+
+Как лист в excel, таблицы состоят из столбцов и строк. Каждая строка представляет собой экземпляр данных с атрибутами в столбце таблицы, которые известны как поля. Для каждой категории для нескольких объектов может быть несколько таблиц. Примером может служить таблица пользователей. Каждая строка будет пользователем, и каждое поле будет содержать сведения о пользователе, такие как адрес электронной почты, пароль и контактные данные для этого конкретного пользователя. На рисунке 1 вы можете увидеть схему примера.
+
+| | пользователь | электронная почта | Телефон | | ------------- | ------------ | ------------------ | --- ----------------------------------- | | строка 1 | Джерри | j@j.uk.za | 771447444121 | | строка 2 | Салли | batgirl@gh.co.za | 771447444121 | | ряд 3 | Алекс | samwis@tty.fe | 771447444121 | | ряд 4 | Дуг | 4sure@dam.us | 745151515152 |
+
+Рисунок 1 - Пример таблицы пользователя.
+
+## документация
+
+Запись - это единый объект данных. Как и в приведенном выше примере, это могут быть пользователь, учетная запись, устройство или все, что могут представлять данные. Записи нуждаются в уникальном идентификаторе, иногда называемом ключом. Этот ключ должен быть уникальным, поскольку он используется для описания отношений, которые запись имеет с другими записями в других таблицах. На рисунке 1 мы могли бы добавлять ключи к каждой строке, которая идентифицирует каждого пользователя с помощью ключа, а таблица теперь будет выглядеть как на рисунке 2.
+
+| КЛЮЧ | пользователь | электронная почта | Телефон | | ----------- | ------------ | ------------------ | ----- --------------------------------- | | u1 | Джерри | j@j.uk.za | 771447444121 | | u2 | Салли | batgirl@gh.co.za | 771447444121 | | u3 | Алекс | samwis@tty.fe | 771447444121 | | u4 | Дуг | 4sure@dam.us | 745151515152 |
+
+Рисунок 2 - Пример пользовательской базы данных с полем KEY.
+
+## поля
+
+Поля описывают запись. Это может содержать любую информацию о сущности, которая символизирует запись. На рисунке 3 вы можете увидеть таблицу, в которой показаны домашние животные. Столбцы (поля) описывают каждое домашнее животное (запись) с p\_name, p\_age, p\_type и p\_owner. P является сокращением для домашнего животного, и последний столбец будет объяснен в следующем разделе о взаимоотношениях.
+
+| КЛЮЧ | p\_name | p\_age | p\_owner | | ----------- | ------------ | ------------------ | ----- ---------- | | p1 | Сьюзи | j@j.uk.za | u1 | | p2 | Маленький Dip | batgirl@gh.co.za | u1 | | p3 | Amillë | samwis@tty.fe | u2 | | p4 | Дуг | 4sure@dam.us | u3 |
+
+Рисунок 3 - Пример стола для домашних животных.
+
+## Отношения
+
+Реляционные базы данных позволяют описывать отношения, которые имеют отношения друг с другом. Иногда это самая сложная тема для реляционных баз данных. Если мы возьмем наши таблицы примеров, мы сможем увидеть взаимосвязь нашей таблицы пользователей с таблицей домашних животных. Если вы читаете поле p\_owner, вы можете видеть, что оно также может быть таким же, как на рисунке 4. Это объясняет отношение, которое каждое домашнее животное имеет с пользователем. Отношения могут иметь разные типы.
+
+| КЛЮЧ | p\_name | p\_age | p\_owner | | ----------- | ------------ | ------------------ | ----- ---------- | | p1 | Сьюзи | j@j.uk.za | Джерри | | p2 | Маленький Dip | batgirl@gh.co.za | Джерри | | p3 | Amillë | samwis@tty.fe | Салли | | p4 | Дуг | 4sure@dam.us | Дуг |
+
+Рисунок 4 - Пример таблицы Pet с подключенным полем владельца.
+
+Отношение «один ко многим» - это одна запись, связанная со многими другими записями, примером которой является пользователь Джерри с двумя домашними животными. Это также может быть отношение «многие ко многим», где таблицы могут быть книгами и авторами, поскольку авторы могли бы написать много книг. Наконец, наиболее распространенный тип отношений - это один к одному, запись, которая может быть связана только с одной и только с одной, другой записью.
+
+## Вывод
+
+Это всего лишь краткое введение в реляционные базы данных. Ниже приведены ссылки на ресурсы, которые могут помочь вам продолжить изучение предмета.
+
+#### Дополнительная информация:
+
+*   Реляционные базы данных по [википедии](https://en.wikipedia.org/wiki/Relational_database)
+*   Один-ко-многим в [Википедии](https://en.wikipedia.org/wiki/One-to-many_(data_model) )
+*   Многие-ко-многим в [Википедии](https://en.wikipedia.org/wiki/Many-to-many_(data_model) )
+*   Один-к-одному в [Википедии](https://en.wikipedia.org/wiki/One-to-one_(data_model) )
+*   Модель отношения к [википедии](https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model)