Базовые понятие реляционной модели данных (создание таблицы 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.Базовые понятия реляционных баз данных
Основными понятиями реляционных базданных являются тип данных, домен, атрибут, кортеж, первичный ключ и отношение.
Для начала покажем смысл этих понятийна примере отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторойорганизации:
/>
Тип данных
Понятие тип данных в реляционноймодели данных полностью адекватно понятию типа данных в языках программирования:числовой тип, денежный, символьный, логический и. т.п. В нашем примере мы имеемдело с данными трех типов: строки символов, целые числа и «деньги».
Домен
Понятие домена более специфичнодля баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования.В самом общем виде домен определяется заданием некоторого базового типа данных,к которому относятся элементы домена, и произвольного логического выражения, применяемогок элементу типа данных. Если вычисление этого логического выражения дает результат«истина», то элемент данных является элементом домена.
Наиболее правильной интуитивной трактовкойпонятия домена является понимание домена как допустимого потенциального множествазначений данного типа. Например, домен «Имена» в нашем примере определенна базовом типе строк символов, но в число его значений могут входить только тестроки, которые могут изображать имя (в частности, такие строки не могут начинатьсяс мягкого знака).
Следует отметить также семантическую(смысловую) нагрузку понятия домена: данные считаются сравнимыми только в том случае,когда они относятся к одному домену. В нашем примере значения доменов «Номерапропусков» и «Номера групп» относятся к типу целых чисел, но не являютсясравнимыми.
Схема отношения, схема базы данных
Схема отношения — это именованноемножество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}.
/>
В данном примере имеется 6 пар {имя атрибута, имя типа}: номер зачетки — числовой,
ФИО-текстовый и т.д.,
и у этого множества из 6 пар есть имя — Студенты
Схема БД (в структурном смысле)- это набор именованных схем отношений.
Кортеж, отношение
Кортеж — это множество пар{имя атрибута, значение} соответствующих данной схеме отношения
/>
В данном примере имеется 3 кортежа,каждый состоит из 6 пар {имя атрибута, значение }:
Номер зачетки — 123456, ФИО — ИвановАлексей Иванович
Группа — ЭУП-011 и т.д.,
Отношение — это множествокортежей, соответствующих одной схеме отношения.
На практике пользователь представляетсебе отношение как таблицу, заголовком которой является схемаотношения, а строками — кортежи отношения; в этом случае именаатрибутов именуют столбцы этой таблицы. Поэтому иногда говорят«столбец таблицы», имея в виду «атрибут отношения». Этой терминологиипридерживаются в большинстве коммерческих реляционных СУБД.
Фундаментальные свойства отношений
1) Отсутствие кортежей-дубликатов
Из этого свойства вытекает наличиеу каждого отношения так называемого первичного ключа — набора атрибутов,значения которых однозначно определяют кортеж отношения. Для каждого отношения покрайней мере полный набор его атрибутов обладает этим свойством.
2) Отсутствие упорядоченностикортежей
Это свойство дает дополнительнуюгибкость СУБД при хранении баз данных во внешней памяти и при выполнении запросовк базе данных. Это не противоречит тому, что при формулировании запроса к БД можнопотребовать сортировки результирующей таблицы в соответствии со значениями некоторыхстолбцов.
3) Отсутствие упорядоченностиатрибутов
Для ссылки на значение атрибута вкортеже отношения всегда используется имя атрибута. Это свойство позволяет, например,модифицировать схемы существующих отношений не только путем добавления новых атрибутов,но и путем удаления существующих атрибутов.
4) Атомарность значений атрибутов
На пересечении строки и столбца должнонаходиться только одно значение атрибута. Не может быть составного заголовка атрибута.товар выручка
план факт
показатель выручка, план выручка, факт /> /> /> /> />
Неатомарный атрибут Атомарный атрибут