4.2 Практическая работа №2 Тема: Реляционная модель базы данных. Цель практической работы
Научиться преобразовывать ранее созданную концептуальную схему базы данных в реляционную модель для решения конкретной экономической задачи в соответствии с индивидуальным вариантом.
После выполнения практической работы студент должен:
Знать: назначение реляционной модели данных в проектировании БД, рассмотреть пример создания реляционной модели путем.
Уметь: преобразовать концептуальную схему данных в реляционную модель и уметь ее нормализовать.
Время выполнения – 2 часа.
Пояснения к работе
Порядок выполнения практической работы:
1. Проработать все описанные упражнения самостоятельно.
2. Выполнить индивидуальное задание, руководствуясь методическими указаниями.
3. Проверить свои знания по контрольным вопросам.
Предварительная подготовка
Создание реляционной БД и процесс нормализации таблиц.
Visual FoxPro 6.0 является системой управления реляционными базами данных. Реляционные базы данных в настоящее время наиболее распространенны и фактически являются промышленным стандартом. В реляционной базе данных все данные хранятся в виде прямоугольных таблиц, при этом все операции над базой данных сводятся к манипули-рованию таблицами. Основными понятиями в этой теории являются таблица, отношение, строка, столбец, первичный и внешний ключи.
Таблица состоит из строк и столбцов и имеет уникальное имя в базе данных. База данных содержит множество таблиц, связь между которыми устанавливается с помощью совпадающих полей. В каждой из таблиц содержится информация о каком-либо объекте одного типа(группы). Каждая запись в таблице идентифицирует один объект группы. В качес-тве идентификационного признака используется первичный ключ. Ключ (Первичный ключ) таблицы – это атрибут или набор атрибутов, одно-значно определяющий каждую строку реляционной таблицы. Отношение между объектами определяет отношение между таблицами. Visual FoxPro поддерживает четыре типа отношений между таблицами: один-к-одному, один-ко-многим, много-к-одному, много-ко-многим.
Отношение один-к-одному означает, что каждая запись одной таблицы соответствует только одной записи в другой таблице. Отношение один-ко-многим означает, что каждой записи одной таблицы соответствует много записей другой таблицы. Отношение много-к-одному анлогично типу отношения один-ко-многим. Тип отношения между объектами зависит от точки зрения разработчика. Отношение много-ко-многим возникает между таблицами в случаях когда: одна запись из первой таблицы может быть связана более чем с одной записью из второй таблицы, и одна запись из второй таблицы может быть связана более чем с одной записью из первой таблицы. Связь между таблицами устанавливается на основании значений в совпадающих полях. Поле по которому осуществляется связь называется внешним ключом. Внешний ключ- это набор атрибутов одной таблицы, являющийся первичным ключом другой таблицы.
Проектирование нормализованных баз данных.
При проектировании реляционной базы данных необходимо решить вопрос о наиболее эффективной структуре данных. Основные цели, которые при этом преследуются:
Обеспечить быстрый доступ к данным в таблицах.
Исключить ненужное повторение данных.
Обеспечить целостность данных таким образом, чтобы при изменении одних объектов автоматически происходило соответствующее изменение связанных с ними объектов.
Процесс уменьшения избыточности информации в базе данных называется нормализацией. Теория нормализации оперирует пятью нормальными формами таблиц. Эти формы предназначены для уменьшения избыточности информации от первой до пятой нормальной формы. При практическом проектировании баз данных четвертая и пятая формы, как правило, не используются, поэтому мы ограничиваемся рассмотрением первых трех нормальных форм.
Преобразуем концептуальную модель в реляционную. Схема данных представленной модели ресторан, такова:
Персонал{ФИО, адрес, телефон, год рождения, должность, оклад, паспортные данные}
Заказ{код заказа, дата заказа, блюдо, порции, Фио}
Внешний ключ ФИО ссылается на таблицу Персонал, внешний ключ Блюдо ссылается на таблицу Блюдо.
Блюдо{Блюдо, Категория, Ингредиент, Вес}
Внешний ключ Ингредиент ссылается на таблицу склад.
Склад{Ингредиент, Вес, Цена, Количество}
Из схемы видно, что база данных ресторан состоит из четырех таблиц: Персонал, Заказ, Блюдо, Склад. Ясно, что строка таблицы персонал содержит информацию о конкретном служащем. Каждая запись таблицы идентифицирует один объект. Первичным ключом таблицы Персонал является атрибут ФИО. В таблице Заказ- первичным ключом является атрибут код заказа, в таблице Блюдо – блюдо, в таблице Склад- атрибут ингредиент. Отношение между объектами определяет отношение между таблицами.
Предполагается, что один и тот же сотрудник(официант) может выполнять несколько заказов. Таким образом, между персоналом и выполненными ими заказами существует отношение один-ко-многим. Связь устанавливается на основании данных в совпадающих полях. Между объектами Блюдо и Заказ также существует связь типа один-ко-многим так как в один заказ может состоять из нескольких блюд, в тоже время в одном заказе может присутствовать только одно блюдо. Между таблицами Склад и Блюдо отношение типа один-ко-многим
После небольшого анализа легко видеть что, реляционные таблицы спроектированы неудачно. Например, официант может выполнять несколько заказов, а в каждом заказе может быть заказано несколько блюд. В строках таблицы Заказ атрибуты: код заказа, дата заказа, ФИО официанта, наименование блюда могут иметь одно и тоже значение. Это повторение или избыточность приводит не только к потере места на диске, но может вызвать нарушение целостности данных в БД.
Воспользуемся рекомендациями теории нормализации для разработки многотабличной базы данных с эффективной структурой.
Таблицы, структура которых приведена выше, находятся в первой нормальной форме. Так как таблица в первой нормальной форме должна удовлетворять следующим требованиям:
Таблица не должна иметь повторяющихся записей.
В таблице должны отсутствовать повторяющиеся группы полей.
Строки и столбцы должны быть не упорядочены.
Выше перечисленные таблицы удовлетворяют этим требованиям.
О таблице говорят, что она находится во второй нормальной форме, если:
Она удовлетворяет условиям первой нормальной формы.
Любое неключевое поле однозначно идентифицируется полным набором ключевых полей.
Понятие второй нормальной формы применимо только к таблицам, имеющим составной индекс. В нашем примере такой таблицей является Заказ и Блюдо, в которых составными ключами являются Код заказа и Фио, также Блюдо и Ингредиент соответственно.
 
