Андреева Е.Г. Базы данных - файл n1.doc

приобрести
Андреева Е.Г. Базы данных
скачать (129.8 kb.)
Доступные файлы (1):
n1.doc397kb.07.06.2005 20:21скачать

n1.doc

1   2   3

Организация среды хранения базы данных

Важным архитектурным компонентом СУБД являются механиз­мы внутреннего уровня системы, реализующие функции среды хра­нения базы данных. База данных полностью представлена в «материализованном» ви­де только в среде хранения. На всех остальных уровнях архитекту­ры системы порождаются и исчезают лишь отдельные объекты дан­ных, срок жизни которых ограничивается временем выполнения различных операций манипулирования данными.

Механизмы среды хранения и архитектура СУБД. Механизмы среды хранения базы данных служат для управления двумя группа­ми ресурсов системы – ресурсами хранимых данных и ресурсами пространства памяти среды хранения. Они обеспечивают поддержку представления «физической» базы данных - структуры хранимых данных, управление пространством памяти базы данных, а также поддержку отображения структуры храни­мых данных в пространство памяти, позволяющего определить ме­сто их размещения при запоминании и при поиске данных.

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

Никакого обновления значений «пользовательских» данных непосредственно на уровне среды хранения система не производит. Эти операции выполняются на более высоких архитектурных уровнях. Здесь не производится никаких преобразований представления хранимых данных. Такие преобразования являются функцией механизмов отображения данных «концептуальный уровень – внутренний уровень».

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

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

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

Как и схемы базы данных других архитектурных уровней, схема хранения оперирует в терминах типов, а не экземпляров объектов хранимых данных. Для ее спецификации используются специаль­ные языковые средства. Пример глубоко проработанной концепции управления средой хранения базы данных представляет собой Язык определения хранимых данных (Data Storage Definition Language), разработанный CODASYL.

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

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

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

Важная функция механизмов среды хранения – поддержка свя­зей между хранимыми записями. Именно в терминах хранимых за­писей и связей между ними в среде хранения представляется струк­тура базы данных. Способы представления связей определяются схемой хранения и чаще всего основаны на использовании указателей.

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

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

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

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

Каждой хранимой записи в пространстве памяти ставится в со­ответствие ее адрес, определяющий место размещения записи. В подходе CODASYL адрес хранимой записи называют ее ключом ба­зы данных.

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

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

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

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

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

В других случаях функции языков могут быть доступны косвенным образом, когда они реализуются в форме различного рода меню, диалоговых сценариев или заполняемых пользователем таблиц. По таким входным данным интерфейсные средства формируют адекватные синтаксические конструкции языка интерфейса и передают их на исполнение или включают в генерируемый программный код приложения. Интерфейсы с неявным использованием языка широко используются в СУБД для персональных компьютеров. В ре­ляционных СУБД широко распространен основанный на таком подходе табличный язык Query-By-Example (QBE).

Языковые средства СУБД используются для выполнения двух основных функций – для описания представления базы данных на управляемых уровнях системной архитектуры и для инициирования выполнения операций манипулирования данными.

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

Многие системы не имеют самостоятельных языков для спецификации междууровневых отображений данных. В таких случаях определения способов отображения также описываются средствами ЯОД одного из смежных архитектурных уровней. Они включаются при этом в соответствующую схему базы данных. Так, в подсхеме базы данных CODASYL (внешней схеме, по терминоло­гии отчета ANSI/SPARC) специфицируется отображение ее объек­тов в среду схемы базы данных (концептуальной схемы, по терми­нологии ANSI /SPARC).

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

Язык манипулирования данными (ЯМД) позволяет запрашивать предусмотренные в системе операции над данными из базы данных. Аналогично языку определения данных ЯМД не обязательно высту­пает в форме синтаксически самостоятельного языка СУБД. На практике разделение ЯОД и ЯМД играет скорее методическую роль или используется в технологических целях.

Имеются многочисленные примеры языков СУБД, объединяющих возможности описания данных и манипулирования данными в единых синтаксических рамках. Весьма популярным среди языков такого рода является реляционный язык SQL, разработанный в исследовательской лаборатории фирмы IBM Corp. в Сан-Хосе и реализованный в середине 70-х годов в экспериментальной реляционной СУБД System R, а впоследствии и в коммерческих системах; SQL/DS и DB2.

В настоящее время SQL весьма широко распространен. Приняты стандарты SQL как реляционного языка, разработанные Американским национальным институтом стандартов (ANSI) и Международной организацией по стандартизации (ISO). Он используется во многих СУБД, особенно на персональных компьютерах.

