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

Вид материала

Документы

Содержание Правильное определение бизнес-правил дает некоторые важные преимущества при ER-моделирование и нормализация Таблица 6.2 (окончание) Шаг Описание Videojd videojtitle video_copy video_chg video_days Проверка модели данных Управление параллельным выполнением (concurrency control)

Подобный материал:

• Системы управления базами данных (субд). Назначение и основные функции, 30.4kb.
• Программа курса лекций "Базы данных в научных исследованиях", 49.32kb.
• Система управления базами данных это комплекс программных и языковых средств, необходимых, 150.5kb.
• Лекция 2 Базы данных, 241.25kb.
• Любая программа для обработки данных должна выполнять три основных функции: ввод новых, 298.05kb.
• Вопросы к государственному экзамену по специальности «Информационные системы и технологии», 39.93kb.
• Лекция № Технологии баз данных, 92.24kb.
• Проектирование базы данных, 642.58kb.
• Системы управления базами данных, 313.7kb.
• Программа дисциплины Системы управления базами данных Семестры, 22.73kb.

Правильное определение бизнес-правил дает некоторые важные преимущества при

проектировании новых систем:

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

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

ER-моделирование и нормализация

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

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

Таблица 6.2. Разработка концептуальной модели с помощью ER-диаграмм

Шаг Описание

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

³ См. "Linking Rules to Models", Alice Sandifer and Barbara von Halle, Database Programming & Design, 4(3), March 1991, стр.13—16. Хотя источник может показаться устаревшим, он, тем не менее, соответствует современным стандартам. Технологии изменились существенно, но сам процесс остался тем же.

Таблица 6.2 (окончание)

Шаг Описание

6. Завершение первоначальной ER-диаграммы
   
7. Проверка конечными пользователями модели, полученной после Шага 6,
   на основе имеющихся данных и технических требований
   
8. Модификация ER-диаграммы на основе Шага 7
   

Некоторые шаги, перечисленные в табл. 6.2, выполняются параллельно. А некоторые, такие как процесс нормализации, могут потребовать создания дополнительных сущностей и/или атрибутов, что может стать причиной пересмотра ER-модели. Например, в процессе выявления двух основных сущностей проектировщик должен идентифицировать переходную промежуточную сущность, представляющую собой связь M:N между двумя основными сущностями.

Для проверки предположим, что создается концептуальная модель для корпорации по прокату видеокассет JollyGood, конечные пользователи которой хотят отслеживать действия клиентов, берущих напрокат кассеты. На простейшей ER-диаграмме, представленной на рис. 6.7, показана составная сущность, которая помогает отеле- I живать клиентов и взятые ими напрокат видеокассеты. Бизнес-правила определяют необязательную природу связей между сущностями VIDEO (кассета) и CUSTOMER (клиент), представленными на рис. 6.7. (Например, клиенты не требуют проверки видеокассеты. Не нужно проверять наличие видеокассет на полке. Клиент может взять напрокат много видеокассет, а видеокассету могут брать напрокат многие кли­енты.) Обратите особое внимание на составную сущность RENTAL (прокат), связы­вающую две основные сущности.



Рис. 6.7. Составная сущность

Вы, вероятно, обратили внимание, что начальная ER-модель может несколько раз подвергаться пересмотру, прежде чем она будет соответствовать требованиям систе­мы. Вы должны помнить, что ER-модель является средством коммуникации, а так­же схемой проекта базы данных. Поэтому начальная ER-диаграмма должна отвечать на такие вопросы, как "Это действительно то, что вам нужно?" в процессе согласо­вания системы с конечными пользователями. Например, ER-диаграмма, представ­ленная на рис. 6.7, еще далека от завершения. Очевидно, что нужно определить еще много атрибутов и проверить множество зависимостей, перед тем как реализовать проект. Кроме того, этот проект не может обеспечить типичные транзакции проката видеокассет. Например, у каждой видеокассеты, скорее всего, есть несколько копий, доступных в прокате. Однако если сущность VIDEO, представленную на рис. 6.7, использовать для хранения основных кассет, а также их копий, то в проекте будет иметь место избыточность данных, что продемонстрировано в табл. 6.3.

Таблица 6.3. Избыточность данных в таблице VIDEO

VIDEOJD VIDEOJTITLE VIDEO_COPY VIDEO_CHG VIDEO_DAYS SF-12345FT-1 Приключения на 1 2,45 1 третьей планете SF-12345FT-2 Приключения на 2 2,45 1 третьей планете SF-12345FT-3 Приключения на 3 2,45 1 третьей планете WE-5432GR-1 Кану и Тайлер 2: 1 1,99 2 Путешествие WE-5432GR-2 Кану и Тайлер 2: 2 1,99 2 Путешествие

