Шпаргалка к РК (960566), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

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

9) Этапы преобразования схемы «Сущность-Связь» в реляционную модель БД.

Преобразование ER-схемы в реляционную модель

Шаг 1. Каждая простая сущность превращается в таблицу. Простая сущность – сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.

Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные (пустые) значения; столбцы, соответствующие обязательным атрибутам, - не могут.

Шаг 3. Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы. Если имеется несколько возможных уникальных идентификатора, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.

Шаг 4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Т.е. делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи – столбцам, не допускающим неопределенные значения.

Шаг 5. Создаются индексы для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы. Индексы – упорядоченные структуры, на основе ключевых полей, обеспечивающие более быстрый поиск необходимых значений.

10) Виды связей в реляционных БД.

Виды связей

1. Один-к-одному.

2. Один-ко-многим.

3. Много-ко-многим.

1. Для связи «один-к-одному» каждому элементу одной стороны связи соответствует только один элемент другой стороны связи. Такой вариант связи не представляет какого-либо интереса для реляционной модели БД.

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

3. Связь «Много-ко-многим » является «ненормальной» с позиций теории БД и реальная такая связь из предметной области может быть перенесена в модель БД путем разбиения на две связи «один-ко-многим». Для этого создается таблица с кодами “N1” (ключевыми), содержащую первичную информацию одной стороны связи предметной области, затем создается вторая таблица с кодами “N2” (ключевыми), которая содержит справочную информацию для второй стороны отношения “многие”. И на заключительном этапе определяют таблицу связей, с полями “N1” и “N2” (неключевые), в каждой строке которой опредлена информация по связям. Для каждой из таблиц таблица связей находится на стороне отношения «многие».

11) Классический подход к проектированию БД. Первая нормальная форма.

Классический подход к проектированию реляционных баз данных

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

При проектировании базы данных решают две основных проблемы:

1. Проблему логического проектирования баз данных. Каким образом следует отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило структуре предметной области и было эффективным и удобным для использования.

2. Проблему физического проектирования баз данных. Как обеспечить эффективность выполнения запросов к базе данных (т.е. как с учетом особенностей конкретной СУБД, расположить данные во внешней памяти, разложить их на отдельные файлы и дополнительные структуры (например, индексы), чтобы повысить скорость работы с информацией, в том числе и при множественном доступе).

Технологически, рассматриваемый подход к процессу проектирования логической модели БД осуществляется следующим образом:

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

2. Осуществляется анализ предложенных схем и производится выбор наиболее удачной схемы, которая станет приоритетной и будет использована за основу при разработке БД.

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

Первая нормальная форма (1НФ)

Отношение R находится в первой нормальной форме (1НФ), когда оно удовлетворяет требованиям, сформулированным к понятию «отношения», т.е., в ячейках этой таблицы содержатся одиночные значения, столбец имеет в пределах таблицы уникальное имя и единый тип данных, нет повторяющихся строк.

12) Назначение нормализации БД. Вторая нормальная форма. Примеры.

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

1. Каждая следующая нормальная форма устраняет недостатки предшествующей и совершенствует модель отношений.

2. Каждая следующая нормальная форма сохраняет свойства предыдущих нормальных форм.

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

Вторая нормальная форма

Отношение R находится во второй нормальной форме (2НФ) в том случае, когда находится в 1НФ, и каждый из неключевых атрибутов полностью зависит от всего ключа.

Табл.1. СЕКЦИИ (КодСтудента, Секция, Плата)

Первая нормальная форма подвержена аномалиям вставки и удаления. Так, для табл.1 при удалении студента «122 » будет потеряна информация о плате в секции «бокс » и нельзя ввести данные о новой секции, пока в нее не будет записан студент. Основной причиной возникновения аномалий является функциональная зависимость атрибутов не от всего ключа, а только от его части. В данном случае Плата зависит только от Секции (Секция->Плата).

13) Транзитивные зависимости. Третья нормальная форма. Примеры.

Характеристики

Список файлов ответов (шпаргалок)