4. Классификация субд. Трехуровневая архитектура бд.

По количеству уровней описания данных, которое поддерживает СУБД, различают одно, двух и трёхуровневые системы. В настоящее время используется трёхуровневая архитектура описания БД.

Эта архитектура включает:

1. внешний уровень, на котором пользователи воспринимают данные, где отдельные группы пользователей имеют своё представление на БД;

2. внутренний уровень, на котором СУБД и ОС воспринимают данные;

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

1. системы общего назначения. Не направлены на удовлетворение потребностей какой-то группы пользователей. Им не важно в какой среде используются.

2. системы спец специального назначения.

По типу управляемой БД СУБД разделяются на:

1. сетевые;2)иерархические;3) реляционные;4)объектно-реляционные;

5)объектно-ориентированные.

По архитектуре организации хранения данных:

1. локальные;

2. распределённые.

По способу доступа к БД:

файл-серверные – в этих СУБД файлы данных располагаются централизованно на файловом сервере. Ядро СУБД располагается на каждом клиентском компьютере. Доступ к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредство файловых блокировок. Преимуществом данной архитектуры является низкая нагрузка на процессор сервера, а недостатком высокая загрузка локальной сети. На данный момент файл-серверные СУБД являются устаревшими. Примеры: Microsoft Access, Borland Paradox;

клиент-серверные – такие СУБД состоят из клиентской части, которая входит в состав прикладной программы и сервера. В отличие от файл-серверных СУБД обеспечивают разграничение доступа между пользователями и мало загружают сеть и клиентские машины. Сервер является внешней по отношение к клиенту программой. При необходимости его можно заменить на какой-то другой. Примеры: FireBird, InterBase, Microsoft SQL Server, CBase, Oracle.

встраиваемые – библиотека, которая позволяет унифицированным образом хранить большие объёмы данных на локальной машине. Доступ к данным производится через SQL либо через особые функции СУБД. Встраиваемые СУБД быстрее обычных клиент-серверных, не требуют установки сервера. Примеры: OpenEdge, SQLite, Berkley DB

5. Эволюция концепций бд. Основные характеристики первого и второго этапов.

На первом этапе эволюции БД хранение данных в файлах организовывалось последовательно, но в физических записях хранилась несколько логических записей.

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

Основные характеристики первого этапа:

1. Обработка в пакетном режиме без доступа в реальном времени;

2. Хранение нескольких копий одного и того же файла;

3. Одни и те же данные нельзя использовать в нескольких приложениях;

4. Высокая степень избыточности данных.

2-й этап

Характеристики второго этапа:

1. Возможность не только последовательной обработки, но и доступа к записям;

2. Оперативная обработка данных в реальном времени;

3. Логическая и физическая структура файлов БД различается, но связь между ними достаточно простая;

4. Запоминающее устройство можно изменять без изменения прикладной программы;

5. Поиск по многим ключам, как правило, невозможен;

6. Существует значительная избыточность данных;

7. ПО обеспечивает методы доступа к данным, но не управление данными.

6. Эволюция концепций БД. Основные характеристики третьего и четвертого этапов. Характеристики третьего этапа:

1. Существует возможность получения нескольких логических файлов в БД из одних и тех же логических файлов БД;

2. Доступ осуществляется различными приложениями и различными методами и механизмами;

3. ПО содержит средства уменьшения избыточности БД;

4. Физическая структура данных не зависит от прикладных программ и её можно изменять;

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

4-й этап

Характеристики четвёртого этапа:

1. Программные средства обеспечивают логическую и физическую независимость БД через существование глобального логического представления данных. Оно не зависит от представления данных в прикладных программ и логических представлениях;

2. БД может развиваться с минимальными затратами на её ведение;

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

4. БД конструируется для выдачи ответов на предвиденные запросы;

5. Программные средства обеспечивают возможность перемещения данны

7. Реляционная модель БД. Основные понятия: отношение, кортеж, атрибут, степень, домен, кардинальность, первичный ключ. Реляционная модель предложена сотрудником компании IBM Коддом в 1970. В настоящее время эта модель является практическим стандартом. Главная заслуга состоит в том, что нашёл удачную форму представления объектов реального мира. Отличительной чертой этого представления заключается в том, что представление данных не зависит от их способа физической организации. Это обеспечивается за счёт математической теории отношений.

