Что такое подсхема в информатике

Уровни представления данных. Понятия схемы и подсхемы данных

При разработке баз данных в зависимости от степени абстрагирования данных выделяют три уровня представления данных: концептуальный уровень, логический и физический.

Физический уровень – уровень представления данных, учитывающий способ организации данных на машинном носителе в виде бит, байт и их структур. Как видно уровень абстракции данных уменьшается от концептуального уровня представления данных к физическому уровню.

Как видно основные этапы проектирования баз данных (концептуальное, логическое, физическое проектирование) также соответствуют трехуровневой архитектуре представления данных.

Следует отметить, что на западе принята двухуровневая система представления данных, используемая при описании баз данных. Рассматриваются логический и физический уровни представления данных. Это связано с тем, что в настоящее время при разработке баз данных в основном используются реляционные или объектно-реляционные модели данных, и этапы концептуального и логического проектирования реляционных баз данных совмещены. Отсюда все современные CASE-средства проектирования баз данных позволяют строить логические и физические модели баз данных (см. раздел 1.5).

На каждом уровне представления данных имеются различные модели представления данных. Фактически синонимом понятия модели данных является понятие схемы базы данных.

Внешний уровень Представление 1 Представление 2……… Представление n

Концептуальный уровень Концептуальная схема

Внутренний уровень Внутренняя схема

Физическая организация данных База данных

При описании базы данных возможно наличие нескольких внешних схем или подсхем, соответствующих представлениям о данных предметной области различными пользователями. На концептуальном уровне описание базы данных называют концептуальной схемой, на нижнем уровне абстракции – внутренней схемой. Следует различать описание базы данных и саму базу данных. Описанием базы данных является схема базы данных или модель данных. Схема создается в процессе проектирования базы данных. Совокупность информации, хранящаяся в базе данных в определенный момент времени, называется состоянием. Таким образом, одной и той же схеме данных может соответствовать несколько состояний базы данных. Схема базы данных иногда называется содержанием базы данных, а ее состояние детализацией. Схема базы данных показывает логическую организацию всей базы данных в целом, а подсхема – описание части базы данных, описание представления о данных отдельного пользователя или приложения.

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Источник

Уровни представления баз данных. Понятия схемы и подсхемы

Современная технология баз данных основана на концепции многоуровневой архитектуры СУБД. Эти идеи впервые были сформулированы в отчёте рабочей группы по базам данных Комитета по планированию стандартов Американского национального института стандартов (ANSI/X3/SPARC). Этот отчёт был опубликован в 1975 г. В нём была предложена обобщенная трёхуровневая модель архитектуры СУБД, включающая концептуальный, внешний и внутренний уровни (рис. 1.7).

Рис.1.7 Уровни представления данных

Концептуальный уровень архитектуры ANSI/SPARC служит для под-держки единого взгляда на базу данных, общего для всех её приложений и независимого от них и от среды хранения [6]. Концептуальный уровень представляет собой формализованную информационно-логическую модель ПО. Описание этого представления называется концептуальной схемой или схемой БД.

Внутренний уровень архитектуры поддерживает представление данных в среде хранения и пути доступа к ним [6]. На этом архитектурном уровне БД представлена в полностью «материализованном» виде, тогда как на других уровнях идёт работа на уровне отдельных экземпляров или множества экземпляров данных. Описание БД на внутреннем уровне называется внутренней схемой или схемой хранения.

Внешний уровень архитектуры БД предназначен для групп пользователей. Описание представления данных для группы пользователей называется внешней схемой. Наличие внешнего уровня позволяет поддерживать разное представление одних и тех же данных для различных групп пользователей или задач [6].

Подсхема базы данных – это описание структуры данных прикладного программиста.

Каждый из этих уровней может считаться управляемым, если он обладает внешним интерфейсом, который обеспечивает возможности определения данных. В этом случае становится возможными формирование и системная поддержка независимого взгляда на БД для какой-либо группы персонала или пользователей, взаимодействующих с БД через интерфейс данного уровня.

В архитектурной модели ANSI/SPARC предполагается наличие в СУБД механизмов, обеспечивающих междууровневое отображение данных «внешний – концептуальный» и «концептуальный – внутренний». Функциональные возможности этих механизмов определяют степень независимости данных на всех уровнях. На переходе «внешний – концептуальный» обеспечивается логическая независимость данных, на переходе «концептуальный – внутренний» – физическая независимость. Под логической независимостью подразумевается возможность вносить изменения в концептуальный уровень, не меняя представление БД для пользователей, или изменять представление данных для пользователей без изменения концептуальной схемы. Физическая независимость данных подразумевает возможность вносить изменения в схему хранения, не меняя концептуальную схему БД.

Основной характеристикой баз данных является совместное использование данных многими пользователями АИС. Должно существовать какое-то общее понимание информации, представленной данными. Общее понимание должно относиться к чему-либо внешнему по отношению к пользователям, и оно должно быть зафиксировано. Для этого необходима некоторая предварительно определённая грамматика, которую принято называть моделью данных.

