Таблицы бд структуры данных способы создания таблиц

Создание таблиц БД является первым шагом в разработке СУБД. Таблицы предназначены для хранения информации БД. Создание таблицы состоит из двух этапов: задание структуры таблицы; ввод записей в таблицу.

Для создания новой таблицы следует в окне БД выбрать меню «Таблицы» (в старых версиях Access для этой цели служит вкладка «Таблицы» ) и нажать кнопку «Создать» . В окне «Новая таблица» необходимо выбрать способ создания таблицы.

Если у разработчика СУБД нет достаточного опыта, рекомендуется для создания таблицы выбрать режим конструктора.

Создание таблицы в режиме конструктора

При выборе режима конструктора появляется окно конструктора.

В поле «Имя поля» вводится имя поля таблицы, являющееся его идентификатором. Рекомендуется формировать имена полей так, чтобы имя было коротким, не содержащим специальных символов (запятых, пробелов и т.д.) и отражающим смысл поля. Необходимо различать идентификатор поля в структуре таблицы и заголовок поля в выходном документе. Во втором случае заголовок поля должен в полной мере отражать смысл поля и обычно задается вручную при форматировании выходного документа.

В поле «Тип данных» выбирается один из типов, показанных в раскрытом списке на рисунке.

Поле «Описание» содержит комментарии к создаваемому полю таблицы. Его заполнение не является обязательным.

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

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

На приведенном выше рисунке описана таблица «Группа» , состоящая из трех полей с идентификаторами НГ , КОЛ и ПБАЛЛ . Поле НГ является текстовым и содержит номера студенческих групп. Основное свойство этого поля — длина, не превышающая 6 символов. Поле КОЛ содержит количество студентов в группе и является числовым (целым). Поле ПБАЛЛ содержит средний балл, полученный студентами группы при поступлении в учебное заведение, является числовым, но в отличие от поля КОЛ — действительным, содержащим десятичную часть.

Важным действием на этапе разработки структуры таблицы является задание ключевых полей. Для задания простого ключа, состоящего из одного поля таблицы, достаточно в режиме конструктора установить курсор в любую позицию этого поля и нажать кнопку «Ключевое поле» на панели инструментов. На рисунке это поле НГ . Для задания составного ключа, состоящего из нескольких полей таблицы, необходимо выделить эти поля, щелкая мышью по кнопкам слева от соответствующих строк при нажатой клавише Ctrl, а затем нажать кнопку «Ключевое поле» . Признаком установки является появление рисунка ключа на кнопках слева от соответствующей строки конструктора.

Имя таблицы запрашивается при закрытии окна конструктора. После закрытия конструктора в окне БД появляется значок и имя созданной таблицы. Если выделить значок таблицы и щелкнуть по кнопке «Открыть» , то таблица будет открыта для ввода записей.

Создание таблицы путем ввода данных

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

Любое поле в этой таблице можно изменить по желанию пользователя. Имена полей задаются непосредственно в заголовках. При сохранении этой таблицы Access проанализирует данные и автоматически присвоит соответствующий тип данных каждому полю, т.е. создаст структуру таблицы. При закрытии режима таблицы Access предложит создать ключевое поле. Если ответить «Да», то будет добавлено еще одно поле типа «Счетчик» , которое и будет ключевым. Если ответить «Нет», то ключ можно задать позже, перейдя в режим конструктора.

Создание таблицы при помощи Мастера

Мастер таблиц автоматически создает таблицу по одному из шаблонов, предлагаемых в окне «Создание таблиц» :

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

Ввод данных в таблицу

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

Вводимые данные должны соответствовать типу данных и формату, определенным в структуре для каждого поля таблицы. При несоответствии Access выдает предупреждение и не разрешает продолжать ввод. Следует либо ввести данные требуемого формата, либо отменить ввод.

Источник

Информационные технологии. 10 класс (Базовый уровень)

§ 2. Работа с таблицами базы данных

2.1. Создание таблиц базы данных

Таблица — основной объект базы данных, предназначенный для хранения данных в структурированном виде.

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

На основе таблиц создаются другие объекты базы данных.

В процессе создания таблиц можно выделить этапы:

1. Создание объекта Таблица (пример 2.1).

2. Описание структуры таблицы — имен полей, типов и свойств данных в них.

3. Ввод данных в таблицу.

Работать с таблицами баз данных можно в двух режимах (пример 2.2).

Описание структуры таблицы (пример 2.3) выполняется в режиме Конструктор (см. Приложение к главе 1).

Данные в таблицу вводятся в режиме Таблица. В этом режиме можно также просматривать и изменять структуру таблицы.

Таблицы в реляционных базах данных должны обладать следующими свойствами:

1. В таблице не может быть двух записей с полностью совпадающими данными.

2. Поля таблицы должны располагаться в порядке, который определяется при ее создании.

3. В таблице обязательно должно быть хотя бы одно поле.

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

Таблица базы данных похожа на электронную таблицу, и в Access реализована возможность импортировать данные из электронных таблиц в БД (пример 2.4).

Пример 2.1. Создание объекта Таблица в Access.

