Министерство образования российской федерации московский государственный институт электроники и математики (Технический университет)
 Скачать 1.02 Mb.
|
|
3. ЭЛЕМЕНТЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ Проектирование БД – одна из наиболее сложных и ответственных задач, связанных с созданием информационной системы. В результате решения этой задачи должны быть определены содержание БД, эффективный для всех её бу- – 25 – дущих пользователей способ организации данных и инструментальные средст- ва управления данными. В крупных системах проектирование БД требует особой тщательности, поскольку цена допущенных на этой стадии просчётов и ошибок особенно ве- лика. Некоторые ошибки проектирования можно скорректировать позже в про- цессе эксплуатации с помощью средств реструктуризации и реорганизации БД, но такие операции являются весьма трудоемкими и дорогостоящими. Основная цель процесса проектирования БД состоит в получении такого проекта, который удовлетворяет следующим требованиям: 1. Корректность схемы БД, т.е. база должна быть гомоморфным образом моде- лируемой ПО, где каждому объекту ПО соответствуют данные в памяти ЭВМ, а каждому процессу – адекватные процедуры обработки данных. 2. Обеспечение ограничений (на объёмы внешней и оперативной памяти и дру- гие ресурсы вычислительной системы). 3. Эффективность функционирования (соблюдение ограничений на время ре- акции системы на запрос и обновление данных). 4. Защита данных (от сбоев и несанкционированного доступа). 5. Простота и удобство эксплуатации. 6. Гибкость, т.е. возможность развития и адаптации к изменениям ПО и/или требований пользователей. Удовлетворение первых 4-х требований обязательно для принятия проекта. Процесс проектирования БД включает в себя следующие этапы: 1. Информационно-логическое (инфологическое) проектирование. 2. Определение требований к операционной обстановке, в которой будет функционировать информационная система. 3. Выбор СУБД и других инструментальных программных средств. 4. Логическое проектирование БД. 5. Физическое проектирование БД. 3.1. Инфологическое проектирование Инфологический подход не содержит формальных способов моделирова- ния реальности, но он закладывает основы методологии проектирования БД. Первой задачей инфологического проектирования является определение ПО системы, позволяющее изучить информационные потребности будущих пользователей. Другая задача этого этапа – анализ ПО, который призван сфор- мировать взгляд на ПО с позиций сообщества будущих пользователей БД, т.е. инфологической модели ПО. Анализ ПО выполняется разработчиком логиче- ской базы данных – специалистом в данной ПО. Инфологическая модель ПО представляет собой описание структуры и динамики ПО, характера информационных потребностей пользователей систе- мы в терминах, понятных пользователю и независимых от реализации системы. Более того, инфологическая модель ПО не должна зависеть от модели данных, которая будет использована при создании БД. Обычно описание ПО выражается в терминах не отдельных объектов и связей между ними, а их типов, связанных с ними ограничений целостности и – 26 – тех процессов, которые приводят к переходу ПО из одного состояния в другое. Такое описание может быть представлено любым способом, допускающим од- нозначную интерпретацию. В простых случаях описание ПО представляется на естественном языке. В более сложных случаях используется также математический аппарат: табли- цы, диаграммы, графы и т.п. Если анализ ПО выполняется несколькими спе- циалистами, то они должны принять соглашения, касающиеся: – используемых методов анализа предметной области; – правил именования и обозначения объектов ПО, атрибутов и связей; – содержания и формата создаваемых ими документов. Примечание. В тексте данного пособия используются следующие обозначения: 1. Имя отношения выделяется курсивом и подчеркиванием и пишется прописными буквами, например: СОТРУДНИКИ. 2. Имя атрибута отношения выделяется курсивом и подчеркиванием и пишется с большой буквы, например: Оклад. 3. Ключевые атрибуты отношения выделяются полужирным шрифтом, например: Табельный номер. 4. Имя связи между отношениями выделяется курсивом и подчеркиванием и пишет- ся строчными буквами, например: работает. Существуют разные подходы к инфологическому проектированию. Рас- смотрим основные из них. 1. Функциональный подход к проектированию БД. Этот метод является наиболее распространённым. Он реализует принцип "от задач" и применяется в том случае, когда известны функции некоторой группы лиц и/или комплекса задач, для обслуживания информационных по- требностей которых создаётся рассматриваемая БД. 2. Предметный подход к проектированию БД. Предметный подход применяется в тех случаях, когда у разработчиков есть чёткое представление о самой ПО и о том, какую именно информацию они хотели бы хранить в БД, а структура запросов не определена или определена не полностью. Тогда основное внимание уделяется исследованию ПО и наиболее адекватному её отображению в БД с учётом самого широкого спектра инфор- мационных запросов к ней. 3. Проектирование с использованием метода "сущность–связь" Метод "сущность–связь" (Entity–Relation, ER–method) был разработан в 1976 г. П.Ченом (Chen P.P.). Он является комбинацией двух предыдущих и об- ладает достоинствами обоих. Этап инфологического проектирования начинает- ся с моделирования ПО. Проектировщик разбивает ПО на ряд локальных об- ластей, каждая из которых (в идеале) включает в себя информацию, достаточ- ную для обеспечения информационных потребностей одной группы будущих пользователей или решения отдельной задачи. Каждое локальное представле- ние моделируется отдельно, а затем выполняется их объединение. Выбор ло- кального представления зависит от масштабов ПО. Обычно ПО разбивается на локальные области так, чтобы каждая из них соответствовала отдельному – 27 – внешнему приложению и содержала 6-7 сущностей (т.е. объектов, о которых в системе будет накапливаться информация). Сущности, существование которых не зависит от существования других сущностей, называются базовыми, остальные сущности – зависимыми. Напри- мер, сущность ЛЕКЦИЯ зависит от базовых сущностей ГРУППА, ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА. Для каждой сущности определяются атрибуты, которые делятся на два типа: идентифицирующие и описательные. Идентифицирующие атрибуты вхо- дят в состав ключа (или ключей) и позволяют однозначно распознавать экземп- ляры сущности. Первичный ключ базовой сущности не может содержать неоп- ределённые значения атрибутов (null). Первичный ключ должен включать в свой состав минимально необходимое для идентификации количество атрибу- тов. Описательные атрибуты заключают в себе свойства сущности, интересую- щие пользователей. Спецификация атрибута состоит из его названия, указания типа данных и описания ограничений целостности – множества значений, которые может при- нимать данный атрибут. Далее осуществляется спецификация связей: выявляются связи между сущностями внутри локального представления. Каждая связь именуется. Кроме спецификации связей типа "сущность – сущность", выполняется спецификация связей типа "сущность – атрибут" и "атрибут – атрибут" для отношений между атрибутами, которые относятся к одной и той же сущности или к одной и той же связи типа "сущность – сущность". При объединении проектировщик может формировать конструкции, про- изводные по отношению к тем, которые были использованы в локальных пред- ставлениях. Цель введения подобных абстракций: – объединение в единое целое фрагментарных представлений о различных свойствах одного и того же объекта; – введение абстрактных понятий, удобных для решения задач системы, уста- новление их связи с более конкретными понятиями модели; – образование классов и подклассов подобных объектов (например, класс "из- делие" и подклассы типов изделий, производимых на предприятии). При небольшом количестве локальных областей (не более пяти) объеди- нение выполняется за один шаг. В противном случае обычно выполняют би- нарное объединение. При объединении представлений используют три осново- полагающие концепции: 1. Идентичность. Два или более элементов модели идентичны, если они име- ют одинаковое семантическое значение. 2. Агрегация. Позволяет рассматривать связь между элементами как новый элемент. Например, связь экзамен между сущностями ДИСЦИПЛИНА, ПРЕПОДАВАТЕЛЬ, СТУДЕНТ может быть представлена агрегированной сущностью ЭКЗАМЕН с атрибутами Название дисциплины, Фамилия препо- давателя, Фамилия студента, Оценка. – 28 – 3. Обобщение. Позволяет образовывать многоуровневую иерархию обоб- щений. Например, в объединяемых представлениях присутствуют следую- щие сущности: ДЕТАЛИ СОБСТВЕННОГО ПРОИЗВОДСТВА ДЕТАЛИ ПОКУПНЫЕ СБОРОЧНЫЕ ЕДИНИЦЫ ПОКУПНЫЕ СБОРОЧНЫЕ ЕДИНИЦЫ СОБСТВЕННОГО ПРОИЗВОДСТВА Их можно объединить так, как показано на рис. 3.1. Это позволит упростить формализацию процессов обработки данных. Например, оформление заказа на покупные элементы изделий в данном примере может быть описано один раз (для второго уровня иерархии). Элементы изделий предприятия Покупные Сборочные единицы Детали Сборочные единицы Детали Собственного производства Рис.3.1. Использование обобщений при объединении На этапе объединения необходимо выявить и устранить все противоре- чия. Например, одинаковые названия семантически различных объектов или связей или несогласованные ограничения целостности на одни и те же атрибу- ты в разных приложениях. Устранение противоречий вызывает необходимость возврата к этапу моделирования локальных представлений с целью внесения в них соответствующих изменений. По завершении объединения результаты проектирования представляют собой концептуальную инфологическую модель ПО. Модели локальных пред- ставлений – это внешние инфологические модели. На этапе анализа ПО также решаются следующие задачи: 1) Определение правил (ограничений целостности), которым должны удовле- творять сущности ПО, атрибуты сущностей и связи между ними. Часть этих правил реализуется в схеме базы данных (возможности реализации ограни- чений целостности в схеме БД определяются моделью данных той СУБД, которая будет выбрана для реализации проекта). Остальные правила реали- зуются с помощью программного обеспечения. 2) Выделение групп пользователей системы. Каждая группа выполняет опреде- лённые задачи и обладает разными правами доступа к системе. 3) Создание внешней спецификации тех функций (процессов), которые эта сис- тема будет выполнять. Например, для той же библиотечной системы это за- дачи поиска книг (по определённым критериям), выдачи/приёма книг, опре- деление списка должников и т.д. – 29 – 3.2. Определение требований к операционной обстановке На этом этапе производится оценка требований к вычислительным ресур- сам, необходимым для функционирования системы, выбор типа и конфигура- ции ЭВМ, типа и версии операционной системы. Выбор зависит от таких показателей, как: – примерный объём данных в БД; – динамика роста объёма данных; – характер запросов к данным (извлечение и обновление отдельных записей, обработка групп записей, обработка отдельных отношений или соединение отношений); – интенсивность запросов к данным по типам запросов; – требования к времени отклика системы по типам запросов. 3.3. Выбор СУБД и инструментальных программных средств Выбор СУБД является одним из важнейших моментов в разработке про- екта БД, так как он принципиальным образом влияет на весь процесс проекти- рования БД и реализации информационной системы. Теоретически при осуществлении этого выбора нужно принимать во внимание десятки факторов. Но на практике разработчики руководствуются лишь собственной интуицией и несколькими наиболее важными критериями, к которым, в частности, относятся: – тип модели данных, которую поддерживает данная СУБД, адекватность мо- дели данных структуре рассматриваемой ПО; – характеристики производительности СУБД; – запас функциональных возможностей для дальнейшего развития информа- ционной системы; – степень оснащенности СУБД инструментарием для персонала администри- рования данными; – удобство и надежность СУБД в эксплуатации; – стоимость СУБД и дополнительного программного обеспечения. 3.4. Логическое проектирование БД На этапе логического проектирования разрабатывается логическая струк- тура БД, соответствующая инфологической модели ПО. Решение этой задачи существенно зависит от модели данных, поддерживаемой выбранной СУБД. Результатом выполнения этого этапа являются схемы БД концептуального и внешнего уровней архитектуры, составленные на языках определения данных (DDL) выбранной СУБД. 3.5. Физическое проектирование БД Этап физического проектирования заключается в увязке логической структуры БД и физической среды хранения с целью наиболее эффективного размещения данных, т.е. отображении логической структуры БД в структуру хранения. Решается вопрос размещения хранимых данных в пространстве па- мяти, выбора эффективных методов доступа к различным компонентам "физи- – 30 – ческой" БД. Результаты этого этапа документируются в форме схемы хранения на языке определения хранимых данных. Принятые на этом этапе решения ока- зывают определяющее влияние на производительность системы. Более подробно процесс проектирования баз данных освещен в [9]. Фактически проектирование БД имеет итерационный характер. В процес- се функционирования системы становится возможным изменение её реальных характеристик, выявление "узких" мест. И если система не отвечает предъяв- ляемым к ней требованиям, то обычно она подвергается реорганизации, т.е. мо- дификации первоначально созданного проекта. 3.6. Автоматизация проектирования БД Функциональное ядро систем автоматизированного проектирования (САПР) БД строится как совокупность взаимосвязанных модулей инфологиче- ского моделирования, проектирования схемы, подсхем и физической организа- ции БД. Существующие в настоящее время САПР БД строятся как человеко- машинные экспертные системы. В первую очередь это определяется слабо под- дающимся формализации процессом синтеза инфологического описания ПО, т.е. преобразования неформальных представлений реального мира в формаль- ные категории. Этот процесс выполняется экспертом – специалистом в той или иной ПО. Поэтому все проблемы, которые характерны для формирования базы знаний экспертной системы, возникают и в случае САПР БД. Характерной особенностью САПР БД является её ориентация на коллек- тивное творчество и продолжительность самого процесса проектирования, предполагающего множество итераций. Это находит свое отражение в наличии журнала проектирования и других средств, обеспечивающих ведение и коллек- тивное использование исходных данных, промежуточных и окончательных ре- зультатов проектирования. Общая структура САПР БД приведена на рис. 3.2. База результатов проектирования Журнал проектирования База промежуточных результатов Проектировщик Средства поддержки инфологического проектирования Средства поддержки логического проектирования Средства поддержки физического проектирования Рис. 3.2. Общая структура САПР БД В настоящее время создан ряд систем автоматизации проектирования БД, но эти системы обладают многими недостатками и поэтому не стали пока мас- совым инструментом разработчиков. – 31 – 3.7. Особенности проектирования реляционных БД Проектирование реляционной базы данных проходит в том же порядке, что и проектирование БД других моделей данных, но имеет свои особенности. Каждое реляционное отношение соответствует одной сущности ПО и в него вносятся все атрибуты объекта, связанные с ним отношением 1:1. Связь типа 1:n реализуется с помощью внешнего ключа. Для реализации связи типа n:m между сущностями вводится дополнительное отношение, содержащее комби- нации первичных ключей связанных отношений и атрибуты этой связи. Проектирование схемы БД должно решать задачи минимизации дублиро- вания данных и упрощения процедур их обработки и обновления. При непра- вильно спроектированной схеме БД могут возникнуть аномалии выполнения операций включения, удаления и модификации данных. Эти аномалии обу- словлены отсутствием средств явного представления типов множественных связей между объектами ПО и неразвитостью средств описания ограничений целостности на уровне модели данных. 3.7.1. Аномалии модификации данных В качестве примера возьмём отношение со следующими атрибутами (ключевые атрибуты выделены подчёркиванием): ПОСТАВКИ (Номер поставки, Название товара, Цена товара, Количество, Дата поставки, Название поставщика, Адрес поставщика) Различают три вида аномалий: аномалии обновления, удаления и добав- ления. Аномалия обновления может возникнуть в том случае, когда информа- ция дублируется. Другие аномалии возникают тогда, когда две и более незави- симые сущности объединены в одно отношение. Например: 1. Аномалия обновления: в отношении ПОСТАВКИ она может возникнуть, если у какого-либо поставщика изменился адрес. Изменения должны быть внесены во все кортежи, соответствующие поставкам этого поставщика; в противном случае данные будут противоречивы. 2. Аномалия удаления: при удалении записей обо всех поставках одного по- ставщика все данные о поставщике будут утеряны. 3. Аномалия добавления: в нашем примере она возникнет, если с поставщи- ком заключен договор, но поставок от него еще не было. Информация о та- ком поставщике не может быть внесена в отношение ПОСТАВКИ, т.к. для него не определён ключ (номер поставки и название товара) и другие обяза- тельные поля. Для решения проблемы аномалии модификации данных при проектиро- вании РБД проводится нормализация отношений. 3.7.2. Нормализация отношений В рамках реляционной модели данных Э.Ф. Коддом был разработан ап- парат нормализации отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей нормальной форме. Нормализация схемы отношения выполняется путём декомпозиции схемы. |