Лекции по Базам данных. лекции. Развитие технологий обработки данных
 Скачать 0.53 Mb.
|
|
Квантор существования. Квантор – обозначает количество чего-либо. Квантор существования означает, что существует хотя бы один экземпляр определенного типа вещей. В реляционном исчислении квантор существования используется для задания условия того, что определенный тип строк в отношении существует. В реляционной алгебре для выполнения этого запроса требуется соединение. Таким образом, квантор существования используется в реляционном исчислении, для того чтобы выполнять функцию соединения. Квантор всеобщности. Квантор всеобщности означает, что некоторое условие применяется ко всем строкам или к каждой строке некоторого типа. Он используется в тех же целях, что и операция деления реляционной алгебры. Проиллюстрируем его применение тем же запросом, который рассматривался в разделе, описывающем операцию деления. Различные представления о данных в базах данных Различные представления о данных в базах данных Проектирование и создание базы данных предполагает объединение данных, предназначенных для решения нескольких прикладных задач для множества разных пользователей. Соответственно, при объединении данных должны учитываться требования к данным каждого из пользователей, основанные на их представлении о данных и связях между ними. Эти требования должны обобщаться в единое представление, которое и будет служить основой для построения единой базы данных (Рис. 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 – Трехуровневая архитектура описания базы данных Логическая независимость от данных означает полную защищенность внешних схем от изменений, вносимых в концептуальную схему. Такие изменения концептуальной схемы, как добавление или удаление новых сущностей, атрибутов или связей, должны осуществляться без необходимости внесения изменений в уже существующие внешние схемы для других групп пользователей. Следовательно, тем группам пользователей, которых эти изменения не касаются, не потребуется вносить изменения в свои прикладные пользовательские программы. Физическая независимость от данных означает защищенность концептуальной схемы от изменений, вносимых во внутреннюю схему. Эти изменения внутренней схемы, как использование различных файловых систем или структур хранения, разных устройств хранения, модификация индексов или хеширование, должны осуществляться без необходимости внесения изменений в концептуальную или внешнюю схемы. Пользователем могут быть замечены изменения только в общей производительности системы. Далее рассмотрим каждый из трех названных уровней. Внешний уровень. Внешний уровень — это пользовательский уровень. Пользователем может быть программист, или конечный пользователь, или администратор базы данных. Представление базы данных с точки зрения пользователей называется внешним представлением. Каждая группа пользователей выделяет в моделируемой предметной области, общей для всей организации, те сущности, атрибуты и связи, которые ей интересны. Выражая их в наиболее удобной для себя форме, она формирует свое пользовательское представление, причем одни и те же данные могут отображаться по-разному в разных пользовательских представлениях. Например, в информационной системе ВУЗа пользователя из бухгалтерии будет интересовать информация о студентах, которым должна быть начислена стипендия, но его совершенно не будет интересовать информация об успеваемости всех студентов и многое другое. И наоборот, пользователя из учебной части будет интересовать успеваемость студента, и не будет интересовать начисленная стипендия. Эти частичные или переопределенные описания базы данных для отдельных групп пользователей или ориентированные на отдельные аспекты предметной области называют подсхемой. При рассмотрении внешнего уровня базы данных важно отметить, что каждый тип пользователей может применять для работы с базой данных свой язык общения. Конечные пользователи употребляют либо язык запросов, либо специальный язык, поддерживаемый приложениями и вызывающий определенные для пользователя экранные формы и пользовательские меню. Прикладные программисты чаще применяют либо языки высокого уровня, например С, Pascal и т.п., либо специальные языки систем управления базами данных. Языки последнего типа относят к языкам четвертого поколения. Какой бы базовый язык высокого уровня не использовался, он должен включать в себя и подъязык для работы с данными. Информационная система может поддерживать любое количество подъязыков данных, любое количество базовых языков высокого уровня. Но язык SQL (язык структурированных запросов) поддерживается практически всеми информационными системами, имеющими в своей структуре базы данных. Он может использоваться и как встроенный в другие языки, и как отдельный самостоятельный язык запросов. Концептуальный уровень. Концептуальный уровень является промежуточным уровнем в трехуровневой архитектуре и обеспечивает представление всей информации базы данных в абстрактной форме. Описание базы данных на этом уровне называется концептуальной схемой, которая является результатом концептуального проектирования. Концептуальное проектирование базы данных включает анализ информационных потребностей пользователей и определение нужных им элементов данных. Следовательно, концептуальная схема — это единое логическое описание всех элементов данных и отношений между ними, логическая структура всей базы данных. Для каждой базы данных имеется только одна концептуальная схема. Концептуальная схема должна содержать: объекты и их атрибуты; связи между объектами; ограничения, накладываемые на данные; семантическую информацию о данных; обеспечение безопасности и поддержки целостности данных. Концептуальный уровень поддерживает каждое внешнее представление, в том смысле, что любые доступные пользователю данные должны содержаться (или могут быть вычислены) на этом уровне. Однако этот уровень не содержит никаких сведений о методах хранения данных. Внутренний уровень. Внутренний уровеньявляется третьим уровнем архитектуры базы данных. Внутреннее представление не связано с физическим уровнем, так как физический уровень хранения информации обладает значительной индивидуальностью для каждой системы и описывает, в основном ее индивидуальные характеристики и качества. Рассматривая внутренний уровень можно сказать, что на нем все индивидуальности не учитываются, и область хранения информации представляется как бесконечное линейное адресное пространство. На нижнем уровне находится внутренняя схема, которая является полным описанием внутренней модели данных. Для каждой базы данных существует только одна внутренняя схема. Внутренняя схема описывает физическую реализацию базы данных и предназначена для достижения оптимальной производительности и обеспечения оптимального использования пространства запоминающего устройства. Именно на этом уровне осуществляется взаимодействие системы управления базы данных с методами доступа операционной системы (вспомогательными функциями хранения и извлечения записей данных) с целью размещения данных на запоминающих устройствах, создания индексов, извлечения данных и т.д. На внутреннем уровне хранится следующая информация: распределение дискового пространства для хранения данных и индексов; описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных); сведения о размещении записей; сведения о сжатии данных и выбранных методах их шифрования. Система управления базой данных отвечает за установление соответствия между всеми тремя типами схем разных уровней, а также за проверку их непротиворечивости. Ниже внутреннего уровня находится физический уровень, который контролируется операционной системой, но под руководством системы управления базой данных. Физический уровень учитывает, каким образом данные представляются в информационной системе. Он обеспечивает физический взгляд на базу данных: дисководы, физические адреса, индексы, указатели и т.д. За этот уровень отвечают проектировщики физической базы данных, которые работают только с известными операционной системе элементами. Область их интересов: указатели, реализация последовательного распределения, способы хранения полей внутренних записей на диске. Однако функции системы управления базой данных и операционной системы на физическом уровне не вполне четко разделены и могут изменяться от системы к системе. В одних системах управления базой данных используются многие предусмотренные в данной операционной системе методы доступа, тогда как в других применяются только самые основные и реализована собственная файловая организация. |