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

Страницы работы

14 страниц (Word-файл)

Фрагмент текста работы

Цель анализа – установить, какие данные должны храниться в БД, как эти данные взаимосвязаны и какие ограничения на них накладываются правилами бизнеса. Кроме того, в процессе анализа выделяются различные группы конечных пользователей и определяются информационные потребности каждой группы. Главный результат этого этапа – концептуальная модель требований пользователя к данным. Обычно это ER-диаграмма с текстовыми документами, дополняющими и поясняющими её.

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

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

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

На четвёртом этапе определяются подмножества данных, необходимых конкретным КП, и проектируются отображения концептуального макета БД на макеты КП. Кроме того, проектируются интерфейсы КП.[1]

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

Рис. 3.1Этапы проектирования БД

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

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

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

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

2 Необходимость проектирования структуры РБД

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

Что это за набор? Зачем он нужен? Почему бы не хранить все данные в одном отношении? Эта «замечательная» идея почему-то приходит в головы многих начинающих «проектировщиков» БД. Здесь мы попытаемся ответить на эти вопросы.

2.1 Универсальное отношение и аномалии обновления

Рассмотрим “учебную” БД ПОСТАВЩИК–ДЕТАЛЬ– ИЗДЕЛИЕ. Эта БД хранит сведения о ПОСТАВЩИКах, поставляемых ими ДЕТАЛях

Похожие материалы

Информация о работе