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

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

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

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

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

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

А->В и В->С.

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

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

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

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

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

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

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

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ЗАКЛЮЧЕНИЕ

 

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

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

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

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

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

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

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

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

 

 

 

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

 

1. Балдин К.В., Уткин В.Б. Информационные системы в экономике. / К.В. Балдин, В.Б. Уткин — 5-е изд. – М. : Дашков и К, 2008. – 395 с.
2. Бураков П.В., Петров В.Ю. Введение в системы баз данных : учеб. пособие / П.В. Бураков, В.Ю. Петров — СПб: СПбГУ ИТМО, 2010. - 128 с.
3. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика — 3-е изд. — М. : Вильямс, 2003. – 1436 с.
4. Кузнецов С.Д. Основы баз данных : учеб. пособие / С.Д. Кузнецов — 2-е изд., испр. — М. : Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с.
5. Фуфаев Э.В. Базы данных: учеб. пособие / Э.В. Фуфаев, Д.Э. Фуфаев. — 3-е изд., стер. — М. : Академия, 2007. — 320 с.
6. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: учебник / под ред. проф. А. Д. Хомоненко. — 4-е изд., доп. н перераб. — СПб.: КОРОНА принт, 2004. — 736 с.