Лабораторная работа №2: Создание er-модели и ее нормализация. Создание er-модели и ее нормализация Ознакомление с методами и алгоритмом создания модели «Сущность-связь»
Скачать 1.55 Mb.
|
4. Раздел ЛАБОРАТОРНЫЕ РАБОТЫ (ЛАБОРАТОРНЫЙ ПРАКТИКУМ)
^ 1. Создайте логическую реляционную модель БД из концептуальной модели анализа (ER-диаграммы), используя правила преобразования. 2. Проверьте логическую модель на соответствие 1-3 нормальным формам последовательно и, при необходимости, произведите нормализацию. ^ С точки зрения теории реляционных баз данных, существуют следующие понятия. ^ Отношение — плоская таблица, состоящая из столбцов и строк. Атрибут — поименованный столбец отношения. Домен — набор допустимых значений для одного или нескольких атрибутов. ^ — строка отношения. Степень — количество атрибутов в отношении. Кардинальность — количество кортежей, которое содержит отношение. Реляционная БД — набор нормализованных отношений. ^ Ключ отношения — атрибут или набор атрибутов, значения которых могут однозначным образом идентифицировать кортеж данного отношения. Ключ отношения должен удовлетворять следующим условиям:
В отношении может быть несколько ключей, из которых складывается множество потенциальных ключей отношения. ^ — потенциальный ключ, который выбран для уникальной идентификации кортежей внутри отношения. Внешний ключ — атрибут или множество атрибутов внутри отношения, которое соответствует потенциальному ключу некоторого (возможно, того же самого) отношения и служит для связи отношений между собой. ^ Определитель NULL — значение атрибута в данный момент неизвестно или неприемлемо. Целостность сущностей — в базовом отношении ни один атрибут первичного ключа не может содержать отсутствующих значений, обозначаемых оператором NULL. ^ — значение внешнего ключа должно соответствовать значению потенциального ключа некоторого кортежа либо задаваться определителем NULL. Согласно определению, реляционная база данных представляет собой набор нормализованных отношений (таблиц). Под «нормализованными отношениями» понимают соответствие отношений определённому набору правила, а процесс приведения модели БД в нормализованную форму называют нормализацией. Нормализация будет подробно рассмотрена в следующей части работы. Перед тем как заняться нормализацией, сформируем из ER-диаграммы набор таблиц. На диаграмме логической модели базы данных присутствуют следующие элементы. Таблицы, представленные в виде прямоугольника, в верхней части которого располагается название таблицы, отчёркнутое линией, а в нижней — список полей таблицы с указанием ключей:  Помимо первичных ключей, рассмотренных нами в ER-моделировании, логическая модель включает в себя внешние, либо вторичные ключи, которые необходимы для реализации связей между таблицами. Связи между таблицами изображаются в виде прямых, ломаных или кривых линий со стрелками, ведущих от внешних к первичным ключам связываемых таблиц:  ^ Для построения такой диаграммы существуют следующие, достаточно несложные правила:
Рассмотрим примеры применения таких правил. ^ Пример «Человек и паспорт» Текстовое описание задачи:
Для идентификации Человека необходимо ввести уникальный ключ — например, числовой Код. ER-диаграмма:  При преобразовании такой модели мы можем воспользоваться одним из 3-х вышеупомянутых вариантов. Попробуем выбрать наиболее подходящий. Самый простой вариант — объединить обе сущности в одну таблицу. Он особенно подходит для тех случаев, когда по условиям задачи всегда существуют обе сущности, входящие в связь.  Однако для данного примера это не так — человек может существовать без паспорта, а паспорт без соответствующего ему человека смысла не имеет. В такой ситуации сущность Паспорт называется «зависимой», т.к. её существование зависит от существования сущности Человек. Хранение обеих сущностей для связи 1:1 в одной таблице хорошо тем, что исключаются затраты разработчика на поддержку связей и работу с ними. В нашем же случае больше подойдёт 2-й способ — добавить в зависимую таблицу Паспорт поле Код_человека — внешний ключ на таблицу Человек:  Таким образом, имея в таблице Паспорт код человека, мы по паспорту можем установить человека. Говорят, что существует возможность «навигации», перемещения от сущности Паспорт к сущности Человек, что так или иначе показывает стрелка на диаграмме. В то же время, работая с конкретным экземпляром сущности Человек (строкой таблицы Человек), можно получить информацию о его паспортных данных только проходя полностью по всей таблице Паспорт и проверяя совпадение Кода_человека с соответствующем значением кода данного экземпляра Человека. Т.е. прямая «навигация» в направлении «Человек —> Паспорт» в такой модели отсутствует. Третий способ, в котором обе таблицы обзаводятся взаимными ссылками хорош тем, что в схеме БД будет существовать возможность прямой двухсторонней навигации от Паспорта к Человеку и наоборот. Однако в случае смены человеком паспорта затраты на обновление обоих внешних ключей явно выше, чем в случае 1-й общей таблицы (1-й вариант) или односторонней внешней ссылки (2-й вариант). Интересно, что при замене паспорта при использовании 1-го варианта организации хранения данных, информация о старом паспорте будет теряться, перетираться новыми данными, а при использовании вариантов 2 и 3 можно будет создать новую запись для паспорта, а запись, соответствующую старому паспорту, сделать неактивной, например введя у Паспорта технический атрибут «статус_блокировки» и установив его значение в «заблокирован». ^ Такой тип отношения встречается наиболее часто, более того, более сложные типы отношений, M:N, в процессе построения логической модели БД всегда сводят к 2-м отношениям типа 1:N. Преобразование для такого типа отношения производится однозначным добавлением внешней ссылки в дочернюю таблицу. Например, для нашей задачи «Аэропорт» для отношения между сущностями Авиакомпания и Самолёт мы получим следующую диаграмму:  Здесь и далее для задачи «Аэропорт» мы будем использовать транслитерированные имена таблиц, столбцов и внешних ключей. Это связано с возможными проблемами при использовании русскоязычных имён в различных системах управления базами данных. Аналогичным образом преобразуются все прочие отношения 1:N ER-модели «Аэропорт». ^ Поскольку технически невозможно, а точнее — крайне неэффективно хранить информацию о двух наборах сущностей, связанных между собой отношением типа M:N в одной или даже двух таблицах, возникает необходимость создавать промежуточную вспомогательную таблицу, содержащую пары ключей на обе таблицы, таким образом разрешая одно отношение типа M:N в два отношения типа 1:N. В отношениях таких типов, очень часто само отношение, а не только сущности, может обладать атрибутами. ^ Текстовое описание задачи:
ER-диаграмма:  Согласно правилу преобразования для отношения M:N введём промежуточную таблицу Заказ-Услуга или Строка_заказа, которая будет содержать составной первичный ключ из двух внешних ключей-ссылок на таблицы Заказ и Услуга и атрибут Количество единиц услуги:  Полная логическая реляционная модель базы данных для задачи «Аэропорт» будет выглядеть следующим образом:  Задание: Создайте логическую реляционную модель БД из концептуальной модели анализа (ER-диаграммы), используя правила преобразования. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Похожие рефераты:
| Лекция Реляционная алгебра и реляционное исчисление. Нормализация... | Программа (Syllabus) Дисциплина: Модели и методы управления «Модели и методы управления» составлена на основе госо мон рк 2006г по специальности 050704 «Вычислительная техника и программное... |
| Модельер-конструктор Чертит основу конструкции модели, делает рабочие лекала, по которым вырезается и в последующем уточняется макет будущей модели. Составляет... | План работы практического психолога гимназии №6 на 2012-2013 год. Создание психолого педагогических условий, адаптивной модели школы и создание психического и психологического здоровья учителей и... |
| Лабораторная работа № Нормализация баз данных. Задание Спроектировать реляционную базу данных, состоящую из четырех связанных отношений | Пять шагов реализации интегрированной модели оказания специальных социальных услуг Первый шаг. Создание межведомственной рабочей группы по внедрению интегрированной модели оказания специальных социальных услуг |
| Название дисциплины по выбору студента Специфика кросс-культурной коммуникации в экономической и политической сферах с представителями индуизированных государств. Особенности... | Задача согласованной оптимизации Этим требованиям удовлетворяют два класса макроэкономических моделей это так называемые вычислимые модели общего равновесия и динамические... |
| Техническая спецификация услуг по определению модели организационной... Целью оказания Услуги является подготовка технико-экономического обоснования (тэо) для создания модели Общего центра обслуживания... | Лабораторная работа №9 Изучение сетевого уровня модели osi на примере протокола ip |
Вы можете разместить ссылку на наш сайт:
