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

1   ...   15   16   17   18   19   20   21   22   23

Рис. 6.14. Нисходящий и восходящий подходы к проектированию БД



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

6.6. Централизованное

и децентрализованное проектирование

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

□ Централизованное проектирование. Эта стратегия эффективна в том случае, когда компоненты данных состоят из относительно небольшого количества объектов и процедур. Централизованное проектирование типично для относительно простых и/или небольших баз данных и может быть выполнено одним человеком (администратором БД) или небольшой неформальной группой проектирования Деятельность компании и масштаб проблем сильно ограничены, что позволяет даже одному проектировщику определить задачи, создать концептуальный про­ект, проверить концептуальный проект с точки зрения пользователей, определить системные процессы и ограничения данных, чтобы обеспечить действенность проекта и гарантировать соответствие проекта всем требованиям. (Хотя центра­лизованное проектирование типично для небольших компаний, нельзя считать, что этот метод применим исключительно для них. Даже в сравнительно больших компаниях могут использоваться относительно небольшие базы данных.) На рис. 6.15 приведены основные операции централизованного проектирования. Обратите внимание, что при этом создается и проверяется единственная концеп­туальная модель.



Рис. 6.15. Централизованное проектирование

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



Рис. 6.16. Децентрализованная модель

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

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

• Синонимы и омонимы. Различные подразделения могут давать одним и тем же
  объектам разные имена (синонимы) или одинаковые имена могут использоваться
  для различных объектов (омонимы). Объект может быть сущностью, атрибутом
  или связью.
  
• Сущность и подтипы сущности. Атрибуты могут быть записаны с использованием
  различных типов (символьный, числовой) или же для одинаковых атрибутов
  могут быть определены различные домены. Определения ограничений также
  могут различаться. Проектировщик должен устранить подобные конфликты.
  

I Резюме

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

Жизненный цикл разработки системы (SDLC, System Development Life Cycle) от­слеживает историю (жизненный цикл) приложения в информационной системе. SDLC можно подразделить на пять стадий: планирование, анализ, подробное сис­темное проектирование, реализация и сопровождение. SDLC является скорее итера­тивным, чем последовательным процессом.

Жизненный цикл базы данных (DBLC, Database Life Cycle) описывает историю (жизненный цикл) базы данных внутри информационной системы. DBLC состоит из шести этапов: начальная разработка, проектирование БД, реализация и загрузка дан­ных, тестирование и оценка, функционирование, а также обслуживание и развитие. Также как и SDLC, процесс DBLC скорее итеративный, чем последовательный.

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

1. Анализ данных и требований помогает определить представления конечных
   пользователей и потребность в данных.
   
2. В результате первого этапа получается определение значимых сущностей, атрибу­тов и связей, что в свою очередь позволяет получить соответствующую ER-модель. Компоненты ER-модели определяют способ получения нормализован­ных таблиц.
   
3. Концептуальная модель проверяется посредством определения ее основных про­цессов и заданием соответствующих правил INSERT (вставка), UPDATE (об­новление) и DELETE (удаление). Кроме того, в процессе проверки просматри­ваются пользовательские представления и соответствующие ограничения данных.
   
4. После проверки анализируется проектирование распределенной БД для того,
   чтобы оценить местоположение таблиц, стратегию фрагментирования БД и тре­бования доступа. ■
   
5. В идеальном случае выбор программного обеспечения делается одновременно с
   разработкой концептуальной модели (этапы 1—4). Однако на практике может
   случиться так, что программное обеспечение уже имеется и концептуальное про­ектирование в какой-то мере будет от него зависеть.
   
6. На основе концептуальной модели и программного обеспечения на этапе логи­ческого дизайна происходит перевод концептуальной схемы в определения таб­лиц, представлений и т. д, зависящих от конкретной СУБД. Логическое проекти­рование зависит, таким образом, от особенностей СУБД, но не зависит от
   оборудования.