Инфологическое проектирование базы данных реферат

Обновлено: 03.07.2024

Цель курсового проектирования – применение на практике знаний, полученных в процессе изучения курса "Технология баз данных", и приобретение практических навыков создания автоматизированных информационных систем (АИС), основанных на базах данных.

ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ

Общие положения

Проектирование базы данных (БД) – одна из наиболее сложных и ответственных задач, связанных с созданием информационной системы (ИС).

В результате её решения должны быть определены:

- эффективный способ организации данных

- инструментальные средства управления данными.

Основная цель проектирования БД - создание проекта, удовлетворяющего следующим требованиям:

Корректность схемы БД, т.е. каждому объекту предметной области соответствуют данные в памяти ЭВМ, а каждому процессу – адекватные процедуры обработки данных.
Гибкость, т.е. возможность развития и адаптации к изменениям предметной области и/или требований пользователей.
Простота и удобство эксплуатации.
Защита данных от аппаратных и программных сбоев и несанкционированного доступа.
Эффективность функционирования, т.е. соблюдение ограничений на время реакции системы на запрос и обновление данных.
Обеспечение ограничений на ресурсы вычислительной системы.

Удовлетворение требований 1–4 обязательно для принятия проекта.

Этапы проектирования базы данных

Процесс проектирования включает в себя следующие этапы:

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

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

Инфологическое проектирование

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

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

Рассмотрим основные подходы к созданию инфологической модели предметной области.

Функциональный -реализует принцип "от задач" и применяется тогда, когда известны функции некоторой группы лиц и/или комплекса задач, для обслуживания информационных потребностей которых создаётся рассматриваемая БД.

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

Проектирование с использованием модели "сущность-связь".

Модель "сущность–связь" или ER–модель является комбинацией двух предыдущих подходов и обладает достоинствами обоих.

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

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

Сущность – это объект, о котором в системе будет накапливаться информация. Сущности бывают как физически существующие (например, СОТРУДНИК или АВТОМОБИЛЬ), так и абстрактные (например, ЭКЗАМЕН или ДИАГНОЗ).

Для сущностей различают тип сущности и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр – конкретными значениями свойств.

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

Для каждой сущности выбираются свойства (атрибуты). Различают:

Идентифицирующие и описательные атрибуты. Идентифицирующие атрибуты имеют уникальное значение для сущностей данного типа и являются потенциальными ключами. Они позволяют однозначно распознавать экземпляры сущности. Из потенциальных ключей выбирается один первичный ключ (ПК). В качестве ПК обычно выбирается потенциальный ключ, по которому чаще происходит обращение к экземплярам записи. Кроме того, ПК должен включать в свой состав минимально необходимое для идентификации количество атрибутов. Остальные атрибуты называются описательными и заключают в себе интересующие свойства сущности.
Составные и простые атрибуты. Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких компонентов, возможно, принадлежащих разным типам данных (например, ФИО или адрес). Решение о том, использовать составной атрибут или разбивать его на компоненты, зависит от характера его обработки и формата пользовательского представления этого атрибута.
Однозначные и многозначные атрибуты (могут иметь соответственно одно или много значений для каждого экземпляра сущности).
Основные и производные атрибуты. Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута вычисляется на основе значений других атрибутов (например, возраст студента вычисляется на основе даты его рождения и текущей даты).

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

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

Каждая связь характеризуется именем, обязательностью, типом и степенью. Различают факультативныеиобязательныесвязи. Если вновь порождённый объект одного типа оказывается по необходимости связанным с объектом другого типа, то между этими типами объектов существует обязательная связь (обозначается двойной линией). Иначе связь является факультативной.

По типу различают множественные связи "один к одному" (1:1), "один ко многим" (1: n) и "многие ко многим" (m: n). ER–диаграмма, содержащая различные типы связей, приведена на рис. 1. Обратите внимание, что обязательные связи на рис. 1 выделены двойной линией.

Рис.1. ER–диаграмма с примерами типов множественных связей

