Что такое реляционная база данных

Обзор

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

Основная цель объектно-реляционной базы данных — преодолеть разрыв между реляционными базами данных и методами объектно-ориентированного моделирования, используемыми в таких языках программирования, как Java , C ++ , Visual Basic .NET или C # . Однако более популярной альтернативой для достижения такого моста является использование стандартных систем реляционных баз данных с некоторой формой программного обеспечения объектно-реляционного сопоставления (ORM). В то время как традиционные СУБД или СУБД SQL ориентированы на эффективное управление данными, полученными из ограниченного набора типов данных (определенных соответствующими языковыми стандартами), объектно-реляционные СУБД позволяют разработчикам программного обеспечения интегрировать свои собственные типы и методы, которые применить к ним в СУБД.

ORDBMS (например, ODBMS или OODBMS ) интегрирована с объектно-ориентированным языком программирования . Характерные свойства ORDBMS: 1) сложные данные, 2) наследование типов и 3) поведение объекта. Создание сложных данных в большинстве СУБД SQL основано на предварительном определении схемы через определяемый пользователем тип (UDT). Иерархия в структурированных сложных данных предлагает дополнительное свойство — наследование типов . То есть структурированный тип может иметь подтипы, которые повторно используют все его атрибуты и содержат дополнительные атрибуты, специфичные для этого подтипа. Другое преимущество — поведение объекта — связано с доступом к программным объектам. Такие программные объекты должны быть сохраняемыми и переносными для обработки базы данных, поэтому они обычно называются постоянными объектами . Внутри базы данных все отношения с постоянным программным объектом являются отношениями с его идентификатором объекта (OID) . Все эти моменты можно решить в соответствующей реляционной системе, хотя стандарт SQL и его реализации налагают произвольные ограничения и дополнительную сложность.

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

Фундаментальные модели

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

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

Организация информации в реляционной базе данных

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

• «один к одному». Связи данного типа предполагают наличие в двух связанных таблицах только одного одинакового атрибута;
• «один ко многим». Это означает, что при данном типе связи один атрибут первой таблицы совпадает с несколькими атрибутами во второй;
• «многие ко многим». В данном случае связи между двумя таблицами устанавливаются через несколько соответствующих друг другу атрибутов.

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

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

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

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

Узнать более подробно об организации информации в реляционных базах данных все желающие смогут в рамках профессиональной подготовки по курсу «Инструментальные средства бизнес-аналитики», которую проводит ВШБИ НИУ ВШЭ. Записаться на обучение по данному курсу можно на нашем сайте.

Как ускорить работу компьютера (ноутбука) Windows 7

Структура реляционной таблицы

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

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

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

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

Связь двух таблиц В нормализованной реляционной БД характеризуется чаще всего отношениями записей двух типов: «один-к-одному» (1:1) и «один-ко-многим» (1:M).

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

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

Для двух таблиц, которые характеризуются связью типа 1:M, она устанавливается по уникальному ключу главной таблицы (представляет в отношении сторону «один»). Во второй таблице, которая представляет в отношении сторону «многие» и называется подчиненной, данный ключ связи может не входить в состав уникального ключа или являться его частью. Ключ связи подчиненной таблицы еще называют внешним ключом.

На рисунке 1 представлены 2 таблицы, которые содержат список покупателей и перечень заключенных договоров. Таблицы связаны отношением типа 1:M и логически связаны общим полем (столбцом) Код покупателя, которое является ключом связи. Данное поле –уникальный ключ в главной таблице ПОКУПАТЕЛЬ и неключевое поле в подчиненной таблице ДОГОВОР.

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

Access содержит средство редактирования и просмотра связанных записей нескольких таблиц. Если раскрыть один уровень иерархии, рядом с записью главной таблицы будут отображаться связанные записи подчиненной. К примеру, для таблиц ДОГОВОР и ПОКУПАТЕЛЬ (рисунок 2), которые связаны отношением 1:М, для каждой записи таблицы ПОКУПАТЕЛЬ можно отобразить и отредактировать связанные записи в таблице ДОГОВОР.

Реляционная модель

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

Ограничения традиционной реляционной модели при моделировании нескольких сущностей реального мира привели к изучению семантических моделей данных и так называемых расширенных реляционных моделей данных. За право считаться следующим поколением реляционной модели сейчас соревнуются две модели: объектно-ориентированная и объектно-реляционная. Базы данных, разрабатываемые на основе первой, называются объектно-ориентированными системами управления базами данных (ООСУБД; Object-Oriented Database Management Systems — OODBMS), а базы данных,разрабатываемые на основе второй, соответственно — объектно-реляционными системами управления базами данных.

Правила Кодда

Правило 0: Основное правило (Foundation Rule):

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

Правило 1: Информационное правило (The Information Rule):

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