Источник

Схемы и подсхемы

Тема : Схемы и подсхемы.

Если бы назначением базы данных (БД) было только хранение данных, то ее структура была бы простой. Причина ее сложности в том, что она должна обеспечивать связи.

Прежде всего следует обсудить способ, с помощью которого пользователи БД представляют эти связи.

Структуру данных необходимо описывать формализованным образом. Описания логической и физической структур БД используется программными средствами управления БД при обработке требований пользователей на получение той информации, которую содержит БД. Описание логической структуры БД называется схемой. Схема представляет собой таблицу типов используемых данных. Она содержит имена объектов и их атрибуты и указывает на существующую между ними связь. Если схема содержит значения элементов данных, как на рис. 7. Ее называют экземпляром схемы.

На рис. 10 приведен пример схемы:

Рекомендуемые файлы

Сплошные линии, соединяющие блоки, отображают связи. Запись Заказ_на_закупку связана с записями Статья_закупки, в которых содержится заказ на закупку. Запись Поставщик связана с записями Расценка, описывающими поставляемые товары и расценки. Связи на схеме могут обеспечивать передачу такой информации, которая не представлена конкретными элементами данных, показанными на схеме.

Штриховые линии отображают перекрестные ссылки. Они не обеспечивают передачу дополнительной информации и если их убрать, то потери информации не произойдет.

Термин схема используется для определения полной таблицы всех типов элементов данных и типов записей, хранимых в БД. Термином подсхема определяют описание данных, которое использует ПП – лист. На основе одной схемы можно составить много различных подсхем. Например, на рис. 11 приведены подсхемы двух ПП – листов. Программисты имеют различные представления о данных, но обе подсхемы получены из схемы, приведенной на рис. 11.

Подсхема программиста А

Подсхема программиста В

Ни схемы, ни подсхемы не отражают способов физического запоминания данных. Существует 4 различных вида описания данных:

1. подсхема – таблица, описывающая ту часть данных, которая ориентирована на нужды одной или нескольких прикладных программ.

2. глобальное описание логической структуры БД или схема – таблица, логически описывающая всю БД. Она отражает представление о данных администратора БД.

3. описание физической организации БД – таблица физического расположения данных на носителях информации. Это представление о данных нужно системному программисту, который занимается вопросами эффективности работы системы, расположения или поиска, а также вопросами использования методов сжатия данных.

4. описание данных, которое система передает пользователю терминала БД как можно более близким к тому описанию данных, которое он использует в своей работе.

Связи этих четырех видов описания данных представлены на рисунке 12.

Следующий момент, который следует обсудить – это связи между элементами данных.

Взаимосвязь между двумя типами данных может быть простая и сложная. Под простой связью понимается такая связь, в которой элементы соединяются один с одним. Например, №_служащего и Имя, так как каждое имя имеет соответствующий №_служащего и наоборот.

Связь между служащим и отделом простая (каждый служащий может работать только в одном отделе), а связь между отделом и служащим сложная, называемая также «многие к одному», (в каждом отделе может работать много служащих).

Четыре типа связи возможны между двумя наборами элементов А и В. связь А с В может быть простой, а обратная связь – сложной и наоборот, а также обе связи могут быть простыми или сложными. На рис. 13 изображены все эти варианты.

А ↔В – один к одному; А В – один ко многим;

А В – многие к одному; А В – многие ко многим

На рис. 14 показаны два способа представления связей между двумя наборами элементов.

Источник

Что такое схемы базы данных? 5-минутное руководство с примерами

При создании серверной части приложения необходимо учитывать, как интерфейс будет взаимодействовать с серверной частью. Однако более важным является построение и дизайн вашей базы данных. Отношения между вашими формами данных приведут к построению вашей схемы базы данных.

Схема базы данных является абстрактным дизайн, который представляет собой хранение ваших данных в базе данных. Он описывает как организацию данных, так и отношения между таблицами в данной базе данных. Разработчики заранее планируют схему базы данных, чтобы знать, какие компоненты необходимы и как они будут соединяться друг с другом.

В этом руководстве мы узнаем, что такое схема базы данных и почему они используются. Мы рассмотрим несколько распространенных примеров, чтобы вы могли узнать, как настроить схему базы данных самостоятельно.

Что такое схемы базы данных?

Когда дело доходит до выбора базы данных, одна из вещей, о которой вы должны подумать, — это форма ваших данных, модель, которой они будут следовать, и то, как сформированные отношения помогут нам при разработке схемы.

Схема базы данных — это план или архитектура того, как будут выглядеть наши данные. Он не содержит самих данных, а вместо этого описывает форму данных и то, как они могут быть связаны с другими таблицами или моделями. Запись в нашей базе данных будет экземпляром схемы базы данных. Он будет содержать все свойства, описанные в схеме.

Думайте о схеме базы данных как о типе структуры данных. Он представляет собой структуру и структуру содержимого данных организации.

Схема базы данных будет включать:

