Основные сведения теории баз данных

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

Рубрика Программирование, компьютеры и кибернетика
Вид реферат
Язык русский
Дата добавления 15.12.2015
Размер файла 66,0 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

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

Реферат

Основные сведения теории баз данных. История развития баз данных

Содержание

Введение

1. Основные сведения теории баз данных. История развития баз данных

1.1 Примеры использования баз данных (БД). Предшественники современных БД

1.2 Система управления базами данных (СУБД)

1.3 Компоненты СУБД

1.4 Общая архитектура СУБД. Трехуровневая архитектура ANSI-SPARC

1.5 Многопользовательские СУБД и сети. Архитектура «клиент-сервер»

1.6 Трехуровневая (трехзвенная) архитектура Интернета. «Тонкие» и «толстые» клиенты

1.7 Модели данных. Основные типы моделей данных

1.8 Элементы теории множеств

1.9 Структура реляционных данных

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

1.11 Реляционная схема и схема реляционной базы данных

1.12 Целостность реляционных данных. Трехзначная логика (3VL)

1.13 Ограничения целостности

1.14 Операции, которые могут нарушить ссылочную целостность

1.15 Стратегии поддержания ссылочной целостности

1.16 Представления

1.17 Реляционная алгебра и реляционное исчисление

1.18 Основные операции реляционной алгебры

1.19 Операция соединения

Литература

Введение

Базы данных стали основой современных информационных систем. В настоящий момент системы управления базами данных (СУБД) предоставляют пользователю мощные и удобные в эксплуатации средства разработки и сопровождения баз данных.

За несколько последних десятилетий технология баз данных проделала значительный путь от файловых систем, положивших начало компьютерной обработке данных до мощных и гибких систем управления базами данных, удобных в использовании. Развитие теории баз данных привело к разработке наиболее широко применяемой в настоящее время реляционной модели данных, эффективной методологии проектирования баз данных, созданию структурированного языка запросов SQL, поддерживаемого большинством существующих СУБД и др.

Несомненно, любой разработчик баз данных должен обладать навыками проектирования эффективно работающих систем. Важной частью разработки хорошо спроектированной системы баз данных является построение логической модели данных, которая реализуется затем в среде выбранной СУБД. Основным же средством «общения» с СУБД, как правило, является язык SQL.

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

1. Основные сведения теории баз данных. История развития баз данных

1.1 Примеры использования баз данных (БД). Предшественники современных БД

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

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

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

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

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

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

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

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

Нетрудно видеть, что все эти проблемы обусловлены двумя неотъемлемыми свойствами файловых систем: определение данных содержалось внутри приложений, а не хранилось независимо от них; единственным средством доступа к данным и их обработке являлись приложения.

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

1.2 Система управления базами данных (СУБД)

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

Таким образом, база данных (БД) определяется однократно, а затем используется одновременно многими пользователями (например, представителями разных подразделений предприятия). База хранит не только рабочую информацию, но и описание данных. Элементы этого описания называют метаданными, т. е. «данными о данных». Именно наличие описания данных в самой базе обеспечивает независимость прикладных программ от данных. Иными словами, при таком подходе к хранению данных добавление (или изменение существующих) их структур никак не влияет на приложения, использующие БД. И только удаление одного или нескольких элементов из структуры данных приведет к необходимости модификации приложения.

Разработка баз данных состоит из двух основных этапов: логического проектирования и физической реализации.

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

Определение Сущности ? это отдельные типы объектов, которые нужно описать в базе данных.

Примерами сущностей являются: человек, предмет, событие и т. д. Атрибутами называют свойства, присущие описываемым объектам, например: стаж работы сотрудника в компании, его оклад и т. д. Наконец, связи - это то, что объединяет несколько сущностей. Логическую модель базы данных можно представить в виде так называемой диаграммы «сущность-связь», на которой графически изображаются сущности, их атрибуты и логические связи между ними. Более подробно моделирование данных будет рассмотрено позже.

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

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

