ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 17.03.2024
Просмотров: 116
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Квантор существования.
Квантор – обозначает количество чего-либо.
Квантор существования означает, что существует хотя бы один экземпляр определенного типа вещей. В реляционном исчислении квантор существования используется для задания условия того, что определенный тип строк в отношении существует.
В реляционной алгебре для выполнения этого запроса требуется соединение. Таким образом, квантор существования используется в реляционном исчислении, для того чтобы выполнять функцию соединения.
Квантор всеобщности.
Квантор всеобщности означает, что некоторое условие применяется ко всем строкам или к каждой строке некоторого типа.
Он используется в тех же целях, что и операция деления реляционной алгебры. Проиллюстрируем его применение тем же запросом, который рассматривался в разделе, описывающем операцию деления.
Различные представления о данных в базах данных
Различные представления о данных в базах данных
Проектирование и создание базы данных предполагает объединение данных, предназначенных для решения нескольких прикладных задач для множества разных пользователей. Соответственно, при объединении данных должны учитываться требования к данным каждого из пользователей, основанные на их представлении о данных и связях между ними. Эти требования должны обобщаться в единое представление, которое и будет служить основой для построения единой базы данных (Рис. 4.1).
Обобщение представлений всех пользователей о данных называется концептуальной моделью (схемой) базы данных. Концептуальная модель представляет информационное описание предметной области с учетом логических взаимосвязей, поэтому ее еще называют инфологической (информационно-логической) моделью. Если в модели отсутствуют какие-либо понятия, связанные с компьютерными технологиями, запоминающими устройствами, способами размещения данных в запоминающих устройствах, то это будет модель только предметной области.
Рисунок 4.1. –
Обобщение представления пользователей о данных
Для проектирования и создания базы данных и работы с ней пользователями используются системы управления базами данных. Каждая конкретная система управления базой данных поддерживает определенный вид данных, в соответствии с форматами записей и отношений между ними. При этом, она называемый моделью данных системы управления базой данных.
В следующем этапе разработки и проектирования базы данных предполагается выбор представления концептуальной модели с помощью модели данных конкретной системы управления базой данных. Таким образом полученное представление концептуальной модели называется логической моделью базы данных. Иначе говоря, логическая модель – это концептуальная схема, специфицированная в языке конкретной системы управления базой данных. Логическая модель представляет данные и элементы данных не зависимо от их содержания и среды хранения. Далее, при проектировании и создании базы данных разработчик системы средствами и инструментами системы управления базой данных отображает полученную логическую модель базы данных в память вычислительного устройства (компьютера) и определяет методы доступа к ней. Полученное представлениеданных в запоминающем устройстве компьютера называется внутренним представлением или структурой хранения. Прикладные программы или приложения работают с логической моделью, причем каждому пользователю представляется подмножество этой логической модели (подсхема), отражающее его представление о конкретной предметной области. Каждая прикладная программа работает только с теми данными, которые необходимы именно ей.
Соответствующее восприятие или как ранее применялось «видение» ограниченного количества данных и работа только с ними прикладными программами (пользователями) представляет собой внешние представления. Взаимосвязь вышеуказанных моделей изображена на рисунке 4.2.
Рисунок 4.2 – Различные представления о данных в базе данных
На данной схеме выделены три различных уровня описания данных (внешний, концептуальный, внутренний). Эти уровни формируют так называемую трехуровневую архитектуру ANSI/SPARC, предложенную в 1975 году. Комитетом планирования стандартов и норм SPARC (Standards Planning and Requirements Committee
) Национального института стандартизации США (American National Standards Institute – ANSI). Целью данной архитектуры является отделение пользовательского представления о данных в базе данных от их физического представления. Использование таких представлений о данных позволяет обеспечить выполнение основного требования к базе данных, которым является независимость программ и данных. При изменении прикладных программ может измениться соответствующее внешнее представление, но логическая модель данных не изменяется и, соответственно, не будут изменяться другие прикладные программы. При изменении внутреннего представления (структур хранения) логическая модель не изменяется, соответственно, не изменяются прикладные программы.
Это требование рассматривалось, когда мы говорили о функциях систем управления базами данных.
Соответствующие представления позволяют четко разграничить полномочия различных пользователей, работающих непосредственно с базой данных.
Эти представления позволяют описать упомянутое выше «видение» базы данных разными пользователями, работающими с ней как различные уровни представления и моделирования:
внешнее представление – представление специалиста предметной области (пользователя);
внешнее представление и логическая модель – представление прикладного программиста, разрабатывающего конкретное приложение для пользователя;
логическая модель и внутреннее представление – представление системного программиста, администрирующего базу данных.
Уровни представления баз данных
Говоря о системе управления базой данных как о сложном программном продукте, прежде всего, необходимо четко обусловить главную концепцию системы, определяющую все последующие этапы ее разработки.
Основные положения концепции разработка систему управления базой данных:
архитектура системы управления базой данных должна обеспечивать, в первую очередь, разграничение системного и пользовательского уровней;
необходимо дать возможность каждому пользователю иметь свое, отличное от других представление о свойствах хранимой информации.
Проектирования любой конкретной информационной системы, в начальной стадии, должно являться абстрактные описания информационных потребностей каждой группы пользователей, на основе которых уже генерируется также абстрактное, но уже общее для всей организации описание структур хранимых данных. Система управления базой данных, посредством которой эта информационная система будет создаваться и поддерживаться, должна иметь для этого соответствующие возможности.
Рассмотрим архитектурные решения построения системы управления базой данных и ее функциональные характеристики, а также типовые организации современных систем управления базами данных, позволяющие воплотить эти решения и характеристики в эффективный программный продукт с точки зрения уровне представления баз данных.
Трехуровневая архитектура базы данных
Важнейшим аспектом развития систем управления базами данных стала концепция отделения логической структуры базы данных и манипуляций данными, необходимых пользователям, от физического представления, требуемого компьютерным оборудованием. Данная концепция должна быть заложена в базис, на котором будет строиться вся надстройка информационной системы.
Рассмотрим архитектуру базы данных, которая уже четверть века официально признана и с достаточной точностью описывает большинство существующих информационных систем. Очевидно, что современный рынок программных продуктов не предлагает только системы, строго следующие этой архитектуре как единственно возможной. Рассматривая конкретные информационные системы управления данными, можно заметить отсутствие поддержки некоторых аспектов данной представленных в традиционных архитектурах.
Одна и та же база данных в зависимости от точки зрения может иметь различные уровни описания.
По числу уровней описания данных, поддерживаемых системой управления базой данных, различают:
одноуровневые системы;
двухуровневые системы;
трехуровневые системы.
В наше время уже чаще всего поддерживается трехуровневая архитектура описания базы данных (Рис. 4.3), с тремя уровнями абстракции, на которых можно рассматривать базу данных. Эта архитектура включает:
внешний уровень, на котором пользователи воспринимают данные, где отдельные группы пользователей имеют свое пользовательское представление (ПП) о базе данных;
внутренний уровень, на котором система управления базой данных и операционная система воспринимают данные;
концептуальный уровень представления данных, предназначенный для отображения внешнего уровня на внутренний уровень, а также для обеспечения необходимой их независимости друг от друга. Этот уровень обобщает представления пользователей.
История формирования такой структуры составляет довольно длительный период. Первые предложения поступили в 1971 году от рабочей группы CODASYL (Conference on Data Systems and Languages — Конференция по языкам и системам данных), которая обосновала необходимость использования двухуровневого подхода, построенного на основе выделения системного представления и пользовательских представлений.
В 1975 году Комитет планирования стандартов и норм SPARC (Standards Planning and Requirements Committee) Американского национального института стандартов ANSI (American National Standards Institute) предложил обобщенную структуру систем баз данных, признав необходимость использования трехуровневой архитектуры, которая и была официально признана в 1978 году.
Описание структуры данных на любом уровне называется схемой. Существует три различных типа схем базы данных, которые определяются в соответствии с уровнями абстракции трехуровневой архитектуры. На самом высоком уровне имеется несколько внешних схем или подсхем, которые соответствуют разным представлениям данных. На концептуальном уровне описание базы данных называют концептуальной схемой, а на самом низком уровне абстракции — внутренней схемой.
Основным назначением трехуровневой архитектуры является обеспечение независимости от данных. Суть этой независимости заключается в том, что изменения на нижних уровнях никак не влияют на верхние уровни. Различают два типа независимости от данных: логическую и физическую.
Рисунок 4.3 – Трехуровневая архитектура описания базы данных
Логическая независимость от данных означает полную защищенность внешних схем от изменений, вносимых в концептуальную схему. Такие изменения концептуальной схемы, как добавление или удаление новых сущностей, атрибутов или связей, должны осуществляться без необходимости внесения изменений в уже существующие внешние схемы для других групп пользователей. Следовательно, тем группам пользователей, которых эти изменения не касаются, не потребуется вносить изменения в свои прикладные пользовательские программы.
Физическая независимость от данных означает защищенность концептуальной схемы от изменений, вносимых во внутреннюю схему. Эти изменения внутренней схемы, как использование различных файловых систем или структур хранения, разных устройств хранения,