Объединение инвертированных списков по всем дополнительным ключам составляет т. н. (полностью) инвертированный файл.
Например, с кодом профессии 03 и годом рождения 1950 лишь работник с учетным номером 1. Если инвертированные списки не перекрывают все множество ключей, то говорят о частично инвертированном файле.
9. УРОВНИ МОДЕЛЕЙ
В БнД отражается информация о предметной области. В автоматизированных ИС отображение предметной области, представлено моделями нескольких уровней. Информационное моделирование в условиях БнД имеет специфические особенности, вызванные, с одной стороны, идеологией банковской организации данных, а с другой – особенностями СУБД.
Даталогическая модель в БнД представлена базой данных (собственно хранимые данные о предметной области) и её описанием (схемой и схемой хранения). Схема играет двойственную роль:
- модель базы данных
- модель (косвенно) предметной области
10. КЛАССИФИКАЦИЯ МОДЕЛЕЙ
СУБД, нашедшие широкое применение в настоящее время, можно назвать синтаксико-ориентированными. Модель данных логического уровня, поддерживаемую средствами СУБД, называют даталогической моделью. Эта модель отражает логические связи между элементами данных безотносительно к их содержанию и среде хранения. Даталогическая модель строится с учётом ограничений конкретной СУБД. При построении даталогической модели учитываются особенности отображаемой предметной области. БД предполагает интегрированное и взаимосвязанное хранение данных, поэтому для проектирования даталогической модели необходимо иметь соответствующее описание предметной области. Выбор синтаксических конструкций проектируемой БД во многом определяется характером связей между отображаемыми в информационной модели сущностями предметной области,
выполненное без ориентации на используемые в дальнейшем программные и технические средства, называется инфологической моделью предметной области. Иногда к инфологической модели относят и описание информационных потребностей пользователя. Инфологическая модель предметной области является исходной по отношению к даталогической модели БД. Она служит связующим звеном между специалистами предметной области и администрацией БД в процессе проектирования БнД.
Для привязки даталогической модели к среде хранения используется модель данных физического уровня (иногда физической моделью).
Эта модель определяет используемые запоминающие устройства, способы расположения элементов данных в памяти, способы физической реализации логических отношений между элементами данных. Модель физического уровня строится с учетом ограничений СУБД и операционной системы.
Модель каждого последующего уровня строится на основе фиксированных характеристик моделей предшествующих уровней. Модели имеют разный уровень абстракции.
Выделение моделей разных уровней абстракции позволяет:
- разделить сложный процесс отображения “предметная область – база данных” на несколько итеративных более простых отображений;
- обеспечить специализацию разработчиков баз данных; возможность работать разным категориям пользователей с моделью соответствующего уровня;
- предоставить возможность активного и конструктивного участия в разработке баз данных лицам, не имеющим профессиональных навыков в области обработки данных;
- создать предпосылки автоматизации проектирования баз данных путем формализованного перехода с одного уровня моделей на другой.
Инфологическая модель отображает объективные, “внутренние” характеристики предметной области, поэтому она сравнительно стабильна. При наличии модели инфологического уровня изменение используемых программных и технических средств потребует не полного перепроектирования информационной базы, а только выполнения перехода от инфологической модели к схеме, поддерживаемой новыми программно-техническими средствами. Использование инфологической модели повышает адаптивность банков данных.
Различают глобальные и локальные модели.
Глобальные модели отражают точку зрения администратора базы данных, локальные – взгляды различных пользователей. Модель, обеспечивающую интегрированное представление о предметной области, называют концептуальной моделью, а модель логического уровня, соответствующую представлению о данных конкретного пользователя внешней моделью. Внешняя модель – подсхема. Применяются локальные модели. Локальные модели и подсхемы не всегда совпадают.
Роль подсхемы
Подсхема ограничивает знания пользователя частью БД, с которой он работает. Делает доступными для пользователя определенные части БД, защищая остальные от несанкционированного доступа.
Обеспечивает соответствие состава и структуры подсхемы потребностям пользователя.
Увеличивает степень независимости программ от данных, так как изменения в схеме не всегда приводят к изменениям в подсхеме.
Для подсхемы можно указывать ограничения и режимы обработки.
Обеспечивается возможность употребления различных языков программирования для различных приложений.
Банк данных (БнД) – это система специальным образом организованных данных (баз данных), программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования этих данных.
Состав БнД:
1. База данных (БД)
2. Языковые средства
3. Программные средства
4. Технические средства
5. Организационно-методические средства
6. Администратор БнД
7. Словарь данных
Технические средства
К техническим средствам БнД относятся процессоры, устройства ввода-вывода, внешние запоминающие устройства, каналы связи. В технической документации СУБД указывается минимальная конфигурация технических средств, а также различные ограничения на состав и количество технических средств. Специальные машины баз данных.
Программные средства
Программные средства представляют собой сложный комплекс, обеспечивающий взаимодействие всех частей ИС в процессе её существования. В составе программных средств БнД можно выделить программы управления данными, которые называются иногда управляющей системой БД, трансляторы с языков БнД, различные вспомогательные программы (утилиты), программные средства, обеспечивающие взаимодействие пользователей и технических средств (операционная система, операционные оболочки). Совокупность программных средств и языковых средств общего или специализированного назначения, необходимая для создания БД, поддержание её в актуальном состоянии и организации доступа к ней различных пользователей в условия принятой технологии обработки данных, называется системой управления базами данных.
Организационно-методические средства
Состоят из нормативно-технологических и инструктивно-методических материалов по организации и использованию БнД, правилам организации работы пользователей.
Языковые средства
Языковые средства служат для описания различных компонентов БнД и внешних элементов, находящихся с ним во взаимодействии.
Языки описания данных (ЯОД) – в зависимости от назначения могут быть нескольких видов. Описание состава и логической организации БД на ЯОД называется схемой. Язык описания данных схем. Например, физическое представление регулярного (симметричного) двоичного дерева.
Описание части БД, представляющая интерес для определенного пользователя (приложения), называется подсхемой. Язык описания подсхем.
Среда хранения БД и соответствующее отображение схемы в памяти описываются на языке описания хранения данных (ЯОХД). Иногда называют языком описания схемы хранения.
Языки общения с БД. В зависимости от особенностей конкретного БнД языковые средства, их синтаксические и семантические свойства, способы реализации, круг лиц, на который они ориентированы, могу изменяться в широком диапазоне: от языков программирования до языков, ориентированных на конечного пользователя.
Язык манипулирования данными (ЯМД)
Включающий язык, базовый язык.
Для общения с базой данной данных непрофессиональных пользователей предназначен язык ведения диалога. Язык запросов.
Используются и другие языковые средства, такие, как языки описания транзакций, описания пользователей, управления ресурсами и выполнения работ и др.
Особым языком можно считать управляющие операторы утилит системы.
В последнее время наблюдается совмещение языковых средств различного назначения в единый язык, в котором каждый из вышеназванных языков представлен одним или несколькими операторами.
11. СХЕМА ВЗАИМОДЕЙСТВИЯ КОМПОНЕНТОВ
Схемы, подсхемы и схемы хранения проектируются и описываются на ЯОД в соответствии с методическими указаниями (1).
Эти описания переносятся на машинные носители (магнитные диски), вводятся в систему (2) и переводятся в объектные или загрузочные представления (3), которые хранятся в соответствующих библиотеках (файлах).
После этого подготавливаются и вводятся в систему входные данные (4) и производится загрузка БД (5). Запросы к БД формируются на языке общения с БнД (6) и вводятся в систему (7).
Термин «пользователи» подразумевает как людей, так и прикладные программы.
Соответственно различают подход к проектированию баз данных «от запросов пользователей» и от реального мира.
При первом подходе на основе анализа запросов определяются границы предметной области и структура данных. Такой подход используется для ограниченного круга технических систем.
При втором подходе с помощью экспертов определяется границы предметных областей, т.е состав объектов, их характеристики и связи между ними (с учетом развития системы). Затем проектируется информационная модель предметной области. Подход от реального мира является основным при проектировании банков данных для сложных автоматизированных систем.
В процессе использования такого банка данных возможна оптимизация, при которой на основе анализа требований пользователя можно путем выбора структуры хранения данных обеспечить наилучшее обслуживание системы в целом по критериям минимизации занимаемой памяти, времени доступа к данным и др.
Приводится также стандартизация в представлении данных, что упрощает эксплуатацию банка данных, обеспечивает выполнение процедур контроля и восстановления данных и обеспечивает возможность обмена данными с другими АС.
12. ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ
На различных этапах проектирования разрабатываются инфологическая и даталогическая концептуальные модели. Последняя часто называется концептуальной моделью. Точно также различаются внешняя инфологическая и даталогическая (внешняя модель) модели.
Задача инфологического этапа проектирования – получение семантических (смысловых) моделей, отражающих конкретное информационное содержание предметной области (ПО). Этот этап соответствует эскизному проекту базы данных.
Даталогическое проектирование включает логический и физический этапы.
Задача логического этапа проектирования – организация данных, выделенных на предыдущем этапе проектирования, в форму, принятую в выбранном конкретном СУБД, т.е. требуется разработать схему концептуальной модели из схемы внешних моделей данных предметной области, пользуясь только теми типами моделей данных и их особенностями, которые поддерживаются данной СУБД. Этот этап соответствует техническому проекту базы данных.
Задача физического этапа проектирования – выбор рациональной структуры хранения данных и методов доступа к ним, использую средства представляемых СУБД. Этот этап соответствует рабочему проектированию базы данных.
Для обеспечения независимости прикладных программ от данных вводится многоуровневая архитектура банка данных, основанная на введении нескольких моделей данных (МД).
Архитектура разделена на три основных уровня: внутренний, концептуальный и внешний. Вообще говоря, внутренний уровень очень близок к физической памяти, то есть связан со способом фактического хранения данных. Внешний уровень наиболее близок к пользователям, то есть связан с тем, как отдельные пользователи представляют себе эти данные. Концептуальный уровень есть промежуточный уровень между двумя другими.
Пользователями системы являются либо прикладные программисты, либо пользователи. В распоряжении каждого пользователя есть язык общения. Для прикладного программиста это будет язык программирования, пользователю за терминалом, возможно, будет предоставлен язык, разработанный с учетом его потребностей. Но важно то, что эти языки включают подъязык данных – подмножество языка пользователя для обработки информации в БД. Этот подъязык данных содержится в базовом языке (фактически по отношению к существующим языкам программирования, элементы подъязыка данных часто есть нечто иное, как обращение к стандартным подпрограммам).
Каждый пользователь обеспечивается рабочей областью, которая используется для приема или передачи данных между пользователем и базой данных. Для прикладного программиста рабочей областью является область ввода/вывода. Для пользователя за терминалом эта область может состоять из рабочей памяти, выделенной терминалу, или, возможно, видеоэкрана.
Отдельного пользователя, как правило, интересует только некоторая часть всей базы данных. Его представление о базе данных не совпадает с реальной физической базой данных. Поэтому на внешнем уровне вводится логическая модель данных (МД). В ней отражается структура данных, имена записей, имена и форматы полей. Для разделения логических моделей разных пользователей и обеспечения защиты данных от неавторизованного доступа логическая модель данных разбивается на два уровня представления:
- каждый пользователь представляет базу данных посредством внешней модели (ВМД). Внешняя модель является информационным содержанием базы данных в том виде, в каком его представляет конкретный пользователь. Вообще говоря, ВМД состоит из различных экземпляров внешних записей.
Каждая ВМД определяется посредством внешней схемы.
Схема – модель данных, в которой отражается только структура данных, имена и форматы полей и записей, но не дается конкретное информационное содержание.
Записи:
002011 Петрова Н.П. 1945
100567 Фомина С.Е. 1947
258341 Безруков В.И. 1950
- из отдельных внешних моделей создается единая для всех пользователей логическая модель, которая называется концептуальной МД (КМД). КМД есть представление полного информационного содержания базы данных в абстрактной форме по сравнению со способом физического хранения данных. Это представление может полностью отличаться от представления данных отдельным пользователем (ВМД). Концептуальная модель состоит из множества экземпляров различных типов концептуальных записей. КМД определяется посредством концептуальной схемы, которая включает определения каждого типа концептуальных записей. Эти определения должны быть определениями только информационного содержания.
Таким образом, концептуальная модель есть представление общего содержания базы данных, а концептуальная схема – определение этого представления.
13. АРХИТЕКТУРА БАНКА ДАННЫХ
Архитектура банка данных
На концептуальном уровне поддерживается одна модель для всех приложений.
Третьим уровнем архитектуры является внутренний уровень. Внутренняя модель (ВнМД) есть представление самого низкого уровня всей базы данных; она состоит из различных экземпляров типов внутренних записей. Термин внутренняя запись применяется для конструкции, которая называется хранимой записью. Таким образом, внутренняя модель является ещё одним шагом в сторону от физического уровня, так как она не строится в терминах физических записей или блоков. ВнМД описывается посредством внутренней схемы, которая не только определяет различные типы хранимых записей, но и то, какие индексы существуют, как представлены хранимые поля, какова физическая последовательность хранимых записей и так далее.
В этой архитектуре имеется два уровня отображения: между внешним и концептуальным уровнями системы и между концептуальным и внутренним уровнями. Отображение “концептуальный – внутренний” определяет соответствие между моделью данных и хранимой базой данных; оно указывает, как концептуальные записи и поля отображаются в их хранимые копии. Если структура хранимой базы данных изменяется, то есть если изменяется определение структуры хранения, отображение “концептуальны – внутренний” должно быть соответственно изменено так, чтобы концептуальная схема оставалась неизменной.
Отображение “внешний – концептуальный” определяет соответствие между конкретной внешней моделью и моделью данных. В общем случае между этими двумя уровнями могут существовать те же виды различий, что и между моделью данных и базой данных. Например, поля могут иметь различные типы данных, записи могут быть по-разному упорядочены и так далее. Несколько внешних моделей может существовать одновременно; несколько пользователей могут совместно использовать данную внешнюю модель; различные внешние модели могут пересекаться.
Система управления базой данных (СУБД) является программой (инструментом), которая управляет всем доступом к базе данных.
14. ПОСЛЕДОВАТЕЛЬНОСТЬ ДЕЙСТВИЙ ПРИ ЧТЕНИИ ЗАПИСИ
Последовательность действий СУБД при формировании записи ВМД для прикладной программы
Алгоритм выполнения операции чтения включает следующие шаги:
1. Прикладная программа (ПП) обращается к СУБД с запросом на чтение записи ВМД
2. СУБД, используя схемы ВМД, КМД и описание отображения ВМД – КМД определяет, какие записи КМД необходимы для формирования записи ВМД
3. Используя схемы КМД, ВнМД и описание отображения КМД – ВнМД, СУБД определяет конкретные хранимые записи, необходимые для построения затребованных записей КМД, и какая совокупность физических записей необходима для считывания с магнитного носителя
4. СУБД выдает ОС запрос на считывание в свою буферную область памяти необходимых данных из ФБД
5. ОС с помощью своих методов доступа считывает с магнитного носителя затребованные записи и помещает их в системные буферы СУБД
6. На основании имеющихся схем моделей и описания их отображения СУБД формирует в буферной памяти записи ВМД в виде, который требует прикладная программа
7. СУБД пересылает сформированную запись в рабочую область ввода/вывода прикладной программы
8. ПП обрабатывает запись, поступившую в её рабочую область.
15. ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ
Инфологический подход к проектированию информационных систем не формализован и зависит во многом от искусства проектировщика, поэтому рассмотрим общую методологию инфологического проектирования, основанную на модели «сущность – связь» (ER – модели)
МОДЕЛЬ «СУЩНОСТЬ – СВЯЗЬ» (ER- МОДЕЛЬ)
Данная модель используется только на этапе инфологического проектирования предметной области. При описании данной модели используются три основных элемента: сущность, атрибут, связь.
Сущность – абстракция реально существующего объекта, процесса или явления, о которых необходимо хранить информацию в системе.
Сущность может быть материальная (предприятие, изделие, и т.п.) и нематериальная(рефераты научных статей, знания и т.п.).
Тип сущности определяет набор однородных объектов(например, сотрудники учреждения). Экземпляр сущности – конкретный объект в наборе (конкретный сотрудник). Для определения конкретных сущностей используются идентификаторы, которые позволяют отличать одну сущность от другой.
Атрибут– поименованная характеристика сущности.
Основное назначение атрибута – описание свойств сущности или идентифицировать экземпляр сущности, если атрибут используется как идентификатор.
Связи– выступают в модели в качестве средства, с помощью которого представляются отношения между сущностями для данной ПО.
Связи могут быть бинарными(между двумя сущностями) и в общем случае n-арные. В модели «сущность – связь» используются только бинарные связи.
Связь 1:1
Один экземпляр сущности, от которого направлена связь, идентифицирует один и только один экземпляр другой сущности, к которому направлена связь, и наоборот.
Связь типа «является ответственным квартиросъемщиком».
Связь 1:М
С одним экземпляром сущности могут быть связаны либо несколько экземпляров сущности, либо один, либо не одного.
Связь типа «имеет в составе» между сущностями «город» и «район».
Связь М:1
Является обратным отображением связи 1:М.
Связь M:N
С помощью отображения M:N определяется тип связей, между двумя сущностями, при которой каждому экземпляру одной сущности может соответствовать 0,1 или несколько экземпляров другой сущности и наоборот.
Связи типа «студент» и «дисциплина»
Все четыре вида связей широко распространены. Иногда необходимо рассматривать однонаправленную связь одной сущности к другой. Различают простую и многозначную связи.
При простой однонаправленной связи одному экземпляру одной сущности соответствует один экземпляр другой сущности. При этом обратная связь не определена.
Связь типа «начальник отдела» между «отдел» и «служащий».
При многозначной однонаправленной связи от одной сущности к другой одному экземпляру одной сущности соответствует 0,1 или несколько экземпляров другой сущности. При этом обратная связь не определена.
Связь типа «перенесенное заболевание» между сущностями «пациент» и «заболевание».
При оформлении проекта для наглядности используются графические диаграммы, в которых тип сущности обозначается прямоугольником, атрибуты – овалами. Атрибуты соединяются с сущностями не направленными ребрами. Идентифицирующие атрибуты подчеркиваются. Связи(отношения) изображаются ребрами. С типами сущностей связи соединяются ребрами: в случае бинарных связей – направленными, в других случаях – не направленными.
Конечным этапом построения модели является использование только бинарных связей.
