Работа с СУБД Oracle. Обзор

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

Рубрика Программирование, компьютеры и кибернетика
Вид курс лекций
Язык русский
Дата добавления 15.06.2018
Размер файла 602,7 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

20.3.9 Значения по умолчанию для столбцов

При объявления столбца таблицы можно также объявить соответствующее значение по умолчанию для этого столбца {default column value). Это значение по умолчанию используется, если приложение вводит новую строку в таблицу, но опускает при вводе значение для столбца. Например, можно указать, что значением по умолчанию для столбца ORDER__DATE (дата_заказа) таблицы ORDERS (заказы) будет текущее системное время, соответствующее моменту создания приложением новою заказа.

Исходным значением по умолчанию для столбца является null-значение (отсутствие значения), если не. указано обратное.

20.3.10 Целостность данных и ограничения целостности

Целостность данных (data integrity) фундаментальное понятие модели реляционной базы данных. Соблюдение целостности базы данных является лишней гарантией наличия в базе данных только допустимой информации. Естественно, желательно соблюдать целостность любой базы данных.

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

20.3.11 Целостность доменов, null-значения и сложные домены

Целостность доменов {domain integrity) определяет домены (области) значений, допустимых для столбцов. Например, запись о клиенте недостоверна, если сокращенный код штата, в котором проживает клиент, не входит в группу пятидесяти кодов штатов США.

Кроме использования типов данных, в Oracle поддерживается два вида ограничений целостности, позволяющих еще более ограничивать домены столбцов:

* Можно исключить, возможность ввода null-значений в столбец, воспользовавшись ограничением (constraint) NOT NULL.

* Можно объявить правило целостности сложных доменов частью таблицы, воспользовавшись ограничением СНЕСК, обычно содержащим явный список значений, допустимых для столбца. Например, "М" (мужской) и "F" (женский) в столбце, содержащем информацию о поле клиента: "AL" (.Алабама), "АК" (Аляска), ..., "WY" (Вайоминг) в столбце, содержащем коды штатов США, и т.д.

20.3.12 Сущностная целостность, первичные и дополнительные ключи

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

Первичные ключи обеспечивают поддержание сущностной целостности таблиц: Первичный ключ, (primary key) -- это столбец, однозначно идентифицирующий строки таблицы. Как правило, в качестве первичных ключей таблиц реляционных баз данных используются столбцы типа ID (столбцы-идентификаторы). Например, в таблице клиентов может содержаться ID-столбец, однозначно идентифицирующий каждую запись о клиенте. Таким образом, даже если два клиента (скажем, Джон Смит и его сын Джон Смит-младший) имеют одинаковые имена, фамилии, адреса, номера телефонов и т.д., их идентификационные номера различны, что позволяет отличить одного от другого.

Первичный ключ таблицы часто бывает составным {composite), т.е. состоящим из нескольких столбцов. Например, в типичной таблице системы ввода заказов, содержащей информацию о пунктах заказов товаров, первичным ключ может быть составным и описываться столбцами ORDER_ID (идентифика-тор_заказа) и ITEM _ID (идентификатор_пункта_заказа). В этой таблице многие записи пунктов заказов могут иметь одинаковые идентификаторы (1,2, ...), но никакие две записи пунктов заказов не могут иметь одновременно одинаковые идентификатор заказа и идентификатор пункта заказа (идентификатор заказа 1, идентификашры пунктов заказа 1, 2, 3, ...; идентификатор заказа 2, идентификаторы пунктов заказа 1, 2, 3, ...; и т. д.).

Иногда в таблице необходимо обеспечить дополнительные уровни сущностной целостности. Дополнительные ключи (altenate keys) -- это столбцы или группы столбцов, в которых не содержатся повторяющиеся значения. Например, столбец EMAIL таблнцы, содержащей информацию о служащих компании, может быть дополнительным ключом, что будет гарантировать уникальность адресов электронной почты всех служащих.

20.3.13 Ссылочная целостность, внешние ключи и действия по обеспечению ссылочной целостности