Основная цель СУБД - дать пользователю абстрактное представление данных, скрыв особенности хранения и управления ими. СУБД взаимодействует как с прикладными программами пользователя, так и с базой данных.

Основные возможности систем управления базами данных:

_ позволяет создавать базу данных при помощи языка определения данных DDL (Data Definition Language). Язык определения данных предоставляет средства описания типа данных и их структуры, а также средства задания ограничений на эти данные;

_ позволяет производить операции вставки, обновления, удаления и выборки данных с помощью языка манипулирования данными DML (Data Manipulation Language). Язык DML используется как общий инструмент организации запросов и его часто называют языком запросов (query language);

_ предоставляет контролируемый доступ к базе данных с помощью следующих средств:

1) система предотвращения несанкционированного доступа пользователей к БД;

2) система поддержания целостности данных для обеспечения непротиворечивости хранимых данных;

3) система управления параллельной работой приложений, контролирующая их совместный доступ к БД;

4) система обработки транзакций (транзакция - операция или совокупность операций, которая либо выполняется целиком, либо не выполняется вообще);

5) система восстановления непротиворечивого состояния БД, нарушенного в результате программного или аппаратного сбоя;

6) доступного пользователям каталога с описанием хранимой в БД информации (т. н. «системного каталога»).

Важным свойством СУБД является механизм создания представлений, позволяющий любому пользователю иметь свой собственный «образ» базы данных. Он может рассматриваться как подмножество исходной БД, содержащее только те данные, которые действительно необходимы данному пользователю (или только те, к которым ему разрешено иметь доступ). Последнее обстоятельство позволяет обеспечить дополнительный уровень безопасности БД с помощью представлений.

1.3 Компоненты СУБД

К компонентам СУБД относятся аппаратное и программное обеспечение, данные и пользователи.

Аппаратное обеспечение для работы СУБД может представлять собой как один единственный персональный компьютер, так и целую сеть. Используемое аппаратное обеспечение определяется требованиями конкретной организации и типом СУБД. Одни СУБД могут работать лишь с конкретными типами операционных систем и оборудования, другие же (и среди современных СУБД их большинство) - с широким спектром аппаратного обеспечения и разными операционными системами. Для работы СУБД обычно необходим определенный минимум оперативной и дисковой памяти, который, впрочем, может оказаться недостаточным для достижения приемлемой производительности системы.

Под программным обеспечением СУБД понимают непосредственно саму СУБД (называемую также «сервер базы данных») в сочетании с прикладными программами, операционной системой и сетевым программным обеспечением, если СУБД используется в сети.