Правило 2: Гарантированный доступ к данным (Guaranteed Access Rule):

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

Правило 3: Систематическая поддержка отсутствующих значений (Systematic Treatment of Null Values):

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

Правило 4: Доступ к словарю данных в терминах реляционной модели (Active On-Line Catalog Based on the Relational Model):

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

Правило 5: Полнота подмножества языка (Comprehensive Data Sublanguage Rule):

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

(а) имеет линейный синтаксис,

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

(в) поддерживает операции определения данных, определения представлений, манипулирования данными (интерактивные и программные), ограничители целостности, управления доступом и операции управления транзакциями (begin, commit и rollback).

Правило 6: Возможность изменения представлений (View Updating Rule):

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

Правило 7: Наличие высокоуровневых операций управления данными (High-Level Insert, Update, and Delete):

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

Правило 8: Физическая независимость данных (Physical Data Independence):

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

Правило 9: Логическая независимость данных (Logical Data Independence):

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

Правило 10: Независимость контроля целостности (Integrity Independence):

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

Правило 11: Независимость от расположения (Distribution Independence):

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

Правило 12: Согласование языковых уровней (The Nonsubversion Rule):

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

Доля рынка

Согласно DB-Engines , в сентябре 2020 года наиболее широко используемыми системами были (ранжированы в следующем порядке):

• Oracle ,
• MySQL ( бесплатное программное обеспечение ),
• Microsoft SQL Server ,
• PostgreSQL (с открытым исходным кодом, продолжение разработки после INGRES),
• IBM DB2 ,
• SQLite (бесплатное программное обеспечение),
• Microsoft Access ,
• и MariaDB (бесплатное программное обеспечение),
• Терадата ,
• и Apache Hive (бесплатное программное обеспечение; специализировано для хранилищ данных ).

По данным исследовательской компании Gartner , в 2011 году в пятерку ведущих производителей реляционных баз данных собственного ПО по объему выручки входили Oracle (48,8%), IBM (20,2%), Microsoft (17,0%), SAP, включая Sybase (4,6%) и Teradata (3,7 %). %).

Принципы создания

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

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

Жесткие диски цены

О выборе SQL-баз данных

1. Необходимость соответствия базы данных требованиям ACID (Atomicity, Consistency, Isolation, Durability — атомарность, непротиворечивость, изолированность, долговечность). Это позволяет уменьшить вероятность неожиданного поведения системы и обеспечить целостность базы данных. Достигается подобное путём жёсткого определения того, как именно транзакции взаимодействуют с базой данных. Это отличается от подхода, используемого в NoSQL-базах, которые ставят во главу угла гибкость и скорость, а не 100% целостность данных.
2. Данные, с которыми вы работаете, структурированы, при этом структура не подвержена частым изменением. Если ваша организация не находится в стадии экспоненциального роста, вероятно, не найдётся убедительных причин использовать БД, которая позволяет достаточно вольно обращаться с типами данных и нацелена на обработку огромных объёмов информации.

Реляционная модель

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

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

Пример модели реляционной базы данных

Для наглядности приведем простой пример реляционной модели базы данных, состоящей из двух сущностей. Существует таблица с названием «Деканат».

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

Как мы видим, типы полей реляционных баз данных совершенно различаются. Присутствуют как цифровые записи, так и символьные. Поэтому в настройках атрибутов следует указывать значения integer, char, vachar, date и другие. В таблице «Деканат» уникальным значением является только ID студента. Данное поле можно взять за первичный ключ. ФИО, группа и телефон из сущности «Студенты» могут быть взяты как внешний ключ, ссылающийся на ID студента. Связь установлена. Это пример модели со связью «один к одному». Гипотетически одна из таблиц лишняя, их можно легко объединить в одну сущность. Чтобы ID-номера студентов не стали всеобще известными, вполне реально существование двух таблиц.

Достоинства и недостатки реляционной модели данных

Достоинства

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

Недостатки

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

Что такое нереляционная база данных

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

Существуют различные типы нереляционных баз данных.

Базы документов — Хранить динамические данные. Они хранят данные в формате JavaScript Object Notation (JSON). Например. CouchDB, Монго

Базы данных столбцов — Чтение и запись данных столбца мудро. Это полезно в аналитике данных. Например. Апач Кассандра.

Значение ключа хранимых баз данных — Быстро и не очень настраиваемый. Например. Couchbase Server, Redis.

Кэш базы данных — Храните данные на диске или в кеше. Например. Memcache

Граф базы данных — состоят из узлов. Отношения создаются с использованием ребер. Например. Oracle NoSQL, Neo4J.

Примеры реляционных СУБД

