Пользовательские требования. 1 страница

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

Правовые – заключаются в определении со стороны собственника базы данных прав на определение правил обработки, охраны информационных ресурсов (базы данных) и доступа к ним.

Технологические требования общие для централизованных и распределенных баз данных.

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

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

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

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

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

4.2. Этапы жизненного цикла базы данных

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

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

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

На первом этапе предпроектной стадии проводится системный анализ автоматизируемого объекта. Основными задачами анализа являются:

– выявление недостатков существующей информационной системы;

– определение потребности в новой информационной системе;

– обоснование экономической целесообразности проектирования;

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

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

Собранные данные анализируются. На основе результатов анализа существующей информационной системы составляется «Технико-экономическое обоснование проекта» сзаключением о необходимости и экономической целесообразности создания базы данных.

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

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

– будет ли это архитектура "файл-сервер", или "клиент-сервер";

– будет ли это 3-уровневая архитектура со слоями: сервер, программное обеспечение промежуточного слоя (сервер приложений), клиентское программное обеспечение;

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

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

– будут ли для достижения необходимой производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).

Все рекомендации излагаются в документе «Техническое задание на проектирование».

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

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

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

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

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

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

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

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

Стадия внедрения проекта завершается приемно-сдаточными испытаниями и сдачей базы данных в промышленную эксплуатацию.

Эксплуатация и сопровождение базы данных. Эффективная повседневная эксплуатация базы данных поддерживается путем ее администрирования.

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

4.3. Этапы моделирования баз данных

Моделирование базы данных состоит в построении комплекса взаимосвязанных моделей данных и выполняется в соответствии с трехуровневой архитектурой СУБД, принятой в 1978г. комитетом по стандартизации ANSI/SPARC (ANSI – Национальный институт стандартизации США; SPARC – Комитет планирования стандартов и меры). Архитектура включает в себя концептуальный, внутренний и внешний уровни.

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

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

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

Модели базы данных строятся поэтапно в соответствии с трехуровневой архитектурой СУБД, как показано на рис. 4.1.

.

Рис. 4.1. Этапы моделирования баз данных.

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

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

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

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

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

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

Изменения в концептуальной модели должны отражаться на внутренней модели,

Рис.4.2. Пример соотношения между концептуальной моделью и внешними моделями.

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

4.4. Инфологическая модель «Сущность-связь»

Основные понятия

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

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

Сущность имеет тип и экземпляры. Типом является название сущности, отличающее одну сущность от другой, например, ГОРОДА. Экземпляр представляет собой конкретное значение этой сущности, например, г. Полоцк Витебской области.

Атрибут – поименованная характеристика сущности. В реляционной таблице атрибуту соответствует поле. Имя атрибута для конкретной сущности должно быть уникальным, но может быть одинаковым для различного типа сущностей. Примерами атрибутов для сущности ГОРОДА могут быть: название города, код АМТС (автоматической междугородной или международной телефонной связи), административное значение (областной или районный центр), расстояние до ближайшей железнодорожной станции.

Атрибут сам может выступать в качестве сущности. Примером может служить сущность КОДЫ АМТС с атрибутами: код АМТС, название города, страна.

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

Связь – ассоциирование двух или более сущностей.

Типы связей

Различают следующие типы связей между сущностями:

– один к одному (1:1);

– один ко многим (1:М);

– многие ко многим (М:М).

Связь один к одному обозначает, что в каждый момент времени одному экземпляру сущности A соответствует один и только один экземпляр сущности B и наоборот.

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

Связь многие ко многим, предполагает, что в каждый момент времени одному экземпляру сущности A соответствует ноль, один или более экземпляров сущности B, и наоборот – каждому экземпляру сущности B соответствует ноль, один или более экземпляров сущности A.

ER- диаграммы

Инструментом графического представления инфологических моделей является язык ER-диаграмм (Entity-Relationship – сущность-связь).

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

Пусть модель описывает предметную область, отражающую командировки сотрудников отдела. Все необходимые для включения в базу данных сведения, содержатся в сущностях, состав и атрибуты которых приведены в табл. 4.1.

Таблица 4.1. Сущности и атрибуты инфологической модели