Р ис. 4
Для приведения таблиц ко второй нормальной форме, разобьем таблицу Заказ на две таблицы Заказ и Заказ_Блюда. Таблицу Блюдо на две таблицы Блюдо и Состав_блюда.
О таблице говорят, что она находится в третьей нормальной форме, если: Она удовлетворяет условиям второй нормальной формы, и ни одно из неключевых полей таблицы не идентифицируется с помощью другого неключевого поля. Поскольку неключевое поле Оклад в таблице Персонал однозначно определяется другим неключевым полем Должность. Для приведения этой таблицы к третьей нормальной форме создадим новую таблицу Должность. Окончательная схема реляционной базы данных представлена на рис. 4.
Создание базы данных
Создание базы данных осуществляется в интерактивном режиме с помощью конструктора базы данных. Конструктор БД позволяет создавать и модифицировать таблицы, входящие в БД, определять для них индексы. БД является частью проекта, поэтому ее целесообразно создавать в конструкторе проектов.
Приступаем к созданию таблиц БД, в которые будет вводиться информация. Создание таблиц с помощью конструктора таблиц представляет более широкие возможности по определению создаваемых таблиц. Таблицу можно представить как реализацию объекта из нашей модели. В таблице данные расположены в виде полей и записей(столбцы и строки соответственно). Например: таблица Персонал состоит из полей ФИО, адрес, телефон, год рождения, должность, оклад, паспорт-ные данные. Поля описывают характеристики объекта, важные для проектировщика. Каждое поле таблицы характеризуется наименование, типом и шириной поля. Кроме того, в Visual FoxPro первичные ключи используются при определении отношений между таблицами. Для того, чтобы создать индекс, в конструкторе таблиц имеется вкладка Indexes. Каждый индекс имеет имя, на которое можно в дальнейшем ссылаться при упорядочивании данных. Каждый индекс имеет тип. Например, первичному ключу соответствует индекс с типом Primary. Структура созданной таблицы Персонал представленная в окне конструктора таблиц показана на рис. 5.
Рис. 5. Структура таблицы Персонал
Рис. 6. Структура таблицы Должность
Рис. 7. Структура таблицы Блюдо
Рис. 8. Структура таблицы Состав_блюда
Рис. 9. Структура таблицы Заказ
Рис. 10. Структура таблицы Заказ_блюда
Рис. 11. Структура таблицы Склад
На рис. 5-11 представлены структуры таблиц в конструкторе для рассматриваемой предметной области.
Задания
Спроектировать реляционную модель данных для своего индивиду-ального варианта
Порядок отчета практической работы
При отчете практической работы необходимо:
Продемонстрировать выполненные задания по индивидуальному варианту, прокомментировать порядок его выполнения и объяснить полученные результаты
Ответить на контрольные вопросы.
Контрольные вопросы
Дайте определение реляционной модели и назовите ее элементы?
Приведите математическое описание понятия отношения?
Что представляет собой первичный ключ отношения , для чего он задается?
|