Размер и сложность схемы вашей базы данных зависит от размера вашего проекта. Визуальный стиль схемы базы данных позволяет программистам правильно структурировать базу данных и ее взаимосвязи, прежде чем переходить к коду. Процесс планирования дизайна базы данных называется моделированием данных.

Схемы важны для проектирования систем управления базами данных (СУБД) или систем управления реляционными базами данных (СУБД). СУБД — это программное обеспечение, которое хранит и извлекает пользовательские данные безопасным способом в соответствии с концепцией ACID.

Во многих компаниях ответственность за проектирование базы данных и СУБД обычно ложится на роль администратора базы данных (DBA). Администраторы баз данных несут ответственность за обеспечение беспрепятственного доступа к информации аналитикам данных и пользователям баз данных. Они работают вместе с командами менеджеров для планирования и безопасного управления базой данных организации.

Примечание. Некоторыми популярными СУБД являются MySQL, Oracle, PostgreSQL, Microsoft Access, MariaBB и dBASE, а также другие.

Типы схемы базы данных

Существует два основных типа схемы базы данных, которые определяют разные части схемы: логическую и физическую.

Логический

Схема логической базы данных представляет, как данные организованы в виде таблиц. Он также объясняет, как атрибуты из таблиц связаны друг с другом. В разных схемах используется разный синтаксис для определения логической архитектуры и ограничений.

Примечание. Ограничения целостности — это набор правил для СУБД, которые поддерживают качество вставки и обновления данных.

Чтобы создать логическую схему базы данных, мы используем инструменты для иллюстрации отношений между компонентами ваших данных. Это называется моделированием сущности-отношения (моделирование ER). Он определяет отношения между типами сущностей.

Схема ниже представляет собой очень простую модель ER, которая показывает логический поток в базовом коммерческом приложении. Он объясняет продукт покупателю, который его покупает.

Идентификаторы в каждом из трех верхних кружков указывают первичный ключ объекта. Это идентификатор, который однозначно определяет запись в документе или таблице. FK на схеме — это внешний ключ. Это то, что связывает отношения от одной таблицы к другой.

Модели сущностей-отношений могут быть созданы всевозможными способами, и существуют онлайн-инструменты, которые помогают в построении диаграмм, таблиц и даже SQL для создания вашей базы данных из существующей модели ER. Это поможет создать физическое представление схемы вашей базы данных.

Физический

Схема физической базы данных представляет, как данные хранятся на диске. Другими словами, это реальный код, который будет использоваться для создания структуры вашей базы данных. Например, в MongoDB с мангустом это примет форму модели мангуста. В MySQL вы будете использовать SQL для создания базы данных с таблицами.

По сравнению с логической схемой она включает имена таблиц базы данных, имена столбцов и типы данных.

Теперь, когда мы знакомы с основами схемы базы данных, давайте рассмотрим несколько примеров. Мы рассмотрим наиболее распространенные примеры, с которыми вы можете столкнуться.

Пример NoSQL

Базы данных NoSQL в первую очередь называются нереляционными или распределенными базами данных. Разработка схемы для NoSQL является предметом некоторых дискуссий, поскольку они имеют динамическую схему. Некоторые утверждают, что привлекательность NoSQL заключается в том, что вам не нужно создавать схему, но другие говорят, что дизайн очень важен для этого типа базы данных, поскольку он не предоставляет одно решение.

Этот фрагмент является примером того, как будет выглядеть физическая схема базы данных при использовании Mongoose (MongoDB) для создания базы данных, представляющей приведенную выше диаграмму отношения сущность. Просматривайте вкладки кода, чтобы увидеть различные части.

Источник

Уровни представления баз данных. Понятия схемы и подсхемы

Современная технология баз данных основана на концепции многоуровневой архитектуры СУБД. Эти идеи впервые были сформулированы в отчёте рабочей группы по базам данных Комитета по планированию стандартов Американского национального института стандартов (ANSI/X3/SPARC). Этот отчёт был опубликован в 1975 г. В нём была предложена обобщенная трёхуровневая модель архитектуры СУБД, включающая концептуальный, внешний и внутренний уровни (рис. 1.7).

Рис.1.7 Уровни представления данных

Концептуальный уровень архитектуры ANSI/SPARC служит для под-держки единого взгляда на базу данных, общего для всех её приложений и независимого от них и от среды хранения [6]. Концептуальный уровень представляет собой формализованную информационно-логическую модель ПО. Описание этого представления называется концептуальной схемой или схемой БД.

Внутренний уровень архитектуры поддерживает представление данных в среде хранения и пути доступа к ним [6]. На этом архитектурном уровне БД представлена в полностью «материализованном» виде, тогда как на других уровнях идёт работа на уровне отдельных экземпляров или множества экземпляров данных. Описание БД на внутреннем уровне называется внутренней схемой или схемой хранения.

Внешний уровень архитектуры БД предназначен для групп пользователей. Описание представления данных для группы пользователей называется внешней схемой. Наличие внешнего уровня позволяет поддерживать разное представление одних и тех же данных для различных групп пользователей или задач [6].

