Образовательный блог – всё для учебы

Архив рубрики «Базы данных»

СУБД Oracle одна из первых претендовала на то, чтобы запускаться на компьютере в нескольким числом процессоров. Если ОП Windows от Microsoft обещают только к 2010 году сделать такой чтобы она учитывала наличие 2-ух процессоров и распределяла нагрузку от одного процессора, то СУБД Oracle уже давно определяет количество процессоров и может перераспределить сама нагрузку на разные процессоры. Особенно это касается операторов выборки данных, удаления записей, обновление записей и т.д. особенно тогда когда надо загружать индексы и основную базу данных, либо когда запрос выполняется на одном процессоре под запросом другого и т.д.
Прочитать остальную часть записи »

Часто используются, когда приходится выполнять запросы типа: найти поставщиков из города N.

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

Хеш-адресацией или хеш-индексированием называется технология быстрого прямого доступа к хранимой записи на основе значения обычного числового поля.

Всякого рода индексирование, в том числе битовые индексы, предполагают наличие ещё одного файла: для десктоповских СУБД – физического, для SQL-сервера – логического (находящегося в одном физическом). Хеширование не требует дополнительного файла.
Прочитать остальную часть записи »

1. Основные правила выбора ТАБЛИЦ при индексировании

1. Целесообразно индексировать таблицы, из которых выбирается не более 5% строк (сразу).
2. Следует индексировать таблицы, не имеющие дублей в разделе where команды select.
3. Не целесообразно индексировать часто обновляемые таблицы.
4. Не целесообразно индексировать таблицы, занимающие не более 2х страниц (~500 записей).
Прим. это м.б. таблицы адресов, городов, районов.
Прочитать остальную часть записи »

Это наиболее распространенные в наше время индексы, для сверх больших баз данных. Фактически это многоуровневые индексы, правда сделанные не потипу индекс на индекс, как мы рассматривали первоначально.

Суть создания такого индекса такова, чтобы за 2, 3 считывания можно было находить нужную запись. Как это делается: Есть какой то корневой индекс Root( в нем номера – 23, 31, 44, они очень разряжены). У них есть идентификация, указатели.

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

Для поиска нужной записи используется RID. Но на самом деле SQL серверы работают не с записями, а со страницами. Считывается каждый раз страница, а внутри страницы ищется нужная запись. А раз так то на самом деле RID (Record идентификатор) можно заменить на идентификатор страниц.
Прочитать остальную часть записи »

Хранимый файл может иметь один индекс, как в нашем рассмотренном случае тут: http://all4study.ru/bd/indeksirovanie-v-bazax-dannyx.html, и хранимый файл может иметь несколько индексов, который сделаны так что они могут быть раздельными или совместными. Если индексов полей два и более, то индекс может быть сделан по каждому полю отдельно, или может быть сделан совместный, так называемый составной индекс. Т.е когда идет комбинация полей, он называется составным.
Прочитать остальную часть записи »

Структура хранения на основе индексирования предполагает использовать двух хранимых файлов.
Прочитать остальную часть записи »

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

Факторы повышения производительности:
- время отклика
- доступность системы
- 100%-ное время работоспособности
- параллельный режим работы
- восстановимость системы данных
- производительность офисных приложений
- сетевой трафик
- многопользовательский режим
и т.п.
Прочитать остальную часть записи »

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

Термин «целостность» используется для описания точности и корректности (или непротиворечивости) данных, хранящихся в базе данных.

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

Под безопасностью подразумевается, что некоторому пользователю разрешается выполнять некоторые действия.
СУБД должны соблюдать 3 основных аспекта информационной безопасности:
1. Конфиденциальность
2. Целостность
3. Доступность

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

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

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

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

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

В последнее время разрабатывать СУБД для подключения 100 и более 1000 пользователей стало экономически невыгодно, пошли по другому пути – создания пулов соединения. Считается, что ресурсы потребляются только активными пользователями. Тот, кто « подключился, но пошел жевать пирожок и болтать о чем-то другом», т.е. активно соединение не использует, он переходит в пассив.
Прочитать остальную часть записи »