Шпаргалка к РК, страница 3
Описание файла
Документ из архива "Шпаргалка к РК", который расположен в категории "". Всё это находится в предмете "информационное обеспечение разработок" из 8 семестр, которые можно найти в файловом архиве МГТУ им. Н.Э.Баумана. Не смотря на прямую связь этого архива с МГТУ им. Н.Э.Баумана, его также можно найти и в других разделах. Архив можно найти в разделе "контрольные работы и аттестации", в предмете "информационное обеспечение разработок" в общих файлах.
Онлайн просмотр документа "Шпаргалка к РК"
Текст 3 страницы из документа "Шпаргалка к РК"
В случае полной идентификации каждый экземпляр данного типа сущности полностью идентифицируется своими собственными ключевыми атрибутами, в противном случае в его идентификации участвуют также атрибуты другой сущности-родителя (рис.7).
9) Этапы преобразования схемы «Сущность-Связь» в реляционную модель БД.
Преобразование ER-схемы в реляционную модель
Шаг 1. Каждая простая сущность превращается в таблицу. Простая сущность – сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.
Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные (пустые) значения; столбцы, соответствующие обязательным атрибутам, - не могут.
Шаг 3. Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы. Если имеется несколько возможных уникальных идентификатора, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.
Шаг 4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Т.е. делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи – столбцам, не допускающим неопределенные значения.
Шаг 5. Создаются индексы для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы. Индексы – упорядоченные структуры, на основе ключевых полей, обеспечивающие более быстрый поиск необходимых значений.
10) Виды связей в реляционных БД.
Виды связей
-
Один-к-одному.
-
Один-ко-многим.
-
Много-ко-многим.
-
Для связи «один-к-одному» каждому элементу одной стороны связи соответствует только один элемент другой стороны связи. Такой вариант связи не представляет какого-либо интереса для реляционной модели БД.
-
Связь «Один-ко-многим» предполагает наличие одного элемента с одной стороны и неограниченного множества элементов с другой стороны связи. В данном случае сторона отношения «один» является справочной, основной, главной таблицей, а сторона отношения «многие» - подчиненной и не может существовать без элементов главной таблицы. При разработке в БД этого отношения создают справочную таблицу с ключевым полем (может быть кодом), а в таблице отношения “многие” создается поле с тем же именем и форматом, но без ключа (т.е. допустим ввод любого количества одинаковых значений).
-
Связь «Много-ко-многим » является «ненормальной» с позиций теории БД и реальная такая связь из предметной области может быть перенесена в модель БД путем разбиения на две связи «один-ко-многим». Для этого создается таблица с кодами “N1” (ключевыми), содержащую первичную информацию одной стороны связи предметной области, затем создается вторая таблица с кодами “N2” (ключевыми), которая содержит справочную информацию для второй стороны отношения “многие”. И на заключительном этапе определяют таблицу связей, с полями “N1” и “N2” (неключевые), в каждой строке которой опредлена информация по связям. Для каждой из таблиц таблица связей находится на стороне отношения «многие».
11) Классический подход к проектированию БД. Первая нормальная форма.
Классический подход к проектированию реляционных баз данных
Классическое решение задачи проектирования реляционной базы данных заключается в обоснованном принятии решений о том, из каких отношений должна состоять БД и какие атрибуты должны быть у этих отношений.
При проектировании базы данных решают две основных проблемы:
-
Проблему логического проектирования баз данных. Каким образом следует отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило структуре предметной области и было эффективным и удобным для использования.
-
Проблему физического проектирования баз данных. Как обеспечить эффективность выполнения запросов к базе данных (т.е. как с учетом особенностей конкретной СУБД, расположить данные во внешней памяти, разложить их на отдельные файлы и дополнительные структуры (например, индексы), чтобы повысить скорость работы с информацией, в том числе и при множественном доступе).
Технологически, рассматриваемый подход к процессу проектирования логической модели БД осуществляется следующим образом:
-
На основе имеющихся представлений о предметной области в виде одного или нескольких отношений, предлагается некоторый набор возможных схем отношений, обладающих наилучшими свойствами с точки зрения разработчика.
-
Осуществляется анализ предложенных схем и производится выбор наиболее удачной схемы, которая станет приоритетной и будет использована за основу при разработке БД.
-
Выбранная модель данных подвергается процессу нормализации имеющихся отношений путем последовательных приближений к удовлетворительному набору схем отношений. При этом каждая следующая нормальная форма описания отношений в схеме должна обладать более лучшими свойствами, чем предыдущая.
Первая нормальная форма (1НФ)
Отношение R находится в первой нормальной форме (1НФ), когда оно удовлетворяет требованиям, сформулированным к понятию «отношения», т.е., в ячейках этой таблицы содержатся одиночные значения, столбец имеет в пределах таблицы уникальное имя и единый тип данных, нет повторяющихся строк.
12) Назначение нормализации БД. Вторая нормальная форма. Примеры.
Метод нормализации основан на декомпозиции отношения, находящегося в предыдущей нормальной форме на два или более отношения, каждое из которых удовлетворяет требованиям новой нормальной формы. При этом соблюдаются следующие требования:
-
Каждая следующая нормальная форма устраняет недостатки предшествующей и совершенствует модель отношений.
-
Каждая следующая нормальная форма сохраняет свойства предыдущих нормальных форм.
Процесс нормализации отношений базируется на фундаментальном в теории реляционных баз данных понятии функциональной зависимости между атрибутами.
Вторая нормальная форма
Отношение R находится во второй нормальной форме (2НФ) в том случае, когда находится в 1НФ, и каждый из неключевых атрибутов полностью зависит от всего ключа.
Табл.1. СЕКЦИИ (КодСтудента, Секция, Плата)
КодСтудента | Секция | Плата |
110 | плавание | 150 |
110 | футбол | 110 |
111 | волейбол | 120 |
111 | плавание | 150 |
122 | бокс | 100 |
112 | шахматы | 100 |
Первая нормальная форма подвержена аномалиям вставки и удаления. Так, для табл.1 при удалении студента «122 » будет потеряна информация о плате в секции «бокс » и нельзя ввести данные о новой секции, пока в нее не будет записан студент. Основной причиной возникновения аномалий является функциональная зависимость атрибутов не от всего ключа, а только от его части. В данном случае Плата зависит только от Секции (Секция->Плата).
13) Транзитивные зависимости. Третья нормальная форма. Примеры.