Другими примерами языков этого класса могут служить языки Quel системы Ingres, созданной в Калифорнийском университете, языковые средства большинства СУБД для персональных компьютеров, например язык dBase семейства СУБД фирмы Ashton-Tate и многочисленных совместимых с ними систем, язык СУБД R:Base фирмы Microrim.

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

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

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

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

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

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

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

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

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

Третья группа – администратор приложенийобеспечивает поддержку представлений базы данных для различных групп ее пользователей механизмами внешнего уровня архитектуры СУБД. Она несет ответственность за всю совокупность внешних схем базы данных.

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

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

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

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

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

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

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

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

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

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

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

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

Процесс проектирования базы данных должен включать следую­щие этапы:

– инфологическое проектирование;

– определение требований к операционной обстановке, в которой будет функционировать информационная система;

– выбор СУБД и других инструментальных программных средств ее реализации;

– логическое проектирование базы данных;

– физическое проектирование базы данных.

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

На практике встречается в основном два подхода к выбору со­става и структуры предметной области.

Наиболее распространен подход, который называется функциональным. Он реализует принцип «от задач» и применяется в случае, когда заранее известны функции некоторой группы лиц и/или комплекса задач, для обслуживания информационных по­требностей которых создается рассматриваемая база данных.

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

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

В простейших случаях проектировщик базы данных ограничива­ется содержательным описанием модели предметной области на ес­тественном языке. Он может использовать также разнообразные выразительные средства для изображения структуры предметной области, такие, как диаграммы типов (диаг­раммы сущностей-связей).

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

Одним из центральных вопросов в разработке проекта является выбор инструментальной системы управления базами данных. Выбор СУБД принципиальным обра­зом влияет на весь процесс проектирования базы данных и реали­зации информационной системы.

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

– тип модели данных, которую поддерживает данная СУБД, ее адекватность потребностям моделирования рассматриваемой пред­метной области;

– характеристики производительности системы;

– наличие в данной СУБД средств разработки приложений;

– запас функциональных возможностей для дальнейшего развития информационной системы, разрабатываемой средствами данной СУБД;

– степень оснащенности системы инструментарием для персонала администрирования данными;

– удобство и надежность СУБД в эксплуатации.

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

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

Более сложный характер имеет проектирование распределенных баз данных.

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

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

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

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Когаловский М. Р. Технология баз данных на персональных ЭВМ. – М.: Финансы и статистика, 1994. – 224 c.

2. Дейт К. Введение в системы баз данных. – М.: Вильямс, 2001. – 1071 с.

3. Диго С. М. Проектирование и использование баз данных. – М.: Финансы и статистика,1995. – 208 с.
ОГЛАВЛЕНИЕ
Введение…………………………………………………………………………. 3

Автоматизированные информационные системы……………………………. 4

Предметная область информационной системы……………………………… 6

База данных……………………………………………………………………… 9

Системы управления базами данных и их функции………………………….. 10

Модели данных………………………………………………………………….. 14

Архитектура систем управления базами данных………………………………16

Система баз данных……………………………………………………………... 18

Данные……………………………………………………………………….. 18

Аппаратное обеспечение……………………………………………………. 19

Программное обеспечение………………………………………………….. 19

Пользователи………………………………………………………………… 20

Базы данных…………………………………………………………………. 21

Преимущества систем БД………..…………………………………………. 21

Реляционные и другие системы…………………………………………………22

Архитектура системы баз данных……………………………………………… 23

Архитектура клиент/сервер…………………………………………………….. 23

Утилиты………………………………………………………………………….. 25

Распределенная обработка……………………………………………………… 26

Организация среды хранения базы данных……………………………………. 29

Языковые средства СУБД………………………………………………………. 32

Администрирование базами данных…………………………………………… 34

Словари-справочники данных………………………………………………….. 35

Проектирование базы данных………………………………………………….. 36

Библиографический список…………………………………………………….. 38
Редактор Н. Н. Пацула

ИД № 06039 от 12.10.2001.

Сводный темплан 2005.

Подписано к печати 3.06.05. Бумага офсетная.

Формат 6084 1/16. Отпечатано на дупликаторе.

Усл. печ. л. 2,5. Уч.-изд. л. 2,5

Тираж экз. Заказ

Изд-во ОмГТУ. 644050, г. Омск, пр. Мира, 11.

Типография ОмГТУ.

1   2   3


Организация среды хранения базы данных
Учебный материал
© nashaucheba.ru
При копировании укажите ссылку.
обратиться к администрации