Студопедия  
Главная страница | Контакты | Случайная страница

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ

Читайте также:
  1. I. Исследование свойств форматов сжатия графических данных
  2. Абстракция данных.
  3. Анализ данных на основе их сортировки.
  4. Анализ эмпирических данных (результаты анкетного обследования)
  5. Архитектура ПК. Центральные и периферийные устройства, средства ввода и средства вывода данных. Оперативная память и средства внешней памяти. Характеристики процессора.
  6. Архитектура системы управления базами данных Microsoft Access.
  7. Б) полезные знания, полученные посредством анализа данных.
  8. База данных
  9. Базы данных
  10. Базы данных, Интернет-источники, информационно-справочные и поисковые системы

Рассмотрим вопрос о проектировании баз данных. К любой базе данных возмо­жен подход на каждом из следующих трех уровней (рис. 1 )

Под представлением данных понимаются правила организации и кодирования.

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

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

 

 
 


Рис. 6.6. Трехуровневое представление данных в концепции ANSI/SPARC

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

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

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

Концептуальное представление основано на определенной модели данных; Этот термин, впервые введенный в 70-х годах основоположником теории баз данных Коддом, в современной трактовке отображает совокупность правил "порожде­ния структур данных в базах данных, последовательности их изменения. Различают три основные типа модели данных: иерархический, сетевой и реляционный.

Модель данных предопределяет множество выводимых допустимых типов дан­ных и отношений между ними и является основой для построения модели конкрет­ной базы данных.

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

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

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

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

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

Процесс построения концептуальной модели разделяется на следующие этапы:

1) сбор и содержательный анализ априорной информации о предметной области и прикладных задачах пользователей;

2) концептуальный анализ данных и синтез концептуальной модели.

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

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

Результатом данного этапа являются

1) список всех создаваемых и используемых элементов данных;

2) перечень прикладных задач, их характеристик и используемых в них данных;

3) список принимаемых решений в управлении организацией или процессами, а также условий и правил их принятия;

4) список возможных будущих изменений в деятельности и их влияний на приня­тие решений.

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

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

 

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

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

Декомпозиция должна

• быть направлена на выделение элементов предметной области, существенных с точки зрения прикладных задач базы данных;

• приводить к вычленению элементов, свойства которых могут быть описаны с помощью собранных на первом этапе элементов данных;

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

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

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

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

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

1. рассмотрения объекта с различных точек зрения, выявления аспектов изучае­мого объекта с учетом их взаимосвязи;

2. расчленения объекта на более простые подсистемы (основанием для введения подсистем является то, что связи между подсистемами много слабее, чем между элементами внутри подсистемы, а каждая подсистема много проще, чем вся система в целом);

3. выделения иерархических отношений типа «целое - часть» между компонента­ми системы разных уровней и отношений эквивалентности между компонентами одного уровня.

 

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

Их дополняют следующие специфические принципы:

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

• необходимо рассматривать лишь те цели, вероятность достижения которых р>р0 за время t< t0, где р0 и t0 - пороги осуществимости цели.

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

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

 

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


1. Сама предметная область
2. Модель предметной области
3. Логическая модель данных
4. Физическая модель данных
5. Собственно база данных и приложения


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


2. Модель предметной области - это наши знания о предметной области. Знания могут быть как в виде неформальных знаний в мозгу эксперта, так и выражены формально при помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания предметной области, наборы должностных инструкций, правила ведения дел в компании и т.п. Опыт показывает, что текстовый способ представления модели предметной области крайне неэффективен. Гораздо более информативными и полезными при разработке баз данных являются описания предметной области, выполненные при помощи специализированных графических нотаций. Имеется большое количество методик описания предметной области. Из наиболее известных можно назвать: методику структурного анализа SADT и основанную на нем IDEF0, диаграммы потоков данных Гейна-Сарсона, методику объектно-ориентированного анализа UML, и др. Модель предметной области описывает процессы, происходящие в предметной области и данные, используемые этими процессами. От того, насколько правильно смоделирована предметная область, зависит успех дальнейшей разработки приложений.


3. Логическая модель данных. На следующем, более низком уровне находится логическая модель данных предметной области. Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий - "сотрудник", "отдел", "проект", "зарплата". Примеры взаимосвязей между понятиями - "сотрудник числится ровно в одном отделе", "сотрудник может выполнять несколько проектов", "над одним проектом может работать несколько сотрудников". Примеры ограничений - "возраст сотрудника не менее 16 и не более 60 лет".


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

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


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


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


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


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

 

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


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


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

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


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


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


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


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


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


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


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


8. Указать ограничения целостности проектируемой базы данных и дать (если это необходимо) краткое описание полученных таблиц и их полей.

Регистрация происходит на сервере www.sciyouth.ru.

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ




Дата добавления: 2015-04-11; просмотров: 71 | Поможем написать вашу работу | Нарушение авторских прав

1 | <== 2 ==> |


lektsii.net - Лекции.Нет - 2014-2024 год. (0.012 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав