Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow Базы данных: проектирование

ФИЗИЧЕСКОЕ МОДЕЛИРОВАНИЕ

По итогам изучения материала данной главы студент должен:

знать

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

уметь

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

владеть

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

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

Особенности построения физической модели базы данных

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

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

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

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

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

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

image314

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


Таблица 5.1

Соглашение имен базы данных

п/п

Объект

Пре

фикс

Имя

Пост

фикс

Описание

1

Таблица

t_

functional

name>

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

2

Таблица

Г

< functional name>

cl

Табл и цы - класс 11ф и каторы именуются по принципу обычной таблицы, но с добавлением соответствующего постфикса

3

Таблица

t_

<functional

name>

_rel

Таблицы-связки именуются по принципу обычной таблицы с добавлением соответствующего постфикса

4

Поле

(колонка)

f_

<functional

name>

Поля (колонки) таблиц именуются в латинском алфавите с использованием префикса обозначения поля и функционального имени, соответствующего логической модели



п/п

Объект

Пре

фикс

Имя

Пост

фикс

Описание

5

Поле

(колонка)

id

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

6

Поле

(колонка)

full name

Поле обозначения полного наименования представляется фиксированным названием без использования префиксов и постфиксов

...

...

...

...

...

7

Первичный ключ

РК_

<table name>

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

8

Внешний

ключ

FK_

abbreviation

tables>_<relation

field>

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

...

...

...

...

...

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

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

  • • таблица — table — объект, ассоциированный с сущностью логической модели, где хранятся данные, сформированные и используемые пользователем;
  • • поле (колонка) — field (column) — объект, ассоциированный с атрибутом логической модели базы данных, описывающий отдельное свойство хранимых экземпляров данных;
  • • тип данных (домен) — datatype (domain) — объект базы данных, представляемый производным типом данных, определяемым на основании типов, имеющихся в базе данных;

  • • умолчание — default — объект, идентичный аналогичному объекту логической модели, определяющий значение, которое должно быть сохранено в поле (колонке), если иное не было определено пользователем или командой внесения данных (insert, update);
  • • ограничение — check — объект, описывающий логическое правило проверки значения для поля (колонки) таблицы, представляющегося обычно свойством поля (колонки), а не самостоятельным объектом;
  • • первичный ключ — primary key — объект, представляемый свойством таблицы, где содержится перечень полей (колонок), используемых для однозначной идентификации экземпляра данных;
  • • внешний ключ — foreign key — объект, представляемый свойством таблицы, где содержится условие связи между родительской и дочерней таблицами с указанием полей связей;
  • • представление (производные таблицы) — view — объект базы данных, используемый для определения правила статичной выборки данных из таблиц, применяемый с целью ограничений доступа к экземплярам данных и реализации стандартных информационных потребностей;
  • • хранимая процедура — stored procedure — объект базы данных, представляемый логически законченным программным модулем на языке программирования СУБД, который выполняется по вызову пользователя или другой процедуры;
  • • триггер — trigger — объект базы данных, представляемый логически законченным программным модулем на языке программирования СУБД, который выполняется при наступлении определенных условий в результате реализации команд обновления данных (insert, update, delete);
  • • табличное пространство — tablespace — объект базы данных, где размещаются таблицы с целью их разделения по факторным признакам и обеспечения высокой скорости обработки данных.

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

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

Таблица 5.2

Описание первичных ключей

п/п

Таблица

Поле —

первичный ключ

Максимальное

значение

Количественная

изменчивость

Периодичность

изменений

1

entity 1

idl

500

+ 10

Ежедневно

2

entity2

id2

100

±50

Ежемесячно

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

Размерность = тах(РК) + /Ки(РК)/ • Кпи, (5.1)

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

В итоге получается, что через пять лет максимальное значение для первичного ключа "id 1" станет равным 500 + 10 • (365 * 5) = 18 750, а для первичного ключа "id2" — 100 + 50 • (12 • 5) = 3100. Полученные значения позволяют говорить о необходимости использования типа данных "integer", диапазон значений которого от 0 до 65 536 или, при использовании отрицательных значений, от -32 767 до 32 768.

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

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

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

image315

Рис. 5.2. Структурирование файла базы данных

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

image316

Рис. 53. Структура страниц экстента


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

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

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

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

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

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

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

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

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

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

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

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

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

 
Если Вы заметили ошибку в тексте выделите слово и нажмите Shift + Enter
< Предыдущая   СОДЕРЖАНИЕ   Следующая >
 

Популярные страницы