Как правило, приложения создаются на языках третьего поколения (C, C++, C#, Java и т. д.) с использованием языка запросов. СУБД может предоставлять и свои собственные инструменты для быстрой разработки приложений с использованием встроенных непроцедурных языков запросов, генераторов отчетов, форм, графики и даже полномасштабных приложений. Использование таких инструментов (инструментов четвертого поколения) позволяет существенно повысить производительность системы.

Данные - безусловно, самый важный компонент СУБД. Как отмечалось выше, база данных содержит не только рабочие данные, но и метаданные или «данные о данных». Обычно данные об одной предметной области хранятся в одной базе. Однако на практике могут возникать ситуации, когда информацию предпочтительно распределить по нескольким отдельным базам данных.

Доступ к данным в СУБД может быть интегрированным, когда пользователь воспринимает базу данных как объединение нескольких отдельных файлов, в которых хранится рабочая информация. Данные в СУБД могут также быть разделяемыми, т. е. различные пользователи могут получить доступ к одним и тем же данным, как последовательно, так и параллельно, т. е. одновременно.

Пользователи СУБД условно делятся на три группы: прикладные программисты, конечные пользователи и администраторы баз данных.

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

Конечные пользователи обращаются к базе данных при помощи таких приложений. При этом они могут и не подозревать о существовании СУБД. Более опытные пользователи могут «общаться» с СУБД, используя язык запросов.

Администраторы баз данных отвечают за физическую реализацию спроектированной заранее БД, за безопасность и целостность данных, а также за обеспечение максимальной производительности приложений.

1.4 Общая архитектура СУБД. Трехуровневая архитектура ANSI-SPARC

Исследовательской группой ANSI-SPARC (ANSI - American National Standard Institute и SPARC - Standards Planning and Requirements Committee) были предложены три уровня абстракции для организации структуры базы данных. Это внешний, концептуальный и внутренний уровни описания данных.

Именно на основе архитектуры ANSI-SPARC базируется архитектура большинства современных СУБД.

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

Определение Концептуальный уровень _ это общее представление БД, описывающее все данные, которые хранятся в ней. Этот уровень содержит логическую структуру всей базы данных. Именно на этом уровне представлены следующие компоненты:

- сущности, атрибуты и связи

- ограничения на данные

- семантическая информация о данных

- информация о том, как обеспечивается безопасность и целостность данных.

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

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

Определение Схемой базы данных называется ее описание. В соответствии с уровнями абстракции определяются и типы схем базы данных: совокупность внешних схем (соответствующих отдельным представлениям данных), концептуальная и внутренняя схемы. Именно концептуальная схема описывает все сущности, атрибуты и связи между ними. Наконец, внутренняя схема есть полное описание физической структуры данных.

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

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

1.5 Многопользовательские СУБД и сети. Архитектура «клиент-сервер»

Развитие компьютерных сетей и Интернета сыграли свою роль в развитии СУБД. Прежде и СУБД, и приложения находились на одном центральном компьютере. Пользователи подключались к центральному компьютеру с помощью терминалов (которые могли лишь принимать и отправлять информацию, но не обрабатывать ее).

Современным подходом является технология «клиент-сервер», при котором роль клиентского процесса выполняет приложение, отправляющее запросы к СУБД, а роль серверного процесса - сама СУБД, обрабатывающая эти запросы и отсылающая программе-клиенту результат. При этом совсем не обязательно, чтобы программа-клиент и программа-сервер находились на одном компьютере. На практике их принято размещать на разных узлах.

1.6 Трехуровневая (трехзвенная) архитектура Интернета. «Тонкие» и «толстые» клиенты

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

В терминологии баз данных клиенты-браузеры называют «тонкими клиентами». «Тонкие клиенты» способны лишь отображать информацию в строго определенном формате и отправлять серверу простейшие запросы. «Толстые клиенты» ориентированы на конкретные СУБД.

1.7 Модели данных. Основные типы моделей данных

Модель данных есть представление «реального мира» событий, объектов и существующих между ними связей. При построении модели учитываются лишь важнейшие их свойства, в то время как второстепенные игнорируются. Можно ввести следующее определение модели данных.

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

Можно выделить три компонента, из которых состоит модель данных:

1) набор правил, по которым может быть построена база данных

2) набор типов допустимых операций с данными и со структурой базы данных

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

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

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

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

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

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

Прорывом в теории баз данных следует считать разработку реляционной модели данных, предложенную доктором Э. Ф. Коддом (E. F. Codd). В 1970 г доктор Кодд опубликовал статью с описанием новой модели данных, позволявшей устранить недостатки прежних моделей и упростить структуру представления данных. Основная идея реляционной модели состояла в том, чтобы упразднить явные указатели на предков и потомков и представить все данные в виде набора простых таблиц.

Первые СУБД, основанные на иерархической модели данных, пришли на смену файловым системам в конце 60 годов XX века. Примером иерархической СУБД может служить СУБД IMS фирмы IBM. В силу ограниченной области применения иерархические СУБД использовались сравнительно недолго.