Ссылочная целостность (referential integrity), иногда называемая целостностью отношений (relation integrity), устанавливает взаимоотношения между различными столбцами и таблицами в базе данных. Ссылочная целостность гарантирует, что каждое значение столбца во внешнем ключе (foreign key) дочерней (child), или подчиненной (detail), таблицы соответствует значению первичного или дополнительного ключа родительской (parent), или основной (master), таблицы, связанной с дочерней. Например: строка таблицы ЕМР не является корректной, если поле номера отдела (department number -- deptno), в котором работает служащий (employee), не ссылается на корректный номер отдела (department) в таблице DEPT. Когда родительская и дочерняя таблицы совпадают, это называется самоссылочной целостностью (self-referential integrity).

20.4 Действия по обеспечению ссылочной целостности

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

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

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

- Update/Delete Restrict (ограничение обновления/удаления). СУБД не позволяет приложению обновлягь родительский ключ или удалять родительскую строку, если ключ или строка имеет зависимые дочерние записи. Например, нельзя удалить из таблицы заказ на продажу, если с ним связаны пункты заказа в другой таблице

- Delete Cascade (каскадное удаление). Когда приложение удаляет строку родительской таблицы, РСУБД каскадно удаляет все зависимые записи в дочерней таблице. Например, при удалении заказа из одной таблицы РСУБД автоматически удаляет все соответствующие пункты этого заказа из другой таблицы.

- Update/Cascade (каскадное обновление). Когда приложение обновляет родительский ключ, РСУБД каскадно обновляет зависимые внешние ключи. Например, при изменении идентификатора заказа в таблице Заказов РСУБД автоматически обновит идентификаторы заказа всех соответствующих записей о пунктах этого заказа в других таблицах. Действие по обеспечению ссылочной целостности крайне полезно, так как обычно в приложениях пользователям, не разрешается обновлять значения ключей.

- Update/Delete Set NULL (установление null-значений при обновлении/удалении). Когда приложение обновляет или удаляет родительский ключ, значения всех зависимых ключей сгановятся null-значениями.

- Update/Delete Set Default (установление значений по умолчанию при обновлении/удалении). Когда приложение обновляет или удаляет родительский ключ, значениями всех зависимых ключей становятся осмысленные значения по умолчанию.

По умолчанию для всех ограничений ссылочной целостности в Oracle используется действие Update/Delete Restrict. Кроме того, для ограничения ссылочной целостности Oracle может выполнять действие Delete Cascade.

20.4.1 Механизм проверки ограничений целостности

Oracle может проверять ограничения целостности в двух ситуациях:

* Сразу после того, как приложение инициирует SQL-оператор ввода, обновления или удаления строк. Если оператор вызывает нарушение целостности данных, Oracle автоматически отменяет результаты выполнения этого оператора.

* Oracle может отложить проверку ограничения целостности для SQL-оператора транзакции до ее завершения. Если любой оператор транзакции вызывает нарушение целостности данных, Oracle автоматически совершает откат всей транзакции (т.е. отменяет результаты выполнения всех операторов транзакции).

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

20.5 Представления как один из способов отображения табличных данных

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

* Можно воспользоваться простым представлением для отображения всех строк и столбцов, содержащихся в таблице, например, создать представление, отображающее все записи о клиентах таблицы Покупатели.

* Можно воспользоваться представлением для обеспечения защиты данных некоторой таблицы, отобразив лишь подмножество строк и/или столбцов таблицы. Например, можно создать представление, отображающее столбцы «фамилия», «имя» и «телефон» только для клиентов таблицы Покупатели, проживающих в США (USA).

* Можно воспользоваться представлением для упрощения программирования приложений. С помощью сложного представления можно соединить данные связанных родительской и дочерней таблиц для создания видимости наличия в базе данных еще одной таблицы. К примеру, можно создать представление, которое будет соединять связанные записи таблиц Зaкaзы и Пункты заказов.

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

Представления достаточно удобны для отображения табличных данных. Представление, по сути, - это запрос, который Oracle сохраняет в словаре данных базы данных в качестве объекта базы данных. Когда приложение использует в своей работе представление, Oracle извлекает данные, являющиеся частью представления, при помощи определяющего запроса (defining query) представления.

20.5.1 Представления только для чтения

Один из видов представлений, поддерживаемых в Oracle8, - представления только для чтения (read-only views). Такие представления используются при выборе необходимых табличных данных, однако с помощью таких представлений приложения не могут вводить, обновлять или удалять данные, содержащиеся в таблицах.

