ОРГАНИЗАЦИЯ БАЗ ДАННЫХ И ЗНАНИЙ ТЕМА 6 ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ. ИНФОЛОГИЧЕСКАЯ, ДАТАЛОГИЧЕСКАЯ, ФИЗИЧЕСКАЯ МОДЕЛИ ДАННЫХ.

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

Этапы жизненного цикла приложения базы данных показаны на рисунке:

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

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

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

КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ сущности атрибуты связи Представление аналитика ЛОГИЧЕСКИЙ УРОВЕНЬ записи элементы данных связи между записями Представление программиста ФИЗИЧЕСКИЙ УРОВЕНЬ группирование данных индексы методы доступа Представление администратора

Цель концептуального (семантического моделирования) – обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в базе данных. С помощью этого вида моделирования решаются 4 основные задачи: наглядное представление системы в целом (для разработчиков и пользователей!); документирование создаваемой системы в строгом формате; создание основы для логического проектирования базы данных; создание единой среды разработки (framework) для разнообразных приложений. Основными конструктивными элементами семантических моделей являются сущности (категории классификации данных), их свойства (атрибуты) и связи между сущностями.

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

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

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

Концептуальное проектирование базы данных 1. Создание локальной концептуальной модели данных исходя из представлений о предметной области каждого из типов пользователей. 2. Определение типов сущностей. 3. Определение типов связей. 4. Определение атрибутов и связывание их с типами сущностей и связей. 5. Определение доменов атрибутов. Определение атрибутов, являющихся потенциальными и первичными ключами. Обоснование необходимости использования понятий расширенного моделирования (необязательный этап). 6. Проверка модели на отсутствие избыточности. 7. Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям. 8. Обсуждение локальных концептуальных моделей данных с конечными пользователями.

Логическое проектирование базы данных (для реляционной модели) 1. Создание и проверка локальной логической модели данных на основе представления о предметной области каждого из типов пользователей. 2. Устранение особенностей локальной логической модели, несовместимых с реляционной моделью (необязательный этап). 3. Определение набора отношений исходя из структуры локальной логической модели данных. 4. Проверка отношений с помощью правил нормализации. 5. Проверка соответствия отношений требованиям пользовательских транзакций. 6. Определение требований поддержки целостности данных. 7. Обсуждение разработанных локальных логических моделей данных с конечными пользователями. 8. Создание и проверка глобальной логической модели данных. 9. Слияние локальных логических моделей данных в единую глобальную модель данных. 10. Проверка глобальной логической модели данных. 11. Проверка возможностей расширения модели в будущем. 12. Обсуждение глобальной логической модели данных с пользователями.

Физическое проектирование базы данных (с использованием реляционной СУБД) 1. Перенос глобальной логической модели данных в среду целевой СУБД. 2. Проектирование базовых отношений в среде целевой СУБД. 3. Проектирование отношений, содержащих производные данные. 4. Реализация ограничений предметной области. 5. Проектирование физического представления базы данных. 6. Анализ транзакций. 7. Выбор файловой структуры. 8. Определение индексов. 9. Определение требований к дисковой памяти. 10. Разработка пользовательских представлений. 11. Разработка механизмов защиты. 12. Анализ необходимости введения контролируемой избыточности. 13. Организация мониторинга и настройка функционирования операционной системы.

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

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

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

Этап 1.1. Определение типов сущностей Цель. Определение основных типов сущностей, которые требуются для контретного представления. Первый этап создания локальной концептуальной модели данных состоит в определении основных объектов, которые могут интересовать пользователя. Эти объекты являются типами сущностей, входящих в модель. Один из методов идентификации сущностей состоит в следующем: a.Осуществляется изучение спецификаций по выполнению конкретных функций пользователя на данном предприятии. b.Из этих спецификаций следует извлечь все используемые в них существительные или сочетания существительного и прилагательного (например, "табельный номер", "фамилия работника", "номер объекта недвижимости", "адрес объекта недвижимости", "арендная плата", "количество комнат"). c.Затем среди них выбираются самые значимые объекты (категории работников, направления деятельности) или важные концепции и исключаются все существительные, которые просто определяют другие объекты. Например, такие свойства, как "табельный номер" и "фамилия работника", могут быть объединены в сводном объекте под названием "работник (staff), тогда как свойства "номер объекта недвижимости", "адрес объекта недвижимости", "арендная плата" и "количество комнат" можно объединить в сущности под названием "объект недвижимости" (PropertyForRent). Альтернативный способ идентификации сущностей состоит в поиске объектов, которые существуют независимо от других.

Документирование типов сущностей. После выделения каждой сущности ей следует присвоить определенное осмысленное имя, которое обязательно должно быть понятно пользователям. Этап 1.2. Определение типов связей Цель. Определение важнейших типов связей, существующих между сущностями, выделенными на этапе 1.1. После выделения сущностей следующим этапом разработки становится установление всех существующих между ними связей. Работа проектировщика существенно упрощается, если есть возможность изучить структуру сложной системы с помощью схемы, а не анализировать подробные текстовые описания спецификаций требований пользователей. Для представления сущностей и связей между ними обычно используются диаграммы "сущность-связь" (ER- диаграммы). Рекомендуется предусмотреть самое широкое использование ER-диаграмм на всех этапах проектирования базы данных.

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

Этап 1.3. Определение атрибутов и связывание их с типами сущностей и связей Цель. Связывание атрибутов с соответствующими типами сущностей или связей. На следующем этапе предлагаемой методологии необходимо выявить все данные, описывающие сущности и связи, выделенные в создаваемой модели базы данных. Воспользуемся тем же методом, который применялся для идентификации сущностей. Для этого: выберем все существительные и содержащие их фразы, присутствующие в спецификациях требований пользователей; выбранное существительное представляет атрибут в том случае, если оно описывает свойство, качество, идентификатор или характеристику некоторой сущности или связи. Важно отметить, что каждый атрибут может быть либо простым, либо составным. Составные атрибуты представляют собой набор простых атрибутов.

Атрибуты могут подразделяться не только на простые или составные, но и рассматриваться как однозначные или многозначные. Чаще всего встречаются однозначные атрибуты, но при определенных обстоятельствах могут также встретиться и многозначные атрибуты; иными словами, атрибуты, которые включают несколько значений, соответствующих одному экземпляру сущности. Например, атрибут telNo (номер телефона) сущности Client может рассматриваться как многозначный атрибут, поскольку клиент может иметь несколько номеров телефонов. Атрибуты, значения которых могут быть установлены с помощью значений других атрибутов, называются производными. Примерами производных атрибутов являются следующие: возраст сотрудника компании; количество объектов недвижимости, которыми управляет сотрудник данной компании; задаток, внесенный при заключении договора аренды (который равен удвоенному значению ежемесячной арендной платы).