Информационное обеспечение систем управления

Особенности реляционной модели данных будут рассмотрены отдельно. Сейчас важно, что конечный пользователь представляет базу данных в виде трёх правильных таблиц, хотя физически она хранится по-другому. Иерархическая модель. Покажем один из возможных вариантов иерархической модели для предметной области из предыдущего примера. В этой модели данные имеют структуру простого дерева, в котором записи о деталях, например, предшествуют записям о поставщиках. Пользователь представляет базу данных в виде четырёх отдельных деревьев, или экземпляров иерархии, по одному на каждую деталь (рис. 2.3). Каждое дерево состоит из одной записи о детали и набора подчинённых записей о поставщиках, по одной для каждого поставщика. Каждая запись поставщика включает соответствующую величину, количественно характеризующую поставку. Число записей поставщиков для данной записи детали может быть любым, включая нуль (для детали Д4). М ожно рассмотреть и другую модель, в которой в корне дерева находятся по одной записи о поставщике. Тип записи в вершине дерева, как и обычно, называется корнем. В нашем примере корень имеет один только подчинённый вид записи (поставщик). В общем случае, корень может иметь произвольное число подчинённых элементов более низкого уровня иерархии. Рис. 2.3. Пример иерархической модели В реляционной базе данных каждой таблице соответствует отдельный файл, в иерархической   один файл содержит четыре отдельных дерева. Эта модель удобна для моделирования соответствия «один – ко   многим». Сетевая модель. Покажем возможный вариант сетевой модели для рассматриваемого примера. Он приведен на рис. 2.4. Здесь, также как и в иерархической модели, данные представляются посредством записей и связей. Но это наиболее общая структура, так как запись может иметь любое число предшествующих записей (в иерархической модели – одну). Данная модель позволяет просто и удобно моделировать соответствие “многие   ко   многим”. В дополнение к записям о деталях и поставщиках, введём третий тип записи, которую можно назвать связующей. Эта связь представляет зависимость между одним поставщиком и одной деталью и содержит количественное выражение этой зависимости (количество поставляемых деталей). Все экземпляры связующей записи, соответствующие одному поставщику, помещаются в цепочку, начинающуюся и заканчивающуюся этим поставщиком. Аналогично, все экземпляры связующей записи для данной детали размещены цепочкой, начинающейся и оканчивающейся этой деталью. Каждый экземпляр связующей записи связан точно с двумя цепочками – цепочкой поставщиков и цепочкой деталей. Например, поставщик П2 поставляет 300 деталей Д1 и 400 деталей Д2. Аналогично, деталь Д1 поставляется в количестве 300 поставщиком П1 и 300 поставщиком П2. Перечислим особенности рассмотренных моделей: 1. Во всех трёх моделях допустимыми информационными единицами являются записи. В иерархических моделях и сетевых, запись может содержать агрегат данных – составную информационную единицу. Например, ДАТА (ЧИСЛО, МЕСЯЦ, ГОД). В реляционной модели для составных данных обычно образуют отдельную таблицу. Количественные характеристики записи (число полей, размер поля, тип поля) определяется конкретной СУБД. 2. Связи во всех моделях имеют свои особенности: в реляционной модели представляются неявно, через одинаковые значения в однотипных столбцах (1:1); в иерархической модели задаются явно, но каждая запись имеет только одну предшествующую запись, хотя несколько последующих (1:М); в сетевой модели имеет место наиболее общий случай; каждая запись может иметь несколько предшествующих и несколько последующих (N:M). 3. Реализация запросов в СУБД с различными моделями различна. Например, рассмотрим алгоритм реализации запроса: найти номера поставщиков, поставляющих деталь Д2 (табл. 2.4). Таблица 2.4 Реляционная модель Иерархическая модель Сетевая модель М: Получить [следующую] поставку, где №Д=Д2. Поставка найдена? Если нет, то выход из программы. Печать №П. Переход на М. Получить [следующую] деталь, где №Д=Д2. М: Получить следующего поставщика для этой детали. Поставщик найден? Если нет, то выход из программы. Печать №П. Переход на М. Получить [следующую] деталь, где №Д=Д2. М: Получить следующую связь для этой детали. Связь найдена? Если нет, то выход. Печать поставщика, исходного для этой связи. Печать №П. Переход на М. Из таблицы видно, что алгоритмы выполнения запроса для каждой модели имеют свои особенности. В заключении данного раздела перечислим основные функции СУБД. В учебниках к их числу принято относить следующие функции. Непосредственное управление данными во внешней памяти. Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для ускорения доступа к данным (обычно для этого используются индексы). В некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других работа производится вплоть до уровня устройств внешней памяти. Но подчеркнем, что в развитых СУБД пользователи в любом случае не обязаны знать, использует ли СУБД файловую систему, и если использует, то как в ней организованы файлы. В частности, СУБД поддерживает собственную систему именования объектов БД. Управление буферами оперативной памяти. СУБД обычно работают с БД значительного размера; по крайней мере, размер существенно больше доступного объема оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. При этом, даже если операционная система производит общесистемную буферизацию, этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной управления ими. Управление транзакциями. Транзакция   это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Поддержание механизма транзакций является не обязательным условием даже однопользовательских СУБД, а в многопользовательских СУБД эта функция необходима. Журнализация. Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут служить аварийное завершение работы СУБД по причине аппаратного сбоя или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной и требуется ликвидировать ее последствия. Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД. Журнал   это особая часть БД, недоступная конечным пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала. Конечно, для нормального восстановления БД после сбоя необходимо, чтобы журнал не пропал. Поддержка языков БД. Для работы с базами данных используются специальные языки. Как правило, поддерживаются два языка   язык определения данных и язык манипулирования данными. Первый служит для определения логической структуры БД, второй   позволяет заносить данные, удалять, модифицировать или выбирать существующие данные. Кроме того, реляционные СУБД обычно поддерживают язык SQL (Structured Query Language). В подразделе язык SQL будет рассматриваться достаточно подробно. 3. РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ В упрощенном виде основная идея реляционной модели состоит в том, что данные должны храниться в таблицах и только в таблицах. Эта, кажущаяся тривиальной, идея оказывается вовсе не простой при рассмотрении вопроса, а что, собственно, представляет собой таблица? В данный момент существуем много различных систем обработки данных, оперирующих понятием "таблица", например, всем известные, электронные таблицы Excel, таблицы текстового редактора Word, и т.п. Ячейки электронной таблицы могут хранить разнотипные данные, например, числа, строки текста, формулы, ссылающиеся на другие ячейки. Собственно, на одном листе электронной таблицы можно разместить несколько совершенно независимых таблиц, если под таблицей понимать прямоугольную область, расчерченную на клеточки и заполненную данными. Таблицы текстовых редакторов вообще могут иметь совершенно произвольную структуру, например, такую, какую имеет следующая таблица. Отдел Сотрудники Дети сотрудников и их интересы Кафедра АиС Иванов И.И. Маша ЛЕГО Петя Книги Видео Саша Компьютеры Дима Спорт Петров П.П. Артур Ничем не интересуется Сидоров С.С. Сергей Компьютеры, Книги Валерий Книги Станислав Видео Кафедра ВТ Сорокин Н.В. … Конечно, и электронные таблицы, и текстовые редакторы позволяют хранить и обрабатывать данные очень гибко. Но как быть, если требуется хранить информацию обо всех сотрудниках большого предприятия и периодически выдавать ответы на запрос, например, следующего типа. Представить список всех сотрудников, принятых на работу не позднее трех лет назад, имеющих не менее одного ребенка, не имеющих взысканий и с зарплатой не выше 5000 р. Для получения ответов на подобные запросы и предназначены реляционные СУБД. Реляционная модель основана на теории множеств и математической логике. Такой фундамент обеспечивает математическую строгость данной модели. В свою очередь, на основе этой модели были разработаны различные языки для доступа к табличным данным. Фактическим промышленным стандартом таких языков в настоящее время стал язык SQL (Structured Query Language   язык структурированных запросов). 3.1. Основные понятия и определения Согласно Дейту [1], реляционная модель состоит из трех частей, а именно: структурной, целостной и манипуляционной. Структурная часть описывает, какие объекты рассматриваются реляционной моделью. Постулируется, что единственной структурой данных, используемой в той модели, являются нормализованные n-арные отношения. Целостная часть описывает ограничения специального вида, которые должны выполняться для любых отношений в любых реляционных базах данных. Эти ограничения принято делить на два вида   внутренняя целостность (целостность сущностей) и внешняя целостность (ссылочная целостность или целостность внешних ключей). Манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными   реляционную алгебру и реляционное исчисление. В данном разделе описана структурная часть реляционной модели. Классическая реляционная модель данных требует, чтобы данные хранились в, так называемых, правильных таблицах. В упрощенном виде правильная таблица   это таблица, каждая ячейка которой может быть однозначно идентифицирована указанием строки и столбца таблицы. Следовательно, правильная таблица с точки зрения разработчика и пользователя – это плоская прямоугольная таблица. Требование плоскости означает, что таблица может быть изображена на листе или экране в привычном для нас виде. Прямоугольность означает, во-первых, что не допускаются таблицы, имеющие вид: как на рис. 3.1 а). Во-вторых, не допускаются таблицы со сложными заголовками (см. рис. 3.1 б)). а) б) Дата число месяц год Рис. 3.1 Недопустимый вид таблиц Необходимым признаком прямоугольности таблицы является одинаковое число ячеек в каждой ее строке, включая заголовок, и одинаковое число ячеек в каждом ее столбце. Правильные таблицы называют отношениями, либо базами данных, либо просто таблицами, либо в dBase-подобных СУБД DBF-файлами. Почему используется термин "отношения"? Основной структурой данных в реляционной модели считается отношение, от английского слова relation – отношение модель получила свое название   реляционная. Известно, что любое не пустое подмножество декартова произведения D1 D2  ... Dn заданной системы множеств D1, D2, ..., Dn, (n > 1), необязательно различных, в теории множеств называют n-арным отношением R . RD1 D2  ... Dn . Число n – это степень отношения. Число кортежей, входящих в отношение R есть мощность отношения R. Исходные множества D1, D2, ..., Dn называют в реляционной модели доменами. Все элементы отношения   это однотипные кортежи. Однотипность кортежей позволяет считать их аналогами строк в правильной таблице. Например, имеем три домена: D1 содержит три фамилии; D2   набор из названий двух учебных дисциплин и D3   набор из трех оценок. Допустим, содержимое доменов следующее: D1={Иванов, Крылов, Степанов}; D2={Теория автоматов, Базы данных}; D3={3, 4, 5}. Тогда декартово произведение D1 D2  D3 является множеством из 323=18 трехкомпонентных кортежей: {<Иванов, Теория автоматов, 3>; <Иванов, Теория автоматов, 4>; <Иванов, Теория автоматов, 5>; <Крылов, Теория автоматов, 3>; <Крылов, Теория автоматов, 4>; <Крылов, Теория автоматов, 5>; <Степанов, Теория автоматов, 3>; <Степанов, Теория автоматов.4>; <Степанов, Теория автоматов, 5>; <Иванов, Базы данных, 3>; <Иванов, Базы данных, 4>: <Иванов, Базы данных, 5>; <Крылов, Базы данных, 3>; <Крылов, Базы данных, 4>; <Крылов, Базы данных, 5>; <Степанов, Базы данных, 3>; <Степанов, Базы данных, 4>; <Степанов, Базы данных, 5>}, в которых первая компонента   это одна из фамилий, вторая   это название одной из учебных дисциплин, а третья   одна из оценок. Пусть отношение R1 моделирует реальную ситуацию и содержит, допустим, только 5 строк, которые соответствуют результатам сессии. Крылов экзамен по «Базам данных» еще не сдавал. Тогда: R1={<Иванов, Теория автоматов, 4>; <Крылов, Теория автоматов, 5>; <Степанов, Теория автоматов, 5>; <Иванов, Базы данных, 3>; <Степанов, Базы данных, 4>}. Отношение R1 может быть представлено в виде следующей таблицы. R1 Фамилия Дисциплина Оценка Иванов Теория автоматов 4 Иванов Базы данных 3 Крылов Теория автоматов 5 Степанов Теория автоматов 5 Степанов Базы данных 4 В реальной действительности отношение, моделирующее текущую ситуацию в предметной области, включает в себя не все возможные кортежи из декартового произведения, а только его часть. Это значит, что для каждого отношения имеется критерий, позволяющий определить, какие кортежи входят в отношение, а какие   нет. Этот критерий, по существу, определяет для нас смысл (семантику) отношения. Действительно, каждому отношению можно поставить в соответствие некоторое логическое выражение P(x1, x2, … ,xn), зависящее от n параметров (n-местный предикат) и определяющее, будет ли кортеж (a1, a2, … ,an) принадлежать отношению R. Это логическое выражение называют предикатом отношения R. Более точно, кортеж (a1, a2, … ,an) принадлежит отношению R тогда и только тогда, когда предикат P(a1, a2, … ,an) принимает значение "истина". Мы рассмотрели на содержательном уровне структуру таблицы. А каковы требования реляционной модели к ее внутреннему содержанию? Основное требование содержательно можно сформулировать следующим образом. В каждой ячейке таблицы должен хранится ровно один, неделимый в рамках данной модели, элемент информации, и все ячейки одного столбца должны содержать данные одного простого типа. Итак, реляционная модель требует, чтобы типы используемых данных были простыми. Для уточнения этого утверждения рассмотрим, какие вообще типы данных обычно рассматриваются в программировании. Как правило, типы данных делятся на три группы: простые, структурированные и ссылочные. Простые, или атомарные, типы данных не обладают внутренней структурой. К ним относятся следующие основные типы: логический, строковый и численный. Различные языки программирования могут расширять и уточнять этот список, добавляя, например, такие типы как целый, интервальный или типа даты. Ниже будут рассмотрены типы данных, которые поддерживаются СУБД VFP. Конечно, понятие атомарности является относительным. Так, строковый тип данных можно рассматривать как одномерный массив символов, а целый тип данных   как набор битов. Важно лишь то, что при переходе на такой низкий уровень теряется семантика (смысл) данных. Если строку, выражающую, например, фамилию сотрудника, разложить в массив символов, то при этом теряется смысл такой строки как единого целого. Собственно, для реляционной модели данных тип используемых данных не важен. Требование, чтобы тип данных был простым, нужно понимать так, что в реляционных операциях не должна учитываться внутренняя структура данных. Конечно, должны быть описаны действия, которые можно производить с данными как с единым целым, например, данные числового типа можно складывать, для строк возможна операция конкатенации и т.д. С этой точки зрения, если рассматривать массив, например, как единое целое и не использовать поэлементных операций, то массив можно считать простым типом данных. Более того, можно создать свой, сколь угодно сложных тип данных, описать возможные действия с этим типом данных, и, если в операциях не требуется знание внутренней структуры данных, то такой тип данных также будет простым с точки зрения реляционной теории. В реляционной модели данных с понятием тип данных тесно связано понятие домена, которое можно считать уточнением типа данных. Домен   это семантическое понятие. Домен можно рассматривать как допустимое подмножество значений некоторого типа данных имеющих определенный смысл. Домен характеризуется следующими свойствами. Домен имеет уникальное имя (в пределах базы данных). Домен определен на некотором простом типе данных или на другом домене. Домен может иметь некоторое логическое условие, позволяющее описать подмножество данных, допустимых для данного домена. Домен несет определенную смысловую нагрузку. Например, домен D, имеющий смысл "Возраст сотрудника" можно описать как следующее подмножество множества натуральных чисел: D={nN : n 18 AND n  60}. Если тип данных можно считать множеством всех возможных значений данного типа, то домен напоминает подмножество в этом множестве. Отличие домена от понятия подмножества состоит именно в том, что домен отражает семантику, определенную предметной областью. Может быть несколько доменов, совпадающих как подмножества, но несущие различный смысл. Например, домены "Вес детали" и "Имеющееся количество" можно одинаково описать как множество неотрицательных целых чисел, но смысл этих доменов будет различным, и это будут различные домены. Основное значение доменов состоит в том, что домены ограничивают сравнения. Некорректно, с логической точки зрения, сравнивать значения из различных доменов, даже если они имеют одинаковый тип. В этом проявляется смысловое ограничение доменов. Синтаксически правильный запрос "Выдать список всех деталей, у которых вес детали больше имеющегося количества" не соответствует смыслу понятий "количество" и "вес". Понятие домена помогает правильно моделировать предметную область. При работе с реальной системой в принципе возможна ситуация когда требуется ответить на запрос, приведенный выше. Система даст ответ, но, вероятно, он будет бессмысленным. Не все домены обладают логическим условием, ограничивающим возможные значения домена. В таком случае множество возможных значений домена совпадает с множеством возможных значений типа данных. Не всегда очевидно, как задать логическое условие, ограничивающее возможные значения домена. Например, каково условие на строковый тип данных, задающий домен "Фамилия сотрудника". Ясно, что строки, являющиеся фамилиями не должны начинаться с цифр, служебных символов, с мягкого знака и т.д. Но вот является ли допустимой фамилия "Ггггггыыыыы"? Трудности такого рода возникают потому, что смысл реальных явлений далеко не всегда можно формально описать. Просто мы, как все люди, интуитивно понимаем, что такое фамилия, но никто не может дать такое формальное определение, которое отличало бы фамилии от строк, фамилиями не являющимися. Выход из этой ситуации простой   положиться на разум конечного пользователя, вводящего фамилии в компьютер. Вхождение домена в отношение принято называть атрибутом или полем. Атрибут отношения есть пара вида <Имя_атрибута : Имя_домена>. Имена атрибутов должны быть уникальны в пределах отношения. Часто имена атрибутов отношения совпадают с именами соответствующих доменов. Отношение R, определенное на множестве доменов D1, D2,…,Dn (не обязательно различных), содержит две части: заголовок и тело. Заголовок отношения содержит фиксированное множество атрибутов данного отношения (<A1 :D1>, <A2 :D2>,…,<An :Dn>). Тело отношения содержит множество кортежей данного отношения, которые обычно называют записями. Ясно, что количество атрибутов есть степень отношения. Отношение обычно записывается в виде R(<A1 :D1>, <A2 :D2>,…,<An :Dn>), (1) или короче R(A1, A2,…,An), или просто R. Возвращаясь к математическому понятию отношения можно сделать следующие выводы. Заголовок отношения описывает декартово произведение доменов, на котором задано отношение. Он статичен и не меняется во время работы с базой данных. Если в отношении изменены, добавлены или удалены атрибуты, то в результате получим уже другое отношение (пусть даже с прежним именем). Тело отношения представляет собой набор кортежей, т.е. подмножество декартового произведения доменов. Таким образом, тело отношения собственно и является отношением в математическом смысле слова. Тело отношения может изменяться во время работы с базой данных   кортежи могут изменяться, добавляться и удаляться. Следовательно, имеет смысл ввести понятие экземпляра отношения, которое отражает состояние некоторого объекта предметной области в текущий момент времени. Реляционной базой данных называется фиксированное в данной предметной области множество отношений. Схемой (логической структурой) реляционной базы данных называется набор заголовков отношений, входящих в эту базу данных. Хотя любое отношение можно изобразить в виде таблицы, нужно четко понимать, что отношения не являются таблицами. Это близкие, но не совпадающие понятия. Свойства отношений непосредственно следуют из определения отношения. В них в основном и состоят различия между отношениями и таблицами. В отношении нет одинаковых кортежей. Действительно, тело отношения есть множество кортежей и, как всякое множество, не может содержать неразличимые элементы. Таблицы в отличие от отношений могут содержать одинаковые строки. Кортежи не упорядочены. Причина та же   тело отношения есть множество, а множество по определению не упорядочено. Строки же в таблицах упорядочены. Одно и то же отношение может быть изображено разными таблицами, в которых строки идут в различном порядке. Атрибуты не упорядочены (слева направо). Поскольку каждый атрибут имеет уникальное имя в пределах отношения, постольку порядок атрибутов не имеет значения. Это свойство несколько отличает отношение от математического определения отношения (компоненты кортежей упорядочены). Столбцы в таблице упорядочены. Одно и то же отношение может быть изображено разными таблицами, в которых столбцы идут в различном порядке. Например, отношение R1 и отношение R2 изображенное ниже, одинаковы с точки зрения реляционной модели данных. R2 Дисциплина Фамилия Оценка Теория автоматов Крылов 5 Теория автоматов Степанов 5 Теория автоматов Иванов 4 Базы данных Иванов 3 Базы данных Степанов 4

