Лабораторная работа №2: Создание er-модели и ее нормализация. Создание er-модели и ее нормализация Ознакомление с методами и алгоритмом создания модели «Сущность-связь»


НазваниеЛабораторная работа №2: Создание er-модели и ее нормализация. Создание er-модели и ее нормализация Ознакомление с методами и алгоритмом создания модели «Сущность-связь»
страница1/14
Дата публикации25.09.2013
Размер1.55 Mb.
ТипЛабораторная работа
referatdb.ru > Бухгалтерия > Лабораторная работа
  1   2   3   4   5   6   7   8   9   ...   14
4. Раздел ЛАБОРАТОРНЫЕ РАБОТЫ (ЛАБОРАТОРНЫЙ ПРАКТИКУМ)


Номер

раздела, тема дисциплины

Цель и содержание лабораторной работы

Результаты лабораторной работы

Формы
контроля выполнения работы


Объем в часах

Лабораторная работа № 1: Проектирование базы данных

1. Проектирование базы данных

Создание логической реляционной модели базы данных

^ Свойства отношений. Реляционная целостность

Правила преобразования ER-диаграммы в логическую модель

Отношение,

ER-диаграммы

Составить отношение и диаграмму

2

^ Лабораторная работа № 2: Создание ER-модели и ее нормализация.

2. Создание ER-модели и ее нормализация

Ознакомление с методами и алгоритмом создания модели «Сущность-связь».

^ ER-модель и ее нормализация

ER-модель и ее нормализация

2

^ Лабораторная работа №3: Проектирования БД на основе декомпозиции универсального отношения.


3. Проектирования БД на основе декомпозиции универсального отношения.


Научиться проектировать БД на основе декомпозиции универсального отношения.

Отношение

Проектированное отношение

2

Лабораторная работа №4: Разработка отчетов в Rave Reports 5.0

4. Разработка отчетов в Rave Reports 5.0

изучить программный продукт Rave Reports, используя его возможности научиться создавать простые и сложные запросы.

Отчет-файл

Создать базху данных и отчет по нему

3

^ Лабораторная работа №5: Управление приложениями пакета MS Office

Управление MS Word



5. Управление приложениями пакета MS Office

Управление MS Word


^ Цель работы: освоить основные принципы использования технологии OLE Automation для взаимодействия программ на уровне внутренних командных языков и обмена данными, освоить принципы и особенности технологии позднего и раннего связывания.


Файл базы данных, запрос, экспортированный в текстовый редактор файл-отчет

Файл базы данных, запрос, экспортированный в текстовый редактор файл-отчет

3

^ Лабораторная работа №6: Разработка баз данных средствами SQL-сервера Interbase. Команды языка SQL для описания данных.


6. ^ Разработка баз данных средствами SQL-сервера Interbase. Команды языка SQL для описания данных.

Цель работы: Изучить команды описания данных и команды манипулирования данными языка SQL. Познакомиться с работой приложения IBConsole.


Получить навыки работы при создании базы данных средствами SQL сервера - InterBase.

Получить навыки работы при работе с интерактивным SQL в приложениях IBConsole и SQLExplorer.

3

^

Лабораторная работа № 1: «Проектирование базы данных»

Задание


1. Создайте логическую реляционную модель БД из концептуальной модели анализа (ER-диаграммы), используя правила преобразования.

2. Проверьте логическую модель на соответствие 1-3 нормальным формам последовательно и, при необходимости, произведите нормализацию.
^

Методические указания:

Создание логической реляционной модели базы данных


С точки зрения теории реляционных баз данных, существуют следующие понятия.
^

Основные элементы реляционной модели


Отношение — плоская таблица, состоящая из столбцов и строк.

Атрибут — поименованный столбец отношения.

Домен — набор допустимых значений для одного или нескольких атрибутов.

^ Кортеж — строка отношения.

Степень — количество атрибутов в отношении.

Кардинальность — количество кортежей, которое содержит отношение.

Реляционная БД — набор нормализованных отношений.
^

Свойства отношений. Реляционные ключи


Ключ отношения — атрибут или набор атрибутов, значения которых могут однозначным образом идентифицировать кортеж данного отношения. Ключ отношения должен удовлетворять следующим условиям:

  • ^ Условие уникальности — в отношении не может быть двух кортежей с одинаковым набором значений ключевых атрибутов;

  • Условие минимальности — из ключа нельзя исключить ни одного атрибута без потери условия уникальности.

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

