Привет студент

 (Лекция 3)

Архитектура БД

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

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

—    взаимодействие пользователя с БД не должно зависеть от особенностей её физической организации;

—    администратор базы данных (АБД) должен иметь возможность изменять структуру и формат данных, не оказывая влияния на пользовательские представления;

—    внутренняя структура БД не должна зависеть от таких изменений физических аспектов хранения информации, как переключение на новое устройство хранения;

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

Для удовлетворения этих потребностей архитектура большинства современных коммерческих СУБД, существующих на рынке программного обеспечения, в той или иной мере, строится на базе так называемой архитектуры ANSI—SPARC. Название произошло по названию комитета планирования стандартов и норм (Standards Planning and Requirements Committee SPARC) национального института стандартизации (American National Standard Institute— ANSI) США. Комитет признал необходимость использования трехуровневого подхода к организации БД. Этот подход отделяет пользовательские представления базы данных от её физического представления посредством создания независимого уровня, изолирующего программы от особенностей представления данных на низком уровне.

Архитектура БД представлена на рисунке 1.

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

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

ПП₁- представление 1—го пользователя, ПП_к - представление к—того пользователя

Рисунок 1 — Трехуровневая архитектура БД

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

Индивидуальное внешнее представление называют подсхемой.

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

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

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

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

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

Внешний уровень представляется внешней схемой, содержащей несколько подсхем, отображающих внешние представления различных пользователей БД. Во—первых, это представление сотрудника фирмы, выполняющего обязанности кадрового учета. Его функциями являются учет личных данных сотрудников, сведения о их приеме на работу, всех перемещениях и увольнениях. Сотрудник—кадровик представляет данные в следующем виде: каждому сотруднику присваивается табельный номер, это 5 значное целое число. Личные данные сотрудника вводятся в базу данных из следующих документов: паспорт сотрудника, диплом об образовании, договор о найме на работу. Сотрудник—кадровик создает личную карточку сотрудника, в которую кроме личных данных вводит сведения о том в какое подразделение и на какую должность принимается сотрудник. Эти данные он берет из приказов о приемах, переводах, увольнениях и отпусках. Сотрудник—кадровик также периодически формирует различные отчеты по качественному составу персонала для руководителя фирмы: список сотрудников, достигших пенсионного возраста на заданную дату, список сотрудников, имеющих более 2—х несовершеннолетних детей, список сотрудников, не имеющих высшего образования и тому подобное. Второе внешнее представление - это представление сотрудника, выполняющего функции начисления заработной платы. Он ведет учет количества отработанных дней каждого сотрудника, сведения о полагающихся сотруднику надбавках, ежемесячно осуществляет расчет заработной платы, формирует ряд отчетов, как для руководителей фирмы, так и для внешних организаций -налоговой инспекции, пенсионного фонда. Третий пользователь базы данных это руководитель фирмы, который может просматривать личные данные сотрудников, сведения о выплатах по зарплате. Четвертый внеший пользователь — это пользователь сети Интернет, который на сайте фирмы может получить следующие сведения о сотрудниках фирмы - увидеть фотографии, прочитать фамилии, имена и отчества, названия подразделений, должности, их ученые звания, степени и другую общедоступную информацию. Таким образом, можно представить, что каждый пользователь видит «свой» фрагмент данных, при этом данные могут иметь разное представление по длине, по виду отображения. Описание всех представлений пользователей дает общее описание внешнего уровня БД. Оно обычно представляется в виде технической документации (технического задания), описании входных и выходных документов, в виде схем, рисунков, словесного описания.