Подсхема базы данных – это описание структуры данных прикладного программиста.

Каждый из этих уровней может считаться управляемым, если он обладает внешним интерфейсом, который обеспечивает возможности определения данных. В этом случае становится возможными формирование и системная поддержка независимого взгляда на БД для какой-либо группы персонала или пользователей, взаимодействующих с БД через интерфейс данного уровня.

В архитектурной модели ANSI/SPARC предполагается наличие в СУБД механизмов, обеспечивающих междууровневое отображение данных «внешний – концептуальный» и «концептуальный – внутренний». Функциональные возможности этих механизмов определяют степень независимости данных на всех уровнях. На переходе «внешний – концептуальный» обеспечивается логическая независимость данных, на переходе «концептуальный – внутренний» – физическая независимость. Под логической независимостью подразумевается возможность вносить изменения в концептуальный уровень, не меняя представление БД для пользователей, или изменять представление данных для пользователей без изменения концептуальной схемы. Физическая независимость данных подразумевает возможность вносить изменения в схему хранения, не меняя концептуальную схему БД.

Основной характеристикой баз данных является совместное использование данных многими пользователями АИС. Должно существовать какое-то общее понимание информации, представленной данными. Общее понимание должно относиться к чему-либо внешнему по отношению к пользователям, и оно должно быть зафиксировано. Для этого необходима некоторая предварительно определённая грамматика, которую принято называть моделью данных.

Модели данных

Модель данных является инструментом моделирования произвольной предметной области.

Понятие модели данных

Модель данных – это совокупность правил порождения структур данных в базе данных, операций над ними, а также ограничений целостности, определяющих допустимые связи и значения данных, последовательность их изменения [6]. Итак, модель данных состоит из трёх частей:

Здесь можно провести аналогию с языками программирования, в которых тоже есть предопределённые типы структур данных, такие как скалярные данные, вектора, массивы, структуры (например, тип struct в языке Си) и т.д.

Такими операциями являются: создание и модификация структур данных, внесение новых данных, удаление и модификация существующих данных, поиск данных по различным условиям.

Правила целостности определяются типом данных и предметной областью. Например, значение атрибута Счётчик является целым числом, т.е. может состоять только из цифр. А ограничения предметной области таковы, что это число не может быть меньше нуля.

Теперь рассмотрим подробнее наборы, составляющие модель данных.

Типы структур данных

Структуризация данных базируется на использовании концепций «агрегации» и «обобщения». Один из первых вариантов структуризации данных был предложен Ассоциацией по языкам обработки данных (Conference on Data Systems Languages, CODASYL) (рис. 2.1).

Рис.2.1 Композиция структур данных по версии CODASYL

Элемент данных – наименьшая поименованная единица данных, к которой СУБД может обращаться непосредственно и с помощью которой выполняется построение всех остальных структур. Для каждого элемента данных должен быть определён его тип.

Агрегат данных – поименованная совокупность элементов данных внутри записи, которую можно рассматривать как единое целое. Агрегат может быть простым (включающим только элементы данных, рис. 2.2,а) и составным (включающим наряду с элементами данных и другие агрегаты, рис. 2.2,б).

Рис.2.2 Примеры агрегатов: а) простой и б) составной агрегат

Запись – поименованная совокупность элементов данных или эле-ментов данных и агрегатов. Запись – это агрегат, не входящий в состав никакого другого агрегата; она может иметь сложную иерархическую структуру, поскольку допускается многократное применение агрегации. Различают тип записи (её структуру) и экземпляр записи, т.е. запись с конкретными значениями элементов данных. Одна запись описывает свойства одной сущности ПО (экземпляра). Иногда термин «запись» за-меняют термином «группа».

Пример записи, содержащей сведения о сотруднике, приведён на рис. 2.3.

Рис.2.3 Пример записи типа СОТРУДНИК

Эта запись имеет несколько элементов данных (Номер пропуска, Должность, Пол и т.д.) и три агрегата: простые агрегаты ФИО и Адрес и повторяющийся агрегат Телефоны. (Повторяющийся агрегат может включаться в запись произвольное число раз).

Среди элементов данных (полей записи) выделяются одно или несколько ключевых полей. Значения ключевых полей позволяют классифицировать сущность, к которой относится конкретная запись. Ключи с уникальными значениями называются потенциальными. Каждый ключ может представлять собой агрегат данных. Один из ключей назначается первичным, остальные являются вторичными. Первичный ключ идентифицирует экземпляр записи, его значение должно быть уникальным и обязательным для записей одного типа. Для примера на рис. 2.3 потенциальными ключами являются поля № пропуска и Паспорт, а первичным ключом целесообразнее выбрать поле № пропуска, т.к. оно явно занимает меньше памяти, чем паспортные данные.

