Базовые понятие реляционной модели данных (создание таблицы MS Access)

Базовые понятие реляционной модели данных (создание таблицы MS Access)

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

Базы данных с двумерными файлами

Реляционные СУБД

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

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

Создают базы данных и обрабатывают запросы к ним системы управления базами данных - СУБД. Известно множество СУБД, различающихся своими возможностями или обладающих примерно равными возможностями и конкурирующих друг с другом: Paradox, dBase, Microsoft Access, FoxPro, Oracle, InterBase, Sybase и много других.

Разные СУБД по разному организуют и хранят базы данных. Например, Paradox и dBase используют для каждой таблицы отдельный файл. В этом случае база данных — это каталог, в котором хранятся файлы таблиц. В Microsoft Access и в InterBase несколько таблиц хранится как один файл. В этом случае база данных — это имя файла с путем доступа к нему.

Типы баз данных.

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

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

Рассмотрим коротко следующие четыре модели баз данных:

1) Автономные

2) С разделяемыми файлами

3) Клиент/сервер

4) Многоярусные

1 Автономные базы данных

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

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

2 Базы данных с разделяемыми файлами

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

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

3 Базы данных клиент/сервер

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

4 Многоярусные базы данных

Наиболее распространен трехъярусный вариант:

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

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

Сервер приложений размещается в узле сети, доступном всем клиентам.

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

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

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

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

Тип данных

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

Домен

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

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

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

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

Схема отношения — это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается) }.

Схема БД (в структурном смысле) — это набор именованных схем отношений.

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

Кортеж — это множество пар {имя атрибута, значение} соответствующих данной схеме отношения В данном примере имеется 3 кортежа, каждый состоит из 6 пар {имя атрибута, значение }:

Номер зачетки - 12 3456,ФИО - Иванов Алексей Иванович

Группа - ЭУП-011 и т. д.,

Отношение — это множество кортежей, соответствующих одной схеме отношения.

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

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

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

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

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

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

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

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

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

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

Неатомарный атрибут Атомарный атрибут