Проектирование АИС. С аратовский госуниверситет м еханико математический факультет проектирование информационных систем Составил
 Скачать 3.17 Mb.
|
|
определенном свойстве сущ- ности, а каждый экземпляр сущности должен быть уникальным. Атрибут или группа атрибутов, которые идентифицируют сущность, называется первичным ключем. Очень важно дать атрибуту правильное имя. Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение. Соблюдение этого правила позволяет частично решить пробле- му нормализации данных уже на этапе определения атрибутов. Например, создание в сущности Сотрудник атрибута Телефоны сотрудника противоречит требованиям нормализации, поскольку ат- рибут должен быть атомарным, т. е. не содержать множественных значений. Согласно синтаксису IDEFIX имя атрибута должно быть уникально в рамках модели (а не только в рамках сущности!). Каждый атрибут должен быть определен, при этом следует избегать циклических определений, например, когда термин 1 определяется через термин 2, термин 2 — через термин 3, а термин 3 в свою очередь — через термин 1. Часто приходится создавать производные атрибуты, т. е. атрибуты, значение которых можно вычислить из других атрибутов. Примером производного атрибута может служить Возраст сотрудника, который может быть вычислен из атрибута Дата рождения сотрудника. Такой атрибут может привести к конфликтам; действительно, если вовремя не обновить значение ат- рибута Возраст сотрудника, он может противоречить значению атрибута Дата рождения сотрудника. Производные атрибуты — ошибка нормализации, однако их вводят для повышения производитель- ности системы, чтобы не проводить вычисления, которые на практике могут быть сложными. Связи Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой. Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы. По умолчанию имя связи на диаграмме не показывается. На ло- гическом уровне можно установить идентифицирующую связь "один-ко-многим связь "многие-ко- многим"и неидентифицирующую связь "один-ко-многим". В IDEFIX различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами. Экземпляр зависимой сущности опреде- ляется только через отношение к родительской сущности. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав пер- вичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ — FK. При установлении неидентифицирующей связи дочерняя сущность остается независимой, а ат- рибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов родительской сущности. Неидентифицирующая связь служит для связывания независимых сущно- стей. Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на до- чернем конце связи, неидентифицирующая – пунктирной. Мощность связей (Cardinality) — служит для обозначения отношения числа экземпляров роди- тельской сущности к числу экземпляров дочерней. Различают четыре типа сущности: • общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности; не помечается каким-либо символом; • символом Р помечается случай, когда одному экземпляру родительской сущности соответству- ют 1 или много экземпляров дочерней сущности (исключено нулевое значение); • символом Z помечается случай, когда одному экземпляру родительской сущности соответству- ют 0 или 1 экземпляр дочерней сущности (исключены множественные значения); • цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущ- ности соответствует заранее заданное число экземпляров дочерней сущности. Рис. 8.5: Пример характеристической сущности “Хобби” Имя связи (Verb Phrase) — фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи "один-ко-многим идентифицирующей или неидентифицирующей, достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child). Для связи многие-ко-многим следует указывать имена как Parent-to-Child, так и Child-to-Parent. Типы сущностей и иерархия наследования Как было указано выше, связи определяют, является ли сущность независимой или зависимой. Различают несколько типов зависимых сущностей. Характеристическая — зависимая дочерняя сущность, которая связана только с одной родитель- ской и по смыслу хранит информацию о характеристиках родительской сущности (рис. 8.5 ). Ассоциативная — сущность, связанная с несколькими родительскими сущностями. Такая сущ- ность содержит информацию о связях сущностей. Именующая — частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигрировавших в качестве внешнего ключа). Категориальная — дочерняя сущность в иерархии наследования. Иерархия наследования (или иерархия категорий) представляет собой особый тип объединения сущностей, которые разделяют общие характеристики. Например, в организации работают служа- щие, занятые полный рабочий день (постоянные служащие), и совместители. Из их общих свойств Рис. 8.6: Иерархия наследования. Неполная категория можно сформировать обобщенную сущность (родовой предок) Сотрудник (рис. 8.6 ), чтобы предста- вить информацию, общую для всех типов служащих. Специфическая для каждого типа информация может быть расположена в категориальных сущностях (потомках) Постоянный сотрудник и Совме- ститель. Обычно иерархию наследования создают, когда несколько сущностей имеют общие по смыслу атрибуты, либо когда сущности имеют общие по смыслу связи (например, если бы Постоянный сотрудник и Совместитель имели сходную по смыслу связь "работает в"с сущностью Организация), либо когда это диктуется бизнес-правилами. Для каждой категории можно указать дискриминатор — атрибут родового предка, который пока- зывает, как отличить одну категориальную сущность от другой (атрибут Тип на рис. 8.6 ). Рис. 8.7: Иерархия наследования. Полная категория Иерархии категорий делятся на два типа — полные и неполные. В полной категории одному экземпляру родового предка (сущность Служащий, рис. 8.7 ) обязательно соответствует экземпляр в каком-либо потомке, т. е. в примере служащий обязательно является либо совместителем, либо консультантом, либо постоянным сотрудником. Если категория еще не выстроена полностью и в родовом предке могут существовать экземпляры, которые не имеют соответствующих экземпляров в потомках, то такая категория будет неполной. На рис. 8.6 показана неполная категория — сотрудник может быть не только постоянным или совмести- телем, но и консультантом, однако сущность Консультант еще не внесена в иерархию наследования. Ключи Как было сказано выше, каждый экземпляр сущности должен быть уникален и должен отличаться от других атрибутов. Первичный ключ (primary key) — это атрибут или группа атрибутов, однозначно идентифици- рующая экземпляр сущности. атрибуты первичного ключа на диаграмме не требуют специального обозначения — это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии (см., например, рис. 8.7 ). В одной сущности могут оказаться несколько атрибутов или наборов атрибутов, претендующих на роль первичного ключа. Такие претенденты называются потенциальными ключами (candidate key). Ключи могут быть сложными, т. е. содержащими несколько атрибутов. Сложные первичные ключи не требуют специального обозначения — это список атрибутов, расположенных выше горизонтальной линии. Рассмотрим кандидатов на роль первичного ключа сущности Сотрудник (рис. 8.8 ). Здесь можно выделить следующие потенциальные ключи: 1. Табельный номер; 2. Номер паспорта; 3. Фамилия + Имя + Отчество. Для того чтобы стать первичным, потенциальный ключ должен удовлетворять ряду требований: Уникальность. Два экземпляра не должны иметь одинаковых значений возможного ключа. по- тенциальный ключ № 3 (Фамилия + Имя + Отчество) является плохим кандидатом, поскольку в организации могут работать полные тезки. Рис. 8.8: Определение первичного ключа для сущности “Сотрудник” Компактность. Сложный возможный ключ не должен содержать ни одного атрибута, удаление которого не приводило бы к утрате уникальности. Для обеспечения уникальности ключа № 3 до- полним его атрибутами Дата рождения и Цвет волос. Если бизнес-правила говорят, что сочетания атрибутов Фамилия + Имя + Отчество + Дата рождения достаточно для однозначной идентифика- ции сотрудника, то Цвет волос оказывается лишним, т. е. ключ Фамилия + Имя + Отчество + Дата рождения + Цвет волос не является компактным. При выборе первичного ключа предпочтение должно отдаваться более простым ключам, т. е. ключам, содержащим меньшее количество атрибутов. В приведенном примере ключи № 1 и 2 пред- почтительней ключа № 3. Атрибуты ключа не должны содержать нулевых значений. Значение атрибутов ключа не должно меняться в течение всего времени существования экземпляра сущности. Сотрудница организации может выйти замуж и сменить как фамилию, так и паспорт. Поэтому ключи № 2 и 3 не подходят на роль первичного ключа. Каждая сущность должна иметь по крайней мере один потенциальный ключ. Многие сущности имеют только один потенциальный ключ. Такой ключ становится первичным. Некоторые сущности могут иметь более одного возможного ключа. Тогда один из них становится первичным, а остальные — альтернативными ключами. Альтернативный ключ (Alternate Key) — это потенциальный ключ, не ставший первичным. Нормализация данных Нормализация данных — процесс проверки и реорганизации сущностей и атрибутов с целью удовлетворения требований к реляционной модели данных. Нормализация позволяет быть уве- ренным, что каждый атрибут определен для своей сущности, а также значительно сократить объем памяти для хранения информации и устранить аномалии в организации хранения данных. В резуль- тате проведения нормализации должна быть создана структура данных, при которой информация о каждом факте хранится только в одном месте. Процесс нормализации сводится к последователь- ному приведению структуры данных к нормальным формам — формализованным требованиям к организации данных. Известны шесть нормальных форм. На практике обычно ограничиваются приведением данных к третьей нормальной форме. Для углубленного изучения нормализации рекомендуется книга К. Дж. Дейта "Введение в системы баз данных"(Киев; М.: Диалектика, 1998). ERwin не содержит полного алгоритма нормализации и не может проводить нормализацию авто- матически, однако его возможности облегчают создание нормализованной модели данных. Запрет на присвоение неуникальных имен атрибутов в рамках модели (при соответствующей установке опции Unique Name) облегчает соблюдение правила "один факт — в одном месте". Имена ролей атрибутов внешних ключей и унификация атрибутов также облегчают построение нормализованной модели. Домены Домен можно определить как совокупность значений, из которых берутся значения атрибутов. Каж- дый атрибут может быть определен только на одном домене, но на каждом домене может быть определено множество атрибутов. В понятие домена входит не только тип данных, но и область значений данных. Например, можно определить домен "Возраст"как положительное целое число и определить атрибут Возраст сотрудника как принадлежащий этому домену. В ERwin домен может быть определен только один раз и использоваться как в логической, так и в физической модели. Домены позволяют облегчить работу с данными как разработчикам на этапе проектирования, так и администраторам БД на этапе эксплуатации системы. На логическом уровне домены можно описать без конкретных физических свойств. На физическом уровне они автоматически получают специфи- ческие свойства, которые можно изменить вручную. Так, домен "Возраст"может иметь на логическом уровне тип Number, на физическом уровне колонкам домена будет присвоен тип INTEGER. Каждый домен может быть описан, снабжен комментарием или свойством, определенным пользо- вателем (UDP). Создание физической модели данных Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Раз- личают два уровня физической модели: • трансформационную модель; • модель СУБД. Трансформационная модель содержит информацию для реализации отдельного проекта, который может быть частью общей ИС и описывать подмножество предметной области. Данная модель поз- воляет проектировщикам и администраторам БД лучше представить, какие объекты БД хранятся в словаре данных, и проверить, насколько физическая модель удовлетворяет требованиям к ИС. Модель СУБД автоматически генерируется из трансформационной модели и является точным отображением системного каталога СУБД. Физический уровень представления модели зависит от выбранного сервера. ERwin поддерживает более 20 реляционных и нереляционных БД. По умолчанию ERwin генерирует имена таблиц и индексов по шаблону на основе имен соответству- ющих сущностей и ключей логической модели, которые в дальнейшем могут быть откорректированы вручную. Имена таблиц и колонок будут сгенерированы по умолчанию на основе имен сущностей и атрибутов логической модели. Правила валидации и значения по умолчанию ERwin поддерживает правила валидации для колонок, а также значение, присваиваемое колонкам по умолчанию. Правило валидации задает список допустимых значений для конкретной колонки и/или правила проверки допустимых значений. В список допустимых значений можно вносить новые значения. ERwin позволяет сгенерировать правила валидации соответственно синтаксису выбранной СУБД с учетом границ диапазона или списка значений. Значение по умолчанию – значение, которое нужно ввести в колонку, если никакое другое значение не задано явным образом во время ввода данных. С каждой колонкой или доменом можно связать значение по умолчанию. Список значений можно редактировать. После создания правила валидации и значения по умолчанию их можно присвоить одной или нескольким колонкам или доменами. Индексы В БД данные обычно хранятся в том порядке, в котором их ввели в таблицу. Многие реляцион- ные СУБД имеют страничную организацию, при которой таблица может храниться фрагментарно в разных областях диска, причем строки таблицы располагаются на страницах неупорядоченно. Такой способ позволяет быстро вводить новые данные, но затрудняет поиск данных. Чтобы решить проблему поиска, СУБД используют объекты, называемые индексами. Индекс со- держит отсортированную по колонке или нескольким колонкам информацию и указывает на строки, в которых хранится конкретное значение колонки. Поскольку значения в индексе хранятся в опре- деленном порядке, при поиске просматривать нужно значительно меньший объем данных, что су- щественно уменьшает время выполнения запроса. Индекс рекомендуется создавать для тех колонок, по которым часто производится поиск. При генерации схемы физической БД ERwin автоматически создает индекс на основе первичного ключа каждой таблицы, а также на основе всех альтернативных ключей и внешних ключей, посколь- ку эти колонки наиболее часто используются для поиска данных. Можно отказаться от генерации индексов по умолчанию и создать собственные индексы. Для увеличения эффективности поиска ад- министратор БД должен анализировать часто выполняемые запросы и на основе анализа создавать собственные индексы. Триггеры и хранимые процедуры Триггеры и хранимые процедуры – это именованные блоки кода SQL, которые заранее отком- пилированы и хранятся на сервере для того, чтобы быстро производить обработку запросов, валидацию данных и другие часто выполняемые функции. Хранение и выполнение кода на сервере позволяет создавать код только один раз, а не в каждом приложении, работающем с БД. Это экономит время при написании и сопровождении программ. При этом гарантируется, что це- лостность данных и бизнес-правила поддерживаются независимо от того, какое именно клиентское приложение обращается к данным. Триггеры и хранимые процедуры не требуется пересылать по сети из клиентского приложения, что значительно снижает сетевой трафик. Хранимой процедурой называется именованный набор предварительно откомпилированных команд SQL, который может вызываться из клиентского приложения или из другой хранимой процедуры. Триггером называется процедура, которая выполняется автоматически как реакция на событие. Таким событием может быть вставка, изменение или удаление строки в существующей таблице. Триггер сообщает СУБД, какие действия нужно выполнить при выполнении команд SQL INSERT, UPDATE или DELETE для обеспечения дополнительной функциональности, выполняемой на серве- ре. Триггер ссылочной целостности – это особый вид триггера, используемый для поддержания целостности между двумя таблицами, которые связаны между собой. Если строка в одной таблице вставляется, изменяется или удаляется, то триггер ссылочной целостности сообщает СУБД, что нужно делать с теми строками в других таблицах, у которых значение внешнего ключа совпадает со значением первичного ключа вставленной строки (измененной или удаленной строки). Для генерации триггеров ERwin использует механизм шаблонов – специальных скриптов, ис- пользующих макрокоманды. При генерации кода триггера вместо макрокоманд подставляются имена таблиц, колонок, переменные и другие фрагменты кода, соответствующие синтаксису выбранной СУБД. Шаблоны триггеров ссылочной целостности, генерируемые ERwin по умолчанию, можно изменять. Для создания и редактирования хранимых процедур ERwin располагает специальными редак- торами, аналогичными редакторам, используемым для создания триггеров. В отличие от триггера хранимая процедура не выполняется в ответ на какое-то событие, а вызывается из другой програм- мы, которая передает на сервер имя процедуры. Хранимая процедура более гибкая, чем триггер, поскольку может вызывать другие хранимые процедуры. Ей можно передавать параметры, и она может возвращать параметры, значения и сообщения. |