Пример 2.2. Режимы работы с таблицами в Access.

Пример 2.3. Описание структуры таблицы.

Пример 2.4. Импорт таблицы из Excel в Access.

1. На вкладке Внешние данные выбрать Excel:

2. В окне Внешние данные нажать кнопку .

3. В окне Открытие файла выбрать файл с электронной таблицей и подтвердить выбор.

4. В окне Импорт электронной таблицы на каждом шаге сделать требуемый выбор и нажать кнопку Далее.

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

По завершении нажать кнопку

Источник

Таблицы бд структуры данных способы создания таблиц

1. Режим таблицы — позволяет создать новую таблицу в режиме таблицы;

Первоначально представляется таблица с полями, куда необходимо ввести данные. Эта таблица содержит, как правило, 20 столбцов и 30 строк, и этого вполне достаточно для начала. После сохранения Access сам решает, какой тип данных присвоить каждому из полей.

Видео YouTube

2. Конструктор — позволяет создать новую таблицу в конструкторе таблиц;

Создание таблиц в окне конструктора предоставляет более широкие возможности по определению параметров создаваемой таблицы. После выбора этой операции открывается конструктор таблиц следующего вида.

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

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

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

В нижней области окна конструктора таблиц отображаются дополнительные характеристики каждого столбца, выделенного в верхней области (свойства полей).

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

Размер – для числа: 1 байт (0..255), с плавающей точкой 8 байт (от -10308..до 10308)

Формат поля – для задания формата отображения значения

Маска ввода – задание отображения постоянных символов в поле (для текста и даты)

Условие на значение – ограничение на значение вводимых данных ( 50)

Индексированное: Да (совпадения не допускаются) – первичный ключ, Да (совпадения допускаются) – вторичный ключ, Нет (неиндексированное поле)

Видео YouTube

3. Мастер таблиц — позволяет создать новую таблицу с помощью мастера;

MS Access содержит целый ряд таблиц, которые вы можете использовать в качестве прототипов требуемых Вам таблиц. При использовании мастера Вы можете не только сэкономить время на создании таблиц, но и обеспечить стандартные имена и типы данных полей таблиц.

Из набора таблиц можно выбрать нужную, которая будет создана в БД пользователя.

Видео YouTube

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

Источник

Руководство по разработке структуры и проектированию базы данных

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

Этапы создания базы данных

Надлежащим образом структурированная база данных:

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

Основные этапы разработки базы данных:

Анализ требований или определение цели базы данных;
Организация данных в таблицах;
Указание первичных ключей и анализ связей;
Нормализация таблиц.

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

Анализ требований: определение цели базы данных

Например, если вы создаете базу данных для публичной библиотеки, нужно продумать, каким образом и читатели, и библиотекари должны получать доступ к БД .

Вот несколько способов сбора информации перед созданием базы данных:

Опрос людей, которые будут ее использовать;
Анализ бизнес-форм, таких как счета-фактуры, расписания, опросы;
Рассмотрение всех существующих систем данных ( включая физические и цифровые файлы ).

Начните со сбора существующих данных, которые будут включены в базу. Затем определите типы данных, которые нужно сохранить. А также объекты, которые описывают эти данные. Например:

Имя;
Адрес;
Город, штат, почтовый индекс;
Адрес электронной почты.

Название;
Цена;
Количество в наличии;
Количество под заказ.

Номер заказа;
Торговый представитель;
Дата;
Товар;
Количество;
Цена;
Стоимость.

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

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

Структура базы данных: построение блоков

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

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

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

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

CHAR — конкретная длина текста;
VARCHAR — текст различной длины;
TEXT — большой объем текста;
INT — положительное или отрицательное целое число;
FLOAT , DOUBLE — числа с плавающей запятой;
BLOB — двоичные данные.

Некоторые СУБД также предлагают тип данных Autonumber , который автоматически генерирует уникальный номер в каждой строке.

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

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

Атрибуты, выбранные в качестве первичных ключей, должны быть уникальными, неизменяемыми и для них не может быть задано значение NULL ( они не могут быть пустыми ). По этой причине номера заказов и имена пользователей являются подходящими первичными ключами, а номера телефонов или адреса — нет. Также можно использовать в качестве первичного ключа несколько полей одновременно ( это называется составным ключом ).

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

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

Создание связей между сущностями

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

Каждый объект может быть взаимосвязан с другим с помощью одного из трех типов связи:

Связь «один-к одному»

Когда существует только один экземпляр объекта A для каждого экземпляра объекта B, говорят, что между ними существует связь « один-к одному » ( часто обозначается 1:1 ). Можно указать этот тип связи в ER-диаграмме линией с тире на каждом конце:

Если при проектировании и разработке баз данных у вас нет оснований разделять эти данные, связь 1:1 обычно указывает на то, что в лучше объединить эти таблицы в одну.

Но при определенных обстоятельствах целесообразнее создавать таблицы со связями 1:1 . Если есть поле с необязательными данными, например «описание», которое не заполнено для многих записей, можно переместить все описания в отдельную таблицу, исключая пустые поля и улучшая производительность базы данных.

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