20.5.2 Обновляемые представления

В Oracle8 разрешается определять обновляемые представления (updatable views), которые могутиспользоваться приложениями для ввода, обновления и удаления табличных данных и для выполнения запросов.

Основной принцип представления - ограничения для обновляемых представлений

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

20.5.3 Триггеры INSTEAD OF и обновляемые представления

Даже в том случае, когда атрибуты представления нарушают основное правило представления, можно сделать представление обновляемым, если определить его с триггерами INSTEAD OF. Триггеры (triggers) INSTEAD OF (вместо) - это программы языка PL/SQL, определяемые вместе с представлением. Эти триггеры описывают последователььность действий, если операторы INSERT (ввести), UPDATE (обновить) или DELETE (удалить) применяются к представлению, которое при других обстоятельствах не было бы обновляемым.

20.5.4 Обновляемые представления и ограничения целостности

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

20.5.5 Представления других типов

В Oracle8 можно создавать представления только для чтения и обновляемые представления, поддерживающие уникальные возможности сервера:

* Представления разделения

* Объектные представления

20.6 Индексы -- повышение производительности доступа к таблицам

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

Основным способом снижения объема операций дискового ввода/вывода и повышения производительности доступа к таблицам является рациональное использование индексов. Как индекс (предметный указатель) для книги, так и индекс (index) по столбцу (или группе столбцов) таблицы дает возможность Oracle быстро наводить в таблице указанные записи. Когда приложение обращается к таблице с запросом и указывает в критериях выбора индексированный столбец, Oracle автоматически использует индекс для того, чтобы быстро найти необходимые строки с минимальным объемом операций дискового ввода/вывода. Чтобы обнаружить строки, соответствующие критериям выбора, без индекса, Oracle приходится считывать всю таблицу с диска.

Наличие индекса для таблицы совсем не обязательно и незаметно для пользователей и разработчиков приложений баз данных:

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

* Когда известно, что имеющийся индекс поможет в выполнении запроса приложения, Oracle автоматически использует этот индекс; в противном случае индекс игнорируется

* Oracle автоматически обновляет индекс для обеспечения его синхронизации с базовой таблицей.

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

Для обеспечения функционирования многочисленных приложений в Огас1е8 поддерживается несколько разных типов индексов.

20.6.1 Другие возможности индексирования

Как и для представлений, в Oracle8 разрешается создавать индексы специальных типов для поддержания уникальных функциональных, возможностей сервера.

* Индексы разделения

* Индексы с обратными ключами

20.6.2 Кластеры данных -- уникальный способ хранения табличных данных

В качестве альтернативы индексированию в OracIe8 предлагаются кластеры данных, что также приводит к снижению количества операции дискового ввода/вывода, необходимых для обращения к таблицам. Кластер данных (data cluster) -- это уникальный способ хранения табличных данных. В кластере данных Oracle объединяет связанные строки одной или нескольких таблиц в блоке данных.

Причиной применения кластеров данных является необходимость группирования на диске тех строк, которые приложение часто использует совместно. Если приложение запрашивает группу строк, Oracle может считать все необходимые строки при помощи одной или небольшого числа операций дискового ввода/вывода. Например, можно использовать кластер данных для того, чтобы заранее соединить таблицы Заказы (ORDERS) и Пункты Заказов (ITEMS) в хранилище данных. Когда приложение по анализу объема продаж запрашивает протокольную информацию о конкретных заказах на продажу, Oracle может считать данные о нужном заказе с помощью всего лишь одной операции дискового ввода/вывода. И наоборот, когда связанные строки некластеризованы и разбросаны по разным блокам данных на диске, для выполнения запроса приложения потребуется несколько операций дискового ввода/вывода.

Как показано на рисунке, каждый кластер данных имеет кластерный ключ (cluster key). Ключ кластера данных -- это столбец (группа столбцов), определяющий способ кластеризации данных. В нашем примере кластерным ключом является столбец ORDERS_ID обеих таблиц.

В Огас1е8 предлагается два типа организации кластеров данных; индексированные кластеры данных и хэш-кластеры данных.

20.7 Последовательности -- эффективная генерация уникальных значений

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

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

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

20.8 Синонимы -- объекты с различными именами

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