Степень связи определяется количеством сущностей, которые охвачены данной связью. Пример бинарной связи – связь между отделом и сотрудниками, которые в нём работают. Примером тернарной связи является связь типа экзамен между сущностями ДИСЦИПЛИНА, СТУДЕНТ, ПРЕПОДАВАТЕЛЬ. Из последнего примера видно, что связь также может иметь атрибуты (в данном случае это Дата проведения и Оценка). Пример ER–диаграммы с указанием сущностей, их атрибутов и связей приведен на рис. 2.

Рис.2. Пример ER–диаграммы с однозначными и многозначными атрибутами

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

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

объединение в единое целое фрагментарных представлений о различных свойствах одного и того же объекта;
введение абстрактных понятий, удобных для решения задач системы, установление их связи с конкретными понятиями, использованными в модели;
образование классов и подклассов подобных объектов (например, класс "изделие" и подклассы типов изделий, производимых на предприятии).

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

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

Обеспечения надежности системы управления данными. Походы к выбору состава и структуры предметной области. Исследования информационной среды для моделирования. Цель инфологического моделирования – обеспечение естественных способов сбора информации.

Рубрика	Программирование, компьютеры и кибернетика
Вид	курсовая работа
Язык	русский
Дата добавления	27.02.2009
Размер файла	212,0 K

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

ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Описание предметной области

1.2 Инфологическое моделирование

ГЛАВА 2. ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

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

ВВЕДЕНИЕ

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

Инфологическое проектирование прежде всего связано с попыткой представления семантики предметной области в модели БД.

Цель нашего проекта - инфологическое моделирование информационной системы выборов.

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

- целостность и непротиворечивость данных,

- достоверность данных,

- простота управления данными,

- безопасность доступа к данным.

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

ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1. Системный анализ и словесное описание информационных объектов предметной области.

2. Проектирование инфологической модели предметной области - частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ER-модели.

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

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

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

Рис. 1. Этапы проектирования БД

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

В общем случае существуют два похода к выбору состава и структуры предметной области:

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

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

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

1.2 Инфологическое моделирование

Процесс, в ходе которого решается, какой вид будет у вновь создаваемой базы данных, называется проектированием базы данных (database design). Работа по проектированию базы данных включает выбор:

- таблиц, которые будут входить в базу данных,

- столбцов, принадлежащих каждой таблице,

- взаимосвязей между таблицами и столбцами.

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

1. Исследования информационной среды для моделирования.

Откуда поступает информация и в каком виде?

Как она будет вводиться в систему и кто этим будет заниматься?

Как часто она изменяется?

Какие параметры системы будут наиболее критическими с точки зрения времени реакции на запрос и надежности?

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

Уточнение, в каком виде информация должна извлекаться из базы данных -- в форме отчетов, заказов, статистической информации.

Кому она будет предназначаться.

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

3. В ходе работы обязательно должен создаваться макет таблиц и связей между ними, называемый структурой данных (data structure), или диаграммой зависимостей между объектами (E-R diagram).

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

5. Затем должны быть рассмотрены зависимости между объектами.

Имеются ли зависимости типа один-ко-многим (один заказчик может иметь множество выписанных счетов, но каждый счет может быть выписан только на одного заказчика) или многие-ко-многим?

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

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

7. Непосредственному создание структуры базы данных и помещению в нее некоторых прототипов данных. Обязательное экспериментирование с запросами, изучение полученных результатов. Выполнение рядов тестов на производительность, чтобы проверить разные технические решения.

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

Данная СУБД была выбрана по следующим причинам:

- простота средств реализации,

- легкость освоения инструментарием разработчика (VBA),

- наглядность визуализации информации.

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

- один-к-одному;

- один-ко-многим;

- многие-к-одному;

- многие-ко-многим.

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

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

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

Сущность имеет имя, уникальное в пределах модели. При этом имя сущности - это имя типа, а не конкретного экземпляра.

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

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

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

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

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

Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип - связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

Второй тип - связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

ГЛАВА 2. ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. Наиболее популярной из них оказалась модель "сущность-связь" или называемая ещё ER-моделью (от англ. Entity-Relationship, т.е. сущность-связь).

Ключ — минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Так как между двумя сущностями возможны связи в обоих направлениях, то существует ещё два типа связи МНОГИЕ-К-ОДНОМУ (М: 1) и МНОГИЕ-КО-МНОГИМ (М: М). Но мы их… Читать ещё >

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

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

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