Связь «один-ко-многим»

Эта связи возникают, когда запись в одной таблице связана с несколькими записями в другой. Например, один клиент мог разместить много заказов, или у читателя может быть сразу несколько книг, взятых в библиотеке. Связи « один- ко-многим » ( 1:M ) обозначаются так называемой «меткой ноги вороны», как в этом примере:

Чтобы реализовать связь 1:M , добавьте первичный ключ из « одной » таблицы в качестве атрибута в другую таблицу. Если первичный ключ таким образом указан в другой таблице, он называется внешним ключом. Таблица со стороны связи « 1 » представляет собой родительскую таблицу для дочерней таблицы на другой стороне.

Связь «многие-ко-многим»

Когда несколько объектов таблицы могут быть связаны с несколькими объектами другой. Говорят, что они имеют связь « многие-ко-многим » ( M:N ). Например, в случае студентов и курсов, поскольку студент может посещать много курсов, и каждый курс могут посещать много студентов.

На ER-диаграмме эти связи отображаются с помощью следующих строк:

При проектировании структуры базы данных реализовать такого рода связи невозможно. Вместо этого нужно разбить их на две связи « один-ко-многим ».

Для этого нужно создать между этими двумя таблицами новую сущность. Если между продажами и продуктами существует связь M:N , можно назвать этот новый объект « sold_products », так как он будет содержать данные для каждой продажи. И таблица продаж, и таблица товаров будут иметь связь 1:M с sold_products . Этот вид промежуточного объекта в различных моделях называется таблицей ссылок, ассоциативным объектом или таблицей связей.

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

Обязательно или нет?

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

Два объекта могут быть взаимозависимыми ( один не может существовать без другого ).

Рекурсивные связи

Иногда при проектировании базы данных таблица указывает на себя саму. Например, таблица сотрудников может иметь атрибут «руководитель», который ссылается на другое лицо в этой же таблице. Это называется рекурсивными связями.

Лишние связи

Лишние связи — это те, которые выражены более одного раза. Как правило, можно удалить одну из таких связей без потери какой-либо важной информации. Например, если объект « ученики » имеет прямую связь с другим объектом, называемым « учителя », но также имеет косвенные отношения с учителями через « предметы », нужно удалить связь между « учениками » и « учителями ». Так как единственный способ, которым ученикам назначают учителей — это предметы.

Нормализация базы данных

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

В то же время не все базы данных необходимо нормализовать. В целом, базы с обработкой транзакций в реальном времени ( OLTP ), должны быть нормализованы.

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

Первая форма нормализации

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

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

Вместо этого во время физического проектирования базы данных разделите данные на несколько таблиц или записей, пока каждая ячейка не будет содержать только одно значение, и дополнительных столбцов не будет. Такие данные считаются разбитыми до наименьшего полезного размера. В приведенной выше таблице можно создать дополнительную таблицу « Реквизиты продаж », которая будет соответствовать конкретным продуктам с продажами. « Продажи » будут иметь связь 1:M с « Реквизитами продаж ».

Вторая форма нормализации

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

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

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

Таким образом, таблица с этими полями не будет соответствовать второй форме нормализации, поскольку атрибут « название товара » зависит от идентификатора продукта, но не от номера заказа:

Номер заказа ( первичный ключ );
ID товара ( первичный ключ );
Название товара.

Третья форма нормализации

Третья форма нормализации ( 3NF ) : каждый не ключевой столбец должен быть независим от любого другого столбца. Если при проектировании реляционной базы данных изменение значения в одном не ключевом столбце вызывает изменение другого значения, эта таблица не соответствует третьей форме нормализации.

В соответствии с 3NF , нельзя хранить в таблице любые производные данные, такие как столбец « Налог », который в приведенном ниже примере, напрямую зависит от общей стоимости заказа:

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

Многомерные данные

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

Правила целостности данных

Также с помощью средств проектирования баз данных необходимо настроить БД с учетом возможности проверки данных на соответствие определенным правилам. Многие СУБД , такие как Microsoft Access , автоматически применяют некоторые из этих правил.

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

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

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

Добавление индексов и представлений

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

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

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

Расширенные свойства

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

SQL и UML

Унифицированный язык моделирования ( UML ) — это еще один визуальный способ выражения сложных систем, созданных на объектно-ориентированном языке. Некоторые из концепций, упомянутых в этом руководстве, известны в UML под разными названиями. Например, объект в UML известен, как класс.

Сейчас UML используется не так часто. В наши дни он применяется академически и в общении между разработчиками программного обеспечения и их клиентами.

Системы управления базами данных

Проектируемая структура базы данных зависит от того, какую СУБД вы используете. Некоторые из наиболее распространенных:

Oracle DB ;
MySQL ;
Microsoft SQL Server ;
PostgreSQL ;
IBM DB2 .

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

Пожалуйста, опубликуйте свои мнения по текущей теме материала. За комментарии, дизлайки, подписки, лайки, отклики низкий вам поклон!

Пожалуйста, оставляйте свои мнения по текущей теме материала. За комментарии, подписки, отклики, лайки, дизлайки низкий вам поклон!

Источник