Для того чтобы сделать приложения менее зависимыми от объектов баз данных, рекомендуется создавать для объектов синонимы. Синоним (synonym) -- это простой псевдоним для таблицы, представлен ния, последовательности или другого объекта баз данных. Синоним является всего лишь "запасным" именем объекта, поэтому для его хранения требуется его определение в словаре данных. Когда приложение использует синоним, Oracle передает запрос объекту, являющемуся базовым для этого синонима.

В Oracle разрешается создавать как общие, так и частные синонимы. Общий синоним {public synonym) -- это псевдоним объекта, доступный каждому пользователю базы данных. Частный синоним (private synonym) расположен внутри схемы конкретного пользователя, имеющего полный контроль над применением данного синонима другими пользователями.

21. Хранение баз данных

Информация баз данных хранится в структурированном виде. Для хранения данных в базах данных Oracle используются как логические, так и физические структуры хранения (storage structures), причем они взаимосвязаны.

* Логическая структура хранения данных (logical storage structure) - это концептуальная структура данных, например база данных или таблица.

* Физическая структура хранения данных (physical storage structure) -- этo реальная единица хранения данных, например файл или блок данных.

Здесь рассмотрим физические и логические структуры хранения информации баз данных Oracle, в том числе:

* Табличные области

* Файлы данных

* Управляющие файлы

* Сегменты данных, индексные, временные сегменты и сегменты отката

* Экстенты

* Блоки данных

* Разделение данных для таблиц и индексов

21.1 Табличные области

Табличная область (tablespace) -- это логическая структура данных в базе данных Oracle,- которой соответствуют один или более физических файлов данных (data files) на диске.

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

Физически объекты базы данных, сохраняемые в табличной области, отображаются на ее базовых файлах данных.

Когда табличная область имеет только один файл данных, все данные, содержащиеся во всех объектах области, хранятся в нем одном.

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

21.1.1 Табличная область SYSTEM

Для каждой базы данных Oracle существует по меньшей мере одна табличная область, называемая SYSTEM (системная табличная область -- SYSTEM tablespace). При создании новой базы данных Oracle необходимо указывать имена, размеры и другие характеристики файлов данных, которые будут обеспечивать физическое хранение табличной области SYSTEM.

Табличная область SYSTEM используется для:

* Хранения словаря данных базы данных.

* Хранения исходного и скомпилированного кода всех программ PL/SQL, таких как хранимые процедуры и функции, модули, триггеры базы данных и методы объектных типов. Для тех баз данных, в которых широко применяются программы PL/SQL, необходимы достаточно большие табличные области SYSTEM.

* Хранения тех объектов базы данных, которые не содержат каких-либо данных, а являются просто описаниями: представлений, описаний объектных типов и последовательностей. Такие объекты хранятся в словаре данных, который находится в табличной области SYSTEM.

21.1.2 Другие табличные области

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

* Данных, с которыми работают приложения, и внутренней информации словаря данных в табличной области SYSTEM

* Данных, содержащихся в таблицах приложений, и индексных данных

* Данных об откате транзакций

* Временных данных, используемых при выполнении внутрисистемных процессов.

Пусть планируется построить базу данных Oracle для обеспечения функционирования бухгалтерского (ACCOUNTING) и производственного (MANUFACTURING) приложений, причем каждое из них должно использовать собственную труппу таблиц базы данных. Одним из способов организации такой базы данных является создание нескольких табличных областей, отделяющих места хранения таблиц и индексов одного приложения от аналогичных мест хранения другого приложения. Получаемая конфигурация, а также отдельные табличные области для временных данных (TEMP) и данных отката (ROLLBACK) системы представлены на рисунке:

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

21.1.3 Оперативные и отключенные табличные области

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

* Данные, содержащиеся в оперативной (online) табличной области, доступны приложениям и базам данных. Как правило, табличные области всегда оперативны, и пользователи могут работать с их информацией.

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

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

21.1.4 Постоянные и временные табличные области

Большинство табличных областей в базе данных Oracle являются постоянными. В постоянной табличной o6ласти (permanent tablespace) хранится информация, которая должна оставаться неизменной при выполнении SQL-запросов и транзакции. Например, постоянная табличная область необходима для хранения информации таблиц, индексов и информации об откате транзакций.