Концептуальный уровень базы данных рассматриваемого примера может быть отображен в виде 2—х схем, получаемых последовательно: концептуальной информационно—логической модели предметной области (ИЛМ), представляющей классы объектов (сущности) предметной области и связи между ними, и концептуальной даталогической модели базы данных (ДЛМ), отображающей описание предметной области в виде логической структуры данных в терминах выбранной модели данных. Каждая из этих схем обобщает представление всех пользователей базы данных и описывает все данные, которые должны храниться в БД, какие связи между ними существуют. Схемы могут быть получены как в бумажном виде, так и в электронном формате и являются проектной документацией. Формируют концептуальный уровень проектировщики базы данных, администратор данных и администратор базы данных. Это особая категория пользователей базы данных, её разработчики. Представление концептуального уровня БД в виде ИЛМ и ДЛМ, либо только в виде ДЛМ зависит от выбранного метода проектирования БД.

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

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

Различают логическую и физическую независимость данных.

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

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

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

Пример. Функциональная подсистема «Приемная комиссия»

1.    Внешняя схема содержит несколько внешних представлений (секретарь ПК

- ввод, изменение данных, ответственный секретарь ПК - чтение, отчеты, Web-страница с динамическим представлением хода приема документов).

2.    Концептуальная схема:

-    ER-диаграмма;

-    логическая структура БД;

3.    Внутренняя схема - скрипты, описывающие объекты БД

Отображение внешне концептуальное: получение информационной модели ПО; получение Даталогической модели БД

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

Модели данных

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

В современной трактовке термин «модель данных» обозначает инструмент моделирования. Модель базы данных (схема данных) или модель предметной области являются результатами моделирования.

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

Для реализации успешного проектирования БД необходимо для каждой модели - инструмента знать три её основных компонента:

—    набор правил, определяющих структуру данных;

—    определение типов допустимых операций с данными;

—    набор ограничений поддержки целостности данных.

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

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

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

3.    Внутренняя модель. Является результатом отображения концептуальной модели средствами языка определения данных выбранной СУБД.

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

Модели данных, как инструменты, делятся на 3 основные категории:

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

Среди объектных моделей выделяют наиболее общие типы:

— семантические модели. Их назначение - обеспечение возможности выражения семантики (смыла) предметной области. Это, например, модели типа "сущность—связь” (ER—модели — Entity Relationship model), отображающие семантику предметной области в виде ER—диаграмм;

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

—объектно—ориентированные модели. Эти модели расширяет определение класса объектов (сущности) предметной области с целью включения в определение не только свойств, описывающих состояние объекта, но и действий, которые с ним связаны, т.е. его поведение. Это, например, модели, основанные на использовании языка UML (Unified Modeling Language — унифицированного языка моделирования). Описание предметной области получают в виде различных диаграмм — диаграмм вариантов использования, диаграмм деятельности, диаграмм классов.

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

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

—    иерархическая (hierarchical data model);

—    сетевая (network data model);

—    реляционная (relational data model).

3.    Физические модели данных. Модель содержит всю информацию, необходимую для реализации конкретной БД в среде выбранной (целевой) СУБД. В физической модели в виде описания содержится информация о всех объектах БД. В описании объектов БД определяется физический формат данных, реализуются ограничения предметной области, бизнес—логика автоматизируемого предприятия, уровни доступа пользователей. Описание создается на языке определения данных (ЯОД) выбранной (целевой) СУБД. В состав ЯОД входят операторы, позволяющие создать или удалить объект БД, модифицировать его структуру. Физическая модель данных не затрагивает вопросы физического размещения данных на машинных носителях, в настоящее время это максимально реализуется средствами СУБД.

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

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

Оптимальная модель данных, полученная в результате проектирования, должна удовлетворять следующим критериям:

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

—    быть относительно простотой, легко понимаемой, как профессионалами в области разработки БД, так и обычными пользователями;

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

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

—    обладать возможностью совместного использования, не принадлежать к какому—то особому приложению или технологии;

—    быть целостной, согласованной со способами использования и управления информацией внутри предприятия;

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

—    иметь возможность представления в виде диаграмм.

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

Таблица 1 — Модели данных

Скачать лекцию: Proektirovanie-IS.-Lekciya-4.rar

Пароль на архив: privetstudent.com