Базы данных

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

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

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

Так, для табл. 2.3 любой отдельный атрибут будет вторичным ключом. Например, если задать значение атрибута «Номер лицензии» равным 107000/0003, в таблице будут найдены две строки с этим значением.

Нормализация  таблиц-отношений.

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

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

Таблицы реляционной БД должны обладать определенными свойствами: все строки должны быть уникальными (должен существовать первичный ключ для каждой таблицы); все строки одной таблицы должны иметь одинаковую структуру; имена столбцов должны быть различными, а значения их простыми (недопустимо несколько значений в одной клетке столбца) и т.п.

 

 

 

 

 

 

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

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

Выделяют следующие  формы нормализованных таблиц:

- первая нормальная форма (1НФ);

- вторая нормальная форма (2НФ);

- третья нормальная  форма (ЗНФ);

- усиленная  третья нормальная форма или  нормальная форма Бойса-Кодда  (БКНФ);

- четвертая  нормальная форма (4НФ);

- пятая нормальная  форма (5НФ).

Обычно при  создании реляционной БД ее таблицы достаточно привести к третьей нормальной форме (ЗНФ или БКНФ).

При первой нормальной форме все атрибуты отношения  должны быть простыми» т.е. иметь единственное значение в каждой строке.

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

При второй нормальной форме все атрибуты отношения  удовлетворяют требованиям 1НФ и каждый неключевой атрибут функционально полно зависит от ключа. Атрибут А функционально зависит от атрибута В, если каждому значению А соответствует только одно значение В, т.е. во всех кортежах с одним и тем же значением атрибута А атрибут В также имеет одно и то же значение (записывается: А - > В). Если атрибут находится в функциональной зависимости от части составного ключа, то такая зависимость называется частичной. Полная функциональная зависимость означает, что ключ однозначно определяет неключевой атрибут и одному значению ключа соответствует только одно значение неключевого атрибута. Если ключ составной, то подобная зависимость должна выполняться на уровне всего ключа, а не какой-либо его части.

При третьей  нормальной форме выполняются требования 1НФ и 2НФ, а каждый неключевой атрибут нетранзитивно зависит от ключа. Атрибут С зависит от атрибута А транзитивно, если для атрибутов А, В и С выполняются условия:

А->В и В->С.

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

Типы полей

Поля - это основные элементы физической модели БД. Для хранения данных в каждой клетке таблицы отводится некоторое поле. Одной из основных характеристик любого поля является его длина (выражается в символах или в знаках), т.е. количество единиц памяти ЭВМ, занимаемых

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

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

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

2) поле для ввода дат или времени;

3) логическое  поле предназначено для ввода  логических данных, имеющих только  два значения («Да» или «Нет»; «0> или «1»и т.п.). Длина этого поля всегда равна 1 байту, что достаточно для выражения логического значения;

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

5) поле объекта OLE (Object Linking and Embedding - связывание и внедрение объектов) используется для хранения картинок, музыкальных клипов и видеоданных;

6) поле MEMO используется для хранения длинного текста (до нескольких тысяч символов). Особенность ноля MEMO состоит в том, что реально в поле хранятся не данные, а только указатель места, где расположен текст;

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

Операции с  данными реляционной модели

В своей теории построения реляционных БД В.Ф. Кодд ввел понятия реляционной алгебры  и реляционного исчисления. Фактически это два языка формулирования и реализации запросов пользователя.

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

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ЗАКЛЮЧЕНИЕ

 

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

       Использование модели данных при работе с БД (в "компьютерном" смысле, в смысле хранения структур данных) неизбежно по нескольким причинам. Во-первых, модель дает общий язык пользователям, работающим с данными. Во-вторых, модель может обеспечить предсказуемость результатов работы с данными. Становится возможным объяснить пользователю, почему он получил конкретный результат при просмотре или изменении данных, и наоборот, работающий с базой может предвидеть, какого сорта он получит результат. За время существования разработок программных систем предложено много различных моделей разной степени распространенности.

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

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

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

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

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

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

 

 

 

 

 

 

 

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

 

1. Семенов Н.И. Автоматизированные информационные технологии. Учебник. – Москва.: «Инфра-М». 2237с. 2000г.
2. Дрога А. А., Жукова П. Н., Копонев Д. Н., Лукьянов Д. Б., Прокопенко А. Н. Информатика и математика. – Белгород.: Белгородский юридический институт МВД РФ, 2008.
3. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика — 3-е изд. — М.: «Вильямс», 2003.
4. Кузнецов С. Д. Основы баз данных. — 1-е изд. — М.: «Интернет-университет информационных технологий - ИНТУИТ.ру», 2005.
5. Никитина Т.П., Рубцов С.А. Базы данных и знаний/Под ред. д-ра техн.наук, проф. Д.О.Бытева. Изд-во ЯГТУ.-108с., 2003.
6. Малышенко Ю.В., Федоров В.В. Информационные таможенные технологии Том(часть) 2.: Учебник (ГРИФ)  - М.: «Рио РТА», 2008
7. Балдин К.В., Уткин В.Б. Информационные системы в экономике. 5-е изд. – М.: «Дашков и К», 2008. – 395 с.