Реляционная модель включает 3 основных понятия:

1. структура данных

2. целостность данных

3)операторы манипулирования данными Отношение –> таблица

картеж –> строка или запись таблицы

кардинальность –> количество строк

атрибут –> столбец или поле таблицы

степень –> количество столбцов

первичный ключ –> уникальный идентификатор

домен –> совокупность допустимых значений

8. Реляционная модель БД. Ключи и индексы. Реляционная модель БД #7. Первичный ключ – множество атрибутов, являющееся подмножеством заголовка данного отношения, составное значение которого определяет кортеж отношений. На практике термин «Первичный ключ» обозначает поле или столбец или группу полей таблицы, значение которого или комбинация значений которых используется в качестве индивидуального идентификатора (записи) этой таблицы. Если первичный ключ составлен из нескольких полей, то такой ключ называется составным. Первичный ключ может состоять из информационных полей таблицы – в этом случае он называется естественным ключом, однако, использование естественных ключей вызывает определённые сложности:

1. Низкая эффективность. Он может быть велик по размеру, и его использование может быть технического невыгодно;

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

3. Несоответствие реальности – уникальность естественного первичного ключа в БД не всегда соблюдается, поэтому на практике используется синтетические или суррогатные ключи.

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

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

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

9. Реляционная модель БД. Связи. Тип и степень участия. Реляционная модель БД #7. Связи:

Если записи в указанной таблице могут быть некоторым образом связаны с записями в другой таблице, то говорят, что между ними есть связь. Между таблицами могут существовать три типа связи:

1. один ко многим 2)многие ко многим 3)один к одному

Связь «один к одному» устанавливается, когда берётся первичный ключ из основной таблицы и вставляется в подчинённую таблицу, где он становится внешним ключом. Этот тип связи является специальным, т.к. во многих случаях внешний ключ также играет роль первичного ключа в подчинённой таблице

Связь «один ко многим» устанавливается, если берётся один первичный ключ и вставляется в таблицы на стороне «многие», где он становится внешним ключом.

Связь «многие ко многим» устанавливается путём создания связывающей таблицы: для этого берётся копия первичного ключа каждой таблицы и используется для формирования структуры новой таблицы. Эти поля служат двум целям: вместе они образуют составной первичный ключ, связывающий таблицы. По отдельности каждый из них служит внешним ключом.

Установка типа участия

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

Существует два типа участия: обязательный и необязательный.

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

Необязательный – отсутствуют требования о наличии любых записей в этой таблице до внесения каких-либо записей в другую таблицу. Установка степени участия

Означает до какой степени каждая таблица будет участвовать в связи. Это выполняется путём определения минимального и максимального количества записей в одной таблице, которые могут быть сопоставлены одной записи в другой таблице. Степень участия представляется двумя числами через запятую в круглых скобках. Первое число указывает минимально возможное количество зависимых записей, а второе – максимальное количество зависимых записей.

10. Реляционная модель БД. Целостность данных, причины нарушения. Реляционная модель БД #7. Основным свойством любой реляционной БД является наличие связи между её таблицами. Связи в реляционной БД устанавливаются с помощью внешних ключей. Благодаря наличию связи в реляционной БД, можно хранить данные об объектах в нормализованном виде. При этом данные об одном объекте хранятся в нескольких таблицах, связанных ссылкой. Но выделить запись, относящуюся к нужному объекту можно только тогда, когда соблюдается ссылочная целостность.

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

1. некорректный ввод (висящие ссылки)

   1. в результате неполной записи объекта

   2. некорректная правка ссылки

   3. правка первичного ключа без каскадного обновления

   4. удаление записи без каскадного обновления

2. сбой в работе системного ПО и оборудования.

• cascade - В стандарте SQL обеспечивается действие по поддержанию ссылочной целостности при удалении строк. Удаление записи может привести к удалению записи с соответствующим значением внешнего ключа.

• no action – можно запретить удаление записей если имеется зависимая запись в соответствующем значении внешнего ключа.

• set null – установка нулевых значений. Удаление записей может приводить к установке в соответствующие внешние ключи неопределённого значения

• set default – можно потребовать чтобы при удалении записи во внешний ключ устанавливалось значение по умолчанию.