Title Лабораторная работа №2 Технологии работы с базами данных.docx ✅

Внутренний уровень. Так же как и концептуальный, внутренний уровень состоит только из одного представления. Внутреннее представление описывает все подробности, связанные с хранением данных в базе. Оно состоит из экземпляров каждого типа внутренней записи. Термин "внутренняя запись" принадлежит терминологии ANSI/SPARC и фактически соответствует хранимой записи. Внутреннее представление, так же как внешнее и концептуальное, нс связано с аппаратным уровнем и не включает подробностей, связанных с размещением данных на дисках, таких как номера секторов и т.п. Внутреннее представление описывается с помощью внутренней схемы, которая определяет типы хранимых записей, индексы (служебные структуры, упрощающие поиск данных), способы представления хранимых полей, физическую последовательность хранимых записей и т.д. Отображения. В представленной архитектуре присутствует отображение двух уровней. Отображение концептуального уровня на внутренний определяет соответствие между концептуальным представлением и хранимой БД. При изменении структур хранения изменяется и отображение "концептуальный – внутренний" таким образом, чтобы концептуальная схема осталась неизменной. Это обеспечивает так называемую физическую независимость данных. Отображение внешнего уровня на концептуальный определяет соответствие между внешними представлениями и концептуальным. Например, несколько концептуальных полей "индекс", "города", "улица", "дом" для пользователя могут быть объединены в одно внешнее поле "адрес". Появляется возможность менять отдельные внешние представления, дополнительно изменяя только отображения и не затрагивая остальные уровни системы. Отделение внешнего уровня от концептуального обеспечивает логическую независимость данных [5]. Определения представлений каждого из уровней и отображений СУБД должна хранить вместе с прочей метаинформацией и использовать их при обработке запросов. Архитектура ANSI/SPARC имеет большое теоретическое значение, определяя пути обеспечения логической и физической независимости данных. Однако два уровня отображения приводят к дополнительным накладным расходам при обработке запросов пользователя, поэтому разработчики СУБД, стараясь увеличить быстродействие систем, обычно отходят от строгой реализации этой архитектуры. Архитектура многопользовательских систем баз данных Рассмотрим аспекты архитектуры систем БД, связанные с обеспечением совместной работы пользователей. В несколько абстрактной форме можно представить многопользовательскую систему БД совокупностью двух компонент – создающего запросы клиента, и сервера, который выполняет приходящие запросы. В частном случае, и клиентское, и серверное приложения могут выполняться на одном и том же компьютере. Но они могут находиться и на разных компьютерах, связанных