Связь — ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных — это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи (16, "https://referat.bookap.info").

Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип — связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности, А соответствует 1 или 0 представителей сущности В:

Второй тип — связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности, А соответствуют 0, 1 или несколько представителей сущности В.

Квартира может пустовать, в ней может жить один или несколько жильцов.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует ещё два типа связи МНОГИЕ-К-ОДНОМУ (М: 1) и МНОГИЕ-КО-МНОГИМ (М: М). Но мы их использовать не будем.

На последующих страницах представлены ER – диаграммы на русском (рис.1) и английском языках (рис.2) (разработаны в проектировщике Microsoft Visio). Данные ER – диаграммы были разработаны в 2008 году Пилюгиной Татьяной Анатольевной.

3.2 Диаграмма "сущность-связь"

4. ПРЕОБРАЗОВАНИЕ ER-ДИАГРАММЫ

1. Жилищная организация (номер организации, код организации, название организации, адрес, телефон);

2. Жилой дом (номер дома, адрес, количество квартир, номер организации);

3. Квартира (номер квартиры, жилая площадь, количество комнат, номер дома);

4. Жильцы (номер жильца, фамилия, имя, отчество, номер дома, номер квартиры);

5. Информация о жильце (паспортные данные, место дата рождения, место рождения, откуда прибыл, гражданство, национальность, владелец/квартиросъемщик, вид прописки, состав семьи, количество прописанных, номер жильца);

6. Услуга (номер услуги, наименование, цена, причина, номер жильца);

7. Информация о выполненной услуге (номер выполненной услуги, срок выполнения, номер услуги).

5. ВЫБОР И ОПИСАНИЕ ИСПОЛЬЗУЕМОЙ СУБД

· Легкий способ создания приложений клиент/сервер. Проект Microsoft Access (.adp) представляет собой новый тип файлов Access, предоставляющих эффективный, естественный доступ к базам данных Microsoft SQL Server с помощью архитектуры компонентов OLE DB. С помощью проекта Access можно легко создать приложение типа клиент/сервер.

· Работа с проектами Access. Работа с проектом Microsoft Access очень похожа на работу с базой данных Access. Процесс создания форм, отчетов, страниц доступа к данным, макросов и модулей одинаков. Подключившись к базе данных SQL Server, можно просматривать, создавать, изменять и удалять таблицы, представления, сохраненные процедуры и схемы баз данных с помощью средств разработки Microsoft SQL Server Design Tools.

· Использование ядра MSDE (Microsoft Data Engine). MSDE представляет собой новую технологию, обеспечивающую совместимость локального хранения данных с Microsoft SQL Server 7.0. MSDE можно рассматривать как ядро обработки данных в архитектуре клиент/сервер, альтернативное ядру базы данных Microsoft Jet для файлового сервера. Технология MSDE разработана и оптимизирована для использования на малых компьютерах, таких как рабочие станции пользователей или малые серверы рабочих групп.

· Преобразование данных и объектов в формат SQL Server с помощью мастера. Мастер преобразования в формат SQL Server преобразует базу данных Microsoft Access (.mdb) в новую или существующую базу данных Microsoft SQL Server версий 6.5 или 7.0, либо в новый проект Microsoft Access (.adp) путем преобразования данных и описаний данных и переноса объектов базы данных.

6. СОЗДАНИЕ БАЗЫ ДАННЫХ

При запуске Microsoft Access открывается диалоговое окно, в котором предлагается создать новую базу данных или открыть существующую. Выбираем в этом диалоговом окне переключатель Новая база данных и нажимаем кнопку ОК.

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

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

Связываем таблицы. Указываем тип связи. Получается:

Наша база данных готова к эксплуатации. Можно вводить необходимые данные.

В ниже представленных таблицах приведен пример ввода первичных данных в созданную базу данных.

СПИСОК ИСПОЛЬЗОВАННЫХ ИНФОРМАЦИОННЫХ ИСТОЧНИКОВ

Раздел: Информатика, программирование
Количество знаков с пробелами: 21159
Количество таблиц: 0
Количество изображений: 11

Читайте также: