Файл: Департамент образования, науки и молодежной политики.pdf

В рамках архитектуры "файл-сервер" были выполнены первые версии популярных так называемых настольных СУБД, таких, как dBase и Microsoft Access.
Основные недостатки данной архитектуры:
· При одновременном обращении множества пользователей к одним и тем же данным производительность работы резко падает, т.к. необходимо дождаться пока пользователь, работающий с данными, завершит свою работу. В противном случае возможно затирание исправлений, сделанных одними пользователями, изменениями других пользователей.
· Вся тяжесть вычислительной нагрузки при доступе к БД ложится на приложение клиента, так как при выдаче запроса на выборку информации из таблицы вся таблица БД копируется на клиентскую машину и выборка осуществляется на клиенте. Таким образом, неоптимально расходуются ресурсы клиентского компьютера и сети. В результате возрастает сетевой трафик и увеличиваются требования к аппаратным мощностям пользовательского компьютера.
· Недостаточно развитый аппарат транзакций служит потенциальным источником ошибок в плане нарушения смысловой и ссылочной целостности информации при одновременном внесении изменений в одну и ту же запись. Преимуществом этой архитектуры является низкая нагрузка на ЦП сервера, а недостатком - высокая загрузка локальной сети. На данный момент файл-серверные СУБД считаются устаревшими.
Клиент-серверные. Такие СУБД состоят из клиентской части (которая входит в состав прикладной программы) и сервера. Клиент-серверные СУБД, в отличие от файл-серверных, обеспечивают разграничение доступа между пользователями и мало загружают сеть и клиентские машины. Недостаток клиент-серверных СУБД в самом факте существования сервера
(что плохо для локальных программ — в них удобнее встраиваемые СУБД) и больших вычислительных ресурсах, потребляемых сервером. В этой архитектуре на выделенном сервере, работающем под управлением серверной операционной системы, устанавливается специальная программа, управляющая удаленной базой данных - SQL-сервер, например, Microsoft®SQL
Server™или Oracle. Основа работы сервера БД - использование языка запросов SQL (Structured
Query Languague). SQL-сервер обеспечивает интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. Извлеченные данные транспортируются по сети от сервера к клиенту. Тем самым, количество передаваемой по сети информации уменьшается во много раз. Примеры: Firebird, Interbase, MS SQL Server, Sybase,
Oracle, PostgreSQL, MySQL.
Итак, в результате работа построена следующим образом:
· База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (сервера сети).
· СУБД располагается также на сервере сети.
· Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлено клиентское приложение для работы с БД.
· На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к СУБД, расположенной на сервере, на выборку/обновление информации. Для общения используется специальный язык запросов SQL, т.е. по сети от клиента к серверу передается лишь текст запроса.
· СУБД инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на сервере.
· СУБД инициирует обращения к данным, находящимся на сервере, в результате которых на сервере осуществляется вся обработка данных и лишь результат выполнения запроса копируется на клиентский компьютер. Таким образом СУБД возвращает результат в приложение.

· Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.
В архитектуре "клиент – сервер" работают так называемые "промышленные" СУБД.
Промышленными они называются из-за того, что именно СУБД этого класса могут обеспечить работу информационных систем масштаба среднего и крупного предприятия, организации, банка. К разряду промышленных СУБД принадлежат MS SQL Server, Oracle, Gupta, Informix,
Sybase, DB2, InterBase и ряд других.
Как правило, SQL-сервер обслуживается отдельным сотрудником или группой сотрудников
(администраторы SQL-сервера). Они управляют физическими характеристиками баз данных, производят оптимизацию, настройку и переопределение различных компонентов БД, создают новые БД, изменяют существующие и т.д., а также выдают привилегии (разрешения на доступ определенного уровня к конкретным БД, SQL-серверу) различным пользователям.
Трехуровневая (трехзвенная) ("тонкий клиент" - сервер приложений - сервер базы данных).
Трехзвенная (в некоторых случаях многозвенная) архитектура представляет собой дальнейшее совершенствование технологии "клиент – сервер". Трехуровневая архитектура функционирует в
Интранет- и Интернет-сетях. Клиентская часть ("тонкий клиент"), взаимодействующая с пользователем, представляет собой HTML-страницу в Web-браузере либо Windows-приложение, взаимодействующее с Web-сервисами. Вся программная логика вынесена на сервер приложений, который обеспечивает формирование запросов к базе данных, передаваемых на выполнение серверу баз данных. Сервер приложений может быть Web-сервером или специализированной программой (например, Oracle Forms Server)
Рассмотрев архитектуру "клиент – сервер", можно заключить, что она является 2-звенной: первое звено – клиентское приложение, второе звено – сервер БД + сама БД. В трехзвенной архитектуре вся бизнес-логика (деловая логика), ранее входившая в клиентские приложения, выделяется в отдельное звено, называемое сервером приложений. При этом клиентским приложениям остается лишь пользовательский интерфейс. Так, в качестве клиентского приложения в описанном выше примере выступает Web-браузер.
Что улучшается при использовании трехзвенной архитектуры? Теперь при изменении бизнес-логики более нет необходимости изменять клиентские приложения и обновлять их у всех пользователей. Кроме того, максимально снижаются требования к аппаратуре пользователей.
Итак, в результате работа построена следующим образом:

База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (сервера сети).

СУБД располагается также на сервере сети.

Существует специально выделенный сервер приложений, на котором располагается программное обеспечение (ПО) делового анализа (бизнес-логика).

Существует множество клиентских компьютеров, на каждом из которых установлен так называемый "тонкий клиент" – клиентское приложение, реализующее интерфейс пользователя.

На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение
– тонкий клиент.
Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к ПО делового анализа, расположенному на сервере приложений.

Сервер приложений анализирует требования пользователя и формирует запросы к БД.
Для общения используется специальный язык запросов SQL, т.е. по сети от сервера приложений к серверу БД передается лишь текст запроса.

СУБД инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на сервере.

СУБД инициирует обращения к данным, находящимся на сервере, в результате которых результат выполнения запроса копируется на сервер приложений.

Сервер приложений возвращает результат в клиентское приложение (пользователю).


Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.
МОДЕЛИ ДАННЫХ
Модель данных — это абстрактное, самодостаточное, логическое определение объектов, операторов и прочих элементов, в совокупности составляющих абстрактную машину доступа к данным, с которой взаимодействует пользователь. Эти объекты позволяют моделировать структуру данных, а операторы — поведение данных.
Каждая БД и СУБД строится на основе некоторой явной или неявной модели данных. Все
СУБД, построенные на одной и той же модели данных, относят к одному типу. Например, основой реляционных СУБД является реляционная модель данных, сетевых СУБД — сетевая модель данных, иерархических СУБД — иерархическая модель данных и т.д.
СУБД используют различные модели данных:
Иерархическая модель. В иерархической модели элементы организованы в структуры, связанные между собой иерархическими или древовидными связями. Родительский элемент может иметь несколько дочерних элементов. Но у дочернего элемента может быть только один предок.
Иерархическая модель организует данные в форме дерева с иерархией родительских и дочерних сегментов. Такая модель подразумевает возможность существования одинаковых
(преимущественно дочерних) элементов. Данные здесь хранятся в серии записей с прикреплёнными к ним полями значений. Модель собирает вместе все экземпляры определённой записи в виде «типов записей» — они эквивалентны таблицам в реляционной модели, а отдельные записи — столбцам таблицы. Для создания связей между типами записей иерархическая модель использует отношения типа «родитель-потомок» вида 1:N. Это достигается путём использования древовидной структуры — она «позаимствована» из математики, как и теория множеств, используемая в реляционной модели.
Иерархические БД были популярны, начиная с конца 1960-х годов, когда компания IBM представила свою СУБД «Система управления информацией. Иерархическая схема состоит из типов записей и типов «родитель-потомок»:

Запись — это набор значений полей.

Записи одного типа группируются в типы записей.

Отношения «родитель-потомок» — это отношения вида 1:N между двумя типами записей.

Схема иерархической базы данных состоит из нескольких иерархических схем.
Сетевая модель. В сетевой модели данных у родительского элемента может быть несколько потомков, а у дочернего элемента — несколько предков. Записи в такой модели связаны списками с указателями. Иерархическая модель структурирует данные в виде древа записей, где есть один родительский элемент и несколько дочерних. Сетевая модель позволяет иметь несколько предков и потомков, формирующих решётчатую структуру.
Сетевая модель позволяет более естественно моделировать отношения между элементами.
И хотя эта модель широко применялась на практике, она так и не стала доминантной по двум основным причинам. Во-первых, компания IBM решила не отказываться от иерархической модели в расширениях для своих продуктов, таких как IMS и DL/I. Во-вторых, через некоторое время её сменила реляционная модель, предлагавшая более высокоуровневый, декларативный интерфейс.
Популярность сетевой модели совпала с популярностью иерархической модели. Некоторые данные намного естественнее моделировать с несколькими предками для одного дочернего элемента. Сетевая модель как раз и позволяла моделировать отношения «многие ко многим».
Основной элемент сетевой модели данных — набор, который состоит из типа «запись- владелец», имени набора и типа «запись-член». Запись подчинённого уровня («запись-член») может выполнять свою роль в нескольких наборах. Соответственно, поддерживается концепция нескольких родительских элементов.

Запись старшего уровня («запись-владелец») также может быть «членом» или «владельцем» в других наборах. Модель данных — это простая сеть, связи, типы пересечения записей (в IDMS они называются junction records, то есть «перекрёстные записи). А также наборы, которые могут их объединять. Таким образом, полная сеть представлена несколькими парными наборами.
В каждом из них один тип записи является «владельцем» (от него отходит «стрелка» связи), и один или более типов записи являются «членами» (на них указывает «стрелка»). Обычно в наборе существует отношение 1:М, но разрешено и отношение 1:1. Сетевая модель данных CODASYL основана на математической теории множеств.
Известные сетевые базы данных: TurboIMAGE; IDMS; Встроенная RDM; Серверная RDM.
Реляционная модель. В реляционной модели, в отличие от иерархической или сетевой, не существует физических отношений. Вся информация хранится в виде таблиц (отношений), состоящих из рядов и столбцов. А данные двух таблиц связаны общими столбцами, а не физическими ссылками или указателями. Для манипуляций с рядами данных существуют специальные операторы.
Распространённые реляционные
СУБД:
Oracle, Sybase, DB2, Ingres, Informix и MS-SQL Server.
Реляционные таблицы обладают следующими свойствами:

Все значения атомарны.

Каждый ряд уникален.

Порядок столбцов не важен.

Порядок рядов не важен.

У каждого столбца есть своё уникальное имя.
Некоторые поля могут быть определены как ключевые. Это значит, что для ускорения поиска конкретных значений будет использоваться индексация. Когда поля двух различных таблиц получают данные из одного набора, можно использовать оператор JOIN для выбора связанных записей двух таблиц, сопоставив значения полей.
Часто у полей будет одно и то же имя в обеих таблицах. Например, таблица «Заказы» может содержать пары «ID-покупателя» и «код-товара». А в таблице «Товар» могут быть пары «код- товара» и «цена». Поэтому чтобы рассчитать чек для определённого покупателя, необходимо суммировать цену всех купленных им товаров, использовав JOIN в полях «код-товара» этих двух таблиц. Такие действия можно расширить до объединения нескольких полей в нескольких таблицах.
Объект в реляционной модели определяется как позиция информации, хранимой в базе данных. Объект может быть осязаемым или неосязаемым. Примером осязаемого объекта может быть сотрудник организации, а примером неосязаемой сущности — учётная запись покупателя.
Объекты определяются атрибутами — информационным отображением свойств объекта. Эти атрибуты также известны как столбцы, а группа столбцов — как ряд. Ряд также можно определить как экземпляр объекта.
Объекты связываются отношениями, основные типы которых можно определить следующим образом:
1.
«Один к одному» - означает, что одной записи в главной таблице соответствует одна запись в подчиненной таблице.
2.
«Один ко многим» - означает, что одной записи в главной таблице может соответствовать несколько записей в подчиненной таблице.
3.
«Много к одному» - отличается от «один ко многим» направлением.
4.
«Много ко многим» - означает, что одной записи главной таблицы может соответствовать несколько записей подчиненной таблицы, и одновременно одной записи подчиненной таблицы – несколько записей главной таблицы.
В реляционной модели объекты и их отношения представлены двухмерным массивом или таблицей.

Каждая таблица представляет объект. Каждая таблица состоит из рядов и столбцов.
Отношения между объектами представлены столбцами. Каждый столбец представляет атрибут объекта. Значения столбцов выбираются из области или набора всех возможных значений.
Столбцы, которые используются для связи объектов, называются ключевыми. Есть два типа ключей — первичные и внешние.
Первичные служат для однозначного определения объекта. Внешний ключ — это первичный ключ одного объекта, существующий как атрибут в другой таблице.
Преимущества реляционной модели данных:
1.
Простота использования.
2.
Гибкость.
3.
Независимость данных.
4.
Безопасность.
5.
Простота практического применения.
6.
Слияние данных.
7.
Целостность данных.
Недостатки:
1.
Избыточность данных.
2.
Низкая производительность.
ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ
Этапы проектирования РБД.
Проектирование баз данных — процесс создания схемы базы данных и определения необходимых ограничений целостности
Основные задачи:

Обеспечение хранения в БД всей необходимой информации.

Обеспечение возможности получения данных по всем необходимым запросам.

Сокращение избыточности и дублирования данных.

Обеспечение правильности их содержания и т.д.
На этапе проектирования базы данных разработчик должен определить, из каких таблиц должна состоять база данных, какие данные нужно поместить в каждую таблицу и как связать таблицы.
Следовательно, в результате проектирования определяются логическая структура базы данных, т. е. состав реляционных таблиц, их структура и межтабличные связи. Для создания базы данных необходимо располагать описанием выбранной предметной области, охватывающим реальные объекты и процессы, а также определить все необходимые источники информации для удовлетворения предполагаемых запросов. Структура данных предметной области может отображаться ИЛМ, на основе которой легко создается реляциионная база данных.
Этапы проектирования и создания базы данных:
• построение информационно-логической модели данных предметной области;
• определение логической структуры реляционной базы данных;
• конструирование таблиц базы данных;
• создание схемы данных;
• ввод данных в таблицы (создание записей);
• разработка необходимых форм, запросов, макросов, модулей, отчетов;
• разработка пользовательского интерфейса.
Выделение информационных объектов