Набор (или групповое отношение) – поименованная совокупность записей, образующих двухуровневую иерархическую структуру. Каждый тип набора представляет собой связь между двумя или несколькими типами записей. Для каждого типа набора один тип записи объявляется владельцем набора, остальные типы записи объявляются членами набора. Каждый экземпляр набора должен содержать только один экземпляр записи типа владельца и столько экземпляров записей типа членов набора, сколько их связано с владельцем. Для группового отношения также различают тип и экземпляр.

Групповые отношения удобно изображать с помощью диаграммы Бахмана, которая названа так по имени одного из разработчиков сетевой модели данных. Диаграмма Бахмана – это ориентированный граф, вершины которого соответствуют группам (типам записей), а дуги – групповым отношениям (рис. 2.4).

Рис. 2.4 Пример диаграммы Бахмана для фрагмента БД «Город»

Здесь запись типа ПОЛИКЛИНИКА является владельцем записей типа ЖИТЕЛЬ и они связаны групповым отношением диспансеризация. Запись типа ОРГАНИЗАЦИЯ также является владельцем записей типа ЖИТЕЛЬ и они связаны групповым отношением работают. Записи типа РЭУ и типа ЖИТЕЛЬ являются владельцами записей типа КВАРТИРА с отношениями соответственно обслуживают и проживают. Таким образом, запись одного и того же типа может быть членом одного отношения и владельцем другого.

База данных – поименованная совокупность экземпляров групп и групповых отношений. Это самый высокий уровень структуризации данных.

Примечание: структуризация данных по версии CODASYL используется в сетевой и иерар-хической моделях данных. В реляционной модели принята другая структуризация данных, основанная на теории множеств.

Операции над данными

Модель данных определяет множество действий, которые допустимо производить над некоторой реализацией БД для её перевода из одного состояния в другое. Это множество соотносят с языком манипулирования данными (Data Manipulation Language, DML).

Любая операция над данными включает в себя селекцию данных (select), то есть выделение из всей совокупности именно тех данных, над которыми должна быть выполнена требуемая операция, и действие над выбранными данными, которое определяет характер операции. Условие селекции – это некоторый критерий отбора данных, в котором могут быть использованы логическая позиция элемента данных, его значение и связи между данными.

По типу производимых действий различают следующие операции:

Обработка данных в БД осуществляется с помощью процедур базы данных – транзакций. Транзакцией называют упорядоченное множество операций, переводящих БД из одного согласованного состояния в другое. Транзакция либо выполняется полностью, т.е. выполняются все входящие в неё операции, либо не выполняется совсем, если в процессе её выполнения возникает ошибка.

Ограничения целостности

Ограничения целостности – это правила, которым должны удовлетворять значения элементов данных. Ограничения целостности делятся на явные и неявные.

Неявные ограничения определяются самой структурой данных. Например, тот факт, что запись типа СОТРУДНИК имеет поле Дата рождения, служит, по существу, ограничением целостности, означающим, что каждый сотрудник организации имеет дату рождения, причём только одну.

Явные ограничения включаются в структуру базы данных с помощью средств языка контроля данных (DCL, Data Control Language). В качестве явных ограничений чаще всего выступают условия, накладываемые на значения данных. Например, номер паспорта является уникальным, заработная плата не может быть отрицательной, а дата приёма сотрудника на работу обязательно будет меньше, чем дата его перевода на другую работу.

Также различают статические и динамические ограничения целостно-сти. Статические ограничения присущи всем состояниям ПО, а динамические определяют возможность перехода ПО из одного состояния в другое. Примерами статических ограничений целостности могут служить требование уникальности индивидуального номера налогоплательщика (ИНН) или задание ограниченного множества значений атрибута «Пол» (‘м’ и ‘ж’). В качестве примера динамического ограничения целостности можно привести правило, которое распространяется на поля-счётчики: значение счётчика не может уменьшаться.

За выполнением ограничений целостности следит СУБД в процессе своего функционирования. Она проверяет ограничения целостности каждый раз, когда они могут быть нарушены (например, при добавлении данных, при удалении данных и т.п.), и гарантирует их соблюдение. Если какая-либо команда нарушает ограничение целостности, она не будет выполнена и система выдаст соответствующее сообщение об ошибке. Например, если задать в качестве ограничения правило «Остаток денежных средств на счёте не может быть отрицательным», то при попытке снять со счёта денег больше, чем там есть, система выдаст сообщение об ошибке и не позволит выполнить эту операцию. Таким образом, ограничения целостности обеспечивают логическую непротиворечивость данных при переводе БД из одного состояния в другое.

В настоящее время разработано много различных моделей данных. Основные – это сетевая, иерархическая и реляционная модели.

Сетевая модель данных (СМД)

Сетевая модель позволяет организовывать БД, структура которых представляется графом общего вида (пример СМД – на рис. 2.4). Организация данных в сетевой модели соответствует структуризации данных по версии CODASYL. Каждая вершина графа хранит экземпляры сущностей (записи одного типа) и сведения о групповых отношениях с сущностями других типов. Каждая запись может хранить произвольное количество значений атрибутов (элементов данных и агрегатов), характеризующих экземпляр сущности. Для каждого типа записи выделяется первичный ключ – атрибут, значение которого позволяет однозначно идентифицировать запись среди экземпляров записей данного типа.

