Манипулирование реляционными данными 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Манипулирование реляционными данными



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

Предложив реляционную модель данных, Э.Ф.Кодд создал и инструмент для удобной работы с отношениями - реляционную алгебру. Каждая операция этой алгебры использует одну или несколько таблиц (отношений) в качестве ее операндов и продуцирует в результате новую таблицу, т.е. позволяет "разрезать" или "склеивать" таблицы (рис. 3.3).

Рис. 3.3. Некоторые операции реляционной алгебры

Созданы языки манипулирования данными, позволяющие реализовать все операции реляционной алгебры и практически любые их сочетания. Среди них наиболее распространены SQL (Structured Query Language - структуризованный язык запросов) и QBE (Quere-By-Example - запросы по образцу) [3, 5]. Оба относятся к языкам очень высокого уровня, с помощью которых пользователь указывает, какие данные необходимо получить, не уточняя процедуру их получения.

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

Глава 4. Введение в проектирование реляционных баз данных

Цели проектирования

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

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

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

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

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

При проектировании информационной системы необходимо провести анализ целей этой системы и выявить требования к ней отдельных пользователей (сотрудников организации) [2, 3, 4, 6, 8, 9, 10]. Сбор данных начинается с изучения сущностей организации и процессов, использующих эти сущности (подробнее в приложении Б). Сущности группируются по "сходству" (частоте их использования для выполнения тех или иных действий) и по количеству ассоциативных связей между ними (самолет - пассажир, преподаватель - дисциплина, студент - сессия и т.д.). Сущности или группы сущностей, обладающие наибольшим сходством и (или) с наибольшей частотой ассоциативных связей объединяются в предметные БД. (Нередко сущности объединяются в предметные БД без использования формальных методик - по "здравому смыслу".) Для проектирования и ведения каждой предметной БД (нескольких БД) назначается АБД, который далее занимается детальным проектированием базы.

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

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

Универсальное отношение

Предположим, что проектирование базы данных "Питание" (рис. 3.2) начинается с выявления атрибутов и подбора данных, образец которых (часть блюд изготовленных и реализованных 1/9/94 г.) показан на рис. 4.1.

Этот вариант таблицы "Питание" не является отношением, так как большинство ее строк не атомарны. Атомарными являются лишь значения полей Блюдо, Вид, Рецепт (хотя он и большой), Порций и Дата_Р остальные же поля таблицы рис. 4.1 - множественные. Для придания таким данным формы отношения необходимо реконструировать таблицу. Наиболее просто это сделать с помощью простого процесса вставки, результат которой показан на рис. 4.2. Однако такое преобразование приводит к возникновению большого объема избыточных данных.

Блюдо Вид Рецепт Порций Дата Р Продукт Калорийность Вес (г) Поставщик Город Страна Вес (кг) Цена ($) Дата П
Лобио Закуска Лом.   1/9/94 Фасоль     "Хуанхэ" Пекин Китай   0.37 24/8/94
          Лук     "Наталка" Киев Украина   0.52 27/8/94
          Масло     "Лайма" Рига Латвия   1.55 30/8/94
          Зелень     "Даугава" Рига Латвия   0.99 30/8/94
Харчо Суп ...   1/9/94 Мясо     "Наталка" Киев Украина   2.18 27/8/94
          Лук     "Наталка" Киев Украина   0.52 27/8/94
          Томаты     "Полесье" Киев Украина   0.45 27/8/94
          Рис     "Хуанхэ" Пекин Китай   0.44 24/8/94
          Масло     "Полесье" Киев Украина   1.62 27/8/94
          Зелень     "Наталка" Киев Украина   0.88 27/8/94
Шашлык Горячее ...   1/9/94 Мясо     "Юрмала" Рига Латвия   2.05 30/8/94
          Лук     "Полесье" Киев Украина   0.61 27/8/94
          Томаты     "Полесье" Киев Украина   0.45 27/8/94
          Зелень     "Даугава" Рига Латвия   0.99 30/8/94
Кофе Десерт ...   1/9/94 Кофе     "Хуанхэ" Пекин Китай   2.87 24/8/94

Рис. 4.1. Данные, необходимые для создания базы данных "Питание"

Таблица на рис. 4.2 представляет собой экземпляр корректного отношения. Его называют универсальным отношением проектируемой БД. В одно универсальное отношение включаются все представляющие интерес атрибуты, и оно может содержать все данные, которые предполагается размещать в БД в будущем. Для малых БД (включающих не более 15 атрибутов) универсальное отношение может использоваться в качестве отправной точки при проектировании БД.

Блюдо Вид Рецепт Порций Дата Р Продукт Калорийность Вес (г) Поставщик Город Страна Вес (кг) Цена ($) Дата П
Лобио Закуска Лом.   1/9/94 Фасоль     "Хуанхэ" Пекин Китай   0.37 24/8/94
Лобио Закуска Лом   1/9/94 Лук     "Наталка" Киев Украина   0.52 27/8/94
Лобио Закуска Лом   1/9/94 Масло     "Лайма" Рига Латвия   1.55 30/8/94
Лобио Закуска Лом   1/9/94 Зелень     "Даугава" Рига Латвия   0.99 30/8/94
Харчо Суп ...   1/9/94 Мясо     "Наталка" Киев Украина   2.18 27/8/94
Харчо Суп ...   1/9/94 Лук     "Наталка" Киев Украина   0.52 27/8/94
Харчо Суп ...   1/9/94 Томаты     "Полесье" Киев Украина   0.45 27/8/94
Харчо Суп ...   1/9/94 Рис     "Хуанхэ" Пекин Китай   0.44 24/8/94
Харчо Суп ...   1/9/94 Масло     "Полесье" Киев Украина   1.62 27/8/94
Харчо Суп ...   1/9/94 Зелень     "Наталка" Киев Украина   0.88 27/8/94
Шашлык Горячее ...   1/9/94 Мясо     "Юрмала" Рига Латвия   2.05 30/8/94
Шашлык Горячее ...   1/9/94 Лук     "Полесье" Киев Украина   0.61 27/8/94
Шашлык Горячее ...   1/9/94 Томаты     "Полесье" Киев Украина   0.45 27/8/94
Шашлык Горячее ...   1/9/94 Зелень     "Даугава" Рига Латвия   0.99 30/8/94
Кофе Десерт ...   1/9/94 Кофе     "Хуанхэ" Пекин Китай   2.87 24/8/94

Рис. 4.2. Универсальное отношение "Питание"



Поделиться:


Последнее изменение этой страницы: 2016-09-13; просмотров: 141; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.148.102.90 (0.009 с.)