В базе данных Oracle можно создавать также временные табличные Области. Временная табличная область (temporary tablespace) -- это большое временное рабочее пространство, которое может использоваться для выполнения сложных SQL-операций: запросон с сортнровкой, соединяющих запросов и операции построения индексов. Вместо того чтобы тратить нремя на создание и удаление множества мелких временных сегментов и постоянной табличной области, Oracle может быстро выделить временное рабочее пространство для SOL-операторов, выполняя определенные действия над элементами таблицы сортировки сегментов временной табличной области.

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

21.1.5 Табличные области только для чтения и чтения/записи

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

Иногда в табличной области хранятся архивные данные, которые никогда не изменяются. В этом случае ее можно сделать таблично» областью только для чтения (read-only tablespace), что предотврагит возможность ненужного изменения данных. Кроме того, задание для статической табличной области режима "только для чтения" сбережет время при выполнении резервного копирования базы данных, так как при этом можно будет не копировать табличную область только для чтения.

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

21.1.6 Дополнительные сведения о файлах данных

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

21.1.7 Число файлов данных для табличной области

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

Во время создания базы данных Oracle устанавливается верхняя граница числа файлов данных. Чтобы не достигать этой границы, при планировании базы данных и ее табличных областей не используйте слишком много файлов данных.

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

21.1.8 Размеры файлов данных

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

* Добавить один или несколько файлов данных к табличной области.

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

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

Некоторые операционные системы позволяют Oracle использовать в качестве файлов данных какие-либо устройства. Например, файлом данных дня табличной области может быть первичный раздел на диске UNIX. В таких случаях увеличение размера файла не имеет смысла.

ВНИМАНИЕ

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

21.1.9 Повреждение файлов данных

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

21.1.10 Оперативные и отключенные файлы данных

Oracle осуществляет контроль за работой с файлами данных табличных областей. Файл данных может быть либо оперативным (online), т.е. доступным, либо отключенным (offline) , т.е. недоступным. В обычных условиях файлы данных являются оперативными. Когда Oracle пытается прочитать или записать файл, но не может этого сделать, файл автоматически отключается. При этом соответствующая табличная область остается оперативной, потому что другие ее файлы данных могут быть доступны. Если возникает какая-либо проблема, файл данных можно отключить вручную, а когда она устранена (например, после восстановления файла данных), отключенный файл можно опять вручную сделать оперативным.

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

21.2 Управляющие файлы

Для каждой базы данных Oracle существует управляющий файл (control file), в котором находится информация о физической структуре базы данных. Управляющий файл содержит имя базы данных, а также имена и местонахождение всех файлов, имеющих к ней отношение. Кроме того, с помощью управляющего файла отслеживается и регистрируется внутрисистемная информация: о табличных областях, файлах данных и о резервных копиях системы.

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

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

21.2.1 Зеркально отображенные управляющие файлы

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

21.2.2 Сегменты, экстенты и блоки данных

Сегменты, состоящие из блоков данных, выделяются для физического хранения объектов базы данных: таблиц, индексов, кластеров данных и других объектов хранения. Группа последовательных блоков данных (data blocks), выделяемая для хранения объектов базы данных, представляе собой экстент (extent). Сегмент (segment) -- это совокупность всех экстентов, отведенных объекту базы данных.

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

21.2.3 Сегменты данных и индексные сегменты

Для различных объектов баз данных Oracle создает различные сегменты. Например, при создании таблицы одновременно создается сегмент данных (data segment) для хранения ее информации. Сегмент данных создается и при создании кластера данных; в таком сегменте хранятся данные всех таблиц, помещаемых в кластер. А при создании индекса одновременно создается индексный сегмент (index segment) для хранения информации этого индекса.

21.2.4 Временные сегменты

Для выполнения SQL-операторов часто требуются временные рабочие области. Например, при создании индекса для большой таблицы, необходимо некоторое временное пространство системы, чтобы перед построением индексного сегмента можно было отсортировать все индексные элементы. Когда обрабатывается SQL-оператор, для которого требуется временное рабочее пространство, Oracle выделяет небольшие временные сегменты (temporary segments) в табличной области базы данных. Когда выполнение оператора завершается Oracle возвращает сегменты табличной области, и это пространство может впоследствии использоваться для других объектов.