Похожие:

	«Учебно-методический комплекс дисциплины «Информационное обеспечение систем управления»		Пояснительная записка «Современная организация и технология документационного обеспечения управления». Он связан с курсами «Документоведение», «Информационное...
	Исследование систем управления процесс определения организационной... Место исследований систем управления в комплексе дисциплин по теории и практке управления		Программное обеспечение для отладки систем управления упругими объектами Целью данной работы является разработка программного обеспечения для лабораторного стенда для изучения систем управления упругими...
	Рабочая программа дисциплины «Информационное обеспечение, базы данных» Факультет информационных систем и технологий Кафедра Прикладной математики и вычислительной техники		Учебная программа по дисциплине " информационное обеспечение управления " Изучение теоретических, методических и практических вопросов разработки, внедрения и совершенствования информационного обеспечения...
	Российской Федерации Самарский государственный архитектурно-строительный... Информационные системы” являются информационные системы и сети, их математическое, информационное и программное обеспечение, способы...		Рабочая программа дисциплины «Архитектура ЭВМ и вычислительных систем»... «Автоматизированные системы обработки информации и управления» (по отраслям) и 230105 «Программное обеспечение вычислительной техники...
	Исследование систем управления Целью работы является рассмотрение частных методов исследования систем управления, а именно эксперимент, наблюдение и опрос		Примерная тематика рефератов по курсу «Исследование систем управления» Современный менеджмент и необходимость исследования систем управления социально-экономической организацией
	Организационно-правовое обеспечение правовой деятельности Информационное обеспечение организации и проведения внеучебной работы		Исследование систем управления Специальности: «Менеджмент организации» «Исследование систем управления» является ведущей,в учебном процессе среди смежных дисциплин
	Реферат по дисциплине "Избирательное право" тема: Информационное... Информационное обеспечение выборов. Правовое регулирование предвыборной агитации в РФ		Информационное обеспечение управления В настоящее время классификационные схемы (классификаторы) строятся не только на основе соподчинения понятий (метод иерархии), но...
	Курсовая работа По дисциплине «Базы данных» Программное обеспечение для создания систем управления базами данных		Рабочая программа учебной дисциплины «исследование систем управления» Студенты научатся методам планирования эксперимента и организации исследования систем управления и научатся использовать приобретенные...