Методы и средства проектирования БД

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 — Модели данных, используемые при проектировании БД

Жизненный цикл БД

Поскольку база данных является основным компонентом автоматизированной информационной системы, её жизненный цикл непрерывно связан с жизненным циклом АИС, с жизненным циклом программного обеспечения АИС. Жизненный цикл АИС, в целом, определяется как период времени, который начинается с момента принятия решений о необходимости создания АИС и заканчивается завершением её полной эксплуатации. Наиболее распространены две основные модели жизненного цикла программного обеспечения: каскадная и спиральная модели. Жизненный цикл АИС, её программного обеспечения, базы данных, как правило, соответствует спиральной модели.

Рассмотрим некоторые этапы жизненного цикла БД.

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

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

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

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

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

2 Определение требований к системе. Это этап определения диапазона действия и границ разрабатываемой БД, состава её пользователей, областей применения.

Задачи этапа:

— анализ и выбор направления совершенствования объекта управления в рамках предприятия;

— установление границ исследуемой области;

— связь разрабатываемой системы с существующими на предприятии АИС;

— выбор программно—технических средств;

— определение ограничения ресурсов на разработку;

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

— определение направлений развития.

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

— посредством опроса специалистов предприятия в наиболее важных областях его деятельности;

— с помощью наблюдения за деятельностью предприятия;

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

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

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

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

На этапе сбора и анализа требований пользователей полезно ответить на следующие вопросы:

а) Что лежит в основе деятельности данного предприятия. Выявляются наиболее важные компоненты, подлежащие автоматизации. Например: подсистема «Управление персоналом» – компоненты: предприятие, отделы, организационно—кадровая структура, личная карта сотрудника, приказ; задача «Почта» – компоненты: отправитель, получатель, почтовое отделение, главпочта; задача «Занятость населения» – компоненты: отдел по трудоустройству, предприятия, учебные заведения, начисление пособий; задача «Учет кассовых операций» – компоненты: касса, бухгалтерия.

б) Как это делается? Определяется список основных процессов, происходящих на данном предприятии, в частности над компонентами. Например, задача «Почта» – обеспечивается ввод, хранение и обработка данных об отправителе, получателе и почтовом отделении. Автоматически рассчитывается сумма оплаты почтовых услуг и выдается квитанция об оплате. Каждый день составляются и выдаются на печать отчеты о принятых и выданных почтовых отправлениях; задача «Занятость населения» – сбор, накопление, обработка и передача данных о безработных, регистрация вакантных рабочих мест, заполнение карточек персонального учета, ведение истории по безработице, выдача рекомендательных писем; задача «Учет кассовых операций» – ведение журнала регистрации кассовых операций, оформление приходных и расходных, кассовых ордеров и т.п.

в) Где происходят данные процессы? Территориально определяется положение компонентов, решается вопрос оптимального распределения данных (локальная, сетевая БД, БД уровня предприятия, распределенные БД).

г) Кто выполняет эти процессы? Рассматривается организационная структура предприятия – подчинение и зависимость подразделений.

д) Когда выполняется то или иное действие? Проясняется периодичность времени осуществляемых процессов, последовательность выполнения.

е) Почему эти действия выполняются? Определяется мотивация деятельности предприятия. Например: достижение наилучших соотношений "затраты – удобства" для клиентов; обеспечение успешной деятельности персонала; получение приемлемой прибыли; повышение доходов при автоматической обработке данных; получение более эффективного управления.

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

— название задачи;

— организационная структура предприятия;

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

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

— функции, которые должны быть автоматизированы в рамках данной задачи;

— формализованное описание предметной области – классы объектов (сущности) и связи между ними;

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

— требования к программному обеспечению АИС;

— требования к техническому обеспечению АИС;

— сроки ввода в эксплуатацию АИС.

4 Этап проектирования (моделирования) БД. Это процесс создания проекта БД, предназначенной для поддержки функционирования АИС. Основные действия, производимые на этапе проектирования, это отображение словесного и естественного описания предметной области в схему внутренней модели БД.

Основными целями проектирования БД являются:

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

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

— разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы – например, ко времени реакции системы.

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

— максимальное время, отпущенное на проект;

— максимальное количество денег, которое может быть потрачено;

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

Проектирование БД охватывает 3 основные области:

— проектирование конкретных объектов, которые будут реализованы в БД (домены, таблицы, хранимые процедуры, триггеры, индексы);

— проектирование конкретных экранных форм, отчетов, программ, которые будут сопровождать данные в БД, и обеспечивать выполнение запросов к ним;

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

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

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

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

7 Создание БД. Этап физической реализации БД в среде выбранной СУБД. Включает в себя следующее:

— компиляцию команд ЯОД, описывающих БД и структуры объектов БД — создание пустой схемы БД;

— реализацию прикладных программ с помощью языков программирования (многие СУБД имеют встроенный язык);

— реализацию элементов прикладных программ на языке манипулирования данными (ЯМД) СУБД;

— разработку экранных форм для ввода—вывода информации, отчетов;

— реализацию мероприятий по защите данных, как правило, средствами ЯОД и ЯМД СУБД.

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

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

По завершении этого этапа БД готова к эксплуатации.

10 Эксплуатация и сопровождение. На данном этапе проводится наблюдение за системой и поддержка её нормального функционирования. При этом выполняют следующие виды работ:

— контроль производительности системы. Если она падает, возможна дополнительная настройка или реорганизация БД (денормализация), оптимизация SQL запросов, создание дополнительных объектов БД (индексов);

— сопровождение и модернизация, в случае необходимости, элементов прикладных программ на языке манипулирования данными (ЯМД) СУБД;

— администрирование БД: проверка эффективности системы блокировок в параллельных процессах; осуществление мониторинга работы системы; создание резервных копий БД и т.п.

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