Тема 7.

Проектирование фактографических бах данных.

Вопросы:

• Система представления данных в информационных системах.

• Цели и подходы к проектированию баз данных.

• Инфологичекое проектирование баз данных.

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

БД

Физическая модель

Датологическая модель

Инфологическая модель

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

2. Процесс проектирования базы данных представляет собой преобразование описания предметной области в схему внутренней модели базы данных. Этот процесс представляется последовательностью более простых, обычно итеративных, процессов проектирования промежуточных моделей данных, т. е. последовательностью проектирования моделей уровня абстрагирования. Основными уровнями абстрагирования являются: 1. Информационный. 2. Внешний. 3. Концептуальный. 4. Внутренний.

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

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

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

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

Основная цель проектирования баз данных — это сокращение избыточности хранимых данных, а следовательно, экономия объемов памяти, уменьшения затрат на обновление избыточных копий и устранения возможности возникновения противоречий из за хранения в разных местах сведений об одном и том же объекте. Идеальный проект базы данных — это каждый факт в одном месте. При проектировании фактографических баз данных, решаются две основные проблемы: 1. Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, что бы это отображение не противоречило семантики предметной области, и было по возможности эффективным. Часто эту проблему называют проблемой логического проектирования. 2. Как обеспечить эффективность выполнения запросов в базе данных, т. е. каким образом использую особенности конкретной СУБД расположить данные во внешней памяти, создание каких дополнительных структур потребовать. Это проблему, называют проблемой физического проектирования баз данных. Проектирование баз данных может быть разбита на информационное проектирование, датологическое. Датологическое разбивается на логическое и физическое. В зависимости от этапов проектирования различают концептуальную инфлогическую модель и концептуальную даталогическую модель, внешнюю инфлогическую модель, и внешнюю даталогическую модель. На этапе физического проектирования получается внутренняя даталогическая модель. Задачей инфлогоческого моделирования является получение семантических моделей, отражающих информационное содержание конкретной предметной области. На этом этапе выполняется восприятие реальной действительности абстрагирования и описания предметной области. Затем, знания о предметной области представляются в какой либо языковой системе. Затем, разрабатывается концептуальная инфлогическая модель. Здесь описывается информация, требуемая для каждой задачи, и запросы к базе данных. Каждый запрос соотносится с определенным фрагментом предметной области. После этого формируется описание внешних инфлогических моделей. Они отражают сущности предметной области, связи между ними, характеристики связей и сущностей, но эти описания не зависят от методов представления данных к конкретной СУБД. Задача логического проектирования — это организация данных, выделенных на предыдущем этапе форму, принятую в выбранной конкретной СУБД. Иными словами, требуется трансформировать схему концептуальной модели и схему внешних моделей данных, пользуясь только теми типами моделей, которые поддерживаются выбранной СУБД. Задачами физического проектирования, является выбор рациональной структуры хранения данных и методов доступа к ним, исходя из методов и средств, представляемых конкретной СУБД. В результате получается внутренняя даталогическая модель данных.

3. Исходя из важности адекватного отображения предметной области, к моделям данных предъявляют ряд требований, и выдвигают комплекс критериев для оценки их оптимальности. Как правило это следующие критерии: 1. Структурная достоверность, т. е. соответствие способа определения и организации информации в данной предметной области. 2. Простота — это легкость понимания модели разработчика, и пользователей информационной системы. 3. Выразительность. Это способность представлять отличия между разными типами данных, связей между данными и ограничения. 4. Отсутствие избыточности. 5. Готовность к совместному использованию. Это отсутствие принадлежности к какому либо приложению или технологии. 6. Расширяемость — способность изменяться с целью включения новых требований с минимальным влиянием несуществующих пользователей. 7. Целостность — это согласованность по способам использования и управления информацией. Инфологическая модель представляется как правило моделью сущность-связь. Это модель используются для нахождения наиболее естественных для человека способов сбора и представления информации. Известны следующие средства создания моделей: 1. Семантические сети. 2. Язык инфлогического моделирования. 3. ER- диаграмма.

В настоящее время, наибольшую популярность из за доступности, наглядности и компактности приобрел подход моделирования сущность-связь ( ER- моделирование). Эта модель разработана 1976 году. Основными её элементами являются: сущности, атрибуты, связи. Сущность — это различимое множество объектов ( экземпляров сущности), реального мира с одинаковым набором атрибутов. На диаграммах сущность изображается прямоугольником, а внутри наименование сущности. Сущность идентифицируется именем и списком свойств ( атрибутов). Атрибут — это неотъемлемое свойство сущности или связи. Значения атрибута составляют основную часть сведений, хранящихся в базе данных. На диаграммах атрибуты изображаются овалом, а внутри пишется их имя. С понятием атрибута тесно связано понятие «домен». Домен — это множество значений, которые может принимать атрибут. Атрибуты делятся на простые, составные, однозначные, многозначные и производные. Вопрос однозначной идентификации экземпляра сущности связан с понятием ключа. Ключ — это минимальный набор атрибутов, под значением которым можно идентифицировать экземпляр сущности.

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

Степень связи — это количество сущностей, которые охвачены данной связью. Если связь определена между двумя сущностями, то её степень 2, и она является бинарной. Связь между тремя сущностями называется тринарной. Унарная связь — это когда сущность замкнута сама на себе ( рекурсия). При построении инфологической модели, на сущности могут накладываться ограничения, отражающие семантику предметной области. С этими ограничениями связано понятие показателя координальности связи. Показатель координальности указывает количественное соотношение экземпляров сущности для каждой связи. Классическими признаны следующие показатели: 1. Один к одному. В каждый момент времени каждому экземпляру сущности А соответствие не более одного экземпляра сущности В. 2. Связь один ко многим. Каждому экземпляру сущности А соответствует 0, 1, или несколько представителей сущности В. 3. Связь многие ко многим. Каждому экземпляру сущности А соответствует 0, 1, или несколько представителей сущности В, и каждому экземпляру сущности В соответствует 0, 1 или несколько представителей сущности А.

Вопросы:

• Логическое проектирование. Выбор системы управления базами данных.

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

• Стадии и этапы проектирования фактографической базы данных.

1. Важным этапом проектирования базы данных является выбор СУБД. Основная цель при подборе СУБД — это выбор системы, удовлетворяющий текущим и прогнозируемым требованиям организации, при оптимальном уровне затрат. Затраты могут включать расходы на приобретение СУБД и дополнительного аппаратного и программного обеспечения. Кроме этого, сюда следует включать расходы связанные с переходом на новую систему и необходимостью переобучения персонала. В общем виде, процесс выбора СУБД включает следующие этапы: 1. Определение перечня показателей, по которым будут сравниваться СУБД. 2. Определение списка оцениваемых СУБД. 3. Оценка продуктов по выбранным показателям. 4. Принятие обоснованного решения. Подготовка отчета.

С математической точки зрения, выбор СУБД является решением задачи оптимизации. Для решения таких задач применяют методы линейного или целочисленного программирования. К числу сходных задач относится задача о наименьшем покрытии, для решения которой применяется метод ветвей и границ. Как правило, при выборе СУБД необходимо использовать методы построения обобщенных критериев. Следовательно, общая постановка задачи выбора СУБД выглядит следующим образом: 1. Имеется некоторое множество а1, а2, …, аn вариантов альтернатив. В данном случае это СУБД. Причем, каждому СУБД характерны свойства а1,.., аn. 2. Имеется совокупность критериев q=(q1,q2,..,qn) отражающих количественно множество свойств системы, т. е. каждая альтернатива характеризуется вектором q(a)= [q1(a),q2(a),..qn(a)]. 3. Необходимо принять решение о выборе одной СУБД, причем, решение называется простым, если выбор производится по одному критерию. Если, выбранная СУБД не является лучшей по какому либо одному критерию, то выбор называется сложным, т. к. приходится рассматривать несколько критериев. 4. Задача выбора альтернативы на множестве критериев, сводится к отысканию отображения фи, которое каждому вектору q, ставит в соответствие действительное число Е ( E=фи(q) =фи(q1,q2,..,qn) ) определяющая степень предпочтительности данного решения. Оператор фи называется интегральным, или обобщенным, критерием. Он присваивает каждому решению соответствующие значение эффективности Е. При решении сложной задачи выбора, можно использовать аддитивное преобразование, при построении обобщенного показателя, котрая выражается следующей формулой E= СУММ(от i=1 до m( biqi)) bi отражает полезность критерия qi (весовой коэффициент). Определение значения этих показателей производится путем обработки мнений экспертов. Для оценки СУБД могут использоваться самые различные характеристики, которые могут быть сгруппированы в следующие обобщенные критерии: 1. Параметры определения данных (предусмотренные типы данных, определения доменов, средства поддержки целостности данных, поддержка словаря данных, тип базовой модели организации данных и д.р.).

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

3. Параметры доступности ( язык запросов( совместимость с SQL), интерфейс для других систем, многопользовательский доступ, защита данных).

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

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

6.Средства разработки ( CASE- инструменты, поддержка хранимых процедур и правил).

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

2. Существует три модели данных

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

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

3. Объектно-ориентированная модель. Характеристики привязываются к объектам.

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

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

Вычислитель

ПИ

ПА

ПС

Модель извлечения

Модель актуализации

Модель хранения

Модель БД

СУБД

Таким образом, в систему управления базами данных входит: ПС — программа хранения структуры базы данных. ПА — программа актуализации данных. ПИ — программа извлечения данных.

3. Проектирование фактографических баз данных имеет свои особенности на всех этапах проектирования.

На предпроектной стадии выполняются следующие работы: 1. Определение экономической целесообразности и технической возможности создания базы данных. 2. Выявления состава содержания и характеристик хранимой информации. 3. Определения оценок количественных характеристик информационных объектов и структурных связей между ними ( из анализа постановок задач). 4. Построение инфологической модели предметной области. 5. Предварительные оценки вариантов разработки баз данных. 6. Оценка возможностей применения СУБД и выбор СУБД.

В результате выполнения проектировщики получают технико-экономическое обоснование и техническое задание, на проектирование базы данных. Причем, техническое задание отдельно не разрабатывается, а в общем техническом задании имеется специальный раздел, ориентированный на проектирование базы данных. В нем отражаются следующие вопросы: 1. Назначение базы данных. 2. Основные требования к базе данных. 3. Основные технические решения. 4. Технико-экономические показатели эффективности использования баз данных. 5. Состав, содержание и организация проектных работ по созданию базы данных.

Этап технического проектирования: 1. Уточняется инфлогическая модель. 2. Выполняется логическое проектирование( составление концептуальной схемы). 3. Выполняется физическое проектирования базы данных, с учетом выбранной СУБД. 4. Проектирование представления данных для приложений.

Этап рабочего проектирования: 1. Выполняются разработка программных средств и сервисных программ. 2. Настройка СУБД в соответствии с выбранными параметрами. 3. Разработка контрольного примера. 4. Разработка инструкций пользователя по обращению с базой данных ( описание меню, порядок запуска, сохранения данных, и корректного выхода из программы).