Связи между записями в СМД выполняются в виде указателей, т.е. каждая запись хранит ссылку на другую однотипную запись (или признак конца списка) и ссылки на списки подчинённых записей, связанных с ней групповыми отношениями. Таким образом, в каждой вершине записи хранятся в виде связного списка. Если список организован как однонаправленный, запись имеет ссылку на следующую однотипную запись в списке; если список двунаправленный – то на следующую и предыдущую однотипные записи.

Групповые отношения характеризуются следующими признаками:

Поддерживаются три способа упорядочения:

Режим включения бывает автоматический и ручной.

При автоматическом режиме подчинённая запись связана с записью-владельцем обязательной связью, поэтому она включается в групповое отношение и прикрепляется к записи-владельцу в момент внесения в БД. (Из этого следует, что запись-владелец должна быть внесена в базу данных до внесения первого экземпляра подчинённой записи.)

При ручном режиме включения подчинённая запись может находиться в БД и не быть прикрепленной к записи-владельцу. Она вручную включается в групповое отношение тогда, когда это отношение (связь) возникает.

Режим исключения определяется классом членства. Различают три класса членства – фиксированный, обязательный и необязательный:/p>

Рассмотрим фрагмент БД «Предприятие» (рис. 2.5). Здесь записи типов ОТДЕЛЫ и ОРГАНИЗАЦИИ-ЗАКАЗЧИКИ являются владельцами записей типа ПРОЕКТЫ и они связаны групповыми отношениями соответственно выполняют и заказывают. Записи типов ОТДЕЛЫ и ПРОЕКТЫ являются владельцами записей типа СОТРУДНИКИ и они связаны групповыми отношениями работают и выполняются. Записи типа СОТРУДНИКИ являются владельцами записей типа ДЕТИ.

Рис. 2.5. Пример фрагмента сетевой БД «Предприятие»

Групповые отношения чаще всего описывают связь «один-ко-многим»: один владелец, много подчинённых. Например, отношение работают подразумевает, что каждый сотрудник работает в одном отделе, но в каждом отделе могут работать несколько сотрудников. С другой стороны, групповое отношение выполняются отражает связь «многие-ко-многим»: каждый сотрудник может участвовать в выполнении нескольких проектов, каждый проект могут выполнять несколько человек. Что касается классов членства подчинённых записей, то связь «сотрудники–дети» относится к фиксированному классу членства, связь «сотрудники–проекты» – к необязательному, а все остальные – к обязательному классу членства. Режим включения для связи «сотрудники–проекты» ручной, для всех остальных – автоматический.

В СМД связи 1:n между разными сущностями реализуются с помощью групповых отношений, а связи 1:n между атрибутами сущности – в рамках записи. Для реализации связей типа n:m вводится вспомогательный тип записи и две связи 1:n.

В СМД применяются следующие операции над данными:

В сетевой модели данных предусмотрены специальные способы навига-ции и манипулирования данными. Аппарат навигации в графовых моделях служит для установления тех записей, к которым будет применяться очередная операция манипулирования данными. Такие записи называются текущими. В СМД возможны переходы:

Навигация в СМД может начинаться с любой записи.

Наиболее распространенной и стандартизованной из реализаций СМД является модель CODASYL. В соответствии с ней описание схемы БД осуществляется на языке COBOL, а манипулирование данными – с помощью включающего языка программирования высокого уровня. Примером се-тевой СУБД является система Integrated Database Management System (IDMS).

СМД является наиболее полной с точки зрения реализации различных типов связей и ограничений целостности, но она является достаточно сложной для проектирования и поддержки. В этой модели не обеспечивается физическая независимость данных, т.к. наборы организованы с помощью физических ссылок. Также в СМД не обеспечивается независимость данных от программ. Из-за этих недостатков эта модель не получила широкого распространения.

Иерархическая модель данных (ИМД)

Иерархическая модель позволяет строить БД с иерархической древовидной структурой. Структура ИМД описывается в терминах, аналогичных терминам сетевой модели данных (версия CODASYL). Группу в ИМД принято называть сегментом. В основе ИМД лежит понятие дерева.

Дерево – это связный неориентированный граф, который не содержит циклов. При работе с деревом выделяют какую-то конкретную вершину, определяют её как корень дерева и рассматривают особо – в эту вершину не заходит ни одно ребро. В этом случае дерево становится ориентированным, ориентация определяется от корня. Дерево как ориентированный граф определяется так:

Конечные вершины, то есть вершины, из которых не выходит ни одной дуги, называются листьями дерева. Количество вершин на пути от корня к листьям в разных ветвях дерева может быть различным.

В иерархических моделях данных используется ориентация древо-видной структуры от корня к листьям. Графическая диаграмма концептуальной схемы базы данных называется деревом определения. Пример иерархической базы данных приведён на рис. 2.6. Каждая некорневая вершина в ИМД связана с родительской вершиной (сегментом) иерархическим групповым отношением. Каждая вершина дерева соответствует типу сущности ПО. Тип сущности характеризуется произвольным количеством атрибутов, связанных с ней отношением 1:1. Атрибуты, связанные с сущностью отношением 1:n, образуют отдельную сущность (сегмент) и переносятся на следующий уровень иерархии. Реализация связей типа n:m не поддерживается.

Рис. 2.6. Пример фрагмента иерархической базы данных

Тип вершины определяется типом сущности и набором её атрибутов. Каждая вершина дерева хранит экземпляры сущностей – записи. Следствием внутренних ограничений иерархической модели является то, что каждому экземпляру зависимой группы в БД соответствует уникальное множество экземпляров родительских записей – по одному экземпляру (записи) каждого типа вершин вышестоящих уровней.

По сравнению с СМД иерархическая имеет ограниченный набор режимов включения и исключения подчинённых записей. Это определяется обязательностью связей: в дереве не может быть «висячих» вершин, не связанных с вершиной верхнего уровня (кроме корневой). Поэтому ИМД не поддерживает необязательный класс членства и ручной режим включения записей.

В ИМД предусмотрены специальные способы навигации. Передвижение по дереву всегда начинается с корневой вершины, от которой можно перейти на конкретный экземпляр записи любой вершины следующего уровня. Эта вершина становится текущей вершиной, а экземпляр – текущей записью. От этой записи можно перейти к другой записи данной вершины, к экземпляру записи родительской вершины или к экземпляру записи подчинённой вершины. Т.о., попасть в любую вершину можно, только проделав полный путь по дереву от корня. Связи между записями в ИМД обычно выполнены в виде ссылок (т.е. хранятся адреса связанных записей).

Корневая запись дерева должна содержать ключ с уникальным значением. Ключи некорневых записей должны иметь уникальные значения только в экземплярах групповых отношений, т.е. на одном и том же уровне иерархии в разных ветвях дерева могут быть экземпляры записей с одинаковыми ключами. Это объясняется тем, что каждая запись идентифицируется полным сцепленным ключом, который образуется путём конкатенации всех ключей экземпляров родительских записей. Например, для студента (рис. 2.6) ключ – это (Шифр_факультета+Номер_курса+Номер_группы+Номер_зачётной_книжки).

Основным недостатком ИМД является дублирование данных. Оно вызвано тем, что каждая сущность (атрибут) может относиться только к одной родительской сущности. Например, если в БД хранятся данные о детях сотрудников, а на предприятии работает и отец, и мать ребёнка, то сведения об этом ребёнке нужно хранить дважды. Аналогичная ситуация возникает, если нужно отразить в БД связь «многие-ко-многим». Дублирование данных может вызвать нарушение логической целостности БД при внесении изменений в эти данные.

Если данные имеют естественную древовидную структуризацию, то ис-пользование иерархической модели данных не вызывает проблем. Но на практике часто требуется реализовать структуры данных, отличные от иерархической. Для решения этих задач конкретные СУБД, основанные на ИМД, включают дополнительные средства, облегчающие представление произвольно организованных данных.

В качестве примера типичного представителя иерархических СУБД можно привести систему IMS (Information Management System, IBM).

Сетевая и иерархическая модели данных относятся к базам данных I-го поколения (60-е – начало 70-х гг. XX века). Эти модели не смогли в полной мере реализовать независимость данных от программ. Из-за особенностей их организации структура запросов к данным в таких системах определяется наличием связей между записями.

Следующее, II-е поколение баз данных основано на реляционной модели.

Реляционная модель данных (РМД)

Понятие отношения

Реляционная модель данных была предложена в 1970 г. математиком Эдгаром Коддом (Codd E.F.). РМД является наиболее широко распространенной моделью данных и единственной из трёх основных моделей данных, для которой разработан теоретический базис с использованием теории множеств.

Базовой структурой РМД является отношение, основанное на декарто-вом произведении доменов. Домен – это множество значений, которое может принимать элемент данных (например, множество целых чисел, множество дат, множество комбинаций символов длиной N и т.п.). Домен может задаваться перечислением элементов, указанием диапазона значений, функцией и т.д.

Таким образом, декартово произведение позволяет получить все возможные комбинации значений элементов исходных множеств.

Пример. Для доменов D₁ = (1, 2), D₂ = (A, B, C) декартово произведение D = D₁×D₂ будет таким: D =

Отношение содержит данные о сущностях определённого типа. Поясним это на примере. Если построить произведение трёх доменов Должности (‘директор’, ‘бухгалтер’, ‘водитель’, ‘продавец’), Оклады (x | 20000?x?80000), Надбавки (1.1, 1.2, 1.3), то мы получим 4*60001*3=720012 комбинаций. Но реально отношение «Штатное расписание» содержит по одной строке на каждую должность, т.е. является именно подмножеством декартова произведения доменов.