21.2.5 Временные табличные области

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

21.2.6 Сегменты отката

Результатом выполнения любой транзакции может стать либо ее завершение, либо ее откат. Как правило, транзакция завершается (commit); при этом все внесенные ею изменения записываются в базу данных. Откат {rollback) транзакции отменяет все ее результаты, как если бы она никогда не выполнялась. Чтобы гарантировать откат транзакции, Oracle должна следить за данными, модифицируемыми транзакцией, до тех пор, пока она не завершится или не будет выполнен ее откат.

Для записи данных отката транзакции в Oracle существуют специальные сегменты, называемые сегментами отката (rollback segments). Иногда их называют сегментами отмены (undo segments). Когда выполняется откат транзакции, Oracle считывает нужные данные в сегменте отката, чтобы воссоздать информацию в том виде, в каком она была до изменения ее транзакцией.

21.2.7 Запись информации в сегменты отката

Oracle записывает информацию в сегменты отката не так, как это происходит с сегментами других видов. На рисунке ниже показано, как производится запись информации в экстенты сегмента отката.

Oracle записывает информацию в экстенты, составляющие сегмент отката, циклически.

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

21.2.8 Сегмент отката SYSTEM

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

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

21.2.9 Несколько сегментов отката

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

Когда начинает выполняться новая транзакция, Oracle автоматически назначает ей доступный сегмент отката базы данных. Чтобы распределить нагрузку среди всех доступных сегментов отката, это назначение производится по алгоритму циклического обслуживания, иногда называемому каруселью (round-robin).

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

21.2.10 Назначение конкретных сегментов отката

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

21.3 Блоки данных

Блок данных (data block) -- это единица доступа к дисковой памяти для базы данных Oracle. Посредством блоков данных осуществляется сохранение и считывание информации. Например, когда для некоторой таблицы формируется запрос, Oracle считывает в память сервера все блоки данных, которые содержат строки результирующего множества этого запроса.

При создании базы данных следует указать для нее размер блока, который должен быть равен или кратен размеру блока, используемому операционной системой сервера. Например, если размер блока, операционной системы сервера равен 512К, то размер блока базы данных, установленной на этом сервере может быть ранен 5l2K, 1024K, 2048K и т.д.

Выделение блоков данных

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

21.3.1 Сцепление строк и размер блока данных

Когда в таблицу вводится новая строка, Oracle помещает эту строку в блок данных из списка свободных блоков таблицы. В оптимальном варианте Oracle размещает всю информацию новой строки в одном блоке данных. Таким образом, при запросе какой-либо строки таблицы Oracle выбирает необходимую информацию, считывая только один блок данных с диска в оперативную память.

Если строка больше, чем блок данных, то Oracle формирует сцепленную (chained) строку, связывая ее с двумя или более блоками данных.

Сцепление строк нежелательно, хотя в этой ситуация оно неизбежно. Дело в том, что для обращения к данным таких строк Oracle приходится считывать с диска в память множество блоков данных. Чем больше число операций дискового ввода/вывода, тем медленнее функционирует система. Поэтому сцепления строк следует избегать.

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

Кроме того, Oracle может создать сцепленную строку, когда пользователь обновляет строку таблицы или индекса. Это происходит, когда:

* Пользователь обновляет строку таким образом, что она становится больше исходной.

* В блоке данных, хранящем строку, нет свободного пространства, достаточного для выполнения обновления.

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

21.4 Параметры хранения объектов

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

21.4.1 Размещение табличных областей

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

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

21.4.2 Параметры для экстентов

При создании нового объекта хранения данных можно задавать различные установки, с учетом которых для сегмента этого объекта выделяются экстенты:

* Число экстентов, выделяемых при создании сегмента. При создании нового сегмента Oracle выделяет по крайней мере один экстент.

* Максимальное число экстентов, выделяемых при создании сегмента.

* Размер экстентов сегмента. Можно установить размер начального и последующих экстентов сегмента, а также коэффициент возрастания, применяемый перед выделением сегменту новых экстентов.

Например, с помощью следующего оператора CREATE TABLE можно управлять выделением экстентов сегменту данных для новой таблицы CUSTOMERS:

CREATE TABLE sales.customers

(... описания столбцов ...}