Начальную ER-диаграмму, представленную на рис. 6.7, нужно модифицировать так, чтобы она отвечала на вопрос: "Доступно ли более одной копии для данного филь­ма?" Необходимо обслуживать платежные операции. (У вас будет возможность мо­дифицировать этот начальный проект в задаче 5 в конце этой главы.) У вас не должно создаться впечатление, что ER-моделирование (определение сущ­ностей и атрибутов, нормализация, проверка) должно выполняться в строгой после­довательности. На самом деле, вполне вероятно, что вы вернетесь к ER-модели по­сле ее завершения и будете повторять все действия до тех пор, пока не убедитесь, что ER-модель в точности соответствует проекту базы данных, способному удовле­творить требования проекта системы в целом. (Действия зачастую выполняются па­раллельно, и весь процесс носит итеративный характер.) На рис. 6.8 представлен весь этот процесс в целом. На рис. 6.9 сведены воедино все средства проектирова­ния и источники информации, которые проектировщик может использовать при разработке концептуальной модели.

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

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

• принять решение о добавлении новых первичных ключей для того, чтобы вы­полнить технологические требования и удовлетворить запросы конечных пользо­вателей;
  
• принять решение по обработке многозначных атрибутов;
  
• принять решение о размещении внешних ключей в связях типа 1:1;
  
• избегать необязательных тернарных связей;
  

Рис. 6.8. Итеративный процесс ER-моделирования, основанный на множестве операций



Рис. 6.9. Инструменты концептуального проектирования и источники информации

• нарисовать соответствующую ER-диаграмму;
  
• нормализовать модель данных;
  
• включить все определения элементов данных в словарь данных;
  
• принять решение по стандарту на соглашение об именовании.
  

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

Хотя мы установили некоторые полезные элементы и атрибуты соглашения об име­новании в гл. 3, мы все же подробно рассмотрим их еще раз чуть позже. Однако надо иметь в виду, что такие соглашения иногда ограничиваются программным обеспечением СУБД. На СУБД действует правило общего знаменателя в масштабе предприятия. Например, в Microsoft Access название атрибута LINE_ITEM_NUMBER считается вполне допустимым. Многие старые СУБД, тем не менее, скорее всего, будут обрезать такие длинные имена при импортировании из одной СУБД в другую, тем самым затрудняя документирование. Поэтому при экспортировании таблиц мо­гут быть установлены ограничения на длину имен. (То же справедливо и для типов данных. Например, многие старые СУБД не поддерживают форматы OLE и memo.)

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

• Нужно использовать наглядные названия для сущностей и атрибутов, когда это возможно. Например, в базе данных университетской компьютерной лаборато­рии (см. гл. 7) сущность USER (пользователь) содержит данные о пользователях лаборатории, а сущность LOCATION (местоположение) относится к размещению элементов (ITEM), которые хочет отслеживать директор лаборатории.
  
• Составным сущностям обычно присваиваются имена, связанные с атрибутами, которые эти сущности представляют. Например, в базе данных университетской компьютерной лаборатории (см. гл. 7) элемент (ITEM) может храниться во мно­гих местах (LOCATION), а в данном месте (LOCATION) может храниться не­сколько элементов (ITEM). Поэтому составная (переходная, промежуточная) сущность, соединяющая ITEM и LOCATION, называется STORAGE (хранилище). Иногда проектировщик считает необходимым показать, какие сущ­ности связаны составной сущностью. В таком случае имя составной сущности может включать фрагменты имен этих сущностей. Например, STUCLASS может быть именем составной сущности, связывающей сущности STUDENT и CLASS. Однако такой вариант именования может вызвать некоторую путаницу, поэтому его надо применять осторожно. (Мы предпочли промежуточную сущность, свя­зывающую сущности CLASS и STUDENT, назвать ENROLL.)
  
• Имена атрибутов должны быть наглядными и иметь префикс, указывающий i таблицу, в которой его можно найти. Мы будем использовать префикс длиннее пяти символов. Например, таблица VENDOR может содержать так рибуты, как VEND_ID и VEND_PHONE. Точно так же таблица ITEM может со­держать атрибуты с такими именами, как 1ТЕМ_Ш и ITEM_DESCRIPTION Преимущество такого соглашения об именовании в том, что при этом ср виден внешний ключ таблицы. Например, если таблица EMPLOYEE со такие атрибуты, как EMPID, EMP_LNAME и DEPT_CODE, то сразу ясн DEPTCODE является внешним ключом, возможно, связывающим та! EMPLOYEE и DEPARTMENT. Естественно, из-за наличия имен связей ; лиц, начинающихся с одних и тех же символов, приходится иногда немного подправлять соглашение об именовании, как это показано в следующем пункте
  
