Физическая организация данных
 Скачать 487.44 Kb.
|
|
Эксплуатация и сопровождение созданной АИС. Здесь можно выделить ряд задач: о В процессе эксплуатации АИС может возникнуть необходимость внесе-ния изменений в систему. Это может быть вызвано изменениями пред-метной области, появлением новых задач или выявлением существенных недостатков в АИС. Нельзя забывать о том, что все вносимые изменения должны быть документированы. о Необходимо выполнять резервное копирование данных, чтобы предот-вратить их потерю в случае серьёзного сбоя или ошибки пользователя. о Сопровождение АИС обычно включает периодические проверки выполнения системных ограничений (на объём данных и время реакции системы). В результате этих проверок удаляются устаревшие данные (если не предусмотрено автоматическое архивирование данных). Улучшение показателей производительности системы может быть достигнуто за счёт настройки СУБД, которая выполняется администратором базы данных. Теперь перейдём к более подробному обсуждению этапов проектирования БД.
Инфологический подход не содержит формальных способов моделирования реальности, но он закладывает основы методологии проектирования БД. Первой задачей инфологического проектирования является определение предметной области(ПО) системы, позволяющее изучить информационные потребности будущих пользователей. Другая задача этого этапа - анализ ПО, который призван сформировать взгляд на неё с позиций сообщества будущих пользователей БД, т.е. инфологической модели ПО. Анализ ПО выполняется проектировщиком БД с помощью специалистов в данной ПО. В основе анализа лежат документы, используемые в работе предприятия (организации), и технология работы с данными. Инфологическая модель ПО включает описание структуры и динамики ПО, характера информационных потребностей пользователей системы. Описание выполняется в терминах, понятных пользователю и независимых от реализации системы. Обратите внимание: инфологическая модель ПО не должна зависеть от модели данных, которая будет использована при создании БД. Обычно описание ПО выражается в терминах не отдельных сущностей и связей между ними, а их типов, связанных с ними ограничений целостности и тех процессов, которые приводят к переходу ПО из одного состояния в другое. Такое описание может быть представлено любым способом, допускающим однозначную интерпретацию. В простых случаях описание ПО представляется на естественном языке. В более сложных случаях используется также математический аппарат: таблицы, диаграммы, графы и т.п. Если анализ ПО выполняется несколькими специалистами, то они должны принять соглашения, которые касаются:
Этап инфологического проектирования начинается с моделирования ПО. Проектировщик разбивает ПО на ряд локальных областей (локальных представлений), каждая из которых (в идеале) включает в себя информацию, достаточную для обеспечения информационных потребностей одной группы будущих пользователей или решения отдельной задачи. Каждое локальное представление моделируется отдельно, а затем выполняется их объединение. Выбор локального представления зависит от масштабов ПО. Обычно ПО разбивается на локальные области так, чтобы каждая из них соответствовала отдельному внешнему приложению и содержала 6-7 сущностей (т.е. объектов, о которых в системе будет накапливаться информация). Таким образом, если ПО небольшая, то разбиение на локальные представления не требуется и моделирование выполняется для ПО в целом. Существуют разные подходы к инфологическому проектированию. Рассмотрим основные из них.
Этот метод реализует принцип "от задач” и применяется в том случае, когда известны функции некоторой группы лиц и/или комплекса задач, для обслуживания информационных потребностей которых создаётся рассматриваемая БД.
Предметный подход применяется в тех случаях, когда у разработчиков есть чёткое представление о самой ПО и о том, какую именно информацию они хотели бы хранить в БД, а структура запросов не определена или определена не полностью. Тогда основное внимание уделяется исследованию ПО и наиболее адекватному её отображению в БД с учётом самого широкого спектра информационных запросов к ней.
Метод "сущность-связь" (Entity-Relation, ER-method) был разработан в 1976 г. П.Ченом (Chen P.P.). Он является комбинацией двух предыдущих и обладает достоинствами обоих. ER-метод является наиболее распространённым методом проектирования БД, поэтому мы рассмотрим его подробно. • 8.3.1. Метод "сущность-связь” В предметной области необходимо выделить сущности, атрибуты и связи. Сущности, существование которых не зависит от существования других сущностей, называются базовыгми, остальные сущности - зависимыгми. Например, сущность ЛЕКЦИЯ зависит от базовых сущностейГРУППА, ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА. Для каждой сущности определяются атрибуты (свойства), которые можно условно классифицировать следующим образом:
Они позволяют однозначно распознавать экземпляры сущности. Из потенциальных ключей выбирается один первичный ключ (ПК). В качестве ПК обычно выбирается потенциальный ключ, по которому чаще происходит обращение к экземплярам сущности. Кроме того, ПК должен включать в свой состав минимально необходимое для идентификации количество атрибутов. Остальные атрибуты называются описательными и заключают в себе интересующие свойства сущности.
Спецификация атрибута состоит из его названия, типа данных, размера и описания ограничений целостности - множества значений, которые может принимать данный атрибут. Далее осуществляется спецификация связей. Под связью понимается осмысленная ассоциация между сущностями, например, СТУДЕНТ учится в ГРУППЕ, ВОДИТЕЛЬ выполняет РЕЙС и т.п. Выявляются все связи между сущностями внутри локального представления. Каждая связь именуется, для неё определяются степень, кардинальность и обязательность. Кроме спецификации связей типа "сущность - сущность", выполняется спецификация связей типа "сущность - атрибут" и "атрибут - атрибут" внутри одной сущности. Для этого надо определить зависимости между экземплярами сущностями и атрибутами, а также между атрибутами, относящимися к одному экземпляру сущности. Например, атрибут Телефоны сущностиСОТРУДНИК может быть многозначным и необязательным, т.е. связь СОТРУДНИК->Телефоныг имеет тип 1:n и является необязательной для сотрудника. А если рассмотреть атрибутыМаршрут и Стоимость сущности БИЛЕТ, то между ними есть связь 1:1, т.к. стоимость билета зависит от маршрута (пункт отправления - пункт назначения). После выявления сущностей и связей ПО строят ER-диаграмму, которая является наглядным отображением модели ПО. (Пример ER-диаграммы приведён на рис. 1.4).
При небольшом количестве локальных областей (не более пяти) объединение выполняется за один шаг. В противном случае обычно выполняют бинарное объединение. При этом проектировщик может формировать конструкции, производные по отношению к тем, которые были использованы в локальных представлениях. Цель введения подобных абст-ракций: о объединение в единое целое фрагментарных представлений о различных свойствах одной и той же сущности; о введение абстрактных понятий, удобных для решения задач системы, установление их связи с более конкретными понятиями модели; о образование классов и подклассов подобных сущностей (например, класс "изделие" и подклассы типов изделий, производимых на предприятии). При объединении локальных представлений используют три основополагающие концепции:
Например, СОТРУДНИК для отдела кадров и СОТРУДНИК для отдела закупок - это один и тот же тип сущности, возможно, с разным набором атрибутов. (Наборы атрибутов исходных сущностей при этом объединяются).
преподавателя, Фамилия студента, Оценка.
ДЕТАЛИ СОБСТВЕННОЕО ПРОИЗВОДСТВА ДЕТАЛИ ПОКУПНЫЕ СБОРОЧНЫЕ ЕДИНИЦЫ1 ПОКУПНЫЕ СБОРОЧНЫЕ ЕДИНИЦЫ1 СОБСТВЕННОЕО ПРОИЗВОДСТВА Их можно объединить так, как показано на рис. 8.2. Рис. 8.2. Использование обобщений при объединениих Это позволит упростить формализацию процессов обработки данных. На пример, оформление заказа на покупные элементы изделий в данном примере может быть описано один раз (для второго уровня иерархии). На этапе объединения необходимо выявить и устранить все противоре чия. Например, изменить одинаковые названия семантически различных сущностей или связей или несогласованные ограничения целостности на одни и те же атрибуты в разных приложениях. Устранение противоречий вызывает необходимость возврата к этапу моделирования локальных представлений с целью внесения в них соответствующих изменений. По завершении объединения результаты проектирования представляют собой концептуальную инфологическую модель ПО. Она фиксируется в виде общей ER-диаграммы предметной области. Модели локальных представлений - это внешние инфологические модели (внешние схемы). На этапе анализа ПО также решаются следующие задачи:
На этом этапе производится оценка требований к вычислительным ресурсам, необходимым для функционирования системы, выбор типа и конфигурации ЭВМ, типа и версии операционной системы (ОС). Выбор зависит от таких показателей, как: о примерный объём данных в БД; о динамика роста объёма данных; о характер запросов к данным (извлечение и обновление отдельных записей, обработка групп записей, обработка отдельных отношений или соединение отношений); о интенсивность запросов к данным по типам запросов; о требования ко времени отклика системы по типам запросов; о режим работы (интерактивный, пакетный или режим реального времени). Эта информация позволяет определить системные требования к объёму оперативной и дисковой памяти, а также функциональным возможностям ОС.
Выбор СУБД является одним из важнейших моментов в разработке проекта БД, так как он принципиальным образом влияет на процесс проектирования БД и реализации информационной системы. Теоретически при осуществлении этого выбора нужно принимать во внимание десятки факторов. Но на практике разработчики руководствуются лишь собственной интуицией и несколькими наиболее важными критериями, к которым относятся: о тип модели данных, которую поддерживает данная СУБД, адекватность модели данных структуре рассматриваемой ПО; о характеристики производительности СУБД; о запас функциональных возможностей для дальнейшего развития информационной системы; о степень оснащённости СУБД инструментарием для персонала администрирования данными; о удобство и надежность СУБД в эксплуатации; о наличие специалистов по работе с конкретной СУБД; о стоимость СУБД и дополнительного программного обеспечения. По результатам предыдущего этапа определены основные характеристики БД, такие как объём памяти и необходимая производительность. В зависимости от этого выбираются 2-3 СУБД, которые соответствуют выявленным требованиям. Например, если объём БД не превысит 100М, большинство запросов выбирает от 1 до 20 записей и время реакции системы не должно превышать 10 секунд, то следует остановить выбор на системах среднего класса, таких как Firebird, PostgreSQL, FoxPro. Для меньших по объёму БД можно выбрать Access или MySQL, а такие серьёзные СУБД как Oracle, DB/2 или Informix следует рассматривать в тех случаях, когда велик объём данных или имеются высокие требования к производительности системы. Выбранные СУБД оцениваются по степени соответствия выявленным требованиям к БД, и выбирается та система, которая лучше им соответствует.
На этапе логического проектирования инфологическая модель ПО, представленная в виде ER-диаграммы, преобразуется в логическую (концептуальную) схему БД. Решение этой задачи существенно зависит от модели данных, поддерживаемой выбранной СУБД. Результатом выполнения этапа логического проектирования являются схемы БД концептуального и внешнего уровней архитектуры, составленные на языке определения данных (DDL, Data Definition Language) выбранной СУБД. Более подробно этот этап мы рассмотрим для РМД (п. 8.9).
Основой для физического проектирования является схема БД, полученная на предыдущем этапе. Физическое проектирование заключается в увязке логической структуры БД и физической среды хранения с целью наиболее эффективного размещения данных. Решается вопрос размещения хранимых данных в пространстве памяти и выбора эффективных методов доступа к различным компонентам "физической" БД. Результаты этого этапа документируются в форме схемы хранения на языке определения данных. Принятые на этом этапе решения оказывают определяющее влияние на производительность системы. |