
- •Уровни представления данных в бд
- •Языки баз данных
- •Логическая структура данных
- •Операции над данными
- •10. Иерархическая модель данных
- •Реляционная модель данных
- •Основные понятия реляционной модели данных
- •Таким образом, отношение - это совокупность кортежей, т.Е. Таблица со всеми своими строками.
- •Ключи отношений
- •Поставщик изделие
- •Первичный ключ никогда не должен принимать нулевого значения, а в составном ключе ни одна из компонент никогда не должна быть нулевой.
- •Контроль ссылочной целостности
- •Нормализация отношений реляционной бд
- •Первая нормальная форма
- •Поставки1 поставки
- •Поставщик1 поставки
- •Операции над отношениями
- •Теоретико-множественные операции
- •Запрос 4
- •Язык sql - общие сведения
- •Язык запросов qbe
- •Запрос 1
- •Запрос 2
Логическая структура данных
Концептуальная схема БД содержит три составляющих:
- логическую структуру данных,
- ограничения, накладываемые на данные,
- операции с данными.
Основой концептуальной схемы БД является логическая структура данных. Именно с ее разработки начинается создание любой БД.
Для того чтобы построить логическую структуру данных вначале необходимо тщательно изучить предметную область и определить круг задач, для решения которых создается БД. На основании этого исследования выявляются объекты предметной области и их свойства, устанавливаются связи, существующие между объектами в предметной области.
Все объекты предметной области и существующие между ними связи отображаются в логической структуре данных.
Любой объект описывается следующей триадой:
<Имя объекта, Свойства объекта, Значения свойств>
Различают два понятия: тип объекта и экземпляр объекта.
Тип объекта характеризуется первыми двумя компонентами триады. Для свойств устанавливаются имена. Например, имя объекта - СТУДЕНТ, свойства объекта: ФИО, ГРУППА, СРЕДНИЙ БАЛЛ и т.п.
В теории БД понятие тип объекта часто заменяют понятием сущность. Следует помнить, что эти понятия относятся к предметной области.
Конкретные значения свойств определяют конкретный экземпляр объекта данного типа. Например: ФИО - Иванов И.И., ГРУППА - 037, СРЕДНИЙ БАЛЛ - 4,5.
В СУБД понятию тип объекта соответствует тип записи, при этом имя объекта часто рассматривается как имя записи. Свойства объекта являются полями записи, каждое поле имеет имя соответствующего свойства. Экземпляру объекта соответствует экземпляр записи, значения каждого свойства хранятся в соответствующем поле.
Между отдельными объектами, а также между свойствами объектов в предметной области могут существовать связи 1:1, 1:М, М:М. Эти связи должны быть отражены в логической структуре данных.
Пусть требуется разработать фрагмент БД, содержащей сведения о студентах одной из кафедр ВУЗа; о дисциплинах, изучаемых студентами и преподавателях, читающих эти дисциплины. При разработке логической структуры данных определим следующие объекты и их свойства:
СТУДЕНТ (№ зачетной книжки, ФИО, Группа, Средний балл);
ПРЕПОДАВАТЕЛЬ (ФИО_П, Должность);
ПРЕДМЕТ (Наименование, Часы, Отчетность).
Проанализируем связи, существующие между объектами в предметной области.
К
аждый
студент учится у многих преподавателей,
а каждый преподаватель обучает многих
студентов. Между этими объектами
существует связь М:М. Наличие двусторонней
множественной связи усложняет модель
данных и без необходимости эту связь
вводить в модель не следует. В данном
случае эта связь необходима, так как
предполагается, что в системе могут
быть запросы, направленные от преподавателя
к студенту и наоборот. Это значит, что
может потребоваться информация о
преподавателях, обучающих конкретного
студента, или о студентах, обучающихся
у данного преподавателя.
М
ежду
объектами СТУДЕНТ и ПРЕДМЕТ также
существует двусторонняя множественная
связь. Но в этом случае связь, направленную
от объекта ПРЕДМЕТ к объекту СТУДЕНТ в
модель данных вводить не будем, так как
предполагается, что запросов, направленных
от предмета к студенту не будет.
М
ежду
объектами ПРЕПОДАВАТЕЛЬ и ПРЕДМЕТ
существует двусторонняя множественная
связь. Учитывая, что возможны запросы
от преподавателя к предмету и наоборот,
эту связь введем в модель данных.
В концептуальной схеме эти связи отображаются соответствующей моделью данных. Связи 1:М отображаются иерархической или, иначе, древовидной моделью, а связи М:М – сетевой или графовой моделью. Существуют СУБД, поддерживающие эти модели данных: иерархические и сетевые СУБД. Однако такие СУБД разрабатывались для использования их на больших ЭВМ.
Подавляющее большинство СУБД для персональных ЭВМ поддерживают реляционную модель данных. Существуют приемы, позволяющие преобразовать иерархическую и сетевую модели в реляционную.
Теперь необходимо проанализировать связи, существующие между свойствами объектов. В процессе такого анализа для каждого из свойств определяется тип связи, существующий между данным свойством и каждым из прочих свойств объекта.
Так, например, можно установить, что для объекта СТУДЕНТ между свойством № зачетной книжки и каждым из прочих свойств существует связь 1:1. Это значит, что каждому конкретному номеру зачетной книжки соответствует единственное значение свойств ФИО, Группа и Средний балл, т.е. конкретный номер зачетной книжки уникальным образом идентифицирует конкретный экземпляр объекта типа СТУДЕНТ. В самом деле, каждый из студентов имеет зачетную книжку с уникальным номером.
В дальнейшем мы узнаем, что такое свойство можно выбрать в качестве первичного ключа для записи типа СТУДЕНТ.
Подобный анализ необходимо провести для каждого из свойств. Если обнаружится, что еще какое-либо из свойств объекта находится в связи 1:1 с одним или несколькими свойствами этого же объекта, возможно, что совокупность этих свойств принадлежит объекту другого типа. Рассматриваемый объект придется разделить на два объекта, каждый из которых имеет собственный первичный ключ.
Например, если для объекта СТУДЕНТ определить еще одно свойство Специальность, то можно убедиться, что между этим свойством и свойством Группа существует связь 1:1. Эти свойства придутся выделить в отдельный объект.
Таким образом, если определены типы объектов (т.е. имена объектов и имена свойств объектов), типы связей между объектами и связи между атрибутами объектов, то определена логическая структура данных. На основании логической структуры данных определяется модель данных (сетевая, иерархическая, реляционная). Модель данных преобразуется в схему БД, а затем описывается на ЯОД.
Ограничения, накладываемые на данные
В логической структуре данных невозможно исчерпывающим образом описать все свойства объектов предметной области. Так в логической структуре нельзя задать условия, которым должны отвечать значения некоторых свойств. Так, например, значения среднего балла не должны быть меньше 3.0 и больше 5.0. Номера студенческих групп также формируются по определенным правилам: первая цифра – год поступления, вторая цифра – факультет, следующие цифры – специальность.
Для повышения семантики логической структуры данных вводятся ограничения, накладываемые на данные или, иначе, ограничения целостности данных. Такие ограничения позволяют поддерживать целостность данных. Выполняемость ограничений проверяет СУБД. Контроль выполнения ограничений может производиться при вводе данных, после выполнения каждой операции ведения, после завершения транзакции.
Возможно определения различных типов ограничений.
Ограничения, накладываемые на значения свойств объектов, относятся к логическому типу.
Внутренние ограничения накладываются самой моделью данных. Так, например, для иерархической модели обязательным является следующее ограничение: у каждого порожденного объекта может быть единственный порождающий объект.
Статические ограничения выражают правила, которые определяют допустимые (достоверные) состояния БД. Эти правила называют законами БД. Для записи законов обычно используется математический аппарат исчисления предикатов. Закон записывается в виде высказывания относительно свойств отдельных полей записей БД. При проверке целостности БД в формулу высказывания подставляются значения соответствующих полей. Состояние БД считается допустимым, если при всех подстановках высказывание остается истинным.
Динамические ограничения определяют допустимые переходы БД из одного состояния в другое.