Вы находитесь на странице: 1из 10

ПРЕИМУЩЕСТВА И НЕДОСТАТКИ РЕЛЯЦИОННЫХ МОДЕЛЕЙ

ДАННЫХ
Реферат по учебному модулю
«Информатика»
по направлению 38.03.02 – Менеджмент

РЕФЕРАТ
2

Оглавление
Введение……………………………………………………………………..3
Часть 1: Реляционные базы данных ............................................................... 4
1.1 База данных .................................................................................................... 4
1.2 Первые модели данных. 4
1.3 Системы управления файлами. ……………………………………………4
1.4 Реляционная модель данных ………………………………………………4
1.5 Таблицы ……………………………………………………………………..5
1.6 Первичные ключи. ………………………………………………………….5
1.7 Отношения предок/потомок. ………………………………………………6
1.8 Внешние ключи …………………………………………………………….6
1.9 Двенадцать правил Кодда………………………………………………......6
Часть 2: Преимущества и недостатки реляционной, иерархической и
сетевой моделей данных. ..................................................................................... 8
2.1 Реляционная модель данных........................................................................ 8
2.2 Иерархическая модель данных…………………………………………….8
2.3 Сетевая модель данных…………………………………………………….8
Заключение…………………………………………………………………….9
Список использованных источников……………………………………..10
3

Введение

В настоящее время информация в жизни человека играет важную роль.


Тема моего реферата актуальна и сейчас, поскольку при увеличении
количества информации её нужно где-то хранить, и не только хранить, но и
правильно сортировать по различным необходимым группам.
В этом нам помогают базы данных которые приобрели широкое
использование в современном мире. Они не только помогают правильно и
удобно распределить все необходимые нам данные, но и обеспечивают
нужный их поиск и другие наглядные и полезные функции.
За время развития баз данных появились различные виды моделей баз
данных. От этого появилась необходимость узнать – какие же модели
данных самые удобные и имеют наибольшее число преимуществ над
другими и наименьшее количество недостатков.
4

Часть 1: Реляционные базы данных


1.1 База данных
Итак, начнём с определения: База Данных - это набор записей и
файлов, организованных специальным образом. С их помощью можно
хранить определённые нужные данные в памяти компьютера. Существует
два типа баз данных: один из них – документы, а второй – электронные
таблицы. Документы – набранные текстом файлы упорядоченные по
необходимым группам. Электронные таблицы же – это совокупность
нескольких таблиц объединённых под одной предметной областью. [1]

1.2 Первые модели данных.


В 70х-80х годах системы управления баз данных набирали большую
популярность, в связи с чем появлялось и больше видов моделей баз
данных. Все они имели свои плюсы и минусы и между тем всё больше
развивали базы данных.
1.3 Системы управления файлами.
До появления СУБД все данные хранились обычными файлами на
компьютере. Операционная система лишь следила за именами и
расположением файлов и не имела больших функциональных способностей.
И в системах управления сами модели данных не использовались. Для этой
системы содержание файлов не имеет значения. Содержанием файлов в
основном интересовались только различные прикладные программы.
Например, в приложении для начисления зарплаты каждая из программ,
обрабатывающих файл с информацией о работниках, содержит в себе
описание структуры данных (ОСД), хранящихся в этом файле. И если
структура как-либо менялась, это требовало изменения и программного
обеспечения. Постепенно количество различных файлов всё росло, а значит
требовались новые системы. И в итоге, проблемы сопровождения больших
систем, основанных на файлах, привели в конце 60-х годов к появлению
СУБД. В её основе лежала довольно простая идея: изъять из программ
определение структуры содержимого файла и хранить её вместе с данными
в базе данных. [2]

1.4 Реляционная модель данных


Недостатки иерархической и сетевой моделей привели к появлению
новой, реляционной модели данных, созданной Коддом в 1970 году, которая
сразу привлекла внимание людей. Реляционная модель пыталась упростить
уже существующие модели. В ней не было явных указателей на предков и
потомков, а все данные представляли собой простые таблицы, разбитые на
строки и столбцы.
К сожалению, практическое определение понятия "реляционная база
данных" оказалось гораздо более расплывчатым, чем точное математическое
определение, данное этому термину Коддом в 1970 году. Во-первых,
5

реляционных СУБД не были реализованы некоторые из ключевых частей


модели Кодда, и этот недостаток был доработал лишь через некоторое
время. По мере роста популярности реляционных моделей данных
реляционными стали называться многие базы данных, даже которые такими
и не являлись. В ответ на неправильное использование термина
"реляционный" Кодд в 1985 году написал статью, где сформулировал 12
правил, которым должна соответствовать любая реляционная база данных.
Так двенадцать правил Кодда служат неким определением реляционной
СУБД. Хотя можно сформулировать и более ёмкое определение:
Реляционной называется база данных, в которой все данные, доступные
пользователю, организованны в виде таблиц, а все операции над данными
сводятся к операциям над этими таблицами.