Сущности	Атрибуты
СОТРУДНИКИ	Фамилия (Фам), номер личного дела (НЛД), код ВУЗа (ВУЗ)
ЛИЧНОЕ ДЕЛО	Номер личного дела, фамилия, характеристика 1 (Хар1) … характеристика N (ХарN)
КОМАНДИРОВКИ	Фамилия, город, расходы
ВУЗЫ	Код Вуза, наименование Вуза (НВ), код специальности (КС)
СПЕЦИАЛЬНОСТИ	Код специальности, наименование специальности (НС)

В столбце «Атрибуты» табл. 4.1. курсивом показаны ключи.

Используя язык ER-диаграмм, построим инфологическую модель (рис.4.3.).

Рис. 4.3. ER-диаграмма инфологической модели базы данных.

Изображенная на рис. 4.3. ER-диаграмма удовлетворяет следующим условиям:

1. Сотрудники отдела могут ездить в разные города;

2. Каждый сотрудник может несколько раз быть в одном и том же городе;

3. В один и тот же город могут ездить разные сотрудники;

4. Любая специальность может быть в любом вузе.

Преобразование ER- модели в реляционную модель данных

Процесс получения реляционной схемы базы данных из ER-диаграммы осуществляется по следующим правилам:

1. Каждая простая сущность превращается в отношение (таблицу). Простая сущность – это сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем отношения.

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

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

4. Атрибуты, имеющие типы связи M:1 (и 1:1) становятся внешними ключами.

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

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

а) все подтипы размещаются в одной таблице;

б) для каждого подтипа строится отдельная таблица.

Полученные таблицы должны удовлетворять требованиям:

– каждая таблица состоит из однотипных строк и имеет уникальное имя;

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

– таблицы имеют фиксированное число полей (столбцов, атрибутов) и значений полей;

– в каждой таблице на пересечении строки и столбца должно находиться только одно значение или ничего;

– в поименованных столбцах (полях) таблицы размещаются однородные значения данных.

Важным этапом проектирования реляционной базы данных является обеспечение реляционной целостности данных.

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

Существуют ограничения по условию целостности данных:

– ограничение по сущностям – каждая строка должна отличаться от остальных ее строк значением хотя бы одного столбца;

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

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

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

2. Не допускается удаление записи из главной таблицы, если существуют связанные с ней записи в подчиненной таблице.

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

4.5. Нормализация таблиц

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

– избыточность полей в таблицах;

– состав первичных ключей;

– нежелательные функциональные зависимости между полями;

– дублирование данных;

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

– время выполнения запросов на выборку данных

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

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

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

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

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

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

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

Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.

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

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

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

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

Четвертая нормальная форма (4НФ) является частным случаем 5НФ, когда полная декомпозиция должна быть соединением ровно двух проекций.

Тема 5. Системы управления базами данных

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

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

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

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

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

– трудности моделирования предметной области;

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

– нечувствительность средств настройки СУБД общего назначения;

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

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

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

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

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

По мощности выделяют настольные и корпоративные СУБД. Настольные системы ориентированы на конечных пользователей (специалистов в конкретной предметной области). Они не предъявляют высоких требований к техническим средствам, отличаются низкой стоимостью.

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

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

5.2. Языковые и программные средства СУБД

Языковые средства СУБД используются для выполнения функций:

описания представления базы данных;

выполнения операций манипулирования данными;

управления базой данных.

Первая из этих функций обеспечивается языком описания (определения) данных (ЯОД) – Shema Definition Language. Описание базы данных средствами ЯОД называется схемой базы данных.

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

Язык манипулирования данными (ЯМД) – Shema Manipulation Language содержит набор операторов манипулирования данными, позволяющих заносить данные в базу данных, удалять, модифицировать их и выбирать запрашиваемую информацию из базы данных.

В настоящее время имеются многочисленные примеры языков СУБД, объединяющих возможности описания данных и манипулирования данными в единых синтаксических рамках. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с базой данных, начиная от ее создания, и обеспечивающий пользовательский интерфейс с базами данных. Наиболее популярным и стандартным для реляционных СУБД является язык SQL (Structured Query Language), разработанный фирмой IBM. SQL положен в основу языка OQL (Object Query Language), который предназначен для поддержки объектных моделей.

Дата добавления: 2014-11-06