Достаточно скоро иерархические СУБД были заменены сетевыми (основанными на сетевой модели данных), которые можно рассматривать как расширение иерархических. Следует отметить, что термин «сетевая СУБД» относится лишь к используемой модели данных и не имеет отношения к локальным сетям или Интернет.

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

С 80-х годов XX века реляционные СУБД являются стандартом де-факто, однако существуют также объектно-ориентированные СУБД и объектно-реляционные СУБД. Более подробно реляционная модель данных будет рассмотрена ниже.

1.8 Элементы теории множеств

Реляционная модель основана на математическом понятии отношения, физической интерпретацией которого является таблица. Термин «отношение» (relation) и дал название модели. Отношения в реляционной модели обладают всеми свойствами математических отношений. На основании существующих отношений реляционной модели можно определять новые, используя операции реляционной алгебры. Напомним коротко основные сведения из теории множеств.

Определение Множество можно представить себе как совокупность элементов, объединенных каким-либо общим свойством. Множество не может содержать двух одинаковых элементов.

Определение Пусть даны n множеств D1, D2, …, Dn. Тогда R есть отношение над этими множествами, если R - множество упорядоченных наборов (n-местных кортежей) вида {d1, d2, …, dn}, где d1 - элемент из D1, d2 - элемент из D2, …, dn - элемент из Dn.

Определение Множества D1, D2, …, DN называются доменами отношения R.

Отношение R можно рассматривать как подмножество декартова произведения множеств D1, D2, …, Dn. Напомним, что декартово произведение определяется как совокупность всех упорядоченных n-местных кортежей вида {d1, d2, …, dn}:

.

Определение Число доменов называется степенью или размерностью отношения.

Определение Текущее число кортежей в отношении называется мощностью или кардинальным числом.

Определение Отношение, состоящее из одноэлементных кортежей, называется унарным отношением. Отношение степени 2 называют бинарным, а степени 3 - тернарным. Для отношений с большим количеством атрибутов (заданных на декартовом произведении n множеств) принят термин n-арное отношение.

Отношение можно представить в виде таблицы , в столбцах которой расположены домены, а в строках - кортежи (однотипные наборы элементов):

D1

D2

Dn

a1

a2

an

z1

z2

zn

1.9 Структура реляционных данных

Рассмотрим базовые понятия реляционной модели.

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

В реляционной модели именно отношения используются для хранения информации об объектах. Отношение имеет вид двумерной таблицы, в которой строки соответствуют записям (содержащим информацию об отдельных экземплярах объекта), а столбцы - атрибутам.

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

Атрибуты могут располагаться в любом порядке. Независимо от их переупорядочивания отношение будет иметь один и тот же смысл.

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

Каждый атрибут реляционной базы данных определяется на некотором домене. Домены могут отличаться для каждого из атрибутов, но разные атрибуты могут определяться на одном и том же домене. Следует отметить, что во многих реляционных СУБД домены поддерживаются не полностью, а лишь частично.

Определение Кортеж - строка отношения.

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

Определение Степень отношения определяется количеством атрибутов, которое оно содержит.

Например, отношение с одним атрибутом имеет степень 1 и называется унарным отношением или одноэлементным кортежем. Отношение с двумя атрибутами называют бинарным, а с тремя атрибутами - тернарным. Для отношений с большим количеством атрибутов принят термин n-арное отношение.

Определение Кардинальность отношения - это количество кортежей, которое содержится в отношении.

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

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

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

Перечислим свойства, которыми обладают реляционные отношения.

1) Каждое отношение имеет имя, отличающееся от имен всех других отношений в реляционной схеме.

2) Каждая ячейка таблицы (отношения) имеет ровно одно элементарное или неделимое значение.

3) Каждый атрибут имеет уникальное имя.

4) Значения атрибута берутся из одного и того же домена.

5) Каждый кортеж является уникальным.

6) Порядок следования атрибутов и кортежей не имеет значения.

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

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

Рассмотрим следующие виды реляционных ключей.

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

Суперключ может содержать и необязательные элементы для идентификации кортежа.

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

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