Элементы отношения называют кортежами (или записями). Каждый кортеж отношения соответствует одному экземпляру сущности определённого типа. Элементы кортежа принято называть атрибутами (или полями).

Схема отношения

Отношение обладает двумя основными свойствами:

Таким образом, в отношении не бывает первого, второго или последнего кортежа: при выводе данных отношения кортежи выводятся в произвольном порядке, если не задано упорядочение по значениям полей.

Отношение удобно представлять как таблицу, где строка является кортежем, а столбец соответствует домену (рис. 2.7, отношение СТУДЕНТЫ). Количество строк в таблице (кортежей в отношении) называется мощностью отношения, количество столбцов (атрибутов) – арностью.

Рис.2.7. Пример табличной формы представления отношения

Отношение имеет имя, которое отличает его от имён всех других отно-шений. Атрибутам реляционного отношения назначаются имена, уникальные в рамках отношения. Обращение к отношению происходит по его имени, а обращение к атрибуту – по имени отношения и имени атрибута.

Каждый атрибут определён на некотором домене, несколько атрибутов отношения могут быть определены на одном и том же домене (например, номера рабочего и домашнего телефонов). Домен задаётся типом данных, размером и ограничениями целостности: например, пол – это символьное поле длиной 1, которое может принимать значения из множества (‘м’, ‘ж’). В реляционных базах данных поддерживаются такие типы данных как символьный, числовой, дата и некоторые другие (конкретный перечень типов зависит от СУБД).

Атрибут может быть обязательным и необязательным. Значение обяза-тельного атрибута должно быть определено в момент внесения данных в БД. Если атрибут необязательный, то для таких случаев предусмотрено специальное значение – NULL, которое можно интерпретировать как «неизвестное значение». Значение NULL не привязано к определённому типу данных, т.е. может назначаться данным любых типов.

Перечень атрибутов отношения с их типами данных и размерами определяют схему отношения. Отношения, построенные по одинаковой схеме, называют односхемными; по различным схемам – разносхемными.

Ключ отношения – это атрибут (группа атрибутов), значения которого классифицируют или идентифицируют кортеж. Например, значение атрибута Группа отношения СТУДЕНТЫ позволяет выделить среди всех студентов института студентов конкретной группы. Если ключ состоит из нескольких атрибутов, он называется составным. Если значения ключа уникальны в рамках столбца отношения, то такой ключ называется потенциальным. Потенциальных ключей может быть несколько (или не быть ни одного), но для отношения выделяется один основной ключ – первичный. Первичный ключ идентифицирует экземпляр сущности, его значение должно быть уникальным (unique) и обязательным (not null). (На рис. 2.7 первичный ключ выделен полужирным шрифтом). Неуникальные ключи ещё называют вторичными.

РМД не поддерживает групповые отношения (по версии CODASYL). Для связей между отношениями используются внешние ключи. Внешний ключ (foreign key) – это атрибут подчинённого (дочернего) отношения, который является копией первичного (primary key) или уникального (unique) ключа родительского отношения. (Пример – отношение ОЦЕНКИ, связанное с отношением СТУДЕНТЫ внешним ключом Номер зачётной книжки, рис. 2.8).

Рис.2.8. Связь отношений «Оценки» и «Студенты» по внешнему ключу

Если связь необязательная, то значение внешнего ключа может быть неопределённым (null).

Фактически внешние ключи логически связывают экземпляры сущно-стей разных типов (родительской и подчинённой сущностей).

Внешний ключ – это ограничение целостности, в соответствии с которым множество значений внешнего ключа является подмножеством значений первичного или уникального ключа родительской таблицы.

Ограничение целостности по внешнему ключу проверяется в двух случаях:

Примечание: внешний ключ может ссылаться на первичный ключ этой же таблицы. Это позволяет описывать унарную связь – иерархию однотипных сущностей. Например, если в таблицу СОТРУДНИКИ добавить поле Руководитель и описать его как внешний ключ на эту же таблицу, то в этом поле будет храниться идентификатор руководителя данного сотрудника (рис. 2.9). Атрибут Руководитель является необязательным.

Рис.2.9. Внешний ключ «Руководитель», ссылающийся на первичный ключ этой же таблицы

Все операции над данными в РМД выполняются над отношением и тре-буют задания имени отношения. Если операция применяется к части отноше-ния, то может потребоваться идентификация кортежа или группы кортежей и задание имён атрибутов. В РМД используются следующие операции:

Структуризация данных в РМД существенно отличается от структуризации данных по версии CODASYL (см. табл. 2.1).

Таблица 2.1. Сравнение структуризации данных в РМД и по версии CODASYL

Примечание: в реляционной модели данных набор (групповое отношение) моделируется с помощью внешнего ключа, описывающего связь между двумя таблицами.

Механическое удерживание земляных масс: Механическое удерживание земляных масс на склоне обеспечивают контрфорсными сооружениями различных конструкций.

Поперечные профили набережных и береговой полосы: На городских территориях берегоукрепление проектируют с учетом технических и экономических требований, но особое значение придают эстетическим.

Источник