• Если одна из таблиц названа ORDER (заказ), а связанная с ней слабая ность — ORDER_ITEM, то для указания на атрибут, находящийся в таблице ORDER, будем использовать префикс ORD. Префикс ITEM мы будем использо­вать для обозначения атрибутов, расположенных в таблице ITEM. Очевидно, что в этом случае для указания на атрибуты таблицы ORDER_ITEM префикс ORD не подходит, поэтому в качестве префикса имен атрибутов таблицы ORDER_ITEM мы будем использовать комбинацию символов, например, 01. Несмотря на все эти проблемы, заметим, что всегда можно найти подходящий способ назначения префиксов, указывающих на происхождение атрибута. (Помните, что некоторые РСУБД используют список "зарезервированных слов". Например, ORDER может интерпретироваться как зарезервированное слово опе­ратора SELECT. В этом случае нужно использовать для таблицы другое имя.)
  

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

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

Проверка модели данных

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

• в отношении к представлениям конечных пользователей и выполняемым ими тран­закциям: операции SELECT, INSERT, UPDATE и DELETE, запросы и отчеты;
  
• в отношении путей доступа, безопасности и управления параллельным выполнением;
  

Управление параллельным выполнением (concurrency control) — это возможность, кото­рая допускает одновременный доступ к базе данных, обеспечивая в то же время целост­ность данных. Необходимость управления параллельным выполнением обоснована в табл. 6.6.

• в отношении требований и ограничений, предъявляемых к информации компа­нией.
  

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

• появление непредвиденных сведений об атрибутах может привести к пересмотру самой сущности. Возможно, некоторые компоненты, которые поначалу прини­мались за сущности, станут атрибутами других сущностей. Или элемент, который мы вначале рассматривали как атрибут, может оказаться состоящим из множест­ва вложенных элементов и станет причиной создания одной или более новых сущностей;
  
• подробное рассмотрение сведений об атрибутах поможет раскрыть природу свя­зей, определенных первичными и внешними ключами. Неправильное определе­ние связей приводит, прежде всего, к проблемам реализации, а впоследствии
  к проблемам при разработке приложений;
  
• для выполнения требований технологического процесса и/или конечных пользова­телей бывает необходимо заменить первичный и внешний ключи новыми. Напри­
  мер, в системе обработки счетов, представленной на рис. 2.29 (см. гл. 2), мы созда­ли первичный ключ, состоящий из атрибутов INVNUMBER и LINENUMBER,
  чтобы заменить первоначальный первичный ключ, составленный из атрибутов
  INVNUMBER и PROD_CODE. Мы сделали это для того, чтобы позиции в счете
  появлялись в том же порядке, в каком они были введены. Иногда для упрощения
  выполнения запросов и увеличения производительности системы необходимо соз­дать первичный ключ, состоящий только из одного атрибута, заменив имеющийся
  первичный ключ, состоящий из нескольких атрибутов;
  
• до тех пор, пока сведения о сущностях (т. е. атрибуты и их характеристики) точ­но не определены, очень трудно оценить глубину нормализации. Знание уровней
  нормализации помогает избежать нежелательной избыточности;
  
• поскольку у нас уже есть, по крайней мере, черновой эскиз проекта, его тща­тельная проверка, скорее всего, повлечет за собой некоторые изменения. Эти
  изменения помогут обеспечить соответствие проекта требованиям конечного
  пользователя.
  

Так как проектирование базы данных в действительности, как правило, выполняется группой проектировщиков, необходимо постараться выполнить основные компо­ненты проекта в виде независимых модулей. (Модуль — это компонент информаци­онной системы, который служит для выполнения специфических функций, таких как инвентаризация, заказы, платежные ведомости и т. д.) Создание и использование модулей преследует несколько важных целей:

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

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

Таблица 6.4. Проверка ЕR-модели



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

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



Рис. 6.10. Итеративный процесс проверки ER-модели

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

• убедиться в сцепленности модуля (module cohesivity). Термин "сцепленность" опи­сывает силу связей между сущностями модуля. Модуль должен обладать высокой сцепленностью — то есть сущности модуля должны быть сильно связаны и мо­дуль должен быть завершенным и автономным;
  
• проанализировать все связи модулей друг с другом на возможность последую­щего связывания модулей. Термин связываемость модулей (module coupling) опи­сывает степень независимости модулей друг от друга. Модули должны обладать низкой связываемостью, что демонстрирует их слабую зависимость от других мо­дулей. Чем ниже связываемость, тем меньше ненужных связей между модулями, что позволяет создать в полном смысле модульную систему и устранить ненуж­ные связи между сущностями.
  

Процессы можно классифицировать:

• по частоте: ежедневные, еженедельные, ежегодные или внеплановые;
  
• по типу операций: INSERT (вставка) или ADD (добавление), UPDATE (обновление) или CHANGE (изменение), DELETE (удаление), запросы и отче­ты, пакетные процедуры, обслуживание и создание резервных копий.
  

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

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