1. Три формы существования мира. Какие процессы называются информационными?
| Вид материала | Документы |
- 1. введение в предмет, 69.23kb.
- Основные этапы эволюции растительного и животного мира, 173.64kb.
- «Сложность строения атома. Состояние электронов в атоме», 79.91kb.
- Лекция Функционально-позиционное устройство, 254.64kb.
- Природа квазирегулярности катастрофических изменений климата и их влияние на биоразнообразие, 292.52kb.
- Одним из факторов устойчивости биосферы и существования ее как единой целостной системы, 96.41kb.
- Российской Федерации Российской Федерации Государственный университет- высшая школа, 221.2kb.
- Программа информационно-управленческой практики для студентов 4 курса специальности, 223.04kb.
- Об ответственности за правонарушения при работе с информационными ресурсами, 60.01kb.
- Солнечная светлость книжной премудрости в стране Литературии, 54.88kb.
Что представляет предметная область при разработке ИС?
При разработке ИС предприятия область рассматривается прежде всего как некоторая совокупность реальных сущностей (объектов), которые представляют интерес для пользователей данной предметной области ИС. Свойства сущностей, которые представляют интерес в рамках одной системы, могут остаться вне сферы внимания другой предметной области, которой данная сущность также принадлежит.
Представление предметной области в терминах конкретных сущностей оказывается чаще всего громоздким, необозримым, не позволяет четко выкристаллизовать ее структуру. Поэтому в большинстве случаев прибегают к типизации сущностей предметной области. При этом все потенциальное множество сущностей предметной области разбивается на именованные группы объектов, однородных по структуре и поведению (относительно рамок рассматриваемой предметной области), называемые типами сущностей. При этом естественно предположить, что все «экземпляры сущностей» одного типа обладают одинаковыми наборами свойств (атрибутов), и таким образом можно условно считать эти их свойства свойствами типа. Свойства типа «делегируются» каждому экземпляру сущностей данного типа.
Подход к представлению предметной области, основанный на типизации ее сущностей, конечно, не является единственно возможным. Но в случаях, когда он приемлем, задача моделирования предметной области и операции над моделью становятся более формализованными.
Каждая сущность предметной области отличается от других сущностей, т.е. имеет свою индивидуальность. Так, в качестве уникальных идентификаторов лиц, при условии отсутствия однофамильцев, могли бы служить их фамилии. А если есть однофамильцы, то добавляется вторичный ключ, например, для студента можно использовать и наименование учебной группы. Точно так же, как можно говорить о типах сущностей предметной области, можно вести речь о типах связей и экземплярах связей этих типов.
Связи между типами сущностей могут быть любой размерности. На практике часто используются бинарные связи, устанавливающие соответствие между сущностями «связанных типов», - «одна к одной» (1:1), «одна к многим» (1:N), «многие к многим» (M:N).
46. Сущность предметной области, индивидуальность, типизация, связи, типы связей, интенсиональная модель предметной области. Каждая сущность предметной области отличается от других сущностей, т.е. имеет свою индивидуальность. Так, в качестве уникальных идентификаторов лиц, при условии отсутствия однофамильцев, могли бы служить их фамилии. А если есть однофамильцы, то добавляется вторичный ключ, например, для студента можно использовать и наименование учебной группы. Точно так же, как можно говорить о типах сущностей предметной области, можно вести речь о типах связей и экземплярах связей этих типов.
Совокупность типов сущностей предметной области и типов связей между ними характеризует типовую структуру предметной области и может рассматриваться как типовая модель предметной области. Такая модель характеризует свойства предметной области, неизменные (или почти неизменные) во времени (Интенсиональная модель предметной области).
47. Экстенсиональная модель предметной области. Ограничения целостности БД. Актуализация данных.
Вместе с тем экземпляры сущностей различных типов, значения атрибутов сущностей и связи между ними могут изменяться во времени. Изменения могут проявляться в появлении новых или исключении из рассмотрения некоторых существующих сущностей в предметной области, установлении новых или разрушении существующих связей меду ними, в изменении значений атрибутов именующихся сущностей. Поэтому с каждым моментом времени можно сопоставить некоторое состояние предметной области.
Эта модель характеризует свойства предметной области, изменяющиеся во времени (и называется экстенсиональной моделью предметной области).
Каждое состояние предметной области должно удовлетворять некоторым ограничениям, которые характеризуют смысл сущностей предметной области и связей между ними. Такие ограничения называются ограничениями целостности.
Для поддержки адекватного отображения состояний предметной области в БД необходимо динамически, в процессе функционирования ИС, обновлять (актуализировать) содержимое БД в соответствии с теми изменениями, которые происходят в предметной области.
48. Интегрированность данных. Минимизация избыточности данных. Репликаторы. БД рассматриваются как интегрированные совокупности данных. Это свойство БД означает, что каждый факт представлен в ней только один раз. Основополагающим принципом создания БД является. Наличие избыточных данных нарушает непротиворечивость БД и создает много сложностей по поддержанию БД в актуальном состоянии. Принцип минимизации избыточности данных на практике иногда сознательно нарушается ради улучшения некоторых других характеристик ИС. Так, в распределенных БД часто используется поддержка копий фрагментов базы данных (репликатов) на разных узлах сети ради сокращения сетевого трафика и повышения производительности системы. Но за это приходиться платить необходимостью синхронизации репликатов при обновлении одного из них.
49. Интегральная эффективность системы. Обычно БД создается для удовлетворения информационных потребностей многих пользователей и для поддержки решения ряда задач (приложений). Это означает, прежде всего, что критерии оценки возможных вариантов построения БД направлены на обеспечение интегральной эффективности системы, а не эффективности удовлетворения информационных потребностей отдельных ее пользователей. Указанные категории могут учитывать приоритеты различных пользователей, особенно при работе в интерактивном режиме, приоритеты и частоту решения различных задач, что на практике оказывается весьма сложной задачей. Однако в ответственных случаях для решения этой трудной проблемы используют оптимизационные математические модели, проводят эксперименты с имитационными моделями исследуемой системы для получения нужных оценок.
50. Два подхода для создания БД. При определении содержания БД (т.е. при анализе предметной области ИС) обычно используют два подхода. При первом подходе разработчик БД руководствуется априори заданными характеристиками информационных потребностей пользователей. При втором подходе такие характеристики заранее не известны, и потому стремятся включить в БД наиболее значимые факты предметной области, которые могут быть полезны многим пользователям.
51. СУБД: назначение, состав, типы, АБД. В соответствии с концепцией БД предполагается, что она представляет собой самостоятельный обобществленный централизованно управляемый ресурс некоторого сообщества пользователей, предназначенный для удовлетворения их информационных потребностей.
Создание БД, поддержка ее в актуальном состоянии и обеспечение доступа пользователей к ней осуществляется с помощью специального программного инструментария, называемого СУБД. Одна установка СУБД на ПК может управлять несколькими БД. Пользователей БД называют конечными пользователями. Кроме того, в качестве пользователей могут рассматриваться различные прикладные программы или программные комплексы (ППП), оперирующие данными из БД. Такие программные средства называют приложениями СУБД, которые взаимодействуют с СУБД через ее интерфейсы прикладного программирования.
Централизованный характер управления БД обусловлен необходимостью существования некоторого лица или группы лиц, на которых возлагаются функции администратора БД (АБД), действующего в интересах всех пользователей.
АБД ответственен за поддержку системы в работоспособном состоянии, своевременную актуализацию данных, эффективное использование информационных ресурсов системы и ресурсов памяти, предоставление полномочий пользователям на доступ к данным.
52. Сосредоточенные и распределенные БД. Различаются сосредоточенные и распределенные БД. Сосредоточенная БД полностью поддерживается на одном компьютере и доступна по запросам пользователей, работающих непосредственно на этом компьютере (с одного или нескольких рабочих мест). Также может использовать и сетевой доступ, который часто применяется в локальных (или удалённых) сетях. Появление компьютерных БД позволило создавать распределенные БД. Которые состоят из нескольких, возможно, пересекающихся или даже дублирующих частей, хранимых в разных частях вычислительных сетей (ВС). Части БД на отдельных узлах могут при этом использоваться одновременно в многопользовательском режиме как автономные локальные БД. Благодаря функциональным возможностям программного обеспечения, применяемого для поддержки и использования распределенных БД, фактор распределённости данных может быть призрачным для пользователей. В таких случаях пользователь распределенной БД не обязан знать, каким образом ее компоненты размещены в узлах сети, и представляет себе эту БД как единое целое. Работа с распределенной БД осуществляется с помощью системы управления распределенной БД. (СУРБД).
В распределенных БД используется два метода распределения данных – фрагментация и тиражирование. Фрагментация данных заключается в разбиении БД на составные части, хранимые в различных частях сети. Тиражирование данных используется для сокращения сетевого трафика и повышения производительности системы при обработке пользовательских запросов за счет того, что данные в сети размещаются в местах их порождения или активного использования. Естественно, что при обновлении копии возникает необходимость синхронизации состояния всех копий модифицированного фрагмента БД. Затраты ресурсов на эту процедуру является плата за сокращение сетевого трафика. Трафик – это поток данных в коммуникационных сетях.
Доступ к данным пользователей ИС возможен только через посредство СУБД. Их информационные потребности удовлетворяются при этом в рамках предоставленных им полномочий доступа к данным.
53. Системы общего назначения и специализированные СУБД. По степени универсальности применения различают два вида СУБД – системы общего назначения и специализированнее системы. СУБД общего назначения создаются без ориентации на какую-то конкретную предметную область или информационные потребности какой-либо группы пользователей. Эти системы могут выполнять функции управления данными, которые необходимы в различных областях применения. Такие СУБД обладают средствами настройки на работу с конкретной БД с учетом особенности ее применения. СУБД общего назначения способны в полной мере обеспечивать потребности весьма широкого круга применений.
Использование СУБД общего назначения как инструментального средства для создания ИС, основанных на технологии БД, позволяет значительно сокращать сроки разработки, экономить трудовые ресурсы. Развитые функциональные возможности таких СУБД, присущая или функциональная избыточность позволяет иметь «запас мощности», необходимый для эволюционного развития созданных ИС в рамках их жизненного цикла. Вместе с тем средства настройки дают возможность достигнуть приемлемого уровня производительности ИС в процессе ее эксплуатации. Однако существуют такие области применения, в которых доступные разработчикам информационных систем СУБД общего назначения не обладают средствами для естественного моделирования предметной области, не позволяют добиться требуемых характеристик производительности создаваемой системы и/или удовлетворить заданные ограничения, например, по объему памяти, предоставляемой для хранения БД. В других случаях может требоваться лишь некоторый ограничительный набор функций управления данными, которыми обладает СУБД общего назначения. Тогда СУБД общего назначения оказывается слишком тяжеловесной и требующей избыточных ресурсов. Возможно также, что использование СУБД общего назначения не желательно по каким-либо иным причинам.
В указанных случаях приходиться разрабатывать специализированные СУБД. Специализированная СУБД может эффективно выполнять необходимые функции управления данными и более рационально использовать компьютерные ресурсы. Это достигается благодаря учету при её разработке специфических особенностей рассматриваемого класса задач, к которым оказываются нечувствительными средства настройки имеющихся в СУБД общего назначения, либо за счет отказа от каких-либо функций СУБД общего назначения, не имеющих жизненно важного значения в рассматриваемых задачах.
Создание специализируемой СУБД, последующее ее сопровождение и развитие – весьма дорогостоящее и трудоемкое дело даже в сравнительно простых случаях. Поэтому для того чтобы избрать этот путь, нужно иметь действительно веские основания и твердую убежденность в невозможности или нецелесообразности использования какой-либо имеющейся СУБД общего назначения. Функциональные возможности существующих в настоящее время СУБД весьма богаты и позволяют удовлетворить потребности чрезвычайно широкого круга задач. Поэтому остается все меньше таких ситуаций, когда в действительности необходима разработка специализированных СУБД.
54. Создание БД, Настройка СУБД на работу, схема БД логическое представление данных, физическое представление данных.
СУБД общего назначения – сложный программный комплекс, предназначенный для выполнения всей совокупности функций, связанных с созданием и эксплуатацией систем БД, которые используются самостоятельно или в составе какой-либо крупной ИС. Разработчики систем БД имеют возможность настраивать СУБД общего назначения с создаваемой БД с учетом конкретных условий применения, инициировать БД, производить начальную загрузку и актуализацию данных. Системные механизмы таких СУБД выполняют функции управления ресурсами среды хранения , обеспечение логической и физической независимости данных, предоставление доступа к пользователям БД, защиту логической целостности БД, обеспечение физической целостности. Другая важная группа функций – управление полномочиями пользователей, организация параллельного доступа к БД, поддержка деятельности персонала администратора, ответственность за эксплуатацию БД.
Для создания БД и настройки СУБД на работу, разработчик описывает логическую структуру полной БД, организацию хранимых данных в тех рамках, которые допускает используема СУБД, а также способы ведения БД пользователями. При этом используются предоставляемые СУБД языковые средства определения данных. Такие описания БД называются схемой БД (логической схемой), схемой хранения (внутренней схемой) и подсхемами (внешними схемами). В соответствии с заданной схемой БД СУБД структурирует данные, вводимые в БД, корректно интерпретирует хранимые данные при осуществлении доступа к ним.
Принципиально важное свойство СУБД заключается в том, что она позволяет различать и поддерживать два независимых взгляда на БД – взгляд пользователя, часто называемый логическим представление данных, и взгляд системы, называемый физическим представлением данных, который характеризует организацию хранимых данных на МД.
- Кто управляет физическим размещением данных?
Пользователей не интересуют при работе с БД байты и биты, представляющие данные в среде хранения, их размещение в ВЗУ, указатели, поддерживающие связи между различными структурными компонентами хранимых данных, выбранные метода доступа. В тоже время все эти факторы важны для выполнения функций управления данными самой СУБД. Поддержка двух независимых представлений БД фактически сводится к тому, что на СУБД возлагается задача формирования из хранимой информации такого представления данных, которое отражает взгляд пользователя.
Важно отметить, что логические средства представления БД могут по своей структуре существенно отличаться от структуры хранимых данных и синтезироваться не только непосредственно из фактических хранимых объектов БД и их связей, но и с помощью различного рода операций агрегирования данных и различных программных встроенных процедур обработки данных.
Такие механизмы трансформации данных, развитые в различной степени в разных СУБД, помогают в значительной мере сократить объем работ по программированию прикладных систем, функционирующих в среде системы БД.
56. Концепция независимости данных, имеющая важнейшее значение в технологиях БД. С информационной архитектурой системы БД тесно связана концепция независимости данных, имеющая важнейшее значение в технологии БД. Различают логическую и физическую независимость данных.
Обеспечение логической независимости данных означает способность СУБД предоставлять администратору систем БД определенную степень свободы вариации логического представления БД без необходимости соответствующей модификации приложений и пользовательских запросов. В терминах архитектурных моделей ANSI/X3/SPARK это свойство можно рассматривать как возможность вариации концептуальной схемы БД без необходимости изменения внешних схем.
Под физической независимостью данных понимается способность СУБД предоставлять администратору систем БД некоторую свободу модификации способов организации БД в среде хранения, не вызывая необходимости внесения соответствующих изменений в логическое её представление. Благодаря этому можно вносить изменения в организацию хранимых данных, производить настройку систем с целью повышения ее производительности и эффективности использования ресурсов памяти для хранения БД, не затрагивая созданных прикладных программ, использующих БД. В терминах архитектурной модели ANSI/X3/SPARK свойство физической независимости данных можно рассматривать как возможность вариации внутренней схемы БД, без необходимости изменения концептуальной схемы (логической модели БД).
57. Логическая независимость данных. Обеспечение логической независимости данных означает способность СУБД предоставлять администратору систем БД определенную степень свободы вариации логического представления БД без необходимости соответствующей модификации приложений и пользовательских запросов. В терминах архитектурных моделей ANSI/X3/SPARK это свойство можно рассматривать как возможность вариации концептуальной схемы БД без необходимости изменения внешних схем.
58. Физическая независимость данных. Под физической независимостью данных понимается способность СУБД предоставлять администратору систем БД некоторую свободу модификации способов организации БД в среде хранения, не вызывая необходимости внесения соответствующих изменений в логическое её представление. Благодаря этому можно вносить изменения в организацию хранимых данных, производить настройку систем с целью повышения ее производительности и эффективности использования ресурсов памяти для хранения БД, не затрагивая созданных прикладных программ, использующих БД. В терминах архитектурной модели ANSI/X3/SPARK свойство физической независимости данных можно рассматривать как возможность вариации внутренней схемы БД, без необходимости изменения концептуальной схемы (логической модели БД).
59. Нарушение логической целостности БД могут быть связаны не только с вводом в нее недостоверных данных или с неправомерными действиями процедур обработки данных, выполняемых в среде БД и помещающих в БД генерируемые ими данные. Они могут быть следствием несвоевременного прерывания выполнения таких процедур для обработки запроса, выданного другими пользователями. Для исключения таких ситуаций в мультипользовательских СУБД предусматривается механизм транзакций.
Транзакция – совокупность операций манипулирования данными в системе БД, которая обеспечивает обработку пользовательского запроса и переводит БД из одного целостного состояния в другое.
60. Нарушение физической целостности БД возникают в результате сбоев и отказов оборудования ПК, повреждение машинных носителей данных. Развитые СУБД располагают средствами восстановления разрушенной БД, основанными чаще всего на использовании ее контрольных копий и журнализации изменений.
61. В некоторых СУБД предусматриваются механизмы разграничения полномочий доступа (управления доступом) пользователей к БД. Может быть ограничена группа пользователей, которой разрешено обновлять те или иные данные. Обычно средства настройки допускают также изменение структуры хранимых данных (реорганизация базы данных). Кроме того, предусматривается возможность логической реструктуризации БД – т.е. модификации схемы БД с последующим приведением состояния БД в соответствие с новой схемой, а также поддержка службы АБД, ответственного за эксплуатацию БД.
Для управления настройками системы используются ее языковые средства – язык определения данных, связанный с различными архитектурными уровнями системы. Характер и возможности языковых средств СУБД определяются главным образом моделью данных, поддерживаемой этой системой.
62. Организация параллельного доступа пользователей к БД является довольно сложной задачей проблемы, связанные с конкурентным обновлением данных различными пользователями, с возможностью чтения одними пользователями данных, которые лишь частично обновил другой пользователь. Такие проблемы приводили бы к нарушению логической целостности БД. Для этого в СУБД предусматривается техника управления транзакциями.
Для исключения подобных коллизий конкурентного доступа к данным в БД параллельно исполняемых транзакций используют блокировку ресурсов БД, обновляемых при исполнении транзакций. На время исполнения транзакций модифицирующей значения некоторых данных, эти ресурсы блокируются с тем, чтобы не допустить к ним доступ для других транзакций. В различных СУБД используют разные способы блокировки. В одних системах предусматривается автоматическая блокировка ресурсов на время их обновления, в других она должна явно запрашиваться в пользовательских транзакциях. Блокировка может предусматривать монопольное использование ресурса данной транзакцией или допускает его совместное использование с другими транзакциями. Возможны возникновения тупиковых ситуаций (клинч), когда группа из двух или более транзакций производят монопольный захват ресурсов таким образом, что каждая из них ожидает освобождения какого-либо ресурса, монопольно захваченного (блокированного) другой транзакцией из этой группы.
В некоторых СУБД реализованы специальные автоматические механизмы предотвращения тупиковых ситуаций либо механизмы, обеспечивающие выход из тупиковой ситуации за счет отката некоторых из образующих ее транзакций.
63. Ядро СУБД. Утилиты (окружение СУБД). Часто наряду с основной частью системы, называемой ядром, в состав СУБД включают ряд программных компонентов, в том числе программы вспомогательного назначения (утилиты), которые могут исполняться независимо от ядра. Совокупность таких компонентов называется окружением СУБД. Окружение чаще всего включает в себя вспомогательные средства разработки приложений, генераторы отчетов, разнообразные утилиты, поддерживающие деятельность АБД, утилиты создания контрольной копии БД и восстановления БД при разрушениях, автономные средства обмена данными, средства обучения пользователей и персонала.
64. Пользователи и пользовательские интерфейсы. Поддержка информационных ресурсов в системе БД делается для удовлетворения информационных потребностей пользователей. К числу пользователей, прежде всего, относятся конечные пользователи – специалисты в предметной области системы, обычно осуществляющие доступ к информационным ресурсам в интерактивном режиме.
В некоторых системах БД информационные ресурсы предоставляются любому пользователю. В других системах, чтобы стать пользователем, необходимо получить от администратора БД требуемые полномочия доступа к системе, а иногда и полномочия доступа к некоторым ее информационным ресурсам. В ИС предусматриваются пользовательские интерфейсы – средства взаимодействия пользователей с системой. Характер этих интерфейсов и их функции зависят от потребностей и квалификации пользователей, на которых они ориентированы.
Пользовательский интерфейс включает интерфейсные технические средства, языки интерфейса, программные средства, поддерживающие работу интерфейсного оборудования и поддержку языков интерфейса.
Иногда потребности пользователей зависят, от каких-либо параметров – даты, названия продукта, фамилии какого-либо лица. Таких пользователей удовлетворяет кнопочный интерфейс.
Таким запросам соответствует система меню. От одного меню переходим к подменю. После нескольких альтернатив, показываемых на экране, получаем выдачу интересующих данных.
65. Языки конечных пользователей. В большинстве случаев информационные потребности конечных пользователей имеют более сложный, нерегламентированный характер. Поэтому интерфейс конечного пользователя в системе с такими потребностями должен включать язык запросов.
Для взаимодействия конечных пользователей с системой БД с помощью языков запросов служат два вида пользовательских интерфейсов
- интерфейс командной строки
- интерфейсы, основанные на языках 4-ого поколения
В первом случае для ввода сообщений и команд в систему используются непосредственно операторы языка запросов, обладающим своим алфавитом и синтаксическими правилами для конструирования команд. В качестве языков запросов используются процедурные и декларативные языки.
Средствами процедурных языков пользователь описывает, каким образом система может выдать ему данные. Декларативные языки позволяют описать какие данные требуются, оставляя самой системе возможность построения эффективного алгоритмах получения на основе содержимого БД. В современных СУБД чаще используют декларативные языки.
Языки 4-го поколения не являются языками в привычном смысле. Это пользовательские интерфейсы, которые обеспечивают ввод в систему сообщений с помощью выбора подходящих альтернатив в меню, ввод параметров через окна экранных форм, использования различных возможностей графического пользовательского интерфейса. Термин «язык 4-го поколения» был предложен американским специалистом по системам обработки данных Джоржем Мартином (J. Martin).
66. Какие два типа пользователей существуют для доступа к БД? Доступ пользователей к ресурсам системы возможен только в пределах предоставляемых им полномочий, которые обычно проверяются системными механизмами при доступе. Наделяет полномочиями пользователей служба АБД системы. Пользователями системы могут быть не только конечные пользователи, но и приложения (прикладные программы). Приложения используют для доступа к БД интерфейсы прикладного программирования (API) СУБД. Средства таких интерфейсов можно применять только в программах, создаваемых с помощью языков программирования таких как С++, Smalltalk, Java и др. В прикладной программе используются операторы языка запросов (макрокоманды) или языка манипулирования данными СУБД. Эти операторы, конечно же, являются инородными конструкциями для языка программирования, на котором написана прикладная программа. Для реляционных СУБД разработаны стандарты, например, ODBC (Open Data Base Connectivity), которые могут использоваться в различных языках программирования, JDBC (Java DBC), SQLJ (SQL-Java Binding), предназначенные для программ на языке Java. SQL – международный стандарт. SQLJ – индустриальный стандарт, который стал основой компонентов нового международного стандарта языка SQL, называемого SQL-2003.
67. Модель данных. Основу механизмов управления данными любой СУБД составляет некоторая модель данных. Так называется инструмент моделирования предметной области, позволяющий отображать ее состояние и динамику в среде БД, управляемой системой. Более точно, модель данных – это совокупность правил структурирования данных в БД, допустимых операций над ними и ограничений целостности, которым эти данные должны удовлетворять. Если некоторая модель данных реализуется механизмами управления данными определенной СУБД, то говорят, что эта СУБД поддерживает указанную модель данных. СУБД может поддерживать несколько моделей данных. Такую систему называют мультимедийной. Прежде всего, модель данных представляет собой средство выражения модели предметной области в среде системы БД. Поэтому можно рассматривать модель данных как метамодель для описания различных предметных областей в среде выбранной СУБД.
Однако, для разработчика и пользователей СУБД единственно конструктивной является «материализация» модели данных в форме полной спецификации воплощающей ее языковые средства – языка определения данных и языка манипулирования данными.
68. Что определяет модель данных, кроме структурных и операционных возможностей? Модель данных определяет не только структурные и операционные возможности моделирования данных, но и виды допустимых ограничений целостности данных (логические ограничения). Эти ограничения дают возможность СУБД следить за тем, чтобы в базе данных содержались только допустимые значения данных и между ними поддерживались только допустимые связи. В современном понимании модель данных – это не результат, а инструмент моделирования предметной области.
В процессе эволюции технологий БД было создано значительное количество разнообразных моделей данных. Разрабатываются сейчас и будут разрабатываться в дальнейшем новые модели. Такая ситуация является следствием реальных потребностей практики обработки данных. В каждом случае разработки системы БД нужно иметь возможности выбора способа видения предметной области, адекватного потребностям пользователей.
69. Какие известны ранние модели данных, как называются и чем они характерны? Ранние модели данных называются графовыми моделями. Они представляют собой инструменты для создания и использования различных разновидностей БД сетевой и иерархической структуры данных. Классическими представителями таких моделей являются – сетевая модель данных CODASYL (IDMS) и иерархическая модель данных СУБД IMS компании IBM.
Хотя в настоящее время в большинстве коммерческих СУБД используются реляционные, объектные и объектно-реляционные модели данных, до сих пор эксплуатируется значительное количество установок СУБД, основанных на графовых моделях.
70. Реляционная модель данных была предложена в 1969г. Э. Коддом, сотрудником исследовательского центра компании IBM в Сан-Хосе (Калифорния). Она получила название базовой реляционной модели и стала основой коммерческих реляционных СУБД.
Эта модель основана на математическом понятии отношения (от англ. relation). Операционные возможности модели имеют две эквивалентные формы, одна из которых – реляционная алгебра (Булева алгебра), другая – реляционное исчисление. Это позволило сформировать развитую математическую теорию реляционных моделей данных. СУБД, поддерживающие реляционную модель заняли доминирующее положение среди инструментальных средств разработки систем БД.
В соответствии с реляционной моделью данных база данных (БД) представляется в виде совокупности таблиц, над которыми могут выполняться операции, формулируемые в терминах реляционной алгебры или реляционного исчисления. В реляционной модели операции над объектами БД имеют теоретико-множественных характер. Каждая операция манипулирования данными в такой модели обрабатывает множество строк таблицы. Это дает возможность пользователям формулировать их запросы более компактно, в терминах более крупных конструкций данных.
Однако такой подход порождает и сложные проблемы, связанные с обеспечением достаточно высокого уровня производительности СУБД этого класса, которые приходится решать разработчикам таких СУБД.
Другая проблема возникает, когда нужно обеспечить интерфейс СУБД, поддерживающей реляционную модель данных, с программами на традиционных языках программирования. Она заключается в несоответствии структур данных модели и языков программирования, ориентированных на «позаписную» обработку. Для ее решения пришлось дополнить реляционную модель данных специальной согласующей конструкцией данных, называемой курсором. Курсор – это временная таблица, содержащая результаты обработки запроса. Прикладная программа может последовательно просматривать строки такой таблицы (курсора) и обрабатывать их индивидуально.
Характерной чертой графовых и реляционных моделей данных является подход к данным как к самостоятельно существующим абстрактным объектам.
71. Объектная модель данных. Еще в середине 1970-х годов начали проводиться исследования и разработки моделей данных нового типа, призванных решить задачу семантики предметной области. Такие модели данных стали называться семантическими. В их создании приняли участи многие крупные научные центры, как у нас, так и за рубежом. Тем не менее, семантические модели данных не стали основой создания коммерческих СУБД для широкого использования.
В конце 1980-х годов успехи объектно-ориентированного программирования стимулировали разработки СУБД, основанных на объектной модели данных. В отличие от реляционных систем среди разработчиков объектных СУБД в течение значительного времени не существовало единодушия конкретного воплощения объектной модели данных. Многочисленные разновидности объектной модели данных получили широкое распространение в области программирования БД и информационных систем. Популярность объектного подхода в области баз данных в значительной мере объясняется предоставляемыми им более естественными возможностями моделирования предметной области, чем при использовании графовых моделей данных и реляционной модели данных.
В объектных моделях предусматривается отношение наследования между типами объектов. Подтип наследует атрибуты состояния и операции своего типа.
На основе объектных моделей в конце 1980-90 годов возникла новая категория СУБД, называемых объектными СУБД.
Основным понятием объектных моделей данных является объект. При этом объект понимается как сущность, обладающая состоянием и поведением. Состояние объекта определяется совокупностью его атрибутов, которые могут принимать значения предписанных типов. Поведение объекта, в свою очередь, определяется совокупностью операций, специфицированных для этого объекта.
Объекты в объектных моделях типизируются. Свойства типа объектов (атрибуты и операции) применяются ко всем его экземплярам. Поддерживаются связи между типами объектов. Были разработаны технологии неоднородных распределенных объектных систем, новые методологии объектного анализа и проектирования сложных программных и информационных систем. Для объектных СУБД актуальной стала проблема стандартизации. Эта проблема была решена в 1993 году рабочей группой ODMG, которая разработала стандарт объектных баз данных (ODMG-93). Действующий в настоящее время стандарт был одобрен международным консорциумом в 2000 г. Объектные СУБД стали широко применяться во многих крупных проектах информационных систем. Эта среда включает объектные технологии языка Java для создания неоднородных распределенных объектных сред и компонентную модель консорциума ODMG. Немаловажное значение имеет также возможность интегрировать объектные технологии в среду Веб.
72. Объектно–реляционная модель данных. Это гибридная модель данных, сочетающая возможности реляционной модели с поддержкой объектных свойств данных. Такие модели стали использоваться как паллиатив, обеспечивающий преодоление ограниченных возможностей реляционной модели, которые препятствовали эффективной реализации многих приложений:
-слабая система типов данных;
-сложности интеграции в новые технологические среды, которые основаны, главным образом, на объектных моделях.
В настоящее время в большинстве коммерческих СУБД используются реляционные, объектные и объектно-реляционные модели данных. Объектно-реляционный подход в технологиях баз данных получил основательную поддержку благодаря принятой в 1999 году очередной версии международного стандарта языка SQL (SQL-1999). В этом стандарте воплощен некоторый вариант объектно-реляционной модели данных, обеспечивающий преемственность для реляционной модели, поддерживаемой ранними версиями языка SQL.
73. Сетевая модель данных. Это модель данных, относящаяся к категории графовых моделей. Основные элементы структуры сетевой БД CODASYL – это тип записи и тип набора. Тип записи определяет множество записей (экземпляров записей) БД, обладающих структурой и другими свойствами, специфицированными в описании данного типа записей в схеме базы данных.
Тип набора CODASYL представляет собой множество наборов, обладающих структурой и другими свойствами, определенными в схеме БД для этого типа набора. Все экземпляры записей одного набора соединяются указателями в цепной список. Указатели обеспечивают обход всех записей в прямом и обратном направлении. В сетевой модели данных CODASYL были разработаны языки манипулирования данными для языков программирования Кобол и Фортран.
На основе модели данных CODASYL был создан ряд широко распространенных коммерческих СУБД. В 1968 году была создана международная Рабочая группа по БД CODASYL, где был представлен полный комплекс языковых средств описания данных и манипулирования данными. В документах CODASYL были впервые систематизированы и сформулированы некоторые фундаментальные концепции технологии БД. Была впервые предложена концепция многоуровневой архитектуры СУБД. Процедуры БД CODASYL стали средством создания активных БД задолго до того, как в языке SQL была предложена аналогичная концепция триггера.
74. Иерархическая модель данных. Представителем этой модели данных является СУБД IMS компании IBM Corp. Система IMS эксплуатируется до настоящего времени на платформах мейнфреймов, выпускаемых той же компанией IBM. Иерархическая модель данных является хрестоматийной разновидностью графовой модели данных. Вершинам деревьев соответствуют сегменты некоторых типов. Сегменты представляют собой записи, состоящие из простых элементов данных различных типов.
Экземпляр сегмента каждого типа идентифицируется уникальным значением ключа, определенного для сегментов этого типа. БД представляет собой совокупность таких деревьев. Наряду с навигационными операциями поддерживаются операции манипулирования данными – вставка, обновление и удаление сегментов с естественным каскадным распространением операции удаления.
75. Многомерные модели данных. Такие модели данных стали основой инструментальных средств поддержки принятия решений. Они оперируют многомерными представлениями данных (в виде гиперкуба). Различные разновидности многомерной модели стали широко использоваться в корпоративных системах баз данных. В середине 1990-х годов в связи с развитием технологий интерактивной аналитической обработки данных (OLAP).
Основные понятия многомерной модели данных – измерение и ячейка. Каждое измерение представляет собой множество однородных значений данных, образующее грань гиперкуба. Обычно значениями измерений являются признаковые данные. Примерами измерений являются годы, месяцы, кварталы, регионы, города, районы, названия предприятий, виды продукции и т.п. Измерения играют роль индексов, совокупности значений которых идентифицируют в гиперкубе конкретные его ячейки, или осей координат в многомерной системе координат гиперкуба. Ячейки (называемые также показателями) представляют собой числовые величины – литералы, переменные или формулы.
Операционные возможности многомерных моделей данных ориентированы на поддержку анализа данных. Предусматривается конструирование разнообразных агрегаций данных в рамках заданного гиперкуба, построение различных его проекций – подмножеств гиперкуба, полученных путем фиксации значений других измерений, детализация (дезагрегация) данных и вращение (изменение порядка измерений) гиперкуба, а также ряд других операций.
76. Основы проектирования БД – это одна из наиболее ответственных и трудных задач, связанных с созданием системы базы данных. В результате ее решения должны быть определены и содержание БД, и эффективный, с точки зрения всего сообщества будущих пользователей, способ ее организации в среде СУБД, выбранной для ИС.
В крупных системах проектирование БД требует особой тщательности, поскольку цена допущенных на этой стадии просчетов и ошибок особенно велика в дальнейшем.
Проектирование БД не может быть полностью автоматизированным. Значительное место в нем отводится интуиции и опыту специалиста-проектировщика.
Сформировался рынок коммерческих программных инструментальных средств, на котором представлен широкий спектр таких инструментов. Они предназначены для создания и поддержания разрабатываемых систем на протяжении всего их жизненного цикла, т.е. периоде от принятия решения о создании системы до снятия ее с эксплуатации, либо только для поддержки отдельных этапов. Эти инструменты CASE-технологий базируются на различных разновидностях структурных или объектно-ориентированных методов.
Существуют программные продукты CASE-технологий, которые поддерживают проектирование баз данных и разработку программного кода приложений. Некоторые из этих программных продуктов ориентированы на довольно широкий набор СУБД. Другие предназначены для конкретных СУБД.
Это позволяет использовать автоматизированные средства для реинжиниринга системы – ее модернизации в процессе разработки и эксплуатации с учетом изменившихся требований.
77. Этапы проектирования БД и концептуальное проектирование. Процесс проектирования БД должен включать следующие этапы:
- концептуальное проектирование БД;
- выбор СУБД и других инструментальных средств реализации системы;
- логическое проектирование БД;
- физическое проектирование БД.
Проектирование БД не может быть полностью автоматизированным. Значительное место в нем отводится интуиции и опыту специалиста-проектировщика.
Сформировался рынок коммерческих программных инструментальных средств, на котором представлен широкий спектр таких инструментов. Они предназначены для создания и поддержания разрабатываемых систем на протяжении всего их жизненного цикла, т.е. периоде от принятия решения о создании системы до снятия ее с эксплуатации, либо только для поддержки отдельных этапов. Эти инструменты CASE-технологий базируются на различных разновидностях структурных или объектно-ориентированных методов.
Существуют программные продукты CASE-технологий, которые поддерживают проектирование баз данных и разработку программного кода приложений. Некоторые из этих программных продуктов ориентированы на довольно широкий набор СУБД. Другие предназначены для конкретных СУБД.
Первой задачей этапа концептуального проектирования является определение предметной области системы, основанное на изучении информационных потребностей будущих пользователей. На практике встречаются в основном два подхода к выбору состава и структуры предметной области.
1. Наиболее распространен подход, который можно назвать функциональным. Он реализует принцип «от задач» и применяется в случае, когда заранее известны функции некоторой группы лиц и/или комплекса задач, для обслуживания информационных потребностей которых создается рассматриваемая БД.
2. При другом, предметном подходе информационные потребности будущих пользователей жестко не фиксированы. Они могут быть многоаспектными и весьма динамичными. В предметную область включают при этом такие сущности и взаимосвязи сущностей, которые наиболее значимы и наиболее характерны для нее. Концептуальная модель предметной области представляет собой описание структуры и динамики предметной области, характера информационных потребностей пользователей системы в терминах, понятных пользователю и независимых от программной реализации системы, и от средств языков какой-либо конкретной СУБД. В простейших случаях проектировщик БД ограничивается содержательным описанием модели предметной области на естественном языке.
Разработчик может использовать также разнообразные выразительные средства для изображения структуры предметной области, такие, как диаграммы типов, графы, вершины которых соответствуют типам сущностей, а ребра – типам связей между ними.
78. Выбор СУБД. Выбор СУБД является важным этапом проектирования БД. Проблема выбора СУБД, а также оценки характеристик их функционирования злободневны на всех стадиях развития технологий, когда речь идет о требованиях к производительности, ресурсам памяти, надежности. В наиболее критических случаях производится сравнительный анализ характеристик различных СУБД.
Оценка производительности СУБД для некоторых типов приложений может выполняться с помощью эталонных тестов, разработанных консорциумом TCP (Transaction Processing Performance Council).
Проектировщики очень часто руководствуются лишь собственными интуитивными экспертными оценками требований к выбираемой системе по нескольким важнейшим количественным и качественным характеристикам. К числу таких характеристик относятся:
- тип модели данных, которую поддерживает данная СУБД, ее адекватность потребностям рассматриваемой предметной области;
- масштабы разрабатываемой системы – количество пользователей, объем данных, интенсивность потока запросов;
- аппаратно-программная платформа;
- характеристики производительности системы;
- наличие в данной СУБД средств разработки приложений;
- запас функциональных возможностей для дальнейшего развития системы;
- степень оснащенности системы инструментарием для АБД;
- удобство и надежность СУБД в эксплуатации.
79. Этап логического проектирования БД состоит в отображении концептуальной модели предметной области в модель данных, поддерживаемую СУБД, выбранной для реализации системы. В результате выполнения этого этапа создаются схемы БД концептуального и внешнего уровней архитектуры, специфицированные на языках описания данных конкретной СУБД.
Этап физического проектирования БД требует поиска проектных решений, обеспечивающих эффективную поддержку построенной «логической» структуры БД в среде хранения. В ряде современных реляционных БД организация хранения данных в значительной степени определяется по умолчанию на основе концептуальной схемы БД.
80. Языки 4-го поколения. Иногда потребности пользователей зависят, от каких-либо параметров – даты, названия продукта, фамилии какого-либо лица. Таких пользователей удовлетворяет кнопочный интерфейс.
Таким запросам соответствует система меню. От одного меню переходим к подменю. После нескольких альтернатив, показываемых на экране, получаем выдачу интересующих данных.
В большинстве случаев информационные потребности конечных пользователей имеют более сложный, нерегламентированный характер. Поэтому интерфейс конечного пользователя в системе с такими потребностями должен включать язык запросов.
Для взаимодействия конечных пользователей с системой БД с помощью языков запросов служат два вида пользовательских интерфейсов
- интерфейс командной строки
- интерфейсы, основанные на языках 4-ого поколения
В первом случае для ввода сообщений и команд в систему используются непосредственно операторы языка запросов, обладающим своим алфавитом и синтаксическими правилами для конструирования команд. В качестве языков запросов используются процедурные и декларативные языки.
Средствами процедурных языков пользователь описывает, каким образом система может выдать ему данные. Декларативные языки позволяют описать какие данные требуются, оставляя самой системе возможность построения эффективного алгоритма получения на основе содержимого БД. В современных СУБД чаще используют декларативные языки.
Языки 4-го поколения не являются языками в привычном смысле. Это пользовательские интерфейсы, которые обеспечивают ввод в систему сообщений с помощью выбора подходящих альтернатив в меню, ввод параметров через окна экранных форм, использования различных возможностей графического пользовательского интерфейса. Термин «язык 4-го поколения» был предложен американским специалистом по системам обработки данных Джоржем Мартином (J. Martin).
Доступ пользователей к ресурсам системы возможен только в пределах предоставляемых им полномочий, которые обычно проверяются системными механизмами при доступе. Наделяет полномочиями пользователей служба АБД системы.
81. Сколько и какие этапы включает процесс проектирования БД. Для понимания принципов функционирования систем баз данных необходимо рассмотреть архитектурные особенности такой системы. Следует принимать во внимание, что архитектура систем БД, их пространственную и информационную архитектуру. Свойства пространственной и информационной архитектуры поддерживаются средствами функциональной архитектуры системы.
Информационная архитектура системы БД характеризует поддерживаемые в системе представления информационных ресурсов, их свойства и взаимосвязи. Три этапа включает процесс проектирования БД. Концепции многоуровневой архитектуры стали основой современной технологии БД. Была предложена обобщенная трехуровневая модель информационной архитектуры системы БД, включающая концептуальный, внутренний и внешний уровни. Такая модель описывает архитектуру любой системы с той лишь оговоркой, что кое-какие ее компоненты или функции в конкретной СУБД могут иметь вырожденный характер. Концептуальный уровень архитектуры служит для поддержки единого взгляда на базу данных, общего для всех ее приложений. Именно в среду концептуального уровня при проектировании БД отображается модель предметной области системы.
Механизмы СУБД, поддерживающие внутренний уровень архитектуры, служат для поддержки представления БД в среде хранения. Это единственный уровень информационной архитектуры, где БД в действительности представлена полностью в «материализованном» виде. Описание представления БД на внутреннем уровне архитектуры называется внутренней схемой или схемой хранения.
Наконец, пользователи БД имеют дело с представлениями БД на внешнем уровне, с так называемыми внешними базами данных. Описания таких представлений называются внешними схемами. В системе БД может одновременно поддерживаться несколько внешних схем для различных групп пользователей или приложений.
Поскольку все уровни модели информационной архитектуры должны отражать разные точки зрения на одну и туже единственную БД, материализованную в среде хранения на МД, необходимо в составе функциональной архитектуры СУБД иметь такие механизмы, которые обеспечивали бы соответствие между представлениями БД на разных уровнях информационной архитектуры системы. В архитектурной модели для этих целей служат механизмы междууровневого отображения данных «внешний - концептуальный» и «концептуальный - внутренний». Именно функциональные возможности этих механизмов обеспечивают абстракцию данных в системе, определяют ту степень свободы, которая предоставляется на связанных ими уровнях для выбора представления БД, и, тем самым, достижимую в системе степень независимости данных.
Такая архитектурная модель является универсальной в том смысле, что в ее рамки укладывается информационная архитектура любой системы БД. Различия архитектуры конкретных систем определяются лишь тем, какие модели данных поддерживаются на архитектурных уровнях используемых в них СУБД, какими возможностями обладают их механизмы междууровневого отображения данных, являются ли управляемыми механизмы их уровней и механизмы междууровневого отображения данных.
82. Какие технологии существуют, которые поддерживают проектирование БД и разработку программного кода приложений ИС? Проектирование БД – это одна из наиболее ответственных и трудных задач, связанных с созданием системы базы данных. В результате ее решения должны быть определены и содержание БД, и эффективный, с точки зрения всего сообщества будущих пользователей, способ ее организации в среде СУБД, выбранной для ИС.
В крупных системах проектирование БД требует особой тщательности, поскольку цена допущенных на этой стадии просчетов и ошибок особенно велика.
Проектирование БД не может быть полностью автоматизированным. Значительное место в нем отводится интуиции и опыту специалиста-проектировщика.
Сформировался рынок коммерческих программных инструментальных средств, на котором представлен широкий спектр таких инструментов. Они предназначены для создания и поддержания разрабатываемых систем на протяжении всего их жизненного цикла, т.е. периоде от принятия решения о создании системы до снятия ее с эксплуатации, либо только для поддержки отдельных этапов. Эти инструменты CASE-технологий базируются на различных разновидностях структурных или объектно-ориентированных методов.
Существуют программные продукты CASE-технологий, которые поддерживают проектирование баз данных и разработку программного кода приложений. Некоторые из этих программных продуктов ориентированы на довольно широкий набор СУБД. Другие предназначены для конкретных СУБД.
Важное достоинство использования CASE-технологий в том, что в процессе разработки системы осуществляется автоматическое документирование проекта.
- Что называют метаданными в ИС? На этапе концептуального проектирования разработчики системы создают логическую модель БД, т.е. описание свойств различных объектов системы (тип данных, размер поля, связи с другими объектами и пр.), которые называют метаданными, а сами данные располагаются на физическом уровне.
84. Что называют реинжинирингом ИС. Важное достоинство использования CASE-технологий в том, что в процессе разработки системы осуществляется автоматическое документирование проекта. Это позволяет использовать автоматизированные средства для реинжиниринга системы – ее модернизации в процессе эксплуатации с учетом изменившихся требований.
85. Какими важнейшими характеристиками должны обладать СУБД для разработки информационной системы? Выбор СУБД является важным этапом проектирования БД. Проблема выбора СУБД, а также оценки характеристик их функционирования злободневны на всех стадиях развития технологий БД, когда речь идет о требованиях к производительности, ресурсам памяти, надежности. В наиболее критических случаях производится сравнительный анализ характеристик различных СУБД.
Оценка производительности СУБД для некоторых типов приложений может выполняться с помощью эталонных тестов, разработанных консорциумом TCP (Transaction Processing Performance Council).
Проектировщики очень часто руководствуются лишь собственными интуитивными экспертными оценками требований к выбираемой системе по нескольким важнейшим количественным и качественным характеристикам. К числу таких характеристик относятся:
- тип модели данных, которую поддерживает данная СУБД, ее адекватность потребностям рассматриваемой предметной области;
- масштабы разрабатываемой системы – количество пользователей, объем данных, интенсивность потока запросов;
- аппаратно-программная платформа;
- характеристики производительности системы;
- наличие в данной СУБД средств разработки приложений;
- запас функциональных возможностей для дальнейшего развития системы;
- степень оснащенности системы инструментарием для АБД;
- удобство и надежность СУБД в эксплуатации.
86. В чём заключается основная цель логического проектирования БД? Этап логического проектирования БД состоит в отображении концептуальной модели предметной области в модель данных, поддерживаемую СУБД, выбранной для реализации системы. В результате выполнения этого этапа создаются схемы БД концептуального и внешнего уровней архитектуры, специфицированные на языках описания данных конкретной СУБД.
87. Что является главной задачей физического проектирования БД? Этап физического проектирования БД требует поиска проектных решений, обеспечивающих эффективную поддержку построенной «логической» структуры БД в среде хранения. В ряде современных реляционных БД организация хранения данных в значительной степени определяется по умолчанию на основе концептуальной схемы БД.
88. Архитектура систем БД. Три уровня информационной архитектуры систем БД. Для понимания принципов функционирования систем баз данных необходимо рассмотреть архитектурные особенности такой системы. Следует принимать во внимание, что архитектура систем БД, их пространственную и информационную архитектуру. Свойства пространственной и информационной архитектуры поддерживаются средствами функциональной архитектуры системы.
Информационная архитектура системы БД характеризует поддерживаемые в системе представления информационных ресурсов, их свойства и взаимосвязи. Концепции многоуровневой архитектуры стали основой современной технологии БД. Была предложена обобщенная трехуровневая модель информационной архитектуры системы БД, включающая концептуальный, внутренний и внешний уровни. Такая модель описывает архитектуру любой системы с той лишь оговоркой, что кое-какие ее компоненты или функции в конкретной СУБД могут иметь вырожденный характер.
89. Для чего служит Концептуальный уровень БД? Концептуальный уровень архитектуры служит для поддержки единого взгляда на базу данных, общего для всех ее приложений. Именно в среду концептуального уровня при проектировании БД отображается модель предметной области системы.
90. Для чего служат механизмы СУБД, поддерживающие внутренний уровень архитектуры? Механизмы СУБД, поддерживающие внутренний уровень архитектуры, служат для поддержки представления БД в среде хранения. Это единственный уровень информационной архитектуры, где БД в действительности представлена полностью в «материализованном» виде. Описание представления БД на внутреннем уровне архитектуры называется внутренней схемой или схемой хранения.
Поскольку все уровни модели информационной архитектуры должны отражать разные точки зрения на одну и туже единственную БД, материализованную в среде хранения на МД, необходимо в составе функциональной архитектуры СУБД иметь такие механизмы, которые обеспечивали бы соответствие между представлениями БД на разных уровнях информационной архитектуры системы. В архитектурной модели для этих целей служат механизмы междууровневого отображения данных «внешний - концептуальный» и «концептуальный - внутренний». Именно функциональные возможности этих механизмов обеспечивают абстракцию данных в системе, определяют ту степень свободы, которая предоставляется на связанных ими уровнях для выбора представления БД, и, тем самым, достижимую в системе степень независимости данных.
91. Что такое внешние БД и что обозначают внешние схемы? Пользователи БД имеют дело с представлениями БД на внешнем уровне, с так называемыми внешними базами данных. Описания таких представлений называются внешними схемами. В системе БД может одновременно поддерживаться несколько внешних схем для различных групп пользователей или приложений. Такая архитектурная модель является универсальной в том смысле, что в ее рамки укладывается информационная архитектура любой системы БД. Различия архитектуры конкретных систем определяются лишь тем, какие модели данных поддерживаются на архитектурных уровнях используемых в них СУБД, какими возможностями обладают их механизмы междууровневого отображения данных, являются ли управляемыми механизмы их уровней и механизмы междууровневого отображения данных.
92. Какими ресурсами управляет внутренний уровень архитектуры БД?
Важным функциональным компонентом СУБД являются механизмы внутреннего уровня информационной архитектуры системы, реализующие функции среды хранения БД. БД в действительности представлена полностью в «материализованном» виде только в среде хранения. На всех остальных уровнях архитектуры системы имеются «метаданные».
Механизмы среды хранения БД в СУБД служат для управления двумя группами ресурсов системы – это ресурсами хранимых данных и ресурсами пространства памяти среды хранения.
Механизмы среды хранения должны выполнять целый ряд операций:
- определение места размещения новых данных в пространстве памяти на МД;
- выделение необходимого ресурса памяти и запоминание адресов;
- формирование и разрушение связей с другими данными;
- удаление хранимых данных с освобождением занимаемой ими памяти;
- поиск данных в пространстве памяти по заданным их атрибутам или по «адресу»;
- выборка хранимых данных для обработки.
Все указанные операции выполняются по запросам механизмов концептуального уровня данной СУБД. Многоуровневый подход к архитектуре СУБД предлагает независимость организации среды хранения данных от модели данных концептуального уровня – т.е. физическую независимость данных.
Нужно учитывать, что ряд объектов среды хранения данных СУБД поддерживаются файловой системой (ОС), в обстановке которой работает данная СУБД. И хотя среда хранения БД должна располагать более тонкими механизмами, чем файловая система, специфика файловой системы также оказывает на ее организацию значительное влияние. Пример глубоко проработанной концепции управления средой хранения БД представляет собой язык определения хранимых данных разработанный CODASYL. Если запись концептуального уровня разбивается в среде хранения на несколько частей, то ее фрагмент представляется экземплярами хранимых записей каких-либо типов. Все они связываются указателями или размещаются по специальному закону так, чтобы механизмы междууровневого отображения данных могли опознать все компоненты и осуществить сборку полной записи по запросу механизмов концептуального уровня.
Каждой хранимой записи в пространстве памяти ставится в соответствие ее адрес, определяющий место размещения записи. Существуют два вида адресации хранимых записей – прямая (непосредственная) и косвенная.
Прямая адресация предусматривает указание непосредственного местоположения записи в пространстве памяти, т.е. адрес. Прямая адресация не позволяет, однако, перемещать записи внутри области хранения без изменения их непосредственного адреса. Такие изменения привели бы к необходимости коррекции различных указателей на записи в среде хранения, что было бы чрезвычайно трудоемкой процедурой, поэтому перемещать записи при прямой адресации нецелесообразно. Подобная ситуация особенно часто возникает при работе с записями переменной длины. Для преодоления указанных трудностей применяется другой вид адресации – косвенная адресация.