Какими свойствами обладает реляционная таблица
ОСНОВНЫЕ ПОНЯТИЯ БАЗ ДАННЫХ
База данных (БД) – именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области данных.
Примеры предметных областей данных: склад, магазин, вуз, больница, учебный процесс и т. д. Именно предметная область определяет совокупность данных, которые должны храниться в базе данных.
Система управления базами данных (СУБД) – совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования базы данных многими пользователями.
Другие определения, имеющие отношение к БД и СУБД.
Банк данных (БнД) – это система специальным образом организованных данных – баз данных, программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и многоцелевого использования данных.
Информационная система (ИС) – взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной задачи.
Основой практически любой информационной системы является база данных.
Сервер – компьютер или программа, владеющая определенным информационным ресурсом и предназначенная для обработки запросов от программ-клиентов.
Основными моделями данных, определяющие структуру базы данных, являются:
иерархическая модель;
сетевая модель;
реляционная модель.
РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ
Теоретической основой этой модели является теория отношений и основной структурой данных – отношение. Именно поэтому модель получила название реляционной (от английского слова relation — отношение).
Отношениепредставляет собой множество элементов, называемых кортежами. Наглядной формой представления отношения является двумерная таблица. Смысловые значения некоторых элементов реляционной модели приведены в следующей таблице.
Обычное представление | База данных | Реляционная модель |
Таблица | Таблица | Отношение |
Строка | Запись | Кортеж |
Название столбца | Поле | Атрибут |
Множество значений столбца | Множество значений поля | Домен (множество значений атрибута) |
Подавляющее число создаваемых и используемых баз данных являются реляционными. Их создание и развитие связано с научными работами известного американского математика, специалиста в области систем баз данных Э. Кодда.
Свойства реляционной таблицы
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
· каждый элемент таблицы — один элемент данных;
· все столбцы (поля, атрибуты) в таблице однородные, т.е. все элементы в одном столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;
· каждый столбец имеет уникальное имя;
· одинаковые строки (записи, кортежи) в таблице отсутствуют;
· порядок следования строк и столбцов может быть произвольным.
Каждое поле содержит одну характеристику объекта предметной области. В записи собраны сведения об одном экземпляре этого объекта.
Ключи
Поле, каждое значение которого однозначно определяет соответствующую запись, называется простым ключом (ключевым полем). Ключ, состоящий из нескольких полей называется составным ключом. В СУБД Access в качестве ключа может быть использован Счетчик, который автоматически возрастает на единицу при вводе в таблицу новой записи. Такой ключ называют искусственным. Он семантически не связан ни с одним полем таблицы. Из-за этого он допускает повторный ввод одних и тех же записей. Но с помощью него просто устанавливать связь между таблицами. Основное свойство ключа – уникальность, неповторимость.
Типы связей между таблицами
Структура базы данных определяется структурой таблиц и связями между ними.
Связи между таблицами бывают трех типов:
«один-к-одному» (1:1) – одной записи в главной таблице соответствует одна запись в подчиненной таблице,
«один-ко-многим» (1:М) – одной записи в главной таблице соответствует несколько записей в подчиненной таблице,
«многие-ко-многим» (М:М) – нескольким записям в главной таблице соответствуют несколько записей в подчиненной таблице. Или одной записи в первой таблице может соответствовать несколько записей во второй таблице. И одной записи во второй таблице могут соответствовать несколько записей в первой таблице.
Создание связей между таблицами
Связь между таблицами устанавливается с помощью ключей. Главной называют таблицу, первичный ключ которой используется для установления связи с другой таблицей, которая в этом случае называется подчиненной.
Чтобы связать две реляционные таблицы, необходимо ключ главной таблицы ввести в состав подчиненной таблицы. Название ключа может быть другим, но обязательно одинаковыми с первичным ключом должны быть тип и размер вторичного ключа в подчиненной таблице. Для удобства лучше обозначение вторичного ключа оставлять таким же, как и первичного. Однако если ключом выбран Счетчик, то вторичный ключ должен иметь тип Числовой – длинное целое (но не Счетчик!). Вторичный ключ – это или обычное поле, или часть первичного ключа в подчиненной таблице.
СУБД Access для реализации связи «многие-ко-многим» требует создать таблицу связи и ввести в нее в качестве вторичных ключей первичные ключи двух таблиц, которые должны иметь такую связь (М:М). После этого устанавливается связь 1:М каждой из двух таблиц с таблицей связи. Между двумя таблицами таким образом реализуется связь М:М. Если в БД «Моя библиотека» создать таблицы Книги и Авторы, то связь между ними будет вида М:М, так как одной записи в таблице Книги (реквизиты одной книги) может соответствовать несколько записей в таблице Авторы. Потому что у одной книги может быть несколько авторов. В свою очередь, одной записи в таблице Авторы могут соответствовать несколько записей в таблице Книги, так как один автор может написать несколько книг. Таблицу связи можно назвать КнигиАвторы, в которую будут включены ключи обеих таблиц – Книги и Авторы. Если требуется, в таблицу связи можно включить и другие поля.
Среди реляционных баз данных следует различать корпоративные и настольные базы данных.
Из корпоративных реляционных СУБД наиболее распространенными являются: Oracl, IBM DB2, Sybase, Microsoft SQL Server, Informix. Из постреляционных СУБД известна СУБД Cache компании InterSystems.
Наиболее известны в настоящее время следующие настольные БД: Microsoft Access, Paradox (фирмы Borland), FoxPro (Microsoft), dBase IV (IBM), Clarion.
Эти СУБД занимают более 90% всего рынка СУБД.
В следующем разделе дана краткая характеристика СУБД Microsoft Access.
Источник
Так как таблицы в реляционной СУБД являются отношениями реляционной модели данных, то и свойства этих таблиц являются свойствами отношений, которые мы уже рассмотрели выше. Кратко сформулируем эти свойства еще раз:
– каждая таблица состоит из однотипных строк и имеет уникальное имя;
– строки имеют фиксированное число полей (столбцов) и значений (множественные поля и повторяющиеся группы недопустимы). Иначе говоря, в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или NULL;
– строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку;
– столбцам таблицы присваиваются уникальные имена, и в каждом из них размещаются однородные значения данных (даты, фамилии, целые числа или денежные суммы);
– полное информационное содержание базы данных представляется в виде явных значений данных, и такой метод представления является единственным. В частности, не существует каких-либо специальных «связей» или указателей, соединяющих одну таблицу с другой;
– при выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке безотносительно к их информационному содержанию. Этому способствует наличие имен таблиц и их столбцов, а также возможность выделения любой строки или любого набора строк с указанными признаками.
Индексы
Выше мы рассмотрели понятие ключей таблиц базы данных. В большинстве реляционных СУБД ключи реализуются с помощью объектов, называемых индексами. Индекс представляет собой указатель на данные, размещенные в реляционной таблице. Можно провести аналогию индекса таблицы базы данных с указателем, обычно помещаемым в конце книги. Чтобы найти в книге страницы, относящиеся к некоторой теме, проще всего обратиться к указателю, в котором устанавливается соответствие между перечисленными в алфавитном порядке темами и номерами страниц, и сразу определить страницы, которые следует просмотреть. Чтобы без указателя найти все страницы, относящиеся к нужной теме, пришлось бы просматривать всю книгу. Индекс базы данных предназначен для аналогичных целей – чтобы ускорить поиск информации в таблице базы данных. Индекс предоставляет информацию о точном физическом расположении данных в таблице.
Мы отмечали, что записи в реляционных таблицах не упорядочены. Тем не менее любая запись в конкретный момент времени имеет вполне определенное физическое местоположение в файле базы данных, хотя оно и может изменяться при изменении информации, хранящейся в базе данных.
При создании индекса в нем сохраняется информация о местонахождении записей, относящихся к индексируемому столбцу таблицы. При добавлении в таблицу новых записей или удалении существующих индекс также модифицируется.
При выполнении запроса к базе данных, в условие поиска которого входит индексированный столбец, поиск значений производится в первую очередь в индексе. Если этот поиск оказывается успешным, то в индексе устанавливается точное местоположение искомых данных в таблице базы данных.
Рассмотрим пример индекса. На рис. 4.1 показан фрагмент таблицы СТУДЕНТЫ и индекса, построенного по полю «Имя» данной таблицы. При выполнении поиска по имени студента, просматривая индекс, можно сразу определить порядковый Номер записи, содержащей необходимую информацию, и затем быстро найти в таблице сами данные. Если бы у таблицы отсутствовал индекс по полю «Имя», то выполнение поиска по имени студента потребовало бы просмотра всей таблицы.
Таким образом, использование индексов снижает время выборки данных.
Рисунок 4.1 – Поиск информации в таблице с помощью индекса
Различают несколько типов индексов. Наиболее часто выделяют три типа:
– простые;
– составные;
– уникальные.
Ускорение поиска информации при использовании индекса может показаться неочевидным – ведь количество записей в индексе совпадает с количеством записей в таблице. Однако следует учитывать два обстоятельства:
– обращение к индексу выполняется быстрее, чем к таблице;
– в индексе записи хранятся в упорядоченном виде (в рассматриваемом примере – в алфавитном порядке) и поэтому при поиске информации в индексе нет необходимости просматривать все данные до конца индекса.
Простые индексыпредставляют собой простейший и вместе с тем наиболее распространенный тип индекса. Простой индекс строится на основе только одного столбца реляционной таблицы (индекс, приведенный на рис. 4.1, является простым).
Составные индексыстроятся по двум и более столбцам реляционной таблицы. При создании составного индекса необходимо принимать во внимание, что последовательность столбцов, по которым создается индекс, влияет на скорость поиска данных.
Последовательность столбцов в составном индексе указывается при его создании и никаким образом не связана с последовательностью столбцов в таблице.
Можно назвать два условия оптимальности следования столбцов в составном индексе:
– первым следует помещать столбец, содержащий наиболее ограничивающее значение (то есть, содержащий меньшее количество повторов);
– первым следует помещать столбец, содержащий данные, которые наиболее часто задаются в условиях поиска.
Сформулированные условия оптимальности часто являются противоречивыми, так что между ними следует находить разумный компромисс.
Следует серьезно относиться к планированию индексов. Неправильное применение индексов может привести к снижению производительности системы. Мы уже говорили о том, что физическое местоположение записей может изменяться в процессе редактирования данных пользователями, а также в результате манипуляций с файлами базы данных, проводимых самой СУБД (таких как сжатие данных, сборка «мусора» и др.). Обычно при этом происходят соответствующие изменения и в индексе, а это увеличивает время, требующееся СУБД для проведения таких операций. Поэтому обычно не следует индексировать:
– столбцы, данные в которых подвержены частому изменению;
– столбцы, содержащие большое количество пустых значений;
– столбцы, содержащие небольшое количество уникальных значений;
– небольшие таблицы;
– поля большого размера.
Уникальные индексыне допускают введения в таблицу дублирующих значений. Уникальные индексы используются не только с целью повышения скорости поиска, но и для поддержания целостности данных. Уникальный индекс может быть как простым, так и составным.
Нормализация данных
Нормализацияпредставляет собой процесс реорганизации данных путем ликвидации повторяющихся групп и иных противоречий с целью приведения таблиц к виду, позволяющему осуществлять непротиворечивое и корректное редактирование данных.
Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, то есть исключена избыточность информации. Таким образом, нормализацию можно также определить как процесс, направленный на уменьшение избыточности информации в реляционной базе данных.
Цели нормализации
Избыточность информации устраняется не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных и упрощения управления ими.
может привести к нарушению целостности данных (противоречивости информации) в базе данных. Обычно различают следующие проблемы, возникающие при использовании ненормализованных таблиц:
– избыточность данных;
– аномалии обновления;
– аномалии удаления;
– аномалии ввода.
Чтобы проиллюстрировать проблемы, возникающие при работе с ненормализованными базами данных, рассмотрим в качестве примера таблицу СОТРУДНИКИ, содержащую информацию о сотрудниках некой организации. Структура этой таблицы приведена на рис. 4.2.
Избыточность данных
Избыточность данных проявляется в том, что в нескольких записях таблицы базы данных повторяется одна и та же информация. Например, один человек может работать на двух (или даже более) должностях. Но в таблице, приведенной на рис. 4.2, каждой должности соответствует запись, и в этой записи содержится информация о личных данных сотрудника, эту должность занимающего. Таким образом, если сотрудник работает на нескольких должностях, то его личные данные будут дублироваться несколько раз, что приведет к неоправданному увеличению занимаемого объема внешней памяти.
Аномалии обновления
Аномалии обновления тесно связаны с избыточностью данных. Предположим, что у сотрудника, работающего на нескольких должностях, изменился адрес. Чтобы информация, содержащаяся в таблице, была корректной, необходимо будет внести изменения в несколько записей. Если же исправление будет внесено не во все записи, то возникнет несоответствие информации, которое и называется аномалией обновления.
Аномалии удаления
Аномалии удаления возникают при удалении записей из ненормализованной таблицы. Пусть, например, в организации проводится сокращение штатов и некоторые должности аннулируются. При этом следует удалить соответствующие записи в рассматриваемой таблице. Однако удаление приведет к потере информации о сотруднике, занимавшем эту должность. Такая потеря информации и называется аномалией удаления. (Для нашего случая можно привести и другой пример – удаление записи при увольнении сотрудника приведет к потере информации о должности, которую он занимал.)
Аномалии ввода
Аномалии ввода возникают при добавлении в таблицу новых записей и обычно возникают, когда для некоторых полей таблицы заданы ограничения NOT NULL. В таблице, рассматриваемой в качестве примера, имеется поле «Рейтинг», в котором содержится информация об уровне квалификации сотрудника, устанавливаемом по результатам его работы. При приеме на работу нового сотрудника установить уровень его квалификации невозможно, так как он еще не выполнял никаких работ в организации. Если для этого поля задать ограничение NOT NULL, то в таблицу нельзя будет ввести информацию о новом сотруднике. Это и называется аномалией ввода.
Вывод
Очевидно, что аномалии обновления, удаления и ввода крайне нежелательны. Чтобы свести к минимуму возможность появления такого рода аномалий, и используется нормализация.
Нормальные формы
Теория нормализации основана на концепции нормальных форм. Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если оно удовлетворяет свойственному данной форме набору ограничений.
В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм:
– первая нормальная форма (1NF);
– вторая нормальная форма (2NF);
– третья нормальная форма (3NF);
– нормальная форма Бойса–Кодда (BCNF);
– четвертая нормальная форма (4NF);
– пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF). Основные свойства нормальных форм:
– каждая следующая нормальная форма в некотором смысле лучше предыдущей;
– при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.
В основе процесса проектирования лежит метод нормализации – декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы.
Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости. Функционально зависимым считается такой атрибут, значение которого однозначно определяется значением другого атрибута. Функционально зависимые атрибуты обозначаются следующим образом: X –> Y. Эта запись означает, что если два кортежа в таблице имеют одно и то же значение атрибута X, то они имеют одно и то же значение атрибута Y. Атрибут, указываемый в левой части, называется детерминантом.
Первичный ключ таблицы является детерминантом, так как его значение однозначно определяет значение любого атрибута таблицы.
Date: 2016-05-25; view: 1746; Нарушение авторских прав
Источник