STORAGE (

INITIAL 500K

NEXT 500K

MINEXTENTS 1

MAXEXTENTS 10

PCTINCREASE 50 );

Когда создается новый сегмент данных для таблицы CUSTOMERS, сервер выделяет ему один начальный экстент размером 500K (INITIAL). Когда этот экстент заполняется, Oracle выделяет следующий экстент размером 500K (NEXT) и изменяет размер последующего экстента сегмента до 750К (т.е. 500K увеличивается на 50% (PCTINCREASE)). Когда требуется новый экстент, Oracle выделяет его (размером 750К) и изменяет размер следующего экстента сегмента до 1125К (т.е. 750К увеличивается на 50%). Такое выделение экстентов продолжается до десятого экстента (MAXEXTENTS), что является пределом для числа экстентов в сегменте. Естественно, можно изменять параметры хранения объектов, например для того; чтобы увеличить максимальное число экстентов для объекта.

Для параметра MAXEXTENTS можно установить значение UNLIMITED. При этом сегменту будет выделяться неограниченное число экстентов.

21.4.3 Установки по умолчанию для хранения объектов

В большинстве случаев параметры хранения объектов не являются обязательными; они позволяют управлять хранением информации каждого объекта. Для параметров хранения всегда существуют установки по умолчанию. Далее показано, как задавать такие установки для объектов хранения данных базы данных Oracle.

21.4.4 Установки по умолчанию для пользователей

Для каждого пользователя можно установить табличную область по умолчанию и временную табличную область. Когда пользователь создает новый объект базы данных и не указывает для него табличную область явно, Oracle сохраняет новый объект в табличной области по умолчанию для этого пользователя; Во временной табличной области пользователя Oracle, по мере необходимости, выделяет временное рабочее пространство для его SQL-операторов.

21.4.5 Установки по умолчанию для табличных областей

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

* Размеров начального и последующих экстентов сегмента

* Минимального и максимального числа экстентов в сегменте

* Коэффициента возрастания последующих экстснтон сегмента.

21.5 Разделение данных

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

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

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

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

Чтобы уменьшить вероятность возникновения проблем такого рода в Огас1е8 поддерживается разделение таблиц и индексов.

21.5.1 Разделенные таблицы

В Oracle8 можно разбивать области хранения таблиц на более мелкие единицы дисковой памяти, называемые разделами {partitions).

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

...

