Характеристика современных автоматизированных информационных систем

“Распределение по отделам”, которой назначим атрибут “Отработано часов”, после чего создадим две новых связи типа 1:М.

5.Удаление множественных атрибутов. Множественными называют атрибуты, которые могут иметь одновременно несколько значений для одного и того же экземпляра сущности. Если в концептуальной модели присутствует множественный атрибут, его следует преобразовать путем определения новой сущности. Например, для отображения ситуации, когда одно и то же отделение компании имеет несколько телефонных номеров, в концептуальной модели был определен множественный атрибут “Телефонный номер”, относящийся к сущности “Отделение компании”. Этот множественный атрибут следует удалить, определив новую сущность “Телефон”, имеющую единственный простой атрибут “Телефонный номер”, и создав новую связь типа 1.

6.Перепроверка связей типа 1:1. В процессе определения сущностей могли быть созданы две различные сущности, которые на самом деле представляют один и тот же объект в предметной области приложения. Например, могли быть созданы две сущности “Отдел” и “Департамент”, которые на самом деле представляют один и тот же тип объекта. Другими словами, имя “Отдел” является синонимом имени “Департамент”. В подобном случае следует объединить эти две сущности в одну. Если первичные ключи объединяемых сущностей различны, выберите один из них в качестве первичного, а другой укажите как альтернативный ключ.

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

При устранении избыточности доступа большое значение имеют временные показатели. Например, рассмотрим ситуацию, когда необходимо смоделировать связи между сущностями “Мужчина”, “Женщина” и “Ребенок”. Очевидно, что между сущностями “Мужчина” и “Ребенок” имеется два пути доступа: один – через непосредственную связь “Является отцом” и другой – через связи “Женат на” и “Является матерью”. На первый взгляд кажется, что связь “Является отцом” избыточна. Однако это утверждение может оказаться ошибочным по двум причинам. Во-первых, отец может иметь детей от предыдущего брака, а мы моделируем только текущий брак отца (через связь 1:1). Во-вторых, отец и мать могут быть вообще не женаты или отец может быть женат на женщине, которая не является матерью данного ребенка (или же мать может быть замужем за мужчиной, который не является отцом ребенка). Поэтому все существующие взаимоотношения не могут быть смоделированы без использования связи типа “Является отцом” (рис. 10).

Физическое проектирование

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

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

Методология физического проектирования баз данных включает четыре основных этапа:

1. Разработка таблиц базы данных и установка необходимых ограничений целостности данных.

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

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

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

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

Недостатки СУБД

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

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

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

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

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

1 Распределенные СУБД

Основные концепции

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

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

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

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

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

приложения, которые не требуют доступа к данным на других сайтах (локальные приложения), и приложения, которые требуют подобного

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

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

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

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

•фрагменты и их реплики распределены по различным сайтам;

•сайты связаны между собой сетевыми соединениями;

•работа с данными на каждом сайте управляется СУБД;

•СУБД на каждом сайте способна поддерживать автономную работу локальных приложений;

•СУБД каждого сайта поддерживает хотя бы одно глобальное приложение.

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

Преимущества и недостатки РСУБД

Системы с распределенными базами данных имеют преимущества перед традиционными централизованными системами баз данных:

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

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

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

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

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

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

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

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