Системы управления базами данных

Размещено на http://www.allbest.ru/

Контрольная работа

Системы управления базами данных

Макаренко С.Ф.

Оглавление

1. Реляционные БД. Основные понятия: домен, атрибут, отношение, кортеж

1.1 Тип данных

1.2 Домен

1.3 Схема отношения, схема базы данных

1.4 Кортеж, отношение

2. Фундаментальные свойства отношений

2.1 Отсутствие кортежей-дубликатов

2.2 Отсутствие упорядоченности кортежей

2.3 Отсутствие упорядоченности атрибутов

2.4 Атомарность значений атрибутов

3. Реляционная модель данных

Список используемых источников

1. Реляционные БД. Основные понятия: домен, атрибут, отношение, кортеж

Базовые понятия реляционных баз данных

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

Для начала покажем смысл этих понятий на примере отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторой организации:

1.1 Тип данных

Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных базах данных допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как "деньги"), а также специальных "темпоральных" данных (дата, время, временной интервал). Достаточно активно развивается подход к расширению возможностей реляционных систем абстрактными типами данных (соответствующими возможностями обладают, например, системы семейства Ingres/Postgres). В нашем примере мы имеем дело с данными трех типов: строки символов, целые числа и "деньги".

1.2 Домен

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

Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа. Например, домен "Имена" в нашем примере определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут изображать имя (в частности, такие строки не могут начинаться с мягкого знака).

Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов "Номера пропусков" и "Номера групп" относятся к типу целых чисел, но не являются сравнимыми. Заметим, что в большинстве реляционных СУБД понятие домена не используется, хотя в Oracle V.7 оно уже поддерживается.

1.3 Схема отношения, схема базы данных

Схема отношения базы данных - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}. Степень или "арность" схемы отношения - мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута).

Схема базы данных (в структурном смысле) - это набор именованных схем отношений. база данный домен кортеж

1.4 Кортеж, отношение

Кортеж, соответствующий данной схеме отношения в базе данных, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или "арность" кортежа, т.е. число элементов в нем, совпадает с "арностью" соответствующей схемы отношения. Попросту говоря, кортеж - это набор именованных значений заданного типа.

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

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

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

Реляционная база данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме базы данных.

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

2. Фундаментальные свойства отношений

Остановимся теперь на некоторых важных свойствах отношений, которые следуют из приведенных ранее определений:

2.1 Отсутствие кортежей-дубликатов

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

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

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

2.2 Отсутствие упорядоченности кортежей

Свойство отсутствия упорядоченности кортежей отношения также является следствием определения отношения-экземпляра как множества кортежей. Отсутствие требования к поддержанию порядка на множестве кортежей отношения дает дополнительную гибкость системам управления базами данных при хранении баз данных во внешней памяти и при выполнении запросов к базе данных. Это не противоречит тому, что при формулировании запроса к базе данных, например, на языке SQL можно потребовать сортировки результирующей таблицы в соответствии со значениями некоторых столбцов. Такой результат, вообще говоря, не отношение, а некоторый упорядоченный список кортежей.

2.3 Отсутствие упорядоченности атрибутов

Атрибуты отношений не упорядочены, поскольку по определению схема отношения есть множество пар {имя атрибута, имя домена}. Для ссылки на значение атрибута в кортеже отношения всегда используется имя атрибута. Это свойство теоретически позволяет, например, модифицировать схемы существующих отношений в базе данных не только путем добавления новых атрибутов, но и путем удаления существующих атрибутов. Однако в большинстве существующих систем такая возможность не допускается, и хотя упорядоченность набора атрибутов отношения явно не требуется, часто в качестве неявного порядка атрибутов используется их порядок в линейной форме определения схемы отношения базы данных.

2.4 Атомарность значений атрибутов

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

3. Реляционная модель данных

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

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

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

1. Запросы с параметрами в Access.

Запрос в Access является объектом, который сохраняется в файле базы данных и может многократно повторяться. Если требуется повторить такой запрос с другими значениями в условиях отбора, его нужно открыть в режиме Конструктора, изменить условие и выполнить. Чтобы не делать многократно этих операций, можно создать запрос с параметрами. При выполнении такого запроса выдается диалоговое окно Введите значение параметра (Enter Parameter Value), в котором пользователь может ввести конкретное значение и затем получить нужный результат.