Отношение может иметь несколько потенциальных ключей.

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

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

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

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

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

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

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

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

Номер_отдела

Название_отдела

В01

бухгалтерия

В02

отдел кадров

В03

отдел разработок

В04

отдел продаж

Номер сотрудника

ФИО

Должность

Номер_отдела

S001

Иванов

лаборант

В03

S002

Петров

главный бухгалтер

В01

S003

Орлов

старший лаборант

В03

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

1.11 Реляционная схема и схема реляционной базы данных

Рассмотрим теперь понятия реляционной схемы и схемы реляционной БД.

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

Так, если даны атрибуты А1, А2, …, Аn с доменами D1, D2, …, Dn ,то реляционной схемой является множество .

Отношение, заданное такой реляционной схемой, является множеством n-арных кортежей вида , где . Например: {Имя: Федор, Фамилия: Иванов, Страна проживания: Россия}.

При записи этого отношения в виде таблицы имена атрибутов помещают в заголовках столбцов, а кортежи - в строках формата :

Имя

Фамилия

Страна проживания

Федор

Иванов

Россия

Иван

Петров

США

Такую конструкцию называют экземпляром отношения.

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

Отдел (Номер_отдела, Название_отдела)

Сотрудник (Номер сотрудника, ФИО Должность, Номер_отдела)

Атрибуты, являющиеся первичными ключами, выделяются подчеркиванием.

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

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

1.12 Целостность реляционных данных. Трехзначная логика (3VL)

Ограничения целостности реляционных данных гарантируют корректность этих данных. Рассмотрим прежде понятие null-значений и правила трехзначной логики.

Для представления информации в базе данных используются привычные типы данных ? строковые, числовые и т.д. Однако встречаются ситуации, когда данные об описываемом объекте не полны или неизвестны. Попытка заменить неизвестную информацию нулевым числовым значением, строкой пробелов или некоторыми фиктивными данными может привести к путанице или неправильной обработке данных. Можно попытаться заменить недостающие данные условной символьной строкой (например, «НЕИЗВЕСТНО»), но тогда придется создать специальную программу для обработки таких данных.

Для решения указанной проблемы были введены так называемые пустые значения или Null-значения.

Определение Null-значение предназначено для указания того, что значение атрибута в данный момент неизвестно или известно не полностью.

Пустое значение обозначается как NULL. Оно рассматривается как логическая величина «неизвестно». Применение NULL означает работу с трехзначной логикой. Следует отметить, что корректность введения NULL -значений не вполне обоснована теоретически. Так, непонятно например, входят ли NULL -значения в домены или нет. Тем не менее, несмотря на недостаточную теоретическую обоснованность использования NULL-значений, практически все реализации современных реляционных СУБД позволяют использовать их.

Поскольку NULL-значение отражает тот факт, что значение неизвестно, то алгебраические операции с NULL -значениями (сложение, умножение и т. п.) должны давать также неизвестное значение, т.е. NULL.

При сравнении выражений, содержащих NULL -значения, результат есть NULL, если один или оба аргумента есть NULL.

Таким образом, определение истинности логических выражений при использовании NULL базируется на трехзначной логике (three-valued logic, 3VL), в которой допустимыми являются три значения: T - ИСТИНА, F - ЛОЖЬ, U - НЕИЗВЕСТНО.

Трехзначная логика базируется на следующих таблицах истинности (таблицы 1, 2 и 3): база данный сервер реляционный

Таблица 1. Таблица истинности AND.

AND

F

T

U

F

F

F

F

T

F

T

U

U

F

U

U

Таблица 2. Таблица истинности OR.

OR

F

T

U

F

F

T

U

T

T

T

T

U

U

T

U

Таблица 3. Таблица истинности NOT.

NOT

F

T

T

F

U

U

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

- Выражение NULL = NULL дает значение не ИСТИНА, а НЕИЗВЕСТНО, т.е. NULL -значение не равно самому себе.

