Столбец одной таблицы, значения в котором совпадают со значениями столбца, являющегося первичным ключом другой таблицы, называется внешним ключом. Реляционная модель данных обладает всеми возможностями сетевой модели по части выражения сложных отношений. Внешние ключи являются неотъемлемой частью реляционной модели, поскольку реализуют отношения между таблицами базы данных.
Основная идея реляционной алгебры, являющейся основой реляционной модели, состоит в том, что таблицы являются множествами, следовательно, средства манипулирования ими могут базироваться на традиционных теоретико-множественных операциях, дополненных некоторыми операциями, специфичными для баз данных.
Используется немного расширенный начальный вариант алгебры, который был предложен Коддом. В этом варианте набор основных алгебраических операций состоит из восьми операций, которые делятся на два класса. В состав теоретико-множественных операций входят операции:
- объединения таблиц;
- пересечения таблиц;
- взятия разности таблиц;
- прямого произведения таблиц.
Специальные реляционные операции включают:
- ограничение таблицы;
- проекцию таблицы;
- соединение таблиц;
- деление таблиц.
В настоящее время благодаря расширению функциональности и ухода от классических основ реляционной теории появились новые (постреляционные) модели баз данных (ненормализованные реляционные базы данных, базы сложных объектов, объектно-ориентированные базы данных и т.д.).
1.3 Нормализация базы данных
Процесс трансформации данных в реляционную форму называется нормализацией. По сути нормализация – это удаление избыточных данных из каждой таблицы в базе данных. У нормализации двойная цель – удалить лишние копии данных и обеспечить максимальную гибкость, как в структурах таблиц, так и в интерфейсных приложениях на случай возможных будущих изменений в базах данных.
О нормализации таблиц в базе данных нужно заботиться на раннем этапе проектирования приложения, так как на последующих этапах довольно трудно менять структуру базы. Иногда процесс нормализации порождает добавочные таблицы, которые не были включены в первоначальный проект.
Нормализация обычно подразделяется на шесть форм или стадий – от первой нормальной формы по третью нормальную форму, нормальная форма Бойса-Кодда, четвёртая и пятая нормальные формы. То есть шесть установок реляционного критерия, который либо обнаруживает таблицу, либо нет. Каждая последующая стадия строится на основе предыдущей. На практике, как правило, используется только первые три. Рассмотрим их более подробно.
Первая нормальная форма: для того чтобы таблица считалась нормализованной к первой нормальной форме, каждое из ее полей должно быть неделимым и не должно содержать никаких повторяющихся групп.
Поле считается неделимым, если оно содержит только один элемент данных. Например, поле, которое содержит не только название улицы, но также и города, почтовый код, не является неделимым. Чтобы соответствовать первой нормальной форме, такие столбцы должны быть разбиты на несколько полей.
Повторяющаяся группа — это поле, которое повторяется внутри определения записи с целью хранения нескольких значений для атрибута.
Вторая нормальная форма: для того чтобы привести таблицу ко второй нормальной форме, нужно, чтобы все не ключевые поля полностью зависели от первичного ключа таблицы и от каждого поля в первичном ключе, если последний состоит из нескольких полей. Это значит, что каждое не ключевое поле должно уникально определяться первичным ключом и полями, его составляющими.
Третья нормальная форма: для того чтобы таблица была приведена к третьей нормальной форме, нужно, чтобы все не ключевые поля полностью зависели от первичного ключа таблицы и не зависели друг от друга. Таким образом, к квалификации второй нормальной формы добавляется требование независимости каждого не ключевого поля таблицы от других не ключевых полей.
1.4 Основные требования к организации базы данных
В процессе активного использования концепций реляционных баз данных и их непосредственного применения сформировалась следующая система требований к свойствам и возможностям этих баз.
Установление многосторонних связей: различным программистам требуются различные логические файлы. Эти файлы получаются из одной и той же совокупности данных. Между элементами запоминаемых данных могут существовать различные связи. Некоторые базы данных будут содержать сложные переплетения взаимосвязей. Метод организации данных должен быть таким, чтобы обеспечивалась возможность удобного представления этих взаимосвязей и быстрого согласования вносимых в них изменений. СУБД должна обеспечивать возможность получения требуемых логических файлов из имеющихся данных и существующих между ними связей.
Производительность: базы данных, специально разработанные для использования их оператором терминала, обеспечивают время ответа, удовлетворительное для диалога человека. Кроме того, система баз данных должна обеспечивать соответствующую пропускную способность запросов.
Минимальные затраты: для уменьшения затрат на создание и эксплуатацию базы данных выбираются такие методы организации, которые минимизируют требования к внешней памяти.
Минимальная избыточность: целью организации базы данных должно быть уничтожение избыточных данных там, где это выгодно, и контроль над теми противоречиями, которые вызываются наличием избыточных данных.
Возможности поиска: пользователь базы данных может обращаться к ней с самыми различными вопросами по поводу хранимых данных.
Целостность: если база данных содержит данные, используемые многими пользователями, очень важно, чтобы элементы данных и связи между ними не разрушались.
Безопасность и секретность: данные в системах баз данных должны храниться в тайне и сохранности. Под безопасностью данных понимают защиту данных от случайного или преднамеренного доступа к ним лиц, не имеющих на это право, от неавторизованной модификации данных или их уничтожения. Секретность определяют как право отдельных лиц или организаций определять, когда, как и какое количество соответствующей информации может быть передано другим лицам или организациям.
Связь с прошлым: организации, которые в течение какого-то времени эксплуатируют системы обработки данных, затрачивают значительные средства на написание программ, процедур и организацию хранения данных. В том случае, когда фирма начинает использовать на вычислительной установке новое программное обеспечение управления базами данных, очень важно, чтобы при этом она могла работать с уже существующими на этой установке программами, обрабатываемые данные можно было бы соответствующим образом преобразовывать.
Связь с будущим: особенно важной представляется связь с будущим. В будущем данные и среда их хранения изменятся по многим направлениям. Любая коммерческая организация со временем претерпевает изменения. Особенно дорогими эти изменения оказываются для пользователей системами обработки данных. Одна из самых важных задач, при разработке баз данных – запланировать базу данных таким образом, чтобы изменения ее можно было выполнять без модификации прикладных программ.
Простота использования: средства, которые используются для представления общего логического описания данных, должны быть простыми и изящными. Интерфейс программного обеспечения должен быть ориентирован на конечного пользователя и учитывать возможность того, что пользователь не имеет необходимой базы знаний по теории баз данных.
Выполнение указанных требований в значительной степени упрощается благодаря использованию трехуровневой архитектуры базы данных и архитектуры приложения типа « клиент - сервер », что также позволяет значительно упростить процесс проектирования и сопровождения баз данных, не выходя за рамки вышеописанных требований.
1.5 Трехуровневая архитектура
Архитектура ANSI/SPARC включает в себя три уровня:
- внутренний, наиболее близкий к физическому хранению информации;
- внешний, наиболее близкий к представлению данных конечным пользователям;
- концептуальный, являющийся неким промежуточным, обобщенным представлением между внутренним и внешним уровнями;
При этом может существовать некоторое число внешних представлений, согласно терминологии являющихся представлениями отдельных пользователей, состоящих из абстрактных представлений определенной части базы данных, и лишь один концептуальный, состоящий из абстрактного представления базы в целом, и внутренний, отражающий всю базу как физически хранимую структуру.
Трехуровневая архитектура легко применима для реализации в реляционных системах баз данных. Концептуальный уровень является определенно реляционным, так как объекты этого уровня являются таблицами (также как и операторы работы с ними). Внешние представления также будут реляционными или близкими к этому. Внутренний уровень не будет реляционным, поскольку объекты этого уровня будут не таблицами, а объектами такого же типа, как и находящиеся на внутреннем уровне объекты любой другой системы.
Внешний уровень представлен для различных пользователей различными языками общения: для программиста – это какой-либо язык программирования, для конечного пользователя – язык запросов или специализированный язык, основанный на формах и меню. Вне зависимости от типа, каждый из них включает подъязык данных, связанный только с объектами баз данных. В большинстве случаев это SQL. Любой подъязык данных является комбинацией как минимум двух подчиненных языков – языка определения данных (DDL), поддерживающего объявление объектов базы данных, и языка обработки данных (DML), поддерживающего обработку таких объектов.
Концептуальное представление существенно отличается от представлений внешнего и внутреннего уровней, так как информация представляется в её натуральном, неискаженном в силу потребностей конкретного пользователя виде и без учета подробностей хранения и доступа к ней. Это представление можно рассматривать как множество экземпляров каждого типа концептуальной записи или как совокупность объектов и отношений между ними в некой прямой форме. При этом в концептуальной схеме определения информации нет никакого упоминания её физической структуры. Обеспечиваемая этим независимость данных предопределяет независимость соответствующей внешней схемы.
Внутреннее представление можно рассматривать как множество экземпляров каждого типа внутренней записи в неком бесконечном линейном адресном пространстве. Подробности непосредственного отображения его на физическое устройство хранения преднамеренно не включены в архитектуру в силу их большой обусловленности системой.
Таким образом, трехуровневая архитектура определяет два отображения уровней: концептуального на внутренний и внешнего на концептуальный. Соответствие, определяемое первым отображением должно быть таким, чтобы при изменении структуры хранимой базы концептуальная схема осталась неизменной.
Страницы: 1, 2, 3, 4, 5, 6, 7