^ Первичный ключ — потенциальный ключ, который выбран для уникальной идентификации кортежей внутри отношения.

Внешний ключ — атрибут или множество атрибутов внутри отношения, которое соответствует потенциальному ключу некоторого (возможно, того же самого) отношения и служит для связи отношений между собой.
^

Реляционная целостность


Определитель NULL — значение атрибута в данный момент неизвестно или неприемлемо.

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

^ Ссылочная целостность — значение внешнего ключа должно соответствовать значению потенциального ключа некоторого кортежа либо задаваться определителем NULL.

Согласно определению, реляционная база данных представляет собой набор нормализованных отношений (таблиц). Под «нормализованными отношениями» понимают соответствие отношений определённому набору правила, а процесс приведения модели БД в нормализованную форму называют нормализацией. Нормализация будет подробно рассмотрена в следующей части работы.

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

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



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

Связи между таблицами изображаются в виде прямых, ломаных или кривых линий со стрелками, ведущих от внешних к первичным ключам связываемых таблиц:


^

Правила преобразования ER-диаграммы в логическую модель


Для построения такой диаграммы существуют следующие, достаточно несложные правила:

  1. Сущность становится таблицей с соответствующим именем.

  1. Атрибут становится столбцом с таким же именем.

  1. Связи типа 1:1 преобразуются одним из следующих вариантов:

    1. Связанные сущности-таблицы сливаются в одну таблицу.

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

    1. В обе таблицы добавляются столбцы-внешние ключи, содержащие ссылки на первичные ключи других таблиц.

  1. Связи типа 1:N реализуются в виде добавления столбца-внешнего ключа в ту таблицу, которой соответствует N единиц сущностей отношения. Такая таблица называется подчинённой, или дочерней, а таблица, соответствующая одной сущности отношения — родительской или главной.

  1. Связи типа M:N реализуются с помощью дополнительно вводимой вспомогательной таблицы, используемой лишь для хранения пар внешних ключей, ссылающихся на первичные ключи связываемых таблиц. Обычно такая таблица получает составное название из названий связываемых ею таблиц вида «Таблица1_Таблица2».


Рассмотрим примеры применения таких правил.
^

Преобразование для отношения 1:1


Пример «Человек и паспорт»

Текстовое описание задачи:

  1. Человек характеризуется ФИО, Датой рождения, Местом рождения, Полом.

  2. Человек может иметь Паспорт, если ему исполнилось 14 лет.

  3. Паспорт характеризуется Номером, Датой выдачи, Местом выдачи, Выдавшей организацией.

Для идентификации Человека необходимо ввести уникальный ключ — например, числовой Код.

ER-диаграмма:



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

Самый простой вариант — объединить обе сущности в одну таблицу. Он особенно подходит для тех случаев, когда по условиям задачи всегда существуют обе сущности, входящие в связь.



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

Паспорт называется «зависимой», т.к. её существование зависит от существования сущности Человек.

Хранение обеих сущностей для связи 1:1 в одной таблице хорошо тем, что исключаются

затраты разработчика на поддержку связей и работу с ними.

В нашем же случае больше подойдёт 2-й способ — добавить в зависимую таблицу Паспорт поле Код_человека — внешний ключ на таблицу Человек:



Таким образом, имея в таблице Паспорт код человека, мы по паспорту можем установить

человека. Говорят, что существует возможность «навигации», перемещения от сущности

Паспорт к сущности Человек, что так или иначе показывает стрелка на диаграмме.

В то же время, работая с конкретным экземпляром сущности Человек (строкой таблицы

Человек), можно получить информацию о его паспортных данных только проходя полностью по всей таблице Паспорт и проверяя совпадение Кода_человека с соответствующем значением кода данного экземпляра Человека. Т.е. прямая «навигация» в направлении «Человек —> Паспорт» в такой модели отсутствует.

Третий способ, в котором обе таблицы обзаводятся взаимными ссылками хорош тем, что в схеме БД будет существовать возможность прямой двухсторонней навигации от Паспорта к Человеку и наоборот. Однако в случае смены человеком паспорта затраты на обновление обоих внешних ключей явно выше, чем в случае 1-й общей таблицы (1-й вариант) или односторонней внешней ссылки (2-й вариант).