Можно показать, как создавать запросы с параметрами на примере запроса "Отсортированный список товаров". С помощью этого запроса можно попробовать отобрать товары, поставляемые определенным поставщиком. Для этого:

Нужно открыть данный запрос в режиме Конструктора.

Чтобы определить параметр запроса, нужно ввести в строку Условие отбора (Criteria) для столбца "Название" (CompanyName) вместо конкретного значения слово или фразу и заключить их в квадратные скобки, например [Поставщик:]. Эта фраза будет выдаваться в виде приглашения в диалоговом окне при выполнении запроса.

Чтобы Access проверяла данные, вводимые в качестве параметра запроса, нужно указать тип данных для этого параметра. Обычно в этом нет необходимости при работе с текстовыми полями, т.к. по умолчанию параметру присваивается тип данных Текстовый (Text). Если же данные в поле запроса представляют собой даты или числа, рекомендуется тип данных для параметра определять. Для этого нужно щелкнуть правой кнопкой мыши на свободном поле в верхней части запроса и выбрать из контекстного меню команду Параметры (Parameters) или выполнить команду меню Запрос, Параметры (Query, Parameters). Появляется диалоговое окно Параметры запроса (Query Parameters), представленное ниже на рисунке 1:

Рис. 1. Диалоговое окно Параметры запроса

В столбец Параметр (Parameter) нужно ввести название параметра точно так, как он определен в бланке запроса (легче всего это сделать путем копирования через буфер обмена), только можно не вводить квадратные скобки. В столбце Тип данных (Data Type) выбрать из раскрывающегося списка необходимый тип данных. Нажать кнопку ОК.

Нажать кнопку Запуск (Run) на панели инструментов, чтобы выполнить запрос. При выполнении запроса появляется диалоговое окно Введите значение параметра (Input Parameter Value) (рис. 2), в которое нужно ввести значение, например Tokyo Traders. Результат выполнения запроса представлен на рис. 3. В него попадают только те товары, которые поставляются данным поставщиком.

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

Рис. 2. Диалоговое окно Введите значение параметра

Рис. 3. Результат выполнения запроса с параметром

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

Практическая часть

Задание 1 (для всех вариантов)

Создать БД Магазин, состоящую из двух таблиц - Отдел и Работник: Составить схему данных для БД Магазин.

В таблицу Работник вместо фамилии Новиков П.Н. ввести свою фамилию.

Из БД Борей в свою БД Магазин импортировать все таблицы.

Задание 2. С помощью Мастера форм на основе таблиц Типы и Товары создать составную связанную форму. В форму включить все поля таблиц. Сохраните форму с именем Вариант 4_1.

Задание 3. На базе таблицы Заказано (поля Код Заказа, КодТовара, Цена, Количество) построить запрос для отбора заказов, у которых количество заказанных товаров больше 5, но меньше 10. Сохранить запрос с именем Вариант4_2.

Задание 4. На базе таблицы Работник построить запрос для отбора работников с должностью Подсобный рабочий. Сохранить запрос с именем Вариант4_3.

(Практическая часть содержится на внешнем носителе (диске), диск прилагается)

Создаём БД Магазин, состоящую из двух таблиц - Отдел и Работник: Составляем схему данных для БД Магазин.

В таблицу Работник вместо ФАМИЛИИ Новиков П.Н. вводим свою фамилию.

Из БД Борей в свою БД Магазин импортируем все таблицы.

С помощью Мастера форм на основе таблиц Типы и Товары создаем составную связную форму. В форму включаем все поля таблиц. Сохраняем с именем Вариант 4_1.

На базе таблицы Заказано (поля КодЗаказа, КодТовара, Цена, Количество) построим запрос для отбора заказов, у которых количество заказанных товаров больше 5, но меньше 10. Сохраняем запрос с именем Вариант 4_2.

На базе таблицы Работник построить запрос для отбора работников с должностью Подсобный рабочий. Сохранить запрос с именем Вариант 4_3.

Список используемых источников

1. Кузин, А. В. Базы данных / А. В. Кузин, С. В. Левонисова. - М. : Академия, 2008.

2. Марков, А. С. Базы данных : Введение в теорию и методологию : учебник для вузов / А. С. Марков, К. Ю. Лисовский. - М.: Финансы и статистика, 2004.

3. Проектирование баз данных СУБД М1сгозой Ассезз / Н. Н. Гринченко [и др.]. - М. : Телеком, 2004.

Размещено на Allbest.ru