1.5 Таблицы
В реляционной базе данных информация организована в виде таблиц,
поделенных на строки и столбцы, на пересечении которых содержатся
значения данных. Каждая таблица имеет уникальное имя, соответствующее
её содержимому. Также и у каждого столбца в таблице есть своё имя,
которое обычно используется как заголовок столбца. Все столбцы в одной
таблице должны иметь уникальные имена.
Столбцы таблицы упорядочены слева направо, и их порядок
определяется при создании таблицы. В любой таблице должен быть как
минимум один столбец. В стандарте ANSI/ISO не указывается максимально
допустимое число столбцов в таблице, но при этом во всех коммерческих
СУБД этот предел существует и составляет около 255 столбцов. В отличие
от столбцов, строки таблицы не имеют определённого порядка. Таблица
может содержать любое количество строк. Даже допустимо отсутствие
строк вообще. Такая таблица будет называться пустой. Пустая таблица
сохраняет структуру, определённую её столбцами, но в ней не содержатся
данные. Стандарт ANSI/ISO не накладывает ограничений на количество
строк в таблице, и во многих СУБД размер таблиц ограничен лишь
свободным дисковым пространством компьютера. В других СУБД имеется
свой предел, но он весьма высок и составляет примерно два миллиарда
строк. [3]

1.6 Первичные ключи.


Из-за того, что строки в реляционной таблице не упорядочены, мы не
можем выбрать строку по ее номеру в таблице. Конкретные строки в
реляционной таблице выбираются особым способом.
В реляционной базе данных каждой таблицы есть один или несколько
столбцов, значения в которых во всех строках разные. Этот столбец
(столбцы) называется первичным ключом таблицы.
Первичный ключ является уникальным для каждой строки таблицы,
поэтому в таблице с первичным ключом нет двух совершенно одинаковых
6

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


отношением. Именно с этим термином и связано название “реляционные
базы данных”, т.е. построенные на отношениях.

1.7 Отношения предок/потомок.


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

1.8 Внешние ключи


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

1.9 Двенадцать правил Кодда


В журнале "Computer World", в своей статье Тэд Кодд описал
двенадцать правил правильной реляционной базы данных, которые мы уже
упоминали выше. Кодд основывался на своей теоретической работе по
реляционным СУБД.
Двенадцать правил Кодда, которым должна соответствовать
реляционная СУБД :
1. Правило информации. Вся информация должна быть представлена
в виде значений в таблице.
2. Правило гарантированного доступа. Логический доступ к любому
из элементов таблиц в реляционной базе данных должен обеспечиваться
путём использования комбинации имени таблицы, первичного ключа и
имени столбца.
3. Правило поддержки недействительных значений. Должна быть
реализована поддержка недействительных значений, которые отличаются от
строки, символов нулевой длинны, строки пробельных символов, и от нуля
7

или любого другого числа и используются для представления


отсутствующих данных независимо от типа этих данных.
4. Правило динамического каталога, основанного на реляционной
модели. Описание базы данных на логическом уровне должно быть
представлено в том же виде, что и основные данные.
5.Правило исчерпывающего подъязыка данных. Реляционная система
должна поддерживать различные языки и режимы взаимодействия с
пользователем.
6. Правило обновления представлений. Все необходимые
представления должны быть доступными для обновления.
7. Правило добавления, обновления и удаления. Наличие возможности
работать при чтении данных с отношением как с одним операндом, так и и
при добавлении, обновлении и удалении данных.
8. Правило независимости физических данных. Программы и утилиты
используемые для работы с данными должны на логическом уровне
оставаться нетронутыми при любых изменениях способов хранения данных
или методов доступа к ним.
9. Правило независимости логических данных. Прикладные
программы и утилиты для работы с данными должны на логическом уровне
оставаться нетронутыми при внесении в базовые таблицы любых изменений,
которые теоретически позволяют сохранить нетронутыми содержащиеся в
этих таблицах данные.
10. Правило независимости условий целостности. Необходимость
существования возможности определять условия целостности, которые
являются специфическими для конкретной реляционной базы данных, на
подъязыке реляционной базы данных и хранить их в каталоге.
11. Правило независимости распространения. Реляционная СУБД не
должна зависеть от потребностей конкретного клиента.
12. Правило единственности. Если в реляционной системе есть
низкоуровневой язык (обрабатывающий одну запись за один раз), то должна
отсутствовать возможность использования его для того, чтобы обойти
правила и условия целостности, выраженные на реляционном языке
высокого уровня (обрабатывающем несколько записей за один раз). [1]
8

Часть 2: Преимущества и недостатки реляционной, иерархической и сетевой


моделей данных

2.1 Реляционная модель данных.


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

2.2 Иерархическая модель данных.


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

2.3 Сетевая модель данных.


Отметим следующие преимущества сетевой модели данных.
Универсальность. Выразительные возможности сетевой модели данных являются
наиболее обширными в сравнении с остальными моделями.
Возможность доступа к данным через значения нескольких отношений (например,
через любые основные отношения).
В качестве недостатков сетевой модели данных можно назвать:
Сложность, т.е. обилие понятий, вариантов их взаимосвязей и особенностей
реализации.
9

Заключение

Итак, в данном реферате я рассмотрел различные виды моделей


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

Список использованных источников

1. Горев А., Ахаян Р., Макашарипов С. Эффективная работа с СУБД


СПБ.: изд. Питер, 1997
2. Попов А.А., Программирование в среде СУБД FoxPro 2.0, изд. Связь,
Москва, 1993
3. Джеймс Р. Грофф, Пол Н. Вайнберг, Эндрю Дж. Оппель, SQL. Полное
руководство, изд. Вильямс, Киев, 1998