Ооп бд объектно-ориентированная база данных
Вид материала | Документы |
- Программа дисциплины Объектно-ориентированное программирование Рекомендуется для направления, 591.42kb.
- Лекция на тему «Что такое база данных. Реляционная база данных ms access», 67.11kb.
- Абстракции, наследование и полиморфизм, 107.42kb.
- Ms access База данных (БД), 134.51kb.
- Лекция: Методологии моделирования предметной области: Методологии моделирования предметной, 347.91kb.
- Развитие объектно-ориентированных систем управления базами данных, 122.52kb.
- Должна быть конкретной, кратко сформулированной и соответствовать современному уровню, 20.13kb.
- В вычислительной математике, 1443kb.
- Базы данных 2, 398.32kb.
- Лекция на тему: Основы организации баз данных, 393.78kb.
38. Фізична організація бази даних в InterBase.
База данных InterBase состоит из последовательно, начиная с 0, пронумерован-ных страниц. Нулевая страница является служебной и содержит информацию, не¬обходимую для соединения с БД. Размер страницы — 1 (по умолчанию), 2, 4 или
8 Кбайт. Размер страницы задается при создании БД, но может быть изменен при сохранении и восстановлении базы. Одна страница читается сервером за один логический доступ к БД.
Объем буфера ввода-вывода для операций чтения-записи определяется в коли¬честве страниц (по умолчанию — 75). Если БД будет чаще читаться, объем бу¬фера следует увеличить. Если в нее будет чаще осуществляться запись, размер буфера можно уменьшить.
В InterBase для записей поддерживается режим множества версий. При измене¬нии записи какой-либо транзакцией создается новая версия записи, куда помимо данных записывается номер транзакции и указатель на предыдущую версию за¬писи. Старая версия помечается как измененная; ее указатель на следующую вер¬сию записи содержит ссылку на вновь созданную версию. Каждая стартующая транзакция работает с последней версией записи, изменения для которой подтвер¬ждены. Таким образом, параллельно работающие с БД транзакции всегда исполь¬зуют разные версии записей, что позволяет снимать блокировки для клиентских приложений, одновременно работающих с одними и теми же данными в БД. При удалении записи она также физически не удаляется с диска, а помечается как уда¬ленная до тех пор, пока не завершатся все активные транзакции, использующие эту запись.
InterBase размещает на одной своей странице все версии одной записи ТБД. Пос¬ле удаления записей на странице образуются «дырки». При добавлении новой записи анализируется размер максимальной «дырки», и, если он меньше длины добавляемой записи, происходит сжатие страницы, в процессе которой «дырки» объединяются. Если освободившегося пространства не хватает для размещения новой записи, та записывается с новой страницы. Загрузка страницы считается нормальной в случае, если «дырки» занимают не более 20 % объема страницы.
Выделение страниц никак не оптимизировано. На отдельной служебной страни¬це БД хранятся номера всех свободных страниц. При выделении страниц не пред¬принимается никаких действий по выделению последовательно расположенных страниц для хранения записей одной таблицы БД, а выделяется первая страница в списке свободных. Если свободной страницы нет, добавляется новая в конец БД. Только в этом случае размер БД возрастает.
Структура записей, поддерживающая режим множества версий, и неоптимальное выделение страниц ведут к высокой фрагментации БД и как следствие — к замед¬лению работы с ней. Поэтому необходимо периодически производить дефрагмен-тацию БД. Дефрагментированная БД характеризуется расположением записей таблиц БД на последовательно расположенных страницах и отсутствием «мусо¬ра». Под мусором понимаются версии записей, с которыми не работает никакая активная транзакция.
Для удаления мусора БД сохраняется на дисковом носителе и затем восстанавли¬вается из сделанной резервной копии с помощью утилиты IBConsole (для преды¬дущих версий InterBase — с помощью утилиты InterBase Server Manager). Этот процесс гарантирует удаление всего мусора, так как в момент сохранения и
становления БД не должно быть активных подключений к БД со стороны дру¬гих пользователей и потому не может быть активных транзакций. Кроме того, в InterBase предусмотрено автоматическое удаление мусора на фоне активных транзакций. Интервал, через который происходит автоматическое удаление му¬сора, по умолчанию составляет 20 000 транзакций. Это значение может быть из¬менено с помощью утилиты IBConsole (InterBase Server Manager). При автома¬тической очистке удаляются только те версии записей, для которых нет активных транзакций. В результате могут быть удалены не все старые версии.
Основи SQL
1. Створення бази даних (Create Database).
В различных СУБД процедура создания баз данных обычно закрепляется только за администратором баз данных. В однопользовательских системах принимаемая по умолчанию база данных может быть сформирована непосредственно в процессе установки и настройки самой СУБД. Стандарт SQL не определяет, как должны создаваться базы данных, поэтому в каждом из диалектов языка SQL обычно используется свой подход.
Процесс создания базы данных в системе SQL-сервера состоит из двух этапов: сначала организуется сама база данных, а затем принадлежащий ей журнал транзакций. Информация размещается в соотв. файлах, имеющих расширения *.mdf (для базы данных) и *.ldf. (для журнала транзакций). В файле базы данных записываются сведения об основных объектах (таблицах, индексах, просмотрах и т.д.), а в файле журнала транзакций – о процессе работы с транзакциями (контроль целостности данных, состояния базы данных до и после выполнения транзакций).
Создание базы данных в системе SQL-сервер осуществляется командой CREATE DATABASE. (процедура создания базы данных в SQL-сервере требует наличия прав администратора сервера.)
<определение_базы_данных> ::=
CREATE DATABASE имя_базы_данных
[ON [PRIMARY]
[ <определение_файла> [,...n] ]
[,<определение_группы> [,...n] ] ]
[ LOG ON {<определение_файла>[,...n] } ]
[ FOR LOAD | FOR ATTACH ]
Параметр ON определяет список файлов на диске для размещения информации, хранящейся в базе данных.
Параметр PRIMARY определяет первичный файл. Если он опущен, то первичным является первый файл в списке.
Параметр LOG ON определяет список файлов на диске для размещения журнала транзакций. Имя файла для журнала транзакций генерируется на основе имени базы данных, и в конце к нему добавляются символы _log.
Основи SQL.
3. Створення доменів (Create Domain). Створення таблиць (Create Table)
CREATE TABLE table
(
где table - имя создаваемой таблицы,
Описание поля состоит из наименования поля и типа поля
Здесь col - имя поля;
datatype - любой правильный тип SQL-сервера, символьные типы могут иметь CHARACTER SET - набор символов, определяющий язык страны. Для русского языка следует задать набор символов WIN1251;
COMPUTED BY (
domain - имя домена (обобщенного типа), определенного в базе данных;
DEFAULT - конструкция, определяющая значение поля по умолчанию;
NOT NULL - конструкция, указывающая на то, что поле не может быть пустым;
COLLATE - предложение, определяющее порядок сортировки для выбранного набора символов.
Пример
CREATE TABLE lsn_team (
id lsn_dintkey,
name lsn_dname UNIQUE,
founded lsn_dfounded,
PRIMARY KEY(id) )
Создание домена
Изучая предметную область разработчик базы данных часто сталкивается с тем, что встроенный тип слишком "широк" для хранения атрибута рассматриваемой сущности. Например, нужно вводить возраст, а типы данных INTEGER и SMALLINT предоставляют слишком широкие диапазоныю Сервер предоставляет нам возможность создать свой тип данных, наложив на него необходимые ограничения. Тип данных в SQL называется доменом и для его создания служит команда CREATE DOMAIN:
CREATE DOMAIN dage AS INTEGER DEFAULT 0 CHECK(VALUE >= 0 AND VALUE <= 120)
Рассмотрим приведенную выше команду. Мы попросили сервер создать домен CREATE DOMAIN с именем dage на основе целочисленного типа AS INTEGER, причем, если пользователь не укажет возраст, то будет использовано значение по умолчанию 0 -- DEFAULT 0, и значение поля должно находиться в пределах от 0 до 120 -- CHECK(VALUE >= 0 AND VALUE <= 120). Мы могли бы указать, что поле будет обязательно для заполнения -- NOT NULL, но в этом нет необходимости, так как NULL значение в любом случае не пройдет проверку CHECK.
Основи SQL
5. Батьківська і підлегла БД. Забезпечення посилальної цілісності
Декларативные ограничения целостности задаются на уровне операторов создания таблиц. При описании таблицы задается имя таблицы, которое является идентификатором в базовом языке СУБД и должно соответствовать требованиям именования объектов в данном языке. Кроме имени таблицы в операторе указывается список элементов таблицы, каждый из которых служит либо для определения столбца, либо для определения ограничения целостности определяемой таблицы. Требуется наличие хотя бы одного определения столбца. То есть таблицу, которая не имеет ни одного столбца, определить нельзя. Количество столбцов в одной таблице не ограничено, но в конкретных СУБД обычно бывают ограничения на количество атрибутов. Так, например, в MS SQL Server 6.5 максимальное количество столбцов в таблице было 250, но уже в MS SQL Server 7.0 оно увеличено до 1024.
При задании ограничений уникальности данный столбец определяется как возможный ключ, что предполагает уникальность каждого вводимого значения в данный столбец. И если это ограничение задано, то СУБД будет автоматически осуществлять проверку на отсутствие дубликатов значений данного столбца во всей таблице.
Если в разделе ограничений целостности указано ограничение по ссылкам данного столбца, то порождается соответствующее определение ограничения по ссылкам для таблицы: FOREIGN KEY(<имя столбца>) < спецификация ссылки>, что означает, что значения данного столбца должны быть взяты из соответствующего столбца родительской таблицы. Родительской таблицей в данном случае называется таблица, которая связана с данной таблицей связью "один-ко-многим" (1:М). При этом каждая строка родительской таблицы может быть связана с несколькими строками определяемой таблицы. Трансляция операторов SQL проводится в режиме интерпретации, поэтому важно, чтобы сначала была бы описана родительская таблица, а потом уже все подчиненные таблицы, связанные с ней. Иначе транслятор определит ссылку на неопределенный объект. Сначала должны быть описаны все основные таблицы, а потом подчиненные таблицы.
Основи SQL
8. Підзапити. Вкладені підзапити
Подзапрос - очень мощное средство языка SQL. Он позволяет строить сложные иерархии запросов, многократно выполняемые в процессе построения результирующего набора или выполнения одного из операторов изменения данных (DELETE, INSERT, UPDATE).
Условно подзапросы иногда подразделяют на три типа, каждый из которых является сужением предыдущего:
- табличный подзапрос, возвращающий набор строк и столбцов;
- подзапрос строки, возвращающий только одну строку, но, возможно, несколько столбцов (такие подзапросы часто используются во встроенном SQL);
- скалярный подзапрос, возвращающий значение одного столбца в одной строке.
Вложенный подзапрос - это подзапрос, заключенный в круглые скобки и вложенный в WHERE (HAVING) фразу предложения SELECT или других предложений, использующих WHERE фразу. Вложенный подзапрос может содержать в своей WHERE (HAVING) фразе другой вложенный подзапрос и т.д. Нетрудно догадаться, что вложенный подзапрос создан для того, чтобы при отборе строк таблицы, сформированной основным запросом, можно было использовать данные из других таблиц (например, при отборе блюд для меню использовать данные о наличии продуктов в кладовой пансионата).
SELECT * from tbl1
WHERE f2=(SELECT f2 FROM tbl2
WHERE f1=1);
Коррелированные подзапросы
В операторе SELECT из внутреннего подзапроса можно ссылаться на столбцы внешнего запроса, указанного во фразе SELECT. Такой подзапрос выполняется для каждой строки таблицы, определяя условие ее вхождения в формируемый результирующий набор.
Например:
SELECT * from tbl1 t1
WHERE f2 IN (SELECT f2 FROM tbl2 t2
WHERE t1.f3=t2.f3);
В данном случае для каждой строки таблицы tbl1 будет проверяться условие, что значение поля f2 совпадает со значением строки таблицы tbl2, где значение поля f3 равно значению поля f3 внешней таблицы (tbl1). Это простейший пример коррелированного подзапроса.