SQLite — это популярная БД SQL с открытым исходным кодом. ПО может хранить всю БД в одном файле. Самым значительным преимуществом, которое она обеспечивает, является то, что все данные могут храниться локально без подключения к серверу. SQLite стала популярной для БД в мобильных телефонах, КПК, MP3-плеерах, телевизионных приставках и других электронных гаджетах.

MySQL — еще одна популярная реляционная модель СУБД SQL с открытым исходным кодом. Обычно она применяется в веб-приложениях и часто доступна с помощью PHP. Главные преимущества ее — простота использования, ценовая доступность, надежность. Некоторые из недостатков проявляются в том, что при масштабировании она страдает от низкой производительности, разработка с применением открытого исходного кода отстает с тех пор, как Oracle установил контроль над MySQL и не включает в себя некоторые расширенные функции.

PostgreSQL — это реляционная модель данных СУБД SQL с использованием открытого исходного кода, которая не контролируется какой-либо корпорацией. Обычно ее используют для разработки веб-приложений. PostgreSQL — простая, надежная и бюджетная программа с большим сообществом разработчиков. Имеет дополнительные функции в виде поддержки внешнего ключа, не требуя сложной настройки. Главный ее недостаток — она работает медленнее, чем иные БД, такие как MySQL. Она также менее популярна, чем MySQL, что затрудняет доступ хостов или поставщиков услуг, которые предлагают управляемые экземпляры PostgreSQL.

Объектная модель

Объектные (или объектно-ориентированные) базы данных по большей части основываются на использовании объектно-ориентированных языков программирования,наподобие C++, Java и Smalltalk. В частности, ОСУБД создаются за счет комбинирования возможностей баз данных с функциональностью объектно-ориентированных языков программирования. Из-за этого любая ОСУБД может, по сути, считаться просто расширением объектно-ориентированного языка с добавленными к нему возможностями для обеспечения взаимосовместимости и восстановления данных. Объектно-ориентированный язык применяется и для разработки приложения, и для хранения данных.Кроме того, он используется для создания объектов, которые являются основными компонентами ОСУБД.

• Ниже перечислено несколько терминов, которые в объектно-ориентированных средах имеют особое значение.
• Объектами (objects) называются сущности, содержащие атрибуты объекта реального мира и ассоциируемые с ним действия.
• Свойствами (properties) называются различные атрибуты объекта.
• Методами (methods) в объектном мире называются функции, которые определяют поведение объекта.
• Взаимодействуют объекты друг с другом посредством сообщений (messages).
• Классом (class) называется группа объектов, обладающих одинаковыми атрибутами.
• Экземплярами (instances) называются фактические инкарнации объектов в классе.
• Классы могут делиться на подклассы (subclasses) и тогда иметь родительский класс, называемый суперклассом (superclass).

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

• Полиморфизм (polymorphism). Под полиморфизмом подразумевается способность объектов реагировать по-разному при получении разных наборов информации (в виде параметров). Объектно-ориентированные языки позволяют делать так,чтобы в зависимости от предоставляемых параметров выполнялись разные методы. В языках, не являющихся объектно-ориентированными, обеспечивать выполнение двух различных задач можно только путем создания двух функций с двумя разными именами.
• Инкапсуляция (encapsulation). Под инкапсуляцией подразумевается возможность включать в объекты информацию как о том, что они собой представляют (их свойства), так и о том, что они могут делать (их методы). Другими словами инкапсуляция позволяет упаковывать код и данные вместе. Например, при наличии в модели объекта, представляющего человека, и метода, позволяющего вычислять его ежегодную заработную плату, код (или метод) для вычисления заработной платы будет “инкапсулироваться” вместе с экземпляром объекта (т.е. человека).
• Наследование (inheritance). Под наследованием подразумевается возможность порождения одного класса от другого для того, чтобы тот мог обладать как некоторыми характеристиками своего родителя, так и своими собственными, отличающимися характеристиками. Например, объект, представляющий студента (Student),может являться подклассом класса, представляющего человека (Person).

Особенности, структура и термины, связанные с реляционной моделью

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

• реляционная табличка = сущность;
• макет = атрибуты = наименование полей = заголовок столбцов сущности;
• экземпляр сущности = кортеж = запись = строка таблички;
• значение атрибута = ячейка сущности= поле.

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

1. Сущность. Таблица реляционной базы данных может быть одна, а может быть целый набор из таблиц, которые характеризируют описанные объекты благодаря хранящимся в них данным. У них фиксированное количество полей и переменное число записей. Таблица реляционной модели баз данных составляется из строк, атрибутов и макета.
2. Запись – переменное число строк, отображающих данные, что характеризируют описываемый объект. Нумерация записей производится системой автоматически.
3. Атрибуты — данные, демонстрирующие собой описание столбцов сущности.
4. Поле. Представляет собой столбец сущности. Их количество – фиксированная величина, устанавливаемая во время создания или изменения таблицы.

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

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

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