«Этапы разработки базы данных» Преподаватель ОПД и СД ШМУ: Французова Г.Н.

План: 1. Процесс разработки БД Процесс разработки БД 2. Этап анализа Этап анализа 3. CASE – средства CASE – средства 4. Постановка задачи Постановка задачи 5. Моделирование процессов предметной области Моделирование процессов предметной области 6. Диаграммы вида «сущность – связь» 7. Этап проектирования структуры базы данных 8. Нормализация 9. Первая нормальная форма 10. Вторая нормальная форма 11. Третья нормальная форма 12. Четвёртая нормальная форма 13. Ограниченная денормализация 14. Этап разработки функциональности

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

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

CASE-средства На рынке существует множество CASE-средств, среди кото­рых можно отметить такие приложения, как Logicworks ERWin, CSA Silverrun, Powersoft PowerDesigner и др. Подобные программы позволяют моделировать объекты базы данных до их фактического создания, давая таким образом возможность анализировать процессы внутри системы еще до их реализации. Кроме того, CASE-средства упрощают многие технические задачи проектирования и обнаруживают потенциальные проблемы, к которым могут привести принимаемые разработчиком решения. В начало

В процессе разработки базы данных CASE-средства можно использовать в следующих областях: моделирование процессов предметной области разработка диаграмм процессов и связей между ними; построение диаграмм вида «сущность-связь» (ER-диаграммы), позволяющих обращаться с элементами данных в терминах соответствующих объектов реального мира; моделирование реляционных структур данных фактическое создание таблиц и связей между ними на основе ER-диаграмм. В начало

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

Хотя CASE-средства и являются значительным подспорьем на этапе анализа и моделирования предметной области системы, позволяя избежать распространенных ошибок, для работы с ними требуются определенные навыки. Кроме того, они далеко не всем «по карману», поскольку довольно дороги. В любом случае, их использование не является обязательным условием, и многие разработчики БД предпочитают работать «по старинке» с ручкой и бумагой. В начало

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

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

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

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

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

Внешний объект – физическое лицо, подразделение или другой объект, являющийся внешним по отношению к описываемой системе, но при этом взаимодействующей с ним. Например, клиент, рынок, поставщик и т.д. В начало

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

Поток - предметы или данные, перемещаемые между внешними объектами, процессами и накопителями. Например, информация о поставщиках, заявки на обслуживание, доставка заказов и т.д. В начало

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

Так, для базы данных STAFF упрощенная модель процессов предметной области может соответствовать рис. 1. Работа с персоналом Резюме соискателя Заявление об уходе Подаётся на рассмотрение Уведомление ПЕРСОНАЛ КЛАССИФИКАТО РЫ Рис. 1. Упрощённая модель процессов предметной области для базы данных STAFF В начало Выборка сведений о подразделениях и должностях Изменение данных о сотрудниках

В данном случае Резюме соискателя и Заявление об уходе - это внешние объекты, Работа с персоналом - процесс, ПЕРСОНАЛ и КЛАССИФИКАТОРЫ - накопители, а стрелки - потоки. Под накопителем ПЕРСОНАЛ подразумевают все данные о сотрудниках, включая сведения о трудовой деятельности и членах семьи, а под накопителем КЛАССИФИКАТОРЫ - списки подразделений и должностей. В начало

Диаграммы вида «сущность- связь» Основой для возникновения ER-диаграмм стала опублико­ванная в 1976 году Питером Ченом (Peter Chen) спецификация подхода к реляционным структурам данных как к набору связей между сущностями. Сущности, определяемые с помощью ER- диаграмм, соответствуют таблицам реляционной модели БД. Именно поэтому многие CASE- средства предоставляют возможность моделировать не только сущности и связи, но также и элементы самой базы данных. В начало

Рассмотрим некоторые термины, применяемые при построении ER-диаграмм, и их соответствие объектам реляционной модели *Таблица.1. Соответствие терминологии, используемой в ER-диаграммах, объектам реляционной модели ER- термин Пояснение Объект реляционной модели Сущность(entity)Реальный объект, информация о котором сохраняется в БД (например, сотрудник, заказ, предприятие) Таблица Экземпляр сущности(entity instance) Конкретный представитель класса сущностей Строка Атрибут(attribute)Характеристика сущности Поле (столбец) Домен (domain)Определённый тип данных или диапазон значений, которые должен принимать атрибут Тип данных Идентификатор сущности(entity identifier) Набор атрибутов, отличающих один экземпляр сущности от другого Первичный ключ Связь (relationship)Соединение двух сущностей, в результате которого изменение состояния одной из этих сущностей приводит к изменению состояния другой. Внешний ключ В начало

В большинстве случаев при построении ER-диаграмм используют нотацию двух видов. Стандартная нотация Чена, согласно которой каждая связь между двумя сущностями представляется в виде отдельной диаграммы (рис. 4.2). Рис. 2. Стандартная ротация Чена, определяющая связь вида «один ко многим» между таблицами STAFF и JOBS В начало STAFF JOBS