- Выражение NULL ? NULL также принимает значение не ИСТИНА, а НЕИЗВЕСТНО, т.е. неверно , что NULL -значение не равно самому себе.

- В трехзначной логике не работает принцип исключенного третьего (любое высказывание либо истинно, либо ложно), т. к. NULL OR NOT NULL не обязательно ИСТИНА.

1.13 Ограничения целостности

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

Определение Целостность сущностей: ни один атрибут первичного ключа не может содержать NULL -значений.

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

Второе ограничение, ссылочная целостность, относится к внешним ключам.

Определение Ссылочная целостность (целостность внешних ключей). Если в отношении существует внешний ключ, то каждое его значение должно соответствовать значению первичного ключа какого-либо кортежа в родительском отношении, либо иметь значение NULL.

Фактически внешние ключи служат ссылками на кортежи в другом (или в том же самом) отношении. Эти ссылки не должны указывать на несуществующие объекты. Иными словами, правило ссылочной целостности означает, что внешние ключи не должны быть несогласованными.

Например, в отношении Сотрудник атрибут Номер_отдела является внешним ключом, который ссылается на атрибут Номер_отдела из родительского отношения Отдел. СУБД не должна позволить создать в дочернем отношении Сотрудник запись с таким значением атрибута Номер_отдела, которого нет в родительском отношении Отдел. Однако в таблице Сотрудник может появиться запись с пустым значением (NULL -значением) атрибута Номер_отдела.

Дополнительные ограничения целостности могут налагать сами пользователи или администраторами базы данных. Например, если количество записей в какой-либо таблице не должно превышать 50, то СУБД должны быть переданы инструкции, запрещающие добавление в нее 51-й записи.

1.14 Операции, которые могут нарушить ссылочную целостность

Ссылочная целостность может быть нарушена в результате операций, которые изменяют состояние базы данных. Таких операций три ? вставка, обновление и удаление кортежей в отношениях. В определении ссылочной целостности участвуют и родительское, и дочернее отношение. В каждом из них возможны операции вставки, обновления и удаления. Поэтому необходимо рассмотреть различные варианты как для родительского, так и для дочернего отношения:

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

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

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

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

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

_ удаление кортежа в дочернем отношении. При удалении кортежа в дочернем отношении ссылочная целостность, очевидно, не нарушается.

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

1) Обновление кортежа в родительском отношении.

2) Удаление кортежа в родительском отношении.

3) Вставка кортежа в дочернее отношение.

4) Обновление кортежа в дочернем отношении.

1.15 Стратегии поддержания ссылочной целостности

Существуют две основные стратегии поддержания ссылочной целостности.:

- RESTRICT (ограничение). В рамках этой стратегии не разрешается выполнять операции, приводящие к нарушению ссылочной целостности. При этом проверяется, имеются ли кортежи в дочернем отношении, связанные с некоторым кортежем в родительском отношении.

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

Рассмотренные стратегии являются стандартными и поддерживаются всеми СУБД, в которых имеется поддержка ссылочной целостности.

Существуют также дополнительные стратегии поддержания ссылочной целостности:

- SET NULL (установить в NULL) . Разрешается выполнение требуемой операции, но все возникающие некорректные значения внешних ключей заменяются на null-значения. При применении этой стратегии кортежи дочернего отношения теряют всякую связь с кортежами родительского отношения. Установить, с каким кортежем родительского отношения были связаны измененные кортежи дочернего отношения, после выполнения операции уже нельзя.

