Реляционная модель данных реферат
Обновлено: 28.06.2024
Название работы: Реляционная модель данных и реляционные СУБД.Типы связей и их реализация
Предметная область: Информатика, кибернетика и программирование
Описание: Реляционная модель данных и реляционные СУБД. Реляционная модель данных логическая модель данных. Реляционная модель данных включает следующие компоненты: Структурный аспект составляющая данные в базе данных представляют собой набор отношений. РМД поддерживает декларативные ограничения целостности уровня домена типа данных уровня отношения и уровня базы данных.
Размер файла: 22.21 KB
Работу скачали: 18 чел.
6. Реляционная модель данных и реляционные СУБД.Типы связей и их реализация.
Реляционная модель данных логическая модель данных. Впервые была предложена британским учёным сотрудником компании IBM Эдгаром Франком Коддом (E. F. Codd) в 1970 году. В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.
Реляционная модель данных включает следующие компоненты:
- Структурный аспект (составляющая) данные в базе данных представляют собой набор отношений .
- Аспект (составляющая) целостности отношения (таблицы) отвечают определенным условиям целостности . РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.
- Аспект (составляющая) обработки (манипулирования) РМД поддерживает операторы манипулирования отношениями ( реляционная алгебра , реляционное исчисление ).
Кроме того, в состав реляционной модели данных включают теорию нормализации .
Для лучшего понимания РМД следует отметить три важных обстоятельства:
- модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;
- для реляционных баз данных верен информационный принцип : всё информационное наполнение базы данных представлено одним и только одним способом, а именно явным заданием значений атрибутов в кортежах отношений; в частности, нет никаких указателей (адресов), связывающих одно значение с другим;
- наличие реляционной алгебры позволяет реализовать декларативное программирование и декларативное описание ограничений целостности, в дополнение к навигационному (процедурному) программированию и процедурной проверке условий.
Состав реляционной модели данных:
Структурная часть модели определяет, что единственной структурой данных является нормализованное n-арное отношение. Отношения удобно представлять в форме таблиц, где каждая строка есть кортеж, а каждый столбец атрибут, определенный на некотором домене. Данный неформальный подход к понятию отношения дает более привычную для разработчиков и пользователей форму представления, где реляционная база данных представляет собой конечный набор таблиц.
Манипуляционная часть модели определяет два фундаментальных механизма манипулирования данными реляционная алгебра и реляционное исчисление. Основной функцией манипуляционной части реляционной модели является обеспечение меры реляционности любого конкретного языка реляционных БД: язык называется реляционным, если он обладает не меньшей выразительностью и мощностью, чем реляционная алгебра или реляционное исчисление.
Целостная часть модели определяет требования целостности сущностей и целостности ссылок . Первое требование состоит в том, что любой кортеж любого отношения отличим от любого другого кортежа этого отношения, т.е. другими словами, любое отношение должно обладать первичным ключом . Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в отношении, на которое ведет ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать).
Реляционная СУБД - СУБД , управляющая реляционными базами данных .
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
- каждый элемент таблицы один элемент данных
- все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.)
- каждый столбец имеет уникальное имя
- одинаковые строки в таблице отсутствуют
- порядок следования строк и столбцов может быть произвольным
Столбцы таблицы называются полями: каждое поле характеризуется своим именем и топом данных. Поле БД это столбец таблицы, содержащий значения определенного свойства.
Строки таблицы являются записями об объекте. Запись БД это строка таблицы, содержащая набор значения определенного свойства, размещенный в полях базы данных.
СУБД используются для упорядоченного хранения и обработки больших объемов информации.
СУБД организует хранение информации таким образом, чтобы ее было удобно:
искать нужные сведения,
делать любые выборки,
осуществлять сортировку в любом порядке.
КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ (представление аналитика)
ЛОГИЧЕСКИЙ УРОВЕНЬ (представление программиста)
- записи
- элементы данных
- связи между записями
ФИЗИЧЕСКИЙ УРОВЕНЬ (представление админитсратора)
- группирование данных
- индексы
- методы доступа
Достоинства реляционной модели:
- простота и доступность для понимания пользователем. Единственной используемой информационной конструкцией является "таблица";
- строгие правила проектирования, базирующиеся на математическом аппарате;
- полная независимость данных. Изменения в прикладной программе при изменении реляционной БД минимальны;
- для организации запросов и написания прикладного ПО нет необходимости знать конкретную организацию БД во внешней памяти.
Недостатки реляционной модели:
- далеко не всегда предметная область может быть представлена в виде "таблиц";
- в результате логического проектирования появляется множество "таблиц". Это приводит к трудности понимания структуры данных;
- БД занимает относительно много внешней памяти;
- относительно низкая скорость доступа к данным.
Связи между таблицами осуществляются на основании внешних ключей.
Внешний ключ - это столбец или группа столбцов в одной таблице R1, совпадающих по типу данных с первичным ключом в таблице R2, и каждому значению этого столбца или группы столбцов в таблице R1 обязательно должно найтись совпадающее с ним значение в таблице R2.
Существуют следующие типы информационных связей:
- один-к-одному (одному атрибуту первой таблицы соответствует только один атрибут второй таблицы и наоборот);
- один-ко-многим (одному атрибуту первой таблицы соответствует несколько атрибутов второй таблицы);
- многие-ко-многим (одному атрибуту первой таблицы соответствует несколько атрибутов второй таблицы и наоборот).
А также другие работы, которые могут Вас заинтересовать
Основные идеи современной информационной технологии базируются на концепции, согласно которой данные должны быть организованы в базы данных с целью адекватного отображения изменяющегося реального мира и удовлетворения информационных потребностей пользователей. Эти базы данных создаются и функционируют под управлением специальных программных комплексов, называемых системами управления базами данных (СУБД).
Увеличение объема и структурной сложности хранимых данных, расширение круга пользователей информационных систем привели к широкому распространению наиболее удобных и сравнительно простых для понимания реляционных (табличных) СУБД. Для обеспечения одновременного доступа к данным множества пользователей, нередко расположенных достаточно далеко друг от друга и от места хранения баз данных, созданы сетевые мультипользовательские версии БД основанных на реляционной структуре. В них тем или иным путем решаются специфические проблемы параллельных процессов, целостности (правильности) и безопасности данных, а также санкционирования доступа.
Основные понятия реляционных баз данных
Основными понятиями реляционных баз данных являются тип данных, домен, атрибут, кортеж, первичный ключ и отношение.
Для начала покажем смысл этих понятий на примере отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторой организации:
Схема отношения, схема базы данных
Схема БД (в структурном смысле) – это набор именованных схем отношений.
Кортеж, отношение
Однако в реляционных базах данных это не принято. Имя схемы отношения в таких базах данных всегда совпадает с именем соответствующего отношения-экземпляра. В классических реляционных базах данных после определения схемы базы данных изменяются только отношения-экземпляры. В них могут появляться новые и удаляться или модифицироваться существующие кортежи. Однако во многих реализациях допускается и изменение схемы базы данных: определение новых и изменение существующих схем отношения. Это принято называть эволюцией схемы базы данных.
Реляционная база данных – это набор отношений, имена которых совпадают с именами схем отношений в схеме БД.
Как видно, основные структурные понятия реляционной модели данных (если не считать понятия домена) имеют очень простую интуитивную интерпретацию, хотя в теории реляционных БД все они определяются абсолютно формально и точно.
Основные свойства отношений
Остановимся теперь на некоторых важных свойствах отношений, которые следуют из приведенных ранее определений:
То свойство, что отношения не содержат кортежей-дубликатов, следует из определения отношения как множества кортежей. В классической теории множеств по определению каждое множество состоит из различных элементов.
Во многих практических реализациях реляционных СУБД допускается нарушение свойства уникальности кортежей для промежуточных отношений, порождаемых неявно при выполнении запросов. Такие отношения являются не множествами, а мультимножествами, что в ряде случаев позволяет добиться определенных преимуществ, но иногда приводит к серьезным проблемам.
Отсутствие упорядоченности кортежей
Свойство отсутствия упорядоченности кортежей отношения также является следствием определения отношения-экземпляра как множества кортежей. Отсутствие требования к поддержанию порядка на множестве кортежей отношения дает дополнительную гибкость СУБД при хранении баз данных во внешней памяти и при выполнении запросов к базе данных. Это не противоречит тому, что при формулировании запроса к БД, например, на языке SQL можно потребовать сортировки результирующей таблицы в соответствии со значениями некоторых столбцов. Такой результат, вообще говоря, не отношение, а некоторый упорядоченный список кортежей.
Отсутствие упорядоченности атрибутов
Атрибуты отношений не упорядочены, поскольку по определению схема отношения есть множество пар . Для ссылки на значение атрибута в кортеже отношения всегда используется имя атрибута. Это свойство теоретически позволяет, например, модифицировать схемы существующих отношений не только путем добавления новых атрибутов, но и путем удаления существующих атрибутов. Однако в большинстве существующих систем такая возможность не допускается, и хотя упорядоченность набора атрибутов отношения явно не требуется, часто в качестве неявного порядка атрибутов используется их порядок в линейной форме определения схемы отношения.
Атомарность значений атрибутов
Значения всех атрибутов являются атомарными. Это следует из определения домена как потенциального множества значений простого типа данных, т.е. среди значений домена не могут содержаться множества значений (отношения). Принято говорить, что в реляционных базах данных допускаются только нормализованные отношения или отношения, представленные в первой нормальной форме. Потенциальным примером ненормализованного отношения является следующее:
Можно сказать, что здесь имеется бинарное отношение, значениями атрибута ОТДЕЛЫ которого являются отношения. Заметим, что исходное отношение СОТРУДНИКИ является нормализованным вариантом отношения ОТДЕЛЫ:
СОТР_НОМЕР | СОТР_ИМЯ | СОТР_ЗАРП | СОТР_ОТД_НОМЕР |
2934 | Иванов | 112,000 | 310 |
2935 | Петров | 144,000 | 310 |
2936 | Сидоров | 92,000 | 313 |
2937 | Федоров | 110,000 | 310 |
2938 | Иванова | 112,000 | 315 |
Нормализованные отношения составляют основу классического реляционного подхода к организации баз данных. Они обладают некоторыми ограничениями (не любую информацию удобно представлять в виде плоских таблиц), но существенно упрощают манипулирование данными. Рассмотрим, например, два идентичных оператора занесения кортежа:
Зачислить сотрудника Кузнецова (пропуск номер 3000, зарплата 115,000) в отдел номер 320 и
Зачислить сотрудника Кузнецова (пропуск номер 3000, зарплата 115,000) в отдел номер 310.
Если информация о сотрудниках представлена в виде отношения СОТРУДНИКИ, оба оператора будут выполняться одинаково (вставить кортеж в отношение СОТРУДНИКИ). Если же работать с ненормализованным отношением ОТДЕЛЫ, то первый оператор выразится в занесение кортежа, а второй – в добавление информации о Кузнецове в множественное значение атрибута ОТДЕЛ кортежа с первичным ключом 310.
Реляционная модель данных
Согласно Дейту реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части.
В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение.
В манипуляционной части модели утверждаются два фундаментальных механизма манипулирования реляционными БД – реляционная алгебра и реляционное исчисление. Первый механизм базируется в основном на классической теории множеств (с некоторыми уточнениями), а второй – на классическом логическом аппарате исчисления предикатов первого порядка. Основной функцией манипуляционной части реляционной модели является обеспечение меры реляционности любого конкретного языка реляционных БД: язык называется реляционным, если он обладает не меньшей выразительностью и мощностью, чем реляционная алгебра или реляционное исчисление.
В целостной части реляционной модели данных фиксируются два базовых требования целостности, которые должны поддерживаться в любой реляционной СУБД. Первое требование называется требованием целостности сущностей. Объекту или сущности реального мира в реляционных БД соответствуют кортежи отношений. Конкретно требование состоит в том, что любой кортеж любого отношения отличим от любого другого кортежа этого отношения, т.е. другими словами, любое отношение должно обладать первичным ключом. Это требование автоматически удовлетворяется, если в системе не нарушаются базовые свойства отношений.
Второе требование называется требованием целостности по ссылкам и является несколько более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности реального мира представляются в реляционной БД в виде нескольких кортежей нескольких отношений. Например, представим, что требуется представить в реляционной базе данных сущность ОТДЕЛ с атрибутами ОТД_НОМЕР (номер отдела), ОТД_КОЛ (количество сотрудников) и ОТД_СОТР (набор сотрудников отдела). Для каждого сотрудника нужно хранить СОТР_НОМЕР (номер сотрудника), СОТР_ИМЯ (имя сотрудника) и СОТР_ЗАРП (заработная плата сотрудника). При правильном проектировании соответствующей БД в ней появятся два отношения: ОТДЕЛЫ (ОТД_НОМЕР, ОТД_КОЛ) (первичный ключ – ОТД_НОМЕР) и СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ИМЯ, СОТР_ЗАРП, СОТР_ОТД_НОМ) (первичный ключ – СОТР_НОМЕР).
Как видно, атрибут СОТР_ОТД_НОМ появляется в отношении СОТРУДНИКИ не потому, что номер отдела является собственным свойством сотрудника, а лишь для того, чтобы иметь возможность восстановить при необходимости полную сущность ОТДЕЛ. Значение атрибута СОТР_ОТД_НОМ в любом кортеже отношения СОТРУДНИКИ должно соответствовать значению атрибута ОТД_НОМ в некотором кортеже отношения ОТДЕЛЫ. Атрибут такого рода называется внешним ключом, поскольку его значения однозначно характеризуют сущности, представленные кортежами некоторого другого отношения (т.е. задают значения их первичного ключа). Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом.
Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в отношении, на которое ведет ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать). Для примера это означает, что если для сотрудника указан номер отдела, то этот отдел должен существовать.
Ограничения целостности сущности и по ссылкам должны поддерживаться СУБД. Для соблюдения целостности сущности достаточно гарантировать отсутствие в любом отношении кортежей с одним и тем же значением первичного ключа. С целостностью по ссылкам дела обстоят несколько более сложно.
Понятно, что при обновлении ссылающегося отношения (вставке новых кортежей или модификации значения внешнего ключа в существующих кортежах) достаточно следить за тем, чтобы не появлялись некорректные значения внешнего ключа. Но как быть при удалении кортежа из отношения, на которое ведет ссылка?
Запрещается производить удаление кортежа, на который существуют ссылки (т.е. сначала нужно либо удалить ссылающиеся кортежи, либо соответствующим образом изменить значения их внешнего ключа).
При удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение внешнего ключа автоматически становится неопределенным.
При удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи (каскадное удаление).
ограничения на допустимые значения в наборе значений (домене). Домен можно трактовать как область определения атрибута, которая может быть задана либо непрерывным или дискретным интервалом, либо фиксированным списком значений.
ограничения на разрешенные значения для каждого атрибута. Например, возраст сотрудников может быть ограничен интервалом от 18 до 65 лет.
ограничения на существующие значения в базе данных. Например, сумма отчислений с зарплаты сотрудника не должна превышать самой зарплаты.
Пример
В таблице не может быть двух одинаковых строк. В математике таблицы, обладающие таким свойством, называют отношениями (англ. relation), отсюда и название – реляционные.
Столбцы располагаются в определенном порядке, который создается при создании таблицы. В таблице может не быть ни одной строки, но обязательно должен быть хотя бы один столбец.
У каждого столбца есть уникальное имя (в пределах таблицы), и все значения в одном столбце имеют один тип (число, текст, дата. ).
На пересечении каждого столбца и строки может находиться только атомарное значение (одно значение, не состоящее из группы значений). Таблицы, удовлетворяющие этому условию, называют нормализованными.
База данных готова. Схематично ее можно представить так:
В данной маленькой базе данных всего три таблички, а если бы их было 10 или 100? Понятно, что сразу невозможно представить все таблицы, поля и связи, которые могут понадобиться. Именно поэтому проектирование базы данных начинается с ее концептуальной модели (ER-модели).
Преобразование концептуальной модели в реляционную
Построить набор предварительных таблиц и указать первичные ключи.
Провести процесс нормализации.
Концептуальная модель имеет вид:
Набор предварительных таблиц, исходя из концептуальной модели, выглядит так:
Нормализация – это пошаговый, обратимый процесс замены исходной схемы другой схемой, в которой таблицы имеют более простую и логичную структуру.
Для чего это нужно? Во-первых, для устранения избыточности данных. Например, в примере для форума (см. предыдущий раздел), осталась бы вот такая таблица:
1НФ – первая нормальная форма
2НФ – вторая нормальная форма
3НФ – третья нормальная форма
НФБК – нормальная форма Бойса-Кодда
4НФ – четвертая нормальная форма
Каждая нормальная форма налагает определенные ограничения на данные. Каждая нормальная форма более высокого уровня предполагает, что анализируемая таблица уже находится в нормальной форме на уровень ниже рассматриваемой. В ходе нормализации схема базы данных становится все более строгой, а ее таблицы все менее подвержены различного рода аномалиям. Для реляционных баз данных необходимо, чтобы ее таблицы находились в 1НФ. Нормальные формы более высоких уровней могут использоваться разработчиками по своему усмотрению. Однако грамотный специалист стремится к тому, чтобы довести уровень нормализации базы данных хотя бы до 3НФ, тем самым исключив избыточность данных и аномалии обновления. Надо сказать, что НФБК, 4НФ и 5НФ используются крайне редко. Поэтому рассмотрим только первые три.
Первая нормальная форма
Таблица находится в первой нормальной форме, если все ее поля имеют простые (атомарные) значения. Само понятие атомарности определить достаточно трудно. Значение, атомарное в одном случае, может быть неатомарным в другом. Общий принцип здесь такой: значение не атомарно, если оно используется по частям.
Вторая нормальная форма
Эта форма применяется к таблицам с составными ключами. Таблица, у которой первичный ключ включает только одно поле, всегда находится во 2НФ. Таблица находится во второй нормальной форме, если она находится в первой нормальной форме, а каждое неключевое поле функционально полно зависит от составного ключа.
Третья нормальная форма
Таблица находится в третьей нормальной форме, если она находится во второй нормальной форме, и каждое неключевое поле нетранзитивно зависит от первичного ключа. Транзитивная зависимость наблюдается в том случае, если одно из двух неключевых полей зависит от первичного ключа, а другое зависит от первого неключевого поля.
Подведем итог. Схема базы данных после нормализации несколько изменилась и выглядит теперь так:
Таким образом, мы преобразовали концептуальную модель в реляционную. Дальше необходимо эту модель реализовать в конкретной СУБД. Для этого нам понадобится сама СУБД и знание языка SQL.
Заключение
На сегодняшний день реляционные базы данных остаются самыми распространенными, благодаря своей простоте и наглядности как в процессе создания так и на пользовательском уровне.
Основным достоинством реляционных баз данных совместимость с самым популярным языком запросов SQL. С помощью единственного запроса на этом языке можно соединить несколько таблиц во временную таблицу и вырезать из нее требуемые строки и столбцы (селекция и проекция). Так как табличная структура реляционной базы данных интуитивно понятна пользователям, то и язык SQL является простым и легким для изучения. Реляционная модель имеет солидный теоретический фундамент, на котором были основаны эволюция и реализация реляционных баз данных. На волне популярности, вызванной успехом реляционной модели, SQL стал основным языком для реляционных баз данных.
Список использованных источников:
Дейт К. Руководство по реляционной СУБД DB2. - М.: Финансы и статистика, 1988. - 320 с.
Кириллов В.В. Основы проектирования реляционных баз данных .Учебное пособие. - СПб.: ИТМО, 1994. - 90 с.
Мейер М. Теория реляционных баз данных. -М.: Мир, 1987. - 608 с.
Ульман Дж. Базы данных на Паскале. -М.: Машиностроение, 1990. - 386 с.
В текущее время самое разное программное обеспечение находит применение в жизни человека. Программы упрощают жизнь и деятельность человека приходя на помощь человеку практически в каждом аспекте его жизни.
Примером такого программного обеспечения могут являться базы данных. Под базой данных (БД) понимают совокупность хранящихся вместе данных при наличии такой минимальной избыточности, которая допускает их использование для одного или нескольких приложений [7].
Для работы с базами данных используются системы управления базами данных (СУБД). Система управления базой данных (СУБД) – совокупность программных средств, обеспечивающих управление базой данных на всех уровнях [6].
Актуальность данной темы заключается в том, что применение баз данных и систем управления баз данных отвечает требования сегодняшнего дня и позволяет эффективно работать с данными.
Целью реферата является изучение теоретических основ реляционной модели баз данных.
Для достижения поставленной цели необходимо решить следующие задачи:
Изучить основные понятия, применяемые в реляционной базе данных;
Изучить ограничения, существующие в реляционной модели;
Изучить преимущества реляционной модели базы данных.
РЕЛЯЦИОННАЯ МОДЕЛЬ БАЗЫ ДАННЫХ
Название для реляционной модели дал сотрудник компании IBM Эдгар Кодд, оно происходит от английского слова relation или отношение по-русски [2]. Идея реляционной модели базы данных это связанная определёнными отношениями совокупность таблиц. Предметная область определяет характер связей между таблицами, а сама связь определяется на логическом уровне.
Основные понятия в реляционной базе данных
Отношение – это определённые данные хранящиеся в двумерной таблице [2].
Сущность – это объект любого характера, данные его описывающие хранятся в базе данных. Данные отвечающие за сущность хранятся как правило в отношении [2].
Атрибуты — это некоторые свойства, описывающие сущность. В составе таблицы все атрибуты называются и имеют свой определённый заголовок столбца таблицы [2].
Домен – это некоторое множество значений некоторого атрибута отношения. Все домены формируют значения определённого типа данных [2].
Таблицы – это основные объекты реляционной базы данных для хранения информации. Таблицы и их структура определяют структуру базы данных[2] .
Рисунок 1 – Пример таблицы базы данных
Первичным ключом называют атрибут отношения, однозначно идентифицирующий запись.
Ключ может быть простым и составным. Простой имеет в своём составе один атрибут, а составной ряд атрибутов. Различные комбинации атрибутов могут являться возможными ключами отношения и любой из этих ключей может быть выбран как первичный. При минимальном составе атрибутов в ключе его называют не избыточным.
Между любыми двумя таблицами может существовать одна из трёх видов отношений:
Один к одному – записи в одной таблице может соответствовать только одна запись в другой таблице;
Один ко многим – одной записи в одной таблице может соответствовать много записей в другой таблице;
Многие ко многим – множеству записей в одной таблице может соответствовать множество записей в другой таблице.
Рисунок 2 – Пример связей между таблицами
В самой базе данных такие отношения представлены с помощью атрибутов, значением которых являются первичные ключи в других таблицах. Такие атрибуты называются вторичными ключами [2].
Как правило реляционная база данных состоит из ряда взаимосвязанных таблиц, хотя в порядке исключения таблица может быть и одной. Процесс организации связей между различными таблицами называется соединением таблиц.
Таблицы могут связываться в следующих случаях:
При создании схемы данных с помощью соединения таблиц в базе данных;
При разработке запросов к используемой базе данных;
При связывании таблицы из текущей базы данных с таблицей, находящейся в другой базе данных [2].
Процесс связывания может применяться как к двум, так и к нескольким таблицам. Для связывания таблиц применяют поля связи, такие поля обязательно должны быть индексированными [2].
Связь между таблицами характеризует и определяет отношение в аспекте подчинённости, при котором одна таблица является главной или родительской, а другая подчинённой или дочерней [2].
Процесс проектирования реляционной базы данных заключается в разработке структуры данных, то есть в выборе структуры состава таблицы и необходимых связей между ними. Создаваемая структура должна быть эффективной, а также:
Обеспечивать быстрый доступ к хранимым данным;
Обеспечивать отсутствие повторения данных ;
Обеспечивать целостность данных[2] .
Проектирование структуры данных именуют также проектирование на логическом уровне базы данных.
Есть три основных подхода при проектировании на логическом уровне базы данных:
Сбор необходимой информации об предметной области решаемой задачи в рамках таблицы и последующая декомпозиция на ряд меньших взаимосвязанных таблиц с соблюдением правил нормализации:
Формулирование знаний о системе и требований к обработке данных и последующее получение схемы базы данных с помощью средств автоматизации разработки программного обеспечения;
Структурирование информации в процессе ;
Проведение системного анализа и структурирование информации на основе свода правил и рекомендаций [2].
Схемой базы данных называют набор таблиц и совокупность всех связей между ними.
Ограничения реляционной модели
В реляционной модели определён ряд ограничений для контроля целостности данных, избыточности и допустимости.
избыточность: кортежи-дубликаты (кортеж — это упорядоченный набор данных) запрещены в отношении [1];
допустимость: доменные ограничения контролируют допустимость данных [1];
целостность: отношения в базе данных связаны друг с другом. Операция над одним отношением, например, обновление или удаление кортежа, может оставить другое отношение в некорректном состоянии [1].
Ограничения в реляционной базе данных можно отнести к двум категориям:
унаследованные от реляционной модели: ограничения доменной целостности, целостности сущностей и ссылочной целостности [1];
семантические ограничения, бизнес-правила и ограничения, свойственные приложению, которые нельзя явно выразить средствами реляционной модели. Однако появление процедурных языков на основе SQL, в частности, PL/pgsql в PostgreSQL, позволило моделировать такие ограничения и в реляционной базе данных [1].
Ограничение доменной целостности гарантирует допустимость данных.
Типом данных домена может быть integer, real, boolean, character, text, inet и так далее, например, имя и адрес электронной почты имеют тип text. Зная тип данных, можно уже определить проверочное ограничение, например, шаблон почтового адреса [1].
Проверочное ограничение: такое ограничение применяется к одному атрибуту или к группе атрибутов [1].
Ограничение умолчания: у атрибута может быть значение по умолчанию. Это может быть либо фиксированное значение, например, стандартная почасовая оплата труда, например, 10 долларов. Или же динамически вычисляемое значение, например, значение функции random, current time или date [1].
Ограничение уникальности: гарантирует, что значение атрибута уникально среди всех кортежей отношения. Допускается также значение null.
Ограничение not null: по умолчанию атрибут может принимать значение null. Ограничение not null запрещает это. Например, у каждого человека в книге записей о рождении должно быть имя.
Ограничение сущностной целостности.
В реляционной модели отношение определяется как множество кортежей. Это означает, что все кортежи в нем должны быть различны. Ограничение сущностной целостности означает наличие первичного ключа, представляющего собой один или несколько атрибутов со следующими характеристиками [1]:
ключ должен быть уникален;
ни один атрибут, входящий в ключ, не должен принимать значение null [1].
В каждом отношении может быть только один первичный ключ, но много уникальных ключей. Ключ-кандидат – это минимальный набор атрибутов, с помощью которых можно однозначно идентифицировать кортеж. Любой уникальный, не принимающий значения null атрибут может быть ключом кандидатом. Набор, состоящий из всех атрибутов, образует суперключ [1].
На практике часто выбирают в качестве первичного ключа один атрибут, а не составной ключ (состоящий из двух или более атрибутов), чтобы было проще соединять отношения между собой [1].
Первичный ключ, генерируемый СУБД, называют суррогатным, или синтетическим. В противном случае ключ называется натуральным. В роли суррогатных ключей-кандидатов могут выступать порядковые номера или универсальные уникальные идентификаторы (UUID) [1].
У суррогатных ключей много преимуществ, в том числе высокая производительность, устойчивость к изменению требований, адаптируемость и совместимость с объектно-реляционными отображениями. Главный недостаток суррогатных ключей состоит в том, что они открывают возможность для появления кортежей-дубликатов, отличающихся только значением ключа [1].
Ограничения ссылочной целостности.
Отношения связаны между собой общими атрибутами. Ограничения ссылочной целостности контролируют связи между двумя отношениями и гарантируют, что данные в кортежах согласованы. Если кортеж одного отношения ссылается на кортеж другого отношения, то этот второй кортеж должен существовать [1].
Отсутствие ограничений ссылочной целостности может стать причиной многих проблем:
некорректные данные в общих атрибутах [1];
некорректная информация при соединении данных из разных отношений;
снижение производительности из-за неоптимального плана выполнения, построенного планировщиком или сторонней программой [1].
Для гарантии целостности данных существует несколько типов поведения в случае, когда кортеж во внешнем отношении обновляется или удаляется:
каскадом: если кортеж во внешнем отношении удаляется или его внешний атрибут обновляется, то ссылающиеся на него кортежи первичного отношения также удаляются или обновляются [1];
запрет: кортеж, на который ведет ссылка, не может быть удален, а его внешний атрибут не может быть изменен;
ничего не делать: то же, что запрет, но решение откладывается до конца транзакции [1];
присваивание значения по умолчанию: если кортеж во внешнем отношении удаляется или внешний атрибут обновляется, то внешнему ключу в первичном отношении присваивается значение по умолчанию [1];
присваивание null: если кортеж во внешнем отношении удаляется, то внешнему ключу в первичном отношении присваивается значение null [1].
Ограничения целостности или ограничения бизнес-логики касаются приложения в целом. Например, в любой момент у клиента может быть не более одной активной службы. Такие ограничения проверяются либо на уровне бизнес-логики прикладной программы, либо с помощью процедурных языков на основе SQL. Для этой цели можно также использовать триггеры и правила [1].
Какой подход выбрать – процедурный язык на основе SQL или высокоуровневый язык программирования, – зависит от приложения; иногда комбинируют оба. У процедурного языка на основе SQL имеются следующие преимущества[1]:
производительность: в реляционных системах управления баз данными часто имеются сложные оптимизаторы для построения эффективных планов выполнения. А в некоторых случаях, например, в приложениях добычи данных, объем обрабатываемых данных очень велик. Обработка на процедурном языке позволяет исключить передачу данных по сети. Кроме того, в некоторых процедурных языках применяются сложные алгоритмы кеширования [1];
срочные изменения: процедурный язык на основе SQL позволяет исправлять ошибки, не останавливая службу [1].
Преимущества реляционной базы данных
К преимуществам можно отнести следующее:
Простота. Представление различных структур данных с помощью двумерных таблиц является одним из самых простых способов взаимодействия с базой данных [3];
Теоретическое обоснование. Отношения, широко используемые в реляционной модели, могут быть описаны и использованы в соответствии с математическими методами, такими как реляционная алгебра [3];
Контроль секретности. Ограничение доступа к данным упрощается при использовании отношений в реляционной модели [3];
Понятность. Реляционная модель упрощает понимание всего массива отношений атрибутов. Размещение таблиц на физическом уровне проще чем работа со структурами в других моделях [3];
Снижение требований к программному и аппаратному обеспечению благодаря отказу от использования сложных указателей связей в файлах [3];
Простота масштабируемости базы данных и изменения хранимых данных. База данных, а точнее её структура предполагает возможность её увеличения, например, появление новых атрибутов. Реляционная модель имеет хорошие показатели масштабируемости[3].
Рисунок 3 – принцип работы технологии клиент-сервер
Уже несколько десятилетий клиент-серверное построение БД является доминирующим. Причин тому несколько:
значительно повышается доступность БД. Сервер представляет собой открытую систему, поэтому клиентские компьютеры могут функционировать под управлением различных операционных систем и с различным ПО [4];
выделенный сервер СУБД в состоянии обеспечить параллельную многопользовательскую обработку данных [4];
основные правила поддержки целостности и непротиворечивости данных описываются на одном сервере СУБД, клиентские приложения никаким образом не в состоянии обойти эти правила [4];
экономно расходуется пропускная способность компьютерных сетей [4];
благодаря централизованному хранению данных сравнительно просто поддерживать единые для всех правила безопасности БД [4];
наличие стандарта на основной язык общения SQL обеспечивает широкие возможности доступа к серверу БД из программного обеспечения различных производителей [4];
упрощены вопросы обслуживания и администрирования БД [4].
Подводя итог можно сказать, что вышеописанные преимущества реляционной модели данных обеспечили ей повсеместное применение.
На сегодняшний день информационные технологии всё сильнее включаются в жизнь человека. Одной из такой технологии являются базы данных. Невозможно себе представить сегодня систему учёта и хранения данных без баз данных и систем управления баз данных. Эти технологии применяются повсеместно для обеспечения эффективной работы как частных, так и государственных предприятий.
На текущий момент базы данных основанные на реляционной модели данных являются наиболее применяемыми.
В процессе выполнения реферата были достигнуты все поставленные цели, а именно изучение основных понятий, применяемых в реляционной модели баз данных, её преимущества и ограничения.
Цель реферата в виде изучения теоретических основ реляционной модели баз данных достигнута.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
Джуба, С. Изучаем PostgreSQL 10 [Текст] / С. Джуба, А. Волков. - Москва: ДМК Пресс, 2018. – 400 с.
Красновидов, А.В. Инструментальные средства информационных систем: учебное пособие [Текст]/ А. В. Красновидов, С. Г. Свистунов, П. А. Новиков. - Санкт-Петербург: ПГУПС, 2015. – 48 с.
Медведкова, И.Е. Базы данных: учебное пособие [Текст]/ И.Е. Медведкова, Ю.В. Бугаев, С.В. Чикунов - Воронеж: ВГУИТ, 2015. – 108 с.
Осипов, Д.Л. Технологии проектирования баз данных [Текст] / Д.Л. Осипов. – Москва: ДМК Пресс, 2019. – 498 с.
Советов, Б.Я. Информационные технологии: теоретические основы: учебное пособие [Текст]/ Б.Я. Советов, В.В. Цехановский. - Санкт-Петербург: Лань, 2017. – 444 с.
Цехановский, В.В. Управление данными [Текст]/ В.В. Цехановский, В.Д. Чертовской. - Санкт-Петербург: Лань, 2015. – 432 с.
Человечество стремительно вступает в принципиально новую для него информационную эпоху. Существенным образом меняются все слагаемые образа жизни людей. В современном обществе уровень информатизации характеризует уровень развития государства. Начавшийся ХХI век специалисты называют веком компьютерных технологий. Их революционное воздействие касается государственных структур и институтов гражданского общества, экономической и социальной сфер, науки и образования, культуры и образа жизни людей. Многие развитые и развивающиеся страны в полной мере осознали те колоссальные преимущества, которые несет с собой развитие и распространение информационно-коммуникационных технологий. Не у кого не вызывает сомнения тот факт, что движение к информационному обществу - это путь в будущее человеческой цивилизации
Содержание
Введение
4
1 Теоретические аспекты изучения реляционных моделей данных: сущность, понятие и виды
6
1.1 Понятие и сущность модели данных в информационных технологиях
6
1.2 Базовые понятия реляционной модели данных
10
1.3 Свойства отношений реляционной модели данных
19
2 Создание реляционной базы данных в программном комплексе Microsoft Ассеss
23
2.1 Общее понятие о реляционной базе данных
23
2.2 Создание реляционной базы данных
26
2.3 Создание запросов в реляционной базе данных
29
Заключение
36
Список использованных источников
Работа состоит из 1 файл
Реляционная модель данных.docx
1 Теоретические аспекты изучения реляционных моделей данных: сущность, понятие и виды
1.1 Понятие и сущность модели данных в информационных технологиях
1.2 Базовые понятия реляционной модели данных
1.3 Свойства отношений реляционной модели данных
2 Создание реляционной базы данных в программном комплексе Microsoft Ассеss
2.1 Общее понятие о реляционной базе данных
2.2 Создание реляционной базы данных
2.3 Создание запросов в реляционной базе данных
Список использованных источников
Человечество стремительно вступает в принципиально новую для него информационную эпоху. Существенным образом меняются все слагаемые образа жизни людей. В современном обществе уровень информатизации характеризует уровень развития государства. Начавшийся ХХI век специалисты называют веком компьютерных технологий. Их революционное воздействие касается государственных структур и институтов гражданского общества, экономической и социальной сфер, науки и образования, культуры и образа жизни людей. Многие развитые и развивающиеся страны в полной мере осознали те колоссальные преимущества, которые несет с собой развитие и распространение информационно-коммуникационных технологий. Не у кого не вызывает сомнения тот факт, что движение к информационному обществу - это путь в будущее человеческой цивилизации [3].
В соответствии с реляционной моделью база данных представляется в виде совокупности таблиц, над которыми могут выполняться операции, формулируемые в терминах реляционной алгебры и реляционного исчисления. В реляционной модели операции над объектами базы данных имеют теоретико-множественный характер. Концепции реляционной модели данных связаны с именем известного специалиста в области систем баз данных Е. Кодда. Именно поэтому реляционную модель данных часто называют моделью Кодда.
Ядром любой базы данных является модель данных. Модель данных представляет собой множество структур данных, ограничений целостности и операций манипулирования данными. С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними.
Основными идеями современных информационных технологий является концепция о том, что все данные должны быть организованы в базы данных. Это делается для того, чтобы была возможность адекватно отображать изменяющийся реальный мир и в полном объеме удовлетворить информационные потребности пользователей. Создание и функционирование таких баз данных управляются специальными программными комплексами - системами управления базами данных (СУБД).
Причиной широкого распространения удобных и простых для восприятия реляционных (табличных) СУБД послужило увеличение объема и структурной сложности хранимых данных, расширение круга пользователей информационных систем. Чтобы обеспечить одновременный доступ к данным различным пользователям, находящимся на значительном расстоянии друг от друга и от места хранения баз данных, были созданы сетевые мультипользовательские версии БД основанных на реляционной структуре. Их основной задачей является решение специфических проблем параллельных процессов, целостности (правильности) и безопасности данных, а также санкционирование доступа. Это и обусловило актуальность темы курсовой работы.
Объектом исследования курсовой работы является реляционная модель данных.
Предметом исследования выступает процесс создания реляционной базы данных.
Цель работы – провести изучение реляционных моделей данных и рассмотреть пример создания реляционной базы данных с использованием Microsoft Ассеss.
Задачи курсового исследования:
- рассмотреть понятие и сущность реляционной модели данных;
- изучить свойства отношений реляционной модели данных;
- рассмотреть создание реляционной модели данных в Microsoft Ассеss;
- изучить создание запросов в базе данных.
Методической и информационной основной курсовой работы явились труды отечественных и зарубежных авторов, статьи и публикации периодических изданий печати, обзоры по данной тематике в сети Интернет и др.
1 Теоретические аспекты изучения реляционных моделей данных: сущность, понятие и виды
1.1 Понятие и сущность модели данных в информационных технологиях
Модель данных – совокупность структур данных и операций их обработки.
Модели данных определяются:
- способами организации данных.
- ограничением ценности данных.
- операциями с данными.
СУБД основывается на использовании иерархической, сетевой или реляционной модели, на комбинации этих моделей или на некотором их подмножестве.
Рассмотрим 3 основных типа моделей данных: иерархическую, сетевую и реляционную.
Иерархическая модель данных
а) Иерархическая структура представляет совокупность элементов, связанных между собой по определённым правилам. Объекты, связанные иерархическими отношениями, образуют ориентированный граф (перевёрнутое дерево), вид которого представлен на рисунке 1.
В1 В2 В3 В4 В5 Уровень 2
С1 С2 С3 С4 С5 С6 С7 С8 Уровень 3
Рисунок 1.1 – Иерархическая структура
К основным понятиям иерархической структуры относятся: уровень, элемент (узел), связь.
Узел – это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину (корень дерева), не подчинённую никакой другой вершине и находящуюся на самом верхнем (первом) уровне. Зависимые (подчинённые) узлы находятся на втором, третьем и т.д. уровнях. Количество деревьев в базах данных определяется числом корневых записей. К каждой Записи базы данных существует только 1 иерархический путь от корневой записи. Например, как видно на рисунке 1.1 для записи С4 путь проходит через записи А и В3.
Пример, представленный на рисунке 1.2 иллюстрирует использование иерархической модели базы данных. Для рассматриваемого примера иерархическая структура правомерна, т.к. каждый студент учится в определённой (только одной) группе, которая относится к определённому (только одному) институту [3, c. 35].
b) Ограничение целостности- целостность ссылок между предком и потомком с учетом основного правила: никакой потомок не может существовать без предка.
Читайте также: