ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 22.11.2023
Просмотров: 82
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Кроме первичного ключа в таблице могут быть вторичные ключи, называемые еще внешними ключами, или индексами. Индекс – это поле или совокупность полей, чьи значения имеются в нескольких таблицах и которое является первичным ключом в одной из них. Значения индекса могут повторяться в некоторой таблице. Индекс обеспечивает логическую последовательность записей в таблице, а также прямой доступ к записи.
По первичному ключу всегда отыскивается только одна строка, а по вторичному – может отыскиваться группа строк с одинаковыми значениями первичного ключа. Ключи нужны для однозначной идентификации и упорядочения записей таблицы, а индексы для упорядочения и ускорения поиска.
Индексы можно создавать и удалять, оставляя неизменным содержание записей реляционной таблицы. Количество индексов, имена индексов, соответствие индексов полям таблицы определяется при создании схемы таблицы.
Индексы позволяют эффективно реализовать поиск и обработку данных, формирую дополнительные индексные файлы. При корректировке данных автоматически упорядочиваются индексы, изменяется местоположение каждого индекса согласно принятому условию (возрастанию или убыванию значений). Сами же записи реляционной таблицы не перемещаются при удалении или включении новых экземпляров записей, изменении значений их ключевых полей.
С
помощью индексов и ключей устанавливаются связи между таблицами. Связь устанавливается путем присвоения значений внешнего ключа одной таблицы значениям первичного ключа другой. Группа связанных таблиц называется схемой данных (рис. 8). Информация о таблицах, их полях, ключах и т.п. называется метаданными.
Рис. 8. Схема данных в СУБД Microsoft Access
Первичный ключ любой таблицы должен содержать уникальные (не повторяющиеся) непустые значения для данной таблицы. Система управления базой данных должна контролировать уникальность первичных ключей. При попытке присвоить первичному ключу значение, уже имеющееся в другой записи таблицы, выдается сообщение об ошибке первичного ключа.
С появлением ПЭВМ реляционные системы стали доминировать среди систем баз данных. Быстрому распространению реляционных моделей способствовало три фактора.
Во-первых, в реляционной системе данные представляются в виде таблиц (отношений), встречающихся в повседневной практике. Поиск и обработка данных в этих таблицах не зависит от их организации и хранения в памяти машины.
Во-вторых, с математической точки зрения реляционная база – это конечный набор отношений. Таким образом, теория реляционных баз данных становится областью математической логики и реляционной алгебры.
В-третьих, множество объектов реляционной модели данных однородно – структура данных определяется только в терминах отношений. Основная единица обработки в операциях реляционной модели данных не запись (как в сетевых и иерархических моделях данных), а множество записей, то есть отношение.
В нереляционных базах данных сложно передать все имеющиеся зависимости, то есть связать друг с другом данные из различных таблиц. Реляционная база данных выполняет все эти действия достаточно просто. Благодаря имеющимся связям в реляционных базах удается избежать дублирования информации, что облегчает работу и позволяет избежать ошибок. В реляционных базах данных также удается легко избежать установления ошибочных связей между различными таблицами данных.
В реляционных базах данных легко производить изменения. Например, если в таблице клиентов изменить адрес конкретного клиента, то соответствующая информация автоматически поступит в другие таблицы, связанные с таблицей клиентов.
Таким образом, достоинства реляционных баз данных можно сформулировать так.
• Упрощенная схема представления данных – в виде таблицы.
• Простота инструментальных средств поддержки реляционной модели.
• Оптимизация доступа к базе данных, поскольку системы сами выбирают наиболее эффективную последовательность действий.
• Улучшение целостности и защиты, поскольку реляционная модель позволяет улучшить выражение требований целостности путем использования языка высокого уровня.
• Возможности различных применений, в том числе и рассчитанных на неспециалистов в области программирования.
• Обеспечение пользователя языками высокого уровня при работе с базой данных.
• Обеспечение методологического подхода, поскольку главной целью модели базы данных является возможность описания реального мира, что проще всего осуществляется в реляционной модели.
Недостаток реляционной модели – в жесткости структуры данных, например, невозможно задать строку таблицы произвольной длины, а также сложность описания иерархических и сетевых связей.
В настоящее время многие известные системы управления базами данных используют именно реляционную модель представления данных –это dBase, FoxBase, FoxPro, Paradox, Oracle, Microsoft Access, Clarion, Clipper, Ingres; отечественные: ПАЛЬМА, HyTech и др.
2 вопрос: Постреляционная модель. Объектно-ориентированная модель. Объектно-реляционная модель. Многомерная модель.
Стройность и мощность реляционных моделей сделали их доминирующими в среде баз данных. Но постоянное усложнение данных позволило выявить ряд неудобств, возникающих при работе с реляционными базами:
•Реляционные системы ограничены в структурах представления данных, так как все данные хранятся в них в виде отношений, состоящих из простых атрибутов. Классическая реляционная модель предполагает неделимость данных, хранящихся в полях таблицы, то есть информация в таблице должна быть представлена в первой нормальной форме. Однако на практике иногда возникают ситуации, когда такое ограничение снижает эффективность работы с базой.
•Данные в реляционной системе пассивны, и для описания их поведения требуется создавать прикладные программы.
•Возможности реляционных баз данных недостаточны в тех случаях, когда объекты данных сложны, например: географические информационные системы, мультимедийные базы, базы с проектной документацией и др.
Все эти требования можно реализовать с помощью реляционных методов, но в результате получается не очень естественное представление требований пользователя.
Постреляционная модель
Постреляционная модель является расширением реляционной модели. Она снимает ограничение неделимости данных, допуская многозначные поля, значения которых состоят из подзначений, и набор значений воспринимается как самостоятельная таблица, встроенная в главную таблицу.
Сопоставим реляционную и постреляционную модели данных на примере. В таблицах 1 и 2 отражена поставка товара в реляционной базе, а в таблице 3 – в постреляционной.
Т
аблица 1
Т
аблица 2
Т
аблица 3
Как видно из приведенного примера, в постреляционной базе данные хранятся более компактно, и не требуется выполнять операции связи двух таблиц. Такое хранение обеспечивает высокую наглядность представления данных и повышение эффективности их обработки.
Спецификой постреляционной модели является то, что она поддерживает множественные группы, называемые ассоциированными множественными полями, а совокупность объединенных множественных полей называется ассоциацией, например, в постреляционной модели может присутствовать множественное поле Выпуск, состоящее из полей, указывающих выпуск по кварталам года. В постреляционной модели не накладываются требования на длину и количество полей в записях, что делает структуру таблиц более наглядной.
Таким образом, основным достоинством постреляционной модели является возможность представления совокупности связанных реляционных таблиц в виде одной постреляционной таблицы. А недостатком является сложность обеспечения целостности и непротиворечивости данных, хранимых в ней.
Постреляционная модель данных реализована в СУБД uniVers, Bubba и Dasdb.
Объектно-ориентированная модель
Объектно-ориентированная модель представляет структуру, которую можно изобразить графически в виде дерева, узлами которого являются объекты (рис. 9). Между записями базы данных и функциями их обработки устанавливаются связи с помощью механизмов, подобных тем, которые имеются в объектно-ориентированных языках программирования. Такая модель позволяет идентифицировать отдельные записи базы. Определяемый пользователем объект называют объектом-целью. Поиск в объектно-ориентированной базе
состоит в выяснении сходства между объектом, задаваемым пользователем, и объектами, хранящимися в базе.
Б
азовыми понятиями этой модели являются следующие: объекты, классы, методы, инкапсуляция, наследование, полиморфизм.
Рис. 9. Объектно-ориентированная база данных
Понятие объекта взято из объектно-ориентированного программирования. В этой среде все состоит из объектов. Объект обладает следующими свойствами: идентифицируется уникальным неизменным образом, принадлежит к определенному классу, может посылать сообщения другим объектам, имеет внутреннее состояние.
Таким образом, объектно-ориентированная база данных состоит из объектов, каждый из которых должен принадлежать к определенному классу, то есть каждый объект – экземпляр класса. Объектно-ориентированная база данных состоит из коллекции классов. Структура и поведение объектов в объектной среде полностью определяется его классом. Класс, в свою очередь, является коллекцией объектов, при этом структура и поведение объектов одного класса одинаковы.
Класс объекта состоит из его интерфейса и закрытой области. Интерфейс класса – это то, что видно другим объектам. Он, в свою очередь, состоит из двух частей: свойства класса и методов класса. Аналогом свойств являются атрибуты отношений. Например, клиент может иметь следующие свойства: номер, ФИО, адрес, телефон. К свойствам относятся также связи с другими объектами. Свойства сами могут быть объектами, что позволяет создавать составные объекты, например, свойство ФИО может состоять из свойств: фамилия, имя, отчество.
Доступ к значениям свойств и манипулирование ими можно осуществлять только посредством методов класса. То есть поведение объекта задается с помощью методов его класса. Обычно они имеют форму операций и функций, которые могут содержать параметры. На уровне интерфейса видимым является только имя каждого метода и требуемые параметры. Методы служат для передачи объектам сообщений. Другими словами, метод представляет то, что, по мнению пользователя, должен делать объект. Например, клиент может сделать заказ, оплатить счет и т.п. Для каждого из этих видов деятельности должен быть соответствующий метод.