Интересно, что при замене паспорта при использовании 1-го варианта организации хранения данных, информация о старом паспорте будет теряться, перетираться новыми данными, а при использовании вариантов 2 и 3 можно будет создать новую запись для паспорта, а запись, соответствующую старому паспорту, сделать неактивной, например введя у Паспорта технический атрибут «статус_блокировки» и установив его значение в «заблокирован».
^

Преобразование для отношения 1:N


Такой тип отношения встречается наиболее часто, более того, более сложные типы отношений, M:N, в процессе построения логической модели БД всегда сводят к 2-м отношениям типа 1:N.

Преобразование для такого типа отношения производится однозначным добавлением внешней ссылки в дочернюю таблицу. Например, для нашей задачи «Аэропорт» для отношения между сущностями Авиакомпания и Самолёт мы получим следующую диаграмму:



Здесь и далее для задачи «Аэропорт» мы будем использовать транслитерированные имена таблиц, столбцов и внешних ключей. Это связано с возможными проблемами при использовании русскоязычных имён в различных системах управления базами данных.

Аналогичным образом преобразуются все прочие отношения 1:N ER-модели «Аэропорт».
^

Преобразование для отношения N:M


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

В отношениях таких типов, очень часто само отношение, а не только сущности, может

обладать атрибутами.

^ Пример «Заказы и услуги»

Текстовое описание задачи:

  1. Заказ характеризуется номером, датой поступления, датой выполнения и суммой заказа.

  2. В процессе выполнения заказа выполняются различные услуги. Одна и та же услуга может оказываться в процессе выполнения разных заказов. Таким образом, одному заказу соответствует набор услуг, и каждой услуге соответствует набор заказов — это и есть определение отношения «многие-ко-многим», M:N.

  3. Услуга характеризуется кодом, названием и тарифной ставкой за единицу.

  4. Процесс оказания услуги в рамках выполнения конкретного заказа также характеризуется определённым выполненным количеством единиц услуги, например, количеством листов.

ER-диаграмма:


Согласно правилу преобразования для отношения M:N введём промежуточную таблицу Заказ-Услуга или Строка_заказа, которая будет содержать составной первичный ключ из двух внешних ключей-ссылок на таблицы Заказ и Услуга и атрибут Количество единиц услуги:



Полная логическая реляционная модель базы данных для задачи «Аэропорт» будет выглядеть следующим образом:


Задание: Создайте логическую реляционную модель БД из концептуальной модели анализа (ER-диаграммы), используя правила преобразования.
  1   2   3   4   5   6   7   8   9   ...   14

Похожие рефераты:

Лекция Реляционная алгебра и реляционное исчисление. Нормализация...

Программа (Syllabus) Дисциплина: Модели и методы управления
«Модели и методы управления» составлена на основе госо мон рк 2006г по специальности 050704 «Вычислительная техника и программное...
Модельер-конструктор
Чертит основу конструкции модели, делает рабочие лекала, по которым вырезается и в последующем уточняется макет будущей модели. Составляет...
План работы практического психолога гимназии №6 на 2012-2013 год.
Создание психолого педагогических условий, адаптивной модели школы и создание психического и психологического здоровья учителей и...
Лабораторная работа № Нормализация баз данных. Задание
Спроектировать реляционную базу данных, состоящую из четырех связанных отношений
Пять шагов реализации интегрированной модели оказания специальных социальных услуг
Первый шаг. Создание межведомственной рабочей группы по внедрению интегрированной модели оказания специальных социальных услуг
Название дисциплины по выбору студента
Специфика кросс-культурной коммуникации в экономической и политической сферах с представителями индуизированных государств. Особенности...
Задача согласованной оптимизации
Этим требованиям удовлетворяют два класса макроэкономических моделей это так называемые вычислимые модели общего равновесия и динамические...
Техническая спецификация услуг по определению модели организационной...
Целью оказания Услуги является подготовка технико-экономического обоснования (тэо) для создания модели Общего центра обслуживания...
Лабораторная работа №9 Изучение сетевого уровня модели osi на примере протокола ip


Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
referatdb.ru
referatdb.ru
Рефераты ДатаБаза