- SET DEFAULT (установить по умолчанию). Разрешается выполнение требуемой операции, но все возникающие некорректные значения внешних ключей изменяются на некоторое значение, принятое по умолчанию. Недостатки этой стратегии заключаются в следующем. Во-первых, в родительском отношении должен быть некий кортеж, потенциальный ключ которого принят как значение по умолчанию для внешних ключей. В качестве такого "кортежа по умолчанию" обычно принимают специальный кортеж, заполненный нулевыми значениями (не null-значениями). Этот кортеж нельзя удалять из родительского отношения, и в этом кортеже нельзя изменять значение потенциального ключа. Таким образом, не все кортежи родительского отношения становятся равнозначными, поэтому приходится прилагать дополнительные усилия для отслеживания этой неравнозначности. Во-вторых, как и в предыдущем случае, кортежи дочернего отношения теряют всякую связь с кортежами родительского отношения. Установить, с каким кортежем родительского отношения были связаны измененные кортежи дочернего отношения, после выполнения операции уже нельзя.

В некоторых реализация СУБД реализована еще одна стратегия поддержания ссылочной целостности:

- IGNORE (игнорирование). Выполнение операции, не обращая внимания на нарушения ссылочной целостности. В целом, это просто отказ от поддержки ссылочной целостности. В этом случае в дочернем отношении могут появляться некорректные значения внешних ключей, и вся ответственность за целостность базы данных ложится на пользователя.

1.16 Представления

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

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

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

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

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

Изменения в базовых отношениях отражаются на представлениях, основанных на них.

Хотя представление не хранится в базе данных как обычное отношение, его определение присутствует в системном каталоге.

Перечислим основные возможности, которые предоставляет механизм представлений:

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

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

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

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

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

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

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

- обновление не допускается через представление, определенное на нескольких базовых отношениях

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

Эти условия используются в большинстве современных СУБД для проверки допустимости обновления данных через представления.

1.17 Реляционная алгебра и реляционное исчисление

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

Реляционная алгебра определяет, как на основе одного или нескольких существующих отношений построить новое отношение.

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

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

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

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

1.18 Основные операции реляционной алгебры

Восемь основных операций реляционной алгебры, предложенные Коддом, следующие:

- выборка

- проекция

- объединение множеств

- разность множеств

- пересечение

- деление

- декартово произведение

- соединение.

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

Рассмотрим вначале унарные операции - операции, совершаемые над одним отношением. Таковыми являются операции выборки и проекции.

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

Вернемся к отношению Сотрудник, представленному на рис. 2. Пусть нам необходимо получить список сотрудников, работающих в отделе с кодовым номером В03 (отдел разработок). Ответ можно получить, совершив над отношением Сотрудник операцию выборки с условием Номер_отдела=В03. Результатом будет отношение, содержащее лишь кортежи отношения Сотрудник со значением атрибута Номер_отдела, равным В03:

...

