Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow ОСНОВЫ ИСПОЛЬЗОВАНИЯ И ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ
Посмотреть оригинал

б КОНЦЕПТУАЛЬНОЕ И ДАТАЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ

Необходимость концептуального проектирования

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

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

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

Желательно, чтобы язык спецификации ИЛМ был одинаково применим как при ручном, так и при автоматизированном проектировании. Для этого он должен:

  • 1) быть вычисляемым, т.е. восприниматься и обрабатываться компьютером;
  • 2) использовать удобный пользователю интерфейс, в частности графический интерфейс;
  • 3) быть независимым от оборудования и других ресурсов, подверженных частым изменениям;
  • 4) использовать средства тестирования ИЛМ, а также иметь аппарат для генерации структуры БД после завершения спецификации ИЛМ.

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

ИЛМ включает в себя ряд компонентов (рис. 6.1).

Компоненты ИЛМ

Рис. 6.1. Компоненты ИЛМ

Основным компонентом является описание объектов предметной области и связей между ними.

Описание предметной области всегда представляется с помощью какой-либо знаковой системы. Поэтому в ИЛМ отражаются не только отношения, присущие предметной области, но и лингвистические отношения, обусловленные особенностями отображения ПО в языковой среде. Поэтому нужно учитывать такие лингвистические категории, как «синонимия», «омонимия», «изоморфизм» и др.

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

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

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

Граф взаимосвязи показателей

Рис. 6.2. Граф взаимосвязи показателей

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

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

Для полей чаще всего используются следующие виды ограничений.

  • 1. Тип и формат поля.
  • 2. Задание диапазона значений. Значения диапазона и его тип зависят от особенностей ПО.
  • 3. Признак непустого поля. Характеризует недопустимость пустого значения поля в БД. Например, в отношении, содержащем сведения о сотрудниках, поля «фамилия», «имя»,

«отчество», «оклад» должны обязательно иметь какое-то значение, а у поля «ученая степень» значение может отсутствовать.

4. Задание домена. Поле может принимать значение из заданного множества значений. Например, значением поля «пол» может быть либо «мужской», либо «женский». Значением поля «должность» для профессорско-пренодавательского состава может быть одно из следующих значений: «ассистент», «старший преподаватель», «доцент», «профессор». Домен необязательно должен определяться перечислением входящих в него значений.

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

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

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

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

Рассмотренные выше ограничения определяли проверку значения поля вне зависимости от того, вводится ли это значение впервые или корректируются имеющиеся в БД значения. Ограничения, которые используются только при проверке допустимости корректировки, называются ограничениями перехода. Например, если в БД имеется поле «возраст сотрудника», то при корректировке значение этого поля может только увеличиваться. Если в БД хранится поле

«год рождения», то следует запретить возможность корректировать это поле.

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

В качестве примера ограничений, относящихся ко всей таблице, можно привести следующий. Предположим, что фонд заработной платы формируется исходя из величины средней зарплаты одного сотрудника и эта величина равна JVpy6. Тогда в качестве ограничения целостности таблицы может быть задано условие, указывающее, что среднее значение поля «оклад» должно быть не большей. Примерами ограничения целостности, которыми проверяют соотношения между строками одной таблицы, являются следующие: 1) нельзя быть родителем и ребенком одного и того же человека; 2) год рождения родителя должен быть меньше, чем год рождения ребенка. Первый из приведенных примеров является частным случаем более общего ограничения на отсутствие циклов.

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

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

Разновидностью ограничения целостности связи является ограничение связи по существованию, заключающееся в том, что для существования объекта в отношении R1 необходимо, чтобы он был связан с объектом в отношении R2. Например, при приеме на работу каждый из работающих должен быть зачислен в какой-то отдел, и соответствующая запись в таблице «Кадры» в поле «отдел» должна иметь значение, совпадающее с одним из значений соответствующего поля в таблице «Отделы».

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

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

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

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

Запрет на обновление может относиться не только к отдельному полю, но и ко всей строке (записи) и к таблице.

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

В этом примере наблюдается также ограничение связи по существованию между таблицами «Поощрения» и «Сотрудники»: табельный номер в таблице «Поощрения» должен обязательно присутствовать в таблице «Сотрудники»; при удалении строки из таблицы «Сотрудники» все связанные с ней строки в таблице «Поощрения» должны быть также удалены.

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

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

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

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

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

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

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

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

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

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

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

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

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

 
Посмотреть оригинал
< Предыдущая   СОДЕРЖАНИЕ   Следующая >
 

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