Подробная нотация, основанная не на связях, а на сущностях. При таком подходе все связи отдельной сущности показывают на одной диаграмме. Подробные ER-диаграммы могут содержать информацию об атрибутах и довольно сильно отличаются от простых диаграмм Чена внешним видом. В качестве примера такой диаграммы можно привести схему данных БД STAFF.mdb (рис. 3). Для этого случая все связи установлены применительно к сущности (таблице) STAFF и относятся к типам «один ко многим» и «многие к одному». В начало

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

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

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

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

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

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

Первая нормальная форма В таблице, соответствующей первой нормальной форме, каждый столбец должен содержать только один элемент данных (такие столбцы еще называют атомарными). Например, в таблице STAFF, которая была рассмотрена в предыдущей главе, адресу сотрудника соответствует сразу три поля: Zip, Street и House. Если бы они были объединены в одно поле (например, Address), то соответствующий столбец атомарным бы не являлся. То же самое можно сказать и о фамилии, имени и отчестве (поля FirstName, LastName и FatherName). Если их объединить в одно неатомарное поле Name, то таблица STAFF перестанет соответствовать первой нормальной форме. В начало

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

Так, база данных Staff не соответствовала бы первой нормальной форме, если бы для хранения информации о членах семьи использовалась не отдельная таблица FAMILY, а повторяющиеся группы полей Kin, KinBirthDate и KinName: CREATE TABLE STAFF ( … Kin1 VARCHAR(6), KinBirthDate1 DATE, KinName1 VARCHAR(50), Kin2 VARCHAR(6), KinBirthDate2 DATE, KinName2 VARCHAR(50), … KinN VARCHAR(6), KinBirthDateN DATE, KinNameN VARCHAR(50) )

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

Вторая нормальная форма Согласно второй нормальной форме в тех таблицах, для которых определен первичный ключ, каждая строка должна однозначно идентифицироваться полями, входящими в состав этого первичного ключа. Например, если в таблице STAFF убрать столбец ID и определить первичный ключ по столбцам FirstName, LastName и FatherName, то она перестанет соответствовать второй нормальной форме, поскольку есть вероятность существования двух сотрудников с одинаковыми фамилией, именем и отчеством. Первичные ключи, включающие в себя данные только одного столбца, всегда соответствуют второй нормальной форме, и для их создания обычно используют числовые поля с уникальными значениями (как в таблицах STAFF, DEPS, POSS и REGIONS базы данных STAFF). В начало

Третья нормальная форма В таблице, соответствующей третьей нормальной форме, все неключевые столбцы не должны зависеть друг от друга. Так, если бы в случае БД STAFF одно или несколько полей, имеющих отношение к подразделениям и должностям (т.е. DeptFullName, DeptShortName, ParentDeptID, PosFuilName, PosShortName и PosLevel), были включены в структуру таблицы STAFF, то возникло бы несоответствие третьей нормальной форме. В начало

Четвертая нормальная форма Согласно четвертой нормальной форме, между столбцами таблицы не допускается многозначная зависимость. Например, некоторый сотрудник может занимать сразу две должности (ситуация не такая уж и редкая). В таком случае для него в таблице STAFF должны быть созданы две строки, которые отличаются только значениями в полях DeplD и PosID. Это является нарушением четвертой нормальной формы, поскольку у одного и того же значения столбца ID может быть несколько значений DeplD и PosID. В начало

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

Данные в столбцах DeptFullName, DeptShortName, ParentDeptID зависят от значения в поле DepID, а данные в столбцах PosFuilName, PosShortName и PosLevel от значения в поле PoslD. Например, при изменении значения в поле PosID может возникнуть необходимость изменить значение в поле PosFuilName, и наоборот. Также существует прямая взаимосвязь между полями PosFuilName и PosShortName. Подобные столбцы лучше всегда выносить в отдельную таблицу, связь с которой затем устанавливается с помощью внешних ключей и объединений. Так, благодаря использованию в базе данных STAFF таблиц REGIONS, DEPS и POSS, связанных с таблицей STAFF по столбцам zip, DepID и PosID, эта БД соответствует третьей нормальной форме.

В представленном примере была создана таблица STAFF_POSS, содержащая ключевые столбцы DeplD и PosID, связанные с таблицами DEPS и POSS соответственно. В то же время эти столбцы были удалены из таблицы STAFF, которая теперь связана по первичному ключу с таблицей STAFF_POSS. Несмотря на то что четвертая нормальная форма сокращает избыточность данных, она увеличивает число таблиц и значительно усложняет SQL-операторы, в связи с чем на практике используется редко В начало

Ограниченная денормализация Иногда складываются ситуации, когда единственным способом повышения производительности системы (особенно при работе с большими базами данных) является так называемая ограниченная денормализация (limited denormalization). Рассмотрим ее суть на следующем примере. В начало

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

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

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

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

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

Литература Ю. Ф. Шпак «Проектирование баз данных»