Подобные документы

  • Основные понятия реляционных баз данных. Ограничительные условия, поддерживающие целостность. Операции над реляционными данными. Виды операций: традиционные и специальные. Нормализация и разновидности ее форм. Целостность категории (сущности) и ссылок.

    реферат [227,6 K], добавлен 22.02.2009

  • Рассмотрение архитектуры "файл-сервер" и двух- и трехуровневых архитектур "клиент-сервер". Модель сервера приложений и свойства "идеальной" системы управления распределенными базами данных. Способы распределения функций обработки логики запроса.

    презентация [60,2 K], добавлен 19.08.2013

  • Основные объекты СУБД Microsoft Access. Формирование запросов на выборку. Основные протоколы обмена в компьютерных сетях. Использование и применение архитектуры клиент-сервер или файл-сервер. Основы реляционных БД. Наиболее известные модели данных.

    курсовая работа [1,3 M], добавлен 13.01.2014

  • Базы данных с двумерными файлами и реляционные системы управления базами данных (СУБД). Создание базы данных и обработка запросов к ним с помощью СУБД. Основные типы баз данных. Базовые понятия реляционных баз данных. Фундаментальные свойства отношений.

    реферат [57,1 K], добавлен 20.12.2010

  • Общее понятие и признаки классификации информационных систем. Типы архитектур построения информационных систем. Основные компоненты и свойства базы данных. Основные отличия файловых систем и систем баз данных. Архитектура клиент-сервер и ее пользователи.

    презентация [203,1 K], добавлен 22.01.2016

  • Основные понятия серверов, базы данных и их классификация. Задача логического проектирования - разработка схемы, ориентированной на выбранную СУБД. Понятия сервер и клиент и закрепленные за ними роли. Специализация и комплектация серверного оборудования.

    реферат [33,2 K], добавлен 08.04.2009

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

    презентация [689,5 K], добавлен 06.06.2015

  • Представление данных в памяти компьютера. Обобщенные структуры и модели данных. Методы доступа к информации. Физическая организация системы управления базами данных, структура сервера. Архитектура "клиент-сервер". Создание базы данных с помощью "Денвер".

    курсовая работа [770,3 K], добавлен 17.11.2014

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

    реферат [122,5 K], добавлен 11.01.2010

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

    презентация [8,6 K], добавлен 14.10.2013

  • Теоретические сведения и основные понятия баз данных. Системы управления базами данных: состав, структура, безопасность, режимы работы, объекты. Работа с базами данных в OpenOffice.Org BASE: создание таблиц, связей, запросов с помощью мастера запросов.

    курсовая работа [3,2 M], добавлен 28.04.2011

  • Архитектура "клиент-сервер". Параллельная обработка данных в многопроцессорных системах. Модернизация устаревших информационных систем. Характерные черты современных серверных СУБД. Наиболее популярные серверные СУБД. Распределенные запросы и транзакции.

    курсовая работа [309,2 K], добавлен 11.11.2011

  • Анализ архитектуры информационной системы, в структуру которой входят системы файл-сервер и клиент-сервер. Сравнение языков запросов SQL и QBE. Принципы разработки приложений архитектуры клиент-сервер при помощи структурированного языка запросов SQL.

    курсовая работа [88,9 K], добавлен 11.04.2010

  • Базы данных как составная часть информационных систем. Изучение взаимосвязи понятий информация и данные. Система управления базами данных. Пример структурированных данных. Обеспечение логической независимости. Безопасность операционной системы.

    контрольная работа [44,6 K], добавлен 15.06.2009

  • Описания программного продукта компании 1С, предназначенного для быстрой разработки прикладных решений. Исследование типов архитектур построения баз данных. Технология с сетью и файловым сервером. Анализ особенностей трехзвенной архитектуры клиент-сервер.

    курсовая работа [401,4 K], добавлен 12.01.2015

  • Понятие и сущность базы данных, их классификация и характеристика. Системы управления базами данных. СУБД структуры "сервер-клиент", его суть. Microsoft Access - функционально полная реляционная СУБД. Предназначение СУБД Access, и описание ее работы.

    реферат [44,3 K], добавлен 27.02.2009

  • Система управление базами данных, реляционная модель. Принципы взаимодействия между клиентскими и серверными частями. Трехуровневая модель технологии "клиент-сервер". Фрактальные методы сжатия больших объемов данных. Анализ концепции хранилища данных.

    курс лекций [265,0 K], добавлен 05.06.2009

  • Изучение функций автоматизированных банков данных. Общие принципы описания, хранения и манипулирования данными. Анализ требований к базам данных. Файл-серверная и клиент-серверная архитектура БД. Преимущества введения системы управления базами данных.

    презентация [91,5 K], добавлен 13.08.2013

  • Система управления базами данных как составная часть автоматизированного банка данных. Структура и функции системы управления базами данных. Классификация СУБД по способу доступа к базе данных. Язык SQL в системах управления базами данных, СУБД Microsoft.

    реферат [46,4 K], добавлен 01.11.2009

  • Базы данных - важнейшая составная часть информационных систем. Проектирование базы данных на примере предметной области "Оргтехника". Сбор информации о предметной области. Построение информационно-логической модели данных. Разработка логической структуры.

    курсовая работа [318,6 K], добавлен 24.12.2014

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.