Подобные документы

  • Резервные базы данных под управлением Oracle Data Guard. Создание физической резервной базы. Защита резервных копий баз данных и базы данных разработчиков. Восстановление базы данных на удаленной машине. Стратегия резервирования и восстановления.

    дипломная работа [499,7 K], добавлен 04.06.2013

  • Краткая история развития СУБД ORACLE, основные понятия и определения, архитектура. Принципы работы с СУБД ORACLE. Разработка баз данных, средства и технологии их реализации; возможности процедурного языка PL/SQL. Приемы администрирования СУБД ORACLE.

    презентация [609,2 K], добавлен 14.02.2014

  • Обзор и сравнительная характеристика программного обеспечения для создания СУБД. Принципы организации данных. Основные возможности MS Access. Разработка структуры и реализация средствами SQL базы данных для учета заказов, наличия и продажи автозапчастей.

    курсовая работа [2,5 M], добавлен 27.05.2013

  • Анализ реляционных баз данных и способов манипулирования ими. Основные понятия баз данных, архитектура СУБД, модели данных. Модель сущность-связь, характеристика связей, классификация сущностей, структура первичных и внешних ключей, целостности данных.

    курсовая работа [166,6 K], добавлен 18.07.2012

  • Инфологическая модель предметной области. Схемы простых объектов и их свойства. Построение реляционных отношений на основе инфологической модели базы данных. Сетевая и иерархическая даталогическая модели БД. Структура таблиц, реализованных в СУБД Oracle.

    курсовая работа [1,0 M], добавлен 10.06.2014

  • Базы данных (БД) и системы управления базами данных (СУБД) как основы современной информационной технологии, их роль в хранении и обработке информации. Этапы реализации БД, средств ее защиты и поддержки целостности. Протоколы фиксации и отката изменений.

    презентация [364,2 K], добавлен 22.10.2013

  • Анализ данных предметной области. Информационно-логическая модель базы данных. Физическое проектирование и мероприятия по защите и обеспечению целостности базы данных. Приложение интерфейса для SQL-сервера базы данных на языке программирования Delphi.

    курсовая работа [2,2 M], добавлен 30.05.2013

  • Объекты модели хранения данных базы данных ORACLE. Взаимосвязь между логическими структурами. Средства манипулирования данными языка SQL, данными языка SQL. Структура выполнения простейших запросов. Формирование критерия отбора. Сортировка данных.

    презентация [120,1 K], добавлен 14.02.2014

  • Общая характеристика системы управления базами данных MySQL, ее основные особенности и возможности, касающиеся обеспечения целостности данных. Реализация ограничений семантической и ссылочной целостности в СУБД MySQL на примере фрагмента ИС "Салон магии".

    курсовая работа [981,0 K], добавлен 14.10.2012

  • Процесс поступления пациента в больницу. Программное обеспечение, используемое в разработке. Обзор Borland Delphi7, MS SQL Server 2008. Динамическое изменение и расширение структуры базы данных. Обоснование выбора СУБД и программного обеспечения.

    курсовая работа [875,4 K], добавлен 21.04.2013

  • Разработка информационного обеспечения для формирования базы данных для государственной итоговой аттестации 9 классов. Обзор методов репликации и синхронизации баз данных. Преимущества алгоритма шифрования Rijndael. СУБД Microsoft SQL Server и Firebird.

    дипломная работа [3,3 M], добавлен 27.06.2012

  • Архитектура и функции СУБД. Инфологическая модель данных "Сущность-связь". Ограничения целостности. Характеристика связей и язык моделирования. Манипулирование реляционными данными. Написание сервера на Java.3 и приложения-клиента на ActoinScript 3.0.

    курсовая работа [935,3 K], добавлен 09.07.2013

  • Система управления базой данных (СУБД), централизованное обеспечение безопасности и целостности данных, защита от несанкционированного доступа. Построение концептуальной и реляционной моделей. Процесс нормализации. Проектирование базы данных в ACCESS.

    курсовая работа [1,8 M], добавлен 29.10.2008

  • Характеристика реляционной, иерархической и сетевой моделей баз данных. Анализ методов проектирования (декомпозиция, синтез, объектная связь), организации, обновления, восстановления, ограничений, поддержания целостности данных на примере СУБД Ms Access.

    дипломная работа [347,4 K], добавлен 13.02.2010

  • Порядок проектирования и разработки базы данных и программного обеспечения. Информация о структуре базы данных, созданных таблицах, формах, отчетах, запросах, хранимой информации. Логическая и концептуальная модели данных; выбор программного обеспечения.

    курсовая работа [906,6 K], добавлен 20.01.2010

  • Определение состава реляционных таблиц и логических связей между ними. Создание схемы (пользователя) базы данных. Особенность получения таблиц и ограничения целостности. Выполнение загрузки, модификации и удаления. Поддержка транзакций в Oracle.

    лабораторная работа [4,8 M], добавлен 25.10.2021

  • Понятие базы данных, их цели и задачи, требования к БД; система управления базами данных. Файловые системы: именование и структуры файлов, программное обеспечение. Уровни абстракции в СУБД, функции абстрактных данных. Экспертные системы и базы знаний.

    презентация [301,6 K], добавлен 17.04.2013

  • Структура и функции системы управления базами данных (СУБД). Управление хранением данных и доступом к ним. Защита и поддержка целостности данных. Надежность хранения данных во внешней памяти. Классификация СУБД по способу доступа к базе данных.

    презентация [3,7 M], добавлен 05.06.2014

  • Определение, свойства и характеристики распределенных систем баз данных. Основная задача систем управления ими. Архитектура распределения СУБД. Сравнение технологий файлового сервера и "клиент-сервера". Стратегия распределения данных по узлам сети ЭВМ.

    курсовая работа [601,3 K], добавлен 24.05.2015

  • Изучение основных понятий баз данных: структура простейшей базы данных, компоненты базы данных Microsoft Access. Проектирование базы данных "Туристическое агентство" в СУБД Access 2010, в которой хранятся данные о клиентах, которые хотят поехать отдыхать.

    курсовая работа [3,3 M], добавлен 20.09.2013

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.